ネットワーク順序(ビッグ エンディアン) は、デファクト スタンダードのようなものです。ただし、プログラムが主にx86 (リトル エンディアン) で使用される場合は、パフォーマンス上の理由からそれを使い続けることをお勧めします (プロトコルはビッグ エンディアン マシンでも使用できますが、代わりにパフォーマンスへの影響があります)。 ）。
htonl (32 ビット値を変換する) の他に、htons (16 ビット) と bswap_64 (64 ビットの非標準) もあります。
バイナリ形式が必要であるが、詳細の一部を抽象化してシリアライゼーションとデシリアライゼーションを容易にしたい場合は、Protocol BuffersまたはThriftを検討してください。プロトコル バッファは更新可能です (既存のコードを壊すことなく、オプションまたは繰り返し (0 個以上の) フィールドをスキーマに追加できます)。Thriftについてはわかりません。
ただし、時期尚早の最適化を行う前に、解析が本当にボトルネックになっているかどうかを検討してください。ファイルのすべての行を読み取るためにデータベース クエリまたは計算が必要な場合は、パフォーマンスに顕著な影響を与えることなく、より読みやすい形式を使用できる場合があります。
この種のタスクには、適切な選択肢がいくつかあると思います。
ほとんどの場合、私が最初に選択するのはおそらく Sun (現在は Oracle) の XDR でしょう。これは Sun の RPC 実装で使用されているため、かなり長い間かなり厳しくテストされてきました。これはRFC 1832で定義されているため、ドキュメントは広く入手できます。この形式との間の変換方法を知っているライブラリ(ポータブルおよびその他)もあります。オンワイヤー表現は適度にコンパクトで、変換はかなり効率的です。
XDR の潜在的な大きな問題は、データをデコードするためにデータが何を表しているかを知る必要があることです。つまり、送信者と受信者が (たとえば) 構造体の定義に同意していることを (何らかの外部手段によって) 確認する必要があります。受信者が送信内容を（簡単に）理解できるようになる前に、ネットワーク経由で送信します。
完全に自己記述的なストリームを作成する必要がある場合は、ストリーム自体のコンテンツのみに基づいてストリームに含まれるものを誰かが把握できるようにする必要がある場合は、ASN.1 を検討してください。いくつかの点で無愛想で厄介ですが、自己記述型ストリームを生成し、公的に文書化されており、かなり広く使用されています (ただし、ほとんどが限られたドメインで)。エンコードとデコードを実装するライブラリは多数あります。本当に好きな人はいないと思いますが、その機能が必要な場合は、すでに知られ、ある程度受け入れられているという理由だけで、おそらく最初の選択肢です.
このような状況で私が最初に選択するのは ASN.1 です。ASN.1 は、プラットフォームに依存しないだけでなく、任意のプログラミング言語をどちらの側でも使用できる柔軟性を提供するからです。エンディアンの問題を隠してくれるので、心配する必要はありません。一方では Java を使用し、他方では C、C++、または C# を使用できます。また、必要に応じて選択できる複数のエンコード ルールもサポートしています。エンコーディングをできるだけ小さくすることが目標の場合は PER (Packed Encoding Rules)、XML を使用して情報を交換する場合は E-XER (Extended XML Encoding Rules)、または DER (Distingushed Encoding Rules) があります。アプリケーションにデジタル署名または証明書が含まれている場合。ASN.1 はテレフォニーで広く使用されていますが、銀行、自動車、航空、医療機器、およびその他のいくつかの分野でも使用されています。
ASN.1 を無料で試すことができる優れたリソースは、http://asn1-playground.oss.comです。ここでは、既存の ASN.1 仕様で遊んだり、独自の仕様を作成して、さまざまなエンコーディング ルールが生成するものを確認したりできます。
http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-books.htmlから無料でダウンロードできる優れた本がいくつかあります。最初の本のタイトルは「ASN.1 — 異種間通信」です。システム」。