UTF-8

topic - Kurzbeschreibung

Anhang

Siehe auch

• UTF-8

Dokumentation

RFC

RFC	Titel
0000

TMP

UTF-8 (Abkürzung für 8-Bit UCS Transformation Format, wobei UCS wiederum Universal Coded Character Set abkürzt) ist die am weitesten verbreitete Kodierung für Unicode-Zeichen (Unicode und UCS sind praktisch identisch). Die Kodierung wurde im September 1992 von Ken Thompson und Rob Pike bei Arbeiten am Plan-9-Betriebssystem festgelegt. Sie wurde zunächst im Rahmen von X/Open als FSS-UTF bezeichnet (filesystem safe UTF in Abgrenzung zu UTF-1, das diese Eigenschaft nicht hat), in den Folgejahren erfolgte im Rahmen der Standardisierung die Umbenennung auf die heute übliche Bezeichnung UTF-8.

UTF-8 ist in den ersten 128 Zeichen (Indizes 0–127) deckungsgleich mit ASCII und eignet sich mit in der Regel nur einem Byte Speicherbedarf für Zeichen vieler westlicher Sprachen, besonders für die Kodierung englischsprachiger Texte, die sich im Regelfall ohne Modifikation daher sogar mit nicht-UTF-8-fähigen Texteditoren ohne Beeinträchtigung bearbeiten lassen, was einen der Gründe für den Status als De-facto-Standard-Zeichenkodierung des Internet und damit verbundener Dokumenttypen darstellt. Im April 2023 verwendeten 97,9 % aller Websites UTF-8 und 98,8 % der Top 1000.

In anderen Sprachen ist der Speicherbedarf in Bytes pro Zeichen größer, wenn diese vom ASCII-Zeichensatz abweichen. Die deutschen Umlaute und das ß (scharfe S) erfordern zwei Bytes, machen aber nur einen kleinen Teil deutscher Texte aus. Ähnlich ist es bei anderen Sprachen wie beispielsweise Französisch, welche überwiegend die lateinischen Buchstaben aus dem ASCII-Raum verwenden. Griechische oder kyrillische Buchstaben belegen hingegen ebenfalls 2 Bytes, allerdings bestehen daraus praktisch die kompletten Texte abgesehen von Leerzeichen, Satzzeichen und Ziffern. Zeichen fernöstlicher Sprachen und von Sprachen aus dem afrikanischen Raum belegen sogar bis zu 4 Bytes je Zeichen.

Da die Verarbeitung von UTF-8 als Multibyte-Zeichenfolge wegen der notwendigen Analyse jedes Bytes im Vergleich zu Zeichenkodierungen mit fester Byteanzahl je Zeichen mehr Rechenaufwand und für bestimmte Sprachen auch mehr Speicherplatz erfordert, werden abhängig vom Einsatzszenario auch andere UTF-Kodierungen zur Abbildung von Unicode-Zeichensätzen verwendet. So führte Microsoft 1993 mit Windows NT 3.1 die Verwendung von UCS-2 ein, einer Zeichenkodierung, bei der jedes Zeichen fest zwei Bytes belegt. Da durch die spätere Weiterentwicklung von Unicode jedoch mit dieser Kodierung nicht mehr alle Zeichen darstellbar waren, erfolgte mit Windows 2000 ein neuerlicher Umstieg auf den kompatiblen Nachfolger UTF-16 Little Endian, womit man allerdings zugleich die Vorteile einer Kodierung mit fester Byteanzahl wieder verlor.

Allgemeines

Bei der UTF-8-Kodierung wird jedem Unicode-Zeichen eine speziell kodierte Zeichenkette variabler Länge zugeordnet. Dabei unterstützt UTF-8 Zeichenketten bis zu einer Länge von vier Byte, auf die sich – wie bei allen UTF-Formaten – alle Unicode-Zeichen abbilden lassen.

