数据包偏移量的计算 我想获得相应的位置 这个代码怎么算的？

问题描述

数据包偏移量的计算 我想获得相应的位置 这个代码怎么算的？

示例数据(包括：帧头、包长、数据包内容、CRC 校验、帧尾)：
AA AA AA 00 01 30 30 31 31 31 31 30 32 30 36 30 39 30 30 30 31 47 31 30 32 4C
32 30 36 31 32 30 32 32 35 00 00 01 D6 07 08 11 05 0F 00 04 0B 33 19 00 2A 00 00 00
03 00 53 03 00 66 02 00 68 00 00 00 02 00 61 00 00 00 00 00 00 00 00 00 0C 33 19 00
2A 00 00 00 02 00 67 02 00 54 01 00 68 00 00 00 02 00 4D 00 00 00 00 00 00 00 00 00
1F 33 19 00 2A 00 00 00 02 00 5C 01 00 6C 01 00 55 01 00 56 01 00 46 00 00 00 00 00
00 00 00 00 20 33 19 00 2A 00 00 00 02 00 5F 02 00 50 01 00 5A 01 00 6C 02 00 53 00
00 00 00 00 00 00 00 00 E0 9F EE EE
数据包分解为：
AA AA 2 个字节的时间间隔的帧头
AA 00 数据包内容长度，170 字节
01 数据包类型，实时交通数据包
30 30 31 31 31 31 30 32 30 36 30 39 30 30 30 31 设备身份识别码
47 31 30 32 4C 32 30 36 31 32 30 32 32 35 00 站点编号
00 设备硬件错误码，正常
01 调查内容，调查所有项目（不含预留字段）
D6 07 年份，2006 年

