Mojibake

Mojibake ( japanisch :文字化け; IPA: [mod͡ʑibake] , „Zeichentransformation“) ist ein verstümmelter oder unverständlicher Text, der entsteht, wenn ein Text mit einer unbeabsichtigten Zeichenkodierung dekodiert wird . ^{[ 1 ]} Das Ergebnis ist ein systematischer Ersatz von Symbolen durch völlig unzusammenhängende Symbole, oft aus einem anderen Schriftsystem .

Diese Anzeige kann das generische Ersetzungszeichen ⟨�⟩ an Stellen enthalten, an denen die Binärdarstellung als ungültig gilt. Eine Ersetzung kann auch mehrere aufeinanderfolgende Symbole umfassen, wie sie in einer Kodierung dargestellt werden, wenn derselbe Binärcode in der anderen Kodierung ein einzelnes Symbol bildet. Dies liegt entweder an unterschiedlichen Kodierungen mit konstanter Länge (wie asiatische 16-Bit-Kodierungen im Vergleich zu europäischen 8-Bit-Kodierungen) oder an der Verwendung von Kodierungen mit variabler Länge (insbesondere UTF-8 und UTF-16 ).

Fehlerhafte Darstellung von Glyphen aufgrund fehlender Schriftarten oder fehlender Glyphen in einer Schriftart ist ein anderes Problem und darf nicht mit Mojibake verwechselt werden. Symptome dieser fehlerhaften Darstellung sind Blöcke, in denen der Codepunkt hexadezimal angezeigt wird oder das generische Ersetzungszeichen verwendet wird. Wichtig ist, dass diese Ersetzungen gültig sind und auf die korrekte Fehlerbehandlung der Software zurückzuführen sind.

Um den ursprünglich kodierten Text korrekt wiederzugeben, muss die Übereinstimmung zwischen den kodierten Daten und dem Kodierungsverfahren gewahrt bleiben (d. h. Quell- und Zielkodierungsstandards müssen übereinstimmen). Da Mojibake ein Beispiel für die Nichteinhaltung dieser Standards ist, kann es durch Manipulation der Daten selbst oder durch einfaches Umbenennen erreicht werden.

Mojibake tritt häufig bei Textdaten auf, die mit einer falschen Kodierung versehen wurden; sie können sogar gar nicht kodiert sein, sondern zwischen Computern mit unterschiedlichen Standardkodierungen übertragen werden. Eine Hauptursache für Probleme sind Kommunikationsprotokolle , die auf den Einstellungen der einzelnen Computer basieren, anstatt Metadaten zusammen mit den Daten zu senden oder zu speichern .

Die unterschiedlichen Standardeinstellungen von Computern sind teils auf die unterschiedliche Implementierung von Unicode in den Betriebssystemfamilien und teils auf die Spezialisierung älterer Kodierungen für verschiedene Schriftsysteme menschlicher Sprachen zurückzuführen. Während Linux-Distributionen im Jahr 2004 größtenteils auf UTF-8 umgestiegen sind ^{[ 2 ]} , verwendet Microsoft Windows im Allgemeinen UTF-16 und greift für Textdateien in verschiedenen Sprachen mitunter auf 8-Bit-Codepages zurück.

Bei einigen Schriftsystemen , wie beispielsweise Japanisch , wurden historisch bedingt verschiedene Kodierungen verwendet, was dazu führt, dass Benutzer relativ häufig Mojibake sehen. So kann beispielsweise das Wort „mojibake “ selbst ( 文字化け) in EUC-JPﾊｸｻ�ｽ､ｱ fälschlicherweise als , ﾊｸｻ嵂ｽ､ｱ( MS-932 ) oder angezeigt werden, ﾊｸｻ郾ｽ､ｱwenn es als Shift-JIS interpretiert wird, oder als ʸ»ú²½¤±in Software, die Text in den Kodierungen Windows-1252 oder ISO 8859-1 (üblicherweise als „Westlich“ oder „Westeuropäisch“ bezeichnet) erwartet . Dies wird noch verstärkt, wenn andere Gebietsschemata involviert sind: Derselbe Text, in UTF-8 gespeichert, kann so erscheinen, als ob 譁�蟄怜喧縺�er als Shift-JIS, als 文字化け„Westlich“ oder (beispielsweise) 鏂囧瓧鍖栥亼als GBK (Festlandchina) interpretiert würde.

Wenn die Kodierung nicht angegeben ist, entscheidet die Software auf anderem Wege darüber. Je nach Softwaretyp werden üblicherweise entweder Konfigurationseinstellungen oder heuristische Zeichensatzerkennungsverfahren verwendet , die beide fehleranfällig sind.

Die Kodierung von Textdateien wird durch die Gebietsschemaeinstellungen beeinflusst , die unter anderem von der Sprache des Benutzers und dem Betriebssystem abhängen . Daher ist die angenommene Kodierung systematisch falsch für Dateien, die von einem Computer mit anderen Einstellungen oder sogar von einer anders lokalisierten Software innerhalb desselben Systems stammen. Für Unicode bietet sich die Verwendung einer Byte-Order-Markierung (BOM) an , die jedoch von vielen Parsern für Quellcode oder andere maschinenlesbare Texte nicht unterstützt wird . Eine andere Lösung besteht darin, die Kodierung als Metadaten im Dateisystem zu speichern. Dateisysteme, die erweiterte Dateiattribute unterstützen , können diese als BOM speichern user.charset. ^{[ 3 ]} Dies erfordert ebenfalls Unterstützung in der Software, die diese Funktion nutzen möchte, ohne andere Software zu beeinträchtigen.