UTF-8 hat zentrale Bedeutung als globale Zeichenkodierung im Internet. Die Internet Engineering Task Force verlangt von allen neuen Internet-Kommunikationsprotokollen, dass die Zeichenkodierung deklariert wird und dass UTF-8 eine der unterstützten Kodierungen ist. Das Vorlage:Lang (IMC) empfiehlt, dass alle E-Mail-Programme UTF-8 darstellen und senden können.

Auch bei der in Webbrowsern angewendeten Auszeichnungssprache HTML hat sich UTF-8 zur Darstellung sprachspezifischer Zeichen durchgesetzt (über 97 % Anteil im Oktober 2021) und ersetzt dabei die vorher genutzten HTML-Entitäten.

Eigenschaften

• Multi-Byte-Zeichenkodierung (MBCS) ähnlich CP950/CP936/CP932 (chinesisch/japanisch), aber ohne die (damals wichtige und nützliche) Eigenschaft, dass doppelt breit dargestellte Zeichen zwei Bytes lang sind.
• Multibyte-Zeichenfolgen bestehen niemals aus 7-Bit-ASCII-Zeichen (ermöglicht Verarbeitung und Parsen mit üblichen 7-Bit-Zeichenkonstanten).
• Im Vergleich zu UTF-16 relativ kompakt bei hohem Anteil an ASCII-Zeichen, jedoch platzintensiver bei Zeichen zwischen U+0800 und U+FFFF (v. a. asiatische Sprachen, vgl. Liste der Unicodeblöcke)
• Sortierbarkeit bleibt erhalten, zwei UTF-8-Zeichenketten haben dieselbe Sortierreihenfolge wie zwei unkodierte Unicode-Zeichenketten
• In beiden Richtungen durchsuchbar (bei bisherigen MBCS nicht der Fall)
• Einfache Transkodierungsfunktion (zudem leicht Hardware-implementierbar)
• Reichlich Kodierungsreserve (falls sich am Unicode-Standard doch noch etwas ändert)
• selbstsynchronisierend

Normung

UTF-8 ist von der IETF, dem Unicode-Konsortium und der ISO gegenwärtig identisch definiert in den Normdokumenten:

• RFC 3629 / STD 63 (2003)RFC 3629 / STD 63
• The Unicode Standard, Version 4.0, §3.9–§3.10 (2003)
• ISO/IEC 10646-1:2000 Annex D (2000)

Diese lösen ältere, teilweise abweichende Definitionen ab, die teilweise noch von älterer Software benutzt werden:

• ISO/IEC 10646-1:1993 Amendment 2 / Annex R (1996)
• The Unicode Standard, Version 2.0, Appendix A (1996)
• RFC 2044 (1996)
• RFC 2279 (1998)
• The Unicode Standard, Version 3.0, §2.3 (2000) und Corrigendum #1: UTF-8 Shortest Form (2000)
• Unicode Standard Annex #27: Unicode 3.1 (2001)

Kodierung

Algorithmus

Unicode-Zeichen mit Werten aus dem Bereich von 0 bis 127 (0 bis 7F hexadezimal) werden in der UTF-8-Kodierung als ein Byte mit dem gleichen Wert wiedergegeben. Daher sind alle Daten, für die ausschließlich ASCII-Zeichen verwendet werden, in beiden Darstellungen identisch.

Unicode-Zeichen größer als 127 werden in der UTF-8-Kodierung zu 2 bis 4 Byte langen Bytefolgen.

