今天在改进 iText 上传前压缩大图的功能。
其中，百度、腾讯、Google 等各家 OCR 服务对上传的图片尺寸都有要求、也都要求对图片进行 base64 压缩。可这要求跟要求可就不同了。
| 服务 | 宣称图片大小 | 实际可用大小 | 计算方式 |
|---|---|---|---|
| 百度 | 4 MB | 1.5 MB | 4 / 2 / 1.3 = 1.5 MB |
| 腾讯 | 1 MB | 0.5 MB | 1 / 2 = 0.5 MB |
| 4 MB | 4 MB | 4 = 4 M |
为什么实际大小与宣称大小不一致呢？
- 首先，base64 压缩后，得到的大小会增加约 1/3
- 进一步，base64 是使用字符串表示的。那么，一个字符串如 'a' 占几个字节呢？看起来百度是使用 2，腾讯是使用 1
- 综合起来，就是上面看到的缩水版大小
- 另外，百度要求图片最大分辨率为 4096 * 4096；而其他 2 家则无此要求
既然 base64 会带来计算上的麻烦，为什么不直接使用解压后的图片大小呢？没错，Google 就是这么干的。你无需考虑 base64 带来的尺寸增加，也无需考虑一个字符串到底占几个字节，只要原图是 4 MB 以下即可
从这一点上看，服务接口的素质（公司的节操）顺序为：
Google > 腾讯 > 百度
