Diskussion:UTF-16

UTF-16 ist nicht UCS-2

Im Gegensatz zu UCS-2 in dem wirlich nur die BMP codiert wird ist UTF-16 explizit ein Encoding, das den kompletten Unicode raum abdeckt, unter Verwendung von surrogat paaren.

Siehe z.B. http://java.sun.com/developer/technicalArticles/Intl/Supplementary/

--BerndEckenfels 08:14, 25. Mär 2005 (CET)

Unverständlich, bitte überarbeiten

Ich bin von der Thematik nicht unbeleckt und trotzdem kapiere ich nicht, was der Artikel mir sagen will. Vor allem das erste Diagramm. Was bedeuten die 0, x, y, z? Was hat es mit den Ersatzzeichen auf sich? Das erschließt sich mir nicht. Die Rechnerei unter den ersten drei Diagrammen kapiere ich überhaupt nicht. Kann man das bitte an einem sinnvollen Beispiel erklären? Byte-Reihenfolge hingegen ist mir wieder verständlich, die Diagramme aber nur teilweise verständlich. -- molily 01:22, 1. Aug 2005 (CEST)

Ich stimme zu. Der Artikel ist sehr früh zu technisch. Für die Technikinteressierten kann es einen Abschnitt geben, wer genaue Informationen braucht, wird sowieso die Primärquellen konsultieren. Mich würde interessieren, wo UTF-16 hauptsächlich eingesetzt wird und warum. Unicode sagt zum Beispiel, Java benutze es. --Shepard 18:39, 6. Dez. 2006 (CET)

Stimme auch zu. Habe mal einen Versuch gestartet, das zu verbessern. Ich denke es ist auf jeden Fall mal etwas besser als vorher. --Breeblebrox1964 20:00, 7. März 2008 (CET)

Erklärung für Laien

UTF-16 ist vielleicht das am schwierigsten zu verstehende UTF. Hier mal eine einfache(?) Erklärung:

• Bei UTF-16 geht es darum, Unicode-Zeichen als Abfolge von 16-bit-Einheiten darzustellen
• Ist das Unicode-Zeichen nur 16 bit groß (oder kleiner) kann man es direkt als 16-bit-Einheit in den Datenstrom schreiben
• Braucht das Zeichen mehr als 16 bit wird's kompliziert:
  • Das Zeichen muss jetzt auf zwei 16-bit-Einheiten verteilt werden
  • Damit man erkennen kann, dass die Einheiten ein Paar bilden haben sie an den höchsten Stellen standardisierte bits:
    • 110110.......... (Die erste Einheit des Paares)
    • 110111.......... (Die zweite Einheit des Paares)
  • In jeder Einheit sind also noch 10 bits frei, in die man jeweils eine Hälfte des Unicode-Zeichens stecken kann

Jetzt wird's kompliziert. Anstatt das Unicode-Zeichen einfach zu zerteilen zieht man erst 65536 davon ab. Dies hat den Vorteil, dass man jetzt 65536 Zeichen mehr kodieren kann. Wenn man das Zeichen lesen möchte muss man daran denken, wieder 65536 zu addieren (Also 1101100000000000 1101110000000000 steht nicht für U+0000 sondern für U+10000). Hoffe dass es jetzt klarer ist. RedNifre 02:30, 15. Feb. 2008 (CET)

Was meiner Ansicht nach bei deiner Erklärung genau wie im Artikel fehlt, ist der Hinweis, dass eben nicht alle 16-Bit-Unicode-Zeichen direkt in den Datenstrom schreiben kann! Denn durch die Kodierung mit 110110 und 110111 ist dies nicht mehr möglich, da 11011yxxxxxxxxxx jetzt zwei Bedeutungen haben würde: Einerseits könnte das Original-16-Bit-Unicodezeichen oder eben die Kodierung gemeint sein.

Eine Unterscheidung beim Lesen ist natürlich nicht möglich, also müssen alle Zeichen zwischen 1101100000000000 und 1101111111111111 immer als Zeichen-Paar (32-Bit) abgelegt werden, obwohl es sich eigentlich um Zeichen handelt, die in die 16 Bit direkt passen würden. Verstehe ich das so richtig?

Anders kann ich mir zumindest nicht erklären, wie man beim Lesen wissen will, ob das bspw. das Zeichen 1101100011001100 nun das Zeichen mit Codepoint 55500 (dez) in Unicode oder das erste Zeichen eines Surrogat-Paars sein soll. Oder gibt es den Wertebereich zwischen 1101100000000000 und 1101111111111111 so in Unicode gar nicht? Also wurde der Bereich freigehalten, um speziell für die UTF-16-Kodierung keine Zeichen zu überdecken?

