Ist es bekannt, dass das Aufzählungszeichen (laut Windows Zeichentabelle, U+2022, 0x95, Alt+0149) in Dateinamen [1] beim Packen mit dem TC-internen-Packer in ein Zip-Archiv in ein BEL verwandelt wird? Solche Dateien können dann nicht mehr wieder aus dem Archiv herauskopiert werden (Man kann sie aber im Archiv umbenennen und dadurch wieder benutzbar machen.)
JOUBE
Entsprechende Dateien entstehen zum Beispiel, wenn man mit dem Firefox-Browser mit installiertem Addon "FileTitle" Seiten des Forums unter thunderbird-mail.de abspeichert.
Das Aufzählungszeichen und ZIP-Archive
Moderators: Hacker, Stefan2, white
Re: Das Aufzählungszeichen und ZIP-Archive
Wer oder was ist BEL?JOUBE wrote:....in ein BEL verwandelt wird? ...
Peter
TC 10.xx / #266191
Win 10 x64
Win 10 x64
Danke für den Hinweis. So ganz zufrieden bin ich mit der Antwort aber keineswegs.HolgerK wrote:wincmd.ini
Section [Packer]
ZipUnicode=3
Warum wird denn da aus dem Aufzählungszeichen ausgerechnet ein BEL gemacht? Nur weil es (unter Windows) so schön ähnlich aussieht? Das wäre ja nun nicht gerade sehr gut umgesetzt. Kopfschüttel.
Das müsste man als erstes konfigurieren können. Andere Programme machen das in anderen Zusammenhängen ja sinnvollerweise so, dass solche speziellen Zeichen wie das Aufzählungszeichen ggf durch (zum Beispiel) Unterstriche ersetzt werden, um die Kompatibilität zu wahren.
Beim Austausch vom Aufzählungszeichen zum BEL ist ja wohl, gelinde gesagt, eine Miss(t)-Implementation unterlaufen. Ist das uU. so, dass das schon im (IIRC) Ntzip-Projekt passiert ist?
JOUBE
-
ghisler(Author)
- Site Admin
- Posts: 50708
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
TC speichert die Umlaute aus Kompatibilitätsgründen im DOS-Format von pkzip. Die Umwandlung übernimmt die Windows-Funktion CharToOem.
Sie können sie auch als ANSI speichern lassen (Archiv wird dann als Windows-Archiv markiert), doch kommen nicht alle Entpacker damit klar.
wincmd.ini
Section [Packer]
ZipAnsiNames=1
Sie können sie auch als ANSI speichern lassen (Archiv wird dann als Windows-Archiv markiert), doch kommen nicht alle Entpacker damit klar.
wincmd.ini
Section [Packer]
ZipAnsiNames=1
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Das ist ja gut.ghisler(Author) wrote:TC speichert die Umlaute aus Kompatibilitätsgründen im DOS-Format von pkzip.
Das ist ja nicht so schön. Ist diese denn in der heutigen Implementation noch kompatibel zu pkzip?ghisler(Author) wrote:Die Umwandlung übernimmt die Windows-Funktion CharToOem.
HolgerK wrote:ZipUnicode=3
Ja, kann ich machen. Aber ich würde da gerne noch etwas ausführlichere Infos haben, als es die knappen Statemants in der Hilfe sind. Ist das einmal irgendwo ausführlicher diskutiert worden?ghisler(Author) wrote:ZipAnsiNames=1
JOUBE
Hallo, JOUBE.
Die Diskussionen über die Regeln, nach denen eine Umwandlung von ANSI-Zeichensätzen in ASCII-Zeichensätzen erfolgen sollte, dürfte so lange geführt worden sein, wie ASCII-Zeichensätze und ANSI-Zeichensätze nebeneinanderher existieren.
Egal welche Regeln man aufstellt, man kommt um das Problem nicht drumherum, dass ANSI-Zeichensätze Zeichen enthalten, die in ASCII-Zeichensätzen keine Entsprechung haben und umgekehrt.
Es handelt sich daher um kein Total Commander spezifisches Problem, sondern um ein allgemeines. Drum dürfte es zu Hauf z.B. WIKI Artikel zu dem Thema geben.
Das Bestechende an Holgerk's Vorschlag, auf die ganze Zeichenersetzung zu verzichten und stattdessen die Unicode verwendende Lösung zu benutzen, ZipUnicode=3, ist, dass man damit das Problem komplett umgeht, weil Unicode-Zeichensätze viel mehr Zeichen wiedergeben können.
Grüße,
Karl
Die Diskussionen über die Regeln, nach denen eine Umwandlung von ANSI-Zeichensätzen in ASCII-Zeichensätzen erfolgen sollte, dürfte so lange geführt worden sein, wie ASCII-Zeichensätze und ANSI-Zeichensätze nebeneinanderher existieren.
Egal welche Regeln man aufstellt, man kommt um das Problem nicht drumherum, dass ANSI-Zeichensätze Zeichen enthalten, die in ASCII-Zeichensätzen keine Entsprechung haben und umgekehrt.
Es handelt sich daher um kein Total Commander spezifisches Problem, sondern um ein allgemeines. Drum dürfte es zu Hauf z.B. WIKI Artikel zu dem Thema geben.
Das Bestechende an Holgerk's Vorschlag, auf die ganze Zeichenersetzung zu verzichten und stattdessen die Unicode verwendende Lösung zu benutzen, ZipUnicode=3, ist, dass man damit das Problem komplett umgeht, weil Unicode-Zeichensätze viel mehr Zeichen wiedergeben können.
Grüße,
Karl
Last edited by karlchen on 2010-06-26, 06:44 UTC, edited 1 time in total.
Mag ja sein. Aber wenn ich das richtig sehe (ich habe aber nicht sehr umfangreich gesucht), beziehen sich die Threads zu diesem Thema in diesem Board überwiegend auf das BEL, weil es aus der Umwandlung des Aufzählungszeichens hervorgeht.karlchen wrote:Es handelt sich daher um kein Total Commander spezifisches Problem
Dabei handelt es dann gar nicht mehr um eine allgemeine Umwandlungfrage, sondern eher um eine Problematik, die daher rührt, dass es bei den hier in anderen Beiträgen beschriebenen Zeichen-Umwandlungen um Routinen für Texte handelt und nicht um Umwandlungen für Dateinamen. Denn dort ist es mehr als ungeschickt, das BEL zu verwenden.
Insofern kann man sich fragen, ob es sinnvoll ist, Zeichenumwandlungsroutinen für Texte bei Dateinamen anzuwenden. Wenn man das schon tut, dann sollte man die Dateinamen danach vielleicht besser noch einmal durch einen eigenen Ersetzungsfilter jagen [1]. Was ich hiermt für den Tc beantrage.
Dies betrifft insbesondere das Aufzählungszeichens, das hierzulande eben häufiger beim Abspeichern von Webseiten in Dateinamen entsteht. Da sollte man sich nicht fingerpointend auf ein "is eben so" zurückziehen. Insofern werde ich nicht mit irgendwelchen Spezialeinstellungen rumeiern, sondern darauf warten, dass der Dateimanager Tc in bezug auf Dateinamen seine Arbeit tut (Von mir aus: optional einstellbar).
JOUBE
[1] Andere machens ja auch. Ein Beispiel: Die Zeichen-Ersetzung von Doppelpunkten in Dateinamen beim Abspeichern von Webseiten durch Browser. Der Doppelpunkt wird dabei zum Unterstrich (und das ist höchstwahrscheinlich durch keine der genannten Standard-Umwandlungsroutinen abgedeckt). Genauso wie der Doppelpunkt in Dateinamen ein Betriebssystemproblem ist, genauso ist das BEL (und andere Funktionszeichen) ein Spezialproblem bei Zip-Archiven, das mit Standardroutinen nicht abdeckbar ist.
Hallo, JOUBE.
In Zeiten, da die Verwendung von Unicode-Dateinamen von allen auch nur halbwegs aktuellen Windows Versionen und von allen auch nur halbwegs aktuellen Programmen unterstützt wird, vermeidet man das Problem mit dem Klingelzeichen (BEL), indem man z.B. im Total Commander im Abschnitt [Packer] den Parameter ZipUnicode=3 stehen hat (läßt sich im Konfigurationsdailog einstellen, kein direktes Editieren der wincmd.ini erforderlich).
Heutzutage noch spezielle Sonderersetzungsregeln aufzustellen für bestimmte ANS/ASCII-Zeichen, die im jeweils anderen Zeichensatz keine genaue Entsprechung haben, ist aus meiner Sicht nicht die sinnvollste Art, seine Zeit zu verwenden. Zumal es sehr viele verschiedene Codepages gibt und damit sehr viele Pärchen von ANSI/ASCII-Zeichensetzen, die Zeichenumsetzungen erfordern.
Grüße
Karl
In Zeiten, da die Verwendung von Unicode-Dateinamen von allen auch nur halbwegs aktuellen Windows Versionen und von allen auch nur halbwegs aktuellen Programmen unterstützt wird, vermeidet man das Problem mit dem Klingelzeichen (BEL), indem man z.B. im Total Commander im Abschnitt [Packer] den Parameter ZipUnicode=3 stehen hat (läßt sich im Konfigurationsdailog einstellen, kein direktes Editieren der wincmd.ini erforderlich).
Heutzutage noch spezielle Sonderersetzungsregeln aufzustellen für bestimmte ANS/ASCII-Zeichen, die im jeweils anderen Zeichensatz keine genaue Entsprechung haben, ist aus meiner Sicht nicht die sinnvollste Art, seine Zeit zu verwenden. Zumal es sehr viele verschiedene Codepages gibt und damit sehr viele Pärchen von ANSI/ASCII-Zeichensetzen, die Zeichenumsetzungen erfordern.
Grüße
Karl
Das schriebst du schon...karlchen wrote:ZipUnicode=3
Ich habe immer etwas Hemmungen von grundlegenden Standards abzuweichen. Dazu habe ich schon zu viele programmspezifische Erweiterungen von Standards kommen und mit den Programmen wieder unter gehen gesehen...
Wer kann denn alles mit, mit ZipUnicode=3 erzeugten Archiven umgehen? Oder anders gefragt: wer alles nicht? (Ist Zip eigentlich inzwischen ISO normiert oder immer noch ein Quasi-Standard? Wie ordnen sich da die mit ZipUnicode=3 erweiterten Archive ein? Sollte ich den Tc brauchen, um solchartige Archive wieder korrekt zu entpacken, würde ich das natürlich nicht verwenden).
JOUBE
Hallo, JOUBE.
Soweit ich das bisher beobachten konnte, mögen 7Zip und Total Commander die von ihnen erzeugten ZIP-Dateien mit Unicode-kodierten Dateinamen drinne wechselseitig.
Habe das mal auf Grund eines älteren Threads mit Dateinamen ausprobiert, die wegen vorhandener Sonderzeichen als Unicode abgespeichert wurden.
7ZIP versteht Total Commander und Total Commander versteht ZIP-Dateien, die von 7Zip erzeugt worden sind. (ZIP-Dateien, nicht 7Z-Dateien). Wahrheitsgemäß gestehe ich gleich ein, dass ich nicht garantieren kann, dass das auch auf alle anderen ZIP-fähigen Packprogramme in aktueller Version am Markt zutrifft.
Standards einzuhalten an sich, ist eine gute Sache, solange bis die Notwendigkeiten sich verändert haben und von den Standards nicht mehr abgedeckt werden. Dass man dabei dann die Abwärtskompatibilität ein Stück weit aufgeben muß, ist wohl so.
So ähnlich scheinen das auch die Macher von Winzip zu betrachten und erweitern gelegentlich den alten, von PKWare gesetzten Quasi-Standard nach ihrem Gusto und schaffen damit dann neue Quasi-Standards.
Zumindest bis gut 2007 gab es wohl sowas wie eine ISO Norm ZIP-Format nicht. Aber das ist drei Jahre her. So eine Norm könnte heute existieren oder aber eher nicht.
Das Ganze ist sicherlich immer eine Abwägungsfrage.
Grüße,
Karl
Soweit ich das bisher beobachten konnte, mögen 7Zip und Total Commander die von ihnen erzeugten ZIP-Dateien mit Unicode-kodierten Dateinamen drinne wechselseitig.
Habe das mal auf Grund eines älteren Threads mit Dateinamen ausprobiert, die wegen vorhandener Sonderzeichen als Unicode abgespeichert wurden.
7ZIP versteht Total Commander und Total Commander versteht ZIP-Dateien, die von 7Zip erzeugt worden sind. (ZIP-Dateien, nicht 7Z-Dateien). Wahrheitsgemäß gestehe ich gleich ein, dass ich nicht garantieren kann, dass das auch auf alle anderen ZIP-fähigen Packprogramme in aktueller Version am Markt zutrifft.
Standards einzuhalten an sich, ist eine gute Sache, solange bis die Notwendigkeiten sich verändert haben und von den Standards nicht mehr abgedeckt werden. Dass man dabei dann die Abwärtskompatibilität ein Stück weit aufgeben muß, ist wohl so.
So ähnlich scheinen das auch die Macher von Winzip zu betrachten und erweitern gelegentlich den alten, von PKWare gesetzten Quasi-Standard nach ihrem Gusto und schaffen damit dann neue Quasi-Standards.
Zumindest bis gut 2007 gab es wohl sowas wie eine ISO Norm ZIP-Format nicht. Aber das ist drei Jahre her. So eine Norm könnte heute existieren oder aber eher nicht.
Das Ganze ist sicherlich immer eine Abwägungsfrage.
Grüße,
Karl
Ein "Quasi-Standard" und "Irgendwas" von WinZip sind immer noch ziemlich verschiedene Dinge.karlchen wrote:So ähnlich scheinen das auch die Macher von Winzip zu betrachten und erweitern gelegentlich den alten, von PKWare gesetzten Quasi-Standard nach ihrem Gusto und schaffen damit dann neue Quasi-Standards.
Interessant ist in diesem Zusammenhang hauptsächlich das Verhalten von Windows, das ja Zip-Archive auch wie Verzeichnisse öffen kann. Wenn MS da eine Möglichkeit unterstützt, dann kann man damit rechnen, dass das auch in künfigen Versionen der Fall sein wird. Klappt es denn damit?
JOUBE