Данные и таблицы · CSV Очиститель
Как UTF-8 и Windows-1252 путаются: восстановление экспорта Mojibake CSV
· Как это работает
csv кодирование очистка данных
Когда «Хосе» становится «Хосе», байты в порядке, а интерпретация неверна. В этом посте объясняется, как сталкиваются две наиболее распространенные кодировки, как распознать симптомы и как их исправить с помощью повторного декодирования.
Имена с акцентом и фигурные кавычки превратились в суп из символов — характерные шаблоны файла UTF-8, читаемого как Windows-1252, и наоборот.
Имя клиента, которое после загрузки становится заменяющим ромбом, не является свидетельством того, что CSV Cleaner обнаружил неверную устаревшую кодовую страницу. В конфигурации написано обратное: понимается только UTF-8, а файл Windows-1252 или Shift-JIS читается как UTF-8. Таким образом, недопустимые последовательности байтов могут быть заменены еще до того, как анализатор CSV увидит символы.
В центре контура находится знакомый моджибаке, такой как Хосе, но путь чтения браузера использует `File.text()` и не предоставляет переключателя кодировки. Данная статья исправляет это обещание. Действенным симптомом этого инструмента является замена символов или иным образом поврежденный текст, при этом исходные байты файла сохраняются для восстановления в другом месте.
Файл, отличный от UTF-8, попадает в этот инструмент как символы замены, а не как проверенный шаблон моджибаке.
Файл с разделителями — это байты на диске, а парсер работает со строкой JavaScript. Кодировка определяет сопоставление между этими слоями. Синтаксис CSV именует запятые, кавычки и границы записей, но не содержит надежного объявления на диске, сообщающего `File.text()`, какое устаревшее сопоставление создало каждый байт, не относящийся к ASCII.
После того как при декодировании были созданы символы замены U+FFFD, последующие операции CSV получают эти заполнители как обычный текст. Обрезка или экспорт не позволяют определить, какая исходная последовательность байтов или символ там принадлежала. Вот почему нетронутый источник имеет большее значение, чем список поиска и замены, составленный на основе поврежденного дисплея.
Два обычных подозреваемых — многобайтовые последовательности UTF-8 и одиночные байты Windows-1252, и почему они создают предсказуемый мусор при замене
UTF-8 представляет символы, отличные от ASCII, с многобайтовыми последовательностями. Windows-1252 присваивает отдельным значениям байтов множество западных символов. Чтение одного соглашения под другим может привести к сбою или созданию вводящего в заблуждение текста, но этот путь не проверяет альтернативные декодеры, не оценивает правдоподобный язык и не предлагает выбор Windows-1252.
Единственное поведение синтаксического анализатора, специфичное для кодировки, — это удаление лидирующего знака порядка байтов U+FEFF UTF-8 после декодирования текста. Это предотвращает присоединение маркера к первому заголовку. Это не общее обнаружение кодировки и не обеспечивает поддержку Shift-JIS, UTF-16 или региональных кодовых страниц, нигде не упомянутых в реализации.
ToolAcre принимает текст UTF-8 и не сравнивает кандидатов Windows-1252
Символы замены указывают на то, что декодер текста не смог отобразить некоторые входные байты согласно выбранной интерпретации. Вопросительные знаки могли быть вставлены при более раннем экспорте с потерями, и в этом случае исходный символ уже мог быть недоступен. Узнаваемая последовательность Ã может возникнуть в других рабочих процессах, но на этой странице не диагностируется ее история.
Не стоит определять исходную кодировку только по одной фамилии. Проверьте настройки экспортирующего приложения, происхождение файла и байтовый инспектор, который оставляет источник нетронутым. Предупреждения строки очистителя касаются закрытия кавычек и ширины столбца; они не являются доказательством правильности кодировки символов.
Повторное декодирование, а не поиск и замена — почему исправление состоит в том, чтобы читать байты с правильной кодировкой и записывать UTF-8, а не исправлять символы один за другим
Надежный способ восстановления — вернуться к исходным байтам и один раз декодировать их с помощью документированной исходной кодировки, а затем записать UTF-8. Эта операция должна произойти перед открытием текстового пути, содержащего только UTF-8. Замена видимых фрагментов мусора после декодирования может испортить допустимые вхождения и не позволит различить несколько исходных символов, свернувшихся в один заполнитель.
CSV Cleaner не имеет контроля перекодирования на уровне байтов, поэтому он не может выполнить обещанное преобразование структуры. Используйте надежный метод преобразования с учетом источника, сравните репрезентативные имена с исходной системой, а затем перенесите сюда результат UTF-8 для разделителей, кавычек, пробелов и дублирования.
Восстановление исходных байтов за пределами этого инструмента; замена персонажей здесь не может их восстановить
Для безопасной демонстрации создайте небольшой файл в устаревшей кодировке, содержащий одно имя с диакритическими знаками, и сохраните шестнадцатеричную копию. Загрузите его в инструмент и посмотрите, появятся ли символы замены. Это наблюдение устанавливает границу UTF-8; он не устанавливает исходную кодовую страницу только потому, что известно ожидаемое имя.
Затем преобразуйте нетронутые байты с помощью явно выбранного декодера за пределами ToolAcre, сохраните UTF-8 и загрузите результат. Теперь имя должно прийти неповрежденным, а синтаксический анализатор CSV нормально обрабатывает разделители. Сравнение этих двух путей дает правильный урок, не утверждая, что уборщик сам выполнил восстановление.
Рабочий пример: продемонстрируйте границу UTF-8, не заявляя о неподдерживаемом ремонте.
Файл с двойным кодированием может потребовать восстановления более раннего преобразования, а данные, уже сохраненные с буквальными вопросительными знаками, могут быть невозможны без другого источника. В этой статье не предписывается универсальное обращение, поскольку реализация не содержит истории кодирования или функции восстановления с сохранением байтов.
Он также избегает заявлений о поддержке UTF-16, восточноазиатских кодировок или форм нормализации. Если это имеет значение, выберите преобразователь, который дает им имена и тестирует. Успешный анализ CSV только подтверждает, что конечный автомат-разделитель обнаружил строки; он ничего не говорит о том, было ли декодирование символов до этого этапа точным.
Исправьте интерпретацию один раз — как ToolAcre CSV Cleaner перекодирует и перекодирует экспорт на вашем устройстве.
ToolAcre может удалить ведущий UTF-8 BOM и сериализовать полученную строку как UTF-8 CSV через путь загрузки браузера. Он не может превратить произвольные устаревшие байты в правильный Unicode, поскольку эти байты уже пересекли фиксированную границу чтения текста браузера без декодера, выбранного пользователем.
Относитесь к знакам замены как к стоп-сигналу. Сохраните исходный код, определите его кодировку у производителя, один раз преобразуйте с помощью подходящего инструмента, поддерживающего байты, и проверьте важные имена. Только после этого используйте CSV Cleaner для структурных работ, которые фактически обещает его конфигурация.