本备忘录的状态

这是一份互联网标准跟踪文档。¶

本文档是互联网工程任务组 (IETF) 的产品。 它代表了IETF社区的共识。 它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准发布。 有关互联网标准的更多信息，请参阅 RFC 7841 第 2 节。¶

有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9485。¶

版权声明

版权所有 (c) 2023 IETF Trust 和文档作者。 保留所有权利。¶

本文档受本文档发布之日生效的 BCP 78 和 IETF Trust 与 IETF 文件相关的法律规定 (https://trustee.ietf.org/license-info) 的约束。 请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。 从本文档中提取的代码组件必须包括《信托法律条款》第 4.e 节中所述的修订版 BSD 许可证文本，并且在提供时不提供修订版 BSD 许可证中所述的保证。¶

目录

1. 简介

本规范描述了一种可互操作的正则表达式（缩写为“regexp”）风格，I-Regexp。¶

I-Regexp 不提供高级正则表达式功能，例如捕获组、前瞻或反向引用。 它仅支持布尔匹配功能，即测试给定的正则表达式是否与给定的文本片段匹配。¶

I-Regexp 支持整个 Unicode 字符库（Unicode 标量值）； I-Regexp 字符串本身以及它们匹配的字符串都是 Unicode 标量值序列（通常以 UTF-8 编码形式 [STD63] 表示以进行交换）。 ¶

I-Regexp 是 XML 架构定义 (XSD) 正则表达式 [XSD-2] 的子集。¶

本文档包含有关转换 I-Regexp 以便与多种众所周知的正则表达式习惯用法一起使用的指南。¶

I-Regexp 的开发是由 JSONPath 工作组 (WG) 的工作推动的。 工作组希望在其规范 [JSONPATH-BASE] 中包含对在 JSONPath 过滤器中使用正则表达式的支持，但无法找到有用的正则表达式规范可以在流行的库之间进行互操作。¶

2. 目标

I-Regexps 应该能够处理数据模型规范或查询语言表达式中需要匹配正则表达式的绝大多数实际情况。¶

在撰写本文时，本文档的编辑对最近发布的 RFC 中使用的正则表达式语法进行了调查。 在那里找到的所有示例都应该由 I-Regexps 涵盖，无论是在语法上还是在其预期语义上。 例外情况是使用多字符转义，第 5 节中提供了解决方法指南。¶

3. I-正则表达式语法

I-Regexp 必须符合图 1 中的 ABNF 规范。¶

i-regexp = branch *( "|" branch )
branch = *piece
piece = atom [ quantifier ]
quantifier = ( "*" / "+" / "?" ) / range-quantifier
range-quantifier = "{" QuantExact [ "," [ QuantExact ] ] "}"
QuantExact = 1*%x30-39 ; '0'-'9'

atom = NormalChar / charClass / ( "(" i-regexp ")" )
NormalChar = ( %x00-27 / "," / "-" / %x2F-3E ; '/'-'>'
 / %x40-5A ; '@'-'Z'
 / %x5E-7A ; '^'-'z'
 / %x7E-D7FF ; skip surrogate code points
 / %xE000-10FFFF )
charClass = "." / SingleCharEsc / charClassEsc / charClassExpr
SingleCharEsc = "\" ( %x28-2B ; '('-'+'
 / "-" / "." / "?" / %x5B-5E ; '['-'^'
 / %s"n" / %s"r" / %s"t" / %x7B-7D ; '{'-'}'
 )
charClassEsc = catEsc / complEsc
charClassExpr = "[" [ "^" ] ( "-" / CCE1 ) *CCE1 [ "-" ] "]"
CCE1 = ( CCchar [ "-" CCchar ] ) / charClassEsc
CCchar = ( %x00-2C / %x2E-5A ; '.'-'Z'
 / %x5E-D7FF ; skip surrogate code points
 / %xE000-10FFFF ) / SingleCharEsc
catEsc = %s"\p{" charProp "}"
complEsc = %s"\P{" charProp "}"
charProp = IsCategory
IsCategory = Letters / Marks / Numbers / Punctuation / Separators /
    Symbols / Others
Letters = %s"L" [ ( %s"l" / %s"m" / %s"o" / %s"t" / %s"u" ) ]
Marks = %s"M" [ ( %s"c" / %s"e" / %s"n" ) ]
Numbers = %s"N" [ ( %s"d" / %s"l" / %s"o" ) ]
Punctuation = %s"P" [ ( %x63-66 ; 'c'-'f'
 / %s"i" / %s"o" / %s"s" ) ]
