Konwerter kodowania i naprawa krzaków

Szybkie odpowiedzi

Czym jest mojibake?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Co robi to narzędzie

Przykłady krok po kroku

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(tylko częściowo)

Jak korzystać z narzędzia

1. 1

   Wklej zniekształcony tekst

   Po prostu wrzuć go do pola — bez wcześniejszego ustalania kodowania. Wystarczy krótki fragment; kilkanaście znaków zwykle jednoznacznie wskazuje łańcuch.

2. 2

   Przeczytaj pierwszego kandydata i jego plakietkę

   „Dokładny” znaczy, że łańcuch odtwarza wejście co do znaku. „Częściowy” znaczy, że nie odtwarza — wtedy wynik jest tylko tropem.

3. 3

   Sprawdź łańcuch kodowań

   Każdy kandydat pokazuje, w jakim kodowaniu tekst naprawdę zapisano i które go błędnie odczytało. To mówi, co naprawić u źródła, a nie tylko co było w treści.

4. 4

   W razie potrzeby zajrzyj w bajty

   Druga sekcja pokazuje dowolny tekst jako bajty w każdym popularnym kodowaniu i dekoduje surowy hex w drugą stronę. Przydaje się przy dobieraniu długości kolumn i sprawdzaniu ramek protokołu.

Błędy, które pogarszają sprawę

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Najpierw potwierdź bieżące kodowanie
file -I correct.txt   # charset=utf-8 → nie ma czego konwertować

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Przejdź przez typ binarny, żeby bajty zostały zachowane, a nie zinterpretowane na nowo
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Bierze pierwszego kandydata niezależnie od plakietki
db.update(row.id, candidates[0].text);

// Zapisuj tylko to, co domyka konwersję w obie strony
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Zdekoduj raz, na granicy, kodowaniem, którego plik faktycznie używa
with open(path, encoding='gbk') as f:
    text = f.read()

Kiedy się przydaje

Migracja bazy danych wyprodukowała krzaki

Stare tabele MySQL zadeklarowane jako latin1, a trzymające faktycznie bajty UTF-8, to zdecydowanie najczęstsze źródło problemu. Wklej tutaj zniekształcony wiersz i potwierdź prawdziwy łańcuch, zanim napiszesz ALTER TABLE — konwersja w złą stronę zamienia problem odwracalny w trwały.

Plik CSV otwarty w Excelu pokazuje bzdury

Excel na Windows nadal zakłada systemową stronę kodową dla plików CSV bez BOM, więc eksport w UTF-8 wychodzi jako krzaki, a polskie nazwiska rozsypują się pierwsze. Potwierdź łańcuch tutaj, a potem wyeksportuj ponownie z BOM albo zaimportuj kreatorem tekstu z jawnie ustawionym kodowaniem.

Logi ze starej usługi

Aplikacje pisane pod GBK albo Shift_JIS zapisują logi w tych kodowaniach, a nowoczesne agregatory czytają wszystko jako UTF-8. Wklej wiersz, żeby go odzyskać — a ponieważ nic nie jest wysyłane, można to robić na logach produkcyjnych.

Nazwy plików zepsute przez archiwum ZIP

Format ZIP nie ma pola na kodowanie, więc archiwa tworzone na chińskim czy japońskim Windowsie niosą nazwy plików w GBK albo Shift_JIS, które narzędzia uniksowe czytają jako UTF-8. Odzyskaj prawdziwe nazwy tutaj, zanim cokolwiek zmienisz.

Dobieranie długości kolumny w bazie

Podgląd bajtów pokazuje ten sam tekst naraz we wszystkich kodowaniach. Znak chiński to 3 bajty w UTF-8, ale 2 w GBK, a polskie ż zajmuje 2 bajty zamiast jednego — dokładnie takie różnice zamieniają VARCHAR(50) w błąd obcięcia.

Skąd biorą się krzaki

Bajty przeżywają, znaczenie nie

Kodowanie odwzorowuje znaki na bajty, dekodowanie prowadzi z powrotem. Mojibake to dekodowanie z niewłaściwym odwzorowaniem. Bajty nigdy nie zostały uszkodzone i dlatego odtworzenie błędnego dekodowania od tyłu zwraca oryginał co do znaku — o ile to błędne dekodowanie niczego nie odrzuciło.

