VisialStudio: MultiByte vs Unicode

rüdiger

Dravere schrieb:

rüdiger schrieb:

UTF-8 ist gut, wenn man den Text möglichst klein haben will oder eben für Legacysysteme :).

Nicht zum Beispiel im asiatischen Raum. Wenn ich mich recht erinnere brauchen gerade chinesische Zeichen in UTF-8 meistens 3 Bytes, während sie in UTF-16 nur 2 Bytes benötigten. Daher wird UTF-16 noch oft im asiatischen Raum eingesetzt.

Aber nur wenn es sich um reinen Text handelt. Das kommt ja mittlerweile eher selten vor. Wenn Steuerzeichen (sind ja idr aus dem ASCII Satz) enthalten sind, dann ist UTF8 auch hier besser. Wenn du mir nicht glauben willst, dann kannst du es ja einfach ausprobieren. Nimm dir ein paar zh/ja-Wikipedia-Seiten und kodier die einmal als UTF8 und einmal als UTF16. UTF8 gewinnt da deutlich.

Für den japanischen UTF-8: UTF-8 vs. UTF-16: 100453 vs. 171166 Bytes. UTF-8 gewinnt mit 41.3% Vorsprung.

Dravere schrieb:

rüdiger schrieb:

UTF-32 ist gut, wenn man sehr viel zeichenweise machen will.

Kannst du auch bei UTF-32 vergessen. Gewisse Zeichen setzen sich aus mehreren UTF-32 Werten zusammen. Man braucht genauso Indextabellen wie in UTF-8 und UTF-16.

Nein. UTF-32 nutzt 32Bit für alle Zeichen. Es gibt keine Indextabelle. (UCS-4 braucht 24Bit für Zeichen).

rüdiger

Jochen Kalmbach schrieb:

UTF-16 ist gut, wenn man WinAPI Funktionen direkt ansprechen will... das geht nun mal mit UTF-8 nicht da Windows dies nicht als Encoding seiner *A-Funkionen nicht unterstützt.
Fazit: Verwende möglichst immer die *W-Funktionen, wenn Du alle Zeichensätze darstellen willst... und damit verwende auch "wchar_t" bzw. "UTF-16".

Wie ich sagte: UTF-16 für Legacysysteme.

Jochen Kalmbach schrieb:

UTF-32 wird in der Praxis nie eingesetzt...

Klar, wenn man Unicode mit einfachem Zeichenzugriff haben will. Bei UTF-8/16 muss man ja immer umständlich schauen wo welches Zeichen ist.

Dravere

rüdiger schrieb:

Aber nur wenn es sich um reinen Text handelt. Das kommt ja mittlerweile eher selten vor.

Wie bitte? Selten? Also ich kenne da einige Anwendungen, wo reiner Text gespeichert wird. Wenn ich nur an all die Datenbanken denke, welche reinen Text abspeichern.

rüdiger schrieb:

Nein. UTF-32 nutzt 32Bit für alle Zeichen. Es gibt keine Indextabelle. (UCS-4 braucht 24Bit für Zeichen).

Bringt nur nichts, wenn man kombinierte Zeichen verwendet. Du kannst zum Beispiel ein A schreiben mit einem zusätzlichen diakritischem Zeichen.

Wir haben sogar einen Unicode Artikel, falls es dich interessiert

Grüssli

Jochen Kalmbach

rüdiger schrieb:

Dravere schrieb:

rüdiger schrieb:

UTF-32 ist gut, wenn man sehr viel zeichenweise machen will.

Kannst du auch bei UTF-32 vergessen. Gewisse Zeichen setzen sich aus mehreren UTF-32 Werten zusammen. Man braucht genauso Indextabellen wie in UTF-8 und UTF-16.

Nein. UTF-32 nutzt 32Bit für alle Zeichen. Es gibt keine Indextabelle. (UCS-4 braucht 24Bit für Zeichen).

Nein. Du solltest Dich mal näher mit Unicode beschäftigen... oder meinen Artikel hier im Forum lesen...

Es gibt einen riesen großen Unterschied zwischen einem *Codepoint* und einem Zeichen (Glyph).
Du redest hier nur von Codepoints... das spielt aber in der *richtigen* Welt keine Rolle... da kommt es nur darauf an, dass Du die Zeichen ricjhtig interpretierst und z.B. bei einer Suche nicht zusammenhängende Codepoints (z.B. via Combining Characters) separat betrachtest...

rüdiger

Stimmt an die Combiningcharacters hab ich gar nicht gedacht. Dann ist UTF-32 also wirklich nicht sehr sinnvoll.

Dravere schrieb:

rüdiger schrieb:

Aber nur wenn es sich um reinen Text handelt. Das kommt ja mittlerweile eher selten vor.

Wie bitte? Selten? Also ich kenne da einige Anwendungen, wo reiner Text gespeichert wird. Wenn ich nur an all die Datenbanken denke, welche reinen Text abspeichern.

