ftpascbin区别总结

bin 对于文件把所有字节传输过去，不进行转化，适用于所有类型
asc 传输文本字符文件，对于换行符自动转化为目的操作系统需要的格式

unix中的换行符为'/n',windows中的换行符为'/r''/n'两个字符
举例：
对于windows中的文件，用'/r''/n'结尾的，用asc方式，到unix上就变成了'/n',用bin方式就有多余的'/r'，
即所显示的^M。
对于windows中的文件，用'/n'结尾的，用asc方式的还是为'/n',用bin方式的还是为'/n'，文件大小不变。
对于unix中的一个文件，用'/n'结尾的，用asc方式ftp到windows机器，用ue查看其字节，其中'/n'变成了
'/r''/n'即 0D 0A 每一行会增加1个字节0D；用bin方式ftp到windows机器，则用ue查看，如果不转化为dos方式，则只有0A一个字符，
也就是只有'/n'，如果转化为dos方式，出现了2个字符，效果跟asc传输一样，不管用哪种方式查看，文件本身的字节数不变，只是显示不同
同理对于unix中一个文件，用'/r''/n'结尾的，在unix中用vim显示就会有^M即是多余的'/r',用asc方式，则在
windows中变成了'/r''/r''/n',如果用dos方式打开就只显示'/r''/n',否则就显示'/r''/r''/n'即 0D 0D 0A，在每行
结尾多了一个所谓的"空格"  ；用bin方式，则在windows中打开不询问是否用dos方式打开，因为已经是'/r''/n'。

通过以上实验，结果是很明显了，但是为什么在unix，人们在写文本文件时候，用'/r''/n'呢(如果用'/n'，应该也一点问题也没有的阿)，
而且也就显示的时候有^M的字符，一点不影响处理，难道以行读入的，自动把'/r''/n'也处理了？(反而用asc下载到windows机器再解析
就抱错，因为此时为'/r''/r''/n'了，以行读入会出错，误认为两行，用bin方式就没问题)