博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
图床失效了?也许你应该试试这个工具
阅读量:6232 次
发布时间:2019-06-22

本文共 1337 字,大约阅读时间需要 4 分钟。

前言

经过几个小伙伴的提醒,发现个人博客中的许多图片都裂了无法访问;原因就不多说,既然出现问题就得要解决。

原本我的处理方式非常简单粗暴:找到原有的图片重新下载下来上传到新的可用图床再把图片地址替换。

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

之前为了代码能在公众号里也有好的阅读体验,所以能截图的我绝不贴代码,导致一篇文章多的得有十几张图片。

好在哪位大佬说过“以人肉XX为耻”,这种重复劳动力完全可自动化;于是便有了本次的这个工具。

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

运行效果如下:

使用

可以直接在这个地址下载 jar 包运行:

当然也可以下载源码编译运行:

git clone https://github.com/crossoverJie/blog.toolboxmvn clean packagejava -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 重新执行程序它会自动过滤掉已经替换的图片,不会再做无用功,这点可以放心。

图片保存

默认情况下,下载的图片会保存在本地,我也建议借此机会自己本地都缓存一份,同时名字还和文中的名字一样,避免今后图床彻底挂掉后连恢复的机会都没有。

总结

这个程序的代码就没怎么讲了,确实也挺简单,感兴趣的可以自己下来看看。

目前功能也很单一,自用完全够了;看后续大家是否还有其他需求再逐渐完善吧,比如:

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

再次贴一下源码地址:

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

转载地址:http://tyena.baihongyu.com/

你可能感兴趣的文章
用 Unity 做个游戏(七) - TCP Socket 客户端
查看>>
npm安装vue-cli报错 -4058 的解决方法
查看>>
2019年首发,有耐心且多思考
查看>>
ios UIWindow swift
查看>>
阿里云态势感知服务相关概念
查看>>
PHP 字符串中的 Heredoc 和 Nowdoc
查看>>
京东淘宝始料未及,小程序将是未来首选购物渠道
查看>>
js事件冒泡和传播详细解释
查看>>
笔试题
查看>>
[番外篇]k位精巧数
查看>>
Spring Security实战 - 短信登录
查看>>
(九)企业级java springcloud b2bc商城系统开源源码二次开发:配置中心和消息总线(配置中心终结版)...
查看>>
Redis 数据采样
查看>>
ELK搭建以及使用大全
查看>>
本地HOSTS测试管理工具
查看>>
httpwatch使用技巧
查看>>
视图的with check option解释
查看>>
我的友情链接
查看>>
安装nginx+tomcat
查看>>
Android配置环境与引入第三方jar包
查看>>