图片处理及上传命令行工具 —— PICTL
前言
自从博客从 WordPress 转到静态博客（先 Hexo 后 Jekyll）之后，文章的图片处理、图片上传就成了一个不大顺畅的事情。最先是使用了 vgy.me 提供的免费图床，支持直接从剪切板上传，操作上相对比较简单，也不需要任何本地存储。不过后来 vgy.me 进行了升级改版，原先的剪切板上传功能也不再支持了，偶尔还出现图片像素被降低、丢失的问题。同时，考虑到 WebP 格式可能会适合博客使用，而 vgy.me 还不支持该格式。于是开始切换到 “对象存储 + CDN” 的方案。本地准备好的 PNG 格式图片，先通过 cwebp 命令行转成 WebP 格式图片，再通过 uPic 工具修改文件名后上传到对象存储。由于此前采用的是腾讯云的 COS 对象存储和 CDN，经常面临着 SSL 证书更新等琐碎的事情。这样一来，整体的效率实际上并不高，只能说勉强接受。
现有工具及存储考察
为此，也对其他工具和对象存储进行了考察。
PicGo 是一款集客户端 UI 和命令行于一体的图片上传工具，虽然可以利用命令串联的方式简单将图片格式转换和上传两步变成一步，但还是有那么点不舒服的地方，比如 PicGo 不提供文件名修改（为固定长度随机字符串）的特性。而 uPic 本身关注于客户端桌面交互，不提供命令行接口。
至于对象存储，国内各家云服务厂商提供的都需要自行手动更新 SSL 证书，且收费。尽管腾讯云 CDN 目前老用户可以每月领券免费使用，但一旦忘记就开始被收费了。实际上也有逐步转向收费的趋势。国外各家云服务厂商基本上都需要收费使用对象存储或者 CDN，大差不差。
当然，网上一直有一种 “Backblaze B2 + Cloudflare” 的解决方案。由于 B2 本身存储和读写操作都有免费额度，流量需要收费，且无法自定义域名，而 B2 和 Cloudflare 同属于宽带联盟（内部流量免费），Cloudflare 还提供 URL 重写功能，这种解决方案一时成为了潮流。不过，B2 的访问链接是中间带着一串参数，重写之后仍然还是有部分参数，最终的 URL 并不是那么朴素。总的来说，还是有那么点别扭。
R2 的出现
因此观望了许久，直到 Cloudflare 推出了 R2。R2 是一款对标 AWS S3 的产品，基于 Cloudflare 对宽带联盟的承诺而构建，为存储对象提供零成本出口，实际上就是免费 CDN。由于 Cloudflare 本身就是一家 CDN 服务商，自定义对象存储访问域名、自动生成部署 SSL 证书这些事情就变得轻而易举了。R2 提供 10GB 的免费存储，读操作每月免费 1000 万次，写、更新和删除操作每月免费 100 万次。这对于一般的静态博客来说，应该完全足够了，即使超出了免费额度，超出部分收费也相较其他云服务厂商便宜一些。
对笔者而言，R2 产品将对象存储和 CDN 两款产品有机地结合起来，解决了静态博客图片对外访问前的“最后一公里”。于是想从 COS 迁移到 R2，无奈 uPic 这个时候卖了个“破绽”。uPic 似乎在开始转向商业收费，Github 上不再发布新版本，而仅在 Appstore 上继续更新对 R2 的支持。当然，Appstore 上的 uPic 是收费的（4.99 美元，其实也不贵）。
R2 虽然说是对标 AWS S3，但是并没有完整实现所有 API 接口，所以目前 Github 上发布的 uPic 版本无法兼容。尽管可以自行通过修改 uPic 的开源代码来实现兼容，但毕竟修改别人的代码的成本还是有一点高的。
开个新项目
在充分梳理个人使用需求之后，还是决定开个新项目——开发一款简单易用的命令行工具 PICTL（全称 Picture Control）。该工具须具备以下特性：
- 考虑图片的存储空间大小和网页加载时长，所有图片应被压缩并转成 WebP 格式；
- 所有图片的名称应被修改成一个固定长度随机字符串，并支持上传到类 S3 的对象存储；
- 简单易用，命令行优先，无网页或桌面交互界面；
- （可选）自动添加水印；
- （可选）根据设定自动调整图片尺寸；
- （可选）可以直接从剪切板读取图片。
架构设计
根据所列出的特性，这款命令行工具主要的模块就是：图片处理模块和上传模块，架构如下图所示。
图片处理模块包括图片压缩、图片格式转换、图片水印、尺寸调整等功能，可以进行无缝横向扩展。上传模块主要包括对于三种存储方式的支持：第一类是最为广泛的类 S3 对象存储，如 R2、AWS S3 及国内外云服务厂商各种对象存储等，第二类是目前仍然在博客中广泛流行的第三方图床，如 SM.MS、vgy.me、chevereto 类型图床等，第三类是自托管 Git 平台和 FTP 平台。
鉴于 Github、Gitlab、Gitee 等公共代码托管平台均禁止把 Git 仓库作为图床的做法，本工具仅支持自建 Git 平台，如自建 Gitlab 和 Gitlab Pages。如试图上传到公共代码托管平台，本工具会自行中断上传。
本工具由于仅支持命令行，所以计划用 Python 和 Click 进行开发。虽然借助 Google Fire 也可以快速开发命令行工具，但其使用方式上与原生 *nix 的命令行工具有所不同。相比之下，用 Click 开发可能会麻烦一点，但能够开发出更类原生的 Python 命令行工具。当然，目前开发上还是比较喜欢使用 Rust...
剩余内容已隐藏