Recraft AI Base64编码非法报错及图片格式规范【解答】

其实，Recraft AI报错的根源并不复杂——绝大多数情况下，是Base64字符串的预处理没做到位。后端解码器非常“挑剔”，要求标准字符集、长度为4的倍数、且不能带多余的mime头信息。搞清楚这几个硬约束，问题基本迎刃而解。

先看最常见的情况：后端直接拒绝“Invalid image data”或“Illegal base64 character”。这不是图片本身质量出了什么问题，而是前端传过去的Base64字符串格式不规范。换句话说，只要按照Recraft后端解码器的严格规范重新梳理一下，就能顺利通过。

剥离data URL前缀再解码

Recraft后端明确不接受带data:image/png;base64,头部的完整data URL字符串。直接提交这类内容，头部那些非Base64字符会立刻触发报错。怎么处理？两步走：

第一步，用英文逗号,分割字符串，取逗号之后的部分。第二步，检查截取后的字符串末尾有没有多余的空格或换行符——如果有，直接删除。如果末尾是%2B或%3D这类URL编码字符，必须先用decodeURIComponent()还原。这一步做完，得到的就是纯粹的Base64字符串，再去提交。这里有一个要点：

修复非法字符：+、-、_、空格

浏览器传参或某些前端库（比如FileReader的readAsDataURL）可能引入非标准字符。Recraft的标准解码器只认A-Z a-z 0-9 + / =这65个字符，出现其他字符就会报错。

有两个常用的修复方法：

方法一，替换URL安全变体字符——把-换成+，把_换成/，然后补全等号。方法二，暴力清洗法——用正则replace(/[^A-Za-z0-9+/=]/g, ')直接删除所有非Base64字符。不过要注意：如果原始字符串里混入了零宽空格（U+200B）这类Unicode控制符，这招很好用；但要是已经混进了中文标点，那说明整个字符串已经损坏，只能重传原图。

这里有个容易踩的坑：千万不要用encodeURIComponent()对Base64字符串做二次编码——Recraft完全不支持双重编码。

强制补全等号使长度为4的倍数

Base64字符串的长度必须是4的倍数，缺位要用=填充。否则Python或Ja va的解码器会抛出binascii.Error，Recraft则会返回Illegal base64 character。

计算当前长度除以4的余数：余1补3个=，余2补2个=，余3补1个=。举个例子，SGVsbG8=（8位，合法）这个就不需要补；但SGVsb（5位，余1），就得补成SGVsb===。操作虽然简单，但

验证图片格式与尺寸硬性要求

Recraft只接受JPEG和PNG两种格式，文件原始大小不能超过8MB——注意，这里说的是解码后的二进制体积，不是Base64字符串的长度。上传之前最好用本地工具（比如Photoshop的“导出为”，或者命令行magick convert input.jpg -quality 85 output.jpg）压缩到7.5MB以下，再编码提交。

宽高比没有限制，但单边像素不能超过16384。超限后，Recraft会静默裁切，导致构图异常。另外，不要尝试用WebP或A VIF格式转Base64提交——Recraft直接拒收，返回Unsupported image type。