Regex-LE

Regex-LE：轻松提取和验证正则表达式

查找、测试和验证当前文件中的正则表达式模式
字面量模式、RegExp 构造函数、ReDoS 筛查

觉得有用？ 点赞或评分能让其他开发者发现它 — ★ GitHub · ★ Open VSX · ★ Marketplace

功能介绍

打开任意文件并运行三条命令中的一条。提取会列出文档中找到的所有正则表达式模式。测试会针对文件内容运行找到的模式或手动输入的模式，并报告匹配项的实际行列位置和捕获组（包括命名组）。验证会检查所有找到的模式是否存在语法错误，并筛查灾难性回溯，同时报告导致问题的输入。适用于 VS Code 及基于 VS Code 的编辑器，例如 Cursor 和 VSCodium（可从 Open VSX 安装）。

安装

在 AI Agent 中使用

同一引擎也可作为 MCP 服务运行，因此 Agent 可以直接调用它，无需你运行命令。

extract_patterns(content, format?, filename?, maxResults?)

返回每个模式及其标志、从 1 开始的位置和 ReDoS 判定，因此“这个文件中的正则表达式有没有危险的？”只需调用一次，而不是两次。报告性能暴涨的判定会附带导致该问题的 witness，以便 Agent 验证发现，而不是盲目信任结果。

该服务接收内容并返回数据，不读取文件，也不会自行发起网络请求。它以 regex-le-mcp 的名称发布在 npm 上，并以 io.github.nolindnaidoo/regex-le 的名称收录于 MCP 注册表。

{
  "mcpServers": {
    "regex-le": {
      "command": "npx",
      "args": ["-y", "regex-le-mcp"]
    }
  }
}

npm install -g regex-le-mcp

{
  "mcpServers": {
    "regex-le": { "command": "regex-le-mcp" }
  }
}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y regex-le-mcp

提取时会扫描整个文档，因此跨行拆分的构造函数也会被找到。文档的语言决定了要查找哪些写法：

无法识别语言并不意味着拒绝处理 — 上面列出的所有写法都会被查找。指定语言可以提高准确性：Python 文件不会扫描裸 /…/，因此 #!/usr/bin/env python 不会被误读为模式。

以下内容不会被提取：

• 除法、日期和文件系统路径（a / b、10/29/2025、/usr/local/bin）：如果 / 前面是标识符、数字、)、]、. 或另一个 /，就不会将其视为正则表达式 — 但在 return 等关键字之后则会。只有在裸 /…/ 合法的地方才会判断这一点。
• 在上述任一语言中都不是格式正确的正则表达式，或标志无效／重复的候选项。其他语言的写法不算语法错误：re.compile(r'(?P<word>\w+)+@') 会按原样报告，并仍会被标记。
• 模式参数是变量，或包含 ${…} 替换的模板字面量的构造函数调用。字符串字面量、静态模板字面量和 String.raw`…` 都会被读取。
• JavaScript 字面量或构造函数以外的任何标志：其他语言都通过常量、构建器方法或内联的 (?i) 设置标志，而不是通过字符串参数设置。
• 注释或字符串中写的任何内容。 解释风险的 JSDoc 块、注释掉的代码行、包含示例的 Python 文档字符串 — 都不是代码；报告这些内容会因为一句话而导致构建失败。此规则关注的是候选项的起始位置，因此 re.compile(r"(a+)+b") 会保留其带引号的参数，而包含整行代码的文档字符串则是说明文字。只有在语言已知时才会应用此规则：如果无法识别文档语言，就会按原样扫描，因为根据错误语法猜测注释规则，会漏掉真实模式，而不是排除虚假模式。

重复的模式＋标志组合只会列出一次。这是启发式词法分析，并非九种语言的解析器：如果字符串中的斜杠看起来处于表达式上下文中，仍可能被识别出来。

ReDoS 筛查

Validate（以及在运行风险模式前使用的 Test）仅当找到能够明确证明会导致模式发生灾难性回溯的输入时才会报告，并会同时报告该输入，作为 witness。

