简介这款新浪微博备份工具专为需要长期保存个人微博数据的普通用户设计可将账号中的文字、图片、评论以及个人收藏等内容一键导出并保存到本地电脑有效避免微博内容因账号异常或平台调整而丢失。工具压缩包采用rar格式整体仅1.87MB包含12个文件主要由exe主程序、多个dll运行库、css样式、txt说明、doc使用文档、dat数据文件及url快捷方式组成内置新旧两个版本新版依赖.NET 2.0运行环境压缩包中已提供相关组件入口。目前已有510人下载学习。使用过程中只需登录微博账号并输入需要备份的地址即可批量抓取并导出目标账号的全部微博内容包括图片评论等完整信息附带的doc与txt说明文档还能帮助用户快速解决不同系统环境下的运行依赖问题轻松完成微博数据的本地化归档与后续查阅。1. 被翻出来的老工具新浪微博备份工具在 2025 年还能做什么很多人是在清理硬盘时翻到这个「新浪微博备份工具v2013.0117中文绿色免费版」压缩包的名字里带着年份和版本号一股浓烈的上古气息。但这恰恰说明它踩中了需求微博数据一直在你手上但平台随时可能改规则、下架内容、限制导出。这个工具诞生于新浪微博开放平台 API 还比较宽松的年代核心价值是把你的微博正文、图片地址、转发评论等数据拉到本地存成结构化文件。它体积小、免安装、双击能用在当时是个人存档微博的标准做法。现在你还能不能直接用这套程序坦白说2013 年的授权接口早已失效直接打开多半停在登录页。但它的备份思路完全不过时而且按当年的流程走一遍你能搞清楚微博备份到底存了什么、漏了什么、图片链接为什么会挂。这篇文章就围绕这个工具讲清楚四件事它的原理是什么、当年的绿色版是怎么运作的、今天你要备份微博该怎么搭一套能跑的流程以及那些隔了十年依然会踩的坑。适合手上有老备份想整理、或者想系统备份自己微博数据的开发者。2. 备份工具的原理解析2013 年版靠什么把数据搬回本地2.1 老版新浪微博开放 API 的授权方式与数据边界2013 年前后的新浪微博开放平台个人开发者可以通过 OAuth 授权拿到用户的 access token然后调用 statuses/user_timeline 这类接口拉取指定用户的微博列表。这个工具做的就是这件事你输入账号密码完成授权工具拿着 token 去请求接口一页一页翻你的微博解析成 JSON 再落盘。那个年代接口有一个特点——它返回的字段比你今天在网页上看到的更「原始」。微博正文、发布时间的 Unix 时间戳、来源设备、转发数、评论数、图片的 URL 列表甚至当时的地理位置信息都会在 JSON 里给到。所以备份出来的数据并不是简单的文本文件而是一个可以被二次处理的数据库。很多后来做微博分析、个人年度报告的作者最初的数据来源就是这类备份。但要说清楚边界它备份的是「能通过 API 拿到的公开或授权范围内的数据」。私信、删掉的微博、仅粉丝可见的内容接口就返回不了。工具本身不会做任何绕过权限的事情这也是为什么它当年能被做成绿色免费版而没被平台封杀——它就是一个合规的数据导出客户端只是把网页上你能看到的自己内容批量拿下来。2.2 数据落盘结构JSON、时间戳与图片 URL 的关系用这个工具备份完成后会在指定目录生成按月份组织的文件夹每个文件夹里是若干 JSON 文件。每一条微博对应一个 JSON 对象里面的字段长这样{ id: 3623123456789012, created_at: 1357000000, text: 这是一条备份测试微博, source: iPhone客户端, reposts_count: 12, comments_count: 3, attitudes_count: 5, pic_urls: [ http://ww1.sinaimg.cn/large/abc123.jpg, http://ww2.sinaimg.cn/mw600/def456.jpg ], geo: null }这个 JSON 结构基本就是当年 API 的报文精简版工具的作用是把报文里的业务字段抽出来按 id 去重后存盘。注意 created_at 是 Unix 时间戳表示从 1970 年 1 月 1 日到发布时刻的秒数这个设计让排序和按时间筛选很方便但人眼读不懂。更关键的是 pic_urls 里的图片地址它指向新浪图床的外链域名是 ww1.sinaimg.cn 这类子域。图片本身并没有下载到本地。这既是绿色版体积小的原因也是后来备份失效的重灾区——网站域名迁移、图床规则变更、原图被平台清理链接随时会 404。所以后来做微博备份的人基本都会再写一步单独把图片拉下来这就属于备份工具之外的事情了。当年工具没做这一步能理解毕竟 2013 年没人想到十年后这些链接会大面积失效。2.3 绿色免安装的本质静态文件解压与配置读取「绿色版」三个字在 2013 年意味着不需要写注册表不需要安装运行库依赖解压即用。这款备份工具能做成绿色版是因为它的本体是一个可执行文件加一个 config.ini 配置文件外加几个存放数据的文件夹。程序启动时读取 config.ini 里的授权信息和备份路径不向系统目录写任何东西。[account] username your_weibo_account expires_in 2592000 [backup] save_path ./backup time_range all media_download false include_comments true [api] base_url https://api.weibo.com/2/statuses/user_timeline.json page_size 200这段配置文件展现了核心参数。expires_in 是 access token 的有效期单位是秒2592000 是 30 天意味着你每 30 天需要重新授权一次。save_path 决定备份输出目录默认存在程序所在目录的 backup 文件夹下。time_range 支持 all 或具体日期media_download 控制是否下载图片include_comments 控制是否连带拉取评论列表。我一般会建议第一次备份时把 time_range 设为 allmedia_download 设为 false。原因很简单先拿到文本数据做索引确认备份逻辑正常再补图片下载避免一次跑太久出错后全部重来。page_size 这个参数值得注意API 单页最多返回 200 条设小会导致请求次数变多设大对老接口来说容易触发频率限制。工具默认 200 是合理的但如果你的微博超过 5000 条整个备份过程会持续数小时中间断掉的概率不小。3. 实操复现从授权到导出一步步跑通微博备份流程3.1 授权环节旧版接口失效后怎么处理既然是 2013 年的工具你在今天运行它遇到的第一个问题一定是授权失败。微博开放平台在 2013 年之后经历过多次接口升级老版本 OAuth 授权页和 token 校验方式都不再支持。直接点「开始备份」会返回错误提示这不是你操作有误而是服务端已经不认识这个客户端了。常见做法是不要硬试老程序的登录按钮把授权环节拆出来单独处理。我们在后面章节会给出一个现代的替代方案用当前可用的开放接口重新拿 token然后把 token 手动填进工具的配置项里。老工具只要能跳过登录界面、拿到一个有效的 token它后续的抓取逻辑依然能工作——因为数据接口域名虽然变了但响应 JSON 的核心结构并没有完全改掉。不过这里有个现实约束当前个人注册微博开放平台应用接口权限审批比 2013 年严格得多。大部分人的账号根本没有调接口的权限。所以更靠谱的路径是放弃老工具自带授权改用模拟网页登录的方式获取 cookie再用 cookie 请求移动端接口。这方面的工具链已经比较成熟下面给出一份可用的最小脚本参考。3.2 用 Python 模拟会话获取 cookie 并拉取微博列表import requests import json from bs4 import BeautifulSoup # 第一步获取登录页的 pincode 和 加密参数 session requests.Session() login_page session.get(https://passport.weibo.com/signin/login) soup BeautifulSoup(login_page.text, html.parser) # 第二步构造登录 POST 请求携带用户名和加密后的密码 # 注意此处需要引入一个 rsa 加密模块微博登录密码是先用 RSA 公钥加密的 login_data { username: your_weibo_username, password: rsa_encrypt(your_password), entry: mweibo, returntype: M2, url: https://weibo.com/ajax/login, } resp session.post(https://passport.weibo.com/sso/login, datalogin_data) # 第三步用会话中的 cookie 请求用户时间线接口 cookies session.cookies.get_dict() api_url https://weibo.com/ajax/statuses/mymblog params { page: 1, feature: 0, } headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), } statuses session.get(api_url, paramsparams, headersheaders, cookiescookies) # 第四步解析 JSON 并提取正文、时间、图片列表 data statuses.json() for item in data.get(data, {}).get(list, []): print(item[text], item[created_at])这段脚本的核心是 Session 对象它维护了登录后的 cookie 状态。第一步访问登录页是为了获得服务端下发的加密种子和临时参数第二步的 rsa_encrypt 函数将密码加密后提交第三步请求 weibo.com 域名下的 mymblog 接口这个接口会返回当前用户最新发布的微博。第四步的提取逻辑就是当年备份工具的简化版。参数说明page 是页码feature 决定是否包含转发的微博0 表示只取原创headers 里的 User-Agent 必须设置为浏览器标识否则服务器会拒绝请求。这个接口并不对第三方应用开放它是微博网页版前端自己调用的所以能绕开开放平台的审批限制但代价是接口随时可能调整参数结构你需要紧跟网页端的变化。我一般会把 headers 和 cookies 单独存成文件避免每次登录触发风控。3.3 数据清洗与本地存储按天归档并去重拿到 JSON 后你不能直接存原始报文因为同一页可能包含转发的原微博和当前用户转发的记录内容存在嵌套。需要做一层扁平化处理把真正需要保留的字段抽出来再写入本地文件。import sqlite3 import datetime conn sqlite3.connect(weibo_backup.db) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS statuses ( id INTEGER PRIMARY KEY, created_at TEXT, text TEXT, source TEXT, reposts_count INTEGER, comments_count INTEGER, pic_urls TEXT, crawled_at TEXT ) ) for item in raw_list: # 只保留原创微博is_retweeted 为真时忽略 if item.get(is_retweeted): continue ts int(item[created_at]) created_at datetime.datetime.fromtimestamp(ts).strftime(%Y-%m-%d %H:%M:%S) pic_urls ,.join(item.get(pic_urls, [])) if item.get(pic_urls) else cursor.execute( INSERT OR IGNORE INTO statuses VALUES (?,?,?,?,?,?,?,?), (item[id], created_at, item[text], item[source], item.get(reposts_count, 0), item.get(comments_count, 0), pic_urls, datetime.datetime.now().isoformat()) ) conn.commit()这段代码用 SQLite 存储清洗后的数据id 作为主键INSERT OR IGNORE 保证重复抓取时不会插入相同微博。created_at 换成人类可读格式方便直接查询。pic_urls 把图片地址列表用逗号拼接成一个文本字段这样在数据库里看不到多对多关系但足够支撑后续的图片批量下载任务。写入数据库而不是 JSON 文件的好处是支持 SQL 查询统计增量备份时可以按 id 判断哪些微博已经存在。我在实际备份时会先执行一次全量抓取写入数据库之后每周跑一次增量脚本只抓最新页码。这个流程比当年工具的一次性导出更抗风险因为你随时可以断点续传不需要担心一个长任务中间失败就丢失全部进度。3.4 图片批量下载处理防盗链和时间戳命名微博图片的地址看起来是 http://ww1.sinaimg.cn/large/xxx.jpg但直接拿这个 URL 去 requests.get 很容易返回 403。这是因为图床开启了防盗链要求请求头里带 Referer 字段并且 UA 不能是纯 Python 脚本。加上这两项后就能正常下载。import os import requests from urllib.parse import urlparse pic_dir ./images os.makedirs(pic_dir, exist_okTrue) headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://weibo.com/, } for row in cursor.execute(SELECT id, pic_urls FROM statuses WHERE pic_urls ! ): status_id, pic_urls row for url in pic_urls.split(,): if not url.startswith(http): continue # 只取 URL 最后一段作为文件名防止图片服务商重定向导致重复下载 filename os.path.basename(urlparse(url).path) filepath os.path.join(pic_dir, f{status_id}_{filename}) if os.path.exists(filepath): continue try: resp requests.get(url, headersheaders, timeout10) if resp.status_code 200: with open(filepath, wb) as f: f.write(resp.content) except requests.exceptions.RequestException: print(f下载失败: {url})关键参数是 Referer它告诉图床你来自微博页面本身。timeout 设 10 秒防止某张图卡住整个任务。文件名前面拼接 status_id这样可以通过微博 id 反查某张图属于哪条内容。图片下载必须做断点续传的检查因为几百张图里总会有几张因为网络抖动失败重新跑一次只会补下缺失的文件。在这个时候你会深刻体会到当年工具把 media_download 默认设为 false 的原因图片下载太慢了。如果你的微博量很大图片下载时间可能是文本备份的十倍。我把这个任务设计成可中断的CtrlC 停掉后再次运行依然续传这是老工具做不到的体验。4. 备份过程中常见的 5 个坑现象、原因和解决方法4.1 授权成功但接口返回 403 Forbidden现象token 有效登录也成功但请求 statuses/user_timeline 时返回 403。原因当年开放的接口权限已经关闭老应用被平台清理或者你请求的接口域名迁移到了新地址。解决不要执着于老接口。换成网页端 mymblog 接口或者使用移动端 m.weibo.cn 的 API这两类接口是当前网页和手机端真正在用的服务器因此会正常响应。同时在请求头中带上完整的浏览器标识403 有很大一部分是因为 UA 被识别为脚本。4.2 备份出来的文本乱码现象JSON 文件里的中文变成 \uXXXX 转义序列或者数据库里显示乱码。原因老工具在 2013 年默认用 GBK 编码写文件而你今天用 UTF-8 打开自然乱码。另一个情况是接口返回的内容本身带有 HTML 标签你存的文本里夹着 这种未清洗的片段。解决写文件时强制指定 encodingutf-8读取老备份文件时用 gbk 解码再转成 utf-8。文本清洗时用正则把 .*? 标签去掉再把 之类的实体转换回来。这两步做完脏数据才能进入分析和展示环节。4.3 图片批量下载后无法打开现象download 下来的图片文件大小只有几 KB用图片查看器打开提示文件损坏。原因图床返回的不是图片内容而是一个 HTML 跳转页面。这是因为请求时没有携带 Referer服务器把你当成盗链请求返回一个防盗链提示页。解决检查下载文件的前几个字节正常的 JPEG 以 \xFF\xD8 开头HTML 以 !DOCTYPE 开头。在下载循环里加一个文件头校验发现是 HTML 就重试重试时带上 Referer 和完整的浏览器 UA。另外有些图片链接带有 HTTP 302 重定向requests 默认会跟随但如果目标域名变了需要确认最终 URL 的扩展名。4.4 增量备份时重复抓取旧微博现象第二次运行时数据库里出现大量重复记录id 相同但 crawled_at 不同。原因mymblog 接口只按 page 翻页不会告诉你某条微博是否已在库里。你如果只是从头翻到尾必然把上次已存的微博再次插入。如果 INSERT OR IGNORE 没生效说明 id 字段没有设置为主键。解决确认数据库表里 id 是 INTEGER PRIMARY KEYINSERT 语句使用 OR IGNORE 修饰。更进一步的做法是记录上次备份成功的最大页码和最后一条微博 id下次从那个位置开始抓。这样即使每次只抓最新的 10 页也能保证没有空隙。4.5 界面卡死或长时间无响应现象程序运行时窗口一直转圈CPU 占用不高但备份进度好几分钟不动。原因2013 年工具是单线程设计遇到网络超时会阻塞住整个流程。接口频率限制也会导致服务端延迟响应工具没有做超时控制和重试机制就一直等下去。解决放弃老程序界面改用 Python 脚本做备份。requests 库可以设置 timeout并在异常时捕获后休眠 5 秒重试。连续失败 5 次就跳过该页并记录日志这样即使微博数量很大脚本也能稳定跑完。你会发现命令行窗口输出的一行行日志比任何进度条都更能让你安心。5. 备份数据的二次利用把十年微博变成可查询的个人档案备份做完数据躺在 SQLite 里并不产生价值。真正值钱的是你怎么用它这决定了整个备份项目值不值得花一个周末去做。我在这部分分享三个最实用的进阶方向你可以按需选择。先看按年统计发布频率的 SQL它能帮你看自己的微博使用习惯变化SELECT strftime(%Y, created_at) AS year, COUNT(*) AS status_count FROM statuses GROUP BY year ORDER BY year DESC;这段 SQL 直接输出每年的发博数量。结合你某年突然活跃或突然沉寂的记录能看到生活状态的变化几乎算一种个人历史数据考古。如果你做年度回顾这就是最核心的图表数据来源。第二个方向是做全文搜索。SQLite 的 LIKE 查询在数据量超过几万条时会明显变慢所以我会用 FTS5 建立全文索引CREATE VIRTUAL TABLE statuses_fts USING fts5(content, contentstatuses); INSERT INTO statuses_fts(rowid, content) SELECT id, text FROM statuses; -- 查询包含出差的微博 SELECT * FROM statuses_fts WHERE statuses_fts MATCH 出差;注意 contentstatuses 是外部内容表语法意味着 FTS 索引只存索引不复制数据节省空间。查询速度比 LIKE 快一到两个数量级即使十万条微博也是毫秒级返回。这个功能对查找很多年前发过的某条重要信息特别有用你早就不记得发布时间和关键词但搜索能瞬间把上下文捞回来。第三个方向也是我强烈推荐做的把备份结果导出成一个离线 HTML 文件用时间线方式展示所有微博和图片。你可以用 Python 遍历数据库按照时间逆序生成一个单一的 HTML 文件图片用本地相对路径引用。这样你不需要任何服务器双击 HTML 就能按年份翻看自己的微博历史。如果在意隐私直接把这个文件夹压缩加密放在移动硬盘里比任何云端存档都安心。我自己做这件事的教训是不要在第一次备份时就追求完美。先跑通文本备份再决定要不要图片最后才上全文索引和 HTML 导出。很多人在图片下载那一步耗光了耐心反而连最基本的文本都没保住。微博备份本质上是和时间赛跑网页端数据随时可能因为内容审核变成「仅自己可见」所以每一步完成的备份都算赚到。希望这些思路能帮你把手上的数据真正沉淀下来哪怕时隔十年也能翻出值得回味的片段。本文还有配套的精品资源点击获取