图床失效了？也许你应该试试这个工具

前言

通过几个小伙伴的提醒，发现我的博客中的许多图片都裂了没法访问；缘由就很少说，既然出现问题就得要解决。

本来个人处理方式很是简单粗暴：找到原有的图片从新下载下来上传到新的可用图床再把图片地址替换。

这样搞了一两篇以后我就绝望了。。。

以前为了代码能在公众号里也有好的阅读体验，因此能截图的我毫不贴代码，致使一篇文章多的得有十几张图片。

好在哪位大佬说过“以人肉XX为耻”，这种重复劳动力彻底可自动化；因而便有了本次的这个工具。

它能够一行命令把你全部 Markdown 写的内容中的图片所有替换为新的图床。

运行效果以下：

使用

能够直接在这个地址下载 jar 包运行：https://github.com/crossoverJie/blog.toolbox/releases/download/v0.0.1/blog.toolbox-0.0.1-SNAPSHOT.jar

固然也能够下载源码编译运行：

git clone https://github.com/crossoverJie/blog.toolbox
mvn clean package
java -jar nows-0.0.1-SNAPSHOT.jar --app.downLoad.path=/xx/img /xx/xx/path 100

看运行方式也知道，其实就是用 SpringBoot 写了一个工具用于批量下载文中出现的图片同时上传后完成替换。

• 其中 app.downLoad.path 是用于将下载的图片保存到本地磁盘的目录。
• /xx/xx/path 则是扫描 .md 文件的目录，会递归扫描全部出全部文件。
• 100 则是须要替换文件的数量，默认是按照文件修改时间排序。

若是本身的图片较多的话仍是有几个坑须要注意下。

线程数量

默认是启动了两个线程去遍历文件、上传下载图片、更新文本等内容，其中的网络 IO 其实挺耗时的，因此其实能够适当的多开些线程来提升任务的执行效率。

但线程过多也许会触发图床的保护机制，同时也和本身电脑配置有关，这个得结合实际状况考虑了。

因此能够经过 --app.thread=6 这样的参数来调整线程数量。

图床限制

这个是图片过多必定是大几率出现的，上传请求的频次太高很容易被限流封 IP。

{"code":"error","msg":"Upload file count limit. Time left 1027 second."}

目前来看是封 IP 居多，因此能够经过走代理、换网络的方式来解决。

固然若是是自搭图床能够无视。

重试

因为我使用的是免费图床，上传过程当中偶尔也会出现上传失败的状况，所以默认是有 5 次重试机制的；若是五次都失败了那么大几率是 IP 被封了。

即使是 ip 被封后只要换了新的 ip 从新执行程序它会自动过滤掉已经替换的图片，不会再作无用功，这点能够放心。

图片保存

默认状况下,下载的图片会保存在本地，我也建议借此机会本身本地都缓存一份，同时名字还和文中的名字同样，避免从此图床完全挂掉后连恢复的机会都没有。

总结

这个程序的代码就没怎么讲了，确实也挺简单，感兴趣的能够本身下来看看。

目前功能也很单一，自用彻底够了；看后续你们是否还有其余需求再逐渐完善吧，好比：

• 图床上传失败自动切换到可用图床。
• 总体处理效率提高。
• 任务执行过程当中更好的进度展示等。

再次贴一下源码地址：

https://github.com/crossoverJie/blog.toolbox

你的点赞与分享是对我最大的支持