Diskussion:UTF-8

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 2 Abschnitte.

Unbeschränkt lange Byteketten

Der Satz »Algorithmus lässt theoretisch unbeschränkt lange Byteketten zu« könnte m. E. noch eine Erklärung vertragen, wie es weitergeht, wenn das Startbyte FF ist. Ich vermute mal, dass dann bei sieben Folgebytes das erste Folgebyte mit 100xxxxx beginnen müsste, bei acht Folgebytes mit 1010xxxx usw., aber offensichtlich wäre diese Konvention nicht, deshalb sollte man sie erwähnen, oder? Ich kann es auch gerne selbst reinschreiben, wenn mir jemand bestätigt, dass es so ist. --Philipp Sªsse (Diskussion) 08:27, 3. Nov. 2023 (CET)

Die Formulierung im Artikel war Quatsch. Oder ließ zumindest Raum für unnötige Spekulationen. Im ursprünglichen Entwurf für UTF-8 (und den ersten Implementierungen) waren Start-Bytes bis FD_hex erlaubt, die eine 6-Byte-Sequen einleiteten, mit denen insgesamt 31-Bit-Werte kodiert werden konnten. Die Werte FE_hex und FF_hex als Start-Byte waren nie in einem offiziellen UTF-8-Standard definiert.

Die im Artikel nachfolgende Tabelle gibt das auch so wieder.

Ich habe darum die missverständliche Formulierung im Artikel korrigiert und hoffe, es bestehen nun keine Fragen mehr. :-)

--RokerHRO (Diskussion) 08:59, 3. Nov. 2023 (CET)

Danke! Könntest du “Entsprechend lange Bytefolgen und große Werte gelten heute als unzulässige Codes und sind …” noch etwas klarer schreiben? Also etwa “… vier Bytes lange Byteketten auf. Längere Byteketten gelten…”. Das Wort “entsprechend” könnte missverstanden werden. Gruß von der Wassermaus (Diskussion) 10:08, 3. Nov. 2023 (CET)

Das Wort „heute“ ist wohl auch missverständlich.

• Es meint: zurzeit
• Also nicht: „Früher war das mal so, aber heutzutage nicht mehr …“
• Sondern: Weil momentan nur bis 1FFFF definiert sind, kann es keine zusätzlichen Bits nutzen. Wenn aber jeder Stern in der Galaxie oder jeder Mensch auf dem Planeten seinen persönlichen Icon und Codepoint bekäme, dann doch wieder.

sind zurzeit unzulässige Codes

VG --PerfektesChaos 10:51, 3. Nov. 2023 (CET)

Der Artikel stellt halt den aktuellen Stand dar. Mit "heute" ist gemeint: "seit der Veröffentlichung des RFC 3629 im November 2003" also vor 20 Jahren. Dieser Standard definiert bis heute UTF-8. Wenn/falls es irgendwann mal ein Update geben sollte, werden wir diesen Wikipedia-Artikel eben entsprechend anpassen. Bis dahin ist das alles Spekulation. --RokerHRO (Diskussion) 21:11, 10. Nov. 2023 (CET)

ASCII

Heute verschobener Text:

• „UTF-8 ist in den ersten 128 Zeichen (Indizes 0–127) deckungsgleich mit ASCII.“
• War vorher schon nicht richtig, aber fiel mir nun auf.
• ASCII sind nur 1–126. NUL und DEL gehören nicht dazu.
• Die Zeichen 128–159 existieren schlicht nicht.

Tatsächlich ist der Bereich bis 159 nach ANSI bzw. ISO 8859-1 übernommen worden, und ausgefüllt.

• Umseitig müsste sich eher auf den späteren Zustand und nicht auf ASCII beziehen.
• Was es sagen will: Für den Bereich der 7-Bit passiert mit UTF-8 nichts. Alles mit dem 8. Bit ist möglicherweise Start einer UTF-8-Sequenz; aber auch nicht alle sind gültig.
• Das kleinste führende Zeichen ist C5 = 192₁₀, weil die ersten drei Bits des ersten Oktetts 110 sein müssen. Alle (ersten) Zeichen 128…191 führen zu unerlaubtem UTF-8, das zweite Oktett (und weiter folgende) muss immer mit 10 beginnen, was zu Werten ≥128 führt, also niemals ASCII sein kann.
• Hingegen sind 128–159 in Unicode verboten, weil sie die Steuerzeichen 0–31 in ASCII spiegeln, nur mit gesetztem 8. Bit. Das hatte man reserviert, so dass die 7 Bit <32 niemals ein erlaubtes druckbares Zeichen ergeben.

