[要約] RFC 2277は、IETFが文字セットと言語に関するポリシーを定めるためのガイドラインです。その目的は、インターネットプロトコルの開発や運用において、文字セットと言語の適切な使用を促進することです。
Network Working Group H. Alvestrand
Request for Comments: 2277 UNINETT
BCP: 18 January 1998
Category: Best Current Practice
IETF Policy on Character Sets and Languages
文字セットと言語に関するIETFポリシー
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
The Internet is international.
インターネットは国際的です。
With the international Internet follows an absolute requirement to interchange data in a multiplicity of languages, which in turn utilize a bewildering number of characters.
国際的なインターネットでは、多数の言語でデータを交換するという絶対的な要件に従っており、途方もない数の文字を利用しています。
This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements.
このドキュメントは、インターネットエンジニアリングステアリンググループ（IESG）がインターネットエンジニアリングタスクフォース（IETF）での標準化に向けて適用している現在のポリシーであり、インターネットプロトコルがこれらの要件を満たすのを支援します。
The document is very much based upon the recommendations of the IAB Character Set Workshop of February 29-March 1, 1996, which is documented in RFC 2130 [WR]. This document attempts to be concise, explicit and clear; people wanting more background are encouraged to read RFC 2130.
このドキュメントは、RFC 2130 [WR]に文書化されている、1996年2月29日〜3月1日のIAB文字セットワークショップの推奨に非常に基づいています。このドキュメントは、簡潔、明示的、明確になるように努めています。背景をもっと知りたい人はRFC 2130を読むことをお勧めします。
The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in [RFC 2119]. In this case, 'the specification' as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process.
このドキュメントでは、[RFC 2119]で説明されている方法で、「必須」、「SHOULD」、「MAY」、およびそれらの否定語を使用しています。この場合、RFC 2119で使用される「仕様」は、IETF標準プロセスに提出されるプロトコルの処理を指します。
Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are. Where protocol elements look like text tokens, such as in many IETF application layer protocols, protocols MUST specify which parts are protocol and which are text. [WR 2.2.1.1]
国際化は人間のためのものです。つまり、プロトコルは国際化の対象ではありません。テキスト文字列です。多くのIETFアプリケーション層プロトコルなどのように、プロトコル要素がテキストトークンのように見える場合、プロトコルは、プロトコルである部分とテキストである部分を指定する必要があります。 [WR 2.2.1.1]
Names are a problem, because people feel strongly about them, many of them are mostly for local usage, and all of them tend to leak out of the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII for all globally visible names.
名前は問題です。人々はそれらについて強く感じるので、それらの多くは主にローカルでの使用のためのものであり、それらすべては時々ローカルコンテキストからリークする傾向があります。 RFC 1958 [RFC 1958]では、グローバルに表示されるすべての名前にUS-ASCIIを推奨しています。
This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII.
このドキュメントでは、名前の国際化に関するポリシーを義務付けていませんが、すべてのプロトコルで名前が国際化されているかUS-ASCIIであるかを説明する必要があります。
NOTE: In the protocol stack for any given application, there is usually one or a few layers that need to address these problems.
注：特定のアプリケーションのプロトコルスタックには、通常、これらの問題に対処する必要がある1つまたはいくつかのレイヤーがあります。
It would, for instance, not be appropriate to define language tags for Ethernet frames. But it is the responsibility of the WGs to ensure that whenever responsibility for internationalization is left to "another layer", those responsible for that layer are in fact aware that they HAVE that responsibility.
たとえば、イーサネットフレームの言語タグを定義することは適切ではありません。しかし、国際化の責任が「別の層」に委ねられている場合は常に、その層の責任者が実際にその責任を負っていることを確実にすることは、WGの責任です。
This document uses the term "charset" to mean a set of rules for mapping from a sequence of octets to a sequence of characters, such as the combination of a coded character set and a character encoding scheme; this is also what is used as an identifier in MIME "charset=" parameters, and registered in the IANA charset registry [REG]. (Note that this is NOT a term used by other standards bodies, such as ISO).
このドキュメントでは、「charset」という用語を使用して、オクテットのシーケンスから文字のシーケンスにマッピングするための一連のルールを意味します。たとえば、コード化文字セットと文字エンコードスキームの組み合わせなどです。これは、MIMEの "charset ="パラメータで識別子として使用され、IANA文字セットレジストリ[REG]に登録されるものでもあります。 （これは、ISOなどの他の標準化団体が使用している用語ではないことに注意してください）。
For a definition of the term "coded character set", refer to the workshop report.
「コード化文字セット」という用語の定義については、ワークショップのレポートを参照してください。
A "name" is an identifier such as a person's name, a hostname, a domainname, a filename or an E-mail address; it is often treated as an identifier rather than as a piece of text, and is often used in protocols as an identifier for entities, without surrounding text.
「名前」は、個人の名前、ホスト名、ドメイン名、ファイル名、電子メールアドレスなどの識別子です。多くの場合、テキストの一部ではなく識別子として扱われ、プロトコルでは周囲のテキストなしでエンティティの識別子としてよく使用されます。
All protocols MUST identify, for all character data, which charset is in use.
すべてのプロトコルは、すべての文字データについて、どの文字セットが使用されているかを識別しなければなりません。
Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text.
プロトコルは、[10646] Annex R（改正2で公開）で定義されているように、UTF-8文字コード化スキームと組み合わされたISO 10646コード化文字セットで構成されるUTF-8文字セットをすべてのテキストに使用できる必要があります。
Protocols MAY specify, in addition, how to use other charsets or other character encoding schemes for ISO 10646, such as UTF-16, but lack of an ability to use UTF-8 is a violation of this policy; such a violation would need a variance procedure ([BCP9] section 9) with clear and solid justification in the protocol specification document before being entered into or advanced upon the standards track.
プロトコルは、さらに、UTF-16などのISO 10646用の他の文字セットまたは他の文字エンコーディングスキームの使用方法を指定する場合がありますが、UTF-8を使用する機能がないことは、このポリシーの違反です。このような違反には、標準化手順に入る前、または標準化過程に進む前に、プロトコル仕様文書に明確で根拠のある差異手順（[BCP9]セクション9）が必要です。
For existing protocols or protocols that move data from existing datastores, support of other charsets, or even using a default other than UTF-8, may be a requirement. This is acceptable, but UTF-8 support MUST be possible.
既存のプロトコルまたは既存のデータストアからデータを移動するプロトコルの場合、他の文字セットのサポート、またはUTF-8以外のデフォルトの使用さえも必要になる場合があります。これは許容されますが、UTF-8サポートが可能でなければなりません。
When using other charsets than UTF-8, these MUST be registered in the IANA charset registry, if necessary by registering them when the protocol is published.
UTF-8以外の文字セットを使用する場合、必要に応じてプロトコルの公開時に登録することにより、これらをIANA文字セットレジストリに登録する必要があります。
(Note: ISO 10646 calls the UTF-8 CES a "Transformation Format" rather than a "character encoding scheme", but it fits the charset workshop report definition of a character encoding scheme).
（注：ISO 10646は、UTF-8 CESを「文字エンコードスキーム」ではなく「変換フォーマット」と呼んでいますが、文字エンコードスキームの文字セットワークショップレポート定義に適合しています）。
When the protocol allows a choice of multiple charsets, someone must make a decision on which charset to use.
プロトコルで複数の文字セットを選択できる場合、使用する文字セットを誰かが決定する必要があります。
In some cases, like HTTP, there is direct or semi-direct communication between the producer and the consumer of data containing text. In such cases, it may make sense to negotiate a charset before sending data.
HTTPのように、テキストを含むデータのプロデューサーとコンシューマーの間で直接または半直接の通信が行われる場合があります。そのような場合、データを送信する前に文字セットをネゴシエートすることは意味があります。
In other cases, like E-mail or stored data, there is no such communication, and the best one can do is to make sure the charset is clearly identified with the stored data, and choosing a charset that is as widely known as possible.
電子メールや保存されたデータのような他の場合では、そのような通信は行われません。最善の方法は、保存されたデータで文字セットを明確に識別し、できるだけ広く知られている文字セットを選択することです。
Note that a charset is an absolute; text that is encoded in a charset cannot be rendered comprehensibly without supporting that charset.
文字セットは絶対であることに注意してください。文字セットでエンコードされたテキストは、その文字セットをサポートしないと、包括的にレンダリングできません。
(This also applies to English texts; charsets like EBCDIC do NOT have ASCII as a proper subset) Negotiating a charset may be regarded as an interim mechanism that is to be supported until support for interchange of UTF-8 is prevalent; however, the timeframe of "interim" may be at least 50 years, so there is every reason to think of it as permanent in practice.
（これは英語のテキストにも適用されます。EBCDICのような文字セットには、適切なサブセットとしてASCIIがありません）文字セットのネゴシエーションは、UTF-8の交換のサポートが普及するまでサポートされる暫定的なメカニズムと見なされる場合があります。ただし、「中間」の期間は少なくとも50年になる可能性があるため、実際には永続的であると考えるのにはあらゆる理由があります。
All human-readable text has a language.
人間が読めるテキストにはすべて言語があります。
Many operations, including high quality formatting, text-to-speech synthesis, searching, hyphenation, spellchecking and so on benefit greatly from access to information about the language of a piece of text. [WC 3.1.1.4].
高品質のフォーマット、音声合成、検索、ハイフネーション、スペルチェックなどの多くの操作は、テキストの言語に関する情報へのアクセスから大きな恩恵を受けます。 [WC 3.1.1.4]。
Humans have some tolerance for foreign languages, but are generally very unhappy with being presented text in a language they do not understand; this is why negotiation of language is needed.
人間は外国語に対してある程度の寛容を持っていますが、一般的に、理解できない言語でテキストが提示されることに非常に不満です。これが言語の交渉が必要な理由です。
In most cases, machines will not be able to deduce the language of a transmitted text by themselves; the protocol must specify how to transfer the language information if it is to be available at all.
ほとんどの場合、マシンは送信されたテキストの言語を自分で推定することはできません。プロトコルは、言語情報を使用できるようにする場合、言語情報の転送方法を指定する必要があります。
The interaction between language and processing is complex; for instance, if I compare "name-of-thing(lang=en)" to "name-of-thing(lang=no)" for equality, I will generally expect a match, while the word "ask(no)" is a kind of tree, and is hardly useful as a command verb.
言語と処理の間の相互作用は複雑です。たとえば、「name-of-thing（lang = en）」と「name-of-thing（lang = no）」を比較して等しいかどうかを比較すると、「ask（no）」という単語が一致しているのが普通です。は一種のツリーであり、コマンド動詞としてはほとんど役に立ちません。
Protocols that transfer text MUST provide for carrying information about the language of that text.
テキストを転送するプロトコルは、そのテキストの言語に関する情報を運ぶために提供しなければなりません。
Protocols SHOULD also provide for carrying information about the language of names, where appropriate.
プロトコルは、必要に応じて、名前の言語に関する情報を提供する必要もあります。
Note that this does NOT mean that such information must always be present; the requirement is that if the sender of information wishes to send information about the language of a text, the protocol provides a well-defined way to carry this information.
これは、そのような情報が常に存在している必要があることを意味しないことに注意してください。要件は、情報の送信者がテキストの言語に関する情報を送信したい場合、プロトコルがこの情報を伝達するための明確な方法を提供することです。
The RFC 1766 language tag is at the moment the most flexible tool available for identifying a language; protocols SHOULD use this, or provide clear and solid justification for doing otherwise in the document.
RFC 1766言語タグは現在、言語を識別するために利用できる最も柔軟なツールです。プロトコルは、これを使用する必要があります。または、ドキュメントでそれ以外のことを行うための明確で確実な正当化を提供してください。
Note also that a language is distinct from a POSIX locale; a POSIX locale identifies a set of cultural conventions, which may imply a language (the POSIX or "C" locale of course do not), while a language tag as described in RFC 1766 identifies only a language.
また、言語はPOSIXロケールとは異なります。 POSIXロケールは、言語を意味する可能性がある一連の文化的規則を識別します（もちろん、POSIXまたは "C"ロケールはそうではありません）。一方、RFC 1766で説明されている言語タグは言語のみを識別します。
Protocols where users have text presented to them in response to user actions MUST provide for support of multiple languages.
ユーザーのアクションに応じてユーザーがテキストを提示するプロトコルは、複数の言語のサポートを提供する必要があります。
How this is done will vary between protocols; for instance, in some cases, a negotiation where the client proposes a set of languages and the server replies with one is appropriate; in other cases, a server may choose to send multiple variants of a text and let the client pick which one to display.
これがどのように行われるかはプロトコルによって異なります。たとえば、場合によっては、クライアントが一連の言語を提案し、サーバーが1つの言語で応答する交渉が適切です。他の場合では、サーバーはテキストの複数の変形を送信することを選択し、クライアントにどれを表示するかを選択させることができます。
Negotiation is useful in the case where one side of the protocol exchange is able to present text in multiple languages to the other side, and the other side has a preference for one of these; the most common example is the text part of error responses, or Web pages that are available in multiple languages.
ネゴシエーションは、プロトコル交換の一方が複数の言語でテキストをもう一方に提示でき、もう一方がこれらのいずれかを優先する場合に役立ちます。最も一般的な例は、エラー応答のテキスト部分、または複数の言語で利用可能なWebページです。
Negotiating a language should be regarded as a permanent requirement of the protocol that will not go away at any time in the future.
言語のネゴシエーションは、将来いつかなくなることのないプロトコルの永続的な要件と見なされます。
In many cases, it should be possible to include it as part of the connection establishment, together with authentication and other preferences negotiation.
多くの場合、認証やその他のプリファレンスネゴシエーションとともに、接続確立の一部としてそれを含めることができるはずです。
When human-readable text must be presented in a context where the sender has no knowledge of the recipient's language preferences (such as login failures or E-mailed warnings, or prior to language negotiation), text SHOULD be presented in Default Language.
人間が読めるテキストを、送信者が受信者の言語設定を知らない状況（ログインの失敗や電子メールによる警告、または言語交渉の前など）で提示する必要がある場合、テキストはデフォルト言語で提示する必要があります（SHOULD）。
Default Language is assigned the tag "i-default" according to the procedures of RFC 1766. It is not a specific language, but rather identifies the condition where the language preferences of the user cannot be established.
デフォルト言語には、RFC 1766の手順に従ってタグ「i-default」が割り当てられています。これは特定の言語ではなく、ユーザーの言語設定を確立できない条件を識別します。
Messages in Default Language MUST be understandable by an English-speaking person, since English is the language which, worldwide, the greatest number of people will be able to get adequate help in interpreting when working with computers.
デフォルトの言語でのメッセージは、英語を話す人が理解できる必要があります。英語は、世界中で最も多くの人がコンピュータを操作する際に十分な解釈を得ることができる言語だからです。
Note that negotiating English is NOT the same as Default Language; Default Language is an emergency measure in otherwise unmanageable situations.
英語の交渉はデフォルト言語と同じではないことに注意してください。デフォルト言語は、他の方法では管理できない状況での緊急対策です。
In many cases, using only English text is reasonable; in some cases, the English text may be augumented by text in other languages.
多くの場合、英語のテキストのみを使用するのが妥当です。場合によっては、英語のテキストに他の言語のテキストが追加されることがあります。
The POSIX standard [POSIX] defines a concept called a "locale", which includes a lot of information about collating order for sorting, date format, currency format and so on.
POSIX標準[POSIX]は、「ロケール」と呼ばれる概念を定義しています。これには、並べ替えの照合順序、日付形式、通貨形式などに関する多くの情報が含まれています。
In some cases, and especially with text where the user is expected to do processing on the text, locale information may be usefully attached to the text; this would identify the sender's opinion about appropriate rules to follow when processing the document, which the recipient may choose to agree with or ignore.
場合によっては、特にユーザーがテキストの処理を行うことが予想されるテキストの場合、ロケール情報をテキストに添付すると便利です。これは、ドキュメントを処理するときに従うべき適切なルールに関する送信者の意見を識別し、受信者は同意するか無視するかを選択できます。
This document does not require the communication of locale information on all text, but encourages its inclusion when appropriate.
このドキュメントでは、すべてのテキストでロケール情報を伝達する必要はありませんが、必要に応じて含めることをお勧めします。
Note that language and character set information will often be present as parts of a locale tag (such as no_NO.iso-8859-1; the language is before the underscore and the character set is after the dot); care must be taken to define precisely which specification of character set and language applies to any one text item.
言語と文字セットの情報は、多くの場合、ロケールタグの一部として存在します（no_NO.iso-8859-1など。言語はアンダースコアの前にあり、文字セットはドットの後ろにあります）。文字セットと言語のどの仕様を1つのテキスト項目に適用するかを正確に定義するように注意する必要があります。
The default locale is the "POSIX" locale.
デフォルトのロケールは「POSIX」ロケールです。
In documents that deal with internationalization issues at all, a synopsis of the approaches chosen for internationalization SHOULD be collected into a section called "Internationalization considerations", and placed next to the Security Considerations section.
国際化の問題を扱うドキュメントでは、国際化のために選択されたアプローチの概要を「国際化の考慮事項」と呼ばれるセクションにまとめ、セキュリティの考慮事項セクションの横に配置する必要があります。
This provides an easy reference for those who are looking for advice on these issues when implementing the protocol.
これは、プロトコルを実装するときにこれらの問題に関するアドバイスを探している人に簡単なリファレンスを提供します。
Apart from the fact that security warnings in a foreign language may cause inappropriate behaviour from the user, and the fact that multilingual systems usually have problems with consistency between language variants, no security considerations relevant have been identified.
外国語のセキュリティ警告がユーザーに不適切な動作を引き起こす可能性があるという事実、および多言語システムでは通常、言語バリアント間の一貫性に問題があるという事実を除いて、関連するセキュリティの考慮事項は確認されていません。
[10646] ISO/IEC, Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, May 1993, with amendments
[10646] ISO / IEC、情報技術-ユニバーサル複数オクテットコード化文字セット（UCS）-パート1：アーキテクチャと基本的な多言語プレーン、1993年5月、修正あり
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[WR] Weider, C., Preston, C., Simonsen, K., Alvestrand, H, Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[WR]ウィダー、C、プレストン、C、サイモンセン、K、アルベストランド、H、アトキンソン、R、クリスピン、M、およびP.スヴァンバーグ、「IABキャラクターセットワークショップのレポート、2月29日開催- 1996年3月1日」、RFC 2130、1997年4月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958] Carpenter、B。、「Architectural Principles of the Internet」、RFC 1958、1996年6月。
[POSIX]
ISO/IEC 9945-2:1993 Information technology -- Portable Operating
System Interface (POSIX) -- Part 2: Shell and Utilities
[REG] Freed, N., and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.
[REG] Freed、N.、J。Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2278、1998年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996.
[BCP9] Bradner、S.、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
Harald Tveit Alvestrand UNINETT P.O.Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY
Harald Tveit Alvestrand UNINETT P.O. Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY
Phone: +47 73 59 70 94
EMail: Harald.T.Alvestrand@uninett.no
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。