71 个版本

0.8.4 2024年6月9日
0.8.3 2024年3月26日
0.8.2 2023年10月14日
0.7.4 2023年7月11日
0.2.1 2015年7月21日

文本处理 类别中排名 23

Download history 3651818/week @ 2024-05-03 3739369/week @ 2024-05-10 3799595/week @ 2024-05-17 3642243/week @ 2024-05-24 3941946/week @ 2024-05-31 4158464/week @ 2024-06-07 4048602/week @ 2024-06-14 4144066/week @ 2024-06-21 3683148/week @ 2024-06-28 3934116/week @ 2024-07-05 4032028/week @ 2024-07-12 4133462/week @ 2024-07-19 4123534/week @ 2024-07-26 4199401/week @ 2024-08-02 4522438/week @ 2024-08-09 4468544/week @ 2024-08-16

每月下载量 18,099,138
43,365 个crate中(144个直接使用)中被使用

MIT/Apache 许可

1.5MB
49K SLoC

regex-syntax

此crate提供了一个健壮的正则表达式解析器。

Build status Crates.io

文档

https://docs.rs/regex-syntax

概述

此crate导出两种主要类型:`Ast` 和 `Hir`。前者是正则表达式的忠实抽象语法,可以在很大程度上保留其原始形式的同时将正则表达式转换回其具体语法。后者是正则表达式的高级中间表示形式,便于分析和编译成字节码或自动机。`Hir` 通过极大地简化正则表达式的语法结构来实现这一点。虽然可以将 `Hir` 转换回其等价的具体语法,但结果很可能与生成 `Hir` 的原始具体语法不相似。

示例

此示例展示了如何将模式字符串解析为其HIR

use regex_syntax::{hir::Hir, parse};

let hir = parse("a|b").unwrap();
assert_eq!(hir, Hir::alternation(vec![
    Hir::literal("a".as_bytes()),
    Hir::literal("b".as_bytes()),
]));

安全性

此crate没有使用 unsafe 代码,并设置了 forbid(unsafe_code)。虽然这个crate将来可能会使用 unsafe 代码,但这样做的要求非常高。一般来说,此crate中的大多数代码都不是性能关键代码,因为它们通常在将正则表达式编译成自动机所需的时间内显得微不足道。因此,几乎没有必要进行极端优化,因此很少使用 unsafe

在这个crate中使用unsafe的标准非常严格,因为这个crate旨在与用户提供的正则表达式一起使用时具有一定的安全性。因此,尽管正则表达式解析器本身可能存在错误,但除非编译器或标准库存在错误,否则这些错误绝不应该导致内存不安全。 (因为regex-syntax没有依赖项。)

crate功能

默认情况下,这个crate捆绑了大量Unicode数据表(源大小约为750KB)。由于它们体积庞大,可以禁用其中的一些或全部数据表。如果正则表达式尝试使用不可用的Unicode数据,则在将Ast转换为Hir时将发生错误。

可以禁用的全部功能都在文档的“crate功能”部分

测试

只需运行cargo test即可获得非常好的覆盖率。然而,由于这个crate暴露了大量的功能,这个目录中包含了一个测试脚本,该脚本将测试几个功能组合。这与CI中运行的脚本相同。

动机

这个crate的主要目的是提供regex使用的解析器。具体来说,这个crate被视为regex的实现细节,主要是为了满足regex的需求而开发的。

由于这个crate是regex的实现细节,它可能会以与regex不同的频率经历破坏性更改的发布。之所以可能,是因为这个crate不是regex的公共依赖项。

这种解耦的另一个后果是,没有直接从regex::Regex编译regex_syntax::hir::Hir的方法。相反,必须首先将Hir转换为字符串(通过其std::fmt::Display),然后通过Regex::new来编译它。虽然这会重复一些工作,但编译通常比解析要慢得多。

换句话说,regexregex-syntax之间的耦合仅存在于具体语法层面。

依赖项