特别是接触下位机 或者socket数据流处理，总少不了涉及所谓字节序问题。今天又拿这个出来说事了。有点啰嗦哈

偶然翻到微量氧项目的ModbusRTU 寄存器说明 ，有这么一段说明：
从站地址默认为0x01
字节序：每个寄存器均一个2字节数据 ，下位机发时遵循 先发高位 再发低位。
比如下位机发 0xff00 那么上位机收到的 byte[] readDatas; 为 readDatas={0xff,0x00}
想着先发高位对方收到的ff 00 对的哈 ，仔细一想 我擦 越想越不对 ，在未发送前 0xff00 按照little字节序 ff可是高位噢。对应65280， 你一发送后 变成了{ff,00} 低字节对应低位 别人用little字节序一转换变成 255了 这不扯淡么。但是 但是 但是 这不是我自己写的么 ，当时我就怎么写出这段话来的呢，鬼使神差？不得不说这玩意儿确实个绕 绞人的东西 ，现在这社会 人浮躁的甚至到了都不能静下心来认真理解一段话的程度了。为了刨根问底儿追这些细节我们来调测一下：

首先是字节序说明和测试:

little字节序，即小端字节序 高字节数据在地址或者数组的高位 ，低字节数据在地址或者数组的低位。这也是符合我们正常人思维理解概念的一种字节序 ，且也是大多数编程环境支持的一种默认处理方式。
另一种与之相反是big字节序 我们这里不做说明。

c#中默认是intel架构 的little字节序 所有的字节数据处理也是遵循的。好的我们 首先编写一段简单的不能再简单的代码

1 UInt16 testNum = 0xff00;//65280
2 byte[] btstest = BitConverter.GetBytes(testNum);
3 
4 //byte[] btstest2 = { 0xff, 0x00 };
5 UInt16 testNum2 = BitConverter.ToUInt16(btstest, 0);
6 Console.WriteLine(testNum2.ToString());

都知道"hello" 数组末尾以\0结尾 数组的高索引代表高位 ，那么上面应该是{00,ff}这种看似简单的东西容易把人绞昏。为什么推进little字节序。你想想这边的环境 发送到对方那 对方也接收到一个数组里 ，先发低地址也就是ff  对方越收到越往数组的后面 排    {ff,00}->{ff,00}  这边环境的东西跟对方环境的东西完全一样，这样才符合人惯性思维的预期 是不是这样。

那我们看下到底是不是高位就在高地址

 嗯 确实是的对吧。输出65280完全没问题。

另外一种处理方式的来由

但是看到下面一段代码 ，反向了？

 1 float oxMeasure = float.Parse(textBox1.Text);
 2 //0,0,127,67
 3 //0x43 7f 00 00
 4 //{0x00,0x00 ,0x7f,0x43}
 5 byte[] oxmeasureData = BitConverter.GetBytes(oxMeasure);
 6 
 7 byte[] uploadData = { 0xEE, 0xB5, 0x02, 0x01, 0x04, 0x01, 0x01, 0x01, 0x01, 0xFF, 0xFC, 0xFF, 0xFF };
 8 //高低位反向
 9 uploadData[5] = oxmeasureData[3];
10 uploadData[6] = oxmeasureData[2];
11 uploadData[7] = oxmeasureData[1];
12 uploadData[8] = oxmeasureData[0];
13 //ComDevice.Write(uploadData, 0, uploadData.Length);

如上代码所描述 反向了，先发高位，那么下位机收到的应该是{0x43,0x7f,0x00,0x00}

为什么要这样写呢。

我们代码这里应该是oxmeasureData = {0x00,0x00 ,0x7f,0x43} ，反着发下位机收到 {0x43,0x7f,0x00,0x00 } ，下位机每收到一个字节都加到字符串然后输出调试。

 1 function measureProcess(parid, parData)
 2     local measureHexStr = "";
 3     local measureval = 0.0;
 4     for i = 1, #parData, 1 do
 5         measureHexStr = measureHexStr .. string.format('%02X', parData[i]);
 6     end
 7     --print(measureHexStr.."------");
 8     measureval = hexToFloat(measureHexStr);
 9     if parid == 1 then --通道1
10         globalvar_ch1_measure = measureval;
11     elseif parid == 2 then --通道2
12         globalvar_ch2_measure = measureval;
13     elseif parid == 3 then
14         globalvar_ch3_measure = measureval;
15     elseif parid == 4 then
16         globalvar_ch4_measure = measureval;
17     end
18     
19 end

那么 问题来了，看到输出的字符串没有 ，转过来了，学过c语言都知道， 0x43是字符串数组中的低位，但是这里是当作全字符串来处理的 就像我们平常书写代码一样//"0x43 7f 00 00"，却恰巧可以正确转换，也正是由于这点小小的猫腻 经常导致我们的混乱。

另外晒一下网上抄的一段支持标志ANSI c 也就是所谓，IEEE754的 转换代码 也即标准的c语言float在内存中怎么形式存在的 就怎么形式转换。

 1 function hexToFloat( hexString )
 2     if hexString == nil then
 3         return 0
 4     end
 5     local t = type( hexString )
 6     if t == "string" then
 7         hexString = tonumber(hexString , 16)
 8     end
 9  
10     local hexNums = hexString
11  
12     local sign = math.modf(hexNums/(2^31))
13  
14     local exponent = hexNums % (2^31)
15     exponent = math.modf(exponent/(2^23)) -127
16  
17     local mantissa = hexNums % (2^23)
18  
19     for i=1,23 do
20         mantissa = mantissa / 2
21     end
22     mantissa = 1+mantissa
23 --    print(mantissa)
24     local result = (-1)^sign * mantissa * 2^exponent
25     --保留一位小数
26     result = math.floor(result * 10+ 0.5) / 10;
27     return result
28 end

事情往就是在这样绞来绞去的过程中 不知不觉就被带偏了 ，然后就囫囵吞枣的过。