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

[quietjosen]

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

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

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

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

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

Google > 腾讯 > 百度

哎，我真是看不出黑百度或者腾讯对我有什么好处，只是多次试错后过来发个牢骚。

对，base64 编码我写成了压缩，这点可以喷；

对，「计算方式」是我根据测试结果逆推的，看起来是有点问题，这个可以喷；不过「实际可用大小」是我实测的结果，这个是准确的。

以上，请尽情喷、吐槽、BS；吐爽了，可以往下看；不然请继续。

---

不过，「base64 编码后大小是 4 MB」，请问这 4MB 如何计算？

是 4MB 「个」编码后的字符串？测试结果不是；是每个字符占 2 个字符吗？百度的测试结果是（虽然这并没太多道理）。 还请行家指个点，这个 4MB 到底怎么比较？最好解释清楚后再 BS 我，显得更专业。

所以，我最想吐槽的是这一点：为什么不直接使用原图来判定、而要用 base64 的这个说不清楚的大小？平白给开发者带来这样的麻烦？只是为了服务器减少一次解码的开销？我只能这么想。

「宣称图片大小」这个用词不对，我认。 base64 是编码不是压缩，我懂，不然我也不会说到 1/3 这个词。你要揪着用词不放，你开心就好。

百度和腾讯文档里提了 base64 编码的大小，我绝逼知道。我发贴是为吐槽那些不用图片原始大小、而非得用 base64 编码大小来比较的服务。我吐槽，是因为我花了不少时间试错，不爽，所以要吐槽。

如果你觉得我是来秀下线的、或者觉得我没有资格在 V 站吐槽我认为不爽的事情、或者是为 iText 上线前宣传造势，欢迎在 V 站 Block 我：点我的头像，右边有个 Block. 这样，可以节约你我的时间。谢谢。

最后，继续欢迎有高手能明确指出 4MB 的 base64 到底应该如何比较？最好你试试后再来；因为我试过多次，跟想当然的并不一样，谢谢。

我就问一句：多大（字节）的图片，可以上传至百度、腾讯 OCR 服务？

如果你知道，欢迎告诉我。

我知道，4MB 的图片可以上传至 Google；我自己试过 3.9MB，可以的。

在表达你的观点之前，请先看下 #64 楼很有技术含量的回复，已经 #65 楼。

我收回对百度的批评，并对百度可能的名誉损失道歉。

不过，我依然对百度此 API 保留意见，具体请看 #69

