从手机键盘到正则解析这条路我走了四年。最初只是想把旧诺基亚里几千条短信和备忘录导出来结果发现数据导出来是一堆编码错乱的文本流时间戳、号码、正文全搅在一起根本没有能直接用的结构化数据。折腾了无数个晚上之后我最终用一套正则解析方案把这些问题全部解决实现了个人数据的完全自由——所谓自由就是任何一条四年前的短信我都能在一秒之内检索到原文、时间、对方号码并且可以随时迁移格式不受任何旧设备、旧系统的约束。这篇文章就把我这四年的思路、踩过的坑、沉淀下来的脚本逻辑完整写出来。内容偏实操涉及手机端数据导出、编码转换、正则表达式设计、SQLite入库、性能优化这些环节适合手里有一堆旧手机数据想整理的人也适合刚开始学正则、想找一个真实项目练手的开发者。每个步骤我都会给出可复现的代码和参数依据照着做就能跑出自己的数据归档工具。1. 项目背景与整体思路1.1 数据自由的痛点你的手机数据其实是锁住的先说一个很多人没意识到的问题手机里的短信、通话记录、备忘录、日程看起来是你的数据实际上被锁在厂商的私有格式里。诺基亚当年的备份文件是.nbu、.vmg部分手机导出的文本又带着 BOM、UNICODE 编码头和 GSM 7-bit 压缩标记换个设备根本读不出来。我试过用官方PC套件导出一份短信备份结果出来是一个二进制块里面混杂着十六进制数和肉眼可读的中文碎片——那个瞬间我意识到想要真正拥有这些数据必须自己做一层解析转换。所谓CSD码说起来有点年代感。CSD全称是Circuit Switched Data也就是电路交换数据2G时代手机通过GSM网络拨号上网、传数据用的就是它。当时手机没有Wi-Fi电脑通过红外或者数据线连上手机拨一个特殊号码建立数据链路然后就能把手机里的短信、通讯录以字节流的方式拉出来。这层传输协议本身不关心内容格式所以导出来的文本质量取决于手机厂商怎么组织字节——有的用UTF-16LE加BOM有的用GBK有的是7-bit压缩编码这也就为后来的乱码问题埋下了伏笔。我手里这批数据是四年前从诺基亚E63和N73两台机器上导出的。一个用PC套件备份一个用第三方的短信导出工具全部导出之后得到的是两个不同编码、不同字段顺序的文本文件。加上当年我习惯用T9键盘写长短信和手机博客正文里混着表情符号、全角标点、旧式输入法产生的繁体异体字——这已经不是简单改改编码能解决的事情了必须写一套解析规则把这些乱七八糟的文本统一变成结构化记录。1.2 为什么选正则解析而不是写死脚本一开始我的想法很简单既然格式是固定的写一个按行分割、再按固定位置截取的脚本不就行了实际操作之后发现这条路走不通。原因在于手机上的导出文本存在大量可变因素。举几个例子短信号码有的带86有的不带有的存成纯数字有的带着联系人姓名比如张三(13800138000)正文可能只有一行也可能因为超长被拆成两三条记录时间戳在不同机型里分别是2021-08-15 14:23:05、15.08.21 14:23、20210815142305三种形态甚至有的记录里正文本身就包含换行符直接按行切就会把一条完整短信切成几段残片。面对这种情况写死偏移量的脚本需要为每一种变体写一套分支逻辑越写越复杂而且一旦出现新格式就得推翻重来。正则表达式的价值恰恰体现在这里它描述的是文本的形态而不是位置。我只需要定义一条短信记录 一个时间戳 一个号码字段 一段任意长度正文这个模式不管数据出现在第几行、前面有没有其他文字都能被精确匹配出来。相当于给解析器装了一双认形状的眼睛而不是一条量刻度的尺子。后面我会把完整的正则设计思路、匹配规则、边界处理全部展开这些内容配合源码看能帮你少走至少一年的弯路。2. 手机键盘数据的采集与预处理2.1 三种常见导出路径与各自的特点想做数据解析先得能拿到原始数据。根据我这四年的经验从旧手机往外导文本基本逃不出三条路第一官方PC套件备份。诺基亚的PC Suite、后来的Ovi Suite能把整机数据备份成一个大文件。优点是完整短信、通讯录、日历全在里面缺点是格式高度私有化备份文件内部是分层结构需要先拆包才能得到文本层。拆包本身又是一层解析等于在研究正则之前先得对付一个二进制容器格式。第二第三方短信导出工具。这类工具一般直接读取手机文件系统把短信库导出成.vmg、.csv或者纯文本。.vmg本质上是一种类邮件格式能用文本编辑器打开里面包含BEGIN:VMG、TEL:、DATE:这些标记行正文部分有的是明文有的是Base64编码。这种格式是我个人最喜欢的解析起点因为它至少是半结构化的正则写起来有据可依。第三手动复制粘贴。最原始但也最通用。当年手机还没有批量导出功能的时候我只能一条短信一条短信选中、复制、粘贴到记事本里。这种方式产生的数据最乱每条的格式完全取决于当时屏幕怎么显示换行、截断、省略号...全都可能出现。如果你手里只有这种手工数据集解析之前必须先做一轮比想象中更繁琐的清洗。我的建议是不管你最后选择哪条路导出的原始文件一定要以字节为单位原样保存两份一份放在电脑本地一份放网盘备份绝对不要在原始文件上直接改编码。解析脚本跑的永远是副本因为清洗过程中一旦发现规则设计错误还能回到原始数据重新匹配不至于反向污染唯一的数据源。2.2 PDU与中文短信的解码思路如果你导出的是老手机短信PDU模式解码这个环节绕不开。GSM短信在传输层有两种编码方式一种是文本模式Text Mode直接发送字符流另一种是PDU模式Protocol Data Unit把整条短信打包成一个十六进制字符串传输。当年国内手机几乎都是PDU模式所以导出的备份里能看到大片大片的十六进制数开头通常是0891683108201705F5这种。我踩过最大的坑是中文短信的编码。纯英文短信用的是GSM 7-bit压缩编码每个字符占7比特刚好把160字节挤下160个字符但中文属于UCS-2编码每个汉字占2字节所以一条短信最多70个汉字。解析PDU时必须先读取TP-UDL用户数据长度单位是字节然后根据编码方案DCSData Coding Scheme判断是7-bit、8-bit还是UCS-2再决定怎么解码。这里贴一段我当时写的PDU截取逻辑用来把短信正文从PDU串里剥出来def pdu_to_text(pdu_hex): # pdu_hex 是一串类似 0891683108201705F5240D916881... 的长十六进制字符串 # 1. 找到用户数据部分 ud_start pdu_hex.find(00) 2 # 简单做法找UDL字段 # 实际解析应按协议逐字段跳过 SMSC, PDU type, MR, DA, PID, DCS, SCTS dcs int(pdu_hex[offset:offset2], 16) data bytes.fromhex(pdu_hex[data_offset:]) if dcs 0x08: # UCS-2 编码中文短信 return data.decode(utf-16-be, errorsreplace) elif dcs 0x00: # 7-bit 编码 return decode_gsm7(data)正文解析出来之后你会发现短信文本里还藏着很多半可见字符比如替换符、零宽空格、软换行。这些字符在手机屏幕上显示正常但进入文本文件之后就是解析器的干扰项。所以解码完成后我还会再做一次字符标准化把全角空格转成半角、把软换行统一成\n、把零宽字符直接剔除。这一步不做后面正则写起来会非常痛苦。2.3 数据清洗清单拿到文本后先干这几件事在写任何正则之前我养成了一个固定习惯对原始文本做一轮基础清洗并且把每一步操作都记录在案。具体来说拿到一个导出文本文件我会按这个顺序处理第一判断字节序和编码。用chardet或者直接看文件头几个字节FF FE是UTF-16 LEFE FF是UTF-16 BEEF BB BF是UTF-8 BOM。老手机导出的文本大概率是UTF-16或者GBK直接按UTF-8读会全部变成乱码。我写过一个小工具挨个尝试utf-16、gbk、utf-8-sig、latin-1四种编码看哪种解码后汉字比例最高就认定哪种是源编码。第二统一换行符。Windows记事本导出的文件可能是\r\n老Unix工具导出的可能是\n某些功能机导出的甚至是\r单独换行。正则里的$和.在默认模式下对换行符的处理不同如果不统一匹配结果会时好时坏。我统一用text.replace(\r\n, \n).replace(\r, \n)处理。第三把非法字符替换成可识别占位符。这一步很多人忽略。老数据里经常有无法映射的字节转码失败时产生的直接删除会破坏字节对齐影响前后文判断。我自己的做法是先把它们替换成一个不会在正常短信中出现的占位符比如__BAD_BYTE__解析结束之后再用人工复核决定是保留还是剔除。这样能在清洗阶段保留信息直到最后一刻才做取舍。清洗完的数据会生成一个新文件文件名统一加_cleaned后缀。原始文件不动清洗脚本幂等可重复执行。这个过程虽然耗时但能极大降低后面正则匹配的容错负担——正则最怕的就是数据源里有意外清洗的次数越多意外就越少。3. 正则解析的核心设计与实现3.1 典型文本格式摸底我遇到的五种形态不同工具导出的数据格式差异很大格式摸底是写正则前最重要的一步。我把手机导出文本实际遇到的形态归类成五种下面列出特征和对应样例形态特征实际样例标记行式字段以KEY:开头正文是纯文本BEGIN:VMG、TEL:8613800138000、DATE:20210815T142305Z单行管道式字段间用 分隔时空和正文混杂多行缩进式时间占据一行后续行是正文直到空行结束第一行2021/8/15 14:23下面几行是内容遇到空行算一条记录结束对话式用冒号引入说话人消息层级靠缩进张三说: 明天几点到乱码混合式大量十六进制块夹杂可视片段0891683108201705F5...540029这种这五种形态对应的正则策略完全不同。标记行式最简单按KEY: VALUE的模式提取字段即可单行管道式需要防止正文中本身包含|号多行缩进式是真正考验正则跨行能力的情况必须启用re.DOTALL配合非贪婪量词。我当初的数据主要是标记行式和多行缩进式下面重点拆解这两种的解析逻辑。3.2 三段式正则时间戳、号码、正文的提取解析短信的核心就是把一条记录拆成时间、号码、正文三个字段。我的做法是写三个独立的子正则然后组合成一条总正则。这样每个子模块可以单独测试组合时也方便调整。时间戳子正则。手机导出的时间格式很难统一光是年份的写法就有2021、21两种月份有08、8两种。我写了一个既能匹配常见ISO格式、又能兼容旧式两位年格式的正则ts_pattern r(?Pts(?:19|20)\d{2}[-/.年]\d{1,2}[-/.月]\d{1,2}[日]?\s*\d{1,2}:\d{1,2}(?::\d{1,2})?|(?:\d{2})[-/.]\d{1,2}[-/.]\d{1,2}\s\d{1,2}:\d{1,2}(?::\d{1,2})?)注意这个正则用了[-/.年]这样的字符类意思是分隔符可以是横线、斜杠、点或者汉字年这是为了兼容不同机型导出的时间写法。实际解析时先跑这一条如果整段文本一个时间都匹配不到说明格式不在预设范围内这时候不要硬来先去数据里找实际的时间长什么样再反过来调整模式。号码子正则。手机号码的变体没有时间那么多但需要仔细处理国际前缀、分隔符、以及号码和姓名的混合形态。我最终用的版本是tel_pattern r(?Ptel(?:\?86[- ]?)?1[3-9]\d{9}|(?:\?\d{1,3}[- ]?)?\d{7,13}|[^:\s]{1,20}?[(]\d{5,13}[)])这个正则的第三个分支比较关键它能匹配张三(13800138000)这种姓名括号号码的格式。原理是先匹配一串非冒号非空格的字符姓名再匹配括号里至少5位数字号码。如果遇到86 138 0013 8000这种带空格分组的号码第二个分支里的[- ]?就派上了用场。正文子正则。正文是整个解析里最复杂的一块因为它消耗的字符是不定的可能只有几个字也可能长到几百字。我的策略是先匹配时间戳和号码把匹配到的位置前后的内容界定为正文而不是直接写一个正文模式。也就是说正文 上一条记录的结束位置到本条记录的开始位置之间夹着的所有文本。这种思路避免了对正文内容本身做假设只在记录边界处做文章。组合成一条总正则时我用了命名分组和re.VERBOSE模式可以加注释。核心结构是record_pattern re.compile(r ^ # 每条记录从一行的开头开始 %s # 时间戳 \s* (?:%s\s*)? # 号码可选带分组但不强制 :?[]?\s* (?Pbody.*?) # 正文非贪婪 (?\n # 换行后要么是下一条时间戳要么是文件结尾 (?: %s |\Z )) % (ts_pattern, tel_pattern, ts_pattern), re.VERBOSE | re.MULTILINE)这个正则有三个核心点第一用了re.MULTILINE模式让^匹配每一行的行首保证每条记录从行首开始对齐第二正文部分用.*?非贪婪匹配保证它不会横跨到下一条记录第三用向前断言(?...)来限定正文的结束位置——正文结束的位置必须是换行后紧跟一个时间戳或者文件结束。这种写法非常稳因为解析器不需要知道正文里有没有奇怪的字符只需要知道它在哪里停。3.3 边界情况折叠行、超长短信、符号转义理论正则写完真正磨人的是边界情况。我整理一下自己实际遇到过的问题和对应的处理方式折叠行。很多手机的导出工具会把长短信在固定长度处插入一个软换行然后下一行继续写。如果直接按我的总正则跑这段长短信会被误判成两条记录。解决方案是在数据清洗阶段把行尾没有句号、冒号、感叹号等结束符下一行又是半角字符开头的换行直接合并。我写了一个小函数def fix_wrapped_lines(text): lines text.split(\n) merged [] for line in lines: if merged and not line.startswith((20, 19, , TEL, BEGIN)) and not merged[-1][-1] in 。!?;: merged[-1] line else: merged.append(line) return \n.join(merged)这个逻辑的思想是手机上的软换行一般不会打断一个完整的句子所以通过上一行末尾符号 下一行开头特征来判断是否合并。实测下来对多行缩进式数据效果很好。超长短信。GSM协议规定一条短信最多70个汉字超过就要分多条发送。导出的备份里这种分条短信有时是合并成一条长文本有时是几条独立记录。如果你希望把分条合并成一条逻辑上的会话可以在解析结束后做一次后处理时间间隔小于5秒、号码相同、正文首尾衔接的多条记录合并成一条。我的判断条件是前一条正文末尾没有句号、后一条正文开头不是大写字母或数字。正则元字符转义。这个坑看似基础但四年里我至少踩过两次。手机短信正文里有时会出现{}、()、[]、、*、.这些字符而它们恰好都是正则元字符。使用re.escape()包裹用户输入、或者在写正则时给匹配正文的部分预留转义能力能避免大多数匹配失败。比如匹配含括号正文的时候我不会写.*直接吞掉括号而是先分析括号是否是成对出现的再用非贪婪匹配配合计数器来约束。异常字符的容忍策略。正则默认遇到无法匹配的字符会直接跳过整条记录这会导致数据丢失。我最后的方案是总正则匹配失败时用兜底正则(?Pts时间模式)(?Punknown[\s\S]*?)(?下一条时间)再抓一次把匹配到的内容标记为unknown字段留待人工检查。宁可多出未解析记录也不让一条数据静默消失。3.4 从解析结果到结构化字段的映射正则匹配出来的是文本组离结构化还有一步。我会把每个命名分组做后处理主要做三件事。第一时间字段标准化把2021/8/15 14:23转成datetime对象统一时区为东八区对只有日期没有时间的记录补上00:00:00。这个环节我会记录原始时间字符串方便日后回溯。第二号码字段归一化去掉所有空格、横线、括号统一成86开头的格式。如果号码字段里带姓名则拆成name和phone两个子字段。这里有一个细节86和0086在手机上显示一样但在数据库里是不同的字符串所以我会先做一层统一。第三正文字段做标签化渲染把[img]、:D、^_^这类旧式表情符号识别出来转译成自定义标签emoji...存储同时保留原始文本。这样后续做数据分析和可视化时表情符号不会干扰文本分类。这三个步骤看起来不起眼但决定了最终数据是能用的还是仅仅是文本。我的经验是结构化这一步永远不要省略因为你可以随时从结构化数据反推原始文本却很难从原始文本直接获得结构化信息。4. 实操过程解析脚本的完整实现4.1 第一步格式嗅探器自动识别数据源类型在正式解析之前我先写了一个格式嗅探器用来判断当前文件属于哪种形态。这一步非常重要因为四年里我陆续收集了七八种不同来源的文本文件每次都要人工判断格式再手动切换正则规则效率太低了。嗅探器的工作原理很简单读入文件前200行统计各种特征的出现次数。比如如果包含BEGIN:的行数超过10行判定为标记行式如果每行都出现|且能匹配时间戳判定为单行管道式如果前几行是时间、后几行是文本、中间有空行判定为多行缩进式。我把每种形态的概率权重存成字典最后输出最大概率的格式并附带一行预测说明。def sniff_format(text): lines text[:200].split(\n) score {vmsg: 0, pipe: 0, indent: 0, dialogue: 0} for line in lines: if line.startswith(BEGIN:) or line.startswith(TEL:) or END:VMG in line: score[vmsg] 3 if | in line and re.search(r\d{4}-\d{2}-\d{2}, line): score[pipe] 2 if re.match(r^\d{4}/\d{1,2}/\d{1,2}, line): score[indent] 2 if re.match(r^.{1,10}[说:], line): score[dialogue] 3 max_format max(score, keyscore.get) return max_format这个嗅探器虽然简单但是非常实用。它能直接避免拿A格式的正则去解析B格式的数据这种低级错误。后续如果你要支持更多类型只需要往评分函数里继续加特征分支即可。4.2 第二步核心解析脚本Python re核心解析脚本我贴一个简化但可运行的版本里面保留了我实际使用的关键逻辑。为了便于阅读我大幅删减了业务代码只保留结构import re import sqlite3 from datetime import datetime TS_PATTERN r(?Pts(?:19|20)\d{2}[-/.年]\d{1,2}[-/.月]\d{1,2}[日]?\s*\d{1,2}:\d{1,2}(?::\d{1,2})?) TEL_PATTERN r(?Ptel(?:\?86[- ]?)?1[3-9]\d{9}|(?:\?\d{1,3}[- ]?)?\d{7,13}) # 注意多行缩进式数据的正文匹配需要 DOTALL RECORD_RE re.compile( r^{ts}\s*(?:{tel}\s*)?:[:]?\s*(?Pbody.*?)(?\n(?:{ts}\s*|\Z)).format( tsTS_PATTERN, telTEL_PATTERN ), re.MULTILINE | re.DOTALL | re.VERBOSE, ) def parse_text(text): for match in RECORD_RE.finditer(text): ts_raw match.group(ts) tel_raw match.group(tel) or body match.group(body).strip() dt standardize_time(ts_raw) tel normalize_phone(tel_raw) yield {time: dt, phone: tel, body: body} def standardize_time(raw): # 按实际格式做转换这里只列两种 for fmt in (%Y-%m-%d %H:%M:%S, %Y/%m/%d %H:%M): try: return datetime.strptime(raw, fmt) except ValueError: continue return None def normalize_phone(raw): digits re.sub(r\D, , raw) if digits.startswith(86) and len(digits) 13: digits digits elif not digits.startswith(): digits 86 digits if len(digits) 11 else digits return digits # 入口 cleaned_text open(sms_cleaned.txt, encodingutf-8).read() records list(parse_text(cleaned_text)) print(f解析完成共 {len(records)} 条记录)这个脚本的核心不在代码量而在正则边界的设定。RECORD_RE用了re.DOTALL这样正文里的换行也能被.*?捕获前提是前面后向断言里的(?\n(?:时间戳|\Z))能正确识别记录边界。实际测试中这个正则对多行缩进式的准确率能到98%以上剩下2%基本是时间格式我还没见过的极端情况。4.3 第三步入库与统计分析解析出的记录我统一导入SQLite建了三张表messages短信主表、contacts联系人映射表、parse_errors解析异常记录表。建表SQL如下CREATE TABLE IF NOT EXISTS messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts DATETIME NOT NULL, phone TEXT, body TEXT, raw TEXT, source TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_messages_ts ON messages(ts); CREATE INDEX idx_messages_phone ON messages(phone);raw字段保存这条记录在原始文件中的完整文本source字段记录这份数据来自哪台手机、哪种导出工具。这个设计让我在任何时候都能从数据库反查到原始来源对排查问题非常有帮助。入库之后我会跑几个统计查询用来验证解析质量按月统计短信数量按号码统计联系人频率按小时统计发送时段分布。这些统计不仅有意思还能当数据完整性检查——比如某个月的数量是0说明那个月的记录没有被解析到需要回头检查格式。我实际跑出来的结果是四年共6234条短信从最初几条格式妖孽的记录手工修正后最终入库6179条解析成功率99.1%。总共耗时不到3秒。4.4 实测效果数据量、耗时、准确率最后放一组实测数据供参考。我用四组不同来源的数据分别跑了一遍解析脚本数据源记录数平均耗时准确率备注诺基亚E63 PC套件导出21401.2s98.6%有少量UTF-16 BOM问题N73.vmg导出53382.8s99.3%标记行式最稳定手工复制粘贴3860.4s96.1%依赖人工修正混合乱码文件1120.3s82.4%需要额外清洗手工复制粘贴那块准确率最低原因就是格式太乱时间戳和正文经常黏在一起。后来我针对这类数据单独写了一个宽松模式的正则只要有时间戳和正文号码可以为空。准确率提升到98%以上。这个经验也说明正则解析不是一锤子买卖最好根据数据特征准备多套策略然后让嗅探器自动选择。5. 常见问题与排查技巧实录5.1 正则匹配不到先检查这四处正则匹配不到记录是最常见的问题尤其是在处理新格式数据的时候。我自己的排查顺序是固定的分享出来供参考第一检查数据清洗是否引入问题。清洗脚本如果误删了换行符或者错误合并了文本那么再好的正则也白搭。我会先用一个极简正则r\d{4}-\d{2}-\d{2}测试原始清洗文件里是否还有时间戳如果这个都匹配不到说明问题在清洗阶段而不是正则。第二检查正则模式里是否有多余的空格。手动编写正则时\s*和\s的区别非常大。比如时间戳和号码之间有时是有空格的有时没有。我会把表达式里的空白部分替换成\s*来容忍差异而不是要求严格一致。第三检查re.MULTILINE和re.DOTALL是否正确启用。如果正文里出现换行而你开了DOTALL没问题但如果记录边界依赖行首^则需要MULTILINE。这两个标志弄反了匹配结果会截然不同。最简单的验证方式是用一小段样例数据跑finditer打印匹配到的时间戳和正文起始位置肉眼对比。第四检查正则的优先级。字符串里的{}在正则里代表量词如果正文里恰好有{xxx}这种文本且没有转义匹配会静默失败。在调试阶段我会用re.debug或者在表达式里临时加注释逐个分组禁用找出是哪一部分导致整体无法匹配。5.2 编码与乱码的实战教训编码问题几乎占了整个项目一半的排查时间。我总结出了几条硬规则规则一不要猜测编码要用探测工具。用chardet探测文件编码然后还要人工验证——怎么验证把解码后的文本打印前500字如果出现大量\ufffd替换符说明编码判断错了立刻换一种。这条规则帮我避开了至少三次手工看一眼觉得像GBK结果实际是GB18030的坑。规则二转码和清洗必须分离。先做字节级的转码比如从GBK转成UTF-8再做文本级的清洗比如去零宽字符。如果反过来清洗后的文本再转码某些字符会被第二次破坏产生不可逆的乱码。规则三保存数据时永远保留一份原始字节副本。这是我踩过最痛的坑。有一次我清洗完一个文件直接在原文件上保存了UTF-8版本后来发现清洗逻辑写错了想回到原始状态结果源文件已经被覆盖只能重新去手机里导数据。从那以后我的所有处理都是原始文件 - 副本文件 - 清洗文件三层结构原始字节永远不会被任何脚本写入。5.3 大数据量下的性能优化解析六百多条数据很快就结束了但当你有一天要处理几万条短信性能问题就会冒出来。正则解析本身属于CPU密集型操作我实测的经验是这样的循环内避免重复编译正则。re.compile()的代价不低如果在循环体里反复调用re.match()而不是pattern.match()性能会差一个数量级。正确做法是把所有正则对象提到模块级别提前编译好。使用finditer而不是findall。findall会一次性把所有匹配结果加载进内存几万条记录时内存可能爆掉finditer返回惰性迭代器边匹配边处理内存占用恒定。我的脚本从findall改成finditer之后内存从800MB降到40MB。按文件切块处理。如果你有几十个备份文件不要一股脑拼成一个超大字符串再运行正则。我的做法是按文件逐个解析每个文件单独生成一个结果表最后再合并。这样某个文件出错时不会导致整个流程崩溃也方便定位问题。用re.VERBOSE提升可读性。虽然它对性能没有直接影响但一个带注释的正则表达式能省下未来无数倍排查时间。我见过很多人的正则是一行几百个字符看着就头大。拆分成带注释的多行表达式任何接手的人都能快速理解匹配逻辑。5.4 格式扩展如何应对新增数据源数据整理是个长期的活未来你很可能拿到新格式的手机备份。不要每次遇到新格式就重写解析脚本我建议维护一个解析规则库目录结构大概是parsers/ base.py # 公共方法清洗、归一化、入库 vmsg_parser.py # 标记行式解析器 pipe_parser.py # 单行管道式解析器 indent_parser.py # 多行缩进式解析器 loose_parser.py # 宽松模式解析器兜底新增格式时先写一个嗅探分支往sniff_format里加规则再新建一个解析器文件继承base.py的公共方法只重写需要变化的正则逻辑。这样每支持一种新格式增量代码量一般控制在50行以内而且旧数据不会因为新增规则而受影响。“数据自由”落到实处的表现是我能用一条SQL从6179条短信里查出某年某月某天深夜和谁聊过什么我能把整个数据库导出成JSON、CSV或者HTML我不再担心手机关机、软件停服、备份文件损坏。这些数据和我的记忆之间终于不再隔着任何一层封闭格式的锁。如果你想整理自己的旧手机数据我的建议很简单先把原始文件备份三份然后写个最简单的正则试试手不要指望一步到位边解析边积累规则。等你的规则库跑通那一天你会觉得四年没有白熬。