Was ist der ASCII-Code?

ASCII steht für American Standard Code for Information Interchange. Der Standard erschien 1963 als ASA X3.4-1963, ausgearbeitet von einem Gremium der American Standards Association, der Vorläuferorganisation der heutigen ANSI. Ursprünglich hatte er nichts mit Webseiten zu tun: Er sollte dafür sorgen, dass Fernschreiber, Rechner und Telekommunikationsgeräte unterschiedlicher Hersteller Text austauschen konnten, ohne dass dabei ein einziges Zeichen verloren ging.

Die Grundidee ist simpel. Jedes Zeichen bekommt eine Zahl zwischen 0 und 127, darstellbar mit 7 Bit. Die ersten 32 Zahlen, von 0 bis 31, sind Steuerzeichen: Zeilenumbruch, Wagenrücklauf und ähnliche Befehle an das Empfangsgerät, keine Zeichen, die auf dem Bildschirm erscheinen sollen. Von 32 bis 126 folgen Groß- und Kleinbuchstaben, die Ziffern 0 bis 9 und die grundlegende englische Interpunktion. Die Zahl 127 steht für DEL, ein Löschzeichen aus der Zeit der Lochstreifen.

Die Fassung von 1963 kannte noch keine Kleinbuchstaben, die kamen erst mit der Revision von 1967 dazu. Die letzte inhaltliche Überarbeitung datiert von 1986, ANSI X3.4-1986, seither steht der Satz von 128 Zeichen fest. Genau diese Stabilität macht ihn im technischen SEO sechzig Jahre später noch relevant: Keine der 128 Zahlen hat seither ihre Bedeutung gewechselt.

Die drei Begriffe werden im technischen Alltag durcheinandergeworfen, obwohl sie nicht austauschbar sind. ASCII ist ein geschlossener Satz von 128 Zeichen. Unicode ist ein deutlich größerer Standard, der praktisch jedem von Menschen verwendeten Schriftzeichen eine eigene Nummer zuweist, mit über 149.000 zugewiesenen Zeichen in der Version von 2025. UTF-8 ist eine Kodierung: das konkrete Verfahren, das diese Nummern zum Speichern oder Übertragen in Bytes umwandelt.

Der Punkt, der selten gut erklärt wird, ist die Abwärtskompatibilität. UTF-8 wurde so entworfen, dass die ersten 128 Unicode-Zeichen, die exakt denen von ASCII entsprechen, ein einziges Byte belegen, mit demselben Wert wie in reinem ASCII. Eine ASCII-Textdatei ist ohne jede Änderung eine gültige UTF-8-Datei. Umgekehrt gilt das nicht: Eine UTF-8-Datei mit einem ü oder einem Emoji ist in dem Moment kein ASCII mehr, in dem dieses Zeichen auftaucht.

Ein ASCII-Zeichen belegt 7 Bit, doch kaum ein modernes System bewegt Daten in Einheiten von 7 Bit; gearbeitet wird in Bytes zu 8 Bit. Genau dieses achte, in der Originalspezifikation freie Bit wurde in den Neunzigerjahren zur Quelle vieler Kodierungsprobleme. Verschiedene Hersteller nutzten es für 128 zusätzliche Zeichen, meist Umlaute und Buchstaben anderer Sprachen, aber jeder mit einer eigenen Tabelle: ISO 8859-1 (Latin-1) in weiten Teilen Westeuropas, Windows-1252 auf PCs unter Windows, andere Codepages im Rest der Welt.

Wanderte ein Text zwischen zwei Systemen, die sich bei der Tabelle nicht einig waren, entstand das sogenannte Mojibake: ein ß, das zu einem bedeutungslosen Symbol wurde, ein Umlaut, der als Kästchen erschien, Text, der schlicht unlesbar war. Unicode und UTF-8 entstanden genau deshalb, um diese Abhängigkeit von der jeweiligen Systemtabelle zu beenden.

