Normalisierung? - Was geschieht hierbei? (was: Normalisierung? - Was geschieht hierbei? - do not ignore )

[Michael Bäuerle]

Thomas Barghahn wrote:
> *Michael Bäuerle* meinte:
> > Marcel Logen wrote:
> > > Martin Schnitkemper in de.test:
> > >
> > > [...]
> > >
> > > > dann problematisch werde, wenn aufgrund eines eigentlich gleichen Betreffs
> > > > aber wegen unterschiedlicher Kodierung doch nicht abgetrennt wird.
> > >
> > > Deswegen meinte ich ja, daß das gesamte Subject zunächst de-
> > > kodiert werden muß. Dann kann man problemlos vergleichen.
> >
> > Bei Unicode reicht das noch nicht.
> > Da muss man nach der Dekodierung auch noch normalisieren.
>
> Bei solchen Schritten (Normalisierung) muss ich dann wirklich immer
> ehrlich bleiben und zugeben, dass ich es (noch) nicht richtig verstanden
> habe! Was genau passiert bei einer Normalisierung eigentlich und was ist
> das Ziel einer solchen Normalisierung?

Unicode erlaubt es mehrere Codepoints zu verwenden, um eine Glyphe für
die Anzeige zu bilden. Es ist z.B. möglich einen Umlaut aus dem Basis-
buchstabe und dem Codepoint COMBINING DIAERESIS (U+0308) zu bilden.
Kombinierende Codepoints werden mit dem davor stehenden Basiszeichen
verbunden, die Reihenfolge für z.B. "Ä" muss also so aussehen:

U+0041 LATIN CAPITAL LETTER A
U+0308 COMBINING DIAERESIS

Für manche (aber nicht alle) zusammengesetzten Zeichen existiert auch
noch ein eigener Codepoint, das ist z.B. bei "Ä" der Fall:

U+00C4 LATIN CAPITAL LETTER A WITH DIAERESIS

Die Sequenz <U+0041,U+0308> und der Codepoint U+00C4 sind als
gleichwertig definiert, d.h. beides bedeutet "Ä", soll gleich angezeigt
werden und sich auch sonst für den Benutzer gleich verhalten.

In einem Text darf beides gemischt vorkommen, das ist kein Fehler
(da beide Varianten eine korrekte Kodierung für "Ä" darstellen).
Beispiel: Mit Copy&Paste zusammenkopiert.

Dann gibt es noch Zeichen, die aus mehr als zwei Teilen zusammengesetzt
sind. Beispiel "ᾅ":

U+1F85 GREEK SMALL LETTER ALPHA WITH DASIA AND OXIA AND YPOGEGRAMMENI

Diese können mit Unicode nicht nur komplett kombiniert oder komplett
zerlegt:

U+03B1 GREEK SMALL LETTER ALPHA
U+0314 COMBINING REVERSED COMMA ABOVE
U+0301 COMBINING ACUTE ACCENT
U+0345 COMBINING GREEK YPOGEGRAMMENI

kodiert werden, sondern auch teilweise kombiniert:

U+1F05 GREEK SMALL LETTER ALPHA WITH DASIA AND OXIA
U+0345 COMBINING GREEK YPOGEGRAMMENI

oder:

U+1F01 GREEK SMALL LETTER ALPHA WITH DASIA
U+0301 COMBINING ACUTE ACCENT
U+0345 COMBINING GREEK YPOGEGRAMMENI

Bei kombinierenden Codepoints mit verschiedenem Wert für ccc
(Character Combining Class) kann auch die Reihenfolge unterschiedlich
sein und es ergibt sich trotzdem das gleiche Resultat (sofern sich
die Reihenfolge der Codepoints mit gleicher ccc nicht ändert).
Es gibt damit noch weitere Möglichkeiten für die Kodierung:

U+03B1 GREEK SMALL LETTER ALPHA (ccc == 0)
U+0314 COMBINING REVERSED COMMA ABOVE (ccc == 230)
U+0345 COMBINING GREEK YPOGEGRAMMENI (ccc == 240)
U+0301 COMBINING ACUTE ACCENT (ccc == 230)

oder:

U+03B1 GREEK SMALL LETTER ALPHA (ccc == 0)
U+0345 COMBINING GREEK YPOGEGRAMMENI (ccc == 240)
U+0314 COMBINING REVERSED COMMA ABOVE (ccc == 230)
U+0301 COMBINING ACUTE ACCENT (ccc == 230)

Der Wert 0 für ccc bezeichnet einen "Starter" (auf diesen werden
die kombinierenden Codepoints montiert). Codepoints mit gleicher ccc
müssen in der gleichen Reihenfolge bleiben, sonst bedeutet die
Sequenz etwas anders.

> Gelesen habe ich, dass es wohl verschiedene Standards einer solchen
> Normalisierung gibt - richtig verstanden habe ich diese allerdings nicht.

Für verschieden kodierte Texte, die aber im Sinne von Unicode äquivalent
sind ("Canonical Equivalence"), ergibt sich nach der Normalisierung
jeweils die gleiche Codepoint-Sequenz.

Unicode definiert auch noch "Compatibility Equivalence", diese ist nur
in Sonderfällen sinnvoll verwendbar (und soll daher hier vernachlässigt
werden).

