简介：这是一款面向电子书阅读与文本编辑场景的轻量级工具，主要解决TXT文件合并、段落合并、分行等日常整理需求。内置HTML转TXT、编码转换（GB/GBK/Big5/Shift-JIS/Unicode）、文本替换、正则表达式、文件切分与文本提取等功能，尤其适合批量清洗文本、转换旧书源编码或整理小说章节的用户。压缩包内共2个文件，包含一个HTM格式的功能说明页面和一个可直接运行的EXE主程序，整体仅245KB，无需复杂安装即可在Windows 2K/XP环境中试用。目前已有179人学习下载，体积小巧但功能集中，可当作快速处理日常文本的备用小工具。借助该包，读者既能了解各功能的具体用法，也能直接运行程序完成合并、分行与编码转换等操作，节省逐条手动处理的时间。
1. TextForever：合文件、清乱码、修段落的老牌 TXT 离线工具箱
网上拼下来的小说，十有八九是碎片：一章一个 txt，文件名是「第1章」「第100章」这种，按名称排序永远排不对；内容里还混着网页残留标签、站内广告和硬换行。TextForever 就是为这种场景开发的离线小工具，一个 rar 包里装着一个 exe 和一份说明 htm，专治电子版小说的脏活：文件合并、TXT 段落合并、分行、编码转换（GB/GBK/Big5/Shift-JIS/Unicode）、HTML 整理、文本替换、正则、文件切分、文本提取。它不联网、不吃内存，适合手动囤书、要把碎片拼成整本再进阅读器的书友，也适合批量维护语料、按固定流程洗数据的从业者。下面按实际使用顺序，拆操作、参数和翻车点。
2. 文件合并与段落合并：把两千章碎片 TXT 拼成一本可读的书
2.1 为什么碎片文件必须先合并
先想明白一件事：阅读器打开一个目录，看到的是几十个 txt 文件，它按文件名字典序排列。于是「第10章」排在「第2章」前面，「第100章」排在「第11章」前面。你在目录里翻页，章节顺序是乱的，这跟文件内容没关系，纯粹是命名规则造成的。另一个更实际的问题是推送：Kindle 网页推送、某些墨水屏阅读器对多文件目录的支持很差，经常只认第一个文件或者干脆不显示。合并成单个 txt 之后，这两个问题同时消失。
还有一个隐藏好处：只有合成一本，你才能做缺章检查。碎片状态下想确认第 37 到 41 章是否齐全都得一个个点开看，合成后搜一遍「第X章」就知道断在哪，这也是后面抽查法的基础。所以我的建议是：拿到一个下载包，别急着看内容，先把该合并的合并了，再做清洗。顺序反了的话，你清洗完的章节文件还得再合一次，等于白洗。
2.2 合并前的一步：把文件名改成可排序的编号
合并操作本身不复杂，但很多翻车都发生在合并之前。下载工具的命名五花八门，「第1章」「01 第一章」「ch001」都有。TextForever 的合并对话框是按你添加文件的顺序读入的，所以只要文件顺序对，合并结果就对。问题是文件对话框里排序还是按字典序，你得手动一个个调，几百个文件点起来要命。
我一般会在合并前先跑一个批处理，把章节号补零到三位，这样字典序就是自然的阅读序。新建一个文件夹，把原文件整个复制进去，然后在这个副本上执行：
@echo off setlocal enabledelayedexpansion cd /d "%~dp0" for %%f in (*.txt) do ( set "name=%%~nf" set "num=!name:第=!" set "num=!num:章=!" if !num! lss 10 ( ren "%%f" "第00!num!章.txt" ) else if !num! lss 100 ( ren "%%f" "第0!num!章.txt" ) )这段批处理做三件事：先把文件名里的「第」「章」剥掉，得到纯数字；然后判断数字大小，小于 10 的补成「第009章」这种三位编号，小于 100 的补成「第099章」；最后用 ren 改回原名文件。setlocal enabledelayedexpansion 必须在开头声明，否则 for 循环里读取变量值会拿到旧值，这是批处理最常见的坑。补零规则也适用于四位数章节，把判断条件改成 lss 1000 就行。注意这套脚本只对未补零的命名有效，跑完一遍不要执行第二次，否则会多出一位零。
提示：批处理只改文件名，不改内容。跑之前确认当前目录确实是你准备合并的副本，别在原目录上直接执行，万一命名规则匹配错了，恢复要花时间。
改名之后，打开 TextForever，切到文件合并功能，按顺序把文件加进去。工具界面上通常能看到已添加文件的列表，检查一下首尾文件是否符合预期。输出时我建议勾上「在文件间插入分隔行」一类的选项，生成的单文件里每章之间会有一条明显的空行或分隔注释，方便后续抽查定位。输出编码默认选 GBK 就行，除非你的阅读器明确支持 UTF-8；老设备对 UTF-8 的支持参差不齐，GBK 是兼容性最保险的选择。
2.3 段落合并：把硬换行压回自然段落
碎片问题解决了，下一个更烦人的是段落问题。网页复制出来的小说，几乎每两行就有一个硬换行，有的句子甚至被拦腰截断。这种文件直接看，满屏都是碎行，阅读器排版再好看也没用。TextForever 的段落合并就是干这个的：它把连续的行按规则重新组装成完整段落。
实际执行时有一个关键判断：哪些行要合并，哪些行必须保留。对话是重灾区，小说里「他说」这种短行如果被强行并进上下两段，读起来会乱。我的经验是分两种情况处理：如果源文件有明确的空行分段，就勾选「空行作为段落分隔」，让工具只在空行处断段，这样对话和短行都能保住；如果源文件连空行都没有，全靠硬换行，那就只能靠行长度阈值来判断。下面是我常用的参数组合：
| 参数 | 推荐值 | 使用说明 |
|---|---|---|
| 空行作为段落分隔 | 勾选 | 源文件有空行时必开，段落边界最可靠 |
| 单行字数阈值 | 30 字 | 超过阈值的行视为一个独立段，不参与合并 |
| 首行缩进 | 2 个全角空格 | 符合中文排版习惯，阅读器里更像书 |
| 段间空行 | 保留 1 行 | 老阅读器渲染长段落时不会糊在一起 |
阈值 30 字的意思是：一行如果超过 30 个字符，就认为它本身是一个完整段落，不再跟上一行合并；少于这个长度的行会被拼进前一个段落。对话、章节标题这类短行因此能保得住。OCR 出来的书这个值要降到 20 左右，因为 OCR 断句更碎；网页复制的小说则建议升到 40，避免把两段并成一段。
2.4 反向操作：文件切分与 TCR 打包
合并是高频操作，切分偶尔也要用。比如某本大部头合并完有 5MB，老式阅读器打开卡顿，或者你只想推送到设备的前一百章。TextForever 的文件切分支持按体积和按标记两种方式：按体积就是每 1MB 或每 500KB 切一卷，适合设备容量受限的场景；按标记则是拿正则匹配「第X章」作为切分点，每遇到 N 个标记切一次。我一般用后者，配合清洗过的文件，每 200 章一卷，文件名形如 book_001.txt、book_002.txt。切分顺序一定要放在段落合并和文本替换之后，否则章节标记被改掉，切分就失效了。如果你的目标设备是老 Palm 或 Pocket PC，工具还带 TCR 批量压缩/解压，能把 txt 压成 tcr 格式方便老设备读取，现在基本用不到，知道有这功能就行。
3. 编码转换与 HTML 清洗：乱码、网页残留和简繁转换的后悔药
3.1 乱码识别：从乱码形态反推原编码
很多用户下载的小说打开是乱码，第一反应是文件坏了，其实只是编码错配。简体中文站多用 GBK/GB2312，台湾香港站点常用 Big5，日文源则是 Shift-JIS，而现代编辑器和阅读器默认按 UTF-8 打开。编码选错，文字就变成一堆不可读符号。TextForever 的编码转换支持 GB/GBK/Big5/Shift-JIS/Unicode 互转，前提是你得先判断源文件的真实编码。
判断方法不靠猜，看乱码形态。我整理了一个对照：
| 打开后的乱码形态 | 源文件实际编码 | 转换目标 |
|---|---|---|
| 满屏「锘?」「鎵?」 | GBK 被当 UTF-8 解析 | GBK -> UTF-8 |
| 繁体字正常显示但夹杂「�」 | Big5 缺字 | Big5 -> GBK 或 UTF-8 |
| 字符变成「繧显」「縲?」 | Shift-JIS 被当 GBK | Shift-JIS -> UTF-8 |
| 整篇都是菱形问号 | 文件本身已是 UTF-8，阅读器不认 | UTF-8 -> GBK |
实操步骤：在 TextForever 里导入文件后，复制一小段乱码到预览区，逐个切换源编码选项，看哪一次字符恢复得最自然。确定源编码后，再选择目标编码转换保存。这里有个细节：Big5 转简体，TextForever 只做编码不做简繁字表替换，转出来还是繁体字形，只是从 Big5 字符集变成了 GBK 里的繁体字。想彻底转简体，得配合第 4 章的文本替换灌入简繁字表，或者转完后用 OpenCC 之类的外部工具再跑一遍。
3.2 HTML 清理的顺序：先剥标签，再清残留
从网页直接复制正文，粘到记事本里会带着一堆标签。TextForever 的 HTML->TXT 转换能把这些标签剥掉，但别指望它一次剥干净。网页结构千奇百怪，总有几个标签会漏网。我常碰到的残留主要是两类：一是转义实体，比如 显示成空格、<显示成小于号；二是脚本残留和样式注释，比如<script>块里的内容没被完全过滤。
我的处理顺序是固定的：先进 HTML->TXT 转换剥掉大部分标签，再用文本替换处理漏网实体，最后才做段落合并。顺序不能反，如果先段落合并，标签和正文被并进同一行，之后再想按行删标签就删不干净了。清理时常用的替换项：
| 查找内容 | 替换为 | 用途 |
|---|---|---|
<br>/<br/>/</p> | 换行 | 把网页折行还原成普通换行 |
| 全角空格 | 消除半角空格粘连 |
& | & | 还原转义符号 |
<script.*?</script> | 空 | 删除脚本块，注意非贪婪写法 |
第二行的 在正文里经常被用来做首行缩进，替换成全角空格后，后续段落合并的缩进设置就能统一生效。如果你拿到的 HTML 来源有很多class=属性，转换后可能残留class="xxx"字符串，这类统一用正则删掉即可。
3.3 网页来源之外的两种清洗策略
除了网页，还有两类来源特别常见：一类是从阅读 App 导出或者复制出来的章节，内容干净，但每一段末尾都带着「来源：XX小说」这种水印；另一类是 OCR 扫出来的 PDF 转 txt，错字和碎行双高。这两种的清洗策略完全不同：App 导出文件重点在去水印和统一换行，OCR 文件重点在段落合并和错字替换。用 TextForever 处理时，OCR 文件要先跑一遍分行把异常的长行打散，再按 2.3 的参数做段落合并，直接合并长行会被阈值误判成独立段。这是我踩过几次才总结出来的顺序。
4. 文本替换、正则与文本提取：批量清洗的三种正确姿势
4.1 文本替换：先字面替换，再整行删除
文本替换是 TextForever 里最常用的功能，但很多人直接把它当记事本的替换用，忽略了两个设置：替换范围和整行匹配。替换范围决定是只处理选中区域还是全文件，批量清洗时一定要选全文件。整行匹配则是判断「查找内容是否占满整行」，专门用来删水印和广告行。
实际操作顺序我建议是：先做整行删除，再做局部替换。原因是水印、广告、公告这类通常是完整一行，先删掉它们，后面局部替换时就不会误伤。比如某站每章末尾固定一行「本站网址 www.example.com」，先在文本替换里输入这行文字，勾选整行匹配，替换内容留空，执行后整行就被删掉了。如果网站每章水印带章节号，没法精确匹配整行，就改用正则，把章节数字匹配成通配。字面替换适合错别字表和标点统一，比如把半角逗号统一成全角、把「丅」修正为「T」，这类替换逐条执行，每执行完一次用文本提取功能抽查一下替换行数，确认没有误伤再继续下一条。
4.2 正则：三个高频模式和非贪婪坑
TextForever 的正则替换支持常见语法，用处集中在三类场景：删带有可变字符的广告行、统一章节标题格式、提取正文里的特定内容。下面是我常驻的几个模式：
| 用途 | 正则表达式 | 说明 |
|---|---|---|
| 删除带网址的广告行 | `^.*(www. | https?://).*$` |
| 删除站内公告块 | 【本章未完.{0,50}】 | 非贪婪匹配，只吞站内公告 |
| 章节标题统一 | ^第\s*[0-9一二三四五六七八九十百千]+\s*章 | 匹配各种写法，统一加标题标记 |
| 提取人物对话行 | ^「.*」$ | 配合文本提取，统计对话比例 |
这里最关键的是非贪婪。.*默认贪婪，会一路匹配到整个文件的末尾；写.{0,50}或[^\n]*才能限制在一行或一小段范围内。第 5 章有个具体翻车案例，这里先记住原则：凡是匹配内容可能跨行的，都要用非贪婪写法，并且先在副本上测一遍再全量执行。
注意：正则替换没有撤销栈。跑全量之前，一定要把待处理文件复制一份副本。TextForever 是离线工具，没有云同步后悔药，副本就是唯一后悔药。
4.3 文本提取与文件切分：利用正则做结构化整理
文本提取功能常被忽略，它其实很有用。比如你想给一本没有任何目录的小说生成章节目录，用正则^第[0-9一二三四五六七八九十百千]+章做提取，工具会把所有匹配行单独输出，这就得到了一份干净目录，可以直接复制进书里或生成导航。另一个用法是盘点：把提取结果的行数统计出来，对比原文件总行数，能快速发现哪些章节标题格式异常，从而定位切分失败的原因。
切分配合正则就更有意思了。TextForever 的切分如果支持按正则切分点，你可以把所有匹配「第X章」的行作为切分标记，每个标记处切一刀，然后按每 200 个标记合并成一卷。这样得到的每个分卷文件开头都是章节标题，后续要单独处理某卷也很方便。参数上我习惯把「每个分卷包含章节数」设成 200，输出文件名用 book_001.txt 这种三位编号，和 2.2 的补零思路一脉相承。
5. TextForever 踩坑排查：顺序、误并、编码翻车五个真实案例
这章写我实际翻过几次车的案例，每条按现象、原因、解决的方式记录。
5.1 合并后章节顺序乱
现象：合并完打开，第 100 章跑到第 11 章前面，整本书没法读。 原因：文件对话框按字典序排列，第 100 章的字符串「100」小于「11」，我按界面顺序添加，工具就按错误顺序读入了。 解决：先在副本上跑 2.2 的补零批处理，把章节号改成三位编号，再重新打开合并对话框添加文件。从那以后我合并前必做这一步，顺序问题再没出现过。
5.2 段落合并把对话并成一大段
现象：勾选了空行断段后，一段段对话还是被并到一起，读起来像语无伦次的长句。 原因：源文件里对话之间没有空行，只有硬换行，空行断段规则根本找不到断点；单行阈值又设得太低，短对话行都被并进上一段了。 解决：把单行字数阈值从 30 提到 40，同时勾选「少于 N 字的行保持独立」之类的保短行选项。对话密集的书，甚至应该放弃段落合并，只做分行和去水印，让阅读器自己排版。
5.3 繁体站点文件转出来全是「锘?」
现象：从台湾站点下载的文件，用 TextForever 转成 GBK，打开满屏「锘?」。 原因：源文件实际是 Big5，我默认当成 GBK 转了，编码判断错了，转换结果自然全错。 解决：先用 3.1 的乱码形态表判断真实编码。看到「锘?」这类怪字符，基本就是 Big5 被误解。选对源编码为 Big5、目标为 GBK，重转一次就正常了。这里没有技巧，只有先预览再全量。
5.4 正则替换把正文大段删掉
现象：用正则删广告，结果一本书少了三分之一，被删的位置全是正文。 原因：我写的模式是^.*(广告|网址).*$，.*贪婪匹配跨行，一个匹配就把几十行正文全吞掉了。 解决：改成^[^\n]*(广告|网址)[^\n]*$，用排除换行的写法把匹配范围锁死在单行内。同时先拿一本小书测试，用文本提取功能统计删除前后行数差异，差异异常就回滚副本重来。现在我的规则是：任何正则跑全量前，先在一章内容上验证，再看全本。
5.5 新电脑上打不开或转换时闪退
现象：Win11 上双击 TextForever.exe 没反应，或者点编码转换就闪退。 原因：这个工具太老了，编码转换部分依赖 Win 2k/XP 时代的系统接口，新系统不兼容。 解决：右键 exe 属性，兼容模式选「Windows XP (SP3)」，必要时以管理员身份运行。合并、段落合并、替换这些核心功能在新系统下一般还算正常；如果编码转换依旧闪退，就别在工具里硬撑，改用 Python 的转码逻辑，把结果导回 txt 后再用 TextForever 做段落合并。工具负责它擅长的部分，转码交给更可靠的方案，各干各的。
6. 进阶用法：把 TextForever 塞进批量整理流程
前面几章讲的都是单本操作，实际囤书的人面对的是一整个文件夹、几十本书。这章说一个我一直在用的半自动流程和验证方法。
6.1 半自动流水线：副本、改名、合并、抽查
核心原则是先建工作区。我整理书库时永远保持两个目录：raw/ 放原始下载包，work/ 放处理中的副本。任何清洗都在 work 里做，raw 里的文件不动。这个习惯救过我很多次，正则误删、编码转错，大不了从 raw 重新拷贝，损失只有几分钟。
处理顺序固定四步：拷贝到 work、补零改名、TextForever 合并清洗、抽查验证。前两步可以批处理化，后两步靠固定流程提速。每本处理完，用一个 Python 脚本抽查章节完整性和残留网址：
import re import sys path = sys.argv[1] for enc in ("utf-8", "gbk", "big5"): try: text = open(path, encoding=enc).read() break except UnicodeDecodeError: continue chapters = re.findall(r"第\s*[0-9０-９一二三四五六七八九十百千]+\s*章", text) print(f"章节数: {len(chapters)}") print("开头:", chapters[:3]) print("结尾:", chapters[-3:]) urls = re.findall(r"(www\.|https?://)", text) print(f"残留网址: {len(urls)} 处")脚本先按 UTF-8、GBK、Big5 顺序尝试解码，能解开的就是实际编码；然后统计章节标题数量和首尾内容，确认缺章和顺序问题；最后扫描 www 和 http 前缀，验证广告行有没有删干净。输出章节数对得上下载源目录数、残留为 0 时，就可以入库。
6.2 抽查三处，胜过通读全书
最后是内容抽查。我不通读全书，只抽三个位置：开头 100 行、全书 50% 处、结尾 100 行，每处看两千字，重点看段落断得自不自然、有没有水印残留、章节标题连不连续。三处过关，整本清洗质量基本就过关。这套抽查对语料库同样适用，把章节标题换成数据标记、网址水印换成噪声模式即可。
从开始批量整理书库到现在，我最大的教训是：清洗这件事，顺序比技巧重要，副本比自信重要。从那以后我每次处理新文件都强制走一遍副本、改名、小样测试、抽查的流程，再没因为一次正则误删丢掉整本书。希望帮到你。
本文还有配套的精品资源，点击获取
