Re: LANG und UTF-8

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Mon, 5 Dec 2005 16:36:53 +0100 (CET)

Rocco Rutte <pdmef(at)cs.tu-berlin.de> wrote:
> * Oliver Fromme [05-12-05 14:06:24 +0100] wrote:
> > Rocco Rutte <pdmef(at)cs.tu-berlin.de> wrote:
> > > * Oliver Fromme [05-12-05 08:55:23 +0100] wrote:
>
> > Wie schaffst Du es, die ganze Software zu vermei-
> > den, die nicht mit Multibyte-Zeichen zurechtkommt?
>
> Ich brauche nur Mail+News+Web, Compiler, Editor und TeX. Und die können es
> alle. Gut, zsh kann es nicht aber dort brauche ich es auch extrem
> selten.

Mir kommen durchaus öfters Dateinamen in die Finger, die
Umlaute oder andere nicht-ASCII-Zeichen enthalten. Damit
müssen alle üblichen Tools zurechtkommen, die man als Admin
so braucht, allen voran natürlich die Shell.

Das Problem ist allerdings noch viel grundlegender, da die
Namen ja im Dateisystem gespeichert werden müssen. Und da
UFS keinen direkten Unicode-Support hat (im Gegensatz zum
NTFS und ISO9660), bleibt einem da nicht viel anderes üb-
rig, als auf ISO8859 auszuweichen. Dasselbe gilt für die
entsprechenden Tools (dump/restore usw.). UTF-8 ist als
Kodierung für ein herkömmliches UFS übrigens ungeeignet, da
es passieren könnte, daß eine Multibyte-Sequenz das Byte
0x2f enthält, was der UFS-Code als Verzeichnistrenner in-
terpretieren würde. Um das Problem zu lösen, müßte man ein
komplett neues Dateisystem entwerfen. Vielleicht ist das
ja etwas für UFS3, irgendwann in ferner Zukunft.

> > Die Problematik, die mit der Umstellung einhergeht, ist na-
> > türlich (leider) nicht ganz vermeidbar. Jetzt sind halt
> > erstmal die Programmierer gefragt, um alle gängigen Pro-
> > gramme Unicode-Fit zu machen.
>
> ACK. Aber meine Kritik ist unter dem Strich, dass man genau diese
> Anpassung, weil sie ohnehin notwendig ist, nutzen könnte, um irgendwann
> den Schalter auf "den" Standard umzulegen.

Solange nicht _alle_ Programme, die ich brauche, damit
klarkommen, werde ich das gewiß nicht tun. Damit würde
ich mir ja nur in den Fuß schießen. Das sehe ich ganz
pragmatisch.

Und es gibt nicht »den« Standard (welchen meinst Du damit
eigentlich genau?). Es gibt eine ganze Reihe von Stan-
dards. Was ich auch nicht unbedingt schlecht finde.

> Jetzt sieht es eher so aus,
> als ob man bei dem Zoo an Kodierungen bleiben will und statt auf einen
> einheitlichen Standard zu migrieren lieber Unicode-Support einbaut.

Warum sollte man trotz Unicode-Support nicht nach wie vor
ISO8859 unterstützen? Das frißt doch kein Brot. 7bit-
ASCII-Support hat man sowieso weiterhin.

> > Es wird natürlich immer eine
> > gewisse Anzahl »Altlasten« geben -- Ich kenne eine Vielzahl
> > Firmen, die eine eingekaufte oder selbstgestrickte Software
> > einsetzen, bei der niemand mehr Anpassungen machen kann
> > oder will -- »Unicode?!? Hör bloß auf, wir sind schon froh,
> > daß das Zeug die Jahrtausendwende überstanden hat.«
>
> Das könnte man bei Neuentwicklungen berücksichtigen.

Was für Neuentwicklungen? Neuentwicklungen sind teuer.
Wenn eine Firma fünf- bis sechstellige Beträge in eine
Spezialanwendung investiert hat, die auf Jahre oder gar
Jahrzehnte hinaus verwenwendet wird (man denke an die
Millionen Zeilen von Fortran und Cobol, die immer noch
in Verwendung sind, aber durchaus auch modernere Dinge),
wird bloß wegen der UTF-8-Unterstützung -- die in der
Firma wahrscheinlich gar niemandem etwas nützt -- ganz
gewiß _keine_ Neuentwicklung finanziert.

