字符速记\s的实现特性答案

【问题标题】：Implementation feature of character shorthand \s字符速记\s的实现特性
【发布时间】：2021-09-26 07:34:45
【问题描述】：

我想知道为什么在 Erlang 的正则表达式库 re 中，字符简写 \s 只选择一个空格（32 ASCII 字符），而不是 [ \\t\\n\\r] 正则表达式的等价物。

同时，\s - \S（非空格字符简写）的“反模式”实现了可预测的行为。

测试实验室

EUnit tests 为\s。
EUnit tests 为[ \\t\\n\\r]。
EUnit tests 为\S。

【问题讨论】：

从未使用过，但第一个链接中的文档说 “为了与 Perl 兼容，\s 不用于匹配 VT 字符（代码 11），这使得它不同于POSIX "space" 类。然而，Perl 在 5.18 版本中添加了 VT，PCRE 在 8.34 版本中跟进。默认的 \s 字符现在是 HT (9), LF (10), VT (11), FF (12), CR (13) 和空格 (32)，它们在“C”语言环境中被定义为空格。” 您是说您遇到的行为与文档中提到的内容相矛盾吗？
是的。原来如此。我已经通过测试验证了这一点。
我目前正在测试 Erlang re 库的工作，阅读文档并分享我的发现。如果有人，一个更有经验的 Erlang 程序员，能告诉我们一些有价值的东西——为什么会这样，我会很高兴。
我回到 Erlang/OTP R14B04 并运行了您的 tests_09_whitespace_01_tests:research_test/0 函数，该函数针对所有值 0-255 测试 \s，并针对该 OTP 版本和此后的每个主要版本，它打印出找到 9、10、12、13 和 32，然后从版本 20.0 开始，它还包含 11 作为匹配项。这与 @41686d6564 的文档和评论相匹配。我在我的环境中设置了LC_ALL=C。我建议检查您的语言环境设置。
@SteveVinoski，谢谢你的线索！我用 Erlang/OTP 24 运行测试。我检查了我的语言环境。 LC_ALL 未设置。应该在变量 LC_ALL 中设置什么值才能获得文档中声明的值并使用 Unicode？从re 库的开发人员的角度来看，我非常希望有正确的系统设置。

标签： regex erlang

【解决方案1】：

我仍然在 re 库的文档中找到了我的问题的答案。

为了与 Perl 兼容，\s 没有用来匹配 VT 字符（代码 11），这使它与 POSIX “空间”类不同。然而，Perl 在 5.18 版本中添加了 VT，PCRE 在发布 8.34。默认的 \s 字符现在是 HT (9)、LF (10)、VT （11）、FF（12）、CR（13）和空格（32），定义为白色 “C”语言环境中的空格。如果特定于语言环境，此列表可能会有所不同匹配正在发生。例如，在某些语言环境中 “不间断空格”字符 (\xA0) 被识别为空格，而在其他情况下，VT 字符不是。

据此，我得出的结论是，预期的工作是可能的，所以只有当有一个设置的语言环境值 - “C”。

现在我明白了为什么一切都是这样工作的——它是由开发人员构思的，也就是说，我们在 Erlang 中实现正则表达式时需要考虑到这个特性。

【讨论】：

【解决方案2】：

为了克服实施限制（与需要考虑区域设置值相关），我实施了一个项目，以便能够使正则表达式文本适应我的软件的可用功能（我的操作系统没有所需的语言环境参数集，但我想继续使用它）。

这是一个帮助库re_tuner。

【讨论】：