企业官网建设流程全解析

我电脑里有个外置硬盘，专门用来存老番和经典动画电影。前段时间想给里面几百集的《龙珠Z》建档，结果刚把文件丢进 Jellyfin，媒体库就冒出一堆“未知电视剧”，其中一个文件的原始名字就是dragonballz_e187-2.mkv。第一眼看这名字好像没啥问题，片名有了、集数有了，连第几段都标了，可刮削器死活不认。后来这种文件见多了，我基本一眼就能判断问题出在哪。今天干脆拿这个文件名当引子，把老番资源整理中那句“命名不规范，折腾两行泪”背后的门道一次讲透，包括分卷处理、集数对位、刮削匹配、字幕音轨检查，以及批量化改名的完整套路。这篇文章适合家里有 NAS、平时用 Plex/Emby/Jellyfin 看动漫的人，也适合硬盘里躺着几百集老番但迟迟没动手整理的人。

1. 一个看起来没毛病的文件名，为什么让媒体库直接疯掉

1.1 刮削失败时的典型现场

先说现象。当你把dragonballz_e187-2.mkv放进 NAS 的某个电视剧目录，媒体服务端会自动扫描并尝试把文件匹配到在线数据库，比如 TMDB、TVDb 这些。匹配成功后会拉回封面、简介、演员表、剧集标题；匹配失败则会出现几种惨状：有的显示成“Unknown Series”，有的被当成一部单独的电影，还有的干脆匹配到同名但完全无关的其他剧集。

我当时把整个文件夹丢进去之后，Jellyfin 里出现了十几个“未知条目”，里头不少文件名比dragonballz_e187-2还随意，比如dbz_186.mp4、DBZ_EP187_1080p.mkv。系统根本不知道该把第186集挂到哪一季，也不知道第187集后面那个“-2”到底是另一集还是同一集的分段。媒体库界面看起来就像一盘散沙，封面缺失、集数混乱，点进去连播放都正常，但完全失去了“媒体库”该有的体验。

刮削这层逻辑其实很机械：它就是靠文件名里能被识别的那几个关键字去数据库查。文件名给的信息越规范，命中率越高；给的信息不对劲，它宁可挂起也不愿猜错。好消息是，绝大多数刮削失败最终都能通过改命名解决，真正意义上的“死档”很少。

1.2 拆开看，这个文件名里到底有什么

把dragonballz_e187-2.mkv拆开看，它其实包含三类信息的雏形：

问题不在“有没有信息”，而在“信息没有按刮削器的约定来组织”。后面要做的所有操作，都是为了让这个文件名变成刮削器一眼就能看懂的标准结构，比如Dragon Ball Z (1989) - S05E187 - 标题.mkv这种，又或者至少带上明确的季号与集号。

2. “e187”和“-2”背后，藏着老番命名里的两种典型陷阱

2.1 “第187集”在龙珠Z里根本不是你想的那个意思

单看e187，最自然的理解就是“第187集”。但放到《龙珠Z》身上，这个“第187集”的对应关系比想象中复杂。

日文原版的《龙珠Z》共291集，但海外发行时，很多地区把某几集素材合并过剪辑过，集数编号也做过调整。哪怕是原版，在 TMDB、TVDb 这类数据库里也不是简单的一个“Season 1”就装下291集，而是按故事篇章或发行介质拆成多个季。比如赛亚人篇、娜美克星篇、人造人·沙鲁篇、魔人布欧篇，这些段落在不同数据库里的季号划分可能还不一样。

所以，当文件名只写e187而没有 Sxx（季号）时，刮削器就要猜：你到底指“总第187集”，还是“某个季里的第187集”？这两者对应的数据库记录完全不同。更麻烦的是，如果你手里的是一个英文配音版、某个重新剪辑的海外版，那么实际内容和你以为的“第187集”可能都对不上。这也是我后来坚持“先查数据库，再改名”的原因，千万不能看着集数差不多就直接动手。

2.2 “-2”是怎么来的：分卷文件的几种来源

老番资源里经常见到-1、-2这样的后缀，含义是一样的：这一集比较大，被切分成了多段。常见原因主要有四类：

