CreateDirUTF8 funktioniert nicht mit "ä"...[gelöst]

[mschnell]

16 Bit Strings erleichtern das Arbeiten nur, wenn man von vorne herein weiß, dass alles was man im Programm verarbeitet BMP ist. Ansonsten hilft es natürlich überhaupt nicht.

Microsoft hat in Windows NT von Anfang an mit UCS-2 gearbeitet. Das ist UTF-16 ohne die Unterstützung für Surrogate Pairs und kann daher nur die BMP darstellen. Seit Windows 2000 wurde dann die UTF-16 Unterstützung ausgebaut. Seit Windows XP ist das dann auch kein Thema mehr, Windows auf Chinesisch zu lokalisieren.

Das ist klar. Was ich meinte, ist dass die Pascal-Programmierung (unabhängig vom OS) durch 16 Bit Strings gegenüber UTF-8 nur bei ausschließlicher Verwendung von BMP vereinfacht wird. Wenn auch 16 bit nicht mehr ausreicht (oder Surrogate Pairs verwendet werden, obwohl es in der Anwendung nicht absolut nötig ist), haben wir natürlich wieder dieselben Schwierigkeiten wie mit UTF-8.

-Michael

[Patito]

Dann noch mal zum Speicher: Ein UTF-16 String benötigt nur dann doppelt so viel Speicher, wie ein UTF-8 String, wenn er nur ASCII Zeichen (das heißt, Zeichen mit einem Codepoint kleiner gleich 127) enthält. Das kommt allenfalls in englischsprachigen Dateien vor. Englisch wird zwar häufig verwendet, ist aber (wie keine Sprache) der Weisheit letzter Schluss.

Der Anteil von ASCII an allen möglichen Strings, die in der Praxis vorkommen, ist aber verdammt hoch. Ich denke nicht, dass Du da ein sinnvolles Argument gefunden hast.

Dann noch mal zur Verarbeitung: Wenn du einen Hash-Algorithmus verwendest, der Byte-Weise arbeitet, benötigt dieser doppelt so viel Zeit, wenn doppelt so viel Speicher (siehe oben) gehasht werden soll. Dies ist jedoch ein spezieller Anwendungsfall. Es spricht nichts dagegen, verschiedene Texte unterschiedlich zu behandeln. Wenn eine Anwendung in verschiedene Sprachregionen eingesetzt werden soll, könnte sie sich je nach Region für einen anderen Hash-Algorithmus entscheiden.
Ob du nun 1 Byte oder 4 Byte in ein Prozessorregister lädst ist bei einer Speicheranbindung von 4 Byte Breite egal. Beide Operationen benötigen gleich viel Zeit.

Stell Dir vor Du hast 2 Dateien mit 20kB und 40kB. Man kann natürlich für eine Datei einen schlechteren Algorithmus nehmen, nur damit dann beide gleich schnell sind, aber so sonderlich sinnvoll ist das doch nicht?!

[Socke]

Der Anteil von ASCII an allen möglichen Strings, die in der Praxis vorkommen, ist aber verdammt hoch. Ich denke nicht, dass Du da ein sinnvolles Argument gefunden hast.

Warst du schon einmal im Asiatischen Sprachraum? Die CJK-Sprachen werden größtenteils nicht in ASCII geschrieben.

Stell Dir vor Du hast 2 Dateien mit 20kB und 40kB. Man kann natürlich für eine Datei einen schlechteren Algorithmus nehmen, nur damit dann beide gleich schnell sind, aber so sonderlich sinnvoll ist das doch nicht?!

Da hast du Recht. Daher wähle ich für beide Dateien den optimalen Algorithmus, damit sie optimal verarbeitet werden.

[Patito]

Warst du schon einmal im Asiatischen Sprachraum? Die CJK-Sprachen werden größtenteils nicht in ASCII geschrieben.

Also zum chatten mit Chinesen habe ich bisher immer Pinyin verwendet -> alles ASCII.

Übrigens existiert für Chinesisch da echt kein Speicher-Optimierungsbedarf. Ein oder zwei Zeichen kodieren dort schon ganze Wörter - für die man in Deutsch oder Englisch schon mal locker 10 Zeichen braucht.

Ich bleibe dabei: Optimierung der EDV Richtung Hieroglyphen-Sprachen ist nicht sonderlich sinnvoll... ASCII ist deutlich wichtiger als alles andere...