Mojibake - Mojibake

UTF-8 kodowanego artykuł Japońska Wikipedia dla Mojibake jak wyświetlane jeśli interpretować jako Windows-1252 kodowania

Mojibake (文字化け; IPA:  [mod͡ʑibake] ) to zniekształcony tekst, który jest wynikiem dekodowania tekstu przy użyciu niezamierzonego kodowania znaków . Efektem jest systematyczne zastępowanie symboli zupełnie niepowiązanymi, często z innego systemu pisma .

Ten wyświetlacz może zawierać ogólny znak zastępczy („ ”) w miejscach, w których reprezentacja binarna jest uważana za nieprawidłową. Zastąpienie może również obejmować wiele kolejnych symboli, jak widać w jednym kodowaniu, gdy ten sam kod binarny stanowi jeden symbol w innym kodowaniu. Wynika to albo z różnych kodowań o stałej długości (jak w azjatyckich kodowaniach 16-bitowych w porównaniu z europejskimi kodowaniami 8-bitowymi) lub z powodu użycia kodowań o zmiennej długości (zwłaszcza UTF-8 i UTF-16 ).

Nieudane renderowanie glifów z powodu brakujących czcionek lub brakujących glifów w czcionce to inny problem, którego nie należy mylić z mojibake. Objawy tego nieudanego renderowania obejmują bloki z punktem kodowym wyświetlanym w postaci szesnastkowej lub przy użyciu ogólnego znaku zastępczego. Co ważne, te zamienniki są ważne i są wynikiem poprawnej obsługi błędów przez oprogramowanie.

Etymologia

Mojibake oznacza „transformacja charakter” w języku japońskim . Słowo składa się z文字(moji, IPA:  [mod͡ʑi] ), „znak” i化け(bake, IPA:  [bäke̞] , wymawiane „bah-keh”), „przekształcić”.

Powoduje

Aby poprawnie odtworzyć oryginalny tekst, który został zakodowany, należy zachować zgodność między zakodowanymi danymi a pojęciem ich kodowania. Ponieważ mojibake jest przykładem niezgodności między nimi, można to osiągnąć manipulując samymi danymi lub po prostu zmieniając je.

Mojibake jest często widziany z danymi tekstowymi, które zostały oznaczone niewłaściwym kodowaniem; może nawet nie być w ogóle oznaczony, ale przenoszony między komputerami z różnymi domyślnymi kodowaniami. Głównym źródłem problemów są protokoły komunikacyjne, które opierają się na ustawieniach na każdym komputerze, a nie na wysyłaniu lub przechowywaniu metadanych razem z danymi.

Różniące się ustawieniami domyślnymi między komputerami są po części ze względu na różniące wdrożeń Unicode wśród System operacyjny rodzin, a częściowo specjalizacje spuścizny kodowania dla różnych systemów pisma języków ludzkich. Podczas gdy dystrybucje Linuksa w 2004 roku przeszły głównie na UTF-8 , Microsoft Windows zazwyczaj używa UTF-16, a czasami używa 8-bitowych stron kodowych dla plików tekstowych w różnych językach.

W przypadku niektórych systemów pisma , na przykład japońskiego , w przeszłości stosowano kilka kodowań, co powodowało, że użytkownicy stosunkowo często widywali mojibake. Na przykład w języku japońskim słowo mojibake „文字化け” przechowywane jako EUC-JP może być nieprawidłowo wyświetlane jako „ハクサ ス、ア”, „ハクサ嵂ス、ア” ( MS-932 ) lub „ハクサ郾ス、ア( Zmiana JIS-2004 ). Ten sam tekst zapisany jako UTF-8 jest wyświetlany jako „譁 蟄怜喧縺 ”, jeśli jest interpretowany jako Shift JIS. Sytuacja pogarsza się jeszcze bardziej, jeśli zaangażowane są inne ustawienia regionalne: ten sam tekst UTF-8 pojawia się jako „æ–‡å—化ã??'” w oprogramowaniu, które zakłada, że ​​tekst jest w kodowaniu Windows-1252 lub ISO-8859-1 , zwykle oznaczony jako Western lub (na przykład) jako „鏂囧瓧鍖栥亼”, jeśli interpretowany jest jako język GBK (Chiny kontynentalne).

Przykład mojibake
Oryginalny tekst
Surowe bajty kodowania EUC-JP CA B8 nocleg ze śniadaniem FA B2 BD A4 B1
Bajty interpretowane jako kodowanie Shift-JIS ja
Bajty interpretowane jako kodowanie ISO-8859-1 MI ¸ » ú ² ½ ¤ ±
Bajty interpretowane jako kodowanie GBK

Niedostateczna specyfikacja

Jeśli kodowanie nie jest określone, decyzja o tym w inny sposób zależy od oprogramowania. W zależności od rodzaju oprogramowania typowym rozwiązaniem jest konfiguracja lub heurystyka wykrywania zestawu znaków . Oba są podatne na błędne przewidywania w niezbyt częstych scenariuszach.

Na kodowanie plików tekstowych ma wpływ ustawienie regionalne , które zależy od języka użytkownika, marki systemu operacyjnego i ewentualnie innych warunków. Dlatego zakładane kodowanie jest systematycznie błędne dla plików, które pochodzą z komputera o innym ustawieniu, a nawet z inaczej zlokalizowanego oprogramowania w tym samym systemie. W przypadku Unicode jednym z rozwiązań jest użycie znacznika kolejności bajtów , ale w przypadku kodu źródłowego i innego tekstu do odczytu maszynowego wiele parserów tego nie toleruje. Innym jest przechowywanie kodowania jako metadanych w systemie plików. Systemy plików, które obsługują rozszerzone atrybuty plików, mogą przechowywać to jako user.charset. Wymaga to również wsparcia w oprogramowaniu, które chce z tego skorzystać, ale nie przeszkadza innym programom.

