@hester 谢谢你的回复.在你说这段话之前,我还真没意识到要区分产品或是 Demo.所以在读了你这段话之后,我可以确定,我做的就是一个 Demo.唔,大概我正文里提到的"小玩具"一词可以作些许旁证吧.
至于长期维护与 github.我个人只在 github 上放源码.如果只是 exe.就算了.我的想法是这只是一个小玩具.可能过了两天,我的这个程序就只能在我的硬盘里找到曾经存在的证明了.
不过正如我回复另一个朋友的话,如果真的有人喜欢,愿意一直的给我提意见,那我非常愿意继续维护和改进,并且开放源码.毕竟整个程序核心还是调用在线的 api(还是人家给的免费额度,嘿嘿).当前的话,我的程序的反馈途径只有这个帖子和我程序里的邮箱了.
我以前是做服务端程序的.写界面算是个新手.我的初衷是练个手.
至于蹭热度,只是随口说的.
我有想法写这个程序,是在 13 天前.刚好回复过 iText 作者的某个帖子(不知道别人能不能看到我的回帖记录,可以去看看),看到有人问有没有 windows 版.在那之后几天就写了这个程序.
然后昨天和今天发现大家都在讨论这个事.我就随手把我的程序分享出来了.
无所谓认同或者其它的.就图个热闹.

@jucelin 啊.我没参考.自己乱想了一个需求然后就写了.你的程序给我看看.让我参考一下.

@harry890829 哈.这个本身没有任何技术含量.乱写的代码.就先不开源了吧.如果后期有大家的反馈做得完善一点了我再开源.没别的意思.现在的代码没法看.唔...我的高手人设不能崩.

哈哈,我也凑个热闹.我也是看到那个 iText 之后自己也写了一个.Windows 版的.
免费使用.
https://pan.baidu.com/s/1pLJtyrh

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

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

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

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

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

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

allow listed only:
if(lists == null)
reject all connect;