HaE规则编写实战指南：5分钟写出第一条可用的正则提取规则
HaE规则编写实战指南：5分钟写出第一条可用的正则提取规则
【免费下载链接】HaEHaE - Highlighter and Extractor, Empower ethical hacker for efficient operations. 赋能白帽，高效作战！项目地址: https://gitcode.com/gh_mirrors/ha/HaE
这篇文章解决一个问题：你想在HaE里自定义"高亮和提取"逻辑，却不知道该往哪个字段填什么、填完为什么没效果。读完你能独立写出第一条可用的HaE规则，会用多分组模板做精确提取，知道匹配不到时先查哪里，最后还能把规则导出给团队复用。
看懂一条HaE规则长什么样
HaE的规则本质上就是四样东西：一段正则表达式、一个结果模板、一个高亮颜色、一个生效范围。它们写在YAML文件里（YAML是一种用缩进和冒号描述键值对的文本格式），按"组（Group）→ 规则（Info）"两级组织，字段定义在 Info.java 中。
最小可用的规则文件长这样：
rules: - name: "密钥提取组" rules: - enabled: true name: "AWS密钥检测" regex1: "AKIA[0-9A-Z]{16}" regex2: "" format: "AWS Key: {0}" color: "FF0000" scope: "response" engine: "dfa" sensitive: true每个字段用一句话说清楚：
| 字段 | 大白话解释 | 示例值 |
|---|---|---|
| enabled | 规则开关，false时整条规则不生效 | true |
| name | 规则名字，给队友看的标识 | "AWS密钥检测" |
| regex1 | 主正则，决定到底匹配什么内容 | "AKIA[0-9A-Z]{16}" |
| regex2 | 二次过滤，作用在regex1的匹配结果上 | "" |
| format | 结果展示模板，{0}代表匹配到的内容 | "AWS Key: {0}" |
| color | 高亮颜色，RGB十六进制 | "FF0000" |
| scope | 匹配范围：request / response / both | "response" |
| engine | 正则引擎：nfa或dfa | "dfa" |
| sensitive | 是否敏感信息，界面会做脱敏展示 | true |
两个概念先记住一句话版本：
- dfa引擎——匹配快、不支持回溯，适合简单模式的长文本。
- nfa引擎——支持回溯和复杂分组提取，适合嵌套结构。
你不需要背这些。先按上面的样子把一条规则写出来，跑通之后再回来对照字段表改参数。
第一条规则怎么写：从字段到保存
操作路径很短：在规则管理界面点"Add"，弹出编辑对话框后依次填名称、regex1、format、color，选scope和engine，勾sensitive，点"OK"保存。规则组的创建、重命名、删除都在 Rule.java 对应的管理界面里完成，一条组里可以挂多条规则。
动手前，常用的正则写法扫一眼即可：
| 写法 | 含义 | 例子 |
|---|---|---|
\d\w\s | 数字 / 字母数字下划线 / 空白字符 | \d{4}匹配4位数字 |
{n}{n,}{n,m} | 恰好n次 / 至少n次 / n到m次 | \d{2,4} |
.*? | 任意字符非贪婪，尽量少吃 | 标签内容提取常用 |
(a\|b) | 匹配a或b | (jpg\|png) |
颜色不用记全，给新手指一个团队常用的约定：
| 颜色 | 代码 | 建议用途 |
|---|---|---|
| 红 | FF0000 | 敏感信息 |
| 黄 | FFFF00 | 警告内容 |
| 橙 | FF9800 | 可疑内容 |
| 绿 | 00FF00 | 成功匹配 |
你可以这样操作：把上面文件里那条AWS规则原样填进对话框，regex1就是AKIA[0-9A-Z]{16}，format写AWS Key: {0}，scope选response，engine选dfa。填完别急着关窗口，先点"Test"按钮，用一段包含AKIA1234567890ABCDEF的文本验证能高亮，再保存。
让规则又快又准：多分组与引擎选择
想从一段内容里抠出两个字段，就在正则里打两个分组，然后在format里分别引用。比如提取URL参数名和参数值：
- enabled: true name: "URL参数提取" regex1: "(\w+)=(\w+)" regex2: "" format: "参数名: {0} 值: {1}"regex1命中user=admin时，{0} 是user，{1} 是admin，format把两者拼成你想要的展示文案。
regex2适合"先粗匹配、再细过滤"的套路：regex1先捞出一大块，regex2在它结果上二次提取。比如匹配<title>(.*?)</title>后，regex2写"$1"就能只取第一个分组的内容，format里再套一层文案。
引擎怎么选，看这个两行表：
| 引擎 | 特点 | 适用 |
|---|---|---|
| dfa | 快、不回溯、省内存 | 简单模式、大段文本 |
| nfa | 支持回溯、复杂分组 | 嵌套结构、需要捕获组 |
性能上记三条就够了：
- 能用
.*?就不用.*，减少回溯。 - 只关心响应体就别用both，scope收窄一半工作量。
- 一条规则做三件事，就拆成三条规则，好调试也好关闭。
正则匹配不到结果，先查这三处
规则"没反应"时，90%是下面三个原因之一，按顺序查：
- 查scope。最常见：你把规则配成response，却在请求里找内容，或者反过来。打开规则看scope字段，不确定就临时改成both验证，确认是这里的问题再改回。
- 查反斜杠转义。YAML里双引号字符串会吃一层转义，正则需要
\d时，YAML双引号里得写\\d，或者干脆把正则放进单引号里保持原样。这是新手匹配失败的第一大坑。 - 查正则本身和性能。把正则单独拿出来对着目标文本测一遍；如果文本很大还慢，多半是
.*加嵌套量词在疯狂回溯，改非贪婪、换dfa或拆分规则。
验证手段就在手边：编辑对话框里的"Test"按钮可以直接试匹配。规则真正的解析和执行发生在 RuleProcessor.java，排查疑难时翻这个文件看处理顺序最快。
规则如何沉淀给团队：导入导出与维护
规则文件就是YAML，天然适合团队共享：你导出整个文件发给同事，对方在自己的HaE里导入即可用，序列化逻辑同样在 RuleProcessor.java 的rulesFormatAndSave方法里。
维护上给三条约定，能省掉很多扯皮：
- 按业务分组。一个组对应一类目标，比如"云服务密钥""自定义协议解析"，组名即目录。
- 用enabled代替删除。过时的规则关开关保留，别直接删，方便回溯。
- 敏感规则必勾sensitive。标记后UI会脱敏展示，避免密钥类明文到处跑。
下一步行动：挑一个你最近还在手工翻找的数据（云密钥、内部ID、自定义协议字段都行），按本文写一条规则，用Test按钮验证后导出成YAML，发给一个同事导入试用。想从源码层面理解规则处理，可以克隆仓库阅读：
git clone --recurse-submodules https://gitcode.com/gh_mirrors/ha/HaE【免费下载链接】HaEHaE - Highlighter and Extractor, Empower ethical hacker for efficient operations. 赋能白帽，高效作战！项目地址: https://gitcode.com/gh_mirrors/ha/HaE
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考