サイト内関連リンク： RFB プロトコル 3.7
トップページ - 翻訳ドキュメント - RFB プロトコル 3.8
原文：http://www.realvnc.com/docs/rfbproto.pdf(注 PDF)
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
2009/01/18 0.1.0 初版
2009/08/15 0.2.0 元の仕様が更新されていたのでそれを反映しました。定数定義の追加と誤植訂正です。
ソーシャルブックマーク：
サイト内関連リンク：
RFB プロトコル 3.7
Tristan Richardson
RealVNC Ltd
(formerly of Olivetti Research Ltd / AT&T Labs Cambridge) *
Tristan Richardson
RealVNC Ltd
(以前は Olivetti Research Ltd / AT&T Labs Cambridge) *
* James Weatherall, Andy Harter and Ken Wood also helped in the design of the RFB protocol James Weatherall、Andy Harter、Ken Wood も RFB プロトコルの設計に貢献した
Version 3.8
Last updated 5 August 2009
バージョン 3.8
最終更新日 2009/8/5
RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces. Because it works at the framebuffer level it is applicable to all windowing systems and applications, including X11, Windows and Macintosh. RFB is the protocol used in VNC (Virtual Network Computing). RFB("remote framebuffer")はグラフィカルユーザーインターフェイスにリモートアクセスするための単純なプロトコルである。このプロトコルはフレームバッファレベルで動作するため、X11 や Windows 3.1/95/NT、Macintosh などを含む、あらゆるウィンドウシステムやアプリケーションに適合する。RFB は VNC (Virtual Network Computing)において使用されるプロトコルである。
The remote endpoint where the user sits (i.e. the display plus keyboard and/or pointer) is called the RFB client or viewer. The endpoint where changes to the framebuffer originate (i.e. the windowing system and applications) is known as the RFB server. ユーザーが居る側(つまり、ディスプレイとキーボードやマウスがある側)の終端を、RFB クライアントまたは RFB ビューワと呼ぶ。フレームバッファへの変更が発生する側(つまり、ウィンドウシステムやアプリケーションが動作している側)を、RFB サーバーと呼ぶ。
RFB is truly a "thin client" protocol. The emphasis in the design of the RFB protocol is to make very few requirements of the client. In this way, clients can run on the widest range of hardware, and the task of implementing a client is made as simple as possible. RFB は真に "シン･クライアント(thin client)" なプロトコルである。RFB プロトコルの設計は、クライアントにほとんど制約を課さないことに重きを置いている。そのため、クライアントは多彩なハードウェア上で動作し、クライアントを実装する作業は非常にシンプルなものになっている。
The protocol also makes the client stateless. If a client disconnects from a given server and subsequently reconnects to that same server, the state of the user interface is preserved. Furthermore, a different client endpoint can be used to connect to the same RFB server. At the new endpoint, the user will see exactly the same graphical user interface as at the original endpoint. In effect, the interface to the user's applications becomes completely mobile. Wherever suitable network connectivity exists, the user can access their own personal applications, and the state of these applications is preserved between accesses from different locations. This provides the user with a familiar, uniform view of the computing infrastructure wherever they go. またこのプロトコルは、クライアントをステートレスにする。あるサーバーから切断したクライアントが後に同じサーバーに再接続したとき、ユーザーインターフェイスは前の状態が保持されている。さらに、同じ RFB サーバーに対して別のクライアントから接続することもできる。ユーザーは新しいクライアントから、最初のクライアントからのユーザーインターフェイスと全く同じ状態を見ることになる。これは事実上、ユーザーのアプリケーションが完全にモバイル化されるということである。適切なネットワーク接続があるところならどこからでも、利用者は自分のアプリケーションにアクセスすることができ、異なる場所からのアクセスに対してアプリケーションの状態は保持される。これによりユーザーがどこにいても、彼らのよく知る同じコンピュータ環境を提供することができる。
The display side of the protocol is based around a single graphics primitive: "put a rectangle of pixel data at a given x,y position". At first glance this might seem an inefficient way of drawing many user interface components. However, allowing various different encodings for the pixel data gives us a large degree of flexibility in how to trade off various parameters such as network bandwidth, client drawing speedand server processing speed. このプロトコルの表示側は「指定された x, y 座標に矩形のピクセル情報を描画する」という単一の描画規則に基づいている。一見すると、これは多様なユーザーインターフェイス要素を描画するには非効率に思えるかもしれない。しかし、ピクセル情報に対して多様なエンコード方法を許可することにより、例えばネットワークの帯域やクライアントの描画能力やサーバーの処理能力といった様々な要因のトレードオフを決定する上で、大きな柔軟性を与えている。
A sequence of these rectangles makes a framebuffer update (or simply update). An update represents a change from one valid framebuffer state to another, so in some ways is similar to a frame of video. The rectangles in an update are usually disjoint but this is not necessarily the case. これらの矩形の連続が、フレームバッファ更新(framebuffer update) (または単に更新(update)) を構成する。更新はある有効なフレームバッファの状態から別の状態への変更として表現され、その点ではビデオフレームに似ている。通常、一回の更新中に現れる矩形が重なることはないが、必ずしもそうである必要はない。
The update protocol is demand-driven by the client. That is, an update is only sent from the server to the client in response to an explicit request from the client. This gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. With typical applications, changes to the same area of the framebuffer tend to happen soon after one another. With a slow client and/or network, transient states of the framebuffer can be ignored, resulting in less network traffic and less drawing for the client. 更新プロトコルはクライアントからの要求によってのみ動作する。つまり、クライアントからの明示的な要求に対する応答によってのみ、サーバーからクライアントに更新が送られるということである。この特徴はこのプロトコルに適応能力を与えており、クライアントやネットワークが遅ければ遅いほど、更新の発生率は低くなる。典型的なアプリケーションでは、フレームバッファの同一エリア内への変更が次々と連続して発生する傾向がある。遅いクライアントや遅いネットワークはその過渡的なフレームバッファの状態を無視することができるため、より少ないネットワークトラフィック、より少ないクライアント側の描画で済むことになる。
The input side of the protocol is based on a standard workstation model of a keyboard and multi-button pointing device. Input events are simply sent to the server by the client whenever the user presses a key or pointer button, or whenever the pointing device is moved. These input events can also be synthesised from other non-standard I/O devices. For example, a pen-based handwriting recognition engine might generate keyboard events. このプロトコルの入力側は「キーボードと複数ボタンの付いたポインティングデバイス」という標準的なワークステーションモデルに基づいている。利用者がキーやボタンを押したりポインティングデバイスを動かしたりした場合には常に、入力イベントがクライアントからサーバーに単純に伝えられる。これらの入力イベントは、他の非標準の入出力デバイスによって合成させることも可能である。例えばペンを使った手書き認識エンジンがキーボードイベントを生成してもよい。
Initial interaction between the RFB client and server involves a negotiation of the format and encoding with which pixel data will be sent. This negotiation has been designed to make the job of the client as easy as possible. The bottom line is that the server must always be able to supply pixel data in the form the client wants. However if the client is able to cope equally with several different formats or encodings, it may choose one which is easier for the server to produce. RFB のクライアント・サーバー間の最初の対話には、送信されるピクセルデータのフォーマット(format) および エンコード形式(encoding) の交渉が含まれる。この交渉は、クライアントの作業が出来るだけ簡単になるように設計されている。最低限は、クライアントの要求する形式でサーバーがピクセルデータを常に提供できなければならないということである。しかしながらクライアントがいくつかの異なるフォーマットやエンコードに対応している場合、サーバーがもっとも簡単に提供できるものを選択してもよい。
Pixel format refers to the representation of individual colours by pixel values. The most common pixel formats are 24-bit or 16-bit "true colour", where bit-fields within the pixel value translate directly to red, green and blue intensities, and 8-bit "colour map" where an arbitrary mapping can be used to translate from pixel values to the RGB intensities. ピクセルの フォーマット(format) はピクセル値による個々の色の表現を表す。もっとも一般的なピクセルフォーマットは、24 ビットまたは 16 ビットの "トゥルーカラー(true colour)"(ピクセル値のビットが赤・緑・青の強さをそのまま表す)と、8 ビットの "カラーマップ(colour map)"(ピクセル値から RGB 値へ変換するために任意のマッピングを使用できる)である。
Encoding refers to how a rectangle of pixel data will be sent on the wire. Every rectangle of pixel data is prefixed by a header giving the X,Y position of the rectangle on the screen, the width and height of the rectangle, and an encoding type which specifies the encoding of the pixel data. The data itself then follows using the specified encoding. エンコードはピクセルデータの矩形がどのように送信されるかを表す。すべての矩形データは、その先頭にヘッダとしてその矩形のスクリーン上での X, Y 座標、幅と高さ、ピクセルデータのエンコード形式を示す エンコードタイプ(encoding type) を持つ。データ自体は指定のエンコード形式でその後に続く。
The encoding types defined at present are Raw, CopyRect, RRE, Hextile and ZRLE. In practice we normally use only the ZRLE, Hextile and CopyRect encodings since they provide the best compression for typical desktops. See section 6.6 for a description of each of the encodings. 現時点で定義されているエンコード形式は、Raw、CopyRect、RRE、Hextile、ZRLE である。実際のところ私たちは通常、ZRLE、Hextile、CopyRect だけを使用する。これらは典型的なデスクトップにとって最も圧縮効率のよい形式だからである。各エンコード形式の詳細はセクション 6.6 を参照してほしい。
There are a number of ways in which the protocol can be extended: このプロトコルを拡張する方法は数多くある：
Under no circumstances should you use a different protocol version number. Protocol versions are defined by the maintainers of the RFB protocol, RealVNC Ltd. If you use a different protocol version number then you are not RFB / VNC compatible. To ensure that you stay compatible with the RFB protocol it is important that you contact RealVNC Ltd to make sure that your encoding types and security types do not clash. Please see the RealVNC website at http://www.realvnc.com for details of how to contact us; sending a message to the VNC mailing list is the best way to get in touch and let the rest of the VNC community know. どのような状況下でも、異なるプロトコルバージョン番号を使用するべきではない。プロトコルバージョンは RFB プロトコルのメンテナである RealVNC Ltd. によって定義される。異なるプロトコルバージョン番号を使用するなら、それは RFB/VNC 互換ではない。RFB プロトコルとの互換性を保っていることを確認するには、エンコードタイプとセキュリティタイプとが衝突していないことを確認するために、RealVNC Ltd に連絡を取ることが重要である。私たちに連絡を取る方法の詳細は、RealVNC のウェブサイト http://www.realvnc.com を参照してほしい。私たちに連絡を取り、他の VNC コミュニティに知らせる最善の方法は、メッセージを VNC メーリングリストに送ることである。
The RFB protocol can operate over any reliable transport, either byte-stream or messagebased. Conventionally it is used over a TCP/IP connection. There are three stages to the protocol. First is the handshaking phase, the purpose of which is to agree upon the protocol version and the type of security to be used. The second stage is an initialisation phase where the client and server exchange ClientInit and ServerInit messages. The final stage is the normal protocol interaction. The client can send whichever messages it wants, and may receive messages from the server as a result. All these messages begin with a message-type byte, followed by any message-specific data. RFB プロトコルは任意の信頼できるトランスポート(バイトストリームまたはメッセージベース)上で運用可能である。通常は TCP/IP 接続上で使用される。このプロトコルには三つの段階がある。第一段階はハンドシェイクフェーズであり、その目的は、使用されるプロトコルのバージョンとセキュリティタイプとに合意することである。第二段階は初期化フェーズであり、クライアントとサーバーは ClientInit メッセージと ServerInit メッセージとを交換する。最終段階は通常のプロトコル対話である。クライアントは何であれ望みのメッセージを送信することができ、その結果としてサーバーからメッセージを受け取る。すべてのメッセージは message-type byte で始まり、その後にメッセージ固有のデータが続く。
The following descriptions of protocol messages use the basic types U8, U16, U32, S8, S16, S32. These represent respectively 8, 16 and 32-bit unsigned integers and 8, 16 and 32-bit signed integers. All multiple byte integers (other than pixel values themselves) are in big endian order (most significant byte first). 以降のプロトコルメッセージの説明では、基本的な型として U8・U16・U32、および S8・S16・S32 を使用する。これらはそれぞれ、8 ビット・16 ビット・32 ビットの符号なし整数、8 ビット・16 ビット・32 ビットの符号付き整数を表す。複数バイトの整数(ピクセル値そのものを除く)はビッグエンディアン(最上位ビットが先に現れる)である。
The type PIXEL is taken to mean a pixel value of bytesPerPixel bytes, where 8 x bytesPerPixel is the number of bits-per-pixel as agreed by the client and server - either in the ServerInit message (section 6.3.2) or a SetPixelFormat message (section 6.4.1). PIXEL 型は bytesPerPixel バイトのピクセル値を意味する。ここで 8 × bytesPerPixel は、サーバーとクライアントとが ServerInit メッセージ(セクション 6.3.2)または SetPixelFormat メッセージ(6.4.1) のどちらかで合意した bits-per-pixel の値である。
Handshaking begins by the server sending the client a ProtocolVersion message.This lets the client know which is the highest RFB protocol version number supported by the server. The client then replies with a similar message giving the version number of the protocol which should actually be used (which may be different to that quoted by the server). A client should never request a protocol version higher than that offered by the server. It is intended that both clients and servers may provide some level of backwards compatibility by this mechanism. ハンドシェイクは、サーバーからクライアントへの ProtocolVersion メッセージの送信で開始される。このメッセージは、サーバーのサポートする RFB プロトコルのバージョン番号のどれが最新かをクライアントに知らせる。その後クライアントは、実際に使われるべきプロトコルのバージョン番号(サーバーが提示したものと異なってもよい)を知らせる同じようなメッセージを返す。クライアントはサーバーの提示したものより高いプロトコルバージョンを要求してはならない。この仕組みは、クライアントとサーバーとの両方が、ある程度の下位互換性を提供できることを目的としたものである。
The only published protocol versions at this time are 3.3, 3.7, 3.8 (version 3.5 was wrongly reported by some clients, but this should be interpreted by all servers as 3.3). Addition of a new encoding or pseudo-encoding type does not require a change in protocol version, since a server can simply ignore encodings it does not understand. 現時点で公開されているプロトコルバージョンは、3.3、3.7、3.8 だけである(一部のクライアントは誤ってバージョン 3.5 を通知するが、サーバーはそれを 3.3 と解釈するべきである)。サーバーは理解できないエンコードを単純に無視できるため、新しいエンコードまたは擬似エンコードの追加はプロトコルバージョンの変更を必要としない。
The ProtocolVersion message consists of 12 bytes interpreted as a string of ASCII characters in the format "RFB xxx.yyy\n" where xxx and yyy are the major and minor version numbers, padded with zeros. ProtocolVersion メッセージは ASCII 文字列として解釈される 12 バイトから構成される。フォーマットは "RFB xxx.yyy\n" であり、xxx および yyy はメジャーバージョン番号とマイナーバージョン番号とを表し、ゼロでパディングされる。
No. of bytes | Value
-------------+------------------------------------------
12 | "RFB 003.003\n"
| (hex 52 46 42 20 30 30 33 2e 30 30 33 0a)
バイト数 | 値
-------------+------------------------------------------
12 | "RFB 003.003\n"
| (hex 52 46 42 20 30 30 33 2e 30 30 33 0a)
or または
No. of bytes | Value
-------------+------------------------------------------
12 | "RFB 003.007\n"
| (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)
バイト数 | 値
-------------+------------------------------------------
12 | "RFB 003.007\n"
| (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)
or または
No. of bytes | Value
-------------+------------------------------------------
12 | "RFB 003.008\n"
| (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)
バイト数 | 値
-------------+------------------------------------------
12 | "RFB 003.008\n"
| (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)
Once the protocol version has been decided, the server and client must agree on the type of security to be used on the connection. プロトコルバージョンが決定すると、サーバーおよびクライアントは、その接続で使用されるセキュリティの種類に合意しなければならない。
No. of bytes | Type [Value] | Description -------------------------+------------------+------------------------- 1 | U8 | number-of-security-types number-of-security-types | U8 array | security-types
バイト数 | 型 [値] | 説明 -------------------------+--------------+------------------------- 1 | U8 | number-of-security-types number-of-security-types | U8 array | security-typesIf the server listed at least one valid security type supported by the client, the client sends back a single byte indicating which security type is to be used on the connection: クライアントのサポートする有効なセキュリティタイプを少なくともひとつサーバーが提示した場合、クライアントはその接続上で使用されるセキュリティタイプを表す単一バイトを送り返す：
No. of bytes | Type [Value] | Description -------------+--------------+-------------- 1 | U8 | security-type
バイト数 | 型 [値] | 説明 -------------+--------------+-------------- 1 | U8 | security-typeIf number-of-security-types is zero, then for some reason the connection failed (e.g. the server cannot support the desired protocol version). This is followed by a string describing the reason (where a string is specified as a length followed by that many ASCII characters): number-of-security-types がゼロの場合、何らかの理由(例えば要求されたプロトコルバージョンをサーバーがサポートしていないため)で接続が失敗したということである。その後に理由を説明する文字列が続く(文字列は長さの後に ASCII 文字列が続く)：
No. of bytes | Type [Value] | Description --------------+------------------+-------------------- 4 | U32 | reason-length reason-length | U8 array | reason-string
バイト数 | 型 [値] | 説明 --------------+------------------+-------------------- 4 | U32 | reason-length reason-length | U8 array | reason-stringThe server closes the connection after sending the reason-string. reason-string を送信した後、サーバーは接続を閉じる。
No. of bytes | Type [Value] | Description -------------+--------------+-------------- 4 | U32 | security-type
バイト数 | 型 [値] | 説明 -------------+--------------+-------------- 4 | U32 | security-typeThe security-type may only take the value 0, 1 or 2. A value of 0 means that the connection has failed and is followed by a string giving the reason, as described above. security-type は値 0、1、2 のみを取ることができる。値 0 は接続の失敗を表し、前述の理由を表す文字列が続く。
The security types defined in this document are: この文書で定義されるセキュリティタイプは以下の通り：
Number | Name -------+------------------- 0 | Invalid 1 | None 2 | VNC Authentication
値 | 名称 -------+------------------- 0 | Invalid 1 | None 2 | VNC Authentication
Other registered security types are: その他の登録済みセキュリティタイプは以下の通り：
Number | Name -------+--------- 5 | RA2 6 | RA2ne 16 | Tight 17 | Ultra 18 | TLS 19 | VeNCrypt 20 | GTK-VNC SASL 21 | MD5 hash authentication
値 | 名称 -------+--------- 5 | RA2 6 | RA2ne 16 | Tight 17 | Ultra 18 | TLS 19 | VeNCrypt 20 | GTK-VNC SASL 21 | MD5 ハッシュ認証
Once the security-type has been decided, data specific to that security-type follows (see section 6.2 for details). At the end of the security handshaking phase, the protocol normally continues with the SecurityResult message. security-type が決定すると、次にその security-type に固有のデータが続く(詳細はセクション 6.2 を参照)。セキュリティハンドシェイク段階の終わりに、プロトコルは通常 SecurityResult メッセージで継続する。
Note that after the security handshaking phase, it is possible that further protocol data is over an encrypted or otherwise altered channel. セキュリティハンドシェイク段階の後のプロトコルデータは、暗号化または別の方法で変更されたチャンネル上を送られる。
The server sends a word to inform the client whether the security handshaking was successful. サーバーはクライアントに、セキュリティハンドシェイクが成功したかどうかを知らせる 1 ワードを送信する。
No. of bytes | Type [Value] | Description
-------------+--------------+------------
4 | U32 | status:
| 0 | OK
| 1 | failed
バイト数 | 型 [値] | 説明
-------------+--------------+---------------
4 | U32 | ステータス:
| 0 | OK (成功)
| 1 | failed (失敗)
If successful, the protocol passes to the initialisation phase (section 6.3). 成功した場合、プロトコルは初期化段階(セクション 6.3)へ移行する。
No. of bytes | Type [Value] | Description
--------------+------------------+--------------------
4 | U32 | reason-length
reason-length | U8 array | reason-string
バイト数 | 型 [値] | 説明 --------------+------------------+-------------------- 4 | U32 | reason-length reason-length | U8 array | reason-string
No authentication is needed and protocol data is to be sent unencrypted. 認証は不要であり、プロトコルデータは暗号化されずに送信される。
VNC authentication is to be used and protocol data is to be sent unencrypted. The server sends a random 16-byte challenge: VNC 認証が使用され、プロトコルデータは暗号化されずに送信される。サーバーはランダムな 16 バイトのチャレンジを送信する：
No. of bytes | Type [Value] | Description -------------+--------------+------------ 16 | U8 | challenge
バイト数 | 型 [値] | 説明 -------------+--------------+------------ 16 | U8 | challenge
The client encrypts the challenge with DES, using a password supplied by the user as the key, and sends the resulting 16-byte response: クライアントは、ユーザーの提供したパスワードを鍵としてチャレンジを DES で暗号化し、結果として 16 バイトの応答を送信する：
No. of bytes | Type [Value] | Description -------------+--------------+------------ 16 | U8 | response
バイト数 | 型 [値] | 説明 -------------+--------------+------------ 16 | U8 | response
The protocol continues with the SecurityResult message. プロトコルは SecurityResult メッセージで継続する。
Once the client and server are sure that they're happy to talk to one another using the agreed security type, the protocol passes to the initialisation phase. The client sends a ClientInit message followed by the server sending a ServerInit message. サーバーとクライアントとが合意したセキュリティタイプを使用して互いに対話できることを確認すると、プロトコルは初期化段階へ移行する。クライアントは ClientInit メッセージを送信し、次にサーバーの ServerInit メッセージが続く。
No. of bytes | Type [Value] | Description -------------+--------------+------------ 1 | U8 | shared-flag
バイト数 | 型 [値] | 説明 -------------+--------------+------------ 1 | U8 | shared-flag
Shared-flag is non-zero (true) if the server should try to share the desktop by leaving other clients connected, zero (false) if it should give exclusive access to this client by disconnecting all other clients. サーバーが他のクライアントを接続したままにすることでデスクトップの共有を試みるべき場合、shared-flag は非ゼロ(真)になる。他のクライアントをすべて切断することでこのクライアントに排他的アクセスを与えるべき場合、ゼロ(偽)になる。
After receiving the ClientInit message, the server sends a ServerInit message. This tells the client the width and height of the server's framebuffer, its pixel format and the name associated with the desktop: ClientInit メッセージを受信した後、サーバーは ServerInit メッセージを送信する。これはクライアントに、サーバーのフレームバッファの幅と高さ、ピクセルフォーマット、デスクトップに関連付けられた名前を伝える：
No. of bytes | Type [Value] | Description -------------+----------------------+------------ 2 | U16 | framebuffer-width 2 | U16 | framebuffer-height 16 | PIXEL_FORMAT | server-pixel-format 4 | U32 | name-length name-length | U8 array | name-string
バイト数 | 型 [値] | 説明 -------------+----------------------+------------ 2 | U16 | framebuffer-width 2 | U16 | framebuffer-height 16 | PIXEL_FORMAT | server-pixel-format 4 | U32 | name-length name-length | U8 array | name-string
where PIXEL_FORMAT is ここで PIXEL_FORMAT は以下の通り
No. of bytes | Type [Value] | Description -------------+--------------+------------ 1 | U8 | bits-per-pixel 1 | U8 | depth 1 | U8 | big-endian-flag 1 | U8 | true-colour-flag 2 | U16 | red-max 2 | U16 | green-max 2 | U16 | blue-max 1 | U8 | red-shift 1 | U8 | green-shift 1 | U8 | blue-shift 3 | | padding
バイト数 | 型 [値] | 説明 -------------+--------------+------------ 1 | U8 | bits-per-pixel 1 | U8 | depth 1 | U8 | big-endian-flag 1 | U8 | true-colour-flag 2 | U16 | red-max 2 | U16 | green-max 2 | U16 | blue-max 1 | U8 | red-shift 1 | U8 | green-shift 1 | U8 | blue-shift 3 | | padding
Server-pixel-format specifies the server's natural pixel format. This pixel format will be used unless the client requests a different format using the SetPixelFormat message (section 6.4.1). Server-pixel-format はサーバーの持つ本来のピクセルフォーマットを表す。クライアントが SetPixelFormat メッセージ(セクション 6.4.1)によって別のフォーマットを要求しない限り、このピクセルフォーマットが使用されることになる。
Bits-per-pixel is the number of bits used for each pixel value on the wire. This must be greater than or equal to the depth which is the number of useful bits in the pixel value. Currently bits-per-pixel must be 8, 16 or 32 - less than 8-bit pixels are not yet supported. Big-endian-flag is non-zero (true) if multi-byte pixels are interpreted as big endian. Of course this is meaningless for 8 bits-per-pixel. bits-per-pixel は各ピクセル値に使用されるビット数である。これは、ピクセル値のうちの有効なビット数である depth 以上でなければならない。今のところ bits-per-pixel は 8 または 16 または 32 でなければならない(8 ビット未満のピクセル値はまだサポートされていない)。マルチバイトのピクセルがビッグエンティアンとして解釈される場合、big-endian-flag は非ゼロ(真)になる。当然ながら、bits-per-pixel が 8 の場合にはこのフラグは意味を持たない。
If true-colour-flag is non-zero (true) then the last six items specify how to extract the red, green and blue intensities from the pixel value. Red-max is the maximum red value (= 2n - 1 where n is the number of bits used for red). Note this value is always in big endian order. Red-shift is the number of shifts needed to get the red value in a pixel to the least significant bit. Green-max, green-shift and blue-max, blue-shift are similar for green and blue. For example, to find the red value (between 0 and red-max) from a given pixel, do the following: true-colour-flag が非ゼロ(真)の場合、続く 6 項目は、赤・緑・青の強さをピクセル値から抽出する方法を表す。red-max は赤の最大値(= 2n - 1 (n は赤に使用されるビット数))である。この値は常にビッグエンディアンであることに注意してほしい。red-shift は、ピクセル内の赤の値を最下位ビットに取得するのため必要なシフト数である。green-max ・ green-shift および blue-max ・ blue-shift は、緑・青のための同様の値である。例えばある特定のピクセルから赤の値(0 から red-max の範囲)を見つけるには、以下のようにする：
If true-colour-flag is zero (false) then the server uses pixel values which are not directly composed from the red, green and blue intensities, but which serve as indices into a colour map. Entries in the colour map are set by the server using the SetColourMapEntries message (section 6.5.2). true-colour-flag がゼロ(偽)の場合、サーバーは、赤・緑・青の強さを直接表すピクセル値ではなく、カラーマップのインデックスを表すピクセル値を使用する。カラーマップ内のエントリは、サーバーの SetColourMapEntries メッセージ(セクション 6.5.2)により設定される。
The client to server message types defined in this document are: この文書で定義されているクライアントからサーバーへのメッセージタイプは以下の通り：
Number | Name -------+------------------------- 0 | SetPixelFormat 2 | SetEncodings 3 | FramebufferUpdateRequest 4 | KeyEvent 5 | PointerEvent 6 | ClientCutText
値 | 名称 -------+------------------------- 0 | SetPixelFormat 2 | SetEncodings 3 | FramebufferUpdateRequest 4 | KeyEvent 5 | PointerEvent 6 | ClientCutText
Other registered message types are: その他の登録済みメッセージタイプは以下の通り：
Number | Name ---------+---------------- 255 | Anthony Liguori 254, 127 | VMWare 253 | gii 252 | tight 251 | Pierre Ossman SetDesktopSize 250 | Colin Dean xvp
値 | 名称 ---------+---------------- 255 | Anthony Liguori 254, 127 | VMWare 253 | gii 252 | tight 251 | Pierre Ossman SetDesktopSize 250 | Colin Dean xvp
Note that before sending a message not defined in this document a client must have determined that the server supports the relevant extension by receiving some extension-specific confirmation from the server. この文書で定義されていないメッセージを送信する前に、クライアントは対応する拡張固有の合意をサーバーから受け取ることで、サーバーがその拡張をサポートすることを確認しなければならない。
Sets the format in which pixel values should be sent in FramebufferUpdate messages. If the client does not send a SetPixelFormat message then the server sends pixel values in its natural format as specified in the ServerInit message (section 6.3.2). FramebufferUpdate メッセージにおいて送信されるべきピクセル値のフォーマットを設定する。クライアントが SetPixelFormat メッセージを送信しない場合、サーバーは ServerInit メッセージ(セクション 6.3.2)で指定した本来のフォーマットでピクセル値を送信する。
If true-colour-flag is zero (false) then this indicates that a "colour map" is to be used. The server can set any of the entries in the colour map using the SetColourMapEntries message (section 6.5.2). Immediately after the client has sent this message the colour map is empty, even if entries had previously been set by the server. true-colour-flag がゼロ(偽)の場合、"カラーマップ(colour map)" が使用されることを表す。サーバーは、SetColourMapEntries メッセージ(セクション 6.5.2)を使用してカラーマップ内の任意のエントリを設定できる。クライアントがこのメッセージを送信すると、それ以前にサーバーによってエントリが設定されていたとしても、カラーマップは空になる。
No. of bytes | Type [Value] | Description -------------+----------------------+------------ 1 | U8 0 | message-type 3 | | padding 16 | PIXEL_FORMAT | pixel-format
バイト数 | 型 [値] | 説明 -------------+----------------------+------------ 1 | U8 0 | message-type 3 | | padding 16 | PIXEL_FORMAT | pixel-format
where PIXEL_FORMAT is as described in section 6.3.2: ここで PIXEL_FORMAT はセクション 6.3.2 で説明されている通りである：
No. of bytes | Type [Value] | Description -------------+--------------+----------------- 1 | U8 | bits-per-pixel 1 | U8 | depth 1 | U8 | big-endian-flag 1 | U8 | true-colour-flag 2 | U16 | red-max 2 | U16 | green-max 2 | U16 | blue-max 1 | U8 | red-shift 1 | U8 | green-shift 1 | U8 | blue-shift 3 | padding
バイト数 | 型 [値] | 説明 -------------+--------------+----------------- 1 | U8 | bits-per-pixel 1 | U8 | depth 1 | U8 | big-endian-flag 1 | U8 | true-colour-flag 2 | U16 | red-max 2 | U16 | green-max 2 | U16 | blue-max 1 | U8 | red-shift 1 | U8 | green-shift 1 | U8 | blue-shift 3 | padding
Sets the encoding types in which pixel data can be sent by the server. The order of the encoding types given in this message is a hint by the client as to its preference (the first encoding specified being most preferred). The server may or may not choose to make use of this hint. Pixel data may always be sent in raw encoding even if not specified explicitly here. サーバーが送信してもよいピクセルデータのエンコードタイプを設定する。このメッセージ内で与えられるエンコードタイプの順序は、クライアントによる優先順位のヒントである(先頭のエンコードがもっとも優先順位が高い)。サーバーはこのヒントを使用してもよいし、しなくてもよい。明示的に指定されなかった場合、ピクセルデータは常に raw エンコードで送信される。
In addition to genuine encodings, a client can request "pseudo-encodings" to declare to the server that it supports certain extensions to the protocol. A server which does not support the extension will simply ignore the pseudo-encoding. Note that this means the client must assume that the server does not support the extension until it gets some extension-specific confirmation from the server. 本物のエンコードに加えて、クライアントはこのプロトコルに対する特定の拡張をサポートすることをサーバーに宣言するために、"擬似エンコード(pseudo-encoding)" を要求することができる。その拡張をサポートしないサーバーは、単純にその擬似エンコードを無視するだろう。これは、何らかの拡張固有の合意をサーバーから受け取らない限り、クライアントはそのサーバーがその拡張をサポートしないと仮定しなければならないことを意味していることに注意してほしい。
See section 6.6 for a description of each encoding and section 6.7 for the meaning of pseudo-encodings. 各エンコードの説明に付いてはセクション 6.6 を、擬似エンコードの意味に付いてはセクション 6.7 を参照してほしい。
No. of bytes | Type [Value] | Description -------------+--------------+-------------------- 1 | U8 2 | message-type 1 | | padding 2 | U16 | number-of-encodings
バイト数 | 型 [値] | 説明 -------------+--------------+-------------------- 1 | U8 2 | message-type 1 | | padding 2 | U16 | number-of-encodings
followed by number-of-encodings repetitions of the following: この後に number-of-encodings の数だけ以下の内容が繰り返される：
No. of bytes | Type [Value] | Description -------------+--------------+-------------- 4 | S32 | encoding-type
バイト数 | 型 [値] | 説明 -------------+--------------+-------------- 4 | S32 | encoding-type
Notifies the server that the client is interested in the area of the framebuffer specified by x-position, y-position, width and height. The server usually responds to a FramebufferUpdateRequest by sending a FramebufferUpdate. Note however that a single FramebufferUpdate may be sent in reply to several FramebufferUpdateRequests. クライアントがフレームバッファの x-position・y-position・width・height で指定される領域に関心があることをサーバーに伝える。通常サーバーは FramebufferUpdate を送信することで FramebufferUpdateRequest に応える。複数の FramebufferUpdateRequest に対して単一の FramebufferUpdate が送信されてもよいことに注意してほしい。
The server assumes that the client keeps a copy of all parts of the framebuffer in which it is interested. This means that normally the server only needs to send incremental updates to the client. サーバーは、クライアントが関心を持つフレームバッファのすべてのコピーを保持すると仮定する。つまり通常サーバーは、クライアントに差分の更新のみを送る必要があることを意味する。
However, if for some reason the client has lost the contents of a particular area which it needs, then the client sends a FramebufferUpdateRequest with incremental set to zero(false). This requests that the server send the entire contents of the specified area as soon as possible. The area will not be updated using the CopyRect encoding. しかしながら、何らかの理由でクライアントが特定の領域の内容を喪失した場合、クライアントは incremental にゼロ(偽)をセットした FramebufferUpdateRequest を送信する。これはサーバーに、指定のエリアを即座に送信するよう要求する。そのエリアが CopyRect エンコードを使用して更新されることはない。
If the client has not lost any contents of the area in which it is interested, then it sends a FramebufferUpdateRequest with incremental set to non-zero (true). If and when there are changes to the specified area of the framebuffer, the server will send a FramebufferUpdate. Note that there may be an indefinite period between the FramebufferUpdateRequest and the FramebufferUpdate. クライアントが関心を持つ領域の内容をすべて保持している場合、クライアントは incremental に非ゼロ(真)をセットした FramebufferUpdateRequest を送信する。フレームバッファの指定された領域に変更がある場合、サーバーは FramebufferUpdate を送信する。FramebufferUpdateRequest と FramebufferUpdate との間には不定の時間が掛かる可能性があることに注意してほしい。
In the case of a fast client, the client may want to regulate the rate at which it sends incremental FramebufferUpdateRequests to avoid hogging the network. 高速なクライアントの場合、ネットワークの占有を避けるために、差分の FramebufferUpdateRequest を送信する速度を制限することを望んでもよい。
No. of bytes | Type [Value] | Description -------------+--------------+-------------------- 1 | U8 3 | message-type 1 | U8 | incremental 2 | U16 | x-position 2 | U16 | y-position 2 | U16 | width 2 | U16 | height
バイト数 | 型 [値] | 説明 -------------+--------------+-------------------- 1 | U8 3 | message-type 1 | U8 | incremental 2 | U16 | x-position 2 | U16 | y-position 2 | U16 | width 2 | U16 | height
A key press or release. Down-flag is non-zero (true) if the key is now pressed, zero (false) if it is now released. The key itself is specified using the "keysym" values defined by the X Window System. キーの押下または解放。キーが押された場合 down-flag は非ゼロ(真)、解放された場合はゼロ(偽)となる。key 自体は、X Window System によって定義される "keysym" の値を表す。
No. of bytes | Type [Value] | Description -------------+--------------+-------------------- 1 | U8 4 | message-type 1 | U8 | down-flag 2 | | padding 4 | U32 | key
バイト数 | 型 [値] | 説明 -------------+--------------+-------------------- 1 | U8 4 | message-type 1 | U8 | down-flag 2 | | padding 4 | U32 | key
For most ordinary keys, the "keysym" is the same as the corresponding ASCII value. For full details, see The Xlib Reference Manual, published by O'Reilly & Associates, or see the header file <X11/keysymdef.h> from any X Window System installation. Some other common keys are: 大部分の通常のキーの場合、"keysym" は対応する ASCII 値と同じである。詳細に付いては O'Reilly & Associates から出版されている Xlib Reference Manual を参照するか、任意の X Window System のインストールが提供するヘッダファイル <X11/keysymdef.h> を参照してほしい。他の一般的なキーの一部を以下に示す：
Key name | Keysym value Key name | Keysym value ----------------+------------- ----------------+------------- BackSpace | 0xff08 F1 | 0xffbe Tab | 0xff09 F2 | 0xffbf Return or Enter | 0xff0d F3 | 0xffc0 Escape | 0xff1b F4 | 0xffc1 Insert | 0xff63 ... | ... Delete | 0xffff F12 | 0xffc9 Home | 0xff50 Shift (left) | 0xffe1 End | 0xff57 Shift (right) | 0xffe2 Page Up | 0xff55 Control (left) | 0xffe3 Page Down | 0xff56 Control (right) | 0xffe4 Left | 0xff51 Meta (left) | 0xffe7 Up | 0xff52 Meta (right) | 0xffe8 Right | 0xff53 Alt (left) | 0xffe9 Down | 0xff54 Alt (right) | 0xffea
キー名 | Keysym 値 キー名 | Keysym 値 ----------------+------------- ----------------+------------- BackSpace | 0xff08 F1 | 0xffbe Tab | 0xff09 F2 | 0xffbf Return or Enter | 0xff0d F3 | 0xffc0 Escape | 0xff1b F4 | 0xffc1 Insert | 0xff63 ... | ... Delete | 0xffff F12 | 0xffc9 Home | 0xff50 Shift (左) | 0xffe1 End | 0xff57 Shift (右) | 0xffe2 Page Up | 0xff55 Control (左) | 0xffe3 Page Down | 0xff56 Control (右) | 0xffe4 Left | 0xff51 Meta (左) | 0xffe7 Up | 0xff52 Meta (右) | 0xffe8 Right | 0xff53 Alt (左) | 0xffe9 Down | 0xff54 Alt (右) | 0xffea
The interpretation of keysyms is a complex area. In order to be as widely interoperable as possible the following guidelines should be used: keysym の解釈は複雑だが、可能な限り高い相互運用性を持たせるために、以下のガイドラインを使用するべきである：
Indicates either pointer movement or a pointer button press or release. The pointer is now at (x-position, y-position), and the current state of buttons 1 to 8 are represented by bits 0 to 7 of button-mask respectively, 0 meaning up, 1 meaning down (pressed). ポインタの移動、またはポインタのボタンの押下または解放を表す。ポインタは現在 (x-position, y-position) にあり、ボタン 1 から 8 の現在の状態は、button-mask のビット 0 から 7 によって、0 が上がっている状態、1 が下がっている(押されている)状態として表される。
On a conventional mouse, buttons 1, 2 and 3 correspond to the left, middle and right buttons on the mouse. On a wheel mouse, each step of the wheel upwards is represented by a press and release of button 4, and each step downwards is represented by a press and release of button 5. 標準的なマウスの場合、ボタン 1・2・3 がマウスの左ボタン・中ボタン・右ボタンに対応する。ホイールマウスの場合、ホイールの上方向への各ステップがボタン 4 の押下と解放とで表され、下方向への各ステップがボタン 5 の押下と解放とで表される。
No. of bytes | Type [Value] | Description -------------+--------------+-------------------- 1 | U8 5 | message-type 1 | U8 | button-mask 2 | U16 | x-position 2 | U16 | y-position
バイト数 | 型 [値] | 説明 -------------+--------------+-------------------- 1 | U8 5 | message-type 1 | U8 | button-mask 2 | U16 | x-position 2 | U16 | y-position
The client has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the linefeed / newline character (value 10) alone. No carriage-return (value 13) is needed. There is currently no way to transfer text outside the Latin-1 character set. クライアントが自身のカットバッファに新しい ISO 8859-1 (Latin-1) テキストを持ったことを表す。行の終端はラインフィード/改行文字(値 10)だけで表される。復帰文字(値 13)は必要ない。今のところ、Latin-1 文字セット以外のテキストを変換する方法はない。
No. of bytes | Type [Value] | Description -------------+------------------+------------- 1 | U8 6 | message-type 3 | | padding 4 | U32 | length length | U8 array | text
バイト数 | 型 [値] | 説明 -------------+------------------+------------- 1 | U8 6 | message-type 3 | | padding 4 | U32 | length length | U8 array | text
The server to client message types defined in this document are: この文書で定義されているサーバーからクライアントへのメッセージタイプは以下の通り：
Number | Name -------+-------------------- 0 | FramebufferUpdate 1 | SetColourMapEntries 2 | Bell 3 | ServerCutText
値 | 名称 -------+-------------------- 0 | FramebufferUpdate 1 | SetColourMapEntries 2 | Bell 3 | ServerCutText
Other registered message types are: その他の登録済みメッセージタイプは以下の通り：
Number | Name ---------+---------------- 255 | Anthony Liguori 254, 127 | VMWare 253 | gii 252 | tight 250 | Colin Dean xvp
値 | 名称 ---------+---------------- 255 | Anthony Liguori 254, 127 | VMWare 253 | gii 252 | tight 250 | Colin Dean xvp
Note that before sending a message not defined in this document a server must have determined that the client supports the relevant extension by receiving some extension-specific confirmation from the client - usually a request for a given pseudo-encoding. この文書で定義されていないメッセージを送信する前に、サーバーは対応する拡張固有の合意をクライアントから受け取ることで、クライアントがその拡張をサポートすることを確認しなければならない。
A framebuffer update consists of a sequence of rectangles of pixel data which the client should put into its framebuffer. It is sent in response to a FramebufferUpdateRequest from the client. Note that there may be an indefinite period between the FramebufferUpdateRequest and the FramebufferUpdate. フレームバッファの更新は、クライアントがフレームバッファに入れるべき一連の矩形のピクセル情報から構成される。これはクライアントからの FramebufferUpdateRequest に応えて送信される。FramebufferUpdateRequest と FramebufferUpdate との間には不定の時間が掛かる可能性があることに注意してほしい。
No. of bytes | Type [Value] | Description -------------+--------------+--------------------- 1 | U8 0 | message-type 1 | | padding 2 | U16 | number-of-rectangles
バイト数 | 型 [値] | 説明 -------------+--------------+--------------------- 1 | U8 0 | message-type 1 | | padding 2 | U16 | number-of-rectangles
This is followed by number-of-rectangles rectangles of pixel data. Each rectangle consists of: この後に number-of-rectangles の数だけ矩形のピクセルデータが続く。各矩形は以下の内容から構成される：
No. of bytes | Type [Value] | Description -------------+--------------+-------------- 2 | U16 | x-position 2 | U16 | y-position 2 | U16 | width 2 | U16 | height 4 | S32 | encoding-type
バイト数 | 型 [値] | 説明 -------------+--------------+-------------- 2 | U16 | x-position 2 | U16 | y-position 2 | U16 | width 2 | U16 | height 4 | S32 | encoding-type
followed by the pixel data in the specified encoding. See section 6.6 for the format of the data for each encoding and section 6.7 for the meaning of pseudo-encodings. 指定されたエンコードのピクセルデータがこの後に続く。各エンコードのデータフォーマットに付いてはセクション 6.6 を、擬似エンコードの意味に付いてはセクション 6.7 を参照してほしい。
When the pixel format uses a "colour map", this message tells the client that the specified pixel values should be mapped to the given RGB intensities. ピクセルフォーマットが "カラーマップ(colour map)" を使用する場合、このメッセージはクライアントに、指定されたピクセル値が特定の RGB 値にマップされるべきであることを伝える。
No. of bytes | Type [Value] | Description -------------+--------------+------------------ 1 | U8 1 | message-type 1 | | padding 2 | U16 | first-colour 2 | U16 | number-of-colours
バイト数 | 型 [値] | 説明 -------------+--------------+------------------ 1 | U8 1 | message-type 1 | | padding 2 | U16 | first-colour 2 | U16 | number-of-colours
followed by number-of-colours repetitions of the following: この後に number-of-colours の数だけ以下の内容が繰り返される：
No. of bytes | Type [Value] | Description -------------+--------------+------------ 2 | U16 | red 2 | U16 | green 2 | U16 | blue
バイト数 | 型 [値] | 説明 -------------+--------------+------------ 2 | U16 | red 2 | U16 | green 2 | U16 | blue
Ring a bell on the client if it has one. クライアントがビープ音の機能を持っていれば、それを鳴らす。
No. of bytes | Type [Value] | Description -------------+--------------+------------- 1 | U8 2 | message-type
バイト数 | 型 [値] | 説明 -------------+--------------+------------- 1 | U8 2 | message-type
The server has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the linefeed / newline character (value 10) alone. No carriage-return (value 13) is needed. There is currently no way to transfer text outside the Latin-1 character set. サーバーが自身のカットバッファに新しい ISO 8859-1 (Latin-1) テキストを持ったことを表す。行の終端はラインフィード/改行文字(値 10)だけで表される。復帰文字(値 13)は必要ない。今のところ、Latin-1 文字セット以外のテキストを変換する方法はない。
No. of bytes | Type [Value] | Description -------------+--------------+------------- 1 | U8 3 | message-type 3 | | padding 4 | U32 | length length | U8 array | text
バイト数 | 型 [値] | 説明 -------------+--------------+------------- 1 | U8 3 | message-type 3 | | padding 4 | U32 | length length | U8 array | text
The encodings defined in this document are: この文書で定義されているエンコードは以下の通り：
Number | Name -------+---------------------------- 0 | Raw 1 | CopyRect 2 | RRE 5 | Hextile 16 | ZRLE -239 | Cursor pseudo-encoding -223 | DesktopSize pseudo-encoding
値 | 名称 -------+---------------------------- 0 | Raw 1 | CopyRect 2 | RRE 5 | Hextile 16 | ZRLE -239 | Cursor 擬似エンコード -223 | DesktopSize 擬似エンコード
Other registered encodings are: その他の登録済みエンコードは以下の通り：
Number | Name -------------------------+----------------------------------- 4 | CoRRE 6 | zlib 7 | tight 8 | zlibhex 15 | TRLE 17 | Hitachi ZYWRLE -1 to -222 | -224 to -238 | -240 to -256 | tight options -257 to -272 | Anthony Liguori -273 to -304 | VMWare -305 | gii -306 | popa -307 | Peter Astrand DesktopName -308 | Pierre Ossman ExtendedDesktopSize -309 | Colin Dean xvp 0x574d5600 to 0x574d56ff | VMWare
値 | 名称 -------------------------+----------------------------------- 4 | CoRRE 6 | zlib 7 | tight 8 | zlibhex 15 | TRLE 17 | Hitachi ZYWRLE -1 ? -222 | -224 ? -238 | -240 ? -256 | tight options -257 ? -272 | Anthony Liguori -273 ? -304 | VMWare -305 | gii -306 | popa -307 | Peter Astrand DesktopName -308 | Pierre Ossman ExtendedDesktopSize -309 | Colin Dean xvp 0x574d5600 to 0x574d56ff | VMWare
The simplest encoding type is raw pixel data. In this case the data consists of width x height pixel values (where width and height are the width and height of the rectangle). The values simply represent each pixel in left-to-right scanline order. All RFB clients must be able to cope with pixel data in this raw encoding, and RFB servers should only produce raw encoding unless the client specifically asks for some other encoding type. もっとも単純なエンコードタイプは Raw ピクセルデータである。この場合のデータは、width × height のピクセル値から構成される(ここで width および height は、矩形の幅と高さである)。値は単純に左から右への走査線内の各ピクセルを表す。すべての RFB クライアントはこの Raw エンコードのピクセルデータに対応できなければならない。また RFB サーバーは、クライアントが具体的に別のエンコードタイプを要求しない限り、Raw エンコードだけを提供するべきである。
No. of bytes | Type [Value] | Description -------------------------------+---------------------+------------ width x height x bytesPerPixel | PIXEL array | pixels
バイト数 | 型 [値] | 説明 -------------------------------+---------------------+------------ width x height x bytesPerPixel | PIXEL array | pixels
The CopyRect (copy rectangle) encoding is a very simple and efficient encoding which can be used when the client already has the same pixel data elsewhere in its framebuffer. The encoding on the wire simply consists of an X,Y coordinate. This gives a position in the framebuffer from which the client can copy the rectangle of pixel data. This can be used in a variety of situations, the most obvious of which are when the user moves a window across the screen, and when the contents of a window are scrolled. A less obvious use is for optimising drawing of text or other repeating patterns. An intelligent server may be able to send a pattern explicitly only once, and knowing the previous position of the pattern in the framebuffer, send subsequent occurrences of the same pattern using the CopyRect encoding. CopyRect (矩形コピー(copy rectangle))エンコードは非常に単純で、クライアントがフレームバッファの別の場所に同じピクセルデータを既に持っている場合に使用できる効果的なエンコードである。転送されるエンコードは単純に X, Y 座標から構成される。これは、クライアントが矩形のピクセルデータをコピーできるフレームバッファ内の位置を与える。これは様々な状況で使用できるが、もっとも分かりやすいのはユーザーがスクリーン内でウィンドウを移動した場合や、ウィンドウの内容をスクロールした場合である。それよりやや劣るが、テキストなどの繰り返しパターンの描画を最適化する場合にも使用できる。高度なサーバーはパターンを一度だけ送信し、フレームバッファ内のそのパターンの位置を知っているので、後続の同じパターンの出現を CopyRect エンコードを使用して送信することができるだろう。
No. of bytes | Type [Value] | Description -------------+--------------+--------------- 2 | U16 | src-x-position 2 | U16 | src-y-position
バイト数 | 型 [値] | 説明 -------------+--------------+--------------- 2 | U16 | src-x-position 2 | U16 | src-y-position
RRE stands for rise-and-run-length encoding and as its name implies, it is essentially a two-dimensional analogue of run-length encoding. RRE-encoded rectangles arrive at the client in a form which can be rendered immediately and efficiently by the simplest of graphics engines. RRE is not appropriate for complex desktops, but can be useful in some situations. RRE は rise-and-run-length encoding を表し、その名前が暗示するように、本質的に run-length エンコードの二次元版である。クライアントに届いた RRE エンコードされた矩形は、もっとも単純なグラフィックエンジンによって即座にかつ効率的に表示することができる形式である。RRE は複雑なデスクトップには適さないが、状況によっては実用的である。
The basic idea behind RRE is the partitioning of a rectangle of pixel data into rectangular subregions (subrectangles) each of which consists of pixels of a single value and the union of which comprises the original rectangular region. The near-optimal partition of a given rectangle into such subrectangles is relatively easy to compute. RRE の背景にある基本的な考え方は、矩形のピクセルデータを小さい矩形領域に分割するというものである(それぞれの小矩形は単一値のピクセルから構成され、それらの結合が元の矩形領域を構成する)。特定の矩形をそのような小矩形にほぼ最適に分割する計算は、比較的簡単である。
The encoding consists of a background pixel value, Vb (typically the most prevalent pixel value in the rectangle) and a count N, followed by a list of N subrectangles, each of which consists of a tuple < v, x, y, w, h > where v (!= Vb) is the pixel value, (x, y) are the coordinates of the subrectangle relative to the top-left corner of the rectangle, and (w; h) are the width and height of the subrectangle. The client can render the original rectangle by drawing a filled rectangle of the background pixel value and then drawing a filled rectangle corresponding to each subrectangle. このエンコードは、背景のピクセル値 Vb(典型的にはその長方形の中で最も広い部分を占めるピクセル値)とカウント N、その後に N 個の小矩形が続き、各小矩形は < v; x; y; w; h > の組で構成され、v (!= Vb) はピクセル値、(x; y) は親矩形の左上端からの相対座標、(w; h) は小矩形の幅と高さとを表す。クライアントは背景のピクセル値で塗りつぶされた矩形を描画し、次に各小矩形に対応する塗りつぶされた矩形を描画することで、元の矩形を表示することができる。
On the wire, the data begins with the header: データは以下のヘッダから始まる：
No. of bytes | Type [Value] | Description --------------+--------------+------------------------ 4 | U32 | number-of-subrectangles bytesPerPixel | PIXEL | background-pixel-value
バイト数 | 型 [値] | 説明 --------------+--------------+------------------------ 4 | U32 | number-of-subrectangles bytesPerPixel | PIXEL | background-pixel-value
This is followed by number-of-subrectangles instances of the following structure: この後に、number-of-subrectangles の数だけ以下の構造体のインスタンスが続く：
No. of bytes | Type [Value] | Description --------------+--------------+-------------------- bytesPerPixel | PIXEL | subrect-pixel-value 2 | U16 | x-position 2 | U16 | y-position 2 | U16 | width 2 | U16 | height
バイト数 | 型 [値] | 説明 --------------+--------------+-------------------- bytesPerPixel | PIXEL | subrect-pixel-value 2 | U16 | x-position 2 | U16 | y-position 2 | U16 | width 2 | U16 | height
Hextile is a variation on the RRE idea. Rectangles are split up into 16x16 tiles, allowing the dimensions of the subrectangles to be specified in 4 bits each, 16 bits in total. The rectangle is split into tiles starting at the top left going in left-to-right, top-to-bottom order. The encoded contents of the tiles simply follow one another in the predetermined order. If the width of the whole rectangle is not an exact multiple of 16 then the width of the last tile in each row will be correspondingly smaller. Similarly if the height of the whole rectangle is not an exact multiple of 16 then the height of each tile in the final row will also be smaller. Hextile は RRE の発想のバリエーションである。矩形は 16 × 16 のサイズのタイルに分割され、小矩形の寸法を各 4 ビット、計 16 ビットで表すことができる。矩形は左上から始めて左から右へ、上から下へとタイルに分割される。エンコードされたタイルの内容は、事前に決められた順序で単純に次々に続く。矩形全体の幅が 16 の正確な倍数ではない場合、各行の最後のタイルの幅がそれに合せて小さくなる。同じように矩形全体の高さが 16 の正確な倍数ではない場合、最後の行の各タイルの高さが小さくなる。
Each tile is either encoded as raw pixel data, or as a variation on RRE. Each tile has a background pixel value, as before. However, the background pixel value does not need to be explicitly specified for a given tile if it is the same as the background of the previous tile. If all of the subrectangles of a tile have the same pixel value, this can be specified once as a foreground pixel value for the whole tile. As with the background, the foreground pixel value can be left unspecified, meaning it is carried over from the previous tile. 各タイルは Raw ピクセルデータ、または RRE のバリエーションとしてエンコードされる。前述の通り、各タイルは背景のピクセル値を持つ。ただし背景のピクセル値が直前のタイルと同じ場合、明示的に指定する必要はない。すべてのタイルの小矩形が同じピクセル値を持つ場合、タイル全体の前景のピクセル値として一度だけ指定すればよいことになる。背景の場合と同様、前景のピクセル値も未指定のままにしておき、直前のタイルから値を持ち越すことができる。
So the data consists of each tile encoded in order. Each tile begins with a subencoding type byte, which is a mask made up of a number of bits: このようにして、データは順番にエンコードされた各タイルから構成される。各タイルは以下のビットから構成される subencoding タイプバイトから始まる：
No. of bytes | Type [Value] | Description
-------------+--------------+--------------------
1 | U8 | subencoding-mask:
| 1 | Raw
| 2 | BackgroundSpecified
| 4 | ForegroundSpecified
| 8 | AnySubrects
| 16 | SubrectsColoured
バイト数 | 型 [値] | 説明
-------------+--------------+--------------------
1 | U8 | subencoding-mask:
| 1 | Raw
| 2 | BackgroundSpecified
| 4 | ForegroundSpecified
| 8 | AnySubrects
| 16 | SubrectsColoured
If the Raw bit is set then the other bits are irrelevant; width x height pixel values follow (where width and height are the width and height of the tile). Otherwise the other bits in the mask are as follows: Raw ビットがセットされている場合、他のビットは意味を持たず、width × height のピクセル値が続く(ここで width および height は、そのタイルの幅と高さである)。そうでない場合、マスク内の他のビットは以下の通りである：
No. of bytes | Type [Value] | Description --------------+--------------+----------------------- bytesPerPixel | PIXEL | background-pixel-value
バイト数 | 型 [値] | 説明 --------------+--------------+----------------------- bytesPerPixel | PIXEL | background-pixel-valueThe first non-raw tile in a rectangle must have this bit set. If this bit isn't set then the background is the same as the last tile. 矩形内の最初の Raw でないタイルには、このビットがセットされなければならない。このビットがセットされていない場合、背景は最後のタイルと同じである。
No. of bytes | Type [Value] | Description --------------+---------------+----------------------- bytesPerPixel | PIXEL | foreground-pixel-value
バイト数 | 型 [値] | 説明 --------------+---------------+----------------------- bytesPerPixel | PIXEL | foreground-pixel-valueIf this bit is set then the SubrectsColoured bit must be zero. このビットがセットされる場合、SubrectsColoured ビットはゼロでなければならない。
No. of bytes | Type [Value] | Description -------------+--------------+------------------------ 1 | U8 | number-of-subrectangles
バイト数 | 型 [値] | 説明 -------------+--------------+------------------------ 1 | U8 | number-of-subrectanglesIf not set, there are no subrectangles (i.e. the whole tile is just solid background colour). セットされていない場合、子矩形はない(つまりタイル全体が単一の背景色ということである)。
No. of bytes | Type [Value] | Description --------------+--------------+-------------------- bytesPerPixel | PIXEL | subrect-pixel-value 1 | U8 | x-and-y-position 1 | U8 | width-and-height
バイト数 | 型 [値] | 説明 --------------+--------------+-------------------- bytesPerPixel | PIXEL | subrect-pixel-value 1 | U8 | x-and-y-position 1 | U8 | width-and-heightIf not set, all subrectangles are the same colour, the foreground colour; if the ForegroundSpecified bit wasn't set then the foreground is the same as the last tile. A subrectangle is: セットされていない場合、すべての子矩形は同じ前景色である。ForegroundSpecified ビットがセットされていない場合、前景色は最後のタイルと同じである。子矩形は以下の内容である：
No. of bytes | Type [Value] | Description -------------+--------------+----------------- 1 | U8 | x-and-y-position 1 | U8 | width-and-height
バイト数 | 型 [値] | 説明 -------------+--------------+----------------- 1 | U8 | x-and-y-position 1 | U8 | width-and-height
The position and size of each subrectangle is specified in two bytes, x-and-y-position and width-and-height. The most-significant four bits of x-and-y-position specify the X position, the least-significant specify the Y position. The most-significant four bits of width-and-height specify the width minus one, the least-significant specify the height minus one. 各子矩形の位置とサイズは、x-and-y-position および width-and-height の 2 バイトで表される。x-and-y-position の上位 4 ビットが X 座標を表し、下位 4 ビットが Y 座標を表す。width-and-height の上位 4 ビットが幅 - 1 を表し、下位 4 ビットが高さ - 1 を表す。
ZRLE stands for Zlib(see http://www.gzip.org/zlib/) Run-Length Encoding, and combines zlib compression, tiling, palettisation and run-length encoding. On the wire, the rectangle begins with a 4-byte length field, and is followed by that many bytes of zlib-compressed data. A single zlib "stream" object is used for a given RFB protocol connection, so that ZRLE rectangles must be encoded and decoded strictly in order. ZRLE は Zlib(参照) Run-Length Encoding を表し、zlib 圧縮・タイリング・パレット化・run-length エンコードの組合せである。矩形は 4 バイトのレングスフィールドで始まり、その後に zlib 圧縮されたバイトが続く。ZRLE の矩形は順番通り正確に圧縮・展開されなければならないため、ある特定のプロトコル接続のためには単一の zlib "ストリーム(stream)" オブジェクトが使用される。
No. of bytes | Type [Value] | Description -------------+------------------+------------ 4 | U32 | length length | U8 array | zlibData
バイト数 | 型 [値] | 説明 -------------+------------------+------------ 4 | U32 | length length | U8 array | zlibData
The zlibData when uncompressed represents tiles of 64x64 pixels in left-to-right, top-to-bottom order, similar to hextile. If the width of the rectangle is not an exact multiple of 64 then the width of the last tile in each row is smaller, and if the height of the rectangle is not an exact multiple of 64 then the height of each tile in the final row is smaller. 展開された zlibData は、左から右、上から下への順の 64 × 64 ピクセルのタイル群という Hextile に似た形式で表される。矩形の幅が 64 の正確な倍数ではない場合、各行の最後のタイルの幅がそれに合せて小さくなる。同じように矩形の高さが 64 の正確な倍数ではない場合、最後の行の各タイルの高さが小さくなる。
ZRLE makes use of a new type CPIXEL (compressed pixel). This is the same as a PIXEL for the agreed pixel format, except where true-colour-flag is non-zero, bits-per-pixel is 32, depth is 24 or less and all of the bits making up the red, green and blue intensities fit in either the least significant 3 bytes or the most significant 3 bytes. In this case a CPIXEL is only 3 bytes long, and contains the least significant or the most significant 3 bytes as appropriate. bytesPerCPixel is the number of bytes in a CPIXEL. ZRLE は新しい型 CPIXEL(圧縮ピクセル(compressed pixel)) を使用する。これは合意されたピクセル形式の PIXEL と同じである。ただし、true-colour-flag が非ゼロ、bits-per-pixel が 32、depth が 24 以下、そして赤・青・黄の強さを構成するすべてのビットが上位 3 バイトまたは下位 3 バイトのどちらかに置かれる場合は例外で、その場合の CPIXEL は 3 バイトのみとなり、必要に応じて下位 3 バイトまたは上位 3 バイトを含む。bytesPerCPixel は CPIXEL 内のバイト数である。
Each tile begins with a subencoding type byte. The top bit of this byte is set if the tile has been run-length encoded, clear otherwise. The bottom seven bits indicate the size of the palette used - zero means no palette, one means that the tile is of a single colour, 2 to 127 indicate a palette of that size. The possible values of subencoding are: 各タイルは subencoding タイプバイトで始まる。このバイトの上位 1 ビットは、そのタイルが run-length エンコードならセットされ、そうでなければクリアされる。下位 7 ビットは使用されているパレットのサイズを表す。0 はパレットが無いこと、1 はタイルが単一色であることを意味し、2 ? 127 はそのサイズのパレットであることを表す。subencoding に可能な値は以下の通り：
No. of bytes | Type [Value] | Description --------------------------------+----------------------+------------ width x height x bytesPerCPixel | CPIXEL array | pixels
バイト数 | 型 [値] | 説明 --------------------------------+----------------------+---------- width x height x bytesPerCPixel | CPIXEL array | pixels
No. of bytes | Type [Value] | Description ---------------+----------------+------------ bytesPerCPixel | CPIXEL | pixelValue
バイト数 | 型 [値] | 説明 ---------------+----------------+------------ bytesPerCPixel | CPIXEL | pixelValue
No. of bytes | Type [Value] | Description -----------------------------+----------------------+------------- paletteSize x bytesPerCPixel | CPIXEL array | palette m | U8 array | packedPixels
バイト数 | 型 [値] | 説明 -----------------------------+----------------------+------------- paletteSize x bytesPerCPixel | CPIXEL array | palette m | U8 array | packedPixelswhere m is the number of bytes representing the packed pixels. For paletteSize of 2 this is floor((width + 7) / 8) x height, for paletteSize of 3 or 4 this is floor((width+3) / 4) x height, for paletteSize of 5 to 16 this is floor((width+1) / 2) x height. m はパックされたピクセルを表すバイト数である。paletteSize が 2 の場合、これは floor (( width + 7) / 8) × height であり、paletteSize が 3 または 4 の場合は floor (( width + 3) / 4) × height、paletteSize が 5 ? 16 の場合は floor (( width + 1) / 2) × height である。
No. of bytes | Type [Value] | Description ---------------------------+------------------+-------------------- bytesPerCPixel | CPIXEL | pixelValue floor((runLength - 1)/255) | U8 array 255 | 1 | U8 | (runLength - 1)%255
バイト数 | 型 [値] | 説明 ---------------------------+-----------------+-------------------- bytesPerCPixel | CPIXEL | pixelValue floor((runLength - 1)/255) | U8 array 255 | 1 | U8 | (runLength - 1)%255
No. of bytes | Type [Value] | Description -----------------------------+----------------------+------------ paletteSize x bytesPerCPixel | CPIXEL array | palette
バイト数 | 型 [値] | 説明 -----------------------------+----------------------+------------ paletteSize x bytesPerCPixel | CPIXEL array | paletteThen as with plain RLE, consists of a number of runs, repeated until the tile is done. A run of length one is represented simply by a palette index: 次に純粋な RLE と同様、タイルの終了まで連続体が繰り返される。長さ 1 の連続体は単純にパレットインデックスによって表される：
No. of bytes | Type [Value] | Description -------------+--------------+------------- 1 | U8 | paletteIndex
バイト数 | 型 [値] | 説明 -------------+--------------+------------- 1 | U8 | paletteIndexA run of length more than one is represented by a palette index with the top bit set, followed by the length of the run as for plain RLE. 1 より大きい長さの連続体は上位ビットをセットされたパレットインデックスによって表され、次に純粋な RLE の場合と同様に連続体の長さが続く。
No. of bytes | Type [Value] | Description ---------------------------+------------------+-------------------- 1 | U8 | paletteIndex + 128 floor((runLength - 1)/255) | U8 array 255 | 1 | U8 | (runLength - 1)%255
バイト数 | 型 [値] | 説明 ---------------------------+-----------------+-------------------- 1 | U8 | paletteIndex + 128 floor((runLength - 1)/255) | U8 array 255 | 1 | U8 | (runLength - 1)%255
A client which requests the Cursor pseudo-encoding is declaring that it is capable of drawing a mouse cursor locally. This can significantly improve perceived performance over slow links. The server sets the cursor shape by sending a pseudo-rectangle with the Cursor pseudo-encoding as part of an update. The pseudo-rectangle's x-position and y-position indicate the hotspot of the cursor, and width and height indicate the width and height of the cursor in pixels. The data consists of width x height pixel values followed by a bitmask. The bitmask consists of left-to-right, top-to-bottom scanlines, where each scanline is padded to a whole number of bytes floor((width + 7)/8). Within each byte the most significant bit represents the leftmost pixel, with a 1-bit meaning the corresponding pixel in the cursor is valid. Cursor 擬似エンコードを要求するクライアントは、ローカルでマウスカーソルを描画する能力を持つことを宣言することになる。これは低速回線における体感速度をかなり向上させる。サーバーは、Cursor 擬似エンコードによる擬似矩形(pseudo-rectrangle)を更新の一部として送信することで、カーソルの形状を設定する。擬似矩形の x-position および y-position はカーソルのホットスポットを表し、width および height はカーソルの幅と高さとをピクセル単位で表す。データは width × height のピクセル値と、それに続くビットマスクから構成される。ビットマスクは左から右へ、上から下への走査線から構成され、各走査線は floor((width + 7)/8) のバイト数までパディングされる。各バイト内の最上位ビットが左端のピクセルを表し、ビット 1 はカーソル内の対応するピクセルが有効であることを表す。
No. of bytes | Type [Value] | Description -------------------------------+---------------------+-------------- width x height x bytesPerPixel | PIXEL array | cursor-pixels floor((width + 7)/8) * height | U8 array | bitmask
バイト数 | 型 [値] | 説明 -------------------------------+---------------------+-------------- width x height x bytesPerPixel | PIXEL array | cursor-pixels floor((width + 7)/8) * height | U8 array | bitmask
A client which requests the DesktopSize pseudo-encoding is declaring that it is capable of coping with a change in the framebuffer width and/or height. The server changes the desktop size by sending a pseudo-rectangle with the DesktopSize pseudo-encoding as the last rectangle in an update. The pseudo-rectangle's x-position and y-position are ignored, and width and height indicate the new width and height of the framebuffer. There is no further data associated with the pseudo-rectangle. DesktopSize 擬似エンコードを要求するクライアントは、フレームバッファの幅や高さの変更に対応する能力を持つと宣言することになる。サーバーは、DesktopSize 擬似エンコードによる擬似矩形を更新の最後の矩形として送信することで、デスクトップサイズを変更する。擬似矩形の x-position および y-position は無視され、width および height がフレームバッファの新しい幅と高さとを表す。この擬似矩形に関してこれ以上の情報はない。