C# 网络字节[]到Int64的问题

我正在一个非常旧的系统上从多播流收集二进制信息。我已经转换了它的大部分，但是我在使用高/低DWORD组合时遇到了问题。我写了一个小测试应用程序来解决这个问题。我被告知该值应在30XXX范围内

给我的文件说它被定义为

DWORD ID_HIGH;
DWORD ID_LOW;

到目前为止，我只是在捡垃圾。我尝试过一些小转变和其他一些方法。到目前为止，没有运气。感谢您的帮助

static void Main(string[] args)
        {            
            byte[] data = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF3, 0x04, 0x51};

            Int32 ID_High = IPAddress.NetworkToHostOrder(BitConverter.ToInt32(data, 0));
            Int32 ID_Low = IPAddress.NetworkToHostOrder(BitConverter.ToInt32(data, 4));
            Int64ToInt32 i6;
            i6.Int64Value = 0;
            i6.LeftInt32 = ID_High;
            i6.RightInt32 = ID_Low;


        }

        [StructLayout(LayoutKind.Explicit)]
        struct Int64ToInt32
        {
            [FieldOffset(0)]
            public Int64 Int64Value;
            [FieldOffset(0)]
            public Int32 LeftInt32;
            [FieldOffset(4)]
            public Int32 RightInt32;
        }

了解更多信息。以下是从多播接收到的整个字节[]

byte[] data = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF3, 0x04, 0x51, 0x00, 0x00, 0x00, 0x10, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF3, 0x04, 0x50, 0x00, 0x00, 0x04, 0x7F,
                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x90, 0x3E, 0xE4, 0x62, 0xB8, 0xB1, 0x4D, 0xB0, 0xF1, 0x15, 0x94,
                            0xF1, 0x13, 0x0F, 0x84, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00 };

这是它应该翻译成什么的定义

typedef struct
{
    DWORD AgentID_High; // Agent phoneset login ID high-order 32 bits
    DWORD AgentID_Low; // Agent phoneset login ID low-order 32 bits
    DWORD State;
    DWORD SupervisorID_High; // Supervisor phoneset login ID high-order 32 bits
    DWORD SupervisorID_Low; // Supervisor phoneset login ID low-order 32 bits
    DWORD TimeInState;
    DWORD AnsweringSkillset;
    DWORD DNInTimeInState;
    DWORD DNOutTimeInState;
    BYTE SupervisorUserID[16];
    DWORD PositionID;
    // TM26314
    DWORD NotReadyReasonCode_High;
    DWORD NotReadyReasonCode_Low;
    DWORD DNOutCallNumber_High;
    DWORD DNOutCallNumber_Low;
    DWORD SkillsetCallAnswered;
    DWORD DNInCallAnswered;
    DWORD DNOutCallMade;
    //Q00635846 griffinn MIROS Changes
    DWORD AnsweringApplication;
    DWORD AnsweringCDN_High;
    DWORD AnsweringCDN_Low;
    DWORD AnsweringDNIS_High;
    DWORD AnsweringDNIS_Low;
} NIMultiCastAgentRecord_Rls5; // size = 104 bytes

所有其他DWORD解析都很好，仅使用IPAddress.NetworkToHostOrderBitConverter.ToInt32data，0； 除了这些分裂的词。我个人认为数据似乎不正确，但我需要第二种意见

**最新发展。。据我所知，探员ID是30451。 如果你看十六进制位，它就在十六进制中

byte[] data = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF3, 0x04, 0x51};

这就是我想到的。我觉得我在这里打破了各种规则

string AgentID = BitConverter.ToString(data);
AgentID = AgentID.Replace("-", "").Replace("F", "");

---

你说它的值在30XXX-30000到30999之间

所以在任何情况下，我们都在寻找0x75到0x79范围内的至少一个字节，不管它是16位、32位还是64位大小的整数，也不管它是大端还是小端

---

您发布的所有字节都不在该范围内-因此，这些值中的任何一个都不可能使用普通整数表示30000到30999范围内的值。

按照网络顺序，作为有符号32位整数，ff f3 04 51将为-850863，前面的四个ff值只是64位的符号扩展。假设这是30XXX的意思，那么这还不到30000。此外，i6.LeftInt32应该从ID_Low分配，即从[4]到[7]的低位。IPAddress有一个方法重载，该重载采用64位值。请尝试IPAddress.NetworkToHostOrderBitConverter.ToInt64数据，0`。一旦您的数据符合您的期望，就应该在没有显式布局结构的情况下处理它。这里没有足够的信息告诉您出了什么问题。但是，您提供的数据看起来不像30000到30999之间的任何数字，甚至不像0x30000到0x30fff之间的任何数字。即使我们取最小的字节并使其成为最重要的字节，也会得到一个大于67000000的数字。如果你能说出这些字节到底应该代表什么，那么弄清楚它们是如何编码的就很简单了。没有这些信息，任何人都只能猜测。添加了更多信息，希望这会有所帮助。我同意这些数据根本不适合这些。我不认为它应该以4x 0xFF开始。我已经有一段时间没有处理这类事情了，所以我正在寻求其他的意见。如果我翻转这些位，我会得到一个正确范围内的数字。按位不是，但我为什么要这样做？@Steve:如果我翻转位，我会得到一个正确范围内的数字-你怎么看？将您的数据解释为带符号，它表示-850863 2的补码。否定它会给你带来850863。如果您将这些位视为1的补码，只需翻转这些位，结果是850862。这两个值都不接近30000位小数。你是说你描述的范围是十六进制的吗？如果是这样的话，如果你能在你的问题中说清楚那肯定会好得多。我应该在凌晨1点停止回答。。我只是想在这里找到一些理由。所以我所做的是。。。FF FF FF FF | FF F3 04 51->1111111 1111 x4 | 1111 1111 1111 0011 0000 0100 0101 0001->0000 | 0000 0000 0000 11001111 1011 1010 1110=850862然后向后读取0111 0101 1101 1111=30175。。但这忽略了最后的0011，我昨晚没有注意到。我想是纯粹的机会。只是因为他们发誓他们的数据没有问题而感到沮丧。我也用Wireshark验证了我的字节[]，它始终输出相同的内容。@vSteve所以数据不是按位的，而是按位翻转的？沃特？因此，例如，给定0x59，而不是0x59==0xA6==1010 0110b，然后将字节中的位顺序反转为0110 0101==0x65。那太疯狂了。是的，是的。这一切都归结为一个简单的问题。在解析这些东西时，我是否遗漏了一个步骤，或者数据是FUBAR。

Decimal    Hex big-endian    Hex little-endian
30000           0x75 0x30            0x30 0x75
30999           0x79 0x17            0x17 0x79