我应该编写多语言 HTML5 文档吗？答案

【问题标题】：Should I write Polyglot HTML5 documents?我应该编写多语言 HTML5 文档吗？
【发布时间】：2010-06-24 01:33:01
【问题描述】：

我一直在考虑将我当前的 HTML5 文档转换为多语言 HTML5 文档。我认为即使他们只被用作text/html，编写 XML 的额外检查也将有助于保持我的编码习惯整洁和有效。

在仅限 HTML5 的领域中是否有什么特别令人兴奋的东西会使这是一个不明智的选择？

其次，关于如何验证多语言文档的规范有点模糊。我假设基础是：

通过 W3C 验证器作为 HTML5 运行时没有错误
通过 XML 解析器运行时没有错误

但是我还缺少其他规则吗？

第三，鉴于它是一种多语言，有谁知道将其作为application/xhtml+xml 用于支持浏览器并将text/html 用于不支持浏览器的任何警告？

编辑：经过一点试验，我发现像&nbsp; 这样的实体会在 XHTML5 中中断（没有 DTD）。 XML 解析器有点像一把双刃剑，我想我已经回答了我的第三个问题。

【问题讨论】：

这个问题需要更新（现在 HTML5 是推荐！）...另见 stackoverflow.com/q/28419046/287948

标签： html xhtml polyglot-markup

【解决方案1】：

目前正在进行定义如何创建 HTML5 多语言文档的工作，但请参阅 http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html 了解早期草案。这当然是可能的，但它确实需要大量的编码纪律，并且您需要决定是否值得付出努力。虽然我创建了 HTML4.01/XHTML1.0 多语言文档，但我使用 XML 工具链创建它们，该工具链保证 XML 格式正确，并具有专门的代码来确保与 HTML 非空元素和有效 XML 字符的兼容性。直接手工编码会非常困难。

HTML5 中一个已知的当前问题是 iframe 元素上的 srcdoc 属性。因为属性的值包含标记，某些字符需要转义。 HTML5 草案规范描述了如何为 HTML 序列化执行此操作，但没有（我上次查看）如何在 XHTML 序列化中执行此操作。

【讨论】：

感谢您的指导！我从不喜欢 iframe。他们总是看起来像“哟，dawg，我听说你喜欢网页，所以我在你的网页中放了一个网页，这样你就可以一边冲浪一边冲浪”。

【解决方案2】：

我迟到了，但 5 年后这个问题仍然有意义。一方面，关闭我所有的标签对我很有吸引力。为了阅读它的人，为了更容易编辑，为了大正义。 OTOH，看看多语言规范的血腥细节 - http://www.sitepoint.com/have-you-considered-polyglot-markup/ 最后有一个方便的摘要 - 我很清楚我不能全部直接手动完成。

https://developer.mozilla.org/en/docs/Writing_JavaScript_for_XHTML 还为 XHTML 失败的原因提供了有趣的启示：选择使用 XML mime 类型在运行时会产生各种副作用。到目前为止，好的 JS 代码处理这些应该是例行公事（例如，在比较之前总是小写标签名称），但我不想要所有这些。有足够多的跨浏览器问题可以按原样进行测试，谢谢。

所以我认为有一个有用的中间方法：

目前仅用作text/html。不要担心它实际上会在 HTML 和 XML 模式下解析为具有相同运行时行为的完全相同的 DOM。
只有 strive 将它解析为 some 格式良好的 XML。它可以帮助读者，可以帮助编辑，还可以让我在自己的文档上使用 XML 解析器。

不幸的是，多语言工具很少甚至不存在 - 甚至很难以同时满足 HTML 要求的方式序列化回 XML...
- 不费吹灰之力：总是自行关闭无效标签 (<hr/>) 并单独关闭非无效标签 (<script ...></script>)。
- 不费吹灰之力：使用小写标签和 attr（除了一些 SVG，但外国内容无论如何都使用 XML 规则），总是引用属性值，总是提供属性值（selected="selected" 比 stanalone 更详细 selected 但我可以忍受）。
- 内联<script> 和<style> 最烦人。在不破坏 XML 解析的情况下，我无法在内部使用 & 或 <。我需要：
```
<script>/*<![CDATA[*/
   foo < bar && bar < baz;
/*]]>*/</script>
```
...就是这样！不关心 XML 命名空间或匹配 HTML 的表隐含 DOM 会降低大约一半的规则:-)
等待将来我可以直接去创作 XHTML，跳过多语言。好处是我将能够忘记标签关闭的限制，将能够直接使用 XML 工具和生成它。当然，现在忽略 xml 命名空间和其他东西会使转换变得更加困难，但我认为我会在未来创建更多新文档，而不是转换现有文档。