Dlaczego najbardziej obrywa tekst CJK

ASCII zajmuje 0x00–0x7F i wszystkie popularne kodowania zgadzają się co do niego, więc tekst angielski przechodzi bez szwanku. Chiński, japoński i koreański wymagają sekwencji wielobajtowych, a kodowania nie zgadzają się co do ich grupowania. UTF-8 używa trzech bajtów na znak chiński, GBK dwóch. Podaj bajty UTF-8 dekoderowi GBK, a grupowanie się przesunie i wyjdzie inna liczba innych znaków.

Test konwersji w obie strony

Dla każdego łańcucha kandydata narzędzie koduje odzyskany tekst pierwszym kodowaniem i dekoduje drugim. Jeżeli odtworzy to wejście dokładnie, łańcuch tłumaczy każdy znak i kandydat dostaje plakietkę „Dokładny”. Kandydaci, którzy testu nie przechodzą, i tak są pokazywani, bo częściowe odzyskanie często wystarcza do rozpoznania treści, nawet gdy nie potrafi jej odtworzyć.

Skąd biorą się tablice kodowań

Tablice dostarcza TextDecoder przeglądarki. Kodowanie w drugą stronę jest trudniejsze, bo TextEncoder obsługuje wyłącznie UTF-8 — narzędzie buduje więc odwrotne odwzorowanie, przechodząc przestrzeń bajtów i pytając dekoder, co znaczy każda sekwencja. Dzięki temu odwzorowanie zawsze zgadza się z zachowaniem samej przeglądarki i na urządzenie nie trafiają żadne tablice.

Heurystyka porządkowania i jej granice

Poza testem konwersji w obie strony kandydaci są punktowani według tego, jaka część tekstu to częste znaki chińskie (te, których wiodący bajt GBK mieści się w 0xB0–0xF7), minus kary za znaki zastępcze, katakanę półszerokościową i znaki sterujące. Katakana półszerokościowa jest mocnym sygnałem Shift_JIS, bo normalny tekst japoński prawie jej nie używa. To heurystyka: rozstrzyga remisy, nie ustala prawdy.

Jak nie dopuścić do powtórki

Napraw źródło, a nie sam ciąg znaków

Łańcuch kodowań wypisany pod każdym kandydatem wskazuje, który element jest źle skonfigurowany. Naprawa samego tekstu bez poprawienia charsetu połączenia, czytnika plików albo ustawień eksportu oznacza powtórkę jutro, na świeżych danych.

Potwierdź kierunek, zanim przekonwertujesz cały plik

Najpierw przepuść przez tę stronę reprezentatywny wiersz. Konwersja w złą stronę potrafi wyprodukować znaki zastępcze, a ten krok — w odróżnieniu od pierwotnej pomyłki — jest nieodwracalny.

Ustawiaj kodowanie jawnie wszędzie

Charset połączenia z bazą, nagłówek HTTP Content-Type, wywołania otwierające pliki, eksport CSV. Każde miejsce, które domyślnie bierze „kodowanie systemowe”, to miejsce, w którym ten sam błąd wróci po przeniesieniu kodu na inną maszynę.

W MySQL wybieraj utf8mb4 zamiast utf8

utf8 w MySQL przechowuje najwyżej trzy bajty na znak, więc emoji i część rzadszych znaków chińskich są po cichu obcinane. utf8mb4 to prawdziwe UTF-8. To inna awaria niż mojibake i narzędzie do odzyskiwania tu nie pomoże, bo bajtów naprawdę już nie ma.

Trzymaj oryginalne bajty, dopóki poprawka nie jest zweryfikowana

Zrób kopię przed jakąkolwiek konwersją. Dopóki oryginalne bajty istnieją, każde błędne dekodowanie jest odwracalne — gdy raz zostaną nadpisane znakami zastępczymi, nie przywróci ich żadne narzędzie, ani z tej strony, ani z żadnej innej.

Najczęstsze pytania