[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 “压缩”倒是第一次见……

[abujj]

谷歌 API 地址能发下看看吗？ 楼主

[bzzhou]

base64 压缩，呵呵

[ORZRRR]

@mengzhuo 都是程序员，给点面子，看还是要认真看的，

[BBCCBB]

https://juejin.im/post/5a1449cef265da432717dc14

这个也是你嘛

[xiao17174]

显然楼主对于为什么用 base64 完全不懂,对于字符编码,字节,位什么的更是从来没有涉及过.
由此可以推断楼主在成为程序员后就一直从事高级语言的相关工作.
建议楼主可以适当下潜,多了解一些基础的东西.
最后解答一下楼主提出来的"请问这 4MB 如何计算？"
答:不要把字符编码和数据大小混在一起.
一个字符'a'占用几个字节是你自己决定的,当你声明你发送的是以 ascii 编码的数据时,它占一个字节.当你声明你发送的是以 chibaolechengde 编码的数据时,它可以是占 10 个字节.
既然人家都说了是要 base64 后的数据发送,那么显然是 ascii 编码.即编码后的数据,每一个可见的字符,如'A','='都是占用一个字节.

[keenwon]

base64 是压缩？

[xiao17174]

另外,多一次 base64 编码在麻烦程度上来说,对谁都没有好处.服务器在拿到你 base64 的数据后,必然是要做一次反编码来获取真实数据的.只是 base64 可以归一化所有的二进制数据到 ascii 码上,从而变成更通用的 string.

[keenwon]

歪个楼，MD5 算加密吗？

[xiao17174]

@keenwon 是摘要算法.可以理解一个 md5 是一篇文章的中心思想.
加密成立的前提在我看来是可以解密,但是我们显然无法从中心思想反推全文,所以不算.

[skadi]

@BBCCBB hhhhhhhh 掘金的回复和 v2 的回复。。
对比起来好搞笑。

[ioth]

说明咱天朝人会过日子，节省

[Youen]

阿里的我测试过,文档说图片大小不超过 1.5MB, 我用 1.47MB 文件 base64 编码后约 1.9MB 可以识别

[sneezry]

其实 API 更严格的限制并不让人不快，即使百度最大图片支持 1.5MB 也没什么问题。问题是为了显示自己有优势而进行虚标，这在实际使用时会出现诡异的问题。

[zwh2698]

顶，兄弟

[jyf]

从吐槽上也能看出一个人的素质 这不就是百度图省事 在上传服务器上做了个请求体大小的限制么 这种也要罗嗦一堆也真是

[nine99]

itext 还不发布吗

[veightz]

一个 API 也许能代表某个开发，但是代表不了一个公司

[mikulch]

国外的公司，在人性化，细节等方面本身就完爆中国的公司
从制造业就能看出来了。

[zhouyg]

百度最喜欢搞虚假的东西，果然连技术人员的骨子里都是腐蚀透了

[moonsola]

@sneezry 14L 有文档，对传输数据的大小限制描述的非常清晰，不存在虚标，这个表格是楼主根据自己的错误理解做的
@zhouyg 对事不对人，估计文档放你眼前你也不会去看，那最起码把楼上的回复都看过之后再发言吧

[schema]

标题日常哗众取宠

[st2udio]

原始图片的 base64 编码数据（解码后大小上限 1MB，支持 JPG、PNG、BMP 格式）

base64 编码后大小不超过 4M，最短边至少 15px，最长边最大 4096px

有不对的宣传吗？不懂。。 [为什么实际大小与宣称大小不一致呢？]

还只是为了推广你的软件，所以要

[so898]

腾讯那个确实有点难找，百度这个可是重复声明了 14 遍啊~~~~~~
估计楼主的母语是英语吧，看英文仔细程度大于看中文仔细程度

[yuriko]

当喷国内公司变成政治正确的时候，不懂瞎说的也有底气了……

[MushishiXian]

v2 太可怕了...

[Charkey]

so 世界好可怕，到处 pen

[quietjosen]

@xiao17174 在这些回复中，你的最有技术含量。

不过，事实上，如果发送 3MB 个字符（按你所说是 ASCII 编码）的 base64 编码的图片给百度，百度是会报错的，说图片尺寸不对。我也只能推测 http 请求是按 utf8 传送、每个字符占 2 位，所以要 /2 ；不然，我是没办法和事实对应。

[xiao17174]

@quietjosen utf-8 是一种编码规范,实际上它是可变长的,并不是所谓的每个字符占 2 字节(不是位).而且正如楼上某位说的,utf8 是兼容 ascii 的,也就是说针对'a''A'这种,utf8 也规定只占用一个字节.可能我说这些你会听得一头雾水.
如果有空可以自己了解一下.

至于你说的猜测,我也有几个猜测.
1.你以为的 3MB 个字符其实并不是真的 3MB,实际的字节数已经超过 4MB,你可以看下你的 context-length 上标识的是多少.
2.如返回值所说,你传的图片的尺寸真的超出 15px*4096px 限制.
3.你传的数据在某个过程中被截断了.可能是你这边,也可能是在服务器那边,错误的数据导致了百度解析图片出错,而服务端的返回值延用了尺寸不对的错误码.本质上是数据解析(读取图片)出错.

[xiao17174]

我为什么这么空....伤脑筋啊...

[quietjosen]

@xiao17174 谢谢回复。

1. 对，我说的是 3MB 个字符；如果确实是用 UTF8 编码、英文字符占 1 个字节，那按道理应该是 3MByte 了。
2. 图片没有超出尺寸限制
3. 应该不是，因为如果解析出错，返回的错误是不同的。

有时间，我测试下连续的尺寸，比如 2.01MB/2.02MB/…/3.00MB，看哪个尺寸开始不行。

问题就在于：为什么要让每个接入服务的开发者，花这么无谓的时间、做这种无谓的试错？看看人家 Google，只要原图 OK 就行。

[xy90321]

@quietjosen 如果照着 API 文档开发也能算试错的话，我建议你自己去发明所有轮子这样就不存在试错了

别人 API 文档里写的那么清楚了，哪里存在试的过程了。。。

要吐槽 API 不够人性化那就请明明白白吐槽 API 不够人性化

非要整点素质啊气质啊什么的，上升到百度腾讯就是渣渣，看我大谷歌秒杀全场

再加上顶楼里那简直可以称为之污蔑诽谤与事实完全不符的描述

这就是所谓的带节奏失败反过来装人畜无害吗？

[sicongwang]

为黑而黑， 已 block

[leonzoe]

只能说同情楼主了.楼上一群人既没试过,也没给个公式算一下,这就开始喷了,斯阔以.

[inoris]

同情楼主。

[binux]

@skadi #30 这就是我喜欢上 v2 的原因啊

[Technetiumer]

這說明了 Google 更人性化
節省了你的時間去計算 base64 後大小

評論裡有人說樓主為了噴爾噴
那我也回复不要為了噴爾噴

[chnyang]

@Technetiumer 指出楼主为喷而喷并不算喷

[dazui]

国内都是参考切糕的卖法，只卖 10 元，然后你要算算是 1 克、1 块还是 1 斤

[atcdef]

楼上有很多抠字眼，base64 压缩，这样说应该明白楼主说的是编码，至于死抠“压缩”两个字么。

[root123]

同情楼主。+1
很喜欢 LZ 的系列 APP，都很方便实用。
而且在开发 APP 的过程中，楼主也经常分享技术、运营的相关经验，很不错啊。

[Tokin]

google 明显更人性化啊，虽然百度和腾讯文档写的很清楚，但是明明可以做的更好的。大概这就是气质？？？

[pathbox]

讲真 API 文档这一类，是一家互联网科技公司的 “门面” 。大家共勉

[jimrok]

google 确实比百度好不少，接口文档就是计算机里的电路板，看过苹果的，再看其他的机器就知道差距是全面的。

[XYxe]

https://i.loli.net/2017/11/23/5a162fb434cdf.png 这是一个 2.48MB （ 5752*4824，超过要求了）的图片，base64 以后是 3.31MB。

时间有限，只测试了百度的 API。代码：

```python
import requests
import base64

rsp = requests.post('https://aip.baidubce.com/oauth/2.0/token', data={'grant_type': 'client_credentials', 'client_id': API_Key, 'client_secret': Secret_Key})
token = rsp.json()['access_token']

f = open('sbpen.png', 'rb')
d = f.read()
b64data = base64.b64encode(d)

rsp = requests.post('https://aip.baidubce.com/rest/2.0/ocr/v1/general_basic', data={'access_token': token, 'image': b64data})
print(rsp.json()['words_result'])
```
输出：
[{'words': '为什么实际大小与宣称大小不一致呢?'}, {'words': '首先,base64 压缩后,得到的大小、会增加约 1/3'}, {'words': '·进一步,base64 是使用字符串表示的。那么
,一个字符串如\'a"占几个字节呢?看起来百度是使用 2,腾讯是使用 1'}, {'words': '综合起来,就是上面看到的缩水版大小'}, {'words': '另外,百度要求图片最大分辨率为 409
6*4096;而其他 2 家则无此要求'}, {'words': '既然 base64 会带来计算上的麻烦,为什么不直接使用解压后的图片大小呢?没错, Google 就是这么干的。你无需考虑'}, {'words':
'base64 带来的尺寸增加,也无需考虑一个字符串到底占几个字节,只要原图是 4MB 以下即可'}, {'words': '从这一点上看,服务接口的素质(公司的节操)顺序为:'}, {'words':
'Goog1e>腾讯>百度'}, {'words': '第 1 条附言·1 天前'}, {'words': '哎,我真是看不出黑百度或者腾讯对我有什么好处,只是多次试错后过来发个牢骚'}, {'words': '对,base
64 编码我写成了压缩,这点可以'}, {'words': '对,「计算方式」」是我根据测试结果逆推的,看起来是有点问题,这个可以喷;不过「实际可用大小√」是我实测的结果,'}, {'w
ords': '这个是准确的。'}, {'words': '以上,请尽情喷、吐槽、Bs;吐爽了,可以往下看;不然请继续。'}, {'words': '不过,「 base64 编码后大小是 4MB 」,请问这 4MB 如何计算
?'}, {'words': '是 4MB 「个」编码后的字符串?测试结果不是;是每个字符占 2 个字符吗?百度的测试结果是(虽然这并没太多道'}, {'words': '理)。还请行家指个点,这个 4MB 到
底怎么比较?最好解释清楚后再 BS 我,显得更专业'}, {'words': '听以,我最想吐槽的是这一点:为什么不直接使用原图来判定、而要用 base64 的这个说不清楚的大小?平白给开发
者带'}, {'words': '来这样的麻烦?只是为了服务器减少一次解码的开销?我只能这么想。'}]



不知道你的 1.5MB 是怎么得出来的。

另外，计算一个字符串占用空间很难吗？

[quietjosen]

@XYxe 首先，谢谢你这么有技术含量的回复。

1. 我试了你的代码和图片，可以上传、识别，没有问题。
2. 我试了你的图片和我的代码，依然提示图片大小不正确。

为什么呢？

我检查了下，因为你用的是普通的识别：
https://aip.baidubce.com/rest/2.0/ocr/v1/general_basic

我用的是高精度识别：
https://aip.baidubce.com/rest/2.0/ocr/v1/accurate_basic

如果，

- 你的代码改用高精度识别，失败，提示图片大小不正确。你可以试试。
- 我的代码改用普通识别，成功

依然是几个事实：

- 百度的文档（ https://cloud.baidu.com/doc/OCR/OCR-API.html ）里并没有说高精度识别的尺寸应该比较小。


- 为什么 5752*4824 明明已经超出了百度规定的「最长边最大 4096px 」，普通版依然能正确识别？

我就不推导什么结论了，看官自己心里自有判断。

[XYxe]

@quietjosen #61 这个错误提示是因为图片尺寸太大了。
https://i.loli.net/2017/11/23/5a163e6d996a8.jpg 这个 2.95 MB，4000*3356，base64 以后大概 3.9MB 。
高精度识别，你试试？

[quietjosen]

@XYxe 我用你的图片试了，高精度可以识别。

那看来上一张图说明的问题是：通用文字识别对最大分辨率的判断不准确，而高精度识别是则是准确的。

另外，百度的错误码并没有区分是图片太大，还是分辨率太大，是混在一起的，不太好：
216202 image size error 上传的图片大小错误，现阶段我们支持的图片大小为：base64 编码后小于 4M，分辨率不高于 4096*4096，请重新上传图片

到目前，我奇怪的是，我之前确实出现过分辨率正确、图片尺寸太大，也返回 216202 这个错误。这次用你的图试，就没出现。之后有时间多造些图试试。不过目前打算中文抱腾讯的大腿了，因为感觉腾讯对英文的识别比百度好。国外用户抱 Google 大腿。

[Kisesy]

@quietjosen 你就不能发个你不行的例子，让别人试一下吗

[quietjosen]

@Kisesy 你这个问题问的很好。

首先回答你的问题：我应该是无法提供这样的图了。具体请向下看：

我在试着做出这样的图时，可能发现了问题。比如，当我在压缩一张 2000*2000、大小为 5,217,759 bytes 的图时，当「压缩」为 2187*2187、大小为 2,397,638 bytes 时，我觉得，恩，图片肯定对了，base64 后大小也没问题。于是就去上传到百度，发现还是得到 216202 这个错误。我想，分辨率没有问题，自然是图片大小比较出现问题。恰好，当继续压缩后（比如文中提到的 1.5MB ）时，可以上传并成功识别了。

所以，我会得出文中开头的推论：可能跟 base64 大小及编码比较有关。

但，你在让我提供这样的图时，我就把压缩过程中、存在于内存中的图片输出出来，结果一看，虽然大小确实是 2,397,638 bytes，但分辨率却是：4374*4374，超出了百度 4096*4096 的限制，所以出错了。

奇怪，明明是压缩了，为什么分辨率反而提高了？

我又用工具查看图片信息，发现 DPI 是 144：



这应该就是原因了。原图应该是 72 DPI 的，而由于我通过 NSImage 缩放、在用 NSBitmapImageRep 取 jpeg 格式的 Data 时，估计 Mac Book Pro 使用 144 来计算 pixels，也就是，把 2187*2187 乘以 2，变成了 4374*4374。



于是这些计算都在内存中，我确实没有发现；直到你让我提供这样的图，还得谢谢你的问题。

所以，我应该收回对百度的批评，并对百度可能的名誉损失道歉。

不过，我依然保留对百度此 API 保留意见：

- 如果百度返回错误区分图片大小和分辨率错误，我就可以很容易地发现问题。
- 如果百度不限制分辨率（ Google 和腾讯均未限制），也就不会出现问题。

[quietjosen]

更正：上楼中的 2000*2000、大小为 5,217,759 bytes 的图，数据不正确，应该是 3000*3000、大小为 13,452,222 bytes ；多次测试过程中，数据贴错了，抱歉。