要約

  • RFC 1013が記したX11接続では、最初の一バイトが順序を告げる。八進数102の大文字Bは上位バイトが先、八進数154の小文字lは下位バイトが先を意味し、通常の16ビット・32ビットの値はクライアントの選択に従う。
  • 画像のビットマップとピクスマップはサーバーが指定する形式に従う。通常の数値は必要ならサーバーが入れ替え、画像はクライアントがサーバーの指定に合わせてバイトを整える。

あるワークステーションのアプリが、別の機械につながった画面に窓を開きたい。幅、高さ、資源の番号、描画の命令を送る。二台の機械が複数バイトの数値を逆向きに記憶していれば、同じバイト列が別の幅に見えてしまう。線は数字を運ぶが、どちら側から読むかは教えてくれない。X11は会話の最初の一字で、その読み方を先に決めた。

1987年6月のRFC 1013は、Xプロトコル第11版のアルファ更新を記録している。遠隔のクライアントは信頼できるバイトストリームを利用でき、TCPでは表示番号Nのサーバーが6000+N番のポートで接続を受ける。最初のバイトは八進数で102または154。ASCIIのBと小文字lに当たり、前者は上位バイトを先に、後者は下位バイトを先に置く。数字に見える値だが、文書の表記は八進数だ。ここを十進数として読むと出だしから話がずれる。

通常のプロトコル項目ではクライアントが順序を選ぶ。16ビットと32ビットの値について、サーバーは必要に応じてバイトを入れ替え、返事も同じ選択に合わせる。アプリは画面側の機械が数値をどの順で記憶するかを調べてから窓を頼む必要がない。違いを引き受けるのがサーバーの仕事だ。最初のBまたはlは挨拶ではなく、変換担当を決める発令書である。

画像が来ると担当が逆になる。ビットマップやピクスマップは、サーバーが示す画像形式で送受信する。接続時のサーバーの返事には、image-byte-order、ビットマップの走査線単位と余白、対応するピクスマップ形式などが入る。XYFormatでは各走査線の単位、ZFormatでは各画素値に画像のバイト順がかかる。クライアントの生まれつきの並べ方が違えば、クライアントが画像のバイトを入れ替える。画面を持つ側が、画像の荷造りの仕方を決めた。

この違いを見落とすと、窓の幅などは正しく読めても画像だけ別の順で渡してしまう。RFCが示した規則から見える実装上の危険であり、特定の画面が乱れたという事件を持ち出す必要はない。数値の命令が正しく通った事実は、次に来る画素まで正しいという証明にならない。同じ接続に二つの翻訳規則があるのだから。

接続の始まりには、バイト順の後にクライアントが期待する版番号と認可方式の名前・データも続く。サーバーは対応する版と結果を返し、受け入れる場合には資源や画像の形式を知らせる。認可方式の具体的な種類は、この中核文書では決めていない。今回の主役は順番だ。最初の字で命令の読み方が決まり、サーバーの返事で画像の作り方が決まる。

どちらの機械が「正しい」順序を持つかという争いではない。普通の値はクライアント流をサーバーが読み、画像はサーバー流にクライアントが合わせる。X11は機械の違いを消す代わりに、誰がどこで直すかを決めた。画面に一枚の絵を出す前に、二台はそれぞれ別の辞書を開く必要があった。