Separators = %s"Z" [ ( %s"l" / %s"p" / %s"s" ) ]
Symbols = %s"S" [ ( %s"c" / %s"k" / %s"m" / %s"o" ) ]
Others = %s"C" [ ( %s"c" / %s"f" / %s"n" / %s"o" ) ]

作为附加限制，charClassExpr 不允许匹配 [^]，根据此语法，它将解析为包含单个字符 的正字符类^.¶

这本质上是一个 XSD 正则表达式，没有：¶

• 字符类减法，¶
• 多字符转义，例如 \s、\S 和 \w 和 ¶
• Unicode 块。¶

I-Regexp 实现必须是这个有限子集的完整实现。 特别是，需要完全支持本规范中定义的 Unicode 功能。 实现：¶

• 不得将自身限制为 7 位或 8 位字符集，例如 ASCII，并且¶
• 必须支持字符类中的 Unicode 字符属性集。¶

4. I-正则表达式语义

此语法是 [XSD-2] 语法的子集。 解释 I-Regexps 必须 的实现会产生 [XSD-2] 中指定的布尔结果。 （另请参阅第 5.2 节。）¶

5. 将 I-Regexp 映射到 Regexp 方言

本节中的材料不是规范性的；它为想要在其他正则表达式方言上下文中使用 I-Regexps 的开发人员提供指导。¶

6. 动机和背景

虽然正则表达式最初旨在描述支持布尔匹配函数的形式语言，但它们已通过支持提取和替换匹配文本的任意部分的解析函数得到增强。 随着功能的增加，解析正则表达式库变得更容易出现错误和令人惊讶的性能下降，控制提交处理的正则表达式的攻击者可以在拒绝服务攻击中利用这些错误和性能下降。 I-Regexp 旨在提供互操作性并且不易受到此类攻击，但其唯一功能是提供关于字符序列是否与正则表达式匹配的布尔响应。¶

7. IANA 注意事项

本文档没有 IANA 操作。¶

8. 安全注意事项

虽然技术上超出了本规范的范围，但 RFC 3629 [STD63 的 10 部分(“安全注意事项”) ] 适用于实现。 Particular note needs to be taken of the last paragraph of Section 3 ("UTF-8 definition" ) of RFC 3629 [STD63]; an I-Regexp implementation may need to mitigate limitations of the platform implementation in this regard.¶

正如第 6 节中所讨论的，更复杂的正则表达式库可能包含可利用的错误，这可能导致崩溃和远程代码执行。 There is also the problem that such libraries often have performance characteristics that are hard to predict, leading to attacks that overload an implementation by matching against an expensive attacker-controlled regexp.¶

I-Regexp 的设计允许以能够抵御这两种威胁的方式实施；需要在整个实施工作中实现这一目标。 非检查实现（参见第 3.1 节)可能会暴露其使用的任何正则表达式引擎的安全限制，如果该引擎在构建时考虑到了安全性（例如，[RE2])。 无论如何，检查实现仍然是推荐。¶

专门实现 I-Regexp 子集的实现可以谨慎地设计为通常在输入中的线性时间和空间中运行，并检测何时不会出现这种情况（见下文）。¶

现有的正则表达式引擎应该能够轻松处理大多数 I-Regexp（在第 5 节中讨论的调整之后），但可能会为某些类型的 I-Regexp 消耗过多的资源或完全拒绝它们，因为它们无法保证高效执行。 （请注意，在这些情况下，同一正则表达式库的不同版本可能或多或少容易受到过度资源消耗的影响。）¶

具体来说，范围量词（如a{2,4})给现有的和以 I-Regexp 为中心的实现带来了特殊的挑战。 因此，实现可能会限制范围量词的可组合性（不允许嵌套范围量词，例如 (a{2,4}){2,4})或范围（不允许非常大的范围，例如 a{ 20,200000})，或者检测并拒绝由范围量词引起的任何过度资源消耗。¶

在这些情况下，用于评估来自不受信任来源的正则表达式的 I-Regexp 实现需要具有鲁棒性。 鼓励实施者使用现有的正则表达式库：¶

• 检查他们的文档以查看缓解措施是否可配置，例如资源消耗限制，以及¶
• 记录他们自己因采用此类缓解措施而产生的稳健程度。¶

致谢

IETF JSONPATH WG 中关于是否将 regexp 机制纳入 JSONPath 查询表达式规范的讨论以及之前关于 YANG pattern 和简洁数据定义语言 (CDDL) .regexp 的讨论特性激发了此规范。¶

此规范的基本方法受到“I-JSON 消息格式”的启发[RFC7493]。¶

作者地址