Mojibake

Mojibake (Japanese: 文字化け; IPA: [mod͡ʑibake], "character transformation") is the garbled or gibberish text that is the result of text being decoded using an unintended character encoding.^[1] The result is a systematic replacement of symbols with completely unrelated ones, often from a different writing system.

This display may include the generic replacement character ("�") in places where the binary representation is considered invalid. A replacement can also involve multiple consecutive symbols, as viewed in one encoding, when the same binary code constitutes one symbol in the other encoding. This is either because of differing constant length encoding (as in Asian 16-bit encodings vs European 8-bit encodings), or the use of variable length encodings (notably UTF-8 and UTF-16).

Failed rendering of glyphs due to either missing fonts or missing glyphs in a font is a different issue that is not to be confused with mojibake. Symptoms of this failed rendering include blocks with the code point displayed in hexadecimal or using the generic replacement character. Importantly, these replacements are valid and are the result of correct error handling by the software.

To correctly reproduce the original text that was encoded, the correspondence between the encoded data and the notion of its encoding must be preserved (i.e. the source and target encoding standards must be the same). As mojibake is the instance of non-compliance between these, it can be achieved by manipulating the data itself, or just relabelling it.

Mojibake is often seen with text data that have been tagged with a wrong encoding; it may not even be tagged at all, but moved between computers with different default encodings. A major source of trouble are communication protocols that rely on settings on each computer rather than sending or storing metadata together with the data.

The differing default settings between computers are in part due to differing deployments of Unicode among operating system families, and partly the legacy encodings' specializations for different writing systems of human languages. Whereas Linux distributions mostly switched to UTF-8 in 2004,^[2] Microsoft Windows generally uses UTF-16, and sometimes uses 8-bit code pages for text files in different languages.

For some writing systems, such as Japanese, several encodings have historically been employed, causing users to see mojibake relatively often. As an example, the word mojibake itself ("文字化け") stored as EUC-JP might be incorrectly displayed as "ﾊｸｻ�ｽ､ｱ", "ﾊｸｻ嵂ｽ､ｱ" (MS-932), or "ﾊｸｻ郾ｽ､ｱ" if interpreted as Shift-JIS, or as "ʸ»ú²½¤±" in software that assumes text to be in the Windows-1252 or ISO 8859-1 encodings, usually labelled Western or Western European. This is further exacerbated if other locales are involved: the same text stored as UTF-8 appears as "譁�蟄怜喧縺�" if interpreted as Shift-JIS, as "文字化け" if interpreted as Western, or (for example) as "鏂囧瓧鍖栥亼" if interpreted as being in a GBK (Mainland China) locale.

If the encoding is not specified, it is up to the software to decide it by other means. Depending on the type of software, the typical solution is either configuration or charset detection heuristics. Both are prone to mis-prediction.

The encoding of text files is affected by locale setting, which depends on the user's language, brand of operating system, and many other conditions. Therefore, the assumed encoding is systematically wrong for files that come from a computer with a different setting, or even from a differently localized software within the same system. For Unicode, one solution is to use a byte order mark, but for source code and other machine readable text, many parsers do not tolerate this. Another is storing the encoding as metadata in the file system. File systems that support extended file attributes can store this as user.charset.^[3] This also requires support in software that wants to take advantage of it, but does not disturb other software.

While a few encodings are easy to detect, such as UTF-8, there are many that are hard to distinguish (see charset detection). A web browser may not be able to distinguish a page coded in EUC-JP and another in Shift-JIS if the encoding is not assigned explicitly using HTTP headers sent along with the documents, or using the HTML document's meta tags that are used to substitute for missing HTTP headers if the server cannot be configured to send the proper HTTP headers; see character encodings in HTML.

