Unicode

Artchi

Schau mal, wer alles NICHT UTF-8 benutzt:

Java-Runtime (UTF-16), Mac OS X (UTF-32), Windows NT (UTF-16) und die .NET Runtime auch nicht.

So grob mal gefragt: ist das negativ aufgefallen, das die gängigen Systeme UTF-16 oder UTF-32 nutzen? Nö.

Was ist der Vorteil? Performance! Feste Bit-Breiten sind einfach schneller zu verarbeiten. Pro 16 bzw. 32 Bit ein Zeichen.

Bei UTF-8 hast du variable Breiten, und dann muss bei jedem Zeichen der Code überprüft werden. Außerdem hat UTF-8 je nach Zeichencode mehr Speicherverbrauch als die anderen UTFs.

UTF-8 hat meines Wissens nur einen Vorteil: wenn es sich nur um ASCII-Zeichen handelt, hat man weniger Speicherverbauch als UTF-16/32. Aber sobald z.B. Umlaute, oder gar arabisch oder chinesisch dazu kommt, ist der Vorteil dahin.

Nathan

Artchi schrieb:

Schau mal, wer alles NICHT UTF-8 benutzt:

Java-Runtime (UTF-16), Mac OS X (UTF-32), Windows NT (UTF-16) und die .NET Runtime auch nicht.

DAS Argument.

So grob mal gefragt: ist das negativ aufgefallen, das die gängigen Systeme UTF-16 oder UTF-32 nutzen? Nö.

Ja.

Was ist der Vorteil? Performance! Feste Bit-Breiten sind einfach schneller zu verarbeiten. Pro 16 bzw. 32 Bit ein Zeichen.

UTF-16 hat auch nicht feste Bitbreiten.

Bei UTF-8 hast du variable Breiten, und dann muss bei jedem Zeichen der Code überprüft werden. Außerdem hat UTF-8 je nach Zeichencode mehr Speicherverbrauch als die anderen UTFs.

Ähm, nein?

Artchi schrieb:

Was ist der Vorteil?

Gute Frage, darauf habe ich keine gute Antwort.

Performance!

lol

Feste Bit-Breiten sind einfach schneller zu verarbeiten. Pro 16 bzw. 32 Bit ein Zeichen.

Was verstehst du unter Zeichen? Einen Codepoint?

Bei UTF-8 hast du variable Breiten, und dann muss bei jedem Zeichen der Code überprüft werden.

lol

Außerdem hat UTF-8 je nach Zeichencode mehr Speicherverbrauch als die anderen UTFs.

Öhm...

UTF-8 hat meines Wissens nur einen Vorteil: wenn es sich nur um ASCII-Zeichen handelt, hat man weniger Speicherverbauch als UTF-16/32. Aber sobald z.B. Umlaute, oder gar arabisch oder chinesisch dazu kommt, ist der Vorteil dahin.

lol

otze

keinjavafanboy schrieb:

Feste Bit-Breiten sind einfach schneller zu verarbeiten. Pro 16 bzw. 32 Bit ein Zeichen.

Was verstehst du unter Zeichen? Einen Codepoint?

Das ist der springende Punkt. Die Anzahl von Unicode-Entitäten sagt nicht viel darüber aus, was dargestellt wird. Zum Einen ist nicht eine 32-Bit entität mit einem Zeichen gleichzusetzen(Chinesisch und Arabisch) es gibt auch Steuerzeichen (Textrichtung).

Es macht in der Praxis keinen Unterschied, welches Encoding man verwendet. Sobald man davon ausgeht, dass im String was komplexeres ist als lateinische Buchstaben, dann hat die Textlänge keine Bedeutung mehr.

volkard

otze schrieb:

Sobald man davon ausgeht, dass im String was komplexeres ist als lateinische Buchstaben, dann hat die Textlänge keine Bedeutung mehr.

Mist. Eigentlich müßte ich Dich verfluchen dafür, daß Du das gesagt hast.
Andererseits auch nicht, es macht mir das Leben doch viel leichter.

otze schrieb:

Es macht in der Praxis keinen Unterschied, welches Encoding man verwendet. Sobald man davon ausgeht, dass im String was komplexeres ist als lateinische Buchstaben, dann hat die Textlänge keine Bedeutung mehr.

Keine Bedeutung für was?

Raven280438

Hi,

wie gesagt:

Im Internet finde ich nur wiedersprüchliche Informationen. Die Einen sagen, unbedingt UTF8 (std::string) benutzen, die Anderen sagen, std::wstring benutzen.

theta

http://www.utf8everywhere.org/

Caligulaminus

Satzproblem schrieb:

Keine Bedeutung für was?

Die Anzahl Code-Units(8Bit/UTF-8, 16Bit/UTF-16, 32Bit/UTF-32) muß nicht gleich der Anzahl Buchstaben sein.

äaä

Vier Code-Units aber nur drei Buchstaben.
Mein Firefox stellt's übrigens falsch dar, Chrome macht's richtig. Auch daran kann man sehen, daß die Sache nicht ganz trivial ist.
Die beiden Varianten des 'ä' sollen übrigens gleich behandelt werden z.B. in der Sortierung. Wer soll das mit beliebigen Zeichen beherrschen?
Ich denke, daß Unicode an einigen Stellen einfach kaputt ist.

