简介：面向QQ日常用户的聊天记录查看入门教程，专为不熟悉QQ操作界面的初学者设计，系统梳理了查看聊天记录的多种途径与具体操作要领。内容涵盖双击好友头像访问历史消息、通过消息记录按钮浏览详情、利用漫游消息功能跨设备查阅，以及普通用户100KB云端存储空间的使用方式，同时说明本地消息记录在缓存或垃圾文件清理后将不再保存的限制，帮助用户快速回溯重要对话内容。资源仅包含1个docx文档，整体大小约160KB，全文采用图文步骤说明，结构清晰、层次分明，无须额外配置即可直接打开阅读，并可随时检索定位关键操作点。已有231人学习下载，适合经常使用QQ办公、社交或需要保留聊天证据的用户，作为快捷查阅手册日常备用，也可用于新手熟悉QQ消息管理功能。
1. 如何查看 QQ 聊天记录：难点不是“看”，是生成一份能交付的 .docx
如果你搜的是“如何查看qq聊天记录.docx”，多半不是想让我告诉你在界面上点哪个按钮，而是想要一份能打开、能搜索、能打印、能交给别人的 Word 文档。把 QQ 聊天记录变成 .docx 这件事，第一印象是把导出的 txt 改个后缀，真做起来要连续过三关：拿到全量数据、处理文本和媒体的格式边界、再排版成可读文档。
先说结论：QQ 客户端的“消息管理器”能导出文本记录，但导出的 txt 里图片只剩占位符；新版本 PC 端把消息存进了加密的 SQLite 数据库，直接用数据库工具打开只能看到乱码。完整做法是先用官方导出功能拿到原始文本，再用脚本转成规整的 .docx。这套方案适合需要做聊天记录存档、项目过程留痕和离职交接附注的从业者，也适合给不懂技术的人交付“打开就能看”的归档文件。
2. 先搞清楚 QQ 把聊天记录放在哪：数据库结构与新旧版本差异
动手导出之前，先讲清楚文件在哪。很多人直接翻Program Files下的 QQ 安装目录，结果什么都没找到。其实聊天记录不在安装目录，而在当前登录用户的数据目录里。默认路径是Documents\Tencent Files\<QQ号>，里面既有消息数据库，也有图片、文件、语音等多媒体目录。
只有弄明白这个目录的职责划分，后面做 docx 的时候才知道哪些数据能写进文档，哪些数据只能“指向附件”，避免生成一份文字很完整、图片全缺席的残缺归档。
2.1 PC 端消息记录落盘位置：从 Msg.db 到 msg3.0.db
旧版 QQ（9.x 之前的版本）在这个目录下放着Msg.db，是一个标准 SQLite 文件，遇到不加密的版本可以用 SQLiteStudio 直接打开，表里有消息内容、发送人、时间。新版 QQ 的目录结构变了，消息主体集中在msg3.0.db上，除此之外还有不小的一份Image、File、Audio目录。我一般用 PowerShell 快速定位：
# 在整个用户目录下递归查找 Tencent Files 里的消息库，按修改时间排序 $root = Join-Path $env:USERPROFILE "Documents" Get-ChildItem -Path $root -Recurse -Directory -Filter "Tencent Files" -ErrorAction SilentlyContinue | ForEach-Object { Get-ChildItem -Path $_.FullName -Recurse -Include *.db,*.sqlite -ErrorAction SilentlyContinue } | Select-Object FullName, @{N="GB";E={[math]::Round($_.Length/1MB,2)}}, LastWriteTime | Sort-Object LastWriteTime -Descending | Format-Table -AutoSize参数说明：
- 用
-Recurse -Directory限定目录搜索，避免把缓存目录里的大量零碎文件带进来。 Include *.db,*.sqlite同时兼容新旧两种数据库命名。- 最后的
Sort-Object LastWriteTime -Descending会把最近改动的库排在最前面，通常就是你当前登录账号正在使用的消息库。 - 如果用户的
Documents被 OneDrive 或企业网盘接管，这个路径可能不存在，那就把搜索起点换成$env:USERPROFILE再跑一遍。
找到目录后，里面的文件职责大致如下：
| 文件或目录 | 存放内容 | 能否直接读取 | 备注 |
|---|---|---|---|
| msg3.0.db | 文本消息、群消息、会话索引 | 否 | 新版加密库 |
| Msg.db | 旧版消息记录 | 部分能读 | 老版本升级前留下 |
| Image | 收到的图片 | 文件无扩展名 | 文件名是 GUID |
| File | 收发文件 | 可直接复制 | 文件名多为数字 ID |
| Audio | 语音消息 | 需专用工具 | silk / amr 编码 |
| Video | 视频 | 需专用工具 | 文件名多为 id.video |
这些目录的文件名基本都是 GUID 或数字 ID，没有扩展名。Image里的图片不叫“张三发的照片.jpg”，而是一串 32 位十六进制字符串。QQ 拿消息 ID 和文件名做关联，导出 txt 后这个关联关系不会体现在文本里，所以直接遍历 Image 目录很难恢复到会话级别。这也是我为什么建议以官方导出为主，而不是从文件夹里翻图。
新旧版本切换时还有一个现象：同一账号在老版本登录时把消息写在 Msg.db，后来装新版 QQ，客户端会把它迁移进 msg3.0.db，并保留一份备份。看到.db.bak或Msg.db.bak不必奇怪，那是升级前自动备份。
2.2 手机端记录别硬啃数据库：权限不足时走官方迁移
手机 QQ 的原始数据在 Android 的/data/data/com.tencent.mobileqq/下，iOS 在沙盒里，普通用户拿不到。Android 即使开 USB 调试也要 root 后才能访问数据库，而且数据库同样是加密的。对绝大多数人来说，手机端正确的数据获取方式不是去挖数据库，而是用 QQ 自带的迁移功能。
操作入口不固定，但路径基本一致：手机 QQ 的设置 -> 通用 -> 聊天记录 -> 聊天记录迁移与备份 -> 迁移聊天记录到电脑。要求手机和电脑在同一局域网，电脑端登录同一个账号并保持在线。迁移完成后，手机上的消息会合并到电脑端，然后在电脑消息管理器里就能看到更完整的会话列表。迁移不能中途锁屏或切后台，会话多的时候会在“正在同步 XX 条”卡很久。
迁移完成之后，手机端聊天记录不会自动删除。如果选了“迁移并清空手机本地记录”，电脑端不受影响，但手机端就没了，所以操作前先确认电脑端消息数量已经同步完成。迁移过程依赖局域网，网络差时不要中途关电脑。
2.3 一眼判断数据库可不可读：文件头会说话
拿到.db文件之后，先用文件头判断是不是标准 SQLite。正规 SQLite 文件第一个字节开始就是SQLite format 3，后面跟一个\x00。用命令行看第一行最直接：
# 查看数据库文件头 16 字节，判断是否标准 SQLite 库 head -c 16 "msg3.0.db" | xxd如果输出开头是53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00，说明这是一个标准 SQLite 数据库；如果看到的是一串乱码，说明这个库已加密或根本不是 SQLite。注意，不要尝试手动改文件头来“修复”，改完大概率直接损坏。加密库的价值只在客户端手里，正确做法是回到客户端导出或迁移。
识别文件头的意义在于别浪费时间在错误工具上。我看到不少人下了一个“全盘数据库扫描”软件，对磁盘做逐扇区扫描，最后捞出一堆系统临时 SQLite 文件，全没用。正确姿势是看文件头，再决定下一步动作。
3. 先走官方通道拿原始数据：消息管理器导出与聊天记录迁移
虽然本地有数据库，但加密库读不了，所以第一步永远是打开 QQ 客户端，把消息记录导成原始文本。这一步做对了，后面的 docx 才稳。下面以 PC 端最新版为例，老版本按钮名字略有不同，但思路一样。
3.1 消息管理器导出 txt：操作步骤与导出样本
操作步骤不复杂，但版本之间菜单有差异：
- 电脑登录 QQ，点击左下角带三条横线的主菜单按钮。
- 在菜单里找到“消息管理器”，有些版本叫“聊天记录”或“消息记录”。
- 左侧选择单个会话，或直接选“全部会话”。
- 点击工具栏上的“导出”，选择“导出消息记录”。
- 保存类型选 txt，编码优先选 UTF-8。
导出得到的文本大致长这样：
2024-01-15 10:23:11 张三(123456) 周末一起吃饭吗 2024-01-15 10:24:03 李四(789012) [图片] 这家的火锅不错 2024-01-15 10:25:18 系统消息 "周末活动群"群聊入群申请已通过这里有两个细节：一是图片在导出结果里只有[图片]占位文本，没有实际图片；二是发送者信息是“昵称(QQ号)”的格式，昵称本身可以带空格，后续解析时不能按空格粗暴切分。编码可能是 UTF-8 也可能是 GBK，导出后在 Git Bash 里执行一行命令确认：
# 检查导出文本的编码类型，避免转换后中文乱码 file "导出.txt"显示UTF-8 Unicode text就用 utf-8 解析，显示ISO-8859或Non-ISO extended-ASCII就优先按 GBK 解析。Windows 自带记事本另存为 UTF-8 也可以，但会改变文件换行符，最好在脚本里直接处理。
老版本的消息管理器菜单可能叫“打开消息管理器”或“我的消息记录”，位置也可能从主菜单变成了搜索框附近的图标。不用纠结按钮叫什么，关键是进入后能看到“导出”这个动作，而不是只能在窗口里手动复制。导出路径里带中文带空格，txt 本身没问题，但后续脚本传参时要注意转义。
有人问，为什么不直接读数据库直接生成 docx？因为数据库里图片和语音还是分离的，txt 至少把文本链路合并好了。先拿 txt 可以快速判断消息是否全量，成本最低。
3.2 聊天记录迁移到电脑：管住“全量”这一点
PC 端导出的内容受客户端加载进度影响，会话太多时经常只导出一部分。最稳妥的做法是先用手机把全量聊天记录迁移到电脑，再在电脑上导出。手机端路径通常是：设置 -> 通用 -> 聊天记录 -> 聊天记录迁移与备份 -> 迁移聊天记录到电脑。成功后电脑端的消息管理器会合并这部分记录，再去执行 3.1 的导出。
这样拿到的 txt 能覆盖手机上能看到的所有历史消息，而不是只覆盖电脑缓存的那几千条。注意，免费的“聊天记录漫游”只能短暂拉取最近一段时间，到期后服务器会清除，不能把它当全量备份；迁移才是把端上的完整记录搬过来。
3.3 txt 导出的数据边界：到底保留了什么、丢掉了什么
在写转换脚本前，先接受一个现实：txt 导出只适合文字归档。下面是我整理的一张边界表：
| 消息类型 | txt 导出是否保留 | 说明 |
|---|---|---|
| 文本 | 保留 | 原始文字，包括部分表情 |
| 图片 | 只留占位 | 导出后仅[图片]或空 |
| 语音 | 不保留 | 无任何标记 |
| 文件 | 视版本 | 部分版本保留文件名 |
| 撤回消息 | 看版本 | 有的保存“撤回了一条消息” |
| 红包/转账 | 部分 | 如“发送了一个红包”文本 |
| 群系统通知 | 部分 | 入群、退群通知可能有 |
这意味着你生成的 docx 是“文字的完整归档”，不是“多媒体的完整归档”。如果业务上必须把图片一起放进 Word，就要走另一条路：自己解析本地 Image 目录，按消息序号关联，工作量会上一个台阶。对多数项目归档需求，文字加时间戳已经足够。
4. 把 txt / JSON 转成 .docx：python-docx 落地脚本与参数调整
到这一步，你已经有一份原始 txt。接下来要把 QQ 导出的文本变成规范的 Word 文档。我用 python-docx，因为它是处理 docx 最直接的工具，生成的文档在 WPS、Microsoft Word、LibreOffice 里都能正常打开。下面两个脚本是我常用的模板，按需复制。先装依赖：pip install python-docx。
4.1 最小可行脚本：把导出的 txt 解析成结构化 docx
先处理最普遍的场景：文件是 UTF-8，行首是时间戳，发送者占一行，消息内容一行或多行。核心脚本如下：
import re from docx import Document from docx.shared import Pt TIME_RE = re.compile(r"^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} ") def txt_to_docx(in_txt, out_docx): doc = Document() current = None with open(in_txt, "r", encoding="utf-8", errors="ignore") as f: for raw in f: line = raw.strip() if not line: continue if TIME_RE.match(line): if current is not None: write_message(doc, current) parts = line.split(maxsplit=2) current = { "time": parts[0] + " " + parts[1], "sender": parts[2] if len(parts) > 2 else "未知", "content": [] } else: if current is None: current = {"time": "", "sender": "", "content": [line]} else: current["content"].append(line) if current is not None: write_message(doc, current) doc.save(out_docx) def write_message(doc, msg): head = doc.add_paragraph() head.paragraph_format.space_before = Pt(10) run = head.add_run(f"{msg['time']} {msg['sender']}") run.bold = True run.font.size = Pt(10) for text in msg["content"]: p = doc.add_paragraph(text) p.paragraph_format.line_spacing = 1.5 if __name__ == "__main__": txt_to_docx("导出.txt", "聊天记录.docx")这段脚本的行为逻辑：逐行读入，行首匹配到2024-01-15 10:23:11就开一条新消息，把时间和发送者切开；如果没有匹配，就认为这一行是上一条消息的续行，追加到 content 列表。QQ 导出的 txt 对换行消息的处理是拆成多行，所以这个规则够用。
几个容易忽略的参数：
errors="ignore"会静默丢弃无法按 UTF-8 解码的字节，如果发现少了消息，先去掉它，改用gbk编码打开。maxsplit=2是为了防止发送者昵称里的空格把内容切错。切三段后parts[2]就是完整昵称加括号号码。space_before=10控制每条消息之间的间距，太密集打印出来很难读。- 如果你希望把
[图片]替换成可见提示，在 write_message 里加一行：text = text.replace("[图片]", "[图片消息，见资源目录]")。
4.2 手里已经有 JSON 数据时的转换模板
有人会用开源查看器直接解析本地数据库并导出 JSON，这种情况下拿到结构通常是：
[ { "type": "text", "sender": "张三", "time": "2024-01-15 10:23:11", "content": "周末一起吃饭吗", "msg_id": 1001 } ]这个结构比 txt 好处理，因为字段是明确的。转换脚本：
import json from docx import Document from docx.shared import Pt def json_to_docx(json_path, docx_path): with open(json_path, "r", encoding="utf-8") as f: msgs = json.load(f) doc = Document() for item in msgs: msg_type = item.get("type", "text") if msg_type != "text": content = f"[非文本消息: {msg_type}]" else: content = item.get("content", "") head = doc.add_paragraph() head.paragraph_format.space_before = Pt(8) run = head.add_run(f"{item.get('time', '')} {item.get('sender', '')}") run.bold = True run.font.size = Pt(10) doc.add_paragraph(content) doc.save(docx_path) if __name__ == "__main__": json_to_docx("messages.json", "聊天记录.docx")注意三点：第一，JSON 字段名不是标准，不同导出工具可能叫senderName、msgTime，运行前先print(msgs[0].keys())看一遍；第二，非文本消息统一生成占位段落，避免 docx 里出现空白；第三，type为image或voice时，要保留msg_id，后续方便和资源目录对账。
4.3 三个必调参数：中文字体、分卷大小、特殊字符
实际交付中影响观感的三个参数值得单独说。第一个是中文字体。python-docx 默认只设置西文字体，导致 docx 在别的电脑打开后中文回退成等线或宋体。解决方案是同时设置w:eastAsia字体：
from docx.oxml.ns import qn style = doc.styles["Normal"] style.font.name = "微软雅黑" style._element.rPr.rFonts.set(qn("w:eastAsia"), "微软雅黑")第二个是分卷。单会话 5000 条以上，一个 docx 会有几十页，Word 滚动很卡。我在 write_message 里维护一个计数器，每满 1000 条插入一个分页符doc.add_page_break()，把长记录拆成逻辑分卷。
第三个是特殊字符。docx 本质是 zip 内的 XML，python-docx 会转义<和&，但遇到\x00这类控制字符仍会抛错。转换前统一做一次清洗：content = content.replace("\x00", "")，可以避免脚本在凌晨跑到一半崩溃。
5. 避坑：查看 QQ 聊天记录的五个高频翻车场景
数据导出和 docx 转换这两步，我已经翻过好几次车。这里挑五个影响最大也最常见的写下来，每个都按现象、原因、解决三个环节说清楚。
5.1 数据库打开乱码：加密库别硬解
现象：用 SQLiteStudio 或 Navicat 打开msg3.0.db，要么提示file is not a database，要么只能看到空表。
原因：新版 QQ 对消息库做了 SQLCipher 加密，没有密钥时读不到业务表。网上流传的“改文件头”或者“另存为 SQLite”方案基本是在碰运气。
解决：先走客户端 txt 导出，能用官方通道就不要在加密库上耗时。如果只是需要文字记录，txt 导出的字段已经足够。若必须读库，就找专门针对 QQ 本地库做只读导出的开源工具，同时只处理自己登录过的账号数据。
5.2 改后缀生成 .docx：文件损坏是低级的错
现象：把导出.txt直接重命名为聊天记录.docx，双击后 Word 提示文件损坏。
原因：.docx是一个 zip 文件包，内部包含固定的 XML 结构，扩展名不决定格式。
解决：用第 4 章的 python-docx 脚本生成，或用 Word 打开 txt 后“另存为 docx”。改名大法唯一能做到的是自欺欺人，交付出去就是事故现场。
5.3 导出 txt 只有几千条，实际记录却有五万条
现象：消息管理器里确实有会话，导出后的 txt 行数却少得可怜，甚至只覆盖最近一周。
原因：PC 端默认只加载当前窗口可见部分，会话历史没有滚动加载完就点击导出，导出的是内存里已加载的缓存。群聊和频繁聊天的大文件最容易踩中。
解决：导出前先在消息管理器里翻到该会话最底部，触发“加载更早消息”，直到不能继续加载；更可靠的是先用手机迁移功能把全量记录搬到电脑再导出。导出完成后用行数校验一下，见第 6 章。
5.4 拷贝整个 Tencent Files 目录到新电脑：登录后记录还是空
现象：把整个Tencent Files目录用 U 盘拷到新电脑，登录同一个 QQ 号，聊天记录一条都不显示。
原因：客户端的消息记录和设备绑定，数据库里除了消息内容，还有设备相关的关联信息。直接拷贝没有走客户端的迁移流程，新环境不认旧库。
解决：别手动拷贝目录，用 QQ 自带“聊天记录迁移与备份”功能；如果需要跨 PC，也优先用“备份聊天记录到电脑”再做恢复。
5.5 转换后 docx 里的图片全空：txt 本来就不带图
现象：python-docx 转完的文档，正文中所有图片位置只有空白或[图片]。
原因：不是脚本写错了。txt 导出格式本身不包含图片内容，[图片]只是占位文本。
解决：转换时统一替换成带指引的占位文字，例如[图片消息：资源索引见 image_index.csv]，再把 Image 目录的索引单独输出成一份 CSV。这样打开 docx 的人至少知道去哪里找原始图。
6. 验证交付：确认 docx 完整性的三个小技巧
6.1 数量与时间范围的双重校验
转换完先别急着发。用脚本快速统计时间戳数量，和消息管理器里的总数对比：
import re def count_timestamps(txt_path): n = 0 first = last = None with open(txt_path, encoding="utf-8", errors="ignore") as f: for line in f: m = re.match(r"^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) ", line) if m: n += 1 if first is None: first = m.group(1) last = m.group(1) print(f"消息条数: {n}, 最早: {first}, 最晚: {last}") return n条数对不上，先回去把会话加载到底再导出；时间范围对不上，优先怀疑 PC 端缓存不完整。两者都对，再进入抽样。
6.2 抽样比对三个会话点
我在 docx 里随机抽前、中、后三个位置，和手机上同一会话逐条核对。核对重点不是字数，而是：时间戳顺序是否正确、发送人是否错位、多行消息有没有被拆分。群聊里昵称带空格的行最容易出问题，如果多行内容被拆成了两条，说明脚本的正则还需要调。
6.3 交付时附带资源索引表
聊天记录 docx 永远只是“文本层”的归档。图片、文件、语音还在本地目录里，不跟着 docx 走。我一般会额外生成一份资源索引表：
import os import csv with open("image_index.csv", "w", newline="", encoding="utf-8") as f: w = csv.writer(f) w.writerow(["文件名", "大小", "修改时间"]) for name in os.listdir("Image"): st = os.stat(os.path.join("Image", name)) w.writerow([name, st.st_size, st.st_mtime])把 docx、txt、image_index.csv 三个文件放在同一个“交付目录”里打包，这才是完整的聊天记录归档。以前我只交 docx，结果同事一直追着问图片怎么全是空的，后来养成了每次附资源索引的习惯。查看 QQ 聊天记录这个需求，真正难的不是技术，而是把原始数据、资源和可读文档三者对应起来才算做完。希望帮到你。
本文还有配套的精品资源，点击获取
