Как диагностировать поврежденные эмодзи в экспортированном файле дневника

Определите, как именно выглядят «поврежденные» символы

Внимательно изучите одну проблемную запись. Строка неожиданных символов, таких как `😀` на месте 😀, может указывать на то, что байты UTF-8 были интерпретированы с использованием другой кодировки. Это явление обычно называют «кракозябрами» (модзибакэ): отображаемые символы неверны, поскольку байты были декодированы при неправильных предположениях. Это подсказка, а не доказательство того, какая именно кодировка использовалась при создании файла.

Отображение символа `` — это другой случай. Это U+FFFD, символ замены в Unicode, используемый вместо символа, который не удается интерпретировать. В [глоссарии](https://www.unicode.org/glossary/#replacement_character) Unicode он отличается от замещающего глифа: шрифт или модуль рендеринга может отображать пустой прямоугольник, если не может нарисовать символ, в то время как сам символ в данных может оставаться неповрежденным. Если в виде прямоугольников отображаются лишь некоторые эмодзи, проверьте файл в другом современном приложении или с другим шрифтом, прежде чем менять кодировку файла.

Сохраните исходную копию перед устранением неполадок

Сделайте копию экспортированного файла и оставьте оригинал без изменений. Зафиксируйте расширение файла, приложение, из которого он был экспортирован, и то, как именно выглядит одна из проблемных фраз. По возможности сравните известный эмодзи из дневника с той же записью в исходном приложении или в предыдущем экспорте. Избегайте многократного открытия и сохранения единственной копии: текстовый редактор может записать заново декодированный текст обратно в виде байтов, превратив обратимый эксперимент с отображением в постоянное повреждение.

Откройте копию как обычный текст в редакторе, позволяющем выбирать кодировку. Сначала попробуйте кодировку, указанную в документации приложения дневника; если она неизвестна, а файл представляет собой типичный современный текстовый экспорт, UTF-8 является разумным кандидатом для проверки, но не поводом сразу перезаписывать оригинал. Сравните проблемный текст и окружающие обычные символы для каждого варианта кодировки. Согласованный результат по всему файлу является более надежным доказательством, чем один случайно отобразившийся корректно эмодзи.

Проверяйте декодирование без перезаписи файла

Если изменение кодировки просмотра в редакторе превращает странную последовательность в ожидаемый эмодзи, а окружающий текст также становится читаемым, экспорт может содержать неповрежденные байты, которые ранее были интерпретированы неверно. Подтвердите это, закрыв копию без сохранения и снова открыв ее с подходящей настройкой. Затем проверьте, предлагает ли процесс импорта или открытия в приложении дневника документированный выбор кодировки; для фактического повторного импорта отдавайте предпочтение именно этому встроенному процессу.

В [Unicode UTF FAQ](https://www.unicode.org/faq/utf_bom.html) объясняется, что некорректные последовательности байтов UTF-8 могут вызывать ошибку или заменяться специальным маркером, таким как U+FFFD. Это означает, что декодер мог уже заменить недопустимые входные данные при отображении или импорте. Смена кодировки после этого шага не обязательно восстановит исходные байты. Не используйте функции «исправления» или параметры конвертации, которые автоматически заменяют недекодируемые символы, работая с единственной копией файла.

Отделяйте проблемы с кодировкой от отсутствующих глифов

Если эмодзи корректно отображается в другой программе просмотра, сохраните этот результат сравнения как подтверждение, прежде чем вносить изменения в файл. Избегайте перезаписи экспортированного файла только ради изменения его внешнего вида.

Если на одной и той же позиции во всех программах просмотра отображается U+FFFD или обычный вопросительный знак, выполните сравнение с исходным дневником или более ранним экспортом. Символ-заменитель, уже сохраненный в файле, невозможно восстановить сменой шрифта. Восстановление зависит от наличия другой копии, в которой символ сохранился.

Используйте разные способы импорта для CSV и JSON

Расширение `.csv` не указывает, какая кодировка символов использовалась, а программы для работы с электронными таблицами могут применять собственные параметры импорта. Для классического приложения Excel компания Microsoft описывает импорт текста через меню **Данные > Из текстового/CSV-файла** и Мастер импорта текста в своем [руководстве по импорту и экспорту текстовых файлов и CSV](https://support.microsoft.com/en-us/excel/get-started/import-or-export-text-txt-or-csv-files). Используйте предварительный просмотр перед загрузкой: проверьте эмодзи, границы строк и столбцов, а также соседний текст. Корректный предварительный просмотр подтверждает, что выбранный способ импорта считывает файл правильно; это не повод перезаписывать исходный файл.

Для JSON сохраните исходный файл и используйте специализированный модуль импорта JSON, а не обрабатывайте его как CSV. [Спецификация JSON RFC 8259](https://www.rfc-editor.org/rfc/rfc8259#section-8.1) требует использования UTF-8 для данных JSON, передаваемых между системами вне закрытой экосистемы. В ней также объясняется, что строки JSON могут представлять символы напрямую или с помощью escape-последовательностей. Наличие escape-последовательности, такой как `\\u263A`, не является признаком повреждения данных; парсер JSON должен корректно интерпретировать допустимые последовательности. Если файл JSON недействителен или модуль импорта сообщает об ошибке синтаксического анализа, остановитесь и сохраните точный файл, вместо того чтобы наугад редактировать знаки препинания или байты.

Определите дальнейшие действия: повторить попытку, экспортировать заново или остановиться

Следуйте этой последовательности: (1) сравните исходный дневник с экспортом; (2) проверьте дубликат, используя ожидаемую кодировку и, при необходимости, кодировку UTF-8; (3) проверьте файл в другой программе просмотра на предмет отсутствующих глифов; (4) выполните предварительный просмотр файла через правильный модуль импорта CSV или JSON; и (5) повторите экспорт с документированной кодировкой текста, если в источнике эмодзи по-прежнему отображаются корректно. Изменяйте только один параметр за раз и фиксируйте каждый результат отдельно.

Если ни одна программа просмотра или модуль импорта не показывают исходный символ, а файл содержит только символы замены или другие подставленные данные, не рассчитывайте на восстановление путем изменения кодировки. Изменение параметров декодирования не может определить, какой именно эмодзи был утрачен. Найдите другой экспорт, резервную копию или неповрежденную запись в дневнике, затем выполните экспорт заново в новый файл и обязательно проверьте его предварительный просмотр, прежде чем использовать в дальнейшем.

Продолжить изучение темы