Warum zeigt ein exportiertes Transkript seltsame Zeichen auf dem iPhone?

Es ist eine ganz eigene, verwirrende Art von Fehler: Das Transkript sieht in der App völlig normal aus, exportiert sich ohne jede Fehlermeldung, und dann kommt ein Name auf Ukrainisch oder ein Wort auf Hebräisch am anderen Ende als Reihe von Fragezeichen oder leeren Kästchen heraus, sobald die Datei woanders geöffnet wird — auf einem Windows-Laptop, in einem älteren Programm, beim Import in eine Tabellenkalkulation. Nichts davon sieht nach einem Tippfehler oder einer Verhörung aus. Es sieht aus, als wäre die Datei unterwegs kaputtgegangen — ein nachvollziehbarer Verdacht, der so gut wie nie zutrifft.

Was eine Textdatei darunter eigentlich ist

Eine reine Textdatei trägt kein internes Etikett, das sagt, welches Alphabet ihre Bytes ergeben sollen. Sie ist nur eine Folge von Bytes, und jedes Programm, das sie öffnet, muss selbst eine Zuordnung annehmen — von diesen Bytes zu den Buchstaben und Zeichen, die es dir zeigt: eine Zeichenkodierung. Liegt die Annahme richtig, liest sich die Datei genau so, wie sie geschrieben wurde. Liegt sie falsch, erfindet das Programm nichts — es zeigt getreu das falsche Zeichen für jedes Byte, bei dem seine Annahme und die tatsächliche Kodierung der Datei nicht übereinstimmen.

Praktisch alles, was für iPhone, Mac, Android oder das moderne Web geschrieben wird, trifft dieselbe Annahme: UTF-8, eine einzige Kodierung, die jede Schrift darstellen kann, die ein iPhone transkribieren kann — Hebräisch, das Kyrillisch des Ukrainischen und Russischen, chinesische Schriftzeichen, japanische Kana und Kanji, koreanisches Hangeul und jeden Akzentbuchstaben im Französischen, Spanischen oder Portugiesischen. Das ist heute das Nächste, was Text an einem universellen Standard hat — genau deshalb ist dieses Problem seltener geworden, als es einmal war, und genau deshalb überrascht es noch, wenn es doch einmal auftritt.

Warum nur manche Wörter betroffen sind

Der Hinweis darauf, dass es sich um eine falsch geratene Kodierung und nicht um einen Transkriptionsfehler handelt, liegt darin, welche Zeichen unversehrt bleiben. Gewöhnliche Buchstaben, Ziffern und normale Satzzeichen werden in UTF-8 und in fast jeder noch gebräuchlichen älteren Kodierung identisch dargestellt — diese Übereinstimmung ist Absicht, geht Jahrzehnte zurück, und deshalb übersteht ein deutscher Satz ohne Umlaute fast jedes fehlerhaft eingestellte Programm unbeschadet. Genau die Zeichen, bei denen sich diese Kodierungen unterscheiden — ein ü oder ein ç, und jede nicht-lateinische Schrift — kommen als Fragezeichen, Kästchen oder eine kurze Reihe zusammenhangloser Symbole heraus. Ist das ganze Transkript von Anfang bis Ende unleserlich, liegt die Ursache woanders; sind nur die Umlaute und die Wörter in einer anderen Schrift betroffen, während der Rest sauber lesbar ist, ist genau dieses Muster die Signatur einer falsch geratenen Kodierung.

So lässt es sich auch von einem echten Fehler der Spracherkennung bei einem Wort unterscheiden. Ein falsch transkribiertes Wort bleibt ein reales, plausibles Wort — die Erkennung hat etwas gehört und ihre beste Vermutung aufgeschrieben, falsch, aber in sich stimmig. Ein kaputtes Zeichen ist überhaupt keine Vermutung: Es hat keinerlei Bezug zu dem, was gesagt wurde, es erscheint jedes Mal exakt gleich kaputt, wenn diese Bytefolge auftaucht, und es ist eine Eigenschaft dessen, was die Datei anzeigt, nicht dessen, was die App tatsächlich hineingeschrieben hat.

Wo das noch vorkommt, jetzt, wo UTF-8 fast überall Standard ist