Also wenn man eine Anwendung ausschließlich für den chinesischen Markt schreibt und nur reinen chinesischen Text behandelt, dann ist UTF-16 vielleicht doch eine Überlegung wert. Das zähle ich mal als Spezialfall.

Dravere

rüdiger schrieb:

Also wenn man eine Anwendung ausschließlich für den chinesischen Markt schreibt und nur reinen chinesischen Text behandelt, dann ist UTF-16 vielleicht doch eine Überlegung wert. Das zähle ich mal als Spezialfall.

Dann bezeichnest du bereits die chinesische Wirtschaft als Spezialfall. Und es gibt noch einige zusätzliche Länder in der Gegend, welche Software einsetzen, welche ausschliesslich für ihr Gebiet programmiert ist.

Zudem vergisst du wohl, dass Windows auf UTF-16 aufbaut. Wieso ständig immer zwischen Kodierungen hin und her konvertieren, wenn das Programm sowieso auf Windows läuft? Daher kenne ich einige, welche zum Beispiel die Sprachdateien in UTF-16LE halten.

Aber gut, du kannst natürlich einfach eine riesige Gruppe machen und diese "Spezialfall" nennen

Grüssli

SideWinder

Auch wenn hier (C++...) gerne übersehen basiert mit Java (und ich glaube auch .NET) ein großer Teil an Software auf UTF16. Uvm. Ich würde soweit gehen und UTF16 als "die Zukunft" bezeichnen.

MfG SideWinder

rüdiger

Dravere schrieb:

rüdiger schrieb:

Also wenn man eine Anwendung ausschließlich für den chinesischen Markt schreibt und nur reinen chinesischen Text behandelt, dann ist UTF-16 vielleicht doch eine Überlegung wert. Das zähle ich mal als Spezialfall.

Dann bezeichnest du bereits die chinesische Wirtschaft als Spezialfall. Und es gibt noch einige zusätzliche Länder in der Gegend, welche Software einsetzen, welche ausschliesslich für ihr Gebiet programmiert ist.

Für eine asiatische Softwarefirma ist es sicher kein Spezialfall. Aber die meisten Leute hier im Forum schreiben Software sicher nicht speziell für den asiatischen Markt. Vielleicht angepasste Versionen von internationaler Software.

Dravere schrieb:

Zudem vergisst du wohl, dass Windows auf UTF-16 aufbaut. Wieso ständig immer zwischen Kodierungen hin und her konvertieren, wenn das Programm sowieso auf Windows läuft? Daher kenne ich einige, welche zum Beispiel die Sprachdateien in UTF-16LE halten.

Für Windows gilt die Ausnahme mit dem Legacysystem. Natürlich macht es kein Sinn UTF-8 zu nehmen, wenn man eine Windowsapplikation schreibt.

Aber welches Encoding würdest du nehmen, wenn du ein komplett neues System entwerfen würdest? UTF-16 weil es bei Software die fast nur asiatische Zeichen speichert einen kleinen Speicherplatzvorteil bietet aber in allen anderen Fällen (zB asiatische Schrift mit englischen Kontrollanweisungen) deutlich mehr Platz verbraucht?

SideWinder schrieb:

Auch wenn hier (C++...) gerne übersehen basiert mit Java (und ich glaube auch .NET) ein großer Teil an Software auf UTF16. Uvm. Ich würde soweit gehen und UTF16 als "die Zukunft" bezeichnen.

Auch hier gilt die Ausnahme mit dem Legacysystem. Ich denke aber nicht das UTF-16 "die Zukunft" ist.

Zumindest im Web sind fast 50% der Seiten UTF-8. Nimmt man ASCII dazu (was ja im Prinzip eine Untermenge von UTF-8 ist), dann ist man fast bei 70%. Zumindest wenn man Google glaubt: http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html

(und hey die meisten "UTF-16"-Anwendungen können eh nicht wirklich mit Zeichen außerhalb des BMP umgehen)

Dravere

@rüdiger,
Du solltest vielleicht deine Begrifflichkeit überdenken. Du bezeichnest UTF-8 und UTF-32 als, ich zitiere, "die einzig sinnvollen Unicodevarianten". Damit sagst du also UTF-16 wäre nicht sinnvoll. Ohne überhaupt einen Grund zu nennen.

Und nun setzt du alles, was UTF-16 verwendet in eine Spezialfall Gruppe. Und wenn Windows oder Java ins Spiel kommt, dann nennst du dies ein altes System. Eine ziemlich willkürliche und unbegründete Einsortierung, welche auch nicht gerade dem Einsatz auf dem Markt entspricht.

Es gibt eine Menge Gründe, wieso UTF-16 genauso sinnvoll ist wie UTF-8 oder UTF-32. Deine Begrifflichkeit war/ist einfach falsch.
Alle drei UTF Varianten haben ihre sinnvollen Einsatzgebiete. Im Internet verwende ich auch oft UTF-8, einfach weil UTF-8 nicht abhängig von BE oder LE ist und man im Internet alle möglichen Systeme trifft. UTF-16 verwende ich meistens auf Windows für die I18n. UTF-32 kann praktisch zur Laufzeit sein, weil man gleich die Unicode-Codepoints hat und diese nicht noch dekodieren muss. Die UTF-Varianten haben einfach unterschiedliche Einsatzgebiete.

