结合急性重音与结合急性音标和如何正常化之间的差异

Question

，所以我有一个应用程序（我们称其为客户端），该应用程序使用带有变性/口音的字符串。此应用程序需要使用这些字符串的带有变性的字符串向另一个应用程序提出请求（我们称其为Web Service）。开发了此其他应用程序以接收此类字符串。

但是，当客户端向Web服务提出请求时，情况并不能按预期工作。在调查中，我意识到问题与变量有关。

基本上，似乎有些显示出与肉眼相同的变音符号具有不同的Unicode表示。

例如，通常称为急性口音：我意识到有一个八十401https://unicodelookup.com/#01401/1，另一个具有01501 https https：//unicodelookup的八分之一。com/＃01501/1

具有01401八分代表示形式的

称为组合急性口音，而具有01501的一个则称为组合急性音调标记。因此，除了具有不同的表示外，它们似乎也具有不同的语义。

这是我遇到的问题的根源。客户使用被称为组合急性音标记的音符创建其字符串，而客户期望与组合急性重音的字符串

所以问题是，这两者到底有什么区别？（谷歌搜索似乎在这里没有任何有用的内容）以及我如何在这两种表示之间"归一化/转换"（我相信这是需要做的），以便客户能够进行成功的呼叫到Web服务。

更新我可以提到客户发送的字符串是从浏览器发送的，因此我可以复制字符串并使用Unicodelookup.com上的工具进行查找。

。

我只是从另一台计算机上进行了同样的查找。以前，我在Mac上进行查询。当我进行查找时（通过从浏览器URL复制并将角色粘贴到Unicodelookup.com上），现在返回的是组合急性音调标记现在返回，以结合急性口音 <<em>/p>

以为我应该提到这个观察。

Answer 1

您可以通过使用JavaScript的String.prototype.normalize方法在浏览器中进行Unicode归一化。

接受Unicode用户输入时，当涉及任何形式的比较时，应进行归一化，而不仅仅是您发现的原因。您应该使用的哪种归一化表格取决于用例，但是NFC是一个不错的默认形式（这是没有参数的.normalize()）。

您提到的组合标记是"典型上等效的"，因此以相同的形式正常化两者（在这种特定情况下哪一个都不会使它们平等：

var accented = "au0300"  // "à"
var toneMarked = "au0340"  // "à"
accented === toneMarked  // false
accented === accented.normalize("NFD")  // true, this is already the canonical decomposed form
toneMarked === toneMarked.normalize("NFD")  // false
accented === toneMarked.normalize("NFD")  // true
accented.normalize("NFC") === toneMarked.normalize("NFC")  // true
accented.normalize() === toneMarked.normalize()  // equivalent to above
// Also have to consider precomposed characters! (single code point)
var composed = "à"
composed === accented  // false
composed.normalize("NFD") === accented  // true
composed === composed.normalize()  // true, this is already the canonical composed form
composed === accented.normalize() && composed === toneMarked.normalize()  // true

请注意，通常应该在后端执行归一化，因为您不能假设来自用户客户端的数据。