Moderne Alltags-Apps lösen dieses Problem beim reinen Öffnen einer Textdatei kaum noch aus — Notizen, Mail, Nachrichten, ein Browser oder ein Textprogramm auf einem aktuellen Telefon oder Computer lesen UTF-8 korrekt, ohne dass du etwas tun musst. Wo eine falsche Annahme noch auftaucht, ist eher am Eingang eines spezielleren Werkzeugs: der „Textdatei importieren"-Dialog einer Tabellenkalkulation, der zwar eine Kodierung zur Auswahl anbietet, standardmäßig aber eine regionale statt UTF-8 wählt, oder ein älteres Skript oder Programm, das von vornherein eine Ein-Byte-Kodierung nur für lateinische Buchstaben annimmt, weil wer auch immer es geschrieben hat, nie mit etwas anderem als Eingabe gerechnet hat. Das Transkript selbst trägt in keinem der beiden Fälle die Schuld — die falsche Annahme passiert genau an der Stelle, an der es durchgereicht wurde.

Genau diese eine betroffene Kopie reparieren

Das ursprüngliche Transkript, das weiterhin in der App liegt, die es erzeugt hat, bleibt von all dem unberührt — nur diese eine exportierte Kopie, gelesen von dem einen Programm, das falsch geraten hat, wird falsch angezeigt. Das weist direkt auf die Lösung hin: die Datei erneut öffnen und dem Programm explizit sagen, welche Kodierung es verwenden soll, wo diese Option angeboten wird. Ein Texteditor mit einem Befehl „mit Kodierung erneut öffnen" oder der Import-Assistent einer Tabellenkalkulation mit einer Kodierungs-Auswahlliste lassen beide direkt UTF-8 wählen, statt zu übernehmen, was das Programm standardmäßig geraten hat. Bietet das Werkzeug gar keine solche Option, umgeht ein erneuter Export aus der Quelle und das direkte Einfügen des Texts in das Ziel — statt die gespeicherte Datei zu öffnen — das Raten vollständig: Einfügen überträgt die tatsächlichen Zeichen, ohne dass dazwischen irgendeine Annahme beim Lesen der Datei steht.

Wie Voice Studio damit umgeht

Sowohl der TXT- als auch der JSON-Export schreiben reinen UTF-8-Text — dieselbe Kodierung, die praktisch jedes aktuelle iOS-, Mac-, Android- oder Web-Werkzeug beim Öffnen einer Datei ohnehin schon annimmt. Ein Transkript auf Hebräisch, Ukrainisch, Chinesisch, Japanisch, Koreanisch oder in akzentuiertem Französisch oder Spanisch öffnet sich an der überwältigenden Mehrheit der Orte, an denen es wahrscheinlich landet, korrekt. Zeigt ein bestimmtes Ziel trotzdem die falschen Zeichen, ist das eine Tatsache über das, was die Datei dort liest, nicht über das, was hineingeschrieben wurde — diesem Programm zu sagen, es solle die Datei als UTF-8 lesen, wo es dir diese Wahl lässt, behebt das Problem tatsächlich. Nichts an diesem Anzeigefehler beim Öffnen wirkt sich auf das Transkript aus, das in der App bleibt — es bleibt genau so, wie es transkribiert wurde.

Häufige Fragen

Bedeutet das, dass die Transkription das Wort falsch erkannt hat?

Nein. Ein falsch transkribiertes Wort bleibt ein echtes Wort, nur das falsche. Kaputte Zeichen — Fragezeichen, Kästchen oder Symbole ohne Bezug zum Original — entstehen dadurch, dass ein Programm die Datei mit der falschen Kodierung liest, ein völlig anderes Problem als ein Verhören der Spracherkennung.

Warum verwandeln sich nur manche Buchstaben in Symbole und nicht das ganze Transkript?

Gewöhnliche Buchstaben, Ziffern und normale Satzzeichen werden in UTF-8 und in fast jeder älteren Kodierung gleich dargestellt, sie lesen sich also unabhängig von der Annahme eines Programms korrekt. Genau die Umlaute und Buchstaben nicht-lateinischer Schriften — dort, wo Kodierungen sich unterscheiden — kommen falsch heraus.

Ist mein Transkript beschädigt, wenn ich das sehe?

Nein. Das Transkript in der App bleibt unberührt — das passiert einer bestimmten exportierten Kopie, in dem Programm, das sie mit der falschen Annahme geöffnet hat. Ein erneuter Export oder das Öffnen dieser Kopie mit auf UTF-8 gesetzter Kodierung behebt es.

Wie repariere ich ein Transkript, das schon kaputte Zeichen zeigt?

Öffne es erneut in einem Programm, das die Kodierung explizit auswählen lässt, und wähle UTF-8, falls diese Option existiert. Gibt es sie nicht, exportiere das Transkript erneut aus der App und füge den Text direkt ins Ziel ein, statt die gespeicherte Datei zu öffnen.