公司的項目開發(fā)在linux下進(jìn)行編譯（Ubuntu16.04）吝镣，但是需要在windows中進(jìn)行更新，所以需要進(jìn)行文件的傳輸昆庇，為了熟悉socket的操作末贾，自己寫的socket程序
由于參考的是網(wǎng)上的程序，基本思路就是整吆，首先發(fā)送一次數(shù)據(jù)拱撵，（一個buf就可以傳完），包含文件名和文件大小表蝙，使用
struct.calcsize('128sl')
計算大小拴测，然后使用
struct.pack()
進(jìn)行打包，發(fā)送之后開始發(fā)送文件數(shù)據(jù)
細(xì)節(jié)將來再說（其實也沒啥細(xì)節(jié)了）府蛇，反正測試的效果就是
- 當(dāng)服務(wù)器和客戶端都在windows平臺的時候集索，文件傳輸沒有問題；
- 當(dāng)服務(wù)器和客戶端都在linux平臺的時候汇跨，文件傳輸也是沒有問題的务荆；
- 服務(wù)器在linux，客戶端在windows穷遂，文件傳完損壞函匕；
- 服務(wù)器在windows，客戶端在linux塞颁，文件傳完損壞浦箱；
但即使文件損壞，大小是一樣的
糾結(jié)了半天不知道是為什么祠锣，以為是字節(jié)序之類的問題酷窥，后來突發(fā)奇想用hex查看器（npp的hex viewer插件）看了一下，發(fā)現(xiàn)接收到的文件開頭莫名有4個空字節(jié)伴网，后面與原文件又是一樣的蓬推，相應(yīng)的，最后的4個字節(jié)不見了澡腾，想來想去沸伏，考慮到可能是前面發(fā)送的文件信息的問題，于是嘗試用
len()
獲取了一下發(fā)送的文件信息的長度动分，發(fā)現(xiàn)竟然不一樣Ｒ阍恪！
明明都是用相同的128sl進(jìn)行的打包澜公，結(jié)果竟然是不同的姆另，于是進(jìn)行測試，發(fā)現(xiàn)
測試結(jié)果.PNG
l的長度是不一樣的，這太糟心了……
后來的實現(xiàn)方式是使用128si迹辐，一段時間是能用了蝶防，但是后來又出現(xiàn)了問題，具體原因我還沒找到明吩，找到了再來更新~~