• 当年部分TV录制源在存档时就按录像带时长切段，一集分成AB两段；
• 字幕组或压制组发表的V1/V2版本里，因为体积限制把一整集拆成part1、part2分发；
• 某些蓝光原盘或HDRip在Rip阶段主动分段，方便断点续传和单独校验；
• 下载工具在文件未完成时产生的分块，合并不当残留成了多文件。

无论是哪种来源，只要确认这两段首尾能衔接成完整一集，最省心的处理方式就是合并成一个文件。但也有例外：如果你的播放器、电视或媒体服务端能很好地识别Part 1、Part 2这类命名，保留分卷直接播也能做到无缝衔接。后面第4节会给出两条路线的判断标准。

2.3 别把“e187-2”当成第187.5集

很多人第一次整理时容易犯一个错：看到-2就以为是“第187集的第二个版本”或者“第二季第187集”。这会导致两个方向的误解，一是刮削时把同一集拆成了两个条目，二是改名的目标格式完全跑偏。

e187-2的正确解读只有一种：这是第187集这个叙事单元的第二段落。也就是说，真正的标题和内容对应到数据库里还是“第187集”，只是在文件层面被拆开了。后续所有处理都应该围绕“如何把两个文件还原成一个可识别的整集”来展开。

3. 刮削器为什么认不出这种文件：先从识别逻辑上死磕一遍

3.1 刮削器解析文件名的方式

Plex、Emby、Jellyfin 在扫描本地文件时，会用一组正则匹配规则去拆解文件名。它们优先级最高的模式是SxxExx（季号+集号），其次是Season 01 Episode 02这类自然语言格式，再次才是e187这种单集号标记。

问题来了：SxxExx中的“季”是明确限定词，但e187只有一个数字。刮削器会先按“单季”去查，查不到就尝试把文件扔到某个默认季，或者干脆标记为无法识别。更致命的是-2这个后缀，在部分匹配规则里会被解析为“第187集第2段”，在另一些规则里会直接被当成噪声忽略，甚至干扰整个文件名的解析。

你可以做一个简单实验：把文件名改成Dragon Ball Z - e187.mkv放进媒体库，大部分情况能识别出正确的剧集标题，但季归属经常是错的；而改成Dragon Ball Z (1989) - S05E187.mkv之后，基本一次命中。这说明刮削器对“季”的依赖远高于对“集”的敏感度。

3.2 老番在TMDB/TVDb里的结构为什么更麻烦

新番在数据库里通常结构清晰：第一季、第二季、每季固定集数。但老番尤其《龙珠Z》这种跨年代、跨版本发行的作品，数据库里的记录往往是多季并行，而且不同数据库的划分还不一致。

举个例子，同一集内容在 TMDB 里可能被划到 Season 4，在 TVDb 里却被归到 Season 5。刮削器只能根据你配置的元数据源去请求，不会自己“聪明地”切换数据库。这就是为什么两台 NAS 上相同的文件，一个能刮出完整封面，另一个却只显示文件名。

另外，老番的数据库条目里经常有多个语言标题，日语原名、英语标题、中文译名并存。如果刮削器请求的语种和你文件的标题信息不匹配，也会出现“文件名里明明写了Dragon Ball Z，却匹配到另一个同名条目”的情况。

3.3 为什么SxxExx比e187好使

直接结论：刮削器是一款“规则优先”的软件，你给它的规则越标准，它调用的数据库查询就越精确。e187只提供了集数，等于把定位季的责任推给了刮削器；S05E187则是把“季+集”的完整坐标直接塞到它嘴里。

所以后面改名的核心目标不是“把名字变漂亮”，而是“补足刮削器需要的关键信息”。季号、集号、标题，这三个字段能齐就齐。拿不准季号的时候，宁可用某个数据库的绝对顺序（Absolute Order），也别让它自由发挥。

4. 标准改名实操：合并分卷还是保留分段

4.1 方案A：如果能确定是同一集，直接用ffmpeg合并

先说最推荐的方案。如果你有dragonballz_e187-1.mkv和dragonballz_e187-2.mkv，并且确认这两段属于同一集，先别急着改名，先合并。

合并前用ffprobe检查两个文件的编码参数是否一致：

ffprobe -v error -show_entries stream=codec_name,codec_type,width,height,fps -of json dragonballz_e187-1.mkv ffprobe -v error -show_entries stream=codec_name,codec_type,width,height,fps -of json dragonballz_e187-2.mkv

