fix: Live Photo 视频的文件名序号与相对应图片的文件名序号不匹配，且视频以及 Live Photo 视频的文件名与图片的文件名格式不一致问题

[YuanChenCheung]

PR Title

fix: Live Photo 视频的文件名序号与相对应图片的文件名序号不匹配，且视频以及Live Photo 视频的文件名与图片的文件名格式不一致问题

PR Description

问题描述 / Problem

微博 API 返回的 live_photo 数组是独立于 pics 数组的顶层字段，两者各自从 0 开始计数。当一条微博同时包含普通图片和 Live Photo 时，live_photo 列表中的视频无法正确定位其在 pics 中的对应图片位置，导致下载后视频文件名与对应的静态图片文件名序号不匹配。

举例： 一条微博有 4 张图，其中第 1 张为普通图片，第 2/3/4 张为 Live Photo：

文件	修复前	修复后
图片 1（普通）	2024-01-15_10-30-00_1.jpg	2024-01-15_10-30-00_1.jpg
图片 2（Live Photo）	2024-01-15_10-30-00_2.jpg	2024-01-15_10-30-00_2.jpg
图片 3（Live Photo）	2024-01-15_10-30-00_3.jpg	2024-01-15_10-30-00_3.jpg
图片 4（Live Photo）	2024-01-15_10-30-00_4.jpg	2024-01-15_10-30-00_4.jpg
Live Photo 视频 1（对应图片 2）	20240115T_xxxxxxxxxxx_1.mp4	2024-01-15_10-30-00_2.mp4
Live Photo 视频 2（对应图片 3）	20240115T_xxxxxxxxxxx_2.mp4	2024-01-15_10-30-00_3.mp4
Live Photo 视频 3（对应图片 4）	20240115T_xxxxxxxxxxx_3.mp4	2024-01-15_10-30-00_4.mp4

根因分析 / Root Cause

旧的 get_live_photo_url() 直接读取 API 返回的顶层 live_photo 数组，该数组仅包含 Live Photo 视频 URL，索引从 0 开始独立计算，不感知 pics 中普通图片的存在。当普通图片与 Live Photo 混合时，两者序号必然错位。

而 API 返回的 pics 数组中，每个条目带有 type 字段（"livephoto" 表示 Live Photo），且 Live Photo 条目包含 videoSrc 字段（即实际视频 URL），同时还包含 pid 信息。因此正确的做法是从 pics 中提取 Live Photo 信息，而非依赖独立的 live_photo 数组。

解决方案 / Solution

重写 get_live_photo_url()，改为遍历 pics 数组（使用与 get_pics() 完全一致的过滤逻辑），从 type: "livephoto" 的条目中提取 videoSrc 字段，并记录每条视频在过滤后 pics 中的 1-based 位置索引。同时将其返回类型从纯字符串改为包含 url 和 indices 的字典。

下载和 Markdown 文件名生成时，使用该索引替代独立计数，确保 Live Photo 视频文件名与对应静态图片文件名序号一致。

修改文件 / Files Changed

weibo.py (5 处修改)

1. get_live_photo_url() — 重写，从 pics 数组提取 videoSrc 并返回 {"url": ..., "indices": [...]} 字典
2. parse_weibo() — 同时存储 live_photo_url 和 live_photo_indices
3. handle_download() — video 和 live_photo 下载逻辑拆分为独立分支，live_photo 分支使用 live_photo_indices 命名
4. get_download_file_names() — 同上拆分，用于 Markdown 链接生成
5. get_write_info() — 从输出中排除内部字段 live_photo_indices

兼容性 / Compatibility

• 向后兼容： live_photo_url 仍为分号分隔的 URL 字符串，存量数据和下游消费者不受影响
• 回退机制： 若 live_photo_indices 缺失，自动回退到 j+1 的独立计数方式

[YuanChenCheung]

PR Title

feat: 新增 markdown_image_order 配置，支持两种图片与 Live Photo 的排列模式。

PR Description

变更概述

在 Markdown 输出模式中，新增 markdown_image_order 配置项，允许用户在两种图片与 Live Photo 的排列模式之间切换。

变更内容

新增配置项 markdown_image_order（config.json）

• live_photo_first（默认，保持向后兼容）：所有 Live Photo 在前，图片在后
• image_first_interleaved（新增）：图片优先排列，同名 Live Photo 插入到对应图片正下方

