Fit*_*aki 11 forms unicode normalization unicode-normalization
在HTML中呈现以下Unicode文本时,事实证明,当将数据发布回服务器时,浏览器(Google Chrome)会执行某种形式的Unicode规范化.(可能是表格C).
但是用希伯来文圣经(בְּרִיךְהוּא)文本时,这可以很容易地将文本,因为它在概述这里(第10页).
有没有办法避免浏览器自动文本规范化？
我写了一篇博文,更详细地描述了我所面临的问题:http: //blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-编辑换了,希伯来文
Juk*_*ela 10
这似乎是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和Opera不要.
我还用拉丁字母e进行了简单的测试,接着是组合分音符U + 0308.WebKit浏览器根据NFC规则将其转换为单个字符ë,而其他浏览器保持字符对完整.
自2006年以来,这似乎是一个故意的特征; https://bugs.webkit.org/show_bug.cgi?id=8769自豪地宣布这是错误修复的一部分!这可以解释W3C政策文件的状态; 它目前的版本在本期中是WebKit-minded,但其他浏览器供应商要么不感兴趣,要么故意反对"早期规范化"的想法.
我认为没有办法阻止这种情况发生.但您可以警告用户不要使用Chrome和Safari.您甚至可以使用包含简单问题案例的隐藏字段,然后检查服务器端是否按原样传输,如果不是,则告诉用户更改浏览器.
修复订单服务器端并不简单,因为常见的规范化例程显然不支持所需的订单.您可以标准化为完全分解的形式(NFD),然后使用您自己的代码重新排序组合标记.也许更简单,更安全,您可以运行一个临时替换例程,用其他序列替换组合标记的序列.这样会更安全,因为它不会影响你想要影响的字符以外的字符,而NFD会用变音符号等分解拉丁字母.
根据Unicode原则,规范等效字符串(例如,仅按连续变音符号的顺序不同)是相同数据的不同表示,但与Unicode字符序列(代码点)不同; 他们不会在演讲中有所不同,但他们可能并且经常这样做.通常,您不应期望程序将规范等效的字符串视为不同的,尽管程序可能会有所不同.请参阅Unicode规范化常见问题.
常见问题解答条目声称圣经希伯来语的问题已经通过引入COMBINING GRAPHEME JOINER解决了.虽然它可以防止Chrome中的重新排序,但它是一种笨拙的方法,它可能会使渲染陷入混乱(它在Web浏览器中会出现;变音符号可能会被错误地放错位置).