RFC2640 日本語訳
2640 Internationalization of the File Transfer Protocol. B. Curtin. July 1999. (Format: TXT=57204 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Curtin Request for Comments: 2640 Defense Information Systems Agency Updates: 959 July 1999 Category: Proposed Standard
コメントを求めるワーキンググループB.カーティン要求をネットワークでつないでください: 2640の防衛情報システム庁アップデート: 959 1999年7月のカテゴリ: 提案された標準
Internationalization of the File Transfer Protocol
ファイル転送プロトコルの国際化
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
RFC959[RFC959]とRFC1123セクション4[RFC1123]で定義されるFile Transferプロトコルはインターネットの最も古くて広く使用されたプロトコルの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はインターネットコミュニティ中で見つけられた複数の文字集合と言語をサポートするのを含んでいます)。 これは、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
要約…1 1序論…2 1.1 要件用語…2 2国際化…3 2.1 国際的な人物はセットしました…3 2.2 転送コード化はセットしました…4 3のパス名…5 3.1 一般承諾…5 3.2 サーバコンプライアンス…6 3.3 クライアントコンプライアンス…7 4言語サポート…7
Curtin Proposed Standard [Page 1] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[1ページ]のRFC2640を提案しました。
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
4.1 ラングコマンド…8 ラングコマンドの4.2構文…9 4.3 ラングコマンドのための功績応答…11 4.3 .1 功績の例…11 5 セキュリティ問題…12 6つの承認…12 7用語集…13 8図書目録…13 9作者のアドレス…15はAを付加します--実装問題。16 A.1の一般問題…16 A.2変遷問題…18 Bを付加してください--コードと例を抽出してください…19 B.1の有効なUTF-8はチェックします…19 B.2変換…20 ローカルキャラクターセットからUTF-8までのB.2.1変換…20 UTF-8からローカルキャラクターセットまでのB.2.2変換…23 B.2.3 ISO/IEC8859-8の例…25B.2.4ベンダーCodepageの例…サーバを翻訳するための25B.3中間コード…26 完全な著作権宣言文…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ビットの制限を取り除くことによって、File Transferプロトコルの能力を高めて、RECOMMENDsはUniversal文字コード(UCS)ISO/IEC10646[ISO-10646]の使用です、RECOMMENDs。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].
本書ではされた推薦状はRFC2277[RFC2277]で定義されるように文字集合と言語に関連するIETF方針で言い表される推薦と一致しています。
1.1. Requirements Terminology
1.1. 要件用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[BCP14]で説明されるように本書では解釈されることであるべきですか?
Curtin Proposed Standard [Page 2] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[2ページ]のRFC2640を提案しました。
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.
File Transferプロトコルが開発された、いつ、文字集合から、7ビットのASCIIと8ビットがEBCDICであったなら勝ってくださいか。 今日、これらの文字集合は多国籍のシステムによって必要とされた広範囲のキャラクタをサポートすることができません。現在の使用での7ビットのASCIIより多くのキャラクタを提供する多くの文字集合があれば、それはそれらの可能性の組合を代表する便利な方法を決める意味になります。 グローバルに働いているのは多くの文字集合のサポートを必要とします、そして、それら、またはシングルの使用の間で変換できるのは文字集合を好みました。 後者がこのドキュメントRECOMMENDSをグローバルな相互運用性に保証するために、FTPのためにNVT ASCIIとEBCDIC(すべてのシステムで理解できるもの)に加えてただ一つの文字集合にアプローチして、定義する、この文字集合SHALL、ISO/IECになってください、10646:1993 グローバルな互換性のサポートのために、パス名を交換するとき、クライアントとサーバがUTF-8コード化を使用するのは、STRONGLY RECOMMENDEDです。 しかしながら、クライアントとサーバが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.
文字集合がローカルの決定を店ファイルSHALLの残りまで使用して、ローカルのオペレーティングシステムの能力によるかもしれない、パス名の交換の前、それら、SHOULD、ISO/IEC10646形式とコード化された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は、国際的な人物セットの簡単な説明を与えて、このドキュメントでRECOMMENDEDをコード化しながら、移されます。 RFC2279[RFC2279]でUTF-8の、より徹底的な記述(本書では与えられたそれを超えたISO/IEC10646、およびユニコード[ユニコード])を見つけることができます。
2.1 International Character Set
2.1 国際的な人物はセットしました。
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.
ISOで定義されるようにUniversal文字コードになってくださいFTP SHALLの国際支援のために定義されて。文字集合、10646:1993 修正されるとして。 この規格は多くの既存の国際的で、国家の、そして、法人の規格の文字集合を取り入れます。 ISO/IEC10646は2つの代替のフォームのコード化、UCS-4、およびUCS-2を定義します。 UCS-4は2**31コードが置く含有をコード化する256機の飛行機の128のグループに分割された4バイト(31ビット)です。 各飛行機は256のセルの256の行から成ります。 UCS-2は飛行機ゼロか基本多言語水準(BMP)から成る2バイト(16ビット)の文字集合です。 現在、codesetsは全く2バイトのBMPの外で定義されていません。
Curtin Proposed Standard [Page 3] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[3ページ]のRFC2640を提案しました。
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[ユニコード]はISO/IEC10646のUCS-2部分集合と一致しています。 標準版2.0がレパートリーを含むユニコードは10646のキャラクタです、修正1-7、10646、および編集的、そして、技術的な正誤表はそうです。
2.2 Transfer Encoding
2.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 Transformation Format8(UTF-8)、国際的な人物を伝えるためにコード化される転送がセットしたので、UTF-2かUTF-FSS、SHALLとして参照された過去に、使用されてください。 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バイトのすべての系列のために、最も重要なビットはZEROです。 1バイト以上のすべての系列のために、最も重要なビット位置から始めて、最初のバイトにおける、ONEビットの数は、ZEROビットに従ってUTF-8系列のバイト数が続いたのを示します。 例えば、3バイトのUTF-8系列の最初のバイトには、最上位ビットとして1110があるでしょう。 それぞれ追加しているバイト、(継続するバイト) UTF-8系列では、ONEビットを含んでください、続いて、それらの最上位ビットとしてZEROビットを含みます。 継続するバイトにおける残っている自由なビット位置は、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範囲(十六進法)UTF-8バイト列(2進の)00000000--0000007F0xxxxxxx00000080--000007FF 110xxxxx 10xxxxxx00000800--0000FFFF 1110xxxx 10xxxxxx 10xxxxxx00010000--001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx00200000--03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx04000000--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コード化をサポートする新しいサーバでまだ共同利用できるところにこの特徴は変遷を許容するでしょう。
Curtin Proposed Standard [Page 4] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[4ページ]のRFC2640を提案しました。
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つのパス名
3.1 General compliance
3.1 一般承諾
- 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>.
<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].
<パス名>:、:= <ストリング>。 BNFでは、=1*(%x01%xFF)をパス名にフォーマットしてください。 ABNFでは、[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>コンベンションに従うことを保証しなければなりません。 以下に注意してください。 御馳走3のキャラクタが固定4キャラクタコマンドとして引きずっている<SP>とのコマンドを水増しすることによって命令する(例えば、CWD、MKDなど)実装は不承諾この仕様に中です。
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
<CR>キャラクタがパス名の一部として遭遇するとき、コマンドを送る前の<NUL>キャラクタと共にそれを水増ししなければなりません。 <CR><NUL>系列を含むパス名を受け取り次第、<NUL>キャラクタをはがなければなりません。 11と12ページのTelnetプロトコル[RFC854]でこのアプローチは説明されます。 例えば、パス名foo<CR><LF>boo.barを保存するために、パス名はなるでしょう。
Curtin Proposed Standard [Page 5] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[5ページ]のRFC2640を提案しました。
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.
コマンドSTOR<SP>foo<CR><NUL><LF>boo.bar<CRLF>を送る前のfoo<CR><NUL><LF>boo.bar。 変えられたパス名を受け取り次第、<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.
- 使用可能なコードセットにそれらを変換できないとき、SHOULDが使用するデータの損失、クライアント、およびサーバを避けるために、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.
- サーバかクライアントに提示されたコードセット/コード化が決定できないとき、ケースがあるかもしれません。 中に、そのようなものは生のバイトSHOULDをケースに入れます。使用されます。
3.2 Servers compliance
3.2 サーバコンプライアンス
- 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""を含む系列です。 しかし、このストリングが大文字と小文字を区別していない、SHOULD、大文字で、伝えられてください。 FEATへの応答は、SHOULDが以下の通りであると命令します。
C> feat
S> 211- <any descriptive text>
S> ...
S> UTF8
S> ...
S> 211 end
C>功績S>211<はどんな説明文>S>です…。 S>UTF8 S>… S>211エンド
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].
楕円は他の特徴が含まれるかもしれませんが、NOT REQUIREDであるプレースホルダを示します。 ハイライト線の1つのスペース刻み目が義務的です[RFC2389]。
Curtin Proposed Standard [Page 6] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[6ページ]のRFC2640を提案しました。
- 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.
- ミラーサーバはまさに、それらが反映しているサイトを反映したがっているかもしれません。 そのような場合サーバは、それがメインサーバから受けた正確なパス名バイトを保存して、提示するかもしれません。
3.3 Clients compliance
3.3 クライアントコンプライアンス
- 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.
- クライアント、SHOULDは正しく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がコマンドであるとサポートして、「サーバがUTF-8コード化をサポートするかどうか決定するUTF8"の特徴(上の3.2では、定義される)」を認めなければなりません。
- 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であり、それはSHOULDです。適切にディスプレイを変えてください。 クライアント実装がどう非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.
- このドキュメントの範囲の外にGlyphレンダリングがあります。 クライアントがどう、それが見せることができないキャラクタを紹介するかは、導入問題の品質です。 これはHH形式がRFC1738[RFC1738]で定義したURL%で提示されていた状態で非「ディスプレイ-可能」キャラクタSHOULDに対応する八重奏があるRECOMMENDSを記録します。 しかしながら、彼らは疑問符、それらのUCS16進価値、またはいかなる他の適当なファッションでもそれらを表示するかもしれません。
- 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でないパス名のためにそうし続けるかもしれません。
4. Language Support
4. 言語サポート
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.
文字コードWorkshop Report[RFC2130]は、クライアントとサーバSHOULDが「挨拶」と「エラーメッセージ」のために言語を交渉するのを示します。 この仕様は、どんな説明しているテキスト文字列もサーバ-PIでユーザ-PIコマンドに対応して戻ったことを意味するためにRFC2130による「エラーメッセージ」という用語の使用を解釈します。
Curtin Proposed Standard [Page 7] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[7ページ]のRFC2640を提案しました。
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.
Implementers SHOULDは、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サーバが仮想サーバをサポートしないかもしれませんか、または仮想サーバは、言語への尊敬なしで環境をサポートするために構成されるかもしれません。 言語交渉にこの仕様を許容するのは新しいラングコマンドを定義します。 この仕様に従うクライアントとサーバはラングコマンドをサポートしなければなりません。
4.1 The LANG command
4.1 ラングコマンド
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.
新しいコマンド「ラング」はコマンドがサーバFTPプロセスが、コマンド応答のサーバ挨拶と原文の部分を提示することをどの言語で決定するかを許容するように設定したFTPに追加されます。 言語の1つがタグであったならラングコマンドSHALLに関連づけられたパラメタはRFC1766で[RFC1766]を定義しました。 パラメタのないラングコマンドを発行すると、サーバのデフォルト言語を使用するでしょう。
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.
サーバのデフォルト言語で言語交渉SHALLの前に発行された挨拶と応答はそうです。 パラグラフ4.5の[RFC2277]はそれを述べます。「デフォルト言語はイギリスの話し人を理解できるに違いありません」この。 この仕様RECOMMENDS、サーバデフォルト言語がイギリスのであることが使用ASCIIをコード化しました。 本稿は他の言語からのテキストによって増大させられるかもしれません。 一度交渉されています、サーバ-PI MUSTは交渉された言語であってUTF-8でコード化されるところでコマンド応答のサーバメッセージと原文の部分を返します。 サーバ-PI MAYは新たに交渉された言語の以前に発行されたサーバメッセージを再送したがっています。
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.
ラングコマンドはコマンド応答に関連しているあいさつメッセージと説明しているテキストのプレゼンテーションに影響するだけです。 サーバはプロトコル要素(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 MAYはいつでも、FTPセッションの間、ラングコマンドを発行します。 この完全給付は獲得するために命令して、それはSHOULDです。認証の前に提示されます。 一般に、HOSTが[MLST]を命令した後にそれは発行されるでしょう。 またはそれに注意してください、HOSTの発行。
Curtin Proposed Standard [Page 8] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[8ページ]のRFC2640を提案しました。
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]はラングコマンドの感情を否定するでしょう。 ユーザ-PI SHOULD、交渉された言語のためのUTF-8コード化をサポートすることができてください。 SHALLが適用するセクション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.
この仕様によるNOT REQUIRED、ユーザ-PI SHOULDはFEATを発行しますが、ラングコマンドの前に[RFC2389]を命令してください。 これで、ユーザ-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.
接続がクライアントと共に確立されたかどうか特定することにおけるこの仕様か、より年取ったクライアントに従うサーバを支援するために、いかなる他のコマンド(FEAT[RFC2389]を除いた)も発行する前に、ユーザ-PI MUSTはHOST[MLST]、そして/または、ラングにコマンドを送ります。 ユーザ-PIがHOSTコマンドを発行して、サーバのデフォルト言語が許容できるなら、それはラングコマンドを発行する必要はありません。 しかしながら、実装が、HOSTがコマンドであるとサポートしないなら、ラングコマンドを発行しなければなりません。 サーバ-PIにHOSTを与えるか、またはラングがそれを命令するまで、SHOULDは、ユーザ-PIがこの仕様に従わないと仮定します。
4.2 Syntax of the LANG command
ラングコマンドの4.2構文
The LANG command is defined as follows:
ラングコマンドは以下の通り定義されます:
lang-command = "Lang" [(SP lang-tag)] CRLF lang-tag = Primary-tag *( "-" Sub-tag) Primary-tag = 1*8ALPHA Sub-tag = 1*8ALPHA
lang-コマンドは「ラング」[(SP lang-タグ)]CRLF lang-タグ=プライマリタグ*(「-」サブタグ)プライマリタグ=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-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.
[RFC1766]で定義されるパラメタがプライマリ言語タグとゼロかその他を指定するので与えられたOPTIONAL「ラング-タグ」サブタグ。 [RFC1766]で説明されるように、言語タグは大文字と小文字を区別しないとして扱われます。 省略されるなら、サーバ-PI MUSTはサーバのデフォルト言語を使用します。
Curtin Proposed Standard [Page 9] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[9ページ]のRFC2640を提案しました。
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」か「誤り応答」のどちらかで「ラング」コマンドに応じます。 Server-FTPが「ラング」コマンドをサポートして、「lang-タグ」の何らかのフォームをサポートすることができるなら、「lang-OK」を送らなければなりません。 SHOULDをサポートしてください。以下の通りになってください:
- If server-FTP receives "Lang" with no parameters it SHOULD return
messages and command responses in the server default language.
- サーバFTPがパラメタのない「ラング」のためにそれを受けるなら、SHOULDはサーバデフォルト言語におけるメッセージとコマンド応答を返します。
- 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.
- それがサポートすることができないプライマリタグ主張(例えば、アン、fr、de、ja、zhなど)しかサーバFTPが「ラング」を受けて、それがそのプライマリタグに関連している言語でSHOULDリターンメッセージとコマンド応答であるなら。 サブタグ(例えば、アン米国、アンイギリスなど)に結合されるとそのサーバFTPがプライマリタグを支えるだけであるのは、可能です。 そのような場合、サーバFTPはセッションの間、使用への適切な異形を決定するかもしれません。 この仕様の範囲の外にサーバFTPがどうそれを決断にするかがあります。 サーバFTPが、サブタグ異形がそれを当てることであるかどうか決定できないなら、SHOULDは「サポートされないパラメタ」(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が実装されるプライマリタグとサブタグの(s)議論で「ラング」を受けて、それが言語議論を支持したSHOULDリターンメッセージとコマンド応答であるなら。 そのサーバFTPがサブタグではなく、「ラング」議論のプライマリタグを支えることができるのは、可能です。 そのような場合サーバFTPは実装されたプライマリタグの最も適切な異形でメッセージとコマンド応答を返すかもしれません。 この仕様の範囲の外にサーバFTPがどうそれを決断にするかがあります。 サーバFTPが、サブタグ異形がそれを当てることであるかどうか決定できないなら、SHOULDは「サポートされないパラメタ」(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が「ラングアンAU」コマンドを送って、サーバFTPが、言語タグがアン米国とアンイギリスであると実装したなら、最も適切な言語タグがアンイギリスと「200アン-AUはサポートしなかった」リターンであることが決めるかもしれません。 「言語はアンイギリスにセットしました。」 数値応答は、プロトコル要素であり、変えることができません。 関連ストリングは説明に役立った目的だけのためのものです。
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.
この仕様に従うクライアントとサーバはラングコマンドをサポートしなければなりません。 しかしながら、クライアントSHOULDが、500か502コマンド応答を受けると予期して、場合では、より古いか不従順なサーバがどこでするかは「ラング」であると認めるか、または実装されました。 501応答SHOULD、「ラング」コマンドへの議論がシンタクス上適度でないなら、送ってください。 504応答SHOULDは「ラング」議論であるならシンタクス上正しい間、送られて、実装されません。 上で述べたように、それは正確な構文マッチではありませんが、議論はレキシコンマッチであると考えられるかもしれません。
Curtin Proposed Standard [Page 10] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[10ページ]のRFC2640を提案しました。
4.3 Feat response for LANG command
4.3 ラングコマンドのための功績応答
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:
コマンド、メッセージの言語サポート、およびコマンド応答がFEATコマンド[RFC2389]、ラングコマンドがサポートされるのを示すハイライト線、およびサポートされた言語タグの事実リストへの応答に含まなければならないラングをサポートするサーバFTPプロセス。 FEATコマンドSHALLへの応答は以下の形式において以下の通りです。
Lang-feat = SP "LANG" SP lang-fact CRLF
lang-fact = lang-tag ["*"] *(";" lang-tag ["*"])
ラング-功績=SP「ラング」SPラング-事実CRLF lang-事実=lang-タグ[「*」]*; (「」、lang-タグ[「*」)
lang-tag = Primary-tag *( "-" Sub-tag)
Primary-tag= 1*8ALPHA
Sub-tag = 1*8ALPHA
lang-タグ=プライマリタグ*(「-」サブタグ)プライマリタグ=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-功績応答は「ラング」が言語事実を続けたストリングを含んでいます。 しかし、このストリングが大文字と小文字を区別していない、SHOULD、大文字で、[RFC2389]で推薦されるように、伝えられてください。 FEATコマンドによってラング-功績応答で示された初期のスペースはREQUIREDです。 それはシングルスペースキャラクタであるに違いありません。 多少、間隔文字は受入れられません。 lang-事実SHALLはサーバFTPが支えることができるlangタグを含んでいます。 FEAT応答で少なくとも1個のlang-タグを含まなければなりません。 フォームでlang-タグSHALLはそうです。より早く本書では説明されます。 存在しているとき、OPTIONALアスタリスクであり、SHALLはメッセージと応答にサーバFTPによって使用される現在のlang-タグを示します。
4.3.1 Feat examples
4.3.1 功績の例
C> feat
S> 211- <any descriptive text>
S> ...
S> LANG EN*
S> ...
S> 211 end
C>功績S>211<はどんな説明文>S>です…。 S>ラングアン*S>… S>211エンド
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>功績S>211<はどんな説明文>S>です…。 S>ラングアン*; フランS>… S>211エンド
Curtin Proposed Standard [Page 11] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[11ページ]のRFC2640を提案しました。
C> LANG fr
S> 200 Le response sera changez au francais
C>ラングfr S>200Le応答血清changez Au francais
C> feat
S> 211- <quelconque descriptif texte>
S> ...
S> LANG EN;FR*
S> ...
S> 211 end
C>功績S>211 <quelconque descriptif texte>S>… S>ラングアン; フラン*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.
この例では、サーバFTPはFEATコマンドへの初期の応答で示されるように英語とフランス語の両方をサポートします。 アスタリスクは、英語がサーバFTPで使用中の現在の言語であることを示します。 言語をフランス語に変えるためにラングコマンドを発行した後に、FEAT応答は使用中の現在の言語としてフランス語を示しています。
In the above examples ellipses indicate placeholders where other features may be included, but are NOT REQUIRED.
上記の例では、楕円は他の特徴が含まれるかもしれませんが、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.DuerstマークハリスポールヘスマンアランジョーンズグレゴリーランドバーグジェームスマシューズキースムーアサンドラオドネルベンジャミンリーフェンシュタールスティーブンTihor
(and others from the FTPEXT working group)
(そして、FTPEXTワーキンググループからの他のもの)
Curtin Proposed Standard [Page 12] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[12ページ]のRFC2640を提案しました。
7 Glossary
7用語集
BIDI - abbreviation for Bi-directional, a reference to mixed right- to-left and left-to-right text.
BIDI--正しい複雑な左の、そして、まっすぐになるのを残されたテキストのBi方向のa参照のための略語。
Character Set - a collection of characters used to represent textual information in which each character has a numeric value
文字コード--キャラクタの収集は以前は、よく各キャラクタが数値を持っている文字情報を表していました。
Code Set - (see character set).
コード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 eighteen N」、1番目、「国際化」という言葉の最後の手紙、および間の18個の手紙。
UCS-2 - the ISO/IEC 10646 two octet Universal Character Set form.
UCS-2--ISO/IEC10646 2八重奏Universal文字コードフォーム。
UCS-4 - the ISO/IEC 10646 four octet Universal Character Set form.
UCS-4--ISO/IEC10646 4八重奏Universal文字コードフォーム。
UTF-8 - the UCS Transformation Format represented in 8 bits.
UTF-8--UCS Transformation Formatは8でビットを表しました。
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(直接コード化される)と代理を含む16ビットの形式は飛行機01-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"、1997年11月のRFC2234。
[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]ISO8859。 世界規格--情報処理--8ビットの単一のバイトは図形文字セット--ローマ字No.1第1部:(1987)--第2部をコード化しました: ローマ字No.(1987)2--パート3: ローマ字No.(1988)3--パート4: ローマ字No.(1988)4--パート5: ラテン/キリル文字(1988)--パート6: ラテン/アラビア文字(1987)--部分: ラテン/ギリシャ語アルファベット(1987)--パート8: ラテン語の、または、ヘブライのアルファベット(1988)--パート9: ローマ字No.5 (1989)--Part10、: ローマ字No.6(1992)
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Curtin Proposed Standard [Page 13] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[13ページ]のRFC2640を提案しました。
[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/IEC10646-1:1993。 世界規格--情報技術--普遍的な複数の八重奏コード化文字集合(UCS)--第1部: アーキテクチャと基本多言語面。
[MLST] Elz, R. and P. Hethmon, "Extensions to FTP", Work in
Progress.
[MLST] 「FTPへの拡大」というElz、R.、およびP.ヘスマンは進行中で働いています。
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC854] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol
(FTP)", STD 9, RFC 959, October 1985.
[RFC959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、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.スバンベルク、「文字コードワークショップレポート」、RFC2130、1997年4月。
[RFC2277] Alvestrand, H., " IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[RFC2389] Elz, R. and P. Hethmon, "Feature Negotiation Mechanism
for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2389] ElzとR.とP.ヘスマン、「ファイル転送プロトコルのための特徴交渉メカニズム」、RFC2389、1998年8月。
[UNICODE] The Unicode Consortium, "The Unicode Standard - Version
2.0", Addison Westley Developers Press, July 1996.
[ユニコード] ユニコード共同体、「バージョン2インチ、アディソンWestley開発者プレス、1996年ユニコード規格--7月。」
[UTF-8] ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS
Transformation Format 8 (UTF-8).
[UTF-8]ISO/IEC10646-1: 1993年の修正2(1996)。 UCS変換形式8(UTF-8)。
Curtin Proposed Standard [Page 14] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[14ページ]のRFC2640を提案しました。
9 Author's Address
9作者のアドレス
Bill Curtin JIEO Attn: JEBBD Ft. Monmouth, N.J. 07703-5613
ビルカーティンJIEO Attn: JEBBDフィート モンマス、ニュージャージー州07703-5613
EMail: curtinw@ftm.disa.mil
メール: curtinw@ftm.disa.mil
Curtin Proposed Standard [Page 15] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[15ページ]のRFC2640を提案しました。
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.
- Implementersは非UTF-8であるパス名が有効なUTF-8として分析されるかもしれないという見込みがあるのを意識しているべきです。 統計的にコード化するのが他のもののためのゼロに合わせるゼロいくつかに、確率は低いです。 最近の非科学的な分析によって、EUCが単語には読みながら虚偽に2.7%いた日本人をコード化したのがわかりました。 SJISには、0.0005%の誤った読みがありました。 ASCIIかKOI-8には読みながら虚偽に0%ある他のコード化。 この確率は、短いパス名に最も高く、パス名サイズが増加するのに従って、減少します。 Implementersは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)を含むのが、可能であることを意識しているべきです。 それらはこれらの文字集合(すなわち、ディレクトリのための左のディスプレイとファイル名のための正しいディスプレイへの左に正しい)のBi方向の(BIDI)ディスプレイを扱うように準備されるべきです。 双方向のディスプレイがこのドキュメントの範囲の外にあって、上記の例より複雑である間、ユニコード2.0[ユニコード]規格で双方向のディスプレイのためのアルゴリズムを見つけることができます。 また、パス名が、異なったバイト順が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ラベリング、異なったパス名には異なったcharsetsがあるかもしれないようなものをそうすることができます。 そしてときにそうすることができないなら、サーバは、すべてのパス名を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
- 何らかのサーバのOSは文字集合を強制しませんが、管理者にFTPサーバでそれを構成させてください。これらのサーバが特定のマッピングテーブルを使用するために構成されるべきである、(どちらか
Curtin Proposed Standard [Page 16] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[16ページ]のRFC2640を提案しました。
external or built-in). This will allow the flexibility of defining
different charsets for different directories.
外部か内蔵、) これは異なったディレクトリのために異なったcharsetsを定義する柔軟性を許容するでしょう。
- 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.
- サーバが鏡であり、まさしくそれが反映しているサイトに似たいなら、それはメインサーバから受けた正確なファイル名バイトを保存するべきです。
Curtin Proposed Standard [Page 17] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[17ページ]のRFC2640を提案しました。
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.
- パス名が年取ったクライアント(この仕様をサポートしないもの)から提示されるときこの仕様をサポートするサーバは、パス名が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に保存されるかもしれないのを考慮に入れるべきです。 しかしながら、この仕様の範囲の外にクライアントがどう非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とMACs)の上では、前のアプローチは、より簡単です。 より無料のフォームファイルシステム(例えば、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つの異なったパス名があるかのようにサーバが行動することであるかもしれません。 制御ファイルシステムの上のサーバか自由形式システムの上でシンボリックリンクを使用することによって、内部でこれをするかもしれません。このアプローチは非対話的な使用、ディレクトリにおける、ファイルのすべての非対話的な転送がそうする一列で転送に効き目があるかもしれない間、写しを製作してください。 実数ファイルの二重であるファイルのリストを対話的なユーザに与えるかもしれません。
Curtin Proposed Standard [Page 18] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[18ページ]のRFC2640を提案しました。
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形式に従うのを確実にするために1番目の、そして、次のバイトの適切なタグ付けがないかどうかチェックすることによって、これをします。 そして、保証するために、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
int utf8_有効(constの未署名の炭*buf、未署名のint len)である、const未署名の炭*endbuf=buf+len; c; 未署名の炭のbyte2mask=0x00、引きずっている=0をintします; 続く//引きずる(継続)バイト
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?
等しい..引きずる..0×80..引きずる..バイト..続く..形式..チェック..バイト..適切..範囲..適切..ビット..設定..等しい..0×00..ほか..リターン..引きずる..ほか..リターン..ほかに..0×80..0×00..続ける; 有効..バイト..ほか..有効..バイト..バイト..適切..範囲..引きずる..等しい..ほか..リターン..ほか..有効..バイト..バイト..適切..範囲..0×20..セット..マスク..チェック..次..バイト..引きずる..ほかに..有効..バイト..0×07..バイト..適切..範囲
Curtin Proposed Standard [Page 19] RFC 2640 FTP Internalization July 1999
カーティンはFTP内面化1999年7月に標準[19ページ]のRFC2640を提案しました。
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;
}
byte2mask=0x30。 =3を引きずる次のバイトをチェックする//かセットマスク//;、5バイトのほかの、しかし、((cと0xFC)=0xF8)//有効なUTF-8、((cと0×03))//は//適切な範囲のUTF-8バイトです--byte2mask=0x38 =4を引きずる次のバイトをチェックする//かセットマスク//;、6バイトのほかの、しかし、((cと0xFE)=0xFC)//有効なUTF-8、((cと0×01))//は//適切な範囲のUTF-8バイトです--byte2mask=0x3C =5を引きずる次のバイトをチェックする//かセットマスク//;、ほかのリターン0。 引きずっている=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.
このセクションのコードの例は、密接にISO10646にアルゴリズムを反映して、UTF-8コード化からの/に変えるために最も効率的なソリューションを提示しないかもしれません。 効率が問題であるなら、implementersは適切なビット単位の演算子を使用するはずです。
Additional code examples and numerous mapping tables can be found at the Unicode site, HTTP://www.unicode.org or FTP://unicode.org.
ユニコードサイト、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が(著しくPlan9と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までの変換はツーステッププロセスにかかわるでしょう。 まず最初に、ローカルキャラクターセットを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/IEC8859-8[ISO-8859]コードは0xE4です。 4バイトの対応するISO/IEC10646コードは0x000005D5です。
Curtin Proposed Standard [Page 20] RFC 2640 FTP Internalization July 1999
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:
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));
Curtin Proposed Standard [Page 21] RFC 2640 FTP Internalization July 1999
*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);
}
Curtin Proposed Standard [Page 22] RFC 2640 FTP Internalization July 1999
B.2.2 Conversion from UTF-8 to Local Character Set
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).
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:
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)
{
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));
Curtin Proposed Standard [Page 23] RFC 2640 FTP Internalization July 1999
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);
}
Curtin Proposed Standard [Page 24] RFC 2640 FTP Internalization July 1999
B.2.3 ISO/IEC 8859-8 Example
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.
The UCS-4 character code is transformed into UTF-8 using the ucs4_to_utf8 routine described earlier by:
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.
3. The second byte is defined by (0x80 + (0x000005D5 % 0x40)) = 0x95.
The UTF-8 encoding is transferred back to UCS-4 by using the utf8_to_ucs4 routine described earlier by:
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.
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".
B.2.4 Vendor Codepage Example
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.
The UCS-4 character code is transformed into UTF-8 using the ucs4_to_utf8 routine described earlier by:
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.
Curtin Proposed Standard [Page 25] RFC 2640 FTP Internalization July 1999
3. The second byte is defined by (0x80 + ((0x00000E0B / 0x40) %
0x40))) = 0xB8.
4. The third byte is defined by (0x80 + (0x00000E0B % 0x40)) = 0x8B.
The UTF-8 encoding is transferred back to UCS-4 by using the utf8_to_ucs4 routine described earlier by:
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.
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".
B.3 Pseudo Code for a High-Quality Translating Server
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
Curtin Proposed Standard [Page 26] RFC 2640 FTP Internalization July 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
Curtin Proposed Standard [Page 27]
一覧
スポンサーリンク
