Versteht hier jemand Unicode?

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

[BUG]

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

Mit je zwei "Zeichen" aus diesem Bereich werden die Zeichen kodiert, die sonst nicht in die 16 Bit passen würden (also nicht in der BMP liegen). Ich nehme an, das meinst du?

Zitat von Luckie:

Stimmt die Erklärung des Prinzips soweit?

Sieht fast so aus

[Luckie]

Zitat von BUG:

Mit je zwei "Zeichen" aus diesem Bereich werden die Zeichen kodiert, die sonst nicht in die 16 Bit passen würden (also nicht in der BMP liegen). Ich nehme an, das meinst du?

Nein, aber jetzt verstehe ich auch das Beispiel mit abc und axyc. b liegt nicht in der BMP, deswegen wird es mit x und y als Ersatz kodiert. Und x und y liegen in diesem reservierten Bereich - oder?

[BUG]

Ja.

x wäre dann das High-Surrogate und y das Low-Surrogate.

[Luckie]

Ich habe es jetzt so formuliert:

Zitat:

UTF-16 ist von den drei Unicode Kodierungen die komplizierteste. Bei UTF-16 kann man zwei Bereiche unterscheiden. Der erste Bereich ist der 16-Bit Bereich, in dem die Zeichen direkt kodiert sind. Dieser beinhaltet die am häufigsten genutzen Zeichen. Innerhalb dieses Bereiches gibt es einen zweiten, reservierten Bereich. In diesem reservierten Bereich werden einzelne Zeichen mit mit zwei mal 16-Bit, also zwei Ersatzzeichen definiert. Nehmen wir die Zeichenfolge abc, wobei bei b nicht im direkt kodierten 16-Bit Bereich liegt. Diese Zeichenfolge wird nun mit axyc kodiert, wobei xy zwei Zeichen innerhalb dieses reservierten Bereiches sind.

So, ich habe meinen Unicode Artikel fertiggestellt: UTF für die Westentasche. Wenn ihr keine Korrekturen mehr habt, dann veröffentliche ich ihn auch hier als Einführungstutorial.