下载来的 TXT 小说为什么总是坏的:五种损坏,三种可修复性

· 约 5 分钟 🧹 TXT 小说整理

从网上下来的小说 TXT,打开之后常常不太对劲:章节对不上、满屏奇怪的字、明明有这个词却搜不到、每行只有几十个字。

这不是一种问题,是五种,而且它们的可修复性差别很大——有的能无损修好,有的修了有风险,有的只能重新下载。

一、编码链断了

这一类要分成两种,因为处理方式完全相反。

能修的:字节还在,只是解释错了

表现是满屏「锟斤拷」「烫烫烫」或者一堆莫名其妙的汉字。原因是文件是用 GBK 存的,而你的阅读器按 UTF-8 打开(或者反过来)。

原始字节一个都没丢,换个编码重新解释就恢复了。

修不了的:字节已经没了

表现是正文里出现 (U+FFFD,替换字符)。

它意味着:在你拿到这个文件之前,上一手已经用错误的编码解码过一次,并且重新保存了。 解码时遇到解不出的字节,就统一替换成这一个字符。

原始字节 → 错误解码 → 遇到解不出的 → 全部变成 �  → 重新保存

几百个不同的字节都变成了同一个 �,没有任何信息能把它们区分开。这是一个有损且不可逆的操作,任何工具都还原不回来。

所以拿到一份小说,先搜一下有没有 �。 有就别修了,回源站重新下载。TXT 小说整理 把「乱码残字」的个数单独统计出来,就是为了给这个判断一个明确的信号。

编码识别和乱码形态的完整讲解,见 乱码的几种形态与恢复

二、零宽字符

一批宽度为零、完全看不见的字符:U+200B(零宽空格)、U+200C、U+200D、U+FEFF。

它们出现在正文里,多数是被有意插进去的

  • 反抓取 —— 随机插入零宽字符,别人整段复制走的文本和原文不完全一致,便于追溯来源
  • 反检索 —— 在词的中间插一个,搜索引擎和阅读器的查找功能就匹配不到这个词
  • 少数是编辑工具无意带入的

对读者的影响很具体

  1. 在阅读器里搜不到明明存在的词——这是最气人的一条
  2. 复制出来的句子和原文对不上
  3. 字数统计偏大

删除是完全安全的:它们不承载任何可见内容,去掉之后正文一个字都不会变。这也是这一项默认开启的原因。

同类问题在普通文本里的表现(BOM、零宽空格),见 文本里看不见的字符

三、抓取失败:缺章、空章、重复章

这三样常常一起出现,因为它们是同一个过程的不同结果。

抓取一本连载小说通常是按目录逐页请求。这个过程里:

发生了什么结果
某一页请求失败且没重试缺章
请求成功但内容没加载出来空章(正文只有几个字)
失败后重试,前一次的结果也被写入了重复章
并发抓取,写入顺序乱了序号回退(第 12 章后面跟着第 9 章)

所以一本书如果同时有缺章和重复章,基本可以断定是抓取脚本的问题,而不是源站缺内容。

怎么判断缺章是真是假,有两种典型的误报:

  • 分卷小说:很多书每卷都从「第一章」重新开始,全书拉通算序号会炸出一大堆假缺口。必须按卷分别计算
  • 正则匹配到了正文:正文里出现「他翻到第三章」这样的句子被当成标题,序号就乱了

判断方法:

  • 算出来的缺口比章节总数还多 → 几乎肯定是序号识别不可靠
  • 缺口集中在连续的一段 → 多半是真的抓取失败
  • 缺口零散且数量很大 → 多半是识别出了问题

序章、楔子、引子、番外、后记本来就没有序号,不参与计算。

四、盗版站的广告水印

每章末尾的「请记住本站」「最新章节请访问」、分隔线、网址行、二维码提示。

这一类是整行插入的,所以按行删除很干净,误删了在对照视图里也一眼能看出来。风险低,默认开启。

