gedit无法识别字符编码，但gvim可以
我有很多来自Windows环境的纯文本文件。
他们中的许多人使用了一个糟糕的默认Windows代码页，既不是ASCII（7位）也不是UTF-8。
gvim打开这些文件没有问题，但是gedit没有这样做。
gvim将编码报告为latin1 。
我假设gvim正在对代码页做出“聪明”的假设。
（我相信这个代码页仍然有国际变体 ）。
由此产生的一些问题：
-
（1）。 有没有什么方法可以告诉gedit识别这个代码页？
** NB。 [更新]关于这一点（1），请参阅下面的答案。
**对于第（2）和（3）点。 看到奥利的回答。 -
（2）。 有没有办法扫描文件系统来识别这些问题文件？
-
（3）。 是否有批量转换工具将这些文件转换为UTF-8？
（..这个旧世界的文字混乱实际上是最后一根稻草，它把我带到了Ubuntu …… UTF-8系统默认为Brilliant ）
[UPDATE]
** 注意： ** 我现在认为以下更新部分无关紧要，因为“问题”文件不是“问题”（请参阅下面的答案）。
我把它留在这里，因为它可能对某人有一些普遍的用处。
我已经找到了一个粗略的，准备好的方法来识别问题文件……
file命令不合适，因为它将我的示例文件标识为ASCII …但是ASCII文件是100％符合UTF-8的…
正如我在下面的评论中提到的，对UTF-8代码点的无效第一个字节的测试是：
- 如果（UTF-8代码点的第一个字节）介于0x80和0xBF之间（保留用于附加字节），或大于0xF7（“超长forms”），则认为是错误
我知道sed （有点，通过Win32端口），所以我设法凑齐了一个RegEx模式，找到了这些令人讨厌的字节。
这是一个丑陋的线，所以如果正则表达式吓到你，请立即离开:)
如果有人指出如何在范围[]表达式中使用hex值，我真的很感激..我刚刚使用了或者运算符\ |
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 hex …这是一个无效的UTF-8字符。
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经验的人可以跳到那里然后把它整理出去，这样它就做对了。
只有在“文件 – 打开 – 字符编码”中列出时，Gedit才能检测到正确的字符集。 您可以更改此列表，但请记住订单很重要。
我一直在想这个……
是的，“ø”= 0xF8 hex *绝对是gedit无法打开文件的原因……
为什么？ 因为它不是有效的UTF-8字节。
默认情况下， gedit只会打开UTF-8文件…
但是， gedit确实具有代码页自动检测function，但您必须首先将代码页添加到其“可能”列表中。
当gedit无法识别代码页时出现的亮红色对话框，上面有一个buttone，允许你添加另一个代码页……
问题解决了…… 几乎 ……
这个棘手的问题现在再次抬头……它是哪个代码页？
在我的情况下，我可以肯定地认为它是标准的英文Windows代码页（对于我的地区？，或者对于文件来源的区域？我确实提到了“knarly”:) ….
无论如何，一旦你将代码页添加到其列表中， gedit将允许你加载文件…
因此，尽管所有终端命令本身都是有用且有趣的，但似乎这种思路正朝着错误的轨道前进。
这些文件没有任何内在错误 ……
问题似乎纯粹是关于代码页。
gedit可以打开文件，就像gvim一样 。
…但必须首先将相关代码页添加到其代码页列表中。
例如。 通过文件打开对话框，或我遇到的红色警告对话框。
您可以使用以下3个命令行中的任何一个：
gedit --encoding=utf-8 filename gedit --encoding=iso-8859-15 filename gedit --encoding=utf-16 filename . . . . .