手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 免费部署 N8N 的 Zeabur 注册 | 登陆
浏览模式: 标准 | 列表分类:Misc

小说导入阅读工具后,章节目录识别不对怎么办?

 不知道从什么时候开始,「阅读」之类的小说工具能找到的更新越来越难了。


尤其是一些不那么热门的小说,基本上过了公众版之后,后面的章节就很难再找到。

后来才知道,现在不少小说的更新已经转移到了 Telegram 上的一些频道里。

看来「阅读」这类工具这些年对小说网站的吸血,多少也让一些站点开始受不了了。

不过这又带来了另外一个问题。

Telegram 上分享的小说很多都是纯 TXT 文件。

TXT 本身倒没什么问题,是个阅读软件都能打开。但它有一个不算大问题的问题:内容跟章节名称是混在一起的,而不同的阅读软件处理的方式都有一些差异,尽管有些允许你自定义一些识别规则,但是依然很麻烦,对于非技术人员来说更是天书。

就算你解决了识别问题,很多小说本身的目录就不规范。

有些小说是:

第1章\
第2章\
第3章

这种算好的了。

更多的时候它可能是:

第一章

第001章

第1章 我回来了

第1卷 第一章

正文 第一章

Chapter 1

甚至还有些文件前面几十章一种格式,写到中间作者或者整理者突然又换了一种格式。

再加上网上流传的 TXT 文件经常经历过很多次转载、合并和重新整理,里面还可能夹杂:

广告网址、下载站水印、重复章节、缺失章节、章节倒序、乱码,以及莫名其妙插进去的说明文字。

这种文件直接丢进阅读软件以后,经常会出现一个很尴尬的情况:

**正文能看,但目录不能用。**

几百上千章的小说如果没有一个正常目录,体验还是挺糟糕的。

### 手工整理当然可以,但太累了

最简单的方法当然是打开 VS Code、Notepad++ 之类的编辑器,自己用正则表达式处理一下。

如果只是几十章倒还好。

但一部长篇网络小说动不动就是几百上千张。

更麻烦的是,很多 TXT 并不是简单地把:

`第一章`

替换成:

`第1章`

这么简单。

真正需要解决的是:

哪些行是章节标题?

哪些只是正文里碰巧出现了类似的文字?

章节编号是不是连续的?

有没有漏掉一章?

有没有重复?

有没有本来是第 135 章,结果文件里写成了第 153 章?

如果碰到卷、章混排这种更是头大,只能将就着看。

正则能解决一部分,但用起来还是比较折腾。

### 于是群里的资深书友巨大出手了!

