Jak zdiagnozować błędnie wyświetlane emoji w wyeksportowanym pliku dziennika

Przyjrzyj się dokładnie jednemu wpisowi, którego dotyczy problem. Ciąg nieoczekiwanych znaków, taki jak 😀 zamiast 😀, może wskazywać, że bajty UTF-8 zinterpretowano przy użyciu innego kodowania. Zjawisko to jest powszechnie nazywane mojibake: wyświetlane znaki są nieprawidłowe, ponieważ bajty odczytano przy błędnych założeniach. To wskazówka, ale nie dowód na to, jakiego kodowania użyto w pliku.

Widoczny znak � to coś innego. Jest to U+FFFD, znak zastępczy Unicode używany w miejsce znaku, którego nie można zinterpretować. W glosariuszu Unicode odróżnia go od glifu zastępczego: czcionka lub mechanizm renderujący może wyświetlić kwadrat, gdy nie potrafi narysować znaku, ale sam znak może nadal być nienaruszony. Jeśli tylko niektóre emoji wyświetlają się jako kwadraty, zanim zmienisz kodowanie pliku, sprawdź je w innej, aktualnej aplikacji lub czcionce.

Utwórz kopię eksportu i pozostaw oryginał bez zmian. Zapisz rozszerzenie pliku, nazwę aplikacji, która go wyeksportowała, oraz to, jak wygląda problematyczny fragment. Jeśli to możliwe, porównaj znane emoji z dziennika z tym samym wpisem w aplikacji źródłowej lub wcześniejszym eksporcie. Nie otwieraj i nie zapisuj wielokrotnie jedynej kopii: edytor tekstu może zapisać nowo odczytany tekst jako bajty, trwale utrwalając wynik odwracalnego eksperymentu z wyświetlaniem.

Otwórz kopię jako zwykły tekst w edytorze, który pozwala wybrać kodowanie. Najpierw wypróbuj kodowanie podane w dokumentacji aplikacji dziennika; jeśli nie jest znane, a plik to typowy współczesny eksport tekstowy, UTF-8 jest rozsądną opcją do sprawdzenia, ale nie założeniem, na podstawie którego należy nadpisać oryginał. Porównaj problematyczny tekst i otaczające go zwykłe znaki przy każdym rozważanym kodowaniu. Spójny wynik w całym pliku jest mocniejszym dowodem niż emoji, które przypadkiem wygląda poprawnie.

Jeśli zmiana widoku kodowania w edytorze sprawia, że dziwny ciąg znaków zmienia się w oczekiwane emoji, a otaczający tekst staje się czytelny, eksport może zawierać nienaruszone bajty, które zostały błędnie zinterpretowane. Zamknij kopię bez zapisywania, a następnie otwórz ją ponownie z obiecującym ustawieniem, aby to potwierdzić. Sprawdź też, czy w przepływie pracy aplikacji dziennika dotyczącym importu lub otwierania plików można wybrać udokumentowane kodowanie; do ponownego importu użyj tej ścieżki.

FAQ Unicode UTF wyjaśnia, że niepoprawne sekwencje bajtów UTF-8 mogą powodować błąd albo zostać obsłużone przez wstawienie znacznika, takiego jak U+FFFD. Oznacza to, że dekoder mógł już zastąpić nieprawidłowe dane podczas wyświetlania lub importowania. Zmiana kodowania po tym etapie nie musi odzyskać oryginalnych bajtów. Nie używaj opcji „naprawy” ani konwersji, które po cichu zastępują nierozpoznane znaki, jeśli pracujesz na jedynej kopii.

Jeśli emoji wyświetla się poprawnie w innym programie, zachowaj to porównanie jako dowód przed wprowadzeniem zmian w pliku. Nie przepisuj eksportu wyłącznie po to, by zmienić jego wygląd.

Jeśli w tym samym miejscu w różnych programach pojawia się U+FFFD lub zwykły znak zapytania, porównaj plik z dziennikiem źródłowym albo wcześniejszym eksportem. Znaku zastępczego zapisanego w pliku nie da się przywrócić przez zmianę czcionki. Odzyskanie znaku jest możliwe, jeśli zachowała go inna kopia.

Rozszerzenie .csv nie wskazuje, jakiego kodowania znaków użyto, a programy arkuszy kalkulacyjnych mogą stosować własne ustawienia importu. W przypadku programu Excel na komputerze Microsoft opisuje importowanie tekstu za pomocą Dane > Z tekstu/CSV oraz Kreatora importu tekstu w przewodniku po importowaniu i eksportowaniu tekstu oraz plików CSV. Przed wczytaniem sprawdź podgląd: zweryfikuj emoji, granice wierszy i kolumn oraz sąsiedni tekst. Poprawny podgląd świadczy o tym, że wybrana ścieżka importu odczytuje plik zgodnie z oczekiwaniami; nie jest powodem, by nadpisywać źródło.

W przypadku JSON zachowaj plik i użyj narzędzia do importowania obsługującego JSON, zamiast traktować go jak CSV. Specyfikacja JSON RFC 8259 wymaga kodowania UTF-8 dla JSON wymienianego między systemami poza zamkniętym ekosystemem. Wyjaśnia też, że ciągi JSON mogą zawierać znaki bezpośrednio lub w postaci sekwencji ucieczki. Pojawienie się sekwencji, takiej jak \u263A, nie oznacza automatycznie uszkodzenia danych; parser JSON powinien interpretować poprawne sekwencje. Jeśli JSON jest nieprawidłowy albo narzędzie do importowania zgłasza błąd parsowania, przerwij pracę i zachowaj dokładny plik, zamiast edytować znaki interpunkcyjne lub bajty na wyczucie.

Postępuj kolejno: (1) porównaj dziennik źródłowy z eksportem; (2) sprawdź duplikat przy użyciu oczekiwanego kodowania, a jeśli to właściwe, także widoku UTF-8; (3) sprawdź w innym programie, czy problem wynika z braku glifu; (4) wyświetl podgląd pliku we właściwym narzędziu do importowania CSV lub JSON; (5) jeśli emoji nadal wyświetla się poprawnie w źródle, ponów eksport z użyciem udokumentowanego kodowania tekstu. Zmieniaj tylko jedną rzecz naraz i zachowuj osobno wyniki każdej próby.

Jeśli żaden widok ani narzędzie do importowania nie ujawnia oryginalnego znaku, a plik zawiera wyłącznie znaki zastępcze lub inne zastąpione dane, nie obiecuj odzyskania przez zmianę kodowania. Zmiana ustawień odczytu nie pozwala ustalić, jakie emoji zostało usunięte. Poszukaj innego eksportu, kopii zapasowej lub nienaruszonego wpisu w dzienniku, a następnie wyeksportuj dane ponownie do nowego pliku i sprawdź jego podgląd, zanim zaczniesz na nim polegać.