系统不会运行你的模式，而是将其编译为自动机，并按照回溯引擎遍历模式的方式遍历自动机——采用深度优先搜索，按顺序遍历每条边，遇到死路就回溯，而不记录已遍历路径——同时统计步数。系统会构造攻击字符串，用两个长度进行扩展，并根据步数预算衡量结果。因此，检测结果可以证伪：运行该见证字符串并观察结果。

报告不会仅凭模式的形状来判断。形状在两个方向上都不是可靠的预测依据：^[a-z0-9]+(?:-[a-z0-9]+)*$ 看起来很危险，实际却不是，因为每次迭代都必须消耗一个内部字符类无法生成的 -；而 (.*a){20} 看起来有界，实际却不是。分隔符是否强制拆分是字符串本身的性质，因此仅检查语法无法得出结论。

没有报告不代表安全。 无法读取的模式——例如包含反向引用、环视或无法解析的语法——会返回 not decided: <reason>，而不是判定为安全。

报告还包含一个粗略的性能评分，根据执行时间相对于输入大小计算——请将其视为提示，而非基准测试（不测量内存）。

扫描文件夹或工作区

Extract 和 Validate 会读取当前打开的文档。两者也都提供一种表单，可从磁盘读取多个文件并生成一份报告。

• 整个工作区：从命令面板运行 Regex-LE: Extract Patterns from Workspace 或 Regex-LE: Validate Patterns in Workspace。
• 单个文件夹：在资源管理器中右键单击该文件夹，然后选择 Extract Patterns from Folder 或 Validate Patterns in Folder。在命令面板中运行相同的两个命令时，系统会提示你选择文件夹。

Extract

项目常会在多个位置写入同一个模式，因此报告会列出不同的模式及其所在位置，并按使用范围从广到窄排序：

# Regex-LE workspace report

`my-project` · 3 file(s) read · 3 distinct pattern(s) in 3 file(s)

| Pattern | Files |
|---|---|
| `/\d+/g` | 2 |
| `/\d+/` | 1 |
| `/^x$/` | 1 |

## `/\d+/g` (2)

- `src/a.ts` · **1:11**
- `src/b.ts` · **1:11**

## `/\d+/` (1)

- `src/c.py` · **2:5**

## `/^x$/` (1)

- `src/a.ts` · **2:11**

当两个模式的文本和标志相同时，它们才相同，因此 /\d+/g 和 /\d+/ 会分开列出。每个模式在每个文件中仅计数一次，位置取该文件中首次写入该模式的地方。

Validate

报告首先以表格列出包含待检查内容的文件，然后列出可能导致卡顿的模式：

# Regex-LE workspace report

`my-project` · 3 file(s) read · 5 pattern(s), 1 can hang, 1 not checked

| File | Patterns | Can hang | Not checked |
|---|---|---|---|
| `src/a.ts` | 2 | 1 | 0 |
| `src/b.py` | 2 | 0 | 1 |

> 1 other file(s) hold only patterns with no finding.

## `src/a.ts` (1)

- **2:14** · `/(a+)+$/` · can hang (high): exponential backtracking: 2000000 steps on 41 characters, against 229328 on 20 · complexity 0/100

可能导致卡顿表示找到了一种输入，会导致模式发生回溯；这与ReDoS 筛查中描述的搜索相同。未检查表示由于模式使用了反向引用或环视，搜索无法判断其情况。这不代表对模式作出任何结论，报告会说明原因。

为其他语言引擎编写的模式也会被读取，而不会被拒绝：Python 的 (?P<year>\d{4})、原子组或占有量词都会像其他模式一样接受搜索。

报告只会列出可能导致卡顿的模式。其余模式会按文件计数，而 regex-le.workspace.scanIncludePassing 会列出所有模式及其检测结果。regex-le.workspace.scanProblemsEnabled 还会将可能导致卡顿的模式放入“问题”面板，每项都是可点击的行。

