問題タブ [endianness]

次の種類のエンディアンの違いは何ですか?

• バイト (8b) 不変のビッグ エンディアンとリトル エンディアン
• ハーフワード (16b) 不変のビッグエンディアンとリトルエンディアン
• 単語 (32b) 不変のビッグ エンディアンとリトル エンディアン
• ダブルワード (64b) 不変のビッグエンディアンとリトルエンディアン

他のタイプ/バリエーションはありますか?

.NET でリトル エンディアンまたはビッグ エンディアンのいずれかでエンコードされたバイナリ ファイルがある場合、それを読み書きする最良の方法は何ですか?

.NET フレームワークでは、デフォルトとしてリトル エンディアンを使用する BinaryWritters / BinaryReaders しか見つけられなかったので、私のアプローチは、ビッグ エンディアンでデータを読み書きするために独自の BinaryReader / BinaryWritter を実装することでしたが、より良いアプローチがあるかどうか疑問に思います.

MacからIntelチップへの変更は、クロスプラットフォームのデータ配布用のバイナリリソースの数値を少し調整することで完了したことを意味しますか？

それがこの問題の最後ですか、それとも私が知らない他のプラットフォームがありますか？

C++ でビッグ エンディアン値とリトル エンディアン値を変換するにはどうすればよいですか?

わかりやすくするために、バイナリ データ (倍精度浮動小数点値と 32 ビットおよび 64 ビット整数) をある CPU アーキテクチャから別の CPU アーキテクチャに変換する必要があります。これにはネットワーキングは含まれないため、ntoh() や同様の関数はここでは機能しません。

注：私が受け入れた答えは、私が対象としているコンパイラに直接適用されます（これが私が選んだ理由です）。ただし、ここには他にも非常に優れた、より移植性の高い回答があります。

64ビットレジスタの下位32ビットサブレジスタにBSWAPを使用する方法の答えを探していました。たとえば、 RAXレジスタ内にあり、単一の命令で0x0123456789abcdef変更したい（パフォーマンスのため）。0x01234567efcdab89

だから私は次のインライン関数を試しました：

その結果は でした0x00000000efcdab89。コンパイラがこのように動作する理由がわかりません。誰かが効率的な解決策を知っていますか?

zlib API を使用して VB6 で作成された一部のデータを解凍しようとしています。

これは qUncompress 関数で可能であると読みました: http://doc.trolltech.com/4.4/qbytearray.html#qUncompress

readRawBytes を介して QDataStream からデータを char 配列に読み込んだ後、解凍のために QByteArray に変換しました。圧縮された長さと予想される解凍された長さがありますが、qUncompress から何も返されません。

ただし、予期される解凍された長さをビッグエンディアン形式で先頭に追加する必要があります。誰かがこれを行い、例を持っていますか?

32ビットのunsignedintに格納されている値を取得し、それを4つの文字に入れてから、これらの各文字の整数値を文字列に格納したいと思います。

最初の部分は次のようになると思います。

UDP/IP 経由で制御できるハードウェアのドキュメントで、次のフラグメントを見つけました。

この通信プロトコルでは、DWORD は 4 バイトのデータ、WORD は 2 バイトのデータ、BYTE は 1 バイトのデータです。格納形式はリトル エンディアンです。つまり、4 バイト (32 ビット) のデータは、d7-d0、d15-d8、d23-d16、d31-d24 として格納されます。2 バイト (16 ビット) のデータは、d7-d0 、d15-d8 として格納されます。

これが C# にどのように変換されるのか疑問に思っています。送信する前にデータを変換する必要がありますか? たとえば、32 ビット整数または 4 文字の文字列を送信したい場合は?

私が書いたオープンソースプログラムでは、ファイルから（別のプログラムによって書かれた）バイナリデータを読み取り、int、double、およびその他のさまざまなデータ型を出力しています。課題の1つは、両方のエンドネスの32ビットおよび64ビットマシンで実行する必要があることです。つまり、かなりの低レベルのビットをいじる必要があります。私は型のパンニングと厳密なエイリアシングについて（非常に）少し知っているので、正しい方法で物事を行っていることを確認したいと思います。

基本的に、char*からさまざまなサイズのintに変換するのは簡単です。

そして、必要に応じて次のようなバイト順序を交換するためのサポート関数のキャストがあります。

実行時に、プログラムはマシンのエンディアンを検出し、上記のいずれかを関数ポインターに割り当てます。

さて、char *をdoubleにキャストしようとすると、トリッキーな部分が発生します。次のようにエンディアンスワッピングコードを再利用したいと思います。

ただし、一部のコンパイラは、「int64todouble.i」割り当てを最適化してプログラムを中断する可能性があります。このプログラムはパフォーマンスのために最適化されたままでなければならず、char *を直接doubleにキャストするための並列変換セットを記述したくないことを考慮しながら、これを行うためのより安全な方法はありますか？駄洒落の結合方法が安全である場合、それを使用するためにsnativeint64_tのような関数を書き直す必要がありますか？

変換関数がmemcpyを使用するように書き直されたため、SteveJessopの回答を使用することになりました。

私の元のコードとまったく同じアセンブラーにコンパイルされました：

2つのうち、memcpyバージョンは、私がやろうとしていることをより明確に表現しており、最も単純なコンパイラーでも機能するはずです。

アダム、あなたの答えも素晴らしかったし、私はそれから多くを学びました。投稿してくれてありがとう！

テンプレート化された低レベルのシリアル化コードがいくつかあり、コンパイル時にシステムのエンディアンを明らかに知る必要があります（テンプレートはシステムのエンディアンに基づいて特殊化されているため）。

現在、いくつかのプラットフォーム定義を含むヘッダーがありますが、テンプレート化されたテスト（static_assertやboost_ifなど）を使用してエンディアンについてアサーションを作成する必要があります。私のコードである理由は、さまざまなマシン、多くの専門ベンダー、そしておそらく2008年には存在しないデバイスでコンパイルして実行する必要があるため、そのヘッダー年に何を入れる必要があるかを実際に推測することはできません道を下って。また、コードベースの予想寿命は約10年です。だから私は永遠にコードに従うことはできません。

うまくいけば、これで私の状況が明らかになります。

では、ベンダー固有の定義に依存せずにエンディアンを判断できるコンパイル時テストを知っている人はいますか？