Versteht hier jemand Unicode?

[Matze]

Zitat von himitsu:

Außerdem ist UTF-8 doch recht einfach?

Das hat Michael längst verstanden, wie den vergangenen Beiträgen zu entnehmen ist.

Aber du bist doch Unicode-Experte. Erkläre mal, wie UTF-16 funktioniert.

[himitsu]

Wenn du diese blöden Surrogate-Pairs ignorierst, dann ist UTF-16 quasi uncodiert und man kann die Werte der Words/Chars direkt verwenden.

[Assarbad]

Zitat von himitsu:

Wenn du diese blöden Surrogate-Pairs ignorierst, dann ist UTF-16 quasi uncodiert und man kann die Werte der Words/Chars direkt verwenden.

Aber genau das kann man nicht mehr machen, seitdem Unicode mehr als 64k Zeichen enthält. Was du meinst ist UCS-2 (wie es von NT anfangs unterstützt wurde).

Aber stimmt schon. In den meisten Fällen mit denen wir es zu tun bekommen werden, wird die in UCS-2 getroffene Annahme 16bit == 1 Kodepunkt schon stimmen.

Ansonsten gibt es ein feines Buch von O'Reilly zum Thema. Kann es empfehlen.

[himitsu]

Es kommt drauf an, wenn man eh nicht viel macht und die SurrogatePairs wie "normale" Zeichen behandelt und sie nicht anfaßt/verändert, dann kann doch eigentlich nichts passieren.
Selbst Pos würde es nicht interessieren, solange man da nur nach Nicht-SurrogatePairs sucht, oder zumindestens nur komplette Surrogate-Paare sucht.

[Luckie]

Und genau da hakt es. Bei diesen Zeichen, die nicht im BPM oder wie das heißt drin sind, Außerdem habe ich noch Verständnisprobleme was das BPM ist.

[p80286]

Ich hab mich vor elend langer Zeit mal damit beschäftigt als die Norm noch ganz neu war.
Damals war es vereinfacht so, daß die ersten 8Bit den "Zeichensatz" angeben und die zweiten das eigentliche Zeichen identifizieren.
Das war ungefähr so aufgebaut, daß man als Basis das Standard ASCII hatte, und z.b. für die europ. Sonderzeichen eine eigene Tabelle dazu kam.
Da IBM und M$ es vorzogen die 256 Bytes zu vergewaltigen, hab ich damals die Beschäftigung damit wieder aufgegeben. In der Praxis gab es wohl auch zu viele Ungereimtheiten mit der Umsetzung von z.B. Minus, Gedankenstrich und Bindestrich.

Gruß
K-H

[himitsu]

Jupp, die 16-Bit des UTF-16 wurden in mehrere Bereiche aufgeteilt.

Wobei die Basic Multilingual Plane (also die kodierten Werte von $0000 bis $FFFF) entsprechend aufgeteilt wurden.
Jeder Bereich enthält nur/vorwiegend bestimmte Zeichen (z.B. jeweils einer der vielen Sprachen).
500px-Roadmap_to_Unicode_BMP_de.svg.png
Du kannst dir praktisch diese Grafik als das obere Byte ($xx00) vorstellen, wobei jedes Quadrat ein High-Byte darstellt.
(mehrfarbige Teilkästchen sind nochmals unterteilt)

Wenn man dieses jetzt zeichenweise interpretieren will, dann sind nur die zwei Surrogate-Bereiche wichtig, da davon jeweils ein High-Surrogate und ein Low-Surrogate zusammen ein Zeichen darstellen, welche im Bereich $00010000 bis $0010FFFF darstellen, die ja in die 16 Bit nicht reinpassen würden.
Außerdem wären die privaten Zeichen noch wichtig, also wo der Programmierer quasi selbst festlegen kann, was sie darstellen/enthalten sollen.

Aber wie gesagt, es kommt selten vor, daß diese Zeichen überhaupt mal vorkommen und meißtens ist es nicht schlimm, wenn man dieses Zusammengehören ignoriert und die beiden Surrogates jeweils als ein eigenes UCS2-Zeichen ansieht.



Einzig die Tatsache, daß UTF-32, UTF-16 und UTF-8 zwar alle gültigen Unicodezeichen darstellen können, aber leider intern nicht eine einheitliche Formatierung/Datenstruktur verwenden, finde ich für verwirrend.


