RFC2130 日本語訳
2130 The Report of the IAB Character Set Workshop held 29 February - 1March, 1996. C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R.Atkinson, M. Crispin, P. Svanberg. April 1997. (Format: TXT=63443 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Weider
Request for Comments: 2130 Microsoft
Category: Informational C. Preston
Preston & Lynch
K. Simonsen
DKUUG
H. Alvestrand
UNINETT
R. Atkinson
Cisco Systems
M. Crispin
University of Washington
P. Svanberg
KTH
April 1997
コメントを求めるワーキンググループC.ワイダーの要求をネットワークでつないでください: 2130年のマイクロソフトカテゴリ: 情報のC.プレストンプレストンとリンチK.シモンセンDKUUG H.Alvestrand UNINETT R.アトキンソンシスコシステムズM.クリスピンワシントン大学P.スバンベルクKTH1997年4月
The Report of the IAB Character Set Workshop
held 29 February - 1 March, 1996
2月29日--1996年3月1日に持たれていたIAB文字コードWorkshopのReport
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Acknowledgments
承認
The authors would like to sincerely thank Information Sciences Institute (ISI), and in particular Joyce K. Reynolds for graciously hosting this event; Joe Kemp and Jeanine Yamazaki of ISI made sure the facilities met our needs. We also wish to thank the Internet Society, which underwrote travel for participants who might not otherwise have been able to attend. Of course, we also wish to thank the many experts who participated in the workshop and on the mailing list; a complete list of these people can be found in Appendix D. Bunyip Information Systems was kind enough to provide mailing list facilities for this work.
作者は丁重にこのそのイベントを主催して頂いて、心から情報Sciences Institute(ISI)、および特にジョイス・K.レイノルズに感謝したがっています。 ISIのジョー・ケンプとジャニーンヤマザキは、施設が私たちの需要を満たしたのを確実にしました。 また、インターネット協会に感謝申し上げます。(それは、そうでなければ出席できなかったかもしれない関係者のために旅行を署名しました)。 もちろん、また、ワークショップとメーリングリストに参加した多くの専門家に感謝申し上げます。 Appendix D.でこれらの人々の全リストを見つけることができます。Bunyip情報Systemsはメーリングリスト施設をこの仕事に提供するほど親切でした。
Table of Contents
目次
Abstract 0: Executive summary.......................................... 2 1: Introduction............................................... 3 2: Character sets on the Internet -- the problem.............. 3 2.1: Character set handling in existing protocols............... 4 3: Architectural model........................................ 6 3.1: Segments defined........................................... 7 3.2: On the wire................................................ 8
要約0: 要約… 2 1: 序論… 3 2: インターネットの文字集合--問題… 3 2.1: 既存のプロトコルにおける文字集合取り扱い… 4 3: 建築モデル… 6 3.1: 定義されたセグメント… 7 3.2: ワイヤに関して… 8
Weider, et. al. Informational [Page 1] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [1ページ]情報のRFC2130文字コードワークショップレポート1997年4月
3.3: Determining which values of CCS, CES, and TES are used..... 9 3.4: Recommended Defaults....................................... 10 3.5: Guidelines for conversions between coded character sets.... 13 4: Presentation issues........................................ 14 5: Open issues................................................ 14 5.1: Language tags.............................................. 15 5.2: Public identifiers......................................... 16 5.3: Bi-directionality.......................................... 16 6: Security Considerations.................................... 16 7: Conclusions................................................ 16 8: Recommendations............................................ 17 8.1: To the IAB................................................. 17 8.2: For new Internet protocols................................. 18 8.3: For registration of new character sets..................... 18 Appendix A: List of protocols affected by character set issues... 20 Appendix B: Acronyms............................................. 23 Appendix C: Glossary............................................. 24 Appendix D: References........................................... 25 Appendix E: Recommended reading.................................. 27 Appendix F: Workshop attendee list............................... 29 Appendix G: Authors' Addresses................................... 30
3.3: CCSのどの値を決定するか、そして、CES、およびTESは使用されています… 9 3.4: お勧めのデフォルト… 10 3.5: コード化文字集合の間の変換のためのガイドライン… 13 4: プレゼンテーション問題… 14 5: 問題を開いてください… 14 5.1: 言語タグ… 15 5.2: 公共の識別子… 16 5.3: 2方向性… 16 6: セキュリティ問題… 16 7: 結論… 16 8: 推薦… 17 8.1: IABに… 17 8.2: 新しいインターネットプロトコルのために… 18 8.3: 新しい文字集合の登録のために… 18 付録A: 文字集合問題で影響を受けるプロトコルのリスト… 20 付録B: 頭文字語… 23 付録C: 用語集… 24 付録D: 参照… 25 付録E: 読むことを勧めます… 27 付録F: ワークショップ出席者リスト… 29 付録G: 作者のアドレス… 30
Abstract
要約
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols.
このレポートは2月29日--1996年3月1日にインターネットにおける文字集合の使用について議論するために開かれたIABによって後援された招待者に限る催しワークショップの結論を詳しく述べます。 それは、テキストを伝えるインターネットプロトコルで文字集合取り扱いを持つ必要性を動機づけて、文字集合を指定するのに概念の構成を提供して、MIMEタグ付けの伝えられたテキストの使用を推薦して、他の文字集合の必要は全くないと述べながら*なしでデフォルト文字集合*を推薦して、文字集合フレームワークの統合をテキスト伝送プロトコルに促進するために一連の推薦状をIAB、IANA、およびIESGにします。
0: Executive summary
0: 要約
The term 'Character Set' means many things to many people. Even the MIME registry of character sets registers items that have great differences in semantics and applicability. This workshop provides guidance to the IAB and IETF about the use of character sets on the Internet and provides a common framework for interoperability between the many characters in use there.
'文字コード'という用語は多くの人々に多くのものを意味します。 文字集合のMIME登録さえ意味論と適用性の大差を持っている項目を登録します。 このワークショップは、インターネットで文字集合の使用に関してIABとIETFに指導を供給して、そこで使用中の多くのキャラクタの間で一般的なフレームワークを相互運用性に提供します。
The framework consists of four components: an architecture model, which specifies components necessary for on-the-wire transmission of text; recommendations for tagging transmitted (and stored) text; recommended defaults for each level of the model; and a set of
フレームワークは4つのコンポーネントから成ります: アーキテクチャモデル(モデルはワイヤにおけるテキストの送信に必要なコンポーネントを指定します)。 タグ付けのための推薦はテキストを伝えました(そして、保存されます)。 モデルの各レベルのためのお勧めのデフォルト。 そして、セットされたa
Weider, et. al. Informational [Page 2] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [2ページ]情報のRFC2130文字コードワークショップレポート1997年4月
recommendations to the IAB, IANA, and the IESG for furthering the integration of this framework into text transmission protocols.
このフレームワークの統合をテキスト伝送プロトコルに促進するためのIAB、IANA、およびIESGへの推薦。
The architectural model specifies 7 layers, of which only three are required for on-the-wire transmission. The Coded Character Set is a mapping from a set of abstract characters to a set of integers. The Character Encoding Scheme is a mapping from a Coded Character Set (or several) to a set of octets. The Transfer Encoding Syntax is a transformation applied to data which has been encoded using a Character Encoding Scheme to allow it to be transmitted. These layers should be specified in a transmitted text stream by using the MIME encoding mechanisms.
建築モデルは7つの層を指定します。(そこでは、3だけがワイヤにおけるトランスミッションに必要です)。 Coded文字コードは1セットの抽象的なキャラクタから1セットの整数までマッピングです。 Coded文字コード(または、数個)から1セットの八重奏までキャラクターEncoding Schemeはマッピングです。 Transfer Encoding Syntaxはそれが伝えられるのを許容するのにキャラクターEncoding Schemeを使用することでコード化されたデータに適用された変換です。 これらの層は、伝えられたテキストストリームでメカニズムをコード化するMIMEを使用することによって、指定されるべきです。
This report recommends the use of ISO 10646 as the default Coded Character Set, and UTF-8 as the default Character Encoding Scheme in the creation of new protocols or new version of old protocols which transmit text. These defaults do not deprecate the use of other character sets when and where they are needed; they are simply intended to provide guidance and a specification for interoperability.
このレポートは新しいプロトコルかテキストを伝える古いプロトコルの新しいバージョンの作成でデフォルトCoded文字コードとしてのISO10646、およびデフォルトキャラクターEncoding SchemeとしてのUTF-8の使用を推薦します。 これらのデフォルトはそれらがある時間と場所で必要である他の文字集合の使用を非難しません。 単に、彼らが相互運用性のための指導と仕様を提供することを意図します。
1: Introduction
1: 序論
This is the report of an IAB-sponsored invitational workshop on the use of Character Sets on the Internet, held 29 February - 1 March 1996 at Information Sciences Institute (ISI) in Marina del Rey, California. In addition, this report covers the discussion on the mailing list up to and slightly beyond the workshop itself. The goals of this workshop were to provide guidance to the IAB and the IETF about the use of character sets on the Internet, and if possible a common framework for interoperability between the many character sets in use there. Both goals were achieved.
これはインターネットにおける文字コードの使用に関するIABによって後援された招待者に限る催しワークショップ、マリナデルレイ、カリフォルニアの情報Sciences Institute(ISI)の保持された1996年2月29日から3月1日のレポートです。 さらに、このレポートはわずかにワークショップとワークショップ自体を超えたメーリングリストについての議論をカバーしています。 このワークショップの目標はそこで使用中の多くの文字集合の間でインターネットにおける文字集合の使用、および相互運用性のためのできれば一般的なフレームワークに関してIABとIETFに指導を供給することでした。 両方の目標は達成されました。
2: Character sets on the Internet - the problem
2: インターネットの文字集合--問題
The term 'character set' is typically applied to the contents of a wide variety of text transmission and display protocols used on the Internet. Because the term is used to mean different things, confusion has arisen. For example, the MIME registry of character sets [MIME] contains items that may differ greatly in their applicability and semantics in various Internet protocols.
'文字集合'という用語はプロトコルがインターネットで使用したさまざまなテキスト伝送とディスプレイのコンテンツに通常適用されます。 用語が別物を意味するのに使用されるので、混乱は起こりました。 例えば、文字集合[MIME]のMIME登録は様々なインターネットプロトコルのそれらの適用性と意味論において大きな開きがあるかもしれない項目を含んでいます。
In addition, there is a vast profusion of different text encoding schemes in use on the Internet. This per se is not a problem; each scheme has evolved to meet real needs. However, information applications such as mail, directories, and the World Wide Web have each developed different techniques for dealing with the growing number of schemes. A robust information architecture for the
さらに、異なったテキストコード化体系のかなりのインターネットで使用中の大量があります。 これほどそういうもの、問題ではありません。 各体系は、真の必要性を満たすために発展しました。 しかしながら、メールや、ディレクトリや、WWWなどの情報アプリケーションはそれぞれ体系の増加している数に対処するための異なった技術を見いだしました。 強健なインフォメーション・アーキテクチャ
Weider, et. al. Informational [Page 3] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [3ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Internet requires as much interoperability between these techniques as possible.
インターネットは可能であるとしてのこれらのテクニックの間の同じくらい多くの相互運用性を必要とします。
2.1: Related topics deemed out of scope for this workshop
2.1: このワークショップのための範囲から考えられた関連した話題
Successful display of plain text transmitted over the Internet requires a lot of information about the text itself, such as the underlying character set, language, and so forth. An additional set of formatting information is needed if the receiving application wishes to use local (cultural) conventions when it presents the data to the user. This formatting includes information, that provides the data necessary to format certain types of textual data (dates, times, numbers and monetary notation) into a form which is familiar to the user. The POSIX [POSIX] notation of locale encompasses language, coded character set and cultural conventions.
インターネットの上に送られたプレーンテキストのうまくいっているディスプレイはテキスト自体の多くの情報を必要とします、基本的な文字集合、言語などなどのように。 ユーザにデータを提示すると受信アプリケーションが地方(文化的な)のコンベンションを使用したいと思うなら、追加形式情報が必要です。 この形式は情報を含んでいます、とそれがあるタイプの原文のデータ(期日、回、数、および通貨の記法)をユーザにとって、身近なフォームにフォーマットするのに必要なデータを前提とします。 現場のPOSIX[POSIX]記法は言語、コード化文字集合、および文化的なコンベンションを包含します。
To avoid unfruitful discussion, and to make the best use of the time available for the workshop, we declared the following issues out of scope for the purposes of this workshop:
無駄な議論を避けて、有効にワークショップに空いている時間を利用するために、私たちはこのワークショップの目的のために範囲から以下の問題を宣言しました:
- glyphs
- sorting
- culture (e.g. do we present the American or British spelling?)
- user interface issues
- internal representation of textual data
- included characters (why aren't certain characters available in
any character set?)
- locale (in the POSIX sense)
- font registration
- semantics
- user input/output issues
- Han unification issues
- glyphs--ソーティング--文化(例えば、私たちはアメリカの、または、イギリスのスペルを提示しますか?) - ユーザーインタフェース問題(原文のデータの内部の表現)はキャラクタ(確信しているキャラクタはなぜどんな文字集合でも手があいていませんか?)を含んでいました。 - 現場(POSIX意味における)--フォント登録--意味論--ユーザ入力/出力問題--漢字統合問題
There are some related issues which were included for discussion, most importantly the 'locale' components necessary for transport and identification of multilingual texts.
関係づけられた或るものは最も重要にそこでは、議論のために含まれていた問題です。多言語テキストの輸送と識別に必要な'現場'コンポーネント。
2.2: Character Set handling in existing protocols
2.2: 既存のプロトコルにおける文字コード取り扱い
One of the group's overriding concerns was that the framework developed for character set handling not break existing protocols. With that in mind, the way character sets are being used in existing protocols was examined. See Appendix A for a list of those protocols and some recommendations for change.
グループが関心をくつがえすものは文字集合取り扱いのために開発されたフレームワークが既存のプロトコルを破らないということでした。 そのことを考慮に入れて、文字集合が既存のプロトコルに使用されている方法は調べられました。 それらのプロトコルと変化のためのいくつかの推薦のリストに関してAppendix Aを見てください。
2.2.1: General comments
2.2.1: 概評
The problem areas here fall into three main categories: protocols,
ここの問題領域は3つの主なカテゴリになります: プロトコル
Weider, et. al. Informational [Page 4] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [4ページ]情報のRFC2130文字コードワークショップレポート1997年4月
identifiers, and data.
識別子、およびデータ。
2.2.1.1: Protocols
2.2.1.1: プロトコル
The protocol machinery SHOULD NOT be changed; allowing, for instance, SMTP [SMTP] to use both MAIL FROM and POST FRA is dangerous to the protocols' stability. However, many protocols carry error messages and other information that is intended for human consumption; it MIGHT be an advantage to allow these to be localized into a specific language and character set, rather than staying in English and US- ASCII [ASCII]. If this is done, new extensions should follow the framework outlined below.
機械SHOULD NOTについて議定書の中で述べてください。変えてください。 例えば、SMTP[SMTP]がMAIL FROMとPOST FRAの両方を使用するのを許容するのはプロトコルの安定性に危険です。 しかしながら、多くのプロトコルがエラーメッセージと人間の消費で意図する他の情報を運びます。 それ、MIGHT、これらがイギリスの、そして、米国のASCII[ASCII]で滞在しているよりむしろ特定の言語と文字集合にローカライズされるのを許容する利点になってください。 これが完了しているなら、新しい拡大は以下に概説されたフレームワークに続くべきです。
2.2.1.2: Identifiers.
2.2.1.2: 識別子。
There is a strong statement of direction from the IAB, RFC 1958 [RFC 1958], which states:
IAB、RFC1958年からの以下を述べる方向[RFC1958]の歯に衣着せぬ陳述があります。
4.3 Public (i.e. widely visible) names should be in case
independent ASCII. Specifically, this refers to DNS names,
and to protocol elements that are transmitted in text format.
...
5.4 Designs should be fully international, with support for
localization (adaptation to local character sets). In
particular, there should be a uniform approach to character
set tagging for information content.
4.3 ケースの独立しているASCIIには公共(すなわち、広く目に見える)の名前があるべきです。 明確に、これはDNS名、およびテキスト形式で伝えられるプロトコル要素を参照します。 ... 5.4のデザインがローカライズ(ローカルキャラクターセットへの適合)のサポートで完全に国際的であるべきです。 特に、情報量のための文字集合タグ付けへの一定のアプローチがあるべきです。
In protocols that up to now have used US-ASCII only, UTF-8 [UTF-8] forms a simple upgrade path; however, its use should be negotiated either by negotiating a protocol version or by negotiating charset usage, and a fallback to a US-ASCII compatible representation such as UTF-7 [UTF-7] MUST be available.
これまで米国-ASCIIだけを使用したプロトコルでは、UTF-8[UTF-8]は簡単なアップグレード経路を形成します。 しかしながら、使用はプロトコルバージョンを交渉するか、またはcharset用法を交渉することによって、交渉されるべきです、そして、UTF-7[UTF-7]などの米国-ASCIIコンパチブル表現への後退は利用可能であるに違いありません。
The need for passing application data such as language on individual identifiers varies between applications; protocols SHOULD attempt to evaluate this need when designing mechanisms. Applying the ASCII requirement for identifiers that are only used in a local context (such as private mailbox folder names) is both unrealistic and unreasonable; in such cases, methods for consistency in the handling of character set should be considered.
個々の識別子に関する言語などのアプリケーションデータを通過する必要性はアプリケーションの間で異なります。 プロトコルSHOULDは、メカニズムを設計するとき、この必要性を評価するのを試みます。ローカルの関係(個人的なメールボックスフォルダー名などの)で使用されるだけである識別子のためのASCII要件を適用するのは、非現実的であって、かつ無理です。 そのような場合、文字集合の取り扱いにおける一貫性のためのメソッドは考えられるべきです。
2.2.1.3: Data
2.2.1.3: データ
Data that require character set handling includes text, databases, and HTML [HTML] pages, for example. In these the support for multiple character sets and proper application information is absolutely vital, and MUST be supported.
文字集合取り扱いを必要とするデータがテキスト、データベース、および例えばHTML[HTML]ページを含んでいます。 これらでの複数の文字集合と適切なアプリケーション情報のサポートを絶対に重大であり、サポートしなければなりません。
Weider, et. al. Informational [Page 5] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [5ページ]情報のRFC2130文字コードワークショップレポート1997年4月
2.3: Architectural requirements
2.3: 建築要件
To address the issues enumerated for this work, first an architectural model was created which establishes the components that are required to fully specify the transmission of textual data. Many of these components are already familiar to the users of encoding protocols such as MIME. Not all of these are discussed in detail in this report; we restrict ourselves primarily to those components which are required to specify the 'on-the-wire' phase of text transmission.
この仕事のために列挙された問題を扱うために、最初に、原文のデータの伝達を完全に指定するのに必要であるコンポーネントを確立する建築モデルは創造されました。 MIMEなどのコード化プロトコルのユーザには、これらのコンポーネントの多くが既に身近です。 このレポートで詳細にこれらのすべてについて議論するというわけではありません。 私たちは自分達を主として'ワイヤ'のテキスト伝送のフェーズを指定するのに必要であるそれらのコンポーネントに制限します。
Mandating a single, all-encompassing character set would not fit well with the IETF philosophy of planning for architectural diversity. So, the best that can be done is to provide a common *framework* for identifying and using the multitude of character sets available on the Internet. It would be an advantage if the total number of Coded Character Sets could be kept to a minimum. This framework should meet the following requirements:
単一の、そして、オール取り囲んでいる文字集合を強制するのは建築多様性の計画を立てるIETF哲学をよく与えないでしょう。 それで、尽くすことができるベストはインターネットで利用可能な文字集合の多数を特定して、使用するのに一般的な*フレームワーク*を提供することです。 Coded文字コードの総数を最小限に保つことができるなら、それは利点でしょうに。 このフレームワークは以下の必要条件を満たすべきです:
- it should not break existing protocols (because then the likelihood
of deployment is very small),
- it should allow the use of character sets currently used on the
Internet, and
- it should be relatively easy to build into new protocols.
- そして、それは既存のプロトコルを破るべきではありません(次に、展開の見込みが非常に小さいので)--現在インターネットで使用されている文字集合の使用を許すべきである、--新しいプロトコルに建てるのは比較的簡単であるはずです。
3: Architectural model
3: 建築モデル
The basic architectural model which guided our discussions is shown in below. A distinction was made between those segments which were necessary to successfully transmit character set data on-the-wire and those needed to present that data to a user in a comprehensible manner. The discussions were primarily restricted to those segments of the model which specify the 'on-the-wire' transmission of textual data.
私たちの議論を誘導した基本的な建築モデルで、以下で目立ちます。 それらのワイヤの上に首尾よく文字集合データを送るのに必要であったセグメントの間で区別をしました、そして、ものは分かりやすい態度でそのデータをユーザに提示する必要がありました。 議論は主として'ワイヤ'での原文のデータの伝達を指定するモデルのそれらのセグメントに制限されました。
User interface issues: these are briefly discussed in Section 3.1.1.
Layout
Culture
Locale
Language
On-the-wire: see section 3.2 for detailed discussion.
Transfer Syntax
Character Encoding Scheme
Coded Character Set
ユーザーインタフェース問題: セクション3.1.1で簡潔にこれらについて議論します。 レイアウトはワイヤの上に現場言語を培養します: 詳細な論議に関してセクション3.2を見てください。 転送構文文字符号化体系コード化文字集合
Weider, et. al. Informational [Page 6] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [6ページ]情報のRFC2130文字コードワークショップレポート1997年4月
3.1: Segments defined
3.1: 定義されたセグメント
3.1:1: User interface
3.1:1: ユーザーインタフェース
3.1.1.1: Layout
3.1.1.1: レイアウト
Layout includes the elements needed for displaying text to the user, such as font selection, word-wrapping, etc. It is similar to the 'presentation' layer in the 7-layer ISO telecommunications model [ISO-7498].
レイアウトはユーザにテキストを表示するのに必要であるフォント選択などの要素、単語ラッピングなどを含んでいます。 それは7ISOテレコミュニケーションモデル[ISO-7498]層の'プレゼンテーション'層と同様です。
3.1.1.2: Culture
3.1.1.2: 文化
Culture includes information about cultural preferences, which affect spelling, word choice, and so forth.
文化は文化的嗜好の情報を含んでいます。(文化的嗜好はスペル、単語選択などに影響します)。
3.1.1.3: Locale
3.1.1.3: 現場
The locale component includes the information necessary to make choices about text manipulation which will present the text to the user in an expected format. This information may include the display of date, time and monetary symbol preferences. Notice that locale modifications are typically applied to a text stream before it is presented to the user, although they also are used to specify input formats.
現場コンポーネントは、テキストに関する選択を予想された形式でユーザにテキストを提示する操作にするように必要情報を含んでいます。 この情報は期日、時間、および通貨のシンボル好みのディスプレイを含むかもしれません。 それがユーザに提示される前に現場変更がテキストストリームに通常適用されるのに注意してください、また、それらは入力フォーマットを指定するのに使用されますが。
3.1.1.4: Language
3.1.1.4: 言語
This component specifies the language of the transmitted text. At times and in specific cases, language information may be required to achieve a particular level of quality for the purpose of displaying a text stream. For example, UTF-8 encoded Han may require transmission of a language tag to select the specific glyphs to be displayed at a particular level of quality.
このコンポーネントは伝えられたテキストの言語を指定します。 時と特定の場合では、言語情報が、テキストストリームを表示する目的のために特定のレベルの品質を獲得するのに必要であるかもしれません。 例えば、UTF-8はハンをコード化しました。特定のglyphsが特定のレベルの品質で表示されるのを選択するために言語タグをトランスミッションに要求するかもしれません。
Note that information other than language may be used to achieve the required level of quality in a display process. In particular, a font tag is sufficient to produce identical results. However, the association of a language with a specific block of text has usefulness far beyond its use in display. In particular, as the amount of information available in multiple languages on the World Wide Web grows, it becomes critical to specify which language is in use in particular documents, to assist automatic indexing and retrieval of relevant documents.
言語以外の情報がディスプレイプロセスで必要なレベルの品質を獲得するのに使用されるかもしれないことに注意してください。 フォントタグは、同じ結果を生むために特に、十分です。 しかしながら、テキストの特定のブロックがある言語の協会には、遠くにディスプレイにおける使用を超えて有用性があります。 WWWに関する複数の言語で有効な情報量が成長するのに応じて、特に、どの言語が関連ドキュメントの自動索引作業と検索を促進するために特定のドキュメントで使用中であるかを指定するのが重要になります。
Weider, et. al. Informational [Page 7] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [7ページ]情報のRFC2130文字コードワークショップレポート1997年4月
The term 'language tag' should be reserved for the short identifier of RFC 1766 [RFC-1766] that only serves to identify the language. While there may be other text attributes intimately associated with the language of the document, such as desired font or text direction, these should be specified with other identifiers rather than overloading the language tag.
'言語タグ'という用語は言語を特定するのに役立つだけであるRFC1766[RFC-1766]の短い識別子のために取っておかれるべきです。 親密にドキュメントの言語に関連している他のテキスト属性があるかもしれない間、必要なフォントやテキスト方向のようなこれらは言語タグを積みすぎるより他の識別子でむしろ指定されるべきです。
3.2: On the wire
3.2: ワイヤに関して
There are three segments of the model which are required for completely specifying the content of a transmitted text stream (with the occasional exception of the Language component, mentioned above). These components are:
伝えられたテキストストリーム(前記のようにLanguageの部品の時々の例外で)の内容を完全に指定するのに必要であるモデルの3つのセグメントがあります。 これらのコンポーネントは以下の通りです。
1) Coded Character Set, 2) Character Encoding Scheme, and 3) Transfer Encoding Syntax.
1) コード化文字集合、2) 文字符号化体系、および3) 構文をコード化して、移してください。
Each of these abstract components must be explicitly specified by the transmitter when the data is sent. There may be instances of an implicit specification due to the protocol/standard being used (i.e. ANSI/NISO Z39.50). Also, in MIME, the Coded Character Set and Character Encoding Scheme are specified by the Charset parameter to the Content-Type header field, and Transfer Encoding Syntax is specified by the Content-Transfer-Encoding header field.
データを送るとき、送信機は明らかにそれぞれのこれらの抽象的なコンポーネントを指定しなければなりません。 暗黙の仕様のインスタンスが使用されるプロトコル/規格(すなわち、ANSI/NISO Z39.50)のためにあるかもしれません。 また、MIMEでは、Coded文字コードとキャラクターEncoding SchemeはCharsetパラメタによってコンテントタイプヘッダーフィールドに指定されます、そして、Transfer Encoding SyntaxはContent転送コード化ヘッダーフィールドによって指定されます。
3.2.1: Coded Character Set
3.2.1: コード化文字集合
A Coded Character Set (CCS) is a mapping from a set of abstract characters to a set of integers. Examples of coded character sets are ISO 10646 [ISO-10646], US-ASCII [ASCII], and ISO-8859 series [ISO-8859].
Coded文字コード(CCS)は1セットの抽象的なキャラクタから1セットの整数までマッピングです。 コード化文字集合に関する例は、ISO10646[ISO-10646]と、米国-ASCII[ASCII]と、ISO-8859シリーズ[ISO-8859]です。
3.2.2: Character Encoding Scheme
3.2.2: 文字符号化体系
A Character Encoding Scheme (CES) is a mapping from a Coded Character Set or several coded character sets to a set of octets. Examples of Character Encoding Schemes are ISO 2022 [ISO-2022] and UTF-8 [UTF-8]. A given CES is typically associated with a single CCS; for example, UTF-8 applies only to ISO 10646.
Coded文字コードかいくつかのコード化文字集合から1セットの八重奏までキャラクターEncoding Scheme(CES)はマッピングです。 キャラクターEncoding Schemesに関する例は、ISO2022[ISO-2022]とUTF-8[UTF-8]です。 与えられたCESは独身のCCSに通常関連しています。 例えば、UTF-8はISO10646だけに適用します。
Weider, et. al. Informational [Page 8] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [8ページ]情報のRFC2130文字コードワークショップレポート1997年4月
3.2.3: Transfer Encoding Syntax
3.2.3: 構文をコード化して、移してください。
It is frequently necessary to transform encoded text into a format which is transmissible by specific protocols. The Transfer Encoding Syntax (TES) is a transformation applied to character data encoded using a CCS and possibly a CES to allow it to be transmitted. Examples of Transfer Encoding Syntaxes are Base64 Encoding [Base64], gzip encoding, and so forth.
変形するのが特定のプロトコルで伝えられる形式にテキストをコード化したのが頻繁に必要です。 Transfer Encoding Syntax(TES)はそれが伝えられるのを許容するのにCCSとことによるとCESを使用することでコード化されたキャラクタデータに適用された変換です。 Transfer Encoding Syntaxesに関する例は、Base64 Encoding[Base64]、gzipコード化などです。
3.3: Determining which values of CCS, CES, and TES are used
3.3: CCS、CES、およびTESのどの値が使用されているかを決定します。
To completely specify which CCS, CES, and TES are used in a specific text transmission, there needs to be a consistent set of labels for specifying which CCS, CES, and TES are used. Once the appropriate mechanisms have been selected, there are six techniques for attaching these labels to the data.
どのCCS、CES、およびTESが特定のテキスト伝送に使用されるかを完全に指定するために、CCS、CES、およびTESがどれであるかを指定するための一貫したセットの使用されたラベルがあるのが必要です。 適切な手段がいったん選択されると、これらのラベルをデータに取り付けるための6つのテクニックがあります。
The labels themselves are named and registered, either with IANA [IANA] or with some other registry. Ideally, their definitions are retrievable from some registration authority.
ラベル自体は、IANA[IANA]かある他の登録に命名されて、登録されます。 理想的に、彼らの定義はある登録局から回収可能です。
Labels may be determined in one of the following ways:
ラベルは以下の方法の1つで断固としているかもしれません:
- Determined by guessing, where the receiver of the text has to
guess the values of the CCS, CES, and TES. For example: "I got
this from Sweden so it's probably ISO-8859-1." This is
obviously not a very foolproof way to decode text.
- Determined by the standard, where the protocol used to transmit
the data has made documented choices of CCS, CES, and TES in the
standard. Thus, the encodings used are known through the
access protocol, for example HTTP [HTTP] uses (but is not
limited to) ISO-8859-1, SMTP uses US-ASCII.
- Attached to the transfer envelope, where the descriptive labels are
attached to the wrapper placed around the text for transport.
MIME headers are a good example of this technique.
- Included in the data stream, where the data stream itself has
been encoded in such a way as to signal the character set used.
For example, ISO-2022 encodes the data with escape sequences to
provide information on the character subset currently being used.
- Agreed by prior bilateral agreement, where some out-of-band
negotiation has allowed the text transmitter and receiver to
determine the CCS, CES, and TES for the transmitted text.
- Agreed to by negotiation during some phase, typically
initialization of the protocol.
- テキストの受信機がCCS、CES、およびTESの値を推測しなければならないところで推測することによって、断固としています。 例えば: 「私がスウェーデンからこれを得たので、それはたぶんISO-8859-1です。」 これは明らかにテキストを解読する非常にきわめて簡単な方法ではありません。 - 規格で断固としていて、データはプロトコルが以前はよく伝わっていたところで規格でCCS、CES、およびTESの記録された選択をしました。 しかし、その結果、使用されるencodingsはアクセス・プロトコルを通して知られています、例えば[HTTP]が使用するHTTP、(制限されない、)、ISO-8859-1、SMTPは米国-ASCIIを使用します。 - 転送封筒に付きました。品質表示は封筒で輸送のためにテキストの周りに置かれたラッパーに付けられています。 MIMEヘッダーはこのテクニックの好例です。 - データ・ストリームで含まれていて、データがどこにそれ自体を流すかは文字集合が使用した信号に関してそのような方法でコード化されました。 例えば、ISO-2022は、文字サブセットの情報を提供するためにエスケープシーケンスで現在使用されることでデータをコード化します。 - 先の二国間条約によって同意されます。何らかのバンドで出ている交渉で、そこでは、テキスト送信機と受信機が伝えられたテキストのためにCCS、CES、およびTESを決定できました。 - 交渉で、何らかのフェーズ、通常プロトコルの初期化の間、同意されます。
Weider, et. al. Informational [Page 9] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [9ページ]情報のRFC2130文字コードワークショップレポート1997年4月
3.3.1: Recommendations for value specification mechanisms
3.3.1: 値の仕様メカニズムのための推薦
While each of these techniques (with the exception of guessing) is useful in particular situations, interoperability requires a more consistent set of techniques. Thus, we recommend that MIME registered values be used for all tagging of character sets and languages UNLESS there is an existing mechanism for determining the required information using one of the other techniques (except guessing). This recommendation will require a fair bit of work on the part of protocol designers, implementors, the IETF, the IESG, and the IAB.
それぞれのこれらのテクニック(推測を除いた)は特定の状況で役に立ちますが、相互運用性は、より一貫したセットにテクニックを要求します。 したがって、私たちは、MIMEの登録された値が文字集合のすべてのタグ付けに使用されることを勧めます、そして、そこの言語UNLESSは、他のテクニック(推測を除いた)の1つを使用することで必須情報を決定するための既存のメカニズムです。 この推薦はプロトコルデザイナー、作成者、IETF、IESG、およびIAB側の仕事の公正なビットを必要とするでしょう。
However, it is important to point out that the MIME concept of 'charset' in some cases cuts across several layers of components in our model. While this can be accepted in existing registrations, we also recommend that the MIME registration procedure for character sets be modified to show how a proposed character set deals with the CCS and the CES. Most 'charsets' have a well defined CCS and CES, they should merely be teased apart for the registration.
しかしながら、いくつかの場合、'charset'のMIME概念が私たちのモデルの数個の層の部品を横切ると指摘するのは重要です。 また、既存の登録証明書でこれを受け入れることができる間、私たちは、文字集合のためのMIME登録手順が提案された文字集合がどうCCSとCESに対処するかを示しているように変更されることを勧めます。 ほとんどの'charsets'にはよく定義されたCCSとCESがあって、彼らは登録のために単に離れてからかわれるべきです。
There are a number of other recommendations, but these will be covered in the next sections.
他の多くの推薦がありますが、これらは次のセクションでカバーされているでしょう。
3.4: Recommended Defaults
3.4: お勧めのデフォルト
For a number of reasons, one cannot define a mandatory set of defaults for all Internet protocols. There is a mass of current practice, future protocols are likely to have different purposes, which may determine their handling of text, and protocols may need specific variation support. For example, in mail, text is a predominant data type and coded character sets then become a major issue for the protocol. Also, since e-mail is ubiquitous and users expect to be able to send it to everyone, the mail protocols need to be quite adept at handling different character set encodings. On the other hand, if strings are seldom used in a given protocol, there is no need to weigh the protocol down with a sophisticated apparatus for handling multiple character sets, assuming that the predicated character set can handle all the protocol's needs. This observation also applies to the specification techniques for character set parameters. If only one character set encoding is needed, it can be made explicit in the protocol specification. Protocols with a greater need for character set support will need a more elaborate specification technique.
様々な意味で、人はすべてのインターネットプロトコルのために義務的なデフォルトを定義できません。 (異なる役割は彼らのテキストの取り扱いを決定するかもしれません)。 例えば、テキストはメールでは、支配的なデータ型です、そして、次に、コード化文字集合はプロトコルのための主要な問題になります。 また、メールが遍在していて、ユーザが、それを皆に送ることができると予想するので、メールプロトコルは、取り扱い異なった文字集合encodingsでかなり手際である必要があります。 他方では、ストリングが与えられたプロトコルにめったに使用されないなら、複数の文字集合を扱うための精巧な装置でプロトコルを圧する必要は全くありません、叙述された文字集合がプロトコルのものが必要とするすべてを扱うことができると仮定して。 また、この観測は文字集合パラメタのために仕様のテクニックに適用されます。 1つの文字集合のコード化を必要として、それをプロトコル仕様で明白にすることさえできれば、よかったでしょう。 文字集合サポートに関するより大きな必要性を伴うプロトコルは、より精巧な仕様のテクニックを必要とするでしょう。
Weider, et. al. Informational [Page 10] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [10ページ]情報のRFC2130文字コードワークショップレポート1997年4月
3.4.1: Clarity of specification
3.4.1: 仕様の明快
We recommend that each protocol clearly specify what it is using for each of the layers of the transmission model. Users (or clients) should never have to guess what the parameter is for a given layer.
私たちは、各プロトコルが、それがそれぞれのトランスミッションモデルの層に何を使用しているかを明確に指定することを勧めます。 ユーザ(または、クライアント)は、パラメタが与えられた層のための何であるかを決して推測する必要はないはずです。
3.4.2: Default Coded Character Set:
3.4.2: デフォルトコード化文字集合:
The default Coded Character Set is the repertoire of ISO-10646.
デフォルトCoded文字コードはISO-10646のレパートリーです。
3.4.3: Default Character Encoding Scheme
3.4.3: デフォルト文字符号化体系
For text-oriented protocols, new protocols should use UTF-8, and protocols that have a backwards compatibility requirement should use the default of the existing protocol, e.g. US-ASCII for mail, and ISO-8859-1 for HTTP. The recommended specification scheme is the MIME "charset" specification, using the IANA "charset" specifications. The MIME specifications will need to be clarified to meet this model in the future.
テキスト指向のプロトコルのために、新しいプロトコルはUTF-8を使用するべきです、そして、遅れている互換性要件を持っているプロトコルは既存のプロトコルのデフォルト、例えば、メールのための米国-ASCII、およびHTTPのためのISO-8859-1を使用するべきです。 IANA"charset"仕様を使用して、お勧めの仕様体系はMIME"charset"仕様です。 MIME仕様は、将来このモデルに会うためにはっきりさせられる必要があるでしょう。
For other protocols, the default should be UTF-8 as this initially allows US-ASCII to be entered as-is, and enables the full repertoire of ISO 10646.
他のプロトコルのために、これが初めは米国-ASCIIがそのままで入られるのを許可して、ISO10646の完全なレパートリーを可能にするとき、デフォルトはUTF-8であるべきです。
Some protocols, such as those descended from SGML [SGML], have other natural notations for characters outside their "natural" repertoire; for instance, HTML [HTML] allows the use of &#nnnn to refer to any ISO 10646 character. Note that this, like all other encodings that depend on "escape characters", redefines at least one character from the base character set for use as an indicator of "foreign" characters. Use of this approach must be weighed very carefully.
SGML[SGML]が離されたそれらなどのいくつかのプロトコルが彼らの「自然な」レパートリーの外でキャラクタのための他の自然な記法を持っています。 例えば、[HTML]が使用を許すHTMLとどんなISO10646キャラクタについても言及する#nnnn。 これが、使用のために「拡張文字」による他のすべてのencodingsのようにベース文字集合から少なくとも1つのキャラクタを「外国」のキャラクタのインディケータと再定義することに注意してください。 非常に慎重にこのアプローチの使用を熟慮しなければなりません。
3.4.4: Default Transport Encoding Scheme
3.4.4: 体系をコード化するデフォルト輸送
There is no recommended default for this level. For plain text oriented protocols, the bytestream transport format should be 8-bit clean, possibly with normalization of end-of-line indicators. Some special cases could be made for protocols that are not 8-bit clean, such as encoding it for transport over 7-bit connections. For binary the same recommendation holds as above. The specification technique should either be defined in the protocol, if only one way is permitted, or by use of MIME content-transfer-encoding (CTE) techniques, using IANA registered values.
このレベルのためのどんなお勧めのデフォルトもありません。 プレーンテキスト指向のプロトコルのために、ことによると行末インディケータの正常化で清潔な状態でbytestream輸送形式は8ビットであるべきです。 清潔な状態で8ビットでないプロトコルのためにいくつかの特別な弁護をすることができました、7ビットの接続の上の輸送のためにそれをコード化するのなどように。 バイナリーのために、同じ推薦は同じくらい上で当てはまります。 仕様のテクニックはプロトコルで定義されるべきです、1つの方法だけが受入れられたか、またはIANAを使用すると値がMIMEの満足している転送コード化(CTE)のテクニックの使用で示されたなら。
Weider, et. al. Informational [Page 11] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [11ページ]情報のRFC2130文字コードワークショップレポート1997年4月
3.4.5: Default Language
3.4.5: デフォルト言語
There is no recommended default for the language level. For human readable text, there should always be a way to specify the natural language. The specification technique should be a MIME identifier with IANA registered values for languages. If headers are used, the header should be 'Content-Language'.
言語水準のためのどんなお勧めのデフォルトもありません。 人間の読み込み可能なテキストのために、自然言語を指定する方法がいつもあるべきです。 仕様のテクニックはIANAがあるMIME識別子が言語のために値を示したということであるべきです。 ヘッダーが使用されているなら、ヘッダーは'満足している言語'であるべきです。
3.4.6: Default Locale
3.4.6: デフォルト現場
The default should be the POSIX locale. The specification technique should use the Cultural register of CEN ENV 12005 [CEN] for the values. If headers are used, the header should be 'Content-Locale'.
デフォルトはPOSIX現場であるべきです。 仕様のテクニックは値にCEN ENV12005[CEN]に関するCulturalレジスタを使用するべきです。 ヘッダーが使用されているなら、ヘッダーは'満足している現場'であるべきです。
3.4.7: Default Culture
3.4.7: デフォルト文化
There is no recommended default for the Culture level. The specification technique should be a MIME or MIME-like identifier (e.g. Content-Culture) and should use the Cultural register of CEN ENV 12005 for its values.
文化レベルのためのどんなお勧めのデフォルトもありません。 仕様のテクニックは、MIMEかMIMEのような識別子であるべきであり(例えば、Content-文化)、値にCEN ENV12005に関するCulturalレジスタを使用するべきです。
3.4.8: Default Presentation
3.4.8: デフォルトプレゼンテーション
There is no recommended default for the Presentation level. The specification technique should be a MIME or MIME-like identifier (e.g. Content-Layout) and use the glyph register of ISO 10036 and other registers for its values.
Presentationレベルのためのどんなお勧めのデフォルトもありません。 仕様のテクニックは、MIMEかMIMEのような識別子(例えば、Content-レイアウト)であり、値にISO10036と他のレジスタに関するglyphレジスタを使用するべきです。
3.4.9: Multiplexing
3.4.9: マルチプレクシング
In some cases, text transmission may require the use of a number of different values for a given parameter; for example, English annotation of Japanese text might well require shifting the Content- Language parameter. The way to switch the value of parameters within a single body of text depends on the application. For instance, the HTML I18N [I18N] work defines a language attribute on most of its elements, including <SPAN>, <HTML>, and <BODY>, for the purpose of switching between different languages. When only one value is needed, this value should be as general as possible, and specified in the protocol standard with reference to the IANA or other registry value. All levels should be specified explicitly.
いくつかの場合、テキスト伝送は多くの異価の与えられたパラメタの使用を必要とするかもしれません。 例えば、和文のイギリスの注釈は、たぶんContent言語パラメタを移行させるのを必要とするでしょう。 テキストの単一のボディーの中でパラメタの値を切り換える方法はアプリケーションによります。 例えば、HTML I18N[I18N]仕事は要素の大部分の言語属性を定義します、<SPAN>、<HTML>、および<BODY>を含んでいて、異なった言語を切り換える目的のために。 1つの値だけが必要であるときに、この値は、できるだけ一般的で、IANAか他の登録値に関してプロトコル標準で指定されているべきです。 すべてのレベルが明らかに指定されるべきです。
3.4.10: Storage
3.4.10: ストレージ
Because stored text may very well be stored without any of the additional information necessary for decoding, stored text SHOULD be tagged in a MIME compliant fashion. This alleviates the problem of being unable to interpret text which has been stored for a long time,
保存されたテキストが非常によく保存されるかもしれないので、解読、保存されたテキストSHOULDに必要な追加情報のいずれがなければも、MIME対応することのファッションでタグ付けをされてください。 これは長い間保存されているテキストを解釈できないという問題を軽減します。
Weider, et. al. Informational [Page 12] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [12ページ]情報のRFC2130文字コードワークショップレポート1997年4月
or text whose provenance is not available.
または、起源が利用可能でないテキスト。
3.5: Guidelines for conversions between coded character sets
3.5: コード化文字集合の間の変換のためのガイドライン
This section covers various algorithms to convert a source text S, encoded in the coded character set CCS(S), to a target text T, encoded in the coded character set CCS(T).
このセクションは、コード化文字集合CCS(T)でコード化された目標テキストTにコード化文字集合CCS(S)でコード化された原始テキストSを変換するために様々なアルゴリズムをカバーします。
Rep(X) is the character repertoire of coded character set X, i.e. the set of characters which can be represented with X.
レップ(X)はコード化文字集合X(すなわち、Xと共に代理をされることができるキャラクタのセット)のキャラクタレパートリーです。
3.5.1: Exact conversion
3.5.1: 正確な変換
When Rep(CCS(S)) and Rep(CCS(T)) are equal or Rep(CCS(S)) is a subset of Rep(CCS(T)), exact conversion is possible; i.e. T is equal to S. The octets just need to be remapped. The algorithm for performing this remapping is simple, if the IANA-registered definition tables for CCS(S) and CCS(T) are available.
CCS(S))はRepの部分集合です。Repである、(CCS(S))とRep、(CCS(T))が同輩かRepである、((CCS(T))、正確な変換は可能です。 すなわち、Tは八重奏が再写像されるためにただ必要とするS.と等しいです。 CCS(S)とCCS(T)のためのIANAによって登録された定義テーブルが利用可能であるなら、この再写像を実行するためのアルゴリズムは簡単です。
3.5.2: Approximate conversion
3.5.2: 近似転換
In all other cases, any conversion creates a text T which differs from S. There are different principles for how this inevitable difference should be handled. A choice between them should be made, depending on the purpose and requirements of the conversion. Where possible, the client application should be given mechanisms to determine what has been done to the text.
他のすべての場合では、どんな変換もS.と異なっているテキストTを作成します。Thereは、この必然の違いがどう扱われるべきであるか異なった原則です。 変換の目的と要件によって、それらの選択をするべきです。 可能であるところでは、メカニズムをテキストに何をしたかをクライアントアプリケーションに決定させるべきです。
3.5.2.1: Length-modifying conversion for human display
3.5.2.1: 人間のディスプレイのための長さを変更する変換
When the length of the target text T is allowed to differ from the length of the source text S, one should use a conversion method in which each source character is converted to one or several target character(s), using a best resemblance criteria in the choice of that target character(s).
目標テキストTの長さが原始テキストSの長さと異なることができるとき、それぞれのソースキャラクタが1つに変換される変換法か数個の目標キャラクタを使用するべきであり、最も良い類似を使用して、それの選択における評価基準はキャラクタを狙います。
Examples:
LATIN CAPITAL LETTER [*] -> AE
COPYRIGHT SIGN [*] -> (c)
例: ラテン語の大文字[*]->AE著作権サイン[*]->。(c)
3.5.2.2: Length-preserving conversion for human display
3.5.2.2: 人間のディスプレイのための長さを保存する変換
Where the text T must be presented and the length of T cannot differ from the length of S, one should use a conversion method where each source character is converted to one target character, using some kind of best resemblance criteria in the choice of target character.
テキストTを提示しなければならなくて、Tの長さがSの長さと異なることができないところでは、それぞれのソースキャラクタが1つの目標キャラクタに変換される変換法を使用するべきです、ある種の目標キャラクタの選択で最も良い類似評価基準を使用して。
Weider, et. al. Informational [Page 13] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [13ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Examples:
LATIN CAPITAL LETTER [*] -> A
COPYRIGHT SIGN [*] -> C
例: 著作権が[*]->Cに署名するラテン語の大文字[*]->。
3.5.2.3: Conversion without data loss
3.5.2.3: データの損失のない変換
Where the conversion of the text S into T must be completely reversible, apply a Character Encoding Syntax or other reversible transformation method. This case is most frequently met in data storage requirements.
TへのテキストSの変換が完全にリバーシブルでなければならないところに、キャラクターEncoding Syntaxか他の可逆的な変換メソッドを適用してください。 本件はデータ保存要件で最も頻繁に満たされます。
Examples:
LATIN CAPITAL LETTER [*] -> &AE
COPYRIGHT SIGN [*] -> &(C
例: ラテン語の大文字[*]->とAE著作権サイン[*]->、(C
An alternate method, which can be used if the size of Rep(CCS(T)) >= Rep(CCS(S)), then for each character in Rep(CCS(S)) which is not present in Rep(CCS(T)), define a mapping into a character in Rep(CCS(T)) which is not present in Rep(CCS(S)).
そうするCCS(T))は中でRepを寄贈しません。Repのサイズであるなら使用できる代替方法、(CCS(T))>がレップと等しい、(そして、Repの各キャラクタのためのCCS(S))、(Repに存在していないCCS(S))、(CCS(T))、Repのキャラクタとマッピングを定義してください、((CCS(S))。
Examples:
LATIN CAPITAL LETTER [*] -> CYRILLIC CAPITAL LETTER [*]
COPYRIGHT SIGN [*] -> PARTIAL DIFFERENTIAL SIGN [*]
例: ラテン語の大文字[*]の->のキリル文字の大文字[*]著作権サイン[*]->偏微分サイン[*]
Note that conversion without data loss requires redefining some member of T to indicate "the introduction of character data outside T". This effectively adds another level of CES on top of CES(T).
データの損失のない変換が、「Tの外のキャラクタデータの導入」を示すためにメンバーを再定義するのをTを要求することに注意してください。 事実上、これはCES(T)の上でCESの別のレベルを加えます。
4: Presentation issues
4: プレゼンテーション問題
There are a number of considerations to make in selecting the base character set. One such consideration is the protocol's convenience to users with limited equipment (for example only ISO 8859-1 or a keyboard without the ability to enter all the characters in ISO 10646). Alternative representation should be considered for these users, both for input and output. Possible options for the representation of characters that can not be displayed include transliteration (a la CEN/TC304 or ISO TC46/SC2 ), RFC 1345 [RFC- 1345] representative icons, or the WG2 short name (u+xxxx).
ベース文字集合を選択する際に作る多くの問題があります。 そのような考慮の1つは限られた設備(ISO10646にすべてのキャラクタを入れる能力のない例えば、ISO8859-1だけかキーボード)をもっているユーザへのプロトコルの便利です。 代替の表現はこれらのユーザと、ともに入出力のために考えられるべきです。 見せることができないキャラクタの表現のための可能なオプションは音訳(CEN/TC304やISO TC46/SC2のような)、RFC1345[RFC1345]の代表しているアイコン、またはWG2省略名(u+xxxx)を含んでいます。
5: Open issues
5: 未解決の問題
In addition to the issues declared out of scope and enumerated in section 2.1, the following issues are still open and will need to be addressed in other forums. These issues: language tags, public identifiers such as URL names, and bi-directionality are briefly discussed below as they repeatedly encroached the discussion.
範囲から宣言されて、セクション2.1で列挙された問題に加えて、以下の問題は、まだ開いていて、他のフォーラムこれらの問題で扱われる必要があるでしょう: 繰り返して食い込んだので以下で議論して、双方向性であるのは、簡潔にそうです。そして、言語タグ、URL名などの公共の識別子、議論。
Weider, et. al. Informational [Page 14] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [14ページ]情報のRFC2130文字コードワークショップレポート1997年4月
5.1: Language tags
5.1: 言語タグ
Although the workshop decided not to explicitly address the so-called "CJK issue", a few members felt it was necessary to have some mechanism to address the problem of correct Han character display in the ISO-10646 issue, and that saying that it was a "font issue" would not suffice.
ワークショップは、明らかにいわゆる「CJK問題」を扱わないと決めましたが、数人のメンバーが、ISO-10646問題で正しいハンキャラクタディスプレイのその問題を訴えるために何らかのメカニズムを持つのが必要であると感じました、そして、それが「フォント問題」であったというそのことわざは十分でないでしょう。
The "CJK issue" refers to the extended discussion about "Han unification", the use of a single ISO-10646 codepoint to represent multiple national variants of a Chinese (Han) character. ISO-10646 can map uniquely to any single CJK national character set, but in the absence of additional information an application can not display an ISO-10646 text using the proper national variants for that text.
「CJK問題」は「漢字統合」((ハン)中国人のキャラクタの複数の国家の異形を表す独身のISO-10646 codepointの使用)の長い討論を示します。 ISO-10646は、そのテキストに適切な国家の異形を使用することでアプリケーションがISO-10646テキストを表示できないという唯一どんなただ一つのCJK国民性にも設定されましたが、追加が不在のとき設定された情報を写像できます。
It was agreed that language tags would be sufficient to disambiguate unified characters. There was not, in our opinion, a significant technical difference between the use of different coded character sets with overlapping codepoints, and a single coded character set with language tags. Either way, the application has sufficient information to display the text properly.
言語タグが統一されたキャラクタのあいまいさを除くために十分であるのに同意されました。 私たちの意見には、異なったコード化文字集合のcodepointsを重ね合わせる使用と、言語タグがあるただ一つのコード化文字集合の間には、重要な技術的な違いがありませんでした。 いずれにせよ、アプリケーションには、適切にテキストを表示できるくらいの情報があります。
It was observed that in contemporary usage of MIME charsets, the language is implied as well as the coded character set and the character encoding syntax. We agreed that this is excessive overloading of MIME charsets.
MIME charsetsの現代の使用法で、言語がコード化文字集合と文字符号化構文と同様に含意されるのが観測されました。 私たちは、これがMIME charsetsの過度の積みすぎであることであるのに同意しました。
To specify the language used in a particular block of text, we recommend that the MIME tag "Content-Language" be used. There are a number of questions about this approach that need to be worked out, however:
テキストの特定のブロックで使用される言語を指定するために、私たちは、MIMEタグ「満足している言語」が使用されることを勧めます。 しかしながら、解決される必要があるこのアプローチに関する多くの質問があります:
- Is Content-Language: actually suitable?
- Is there an overload between this function and the other
intended functions of Content-Language: as described in RFC
1766?
- What, precisely, does "Content-Language: zh-tw, ja, ko, zh-cn"
mean in this context? We believe it means that, in drawing a
Han character, the Taiwanese variant (presumably traditional
Han) is preferred, followed by the Japanese, Korean, and
mainland Chinese (presumably simplified Han) variants. It does
*NOT* mean "mixed text containing Taiwanese, Japanese, Korean,
and mainland Chinese text with all the national variants in
each of these".
- 満足している言語です: 実際に適当ですか? - Content-言語のこの機能と他の意図している機能の間には、オーバーロードがあります: RFC1766で説明されるように? - ことが正確にする、「満足している言語:」 この文脈で意地悪な「zh-tw、ja、ko、zh-cn?」 私たちは、それが、台湾の異形(おそらく伝統的なハン)がハンキャラクタを描く際に好まれることを意味すると信じています、日本人、韓国語、および本土中国人(おそらく簡易型のハン)異形があとに続いていて。 それはどんな意地悪な「それぞれのこれらに台湾人、日本語、韓国語、およびすべての国家の異形がある本土中国語テキストを含む複雑なテキスト」もしません。
Mixed CJK text, that simultaneously displays different variants occupying the same codepoint, requires language tags embedded in the data. Ohta and Handa propose in RFC 1554 [RFC-1554] a MIME charset
Mixed CJKテキスト(同じそんなに同時にディスプレイ異なった異形占領codepoint)はデータに埋め込まれた言語タグを必要とします。 太田と半田は1MIMEあたりのRFC1554年[RFC-1554]にcharsetを提案します。
Weider, et. al. Informational [Page 15] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [15ページ]情報のRFC2130文字コードワークショップレポート1997年4月
using ISO-2022 shifts between multiple coded character sets; in effect this is an encoding that uses coded character sets for displaying the appropriate glyphs.
ISO-2022を使用するのは複数のコード化文字集合の間で移行します。 事実上、これは適切なglyphsを表示するのにコード化文字集合を使用するコード化です。
There is some speculation that states that mixed CJK text is relatively infrequent, and that therefore it is acceptable to require that such text be represented using a rich text format that can support language tags. In other words, that a simplifying assumption can be made for TEXT/PLAIN in email using ISO-10646 that will not require multiple display representations for the same codepoint. A mechanism such as RFC 1554 could address this need if it was important; although arguably RFC 1554 should really be identified as TEXT/ISO-2022.
複雑なCJKテキストが比較的珍しく、したがって、そのようなテキストが言語がタグであるとサポートすることができるリッチテキストフォーマットを使用することで表されるのが必要である許容できると述べる何らかの思惑があります。 言い換えれば、メールによるTEXT/PLAINのためにそうするISO-10646を使用することで簡素化仮定をすることができるのは同じcodepointにおいて複数のディスプレイ表現を必要としません。 それが重要であるなら、RFC1554などのメカニズムはこの必要性を扱うかもしれないでしょうに。 RFC1554は論証上本当にTEXT/ISO-2022として特定されるべきですが。
Note again that we recommend that support for language tagging SHOULD be built into new protocols, as this will become a critical component of the automated indexing and retrieval in information applications of the future.
私たちが、新しいプロトコルが言語タグ付けSHOULDのサポートに組み込まれることを勧めることにもう一度注意してください、これが未来の情報アプリケーションにおける、自動化されたインデックスと検索の重要な要素になるとき。
5.2: Public identifiers
5.2: 公共の識別子
There is a considerable demand from the user community for the ability to use non-ASCII characters in URL names, IMAP mailbox names, file names, and other public identifiers. This is still an open problem.
ユーザーコミュニティからのURL名、IMAPメールボックス名、ファイル名、および他の公共の識別子で非ASCII文字を使用する能力のかなりの要求があります。 これは開いている問題です。
5.3: Bi-directionality
5.3: 双方向性
It was realized that a consistent framework for bi-directional text was needed but there was no attempt to work on it in this workshop.
双方向のテキストのための一貫したフレームワークが必要でしたが、このワークショップで企てる試みが全くなかったと実感されました。
6: Security Considerations
6: セキュリティ問題
There are no security considerations associated with character sets.
文字集合に関連しているどんなセキュリティ問題もありません。
7: Conclusions
7: 結論
This paper provides a conceptual framework and a set of recommendations which, if adopted, should provide a solid foundation for interoperability on the Internet. There are, however, a number of open issues which will need to be addressed to provide ever better use of text on the Internet.
この紙は採用されるならインターネットで堅実な基礎を相互運用性に提供するべきである推薦の概念の構成とセットを提供します。 しかしながら、インターネットにおけるテキストの、より良い使用を提供するために扱われる必要がある多くの未解決の問題があります。
Weider, et. al. Informational [Page 16] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [16ページ]情報のRFC2130文字コードワークショップレポート1997年4月
8: Recommendations
8: 推薦
8.1: To the IAB
8.1: IABに
There were a number of recommendations to the IAB about making the standards process more aware of the need for character set interoperability, and about the framework itself.
標準化過程を文字集合相互運用性の必要性をより意識するようにする周りと、そして、フレームワーク自体の周りに関してIABへの多くの推薦がありました。
A: The IAB should trigger the examination of all RFCs to determine the way they handle character sets, and obsolete or annotate the RFCs where necessary.
A: IABは必要であるところにRFCsの彼らが文字集合を扱う方法で決定するすべてのRFCsの試験の引き金となって、時代遅れにするはずであるか、または注釈するはずです。
B: The IESG should trigger the recommendation of procedures to the RFC editor to encourage RFCs to specify character set handling if they specify the transmission of text.
B: 彼らがテキストの送信を指定するなら、IESGはRFCエディタへの手順が、RFCsが文字集合取り扱いを指定するよう奨励するという推薦の引き金となるはずです。
C: The IAB should trigger the production of a perspectives document on the character set work that has gone on in the past and relate it to the current framework.
C: IABは過去に先へ進んだ文字集合仕事の見解ドキュメントの生産の引き金となって、現在のフレームワークにそれに関連するはずです。
D: Full ISO 10646 has a sufficiently broad repertoire, and scope for further extension, that it is sufficient for use in Internet Protocols (without excluding the use of existing alternatives). There is no need for specific development of character set standards for the Internet.
D: 完全なISO10646には十分広いレパートリー、およびさらなる拡大のための範囲があって、それはインターネットプロトコル(既存の代替手段の使用を除くことのない)における使用に十分です。 インターネットの文字集合規格の特定の開発の必要は全くありません。
E: The IAB should encourage the IRTF to create a research group to explore the open issues of character sets on the Internet. This group should set its sights much higher than this workshop did.
E: IABは、IRTFがインターネットで文字集合の未解決の問題を探るために研究グループを創設するよう奨励するはずです。 このグループはこのワークショップがそうしたよりはるかに高い目標を設定するべきです。
F: The IANA (perhaps with the help of an IETF or IRTF group) should develop procedures for the registration of new character sets for use in the Internet.
F: IANA(恐らくIETFかIRTFグループの助けがある)はインターネットでの使用のために新しい文字集合の登録のための手順を開発するはずです。
G: Register UTF-8 as a Character Encoding Scheme for MIME.
G: MIMEの文字符号化体系としてUTF-8を登録してください。
H: The current use of the "x-*" format for distinguishing experimental tags should be continued for private use among consenting parties. All other namespaces should be allocated by IANA.
H: 「x-*」形式の実験用タグを区別する現在の使用は私的使用目的で賛成者側で続けられるべきです。 他のすべての名前空間がIANAによって割り当てられるはずです。
I: Application protocol RFCs SHOULD include a section on "multilingual Considerations".
私: アプリケーション・プロトコルRFCs SHOULDは「多言語Considerations」のセクションを含んでいます。
J: Application Protocol RFCs SHOULD indicate how to transfer 'on the wire' all characters in the character sets they use. They SHOULD also specify how to transfer other information that applications may need to know about the data.
J: アプリケーションプロトコルRFCs SHOULDは'ワイヤ'でそれらが使用する文字集合ですべてのキャラクタを移す方法を示します。 それら、また、SHOULDはアプリケーションが、データに関して知る必要があるかもしれないという他の情報を移す方法を指定します。
Weider, et. al. Informational [Page 17] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [17ページ]情報のRFC2130文字コードワークショップレポート1997年4月
K: The IESG should trigger a set of extensions to RFC 1522 to allow language tagging of the free text parts of message headers.
K: IESGは、メッセージヘッダーの自由なテキスト一部の言語タグ付けを許すために1セットの拡大のRFC1522に引き金となるはずです。
8.2: For new Internet protocols
8.2: 新しいインターネットプロトコルのために
New protocols do not suffer from the need to be compatible with old 7-bit pipes. New protocol specifications SHOULD use ISO 10646 as the base charset unless there is an overriding need to use a different base character set.
新しいプロトコルは古い7ビットのパイプと互換性がある必要性に苦しみません。 異なった基本文字を使用する最優先で必要なものがない場合ベースcharsetがセットしたので、新しいプロトコル仕様SHOULDはISO10646を使用します。
New protocols SHOULD use values from the IANA registries when referring to parameter values. The way these values are carried in the protocols is protocol dependent; if the protocol uses RFC-822- like headers, the header names already in use SHOULD be used.
パラメタ値について言及するとき、新しいプロトコルSHOULDはIANA登録から値を使用します。 これらの値がプロトコルで運ばれる方法はプロトコル扶養家族です。 プロトコルがRFC-822同様のヘッダーを使用するなら、ヘッダーは既に使用中でありSHOULDを命名します。使用されます。
For protocols with only a single choice for each component, the protocol should use the most general specification and should be specified with reference to the registered value in the protocol standard.
各コンポーネントのためのただ一つの選択だけがあるプロトコルとして、プロトコルは、最も一般的な仕様を使用するべきであり、プロトコル標準における登録された値に関して指定されるべきです。
Protocols SHOULD tag text streams with the language of the text.
プロトコルSHOULDタグテキストはテキストの言語であふれます。
8.3: For the registration of new character sets
8.3: 新しい文字集合の登録のために
Ned Freed will be releasing a new MIME registration document in conjunction with this paper.
ネッド・フリードはこの紙に関連して新しいMIME登録用書類を発表するでしょう。
8.3.1: A definition table for a coded character set
8.3.1: コード化文字集合のための定義テーブル
A definition table for a coded character set A must for each character C that is in the repertoire of A give:
コード化文字集合AのためのAのレパートリーで以下を与えることである定義テーブルは各キャラクタCのためにそうしなければなりません。
a) if C is present in ISO 10646, the code value (in hexadecimal form)
for that character.
a) CがISO10646、そのキャラクタのためのコード値(16進フォームの)で存在しているなら。
b) If C is not present in ISO 10646, but may be constructed using ISO
10646 combining characters, the series of code values (in
hexadecimal form) used to construct that character.
b) CがISO10646に存在していませんが、ISO10646の結合したキャラクタを使用することで組み立てられるかもしれないなら、コード値(16進フォームの)のシリーズは以前はよくそのキャラクタを構成していました。
c) if C is not present in ISO 10646, a textual description of the
character, and a reference to its origin.
c)はCであるならISO10646、キャラクタの原文の記述、および発生源の参照に存在していません。
Weider, et. al. Informational [Page 18] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [18ページ]情報のRFC2130文字コードワークショップレポート1997年4月
8.3.2: A definition of a character encoding scheme
8.3.2: 文字符号化体系の定義
A definition of a character encoding scheme consists of:
文字符号化体系の定義は以下から成ります。
- A description of an algorithm which transforms every possible
sequence of octets to either a sequence of pairs <CCS, code
value> or to the error state "illegal octet sequence"
- Specifications, either by reference to CCS's registered by IANA or
in text, of each CCS upon which this CES is based.
- 八重奏のあらゆる可能な系列をこのCESが基づいている各CCSコード値>かCCSのものへのどちらか参照による「不法な八重奏系列」--仕様がIANAで示した誤り状態かテキストの組<CCSの系列に変えるアルゴリズムの記述。
Weider, et. al. Informational [Page 19] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [19ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Appendix A:
付録A:
A-1: IETF Protocols
A-1: IETFプロトコル
The following list describes how various existing protocols handle multiple character set information.
以下のリストは様々な既存のプロトコルがどう複数の文字集合情報を扱うかを説明します。
メール
SMTP
See 8.2. ESMTP makes it easy to negotiate the use of alternate
language and encoding if it is needed.
Headers
RFC 1522 forms an adequate framework for supporting text; UTF-8
alone is not a possible solution, because the mail pathways are
assumed to be 7-bit 'forever'. However, RFC 1522 should be
extended to allow language tagging of the free text parts of
message headers.
Bodies
Selection of charset parameters for Email text bodies is
reasonably well covered by the charset= parameter on Text/* MIME
types. Language is defined by the Content-language header of
RFC 1766. Other information will have to be added using body
part headers; due to the way MIME differentiates between body
part headers and message headers, these will all have to have
names starting with Content- .
SMTPは8.2を見ます。 ESMTPはそれが必要であるなら代替の言語とコード化の使用を交渉するのを簡単にします。 RFC1522がテキストをサポートしながら適切なフレームワークを形成するヘッダー。 メール小道が'いつまでも'のときに7ビットであると思われるので、唯一のUTF-8は可能なソリューションではありません。 しかしながら、RFC1522は、メッセージヘッダーの自由なテキスト一部の言語タグ付けを許すために広げられるべきです。 メールテキスト本文のためのcharsetパラメタのボディーSelectionはText/*MIMEの種類でcharset=パラメタで合理的によくカバーされています。 言語はRFC1766のContent-言語ヘッダーによって定義されます。 他の情報はボディー部分ヘッダーを使用することで加えられなければならないでしょう。 MIMEがボディー部分ヘッダーとメッセージヘッダーを区別する方法のため、これらですべて、Contentから始まって、名前を持つでしょう。
NetNews
ネットニュース
NNTP
See 8.2. No strong tradition for negotiation of encoding in NNTP
exists.
NetNews Messages
These should be able to leverage off the mechanisms defined for
Email. One difference is that nearly all NNTP channels are 8-
bit clean; some NNTP newsgroups have a tradition of using 8-bit
charsets in both headers and bodies. Defining character set
default on a per newsgroup basis might be a suitable approach.
NNTPは8.2を見ます。 NNTPでのコード化の交渉のための強い伝統は全く存在していません。 ネットニュースMessages Theseはメールのために定義されたメカニズムで力を入れるはずであることができます。 1つの違いはほとんどすべてのNNTPチャンネルが8ビット清潔であるということです。 NNTPニュースグループの中にはヘッダーとボディーの両方で8ビットのcharsetsを使用する伝統を持っているものもあります。 ニュースグループ基礎あたりのaで文字集合デフォルトを定義するのは、適当なアプローチであるかもしれません。
RTCP
The identifiers carried as information about parties are already
defined to be in UTF-8.
識別子がパーティーの情報として運んだRTCPは、UTF-8にあるように既に定義されます。
Weider, et. al. Informational [Page 20] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [20ページ]情報のRFC2130文字コードワークショップレポート1997年4月
FTP
Protocol
See 8.2. The common use of welcome banners in the login response
means that there might be strong reason here to allow client and
server to negotiate a language different from the default for
greetings and error messages. This should be a simple protocol
extension.
Filenames
Many fileservers now how have the capability of using non-ASCII
characters in filenames, while the "dir" and "get" commands of
are defined in terms of US-ASCII only. One possible solution
would be to define a "UTF-8" mode for the transfer of filenames
and directory information; this would need to be a negotiated
facility, with fallback to US-ASCII if not negotiated. The
important point here is consistency between all implementations;
a single charset is better here than the ability to handle
multiple charsets.
FTPプロトコルは8.2を見ます。 ログイン応答における歓迎されたバナーの一般の使用は、クライアントとサーバが挨拶とエラーメッセージにおいて、デフォルトと異なった言語を交渉するのを許容する強い理由がここにあるかもしれないことを意味します。 これは簡単なプロトコル拡大であるべきです。 ファイル名Many fileservers、今、どのようにがファイル名に非ASCII文字を使用する能力を持って、"dir"をゆったり過ごして、コマンドを「得るか」、米国-ASCIIだけで、定義されます。 1つの可能なソリューションは「ファイル名とディレクトリ情報の転送のためのUTF-8インチのモード」を定義するだろうことです。 交渉されないなら、これは、米国-ASCIIへの後退の交渉された能力である必要があるでしょう。 ここの重要なポイントはすべての実装の間の一貫性です。 ここで、単一のcharsetは複数のcharsetsを扱う能力より良いです。
World Wide Web
HTTP
See 8.2. The single-shot stype of HTTP makes negotiation more
complex than it would otherwise be.
HTML
Internationalization of HTML [I18N] seems fairly well covered in
the current "I18N" document. It needs review to see if it needs
more specific details in order to carry application information
apart from the language.
WWW HTTPは8.2を見ます。 HTTPのただ一つのショットstypeは交渉をそうでなければ、それがあるだろうより複雑にします。 HTML[I18N]のHTML Internationalizationは、"I18N"という現在のドキュメントで公正によくカバーされるように思えます。 それは、それが言語は別としてアプリケーション情報を運ぶために、より特定の詳細を必要とするかどうか確認するためにレビューを必要とします。
URLs
URLs are "input identifiers", and powerful arguments should be
made if they are ever to be anything but US-ASCII.
URL URLは「入力識別子」です、そして、かつて決して米国のASCIIでないつもりであるなら強力な議論をするべきです。
IMAP
IMAP's information objects are MIME Email objects, and therefore
are able to use that standard's methods. However, IMAP folder
names are local identifiers; there is strong reason to allow
non-ASCII characters in these. A UTF-8 negotiation might be the
most appropriate thing, however, UTF-8 is awkward to use.
Unfortunately, UTF-7 isn't suitable because it conflicts with
popular hierarchy delimiters. The most recent IMAP work in
progress specification describes a modified UTF-7 which avoids
this problem.
IMAP IMAPの情報オブジェクトは、MIMEメールオブジェクトであり、したがって、その規格のメソッドを使用できます。 しかしながら、IMAPフォルダー名はローカルの識別子です。 これらに非ASCII文字を許容する強い理由があります。 UTF-8交渉が最も適切なものであるかもしれない、しかしながら、UTF-8は、使用するためにまずいです。 残念ながら、ポピュラーな階層構造デリミタと衝突するので、UTF-7は適当ではありません。 最新のIMAP処理中の作業仕様はこの問題を避ける変更されたUTF-7について説明します。
Weider, et. al. Informational [Page 21] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [21ページ]情報のRFC2130文字コードワークショップレポート1997年4月
DNS
DNS names are the prime example of identifiers that need to stay
in US-ASCII for global interoperability. However, some DNS
information, in particular TXT records, may represent
information (such as names) that is outside the ASCII range. A
single solution is the best; problems resulting from UTF-8
should be investigated.
DNS DNS名はグローバルな相互運用性のための米国-ASCIIで滞在する必要がある識別子に関する主要例です。 しかしながら、何らかのDNS情報(特にTXT記録)がASCII範囲の外にある情報(名前などの)を表すかもしれません。 ただ一つのソリューションは最も良いです。 UTF-8から生じることにおける問題は調査されるべきです。
WHOIS++
WHOIS++ version 1 is defined to use ISO 8859-1. The next version
will use UTF-8. The currently designed changes will also allow
the specification of individual attributes on attribute names;
these will make the passing of application information about the
values (such as language) easier. No immediate action seems
necessary.
WHOIS++WHOIS++バージョン1は、ISO8859-1を使用するために定義されます。 次のバージョンはUTF-8を使用するでしょう。 また、現在設計された変化は属性名の個々の属性の仕様を許容するでしょう。 これらで、値(言語などの)に関するアプリケーション情報の通過は、より簡単になるでしょう。 即座の行動は全く必要に見えません。
WHOIS
This has been a stable protocol for so many years now that it
seems unwise to suggest that it be modified. Furthermore,
compatible extensions exist in RWHOIS and WHOIS++; modification
should rather be made to these protocols than to the WHOIS
protocol itself.
それが変更されるのを示すのが賢明でなく思えるので、あまりに何年間もWHOIS Thisは安定したプロトコルです。 その上、コンパチブル拡大はRWHOISとWHOIS++に存在しています。 WHOISプロトコル自体よりむしろ変更をこれらのプロトコルにするべきです。
Telnet
This is a prime example of protocol where character set support
is necessary and nonexistent. The current work in progress on
character set negotiation in Telnet seems adequate to the task;
the question of passing other application data that might be
useful is still open.
telnet Thisは文字集合サポートが必要であって、実在しないプロトコルに関する主要例です。 Telnetでの文字集合交渉の進行中の執筆中の作品はタスクに適切に見えます。 他のアプリケーションデータを通過する役に立つかもしれない問題はまだ未解決です。
A-2: Non-IETF protocols
A-2: 非IETFプロトコル
For these protocols, the IETF does not have any power to change them. However, the guidelines developed by the workshop may still be useful as input to the further development of the protocols.
これらのプロトコルのために、IETFには、それらを変える少しのパワーもありません。 しかしながら、ワークショップで開発されたガイドラインはプロトコルのさらなる開発に入力されるようにまだ役に立っているかもしれません。
Gopher: Gopher, Gopher+
ゴーファー: ゴーファー、ゴーファー+
Prospero (Archie)
プロスペロー(アーチー)
NFS: Filesystem
NFS: ファイルシステム
CORBA, Finger, GEDI, IRC, ISO 10160/1, Kerberos, LPR, RSTAT, RWhois, SGML, TFTP, X11, X.500, Z39.50
CORBA、指、GEDI、IRC、ISO10160/1、ケルベロス、LPR、RSTAT、RWhois、SGML、TFTP、X11、X.500、Z39.50
Weider, et. al. Informational [Page 22] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [22ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Appendix B: Acronyms
付録B: 頭文字語
ASCII American National Standard Code for Information Character
Sets
CCS Coded Character Sets
CEN ENV European Committee for Standardisation (CEN) European
pre-standard (ENV)
CES Character Encoding Scheme
CJK Chinese Japanese Korean
CORBA Common Object Request Broker Architecture
CTE Content Transfer Encoding
DNS Domain Name Service
ESMTP Extended SMTP
FTP File Transfer Protocol
HTML Hypertext Transfer Protocol
I18N Internationalization (or 18 characters between the first
(I) and last (n)character)
IAB Internet Activities Board
IANA Internet Assigned Numbers Authority
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IMAP Internet Message Access Protocol
IRC Internet Relay Chat
IRTF Internet Research Task Force
ISI Information Sciences Institute
ISO International Standards Organization
MIME Multipurpose Internet Mail Extensions
NFS Networked File Server
NNTP Net News Transfer Protocol
POSIX Portable Operating System Interface
RFC Request for Comments (Internet standards documents)
RPC Remote Procedure Call
RSTAT Remote Statistics
RTCP Real-Time Transport Control Protocol
Rwhois Referral Whois
SGML Standard Generalized Mark-up Language
SMTP Simple Mail Transfer Protocol
TES Transfer Encoding Syntax
TFTP Trivial File Transfer Protocol
URL Uniform Resource Locator
UTF Universal Text/Translation Format
ヨーロッパのプレ標準の中国の日本の韓国のStandardisation(CEN)のプロトコルHTMLハイパーテキストTransferプロトコル(ENV)CESキャラクターEncoding Scheme CJK CORBA共通オブジェクト・リクエスト・ブローカー・アーキテクチャCTE Content Transfer Encoding DNS Domain Name Service ESMTP Extended SMTP FTP File Transfer I18N Internationalization(または、最初の(I)と最後の(n)キャラクタの間の18のキャラクタ)IABのための情報文字コードCCS Coded文字コードCEN ENVヨーロッパ人CommitteeのためのASCII米国標準規格Code; CommentsのためのインターネットActivities Board IANAインターネットAssigned民数記Authority IESGインターネットEngineering Steering Group IETFインターネット・エンジニアリング・タスク・フォースIMAPインターネットMessage AccessプロトコルIRCインターネットRelay Chat IRTFインターネットResearch Task Force ISI情報Sciences Institute国際標準化機構国際規格Organization MIMEマルチパーパスインターネットメールエクステンションNFS Networked File Server NNTPネットNews TransferプロトコルPOSIX Portable Operating System Interface RFC Request、(インターネット標準documents) RPC Remote Procedure Call RSTAT Remote Statistics RTCPレアル-時間Transport ControlプロトコルRwhois Referral Whois SGML Standard Generalizedマーク上がっているLanguage SMTPのシンプルメールトランスファプロトコルTES Transfer Encoding Syntax TFTPトリビアル・ファイル転送プロトコルURL Uniform Resource Locator UTF Universal Text/翻訳Format
Weider, et. al. Informational [Page 23] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [23ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Appendix C: Glossary
付録C: 用語集
Bi-directionality - A property of some text where text written right-
to- left (Arabic or Hebrew) and text written left-to-right
(e.g. Latin) are intermixed in one and the same line.
双方向性--、書かれたテキストがまっすぐになる何らかのテキストの特性、-、全く同じ系列で左(アラビアの、または、ヘブライの)と左から右に書かれたテキスト(例えば、ラテン語)を混ぜます。
Character - A single graphic symbol represented by sequence of one or
more bytes.
キャラクター--1バイト以上の系列によって表されたただ一つの図形。
Character Encoding Scheme - The mapping from a coded character set to
an encoding which may be more suitable for specific purpose. For
example, UTF-8 is a character encoding scheme for ISO 10646.
キャラクターEncoding Scheme--コード化文字集合から明確な目標により適するかもしれないコード化までのマッピング。 例えば、UTF-8はISO10646が文字符号化体系です。
Character Set - An enumerated group of symbols (e.g., letters, numbers
or glyphs)
文字コード--シンボルの列挙されたグループ(例えば、手紙、数またはglyphs)
Coded Character Set - The mapping from a set of integers to the
characters of a character set.
コード化された文字コード--1セットの整数から文字集合のキャラクタまでのマッピング。
Culture - Preferences in the display of text based on cultural norms,
such as spelling and word choice.
文化--テキストのディスプレイにおける好みはスペルや単語選択などの文化的な標準を基礎づけました。
Language - The words and combinations of words the constitute a system
of expression and communication among people with a shared
history or set of traditions.
言語--、単語の単語と組み合わせ、人々で伝統の共有する歴史かセットで式とコミュニケーションのシステムを構成してください。
Layout - Information needed to display text to the user, similar to
the presentation layer in the ISO telecommunications model.
レイアウト--情報は、ISOテレコミュニケーションモデルのプレゼンテーション層と同様のユーザにテキストを表示する必要がありました。
Locale - The attributes of communication, such as language, character
set and cultural conventions.
現場--コミュニケーションの言語や、文字集合や文化的なコンベンションなどの属性。
On-the-wire - The data that actually gets put into packets for
transmission to other computers.
ワイヤ、--他のコンピュータへの伝送のため実際にパケットに入れられるデータ。
Transfer Encoding Syntax - The mapping from a coded character set
which has been encoded in a Character Encoding Scheme to an
encoding which may be more suitable for transmission using
specific protocols. For example, Base64 is a transfer encoding
syntax.
Encoding Syntaxを移してください--キャラクターEncoding Schemeでコード化されたコード化文字集合から特定のプロトコルを使用することでトランスミッションにより適するかもしれないコード化までのマッピング。 例えば、Base64は構文をコード化する転送です。
Weider, et. al. Informational [Page 24] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [24ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Appendix D: References
付録D: 参照
[*] Non-ASCII character
[*] 非ASCII文字
[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)をコード化します」。
[Base64] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[Base64]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[CEN] see http://tobbi.iti.is/TC304/welcome.html for current status.
[CEN]は現在の状態に http://tobbi.iti.is/TC304/welcome.html を見ます。
[HTML] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
[HTML] バーナーズ・リー、T.、およびD.コノリー、「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ--11月。」
[HTTP] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[HTTP] バーナーズ・リー、T.、フィールディング、R.、およびH.ニールセン、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[I18N] Yergeau, F., et.al., "Internationalization of the Hypertext
Markup Language", RFC 2070, January 1997.
[I18N] Yergeau、F.、et.al、「ハイパーテキストマークアップランゲージの国際化」、RFC2070、1月1997日
[IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, ISI, October 1994.
[IANA] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、ISI、1994年10月。
[ISO-2022] ISO/IEC 2022:1994, "Information technology -- Character
Code Structure and Extension Techniques", JTC1/SC2.
[ISO-2022]ISO/IEC、2022:1994、「情報技術--、キャラクターCode StructureとExtension Techniques、」、JTC1/SC2。
[ISO-7498] ISO/IEC 7498-1:1994, "Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model".
[ISO-7498]ISO/IEC7498-1:1994、「情報技術(オープン・システム・インターコネクション)の基本的なReference Model:」 「基本型。」
[ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic
Character Sets -- Part 1: Latin Alphabet no. 1,
ISO 8859-1:1987(E). Part 2: Latin Alphabet no. 2, ISO 8859-2
1987(E). Part 3: Latin Alphabet no. 3, ISO 8859-3:1988(E).
Part 4: Latin Alphabet no. 4, ISO 8859-4, 1988(E). Part 5:
Latin/Cyrillic Alphabet ISO 8859-5, 1988(E). Part 6:
Latin/Arabic Alphabet, ISO 8859-6, 1987(E). Part 7: Latin/Greek
Alphabet, ISO 8859-7, 1987(E). Part 8: Latin/Hebrew Alphabet, ISO
8859-8-1988(E).Part 9: Latin Alphabet no. 5, ISO 8859-9, 1990(E).
Part 10: Latin Alphabet no. 6, ISO 8859-10:1992(E).
[ISO-8859]情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1 ISO8859-1: 1987(E)。 第2部: ローマ字No.2 ISO8859-2 1987(E)。 パート3: ローマ字No.3 ISO8859-3: 1988(E)。 パート4: ローマ字No.4 ISO8859-4、1988(E)。 パート5: ラテン/キリル文字ISO8859-5、1988(E)。 パート6: ラテン語の、または、アラビアのアルファベット、ISO8859-6、1987(E)。 パート7: ラテン語の、または、ギリシアのアルファベット、ISO8859-7、1987(E)。 パート8: ラテン語の、または、ヘブライのアルファベット、ISO8859-8-1988(E).Part9: ローマ字No.5 ISO8859-9、1990(E)。 パート10: ローマ字No.6 ISO8859-10: 1992(E)。
[ISO-10646] ISO/IEC 10646-1:1993(E ), "Information technology --
Universal Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane". JTC1/SC2, 1993
[ISO-10646]ISO/IEC10646-1: 1993(E )、「情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部:、」 「アーキテクチャと基本多言語水準。」 JTC1/SC2、1993
Weider, et. al. Informational [Page 25] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [25ページ]情報のRFC2130文字コードワークショップレポート1997年4月
[MIME] See [Base64]
[まねます] 見てください。[Base64]
[POSIX] Institute of Electrical and Electronics Engineers. "IEEE
standard interpretations for IEEE standard portable operating
systems interface for computer environments". IEEE Std 1003.1
-1988/Int, 1992 edition. Sponsor, Technical Committee on Operating
Systems of the IEEE Computer Society. New York, NY: Institute of
Electrical and Electronic Engineers, 1992.
[POSIX]米国電気電子技術者学会。 「IEEEの標準の携帯用のオペレーティングシステムのためのIEEEの標準の解釈はコンピュータ環境のために連結します。」 IEEE Std1003.1 -1988/Int、1992年の版。 スポンサー、IEEEコンピュータ社会のオペレーティングシステムの専門委員会。 ニューヨーク(ニューヨーク): 電気電子学会、1992。
RFC 1340 See [IANA]
RFC1340は見ます。[IANA]
[RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets",
RFC 1345, Rationel Alim Planlaegning, June 1992.
[RFC-1345] シモンセン、K.、「キャラクターニーモニックと文字コード」、RFC1345、Rationel Alim Planlaegning、1992年6月。
[RFC-1554] Ohta, M., and K. Handa, "ISO-2022-JP-2: Multilingual
Extension of ISO-2022-JP", Tokyo Institute of Technology, ETL,
December 1993.
[RFC-1554] 太田、M.、およびK.半田、「ISO2022JP2:」 「ISO2022JPの多言語拡大」、東京工業大学、ETL、1993年12月。
RFC 1642 See [UTF-7]
RFC1642は見ます。[UTF-7]
[RFC-1766] Alvestrad, H., "Tags for the Identification of Languages",
RFC 1766, UNINETT, March 1995.
[RFC-1766]Alvestrad、H.、「言語の識別のためのタグ」、RFC1766、UNINETT、1995年3月。
[RFC 1958] Carpenter, B. (ed.) "Architectural Principles of the
Internet", RFC 1958, IAB, June 1996.
B.編、[RFC1958]は大工仕事をします。 「インターネットの建築プリンシプルズ」、RFC1958、IAB、1996年6月。
[SGML] ISO 8879:1986 "Information Processing - Text and Office Systems
- Standard Generalized Markup Language (SGML)"
[SGML]ISO8879: 1986「情報処理(テキストとオフィス・システム)マークアップ言語(SGML)」
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August, 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[Unicode] "The Unicode standard, version 2.0. Unicode Consortium.
Reading, Mass.: Addison-Wesley Developers Press, 1996
[ユニコード] 「ユニコード規格、バージョン2.0。」 ユニコード共同体。 読書、マサチューセッツ州: アディソン-ウエスリー開発者プレス、1996
[UTF-7] Goldsmith, D., and M. Davis, "UTF-7: A Mail Safe
Transformation Format of Unicode", RFC 1642, Taligent, Inc., July
1994.
[UTF-7] ゴールドスミス、D.、およびM.デイヴィス、「UTF-7:」 「ユニコードのメールの安全な変換形式」、RFC1642、Taligent Inc.、1994年7月。
[UTF-8] International Standards Organization, Joint Technical
Committee 1 (ISO/JTC1), "Amendment 2:1993, UCS Transformation
Format 8 (UTF-8)", in ISO/IEC 10646-1:1993 Information technology
- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane. JTC1/SC2, 1993.
[UTF-8]国際Standards Organization、Joint Technical Committee1(ISO/JTC1)、「修正、2:1993、UCS変換形式8(UTF-8)、」、ISO/IEC10646-1: 1993年の情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部で: アーキテクチャと基本多言語水準。 JTC1/SC2、1993。
Weider, et. al. Informational [Page 26] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [26ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Appendix E: Recommended reading
付録E: お勧めの読書
Alvestrand, H., "Tags for the Identification of Languages", RFC 1766,
UNINETT, March 1995.
Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、UNINETT、1995年3月。
Alvestrand, H., "X.400 Use of Extended Character Sets", RFC 1502,
SINTEF DELAB, August 1993.
Alvestrand、H.、「拡張文字集合のX.400使用」、RFC1502、SINTEF DELAB、1993年8月。
Borenstein, N., "Implications of MIME for Internet Mail Gateways",
RFC 1344, Bellcore, June 1992.
Borenstein、N.、「インターネットメール・ゲートウェイへのMIMEの含意」、RFC1344、Bellcore、1992年6月。
Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
N.、およびN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Chernov, A., "Registration of a Cyrillic Character Set", RFC 1489,
RELCOM Development Team, July 1993.
チェルノフ、A.、「キリル文字の文字コードの登録」、RFC1489、RELCOM開発チーム、1993年7月。
Choi, U., and K. Chan, "Korean Character Encoding for Internet
Messages", RFC 1557, KAIST, December 1993.
チェ、U.、およびK.チェン、「インターネットメッセージのための韓国の文字符号化」、RFC1557、KAIST、1993年12月。
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, November 1996.
N.、およびN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Goldsmith, D., and M. Davis, "Transformation Format for Unicode",
RFC 1642, Taligent, Inc., July 1994.
ゴールドスミス、D.、およびM.デイヴィス、「ユニコードのための変換形式」、RFC1642、Taligent Inc.、1994年7月。
Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641,
Taligent, Inc., July 1994.
ゴールドスミス、D.、およびM.デイヴィス、「MIMEがあるユニコードを使用します」、RFC1641、Taligent Inc.、1994年7月。
Jerman-Blazic, B. "Character handling in computer communication" in
"user needs in information technology standards", Computer Weekly
Professional service, eds. C.D. Evans, B.L. Meed & R.S. Walker,
P.C. Butterworth Heineman, 1993, Oxford, Boston, p. 102-129.
B. Jerman-Blazic、「情報技術規格におけるユーザの必要性」、コンピュータWeekly Professionalサービス、edsの「コンピュータコミュニケーションにおけるキャラクター取り扱い。」 C.D.エヴァンスとB.L.MeedとR.S.ウォーカー、バターワースHeineman、1993、C.オックスフォード、P.ボストンp。 102-129.
Jerman-Blazic, B. "Tool supporting the internationalization of the
generic network services", Computer Networks and ISDN Systems,
No. 27 (1994), p. 429-435.
Jerman-BlazicとB. 「ジェネリックネットワーク・サービスの国際化をサポートするツール」とコンピュータNetworksとISDN Systems、No.(1994)、27p。 429-435.
Jerman-Blazic, B., A. Gogala and D. Gabrijelcic, "Transparent language
processing: A solution for internationalization of Internet
services", The LISA Forum Newsletter, 5 (1996) p. 12-21
Jerman-BlazicとB.とA.GogalaとD.Gabrijelcic、「以下を処理する見え透いた言語」 「インターネットのサービスの国際化のためのソリューション」、リサForumニュースレター、5(1996)p。 12-21
Lee, F., "HZ - A Data Format for Exchanging Files of Arbitrarily Mixed
Chinese and ASCII Characters", RFC 1843, Stanford University,
August 1995.
リー、F.、「HZ--交換のためのデータの形式は任意に複雑な中国語とASCIIキャラクターをファイルします」、RFC1843、スタンフォード大学、1995年8月。
Weider, et. al. Informational [Page 27] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [27ページ]情報のRFC2130文字コードワークショップレポート1997年4月
McCarthy, J., "Arbitrary Character Sets", RFC 373, Stanford
University, July 1972.
マッカーシー、J.、「気紛れな質セット」、RFC373、スタンフォード大学、1972年7月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two:
Message Header Extensions for Non-ASCII Text", RFC 1522,
September 1993. (Obsoleted by RFC 2047.)
ムーア、K.、「パートTwoをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC1522、1993年9月。 (RFC2047によって時代遅れにされます。)
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text", RFC 2047,
University of Tennessee, November 1996.
ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、テネシー大学、1996年11月。
Murai, J., Crispin, M., and E. von der Poel. "Japanese Character
Encoding for Internet Messages", RFC 1468, Keio University &
Panda Programming, June 1993.
村井、J.、クリスピン、M.、およびE.フォン・derポール。 「インターネットメッセージのための日本の文字符号化」とRFC1468と慶応義塾大学とパンダプログラミング、1993年6月。
Nussbacher, H., "Handling of Bi-directional Texts in MIME", Israeli
Inter-University, December 1993.
Nussbacher、H.、「MIMEにおける双方向のテキストの取り扱い」、イスラエルの相互大学、1993年12月。
Nussbacher, H., and Y. Bourvine, "Hebrew Character Encoding for
Internet Messages", RFC 1555, Israeli Inter-University and
Hebrew University, December 1993.
NussbacherとH.とY.Bourvineと「インターネットメッセージのためのヘブライの文字符号化」とRFC1555とイスラエルの相互大学とヘブライの大学、1993年12月。
Ohta, M., "Character Sets ISO-10646 and ISO-10646-J-1", RFC 1815,
Tokyo Institute of Technology, July 1995.
太田とM.と「文字コードISO-10646とISO-10646-J-1インチ、RFC1815、東京工業大学、1995年7月。」
Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9,
RFC 959, ISI, October 1985.
ポステル、J.、およびJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、ISI、1985年10月。
Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 8,
RFC 854, ISI, May 1983.
ポステル(J.、およびJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、ISI)は、1983がそうするかもしれません。
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
ISI, October 1994. p.100-117.
レイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700、ISI、10月1994日のp.100-117。
Rose, M., "The Internet Message", Prentice Hall, 1992.
ローズ、M.、「インターネットメッセージ」、新米のホール、1992。
Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345,
Rationel Almen Planlaegning, June 1992.
シモンセン、K.、「キャラクターニーモニックと文字コード」、RFC1345、Rationel Almen Planlaegning、1992年6月。
Unicode Consortium. "The Unicode standard, version 2.0. Reading,
Mass.: Addison-Wesley Developers Press, 1996
ユニコード共同体。 「ユニコード規格、バージョン2.0。」 読書、マサチューセッツ州: アディソン-ウエスリー開発者プレス、1996
Wei, U., et.al. "ASCII Printable Characters-Based Chinese Character
Encoding for Internet Messages", RFC 1842, AsiInfo Services,
Inc., et.al. August 1995.
ウェイ、U.、et.al。 「インターネットMessagesのためのASCII Printableベースのキャラクター漢字Encoding」、RFC1842、AsiInfo Services Inc.、et.al。 1995年8月。
Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646",
RFC 2044, ALIS Technologies, October 1996.
Yergeau、F.、「UTF-8、ユニコードとISO10646インチ、RFC2044年の変換形式、ALIS Technologies、10月1996日
Weider, et. al. Informational [Page 28] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [28ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Zhu, H., et.al., "Chinese Character Encoding for Internet Messages",
RFC 1922, Tsinghua University, et.al., March 1996.
et.al朱、H.、RFC1922、Tsinghua大学、「漢字はメッセージをインターネットにコード化すること」でのet.al、3月1996日
Appendix F: Workshop attendee list
付録F: ワークショップ出席者リスト
These people were participants on the workshop mailing list. An * indicates that the person attended the workshop in person.
これらの人々はワークショップメーリングリストの関係者でした。 *は、人が自分でワークショップに出席したのを示します。
Glenn Adams <glenn@spyglass.com>
* Joan Aliprand <joan@unicode.org>
* Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
* Ran Atkinson <ran@cisco.com>
* Bert Bos <bert@w3.org>
* Brian Carpenter <brian@dxcoms.cern.ch>
* Mark Crispin <mrc@panda.com>
Makx Dekkers <dekkers@pica.nl>
Robert Elz <kre@munnari.oz.au>
Patrik Faltstrom <paf@paf.se>
* Zhu Haifeng <zhf@net.tsinghua.edu.cn>
Keniichi Handa<handa@etl.go.jp>
Olle Jarnefors <ojarnef@admin.kth.se>
Borka Jerman-Blazic <borka@e5.ijs.si>
John Klensin <klensin@mail1.reston.mci.net>
* Larry Masinter <masinter@parc.xerox.com>
* Rick McGowan <Rick_McGowan@next.com>
* Keith Moore <moore+charsets@cs.utk.edu>
* Lisa Moore <lisam@vnet.ibm.com>
Ruth Moulton <ruth@muswell.demon.co.uk>
* Cecilia Preston <cecilia@well.com>
* Joyce K. Reynolds <jkrey@isi.edu>
* Keld Simonsen <keld@dkuug.dk>
* Gary Smith <Gary_Smith@oclc.org>
* Peter Svanberg <psv@nada.kth.se>
* Chris Weider <cweider@microsoft.com >
ijs.si>ジョン Klensin <klensin@mail1.reston.mci.net 、gt;、*ラリー Masinter <masinter@parc.xerox.com 、gt;、*リックマガウアン<リック_マガウアン@next.com>*キースムーア<moore+ charsets@cs.utk.edu 、gt;、*リサ Moore <lisam@vnet.ibm.com 、gt;、ルース Moulton <ruth@muswell
Weider, et. al. Informational [Page 29] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [29ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Appendix G: Authors' Addresses
付録G: 作者のアドレス
Chris Weider Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
クリスワイダーMicrosoft Corp.1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: cweider@microsoft.com
メール: cweider@microsoft.com
Cecilia Preston Preston & Lynch PO Box 8310 Emeryville, CA 94662 USA
シシリア・プレストンプレストンとリンチPO Box8310カリフォルニア94662エマリービル(米国)
EMail: cecilia@well.com
メール: cecilia@well.com
Keld Simonsen DKUUG Freubjergvey 3 DK-2100 Kxbenhavn X Danmark
KeldシモンセンDKUUG Freubjergvey3DK-2100 Kxbenhavn Xデンマーク
EMail: Keld@dkuug.dk
メール: Keld@dkuug.dk
Harald T. Alvestrand UNINETT P.O.Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY
ハラルドT.Alvestrand UNINETT私書箱6883Elgeseter N-7002トロンヘイムノルウェー
EMail: Harald.T.Alvestrand@uninett.no
メール: Harald.T.Alvestrand@uninett.no
Randall Atkinson cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA
ランドルアトキンソンコクチマスSystems170の西タスマン・Driveカリフォルニア95134-1706サンノゼ(米国)
EMail: rja@cisco.com
メール: rja@cisco.com
Weider, et. al. Informational [Page 30] RFC 2130 Character Set Workshop Report April 1997
etワイダー、アル。 [30ページ]情報のRFC2130文字コードワークショップレポート1997年4月
Mark Crispin Networks & Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527 USA
第15マーククリスピンネットワークと分散コンピューティングワシントン大学4545アベニューNEワシントン98105-4527シアトル(米国)
EMail: mrc@cac.washington.edu
メール: mrc@cac.washington.edu
Peter Svanberg Dept. of Numberical Analysis and Computing Science (Nada) Royal Institute of Technology SE-100 44 STOCKHOLM SWEDEN
Numberical分析と電子計算学(Nada)のロイヤル工科大学SE-100 44ストックホルムスウェーデンのピータースバンベルク部
EMail: psv@nada.kth.se
メール: psv@nada.kth.se
Weider, et. al. Informational [Page 31]
etワイダー、アル。 情報[31ページ]
一覧
スポンサーリンク
