每个人都能使用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 的重要标准，但这仅仅是开始。各标准组织都在逐渐
