Edit Diary: nas media

Signed-off-by: SilverAg.L <caclx@outlook.com>

docs/diaries/wbsy/nas-media.md

@@ -66,42 +66,85 @@ volumes:
   - 没招，默认合并（甚至可以看到重复的曲号，都是第六首）。只能手工分离（`Fragrance - SoundzImage`和`Fragrance - Hatsune Miku`）。
 :::
 
-### 电子书：组织难绷，查阅也难绷
+### 电子书：吃力不讨好
 
-至于小说漫画，或者说书籍媒体库，那只能说真搭一个私人图书馆也是同样的格式要求。平时在各种论坛搜罗的 TXT、DOC(X) 显然难登“书架”之上。
+至于小说漫画，或者说书籍媒体库，那只能说真搭一个私人图书馆也是同样的编排要求，满满的工作量。
 
-但 Jellyfin 对书籍库的编排属于是并不上心（也许他们真在用 Calibre？到处都能看到推荐它的），默认是文件夹视图，却又因为元数据裸放要求一本（或者说一章？一话？）一个文件夹。这棵文件夹子树能长多繁茂我都不敢想。
+> 不禁想到米哈游创始人蔡浩宇的“快乐守恒定律”：你做的过程中如果很轻松快乐，那么你做出来的结果未必能给人带来快乐。  
+> 媒体库编排是不是也要“苦其心志、劳其筋骨”，借阅者、用户才能有好的体验呢？但话又说回来，像 Jellyfin 这样的家庭影院通常都是自己管理自己用，费那么大功夫组织这些文件，观赏的体验又能改善多少呢？
+
+我相信大多数\*并不在乎资源来源\*的读者去找网络上流通的小说肯定优先去找 txt、doc(x) 这种容易打开的格式。但现有的私人图书馆，无论 Jellyfin 这种顺手实现的，还是 Kavita 这种专用的，**都不支持这些格式**。Calibre 也许可以，但**书目的元数据就成了另一桩麻烦事**。
 
 ::: tip 最简方案
-那当然是通通转换成 PDF，单纯当作文件管理器那样访问文件夹、文件最简单。只是这种方法对于文字读物不太友好。毕竟 **PDF 只能缩放整页，内容又不会自适应**。
+那当然是通通转换成 pdf，单纯当作文件管理器那样访问文件夹、文件最简单。**但 pdf 对移动端并不友好，文字内容并不能自适应，更多还是用于漫画**。
 :::
 
-尝试一番之后，的确还是适应它们那一套更为高效。Jellyfin 这边对于文本读物最友好的还是 EPUB（当然阅读体验也就那样，但总比 PDF 好）。至于漫画，通用的扩展名是`.cbz`、`.cbr`、`.cb7`（对应`.zip` `.rar` `.7z`）。其中 Jellyfin 只支持前两种。查了下 vivo 的 BlueLM Copilot，似乎`.cbr`的支持也算不上好，所以建议还是`.cbz`。
+进阶一点的方案就只能按照文档来了。啰嗦是显然的，但如前面的“快乐守恒定律”所言，苦一苦自己，阅读体验才能好起来。
 
-元数据这一块，Jellyfin 似乎集成在电子书里还是裸放均可（仅考虑上述格式）。我还是觉得集成更好，要不然漫画每一话都开一个文件夹裸放`.cbz`和`ComicInfo.xml`，我是觉得有些抽象。
+首先讨论相对容易些的漫画。“画”嘛，总归是一张张的图片序列。把它们打成压缩包[^compress]（当然多数网站已经打好包给你下载了），我们就得到本体了。顺带一提`.cbz`即`.zip`，`.cbr`即`.rar`，`.cb7`即`.7z`，有需要的话改个后缀名就是了。至于元数据，Jellyfin 文档指出**只有 epub 书籍才允许元数据集成在文件里**，对于这种漫画压缩包，需要另写`ComicInfo.xml`。也就是说，**每一本、系列的每一话，都需要单独的文件夹放置元数据和本体**。
 
-::: info EPUB 索引
+[^compress]: 还请注意**不要把文件夹层级包含进去**。换言之，用软件打开压缩包应**直接显示图片序列**。
-现有的 EPUB 编辑器几乎都是放个 HTML 编辑器让用户手改。基于此，的确不如考虑用在线转换器，一键导入 TXT 等通用格式。但这种转换出来的 EPUB 的目录似乎无法跳转（只能逐页翻），暂时还不知道怎么回事。
+
+然后是 epub 电子书，它的话则更麻烦亿些。现有的 epub 编辑器并没有像写 bilibili 专栏（或者像 Word 文档）那样自动编纂页面的能力，操作起来更像是手搓 HTML 博客。所以，**图方便的话更建议在线转换**`.txt` `.doc(x)`文档。
+
+::: details EPUB 内容物
+epub 的 mimetype 通常标`application/epub+zip`，说明其本质是压缩包。解压出来通常分这么几块：
+- `mimetype`：资源类型标识，内容如上。
+- `META-INF/container.xml`：标明电子书（OEBPS 包）的根目录。
+- `OEBPS/`
+  - `Images/cover.*`：封面
+  - `Styles/*.css`：网页排版
+  - `Text/*.*htm*`：反正必须是 HTML。
+  - `content.opf`：电子书的元数据、内容物信息。
+  - `nav.*htm*` `nav.opf`：电子书的目录。前者为 epub3 标准，后者为 epub2 标准，通常在`content.opf`里特别标注。
+  - `Fonts/` `Audio/` ...：其他内容。
+
+所以我称编辑 epub 这件事为“手搓 HTML 博客”，因为本来就需要按章回编排 HTML 内容。每一章是一页 HTML，不恰好对应一篇博文吗？
+:::
+
+::: warning 书目目录索引
+和 Calibre 等阅读器不同，Jellyfin 对目录的跳转**以 OEBPS 包为基准**，而不是以目录文件为基准。如果发现 Jellyfin 里**点目录里的章标题没有反应**，你需要用 Sigil 等编辑器将`nav.*`移动到`OEBPS/`目录下。
+:::
+
+::: note 文件组织
+实测结论是：可以不像漫画那样遵循官方文档“一书一目录”的要求，但**应尽量避免“一目录只有一 epub”的情形**。像以下情形 Jellyfin 会误判：
+
+- Books
+  - 正经的
+    - 《时间简史》.epub
+    - 毛泽东
+      - 《实践论》.pdf
+      - 《矛盾论》.pdf
+    - 《葬送的芙莉莲》.pdf
+  - 不正经的
+
+扫描结果是：“不正经的”和《时间简史》。其余读物无法直接访问（可能仍能搜索到）。
 :::
 
 ### 元数据刮削：一笔糊涂账