Mojibake also occurs when the encoding is incorrectly specified. This often happens between encodings that are similar. For example, the Eudora email client for Windows was known to send emails labelled as ISO 8859-1 that were in reality Windows-1252.^[4] Windows-1252 contains extra printable characters in the C1 range (the most frequently seen being curved quotation marks and extra dashes), that were not displayed properly in software complying with the ISO standard; this especially affected software running under other operating systems such as 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, consider a web server serving a static HTML file over HTTP. The character set may be communicated 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 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 US-ASCII. UTF-8 also has the ability to be directly recognised by a simple algorithm, so that well written software should be able to avoid mixing UTF-8 up with other encodings.

The difficulty of resolving an instance of mojibake varies depending on the application within which it occurs and the causes of it. Two of the most common applications in which mojibake may occur are web browsers and word processors. Modern browsers and word processors often support a wide array of character encodings. Browsers often allow a user to change their rendering engine's encoding setting on the fly, while word processors allow the user to select the appropriate encoding when opening a file. It may take some trial and error for users to find the correct encoding.

The problem gets more complicated when it occurs in an application that normally does not support a wide range of character encoding, such as in a non-Unicode computer game. In this case, the user must change the operating system's encoding settings to match that of the game. However, changing the system-wide encoding settings can also cause Mojibake in pre-existing applications. In Windows XP or later, a user also has the option to use Microsoft AppLocale, an application that allows the changing of per-application locale settings. Even so, changing the operating system encoding settings is not possible on earlier operating systems such as Windows 98; to resolve this issue on earlier operating systems, a user would have to use third party font rendering applications.

Mojibake in English texts generally occurs in punctuation, such as em dashes (—), en dashes (–), and curly quotes (“,”,‘,’), but rarely in character text, since most encodings agree with ASCII on the encoding of the English alphabet. For example, the pound sign £ will appear as £ if it was encoded by the sender as UTF-8 but interpreted by the recipient as one of the Western European encodings (CP1252 or ISO 8859-1). If iterated using CP1252, this can lead to £, £, £, £, and so on.

Similarly, the right single quotation mark (’), when encoded in UTF-8 and decoded using Windows-1252, becomes ’, ’, ’, and so on.

In older eras, some computers had vendor-specific encodings which caused mismatch also for English text. Commodore brand 8-bit computers used PETSCII encoding, particularly notable for inverting the upper and lower case compared to standard ASCII. PETSCII printers worked fine on other computers of the era, but inverted the case of all letters. IBM mainframes use the EBCDIC encoding which does not match ASCII at all.

The alphabets of the North Germanic languages, Catalan, Romanian, Finnish, French, German, Italian, Portuguese and Spanish are all extensions of the Latin alphabet. The additional characters are typically the ones that become corrupted, making texts only mildly unreadable with mojibake:

• å, ä, ö in Finnish and Swedish (š and ž are present in some Finnish loanwords, é marginally in Swedish, mainly also in loanwords)
• à, ç, è, é, ï, í, ò, ó, ú, ü in Catalan
• æ, ø, å in Norwegian and Danish as well as optional acute accents on é etc for disambiguation
• á, é, ó, ij, è, ë, ï in Dutch
• ä, ö, ü, and ß in German
• á, ð, í, ó, ú, ý, æ, ø in Faroese
• á, ð, é, í, ó, ú, ý, þ, æ, ö in Icelandic
• à, â, ç, è, é, ë, ê, ï, î, ô, ù, û, ü, ÿ, æ, œ in French
• à, è, é, ì, ò, ù in Italian
• á, é, í, ñ, ó, ú, ü, ¡, ¿ in Spanish
• à, á, â, ã, ç, é, ê, í, ó, ô, õ, ú in Portuguese (ü no longer used)
• á, é, í, ó, ú in Irish
• à, è, ì, ò, ù in Scottish Gaelic
• ă, â, î, ș, ț in Romanian
• £ in British English (æ and œ are rarely used)

... and their uppercase counterparts, if applicable.

