[要約] RFC 2640は、FTPの国際化に関する標準化文書であり、FTPプロトコルの国際化のためのガイドラインを提供しています。目的は、FTPの国際化に関する問題を解決し、異なる言語や文字セットをサポートするための一貫性のある方法を提供することです。
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.
Copyright（c）The Internet Society（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]で定義されているファイル転送プロトコルは、インターネット上で最も古く広く使用されているプロトコルの1つです。プロトコルの主要なキャラクターセットである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] / LATIN-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]の使用を推奨します。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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14 [BCP14]で説明されているように解釈される。
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に加えて、すべてのシステムで理解できる単一の文字セットを定義します。FTPの場合、この文字セットはISO/IEC 10646：1993でなければなりません。グローバルな互換性をサポートするには、クライアントとサーバーがパス名を交換するときにUTF-8エンコードを使用することを強くお勧めします。ただし、クライアントとサーバーは、STORやRETなどの操作のファイルのコンテンツで変換を実行する義務がありません。
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エンコードに変換する必要があります。このアプローチは、PathNamesの国際交換を可能にしますが、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.
FTPの国際的なサポートのために定義されたキャラクターセットは、修正されたISO 10646：1993で定義されている普遍的なキャラクターセットとするものとします。この基準には、多くの既存の国際、国内、企業の基準のキャラクターセットが組み込まれています。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.
Unicode Standardバージョン2.0 [Unicode]は、ISO/IEC 10646のUCS-2サブセットと一致しています。UnicodeStandardバージョン2.0には、IS 10646文字、IS 10646の修正1-7、および編集および技術的なコリゲンダのレパートリーが含まれます。
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の利点のいくつかは、7ビットASCIIと互換性があることであるため、さまざまな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シーケンスの追加バイト（継続バイト）には、最も重要なビットとしてゼロビットが続く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 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 10xxxxxx10xxxxxx 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-Onlyクライアントが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エンコードされた文字シーケンスと間違えられる可能性は非常に低いことです。クライアントとサーバーは、簡単なルーチンを使用して、交換される文字セットが有効かどうかを判断できます。セクションB.1は、このチェックのコード例を示しています。
3 Pathnames
3 PathNames
- 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>文字の使用が許可されています。これらの特別なコマンド文字とのパス名の交換により、パス名は不適切に解析されます。これは、PathNamesに関連付けられたFTPコマンドにフォームがあるためです。
COMMAND <SP> <pathname> <CRLF>.
コマンド<sp> <PathName> <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:
PathNames内のこれらの文字を特別なコマンド文字として間違えないようにするために、次のルールが適用されます。
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コマンドとPathNameの間には<sp>が1つだけある必要があります。実装は、パス名の一部として初期<sp>に続く<sp>文字を想定する必要があります。たとえば、Stor <sp> <sp> <sp> foo.bar <crlf>のパス名は<sp> <s spoo.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.
コマンドとPathNameの間のセパレーターとして複数の<sp>文字を許可する可能性がある現在の実装は、この単一の<sp>コンベンションに準拠することを保証する必要があります。注：3文字コマンド（CWD、MKDなど）を扱う実装は、Trailing <sp>でコマンドをパディングして、固定4文字コマンドとしてこの仕様に違反しています。
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>の文字を取り除く必要があります。このアプローチは、Telnetプロトコル[RFC854]で11ページと12ページに記載されています。たとえば、パスネームfoo <cr> <lf> boo.barを保存するには、パス名はfoo <cr> <cr> <nul> <lf> booになります。コマンドを送信する前にbar <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.
- 適合クライアントとサーバーは、PathNamesの転送と受領のために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機能をサポートする必要があります。UTF-8機能は、正確な文字列「UTF8」を含む行です。この文字列はケースに敏感ではありませんが、大文字で送信する必要があります。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で定義）を認識して、サーバーがUTF-8エンコーディングをサポートするかどうかを判断する必要があります。
- 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を処理する方法は、実装の品質の問題です。他のエンコードを想定したり、ユーザーに何かを想定したりする機会を与えたり、サーバーのエンコード仮定をある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六量体値、または他の適切な方法で表示する場合があります。
- 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]は、クライアントとサーバーが「グリーティング」と「エラーメッセージ」の言語をネゴシエートする必要があることを示唆しています。この仕様は、RFC 2130による「エラーメッセージ」という用語の使用を、ユーザー-PIコマンドに応じてサーバー-PIによって返される説明テキスト文字列を意味することを解釈します。
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でエンコードする必要があります。Server-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 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.
user-piは、FTPセッション中にいつでもLangコマンドを発行できます。このコマンドの完全な利益を得るには、認証の前に提示する必要があります。一般に、ホストコマンド[MLST]の後に発行されます。ホストまたは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]を発行する必要があります。これにより、ユーザー-PIは、サーバーがLangコマンドをサポートしているかどうか、およびどの言語オプションをサポートしているかを判断できます。
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がホストコマンドを発行し、サーバーのデフォルト言語が許容できる場合、LANGコマンドを発行する必要はありません。ただし、実装がホストコマンドをサポートしていない場合、Langコマンドを発行する必要があります。Server-PIがホストまたは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
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
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」コマンドワードはケース独立であり、任意のキャラクターケースで指定される場合があります。したがって、「ラング」、「ラング」、「ラング」、および「ラング」は同等のコマンドです。
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.
パラメーターとして指定されたオプションの「Lang-Tag」は、[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:
server-ftpは、「lang-ok」または「エラー応答」のいずれかで「lang」コマンドに応答します。「Lang」コマンドをサポートし、何らかの形の「Lang-Tag」をサポートできる場合、「Lang-OK」を送信する必要があります。サポートは次のとおりです。
- If server-FTP receives "Lang" with no parameters it SHOULD return messages and command responses in the server default language.
- Server-FTPがパラメーターなしで「Lang」を受信した場合、Serverのデフォルト言語でメッセージとコマンド応答を返す必要があります。
- 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.
- Server-FTPがプライマリタグ引数のみで「Lang」を受信した場合（例：EN、FR、DE、JA、ZHなど）、サポートできます。。Server-FTPは、サブタグ（EN-US、EN-UKなど）と組み合わせると、プライマリタグのみをサポートする可能性があります。そのような場合、Server-FTPは、セッション中に使用する適切なバリアントを決定する場合があります。Server-FTPがその決定をこの仕様の範囲外にする方法。Server-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.
- Server-FTPが実装されているプライマリタグとサブタグ引数で「Lang」を受信する場合、言語引数をサポートするためにメッセージとコマンドの応答を返す必要があります。Server-FTPは、サブタグではなく「ラング」引数の主要なタグをサポートできる可能性があります。このような場合、Server-FTPは、実装されているプライマリタグの最も適切なバリアントでメッセージとコマンド応答を返す場合があります。Server-FTPがその決定をこの仕様の範囲外にする方法。Server-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.
たとえば、client-ftpが「lang en-au」コマンドを送信し、server-ftpが言語タグを実装した場合、最も適切な言語タグはen-ukであると決定する場合があり、200 en-auを返しますサポートされていません。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コマンドをサポートする必要があります。ただし、クライアントは、古いサーバーまたは非準拠サーバーが「LANG」を認識していない、または実装していない場合に、500または502のコマンド応答を受信することを予測する必要があります。「Lang」コマンドへの引数が構文的に正しい場合は、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:
LANGコマンドをサポートするサーバー-FTPプロセス、およびメッセージとコマンドレスポンスの言語サポートは、featコマンド[RFC2389]への応答に含める必要があります。言語タグ。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
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-Feat Responseには、文字列「Lang」に続いて言語の事実が含まれています。この文字列は、ケースに敏感ではありませんが、[RFC2389]で推奨されるように、上品で送信する必要があります。Lang-Feat応答に示されている初期スペースは、featコマンドで必要です。単一のスペース文字でなければなりません。多かれ少なかれスペース文字は許可されていません。Lang-factには、Server-FTPがサポートできるLang-Tagsが含まれます。Feat Responseには、少なくとも1つのLang-Tagを含める必要があります。Lang-Tagは、このドキュメントで前述の形式であるものとします。オプションのアスタリスクは、存在する場合、メッセージと応答のためにServer-FTPで使用されている現在のラングタグを示します。
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.
この例では、Server-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> feat
S> 211- <quelconque descriptif texte>
S> ...
S> LANG EN;FR*
S> ...
S> 211 end
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コマンドへの最初の応答で示されているように、Server-FTPは英語とフランス語の両方をサポートしています。アスタリスクは、英語がServer-FTPで使用されている現在の言語であることを示しています。言語をフランス語に変更するためにLangコマンドが発行された後、偉業の対応はフランス語が現在の言語として使用されていることを示しています。
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バイトを超えた文字セットのサポートと新しい言語交渉コマンドに対応しています。このドキュメントへの適合は、セキュリティリスクを誘発してはなりません。
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.デューストマークハリスポールヘスモンアルンジョーンズグレゴリーランドバーグジェームズマシューズキースムーアサンドラオドネルベンジャミンリーフェンシュタールスティーブンティホール
(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.
GLYPH-ディスプレイデバイスで表されるキャラクター画像。
I18N - "I eighteen N", the first and last letters of the word "internationalization" and the eighteen letters in between.
i18n- "i e8een 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-平面01-16の文字を表すためのBMP（直接エンコード）およびサロゲートペアを含む16ビット形式。Unicodeに相当します。
8 Bibliography
8書誌
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、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)
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Elz、R。、およびP. Hethmon、「FTPへの拡張」、進行中の作業。
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC854] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[RFC959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル（FTP）」、STD 9、RFC 959、1985年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、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] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（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] Weider、C.、Preston、C.、Simonsen、K.、Alvestrand、H.、Atkinson、R.、Crispin、M。、およびP. Svanberg、「Character Set Workshop Report」、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] Elz、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 Consortium、「Unicode Standard -Version 2.0」、Addison Westley Developers Press、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
ビル・カーティン・ジエオ・アトン：jebbd ft。モンマス、ニュージャージー07703-5613
EMail: curtinw@ftm.disa.mil
Annex A - Implementation Considerations
付録A-実装の考慮事項
- 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.
- 実装者は、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.
- クライアント開発者は、PathNamesが混合文字を含めることが可能であることに注意する必要があります（// latin1directoryName/hebrewfileNameなど）。これらのキャラクターセットの双方向（BIDI）ディスプレイ（つまり、ディレクトリの右から左のディスプレイ、ファイル名の左から右へのディスプレイ）を処理する準備をする必要があります。双方向ディスプレイはこのドキュメントの範囲外であり、上記の例よりも複雑ですが、双方向ディスプレイのアルゴリズムはUnicode 2.0 [Unicode]標準にあります。また、パス名は異なるバイト順序を持つことができますが、組成中の異なるポイントでのバイディコントロールキャラクターの挿入により、論理的にはディスプレイワイバルであることに注意してください。また、混合された文字セットは、フォントスワッピングの問題も提示する可能性があることに注意してください。
- 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.
- ローカルファイルシステムから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.
- サーバーがミラーであり、ミラーリングしているサイトのように見える場合は、メインサーバーから受信した正確なファイル名バイトを保存する必要があります。
- 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.
- この仕様をサポートするサーバーは、古いクライアント（この仕様をサポートしていないもの）からパス名を提示したときに、パス名が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コマンドとUTF8機能（3.2で定義）をサポートする機能によってUTF-8をサポートできるかどうか（つまり、この仕様をサポートする）ことができるかどうかを判断できます。新しいクライアントがサーバーがUTF-8をサポートしていないと判断した場合、異なるコードセットをデフォルトすることを望む場合があります。クライアント開発者は、古いサーバーに関連付けられているパス名がUTF-8に保存される可能性があることを考慮する必要があります。ただし、クライアントがNon 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.
- 古いRAW PATHNAME（リンクされたURLなど）の下にファイルを参照する多くのアプリケーションがある場合があります。PathNameをUTF-8に変更すると、古いURLへのアクセスが失敗します。ソリューションは、ファイルに関連付けられた2つの異なるパス名があるかのようにサーバーが動作する場合があります。これは、制御されたファイルシステム上のサーバーの内部またはフリーフォームシステムでシンボリックリンクを使用して行われる場合があります。このアプローチは、単一ファイル転送ではない非対話的使用に対して機能する可能性がありますが、ディレクトリ内のすべてのファイルの非インタラクティブ転送は重複を生成します。インタラクティブなユーザーには、実際の番号ファイルが2倍のファイルのリストが表示される場合があります。
Annex B - Sample Code and Examples
付録B-サンプルコードと例
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;
}
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への変換は必要ありません。
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に変換します。次に、UCSをUTF-8に変換します。
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:
次のステップは、UCS文字コードをUTF-8エンコーディングに変換することです。次のルーチンを使用して、UCS-4文字コードに基づいて正しい数のバイト数を決定およびエンコードできます。
unsigned int ucs4_to_utf8 (unsigned long *ucs4_buf, unsigned int ucs4_len, unsigned char *utf8_buf)
unsigned int ucs4_to_utf8（unsigned 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
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);
}
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からUTF-8に変換するには、UTF-8シーケンスでフリービット（UTF-8シーケンスサイズを定義しない、または継続バイトを意味しないもの）は、ビットストリングとして連結されます。次に、ビットは、最も有意なビットから始まる4バイトシーケンスに分布します。4バイトシーケンスで少し割り当てられていないこれらのビットには、ビットがゼロでパッドが付けられています。次のルーチンは、UTF-8エンコードをUCS-4文字コードに変換します。
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 intf8_len、unsigned char *utf8_buf）{
const unsigned char *utf8_endbuf = utf8_buf + utf8_len;
unsigned int ucs_len=0;
while (utf8_buf != utf8_endbuf) {
while（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);
}
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」は、ISO/IEC 8859-8文字コード0XE4から、コンバージョン/マッピングファイルの単純な検索により、0x000005D5の対応する4バイトISO/IEC 10646コードに変換されます。
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で定義されます。
3. The second byte is defined by (0x80 + (0x000005D5 % 0x40)) = 0x95.
3. 2番目のバイトは（0x80（0x000005d5％0x40））= 0x95で定義されます。
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.
1. シーケンスの最初のバイトは、0xe0の値を持つ '＆'演算子が適用されると、0xc0（0xd7＆0xe0 = 0xc0）が生成されるため、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文字コードはISO/IEC 8859-8文字コード（ISO/IEC 8859-8とUCS-4に一致するマッピングテーブルを使用）に変換され、ヘブライ語文字「Vav」の元の0xe4コードを生成する。
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です。この文字は、変換/マッピングファイルを使用してUCS-4にマッピングして、0x0E0Bの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.
3. 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.
1. シーケンスの最初のバイトは、0xF0の値を持つ '＆'演算子が適用されると、0xe0（0xe0＆0xf0 = 0xe0）が生成されるため、UTF-8は3バイトシーケンスです。2. 4バイトUCS -4文字コードは、（（0xe0-0xe0） * 0x1000）（（0xb8 -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文字コードは、PCまたはMac CodePage文字コード（CodePageに匹敵するマッピングテーブルを使用してUCS-4を使用して）に変換され、タイ文字「So So」の元の0xABコードを作成します。
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。