前言

經(jīng)過幾個小伙伴的提醒，發(fā)現(xiàn)個人博客中的許多圖片都裂了無法訪問；原因就不多說，既然出現(xiàn)問題就得要解決。

原本我的處理方式非常簡單粗暴：找到原有的圖片重新下載下來上傳到新的可用圖床再把圖片地址替換。

這樣搞了一兩篇之后我就絕望了。。。

之前為了代碼能在公眾號里也有好的閱讀體驗，所以能截圖的我絕不貼代碼，導(dǎo)致一篇文章多的得有十幾張圖片。

好在哪位大佬說過“以人肉XX為恥”，這種重復(fù)勞動力完全可自動化；于是便有了本次的這個工具。

它可以一行命令把你所有 Markdown 寫的內(nèi)容中的圖片全部替換為新的圖床。

運(yùn)行效果如下：

使用

可以直接在這個地址下載 jar 包運(yùn)行：https://github.com/crossoverJie/blog.toolbox/releases/download/v0.0.1/blog.toolbox-0.0.1-SNAPSHOT.jar

當(dāng)然也可以下載源碼編譯運(yùn)行：

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

看運(yùn)行方式也知道，其實(shí)就是用 SpringBoot 寫了一個工具用于批量下載文中出現(xiàn)的圖片同時上傳后完成替換。

• 其中 app.downLoad.path 是用于將下載的圖片保存到本地磁盤的目錄。
• /xx/xx/path 則是掃描 .md 文件的目錄，會遞歸掃描所有出所有文件。
• 100 則是需要替換文件的數(shù)量，默認(rèn)是按照文件修改時間排序。

如果自己的圖片較多的話還是有幾個坑需要注意下。

線程數(shù)量

默認(rèn)是啟動了兩個線程去遍歷文件、上傳下載圖片、更新文本等內(nèi)容，其中的網(wǎng)絡(luò) IO 其實(shí)挺耗時的，所以其實(shí)可以適當(dāng)?shù)亩嚅_些線程來提高任務(wù)的執(zhí)行效率。

但線程過多也許會觸發(fā)圖床的保護(hù)機(jī)制，同時也和自己電腦配置有關(guān)，這個得結(jié)合實(shí)際情況考慮了。

所以可以通過 --app.thread=6 這樣的參數(shù)來調(diào)整線程數(shù)量。

圖床限制

這個是圖片過多一定是大概率出現(xiàn)的，上傳請求的頻次過高很容易被限流封 IP。

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

目前來看是封 IP 居多，所以可以通過走代理、換網(wǎng)絡(luò)的方式來解決。

當(dāng)然如果是自搭圖床可以無視。

重試

由于我使用的是免費(fèi)圖床，上傳過程中偶爾也會出現(xiàn)上傳失敗的情況，因此默認(rèn)是有 5 次重試機(jī)制的；如果五次都失敗了那么大概率是 IP 被封了。

即便是 ip 被封后只要換了新的 ip 重新執(zhí)行程序它會自動過濾掉已經(jīng)替換的圖片，不會再做無用功，這點(diǎn)可以放心。

圖片保存

默認(rèn)情況下,下載的圖片會保存在本地，我也建議借此機(jī)會自己本地都緩存一份，同時名字還和文中的名字一樣，避免今后圖床徹底掛掉后連恢復(fù)的機(jī)會都沒有。

總結(jié)

這個程序的代碼就沒怎么講了，確實(shí)也挺簡單，感興趣的可以自己下來看看。

目前功能也很單一，自用完全夠了；看后續(xù)大家是否還有其他需求再逐漸完善吧，比如：

• 圖床上傳失敗自動切換到可用圖床。
• 整體處理效率提升。
• 任務(wù)執(zhí)行過程中更好的進(jìn)度展現(xiàn)等。

再次貼一下源碼地址：

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

你的點(diǎn)贊與分享是對我最大的支持

轉(zhuǎn)載于:https://www.cnblogs.com/crossoverJie/p/10836405.html

總結(jié)

以上是生活随笔為你收集整理的图床失效了？也许你应该试试这个工具的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。