„discouraged characters“: warum sind welche Zeichen unerwünscht?
0 0 0 0 0 0 
Tim Tepaße
0
„discouraged characters“: warum sind welche Zeichen unerwünscht?
你们好,
bei der Bearbeitung von http://wwwtech.de/flyspray/?do=details&id=61 ist mir eine Frage aufgekommen: http://www.w3.org/TR/REC-xml/#charsets definiert erstmal grundsätzlich alle Zeichen, die in XML vorkommen dürfen. Soweit ist noch alles klar, aber etwas später, in der note, wird von „discouraged characters“ gesprochen. Das sollen die „compatibility characters“ sein und die im grauen Block spezifizierten Ranges. Da liegt jedoch ein Verständnisproblem meinerseits vor:
[#x7F-#x84], [#x86-#x9F]: Klar, das sind einige Kontroll-Sequenzen und nicht belegte Zeichen.
[#xFDD0-#xFDDF]: Ein Teil eines größeren Blocks, der nicht definiert ist (der geht eigentlich bis #xFFFF, bzw. bis #xFFFF gehen Non-Character-Codepoints, wenn ich das richtig sehe) – was ist mit dem Rest des Blocks? Warum ist da die hälfte des No_Block-Blocks trotzdem erlaubt?
[#1FFFE-#x1FFFF], [#2FFFE-#x2FFFF], [#3FFFE-#x3FFFF], [#4FFFE-#x4FFFF], [#5FFFE-#x5FFFF], [#6FFFE-#x6FFFF], [#7FFFE-#x7FFFF], [#8FFFE-#x8FFFF], [#9FFFE-#x9FFFF], [#AFFFE-#xAFFFF], [#BFFFE-#xBFFFF], [#CFFFE-#xCFFFF], [#DFFFE-#xDFFFF], [#EFFFE-#xEFFFF], [#FFFFE-#xFFFFF], [#10FFFE-#x10FFFF]: Scheint ein nicht-definierter Block zu sein, keines der Zeichen ist in http://www.unicode.org/cgi-bin/Code2Chart.pl zu finden.
Bleibt die Frage: Wie kommt der Bereich #xFDD0-#xFDDF zustande?
再见,
克里斯蒂安
-
你们好,
[#xFDD0-#xFDDF]: Ein Teil eines größeren Blocks, der nicht definiert ist (der geht eigentlich bis #xFFFF, bzw. bis #xFFFF gehen Non-Character-Codepoints, wenn ich das richtig sehe)
Falsch ausgedrückt. Was ich meinte: lt. http://www.sql-und-xml.de/unicode-database/noncharacter_code_point.html sind in dem Bereich bis U+FFFF immer wieder Lücken drin. Was ist mit denen, warum sind die erlaubt?
再见,
克里斯蒂安--
Beware Evildoers for my deed is done and every little damsel in distress will be shelted!
http://wwwtech.de/
-
Privit!
Wenn ich Dich richtig verstehe, geht es um den Block "Arabic Presentation Forms-A", der von U+FB50 bis U+FDFF geht.
In diesem sind die 32 Codes von U+FDD0 bis U+FDEF als Non-characters definiert; so weit ich weiß für interne Berechnungen von Programmen, die diese ganzen arabischen Ligaturen darstellen.
"These codes are intended for process internal uses, but are not permitted for interchange", steht in http://www.unicode.org/charts/PDF/UFB50.pdf.Danach (von U+FDF0 bis FDFF) kommen weitere arabische Ligaturen, die immer noch zu den Arabic Presentation Forms-A gehören. Dann folgen weitere Blöcke: Variation Selectors, Vertical Forms, Combining Half Marks, CJK Compatibility Forms, Small Form Variants, Arabic Presentation Forms-B, Halfwidth and Fullwidth Forms und Specials.
Die Specials gehen von U+FFF0 bis U+FFFF, wovon wiederum die letzten beiden Non-characters sind. (In jeder Ebene sind jeweils die letzten beiden Codes Non-characters.)Ich hoffe, das war das, was Du meinst. ;-)
Viele Grüße vom Længlich
-
Moin!
Wenn ich Dich richtig verstehe, geht es um den Block "Arabic Presentation Forms-A", der von U+FB50 bis U+FDFF geht.
Aha, interessante Informationen, die du da verteilst. :)
Die Specials gehen von U+FFF0 bis U+FFFF, wovon wiederum die letzten beiden Non-characters sind. (In jeder Ebene sind jeweils die letzten beiden Codes Non-characters.)
Naja, warum U+FFFE ein Non-Character sein muß, war mir schon klar, weil man sonst die BOM U+FEFF nicht als Unterscheidung für little/big endian einsetzen könnte. Aber der Rest - da hätte ich vermutet, dass irgendwie dieselben Ansätze für die Surrogatzeichen gelten könnten, was nach Betrachtung der Bereiche, die Surrogate darstellen sollen, und der hier hinterfragten Non-Chars aber irgendwie gar keinen Sinn ergab. ;)
- Sven Rautenberg
-
你好 Længlich,
Wenn ich Dich richtig verstehe, geht es um den Block "Arabic Presentation Forms-A", der von U+FB50 bis U+FDFF geht.
Jain, es geht um den kompletten Bereich bis U+FFFF; zugegeben, dass U+FFFE und U+FFFF non-characters und nicht erlaubt sind, ist mir klar, BOM und so. Also kann man den Bereich in der Tat einschränken bis U+FDFF
In diesem sind die 32 Codes von U+FDD0 bis U+FDEF als Non-characters definiert; so weit ich weiß für interne Berechnungen von Programmen, die diese ganzen arabischen Ligaturen darstellen.
"These codes are intended for process internal uses, but are not permitted for interchange", steht in http://www.unicode.org/charts/PDF/UFB50.pdf.Ja, auch das hatte ich bereits herausgefunden. Aber meine Frage war eine ganz andere: warum ist innerhalb dieses Bereichs nur U+FDD0 - U+FDDF „unerwünscht“ in XML/SGML-Dokumenten. Warum nicht die anderen Non-Characters auch? Davon haben wir ja in diesem Bereich genug, z. B. U+FDE0, U+FDED, U+FDEE und so weiter und so fort. Warum ist U+FDD0 - U+FDDF unerwünscht?
再见,
克里斯蒂安--
Swen Wacker: Denn wer 'ne Blacklist hat, muss halt daran denken, dass er manches nicht sieht... und vor dem posten die Realitaet einschalten
http://wwwtech.de/
-
Moin!
Ja, auch das hatte ich bereits herausgefunden. Aber meine Frage war eine ganz andere: warum ist innerhalb dieses Bereichs nur U+FDD0 - U+FDDF „unerwünscht“ in XML/SGML-Dokumenten. Warum nicht die anderen Non-Characters auch? Davon haben wir ja in diesem Bereich genug, z. B. U+FDE0, U+FDED, U+FDEE und so weiter und so fort. Warum ist U+FDD0 - U+FDDF unerwünscht?
Letztendlich wird es wohl darauf hinauslaufen, dass irgendwer das willkürlich so festgelegt und derartige Codepoints einfach als "ungültig für den Datenaustausch" definiert hat. Dementsprechend dürfen sie eben nicht in Codesequenzen vorkommen. :)
- Sven Rautenberg
-
Hallo,
Letztendlich wird es wohl darauf hinauslaufen, dass irgendwer das willkürlich so festgelegt und derartige Codepoints einfach als "ungültig für den Datenaustausch" definiert hat.
Dann ist da aber zweimal Willkür:
Erstens, wieso definiert jemand ab dem Unicode Standard 3.1 plötzlich mitten im BMP die Zeichen von U+FDD0 bis U+FDEF als „noncharacters“. „noncharacters“ sind da ja relativ selten, eigentlich bislang nur U+hFFFE und U+hFFFF (mit h aus 0 bis F) und die nachvollziehbar wegen BOM. Auf der Unicode-Seite und in den Unicode Standards findet sich da nichts außer einem vagen „historical reasons“.
Zweitens, wenn die Third Edition vom XML-Standard zusätzlich die Empfehlung aufnimmt, der Autor solle diese Zeichen wenn möglich nicht verwenden, wieso beschränkt er sich da auf die Zeichen von U+FDD0 bis U+FDDF, wenn doch dieser Block von noncharacters im Unicode-Standard bis U+FDEF weiter geht?
Christian, molily und ich, die wir im Chat darüber gestolpert sind, sind halt noch jung, wir hoffen halt noch auf eine irgendwie nachvollziehbare Logik. ;)
Tim
-
Moin!
Dann ist da aber zweimal Willkür:
Erstens, wieso definiert jemand ab dem Unicode Standard 3.1 plötzlich mitten im BMP die Zeichen von U+FDD0 bis U+FDEF als „noncharacters“. „noncharacters“ sind da ja relativ selten, eigentlich bislang nur U+hFFFE und U+hFFFF (mit h aus 0 bis F) und die nachvollziehbar wegen BOM. Auf der Unicode-Seite und in den Unicode Standards findet sich da nichts außer einem vagen „historical reasons“.
Das ist eine Frage, die wahrscheinlich nur die Unicode-Organisation ausführlicher beantworten kann.
Zweitens, wenn die Third Edition vom XML-Standard zusätzlich die Empfehlung aufnimmt, der Autor solle diese Zeichen wenn möglich nicht verwenden, wieso beschränkt er sich da auf die Zeichen von U+FDD0 bis U+FDDF, wenn doch dieser Block von noncharacters im Unicode-Standard bis U+FDEF weiter geht?
Das dürfte dann das W3C beantworten können. Möglich, dass da jemand (genau wie beim "Referrer") einfach nur einen Tippfehler eingebaut hat, der u.U. noch unbekannt geblieben ist.
Im Zweifel würde ich einfach mal eine Mail an unicode.org und w3c.org schicken und nachfragen, wo denn da der Sinn steckt.
- Sven Rautenberg
-
-
你好 Sven,
das sind so die Antworten, die ich gar nicht hören will ;-)
再见,
克里斯蒂安
-
-
-
-