Zeichencodierung/Bytes und Buchstaben

leicht

20min

• Grundlagen
• HTML-Kenntnisse

Computer kennen im Prinzip keine Buchstaben oder Zeichen, sondern nur Bytes. Bytes sind Zahlen im Bereich von 0 bis 255. Um mit Zahlen einen Text darstellen zu können, benötigt der Computer eine Zuordnungstabelle, in der verzeichnet ist, welche Zahl für welchen Buchstaben stehen soll. Diese Tabelle ist in beide Richtungen eindeutig, aus einem Buchstaben wird also exakt eine Zahl, und aus dieser Zahl wird umgekehrt wieder exakt dieser Buchstabe.

ASCII

Grundsätzlich ist die Zuordnung der Zahl zum Buchstaben vollkommen willkürlich wählbar, und daher entwickelten sich in der Anfangszeit der Computer in Amerika mehrere unterschiedliche Zuordnungsvorschriften. Von diesen haben sich zwei heute gehalten: der American Standard Code for Information Interchange (ASCII) und der Extended Binary Coded Decimals Interchange Code (EBCDIC). Der Unterschied zwischen den beiden lässt sich an einem Beispiel verdeutlichen: Im ASCII wird das große A dem Bytewert 65 zugeordnet, und das kleine a dem Bytewert 97. Im EBCDIC erhält das kleine a den Wert 129, das große A den Wert 193.

Drückt man also eine Taste der Tastatur, erkennt der Computer, welche Taste gedrückt wurde, und ordnet ihr aufgrund des konfigurierten Tastaturlayouts den Bytewert des Buchstabens zu, der sich dahinter verbirgt. Bei der Ausgabe des Buchstabens auf dem Bildschirm wird der Bytewert umgewandelt in die Anweisung, wie der entsprechenden Buchstabe zu malen ist, und er erscheint dann auf dem Bildschirm. Wie der Buchstabe konkret aussieht, entscheidet dabei die Malanweisung der Schriftart. Ändert man die Schriftart, wird eine neue Malanweisung verwendet, aber die Bytewerte der Zeichen bleiben identisch.

ASCII-Tabelle

Dezimal		0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
	Hex.	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