Fragen über Fragen, die hier und dann im Artikel geklärt werden sollten. --217.228.225.235 01:38, 28. Mär. 2008 (CET)

Ich antworte mir mal selbst. Es ist tatsächlich so, dass die 2048 Zeichen zwischen 1101100000000000 und 1101111111111111 speziell freigehalten werden. Dort befinden sich keine Zeichen. Zitat aus dem Unicode-Glossar: "Surrogate Code Point. A Unicode code point in the range U+D800..U+DFFF. Reserved for use by UTF-16, where a pair of surrogate code units (a high surrogate followed by a low surrogate) “stand in” for a supplementary code point." Diese Information fehlt im deutschen Wikipedia-Artikel, während sie im englischen in einer Klammer irgendwo im Fließtext enthalten ist. Damit ist die Aussage, dass 16-Bit-Zeichen direkt in den Datenstrom geschrieben werden können, doch richtig.

Ich finde den jetzigen Stand des Artikel trotzdem mehr als verwirrend. Die Erklärung von RedNifre hier drüber ist dagegen perfekt verständlich, und das ganz ohne zweifelhafte Schaubilder. --217.228.225.235 01:49, 28. Mär. 2008 (CET)

Schön dass meine Erklärung verständlich ist :). Wäre ich momentan nicht vollständig ausgelastet hätte ich den Artikel schon längst überarbeitet. Übrigens: Selbst wenn man wollte könnte man die verbotenen "Zeichen" im Bereich von 1101100000000000 bis 1101111111111111 nicht in UTF-16 als Zeichenpaar abspeichern: da man ja erst 65536 (Die Größe der BMP) abziehen müsste käme man ins Negative. RedNifre 22:34, 28. Mär. 2008 (CET)

