传输协议是TCP；
服务器建在linux上，window和linux各开发一个客户端。
但linux的客户端与服务器传输文件时，100M的文件传输都没有问题；
当window的客户端与服务器传输文件时，1M左右的文件就会有时出错有时错，而且文件越大越容易出错。


传输流程：1：客户端发生文件名和文件大小到服务器；
  2：服务器接受文件名和大小
  3：客户端发生1024bytes连续发生，最后发送不足1024bytes的内容
  4：服务器不停地接受，知道大小等于文件的大小。

1:小弟曾传输一个内容全为1的文件，客户端send(client_socket,buffer,1024,0)内容是1
   可从服务器端recv(new_server_socket,buffer,1024,0);读取文件是发现内容有时是1有时不是1
   疑问：1.1这说明是不是传输过程中出错了？可我用的是TCP，可靠传输不该有错啊？而且用linux客户端传输也没问题啊
 1.2 如果是传输出错，那我改怎么保证传输正确啊？

2.小弟传输和接受buffer时，char buffer是1024，但是char buffer[1023]都没有设为'';
问题不会出现在这里吧？ 我在recv(new_server_socket,buffer,1024,0)和send(client_socket,buffer,1024,0)，长度都是1024
这和有没有赋值''没有关系吧？

哦，我理解错了，我还以为你用的FTP协议呢。
你检查一下recv()的返回值，单次recv()调用不一定能获取所要求长度的数据的

对于1，这个我觉得最大的可能，还是你代码出现的问题。实在不行你在你的windows端装一个sniffer，看看，到底发出去的是什么。
对于2，和''没有关系。对于recv来说它是接收数据流，不是字符串流。不过你需要知道，收下来的buffer不能当作字符串来处理，比如一些字符串处理函数，都不能用。

2. 这个与window是ascii编码，而linux是UTF-8编码有么有关系


有关系，UTF-8文件前面有额外的标志字段

传输的时候虽然UTF-8不用考虑字节序的问题。但是开头字节这个东西却是所有的传输都需要考虑。决定了后面程序是怎么处理的。

开头字节           编码方式
FEFF             big-endian
FFFE             little-endian
EFBBBF           UTF-8

是否与二进制传输有关系？