我知道XML 的默认编码是 UTF-8。所有 XML 消费者都必须如此等等。因此，这不仅仅是 XML 是否具有默认编码的问题。
我也知道文档开头的XML-Declarataion是可选的。<?xml version="1.0" ... ?>并且在其中指定编码也是可选的。
所以我问自己以下两个 XML 声明是否是完全相同的两个表达式：
<?xml version="1.0"?>
<?xml version="1.0" encoding="UTF-8"?>
根据我目前的理解，我会说这些是等价的，但我不知道。是否在某处指定了这两个声明的等价性？
（假设这两个示例行都是 XML 文档的第一行，前面是任何（零）字节并且是 UTF-8 编码的）
简短的回答
在没有外部编码信息的 UTF-8 编码文档的非常特殊的情况下（我从评论中了解到这是您感兴趣的内容），这两个声明之间没有区别。
不过，长答案要有趣得多。
规格说明了什么
如果您查看XML 规范的附录 F1，它解释了在没有外部编码信息时确定编码应遵循的过程。
如果文档被编码为 UTF 变体之一，则解析器应该能够从字节顺序标记或 XML 声明的开头检测前 4 个字节内的编码。
但是，根据规范，它仍应读取编码声明。
在上述不需要读取编码声明来确定编码的情况下，第 4.3.3 节仍然要求读取编码声明（如果存在）并检查编码名称以匹配实体的实际编码。
如果它们不匹配，根据第 4.3.3 节：
...对于包含编码声明的实体以声明中指定的编码以外的编码呈现给 XML 处理器，这是一个致命错误
编码 UTF-16，声明 UTF-8
让我们看看当我们创建一个编码为 UTF-16 但编码声明设置为 UTF-8 的 XML 文档时实际发生的情况。
Opera、Firefox 和 Chrome 都将文档解释为 UTF-16，忽略编码声明。Internet Explorer（至少版本 9）显示一个空白文档，但没有实际错误。
因此，如果您在 UTF-8 文档中包含 UTF-8 编码声明，并且稍后有人将其转换为 UTF-16，它将在大多数浏览器中工作，但在 IE 中失败（而且，我假设大多数 Microsoft XML蜜蜂）。如果你关闭了编码声明，你会没事的。
从技术上讲，我认为 IE 是最准确的。它不显示错误的事实可能是因为错误发生在编码级别而不是 XML 级别。假定尽最大努力将 UTF-16 字符解释为 UTF-8，未能找到任何解码的字符，并最终将空字符序列传递给 XML 解析器。
编码 UTF-8，否则声明
您现在可能认为 Firefox、Chrome 和 Opera 只是完全忽略了编码声明，但情况并非总是如此。
如果您将文档编码为 UTF-8（带有字节顺序标记，因此它与其他任何东西一样无误），但将编码声明设置为 Latin1，则所有浏览器都会成功地将内容解码为 Latin1，而忽略 UTF-8 BOM。
这对我来说似乎是正确的。BOM 字符在 Latin1 中无效的事实仅意味着它们在字符解码级别被静默删除。
不过，这不适用于 UTF-8 文档上所有声明的编码。如果声明的编码是 UTF-16，我们将返回 Opera、Firefox 和 Chrome，忽略声明的编码，而 Internet Explorer 返回一个空白文档。
本质上，任何使 IE 返回空白文档的东西都会使其他浏览器忽略声明的编码。
其他不一致
还值得一提的是字节顺序标记的重要性。根据规范的第 4.3.3 节：
以 UTF-16 编码的实体必须 [...] 以字节顺序标记开头
但是，如果您尝试读取没有 BOM 的 UTF-16 编码的 XML 文档，大多数浏览器仍会接受它为有效的。只有 Firefox 将其报告为 XML 解析错误。
外部编码信息
到目前为止，我们一直在考虑没有外部编码信息时会发生什么，但是，正如其他人所提到的，如果文档是通过 HTTP 接收的或包含在某种 MIME 信封中，那么来自这些来源的编码信息应该优先于文档编码。
RFC3023中描述了各种 XML MIME 类型的大部分细节。然而，实际情况与所指定的有所不同。
首先，带有省略字符集参数的 text/xml 应使用 US-ASCII 字符集，但几乎总是忽略该要求。浏览器通常会使用 XML 编码声明的值，如果没有，则默认使用 UTF-8。
其次，如果文档上有 UTF-8 BOM，并且 XML 编码声明是 UTF-8 或不包括在内，则无论 Content-Type 中使用的字符集如何，文档都将被解释为 UTF-8。
只有在没有 BOM 并且在 Content-Type 中指定了明确的字符集时，来自 Content-Type 的编码似乎优先。
无论如何，在 UTF-8 文档中包含 UTF-8 XML 编码声明与根本没有编码声明没有任何区别（涉及 Content-Type）。
孤立地看，两者是等价的。您已经引用了规范的相关部分，表明这两个声明是等效的。
然而，XML 可以有一个信封，例如 HTTPContent-Type标头。W3C 指定此信封信息优先于文件中的任何其他声明。例如，如果您通过 http 检索 XML，您可能会得到以下信息：
HTTP/1.1 200 OK
Content-Type: text/xml
<root/>
在这种情况下，应该将 XML 读取为ascii，因为text/*mime 类型的默认字符集是 ascii。这就是为什么你应该使用application/xmlmime 类型——这些默认为 utf-8。“应用程序”前缀意味着相关的应用程序规范定义了诸如默认编码之类的东西。（即 XML 规范接管。）对于text/*mime 类型，默认值为 ascii，并且charset参数必须包含在 mime 类型中才能更改字符集。
这是另一个案例：
HTTP/1.1 200 OK
Content-Type: text/xml; charset=win-1252
<?xml version="1.0" encoding="utf-8"?>
<root/>
在这种情况下，符合标准的 XML 处理器应该将此文件读取为win-1252，而不是 utf-8.
另一个案例：
HTTP/1.1 200 OK
Content-Type: application/xml
<?xml version="1.0" encoding="win-1252"?>
<root/>
这里的编码是win-1252.
HTTP/1.1 200 OK
Content-Type: application/xml; charset=ascii
<?xml version="1.0" encoding="win-1252"?>
<root/>
这里的编码是ascii.
如果第二个声明到达已被检测为具有非 UTF-8 兼容编码（例如 UTF-16）的文档的开头，则拒绝第二个声明并非不合理。但是，鉴于您声明文档是 UTF-8 编码的，它们的处理方式没有区别。
在这两种情况下，外部指定的编码都将优先；两份文件仍将一视同仁。
按照我阅读规范的方式，UTF-8不是XML 声明中的默认编码。它只是“既不以字节顺序标记也不以编码声明开头的实体”的默认编码。如果一个文档是 UTF-16 格式并且有一个 BOM，它可能有一个没有编码声明或根本没有 XML 声明的 XML 声明，并且仍然是有效的 XML。
仅对于没有 BOM 的文档，您提到的两个 XML 声明应该是等效的。