UTF-32 ist also über den kompletten bereich direkt adressierbar.
- Datenwert $00000000..$0010FFFF = Zeichenwert
- unpraktisch ist, daß immer 4 Byte pro Zeichen belegt sind und davon auch maximal 0,0259% des gesamten möglichen Wertebereichs genutzt werden (drum nutzt es auch aum einer ... PS: den UCS4String kennt Delphi schon seit vielen Jahren, aber dieser ist leider nicht zuweisungskompatibel zu den anderen Strings )

UTF-16 ist großteils auch direkt adressierbar und der Rest ist in den Surrogates kodiert
- Datenwert $0000..$FFFF = Zeichenwert $0000..$FFFF
- die Surrogates = Zeichenwert $000010000..$0010FFFF

UTF-8 ist auch bekannt
- Datenwert $00..$7F = Zeichenwert $00..$7F
- Datenwerte $80..FF °1 = $000000080..$0010FFFF
°1 Bitweise auf ausreichend viele Bytes verteilt

[Assarbad]

Zitat von himitsu:

UTF-32 ist also über den kompletten bereich direkt adressierbar.
- Datenwert $00000000..$0010FFFF = Zeichenwert
- unpraktisch ist, daß immer 4 Byte pro Zeichen belegt sind und davon auch maximal 0,0259% des gesamten möglichen Wertebereichs genutzt werden (drum nutzt es auch aum einer ... PS: den UCS4String kennt Delphi schon seit vielen Jahren, aber dieser ist leider nicht zuweisungskompatibel zu den anderen Strings )

Dein Browser kann kein Javascript?

Der ECMAScript-Standard auf dem Javascript aufbaut benutzt meines Wissens nach intern UTF-32.

Zitat von himitsu:

UTF-8 ist auch bekannt
- Datenwert $00..$7F = Zeichenwert $00..$7F
- Datenwerte $80..FF °1 = $000000080..$0010FFFF
°1 Bitweise auf ausreichend viele Bytes verteilt

Die einfachste Kodierung überhaupt, da auf die Reihenfolge der Bytes nicht geachtet werden muß. Das macht man sich vielleicht sonst nicht so klar, aber das ist ein riesiger Vorteil.

[Luckie]

Also, ich habe innerhalb des 16-Bit Bereichs, dem BMP, wo die Zeichen mit 16-Bit kodiert sind einen Bereich, der reserviert ist. Innerhalb dieses Bereiches werden die Zeichen mit zwei mal 16-Bit kodiert. Wobei bei diesen beiden 16-Bit die oberen sechs Bits zur Kennzeichnung dienen, dass es sich um Zeichen in diesen Reservierten Bereich handelt.

Stimmt die Erklärung des Prinzips soweit? Wie die die Kodierung im Einzelnen zu Stande kommt, ist erst mal nicht so wichtig. Ich will nur wissen, ob ich das Prinzip verstanden habe.

[Luckie]

Also im BMP Bereich sind alle zeichen kodiert, die am gebräuchlichsten sind. Dieser Bereich liegt in den 16 Bit. Dann gibt es noch den zweiten Bereich der mit zwei mal 16-Bit kodiert ist. Ist das soweit richtig? OK, nehmen wir mal an, ich hätte es richtig verstanden. Womit ich jetzt Probleme habe ist der Absatz, wo das mit den zwei mal 16-Bit erklärt wird:

Zitat:

Unicode-Zeichen außerhalb der BMP (d. h. U+10000 bis U+10FFFF) werden durch zwei 16-Bit-Wörter (engl. code units) dargestellt, die wie folgt gebildet werden:

Von der Nummer des Zeichens wird zunächst die Zahl 65536 (10000hex) abgezogen, wodurch eine 20-Bit-Zahl im Bereich von 00000hex bis FFFFFhex entsteht, die anschließend in zwei Blöcke zu je 10 Bit aufgeteilt und dem ersten Block die Bitfolge 110110, dem zweiten Block dagegen die Bitfolge 110111 vorangestellt wird. Das erste der beiden so entstandenen 16-Bit-Wörter bezeichnet man als High-Surrogate, das zweite als Low-Surrogate, und ihren Namen entsprechend enthält das High-Surrogate die 10 höherwertigen, das Low-Surrogate die 10 niederwertigen Bits des um 65536 verringerten ursprünglichen Zeichencodes. Der Codebereich von U+D800 bis U+DBFF (High-Surrogates) und der Bereich von U+DC00 bis U+DFFF (Low-Surrogates) ist speziell für solche UTF-16-Ersatzzeichen reserviert und enthält daher keine eigenständigen Zeichen.

Kann mir das noch mal jemand bitte erklären? Ich verstehe da nur Bahnhof.