@joe1213 不管，我就喜欢 😂 主要是跟我 i 系列的名字一致。要起个好的、又全球唯一的名字，几乎不可能。

@humorce 「装上去留着备用，一个月都不见得能用几次。」 iText 默认每月可免费识别 20 次，像你说的够用了。

@isCyan 并不能。因为如果提供客观公正的结论，要做大量的测试，我做不到，不能随便下结论；并且，云服务是在不断变化的。

不过，你提供一张具体的图，我是可以给出二者的识别结果的。

@WhiteSJ
@newbieo0O
@January 谢谢支持。

@WhiteSJ
@newbieo0O
@January

@zjia8765 谢谢，努力得到肯定，开心 😀

@douglas1997 谢谢肯定，我一直在坚持，iText 已经是第 7 款 macOS App 了😀

@caidaoli 谢谢肯定 🤝

@naiba 没事，你发出来吧。

@Jobin0528 咦，奇怪，我 28 小时前就在 iTunes 后台改过价格了，现在还没更新？可能是时差问题，美国时间还没到 30 号，可以再等等。

@liz2nku 大气👍

@zhuoziyu 没印象有类似服务提供 html 下载。

3、APP 官网
试试 AppSites.io

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

@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：

https://ws2.sinaimg.cn/large/006tNc79gy1fls07gxsm1j30b6040glr.jpg

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

https://ws3.sinaimg.cn/large/006tNc79gy1fls06y1pk2j30c803qju3.jpg

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

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

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

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

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

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

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

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

@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 ）里并没有说高精度识别的尺寸应该比较小。
https://ws1.sinaimg.cn/large/006tNc79gy1flru78845dj313q0763z4.jpg

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

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

@xiao17174 谢谢回复。

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

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

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

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

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