[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: smbfs, codepage, iocharset, user



* Rüdiger Noack:

> Theoretisch nicht, praktisch sehe ich mehr Probleme als Vorteile.

Vermutlich meinst Du a) nicht utf8-fähige Programme und b) die Arbeit an
der Textconsole.

(a) lassen sich entweder substituieren oder per alias aus einer lokalen
iso8859-Umgebung starten.

(b) Wenn der Rechner hauptsächlich ohne X verwendet wird, sehe ich einen
ernsthaften Grund, nicht auf utf8 umzusteigen. Es funktioniert zwar
rudimentär, aber ohne Vorteile gegenüber iso8859.

> Wenn es jemand für seine lokale Umgebung als sinnvoll ansieht, Unicode 
> zu benutzen, soll er das doch tun. Mir reicht dafür ISO-8859. Nun gäbe 
> es also nur noch Gründe pro UTF-8 wegen der Kommunikation mit der großen 
> weiten Welt.

...in der Hoffnung, die Welt einigt sich in absehbarer Zukunft darauf.
Den jetzigen Zustand finde ich jedenfalls unbefriedigend.

> Dabei geht es quasi "nur" um Dateinamen und Dateiinhalt. Für den Inhalt 
> ist eher das benutzte Programm zuständig.

Ich meine schon plain Text, wir sind ja hier unixoid. Benutzer anderer
Systeme mögen meinetwegen in dem Glauben leben, für typographische
Anführungszeichen ihr »Uöörd« aufreißen zu müssen. Es ist IMHO generell
nicht die Aufgabe einer Textverarbeitung, die Encoding-Fähigkeiten des
Systems zu erweitern, man erkauft es schließlich mit der Abhängigkeit
von deren Format.

> Bleibt der Name. Ist das Zielsystem fähig, mit dem UTF-8-Namen
> umzugehen, ist alles ok. Aber wenn nicht? Im besten Fall wird dann
> dein Dokument problemlos unter einem anderen Namen abgelegt. Damit ist
> aber der UTF-8-Vorteil dahin. Im schlechteren Fall spielt das
> Zielsystem verrückt. Und das wäre übel. Das möchte ich niemand antun.

Richtig. Nur ist das Problem das gleiche, wenn Du zwischen zwei
Ein-Byte-Codepages wechselst. In D fällt das ohne Euro nicht weiter auf,
weil für alle üblichen Umlaute ms-ansi zufällig iso8859-1 entspricht.
Mit Euro fällt es dann schon auf, und die erste Grenze ist erreicht. Und
wenn das Zielsystem z.B. OS/2 ist (DOS cp850), darfst Du schon
rumbasteln. Wir haben hierzulande nur den Spezialfall der zufälligen
Übereinstimmung von 7 Zeichen zwischen zwei Systemen und ihren
Codepages, an allen anderen Stellen fällt Konvertierung an.

> Ich persönlich arbeite zum Beispiel an einem Firmennotebook mit 
> eigentlich W2k. Da ich Win aber möglichst vermeiden will, habe ich das 
> System mit einer Systempartition NTFS, einer Datenpartition FAT32 und 
> freiem Platz einrichten lassen. Auf dem ursprünglich freien Platz läuft 
> jetzt sarge. Die Datenpartition wird von beiden Systemen lesend und 
> schreiben benutzt. Schon allein diese Konstellation erlaubt mir die 
> Benutzung von UTF-8 nicht, jedenfalls ließen meine erfolglosen Versuche 
> dies vermuten. Ich gestehe aber gern zu, dass ich mich nicht sehr 
> ernsthaft daran versucht habe.

Sollte sich mit Mount-Optionen regeln lassen. Gemeinsame Partitionen
benutze ich nicht, aber mit einem Win2000/XP/2003-Server über cifs
funktioniert utf8 reibungslos.

> Die gesetze locale wird an vielen Stellen ignoriert.

Das sind IMHO heftige Bugs und führt den Sinn einer locale ad absurdum.

> Mal 'ne Frage am Rande: Wie erzeugst du eigentlich die vielen netten 
> Zeichen mit der Tastatur? Über den Hexwert? Hast du ständig eine 
> UTF-8-Zeichentabelle griffbereit?

Über Compose. Ich finde die voreingestellte Compose-Tabelle ziemlich
intuitiv und muß nicht oft nachschlagen.

Grüße,
Andreas
-- 
You have the capacity to learn from mistakes.  You'll learn a lot today.



Reply to: