Mojibake - Mojibake

Der UTF-8- codierte japanische Wikipedia-Artikel für Mojibake wird angezeigt, wenn er als Windows-1252- Codierung interpretiert wird

Mojibake (文字化け; IPA:  [mod͡ʑibake] ) ist der verstümmelte Text, der das Ergebnis einer Decodierung von Text mit einer unbeabsichtigten Zeichencodierung ist . Das Ergebnis ist ein systematischer Ersatz von Symbolen durch völlig unzusammenhängende, oft aus einem anderen Schriftsystem .

Diese Anzeige kann an Stellen, an denen die binäre Darstellung als ungültig erachtet wird, das generische Ersetzungszeichen (" ") enthalten. Eine Ersetzung kann auch mehrere aufeinanderfolgende Symbole umfassen, wie in einer Codierung betrachtet, wenn der gleiche Binärcode ein Symbol in der anderen Codierung bildet. Dies liegt entweder an der unterschiedlichen Codierung mit konstanter Länge (wie bei asiatischen 16-Bit-Codierungen im Vergleich zu europäischen 8-Bit-Codierungen) oder an der Verwendung von Codierungen mit variabler Länge (insbesondere UTF-8 und UTF-16 ).

Das fehlgeschlagene Rendern von Glyphen aufgrund fehlender Schriftarten oder fehlender Glyphen in einer Schriftart ist ein anderes Problem, das nicht mit Mojibake zu verwechseln ist. Zu den Symptomen dieses fehlgeschlagenen Renderns gehören Blöcke, bei denen der Codepunkt hexadezimal angezeigt wird oder das generische Ersetzungszeichen verwendet. Wichtig ist, dass diese Ersetzungen gültig sind und das Ergebnis einer korrekten Fehlerbehandlung durch die Software sind.

Etymologie

Mojibake bedeutet auf Japanisch "Charaktertransformation" . Das Wort besteht aus文字(moji, IPA:  [mod͡ʑi] ) "Zeichen" und化け(bake, IPA:  [Bake] , ausgesprochen "BAH-keh"), "transformieren".

Ursachen

Um den kodierten Originaltext korrekt zu reproduzieren, muss die Übereinstimmung zwischen den kodierten Daten und dem Begriff ihrer Kodierung erhalten bleiben. Da Mojibake der Fall der Nichteinhaltung zwischen diesen ist, kann dies durch Manipulation der Daten selbst oder durch einfaches Umbenennen erreicht werden.

Mojibake wird oft mit Textdaten gesehen, die mit einer falschen Codierung versehen wurden; es wird möglicherweise überhaupt nicht getaggt, sondern zwischen Computern mit unterschiedlichen Standardcodierungen verschoben. Eine Hauptursache für Probleme sind Kommunikationsprotokolle , die auf Einstellungen auf jedem Computer angewiesen sind, anstatt Metadaten zusammen mit den Daten zu senden oder zu speichern .

Die unterschiedlichen Standardeinstellungen zwischen den Computern sind teilweise auf unterschiedliche Bereitstellungen von Unicode in den Betriebssystemfamilien und teilweise auf die Spezialisierungen der Legacy-Kodierungen für verschiedene Schreibsysteme menschlicher Sprachen zurückzuführen. Während Linux-Distributionen im Jahr 2004 hauptsächlich auf UTF-8 umgestellt wurden , verwendet Microsoft Windows im Allgemeinen UTF-16 und verwendet manchmal 8-Bit-Codepages für Textdateien in verschiedenen Sprachen.

Für einige Schreibsysteme , beispielsweise Japanisch , wurden in der Vergangenheit mehrere Kodierungen verwendet, die dazu führten, dass Benutzer relativ oft Mojibake sehen. Als japanisches Beispiel könnte das als EUC-JP gespeicherte Wort mojibake "文字化け" fälschlicherweise als "ハクサ ス、ア", "ハクサ嵂ス、ア" ( MS-932 ) oder "ハクサ郾ス、ア ." angezeigt werden " ( Verschiebung JIS-2004 ). Derselbe als UTF-8 gespeicherte Text wird als "譁 蟄怜喧縺 " angezeigt, wenn er als Shift JIS interpretiert wird. Dies wird noch verschlimmert, wenn andere Gebietsschemas beteiligt sind: Derselbe UTF-8-Text erscheint als "æ–‡å—化ã??'" in Software, die davon ausgeht, dass der Text in der Windows-1252- oder ISO-8859-1- Kodierung vorliegt , normalerweise als Western bezeichnet oder (zum Beispiel) als "鏂囧瓧鍖栥亼", wenn es in einem GBK- Gebietsschema (Festlandchina) interpretiert wird .

Mojibake-Beispiel
Original Text
Rohbytes der EUC-JP-Kodierung CA B8 BB FA B2 BD A4 B1
Als Shift-JIS-Codierung interpretierte Bytes Ich
Bytes interpretiert als ISO-8859-1-Kodierung Ê ¸ » ú ² ½ ¤ ±
Als GBK-Kodierung interpretierte Bytes

Unterspezifikation

Wenn die Kodierung nicht angegeben ist, liegt es an der Software, dies auf andere Weise zu entscheiden. Je nach Softwaretyp ist die typische Lösung entweder eine Konfigurations- oder Zeichensatzerkennungsheuristik . Beide sind in nicht so ungewöhnlichen Szenarien anfällig für Fehlprognosen.

Die Kodierung von Textdateien wird durch die Gebietsschemaeinstellung beeinflusst , die von der Sprache des Benutzers, der Marke des Betriebssystems und möglicherweise anderen Bedingungen abhängt. Daher ist die angenommene Kodierung systematisch falsch für Dateien, die von einem Computer mit einer anderen Einstellung oder sogar von einer anders lokalisierten Software innerhalb desselben Systems stammen. Für Unicode besteht eine Lösung darin, eine Bytereihenfolgemarkierung zu verwenden , aber für Quellcode und anderen maschinenlesbaren Text tolerieren viele Parser dies nicht. Ein anderer ist das Speichern der Kodierung als Metadaten im Dateisystem. Dateisysteme, die erweiterte Dateiattribute unterstützen, können diese als user.charset. Dies erfordert auch Unterstützung in Software, die davon profitieren möchte, aber andere Software nicht stört.