示例对比（为了不影响预览，默认目录 img 均更改为 im g）

live_photo_first（现有模式）：
[Live Photo 1](原创微博Live Photo视频/2026-07-01_22-00-00_1.mov)

[Live Photo 2](原创微博Live Photo视频/2026-07-01_22-00-00_3.mov)




image_first_interleaved（新增模式）：
[Live Photo 1](原创微博Live Photo视频/2026-07-01_22-00-00_1.mov)


[Live Photo 2](原创微博Live Photo视频/2026-07-01_22-00-00_3.mov)

兼容性

• 完全向后兼容：默认值为 live_photo_first，现有用户升级后无需修改配置，行为与之前完全一致
• 仅在用户主动将 markdown_image_order 改为 image_first_interleaved 时启用新模式
• 对非 Markdown 输出模式（csv、json 等）无任何影响

[YuanChenCheung]

PR Title

feat: 新增 markdown_preview 配置，支持各类媒体文件在 Markdown 中的预览开关。

PR Description

变更概述

在 config.json 中新增 markdown_preview 配置块，允许用户独立控制八种媒体类型在生成的 Markdown 文件中是否使用 ! 语法实现直接预览。

此前 Markdown 输出中，图片使用 ![img](path) 直接渲染预览，而网页链接、视频、Live Photo 使用 [label](path) 普通链接。这种硬编码行为无法满足不同 Markdown 阅读器的查看偏好——有些用户希望统一预览，有些用户希望全部显示为普通链接以减少渲染开销。

变更内容

新增配置块 markdown_preview（config.json）

配置项	默认值	说明
link_preview	0	网页链接
original_video_preview	0	原创微博视频
retweet_video_preview	0	转发微博视频
original_image_preview	1	原创微博图片
retweet_image_preview	1	转发微博图片
original_live_photo_preview	0	原创微博 Live Photo
retweet_live_photo_preview	0	转发微博 Live Photo
inline_image_preview	1	正文中"查看图片"占位符

每个选项取值 0（普通链接 [text](url)）或 1（预览 ![text](url)）。

兼容性

• 完全向后兼容：默认值与现有硬编码行为一致（图片预览，其余不预览），现有用户升级后无需修改任何配置
• 用户可自由组合 8 个开关，实现任意预览策略（如全预览、全不预览、仅视频预览等）
• markdown_preview 非必填项，缺失整个块或部分 key 均自动使用默认值
• 对非 Markdown 输出模式无任何影响

[YuanChenCheung]

PR Title

feat: 新增 markdown_file_dir 与 download_folder_name 配置，支持自定义媒体文件的存储目录名。

PR Description

变更概述

新增 markdown_file_dir 和 download_folder_name 两个配置块，允许用户自定义六类媒体文件（原创/转发图片、原创/转发视频、原创/转发 Live Photo）在 Markdown 中的相对路径以及下载到本地的存储目录名。

此前所有媒体文件的目录名均为硬编码。其中图片的逻辑最为复杂，存在两套不同的路径约定：

场景	图片路径	视频/Live Photo 路径
非 markdown 模式下载 (download_files)	原创微博图片/、转发微博图片/	原创微博视频/、原创微博Live Photo视频/ …
markdown 模式下载 (download_markdown_images)	统一 img/（不区分原创/转发）	N/A（不走此路径）
Markdown 文件中的链接 (generate_markdown_file)	img/xxx.jpg（不区分原创/转发）	原创微博视频/xxx.mp4、原创微博Live Photo视频/xxx.mov …

这种不一致导致用户无法统一自定义。本次变更将两个维度的路径均暴露为配置项，同时完全保留原始默认值，确保向后兼容。

变更内容

新增配置块 markdown_file_dir（config.json）

控制 Markdown 文件中各媒体链接使用的相对路径目录名，以及 markdown 模式下图片下载的目标目录名。

配置项	默认值	对应原始硬编码
original_image_dir	img	img/
retweet_image_dir	img	img/
original_video_dir	原创微博视频	原创微博视频/
retweet_video_dir	转发微博视频	转发微博视频/
original_live_photo_dir	原创微博Live Photo视频	原创微博Live Photo视频/
retweet_live_photo_dir	转发微博Live Photo视频	转发微博Live Photo视频/

新增配置块 download_folder_name（config.json）

