Re: Dateisysteme, Unicode, UTF-8 und Konvertierungsprobleme
Moin Martin! Martin v. Löwis schrieb am Friday, den 14. March 2003: , kein Dateisystem unterstützt Unicode, es gibt nicht mal eine interne Zeichensatzdeklaration, die den Zeichensatz angibt. Falsch. Man kann gut UTF-8 in Dateinamen verwenden. In NFSv4 ist sogar festgelegt, dass Dateinamen in UTF-8 kodiert sind. Doch. Mit Unterstützen meine ich richtige auf- und abwährtskompatible Lösung. Das ist so nicht gegeben, der verwendete Zeichensatz wird nirgendwo deklariert. Dass NFSv4 UTF-8 eindeutig vorschreibt ist dagegen eine gute Tatsache. Alphabete mit nicht-lateinischen Zeichen wurden nach bestimmten Tabellen (NLS-Zeichensätzen) in dem erweiterten (8-bit) ASCII verteilt. Falsch. Man kann sehr gut Multi-Byte-Zeichensätze in Dateisystemen benutzen; davon wird auch intensive gebrauch gemacht. Jain, sehr gut würde ich nicht dazu sagen, die Multi-Byte-Zeichensätze verursachen im Prinzip die gleichen Probleme wie Unicode. Während Probleme mit Zeichensätzen den Windows-Usern spaetestens seit Win2k fremd sind, müssen sich Linux-Benutzer noch lange Zeit damit plagen. Ich bin nicht sicher. Redhat 8 geht in die richtige Richtigung: Alle locales verwenden UTF-8, und das Problem ist gelöst. Nur bedingt: was ist mit der Umwandlung der vorhandenen Dateinamen? Und was ist mit Anwendungen, die nicht UTF-8-vorbereitet sind? Andererseits, man kann den alten Kram aus der Distribution rausoperieren und das Problem ist gelöst. Man ist in der Regel auf ein Zeichensatz beschränkt und muss die gesammte Umgebung auf eine andere Locale umstellen (und ausserdem überall händisch Fonts ändern, sofern das nicht durch Toolkits wie Gt vereinheitlich ist), wenn man mit anderen Welten Kontakt aufnehmen will. Falsch. Das hängt von der anderen Welt ab: In der Regel ist die Windows, und man kann für Dateisystemnamen die Mount-Optionen verwenden. Doch. Um die Umstellung der Umgebung kommt man nicht herum. Wenn es lediglich um die Dateinamen geht - die werden halt falsch angezeigt, aber i.d.R. trotzdem angenommen. Es gibt nähmlich keinen Mechanismus für Abwährtskompatiblität (wie in Windows-XP), mit dem das System die Soll-Sprache einer Anwendung erkennt und aus dem System-Internen Unicode automatisch mit der Soll-Sprache der Anwendung kommuniziert. Falsch. Es gibt verschiedene solcher Mechanismen, etwa das X-Clipboard. Stimmt, das ist das wenigste. - Bei nicht-lateinischen Zeichensätzen benötigen die Zeichen mehr Platz, somit schrumpft die maximale Stringlänge beim gleichbleibenden reelen Speicherplatz (z.B. in Dateinamen). Womit wir früher oder später auf ein anderes Problem zusteuern, Beschränkungen, die man z.B. von Joliet kennt (64Zeichen) Falsch: Das hängt von den nicht-lateinischen Zeichen ab. Kyrillisch, Armenisch, Hebräisch usw. brauchen in UTF-8 geringfügig weniger Platz als UCS-2 (wenn im Text Leerzeichen vorkommen). Falsch. Z.B. kyrillische Zeichen verwenden andere Codes, auch wenn sie beinahe identisch aussehen. Sieh selbst nach. Gruss/Regards, Eduard. -- Wenn der Bauer das Schwein verhaut, hat es Scheiße wohl gebaut. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Dateisysteme, Unicode, UTF-8 und Konvertierungsprobleme
Eduard Bloch wrote: Ich bin nicht sicher. Redhat 8 geht in die richtige Richtigung: Alle locales verwenden UTF-8, und das Problem ist gelöst. Nur bedingt: was ist mit der Umwandlung der vorhandenen Dateinamen? Die muss man konvertieren (durch Umbenennung). Gewisse Probleme mit mojibake wird man nicht vermeiden können - allerdings sind andere Systeme da auch nicht besser; unter Windows sind beispielsweise nach wie vor *zwei* Zeichensätze in Verwendung: der Zeichensatz im Terminalfenster (OEMCP) ist ein anderer als der im Window-Teil (ACP). Und was ist mit Anwendungen, die nicht UTF-8-vorbereitet sind? An welche denkst Du da genau? Alle meine Anwendungen, die irgendwie mit Dateinamen zu tun haben, kommen gut mit beliebigen Kodierungen derselben klar: Entweder ist es ihnen egal, weil sie die sowieso nur weiterreichen (etwa /bin/ls), oder aber entsprechend der locale darstellen (Gnome, etc). Ein gewisses mojibake muss man vermutlich wiederum akzeptieren, bis die restlichen Bugs gefixt sind: Auch unter Windows haben viele Programme Schwierigkeiten mit Dateinamen, die in ACP nicht repräsentierbar sind; diese Programme erhalten dann Fragezeichen anstelle der eigentlichen Zeichen. - Bei nicht-lateinischen Zeichensätzen benötigen die Zeichen mehr Platz, somit schrumpft die maximale Stringlänge beim gleichbleibenden reelen Speicherplatz (z.B. in Dateinamen). Womit wir früher oder später auf ein anderes Problem zusteuern, Beschränkungen, die man z.B. von Joliet kennt (64Zeichen) Falsch: Das hängt von den nicht-lateinischen Zeichen ab. Kyrillisch, Armenisch, Hebräisch usw. brauchen in UTF-8 geringfügig weniger Platz als UCS-2 (wenn im Text Leerzeichen vorkommen). Falsch. Z.B. kyrillische Zeichen verwenden andere Codes, auch wenn sie beinahe identisch aussehen. Sieh selbst nach. Hab ich doch gemacht: Nehmen wir als Beispiel CYRILLIC CAPITAL LETTER ZHE, U+0416. In UCS-2 ist das \x04\x16, in UTF-8 ist es \xd0\x96. In beiden Fällen zwei Byte. An welches Zeichen dachtest Du? Ciao, Martin -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Dateisysteme, Unicode, UTF-8 und Konvertierungsprobleme
#include hallo.h * Stephan Seitz [Thu, Mar 13 2003, 05:55:44PM]: Folgendes: Du bringst 2 Sachen zusammen die nicht zusammen gehören. Einmal gibts da die Kodierung der Dateinamen im Dateisystem - bei Redhat 8 wird offensichtlich die Standard NLS auf UTF-8 gesetzt und damit werden dann alle Dateinamen in UTF-8 kodiert. Das andere ist die Anzeige von UTF-8 kodierten Dingen. Das eine hat mit dem anderen nahezu nichts IMO ja. Dann werden die Dateinamen direkt in UTF-8 geschrieben. Sagt mal, ist es bei Dateisystemen wie ext2/3 oder reiser nicht so, daß die Kodierung von der locale abhängig ist? Also ich habe hier ein Verzeichnis angelegt unter einer UTF-8-Umgebung (locale: de_DE.UTF-8) und die Namen sind falsch in [EMAIL PROTECTED] (also iso-8859-15) und natürlich umgekehrt. Ich dachte immer, diese NLS-Module bräuchte man nur für Samba, CD-ROM oder FAT, zumindest lädt der Kernel diese Module nur in diesem Zusammenhang. Folgendes behaupte ich ohne Anspruch auf Richtigkeit: Dateisysteme unter Linux und ihre Kodierungen sind eine komplizierte Angelegenheit. Allgemein ist Internationalisierung nur mit langfristiger und grundlegender Plannung elegant realisierbar. Microsoft erkannte dies schon vor zehn Jahren und ihre neuere Dateisysteme verwenden allesamt Unicode (VFAT, VFAT32, Joliet, NTFS, interne Kodierung ist AFAIK UCS-2 mit BOM, d.h. immer zwei-bytig mit einer Endianes-Markierung am Stringanfang) [1]. Unter Linux dagegen hat man lange Zeit geschlafen: grundsätzlich wurde alles auf der Annahme: Zeichen=Byte aufgebaut, kein Dateisystem unterstützt Unicode, es gibt nicht mal eine interne Zeichensatzdeklaration, die den Zeichensatz angibt. Alphabete mit nicht-lateinischen Zeichen wurden nach bestimmten Tabellen (NLS-Zeichensätzen) in dem erweiterten (8-bit) ASCII verteilt. Während Probleme mit Zeichensätzen den Windows-Usern spaetestens seit Win2k fremd sind, müssen sich Linux-Benutzer noch lange Zeit damit plagen. Man ist in der Regel auf ein Zeichensatz beschränkt und muss die gesammte Umgebung auf eine andere Locale umstellen (und ausserdem überall händisch Fonts ändern, sofern das nicht durch Toolkits wie Gtk vereinheitlich ist), wenn man mit anderen Welten Kontakt aufnehmen will. Es gibt nähmlich keinen Mechanismus für Abwährtskompatiblität (wie in Windows-XP), mit dem das System die Soll-Sprache einer Anwendung erkennt und aus dem System-Internen Unicode automatisch mit der Soll-Sprache der Anwendung kommuniziert. Immerhin kann man bei deutschen Texten auch mit 7-bit ASCII auskommen, das Umschreiben von wenigen Umlauten ist erträglich. Bei anderen, z.B. kyrillischen Zeichensätzen, sieht es dagegen düster aus. Als Lösung aus der Misere wurde UTF-8 auserkoren. Dies ist eine echte Unicode-Variante: Mischung aus dem herkömmlichen ASCII und Unicode-Zeichen, die in die Byte-Zeichen eingebettet werden. Der Vorteil von UTF-8 ist die vollständige Kompatibilität zu ASCII (7-bit, keine Probleme mit englischer Sprache) und somit die platzsparende Datenlagerung im Vergleich zu UCS-2 oder UCS-4 bei wissenschaftlichen Daten u.Ae. Aber nichts geht ohne Nachteile: - Bei nicht-lateinischen Zeichensätzen benötigen die Zeichen mehr Platz, somit schrumpft die maximale Stringlänge beim gleichbleibenden reelen Speicherplatz (z.B. in Dateinamen). Womit wir früher oder später auf ein anderes Problem zusteuern, Beschränkungen, die man z.B. von Joliet kennt (64Zeichen) - Es ist nicht kompatibel zu vorhanden 8bit-Zeichensaetzen; somit sind alle Sprachen wieder gleichberechtigt und betroffene Benutzer gleichermassen von Umstellungsproblemen betroffen. Diese sind gewaltig, zu viele Programme sind einfach kurzsichtig entstanden und müssen geändert werden. Siehe Unicode-on-Linux-Howto für Details. - Daraus resultiert auch das nächste Problem: UTF-8 soll die nativen Zeichensätze irgendwann mal ersetzen. Unter ungünstigen Umständen, und diese sind immer zu erwarten, wenn man den Übergang nicht sorgfältig plannt, ensteht ein Gemisch aus UTF-8 und Zeichen in der alten NLS-Kodierung (z.B. latin1). Mir fällt nur eine vernünftige Lösung, um mit diesem Schlamassel aufzuräumen: - für Korrektur vorher: Perl-Skript, das das Dateisystem durchgeht und die Dateinamen NLS-UTF-8 ändern - für Korrektur nach der Panne: Perl-Skript, das das Dateisystem durchgeht und nur typische Spezialzeichen (hier: Umlaute) erkennt und ins UTF-8 umwandelt. [1] Es ist also möglich, beliebige Zeichen auf von MS-stammenden Dateisystemen zu speichern. Mit der Mount-Option iocharset=8-bit-zeichensatz wandelt der Kernel die Zeichen zwischen einer best. NLS-Kodierung für die Anwendungen und den gespeicherten Unicode-Dateinamen im Dateisytem. Mit der Option utf-8 kodiert der Kernel das Dateisystem-interne Unicode-Format ins UTF-8-Unicode, das für die Anwendungen sichtbar wird. Dies erfordet natürlich Programe, die damit auch umgehen können, siehe oben. Mir ist leider keine Option bekannt,
Re: Dateisysteme, Unicode, UTF-8 und Konvertierungsprobleme
Eduard Bloch wrote: Folgendes behaupte ich ohne Anspruch auf Richtigkeit: Ist ziemlich richtig. Ich versuche mal, die Fehler zu finden: Dateisysteme unter Linux und ihre Kodierungen sind eine komplizierte Angelegenheit. Allgemein ist Internationalisierung nur mit langfristiger und grundlegender Plannung elegant realisierbar. (Planung) Microsoft erkannte dies schon vor zehn Jahren und ihre neuere Dateisysteme verwenden allesamt Unicode (VFAT, VFAT32, Joliet, NTFS, interne Kodierung ist AFAIK UCS-2 mit BOM, d.h. immer zwei-bytig mit einer Endianes-Markierung am Stringanfang) [1]. Ist ohne BOM, und ist zunehmend auch UTF-16. Unter Linux dagegen hat man lange Zeit geschlafen: grundsätzlich wurde alles auf der Annahme: Zeichen=Byte aufgebaut Ich bin hier nicht so sicher. Es ist eher die Annahme: Dateinamen=Bytefolgen; Zeichen sind uninteressant und Aufgabe der Anwendung. , kein Dateisystem unterstützt Unicode, es gibt nicht mal eine interne Zeichensatzdeklaration, die den Zeichensatz angibt. Falsch. Man kann gut UTF-8 in Dateinamen verwenden. In NFSv4 ist sogar festgelegt, dass Dateinamen in UTF-8 kodiert sind. Alphabete mit nicht-lateinischen Zeichen wurden nach bestimmten Tabellen (NLS-Zeichensätzen) in dem erweiterten (8-bit) ASCII verteilt. Falsch. Man kann sehr gut Multi-Byte-Zeichensätze in Dateisystemen benutzen; davon wird auch intensive gebrauch gemacht. Während Probleme mit Zeichensätzen den Windows-Usern spaetestens seit Win2k fremd sind, müssen sich Linux-Benutzer noch lange Zeit damit plagen. Ich bin nicht sicher. Redhat 8 geht in die richtige Richtigung: Alle locales verwenden UTF-8, und das Problem ist gelöst. Man ist in der Regel auf ein Zeichensatz beschränkt und muss die gesammte Umgebung auf eine andere Locale umstellen (und ausserdem überall händisch Fonts ändern, sofern das nicht durch Toolkits wie Gt vereinheitlich ist), wenn man mit anderen Welten Kontakt aufnehmen will. Falsch. Das hängt von der anderen Welt ab: In der Regel ist die Windows, und man kann für Dateisystemnamen die Mount-Optionen verwenden. Es gibt nähmlich keinen Mechanismus für Abwährtskompatiblität (wie in Windows-XP), mit dem das System die Soll-Sprache einer Anwendung erkennt und aus dem System-Internen Unicode automatisch mit der Soll-Sprache der Anwendung kommuniziert. Falsch. Es gibt verschiedene solcher Mechanismen, etwa das X-Clipboard. [UTF-8] - Bei nicht-lateinischen Zeichensätzen benötigen die Zeichen mehr Platz, somit schrumpft die maximale Stringlänge beim gleichbleibenden reelen Speicherplatz (z.B. in Dateinamen). Womit wir früher oder später auf ein anderes Problem zusteuern, Beschränkungen, die man z.B. von Joliet kennt (64Zeichen) Falsch: Das hängt von den nicht-lateinischen Zeichen ab. Kyrillisch, Armenisch, Hebräisch usw. brauchen in UTF-8 geringfügig weniger Platz als UCS-2 (wenn im Text Leerzeichen vorkommen). - Es ist nicht kompatibel zu vorhanden 8bit-Zeichensaetzen; somit sind alle Sprachen wieder gleichberechtigt und betroffene Benutzer gleichermassen von Umstellungsproblemen betroffen. Diese sind gewaltig, zu viele Programme sind einfach kurzsichtig entstanden und müssen geändert werden. Siehe Unicode-on-Linux-Howto für Details. Richtig. Das gilt natürlich auch für UCS-2. - für Korrektur vorher: Perl-Skript, das das Dateisystem durchgeht und die Dateinamen NLS-UTF-8 ändern Richtig; Python tut's auch. Ciao, Martin -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
