C の大規模な文字配列のバイト オーダー

わかりました、2 つの異なるレベルで行っていることに問題があるようです。ここでの混乱の一部は、ポインタの使用、ポインタが指すオブジェクトのタイプ、およびポインタが指すメモリ内の値のエンコードの解釈に起因するようです.

メモリ内のマルチバイト エンティティのエンコードは、エンディアンと呼ばれるものです。 2 つの一般的なエンコーディングは、リトル エンディアン と呼ばれます。 (LE) と ビッグ エンディアン (なれ)。 LE では、short のような 16 ビット量が最下位バイト (LSB) から最初にエンコードされます。 BE では、最上位バイト (MSB) が最初にエンコードされます。

慣例により、ネットワーク プロトコルは通常、「ネットワーク バイト オーダー」(NBO) と呼ばれるものにエンコードします。これはたまたま BE と同じです。ビッグ エンディアン プラットフォームでメモリ バッファを送受信している場合、変換の問題は発生しません。ただし、コードは BE 規則に依存するプラットフォームになります。 LE プラットフォームと BE プラットフォームの両方で正しく動作する移植可能なコードを書きたい場合は、プラットフォームのエンディアンを想定しないでください。

エンディアンの移植性を達成することは、ntohs() のようなルーチンの目的です ntohl() , htons() 、および htonl() .これらの関数/マクロは、送信側と受信側で必要な変換を行うために特定のプラットフォームで定義されています:

  • htons() - 短い値をホスト注文からネットワーク注文に変換します (送信用)
  • htonl() - long 値をホスト オーダーからネットワーク オーダーに変換します (送信用)
  • ntohs() - ショート値をネットワーク注文からホスト注文に変換します (受信後)
  • ntohl() - long 値をネットワーク オーダーからホスト オーダーに変換します (受信後)

文字にキャストバックするときのメモリへのアクセスに関するコメントは、メモリ内のエンティティの実際の順序には影響しないことを理解してください。つまり、一連のバイトとしてバッファにアクセスすると、BE マシンでも LE マシンでも、実際にメモリにエンコードされた順序でバイトが表示されます。したがって、受信後に NBO エンコードされたバッファを見ている場合は、常に MSB が最初になります。ホストオーダーに戻した後に出力バッファを見ると、BE マシンを使用している場合、バイトオーダーは変更されません。逆に、LE マシンでは、変換されたバッファでバイトがすべて逆になります。

最後に、変換ループで、変数 total バイトを指します。ただし、バッファに shorts としてアクセスしています .ループ ガードは total であってはなりません 、ただし、次のようにする必要があります:

total / sizeof( unsigned short )

short の 2 バイトの性質を考慮する .


それが私の予想です。

送信者が何を送信したかを知る必要があります。つまり、データがバイト (反転する必要がない) であるか、ショートかロング (反転する必要がある) であるかを知る必要があります。

ntohs に関連するチュートリアルの Google 、 htons 、および htons API。


aResponse が何であるかは明確ではありません (文字列? 構造体?) を表します。エンディアンは数値のみに関連し、char には関連しません 秒。また、送信者側で、すべての数値がホストからネットワークのバイト順 (hton*) に変換されていることを確認する必要があります。 ).