Während einige Kodierungen, wie beispielsweise UTF-8, leicht zu erkennen sind, gibt es viele, die schwer zu unterscheiden sind (siehe Zeichensatzerkennung ). So kann ein Webbrowser beispielsweise nicht zwischen einer in EUC-JP kodierten Seite und einer in Shift-JIS kodierten Seite unterscheiden , wenn die Kodierung nicht explizit über HTTP-Header, die mit den Dokumenten gesendet werden, oder über die Meta-Tags des Dokuments , die fehlende HTTP-Header ersetzen, falls der Server nicht für das Senden der korrekten HTTP-Header konfiguriert werden kann, zugewiesen wird; siehe Zeichenkodierungen in HTML .

Mojibake tritt auch auf, wenn die Kodierung falsch angegeben wird. Dies geschieht häufig zwischen ähnlichen Kodierungen. Beispielsweise war bekannt, dass der E-Mail-Client Eudora für Windows E-Mails mit der Kennzeichnung ISO 8859-1 versendete, die in Wirklichkeit Windows-1252 entsprachen . ^{[ 4 ]} Windows-1252 enthält zusätzliche druckbare Zeichen im C1- Bereich (am häufigsten gebogene Anführungszeichen und zusätzliche Bindestriche ), die in ISO-konformer Software nicht korrekt dargestellt wurden; dies betraf insbesondere Software unter anderen Betriebssystemen wie Unix .

Of the encodings still in common use, many originated from taking ASCII and appending atop it; as a result, these encodings are partially compatible with each other. Examples of this include Windows-1252 and ISO 8859-1. People thus may mistake the expanded encoding set they are using with plain ASCII.

When there are layers of protocols, each trying to specify the encoding based on different information, the least certain information may be misleading to the recipient. For example, a web server serving a static HTML file over HTTP can communicate the character set to the client in any number of 3 ways:

• in the HTTP header. This information can be based on server configuration (for instance, when serving a file off disk) or controlled by the application running on the server (for dynamic websites).
• in the file, as an HTML meta tag (http-equiv or charset) or the encoding attribute of an XML declaration. This is the encoding that the author meant to save the particular file in.
• in the file, as a byte order mark. This is the encoding that the author's editor actually saved it in. Unless an accidental encoding conversion has happened (by opening it in one encoding and saving it in another), this will be correct. It is, however, only available in Unicode encodings such as UTF-8 or UTF-16.

Much older hardware is typically designed to support only one character set and the character set typically cannot be altered. The character table contained within the display firmware will be localized to have characters for the country the device is to be sold in, and typically the table differs from country to country. As such, these systems will potentially display mojibake when loading text generated on a system from a different country. Likewise, many early operating systems do not support multiple encoding formats and thus will end up displaying mojibake if made to display non-standard text – early versions of Microsoft Windows and Palm OS for example, are localized on a per-country basis and will only support encoding standards relevant to the country the localized version will be sold in, and thus will display mojibake if a file containing a text in a different encoding format from the version that the OS is designed to support is opened.

Applications using UTF-8 as a default encoding may achieve a greater degree of interoperability because of its widespread use and backward compatibility with ASCII. UTF-8 also has the ability to be directly recognized by a simple algorithm, so that well-written software should be able to avoid mixing UTF-8 up with other encodings.

Wie schwierig es ist, ein Problem mit Mojibake zu beheben, hängt von der jeweiligen Anwendung und den Ursachen ab. Zwei der häufigsten Anwendungen, in denen Mojibake auftreten kann, sind Webbrowser und Textverarbeitungsprogramme . Moderne Browser und Textverarbeitungsprogramme unterstützen oft eine Vielzahl von Zeichenkodierungen. Browser ermöglichen es dem Benutzer häufig, die Kodierungseinstellung der Rendering-Engine direkt zu ändern, während Textverarbeitungsprogramme die Auswahl der passenden Kodierung beim Öffnen einer Datei erlauben. Es kann einige Versuche erfordern , die richtige Kodierung zu finden.

Das Problem wird komplexer, wenn es in einer Anwendung auftritt, die normalerweise keine breite Palette an Zeichenkodierungen unterstützt, wie beispielsweise in einem Nicht-Unicode-Computerspiel. In diesem Fall muss der Benutzer die Kodierungseinstellungen des Betriebssystems an die des Spiels anpassen. Allerdings kann die Änderung der systemweiten Kodierungseinstellungen auch bei bereits vorhandenen Anwendungen zu Mojibake führen. Unter Windows XP und neueren Versionen kann der Benutzer Microsoft AppLocale verwenden , eine Anwendung, mit der die Gebietsschemaeinstellungen für jede Anwendung einzeln geändert werden können. Auf älteren Betriebssystemen wie Windows 98 ist die Änderung der Betriebssystemkodierungseinstellungen jedoch nicht möglich . Um dieses Problem auf älteren Betriebssystemen zu beheben, muss der Benutzer auf Drittanbieter-Anwendungen zur Schriftartendarstellung zurückgreifen.

