現在很多app和伺服器互動，雙方收到對方收據，怎麼才能完整解析訊息，是大家都會遇到的問題。現在來看以下他們的位元組長度差異。
iOS
64位編譯器，對應64位系統,包含機型（iphone5s—同時執行32位應用和64位應用，iphone6, iphone6 plus, iphone6s, iphone6s plus, iphone7, iphone7 plus）
char ：1個位元組（32位的定址空間是2^32, 即32個bit，也就是4個位元組。同理其它編譯器）
char*(即指標變數): 8個位元組
short int : 2個位元組
int： 4個位元組
unsigned int : 4個位元組
float: 4個位元組
double: 8個位元組
long: 8個位元組
long long: 8個位元組
unsigned long: 8個位元組
32位編譯器，對應32位系統,包含主要機型（iphone4，iphone4s, iphone5），iphone4以下機型蘋果商店不需要適配，所以忽略。
char ：1個位元組
char*（即指標變數）: 4個位元組
short int : 2個位元組
int： 4個位元組
unsigned int : 4個位元組
float: 4個位元組
double: 8個位元組
long: 4個位元組
long long: 8個位元組
unsigned long: 4個位元組
java編譯器。
Byte: 1位元組
Short: 2位元組
Int: 4 位元組
Long: 8位元組
Character: 2位元組
Float: 4位元組
Double: 8位元組
c/c++ win32、win64、linux32、linux64中各資料型別佔位元組數

以前遇到訊息id，app定義的為int型別，伺服器（java）定義為long型別，結果導致訊息解析不一致,修改long long型別才解決。
我遇到過訂單id，app定義的為long型別，伺服器（java）定義的為long型別，當應用執行在iphone5s（64位系統）手機上正常，當執行在iphone4s（32位系統）時，發現訂單不識別，接不了單，後來app修改為long long型別才解決。
遇到過[_orderInfo[@”ID”] longValue] 崩潰後修改為 [_orderInfo[@”ID”] longLongValue]才正常，發現app只要是long,int，bool型別都可以用longLongValue來解析，反過來就不一定行。

國內絕大多少企業為了伺服器開發快和具有web前端，都是基於java語言的開發，並且有web展示前端，伺服器大多數部署在阿里雲上。所以瞭解下各個編譯器在各個作業系統平臺上的位元組定義很有必要。
基於Java伺服器的優點：跨平臺容易，基於web開發快，java開發人員多。
基於c++伺服器的有限：執行速度比基於java語言開發的伺服器快20%（從視訊處理上顯然的看出），便於底層協議開發，對web的相容性很差（一般需要中介軟體嵌入基於java的web頁面，c#,.net語言我不瞭解）。