Преобразование искаженных символов обратно в UTF-8

#utf-8 #windows-1252 #codepage-437

#utf-8 #windows-1252 #кодовая страница-437

Вопрос:

Вот что я сделал:

  1. Я сбросил базу данных SQLite с данными UTF-8 ( sqlite3 example.db .dump > dump.sql ), но поскольку это было в powershell, я предполагаю, что конвейер преобразовал ее в Windows-1252
  2. Я загрузил эти сброшенные данные в новую базу данных, снова используя powershell ( Get-Content dump.sql | sqlite3 example2.db )
  3. Я сбросил эту новую базу данных и остался с новым .sql файлом (на этот раз это было не через powershell, поэтому я предполагаю, что он не был изменен)

Символы UTF-8 в этом новом файле sql серьезно искажены, и мне было интересно, есть ли способ преобразовать его обратно в правильный UTF-8.

В качестве нескольких примеров, вот какие последовательности есть в новом файле, и какими они должны быть (все рассматриваются как UTF-8):

  1. ÒüéÒü¬ÒüƒÒü½ должно быть あなたに
  2. ´╝ü должен быть восклицательный знак во всю ширину
  3. Òé¡Òé╗Òé¡ должно быть キセキ

Есть ли у кого-нибудь идеи относительно того, как я мог бы отменить это искажение? Любой метод был бы очень полезен!

Это в powershell 7.0.1

Редактировать:

При дальнейшей проверке вы можете повторить мое затруднительное положение, перенаправив любые такие данные в файл в powershell (обратите внимание, что сами данные не могут быть введены в powershell). Следовательно, настройка подобного сценария дает тот же результат:

test.sh

 #!/bin/bash
echo "キ"
  

И затем запуск wsl ./test.sh > test.txt выдаст результат Òé¡ , а не

Редактировать 2:

Похоже, что кодовая страница, в которую был преобразован текст UTF-8, почти равна 437: некоторые символы восстанавливаются с использованием этого предположения (например, ), но другие нет. Если это близко к 437, но это не так, что бы это могло быть?

Ответ №1:

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