实际上，我不完全确定是什么阻止了我现在生活在那个未来。只有IE 8吗？我也有点担心全有或全无的错误处理。我有点希望未来的 HTML 规范能找到缩小 HTML 与 XML 差距的方法，例如让浏览器接受 HTML 中的 <hr></hr> 和 <script .../>，同时仍保留 HTML 错误处理。

还有工具。拥有可以序列化为多语言标记的多种语言的库将使程序生成它变得可行。拥有验证和转换 HTML5 polyglot XHTML5 的工具会有所帮助。否则，它几乎注定要失败。

【讨论】：

【解决方案3】：

鉴于 W3C 关于 HTML 和 XHTML 之间差异的文档甚至还没有完成，您可能不值得花时间尝试多语言。反正还没有……再给它几年。

无论如何，只有在您积极计划将 HTML 解析为 XML 以用于某些特定目的的极少数情况下，您才应该在 XML 合规性上投入额外的时间。纯粹为了让网络浏览器使用它没有任何好处——只有缺点。

【讨论】：

【解决方案4】：

你应该吗？是的。但首先要澄清几点。

发送Content-Type: application/xhtml+xml 标头仅意味着它应该通过 XML 解析器，据我所知，它仍然具有 HTML5 的所有优点。
关于&nbsp;，在 XML 中没有定义，XML 定义的唯一字符实体引用是 lt、gt、apos、quot 和 amp，您需要对其他任何内容使用数字字符引用。 nbsp 的代码是&#xa0; 或&#160;，我个人更喜欢十六进制，因为 unicode 代码点是这样表示的（U+00A0）。

发送标头对于测试很有用，因为您可以快速找到标记的问题，例如未闭合的标签、杂散的结束标签、可能被解释为标签的文本等，基本上是可能破坏外观甚至功能的东西您的网站。
在我看来，最重要的是，如果您允许用户输入并且它无法解析，这通常意味着您没有逃避他们的数据并且让自己容易受到漏洞的影响。解析为 HTML，在有人开始注入脚本来骚扰您的用户或窃取数据之前，您可能永远不会注意到问题。

这个页面很好地解释了多语言标记是什么：https://blog.whatwg.org/xhtml5-in-a-nutshell

【讨论】：

实际上，今天我会以“否”来回答我自己的问题。维护有效文档的唯一万无一失的方法是生成您的 (X)HTML5，并且从不发送任何原始的人工生成数据。因此，如果您已经要使用生成器，您不妨只生成 HTML5，并让生成器在文档到达浏览器之前将您的输入或原始数据验证为可预测的输出。通过像 haml 或 slim-lang（带有解析器的东西）这样的模板引擎生成，或者使用像 React 这样的视图渲染引擎生成。
我已经写了几年的多语言标记，除了htmlentities($dirty,ENT_QUOTES|ENT_XML1|ENT_SUBSTITUTE,"UTF-8",true)（为了方便我将它包装在一个函数中）之外，我从来不需要任何东西来处理用户在 PHP 中生成的内容或我提供的内容将其作为 JSON 转换为 javascript 并设置 textContent（适用于重复标记）。我很好奇你觉得这有什么困难。

【解决方案5】：

这听起来是一件非常困难的事情。 XHTML 的缺点之一是它无法成功地在 XML 和老式 HTML 的竞争需求之间进行转换。

我认为，如果您编写 HTML5 并成功验证它，您将拥有任何人都需要的整洁有效的文档。

【讨论】：

不确定是否像任何人都需要的那样整洁有效。考虑xmlplease.com/xhtml/xhtml5polyglot/#s1

【解决方案6】：

这个 wiki 有一些 W3C 文档中没有的信息：http://wiki.whatwg.org/wiki/HTML_vs._XHTML

【讨论】：