Podczas gdy kilka kodowań jest łatwych do wykrycia, w szczególności UTF-8, wiele jest trudnych do odróżnienia (zobacz wykrywanie zestawów znaków ). Przeglądarka internetowa może nie być w stanie odróżnić strony zakodowanej w EUC-JP i innej w Shift-JIS, jeśli schemat kodowania nie jest przypisany jawnie za pomocą nagłówków HTTP wysłanych wraz z dokumentami lub za pomocą metatagów dokumentu HTML , które są używane do zastąpić brakujące nagłówki HTTP, jeśli serwer nie może być skonfigurowany do wysyłania odpowiednich nagłówków HTTP; zobacz kodowanie znaków w HTML .

Błędna specyfikacja

Mojibake występuje również, gdy kodowanie jest błędnie określone. Dzieje się tak często między podobnymi kodowaniami. Na przykład klient poczty Eudora dla systemu Windows był znany z wysyłania wiadomości e-mail oznaczonych jako ISO-8859-1 , które w rzeczywistości były Windows-1252 . Wersja Eudora dla systemu Mac OS nie wykazała tego zachowania. Windows-1252 zawiera dodatkowe drukowalne znaki z zakresu C1 (najczęściej spotykane są zakrzywione cudzysłowy i dodatkowe myślniki ), które nie były wyświetlane poprawnie w oprogramowaniu zgodnym ze standardem ISO; dotyczyło to szczególnie oprogramowania działającego w innych systemach operacyjnych, takich jak Unix .

Ludzka ignorancja

Spośród wciąż używanych kodowań, wiele jest częściowo ze sobą kompatybilnych, z ASCII jako dominującym wspólnym podzbiorem. To przygotowuje grunt pod ludzką ignorancję:

  • Zgodność może być właściwością zwodniczą, ponieważ na wspólny podzbiór znaków nie ma wpływu pomieszanie dwóch kodowań (patrz Problemy w różnych systemach pisma ).
  • Ludzie myślą, że używają ASCII i mają tendencję do oznaczania dowolnego nadzbioru ASCII, którego faktycznie używają, jako "ASCII". Może dla uproszczenia, ale nawet w literaturze naukowej, słowo „ASCII” można znaleźć używany jako przykład czegoś nie zgodnego z Unicode, gdzie ewidentnie „ASCII” jest Windows 1252 oraz „Unicode” jest UTF-8. Zauważ, że UTF-8 jest wstecznie kompatybilny z ASCII.

Nadmierna specyfikacja

Gdy istnieją warstwy protokołów, z których każdy próbuje określić kodowanie na podstawie innych informacji, najmniej pewne informacje mogą wprowadzać odbiorcę w błąd. Rozważmy na przykład serwer WWW obsługujący statyczny plik HTML przez HTTP. Zestaw znaków można przekazać klientowi na 3 sposoby:

  • w nagłówku HTTP. Informacje te mogą być oparte na konfiguracji serwera (np. podczas udostępniania pliku poza dyskiem) lub kontrolowane przez aplikację działającą na serwerze (dla dynamicznych stron internetowych).
  • w pliku jako metatag HTML ( http-equivlub charset) lub encodingatrybut deklaracji XML . Jest to kodowanie, w którym autor zamierzał zapisać konkretny plik.
  • w pliku jako oznaczenie kolejności bajtów . To jest kodowanie, w którym edytor autora faktycznie go zapisał. O ile nie doszło do przypadkowej konwersji kodowania (poprzez otwarcie go w jednym kodowaniu i zapisanie go w innym), będzie to poprawne. Jest jednak dostępny tylko w kodowaniach Unicode, takich jak UTF-8 lub UTF-16.

Brak wsparcia sprzętowego lub programowego

Znacznie starszy sprzęt jest zwykle zaprojektowany do obsługi tylko jednego zestawu znaków i zazwyczaj nie można go zmienić. Tabela znaków zawarta w oprogramowaniu sprzętowym wyświetlacza zostanie zlokalizowana tak, aby zawierała znaki dla kraju, w którym urządzenie ma być sprzedawane, i zazwyczaj tabela różni się w zależności od kraju. W związku z tym systemy te potencjalnie będą wyświetlać mojibake podczas ładowania tekstu wygenerowanego w systemie z innego kraju. Podobnie wiele wczesnych systemów operacyjnych nie obsługuje wielu formatów kodowania i dlatego wyświetla mojibake w przypadku wyświetlania niestandardowego tekstu — na przykład wczesne wersje systemu Microsoft Windows i Palm OS są zlokalizowane w poszczególnych krajach i będą obsługuje standardy kodowania odpowiednie dla kraju, w którym będzie sprzedawana zlokalizowana wersja, i wyświetli mojibake, jeśli zostanie otwarty plik zawierający tekst w innym formacie kodowania niż wersja obsługiwana przez system operacyjny.

Postanowienia

Aplikacje używające UTF-8 jako domyślnego kodowania mogą osiągnąć wyższy stopień współdziałania ze względu na jego szerokie zastosowanie i wsteczną kompatybilność z US-ASCII . UTF-8 ma również możliwość bezpośredniego rozpoznawania przez prosty algorytm, więc dobrze napisane oprogramowanie powinno być w stanie uniknąć mieszania UTF-8 z innymi kodowaniami.

Trudność w rozwiązaniu instancji mojibake różni się w zależności od aplikacji, w której występuje, i jej przyczyn. Dwie z najczęstszych aplikacji, w których może wystąpić mojibake, to przeglądarki internetowe i edytory tekstu . Nowoczesne przeglądarki i edytory tekstu często obsługują szeroką gamę kodowań znaków. Przeglądarki często pozwalają użytkownikowi na zmianę ustawień kodowania silnika renderującego w locie, podczas gdy edytory tekstu pozwalają użytkownikowi wybrać odpowiednie kodowanie podczas otwierania pliku. Odnalezienie prawidłowego kodowania może zająć użytkownikom kilka prób i błędów .

