#utf-8 #windows-1252 #codepage-437
#utf-8 #windows-1252 #кодовая страница-437
Вопрос:
Вот что я сделал:
- Я сбросил базу данных SQLite с данными UTF-8 (
sqlite3 example.db .dump > dump.sql
), но поскольку это было в powershell, я предполагаю, что конвейер преобразовал ее в Windows-1252 - Я загрузил эти сброшенные данные в новую базу данных, снова используя powershell (
Get-Content dump.sql | sqlite3 example2.db
) - Я сбросил эту новую базу данных и остался с новым
.sql
файлом (на этот раз это было не через powershell, поэтому я предполагаю, что он не был изменен)
Символы UTF-8 в этом новом файле sql серьезно искажены, и мне было интересно, есть ли способ преобразовать его обратно в правильный UTF-8.
В качестве нескольких примеров, вот какие последовательности есть в новом файле, и какими они должны быть (все рассматриваются как UTF-8):
ÒüéÒü¬ÒüƒÒü½
должно бытьあなたに
´╝ü
должен быть восклицательный знак во всю ширинуÒé¡Òé╗Òé¡
должно бытьキセキ
Есть ли у кого-нибудь идеи относительно того, как я мог бы отменить это искажение? Любой метод был бы очень полезен!
Это в 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 устранили мою проблему!