32	20		!	"	#	$	%	&	'	(	)	*	+	,	-	.	/
48	30	0	1	2	3	4	5	6	7	8	9	:	;	<	=	>	?
64	40	@	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O
80	50	P	Q	R	S	T	U	V	W	X	Y	Z	[	\	]	^	_
96	60	`	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o
112	70	p	q	r	s	t	u	v	w	x	y	z	{	|	}	~

Diese betagten Codes wie ASCII und EBCDIC haben jedoch eine Schwäche: Mit ihnen lassen sich, da sie einem Zeichen ein Byte zuordnen, maximal 256 verschiedene Zeichen darstellen. Dieser Zeichenvorrat reicht gerade für das lateinische Alphabet und einige zusätzliche Zeichen. Als die Codes in den 1960ern entstanden, war das für die englisch sprechenden Amerikaner ausreichend. Außerdem mussten technische Beschränkungen ebenfalls berücksichtigt werden. Aber es gibt weltweit noch viele andere Sprachen und Alphabete und somit weit mehr als 256 unterschiedliche Zeichen. Als ASCII entstand, kam man – zumindest in der Datenverarbeitung im englischen Sprachraum – mit 128 verschiedenen Zeichen aus, es reichten daher 7 Bit für die Codierung des Zeichensatzes. Das 8. Bit eines Bytes wurde nicht benutzt oder für verschiedene andere Zwecke benutzt, beispielsweise als Paritätsbit oder für Erweiterungen von ASCII wie ISO-8859-15 oder UTF-8. Nebenstehend ist die ASCII-Codetabelle dargestellt, soweit es sich um druckbare Zeichen handelt (die Zeichen von 0 bis 31 sowie 127 sind Steuerzeichen). Um den ASCII-Wert eines Zeichens zu ermitteln, addieren Sie einfach den Zeilen- und Spaltenwert – entweder in dezimaler oder hexadezimaler Form. So hat z. B. der Großbuchstabe „K“ den dezimalen Wert „75“ (=64+11), bzw. den hexadezimalen Wert „4B“ (=40+B).

Die erste, nicht hundertprozentig befriedigende Lösung für dieses Problem bestand darin, für andere Alphabete neue Zuordnungen zu erstellen. Dies bedeutete bei der interkulturellen Kommunikation aber einen kleinen Mehraufwand. Wollte beispielsweise ein Russe einem Amerikaner einen russischen Text zukommen lassen, so reichte es nicht, einfach die Textdatei weiterzugeben. Der Absender musste zusätzlich die für das kyrillische Alphabet verwendete Codierung angeben. Mit der amerikanischen Codierung würde der Computer des Empfängers die Bytes als lateinische Buchstaben interpretieren und somit einen sinnlosen Buchstabensalat produzieren.

ISO-8859-Familie

 Win-1252  und ISO-8859-1

Dezimal		0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
	Hex.	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
128	80	€		‚	ƒ	„	…	†	‡	ˆ	‰	Š	‹	Œ		Ž
144	90		‘	’	“	”	•	–	—	˜	™	š	›	œ		ž	Ÿ
160	A0		¡	¢	£	¤	¥	¦	§	¨	©	ª	«	¬		®	¯
176	B0	°	±	²	³	´	µ	¶	·	¸	¹	º	»	¼	½	¾	¿
192	C0	À	Á	Â	Ã	Ä	Å	Æ	Ç	È	É	Ê	Ë	Ì	Í	Î	Ï
208	D0	Ð	Ñ	Ò	Ó	Ô	Õ	Ö	×	Ø	Ù	Ú	Û	Ü	Ý	Þ	ß
224	E0	à	á	â	ã	ä	å	æ	ç	è	é	ê	ë	ì	í	î	ï
240	F0	ð	ñ	ò	ó	ô	õ	ö	÷	ø	ù	ú	û	ü	ý	þ	ÿ
Farben: nicht belegt, nicht sichtbar

Im westeuropäischen Sprachraum verbreiteten sich insbesondere zwei Codierungen aus der sogenannten ISO-8859-Familie: ISO-8859-1 und ISO-8859-15. Den Codierungen der ISO-8859-Familie ist gemeinsam, dass sie nur 256 verschiedene Zeichen codieren können, da ein Zeichen immer mit einem Byte codiert wird. Jede dieser Codetabellen versucht, möglichst alle Zeichen möglichst vieler Schriften zu speichern. Sie verwenden alle die ASCII-Codetabelle für die Zeichen 0 bis 127 und definieren zusätzlich die Werte 160 bis 255. Sofern in diesem Bereich das gleiche Zeichen in verschiedenen Schriften vorkommt, überlappen sie sich zumeist.

Eine weitere in Westeuropa häufiger verwendete Codierung ist Windows-1252, die auf ISO-8859-1 aufbaut und zusätzlich die Zeichen 128 bis 159 verwendet. Da sich auf diesen Positionen bei ISO-8859-1 keine für HTML relevanten Zeichen befinden und diese Codierung oft mit Windows-1252 verwechselt wird, verwenden Browser auch dann Windows-1252, wenn das Dokument als ISO-8859-1 deklariert ist.

Es blieb aber immer das Problem, dass viele Zeichen nicht in allen Codierungen vorhanden waren. Das Euro-Zeichen (€) fehlt z. B. in den meisten ISO-Codierungen. HTML 3.2 versuchte, das Problem zu lösen, indem für ISO-8859-1 und einige andere Zeichen in anderen Codierungen (z. B. griechische Buchstaben) Zeichen-Entities definiert wurden. Der Buchstabe „Ä“ kann z. B. auch als „Ä“ (= A mit Umlaut) angegeben werden (siehe hierzu die Zeichenreferenz) – unabhängig von der Codierung. Letztlich war dieses Verfahren aber auch nicht zielführend.

Weiterhin gibt es für die Sprachregionen Osteuropas (Russisch etc.) sowie die asiatischen Sprachen (Chinesisch, Japanisch, Koreanisch, abgekürzt CJK) eigene Codetabellen, die sich teilweise eigenständig und unabhängig entwickelt haben und mitunter nur die Anforderungen des jeweiligen Sprachraumes berücksichtigen.

Der universale Code: Unicode

Mit Unicode werden so ziemlich alle Zeichencodierungsprobleme dieser Welt gelöst. Und weil Webseiten potentiell mit allen Schriften dieser Welt genutzt werden, ist seit HTML 4.0 und XML (und damit auch XHTML) festgelegt, dass grundsätzlich alle in Unicode definierten Zeichen vorkommen dürfen.

Mit dieser Festlegung kann man also jedes der 149.186 Unicode-Zeichen in seinem Text verwenden. Aber Unicode regelt nicht nur die Codierung von immer mehr Schriftzeichen dieser Welt, sondern kennt zu jedem Zeichen dutzende definierte Eigenschaften. Ein Zeichen besitzt mindestens folgende Informationen:

• der eindeutige Unicode-Name des Zeichens
• den zugeordneten Codepoint (die „Nummer“ des Zeichens)
• eine generelle Kategorisierung (Buchstabe, Zahl, Symbol, Interpunktion, ...)
• weitere grundsätzliche Charakteristiken (Whitespace, Bindestrich, alphabetisch, ideografisch, Nicht-Zeichen, veraltet, ...)
• anzeigerelevante Informationen (Schreibrichtung, Form, Spiegelung, Breite)
• Groß-/Kleinschreibung
• Zahlenwert und -typ bei Zahlzeichen
• Trennfunktionen (zwischen Wörtern, Zeilen, Sätzen,...)

Die meisten Eigenschaften eines Zeichens sind nur für die interne Behandlung durch den Computer relevant. Beispielsweise werden arabische Schriftzeichen automatisch korrekt von rechts nach links geschrieben, oder der Zeilenumbruch nutzt die Stellen, an denen eine Wortgrenze z. B. durch ein normales Leerzeichen existiert. Dieser kleine Exkurs soll aber verdeutlichen, dass die Bytewerte der Buchstaben für den Computer viel mehr bedeuten können, als nur den Buchstaben an sich.

Über die Definition von Zeichen und ihren Codepoints hinaus liefert das Unicode-Konsortium noch eine Fülle von weiteren Standardisierungen, die sich auf die linguistisch korrekten Behandlung von schriftlicher menschlicher Sprache beziehen. Darunter sind Algorithmen zur sprachspezifischen Sortierung (Beispiel: Im Deutschen gibt es zwei Sortierungsvarianten, Wörterbücher sortieren mit ä=a, ö=o, ü=u, Telefonbücher mit ä=ae, ö=oe, ü=ue) und zur Normalisierung (Wie prüft man, ob zwei Zeichenketten identisch sind).

Codepoints und Schriftzeichen

Ein Unicode Codepoint entspricht oft einem bestimmten Schriftzeichen oder Leerraum. Das muss aber nicht immer so sein. Einige Codepoints stellen Steuerzeichen dar, wie zum Beispiel U+0009 und U+000A für Tabulator und Zeilenvorschub. Andere werden nur fallweise dargestellt, beispielsweise der bedingte Trennstrich ­ mit dem Codepoint U+00AD.

Um beliebige Kombinationen von Akzenten (diakritische Zeichen) mit anderen Schriftzeichen zu ermöglichen, gibt es Codepoints für kombinierende Zeichen. Sie werden nicht eigenständig dargestellt, sondern mit dem vorangehenden Zeichen zu einem Schriftzeichen verschmolzen. Die deutschen Umlautpunkte  ̈ existieren beispielsweise als Codepoint U+0308 COMBINING DIAERESIS. Ein ä lässt sich dadurch einerseits als Codepoint U+00E4 LATIN SMALL LETTER A WITH DIAERESIS darstellen, andererseits aber auch als die Abfolge U+0061 U+0308.

Weil es dadurch erschwert wird, Zeichenketten zu verarbeiten und zu vergleichen, sieht Unicode einen Normalisierungsalgorithmus vor, der in JavaScript durch die Methode normalize von String.prototype und in PHP durch die Normalizer-Klasse bereitgestellt wird.

Andererseits gibt es auch Zeichen, die den gleichen Glyphen (die visuelle Darstellung des Zeichens) nutzen, aber unterschiedliche Bedeutung haben. Vergleichen Sie beispielsweise p und р - sie sehen gleich aus, aber eins von den beiden ist das kyrillische Zeichen Er. Da die kyrillischen Zeichen trotz gleichen Aussehens eine andere Bedeutung haben, nutzen sie andere Codepoints. Die dadurch entstehende visuelle Verwechselungsgefahr ist bei Phishing-Attacken beliebt: eine URL wie https://рost.example.org kann Sie schneller nach Fernost schicken als Sie „Transsibirische Eisenbahn“ sagen können. Wenn Sie diesen Link kopieren und einfügen, sehen Sie https://xn--ost-zed.example.org/, die für nicht-ASCII-Zeichen erforderliche Punycode-Darstellung des Domain-Namens, woran Sie die Täuschung erkennen können.

Unicode und Fonts

Die gängigen Font-Formate TTF (TrueType) und OTF (OpenType) lassen maximal 65535 Glyphen zu. Die Darstellung sämtlicher Unicode-Zeichen mit einer Schriftdatei (und damit font-family in CSS) ist damit technisch unmöglich. Projekte wie Googles Noto bestehen daher aus vielen Schriftdateien, um das Problem durch Modularisierung zu lösen. In einer CSS @font-face Definition lässt sich der Unicode-Zeichenbereich angeben, für den eine Schriftart Glyphen enthält. Wenn ein HTML Element nun beispielsweise Codepoints für ägyptische Hieroglyphen und lateinische Schriftzeichen enthält, könnte man im CSS die entsprechenden Noto-Module so angeben:

  p.ägyptisch {
    font-family: "Noto Sans Egyptian Hieroglyphs", "Noto Sans", sans-serif;
  }

und auf diese Weise beide Noto-Module gemeinsam nutzen.

Codierungsformen von Unicode-Zeichen

Der oben erwähnte Codepoint eines Unicode-Zeichens ist nur eine abstrakte Nummer. Die Schreibweise dieser Nummer im Unicode-Standard erfolgt in hexadezimalen Zahlen mit vorangestelltem „U+“. Der Codepoint legt noch keinerlei computerkompatible Darstellung fest, dies ist Aufgabe des Codierschemas. Da die Unicode-Codepoints von U+0000 bis U+10FFFF (hexadezimale Zahlendarstellung), mit einer beabsichtigten Lücke zwischen U+D7FF und U+E000, reichen, sind für eine vollständige Codierung des gesamten Codepoint-Bereichs als Binärzahl mindestens 3 Byte erforderlich.

Im Folgenden werden die verbreiteten Speichervarianten von Unicode-Zeichen kurz vorgestellt.

UTF-32: Simpel, aber verschwenderisch

Da Computer viel besser mit Vielfachen von 2 umgehen können, hat man kein Codierschema mit 3 Bytes definiert, sondern als simpelste Variante UTF-32 festgelegt, bei dem jede Codeeinheit 32 Bit = 4 Bytes groß ist. Der Codepoint jedes Zeichens wird hierbei einfach als 32-Bit-Zahlwert gespeichert.

Es gibt von UTF-32 zwei Varianten, UTF-32LE (Little Endian) und UTF-32BE (Big Endian), die sich einfach nur in der Reihenfolge unterscheiden, mit denen einzelne Bytes einer größeren Zahl in den Datenstrom gegeben werden. Big Endian beginnt mit der „Tausenderstelle“, Little Endian mit der „Einerstelle“. Damit eindeutig festgestellt werden kann, welche Variante genutzt wird, gibt es ein spezielles Zeichen namens „BOM“ (Byte Order Mark) mit dem Codepoint U+FEFF, welches dem Datenstrom vorangestellt wird. Sind die ersten vier Bytes eines Datenstroms 0x00, 0x00, 0xFE und 0xFF, so wird Big Endian verwendet. Sind es hingegen 0xFF, 0xFE, 0x00 und 0x00, wird Little Endian verwendet.

Der größte Nachteil ist, dass UTF-32 extrem verschwenderisch mit Speicherplatz umgeht. Da Unicode insgesamt pro Zeichen nur 3 Byte benötigt, ist pro UTF-32-Zeichen schon mindestens ein Byte ungenutzt verschwendet. Die am häufigsten benutzten Zeichen lassen sich sogar allesamt mit nur 2 Bytes darstellen, da sie sich im Bereich U+0000 bis U+FFFF befinden. Lateinische Buchstaben ohne diakritische Zeichen, wie sie in (westlichen) Fließtexten häufig vorkommen, lassen sich gar nur mit einem Byte codieren, da sie im Bereich U+0000 bis U+00FF vorkommen.

UTF-16: Praxisformat im RAM

UTF-16 nutzt Codiereinheiten, die 16 Bit = 2 Bytes groß sind. Dies halbiert bei üblichen Texten den Speicherverbrauch im Vergleich zu UTF-32. Auch für UTF-16 gibt es wieder die zwei Varianten UTF-16LE und UTF-16BE. Die BOM erscheint bei Big Endian als 0xFE, 0xFF, und bei Little Endian als 0xFF, 0xFE.

Allerdings lassen sich mit nur 2 Bytes nicht mehr alle Unicode-Zeichen direkt darstellen. An dieser Stelle kommt die eingangs erwähnte beabsichtigte Lücke ins Spiel. Zeichen, die sich nicht direkt codieren lassen, weil sie aus dem Codepoint-Bereich zwischen U+10000 und U+10FFFF kommen, werden als Kombination zweier Codiereinheiten dargestellt, den so genannten Surrogatzeichen aus dem Bereich U+D800 bis U+DFFF. Da in diesem Bereich keine gültigen Unicode-Zeichen liegen können, kann ein Programm eindeutig erkennen, dass hier Zeichen aus dem höheren Bereich codiert wurden.

Um ein Unicode-Zeichen mit einer Codepoint-Nummer über U+FFFF in UTF-16 zu codieren, wird von der Codepoint-Nummer zunächst 65536 (Hexadezimal 10000) abgezogen. Weil die höchste zulässige Codepoint-Nummer U+10FFFF ist, entsteht so eine Zahl im Bereich 0x00000 bis 0xFFFFF, die sich mit 20 Bits darstellen lässt. Der reservierte Bereich der Surrogatzeichen ist zweigeteilt, zum einen U+D800 bis U+DBFF für die so genannten high surrogates und U+DC00 bis U+DFFF für die low surrogates. Wenn Sie nachrechnen, werden Sie feststellen, dass beide Teilbereiche einen Umfang von 1024 Zeichen haben, wodurch sich jeweils 10 Bits codieren lassen. Der Codiervorgang soll an Hand des Unicodezeichens U+1F642 (leicht lächelndes Gesicht 🙂) vorgestellt werden.

Codepoint	1F642	0001 1111 0110 0100 0010
0x10000 abziehen	0F642	0000 1111 0110 0100 0010
Aufteilen Umgruppieren		0000 1111 01 .... ..00 0111 1101	10 0100 0010 .... ..10 0100 0010
Surrogate	D800 / DC00	1101 1000 0000 0000	1101 1100 0000 0000
Zusammenfügen		1101 1000 0011 1101 D83D	1101 1110 0100 0010 DE42

Die UTF-16 Darstellung von U+1F642 erfolgt durch die beiden Surrogatzeichen U+D83D (high surrogate) und U+DE42 (low surrogate). Die Aufteilung der Surrogatzeichen in zwei Bereiche stellt sicher, dass auch bei einer Verwechslung von UTF-16LE und UTF-16BE die richtige Zuordnung der höherwertigen und niederwertigen Bitgruppe möglich ist.

UTF-16 wird von vielen Programmen für die interne Repräsentation von Zeichenketten verwendet. Da es aber gerade bei westeuropäischen Sprachen immer noch relativ viele Bytes verschwendet, und außerdem Probleme mit Unicode-unfähigen Programmen wie z. B. Editoren macht, wird es zum Datenaustausch zwischen Systemen nicht sehr häufig verwendet.

UTF-8: Die Codierungsform der Wahl

UTF-8 nutzt Codiereinheiten, die 8 Bit = 1 Byte groß sind. Genau wie bei UTF-16 ist der Gesamtbereich der Unicode-Zeichen mit nur einem Byte nicht abzudecken, also werden bei Bedarf mehrere Bytes zusammengefasst, um einen Codepoint zu codieren.

UTF-8 hat im Vergleich zu den anderen UTF-Varianten mehrere praktische Vorteile:

• Die ersten 127 Zeichen und Bytes sind identisch mit ASCII, d. h. alle Texte, die in der Hauptsache Unicode-Zeichen mit Codepoints zwischen U+0000 und U+007F verwenden, bleiben problemlos lesbar.
• Auch Systeme, die UTF-8 nicht verstehen, können die Bytes trotzdem (eingeschränkt) verarbeiten, weil es sich um – wenn auch eher abstruse – „normale“ Zeichen handelt.
• Selbst das byteorientierte Sortieren von UTF-8-Texten funktioniert und sortiert die Strings geordnet nach dem Zahlenwert der enthaltenen Codepoints.
• Bei Verwendung von westeuropäischen Sprachen wird im Vergleich zu UTF-16 viel Speicherplatz gespart, da die meisten Zeichen nur ein Byte benötigen.

Ein Unicode-Zeichen kann in UTF-8 zwischen einem und vier Bytes groß sein. Um einen Codepoint in UTF-8 zu codieren, wird dessen binäre Zahldarstellung benötigt.

Unicode-Bereich	Binäre Zahldarstellung	1. Byte	2. Byte	3. Byte	4. Byte
U+0000–U+007F	00000000 0xxxxxxx	0xxxxxxx
U+0080–U+07FF	00000yyy yyxxxxxx	110yyyyy	10xxxxxx
U+0800–U+D7FF, U+E000–U+FFFF	zzzzyyyy yyxxxxxx	1110zzzz	10yyyyyy	10xxxxxx
U+10000–U+10FFFF	000uuuuu zzzzyyyy yyxxxxxx	11110uuu	10uuzzzz	10yyyyyy	10xxxxxx

In der Tabelle steht u für die Angabe der Unicode-Ebene (Plane) falls nicht BMP. Was die Position des Zeichens innerhalb der Ebene betrifft, steht x steht für den Anteil im letzten, y für den Anteil im vorletzten und z für den Anteil im drittletzten Zeichen. Die Angabe anderer Unicode-Ebenen als der BMP muss auf die genannte Art erfolgen. Die UTF-16-Surrogates U+D800–U+DFFF dürfen nicht in UTF-8 kodiert werden. Einige Datenbanksysteme tun dies trotzdem. Diese Fehlfunktion wurde nachträglich als CESU-8 standardisiert. Ebenso ist die Codierung der Zeichen U+110000–U+1FFFFF oder die Erweiterung auf mehr als 4 Zeichen nicht erlaubt, da Unicode nur 17 Ebenen definiert und UTF-16 auch nur diese kodieren kann. Außerdem dürfen keine Sequenzen kodiert werden, die länger als nötig sind.

Ein Beispiel: Das Eurozeichen hat den Codepoint U+20AC. Die binäre Darstellung dieser Zahl ist 00100000 10101100. Setzt man diese Bits in das Schema der dritten Zeile, so erhält man 11100010 10000010 10101100 oder als Bytes 0xE2, 0x82 und 0xAC.

UTF-8 basiert zwar prinzipiell auf Big Endian, kennt aber offiziell keine Varianten für Big Endian oder Little Endian. Die für diesen Zweck benutzte Byte Order Mark sieht immer gleich aus: 0xEF, 0xBB und 0xBF. Da sie somit ihren Zweck der Erkennung der Byte-Reihenfolge nicht erfüllt, darf man sie ohne Probleme weglassen. Allerdings kann sie auch zur Erkennung, dass es sich um UTF-8-Text handelt, herangezogen werden.

Codepoints

Jedes im Unicode-Standard codierte elementare Zeichen ist einer Codepoint-Nummer im Bereich von 0 bus 10FFFF_hex. Die Codepoints werden thematisch in Codeblöcke gruppiert. Jeweils 65536 Codepoints mit den Endziffern 0000 bis FFFF_hex bilden darüber hinaus eine Ebene.

Die ersten Unicodeversionen sahen nur Codepointnummern bis FFFF_hex vor. Nachdem eine Flut ostasiatischer Schriftzeichen diesen Umfang gesprengt hat, wurde der Zeichenvorrat ab Unicode 3.1 versiebzehnfacht und es gibt nun einen möglichen Zeichenvorrat von 1.112.064 Zeichen (1.114.112 Codepunkte, von denen 2048 als Surrogatzeichen reserviert sind). Die aktuelle Unicode-Version 14.0 verwendet 144.697 davon.

Die Codepoint-Gruppen aus der Zeit bis Unicode 3.0 bilden die Ebene 0, die so genannte Basic Multilingual Plane BMP. Eine Grafik aus der Wikipedia zeigt, wie die darin befindlichen Codeblöcke belegt sind:

Grafische Darstellung der Ebenen von Unicode, Quelle: Wikipedia

In der Ebene 0 konnten nur die häufigsten CJK-Ideogramme (Symbolschriftzeichen der chinesischen, japanischen und koreanischen Schrift) berücksichtigt werden.

Weitere Ebenen sind

Ebene 01 

Supplementary Multilingual Plane SMP (ergänzende mehrsprachige Ebene mit Schriftzeichen aus den unterschiedlichsten Kulturen)

Ebene 02 

Supplementary Ideographic Plane SIP (ergänzende ideographische Ebene, enthält nur CJK Ideogramme)

Ebene 03 

Tertiary Ideographic Plane TIP (dritte ideographische Ebene, bislang nur ca 5000 Zeichen. Beantragt sind darüber hinaus die chinesische Siegelschrift und Orakelknochenschrift)

Ebenen 04 bis 0D 

Derzeit noch unbelegt

Ebene 0E 

für Sonderzwecke reserviert

Ebenen 0F und 10

Ebenen für private Verwendung. Die Codepunkte dieser Ebenen sind nicht für spezielle Schriftzeichen reserviert und können von Schriftarten individuell belegt werden.

• Zeichencodierung
  (Übersicht)
• Unicode in der Praxis