Unicode-Bereich (hex)	UTF-8-Kodierung (binär, Schema)	Erläuterungen	Anzahl der codierbaren Zeichen
0000 0000 – 0000 007F	0 a6a5a4a3a2a1a0	In diesem Bereich entspricht UTF-8 genau dem ASCII-Code: Das höchstwertige Bit ist 0, die restlichen Bits a6…0 kodieren das ASCII-Zeichen.	Vorlage:027	Vorlage:0128
0000 0080 – 0000 07FF	1 1 0 b2b1b0a7a6 1 0 a5a4a3a2a1a0	Das Startbyte beginnt immer mit 11, Folgebytes mit 10. c4…0b7…0a7…0 steht für das zu kodierende max. 21 Bit lange Zeichen. Die Anzahl der Einsen 1 vor der ersten Null 0 im ersten Byte ist gleich der Gesamtzahl der Bytes für das Zeichen.	Vorlage:0211 − 27 (211)	Vorlage:01920 (2048)
0000 0800 – 0000 FFFF	1 1 1 0 b7b6b5b4 1 0 b3b2b1b0a7a6 1 0 a5a4a3a2a1a0		Vorlage:0216 − 211 (216)	Vorlage:063.488 (65.536)
0001 0000 – 0010 FFFF	1 1 1 1 0 c4c3c2 1 0 c1c0b7b6b5b4 1 0 b3b2b1b0a7a6 1 0 a5a4a3a2a1a0		Vorlage:0220 (221)	Vorlage:01.048.576 (2.097.152)

Anmerkungen

Der Algorithmus lässt theoretisch längere Bytesequenzen zu. Ursprünglich wurde eine Folge aus einem ersten Byte mit bis zu 1111110x (FC_hex und FD_hex) und fünf Folge-Bytes der Form 10xxxxxx definiert, in denen so insgesamt 31 Bit für den enthaltenen Unicode-Wert kodiert werden konnten.

In seiner Verwendung als UTF-Kodierung ist er aber auf den gemeinsamen Coderaum aller Unicode-Kodierungen beschränkt, also von 0 bis 0010 FFFF (1.114.112 Möglichkeiten) und weist maximal vier Bytes lange Byteketten auf. Der damit verfügbare Wertebereich für den Zeichencode wird letztlich nicht vollständig benutzt. Entsprechend lange Bytefolgen und große Werte gelten heute als unzulässige Codes und sind entsprechend zu behandeln.

Das erste Byte eines UTF-8-kodierten Zeichens nennt man dabei Start-Byte, weitere Bytes heißen Folge-Bytes. Start-Bytes beginnen also immer mit 0 oder 11, Folge-Bytes immer mit 10.

• Ist das höchste Bit des ersten Bytes 0, handelt es sich um ein ASCII-Zeichen, da ASCII eine 7-Bit-Kodierung ist und die ersten 128 Unicode-Zeichen den ASCII-Zeichen entsprechen. Damit sind alle ASCII-Zeichenketten automatisch aufwärtskompatibel zu UTF-8.
• Ist das höchste Bit des ersten Bytes 1, handelt es sich um ein Mehrbytezeichen, also ein Unicode-Zeichen mit einer Zeichennummer größer als 127.
• Sind die höchsten beiden Bits eines Bytes 11, handelt es sich um das Startbyte eines Mehrbytezeichens, sind sie 10, um ein Folgebyte.
• Die lexikalische Ordnung nach Bytewerten entspricht der lexikalischen Ordnung nach Zeichennummern, da höhere Zeichennummern mit entsprechend mehr 1-Bits im Start-Byte kodiert werden.
• Bei den Startbytes von Mehrbyte-Zeichen gibt die Anzahl der höchsten 1-Bits die gesamte Bytezahl des als Mehrbyte-Zeichen kodierten Unicode-Zeichens an. Anders interpretiert, die Anzahl der 1-Bits links des höchsten 0-Bits entspricht der Anzahl an Folgebytes plus eins, z. B. 1110xxxx 10xxxxxx 10xxxxxx = drei Bits vor dem höchsten 0-Bit = drei Bytes insgesamt, zwei Bits nach dem höchsten 1-Bit vor dem höchsten 0-Bit = zwei Folgebytes.
• Startbytes (0… oder 11…) und Folgebytes (10…) lassen sich eindeutig voneinander unterscheiden. Somit kann ein Bytestrom auch in der Mitte gelesen werden, ohne dass es Probleme mit der Dekodierung gibt, was insbesondere bei der Wiederherstellung defekter Daten wichtig ist. Bytes beginnend mit 10 werden einfach übersprungen, bis 0… oder 11… erkannt wird. Dass Startbytes und Folgebytes eindeutig voneinander unterschieden sind, ist ein Vorteil der UTF-8-Kodierung. Bei Kodierungen ohne diese Eigenschaft ist das Lesen eines Datenstroms, dessen Beginn unbekannt ist, unter Umständen nicht möglich.

