从 API 的素质可以看出公司的气质

[quietjosen]

今天在改进 iText 上传前压缩大图的功能。其中，百度、腾讯、Google 等各家 OCR 服务对上传的图片尺寸都有要求、也都要求对图片进行 base64 压缩。可这要求跟要求可就不同了。

为什么实际大小与宣称大小不一致呢？

• 首先，base64 压缩后，得到的大小会增加约 1/3
• 进一步，base64 是使用字符串表示的。那么，一个字符串如 'a' 占几个字节呢？看起来百度是使用 2，腾讯是使用 1
• 综合起来，就是上面看到的缩水版大小
• 另外，百度要求图片最大分辨率为 4096 * 4096 ；而其他 2 家则无此要求

既然 base64 会带来计算上的麻烦，为什么不直接使用解压后的图片大小呢？没错，Google 就是这么干的。你无需考虑 base64 带来的尺寸增加，也无需考虑一个字符串到底占几个字节，只要原图是 4 MB 以下即可

从这一点上看，服务接口的素质（公司的节操）顺序为：

Google > 腾讯 > 百度

[kunluanbudang]

还有国内公司的 REST API, 用户体验是..

[tlday]

看不懂"一个字符如'a'占几个字节"这条。base64 不就是拿 4 个字节表示原来三个字节表示的东西，用 64 个可见字符映射了 256 个全量字符，不能被三整除的余位补等号的算法么，怎么还有'a'占几个字节这一说。这 64 个可见字符都是 ascii 标准可见字符，在 utf8 和 ascii 下编码和占用空间不也是一样的么，怎么还有百度用 2，腾讯用 1 之分？

[OldPanda]

不禁想起两年前用豆瓣 API 搞了个图片同步工具，然而不久后豆瓣就把 API 关了 ┑(￣Д ￣)┍

[Keyblade]

应该是
Google > 腾讯 ＝ 百度

[CSM]

第一看到 base64 *压缩*这种说法...

[onlyice]

感觉这个有点为黑而黑了。

你觉得像百度 / 腾讯会在意这点大小吗？用 2M 会比 1M 增加很多成本吗？会需要为了宣传而搞一个大一点的数字吗？有什么意义呢。。

这只能说明文档上写得不严谨，还能跟公司挂钩起来，也是有意思

[missdeer]

第一看到 base64 *压缩*这种说法...+1

[azygote]

压缩后体积会变大……

[MrSong0607]

第一看到 base64 *压缩*这种说法...+2，base64 不是编码么

[xiaojunjor]

“首先，base64 压缩后，得到的大小会增加约 1/3 ”。。。压缩后大小增加了？？？

[leeg810312]

百度和腾讯没有在文档说清大小是 base64 格式，谷歌说的是图片文件大小，为黑而黑，而且还说错了，base64 是压缩？

[xsd3169]

第一看到 base64 * 压缩 * 这种说法...+3。。。确定不是 ** 膨胀 **吗？

[q409195961]

第一看到 base64 *压缩*这种说法...+4

编码：aGVsbG8lMkN3b3JsZA==
明文：hello,world

压缩了？？

[onlyice]

百度的文档[1]，清晰地写着「 base64 编码后大小不超过 4M 」；腾讯的文档[2]写着「原始图片的 base64 编码数据（解码后大小上限 1MB，支持 JPG、PNG、BMP 格式）」。

楼主我不得不说这文章体现的是你的节操？

[1] https://cloud.baidu.com/doc/OCR/OCR-API.html
[2] https://ai.qq.com/doc/ocridcardocr.shtml

[marcong95]

@onlyice 2M 跟 1M 翻了个倍，成本也翻倍，作为一家巨头公司成本翻倍不在意？多了 50%的利润空间根据邓宁格的说法就已经引起积极的冒险了。资本是逐利的，国内大型公司没节操的事情还见得少？

不过呢，这件事上好像并不怎么能黑，我看了下他们的文档，百度写的是 base64 字符串小于 4096K，腾讯写的是图片小于 1M，跟楼主所说的一致，两者好像都没有什么不严谨的地方。

[marcong95]

@marcong95 更正一下用词：百度说的是编码后不大于 4M

[mengzhuo]

看到 base64 压缩之后就不想看后面，直接看评论

[xfspace]

楼主想黑百度腾讯，没想到被自己智商秀了一波

[onlyice]

@marcong95 一个 OCR 服务能有多少成本？又不是全部服务都翻一倍。但这不是重点，重点还是人家文档已经写清楚了，楼主强行表示对方夸大

[DOLLOR]

此前见过说 base64 “加密”的，base64 “压缩”倒是第一次见……