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(Planung)
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].
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)
