Проблема преобразования набора символов - отладка недопустимых символов - обратный инжиниринг предыдущих преобразований - PullRequest
0 голосов
/ 19 января 2019

Проблема преобразования символов. У меня есть несколько строк, которые неправильно закодированы или декодированы. Строки пришли в CSV-файле формата ASCII.

У меня есть следующие строки:

N‚met
Tet‹

Я знаю, что:

"‚" character (0x82) should be originally "é" (é acute accent)
"‹" character (0x8B) should be originally "ő" (o double acute accent)

Как я могу отладить и перепроектировать, какие преобразования произошли с исходными символами, чтобы получить текущие символы?

Я предполагаю, что произошло многократное декодирование, но я не смог воспроизвести исходный символ.

Ответы [ 2 ]

0 голосов
/ 22 января 2019

Я написал свою собственную утилиту, которая помогла мне диагностировать и исправить многие острые проблемы кодирования.Он доступен как часть библиотеки с открытым исходным кодом.Утилита преобразует любую строку в последовательность Unicode и наоборот.Все, что вам нужно сделать, это:

String codes = StringUnicodeEncoderDecoder.encodeStringToUnicodeSequence("Hello world");

И он вернет строку "\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064"

То же самое будет работать для любой строки в любом языке, включая специальные символы.Вот ссылка на статью Java-библиотека с открытым исходным кодом с фильтрацией трассировки стека, конвертер Unicode для анализа Silent String и сравнение версий , в котором объясняется, что такое библиотека и где ее можно получить (доступно как в Maven central и github . В статье ищите абзац: «String Unicode converter» .

Поэтому, когда вы читаете вашу String, преобразуйте ее и посмотрите, что произойдет. Таким образом, выувидит, какие символы есть, и если информация верна и искажена только неправильной кодировкой или сама информация потеряна. Вы можете легко найти информацию в Интернете, которая предоставляет таблицы сопоставления любого символа с юникодом

0 голосов
/ 22 января 2019

Я добавил расширенную версию моего комментария в качестве ответа:

Ваш зритель использует CP1252 (английский и Западная Европа, также называемый ANSI в Windows) или CP1250 (Восточная Европа) или другую подобную кодовую страницу. Большинство символов закодированы одинаково, только несколько изменений для конкретного языка. Ваш пример не включает символы, которые отличаются в двух кодировках, поэтому я не могу сказать точно.

Эти кодовые страницы используются в Microsoft Windows, и они основаны (но не на 100% совместимы) с Latin-1, поэтому часто можно увидеть текст, интерпретируемый с такой кодировкой. MacO и Linux сильно (сейчас) кодируются в UTF-8. Windows использует Юникод внутри (но UTF-16)

Старая кодировка, вероятно, CP437: стандартная кодовая страница в DOS, поэтому она часто использовалась также для файлов CSV. Другие часто используемые старые кодировки - CP850 (Западная Европа) и CP852 (Центральная Европа).

Что касается других ответов, которые вы добавляете в комментарии, я думаю, вам следует перейти к Superuser (если вы запрашиваете инструменты (некоторые редакторы позволяют указывать кодировку. Вы можете использовать браузер (открывая локальный файл): браузеры также позволяют выбрать локальную кодировку, и я думаю, что вы можете копировать как Unicode [не уверен], другие инструменты иногда имеют скрытую опцию для импорта файлов, но, возможно, не со всеми параметрами), или как новый вопрос на этом сайте, если вы хотите сделать это программно. Но поэтому вам необходимо указать язык. Python хорошо подходит для таких преобразований (большинство языков сценариев создаются для обработки текстов): в python встроено множество кодировок, вы должны просто указать при чтении и при написании файлы. R также может быть указан на входной кодировке.

...