Mojibake ehk tähemärgiviga — miks tekst kuvatakse valesti ja lahendused

Mojibake ehk tähemärgiviga: miks tekst kuvatakse valesti ja kuidas kodeeringuid (UTF‑8, ISO‑8859 jt) tuvastada ning kiiresti tõrkeid parandada.

Mojibake (文字化け, hääldatakse /modʑibake/) on nimetus selle kohta, kui tekst kuvatakse valesti — loetamatute või valemate tähemärkidena — sest kuvamiseks kasutatav tarkvara tõlgendab baitide jada vale tähemärgikodeeringuna. Tekst arvutis kodeeritakse tähemärkide kodeeringuga: iga märk esitatakse teatud baitide jadana vastavas kodeeringus. Kui baitide jada kuvatakse teisest kodeeringust lähtudes, asendatakse tegelikud märgid valevõrdlusega ja tulemuseks on mojibake. Mojibake tekkimise põhjuseks võivad olla vale meta-info, mittenõuetekohaselt salvestatud failid, valed HTTP- või e-kirja päised, andmebaasi ühenduse vale kodeering või topeltkodeerimine. Arvutitarkvara näitab teksti õigesti alles siis, kui kõik osapooled (faili salvestaja, server, side ja kliendirakendus) kasutavad sama kodeeringut. Unicode ja sellest kõige levinumalt kasutatav esituse vorm UTF-8 on loodud selle probleemi vähendamiseks: UTF-8 kodeerib Unicode-märke muutuva pikkusega baitidena (1–4 baiti), mis võimaldab ühes standardis esitada suuri hulki eri keelte ja sümbolite tähemärke.

Miks mojibake tekib

• Vale kodeeringu tõlgendamine: baitide jada salvestati ühes kodeeringus (nt ISO-8859-1 või Windows-1252), aga loetakse teises (nt UTF-8).
• Puuduv või vale meta-info: veebilehel puudub charset-meta või server ei saada õiget Content-Type päist.
• Andmebaasi ja kliendi mittevastavus: andmed salvestati ühes kodeeringus, kuid ühendus või päring on teises (nt andmebaas salvestab UTF-8, aga klient kasutab latin1).
• Topeltkodeerimine: andmed on juba UTF-8-na kodeeritud, aga neid käsitletakse kui latin1 ja see tulemus kodeeritakse uuesti.
• Puuduvad glüfüd: font ei sisalda vajalikke märke — see ei ole mojibake täpse tähenduses (see toob tavaliselt nähtavale “kastikesed” või küsimärgid), kuid kasutajale näeb välja sarnane probleem.
• BOM (Byte Order Mark): mõnikord tekitab UTF-8 BOM ebatavalise sisu kuvamise, kui tarkvara seda ei oota.

Levinud näited

• Ä, Ö, Ü asemel kuvatakse “Ä”, “Ö”, “Ãœ” — tüüpiline, kui UTF-8 baitidena salvestatud tähed loetakse Latin-1/Windows-1252 järgi.
• Dash (—) kuvamine kui “—” või “–”.
• Kastikesed või küsimärgid (□, ?) — sageli fonti puudumise või asenduse tõttu.

Kuidas tuvastada kodeeringu viga

• Vaata teksti mustrit: teatud valekoodide järjestused (nt “Ô, “”, “â”) viitavad konkreetsetele valedele tõlgendustele.
• Kontrolli faili baitide heksaväljapraane — kui need vastavad UTF-8 valid-baitidele, aga kuvatakse nagu latin1, siis on problema tunnustatud.
• Kasutage tööriistu: file, enca, chardet jms, mis proovivad ära arvata faili kodeeringut.
• Veebibrauseris: menüüst Character Encoding / Teksti kodeeringu valikuga proovida erinevaid kodeeringuid.

Kuidas mojibaket parandada ja kuidas seda vältida

• Kasuta UTF-8 standardina: nii lähtefailide, andmebaasi, HTTP-päiste kui ka e-kirjade puhul. UTF-8 toetab kõiki Unicode-märke ja vähendab kodeeringute kokkupõrkeid.
• Aseta charset juba alguses: HTML-s pane <meta charset="utf-8"> dokumendi sektsiooni enne teisi meta-silte ja sisu, ning server saadaks HTTP päise Content-Type: text/html; charset=utf-8.
• Kontrolli andmebaasi ja ühenduste sätteid: veendu, et andmebaas, tabeli kollatsioon ja kliendiühenduse charset ühtiksid (nt utf8mb4 ja utf8mb4_unicode_ci MySQL-s; ning kasuta SET NAMES või vastavat kliendikonfiguratsiooni).
• Ära topeltkodeeri: ära “paranda” juba UTF-8 andmeid käesolevaks presetsiooniks, vaid mõista, millisel kujul baitide jada tegelikult on ja teisenda korrektselt.
• Säilita meta- ja päiseteave koos sisuga: kui edastad faile või andmevooge, lisa alati informatsioon kasutatud kodeeringu kohta.
• Kontrolli fonte: kui probleemiks on puuduvad glüfid, kasuta sobivat fonti või varufonte, mis sisaldavad vajalikke märke.

Tööriistad ja praktilised näited

• Faili konverteerimine iconv-iga:
  iconv -f ISO-8859-1 -t UTF-8 vana.txt > uus.txt
• Diagnostika: enca või chardet aitavad ära arvata tõenäolist kodeeringut:
  enca -L none fail.txt
• Veebiserver: saada õige HTTP päis:
  Content-Type: text/html; charset=utf-8
• Andmebaas: MySQL näide:
  ALTER TABLE mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  ja veendu, et ühendus kasutab utf8mb4 (SET NAMES utf8mb4).
• E-kirjad: ära unusta Content-Type päist koos charset-iga (nt text/plain; charset="utf-8").

Lisamärkused

• ISO-8859 seeria (näiteks ISO-8859-1) koosneb mitmest variandist, mis katavad eri keelte erimärke — nende üleõige kasutamine ja tõlgendamine on mojibake vältimiseks oluline. Paljud keskkonnad kasutasid varem ISO-8859-1 või Windows-1252 ning nende ja UTF-8 segamine tekitab tihti probleeme.
• UTF-16 ja UTF-32 on samuti Unicode’i esitusviisid — need kasutavad fikseeritud või pool-fikseeritud baitide pikkusi (UTF-16 2 või 4 baiti enamiku märkide jaoks), kuid veebis ja failisüsteemides on tänapäeval kõige laialdasem UTF-8.

Kokkuvõtteks: mojibake tekib siis, kui baitide jada ja seda tõlgendav kodeering ei kattu. Parim ennetus on ühtne, selgelt määratud ja standardile vastav kodeering (tavaliselt UTF-8) kogu andmevoos — failidest kuni serverite, andmebaaside ja rakendusteni. Kui viga on juba tekkinud, aitab olukorra parandamisel kõigepealt vigade tuvastamine (mida baitide muster näitab) ning seejärel korrektne teisendamine ja ka lähtepunktide (päised, meta, DB-ühendused, editorid) sättimine ühtsele kodeeringule.

Küsimused ja vastused

K: Mis on "mojibake"?

K: Kuidas kodeeritakse teksti arvutite kasutamisel?

K: Mis juhtub, kui teksti edastamisel ei ole algset kodeeringut määratud?

K: Mis on Unicode ja kuidas see probleemi lahendab?

K: Millised on mõned näited muudest tähemärkide kodeeringutest, mida kasutati enne Unicode'i?

K: Mitu erinevat kodeeringut sisaldab ISO-8859?

K: Kas ISO-8859 erimärgid on kõikides kodeeringutes samad?

Otsing