标签:table short images lsb 数据 二进制 lin java语言 协议
ARPG项目的需求:需要将现有的服务器从C++的编写平台换为java语言。
在对需求进行分析的过程中,发现几点需要研究实现的问题
综上所述,工作任务有两点:
在几乎所有的机器上,多字节对象都被存储为连续的字节序列。例如在C语言中,一个类型为int的变量x地址为0x100,那么其对应地址表达式&x的值为0x100。且x的四个字节将被存储在存储器的0x100, 0x101, 0x102, 0x103位置。[1]
而存储地址内的排列则有两个通用规则。一个多位的整数将按照其存储地址的最低或最高字节排列。如果最低有效位在最高有效位的前面,则称小端序;反之则称大端序。在网络应用中,字节序是一个必须被考虑的因素,因为不同机器类型可能采用不同标准的字节序,所以均按照网络标准转化。
例如假设上述变量x类型为int,位于地址0x100处,它的十六进制为0x01234567,地址范围为0x100~0x103字节,其内部排列顺序依赖于机器的类型。大端法从首位开始将是:0x100: 01, 0x101: 23,..。而小端法将是:0x100: 67, 0x101: 45,..。
大端序(英:big-endian)或称大尾序。
数据以8bit为单位:
地址增长方向 → |
|
|
|
|
|
... |
0x0A |
0x0B |
0x0C |
0x0D |
... |
示例中,最高位字节是0x0A 存储在最低的内存地址处。下一个字节0x0B存在后面的地址处。正类似于十六进制字节从左到右的阅读顺序。
数据以16bit为单位:
地址增长方向 → |
|
|
|
|
|
|
... |
0x0A0B |
0x0C0D |
... |
|
|
|
最高的16bit单元0x0A0B存储在低位。
数据以8bit为单位:
地址增长方向 → |
|
|
|
|
|
... |
0x0D |
0x0C |
0x0B |
0x0A |
... |
最低位字节是0x0D 存储在最低的内存地址处。后面字节依次存在后面的地址处。
数据以16bit为单位:
地址增长方向 → |
|
|
|
|
|
|
... |
0x0C0D |
0x0A0B |
... |
|
|
|
最低的16bit单元0x0D0C存储在低位。
当更改地址的增长方向,使之由右至左时,表格更具有可阅读性。
← 地址增长方向 |
|
|
|
|
|
... |
0x0A |
0x0B |
0x0C |
0x0D |
... |
最低有效位(LSB)是0x0D 存储在最低的内存地址处。后面字节依次存在后面的地址处。
← 地址增长方向 |
|
|
|
|
|
|
... |
0x0A0B |
0x0C0D |
... |
|
|
|
最低的16bit单元0x0C0D存储在低位。
本部分具体内容详见https://zh.wikipedia.org/wiki/%E5%AD%97%E8%8A%82%E5%BA%8F
所以在PJIO中对报文对象进行传输之前和接收报文之后 都会对报文的BYTE数组进行反转,以兼容c#的字节序,这也是对java的输入输出流进行重构的主要目的;
例如 ushort>>short;
1,这个项目主要是遇到一个问题,java 不能在同一个文件里 生成多个公共类
还有关于驼峰式命名法的 语言规范与C#不同。C#函数首字母大写,比如a.ReadInt16();
Java中的方法(函数)首字母要小写即 a.readInt16();
而java 则不允许,如果非要实现:结果很不令人满意
所以枚举统一转换成仅含有常量的公共类
如上图
暂时未解决的问题:
java在读取c#传输过来的报文的时候 后面会有两个字节的0;
标签:table short images lsb 数据 二进制 lin java语言 协议
原文地址:http://www.cnblogs.com/hellohuan/p/6068519.html