DOM方式解析XML的时候encoding属性的作用

您所在的位置:网站首页 utf-8有bom和无bom DOM方式解析XML的时候encoding属性的作用

DOM方式解析XML的时候encoding属性的作用

2023-09-30 00:58| 来源: 网络整理| 查看: 265

一起养成写作习惯!这是我参与「掘金日新计划 · 4 月更文挑战」的第27天,点击查看活动详情。

1.规定

W3C定义了三条XML解析器如何正确读取XML文件的编码的规则:

如果文本文件头部有BOM(Byte Order Mark),即字节顺序标记(它是在Unicode编码标准中用于标识文件是采用哪种格式的编码),就按照BOM来。 如果没有BOM,就查看XML声明的编码属性。 如果上述两个都没有,就假定XML文档采用UTF-8编码。

也就是说XML解析器首先根据文件的BOM来解析文件;如果没找到BOM,由用XML里的encoding属性指定的编码;如果xml里encoding没指定的话,就默认用utf-8来解析文档。然后又可以推出,BOM和ENCODING都有的话,则以BOM指定的为准。

2实际DOM解析的时候或者是浏览器解析XML的规则

但是对于DOM(这里以Dom4j为例)解析的时候或者是浏览器解析XML的时候,会省略第一步(本人亲自尝试,例子如下所示),直接就查看XML声明的编码属性,然后用其声明的方式进行解码。如果没有在xml中声明编码方式,就假定XML文档采用UTF-8编码。

关于识别XML的理解:因为无论是哪种编码都是兼容ASCII的,所以XML解析器能够正常读取xml的头部声明,然后在读取xml声明中的encoding,向解析器说明以哪种编码方式解析ascii之外的字符,如果未找到xml头部声明或头部声明中没有encoding属性,则默认为utf-8编码。

2.1如果出现以下几种情况XML解析将会出错:(用上述规则进行分析)

一.编码格式为UTF-8(无BOM),xml声明为encoding="GBK" 在这里插入图片描述 Dom4j解析出现乱码: 在这里插入图片描述

二.编码格式为UTF-8(有BOM),xml声明为encoding="GBK" 在这里插入图片描述

Dom4j解析也出现乱码:

在这里插入图片描述

三.编码格式为GB2312(GBK包含了GB2312),xml声明为encoding="UTF-8" 在这里插入图片描述

Dom4j解析时直接报错: 在这里插入图片描述

四.编码格式为GB2312(GBK包含了GB2312),xml声明中无encoding" 在这里插入图片描述 Dom4j解析时直接报错(因为没指定默认为UTF-8): 在这里插入图片描述

2.2出现如下几种情况正常解析

五.编码格式为GB2312(GBK包含了GB2312),xml声明为encoding="GBK" 在这里插入图片描述

Dom4j正常解析XML:

在这里插入图片描述

六.编码格式为UTF-8(有无BOM都可以),xml声明为encoding="GBK" 在这里插入图片描述

Dom4j正常解析XML:

在这里插入图片描述

七.编码格式为UTF-8(有无BOM都可以),xml声明中无encoding" 在这里插入图片描述

Dom4j正常解析XML(因为没指定默认为UTF-8):

在这里插入图片描述

八.编码格式为UTF-8(有无BOM都可以),无xml声明" 在这里插入图片描述

Dom4j正常解析XML(因为没指定默认为UTF-8): 在这里插入图片描述

3.Dom4j解析中的编码

在Dom4j把XML解析成document对象后,可以看到其读取到的xml声明encoding="UTF-8”,其默认的编码格式也是UTF-8,如下图: 在这里插入图片描述

4.这里对BOM说明一下(了解的同学可跳过该部分)

它是在Unicode编码标准中用于标识文件是采用哪种格式的编码。比如: UTF-8 (文本文件头部的BOM为:EF BB BF)、 UTF-16(大端序)(文本文件头部的BOM为:FE FF)、 UTF-16(小端序)(文本文件头部的BOM为:FF FE)、 UTF-32或UCS-(大端序)(文本文件头部的BOM为:00 00 FE FF) UTF-32(小端序)(文本文件头部的BOM为:FF FE 00 00)

Ps: 第一点: 这里说一下大小端: 对于0xABCD在内存中存储方式如下: 大端(Big-Endian): 低地址 -----> 高地址 0xAB 0xCD 小端:(Little- Endian): 低地址 -----> 高地址 0xCD 0xAB

第二点: UTF-8 是可变长编码,不需要 BOM 来表明字节顺序,但可以用 BOM 来表明编码方式。字符 "Zero Width No-Break Space" 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的字节流,就知道这是 UTF-8编码了。Windows 就是使用 BOM 来标记文本文件的编码方式的。

Zero Width No-Break Space是什么? 在UCS 编码中有一个叫做 "Zero Width No-Break Space" ,中文译名作“零宽无间断间隔”的字符,它的编码是 FEFF。而 FEFF 在 UCS 中是不存在的字符,所以不应该出现在实际传输中。UCS 规范建议我们在传输字节流前,先传输字符 "Zero Width No-Break Space"。这样如果接收者收到 FEFF,就表明这个字节流是 Big-Endian 的;如果收到FFFE,就表明这个字节流是 Little- Endian 的。因此字符 "Zero Width No-Break Space" (“零宽无间断间隔”)又被称作 BOM。

UCS 编码是什么? Unicode是为整合全世界的所有语言文字而诞生的。任何文字在Unicode中都对应一个值,这个值称为代码点(code point)。代码点的值通常写成 U+ABCD 的格式。而文字和代码点之间的对应关系就是UCS-2(Universal Character Set coded in 2 octets)。顾名思义,UCS-2是用两个字节来表示代码点,其取值范围为 U+0000~U+FFFF。 为了能表示更多的文字,人们又提出了UCS-4,即用四个字节表示代码点。它的范围为 U+00000000~U+7FFFFFFF,其中 U+00000000~U+0000FFFF和UCS-2是一样的。 要注意,UCS-2和UCS-4只规定了代码点和文字之间的对应关系,并没有规定代码点在计算机中如何存储。规定存储方式的称为UTF(Unicode Transformation Format),其中应用较多的就是UTF-16和UTF-8了。



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3