如果分辨率、帧率、编码器都一样，大概率只是单纯的时间切段，可以用concat无损合并：

ffmpeg -f concat -safe 0 -i list.txt -c copy dragonballz_e187_merged.mkv

其中list.txt的内容是：

file 'dragonballz_e187-1.mkv' file 'dragonballz_e187-2.mkv'

这里用了-c copy，等于直接流复制，不重新编码，速度快且画质无损。合并完成后，确认播放能无缝衔接，再去改名。

4.2 方案B：如果无法合并，就用规范命名保留分段

有些时候你没法合并，比如两段文件的音频采样率不同、帧率不一致，强行拼接会导致音画不同步；又或者你只有第二段，没找到第一段。这时候就用数据库可识别的分卷命名。

以 Plex 和 Jellyfin 为例，它们对Part的支持比较好：

Dragon Ball Z (1989) - S05E187 - Part 1.mkv Dragon Ball Z (1989) - S05E187 - Part 2.mkv

注意，季号要换成你查到的实际季号。这种写法在媒体库里会被识别成“第187集”，并且知道它由两个文件组成，播放时通常会自动连续播放。Emby 的老版本对 Part 支持不稳定，如果遇到不能连续播放的情况，就退化回方案A合并。

4.3 改名前先查数据库，别猜

这部分是硬经验，我踩过不少坑。给老番改名时，一定要先打开 TMDB 或 TVDb 的《Dragon Ball Z (1989)》页面，用“第187集”反查它到底落在哪一季、剧集标题是什么。

查询过程很简单：浏览器打开数据库网站，搜索 Dragon Ball Z，进入剧集详情页，找到季列表，再翻到第187条记录。记下季号和英文标题。接下来照格式填写即可。

Dragon Ball Z (1989) - S05E187 - The Last Hope.mkv

如果某个数据库里第187集不在你预想的季，就查另一个数据库交叉验证。老番的季号经常在 TMDB 和 TVDb 之间存在错位，宁可多花两分钟查证，也别改完才发现刮削成另一部剧。

5. 字幕、音轨和转码：分卷文件整理里的隐形坑

5.1 外挂字幕的同步与命名

文件本体处理完后，字幕是第二个大坑。外挂字幕和视频文件必须同名，才能被播放器和媒体服务器自动加载。如果你决定保留Part 1、Part 2的分段方案，字幕也要对应拆成两个文件，否则第二段播放时找不到字幕。

比如：

Dragon Ball Z (1989) - S05E187 - Part 1.zh.srt Dragon Ball Z (1989) - S05E187 - Part 2.zh.srt

这里zh是语言标签，方便媒体库在多种字幕间切换。另外很多老番字幕是 ASS 格式，里面用了特殊字体，但你的播放设备没装，字幕就会变成一片乱码或方块。做法是用 Aegisub 或ffmpeg把字体嵌入字幕文件，或者转换回 SRT 纯文本格式，兼容性最好。

老番字幕还有一个常见问题：字幕整体延迟或提前几百毫秒。这是因为你手里的可能是不同来源的Rip，帧率或时间轴有偏差。字幕加载后如果发现对不上，可以在播放器里手动调整字幕偏移，也可以在 Aegisub 里批量平移时间轴。

5.2 音轨语言与默认音轨检查

很多压制的双语版会内封两条音轨，一条日语原声，一条英语配音。默认音轨不一定是日语或中文，播放时可能直接给你放英语配音，体验大打折扣。

用 ffprobe 可以快速查看音轨信息：

ffprobe -v error -show_entries stream=codec_type,codec_name,lang_channel -of json Dragon.Ball.Z.1989.S05E187.mkv

如果发现默认音轨不对，可以用 ffmpeg 重新封装调整顺序，不需要重新编码：

ffmpeg -i input.mkv -map 0:v:0 -map 0:a:1 -map 0:a:0 -map 0:s? -c copy output.mkv

把第2条音轨提到默认位置，字幕轨按需保留。这类重新封装操作速度很快，因为也是流复制。整理几百集老番时，统一检查一遍音轨能省下很多日后播放时的烦躁。

5.3 转码参数：什么时候适合重新压一遍

老番资源里偶尔会混进低码率、隔行扫描、甚至画面比例错误的分卷文件。不是所有问题都能靠改名解决，有时候必须转码。

