Wer Programmier­erfah­rung z.B. aus den 1990er Jah­ren hat, weiß noch, wie leicht man eine Zeichen­kette aus­wer­ten oder ver­ändern konnte, weil darin jedes Byte für genau ein Zeichen stand. Doch mit UTF-8 ist das heut­zutage manch­mal etwas schwie­ri­ger. Hier ein Rück­blick auf die guten Gründe für die Ent­wick­lung von Uni­code und UTF-8 ...

Man erinnert sich kaum noch daran: Der be­liebte Home­computer C-64 (er­schie­nen 1982) kannte ↗keine Um­laute. Eine weitere Ein­schrän­kung war: Wenn ein Spiel viele Grafik­zeichen ver­wen­den wollte, musste es auf den zwei­ten Zeichen­satz um­schal­ten, wo aber die Klein­buch­staben fehlten. Deshalb stell­ten viele Spiele ihre Texte nur in Groß­buch­staben dar. Und deutsche Text­adven­tures schrie­ben mit den Um­laut-Erset­zun­gen AE OE UE.

Noch schlichter war es bei den frühen Compu­tern der 1950er Jah­re, als ein Byte z.B. nur aus 6 Bits be­stand. Ja tat­säch­lich: ein Byte war noch nicht auf 8 Bits fest­ge­legt. Im 6-Bit-Werte­bereich von 0 bis 63 kriegte man nur ein paar Steuer­zeichen unter­ge­bracht, z.B. Zeilen­vorschub und Wagen­rücklauf für Drucker, außerdem die 10 Ziffern, ein paar Satz­zeichen und eben­falls nur die latei­ni­schen Groß­buch­staben. Das war damals nicht schlimm, weil man die Groß­rechner, die mittels Loch­streifen ge­steu­ert wur­den, zum Rechnen nutzte, nicht für Texte.

Erst beim IBM Großrechner ↗System/360 (1964) wurde ein Byte standard­mäßig als 8 Bit defi­niert. Nun konnte man der Kodier­tabelle endlich auch die Klein­buch­staben und wei­tere Satz­zeichen hin­zu­fü­gen. Die IBM-eigene, proprie­täre Umset­zung nennt sich ↗EBCDIC (1963 ent­wickelt), während eben­falls in 1963 US-ASCII als all­ge­meine Kodier-Empfeh­lung er­schien, die aber nicht zu EBCDIC kompa­ti­bel ist. ASCII be­schränkte sich auf die Nut­zung von 7 Bits (Werte 0 bis 127), weil man das 8. Bit als Paritäts-Bit ver­wen­den wollte, d.h. ein Prüf-Bit zur Er­ken­nung von Übertra­gungs­fehlern bei der Kom­mu­ni­ka­tion mit Druckern und Terminals.

In den 60er Jah­ren bekam IBM immer mehr Kunden auch in Europa, wo sprach­spezi­fi­sche Buch­staben be­nötigt wurden, z.B. deutsche Um­laute. Deshalb ent­warf IBM über 200 natio­nale Code Pages (Kodier­seiten = Zeichen­tabellen) als sprach­spezi­fi­sche, regio­nale Varian­ten von EBCDIC, die auf Groß­rechnern (Main­frames) ge­nutzt wurden.

Für den IBM PC (ab 1981) entwickelte IBM die ASCII-basierte Code­page ↗CP437 in 8 Bit, worin auch Um­laute und Akzent­zeichen ent­hal­ten waren. Später ent­stan­den weitere ASCII-kompatible Code­pages für andere Regionen und Sprachen. Ab ↗PC-DOS bzw. MS-DOS 3.3 (1987) konnte der Anwen­der die Code­page selber in der CONFIG.SYS fest­legen.

Als neuer internationaler Standard wurde 1987 die Norm ↗ISO 8859 vor­ge­stellt, für Sprachen in Europa und dem Nahen Osten. Dabei setzte man auf 8 Bit, ASCII-Kompati­bi­li­tät und nutzt sepa­rate Code­pages, die hier "Parts" (Unter­normen/Teil­normen) heißen.
Doch für DOS kam ISO 8859 einige Jahre zu spät, denn DOS hatte nun schon mehrere eigene ASCII-kompa­tible Code­pages. Hingegen wurde Linux erst ab 1991 ent­wickelt, als ISO-8859-1 (Latin-1) bereits ein etablier­ter Standard war. Deshalb konnte Linux sofort auf die ISO-Norm setzen. Ebenso wird sie für E-Mail und HTML ver­wendet.

Zur gleichen Zeit schwenkte auch Micro­soft auf ISO 8859 ein, denn seit Windows 3.1 (1992) über­nimmt Windows nicht mehr die ein­ge­stellte DOS-Code­page, sondern nutzt "ANSI Code Pages", welche die Um­set­zung der ISO-Familie sind, z.B. ent­spricht CP1252 (Windows-1252, west­europä­isch) dem ISO-8859-1.
Aber weil Windows eine grafische Ober­fläche hat, wollte man erst­mals typo­grafi­sche Zeichen mit an­bie­ten, z.B. diese „ “ Anfüh­rungs­zeichen, die man nun dar­stel­len kann. Deshalb hat Micro­soft die un­ge­nutzten, nicht-druck­baren Steuer­codes zwischen 80(hex) und 9F durch solche typo­gra­fi­schen Zeichen er­setzt.