要注意的是规则要按站点补:不同站点的水印文案不一样,默认规则覆盖不到的,自己加一条正则即可。

五、硬换行

打开发现每行只有三四十个字,一句话被切成好几行。

这是早期 TXT 阅读器和打印排版留下的习惯——那时候的阅读软件不会自动折行,所以文本文件在生成时就按固定宽度断好了。

合并规则:一行没有以句号、问号、引号这类终止标点结尾,就和下一行接起来。章节标题和空行是硬边界。

什么时候不该开

  • 原文本来就是一段一行,而某些段落恰好以破折号或省略号结尾
  • 诗词、歌词、书信格式——本来就是短行分列
  • 对话密集的段落

怎么判断需不需要开:随便翻几页。每行长度都差不多且明显偏短,是硬换行;行长参差不齐、有长有短,那是正常段落。

可修复性对照

损坏可修复性说明
编码解释错误(锟斤拷)无损修复换编码即可,字节没丢
零宽字符无损修复不承载可见内容
行尾空白、连续空行无损修复纯格式
广告水印行✅ 整行删除误删一眼可见
硬换行⚠️ 有风险可能误并诗词、对话
标点全半角、缩进统一⚠️ 有风险逐字改动正文
缺章、空章不可修内容本来就没下下来
乱码残字 �不可修字节已丢失

这张表也解释了为什么清理类操作默认开、改写类默认关:

你手里没有原件可以对照。 删错一行,在左右对照里划着线一眼能看出来;而把「Windows 3.1」改成「Windows 3。1」这种误伤,是散在几百万字里的,默认开了根本不会有人发现。

拿到一本书的处理顺序

  1. 先体检 —— 看缺章、重复章、空章、乱码残字的数量。有 � 或缺章严重,直接重下,后面都不用做了
  2. 确认编码 —— 探测不对就手工切换,看正文是否正常
  3. 开清理类 —— 去广告、去零宽、清行尾空白、压空行。风险低
  4. 按需开改写类 —— 硬换行、标点、缩进。开之前先在对照视图里抽查几段
  5. 导出 —— 还要继续用 TXT 就导 UTF-8(给 Windows 记事本看的加 BOM);想要带目录能跳转的电子书,转 TXT 转 EPUB

第 5 步的选择值得多说一句:TXT 没有目录结构,章节跳转全靠阅读器自己猜。整理干净之后再转 EPUB,章节识别的准确率会高很多——两边用的是同一份章节正则。转换时的章节识别和目录生成,见 TXT 转 EPUB 的章节识别

❓ 常见问题

为什么有的乱码换个编码就好了,有的换什么都没用?

看屏幕上出现的是「别的字」还是「�」两种情况的本质不同:(1) 字节还在,只是解释错了 —— 表现为满屏「锟斤拷」「烫烫烫」或者奇怪的汉字,把编码从 UTF-8 换成 GBK(或反过来)立刻恢复,因为原始字节一个没丢;(2) 字节已经没了 —— 表现为 �(U+FFFD 替换字符),说明在你拿到这个文件之前,上一手已经用错误的编码解码过一次并重新保存,解不出的字节被统一替换成了这一个字符。第二种不可逆:几百个不同的字节都变成了同一个 �,没有任何信息能把它们区分开,任何工具都还原不回来判断方法:搜一下正文里有没有 �,有就只能回源站重新下载。这也是 TXT 小说整理 把「乱码残字」单独统计出来的原因——它是一个「别修了,重下」的信号。

零宽字符是什么?为什么正文里会有?

是一批宽度为零、完全看不见的字符,多数是被有意插进来的常见的几个:U+200B(零宽空格)、U+200C、U+200D、U+FEFF。为什么会有:(1) 反抓取 —— 有些站点在正文里随机插入零宽字符,这样别人整段复制走的文本和原文不完全一致,便于追溯,也能干扰全文比对;(2) 反检索 —— 词中间插一个零宽字符,搜索引擎和阅读器的查找功能就匹配不到这个词;(3) 少数是编辑工具无意带入的。对读者的影响:(1) 在阅读器里搜不到明明存在的词;(2) 复制出来的句子和原文对不上;(3) 字数统计偏大。删除是安全的 —— 它们不承载任何可见内容,去掉之后正文一个字都不会变。

