Siehe auch Woher weiß eine Datei mit chinesischen Zeichen, wie viele Bytes pro Zeichen verwendet werden sollen? - Ohne Zweifel gibt es andere SO-Fragen, die ebenfalls helfen würden.
In UTF-8 erhalten Sie die folgenden Arten von Bytes:
Binary Hex Comments
0xxxxxxx 0x00..0x7F Only byte of a 1-byte character encoding
10xxxxxx 0x80..0xBF Continuation bytes (1-3 continuation bytes)
110xxxxx 0xC0..0xDF First byte of a 2-byte character encoding
1110xxxx 0xE0..0xEF First byte of a 3-byte character encoding
11110xxx 0xF0..0xF4 First byte of a 4-byte character encoding
(Die letzte Zeile sieht so aus, als ob sie 0xF0..0xF7 lauten sollte. Der 21-Bit-Bereich von Unicode (U + 0000 - U + 10FFFF) bedeutet jedoch, dass der maximal gültige Wert 0xF4 ist. Werte 0xF5..0xF7 können in nicht auftreten gültiges UTF-8.)
Wenn Sie prüfen, ob eine bestimmte Folge von Bytes für UTF-8 gültig ist, müssen Sie über Folgendes nachdenken:
- Fortsetzung Bytes erscheinen, wo nicht erwartet
- Nichtfortsetzungsbytes werden dort angezeigt, wo ein Fortsetzungsbyte erwartet wird
- Unvollständige Zeichen am Ende der Zeichenfolge (Variation des 'Fortsetzungsbytes erwartet')
- Nicht minimale Sequenzen
- UTF-16-Ersatz
In gültigem UTF-8 können die Bytes 0xF5..0xFF nicht vorkommen.
Nicht minimale Sequenzen
Für einige Zeichen gibt es mehrere mögliche Darstellungen. Beispielsweise könnte das Unicode-Zeichen U + 0000 (ASCII NUL) dargestellt werden durch:
0x00
0xC0 0x80
0xE0 0x80 0x80
0xF0 0x80 0x80 0x80
Der Unicode-Standard besagt jedoch eindeutig, dass die letzten drei Alternativen nicht akzeptabel sind, da sie nicht minimal sind. Es kommt daher vor, dass die Bytes 0xC0 und 0xC1 niemals in einem gültigen UTF-8 erscheinen können, da die einzigen Zeichen, die von diesen codiert werden könnten, minimal als Einzelbytezeichen im Bereich 0x00..0x7F codiert sind.
UTF-16-Ersatz
Innerhalb der Basic Multi-Lingual Plane (BMP) sind die Unicode-Werte U + D800 - U + DFFF für UTF-16-Surrogate reserviert und können nicht in gültigem UTF-8 codiert erscheinen. Wenn sie in UTF-8 gültig wären (was ich nicht betone), würden die Surrogate codiert:
- U + D800 - 0xED 0xA0 0x80 (kleinster hoher Ersatz)
- U + DBFF - 0xED 0xAF 0xBF (größter hoher Ersatz)
- U + DC00 - 0xED 0xB0 0x80 (kleinster niedriger Ersatz)
- U + DFFF - 0xED 0xBF 0xBF (größter niedriger Ersatz)
Schlechte Daten
Daher sollten Ihre BAD-Daten Proben enthalten, die gegen diese verschiedenen Vorschriften verstoßen.
- Fortsetzungsbyte, dem keiner der Anfangsbytewerte vorangestellt ist
- Anfangsbytes mit mehreren Zeichen, gefolgt von nicht genügend Fortsetzungsbytes
- Nicht minimale Multi-Byte-Zeichen
- UTF-16-Ersatz
- Ungültige Bytes (0xC0, 0xC1, 0xF5..0xFF).
Beachten Sie, dass ein Byte-Order-Mark (BOM) U + FEFF, auch bekannt als No-Break-Space mit Nullbreite (ZWNBSP), in UTF-8 nicht unverschlüsselt erscheinen kann - die Bytes 0xFF und 0xFE sind in gültigem UTF-8 nicht zulässig. Ein codierter ZWNBSP kann in einer UTF-8-Datei als 0xEF 0xBB 0xBF angezeigt werden, aber die Stückliste ist in UTF-8 völlig überflüssig.
Es gibt auch einige Nicht- Zeichen in Unicode. U + FFFE und U + FFFF sind zwei solche Nichtzeichen (und die letzten beiden Codepunkte in jeder Ebene, U + 1FFFE, U + 1FFFF, U + 2FFFE, U + 2FFFF, ... U + 10FFFE, U + 10FFFF sind andere ). Diese sollten normalerweise nicht in Unicode-Daten für den Datenaustausch enthalten sein, sondern können im privaten Gebrauch angezeigt werden. Unter dem Unicode-FAQ-Link finden Sie viele schmutzige Details, einschließlich der ziemlich komplexen Geschichte von Nicht-Zeichen in Unicode. ( Berichtigung Nr. 9: Klarstellung über Nichtzeichen , die im Januar 2013 veröffentlicht wurde, macht das, was der Titel andeutet - verdeutlicht die Bedeutung von Nichtzeichen .)