Muss ein Nicht-ASCII-Zeichen durch einen Kanal, der nur ASCII zulässt, wie es bei einer URL oder einer E-Mail-Kopfzeile bis heute der Fall ist, greift die Prozent-Kodierung: Das Zeichen wird zunächst in UTF-8-Bytes umgewandelt, jedes Byte dann als %, gefolgt von zwei Hexadezimalziffern dargestellt, also nur mit ASCII-Zeichen geschrieben, obwohl der Ursprung keines war. Eine reine Textkonfigurationsdatei wie die robots.txt einer Website wird weiterhin in ASCII oder unmarkiertem UTF-8 empfohlen, damit jeder Crawler sie eindeutig liest.

ASCII spielt 2026 aus einem konkreten Grund noch eine Rolle: Mehrere Teile der Web-Infrastruktur erwarten dieses Format weiterhin oder bevorzugen es eindeutig. Google äußert sich dazu ausdrücklich in seiner Dokumentation zur URL-Struktur: Zeichen außerhalb des ASCII-Bereichs sollen prozentkodiert werden, als Negativbeispiel zeigt Google eine URL mit unkodierten arabischen Zeichen neben ihrer kodierten Version.

Der praktischste Fall ist der Slug einer URL. Einer mit Umlauten oder ß bricht die Seite nicht, aber Browser und viele Systeme zeigen am Ende die prozentkodierte Version an, für Menschen unlesbar und im Suchergebnis weniger klar. Diese Lesbarkeit gehört auch zur Nutzererfahrung, sobald jemand den Link von Hand kopiert oder teilt. Existieren die URL mit Umlauten und ihre kodierte Version nebeneinander, zeigen zwei unterschiedliche Adressen auf dieselbe Seite, und dann lohnt sich eine Canonical-Angabe, welche Version als Referenz gilt.

Außerhalb des Browsers erwarten E-Mail-Kopfzeilen und etliche Altsysteme weiterhin reines ASCII, und ein Dateiname mit Sonderzeichen verhält sich je nach Betriebssystem oder Server, auf den er hochgeladen wird, unterschiedlich.

• Verwende im Slug jeder URL nur Buchstaben ohne Umlaute, Ziffern und Bindestriche; vermeide Umlaute, ß und Leerzeichen, auch wenn der Inhalt auf Deutsch ist.
• Lass Browser oder Server jedes Zeichen außerhalb von ASCII prozentkodieren, statt es direkt in einen Link zu schreiben.
• Speichere Textdateien in UTF-8 ohne BOM: Für die ersten 128 Zeichen bleibt das Byte für Byte kompatibel mit ASCII.
• Benenne Dateien, die auf einen Server geladen werden (Bilder, PDFs, Stylesheets), ohne Umlaute oder Sonderzeichen, um unterschiedliches Verhalten je nach Hosting-System zu vermeiden.
• Halte die robots.txt und andere Konfigurationsdateien in reinem ASCII, ohne Sonderzeichen, die ein Crawler oder Server falsch interpretieren könnte.
• Existieren eine URL mit Umlauten und ihre kodierte Version parallel, markiere per Canonical, welche Fassung indexiert werden soll, statt es Suchmaschinen zu überlassen.

• Umlaute oder ß direkt in einen Link schreiben, statt sie kodieren zu lassen, wodurch zwei unterschiedliche Adressen für denselben Inhalt entstehen.
• ASCII und Unicode als Synonyme behandeln: ASCII deckt 128 Zeichen ab, Unicode über 149.000.
• Eine Datei in einer anderen Kodierung als UTF-8 speichern, etwa Windows-1252, ohne sie zu deklarieren, was beim Öffnen auf einem anderen System zu Mojibake führt.
• E-Mail-Kopfzeilen mit Nicht-ASCII-Zeichen versenden, ohne sie nach dem MIME-Standard zu kodieren, wodurch manche Mailprogramme unlesbaren Text anzeigen.
• Sonderzeichen wie Häkchen oder Pfeile direkt im Titel oder in der Meta Description einsetzen, ohne zu prüfen, ob die Suchmaschine sie unterstützt, was im Snippet manchmal ein kaputtes Zeichen statt des gewünschten Symbols zeigt.