VG --PerfektesChaos 01:00, 15. Nov. 2024 (CET)

Hallo Perfekter Chaot, ich war es, der den Text (in unveränderter Form) ein paar Absätze nach hinten verschoben hat. Aus rein formalen Gründen, ohne den Inhalt in Frage zu stellen. Ich versuche zu verstehen, was das Problem ist, komme aber vielleicht nicht ganz mit.

“Für den Bereich der 7-Bit passiert mit UTF-8 nichts.” - genauer wohl: Die Unicode (oder UCS??) Zeichen 0-127, also exakt Unicodeblock Basis-Lateinisch, werden un UTF-8 genauso kodiert. In American Standard Code for Information Interchange wird ungerührt von 128 7-Bit-Zeichen gesprochen, nur irgend wo mittendrin mal der Disclaimer “Aus diesem Grund gehörten zum eigentlichen ASCII nur 126 Zeichen,…” Auch in [1] oder [2] ist von 128 characters die Rede. Aber wie dem auch sei: der UTF-8-Algorithmus ist wenn ich das recht sehe doch ein stupides Mapping von Unicode-Bit-Anordnungen auf 1 bis 4 Byte lange Folgen, egal ob da ein druckbares Character hintersteckt oder nicht. Zumindest steht nichts in der angegebenen Ref, dass bei Transformation von Textdatein rüber ins UTF-8 die Zeichen 0 oder 127 oder 128 bis 159 nicht übersetzt werden dürfen. Sind sie ausgeschlossen? Letztere stehen sogar in Unicodeblock Lateinisch-1, Ergänzung drin

Warum soll C2-C4 als UTF-8 (Start-)byte verboten sein? Nehmen wir das Yen-Zeichen U+00A5. Das müsste nach UTF-8 konvertiert C2A5 lauten. Oder das ä: wie in der Tabelle steht, wird es als C3 A4 dargestellt.

gruß von der Wassermaus (Diskussion) 02:29, 15. Nov. 2024 (CET)

@ „ASCII“: Das Problem ist die Jahreszahl.

• „ASCII“ ist ein Begriff und eine Standardisierung aus den 1960er Jahren.
• ASCII befasste sich mit dem Lochen von Papierstreifen (hatten wir uns nicht kürzlich via Byte getroffen)?
• ASCII kennt nur 126 Zeichen mit Bedeutung. NUL und DEL existieren nicht, egal wie oft vorkommend, ob null oder fünf. NUL ist ein Stück ungelochter Papierstreifen. DEL ist ein Stück Papierstreifen mit Löchern, wo man sich vertippt hatte und wo das Zeichen ausgeixt wurde, indem zusätzlich alle Positionen gelocht wurden. Damit gilt es als nicht vorhanden.
• Es gibt 128 Bit-Kombinationsmuster, aber nur 126 Bedeutungen in ASCII.

In späteren Jahrzehnten (ANSI, ISO 8859-1, schließlich Unicode) wurde der 127₁₀ mal diese, mal jene Bedeutung unterlegt, und 0 wurde zu einem Steuerzeichen, was auch immer es bedeuten möge.

• Der Übergang von ASCII zu seinen Nachfolgern wäre wie folgt zu formulieren:
  • 0 wird zu einem existenten Steuerzeichen
  • 1–126 behalten ihre Bedeutung
  • 127 wurde irgendwas, ging durcheinander, bedeutete Backspace und war damit auch Steuerzeichen, aber nicht druckbar.

Anfangsbits: War heute nacht etwas müde und habe auch momentan keine Zeit und Gelegenheit zu tiefem Reinwühlen, aber meiner Erinnerung nach gilt für die Bits von links im Oktett folgende Überlegung:

