Typografische Anführungszeichen („ “ ‘ ’) sind andere Unicode-Zeichen als die geraden Anführungszeichen (" '), die Programmiersprachen und Datenformate verlangen. Parser vergleichen exakte Codepunkte, also ist ein geschwungenes Anführungszeichen für sie nur ein gewöhnlicher Buchstabe – und die Zeichenkette öffnet sich nie. Das Ersetzen durch gerade Anführungszeichen behebt das Problem sofort.
Es sind tatsächlich unterschiedliche Zeichen
Das ganze Problem in einer Tabelle:
| Zeichen | Name | Codepunkt |
|---|---|---|
" |
Gerades doppeltes Anführungszeichen | U+0022 |
| “ | Linkes doppeltes Anführungszeichen | U+201C |
| ” | Rechtes doppeltes Anführungszeichen | U+201D |
' |
Gerades Apostroph | U+0027 |
| ‘ | Linkes einfaches Anführungszeichen | U+2018 |
| ’ | Rechtes einfaches Anführungszeichen | U+2019 |
Programmiersprachen, JSON, CSV und Shell-Interpreter erkennen genau zwei davon als String-Begrenzer: U+0022 und U+0027. Die anderen vier sind gewöhnliche druckbare Zeichen, in derselben Kategorie wie ein Buchstabe oder ein Komma.
Wenn ein Parser auf “name” trifft, sieht er also keine Zeichenkette mit leicht dekorativen Anführungszeichen. Er sieht eine Zeichenfolge ohne Begrenzer, die mit einem Symbol beginnt, das er nicht erwartet hat. Die Fehlermeldung lautet dann unexpected token und zeigt auf eine Zeile, die völlig korrekt aussieht – weil der Unterschied zwischen " und “ bei normaler Schriftgröße nur ein paar Pixel Krümmung sind.
Woher sie kommen
Fast immer von Software, die hilfreich sein will.
- Word und Google Docs wandeln gerade Anführungszeichen beim Tippen in geschwungene um. Das ist standardmäßig aktiviert, und die meisten bemerken es nie, weil es in Fließtext genau das ist, was man will.
- KI-Modelle erzeugen sie, weil sie aus publizierten Texten gelernt haben, die mit korrekten Anführungszeichen gesetzt sind.
- macOS wendet die intelligente Substitution systemweit in vielen Textfeldern an.
- CMS-Editoren und Kommentarfelder lassen häufig typografische Filter über eingereichten Text laufen.
- Kopieren aus PDFs übernimmt, was der Satz verwendet hat – und das ist bei professionell erstellten Dokumenten immer die geschwungene Variante.
Der gemeinsame Nenner: Der Text ist durch etwas gelaufen, das zum Lesen gedacht ist, auf dem Weg zu etwas, das zum Parsen gedacht ist. Prosa will typografische Anführungszeichen, Code will exakte Bytes. Das Problem entsteht an der Grenze.
Das Gleiche gilt für ein paar Begleiter, die man kennen sollte: das Auslassungszeichen (…) statt drei Punkten, Bindestrich und Gedankenstrich statt des Minuszeichens sowie geschützte Leerzeichen statt gewöhnlicher. Jedes ist ein anderer Codepunkt als das ASCII-Zeichen, dem es ähnelt, und jedes bricht einen Parser auf dieselbe stille Weise.
Was konkret kaputtgeht
JSON. Jede Zeichenkette in JSON muss U+0022 verwenden. Ein einziges geschwungenes Anführungszeichen macht das Dokument ungültig, und weil Parser den ersten Fehler melden, braucht eine Datei mit Dutzenden davon mehrere Durchgänge, um sie von Hand zu reparieren. Das Einfügen in einen JSON-Formatter und -Validator zeigt die genaue Position des ersten Übeltäters.
CSV. Anführungsregeln existieren, um Felder mit Kommas zu schützen. Ein geschwungenes Anführungszeichen ist kein Anführungszeichen, also wird ein Feld wie “Smith, John” am Komma getrennt und jede folgende Spalte rutscht um eins nach links. Das ist heimtückischer als ein Syntaxfehler, weil es still scheitert – du erhältst eine Datei, die sich ohne Murren importieren lässt und falsch ist.
Quellcode. In den meisten Sprachen ist das ein Kompilier- oder Parsefehler, was wenigstens laut ist. In Shell-Skripten kann es schlimmer sein: rm –rf mit einem Bindestrich statt eines Minuszeichens ist nicht das Flag, das du meintest, und Argumente in geschwungenen Anführungszeichen werden als wörtlicher Text durchgereicht.
Konfigurationsdateien. YAML, TOML und .env-Dateien akzeptieren geschwungene Anführungszeichen stillschweigend als Teil des Werts. Dein API-Schlüssel bekommt ein dekoratives Zeichen angehängt, die Authentifizierung schlägt fehl, und nichts im Log sagt dir warum.
Reguläre Ausdrücke und Suche. Ein Muster mit einem geraden Anführungszeichen trifft keinen Text mit einem geschwungenen – Suchen-und-Ersetzen liefert also leise null Treffer.
So behebst du es richtig
Vereinheitliche den Text. Füge ihn in Typografische Anführungszeichen ersetzen ein. Das Werkzeug ersetzt alle vier geschwungenen Varianten durch ihre ASCII-Entsprechungen und zeigt an, wie viele es geändert hat. Speziell für KI-Ausgaben erledigt der KI-Text-Bereiniger Anführungszeichen zusammen mit Gedankenstrichen, unsichtbaren Zeichen und Emojis in einem Durchgang.
Schalte die Quelle ab. Wenn das immer wieder passiert, deaktiviere die Substitution:
- Word: Datei → Optionen → Dokumentprüfung → AutoKorrektur-Optionen → AutoFormat während der Eingabe → Häkchen bei "Gerade Anführungszeichen durch typografische ersetzen" entfernen.
- Google Docs: Tools → Einstellungen → Häkchen bei "Typografische Anführungszeichen verwenden" entfernen.
- macOS: Systemeinstellungen → Tastatur → Texteingabe → Bearbeiten → intelligente Anführungszeichen und Bindestriche deaktivieren.
Schreibe keinen Code in einer Textverarbeitung. Die eigentliche Lösung ist strukturell. Alles, was für einen Parser bestimmt ist, gehört in einen Plain-Text-Editor, der deine Zeichen niemals umschreibt.
Vorsicht vor Überkorrektur. Ersetze geschwungene Anführungszeichen nicht pauschal in Fließtext. In einem Artikel oder einer E-Mail sind typografische Anführungszeichen korrekt, und gerade sehen schlechter aus. Vereinheitliche an der Grenze – wenn Text aus einem Dokument in Code oder Daten wandert –, nicht standardmäßig überall.
Wenn eine Datei nach dem Vereinheitlichen der Anführungszeichen immer noch scheitert, ist der nächste Verdächtige ein unsichtbares Zeichen; siehe die Referenz zu unsichtbaren Unicode-Zeichen.
Häufige Fragen
Warum meldet mein JSON „unexpected token“, obwohl es korrekt aussieht?
Fast immer ein geschwungenes Anführungszeichen an einer Stelle, an die ein gerades gehört. JSON verlangt exakt U+0022, und die geschwungenen Varianten U+201C und U+201D sind für einen Parser gewöhnliche Zeichen. Der Unterschied ist auf dem Bildschirm nur wenige Pixel groß – deshalb sieht die Zeile in Ordnung aus.
Was ist der Unterschied zwischen typografischen und geraden Anführungszeichen?
Es sind unterschiedliche Unicode-Zeichen. Gerade Anführungszeichen sind U+0022 und U+0027, die ASCII-Zeichen, die jeder Parser erwartet. Typografische Anführungszeichen sind U+2018, U+2019, U+201C und U+201D – typografische Zeichen, die sich zum Text hin krümmen, korrekt in Prosa und ungültig als String-Begrenzer.
Wie wandle ich typografische in gerade Anführungszeichen um?
Füge den Text in ein Normalisierungswerkzeug wie Typografische Anführungszeichen ersetzen ein. Es tauscht alle vier geschwungenen Varianten aus und zeigt die Anzahl an. Mit Suchen-und-Ersetzen braucht man vier einzelne Durchgänge, einen pro Zeichen – deshalb bleibt es oft unvollständig.
Warum verschieben sich die Spalten beim CSV-Import?
Ein Feld mit Komma ist nur geschützt, wenn es in geraden Anführungszeichen steht. Geschwungene Anführungszeichen sind keine Anführungszeichen, also wird das Feld am Komma getrennt und jede folgende Spalte rutscht. Das scheitert still und erzeugt eine Datei, die sich sauber importieren lässt und falsch ist.
Sollte ich typografische Anführungszeichen immer entfernen?
Nein. In Fließtext sind sie korrekte Typografie und sehen besser aus als gerade. Vereinheitliche nur, wenn Text in Code, JSON, CSV, Konfigurationsdateien oder etwas anderes übergeht, das geparst statt gelesen wird.