javascript 文件上传请求中的内容传输编码
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5169434/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Content-Transfer-Encoding in file uploading request
提问by Scalar
I'm trying to upload file, using XMLHTTPRequest, and sending this headers:
我正在尝试使用 XMLHTTPRequest 上传文件并发送此标头：
Content-Type:multipart/form-data, boundary=xxxxxxxxx
--xxxxxxxxx
Content-Disposition: form-data; name='uploadfile'; filename='123_logo.jpg'
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
/*base64data*/
But on server side PHP ignore header "Content-Transfer-Encoding: base64" and write base64 undecoded data directly into the file!
但是在服务器端，PHP 忽略标头“Content-Transfer-Encoding: base64”并将未解码的 base64 数据直接写入文件！
Is there any way to fix it?
有什么办法可以解决吗？
p.s. it is very important to send data using base64
ps使用base64发送数据非常重要
采纳答案by Xavier Combelle
My previous answer was wrong
我之前的回答是错误的
Content-Transfer-Encodingmay appear in the a composite body
Content-Transfer-Encoding可能会出现在复合体中
http://www.ietf.org/rfc/rfc2616.txt
http://www.ietf.org/rfc/rfc2616.txt
There are several consequences of this. The entity-body for composite types MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers).
这有几个后果。复合类型的实体主体可能包含许多主体部分，每个主体部分都有自己的 MIME 和 HTTP 标头（包括 Content-MD5、Content-Transfer-Encoding 和 Content-Encoding 标头）。
回答by mairo
Xavier's answer doesn't sound right. RFC2616 also has this to say (section 3.7):
泽维尔的回答听起来不对。RFC2616 也有这个说法（第 3.7 节）：
In general, HTTP treats a multipart message-body no differently than
any other media type: strictly as payload. The one exception is the
"multipart/byteranges"
通常，HTTP 将多部分消息体视为与
任何其他媒体类型没有区别：严格视为有效负载。一个例外是
“多部分/字节范围”
It seems to me that section 19.4 of RFC2616 is talking about HTTP as a whole, in the sense that it uses a syntax similar to MIME (like headers format), but is notMIME-compliant.
在我看来，RFC2616 的第 19.4 节是在讨论整个 HTTP，因为它使用类似于 MIME 的语法（如标头格式），但不符合 MIME。
Also, there is RFC2388. In section 3, last paragraph, it says:
Each part may be encoded and the "content-transfer-encoding" header
supplied if the value of that part does not conform to the default
encoding.
如果该部分的值不符合默认
编码，则可以对每个部分进行编码并提供“内容传输编码”标头。
Section 4.3elaborates on this:
第 4.3 节对此进行了详细说明：
4.3 Encoding
While the HTTP protocol can transport arbitrary binary data, the default for mail transport is the 7BIT encoding. The value supplied for a part may need to be encoded and the "content-transfer-encoding" header supplied if the value does not conform to the default encoding. [See section 5 of RFC 2046for more details.]
4.3 编码
虽然 HTTP 协议可以传输任意二进制数据，但邮件传输的默认值是 7BIT 编码。如果该值不符合默认编码，则可能需要对为部件提供的值进行编码并提供“内容传输编码”标头。[有关更多详细信息，请参阅RFC 2046 的第 5 节。]