Zu beachten:

• Das gleiche Zeichen kann theoretisch auf unterschiedliche Weise kodiert werden (Zum Beispiel „a“ als 01100001 oder fälschlich als 11000001 10100001). Jedoch ist nur die jeweils kürzestmögliche Kodierung erlaubt. Dieser Umstand hat mehrfach zu Problemen geführt, wenn Programme bei ungültigen Kodierungen abstürzen, diese als gültig interpretieren oder einfach ignorieren. Die Kombinationen der letzten beiden Verhaltensweisen führte z. B. zu Firewalls, die gefährliche Inhalte auf Grund der ungültigen Kodierung nicht erkennen, wo jedoch der zu schützende Client diese Kodierungen als gültig interpretiert und dadurch gefährdet ist.
• Bei mehreren Bytes für ein Zeichen werden die Bits bündig angeordnet – das niedrigste Bit (least significant bit) des Unicode-Zeichens steht also immer im niedrigsten Bit des letzten UTF-8-Bytes.
• Ursprünglich gab es auch Kodierungen mit mehr als vier Oktetten (bis zu sechs), diese sind jedoch ausgeschlossen worden, da es in Unicode keine korrespondierenden Zeichen gibt und ISO 10646 in seinem möglichen Zeichenumfang an Unicode angeglichen wurde.
• Für alle auf dem lateinischen Alphabet basierenden Schriften ist UTF-8 eine besonders platzsparende Methode zur Abbildung von Unicode-Zeichen.
• Die Unicode-Bereiche U+D800 bis U+DBFF und U+DC00 bis U+DFFF sind ausdrücklich keine Zeichen, sondern dienen nur in UTF-16 zur Kodierung von Zeichen außerhalb der Basic Multilingual Plane, sie wurden früher als Low und High surrogates bezeichnet. Folglich sind Bytefolgen, die diesen Bereichen entsprechen, kein gültiges UTF-8. Zum Beispiel wird U+10400 in UTF-16 als D801,DC00 dargestellt, sollte in UTF-8 aber als F0,90,90,80 und nicht als ED,A0,81,ED,B0,80 ausgedrückt werden. Java unterstützt dies seit der Version 1.5. Aufgrund der weiten Verbreitung der falschen Kodierung, insbesondere auch in Datenbanken, wurde diese Kodierung nachträglich als CESU-8 normiert.
• In UTF-8, UTF-16 und UTF-32 ist jeweils der gesamte Wertebereich von Unicode kodiert.
• Kann eine Byte-Sequenz nicht als UTF-8-Zeichen interpretiert werden, so wird es beim Lesen in der Regel durch das Unicode-Replacement-Zeichen U+FFFD bzw. EF,BF,BD ersetzt.

Zulässige Bytes und ihre Bedeutung

Durch die Kodierungsregel von UTF-8 sind bestimmte Bytewerte nicht zulässig. In nachfolgender Tabelle sind alle 256 Möglichkeiten aufgeführt und deren Verwendung bzw. Gültigkeit angegeben. Bytewerte in roten Zeilen sind unzulässig, grün beschreibt zulässige Bytewerte, welche unmittelbar ein Zeichen darstellen. In blau sind jene Werte hinterlegt, welche den Start einer Sequenz von zwei oder mehr Byte beginnen und als Sequenz mit den Bytewerten aus orange hinterlegten Zeilen fortgesetzt werden.

