现在很多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语言我不了解）。