Ein neues System ausschliesslich für Windows würde ich mit UTF-16 entwickeln. Nicht wegen des Speicherplatzvorteils, dieser ist mit heutigen HDs sowieso eher nebensächlich, sondern einfach weil Windows am besten mit UTF-16 arbeitet. Ich habe dich wegen des Speicherplatzes nur korrigiert, weil du gesagt hast, dass man UTF-8 einsetzen soll, wenn man den Text klein halten möchte. Diese Aussage ist, so pauschal formuliert, aber falsch.

Grüssli

rüdiger

@Dravere
Java und Windows wurden eben für UCS-2 entworfen. Mittlerweile gibt es UCS-4 und 16Bit sind nicht mehr genug. Also nimmt man UTF-16 für diese Systeme, damit man mit ihnen UCS-4 unterstützen kann. Das meine ich mit "legacy Systeme". Niemand würde heute ein komplett neues System entwerfen und dafür UTF-16 nehmen, weil UTF-16 in den meisten Fällen (reiner asiatischer Text ausgenommen) eben deutlich mehr Speicher verbraucht, als zB UTF-8 und man im Vergleich zu UTF-32 keine einfache Zuordnung zu den Codepoints hat. Wenn man also ein komplett neues System entwerfen würde, dann würde man dafür sicher kein UTF-16 nehmen.

Mit der Ausnahme des Spezialfalls, dass man ein System fast ausschließlich Text in asiatischen Zeichen hat (also ohne irgendwelche "lateinischen" Kontrollanweisungen etc. dazwischen).

Und mit System meine ich keine Windowsanwendung. In dem Fall wäre ja Windows das System und Windows benutzt UTF-16LE. Also nimmt man in dem Fall einfach UTF-16LE. UTF-7 ist zB auch sehr sinnvoll für Emails und UTF-EBCDIC für alte IBM Großrechner.

Unicode im Web ist ja eine relativ neue Sache und da nimmt man eben UTF-8. Nicht nur weil es keine Unterscheidung zwischen LE und BE braucht. Sondern vorallem weil es sehr platzsparend ist. Selbst bei Webseiten mit asiatischem Text spart man locker 40% gegenüber UTF-16.

UTF-16 kombiniert den Nachteil von UTF-8 (keine feste Zuordnung der Codepoints) mit den Nachteilen von UTF-32 (viel Speicherverbraucht).

Dravere

rüdiger schrieb:

Wenn man also ein komplett neues System entwerfen würde, dann würde man dafür sicher kein UTF-16 nehmen.

Und deiner Meinung nach was dann? Aber bitte mit genauer Begründung.

rüdiger schrieb:

Unicode im Web ist ja eine relativ neue Sache und da nimmt man eben UTF-8. Nicht nur weil es keine Unterscheidung zwischen LE und BE braucht. Sondern vorallem weil es sehr platzsparend ist. Selbst bei Webseiten mit asiatischem Text spart man locker 40% gegenüber UTF-16.

Also in erster Linie nimmt man im Web UTF-8, weil das Web ein Legacy System ist, welches früher auf ASCII aufgebaut hat (oder noch tut). Und der zweite Grund wäre das Problem mit LE und BE, weil man im Web beides antrifft. Der Platz käme erst an 3. Stelle und habe ich persönlich noch kaum als Begründung aufgeführt gesehen.
Das ist im übrigen sowieso einer der Hauptgründe, wieso UTF-8 so weit verbreitet ist, da jedes System/Bibliothek/Program/usw., welches ASCII verarbeiten konnte, auch UTF-8 durchreichen kann. strlen aus C kann man auch auf UTF-8 anwenden, während dies bei UTF-16 und UTF-32 ziemlich problematisch wird. UTF-8 ist so wahnsinnig verbreitet wegen den Legacy Systemen. Da finde ich es schon sehr verwunderlich, dass du UTF-8 nicht in diese Gruppe nimmst.

rüdiger schrieb:

UTF-16 kombiniert den Nachteil von UTF-8 (keine feste Zuordnung der Codepoints) mit den Nachteilen von UTF-32 (viel Speicherverbraucht).

Man könnte es auch anders sehen. UTF-16 ist einfacher zu dekodieren, da die üblichen Zeichen sogar mit den asiatischen, immer in 2 Bytes platz haben. Meistens muss also nichts gross dekodiert werden. Allerdings verbraucht man dabei auch nicht gleich so viel Speicherplatz wie bei UTF-32.

Im übrigen finde ich noch witzig, dass du von einem neuen Betriebsystem redest. Wir reden aber von aktuellen Anwendungen und sogar in diesem Thread von Windows. Und wenn du in diesem Kontext UTF-16 als nicht sinnvoll bezeichnest, da habe ich schon so meine Mühe mit. Und gerade dieser riesen Windows- und Java-Markt empfinde ich irgendwie nicht als "Sonderfall".

Grüssli