Mojibake tritt in englischen Texten üblicherweise bei Satzzeichen wie Gedankenstrichen (—), Halbgeviertstrichen (–) und geschweiften Anführungszeichen („“, , ', ') auf, jedoch selten in Fließtext, da die meisten Kodierungen mit ASCII hinsichtlich der Kodierung des englischen Alphabets übereinstimmen . Beispielsweise erscheint das Rautezeichen (#) so, als wäre es vom Absender als UTF-8 kodiert , vom Empfänger aber als eine der westeuropäischen Kodierungen ( CP1252 oder ISO 8859-1 ) interpretiert worden. Bei wiederholter Anwendung von CP1252 kann dies zu Zeichenketten wie „, “, „, “, „,“ usw. führen .£Â£Ã‚£Ã‚£Ã‚£Ã‚£

In ähnlicher Weise wird das rechte einfache Anführungszeichen (') bei der Kodierung in UTF-8 und der Dekodierung mit Windows-1252 zu ’, ’, ’, usw.

In früheren Zeiten verwendeten einige Computer herstellerspezifische Kodierungen, was auch bei englischen Texten zu Inkompatibilitäten führte. Commodore - 8-Bit- Computer nutzten die PETSCII- Kodierung, die insbesondere durch die Umkehrung der Groß- und Kleinschreibung im Vergleich zu Standard- ASCII auffiel . PETSCII-Drucker funktionierten zwar auf anderen Computern dieser Zeit einwandfrei, kehrten aber die Groß- und Kleinschreibung aller Buchstaben um. IBM- Großrechner verwendeten die EBCDIC -Kodierung, die überhaupt nicht mit ASCII übereinstimmt.

Die Alphabete der nordgermanischen Sprachen – Katalanisch , Rumänisch , Finnisch , Französisch , Deutsch , Italienisch , Portugiesisch und Spanisch – sind allesamt Erweiterungen des lateinischen Alphabets . Die zusätzlichen Zeichen sind typischerweise diejenigen, die verfälscht werden, sodass Texte mit Mojibake nur geringfügig unlesbar sind.

• å , ä , ö im Finnischen und Schwedischen (š und ž kommen in einigen finnischen Lehnwörtern vor , é nur vereinzelt im Schwedischen, hauptsächlich aber ebenfalls in Lehnwörtern)
• à, ç, è, é, ï, í, ò, ó, ú, ü auf Katalanisch
• æ , ø , å im Norwegischen und Dänischen sowie optionale Akutakzente auf é, ǿ usw. zur Unterscheidung
• á, é, ó, ij , è, ë, ï auf Niederländisch
• ä, ö, ü und ß auf Deutsch
• á, ð , í , ó , ú , ý , æ, ø auf Färöisch
• á, ð, é , í, ó, ú, ý, þ , æ, ö auf Isländisch
• à, â, ç, è, é, ë, ê, ï, î, ô, ù, û, ü, ÿ, æ, œ auf Französisch
• à, è, é, ì, ò, ù auf Italienisch
• á, é, í, ñ , ó, ú, ü, ¡, ¿ auf Spanisch
• à, á, â, ã, ç, é, ê, í, ó, ô, õ, ú auf Portugiesisch ( ü wird nicht mehr verwendet)
• á, é, í, ó, ú auf Irisch
• à, è, ì, ò, ù auf Schottisch-Gälisch
• ă, â, î, ș, ț auf Rumänisch
• £ im britischen Englisch (æ und œ werden selten verwendet, ebenso wie é und ê in einigen Lehnwörtern)

...und gegebenenfalls deren Entsprechungen in Großbuchstaben.

Dies sind Sprachen, für die der Zeichensatz ISO 8859-1 (auch bekannt als Latin-1 oder Western ) verwendet wurde. ISO 8859-1 wurde jedoch durch zwei konkurrierende Standards ersetzt: das abwärtskompatible Windows-1252 und das leicht veränderte ISO 8859-15 . Beide fügen das Euro-Zeichen € und das französische œ hinzu. Ansonsten führt eine Verwechslung dieser drei Zeichensätze in diesen Sprachen nicht zu Mojibake (einer Art Zeichensatz). Es ist stets unbedenklich, ISO 8859-1 als Windows-1252 und relativ unbedenklich als ISO 8859-15 zu interpretieren, insbesondere im Hinblick auf das Euro-Zeichen, das das selten verwendete Währungszeichen (¤) ersetzt. Mit dem Aufkommen von UTF-8 ist Mojibake jedoch in bestimmten Szenarien häufiger geworden, z. B. beim Austausch von Textdateien zwischen UNIX- und Windows- Computern, da UTF-8 nicht mit Latin-1 und Windows-1252 kompatibel ist. UTF-8 lässt sich jedoch direkt durch einen einfachen Algorithmus erkennen, sodass gut programmierte Software Verwechslungen mit anderen Kodierungen vermeiden sollte. Dies war besonders häufig der Fall, als viele Programme UTF-8 nicht unterstützten. Die meisten dieser Sprachen wurden von MS-DOS standardmäßig mit CP437 und anderen Standardkodierungen unterstützt (mit Ausnahme von ASCII), weshalb Probleme beim Kauf einer Betriebssystemversion seltener auftraten. Windows und MS-DOS sind jedoch nicht kompatibel.

Im Schwedischen, Norwegischen, Dänischen und Deutschen werden Vokale selten wiederholt, und es ist meist offensichtlich, wenn ein Zeichen verfälscht wird, z. B. der zweite Buchstabe im schwedischen Wort kärlekfür „Liebe“, wenn es in UTF-8 kodiert, aber in Western dekodiert wird, was zu „“ führt kÃ⁠¤rlek, oder fürim Deutschen, was zu „“ wird für. Auf diese Weise bleiben fast alle Texte lesbar, auch wenn der Leser den ursprünglichen Buchstaben erraten muss. Finnisch hingegen verwendet häufig wiederholende Vokale in Wörtern wie „ hääyö“ („Hochzeitsnacht“), was verfälschten Text sehr schwer lesbar machen kann (z. B. hääyöerscheint „“ als hÃ⁠¤Ã⁠¤yÃ⁠¶„“). Isländisch hat zehn möglicherweise verwirrende Zeichen und Färöisch acht, wodurch viele Wörter im verfälschten Zustand fast völlig unverständlich werden (z. B. erscheint das isländische Wort für þjóðlöð„hervorragende Gastfreundschaft“ als þjóðlöð„“).

Im Deutschen ist Buchstabensalat ein gebräuchlicher Begriff für dieses Phänomen, im Spanischen wird deformación (wörtlich „Verformung“) verwendet und im Portugiesischen desformatação (wörtlich „Entformung“).

Manche Nutzer transkribieren ihre Texte am Computer, indem sie entweder problematische diakritische Zeichen weglassen oder Digraphen verwenden ( å → aa , ä/æ → ae , ö/ø → oe , ü → ue usw.). So schreibt ein Autor beispielsweise „ueber“ statt „über“, was im Deutschen üblich ist, wenn keine Umlaute verfügbar sind. Diese Praxis scheint im deutschsprachigen Raum besser akzeptiert zu werden als in den nordischen Ländern . Im Norwegischen beispielsweise werden Digraphen mit archaischem Dänisch assoziiert und mitunter scherzhaft verwendet. Dennoch sind Digraphen für die Kommunikation mit anderen Teilen der Welt nützlich. So trug der norwegische Fußballspieler Ole Gunnar Solskjær beispielsweise bei Manchester United den Nachnamen „SOLSKJAER“ auf seinem Trikot .

Ein Artefakt, bei dem UTF-8 fälschlicherweise als ISO 8859-1 interpretiert und Ring meg nåals dargestellt wurde Ring meg nå, wurde 2014 bei einem SMS-Betrug beobachtet, der auf Norwegen abzielte. ^{[ 5 ]}

Das gleiche Problem tritt auch im Rumänischen auf, siehe diese Beispiele:

Auch Nutzer mittel- und osteuropäischer Sprachen können betroffen sein. Da die meisten Computer Mitte bis Ende der 1980er Jahre nicht mit einem Netzwerk verbunden waren, gab es für jede Sprache mit diakritischen Zeichen unterschiedliche Zeichenkodierungen (siehe ISO/IEC 8859 und KOI-8 ), die oft auch je nach Betriebssystem variierten.

Im Ungarischen wird dieses Phänomen als „betűszemét “ bezeichnet , was so viel wie „Buchstabenmüll“ bedeutet. Ungarisch ist besonders anfällig dafür, da es die Akzentbuchstaben á, é, í, ó, ú, ö, ü (alle im Zeichensatz Latin-1 enthalten) sowie die beiden Zeichen ő und ű enthält, die nicht zu Latin-1 gehören. Diese beiden Zeichen lassen sich in Latin-2, Windows-1250 und Unicode korrekt kodieren. Bevor Unicode jedoch in E-Mail-Clients weit verbreitet war, wurden die Buchstaben ő und ű in E-Mails mit ungarischem Text oft fehlerhaft dargestellt, manchmal sogar so stark, dass sie unleserlich waren. Häufig antwortet man auf eine fehlerhafte E-Mail mit dem sinnlosen Satz „Árvíztűrő tükörfúrógép“ (wörtlich „Hochwassersichere Spiegelbohrmaschine“), der alle im Ungarischen verwendeten Akzentbuchstaben enthält.

Vor der Einführung von ISO 8859-2 im Jahr 1987 verwendeten Nutzer verschiedener Computerplattformen ihre eigenen Zeichenkodierungen , beispielsweise AmigaPL auf dem Amiga, Atari Club auf dem Atari ST und Masovia sowie IBM CP852 , Mazovia und Windows CP1250 auf IBM-PCs. Polnische Hersteller früher DOS- Computer entwickelten eigene, inkompatible Methoden zur Kodierung polnischer Zeichen und programmierten die EPROMs der Grafikkarten (typischerweise CGA , EGA oder Hercules ) einfach um, um Hardware-Codepages mit den benötigten Glyphen für Polnisch bereitzustellen – willkürlich platziert, ohne jeglichen Bezug zu den Glyphen anderer Computerhersteller.

Die Situation begann sich zu verbessern, als sich ISO 8859-2 nach Druck von akademischen Gruppen und Anwendern als „Internetstandard“ durchsetzte, allerdings mit begrenzter Unterstützung durch die Software der führenden Anbieter (heute weitgehend durch Unicode ersetzt). Aufgrund der zahlreichen Probleme, die durch die Vielfalt der Kodierungen entstehen, bezeichnen manche Anwender polnische diakritische Zeichen noch heute als „ krzaczki “ ( [ˈkʂät͜ʂ.ki] , wörtlich „kleine Sträucher“).

Mojibake wird im Russischen umgangssprachlich als Krakozyabry ( кракозя́бры [krɐkɐˈzʲæbrɪ̈] ) bezeichnet, was aufgrund verschiedener Systeme zur Kodierung des Kyrillischen kompliziert war und ist . ^{[ 6 ]} Die Sowjetunion und die frühe Russische Föderation entwickelten KOI-Kodierungen ( Kod Obmena Informatsiey , Код Обмена Информацией , wörtlich „Code für den Informationsaustausch“). Dies begann mit der kyrillisch reinen 7-Bit- Kodierung KOI7 , die auf ASCII basierte , jedoch lateinische und einige andere Zeichen durch kyrillische Buchstaben ersetzte. Darauf folgte die 8-Bit -Kodierung KOI8 , eine Erweiterung von ASCII , die ausschließlich kyrillische Buchstaben mit Oktetten höherer Bits kodiert, die den 7-Bit-Codes von KOI7 entsprechen. Aus diesem Grund bleibt KOI8-Text, selbst russischer, nach dem Entfernen des achten Bits teilweise lesbar, was im Zeitalter von E-Mail-Systemen ohne 8BITMIME -Unterstützung als großer Vorteil galt . Beispielsweise werden die Wörter ( shkola russkogo yazyka ) nach der Kodierung in KOI8 und dem Entfernen der höchsten Bits wie folgt dargestellt : [Hier sollte der Text stehen]. Schließlich entstanden verschiedene KOI8-Varianten für Russisch und Bulgarisch ( KOI8-R ), Ukrainisch ( KOI8-U ), Belarussisch (KOI8-RU) und sogar Tadschikisch (KOI8-T). Школа русского языка[KOLA RUSSKOGO qZYKA

Im Westen unterstützte die Codepage 866 unter MS-DOS neben Russisch und Bulgarisch auch Ukrainisch und Belarussisch . Für Microsoft Windows fügte die Codepage 1251 die Unterstützung für Serbisch und andere slawische Varianten des Kyrillischen hinzu .

Die neueste Unicode -Kodierung umfasst Codepunkte für praktisch alle Zeichen in allen Sprachen, einschließlich aller kyrillischen Zeichen.

Vor Unicode war es notwendig, die Textkodierung mit einer Schriftart abzustimmen, die dasselbe Kodierungssystem verwendete. Andernfalls entstand unlesbarer Kauderwelsch , dessen genaues Erscheinungsbild von der Kombination aus Text- und Schriftkodierung abhing. Beispielsweise führt der Versuch, nicht-Unicode-konformen kyrillischen Text mit einer auf das lateinische Alphabet beschränkten Schriftart oder mit der Standardkodierung („Western“) anzuzeigen, typischerweise zu einem Text, der fast ausschließlich aus Großbuchstaben mit diakritischen Zeichen besteht (z. B. wird aus KOI8 Библиотека( biblioteka , Bibliothek) âÉÂÌÉÏÔÅËÁ, während aus Школа русского языка( shkola russkogo yazyka , russischsprachige Schule) ) ûËÏÌÁ ÒÕÓÓËÏÇÏ ÑÚÙËÁ. Die Verwendung der Codepage 1251 zur Anzeige von Text in KOI8 oder umgekehrt führt zu einem verstümmelten Text, der hauptsächlich aus Großbuchstaben besteht (KOI8 und Codepage 1251 verwenden zwar denselben ASCII-Bereich, aber KOI8 verwendet Großbuchstaben in dem Bereich, in dem Codepage 1251 Kleinbuchstaben verwendet, und umgekehrt).

In den Anfangsjahren des russischen Teils des World Wide Web waren sowohl KOI8 als auch die Codepage 1251 weit verbreitet. Fast alle Websites verwenden heute Unicode, doch im November 2023 waren schätzungsweise 0,35 % aller Webseiten weltweit – unabhängig von ihrer Sprache – noch mit der Codepage 1251 kodiert, während weniger als 0,003 % der Seiten noch mit KOI8-R kodiert waren. ^{[ 7 ] [ 8 ]} Obwohl der HTML-Standard die Möglichkeit bietet, die Kodierung für jede Webseite im Quelltext anzugeben, ^{[ 9 ]} wird dies mitunter vernachlässigt, sodass der Benutzer die Kodierung im Browser manuell ändern muss.

Im Bulgarischen wird Mojibake oft als Majmunica ( маймуница ) bezeichnet, was so viel wie „Affenalphabet“ bedeutet. Im Serbischen heißt es đubre ( ђубре ), was „ Müll “ bedeutet. Anders als in der ehemaligen UdSSR verwendeten die Südslawen nie etwas wie KOI8, und die Codepage 1251 war vor Unicode die vorherrschende kyrillische Kodierung. Daher hatten diese Sprachen weniger Probleme mit Kodierungsinkompatibilität als Russisch. In den 1980er-Jahren verwendeten bulgarische Computer ihre eigene MIK-Kodierung , die zwar oberflächlich ähnlich, aber inkompatibel mit CP866 ist.

Kroatisch , Bosnisch , Serbisch (die abtrünnigen Varietäten der serbokroatischen Sprache) und Slowenisch erweitern das lateinische Alphabet um die Buchstaben š, đ, č, ć, ž und ihre Großbuchstaben Š, Đ, Č, Ć, Ž (offiziell werden im Slowenischen nur č/Č, š/Š und ž/Ž verwendet, andere kommen jedoch bei Bedarf, vor allem in ausländischen Namen, zum Einsatz). Alle diese Buchstaben sind in Latin-2 und Windows-1250 definiert , während in der standardmäßigen Windows-1252 -Version nur einige (š, Š, ž, Ž, Đ) aufgrund anderer Sprachen vorhanden sind.

Obwohl Mojibake bei allen diesen Zeichen auftreten kann, sind die Buchstaben, die nicht in Windows-1252 enthalten sind, deutlich fehleranfälliger. Daher ŠĐČĆŽ šđčćžkann die Anzeige auf älteren Systemen selbst heute noch zu Fehlern führen ŠÐÈÆŽ šðèæž, obwohl ð, È und Æ in slawischen Sprachen nicht vorkommen.

Bei Verwendung des einfachen ASCII-Zeichensatzes (z. B. bei den meisten Benutzernamen) sind gängige Ersetzungen: š→s, đ→dj, č→c, ć→c, ž→z (bei Großbuchstaben analog, mit Đ→Dj oder Đ→DJ je nach Groß-/Kleinschreibung). Da all diese Ersetzungen Mehrdeutigkeiten erzeugen, wird die ursprüngliche Form bei Bedarf in der Regel manuell rekonstruiert.

Die Windows-1252 -Kodierung ist wichtig, da englische Versionen des Windows-Betriebssystems am weitesten verbreitet sind, nicht lokalisierte. Gründe hierfür sind ein relativ kleiner und fragmentierter Markt, die steigenden Kosten für hochwertige Lokalisierungen, ein hohes Maß an Softwarepiraterie (was wiederum durch die hohen Softwarepreise im Verhältnis zum Einkommen bedingt ist), was Lokalisierungsbemühungen hemmt, und die Tatsache, dass Nutzer englische Versionen von Windows und anderer Software bevorzugen.

Das Bestreben, Kroatisch von Serbisch, Bosnisch von Kroatisch und Serbisch und nun sogar Montenegrinisch von den anderen drei Sprachen zu unterscheiden , führt zu vielen Problemen. Es gibt zahlreiche Lokalisierungen mit unterschiedlichen Standards und Qualitätsstufen. Für die Vielzahl englischsprachiger Computerbegriffe existieren keine einheitlichen Übersetzungen. Letztendlich verwenden viele Menschen englische Lehnwörter („kompjuter“ für „Computer“, „kompajlirati“ für „kompilieren“ usw.), und wenn sie mit den übersetzten Begriffen nicht vertraut sind, verstehen sie möglicherweise nicht, welche Funktion eine Menüoption aufgrund der Übersetzung haben soll. Daher greifen englischsprachige Nutzer sowie diejenigen, die mit der englischen Terminologie vertraut sind (und das sind die meisten, da Englisch aufgrund dieser Probleme auch hauptsächlich in Schulen gelehrt wird), regelmäßig zu den englischen Originalversionen von Standardsoftware.

Bei Verwendung der kyrillischen Schrift (für Mazedonisch und teilweise Serbisch ) ist das Problem ähnlich wie bei anderen auf Kyrillisch basierenden Schriftsystemen .

Neuere englische Windows-Versionen ermöglichen die Änderung der Codepage (ältere Versionen benötigen spezielle englische Versionen mit dieser Unterstützung), jedoch kann diese Einstellung fehlerhaft sein und wurde es häufig auch. Beispielsweise lassen sich Windows 98 und Windows Me auf die meisten nicht von rechts nach links verlaufenden Single-Byte- Codepages, einschließlich 1250, einstellen, allerdings nur bei der Installation.

Eine weitere Art von Mojibake tritt auf, wenn Text, der in einer Einzelbyte-Kodierung vorliegt, fälschlicherweise in einer Mehrbyte-Kodierung, wie beispielsweise einer Kodierung für ostasiatische Sprachen, interpretiert wird . Bei dieser Art von Mojibake werden mehrere (typischerweise zwei) Zeichen gleichzeitig verfälscht. Wenn beispielsweise das schwedische Wort „ kärlek“ in Windows-1252 kodiert, aber mit GBK dekodiert wird, erscheint es als „k鋜lek“, wobei „ är “ als „鋜“ interpretiert wird. Im Vergleich zum oben genannten Mojibake ist dies schwerer lesbar, da Buchstaben fehlen, die nicht mit den problematischen Buchstaben å, ä oder ö in Verbindung stehen. Besonders problematisch ist dies bei kurzen Wörtern, die mit å, ä oder ö beginnen (z. B. wird aus „än“ „鋘“). Da zwei Buchstaben kombiniert werden, wirkt der Mojibake auch zufälliger (über 50 Varianten im Vergleich zu den üblichen drei, die selteneren Großbuchstaben nicht mitgerechnet). In seltenen Fällen kann ein ganzer Textstring, der zufällig ein Muster bestimmter Wortlängen enthält, wie zum Beispiel der Satz " Bush hid the facts ", falsch interpretiert werden.

Im Vietnamesischen wird dieses Phänomen als chữ ma ( Hán-Nôm : 𡨸魔Code: vie wurde zu Code: vi befördert, „Geisterzeichen“) oder loạn mã (vom Chinesischen 乱码, luànmǎ ) bezeichnet. Es kann auftreten, wenn ein Computer versucht, in UTF-8 kodierten Text als Windows-1258 , TCVN3 oder VNI zu dekodieren . In Vietnam war chữ ma häufig auf Computern mit älteren Windows-Versionen als Vista oder auf günstigen Mobiltelefonen zu beobachten.

In Japan stellt Mojibake ein besonderes Problem dar, da es viele verschiedene japanische Textkodierungen gibt. Neben Unicode (UTF-8 und UTF-16) existieren weitere Standardkodierungen wie Shift-JIS (Windows) und EUC-JP (UNIX). Auch heute noch stoßen Japaner wie Nicht-Japaner häufig auf Mojibake, wenn sie versuchen, für den japanischen Markt entwickelte Software auszuführen.

Im Chinesischen wird dasselbe Phänomen als Luàn mǎ ( Pinyin , vereinfachtes Chinesisch乱码, traditionelles Chinesisch亂碼, wörtlich „chaotischer Code“) bezeichnet und kann auftreten, wenn computerisierter Text in einer bestimmten chinesischen Zeichenkodierung codiert, aber mit der falschen Kodierung angezeigt wird. In diesem Fall lässt sich das Problem oft durch einen Wechsel der Zeichenkodierung ohne Datenverlust beheben. Die Situation wird durch die Existenz mehrerer chinesischer Zeichenkodierungssysteme verkompliziert, wobei Unicode , Big5 und Guobiao (mit mehreren abwärtskompatiblen Versionen) am weitesten verbreitet sind. Hinzu kommt die Möglichkeit, dass chinesische Zeichen mit japanischer Kodierung codiert werden.

Die ursprüngliche Kodierung lässt sich relativ leicht identifizieren, wenn luànmǎ in Guobiao-Kodierungen vorkommt:

Ein weiteres Problem im Chinesischen tritt auf, wenn seltene oder veraltete Schriftzeichen, von denen viele noch in Personen- oder Ortsnamen verwendet werden, in manchen Kodierungen nicht existieren. Beispiele hierfür sind:

• Das Fehlen des „煊“ ( xuān ) im Namen des taiwanesischen Politikers Wang Chien-shien (Chinesisch:王建煊; Pinyin: Wáng Jiànxuān ) in der Big5 -Kodierung und des „堃“ ( kūn ) im Namen von Yu Shyi-kun (vereinfachtes Chinesisch:游锡堃; traditionelles Chinesisch:游錫堃); Pinyin: Yóu Xíkūn ) und das „喆“ ( zhé ) im Namen des Sängers David Tao (Chinesisch:陶喆; Pinyin: Táo Zhé ),
• GB 2312 Fehlen des „镕“ ( róng ) im ehemaligen Premierminister der VR China, Zhu Rongji (chinesisch:朱镕基; Pinyin: Zhū Róngjī ), und
• GBKs fehlendes Copyright-Symbol „©“ . ^{[ 10 ]}

Zeitungen sind auf verschiedene Weise mit fehlenden Zeichen umgegangen, unter anderem durch den Einsatz von Bildbearbeitungssoftware, um diese durch die Kombination anderer Radikale und Zeichen zu synthetisieren; durch die Verwendung eines Bildes der Persönlichkeit (im Falle von Personennamen) oder durch einfaches Ersetzen durch Homophone in der Hoffnung, dass die Leser die richtige Schlussfolgerung ziehen könnten.

Ein ähnlicher Effekt kann in den Brahmic- oder indischen Schriften Südasiens auftreten, die in indoarischen oder indischen Sprachen wie Hindustani (Hindi-Urdu), Bengali , Punjabi , Marathi und anderen verwendet werden, selbst wenn der verwendete Zeichensatz von der Anwendung korrekt erkannt wird. Dies liegt daran, dass in vielen indischen Schriften die Regeln, nach denen einzelne Buchstabensymbole zu Silbensymbolen kombiniert werden, von einem Computer ohne die entsprechende Software möglicherweise nicht korrekt verstanden werden, selbst wenn die Glyphen für die einzelnen Buchstabenformen vorhanden sind.

Ein Beispiel hierfür ist das alte Wikipedia-Logo , das auf jedem seiner vielen Puzzleteile das Zeichen für „wi“ (die erste Silbe von „Wikipedia“) darstellen sollte. Das Puzzleteil, das das Devanagari -Zeichen für „wi“ zeigen sollte, zeigte stattdessen das Zeichen „wa“ gefolgt von einem einzelnen „i“ -Vokal , leicht erkennbar als Mojibake, das von einem Computer erzeugt wurde, der nicht für die Darstellung indischer Texte konfiguriert war. ^{[ 11 ]} Das im Mai 2010 überarbeitete Logo behebt diese Fehler.

Das Konzept von Klartext erfordert, dass das Betriebssystem eine Schriftart zur Darstellung von Unicode-Codes bereitstellt. Diese Schriftart ist für Singhala von Betriebssystem zu Betriebssystem unterschiedlich, was dazu führt, dass einige Buchstaben (Silben) auf allen Betriebssystemen orthografisch inkorrekte Glyphen erzeugen. Beispielsweise ist das „reph“, die Kurzform von „r“, ein diakritisches Zeichen, das normalerweise über einem normalen Buchstaben steht. In bestimmten Kontexten ist es jedoch falsch, es über Buchstaben wie „ya“ oder „la“ zu setzen. Bei Sanskrit-Wörtern oder -Namen, die von modernen Sprachen übernommen wurden, wie z. B. कार्य (IAST: kārya ) oder आर्या (IAST: āryā) , ist es hingegen korrekt, das Zeichen über diese Buchstaben zu setzen. Im Gegensatz dazu wird bei ähnlichen Lauten in modernen Sprachen, die sich aus ihren spezifischen Regeln ergeben, der Buchstabe nicht an den Anfang gesetzt, wie beispielsweise im Wort करणाऱ्या (IAST: karaṇāryā) , einer Stammform des gebräuchlichen Wortes करणारा/री (IAST: karaṇārā/rī ) in der Marathi-Sprache . ^{[ 12 ]} In den meisten Betriebssystemen tritt dieses Problem jedoch auf. Es scheint sich um einen Fehler in der internen Programmierung der Schriftarten zu handeln. Unter macOS und iOS führen die Kombination aus dem Muurdhaja-l (dunkles l) und dem u sowie dessen Langform zu fehlerhaften Darstellungen.

Einige indische und von indischen Schriften abgeleitete Schriftsysteme, insbesondere Lao , wurden von Windows XP erst mit der Veröffentlichung von Vista offiziell unterstützt . ^{[ 13 ]} Verschiedene Websites bieten jedoch kostenlos herunterladbare Schriftarten an.

Aufgrund westlicher Sanktionen ^{[ 14 ]} und der späten Einführung der burmesischen Sprachunterstützung in Computern ^{[ 15 , 16 ]} erfolgte ein Großteil der frühen burmesischen Lokalisierung ohne internationale Zusammenarbeit. Die gängigste Methode zur Unterstützung des Burmesischen war die Verwendung der Zawgyi-Schriftart , die ^zwar als Unicode-Schriftart entwickelt wurde , aber tatsächlich nur teilweise Unicode-konform war. ^{[ 16 ]} In der Zawgyi-Schriftart wurden einige Codepunkte für die burmesische Schrift gemäß Unicode implementiert , andere jedoch nicht. ^{[ 17 ]} Das Unicode-Konsortium bezeichnet dies als Ad-hoc-Schriftkodierung . ^{[ 18 ]} Mit dem Aufkommen von Mobiltelefonen ersetzten Hersteller wie Samsung und Huawei die Unicode-konformen Systemschriftarten einfach durch Zawgyi-Versionen. ^{[ 15 ]}

Aufgrund dieser improvisierten Kodierungen würde die Kommunikation zwischen Nutzern von Zawgyi und Unicode zu fehlerhaftem Text führen. Um dieses Problem zu umgehen, veröffentlichten Content-Ersteller Beiträge sowohl in Zawgyi als auch in Unicode. ^{[ 19 ]} Die Regierung Myanmars legte den 1. Oktober 2019 als „U-Day“ für die offizielle Umstellung auf Unicode fest. ^{[ 14 ]} Der vollständige Übergang sollte schätzungsweise zwei Jahre dauern. ^{[ 20 ]}

In einigen afrikanischen Schriftsystemen ist unkodierter Text unlesbar. Zu den Texten, die Mojibake erzeugen können, gehören solche vom Horn von Afrika wie die Ge'ez-Schrift in Äthiopien und Eritrea , die für Amharisch , Tigre und andere Sprachen verwendet wird, sowie die somalische Sprache , die das Osmanya-Alphabet nutzt . Im südlichen Afrika wird das Mwangwego-Alphabet für die Sprachen Malawis verwendet , und das Mandombe-Alphabet wurde für die Demokratische Republik Kongo entwickelt; diese werden jedoch nicht allgemein unterstützt. Verschiedene andere in Westafrika beheimatete Schriftsysteme weisen ähnliche Probleme auf, wie beispielsweise das N'Ko-Alphabet für die Manding-Sprachen in Guinea und die Vai-Silbenschrift in Liberia .

Eine weitere betroffene Sprache ist Arabisch (siehe unten ), in dem ein Text völlig unlesbar wird, wenn die Kodierungen nicht übereinstimmen.

Arabisches Beispiel	Browser-Rendering	Quellenkodierung	Zielkodierung	Ergebnis
( Allgemeine Erklärung der Menschenrechte )	Die Lösung ist nicht verfügbar	UTF-8	KOI8-R	ь╖ы└ь╔ь╧ы└ь╖ы├ ь╖ы└ь╧ь╖ы└ы┘ы┴ ы└ь╜ы┌ы┬ы┌ ь╖ы└ь╔ы├ьЁь╖ы├
		UTF-8	Windows-1250	الإعلان العالمى Ů„ŘŮ‚ŮˆŮ‚ الإنسان
		UTF-8	Windows-1251	Ш§Щ„ШҐШ№Щ„Ш§Щ† Ш§Щ„Ш№Ш§Щ„Щ…Щ‰ Щ„ШЩ‚Щ€Щ‚ Ш§Щ„ШҐЩ†ШіШ§Щ†
		UTF-8	Windows-1252	الإعلان العالمى Ù„Øقوق الإنسان
		UTF-8	Windows-1256	ط§ظ„ط¥ط¹ظ„ط§ظ† ط§ظ„ط¹ط§ظ„ظ…ظ‰ ظ„طظ‚ظˆظ‚ ط§ظ„ط¥ظ†ط³ط§ظ†
		UTF-8	ISO 8859-5	иЇй�иЅиЙй�иЇй� иЇй�иЙиЇй�й�й� й�ий�й�й� иЇй�иЅй�иГиЇй�
		UTF-8	ISO 8859-6	ظ�ع„ظ�ظ�ع„ظ�ع† ظ�ع„ظ�ظ�ع„ع…ع‰ ع„ظع‚عˆع‚ ظ�ع„ظ�ع†ظ�ظ�ع†
		UTF-8	CP 852	ěž┘äěąě╣┘äěž┘ć ěž┘äě╣ěž┘ä┘ů┘ë ┘äěş┘é┘ł┘é ěž┘äěą┘ćě│ěž┘ć
		UTF-8	CP 866	╪з┘Д╪е╪╣┘Д╪з┘Ж ╪з┘Д╪╣╪з┘Д┘Е┘Й ┘Д╪н┘В┘И┘В ╪з┘Д╪е┘Ж╪│╪з┘Ж
		UTF-8	Mac Arabic	ظ'عÑظ٪ظ٩عÑظ'عÜ ظ'عÑظ٩ظ'عÑعÖعâ عÑظ-عÇعàعÇ ظ'عÑظ٪عÜظ٣ظ'عÜ
		UTF-8	Mac Roman	الإعلان العالمى لحقوق الإنسان
		Mac Arabic	Mac Roman	«‰≈Ÿ‰«Ê†«‰Ÿ«‰ÂȆ‰Õ‚Ë‚†«‰≈Ê“«Ê
		Windows-1256	Mac Roman	«·≈⁄·«‰ «·⁄«·„Ï ·ÕfiÊfi «·≈‰“«‰
			Windows-1252	ÇáÅÚáÇä ÇáÚÇáãì áÍÞæÞ ÇáÅäÓÇä

The examples in this article do not have UTF-8 as browser setting, because UTF-8 is easily recognisable, so if a browser supports UTF-8 it should recognise it automatically, and not try to interpret something else as UTF-8.

• Code point
• Replacement character
• Substitute character
• Newline – The conventions for representing the line break differ between Windows and Unix systems. Though most software supports both conventions (which is trivial), software that must preserve or display the difference (e.g. version control systems and data comparison tools) can get substantially more difficult to use if not adhering to one convention.
• Byte order mark – The most in-band way to store the encoding together with the data – prepend it. This is by intention invisible to humans using compliant software, but will by design be perceived as "garbage characters" to incompliant software (including many interpreters).
• HTML entities – An encoding of special characters in HTML, mostly optional, but required for certain characters to escape interpretation as markup. While failure to apply this transformation is a vulnerability (see cross-site scripting), applying it too many times results in garbling of these characters. For example, the quotation mark " becomes ", ", ", ", and so on.
• Bush hid the facts

• Die Wörterbuchdefinition von Mojibake bei Wiktionary
• Medien zum Thema Mojibake auf Wikimedia Commons