控制非 markdown 模式（以及 markdown 模式中视频/Live Photo）下载到本地的目录名。

配置项	默认值	对应原始硬编码
original_image_folder	原创微博图片	原创微博图片/
retweet_image_folder	转发微博图片	转发微博图片/
original_video_folder	原创微博视频	原创微博视频/
retweet_video_folder	转发微博视频	转发微博视频/
original_live_photo_folder	原创微博Live Photo视频	原创微博Live Photo视频/
retweet_live_photo_folder	转发微博Live Photo视频	转发微博Live Photo视频/

兼容性

• 完全向后兼容：默认值与原始硬编码完全一致，现有用户升级后无任何行为变化
• 两个配置块均非必填，缺失整个块或部分 key 自动使用默认值
• 对非 Markdown 输出模式无任何影响

[YuanChenCheung]

PR Title

refactor: 新增 config.json.example 模板，将 config.json 从版本控制中移除。

PR Description

变更概述

新增 config.json.example 作为版本控制中的配置模板，将 config.json 从 git 追踪中移除并加入 .gitignore，避免用户每次 git pull 时因本地配置差异产生合并冲突。

config.json 包含用户的个人配置（Cookie、自定义目录名等），每个人的本地配置都不同。当上游通过 git pull 更新默认配置时，用户本地修改过的 config.json 会与上游产生冲突，每次都需要手动解决。

变更内容

新增 config.json.example

原 config.json 重命名为 config.json.example，作为版本控制中的默认模板。

修改 weibo.py — get_config() 加载逻辑

配置文件加载优先级：

1. config.json（用户本地文件）— 优先使用
2. config.json.example（版本控制中的模板）— 回退使用

当两个文件都不存在时，程序退出并给出错误提示。
当仅存在 config.json.example 时，程序使用它运行，并提示用户复制一份。

修改 .gitignore

新增 config.json，使其不再被 git 追踪。

用户升级指南

由于 config.json 不再被 git 追踪，升级时：

1. 如果你已经有 config.json：无需操作。git pull 后本地配置不受影响
2. 如果你想使用新版本新增的配置项：参考 config.json.example 中的新内容，手动合并到你的 config.json
3. 初次使用：cp config.json.example config.json 然后编辑

兼容性

• 完全向后兼容：现有用户升级后无任何行为变化

[YuanChenCheung]

PR Title

feat: 新增 markdown_sort_order 与 missing_weibo_report 配置，修复转发图片下载不尊重 retweet_pic_download 的 bug。

PR Description

变更概述

本次变更包含三个独立改进：

1. 新增 markdown_sort_order 配置，控制同一分组内多条微博的排序方向
2. 新增 missing_weibo_report 功能，在每次爬取结束后生成缺失微博报告
3. 修复 bug：download_markdown_images 中转发图片下载不尊重 retweet_pic_download 配置

变更内容

新增配置项 markdown_sort_order — 微博排序配置

假设同一天内有三条微博，发布时间分别为 10:00、14:00、18:00：

new_to_old（默认）：

### 18:00:00
<!-- weibo_id: 9999 -->
今天傍晚的动态...
---
### 14:00:00
<!-- weibo_id: 9998 -->
下午的动态...
---
### 10:00:00
<!-- weibo_id: 9997 -->
早上的动态...
---

old_to_new（默认）：

### 10:00:00
<!-- weibo_id: 9997 -->
早上的动态...
---
### 14:00:00
<!-- weibo_id: 9998 -->
下午的动态...
---
### 18:00:00
<!-- weibo_id: 9999 -->
今天傍晚的动态...
---

新增配置项 missing_weibo_report — 缺失微博报告

程序每次重新爬取全量微博，但 md 文件使用增量去重写入。如果某条微博在上次爬取时存在、本次爬取时已被博主删除，md 文件中会永久保留旧记录，用户没有任何提示。

开启该功能后，每个用户爬取结束后，在 output_directory（默认 weibo_data）下生成一份报告文件。

兼容性

• 完全向后兼容：所有新配置项默认值均保持当前行为不变，现有用户升级后无任何行为变化
• missing_weibo_report 默认 0（关闭），用户需主动开启
• markdown_sort_order 默认 "new_to_old"，与当前 API 返回顺序一致
• 修复的 bug 仅影响 retweet_pic_download: 0 用户，修正为预期行为