forms - 提交带有 Unicode 的表单时如何避免浏览器的 Unicode 规范化

Question

在 HTML 中呈现以下 Unicode 文本时，事实证明浏览器(Google Chrome)执行某种形式的 Unicode normalization将数据发回服务器时。 (可能在 Form C 中)。

但是当使用圣经希伯来语 (בְּרִיךְ הוּא) 文本时，这很容易破坏文本，如 here 中所述(第 9 页)。

有没有办法避免浏览器自动文本规范化？

我写了一篇博文，更详细地描述了我面临的问题:
http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text

Answer 1

这似乎是 WebKit 浏览器(Chrome、Safari)中的一个功能/错误；他们将表单数据标准化为 NFC，这意味着，除其他外，将连续的组合标记重新排序为“规范”顺序。这对我来说是新的，在这种情况下是个坏消息。最糟糕的是，不同的浏览器表现不同。

使用测试用例的简化版本 http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text (使用仅回显原始数据的服务器端脚本)，我注意到 Chrome 和 Safari 重新排列了 U+05E9 U+05C1 U+05B5(SHIN、SHIN DOT、TSERE)中的变音符号，而 IE、Firefox 和歌剧不要。

我还用拉丁字母 e 和组合分音符 U+0308 进行了一个简单的测试。 WebKit 浏览器根据 NFC 规则将其转换为单个字符 ë，而其他浏览器则保持字符对不变。

自 2006 年以来，这似乎是一个有意的特征； https://bugs.webkit.org/show_bug.cgi?id=8769自豪地宣布这是错误修复的一部分!这可能解释了 W3C 政策文件的状态；它的当前版本在这个问题上支持 WebKit，但其他浏览器供应商要么不感兴趣，要么故意反对“早期规范化”的想法。

我认为没有办法阻止这种情况。但是您可以警告用户不要使用 Chrome 和 Safari。您甚至可以使用包含简单问题案例的隐藏字段，然后检查服务器端是否按原样传输，如果不是，则告诉用户更换浏览器。

修复服务器端的订单并不简单，因为常见的规范化例程显然不支持所需的订单。您可以标准化为完全分解形式 (NFD)，然后为此使用您自己的代码重新排列组合标记。也许更简单和更安全，您可以运行一个临时替换例程，用其他序列替换组合标记序列。这会更安全，因为它不会影响您想要影响的字符以外的字符，而 NFD 使用变音符号分解拉丁字母等。

根据 Unicode 原则，规范等效的字符串(例如，仅在连续变音符号的顺序上有所不同)是相同数据的不同表示，但与 Unicode 字符序列(代码点)不同；预计它们的呈现方式不会有所不同，但它们可能并且经常会有所不同。通常，您不应期望程序将规范等效的字符串视为不同的字符串，尽管程序可能会有所不同。见 Unicode Normalization FAQ .

FAQ 条目声称通过引入 COMBINING GRAPHEME JOINER 已经解决了圣经希伯来语的问题。尽管它可以防止 Chrome 中的重新排序，但它是一种笨拙的方法，并且可能会弄乱渲染(在 Web 浏览器中确实如此；变音符号可能会严重错位)。