特别是接触下位机 或者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());