Mein Versuch der Interpretation (anhand der Implementierung verifiziert): Aus beiden Surrogaten werden nur die unteren 10 Bit verwendet (surrogat & 0x3ff). Da das Ergebnis aber praktisch 11 Bit hat, ist für das Highsurrogat definiert, daß die oberen 4 Bits um eins kleiner sind als das Ergebnis (deshalb dort: high += 0x40h). Das Ergebnis ist dann: (high << 10) | low, oder ausgehend von den Original 16 Bit Surrogaten: (((high & 0x3ff) +0x40) << 10 | (low & 0x3ff). Vorher muß lediglich sichergestellt werden, daß die Surrogate innerhalb des entsprechenden Bereichs liegen: für das Highsurrogat gilt ((high & 0xfc00) == 0xd800), analog für das Lowsurrogat ((low & 0xfc00) == 0xdc00). --maku 12:17, 29. Mär. 2008 (CET)

Wer’s ganz genau wissen möchte: UTF-16 FAQ (engl.) vom Unicode-Konsortium – sollte keine Fragen offen lassen und Interpretationen unnötig machen. (Das soll aber nicht heißen, dass der Artikel so nicht in Ordnung wäre.) --131.169.184.136 00:51, 19. Apr. 2008 (CEST)

Visualisierung

Ein Bild sagt mehr als 1000 Worte. Was haltet ihr davon? --RokerHRO 15:18, 26. Aug. 2008 (CEST)

Guter Ansatz, das Bild sieht nett aus! Nur leider enthält es noch ein paar Fehler: Unicode-Zeichen sind bis zu 21 Bit groß. In deinem Bild hat das ursprüngliche Zeichen aber nur 20 Bit (0 bis 19). Außerdem fehlt die Subtraktion. Die würde ich als "-1" über die linken fünf Pfeile schreiben, wobei der Pfeil vom höchsten Bit (Index 20) irgendwie im Nichts enden muss (Nach der Subtraktion ist das 21. Bit auf jeden Fall 0 und landet deswegen nicht in den Surrogaten). Die linken fünf Pfeile könnten auch noch eine andere Farbe bekommen als die rechten 16. RedNifre 22:07, 27. Aug. 2008 (CEST)

Darum steht da ja auch nicht U sondern U'. Das ist bereits der Wert nach der Subtraktion. Das Bild soll ja nicht selbsterklärend sein, sondern eine textuelle Beschreibung des Algorithmusses nur ergänzen. --RokerHRO 00:23, 28. Aug. 2008 (CEST)

Ach so, ja, dann passt das Bild wohl. (Ich persönlich fände es besser, den kompletten Algorithmus in ein Bild zu packen (Als eine Art Flussdiagramm), aber mir fallen gerade keine guten Argumente dafür ein ;-) RedNifre 11:01, 28. Aug. 2008 (CEST)

Den Algo komplett als Bild zu haben wäre nicht mehr barrierefrei. Das Bild soll den Text ja nur ergänzen, nicht ersetzen. --RokerHRO 13:50, 29. Aug. 2008 (CEST)

Bedeutung der Abkürzung

Steht die Abkürzung UTF-16 wirklich für „Universal Multiple-Octet Coded Character Set Transformation Format for 16 Planes of Group 00“? Man findet fast immer nur „16-bit Unicode Transformation Format“, und diese Bedeutung wäre sinngemäß ja auch auf UTF-8 und UTF-32 übertragbar (wenn man annimmt, dass die Zahl für die kleinstmögliche Anzahl von Bits in einem Code steht). Außerdem codiert UTF-16 genaugenommen ja nicht nur 16, sondern alle 17 Planes … --131.169.184.136 23:12, 14. Aug. 2007 (CEST)

Ja, genauso steht es im Buch "The Unicode Standard 4.0" im Glossar sowie in Anhang C.3: "The term UTF-16 stands for UCS Transformation Format for 16 Planes of Group 00." Ein paar Sätze weiter oben steht: "The Term UTF-8 stands for UCS Transformation Format, 8-bit form." Es lebe die Inkonsistenz. --RolandIllig 13:43, 11. Feb. 2009 (CET)

Java

...wird UTF-16 vielerorts zur internen Zeichenkettenrepräsentation verwendet, beispielsweise in aktuellen Versionen von Java.

nicht UCS-2? --109.41.11.118 07:49, 11. Aug. 2012 (CEST)

Seit Java 1.5 beachtet Java bei Strings UTF-16-Surrogates. Einzelne Zeichen sind allerdings weiterhin nur 16 Bit groß, können somit keine Unicodezeichen jenseits der BMP abbilden. --RokerHRO (Diskussion) 08:17, 11. Aug. 2012 (CEST)

CharsetDecoder beachtet wohl, oder wie? --109.41.11.118 08:38, 11. Aug. 2012 (CEST)

Äh… wonach genau fragst du jetzt? --RokerHRO (Diskussion) 15:02, 11. Aug. 2012 (CEST)

Geschichte Geschwafel

Warum es bei den überragenden Vorteilen von UTF-8 dieses UTF-16 überhaupt noch gibt, mag sich manch einer fragen.

Das liegt daran, dass man Unicode lange Zeit auf ca. 65000 Zeichen begrenzen wollte! Bis zur Version 3.0. Darum das Zusammenlegen von Chinesisch und Japanisch, einer wenn nicht der Schwerpunkt der Unicode-Arbeit. Sonst hätte es nicht in 16 Bit gepasst. Worüber chinesische und japanische Linguisten gleichermaßen die Nase rümpfen. Denn die Entwicklung der chinesischen Zeichen ging in China, Taiwan, Hongkong und Japan doch recht weit auseinander.

Tatsächlich ist die Limitierung des Adressraumes für die wichtigen Zeichen auf < 64K ein entscheidender Erfolgsfaktor für Unicode.

Systementwickler bei Sun (Java) und Microsoft (Windows) nahmen den 16-Bit-Zeichentyp als neuen „endgültigen“ Standard hin, und definierten den entsprechenden Datentyp (Windows: WCHAR, als wchar_t in den C-Standard aufgenommen). Auch auf dem Dateisystem (NTFS, mit Windows 95 bei VFAT) und beim USB wurde es genau so festgelegt. Damit waren alle Probleme gelöst. Alle? Nein! Der Datenaustausch zum Rest der Welt (sagen wir mal: DOS und Windows 3.1, sowie Textdateien - man beachte, dass Windows NT auch für Big Endian vorgesehen war) war erheblich erschwert, und führte bei Windows zu dem Ungetüm der API-Dopplung (bspw. SetWindowTextW() vs. SetWindowTextA()).

Auch der C-Standard wurde per API-Dopplung erweitert, etwa wcslen() (lies: „Wide Character String Length“) vs. strlen(), aber hier nicht indem strlen() bimodal wurde wie Windows' SetWindowText(). Murks. Während 16-Bit-Windows-Quelltexte einigermaßen durch Neucompilierung überlebten, mussten bimodale C-Programme bspw. _tcschr() benutzen, also komplett umgeschrieben werden.

Bei Linux hat man den Zug schlicht verschlafen und blieb bei 7 Bit. Eine Reihe von Programmen versagte gar bei 8-Bit-Zeichensätzen, da diese etwa folgenden Kode enthielten: char c; while ((c=getchar())>=0) ..., ein klassischer Bug.

Internationalisierung von Linux lief damals ziemlich holprig, und man begnügte sich weitgehend mit Englisch. 8-Bit-Systeme blieben beim System der mehr oder weniger umschaltbaren Codepages. Wie es beim Mac aussah entzieht sich meiner Kenntnis.

Mit der Version 4.0 brüskierte Unicode die Systemprogrammierer mit dem Bruch der 64-K-Mauer. (Wir erinnern uns an den Satz von Bill Gates: „640 KByte sind genug für jedermann“?) MBCS mit 16 Bit (so könnte man UTF-16 bezeichnen) ist so ziemlich das blödeste, was einem Systemdesigner einfallen kann: Es kombiniert den Bruch mit „Zeichen == 8 Bit“ und „Zeichen ist untrennbar“. (Die Erweiterung von Unicode auf mehr als 64K Zeichen war mit der Reservierung von Bereichen für die später Low- und High-Surrogates irgendwie vorgesehen, aber man dachte wohl nicht so schnell an eine Auffüllung der Kodepositionen.) Daraufhin entschied man sich bei Microsoft und Java zunächst, offiziell nur „BMP0“, also die unteren „echten“ 16-Bit-Kodepositionen zu unterstützen. Vorläufig. Damit ein WCHAR ein Zeichen bleibt. Schriften für >64K waren und sind sowieso Mangelware. Entsprechende Unicode-Routinen wurden nur dafür ausgelegt (siehe WideCharToMultiByte): CESU-8 war die Folge, so konnte nämlich der Anwender „höhere“ Unicodes einschmuggeln. Durch die Hintertür.

Die C-Entwickler hatten übrigens nie festgelegt, dass wchar_t 16 Bit groß ist. Es ist nur ≥ char. (Pragmatisch wird ≤ int angenommen.) Auch bei Intel war man so „vorauseilend schlau“, den 16-Bit-Datentyp im 32-Bit-Mode des 80386 mit Opcode-Präfixen 0x66 zu bestrafen. C mit wchar_t hätte demnach den Übergang zu > 64K Zeichen mühelos verkraften können. Aber so recht wollte das niemand. Wäre ja wiederholter Data Bloat. Gerade in kleinen Systemen mit wenig Speicher, etwa Mikrocontrollern in WLAN-Routern, wären die dann erforderlichen Arrays und Stringkonstanten aus 4-Byte-wchar_t schlichtweg nutzloser Overkill.

Inzwischen wurde UTF-8 bekannt, und große Linux-Distributoren schalteten recht zügig um. Daher die heutige (2014) faktisch durchgängige UTF-8-Unterstützung von Linux. Auch auf Webseiten hielt UTF-8 auf breiter Front Einzug, gerade so, als ob man nur darauf gewartet hätte. Unter anderem weil hässliche, Platz fressende HTML-Entitäten (&auml; usw.) verschwinden konnten. Bei E-Mail hingegen ist die Codepage-Benutzung noch weit verbreitet, was wohl nur an den Voreinstellungen diverser Programme liegt. (Die Fehler im OSI-Layer 8 sind ja sattsam bekannt.)

Heimlich, still und leise wurde dann mal festgelegt, dass Windows richtiges UTF-16 unterstützt. Ab Windows XP ungefähr. Alles was dazu nötig war ist ein bisschen mehr Kode bei MultiByteToWideChar() sowie WideCharToMultiByte(). Das war alles. Hat Folgen für die Entwickler von Schriften sowie für CESU-8. Und für Programmierer: Plötzlich hat man es mit MBCS zu tun. Trotz Unicode. Da hätte man ja gleich bei UTF-8 bleiben können. Gab es aber damals noch nicht. Sogar der USB-Standard wurde durch die Hintertür angepasst, was die String-Deskriptoren betrifft. Muss ja zum Windows passen. Nachweis: UnicodeECN,2005-02-21. Da USB-Geräte wohl nie Strings verarbeiten, sondern nur Konstanten liefern, fällt das kaum ins Gewicht. (Abgesehen von meinen eigenen kenne ich auch keine, die mehrsprachige Strings anbieten.)

Nunmehr sind Programmierer auf den Trichter gekommen, möglichst nur noch UTF-8 zu verwenden. Das sichert Portabilität zu Unix, Textdateien, HTML, Mail, dem Compiler (der Stringkonstanten in aller Regel uninterpretiert in den Objektcode wirft) und den gewöhnlichen String-Funktionen (also strlen()). C-Programmierer sind ja entweder Gewohnheitstiere oder faul oder beides, in jedem Falle schreibfaul (sonst wär's ja nicht so kryptisch kurz).

Jetzt müsste man ja nur noch die ANSI-Codepage von Windows auf UTF-8 (numerisch 65001) stellen, und (unter Windows) wären alle Probleme verschwunden. Genau dies hat man auch in Redmond gesehen — und einen Riegel vorgeschoben! Nein, man will keinesfalls Programmierern das Leben leichter machen, die Programme für Unix und Windows schreiben. „Wir waren mit UTF-16 zuerst da! Ätsch!“ Unabhängig davon hätte es nicht so einfach funktioniert, da der ANSI-Zeichensatz nicht als MBCS akzeptiert wird (beim westeuropäischen Windows) bzw. sich nicht mit DBCS verträgt (ostasiatisches Windows). Hier rächt es sich, dass die Sprache im Windows eincompiliert ist. Könnte man fixen. Per Internet-Update. Wenn man nur will.

Bei Java dasselbe „Ätsch“, nur dass es dort weniger stört. Denn dort sind char und int nicht zuweisungskompatibel. An machen Stellen stört es aber trotzdem, bei Systemprogrammierern wie bei mancher Datei-Ein/Ausgabe.

Bleibt zu hoffen, dass man in Redmond irgendwann dem vielfachen Wunsch der Programmierer nachgibt, alles (ALLES! Auch COM, WindowsForms, NTFS und USB) auf UTF-8 umstellt und UTF-16 begräbt. Für immer. Oder für Java übrig lässt.

In vielen Fällen wurde pragmatisch zu UTF-8 gewechselt ohne einen Standard zu verabschieden. Etwa bei der Ablage von Dateinamen in ZIP-Archiven.

--86.56.10.171 02:33, 23. Feb. 2014 (CET)

Lauter für sich plausibel klingende, aber leider nicht belegte Aussagen. Wie soll das nun bei der Verbesserung des Artikels helfen? Ich weiß es leider nicht. --RokerHRO (Diskussion) 21:54, 23. Feb. 2014 (CET)

Der Einzelnachweis fällt natürlich schwer, deshalb steht's ja erst mal unter "Diskussion" und nicht im Artikel. Vielleicht könnten mehrere Leser dazu beitragen. Wenn ich etwas finde werde ich damit anfangen. --Henrik Haftmann (Diskussion) 01:11, 24. Mär. 2014 (CET)

Naja, dieser Abschnitt ist aber keine objektive oder gar nachvollziehbare (also belegbare) Beschreibgung der Geschichte, sondern persönliches Geschwurbel des Autors, was man nicht nur an den fehlenden Belegen sieht, sondern auch an der immerzu eingebrachten Meinung des Autors, z.T. in unsachlichem und WP-unwürdigem Stil.

Ich könnte auch eine Menge über die Irrungen und Wirrungen von Unicode im Allgmeinen und UTF-16 im Speziellen hier abkippen. Mach ich aber nicht, denn diese Diskussionsseite ist kein Platz für persönliches Geschwafel, sondern dient einzig der Verbesserung des Artikels, siehe WP:DS. Und inwieweit dieser Abschnitt diesem Ziel dient, ist mir weiterhin unklar.

--RokerHRO (Diskussion) 12:21, 24. Mär. 2014 (CET)

Kodierung

Zitat "Die Zeichen der BMP werden direkt auf die 16 Bits einer UTF-16-Code-Unit abgebildet. Die BMP enthält die Unicode-Zeichen, deren Code im Bereich U+0000 bis U+FFFF liegt." ist doch einfach nur falsch. Wie sonst könnten sonst "Surrogate Pairs" codiert werden? (nicht signierter Beitrag von 188.62.58.119 (Diskussion) 21:12, 20. Jan. 2015 (CET))

Das ist schon richtig so.

"Die Zeichen der BMP liegen im Bereich 0000_hex bis FFFF_hex". Daraus folgt natürlich nicht die Umkehrung. (Also: dass in diesem Codebreich nur BMP-Zeichen liegen würden). Denn in diesem Code-Bereich sind große Teile freigehalten worden, z.B. für die UTF-16-Surrogat-Pärchen.

Wenn du die Formulierung unglücklich / missverständlich findest, kannst du gerne eine verständlichere vorschlagen. :-)

--RokerHRO (Diskussion) 22:02, 20. Jan. 2015 (CET)

Berechnung der Surrogates

Die Berechnung der Surrogate-Pairs ist nicht ganz richtig wiedergegeben, obwohl die Formel beim Unicode Konsortium auch in dieser Form veröffentlicht wurde. Es fehlt die Aussage, dass es sich bei der Berechnung des High-Surrogates um eine Integer-Division ohne Rest handelt bzw. es sollte, weil noch anschaulicher, eine Abrundungsfunktion, ein „Right-Shift“ oder eine Gaußklammer eingefügt werden. Die Formeln könnten z.B. so aussehen:

hiSur = D800 + floor((v-10000) / 400) oder D800 + ( ( v -10000) >> 10)

loSur = DC00 + ((v-10000) % 400)

Aus dem Artikel wird auch nicht verständlich, wie die Kodierung der Surrogates tatsächlich funktioniert. Die Erklärung über die Bitfolge verwirrt, meiner Meinung nach, viel mehr als dass sie Klarheit schafft. Aus diesem Grunde möchte ich den folgender Formulierungsvorschlag zur Diskussion stellen:

Mit den vorhandenen 1024 High-Surrogates und 1024 Low-Surrogates werden die 1.048.576 Supplementary Code Points, und damit alle Zeichen, die nicht innerhalb er BMP liegen, codiert.

Die Anzahl der Supplementary Code Points von 1.048.567 entspricht dem Produkt von 1024 * 1024. Somit lassen sich alle 1.048.567 Zeichen in 1024 Abschnitte zu je 1024 Zeichen aufteilen.

Das High-Surrogate repräsentiert in dieser Aufteilung den Abschnitt in dem das Zeichen zu finden ist und das Low-Surrogate repräsentiert die Zeichenposition innerhalb des Abschnittes.

Da für die Surrogate-Blöcke innerhalb der BMP feste Positionen reserviert sind, sind die Positionen des ersten High-Surrogate Code Points und des ersten Low-Surrogate Code Points als Offsets zu verstehen, zu denen jeweils der Abschnitt bzw. die Position des Zeichens innerhalb des Abschnitts hinzu addiert wird.

Die Codierung für einen Supplementary Code Point besteht somit aus dem High-Surrogate-Offset ( D800 ) + Abschnittsposition und dem Low-Surrogate-Offset ( DC00 ) + Zeichenposition Zu beachten ist dabei, dass die Zählweise der Zeichen und Abschnitte Null indiziert ist und somit der erste Supplementary Code Point im Abschnitt 0 auf Position 0 liegt.

Die Codierung ist von der Logik her, ohne die Offsets zu berücksichtigen, analog zur Darstellung von Zeiteinheiten in Stunden und Minuten. Liegt beispielsweise eine Zeitangabe nur in Minuten vor, kann aus dieser, anhand einer Integer-Division und Modulo-Operation, eine Angabe in Stunden und Minuten gewonnen werden.

Disclaimer:

mir ist bewusst das ein Code Point nicht direkt einem darstellbaren Zeichen entspricht, verwende die Beiden jedoch mit Absicht als austauschbare Begriffe, da die übertriebene Korrektheit das Allgemeinverständnis um die Berechnung der Surrogates trüben würde. (nicht signierter Beitrag von Sivale (Diskussion | Beiträge) 17:38, 4. Mär. 2017 (CET))

Erweiterung auf Codepunkte jenseits U+10FFFF

Sind dafür einige High-Three-Word-Surrogates und High-Four-Word-Surrogates geplant, die von jeweils zwei bzw. drei Low-Surrogates gefolgt werden? --88.70.36.224 21:49, 27. Dez. 2019 (CET)

Nö. Wozu? UTF-16 deckt bereits alle Zeichen ab, die es jemals in Unicode geben soll. (Genauer: Man hat den Zeichenvorrat von Unicode eben absichtlich auf den Codebereich begrenzt, den UTF-16 kodieren kann: U+0000 … U+10FFFF). --RokerHRO (Diskussion) 15:38, 2. Jul. 2021 (CEST)