asc

Artchi schrieb:

Schau mal, wer alles NICHT UTF-8 benutzt:

Java-Runtime (UTF-16), Mac OS X (UTF-32), Windows NT (UTF-16) und die .NET Runtime auch nicht.

Nach meiner Kenntnis nutzen Windows, Java und .Net nicht UTF-16 sondern UCS-2 (Entspricht im wesentlichen UTF-16, aber begrenzt auf Unicode 3.0 und damit fixen Bytelängen von 2 Byte).

Caligulaminus

Nein, sie benutzen UTF-16. (Ich glaube, Windows hat bis inklusive NT UCS-2 verwendet)

Raven280438

Hi,

ich tendiere dazu, UTF8 zu benutzen (da die Schnittstellen das beherrschen).

Allerdings hab ich trotz Googeln immernoch keine Lösung für mein Problem gefunden:

Für meine Font-Engine benötige ich zB die Anzahl an Zeichen eines Strings, sowie die Charcode der einzelnen Zeichen als Decimal.

Gruß

otze

benutze doch ein vorgefertigte engine die utf kann. Das wonach du fragst ist nicht trivial, wie man an dem Beispiel von Caligulaminus sieht.

Satzproblem schrieb:

otze schrieb:

Es macht in der Praxis keinen Unterschied, welches Encoding man verwendet. Sobald man davon ausgeht, dass im String was komplexeres ist als lateinische Buchstaben, dann hat die Textlänge keine Bedeutung mehr.

Keine Bedeutung für was?

Caligulaminus schrieb:

Satzproblem schrieb:

Keine Bedeutung für was?

Die Anzahl Code-Units(8Bit/UTF-8, 16Bit/UTF-16, 32Bit/UTF-32) muß nicht gleich der Anzahl Buchstaben sein.

Das sagt doch nicht der Satz aus. Wie sollte der Satz dann lauten?

"Sobald man davon ausgeht, dass im String was komplexeres ist als lateinische Buchstaben, dann hat die Textlänge keine Bedeutung für die Anzahl Code-Units mehr." ? Das würde ja nicht stimmen, die Anzahl Code-Units ändert sich so gut wie immer, wenn sich die Textlänge ändert.

Caligulaminus

Raven280438 schrieb:

Für meine Font-Engine benötige ich zB die Anzahl an Zeichen eines Strings, sowie die Charcode der einzelnen Zeichen als Decimal.

for(char c : utf8string)
{
    if(!(c & 0x80) || (c & 0xC0) == 0xC0)
        ++counter;
}

^Ungetestet.

Zählt die code points (siehe meinen vorletzten Post).
Dafür gibt's bestimmt was fertiges, ich weiß aber grad' nix.

Was die Codes angeht mußt Du entweder von Hand dekodieren oder eine von den UTF-8 zu UTF-32 Konvertierungsfunktionen (->google) benutzen. In UTF-32 steht dann in jedem 32-Bit-Wort ein Unicode code point.

~Edit: Code korrigiert, unit->point~

Raven280438

Hi,

soweit kein Problem.

In UTF-32 steht dann in jedem 32-Bit-Wort ein Unicode code point.

d.h. 4 Byte = 1 Codepoint?

Aus den 4 Bytes kann ich dann einfach nen Integer machen?

Gruß

dot

Raven280438 schrieb:

In UTF-32 steht dann in jedem 32-Bit-Wort ein Unicode code point.

d.h. 4 Byte = 1 Codepoint?

Zumindest im Moment: ja

Raven280438 schrieb:

Aus den 4 Bytes kann ich dann einfach nen Integer machen?

Musst natürlich auf die Endianess aufpassen, aber rein prinzipiell: ja

Die Frage ist: Was hilft dir der Codepoint?

Schwarzefee

Hi,

wird bei einem Font (in meinem Fall erstellt mit BMFont) eine Glyphe nicht über den Codepoint identifiziert?

Gruß

dot

Schwarzefee schrieb:

wird bei einem Font (in meinem Fall erstellt mit BMFont) eine Glyphe nicht über den Codepoint identifiziert?

Im Allgemeinen nicht, zumindest nicht im Kontext von Unicode; da muss man unterscheiden zwischen Code Units, Code Points, abstract Characters, Grapheme Clusters usw. das ist alles nicht so einfach, wie man vielleicht meinen würde. Zusammenfassung: UTF-32 bringt vielleicht eine 1:1 Entsprechung von Code Units zu Code Points (und selbst da wäre ich vorsichtig; früher dachte man auch mal, 7 Bit wären genug; dann dachte man, 8 Bit wären genug; dann dachte man, 16 Bit wären genug...), aber selbst das erlaubt keine fixed-width Behandlung eines String auf Ebene der Einheiten, die ein Mensch als "Zeichen" wahrnehmen würde. Es ist insofern also völlig egal, welches Encoding man jetzt verwendet, denn "Zeichen" haben am Ende nirgendwo fixe Länge...auch nicht in UTF-32...

one code point of view will never reveal the entire grapheme.