Mojibake: hibás, olvashatatlan karakterek és a kódolás oka

Mojibake: mi okozza a hibás, olvashatatlan karaktereket? Ismerd meg a karakterkódolás, ISO-8859 és az Unicode/UTF-8 megoldását lépésről lépésre.

Mojibake (文字化け, kiejtése /modʑibake/) a hibás, olvashatatlan karakterek gyűjtőneve, amelyek akkor jelennek meg, amikor a számítógépes szoftver nem a megfelelő karakterkódolással jeleníti meg a szöveget. A számítógépekben a karaktereket bájtok (vagy bájtsorozatok) formájában tárolják: minden karakterhez egy szám (kódpont vagy bájtsorozat) tartozik, és a megjelenítéshez a szoftvernek tudnia kell, hogyan kell ezeket a számokat karakterekké visszaalakítani. Ha a dekódoláshoz használt kódolás eltér az eredeti kódolástól, akkor a bájtokat rosszul értelmezve idegen, olvashatatlan jelek vagy helyettesítő karakterek (például a �, U+FFFD) jelennek meg — ez a jelenség a mojibake.

Mi okozza a mojibake-ot?

• Kódolás- és dekódolás-eltérés: a leggyakoribb ok, amikor a szöveg bájtjait egy másik karakterkészlettel (például ISO-8859-1 vagy Windows-1252) értelmezik, mint amivel eredetileg kódolták (például UTF-8). Ennek tipikus következménye, hogy például az é betű helyén "é" jelenik meg, vagy az en dash (–) helyén "–".
• Kettős vagy hibás kódolás: előfordul, hogy egy már UTF-8-ban tárolt szöveget tévesen Latin-1-ként olvasnak be, majd az így kapott byte-okat újra UTF-8-ként tárolják — ez súlyos, nehezen visszafordítható garblinghez vezet.
• Hiányzó vagy hibás meta/információ: ha a fájl vagy a weboldal nem közli a kódolást (vagy rosszat ad meg), a böngésző vagy a kliens kitalálhatja — gyakran rosszul.
• BOM és bájt-sorrend problémák: a UTF-8 vagy UTF-16 BOM (Byte Order Mark) néha látható karakterekként jelenik meg (pl. UTF‑8 BOM hibás értelmezése Latin‑1 esetén: "" a fájl elején).
• Nem támogatott betűtípusok: ha a megjelenítő rendszerben nincs olyan font, ami tartalmazná a szükséges glifeket, helyettesítő jelek jelennek meg.

Régi kódolások és a Unicode szerepe

A Unicode célja az volt, hogy egységesen leírja a világ összes írásrendszerének karaktereit. Maga a Unicode az egyes karakterekhez kódpontokat rendel, a tényleges bájtsorosításra különböző ábrázolások (encodingek) használhatók — ezek közül a legelterjedtebb az UTF‑8.

Fontos megjegyezni, hogy az UTF‑8 nem korlátozódik "2 bájtra": az ASCII karakterek 1 bájttal kódolódnak, sok gyakori latin és más nem latin karakter 2 vagy 3 bájttal, a legtöbb Unicode karakter pedig 1–4 bájttal. A Unicode bevezetése előtt sok, nyelvspecifikus 8 bites kódolás létezett (például az ISO-8859 sorozat — több változat, pl. ISO-8859-1/2/5 stb. — vagy a Windows-125x kódoldalak). Ezek a régi kódolások korlátozott karakterkészletet tartalmaztak, és eltérő módon „foglalják be” a speciális karakterhelyeket, ezért a fájlok átvihetősége problémás volt.

Tipikus példák

• "é" (helyesen) → helytelen dekódolásnál "é"
• "–" (en dash) → "–"
• "…" (ellipszis) → "…"
• UTF‑8 BOM rossz dekódolás esetén: a fájl elején ""

Hogyan előzhető meg

• Egységes használat: használj végponttól végpontig ugyanazt a kódolást (ajánlott: UTF‑8, lehetőleg utf8mb4 az adatbázisoknál az emoji és ritkább jelek miatt).
• HTTP és HTML beállítások: állítsd a szerveren és a válasz fejlécben a Content-Type: text/html; charset=utf-8 értéket, illetve az oldal fejléce legyen .
• Fájlok mentése: szerkesztőben mentsd el egyértelműen UTF‑8-ként (BOM nélkül, ha lehetséges, mert a BOM okozhat kompatibilitási problémákat).
• Adatbázis-kapcsolat: állítsd be a kapcsolat karakterkészletét (például MySQL-nél SET NAMES utf8mb4 vagy a klienskönyvtár megfelelő beállítása), és a táblák/mezők kódolása is legyen UTF‑8.
• Tesztelés: böngészőkben és különböző eszközökön ellenőrizd a megjelenést; ha lehetséges, használj automatikus validálást és CI-lépéseket, amelyek ellenőrzik a kódolást.

Hogyan lehet javítani egy már meglévő mojibake-ot?

• Azonosítás: próbáld meg kideríteni az eredeti és a jelenleg használt kódolást. Segédeszközök: chardet, enca, Notepad++ kódolás-váltó, böngészők „Character Encoding” menüje.
• Egyszerű konverzió: ha tudod, mi a forrás és mi a cél, konvertálj eszközzel, pl. iconv:
  • példa: iconv -f ISO-8859-1 -t UTF-8 forras.txt > cel.txt
• Kettősen kódolt szöveg visszafordítása: ha egy UTF‑8 bájtsorozatot Latin‑1‑ként értelmeztek majd ismét UTF‑8‑ra mentettek, gyakran vissza lehet hozni speciális eszközökkel vagy scriptekkel — de ez bonyolultabb, és óvatos vizsgálatot igényel.
• Szerkesztők használata: sok szövegszerkesztő (pl. Notepad++, Sublime Text) lehetővé teszi a fájl megnyitását különböző kódolásokkal és újra mentésüket.
• Mentés biztonsági másolatról: mindig készíts biztonsági másolatot az eredeti fájlról, mielőtt konvertálsz vagy automatizált javítást futtatsz.

Gyakorlati tanácsok

• Webfejlesztésnél a legegyszerűbb és legtartósabb megoldás: minden rétegen (forrásfájlok, sablonok, adatbázis, HTTP válaszok) UTF‑8-at használni.
• Adatcsere esetén (CSV, XML, JSON) mindig jelöld explicit módon a kódolást, és ellenőrizd a vevő oldalt, hogy azt használja-e.
• Fontok hiánya esetén a probléma nem mindig mojibake: előfordul, hogy a karakterkódolás helyes, de a megjelenítő nincs felkészítve az adott írásrendszerre.

Összefoglalva: a mojibake a kódolások nem megfelelő egyeztetésének következménye. A megelőzés kulcsa az egységes, jól dokumentált és következetesen alkalmazott kódolási gyakorlat (ajánlott: UTF‑8), valamint a szerver- és kliensoldali beállítások pontos kezelése.

Kérdések és válaszok

K: Mi az a "mojibake"?

K: Hogyan kódolják a szöveget a számítógépek használatakor?

K: Mi történik, ha a szöveg átvitelekor nem az eredeti kódolás van megadva?

K: Mi az az Unicode, és hogyan oldja meg ezt a problémát?

K: Milyen más karakterkódolásokat használtak az Unicode előtt?

K: Hány különböző kódolást tartalmaz az ISO-8859?

K: Az ISO-8859 speciális karakterei az összes kódolásban azonosak?

Keresés betűvel