正则表达式模式解释器和测试器技能

--- name: regex-pattern-explainer-and-tester description: 逐词解释Python正则表达式，在必须匹配和必须不匹配的样本上测试它们，包含匹配位置和命名组，并标记有风险的模式：导致灾难性回溯的嵌套量词、[A-z]、未转义的点号、空匹配和缺失锚点，然后提出更安全的改写方案。当用户询问“这个正则表达式是做什么的？”、“为什么它不匹配？”或“这个正则表达式安全吗？”时使用。包含一个经过测试的标准库Python检查器。 --- # 正则表达式解释器和测试器 你帮助人们理解、修复和信任正则表达式。你用通俗的语言解释模式，用真实的测试用例证明其行为，并找出导致正则表达式在生产环境中失败的问题：不应通过却通过的输入、应通过却不通过的输入，以及在长输入上挂起的模式。你返回修正后的模式和测试表，而不仅仅是意见。 ## 此技能中的文件 - `scripts/regex_check.py` - 从Python自身的正则表达式解析器解释模式，运行带有“+”（必须匹配）和“-”（必须不匹配）期望的样本输入，并报告高风险、警告和信息风险；`--probe` 在子进程中用生成的极端输入计时模式（仅使用Python 3标准库） - `references/regex-pitfalls.md` - 检查器报告的每个风险、其重要性以及应使用的安全模式 - `references/flavor-differences.md` - Python `re` 与JavaScript、PCRE、Go RE2、.NET、Java和POSIX grep的差异，以便修复在用户运行的环境中有效 - `templates/regex-review.md` - 要返回的审查报告 - `examples/example-email-validation-review.md` - 对在长输入上挂起的电子邮件检查的完整审查示例 ## 工作流程 ### 1. 收集事实 询问，或假设并说明： - 代码中完全按照原样书写的模式（原始字符串或转义字符串字面量）以及运行它的语言或工具。 - 它必须接受什么和必须拒绝什么：每种4到10个真实示例，包括边界情况（空输入、空格、Unicode、非常长的输入）。 - 它的使用方式：验证整个值（fullmatch）、查找第一个匹配（search）、提取所有匹配（findall）或替换。 - 输入来源。不可信输入（Web表单、日志、API负载）使灾难性回溯成为安全问题。 ### 2. 运行检查器 ```bash python3 scripts/regex_check.py '模式' -t '样本一' -t '样本二' python3 scripts/regex_check.py '模式' --cases cases.txt --mode fullmatch --flags a python3 scripts/regex_check.py '模式' --probe --no-explain # 确认回溯风险 python3 scripts/regex_check.py '模式' --cases - --json < cases.txt ``` 案例文件每行一个样本：`+ 文本` 必须匹配，`- 文本` 必须不匹配，`# ...` 是注释。在shell中始终用单引号引用模式。检查器使用Python的 `re`；对于其他风格，阅读 `references/flavor-differences.md` 并翻译结果。如果无法运行脚本，请手动用相同的结构解释模式，并应用 `references/regex-pitfalls.md`。 ### 3. 解释，然后修复 1. 用通俗的语言从上到下解释模式，每个标记或组一行，以检查器的解释为基础。 2. 显示测试表：每个样本、预期结果、实际结果以及匹配的文本或组。 3. 按此顺序修复：可能挂起的模式（高风险）、错误接受和错误拒绝（未通过的期望），然后是清晰度和信息注释。 4. 优先选择简单、可读的改写：一个重复而不是嵌套的重复，否定类如 `[^,]*` 而不是 `.*`，显式锚点 `\A...\Z` 或 `fullmatch`，以及长模式使用带注释的 `re.VERBOSE`。 5. 在修正后的模式上重新运行检查器，使用相同的案例加上任何新的边界情况，直到每个期望都通过且没有高风险。如果原始模式有高风险，则在修复上运行 `--probe`。 ### 4. 交付 填写 `templates/regex-review.md`：通俗语言解释、修复前后的测试表、发现的风险、用户语言中正确转义的修正模式，以及建议保留在测试套件中的简短测试用例列表。遵循 `examples/example-email-validation-review.md` 的风格。 ## 规则 - 除非在测试用例上展示，否则切勿声称模式是正确的；添加用户忘记的边界情况。 - 不要过度验证：对于电子邮件、URL和名称，建议简单的形状检查加上真实的验证步骤（发送电子邮件、解析URL），而不是巨大的模式。 - 保持用户的风格：不要建议其引擎不支持的后向断言、占有量词或原子组。 - 为目标语言正确转义（Python中的原始字符串，Java和C#字符串中的双反斜杠，JavaScript字面量中的斜杠）。 - 将不可信输入上的灾难性回溯视为安全漏洞（ReDoS）并明确说明；建议输入长度限制作为第二道防线。