「缺 3 章」会不会是误报?

会,而且有两种典型的误报来源第一种:分卷小说。很多书每一卷都从「第一章」重新开始,如果把全书拉通算序号,会炸出一大堆假缺口。正确做法是按卷分别计算第二种:章节标题正则匹配到了正文。正文里出现「他翻到第三章」这样的句子,被当成章节标题,序号就乱了。怎么分辨真假:(1) 算出来的缺口比章节总数还多,基本可以断定是识别不可靠,而不是真缺了那么多;(2) 缺口集中在连续的一段,多半是真的抓取失败;(3) 缺口零散分布且数量很大,多半是序号识别出了问题。不参与计算的:序章、楔子、引子、番外、后记这些本来就没有序号。遇到自己的章节写法(比如「(一)」),改一下识别正则再跑一遍。

「合并硬换行」什么时候不该开?

原文本来就是一段一行时不该开这个开关的用途:修复「每行只有三四十个字、一句话被切成好几行」的排版。它的规则是——一行没有以句号、问号、引号这类终止标点结尾,就和下一行接起来。什么时候会误伤:(1) 原文已经是正常的一段一行,而某些段落恰好以非终止标点结尾(比如以破折号或省略号结尾的),会被错误地并进下一段;(2) 诗词、歌词、书信格式,本来就是短行分列,合并会毁掉排版;(3) 对话密集的段落。安全做法:先在左右对照视图里看一眼被并了哪些行再决定。判断是否需要开:随便翻几页,如果每行长度都差不多且明显偏短,就是硬换行;如果行长参差不齐、有长有短,那是正常段落。

🧹 打开 TXT 小说整理 缺章/重复章/乱序体检·去盗版站广告水印·去零宽字符·GBK 乱码修复·统一缩进与标点·导出仍是 TXT·本地处理

🔗 相关阅读

全部教程 →
锟斤拷、烫烫烫、浣犲ソ、中文 都是怎么来的:四类乱码的产生机制与可逆性判断
乱码不是随机的——每种「乱」法都精确对应一条出错路径。这篇拆解四类最常见的乱码模式:哪个环节错了、为什么恰好变成这几个字、以及最关键的——哪些能一键还原,哪些已经永久损坏。
EPUB / MOBI / AZW3 / PDF / TXT 到底怎么选:按设备和用途倒推的电子书格式决策表
五种格式不是新旧关系,而是各自解决不同问题。这篇讲清重排式和固定版式的根本分野、为什么 PDF 在六寸屏上一定难看、Kindle 现在还认不认 MOBI、TXT 什么时候反而是最优解,以及格式转换时哪些东西必然会丢。
怎么判断一个文件是什么编码:BOM、自动识别的原理,以及 CSV 给 Excel 加 BOM 的正确姿势
文件本身不记录自己的编码——判断编码本质上是猜。这篇讲清三件事:BOM 这三个字节到底是什么、什么时候该加什么时候是坑;没有 BOM 时自动识别靠什么、为什么短文本会猜错;以及 UTF-8 CSV 在 Excel 里乱码的标准解法。
2FA 验证码总是对不上?TOTP 时间步、SHA 算法与 Base32 密钥三类坑排查
自己实现两步验证、或换手机想恢复 Google Authenticator 时,最常见的崩溃是"算出来的 6 位码和服务端就是对不上"。这篇讲清 TOTP 是怎么用密钥和时间算出动态码的,再按设备时间、算法/位数/周期、Base32 密钥格式三类高频原因逐一排查,并说明备份密钥如何手动出码与跨设备恢复。