Network Working Group B. Curtin
Request for Comments: 2640 Defense Information Systems Agency
Updates: 959 July 1999
Category: Proposed Standard
Internationalization of the File Transfer Protocol
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII.
RFC 959 [RFC959]とRFC 1123、セクション4 [RFC1123]で定義されるようにファイル転送プロトコルは、インターネット上で最も古く、広く使用されているプロトコルの一つです。プロトコルの主要な文字セット、7ビットASCIIは、インターネットの初期の成長年間を通じてうまくプロトコルを務めています。インターネットがよりグローバルになるにつれてしかし、7ビットASCIIを超えて文字セットをサポートする必要があります。
This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support.
この文書は、インターネットコミュニティ全体で見られる複数の文字セットと言語をサポート含んでFTPの国際化（I18N）を、対応しています。これは、FTPの仕様を拡張し、適切な国際化支援のための勧告を与えることによって達成されます。
Table of Contents
目次
ABSTRACT.......................................................1
1 INTRODUCTION.................................................2
1.1 Requirements Terminology..................................2
2 INTERNATIONALIZATION.........................................3
2.1 International Character Set...............................3
2.2 Transfer Encoding Set.....................................4
3 PATHNAMES....................................................5
3.1 General compliance........................................5
3.2 Servers compliance........................................6
3.3 Clients compliance........................................7
4 LANGUAGE SUPPORT.............................................7
4.1 The LANG command..........................................8
4.2 Syntax of the LANG command................................9
4.3 Feat response for LANG command...........................11
4.3.1 Feat examples.........................................11
5 SECURITY CONSIDERATIONS.....................................12
6 ACKNOWLEDGMENTS.............................................12
7 GLOSSARY....................................................13
8 BIBLIOGRAPHY................................................13
9 AUTHOR'S ADDRESS............................................15
ANNEX A - IMPLEMENTATION CONSIDERATIONS.......................16
A.1 General Considerations...................................16
A.2 Transition Considerations................................18
ANNEX B - SAMPLE CODE AND EXAMPLES............................19
B.1 Valid UTF-8 check........................................19
B.2 Conversions..............................................20
B.2.1 Conversion from Local Character Set to UTF-8..........20
B.2.2 Conversion from UTF-8 to Local Character Set..........23
B.2.3 ISO/IEC 8859-8 Example................................25
B.2.4 Vendor Codepage Example...............................25
B.3 Pseudo Code for Translating Servers......................26
Full Copyright Statement......................................27
1 Introduction
1はじめに
As the Internet grows throughout the world the requirement to support character sets outside of the ASCII [ASCII] / Latin-1 [ISO-8859] character set becomes ever more urgent. For FTP, because of the large installed base, it is paramount that this is done without breaking existing clients and servers. This document addresses this need. In doing so it defines a solution which will still allow the installed base to interoperate with new clients and servers.
インターネットは、世界中で成長するにつれてASCII [ASCII] /ラテン-1 [ISO-8859]文字セットの外の文字セットをサポートするための要件は、これまで以上に緊急になります。 FTPの場合、理由は大規模なインストールベースの、既存のクライアントとサーバーを壊すことなく行われること非常に重要です。この文書では、このニーズに対応しています。そうすることで、それはまだインストールベースは新しいクライアントとサーバとの相互運用を可能にするソリューションを定義します。
This document enhances the capabilities of the File Transfer Protocol by removing the 7-bit restrictions on pathnames used in client commands and server responses, RECOMMENDs the use of a Universal Character Set (UCS) ISO/IEC 10646 [ISO-10646], RECOMMENDs a UCS transformation format (UTF) UTF-8 [UTF-8], and defines a new command for language negotiation.
この文書では、クライアントのコマンドとサーバ応答で使用されるパス名に7ビットの制限を除去することにより、ファイル転送プロトコルの機能を強化し、ユニバーサル文字セット（UCS）ISO / IEC 10646 [ISO-10646]の使用を推奨しています、A推奨していますUCS変換フォーマット（UTF）UTF-8 [UTF-8]、および言語ネゴシエーションのための新しいコマンドを定義します。
The recommendations made in this document are consistent with the recommendations expressed by the IETF policy related to character sets and languages as defined in RFC 2277 [RFC2277].
RFC 2277 [RFC2277]で定義されるように本書で提言は、文字セットと言語に関連するIETFポリシーで表さ提言と一致しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [BCP14].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[BCP14] BCP 14に記載されるように解釈されます。
2 Internationalization
2国際化
The File Transfer Protocol was developed when the predominate character sets were 7 bit ASCII and 8 bit EBCDIC. Today these character sets cannot support the wide range of characters needed by multinational systems. Given that there are a number of character sets in current use that provide more characters than 7-bit ASCII, it makes sense to decide on a convenient way to represent the union of those possibilities. To work globally either requires support of a number of character sets and to be able to convert between them, or the use of a single preferred character set. To assure global interoperability this document RECOMMENDS the latter approach and defines a single character set, in addition to NVT ASCII and EBCDIC, which is understandable by all systems. For FTP this character set SHALL be ISO/IEC 10646:1993. For support of global compatibility it is STRONGLY RECOMMENDED that clients and servers use UTF-8 encoding when exchanging pathnames. Clients and servers are, however, under no obligation to perform any conversion on the contents of a file for operations such as STOR or RETR.
支配的な文字セットが7ビットASCIIと8ビットのEBCDICいたときのファイル転送プロトコルを開発しました。今日、これらの文字セットは、多国籍企業のシステムで必要な文字の広い範囲をサポートすることはできません。 7ビットのASCIIより多くの文字を提供し、現在使用中の文字セットの数があることを考えると、それはそれらの可能性の組合を代表する便利な方法を決定するために理にかなっています。世界的に作業するには、文字セットの数のサポートを必要とし、それら、または単一の好適な文字セットを使用することを相互に変換できるようにするのどちらか。グローバルな相互運用性を確保するために、このドキュメントでは、後者のアプローチを推奨していますし、すべてのシステムが理解している、NVT ASCIIとEBCDICに加えて、単一の文字セットを定義します。 1993：FTPの場合、この文字セットは、ISO / IEC 10646ものでなければなりません。グローバルな互換性のサポートのために、強く、パス名を交換する際に、クライアントとサーバーはUTF-8エンコーディングを使用することをお勧めします。クライアントとサーバーは、そのようなSTORまたはRETRなどの操作のためのファイルの内容上の任意の変換を実行する義務を負いません、しかし、です。
The character set used to store files SHALL remain a local decision and MAY depend on the capability of local operating systems. Prior to the exchange of pathnames they SHOULD be converted into a ISO/IEC 10646 format and UTF-8 encoded. This approach, while allowing international exchange of pathnames, will still allow backward compatibility with older systems because the code set positions for ASCII characters are identical to the one byte sequence in UTF-8.
ファイルを保存するために使用される文字セットは、地元の意思決定存続するものとローカルのオペレーティング・システムの能力に依存してもよいです。これらは符号化されたISO / IEC 10646の形式とUTF-8に変換する必要があるパス名の交換に先立っ。 ASCII文字のコードセット位置がUTF-8での1つのバイト配列と同一であるため、このアプローチは、パス名の国際交流を可能にしながら、まだ古いシステムとの後方互換性が可能になります。
Sections 2.1 and 2.2 give a brief description of the international character set and transfer encoding RECOMMENDED by this document. A more thorough description of UTF-8, ISO/IEC 10646, and UNICODE [UNICODE], beyond that given in this document, can be found in RFC 2279 [RFC2279].
セクション2.1と2.2は、この文書が推奨する国際文字セットと転送エンコーディングの簡単な説明を与えます。より完全なUTF-8の説明では、ISO / IEC 10646、およびUnicode [UNICODE]は、この文書で与えられるものを超えて、RFC 2279 [RFC2279]に見出すことができます。
The character set defined for international support of FTP SHALL be the Universal Character Set as defined in ISO 10646:1993 as amended. This standard incorporates the character sets of many existing international, national, and corporate standards. ISO/IEC 10646 defines two alternate forms of encoding, UCS-4 and UCS-2. UCS-4 is a four byte (31 bit) encoding containing 2**31 code positions divided into 128 groups of 256 planes. Each plane consists of 256 rows of 256 cells. UCS-2 is a 2 byte (16 bit) character set consisting of plane zero or the Basic Multilingual Plane (BMP). Currently, no codesets have been defined outside of the 2 byte BMP.
改正され1993：FTPの国際的な支援のために定義された文字セットは、ISO 10646で定義されているユニバーサル文字セットされなければなりません。この規格は、既存の多くの国際、国内、および企業標準の文字セットを搭載しています。 ISO / IEC 10646は、符号化の2つの代替形態、UCS-4、UCS-2を規定します。 UCS-4は、256面の128個のグループに分け、2つの** 31コード位置を含む4バイト（31ビット）符号化です。各プレーンは、256個の細胞の256行から成ります。 UCS-2は、平面ゼロ又は基本多言語面（BMP）からなる2バイト（16ビット）文字セットです。現在、コードセットは、2バイトのBMPの外部で定義されていません。
The Unicode standard version 2.0 [UNICODE] is consistent with the UCS-2 subset of ISO/IEC 10646. The Unicode standard version 2.0 includes the repertoire of IS 10646 characters, amendments 1-7 of IS 10646, and editorial and technical corrigenda.
ユニコード規格バージョン2.0 [UNICODE]はユニコード規格バージョン2.0である10646文字、IS 10646の修正1-7、および編集および技術正誤表のレパートリーを含むISO / IEC 10646のUCS-2サブセットと一致しています。
UCS Transformation Format 8 (UTF-8), in the past referred to as UTF-2 or UTF-FSS, SHALL be used as a transfer encoding to transmit the international character set. UTF-8 is a file safe encoding which avoids the use of byte values that have special significance during the parsing of pathname character strings. UTF-8 is an 8 bit encoding of the characters in the UCS. Some of UTF-8's benefits are that it is compatible with 7 bit ASCII, so it doesn't affect programs that give special meanings to various ASCII characters; it is immune to synchronization errors; its encoding rules allow for easy identification; and it has enough space to support a large number of character sets.
UCS変換形式8（UTF-8）、過去にUTF-2またはUTF-FSSと呼ばれる、国際文字セットを送信するために転送エンコーディングとして使用しなければなりません。 UTF-8は、パス名の文字列の解析中に特別な意味を持つバイト値の使用を避けるファイルの安全なエンコーディングです。 UTF-8は、UCSの文字の8ビット符号化です。 UTF-8の利点のいくつかは、それがさまざまなASCII文字に特別な意味を与えるプログラムに影響を与えないように、それは、7ビットASCIIと互換性があることです。それは、同期エラーの影響を受けています。その符号化規則は、簡単に識別可能にします。そして、それは文字セットの大規模な数をサポートするのに十分なスペースがあります。
UTF-8 encoding represents each UCS character as a sequence of 1 to 6 bytes in length. For all sequences of one byte the most significant bit is ZERO. For all sequences of more than one byte the number of ONE bits in the first byte, starting from the most significant bit position, indicates the number of bytes in the UTF-8 sequence followed by a ZERO bit. For example, the first byte of a 3 byte UTF-8 sequence would have 1110 as its most significant bits. Each additional bytes (continuing bytes) in the UTF-8 sequence, contain a ONE bit followed by a ZERO bit as their most significant bits. The remaining free bit positions in the continuing bytes are used to identify characters in the UCS. The relationship between UCS and UTF-8 is demonstrated in the following table:
UTF-8エンコーディングは、長さが1〜6バイトのシーケンスとして各UCS文字を表します。 1バイトの全ての配列について最上位ビットがゼロです。最初のバイトの1つのビット数は、最上位ビット位置から複数のバイトの全ての配列については、ゼロ・ビットが続いUTF-8シーケンスのバイト数を示します。例えば、3バイトUTF-8シーケンスの最初のバイトは、その最上位ビットとして1110を有するであろう。 UTF-8シーケンス内の各追加のバイト（継続バイト）は、その最上位ビットとしてZEROビット続く1ビットを含みます。継続バイトの残りの遊離のビット位置は、UCSの文字を識別するために使用されます。 UCSとUTF-8との間の関係は、以下の表に示されています。
UCS-4 range(hex) UTF-8 byte sequence(binary) 00000000 - 0000007F 0xxxxxxx 00000080 - 000007FF 110xxxxx 10xxxxxx 00000800 - 0000FFFF 1110xxxx 10xxxxxx 10xxxxxx 00010000 - 001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 00200000 - 03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 04000000 - 7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
UCS-4範囲（16進数）UTF-8バイト配列（バイナリ）00000000 - 0000007F 0xxxxxxx 00000080 - 000007FF 110xxxxx 10xxxxxxに00000800 - 0000FFFF 1110xxxx 10xxxxxxに10xxxxxxに00010000 - 001FFFFF 11110xxx 10xxxxxxに10xxxxxxに10xxxxxxに0020万 - 03FFFFFF 111110xx 10xxxxxxに10xxxxxxに10xxxxxxに10xxxxxxに0400万 - 7FFFFFFF 1111110x 10xxxxxxに10xxxxxxに10xxxxxxに10xxxxxxに10xxxxxxに
A beneficial property of UTF-8 is that its single byte sequence is consistent with the ASCII character set. This feature will allow a transition where old ASCII-only clients can still interoperate with new servers that support the UTF-8 encoding.
UTF-8の有益な特性は、その単一バイトシーケンスは、ASCII文字セットと一致していることです。この機能は、古いASCIIのみのクライアントはまだUTF-8エンコーディングをサポートする新しいサーバとの相互運用ができ移行が可能になります。
Another feature is that the encoding rules make it very unlikely that a character sequence from a different character set will be mistaken for a UTF-8 encoded character sequence. Clients and servers can use a simple routine to determine if the character set being exchanged is valid UTF-8. Section B.1 shows a code example of this check.
もう一つの特徴は、符号化規則は、それは非常に低い異なる文字セットの文字列がUTF-8エンコードされた文字列と誤解されることを作成することです。交換されている文字セットが有効なUTF-8の場合は、クライアントとサーバが判断するために、単純なルーチンを使用することができます。 B.1節は、このチェックのコード例を示します。
3 Pathnames
3つのパス名
- The 7-bit restriction for pathnames exchanged is dropped.
- 交換パス名のための7ビットの制限がドロップされます。
- Many operating system allow the use of spaces <SP>, carriage return <CR>, and line feed <LF> characters as part of the pathname. The exchange of pathnames with these special command characters will cause the pathnames to be parsed improperly. This is because ftp commands associated with pathnames have the form:
- 多くのオペレーティングシステムパス名の一部として、空間の使用<SP>、キャリッジリターン<CR>、ラインフィード<LF>文字を許容します。これらの特別なコマンド文字とパス名の交換は、パス名が正しく解析されるようになります。パス名に関連付けられているFTPコマンドの形式を持っているからです。
COMMAND <SP> <pathname> <CRLF>.
COMMAND <SP> <パス名> <CRLF>。
To allow the exchange of pathnames containing these characters, the definition of pathname is changed from
これらの文字を含むパス名の交換を可能にするには、パス名の定義が変更されたから
<pathname> ::= <string> ; in BNF format
to
pathname = 1*(%x01..%xFF) ; in ABNF format [ABNF].
To avoid mistaking these characters within pathnames as special command characters the following rules will apply:
次のルールが適用される特別なコマンド文字とパス名の中にこれらの文字を間違えないようにするには：
There MUST be only one <SP> between a ftp command and the pathname. Implementations MUST assume <SP> characters following the initial <SP> as part of the pathname. For example the pathname in STOR <SP><SP><SP>foo.bar<CRLF> is <SP><SP>foo.bar.
ftpコマンドとパス名の間だけ1 <SP>がなければなりません。実装は、パス名の一部として、最初の<SP>次の<SP>文字を仮定しなければなりません。例えばSTORでパス名<SP> <SP> <SP> foo.bar <CRLF>は<SP> <SP> foo.bar。
Current implementations, which may allow multiple <SP> characters as separators between the command and pathname, MUST assure that they comply with this single <SP> convention. Note: Implementations which treat 3 character commands (e.g. CWD, MKD, etc.) as a fixed 4 character command by padding the command with a trailing <SP> are in non-compliance to this specification.
コマンドとパス名の間にセパレータとして複数の<SP>文字を許可することがあり、現在の実装では、彼らはこの単一の<SP>規則に準拠していることを保証しなければなりません。注：末尾でコマンドをパディングによって固定4文字コマンドと3つの文字のコマンドを処理する実装（例えば等CWD、MKD）<SP>本明細書に不適合です。
When a <CR> character is encountered as part of a pathname it MUST be padded with a <NUL> character prior to sending the command. On receipt of a pathname containing a <CR><NUL> sequence the <NUL> character MUST be stripped away. This approach is described in the Telnet protocol [RFC854] on pages 11 and 12. For example, to store a pathname foo<CR><LF>boo.bar the pathname would become foo<CR><NUL><LF>boo.bar prior to sending the command STOR <SP>foo<CR><NUL><LF>boo.bar<CRLF>. Upon receipt of the altered pathname the <NUL> character following the <CR> would be stripped away to form the original pathname.
<CR>文字がパス名の一部として検出された場合には、コマンドを送信する前に、<NUL>文字で埋めなければなりません。 <CR> <NUL>配列を含むパス名を受け取ると、<NUL>文字が剥ぎ取らなければなりません。このアプローチは、パス名boo.barパス名FOO <CR> <LF>はFOO <CR> <NUL> <LF> BOOなる記憶するために、例えば、ページ11および12にTelnetプロトコル[RFC854]に記載されています。コマンドSTOR <SP> FOO <CR> <NUL> <LF> boo.bar <CRLF>を送信する前にバー。改変されたパス名<CR>元のパス名を形成するために剥離されることになる次の<NUL>文字を受信します。
- Conforming clients and servers MUST support UTF-8 for the transfer and receipt of pathnames. Clients and servers MAY in addition give users a choice of specifying interpretation of pathnames in another encoding. Note that configuring clients and servers to use character sets / encoding other than UTF-8 is outside of the scope of this document. While it is recognized that in certain operational scenarios this may be desirable, this is left as a quality of implementation and operational issue.
- 準拠クライアントとサーバは、パス名の転送と受信をUTF-8をサポートしなければなりません。クライアントとサーバーはほかに、ユーザーが別のエンコーディングでパス名の解釈を指定する選択肢を与えることができます。 UTF-8以外の文字セットを使用するようにクライアントとサーバーの設定/エンコードは、この文書の範囲外であることに注意してください。それは、特定の動作シナリオでは、これは望ましいことが認識されているが、これは実装と運用問題の品質として残されています。
- Pathnames are sequences of bytes. The encoding of names that are valid UTF-8 sequences is assumed to be UTF-8. The character set of other names is undefined. Clients and servers, unless otherwise configured to support a specific native character set, MUST check for a valid UTF-8 byte sequence to determine if the pathname being presented is UTF-8.
- パス名は、バイトの配列です。有効なUTF-8シーケンスである名前のエンコーディングはUTF-8であると想定されます。他の名前の文字セットが定義されていません。クライアントとサーバーは、そうでない場合は、特定のネイティブの文字セットをサポートするように設定されない限り、提示されているパス名がUTF-8であるかどうかを判断するために有効なUTF-8バイトのシーケンスのためにチェックしなければなりません。
- To avoid data loss, clients and servers SHOULD use the UTF-8 encoded pathnames when unable to convert them to a usable code set.
- ときに使用可能なコードセットに変換することができないデータの損失を回避するために、クライアントとサーバは、UTF-8エンコードされたパス名を使用すべきです。
- There may be cases when the code set / encoding presented to the server or client cannot be determined. In such cases the raw bytes SHOULD be used.
- サーバーまたはクライアントに提示コードセット/エンコーディングが決定できないとき例があるかもしれません。このような場合には、生のバイトが使用されるべきです。
- Servers MUST support the UTF-8 feature in response to the FEAT command [RFC2389]. The UTF-8 feature is a line containing the exact string "UTF8". This string is not case sensitive, but SHOULD be transmitted in upper case. The response to a FEAT command SHOULD be:
- サーバーは、FEATコマンド[RFC2389]に応じて、UTF-8の機能をサポートしなければなりません。 UTF8機能は、正確な文字列「UTF8」を含む行です。この文字列は、大文字と小文字を区別しませんが、大文字で送信されるべきである（SHOULD）。 FEATコマンドへの応答は次のようになります。
C> feat
S> 211- <any descriptive text>
S> ...
S> UTF8
S> ...
S> 211 end
The ellipses indicate placeholders where other features may be included, but are NOT REQUIRED. The one space indentation of the feature lines is mandatory [RFC2389].
楕円は、他の機能が含まれていてもよいが、必須ではありませんプレースホルダを示しています。フィーチャーラインの1つのスペースのインデントは必須では[RFC2389]です。
- Mirror servers may want to exactly reflect the site that they are mirroring. In such cases servers MAY store and present the exact pathname bytes that it received from the main server.
- ミラーサーバは、まさに彼らがミラーリングされているサイトを反映することができます。そのような場合、サーバは、メインサーバから受信した正確なパス名のバイトを格納し、提示することができます。
- Clients which do not require display of pathnames are under no obligation to do so. Non-display clients do not need to conform to requirements associated with display.
- パス名の表示を必要としないクライアントは、そうする義務はありません。非表示クライアントは、ディスプレイに関連付けられている要件に準拠する必要はありません。
- Clients, which are presented UTF-8 pathnames by the server, SHOULD parse UTF-8 correctly and attempt to display the pathname within the limitation of the resources available.
- サーバがUTF-8のパス名を提示しているクライアントは、UTF-8を正しく解析し、利用可能なリソースの制限の範囲内のパス名を表示しようとすべきです。
- Clients MUST support the FEAT command and recognize the "UTF8" feature (defined in 3.2 above) to determine if a server supports UTF-8 encoding.
- クライアントは、FEATコマンドをサポートし、サーバーがUTF8エンコーディングをサポートしているかどうかを判断する（上記3.2で定義された）「UTF8」機能を認識しなければなりません。
- Character semantics of other names shall remain undefined. If a client detects that a server is non UTF-8, it SHOULD change its display appropriately. How a client implementation handles non UTF-8 is a quality of implementation issue. It MAY try to assume some other encoding, give the user a chance to try to assume something, or save encoding assumptions for a server from one FTP session to another.
- 他の名前のキャラクタ・セマンティクスは未定義のままなりません。クライアントは、サーバが非UTF-8であることを検出した場合、それが適切に表示を変更する必要があります。クライアントの実装がどのように処理するか非UTF-8は、実装の問題の質があります。これは、ユーザーに何かを想定し、または1つのFTPセッションから別のサーバーの仮定をコードする保存しようとする機会を与える、いくつかの他のエンコーディングを仮定しよう。
- Glyph rendering is outside the scope of this document. How a client presents characters it cannot display is a quality of implementation issue. This document RECOMMENDS that octets corresponding to non-displayable characters SHOULD be presented in URL %HH format defined in RFC 1738 [RFC1738]. They MAY, however, display them as question marks, with their UCS hexadecimal value, or in any other suitable fashion.
- グリフのレンダリングは、この文書の範囲外です。クライアントは、それが表示できない文字を提示どのように実装の問題の質があります。この文書では、非表示の文字に対応するオクテットは、RFC 1738 [RFC1738]で定義されたURL％HH形式で提示されるべきであることをお勧めします。彼らは、しかし、彼らのUCSの16進数の値を持つ、または任意の他の適切な方法で、疑問符としてそれらを表示することがあります。
- Many existing clients interpret 8-bit pathnames as being in the local character set. They MAY continue to do so for pathnames that are not valid UTF-8.
- 多くの既存のクライアントは、ローカルの文字セットであるものとして、8ビットのパス名を解釈します。彼らは有効なUTF-8でないパス名のためにそうし続けることができます。
The Character Set Workshop Report [RFC2130] suggests that clients and servers SHOULD negotiate a language for "greetings" and "error messages". This specification interprets the use of the term "error message", by RFC 2130, to mean any explanatory text string returned by server-PI in response to a user-PI command.
ワークショップ報告書[RFC2130]文字セットは、クライアントとサーバは、「挨拶」と「エラーメッセージ」の言語を交渉すべきであることを示唆しています。この仕様は、ユーザー-PIコマンドに応答して、サーバ-PIによって返された任意の説明テキスト文字列を意味するように、RFC 2130で、用語「エラーメッセージ」の使用を解釈します。
Implementers SHOULD note that FTP commands and numeric responses are protocol elements. As such, their use is not affected by any guidance expressed by this specification.
実装者は、FTPコマンドと数値の応答はプロトコル要素であることに注意すべきです。そのため、その使用は、本明細書で表現任意の指導の影響を受けません。
Language support of greetings and command responses shall be the default language supported by the server or the language supported by the server and selected by the client.
挨拶やコマンド応答の言語サポートは、デフォルトの言語は、サーバや言語、サーバーによってサポートされており、クライアントによって選択によりサポートされなければなりません。
It may be possible to achieve language support through a virtual host as described in [MLST]. However, an FTP server might not support virtual servers, or virtual servers might be configured to support an environment without regard for language. To allow language negotiation this specification defines a new LANG command. Clients and servers that comply with this specification MUST support the LANG command.
[MLST]に記載されているように、仮想ホストを介して言語サポートを実現することが可能です。しかし、FTPサーバ、仮想サーバをサポートしていない可能性があります、または仮想サーバーでは、言語に関係なく環境をサポートするように設定される可能性があります。言語ネゴシエーションを可能にするには、この仕様は新しいLANGコマンドを定義します。この仕様に準拠し、クライアントとサーバは、LANGコマンドをサポートしなければなりません。
A new command "LANG" is added to the FTP command set to allow server-FTP process to determine in which language to present server greetings and the textual part of command responses. The parameter associated with the LANG command SHALL be one of the language tags defined in RFC 1766 [RFC1766]. If a LANG command without a parameter is issued the server's default language will be used.
新しいコマンド「LANG」は、サーバFTPプロセスは、サーバーの挨拶やコマンド応答のテキストの一部を提示するためにどの言語で決定できるようにするためにFTPコマンドセットに追加されます。 LANGコマンドに関連付けられたパラメータは、RFC 1766 [RFC1766]で定義された言語タグの1つでなければなりません。パラメータなしLANGコマンドが発行されている場合は、サーバのデフォルト言語が使用されます。
Greetings and responses issued prior to language negotiation SHALL be in the server's default language. Paragraph 4.5 of [RFC2277] state that this "default language MUST be understandable by an English-speaking person". This specification RECOMMENDS that the server default language be English encoded using ASCII. This text may be augmented by text from other languages. Once negotiated, server-PI MUST return server messages and textual part of command responses in the negotiated language and encoded in UTF-8. Server-PI MAY wish to re-send previously issued server messages in the newly negotiated language.
前言語交渉に発行された挨拶と応答は、サーバのデフォルト言語でされなければなりません。この「デフォルトの言語は、英語圏の人が理解しなければなりません」という[RFC2277]状態のパラグラフ4.5。この仕様は、サーバのデフォルト言語は英語ASCIIを使用してエンコードすることをお勧めします。このテキストは、他の言語からのテキストによって増大することができます。一度交渉し、サーバー-PIは、サーバ・メッセージと交渉した言語でコマンド応答のテキストの一部を返し、UTF-8でエンコードしなければなりません。サーバー-PIは、新たに交渉された言語で、以前に発行されたサーバメッセージを再送信することもできます。
The LANG command only affects presentation of greeting messages and explanatory text associated with command responses. No attempt should be made by the server to translate protocol elements (FTP commands and numeric responses) or data transmitted over the data connection.
LANGコマンドは、グリーティングメッセージとコマンド応答に関連する説明テキストのプレゼンテーションに影響を与えます。試みはプロトコル要素（FTPコマンドと数値応答）、またはデータ接続を介して送信されたデータを変換するために、サーバによってなされるべきではありません。
User-PI MAY issue the LANG command at any time during an FTP session. In order to gain the full benefit of this command, it SHOULD be presented prior to authentication. In general, it will be issued after the HOST command [MLST]. Note that the issuance of a HOST or
ユーザー-PIは、FTPセッション中にいつでもLANGコマンドを発行することができます。このコマンドの完全な利益を得るためには、認証前に提示されるべきです。一般的には、HOSTコマンド[MLST]の後に発行されます。なお、HOSTの発行又は
REIN command [RFC959] will negate the affect of the LANG command. User-PI SHOULD be capable of supporting UTF-8 encoding for the language negotiated. Guidance on interpretation and rendering of UTF-8, defined in section 3, SHALL apply.
REINコマンドは、[RFC959] LANGコマンドの影響を否定します。ユーザー-PIは、交渉した言語のUTF-8エンコーディングをサポートすることが可能であるべきです。セクション3で定義されたUTF-8の解釈とレンダリングに関する指針は、適用しなければなりません。
Although NOT REQUIRED by this specification, a user-PI SHOULD issue a FEAT command [RFC2389] prior to a LANG command. This will allow the user-PI to determine if the server supports the LANG command and which language options.
この仕様で必須ではありませんが、ユーザー-PIは、LANGコマンドに先立ってFEATコマンド[RFC2389]を発行する必要があります。サーバはLANGコマンドと言語のオプションをサポートしている場合、これは、ユーザー-PIを決定することができます。
In order to aid the server in identifying whether a connection has been established with a client which conforms to this specification or an older client, user-PI MUST send a HOST [MLST] and/or LANG command prior to issuing any other command (other than FEAT [RFC2389]). If user-PI issues a HOST command, and the server's default language is acceptable, it need not issue a LANG command. However, if the implementation does not support the HOST command, a LANG command MUST be issued. Until server-PI is presented with either a HOST or LANG command it SHOULD assume that the user-PI does not comply with this specification.
接続は、本明細書または古いクライアントに準拠クライアントとの間で確立されているかどうかを識別する際にサーバを助けるために、ユーザ-PIは、他の（従来の任意の他のコマンドを発行するためにホスト[MLST]および/またはLANGコマンドを送信しなければなりませんFEAT [RFC2389]より）。ユーザー-PIは、HOSTコマンドを発行し、サーバのデフォルト言語が許容される場合には、LANGコマンドを発行する必要はありません。実装はHOSTコマンドをサポートしていない場合は、LANGコマンドを発行する必要があります。サーバー-PIは、HOSTまたはLANGコマンドのいずれかを提示するまでは、ユーザー-PIは、この仕様に準拠していないことを前提とすべきです。
The LANG command is defined as follows:
次のようにLANGコマンドが定義されています。
lang-command = "Lang" [(SP lang-tag)] CRLF lang-tag = Primary-tag *( "-" Sub-tag) Primary-tag = 1*8ALPHA Sub-tag = 1*8ALPHA
長いコマンド=「長い」[（SP長タグ）] CRLF長タグ=プライマリタグ*（「 - 」サブタグ）一次タグ= 1 * 8ALPHAサブタグ= 1 * 8ALPHA
lang-response = lang-ok / error-response lang-ok = "200" [SP *(%x00..%xFF) ] CRLF error-response = command-unrecognized / bad-argument / not-implemented / unsupported-parameter command-unrecognized = "500" [SP *(%x01..%xFF) ] CRLF bad-argument = "501" [SP *(%x01..%xFF) ] CRLF not-implemented = "502" [SP *(%x01..%xFF) ] CRLF unsupported-parameter = "504" [SP *(%x01..%xFF) ] CRLF
langの応答= langの-OK /エラー応答のlang-OK = "200" [SP *（％X00 ..％XFF）] CRLFエラー応答=コマンド認識されない/不良引数/実装しない/サポートされていないパラメータコマンド認識されない= "500" [SP *（％X01 ..％XFF）] CRLF不良引数が= "501" [SP *（％X01 ..％XFF）] CRLF-実装されていない= "502" [SP * （％X01 ..％XFF）] CRLFサポートされていないパラメータ= "504" [SP *（％X01 ..％XFF）] CRLF
The "lang" command word is case independent and may be specified in any character case desired. Therefore "LANG", "lang", "Lang", and "lAnG" are equivalent commands.
「LANG」コマンドワードは、ケースの独立であり、所望の任意の文字の場合に指定することができます。したがって、 "LANG"、 "LANG"、 "ラング"、および "LANGは、" 同等のコマンドです。
The OPTIONAL "Lang-tag" given as a parameter specifies the primary language tags and zero or more sub-tags as defined in [RFC1766]. As described in [RFC1766] language tags are treated as case insensitive. If omitted server-PI MUST use the server's default language.
パラメータとして与えられたOPTIONAL「ラングタグ」は、[RFC1766]で定義されるように一次言語タグおよびゼロ以上のサブタグを指定します。 [RFC1766]で説明されるように言語タグは大文字と小文字を区別しないとして扱われます。省略サーバー-PIはサーバのデフォルト言語を使用する必要がある場合。
Server-FTP responds to the "Lang" command with either "lang-ok" or "error-response". "lang-ok" MUST be sent if Server-FTP supports the "Lang" command and can support some form of the "lang-tag". Support SHOULD be as follows:
サーバFTPはどちらか「LANG-OK」または「エラー応答」と「ラング」コマンドに応答します。サーバFTPは「ラング」コマンドをサポートしており、「LANGタグ」のいくつかのフォームをサポートできる場合、「LANG-OK」を送らなければなりません。次のようにサポートする必要があります。
- If server-FTP receives "Lang" with no parameters it SHOULD return messages and command responses in the server default language.
- サーバFTPは、パラメータなしで「ラング」を受信した場合には、サーバのデフォルト言語でメッセージとコマンド応答を返すべきです。
- If server-FTP receives "Lang" with only a primary tag argument (e.g. en, fr, de, ja, zh, etc.), which it can support, it SHOULD return messages and command responses in the language associated with that primary tag. It is possible that server-FTP will only support the primary tag when combined with a sub-tag (e.g. en-US, en-UK, etc.). In such cases, server-FTP MAY determine the appropriate variant to use during the session. How server-FTP makes that determination is outside the scope of this specification. If server-FTP cannot determine if a sub-tag variant is appropriate it SHOULD return an "unsupported-parameter" (504) response.
- サーバFTPは、サポートできる唯一の主要なタグ引数（例えばEN、フランス、ドイツ、JA、ZH、など）、と「ラング」を受信した場合、その主に関連付けられている言語でメッセージおよびコマンド応答を返すべきです鬼ごっこ。サブタグと組み合わせた（JA-UK例えばEN-US、など）場合、サーバFTPのみプライマリタグをサポートすることが可能です。このような場合には、サーバFTPは、セッション中に使用するための適切なバリアントを決定することができます。どのようにサーバFTPは、決定はこの仕様の範囲外であることになります。サブタグ変異体が適切である場合、サーバFTPは判断できない場合は、「サポートされていないパラメータ」（504）レスポンスを返すべきです。
- If server-FTP receives "Lang" with a primary tag and sub-tag(s) argument, which is implemented, it SHOULD return messages and command responses in support of the language argument. It is possible that server-FTP can support the primary tag of the "Lang" argument but not the sub-tag(s). In such cases server-FTP MAY return messages and command responses in the most appropriate variant of the primary tag that has been implemented. How server-FTP makes that determination is outside the scope of this specification. If server-FTP cannot determine if a sub-tag variant is appropriate it SHOULD return an "unsupported-parameter" (504) response.
- サーバFTPが実装されている主なタグとサブタグ（複数可）の引数で「ラング」を受信した場合、それは言語の引数をサポートするメッセージとコマンド応答を返すべきです。サーバFTPは「ラング」の引数ではなく、サブタグ（複数可）の主なタグをサポートすることが可能です。そのような場合には、サーバFTPは実装されている主なタグの最も適切なバリアントでのメッセージとコマンド応答を返す場合があります。どのようにサーバFTPは、決定はこの仕様の範囲外であることになります。サブタグ変異体が適切である場合、サーバFTPは判断できない場合は、「サポートされていないパラメータ」（504）レスポンスを返すべきです。
For example if client-FTP sends a "LANG en-AU" command and server-FTP has implemented language tags en-US and en-UK it may decide that the most appropriate language tag is en-UK and return "200 en-AU not supported. Language set to en-UK". The numeric response is a protocol element and can not be changed. The associated string is for illustrative purposes only.
例えば、クライアントFTPは「LANG EN-AU」コマンドを送信した場合、サーバー・FTPは、それがエンAU最も適切な言語タグは、EN-英国であると判断し、」200を返すことがen-USで、専用英国の言語タグを実装していますサポートされていません。言語は、EN-UK」に設定します。数値応答は、プロトコル要素であり、変更することはできません。関連する文字列は、説明のみを目的としています。
Clients and servers that conform to this specification MUST support the LANG command. Clients SHOULD, however, anticipate receiving a 500 or 502 command response, in cases where older or non-compliant servers do not recognize or have not implemented the "Lang". A 501 response SHOULD be sent if the argument to the "Lang" command is not syntactically correct. A 504 response SHOULD be sent if the "Lang" argument, while syntactically correct, is not implemented. As noted above, an argument may be considered a lexicon match even though it is not an exact syntax match.
この仕様に準拠クライアントとサーバーはLANGコマンドをサポートしなければなりません。クライアントは、しかし、古いまたは非準拠のサーバーが認識していないか、「ラング」を実装していない場合には、500または502コマンド応答を受信することが予想されるべきです。 「ラング」コマンドの引数の構文が正しくない場合に501応答が送信されるべきです。構文的に正しく実装されていない状態504の応答は、「ラング」引数場合に送信されるべきです。上述のように、引数は、それが正確な構文が一致しない場合であっても辞書一致とみなすことができます。
A server-FTP process that supports the LANG command, and language support for messages and command responses, MUST include in the response to the FEAT command [RFC2389], a feature line indicating that the LANG command is supported and a fact list of the supported language tags. A response to a FEAT command SHALL be in the following format:
サーバー・FTPのLANGコマンドをサポートし、プロセス、およびメッセージおよびコマンド応答のための言語サポート、FEATコマンドに応答して含まなければならない[RFC2389]、LANGコマンドはサポートされていることを示す特徴ラインとサポートの事実リスト言語タグ。 FEATコマンドへの応答は、次の形式でなければなりません。
Lang-feat = SP "LANG" SP lang-fact CRLF
lang-fact = lang-tag ["*"] *(";" lang-tag ["*"])
lang-tag = Primary-tag *( "-" Sub-tag) Primary-tag= 1*8ALPHA Sub-tag = 1*8ALPHA
長いタグ=プライマリタグ*（「 - 」サブタグ）一次タグ= 1 * 8ALPHAサブタグ= 1 * 8ALPHA
The lang-feat response contains the string "LANG" followed by a language fact. This string is not case sensitive, but SHOULD be transmitted in upper case, as recommended in [RFC2389]. The initial space shown in the Lang-feat response is REQUIRED by the FEAT command. It MUST be a single space character. More or less space characters are not permitted. The lang-fact SHALL include the lang-tags which server-FTP can support. At least one lang-tag MUST be included with the FEAT response. The lang-tag SHALL be in the form described earlier in this document. The OPTIONAL asterisk, when present, SHALL indicate the current lang-tag being used by server-FTP for messages and responses.
LANG-偉業応答は言語事実に続く文字列「LANG」が含まれています。この文字列は、大文字と小文字は区別されず、[RFC2389]に推奨されているように、大文字で送信されなければなりません。ラング - 偉業応答に示す初期空間がFEATコマンドによって要求されています。これは、単一の空白文字でなければなりません。多かれ少なかれ、スペース文字は許可されていません。 LANG-事実は、サーバFTPがサポートできるLANGタグを含まなければなりません。少なくとも一つのlang-タグがFEAT応答に含まれなければなりません。 langのタグは、この文書で先に説明した形態でなければなりません。オプションアスタリスクは、存在する場合、メッセージと応答のために、サーバ・FTPで使用されている現在のlang-タグを表示しなければなりません。
C> feat
S> 211- <any descriptive text>
S> ...
S> LANG EN*
S> ...
S> 211 end
In this example server-FTP can only support English, which is the current language (as shown by the asterisk) being used by the server for messages and command responses.
この例では、サーバFTPは、メッセージのみとコマンド応答用のサーバーによって使用されている現在の言語（アスタリスクで示す）である英語を、サポートすることができます。
C> feat
S> 211- <any descriptive text>
S> ...
S> LANG EN*;FR
S> ...
S> 211 end
C> LANG fr S> 200 Le response sera changez au francais
C> LANG FR S> 200レスポンスがフランス語に変更されます
C> feat S> 211- <quelconque descriptif texte> S> ... S> LANG EN;FR* S> ... S> 211 end
C>偉業S> 211- <任意の説明テキスト> S> ... S> LANG EN; FR * S> ... S> 211終了
In this example server-FTP supports both English and French as shown by the initial response to the FEAT command. The asterisk indicates that English is the current language in use by server-FTP. After a LANG command is issued to change the language to French, the FEAT response shows French as the current language in use.
FEATコマンドに対する初期応答によって示されるように、この例では、サーバFTPは、英語とフランス語の両方をサポートしています。アスタリスクは英語がサーバFTPが現在使用している言語であることを示しています。 LANGコマンドはフランス語に言語を変更するために発行された後、FEAT応答は、現在使用中の言語としてフランス語を示しています。
In the above examples ellipses indicate placeholders where other features may be included, but are NOT REQUIRED.
上記の例では楕円は、他の特徴が含まれていてもよいが、必要ではないプレースホルダを示しています。
5 Security Considerations
5セキュリティに関する考慮事項
This document addresses the support of character sets beyond 1 byte and a new language negotiation command. Conformance to this document should not induce a security risk.
この文書では、1バイトと新しい言語negotiationコマンドを越えた文字セットのサポートに対応しています。このドキュメントへの適合性は、セキュリティ上のリスクを誘発してはなりません。
6 Acknowledgments
6つの謝辞
The following people have contributed to this document:
次の人は、この文書に貢献しています：
D. J. Bernstein Martin J. Duerst Mark Harris Paul Hethmon Alun Jones Gregory Lundberg James Matthews Keith Moore Sandra O'Donnell Benjamin Riefenstahl Stephen Tihor
D. J.バーンスタイン・マーティンJ. Duerstマーク・ハリス・ポールHethmonアラン・ジョーンズグレゴリー・ランドバーグジェームズ・マシューズキース・ムーアサンドラ・オドネルベンジャミン・リーフェンシュタールスティーブンTihor
(and others from the FTPEXT working group)
（FTPEXTワーキンググループからなど）
7 Glossary
7用語集
BIDI - abbreviation for Bi-directional, a reference to mixed right-to-left and left-to-right text.
BIDI - 双方向の略語、混合右から左、左から右のテキストを参照。
Character Set - a collection of characters used to represent textual information in which each character has a numeric value
文字セット - 各文字が数値を持っているテキスト情報を表すために使用される文字の集合
Code Set - (see character set).
コードセット - （文字セットを参照してください）。
Glyph - a character image represented on a display device.
グリフ - 表示装置上に表される文字画像。
I18N - "I eighteen N", the first and last letters of the word "internationalization" and the eighteen letters in between.
I18N - 「I 18 N」、単語「国際化」の最初と最後の文字との間で18の文字。
UCS-2 - the ISO/IEC 10646 two octet Universal Character Set form.
UCS-2 - ISO / IEC 10646 2オクテットユニバーサル・キャラクタ・セット・フォーム。
UCS-4 - the ISO/IEC 10646 four octet Universal Character Set form.
UCS-4 - ISO / IEC 10646 4つのオクテットユニバーサル・キャラクタ・セット・フォーム。
UTF-8 - the UCS Transformation Format represented in 8 bits.
UTF-8から8ビットで表現UCS変換フォーマット。
TF-16 - A 16-bit format including the BMP (directly encoded) and surrogate pairs to represent characters in planes 01-16; equivalent to Unicode.
TF-16 - BMP（直接エンコード）及び平面01-16内の文字を表すためにサロゲートペアを含む16ビット・フォーマット、ユニコードに相当。
8 Bibliography
8参考文献
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[ASCII] ANSI X3.4:1986 Coded Character Sets - 7 Bit American National Standard Code for Information Interchange (7- bit ASCII)
[ASCII]のANSI X3.4：1986コード化文字セット - 7ビットの情報交換用米国標準コード（7ビットASCII）
[ISO-8859] ISO 8859. International standard -- Information processing -- 8-bit single-byte coded graphic character sets -- Part 1:Latin alphabet No. 1 (1987) -- Part 2: Latin alphabet No. 2 (1987) -- Part 3: Latin alphabet No. 3 (1988) -- Part 4: Latin alphabet No. 4 (1988) -- Part 5: Latin/Cyrillic alphabet (1988) -- Part 6: Latin/Arabic alphabet (1987) -- Part : Latin/Greek alphabet (1987) -- Part 8: Latin/Hebrew alphabet (1988) -- Part 9: Latin alphabet No. 5 (1989) -- Part10: Latin alphabet No. 6 (1992)
[ISO-8859] ISO 8859国際標準 - 情報処理 - 8ビット単一バイト符号化された図形文字セット - パート1：ラテンアルファベット1号（1987） - 第2部：ラテンアルファベット番号2（ 1987） - 第3部：ラテンアルファベット3号（1988） - 第4部：ラテンアルファベット4号（1988） - 第5部：ラテン/キリルアルファベット（1988） - パート6：ラテン/アラビア文字（ 1987年） - パート：ラテン語/ギリシャ語のアルファベット（1987） - パート8：ラテン/ヘブライ語のアルファベット（1988） - パート9：ラテンアルファベット5号（1989） - Part10：ラテンアルファベットの第6号（1992）
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ISO-10646] ISO/IEC 10646-1:1993. International standard -- Information technology -- Universal multiple-octet coded character set (UCS) -- Part 1: Architecture and basic multilingual plane.
[ISO-10646] ISO / IEC 10646-1：1993。国際標準 - 情報技術 - ユニバーサルマルチオクテット符号化文字集合（UCS） - 第1部：アーキテクチャと基本多言語面。
[MLST] Elz, R. and P. Hethmon, "Extensions to FTP", Work in Progress.
[MLST]エルツ、R.とP. Hethmon、 "FTPへの拡張" が進行中で働いています。
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC854]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[RFC959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル（FTP）"、STD 9、RFC 959、1985年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H.、 "言語識別のためのタグ"、RFC 1766、1995年3月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M. and P. Svanberg, "Character Set Workshop Report", RFC 2130, April 1997.
[RFC2130]ウイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、クリスピン、M.およびP. Svanberg、 "ワークショップ報告文字セット"、RFC 2130、1997年4月。
[RFC2277] Alvestrand, H., " IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、RFC 2277、1998年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC2389] Elz, R. and P. Hethmon, "Feature Negotiation Mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2389]エルツ、R.とP. Hethmon、 "ファイル転送プロトコルの機能ネゴシエーションメカニズム"、RFC 2389、1998年8月。
[UNICODE] The Unicode Consortium, "The Unicode Standard - Version 2.0", Addison Westley Developers Press, July 1996.
[UNICODE]のUnicodeコンソーシアム、 "Unicode標準 - バージョン2.0"、アディソンウェストリー開発者プレス、1996年7月。
[UTF-8] ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transformation Format 8 (UTF-8).
[UTF-8] ISO / IEC 10646-1：1993改正2（1996）。 UCS変換フォーマット8（UTF-8）。
9 Author's Address
9著者のアドレス
Bill Curtin JIEO Attn: JEBBD Ft. Monmouth, N.J. 07703-5613
ビル・カーティンJIEOの事務局担当：JEBBDフォート。モンマス、ニュージャージ州07703-5613
EMail: curtinw@ftm.disa.mil
メールアドレス：curtinw@ftm.disa.mil
Annex A - Implementation Considerations
附属書A - 実装に関する考慮事項
A.1 General Considerations
A.1一般的な考慮事項
- Implementers should ensure that their code accounts for potential problems, such as using a NULL character to terminate a string or no longer being able to steal the high order bit for internal use, when supporting the extended character set.
- Implementersは、それらのコードは、拡張文字セットをサポートしている場合、内部使用のために上位ビットを盗むことができることはもはや文字列を終了するNULL文字を使用するかなどの潜在的な問題、を占めていることを確認すべきです。
- Implementers should be aware that there is a chance that pathnames that are non UTF-8 may be parsed as valid UTF-8. The probabilities are low for some encoding or statistically zero to zero for others. A recent non-scientific analysis found that EUC encoded Japanese words had a 2.7% false reading; SJIS had a 0.0005% false reading; other encoding such as ASCII or KOI-8 have a 0% false reading. This probability is highest for short pathnames and decreases as pathname size increases. Implementers may want to look for signs that pathnames which parse as UTF-8 are not valid UTF-8, such as the existence of multiple local character sets in short pathnames. Hopefully, as more implementations conform to UTF-8 transfer encoding there will be a smaller need to guess at the encoding.
- 実装者は、非UTF-8ですパス名が有効なUTF-8として解析することができる可能性があることを認識する必要があります。確率は他のためのいくつかの符号化又は統計的にゼロゼロにするための低されています。最近の非科学的な分析では、EUCエンコードされた日本語の単語は2.7％偽の読書を持っていたことが分かりました。 SJISは0.0005％偽の読書を持っていました。例えばASCII又はKOI-8などの他のエンコーディングは0％偽読取を有します。この確率は、短いパス名のための最も高く、パス名のサイズが増加するにつれて減少します。実装者はUTF-8として解析パス名が有効でない兆候を見てみたいことがありますUTF-8、このような短いパス名で複数のローカル文字セットの存在として。うまくいけば、より多くの実装がUTF-8転送符号化に適合よう符号化を推測するために小さい必要があるだろう。
- Client developers should be aware that it will be possible for pathnames to contain mixed characters (e.g. //Latin1DirectoryName/HebrewFileName). They should be prepared to handle the Bi-directional (BIDI) display of these character sets (i.e. right to left display for the directory and left to right display for the filename). While bi-directional display is outside the scope of this document and more complicated than the above example, an algorithm for bi-directional display can be found in the UNICODE 2.0 [UNICODE] standard. Also note that pathnames can have different byte ordering yet be logically and display-wise equivalent due to the insertion of BIDI control characters at different points during composition. Also note that mixed character sets may also present problems with font swapping.
- クライアント開発者は、パス名が混在文字（例えば// Latin1DirectoryName / HebrewFileName）を含んすることが可能になることに注意してください。彼らは、これらの文字セットの双方向（BIDI）ディスプレイ（すなわち、ディレクトリの左側のディスプレイに右とファイル名を右表示するには、左）を処理するために準備しなければなりません。双方向ディスプレイは、本書及び上記の例よりも複雑の範囲外であるが、双方向表示するためのアルゴリズムは、UNICODE 2.0 [UNICODE]規格に見出すことができます。また、パス名が原因構図中の異なる点でBIDI制御文字の挿入にはまだ論理的に可能と表示ワイズ同等異なるバイトオーダーを持つことができることに注意してください。また、混合文字セットは、フォントスワッピングと存在の問題にも可能性があります。
- A server that copies pathnames transparently from a local filesystem may continue to do so. It is then up to the local file creators to use UTF-8 pathnames.
- コピーがローカルファイルシステムから透過的にパス名サーバがそうし続けることがあります。その後、ローカルファイルクリエイターまでUTF-8のパス名を使用することです。
- Servers can supports charset labeling of files and/or directories, such that different pathnames may have different charsets. The server should attempt to convert all pathnames to UTF-8, but if it can't then it should leave that name in its raw form.
- サーバは異なるパス名が異なる文字セットを持つことができるように、ファイルおよび/またはディレクトリのcharsetラベルを、サポートすることができます。サーバーは、UTF-8へのすべてのパス名を変換しようとすべきであるが、それは、それはその生の形式でその名を残す必要があることができない場合。
- Some server's OS do not mandate character sets, but allow administrators to configure it in the FTP server. These servers should be configured to use a particular mapping table (either external or built-in). This will allow the flexibility of defining different charsets for different directories.
- 一部のサーバーのOSは、文字セットを義務付けるが、管理者は、FTPサーバにそれを設定することはできません。これらのサーバーは、（外部または内蔵のいずれか）の特定のマッピングテーブルを使用するように構成されるべきです。これは、異なるディレクトリの異なる文字セットを定義する柔軟性を許可します。
- If the server's OS does not mandate the character set and the FTP server cannot be configured, the server should simply use the raw bytes in the file name. They might be ASCII or UTF-8.
- サーバのOSは、文字セットとFTPサーバを設定することはできません強制しない場合は、サーバーは、単にファイル名に生のバイトを使用する必要があります。彼らは、ASCIIまたはUTF-8であるかもしれません。
- If the server is a mirror, and wants to look just like the site it is mirroring, it should store the exact file name bytes that it received from the main server.
- サーバーがミラーであり、そしてちょうどそれがミラーリングされたサイトのように見えるしたい場合は、それがメインサーバから受信し、正確なファイル名のバイトを保存する必要があります。
A.2 Transition Considerations
A.2の移行に関する注意事項
- Servers which support this specification, when presented a pathname from an old client (one which does not support this specification), can nearly always tell whether the pathname is in UTF-8 (see B.1) or in some other code set. In order to support these older clients, servers may wish to default to a non UTF-8 code set. However, how a server supports non UTF-8 is outside the scope of this specification.
- この仕様をサポートするサーバーは、古いクライアント（この仕様をサポートしていない1）からのパス名を発表したときに、ほとんど常にパス名がUTF-8（B.1を参照）または他のいくつかのコードセットにあるかどうかを伝えることができます。これらの古いクライアントをサポートするために、サーバは、非UTF-8コードセットをデフォルトにすることを望むかもしれません。しかし、サーバが非UTF-8をサポートする方法この仕様の範囲外です。
- Clients which support this specification will be able to determine if the server can support UTF-8 (i.e. supports this specification) by the ability of the server to support the FEAT command and the UTF8 feature (defined in 3.2). If the newer clients determine that the server does not support UTF-8 it may wish to default to a different code set. Client developers should take into consideration that pathnames, associated with older servers, might be stored in UTF-8. However, how a client supports non UTF-8 is outside the scope of this specification.
- サーバは、FEATコマンドと（3.2で定義）UTF8機能をサポートするサーバの能力によって（すなわち、この仕様をサポート）UTF8をサポートすることができる場合は、この仕様をサポートするクライアントは、決定することができるであろう。新しいクライアントは、サーバーがUTF-8をサポートしていないと判断した場合には、異なるコードセットをデフォルトにすることを望むかもしれません。クライアント開発者は、古いサーバに関連付けられている、パス名を考慮に入れる必要があり、UTF-8に格納される可能性があります。しかし、クライアントが非UTF-8をサポートする方法この仕様の範囲外です。
- Clients and servers can transition to UTF-8 by either converting to/from the local encoding, or the users can store UTF-8 filenames. The former approach is easier on tightly controlled file systems (e.g. PCs and MACs). The latter approach is easier on more free form file systems (e.g. Unix).
- クライアントとサーバは、ローカルエンコーディングへ/から変換する、またはユーザーがUTF-8ファイル名を格納することができることにより、UTF-8に移行することができます。前者のアプローチは、厳密に制御されたファイルシステム（例えば、PCやMac）に容易です。後者のアプローチは、より自由な形式のファイルシステム（例えばUNIX）に容易です。
- For interactive use attention should be focused on user interface and ease of use. Non-interactive use requires a consistent and controlled behavior.
- 対話的な使用の注意のためのユーザインターフェースと使いやすさに焦点を置くべきです。非対話型の使用は、一貫して制御動作を必要とします。
- There may be many applications which reference files under their old raw pathname (e.g. linked URLs). Changing the pathname to UTF-8 will cause access to the old URL to fail. A solution may be for the server to act as if there was 2 different pathnames associated with the file. This might be done internal to the server on controlled file systems or by using symbolic links on free form systems. While this approach may work for single file transfer non-interactive use, a non-interactive transfer of all of the files in a directory will produce duplicates. Interactive users may be presented with lists of files which are double the actual number files.
- 彼らの古い生のパス名（例えば、リンクされたURL）の下にあるファイルを参照する多くのアプリケーションがあるかもしれません。 UTF-8へのパス名を変更すると、古いURLへのアクセスが失敗します。ファイルに関連付けられた2つの異なるパス名があった場合、サーバが作用するため、溶液であってもよいです。これは、制御されたファイル・システム上またはフリーフォーム・システム上のシンボリックリンクを使用して、サーバーの内部で行われることがあります。このアプローチは、単一のファイル転送、非対話型の使用のために働くかもしれないが、ディレクトリ内のファイルのすべての非対話型の転送は、重複を生成します。インタラクティブなユーザーがダブル実際の数のファイルであるファイルのリストを提示することができます。
Annex B - Sample Code and Examples
附属書B - サンプルコードと例
B.1 Valid UTF-8 check
B.1有効なUTF-8チェック
The following routine checks if a byte sequence is valid UTF-8. This is done by checking for the proper tagging of the first and following bytes to make sure they conform to the UTF-8 format. It then checks to assure that the data part of the UTF-8 sequence conforms to the proper range allowed by the encoding. Note: This routine will not detect characters that have not been assigned and therefore do not exist.
次のルーチンのチェックバイトシーケンスが有効なUTF-8である場合。これは、彼らがUTF-8形式に準拠を確認するために最初と次のバイトの適切なタグ付けをチェックすることによって行われます。その後、UTF-8配列のデータ部分を符号化することによって許容適正範囲に準拠していることを保証するためにチェックします。注意：このルーチンは、割り当てられていないため、存在しない文字を検出しません。
int utf8_valid(const unsigned char *buf, unsigned int len)
{
const unsigned char *endbuf = buf + len;
unsigned char byte2mask=0x00, c;
int trailing = 0; // trailing (continuation) bytes to follow
while (buf != endbuf)
{
c = *buf++;
if (trailing)
if ((c&0xC0) == 0x80) // Does trailing byte follow UTF-8 format?
{if (byte2mask) // Need to check 2nd byte for proper range?
if (c&byte2mask) // Are appropriate bits set?
byte2mask=0x00;
else
return 0;
trailing--; }
else
return 0;
else
if ((c&0x80) == 0x00) continue; // valid 1 byte UTF-8
else if ((c&0xE0) == 0xC0) // valid 2 byte UTF-8
if (c&0x1E) // Is UTF-8 byte in
// proper range?
trailing =1;
else
return 0;
else if ((c&0xF0) == 0xE0) // valid 3 byte UTF-8
{if (!(c&0x0F)) // Is UTF-8 byte in
// proper range?
byte2mask=0x20; // If not set mask
// to check next byte
trailing = 2;}
else if ((c&0xF8) == 0xF0) // valid 4 byte UTF-8
{if (!(c&0x07)) // Is UTF-8 byte in
// proper range?
byte2mask=0x30; // If not set mask
// to check next byte
trailing = 3;}
else if ((c&0xFC) == 0xF8) // valid 5 byte UTF-8
{if (!(c&0x03)) // Is UTF-8 byte in
// proper range?
byte2mask=0x38; // If not set mask
// to check next byte
trailing = 4;}
else if ((c&0xFE) == 0xFC) // valid 6 byte UTF-8
{if (!(c&0x01)) // Is UTF-8 byte in
// proper range?
byte2mask=0x3C; // If not set mask
// to check next byte
trailing = 5;}
else return 0;
}
return trailing == 0;
}
B.2 Conversions
B.2の変換
The code examples in this section closely reflect the algorithm in ISO 10646 and may not present the most efficient solution for converting to / from UTF-8 encoding. If efficiency is an issue, implementers should use the appropriate bitwise operators.
このセクションのコード例は、密接にISO 10646にアルゴリズムを反映し、UTF-8エンコーディングから/へ変換するための最も効率的な解決策を提示しなくてもよいです。効率が問題である場合、実装者は、適切なビット演算子を使用する必要があります。
Additional code examples and numerous mapping tables can be found at the Unicode site, HTTP://www.unicode.org or FTP://unicode.org.
追加のコード例と多数のマッピングテーブルは、Unicodeサイト、HTTP://www.unicode.orgまたはFTP://unicode.orgで見つけることができます。
Note that the conversion examples below assume that the local character set supported in the operating system is something other than UCS2/UTF-16. There are some operating systems that already support UCS2/UTF-16 (notably Plan 9 and Windows NT). In this case no conversion will be necessary from the local character set to the UCS.
変換の例は、以下のオペレーティングシステムでサポートされているローカル文字セットは、UCS2 / UTF-16以外の何かがあることを前提としています。すでにUCS2 / UTF-16をサポートするいくつかのオペレーティングシステムがあります（特に9を計画し、Windows NT）。この場合、変換はUCSに設定されたローカルの文字から必要ではないでしょう。
B.2.1 Conversion from Local Character Set to UTF-8
UTF-8に設定されたローカル文字からB.2.1変換
Conversion from the local filesystem character set to UTF-8 will normally involve a two step process. First convert the local character set to the UCS; then convert the UCS to UTF-8.
UTF-8に設定されたローカルファイルシステムの文字からの変換は、通常、2段階のプロセスが関与します。まずUCSに設定されたローカルの文字を変換します。その後、UTF-8にUCSを変換します。
The first step in the process can be performed by maintaining a mapping table that includes the local character set code and the corresponding UCS code. For instance the ISO/IEC 8859-8 [ISO-8859] code for the Hebrew letter "VAV" is 0xE4. The corresponding 4 byte ISO/IEC 10646 code is 0x000005D5.
プロセスの最初のステップは、ローカル文字セットのコードと、対応するUCSコードを含むマッピングテーブルを維持することによって行うことができます。例えばヘブライ文字 "VAV" のISO / IEC 8859-8 [ISO-8859]コード0xE4です。対応する4バイトのISO / IEC 10646のコードは0x000005D5です。
The next step is to convert the UCS character code to the UTF-8 encoding. The following routine can be used to determine and encode the correct number of bytes based on the UCS-4 character code:
次のステップは、UTF-8エンコーディングにUCS文字コードを変換することです。次のルーチンは、UCS-4文字コードに基づいてバイトの正確な数を決定し、符号化するために使用することができます。
unsigned int ucs4_to_utf8 (unsigned long *ucs4_buf, unsigned int ucs4_len, unsigned char *utf8_buf)
unsigned int型ucs4_to_utf8（符号なしlong * ucs4_buf、unsigned int型ucs4_len、unsigned char型* utf8_buf）
{ const unsigned long *ucs4_endbuf = ucs4_buf + ucs4_len; unsigned int utf8_len = 0; // return value for UTF8 size unsigned char *t_utf8_buf = utf8_buf; // Temporary pointer // to load UTF8 values
{CONSTのunsigned long * ucs4_endbuf = ucs4_buf + ucs4_len。 unsigned int型utf8_len = 0; // UTF8サイズunsigned char型の戻り値* t_utf8_buf = utf8_buf。 //一時的なポインタ// UTF8値をロードします
while (ucs4_buf != ucs4_endbuf)
{
if ( *ucs4_buf <= 0x7F) // ASCII chars no conversion needed
{
*t_utf8_buf++ = (unsigned char) *ucs4_buf;
utf8_len++;
ucs4_buf++;
}
else
if ( *ucs4_buf <= 0x07FF ) // In the 2 byte utf-8 range
{
*t_utf8_buf++= (unsigned char) (0xC0 + (*ucs4_buf/0x40));
*t_utf8_buf++= (unsigned char) (0x80 + (*ucs4_buf%0x40));
utf8_len+=2;
ucs4_buf++;
}
else
if ( *ucs4_buf <= 0xFFFF ) /* In the 3 byte utf-8 range. The
values 0x0000FFFE, 0x0000FFFF
and 0x0000D800 - 0x0000DFFF do
not occur in UCS-4 */
{
*t_utf8_buf++= (unsigned char) (0xE0 +
(*ucs4_buf/0x1000));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x40)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 + (*ucs4_buf%0x40));
utf8_len+=3;
ucs4_buf++;
}
else
if ( *ucs4_buf <= 0x1FFFFF ) //In the 4 byte utf-8 range
{
*t_utf8_buf++= (unsigned char) (0xF0 +
(*ucs4_buf/0x040000));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x10000)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x40)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 + (*ucs4_buf%0x40));
utf8_len+=4;
ucs4_buf++;
}
else
if ( *ucs4_buf <= 0x03FFFFFF )//In the 5 byte utf-8 range
{
*t_utf8_buf++= (unsigned char) (0xF8 +
(*ucs4_buf/0x01000000));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x040000)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x1000)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x40)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
(*ucs4_buf%0x40));
utf8_len+=5;
ucs4_buf++;
}
else
if ( *ucs4_buf <= 0x7FFFFFFF )//In the 6 byte utf-8 range
{
*t_utf8_buf++= (unsigned char)
(0xF8 +(*ucs4_buf/0x40000000));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x01000000)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x040000)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x1000)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
((*ucs4_buf/0x40)%0x40));
*t_utf8_buf++= (unsigned char) (0x80 +
(*ucs4_buf%0x40));
utf8_len+=6;
ucs4_buf++;
} } return (utf8_len); }
}}戻り（utf8_len）。 }
B.2.2 Conversion from UTF-8 to Local Character Set
B.2.2変換UTF-8からローカル文字セットへ
When moving from UTF-8 encoding to the local character set the reverse procedure is used. First the UTF-8 encoding is transformed into the UCS-4 character set. The UCS-4 is then converted to the local character set from a mapping table (i.e. the opposite of the table used to form the UCS-4 character code).
ローカル文字にUTF-8エンコーディングから移動するとき逆の手順が使用されている設定。まずUTF-8エンコーディングは、UCS-4文字セットに変換されます。 UCS-4は、マッピングテーブルから設定されたローカルの文字に変換され（すなわち、UCS-4文字コードを形成するために使用されるテーブルの反対側）。
To convert from UTF-8 to UCS-4 the free bits (those that do not define UTF-8 sequence size or signify continuation bytes) in a UTF-8 sequence are concatenated as a bit string. The bits are then distributed into a four-byte sequence starting from the least significant bits. Those bits not assigned a bit in the four-byte sequence are padded with ZERO bits. The following routine converts the UTF-8 encoding to UCS-4 character codes:
UTF-8からUCS-4に変換するUTF-8シーケンス内の空きビット（UTF-8配列のサイズを定義したり、継続バイトを意味しないもの）は、ビット列として連結されています。ビットは、最下位ビットから始まる4バイトシーケンスに分配されます。 4バイトシーケンスのビットが割り当てられていないこれらのビットは、ゼロビットでパディングされます。以下のルーチンは、UCS-4文字コードをUTF-8エンコーディングを変換します。
int utf8_to_ucs4 (unsigned long *ucs4_buf, unsigned int utf8_len, unsigned char *utf8_buf) {
INT utf8_to_ucs4（unsigned long型* ucs4_buf、unsigned int型utf8_len、unsigned char型* utf8_buf）{
const unsigned char *utf8_endbuf = utf8_buf + utf8_len;
unsigned int ucs_len=0;
while (utf8_buf != utf8_endbuf) {
しばらく（utf8_buf！= utf8_endbuf）{
if ((*utf8_buf & 0x80) == 0x00) /*ASCII chars no conversion
needed */
{
*ucs4_buf++ = (unsigned long) *utf8_buf;
utf8_buf++;
ucs_len++;
}
else
if ((*utf8_buf & 0xE0)== 0xC0) //In the 2 byte utf-8 range
{
*ucs4_buf++ = (unsigned long) (((*utf8_buf - 0xC0) * 0x40)
+ ( *(utf8_buf+1) - 0x80));
utf8_buf += 2;
ucs_len++;
}
else
if ( (*utf8_buf & 0xF0) == 0xE0 ) /*In the 3 byte utf-8
range */
{
*ucs4_buf++ = (unsigned long) (((*utf8_buf - 0xE0) * 0x1000)
+ (( *(utf8_buf+1) - 0x80) * 0x40)
+ ( *(utf8_buf+2) - 0x80));
utf8_buf+=3;
ucs_len++;
}
else
if ((*utf8_buf & 0xF8) == 0xF0) /* In the 4 byte utf-8
range */
{
*ucs4_buf++ = (unsigned long)
(((*utf8_buf - 0xF0) * 0x040000)
+ (( *(utf8_buf+1) - 0x80) * 0x1000)
+ (( *(utf8_buf+2) - 0x80) * 0x40)
+ ( *(utf8_buf+3) - 0x80));
utf8_buf+=4;
ucs_len++;
}
else
if ((*utf8_buf & 0xFC) == 0xF8) /* In the 5 byte utf-8
range */
{
*ucs4_buf++ = (unsigned long)
(((*utf8_buf - 0xF8) * 0x01000000)
+ ((*(utf8_buf+1) - 0x80) * 0x040000)
+ (( *(utf8_buf+2) - 0x80) * 0x1000)
+ (( *(utf8_buf+3) - 0x80) * 0x40)
+ ( *(utf8_buf+4) - 0x80));
utf8_buf+=5;
ucs_len++;
}
else
if ((*utf8_buf & 0xFE) == 0xFC) /* In the 6 byte utf-8
range */
{
*ucs4_buf++ = (unsigned long)
(((*utf8_buf - 0xFC) * 0x40000000)
+ ((*(utf8_buf+1) - 0x80) * 0x010000000)
+ ((*(utf8_buf+2) - 0x80) * 0x040000)
+ (( *(utf8_buf+3) - 0x80) * 0x1000)
+ (( *(utf8_buf+4) - 0x80) * 0x40)
+ ( *(utf8_buf+5) - 0x80));
utf8_buf+=6;
ucs_len++;
}
} return (ucs_len); }
} Retarn（utss_len）。 }
B.2.3 ISO/IEC 8859-8 Example
B.2.3 ISO / IEC 8859-8の例
This example demonstrates mapping ISO/IEC 8859-8 character set to UTF-8 and back to ISO/IEC 8859-8. As noted earlier, the Hebrew letter "VAV" is convertd from the ISO/IEC 8859-8 character code 0xE4 to the corresponding 4 byte ISO/IEC 10646 code of 0x000005D5 by a simple lookup of a conversion/mapping file.
この例ではUTF-8にして戻ってISO / IEC 8859-8に設定されたマッピングISO / IEC 8859-8の文字を示しています。先に述べたように、ヘブライ語の文字「VAVは」変換/マッピングファイルの簡単な検索によって、対応する4バイト0x000005D5のISO / IEC 10646のコードにISO / IEC 8859-8文字コード0xE4からconvertdされます。
The UCS-4 character code is transformed into UTF-8 using the ucs4_to_utf8 routine described earlier by:
UCS-4文字コードによって前述しucs4_to_utf8ルーチンを使用してUTF-8に変換されます。
1. Because the UCS-4 character is between 0x80 and 0x07FF it will map to a 2 byte UTF-8 sequence. 2. The first byte is defined by (0xC0 + (0x000005D5 / 0x40)) = 0xD7.
1. UCS-4文字が0x80とし、0x07FFの間にあるので、それは2バイトUTF-8シーケンスにマップされます。 2.最初のバイトは、（0xC0の+（0x000005D5 / 0x40の））= 0xD7によって定義されます。
The UTF-8 encoding is transferred back to UCS-4 by using the utf8_to_ucs4 routine described earlier by:
UTF-8エンコーディングをすることによって前述しutf8_to_ucs4ルーチンを使用して、UCS-4に戻されます。
1. Because the first byte of the sequence, when the '&' operator with a value of 0xE0 is applied, will produce 0xC0 (0xD7 & 0xE0 = 0xC0) the UTF-8 is a 2 byte sequence. 2. The four byte UCS-4 character code is produced by (((0xD7 - 0xC0) * 0x40) + (0x95 -0x80)) = 0x000005D5.
シーケンスの最初のバイトは、0xE0となっの値に「＆」演算子が適用される場合、0xC0の（0xD7＆0xE0となっ= 0xC0の）を生成するため1. UTF-8は、2バイトのシーケンスです。 2. 4バイトUCS-4文字コードがによって生成される（（（0xD7 - 0xC0の）* 0x40の）+（0x95 -0x80））= 0x000005D5。
Finally, the UCS-4 character code is converted to ISO/IEC 8859-8 character code (using the mapping table which matches ISO/IEC 8859-8 to UCS-4 ) to produce the original 0xE4 code for the Hebrew letter "VAV".
最後に、UCS-4文字コードは、ヘブライ文字「VAV」の元0xE4コードを生成する（UCS-4にISO / IEC 8859-8に一致するマッピングテーブルを使用して）ISO / IEC 8859-8の文字コードに変換されます。 。
B.2.4 Vendor Codepage Example
B.2.4ベンダーコードページの例
This example demonstrates the mapping of a codepage to UTF-8 and back to a vendor codepage. Mapping between vendor codepages can be done in a very similar manner as described above. For instance both the PC and Mac codepages reflect the character set from the Thai standard TIS 620-2533. The character code on both platforms for the Thai letter "SO SO" is 0xAB. This character can then be mapped into the UCS-4 by way of a conversion/mapping file to produce the UCS-4 code of 0x0E0B.
この例ではUTF-8にして戻ってベンダーのコードページにコードページのマッピングを示しています。上記のようにベンダーコードページとの間のマッピングは、非常に類似した方法で行うことができます。たとえば、PCとMacの両方のコードページは、タイの標準TIS 620から2533の文字セットを反映しています。タイ文字のため、両方のプラットフォーム上の文字コードは「SO SO」0xABです。この文字は、その後0x0E0BのUCS-4コードを生成する変換/マッピングファイルの方法によってUCS-4にマッピングすることができます。
The UCS-4 character code is transformed into UTF-8 using the ucs4_to_utf8 routine described earlier by:
UCS-4文字コードによって前述しucs4_to_utf8ルーチンを使用してUTF-8に変換されます。
1. Because the UCS-4 character is between 0x0800 and 0xFFFF it will map to a 3 byte UTF-8 sequence. 2. The first byte is defined by (0xE0 + (0x00000E0B / 0x1000) = 0xE0.
1. UCS-4文字が0x0800でと0xFFFFの間にあるので、それは3バイトUTF-8シーケンスにマップされます。 2.最初のバイトは、（0xE0となっ+（0x00000E0B / 0x1000番地）= 0xE0となっによって定義されます。
3. The second byte is defined by (0x80 + ((0x00000E0B / 0x40) % 0x40))) = 0xB8. 4. The third byte is defined by (0x80 + (0x00000E0B % 0x40)) = 0x8B.
前記第2のバイトは、（は0x80 +（（0x00000E0B / 0x40の）％の0x40の））で定義される）= 0xB8。 4. 3番目のバイトは、（は0x80 +（0x00000E0Bの％の0x40の））= 0x8Bによって定義されます。
The UTF-8 encoding is transferred back to UCS-4 by using the utf8_to_ucs4 routine described earlier by:
UTF-8エンコーディングをすることによって前述しutf8_to_ucs4ルーチンを使用して、UCS-4に戻されます。
1. Because the first byte of the sequence, when the '&' operator with a value of 0xF0 is applied, will produce 0xE0 (0xE0 & 0xF0 = 0xE0) the UTF-8 is a 3 byte sequence. 2. The four byte UCS-4 character code is produced by (((0xE0 - 0xE0) * 0x1000) + ((0xB8 - 0x80) * 0x40) + (0x8B -0x80) = 0x0000E0B.
シーケンスの最初のバイトは、0xF0がの値に「＆」オペレータが印加されると、0xE0となっ（0xE0となっ＆0xF0が= 0xE0となっ）を生成するため1. UTF-8は、3バイトのシーケンスです。 0xE0となっ）* 0x1000番地）+（（0xB8 - - 2と4バイトUCS-4文字コードは（（（0xE0となっすることにより製造されるが0x80）0x40の*）+（0x8B -0x80）= 0x0000E0B。
Finally, the UCS-4 character code is converted to either the PC or MAC codepage character code (using the mapping table which matches codepage to UCS-4 ) to produce the original 0xAB code for the Thai letter "SO SO".
最後に、UCS-4文字コードは、タイ語文字「SO SO」の元0xABコードを生成する（UCS-4をコードページに一致するマッピングテーブルを使用して）PCまたはMACコードページの文字コードのどちらかに変換されます。
B.3 Pseudo Code for a High-Quality Translating Server
高品質翻訳ServerのB.3擬似コード
if utf8_valid(fn) { attempt to convert fn to the local charset, producing localfn if (conversion fails temporarily) return error if (conversion succeeds) { attempt to open localfn if (open fails temporarily) return error if (open succeeds) return success } } attempt to open fn if (open fails temporarily) return error if (open succeeds) return success return permanent error
もしutf8_validローカル文字セットにFNを変換する（FN）{試み、（変換が一時的に失敗した）場合localfnを生産リターンエラー（オープンは一時的に失敗した）場合localfnオープンする（変換が成功した）{しようとすると、リターンエラー（オープンが成功した）成功を返す場合}}（オープンは一時的に失敗した）場合はfnを開こうとするリターンエラー（オープンが成功した）リターンの成功は、永続的なエラーを返す場合
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。