Ein großes Problem von Codepages ist, dass sie (oberhalb von ASCII) nicht unter­einander kompa­ti­bel sind. Man kann nur ent­weder west­europä­ische oder grie­chi­sche oder kyril­li­sche Buch­staben etc. kodieren und dar­stel­len, aber nicht gemein­sam in einem Text. Und wenn man nicht weiß, mit welcher Code­page ein Text oder eine Datei kodiert wurde, kann man es ggf. nicht lesen.

An anderes Problem betrifft den asiati­schen Raum mit seinen kom­plexen Schrift­zeichen. Manche Schrift­systeme be­stehen aus mehre­ren tausend Zeichen, die man mengen­mäßig gar nicht in 8 Bit (256 Code­punkte) ab­bil­den kann.

Ab 1987 entwickelten die Mitarbei­ter verschie­dener Computer­firmen den Unicode-Standard in 16 Bit. Sie schrie­ben dazu (über­setzt): „Mit Unicode soll der Bedarf an einer prakti­ka­blen, zu­verläs­sigen Welt-Text­kodierung ge­deckt werden. Unicode könnte grob als "Wide-Body-ASCII" be­schrie­ben werden, das auf 16 Bits ge­streckt wurde, um die Zeichen aller leben­den Sprachen der Welt zu um­fassen.“

1991 wurde nach mehrjähriger Entwicklungs­zeit die Version 1.0 des Unicode-Standards ver­öffent­licht, der über 7.000 Zeichen ent­hielt. Zur Unter­stützung des Projekts hatte sich zuvor das Unicode-Konsor­tium ge­grün­det, mit vielen be­kann­ten Firmen wie Adobe, Apple, Borland, DEC, IBM, Lotus, Micro­soft, NeXT, Novell, Sun Micro­systems, Syman­tec, Unisys, Word­Perfect, Xerox und anderen.

In den folgenden Jahren wurden immer mehr Sprachen und Zeichen in die Unicode-Tabellen mit auf­genom­men, so dass bereits 1993 schon 34.000 Zeichen ent­hal­ten waren. Es wurde abseh­bar, dass man die 64k-Grenze der 16 Bits (UCS-2) über­schrei­ten würde, ins­beson­dere wenn man auch histo­rische Schrift­systeme mit auf­nehmen wollte.

Deshalb definierte 1996 die Version 2.0 von Uni­code seine Erweiter­bar­keit auf 32 Bit. Das bedeutet, dass man die bis dahin gängigs­ten Zeichen in einem 16-Bit-Word kodie­ren kann und man nur auf ein zweites Daten­wort zurück­greifen braucht, wenn es sich um seltene oder histori­sche Zeichen han­delt. Der flexible Speicher­bedarf wird im Kodie­rungs­format UTF-16 um­ge­setzt, welches das starre UCS-2 er­setzt.

UTF-8 wurde 1992 bei Bell Labs ent­wickelt, außer­halb des Unicode-Konsor­tiums. UTF-8 ist rückwärts­kompati­bel zu ASCII, d.h. ASCII-Zeichen be­legen weiter­hin nur ein Byte. Durch die varia­ble Länge von bis zu 4 Bytes, können alle Code­punkte von Uni­code kodiert werden. In Uni­code sind inzwi­schen über 1 Mil­lion Zeichen (Code­points) de­fi­niert.

UTF-8 ist sehr speicher­effizient. Und in Kombina­tion mit seiner ASCII-Kompati­bi­li­tät ist es leicht in be­stehende Systeme zu inte­grieren – ein ent­schei­dender Faktor für die Ver­brei­tung auf Linux-Systemen und im Web. Obwohl das Unicode-Konsor­tium ur­sprüng­lich auf UTF-16 als Haupt­kodierung setzte, wurde UTF-8 später offi­ziell in den Unicode-Standard auf­genom­men (ab Unicode 3.0, 1999).

Ab Mitte der 2000er Jahre be­gan­nen die meis­ten Linux-Distri­bu­tionen (Debian, Red Hat, später Ubuntu), UTF-8 standard­mäßig zu ver­wen­den. Auch im Internet ist UTF-8 heut­zutage die dominie­rende Zeichen­kodie­rung.

Es gibt aber auch APIs (Schnitt­stellen), die von ANSI/Code­pages auf UTF-16 um­ge­stellt wurden, bevor UTF-8 sich durch­setzte. Dazu ge­hören die Windows API seit Windows NT (ab 1993), Apple Cocoa API und Core Founda­tion, und Android (bezüg­lich Java). UTF-16 wird bei den Programmier­sprachen Java, Kotlin, C# (.NET), Delphi (ab 2009) und Java­Script als primä­rer String-Typ ver­wendet.