UTF-8 Wertebereich			Bedeutung
Binär	Hexadezimal	Dezimal
00000000–01111111	00–7F	0–127	Ein Byte lange Zeichen, deckungsgleich mit US-ASCII
10000000–10111111	80–BF	128–191	Zweites, drittes oder viertes Byte einer Bytesequenz
11000000–11000001	C0–C1	192–193	Start einer 2 Byte langen Sequenz, welche den Codebereich aus 0 bis 127 abbildet, unzulässig
11000010–11011111	C2–DF	194–223	Start einer 2 Byte langen Sequenz (U+0080 … U+07FF) Startbyte abgedeckter Codebereich C2 U+0080 … U+00BF C3 U+00C0 … U+00FF C4 U+0100 … U+013F C5 U+0140 … U+017F C6 U+0180 … U+01BF C7 U+01C0 … U+01FF C8 U+0200 … U+023F C9 U+0240 … U+027F CA U+0280 … U+02BF CB U+02C0 … U+02FF CC U+0300 … U+033F CD U+0340 … U+027F CE U+0380 … U+03BF CF U+03C0 … U+03FF D0 U+0400 … U+043F D1 U+0440 … U+047F D2 U+0480 … U+04BF D3 U+04C0 … U+04FF D4 U+0500 … U+053F D5 U+0540 … U+057F D6 U+0580 … U+05BF D7 U+05C0 … U+05FF D8 U+0600 … U+063F D9 U+0640 … U+067F DA U+0680 … U+06BF DB U+06C0 … U+06FF DC U+0700 … U+073F DD U+0740 … U+077F DE U+0780 … U+07BF DF U+07C0 … U+07FF
11100000–11101111	E0–EF	224–239	Start einer 3 Byte langen Sequenz (U+0800 … U+FFFF) Startbyte abgedeckter Codebereich Anmerkung E0 U+0800 … U+0FFF 2. Byte: 80 … 9F unzulässige Kodierung für U+0000 … U+07FF A0 … BF U+0800 … U+0FFF E1 U+1000 … U+1FFF E2 U+2000 … U+2FFF E3 U+3000 … U+3FFF E4 U+4000 … U+4FFF E5 U+5000 … U+5FFF E6 U+6000 … U+6FFF E7 U+7000 … U+7FFF E8 U+8000 … U+8FFF E9 U+9000 … U+9FFF EA U+A000 … U+AFFF EB U+B000 … U+BFFF EC U+C000 … U+CFFF ED U+D000 … U+DFFF 2. Byte: 80 … 9F U+D000 … U+D7FF A0 … BF unzulässig! Siehe CESU-8 EE U+E000 … U+EFFF (Private Use Zone) EF U+F000 … U+FFFF (Private Use Zone, wenn 2. Byte im Bereich 80 … A3)
11110000–11110100	F0–F4	240–244	Start einer 4 Byte langen Sequenz (Inklusive der ungültigen Codebereiche von 110000 bis 13FFFF) Startbyte abgedeckter Codebereich F0 U+10000 … U+3FFFF (2. Byte muss aus Bereich 90 … BF sein, wobei B0…BF der bisher ungenutzten Ebene 3 entspricht) F1 U+40000 … U+7FFFF (derzeit keine gültigen Zeichen in diesem Bereich) F2 U+80000 … U+BFFFF (derzeit keine gültigen Zeichen in diesem Bereich) F3 U+C0000 … U+FFFFF F4 U+100000 … U+10FFFF (2. Byte muss aus Bereich 80 … 8F sein!)
11110101–11110111	F5–F7	245–247	Ungültig nach RFC 3629: Start einer 4 Byte langen Sequenz für Codebereich über 140000
11111000–11111011	F8–FB	248–251	Ungültig nach RFC 3629: Start einer 5 Byte langen Sequenz
11111100–11111101	FC–FD	252–253	Ungültig nach RFC 3629: Start einer 6 Byte langen Sequenz
11111110–11111111	FE–FF	254–255	Ungültig. In der ursprünglichen UTF-8-Spezifikation nicht definiert.

