在网络传输中，很多数据都是按字节传递而不是字符串。最近就遇到了这个问题，在刚开始学c语言时都没有问题，可能太久不用了，记录一下
在报中文，用2个字节hex码来表示报文正文长度，什么是hex码呢 就是16进制数
char c = ‘’;
那么c的整数类型就是8(ascii 8对应)
char类型是可以直接转int的 我犯得错误就是用atoi来转整形，aoti转的是字符串类型到整形 比如"123"转为123，而如果"b"用atoi 则转出来的为0
而如果网络报文中用两个字节来表示长度的话，可以用
char *c=....
*(short*)(c);
四字节用
*(int*((c);
单个字节就直接找到长度的那位字符 如*(int*)(c[10])
2019/5/29
在解析报文长度的字节时，直接把报文中代表长度的两个字节拷到 数组中 char c[2]；c[1]为'0',c[2]为8''，在这里我直接用*((short*)(c)) 来把字节转为数字。期望的结果是8，却得出了2048.。。
这里就要从大小端开始说。数组 c在内存中的分布是 00 08，而inter x86 是小端机，short类型为两个字节，读出来的字节序就为0800了，这就是原因。 需要转换一下字节序即可。
下面是几个转换的方法
对于字数据（16位）：
#define BigtoLittle16(A) (( ((uint16)(A) & 0xff00) >> 8) |
(( (uint16)(A) & 0x00ff) << 8))
对于双字数据（32位）：
#define BigtoLittle32(A) ((( (uint32)(A) & 0xff000000) >> 24) |
(( (uint32)(A) & 0x00ff0000) >> 8) |
(( (uint32)(A) & 0x0000ff00) << 8) |
(( (uint32)(A) & 0x000000ff) << 24))
延伸出来的问题是，为什么数组没有大小端这一说法呢？ 猜测应该是数组内存经过管理不用大小端转换
2019/6/12 更新 浮点数也没有大小端之分，其内存结构应该遵循IEEE制定的规范。
下面为一篇浮点数在内存中分布的讲解
http://www.ruanyifeng.com/blog/2010/06/ieee_floating-point_representation.html
2019/6/13更新 今天又被现实上了一课。。。
发现报文中传输的数据，是这样子的
这是wireshark抓的包，里面是hex即16进制字符，对方给的数据在16进制下显示为19060310，而实际的十进制下也是19060310。。。这种写法真是挺少见的
处理的方法只能一个字节一个字节处理了，先处理每个字节的高4位，保存一下，再处理低四位(每个16进制的高低四位分开看其实就等于它的十进制数据，说不太明白。。。) 查了一下 就是 hex转string
char str_hex[] = "x19"; char pp = str_hex[0] >> 4; char pppp = str_hex[0] & 0x0F; char endppp = pp * 10 + pppp;
思考了一下 发现这种写法可以节约空间提升传输效率，如果12这个数字通过转换成字符串的类型发送，则要耗费2个字节，而如果转换为16进制字节的表示形式，只需要一个字节即可。缺点就是转换繁琐，容易出错
#include <iostream> #include <stream> #include <sstream>
//deep为s长度减1
//2019/6/27更新 修改将无符号字节解析为有符号数从而出现负数的情况
static int hex2d(string s, int deep)
{
if (s.empty())
return 0;
//每次只解析一个字节
unsigned char high4 = (s[0] >> 4) &0x0F;
unsigned char low4 = s[0] & 0x0F;
unsigned char ch_ret = high4 * 10 + low4;
int n = 0;
n = pow(100, deep);
return ch_ret*n + hex2d(s.substr(1), deep - 1);
}
使用方法 hex2d(str,str.size()-1)
另一种方法
https://blog.csdn.net/sunflover454/article/details/51219472