将字节数组的字节交换为长整型 [英] Byte swap of a byte array into a long long

问题描述

我有一个程序，我只需将一个字节数组复制到一个long long数组。总共有20个字节，所以我只需要一个很长的长3.我把字节复制到一个长的原因是为了使它在64位系统上可移植。

I have a program where i simply copy a byte array into a long long array. There are a total of 20 bytes and so I just needed a long long of 3. The reason I copied the bytes into a long long was to make it portable on 64bit systems.

我只需要现在的字节交换，然后填充该数组，使进入它的值被颠倒。

I just need to now byte swap before I populate that array such that the values that go into it go reversed.

有一个byteswap.h，它有_int64 bswap_64（_int64）函数，我想我可以使用。我希望一些帮助使用该函数给出我的long long数组。我只是简单地传递长long的名字，读出来另一个长的长阵列？
我使用c ++不是.net或c＃

there is a byteswap.h which has _int64 bswap_64(_int64) function that i think i can use. I was hoping for some help with the usage of that function given my long long array. would i just simply pass in the name of the long long and read it out into another long long array? I am using c++ not .net or c#

更新：
清楚有问题我仍然困惑。例如，工作与字节数组，刚刚恰巧填充了160位十六进制字符串，然后必须以十进制形式输出使我想到的情况下，如果我只是做一个简单的赋值一个长（4字节）数组我的担忧会结束。然后我发现，这个代码将ahve运行在64位太阳盒。然后我认为，由于数据从一个env到另一个的大小可以改变只是一个简单的赋值不会削减它。这使我想到只使用一个长的长，只是使代码排序免疫大小问题。然而，然后，我读到关于字节序，如何64位读取MSB vs 32位，这是LSB。所以，拿我的数据，扭转它，它存储在我的长期，因为MSB是唯一的解决方案。 ofc，有关于4个额外字节的情况，在这种情况下并不重要，我只是将采取十进制输出和显示任何随机六位数字我选择。但是，编程，我想最好只是工作4字节长，而不是处理这整个浪费的4字节问题。

update: clearly there are issues i am still confused about. for example, workng with byte arrays that just happen to be populated with 160 bit hex string which then has to be outputed in decimal form made me think about the case where if i just do a simple assignment to a long (4 byte) array my worries would be over. Then i found out that this code would ahve to run on a 64bit sun box. Then I thought that since the sizes of data from one env to another can change just a simple assignment would not cut it. this made me think about just using a long long to just make the code sort of immune to that size issue. however, then i read about endianess and how 64bit reads MSB vs 32bit which is LSB. So, taking my data and reversing it such that it is stored in my long long as MSB was the only solution that came to mind. ofc, there is the case about the 4 extra bytes which in this case does not matter and i simply will take the decimal output and display any random six digits i choose. However programatically, i guess it would be better to just work with 4 byte longs and not deal with that whole wasted 4 byte issue.

推荐答案

在这个和你之前的问题之间，这里似乎有几个基本的混乱：

Between this and your previous questions, it sounds like there are several fundamental confusions here:

1. 如果你的程序要在64位机器上运行，听起来你应该在64位机器上编译和单元测试。在32位机器上运行单元测试可以让您确信程序在该环境中是正确的，但不一定意味着代码对于64位环境是正确的。

1. If your program is going to be run on a 64-bit machine, it sounds like you should compile and unit-test it on a 64-bit machine. Running unit tests on a 32-bit machine can give you confidence the program is correct in that environment, but doesn't necessarily mean the code is correct for a 64-bit environment.

您似乎对32位和64位架构如何与字节序相关感到困惑。 32位机器不总是小端，64位机器不总是大端。

You seem to be confused about how 32- and 64-bit architectures relate to endianness. 32-bit machines are not always little-endian, and 64-bit machines are not always big-endian. They are two separate concepts and can vary independently.

字节序只适用于由多个字节组成的单个值;例如，整数305,419,896（0x12345678）需要4个字节来表示，或者UTF-16字符（通常）需要2个字节来表示。对于这些，存储顺序很重要，因为字节被解释为单个单元。听起来像你正在使用的是一个原始字节序列（如校验和或散列）。像这样的值，其中多个字节不是以组解释，不受处理器的字节顺序的影响。在你的情况下，将字节数组转换为 long long * 实际上会创建潜在的端序问题（在小端体系结构上，

Endianness only matters for single values consisting of multiple bytes; for example, the integer 305,419,896 (0x12345678) requires 4 bytes to represent, or a UTF-16 character (usually) requires 2 bytes to represent. For these, the order of storage matters because the bytes are interpreted as a single unit. It sounds like what you are working with is a sequence of raw bytes (like a checksum or hash). Values like this, where multiple bytes are not interpreted in groups, are not affected by the endianness of the processor. In your case, casting the byte array to a long long * actually creates a potential endianness problem (on a little-endian architecture, your bytes will now be interpreted in the opposite order), not the other way around.

字节序也没关系，除非小端字节和大字节序版本您的程序实际上必须相互进行 通信。例如，如果小端程序在没有交换的情况下写入包含多字节整数的文件，并且大端程序读取它，则大端程序可能会错误地解释数据。听起来像你认为你的代码在小端平台上工作会突然打破一个大端平台，即使两个从来没有交换数据。

Endianness also doesn't matter unless the little-endian and big-endian versions of your program actually have to communicate with each other. For example, if the little-endian program writes a file containing multi-byte integers without swapping and the big-endian program reads it in, the big-endian program will probably misinterpret the data. It sounds like you think your code that works on a little-endian platform will suddenly break on a big-endian platform even if the two never exchange data. You generally don't need to be worried about the endianness of the architecture if the two versions don't need to talk to each other.

另一点是，如果两个版本不需要互相交流，那么你通常不需要担心架构的字节顺序。混乱（也许有点蹒跚）。一个字节不存储十六进制值相对于十进制值，它存储一个整数。十进制和十六进制只是表示（打印）特定整数值的两种不同方式。

Another point of confusion (perhaps a bit pedantic). A byte does not store a "hex value" versus a "decimal value," it stores an integer. Decimal and hexadecimal are just two different ways of representing (printing) a particular integer value. It's all binary in the computer's memory anyway, hexadecimal is just an easy conversion to and from binary and decimal is convenient to our brains since we have ten fingers.

$ b这是一个二进制的十进制数，十进制和十进制是方便的我们的大脑，因为我们有十个手指。
$ b

假设你要做的是将数组的每个字节的值打印成十进制，你可以这样做：

Assuming what you're trying to do is print the value of each byte of the array as decimal, you could do this:

unsigned char bytes[] = {0x12, 0x34, 0x56, 0x78};
for (int i = 0; i < sizeof(bytes) / sizeof(unsigned char); ++i)
{
  printf("%u ", (unsigned int)bytes[i]);
}
printf("\n");

输出应该是：

18 52 86 120

18 52 86 120

这篇关于将字节数组的字节交换为长整型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！