Während einige wenige Kodierungen leicht zu erkennen sind, insbesondere UTF-8, gibt es viele, die schwer zu unterscheiden sind (siehe Zeichensatzerkennung ). Ein Webbrowser ist möglicherweise nicht in der Lage, eine in EUC-JP codierte Seite und eine andere in Shift-JIS zu unterscheiden, wenn das Codierungsschema nicht explizit über HTTP-Header zugewiesen wird, die mit den Dokumenten gesendet werden, oder über die Meta-Tags des HTML- Dokuments , die verwendet werden, um ersetzen fehlende HTTP-Header, wenn der Server nicht zum Senden der richtigen HTTP-Header konfiguriert werden kann; siehe Zeichenkodierungen in HTML .

Falsche Spezifikation

Mojibake tritt auch auf, wenn die Codierung falsch angegeben ist. Dies geschieht häufig zwischen ähnlichen Codierungen. Zum Beispiel war bekannt, dass der Eudora- E-Mail-Client für Windows E-Mails mit der Bezeichnung ISO-8859-1 sendete , die in Wirklichkeit Windows-1252 waren . Die Mac OS-Version von Eudora zeigte dieses Verhalten nicht. Windows-1252 enthält zusätzliche druckbare Zeichen im C1- Bereich (am häufigsten sind gebogene Anführungszeichen und zusätzliche Bindestriche ), die in Software, die dem ISO-Standard entspricht, nicht richtig angezeigt wurden; dies betraf insbesondere Software, die unter anderen Betriebssystemen wie zB Unix läuft .

Menschliche Unwissenheit

Von den noch verwendeten Codierungen sind viele teilweise miteinander kompatibel, wobei ASCII die vorherrschende gemeinsame Untermenge ist. Dies bereitet die Bühne für menschliche Ignoranz:

  • Kompatibilität kann eine trügerische Eigenschaft sein, da die gemeinsame Teilmenge von Zeichen durch eine Verwechslung zweier Codierungen nicht beeinträchtigt wird (siehe Probleme in verschiedenen Schriftsystemen ).
  • Die Leute denken, dass sie ASCII verwenden, und neigen dazu, jede Obermenge von ASCII, die sie tatsächlich verwenden, als "ASCII" zu bezeichnen. Vielleicht zur Vereinfachung, aber auch in der akademischen Literatur findet sich das Wort "ASCII" als Beispiel für etwas, das nicht mit Unicode kompatibel ist, wobei "ASCII" offensichtlich Windows-1252 und "Unicode" UTF-8 ist. Beachten Sie, dass UTF-8 ist nach hinten mit ASCII kompatibel.

Überspezifikation

Wenn es Protokollschichten gibt, von denen jede versucht, die Kodierung basierend auf unterschiedlichen Informationen zu spezifizieren, können die am wenigsten bestimmten Informationen für den Empfänger irreführend sein. Stellen Sie sich beispielsweise einen Webserver vor, der eine statische HTML-Datei über HTTP bereitstellt. Der Zeichensatz kann dem Client auf drei verschiedene Arten mitgeteilt werden:

  • im HTTP-Header. Diese Informationen können auf der Serverkonfiguration basieren (z. B. beim Bereitstellen einer Datei außerhalb des Datenträgers) oder durch die auf dem Server ausgeführte Anwendung (für dynamische Websites) gesteuert werden.
  • in der Datei, als HTML-Meta-Tag ( http-equivoder charset) oder als encodingAttribut einer XML- Deklaration. Dies ist die Codierung, in der der Autor die bestimmte Datei speichern wollte.
  • in der Datei als Byte-Reihenfolgemarkierung . Dies ist die Kodierung, in der der Editor des Autors sie tatsächlich gespeichert hat. Sofern keine versehentliche Kodierungskonvertierung stattgefunden hat (indem sie in einer Kodierung geöffnet und in einer anderen gespeichert wurde), ist dies korrekt. Es ist jedoch nur in Unicode- Kodierungen wie UTF-8 oder UTF-16 verfügbar .

Fehlende Hardware- oder Softwareunterstützung

Viel ältere Hardware ist normalerweise so ausgelegt, dass sie nur einen Zeichensatz unterstützt, und der Zeichensatz kann normalerweise nicht geändert werden. Die in der Display-Firmware enthaltene Zeichentabelle wird so lokalisiert, dass sie Zeichen für das Land enthält, in dem das Gerät verkauft werden soll, und in der Regel unterscheidet sich die Tabelle von Land zu Land. Daher zeigen diese Systeme möglicherweise Mojibake an, wenn Text geladen wird, der auf einem System aus einem anderen Land generiert wurde. Ebenso unterstützen viele frühe Betriebssysteme nicht mehrere Kodierungsformate und zeigen daher am Ende Mojibake an, wenn sie nicht standardmäßigen Text anzeigen – frühe Versionen von Microsoft Windows und Palm OS zum Beispiel sind länderspezifisch lokalisiert und werden nur unterstützt Kodierungsstandards, die für das Land relevant sind, in dem die lokalisierte Version verkauft wird, und zeigt Mojibake an, wenn eine Datei geöffnet wird, die einen Text in einem anderen Kodierungsformat als der Version, die das Betriebssystem unterstützen soll, enthält.

Auflösungen

Anwendungen, die UTF-8 als Standardcodierung verwenden, können aufgrund der weit verbreiteten Verwendung und Abwärtskompatibilität mit US-ASCII möglicherweise ein höheres Maß an Interoperabilität erreichen . UTF-8 kann auch von einem einfachen Algorithmus direkt erkannt werden, sodass gut geschriebene Software in der Lage sein sollte, UTF-8 nicht mit anderen Kodierungen zu vermischen.

Die Schwierigkeit, einen Mojibake-Vorfall zu beheben, hängt von der Anwendung ab, in der er auftritt, und den Ursachen dafür. Zwei der häufigsten Anwendungen, in denen Mojibake vorkommen kann, sind Webbrowser und Textverarbeitungsprogramme . Moderne Browser und Textverarbeitungsprogramme unterstützen oft eine Vielzahl von Zeichenkodierungen. Browser ermöglichen es einem Benutzer häufig, die Codierungseinstellungen ihrer Rendering-Engine im Handumdrehen zu ändern , während Textverarbeitungsprogramme es dem Benutzer ermöglichen, beim Öffnen einer Datei die geeignete Codierung auszuwählen. Es kann einige Versuche dauern, bis Benutzer die richtige Codierung finden.

Komplizierter wird das Problem, wenn es in einer Anwendung auftritt, die normalerweise keine breite Palette von Zeichenkodierungen unterstützt, wie beispielsweise in einem Nicht-Unicode-Computerspiel. In diesem Fall muss der Benutzer die Codierungseinstellungen des Betriebssystems an die des Spiels anpassen. Das Ändern der systemweiten Codierungseinstellungen kann jedoch auch Mojibake in bereits vorhandenen Anwendungen verursachen. In Windows XP oder höher hat ein Benutzer auch die Möglichkeit, Microsoft AppLocale zu verwenden , eine Anwendung, mit der die Gebietsschemaeinstellungen pro Anwendung geändert werden können. Trotzdem ist das Ändern der Codierungseinstellungen des Betriebssystems auf früheren Betriebssystemen wie Windows 98 nicht möglich ; Um dieses Problem auf früheren Betriebssystemen zu beheben, müsste ein Benutzer Schriftarten-Rendering-Anwendungen von Drittanbietern verwenden.

Probleme in verschiedenen Schriftsystemen

Englisch

Mojibake in englischen Texten tritt in der Regel in der Zeichensetzung, wie em Striche (-), en Bindestriche (-) und typografische Anführungszeichen ( „“, ''), aber nur selten in Zeichen Text, da die meisten Codierungen Übereinstimmen mit ASCII auf dem Kodierung des englischen Alphabets . Das Rautezeichen "£" wird beispielsweise als "£" angezeigt, wenn es vom Sender als UTF-8 kodiert wurde, aber vom Empfänger als CP1252 oder ISO 8859-1 interpretiert wurde . Bei Iteration mit CP1252 kann dies zu "£", "£", "ÃÆ'‚£" usw.

Einige Computer hatten in älteren Epochen herstellerspezifische Kodierungen, die auch bei englischem Text zu Fehlanpassungen führten. 8-Bit- Computer der Marke Commodore verwendeten die PETSCII- Codierung, die insbesondere für die Invertierung der Groß- und Kleinschreibung im Vergleich zu Standard- ASCII bemerkenswert ist . PETSCII-Drucker funktionierten auf anderen Computern der Ära gut, drehten jedoch die Groß-/Kleinschreibung aller Buchstaben um. IBM Mainframes verwenden die EBCDIC- Codierung, die überhaupt nicht mit ASCII übereinstimmt.

Andere westeuropäische Sprachen

Die Alphabete der nordgermanischen Sprachen , Katalanisch , Finnisch , Deutsch , Französisch , Portugiesisch und Spanisch sind alle Erweiterungen des lateinischen Alphabets . Die zusätzlichen Zeichen sind in der Regel diejenigen, die beschädigt werden, wodurch Texte mit Mojibake nur leicht unlesbar werden:

… und ggf. deren Pendants in Großbuchstaben.

Dies sind Sprachen, für die der Zeichensatz ISO-8859-1 (auch als Latin 1 oder Western bekannt ) verwendet wurde. ISO-8859-1 wurde jedoch von zwei konkurrierenden Standards überholt, dem abwärtskompatiblen Windows-1252 und dem leicht veränderten ISO-8859-15 . Beide fügen das Eurozeichen € und das französische œ hinzu, aber ansonsten führt jede Verwechslung dieser drei Zeichensätze nicht zu Mojibake in diesen Sprachen. Darüber hinaus ist es immer sicher, ISO-8859-1 als Windows-1252 zu interpretieren, und ziemlich sicher als ISO-8859-15, insbesondere in Bezug auf das Eurozeichen, das das selten verwendete Währungszeichen (¤) ersetzt. . Mit dem Aufkommen von UTF-8 ist Mojibake jedoch in bestimmten Szenarien häufiger geworden, zB beim Austausch von Textdateien zwischen UNIX- und Windows- Computern, aufgrund der Inkompatibilität von UTF-8 mit Latin-1 und Windows-1252. Aber UTF-8 kann von einem einfachen Algorithmus direkt erkannt werden, so dass gut geschriebene Software in der Lage sein sollte, UTF-8 nicht mit anderen Kodierungen zu vermischen. Dies war also am häufigsten, als viele Software hatten, die UTF-8 nicht unterstützte. Die meisten dieser Sprachen wurden vom MS-DOS-Standard CP437 und anderen Computer-Standardcodierungen außer ASCII unterstützt, so dass Probleme beim Kauf einer Betriebssystemversion weniger häufig waren. Windows und MS-DOS sind jedoch nicht kompatibel.

Im Schwedischen, Norwegischen, Dänischen und Deutschen werden Vokale selten wiederholt, und es ist normalerweise offensichtlich, wenn ein Zeichen verfälscht wird, zB der zweite Buchstabe in "kärlek" ( kärlek , "Liebe"). Auf diese Weise bleiben fast alle Texte lesbar, auch wenn der Leser zwischen å, ä und ö raten muss. Finnischer Text hingegen enthält sich wiederholende Vokale in Wörtern wie hääyö ("Hochzeitsnacht"), was den Text manchmal sehr schwer lesbar machen kann ( zB erscheint hääyö als "hääääyö"). Isländisch und Färöisch haben zehn bzw. acht möglicherweise verwechselnde Zeichen, was es daher schwieriger machen kann, verfälschte Zeichen zu erraten; Isländische Wörter wie þjóðlöð ("herausragende Gastfreundschaft") werden fast völlig unverständlich, wenn sie als "þjóðlöð" wiedergegeben werden.

Im Deutschen ist Buchstabensalat ein gebräuchlicher Begriff für dieses Phänomen und im Spanischen deformación (wörtlich Deformation).

Einige Benutzer transliterieren ihre Schrift, wenn sie einen Computer verwenden, indem sie entweder die problematischen diakritischen Zeichen weglassen oder Digraph-Ersetzungen verwenden (å → aa, ä/æ → ae, ö/ø → oe, ü → ue usw.). So könnte ein Autor "ueber" statt "über" schreiben, was im Deutschen Standard ist, wenn keine Umlaute verfügbar sind. Letztere Praxis scheint im deutschen Sprachraum besser geduldet zu werden als in den nordischen Ländern . Im Norwegischen werden Digraphen beispielsweise mit archaischem Dänisch in Verbindung gebracht und können scherzhaft verwendet werden. Digraphen sind jedoch bei der Kommunikation mit anderen Teilen der Welt nützlich. Als Beispiel trug der norwegische Fußballspieler Ole Gunnar Solskjær seinen Namen auf dem Rücken, als er für Manchester United spielte .

Ein Artefakt von UTF-8, das als ISO-8859-1 fehlinterpretiert wurde , "Ring meg " (" Ring meg nå "), wurde im Juni 2014 in einem SMS-Betrug in Norwegen gesehen.

Beispiele
Schwedisches Beispiel: Smörgås ( offenes Sandwich )
Dateicodierung Einstellung im Browser Ergebnis
MS-DOS 437 ISO 8859-1 Sm"rg†s
ISO 8859-1 Mac Roman SmˆrgÂs
UTF-8 ISO 8859-1 Smörg¥s
UTF-8 Mac Roman Smörgås

Mittel- und Osteuropa

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

ungarisch

Ungarisch ist eine weitere betroffene Sprache, die die 26 englischen Grundzeichen plus die akzentuierten Formen á, é, í, ó, ú, ö, ü (alle im Zeichensatz Latin-1 vorhanden) plus die beiden Zeichen ő und ű verwendet , die nicht in Latein-1 sind. Diese beiden Zeichen können in Latin-2, Windows-1250 und Unicode korrekt codiert werden. Bevor Unicode in E-Mail-Clients üblich wurde, waren in E-Mails mit ungarischem Text oft die Buchstaben ő und ű beschädigt, manchmal bis zur Unkenntlichkeit. Es ist üblich, auf eine E-Mail, die unlesbar gemacht wurde (siehe Beispiele unten), durch Zeichenverstümmelung (bezeichnet als "betűszemét", was "Briefmüll" bedeutet) mit der Phrase "Árvíztűrő tükörfúrógép", einer unsinnigen Phrase (wörtlich "Flood- widerstandsfähige Spiegelbohrmaschine") mit allen im Ungarischen verwendeten Akzentzeichen.

Beispiele
Quellcodierung Zielcodierung Ergebnis Auftreten
Ungarisches Beispiel ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP
árvíztűrő tükörfúrógép
Rot dargestellte Zeichen sind falsch und stimmen nicht mit dem Beispiel oben links überein.
CP 852 CP 437 RV ZT δ R è TÜKÖRF Θ R α GÉP
árvízt r ï tükörfúrógép
Dies war in der DOS- Ära sehr üblich, als der Text mit der mitteleuropäischen CP 852- Kodierung kodiert wurde; das Betriebssystem , eine Software oder ein Drucker verwendeten jedoch die Standardcodierung CP 437 . Bitte beachten Sie, dass hauptsächlich Kleinbuchstaben korrekt sind, Ausnahmen mit ő (ï) und ű (√). Ü/ü ist richtig, weil CP 852 deutschkompatibel gemacht wurde. Heutzutage kommt es hauptsächlich auf gedruckten Rezepten und Schecks vor.
CWI-2 CP 437 Å RV ì ZT ÿ R º TÜKÖRF ù R ò GÉP
árvízt û r ô tükörfúrógép
Die CWI-2- Kodierung wurde so konzipiert, dass der Text auch dann gut lesbar bleibt, wenn das Display oder der Drucker die standardmäßige CP 437- Kodierung verwendet. Diese Codierung wurde in den 1980er und frühen 1990er Jahren stark verwendet, ist aber heute völlig veraltet.
Windows-1250 Windows-1252 ÁRVÍZT Û R Õ TÜKÖRFÚRÓGÉP
árvízt û r õ tükörfúrógép
Anstelle der mitteleuropäischen wird die standardmäßige westliche Windows-Codierung verwendet. Nur ő-Ő (õ-Õ) und ű-Ű (û-Û) sind falsch, aber der Text ist vollständig lesbar. Dies ist heutzutage der häufigste Fehler; aus Unwissenheit kommt es oft auf Webseiten oder sogar in gedruckten Medien vor.
CP 852 Windows-1250 µ RV Ö ZT ë R Š T š K RF é R ŕ G?? P
rv ztűr < t ?? k " rf Ł r ˘ g p
Anstelle der DOS-Kodierung wird die mitteleuropäische Windows-Kodierung verwendet. Die Verwendung von ű ist richtig.
Windows-1250 CP 852 RV ZT R Ň T K Í RF R Ë G P
ß rv Ý ztűr § t Ř k ÷ rf ˙ r g Ú p
Anstelle der Windows-Kodierung wird die mitteleuropäische DOS-Kodierung verwendet. Die Verwendung von ű ist richtig.
Zitat-druckbar 7-Bit- ASCII =C1 RV =CD ZT =DB R =D5 T =DC K =D6 RF =DA R =D3 G =C9 P
=E1 rv =ED zt =FB r =F5 t =FC k =F6 rf =FA r =F3 g =E9 p
Wird hauptsächlich durch falsch konfigurierte Mailserver verursacht, kann aber auch auf einigen Mobiltelefonen in SMS- Nachrichten auftreten .
UTF-8 Windows-1252 à ??RV à ??ZT Å° R Å ?? T Ãœ K Ö RF Ú R Ã" G É P
á rv à zt ű r Å' t ü k ö rf ú r ó g é p
Hauptsächlich verursacht durch falsch konfigurierte Webservices oder Webmail-Clients, die nicht für den internationalen Einsatz getestet wurden (da das Problem bei englischen Texten verborgen bleibt). In diesem Fall liegt der eigentliche (oft generierte) Inhalt in UTF-8 vor ; es ist jedoch nicht in den HTML- Headern konfiguriert , daher zeigt die Rendering-Engine es mit der standardmäßigen Western-Codierung an.

Polieren

Vor der Schaffung von ISO 8859-2 im Jahr 1987 verwendeten Benutzer verschiedener Computerplattformen ihre eigenen Zeichencodierungen wie AmigaPL auf Amiga, Atari Club auf Atari ST und Masovia, IBM CP852 , Mazovia und Windows CP1250 auf IBM-PCs. Polnische Unternehmen, die frühe DOS- Computer verkauften, entwickelten ihre eigenen, miteinander inkompatiblen Methoden zur Kodierung polnischer Zeichen und programmierten einfach die EPROMs der Grafikkarten (normalerweise CGA , EGA oder Hercules ) um, um Hardware-Codepages mit den erforderlichen Glyphen für Polnisch bereitzustellen – willkürlich ohne Hinweis darauf, wo andere Computerverkäufer sie platziert hatten.

Die Situation begann sich zu verbessern, als sich auf Druck von Wissenschaftlern und Anwendergruppen die ISO 8859-2 als "Internetstandard" mit eingeschränkter Unterstützung der Software der dominierenden Hersteller durchsetzte (heute weitgehend durch Unicode ersetzt). Angesichts der zahlreichen Probleme, die durch die Vielfalt der Kodierungen verursacht werden, neigen einige Benutzer auch heute noch dazu, polnische diakritische Zeichen als krzaczki ([kshach-kih], wörtlich "kleine Sträucher") zu bezeichnen.

Russische und andere kyrillische Alphabete

Mojibake kann umgangssprachlich Krakozyabry ( кракозя́бры .) genannt werden [krɐkɐˈzʲæbrɪ̈] ) auf Russisch , die durch mehrere Systeme zur Kodierung von Kyrillisch kompliziert wurde und bleibt. Die Sowjetunion und die frühe Russische Föderation entwickelten KOI-Kodierungen ( Kod Obmena Informatsiey , Код Обмена Информацией , was übersetzt "Code für den Informationsaustausch" bedeutet). Dies begann mit nur kyrillischer 7-Bit- KOI7 , basierend auf ASCII, aber mit lateinischen und einigen anderen Zeichen, die durch kyrillische Buchstaben ersetzt wurden. Dann kam die 8-Bit- KOI8- Codierung, die eine ASCII-Erweiterung ist, die kyrillische Buchstaben nur mit High-Bit-Set-Oktetts codiert, die 7-Bit-Codes von KOI7 entsprechen. Aus diesem Grund bleibt KOI8-Text, auch Russisch, nach dem Entfernen des achten Bits teilweise lesbar, was im Zeitalter von 8BITMIME- unbewussten E-Mail-Systemenals großer Vorteil angesehen wurde. Zum Beispiel werden die Wörter " Школа русского языка " shkola russkogo yazyka , die in KOI8 codiert und dann den High-Bit-Stripping-Prozess durchlaufen haben, als "[KOLA RUSSKOGO qZYKA" gerendert. Schließlich erhielt KOI8 verschiedene Geschmacksrichtungen für Russisch und Bulgarisch ( KOI8-R ), Ukrainisch ( KOI8-U ), Weißrussisch (KOI8-RU) und sogar Tadschikisch (KOI8-T).

Inzwischen im Westen, Codepage 866 unterstützt Ukrainisch und Belarusian sowie Russisch / Bulgarisch in MS-DOS . Für Microsoft Windows hat Codepage 1251 Unterstützung für serbische und andere slawische Varianten von Kyrillisch hinzugefügt .

In jüngster Zeit enthält die Unicode- Codierung Codepunkte für praktisch alle Zeichen aller Sprachen der Welt, einschließlich aller kyrillischen Zeichen.

Vor Unicode war es notwendig, die Textkodierung mit einer Schriftart abzugleichen, die dasselbe Kodierungssystem verwendet. Geschieht dies nicht, entstand unlesbares Kauderwelsch, dessen spezifisches Aussehen je nach der genauen Kombination von Textkodierung und Schriftkodierung variierte. Wenn Sie beispielsweise versuchen, kyrillischen Nicht-Unicode-Text mit einer Schriftart anzuzeigen, die auf das lateinische Alphabet beschränkt ist, oder mit der standardmäßigen ("westlichen") Kodierung, führt dies normalerweise zu Text, der fast ausschließlich aus Vokalen mit diakritischen Zeichen besteht. (KOI8 " Библиотека " ( biblioteka , Bibliothek) wird zu "âÉÂÌÉÏÔÅËÁ".) Die Verwendung der Windows-Codepage 1251 zum Anzeigen von Text in KOI8 oder umgekehrt führt zu einem verstümmelten Text, der hauptsächlich aus Großbuchstaben besteht (KOI8 und Codepage 1251 teilen die gleiche ASCII-Region, aber KOI8 hat Großbuchstaben in der Region, in der Codepage 1251 Kleinbuchstaben hat und umgekehrt). Im Allgemeinen ist kyrillisches Kauderwelsch symptomatisch für die Verwendung der falschen kyrillischen Schriftart. In den frühen Jahren des russischen Sektors des World Wide Web waren sowohl KOI8 als auch Codepage 1251 üblich. Ab 2017 kann man noch HTML-Seiten in Codepage 1251 und selten KOI8-Kodierungen sowie Unicode antreffen. (Schätzungsweise 1,7% aller Webseiten weltweit – alle Sprachen eingeschlossen – sind in Codepage 1251 kodiert.) Obwohl der HTML-Standard die Möglichkeit beinhaltet, die Kodierung für jede beliebige Webseite im Quellcode anzugeben, wird dies manchmal vernachlässigt, was den Benutzer zwingt, Codierungen im Browser manuell umzuschalten.

Auf Bulgarisch wird Mojibake oft majmunica ( маймуница ) genannt, was "Affen [Alphabet]" bedeutet. Auf Serbisch heißt es đubre ( ђубре ), was so viel wie „ Müll “ bedeutet. Anders als in der ehemaligen UdSSR verwendeten Südslawen nie etwas wie KOI8, und Codepage 1251 war dort vor Unicode die vorherrschende kyrillische Kodierung. Daher traten bei diesen Sprachen weniger Codierungsinkompatibilitätsprobleme auf als bei Russisch. In den 1980er Jahren verwendeten bulgarische Computer ihre eigene MIK-Codierung , die oberflächlich CP866 ähnelt (wenn auch nicht mit ihr kompatibel ist).

