RFC3536 日本語訳
3536 Terminology Used in Internationalization in the IETF. P. Hoffman. May 2003. (Format: TXT=64284 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Hoffman Request for Comments: 3536 IMC & VPNC Category: Informational May 2003
コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 3536年のIMC&VPNCカテゴリ: 情報の2003年5月
Terminology Used in Internationalization in the IETF
IETFでの国際化に使用される用語
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
このドキュメントは国際化について議論するときIETFで使用される用語の用語集を提供します。 目的は、IETFの様々な領域での国際化のフレーム議論を助けて、IETF関係者に主な概念を紹介するのを助けることです。
Table of Contents
目次
1. Introduction................................................... 2
1.1 Purpose of this document.................................... 2
1.2 Format of the definitions in this document.................. 3
2. Fundamental Terms.............................................. 3
3. Standards Bodies and Standards................................. 8
3.1 Standards bodies............................................ 8
3.2 Encodings and transformation formats of ISO/IEC 10646....... 10
3.3 Native CCSs and charsets.................................... 11
4. Character Issues............................................... 12
4.1 Types of characters......................................... 15
5. User interface for text........................................ 17
6. Text in current IETF protocols................................. 19
7. Other Common Terms In Internationalization..................... 22
8. Security Considerations........................................ 25
9. References..................................................... 25
9.1 Normative References........................................ 25
9.2 Informative References...................................... 26
10. Additional Interesting Reading................................ 27
11. Index......................................................... 27
A. Acknowledgements............................................... 29
B. Author's Address............................................... 29
Full Copyright Statement.......................................... 30
1. 序論… 2 1.1 このドキュメントの目的… 2 1.2 このドキュメントの定義の形式… 3 2. 基本項… 3 3. 標準化団体と規格… 8 3.1の標準化団体… 8 3.2 ISO/IEC10646のEncodingsと変化形式… 10 3.3 ネイティブのCCSsとcharsets… 11 4. キャラクター問題… 12 4.1のタイプのキャラクタ… 15 5. テキストのためのユーザーインタフェース… 17 6. 現在のIETFプロトコルのテキスト… 19 7. 国際化における他の一般的な用語… 22 8. セキュリティ問題… 25 9. 参照… 25 9.1 標準の参照… 25 9.2 有益な参照… 26 10. 追加おもしろい読書… 27 11. 索引をつけてください… 27 A.承認… 29B.作者のアドレス… 29 完全な著作権宣言文… 30
Hoffman Informational [Page 1] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[1ページ]のRFC3536Terminology
1. Introduction
1. 序論
As [RFC2277] summarizes: "Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are." Many protocols throughout the IETF use text strings that are entered by, or are visible to, humans. It should be possible for anyone to enter or read these text strings, which means that Internet users must be able to be enter text in typical input methods and displayed in any human language. Further, text containing any character should be able to be passed between Internet applications easily. This is the challenge of internationalization.
[RFC2277]が以下をまとめるので 「国際化は人間のためのものです。」 これは、プロトコルが国際化を被りやすくないことを意味します。 「テキスト文字列はそうです。」 人間、IETF中の多くのプロトコルがそれが入られるか、または目に見えるテキスト文字列を使用します。 だれでもこれらのテキスト文字列を入るか、または読むのが、可能であるべきであり、インターネットユーザがそうすることができなければならないどの手段が典型的にテキストを記録するかは、どんな人間の言語でも方法を入力して、表示しました。 さらに、どんなキャラクタも含むテキストはインターネットアプリケーションの間を容易に通ることができるべきです。 これは国際化の挑戦です。
1.1 Purpose of this document
1.1 このドキュメントの目的
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
このドキュメントは国際化について議論するときIETFで使用される用語の用語集を提供します。 目的は、IETFの様々な領域での国際化のフレーム議論を助けて、IETF関係者に主な概念を紹介するのを助けることです。
Internationalization is discussed in many working groups of the IETF. However, few working groups have internationalization experts. When designing or updating protocols, the question often comes up "should we internationalize this" (or, more likely, "do we have to internationalize this").
IETFの多くのワーキンググループで国際化について議論します。 しかしながら、わずかなワーキンググループにはしか、国際化の専門家がいません。 プロトコルを設計するか、またはアップデートするとき、質問はしばしば「私たちはこれを国際的にするべきであること」を来ます(おそらく、「私たちはこれを国際的にしなければなりません」)。
This document gives an overview of internationalization as it applies to IETF standards work by lightly covering the many aspects of internationalization and the vocabulary associated with those topics. It is not meant to be a complete description of internationalization. The definitions in this document are not normative for IETF standards; however, they are useful and standards may make informative reference to this document after it becomes an RFC. Some of the definitions in this document come from many earlier IETF documents and books.
それが軽く国際化の多くの局面とそれらの話題に関連しているボキャブラリーを含んでいることによってIETF標準化作業に適用されるとき、このドキュメントは国際化の概観を与えます。 それは国際化の完全な記述であることが意味されません。 IETF規格には、定義は本書では規範的ではありません。 しかしながら、それらは役に立ちます、そして、RFCになった後に規格はこのドキュメントの有益な参照をするかもしれません。 定義のいくつかが多くの以前のIETFドキュメントと本から本書では来ます。
As in many fields, there is disagreement in the internationalization community on definitions for many words. The topic of language brings up particularly passionate opinions for experts and non- experts alike. This document attempts to define terms in a way that will be most useful to the IETF audience.
多くの分野のように、不一致が多くの単語のために定義での国際化共同体にあります。 言語の話題は同じく専門家に関する特に激しい意見と非の専門家を育てます。 このドキュメントは、IETF聴衆の最も役に立つ方法で用語を定義するのを試みます。
This document uses definitions from many documents that have been developed outside the IETF. The primary documents used are:
このドキュメントはIETFの外で開発された多くのドキュメントから定義を使用します。 使用される第一のドキュメントは以下の通りです。
- ISO/IEC 10646 [ISOIEC10646]
- ISO/IEC10646[ISOIEC10646]
- The Unicode Standard [UNICODE]
- ユニコード規格[ユニコード]
Hoffman Informational [Page 2] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[2ページ]のRFC3536Terminology
- W3C Character Model [CHARMOD]
- W3Cキャラクターモデル[CHARMOD]
- IETF RFCs, including [RFC2277]
- IETF RFCs、包含[RFC2277]
1.2 Format of the definitions in this document
1.2 このドキュメントの定義の形式
In the body of this document, the source for the definition is shown in angle brackets, such as "<ISOIEC10646>". Many definitions are shown as "<NONE>", which means that the definitions were crafted originally for this document. The angle bracket notation for the source of definitions is different than the square bracket notation used for references to documents, such as in the paragraph above; these references are given in Section 9.
このドキュメントのボディーを、定義のためのソースは「<ISOIEC10646>」などの角ブラケットで見せられます。 多くの定義が示される、「<、>のいずれ、も」でない、定義が元々このドキュメントのために作られたことを意味する。 定義の源への角ブラケット記法はドキュメントの参照に使用される角括弧記法と異なっています、上のパラグラフなどのように。 セクション9でこれらの参照を与えます。
For some terms, there are commentary and examples after the definitions. In those cases, the part before the angle brackets is the definition that comes from the original source, and the part after the angle brackets is commentary that is not a definition (such as examples or further exposition).
いくつかの期間、定義の後に、論評と例があります。 それらの場合では、角ブラケットの前の部分は一次資料から来る定義です、そして、角ブラケットの後の部分は定義(例か一層の博覧会などの)でない論評です。
Examples in this document use the notation for code points and names from the Unicode Standard [UNICODE] and ISO/IEC 10646 [ISOIEC10646]. For example, the letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER A".
例はコード・ポイントと名前にユニコードStandard[ユニコード]とISO/IEC10646[ISOIEC10646]から記法を本書では使用します。 例えば、手紙“a"は「U+0061」か「ラテン語の小文字A」のどちらかとして表されるかもしれません。
2. Fundamental Terms
2. 基本項
This section covers basic topics that are needed for almost anyone who is involved with making IETF protocols more friendly to non-ASCII text and with other aspects of internationalization.
このセクションはほとんどIETFプロトコルを非ASCIIテキストにより好意的にして、国際化の他の局面にかかわる人はだれにも必要である基本的な話題をカバーします。
language
言語
A language is a way that humans interact. The use of language
occurs in many forms, the most common of which are speech,
writing, and signing. <NONE>
言語は人間が相互作用する方法です。 言語の使用は多くのフォームに起こります。その最も一般的なものは、スピーチであり、書いて、サインしています。 <、>のいずれも
Some languages have a close relationship between the written and
spoken forms, while others have a looser relationship. [RFC3066]
discusses languages in more detail and provides identifiers for
languages for use in Internet protocols. Note that computer
languages are explicitly excluded from this definition.
いくつかの言語には、書かれて話されたフォームの間の密接な関係がありますが、他のものは、よりゆるい関係を持っています。 [RFC3066]は、インターネットプロトコルにおける使用にさらに詳細に言語について議論して、言語のための識別子を提供します。 コンピュータ言語がこの定義から明らかに除かれることに注意してください。
script
スクリプト
A set of graphic characters used for the written form of one or
more languages. <ISOIEC10646>
1セットの図形文字は書かれたフォームの1つ以上に言語を使用しました。 <ISOIEC10646>。
Hoffman Informational [Page 3] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[3ページ]のRFC3536Terminology
Examples of scripts are Latin, Cyrillic, Greek, Arabic, and Han
(the ideographs used in writing Chinese, Japanese, and Korean).
[RFC2277] discusses scripts in detail.
スクリプトに関する例は、ラテン語の、そして、キリル文字の、そして、ギリシアのアラビア語と、ハン(中国語、日本語、および韓国語を書く際に使用される表意文字)です。 [RFC2277]は詳細にスクリプトについて議論します。
It is common for internationalization novices to mix up the terms
"language" and "script". This can be a problem in protocols that
differentiate the two. Almost all protocols that are designed (or
were re-designed) to handle non-ASCII text deal with scripts (the
written systems) or characters, while fewer actually deal with
languages.
国際化初心者が用語「言語」と「スクリプト」に混合するのは、一般的です。 これは2を微分するプロトコルの問題であるかもしれません。 ほとんどすべてのプロトコルがスクリプト(書かれたシステム)かキャラクタとの非ASCIIテキスト取引を扱うように設計されていて(または、再設計されました)、実際により少ない間、言語に対処してください。
A single name can mean either a language or a script; for example,
"Arabic" is both the name of a language and the name of a script.
In fact, many scripts borrow their names from the names of
languages. Further, many scripts are used for many languages; for
example, the Russian and Bulgarian languages are written in the
Cyrillic script. Some languages can be expressed using different
scripts; the Mongolian language can be written in either the
Mongolian and Cyrillic scripts, and the Serbo-Croatian language is
written using both the Latin and Cyrillic scripts. Further, some
languages are normally expressed with more than one script at the
same time; for example, the Japanese language is normally
expressed in the Kanji (Han), Katakana, and Hiragana scripts in a
single string of text.
ただ一つの名前は言語かスクリプトのどちらかを意味できます。 例えば、「アラビア語」は言語の名前とスクリプトの名前の両方です。 事実上、多くのスクリプトが言語の名前からそれらの名前を借ります。 さらに、多くのスクリプトが多くの言語に使用されます。 例えば、ロシアの、そして、ブルガリア人の言語はキリル文字のスクリプトで書かれています。 異なったスクリプトを使用することでいくつかの言語を表すことができます。 モンゴルの、そして、キリル文字の文字でモンゴルの言語を書くことができます、そして、セルビア・クロアチア語言語は、両方のラテン語の、そして、キリル文字のスクリプトを使用することで書かれています。 さらに、通常、いくつかの言語が同時に、1つ以上のスクリプトで表されます。 例えば、通常、日本語はテキストの一連のKanji(ハン)、Katakana、およびHiraganaスクリプトで表されます。
character
キャラクタ
A member of a set of elements used for the organization, control,
or representation of data. <ISOIEC10646>
組織に使用される1セットの要素、コントロール、またはデータの表現のメンバー。 <ISOIEC10646>。
There are at least three common definitions of the word
"character":
「キャラクタ」という言葉の少なくとも3つの一般的な定義があります:
- a general description of a text entity
- テキスト実体の概説
- a unit of a writing system, often synonymous with "letter" or
similar terms
- しばしば「手紙」か同類項と同義の書記体系のユニット
- the encoded entity itself
- コード化された実体自体
When people talk about characters, they are mostly using one of
the first two definitions.
人々がキャラクタに関して話すとき、彼らは最初の2つの定義の1つをほとんど使用しています。
A particular character is identified by its name, not by its
shape. A name may suggest a meaning, but the character may be
used for representing other meanings as well. A name may suggest
特定のキャラクタは形によって特定されるのではなく、その名前によって特定されます。 名前は意味を示すかもしれませんが、キャラクタは、また、他の意味を表すのに使用されるかもしれません。 名前は示されるかもしれません。
Hoffman Informational [Page 4] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[4ページ]のRFC3536Terminology
a shape, but that does not imply that only that shape is commonly
used in print, nor that the particular shape is associated only
with that name.
しかし、形、それは、その形だけが一般的に印刷して使用されるのを含意しません、そして、特定の形はその名前だけに関連しています。
coded character
コード化されたキャラクタ
A character together with its coded representation. <ISOIEC10646>
コード値に伴うキャラクタ。 <ISOIEC10646>。
coded character set
コード化文字集合
A coded character set (CCS) is a set of unambiguous rules that
establishes a character set and the relationship between the
characters of the set and their coded representation.
<ISOIEC10646>
コード化文字集合(CCS)は、文字の組を確立する1セットの明白な規則とセットと彼らのコード値の登場人物の相関関係です。 <ISOIEC10646>。
character encoding form
フォームをコード化するキャラクタ
A character encoding form is a mapping from a character set
definition to the actual code units used to represent the data.
<UNICODE>
文字の組定義から実際のデータを表すのに使用されるコード単位までフォームをコード化するキャラクタはマッピングです。 <ユニコード>。
repertoire
レパートリー
The collection of characters included in a character set. Also
called a character repertoire. <UNICODE>
文字の組にキャラクタの収集を含んでいます。 また、キャラクタレパートリーと呼ばれます。 <ユニコード>。
glyph
glyph
A glyph is an abstract form that represents one or more glyph
images. The term "glyph" is often a synonym for glyph image,
which is the actual, concrete image of a glyph representation
having been rasterized or otherwise imaged onto some display
surface. In displaying character data, one or more glyphs may be
selected to depict a particular character. These glyphs are
selected by a rendering engine during composition and layout
processing. <UNICODE>
glyphは1つ以上のglyphイメージを表す抽象的なフォームです。 しばしば"glyph"という用語はglyphイメージのための同義語です。(それは、ラスタライズされるか、または別の方法でいくらかの表示面に像を描かれたglyph表現の実際の、そして、具体的なイメージです)。 キャラクタデータを表示する際に、1glyphsが特定のキャラクタについて表現するのが選択されるかもしれません。 これらのglyphsは構成とレイアウト処理の間、表現エンジンによって選択されます。 <ユニコード>。
glyph code
glyphコード
A glyph code is a numeric code that refers to a glyph. Usually,
the glyphs contained in a font are referenced by their glyph code.
Glyph codes are local to a particular font; that is, a different
font containing the same glyphs may use different codes.
<UNICODE>
glyphコードはglyphについて言及する数字コードです。 通常、字体で含まれたglyphsは彼らのglyphコードによって参照をつけられます。 Glyphコードは特定の字体にローカルです。 すなわち、同じglyphsを含む異なった字体は異なったコードを使用するかもしれません。 <ユニコード>。
Hoffman Informational [Page 5] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[5ページ]のRFC3536Terminology
transcoding
コード変換
Transcoding is the process of converting text data from one
character encoding form to another. Transcoders work only at the
level of character encoding and do not parse the text. Note:
Transcoding may involve one-to-one, many-to-one, one-to-many or
many-to-many mappings. Because some legacy mappings are glyphic,
they may not only be many-to-many, but also discontinuous: thus
XYZ may map to yxz. <CHARMOD>
コード変換はフォームをコード化する1つのキャラクタから別のキャラクタまでテキストデータを変換する過程です。 トランスコーダは、単にキャラクタコード化のレベルで働いて、テキストを分析しません。 以下に注意してください。 コード変換は1〜1、1つへの多く、多くへの1または多くへの多くマッピングにかかわるかもしれません。 しかし、また、いくつかの遺産マッピングがglyphicであるので彼らが多くに多くであるかもしれないだけではない、不連続: したがって、XYZはyxzに写像するかもしれません。 <CHARMOD>。
In this definition, "many-to-one" means a sequence of characters
mapped to a single character. The "many" does not mean
alternative characters that map to the single character.
この定義では、「1つへの多く」は単独のキャラクタに写像されたキャラクタの系列を意味します。 「多く」はどんな意地悪な代替の性格にも単独のキャラクタへのその地図をしません。
character encoding scheme
計画をコード化するキャラクタ
A character encoding scheme (CES) is a character encoding form
plus byte serialization. There are many character encoding
schemes in Unicode, such as UTF-8 and UTF-16. <UNICODE>
計画(CES)をコード化するキャラクタはフォームプラスバイト連載をコード化するキャラクタです。 UTF-8やUTF-16などのユニコードには多くのキャラクタコード化計画があります。 <ユニコード>。
Some CESs are associated with a single CCS; for example, UTF-8
[RFC2279] applies only to ISO/IEC 10646. Other CESs, such as ISO
2022, are associated with many CCSs.
いくつかのCESsが独身のCCSに関連しています。 例えば、UTF-8[RFC2279]はISO/IEC10646だけに適用します。 ISO2022などの他のCESsは多くのCCSsに関連しています。
charset
charset
A charset is a method of mapping a sequence of octets to a
sequence of abstract characters. A charset is, in effect, a
combination of one or more CCSs with a CES. Charset names are
registered by the IANA according to procedures documented in
[RFC2278]. <NONE>
charsetは抽象的なキャラクタの系列に八重奏の系列を写像する方法です。 事実上、charsetはCESへの1CCSsの組み合わせです。 [RFC2278]に記録された手順によると、Charset名はIANAによって登録されます。 <、>のいずれも
Many protocol definitions use the term "character set" in their
descriptions. The terms "charset" or "character encoding scheme"
are strongly preferred over the term "character set" because
"character set" has other definitions in other contexts and this
can be confusing.
多くのプロトコル定義が彼らの記述に「文字の組」という用語を使用します。 「文字の組」が他の文脈に他の定義を持って、これが混乱させられることができるので、"charset"か「計画をコード化するキャラクタ」という用語は「文字の組」という用語より強く都合がよいです。
internationalization
国際化
In the IETF, "internationalization" means to add or improve the
handling of non-ASCII text in a protocol. <NONE>
IETFでは、「国際化」は、プロトコルにおける非ASCIIテキストの取り扱いを加えるか、または改良することを意味します。 <、>のいずれも
Many protocols that handle text only handle one script (often, the
one that contains the letters used in English text), or leave the
question of what character set is used up to local guesswork
テキストを扱う多くのプロトコルが、1つのスクリプト(しばしば英文で使用される手紙を含むもの)を扱うか、またはどんな文字の組がローカルの当て推量まで使用されるかに関する質問を残すだけです。
Hoffman Informational [Page 6] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[6ページ]のRFC3536Terminology
(which leads, of course, to interoperability problems). Adding
non-ASCII text to such a protocol allows the protocol to handle
more scripts, hopefully all of the ones useful in the world.
(もちろん相互運用性問題に導きます。) そのようなプロトコルへの非ASCIIテキストの付加で、プロトコルは、より多くのスクリプト、うまくいけば世界で役に立つもののすべてを扱うことができます。
localization
ローカライズ
The process of adapting an internationalized application platform
or application to a specific cultural environment. In
localization, the same semantics are preserved while the syntax
may be changed. [FRAMEWORK]
国際化しているアプリケーションプラットホームかアプリケーションを特定の文化面での環境に翻案する過程。 ローカライズでは、構文を変えるかもしれませんが、同じ意味論を保存します。 [枠組み]
Localization is the act of tailoring an application for a
different language or script or culture. Some internationalized
applications can handle a wide variety of languages. Typical
users only understand a small number of languages, so the program
must be tailored to interact with users in just the languages they
know.
ローカライズは異なった言語、スクリプトまたは文化のアプリケーションを合わせる行為です。 いくつかの国際化しているアプリケーションがさまざまな言語を処理できます。 典型的なユーザが少ない数の言語を理解しているだけであるので、まさしく彼らが知っている言語でユーザと対話するためにプログラムを仕立てなければなりません。
The major work of localization is translating the user interface
and documentation. Localization involves not only changing the
language interaction, but also other relevant changes such as
display of numbers, dates, currency, and so on. The better
internationalized an application is, the easier it is to localize
it for a particular language and character encoding scheme.
ローカライズの主要な仕事はユーザーインタフェースとドキュメンテーションを翻訳することです。 ローカライズは、言語相互作用だけではなく、数、日付、通貨などの表示などの他の関連変化も変えることを伴います。 アプリケーションが国際化するほうがよければ、それは計画をコード化する特定の言語とキャラクタのためにそれをより局所化しやすいです。
Localization is rarely an IETF matter, and protocols that are
merely localized, even if they are serially localized for several
locations, are generally considered unsatisfactory for the global
Internet.
めったにローカライズはIETF問題ではありません、そして、一般に、それらが順次数個の位置に局所化されても単に局所化されるプロトコルは世界的なインターネットに不十分であると考えられます。
Do not confuse "localization" with "locale", which is described in
Section 7 of this document.
「ローカライズ」を「現場」に間違えないでください。(それは、このドキュメントのセクション7で説明されます)。
i18n, l10n
i18n、l10n
These are abbreviations for "internationalization" and
"localization". <NONE>
これらは「国際化」と「ローカライズ」のための略語です。 <、>のいずれも
"18" is the number of characters between the "i" and the "n" in
"internationalization", and "10" is the number of characters
between the "l" and the "n" in "localization".
「18インチは「i」と「国際化」における「n」の間のキャラクタの数です、そして、「10インチは「l」と「ローカライズ」における「n」の間のキャラクタの数です」。
multilingual
多数の言語で表現にされる
The term "multilingual" has many widely-varying definitions and
thus is not recommended for use in standards. Some of the
definitions relate to the ability to handle international
「多言語」という用語は、多くの広く異なった定義を持って、その結果、規格における使用のために推薦されません。 定義のいくつかが国際的に扱う能力に関連します。
Hoffman Informational [Page 7] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[7ページ]のRFC3536Terminology
characters; other definitions relate to the ability to handle
multiple charsets; and still others relate to the ability to
handle multiple languages. <NONE>
キャラクタ。 他の定義は複数のcharsetsを扱う能力に関連します。 そして、それでも、他のものは複数の言語を扱う能力に関連します。 <、>のいずれも
displaying and rendering text
表示と表現テキスト
To display text, a system puts characters on a visual display
device such as a screen or a printer. To render text, a system
analyzes the character input to determine how to display the text.
The terms "display" and "render" are sometimes used
interchangeably. Note, however, that text might be rendered as
audio and/or tactile output, such as in systems that have been
designed for people with visual disabilities. <NONE>
テキストを表示するために、システムはスクリーンかプリンタなどの視覚ディスプレイ装置にキャラクタを置きます。 テキストを表すなら、システムは、テキストを表示する方法を決定するためにキャラクタ入力を分析します。 用語「表示」と「レンダリング」は時々互換性を持って使用されます。 注意、しかしながら、そのテキストはオーディオの、そして/または、触覚の出力として表されるかもしれません、人々のために視覚障害で設計されているシステムなどのように。 <、>のいずれも
Combining characters modify the display of the character (or, in
some cases, characters) that precede them. When rendering such
text, the display engine must either find the glyph in the font
that represents the base character and all of the combining
characters, or it must render the combination itself. Such
rendering can be straight-forward, but it is sometimes complicated
when the combining marks interact with each other, such as when
there are two combining marks that would appear above the same
character. Formatting characters can also change the way that a
renderer would display text. Rendering can also be difficult for
some scripts that have complex display rules for base characters,
such as Arabic and Indic scripts.
結合したキャラクタは彼らに先行するキャラクタ(いくつかの場合キャラクタ)の表示を変更します。 そのようなテキストを表すとき、結合したキャラクタの基本文字とすべての代理をする字体で表示エンジンはglyphに当たらなければなりませんか、またはそれが組み合わせ自体をレンダリングしなければなりません。 そのような表現は簡単である場合がありますが、結合マークが互いに対話するとき、それは時々複雑です、同じキャラクタを超えて現れる2つの結合マークがある時のように。 また、形式キャラクタはレンダラーがテキストを表示する方法を変えることができます。 また、基本文字のための複雑な表示規則を持っているいくつかのスクリプトに、表現も難しい場合があります、アラビアの、そして、インドの文字などのように。
3. Standards Bodies and Standards
3. 標準化団体と規格
This section describes some of the standards bodies and standards that appear in discussions of internationalization in the IETF. This is an incomplete and possibly over-full list; listing too few bodies or standards can be just as politically dangerous as listing too many. Note that there are many other bodies that deal with internationalization; however, few if any of them appear commonly in IETF standards work.
このセクションはIETFでの国際化の議論に現れる標準化団体と規格のいくつかについて説明します。 これがそうである、不完全でことによるとリストを洗い張りし過ぎています。 あまりにわずかなボディーか規格を記載するのは政治的にまた、多くを記載するのとちょうど同じくらい危険であることができます。 国際化に対処する他の多くのボディーがあることに注意してください。 しかしながら、彼らのどれかがIETF規格に一般的に現れるなら、わずかしか働いていません。
3.1 Standards bodies
3.1 標準化団体
ISO
ISO
The International Organization for Standardization has been
involved with standards for characters since before the IETF was
started. ISO is a non-governmental group made up of national
bodies. ISO has many diverse standards in the international
characters area; the one that is most used in the IETF is commonly
referred to as "ISO/IEC 10646", although its official name has
IETFが始動される前以来国際標準化機構はキャラクタの規格にかかわっています。 ISOは国家体で構成されていた民間のグループです。 ISOは国際的な人物領域に多くのさまざまの規格を持っています。 IETFで最も使用されるのは一般的に「ISO/IEC10646」と呼ばれます、正式名称はそうしましたが
Hoffman Informational [Page 8] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[8ページ]のRFC3536Terminology
more qualifications. (The IEC is International Electrotechnical
Commission). ISO/IEC 10646 describes a CCS that covers almost all
known written characters in use today.
より多くの資格。 (IECは国際電気標準化会議です。) ISO/IEC10646は今日使用中のほとんどすべての知られている書かれたキャラクタをカバーするCCSについて説明します。
ISO/IEC 10646 is controlled by the group known as "ISO/IEC JTC
1/SC 2 WG2", often called "WG2" for short. ISO standards go
through many steps before being finished, and years often go by
between changes to ISO/IEC 10646. Information on WG2, and its
work products, can be found at
<http://www.dkuug.dk/JTC1/SC2/WG2/>.
ISO/IEC10646が知られているグループによって制御される、「しばしば「略してWG2"」と呼ばれるISO/IEC JTC1/サウスカロライナ2WG2" 終わっている前にISO規格は多くの階段を通ります、そして、何年もISO/IEC10646への変化の間でしばしば過ぎます。 <http://www.dkuug.dk/JTC1/SC2/WG2/>でWG2に関する情報、およびその作業生産物を見つけることができます。
The standard, which comes in multiple parts, can be purchased in
both print and CD-ROM versions. One example of how to cite the
standard is given in [RFC2279]. Any standard that cites ISO/IEC
10646 needs to evaluate how to handle the versioning problem that
is relevant to the protocol's needs.
印刷とCD-ROMバージョンの両方で規格(複数の部品に入る)を購入できます。 どう規格を引用するかに関する1つの例が[RFC2279]で出されます。 ISO/IEC10646を引用するどんな規格も、プロトコルの必要性に関連しているversioning問題を扱う方法を評価する必要があります。
ISO is responsible for other standards that might be of interest
to protocol developers. [ISO 639] specifies the names of
languages, and [ISO 3166] specifies the abbreviations of
countries. Character work is done in the group known as ISO/IEC
JTC1/SC22 and ISO TC46, as well as other ISO groups.
ISOは他の開発者について議定書の中で述べるために興味があるかもしれない規格に責任があります。 [ISO639]は言語の名前を指定します、そして、[ISO3166]は国の略語を指定します。 ISO/IEC JTC1/SC22、ISO TC46、および他のISOグループとして知られているグループでキャラクター仕事をします。
Another relevant ISO group is JTC 1/SC22/WG20, which is
responsible for internationalization in JTC1, such as for
international string ordering. Information on WG20, and its work
products, can be found at <http://www.dkuug.dk/jtc1/sc22/wg20/>
別の関連ISOグループはJTC1/SC22/WG20です。(そのJTCはJTC1での国際化、国際的なストリング注文などのように責任があります)。 <http://www.dkuug.dk/jtc1/sc22/wg20/>でWG20に関する情報、およびその作業生産物を見つけることができます。
Unicode Consortium
ユニコード共同体
The second important group for international character standards
is the Unicode Consortium. The Unicode Consortium is a trade
association of companies, governments, and other groups interested
in promoting the Unicode Standard [UNICODE]. The Unicode Standard
is a CCS whose repertoire and code points are identical to ISO/IEC
10646. The Unicode Consortium has added features to the base CCS
which make it more useful in protocols, such as defining
attributes for each character. Examples of these attributes
include case conversion and numeric properties.
国際的な人物規格のための2番目の重要なグループはユニコードConsortiumです。 ユニコードConsortiumはユニコードStandard[ユニコード]を促進したがっていた会社、政府、および他のグループの産業団体です。 ユニコードStandardはレパートリーとコード・ポイントがISO/IEC10646と同じであるCCSです。 ユニコードConsortiumはそれをプロトコルで、より役に立つようにするベースCCSに特徴を加えました、各キャラクタのために属性を定義するのなどように。 これらの属性に関する例はケース変換と数値特性を含んでいます。
The Unicode Consortium publishes addenda to the Unicode Standard
as Unicode Technical Reports. There are many types of technical
reports at various stages of maturity. The Unicode Standard and
affiliated technical reports can be found at
<http://www.unicode.org/>.
ユニコードConsortiumはユニコードTechnical ReportsとしてユニコードStandardに付加物を発行します。 様々なステージの円熟のときに、多くのタイプに関する技術報告書があります。 <http://www.unicode.org/>でユニコードStandardと系列技術報告書を見つけることができます。
Hoffman Informational [Page 9] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[9ページ]のRFC3536Terminology
World Wide Web Consortium (W3C)
ワールドワイドウェブコンソーシアム(W3C)
This group created and maintains the standard for XML, the markup
language for text that has become very popular. XML has always
been fully internationalized so that there is no need for a new
version to handle international text.
このグループは、非常にポピュラーになったテキストのために、XMLの規格、マークアップ言語を作成して、維持します。 XMLは、新しいバージョンが国際的なテキストを扱う必要は全くないように、完全にいつも国際的にされていました。
local and regional standards organizations
地方の、そして、地方の規格組織
Just as there are many native CCSs and charsets, there are many
local and regional standards organizations to create and support
them. Common examples of these are ANSI (United States), and
CEN/ISSS (Europe).
ちょうど多くのネイティブのCCSsとcharsetsがあるとき、それらを作成して、支持するために、多くの地方の、そして、地方の規格組織があります。 これらの一般的な例は、ANSI(合衆国)と、CEN/ISSS(ヨーロッパ)です。
3.2 Encodings and transformation formats of ISO/IEC 10646
3.2 ISO/IEC10646のEncodingsと変化形式
Characters in the ISO/IEC 10646 CCS can be expressed in many ways. Encoding forms are direct addressing methods, while transformation formats are methods for expressing encoding forms as bits on the wire.
様々な意味でISO/IEC10646CCSのキャラクターを言い表すことができます。 コード化フォームは直接アドレス指定方法ですが、変化形式はワイヤのビットとしてフォームをコード化する言い表す方法です。
Basic Multilingual Plane (BMP)
基本多言語水準(BMP)
The BMP is composed of the first 2^16 code points in ISO/IEC
10646. The BMP is also called "plane 0".
BMPはISO/IEC10646の最初の2^16コード・ポイントで構成されます。 また、BMPは「飛行機0インチ」と呼ばれます。
UCS-2 and UCS-4
UCS-2とUCS-4
UCS-2 and UCS-4 are the two encoding forms defined for ISO/IEC
10646. UCS-2 addresses only the BMP. Because many useful
characters (such as many Han characters) have been defined outside
of the BMP, many people would consider UCS-2 to be dead.
Theoretically, UCS-4 addresses the entire range of 2^31 code
points from ISO/IEC 10646 as 32-bit values. However, for
interoperability with UTF-16, ISO 10646 restricts the range of
characters that will actually be allocated to the values
0..0x10FFFF.
UCS-2とUCS-4はISO/IEC10646のために定義された書式をコード化する2歳です。 UCS-2はBMPだけを記述します。 多くの役に立つキャラクタ(多くのハンキャラクタなどの)がBMPの外で定義されたので、多くの人々が、UCS-2が死んでいると考えるでしょう。 理論的に、UCS-4は32ビットの値としてISO/IEC10646から2^31コード・ポイントの全体の範囲を記述します。 しかしながら、UTF-16がある相互運用性のために、ISO10646は実際に値0に割り当てられるキャラクタの範囲を制限します。0x10FFFF。
UTF-8
UTF-8
UTF-8, a transformation format specified in [RFC2279], is the
preferred encoding for IETF protocols. Characters in the BMP are
encoded as one, two, or three octets. Characters outside the BMP
are encoded as four octets. Characters from the US-ASCII
repertoire have the same on-the-wire representation in UTF-8 as
they do in US-ASCII.
UTF-8([RFC2279]で指定された変化形式)はIETFプロトコルのための都合のよいコード化です。 BMPのキャラクターは1、2、または3つの八重奏としてコード化されます。 BMPの外のキャラクターは4つの八重奏としてコード化されます。 それらが米国-ASCIIでするように米国-ASCIIレパートリーからのキャラクターはUTF-8にワイヤにおける同じ表現を持っています。
Hoffman Informational [Page 10] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[10ページ]のRFC3536Terminology
UTF-16, UTF-16BE, and UTF-16LE
UTF-16、UTF-16BE、およびUTF-16LE
UTF-16, UTF-16BE, and UTF-16LE, three transformation formats
defined in [RFC2781], are not required by any IETF standards, and
are thus used much less often than UTF-8. Characters in the BMP
are always encoded as two octets, and characters outside the BMP
are encoded as four octets. The three formats differ based on the
order of the octets and the presence of a special lead-in mark
called the "byte order mark" or "BOM".
UTF-16(形式が[RFC2781]で定義したUTF-16BE、およびUTF-16LE、3変化)はUTF-8よりどんなIETF規格も必要でなく、このようにしてまして、しばしば使用されます。 BMPのキャラクターは2つの八重奏としていつもコード化されます、そして、BMPの外のキャラクタは4つの八重奏としてコード化されます。 3つの形式が「バイト・オーダー・マークかBOM」と呼ばれる八重奏の注文と特別な引込み線のマークの存在に基づいて異なります。
UTF-32
UTF-32
The Unicode Consortium has defined UTF-32 as a transformation
format for UCS-4 in [UTR19].
ユニコードConsortiumは[UTR19]でUCS-4のための変化形式とUTF-32を定義しました。
SCSU and BOCU-1
SCSUとBOCU-1
The Unicode Consortium has defined an encoding, SCSU, which is
designed to offer good compression for typical text. SCSU is
described in [UTR6]. A different encoding that is meant to be
MIME-friendly, BOCU-1, is described in [UTN6]. Although
compression is attractive, as opposed to UTF-8 , neither of these
(at the time of this writing) has attracted much interest in the
IETF.
ユニコードConsortiumはコード化、典型的なテキストのために良い圧縮を提供するように設計されているSCSUを定義しました。 SCSUは[UTR6]で説明されます。 MIMEに優しいことが意味される異なったコード化(BOCU-1)は[UTN6]で説明されます。 圧縮はUTF-8と対照的に魅力的ですが、これら(この書くこと時点の)のどちらもIETFへの大きな関心を引き付けていません。
3.3 Native CCSs and charsets
3.3 ネイティブのCCSsとcharsets
Before ISO/IEC 10646 was developed, many countries developed their own CCSs and charsets. Many dozen of these are in common use on the Internet today. Examples include ISO 8859-5 for Cyrillic and Shift- JIS for Japanese scripts.
ISO/IEC10646が発展する前に、多くの国がそれら自身のCCSsとcharsetsを開発しました。 ダースの多くのこれらは今日、インターネットで共用です。 例は日本の文字のためのキリール文字とShift JISのためのISO8859-5を含んでいます。
The official list of the registered charset names for use with IETF protocols is maintained by IANA and can be found at <http://www.iana.org/assignments/character-sets>. The list contains preferred names and aliases. Note that this list has historically contained many errors, such as names that are in fact not charsets or references that do not give enough detail to reliably map names to charsets.
IETFプロトコルによる使用のための登録されたcharset名に関する株式相場表をIANAが維持して、<http://www.iana.org/課題/文字集合>で見つけることができます。 リストは都合のよい名前と別名を含んでいます。 このリストにはある注意は多くの誤りを歴史的に含みました、事実上charsetsでない名前や名前をcharsetsに確かに写像できるくらいの詳細を述べない参照のように。
Probably the most well-known native CCS is ASCII [US-ASCII]. This CCS is used as the basis for keywords and parameter names in many IETF protocols, and as the sole CCS in numerous IETF protocols that have not yet been internationalized.
たぶん最もよく知られているネイティブのCCSはASCII[米国-ASCII]です。 このCCSはキーワードの基礎と多くのIETFプロトコルのパラメタ名としてまだ国際的にされていない多数のIETFプロトコルの唯一のCCSとして使用されます。
[UTR22] describes issues involved in mapping character data between charsets, and an XML format for mapping table data.
[UTR22]は、charsetsの間でキャラクタデータを写像するのにかかわる問題について説明して、テーブルデータを写像するためにXML形式について説明します。
Hoffman Informational [Page 11] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[11ページ]のRFC3536Terminology
4. Character Issues
4. キャラクター問題
This section contains terms and topics that are commonly used in character handling and therefore are of concern to people adding non-ASCII text handling to protocols. These topics are standardized outside the IETF.
このセクションは非ASCIIテキスト取り扱いをプロトコルに追加するキャラクタ取り扱いに一般的に使用された、人々にとって、したがって重要な用語と話題を含みます。 これらの話題はIETFの外で標準化されます。
combining character
キャラクタを結合します。
A member of an identified subset of the coded character set of
ISO/IEC 10646 intended for combination with the preceding non-
combining graphic character, or with a sequence of combining
characters preceded by a non-combining character. <ISOIEC10646>
前の非結合した図形文字、または非結合したキャラクタによって先行されている結合したキャラクタの系列への組み合わせのために意図するISO/IEC10646のコード化文字集合の特定された部分集合のメンバー。 <ISOIEC10646>。
composite sequence
コンポジット・シーケンス
A sequence of graphic characters consisting of a non-combining
character followed by one or more combining characters. A graphic
symbol for a composite sequence generally consists of the
combination of the graphic symbols of each character in the
sequence. A composite sequence is not a character and therefore
is not a member of the repertoire of ISO/IEC 10646. <ISOIEC10646>
非結合したキャラクタから成る図形文字の順序は、より1時までにキャラクタを結合しながら、従いました。 一般に、コンポジット・シーケンスの図形は系列における、それぞれのキャラクタの図形の組み合わせから成ります。 コンポジット・シーケンスは、キャラクタでなく、またしたがって、ISO/IEC10646のレパートリーのメンバーではありません。 <ISOIEC10646>。
In some CCSs, some characters consist of combinations of other
characters. For example, the letter "a with acute" might be a
combination of the two characters "a" and "combining acute", or it
might be a combination of the three characters "a", a non-
destructive backspace, and an acute. The rules for combining two
or more characters are called "composition rules", and the rules
for taking apart a character into other characters is called
"decomposition rules". The results of composition is called a
"precomposed character"; the results of decomposition is called a
"decomposed character".
いくつかのCCSsに、他のキャラクタの組み合わせから成るキャラクタもあります。 そして、例えば、2つのキャラクタの組み合わせが“a"で「結合鋭い」なら「鋭いのがあるa」がそうするか、または3つのキャラクタ“a"、aの組み合わせが非破壊的であるならそれがそうする手紙がバックスペースキーである、鋭いです。 2つ以上のキャラクタを結合するための規則は他のキャラクタにキャラクタを分解するために「構成規則」、および規則と呼ばれているのが、呼ばれた「分解規則」であるということです。 構成の結果は「前構成されたキャラクタ」と呼ばれます。 分解の結果は「分解しているキャラクタ」と呼ばれます。
normalization
正常化
Normalization is the transformation of data to a normal form, for
example, to unify spelling. <UNICODE>
正常化は、例えばスペルを統一するためには正規形へのデータの変換です。 <ユニコード>。
Note that the phrase "unify spelling" in the definition above does
not mean unifying different words with the same meaning (such as
"color" and "colour"). Instead, it means unifying different
character sequences that are intended to form the same composite
characters (such as "<a><n><combining tilde><o>" and "<a><n with
tilde><o>").
上の定義で「スペルを統一する」という句が、同じ意味(「色」や「色」などの)で異なった単語を統一することを意味しないことに注意してください。 代わりに、それは、同じ作られた登場人物(「<a><n><結合ティルド><o>」や「ティルド><o>と<a><n」などの)を形成することを意図する異なったキャラクタシーケンスを統一することを意味します。
Hoffman Informational [Page 12] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[12ページ]のRFC3536Terminology
The purpose of normalization is to allow two strings to be
compared for equivalence. The strings "<a><n><combining
tilde><o>" and "<a><n with tilde><o>" would be shown identically
on a text display device. If a protocol designer wants those two
strings to be considered equivalent during comparison, the
protocol must define where normalization occurs.
正常化の目的は2個のストリングが等価性のために比較されるのを許容することです。 ストリングの「<a><n><結合ティルド><o>」と「ティルド><o>と<a><n」は同様にテキストディスプレイ装置で示されるでしょう。 プロトコルデザイナーが比較の間、同等であるとそれらの2個のストリングを考えて欲しいなら、プロトコルは、正常化がどこに起こるかを定義しなければなりません。
The terms "normalization" and "canonicalization" are often used
interchangeably. Generally, they both mean to convert a string of
one or more characters into another string based on standardized
rules. Some CCSs allow multiple equivalent representations for a
written string; normalization selects one among multiple
equivalent representations as a base for reference purposes in
comparing strings. In strings of text, these rules are usually
based on decomposing combined characters or composing characters
with combining characters. [UTR15] describes the process and many
forms of normalization in detail. Normalization is important when
comparing strings to see if they are the same.
用語の「正常化」と"canonicalization"はしばしば互換性を持って使用されます。 一般に、それらの両方が、標準化された規則に基づく別のストリングに一連の1つ以上のキャラクタを変換することを意味します。 いくつかのCCSsが書かれたストリングの複数の同等な表現を許容します。 正常化はストリングを比較する際にベースとしての参照目的の複数の同等な表現の中の1つを選択します。 テキストのストリングでは、これらの規則は、通常、結合したキャラクタを分解するのに基づいているか、またはキャラクタを結合するのにキャラクタを構成することです。 [UTR15]は詳細にプロセスと多くの形式の正常化について説明します。 それらが同じであるかどうか確認するためにストリングを比較するとき、正常化は重要です。
case
ケース
Case is the feature of certain alphabets where the letters have
two distinct forms. These variants, which may differ markedly in
shape and size, are called the uppercase letter (also known as
capital or majuscule) and the lowercase letter (also known as
small or minuscule). Case mapping is the association of the
uppercase and lowercase forms of a letter. <UNICODE>
ケースは手紙が2つの異なったフォームを持っているあるアルファベットの特徴です。これらの異形(形とサイズにおいて著しく異なるかもしれない)は大文字(また、首都として知られているか、大文字の)と小文字(また、小さいか小さいとして、知られている)と呼ばれます。 ケースマッピングは手紙の大文字していて小文字のフォームの協会です。 <ユニコード>。
There is usually (but not always) a one-to-one mapping between the
same letter in the two cases. However, there are many examples of
characters which exist in one case but for which there is no
corresponding character in the other case or for which there is a
special mapping rule, such as the Turkish dotless "i" and some
Greek characters with modifiers. Case mapping can even be
dependent on locale. Converting text to have only one case is
called "case folding".
(いつもでない)通常、同じ手紙の間には、2つの場合に1〜1つのマッピングがあります。 しかしながら、ある場合で存在しますが、もう片方の場合にはどんな対応するキャラクタもないか、または特別な配置規則があるキャラクタに関する多くの例があります、トルコのdotless「i」や修飾語がある何人かのギリシア人のキャラクタのように。 ケースマッピングは現場に依存してさえいる場合があります。 1つのケースしか持たないようにテキストを変換するのは「ケースの折り重なり」と呼ばれます。
sorting and collation
ソーティングと照合
Collating is the process of ordering units of textual information.
Collation is usually specific to a particular language. It is
sometimes known as alphabetizing, although alphabetization is just
a special case of sorting and collation. <UNICODE>
照合はユニットの文字情報を注文するプロセスです。 通常、照合は特定の言語に特定です。 ABC順排列はただソーティングと照合の特別なケースですが、それはアルファベット順にするとして時々知られています。 <ユニコード>。
Hoffman Informational [Page 13] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[13ページ]のRFC3536Terminology
Collation is concerned with the determination of the relative
order of any particular pair of strings, and algorithms concerned
with collation focus on the problem of providing appropriate
weighted keys for string values, to enable binary comparison of
the key values to determine the relative ordering of the strings.
キー値の2進の比較がストリングを注文する親類を決定するのを可能にするために適切な状態で提供するという問題の焦点がストリング値のためにキーに重みを加えたことをどんな特定の組のストリング、および照合に関するアルゴリズムの相対オーダの決断にも照合を心配させます。
Sorting is the process of actually putting data records into
specified orders, according to criteria for comparison between the
records. Sorting can apply to any kind of data (including textual
data) for which an ordering criterion can be defined. Algorithms
concerned with sorting focus on the problem of performance (in
terms of time, memory, or other resources) in actually putting the
data records into a specified order.
ソーティングは記録での比較の評価基準に従って実際に指定された命令にデータレコードを入れるプロセスです。 注文評価基準を定義できるどんな種類のデータ(原文のデータを含んでいる)にもソーティングは適用できます。 ソーティングに関するアルゴリズムは実際に指定されたオーダーにデータレコードを入れる際に性能(時間、メモリ、または他のリソースに関する)の問題に焦点を合わせます。
A sorting algorithm for string data can be internationalized by
providing it with the appropriate collation-weighted keys
corresponding to the strings to be ordered.
注文されるストリングに対応する適切な照合で荷重しているキーをそれに提供することによって、列データのためのソーティングアルゴリズムを国際的にすることができます。
Many processes have a need to order strings in a consistent
sequence (sorted). For only a few CCS/CES combinations, there is
an obvious sort order that can be done without reference to the
linguistic meaning of the characters: the codepoint order is
sufficient for sorting. That is, the codepoint order is also the
order that a person would use in sorting the characters. For many
CCS/CES combinations, the codepoint order would make no sense to a
person and therefore is not useful for sorting if the results will
be displayed to a person.
多くのプロセスには、一貫した系列(分類される)でストリングを注文する必要があります。 ほんのいくつかのCCS/CES組み合わせのために、キャラクタの言語的意味の参照なしでできる明白なソート順序があります: codepointオーダーはソーティングに十分です。 また、すなわち、codepointオーダーは人がキャラクタを割り当てる際に使用するオーダーです。 多くのCCS/CES組み合わせでは、人に結果を表示するなら、codepointオーダーは、人に意味をなさないだろう、したがって、ソーティングの役に立ちません。
Codepoint order is usually not how any human educated by a local
school system expects to see strings ordered; if one orders to the
expectations of a human, one has a language-specific sort.
Sorting to codepoint order will seem inconsistent if the strings
are not normalized before sorting because different
representations of the same character will sort differently. This
problem may be smaller with a language-specific sort.
通常、Codepointオーダーは地元の学校システムによって教育されたどんな人間も、ストリングが注文されるのを見るとどう予想するかということではありません。 1つが人間への期待に注文されるなら、1つには、言語特有の種類があります。 同じキャラクタの異なった表現が異なって分類されるのでストリングがソーティングの前に正常にされないなら、codepointオーダーへのソーティングは矛盾しているように見えるでしょう。 この問題は言語特有の種類で、より小さいかもしれません。
code table
コードテーブル
A code table is a table showing the characters allocated to the
octets in a code. <ISOIEC10646>
コードテーブルはキャラクタがコードにおける八重奏に割り当てたテーブル表示です。 <ISOIEC10646>。
Code tables are also commonly called "code charts".
また、コードテーブルは一般的に「コードチャート」と呼ばれます。
Hoffman Informational [Page 14] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[14ページ]のRFC3536Terminology
4.1 Types of characters
キャラクタの4.1のタイプ
The following definitions of types of characters do not clearly delineate each character into one type, nor do they allow someone to accurately predict what types would apply to a particular character. The definitions are intended for application designers to help them think about the many (sometimes confusing) properties of text.
キャラクタのタイプの以下の定義は明確に各キャラクタを1つのタイプに図で表わしません、そして、彼らはだれかが、どんなタイプが特定のキャラクタに当てはまるかを正確に予測するのを許しません。 定義はアプリケーション設計者が、彼らがテキストの多くの(時々紛らわしい)の特性について考えるのを助けることを意図します。
alphabetic
アルファベット
An informative Unicode property. Characters that are the primary
units of alphabets and/or syllabaries, whether combining or
noncombining. This includes composite characters that are
canonical equivalents to a combining character sequence of an
alphabetic base character plus one or more combining characters:
letter digraphs; contextual variant of alphabetic characters;
ligatures of alphabetic characters; contextual variants of
ligatures; modifier letters; letterlike symbols that are
compatibility equivalents of single alphabetic letters; and
miscellaneous letter elements. <UNICODE>
有益なユニコードの特性。 結合か非結合であることにかかわらずプライマリユニットのアルファベット、そして/または、音節表であるキャラクター。 これはキャラクタを結合するアルファベット基本文字と1つ以上の結合キャラクタシーケンスと正準な同等物である作られた登場人物を含んでいます: 手紙連字。 英字の文脈上の異形。 英字のひも。 ひもの文脈上の異形。 修飾語手紙。 ただ一つのアルファベット手紙の互換性同等物であるletterlikeシンボル。 そして、種々雑多な手紙要素。 <ユニコード>。
ideographic
表意文字
Any symbol that primarily denotes an idea (or meaning) in contrast
to a sound (or pronunciation), for example, a symbol showing a
telephone or the Han characters used in Chinese, Japanese, and
Korean. <UNICODE>
例えば電話を示しているシンボルかハンキャラクタが中国語、日本語、および韓国語で使用した音(または、発音)と対照して主として、考え(または、意味)を指示するどんなシンボル。 <ユニコード>。
punctuation
句読
Characters that separate units of text, such as sentences and
phrases, thus clarifying the meaning of the text. The use of
punctuation marks is not limited to prose; they are also used in
mathematical and scientific formulae, for example. <UNICODE>
ユニットのテキストを切り離すその結果テキストの意味をはっきりさせる文や句などのキャラクター。 句読点の使用は散文に制限されません。 また、それらは例えば、数学的、そして、科学的な公式に使用されます。 <ユニコード>。
symbol
シンボル
One of a set of characters other than those used for letters,
digits, or punctuation, and representing various concepts
generally not connected to written language use per se. Examples
include symbols for mathematical operators, symbols for OCR,
symbols for box-drawing or graphics, and symbols for dingbats.
<NONE>
一般に、それら以外の文字、ケタ、または句読に使用される1セットのキャラクタのひとりと、様々な概念を表すのはそういうものとして文語使用に接続しませんでした。 例は数学のオペレータのシンボル、OCRのシンボル、箱図面かグラフィックスのシンボル、および装飾活字のシンボルを含んでいます。 <、>のいずれも
Examples of symbols include characters for arrows, faces, and
geometric shapes. [UNICODE] has a property that defines
characters as symbols.
シンボルに関する例は矢、表面、および幾何学上形のためのキャラクタを含んでいます。 [ユニコード]には、キャラクタをシンボルと定義する特性があります。
Hoffman Informational [Page 15] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[15ページ]のRFC3536Terminology
nonspacing character
キャラクタを「非-区切」ります。
A combining character whose positioning in presentation is
dependent on its base character. It generally does not consume
space along the visual baseline in and of itself. <UNICODE>
プレゼンテーションにおける位置決めが基本文字に依存している結合したキャラクタ。 一般に、それはそういうものの視覚基線に沿ってスペースを消費しません。 <ユニコード>。
A combining acute accent (U+0301) is an example of a nonspacing
character.
結合鋭アクセント(U+0301)は「非-区切」っているキャラクタに関する例です。
diacritic
区別的発音符
A mark applied or attached to a symbol to create a new symbol that
represents a modified or new value. They can also be marks
applied to a symbol irrespective of whether it changes the value
of that symbol. In the latter case, the diacritic usually
represents an independent value (for example, an accent, tone, or
some other linguistic information). Also called diacritical mark
or diacritical. <UNICODE>
マークは、変更されたか新しい値を表す新しいシンボルを作成するためにシンボルに適用したか、または付きました。 また、それらはそのシンボルの値を変えるかどうかの如何にかかわらずシンボルに適用されたマークであるかもしれません。 後者の場合では、通常、区別的発音符は独立している値(例えば、アクセント、トーン、またはある他の言語学の情報)を表します。 また、読み分け記号か識別的であると呼ばれます。 <ユニコード>。
control character
制御文字
The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F.
They are also known as control codes. <UNICODE>
範囲U+0000の65のキャラクタ。U+001FとU+007F.。U+009F。 また、それらは制御コードとして知られています。 <ユニコード>。
formatting character
形式キャラクタ
Characters that are inherently invisible but that have an effect
on the surrounding characters. <UNICODE>
本来目に見えないキャラクターにもかかわらず、それは周囲のキャラクタに影響を与えます。 <ユニコード>。
Examples of formatting characters include characters for
specifying the direction of text and characters that specify how
to join multiple characters.
形式キャラクタに関する例はテキストの方向を指定するためのキャラクタと複数のキャラクタに加わる方法を指定するキャラクタを含んでいます。
compatibility character
互換性キャラクタ
A graphic character included as a coded character of ISO/IEC 10646
primarily for compatibility with existing coded character sets.
<ISOIEC10646>
図形文字は主として存在するとの互換性のためのISO/IEC10646のコード化されたキャラクタとしてコード化文字集合を含んでいました。 <ISOIEC10646>。
For example, U+FF01 (FULLWIDTH EXCLAMATION MARK) was included for
compatibility with Asian character sets that include full-width
and half-width ASCII characters.
例えば、U+FF01(FULLWIDTH EXCLAMATION MARK)は全幅と半値幅ASCII文字を含んでいるアジアの文字集合との互換性のために含まれていました。
Hoffman Informational [Page 16] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[16ページ]のRFC3536Terminology
5. User interface for text
5. テキストのためのユーザーインタフェース
Although the IETF does not standardize user interfaces, many protocols make assumptions about how a user will enter or see text that is used in the protocol. Internationalization challenges assumptions about the type and limitations of the input and output devices that may be used with applications that use various protocols. It is therefore useful to consider how users typically interact with text that might contain one or more non-ASCII characters.
IETFはユーザインタフェースを標準化しませんが、多くのプロトコルがユーザがプロトコルに使用されるテキストを入るか、またはどう見るかに関する仮定をします。 国際化は様々なプロトコルを使用するアプリケーションと共に使用されるかもしれない入出力装置のタイプと限界に関する仮定に挑戦します。 したがって、ユーザがどのように1人以上の非ASCII文字を含むかもしれないテキストと通常対話するかを考えるのは役に立ちます。
input methods
入力メソッド
An input method is a mechanism for a person to enter text into an
application. <NONE>
入力メソッドは人がアプリケーションにテキストを入れるメカニズムです。 <、>のいずれも
Text can be entered into a computer in many ways. Keyboards are
by far the most common device used, but many characters cannot be
entered on typical computer keyboards in a single stroke. Many
operating systems come with system software that lets users input
characters outside the range of what is allowed by keyboards.
様々な意味でコンピュータにテキストを入れることができます。 キーボードは使用される中で断然最も一般的なデバイスですが、1つのストロークでは典型的なコンピュータのキーボードに多くのキャラクタを入れることができません。 多くのオペレーティングシステムがユーザがキーボードによって許容されていることに関する範囲の外でキャラクタを入力できるシステムソフトと共に来ます。
For example, there are dozens of different input methods for Han
characters in Chinese, Japanese, and Korean. Some start with
phonetic input through the keyboard, while others use the number
of strokes in the character. Input methods are also needed for
scripts that have many diacritics, such as European characters
that have two or three diacritics on a single alphabetic
character.
例えば、中国語、日本語、および韓国語にはハンキャラクタのための何十もの異なった入力メソッドがあります。 或るものはキーボードを通した音声の入力から始まりますが、他のものはキャラクタのストロークの数を使用します。 また、入力メソッドが多くの区別的発音符を持っているスクリプトに必要です、ただ一つの英字に2か3つの区別的発音符を持っているヨーロッパ人のキャラクタなどのように。
rendering rules
レンダリング規則
A rendering rule is an algorithm that a system uses to decide how
to display a string of text. <NONE>
レンダリング規則はシステムがテキストのストリングを表示する方法を決めるのに使用するアルゴリズムです。 <、>のいずれも
Some scripts can be directly displayed with fonts, where each
character from an input stream can simply be copied from a glyph
system and put on the screen or printed page. Other scripts need
rules that are based on the context of the characters in order to
render text for display.
フォントと共にいくつかのスクリプトを直接表示できます、単に入力ストリームからの各キャラクタをglyphシステムからコピーして、スクリーンか印刷されたページに置くことができるところで。 他のスクリプトはディスプレイのためにテキストを表すためにキャラクタの文脈に基づいている規則を必要とします。
Some examples of these rendering rules include:
これらのレンダリング規則に関するいくつかの例は:
- Scripts such as Arabic (and many others), where the form of
the letter changes depending on the adjacent letters, whether
the letter is standing alone, at the beginning of a word, in
the middle of a word, or at the end of a word. The rendering
rules must choose between two or more glyphs.
- アラビア語(そして、多くの他のもの)などのように、手紙が単語の中央か、単語の終わりに単独で語頭に立っているか否かに関係なく、原稿を書きます。そこでは、隣接している手紙によって、手紙のフォームが変化します。 レンダリング規則は2以上glyphsを選ばなければなりません。
Hoffman Informational [Page 17] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[17ページ]のRFC3536Terminology
- Scripts such as the Indic scripts, where consonants may
change their form if they are adjacent to certain other
consonants or may be displayed in an order different from
the way they are stored and pronounced. The rendering rules
must choose between two or more glyphs.
- インドのスクリプトなどのスクリプト、それらを他のある子音に隣接しているか、または道と異なったオーダーに表示するかもしれないなら子音がそれらのフォームを変えるかもしれないところでは、それらは、保存されて、発音されます。 レンダリング規則は2以上glyphsを選ばなければなりません。
- Arabic and Hebrew scripts, where the order of the characters
displayed are changed by the bidirectional properties of the
alphabetic characters and with right-to-left and
left-to-right ordering marks. The rendering rules must
choose the order that characters are displayed.
- アラビアの、そして、ヘブライの文字。(そこでは、キャラクタの注文が、英字の双方向の特性によって変えられて、右から左と左から右でマークを注文しながら、表示しました)。 表示して、規則がキャラクタがそうであるオーダーを選ばなければならないレンダリング。
graphic symbol
図形
A graphic symbol is the visual representation of a graphic
character or of a composite sequence. <ISOIEC10646>
図形は図形文字かコンポジット・シーケンスの視覚表現です。 <ISOIEC10646>。
font
フォント
A font is a collection of glyphs used for the visual depiction of
character data. A font is often associated with a set of
parameters (for example, size, posture, weight, and serifness),
which, when set to particular values, generate a collection of
imagable glyphs. <UNICODE>
フォントはキャラクタデータの視覚描写に使用されるglyphsの収集です。 フォントはしばしば1セットのパラメタ(例えば、サイズ、姿勢、重さ、およびセリフ)に関連しています。(特定の値に設定されると、パラメタはimagable glyphsの収集を作ります)。 <ユニコード>。
bidirectional display
双方向のディスプレイ
The process or result of mixing left-to-right oriented text and
right-to-left oriented text in a single line is called
bidirectional display. <UNICODE>
右まで残っている混合のプロセスか結果がテキストを適応させました、そして、単線における右から左への指向のテキストは双方向のディスプレイと呼ばれます。 <ユニコード>。
Most of the world's written languages are displayed left-to-right.
However, many widely-used written languages such as ones based on
the Hebrew or Arabic scripts are displayed right-to-left. Right-
to-left text often confuses protocol writers because they have to
keep thinking in terms of the order of characters in a string in
memory, and that order might be different than what they see on
the screen. (Note that some languages are written both
horizontally and vertically.)
世界の文語の大部分は、表示された左から右です。 しかしながら、ヘブライの、または、アラビアの文字に基づくものなどの広く使用された多くの文語が、表示された右から左です。 彼らがメモリのストリングにおける、キャラクタの注文で思い続けなければならないので、正しい左のテキストはプロトコル作家をしばしば混乱させます、そして、そのオーダーは彼らがスクリーンで見るものと異なっているかもしれません。 (いくつかの言語が水平に垂直に書かれていることに注意してください。)
Further, bidirectional text can cause confusion because there are
formatting characters in ISO/IEC 10646 which cause the order of
display of text to change. These explicit formatting characters
change the display regardless of the implicit left-to-right or
right-to-left properties of characters.
さらに、テキストのディスプレイが変化する命令を引き起こすISO/IEC10646には形式キャラクタがあるので、双方向のテキストは混乱を引き起こす場合があります。 これらの明白な形式キャラクタは右から暗黙の左から右か左へのキャラクタの特性にかかわらずディスプレイを変えます。
Hoffman Informational [Page 18] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[18ページ]のRFC3536Terminology
It is common to see strings with text in both directions, such as
strings that include both text and numbers, or strings that
contain a mixture of scripts.
両方の方向にテキストがあるストリングを見るのは一般的です、テキストと数の両方を含んでいるストリング、またはスクリプトの混合物を含むストリングなどのように。
[UNICODE] has a long and incredibly detailed algorithm for
displaying bidirectional text.
[ユニコード]には、双方向のテキストを表示するための長くて信じられないほど詳細なアルゴリズムがあります。
undisplayable character
表示できないキャラクタ
A character that has no displayable form. <NONE>
「ディスプレイ-可能」が全く形成させられないキャラクタ。 <、>のいずれも
For instance, the zero-width space (U+200B) cannot be displayed
because it takes up no horizontal space. Formatting characters
such as those for setting the direction of text are also
undisplayable. Note, however, that every character in [UNICODE]
has a glyph associated with it, and that the glyphs for
undisplayable characters are enclosed in a dashed square as an
indication that the actual character is undisplayable.
例えば、どんな水平なスペースも取らないので、ゼロ幅スペース(U+200B)を表示できません。 また、テキストの方向を設定するためのそれらなどの形式キャラクタも表示できないです。 しかしながら、[ユニコード]によるすべてのキャラクタがそれに関連しているglyphを持って、表示できないキャラクタのためのglyphsが実際のキャラクタが表示できないという指示として投げつけられた正方形で同封されることに注意してください。
6. Text in current IETF protocols
6. 現在のIETFプロトコルのテキスト
Many IETF protocols started off being fully internationalized, while others have been internationalized as they were revised. In this process, IETF members have seen patterns in the way that many protocols use text. This section describes some specific protocol interactions with text.
完全に国際化していて、多くのIETFプロトコルが始められましたが、自分達が改訂されたとき、他のものは国際的にされました。 このプロセスでは、IETFメンバーは多くのプロトコルがテキストを使用する方法でパターンを見ました。 このセクションはテキストとのいくつかの特定のプロトコル相互作用について説明します。
protocol elements
プロトコル要素
Protocol elements are uniquely-named parts of a protocol. <NONE>
プロトコル要素はプロトコルの唯一命名された部分です。 <、>のいずれも
Almost every protocol has named elements, such as "source port" in
TCP. In some protocols, the names of the elements (or text tokens
for the names) are transmitted within the protocol. For example,
in SMTP and numerous other IETF protocols, the names of the verbs
are part of the command stream. The names are thus part of the
protocol standard. The names of protocol elements are not
normally seen by end users.
ほとんどあらゆるプロトコルがTCPの「ソースポート」などの要素を命名しました。 いくつかのプロトコルで、要素(または、名前のためのテキストトークン)の名前はプロトコルの中で伝えられます。 例えば、SMTPと他の多数のIETFプロトコルでは、動詞の名前はコマンドストリームの一部です。 その結果、名前はプロトコル標準の一部です。 通常、プロトコル要素の名前はエンドユーザによって見られません。
name spaces
名前空間
A name space is the set of valid names for a particular item, or
the syntactic rules for generating these valid names. <NONE>
名前スペースは、特定の項目のための妥当な名前のセット、またはこれらが妥当な名前であると生成するための構文の規則です。 <、>のいずれも
Hoffman Informational [Page 19] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[19ページ]のRFC3536Terminology
Many items in Internet protocols use names to identify specific
instances or values. The names may be generated (by some
prescribed rules), registered centrally (e.g., such as with
IANA), or have a distributed registration and control mechanism,
such as the names in the DNS.
インターネットプロトコルの多くの項目が、特定のインスタンスか値を特定するのに名前を使用します。 名前には、生成されるか(規則が定められたいくつかで)、中心に登録するか(例えばIANAなどのように)、または分配された登録と制御機構があるかもしれません、DNSの名前などのように。
on-the-wire encoding
ワイヤの上のコード化
The encoding and decoding used before and after transmission over
the network is often called the "on-the-wire" (or sometimes just
"wire") format. <NONE>
以前、ネットワークの上のトランスミッションがしばしば「ワイヤ」の(または、まさしく時々「ワイヤ」)形式と呼ばれた後に使用されるコード化と解読。 <、>のいずれも
Characters are identified by codepoints. Before being transmitted
in a protocol, they must first be encoded as bits and octets.
Similarly, when characters are received in a transmission, they
have been encoded, and a protocol that needs to process the
individual characters needs to decode them before processing.
キャラクターはcodepointsによって特定されます。 プロトコルで伝えられる前に、最初に、ビットと八重奏としてそれらをコード化しなければなりません。 トランスミッションでキャラクタを受け取るとき、同様に、彼らをコード化しました、そして、個性を処理する必要があるプロトコルは処理の前にそれらを解読する必要があります。
parsed text
分析されたテキスト
Text strings that is analyzed for subparts. <NONE>
下位区分のために分析されるテキスト文字列。 <、>のいずれも
In some protocols, free text in text fields might be parsed. For
example, many mail user agents will parse the words in the text of
the Subject: field to attempt to thread based on what appears
after the "Re:" prefix.
いくつかのプロトコルでは、テキストフィールドの無料のテキストは分析されるかもしれません。 例えば、多くのメールユーザエージェントがSubject:のテキストの単語を分析するでしょう。 「Re:」の後に現れることに基づいて縫うように通るのを試みる分野 前に置きます。
charset identification
charset識別
Specification of the charset used for a string of text. <NONE>
テキストのストリングに使用されるcharsetの仕様。 <、>のいずれも
Protocols that allow more than one charset to be used in the same
place should require that the text be identified with the
appropriate charset. Without this identification, a program
looking at the text cannot definitively discern the charset of the
text. Charset identification is also called "charset tagging".
1charsetが同じ箇所に使用されるのを許容するプロトコルは、テキストが適切なcharsetと同一視されているのを必要とするべきです。 この識別がなければ、テキストを見るプログラムはテキストのcharsetについて決定的に明察できません。 また、Charset識別は「charsetタグ付け」と呼ばれます。
language identification
言語識別
Specification of the human language used for a string of text.
<NONE>
テキストのストリングに使用される人間の言語の仕様。 <、>のいずれも
Some protocols (such as MIME and HTTP) allow text that is meant
for machine processing to be identified with the language used in
the text. Such identification is important for machine-processing
of the text, such as by systems that render the text by speaking
it. Language identification is also called "language tagging".
いくつかのプロトコル(MIMEやHTTPなどの)がマシン処理がテキストで使用される言語と同一視されることになっているテキストを許容します。 テキストのそれを話すことによってテキストを表すシステムなどのマシン処理に、そのような識別は重要です。 また、言語識別は「言語タグ付け」と呼ばれます。
Hoffman Informational [Page 20] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[20ページ]のRFC3536Terminology
MIME
MIME
MIME (Multipurpose Internet Mail Extensions) is a message format
that allows for textual message bodies and headers in character
sets other than US-ASCII in formats that require ASCII (most
notably, [RFC2822], the standard for Internet mail headers). MIME
is described in RFCs 2045 through 2049, as well as more recent
RFCs. <NONE>
MIME(マルチパーパスインターネットメールエクステンション)はASCIIを必要とする形式における米国-ASCIIを除いた文字集合で原文のメッセージ本体とヘッダーを考慮するメッセージ・フォーマット(最も著しく、[RFC2822]、インターネットの規格はヘッダーに郵送する)です。 MIMEは、より最近のRFCsと同様に2049を通してRFCs2045で説明されます。 <、>のいずれも
transfer encoding syntax
構文をコード化しながら、移してください。
A transfer encoding syntax (TES) (sometimes called a transfer
encoding scheme) is a reversible transform of already-encoded data
that is represented in one or more character encoding schemes.
<NONE>
構文(TES)(時々体系をコード化する転送と呼ばれます)をコード化する転送は1つ以上の文字符号化体系で表される既にコード化されたデータのリバーシブルの変換です。 <、>のいずれも
TESs are useful for encoding types of character data into an
another format, usually for allowing new types of data to be
transmitted over legacy protocols. The main examples of TESs used
in the IETF include Base64 and quoted-printable.
キャラクタデータのタイプをコード化する、TESsが役に立つ通常、新しいタイプに関するデータがレガシープロトコルの上に送られるのを許容するための別の形式。 TESsのIETFインクルードBase64で中古の、そして、引用されて印刷可能な主な例。
Base64
Base64
Base64 is a transfer encoding syntax that allows binary data to be
represented by the ASCII characters A through Z, a through z, 0
through 9, +, /, and =. It is defined in [RFC2045]. <NONE>
Base64はバイナリ・データがZ、aからz、0〜9、+、/、および=を通してASCII文字Aによって表されるのを許容する構文をコード化する転送です。それは[RFC2045]で定義されます。 <、>のいずれも
quoted printable
引用、印刷可能
Quoted printable is a transfer encoding syntax that allows strings
that have non-ASCII characters mixed in with mostly ASCII
printable characters to be somewhat human readable. It is
described in [RFC2047]. <NONE>
引用されて、印刷可能であるのは、いくらか人間であるためにほとんどASCIIの印刷可能なキャラクタに複雑である非ASCII文字を読み込み可能にするストリングを許容する構文をコード化する転送です。 それは[RFC2047]で説明されます。 <、>のいずれも
The quoted printable syntax is generally considered to be a
failure at being readable. It is jokingly referred to as "quoted
unreadable".
一般に、引用された印刷可能な構文は読み込み可能であるところの失敗であると考えられます。 「読みにくい状態で、引用されます」のように言及されて、それはふざけてそうです。
XML
XML
XML (which is an approximate abbreviation for Extensible Markup
Language) is a popular method for structuring text. XML text is
explicitly tagged with charsets. The specification for XML can be
found at <http://www.w3.org/XML/>. <NONE>
XML(拡張マークアップ言語のための大体の略語である)は、テキストを構造化するためのポピュラーなメソッドです。 XMLテキストはcharsetsで明らかにタグ付けをされます。 <http://www.w3.org/XML/><NONE>でXMLのための仕様を見つけることができます。
Hoffman Informational [Page 21] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[21ページ]のRFC3536Terminology
ASN.1 text formats
ASN.1テキスト形式
The ASN.1 data description language has many formats for text
data. The formats allow for different repertoires and different
encodings. Some of the formats that appear in IETF standards
based on ASN.1 include IA5String (all ASCII characters),
PrintableString (most ASCII characters, but missing many
punctuation characters), BMPString (characters from ISO/IEC 10646
plane 0 in UTF-16BE format), UTF8String (just as the name
implies), and TeletexString (also called T61String; the repertoire
changes over time).
ASN.1データ記述言語には、テキストデータのための多くの形式があります。 形式は異なったレパートリーと異なったencodingsを考慮します。 ASN.1に基づくIETF規格に現れる形式のいくつかがIA5String(すべてのASCII文字)、PrintableString(しかし、ほとんどのASCII文字、取り逃がす多くの句読文字)、BMPString(UTF-16BE形式におけるISO/IEC10646飛行機0からのキャラクタ)、UTF8String(ちょうど名前が含意するように)、およびTeletexString(また、呼ばれたT61String; 時間がたつにつれてのレパートリー変化)を含んでいます。
ASCII-compatible encoding (ACE)
ASCIIコンパチブルコード化(ACE)
Starting in 1996, many ASCII-compatible encoding schemes (which
are actually transfer encoding syntaxes) have been proposed as
possible solutions for internationalizing host names. Their goal
is to be able to encode any string of ISO/IEC 10646 characters as
legal DNS host names (as described in STD 13). At the time of
this writing, no ACE has become an IETF standard.
1996年から、多くのASCIIコンパチブルコード化計画(実際に構文をコード化する転送である)がホスト名を国際的にする可能な解決策として提案されました。 それらの目標は法的なDNSが名前をホスティングするとき(STD13で説明されるように)ISO/IEC10646のキャラクタのどんなストリングもコード化することであることができます。 この書くこと時点で、ACEは全くIETF規格になっていません。
7. Other Common Terms In Internationalization
7. 国際化における他の一般的な用語
This is a hodge-podge of other terms that have appeared in internationalization discussions in the IETF. It is likely that additional terms will be added as this document matures.
これはIETFでの国際化議論に現れた他の用語の寄せ集めです。 このドキュメントが熟すとき、追加用語は加えられそうでしょう。
locale
現場
Locale is the user-specific location and cultural information
managed by a computer. <NONE>
現場は、コンピュータによって管理されたユーザ特有の位置と文化的な情報です。 <、>のいずれも
Because languages differ from country to country (and even region
to region within a country), the locale of the user can often be
an important factor. Typically, the locale information for a user
includes the language(s) used.
言語が国から国(そして、国の中の領域への領域さえ)まで異なるので、しばしばユーザの現場は重要な要素であるかもしれません。 通常、ユーザへの現場情報は(s)が使用した言語を含んでいます。
Locale issues go beyond character use, and can include things such
as the display format for currency, dates, and times. Some
locales (especially the popular "C" and "POSIX" locales) do not
include language information.
現場問題は、キャラクタ使用を越えて、通貨、日付、および何倍もシステム出力表示形式などのものを含むことができます。 いくつかの現場(特にポピュラーな「C」と"POSIX"現場)は言語情報を含んでいません。
It should be noted that there are many thorny, unsolved issues
with locale. For example, should text be viewed using the locale
information of the person who wrote the text or the person viewing
it? What if the person viewing it is travelling to different
locations? Should only some of the locale information affect
creation and editing of text?
現場には多くのとげがあって、未解決の問題があることに注意されるべきです。 例えば、テキストは、テキストを書いた人かそれを見ている人の現場情報を使用することで見られるべきですか? それを見ている人が別の場所に旅行していると、どうなるでしょうか? 現場情報のいくつかだけがテキストの創造と編集に影響するべきですか?
Hoffman Informational [Page 22] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[22ページ]のRFC3536Terminology
Latin characters
ラテン語のキャラクタ
"Latin characters" is a not-precise term for characters
historically related to ancient Greek script and currently used
throughout the world. <NONE>
「ラテン語のキャラクタ」は古代ギリシャ語スクリプトに歴史的に関連して、現在世界中で使用されているキャラクタへの正確でない用語です。 <、>のいずれも
The base Latin characters make up the ASCII repertoire and have
been augmented by many single and multiple diacritics and quite a
few other characters. ISO/IEC 10646 encodes the Latin characters
in the ranges U+0020..U+024F, U+1E00..U+1EFF, and other ranges.
ベースラテン語キャラクタを、ASCIIレパートリーを作って、多くの単一で複数の区別的発音符と他のかなり多くのキャラクタが増大させました。 ISO/IEC10646は範囲Uで+0020にラテン語のキャラクタをコード化します。U+024Fと、U+1 00ユーロ。U+1EFF、および他の範囲。
romanization
ローマ字化したもの
The transliteration of a non-Latin script into Latin characters.
<NONE>
ラテン語のキャラクタへの非ラテンスクリプトの音訳。 <、>のいずれも
Because of the widespread use of Latin characters, people have
tried to represent many languages that are not based on a Latin
repertoire in Latin. For example, there are two popular
romanizations of Chinese: Wade-Giles and Pinyin, the latter of
which is by far more common today. Many romanization systems are
inexact and do not give perfect round trip mappings between the
native script and the Latin characters.
ラテン語のキャラクタの普及使用のために、人々はラテン語でラテン語のレパートリーに基づいていない多くの言語を表そうとしました。 例えば、中国語の2つのポピュラーなローマ字化したものがあります: それのウェイド-ジャイルスとピンイン、後者は今日、断然一般的です。 多くのローマ字化したものシステムは、不正確であり、固有のスクリプトとラテン語のキャラクタの間に完全な周遊旅行マッピングを与えません。
CJK characters and Han characters
CJK文字とハンキャラクタ
The ideographic characters used in Chinese, Japanese, Korean, and
traditional Vietnamese writing systems are often called 'CJK
characters' after the initial letters of the language names in
English. They are also called "Han characters", after the term in
Chinese that is often used for these characters. <NONE>
中国的、そして、日本的、そして、韓国的、そして、伝統的なベトナムの書記体系で使用される表意文字のキャラクタは言語名に関する大文字の後に英語でしばしば'CJK文字'と呼ばれます。 また、それらはこれらのキャラクタにしばしば使用される中国語の用語の後に「ハンキャラクタ」と呼ばれます。 <、>のいずれも
Note that CJK and Han characters do not include the phonetic
characters used in the Japanese and Korean languages.
CJKとハンキャラクタが日本の、そして、韓国の言語で使用される音声のキャラクタを入れないことに注意してください。
In ISO/IEC 10646, the Han characters were "unified", meaning that
each set of Han characters from Japanese, Chinese, and/or Korean
that had the same origin was assigned a single code point. The
positive result of this was that many fewer code points were
needed to represent Han; the negative result of this was that
characters that people who write the three languages think are
different have the same code point. There is a great deal of
disagreement on the nature, the origin, and the severity of the
problems caused by Han unification.
ISO/IEC10646では、ハンキャラクタは「統一されました」、1コード・ポイントが同じ起源を持っていた日本語、中国語、そして/または、韓国語からのそれぞれのセットのハンキャラクタに割り当てられたことを意味して。 この肯定的な結果は多くの、より少ないコード・ポイントがハンの代理をするのに必要であったということでした。 この否定的結果は3つの言語を書く人々が異なると考えるキャラクタには同じコード・ポイントがあるということでした。 多くの不一致が漢字統合で引き起こされた問題の自然、起源、および厳しさにあります。
Hoffman Informational [Page 23] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[23ページ]のRFC3536Terminology
translation
翻訳
The process of conveying the meaning of some passage of text in
one language, so that it can be expressed equivalently in another
language. <NONE>
別の言語で同等にそれを言い表すことができるように1つの言語のテキストのいくらかの通路の意味を伝える過程。 <、>のいずれも
Many language translation systems are inexact and cannot be
applied repeatedly to go from one language to another to another.
多くの言語翻訳システムは、不正確であり、1つの言語から別の言語まで別のものに行くために繰り返して適用できません。
transliteration
音訳
The process of representing the characters of an alphabetical or
syllabic system of writing by the characters of a conversion
alphabet. <NONE>
変換アルファベットのキャラクタで書くアルファベット順の、または、音節のシステムのキャラクタの代理をする過程。 <、>のいずれも
Many script transliterations are exact, and many have perfect
round-trip mappings. The notable exception to this is
romanization, described above. Transliteration involves
converting text expressed in one script into another script,
generally on a letter-by-letter basis.
多くのスクリプト音訳が正確です、そして、多くには、完全な往復のマッピングがあります。 これへの注目に値する例外は上で説明されたローマ字化したものです。 音訳は、一般に手紙による手紙ベースで1つのスクリプトで言い表されたテキストを別のスクリプトに変換することを伴います。
transcription
転写
The process of systematically writing the sounds of some passage
of spoken language, generally with the use of a technical phonetic
alphabet (usually Latin-based) or other systematic transcriptional
orthography. Transcription also sometimes refers to the
conversion of written text into a transcribed (usually Latin-
based) form, based on the sound of the text as if it had been
spoken. <NONE>
系統的に話し言葉と、一般に、技術的な音標文字の使用が(通常ラテン語ベース)か他でのいくらかの通路の音に系統的なtranscriptional綴り字法を書く過程。 また、転写は時々まるでそれが話されたかのようにテキストの音に基づく転写された(通常基づくラテン語)フォームと書かれたテキストの変換を呼びます。 <、>のいずれも
Unlike transliterations, which are generally designed to be
round-trip convertible, transcriptions of written material are
almost never round-trip convertible to their original form.
音訳と異なって、資料の転写はそれらの原型へのほとんどの往復でないオープンカーです。一般に、音訳は、往復のオープンカーになるように設計されています。
regular expressions
正規表現
Regular expressions provide a mechanism to select specific strings
from a set of character strings. Regular expressions are a
language used to search for text within strings, and possibly
modify the text found with other text. <NONE>
正規表現は、1セットの文字列から特定のストリングを選択するためにメカニズムを提供します。 正規表現は、ストリングの中にテキストを捜し求めるのに使用される言語であり、ことによると他のテキストで見つけられたテキストを変更します。 <、>のいずれも
Pattern matching for text involves being able to represent one or
more code points in an abstract notation, such as searching for
all capital Latin letters or all punctuation. The most common
mechanism in IETF protocols for naming such patterns is the use of
regular expressions. There is no single regular expression
language, but there are numerous very similar dialects.
テキストが1を表すことができるか、以上にかかわるので、パターン・マッチングは抽象的な記法でポイントをコード化します、すべての資本のラテン語の手紙かすべての句読を検索するのなどように。 そのようなパターンを命名するためのIETFプロトコルで最も一般的なメカニズムは正規表現の使用です。 どんなただ一つの正規表現言語もありませんが、多数の非常に同様の方言があります。
Hoffman Informational [Page 24] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[24ページ]のRFC3536Terminology
The Unicode Consortium has a good discussion about how to adapt
regular expression engines to use Unicode. [UTR18]
ユニコードConsortiumはユニコードを使用するためにどう正規表現エンジンを適合させるかについての良い議論をします。 [UTR18]
private use
私用
ISO/IEC 10646 code points from U+E000 to U+F8FF, U+F0000 to
U+FFFFD, and U+100000 to U+10FFFD are available for private use.
This refers to code points of the standard whose interpretation is
not specified by the standard and whose use may be determined by
private agreement among cooperating users. <UNICODE>
コードが000U+EからU+F8FFまで指すISO/IEC10646、U+FFFFDへのU+F0000、およびU+10FFFDへのU+100000は私的使用目的で利用可能です。 これは解釈が規格によって指定されないで、使用が協力関係を持っているユーザの中で個人的な協定で決定するかもしれない規格のコード・ポイントを示します。 <ユニコード>。
The use of these "private use" characters is defined by the
parties who transmit and receive them, and is thus not appropriate
for standardization. (The IETF has a long history of private use
names for things such as "x-" names in MIME types, charsets, and
languages. The experience with these has been quite negative,
with many implementors assuming that private use names are in fact
public and long-lived.)
これらの「私用」キャラクタの使用は、彼らを送受信するパーティーによって定義されて、標準化には、その結果、適切ではありません。 (IETFには、MIMEの種類、charsets、および言語の「x」名などのもののための私用名の長い歴史があります。 これらの経験はかなり否定的です、多くの作成者が、私用名が事実上、公共であって、長命であると仮定していて。)
8. Security Considerations
8. セキュリティ問題
Security is not discussed in this document.
本書ではセキュリティについて議論しません。
9. References
9. 参照
9.1 Normative References
9.1 標準の参照
[ISOIEC10646] ISO/IEC 10646-1:2000. International Standard --
Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture and
Basic Multilingual Plane, 2000.
[ISOIEC10646]ISO/IEC10646-1:2000。 国際規格--情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部: 構造的、そして、基本的な多言語飛行機、2000。
[UNICODE] The Unicode Standard, Version 3.2.0 is defined by The
Unicode Standard, Version 3.0 (Reading, MA, Addison-
Wesley, 2000. ISBN 0-201-61633-5), as amended by the
Unicode Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the
Unicode Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/), The Unicode
Consortium, 2002.
[ユニコード]ユニコードStandard、バージョン、3.2、.0、ユニコードStandard、バージョン3.0(読書、MA、アディソン・ウエスリー、2000ISBN0-201-61633-5)で、ユニコードStandard Annex#27によって修正されるように、定義されます: ( http://www.unicode.org/reports/tr27/ )とユニコード規格別館#28によるユニコード3.1: ユニコード3.2( http://www.unicode.org/reports/tr28/ )、ユニコード共同体、2002。
Hoffman Informational [Page 25] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[25ページ]のRFC3536Terminology
9.2 Informative References
9.2 有益な参照
[CHARMOD] Character Model for the World Wide Web 1.0, W3C,
<http://www.w3.org/TR/charmod/>.
WWW1.0のための[CHARMOD]キャラクターモデル、W3C、<http://www.w3.org/TR/charmod/>。
[FRAMEWORK] ISO/IEC TR 11017:1997(E). Information technology -
Framework for internationalization, prepared by ISO/IEC
JTC 1/SC 22/WG 20, 1997.
[枠組み] ISO/IEC TR11017: 1997(E)。 情報技術--ISO/IEC JTC1/サウスカロライナ22/WG20、1997年までに準備された国際化のための枠組み。
[ISO 639] ISO 639:2000 (E/F) - Code for the representation of
names of languages, 2000.
[ISO639]ISO、639:2000 (E/F)--言語、2000年の名前の表現のためのコード。
[ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of
names of countries, 2000.
[ISO3166]ISO、3166:1988 (E/F)--国、2000年の名前の表現のためのコード。
[RFC2045] Freed, N. and N. Borenstein, "MIME Part One: Format of
Internet Message Bodies", November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「パート1をまねてください」 1996年11月の「インターネットメッセージ本体の形式。」
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions
for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、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。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
[RFC2781]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986, 1986.
[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986、1986。
[UTN6] "BOCU-1: MIME-Compatible Unicode Compression", M.
Scherer & M. Davis, Unicode Technical Note #6.
[UTN6]、「BOCU-1:」 「MIMEコンパチブルユニコード圧縮」、M.シェーラーとM.デイヴィス、ユニコードテクニカルノート#6。
[UTR6] "A Standard Compression Scheme for Unicode", M. Wolf,
et. al., Unicode Technical Report #6.
[UTR6] et「ユニコードの標準の圧縮技術」、M.ヴォルフ、アル、ユニコードTechnical Report#6
[UTR15] "Unicode Normalization Forms", M. Davis & M. Duerst,
Unicode Technical Report #15.
[UTR15]「ユニコード正常化フォーム」、M.デイヴィス、およびM.Duerst、ユニコード技術報告書#15。
Hoffman Informational [Page 26] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[26ページ]のRFC3536Terminology
[UTR18] "Unicode Regular Expression Guidelines", M. Davis,
Unicode Technical Report #18.
[UTR18]「ユニコード正規表現ガイドライン」、M.デイヴィス、ユニコード技術報告書#18。
[UTR19] "UTF-32", M. Davis, Unicode Technical Report #19.
[UTR19] 「UTF-32インチ、M.デイヴィス、ユニコード技術報告書#19。」
[UTR22] "Character Mapping Markup Language", M. Davis, Unicode
Technical Report #22.
[UTR22]「キャラクターマッピングマークアップ言語」、M.デイヴィス、ユニコード技術報告書#22。
10. Additional Interesting Reading
10. 追加おもしろい読書
ALA-LC Romanization Tables, Randall Barry (ed.), U.S. Library of Congress, 1997, ISBN 0844409405
ALA-LCローマ化テーブル、ランドルのバリトンサックス編、米国議会図書館、1997、ISBN0844409405
Blackwell Encyclopedia of Writing Systems, Florian Coulmas, Blackwell Publishers, 1999, ISBN 063121481X
システム、フローリアンクルマスにブラックウェル出版社を書くブラックウェルEncyclopedia、1999、ISBN 063121481X
The World's Writing Systems, Peter Daniels and William Bright, Oxford University Press, 1996, ISBN 0195079930
世界が明るくシステム、ピーター・ダニエル、およびウィリアムに書くオックスフォード大学出版局、1996、ISBN0195079930
Writing Systems of the World, Akira Nakanishi, Charles E. Tuttle Company, 1980, ISBN 0804816549
世界、Akira中西、チャールズE.タトル社、1980、ISBN0804816549の書記体系
11. Index
11. インデックス
alphabetic -- 4.1 ASCII-compatible encoding (ACE) -- 6 ASN.1 text formats -- 6 Base64 -- 6 Basic Multilingual Plane (BMP) -- 3.2 bidirectional display -- 5 BOCU-1 -- 3.2 case -- 4 character -- 2 character encoding form -- 2 character encoding scheme -- 2 charset -- 2 charset identification -- 6 CJK characters and Han characters -- 7 code chart -- 4 code table -- 4 coded character -- 2 coded character set -- 2 combining character -- 4 compatibility character -- 4.1 composite sequence -- 4 control character -- 4.1 diacritic -- 4.1 displaying and rendering text -- 2
アルファベット((ACE)をコード化するASCIIコンパチブル4.1)の6ASN.1テキスト形式--6Base64--6 基本多言語水準(BMP)--3.2 双方向の表示--5BOCU-1--3.2ケース--4キャラクタ--2 フォームをコード化するキャラクタ; 2 計画をコード化するキャラクタ--2charset--2charset識別--6人のCJK文字とハンキャラクタ--7コード図--4コードテーブル--4はキャラクタ--2コード化文字集合--2の結合したキャラクタ--4互換性キャラクタ--4.1にコンポジット・シーケンス--4制御文字--4.1区別的発音符--4.1の表示と表現テキスト--2をコード化しました。
Hoffman Informational [Page 27] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[27ページ]のRFC3536Terminology
font -- 5 formatting character -- 4.1 glyph -- 2 glyph code -- 2 graphic symbol -- 5 i18n, l10n -- 2 ideographic -- 4.1 input methods -- 5 internationalization -- 2 ISO -- 3.1 language -- 2 language identification -- 6 Latin characters -- 7 local and regional standards organizations -- 3.1 locale -- 7 localization -- 2 MIME -- 6 multilingual -- 2 name spaces -- 6 nonspacing character -- 4.1 normalization -- 4 on-the-wire encoding -- 6 parsed text -- 6 private use -- 7 protocol elements -- 6 punctuation -- 4.1 quoted printable -- 6 regular expressions -- 7 rendering rules -- 5 romanization -- 7 script -- 2 SCSU -- 3.2 sorting and collation -- 4 symbol -- 4.1 transcoding -- 2 transcription -- 7 transfer encoding syntax -- 6 translation -- 7 transliteration -- 7 UCS-2 and UCS-4 -- 3.2 undisplayable character -- 5 Unicode Consortium -- 3.1 UTF-32 -- 3.2 UTF-16, UTF-16BE, and UTF-16LE -- 3.2 UTF-8 -- 3.2 World Wide Web Consortium -- 3.1 XML -- 6
字体--5 形式キャラクタ--4.1glyph--2 glyphコード--2図形--5i18n、l10n--2 表意文字(4.1の入力方法)の5国際化--2ISO; 3.1 言語--2言語識別--6つのラテン語のキャラクタ--7 地方の、そして、地方の規格組織--3.1現場--7ローカライズ--2MIME--6 多言語(2つの名前空間)の6「非-区切」っているキャラクタ; 4.1 正常化--4 ワイヤの上のコード化--6 分析されたテキスト--6私用--4.1が引用した印刷可能な7個のプロトコル要素(6句読)--6つの正規表現--7 表現は統治されます--5ローマ字化したもの; 7 スクリプト--2SCSU--6構文--翻訳--7音訳--7UCS-2とUCS-4--3.2の表示できないキャラクタ--5ユニコードConsortium--3.1UTF-32--3.2UTF-16、UTF-16BE、およびUTF-16LE--3.2UTF-8--3.2WWW Consortium--3.1XML--6をコード化するソーティングと照合--4シンボル--4.1コード変換--2転写--7が移す3.2
Hoffman Informational [Page 28] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[28ページ]のRFC3536Terminology
A. Acknowledgements
A。 承認
The definitions in this document come from many sources, including a wide variety of IETF documents.
定義はさまざまなIETFドキュメントを含む多くのソースから本書では来ます。
James Seng contributed to the initial outline of this document. Harald Alvestrand and Martin Duerst made extensive useful comments on early versions. Others who contributed to the development include:
ジェームスSengはこのドキュメントに関する原形線に貢献しました。 ハラルドAlvestrandとマーチンDuerstは早めのバージョンの大規模な役に立つコメントをしました。 開発に貢献した他のものは:
Dan Kohn
Jacob Palme
Johan van Wingen
Peter Constable
Yuri Demchenko
Susan Harris
Zita Wenzel
John Klensin
Henning Schulzrinne
Leslie Daigle
Markus Scherer
Ken Whistler
ダンコーンヤコブパルメジョハンバンWingenピーターコンスタブルユリDemchenkoスーザンハリスZitaウェンツェルジョンKlensinヘニングSchulzrinneレスリーDaigleマーカスシェーラーケンウィスラー
B. Author's Address
B。 作者のアドレス
Paul Hoffman Internet Mail Consortium and VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンインターネットメール共同体とVPN共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
メール: paul.hoffman@imc.org とpaul.hoffman@vpnc.org
Hoffman Informational [Page 29] RFC 3536 Terminology Used in Internationalization in the IETF May 2003
2003年5月にIETFでの国際化に使用されたホフマン情報[29ページ]のRFC3536Terminology
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hoffman Informational [Page 30]
ホフマンInformationalです。[30ページ]
一覧
スポンサーリンク
