标题不知道该怎么写了。
最近调试AGPS，嵌入式设备需要从FTP服务器上下载星历数据，星历数据是二进制数据。嵌入式设备下载完数据后和原始数据对比，发现数据量变大了（但是通过pc端的FTP软件下载下来的数据和服务器上的是一致的），对比数据发现，凡是有0x0A出现的地方，前边都多出了0x0D。是不是感觉很眼熟，这两个16进制数正式回车换行啊。瞬间想到了linux系统和windos系统回车换行的区别（猜测ftp服务器是linux环境，后得到确认）。但是这是如何造成的呢，是在哪里改变的呢？去网上搜索答案，看到一篇博文（http://www.xuebuyuan.com/2143934.html）内容如下：
FTP有两种传输模式：BINARY和ASCII
BINARY模式
复制时保留文件的位序，逐位拷贝原始文件而不管内容——即使对目的机器操作系统来说该文件是没意义的。
ASCII模式
复制时候会进行调整，主要体现为对不同操作系统的回车/换行/结束符等进行转译。
比如，回车符号在Unix下是
(0A)，Windows下是
(0D0A)，Mac下是
(0D)。当在一个Windows操作系统上用ASCII方式从Unix服务器上下载文件时——无论是文本文件还是二进制文件——都会进行检测和转换：每检测到一个0A，则认为是回车符号，自动插入0D形成Windows下的回车符。显然，如果下载的是文本文件，这种转换是很有用的——我们能在Windows下看到分行后的文本，否则我们看到的是中间夹杂着小黑方块的不换行的一堆文字；然而如果下载的是二进制文件（比如exe或rar），这种转换无异于画蛇添足，破坏了整个文件。
因此，如果服务器和客户端的OS不相同，对于ASCII文件（文本文件）采用ASCII模式下载，对于非文本文件采用BINARY模式下载；如果两端OS相同，两种方式具有同样效果（-_-MS用户太多了，so我们平时都不用注意这些...）。
找到答案了，接着做实验验证一下：windos下使用cmd通过命令行链接ftp服务器，查看服务器上文件大小为3291字节，直接下载，提示使用文本模式传输数据（默认），收到3306字节；配置使用二进制模式传输，收到3291字节，如下图：
另外这也说明，ftp客户端软件在下载文件的时候会自动匹配文件格式或者默认就是BINARY模式，所以下载下来的文件和服务器文件是保持一致的。cmd命令下载默认是ASCII模式，如果需要下载二进制文件需要手动切换到BINARY模式。