byte[] newBytes = Arrays.copyOf(bytes, bytes.length);
String logMsg=CommUtils2.toHexString(newBytes);//设备状态表中的部分错误信息（因可能超长，应用时可将其置为""）
//拆分数组,查询标识符及长度进行拆分
//注：ArrayUtils.subarray(newBytes, 0,5) 截取下角标从0到4的内容
int splitFlag=0;
int splitNextFlag=0;
//int byteLength=1;
//int byteLengthTemp=newBytes[2]& 0xFF;
//byteLength=byteLengthTemp+2;
//boolean runFlag=true;
while(splitNextFlag<newBytes.length){
try {
splitFlag=splitNextFlag;//每次都更新读取的起始位置

            if(newBytes[splitFlag] != (byte)0xFF){
                throw new RuntimeException("设备"+recEntity.getDeviceId()+"接收数据异常,信息分组首字节不是FF : "+CommUtils2.toHexString(newBytes));

// throw new RuntimeException("接收数据异常,信息分组首字节不是FF：" + logMsg);

            }

            byte recFlag=newBytes[splitFlag+1]; //标识符位
            int byteLengthTemp=newBytes[splitFlag+2]& 0xFF;//车道字节所占长度
            int splitFlagTemp=splitFlag;

            splitNextFlag=splitFlagTemp+byteLengthTemp+4;//读取下条数据起始位置

            switch (recFlag) {
            case 0x20://32
                flowBytes2=ArrayUtils.subarray(newBytes, splitFlag,splitNextFlag);
                System.out.println("中车流量"+CommUtils2.toHexString(flowBytes2));
                break;

            case 0x1B://27
                flowBytes3=ArrayUtils.subarray(newBytes, splitFlag,splitNextFlag);
                System.out.println("长车流量"+CommUtils2.toHexString(flowBytes3));
                break;

        public static String toHexString(byte[] src) {
    if (src == null || src.length <= 0) {
        throw new IllegalArgumentException("[toHexString] this byteArray must not be null or empty");
    }
    StringBuilder stringBuilder = new StringBuilder("");
    for (int i = 0; i < src.length; i++) {
        int v = src[i] & 0xFF;
        String hv = Integer.toHexString(v);
        stringBuilder.append("0x");
        if (hv.length() < 2) {
            stringBuilder.append(0);
        }
        stringBuilder.append(hv.toUpperCase());
    }
    return stringBuilder.toString();
}

解决方案

这里有很多帧同步的00 00 00 00 00 00 00 00 00
每一部分的数据，构成一个单独的数据项
0x20是中车，0x18是大车，至于为什么如此，是协议制定者规定的。

解决方案二：

这个0X20应该是自定义的，它发送数据的时候就定义好了，这个对应的字段，会可能出现这些数据，这每一个数据，0x20， 0x1B 都代表一种类型含义
中车流量， 长车流量

解决方案三：

这里不是说的很清楚了么
帧头、包长、数据包内容、CRC 校验、帧尾
每部分的长度
还有举例
你的问题是什么呢？如果这不是标准的协议，并且你认为有偏差，应该和定协议的人询问。

解决方案四：

这个0X20 怎么算出来的啊？

解决方案五：

用流一个byte或一个int读取，0x20 =32嘛 转换一下就行了

解决方案六：

2 、 、、 、CRC 字节表
/* CRC 高位字节值表*/
static unsigned char auchCRCHi[] = {
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
73
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40
} ;
/* CRC 低位字节值表*/
static char auchCRCLo[] = {
0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4,
0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09,
0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD,
0x1D, 0x1C, 0xDC, 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3,
0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7,
0x37, 0xF5, 0x35, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A,
0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE,
0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26,
0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2,
0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F,
0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB,
0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5,
0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x50, 0x90, 0x91,
0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C,
0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98, 0x88,
0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80,
0x40
}

解决方案七：

先去了解协议，再去分析，那个字节对应什么意思，每个协议都有个开始的标识，你找到这个标识，然后根据协议的字节去看它的意思。

时间： 2024-08-03 11:40:24

数据包偏移量的计算 我想获得相应的位置 这个代码怎么算的？的相关文章

linux网络实现分析(3)——数据包的发送（IP层到链路层）

二层(链路层)数据包发送过程分析         当上层准备好一个包之后,交给链路层,链路层数据包发送主要通过dev_queue_xmit函数处理.数据包的发送可分为两种,一种是正常的传输流程,即通过网卡驱动,另一种是通过软中断(见注3).为了理解方便,首先看一下dev_queue_xmi函数的整体调用关系图.     dev_queue_xmit     本函数用来将带发送的skb加入一个dev的队列(Queue),调用这个函数前必须设置好skb的device和priority,本函数可以在中

《精通Wireshark》—第1章1.4节通过Wireshark进行数据包分析

1.4 通过Wireshark进行数据包分析 数据包分析(也称为数据包嗅探或协议分析)的作用是抓取在网络(以太网或WiFi)传输中的数据包,并且对其中的信息进行解答的过程,其目的在于了解网络中正在发生的情况.数据包分析需要借助像Wireshark这样的协议分析软件来实现,这些软件可以在互联网上进行下载.其中有些软件是免费的,也有一些软件需要付费才能用于商业目的.在本书中,我们会使用Wireshark来进行网络分析.Wireshark是一款开源软件,同时也是互联网上最优秀的免费网络分析软件. 在当

公司系统，录制数据的时候一直出现这个，同一个数据别人不会啊，想请教一下。

问题描述 公司系统,录制数据的时候一直出现这个,同一个数据别人不会啊,想请教一下. 解决方案 有源代码么?有源代码的话贴出你的Page_Load的代码,有参数没有获取,是null 解决方案二: 空指针,,打个断点看看,,,

switch-这个代码对于这个数据包什么意思？它是怎么算出来的？

问题描述 这个代码对于这个数据包什么意思?它是怎么算出来的? int splitFlag=0; int splitNextFlag=0; //int byteLength=1; //int byteLengthTemp=newBytes[2]& 0xFF; //byteLength=byteLengthTemp+2; //boolean runFlag=true; while(splitNextFlag<newBytes.length){ try { splitFlag=splitNextF

数据包 进制的转换-数据包的位置的相应计算

问题描述 数据包的位置的相应计算 示例数据(包括:帧头.包长.数据包内容.CRC 校验.帧尾): AA AA AA 00 01 30 30 31 31 31 31 30 32 30 36 30 39 30 30 30 31 47 31 30 32 4C 32 30 36 31 32 30 32 32 35 00 00 01 D6 07 08 11 05 0F 00 04 0B 33 19 00 2A 00 00 00 03 00 53 03 00 66 02 00 68 00 00 00 02

交通-数据包的位置计算（跟CRC16有关吗？）以及数据包的字节长度

问题描述 数据包的位置计算(跟CRC16有关吗?)以及数据包的字节长度 20C 车 道 数 字节长度 1 设 备 所 处 调 查 断 面 双 向 车道 数 , 为 1 及 2-18 间 的 整型 数 , 其 中 2-18 间 为 " 2"的 整 数 倍 ." 01" 代 表 单 车道 ," 02" 代 表 双 车 道 , 依此 类 推01,02,04,06,08,0A,0C,0E,10,12 这个可以用0x10;但是这个我怎么判断他的标志位 小型

用InternetGetCookieEx抓取完整cookie 但刷新页面会提交两次数据包想获取第二个数据包的cookie

问题描述 用InternetGetCookieEx抓取完整cookie但刷新页面会提交两次数据包想获取第二个数据包的cookie

《Linux防火墙（第4版）》——2.4　过滤传入的数据包

2.4 过滤传入的数据包 外部网卡I/O对中的输入端.输入规则集,对于保护您的站点而言,是更值得注意的.就像前面提到的那样,您能够基于源地址.目的地址.源端口.目的端口.TCP状态标志以及其他标准进行过滤. 您将在后面的章节中了解到所有这些信息. 2.4.1 远程源地址过滤 在数据包层面,唯一确定IP数据包发送者的方式便是数据包报头的源地址.这个事实为源地址欺骗(source address spoofing)提供了可能,发送者将一个并非他/她真实地址的错误地址放在报文的相应源地址域里.该地址可

路由器网络中数据包传输分析

本篇介绍一个基础的知识,关于数据包在路由器中是如何进行传输和交换的,只要明白这点,那么对你配置出一个好的网络环境会有很大的帮助. 一.输入的问题 1.原始套接口可以接收到任何TCP或UDP报文. 2.要想接收到原始套接口,首先要接收的数据包必须有一个完整的.正确的IP头,否则不能通过ip_rcv()中的包头检查和检验和验证. 3.在原始套接口接收的数据包过程中,内核会对接收的IP包进行校验和验证,但不会对IP包以后的任何字段进行检测和验证.如,我们创建原始套接口时,所指定的protocol参数为