我的经验是：只要文件能正常播放、画面没有明显问题，就不转码。转码是在资源画质确实烂、或者播放设备不兼容时最后的武器。如果真要转，用 ffmpeg 参数保持 H.264 编码和高兼容性：

ffmpeg -i input.mkv -c:v libx264 -crf 20 -preset slow -c:a copy -c:s copy output.mkv

CRF 20 是质量和体积的平衡点，追求更小体积可以放宽到 22 到 23；preset slow压缩率更高但耗时更长。老番这种动态场景偏多的动画，CRF 不建议超过 23，否则复杂场景会糊成一团。转码前先想清楚：必要吗？值得为一个八成时间在静态对话的画面花三个小时？没必要就别动。

6. 批量整理老番资源的完整套路

6.1 工具选型对比

整理一两集还可以手动操作，整理几百集如果还手改，那不是认真，是折磨。我试过几种常见工具后，大概的选型经验如下：

我的建议是，老番一次性整理用 Tiny Media Manager 或者 FileBot 最省事，它们能直接读取文件里的视频信息去匹配数据库，然后按你的模板统一改名。它们刮削后生成的 NFO 文件和图片，Jellyfin、Emby 都能直接用。

6.2 正则表达式批量改名的实际姿势

手头已经清空的一天几百集，最实际的是写个小脚本处理。以dragonballz_e187-2.mkv这类文件为例，核心就两步：先提取集数，再替换成标准格式。

PowerShell 示例：

Get-ChildItem -Path "D:\DBZ" -Filter "dragonballz_e*.mkv" | ForEach-Object { if ($_.Name -match 'dragonballz_e(\d+)-(\d+)\.(mkv|mp4)$') { $ep = [int]$Matches[1] $part = [int]$Matches[2] $newName = "Dragon Ball Z (1989) - S05E{0:D3} - Part {1}.mkv" -f $ep, $part Rename-Item -Path $_.FullName -NewName $newName } }

这里有几个细节要注意：季号S05必须根据实际数据库查询结果替换，别照抄；{0:D3}的作用是把第187集输出成三位数，保证排序正确；-(\d+)用来捕获-1、-2的段号。如果某个文件只有单段没有后缀，$Matches[2]会不存在，脚本需要在分支里单独处理，否则会报错。

正则批量改名之前，最好先暴力扫描一遍文件名，确认没有特殊字符和空字节。老资源文件里偶尔会混入全角字符、连续空格，甚至在文件名末尾藏了不可见字符，这些都会导致重命名脚本行为异常。

6.3 一套可以直接照着用的老番整理流程

整理老番不只是改名，而是一条流水线。我跑完整套流程后的固定顺序大概是：

1. 扫描文件，把所有文件复制到一个临时目录，先别动原始目录；
2. 清理文件名中的乱码、空格、特殊字符，统一编码为 UTF-8；
3. 用 ffprobe 批量检查视频流、音轨、字幕、分辨率是否完整；
4. 对照 TMDB/TVDb 确认季号和集号，必要时处理分卷合并；
5. 用 FileBot 或 Tiny Media Manager 自动刮削并写入 NFO；
6. 手动抽查几集，确认封面、简介、音轨、字幕都没问题；
7. 原目录文件移到正式库，刷新媒体库索引。

这套流程在整理《龙珠Z》全集时跑过一次，也顺带清了其他几部老番。整体下来最耗时的不是改名，而是音轨检查和字幕同步。如果文件来源比较统一，可以省掉 3 和 6 的大部分时间；但文件来源五花八门时，这一步省了后面大概率要返工。

另外提醒一句：大范围改名或者合并之前，至少留一份原始文件名的备份清单，哪怕是导出到一个 TXT 里也行。我见过有人脚本写错正则，把几百个文件名一次性改残的，这时候一份原始清单能帮你快速恢复。整理文件本身是件慢工出细活的事，急不得。

就我个人的体会来说，整理这些老番最大的收获不是媒体库终于变得整齐了，而是以后再遇到dragonballz_e187-2这样的怪名字，我能在大脑里飞快地过一遍处理链路：查库、定位、合并或分段、配对字幕、调好音轨，最后刮削。这套流程现在看依然有它的笨拙之处，但对一个装满童年回忆的硬盘来说，花点时间把它们规整好，值得。