★ FEATURED ARTICLE 前阵子整理工作目录我发现自己一年里居然攒了三十多个文本处理脚本有的是从日志里拽出接口耗时有的是把抓回来的 HTML 片段整理成表格有的是把批量导出文件里的脏字段洗一遍。这些脚本功能高度重叠但每次来了新需求我还是得重新翻正则、改编码、处理输出格式整个流程重复得让人烦躁。后来我把它们全部收编成了一个命令行小工具名字就叫 rea。全称不复杂就是 Regular Expression Assistant说白了一句话把“从非结构化文本里抽取结构化数据”这件事从每次手写脚本变成一份可复用的规则文件。rea 解决的问题很聚焦杂乱文本太多人工处理太慢手写脚本又难维护。它适合后端开发、数据分析、运维和测试同学尤其是那些每天要跟日志、导出报表、接口原始数据打交道的场景。这篇文章我会把 rea 的设计思路、规则写法、完整实操过程和踩过的坑全部写出来内容偏实战尽量把每一步为什么这么做也讲清楚保证看完你也能在自己的机器上直接上手把一类重复劳动收敛成一个命令。1. 为什么要把文本抽取单独做成工具1.1 重复脚本带来的真实痛点我之前那三十多个脚本不是一次写出来的是需求一个一个攒出来的。每次要做数据抽取流程几乎一样读文件、判断编码、写正则、遍历匹配、处理异常、写 CSV 或 JSON。这些东西说难不难但架不住频繁重复。最大的问题不是写起来费劲而是维护起来非常恶心。业务解析逻辑和文件处理代码混在一起改一个字段的正则可能要翻遍整个脚本去找对应的循环和输出列。时间一长连我自己都不确定某个脚本里的replace到底是处理什么脏数据的。而且这些规则完全没法跨项目复用A 项目抽日志的正则B 项目要用只能复制粘贴再改半天。另一个痛点是稳定性。手写脚本处理几万行文本没问题但一旦文件到了 GB 级别内存就顶不住了。有的脚本用readlines()一次性加载日志文件一大直接内存报警。输出格式也不统一有的脚本写 CSV 用逗号分割但字段里又带逗号导到表格软件里就错位又得补一层引号转义。1.2 rea 的定位和边界rea 不是一个大而全的数据处理框架它只做一件事情把“从非结构化文本到结构化数据”这一段单独拎出来做成一个可复用的命令行工具。它接受任意文本文件通过你定义的规则抽取字段然后输出成 JSON、CSV 或者 Excel。规则文件独立于业务代码存在想改解析逻辑不需要动任何程序代码只需要改规则描述。这也是我设计它时最核心的一个思路解析规则和数据消费逻辑必须解耦。边界也很清楚rea 不负责复杂的业务转换比如根据某个字段查库、调用外部接口、做关联分析这些应该由后续的脚本或数据分析工具完成。rea 只负责把文本里你需要的信息干净、准确、批量地取出来这一步做稳了后面所有环节都轻松。1.3 对比手写脚本、在线工具和 rea很多人会问我自己写 Python 脚本不就行了吗干嘛还要专门用 rea 这类工具。我列过一张对比表把常见的三种方案放在一起看选型逻辑就很清楚了。对比维度手写脚本在线正则工具rea上手成本需要写代码极低低写规则文件即可规则复用性差散落在脚本里无好规则文件可保存复用批量处理看实现水平差通常只测样本内置流式读取与批量输出编码处理每次手写不涉及内置编码声明与自动转换输出格式需要另写逻辑无内置 JSON/CSV/Excel可维护性差无规则集中管理易 review我并不是说手写脚本没用它更灵活适合一次性复杂任务。但如果你发现自己一个月内三次写了功能类似的抽取逻辑那就是时候把这层规则抽出来了。在线工具适合临时验证单条正则但它不解决批量处理问题也不解决数据落盘问题。rea 就是把在线正则工具的那套即时反馈和脚本的批量能力结合到一起同时把规则独立成文件。2. 核心设计规则文件、字段类型与处理流水线2.1 规则文件长什么样rea 的规则文件用 YAML 来写我觉得 YAML 比 JSON 更适合做这件事原因有两个一是可以写注释正则这玩意儿过一个月再看基本就是天书规则旁边必须记录示例行和字段含义二是结构缩进清晰层级关系一眼就能看懂。一份最基础的规则文件大概长这样rules: access_log: pattern: (?Pip[\d.]) - - \[(?Ptime.*?)\] (?Pmethod\w) (?Ppath.*?) HTTP/\d\.\d (?Pstatus\d{3}) (?Pbytes\d) (?Pduration[\d.]) fields: time: type: datetime format: %d/%b/%Y:%H:%M:%S %z method: string status: int bytes: int duration: floatpattern是核心用命名分组提取感兴趣的内容。这里有个经验正则里能不用.*就不用尤其是后面还要跟其他内容时.*很容易产生灾难性回溯。能用[^]*就绝对不用.*这不是洁癖是实用性考量后面我会专门讲性能问题。fields里声明每个字段的期望类型。这里我见过很多人一开始不理解为什么要声明类型反正抽出来的都是字符串直接写文件不行吗这就引出了下一点。2.2 字段类型声明为什么重要如果所有抽取结果都按字符串处理传到下游之后所有类型转换压力就全堆积到了消费端。你想做状态码分布统计发现status是字符串每次都要int(x)你想按时间排序发现time格式不统一还得自己解析。rea 的字段类型声明就是要把这层转换提前到抽取阶段完成。目前内置了几种常用类型string默认类型保留原始字符串不做任何转换。int自动去掉千分位逗号和空白字符转成整数转换失败时输出null。float同理处理小数和科学计数法。datetime配合format字段解析时间字符串输出 ISO 标准时间格式方便后续排序和建索引。bool识别true/false/yes/no/on/off/1/0等常见写法统一成布尔值。json若某个字段抽取出来的内容本身是 JSON 字符串直接反序列化成结构化对象最后输出时保留嵌套结构。这里我加了一个很实用的设计字段支持default参数。比如日志里某些行没有duration字段你想给它一个默认值 0直接在规则里写default: 0就行不用在业务代码里补逻辑。2.3 内置预处理步骤正则抽出来的内容经常带着多余的空格、引号、HTML 实体等这些脏东西如果留到下游处理会很烦。rea 内置了几个常见的预处理步骤可以在字段声明里开启。最常用的是trim去掉首尾空白。其次是normalize_whitespace把字段内部连续多个空格压缩成一个。我处理爬虫数据时经常需要html_unescape它能把amp;、lt;这类实体转回正常字符。预处理步骤是按顺序执行的先做 trim再 normalize再 html_unescape。我设计的原则是这些操作必须幂等也就是说对已处理过的数据再跑一遍不会产生新变化这样即使规则被重复执行结果也是稳定的。2.4 支持多行匹配与上下文字段单行文本是最常见的情况但真实世界不是所有日志都是一行一条。异常堆栈就是典型的多行结构异常类型可能在开头一行堆栈细节在后面好几行里。rea 对这种情况提供了multiline模式。开启后规则会从当前行开始按pattern中设置的跨行匹配去吞并后续行直到匹配结束。这个功能非常耗内存所以默认关闭。我的建议是能用单行拆分解决的问题就尽量用单行多行模式只在抽异常堆栈这类场景使用而且要控制单次匹配的行数上限。另一个比较实用的功能是上下文字段捕获。有的文本里某些信息不在当前匹配行内而在它前面几行。rea 支持在一个规则里定义context_before和context_after两个子规则分别在前 N 行和后 N 行里做额外匹配把结果合并到当前记录里。这个设计解决了我实际遇到的一个场景每一条业务日志后面跟着一行线程名和耗时但这两类信息在物理上并不在同一行把它们合并成一条记录后后续统计就方便多了。3. 实操全过程把 Web 访问日志转成统计表3.1 准备样本数据和需求拆解我先拿实际工作中最常见的 Web 访问日志来演示完整流程。日志格式如下192.168.1.18 - - [12/Nov/2024:14:23:11 0800] GET /api/user/info?id1001 HTTP/1.1 200 523 0.034 - Mozilla/5.0 192.168.1.31 - - [12/Nov/2024:14:23:15 0800] POST /api/order/submit HTTP/1.1 201 128 0.212 - Mozilla/5.0 192.168.1.22 - - [12/Nov/2024:14:23:19 0800] GET /api/cart/list HTTP/1.1 200 1024 0.018 - Mozilla/5.0需求很典型按状态码统计请求量按接口路径统计平均耗时找出耗时超过 200ms 的慢请求。拆解一下我需要从每一行日志里抽出来六个信息客户端 IP、访问时间、HTTP 方法、请求路径、状态码、响应大小、耗时。3.2 编写规则文件对应需求规则文件写起来是这样的rules: web_access: pattern: (?Pip[\d.]) - - \[(?Ptime[^\]])\] (?Pmethod[A-Z]) (?Ppath[^]*?) HTTP/\d\.\d (?Pstatus\d{3}) (?Pbytes\d) (?Pduration[\d.]) fields: ip: string time: type: datetime format: %d/%b/%Y:%H:%M:%S %z method: string path: string status: int bytes: int duration: float这里有几个细节值得展开讲。第一路径里用了[^]*?而不是.*?。因为在访问日志里方法名、路径和协议版本都在一对引号内路径内部不会出现引号用排除引号的字符集既准确又避免了回溯风险。如果路径里可能包含引号转义那是另一种业务场景应该用更复杂的解码规则而不是无脑用.*。第二时间字段必须显式声明datetime类型并给出format。%d是两位日期%b是英文缩写月份%Y是四位年份%z是时区偏移量。如果不给格式rea 无法自动推断出这种自定义的时间表达方式。第三我故意没在规则里声明ua字段。虽然日志末尾有 User-Agent但当前需求不需要它抽出来只会增加输出体积。规则只声明你关心的字段这也是保持输出干净的原则。3.3 命令行执行与参数选择规则文件保存为web_access.yaml后执行命令如下rea parse -r web_access.yaml -i access.log -o access_result.csv --format csv各个参数的含义-r指定规则文件路径也支持多个规则文件合并解析。-i指定输入文件若不填默认读取标准输入这样可以接管道处理。-o指定输出文件不填时结果直接打到标准输出便于快速查看。--format指定输出格式支持csv、json、excel。执行过程中 rea 会实时打印进度信息已处理行数、匹配成功数、匹配失败数。这里有一个我很喜欢的设计进度信息走标准错误输出而真正的结果数据走标准输出互不干扰。也就是说哪怕你不把结果写到文件也可以放心地用rea parse -r rule.yaml -i input.log --format json | jq .这样的管道方式把结果交给其他工具。如果日志文件不是 UTF-8 编码比如老系统常见的 GBK 编码日志要用--encoding gbk来指定避免中文乱码。3.4 结果确认与后续统计分析执行完成后生成的 CSV 文件大概是这个样子ip,time,method,path,status,bytes,duration 192.168.1.18,2024-11-12T14:23:1108:00,GET,/api/user/info,200,523,0.034 192.168.1.31,2024-11-12T14:23:1508:00,POST,/api/order/submit,201,128,0.212 192.168.1.22,2024-11-12T14:23:1908:00,GET,/api/cart/list,200,1024,0.018注意到时间字段已经被统一成了 ISO 8601 格式这个格式的最大好处是排序、去重、入库都不需要二次解析。状态码和耗时也已经是数字类型了表格软件可以直接求和、求平均、做筛选。到这一步rea 的任务就完成了。后面的统计我一般直接用表格软件做透视表或者用几行 Python 的pandas读 CSV 做聚合不再让 rea 承担业务分析的工作。rea 本身也带了一个rea stats子命令可以做简单的按字段分组计数比如统计状态码分布rea stats -i access_result.csv -g status -m count但它只做基础聚合复杂分析还是交给专业工具更顺手。把抽取和统计分开各自做精是我在实践中很坚持的一个原则。4. 常见问题与排查技巧实录4.1 匹配不到任何内容时按这个顺序排查这是使用 rea 频率最高的一个排查场景。明明在在线工具里验证过正则没问题一到 rea 就跑不出结果一般有四个原因。第一个是 YAML 转义问题。YAML 单引号字符串里反斜杠会被保留但如果你用了双引号包裹正则\d这类写法可能被 YAML 解释成转义序列直接报错或者匹配失败。我的建议是正则里所有反斜杠都按原始字符处理规则文件统一用单引号或者块标量来写。第二个是编码问题。日志文件如果是 GBK 编码rea 默认按 UTF-8 读取解析出来的内容自然不对。排查时先确认文件编码然后显式传--encoding参数不要靠猜。第三个是默认模式限制。rea 默认逐行处理输入每行独立匹配。如果你的目标内容跨行了需要开启multiline模式否则跨行部分永远匹配不到。第四个是分组名写错。命名分组(?Pname...)的名称在 fields 声明里必须完全一致大小写敏感。我犯过一次错规则里写的(?PStatus...)字段里写的是status结果那个字段全部为空。我还在 rea 里加了一个--debug参数开启后会打印每条输入样本的前 200 字符和对应正则的匹配结果。排查疑难杂症时这个参数很有用能直接看出输入数据是不是和预期的一致比如日志里有时候藏着不可见字符肉眼根本发现不了。4.2 字段变成 null 的隐藏原因匹配成功但某个字段输出null是第二个高频问题。这种情况通常是类型转换失败导致的。比如状态码字段声明为int但抽取到的内容里夹杂了引号或者空格rea 在转换时就会返回null。日志里偶尔会出现-这种占位符而不是真实数字最常见的就是请求耗时字段当请求失败时日志里不会记录耗时而是写一个-。解决方案有两种。第一种是声明defaultduration: type: float default: 0这样转换失败时就会使用默认值 0而不是null。第二种是想保留失败痕迹就把类型改成string让下游去判断这个-的含义。这里我要强调一个设计理念抽取工具不该静默丢弃异常数据。rea 默认会在转换失败时记录一条日志说明是哪一行、哪个字段、转换失败的原因。如果失败行数太多还会生成一个.err文件把原始行内容存档方便回头分析。数据清理这件事最怕的就是丢数据丢得悄无声息最终统计结果对不上才发现源头已经找不回来了。4.3 大文件处理的内存控制文本处理工具最容易踩的坑就是一次性把整个文件读进内存。rea 的读取模块默认是按固定缓冲区大小流式读取的不管文件多大内存占用都保持在一个稳定水平不会因为文件翻倍就内存翻倍。真正容易出问题的是multiline模式。因为跨行匹配必须在内存里维护一个待匹配窗口如果规则里设置了过长的行数范围窗口内数据会非常大。我踩过的一个实际场景是分析一个包含完整 SQL 日志的文件每条 SQL 可能横跨上百行我一开始在规则里设置了context_before: 100结果单条记录的内存占用直接飙到几十 MB。后来我把匹配方案改成了“先定位特征行再按需要往后吞行”避免一次性把前面几百行全部加载进来。所以处理大文件时我的建议是优先用单行模式迫不得已用多行模式时把跨行范围压缩到最小并且先用几百行的样本试跑观察内存占用情况再决定是否全量执行。如果你要处理的文件特别大比如几十 GB 的日志还有一个技巧先用系统命令做粗粒度过滤比如把包含ERROR的行先筛出来再对筛选结果执行 rea。过滤规则和抽取规则分开性能会好很多。4.4 输出中文乱码怎么破CSV 文件的中文乱码问题几乎是跨平台协作的经典难题。rea 默认输出的 CSV 是按 UTF-8 无 BOM 编码的这在 Linux 终端里完全没问题但如果你把文件用 Excel 打开经常会看到中文全部变成乱码。原因不是数据丢了而是 Windows 平台的老版本 Excel 默认用 GBK 编码打开 CSV 文件。解决方案是在输出 CSV 时加上 BOM 头rea 专门提供了一个参数rea parse -r rule.yaml -i input.log -o result.csv --format csv --csv-bom加上这个参数后CSV 文件开头会多两个字节的标记Excel 识别到 BOM 后会使用 UTF-8 解码中文就正常显示了。这个参数默认关闭是因为有些 Linux 工具对带 BOM 的文件反而会误判开头字段名我把选择权留给了使用者。如果输出的是 Excel 格式我直接让 rea 写入带有 BOM 的 UTF-8 内容规避了这个问题。Excel 格式底层也是多个 XML 文件打包编码声明处理好后跨平台打开都不会乱码。4.5 正则性能优化的一个真实案例正则性能问题不是玄学根源大多数时候都在回溯。我给 rea 内置了一个简易的性能自检功能会输出每一条规则的匹配耗时分布。实测中我发现用.*匹配日志里的一对引号之间的内容和处理一万行日志时明显比用[^]*慢不少差距能到几倍甚至更多日志里转义字符越多差距越明显。原因很简单.*是贪婪匹配会一直往前吞到行尾然后再逐步回退去找下一个匹配点如果后面还跟着其他通配符就可能产生指数级的回溯尝试次数。[^]*则明确告诉正则引擎到引号为止不要往前多看一个字符。所以我在规则编写规范里给自己定了几条铁律。能用字符集时绝不用任意字符能用非贪婪就用非贪婪能锚定开头就用^锚定。规则文件是给人看的正则的可读性和可维护性比炫技重要得多。每次写完正则我都会拿真实样本跑一遍--debug确认匹配分支没走偏再放进去做全量执行。4.6 常见问题速查表把刚才讲的内容整理成一张速查表遇到问题时可以直接对照。现象可能原因解决办法全部匹配不到文件编码不是 UTF-8指定--encoding gbk等参数全部匹配不到目标数据跨行开启multiline模式部分字段为 null字段类型转换失败设置default或改用string类型输出中文乱码CSV 缺少 BOM 标记加--csv-bom参数大文件处理很慢正则回溯严重把.*改为字符集排除写法规则验证通过但跑不出结果YAML 字符串转义问题统一用单引号或块标量写正则Excel 打开日期变成一串数字日期被当文本读用rea输出 Excel 格式或手动设列类型我个人实操中留下的三个习惯写规则时永远先拿一行真实数据试跑不要拿想象出来的格式写正则。真实数据里总有你想不到的空白字符、错位字段和异常占位符先跑通一个最小用例再扩展到全量文件能省下大量排查时间。规则文件里一定要写注释记录这份规则的适用样本和抽取意图。正则文件如果没有任何上下文说明三个月后你再看它就是一堆符号别人接手更是灾难。我在每个规则文件头部都会写清楚来源日志长什么样、哪些字段是关键、哪些异常值需要特殊处理这样维护成本能降下一大截。把抽取和统计分成两层rea 负责把文本变成干净、类型明确的表格统计交给专业工具去处理。你会发现一旦这层抽取逻辑稳定下来下游所有分析脚本都变得非常简单因为它们拿到的永远是规范数据。这也是我把 rea 从脚本堆里单独拎出来之后最大的收益。
阅读完成 · 觉得有帮助？
