问题标签 [unicode-normalization]

Unicode 规范化常见问题解答包括以下段落：

程序应始终比较规范等效的 Unicode 字符串是否相等...... Unicode 标准提供了可用于此的明确定义的规范化形式：NFC 和 NFD。

并继续...

选择使用哪个取决于特定的程序或系统。NFC 是一般文本的最佳形式，因为它与从传统编码转换的字符串更兼容。... NFD 和 NFKD 对内部处理最有用。

我的问题是：

什么使 NFC 最适合“一般文本”。什么定义了“内部处理”，为什么最好留给 NFD？最后，不管什么是“最好的”，只要使用相同的规范化形式比较两个字符串，这两种形式是否可以互换？

如果我接受完整的 Unicode 密码，我应该如何在将字符串传递给哈希函数之前对其进行规范化？

目标

如果没有规范化，如果有人ma\u00F1ana在一台计算机ma\u006E\u0303ana上将他们的密码设置为“mañana”（这是在用户代理或其操作系统的控制之下。

• 我想确保这些哈希值相同。
• 我不关心诸如Α、А 和 A（希腊语、西里尔语、拉丁语）之类的同形文字。

参考

Unicode 规范化形式：http ://unicode.org/reports/tr15/#Norm_Forms

注意事项

• 任何标准化过程都可能导致冲突，例如"office" == "office"。
• 规范化可以改变字符串中的字节数。

进一步的问题

• 如果服务器接收到无效的 UTF-8（或其他格式）的字节序列会发生什么？拒绝，因为它不能被规范化？
• 如果服务器接收到在其 Unicode 版本中未分配的字符会怎样？

我正在寻找一个示例文本 unicode 文件 (UTF-8)，可用于测试与文本编码和解码相关的不同问题，包括：

• 低 ascii 字符使用率，例如前 32 个代码
• BMP 以外的字符
• NFC 相关问题
• XML 编码/解码问题

主要是我想将文本复制到剪贴板，将其粘贴到应用程序的 HTML 文本区域中，然后能够从页面中检索它。

这将能够识别可能在解码、编码甚至数据库级别发生的不同 Unicode 相关问题。

我们使用的是 Perl 版本 5.8.8。我相信它有一些 Unicode (UTF-8) 支持，但我不相信它是可靠的。使用 Perl 5.8.8 处理和保存数据的最佳选择是什么？html实体与实际处理Unicode怎么样？我们处理非常大的文档。为了使许多功能正常工作，我们目前过滤/替换一些 Unicode，将一些非恒定编码作为 html 授权，并且一些代码通过但转义匹配并导致许多必须修复的错误修复逐个。有些可能被忽视了，我们生活在减少的排版中。我是那种对此有点恼火的类型。
到目前为止，我的想法是输入 Unicode 字符很麻烦，并且扩展的标点字符比实体更难在视觉上区分。最后，我阅读了有关处理 Unicode 的文章，并认为它可能对使用当代 Perl 版本的新项目有好处，但难以改造，因此将脚本标准化为 html 实体似乎是一个更好的选择。另一方面，边界代码或脚本无论如何都需要使用 Unicode。我认为它不会影响 JavaScript 中的功能。我相信这些实体很快就会被翻译成 Unicode 字符并成为 DOM 文本节点的常规元素。

是否有一个库或脚本可以始终规范 Unicode和html 实体的使用？如果是实体，它应该使用命名实体的简短词典在该空间内进行规范化，其余部分默认为数字。那将是一个单独的步骤，并且相对容易。其他步骤是修改输入脚本以帮助规范化 Perl 代码，并创建一些习惯用法来匹配诸如破折号、具有多个选项的引号之类的元素。

我们最近升级了我们的安全扫描器，它报告了一个新问题。

推荐的修复方法是什么？（我们恰好在 ACF9 上。）

（另外，如果你有一个针对 CF 的示例漏洞，我将不胜感激。）

---

Unicode 转换问题

严重性

高的

类型

配置

按模块报告

脚本 (XSS.script)

描述

此页面容易受到各种 Unicode 转换问题的影响，例如最佳匹配映射、超长字节序列、格式错误的序列。

当字符 X 转换为完全不同的字符 Y 时，会发生最佳匹配映射。通常，当字符在 Unicode 和另一种编码之间进行转码时，会发生最佳匹配映射。

超长字节序列（非最短形式）- UTF-8 允许不同的字符表示形式也具有较短的形式。出于安全原因，UTF-8 解码器不得接受长于编码字符所需的 UTF-8 序列。例如，字符 U+000A（换行符）只能以 0x0A 的形式从 UTF-8 流中接受，但不能以以下五种可能的超长形式中的任何一种形式接受：

• 0xC0 0x8A

• 0xE0 0x80 0x8A

• 0xF0 0x80 0x80 0x8A

• 0xF8 0x80 0x80 0x80 0x8A

• 0xFC 0x80 0x80 0x80 0x80 0x8A

UNICODE 3.0 要求的格式错误的子序列，并在 Unicode 技术报告 #36 中指出，如果前导字节后跟无效的后继字节，则不应使用它。

