[要約] RFC 6143は、リモートフレームバッファプロトコルに関する仕様であり、リモートデスクトップ接続を可能にするためのプロトコルです。目的は、クライアントとサーバー間でグラフィカルな情報を効率的に転送することです。
Internet Engineering Task Force (IETF) T. Richardson
Request for Comments: 6143 J. Levine
Category: Informational RealVNC Ltd.
ISSN: 2070-1721 March 2011
The Remote Framebuffer Protocol
リモートフレームバッファプロトコル
Abstract
概要
RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC.
RFB（「リモートフレームバッファー」）は、クライアントが別のコンピューター上のウィンドウシステムを表示および制御できるようにする、グラフィカルユーザーインターフェイスへのリモートアクセス用のシンプルなプロトコルです。 RFBはフレームバッファレベルで機能するため、すべてのウィンドウシステムとアプリケーションに適用できます。このドキュメントでは、RFBクライアントとRFBサーバー間の通信に使用されるプロトコルについて説明します。 RFBはVNCで使用されるプロトコルです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6143.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6143で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Initial Connection . . . . . . . . . . . . . . . . . . . . . . 4
3. Display Protocol . . . . . . . . . . . . . . . . . . . . . . . 4
4. Input Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Representation of Pixel Data . . . . . . . . . . . . . . . . . 5
6. Protocol Versions and Extensions . . . . . . . . . . . . . . . 6
7. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Handshake Messages . . . . . . . . . . . . . . . . . . . . 8
7.1.1. ProtocolVersion Handshake . . . . . . . . . . . . . . 8
7.1.2. Security Handshake . . . . . . . . . . . . . . . . . . 8
7.1.3. SecurityResult Handshake . . . . . . . . . . . . . . . 10
7.2. Security Types . . . . . . . . . . . . . . . . . . . . . . 10
7.2.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2.2. VNC Authentication . . . . . . . . . . . . . . . . . . 10
7.3. Initialization Messages . . . . . . . . . . . . . . . . . 11
7.3.1. ClientInit . . . . . . . . . . . . . . . . . . . . . . 11
7.3.2. ServerInit . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Pixel Format Data Structure . . . . . . . . . . . . . . . 12
7.5. Client-to-Server Messages . . . . . . . . . . . . . . . . 13
7.5.1. SetPixelFormat . . . . . . . . . . . . . . . . . . . . 13
7.5.2. SetEncodings . . . . . . . . . . . . . . . . . . . . . 14
7.5.3. FramebufferUpdateRequest . . . . . . . . . . . . . . . 15
7.5.4. KeyEvent . . . . . . . . . . . . . . . . . . . . . . . 16
7.5.5. PointerEvent . . . . . . . . . . . . . . . . . . . . . 19
7.5.6. ClientCutText . . . . . . . . . . . . . . . . . . . . 19
7.6. Server-to-Client Messages . . . . . . . . . . . . . . . . 20
7.6.1. FramebufferUpdate . . . . . . . . . . . . . . . . . . 20
7.6.2. SetColorMapEntries . . . . . . . . . . . . . . . . . . 21
7.6.3. Bell . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.6.4. ServerCutText . . . . . . . . . . . . . . . . . . . . 22
7.7. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 22
7.7.1. Raw Encoding . . . . . . . . . . . . . . . . . . . . . 23
7.7.2. CopyRect Encoding . . . . . . . . . . . . . . . . . . 23
7.7.3. RRE Encoding . . . . . . . . . . . . . . . . . . . . . 23
7.7.4. Hextile Encoding . . . . . . . . . . . . . . . . . . . 24
7.7.5. TRLE . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.7.6. ZRLE . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.8. Pseudo-Encodings . . . . . . . . . . . . . . . . . . . . . 30
7.8.1. Cursor Pseudo-Encoding . . . . . . . . . . . . . . . . 30
7.8.2. DesktopSize Pseudo-Encoding . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. RFB Security Types . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Registry Name . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 32
8.2. Client-to-Server Message Types . . . . . . . . . . . . . . 32
8.2.1. Registry Name . . . . . . . . . . . . . . . . . . . . 32
8.2.2. Registry Contents . . . . . . . . . . . . . . . . . . 32
8.3. Server-to-Client Message Types . . . . . . . . . . . . . . 33
8.3.1. Registry Name . . . . . . . . . . . . . . . . . . . . 33
8.3.2. Registry Contents . . . . . . . . . . . . . . . . . . 33
8.4. RFB Encoding Types . . . . . . . . . . . . . . . . . . . . 34
8.4.1. Registry Name . . . . . . . . . . . . . . . . . . . . 34
8.4.2. Registry Contents . . . . . . . . . . . . . . . . . . 34
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Differences in Earlier Protocol Versions . . . . . . 38
A.1. Differences in the Version 3.3 Protocol . . . . . . . . . 38
A.2. Differences in the Version 3.7 Protocol . . . . . . . . . 38
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. The protocol is widely implemented and has had fairly good interoperability.
RFB（「リモートフレームバッファ」）は、グラフィカルユーザーインターフェイスへのリモートアクセスのためのシンプルなプロトコルです。フレームバッファレベルで機能するため、X11、Windows、Macintoshを含むすべてのウィンドウシステムとアプリケーションに適用できます。 RFBはVNCで使用されるプロトコルです。プロトコルは広く実装されており、相互運用性はかなり良好です。
The remote endpoint where the user sits (typically with a display, keyboard, and 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 is 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は「シンクライアント」プロトコルです。 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 RFB protocol has evolved over the past decade, and has been implemented several times, including at least one open source version. This document describes the RFB protocol as actually implemented, so that future implementers can interoperate with existing clients and servers.
RFBプロトコルは過去10年間に進化し、少なくとも1つのオープンソースバージョンを含め、何度か実装されています。このドキュメントでは、実際に実装されたRFBプロトコルについて説明します。これにより、将来の実装者は既存のクライアントおよびサーバーと相互運用できます。
An RFB server is typically a long-lived process that maintains the state of a framebuffer. RFB clients typically connect, communicate with the server for a period of time to use and manipulate the framebuffer, then disconnect. A subsequent RFB session will then pick up where a prior session left off, with the state of the framebuffer intact.
RFBサーバーは通常、フレームバッファーの状態を維持する、長期間有効なプロセスです。 RFBクライアントは通常、接続してサーバーと一定期間通信し、フレームバッファを使用および操作してから切断します。後続のRFBセッションは、前のセッションが中断したところから再開し、フレームバッファーの状態はそのままです。
An RFB client contacts the server on TCP port 5900. On systems with multiple RFB servers, server N typically listens on port 5900+N, analogous to the way that X Window servers listen on port 6000+N.
RFBクライアントは、TCPポート5900でサーバーに接続します。複数のRFBサーバーがあるシステムでは、サーバーNは通常、ポート5900 + Nでリッスンします。これは、Xウィンドウサーバーがポート6000 + Nでリッスンする方法と似ています。
Some browser-based clients use a Java application to run the RFB protocol. RFB servers sometimes provide a simple HTTP server on port 5800 that provides the requisite Java applet.
一部のブラウザベースのクライアントは、Javaアプリケーションを使用してRFBプロトコルを実行します。 RFBサーバーは、必要なJavaアプレットを提供する単純なHTTPサーバーをポート5800で提供することがあります。
In some cases, the initial roles of the client and server are reversed, with the RFB client listening on port 5500, and the RFB server contacting the RFB client. Once the connection is established, the two sides take their normal roles, with the RFB server sending the first handshake message.
場合によっては、クライアントとサーバーの初期の役割が逆になり、RFBクライアントがポート5500でリッスンし、RFBサーバーがRFBクライアントに接続します。接続が確立されると、双方が通常の役割を果たし、RFBサーバーが最初のハンドシェイクメッセージを送信します。
Note that the only port number assigned by IANA for RFB is port 5900, so RFB clients and servers should avoid using other port numbers unless they are communicating with servers or clients known to use the non-standard ports.
IANAがRFBに割り当てるポート番号はポート5900だけなので、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". 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 speed, and server processing speed.
プロトコルの表示側は、「特定のx、y位置にピクセルデータの長方形を配置する」という単一のグラフィックスプリミティブに基づいています。これは、多くのユーザーインターフェイスコンポーネントを描画する非効率的な方法のように思えるかもしれません。ただし、ピクセルデータにさまざまな異なるエンコーディングを許可すると、ネットワーク帯域幅、クライアントの描画速度、サーバーの処理速度などのさまざまなパラメーターをトレードオフする方法に大きな柔軟性が与えられます。
A sequence of these rectangles makes a framebuffer update (simply referred to here as "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 but not always disjoint.
これらの長方形のシーケンスにより、フレームバッファが更新されます（ここでは単に「更新」と呼びます）。更新は、ある有効なフレームバッファーの状態から別の状態への変化を表すため、いくつかの点でビデオのフレームに似ています。更新の四角形は通常、ただし必ずしもそうではありませんがばらばらです。
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. With typical applications, changes to the same area of the framebuffer tend to happen soon after one another. With a slow client or network, transient states of the framebuffer can be ignored, resulting in less network traffic and less drawing for the client.
更新プロトコルは、クライアントによって要求駆動型です。つまり、更新は、クライアントからの明示的な要求に応答してサーバーからクライアントにのみ送信されます。これはプロトコルに適応品質を与えます。クライアントとネットワークの速度が遅いほど、更新率は低くなります。一般的なアプリケーションでは、フレームバッファの同じ領域への変更は、次々に発生する傾向があります。遅いクライアントまたはネットワークでは、フレームバッファの一時的な状態を無視できるため、クライアントのネットワークトラフィックと描画が少なくなります。
After the initial handshake sequence, the protocol is asynchronous, with each side sending messages as needed. The server must not send unsolicited updates. An update must only be sent in response to a request from the client. When several requests from the client are outstanding, a single update from the server may satisfy all of them.
最初のハンドシェイクシーケンスの後、プロトコルは非同期になり、各サイドは必要に応じてメッセージを送信します。サーバーは、一方的な更新を送信してはなりません。更新は、クライアントからの要求に応答してのみ送信する必要があります。クライアントからのいくつかの要求が未解決の場合、サーバーからの単一の更新でそれらすべてを満たすことができます。
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 synthesized from other non-standard I/O devices. For example, a pen-based handwriting recognition engine might generate keyboard events.
プロトコルの入力側は、キーボードとマルチボタンポインティングデバイスの標準ワークステーションモデルに基づいています。入力イベントは、ユーザーがキーまたはポインターボタンを押すたび、またはポインティングデバイスが移動されるたびに、クライアントによってサーバーに送信されるだけです。これらの入力イベントは、他の非標準I / Oデバイスから合成することもできます。たとえば、ペンベースの手書き認識エンジンがキーボードイベントを生成する場合があります。
Initial interaction between the RFB client and server involves a negotiation of the format and encoding of the pixel data that will be sent. This negotiation has been designed to make the job of the client as easy as possible. 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 that is easier for the server to produce.
RFBクライアントとサーバー間の最初の対話には、送信されるピクセルデータの形式とエンコードのネゴシエーションが含まれます。この交渉は、クライアントの仕事をできるだけ簡単にするように設計されています。サーバーは常に、クライアントが望む形式でピクセルデータを提供できなければなりません。ただし、クライアントが複数の異なるフォーマットまたはエンコーディングに等しく対応できる場合は、サーバーが生成する方が簡単なものを選択できます。
Pixel format refers to the representation of individual colors by pixel values. The most common pixel formats are 24-bit or 16-bit "true color", where bit-fields within the pixel value translate directly to red, green, and blue intensities, and 8-bit "color map" (palette) where the pixel values are indices into a 256-entry table that contains the actual RGB intensities.
ピクセル形式は、ピクセル値による個々の色の表現を指します。最も一般的なピクセル形式は、24ビットまたは16ビットの「トゥルーカラー」で、ピクセル値内のビットフィールドは赤、緑、青の強度に直接変換され、8ビットの「カラーマップ」（パレット）はピクセル値は、実際のRGB強度を含む256エントリのテーブルへのインデックスです。
Encoding refers to the way that a rectangle of pixel data will be sent to the client. 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位置、四角形の幅と高さ、およびピクセルデータのエンコードを指定するエンコードタイプを示すヘッダーが先頭に付きます。次に、指定されたエンコーディングを使用してデータ自体が続きます。
The encoding types defined at present are: Raw, CopyRect, RRE, TRLE, Hextile, and ZRLE. In practice, current servers use the ZRLE, TRLE, and CopyRect encodings since they provide the best compression for typical desktops. Clients generally also support Hextile, which was often used by older RFB servers that didn't support TRLE. See Section 7.7 for a description of each of the encodings.
現在定義されているエンコードタイプは、Raw、CopyRect、RRE、TRLE、Hextile、およびZRLEです。実際には、現在のサーバーはZRLE、TRLE、およびCopyRectエンコーディングを使用しています。これらのエンコーディングは、一般的なデスクトップに最適な圧縮を提供するためです。クライアントは通常、Hextileもサポートします。Hextileは、TRLEをサポートしていない古いRFBサーバーでよく使用されていました。各エンコーディングの説明については、7.7項を参照してください。
The RFB protocol has evolved through three published versions: 3.3, 3.7, and 3.8. This document primarily documents the final version 3.8; differences from the earlier versions, which are minor, are described in Appendix A. Under no circumstances should an implementation use a protocol version number other than one defined in this document. Over the years, different implementations of RFB have attempted to use different version numbers to add undocumented extensions, with the result being that to interoperate, any unknown 3.x version must be treated as 3.3, so it is not possible to add a 3.9 or higher version in a backward-compatible fashion. Future evolution of RFB will use 4.x version numbers.
RFBプロトコルは、公開されている3つのバージョン3.3、3.7、および3.8を通じて進化しました。このドキュメントは主に最終バージョン3.8について説明しています。マイナーな以前のバージョンとの違いについては、付録Aで説明します。いかなる場合でも、実装では、このドキュメントで定義されているもの以外のプロトコルバージョン番号を使用しないでください。長年にわたり、RFBの異なる実装では、ドキュメント化されていない拡張を追加するために異なるバージョン番号を使用することを試みてきました。その結果、相互運用するには、不明な3.xバージョンを3.3として扱う必要があるため、3.9または下位互換性のある方法で上位バージョン。 RFBの将来の進化では、4.xバージョン番号を使用します。
It is not necessary to change the protocol version number to extend the protocol. The protocol can be extended within an existing version by:
プロトコルを拡張するためにプロトコルバージョン番号を変更する必要はありません。このプロトコルは、次の方法で既存のバージョン内で拡張できます。
New encodings A new encoding type can be added to the protocol relatively easily while maintaining compatibility with existing clients and servers. Existing servers will simply ignore requests for a new encoding that they don't support. Existing clients will never request the new encoding so will never see rectangles encoded that way.
新しいエンコーディング新しいエンコーディングタイプは、既存のクライアントおよびサーバーとの互換性を維持しながら、比較的簡単にプロトコルに追加できます。既存のサーバーは、サポートしていない新しいエンコーディングのリクエストを単に無視します。既存のクライアントは新しいエンコーディングを要求しないので、そのようにエンコードされた四角形は表示されません。
Pseudo-encodings In addition to genuine encodings, a client can request a "pseudo-encoding" to declare to the server that it supports a certain extension to the protocol. A server that 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. See Section 7.8 for a description of current pseudo-encodings.
擬似エンコーディング正規のエンコーディングに加えて、クライアントは「擬似エンコーディング」を要求して、プロトコルの特定の拡張をサポートすることをサーバーに宣言できます。拡張機能をサポートしないサーバーは、疑似エンコーディングを単に無視します。これは、クライアントがサーバーから拡張機能固有の確認を取得するまで、サーバーが拡張機能をサポートしていないと想定する必要があることに注意してください。現在の疑似エンコーディングの説明については、セクション7.8を参照してください。
New security types Adding a new security type gives full flexibility in modifying the behavior of the protocol without sacrificing compatibility with existing clients and servers. A client and server that agree on a new security type can effectively talk whatever protocol they like after that -- it doesn't necessarily have to be anything like the RFB protocol.
新しいセキュリティタイプ新しいセキュリティタイプを追加すると、既存のクライアントやサーバーとの互換性を犠牲にすることなく、プロトコルの動作を柔軟に変更できます。新しいセキュリティタイプに同意するクライアントとサーバーは、その後、好きなプロトコルを効果的に話すことができます。必ずしもRFBプロトコルのようなものである必要はありません。
See Section 8 for information on obtaining an ID for a new encoding or security type.
新しいエンコーディングまたはセキュリティタイプのIDを取得する方法については、セクション8を参照してください。
The RFB protocol can operate over any reliable transport, either byte-stream or message based. It usually operates 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 initialization 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 message-specific data.
RFBプロトコルは、バイトストリームまたはメッセージベースの信頼性の高いトランスポート上で動作できます。通常、TCP / IP接続で動作します。プロトコルには3つの段階があります。最初はハンドシェイクフェーズです。その目的は、プロトコルバージョンと使用するセキュリティのタイプについて合意することです。 2番目の段階は、クライアントとサーバーがClientInitおよびServerInitメッセージを交換する初期化フェーズです。最後の段階は、通常のプロトコルの相互作用です。クライアントは必要なメッセージを送信でき、結果としてサーバーからメッセージを受信できます。これらのメッセージはすべて、メッセージタイプのバイトで始まり、その後にメッセージ固有のデータが続きます。
The following descriptions of protocol messages use the basic types U8, U16, U32, S8, S16, and 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). Some messages use arrays of the basic types, with the number of entries in the array determined from fields preceding the array.
以下のプロトコルメッセージの説明では、基本タイプU8、U16、U32、S8、S16、およびS32を使用しています。これらはそれぞれ、8、16、および32ビットの符号なし整数と、8、16、および32ビットの符号付き整数を表します。すべてのマルチバイト整数（ピクセル値自体を除く）はビッグエンディアン順（最上位バイトが最初）です。一部のメッセージは、基本タイプの配列を使用し、配列内のエントリの数は、配列の前のフィールドから決定されます。
The type PIXEL means a pixel value of bytesPerPixel bytes, where bytesPerPixel is the number of bits-per-pixel divided by 8. The bits-per-pixel is agreed by the client and server, either in the ServerInit message (Section 7.3.2) or a SetPixelFormat message (Section 7.5.1). See Section 7.4 for the detailed description of the pixel format.
タイプPIXELは、bytesPerPixelバイトのピクセル値を意味します。ここで、bytesPerPixelは、ピクセルあたりのビット数を8で除算したものです。ピクセルあたりのビット数は、ServerInitメッセージでクライアントとサーバーによって合意されます（セクション7.3.2 ）またはSetPixelFormatメッセージ（セクション7.5.1）。ピクセル形式の詳細な説明については、セクション7.4を参照してください。
Several message formats include padding bits or bytes. For maximum compatibility, messages should be generated with padding set to zero, but message recipients should not assume padding has any particular value.
いくつかのメッセージ形式には、ビットまたはバイトの埋め込みが含まれます。互換性を最大にするために、メッセージはパディングをゼロに設定して生成する必要がありますが、メッセージ受信者はパディングに特定の値があると想定しないでください。
When an RFB client and server first connect, they exchange a sequence of handshake messages that determine the protocol version, what type of connection security (if any) to use, a password check if the security type requires it, and some initialization information.
RFBクライアントとサーバーが最初に接続するとき、プロトコルバージョン、使用する接続セキュリティのタイプ（存在する場合）、セキュリティタイプで必要かどうかのパスワードチェック、および初期化情報を決定する一連のハンドシェイクメッセージを交換します。
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 that 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, and 3.8. Other version numbers are reported by some servers and clients, but should be interpreted as 3.3 since they do not implement the different handshake in 3.7 or 3.8. 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.7または3.8で異なるハンドシェイクを実装していないため、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, left-padded with zeros:
ProtocolVersionメッセージは、「RFB xxx.yyy \ n」形式のASCII文字列として解釈される12バイトで構成されます。ここで、xxxとyyyは、左側にゼロが埋め込まれたメジャーバージョン番号とマイナーバージョン番号です。
RFB 003.008\n (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)
RFB 003.008 \ n（16進数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. The server lists the security types that it supports:
プロトコルのバージョンが決定したら、サーバーとクライアントは、接続で使用するセキュリティの種類について合意する必要があります。サーバーは、サポートするセキュリティタイプをリストします。
+--------------------------+-------------+--------------------------+
| No. of bytes | Type | Description |
| | [Value] | |
+--------------------------+-------------+--------------------------+
| 1 | U8 | number-of-security-types |
| number-of-security-types | U8 array | security-types |
+--------------------------+-------------+--------------------------+
If 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 |
+--------------+--------------+---------------+
If 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 |
+---------------+--------------+---------------+
The server closes the connection after sending the reason-string.
サーバーは、reason-stringを送信した後、接続を閉じます。
The security types defined in this document are:
このドキュメントで定義されているセキュリティタイプは次のとおりです。
+--------+--------------------+
| Number | Name |
+--------+--------------------+
| 0 | Invalid |
| 1 | None |
| 2 | VNC Authentication |
+--------+--------------------+
Other security types exist but are not publicly documented.
他のセキュリティタイプは存在しますが、公開されていません。
Once the security-type has been decided, data specific to that security-type follows (see Section 7.2 for details). At the end of the security handshaking phase, the protocol normally continues with the SecurityResult message.
セキュリティタイプが決定すると、そのセキュリティタイプに固有のデータが続きます（詳細については、セクション7.2を参照してください）。セキュリティハンドシェイクフェーズの最後に、プロトコルは通常SecurityResultメッセージを続けます。
Note that after the security handshaking phase, it is possible that further communication is over an encrypted or otherwise altered channel if the two ends agree on an extended security type beyond the ones described here.
セキュリティハンドシェイクフェーズの後、両端がここで説明したもの以外の拡張セキュリティタイプに同意する場合、暗号化されたチャネルまたは変更されたチャネルを介してさらに通信が行われる可能性があることに注意してください。
The server sends a word to inform the client whether the security handshaking was successful.
サーバーは、セキュリティハンドシェイクが成功したかどうかをクライアントに通知するための単語を送信します。
+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 4 | U32 | status: |
| | 0 | OK |
| | 1 | failed |
+--------------+--------------+-------------+
If successful, the protocol passes to the initialization phase (Section 7.3).
成功した場合、プロトコルは初期化フェーズ（セクション7.3）に進みます。
If unsuccessful, the server sends a string describing the reason for the failure, and then closes the connection:
失敗した場合、サーバーは失敗の理由を説明する文字列を送信し、接続を閉じます。
+---------------+--------------+---------------+
| No. of bytes | Type [Value] | Description |
+---------------+--------------+---------------+
| 4 | U32 | reason-length |
| reason-length | U8 array | reason-string |
+---------------+--------------+---------------+
Two security types are defined here.
ここでは、2つのセキュリティタイプが定義されています。
No authentication is needed. The protocol continues with the SecurityResult message.
認証は必要ありません。プロトコルはSecurityResultメッセージを続けます。
VNC authentication is to be used. The server sends a random 16-byte challenge:
VNC認証が使用されます。サーバーはランダムな16バイトのチャレンジを送信します。
+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 16 | U8 | challenge |
+--------------+--------------+-------------+
The client encrypts the challenge with DES, using a password supplied by the user as the key. To form the key, the password is truncated to eight characters, or padded with null bytes on the right. The client then sends the resulting 16-byte response:
クライアントは、ユーザーが指定したパスワードをキーとして使用して、チャレンジをDESで暗号化します。キーを形成するために、パスワードは8文字に切り捨てられるか、右側にヌルバイトが埋め込まれます。次に、クライアントは結果の16バイトの応答を送信します。
+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 16 | U8 | response |
+--------------+--------------+-------------+
The protocol continues with the SecurityResult message.
プロトコルはSecurityResultメッセージを続けます。
This type of authentication is known to be cryptographically weak and is not intended for use on untrusted networks. Many implementations will want to use stronger security, such as running the session over an encrypted channel provided by IPsec [RFC4301] or SSH [RFC4254].
このタイプの認証は、暗号学的に脆弱であることが知られており、信頼できないネットワークでの使用を目的としていません。多くの実装では、IPsec [RFC4301]またはSSH [RFC4254]によって提供される暗号化されたチャネルを介してセッションを実行するなど、より強力なセキュリティを使用する必要があります。
Once the client and server agree on and perhaps validate a security type, the protocol passes to the initialization stage. The client sends a ClientInit message. Then, the server sends a ServerInit message.
クライアントとサーバーが同意してセキュリティタイプを検証すると、プロトコルは初期化段階に進みます。クライアントはClientInitメッセージを送信します。次に、サーバーはServerInitメッセージを送信します。
+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 1 | U8 | shared-flag |
+--------------+--------------+-------------+
Shared-flag is non-zero (true) if the server should try to share the desktop by leaving other clients connected, and zero (false) if it should give exclusive access to this client by disconnecting all other clients.
Shared-flagは、サーバーが他のクライアントを接続したままにしてデスクトップを共有しようとする場合はゼロ以外（true）であり、他のすべてのクライアントを切断してこのクライアントへの排他的アクセスを提供する場合は0（false）です。
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 in pixels |
| 2 | U16 | framebuffer-height in pixels |
| 16 | PIXEL_FORMAT | server-pixel-format |
| 4 | U32 | name-length |
| name-length | U8 array | name-string |
+--------------+--------------+------------------------------+
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 7.5.1).
server-pixel-formatは、サーバーの自然なピクセル形式を指定します。このピクセルフォーマットは、クライアントがSetPixelFormatメッセージを使用して別のフォーマットを要求しない限り使用されます（セクション7.5.1）。
Several server-to-client messages include a PIXEL_FORMAT, a 16-byte structure that describes the way a pixel is transmitted.
いくつかのサーバーからクライアントへのメッセージには、ピクセルが送信される方法を記述する16バイトの構造であるPIXEL_FORMATが含まれています。
+--------------+--------------+-----------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-----------------+
| 1 | U8 | bits-per-pixel |
| 1 | U8 | depth |
| 1 | U8 | big-endian-flag |
| 1 | U8 | true-color-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 |
+--------------+--------------+-----------------+
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. Big-endian-flag is non-zero (true) if multi-byte pixels are interpreted as big endian. Although the depth should be consistent with the bits-per-pixel and the various -max values, clients do not use it when interpreting pixel data.
ピクセルあたりのビット数は、ワイヤ上の各ピクセル値に使用されるビット数です。これは、ピクセル値の有効ビット数である深さ以上である必要があります。現在のところ、ピクセルあたりのビット数は8、16、または32である必要があります。マルチバイトピクセルがビッグエンディアンとして解釈される場合、ビッグエンディアンフラグはゼロ以外（true）です。深度はピクセルあたりのビット数およびさまざまな-max値と一致する必要がありますが、クライアントはピクセルデータを解釈するときにそれを使用しません。
If true-color-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 and must be 2^N - 1, where N is the number of bits used for red. Note the -max values are 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, blue-max, and 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-color-flagがゼロ以外（true）の場合、最後の6つの項目は、ピクセル値から赤、緑、青の強度を抽出する方法を指定します。 Red-maxは最大の赤の値であり、2 ^ N-1でなければなりません。Nは赤に使用されるビット数です。 -max値は常にビッグエンディアン順であることに注意してください。赤シフトは、ピクセルの赤の値を最下位ビットにするために必要なシフトの数です。グリーンマックス、グリーンシフト、ブルーマックス、ブルーシフトは、グリーンとブルーで同様です。たとえば、特定のピクセルから赤の値（0とred-maxの間）を見つけるには、次のようにします。
o Swap the pixel value according to big-endian-flag, e.g., if big-endian-flag is zero (false) and host byte order is big endian, then swap.
o ビッグエンディアンフラグに従ってピクセル値をスワップします。たとえば、ビッグエンディアンフラグがゼロ（false）で、ホストのバイトオーダーがビッグエンディアンの場合、スワップします。
o Shift right by red-shift.
o レッドシフトで右シフト。
o AND with red-max (in host byte order).
o AND-max（ホストのバイト順）。
If true-color-flag is zero (false), then the server uses pixel values that are not directly composed from the red, green, and blue intensities, but serve as indices into a color map. Entries in the color map are set by the server using the SetColorMapEntries message (See Section 7.6.2).
true-color-flagがゼロ（false）の場合、サーバーは赤、緑、青の強度から直接構成されていないピクセル値を使用しますが、カラーマップへのインデックスとして機能します。カラーマップのエントリは、SetColorMapEntriesメッセージを使用してサーバーによって設定されます（セクション7.6.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 |
+--------+--------------------------+
Other message types exist but are not publicly documented. Before sending a message other than those described in this document, a client must have determined that the server supports the relevant extension by receiving an appropriate extension-specific confirmation from the server.
他のメッセージタイプが存在しますが、公開されていません。このドキュメントで説明されている以外のメッセージを送信する前に、クライアントは、サーバーから適切な拡張機能固有の確認を受信することにより、サーバーが関連する拡張機能をサポートしていることを確認しておく必要があります。
A SetPixelFormat message 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 7.3.2).
SetPixelFormatメッセージは、FramebufferUpdateメッセージでピクセル値が送信されるフォーマットを設定します。クライアントがSetPixelFormatメッセージを送信しない場合、サーバーはServerInitメッセージ（セクション7.3.2）で指定されている自然な形式でピクセル値を送信します。
If true-color-flag is zero (false), then this indicates that a "color map" is to be used. The server can set any of the entries in the color map using the SetColorMapEntries message (Section 7.6.2). Immediately after the client has sent this message, the contents of the color map are undefined, even if entries had previously been set by the server.
true-color-flagがゼロ（false）の場合、これは「カラーマップ」が使用されることを示します。サーバーは、SetColorMapEntriesメッセージ（セクション7.6.2）を使用して、カラーマップの任意のエントリを設定できます。クライアントがこのメッセージを送信した直後は、以前にサーバーによってエントリが設定されていたとしても、カラーマップの内容は定義されていません。
+--------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+--------------+
| 1 | U8 [0] | message-type |
| 3 | | padding |
| 16 | PIXEL_FORMAT | pixel-format |
+--------------+--------------+--------------+
PIXEL_FORMAT is as described in Section 7.4.
PIXEL_FORMATはセクション7.4で説明されています。
A SetEncodings message 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.
SetEncodingsメッセージは、サーバーがピクセルデータを送信できるエンコードタイプを設定します。このメッセージで指定されたエンコーディングタイプの順序は、そのプリファレンスに関するクライアントからのヒントです（指定された最初のエンコーディングが最も好ましい）。サーバーは、このヒントを使用することを選択する場合としない場合があります。ここで明示的に指定されていなくても、ピクセルデータは常に未加工のエンコードで送信される場合があります。
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 that 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.
本物のエンコーディングに加えて、クライアントは「疑似エンコーディング」を要求して、プロトコルの特定の拡張をサポートすることをサーバーに宣言できます。拡張機能をサポートしないサーバーは、疑似エンコーディングを単に無視します。これは、クライアントがサーバーから拡張機能固有の確認を取得するまで、サーバーが拡張機能をサポートしていないと想定する必要があることに注意してください。
See Section 7.7 for a description of each encoding and Section 7.8 for the meaning of pseudo-encodings.
各エンコーディングの説明についてはセクション7.7を、疑似エンコーディングの意味についてはセクション7.8を参照してください。
+--------------+--------------+---------------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+---------------------+
| 1 | U8 [2] | message-type |
| 1 | | padding |
| 2 | U16 | number-of-encodings |
+--------------+--------------+---------------------+
This is followed by number-of-encodings repetitions of the following:
これに続いて、次のエンコード数の繰り返しが続きます。
+--------------+--------------+---------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+---------------+
| 4 | S32 | encoding-type |
+--------------+--------------+---------------+
A FramebufferUpdateRequest message 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. A single FramebufferUpdate may be sent in reply to several FramebufferUpdateRequests.
FramebufferUpdateRequestメッセージは、クライアントがx位置、y位置、幅、高さで指定されたフレームバッファの領域に関心があることをサーバーに通知します。サーバーは通常、FramebufferUpdateを送信して、FramebufferUpdateRequestに応答します。単一のFramebufferUpdateは、複数のFramebufferUpdateRequestに応答して送信される場合があります。
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.
サーバーは、クライアントが関係するフレームバッファーのすべての部分のコピーを保持していると想定します。つまり、通常、サーバーはクライアントに増分更新を送信するだけで済みます。
If the client has lost the contents of a particular area that 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.
クライアントが必要な特定の領域のコンテンツを失った場合、クライアントは増分がゼロ（false）に設定された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.
クライアントが関心のある領域のコンテンツを失っていない場合は、増分がゼロ以外（true）に設定された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 excessive network traffic.
高速クライアントの場合、クライアントは、過度のネットワークトラフィックを回避するために、増分FramebufferUpdateRequestsを送信するレートを調整したい場合があります。
+--------------+--------------+--------------+
| 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 |
+--------------+--------------+--------------+
A KeyEvent message indicates a key press or release. Down-flag is non-zero (true) if the key is now pressed, and zero (false) if it is now released. The key itself is specified using the "keysym" values defined by the X Window System, even if the client or server is not running the X Window System.
KeyEventメッセージは、キーの押下またはリリースを示します。キーが現在押されている場合、ダウンフラグはゼロ以外（true）であり、解放されている場合はゼロ（false）です。キー自体は、クライアントまたはサーバーがXウィンドウシステムを実行していない場合でも、Xウィンドウシステムによって定義された「keysym」値を使用して指定されます。
+--------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+--------------+
| 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 [XLIBREF] or see the header file <X11/keysymdef.h> in the X Window System distribution. Some other common keys are:
ほとんどの通常のキーでは、keysymは対応するASCII値と同じです。詳細については、[XLIBREF]を参照するか、X Window Systemディストリビューションのヘッダーファイル<X11 / keysymdef.h>を参照してください。その他の一般的なキーは次のとおりです。
+-----------------+--------------------+
| Key name | Keysym value (hex) |
+-----------------+--------------------+
| BackSpace | 0xff08 |
| Tab | 0xff09 |
| Return or Enter | 0xff0d |
| Escape | 0xff1b |
| Insert | 0xff63 |
| Delete | 0xffff |
| Home | 0xff50 |
| End | 0xff57 |
| Page Up | 0xff55 |
| Page Down | 0xff56 |
| Left | 0xff51 |
| Up | 0xff52 |
| Right | 0xff53 |
| Down | 0xff54 |
| F1 | 0xffbe |
| F2 | 0xffbf |
| F3 | 0xffc0 |
| F4 | 0xffc1 |
| ... | ... |
| F12 | 0xffc9 |
| Shift (left) | 0xffe1 |
| Shift (right) | 0xffe2 |
| Control (left) | 0xffe3 |
| Control (right) | 0xffe4 |
| Meta (left) | 0xffe7 |
| Meta (right) | 0xffe8 |
| Alt (left) | 0xffe9 |
| Alt (right) | 0xffea |
+-----------------+--------------------+
The interpretation of keysyms is a complex area. In order to be as widely interoperable as possible, the following guidelines should be followed:
キーシムの解釈は複雑な領域です。できるだけ広く相互運用できるようにするために、次のガイドラインに従う必要があります。
o The "shift state" (i.e., whether either of the Shift keysyms is down) should only be used as a hint when interpreting a keysym. For example, on a US keyboard the '#' character is shifted, but on a UK keyboard it is not. A server with a US keyboard receiving a '#' character from a client with a UK keyboard will not have been sent any shift presses. In this case, it is likely that the server will internally need to simulate a shift press on its local system in order to get a '#' character and not a '3'.
o 「シフト状態」（つまり、Shiftキーシムのいずれかが押されているかどうか）は、キーシムを解釈するときのヒントとしてのみ使用してください。たとえば、USキーボードでは '＃'文字はシフトされますが、UKキーボードではシフトされません。 USキーボードを備えたサーバーがUKキーボードを備えたクライアントから「＃」文字を受け取ると、シフトプレスは送信されません。この場合、「3」ではなく「＃」文字を取得するために、サーバーがローカルシステムでシフトプレスを内部的にシミュレートする必要がある可能性があります。
o The difference between upper and lower case keysyms is significant. This is unlike some of the keyboard processing in the X Window System that treats them as the same. For example, a server receiving an upper case 'A' keysym without any shift presses should interpret it as an upper case 'A'. Again this may involve an internal simulated shift press.
o 大文字と小文字のキーシムの違いは重要です。これは、X Window Systemで同じように処理するキーボード処理の一部とは異なります。たとえば、Shiftキーを押さずに大文字の「A」キーシムを受け取ったサーバーは、大文字の「A」として解釈する必要があります。この場合も、内部シミュレーションシフトプレスが必要になる場合があります。
o Servers should ignore "lock" keysyms such as CapsLock and NumLock where possible. Instead, they should interpret each character-based keysym according to its case.
o サーバーは、可能な場合、CapsLockやNumLockなどの「ロック」キーシムを無視する必要があります。代わりに、ケースに応じて各文字ベースのキーシムを解釈する必要があります。
o Unlike Shift, the state of modifier keys such as Control and Alt should be taken as modifying the interpretation of other keysyms. Note that there are no keysyms for ASCII control characters such as Ctrl-A -- these should be generated by clients sending a Control press followed by an 'a' press.
o Shiftとは異なり、ControlやAltなどの修飾キーの状態は、他のキーシムの解釈を変更するものとして解釈されるべきです。 Ctrl-AなどのASCII制御文字にはキーシムがないことに注意してください。これらは、Ctrlキーを押した後に「a」キーを押すクライアントによって生成される必要があります。
o On a client where modifiers like Control and Alt can also be used to generate character-based keysyms, the client may need to send extra "release" events in order that the keysym is interpreted correctly. For example, on a German PC keyboard, Ctrl-Alt-Q generates the '@' character. In this case, the client needs to send simulated release events for Control and Alt in order that the '@' character is interpreted correctly, since Ctrl-Alt-@ may mean something completely different to the server.
o ControlやAltなどの修飾子を使用して文字ベースのキーシムを生成することもできるクライアントでは、キーシムが正しく解釈されるように、クライアントは追加の「解放」イベントを送信する必要がある場合があります。たとえば、ドイツ語のPCキーボードでは、Ctrl-Alt-Qは「@」文字を生成します。この場合、Ctrl-Alt- @はサーバーとはまったく異なるものを意味する可能性があるため、「@」文字が正しく解釈されるように、クライアントはControlおよびAltのシミュレートされたリリースイベントを送信する必要があります。
o There is no universal standard for "backward tab" in the X Window System. On some systems shift+tab gives the keysym "ISO_Left_Tab", on others it gives a private "BackTab" keysym, and on others it gives "Tab" and applications tell from the shift state that it means backward-tab rather than forward-tab. In the RFB protocol, the latter approach is preferred. Clients should generate a shifted Tab rather than ISO_Left_Tab. However, to be backwards-compatible with existing clients, servers should also recognize ISO_Left_Tab as meaning a shifted Tab.
o X Window Systemには、「後方タブ」の普遍的な標準はありません。一部のシステムでは、shift + tabはキーシム「ISO_Left_Tab」を提供し、他のシステムではプライベート「BackTab」キーシムを提供し、他のシステムでは「Tab」を提供し、アプリケーションはシフト状態からフォワードタブではなく後方タブを意味することを通知します。 RFBプロトコルでは、後者のアプローチが推奨されます。クライアントは、ISO_Left_Tabではなく、シフトされたタブを生成する必要があります。ただし、既存のクライアントとの下位互換性を保つために、サーバーはISO_Left_Tabをシフトされたタブを意味するものとして認識する必要もあります。
o Modern versions of the X Window System handle keysyms for Unicode characters, consisting of the Unicode character with the hex 1000000 bit set. For maximum compatibility, if a key has both a Unicode and a legacy encoding, clients should send the legacy encoding.
o X Window Systemの最新バージョンは、16進数の1000000ビットが設定されたUnicode文字で構成されるUnicode文字のキーシムを処理します。互換性を最大にするために、キーにUnicodeとレガシーエンコーディングの両方がある場合、クライアントはレガシーエンコーディングを送信する必要があります。
o Some systems give a special interpretation to key combinations such as Ctrl-Alt-Delete. RFB clients typically provide a menu or toolbar function to send such key combinations. The RFB protocol does not treat them specially; to send Ctrl-Alt-Delete, the client sends the key presses for left or right Control, left or right Alt, and Delete, followed by the key releases. Many RFB servers accept Shift-Ctrl-Alt-Delete as a synonym for Ctrl-Alt-Delete that can be entered directly from the keyboard.
o一部のシステムは、Ctrl-Alt-Deleteなどのキーの組み合わせに特別な解釈を与えます。 RFBクライアントは通常、このようなキーの組み合わせを送信するためのメニューまたはツールバー機能を提供します。 RFBプロトコルはそれらを特別に扱いません。 Ctrl-Alt-Deleteを送信するには、クライアントは左または右のControl、左または右のAlt、Deleteのキープレスを送信し、その後にキーを離します。多くのRFBサーバーは、キーボードから直接入力できるCtrl-Alt-Deleteの同義語としてShift-Ctrl-Alt-Deleteを受け入れます。
A PointerEvent message 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 means up, 1 means down (pressed).
PointerEventメッセージは、ポインターの動きまたはポインターボタンの押し下げを示します。ポインタは（x位置、y位置）にあり、ボタン1〜8の現在の状態は、それぞれボタンマスクのビット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 |
+--------------+--------------+--------------+
RFB provides limited support for synchronizing the "cut buffer" of selected text between client and server. This message tells the server that the client has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the newline character (hex 0a) alone. No carriage-return (hex 0d) is used. There is no way to transfer text outside the Latin-1 character set.
RFBは、クライアントとサーバー間で選択したテキストの「カットバッファー」を同期するための限定的なサポートを提供します。このメッセージは、クライアントのカットバッファーに新しいISO 8859-1（Latin-1）テキストがあることをサーバーに通知します。行末は改行文字（16進0a）だけで表されます。キャリッジリターン（16進0d）は使用されません。 Latin-1文字セットの外にテキストを転送する方法はありません。
+--------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+--------------+
| 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 | SetColorMapEntries |
| 2 | Bell |
| 3 | ServerCutText |
+--------+--------------------+
Other private message types exist but are not publicly documented. Before sending a message other than those described 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 that 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 |
+--------------+--------------+----------------------+
This header is followed by number-of-rectangles rectangles of pixel data. Each rectangle starts with a rectangle header:
このヘッダーの後には、ピクセルデータの長方形の数の長方形が続きます。各長方形は長方形ヘッダーで始まります：
+--------------+--------------+---------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+---------------+
| 2 | U16 | x-position |
| 2 | U16 | y-position |
| 2 | U16 | width |
| 2 | U16 | height |
| 4 | S32 | encoding-type |
+--------------+--------------+---------------+
The rectangle header is followed by the pixel data in the specified encoding. See Section 7.7 for the format of the data for each encoding and Section 7.8 for the meaning of pseudo-encodings.
長方形のヘッダーの後に、指定されたエンコーディングのピクセルデータが続きます。各エンコーディングのデータ形式についてはセクション7.7を、疑似エンコーディングの意味についてはセクション7.8を参照してください。
When the pixel format uses a "color map", this message tells the client that the specified pixel values should be mapped to the given RGB values. Note that this message may only update part of the color map. This message should not be sent by the server until after the client has sent at least one FramebufferUpdateRequest, and only when the agreed pixel format uses a color map.
ピクセル形式が「カラーマップ」を使用する場合、このメッセージは、指定されたピクセル値を指定されたRGB値にマップする必要があることをクライアントに通知します。このメッセージは、カラーマップの一部のみを更新する場合があることに注意してください。このメッセージは、クライアントが少なくとも1つのFramebufferUpdateRequestを送信した後、合意されたピクセル形式がカラーマップを使用する場合にのみ、サーバーによって送信されるべきではありません。
Color map values are always 16 bits, with the range of values running from 0 to 65535, regardless of the display hardware in use. The color map value for white, for example, is 65535,65535,65535.
カラーマップ値は常に16ビットで、使用しているディスプレイハードウェアに関係なく、値の範囲は0〜65535です。たとえば、白のカラーマップ値は65535,65535,65535です。
The message starts with a header describing the range of colormap entries to be updated.
メッセージは、更新するカラーマップエントリの範囲を説明するヘッダーで始まります。
+--------------+--------------+------------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+------------------+
| 1 | U8 [1] | message-type |
| 1 | | padding |
| 2 | U16 | first-color |
| 2 | U16 | number-of-colors |
+--------------+--------------+------------------+
This header is followed by number-of-colors RGB values, each of which is in this format:
このヘッダーの後に色数RGB値が続きます。それぞれの値は次の形式です。
+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 2 | U16 | red |
| 2 | U16 | green |
| 2 | U16 | blue |
+--------------+--------------+-------------+
A Bell message makes an audible signal on the client if it provides one.
ベルメッセージが提供されている場合、ベルメッセージはクライアントに可聴信号を発信します。
+--------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+--------------+
| 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 newline character (hex 0a) alone. No carriage-return (hex 0d) is used. There is no way to transfer text outside the Latin-1 character set.
サーバーのカットバッファーに新しいISO 8859-1（Latin-1）テキストが含まれています。行末は改行文字（16進0a）だけで表されます。キャリッジリターン（16進0d）は使用されません。 Latin-1文字セットの外にテキストを転送する方法はありません。
+--------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+--------------+
| 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 |
| 15 | TRLE |
| 16 | ZRLE |
| -239 | Cursor pseudo-encoding |
| -223 | DesktopSize pseudo-encoding |
+--------+-----------------------------+
Other encoding types exist but are not publicly documented.
他のエンコードタイプは存在しますが、公開されていません。
The simplest encoding type is raw pixel data. In this case, the data consists of width*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 scan line order. All RFB clients must be able to handle pixel data in this raw encoding, and RFB servers should only produce raw encoding unless the client specifically asks for some other encoding type.
最も単純なエンコードタイプは、生のピクセルデータです。この場合、データはwidth * heightピクセル値で構成されます（widthとheightは長方形の幅と高さです）。値は、単純に各ピクセルを左から右の走査線の順序で表します。すべてのRFBクライアントは、この未加工のエンコードでピクセルデータを処理できなければならず、RFBサーバーは、クライアントが他のエンコードタイプを特に要求しない限り、未加工のエンコードのみを生成する必要があります。
+----------------------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+----------------------------+--------------+-------------+
| width*height*bytesPerPixel | PIXEL array | pixels |
+----------------------------+--------------+-------------+
The CopyRect (copy rectangle) encoding is a very simple and efficient encoding that 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 common of which are when the user moves a window across the screen, and when the contents of a window are scrolled.
CopyRect（長方形のコピー）エンコーディングは非常にシンプルで効率的なエンコーディングであり、クライアントのフレームバッファー内のどこかにすでに同じピクセルデータがある場合に使用できます。ワイヤー上のエンコーディングは、単にX、Y座標で構成されます。これにより、クライアントがピクセルデータの四角形をコピーできるフレームバッファー内の位置がわかります。これはさまざまな状況で使用できますが、最も一般的なのは、ユーザーが画面上でウィンドウを移動したとき、およびウィンドウのコンテンツがスクロールされたときです。
+--------------+--------------+----------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+----------------+
| 2 | U16 | src-x-position |
| 2 | U16 | src-y-position |
+--------------+--------------+----------------+
For maximum compatibility, the source rectangle of a CopyRect should not include pixels updated by previous entries in the same FramebufferUpdate message.
互換性を最大にするために、CopyRectのソースの四角形には、同じFramebufferUpdateメッセージの以前のエントリによって更新されたピクセルを含めないでください。
Note: RRE encoding is obsolescent. In general, ZRLE and TRLE encodings are more compact.
注：RREエンコーディングは廃止されました。一般に、ZRLEおよびTRLEエンコーディングはよりコンパクトです。
RRE stands for rise-and-run-length encoding. 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 that can be rendered immediately by the simplest of graphics engines. RRE is not appropriate for complex desktops, but can be useful in some situations.
RREは、ライズアンドランレングスエンコーディングの略です。その名前が示すように、基本的にはランレングスエンコーディングの2次元アナログです。 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 (which should be different from 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 |
+---------------+--------------+-------------------------+
This is followed by number-of-subrectangles instances of the following structure:
この後に、次の構造の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 |
+---------------+--------------+---------------------+
Note: Hextile encoding is obsolescent. In general, ZRLE and TRLE encodings are more compact.
注：Hextileエンコーディングは廃止されました。一般に、ZRLEおよびTRLEエンコーディングはよりコンパクトです。
Hextile is a variation on RRE. 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のバリエーションです。長方形は16x16のタイルに分割されているため、サブ長方形のサイズをそれぞれ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. 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. However, the background pixel value may not be carried over if the previous tile was raw. 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. The foreground pixel value may not be carried over if the previous tile was raw or had the SubrectsColored bit set. It may, however, be carried over from a previous tile with the AnySubrects bit clear, as long as that tile itself carried over a valid foreground from its previous tile.
各タイルは、未加工のピクセルデータとして、またはRREのバリエーションとしてエンコードされます。以前と同様に、各タイルには背景のピクセル値があります。背景のピクセル値が前のタイルの背景と同じである場合、特定のタイルに明示的に指定する必要はありません。ただし、前のタイルが未加工の場合、背景のピクセル値は引き継がれない場合があります。タイルのすべてのサブ長方形が同じピクセル値を持っている場合、これはタイル全体の前景ピクセル値として一度指定できます。背景と同様に、前景のピクセル値は指定しないままにすることができます。つまり、前のタイルから引き継がれます。前のピクセル値は、前のタイルが未加工であるか、SubrectsColoredビットが設定されている場合は引き継がれない場合があります。ただし、そのタイル自体が前のタイルから有効な前景を引き継いでいる限り、AnySubrectsビットがクリアされている前のタイルから引き継がれます。
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:
データは、順番にエンコードされた各タイルで構成されます。各タイルは、サブエンコードタイプのバイトで始まります。これは、いくつかのビットで構成されるマスクです。
+--------------+--------------+---------------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+---------------------+
| 1 | U8 | subencoding-mask: |
| | [1] | Raw |
| | [2] | BackgroundSpecified |
| | [4] | ForegroundSpecified |
| | [8] | AnySubrects |
| | [16] | SubrectsColored |
+--------------+--------------+---------------------+
If the Raw bit is set, then the other bits are irrelevant; width*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: BackgroundSpecified If set, a pixel value of bytesPerPixel bytes follows and specifies the background color for this tile. The 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ビットが設定されている場合、他のビットは無関係です。 width * heightピクセル値が続きます（ここで、widthとheightはタイルの幅と高さです）。それ以外の場合、マスクの他のビットは次のとおりです。BackgroundSpecified設定されている場合、bytesPerPixelバイトのピクセル値が続き、このタイルの背景色を指定します。長方形の最初の未加工タイルには、このビットが設定されている必要があります。このビットが設定されていない場合、背景は最後のタイルと同じです。
ForegroundSpecified If set, a pixel value of bytesPerPixel bytes follows and specifies the foreground color to be used for all subrectangles in this tile.
ForegroundSpecified設定されている場合、bytesPerPixelバイトのピクセル値が続き、このタイルのすべてのサブ長方形に使用される前景色を指定します。
If this bit is set, then the SubrectsColored bit must be zero.
このビットが設定されている場合、SubrectsColoredビットはゼロでなければなりません。
AnySubrects If set, a single byte follows and gives the number of subrectangles following. If not set, there are no subrectangles (i.e., the whole tile is just solid background color).
AnySubrects設定されている場合、1バイトが続き、それに続くサブ長方形の数を示します。設定されていない場合、サブレクタングルはありません（つまり、タイル全体が単色の背景色になります）。
SubrectsColored If set, then each subrectangle is preceded by a pixel value giving the color of that subrectangle, so a subrectangle is:
SubrectsColored設定されている場合、各サブ長方形の前にそのサブ長方形の色を示すピクセル値があり、サブ長方形は次のようになります。
+---------------+--------------+---------------------+
| No. of bytes | Type [Value] | Description |
+---------------+--------------+---------------------+
| bytesPerPixel | PIXEL | subrect-pixel-value |
| 1 | U8 | x-and-y-position |
| 1 | U8 | width-and-height |
+---------------+--------------+---------------------+
If not set, all subrectangles are the same color -- the foreground color; 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 |
+--------------+--------------+------------------+
The position and size of each subrectangle is specified in two bytes, x-and-y-position and width-and-height. The most significant 4 bits of x-and-y-position specify the X position, the least significant specify the Y position. The most significant 4 bits of width-and-height specify the width minus 1, the least significant specify the height minus 1.
各サブ長方形の位置とサイズは、xとyの位置と幅と高さの2バイトで指定されます。 xとyの位置の最上位4ビットはX位置を指定し、最下位のビットはY位置を指定します。幅と高さの最上位4ビットは、幅から1を引いた値を指定し、最下位のビットは、高さから1を引いた値を指定します。
TRLE stands for Tiled Run-Length Encoding, and combines tiling, palettization, and run-length encoding. The rectangle is divided into tiles of 16x16 pixels in left-to-right, top-to-bottom order, similar to Hextile. If the width of the rectangle is not an exact multiple of 16, 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 16, then the height of each tile in the final row is smaller.
TRLEはTiled Run-Length Encodingの略で、タイリング、パレット化、ランレングスエンコーディングを組み合わせたものです。長方形は、Hextileと同様に、左から右、上から下の順序で16x16ピクセルのタイルに分割されます。長方形の幅が正確に16の倍数ではない場合、各行の最後のタイルの幅は小さくなり、長方形の高さが正確に16の倍数でない場合は、各タイルの高さが最終行は小さくなります。
TRLE makes use of a new type CPIXEL (compressed pixel). This is the same as a PIXEL for the agreed pixel format, except as a special case, it uses a more compact format if true-color-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. If all of these are the 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.
TRLEは新しいタイプのCPIXEL（圧縮ピクセル）を使用します。これは、合意されたピクセル形式のPIXELと同じですが、特殊なケースとして、トゥルーカラーフラグがゼロ以外で、ピクセルあたりのビット数が32、深度が24以下の場合、よりコンパクトな形式を使用します。赤、緑、青の強度を構成するすべてのビットは、最下位3バイトまたは最上位3バイトのいずれかに収まります。これらすべてが当てはまる場合、CPIXELの長さは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 7 bits indicate the size of the palette used: zero means no palette, 1 means that the tile is of a single color, and 2 to 127 indicate a palette of that size. The special subencoding values 129 and 127 indicate that the palette is to be reused from the last tile that had a palette, with and without RLE, respectively.
各タイルは、サブエンコーディングタイプのバイトで始まります。タイルがランレングスエンコードされている場合、このバイトの最上位ビットが設定され、それ以外の場合はクリアされます。下位7ビットは使用されるパレットのサイズを示します。0はパレットなし、1はタイルが単色であることを意味し、2〜127はそのサイズのパレットを示します。特別なサブエンコーディング値129および127は、パレットがRLEのある場合とない場合のそれぞれで、パレットがあった最後のタイルから再利用されることを示しています。
Note: in this discussion, the div(a,b) function means the result of dividing a/b truncated to an integer.
注：この説明では、div（a、b）関数はa / bを整数に切り捨てた結果を意味します。
The possible values of subencoding are:
サブエンコーディングの可能な値は次のとおりです。
0: Raw pixel data. width*height pixel values follow (where width and height are the width and height of the tile):
0：生のピクセルデータ。 width * heightピクセル値が続きます（ここで、widthとheightはタイルの幅と高さです）：
+-----------------------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+-----------------------------+--------------+-------------+
| width*height*BytesPerCPixel | CPIXEL array | pixels |
+-----------------------------+--------------+-------------+
1: A solid tile consisting of a single color. The pixel value follows:
1：単色で構成される単色のタイル。ピクセル値は次のとおりです。
+----------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+----------------+--------------+-------------+
| bytesPerCPixel | CPIXEL | pixelValue |
+----------------+--------------+-------------+
2 to 16: Packed palette types. The paletteSize is the value of the subencoding, which is followed by the palette, consisting of paletteSize pixel values. The packed pixels follow, with each pixel represented as a bit field yielding a zero-based index into the palette. For paletteSize 2, a 1-bit field is used; for paletteSize 3 or 4, a 2-bit field is used; and for paletteSize from 5 to 16, a 4-bit field is used. The bit fields are packed into bytes, with the most significant bits representing the leftmost pixel (i.e., big endian). For tiles not a multiple of 8, 4, or 2 pixels wide (as appropriate), padding bits are used to align each row to an exact number of bytes.
2から16：パックされたパレットタイプ。パレットサイズはサブエンコーディングの値であり、その後にパレットが続き、パレットサイズのピクセル値で構成されます。パックされたピクセルが続き、各ピクセルはビットフィールドとして表され、パレットへのゼロベースのインデックスを生成します。パレットサイズ2の場合、1ビットのフィールドが使用されます。 PaletteSize 3または4の場合、2ビットのフィールドが使用されます。 5から16までのパレットサイズには、4ビットのフィールドが使用されます。ビットフィールドはバイトにパックされ、最上位ビットは左端のピクセル（ビッグエンディアン）を表します。幅が8、4、または2ピクセルの倍数でないタイルの場合（適切な場合）、パディングビットを使用して、各行を正確なバイト数に揃えます。
+----------------------------+--------------+--------------+
| No. of bytes | Type [Value] | Description |
+----------------------------+--------------+--------------+
| paletteSize*bytesPerCPixel | CPIXEL array | palette |
| m | U8 array | packedPixels |
+----------------------------+--------------+--------------+
where m is the number of bytes representing the packed pixels. For paletteSize of 2, this is div(width+7,8)*height; for paletteSize of 3 or 4, this is div(width+3,4)*height; or for paletteSize of 5 to 16, this is div(width+1,2)*height.
ここで、mはパックされたピクセルを表すバイト数です。 2のパレットサイズの場合、これはdiv（width + 7,8）* heightです。 3または4のパレットサイズの場合、これはdiv（width + 3,4）* heightです。または、5〜16のパレットサイズの場合、これはdiv（width + 1,2）* heightです。
17 to 126: Unused. (Packed palettes of these sizes would offer no advantage over palette RLE).
17〜126：未使用。 （これらのサイズのパックされたパレットは、パレットRLEに勝る利点はありません）。
127: Packed palette with the palette reused from the previous tile. The subencoding byte is followed by the packed pixels as described above for packed palette types.
127：前のタイルからパレットが再利用された、パックされたパレット。サブエンコーディングバイトの後には、上記のパックされたパレットタイプについて説明したように、パックされたピクセルが続きます。
128: Plain RLE. The data consists of a number of runs, repeated until the tile is done. Runs may continue from the end of one row to the beginning of the next. Each run is represented by a single pixel value followed by the length of the run. The length is represented as one or more bytes. The length is calculated as one more than the sum of all the bytes representing the length. Any byte value other than 255 indicates the final byte. So for example, length 1 is represented as [0], 255 as [254], 256 as [255,0], 257 as [255,1], 510 as [255,254], 511 as [255,255,0], and so on.
128：プレーンRLE。データは、タイルが完了するまで繰り返される実行の数で構成されます。実行は、ある行の終わりから次の行の始まりまで続く場合があります。各ランは、単一のピクセル値とそれに続くランの長さで表されます。長さは1バイト以上で表されます。長さは、長さを表すすべてのバイトの合計よりも1だけ多く計算されます。 255以外のバイト値は、最終バイトを示します。たとえば、長さ1は[0]、255は[254]、256は[255,0]、257は[255,1]、510は[255,254]、511は[255,255,0]として表されます。など。
+-------------------------+--------------+-----------------------+
| No. of bytes | Type [Value] | Description |
+-------------------------+--------------+-----------------------+
| bytesPerCPixel | CPIXEL | pixelValue |
| div(runLength - 1, 255) | U8 array | 255 |
| 1 | U8 | (runLength-1) mod 255 |
+-------------------------+--------------+-----------------------+
129: Palette RLE with the palette reused from the previous tile. Followed by a number of runs, repeated until the tile is done, as described below for 130 to 255.
129：前のタイルからパレットが再利用されたパレットRLE。以下に示すように、タイルが完了するまで繰り返されるいくつかの実行が続きます。
130 to 255: Palette RLE. Followed by the palette, consisting of
paletteSize = (subencoding - 128) pixel values:
+----------------------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+----------------------------+--------------+-------------+
| paletteSize*bytesPerCPixel | CPIXEL array | palette |
+----------------------------+--------------+-------------+
Following the palette is, as with plain RLE, 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 |
+--------------+--------------+--------------+
A 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.
2つ以上の長さのランは、最上位ビットが設定されたパレットインデックスで表され、その後にプレーンRLEの場合と同じランの長さが続きます。
+-------------------------+--------------+-----------------------+
| No. of bytes | Type [Value] | Description |
+-------------------------+--------------+-----------------------+
| 1 | U8 | paletteIndex + 128 |
| div(runLength - 1, 255) | U8 array | 255 |
| 1 | U8 | (runLength-1) mod 255 |
+-------------------------+--------------+-----------------------+
ZRLE stands for Zlib (see [RFC1950] and [RFC1951]) Run-Length Encoding, and combines an encoding similar to TRLE with zlib compression. 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（[RFC1950]および[RFC1951]を参照）の略で、Run-Length Encodingであり、TRLEと同様のエンコーディングとzlib圧縮を組み合わせています。ネットワーク上では、長方形は4バイトの長さフィールドで始まり、その後にzlib圧縮されたデータのそのバイト数が続きます。特定のRFBプロトコル接続に単一のzlib「ストリーム」オブジェクトが使用されるため、ZRLE長方形は厳密に順序どおりにエンコードおよびデコードする必要があります。
+--------------+--------------+-------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+-------------+
| 4 | U32 | length |
| length | U8 array | zlibData |
+--------------+--------------+-------------+
The zlibData when uncompressed represents tiles in left-to-right, top-to-bottom order, similar to TRLE, but with a tile size of 64x64 pixels. 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は、TRLEと同様に左から右、上から下の順序でタイルを表しますが、タイルサイズは64x64ピクセルです。長方形の幅が64の正確な倍数でない場合は、各行の最後のタイルの幅が小さくなり、長方形の高さが64の正確な倍数でない場合は、各タイルの高さが最終行は小さくなります。
The tiles are encoded in exactly the same way as TRLE, except that subencoding may not take the values 127 or 129, i.e., palettes cannot be reused between tiles.
タイルはTRLEとまったく同じ方法でエンコードされますが、サブエンコードでは値127または129を使用できない場合があります。つまり、タイル間でパレットを再利用できません。
The server flushes the zlib stream to a byte boundary at the end of each ZRLE-encoded rectangle. It need not flush the stream between tiles within a rectangle. Since the zlibData for a single rectangle can potentially be quite large, clients can incrementally decode and interpret the zlibData but must not assume that encoded tile data is byte aligned.
サーバーはzlibストリームを、各ZRLEエンコードされた長方形の最後のバイト境界にフラッシュします。長方形内のタイル間のストリームをフラッシュする必要はありません。単一の長方形のzlibDataは非常に大きくなる可能性があるため、クライアントはzlibDataを段階的にデコードおよび解釈できますが、エンコードされたタイルデータがバイト単位で整列されていると想定してはなりません。
An update rectangle with a "pseudo-encoding" does not directly represent pixel data but instead allows the server to send arbitrary data to the client. How this data is interpreted depends on the pseudo-encoding.
「疑似エンコーディング」を含む更新長方形は、ピクセルデータを直接表すのではなく、サーバーが任意のデータをクライアントに送信できるようにします。このデータの解釈方法は、疑似エンコーディングによって異なります。
A client that requests the Cursor pseudo-encoding is declaring that it is capable of drawing a pointer cursor locally. This can significantly improve perceived performance over slow links. The server sets the cursor shape by sending a rectangle with the Cursor pseudo-encoding as part of an update. The 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*height raw pixel values followed by a shape bitmask, with one bit corresponding to each pixel in the cursor rectangle. The bitmask consists of left-to-right, top-to-bottom scan lines, where each scan line is padded to a whole number of bytes, the number being div(width+7,8). Within each byte, the most significant bit represents the leftmost pixel; a bit set to 1 means the corresponding pixel in the cursor is valid.
Cursor疑似エンコーディングを要求するクライアントは、ポインタカーソルをローカルで描画できることを宣言しています。これにより、低速リンク上で認識されるパフォーマンスを大幅に改善できます。サーバーは、更新の一部としてCursor疑似エンコーディングを使用して長方形を送信することにより、カーソルの形状を設定します。四角形のx位置とy位置はカーソルのホットスポットを示し、幅と高さはカーソルの幅と高さをピクセル単位で示します。データは、width * heightの生のピクセル値とそれに続く形状ビットマスクで構成され、カーソルの長方形の各ピクセルに1ビットが対応します。ビットマスクは左から右、上から下の走査線で構成され、各走査線は整数のバイト数にパディングされ、その数はdiv（width + 7,8）です。各バイト内で、最上位ビットは左端のピクセルを表します。 1に設定されたビットは、カーソル内の対応するピクセルが有効であることを意味します。
+----------------------------+--------------+---------------+
| No. of bytes | Type [Value] | Description |
+----------------------------+--------------+---------------+
| width*height*bytesPerPixel | PIXEL array | cursor-pixels |
| div(width+7,8)*height | U8 array | bitmask |
+----------------------------+--------------+---------------+
A client that requests the DesktopSize pseudo-encoding is declaring that it is capable of coping with a change in the framebuffer width and height. The server changes the desktop size by sending a rectangle with the DesktopSize pseudo-encoding as the last rectangle in an update. The rectangle's x-position and y-position are ignored, and width and height indicate the new width and height of the framebuffer.
DesktopSize疑似エンコーディングを要求するクライアントは、フレームバッファの幅と高さの変更に対応できることを宣言しています。サーバーは、更新の最後の長方形としてDesktopSize疑似エンコーディングを使用して長方形を送信することにより、デスクトップサイズを変更します。長方形のx位置とy位置は無視され、幅と高さはフレームバッファーの新しい幅と高さを示します。
There is no further data associated with the rectangle. After changing the desktop size, the server must assume that the client no longer has the previous framebuffer contents. This will usually result in a complete update of the framebuffer at the next update. However, for maximum interoperability with existing servers the client should preserve the top-left portion of the framebuffer between the old and new sizes.
長方形に関連付けられたそれ以上のデータはありません。デスクトップサイズを変更した後、サーバーは、クライアントが以前のフレームバッファーの内容を失ったと想定する必要があります。これにより、通常、次の更新時にフレームバッファーが完全に更新されます。ただし、既存のサーバーとの相互運用性を最大にするために、クライアントはフレームバッファーの左上部分を古いサイズと新しいサイズの間で保持する必要があります。
IANA has allocated port 5900 to the RFB protocol. The other port numbers mentioned in Section 2 are called out for historical context and do not match IANA allocations.
IANAはポート5900をRFBプロトコルに割り当てました。セクション2で言及されている他のポート番号は、履歴のコンテキストで呼び出されており、IANA割り当てと一致していません。
Future assignments to the IANA registries created by this specification are to be made through either "Expert Review" or "IESG Approval" (if there is no currently appointed expert) as defined in [RFC5226].
この仕様によって作成されたIANAレジストリへの将来の割り当ては、[RFC5226]で定義されているように、「エキスパートレビュー」または「IESG承認」（現在エキスパートが任命されていない場合）を通じて行われます。
The name of this registry is "Remote Framebuffer Security Types".
このレジストリの名前は、「リモートフレームバッファセキュリティタイプ」です。
IANA established a registry for security types that are used with the RFB protocol.
IANAは、RFBプロトコルで使用されるセキュリティタイプのレジストリを確立しました。
The initial entries in the registry are:
レジストリの最初のエントリは次のとおりです。
+------------+-------------------------+-----------------------+
| Number | Name | References |
+------------+-------------------------+-----------------------+
| 0 | Invalid | (this document) |
| 1 | None | (this document) |
| 2 | VNC Authentication | (this document) |
| 3 to 15 | RealVNC | (historic assignment) |
| 16 | Tight | (historic assignment) |
| 17 | Ultra | (historic assignment) |
| 18 | TLS | (historic assignment) |
| 19 | VeNCrypt | (historic assignment) |
| 20 | GTK-VNC SASL | (historic assignment) |
| 21 | MD5 hash authentication | (historic assignment) |
| 22 | Colin Dean xvp | (historic assignment) |
| 128 to 255 | RealVNC | (historic assignment) |
+------------+-------------------------+-----------------------+
The name of this registry is "Remote Framebuffer Client-to-Server Message Types".
このレジストリの名前は、「リモートフレームバッファクライアントからサーバーへのメッセージタイプ」です。
IANA established a registry for client-to-server message types that are used with the RFB protocol.
IANAは、RFBプロトコルで使用されるクライアントからサーバーへのメッセージタイプのレジストリを確立しました。
The initial entries in the registry are:
レジストリの最初のエントリは次のとおりです。
+--------+------------------------------+-----------------------+
| Number | Name | References |
+--------+------------------------------+-----------------------+
| 0 | SetPixelFormat | (this document) |
| 2 | SetEncodings | (this document) |
| 3 | FramebufferUpdateRequest | (this document) |
| 4 | KeyEvent | (this document) |
| 5 | PointerEvent | (this document) |
| 6 | ClientCutText | (this document) |
| 127 | VMWare | (historic assignment) |
| 128 | Nokia Terminal Mode Spec | (historic assignment) |
| 249 | OLIVE Call Control | (historic assignment) |
| 250 | Colin Dean xvp | (historic assignment) |
| 251 | Pierre Ossman SetDesktopSize | (historic assignment) |
| 252 | tight | (historic assignment) |
| 253 | gii | (historic assignment) |
| 254 | VMWare | (historic assignment) |
| 255 | Anthony Liguori | (historic assignment) |
+--------+------------------------------+-----------------------+
The name of this registry is "Remote Framebuffer Server-to-Client Message Types".
このレジストリの名前は、「リモートフレームバッファサーバーからクライアントへのメッセージタイプ」です。
IANA established a registry for server-to-client message types that are used with the RFB protocol.
IANAは、RFBプロトコルで使用されるサーバーからクライアントへのメッセージタイプのレジストリを確立しました。
The initial entries in the registry are:
レジストリの最初のエントリは次のとおりです。
+--------+--------------------------+-----------------------+
| Number | Name | References |
+--------+--------------------------+-----------------------+
| 0 | FramebufferUpdate | (this document) |
| 1 | SetColourMapEntries | (this document) |
| 2 | Bell | (this document) |
| 3 | ServerCutText | (this document) |
| 127 | VMWare | (historic assignment) |
| 128 | Nokia Terminal Mode Spec | (historic assignment) |
| 249 | OLIVE Call Control | (historic assignment) |
| 250 | Colin Dean xvp | (historic assignment) |
| 252 | tight | (historic assignment) |
| 253 | gii | (historic assignment) |
| 254 | VMWare | (historic assignment) |
| 255 | Anthony Liguori | (historic assignment) |
+--------+--------------------------+-----------------------+
The name of this registry is "Remote Framebuffer Encoding Types".
このレジストリの名前は「リモートフレームバッファエンコーディングタイプ」です。
IANA established a registry for encoding types that are used with the RFB protocol.
IANAは、RFBプロトコルで使用されるエンコードタイプのレジストリを確立しました。
The initial entries in the registry are:
レジストリの最初のエントリは次のとおりです。
+-------------------+----------------------------+------------------+
| Number | Name | References |
+-------------------+----------------------------+------------------+
| 0 | Raw | (this document) |
| 1 | CopyRect | (this document) |
| 2 | RRE | (this document) |
| 5 | Hextile | (this document) |
| 16 | ZRLE | (this document) |
| -239 | Cursor pseudo-encoding | (this document) |
| -223 | DesktopSize | (this document) |
| | pseudo-encoding | |
| 4 | CoRRE | (historic |
| | | assignment) |
| 6 | zlib | (historic |
| | | assignment) |
| 7 | tight | (historic |
| | | assignment) |
| 8 | zlibhex | (historic |
| | | assignment) |
| 15 | TRLE | (this document) |
| 17 | Hitachi ZYWRLE | (historic |
| | | assignment) |
| 1024 to 1099 | RealVNC | (historic |
| | | assignment) |
| -1 to -222 | tight options | (historic |
| | | assignment) |
| -224 to -238 | tight options | (historic |
| | | assignment) |
| -240 to -256 | tight options | (historic |
| | | assignment) |
| -257 to -272 | Anthony Liguori | (historic |
| | | assignment) |
| -273 to -304 | VMWare | (historic |
| | | assignment) |
| -305 | gii | (historic |
| | | assignment) |
| -306 | popa | (historic |
| | | assignment) |
| -307 | Peter Astrand DesktopName | (historic |
| | | assignment) |
| -308 | Pierre Ossman | (historic |
| | ExtendedDesktopSize | assignment) |
| -309 | Colin Dean xvp | (historic |
| | | assignment) |
| -310 | OLIVE Call Control | (historic |
| | | assignment) |
| -412 to -512 | TurboVNC fine-grained | (historic |
| | quality level | assignment) |
| -523 to -524 | Nokia Terminal Mode Spec | (historic |
| | | assignment) |
| -763 to -768 | TurboVNC subsampling level | (historic |
| | | assignment) |
| 0x574d5600 to | VMWare | (historic |
| 0x574d56ff | | assignment) |
+-------------------+----------------------------+------------------+
The RFB protocol as defined here provides no security beyond the optional and cryptographically weak password check described in Section 7.2.2. In particular, it provides no protection against observation of or tampering with the data stream. It has typically been used on secure physical or virtual networks.
ここで定義されているRFBプロトコルは、セクション7.2.2で説明されているオプションの暗号的に脆弱なパスワードチェック以外のセキュリティを提供しません。特に、データストリームの観測や改ざんに対する保護は提供されません。これは通常、安全な物理ネットワークまたは仮想ネットワークで使用されています。
Security methods beyond those described here may be used to protect the integrity of the data. The client and server might agree to use an extended security type to encrypt the session, or the session might be transmitted over a secure channel such as IPsec [RFC4301] or SSH [RFC4254].
ここで説明する方法以外のセキュリティメソッドを使用して、データの整合性を保護できます。クライアントとサーバーは、拡張セキュリティタイプを使用してセッションを暗号化することに同意するか、セッションがIPsec [RFC4301]やSSH [RFC4254]などの安全なチャネルを介して送信される可能性があります。
James Weatherall, Andy Harter, and Ken Wood also contributed to the design of the RFB protocol.
James Weatherall、Andy Harter、およびKen Woodも、RFBプロトコルの設計に貢献しました。
RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. and in other countries.
RFBおよびVNCは、RealVNC Ltd.の米国およびその他の国における登録商標です。
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch、L. and J-L。ゲイリー、「ZLIB圧縮データ形式仕様バージョン3.3」、RFC 1950、1996年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、1996年5月。
[XLIBREF] Nye, A., "XLIB Reference Manual R5", June 1994.
[XLIBREF] Nye、A。、「XLIBリファレンスマニュアルR5」、1994年6月。
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[RFC4254] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）Connection Protocol」、RFC 4254、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
For maximum interoperability, clients and servers should be prepared to fall back to the earlier 3.3 and 3.7 versions of the RFB protocol. Any version reported other than 3.7 or 3.8 should be treated as 3.3.
相互運用性を最大にするために、クライアントとサーバーは、RFBプロトコルの以前のバージョン3.3および3.7にフォールバックできるように準備する必要があります。 3.7または3.8以外で報告されたバージョンは、3.3として扱う必要があります。
All of the differences occur in the initial handshake phase. Once the session reaches the ClientInit and ServerInit messages, all three protocol versions are identical. Even within a protocol version, clients and servers may support different subsets of the encoding and pseudo-encoding types.
すべての違いは、初期ハンドシェイクフェーズで発生します。セッションがClientInitおよびServerInitメッセージに到達すると、3つのプロトコルバージョンはすべて同じになります。プロトコルバージョン内であっても、クライアントとサーバーは、エンコードタイプと疑似エンコードタイプの異なるサブセットをサポートする場合があります。
The ProtocolVersion message is:
ProtocolVersionメッセージは次のとおりです。
RFB 003.003\n (hex 52 46 42 20 30 30 33 2e 30 30 33 0a)
RFB 003.003 \ n（16進数52 46 42 20 30 30 33 2e 30 30 33 0a）
In the security handshake (Section 7.1.2), rather than a two-way negotiation, the server decides the security type and sends a single word:
セキュリティハンドシェイク（セクション7.1.2）では、サーバーは双方向のネゴシエーションではなく、セキュリティタイプを決定し、1つの単語を送信します。
+--------------+--------------+---------------+
| No. of bytes | Type [Value] | Description |
+--------------+--------------+---------------+
| 4 | U32 | security-type |
+--------------+--------------+---------------+
The 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 in Section 7.1.2.
セキュリティタイプは、0、1、または2の値のみを取ることができます。値0は、接続が失敗したことを意味し、セクション7.1.2で説明されているように、理由を示す文字列が続きます。
If the security-type is 1, for no authentication, the server does not send the SecurityResult message but proceeds directly to the initialization messages (Section 7.3).
security-typeが1の場合、認証がないため、サーバーはSecurityResultメッセージを送信せず、初期化メッセージに直接進みます（7.3節）。
In VNC Authentication (Section 7.2.2), if the authentication fails, the server sends the SecurityResult message, but does not send an error message before closing the connection.
VNC認証（セクション7.2.2）では、認証が失敗した場合、サーバーはSecurityResultメッセージを送信しますが、接続を閉じる前にエラーメッセージを送信しません。
The ProtocolVersion message is:
ProtocolVersionメッセージは次のとおりです。
RFB 003.007\n (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)
RFB 003.007 \ n（16進数52 46 42 20 30 30 33 2e 30 30 37 0a）
After the security handshake, if the security-type is 1, for no authentication, the server does not send the SecurityResult message but proceeds directly to the initialization messages (Section 7.3).
セキュリティハンドシェイクの後、セキュリティタイプが1の場合、認証は行われず、サーバーはSecurityResultメッセージを送信せずに、初期化メッセージ（セクション7.3）に直接進みます。
In VNC Authentication (Section 7.2.2), if the authentication fails, the server sends the SecurityResult message, but does not send an error message before closing the connection.
VNC認証（セクション7.2.2）では、認証が失敗した場合、サーバーはSecurityResultメッセージを送信しますが、接続を閉じる前にエラーメッセージを送信しません。
Authors' Addresses
著者のアドレス
Tristan Richardson RealVNC Ltd. Betjeman House, 104 Hills Road Cambridge CB2 1LQ UK
Tristan Richardson RealVNC Ltd. Betjeman House、104 Hills Road Cambridge CB2 1LQ UK
Phone: +44 1223 310400
EMail: standards@realvnc.com
URI: http://www.realvnc.com
John Levine RealVNC Ltd.
John Levine RealVNC Ltd.
Phone: +44 1223 790005
EMail: standards@taugh.com
URI: http://jl.ly