Problem staje się bardziej skomplikowany, gdy występuje w aplikacji, która normalnie nie obsługuje szerokiego zakresu kodowania znaków, na przykład w grze komputerowej innej niż Unicode. W takim przypadku użytkownik musi zmienić ustawienia kodowania systemu operacyjnego, aby dopasować je do gry. Jednak zmiana ustawień kodowania w całym systemie może również powodować Mojibake w istniejących aplikacjach. W systemie Windows XP lub nowszym użytkownik ma również możliwość korzystania z Microsoft AppLocale , aplikacji umożliwiającej zmianę ustawień regionalnych poszczególnych aplikacji. Mimo to zmiana ustawień kodowania systemu operacyjnego nie jest możliwa we wcześniejszych systemach operacyjnych, takich jak Windows 98 ; aby rozwiązać ten problem we wcześniejszych systemach operacyjnych, użytkownik musiałby użyć aplikacji do renderowania czcionek innych firm.

Problemy w różnych systemach pisma

język angielski

Mojibake w tekstach angielskich zwykle występuje w znakach interpunkcyjnych, takich jak pauzy (—), pauzy (–) i cudzysłowy („,”,','), ale rzadko w tekście znakowym, ponieważ większość kodowań zgadza się z ASCII na kodowanie alfabetu angielskiego . Na przykład krzyżyk „£” pojawi się jako „£”, jeśli został zakodowany przez nadawcę jako UTF-8, ale zinterpretowany przez odbiorcę jako CP1252 lub ISO 8859-1 . W przypadku iteracji przy użyciu CP1252, może to prowadzić do „£”, „£”, „ÃÆ'‚šÂ£” itp.

Niektóre komputery, w starszych epokach, miały kodowanie specyficzne dla dostawcy, co powodowało niezgodność również w przypadku tekstu w języku angielskim. 8-bitowe komputery marki Commodore używały kodowania PETSCII , co jest szczególnie godne uwagi ze względu na odwracanie wielkich i małych liter w porównaniu ze standardowym ASCII . Drukarki PETSCII działały dobrze na innych komputerach tamtej epoki, ale odwracały wielkość liter. Komputery mainframe IBM używają kodowania EBCDIC, które w ogóle nie jest zgodne z ASCII.

Inne języki zachodnioeuropejskie

Alfabety języków północnogermańskich , katalońskiego , fińskiego , niemieckiego , francuskiego , portugalskiego i hiszpańskiego są rozszerzeniami alfabetu łacińskiego . Dodatkowe znaki to zazwyczaj te, które ulegają uszkodzeniu, przez co teksty są tylko nieznacznie nieczytelne za pomocą mojibake:

…i ich odpowiedniki pisane wielkimi literami, jeśli mają zastosowanie.

Są to języki, dla których używany jest zestaw znaków ISO-8859-1 (znany również jako Latin 1 lub Western ). Jednak ISO-8859-1 został przestarzały przez dwa konkurencyjne standardy, wstecznie kompatybilny Windows-1252 i nieco zmieniony ISO-8859-15 . Oba dodają znak Euro € i francuski œ, ale poza tym pomylenie tych trzech zestawów znaków nie tworzy mojibake w tych językach. Co więcej, zawsze można bezpiecznie interpretować ISO-8859-1 jako Windows-1252 i całkiem bezpiecznie interpretować go jako ISO-8859-15, w szczególności w odniesieniu do znaku euro, który zastępuje rzadko używany znak waluty (¤) . Jednak wraz z pojawieniem się UTF-8 , mojibake stało się bardziej powszechne w niektórych scenariuszach, np. wymiana plików tekstowych między komputerami UNIX i Windows , ze względu na niekompatybilność UTF-8 z Latin-1 i Windows-1252. Ale UTF-8 może być bezpośrednio rozpoznawany przez prosty algorytm, więc dobrze napisane oprogramowanie powinno być w stanie uniknąć mieszania UTF-8 z innymi kodowaniami, więc było to najbardziej powszechne, gdy wiele z nich miało oprogramowanie nie obsługujące UTF-8. Większość z tych języków była obsługiwana przez domyślny CP437 MS-DOS i inne domyślne kodowania maszynowe, z wyjątkiem ASCII, więc problemy przy zakupie wersji systemu operacyjnego były mniej powszechne. Windows i MS-DOS nie są jednak kompatybilne.

W szwedzkim, norweskim, duńskim i niemieckim samogłoski rzadko się powtarzają i zwykle jest to oczywiste, gdy jeden znak zostanie uszkodzony, np. druga litera w „kÃ⁠¤rlek” ( kärlek , „miłość”). W ten sposób, mimo że czytelnik musi odgadnąć między å, ä i ö, prawie wszystkie teksty pozostają czytelne. Z drugiej strony tekst fiński zawiera samogłoski powtarzające się w słowach takich jak hääyö („noc poślubna”), co może czasami utrudniać czytanie tekstu (np. hääyö pojawia się jako „hÃ⁠¤Ã⁠¤yÃ⁠¶”). Islandzki i Farerski mają odpowiednio dziesięć i osiem znaków, które mogą być mylące, co może utrudnić odgadnięcie uszkodzonych znaków; Islandzkie słowa, takie jak þjóðlöð („niezwykła gościnność”), stają się prawie całkowicie niezrozumiałe, gdy są tłumaczone jako „þjóðlöð”.

W języku niemieckim Buchstabensalat („sałatka z listami”) jest powszechnym określeniem tego zjawiska, a w języku hiszpańskim deformación (dosłownie deformacja).

Niektórzy użytkownicy transliterują swoje pismo podczas korzystania z komputera, pomijając problematyczne znaki diakrytyczne lub stosując zamienniki dwuznaków (å → aa, ä/æ → ae, ö/ø → oe, ü → ue itp.). W związku z tym autor może napisać „ueber” zamiast „über”, co jest standardową praktyką w języku niemieckim, gdy umlauty nie są dostępne. Ta ostatnia praktyka wydaje się być lepiej tolerowana w sferze języka niemieckiego niż w krajach skandynawskich . Na przykład w języku norweskim dwuznaki kojarzą się z archaicznym językiem duńskim i mogą być używane żartobliwie. Digrafy są jednak przydatne w komunikacji z innymi częściami świata. Na przykład norweski piłkarz Ole Gunnar Solskjær miał na plecach pisane „SOLSKJAER”, kiedy grał dla Manchesteru United .

