xmlutf8编码_⽤UTF-8编码XML⽂档
xml utf8 编码
Google的Sitemaps服务最近要求所有站点地图必须以Unicode的UTF-8编码专门发布，从⽽在XML社区引起了轻微的轰动。 Google甚⾄不允许使⽤Unicode的替代编码（例如UTF-16），更不允许使⽤⾮Unicode编码（例如ISO-8859-1）。 从技术上讲，这意味着Google 使⽤的是不合格的XML解析器，因为XML建议特别要求“所有XML处理器必须接受Unicode 3.1的UTF-8和UTF-16编码”。 但是，这真的是⼀个⼤问题吗？
每个⼈都可以使⽤UTF-8
普遍性是选择UTF-8的第⼀个也是最令⼈信服的原因。 它可以处理当今星球上⼏乎所有正在使⽤的脚本。 仍然存在⼀些差距，但这些差距越来越模糊，现在正在填补。 通常，未发现的脚本也没有以任何其他字符集实现，即使有，也⽆法在XML中使⽤。 充其量，它们会被嫁接到像Latin-1这样的⼀字节字符集上的字体hack所覆盖。 对这些少数脚本的真正⽀持将⾸先出现，并且可能仅在Unicode中出现。
但是，这仅是使⽤Unicode的参数。 为什么选择UTF-8⽽不是UTF-16或其他Unicode编码？ 最简单的原因之⼀是⼴泛的⼯具⽀持。 ⼏乎所有可能与XML⼀起使⽤的重要编辑器都可以处理UTF-8，包括JEdit，
BBEdit，Eclipse，emacs甚⾄Notepad。 在XML和⾮XML⼯具中，没有其他Unicode编码具有如此⼴泛的⼯具⽀持。
在某些情况下，例如BBEdit和Eclipse，UTF-8不是默认字符集。 现在是时候更改默认值了-所有⼯具都应该开箱即⽤，将UTF-8选择为默认编码。 在这种情况发⽣之前，我们陷⼊了⽆法互操作的⽂件的混乱之中，这些⽂件在跨国家，平台和语⾔边界传输时会破裂。 但是在所有程序默认为UTF-8之前，您可以轻松更改默认值。 例如，在Eclipse中，图1所⽰的“ General / Editors”⾸选项⾯板允许您指定所有⽂件都应为UTF-8。 您会注意到Eclipse希望默认使⽤MacRoman。 但是，如果您允许这样做，则当⽂件传输到在Microsoft®Windows®或美洲和西欧以外的任何计算机上⼯作的程序员时，⽂件将不会编译。
图1.在Eclipse中更改默认字符集
Eclipse字符集⾸选项
当然，要使UTF-8正常⼯作，与您交换⽂件的开发⼈员也必须使⽤UTF-8。 但这不应该是⼀个问题。 与MacRoman不同，UTF-8不仅限于少数脚本和少数平台。 UTF-8适合所有⼈。 对于MacRoman，Latin-1，SJIS和其他各种国家传统字符集⽽⾔，情况并⾮如此。
UTF-8在不希望接收多字节数据的⼯具上也能更好地⼯作。 其他Unicode格式（例如UTF-16）往往包含许多零字节。 有许多⼯具将这些字节解释为⽂件末尾或某些其他特殊的定界符，从⽽产⽣意想不到的，⽆法预料的以及通常令⼈不快的效果。 例如，如果将UTF-16数据天真地加载到C字符串中，则该字符串可能会在第⼀个ASCII字符的第⼆个字节上被截断。 UTF-8⽂件仅包含真正意味着为null的null。 当然，您不会选择使⽤任何此类幼稚的⼯具来处理XML⽂档。 但是，⽂档通常会出现在旧系统中的陌⽣地⽅，没有⼈真正考虑或理解将新酒装⼊旧瓶的后果。 与UTF-16或其他Unicode编码相⽐，UTF-8不太可能导致不了解Unicode和XML的系统出现问题。
规格怎么说
XML是第⼀个全⼼全意地⽀持UTF-8的主要标准，但这仅仅是趋势的开始。 标准机构越来越多地建议使⽤UTF-8。 例如，包含⾮ASCII字符的URL长期以来⼀直是Web上令⼈困扰的问题。 包含在Mac上的⾮ASCII字符的URL在Mac上加载后失败，反之亦然。 万维⽹联盟
（W3C）和互联⽹⼯程任务组（IETF）同意，所有URL都将以UTF-8进⾏编码，⽽这⼀问题最近得到解决。
最近，W3C和IETF都更加坚定地选择⾸先，最后，有时甚⾄仅选择UTF-8。 万维⽹1.0：基本原理的W3C字符模型指出：“当需要唯⼀的字符编码时，字符编码必须为UTF-8，UTF-16或UTF-32。US-AS
CII与UTF-向上兼容。 8（US-ASCII字符串也是UTF-8字符串，请参见[RFC 3629]），因此，如果需要与US-ASCII兼容，则UTF-8是合适的。” 实际上，与US-ASCII的兼容性是如此有⽤，⼏乎是必需的。W3C明智地解释说：“在其他情况下，例如对于API，UTF-16或UTF-32可能更合适。选择其中⼀种可能的原因包括内部处理的效率以及与其他进程的互操作性。”
我可以相信关于内部处理效率的争论。 例如，Java™语⾔的字符串内部表⽰形式是基于UTF-16的，这使得索引字符串的速度更快。 但是，Java代码从不将此内部表⽰公开给与其交换数据的程序。 相反，对于外部数据交换，使⽤java.io.Writer ，并明确指定字符集。 做出这样的选择时，强烈建议使⽤UTF-8。
IETF更加明确。 IETF字符集策略[RFC 2277]明确指出：
协议必须能够对所有⽂本使⽤UTF-8字符集，该字符集由ISO 10646编码字符集和UTF-8字符编码⽅案（如[10646]附件R（在修订2中发布）定义）组成。
协议可以另外规定如何对ISO 10646使⽤其他字符集或其他字符编码⽅案，例如UTF-16，但是缺乏使⽤UTF-8的能⼒则违反了该政策。 这种违规将需要在协议规范⽂档中加⼊或推进标准流程之前，在协议规范⽂档中有明确⽽明确的理由的差异程序（[BCP9]第9节）。
对于现有协议或从现有数据存储中移动数据的协议，可能需要⽀持其他字符集，甚⾄使⽤UTF-8以外的默认字符集。 这是可以接受的，但必须⽀持UTF-8。
底线：对旧版协议和⽂件的⽀持可能需要⼀段时间才能接受UTF-8以外的字符集和编码-但是如果需要的话，我会保持警惕。 每个新协议，应⽤程序和⽂档都应使⽤UTF-8。
中⽂，⽇⽂和韩⽂
⼀个常见的误解是UTF-8是⼀种压缩格式。 不是。 ASCII范围内的字符仅占UTF-8中其他字符（特别是UTF-16）的⼀半。 但是，某些字符需要最多50％的空间才能⽤UTF-8进⾏编码-特别是中⽂，⽇⽂和韩⽂（CJK）表意⽂字。
但是，即使您使⽤UTF-8编码CJK XML，与UTF-16相⽐，实际的⼤⼩增加也不算太⼤。 例如，⼀个中⽂XML⽂档包含许多ASCII字符，例如<，>，＆，=，“，”和空格。在UTF-8中，这些字符都⽐在UTF-16中都⼩。确切的收缩或扩展因⼦会有所不同从⼀个⽂档到下⼀个⽂档，但是⽆论哪种⽅式，差异都不⼤。
最后，值得注意的是，与拉丁字母和西⾥尔字母字母的脚本相⽐，象中⽂和⽇语的表意⽂字往往与字符同等。 这些字符的绝对数量很⼤，每个字符需要三个或更多字节才能完全表⽰这些脚本。 这意味着
相同的单词和句⼦可以⽤少于英语和俄语等语⾔的字符来表达。 例如，⽇本⼈对树的表意⽂字是æ??¨。 （它看起来有点像⼀棵树。）在UTF-8中占据了三个字节，⽽英语单词“ tree”则由四个字母和四个字节组成。 ⽇本格罗夫的表意⽂字是æ （两棵树彼此相邻）。 它在UTF-8中仍占据三个字节，⽽英语单词“ grove”则需要五个字母并需要五个字节。 ⽇本表意⽂字（三棵树）仍然只占三个字节。 但是，等效的英语单词“ forest”需要六个。
如果确实要进⾏压缩，请对XML进⾏zip或gzip压缩。 压缩后的UTF-8⼤⼩可能会接近压缩后的UTF-16，⽆论初始⼤⼩如何不同。 最初以较⼤者为准，它将具有更多冗余以减少压缩算法。
坚固性
真正的缺点是，从设计上讲，UTF-8是⼀种⽐之前或之后设计的任何其他⽂本编码更健壮和易于解释的格式。 ⾸先，与UTF-16不
url编码和utf8区别同，UTF-8没有字节顺序问题。 ⼤端和⼩端UTF-8是相同的，因为UTF-8是根据8位字节⽽不是16位字定义的。 UTF-8对于必须使⽤字节顺序标记或其他启发式解析的字节顺序没有任何歧义。
UTF-8的⼀个更重要的特征是⽆状态。 UTF-8流或序列的每个字节都是明确的。 在UTF-8中，您始终知道⾃⼰的位置-也就是说，给定⼀个字节，您可以⽴即确定它是单字节字符，两个字节字符的第⼀个
字节，还是两个字节的第⼆个字节字符，或三字节或四字节字符的第⼆，第三或第四字节。 （这不是所有的可能性，但是您明⽩了。）在UTF-16中，您并不总是知道字节“ 0x41”是否为字母“ A”。 有时是，有时不是。 您必须跟踪⾜够的状态才能知道您在流中的位置。 如果丢失单个字节，则从该点开始的所有数据都将被破坏。 在UTF-8中，丢失或损坏的字节很明显，并且不会破坏其余数据。
UTF-8并⾮在所有情况下都是理想的。 当使⽤固定宽度的编码（例如UCS2或UTF-32）时，需要随机访问⽂档中特定索引的应⽤程序可以更快地运⾏。 （⼀旦考虑了代理对，UTF-16是可变宽度的字符编码。）但是，XML处理并不是这样的应⽤程序。 XML规范实际上要求解析器从XML⽂档的第⼀个字节开始，然后继续解析直到结束，并且所有现有的解析器都像这样运⾏。 更快的随机访问不会以任何有意义的⽅式帮助XML处理。 因此，尽管这可能是在数据库或其他系统中使⽤其他编码的⼀个很好的理由，但它不适⽤于XML。
摘要
在⽇益国际化的世界中，语⾔和政治边界每天变得越来越模糊，依赖于语⾔环境的字符集不再可⾏。 Unicode是唯⼀可以在地球上的许多区域进⾏互操作的字符集。 UTF-8是Unicode的正确编码：
它提供了⼴泛的⼯具⽀持，包括与传统ASCII系统的最佳兼容性。
它是直接且⾼效的处理。
它可以抵抗腐败。
它是平台⽆关的。
现在是时候停⽌争论字符集和编码了-选择UTF-8并完成讨论。xml utf8 编码

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。