> > > dann wäre allen geholfen und man könnte
> > > endlich mal die ganzen Würgarounds abschaffen (die ganze
> > > Spezialbehandlung für Mail zum Beispiel,
>
> > Hmm, was für Spezialbehandlung von Mails meinst Du?
>
> Alle Kodierungsmechanismen.

Das wird alles von MIME abgedeckt; dazu braucht's keine
Spezialbehandlung.

> Ich habe zum Beispiel ein Perlskript als Mailfilter im
> Einsatz, was Subjecttags entfernt; das geht nicht mit sed(1), weil
> kaputte Clients auch ASCII-Worte in das Encoded Word einbauen.

Wie meinst Du das? Habe sowas noch nicht gesehen. Das
einzige kaputte, was ich ab und zu sehe, ist, daß 8bit-
Zeichen unkodiert in Headern landen.

> Hätte man
> nur einen Kodierstandard, müsste man nicht MIME-kodieren und ich könnte
> sed(1) nehmen.

1. Es wird _nie_ einen einzigen Kodierstandard geben. Es
    wird mindestens UTF-7, UTF-8 und UTF-16 geben, viel-
    leicht auch noch mehr. Und das ist gut so. Davon ab-
    gesehen können die dann wiederum mit Base64 und Quoted-
    Printable kombiniert werden. Jedes davon hat Vor- und
    Nachteile, je nach Anwendungsfall.

2. Du willst nicht ernsthaft MIME abschaffen, nehme ich an.

3. Du willst nicht ernsthaft 8-bit-Zeichen uncodiert in
    Mail-Header reintun, nehme ich an. Siehe RFC2822.

4. Wenn Du in einem Programm (egal ob Perl oder sonstwas)
    Emails parsen willst, dann muß Dein Programm auch MIME
    können. Mit sed(1) allein ist es nicht getan. Es gibt
    für alle gängigen Programmiersprachen (natürlich auch
    Perl) entsprechende Module oder Libraries, so daß das
    nicht wirklich schwer ist.

> > Übrigens habe ich keine Probleme damit -- weder technische
> > noch mentale -- wenn jemand UTF-8 in Mails oder Postings
> > verwendet, sofern alles per MIME korrekt deklariert ist.
>
> Sicher. Ich habe ja auch nicht gesagt, dass man es technisch nicht durch
> Standards verkomplizieren und die dann sauber implementieren kann. Es
> kann IMHO aber auch keine Dauerlösung sein.

MIME ist eigentlich nicht unnötig kompliziert, sondern er-
füllt seine Zwecke ziemlich gut. Es ist zudem ein seit
10 Jahren etablierter und weitgehende akzeptierter Stan-
dard. Ihn ersetzen zu wollen halte ich für ziemlich aus-
sichtslos, mal davon abgesehen, daß ich nicht wüßte, wo-
durch man es ersetzen sollte.

> > Allerdings wäre es theoretisch möglich, syscons Multibyte-
> > fähig zu machen und die Zeichen auf einen existierenden
> > ISO8859-Font zu mappen, und auf diese Weise per UTF-8 o.ä.
> > ein Unicode-Subset zu supporten, das mit dem jeweiligen
> > ISO8859-Font übereinstimmt. Aber das ist wieder eine ganz
> > andere Sache.
>
> Darf ich raten, dass die Motivation dafür ziemlich gering ist? Weil es
> eh keiner wirklich haben will?

Da könnte ich auch nur raten da mir keine repräsentativen
Umfragen zu diesem Thema bekannt sind. Ich kann da nur
folgende Indizien oder Mutmaßungen heranziehen:

1. Die meisten Leute arbeiten überwiegend unter X, und nur
    in Notfällen unter syscons (solange X noch nicht in-
    stalliert ist, bzw. um X zu reparieren, wenn's mal
    nicht geht, und zum Editieren der X-Config o.ä. genügt
    ASCII).

2. Falls es Developer gibt, die auch sonst häufig mit
    syscons arbeiten, so scheinen diese Multibyte-Support
    nicht sonderlich zu vermissen, da man sonst annehmen
    müßte, daß es jemand implementiert hätte.

3. Um den syscons-Code kümmern sich zahlreiche Leute,
    deren Muttersprache nicht Englisch ist, zum Beispiel
    Kazutaka Yokota. Es ist also gewiß nicht so, daß da
    nur ASCII-Hardliner dran herumprogrammieren.

4. Unicode-Support (nicht zwangsläufig UTF-8-Support!)
    ist nicht unbedingt trivial zu implementieren, da man
    erstmal eine zusätzliche Abstraktionsschicht program-
    mieren müßte, die Unicode auf die Restriktionen der
    Hardware abbildet. Man könnte da vielleicht den Code,
    der Screenmaps implementiert, als Grundlage nehmen,
    müßte aber noch erheblich ausgebaut werden.

Falls Du Dich berufen fühlst, kannst Du Dir den Code gerne
mal zu Gemüte führen. Zu finden unter src/sys/dev/syscons.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"[...]  one observation we can make here is that Python makes
an excellent pseudocoding language, with the wonderful attribute
that it can actually be executed."  --  Bruce Eckel
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 05 Dec 2005 - 16:40:58 CET

search this site