拓冰网站定制 
简介这是一款面向微信用户、数据分析爱好者及课程作业开发者的聊天记录提取与分析工具可解决聊天记录长期留存与回顾的痛点。资源包共257个文件约24.96MB以103个Python源码文件为核心配合61张png与43个svg图形资源、18个html页面模板以及json、md、yml等配置与说明文件另含少量pyd、proto、qss、qrc等工程文件整体结构完整便于二次开发与功能扩展。工具支持将聊天记录导出为HTML、Word、CSV文档实现永久保存同时具备聊天记录分析能力可生成年度聊天报告帮助用户回顾与他人的沟通情况。目前已有9737人学习下载适合想研究微信数据提取、文档导出或报告可视化的读者参考既能直接使用现成功能也能借鉴其Python实现思路与页面模板组织方式。1. 微信聊天记录提取和分析工具从加密数据库到 HTML、Word、CSV 的完整落地路径微信聊天记录躺在手机或电脑里平时翻着方便一旦想长期保存、跨设备检索、做关键词统计就会发现它既导不出、也搜不动。所谓「微信聊天记录提取和分析工具」核心要解决的就是三件事把散落在本地数据库里的消息读出来、把读出来的内容整理成结构化数据、再导出成 HTML、Word、CSV 这类通用文档实现永久保存。它适合两类人一类是想给自己多年聊天做个可检索归档的普通用户另一类是需要对客服会话、群聊记录做批量分析的从业者。热词里频繁出现的「微信dat文件查看器」「聊天记录导出」「导入csv文件」本质上都是这条链路上的不同环节。这篇笔记不讲玄学只讲我实际跑通过的路径从定位数据文件、解密数据库到解析消息、生成三种格式每一步都给可复现的命令和参数。2. 先搞清楚数据在哪微信本地存储结构与解密前置条件2.1 PC 微信与手机微信的存储差异做提取之前必须先定位数据。PC 端微信尤其是 4.x 版本把聊天数据放在用户目录下的xwechat_files或旧版的WeChat Files里核心是一个加密的 SQLite 数据库常见文件名是MSG.db或分库的message_*.db。手机端则更麻烦安卓需要 root 或借助备份文件iOS 基本只能走 iTunes 备份再解析备份包。热词里「pc 微信4.x 的数据库解密」之所以被反复搜就是因为 4.x 之后加密方式变了老工具直接读会报「file is not a database」。我一般建议先从 PC 端入手原因是文件路径固定、权限可控、调试方便。手机端除非有明确需求否则投入产出比不高。定位时可以用系统搜索找这几个关键目录# Linux/macOS 下查找微信数据目录Windows 用 dir /s 或 Everything find ~ -type d -iname *wechat* 2/dev/null find ~ -type f -iname MSG*.db 2/dev/null # 找到后先看文件头判断是否加密 xxd -l 16 /path/to/MSG.db逻辑说明find用来快速定位目录xxd读文件头 16 字节。正常的 SQLite 文件头是SQLite format 3如果看到的是随机字节说明数据库被加密了必须先解密才能解析。参数上-l 16只读前 16 字节避免大文件卡顿。2.2 解密拿到密钥是唯一门槛解密这一步是整个链路里最容易翻车的地方。微信的数据库密钥和当前登录账号绑定常见做法是从微信进程内存里提取密钥再用 SQLCipher 解密。这里不展开内存提取的具体工具涉及平台差异大重点说解密后的验证。假设你已经拿到 32 字节的十六进制密钥用sqlcipher命令行解密# 用 sqlcipher 打开加密库并导出为明文库 sqlcipher /path/to/MSG.db # 进入交互后执行 PRAGMA key x你的32字节十六进制密钥; PRAGMA cipher_page_size 4096; PRAGMA kdf_iter 64000; ATTACH DATABASE /path/to/MSG_plain.db AS plaintext KEY ; SELECT sqlcipher_export(plaintext); DETACH DATABASE plaintext;逻辑说明PRAGMA key传入密钥cipher_page_size和kdf_iter是 SQLCipher 的加密参数微信不同版本这两个值可能不同4.x 常见kdf_iter是 64000老版本可能是 4000。如果解密后MSG_plain.db用sqlite3能正常打开并看到表说明密钥和参数都对。参数错了会直接报file is encrypted or is not a database这时候别急着换工具先把kdf_iter试几个常见值。提示解密后的明文库包含全部聊天内容属于高度敏感数据建议在离线环境操作处理完及时清理临时文件。2.3 表结构速览消息到底存在哪张表解密成功后用sqlite3看表结构核心表通常是message和contact。message表里关键字段包括localId、TalkerId会话对象、Type消息类型、CreateTime时间戳、Content消息体。Type的取值决定了解析方式1 是文本3 是图片34 是语音43 是视频49 是各种卡片和引用。理解这张表是后面所有解析工作的基础字段名在不同版本可能略有差异用.schema message先确认。3. 把消息读出来Python 解析 message 表并清洗成结构化数据3.1 连接数据库与基础查询拿到明文库后用 Python 的sqlite3直接读。第一步不是急着导出而是先摸清数据分布避免一上来就全量拉取导致内存爆掉。import sqlite3 from datetime import datetime conn sqlite3.connect(MSG_plain.db) cur conn.cursor() # 先看消息类型分布决定后续解析策略 cur.execute(SELECT Type, COUNT(*) FROM message GROUP BY Type ORDER BY COUNT(*) DESC) for msg_type, cnt in cur.fetchall(): print(fType{msg_type}, count{cnt}) # 按会话统计消息量找出主要会话 cur.execute( SELECT TalkerId, COUNT(*) as cnt FROM message GROUP BY TalkerId ORDER BY cnt DESC LIMIT 20 ) for talker, cnt in cur.fetchall(): print(talker, cnt)逻辑说明第一条查询统计各Type的数量帮你判断这个库里主要是文本还是图片语音决定要不要做多媒体导出。第二条按TalkerId聚合快速定位消息量最大的会话。参数上LIMIT 20只是预览实际导出时按需调整。这一步的意义在于如果 90% 是图片消息那导出 CSV 的价值就很低应该优先考虑 HTML 带缩略图的方案。3.2 文本消息解析与时间戳转换文本消息的Content字段可能是纯文本也可能带 XML 结构比如引用、链接卡片。我一般先做一层清洗把能提取的纯文本抽出来同时把CreateTime转成可读时间。import re import html def parse_content(raw: str, msg_type: int) - str: if raw is None: return # 文本消息直接返回做 HTML 转义防止导出时破坏结构 if msg_type 1: return html.escape(raw) # 49 类型里常见的是引用和链接尝试抽 title if msg_type 49: m re.search(rtitle(.*?)/title, raw, re.S) if m: return html.escape(m.group(1)) return [非文本消息] return f[类型{msg_type}消息] def ts_to_str(ts: int) - str: # 微信时间戳是秒级部分版本是毫秒做个兼容 if ts 1e12: ts ts / 1000 return datetime.fromtimestamp(ts).strftime(%Y-%m-%d %H:%M:%S) cur.execute(SELECT localId, TalkerId, Type, CreateTime, Content FROM message ORDER BY CreateTime) rows cur.fetchall() messages [ { id: r[0], talker: r[1], type: r[2], time: ts_to_str(r[3]), content: parse_content(r[4], r[2]), } for r in rows ] print(f共解析 {len(messages)} 条消息)逻辑说明parse_content按Type分流文本直接转义49 类型用正则抽title抽不到就给占位符。ts_to_str兼容秒和毫秒两种时间戳这是血泪经验——不同微信版本时间戳单位不一致不兼容会导致时间全变成 1970 年。html.escape很关键聊天内容里如果有或不转义会直接破坏后面生成的 HTML 结构。3.3 关联联系人把 TalkerId 换成可读名字光有TalkerId没法看得关联contact表拿到昵称或备注。注意群聊的TalkerId以chatroom结尾单聊则是wxid_开头。# 建立 TalkerId - 显示名 的映射 cur.execute(SELECT UserName, NickName, Remark FROM contact) name_map {} for user_name, nick, remark in cur.fetchall(): name_map[user_name] remark or nick or user_name for msg in messages: talker msg[talker] if talker and talker.endswith(chatroom): msg[talker_name] f群聊:{name_map.get(talker, talker)} else: msg[talker_name] name_map.get(talker, talker) # 预览前 5 条 for m in messages[:5]: print(m[time], m[talker_name], m[content][:50])逻辑说明Remark优先于NickName因为备注是用户自己设的更符合检索习惯。群聊加前缀是为了在导出文档里一眼区分。这一步做完数据就从「数据库行」变成了「人能读的记录」可以进入导出环节了。4. 三种格式导出实战HTML、Word、CSV 各自的取舍与代码4.1 CSV最适合做数据分析但要注意编码和换行CSV 是导入 Excel、做关键词统计的首选。坑在于聊天内容里常有逗号和换行不处理会直接把表格撑乱。用 Python 标准库csv模块能自动处理转义。import csv with open(chat_export.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([时间, 会话, 类型, 内容]) for m in messages: writer.writerow([m[time], m[talker_name], m[type], m[content]]) print(CSV 导出完成)逻辑说明newline是必须的否则 Windows 下会出现空行。encodingutf-8-sig带 BOMExcel 直接双击打开不乱码这是热词里「导入csv文件」最常见的翻车点——用utf-8导出Excel 打开全是乱码。csv.writer会自动给含逗号或换行的字段加引号不用手动处理。4.2 HTML最适合永久保存和检索单文件自包含HTML 的优势是浏览器直接打开、支持搜索、可以内嵌样式适合做长期归档。热词里「打包多个html」说明很多人有把多个会话合并成一个文件的需求。我一般生成一个自包含的单文件带简单样式和锚点。def export_html(messages, pathchat_export.html): rows_html [] for m in messages: rows_html.append( fdiv classmsgspan classtime{m[time]}/span fspan classtalker{html.escape(m[talker_name])}/span fdiv classcontent{m[content]}/div/div ) doc f!DOCTYPE html html langzh-cn head meta charsetutf-8 title微信聊天记录归档/title style body {{ font-family: sans-serif; max-width: 900px; margin: 0 auto; padding: 20px; }} .msg {{ border-bottom: 1px solid #eee; padding: 8px 0; }} .time {{ color: #888; font-size: 12px; margin-right: 8px; }} .talker {{ color: #07c160; font-weight: bold; margin-right: 8px; }} .content {{ margin-top: 4px; white-space: pre-wrap; word-break: break-word; }} /style /head body h1微信聊天记录归档共 {len(messages)} 条/h1 {.join(rows_html)} /body /html with open(path, w, encodingutf-8) as f: f.write(doc) export_html(messages)逻辑说明white-space: pre-wrap让内容里的换行正常显示word-break: break-word防止长链接撑破布局。整个文件不依赖外部资源拷到任何地方都能打开这就是「永久保存」的关键。html.escape在解析阶段已经做过这里直接输出是安全的。如果消息量上万.join比字符串拼接效率高很多。4.3 Word适合正式归档用 python-docx 控制段落Word 适合需要打印或正式提交的场景。用python-docx生成注意中文字体要显式设置否则默认字体显示中文会很难看。from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc Document() style doc.styles[Normal] style.font.name 微软雅黑 style.font.size Pt(10) # 关键设置中文字体否则中文可能回退成宋体 style.element.rPr.rFonts.set(qn(w:eastAsia), 微软雅黑) doc.add_heading(微信聊天记录归档, level1) for m in messages: p doc.add_paragraph() p.add_run(f{m[time]} {m[talker_name]}).bold True doc.add_paragraph(m[content]) doc.save(chat_export.docx) print(Word 导出完成)逻辑说明qn(w:eastAsia)是设置中文字体的关键只设font.name对中文无效这是热词里「word 表格列宽无法拖动」之外另一个高频字体坑。每条消息用两个段落第一段加粗显示时间和会话第二段放内容结构清晰。消息量大时 Word 文件会很大超过几千条建议改用 HTML。4.4 三种格式的选型对照格式适合场景优点主要限制CSV数据分析、关键词统计可导入 Excel、易程序处理不支持富文本、图片HTML长期归档、全文检索单文件自包含、浏览器直开消息过多时文件偏大Word正式归档、打印排版规范、易分享大文件打开慢、字体需设置选型上没有绝对优劣我的习惯是三种都生成一份CSV 用来做分析HTML 用来日常检索Word 用来存档。反正解析一次数据导出三次成本很低。5. 避坑与排查提取微信聊天记录最常见的 5 个翻车点5.1 解密后 sqlite3 打不开报 not a database现象sqlcipher_export执行完用sqlite3 MSG_plain.db打开报错。原因密钥正确但kdf_iter或cipher_page_size不匹配导出的仍是加密数据。解决先确认微信版本4.x 常见kdf_iter64000老版本试 4000cipher_page_size试 1024 和 4096。还不行就用PRAGMA cipher_migrate让 SQLCipher 自动尝试迁移参数。5.2 时间全变成 1970 年现象导出的时间戳转换后全是 1970-01-01。原因CreateTime单位判断错误毫秒被当成秒处理。解决在ts_to_str里加阈值判断大于1e12的按毫秒除以 1000。这个坑我在不同版本微信上踩过两次现在一律先打印几个原始时间戳看量级。5.3 CSV 用 Excel 打开中文乱码现象CSV 在编辑器里正常Excel 双击打开中文变问号。原因Excel 默认按 GBK 解析无 BOM 的 UTF-8 文件。解决导出时用encodingutf-8-sig让文件带 BOM 头。如果已经导出了用记事本另存为「UTF-8 带 BOM」也能救回来。5.4 HTML 导出后内容里的标签把页面搞乱现象聊天内容里有人发了div之类的文本导出后页面结构错乱。原因内容未做 HTML 转义直接拼接。解决在解析阶段就对Content做html.escape而不是在导出阶段补。这样 CSV 和 Word 导出也顺带安全了因为转义后的实体在纯文本场景下也能正常显示。5.5 消息量上万时内存爆掉现象一次性fetchall几万条消息Python 进程内存飙升甚至被系统杀掉。原因全量加载到内存。解决改用游标迭代边读边写。CSV 和 HTML 都可以流式写入只有 Word 因为文档对象模型限制需要全量所以超大记录优先用 HTML 或 CSV。6. 进阶技巧用 SQL 直接做关键词统计与按会话拆分导出数据落到 SQLite 里之后其实不用急着写 Python很多分析用 SQL 更快。比如统计某个关键词在哪些会话里出现最多一条 SQL 就能出结果-- 统计包含「发票」的消息按会话聚合 SELECT TalkerId, COUNT(*) AS hit_count FROM message WHERE Type 1 AND Content LIKE %发票% GROUP BY TalkerId ORDER BY hit_count DESC LIMIT 10;逻辑说明Type 1限定文本消息避免图片语音干扰LIKE %发票%做模糊匹配中文在 SQLite 里默认按字节匹配短关键词没问题。这个查询能快速定位「哪个客户最常提发票」对客服场景很实用。再进一步按会话拆分导出多个 HTML方便分人归档。思路是先查出所有TalkerId对每个会话过滤消息列表再调用一次export_htmlfrom collections import defaultdict by_talker defaultdict(list) for m in messages: by_talker[m[talker_name]].append(m) for name, msgs in by_talker.items(): safe_name re.sub(r[\\/:*?|], _, name) # 去掉文件名非法字符 export_html(msgs, pathfexport_{safe_name}.html) print(f{name}: {len(msgs)} 条)逻辑说明defaultdict按会话分组re.sub清理文件名里的非法字符——Windows 下文件名不能含\/:*?|不处理会直接报错这是打包多个 HTML 时必踩的坑。每个会话一个文件配合前面的单文件方案既能整体检索也能分人查看。最后说个验证方法导出完成后随机抽 3 个会话用微信客户端里的搜索功能对照条数和内容确认没有漏消息。我一般会重点核对跨天和含图片的会话因为这两类最容易在解析时丢数据。这套流程我从定位数据库到三种格式导出跑通大概花了两个晚上最大的教训是别在解密参数上死磕先把微信版本和kdf_iter对应关系查清楚能省掉一半时间。希望帮到你。本文还有配套的精品资源点击获取 微信聊天记录提取与分析：从加密数据库到HTML、Word、CSV导出实战
简介这是一款面向微信用户、数据分析爱好者及课程作业开发者的聊天记录提取与分析工具可解决聊天记录长期留存与回顾的痛点。资源包共257个文件约24.96MB以103个Python源码文件为核心配合61张png与43个svg图形资源、18个html页面模板以及json、md、yml等配置与说明文件另含少量pyd、proto、qss、qrc等工程文件整体结构完整便于二次开发与功能扩展。工具支持将聊天记录导出为HTML、Word、CSV文档实现永久保存同时具备聊天记录分析能力可生成年度聊天报告帮助用户回顾与他人的沟通情况。目前已有9737人学习下载适合想研究微信数据提取、文档导出或报告可视化的读者参考既能直接使用现成功能也能借鉴其Python实现思路与页面模板组织方式。1. 微信聊天记录提取和分析工具从加密数据库到 HTML、Word、CSV 的完整落地路径微信聊天记录躺在手机或电脑里平时翻着方便一旦想长期保存、跨设备检索、做关键词统计就会发现它既导不出、也搜不动。所谓「微信聊天记录提取和分析工具」核心要解决的就是三件事把散落在本地数据库里的消息读出来、把读出来的内容整理成结构化数据、再导出成 HTML、Word、CSV 这类通用文档实现永久保存。它适合两类人一类是想给自己多年聊天做个可检索归档的普通用户另一类是需要对客服会话、群聊记录做批量分析的从业者。热词里频繁出现的「微信dat文件查看器」「聊天记录导出」「导入csv文件」本质上都是这条链路上的不同环节。这篇笔记不讲玄学只讲我实际跑通过的路径从定位数据文件、解密数据库到解析消息、生成三种格式每一步都给可复现的命令和参数。2. 先搞清楚数据在哪微信本地存储结构与解密前置条件2.1 PC 微信与手机微信的存储差异做提取之前必须先定位数据。PC 端微信尤其是 4.x 版本把聊天数据放在用户目录下的xwechat_files或旧版的WeChat Files里核心是一个加密的 SQLite 数据库常见文件名是MSG.db或分库的message_*.db。手机端则更麻烦安卓需要 root 或借助备份文件iOS 基本只能走 iTunes 备份再解析备份包。热词里「pc 微信4.x 的数据库解密」之所以被反复搜就是因为 4.x 之后加密方式变了老工具直接读会报「file is not a database」。我一般建议先从 PC 端入手原因是文件路径固定、权限可控、调试方便。手机端除非有明确需求否则投入产出比不高。定位时可以用系统搜索找这几个关键目录# Linux/macOS 下查找微信数据目录Windows 用 dir /s 或 Everything find ~ -type d -iname *wechat* 2/dev/null find ~ -type f -iname MSG*.db 2/dev/null # 找到后先看文件头判断是否加密 xxd -l 16 /path/to/MSG.db逻辑说明find用来快速定位目录xxd读文件头 16 字节。正常的 SQLite 文件头是SQLite format 3如果看到的是随机字节说明数据库被加密了必须先解密才能解析。参数上-l 16只读前 16 字节避免大文件卡顿。2.2 解密拿到密钥是唯一门槛解密这一步是整个链路里最容易翻车的地方。微信的数据库密钥和当前登录账号绑定常见做法是从微信进程内存里提取密钥再用 SQLCipher 解密。这里不展开内存提取的具体工具涉及平台差异大重点说解密后的验证。假设你已经拿到 32 字节的十六进制密钥用sqlcipher命令行解密# 用 sqlcipher 打开加密库并导出为明文库 sqlcipher /path/to/MSG.db # 进入交互后执行 PRAGMA key x你的32字节十六进制密钥; PRAGMA cipher_page_size 4096; PRAGMA kdf_iter 64000; ATTACH DATABASE /path/to/MSG_plain.db AS plaintext KEY ; SELECT sqlcipher_export(plaintext); DETACH DATABASE plaintext;逻辑说明PRAGMA key传入密钥cipher_page_size和kdf_iter是 SQLCipher 的加密参数微信不同版本这两个值可能不同4.x 常见kdf_iter是 64000老版本可能是 4000。如果解密后MSG_plain.db用sqlite3能正常打开并看到表说明密钥和参数都对。参数错了会直接报file is encrypted or is not a database这时候别急着换工具先把kdf_iter试几个常见值。提示解密后的明文库包含全部聊天内容属于高度敏感数据建议在离线环境操作处理完及时清理临时文件。2.3 表结构速览消息到底存在哪张表解密成功后用sqlite3看表结构核心表通常是message和contact。message表里关键字段包括localId、TalkerId会话对象、Type消息类型、CreateTime时间戳、Content消息体。Type的取值决定了解析方式1 是文本3 是图片34 是语音43 是视频49 是各种卡片和引用。理解这张表是后面所有解析工作的基础字段名在不同版本可能略有差异用.schema message先确认。3. 把消息读出来Python 解析 message 表并清洗成结构化数据3.1 连接数据库与基础查询拿到明文库后用 Python 的sqlite3直接读。第一步不是急着导出而是先摸清数据分布避免一上来就全量拉取导致内存爆掉。import sqlite3 from datetime import datetime conn sqlite3.connect(MSG_plain.db) cur conn.cursor() # 先看消息类型分布决定后续解析策略 cur.execute(SELECT Type, COUNT(*) FROM message GROUP BY Type ORDER BY COUNT(*) DESC) for msg_type, cnt in cur.fetchall(): print(fType{msg_type}, count{cnt}) # 按会话统计消息量找出主要会话 cur.execute( SELECT TalkerId, COUNT(*) as cnt FROM message GROUP BY TalkerId ORDER BY cnt DESC LIMIT 20 ) for talker, cnt in cur.fetchall(): print(talker, cnt)逻辑说明第一条查询统计各Type的数量帮你判断这个库里主要是文本还是图片语音决定要不要做多媒体导出。第二条按TalkerId聚合快速定位消息量最大的会话。参数上LIMIT 20只是预览实际导出时按需调整。这一步的意义在于如果 90% 是图片消息那导出 CSV 的价值就很低应该优先考虑 HTML 带缩略图的方案。3.2 文本消息解析与时间戳转换文本消息的Content字段可能是纯文本也可能带 XML 结构比如引用、链接卡片。我一般先做一层清洗把能提取的纯文本抽出来同时把CreateTime转成可读时间。import re import html def parse_content(raw: str, msg_type: int) - str: if raw is None: return # 文本消息直接返回做 HTML 转义防止导出时破坏结构 if msg_type 1: return html.escape(raw) # 49 类型里常见的是引用和链接尝试抽 title if msg_type 49: m re.search(rtitle(.*?)/title, raw, re.S) if m: return html.escape(m.group(1)) return [非文本消息] return f[类型{msg_type}消息] def ts_to_str(ts: int) - str: # 微信时间戳是秒级部分版本是毫秒做个兼容 if ts 1e12: ts ts / 1000 return datetime.fromtimestamp(ts).strftime(%Y-%m-%d %H:%M:%S) cur.execute(SELECT localId, TalkerId, Type, CreateTime, Content FROM message ORDER BY CreateTime) rows cur.fetchall() messages [ { id: r[0], talker: r[1], type: r[2], time: ts_to_str(r[3]), content: parse_content(r[4], r[2]), } for r in rows ] print(f共解析 {len(messages)} 条消息)逻辑说明parse_content按Type分流文本直接转义49 类型用正则抽title抽不到就给占位符。ts_to_str兼容秒和毫秒两种时间戳这是血泪经验——不同微信版本时间戳单位不一致不兼容会导致时间全变成 1970 年。html.escape很关键聊天内容里如果有或不转义会直接破坏后面生成的 HTML 结构。3.3 关联联系人把 TalkerId 换成可读名字光有TalkerId没法看得关联contact表拿到昵称或备注。注意群聊的TalkerId以chatroom结尾单聊则是wxid_开头。# 建立 TalkerId - 显示名 的映射 cur.execute(SELECT UserName, NickName, Remark FROM contact) name_map {} for user_name, nick, remark in cur.fetchall(): name_map[user_name] remark or nick or user_name for msg in messages: talker msg[talker] if talker and talker.endswith(chatroom): msg[talker_name] f群聊:{name_map.get(talker, talker)} else: msg[talker_name] name_map.get(talker, talker) # 预览前 5 条 for m in messages[:5]: print(m[time], m[talker_name], m[content][:50])逻辑说明Remark优先于NickName因为备注是用户自己设的更符合检索习惯。群聊加前缀是为了在导出文档里一眼区分。这一步做完数据就从「数据库行」变成了「人能读的记录」可以进入导出环节了。4. 三种格式导出实战HTML、Word、CSV 各自的取舍与代码4.1 CSV最适合做数据分析但要注意编码和换行CSV 是导入 Excel、做关键词统计的首选。坑在于聊天内容里常有逗号和换行不处理会直接把表格撑乱。用 Python 标准库csv模块能自动处理转义。import csv with open(chat_export.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([时间, 会话, 类型, 内容]) for m in messages: writer.writerow([m[time], m[talker_name], m[type], m[content]]) print(CSV 导出完成)逻辑说明newline是必须的否则 Windows 下会出现空行。encodingutf-8-sig带 BOMExcel 直接双击打开不乱码这是热词里「导入csv文件」最常见的翻车点——用utf-8导出Excel 打开全是乱码。csv.writer会自动给含逗号或换行的字段加引号不用手动处理。4.2 HTML最适合永久保存和检索单文件自包含HTML 的优势是浏览器直接打开、支持搜索、可以内嵌样式适合做长期归档。热词里「打包多个html」说明很多人有把多个会话合并成一个文件的需求。我一般生成一个自包含的单文件带简单样式和锚点。def export_html(messages, pathchat_export.html): rows_html [] for m in messages: rows_html.append( fdiv classmsgspan classtime{m[time]}/span fspan classtalker{html.escape(m[talker_name])}/span fdiv classcontent{m[content]}/div/div ) doc f!DOCTYPE html html langzh-cn head meta charsetutf-8 title微信聊天记录归档/title style body {{ font-family: sans-serif; max-width: 900px; margin: 0 auto; padding: 20px; }} .msg {{ border-bottom: 1px solid #eee; padding: 8px 0; }} .time {{ color: #888; font-size: 12px; margin-right: 8px; }} .talker {{ color: #07c160; font-weight: bold; margin-right: 8px; }} .content {{ margin-top: 4px; white-space: pre-wrap; word-break: break-word; }} /style /head body h1微信聊天记录归档共 {len(messages)} 条/h1 {.join(rows_html)} /body /html with open(path, w, encodingutf-8) as f: f.write(doc) export_html(messages)逻辑说明white-space: pre-wrap让内容里的换行正常显示word-break: break-word防止长链接撑破布局。整个文件不依赖外部资源拷到任何地方都能打开这就是「永久保存」的关键。html.escape在解析阶段已经做过这里直接输出是安全的。如果消息量上万.join比字符串拼接效率高很多。4.3 Word适合正式归档用 python-docx 控制段落Word 适合需要打印或正式提交的场景。用python-docx生成注意中文字体要显式设置否则默认字体显示中文会很难看。from docx import Document from docx.shared import Pt from docx.oxml.ns import qn doc Document() style doc.styles[Normal] style.font.name 微软雅黑 style.font.size Pt(10) # 关键设置中文字体否则中文可能回退成宋体 style.element.rPr.rFonts.set(qn(w:eastAsia), 微软雅黑) doc.add_heading(微信聊天记录归档, level1) for m in messages: p doc.add_paragraph() p.add_run(f{m[time]} {m[talker_name]}).bold True doc.add_paragraph(m[content]) doc.save(chat_export.docx) print(Word 导出完成)逻辑说明qn(w:eastAsia)是设置中文字体的关键只设font.name对中文无效这是热词里「word 表格列宽无法拖动」之外另一个高频字体坑。每条消息用两个段落第一段加粗显示时间和会话第二段放内容结构清晰。消息量大时 Word 文件会很大超过几千条建议改用 HTML。4.4 三种格式的选型对照格式适合场景优点主要限制CSV数据分析、关键词统计可导入 Excel、易程序处理不支持富文本、图片HTML长期归档、全文检索单文件自包含、浏览器直开消息过多时文件偏大Word正式归档、打印排版规范、易分享大文件打开慢、字体需设置选型上没有绝对优劣我的习惯是三种都生成一份CSV 用来做分析HTML 用来日常检索Word 用来存档。反正解析一次数据导出三次成本很低。5. 避坑与排查提取微信聊天记录最常见的 5 个翻车点5.1 解密后 sqlite3 打不开报 not a database现象sqlcipher_export执行完用sqlite3 MSG_plain.db打开报错。原因密钥正确但kdf_iter或cipher_page_size不匹配导出的仍是加密数据。解决先确认微信版本4.x 常见kdf_iter64000老版本试 4000cipher_page_size试 1024 和 4096。还不行就用PRAGMA cipher_migrate让 SQLCipher 自动尝试迁移参数。5.2 时间全变成 1970 年现象导出的时间戳转换后全是 1970-01-01。原因CreateTime单位判断错误毫秒被当成秒处理。解决在ts_to_str里加阈值判断大于1e12的按毫秒除以 1000。这个坑我在不同版本微信上踩过两次现在一律先打印几个原始时间戳看量级。5.3 CSV 用 Excel 打开中文乱码现象CSV 在编辑器里正常Excel 双击打开中文变问号。原因Excel 默认按 GBK 解析无 BOM 的 UTF-8 文件。解决导出时用encodingutf-8-sig让文件带 BOM 头。如果已经导出了用记事本另存为「UTF-8 带 BOM」也能救回来。5.4 HTML 导出后内容里的标签把页面搞乱现象聊天内容里有人发了div之类的文本导出后页面结构错乱。原因内容未做 HTML 转义直接拼接。解决在解析阶段就对Content做html.escape而不是在导出阶段补。这样 CSV 和 Word 导出也顺带安全了因为转义后的实体在纯文本场景下也能正常显示。5.5 消息量上万时内存爆掉现象一次性fetchall几万条消息Python 进程内存飙升甚至被系统杀掉。原因全量加载到内存。解决改用游标迭代边读边写。CSV 和 HTML 都可以流式写入只有 Word 因为文档对象模型限制需要全量所以超大记录优先用 HTML 或 CSV。6. 进阶技巧用 SQL 直接做关键词统计与按会话拆分导出数据落到 SQLite 里之后其实不用急着写 Python很多分析用 SQL 更快。比如统计某个关键词在哪些会话里出现最多一条 SQL 就能出结果-- 统计包含「发票」的消息按会话聚合 SELECT TalkerId, COUNT(*) AS hit_count FROM message WHERE Type 1 AND Content LIKE %发票% GROUP BY TalkerId ORDER BY hit_count DESC LIMIT 10;逻辑说明Type 1限定文本消息避免图片语音干扰LIKE %发票%做模糊匹配中文在 SQLite 里默认按字节匹配短关键词没问题。这个查询能快速定位「哪个客户最常提发票」对客服场景很实用。再进一步按会话拆分导出多个 HTML方便分人归档。思路是先查出所有TalkerId对每个会话过滤消息列表再调用一次export_htmlfrom collections import defaultdict by_talker defaultdict(list) for m in messages: by_talker[m[talker_name]].append(m) for name, msgs in by_talker.items(): safe_name re.sub(r[\\/:*?|], _, name) # 去掉文件名非法字符 export_html(msgs, pathfexport_{safe_name}.html) print(f{name}: {len(msgs)} 条)逻辑说明defaultdict按会话分组re.sub清理文件名里的非法字符——Windows 下文件名不能含\/:*?|不处理会直接报错这是打包多个 HTML 时必踩的坑。每个会话一个文件配合前面的单文件方案既能整体检索也能分人查看。最后说个验证方法导出完成后随机抽 3 个会话用微信客户端里的搜索功能对照条数和内容确认没有漏消息。我一般会重点核对跨天和含图片的会话因为这两类最容易在解析时丢数据。这套流程我从定位数据库到三种格式导出跑通大概花了两个晚上最大的教训是别在解密参数上死磕先把微信版本和kdf_iter对应关系查清楚能省掉一半时间。希望帮到你。本文还有配套的精品资源点击获取