Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

On Tue, Mar 18, 2014 at 06:41:39PM +0100, Polytropon wrote:
> On Tue, 18 Mar 2014 17:19:51 +0100 (CET), Oliver Fromme wrote:
> > Polytropon <freebsd(at)edvax.de> wrote:
> > Warum sollte man für deutschsprachige Texte von UTF-8 auf UTF-16
> > umstellen wollen?
>
> Warum sollte man für deutschsprachige Texte von ISO-8859-1 oder -15
> auf UTF-8 umstellen wollen? Weil... wenn man typographische
> Zeichen wie Ellipse, Halbgeviertstrich, Anführungszeichen
> oben und unten oder Ligaturen mit einbacken will, und das
> direkt im Textverarbeitungsprogramm oder Editor, dann
> reicht das nicht aus. Daß etwas nicht ausreicht ist der
> Motor der Weiterentwicklung und Veränderung, daher
> denke ich, daß bis zur Ankunft von UTF-64 noch ein
> paar Jahre bleiben, dann aber... :-)

UTF-16 reicht eh vielfach nicht mehr.
UTF-32 ist Stand der Dinge.
Der vermeindliche Vorteil von UTF-16 gegenüber UTF-8 liegt auf der Hand:
Ein Zeichen hat eine feste Größe.
Der Nachteil:
Es stimmt in Wirklichkeit gar nicht, wegen kombinatorer Zeichen.
Stringverarbeitung ist mit Variablen Zeichen echt ein Drama.
Wie viel Speicher muss ich allokieren, um 10-Zeichen zu speichern?
Einmal durchzählen oder schnell einfach 6*10+1 Bytes für den Worstcase
belegen?
Oder nur 6*10+1, weil man nach RFC3929 auf 0x10ffff begrenzt arbeitet.
Aber das reicht für kombinatorische Zeichen ja auch wieder nicht...
Auf Steuerungssystemen mit wenigen kB-RAM oder NV-Seicher sieht
man sowas gar nicht gerne.
So begrenzt war früher gar mal die Bürohardware.
Wer will kann sich gerne mal Informieren wie viele Bytes auf einem
Magnetstreifen einer Scheckkarte passen...
Oder wie gerne man in der Fertigung 64k Typen für die Hochprägung auf
Kreditkarten sieht.
Bei den Amerikanern darf man nicht vergessen, dass Kartenzahlung bei
denen deutlich populärer ist und die sehr früh massiv im Einsatz war.
Das musste entsprechend auch auf damaliger Hardware sinnvoll zu verarbeiten
sein und dazu gehört auch der Performanceverlust durch variablen
Speicherbedarf.
Datenbanken haben früher gerne mit festen Feldlängen gearbeitet und
nicht nur wegen Formularfelder, sondern auch wegen leichterer Verarbeitung.
Die 3123. Zeile ereicht man halt einfacher mit 3123*Feldgrößen als
einen Index mit zu schleppen, oder gar immer alles abzugrasen.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message