影响

出现最佳拟合映射时会出现软件漏洞。例如，可以操纵字符以绕过字符串处理过滤器，例如跨站点脚本 (XSS) 或 SQL 注入过滤器、WAF 和 IDS 设备。过长的 UTF-8 序列可能会被滥用来绕过 UTF-8 子字符串测试，这些测试只寻找可能的最短编码。

推荐

确定这些 Unicode 转换问题的来源并修复它们。有关更多信息，请参阅下面的网络参考。

参考

Unicode 安全

适用于 Unix/Linux 的 UTF-8 和 Unicode 常见问题解答

PHP 和 Firefox 上的几个 unicode 问题

Unicode 安全注意事项

影响项目

/我的网站门户/

细节

URL 编码的 POST 输入 linkServID 设置为 acu5955%EF%BC%9Cs1%EF%B9%A5s2%CA%BAs3%CA%B9uca5955

问题清单：

• Unicode 字符 U+02B9 MODIFIER LETTER PRIME（编码为 %CA%B9）被转换为 U+0027 APOSTROPHE (')

• Unicode 字符 U+02B9 MODIFIER LETTER PRIME（编码为 %CA%B9）被转换...（行被截断）

请求标头

得到

/mysite-portal/?display=login&status=failed&rememberMe=0&contentid=&LinkServID=acu5955%1 Cs1es2%BAs3%B9uca5955&returnURL= https://stage-cms.mysite.com/mysite-portal/ HTTP/1.1 参考：https:// stage-cms.mysite.com:443/

连接：保活

接受编码：gzip,deflate

用户代理：Mozilla/5.0（兼容；MSIE 9.0；Windows NT 6.1；WOW64；Trident/5.0）

接受： */*

主办方：stage-cms.mysite.com

我想从 Haskell 运行一个具有 unicode 文件路径的 bash 命令。

Haskell 中的字符串使用 \escapes 例如

"beißen" -> "bei\223en"

Bash 似乎接受以下格式：

$'bei\xC3\x9Fen.avi'和'beißen.avi'

因为runCommandfromSystem.Process有类型

runCommand :: String -> IO System.Process.Internals.ProcessHandle

如何将 Haskell 字符串编码为 Bash 接受的格式之一？

使用具有 bash 3.2 的 Mac OSX 10.8.4 。

编辑

我的问题似乎与 bash 转义有关

我正在使用Text.ShellEscape（http://hackage.haskell.org/packages/archive/shell-escape/0.1.2/doc/html/Text-ShellEscape.html）来转义需要为 bash 转义的字符

例如

这给了我"$'bei\\xDFen.txt'"

跑步时runCommand $ "ls " ++ cmd

它给了我 ls: bei�en.txt: No such file or directory

是否有更好的方法来为 bash 转义字符串？

在最近的一次漏洞披露中，spotify 谈到了用户如何使用用户名规范化代码中的故障来访问他们不拥有的帐户。问题是他们正在对用户名应用非幂等操作以检查它们是否被使用，因此 ᴮᴵᴳᴮᴵᴿᴰ 和 BIGBIRD 是不同的用户名，而不应该是。

我想允许我的网站使用 Unicode 用户名，但我不想容易受到此类攻击。我不使用 Python，所以我不能使用他们在他们的网站上提出的解决方案。是否有任何一种幂等公式，可以在支持 Unicode 操作的任何平台（即 python、ruby、lua、javascript、.NET 等）上使用，它将处理两个仅具有“视觉”差异的 Unicode 字符串相同的字符串? 它像NKFD +小写字符串一样简单吗？

如果我将 Unicode 规范化表格 C 应用于字符串，字符串中的代码点数量会增加吗？

给定一个 NFC 规范化字符串，对该字符串应用全大小写折叠，我可以假设结果也是 NFC 规范化的吗？

我不明白 Unicode 标准在这句话中试图告诉我什么：

规范化也与案例折叠相互作用。对于任何字符串 X，令 Q(X) = NFC(toCasefold(NFD(X)))。换句话说，Q(X) 是对 X 进行归一化，然后对结果进行大小写折叠，然后将结果放入归一化形式 NFC 格式的结果。由于定义归一化和大小写折叠的方式，Q(Q(X)) = Q(X)。重复应用 Q 不会改变结果；对于规范化形式 NFC 或 NFD，案例折叠在规范规范化下关闭。

Mac 通常在规范化路径的 HFS+ 文件系统上运行。也就是说，如果您保存一个带有重音符号 é 的文件（u'\xe9'例如），然后执行 a os.listdir，您会看到文件名已转换为u'e\u0301'. 这是Pythonunicodedata模块可以处理的正常 unicode NFD 规范化。不幸的是，HFS+ 与 NFD 不完全一致，这意味着一些路径不会被规范化，例如福 ( u'\ufa1b') 不会改变，尽管它的 NFD 形式是u'\u798f'。

那么，如何在 Python 中进行规范化呢？只要我可以从 Python 调用它们，我就可以使用本机 API。