Beispiel
Russisches Beispiel: Кракозябры ( krakozyabry , Müllzeichen )
Dateicodierung Einstellung im Browser Ergebnis
MS-DOS 855 ISO 8859-1 Æá ÆÖóÞ¢áñ
KOI8-R ISO 8859-1 ÂÒÙ
UTF-8 KOI8-R п я─п╟п╨п╬п╥я▐п╠я─я▀

Jugoslawische Sprachen

Kroatisch , Bosnisch , Serbisch (die Dialekte der jugoslawischen serbokroatischen Sprache) und Slowenisch fügen dem lateinischen Grundalphabet die Buchstaben š, đ, č, ć, ž und ihre Großbuchstaben Š, Đ, Č, Ć, Ž hinzu ( nur č/Č, š/Š und ž/Ž auf Slowenisch; offiziell, obwohl bei Bedarf auch andere verwendet werden, meist auch in ausländischen Namen). Alle diese Buchstaben sind in Latin-2 und Windows-1250 definiert , während nur einige (š, Š, ž, Ž, Đ) im üblichen Betriebssystem-Standard Windows-1252 existieren und aufgrund einiger anderer Sprachen vorhanden sind.

Obwohl Mojibake mit jedem dieser Zeichen auftreten kann, sind die Buchstaben, die nicht in Windows-1252 enthalten sind, viel anfälliger für Fehler. So wird "šđčćž ŠĐČĆŽ" auch heute noch oft als "šðèæž ŠÐÈÆŽ" angezeigt, obwohl ð, è, æ, È, Æ in slawischen Sprachen nie verwendet werden.

Wenn man sich auf einfaches ASCII beschränkt (zum Beispiel die meisten Benutzernamen), sind gängige Ersetzungen: š→s, đ→dj, č→c, ć→c, ž→z (Großbuchstaben analog, mit Đ→Dj oder Đ→DJ je nach Schreibweise). Alle diese Ersetzungen führen zu Mehrdeutigkeiten, so dass die Rekonstruktion des Originals aus einem solchen Formular bei Bedarf normalerweise manuell erfolgt.

Die Windows-1252- Codierung ist wichtig, da die englischen Versionen des Windows-Betriebssystems am weitesten verbreitet sind, nicht lokalisierte. Gründe dafür sind ein relativ kleiner und fragmentierter Markt, steigende Preise für qualitativ hochwertige Lokalisierungen, ein hohes Maß an Softwarepiraterie (wiederum verursacht durch hohe Softwarepreise im Vergleich zum Einkommen), die Lokalisierungsbemühungen entmutigen, und Menschen, die englische Versionen bevorzugen von Windows und anderer Software.

Der Antrieb zu unterscheiden Kroatisch von Serbisch, Bosnisch von Kroatisch und Serbisch, und jetzt sogar Montenegros von den anderen drei schafft viele Probleme. Es gibt viele verschiedene Lokalisierungen, die unterschiedliche Standards verwenden und von unterschiedlicher Qualität sind. Für die große Menge an Computerterminologie, die aus dem Englischen stammt, gibt es keine gängigen Übersetzungen. Am Ende verwenden die Leute übernommene englische Wörter ("kompjuter" für "Computer", "kompajlirati" für "kompilieren" usw.) basierend auf der übersetzten Phrase zu tun. Daher wählen Menschen, die Englisch verstehen, sowie diejenigen, die an die englische Terminologie gewöhnt sind (die am meisten sind, weil englische Terminologie aufgrund dieser Probleme auch meistens in Schulen gelehrt wird), regelmäßig die englischen Originalversionen von nicht spezialisierter Software.

Wenn kyrillische Schrift verwendet wird (für Mazedonisch und teilweise Serbisch ), ist das Problem ähnlich wie bei anderen kyrillischen Schriften .

Neuere Versionen von englischem Windows erlauben das Ändern der Codepage (ältere Versionen erfordern spezielle englische Versionen mit dieser Unterstützung), aber diese Einstellung kann und wurde oft falsch gesetzt. Windows 98 und Windows Me können beispielsweise auf die meisten nicht rechts-nach-links -Einzelbyte- Codepages eingestellt werden, einschließlich 1250, jedoch nur zum Zeitpunkt der Installation.

Kaukasische Sprachen

Die Schriftsysteme bestimmter Sprachen der Kaukasusregion , einschließlich der Schriften des Georgischen und Armenischen , können Mojibake erzeugen. Dieses Problem ist im Fall von ArmSCII oder ARMSCII besonders akut , einem Satz veralteter Zeichencodierungen für das armenische Alphabet, die durch Unicode-Standards ersetzt wurden. ArmSCII wird aufgrund mangelnder Unterstützung in der Computerindustrie nicht häufig verwendet. Microsoft Windows unterstützt es beispielsweise nicht.

Asiatische Kodierungen

Eine andere Art von Mojibake tritt auf, wenn Text fälschlicherweise in einer Multi-Byte-Kodierung geparst wird, wie etwa einer der Kodierungen für ostasiatische Sprachen . Bei dieser Art von Mojibake werden mehr als ein (typischerweise zwei) Zeichen gleichzeitig verfälscht, zB "k舐lek" ( kärlek ) auf Schwedisch, wobei " är " als "舐" geparst wird. Im Vergleich zum obigen Mojibake ist dies schwieriger zu lesen, da Buchstaben fehlen, die nichts mit den problematischen å, ä oder ö zu tun haben, und ist besonders problematisch bei kurzen Wörtern, die mit å, ä oder ö beginnen, wie z "). Da zwei Buchstaben kombiniert werden, wirkt der Mojibake auch zufälliger (über 50 Varianten im Vergleich zu den normalen drei, die selteneren Großbuchstaben nicht mitgerechnet). In seltenen Fällen kann eine ganze Textzeichenfolge, die zufällig ein Muster bestimmter Wortlängen enthält, wie der Satz " Bush versteckte die Fakten ", falsch interpretiert werden.

japanisch

Im Japanischen heißt das Phänomen, wie erwähnt, mojibake (文字化け) . Dies ist ein besonderes Problem in Japan aufgrund der zahlreichen verschiedenen Kodierungen, die für japanische Texte existieren. Neben Unicode-Kodierungen wie UTF-8 und UTF-16 gibt es weitere Standardkodierungen wie Shift-JIS (Windows-Rechner) und EUC-JP (UNIX-Systeme). Mojibake wird nicht nur von japanischen Benutzern angetroffen, sondern auch von Nicht-Japanern, wenn sie versuchen, Software auszuführen, die für den japanischen Markt geschrieben wurde.