Artefakt kodu UTF-8 błędnie zinterpretowany jako ISO-8859-1 , „Ring meg nÃ¥” („ Ring meg nå ”), został zaobserwowany w oszustwie SMS, który szalał w Norwegii w czerwcu 2014 r.

Przykłady
Przykład szwedzki: Smörgås ( otwarta kanapka )
Kodowanie plików Ustawienie w przeglądarce Wynik
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

Europa Środkowo-Wschodnia

Może to również dotyczyć użytkowników języków Europy Środkowej i Wschodniej . Ponieważ od połowy do końca lat osiemdziesiątych większość komputerów nie była podłączona do żadnej sieci, dla każdego języka istniały różne kodowania znaków ze znakami diakrytycznymi (patrz ISO/IEC 8859 i KOI-8 ), często także różne w zależności od systemu operacyjnego.

język węgierski

Węgierski to kolejny język, którego dotyczy problem, który używa 26 podstawowych znaków angielskich oraz akcentowane formy á, é, í, ó, ú, ö, ü (wszystkie obecne w zestawie znaków Latin-1) oraz dwa znaki ő i ű , których nie ma w języku Latin-1. Te dwa znaki mogą być poprawnie zakodowane w Latin-2, Windows-1250 i Unicode. Zanim Unicode stał się powszechny w klientach poczty e-mail, wiadomości e-mail zawierające tekst węgierski często miały uszkodzone litery ő i ű, czasami do stopnia nierozpoznawalnego. Powszechne jest odpowiadanie na wiadomości e-mail, które są nieczytelne (patrz przykłady poniżej) poprzez przekręcanie znaków (określane jako „betűszemét”, co oznacza „śmieci listowe”), z frazą „Árvíztűrő tükörfúrógép”, nonsensowną frazą (dosłownie „Flood- odporna wiertarka lustrzana”) zawierająca wszystkie znaki akcentowane używane w języku węgierskim.

Przykłady
Kodowanie źródła Kodowanie docelowe Wynik Występowanie
Przykład węgierski ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP
árvíztűrő tükörfúrógép
Znaki na czerwono są nieprawidłowe i nie pasują do przykładu w lewym górnym rogu.
PK 852 PK 437 RV ZT δ R è TÜKÖRF Θ R α GÉP
árvízt r ï tükörfúrógép
Było to bardzo powszechne w erze DOS, kiedy tekst był kodowany przez środkowoeuropejskie kodowanie CP 852 ; jednak system operacyjny , oprogramowanie lub drukarka używały domyślnego kodowania CP 437 . Należy pamiętać, że małe litery są w większości poprawne, z wyjątkiem ő (ï) i ű (√). Ü/ü jest poprawne, ponieważ CP 852 został dostosowany do języka niemieckiego. Obecnie występuje głównie na drukowanych receptach i czekach.
CWI-2 PK 437 Lista RV ì ZT ź R ° TÜKÖRF Ù R ò GÉP
árvízt Û R ô tükörfúrógép
CWI-2 kodowania został zaprojektowany tak, że tekst pozostaje dość dobrze czytelny nawet jeśli wyświetlacz lub drukarka używa domyślnego CP 437 kodowanie. To kodowanie było intensywnie używane w latach 80. i wczesnych 90., ale obecnie jest całkowicie przestarzałe.
Okna-1250 Okna-1252 ÁRVÍZT Û R Õ TÜKÖRFÚRÓGÉP
árvízt û r õ tükörfúrógép
Domyślne kodowanie Western Windows jest używane zamiast środkowoeuropejskiego. Tylko ő-Ő (õ-Õ) i ű-Ű (û-Û) są błędne, ale tekst jest całkowicie czytelny. To obecnie najczęstszy błąd; z powodu ignorancji często pojawia się na stronach internetowych, a nawet w mediach drukowanych.
PK 852 Okna-1250 µ RV Ö ZT ë R Š T š K RF é R ŕ G?? P
dzieci ztűr < T ?? k " rf Ł r ˘ g p
Zamiast kodowania DOS używane jest środkowoeuropejskie kodowanie Windows. Użycie ű jest poprawne.
Okna-1250 PK 852 RV ZT R ń T K Í RF R Ë G P
SS dzieci Y ztűr § t Ø K ÷ RF ˙ R g Ú str
Zamiast kodowania Windows używane jest środkowoeuropejskie kodowanie DOS. Użycie ű jest poprawne.
Cytowane-do druku 7-bitowy kod 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
Głównie spowodowane przez źle skonfigurowane serwery pocztowe, ale może również wystąpić w wiadomościach SMS na niektórych telefonach komórkowych.
UTF-8 Okna-1252 à ?? RV à ?? ZT nm ° R nm ?? T AOe K Ã- RF AS R Ô G à ‰ P
 ¡ dzieci à ZT A ± r A” t å¼ K ö RF ú R ó g à © str
Głównie spowodowane przez źle skonfigurowane usługi sieciowe lub klienty poczty internetowej, które nie zostały przetestowane pod kątem użycia międzynarodowego (ponieważ problem pozostaje ukryty w przypadku tekstów w języku angielskim). W tym przypadku rzeczywista (często generowana) zawartość jest w UTF-8 ; jednak nie jest skonfigurowany w nagłówkach HTML , więc silnik renderujący wyświetla go z domyślnym kodowaniem zachodnim.

Polskie

