Konwersja pliku Windows-1252 do UTF-8 bez zmiany zakończeń wierszy

Przykład bajt po bajcie pokazujący, jak zachować znaki diakrytyczne, symbol euro i CRLF podczas konwersji lokalnego pliku tekstowego do UTF-8.

Mały, powtarzalny przykład

Wybierz Wczytaj przykład Windows-1252. Syntetyczny plik zawiera dokładnie osiem bajtów: 43 61 66 E9 20 80 0D 0A. Kodowanie Windows-1252 jest wybrane jawnie. Oczekiwany tekst Unicode to Café €\r\n: końcowy zapis oznacza rzeczywisty CR, po którym następuje LF, a nie cztery dosłowne znaki.

Punkty kodowe Unicode to U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. UTF-8 nie może ściśle zdekodować oryginalnych bajtów: po E9 nie następują wymagane bajty kontynuacji. To powód, by sprawdzić kodowanie źródłowe, a nie dowód, że każdy taki plik jest w Windows-1252.

1. Pozostaw wybrane Windows-1252 i kliknij Podgląd konwersji.
2. Sprawdź, czy podgląd pokazuje Café €, a szczegóły wskazują jeden CRLF i końcowy znak nowego wiersza.
3. Pozostaw opcję BOM pliku wynikowego wyłączoną, chyba że aplikacja docelowa wyraźnie go wymaga.
4. Pobierz plik UTF-8. Jego dokładnie jedenaście bajtów to 43 61 66 C3 A9 20 E2 82 AC 0D 0A.
5. Po zaznaczeniu opcji BOM ponownie wyświetl podgląd: wynik ma czternaście bajtów i zaczyna się od EF BB BF przed tymi jedenastoma bajtami.

Dlaczego informacja „ANSI” nie wystarcza

Etykieta „ANSI” w aplikacji jest niejednoznaczna. Windows-1252 przypisuje bajtowi 80 symbol euro; ISO-8859-1 przypisuje mu U+0080, znak sterujący C1 odrzucany przez to narzędzie. Bajty 81, 8D, 8F, 90 i 9D są niezdefiniowane w ścisłym mapowaniu Windows-1252 tego narzędzia i zatrzymują konwersję. Zapytaj autora eksportu o rzeczywiste kodowanie zamiast próbować kolejnych opcji, aż tekst zacznie wyglądać wiarygodnie.

BOM, UTF-16 i uszkodzone zakończenia wierszy

FF FE 41 00 0D 00 0A 00 to przykład UTF-16LE ze znacznikiem BOM. Po konwersji ma postać 41 0D 0A w UTF-8 bez BOM: A i CRLF. Bez BOM trzeba jawnie wybrać UTF-16. Nieparzysty ostatni bajt lub niesparowany surogat zatrzymuje konwersję, również poza widocznym podglądem. BOM UTF-32 jest rozpoznawany, ale odrzucany.

Co konwersja zachowuje, a czego nie naprawi

Spacje, tabulatory, mieszane zakończenia CRLF/LF/CR, obecność lub brak końcowego znaku nowego wiersza oraz złożone i łączone znaki Unicode zostają zachowane. Usuwany jest tylko początkowy BOM źródła; o BOM w pliku wynikowym decydujesz Ty. Jeśli U+FFFD występuje już w źródle, pozostaje w nim. Konwersja uszkodzonego już „Café” nie odzyskuje oryginalnych bajtów.

Limit wynosi 5 MiB (5 242 880 bajtów); podgląd pokazuje najwyżej 16 000 jednostek kodowych UTF-16, a walidacja i eksport obejmują cały plik. Znane sygnatury binarne oraz znaki sterujące NUL/C0/C1 inne niż tabulator, CR i LF są odrzucane. To ostrożne zabezpieczenie może odrzucić nietypowy, poprawny tekst. Pobrane pliki mają rozszerzenie .utf8.txt i zawierają zwykły tekst. Plik źródłowy nie jest nadpisywany.

W pracy z CSV najpierw zmień kodowanie, a następnie użyj narzędzia CSV do JSON do zmiany jego struktury. Samo narzędzie kodowania nie analizuje CSV ani nie zmienia separatorów. Przetwarzanie odbywa się w pamięci przeglądarki, bez żądań sieciowych ani zapisu danych przez narzędzie; zwykłe żądania witryny nadal pobierają strony i zasoby. Otwórz narzędzie Inspektor kodowania, aby wypróbować dokładnie ten przykład.