ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2021-12-14 14:06:12  阅读:125  来源: 互联网

标签:XML 编码 UTF DOM encoding xml BOM 解析


目录

1.规定

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

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

标签:XML,编码,UTF,DOM,encoding,xml,BOM,解析
来源: https://blog.csdn.net/MrYushiwen/article/details/121925364

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有