扫描读取的内容。 提取器支持的九种语言的源文件：JavaScript、TypeScript、Python、Rust、Go、Java、Ruby、PHP 和 C#。其他文件会针对所有模式写法进行搜索，而 README 中的路径会被视为一个整体。scanPatterns 可以扩大扫描范围。文件从磁盘读取，因此不会包含未保存的编辑内容。超过安全大小的文件或非 UTF-8 文本文件将不会被读取。扫描最多处理 5,000 个文件或列出 10,000 个模式。报告末尾会为每个未纳入的项目附上一行说明，因此不会误把简短报告当成项目没有问题。

跳过的内容及如何更改。 默认启用三个开关，可以在设置中分别关闭：

两个列表可以调整结果，而无需关闭开关。若要跳过更多内容，请在 scanExcludes 中添加模式。若要读取某个开关会跳过的内容，请将其添加到 scanAlwaysInclude：

{
	// Also skip the test fixtures.
	"regex-le.workspace.scanExcludes": ["**/fixtures/**"],
	// Read the vendored code, though the built-in list skips it.
	"regex-le.workspace.scanAlwaysInclude": ["**/vendor/**"]
}

Regex-LE: Open Settings 会在“设置”编辑器中打开所有这些设置。

影响扫描的设置位于设置下。“位置”设置同样适用于扫描，与单文件命令的适用方式相同。

命令行工具

相同的 lint 也可以从终端或 Shell 管道运行：Rust 命令行工具位于 crate/，并与扩展共用同一语料库 — crate/fixtures/ — 因此两者读取文档的方式绝不会不同。同一命令行工具也以 regex-le 的形式发布在 npm 上，适用于安装了 Node 但未安装 Rust 的机器；CI 会在三种操作系统上逐字节确保它与 crate 一致。

regex-le .                      # every vulnerable pattern; JSON on stdout when piped
regex-le --severity high src/   # only the exponential shapes
regex-le --all src/             # every pattern, vulnerable or not
regex-le mcp                    # the same lint over MCP on stdio

从 npm (regex-le) 或 crates.io 安装 (regex-le)。两种方式都会安装同一个 regex-le 命令。

npm install -g regex-le   # or run it once: npx regex-le
cargo install regex-le

退出码：0 表示没有发现漏洞，1 表示至少有一项发现，2 表示问题格式错误 — 因此 regex-le . || exit 1 可用作 CI 门禁。

它移植的是 lint 部分，而不是测试器。 使用 JavaScript 语义对文本运行模式需要 JavaScript 引擎；如果只是做到近似正确，就会导致两个前端针对同一模式报告不同的匹配结果。测试属于编辑器中的操作；请在这里进行。lint 完全不需要引擎 — ReDoS 判定会在步数预算内遍历根据模式文本构建的自动机 — 因而可以成为一种轻量且确定性的 CI 步骤。

它会报告能够证明的内容，并且拒绝处理无法读取的内容，与此扩展中的筛查方式完全一致。

命令

默认情况下，没有命令绑定快捷键。你可以在编辑器的键盘快捷方式中为任意命令设置快捷键。

设置

语言

除英语外的十二种语言：

德语 · 西班牙语 · 法语 · 印度尼西亚语 · 意大利语 · 日语 · 韩语 · 葡萄牙语（巴西） · 俄语 · 乌克兰语 · 越南语 · 简体中文

两部分内容均已覆盖：清单（命令标题、设置名称和说明），以及扩展运行期间显示的所有内容（通知、状态栏、快速选择和提示词）。扩展会遵循 VS Code 的显示语言，因此会与编辑器当前设置的语言一致；无需单独设置。

隐私与安全

• 不访问网络。 此扩展绝不会向任何地方发送数据。telemetryEnabled 设置只会将事件写入可供你检查的本地输出通道（Regex-LE Telemetry）。
• ReDoS 界面将某个模式评为高严重性时，测试该模式前会先征求确认。
• MCP 服务同样恪守这条原则。 它将内容作为参数接收并返回数据：不访问文件系统、不发起网络调用、不收集遥测数据。你的 Agent 已有文件读取工具，因此在服务中重复实现这些功能只会带来路径遍历风险，却不会增加任何能力。如果服务导入了任何可能访问文件系统或网络的内容，check:mcp-bundle 就会使构建失败。
• 错误通知会隐藏主目录路径和类似凭据的片段。
• 评分提示最多出现两次。 第 3 次成功使用时，扩展会询问你是否愿意评分；如果你选择稍后或关闭提示，则会在第 20 次使用时再询问一次。选择不再询问后便不会再提示。自行将 notificationsLevel 设为 important 或 silent 也会关闭提示。计数保存在 VS Code 的扩展存储中，不会发送到任何地方；点击评分会在浏览器中打开你安装该扩展的平台页面——VS Code Marketplace 或 Open VSX。

