2

可能な限り最小のバイト数を使用して、数値をバイトと同等の形式で格納しています。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);

私の質問は、システムのエンディアン性に気を配る必要がありますか、それとも CLR は関係なくこのリトルエンディアン形式を使用するだけですか? バイト配列が逆の順序で出力されるかどうかをテストするための BigEndian システムはありません (取得方法もわかりません)。

4

2 に答える 2

2

はい、ドキュメンテーションによると、心配する必要があります。アーキテクチャが目的のエンディアンでない場合にバイトを逆にする例があります。

どこで BigEndian システムを入手するかについては、ARM ベースのプロセッサはビッグ エンディアンだと思いますが、私はこれをテストしていません。たとえば、Win RT デバイスまたは電話で実行している場合は、異なる動作が発生する可能性があります。

于 2014-09-25T09:52:32.440 に答える
2

それは、データで何をしているかに完全に依存します。移植可能な永続性のためにディスクに書き込む場合は、はい...おそらくエンディアンが気になります。後で同じプロセス (または同じマシン上) で再作成するためにそれを使用する場合はint、おそらくそれほど重要ではありません。

ただし、エンディアンについて心配する必要がある場合、通常はまったくそれを達成しません。個人BitConverter 的には、バイト マスキングとシフトを使用したくなるでしょう。その場合、エンディアンを知る必要さえありません。どのシステムでも同じように機能します。また、配列とオフセットを受け入れるのではなく、バイト配列を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);
于 2014-09-25T09:49:16.667 に答える