OpenTag常见问题声明:
如果XML文档中没有编码声明(并且没有外部编码声明机制,例如HTTP报头),则假定XML文档的编码取决于Byte-Order-Mark (BOM)的存在。 BOM是放置在文件顶部的Unicode特殊标记,它指示其编码。BOM对于UTF-8是可选的. 假设
对上面这一段有什么含糊其辞的解释吗?
发布于 2011-06-10 06:54:06
要么你必须用类似于
<?xml version="1.0" encoding="iso-8859-1" ?>若要指定使用哪种编码,请执行以下操作。如果未指定编码,则可以出现字节顺序标记(BOM)。如果存在UTF-16或UTF-32的BOM,则使用该编码。否则,UTF-8是编码。( UTF-8的BOM是可选的)
编辑
BOM是一个看不见的角色。但没有必要去看。应用程序会自动处理它。使用windows记事本时,可以在保存文件时选择编码。记事本将在文件开始时自动插入BOM。稍后重新打开文件时,记事本将识别BOM,并使用正确的编码来读取该文件。没有必要修改BOM,如果你这样做,字符可以得到不同的含义,所以文本将不一样。
我会试着用一个例子来解释。考虑一个文本文件,其中只有字符"test“。默认记事本将使用ANSI编码,当您在十六进制模式中查看它时,文本文件将如下所示
C:\>C:\gnuwin32\bin\hexdump -C test-ansi.txt
00000000 74 65 73 74 |test|
00000004(正如您所看到的,我使用的是来自gnuwin32的十六进制,但也可以使用像弗雷德这样的十六进制编辑器来查看。
在这个文件前面没有BOM。这是不可能的,因为用于BOM的字符在ANSI编码中不存在。(由于没有BOM,不支持ANSI编码的编辑器会将此文件视为UTF-8)。
当我现在像utf8一样保存文件时,您将在“test”前面看到3个额外的字节( BOM):
C:\>C:\gnuwin32\bin\hexdump -C test-utf8.txt
00000000 ef bb bf 74 65 73 74 |test|
00000007(如果您使用不支持utf-8的文本编辑器打开该文件,您将实际看到这些字符“with”)。
记事本还可以将文件保存为unicode,这意味着UTF-16小终端(UTF-16 16):
C:\>C:\gnuwin32\bin\hexdump -C test-unicode.txt
00000000 ff fe 74 00 65 00 73 00 74 00 |ÿþt.e.s.t.|
0000000a下面是保存为unicode (大端)(UTF-16BE)的版本:
C:\>C:\gnuwin32\bin\hexdump -C test-unicode-big-endian.txt
00000000 fe ff 00 74 00 65 00 73 00 74 |þÿ.t.e.s.t|
0000000a现在考虑一个包含4个汉字"琀攀猀琀“的文本文件。当我将其保存为unicode (大端)时,结果如下所示:
C:\>C:\gnuwin32\bin\hexdump -C test2-unicode-big-endian.txt
00000000 fe ff 74 00 65 00 73 00 74 00 |þÿt.e.s.t.|
0000000a正如您所看到的,UTF-16 the中的"test“一词的存储方式与UTF-16BE中的"琀攀猀琀”一词相同。但是,由于BOM存储方式不同,您可以看到该文件是包含"test“还是"琀攀猀琀”。如果没有BOM你就得猜。
https://stackoverflow.com/questions/6302544
复制相似问题