Question

我使用尽可能少的字节数以字节等效格式存储数字。在65535到16777215的范围内，BitConverter给了我一个4字节的数组，但我想只存储3个字节。

对于下面的代码，我的数组是[0] 254，[1] 255，[2] 255，[3] 0，所以我可以输出字节[3]。这是在Core i7 proc上。在我的生产代码中，在数组复制之前，我正在检查BitConverter.IsLittleEndian以确定我可以删除最后一个字节。

int i = 16777214;
byte[] bytesTemp = BitConverter.GetBytes(i);

byte[] value = null;
if (BitConverter.IsLittleEndian) 
    Array.Copy(bytesTemp, 0, value, 0, 3);

我的问题是 - 我是否需要关注系统的Endian-ness，或者CLR是否只使用这种LittleEndian格式？我没有BigEndian系统（甚至不知道我是怎么得到的）来测试我的字节数组是否以相反的顺序出现。

Answer 1

这完全取决于您对数据的处理方式。如果你打算将它写入磁盘以实现可移植的持久性，那么是的......我可能会关心字节序。如果您打算在同一个过程中（或在同一台机器上）稍后使用它来重新创建int，那么它可能并不重要。

但是，当我做需要担心字节序时，我通常不会BitConverter 完成 - 个人，我＆＃ 39; d被诱惑使用字节屏蔽和移位;那么你甚至不需要知道字节序 - 它在任何系统上的工作方式都是一样的。它还避免了BitConverter 返回字节数组而不是接受数组和偏移量的令人讨厌的糟糕设计决策。

例如：

byte[] buffer = ...

// write little-endian
buffer[offset++] = (byte)(i & 0xFF);
buffer[offset++] = (byte)((i >> 8) & 0xFF);
buffer[offset++] = (byte)((i >> 16) & 0xFF);
buffer[offset++] = (byte)((i >> 24) & 0xFF);

Answer 2

是的，根据documentation，您需要关注。他们有一个例子，如果架构不是所需的字节顺序，它们会反转字节。

至于在哪里获得BigEndian系统，我认为基于ARM的处理器是大端的，尽管我还没有测试过。因此，例如，如果您在Win RT设备或手机上运行，您可能会遇到不同的行为。

BitConverter.IsLittleEndian = false时的字节顺序

2 个答案: