[要約] RFC 3536は、IETFにおける国際化に関する用語を定義したものであり、国際化に関する共通の言葉や概念を提供することを目的としています。
Network Working Group P. Hoffman
Request for Comments: 3536 IMC & VPNC
Category: Informational May 2003
Terminology Used in Internationalization in the IETF
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.
Copyright（c）The Internet Society（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 RFCS
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>」などの角度ブラケットに示されています。多くの定義は「<<negn」として示されています。つまり、定義はもともとこのドキュメントのために作成されたことを意味します。定義のソースの角度ブラケット表記は、上記の段落などのドキュメントへの参照に使用される四角いブラケット表記とは異なります。これらの参照は、セクション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]のコードポイントと名前の表記を使用します。たとえば、「a」という文字は、「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.
このセクションでは、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> Examples of scripts are Latin, Cyrillic, Greek, Arabic, and Han (the ideographs used in writing Chinese, Japanese, and Korean). [RFC2277] discusses scripts in detail.
1つ以上の言語の書かれた形式に使用されるグラフィック文字のセット。<ISOIEC10646>スクリプトの例は、ラテン語、キリル語、ギリシャ語、アラビア語、および漢（中国語、日本、韓国語の書面で使用される表彰台）です。[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.
単一の名前は、言語またはスクリプトのいずれかを意味します。たとえば、「アラビア語」は言語の名前とスクリプトの名前の両方です。実際、多くのスクリプトが言語の名前から名前を借りています。さらに、多くの言語で多くのスクリプトが使用されています。たとえば、ロシア語とブルガリア語はキリル文字に記載されています。一部の言語は、異なるスクリプトを使用して表現できます。モンゴル語はモンゴル語とキリル語のスクリプトのいずれかで書くことができ、セルボクロアチア語はラテン語とキリル語の両方のスクリプトを使用して書かれています。さらに、一部の言語は通常、同時に複数のスクリプトで表現されます。たとえば、日本語は通常、一連のテキストで漢字（漢）、カタカナ、およびヒラガナの脚本で表現されています。
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.
人々がキャラクターについて話すとき、彼らは主に最初の2つの定義のいずれかを使用しています。
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>
コード化された表現と一緒にキャラクター。<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）は、文字セットとセットの文字とコード化された表現の関係を確立する明確なルールのセットです。<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>
グリフは、1つ以上のグリフ画像を表す抽象的な形式です。「グリフ」という用語は、多くの場合、グリフ画像の同義語であり、グリフ表現の実際の具体的なイメージであり、いくつかのディスプレイ表面にラスタライズされているか、さもなければ画像化されています。文字データを表示する際には、特定の文字を描写するために1つ以上のグリフを選択できます。これらのグリフは、組成およびレイアウト処理中にレンダリングエンジンによって選択されます。<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、1対多、または多くのマッピングが含まれる場合があります。一部のレガシーマッピングはグリファイティックであるため、多くの人から多いだけでなく、不連続である可能性があります。したがって、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.
この定義では、「Muly-One」とは、単一の文字にマッピングされた一連の文字を意味します。「多く」は、単一の文字にマッピングされる代替文字を意味するものではありません。
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.
一部のセスは単一のCCに関連付けられています。たとえば、UTF-8 [RFC2279]はISO/IEC 10646にのみ適用されます。ISO2022などの他のCESは、多くのCCSに関連しています。
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>
チャーセットは、オクテットのシーケンスを抽象文字のシーケンスにマッピングする方法です。憲章は、実際には、1つ以上のCCSとCESの組み合わせです。チャーセット名は、[RFC2278]に文書化された手順に従って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 (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つのスクリプトのみを処理します（多くの場合、英語のテキストで使用されている文字を含むもの）、またはどの文字セットがローカルの推測に使用されているかという問題を残します（もちろん、相互運用性の問題につながります）。このようなプロトコルに非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で説明されている「Locale」と「ローカリゼーション」を混同しないでください。
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」の「Internationalization」の「N」の間の文字の数であり、「10」は「L」と「ローカリゼーション」の「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>
「多言語」という用語には、多くの広く変動する定義があるため、標準での使用には推奨されません。定義のいくつかは、国際的なキャラクターを処理する能力に関連しています。他の定義は、複数の充電器を処理する機能に関連しています。さらに、複数の言語を処理する能力に関連しています。<なし>
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.
キャラクターを組み合わせると、前の文字（または場合によっては文字）の表示が変更されます。そのようなテキストをレンダリングするとき、ディスプレイエンジンは、ベース文字と結合文字のすべてを表すフォントにグリフを見つけるか、組み合わせ自体をレンダリングする必要があります。このようなレンダリングは簡単にすることができますが、同じ文字の上に表示される2つの組み合わせマークがある場合など、組み合わせマークが相互に相互作用する場合、それは時々複雑になります。文字のフォーマットは、レンダラーがテキストを表示する方法を変更することもできます。レンダリングは、アラビア語やINDICスクリプトなど、ベース文字の複雑な表示ルールを備えた一部のスクリプトでも困難です。
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
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で最も使用されるものは、一般に「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は、「ISO/IEC JTC 1/SC 2 WG2」として知られるグループによって制御されており、多くの場合「WG2」と呼ばれます。ISO標準は、終了する前に多くのステップを経て、ISO/IEC 10646の変更の間に数年が経過します。WG2とその作業製品に関する情報は、<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バージョンの両方で購入できます。標準を引用する方法の1つの例は、[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グループはJTC 1/SC22/WG20です。これは、国際文字列の注文など、JTC1の国際化を担当しています。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.
国際キャラクター標準の2番目の重要なグループは、Unicodeコンソーシアムです。Unicodeコンソーシアムは、Unicode標準[Unicode]の促進に関心のある企業、政府、および他のグループの業界団体です。Unicode標準は、レパートリーとコードポイントがISO/IEC 10646と同一のCCSです。Unicodeコンソーシアムは、各文字の属性を定義するなど、プロトコルでより有用なベース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 Consortiumは、Unicodeの技術レポートとしてUnicode標準への補遺を公開しています。成熟度のさまざまな段階では、多くの種類の技術レポートがあります。Unicode Standard and Affiliatedの技術レポートは、<http://www.unicode.org/>にあります。
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).
多くのネイティブのCCSと充電器があるように、それらを作成およびサポートするための多くのローカルおよび地域の標準団体があります。これらの一般的な例は、ANSI（米国）とCEN/ISS（ヨーロッパ）です。
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 CCの文字は、さまざまな方法で表現できます。エンコーディングフォームは直接的なアドレス指定方法であり、変換形式はエンコードフォームをワイヤのビットとして表す方法です。
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/IEC 10646の最初の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/IEC 10646に対して定義された2つのエンコードフォームです。UCS-2はBMPのみにアドレス指定されます。多くの有用なキャラクター（多くのHANキャラクターなど）がBMP以外で定義されているため、多くの人はUCS-2が死んでいると考えるでしょう。理論的には、UCS-4は、ISO/IEC 10646からの2^31コードポイントの全範囲に32ビット値として扱います。ただし、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.
[RFC2279]で指定された変換形式であるUTF-8は、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].
Unicodeコンソーシアムは、UTF-32を[UTR19]のUCS-4の変換形式として定義しています。
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.
Unicodeコンソーシアムは、典型的なテキストに適した圧縮を提供するように設計されたエンコーディング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および日本のスクリプトのシフトJIが含まれます。
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/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はASCII [us-ascii]です。このCCSは、多くのIETFプロトコルのキーワードとパラメーター名の基礎として、およびまだ国際化されていない多数のIETFプロトコルの唯一のCCとして使用されます。
[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>
非結合キャラクターで構成されるグラフィック文字のシーケンスに続いて、1つ以上の組み合わせ文字が続きます。コンポジットシーケンスのグラフィックシンボルは、一般に、シーケンス内の各文字のグラフィックシンボルの組み合わせで構成されています。複合シーケンスはキャラクターではないため、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".
一部のCCSでは、一部の文字は他の文字の組み合わせで構成されています。たとえば、「鋭いa」という文字は、2人のキャラクター「a」と「鋭い結合」の組み合わせであるか、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> <tilde> <o>」や「<a> <nとtilde> <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> <Tilde> <o>を組み合わせて<n <n <o>」と「<a> <n with tilde> <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つ以上の文字列を別の文字列に変換することを意味します。一部のCCSは、書かれた文字列の複数の等価表現を許可します。正規化は、文字列を比較する際に参照目的のベースとして複数の等価表現の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つの異なる形式がある特定のアルファベットの特徴です。形状とサイズが著しく異なる場合があるこれらのバリアントは、大文字（資本または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のマッピングがあります（常にではありませんが）。ただし、あるケースには存在するが、他のケースには対応する文字がないか、トルコのドットレス「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> 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.
照合は、テキスト情報の単位を注文するプロセスです。照合は通常、特定の言語に固有です。アルファベット順は、ソートと照合の特別なケースにすぎませんが、アルファベット順として知られています。<unicode>照合は、特定の文字列の相対順序の決定に関係しています。また、照合値に適切な加重キーを提供する問題に焦点を当て、キー値をバイナリ比較して相対的な比較を可能にするための相対的な比較を可能にします。文字列の注文。
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の注文は、人がキャラクターのソートに使用する順序でもあります。多くの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 Orderは通常、地元の学校システムによって教育を受けた人間が文字列が注文されることを期待する方法ではありません。人間の期待を注文する場合、言語固有の種類を持っています。同じ文字の異なる表現が異なるソートをするため、ソートする前に文字列が正規化されない場合、コードポイント順序へのソートは一貫性がないように思われます。この問題は、言語固有の種類では小さくなる可能性があります。
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.
文字のタイプの次の定義は、各文字を明確に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つ以上の結合文字の組み合わせ文字シーケンスと標準的なキャラクターである複合文字が含まれます。アルファベット文字のコンテキストバリアント。アルファベット文字の結晶;結晶の文脈バリアント。モディファイア文字;単一のアルファベット文字の互換性と同等の文字のようなシンボル。およびその他の文字要素。<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のシンボル、ボックスドラウングまたはグラフィックスのシンボル、およびディンバットのシンボルが含まれます。<なし>
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>
修正または新しい値を表す新しいシンボルを作成するために、記号に適用または添付されたマーク。また、そのシンボルの値を変更するかどうかに関係なく、シンボルにマークを適用することもできます。後者の場合、Diacriticは通常、独立した値（たとえば、アクセント、トーン、または他の言語情報）を表します。また、ディアチカルマークまたはダイクリティカルとも呼ばれます。<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>
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（フル幅の感嘆符）は、完全な幅および半幅の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>
入力方法は、人がアプリケーションにテキストを入力するメカニズムです。<なし>
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.
たとえば、中国語、日本、韓国語のHANキャラクターには、多数の異なる入力方法があります。キーボードからの音声入力から始まるものもあれば、キャラクターのストローク数を使用するものもあります。また、単一のアルファベット文字に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.
一部のスクリプトはフォントで直接表示できます。ここでは、入力ストリームの各文字をグリフシステムからコピーして画面または印刷ページに置くことができます。他のスクリプトには、表示用のテキストをレンダリングするために、文字のコンテキストに基づいたルールが必要です。
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つ以上のグリフから選択する必要があります。
- 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つ以上のグリフから選択する必要があります。
- 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>
フォントは、キャラクターデータの視覚的描写に使用されるグリフのコレクションです。フォントは、多くの場合、一連のパラメーター（サイズ、姿勢、重量、セリフネスなど）に関連付けられており、特定の値に設定すると、画像のコレクションを生成します。<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>
表示可能なフォームがない文字。<なし>
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>
プロトコル要素は、プロトコルの独自の名前の部分です。<なし>
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> 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.
文字はコードポイントによって識別されます。プロトコルで送信される前に、最初にビットとオクテットとしてエンコードする必要があります。同様に、キャラクターが送信で受信されると、エンコードされており、個々の文字を処理する必要があるプロトコルは処理前にデコードする必要があります。
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.
一部のプロトコルでは、テキストフィールドの無料テキストが解析される場合があります。たとえば、多くのメールユーザーエージェントは、「Re：」プレフィックスの後に表示されるものに基づいて、件名のテキストの単語を解析します。フィールド。
charset identification
チャーセット識別
Specification of the charset used for a string of text. <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".
同じ場所で複数のチャーセットを使用できるようにするプロトコルは、テキストを適切な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など）は、マシン処理がテキストで使用される言語で識別されることを意図したテキストを許可します。このような識別は、テキストを話すことでテキストをレンダリングするシステムなど、テキストの機械加工にとって重要です。言語識別は「言語タグ付け」とも呼ばれます。
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は、RFCS 2045から2049、および最近のRFCで説明されています。<なし>
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は、通常、レガシープロトコルを介して新しいタイプのデータを送信できるようにするために、タイプの文字データを別の形式にエンコードするのに役立ちます。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>
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>
引用されたPrintableは、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テキストは、充電器で明示的にタグ付けされています。XMLの仕様は<http://www.w3.org/xml/>にあります。<なし>
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（ISO/IEC 10646プレーン0の文字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互換のエンコードスキーム（実際に転送されている構文の転送）が、ホスト名を国際化するための可能なソリューションとして提案されています。彼らの目標は、ISO/IEC 10646文字の文字列をリーガルDNSホスト名としてエンコードできることです（STD 13で説明されています）。この執筆時点では、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での国際化の議論に登場した他の用語のホッジポッジです。このドキュメントが成熟するにつれて、追加の用語が追加される可能性があります。
locale
ロケール附近付近
Locale is the user-specific location and cultural information managed by a computer. <NONE>
Localeは、コンピューターが管理するユーザー固有の場所と文化情報です。<なし>
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>
「ラテン語のキャラクター」は、古代ギリシャ語の脚本に歴史的に関連しており、現在世界中で使用されているキャラクターの前ではない用語です。<なし>
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 0020..U 024F、U 1E00..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文字とhan文字
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およびHANの文字には、日本語と韓国語で使用される音声キャラクターは含まれていないことに注意してください。
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では、HAN文字は「統一」されていました。つまり、同じ起源を持っていた日本、中国語、韓国語の各セットには、単一のコードポイントが割り当てられています。これの肯定的な結果は、HANを表すために必要なコードポイントがはるかに少ないことでした。これの否定的な結果は、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>
ある言語でテキストの通過の意味を伝えるプロセスでは、別の言語で同等に表現できます。<なし>
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>
回心アルファベットのキャラクターによる執筆のアルファベット順または音節システムのキャラクターを表現するプロセス。<なし>
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>
一般的に技術的な音声アルファベット（通常はラテンベース）またはその他の系統的転写正書法の使用により、話し言葉の一部の音の音を体系的に書き込むプロセス。また、転写は、テキストが話されているかのように、テキストの音に基づいて、書かれたテキストの転写された（通常はラテンベースの）形式への変換を指します。<なし>
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>
正規表現は、文字文字列のセットから特定の文字列を選択するメカニズムを提供します。正規表現は、文字列内のテキストを検索するために使用される言語であり、おそらく他のテキストで見つかったテキストを変更します。<なし>
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コンソーシアムは、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>
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-」名前の名前の個人的な名前の長い歴史があります。これらの経験は非常に否定的であり、多くの実装者が実際に公開されていると仮定しています。そして長寿命。）
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.
[ISOIEC10646] ISO/IEC 10646-1：2000。国際標準 - 情報技術 - ユニバーサルマルチオクテットコード化された文字セット（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は、Unicode Standard Annex＃27によって修正されているように、Unicode標準バージョン3.0（MA、Addison-Wesley、2000、2000年、ISBN 0-201-61633-5）によって定義されています。：Unicode 3.1（http://www.unicode.org/reports/tr27/）およびUnicode Standard Annex＃28：Unicode 3.2（http://www.unicode.org/reports/tr28/）、Unicode Consortiumium、2002年。
[CHARMOD] Character Model for the World Wide Web 1.0, W3C, <http://www.w3.org/TR/charmod/>.
[Charmod] World Wide Web 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.
[フレームワーク] 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] Freed、N。およびN. Borenstein、「Mimeパート1：インターネットメッセージボディの形式」、1996年11月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「マイムパート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] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、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]コード化された文字セット - 情報交換のための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。デイビス、Unicodeテクニカルノート＃6。
[UTR6] "A Standard Compression Scheme for Unicode", M. Wolf, et. al., Unicode Technical Report #6.
[utr6]「ユニコードの標準圧縮スキーム」、M。Wolf、et。al。、Unicodeテクニカルレポート＃6。
[UTR15] "Unicode Normalization Forms", M. Davis & M. Duerst, Unicode Technical Report #15.
[UTR15]「ユニコード正規化フォーム」、M。Davis＆M。Duerst、Unicodeテクニカルレポート＃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。Davis、Unicodeテクニカルレポート＃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
Blackwell Encyclopedia of Writing Systems、Florian Coulmas、Blackwell Publishers、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
世界の執筆システム、nakira、チャールズ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 charset -2 charset識別-6 cjk文字とhan文字 - 7コードチャート-4コードテーブル-4コード化された文字-2コード文字セット-2組み合わせキャラクター-4互換性キャラクター-4.1コンポジットシーケンス-4コントロール文字-4.1ディクリティック-4.1テキストの表示とレンダリング-2フォント-5フォーマット文字-4.1グリフ-2グリフコード-2グラフィックシンボル-5 i18n、l10n-2 ideographic-4.1入力方法-5国際化-2 ISO-3.1言語-2言語識別-6ラテン文字-7ローカルおよび地域の標準組織 - -3.1ロケール-7ローカリゼーション-2 MIME-6 MULTINGUAL-2 NAMEスペース-6 NONSPACENG CALTERY-4.1正規化-4オンザワイヤエンコード-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 Unicode Consortium-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:
ジェームズ・センは、このドキュメントの最初の概要に貢献しました。Harald AlvestrandとMartin 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
ダン・コーン・ジェイコブ・パルメヨハン・ヴァン・ウィンゲン・ピーター・コンスタブル・ユーリ・デムチェンコ・スーザン・ハリス・ジタ・ウェンツェル・ジョン・クレンシン・ヘニング・シュルツリン・レスリー・デイグル・マルクス・シェラー・ケン・ウィスラー
B. Author's Address
B.著者の住所
Paul Hoffman Internet Mail Consortium and VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンインターネットメールコンソーシアムとVPNコンソーシアム127 Segre Place Santa Cruz、CA 95060 USA
EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。