文档

性能

数据为预热后运行 7 次的中位数，测试设备为 Apple M5 Pro，配备 24 GB RAM，运行 Node 24.3.0。输入由 scripts/benchmark.ts 生成，而非签入仓库，因此上面的大小与实际测量值完全一致。运行 bun run benchmark 即可复现。

这些数据因设备而异，不会在 CI 中作为断言——用基准测试决定是否允许构建，只能说明运行器当时有多忙。

测试

28 个文件共包含 401 个测试用例，另有一个在真实 VS Code 扩展宿主中运行的集成测试套件，以及一个将构建好的 .vsix 安装到干净配置中的端到端测试。

数据由 scripts/coverage-readme.js 根据真实运行结果 coverage/coverage-summary.json 和 coverage/test-results.json 生成；如果本节内容发生偏差，CI 会失败。运行 bun run test:coverage 即可复现；用例数量以 vitest 输出为准。

LE 系列的更多工具

为每个模型眼前的工作打造的 16 款单一用途工具。每款都附带一个 Rust CLI 和一个 MCP 服务。一页尽览：letools.dev

提取

• String-LE — 提取代码库中的所有字符串，方便人工阅读
• Numbers-LE — 提取代码库中所有硬编码数字，方便人工检查
• Units-LE — 提取所有带单位的数量并统一格式，遇到含义不明确的数量时会按名称拒绝处理
• Dates-LE — 提取所有日期和时间戳，并给出每个日期和时间戳解析出的确切时刻
• IDs-LE — 提取所有 UUID、ULID、NanoID、ObjectId 和 Snowflake，并解码其中的时间
• IPs-LE — 提取所有 IP 地址、CIDR 网段和 MAC 地址，统一格式并按范围分类
• URLs-LE — 提取代码库中的所有 URL，并给出协议和确切位置
• Paths-LE — 提取代码库中的所有文件路径，并说明它们是否仍指向实际内容
• Colors-LE — 提取代码库中的所有颜色，并指出哪些颜色不在你的调色板中

检查

• Regex-LE — 查找代码库中的所有正则表达式，并报告哪些可能导致灾难性回溯
• Versions-LE — 查找某个依赖项在仓库的各个清单文件中受到不同约束的位置
• i18n-LE — 识别项目使用的 i18n 库，然后依据该库的规则审查其目录
• Scrape-LE — 在编写抓取器之前检查网页能否抓取，并说明何时无法判断

防护

• Secrets-LE — 查找代码库中的硬编码凭据，绝不在报告中打印凭据
• EnvSync-LE — 比较目录树中的 dotenv 文件，并指出哪些文件缺少哪些键
• Unicode-LE — 查找那些隐藏含义的 Unicode 字符——双向控制字符、不可见字符、同形异义字符、混合文字系统

每款工具都独立运行：没有共享的 crate，也没有发布的核心库。若有两款工具得出相同结论，那是因为这个答案经得起两次验证。

联系 — nolindnaidoo.com · GitHub · LinkedIn

nolindnaidoo 的其他项目

Rust — pixelcoords 和 pixelactions 构成一个工作循环：pixelcoords 回答 位置，pixelactions 在那里执行操作。它们有各自的工具、各自的风格——不属于 LE 系列。

• pixelcoords — 冻结屏幕，标记区域，获取像素级精确的坐标和裁剪图像 pixelcoords.dev · crates.io · docs.rs
• pixelactions — 使用经过人工验证的坐标执行交互，并确认操作已生效 pixelactions.dev · crates.io · docs.rs

许可证

MIT © nolindnaidoo