RFC3536 日本語訳

3536 Terminology Used in Internationalization in the IETF. P. Hoffman. May 2003. (Format: TXT=64284 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         P. Hoffman
Request for Comments: 3536                                    IMC & VPNC
Category: Informational                                         May 2003

コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 3536年のIMC&VPNCカテゴリ: 情報の2003年5月

          Terminology Used in Internationalization in the IETF

IETFでの国際化に使用される用語

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document provides a glossary of terms used in the IETF when
   discussing internationalization.  The purpose is to help frame
   discussions of internationalization in the various areas of the IETF
   and to help introduce the main concepts to IETF participants.

このドキュメントは国際化について議論するときIETFで使用される用語の用語集を提供します。 目的は、IETFの様々な領域での国際化のフレーム議論を助けて、IETF関係者に主な概念を紹介するのを助けることです。

Table of Contents

目次

   1. Introduction...................................................  2
     1.1 Purpose of this document....................................  2
     1.2 Format of the definitions in this document..................  3
   2. Fundamental Terms..............................................  3
   3. Standards Bodies and Standards.................................  8
     3.1 Standards bodies............................................  8
     3.2 Encodings and transformation formats of ISO/IEC 10646....... 10
     3.3 Native CCSs and charsets.................................... 11
   4. Character Issues............................................... 12
     4.1 Types of characters......................................... 15
   5. User interface for text........................................ 17
   6. Text in current IETF protocols................................. 19
   7. Other Common Terms In Internationalization..................... 22
   8. Security Considerations........................................ 25
   9. References..................................................... 25
     9.1 Normative References........................................ 25
     9.2 Informative References...................................... 26
   10. Additional Interesting Reading................................ 27
   11. Index......................................................... 27
   A. Acknowledgements............................................... 29
   B. Author's Address............................................... 29
   Full Copyright Statement.......................................... 30

1. 序論… 2 1.1 このドキュメントの目的… 2 1.2 このドキュメントの定義の形式… 3 2. 基本項… 3 3. 標準化団体と規格… 8 3.1の標準化団体… 8 3.2 ISO/IEC10646のEncodingsと変化形式… 10 3.3 ネイティブのCCSsとcharsets… 11 4. キャラクター問題… 12 4.1のタイプのキャラクタ… 15 5. テキストのためのユーザーインタフェース… 17 6. 現在のIETFプロトコルのテキスト… 19 7. 国際化における他の一般的な用語… 22 8. セキュリティ問題… 25 9. 参照… 25 9.1 標準の参照… 25 9.2 有益な参照… 26 10. 追加おもしろい読書… 27 11. 索引をつけてください… 27 A.承認… 29B.作者のアドレス… 29 完全な著作権宣言文… 30

Hoffman                      Informational                      [Page 1]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[1ページ]のRFC3536Terminology

1. Introduction

1. 序論

   As [RFC2277] summarizes: "Internationalization is for humans.  This
   means that protocols are not subject to internationalization; text
   strings are." Many protocols throughout the IETF use text strings
   that are entered by, or are visible to, humans.  It should be
   possible for anyone to enter or read these text strings, which means
   that Internet users must be able to be enter text in typical input
   methods and displayed in any human language.  Further, text
   containing any character should be able to be passed between Internet
   applications easily.  This is the challenge of internationalization.

[RFC2277]が以下をまとめるので 「国際化は人間のためのものです。」 これは、プロトコルが国際化を被りやすくないことを意味します。 「テキスト文字列はそうです。」 人間、IETF中の多くのプロトコルがそれが入られるか、または目に見えるテキスト文字列を使用します。 だれでもこれらのテキスト文字列を入るか、または読むのが、可能であるべきであり、インターネットユーザがそうすることができなければならないどの手段が典型的にテキストを記録するかは、どんな人間の言語でも方法を入力して、表示しました。 さらに、どんなキャラクタも含むテキストはインターネットアプリケーションの間を容易に通ることができるべきです。 これは国際化の挑戦です。

1.1 Purpose of this document

1.1 このドキュメントの目的

   This document provides a glossary of terms used in the IETF when
   discussing internationalization.  The purpose is to help frame
   discussions of internationalization in the various areas of the IETF
   and to help introduce the main concepts to IETF participants.

このドキュメントは国際化について議論するときIETFで使用される用語の用語集を提供します。 目的は、IETFの様々な領域での国際化のフレーム議論を助けて、IETF関係者に主な概念を紹介するのを助けることです。

   Internationalization is discussed in many working groups of the IETF.
   However, few working groups have internationalization experts.  When
   designing or updating protocols, the question often comes up "should
   we internationalize this" (or, more likely, "do we have to
   internationalize this").

IETFの多くのワーキンググループで国際化について議論します。 しかしながら、わずかなワーキンググループにはしか、国際化の専門家がいません。 プロトコルを設計するか、またはアップデートするとき、質問はしばしば「私たちはこれを国際的にするべきであること」を来ます(おそらく、「私たちはこれを国際的にしなければなりません」)。

   This document gives an overview of internationalization as it applies
   to IETF standards work by lightly covering the many aspects of
   internationalization and the vocabulary associated with those topics.
   It is not meant to be a complete description of internationalization.
   The definitions in this document are not normative for IETF
   standards; however, they are useful and standards may make
   informative reference to this document after it becomes an RFC.  Some
   of the definitions in this document come from many earlier IETF
   documents and books.

それが軽く国際化の多くの局面とそれらの話題に関連しているボキャブラリーを含んでいることによってIETF標準化作業に適用されるとき、このドキュメントは国際化の概観を与えます。 それは国際化の完全な記述であることが意味されません。 IETF規格には、定義は本書では規範的ではありません。 しかしながら、それらは役に立ちます、そして、RFCになった後に規格はこのドキュメントの有益な参照をするかもしれません。 定義のいくつかが多くの以前のIETFドキュメントと本から本書では来ます。

   As in many fields, there is disagreement in the internationalization
   community on definitions for many words.  The topic of language
   brings up particularly passionate opinions for experts and non-
   experts alike.  This document attempts to define terms in a way that
   will be most useful to the IETF audience.

多くの分野のように、不一致が多くの単語のために定義での国際化共同体にあります。 言語の話題は同じく専門家に関する特に激しい意見と非の専門家を育てます。 このドキュメントは、IETF聴衆の最も役に立つ方法で用語を定義するのを試みます。

   This document uses definitions from many documents that have been
   developed outside the IETF.  The primary documents used are:

このドキュメントはIETFの外で開発された多くのドキュメントから定義を使用します。 使用される第一のドキュメントは以下の通りです。

      - ISO/IEC 10646 [ISOIEC10646]

- ISO/IEC10646[ISOIEC10646]

      - The Unicode Standard [UNICODE]

- ユニコード規格[ユニコード]

Hoffman                      Informational                      [Page 2]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[2ページ]のRFC3536Terminology

      - W3C Character Model [CHARMOD]

- W3Cキャラクターモデル[CHARMOD]

      - IETF RFCs, including [RFC2277]

- IETF RFCs、包含[RFC2277]

1.2 Format of the definitions in this document

1.2 このドキュメントの定義の形式

   In the body of this document, the source for the definition is shown
   in angle brackets, such as "<ISOIEC10646>".  Many definitions are
   shown as "<NONE>", which means that the definitions were crafted
   originally for this document.  The angle bracket notation for the
   source of definitions is different than the square bracket notation
   used for references to documents, such as in the paragraph above;
   these references are given in Section 9.

このドキュメントのボディーを、定義のためのソースは「<ISOIEC10646>」などの角ブラケットで見せられます。 多くの定義が示される、「<、>のいずれ、も」でない、定義が元々このドキュメントのために作られたことを意味する。 定義の源への角ブラケット記法はドキュメントの参照に使用される角括弧記法と異なっています、上のパラグラフなどのように。 セクション9でこれらの参照を与えます。

   For some terms, there are commentary and examples after the
   definitions.  In those cases, the part before the angle brackets is
   the definition that comes from the original source, and the part
   after the angle brackets is commentary that is not a definition (such
   as examples or further exposition).

いくつかの期間、定義の後に、論評と例があります。 それらの場合では、角ブラケットの前の部分は一次資料から来る定義です、そして、角ブラケットの後の部分は定義(例か一層の博覧会などの)でない論評です。

   Examples in this document use the notation for code points and names
   from the Unicode Standard [UNICODE] and ISO/IEC 10646 [ISOIEC10646].
   For example, the letter "a" may be represented as either "U+0061" or
   "LATIN SMALL LETTER A".

例はコード・ポイントと名前にユニコードStandard[ユニコード]とISO/IEC10646[ISOIEC10646]から記法を本書では使用します。 例えば、手紙“a"は「U+0061」か「ラテン語の小文字A」のどちらかとして表されるかもしれません。

2. Fundamental Terms

2. 基本項

   This section covers basic topics that are needed for almost anyone
   who is involved with making IETF protocols more friendly to non-ASCII
   text and with other aspects of internationalization.

このセクションはほとんどIETFプロトコルを非ASCIIテキストにより好意的にして、国際化の他の局面にかかわる人はだれにも必要である基本的な話題をカバーします。

   language

言語

      A language is a way that humans interact.  The use of language
      occurs in many forms, the most common of which are speech,
      writing, and signing.  <NONE>

言語は人間が相互作用する方法です。 言語の使用は多くのフォームに起こります。その最も一般的なものは、スピーチであり、書いて、サインしています。 <、>のいずれも

      Some languages have a close relationship between the written and
      spoken forms, while others have a looser relationship.  [RFC3066]
      discusses languages in more detail and provides identifiers for
      languages for use in Internet protocols.  Note that computer
      languages are explicitly excluded from this definition.

いくつかの言語には、書かれて話されたフォームの間の密接な関係がありますが、他のものは、よりゆるい関係を持っています。 [RFC3066]は、インターネットプロトコルにおける使用にさらに詳細に言語について議論して、言語のための識別子を提供します。 コンピュータ言語がこの定義から明らかに除かれることに注意してください。

   script

スクリプト

      A set of graphic characters used for the written form of one or
      more languages.  <ISOIEC10646>

1セットの図形文字は書かれたフォームの1つ以上に言語を使用しました。 <ISOIEC10646>。

Hoffman                      Informational                      [Page 3]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[3ページ]のRFC3536Terminology

      Examples of scripts are Latin, Cyrillic, Greek, Arabic, and Han
      (the ideographs used in writing Chinese, Japanese, and Korean).
      [RFC2277] discusses scripts in detail.

スクリプトに関する例は、ラテン語の、そして、キリル文字の、そして、ギリシアのアラビア語と、ハン(中国語、日本語、および韓国語を書く際に使用される表意文字)です。 [RFC2277]は詳細にスクリプトについて議論します。

      It is common for internationalization novices to mix up the terms
      "language" and "script".  This can be a problem in protocols that
      differentiate the two.  Almost all protocols that are designed (or
      were re-designed) to handle non-ASCII text deal with scripts (the
      written systems) or characters, while fewer actually deal with
      languages.

国際化初心者が用語「言語」と「スクリプト」に混合するのは、一般的です。 これは2を微分するプロトコルの問題であるかもしれません。 ほとんどすべてのプロトコルがスクリプト(書かれたシステム)かキャラクタとの非ASCIIテキスト取引を扱うように設計されていて(または、再設計されました)、実際により少ない間、言語に対処してください。

      A single name can mean either a language or a script; for example,
      "Arabic" is both the name of a language and the name of a script.
      In fact, many scripts borrow their names from the names of
      languages.  Further, many scripts are used for many languages; for
      example, the Russian and Bulgarian languages are written in the
      Cyrillic script.  Some languages can be expressed using different
      scripts; the Mongolian language can be written in either the
      Mongolian and Cyrillic scripts, and the Serbo-Croatian language is
      written using both the Latin and Cyrillic scripts.  Further, some
      languages are normally expressed with more than one script at the
      same time; for example, the Japanese language is normally
      expressed in the Kanji (Han), Katakana, and Hiragana scripts in a
      single string of text.

ただ一つの名前は言語かスクリプトのどちらかを意味できます。 例えば、「アラビア語」は言語の名前とスクリプトの名前の両方です。 事実上、多くのスクリプトが言語の名前からそれらの名前を借ります。 さらに、多くのスクリプトが多くの言語に使用されます。 例えば、ロシアの、そして、ブルガリア人の言語はキリル文字のスクリプトで書かれています。 異なったスクリプトを使用することでいくつかの言語を表すことができます。 モンゴルの、そして、キリル文字の文字でモンゴルの言語を書くことができます、そして、セルビア・クロアチア語言語は、両方のラテン語の、そして、キリル文字のスクリプトを使用することで書かれています。 さらに、通常、いくつかの言語が同時に、1つ以上のスクリプトで表されます。 例えば、通常、日本語はテキストの一連のKanji(ハン)、Katakana、およびHiraganaスクリプトで表されます。

   character

キャラクタ

      A member of a set of elements used for the organization, control,
      or representation of data.  <ISOIEC10646>

組織に使用される1セットの要素、コントロール、またはデータの表現のメンバー。 <ISOIEC10646>。

      There are at least three common definitions of the word
      "character":

「キャラクタ」という言葉の少なくとも3つの一般的な定義があります:

         - a general description of a text entity

- テキスト実体の概説

         - a unit of a writing system, often synonymous with "letter" or
           similar terms

- しばしば「手紙」か同類項と同義の書記体系のユニット

         - the encoded entity itself

- コード化された実体自体

      When people talk about characters, they are mostly using one of
      the first two definitions.

人々がキャラクタに関して話すとき、彼らは最初の2つの定義の1つをほとんど使用しています。

      A particular character is identified by its name, not by its
      shape.  A name may suggest a meaning, but the character may be
      used for representing other meanings as well.  A name may suggest

特定のキャラクタは形によって特定されるのではなく、その名前によって特定されます。 名前は意味を示すかもしれませんが、キャラクタは、また、他の意味を表すのに使用されるかもしれません。 名前は示されるかもしれません。

Hoffman                      Informational                      [Page 4]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[4ページ]のRFC3536Terminology

      a shape, but that does not imply that only that shape is commonly
      used in print, nor that the particular shape is associated only
      with that name.

しかし、形、それは、その形だけが一般的に印刷して使用されるのを含意しません、そして、特定の形はその名前だけに関連しています。

   coded character

コード化されたキャラクタ

      A character together with its coded representation.  <ISOIEC10646>

コード値に伴うキャラクタ。 <ISOIEC10646>。

   coded character set

コード化文字集合

      A coded character set (CCS) is a set of unambiguous rules that
      establishes a character set and the relationship between the
      characters of the set and their coded representation.
      <ISOIEC10646>

コード化文字集合(CCS)は、文字の組を確立する1セットの明白な規則とセットと彼らのコード値の登場人物の相関関係です。 <ISOIEC10646>。

   character encoding form

フォームをコード化するキャラクタ

      A character encoding form is a mapping from a character set
      definition to the actual code units used to represent the data.
      <UNICODE>

文字の組定義から実際のデータを表すのに使用されるコード単位までフォームをコード化するキャラクタはマッピングです。 <ユニコード>。

   repertoire

レパートリー

      The collection of characters included in a character set.  Also
      called a character repertoire.  <UNICODE>

文字の組にキャラクタの収集を含んでいます。 また、キャラクタレパートリーと呼ばれます。 <ユニコード>。

   glyph

glyph

      A glyph is an abstract form that represents one or more glyph
      images.  The term "glyph" is often a synonym for glyph image,
      which is the actual, concrete image of a glyph representation
      having been rasterized or otherwise imaged onto some display
      surface.  In displaying character data, one or more glyphs may be
      selected to depict a particular character.  These glyphs are
      selected by a rendering engine during composition and layout
      processing. <UNICODE>

glyphは1つ以上のglyphイメージを表す抽象的なフォームです。 しばしば"glyph"という用語はglyphイメージのための同義語です。(それは、ラスタライズされるか、または別の方法でいくらかの表示面に像を描かれたglyph表現の実際の、そして、具体的なイメージです)。 キャラクタデータを表示する際に、1glyphsが特定のキャラクタについて表現するのが選択されるかもしれません。 これらのglyphsは構成とレイアウト処理の間、表現エンジンによって選択されます。 <ユニコード>。

   glyph code

glyphコード

      A glyph code is a numeric code that refers to a glyph.  Usually,
      the glyphs contained in a font are referenced by their glyph code.
      Glyph codes are local to a particular font; that is, a different
      font containing the same glyphs may use different codes.
      <UNICODE>

glyphコードはglyphについて言及する数字コードです。 通常、字体で含まれたglyphsは彼らのglyphコードによって参照をつけられます。 Glyphコードは特定の字体にローカルです。 すなわち、同じglyphsを含む異なった字体は異なったコードを使用するかもしれません。 <ユニコード>。

Hoffman                      Informational                      [Page 5]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[5ページ]のRFC3536Terminology

   transcoding

コード変換

      Transcoding is the process of converting text data from one
      character encoding form to another.  Transcoders work only at the
      level of character encoding and do not parse the text.  Note:
      Transcoding may involve one-to-one, many-to-one, one-to-many or
      many-to-many mappings.  Because some legacy mappings are glyphic,
      they may not only be many-to-many, but also discontinuous: thus
      XYZ may map to yxz.  <CHARMOD>

コード変換はフォームをコード化する1つのキャラクタから別のキャラクタまでテキストデータを変換する過程です。 トランスコーダは、単にキャラクタコード化のレベルで働いて、テキストを分析しません。 以下に注意してください。 コード変換は1〜1、1つへの多く、多くへの1または多くへの多くマッピングにかかわるかもしれません。 しかし、また、いくつかの遺産マッピングがglyphicであるので彼らが多くに多くであるかもしれないだけではない、不連続: したがって、XYZはyxzに写像するかもしれません。 <CHARMOD>。

      In this definition, "many-to-one" means a sequence of characters
      mapped to a single character.  The "many" does not mean
      alternative characters that map to the single character.

この定義では、「1つへの多く」は単独のキャラクタに写像されたキャラクタの系列を意味します。 「多く」はどんな意地悪な代替の性格にも単独のキャラクタへのその地図をしません。

   character encoding scheme

計画をコード化するキャラクタ

      A character encoding scheme (CES) is a character encoding form
      plus byte serialization.  There are many character encoding
      schemes in Unicode, such as UTF-8 and UTF-16.  <UNICODE>

計画(CES)をコード化するキャラクタはフォームプラスバイト連載をコード化するキャラクタです。 UTF-8やUTF-16などのユニコードには多くのキャラクタコード化計画があります。 <ユニコード>。

      Some CESs are associated with a single CCS; for example, UTF-8
      [RFC2279] applies only to ISO/IEC 10646.  Other CESs, such as ISO
      2022, are associated with many CCSs.

いくつかのCESsが独身のCCSに関連しています。 例えば、UTF-8[RFC2279]はISO/IEC10646だけに適用します。 ISO2022などの他のCESsは多くのCCSsに関連しています。

   charset

charset

      A charset is a method of mapping a sequence of octets to a
      sequence of abstract characters.  A charset is, in effect, a
      combination of one or more CCSs with a CES.  Charset names are
      registered by the IANA according to procedures documented in
      [RFC2278].  <NONE>

charsetは抽象的なキャラクタの系列に八重奏の系列を写像する方法です。 事実上、charsetはCESへの1CCSsの組み合わせです。 [RFC2278]に記録された手順によると、Charset名はIANAによって登録されます。 <、>のいずれも

      Many protocol definitions use the term "character set" in their
      descriptions.  The terms "charset" or "character encoding scheme"
      are strongly preferred over the term "character set" because
      "character set" has other definitions in other contexts and this
      can be confusing.

多くのプロトコル定義が彼らの記述に「文字の組」という用語を使用します。 「文字の組」が他の文脈に他の定義を持って、これが混乱させられることができるので、"charset"か「計画をコード化するキャラクタ」という用語は「文字の組」という用語より強く都合がよいです。

   internationalization

国際化

      In the IETF, "internationalization" means to add or improve the
      handling of non-ASCII text in a protocol.  <NONE>

IETFでは、「国際化」は、プロトコルにおける非ASCIIテキストの取り扱いを加えるか、または改良することを意味します。 <、>のいずれも

      Many protocols that handle text only handle one script (often, the
      one that contains the letters used in English text), or leave the
      question of what character set is used up to local guesswork

テキストを扱う多くのプロトコルが、1つのスクリプト(しばしば英文で使用される手紙を含むもの)を扱うか、またはどんな文字の組がローカルの当て推量まで使用されるかに関する質問を残すだけです。

Hoffman                      Informational                      [Page 6]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[6ページ]のRFC3536Terminology

      (which leads, of course, to interoperability problems).  Adding
      non-ASCII text to such a protocol allows the protocol to handle
      more scripts, hopefully all of the ones useful in the world.

(もちろん相互運用性問題に導きます。) そのようなプロトコルへの非ASCIIテキストの付加で、プロトコルは、より多くのスクリプト、うまくいけば世界で役に立つもののすべてを扱うことができます。

   localization

ローカライズ

      The process of adapting an internationalized application platform
      or application to a specific cultural environment.  In
      localization, the same semantics are preserved while the syntax
      may be changed.  [FRAMEWORK]

国際化しているアプリケーションプラットホームかアプリケーションを特定の文化面での環境に翻案する過程。 ローカライズでは、構文を変えるかもしれませんが、同じ意味論を保存します。 [枠組み]

      Localization is the act of tailoring an application for a
      different language or script or culture.  Some internationalized
      applications can handle a wide variety of languages.  Typical
      users only understand a small number of languages, so the program
      must be tailored to interact with users in just the languages they
      know.

ローカライズは異なった言語、スクリプトまたは文化のアプリケーションを合わせる行為です。 いくつかの国際化しているアプリケーションがさまざまな言語を処理できます。 典型的なユーザが少ない数の言語を理解しているだけであるので、まさしく彼らが知っている言語でユーザと対話するためにプログラムを仕立てなければなりません。

      The major work of localization is translating the user interface
      and documentation.  Localization involves not only changing the
      language interaction, but also other relevant changes such as
      display of numbers, dates, currency, and so on.  The better
      internationalized an application is, the easier it is to localize
      it for a particular language and character encoding scheme.

ローカライズの主要な仕事はユーザーインタフェースとドキュメンテーションを翻訳することです。 ローカライズは、言語相互作用だけではなく、数、日付、通貨などの表示などの他の関連変化も変えることを伴います。 アプリケーションが国際化するほうがよければ、それは計画をコード化する特定の言語とキャラクタのためにそれをより局所化しやすいです。

      Localization is rarely an IETF matter, and protocols that are
      merely localized, even if they are serially localized for several
      locations, are generally considered unsatisfactory for the global
      Internet.

めったにローカライズはIETF問題ではありません、そして、一般に、それらが順次数個の位置に局所化されても単に局所化されるプロトコルは世界的なインターネットに不十分であると考えられます。

      Do not confuse "localization" with "locale", which is described in
      Section 7 of this document.

「ローカライズ」を「現場」に間違えないでください。(それは、このドキュメントのセクション7で説明されます)。

   i18n, l10n

i18n、l10n

      These are abbreviations for "internationalization" and
      "localization".  <NONE>

これらは「国際化」と「ローカライズ」のための略語です。 <、>のいずれも

      "18" is the number of characters between the "i" and the "n" in
      "internationalization", and "10" is the number of characters
      between the "l" and the "n" in "localization".

「18インチは「i」と「国際化」における「n」の間のキャラクタの数です、そして、「10インチは「l」と「ローカライズ」における「n」の間のキャラクタの数です」。

   multilingual

多数の言語で表現にされる

      The term "multilingual" has many widely-varying definitions and
      thus is not recommended for use in standards.  Some of the
      definitions relate to the ability to handle international

「多言語」という用語は、多くの広く異なった定義を持って、その結果、規格における使用のために推薦されません。 定義のいくつかが国際的に扱う能力に関連します。

Hoffman                      Informational                      [Page 7]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[7ページ]のRFC3536Terminology

      characters; other definitions relate to the ability to handle
      multiple charsets; and still others relate to the ability to
      handle multiple languages.  <NONE>

キャラクタ。 他の定義は複数のcharsetsを扱う能力に関連します。 そして、それでも、他のものは複数の言語を扱う能力に関連します。 <、>のいずれも

   displaying and rendering text

表示と表現テキスト

      To display text, a system puts characters on a visual display
      device such as a screen or a printer.  To render text, a system
      analyzes the character input to determine how to display the text.
      The terms "display" and "render" are sometimes used
      interchangeably.  Note, however,  that text might be rendered as
      audio and/or tactile output, such as in systems that have been
      designed for people with visual disabilities.  <NONE>

テキストを表示するために、システムはスクリーンかプリンタなどの視覚ディスプレイ装置にキャラクタを置きます。 テキストを表すなら、システムは、テキストを表示する方法を決定するためにキャラクタ入力を分析します。 用語「表示」と「レンダリング」は時々互換性を持って使用されます。 注意、しかしながら、そのテキストはオーディオの、そして/または、触覚の出力として表されるかもしれません、人々のために視覚障害で設計されているシステムなどのように。 <、>のいずれも

      Combining characters modify the display of the character (or, in
      some cases, characters) that precede them.  When rendering such
      text, the display engine must either find the glyph in the font
      that represents the base character and all of the combining
      characters, or it must render the combination itself.  Such
      rendering can be straight-forward, but it is sometimes complicated
      when the combining marks interact with each other, such as when
      there are two combining marks that would appear above the same
      character.  Formatting characters can also change the way that a
      renderer would display text.  Rendering can also be difficult for
      some scripts that have complex display rules for base characters,
      such as Arabic and Indic scripts.

結合したキャラクタは彼らに先行するキャラクタ(いくつかの場合キャラクタ)の表示を変更します。 そのようなテキストを表すとき、結合したキャラクタの基本文字とすべての代理をする字体で表示エンジンはglyphに当たらなければなりませんか、またはそれが組み合わせ自体をレンダリングしなければなりません。 そのような表現は簡単である場合がありますが、結合マークが互いに対話するとき、それは時々複雑です、同じキャラクタを超えて現れる2つの結合マークがある時のように。 また、形式キャラクタはレンダラーがテキストを表示する方法を変えることができます。 また、基本文字のための複雑な表示規則を持っているいくつかのスクリプトに、表現も難しい場合があります、アラビアの、そして、インドの文字などのように。

3. Standards Bodies and Standards

3. 標準化団体と規格

   This section describes some of the standards bodies and standards
   that appear in discussions of internationalization in the IETF.  This
   is an incomplete and possibly over-full list; listing too few bodies
   or standards can be just as politically dangerous as listing too
   many.  Note that there are many other bodies that deal with
   internationalization; however, few if any of them appear commonly in
   IETF standards work.

このセクションはIETFでの国際化の議論に現れる標準化団体と規格のいくつかについて説明します。 これがそうである、不完全でことによるとリストを洗い張りし過ぎています。 あまりにわずかなボディーか規格を記載するのは政治的にまた、多くを記載するのとちょうど同じくらい危険であることができます。 国際化に対処する他の多くのボディーがあることに注意してください。 しかしながら、彼らのどれかがIETF規格に一般的に現れるなら、わずかしか働いていません。

3.1 Standards bodies

3.1 標準化団体

   ISO

ISO

      The International Organization for Standardization has been
      involved with standards for characters since before the IETF was
      started. ISO is a non-governmental group made up of national
      bodies.  ISO has many diverse standards in the international
      characters area; the one that is most used in the IETF is commonly
      referred to as "ISO/IEC 10646", although its official name has

IETFが始動される前以来国際標準化機構はキャラクタの規格にかかわっています。 ISOは国家体で構成されていた民間のグループです。 ISOは国際的な人物領域に多くのさまざまの規格を持っています。 IETFで最も使用されるのは一般的に「ISO/IEC10646」と呼ばれます、正式名称はそうしましたが

Hoffman                      Informational                      [Page 8]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[8ページ]のRFC3536Terminology

      more qualifications.  (The IEC is International Electrotechnical
      Commission).  ISO/IEC 10646 describes a CCS that covers almost all
      known written characters in use today.

より多くの資格。 (IECは国際電気標準化会議です。) ISO/IEC10646は今日使用中のほとんどすべての知られている書かれたキャラクタをカバーするCCSについて説明します。

      ISO/IEC 10646 is controlled by the group known as "ISO/IEC JTC
      1/SC 2 WG2", often called "WG2" for short.  ISO standards go
      through many steps before being finished, and years often go by
      between changes to ISO/IEC 10646.  Information on WG2, and its
      work products, can be found at
      <http://www.dkuug.dk/JTC1/SC2/WG2/>.

ISO/IEC10646が知られているグループによって制御される、「しばしば「略してWG2"」と呼ばれるISO/IEC JTC1/サウスカロライナ2WG2" 終わっている前にISO規格は多くの階段を通ります、そして、何年もISO/IEC10646への変化の間でしばしば過ぎます。 <http://www.dkuug.dk/JTC1/SC2/WG2/>でWG2に関する情報、およびその作業生産物を見つけることができます。

      The standard, which comes in multiple parts, can be purchased in
      both print and CD-ROM versions.  One example of how to cite the
      standard is given in [RFC2279].  Any standard that cites ISO/IEC
      10646 needs to evaluate how to handle the versioning problem that
      is relevant to the protocol's needs.

印刷とCD-ROMバージョンの両方で規格(複数の部品に入る)を購入できます。 どう規格を引用するかに関する1つの例が[RFC2279]で出されます。 ISO/IEC10646を引用するどんな規格も、プロトコルの必要性に関連しているversioning問題を扱う方法を評価する必要があります。

      ISO is responsible for other standards that might be of interest
      to protocol developers.  [ISO 639] specifies the names of
      languages, and [ISO 3166] specifies the abbreviations of
      countries.  Character work is done in the group known as ISO/IEC
      JTC1/SC22 and ISO TC46, as well as other ISO groups.

ISOは他の開発者について議定書の中で述べるために興味があるかもしれない規格に責任があります。 [ISO639]は言語の名前を指定します、そして、[ISO3166]は国の略語を指定します。 ISO/IEC JTC1/SC22、ISO TC46、および他のISOグループとして知られているグループでキャラクター仕事をします。

      Another relevant ISO group is JTC 1/SC22/WG20, which is
      responsible for internationalization in JTC1, such as for
      international string ordering.  Information on WG20, and its work
      products, can be found at <http://www.dkuug.dk/jtc1/sc22/wg20/>

別の関連ISOグループはJTC1/SC22/WG20です。(そのJTCはJTC1での国際化、国際的なストリング注文などのように責任があります)。 <http://www.dkuug.dk/jtc1/sc22/wg20/>でWG20に関する情報、およびその作業生産物を見つけることができます。

   Unicode Consortium

ユニコード共同体

      The second important group for international character standards
      is the Unicode Consortium.  The Unicode Consortium is a trade
      association of companies, governments, and other groups interested
      in promoting the Unicode Standard [UNICODE].  The Unicode Standard
      is a CCS whose repertoire and code points are identical to ISO/IEC
      10646.  The Unicode Consortium has added features to the base CCS
      which make it more useful in protocols, such as defining
      attributes for each character.  Examples of these attributes
      include case conversion and numeric properties.

国際的な人物規格のための2番目の重要なグループはユニコードConsortiumです。 ユニコードConsortiumはユニコードStandard[ユニコード]を促進したがっていた会社、政府、および他のグループの産業団体です。 ユニコードStandardはレパートリーとコード・ポイントがISO/IEC10646と同じであるCCSです。 ユニコードConsortiumはそれをプロトコルで、より役に立つようにするベースCCSに特徴を加えました、各キャラクタのために属性を定義するのなどように。 これらの属性に関する例はケース変換と数値特性を含んでいます。

      The Unicode Consortium publishes addenda to the Unicode Standard
      as Unicode Technical Reports.  There are many types of technical
      reports at various stages of maturity.  The Unicode Standard and
      affiliated technical reports can be found at
      <http://www.unicode.org/>.

ユニコードConsortiumはユニコードTechnical ReportsとしてユニコードStandardに付加物を発行します。 様々なステージの円熟のときに、多くのタイプに関する技術報告書があります。 <http://www.unicode.org/>でユニコードStandardと系列技術報告書を見つけることができます。

Hoffman                      Informational                      [Page 9]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[9ページ]のRFC3536Terminology

   World Wide Web Consortium (W3C)

ワールドワイドウェブコンソーシアム(W3C)

      This group created and maintains the standard for XML, the markup
      language for text that has become very popular.  XML has always
      been fully internationalized so that there is no need for a new
      version to handle international text.

このグループは、非常にポピュラーになったテキストのために、XMLの規格、マークアップ言語を作成して、維持します。 XMLは、新しいバージョンが国際的なテキストを扱う必要は全くないように、完全にいつも国際的にされていました。

   local and regional standards organizations

地方の、そして、地方の規格組織

      Just as there are many native CCSs and charsets, there are many
      local and regional standards organizations to create and support
      them.  Common examples of these are ANSI (United States), and
      CEN/ISSS (Europe).

ちょうど多くのネイティブのCCSsとcharsetsがあるとき、それらを作成して、支持するために、多くの地方の、そして、地方の規格組織があります。 これらの一般的な例は、ANSI(合衆国)と、CEN/ISSS(ヨーロッパ)です。

3.2 Encodings and transformation formats of ISO/IEC 10646

3.2 ISO/IEC10646のEncodingsと変化形式

   Characters in the ISO/IEC 10646 CCS can be expressed in many ways.
   Encoding forms are direct addressing methods, while transformation
   formats are methods for expressing encoding forms as bits on the
   wire.

様々な意味でISO/IEC10646CCSのキャラクターを言い表すことができます。 コード化フォームは直接アドレス指定方法ですが、変化形式はワイヤのビットとしてフォームをコード化する言い表す方法です。

   Basic Multilingual Plane (BMP)

基本多言語水準(BMP)

      The BMP is composed of the first 2^16 code points in ISO/IEC
      10646.  The BMP is also called "plane 0".

BMPはISO/IEC10646の最初の2^16コード・ポイントで構成されます。 また、BMPは「飛行機0インチ」と呼ばれます。

   UCS-2 and UCS-4

UCS-2とUCS-4

      UCS-2 and UCS-4 are the two encoding forms defined for ISO/IEC
      10646.  UCS-2 addresses only the BMP.  Because many useful
      characters (such as many Han characters) have been defined outside
      of the BMP, many people would consider UCS-2 to be dead.
      Theoretically, UCS-4 addresses the entire range of 2^31 code
      points from ISO/IEC 10646 as 32-bit values.  However, for
      interoperability with UTF-16, ISO 10646 restricts the range of
      characters that will actually be allocated to the values
      0..0x10FFFF.

UCS-2とUCS-4はISO/IEC10646のために定義された書式をコード化する2歳です。 UCS-2はBMPだけを記述します。 多くの役に立つキャラクタ(多くのハンキャラクタなどの)がBMPの外で定義されたので、多くの人々が、UCS-2が死んでいると考えるでしょう。 理論的に、UCS-4は32ビットの値としてISO/IEC10646から2^31コード・ポイントの全体の範囲を記述します。 しかしながら、UTF-16がある相互運用性のために、ISO10646は実際に値0に割り当てられるキャラクタの範囲を制限します。0x10FFFF。

   UTF-8

UTF-8

      UTF-8, a transformation format specified in [RFC2279], is the
      preferred encoding for IETF protocols.  Characters in the BMP are
      encoded as one, two, or three octets.  Characters outside the BMP
      are encoded as four octets.  Characters from the US-ASCII
      repertoire have the same on-the-wire representation in UTF-8 as
      they do in US-ASCII.

UTF-8([RFC2279]で指定された変化形式)はIETFプロトコルのための都合のよいコード化です。 BMPのキャラクターは1、2、または3つの八重奏としてコード化されます。 BMPの外のキャラクターは4つの八重奏としてコード化されます。 それらが米国-ASCIIでするように米国-ASCIIレパートリーからのキャラクターはUTF-8にワイヤにおける同じ表現を持っています。

Hoffman                      Informational                     [Page 10]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[10ページ]のRFC3536Terminology

   UTF-16, UTF-16BE, and UTF-16LE

UTF-16、UTF-16BE、およびUTF-16LE

      UTF-16, UTF-16BE, and UTF-16LE, three transformation formats
      defined in [RFC2781], are not required by any IETF standards, and
      are thus used much less often than UTF-8.  Characters in the BMP
      are always encoded as two octets, and characters outside the BMP
      are encoded as four octets.  The three formats differ based on the
      order of the octets and the presence of a special lead-in mark
      called the "byte order mark" or "BOM".

UTF-16(形式が[RFC2781]で定義したUTF-16BE、およびUTF-16LE、3変化)はUTF-8よりどんなIETF規格も必要でなく、このようにしてまして、しばしば使用されます。 BMPのキャラクターは2つの八重奏としていつもコード化されます、そして、BMPの外のキャラクタは4つの八重奏としてコード化されます。 3つの形式が「バイト・オーダー・マークかBOM」と呼ばれる八重奏の注文と特別な引込み線のマークの存在に基づいて異なります。

   UTF-32

UTF-32

      The Unicode Consortium has defined UTF-32 as a transformation
      format for UCS-4 in [UTR19].

ユニコードConsortiumは[UTR19]でUCS-4のための変化形式とUTF-32を定義しました。

   SCSU and BOCU-1

SCSUとBOCU-1

      The Unicode Consortium has defined an encoding, SCSU, which is
      designed to offer good compression for typical text.  SCSU is
      described in [UTR6].  A different encoding that is meant to be
      MIME-friendly, BOCU-1, is described in [UTN6].  Although
      compression is attractive, as opposed to UTF-8 , neither of these
      (at the time of this writing) has attracted much interest in the
      IETF.

ユニコードConsortiumはコード化、典型的なテキストのために良い圧縮を提供するように設計されているSCSUを定義しました。 SCSUは[UTR6]で説明されます。 MIMEに優しいことが意味される異なったコード化(BOCU-1)は[UTN6]で説明されます。 圧縮はUTF-8と対照的に魅力的ですが、これら(この書くこと時点の)のどちらもIETFへの大きな関心を引き付けていません。

3.3 Native CCSs and charsets

3.3 ネイティブのCCSsとcharsets

   Before ISO/IEC 10646 was developed, many countries developed their
   own CCSs and charsets.  Many dozen of these are in common use on the
   Internet today.  Examples include ISO 8859-5 for Cyrillic and Shift-
   JIS for Japanese scripts.

ISO/IEC10646が発展する前に、多くの国がそれら自身のCCSsとcharsetsを開発しました。 ダースの多くのこれらは今日、インターネットで共用です。 例は日本の文字のためのキリール文字とShift JISのためのISO8859-5を含んでいます。

   The official list of the registered charset names for use with IETF
   protocols is maintained by IANA and can be found at
   <http://www.iana.org/assignments/character-sets>.  The list contains
   preferred names and aliases.  Note that this list has historically
   contained many errors, such as names that are in fact not charsets or
   references that do not give enough detail to reliably map names to
   charsets.

IETFプロトコルによる使用のための登録されたcharset名に関する株式相場表をIANAが維持して、<http://www.iana.org/課題/文字集合>で見つけることができます。 リストは都合のよい名前と別名を含んでいます。 このリストにはある注意は多くの誤りを歴史的に含みました、事実上charsetsでない名前や名前をcharsetsに確かに写像できるくらいの詳細を述べない参照のように。

   Probably the most well-known native CCS is ASCII [US-ASCII].  This
   CCS is used as the basis for keywords and parameter names in many
   IETF protocols, and as the sole CCS in numerous IETF protocols that
   have not yet been internationalized.

たぶん最もよく知られているネイティブのCCSはASCII[米国-ASCII]です。 このCCSはキーワードの基礎と多くのIETFプロトコルのパラメタ名としてまだ国際的にされていない多数のIETFプロトコルの唯一のCCSとして使用されます。

   [UTR22] describes issues involved in mapping character data between
   charsets, and an XML format for mapping table data.

[UTR22]は、charsetsの間でキャラクタデータを写像するのにかかわる問題について説明して、テーブルデータを写像するためにXML形式について説明します。

Hoffman                      Informational                     [Page 11]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[11ページ]のRFC3536Terminology

4. Character Issues

4. キャラクター問題

   This section contains terms and topics that are commonly used in
   character handling and therefore are of concern to people adding
   non-ASCII text handling to protocols.  These topics are standardized
   outside the IETF.

このセクションは非ASCIIテキスト取り扱いをプロトコルに追加するキャラクタ取り扱いに一般的に使用された、人々にとって、したがって重要な用語と話題を含みます。 これらの話題はIETFの外で標準化されます。

   combining character

キャラクタを結合します。

      A member of an identified subset of the coded character set of
      ISO/IEC 10646 intended for combination with the preceding non-
      combining graphic character, or with a sequence of combining
      characters preceded by a non-combining character.  <ISOIEC10646>

前の非結合した図形文字、または非結合したキャラクタによって先行されている結合したキャラクタの系列への組み合わせのために意図するISO/IEC10646のコード化文字集合の特定された部分集合のメンバー。 <ISOIEC10646>。

   composite sequence

コンポジット・シーケンス

      A sequence of graphic characters consisting of a non-combining
      character followed by one or more combining characters.  A graphic
      symbol for a composite sequence generally consists of the
      combination of the graphic symbols of each character in the
      sequence.  A composite sequence is not a character and therefore
      is not a member of the repertoire of ISO/IEC 10646.  <ISOIEC10646>

非結合したキャラクタから成る図形文字の順序は、より1時までにキャラクタを結合しながら、従いました。 一般に、コンポジット・シーケンスの図形は系列における、それぞれのキャラクタの図形の組み合わせから成ります。 コンポジット・シーケンスは、キャラクタでなく、またしたがって、ISO/IEC10646のレパートリーのメンバーではありません。 <ISOIEC10646>。

      In some CCSs, some characters consist of combinations of other
      characters.  For example, the letter "a with acute" might be a
      combination of the two characters "a" and "combining acute", or it
      might be a combination of the three characters "a", a non-
      destructive backspace, and an acute.  The rules for combining two
      or more characters are called "composition rules", and the rules
      for taking apart a character into other characters is called
      "decomposition rules".  The results of composition is called a
      "precomposed character"; the results of decomposition is called a
      "decomposed character".

いくつかのCCSsに、他のキャラクタの組み合わせから成るキャラクタもあります。 そして、例えば、2つのキャラクタの組み合わせが“a"で「結合鋭い」なら「鋭いのがあるa」がそうするか、または3つのキャラクタ“a"、aの組み合わせが非破壊的であるならそれがそうする手紙がバックスペースキーである、鋭いです。 2つ以上のキャラクタを結合するための規則は他のキャラクタにキャラクタを分解するために「構成規則」、および規則と呼ばれているのが、呼ばれた「分解規則」であるということです。 構成の結果は「前構成されたキャラクタ」と呼ばれます。 分解の結果は「分解しているキャラクタ」と呼ばれます。

   normalization

正常化

      Normalization is the transformation of data to a normal form, for
      example, to unify spelling.  <UNICODE>

正常化は、例えばスペルを統一するためには正規形へのデータの変換です。 <ユニコード>。

      Note that the phrase "unify spelling" in the definition above does
      not mean unifying different words with the same meaning (such as
      "color" and "colour").  Instead, it means unifying different
      character sequences that are intended to form the same composite
      characters (such as "<a><n><combining tilde><o>" and "<a><n with
      tilde><o>").

上の定義で「スペルを統一する」という句が、同じ意味(「色」や「色」などの)で異なった単語を統一することを意味しないことに注意してください。 代わりに、それは、同じ作られた登場人物(「<a><n><結合ティルド><o>」や「ティルド><o>と<a><n」などの)を形成することを意図する異なったキャラクタシーケンスを統一することを意味します。

Hoffman                      Informational                     [Page 12]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[12ページ]のRFC3536Terminology

      The purpose of normalization is to allow two strings to be
      compared for equivalence.  The strings "<a><n><combining
      tilde><o>" and "<a><n with tilde><o>" would be shown identically
      on a text display device.  If a protocol designer wants those two
      strings to be considered equivalent during comparison, the
      protocol must define where normalization occurs.

正常化の目的は2個のストリングが等価性のために比較されるのを許容することです。 ストリングの「<a><n><結合ティルド><o>」と「ティルド><o>と<a><n」は同様にテキストディスプレイ装置で示されるでしょう。 プロトコルデザイナーが比較の間、同等であるとそれらの2個のストリングを考えて欲しいなら、プロトコルは、正常化がどこに起こるかを定義しなければなりません。

      The terms "normalization" and "canonicalization" are often used
      interchangeably.  Generally, they both mean to convert a string of
      one or more characters into another string based on standardized
      rules.  Some CCSs allow multiple equivalent representations for a
      written string; normalization selects one among multiple
      equivalent representations as a base for reference purposes in
      comparing strings.  In strings of text, these rules are usually
      based on decomposing combined characters or composing characters
      with combining characters.  [UTR15] describes the process and many
      forms of normalization in detail.  Normalization is important when
      comparing strings to see if they are the same.

用語の「正常化」と"canonicalization"はしばしば互換性を持って使用されます。 一般に、それらの両方が、標準化された規則に基づく別のストリングに一連の1つ以上のキャラクタを変換することを意味します。 いくつかのCCSsが書かれたストリングの複数の同等な表現を許容します。 正常化はストリングを比較する際にベースとしての参照目的の複数の同等な表現の中の1つを選択します。 テキストのストリングでは、これらの規則は、通常、結合したキャラクタを分解するのに基づいているか、またはキャラクタを結合するのにキャラクタを構成することです。 [UTR15]は詳細にプロセスと多くの形式の正常化について説明します。 それらが同じであるかどうか確認するためにストリングを比較するとき、正常化は重要です。

   case

ケース

      Case is the feature of certain alphabets where the letters have
      two distinct forms.  These variants, which may differ markedly in
      shape and size, are called the uppercase letter (also known as
      capital or majuscule) and the lowercase letter (also known as
      small or minuscule).  Case mapping is the association of the
      uppercase and lowercase forms of a letter.  <UNICODE>

ケースは手紙が2つの異なったフォームを持っているあるアルファベットの特徴です。これらの異形(形とサイズにおいて著しく異なるかもしれない)は大文字(また、首都として知られているか、大文字の)と小文字(また、小さいか小さいとして、知られている)と呼ばれます。 ケースマッピングは手紙の大文字していて小文字のフォームの協会です。 <ユニコード>。

      There is usually (but not always) a one-to-one mapping between the
      same letter in the two cases.  However, there are many examples of
      characters which exist in one case but for which there is no
      corresponding character in the other case or for which there is a
      special mapping rule, such as the Turkish dotless "i" and some
      Greek characters with modifiers.  Case mapping can even be
      dependent on locale.  Converting text to have only one case is
      called "case folding".

(いつもでない)通常、同じ手紙の間には、2つの場合に1〜1つのマッピングがあります。 しかしながら、ある場合で存在しますが、もう片方の場合にはどんな対応するキャラクタもないか、または特別な配置規則があるキャラクタに関する多くの例があります、トルコのdotless「i」や修飾語がある何人かのギリシア人のキャラクタのように。 ケースマッピングは現場に依存してさえいる場合があります。 1つのケースしか持たないようにテキストを変換するのは「ケースの折り重なり」と呼ばれます。

   sorting and collation

ソーティングと照合

      Collating is the process of ordering units of textual information.
      Collation is usually specific to a particular language.  It is
      sometimes known as alphabetizing, although alphabetization is just
      a special case of sorting and collation.  <UNICODE>

照合はユニットの文字情報を注文するプロセスです。 通常、照合は特定の言語に特定です。 ABC順排列はただソーティングと照合の特別なケースですが、それはアルファベット順にするとして時々知られています。 <ユニコード>。

Hoffman                      Informational                     [Page 13]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[13ページ]のRFC3536Terminology

      Collation is concerned with the determination of the relative
      order of any particular pair of strings, and algorithms concerned
      with collation focus on the problem of providing appropriate
      weighted keys for string values, to enable binary comparison of
      the key values to determine the relative ordering of the strings.

キー値の2進の比較がストリングを注文する親類を決定するのを可能にするために適切な状態で提供するという問題の焦点がストリング値のためにキーに重みを加えたことをどんな特定の組のストリング、および照合に関するアルゴリズムの相対オーダの決断にも照合を心配させます。

      Sorting is the process of actually putting data records into
      specified orders, according to criteria for comparison between the
      records.  Sorting can apply to any kind of data (including textual
      data) for which an ordering criterion can be defined.  Algorithms
      concerned with sorting focus on the problem of performance (in
      terms of time, memory, or other resources) in actually putting the
      data records into a specified order.

ソーティングは記録での比較の評価基準に従って実際に指定された命令にデータレコードを入れるプロセスです。 注文評価基準を定義できるどんな種類のデータ(原文のデータを含んでいる)にもソーティングは適用できます。 ソーティングに関するアルゴリズムは実際に指定されたオーダーにデータレコードを入れる際に性能(時間、メモリ、または他のリソースに関する)の問題に焦点を合わせます。

      A sorting algorithm for string data can be internationalized by
      providing it with the appropriate collation-weighted keys
      corresponding to the strings to be ordered.

注文されるストリングに対応する適切な照合で荷重しているキーをそれに提供することによって、列データのためのソーティングアルゴリズムを国際的にすることができます。

      Many processes have a need to order strings in a consistent
      sequence (sorted).  For only a few CCS/CES combinations, there is
      an obvious sort order that can be done without reference to the
      linguistic meaning of the characters: the codepoint order is
      sufficient for sorting.  That is, the codepoint order is also the
      order that a person would use in sorting the characters.  For many
      CCS/CES combinations, the codepoint order would make no sense to a
      person and therefore is not useful for sorting if the results will
      be displayed to a person.

多くのプロセスには、一貫した系列(分類される)でストリングを注文する必要があります。 ほんのいくつかのCCS/CES組み合わせのために、キャラクタの言語的意味の参照なしでできる明白なソート順序があります: codepointオーダーはソーティングに十分です。 また、すなわち、codepointオーダーは人がキャラクタを割り当てる際に使用するオーダーです。 多くのCCS/CES組み合わせでは、人に結果を表示するなら、codepointオーダーは、人に意味をなさないだろう、したがって、ソーティングの役に立ちません。

      Codepoint order is usually not how any human educated by a local
      school system expects to see strings ordered; if one orders to the
      expectations of a human, one has a language-specific sort.
      Sorting to codepoint order will seem inconsistent if the strings
      are not normalized before sorting because different
      representations of the same character will sort differently.  This
      problem may be smaller with a language-specific sort.

通常、Codepointオーダーは地元の学校システムによって教育されたどんな人間も、ストリングが注文されるのを見るとどう予想するかということではありません。 1つが人間への期待に注文されるなら、1つには、言語特有の種類があります。 同じキャラクタの異なった表現が異なって分類されるのでストリングがソーティングの前に正常にされないなら、codepointオーダーへのソーティングは矛盾しているように見えるでしょう。 この問題は言語特有の種類で、より小さいかもしれません。

   code table

コードテーブル

      A code table is a table showing the characters allocated to the
      octets in a code.  <ISOIEC10646>

コードテーブルはキャラクタがコードにおける八重奏に割り当てたテーブル表示です。 <ISOIEC10646>。

      Code tables are also commonly called "code charts".

また、コードテーブルは一般的に「コードチャート」と呼ばれます。

Hoffman                      Informational                     [Page 14]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[14ページ]のRFC3536Terminology

4.1 Types of characters

キャラクタの4.1のタイプ

   The following definitions of types of characters do not clearly
   delineate each character into one type, nor do they allow someone to
   accurately predict what types would apply to a particular character.
   The definitions are intended for application designers to help them
   think about the many (sometimes confusing) properties of text.

キャラクタのタイプの以下の定義は明確に各キャラクタを1つのタイプに図で表わしません、そして、彼らはだれかが、どんなタイプが特定のキャラクタに当てはまるかを正確に予測するのを許しません。 定義はアプリケーション設計者が、彼らがテキストの多くの(時々紛らわしい)の特性について考えるのを助けることを意図します。

   alphabetic

アルファベット

      An informative Unicode property.  Characters that are the primary
      units of alphabets and/or syllabaries, whether combining or
      noncombining.  This includes composite characters that are
      canonical equivalents to a combining character sequence of an
      alphabetic base character plus one or more combining characters:
      letter digraphs; contextual variant of alphabetic characters;
      ligatures of alphabetic characters; contextual variants of
      ligatures; modifier letters; letterlike symbols that are
      compatibility equivalents of single alphabetic letters; and
      miscellaneous letter elements.  <UNICODE>

有益なユニコードの特性。 結合か非結合であることにかかわらずプライマリユニットのアルファベット、そして/または、音節表であるキャラクター。 これはキャラクタを結合するアルファベット基本文字と1つ以上の結合キャラクタシーケンスと正準な同等物である作られた登場人物を含んでいます: 手紙連字。 英字の文脈上の異形。 英字のひも。 ひもの文脈上の異形。 修飾語手紙。 ただ一つのアルファベット手紙の互換性同等物であるletterlikeシンボル。 そして、種々雑多な手紙要素。 <ユニコード>。

   ideographic

表意文字

      Any symbol that primarily denotes an idea (or meaning) in contrast
      to a sound (or pronunciation), for example, a symbol showing a
      telephone or the Han characters used in Chinese, Japanese, and
      Korean.  <UNICODE>

例えば電話を示しているシンボルかハンキャラクタが中国語、日本語、および韓国語で使用した音(または、発音)と対照して主として、考え(または、意味)を指示するどんなシンボル。 <ユニコード>。

   punctuation

句読

      Characters that separate units of text, such as sentences and
      phrases, thus clarifying the meaning of the text.  The use of
      punctuation marks is not limited to prose; they are also used in
      mathematical and scientific formulae, for example.  <UNICODE>

ユニットのテキストを切り離すその結果テキストの意味をはっきりさせる文や句などのキャラクター。 句読点の使用は散文に制限されません。 また、それらは例えば、数学的、そして、科学的な公式に使用されます。 <ユニコード>。

   symbol

シンボル

      One of a set of characters other than those used for letters,
      digits, or punctuation, and representing various concepts
      generally not connected to written language use per se.  Examples
      include symbols for mathematical operators, symbols for OCR,
      symbols for box-drawing or graphics, and symbols for dingbats.
      <NONE>

一般に、それら以外の文字、ケタ、または句読に使用される1セットのキャラクタのひとりと、様々な概念を表すのはそういうものとして文語使用に接続しませんでした。 例は数学のオペレータのシンボル、OCRのシンボル、箱図面かグラフィックスのシンボル、および装飾活字のシンボルを含んでいます。 <、>のいずれも

      Examples of symbols include characters for arrows, faces, and
      geometric shapes.  [UNICODE] has a property that defines
      characters as symbols.

シンボルに関する例は矢、表面、および幾何学上形のためのキャラクタを含んでいます。 [ユニコード]には、キャラクタをシンボルと定義する特性があります。

Hoffman                      Informational                     [Page 15]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[15ページ]のRFC3536Terminology

   nonspacing character

キャラクタを「非-区切」ります。

      A combining character whose positioning in presentation is
      dependent on its base character.  It generally does not consume
      space along the visual baseline in and of itself.  <UNICODE>

プレゼンテーションにおける位置決めが基本文字に依存している結合したキャラクタ。 一般に、それはそういうものの視覚基線に沿ってスペースを消費しません。 <ユニコード>。

      A combining acute accent (U+0301) is an example of a nonspacing
      character.

結合鋭アクセント(U+0301)は「非-区切」っているキャラクタに関する例です。

   diacritic

区別的発音符

      A mark applied or attached to a symbol to create a new symbol that
      represents a modified or new value.  They can also be marks
      applied to a symbol irrespective of whether it changes the value
      of that symbol.  In the latter case, the diacritic usually
      represents an independent value (for example, an accent, tone, or
      some other linguistic information).  Also called diacritical mark
      or diacritical.  <UNICODE>

マークは、変更されたか新しい値を表す新しいシンボルを作成するためにシンボルに適用したか、または付きました。 また、それらはそのシンボルの値を変えるかどうかの如何にかかわらずシンボルに適用されたマークであるかもしれません。 後者の場合では、通常、区別的発音符は独立している値(例えば、アクセント、トーン、またはある他の言語学の情報)を表します。 また、読み分け記号か識別的であると呼ばれます。 <ユニコード>。

   control character

制御文字

      The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F.
      They are also known as control codes.  <UNICODE>

範囲U+0000の65のキャラクタ。U+001FとU+007F.。U+009F。 また、それらは制御コードとして知られています。 <ユニコード>。

   formatting character

形式キャラクタ

      Characters that are inherently invisible but that have an effect
      on the surrounding characters.  <UNICODE>

本来目に見えないキャラクターにもかかわらず、それは周囲のキャラクタに影響を与えます。 <ユニコード>。

      Examples of formatting characters include characters for
      specifying the direction of text and characters that specify how
      to join multiple characters.

形式キャラクタに関する例はテキストの方向を指定するためのキャラクタと複数のキャラクタに加わる方法を指定するキャラクタを含んでいます。

   compatibility character

互換性キャラクタ

      A graphic character included as a coded character of ISO/IEC 10646
      primarily for compatibility with existing coded character sets.
      <ISOIEC10646>

図形文字は主として存在するとの互換性のためのISO/IEC10646のコード化されたキャラクタとしてコード化文字集合を含んでいました。 <ISOIEC10646>。

      For example, U+FF01 (FULLWIDTH EXCLAMATION MARK) was included for
      compatibility with Asian character sets that include full-width
      and half-width ASCII characters.

例えば、U+FF01(FULLWIDTH EXCLAMATION MARK)は全幅と半値幅ASCII文字を含んでいるアジアの文字集合との互換性のために含まれていました。

Hoffman                      Informational                     [Page 16]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[16ページ]のRFC3536Terminology

5. User interface for text

5. テキストのためのユーザーインタフェース

   Although the IETF does not standardize user interfaces, many
   protocols make assumptions about how a user will enter or see text
   that is used in the protocol.  Internationalization challenges
   assumptions about the type and limitations of the input and output
   devices that may be used with applications that use various
   protocols.  It is therefore useful to consider how users typically
   interact with text that might contain one or more non-ASCII
   characters.

IETFはユーザインタフェースを標準化しませんが、多くのプロトコルがユーザがプロトコルに使用されるテキストを入るか、またはどう見るかに関する仮定をします。 国際化は様々なプロトコルを使用するアプリケーションと共に使用されるかもしれない入出力装置のタイプと限界に関する仮定に挑戦します。 したがって、ユーザがどのように1人以上の非ASCII文字を含むかもしれないテキストと通常対話するかを考えるのは役に立ちます。

   input methods

入力メソッド

      An input method is a mechanism for a person to enter text into an
      application.  <NONE>

入力メソッドは人がアプリケーションにテキストを入れるメカニズムです。 <、>のいずれも

      Text can be entered into a computer in many ways.  Keyboards are
      by far the most common device used, but many characters cannot be
      entered on typical computer keyboards in a single stroke.  Many
      operating systems come with system software that lets users input
      characters outside the range of what is allowed by keyboards.

様々な意味でコンピュータにテキストを入れることができます。 キーボードは使用される中で断然最も一般的なデバイスですが、1つのストロークでは典型的なコンピュータのキーボードに多くのキャラクタを入れることができません。 多くのオペレーティングシステムがユーザがキーボードによって許容されていることに関する範囲の外でキャラクタを入力できるシステムソフトと共に来ます。

      For example, there are dozens of different input methods for Han
      characters in Chinese, Japanese, and Korean.  Some start with
      phonetic input through the keyboard, while others use the number
      of strokes in the character.  Input methods are also needed for
      scripts that have many diacritics, such as European characters
      that have two or three diacritics on a single alphabetic
      character.

例えば、中国語、日本語、および韓国語にはハンキャラクタのための何十もの異なった入力メソッドがあります。 或るものはキーボードを通した音声の入力から始まりますが、他のものはキャラクタのストロークの数を使用します。 また、入力メソッドが多くの区別的発音符を持っているスクリプトに必要です、ただ一つの英字に2か3つの区別的発音符を持っているヨーロッパ人のキャラクタなどのように。

   rendering rules

レンダリング規則

      A rendering rule is an algorithm that a system uses to decide how
      to display a string of text.  <NONE>

レンダリング規則はシステムがテキストのストリングを表示する方法を決めるのに使用するアルゴリズムです。 <、>のいずれも

      Some scripts can be directly displayed with fonts, where each
      character from an input stream can simply be copied from a glyph
      system and put on the screen or printed page.  Other scripts need
      rules that are based on the context of the characters in order to
      render text for display.

フォントと共にいくつかのスクリプトを直接表示できます、単に入力ストリームからの各キャラクタをglyphシステムからコピーして、スクリーンか印刷されたページに置くことができるところで。 他のスクリプトはディスプレイのためにテキストを表すためにキャラクタの文脈に基づいている規則を必要とします。

      Some examples of these rendering rules include:

これらのレンダリング規則に関するいくつかの例は:

         - Scripts such as Arabic (and many others), where the form of
           the letter changes depending on the adjacent letters, whether
           the letter is standing alone, at the beginning of a word, in
           the middle of a word, or at the end of a word.  The rendering
           rules must choose between two or more glyphs.

- アラビア語(そして、多くの他のもの)などのように、手紙が単語の中央か、単語の終わりに単独で語頭に立っているか否かに関係なく、原稿を書きます。そこでは、隣接している手紙によって、手紙のフォームが変化します。 レンダリング規則は2以上glyphsを選ばなければなりません。

Hoffman                      Informational                     [Page 17]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[17ページ]のRFC3536Terminology

         - Scripts such as the Indic scripts, where consonants may
           change their form if they are adjacent to certain other
           consonants or may be displayed in an order different from
           the way they are stored and pronounced.  The rendering rules
           must choose between two or more glyphs.

- インドのスクリプトなどのスクリプト、それらを他のある子音に隣接しているか、または道と異なったオーダーに表示するかもしれないなら子音がそれらのフォームを変えるかもしれないところでは、それらは、保存されて、発音されます。 レンダリング規則は2以上glyphsを選ばなければなりません。

         - Arabic and Hebrew scripts, where the order of the characters
           displayed are changed by the bidirectional properties of the
           alphabetic characters and with right-to-left and
           left-to-right ordering marks.  The rendering rules must
           choose the order that characters are displayed.

- アラビアの、そして、ヘブライの文字。(そこでは、キャラクタの注文が、英字の双方向の特性によって変えられて、右から左と左から右でマークを注文しながら、表示しました)。 表示して、規則がキャラクタがそうであるオーダーを選ばなければならないレンダリング。

   graphic symbol

図形

      A graphic symbol is the visual representation of a graphic
      character or of a composite sequence.  <ISOIEC10646>

図形は図形文字かコンポジット・シーケンスの視覚表現です。 <ISOIEC10646>。

   font

フォント

      A font is a collection of glyphs used for the visual depiction of
      character data.  A font is often associated with a set of
      parameters (for example, size, posture, weight, and serifness),
      which, when set to particular values, generate a collection of
      imagable glyphs.  <UNICODE>

フォントはキャラクタデータの視覚描写に使用されるglyphsの収集です。 フォントはしばしば1セットのパラメタ(例えば、サイズ、姿勢、重さ、およびセリフ)に関連しています。(特定の値に設定されると、パラメタはimagable glyphsの収集を作ります)。 <ユニコード>。

   bidirectional display

双方向のディスプレイ

      The process or result of mixing left-to-right oriented text and
      right-to-left oriented text in a single line is called
      bidirectional display.  <UNICODE>

右まで残っている混合のプロセスか結果がテキストを適応させました、そして、単線における右から左への指向のテキストは双方向のディスプレイと呼ばれます。 <ユニコード>。

      Most of the world's written languages are displayed left-to-right.
      However, many widely-used written languages such as ones based on
      the Hebrew or Arabic scripts are displayed right-to-left.  Right-
      to-left text often confuses protocol writers because they have to
      keep thinking in terms of the order of characters in a string in
      memory, and that order might be different than what they see on
      the screen.  (Note that some languages are written both
      horizontally and vertically.)

世界の文語の大部分は、表示された左から右です。 しかしながら、ヘブライの、または、アラビアの文字に基づくものなどの広く使用された多くの文語が、表示された右から左です。 彼らがメモリのストリングにおける、キャラクタの注文で思い続けなければならないので、正しい左のテキストはプロトコル作家をしばしば混乱させます、そして、そのオーダーは彼らがスクリーンで見るものと異なっているかもしれません。 (いくつかの言語が水平に垂直に書かれていることに注意してください。)

      Further, bidirectional text can cause confusion because there are
      formatting characters in ISO/IEC 10646 which cause the order of
      display of text to change.  These explicit formatting characters
      change the display regardless of the implicit left-to-right or
      right-to-left properties of characters.

さらに、テキストのディスプレイが変化する命令を引き起こすISO/IEC10646には形式キャラクタがあるので、双方向のテキストは混乱を引き起こす場合があります。 これらの明白な形式キャラクタは右から暗黙の左から右か左へのキャラクタの特性にかかわらずディスプレイを変えます。

Hoffman                      Informational                     [Page 18]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[18ページ]のRFC3536Terminology

      It is common to see strings with text in both directions, such as
      strings that include both text and numbers, or strings that
      contain a mixture of scripts.

両方の方向にテキストがあるストリングを見るのは一般的です、テキストと数の両方を含んでいるストリング、またはスクリプトの混合物を含むストリングなどのように。

      [UNICODE] has a long and incredibly detailed algorithm for
      displaying bidirectional text.

[ユニコード]には、双方向のテキストを表示するための長くて信じられないほど詳細なアルゴリズムがあります。

   undisplayable character

表示できないキャラクタ

      A character that has no displayable form.  <NONE>

「ディスプレイ-可能」が全く形成させられないキャラクタ。 <、>のいずれも

      For instance, the zero-width space (U+200B) cannot be displayed
      because it takes up no horizontal space.  Formatting characters
      such as those for setting the direction of text are also
      undisplayable.  Note, however, that every character in [UNICODE]
      has a glyph associated with it, and that the glyphs for
      undisplayable characters are enclosed in a dashed square as an
      indication that the actual character is undisplayable.

例えば、どんな水平なスペースも取らないので、ゼロ幅スペース(U+200B)を表示できません。 また、テキストの方向を設定するためのそれらなどの形式キャラクタも表示できないです。 しかしながら、[ユニコード]によるすべてのキャラクタがそれに関連しているglyphを持って、表示できないキャラクタのためのglyphsが実際のキャラクタが表示できないという指示として投げつけられた正方形で同封されることに注意してください。

6. Text in current IETF protocols

6. 現在のIETFプロトコルのテキスト

   Many IETF protocols started off being fully internationalized, while
   others have been internationalized as they were revised.  In this
   process, IETF members have seen patterns in the way that many
   protocols use text.  This section describes some specific protocol
   interactions with text.

完全に国際化していて、多くのIETFプロトコルが始められましたが、自分達が改訂されたとき、他のものは国際的にされました。 このプロセスでは、IETFメンバーは多くのプロトコルがテキストを使用する方法でパターンを見ました。 このセクションはテキストとのいくつかの特定のプロトコル相互作用について説明します。

   protocol elements

プロトコル要素

      Protocol elements are uniquely-named parts of a protocol.  <NONE>

プロトコル要素はプロトコルの唯一命名された部分です。 <、>のいずれも

      Almost every protocol has named elements, such as "source port" in
      TCP.  In some protocols, the names of the elements (or text tokens
      for the names) are transmitted within the protocol.  For example,
      in SMTP and numerous other IETF protocols, the names of the verbs
      are part of the command stream.   The names are thus part of the
      protocol standard.  The names of protocol elements are not
      normally seen by end users.

ほとんどあらゆるプロトコルがTCPの「ソースポート」などの要素を命名しました。 いくつかのプロトコルで、要素(または、名前のためのテキストトークン)の名前はプロトコルの中で伝えられます。 例えば、SMTPと他の多数のIETFプロトコルでは、動詞の名前はコマンドストリームの一部です。 その結果、名前はプロトコル標準の一部です。 通常、プロトコル要素の名前はエンドユーザによって見られません。

   name spaces

名前空間

      A name space is the set of valid names for a particular item, or
      the syntactic rules for generating these valid names.  <NONE>

名前スペースは、特定の項目のための妥当な名前のセット、またはこれらが妥当な名前であると生成するための構文の規則です。 <、>のいずれも

Hoffman                      Informational                     [Page 19]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[19ページ]のRFC3536Terminology

      Many items in Internet protocols use names to identify specific
      instances or values.  The names may be generated (by some
      prescribed rules),  registered centrally (e.g., such as with
      IANA), or have a distributed registration and control mechanism,
      such as the names in the DNS.

インターネットプロトコルの多くの項目が、特定のインスタンスか値を特定するのに名前を使用します。 名前には、生成されるか(規則が定められたいくつかで)、中心に登録するか(例えばIANAなどのように)、または分配された登録と制御機構があるかもしれません、DNSの名前などのように。

   on-the-wire encoding

ワイヤの上のコード化

      The encoding and decoding used before and after transmission over
      the network is often called the "on-the-wire" (or sometimes just
      "wire") format.  <NONE>

以前、ネットワークの上のトランスミッションがしばしば「ワイヤ」の(または、まさしく時々「ワイヤ」)形式と呼ばれた後に使用されるコード化と解読。 <、>のいずれも

      Characters are identified by codepoints.  Before being transmitted
      in a protocol, they must first be encoded as bits and octets.
      Similarly, when characters are received in a transmission, they
      have been encoded, and a protocol that needs to process the
      individual characters needs to decode them before processing.

キャラクターはcodepointsによって特定されます。 プロトコルで伝えられる前に、最初に、ビットと八重奏としてそれらをコード化しなければなりません。 トランスミッションでキャラクタを受け取るとき、同様に、彼らをコード化しました、そして、個性を処理する必要があるプロトコルは処理の前にそれらを解読する必要があります。

   parsed text

分析されたテキスト

      Text strings that is analyzed for subparts.  <NONE>

下位区分のために分析されるテキスト文字列。 <、>のいずれも

      In some protocols, free text in text fields might be parsed.  For
      example, many mail user agents will parse the words in the text of
      the Subject: field to attempt to thread based on what appears
      after the "Re:" prefix.

いくつかのプロトコルでは、テキストフィールドの無料のテキストは分析されるかもしれません。 例えば、多くのメールユーザエージェントがSubject:のテキストの単語を分析するでしょう。 「Re:」の後に現れることに基づいて縫うように通るのを試みる分野 前に置きます。

   charset identification

charset識別

      Specification of the charset used for a string of text.  <NONE>

テキストのストリングに使用されるcharsetの仕様。 <、>のいずれも

      Protocols that allow more than one charset to be used in the same
      place should require that the text be identified with the
      appropriate charset.  Without this identification, a program
      looking at the text cannot definitively discern the charset of the
      text.  Charset identification is also called "charset tagging".

1charsetが同じ箇所に使用されるのを許容するプロトコルは、テキストが適切なcharsetと同一視されているのを必要とするべきです。 この識別がなければ、テキストを見るプログラムはテキストのcharsetについて決定的に明察できません。 また、Charset識別は「charsetタグ付け」と呼ばれます。

   language identification

言語識別

      Specification of the human language used for a string of text.
      <NONE>

テキストのストリングに使用される人間の言語の仕様。 <、>のいずれも

      Some protocols (such as MIME and HTTP) allow text that is meant
      for machine processing to be identified with the language used in
      the text.  Such identification is important for machine-processing
      of the text, such as by systems that render the text by speaking
      it.  Language identification is also called "language tagging".

いくつかのプロトコル(MIMEやHTTPなどの)がマシン処理がテキストで使用される言語と同一視されることになっているテキストを許容します。 テキストのそれを話すことによってテキストを表すシステムなどのマシン処理に、そのような識別は重要です。 また、言語識別は「言語タグ付け」と呼ばれます。

Hoffman                      Informational                     [Page 20]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[20ページ]のRFC3536Terminology

   MIME

MIME

      MIME (Multipurpose Internet Mail Extensions) is a message format
      that allows for textual message bodies and headers in character
      sets other than US-ASCII in formats that require ASCII (most
      notably, [RFC2822], the standard for Internet mail headers).  MIME
      is described in RFCs 2045 through 2049, as well as more recent
      RFCs.  <NONE>

MIME(マルチパーパスインターネットメールエクステンション)はASCIIを必要とする形式における米国-ASCIIを除いた文字集合で原文のメッセージ本体とヘッダーを考慮するメッセージ・フォーマット(最も著しく、[RFC2822]、インターネットの規格はヘッダーに郵送する)です。 MIMEは、より最近のRFCsと同様に2049を通してRFCs2045で説明されます。 <、>のいずれも

   transfer encoding syntax

構文をコード化しながら、移してください。

      A transfer encoding syntax (TES) (sometimes called a transfer
      encoding scheme) is a reversible transform of already-encoded data
      that is represented in one or more character encoding schemes.
      <NONE>

構文(TES)(時々体系をコード化する転送と呼ばれます)をコード化する転送は1つ以上の文字符号化体系で表される既にコード化されたデータのリバーシブルの変換です。 <、>のいずれも

      TESs are useful for encoding types of character data into an
      another format, usually for allowing new types of data to be
      transmitted over legacy protocols.  The main examples of TESs used
      in the IETF include Base64 and quoted-printable.

キャラクタデータのタイプをコード化する、TESsが役に立つ通常、新しいタイプに関するデータがレガシープロトコルの上に送られるのを許容するための別の形式。 TESsのIETFインクルードBase64で中古の、そして、引用されて印刷可能な主な例。

   Base64

Base64

      Base64 is a transfer encoding syntax that allows binary data to be
      represented by the ASCII characters A through Z, a through z, 0
      through 9, +, /, and =.  It is defined in [RFC2045].  <NONE>

Base64はバイナリ・データがZ、aからz、0〜9、+、/、および=を通してASCII文字Aによって表されるのを許容する構文をコード化する転送です。それは[RFC2045]で定義されます。 <、>のいずれも

   quoted printable

引用、印刷可能

      Quoted printable is a transfer encoding syntax that allows strings
      that have non-ASCII characters mixed in with mostly ASCII
      printable characters to be somewhat human readable.  It is
      described in [RFC2047].  <NONE>

引用されて、印刷可能であるのは、いくらか人間であるためにほとんどASCIIの印刷可能なキャラクタに複雑である非ASCII文字を読み込み可能にするストリングを許容する構文をコード化する転送です。 それは[RFC2047]で説明されます。 <、>のいずれも

      The quoted printable syntax is generally considered to be a
      failure at being readable.  It is jokingly referred to as "quoted
      unreadable".

一般に、引用された印刷可能な構文は読み込み可能であるところの失敗であると考えられます。 「読みにくい状態で、引用されます」のように言及されて、それはふざけてそうです。

   XML

XML

      XML (which is an approximate abbreviation for Extensible Markup
      Language) is a popular method for structuring text.  XML text is
      explicitly tagged with charsets.  The specification for XML can be
      found at <http://www.w3.org/XML/>.  <NONE>

XML(拡張マークアップ言語のための大体の略語である)は、テキストを構造化するためのポピュラーなメソッドです。 XMLテキストはcharsetsで明らかにタグ付けをされます。 <http://www.w3.org/XML/><NONE>でXMLのための仕様を見つけることができます。

Hoffman                      Informational                     [Page 21]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[21ページ]のRFC3536Terminology

   ASN.1 text formats

ASN.1テキスト形式

      The ASN.1 data description language has many formats for text
      data.  The formats allow for different repertoires and different
      encodings.  Some of the formats that appear in IETF standards
      based on ASN.1 include IA5String (all ASCII characters),
      PrintableString (most ASCII characters, but missing many
      punctuation characters), BMPString (characters from ISO/IEC 10646
      plane 0 in UTF-16BE format), UTF8String (just as the name
      implies), and TeletexString (also called T61String; the repertoire
      changes over time).

ASN.1データ記述言語には、テキストデータのための多くの形式があります。 形式は異なったレパートリーと異なったencodingsを考慮します。 ASN.1に基づくIETF規格に現れる形式のいくつかがIA5String(すべてのASCII文字)、PrintableString(しかし、ほとんどのASCII文字、取り逃がす多くの句読文字)、BMPString(UTF-16BE形式におけるISO/IEC10646飛行機0からのキャラクタ)、UTF8String(ちょうど名前が含意するように)、およびTeletexString(また、呼ばれたT61String; 時間がたつにつれてのレパートリー変化)を含んでいます。

   ASCII-compatible encoding (ACE)

ASCIIコンパチブルコード化(ACE)

      Starting in 1996, many ASCII-compatible encoding schemes (which
      are actually transfer encoding syntaxes) have been proposed as
      possible solutions for internationalizing host names.  Their goal
      is to be able to encode any string of ISO/IEC 10646 characters as
      legal DNS host names (as described in STD 13).  At the time of
      this writing, no ACE has become an IETF standard.

1996年から、多くのASCIIコンパチブルコード化計画(実際に構文をコード化する転送である)がホスト名を国際的にする可能な解決策として提案されました。 それらの目標は法的なDNSが名前をホスティングするとき(STD13で説明されるように)ISO/IEC10646のキャラクタのどんなストリングもコード化することであることができます。 この書くこと時点で、ACEは全くIETF規格になっていません。

7. Other Common Terms In Internationalization

7. 国際化における他の一般的な用語

   This is a hodge-podge of other terms that have appeared in
   internationalization discussions in the IETF.  It is likely that
   additional terms will be added as this document matures.

これはIETFでの国際化議論に現れた他の用語の寄せ集めです。 このドキュメントが熟すとき、追加用語は加えられそうでしょう。

   locale

現場

      Locale is the user-specific location and cultural information
      managed by a computer.   <NONE>

現場は、コンピュータによって管理されたユーザ特有の位置と文化的な情報です。 <、>のいずれも

      Because languages differ from country to country (and even region
      to region within a country), the locale of the user can often be
      an important factor.  Typically, the locale information for a user
      includes the language(s) used.

言語が国から国(そして、国の中の領域への領域さえ)まで異なるので、しばしばユーザの現場は重要な要素であるかもしれません。 通常、ユーザへの現場情報は(s)が使用した言語を含んでいます。

      Locale issues go beyond character use, and can include things such
      as the display format for currency, dates, and times.  Some
      locales (especially the popular "C" and "POSIX" locales) do not
      include language information.

現場問題は、キャラクタ使用を越えて、通貨、日付、および何倍もシステム出力表示形式などのものを含むことができます。 いくつかの現場(特にポピュラーな「C」と"POSIX"現場)は言語情報を含んでいません。

      It should be noted that there are many thorny, unsolved issues
      with locale.  For example, should text be viewed using the locale
      information of the person who wrote the text or the person viewing
      it? What if the person viewing it is travelling to different
      locations? Should only some of the locale information affect
      creation and editing of text?

現場には多くのとげがあって、未解決の問題があることに注意されるべきです。 例えば、テキストは、テキストを書いた人かそれを見ている人の現場情報を使用することで見られるべきですか? それを見ている人が別の場所に旅行していると、どうなるでしょうか? 現場情報のいくつかだけがテキストの創造と編集に影響するべきですか?

Hoffman                      Informational                     [Page 22]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[22ページ]のRFC3536Terminology

   Latin characters

ラテン語のキャラクタ

      "Latin characters" is a not-precise term for characters
      historically related to ancient Greek script and currently used
      throughout the world.  <NONE>

「ラテン語のキャラクタ」は古代ギリシャ語スクリプトに歴史的に関連して、現在世界中で使用されているキャラクタへの正確でない用語です。 <、>のいずれも

      The base Latin characters make up the ASCII repertoire and have
      been augmented by many single and multiple diacritics and quite a
      few other characters.  ISO/IEC 10646 encodes the Latin characters
      in the ranges U+0020..U+024F, U+1E00..U+1EFF, and other ranges.

ベースラテン語キャラクタを、ASCIIレパートリーを作って、多くの単一で複数の区別的発音符と他のかなり多くのキャラクタが増大させました。 ISO/IEC10646は範囲Uで+0020にラテン語のキャラクタをコード化します。U+024Fと、U+1 00ユーロ。U+1EFF、および他の範囲。

   romanization

ローマ字化したもの

      The transliteration of a non-Latin script into Latin characters.
      <NONE>

ラテン語のキャラクタへの非ラテンスクリプトの音訳。 <、>のいずれも

      Because of the widespread use of Latin characters, people have
      tried to represent many languages that are not based on a Latin
      repertoire in Latin.  For example, there are two popular
      romanizations of Chinese: Wade-Giles and Pinyin, the latter of
      which is by far more common today.  Many romanization systems are
      inexact and do not give perfect round trip mappings between the
      native script and the Latin characters.

ラテン語のキャラクタの普及使用のために、人々はラテン語でラテン語のレパートリーに基づいていない多くの言語を表そうとしました。 例えば、中国語の2つのポピュラーなローマ字化したものがあります: それのウェイド-ジャイルスとピンイン、後者は今日、断然一般的です。 多くのローマ字化したものシステムは、不正確であり、固有のスクリプトとラテン語のキャラクタの間に完全な周遊旅行マッピングを与えません。

   CJK characters and Han characters

CJK文字とハンキャラクタ

      The ideographic characters used in Chinese, Japanese, Korean, and
      traditional Vietnamese writing systems are often called 'CJK
      characters' after the initial letters of the language names in
      English.  They are also called "Han characters", after the term in
      Chinese that is often used for these characters.  <NONE>

中国的、そして、日本的、そして、韓国的、そして、伝統的なベトナムの書記体系で使用される表意文字のキャラクタは言語名に関する大文字の後に英語でしばしば'CJK文字'と呼ばれます。 また、それらはこれらのキャラクタにしばしば使用される中国語の用語の後に「ハンキャラクタ」と呼ばれます。 <、>のいずれも

      Note that CJK and Han characters do not include the phonetic
      characters used in the Japanese and Korean languages.

CJKとハンキャラクタが日本の、そして、韓国の言語で使用される音声のキャラクタを入れないことに注意してください。

      In ISO/IEC 10646, the Han characters were "unified", meaning that
      each set of Han characters from Japanese, Chinese, and/or Korean
      that had the same origin was assigned a single code point.  The
      positive result of this was that many fewer code points were
      needed to represent Han; the negative result of this was that
      characters that people who write the three languages think are
      different have the same code point.  There is a great deal of
      disagreement on the nature, the origin, and the severity of the
      problems caused by Han unification.

ISO/IEC10646では、ハンキャラクタは「統一されました」、1コード・ポイントが同じ起源を持っていた日本語、中国語、そして/または、韓国語からのそれぞれのセットのハンキャラクタに割り当てられたことを意味して。 この肯定的な結果は多くの、より少ないコード・ポイントがハンの代理をするのに必要であったということでした。 この否定的結果は3つの言語を書く人々が異なると考えるキャラクタには同じコード・ポイントがあるということでした。 多くの不一致が漢字統合で引き起こされた問題の自然、起源、および厳しさにあります。

Hoffman                      Informational                     [Page 23]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[23ページ]のRFC3536Terminology

   translation

翻訳

      The process of conveying the meaning of some passage of text in
      one language, so that it can be expressed equivalently in another
      language.  <NONE>

別の言語で同等にそれを言い表すことができるように1つの言語のテキストのいくらかの通路の意味を伝える過程。 <、>のいずれも

      Many language translation systems are inexact and cannot be
      applied repeatedly to go from one language to another to another.

多くの言語翻訳システムは、不正確であり、1つの言語から別の言語まで別のものに行くために繰り返して適用できません。

   transliteration

音訳

      The process of representing the characters of an alphabetical or
      syllabic system of writing by the characters of a conversion
      alphabet.  <NONE>

変換アルファベットのキャラクタで書くアルファベット順の、または、音節のシステムのキャラクタの代理をする過程。 <、>のいずれも

      Many script transliterations are exact, and many have perfect
      round-trip mappings.  The notable exception to this is
      romanization, described above.  Transliteration involves
      converting text expressed in one script into another script,
      generally on a letter-by-letter basis.

多くのスクリプト音訳が正確です、そして、多くには、完全な往復のマッピングがあります。 これへの注目に値する例外は上で説明されたローマ字化したものです。 音訳は、一般に手紙による手紙ベースで1つのスクリプトで言い表されたテキストを別のスクリプトに変換することを伴います。

   transcription

転写

      The process of systematically writing the sounds of some passage
      of spoken language, generally with the use of a technical phonetic
      alphabet (usually Latin-based) or other systematic transcriptional
      orthography.  Transcription also sometimes refers to the
      conversion of written text into a transcribed (usually Latin-
      based) form, based on the sound of the text as if it had been
      spoken.  <NONE>

系統的に話し言葉と、一般に、技術的な音標文字の使用が(通常ラテン語ベース)か他でのいくらかの通路の音に系統的なtranscriptional綴り字法を書く過程。 また、転写は時々まるでそれが話されたかのようにテキストの音に基づく転写された(通常基づくラテン語)フォームと書かれたテキストの変換を呼びます。 <、>のいずれも

      Unlike transliterations, which are generally designed to be
      round-trip convertible, transcriptions of written material are
      almost never round-trip convertible to their original form.

音訳と異なって、資料の転写はそれらの原型へのほとんどの往復でないオープンカーです。一般に、音訳は、往復のオープンカーになるように設計されています。

   regular expressions

正規表現

      Regular expressions provide a mechanism to select specific strings
      from a set of character strings.  Regular expressions are a
      language used to search for text within strings, and possibly
      modify the text found with other text.  <NONE>

正規表現は、1セットの文字列から特定のストリングを選択するためにメカニズムを提供します。 正規表現は、ストリングの中にテキストを捜し求めるのに使用される言語であり、ことによると他のテキストで見つけられたテキストを変更します。 <、>のいずれも

      Pattern matching for text involves being able to represent one or
      more code points in an abstract notation, such as searching for
      all capital Latin letters or all punctuation.  The most common
      mechanism in IETF protocols for naming such patterns is the use of
      regular expressions.  There is no single regular expression
      language, but there are numerous very similar dialects.

テキストが1を表すことができるか、以上にかかわるので、パターン・マッチングは抽象的な記法でポイントをコード化します、すべての資本のラテン語の手紙かすべての句読を検索するのなどように。 そのようなパターンを命名するためのIETFプロトコルで最も一般的なメカニズムは正規表現の使用です。 どんなただ一つの正規表現言語もありませんが、多数の非常に同様の方言があります。

Hoffman                      Informational                     [Page 24]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[24ページ]のRFC3536Terminology

      The Unicode Consortium has a good discussion about how to adapt
      regular expression engines to use Unicode.  [UTR18]

ユニコードConsortiumはユニコードを使用するためにどう正規表現エンジンを適合させるかについての良い議論をします。 [UTR18]

   private use

私用

      ISO/IEC 10646 code points from U+E000 to U+F8FF, U+F0000 to
      U+FFFFD, and U+100000 to U+10FFFD are available for private use.
      This refers to code points of the standard whose interpretation is
      not specified by the standard and whose use may be determined by
      private agreement among cooperating users.  <UNICODE>

コードが000U+EからU+F8FFまで指すISO/IEC10646、U+FFFFDへのU+F0000、およびU+10FFFDへのU+100000は私的使用目的で利用可能です。 これは解釈が規格によって指定されないで、使用が協力関係を持っているユーザの中で個人的な協定で決定するかもしれない規格のコード・ポイントを示します。 <ユニコード>。

      The use of these "private use" characters is defined by the
      parties who transmit and receive them, and is thus not appropriate
      for standardization.  (The IETF has a long history of private use
      names for things such as "x-" names in MIME types, charsets, and
      languages.  The experience with these has been quite negative,
      with many implementors assuming that private use names are in fact
      public and long-lived.)

これらの「私用」キャラクタの使用は、彼らを送受信するパーティーによって定義されて、標準化には、その結果、適切ではありません。 (IETFには、MIMEの種類、charsets、および言語の「x」名などのもののための私用名の長い歴史があります。 これらの経験はかなり否定的です、多くの作成者が、私用名が事実上、公共であって、長命であると仮定していて。)

8.  Security Considerations

8. セキュリティ問題

   Security is not discussed in this document.

本書ではセキュリティについて議論しません。

9.  References

9. 参照

9.1 Normative References

9.1 標準の参照

   [ISOIEC10646] ISO/IEC 10646-1:2000.  International Standard --
                 Information technology -- Universal Multiple-Octet
                 Coded Character Set (UCS) -- Part 1: Architecture and
                 Basic Multilingual Plane, 2000.

[ISOIEC10646]ISO/IEC10646-1:2000。 国際規格--情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部: 構造的、そして、基本的な多言語飛行機、2000。

   [UNICODE]     The Unicode Standard, Version 3.2.0 is defined by The
                 Unicode Standard, Version 3.0 (Reading, MA, Addison-
                 Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
                 Unicode Standard Annex #27: Unicode 3.1
                 (http://www.unicode.org/reports/tr27/) and by the
                 Unicode Standard Annex #28: Unicode 3.2
                 (http://www.unicode.org/reports/tr28/), The Unicode
                 Consortium, 2002.

[ユニコード]ユニコードStandard、バージョン、3.2、.0、ユニコードStandard、バージョン3.0(読書、MA、アディソン・ウエスリー、2000ISBN0-201-61633-5)で、ユニコードStandard Annex#27によって修正されるように、定義されます: ( http://www.unicode.org/reports/tr27/ )とユニコード規格別館#28によるユニコード3.1: ユニコード3.2( http://www.unicode.org/reports/tr28/ )、ユニコード共同体、2002。

Hoffman                      Informational                     [Page 25]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[25ページ]のRFC3536Terminology

9.2 Informative References

9.2 有益な参照

   [CHARMOD]     Character Model for the World Wide Web 1.0, W3C,
                 <http://www.w3.org/TR/charmod/>.

WWW1.0のための[CHARMOD]キャラクターモデル、W3C、<http://www.w3.org/TR/charmod/>。

   [FRAMEWORK]   ISO/IEC TR 11017:1997(E).  Information technology -
                 Framework for internationalization, prepared by ISO/IEC
                 JTC 1/SC 22/WG 20, 1997.

[枠組み] ISO/IEC TR11017: 1997(E)。 情報技術--ISO/IEC JTC1/サウスカロライナ22/WG20、1997年までに準備された国際化のための枠組み。

   [ISO 639]     ISO 639:2000 (E/F) - Code for the representation of
                 names of languages, 2000.

[ISO639]ISO、639:2000 (E/F)--言語、2000年の名前の表現のためのコード。

   [ISO 3166]    ISO 3166:1988 (E/F) - Codes for the representation of
                 names of countries, 2000.

[ISO3166]ISO、3166:1988 (E/F)--国、2000年の名前の表現のためのコード。

   [RFC2045]     Freed, N. and N. Borenstein, "MIME Part One: Format of
                 Internet Message Bodies", November 1996.

解放された[RFC2045]、N.、およびN.Borenstein、「パート1をまねてください」 1996年11月の「インターネットメッセージ本体の形式。」

   [RFC2047]     Moore, K., "MIME Part Three: Message Header Extensions
                 for Non-ASCII Text", RFC 2047, November 1996.

[RFC2047]ムーア、K.、「パートThreeをまねてください」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。

   [RFC2277]     Alvestrand, H., "IETF Policy on Character Sets and
                 Languages", BCP 18, RFC 2277, January 1998.

[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。

   [RFC2279]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", RFC 2279, January 1998.

[RFC2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。

   [RFC2781]     Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
                 10646", RFC 2781, February 2000.

[RFC2781]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。

   [RFC2822]     Resnick, P., "Internet Message Format", RFC 2822, April
                 2001.

[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [RFC3066]     Alvestrand, H., "Tags for the Identification of
                 Languages", BCP 47, RFC 3066, January 2001.

[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。

   [US-ASCII]    Coded Character Set -- 7-bit American Standard Code for
                 Information Interchange, ANSI X3.4-1986, 1986.

[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986、1986。

   [UTN6]        "BOCU-1: MIME-Compatible Unicode Compression", M.
                 Scherer & M.  Davis, Unicode Technical Note #6.

[UTN6]、「BOCU-1:」 「MIMEコンパチブルユニコード圧縮」、M.シェーラーとM.デイヴィス、ユニコードテクニカルノート#6。

   [UTR6]        "A Standard Compression Scheme for Unicode", M. Wolf,
                 et. al., Unicode Technical Report #6.

[UTR6] et「ユニコードの標準の圧縮技術」、M.ヴォルフ、アル、ユニコードTechnical Report#6

   [UTR15]       "Unicode Normalization Forms", M. Davis & M. Duerst,
                 Unicode Technical Report #15.

[UTR15]「ユニコード正常化フォーム」、M.デイヴィス、およびM.Duerst、ユニコード技術報告書#15。

Hoffman                      Informational                     [Page 26]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[26ページ]のRFC3536Terminology

   [UTR18]       "Unicode Regular Expression Guidelines", M. Davis,
                 Unicode Technical Report #18.

[UTR18]「ユニコード正規表現ガイドライン」、M.デイヴィス、ユニコード技術報告書#18。

   [UTR19]       "UTF-32", M. Davis, Unicode Technical Report #19.

[UTR19] 「UTF-32インチ、M.デイヴィス、ユニコード技術報告書#19。」

   [UTR22]       "Character Mapping Markup Language", M. Davis, Unicode
                 Technical Report #22.

[UTR22]「キャラクターマッピングマークアップ言語」、M.デイヴィス、ユニコード技術報告書#22。

10. Additional Interesting Reading

10. 追加おもしろい読書

   ALA-LC Romanization Tables, Randall Barry (ed.), U.S. Library of
   Congress, 1997, ISBN 0844409405

ALA-LCローマ化テーブル、ランドルのバリトンサックス編、米国議会図書館、1997、ISBN0844409405

   Blackwell Encyclopedia of Writing Systems, Florian Coulmas, Blackwell
   Publishers, 1999, ISBN 063121481X

システム、フローリアンクルマスにブラックウェル出版社を書くブラックウェルEncyclopedia、1999、ISBN 063121481X

   The World's Writing Systems, Peter Daniels and William Bright, Oxford
   University Press, 1996, ISBN 0195079930

世界が明るくシステム、ピーター・ダニエル、およびウィリアムに書くオックスフォード大学出版局、1996、ISBN0195079930

   Writing Systems of the World, Akira Nakanishi, Charles E. Tuttle
   Company, 1980, ISBN 0804816549

世界、Akira中西、チャールズE.タトル社、1980、ISBN0804816549の書記体系

11. Index

11. インデックス

   alphabetic -- 4.1
   ASCII-compatible encoding (ACE) -- 6
   ASN.1 text formats -- 6
   Base64 -- 6
   Basic Multilingual Plane (BMP) -- 3.2
   bidirectional display -- 5
   BOCU-1 -- 3.2
   case -- 4
   character -- 2
   character encoding form -- 2
   character encoding scheme -- 2
   charset -- 2
   charset identification -- 6
   CJK characters and Han characters -- 7
   code chart -- 4
   code table -- 4
   coded character -- 2
   coded character set -- 2
   combining character -- 4
   compatibility character -- 4.1
   composite sequence -- 4
   control character -- 4.1
   diacritic -- 4.1
   displaying and rendering text -- 2

アルファベット((ACE)をコード化するASCIIコンパチブル4.1)の6ASN.1テキスト形式--6Base64--6 基本多言語水準(BMP)--3.2 双方向の表示--5BOCU-1--3.2ケース--4キャラクタ--2 フォームをコード化するキャラクタ; 2 計画をコード化するキャラクタ--2charset--2charset識別--6人のCJK文字とハンキャラクタ--7コード図--4コードテーブル--4はキャラクタ--2コード化文字集合--2の結合したキャラクタ--4互換性キャラクタ--4.1にコンポジット・シーケンス--4制御文字--4.1区別的発音符--4.1の表示と表現テキスト--2をコード化しました。

Hoffman                      Informational                     [Page 27]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[27ページ]のRFC3536Terminology

   font -- 5
   formatting character -- 4.1
   glyph -- 2
   glyph code -- 2
   graphic symbol -- 5
   i18n, l10n -- 2
   ideographic -- 4.1
   input methods -- 5
   internationalization -- 2
   ISO -- 3.1
   language -- 2
   language identification -- 6
   Latin characters -- 7
   local and regional standards organizations -- 3.1
   locale -- 7
   localization -- 2
   MIME -- 6
   multilingual -- 2
   name spaces -- 6
   nonspacing character -- 4.1
   normalization -- 4
   on-the-wire encoding -- 6
   parsed text -- 6
   private use -- 7
   protocol elements -- 6
   punctuation -- 4.1
   quoted printable -- 6
   regular expressions -- 7
   rendering rules -- 5
   romanization -- 7
   script -- 2
   SCSU -- 3.2
   sorting and collation -- 4
   symbol -- 4.1
   transcoding -- 2
   transcription -- 7
   transfer encoding syntax -- 6
   translation -- 7
   transliteration -- 7
   UCS-2 and UCS-4 -- 3.2
   undisplayable character -- 5
   Unicode Consortium -- 3.1
   UTF-32 -- 3.2
   UTF-16, UTF-16BE, and UTF-16LE -- 3.2
   UTF-8 -- 3.2
   World Wide Web Consortium -- 3.1
   XML -- 6

字体--5 形式キャラクタ--4.1glyph--2 glyphコード--2図形--5i18n、l10n--2 表意文字(4.1の入力方法)の5国際化--2ISO; 3.1 言語--2言語識別--6つのラテン語のキャラクタ--7 地方の、そして、地方の規格組織--3.1現場--7ローカライズ--2MIME--6 多言語(2つの名前空間)の6「非-区切」っているキャラクタ; 4.1 正常化--4 ワイヤの上のコード化--6 分析されたテキスト--6私用--4.1が引用した印刷可能な7個のプロトコル要素(6句読)--6つの正規表現--7 表現は統治されます--5ローマ字化したもの; 7 スクリプト--2SCSU--6構文--翻訳--7音訳--7UCS-2とUCS-4--3.2の表示できないキャラクタ--5ユニコードConsortium--3.1UTF-32--3.2UTF-16、UTF-16BE、およびUTF-16LE--3.2UTF-8--3.2WWW Consortium--3.1XML--6をコード化するソーティングと照合--4シンボル--4.1コード変換--2転写--7が移す3.2

Hoffman                      Informational                     [Page 28]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[28ページ]のRFC3536Terminology

A. Acknowledgements

A。 承認

   The definitions in this document come from many sources, including a
   wide variety of IETF documents.

定義はさまざまなIETFドキュメントを含む多くのソースから本書では来ます。

   James Seng contributed to the initial outline of this document.
   Harald Alvestrand and Martin Duerst made extensive useful comments on
   early versions.  Others who contributed to the development include:

ジェームスSengはこのドキュメントに関する原形線に貢献しました。 ハラルドAlvestrandとマーチンDuerstは早めのバージョンの大規模な役に立つコメントをしました。 開発に貢献した他のものは:

      Dan Kohn
      Jacob Palme
      Johan van Wingen
      Peter Constable
      Yuri Demchenko
      Susan Harris
      Zita Wenzel
      John Klensin
      Henning Schulzrinne
      Leslie Daigle
      Markus Scherer
      Ken Whistler

ダンコーンヤコブパルメジョハンバンWingenピーターコンスタブルユリDemchenkoスーザンハリスZitaウェンツェルジョンKlensinヘニングSchulzrinneレスリーDaigleマーカスシェーラーケンウィスラー

B. Author's Address

B。 作者のアドレス

   Paul Hoffman
   Internet Mail Consortium and VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060 USA

ポールホフマンインターネットメール共同体とVPN共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)

   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org

メール: paul.hoffman@imc.org とpaul.hoffman@vpnc.org

Hoffman                      Informational                     [Page 29]

RFC 3536  Terminology Used in Internationalization in the IETF  May 2003

2003年5月にIETFでの国際化に使用されたホフマン情報[29ページ]のRFC3536Terminology

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Hoffman                      Informational                     [Page 30]

ホフマンInformationalです。[30ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ソフトウエアRAIDでストレージを構築しマウントする方法 ディスクの高速化・冗長化

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る