Diskussion:UTF-16

message: 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)
thread_title:  UTF-16 ist nicht UCS-2 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Unverständlich, bitte überarbeiten 

message: Ein Bild sagt mehr als 1000 Worte. Was haltet ihr davon? 
--RokerHRO 15:18, 26. Aug. 2008 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Visualisierung 

message: 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)
replies: text: 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)
thread_title:  Bedeutung der Abkürzung 

message: :...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)
replies: text: 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)
replies: text: CharsetDecoder beachtet wohl, oder wie? --109.41.11.118 08:38, 11. Aug. 2012 (CEST)
replies: text:  Äh… wonach genau fragst du jetzt? --RokerHRO (Diskussion) 15:02, 11. Aug. 2012 (CEST)
thread_title:  Java 

message: 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)
thread_title:  Berechnung der Surrogates 

message: 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)
replies: text: 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)
thread_title:  Erweiterung auf Codepunkte jenseits U+10FFFF