NCR und Valligator

[pl]

Hmm,

warum quittiert mir der Valligator ein 龜 mit Text run is not in Unicode Normalization Form C.???

Bitte mal um Hinweise. MfG

[Gunnar Bittersmann]

@@pl

warum quittiert mir der Valligator ein 龜 mit Text run is not in Unicode Normalization Form C.???

Woran hapert’s denn? An Unicode Normalization Form C wohl nicht – in Sachen Zeichncodierungen bist du ja hier der allwissende Überflieger.

Am Herausfinden, was U+FACE für ein Zeichen ist? Dafür hast du gerade eben dein eigenes Tool angepriesen.

Am Herausfinden, was es mit CJK Compatibility Ideographs auf sich hat? Die Suchmaschine deiner Wahl sollte dich zur Wikipedia führen.

Die deutsche Wikipedia sagt dir auch, welches Zeichen in NFC anstelle von U+FACE zu verwenden ist.

LLAP 🖖

[pl]

Woran hapert’s denn? An Unicode Normalization Form C wohl nicht – in Sachen Zeichncodierungen bist du ja hier der allwissende Überflieger.

So eine arrogante Antwort kann ja nur von Dir kommen. Darauf kann ich gerne verzichten. MfG

[Gunnar Bittersmann]

@@pl

Du suchst schon wieder Streit? Nicht mit mir.

LLAP 🖖

[pl]

Hmm,

warum quittiert mir der Valligator ein 龜 mit Text run is not in Unicode Normalization Form C.???

Es betrifft eine ganze Reihe weiterer Zeichen. Und die Meldung des Valigators liegt darin begründet, daß Unicode kanonisch aufgebaut ist. Für meine Anwendung ist das ohne Belang. MfG

[pl]

Hmm,

warum quittiert mir der Valligator ein 龜 mit Text run is not in Unicode Normalization Form C.???

Es betrifft eine ganze Reihe weiterer Zeichen. Und die Meldung des Valigators liegt darin begründet, daß Unicode kanonisch aufgebaut ist. Für meine Anwendung ist das ohne Belang. MfG

Das war gestern. Meine Anwendung habe ich entsprechend Unicode Standard Annex 15 erweitert, das Decomposition Mapping habe ich so in das Suchergebnis übernommen, daß beim Anklicken eine neue Suche in der Datei UnicodeData.txt stattfindet.

Im Beispiel listed das Suchergebnis alle Zeichen auf, die das COMBINING CARON, Codepoint 030C verwenden.

Es ist von der Handhabe (UX) evnt. noch verbesserungswürdig aber ihr seid ja auch noch da und dürft euren Senf dazugeben 😉

Und jetzt werde ich mal schauen ob CPAN schon ein API für diese Datei UnicodeData.txt hat, vielleicht gibts ja auch einen Webservice vom Konsortium. MfG

[pl]

Was sich auch der Valligator da einmischt 😉

Wie auch immer, bei einer Response als JSON hat der Valigator nichts mehr zu meckern. Schließlich kann sich jeder anhand der Codepoints seine Zeichen selber basteln wie er das für richtig hält, egal ob als NCR oder proprietäre Bytesequenzen.

Was mich etwas verwundert ist, daß es auf unicode.org noch keinen solchen Webservice gibt oder habe ich da was übersehen?

Für diesen Service habe ich ein PerlModule UnicodeDataAPI entwickelt, sowas gibt es auch noch nicht auf CPAN.

Ansonsten MfG

[Gunnar Bittersmann]

@@pl

egal ob als NCR oder proprietäre Bytesequenzen.

Proprietäre Bytesequenzen?? Was soll das sein?

Du meintest nicht NCR, sondern NFC?

Was mich etwas verwundert ist, daß es auf unicode.org noch keinen solchen Webservice gibt oder habe ich da was übersehen?

Was genau sollte es da geben? Es ist doch Sache des Texteditors, die Zeichen in NFC (oder einer anderen Normalisierungsform) zu speichern.

LLAP 🖖

[pl]

Malne Frage: Ω entspricht nicht der Normalform C (sagt Valligator). Was verrät mir die Abfrage auf UnicodeData.txt über die Normalform für dieses Zeichen?

Das Decomposition_Mapping (lt. UCD) zeigt auf den Codepoint 03A9 ist das die Normalform und wenn ja warum und welche Information liefert UCD zum warum? MfG

[Gunnar Bittersmann]

@@pl

Das Decomposition_Mapping (lt. UCD) zeigt auf den Codepoint 03A9 ist das die Normalform und wenn ja warum

Ja. Aus demselben Grund, warum Å U+00C5 (lateinisches großes A mit Ring) die Normalform zu Å U+212B (Ångström-Zeichen) ist.

Darum gegt’s ja bei Normalisierung: dass man nicht mehrere Vorkommen desselben Dings zulässt.

LLAP 🖖

[pl]

@@pl

Das Decomposition_Mapping (lt. UCD) zeigt auf den Codepoint 03A9 ist das die Normalform und wenn ja warum

Ja. Aus demselben Grund, warum Å U+00C5 (lateinisches großes A mit Ring) die Normalform zu Å U+212B (Ångström-Zeichen) ist.

Ja, mit Perl Unicode::Normalize kann ich z.B. die Normalform NFC erzeugen:

my $string = pack "U", 0x212B;
my $normalized_string = normalize('NFC', $string);
printf "%X", unpack "U", $normalized_string;

und sehe, daß da C5 rauskommt. Meine Frage war, wie ich das anhand der Unicode Character Database nachvollziehen kann.

MfG

[pl]

hi @Gunnar Bittersmann ,

Was genau sollte es da geben?

Genau Sowas

Es ist doch Sache des Texteditors, die Zeichen in NFC (oder einer anderen Normalisierungsform) zu speichern.

Meine UnicodeDataAPI habe ich ergänzt. Jede Abfrage liefert nun auch die Normalform C. Um die anderen Normalformen, KC, D und KD kann ich das auch noch ergänzen.

MfG