我记得我过去在日本开发网站时--在日本有三种不同的字符编码--开发人员有一个诀窍,要“强制”对源文件进行编码,这样它就会在IDE中以正确的编码方式打开。
他们所做的是在文件的顶部加上一个只存在于特定字符编码中的日文字符的注释--它不在任何其他字符中!这件事很好用。
我记得这一点,因为我现在有一个类似的问题,尽管是英语,问题。
我有一些文件必须是ISO-8859-1,但在我的编辑器(Linux上的Bluefish 1.0.7 )中继续打开UTF-8。这通常不是一个问题,除了英镑(‘t)符号和诸如此类。不要误解我的意思,我可以修复这个文件并将其保存为ISO-8859-1,但我希望它在我的编辑器中始终以ISO-8859-1的形式打开。
那么,有没有像我上面提到的那样的角色黑客来这么做呢?或者其他方法?
PS。Unicode倡导者/传道者不必浪费他们的时间试图改变我,因为我已经是他们中的一员了!这是我继承的一个摇摇欲坠的旧系统
PPS。请不要说“使用不同的编辑器”,因为我是一个老屁,设置在我的方式:-)
发布于 2010-07-09 17:16:07
通常情况下,如果您的£编码为ISO8859-1(即.一个单独的字节0xA3),这不会构成一个有效的UTF-8字节序列的一部分,除非你运气不好,它紧跟在另一个顶级设置字符之后,使它们作为UTF-8序列一起工作。(您可以通过在文件顶部单独放置一个£来防范这种情况。)
因此,任何编辑器都不应该打开任何像UTF-8这样的文件;如果这样做了,它就会完全失去£。如果您的编辑器这样做,“使用不同的编辑器”-seriously!如果您的问题是编辑器将不包含£或任何其他非ASCII字符的文件加载为UTF-8,导致添加到它们中的任何新£随后被保存为UTF-8,那么简单地将一个£字符单独添加到文件的顶部肯定会停止这一点。
您不能做的是让编辑器将其加载为ISO-8859-1,而不是所有单个顶位集字节都有效的任何其他字符集。只有UTF-8和Shift-JIS这样的多字节编码才能通过使用对这种编码无效的字节序列来排除它们。
在Windows上通常会发生的情况是,编辑器将使用系统默认代码页加载文件,通常是1252在西方机器上。(实际上与ISO-8859-1不太一样,但很接近。)
有些编辑器有一个功能,您可以提示他们在第一行注释中使用什么编码,例如。对于vim:
# vim: set fileencoding=iso-8859-1 :不同的编辑器/配置的语法会有所不同。但通常都很难看。其他控件可能会在目录基础上更改默认编码,但由于我们不知道您使用的是什么.
从长远来看,存储为ISO-8859-1或任何其他不是UTF-8的编码的文件当然需要离开并死去。:-)
发布于 2010-07-09 17:18:59
您可以将字符ÿ (0xFF)放入文件中。它在UTF8中无效。Mac上的BBEdit正确地将其识别为ISO8859-1.不知道你选择的编辑会怎么做。
https://stackoverflow.com/questions/3214830
复制相似问题