每一个人都能运用UTF-8
普遍性是挑选UTF-8的第一个也是最有说服力的来由。它可以处置惩罚如今天下上运用的每一种笔墨。虽然另有少数空缺，然则愈来愈不明显，被逐步填平了。没有归入的笔墨一般也没有其他任何字符集完成过，纵然有也不能在 XML 中运用。最好的状况下，这些笔墨经由历程字体借用转嫁到 Latin-1 如许的单字节字符集。对这类有数笔墨的真正支撑可以最早来自 Unicode，而且可以只要 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 的默许字符集
固然，要让 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 编码比拟，关于不支撑 Unicode 和 XML 的体系，UTF-8 更不轻易形成题目。
专家们的说法
XML 是第一个周全支撑 UTF-8 的主要范例，但这仅仅是最先。各范例构造都在逐步引荐 UTF-8。比方，包括非 ASCII 字符的 URL 是历久搅扰 Web 的一个题目。在 PC 机上事情的包括非 ASCII 字符的 URL 不能用于 Mac，反之亦然。万维网同盟（W3C）和 Internet 工程使命组（IETF）近来赞同一切 URL 都必须采纳 UTF-8 编码而不能是其他编码，从而处理了这一题目。
W3C 和 IETF 对最早、末了照样偶然运用 UTF-8 变得愈来愈倔强。The W3C Character Model for the World Wide Web 1.0: Fundamentals 指出，“假如必须挑选一种字符编码，则必须是 UTF-8、UTF-16 或 UTF-32。US-ASCII 对 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 以至越发邃晓。The IETF Charset Policy [RFC 2277] 指出，在没有不肯定性的言语中：
协定必须可以运用 UTF-8 字符集，它由 ISO 10646 编码集和 UTF-8 字符编码方法构成，全文拜见 [10646] Annex R（修正版 2 中宣布）。
另外，协定可以划定怎样运用其他 ISO 10646 字符集和字符编码方案，如 UTF-16，然则不能运用 UTF-8 是对本战略的违背，这类违背在进入或许提升到范例跟踪历程时，须要经由变动顺序（[BCP9] 第 9 节），并在协定范例文档中提出邃晓、牢靠的来由。
现有的协定或许从已有数据存储转移数据的协定，可以须要支撑其他数据集，以至运用 UTF-8 以外的默许编码。这是许可的，然则必须可以支撑 UTF-8。
要点：今后一段时间，对遗留协定和文件的支撑可以请求接收 UTF-8 以外的字符集和编码，然则假如必须云云我会异常警惕。每种新的协定、应用顺序和文档都应该运用 UTF-8。
中文、日文和韩文
一种罕见的误会是以为 UTF-8 是一种紧缩花样。实在并非云云。与其他 Unicode 编码迥殊是 UTF-16 比拟，在 UTF-8 中 ASCII 字符占用的空间只要一半。不过一些字符的 UTF-8 编码占用的空间要多出 50%，迥殊是中文、日文和韩文（CJK）如许的象形笔墨。
但即运用 UTF-8 编码 CJK XML，现实的大小可以也比 UTF-16 小。比方，中文的 XML 文档包括大批 ASCII 字符，如 <、>、&、=、"、' 和空格。这些字符的 UTF-8 编码要比 UTF-16 小。细致的紧缩/膨胀要素因文档而异，但不管哪一种状况，差异都不可以很明显。
末了，值得一提的是中文和日文这类象形笔墨，与 Latin、Cyrillic 这类字母笔墨比拟，用字每每更少。因为字符的相对量很大，请求每一个字符运用三个或更多字节才完整地表达这些笔墨，就是说，与英文或俄文比拟，一样的词语或句子，这些言语可以用更少的字表达。比方，“tree”在日文顶用“木”示意（异常像一棵树）。 用 UTF-8 示意须要三个字节，而英文单词“tree”包括四个字母，须要四个字节。日文中的“grove（小树林）”是“林”（两棵树靠在一同）。用 UTF-8 编码须要三个字节，而英文单词“grove”有五个字母，须要五个字节。日文中的“森”（三棵树）依然须要三个字节。而对应的英笔墨“forest”须要六个字节。
假如确切须要紧缩，则运用 zip 或 gzip。紧缩后，UTF-8 和 UTF-16 的大小差不多，不管原始大小相差若干。不管哪一种编码，原始大小越大，紧缩算法去掉的冗余就更多。
硬朗性
真正的上风在于设想，与之前和今后设想的其他任何文本编码比拟，UTF-8 是一种更硬朗、更轻易诠释的花样。起首，与 UTF-16 比拟，UTF-8 没有 endianness 题目。UTF-8 用 Big-endian 和 little-endian 来示意都是一样的，因为 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，完毕纷争。
以上就是细致引见运用UTF-8对XML文档举行编码的细致内容，更多请关注ki4网别的相干文章！
