接受HTML5 Polyglot作为应用程序/xhtml+；xml

就浏览器支持和HTML5合规性而言，（假设页面实际上是XML格式良好的），使用

application/xhtml+XML

HTTP

Content-type

header为HTML5多语言页面提供服务有多方便

在早期，我提供了XHTML宽度

文本/html

标题，因为在其他方面，一些浏览器根本没有呈现页面或呈现页面，但在行为上有一些奇怪之处

---

HTML5标准是否要求浏览器支持

应用程序/xhtml+xml

内容类型？跨浏览器的实际支持状态是什么？现在使用

应用程序/xhtml+xml

有什么缺点？

不，HTML5不要求浏览器支持

应用程序/xhtml+xml

或

文本/html

它只是

为了与现有内容和以前的规范兼容，此 规范描述了两种创作格式：一种基于XML （称为XHTML语法）和使用自定义格式的语法 受SGML（称为HTML语法）启发。启动位置 必须至少支持这两种格式中的一种，但支持 两者都受到鼓励

自IE9以来，所有值得注意的浏览器都支持

application/xhtml+xml

---

假设您可以编写格式良好的XML，这其实并不难，最大的问题是并非所有Unicode字符都是有效的XML字符，因此您必须始终对用户输入进行额外的清理，这些输入可能会回显到屏幕上，以清理XML中无效的任何字符，否则，您的网页将无法正确呈现（或根本无法呈现）

---

此外，第三方JS库并不总是多语言兼容的。特别是，有些依赖于XML文档不支持的document.write（）。

始终

text/html

，但最重要的是您的编码类型“并非所有Unicode字符都是有效的XML字符，因此您必须始终对用户输入进行额外的清理”所有Unicode字符都是有效的。我相信您得到的是，XML只定义了5个字符的实体引用：quot、apos、lt、gt、amp。无论如何，如果需要，用户输入应该总是经过消毒（删除不需要的数据）并转义（使数据在上下文中安全）。如果您在以前正常工作的页面上遇到XML解析错误，通常意味着您忘记了转义，从而使自己面临漏洞。这就是我使用XML解析进行测试的原因。@chinoto-不，我不是指命名字符实体引用。有效的XML字符省略了代理块U+FFFE和U+FFFF。哦，是的，忘了那些家伙了。但要明确的是，它们似乎只有在未配对或配对不当时才被禁止。