Zeichenkodierung (was: Re: [linux-l] Plan9-Konzepte)

[Jan-Benedict Glaw]

On Tue, 2006-04-25 09:33:53 +0200, olafBuddenhagen at gmx.net <olafBuddenhagen at gmx.net> wrote:
> On Sun, Apr 23, 2006 at 09:26:40PM +0200, Volker Grabsch wrote:
> > > > Ach ja, und diese Strings sind natürlich alles "Unicode"-Objekte. 
> > > 
> > > Objekte?
> > 
> > Ich weiß nicht, wie man das in C handhabt. Gibt es spezielle strlen(),
> > ... Funktionen für UTF-8 codierte char* ?
> 
> Freilich, moderne libc-Varianten haben all diesen Kram -- einer der
> Gründe, warum sie so riesig groß sind...

strlen() ist gleich für ASCII (und unsere europäischen
Ein-Byte-Kodierungen) und für UTF-8.

Es gibt aber Funktionen, die spezifische Aufgaben übernehmen. In UTF-8
muß man sehr genau unterscheiden zwischen:

  * Speicherverbrauch,
  * Anzahl der Zeichen,
  * Anzahl der zur Anzeige benötigten Spalten.

Speicherverbrauch ist mit strlen() zu messen.

Die Anzahl der Zeichen ist schon etwas komplizierter: UTF-8 kennt
Zeichen, die alleine überhaupt keinen Platz brauchen (z.B. die Akzente
zu Umlauten, wenn es keinen vordefinierten Buchstaben gibt, der diesen
Akzent beinhaltet). Natürlich gibt es auch Zeichen, die zwei Spalten
einnehmen (das betrifft wohl vor allem asiatische und arabische
Zeichen.)

In C wird zudem noch zwischen UTF-8/UTF-16 (wobei meistens UTF-8
benutzt wird, weil ggf. der Portierungsaufwand bestehender
Applikationen kleiner ist) und dem wchar_t unterschieden.

UTF-8 ist einfach eine Folge von Bytes; wie viele Bytes zum nächsten
anzeigbaren Zeichen gehören, das muß man immer erst herausfinden. Der
wchar_t ist so groß dimensioniert, daß immer ein "großes" Zeichen
hineinpaßt.

Zu allem Überfluß gibt es nicht alle Funktionen (Speicherverbrauch,
Anzeigebreite und Zeichenanzahl) für alle Darstellungsformen, sodaß
man mitunter lustig hin- und herkonvertiert (oder sich die Funktionen
alle schreibt und dann intern die Umwandlungen macht.)

> > Wie dem auch sei, in OO-Sprachen wie Python, Java, und etlichen C++
> > Bibliotheken ist es jedenfalls üblich, dass es Unicode-Objekte gibt.
> > Das sind im Prinzip String-Objekte (in Java heißen sie sogar
> > "String"), die aber eben den gesamten Unicode-Zeichensatz
> > unterstützen. An deren interne Darstellung kommt man von außen nicht
> > ran (ist meist UTF-16),
> 
> Meist UTF-16? Wirklich? Kann ich mir kaum vorstellen, dass die wirklich
> alle so hirnverbrannt sind -- UTF-16 ist die denkbar dümmste mögliche
> Kodierung! Es bringt weder den Vorteil einer einheitlichen Zeichenlänge
> (und damit einfachen Verarbeitung), noch effizienten Verarbeitung
> (kleiner Datenmengen) dank Zeichen in nativer int-Größe des Prozessors,
> noch effizienter Speicherung der meisten Daten... Kurzum: Es vereint auf
> bemerkenswerte Weise alle Nachteile von UCS-4 und UTF-8.

Ja, das ist schön gesagt:)  (/me denkt gerade an die nativen Strings
unter Windows...)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20060427/83341fb3/attachment.sig>