摘要

  • RFC 1013 描述的 X11 建联首字节有两种值：八进制 102，即 ASCII 大写 B，表示高位字节在前；八进制 154，即小写 l，表示低位字节在前。普通 16 位和 32 位协议字段依客户端的选择读写。
  • 位图和像素图依服务器公布的图像格式，包括图像字节序。服务器负责为普通协议字段换字节；客户端若原生图像字节序不同，就要按服务器的要求调整像素数据。

想象一台工作站上的程序，要在另一台机器连接的屏幕上开窗口。它得发尺寸、资源编号、绘图指令。如果两台机器把一个多字节数字装进内存的顺序相反，“宽度”就可能被读成另一个宽度。线缆把字节送到了，却不会替两端解释从哪一头开始念。X11 把这个约定放在谈话的第一个字节里。

1987 年 6 月发表的 RFC 1013 收录了 X 协议第 11 版的 alpha 更新。远程客户端可使用可靠字节流；若用 TCP，编号 N 的显示服务器接受 6000 加 N 端口上的连接。客户端第一字节告诉服务器 16 位与 32 位字段采用什么顺序。文档用八进制写作 102 和 154，分别对应 ASCII 大写 B 和小写 l。它们不是十进制的两个神秘常量，而是让双方知道“先读哪头”的开场白。

对普通协议字段，客户端说了算。服务器在自己的本机字节序不同时负责调整，回传的多字节值通常也采用客户端选的顺序。程序无须事先打听显示服务器的处理器怎么摆放每个数字。服务器接过这份翻译工作。第一个字母仿佛会议纪要的写法已经定了，大家可以开始谈窗口有多宽。

轮到图片，主持人换了。RFC 1013 要求位图、像素图按服务器指定的格式传送和接收。建联回复会列出 image-byte-order、位图扫描线的单位与填充、可用像素图格式等信息。XYFormat 的字节序落在每个扫描线单位上；ZFormat 则落在每个像素值上。客户端原生图像字节序若与服务器要求不同，就由客户端换字节。屏幕要显示图片，屏幕所在的一方规定图片的装箱方式。

这不是卖弄“大端”“小端”术语。它决定谁干活，也指出一个很具体的错误：窗口命令解码完全正常，图像却因为客户端沿用了命令的字节序而排错。原文给出避免错误的分工；这是从规则推得的实现风险，不必替 1987 年编造一场花屏事故。一次连接里，协议字段读得懂，并不能保证像素也按同一套办法读。

开场白还包含客户端预期的协议主次版本、授权名称和相关数据。服务器回报自己的版本与连接结果；接受后，又给出资源、屏幕和图像格式。RFC 1013 把有效授权机制留给其他安排。对字节序故事来说，关键是这两次交代：第一个字节让服务器听懂命令，服务器的回复让客户端准备好图片。只听一半，就像把会议记录写对了，却把投影片拿反。

协议没有要求所有电脑的内存都排得一样。它把翻译工作分派给两端：服务器照客户端的顺序理解普通数字，客户端照服务器的顺序交付图像。共同窗口看似只有一扇，背后却有两份明确的交接单。图像真正出现之前，双方先得知道谁该为哪一段字节负责。