Chinesisch

Auf Chinesisch heißt das gleiche Phänomen Luàn mǎ ( Pinyin , Vereinfachtes Chinesisch 乱码, Traditionelles Chinesisch 亂碼, was 'chaotischer Code' bedeutet) und kann auftreten, wenn computergestützter Text in einer chinesischen Zeichenkodierung kodiert, aber mit der falschen Kodierung angezeigt wird. In diesem Fall ist es oft möglich, das Problem durch Umschalten der Zeichencodierung ohne Datenverlust zu beheben. Die Situation ist kompliziert, da mehrere chinesische Zeichencodierungssysteme verwendet werden, von denen die gängigsten sind: Unicode , Big5 und Guobiao (mit mehreren abwärtskompatiblen Versionen) und die Möglichkeit, dass chinesische Zeichen mit japanischer Codierung codiert werden.

Es ist leicht, die ursprüngliche Kodierung zu identifizieren, wenn luanma in Guobiao-Kodierungen auftritt:

Originalkodierung Angesehen als Ergebnis Original Text Notiz
Die großen 5 GB ? T瓣в变巨肚 三國 志 曹操 傳 Verstümmelte chinesische Schriftzeichen ohne Hinweis auf die ursprüngliche Bedeutung. Das rote Zeichen ist kein gültiger Codepunkt in GB2312.
Umschalt-JIS GB 暥 帤 壔 偗 僥 僗 僩 文字 化 け テ ス ト Kana wird als Zeichen mit dem radikalen 亻 angezeigt, während Kanji andere Zeichen sind. Die meisten von ihnen sind äußerst ungewöhnlich und werden im modernen Chinesisch nicht in der Praxis verwendet.
EUC-KR GB 叼力捞钙胶 抛农聪墨 디제이맥스 테크니카 Zufällige gebräuchliche vereinfachte chinesische Schriftzeichen, die in den meisten Fällen keinen Sinn ergeben. Leicht identifizierbar durch Leerzeichen zwischen jeweils mehreren Zeichen.

Ein zusätzliches Problem entsteht, wenn in der Kodierung Zeichen fehlen, was bei seltenen oder veralteten Zeichen üblich ist, die noch in Personen- oder Ortsnamen verwendet werden. Beispiele hierfür sind das „煊“ des taiwanesischen Politikers Wang Chien-shien (Chinesisch:王建煊; Pinyin: Wáng Jiànxuān ), Yu Shyi-kun (vereinfachtes Chinesisch:游锡堃; traditionelles Chinesisch:游錫堃; Pinyin: Yóu Xíkūn ) „堃" und Sänger David Tao (Chinesisch:陶喆; Pinyin: Táo Zhé ) fehlt "喆" in Big5 , Ex-PRC-Premier Zhu Rongji (Chinesisch:朱镕基; Pinyin: Zhū ​​Róngjī ) fehlt "镕" in GB2312 . Copyright-Symbol "©" fehlt in GBK .

Zeitungen haben dieses Problem auf verschiedene Weise angegangen, einschließlich der Verwendung von Software, um zwei existierende, ähnliche Zeichen zu kombinieren; ein Bild der Persönlichkeit verwenden; oder einfach das seltene Zeichen durch ein Homophon ersetzen, in der Hoffnung, dass der Leser die richtige Schlussfolgerung ziehen kann.

Indikativer Text

Ein ähnlicher Effekt kann in auftreten Brahmic oder indischen Schriften von Südasien in solchen, verwendet indoarische oder indischen Sprachen als Hindustani (Hindi-Urdu), Bengali , Punjabi , Marathi und andere, auch wenn der Zeichensatz richtig erkannt eingesetzt wird die Anwendung. Dies liegt daran, dass in vielen indischen Schriften die Regeln, nach denen einzelne Buchstabensymbole kombiniert werden, um Symbole für Silben zu erzeugen, von einem Computer ohne die entsprechende Software möglicherweise nicht richtig verstanden werden, selbst wenn die Glyphen für die einzelnen Buchstabenformen verfügbar sind.

Ein Beispiel dafür ist das alte Wikipedia-Logo , das versucht, das Zeichen analog zu „wi“ (der ersten Silbe von „Wikipedia“) auf jedem der vielen Puzzleteile darzustellen. Das Puzzleteil bedeutete zu tragen Devanaga für „wi“ -Zeichen verwendet , um die Stelle „wa“ Zeichen angezeigt werden, gefolgt von einem ungepaarten „i“ Modifikator Vokal, leicht erkennbar als Mojibake durch einen Computer erzeugt wird, nicht Indic Text anzuzeigen konfiguriert. Das ab Mai 2010 neu gestaltete Logo hat diese Fehler behoben.

Die Idee von Plain Text erfordert, dass das Betriebssystem eine Schriftart bereitstellt, um Unicode-Codes anzuzeigen. Diese Schriftart unterscheidet sich von OS zu OS für Singhala und macht orthografisch falsche Glyphen für einige Buchstaben (Silben) auf allen Betriebssystemen. Zum Beispiel ist das 'reph', die Kurzform für 'r', ein diakritisches Zeichen, das normalerweise über einem einfachen Buchstaben steht. Es ist jedoch falsch, in bestimmten Kontexten einige Buchstaben wie 'ya' oder 'la' zu übersteigen. Bei sanskritischen Wörtern oder Namen, die von modernen Sprachen geerbt wurden, wie कार्य, IAST: kārya oder आर्या, IAST: āryā , ist es geeignet, sie über diese Buchstaben zu setzen. Im Gegensatz dazu wird es bei ähnlichen Lauten in modernen Sprachen, die sich aus ihren spezifischen Regeln ergeben, nicht angesetzt, wie das Wort करणाऱ्या, IAST: karaṇāryā , eine Stammform des gebräuchlichen Wortes करणारा/री, IAST: karaṇārā/rī , in der Marathi-Sprache . Aber es passiert in den meisten Betriebssystemen. Dies scheint ein Fehler der internen Programmierung der Schriftarten zu sein. In Mac OS und iOS ergeben die Kombination muurdhaja l (dunkles l) und 'u' und ihre lange Form beide falsche Formen.

