Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

From: Polytropon <freebsd(at)edvax.de>
Date: Thu, 20 Mar 2014 21:48:20 +0100

On Thu, 20 Mar 2014 20:28:15 +0100, Bernd Walter wrote:
> UTF-16 reicht eh vielfach nicht mehr.

Unterscheidet man hier nicht auch noch Little und Big Endian,
so daß es da "zwei Versionen" gibt?

> Der vermeindliche Vorteil von UTF-16 gegenüber UTF-8 liegt auf der Hand:
> Ein Zeichen hat eine feste Größe.

Das ist ja auch gegenüber ISO-8859-1 und -15 so zu sehen.

> Stringverarbeitung ist mit Variablen Zeichen echt ein Drama.

Plus die Möglichkeit der Falschnegativen durch Fehlinterpre-
tation, wenn mehrere Zeichen ligatuiert bzw. kombiniert
werden...

'E' 'i' 'n' 'fl' 'u' 'g' '...' != 'E' 'i' 'n' 'f' 'l' 'u' 'g' '.' '.' '.'

Sogar ob strlen() hier gleich oder unterschiedlich sein
soll, wäre hier debattierbar.

> 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?

Um derartige "low level"-Fragen macht sich sicher niemand
so richtig Gedanken, da es ja bereits Frameworks gibt, die
einem die Arbeit abnehmen und "mit Sicherheit" genug Platz
im Speicher selbsttätig verwalten. :-)

> So begrenzt war früher gar mal die Bürohardware.

Und damit hat man auch schon seitenlange Reports, Personal-
datenbanken, Kundenaufträge, Stunden- und Raumplanung oder
Geschäftskorrespondenz gemacht, teils von höherer formaler
Qualität als mit heutigen Mitteln... ;-)

> Wer will kann sich gerne mal Informieren wie viele Bytes auf einem
> Magnetstreifen einer Scheckkarte passen...

Ohne nachgeschaut zu haben, aber im Hinterkopf klappert
bei mir die Zahl 130 Zeichen, kann das sein? Also auf
allen drei Spuren zusammen, oder 3 * 130 Zeichen je?
Viel (im Sinne von 640 kB) war's jedenfalls nicht.

> [...] Performanceverlust durch variablen
> Speicherbedarf.

Interessante (und durchaus valide) Betrachtungsweise.

> 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.

Ja, derartige Formate waren früher den begrenzten
technischen Gegebenheiten geschuldet. Aber auch in
Datenbanksoftware wie dBase oder Clipper hat sich
das noch im beginnenden PC-Zeitalter gehalten, mit
so Überbleibseln wie "rechts auffüllen mit Leerzeichen".
Selbst heute ist diese Art der Datenhaltung im
Großrechnerumfeld noch vorzufinden. Und wer mal
mit RPG - sei's auf Großrechner oder AS/400 -
hantieren mußte, kann das Leiden sicher nachvollziehen. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 20 Mar 2014 - 21:49:03 CET

search this site