Przed stworzeniem ISO 8859-2 w 1987 r. użytkownicy różnych platform komputerowych używali własnych kodowań znaków, takich jak AmigaPL na Amidze, Atari Club na Atari ST i Masovia, IBM CP852 , Mazovia i Windows CP1250 na komputerach IBM PC. Polskie firmy sprzedające wczesne komputery DOS stworzyły własne, wzajemnie niekompatybilne sposoby kodowania polskich znaków i po prostu przeprogramowały EPROM kart graficznych (zwykle CGA , EGA lub Hercules ), aby zapewnić sprzętowe strony kodowe z niezbędnymi glifami dla języka polskiego — arbitralnie zlokalizowanymi bez odniesienie do miejsca, w którym umieścili je inni sprzedawcy komputerów.

Sytuacja zaczęła się poprawiać, gdy pod naciskiem środowisk akademickich i użytkowników ISO 8859-2 odniosła sukces jako „standard internetowy” z ograniczonym wsparciem oprogramowania dominujących dostawców (dziś w dużej mierze zastąpionego przez Unicode). Ze względu na liczne problemy wynikające z różnorodności kodowań, niektórzy użytkownicy do dziś określają polskie znaki diakrytyczne jako krzaczki ([ksach-kih], dosł. „krzaczki”).

Rosyjski i inne alfabety cyrylicy

Mojibake można potocznie nazywać krakozyabry ( кракозя́бры [krɐkɐˈzʲæbrɪ̈] ) w języku rosyjskim , który był i pozostaje skomplikowany przez kilka systemów kodowania cyrylicy . Związek Radziecki i wcześnie Federacja Rosyjska rozwinięte kodowanie KOI ( Kod Obmena Informatsiey , Код Обмена Информацией , co przekłada się na „Kod Wymiany Informacji”). Zaczęło się od 7-bitowego KOI7 zawierającego tylko cyrylicę , opartego na ASCII, ale z łaciną i kilkoma innymi znakami zastąpionymi literami cyrylicy. Potem przyszło 8-bitowekodowanie KOI8, które jest rozszerzeniem ASCII, które koduje litery cyrylicy tylko za pomocą wysokobitowych oktetów odpowiadających 7-bitowym kodom z KOI7. Z tego powodu tekst KOI8, nawet rosyjski, pozostaje częściowo czytelny po usunięciu ósmego bitu, co było uważane za główną zaletę w dobie 8BITMIME - nieświadomych systemów pocztowych. Na przykład słowa " Школа русского языка " shkola russkogo yazyka , zakodowane w KOI8 , a następnie przepuszczone przez proces usuwania wysokich bitów, są renderowane jako "[KOLA RUSSKOGO qZYKA". Ostatecznie KOI8 zyskało różne smaki dla rosyjskiego i bułgarskiego ( KOI8-R ), ukraińskiego ( KOI8-U ), białoruskiego (KOI8-RU), a nawet tadżyckiego (KOI8-T).

Tymczasem na Zachodzie strona kodowa 866 obsługiwała języki ukraiński i białoruski, a także rosyjski/ bułgarski w systemie MS-DOS . Dla Microsoft Windows , Code Page 1251 dodano wsparcie dla serbskim i inne słowiańskie warianty cyrylicą .

Ostatnio kodowanie Unicode obejmuje punkty kodowe dla praktycznie wszystkich znaków wszystkich języków świata, w tym wszystkich znaków cyrylicy.

Przed Unicode konieczne było dopasowanie kodowania tekstu do czcionki przy użyciu tego samego systemu kodowania. Niewykonanie tego spowodowało nieczytelny bełkot, którego specyficzny wygląd różnił się w zależności od dokładnej kombinacji kodowania tekstu i kodowania czcionek. Na przykład próba wyświetlenia tekstu cyrylicy innego niż Unicode przy użyciu czcionki ograniczonej do alfabetu łacińskiego lub przy użyciu domyślnego („zachodniego”) kodowania zwykle skutkuje tekstem, który składa się prawie wyłącznie z samogłosek ze znakami diakrytycznymi. (KOI8 " Библиотека " ( biblioteka , biblioteka) staje się "âÉÂÌÉÏÔÅËÁ".) Używanie strony kodowej Windows 1251 do przeglądania tekstu w KOI8 lub odwrotnie powoduje powstanie nieczytelnego tekstu składającego się głównie z wielkich liter (KOI8 i strona kodowa 1251 mają ten sam region ASCII, ale KOI8 ma wielkie litery w regionie, w którym strona kodowa 1251 ma małe litery i na odwrót). Ogólnie rzecz biorąc, bełkot cyrylicy jest objawem używania niewłaściwej czcionki cyrylicy. We wczesnych latach rosyjskiego sektora World Wide Web zarówno KOI8, jak i strona kodowa 1251 były powszechne. Od 2017 r. nadal można spotkać strony HTML ze stroną kodową 1251 i, rzadko, kodowanie KOI8, a także Unicode. (Szacuje się, że 1,7% wszystkich stron internetowych na całym świecie – wszystkie języki włącznie – są zakodowane na stronie kodowej 1251). Chociaż standard HTML zawiera możliwość określenia kodowania dla dowolnej strony internetowej w jej źródle, czasami jest to pomijane, zmuszając użytkownika aby ręcznie przełączać kodowanie w przeglądarce.

W języku bułgarskim mojibake jest często nazywany majmunica ( маймуница ), co oznacza "małpi [alfabet]". W języku serbskim nazywa się to đubre ( ђубре ), co oznacza " śmieci ". W przeciwieństwie do byłego ZSRR, Słowianie Południowi nigdy nie używali czegoś takiego jak KOI8, a Code Page 1251 był tam dominującym kodowaniem cyrylicy przed Unicode. Dlatego te języki miały mniej problemów z niekompatybilnością kodowania niż rosyjski. W latach 80. bułgarskie komputery używały własnego kodowania MIK , które jest powierzchownie podobne (choć niezgodne z) CP866.

Przykład
Rosyjski przykład: Кракозябры ( krakozyabry , śmieciowe postacie)
Kodowanie plików Ustawienie w przeglądarce Wynik
MS-DOS 855 ISO 8859-1 Æá ÆÖóÞ¢áñ
KOI8-R ISO 8859-1 ëÒÁËÏÚÑÂÒÙ
UTF-8 KOI8-R п я─п╟п╨п╬п╥я▐п╠я─я▀

