Naprawa mojibake

Porównanie hipotez kodowania
Wklejony tekst i wszystkie warianty pozostają w tej przeglądarce. Tryb krokowy przechowuje w tej karcie jeden sprawdzony zapis przez maksymalnie 30 minut, a w adresie URL umieszcza tylko niejawny identyfikator zadania. Nic nie jest wysyłane przez nasze serwery ani interfejs API naprawy.

Wklej tekst wyglądający na uszkodzony

Wklej tekst taki jak café albo japoński ciąg, który stał się nieczytelny wskutek niezgodności kodowań. Oryginał pozostanie w edytorze bez zmian.

Maksymalnie 50 000 znaków. Narzędzie porównuje wyłącznie wklejony tekst Unicode. Nie sprawdza ani nie naprawia plików, strumieni bajtów, baz danych czy nagłówków HTTP.

Mojibake to czytelne dane wyświetlone jako niewłaściwe znaki, ponieważ bajty zdekodowano przy użyciu niezgodnego zestawu znaków. Znany przykład to café, gdy słowo café zapisano jako UTF-8, lecz jego bajty odczytano jako Latin-1 lub Windows-1252. Wklej widoczny tekst, aby porównać ściśle odwracalne hipotezy naprawy. Narzędzie zachowuje oryginał bez zmian, nazywa każdy wariant hipotezą i wykonuje porównanie lokalnie w przeglądarce.

Jak porównać hipotezę naprawy mojibake

  1. 1

    Wklej widoczny tekst

    Użyj tekstu dokładnie w otrzymanej postaci. Narzędzie nie przesyła ani nie sprawdza pliku źródłowego.

  2. 2

    Świadomie włącz porównanie

    Poproś przeglądarkę o sprawdzenie interpretacji bajtów Latin-1 i Windows-1252 w ścisłym dekoderze UTF-8.

  3. 3

    Porównuj, nie zakładaj

    Czytaj niezmieniony oryginał obok każdego odwracalnego wariantu i wybieraj tylko wtedy, gdy przemawia za tym kontekst.

  4. 4

    Skopiuj zwykły tekst

    Skopiuj, pobierz lub wydrukuj wybraną hipotezę bez nadpisywania tekstu oryginalnego.

Co naprawa mojibake może ustalić, a czego nie

Kodowanie odwzorowuje znaki na bajty i z powrotem. UTF-8 przedstawia é za pomocą dwóch bajtów C3 A9. Gdy oprogramowanie odczyta je jako Windows-1252 lub ISO-8859-1, wynikiem może być é. Przydatna hipoteza naprawy odwraca właśnie ten błąd: traktuje widoczne znaki starszego kodowania jako wartości bajtów, ściśle dekoduje te bajty jako UTF-8 i sprawdza, czy ponowne kodowanie wariantu w UTF-8 daje dokładnie te same bajty.

Kontrola w obie strony odrzuca niepełne i nieprawidłowe sekwencje UTF-8. Odrzuca też wariant zawierający znak zastępczy , ponieważ informacja ukryta za tym znakiem została już utracona. Poprawne odtworzenie bajtów jest przesłanką na rzecz hipotezy, lecz nie dowodzi, jakiego kodowania używał system źródłowy ani co zamierzał autor.

Widoczny tekst Sprawdzana hipoteza Możliwy wariant Co sprawdzić
café Bajty UTF-8 odczytane jako Latin-1 café Porównaj pisownię ze źródłem
It’s Bajty UTF-8 odczytane jako Windows-1252 It’s Sprawdź interpunkcję i reguły redakcyjne
文字化け Bajty UTF-8 odczytane jako Latin-1 文字化け Porównaj japoński tekst z wiarygodną kopią
café Dwa kolejne błędy kodowania café Sprawdź oba kontrolowane przejścia

Dlaczego tekst japoński wymaga kontekstu

Japońskie określenie 文字化け oznacza zniekształcone znaki. Tekst japoński zapisany w UTF-8 może zmienić się w długą mieszaninę liter łacińskich, symboli i znaków przypominających sterujące, jeśli jego bajty zostaną odczytane w niewłaściwym starszym kodowaniu. Odwracalność jest cenna, ale krótka nazwa lub pojedynczy znak nadal mogą być niejednoznaczne. Porównaj wariant z oryginalnym dokumentem, eksportem bazy danych, wiadomością od nadawcy albo inną autorytatywną kopią.

Ograniczenia i bezpieczniejsze odzyskiwanie

Narzędzie otrzymuje tekst Unicode, który przeglądarka już zdekodowała. Nie odzyska wcześniej utraconych bajtów, nie rozpozna kodowania pliku binarnego, nie naprawi kolumny bazy danych i nie zmieni nagłówka HTTP Content-Type. Jeśli nie pojawi się żaden wariant, zachowaj oryginał. W miarę możliwości zdobądź rzeczywiste bajty źródłowe, utwórz kopię zapasową, ustal deklarowane i faktyczne kodowanie, a następnie zdekoduj materiał jeden raz narzędziem przeznaczonym do plików lub strumieni bajtów. Nigdy nie zapisuj wielokrotnie uszkodzonego tekstu na jedynej kopii źródła.

Najczęściej zadawane pytania

Nie. Oznacza jedynie, że określona interpretacja bajtów starszego kodowania dała prawidłowy UTF-8 i przeszła dokładną kontrolę odtworzenia bajtów. Różne interpretacje mogą tworzyć ten sam lub inny czytelny tekst. Nadal potrzebujesz kontekstu i autorytatywnego źródła.

Widoczne znaki mogą nie pochodzić z bajtów UTF-8 odczytanych jako ISO-8859-1 lub Windows-1252, sekwencja może być niepełna albo znak zastępczy mógł już usunąć informację. Zachowaj oryginał i sprawdź rzeczywiste bajty oraz metadane kodowania.

Nie. Porównuje wyłącznie wklejony tekst Unicode. Nie odczytuje plików ani ich kodowania, nie łączy się z bazą danych, nie przepisuje zapisanych wartości i nie naprawia nagłówków serwera. Przed konwersją bajtów wykonaj kopię zapasową źródła.

Nie. Porównanie, wybór wariantu, kopiowanie, utworzenie TXT i przygotowanie wydruku odbywają się w przeglądarce. Tryb krokowy może zachować jeden sprawdzony zapis w tej karcie przez maksymalnie 30 minut i umieszcza w adresie URL tylko niejawny identyfikator zadania.

Powiązane narzędzia