gedit не может распознать кодировку символов, но gvim может
У меня есть много файлов простого текста, которые прибывают из среды Windows.
Многие из них используют эксцентричную кодовую страницу Windows по умолчанию, которая не является ни ASCII (7 битов), ни UTF-8.
gvim не имеет никакой проблемы при открытии этих файлов, но gedit не удается сделать так.
gvim сообщает о кодировании latin1.
Я предполагаю, что gvim делает "умное" предположение о кодовой странице.
(Я полагаю, что эта кодовая страница все еще имеет международные варианты).
Некоторые вопросы являются результатом этого:
(1). Действительно ли там некоторым путем является gedit, может быть сказан распознать эту кодовую страницу?
** NB. [Обновление] Для этой точки (1), см. мой ответ, ниже.
** Для точек (2) и (3). см. ответ Oli.(2). Существует ли способ просканировать файловую систему для идентификации этих проблемных файлов?
(3). Существует ли инструмент преобразования пакета для преобразования этих файлов в UTF-8?
(.. этот старосветский текстовый погром был на самом деле последней каплей, которая принесла мне к Ubuntu... UTF-8 в масштабе всей системы по умолчанию Brilliant)
[ОБНОВЛЕНИЕ]
** NB: ** я теперь полагаю, что следующее Обновление частично не важно, потому что "проблемные" файлы не являются "проблемой" (см. мой ответ ниже).
Я оставил его здесь, потому что, может иметь некоторое общее применение для кого-то.
Я разработал грубый и готовый способ определить проблемные файлы...
file команда не подходила, потому что она идентифицировала мой файл в качестве примера как ASCII..., но ASCII-файлом является 100%-й совместимый UTF-8...
Как я упомянул в комментарии ниже, тест для недопустимого первого байта кодовой точки UTF-8:
- если первый байт (кодовой точки UTF-8) между 0x80 и 0xBF (зарезервирован для дополнительных байтов), или больше, чем 0xF7 ("слишком долгая форма"), который считают ошибкой
Я знаю sed (немного, через порт Win32), таким образом, мне удалось починить шаблон RegEx, который находит эти незаконные байты.
Это - ужасная строка, поэтому отведите взгляд теперь, если регулярные выражения пугают Вас :)
Я был бы очень признателен, если кто-то указывает, как использовать шестнадцатеричные значения в диапазоне [] выражение.. Я только что использовал или оператор \|
fqfn="/my/fully/qualified/filename"
sed -n "/\x80\|\x81\|\x82\|\x83\|\x84\|\x85\|\x86\|\x87\|\x88\|\x89\|\x8A\|\x8B\|\x8C\|\x8D\|\x8E\|\x8F\|\x90\|\x91\|\x92\|\x93\|\x94\|\x95\|\x96\|\x97\|\x98\|\x99\|\x9A\|\x9B\|\x9C\|\x9D\|\x9E\|\x9F\|\xA0\|\xA1\|\xA2\|\xA3\|\xA4\|\xA5\|\xA6\|\xA7\|\xA8\|\xA9\|\xAA\|\xAB\|\xAC\|\xAD\|\xAE\|\xAF\|\xB0\|\xB1\|\xB2\|\xB3\|\xB4\|\xB5\|\xB6\|\xB7\|\xB8\|\xB9\|\xBA\|\xBB\|\xBC\|\xBD\|\xBE\|\xBF\|\xF8\|\xF9\|\xFA\|\xFB\|\xFC\|\xFD\|\xFE\|\xFF/p" "${fqfn}"
Так, я теперь привью это в пакетное решение Oli... Спасибо Oli!
PS. Вот недопустимый байт UTF-8, который это нашло в моем файле примера...
"H.Bork, Gøte-borg".... "ø" = F8 преобразовывают в шестнадцатеричную систему..., который является недопустимым символом UTF-8.
4 ответа
iconv - это, вероятно, то, что вы захотите использовать. iconv -l покажет вам доступные кодировки, а затем вы можете использовать пару команд для их перекодирования:
# all text files are in ./originals/
# new files will be written to ./newversions/
mkdir -p newversions
cd originals
for file in *.txt; do
cat $file | iconv -f ASCII -t utf-8 > ../newversions/$file;
done
Если вы хотите сделать это с файлами, кодирование которых вы не выполняете (потому что они повсюду), вы хотите ввести еще несколько команд: find, file, awk и sed. Последние два просто для обработки вывода файла.
for file in find . -type f -exec file --mime {} \; | grep "ascii" | awk '{print $1}' | sed s/.$//; do
...
Я понятия не имею, работает ли это на самом деле, поэтому я, конечно, не запустил бы его из ничего, кроме наименее важного каталога, который у вас есть (создайте папку для тестирования с некоторыми известными файлами ASCII). Синтаксис find может помешать ему находиться внутри цикла for. Я надеюсь, что кто-то еще с большим опытом работы в bash может подключиться и разобраться, чтобы он поступил правильно.
Я думал об этом немного больше ...
Да, "ø" = 0xF8 hex * определенно была причиной, по которой gedit не открывал файл. ..
Зачем? Потому что это недопустимый байт UTF-8.
По умолчанию gedit будет открывать только файлы UTF-8 ...
Однако, gedit имеет функцию автоопределения кодовой страницы, но вы должны сначала ] Добавьте кодовые страницы в список «возможных».
Ярко-красный диалог, который появляется, когда gedit не может распознать кодовую страницу, содержит кнопку, которая позволяет добавить другую кодовую страницу ...
Проблема решена! ... почти ...
Теперь проблема снова подняла голову ... Какая это кодовая страница?
В моей ситуации я могу разумно предположить, что это стандартная английская кодовая страница Windows (для моего региона? Или для региона происхождения файла? .. Я упомянул «knarly»:) ... .
В любом случае, gedit позволит вам загрузить файл, как только вы добавили кодовую страницу в свой список ...
Итак, хотя все команды Терминала сами по себе полезны и интересны, кажется, что это направление мысли движется в неверном направлении.
В этих файлах нет ничего по сути неправильного ...
Проблема, похоже, касается исключительно кодовых страниц.
gedit может открыть файл, как gvim .
... но соответствующая кодовая страница должна быть сначала добавлена в список кодовых страниц.
например. через диалог открытия файла или красный диалог предупреждения, с которым я столкнулся.
Вы можете использовать любую из 3 командных строк:
gedit --encoding=utf-8 filename
gedit --encoding=iso-8859-15 filename
gedit --encoding=utf-16 filename
. . . . .
Gedit может определить правильный набор символов, только если он указан в «File-Open-Character Encoding» Вы можете изменить этот список, но имейте в виду, что порядок важен.