作为之前大站站长兼程序猿,巨大受够了这些问题,他做了个叫 **[NovelLint](https://www.novellint.com)** 的在线工具。

NovelLint 可以直接导入 TXT 或 EPUB,然后扫描整本小说,自动识别里面可能的章节标题。

地址:[https://novellint.com](https://novellint.com)

和普通的“搜索一下 `第.*章`”不太一样,它会把识别出来的章节单独列出来,然后分析章节编号。

例如一本小说应该是:

第128章\
第129章\
第130章\
第131章

结果文件里面变成:

第128章\
第129章\
第131章

它会提示你:

**第130章可能缺失了。**

并且提供一些修复手段,比如附近潜在的章节名称,或者没找到潜在章节时允许你通过配置的AI帮你在附近的内容中找一下。

重复章节、编号倒序之类的问题也比较容易找出来。

对于网上弄到的 TXT 小说,这个功能还是挺实用的。

还有一个很有意思的小功能,它允许你一键将章节命名方式对齐,什么意思呢?

比如小说的章节列表是:

(01)xx

(02)yy

或者:

第一章:xxx

第2章:yyy

这样的格式,但你更喜欢 「第01章:xx」 这样格式,工具可以一键将它们转换成:

第01章:xxx

第02章:yyy

工具本身提供了一个可以转换的列表,基本涵盖了大部分章节命名习惯,算是强迫症的一点小福利。

工具很易用,基本传一本书跑一次就明白了,另外巨大也提供了详细的图文帮助文档。

### 我比较喜欢的一点:文件不用上传服务器

这类工具我比较在意一个问题:

**小说文件会不会被上传到别人服务器?**

NovelLint 目前的处理方式是直接在浏览器本地完成。

也就是说把 TXT 拖进去之后,分析和处理主要在当前浏览器里进行,不需要先把整本小说上传到服务器再处理。

这样至少在处理私人整理的文本时比较省心。

而且打开网页就能用,也不用为了偶尔整理一两本小说专门安装一个软件。

### 还能顺手生成 EPUB

TXT 整理完以后,还有一个挺实际的需求:**转成 EPUB。**

现在很多阅读软件虽然支持 TXT,但 EPUB 在目录、章节跳转这些方面还是舒服很多。

如果原始 TXT 本身没有标准目录,就算直接找个 TXT 转 EPUB 工具转换,最后生成出来的 EPUB 目录通常也不会特别理想。

NovelLint 的思路是先:

识别章节\
→ 检查章节结构\
→ 清理标题\
→ 再输出

这样最后得到的 EPUB 目录会规整很多。

对喜欢把小说丢进 Apple Books、Kindle 或其他本地阅读器的人来说,这一步还挺方便。

### 它比较适合什么情况?

如果只是一本格式特别标准的 TXT:

第一章\
第二章\
第三章

其实完全没必要用什么特殊工具,阅读软件自己一般就能正确识别。

NovelLint 更适合的是那些已经被“折腾过很多遍”的小说文件。

比如:

网上下载的 TXT;

Telegram 频道里拿到的小说合集;

多个 TXT 手工合并出来的长篇小说;

章节标题格式不统一的文件;

怀疑存在缺章、重复章的小说;

想整理完以后再转换成 EPUB 的文件。

这种情况下,先扫一遍目录还是挺有用的。

### 最后

网络小说发展这么多年以后,一个挺有意思的现象就是:

**小说本身越来越容易保存,但整理小说反而成了一件麻烦事。**

以前可能是在网站上直接一章一章看。

后来是阅读工具自动抓。

再后来又变成 TXT、EPUB、网盘、Telegram 到处流转。

文件倒是拿到了,但各种转载、合并和格式转换之后,章节目录往往已经惨不忍睹。

如果只是偶尔遇到一本,手动改改也无所谓。

但如果经常下载 TXT 小说,可以试一下 NovelLint:[https://novellint.com](https://novellint.com)

至少比拿着几百章的 TXT 自己一行一行找章节轻松得多。

Cursor越用越卡怎么办??

有没发现,Cursor在使用超过1个月后,会开始逐渐变得卡一点,用2个月会更卡。如果你频繁使用,那么你就会发现,你的输入框打一字,就要卡住半天,而且CPU占用也非常高,经常2~300%

这是为什么呢?其实除了网络等原因外,还有一个巨大的原因,就是cursor的聊天数据库太大了,我看了一下,我本地有4G,ls -lah ~/Library/Application\ Support/Cursor/User/globalStorage,看看这个:-rw-r--r--  1 admin staff 4.0G Aug 11 22:46 state.vscdb,
想想看,你每次切一下session,他就要从这4g的sqlite里查找一波对话。如果你还要往上翻页看历史对话,你自己想想,性能能高到哪里去??

所幸,官方本身就有解决方案,在agent界面,你cmd(ctrl)+shift+p,输入developer,会出来一个delete old chats。然后你自己选择删除几天前的对话。我删除了10天前的,我觉得10天前的对话,应该意义不大了(但其实不能完全这么想,比如有些项目,你暂时没动它,但他可能是一个月前的,你要删除了,那所有的历史对话就全没了),删除前,你可以自己做一个导出,要么让cursor整理成文档,要么你copy一下数据库做备份。

我4G速度还行,得益于我机器内存大。。。但,这个方案是没错的,你们可以自己试试,立刻就会感觉象飞起来了

用Agent管理服务器

这里不就说具体品牌的Agent了,但也别乱猜。我用的国产的

 
其实这应该不是什么新鲜事了吧,我现在就经常在服务器上用cli,先分析服务器环境和安全,主要是可以让他写成安全脚本,这样以后任何一台机器都可以复用,也避免在每台机器上都安装 Agent 之类的
 
然后让他配置防火墙之类的,改改什么ssh账号和限制 密码登录等,也确实方便。
 
自从有了AI,外包业务也越来越少了,最近网上有个段子,我特别感到好笑,以下是大意内容:有公司接项目,报价了10万,但甲方说现在都有vibe coding了,他们花了半个月用vibe coding写了整个项目,现在有点BUG,问甲方是否同意5000 改一改BUG。 甲方感慨的发了这个贴,我看有评论说,本来是10万,现在要改这个项目,那就得50万了。
 
agent越来越多,但不要让自己变成agent的奴隶 就行了。。
 
大小: 64.23 K
尺寸: 800 x 627
浏览: 6434 次
点击打开新窗口浏览全图

虽然大家都说ClawCloud是aliyun青春版,但我总感觉他已经死了

 如题。

为什么这么判定?是因为之前在 run.claw.cloud上提问没人回,开始我以为我不是会员,后面升了会员,提问也没有人回。创建个容器还3天2头崩。虽然我只是个尊贵的5刀会员,但也毕竟每个月都有5刀出去啊,结果 今年就突然说停止服务了。嗯,我也没收到邮件,不知道其他人是怎么收到消息的
 
为什么我现在又判断说他快死了呢?是我前几天发的工单,一周了,也没有任何人回复。去年活跃的时候,凌晨1点的工单,5点就有人回复了。要知道我们和新加坡是没有时差的。
见微知著吧。坐等他随时关闭,已经不敢随便续费了

简单的运维大概是真要失业了吧

如果一个运维,只是到服务器上配置配置工具,装装防火墙,优化一下系统之类的。估计比程序员还要先失业了。毕竟现在服务器装个codex或者kimi-cli等工具,妥妥的帮你配置好各种。为了安全你可以先不让他执行,或者你在另外的机器上问问题,只是在将服务器上的结果 反馈给Agent。

 
这种都不要太多量,kimi最便宜的/Qwen lite应该都可以。minimax大活做不了,这种小活还是问题不大的,毕竟大多数中小白,也都实时现 查的,那minimax可做的 就很多了。难道不是是吗?
 
自从各种agent/各种虾越来越多,天天都在叫,这个行业要消失了,那个行业要灭亡了,有没有灭亡不清楚,但每个月消耗的token倒是变多了,而且消耗的token变多了,原来的各种群,技术探讨群倒是越来越冷清了。怕是行业没消失,技术论坛、技术BBS以及 QQ聊天群之类,倒真是要消失了。。
 
 
Records:98412345678910»