Języki jugosłowiańskie

Chorwacki , bośniacki , serbski (dialekty jugosłowiańskiego języka serbsko-chorwackiego ) i słoweński dodają do podstawowego alfabetu łacińskiego litery š, đ, č, ć, ž i ich odpowiedniki w wielkich literach Š, Đ, Č, Ć, Ž ( tylko č/Č, š/Š i ž/Ž w języku słoweńskim (oficjalnie, chociaż inne są używane w razie potrzeby, głównie w nazwach obcych). Wszystkie te litery są zdefiniowane w Latin-2 i Windows-1250 , podczas gdy tylko niektóre (š, Š, ž, Ž, Đ) istnieją w zwykłym systemie operacyjnym Windows-1252 i są tam z powodu kilku innych języków.

Chociaż Mojibake może wystąpić z dowolnym z tych znaków, litery, które nie są zawarte w systemie Windows-1252, są znacznie bardziej podatne na błędy. Tak więc, nawet obecnie, „šđčćž ŠĐČĆŽ” jest często wyświetlany jako „šðèæž ŠÐÈÆŽ”, chociaż ð, è, æ, È, Æ nigdy nie są używane w językach słowiańskich.

Ograniczając się do podstawowego ASCII (na przykład większość nazw użytkowników), często zamiennikami są: š→s, đ→dj, č→c, ć→c, ž→z (duże litery analogicznie, z Đ→Dj lub Đ→DJ w zależności od wielkości liter). Wszystkie te zamiany wprowadzają niejasności, więc rekonstrukcja oryginału z takiej formy jest zwykle wykonywana ręcznie, jeśli jest to wymagane.

Windows 1252 kodowanie jest ważne, ponieważ wersje angielska systemu operacyjnego Windows są najbardziej rozpowszechnione, a nie te, zlokalizowane. Powodem tego jest stosunkowo mały i rozdrobniony rynek, rosnąca cena wysokiej jakości lokalizacji, wysoki stopień piractwa komputerowego (wynikający z wysokiej ceny oprogramowania w porównaniu do dochodów), co zniechęca do podejmowania działań lokalizacyjnych oraz osoby preferujące wersje anglojęzyczne systemu Windows i innego oprogramowania.

Dążenie do odróżnienia chorwackiego od serbskiego, bośniackiego od chorwackiego i serbskiego, a teraz nawet czarnogórskiego od pozostałych trzech, stwarza wiele problemów. Istnieje wiele różnych lokalizacji, wykorzystujących różne standardy i różnej jakości. Nie ma wspólnych tłumaczeń dla ogromnej ilości terminologii komputerowej pochodzącej z języka angielskiego. W końcu ludzie używają przyjętych angielskich słów („kompjuter” dla „komputer”, „kompajlirati” dla „kompilacja” itp.), a jeśli nie są przyzwyczajeni do przetłumaczonych terminów, mogą nie rozumieć, do czego ma służyć jakaś opcja w menu zrobić na podstawie przetłumaczonego wyrażenia. Dlatego osoby, które rozumieją angielski, a także te, które są przyzwyczajone do terminologii angielskiej (których jest najwięcej, ponieważ terminologia angielska jest również najczęściej nauczana w szkołach z powodu tych problemów) regularnie wybierają oryginalne angielskie wersje oprogramowania niespecjalistycznego.

Gdy używany jest cyrylica (dla języka macedońskiego i częściowo serbskiego ), problem jest podobny do innych skryptów opartych na cyrylicy .

Nowsze wersje angielskiego systemu Windows umożliwiają zmianę strony kodowej (starsze wersje wymagają specjalnych wersji angielskich z tą obsługą), ale to ustawienie może być i często było nieprawidłowo ustawione. Na przykład systemy Windows 98 i Windows Me można ustawić na większość jednobajtowych stron kodowych innych niż od prawej do lewej, w tym 1250, ale tylko podczas instalacji.

Języki kaukaskie

Systemy pisma niektórych języków regionu Kaukazu , w tym pisma gruzińskiego i ormiańskiego , mogą tworzyć mojibake. Problem ten jest szczególnie dotkliwy w przypadku ArmSCII lub ARMSCII, zestawu przestarzałych kodowań znaków dla alfabetu ormiańskiego, które zostały zastąpione przez standardy Unicode. ArmSCII nie jest powszechnie używany z powodu braku wsparcia w branży komputerowej. Na przykład Microsoft Windows go nie obsługuje.

kodowania azjatyckie

Inny rodzaj mojibake występuje, gdy tekst jest błędnie analizowany w kodowaniu wielobajtowym, takim jak jedno z kodowań dla języków wschodnioazjatyckich . W tego rodzaju mojibake więcej niż jeden (zazwyczaj dwa) znaki są uszkadzane na raz, np. "k舐lek" ( kärlek ) w języku szwedzkim, gdzie " är " jest analizowane jako "舐". W porównaniu z powyższym mojibake, jest to trudniejsze do odczytania, ponieważ brakuje liter niezwiązanych z problematycznym å, ä lub ö, co jest szczególnie problematyczne w przypadku krótkich słów zaczynających się na å, ä lub ö, takich jak „än” (co staje się „舅"). Ponieważ dwie litery są połączone, mojibake również wydaje się bardziej losowy (ponad 50 wariantów w porównaniu do normalnych trzech, nie licząc rzadszych wielkich liter). W niektórych rzadkich przypadkach może zostać błędnie zinterpretowany cały ciąg tekstowy, który zawiera wzór o określonej długości słowa, na przykład zdanie „ Bush ukrył fakty ”.

język japoński

W języku japońskim zjawisko to nazywa się, jak wspomniano, mojibake (文字化け) . Jest to szczególny problem w Japonii ze względu na liczne różne kodowania tekstu japońskiego. Oprócz kodowania Unicode, takiego jak UTF-8 i UTF-16, istnieją inne standardowe kodowania, takie jak Shift-JIS (maszyny Windows) i EUC-JP (systemy UNIX). Mojibake, nie tylko spotykany przez japońskich użytkowników, jest również często spotykany przez osoby niebędące Japończykami, gdy próbują uruchomić oprogramowanie napisane na rynek japoński.

chiński

W języku chińskim to samo zjawisko nosi nazwę Luàn mǎ ( Pinyin , chiński uproszczony 乱码, chiński tradycyjny 亂碼, co oznacza „kod chaotyczny”) i może wystąpić, gdy skomputeryzowany tekst jest zakodowany jednym chińskim kodowaniem znaków, ale jest wyświetlany przy użyciu niewłaściwego kodowania. W takim przypadku często można rozwiązać problem, zmieniając kodowanie znaków bez utraty danych. Sytuacja jest skomplikowana ze względu na istnienie kilku używanych chińskich systemów kodowania znaków, z których najczęstsze to: Unicode , Big5 i Guobiao (z kilkoma wersjami kompatybilnymi wstecz) oraz możliwość zakodowania chińskich znaków przy użyciu kodowania japońskiego.

Łatwo jest zidentyfikować oryginalne kodowanie, gdy luanma występuje w kodowaniach Guobiao:

Oryginalne kodowanie Oglądane jako Wynik Oryginalny tekst Notatka
Duży5 GB ? Twa 三國 志 曹操 傳 Zniekształcone chińskie znaki bez śladu oryginalnego znaczenia. Czerwony znak nie jest prawidłowym punktem kodowym w GB2312.
Shift-JIS GB 暥 帤 壔 偗 僥 僗 僩 文字 化 け テ ス ト Kana jest wyświetlana jako znaki z radykalnym 亻, podczas gdy kanji to inne znaki. Większość z nich jest niezwykle rzadka i nie ma praktycznego zastosowania we współczesnym języku chińskim.
EUC-KR GB 叼 力 捞 钙 胶 抛 农 聪 墨 디제이 맥스 테크니카 Losowe popularne znaki chińskiego uproszczonego, które w większości przypadków nie mają sensu. Łatwo rozpoznawalny dzięki spacji między kilkoma znakami.

Dodatkowy problem powstaje, gdy w kodowaniu brakuje znaków, co jest powszechne w przypadku rzadkich lub przestarzałych znaków, które są nadal używane w nazwach osobistych lub nazwach miejscowości. Przykładami tego są tajwańscy politycy Wang Chien-shien ( chiński :王建煊; pinyin : Wáng Jiànxuān ) za „煊”, Yu Shyi-kun ( chiński uproszczony :游锡堃; tradycyjny chiński :游錫堃; pinyin : Yóu Xíkūn ) za „堃” i piosenkarza Davida Tao (chiń.:陶喆; pinyin: Táo Zhé ) zaginął „喆” w Big5 , byłego premiera ChRL Zhu Rongji (chiń.:朱镕基; pinyin: Zhū ​​Róngjī ) zaginęło „镕” w GB2312 , brak symbolu praw autorskich „©” w GBK .

Gazety radziły sobie z tym problemem na różne sposoby, w tym za pomocą oprogramowania do łączenia dwóch istniejących, podobnych postaci; używanie obrazu osobowości; lub po prostu zastępując rzadki znak homofonem w nadziei, że czytelnik będzie w stanie dokonać poprawnego wnioskowania.

Tekst indyjski

Podobny efekt może wystąpić w pismach bramickich lub indyjskich z Azji Południowej , używanych w takich językach indoaryjskich lub indyjskich, jak hindustański (hindi-urdu), bengalski , pendżabski , marathi i inne, nawet jeśli zastosowany zestaw znaków jest prawidłowo rozpoznawany przez Aplikacja. Dzieje się tak, ponieważ w wielu skryptach indyjskich zasady, według których poszczególne symbole liter łączą się, tworząc symbole dla sylab, mogą nie być właściwie zrozumiane przez komputer, który nie ma odpowiedniego oprogramowania, nawet jeśli dostępne są glify dla poszczególnych form liter.

Jednym z przykładów jest stare logo Wikipedii , które próbuje pokazać znak analogiczny do „wi” (pierwsza sylaba „Wikipedii”) na każdym z wielu elementów układanki. Kawałek układanki miał nosić znak Devanagari dla „wi” zamiast tego używany do wyświetlania znaku „wa”, po którym następuje niesparowana samogłoska modyfikująca „i” , łatwo rozpoznawalna jako mojibake wygenerowana przez komputer nieskonfigurowany do wyświetlania tekstu indyjskiego. Logo przeprojektowane w maju 2010 r. naprawiło te błędy.

Idea Plain Text wymaga od systemu operacyjnego dostarczenia czcionki do wyświetlania kodów Unicode. Ta czcionka różni się od OS do OS dla Singhala i tworzy niepoprawne ortograficznie glify dla niektórych liter (sylab) we wszystkich systemach operacyjnych. Na przykład „reph”, krótka forma „r” to znak diakrytyczny, który zwykle znajduje się na górze zwykłej litery. Jednak niewłaściwe jest umieszczanie na górze niektórych liter, takich jak „ya” lub „la” w określonych kontekstach. W przypadku słów lub nazw sanskryckich odziedziczonych przez współczesne języki, takich jak कार्य, IAST: kārya lub आर्या, IAST: āryā , warto umieścić je na górze tych liter. Natomiast w przypadku podobnych dźwięków we współczesnych językach, które wynikają z ich specyficznych reguł, nie umieszcza się go na górze, np. słowo करणाऱ्या, IAST: karaṇāryā , forma rdzenia popularnego słowa करणारा/री, IAST: karaṇārā/rī , w języku marathi . Ale zdarza się to w większości systemów operacyjnych. Wydaje się to być wadą wewnętrznego programowania czcionek. W systemach Mac OS i iOS kombinacja muurdhaja l (ciemne l) i „u” oraz jej długa forma dają nieprawidłowe kształty.

Niektóre skrypty indyjskie i wywodzące się z Indii, w szczególności Lao , nie były oficjalnie obsługiwane przez Windows XP aż do wydania Visty . Jednak różne witryny udostępniają czcionki do pobrania za darmo.

Birmańczyk

Ze względu na sankcje zachodnie i późne pojawienie się obsługi języka birmańskiego w komputerach, większość wczesnych lokalizacji birmańskich była rodzima bez międzynarodowej współpracy. Dominującym sposobem obsługi birmańskiej jest czcionka Zawgyi , czcionka , która została stworzona jako czcionka Unicode, ale w rzeczywistości była tylko częściowo zgodna z Unicode. W czcionce Zawgyi niektóre punkty kodowe dla birmańskiego skryptu zostały zaimplementowane zgodnie ze specyfikacją Unicode , ale inne nie. Konsorcjum Unicode nazywa to kodowaniem czcionek ad hoc . Wraz z pojawieniem się telefonów komórkowych, producenci telefonów komórkowych, tacy jak Samsung i Huawei, po prostu zastąpili czcionki systemowe zgodne ze standardem Unicode wersjami Zawgyi.

Ze względu na te kodowania ad hoc , komunikacja między użytkownikami Zawgyi i Unicode byłaby renderowana jako nieczytelny tekst. Aby obejść ten problem, producenci treści publikowali posty zarówno w Zawgyi, jak i Unicode. Rząd Birmy wyznaczył 1 października 2019 r. jako „U-Day”, aby oficjalnie przejść na Unicode. Szacuje się, że pełne przejście zajmie dwa lata.

języki afrykańskie

W niektórych systemach pisma Afryki niekodowany tekst jest nieczytelny. Teksty, które mogą tworzyć mojibake, obejmują te z Rogu Afryki, takie jak pismo Ge'ez w Etiopii i Erytrei , używane dla amharskiego , tigre i innych języków, oraz język somalijski , w którym używa się alfabetu osmanii . W Afryce Południowej , alfabet Mwangwego służy do pisania języków Malawi i alfabet Mandombe został stworzony dla Demokratycznej Republiki Konga , ale te nie są zazwyczaj obsługiwane. Różne inne systemy pisma pochodzące z Afryki Zachodniej stwarzają podobne problemy, takie jak alfabet N'Ko , używany w językach Manding w Gwinei , oraz sylabariusz Vai , używany w Liberii .

arabski

Innym językiem, którego dotyczy problem, jest arabski (patrz poniżej ). Tekst staje się nieczytelny, gdy kodowania nie są zgodne.

Przykłady

Kodowanie plików Ustawienie w przeglądarce Wynik
Przykład arabski: ( Powszechna Deklaracja Praw Człowieka )
Renderowanie w przeglądarce: الإعلان العالمى لحقوق الإنسان
UTF-8 Okna-1252 الإعلان العالمى Ù„Øقوق الإن³Ø§Ù†
KOI8-R О╩©ь╖ы└ь╔ь╧ы└ь╖ы├ ь╖ы└ь╧ь╖ы└ы┘ы┴ ы└ь╜ы┌ы┬ы┌ ь╖ы└ь╔ы├ьЁь ы├
ISO 8859-5 яЛПиЇй иЅиЙй иЇй иЇй иЙиЇй й й й ий й й иЇй иЅй иГиЇй
PK 866 я╗┐╪з┘Д╪е╪╣┘Д╪з┘Ж ╪з┘Д╪╣╪з┘Д┘Е┘Й ┘Д╪н┘В┘И┘В ╪з┘Д╪е┘Ж╪ з┘Ж
ISO 8859-6 ُ؛؟ظ ع ظ ظ ع ظ ع ظ ع ظ ظ ع ع ع ع ظع ع ع ظ ع ظ ع ظ ظ ع
ISO 8859-2 ا٠ؼؚ٠ا٠ا٠ؚا٠٠٠٠Ř٠٠٠ا٠ؼ٠ساŮ
Okna-1256 Okna-1252 ÇáÅÚáÇä ÇáÚÇáãì áÍÞæÞ ÇáÅäÓÇä

Przykłady w tym artykule nie mają UTF-8 jako ustawienia przeglądarki, ponieważ UTF-8 jest łatwo rozpoznawalny, więc jeśli przeglądarka obsługuje UTF-8, powinna rozpoznawać go automatycznie i nie próbować interpretować czegoś innego jako UTF-8.

Zobacz też

  • Punkt kodowy
  • Znak zastępczy
  • Znak zastępczy
  • NEWLINE - Konwencje do reprezentowania podział wiersza różnią się między systemami Windows i Unix. Chociaż większość oprogramowania obsługuje obie konwencje (co jest trywialne), oprogramowanie, które musi zachowywać lub wyświetlać różnicę (np. systemy kontroli wersji i narzędzia do porównywania danych ), może być znacznie trudniejsze w użyciu, jeśli nie przestrzega jednej konwencji.
  • Znacznik kolejności bajtów — najbardziej w paśmie sposób przechowywania kodowania wraz z danymi — dołącz go. Jest to celowo niewidoczne dla ludzi używających zgodnego oprogramowania, ale z założenia będzie postrzegane jako „śmieci” dla niezgodnego oprogramowania (w tym wielu tłumaczy ).
  • Jednostki HTML — kodowanie znaków specjalnych w HTML, w większości opcjonalne, ale wymagane, aby niektóre znaki mogły uniknąć interpretacji jako znaczników.

    Chociaż niepowodzenie zastosowania tej transformacji jest usterką (patrz cross-site scripting ), zbyt częste jej stosowanie powoduje zniekształcenie tych znaków. Na przykład znak cudzysłowu "staje &quot;, &amp;quot;, &amp;amp;quot;i tak dalej.

  • Bush ukrył fakty

Bibliografia

Zewnętrzne linki

  • Słownikowa definicja mojibake w Wikisłowniku
  • Multimedia związane z Mojibake w Wikimedia Commons