-前面我也论述过，音乐专辑的元数据库就是几桌草台班子。但比起草台班子，更令我恼火的当属大把大把的、查无此作的“黑户”。怎么来的？音声、同人志、网文。
+前面我也论述过，音乐专辑的元数据库就是几桌草台班子。但比起草台班子，更令我恼火的当属大把大把的、查无此人的“黑户”。怎么来的？音声、同人志、网文。
 
 > 我的整理方式和 acgdb 类似：3D 区、音声区（作者分发、油管录播、DLsite 正作）、书目区（漫画和文集）、写真区、插画区。
 
-3D 区无论玩恋活还是 MMD，既有图集又有视频，无法按媒体类型区分（即便真要分，它算电视节目？电影？MV？分不明白）。音声区大量的音频资源，摆烂一点直接用电子书库、按文件夹访查也不是不行，但显示出来反倒是专辑名（或者说 DLsite、系列作品名）更显眼，而非每一集的标题；若要用音乐库收纳，就得改造一番目录树适配它那个“一个专辑只有一个目录”的原则，工作量也不小。
+3D 区无论玩恋活还是 MMD，既有图集又有视频，无法按媒体类型区分。即便真要分，它算电视节目？电影？MV？分不明白。
+
+音声区大量的音频资源，摆烂一点直接用电子书库、按文件夹访查也不是不行，但显示出来反倒是专辑名（或者说 DLsite、系列作品名）更显眼，而非每一集的标题；若要用音乐库收纳，就得改造一番目录树适配它那个“一个专辑只有一个目录”的原则，工作量也不小。
+
+至于书目区，像上面列的“正经读物”想获取元数据并不难。那“不正经读物”呢？对比出版物，网文显然算不上“正经”，但豆瓣之流依然有机会找到。所谓的同人文受限于作者的圈地自萌，但若是有缘知道 Ta 发布的平台，也是能记下元数据的（同人圈子对打 Tag 这件事很看重）。那么只剩下来源不正经、题材也不正经的“那种”作品了，它们流通的地方通常都是论坛这种早期网络社区，只知道个标题（甚至标题也不一定知道）。What can I say?
 
 偏偏这种不在台面上的“资源”我收纳了不少，哪怕有自动化工具，后续校对也是个体力活，何况很多资源只能一件件手工入库。饶了我吧。
 
 ## 穿透与反向代理
 
+如今连网易云也改得不知为何物了，于是我随身听的需求便也转向 Jellyfin。最简单的方法可以是 ZeroTier，但安卓有“同一时间只允许一个 VPN”的限制，所以在群友指导下搞了内网穿透（FRP）。
+
+此后，我遇到了子网划分的问题。起初这个问题并不起眼，直到我在户外同时尝试走 ZeroTier 和穿透，我才发现 frp 连上之后似乎更像是在本地回环，而 Jellyfin 似乎**对本地回环不设限速**。
+
 > ~~写着写着总会变成报流水账。~~
 
-在部署好 frp 穿透后，我遇到了子网划分的问题。经由 frp 进来的流量再进 Jellyfin，源 IP 默认就变换为`localhost`，Jellyfin **默认对本地回环不设限速**，在 Dashboard 里全局设置流比特率的做法并不起作用。
+AI 对此的解法是在 frp 这里记录下真实 IP。我选配的服务商支持 Proxy Protocol，也更推荐这么实现。但在实地测试后，发现 Jellyfin 并不直接支持 Proxy Protocol，那么就只能在 frpc 跟 Jellyfin 之间多加一层 nginx 做反向代理了（frps 显然我是动不了的）。
 
-在实地测试后，发现 Jellyfin 并不直接支持 Proxy Protocol，那么就只能在前面套多一层 nginx 做反向代理了。
+方法很简单，frp 侧仍旧启用 Proxy Protocol，在 nginx 里剥离真实 ip。我是在 Ubuntu Server 上安装的 nginx，据称已集成`real-ip`模块。那么编辑`/etc/nginx/sites-enabled/default`（我是图方便直接原地开刀了）：
-
-方法很简单，frp 侧仍旧启用 Proxy Protocol，在 nginx 里剥离真实 ip。我是在 Ubuntu Server 上安装的 nginx，据称已集成`realip`模块。那么编辑`/etc/nginx/sites-enabled/default`（我是图方便直接原地开刀了）：
 
 ```
 server {