Es gibt zwei Varianten:
- Normalization Form C (NFC)
Das "C" ist als "Composed" zu verstehen
- Normalization Form D (NFD)
Das "D" ist als "Decomposed" zu verstehen

Für "Normalization Form C" wird alles soweit wie möglich kombiniert.
Für "Normalization Form D" wird alles soweit wie möglich zerlegt.
Die kombinierenden Codepoints werden dabei in eine definierte
Reihenfolge gebracht ("Canonical Ordering Algorithm").

Für die obigen Beispiele sollte sich mit allen Kodierungen nach
Normalisierung auf NFC der Codepoint U+00C4 bzw. U+1F85 ergeben
(sofern mir kein Fehler unterlaufen ist).

> Könnten wir vielleicht einmal ein /einfaches Beispiel/ besprechen,

Das einfache Beispiel wäre der Umlaut, siehe oben.

> sodass auch jedem Leser klar wird, was mit einer Normalisierung an-
> gestrebt wird und wozu sie eigentlich notwendig ist?

Das kompliziertere Beispiel mit dem griechischen Buchstaben soll
demonstrieren, dass es auch mehr als zwei Kodierungen geben kann.
Und dass Sequenzen der gleichen Codepoints, mit unterschiedlicher
Reihenfolge, bei Unicode trotzdem das gleiche bedeuten können.


[Xpost und Fup2 nach de.comp.text.misc]

[Thomas Barghahn]

*Michael Bäuerle* meinte:

> Thomas Barghahn wrote:
>> *Michael Bäuerle* meinte:

>>> Bei Unicode reicht das noch nicht.
>>> Da muss man nach der Dekodierung auch noch normalisieren.

>> Bei solchen Schritten (Normalisierung) muss ich dann wirklich immer
>> ehrlich bleiben und zugeben, dass ich es (noch) nicht richtig verstanden
>> habe! Was genau passiert bei einer Normalisierung eigentlich und was ist
>> das Ziel einer solchen Normalisierung?

> Unicode erlaubt es mehrere Codepoints zu verwenden, um eine Glyphe für
> die Anzeige zu bilden. Es ist z.B. möglich einen Umlaut aus dem Basis-
> buchstabe und dem Codepoint COMBINING DIAERESIS (U+0308) zu bilden.
> Kombinierende Codepoints werden mit dem davor stehenden Basiszeichen
> verbunden, die Reihenfolge für z.B. "Ä" muss also so aussehen:

> [...]

Zunächst einmal Vielen herzlich Dank(!) für all die Beiträge, die zu
diesem Thema auch von Heiko und Marcel gepostet wurden.

Anhand all dieser Beispiele und detaillieretn Information fällt es nicht
schwer, die Problematik "Normalisierung" zu durchschauen und somit auch
letztendlich zu verstehen.

Richtig bewusst und auch klar wurde mir diese Thematik mit dem ein-
fachsten Beispiel in dieser Diskussion, dem "ö", welches Heiko zur
Veranschaulichung eingebracht hatte. Dieses "ö", welches einst ein
zusammengesetztes Zeichen war, wurde während dieser Diskussion nämlich
"normalisiert". Ein besseres Beispiel kann es also gar nicht geben, denn
so konnte man den "Vorgang" /hautnah/ miterleben. :-)

Auch wurde mir nun der Sinn jener Normalisierung erstmalig richtig be-
wusst. Ein Vergleich zweier Zeichen, welche "nur" unterschiedlich auf-
gebaut sind, für den Leser aber exakt die gleiche Bedeutung als auch ein
gleiches Aussehen haben, der sollte schon funktionieren. So wurde mir
also nun ebenfalls klar, warum ein Subjekt nach der Dekodierung zunächst
"normalisiert" werden sollte, bevor man es mit einem anderen Subjekt
vergleichen will bzw. muss.

| Ja, flnews versendet NFC gemäß RFC 5198 (Kapitel 2, Punkt 4):
|
| > <https://www.rfc-editor.org/rfc/rfc5198#section-2>
| |
| | 4. Before transmission, all character sequences SHOULD be normalized
| | according to Unicode normalization form "NFC" (see Section 3).

Bei der "Vielzahl" von NRn, welche ich stets beobachte ;-), fällt nach
all der Lektüre nun auf, dass sich allein nur flnews an den obigen RFC
hält, was ich im Detail aber noch genauer prüfen muss und auch prüfen
werde.

Klar ist aber jetzt schon, dass der NR Dialog solch eine Normalisierung
*nicht* durchführt! Wie sollte er auch(?), wenn der Autor des Konverters
noch nicht einmal wusste, was sich hinter diesem Vorgang eigentlich ver-
birgt. ;-)

Nochmals Vielen herzlichen Dank(!) für all die Beiträge, welche mir
*alle* den Vorgang "Normalisierung" bzgl. Unicode deutlich näher gebracht
haben!

Thomas 😷
--
== S E N D E Z E I T ==============
  DATUM : Montag, 03. Juli 2023
  UHRZEIT: 12:39:41 UHR (MESZ)
== Heute: 'Iss Deine Bohnen' Tag ==