Code	…0	…1	…2	…3	…4	…5	…6	…7	…8	…9	…A	…B	…C	…D	…E	…F
0…	NUL	SOH	STX	ETX	EOT	ENQ	ACK	BEL	BS	HT	LF	VT	FF	CR	SO	SI
1…	DLE	DC1	DC2	DC3	DC4	NAK	SYN	ETB	CAN	EM	SUB	ESC	FS	GS	RS	US
2…	SP	!	"	#	$	%	&	'	(	)	*	+	,	-	.	/
3…	0	1	2	3	4	5	6	7	8	9	:	;	<	=	>	?
4…	@	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O
5…	P	Q	R	S	T	U	V	W	X	Y	Z	[	\	]	^	_
6…	`	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o
7…	p	q	r	s	t	u	v	w	x	y	z	{	|	}	~	DEL
8…	Zweites, drittes oder viertes Byte einer Bytesequenz
9…
A…
B…
C…			Start einer 2 Byte langen Sequenz
D…
E…	Start einer 3 Byte langen Sequenz
F…	Start einer 4 Byte langen Sequenz
	…0	…1	…2	…3	…4	…5	…6	…7	…8	…9	…A	…B	…C	…D	…E	…F

Beispiele

In folgender Tabelle sind einige Kodierungsbeispiele für UTF-8 angegeben:

Beispiele für UTF-8 Kodierungen

Zeichen	Unicode	Unicode binär	UTF-8 binär	UTF-8 hexadezimal
Buchstabe y	U+0079	00000000 01111001	01111001	79
Buchstabe ä	U+00E4	00000000 11100100	11000011 10100100	C3 A4
Zeichen für eingetragene Marke ®	U+00AE	00000000 10101110	11000010 10101110	C2 AE
Eurozeichen €	U+20AC	00100000 10101100	11100010 10000010 10101100	E2 82 AC
Violinschlüssel 𝄞	U+1D11E	00000001 11010001 00011110	11110000 10011101 10000100 10011110	F0 9D 84 9E

Das letzte Beispiel liegt außerhalb des ursprünglich in Unicode (unter Version 2.0) enthaltenen Codebereiches (16 Bit), der in der aktuellen Unicode-Version als BMP-Bereich (Ebene 0) enthalten ist. Da derzeit viele Schriftarten diese neuen Unicode-Bereiche noch nicht enthalten, können die dort enthaltenen Zeichen auf vielen Plattformen nicht korrekt dargestellt werden. Stattdessen wird ein Ersatzzeichen dargestellt, welches als Platzhalter dient.

Darstellung in Editoren

Byte Order Mark

Obwohl bei UTF-8 aufgrund der Art der Kodierung grundsätzlich nicht das Problem unterschiedlicher Bytereihenfolgen auftreten kann, fügen einige Programme eine Byte Order Mark (BOM, Vorlage:DeS) am Dateianfang von UTF-8-Dateien ein. Die BOM besteht aus der Bytesequenz EF BB BF, die in nicht UTF-8-fähigen Texteditoren und Browsern meist als ISO-8859-1-Zeichenfolge  erscheint und für Kompatibilitätsprobleme verantwortlich sein kann.

Nicht im Unicodeblock Basis-Lateinisch enthaltene Zeichen

Die Buchstaben des lateinischen Grundalphabets sowie die wichtigsten Satzzeichen werden in UTF-8 und ISO-8859-* identisch angezeigt. Probleme mit der falsch gewählten Zeichencodierung treten bei den anderen Zeichen auf, beispielsweise bei Umlauten. In deutschsprachigen Texten treten diese Zeichen jedoch nur vereinzelt auf, sodass der Text zwar stark entstellt wirkt, aber meist noch lesbar bleibt.

In UTF-8 bestehen die Umlaute des deutschen Alphabets (sofern sie in der Normalform NFC vorliegen, also als precomposed character) und das ß aus zwei Bytes; nach ISO 8859 wird jedes Zeichen als 1 Byte codiert und jedes Byte beim Lesen in ein Zeichen transformiert. Das in der UTF-8-Kodierung dieser Buchstaben gemeinsame erste Byte C3_hex wird, wie der Tabelle zu entnehmen ist, jeweils unterschiedlich decodiert, ebenso das weitere Byte der Codierung von äöü, dagegen wird bei ÄÖÜß das zweite Byte nicht oder mit dem gleichen Fehler-Zeichen dargestellt, weil 7F_hex bis 9F_hex in ISO 8859 nicht definiert sind, was die Lesbarkeit des Textes zusätzlich erschwert.

Bei der Interpretation eines in ISO-8859-codierten Textes als UTF-8 führen die Buchstaben öü zur Anzeige eines Ersetzungszeichens, weil der entsprechende Byte-Wert, wie der Tabelle unten zu entnehmen ist, nicht definiert ist. Bei den Buchstaben äöüß wird ein Start-Byte angenommen und versucht, das nächste Byte als Folgebyte gemeinsam als ein Zeichen zu interpretieren. Das scheitert häufig, weil die Codierungen der meisten Buchstaben keine gültigen Folgebytes sind. Bei einem ä wird sogar versucht, die nächsten beiden Bytes als Folgebyte zu interpretieren, was aus denselben Gründen regelmäßig scheitert. Je nach Programmierung des anzeigenden Programms verschwinden womöglich entsprechend viele Buchstaben aus dem Text.

UTF-8-Text mit anderem Encoding geöffnet:

UTF-8			ISO-8859-1	ISO-8859-15	UTF16
U+00E4	C3A4hex	ä	ä	À	쎤
U+00F6	C3B6hex	ö	ö	ö	쎶
U+00FC	C3BChex	ü	ü	ÃŒ	쎼
U+00DF	C39Fhex	ß	ÃVorlage:Char	ÃVorlage:Char	쎟
U+00C4	C384hex	Ä	ÃVorlage:Char	ÃVorlage:Char	쎄
U+00D6	C396hex	Ö	ÃVorlage:Char	ÃVorlage:Char	쎖
U+00DC	C39Chex	Ü	ÃVorlage:Char	ÃVorlage:Char	쎜

ISO-Latin-				1	2	3	4	5	6	7	8	9	10	UTF-8
ISO/IEC 8859-				1	2	3	4	9	10	13	14	15	16
Bin	Oct	Dec	Hex
1010 0100	244	164	A4	¤				¤	Ī	¤	Ċ	€		Folgebyte	+24
1011 0110	266	182	B6	¶	ś	ĥ	ļ	¶	ķ	¶				Folgebyte	+36
1011 1100	274	188	BC	¼	ź	ĵ	ŧ	¼	ž	¼	ỳ	Œ		Folgebyte	+3C
1100 0011	303	195	C3	Ã	Ă		Ã			Ć	Ã		Ă	Startbyte	Latin 0080
1100 0100	304	196	C4	Ä										Startbyte	Latin 00C0
1101 0110	326	214	D6	Ö										Startbyte	Hebrew 0580
1101 1100	334	220	DC	Ü										Startbyte	Syriac 0700
1101 1111	337	223	DF	ß										Startbyte	N’Ko 07C0
1110 0100	344	228	E4	ä										Startbyte	Kana 3000
1111 0110	366	246	F6	ö										unzulässig
1111 1100	374	252	FC	ü										unzulässig

Ein Beispiel für das Wort Höhe:

UTF-8-Text in ISO-8859-1/9/13-16-Umgebung

Höhe → Höhe.

ISO-8859-1-Text in UTF-8-Umgebung

Höhe → H�he bzw. Fehlermeldung mit Abbruch. Ein Byte mit dem Hexadezimalwert F6 ist in UTF-8 nicht zulässig. Es ist üblich, für nicht konvertierbare Zeichen das Ersetzungszeichen (U+FFFD) einzufügen.

Weblinks

• Vorlage:RFC-Internet
• UTF-8-Codetabelle mit Unicode-Zeichen – UTF-8-Kodierung aller Unicode-Positionen aus der BMP mit Zusatzinformationen und benannten HTML-Entitäten
• Dieter Pawelczak: Kodierung von Zeichenfolgen. Beispiel UCS/UTF8. Universität der Bundeswehr München, Institut für Software Engineering.
• Pavel Radzivilovsky, Yakov Galka, Slava Novgorodov: UTF-8 Everywhere. Manifesto. (englisch)