有关使用HTTP协议传输二进制文件

从第一次接触http协议的时候，不知是怎么回事，形成了这么一个错误的观点，认为http协议是个纯ASCII字符协议。关于HTTP传输ASCII文本内容的过程相信大家都应该容易理解，因为HTTP请求头和响应头都是以ASCII文本方式传输的。而对于HTTP传输二进制流的相关细节，其实没有我想象中的那么复杂，以前学习POP3和SMTP（这两个都是邮件传输协议）的时候，知道他们都只能传输ASCII文本，如果要在邮件中加入附件，如一张图片（图片文件就是二进制文件）那就得先对图片文件转码，即将邮件协议不能传输的二进制数据流转换成可被邮件协议传输的ASCII数据流，其中用的最多的转换就是BASE64编码转换。其实BASE64编码转换也同样适合于HTTP协议，只有你在转换后将HTTP响应头中的Transfer-Encoding设置为base64，当然如果客服端浏览器不支持base64编码那这种转换也是徒劳的，不过幸好现在几乎所有浏览器都支持BASE64(你能用浏览器查看邮件中的附件就是证据)。

不过话又回来，既然HTTP能够直接支持二进制的数据流传输，那我们又何必绕着弯子，走冤枉路呢？

下面我们就准备一个例子，证明http中传输二进制数据。

HTTP协议是基于字符（ASCII）的，当Content-Type项为text/xml，则内容是文本格式；当二进制格式时，Content-Type项为image/gif，就是了。例如，浏览器请求一张图片的数据包信息：

1、请求消息：

2、响应消息：

下面是二进制的数据区

由上可知，http协议中content中可以是纯二进制的。

 

通常上的理解，http协议中请求、相应都是以ascii字符方式传输，如果要传输二进制需要经过BASE64或MIME等编码（因为HTTP协议pop3、smtp邮件协议都是针对文本的，而FTP支持传输二进制数据,即不需要经过编码转换成字符型数据）

如果直接使用http传输二进制(不经过base64编码)，可能会造成一下问题：

 

1) 不知道传输字节的具体长度，如传输的int类型，将int类型之间转为char以后，丢失掉了长度的信息，如数字1234567，本来只有4个字节，但是转化成文本的“1234567”是有7个字节。在int类型的时候固然好办，但是一个数组的时候，经过转化以后，在转化回来就很麻烦了。

2) 对于一些数字，二进制传输Server是没法处理的。如int 1,二进制数据是0x00000001，按字节传输的时候，client能够正常发送，但是libevent收到以后，在抛给libevent_http层是，会把数据截断，前两位0x00是字符串的停止符。