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.

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 oder 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)

Unklare Formulierung: Wenig mehr als ein Byte pro Zeichen

"Die ersten 128 Unicodezeichen (...) werden in UTF-8 deckungsgleich durch nur ein Byte dargestellt. Dies umfasst unter anderem die Ziffern und die Groß- und Kleinbuchstaben des lateinischen Grundalphabets. Zusätzliche Zeichen in europäischen Sprachen mit lateinischer Schrift, z. B. ä, ß, é, ł und Š, werden durch zwei Byte dargestellt. Texte in solchen Sprachen benötigen daher nur wenig mehr als ein Byte pro Zeichen."

Ist mit dem letzten Satz die durchschnittliche Byte-Anzahl pro Text in einer solchen Sprache gemeint? Die Formulierung ist so unklar, die könnte man entfernen. --Reztib42 (Diskussion) 16:57, 5. Mai 2026 (CEST)

Wenn der gesamte deutschsprachige Text 765 Zeichen hat, dann benötigt er womöglich 789 Bytes.

Ein englischsprachiger Text mit 654 Zeichen benötigt vielleicht auch 654 Bytes.

In Thai mit 547 Zeichen werden jedoch 1654 Bytes erforderlich.

Heißt:

• Texte mit lateinischer Grundschrift erfordern eines oder durchschnittlich etwas mehr als ein Byte pro Zeichen.
• Nicht-lateinische Texte brauchen ein Mehrfaches.

Diese Überlegung darzustellen ist durchaus sinnvoll und sollte nicht entfallen.

Man kann auch einheitlich jedes Zeichen mit vier Bytes kodieren; das kostet dann reichlich gegenüber UTF.

VG --PerfektesChaos 17:25, 5. Mai 2026 (CEST)

So isses. Vielleicht könnte man in den letzten Satz irgendwo „im Mittel“, „im Durchnitt“ oder so was einbauen - so es denn wirklich missver Ist. — Wassermaus (Diskussion) 17:41, 5. Mai 2026 (CEST)