• 0 – 7-Bit-Zeichen; wird genau so genommen wie vorgefunden (Bits 2–8 ergeben den Zeichencode).
• 10 – Folge-Oktett in UTF-8 gemäß Mengenangabe in erstem Oktett.
• 110 – Erstes Oktett eines in zwei Oktetts kodierten Zeichens.
• 1110 – Erstes Oktett eines in drei Oktetts kodierten Zeichens (reicht bis U+FFFF).
• 11110 – [gefühlte Erinnerung] Erstes Oktett eines in vier Oktetts kodierten Zeichens (ab U+10000).
• Die restlichen Bits 3–8 bzw. ab 4 bzw. 5 bzw. 6 werden gesammelt, nebeneinander hingeschrieben und ergeben die Kodierung des gesuchten Zeichens.
  • 2–8 sind 7 Bit und ergeben 128 Kombinationen
  • 4–8 & 3–8 sind 5+6=11 Bits und ergeben 2048 Kombinationen
  • 5–8 & 3–8 & 3–8 sind 4+6+6=16 Bits und ergeben 65536 Kombinationen
  • 6–8 & 3–8 & 3–8 & 3–8 sind 3+6+6+6=21 Bits und ergeben 2097152 Kombinationen
• Soweit aus dem Handgelenk; wäre nachzurechnen, zu verifizieren und Erkenntnisse ggf. umseitig einzuarbeiten.

Aus den Anfangsbits ergeben sich Regeln für die an den Stellen möglichen Oktetts und deren numerische Interpretation, und umgekehrt Folgerungen für ungültiges UTF-8.

• So ist es eiiiigentlich auch unerlaubt, mehr Oktetts zu verwenden wenn weniger ausreichen würden.

Alle Zahlenangaben noch nicht in letzter enzyklopädischer Sicherheit.

Apopos Byte: hilfreich oder Linkspam?

VG --PerfektesChaos 10:19, 15. Nov. 2024 (CET)

Da ohnehin was umgestellt werden musste, habe ich das mit dem ASCII ersetzt durch "Die ersten 128 Unicodezeichen (U+0000 bis U+007F, entsprechend den Positionen 0–127 in allen ISO-8859-Varianten, auch als 7-Bit-ASCII-bezeichnet) ...". Ich hoffe, das ist jetzt unmissverständlich.

Was das andere angeht (Bitstruktur in UTF.8) -- ja, das ist so, aber ich denke so steht es schon gut verständlich drin. Ich habe es aber als Anlass genommen die Reihenfolge der Subkapitel umzustellen: Zuvor: 4.1 Algorithmus, 4.2 Folgerungen, 4.3 Zulässige Bytes und ihre Bedeutung, 4.4 Beispiele, Änderung: 4.2 hinter 4.4 geschoben

Ich hoffe, das war eine Verbesserung in deinem Sinne. Du weißt, du hast meine hohe Wertschätzung. Gruß von der Wassermaus (Diskussion) 18:11, 15. Nov. 2024 (CET)

Kompliment zurück; der Artikel wird deutlich besser.

Der Dekodierungsalgorithmus-muss ja aus den Daten die Informationen ziehen können, wann was womit passieren soll, wann eine Sequenz beendet ist.

Ich habe keine geistig ansporuchsvolle Zeit, mich da wieder reinzulesen, und schreibe aus der Erinnerung von Anfang des Jahrhunderts, als ich da mal intensiver zugange war.

Nebenbei ist es ein Unterschied zwischen einer eigentlich unerlaubten Bytefolge, die aber noch eindeutig interpretierbar ist, und einer absolut ungültigen Sequenz. Man kann ein M technisch auch in zwei oder vier Oktetts kodieren und die ganzen Nullen auch wieder auflösen, obwohl eigentlich unerwünscht, und bei der normalen Verarbeitung kritiklos hinnehmen. Nur wenn eine Validierung betrieben wird, mag der generierende Prozess beanstandet werden. Wenn Sicherheitsmechanismen sich auf UTF-8 statt den resultierenden Klartext verlassen, können die mit solch einer Verschleierung kinderleicht übertölpelt werden. Nur wenn ein Folgebyte nicht mit 10 beginnt, wäre es unauflösbar, oder 10 im Startbyte. Falls private oder unsinnige Zeichenwerte herauskommen, kann die Anwendung zwar ggf. nichts damit anfangen, aber da hat UTF-8 selbst keine Schuld dran.

VG --PerfektesChaos 09:41, 17. Nov. 2024 (CET)