curl传递Base64编码数据报参数过长、文件格式不支持报错咨询

• 触发*参数列表过长（Argument list too long）*错误：直接将超长Base64字符串拼接在--data的命令行参数中，会触发操作系统对命令行参数长度的限制阈值，属于系统层面的拦截，和接口逻辑无关。
• 触发文件已损坏或格式不受支持错误：核心是curl的@文件传参语法使用错误。curl仅在--data的参数值以@开头、作为整个参数值时，才会读取@后路径对应的文件内容替换参数位置；你将@file.txt包裹在JSON字符串内部，curl不会解析JSON结构去替换字段内的文件引用，只会把字面量字符串@file.txt作为base64Source字段的值传给接口，接口拿到的不是合法Base64内容自然报错。除此之外你之前写的JSON使用单引号包裹键值，不符合标准JSON的双引号语法要求，也是潜在的格式错误。

优先推荐直接传二进制源文件的方案，不需要手动做Base64编码，操作更简单也不容易出错；如果业务要求必须传Base64编码内容，可以使用构造完整请求体文件的方案。

方案1：直接上传二进制源文件（推荐） #

Azure Form Recognizer接口原生支持直接接收二进制文件作为请求体，不需要提前转Base64，执行以下命令即可：

curl -v -i POST "https://contoso.azure.com/formrecognizer/documentModels/prebuilt-idDocument:analyze?api-version=2022-06-30-preview" \
-H "Content-Type: application/octet-stream" \
-H "Ocp-Apim-Subscription-Key: <替换为你的订阅密钥>" \
--data-binary "@/本地路径/你的身份证源文件（支持图片、PDF格式）"

注意点：

• 必须用--data-binary参数传文件，不要用普通--data，避免文件内容被转义修改
• @后面直接跟源文件的本地绝对/相对路径，不需要额外包裹JSON结构

方案2：通过base64Source字段传Base64编码内容 #

需要先构造完全符合规范的完整JSON请求体文件，再让curl读取整个文件发送，不要尝试在JSON字段值内部嵌入文件引用，步骤如下：

1. 确认存储Base64内容的file.txt中只有纯Base64字符串，没有多余的换行、空格、注释内容。
2. 生成合法的JSON请求体文件，命名为req.json，文件内所有键和字符串值必须用双引号包裹，格式如下：

   {
       "base64Source": "替换为file.txt内的完整Base64字符串，不要加@前缀"
   }
   

   Linux/macOS环境可以直接执行以下命令自动生成合法的req.json，不需要手动复制粘贴超长Base64内容：

   echo -n "{\"base64Source\":\"$(cat file.txt | tr -d '\n\r')\"}" > req.json
   

   该命令会自动读取file.txt内容、删除多余的换行符，拼接成合法JSON结构存入req.json。
3. 执行curl命令读取整个req.json作为请求体发送：

   curl -v -i POST "https://contoso.azure.com/formrecognizer/documentModels/prebuilt-idDocument:analyze?api-version=2022-06-30-preview" \
   -H "Content-Type: application/json" \
   -H "Ocp-Apim-Subscription-Key: <替换为你的订阅密钥>" \
   --data "@req.json"
   

   此处@req.json直接作为--data的完整参数值，curl会正确读取req.json的全部内容作为请求体发送给接口。

• curl不会解析JSON、XML等结构化请求体的内部内容，所有@文件路径的引用必须写在参数值的最外层，才能被curl识别为文件读取指令。
• 发送JSON请求时必须严格使用双引号包裹键名和字符串值，单引号不符合JSON语法规范，会被接口判定为非法请求。

内容的提问来源于stack exchange，提问作者ask4sunny