エンディアン (Endianness) とは、マルチバイトデータをメモリやファイルに格納する際のバイト順序を指します。上位バイトを先に格納するビッグエンディアン (BE) と、下位バイトを先に格納するリトルエンディアン (LE) の 2 種類があります。この用語はジョナサン・スウィフトの小説「ガリヴァー旅行記」に登場する、卵をどちらの端から割るかで争う寓話に由来しています。

具体例で説明すると、16 進数 0x1234 を 2 バイトで格納する場合、ビッグエンディアンでは 12 34 の順に、リトルエンディアンでは 34 12 の順にメモリに配置されます。人間にとってはビッグエンディアンのほうが直感的ですが、加算処理などではリトルエンディアンのほうが効率的な場合があります。

プロセッサごとにエンディアンの採用方針が異なります。Intel の x86/x64 プロセッサはリトルエンディアンを採用しており、2026 年時点のデスクトップ PC やサーバーの大半がこの方式です。一方、ネットワークプロトコル (TCP/IP) はビッグエンディアン (ネットワークバイトオーダー) を標準としています。ARM プロセッサはバイエンディアン (両方対応) で、OS やファームウェアの設定で切り替えられます。Apple Silicon (M1 以降) はリトルエンディアンモードで動作しています。

文字エンコーディングにおいて、エンディアンは UTF-16 と UTF-32 で特に重要です。たとえば「あ」(U+3042) はビッグエンディアンでは 30 42、リトルエンディアンでは 42 30 とバイト列が反転するため、エンディアンの不一致はそのまま文字化けの原因になります。この問題に対応するために BOM (Byte Order Mark, U+FEFF) が使われます。エンディアンを明示せず「UTF-16」としてやり取りする場合、ファイル先頭が FE FF ならビッグエンディアン、FF FE ならリトルエンディアンと判別できます。UTF-32 の BOM は 4 バイトで、ビッグエンディアンが 00 00 FE FF、リトルエンディアンが FF FE 00 00 です。

ここで見落とされやすいのが、UTF-16BE や UTF-16LE のようにエンディアンを明示したラベルを付けた場合の扱いです。Unicode の規定では、この場合 BOM は不要であるだけでなく使ってはならないとされており、先頭に U+FEFF があっても順序の指示ではなく ZWNBSP (ゼロ幅ノーブレークスペース) という実体のある文字として解釈されます。「UTF-16BE の BOM は FE FF」という覚え方は正確ではなく、同じバイト列でも読み取り側に渡すラベル次第で意味が変わる、と理解するのが正しい捉え方です。また UTF-32LE の BOM は先頭 2 バイトが FF FE で UTF-16LE の BOM と一致するため、先頭 2 バイトだけを見る簡易判定は UTF-32LE を UTF-16LE と誤認します。

よくある落とし穴として、異なるエンディアンのシステム間でバイナリデータを交換する際の変換忘れがあります。ネットワークプログラミングでは htons() (host to network short) や ntohl() (network to host long) といった変換関数を使ってバイトオーダーを明示的に変換する必要があります。この変換を怠ると、数値データが正しく解釈されず、デバッグが困難なバグの原因となります。

文字数カウントの観点では、エンディアンは文字のバイト表現に影響しますが、文字数自体は変わりません。ただし、バイト数カウントではエンディアンと BOM の有無を考慮する必要があります。UTF-16 ファイルに BOM が付加されている場合、先頭の 2 バイトはテキスト内容ではなくメタ情報であるため、正確なバイト数を算出する際には BOM を除外して計算するのが適切です。文字数についても、前述のラベルの扱いが影響します。FE FF 30 42 30 44 という 6 バイトを「UTF-16」として読めば「あい」の 2 文字ですが、同じバイト列を UTF-16BE として読むと先頭が ZWNBSP と見なされ 3 文字になります。カウント結果が想定より 1 文字だけ多いときは、BOM がメタ情報として除去されないまま不可視文字として本文に紛れ込んでいる可能性を疑うと原因に近づけます。