gedit 无法识别字符编码,但 gvim 可以

gedit 无法识别字符编码,但 gvim 可以

我有很多来自 Windows 环境的纯文本文件。
其中许多文件使用奇怪的默认 Windows 代码页,既不是 ASCII(7 位),也不是 UTF-8。

格维姆打开这些文件没有问题,但是编辑未能这样做。
格维姆报告编码为拉丁语1

我认为格维姆正在对代码页做出“智能”假设。
(我相信这个代码页仍然具有国际变体)。

由此产生了一些问题:

  • (1)有没有办法编辑可以告知识别该代码页吗?
    **注意:[更新] 关于这一点(1),请参阅我的答案如下。
    ** 对于第 (2) 点和第 (3) 点,请参阅 Oli 的回答。

  • (2). 有没有办法扫描文件系统来识别这些问题文件?

  • (3). 有没有批量转换工具可以把这些文件转换成UTF-8?

(...这个旧世界的文本混乱实际上是压死我的最后一根稻草,让我转向 Ubuntu...默认情况下整个系统都是 UTF-8杰出的

[更新]
**注意:**我现在认为以下更新部分不相关,因为“问题”文件不是“问题”(见我的答案如下)。
我把它留在这里,因为它可能对某些人有用。


我已经找到了一种粗略的方法来识别问题文件...
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!

附言:这是在我的示例文件中找到的无效 UTF-8 字节...
“H.Bork,哥德堡。” ... 这“ø”=F8 十六进制...这是一个无效的 UTF-8 字符。

答案1

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

如果你想对不知道其编码的文件执行此操作(因为它们到处都是),你需要引入更多命令:findfile和。最后两个只是用来处理文件的输出。awksed

for file in find . -type f -exec file --mime {} \; | grep "ascii" | awk '{print $1}' | sed s/.$//; do
    ...

我不知道这是否真的有效,所以我肯定不会从任何目录运行它,除了你最不重要的目录(创建一个包含一些已知 ASCII 文件的测试文件夹)。 find 的语法可能会阻止它进入 for 循环。我希望其他拥有更多 bash 经验的人可以介入并解决它,以便它做正确的事情。

答案2

仅当“文件-打开-字符编码”中列出了正确的字符集时,Gedit 才能检测到正确的字符集。您可以更改此列表,但请记住顺序很重要。

答案3

您可以使用以下 3 个命令行中的任意一个:

gedit --encoding=utf-8 filename
gedit --encoding=iso-8859-15 filename
gedit --encoding=utf-16 filename
. . . . .

答案4

我对此想了一会儿……

是的,“ø”= 0xF8 hex* 绝对是原因编辑无法打开文件...
为什么?因为它不是有效的 UTF-8 字节。
默认情况下,编辑只能打开 UTF-8 文件...

然而,编辑确实具有代码页自动检测功能,但您必须先添加代码页添加到其“可能”列表中。

当出现编辑无法识别代码页,上面有一个按钮,可以让你添加另一个代码页...

问题解决了!...几乎...

这个棘手的问题现在再次出现......它是哪个代码页?

就我的情况而言,我可以合理地假设它是标准的英语 Windows 代码页(对于我的地区?还是对于文件来源的地区?.. 我确实提到了“knarly”:)....

无论如何,编辑允许您加载文件添加代码页到其列表...

因此,尽管所有终端命令本身都是有用且有趣的,但这种思路似乎走向了错误的轨道。

没有什么本质上错误的在这些文件中...
问题似乎纯粹与代码页有关。

编辑可以打开文件,就像格维姆能。
但必须先添加到其代码页列表。
例如通过文件打开对话框,或者我遇到的红色警告对话框。

相关内容