Network Working Group P. Hoffman
Request for Comments: 3536 IMC & VPNC
Category: Informational May 2003
Terminology Used in Internationalization in the IETF
Status of this 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.
著作権（C）インターネット協会（2003）。全著作権所有。
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
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使用テキスト文字列全体に多くのプロトコル。誰もがこれらのテキスト文字列を入力するか、読みすることは、インターネットユーザーは、標準的な入力方法でテキストを入力し、任意の人間の言語で表示することができなければならないことを意味し、可能でなければなりません。さらに、任意の文字を含むテキストを簡単にインターネットアプリケーション間で渡されることができるはずです。これは、国際化の課題です。
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 / IEC 10646 [ISOIEC10646]
- The Unicode Standard [UNICODE]
- Unicode標準[UNICODE]
- W3C Character Model [CHARMOD]
- W3Cキャラクターモデル[CHARMOD]
- IETF RFCs, including [RFC2277]
- [RFC2277]を含むIETFのRFC、
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>」のように、角括弧で示されています。多くの定義は、定義がこの文書のために元々作られたことを意味し、「<NONE>」として表示されます。定義のソースのアングルブラケット表記は、上の段落のようにドキュメントへの参照に使用される角括弧表記法とは異なります。これらの文献は、第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".
この文書に記載されている例は、Unicode標準[UNICODE]およびISO / IEC 10646 [ISOIEC10646]のコードポイントと名の表記を使用します。例えば、文字「は」「U + 0061」又は「ラテン小文字A」のいずれかとして表すことができます。
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.
このセクションでは、非ASCIIテキストへのIETFプロトコルは、より親しみやすい作りとし、国際化の他の側面に関与しているほとんど誰のために必要とされる基本的なトピックをカバーしています。
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>
言語は人間が対話する方法です。言語の使用は、音声、書き込み、および署名されている最も一般的なものは、多くの形で発生します。 <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>
一の以上の言語の表記に使用するグラフィック文字のセット。 <ISOIEC10646>
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.
国際初心者は用語「言語」と「スクリプト」をアップミックスするのが一般的です。これは、二つを区別するプロトコルで問題になることができます。少数の実際の言語を扱う一方で、スクリプト（書かれたシステム）または文字で非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.
単一の名前は、言語やスクリプトのいずれかを意味することができます。例えば、「アラビア語は、」言語の名前とスクリプトの名前でもあります。実際には、多くのスクリプトは、言語の名前から自分の名前を借りて。さらに、多くのスクリプトは、多くの言語のために使用されています。例えば、ロシア語、ブルガリア語はキリル文字で書かれています。一部の言語では異なるスクリプトを使用して表現することができます。モンゴル語のいずれかモンゴルとキリルスクリプトで記述することができ、そしてセルビア・クロアチア語はラテン語とキリルスクリプトの両方を使用して書かれています。さらに、いくつかの言語は、通常、同時に複数のスクリプトを使用して表現されます。例えば、日本語の言語は、通常のテキストの単一の列に漢字（漢）、カタカナ、ひらがな、およびスクリプトで表現されます。
character
キャラクター
A member of a set of elements used for the organization, control, or representation of data. <ISOIEC10646>
組織のために使用される要素の集合のメンバー、制御、又はデータの表現。 <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.
人々は文字について話すとき、彼らは主に最初の二つの定義のいずれかを使用しています。
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 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>
一緒にその符号化表現を持つ文字。 <ISO IEC 10646>
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）は、文字セットとセットの文字とその符号化表現との間の関係を確立する明確な規則のセットです。 <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>
文字エンコード形式は、データを表すために使用される実際のコード単位に文字セットの定義からマッピングです。 <UNICODE>
repertoire
レパートリー
The collection of characters included in a character set. Also called a character repertoire. <UNICODE>
文字のコレクションは、文字セットに含まれています。また、文字レパートリと呼ばれます。 <UNICODE>
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>
グリフは、一つ以上のグリフ画像を表す抽象形態です。用語「グリフ」は、しばしばグリフ表現ラスタライズまたはそうでなければ、いくつかの表示面上に結像された実際の、具体的な画像であるグリフ画像、同義語です。文字データを表示する際に、一つ以上のグリフは、特定の文字を描くように選択することができます。これらのグリフは、組成物及びレイアウト処理中に、レンダリングエンジンによって選択されます。 <UNICODE>
glyph code
グリフコード
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>
グリフコードがグリフを意味する数値コードです。通常、フォントに含まれるグリフは、そのグリフコードによって参照されています。グリフコードは、特定のフォントにローカルです。つまり、同一のグリフを含む異なるフォントが異なるコードを使用することができます。 <UNICODE>
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対多または多対多マッピング。一部のレガシーマッピングが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.
この定義では、「多対一」は、単一の文字にマッピングされた文字の配列を意味します。 「多くの」は、単一の文字にマップする代替文字を意味するものではありません。
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などのUnicodeには多くの文字符号化スキームは、あります。 <UNICODE>
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 2022などのISO / IEC 10646他CESS、にのみ適用され、多くのCCSSに関連付けられています。
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>
文字セットは、抽象文字の列にオクテットのシーケンスをマッピングする方法です。文字セットは、実際に、CESを有する1つ以上のCCSSの組み合わせです。文字セット名は、[RFC2278]に記載の手順に従って、IANAによって登録されています。 <NONE>
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.
多くのプロトコル定義は、その説明において、「文字セット」を使用します。用語「文字セット」または「文字セット」は他の文脈で他の定義を持っており、これが混乱することができますので、「文字コード体系が」強く用語「文字セット」よりも好まれます。
internationalization
国際化
In the IETF, "internationalization" means to add or improve the handling of non-ASCII text in a protocol. <NONE>
IETFでは、「国際化」プロトコルに非ASCIIテキストの取り扱いを追加したり、改善することを意味します。 <NONE>
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 (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.
（相互運用性の問題のために、当然のことながら、リード）テキストのみ（多くの場合、英語のテキストに使用される文字が含まれている1）1つのスクリプトを扱う扱う、またはローカル当て推量まで使用されているものの文字セットの問題を残して多くのプロトコル。そのようなプロトコルに非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
国際化、ローカライゼーション
These are abbreviations for "internationalization" and "localization". <NONE>
これらは、「国際化」と「ローカリゼーション」の略称です。 <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 characters; other definitions relate to the ability to handle multiple charsets; and still others relate to the ability to handle multiple languages. <NONE>
用語「多言語」は、多くの広く様々な定義がありますので、標準規格での使用は推奨されません。定義の一部は、国際文字を処理する能力に関係します。他の定義は、複数の文字セットを処理する能力に関係します。そして、まだ他の人が複数の言語を処理する能力に関係します。 <NONE>
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>
テキストを表示するために、システムは、スクリーンやプリンタなどの視覚表示装置に文字を置きます。テキストを描画するために、システムは、テキストを表示する方法を決定するために文字入力を分析します。用語「ディスプレイ」と時々交換可能に使用される「レンダリング」。注意は、しかし、そのテキストは、視覚障害を持つ人々のために設計されたシステムのようなオーディオおよび/または触覚出力、としてレンダリングされる可能性があります。 <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.
文字を組み合わせることで、それらの前の文字（または、いくつかのケースでは、文字）の表示を変更します。そのようなテキストをレンダリングすると、ディスプレイエンジンは、基本文字と結合文字のすべてを表しているフォントにグリフを見つけなければならないか、それは組み合わせ自体をレンダリングする必要があります。このようなレンダリングはストレートフォワードすることができますが、組み合わせたマークは、そのような同じ文字の上に表示されます2組み合わせた跡がある場合など、互いに相互作用するとき、それは時々複雑です。フォーマット文字もレンダラーがテキストを表示するような方法を変更することができます。レンダリングはまた、アラビア語やインド語スクリプトなどの基本文字、のための複雑な表示ルールを持っているいくつかのスクリプトのために困難な場合があります。
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標準化作業に一般的に表示されます。
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 more qualifications. (The IEC is International Electrotechnical Commission). ISO/IEC 10646 describes a CCS that covers almost all known written characters in use today.
国際標準化機構は、IETFが開始された前以降の文字を基準に携わってきました。 ISOは、国家機関で構成された非政府グループです。 ISOは、国際文字領域に多くの多様な基準を持っています。その正式名称は、より多くの資格を有しているが、ほとんどのIETFで使用されている1は、一般的に、「ISO / IEC 10646」と呼ばれています。 （IECは、国際電気標準会議）です。 ISO / IEC 10646は、今日使用されているほとんどすべての既知の書かれた文字をカバーしてい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 / IEC 10646は、多くの場合、略して "WG2" と呼ばれる "ISO / IEC JTC 1 / SC 2 WG2" として知られているグループによって制御されます。 ISO規格は、完成される前に多くのステップを経ると、年は、多くの場合、WG2にISO / IEC 10646情報の変更、およびその作業成果物の間で行く、<http://www.dkuug.dk/JTC1/SC2で見つけることができます/ 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版の両方で購入することができます。標準を引用する方法の一例は、[RFC2279]で与えられています。 ISO / IEC 10646を引用している任意の標準的なプロトコルのニーズに関連するバージョン管理の問題をどのように処理するかを評価する必要があります。
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は、プロトコルの開発者を対象とあるかもしれない他の規格を担当しています。 [ISO 639]は言語の名前を指定し、[ISO 3166]は国の略称を指定します。文字作業は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における国際化、責任あるJTC 1 / SC22 / WG20、です。 WG20の情報、およびその作業成果物は、<http://www.dkuug.dk/jtc1/sc22/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.
国際文字規格の第二の重要なグループは、Unicodeコンソーシアムです。ユニコードコンソーシアムは、企業、政府、およびUnicode標準[UNICODE]を促進する上で興味を持って他のグループの業界団体です。 Unicode標準は、そのレパートリーとコードポイントのISO / IEC 10646と同じユニコードコンソーシアムは、各文字の属性を定義するように、プロトコルにそれをより有用にするベースCCSへ機能を追加しましたれる。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/>.
ユニコードコンソーシアムは、UnicodeテクニカルレポートとしてUnicode標準に添加物を発行しています。成熟の様々な段階での技術報告書の多くの種類があります。 Unicode標準と提携して技術的なレポートは、<http://www.unicode.org/>で見つけることができます。
World Wide Web Consortium (W3C)
World Wide Webコンソーシアム（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と文字セットがあるのと同様に、多くの地方や地域の標準化団体は、それらを作成し、サポートすることがあります。これらの一般的な例としては、ANSI（米国）、およびCEN / ISSS（ヨーロッパ）です。
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 / IEC 10646 CCSの文字は、多くの方法で表現することができます。変換フォーマットはワイヤ上のビットとして符号化形態を発現させる方法であるが、符号化形態は、ダイレクトアドレッシング方法です。
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は、BMPはまた、「プレーン0」と呼ばれているISO / IEC 10646に第2 ^ 16コード・ポイントで構成されています。
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 / IEC 10646 UCS-2アドレスのみBMPために定義された2つの符号化形態です。 （例えば、多くの漢字など）多くの有用な文字がBMPの外で定義されているので、多くの人が死んでいるUCS-2を検討します。理論的には、UCS-4は、32ビット値としてISO / IEC 10646から2 ^ 31コード・ポイントの全範囲に対処します。しかし、UTF-16との相互運用性のために、ISO 10646は、実際の値の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つのオクテットとしてエンコードされています。彼らはUS-ASCIIでそうであるようにUS-ASCIIレパートリーからの文字はUTF-8で同じオン・ワイヤー表現を持ちます。
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、UTF-16BE、およびUTF-16LE、[RFC2781]で定義された3つの変換フォーマットは、任意のIETF規格で必要とされないので、UTF-8よりもはるかに少ない頻繁に使用されます。 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].
ユニコードコンソーシアムは、[UTR19]でUCS-4の変換フォーマットとしてUTF-32を定義しています。
SCSU and BOCU-1
SCSUとBOTTLE-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.
ユニコードコンソーシアムは、典型的なテキストのための良好な圧縮を提供するように設計されている符号化、SCSUを定義しています。 SCSUは[UTR6]に記載されています。 MIME向けであることを意味する、異なる符号化、BOCU-1は、[UTN6]に記載されています。圧縮はUTF-8とは反対に、魅力的ではあるが、これらのどちらも（これを書いている時点で）IETFで多くの関心を集めています。
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 / IEC 10646が開発される前は、多くの国が独自のCCSSと文字セットを開発しました。これらの多くのダースは、インターネット上で一般的に使用され、今日です。例としては、キリル文字のISO 8859-5が含まれており、シフトJISの日本語のスクリプト用。
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プロトコルで使用するために登録した文字セット名の正式なリストはIANAによって維持され、<http://www.iana.org/assignments/character-sets>で見つけることができます。リストは優先名とエイリアスが含まれています。このリストは、歴史的な事実で確実に文字セットに名前をマップするために十分な詳細を与えていないではない文字セットまたは参照されている名前など、多くのエラーを、含まれていることに注意してください。
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 [US-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】文字セットとの間のマッピング文字データに関連する問題、およびマッピングテーブルデータのXMLフォーマットを記述する。
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 / IEC 10646のコード化文字セットの識別されたサブセットのメンバー、または非結合文字が先行文字を組み合わせた配列を有します。 <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>
非結合文字からなるグラフィック文字のシーケンスは、一つ以上の結合文字が続きます。複合シーケンスのためのグラフィックシンボルは、一般的にシーケンス内の各文字の図形の組み合わせで構成されています。複合配列は、文字ではなく、従って、ISO / IEC 10646 <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つの文字の組み合わせである場合もあれば、3つの文字「A」の組み合わせ、非破壊バックスペース、および急性かもしれません。 2文字以上を組み合わせるためのルールは、「構成ルール」と呼ばれ、他の文字に文字を離れて取るためのルールは、「分解ルール」と呼ばれています。構図の結果は、「合成済み文字」と呼ばれています。分解の結果は、「分解文字」と呼ばれています。
normalization
正常化
Normalization is the transformation of data to a normal form, for example, to unify spelling. <UNICODE>
正規化は、例えば、スペルを統一するために、正規形へのデータの変換です。 <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>」および「<A> <nのチルダ> <O>」） 。
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>" および "<A> <nのチルダ> <O>" テキスト表示装置に同一示されるであろう。プロトコルの設計者は、これらの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.
用語「正規化」と「正規化」は、しばしば互換的に使用されています。一般的には、どちらも標準化されたルールに基づいて、別の文字列に1文字以上の文字列を変換することを意味します。いくつかのCCSSが書かれた文字列に対して複数の同等の表現が可能。正規化は、文字列を比較するに、参照目的のためのベースとして、複数の同等の表現のうちの一つを選択します。テキストの文字列では、これらのルールは通常、組み合わせ文字を分解したり、文字を組み合わせて文字を構成するに基づいています。 【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つの異なる形態を持っている特定のアルファベットの機能です。形状及び大きさが著しく異なることがあり、これらの変異体は、大文字（また、資本又はmajusculeとしても知られる）と小文字（も小さいか微小としても知られる）と呼ばれます。ケースマッピングは、文字の大文字と小文字のフォームの団体です。 <UNICODE>
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のマッピングは、（常にではない）通常あります。ただし、1ケースに存在する文字の多くの例があるが、そのために、他の場合には、対応する文字が存在しないか、そのためにこのようなトルコのドットなし修飾子と「I」といくつかのギリシャ語の文字として、特殊なマッピングルールがあります。ケースマッピングは、さらに、ロケールに依存することができます。一つだけの場合は、「ケースの折りたたみ」と呼ばれる持っているテキストを変換します。
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>
照合は、テキスト情報の単位を注文するプロセスです。照合は、特定の言語に通常は固有のものです。それは時々alphabetizationは、ソートと照合するだけの特殊なケースではあるが、アルファベット順に並べとして知られています。 <UNICODE>
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.
照合は、文字列の任意の特定のペアの相対的な順序の決意に関係し、文字列値に適切な重み付きキーを提供するという課題に照合フォーカスに関するアルゴリズムは、の相対的な順序を決定するために、キー値のバイナリ比較を可能にするために文字列。
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の組み合わせの場合は、文字の言語的な意味を参照することなく行うことができます明らかにソート順序があります：コードポイントの順序は、ソートのために十分です。つまり、コードポイントの順序も、人が文字を並べ替えに使用することの順序です。多くのCCS / CESの組み合わせの場合は、コードポイントの順序は人に意味をなさないので、結果は人に表示される場合は、ソートのために有用ではありませんでしょう。
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.
コードポイントの順序は、地元の学校制度で教育を受けたすべての人が注文した文字列を見ることを期待どのように通常ではありません。人間の期待に1つのオーダーならば、人は言語固有の並べ替えを持っています。文字列が同じ文字の異なる表現がソート異なりますので、並べ替えの前に正規化されていない場合はコードポイントの順にソートすることは矛盾するように見えるだろう。この問題は、言語固有のソートと小さくてもよいです。
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".
コードテーブルは一般に「コードチャート」と呼ばれています。
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.
文字の種類の以下の定義が明確にいずれかのタイプに各文字を描くていない、また彼らは誰かが正確に特定の文字に適用される種類を予測することができます。定義は、それらがテキストの多くの（時には混乱）の性質について考えるのを助けるためにアプリケーション設計者のために意図されています。
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>
有益なUnicodeのプロパティ。結合またはnoncombiningかアルファベットおよび/または音節の主要部である文字。これはアルファベット基本文字を加えた一つ以上の結合文字の組み合わせの文字列に対して正規等価物である複合文字含む：文字ダイグラフと、アルファベット文字の文脈変異体;アルファベット文字の合字。合字の文脈の変種。修飾子手紙;単一アルファベットの互換性の等価物であるシンボルletterlike。およびその他の文字要素。 <UNICODE>
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>
主に音（または発音）とは対照的にアイデア（または意味）を示す任意のシンボル、例えば、中国語、日本語、韓国語で使用される電話や漢字を示すシンボル。 <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>
したがって、テキストの意味を明確にする、などの文章やフレーズなどのテキストの単位を、区切り文字。句読点の使用は、散文に限定されるものではありません。彼らはまた、例えば、数学や科学の式で使用されています。 <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のシンボル、ボックスの描画やグラフィックスのためのシンボル、飾り文字のシンボルが含まれています。 <NONE>
Examples of symbols include characters for arrows, faces, and geometric shapes. [UNICODE] has a property that defines characters as symbols.
シンボルの例には、矢印、顔、及び幾何学的形状のための文字を含みます。 [UNICODE]は記号としての文字を定義する特性を有しています。
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>
そのポジショニングプレゼンテーションの結合文字は、その基本文字に依存しています。これは、一般的に、それ自体の視覚的なベースラインに沿ってスペースを消費しません。 <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>
マークは、適用または修飾された、または新しい値を表す新しいシンボルを作成するシンボルに取り付けられています。彼らはまた、そのシンボルの値を変更するかどうかに関係なくシンボルに適用マークすることができます。後者の場合、発音区別符号は、通常、（例えば、アクセント、トーン、またはいくつかの他の言語情報）の独立した値を表します。また、ダイアクリティカルマークや発音区別と呼ばれます。 <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..U + 001FおよびU + 007F..U + 009Fで65の文字。これらはまた、制御コードとして知られています。 <UNICODE>
formatting character
文字の書式設定
Characters that are inherently invisible but that have an effect on the surrounding characters. <UNICODE>
本質的に目に見えないですが、文字は、周囲の文字に影響を与えます。 <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 / IEC 10646の符号化文字として含まれています。 <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感嘆符）は全角と半角ASCII文字を含むアジアの文字セットとの互換性のために含まれていました。
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>
入力方法は、アプリケーションにテキストを入力する人のためのメカニズムです。 <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.
テキストは、多くの方法でコンピュータに入力することができます。キーボードは、これまでで使用される最も一般的なデバイスですが、多くの文字は、単一のストロークで、一般的なコンピュータのキーボードで入力することはできません。多くのオペレーティングシステムは、キーボードによって許可されているものの範囲外のユーザー入力文字をすることができ、システムソフトウェアが付属しています。
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.
例えば、中国語、日本語、韓国語での漢字のためのさまざまな入力方法の数十があります。他の人が文字にストローク数を使用しながら、いくつかは、キーボードからの入力表音で始まります。インプットメソッドはまた、単一のアルファベット文字の上に二、三発音区別符号を持つヨーロッパの文字など、多くの発音区別符号を、持っているスクリプトのために必要とされます。
rendering rules
ルールをレンダリング
A rendering rule is an algorithm that a system uses to decide how to display a string of text. <NONE>
レンダリング・ルールは、システムがテキストの文字列を表示する方法を決定するために使用するアルゴリズムです。 <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.
いくつかのスクリプトは、直接入力ストリームからの各文字は、単にグリフシステムからコピーされ、画面や印刷されたページに置くことができ、フォント、で表示することができます。他のスクリプトは、表示用テキストをレンダリングするために、文字のコンテキストに基づいているルールを必要としています。
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.
- そのような手紙の形で文字が単語の途中に、単語の初めに、単独で立っているかどうか、または終了時に、隣接する文字に応じて変化するアラビア語（および多くの他）、などのスクリプト単語。レンダリング規則は、二つ以上のグリフの間で選択する必要があります。
- 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.
- それらは、特定の他の子音に隣接している、またはそれらが記憶され、発音される方法とは異なる順序で表示されてもよい場合に子音がその形状を変更することができるインド語スクリプトなどのスクリプト。レンダリング規則は、二つ以上のグリフの間で選択する必要があります。
- 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>
フォントは、文字データを視覚的に描写するために使用されたグリフのコレクションです。フォントは、多くの場合、画像形成可能なグリフの集合を生成し、特定の値に設定され、パラメータ（例えば、大きさ、姿勢、重量、及びserifness）のセットに関連付けられています。 <UNICODE>
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>
プロセスまたは混合の結果は、左から右へ単一行に配向テキストと右から左への方向のテキストの双方向ディスプレイと呼ばれています。 <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 / IEC 10646での書式設定の文字があるので、さらに、双方向テキストは、混乱を引き起こす可能性があります。これらの明示的な書式文字は関係なく、文字の左から右への暗黙的または右から左のプロパティの表示を変更します。
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.
[UNICODE]は双方向テキストを表示するために長いと信じられないほど詳細なアルゴリズムを持っています。
undisplayable character
表示不可能な文字
A character that has no displayable form. <NONE>
何も表示可能な形式を持っていない文字。 <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）を表示することができません。そのようなテキストの方向を設定するためのものとの書式文字も表示不可能です。 [UNICODE]のすべての文字は、それに関連付けられたグリフを有すること、および表示不可能文字のグリフが実際の文字が表示不可能であることを示すものとして正方形点線で囲まれていること、しかし、注意してください。
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>
プロトコル要素は、プロトコルの一意の名前の一部です。 <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>
名前空間には、特定の項目のための有効な名前、またはこれらの有効な名前を生成するための構文規則のセットです。 <NONE>
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.
インターネット・プロトコルの多くの項目は、特定のインスタンスまたは値を識別するための名前を使用しています。名前は、DNS内の名前として、（いくつかの所定のルールにより）生成（例えば、IANAと同様に）中央登録、または分散登録および制御機構を有していてもよいです。
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>
前とネットワークを介して送信した後に使用される符号化および復号化は、多くの場合、「オン・ザ・ワイヤ」（または時には単に「ワイヤ」）フォーマットと呼ばれます。 <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.
文字はコードポイントによって識別されます。プロトコルで送信される前に、彼らは、最初のビットとのオクテットとして符号化されなければなりません。文字を送信で受信された場合も同様に、それらは、符号化されており、個々の文字を処理する必要があるプロトコルは、処理前にそれらをデコードする必要があります。
parsed text
解析されたテキスト
Text strings that is analyzed for subparts. <NONE>
サブパーツについて分析されるテキスト文字列。 <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.
いくつかのプロトコルでは、テキストフィールドにフリーテキストを解析することがあります。接頭辞：「再」の後に表示される内容に基づいてスレッドしようとするフィールド：たとえば、多くのメールユーザエージェントは、件名のテキスト中の単語を解析します。
charset identification
文字集合の識別
Specification of the charset used for a string of text. <NONE>
テキストの文字列に使用する文字セットの仕様。 <NONE>
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".
複数の文字セットが同じ場所で使用できるようにするプロトコルは、テキストが適切な文字セットを識別することを要求しなければなりません。この識別せずに、テキストを見ているプログラムは、決定的にテキストの文字セットを識別することはできません。文字セットの識別はまた、「文字セットタギング」と呼ばれています。
language identification
言語識別
Specification of the human language used for a string of text. <NONE>
テキストの文字列に使用する人間の言語の仕様。 <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などの）いくつかのプロトコルは、機械加工のために意図されたテキストがテキストで使用される言語で識別されることを可能にします。そのような識別は、それを話すことによってテキストをレンダリングシステムなどによって、テキストの機械加工のために重要です。言語の識別はまた、「言語タグ」と呼ばれています。
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（最も顕著なのは、[RFC2822]、インターネットメールヘッダーの標準）が必要な形式でUS-ASCII以外の文字集合でのテキストメッセージの本文とヘッダを可能メッセージ形式です。 MIMEは2049年と同様に、より最近のRFC経由のRFC 2045に記述されています。 <NONE>
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つまたは複数の文字符号化スキームに示されている可逆の変換済み符号化データです。 <NONE>
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は通常、レガシープロトコルを介して送信されるデータの新しいタイプを可能にするために、別のフォーマットに文字データの種類をエンコードするために有用です。 IETFにおいて使用TESSの主な例は、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を介して、0〜9、+、/、および=、バイナリデータは、Zを介してASCII文字のAで表されることを可能にする転送符号化シンタックスです。それは、[RFC2045]で定義されています。 <NONE>
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]に記載されています。 <NONE>
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テキストは明示的に文字セットでタグ付けされています。 XMLの仕様は、<http://www.w3.org/XML/>で見つけることができます。 <NONE>
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データ記述言語は、テキストデータのための多くのフォーマットを持っています。フォーマットが異なるレパートリーと異なるエンコーディングを可能とします。 ASN.1に基づくIETF標準に現れる形式のいくつかはIA5String（すべてのASCII文字）、PrintableStringの（ほとんどのASCII文字が、多くの句読点文字の欠落）、BMPString（UTF-16BE形式のISO / IEC 10646プレーン0から文字を含みます）、UTF8Stringを（名前が示すと同じように）、また、T61String呼ばTeletexStringは（;レパートリー）は、時間の経過とともに変化します。
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互換エンコード方式は、ホスト名を国際化のための可能な解決策として提案されています。彼らの目標は、ISO / IEC法的DNSホスト名などの10646文字（STD 13で説明したように）の任意の文字列をエンコードすることができることです。これを書いている時点では、ACEは、IETF標準となっていません。
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での国際化の議論に登場している他の用語のホッジ-podgeです。この文書が成熟するにつれて、追加条項が追加される可能性があります。
locale
ローカル
Locale is the user-specific location and cultural information managed by a computer. <NONE>
ロケールは、コンピュータによって管理されているユーザ固有の場所と文化の情報です。 <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.
言語（国内の領域にも地域）国によって異なるため、ユーザーのロケールは、多くの場合、重要な要因となることができます。典型的には、ユーザのロケール情報が使用される言語（複数可）を含みます。
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?
ロケールで、多くの厄介な、未解決の問題があることに留意すべきです。例えば、テキストは、テキストまたはそれを見ている人を書いた人のロケール情報を使用して表示すべきですか？どのような場合には、それを見た人は、別の場所に移動していますか？唯一のロケール情報の一部は、テキストの作成および編集に影響を与えるべきか？
Latin characters
ラテン文字
"Latin characters" is a not-precise term for characters historically related to ancient Greek script and currently used throughout the world. <NONE>
「ラテン文字は」歴史的に古代ギリシャのスクリプトに関連し、現在、世界全体で使用される文字のない、正確な用語です。 <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 / IEC 10646は、範囲U + + 024F 0020..U、U + 1E00..U + 1EFF、他の範囲でラテン文字をエンコードします。
romanization
ローマ字
The transliteration of a non-Latin script into Latin characters. <NONE>
ラテン文字への非ラテン文字の音訳。 <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文字」と呼ばれています。彼らはまた、多くの場合、これらの文字のために使用されている中国での用語の後に、「漢字」と呼ばれています。 <NONE>
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 / IEC 10646では、漢字は同じ起源を持っていた日本、中国、および/または韓国語から漢字の各セットは、単一のコードポイントが割り当てられたことを意味し、「統一」でした。この肯定的な結果は、多くの、より少ないコードポイントがハンを表現するために必要であったということでした。この負の結果は、3つの言語を書く人々は異なっていると思うの文字が同じコードポイントを持っているということでした。自然、起源、そして漢の統一によって引き起こされる問題の深刻さの不一致の大きな取引があります。
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>
それが別の言語で等価的に表すことができるように、一つの言語のテキストの一部通路の意味を伝えるプロセス。 <NONE>
Many language translation systems are inexact and cannot be applied repeatedly to go from one language to another to another.
多くの言語翻訳システムは不正確であり、他の言語から別の言語から行くために繰り返し適用することはできません。
transliteration
音訳
The process of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet. <NONE>
変換アルファベットの文字で書き込みのアルファベットまたは音節システムの文字を表現する方法。 <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.
多くのスクリプト音訳は正確であり、多くは完璧なラウンドトリップのマッピングを持っています。これに注目すべき例外は、前述した、ローマ字表記です。音訳は、一般的に文字ごとの文字に基づいて、別のスクリプト内のスクリプトで表現さテキストを変換することを含みます。
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>
体系的に一般的に技術的な音標文字（通常はラテン語ベース）、または他の系統的転写正書法を使用して、話し言葉のいくつかの通路の音を書き込む処理。転写はまた、時にはそれが話されたかのようにテキストの音に基づいて転写（通常ラテン系）形態、に書かれたテキストの変換を指します。 <NONE>
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>
正規表現は、文字列の集合から特定の文字列を選択するためのメカニズムを提供します。正規表現は、文字列内のテキストを検索し、おそらく他のテキストで見つかったテキストを変更するために使用される言語です。 <NONE>
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プロトコルで最も一般的なメカニズムは、正規表現を使用することです。単一の正規表現言語はありませんが、数多くの非常によく似た方言があります。
The Unicode Consortium has a good discussion about how to adapt regular expression engines to use Unicode. [UTR18]
ユニコードコンソーシアムは、Unicodeを使用するために、正規表現エンジンを適応する方法について良い議論を持っています。 [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>
ISO / IECはU + 10FFFDにU + U + F8FFにE000、U + FFFFDにU + F0000、およびU + 100000から10646個のコードポイントは、私的使用のために利用可能です。これは解釈その使用が協働するユーザ間のプライベート契約によって決定することができる標準によって指定されていない標準のコードポイントを指します。 <UNICODE>
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タイプ、文字セット、および言語の「X-」の名前のように、物事のための私的使用の名前の長い歴史を持っている。これらの経験は、多くの実装者は、私的使用の名前は、実際には公共の場であると仮定して、かなりのマイナスとなっていますと長寿命。）
Security is not discussed in this document.
セキュリティは、この文書で説明されていません。
[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.
2000：[ISOIEC10646] ISO / IEC 10646-1。国際規格 - 情報技術 - ユニバーサルマルチオクテット符号化文字セット（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.
[UNICODE] Unicode標準、バージョン3.2.0は、ユニコード規格によって定義され、バージョン3.0（読書、MA、アディソン・ウェズリー、2000 ISBN 0-201-61633-5）は、Unicode標準によって修正されるよう＃27アネックス：ユニコード3.1（http://www.unicode.org/reports/tr27/）とUnicode規格付属書＃28によって：ユニコード3.2（http://www.unicode.org/reports/tr28/）、ユニコードコンソーシアム2002年。
[CHARMOD] Character Model for the World Wide Web 1.0, W3C, <http://www.w3.org/TR/charmod/>.
[CHARMOD]ワールド・ワイド・ウェブ1.0、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.
【FRAMEWORK] ISO / IEC TR 11017：1997（E）。情報技術 - 国際化のためのフレームワーク、ISO / IEC JTC 1 / SC 22 / WG 20、1997によって調製。
[ISO 639] ISO 639:2000 (E/F) - Code for the representation of names of languages, 2000.
[ISO 639] ISO 639：2000（E / F） - 言語の名前の表現のためのコードを、2000年。
[ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries, 2000.
[ISO 3166] 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、 "MIMEパートワン：インターネットメッセージ本体のフォーマット"、1996年11月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIMEパート3：メッセージヘッダの拡張非ASCIIテキストのために"、RFC 2047、1996年11月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、 "言語識別のためのタグ"、BCP 47、RFC 3066、2001年1月。
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986, 1986.
[US-ASCII]コード化文字セット - 情報交換、ANSI X3.4-1986、1986年のための7ビットの米国標準コードを。
[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「Unicodeの標準圧縮方式」、M.ウルフら。アル。、Unicodeのテクニカルレポート＃6。
[UTR15] "Unicode Normalization Forms", M. Davis & M. Duerst, Unicode Technical Report #15.
【UTR15 "Unicode正規化フォーム"、M.＆M.デイヴィスDuerst、ユニコード技術報告＃15。
[UTR18] "Unicode Regular Expression Guidelines", M. Davis, Unicode Technical Report #18.
[UTR18] "のUnicode正規表現ガイドライン"、M.デイヴィス、Unicodeのテクニカルレポート＃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.デイヴィス、Unicodeのテクニカルレポート＃22。
ALA-LC Romanization Tables, Randall Barry (ed.), U.S. Library of Congress, 1997, ISBN 0844409405
ALA-LCのローマ字表、ランドール・バリー（編）、米国議会の米国図書館、1997、ISBN 0844409405
Blackwell Encyclopedia of Writing Systems, Florian Coulmas, Blackwell Publishers, 1999, ISBN 063121481X
ライティングシステム、フロリアンCoulmas、ブラックウェル出版、1999、ISBN 063121481Xのブラックウェル百科事典
The World's Writing Systems, Peter Daniels and William Bright, Oxford University Press, 1996, ISBN 0195079930
世界ライティングシステム、ピーター・ダニエルズとウィリアム・ブライト、オックスフォード大学出版、1996、ISBN 0195079930
Writing Systems of the World, Akira Nakanishi, Charles E. Tuttle Company, 1980, ISBN 0804816549
世界のライティングシステム、明中西、チャールズ・E・タトル社、1980年、ISBN 0804816549
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 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
アルファベット - 4.1 ASCIIコンパチブルエンコーディング（ACE） - 6 ASN.1テキスト形式 - 6のBase64 - 6基本多言語面（BMP） - 3.2双方向ディスプレイ - 5 BOCU -1 - 3.2場合 - 4文字 - 2文字符号化形式 - 2文字符号化方式 - 2文字セット - 2文字セットの識別 - 6つのCJK文字と漢字 - 7コードチャート - 4コード表 - 4符号化された文字 - 2符号化された文字セット - 文字を組み合わせた2 - 4互換文字 - 4制御文字 - - 4.1区別符号 - 4.1テキストを表示し、レンダリング - 2フォント - 5書式文字 - 4.1グリフ - 2グリフコード4.1複合配列 - 2グラフィックシンボル - 5国際化、ローカライゼーション - 2表意 - 4.1インプットメソッド - 5国際化 - 2 ISO - 3.1言語 - 2言語識別 - 6つのラテン文字 - 7つの地方や地域の標準化団体 - 3.1ロケール - 7局在 - 2 MIME - 6つの多 - 2名前空間 - 6ノンスペーシングキャラクタ - 4.1正規 - 4上ワイヤencod INGの - 6解析されたテキスト - 6私的使用 - 7つのプロトコル要素 - 6句読点 - 4.1印刷可能引用し - 6つの正規表現 - 7つのレンダリングルール - 5ローマ字 - 7スクリプト - 2 SCSU - 3.2ソーティングと照合 - 4シンボル - 4.1トランス - 2転写 - 7転送符号化シンタックス - 6翻訳 - 7音訳 - 7 UCS-2及びUCS-4から3.2表示不可文字 - 5ユニコードコンソーシアム - - 3.1 UTF-32から3.2 UTF-16、UTF-16BE、およびUTF-16LE - 3.2 UTF-8から3.2 World Wide Webコンソーシアム - 3.1 XML - 6
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:
ジェームズ・センは、このドキュメントの最初のアウトラインに貢献しました。ハラルド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スーザン・ハリスジータヴェンツェルジョン・クレンシンヘニング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セグレ場所サンタクルス、CA 95060 USA
EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
電子メール：paul.hoffman@imc.orgとpaul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。