These are languages for which the ISO 8859-1 character set (also known as Latin 1 or Western) has been in use. However, ISO 8859-1 has been obsoleted by two competing standards, the backward compatible Windows-1252, and the slightly altered ISO 8859-15. Both add the Euro sign € and the French œ, but otherwise any confusion of these three character sets does not create mojibake in these languages. Furthermore, it is always safe to interpret ISO 8859-1 as Windows-1252, and fairly safe to interpret it as ISO 8859-15, in particular with respect to the Euro sign, which replaces the rarely used currency sign (¤). However, with the advent of UTF-8, mojibake has become more common in certain scenarios, e.g. exchange of text files between UNIX and Windows computers, due to UTF-8's incompatibility with Latin-1 and Windows-1252. But UTF-8 has the ability to be directly recognised by a simple algorithm, so that well written software should be able to avoid mixing UTF-8 up with other encodings, so this was most common when many had software not supporting UTF-8. Most of these languages were supported by MS-DOS default CP437 and other machine default encodings, except ASCII, so problems when buying an operating system version were less common. Windows and MS-DOS are not compatible, however.

In Swedish, Norwegian, Danish and German, vowels are rarely repeated, and it is usually obvious when one character gets corrupted, e.g. the second letter in the Swedish word kärlek ("love") when it is encoded in UTF-8 but decoded in Western, producing "kÃ⁠¤rlek", or für in German, which becomes "für". This way, even though the reader has to guess what the original letter is, almost all texts remain legible. Finnish, on the other hand, frequently uses repeating vowels in words like hääyö ("wedding night") which can make corrupted text very hard to read (e.g. hääyö appears as "hÃ⁠¤Ã⁠¤yÃ⁠¶"). Icelandic has ten possibly confounding characters, and Faroese has eight, making many words almost completely unintelligible when corrupted (e.g. Icelandic þjóðlöð, "outstanding hospitality", appears as "þjóðlöð").

In German, Buchstabensalat ("letter salad") is a common term for this phenomenon, in Spanish, deformación (literally "deformation") is used, and in Portuguese, desformatação (literally "deformatting") is used.

Some users transliterate their writing when using a computer, either by omitting the problematic diacritics, or by using digraph replacements (å → aa, ä/æ → ae, ö/ø → oe, ü → ue etc.). Thus, an author might write "ueber" instead of "über", which is standard practice in German when umlauts are not available. The latter practice seems to be better tolerated in the German language sphere than in the Nordic countries. For example, in Norwegian, digraphs are associated with archaic Danish, and may be used jokingly. However, digraphs are useful in communication with other parts of the world. As an example, the Norwegian football player Ole Gunnar Solskjær had his last name spelled "SOLSKJAER" on his uniform when he played for Manchester United.

An artifact of UTF-8 misinterpreted as ISO 8859-1, "Ring meg nå" being rendered as "Ring meg nÃ¥", was seen in 2014 in an SMS scam targeting Norway.^[5]

The same problem occurs also in Romanian, see these examples:

Users of Central and Eastern European languages can also be affected. Because most computers were not connected to any network during the mid- to late-1980s, there were different character encodings for every language with diacritical characters (see ISO/IEC 8859 and KOI-8), often also varying by operating system.

In Hungarian, the phenomenon is referred to as betűszemét, meaning "letter garbage". Hungarian has been particularly susceptible as it contains the accented letters á, é, í, ó, ú, ö, ü (all present in the Latin-1 character set), plus the two characters ő and ű which are not in Latin-1. These two characters can be correctly encoded in Latin-2, Windows-1250, and Unicode. However, before Unicode became common in e-mail clients, e-mails containing Hungarian text often had the letters ő and ű corrupted, sometimes to the point of unrecognizability. It is common to respond to a corrupted e-mail with the nonsense phrase "Árvíztűrő tükörfúrógép" (literally "Flood-resistant mirror-drilling machine") which contains all accented characters used in Hungarian.