Einige indische und von Indic abgeleitete Skripte, insbesondere Lao , wurden bis zur Veröffentlichung von Vista nicht offiziell von Windows XP unterstützt . Verschiedene Websites haben jedoch Schriftarten zum kostenlosen Download bereitgestellt.

birmanisch

Aufgrund westlicher Sanktionen und der späten Einführung der burmesischen Sprachunterstützung in Computern wurde ein Großteil der frühen burmesischen Lokalisierung ohne internationale Zusammenarbeit heimisch. Die vorherrschende burmesische Unterstützung erfolgt über die Schriftart Zawgyi , eine Schriftart, die als Unicode-Font erstellt wurde, aber tatsächlich nur teilweise Unicode-kompatibel war. In der Schriftart Zawgyi wurden einige Codepunkte für burmesische Schrift wie in Unicode angegeben implementiert , andere jedoch nicht. Das Unicode-Konsortium bezeichnet dies als Ad-hoc-Schriftcodierung . Mit dem Aufkommen von Mobiltelefonen ersetzten Mobilfunkanbieter wie Samsung und Huawei einfach die Unicode-kompatiblen Systemfonts durch Zawgyi-Versionen.

Aufgrund dieser Ad-hoc- Kodierungen würde die Kommunikation zwischen Benutzern von Zawgyi und Unicode als verstümmelter Text gerendert. Um dieses Problem zu umgehen, würden Content-Produzenten Beiträge sowohl in Zawgyi als auch in Unicode erstellen. Die Regierung von Myanmar hat den 1. Oktober 2019 zum "U-Day" erklärt, um offiziell auf Unicode umzustellen. Die vollständige Umstellung wird voraussichtlich zwei Jahre dauern.

Afrikanische Sprachen

In bestimmten Schriftsystemen Afrikas ist unverschlüsselter Text nicht lesbar. Zu den Texten, die Mojibake produzieren 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, und die somalische Sprache , die das Osmanya-Alphabet verwendet . Im südlichen Afrika wird das Mwangwego-Alphabet verwendet, um Sprachen von Malawi zu schreiben, und das Mandombe-Alphabet wurde für die Demokratische Republik Kongo entwickelt , aber diese werden im Allgemeinen nicht unterstützt. Verschiedene andere in Westafrika beheimatete Schriftsysteme weisen ähnliche Probleme auf, wie das N'Ko-Alphabet , das für Manding-Sprachen in Guinea verwendet wird , und die Vai-Silbenschrift , die in Liberia verwendet wird .

Arabisch

Eine weitere betroffene Sprache ist Arabisch (siehe unten ). Der Text wird unlesbar, wenn die Codierungen nicht übereinstimmen.

Beispiele

Dateicodierung Einstellung im Browser Ergebnis
Arabisches Beispiel: ( Allgemeine Erklärung der Menschenrechte )
Browser-Rendering: الإعلان العالمى لحقوق الإنسان
UTF-8 Windows-1252 الإعلان العالمى Ù„Øقوق الإنسان
KOI8-R О╩©ь╖ы└ь╔ь╧ы└ь╖ы├ ь╖ы└ь╧ь╖ы└ы┘ы┴ ы└ь╜ы┌ы┬ы┌ ь╖ы└ь╔ы├ьЁь ╖ы├
ISO 8859-5 иЇй иЅиЙй иЇй иЇй иЙиЇй й й й ий й й иЇй иЅй иГиЇй
CP 866 е╪╣┘Д╪з┘Ж ╪з┘Д╪╣╪з┘Д┘Е┘Й ┘Д╪н┘В┘И┘В ╪з┘Д╪е┘Ж╪ │╪з┘Ж
ISO 8859-6 ُ؛؟ظ ع ظ ظ ع ظ ع ظ ع ظ ظ ع ع ع ع ظع ع ع ظ ع ظ ع ظ ظ ع
ISO 8859-2 ا٠ؼؚ٠ا٠ا٠ؚا٠٠٠٠Ř٠٠٠ا٠ؼ٠ساŮ
Windows-1256 Windows-1252 ÇáÅÚáÇä ÇáÚÇáãì áÍÞæÞ ÇáÅäÓÇä

Die Beispiele in diesem Artikel haben UTF-8 nicht als Browsereinstellung, da UTF-8 leicht zu erkennen ist. Wenn ein Browser also UTF-8 unterstützt, sollte er es automatisch erkennen und nicht versuchen, etwas anderes als UTF-8 zu interpretieren.

Siehe auch

  • Codepunkt
  • Ersatzzeichen
  • Ersatzzeichen
  • Newline – Die Konventionen zur Darstellung des Zeilenumbruchs unterscheiden sich zwischen Windows- und Unix-Systemen. Obwohl die meisten Softwares beide Konventionen unterstützen (was trivial ist), kann Software, die den Unterschied beibehalten oder anzeigen muss (zB Versionskontrollsysteme und Datenvergleichstools ), erheblich schwieriger zu bedienen sein, wenn sie sich nicht an eine Konvention hält.
  • Bytereihenfolgemarkierung - die In-Band - Art und Weise der Codierung zusammen mit den Daten zu speichern - prepend es. Dies ist absichtlich für Menschen, die konforme Software verwenden, unsichtbar, wird jedoch konstruktionsbedingt als "Müllzeichen" für inkompatible Software (einschließlich vieler Interpreter ) wahrgenommen .
  • HTML-Entitäten – Eine Codierung von Sonderzeichen in HTML, meist optional, aber erforderlich, damit bestimmte Zeichen der Interpretation als Markup entgehen .

    Wenn diese Transformation nicht angewendet wird , stellt dies eine Schwachstelle dar (siehe Cross-Site-Scripting ), aber eine zu häufige Anwendung führt zu einer Verstümmelung dieser Zeichen. Zum Beispiel können die Anführungszeichen "werden &quot;, &amp;quot;, &amp;amp;quot;und so weiter.

  • Bush hat die Fakten versteckt

Verweise

Externe Links

  • Die Wörterbuchdefinition von Mojibake bei Wiktionary
  • Medien im Zusammenhang mit Mojibake bei Wikimedia Commons