Copyright © 2014-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、仕様を開発する際の国際化関連の考慮事項のチェックリストを提供します。 ほとんどのチェックリスト項目は、他の文書にある詳細な補足情報を指しています。そのような 情報がまだ存在しない場合は、この文書の中に一時的な置き場所を設けることができます。この文書の 情報は、新しい内容が追加され、既存の内容が経験と議論を踏まえて修正されるにつれて、 定期的に変更されます。
この節では、この文書の公開時点における ステータスについて説明します。現在の W3C 公開物の一覧およびこの技術報告書の最新版は、 W3C 標準および草案の 索引で確認できます。
この文書は、国際的な利用のための要件を仕様へ組み込む方法について、仕様策定者に助言を提供します。 現在ここで提供されている内容は直ちに役立つことが期待されますが、依然として 初期草案であり、文書は変更が続いています。また、レビューや 議論で得られた知見がガイドラインとして具体化されるにつれて、内容は拡充されます。
この文書は、国際化 ワーキンググループによって、 ノート トラックを使用したグループノートとして公開されました。
このグループノートは、 国際化ワーキンググループによって承認されていますが、 W3C 自体およびその メンバーによって承認されたものではありません。
W3C 特許 ポリシーは、 この文書にライセンス要件または確約を 課しません。
この文書には、 2025年8月18日付の W3C プロセス文書が適用されます。
仕様の策定者には、自らが作成するものが世界中のコミュニティで機能することを保証するための助言が必要です。
国際化（i18n）ワーキンググループは、仕様をレビューし、議論に参加することによって、各ワーキンググループを支援しようとしています。 しかし、多くの場合、このような介入は理想的な時期よりも遅い段階で行われるか、または i18nワーキンググループが、関係する各ワーキンググループに同じ情報を繰り返し伝える必要が生じます。
仕様の策定者が、必要な箇所で説明、例、および根拠を参照できるベストプラクティスのチェックリストにアクセスできれば、 より良いでしょう。そうすれば、策定者はこの知識を作業の初期段階から取り入れることができ、 i18nワーキンググループが仕様をレビューする際に必要となる手戻りを減らすことができます。
この文書にはチェックリストの初期版が含まれており、提示された推奨事項の説明、例、および根拠を確認できる場所を 示しています。 そのような情報を掲載する別の場所がない場合は、 追加情報がこの文書に加えられます。この文書は、アイデアを発展させ、整理するためにも使用できます。
この文書のガイドラインは、厳格で絶対的な要件を意図したものではありません。ガイドラインを理解できない場合や 同意できない場合に、何をすべきかを議論するため国際化ワーキンググループへ連絡してもらえれば、 この文書はその目的の重要な部分を達成したことになります。
この文書では、自然言語という用語は通常、 人間が利用することを意図した文書またはプロトコルの部分を指すために使用されます。ローカライズ可能な テキストという用語は、形式言語、プロトコル構文などに含まれる自然言語コンテンツを、構文コンテンツまたはユーザー指定値と区別して指すために使用されます。 これらおよび国際化ワーキンググループが使用するその他の用語の定義については、 [I18N-GLOSSARY]を参照してください。
仕様の国際化レビューを支援するため、このページにはチェックリスト機能が用意されています。 レビュー結果はGitHubのissueに投稿する必要があります。
仕様に関連する各節について、次の手順に従ってください。
国際化に関する考慮事項の節へのすべての追加または変更は、 国際化（i18n）ワーキンググループによってレビューされなければなりません。
国際化に関する考慮事項の節を作成する場合、そのタイトルは 国際化に関する考慮事項または 国際化（i18n）に関する考慮事項でなければなりません。
仕様には、その仕様における国際化上の考慮事項を説明する特別な節または附属書を含めることは要求されません。 一般に、国際化ワーキンググループは代わりに、言語、地域、文化による差異、対応、または適応に関する情報を、 関連する機能と密接に関連付けて仕様本文に記載することを推奨します。
ただし、このような節の提供を検討できる場合がいくつかあります。次の場合には、 国際化に関する考慮事項の節を含めることを検討してください。
国際化に関する考慮事項の節を作成する場合、通常は附属書として配置します。 ただし、仕様の他の部分または他の附属書に対する順序と配置は任意です。
国際化に関する考慮事項の節を作成する場合は、国際化ワーキンググループへの 水平レビュー依頼でそのことに言及する必要があります。レビュー依頼テンプレートには、 これを簡単に行うためのチェックボックスが含まれています。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、 2番目のチェックボックスを選択してください。その後、「GitHub用のMarkdownを作成」ボタンをクリックし、 結果をGitHubのissue一覧へコピーしてください。詳細を参照してください。
言語の基本
langおよびXMLの
xml:lang言語属性を使用して、
テキスト処理言語を特定してください。詳細
langおよびXMLの
xml:lang言語属性を使用するべきではありません。
それらがメタデータ（特定のテキスト範囲の言語ではなく、リソースの意図された用途を示すもの）を表す場合は、
別の属性を使用するべきです。詳細
言語値の定義
言語の宣言
文字列の言語の特定
zxx
（「言語コンテンツなし」）を関連付けることを推奨するべきです。詳細und
（「未判定」）を関連付けることを推奨するべきです。仕様は、適切な場合、
ヒューリスティックの使用または他のフィールド値からの言語の推論を許可してもよいです。詳細U+E0000からU+E007F）を
使用するべきではありません。詳細
@contextおよび組み込みの
@language属性を使用することが推奨されます。詳細
i18n名前空間機能を使用するべきです。詳細i18n名前空間を利用できない場合、または使用が適切でない場合、
仕様は、自然言語の値に文字列固有の言語情報を提供するため、
[JSON-LD]のプレーン文字列リテラルを要求するべきです。詳細言語の検出
あらゆるローカライズ可能なテキストまたは 自然言語コンテンツに、 言語を関連付けられるようにするべきです。
テキストは、その言語に応じて異なる方法でレンダリングまたは処理されます。たとえば、言語が変化した場合には スクリーンリーダーへ通知する必要があり、スペルチェッカーは言語を考慮するべきです。 テキストをレンダリングする際には、適切なフォント、ハイフネーション、改行、大文字と小文字の変換、 およびその他の機能を適用するために、言語に関する知識が必要です。
たとえば、雪、刃、直、令、垔などの表意文字は、日本語フォントと中国語フォントで使用した場合に わずかではあるものの重要な違いがあります。ユーザーへ表示する際に、日本語テキストへ中国語フォントを適用したり、 その逆を行ったりしないことが重要です。
特定のリソースの言語情報は、主に2つの目的で使用できます。テキスト処理のため、または リソースの意図された用途を示すためです。以下でその違いを説明します。
テキスト処理 言語を指定する場合、音声ブラウザー、スペルチェッカー、スタイルプロセッサー、 ハイフネーション処理など、テキストを操作するユーザーエージェントまたはアプリケーションが 対象のテキストに適切な規則を適用できるように、特定のテキスト範囲が実際に記述されている 言語を宣言します。したがって、必然的に、特定のテキスト範囲に 単一の言語を関連付けることになります。
通常は、リソース全体を処理するための既定の言語としてテキスト処理言語を表しますが、 リソース内で言語が変化する箇所を示す必要がある場合もあります。
ある範囲のテキスト処理言語を特定するために、HTMLではlang属性が提供され、XMLではすべてのXML形式で使用できる
xml:lang属性が提供されています。
作成者だけでなくHTMLおよびXMLプロセッサーもこれらの属性を認識するため、
関連するマークアップ形式で引き続き使用することは有用です。
リソース全体の言語を説明することも有用な場合があります。この種類の言語宣言は、 対象とする言語利用者 を示すリソースの情報と呼ばれます。たとえば、このようなメタデータは、検索、 適切な言語版の提供、分類などに使用できます。
この種類の言語宣言は、テキスト処理宣言とは次の点で異なります。（a）このような宣言の値には 複数の言語サブタグを含めることができ、（b）宣言された言語値は、多言語リソースのどの部分が どの言語であるかを示しません。
メタデータ型の言語宣言 （特定のテキスト範囲の言語ではなく、リソースの意図された用途を示すもの）に、 複数の言語値を関連付けられるようにするべきです。
リソースの意図された用途を説明する言語には、文書で使用されているすべての言語が 必ず含まれるわけではありません。たとえば、ウェブ上の多くの文書には異なる言語の コンテンツ断片が埋め込まれていますが、そのページは明らかに特定の1つの言語の話者を対象としています。 たとえば、北京についてのドイツ語の都市ガイドには中国語の便利な表現が含まれていることがありますが、 対象は中国語話者ではなくドイツ語話者です。
一方で、同じまたは対応するコンテンツを複数の言語で含む文書も考えられます。 たとえば、ウェブページの左列にフランス語のコンテンツを、右列に同じ内容の英語コンテンツを表示して、 カナダの読者を迎える場合があります。この場合、文書は両方の言語の話者を等しく対象としているため、 対象言語は2つあります。別のユースケースとして、多言語コミュニティを対象としたブログまたはニュースページがあり、 ページ内の一部の記事がある言語で、別の記事が別の言語で記述される場合があります。 この場合、言語宣言の値として複数の言語タグを列挙することが適切な場合があります。
外部リソースの言語を表す属性は、HTMLの
langおよびXMLの
xml:lang言語属性を使用するべきではありません。
それらがメタデータ（特定のテキスト範囲の言語ではなく、リソースの意図された用途を示すもの）を表す場合は、
別の属性を使用するべきです。
XML文書スキーマにおける
xml:lang – XML文書スキーマ（DTD）で
言語値を渡す場合、いつxml:langを使用し、いつ独自の要素または属性を定義するべきか？
外部リソースの言語を示すために別の属性を使用すると、属性に複数の言語を指定できます。 また、参照先のリソースが単一の言語ではない場合にも、より適切に機能します。
この区別は、HTMLにおけるlang属性とhreflang属性の分離に見られます。前者はHTMLページ内のテキストの言語を示し、
後者はリンク先ページの想定言語を示すメタデータです。
これに関する詳細な議論については、XML文書スキーマにおける
xml:langを参照してください。この記事では特に
xml:langについて説明していますが、
その概念は他の状況にも適用できます。
BCP 47は、インターネットおよびウェブ標準（さらに多くの他の場所）で使用される 言語タグシステムです。 IANAレジストリのサブタグを使用して、コンテンツの言語を記述する文字列を形成する方法を定義します。 レジストリ内のサブタグは、主として言語、用字系、地域、および国を特定するためのISOおよび国連標準に基づき、 それらとの厳密な互換性を維持しています。BCP47は、Unicodeロケールの 基礎にもなっています。
BCP 47の主要な機能の概要については、HTMLおよびXMLの言語タグを 参照してください。
RFC 5646やRFC 4647などの構成要素ではなく、BCP 47を参照してください。
BCP 47へのリンクと名称は、言語を識別するためのタグの定義に対する 不変の参照を提供するために、特別に作成されました。RFC 1766、3066、4646は以前の （置き換えられた）版です。現在のBCP 47は、5646と4647という2つのRFCで構成されています。
言語タグに期待する適合性の水準を明確にしてください。BCP 47では、 「妥当」と「整形式」という2つの適合性水準が定義されています。
整形式のBCP 47言語タグは、言語タグとして定義された構文に従います。 実装は、各言語タグがハイフンで区切られたサブタグで構成されていること、およびタグ内での位置に応じて、 各サブタグが特定の長さと特定の内容（文字、数字、または特定の組み合わせ）を持つことを確認します。 妥当なBCP 47言語タグは整形式であり、さらにIANAサブタグレジストリに 登録されているサブタグだけが使用されていることを保証します。IANAサブタグレジストリは、 新しいサブタグによって頻繁に更新されることに注意してください。
仕様は、言語タグが「妥当」であるかを実装に確認させてもよいですが、 ほとんどの場合、言語タグが「整形式」であることのみを要求するべきです。
ほとんどの仕様は、言語メタデータを二次的に利用します。つまり、文書形式ですでに提供されているデータ （HTMLのlang、XMLの xml:lang、または文書形式の言語フィールドや属性）を 使用します。
一般に、ほとんどの仕様は、リソース（スペルチェッカー、トークナイザー、フォントなど）の選択、 または照合（たとえば表示する文字列の選択）を扱い、言語タグの内容自体には直接関与しません。 妥当ではないが整形式であるタグは、単に何とも一致せず、通常はフォールバックスキームによって 適切な動作が提供されます。
実装レベルで妥当性を確認する必要がある仕様も存在する可能性があります。その場合は、 タグが妥当性確認に失敗した結果を指定する必要があります（アプリケーションを終了するのか、 ユーザーへ警告するのか、など）。また、レジストリは大規模で時間とともに変化するため、 各実装が特定のレジストリ版に依存することも問題です。時間の経過による変更は多くの場合小さいものですが、 仕様の古い実装が、後に妥当になった言語タグを拒否すると、実際のユーザーは相互運用性の問題に遭遇します。
さらに、BCP 47には、追加のサブタグ列を定義する拡張機構があります。たとえば、 ある拡張[RFC6067]（単独サブタグ -uを使用するUnicodeロケール）は、 JavaScriptの国際化機能を制御するために一般的に使用されます（その他の用途もあります）。 これらの追加サブタグの妥当性確認は、ほとんどの仕様の範囲外である可能性があります。
仕様は、コンテンツおよびコンテンツ作成者に「妥当」な言語タグの使用を 要求するべきです。
言語タグに関する規範的な表現は、コンテンツ要件と実装要件で異なる場合があります。 仕様の作成者は、仕様にどのような適合性要件とテストが必要であるか、および実装に何を要求するかを 慎重に検討する必要があります。1つの解決策は、コンテンツ作成者に「妥当」な言語タグの使用を 規範的に要求する一方で、実装には「整形式」の言語タグの確認のみを要求することです。
仕様は、ISO 639、ISO 3166、またはその他の標準から抽出した コード一覧を提供するのではなく、IANA言語サブタグレジストリを参照するべきです。
以前は、言語タグで使用されるサブタグを提供する一部の標準が、無料または一般に利用できなかったため、 相互運用性を確保する目的で、いくつかの仕様が一覧を提供していました。現在ではその必要はありません。 BCP 47の一部として、IANAは言語サブタグレジストリを管理しています。これは、 言語タグの構築に使用できる妥当なサブタグを収録した、一般公開され機械可読な一覧です。 このレジストリは、ISO 639の各部（639-1、639-2、639-3など）、ISO 15924用字系コード、 ISO 3166および国連M.49地域コードなどの基礎標準に基づいています。 このレジストリは積極的に保守され、安定化されており、インターネット上の他の一覧にはない可能性のある 包括性を備えています。各サブタグ型は、それらの標準の管理者による支援と参加によって 親標準と同期されているため、独自にコード一覧を抽出または作成したり、別の場所にある一覧を参照したりすると、 保守上の問題や混乱につながる可能性があります。
完全な言語タグの独自一覧を作成すると、使用できる言語の一覧を不必要に制限することになります。 さらに、ロケールデータは常に拡張されているため、現在の対応状況を記述した一覧は将来古くなります。 ユーザーが利用できるタグまたはサブタグを制限することは、普遍的なアクセスを提供するという 私たちの目標に反します。
ここでは、構造化されたテキストを含む独立したデータ単位について説明します。 例として、HTMLページ全体、XML文書、JSONファイル、WebVTTスクリプト、注釈などがあります。
仕様は、リソース全体の既定のテキスト処理言語を定義する方法を 示すべきです。
リソース全体の言語、または少なくとも既定の言語を1か所で特定すると、
多くの場合、問題を減らすことができます。たとえば、HTMLファイルでは、
html要素に
lang属性を設定することでこれを行います。
明示的に上書きされない限り、リソース内のコンテンツは、 リソースレベルで宣言されたテキスト処理言語を継承するべきです。
テキスト処理言語と、リソースの想定用途に関するメタデータとを示すために、 個別の宣言が必要かどうかを検討してください。
多くの場合、リソースには1つの言語のテキストのみが含まれます。また、さらに多くの場合、 テキスト処理の既定言語として宣言された言語は、リソース全体に関するメタデータで示される言語と同じです。 そのような場合は、単一の宣言を使用することが適切です。
ただし、どの1つの言語をテキスト処理の既定値として使用するかを判定する方法がない状態で、 単一の宣言が複数の言語を参照すると問題になります。
リソースに言語宣言が1つしかなく、その値として複数の言語タグが 指定されている場合は、リソースの既定のテキスト処理言語を特定できなければなりません。
ここでは、ブロックおよび／または チャンクという語を、 リソース全体の内部でコンテンツをまとめ、隣接するコンテンツから分離する構造的な構成要素を 指すために使用します。あるブロックと別のブロックの境界は、テキストにおける段落または節の境界、 あるいはファイル内の個別のデータ項目に相当します。
たとえば、XMLまたはHTMLのブロックや段落、JSONのオブジェクト宣言、 WebVTTのキュー、CSVファイルの行などを指す場合があります。これは、段落や文などの内部の範囲を表す インラインコンテンツとは対照的です。
仕様で定義されたどの構造がこれらの要件に関連するかを解釈するには、多少の検討が必要となる場合があり、 関係するデータ形式によって異なります。
既定では、コンテンツブロックはリソース全体に設定された テキスト処理言語を継承するべきです。
既定のテキスト処理言語情報に関連する指針については、 2.1 言語の基本を参照してください。
言語が変化するコンテンツブロックについて、言語の変更を 示せるようにするべきです。
この節では、段落または文字列の途中にある文字範囲について提供する必要がある情報を扱います。
言語が変化するインラインテキストの範囲について、 言語を示せるようにするべきです。
言語の切り替えが、スペルチェック、レンダリング、スタイル設定、音声生成、翻訳、 情報検索などのコンテンツに対する処理へ影響する場合は、影響を受けるテキスト範囲を示し、 そのコンテンツの言語を特定する必要があります。
この節の情報は、データ形式における言語および方向メタデータの要件 [STRING-META]で 策定中です。その文書はまだ執筆中であるため、これらのガイドラインは随時変更される可能性があります。
ウェブ上のデータ交換では、可能な限りロケール非依存の 標準化された形式を使用するべきです。ただし、ウェブ上の一部のデータは必然的に、 人間への表示を意図した自然言語情報で構成されます。 この自然言語情報を適切に表示するには、 言語および方向メタデータの存在が必要であり、それによって恩恵を受けます。 Unicodeへの対応とともに、テキスト範囲の基本方向と自然言語を含め、 指定するための仕組みは、ウェブ向けの新しい形式および技術を開発する際の 主要な国際化上の考慮事項の1つです。
国際化ワーキンググループがすべての仕様で確認する、最も基本的なベストプラクティスは次のとおりです。
自然言語テキストを含むあらゆる文字列フィールドについて、 その特定の文字列の言語と文字列方向を 判定できなければなりません。この判定には、文字列レベルまたは文書レベルのメタデータを使用するべきであり、 ヒューリスティックに依存するべきではありません。
文字列形式の言語および方向メタデータに関する作業は進行中です。仕様には、 将来メタデータを採用する必要性を示す注記を含める必要がある場合があります。 次にひな型を示します。
フィールド{fieldname}は、
ウェブ上の文字列：言語および方向メタデータ
[STRING-META]に
記載されているベストプラクティスに従うべきです。これには、文字列の言語および方向メタデータの
報告に関して将来策定される標準を使用することも含まれます。
個々のローカライズ可能なテキスト値の 言語と文字列方向を示すために、 フィールドベースのメタデータまたは文字列データ型を使用してください。
個々のデータ値は、同じデータファイルまたは文書内の他の値とは異なる言語または方向を持つことがあります。 各ローカライズ可能なテキスト フィールドに直接関連付けられたメタデータ値を提供すると、メタデータを適切に上書きでき、 アプリケーションが各データフィールドを組み立て、抽出、転送、またはその他の方法で処理して 使用する際の自動化に役立ちます。
仕様は、特定のリソース内のすべての文字列に対して、 既定の言語と既定の文字列方向を提供する 仕組みを定義してもよいです。ただし、リソース全体の既定値だけで十分であると仮定してはなりません。 リソース全体の設定が利用できる場合でも、文字列固有のメタデータを使用して その既定値を上書きできなければなりません。
多くの文書には、単一の言語のデータが含まれています。おそらくヘッダー内で、 対象とする言語利用者を示す手段を提供することで、文書全体のサイズと複雑さを軽減できます。 ただし、一部の文字列が文書の言語で利用できない場合や、基本方向が文書全体の他の ローカライズ可能なテキスト値の 既定方向と一致しない場合は常に起こり得るため、特定の文字列値を上書きできることは依然として重要です。
その他の情報がない場合は、既定の方向と既定の言語が 不明であることを指定してください。
仕様では、ユーザー指定値を含む 構文コンテンツと、 ローカライズ可能なテキストを 慎重に区別するべきです。
仕様は、自然言語テキストを含むことができないフィールドに対し、 言語メタデータの使用を指定または要求するべきではありません。
ウェブ上の文書形式はテキストで構成されます。ほとんどの場合、特定の文書形式のデータ値は、 単なる任意の文字列ではなく、何かを表し意味を持つことを意図しています。 たとえば、データ値が英語のキーワードで構成されているという事実だけでは、そのデータ値は テキストとして表示されることを意図した自然言語文字列にはなりません （つまり、その値はローカライズ可能なテキストでは ありません）。このようなデータ値は、文書の構文コンテンツの一部です。 言語および方向メタデータを必要としないだけでなく、そのようなメタデータと関連付けるべきでもありません。
ローカライズ可能なテキスト
ではない文字列値および文字列フィールドについて、仕様は、そのフィールドが非言語的な性質であることを指定し、
各文字列値に言語タグzxx
（「言語コンテンツなし」）を関連付けることを推奨するべきです。
ローカライズ可能なテキストを
含むことが分かっているものの、基礎となる形式から言語メタデータを得ることができない文字列値および
文字列フィールドについて、仕様はコンテンツの言語が不明であることを指定し、
各文字列に言語タグund
（「未判定」）を関連付けることを推奨するべきです。仕様は、適切な場合、
ヒューリスティックの使用または他のフィールド値からの言語の推論を許可してもよいです。
一部の文字列値は、既存のプロトコルまたは形式に依存するか、それらによって定義されます。 多くの場合、これらの文字列には言語または方向メタデータが関連付けられておらず、 そのようなメタデータも提供されません。たとえば、多くのHTTPヘッダーは、その内容に自然言語テキストが 含まれる場合であっても、ローカライズ可能なテキスト ではないかのように定義されています。利用側の仕様は、このような性質の文字列に依存したり、 そのような文字列を記述する形式を定義したりする必要がある場合があります。 この場合、仕様のデータ構造または文書形式の文字列にコンシューマーが関連付けられる 言語または方向メタデータは存在せず、仕様のデータ構造または文書形式が プロデューサーとして機能するときに 提供するメタデータも、基礎となる形式を通じてシリアル化されません。
仕様は、言語の特定にUnicodeの「言語タグ」文字
（コードポイントU+E0000からU+E007F）を
使用するべきではありません。
Unicodeの「言語タグ」文字は、言語タグとしての使用が非推奨となっており、 文書形式および通信プロトコルにおける言語メタデータの問題を解決する方法として不適切である理由が 数多くあります。仕様の作成者は、これらの文字を別の目的に転用したり、 これらに基づいて言語情報を伝達する新しい仕組みを構築したりしないよう注意する必要があります。
プロデューサーは、 特定のコンテンツ項目またはデータレコードについて、ローカライズされた値を提供する必要がある場合があります。 これは、プロデューサーと コンシューマーとの間の 言語ネゴシエーションによって 行われることがあります。その場合、ネゴシエーションされた言語を使用して返すコンテンツを選択することにより、 プロデューサー側で ローカライゼーションが行われます。
また、コンテンツ項目のローカライズは、プロデューサーがその項目について 複数の言語表現を返し、コンシューマーが表示する値を 選択することで行われる場合もあります。この後者の処理は、言語索引付けと呼ばれます。言語索引付けの詳細については、 [STRING-META]の ローカライズに関する 考慮事項を参照してください。
[JSON-LD]は、この節に記載されている 一部のベストプラクティスを満たすための複数の仕組みを提供します。
この文書のベストプラクティス、および ウェブ上の文字列：言語および方向メタデータ [STRING-META]では、 自然言語コンテンツを言語メタデータと関連付けることが要求されています。 ウェブ上で「言語メタデータ」とは、言語タグ、 特に[BCP47]で定義されたものを意味します。 仕様またはアプリケーションは、言語またはユーザーのロケールに従って、 コンテンツを選択またはフィルタリングする必要がある場合があります。
[BCP47]は2つのRFCで構成されています。
1つ目の[RFC5646]は、 言語タグの文法、処理、および形成と、 妥当なサブタグを列挙するIANA言語サブタグレジストリの 内容および保守を定義します。
2つ目の[RFC4647]は、 言語範囲、 言語優先順位リスト、 および言語タグを使用して選択またはフィルタリングする際にアプリケーションが使用できる （または仕様が指定できる）一般的な照合方式を定義します。
Unicodeの[CLDR]は、言語タグが ロケール識別子として使用される場合に、 それらを管理および照合するための追加のアルゴリズム、規則、および処理を定義します。
言語タグの照合には、 ルックアップとフィルタリングという2つの異なる種類があります。
ルックアップ [RFC4647]は、 基本言語範囲で構成される 言語優先順位リストと、 言語タグの集合を照合して、 指定された範囲に最も適合する厳密に1つの 言語タグを見つけます。 つまり、ユーザーの要件に最も適合する結果（または適切な既定値）として 厳密に1つの項目または値が必要な場合に、ルックアップを使用します。 ルックアップの例には次のものがあります。
フィルタリングは、言語優先順位リストと 言語タグの集合を照合し、 0個以上の一致を生成します。つまり、コンテンツをフィルタリングして、 言語優先順位リストに 一致する項目だけを生成するために使用されます。これにより、すべての言語タグ値が除外される場合もあれば、 多数（またはすべて）の項目が含まれる場合もあります。
[BCP47]は、 基本フィルタリングと 拡張フィルタリングという 2種類のフィルタリングを定義しています [RFC4647]。
基本フィルタリングは、 基本言語範囲で構成される 言語優先順位リストを 使用して、言語タグまたは言語タグ付きコンテンツの一覧をフィルタリングします。 基本フィルタリングでは、各言語範囲に対して言語タグの接頭辞を照合します。 言語優先順位リストの言語範囲の厳密な子孫である言語タグだけをすべて選択する必要がある場合に、 基本フィルタリングが役立ちます。
拡張フィルタリングは、
拡張言語範囲で構成される
言語優先順位リストを
使用して、言語タグまたは言語タグ付きコンテンツの一覧をフィルタリングします。
拡張言語範囲には、
1つ以上のサブタグの代わりにワイルドカード*サブタグを含めることができます。
（先頭の「主要言語サブタグ」の位置以外にあるワイルドカードは無視されます。）
基本フィルタリングとは異なり、
拡張フィルタリングは言語タグ内部の特定のサブタグを選択するために使用されます。
指定された言語範囲内の
特定のサブタグ一覧と一致しない言語タグを除外するために、
拡張フィルタリングを使用します。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、 2番目のチェックボックスを選択してください。その後、「GitHub用のMarkdownを作成」ボタンをクリックし、 結果をGitHubのissue一覧へコピーしてください。詳細を参照してください。
基本要件
背景情報
基本方向の値
マークアップでの方向の処理
autoに設定することもできなければなりません。
これは、コンテンツ自体を調べて基本方向が判定されることを意味します。詳細
autoに設定されている場合、
コンテンツ内の段落の方向は段落ごとに判定するべきです。詳細
文字列の基本方向の処理
インラインまたは部分文字列テキストの基本方向の設定
autoに設定することもできなければなりません。
これは、コンテンツ自体を調べて基本方向が判定されることを意味します。一般的な方法は、
マークアップ外にある最初の強い方向性文字に基づいて方向を設定することです。詳細
方向の検出と照合（未定）
右から左へ記述する用字系で書かれたテキスト、またはそのような用字系と混在するテキストでは、 方向を設定することが重要です。これらの用字系の文字は、入力および発音される順序でメモリに格納されます。 これは論理順序と呼ばれます。Unicode双方向アルゴリズム（UBA）は、論理順序で格納された文字列を、 期待される視覚的順序で自動的にレンダリングするための多くの機能を提供します。しかし残念ながら、 双方向テキストを正しくレンダリングするにはUBAだけでは不十分であり、特定の文字列に適用する 既定の方向性コンテキストについて追加情報を提供する必要があります。
基本要件は次のとおりです。
上記の特殊な場合として、データ構造および文書形式内の自然言語文字列値には、 次の要件が適用されます。
自然言語テキストを含む あらゆる文字列フィールドについて、その特定の文字列の言語と文字列方向を 判定できなければなりません。この判定には文字列レベルまたは文書レベルのメタデータを使用するべきであり、 ヒューリスティックに依存するべきではありません。
すべてのローカライズ可能なテキストについて、 埋め込まれたインライン双方向テキスト範囲の基本方向の変更を示せなければなりません。
右から左へ記述する用字系を日常的に使用する人が、 右から左へのテキストに注釈を付けるために必要な労力を最小限にしなければなりません。
アラビア語、ディベヒ語、ヘブライ語、ペルシア語、ウルドゥー語などの話者に、 記述するすべての段落または小さなデータ項目へマークアップや制御文字を追加させることは、 管理できないほど過大な負担です。通常、形式は既定方向を設定し、例外へ対応する必要がある場合にのみ、 ユーザーの介入を要求するべきです。
この節では、後に続く推奨事項を理解しやすくするため、 テキスト方向に関連するいくつかの重要な概念について説明します。
「右から左」の用字系で記述されたテキスト、または双方向要素を含む左から右へのテキストを 正しく表示するには、テキストの各要素を表示する順序を決定するために使用される基本方向を設定することが重要です。
Unicode双方向アルゴリズム（UBA）が行うことと行わないこと、および基本方向が重要である理由に 詳しくない場合は、Unicode 双方向アルゴリズムの基本を参照してください。
この節では、段落という語は、
プレーンテキストではハード改行が後に続くテキスト範囲を示しますが、その他の状況では
異なるものを意味する場合があります。CSVでは「セル」に相当するため、カンマで区切られた項目の
1行は、実際にはカンマで区切られた段落の集合です。 HTMLでは最下位レベルのブロック要素に相当し、
多くの場合はp要素ですが、テキストおよび／または
インライン要素のみを含む場合は、div、liなども該当します。
JSONでは多くの場合、引用符で囲まれた文字列値に相当しますが、文字列値がマークアップを使用する場合、
段落はブロック要素に関連付けられます。また、文字列値が複数行のプレーンテキストである場合、
各行が段落になります。
ここでメタデータという用語は、 データに関連付けられた注釈またはプロパティである情報、許可される状況ではマークアップ、 上位レベルのプロトコルなどを意味します。
基本方向を設定する方法はいくつかあります。
ltr、rtl、または
autoがあります。
dir=autoを設定した場合に行われる処理です。）dir属性がない場合に行われる処理です。）htmlタグに
dir属性を設定した場合がこれに該当します。
別の例として、すべてアラビア語で記述された多数のキューを含む字幕ファイルがあります。
作成者がファイルの先頭で、すべてのキューテキストの既定値がRTLであると指定できることが望まれます。
必要な場合は、特定の段落の方向情報を上書きする方法を常に用意するべきです。
autoに設定した場合にのみ行われます。）
ユーザーが入力したテキストを取得する場合、通常は入力の基本方向を判定するために、
ユーザーがデータを入力したコンテキストを理解する必要があります。たとえばHTMLでは、
htmlタグから継承された方向によって設定される場合や、
ユーザーがフォームフィールドの基本方向を設定するキーを押すことで設定される場合があります。
その後、基本方向に関する情報を格納する方法、またはレンダリング時に文字列へ関連付ける方法を
見つける必要があります。通常、この状況では、入力中の文字列内部の方向変更はユーザーが処理し、
文字列の一部として取得されます。
単一の段落の内部に埋め込まれたテキスト範囲には、 異なる基本方向が必要となる場合があります。たとえば、
「タイトルは『!NOITASILANOITANRETNI』でした。」
ここで、単一引用符内の範囲はヘブライ語、アラビア語、ディベヒ語などであり、 感嘆符を正しく配置するため、周囲の段落のLTR基本方向ではなく、 RTL基本方向を 使用する必要があります。
コンテンツ作成者がマークアップを利用できる場合は、このようなインライン範囲を示すために
マークアップを使用する方が容易で安全である可能性があります（後述）。
HTMLでは通常、dir属性を持つインライン要素を使用して、
このようなテキスト範囲の基本方向を設定します。HTMLのtitle要素など、テキストをマークアップできない場合や、
プレーンテキストコンテンツのみを処理する環境では、このような内部範囲の基本方向を設定するために、
Unicodeの対になった制御文字を使用する必要があります。
さらに、基本方向が変更されるインライン範囲は、境界を越えた干渉によって Unicode双方向 アルゴリズムが誤った結果（「波及効果」）を 生成しないよう、周囲のテキストから双方向分離するべきです。
これは、コンテンツ作成者がUnicode制御コードを使用する場合、
埋め込み制御RLE/LRE…PDFではなく、
分離制御RLI/LRI/FSI…PDIを
使用するべきであることを意味します。
方向を設定するために制御文字へ依存することを避ける理由には、次のものがあります。
上記の最後の2項目はマークアップにも該当する場合がありますが、 実装者は通常、含まれる制御コードよりも含まれるマークアップを適切にサポートします。
ユーザーがすべての段落の先頭と末尾に制御コードを追加することを期待しないでください。 これは過大な作業です。
ここで、Unicode文字
U+200F RIGHT-TO-LEFT MARK（RLM）、
U+200E LEFT-TO-RIGHT MARK（LRM）、および
U+061C ARABIC LETTER MARK（ALM）について説明しておく必要があります。
最初に明確にするべき点は、これら3つの文字はテキスト範囲の基本方向を設定しないということです。 これらは、強い方向性プロパティを持つ不可視文字にすぎません。
前の例を思い出してください。これは、たとえばRLMを使用しても、 W3Cというテキストを ヘブライ語テキストの左側に表示することはできないという意味です。 メタデータまたは対になった制御文字を使用した場合にのみ、正しい表示になります。
もちろん、最初の強い文字によるヒューリスティック
（HTMLのdir="auto"など）を使用して基本方向を検出する場合、
対象のテキストが、そのままでは誤った結果を生じさせる文字で始まるときに、
検出される基本方向へ影響を与えるためRLM、ALM、またはLRMを挿入すると役立つことがあります。
基本方向の設定にメタデータを使用する場合、最初の強い文字によるヒューリスティックを 使用するべきであるとメタデータで明示的に指定しない限り、 強い方向性書式文字は無視されることに注意してください。
最後に、U+061C ARABIC LETTER MARK（ALM）の
使用について説明します。この文字は、数字の前にアラビア文字がない場合に、
アラビア用字系のテキスト内で数列の表示へ影響を与えるために使用されます。
言語タグを基本方向に関する情報の提供へ使用できない理由には、次のものがあります。
auto値を表現できません。Suppress-Script: Hebr）など、
通常は必要のない言語では用字系タグの使用を省略することを推奨しています。
ペルシア語など、通常RTL用字系で記述される言語も、転写形式で記述される場合があり、
方向情報を伝えるために必要な用字系タグが存在することを保証できません。
つまり、方向へ影響を与えるために、言語情報の一部として用字系タグを提供することを
利用者へ期待することはできません。既定の基本方向の値には、左から右、右から左、および自動を 含めるべきです。
auto値を使用すると、テキストの基本方向を
自動的に検出できます。たとえば、HTMLのdirの
auto値は、テキスト内の最初の強い方向性文字を探し、
一部のマークアップ項目も無視して、テキストの基本方向を推測します。
自動検出アルゴリズムは完全とはほど遠いことに注意してください。
最初の強い文字による検出では、実際には右から左へのテキストであっても、
強いLTR文字で始まるものを正しく識別できません。テキストの内容に基づいて基本方向を
判断しようとするアルゴリズムにも問題があります。基本方向が分かっており、
宣言されている状態が最も望ましい状況です。
この節では、マークアップを使用してコンテンツを構成するリソースで機能する 双方向処理方法の定義について説明します。一部の推奨事項は、ウェブ上の文字列を処理する場合のものとは異なります （3.5 文字列の基本方向の処理を参照）。
仕様は、リソース全体の既定の基本方向、 すなわち全体の基本方向を設定する方法を示すべきです。
その他の情報がない場合、既定の基本方向は autoであるべきです。
コンテンツ作成者は、テキスト内で基本方向が変化する部分を 示せなければなりません。ブロックレベルでは属性またはメタデータを使用して実現するべきであり、 コンテンツ作成者に方向制御のためのUnicode制御文字の使用を要求するべきではありません。
改行によってUnicode制御文字の効果が終了するため、各ブロックの方向を設定するために Unicode制御文字へ依存することは現実的ではありません。また、制御文字が必要となるすべての箇所に 表示されなければならない場合、データの安定性が大幅に低下し、管理が不必要に困難になります。
コンテンツ断片の方向をautoに設定することもできなければなりません。
これは、コンテンツ自体を調べて基本方向が判定されることを意味します。
HTMLおよびCSSにおける双方向処理の追加要件の 推定 アルゴリズム。
一般的な方法は、マークアップ外にある最初の強い方向性文字に基づいて方向を設定することですが、 これが唯一の方法ではありません。方向がautoに設定されている場合に方向性を判定するためのアルゴリズムは、 受信側が想定するものと一致するべきです。
最初の強い文字アルゴリズムは、Unicodeの定義に従って強い方向性プロパティを持つ 段落内の最初の文字を探します。その後、その文字の方向に従って段落の基本方向を設定します。
RTLの段落または行がLTRのブランド名や技術用語で始まる場合など、 最初の文字が段落の残りの部分を代表していない場合、 最初の強い文字アルゴリズムが段落の方向を誤って推測する可能性があることに注意してください。
方向を検出するアルゴリズムの詳細については、HTMLを参照してこの問題を論じた文書の 推定アルゴリズムを 参照してください。
プレーンテキスト全体の基本方向がautoに設定されている場合、コンテンツ内の段落の方向は
段落ごとに判定するべきです。
テキストブロックに含まれる行の始端と終端を基準としてブロックの辺を示すには、 'top'および'bottom'ではなく、'block-start'および'block-end'を使用してください。
行の始端／終端を示すには、'left'および'right'ではなく、 'start'および'end'、または'inline-start'および'inline-end'を使用するべきです。
基本方向および双方向上書きを制御するための専用属性を提供してください。 双方向制御を実現するために、ユーザーが任意のマークアップへスタイルプロパティを適用することに 依存しないでください。
双方向対応における CSSとマークアップ、W3Cの記事。
たとえば、HTMLには、CSSによるスタイル設定の支援なしで基本方向を管理できる
dir属性があります。XML形式では、必要な表示を
実現するためにCSSが必要な場合でも、テキストが他の方法で使用される可能性があるため、
方向情報を表す専用マークアップを定義するべきです。
CSSなどのスタイルシートは、常にデータとともに使用されるとは限らず、 配信時などにデータとともに運ばれない場合もあります。方向情報はデータを正しく表示するために 根本的に重要であり、マークアップまたはデータへ、より密接かつ永続的に関連付けるべきです。
この節の情報は、ウェブ上の文字列：言語および方向メタデータから 取得しています。その文書はまだ執筆中であるため、これらのガイドラインは随時変更される可能性があります。
メタデータが提供されている場合を除き、文字列の利用者が ヒューリスティック、できればUnicode標準の最初の強い文字アルゴリズムに基づく方法を使用して、 文字列の基本方向を検出するべきであると指定してください。
ウェブ上の文字列：言語および方向メタデータの ベストプラクティス、推奨事項、 および不足点
可能な場合は、特定のリソースまたは文書内のすべての文字列の 既定方向を示すフィールドを定義してください。
ウェブ上の文字列：言語および方向メタデータの ベストプラクティス、推奨事項、 および不足点
任意の文字列の方向を変更できない状態で文書レベルの既定値を作成するだけで 十分であると仮定してはなりません。
ウェブ上の文字列：言語および方向メタデータの ベストプラクティス、推奨事項、 および不足点
レガシー実装のためにメタデータを利用できず、他の方法でも提供できない場合、 仕様は、利用可能な言語メタデータから文字列方向を 補間することを許可してもよいです。
ウェブ上の文字列：言語および方向メタデータの ベストプラクティス、推奨事項、 および不足点
ここで「インラインテキスト」は、マークアップでは容易に理解できる意味を持ちます。 これは文字列（JSON、CSV、またはその他のプレーンテキスト形式など）にも適用され、 文字列内のすべての文字を含まない文字範囲を意味します。
基本方向が変化するインラインテキストの範囲を示せなければなりません。 マークアップを利用できる場合は、それが推奨される方法です。そうでない場合、仕様は、 受信側アプリケーションがUnicode制御文字を認識し、正しく実装することを要求しなければなりません。
インラインテキスト範囲の方向をautoに設定することもできなければなりません。
これは、コンテンツ自体を調べて基本方向が判定されることを意味します。一般的な方法は、
マークアップ外にある最初の強い方向性文字に基づいて方向を設定することです。
最初の強い文字アルゴリズムは、Unicodeの定義に従って強い方向性プロパティを持つ 段落内の最初の文字を探します。その後、その文字の方向に従って段落の基本方向を設定します。
RTLの段落または行が LTRのブランド名や 技術用語で始まる場合など、最初の文字が段落の残りの部分を代表していない場合、 最初の強い文字アルゴリズムが段落の方向を誤って推測する可能性があることに注意してください。
方向を検出するアルゴリズムの詳細については、HTMLを参照してこの問題を論じた文書の 推定アルゴリズムを 参照してください。
ユーザーがUnicode双方向制御文字を使用する場合、 PDI文字と組み合わせた分離制御文字RLI／LRI／FSIをアプリケーションがサポートし、 仕様がPDFと組み合わせたRLE／LREではなくこれらを推奨しなければなりません。
RLM／LRMを適切に使用し、これらの制御文字で可能なことと不可能なことを 仕様で明確にするべきです。
Unicode双方向制御文字U+200F RIGHT-TO-LEFT MARKおよび
U+200E LEFT-TO-RIGHT MARKだけでは、
双方向テキストを管理するには不十分です。これらは埋め込まれたテキストに異なる基本方向を
設定できません。そのためには、埋め込まれたテキスト範囲の始端と終端を示す必要があります。
マークアップを利用できる場合はそれを使用するのが最善であり、利用できない場合は、
直前に説明したその他のUnicode双方向制御文字を使用します。
マークアップでは、基本方向および双方向上書きを制御するための 専用属性を提供してください。双方向制御を実現するために、ユーザーが任意のマークアップへ スタイルプロパティを適用することに依存しないでください。
マークアップでは、テキストを含むすべてのインライン要素で 双方向属性を使用できるようにしてください。
マークアップでは、ユーザーが（a）分離または埋め込みの基本方向を作成するか、 （b）双方向アルゴリズムを完全に上書きできる属性を提供してください。このような属性では、 これら2つの状況のいずれでも、方向をLTR、RTL、またはAutoに設定できるようにするべきです。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、 2番目のチェックボックスを選択してください。その後、「GitHub用のMarkdownを作成」ボタンをクリックし、 結果をGitHubのissue一覧へコピーしてください。詳細を参照してください。
文字と文字エンコーディングの基本
「文字列」の定義の選択
DOMStringを
使用してください。（この用途の一覧は網羅的ではありません。）詳細
USVString を
Unicode
スカラー値に対して処理する文字列、
または入力内の サロゲートを処理できない操作には使用します。これには
文字列内の コードポイントを反復処理するアルゴリズム、文字列を
UTF-8
エンコードする処理、および
対になっていない サロゲート
コードポイント
によってエラーが発生する別のコンポーネントまたは API に文字列を渡す操作が含まれます。 詳細
DOMStringと
USVStringを
混在させないでください。後者には、ほとんどの文書形式やプロトコルに利点をもたらさない
追加処理が必要となるため、多くの場合は
USVStringより
DOMStringを
選択します。詳細
DOMString、
またはまれにUSVStringを
指定してください。詳細
Uint8Arrayを
指定してください。詳細
ByteStringを
指定してください。詳細
参照処理モデルの定義
文字範囲の包含と除外
私用領域の使用
文字エンコーディングの選択
文字エンコーディングの特定
文字エスケープの設計
ካや\u{12F}のような明示的な終了区切り文字、
または\u12ABや\U001234ABのような固定桁数の
いずれかを使用しなければなりません。詳細
テキストの格納
空白文字
文字という語は、コンテキストによって異なる意味を持ちます。特定のテキスト単位の 視覚的表現、論理的表現、またはバイトレベルの表現を指すことがあります。このため、この用語は 仕様で安易に使用するには不正確すぎます。文字列データの処理について説明するには、 コンピューターシステムにおいてテキストがどのように定義およびエンコードされるかと、 その仕様を曖昧さなく記述するための関連用語を理解しておく必要があります。
仕様の開発者、およびその仕様に基づくソフトウェアの開発者は、これまで経験した 「文字」という用語の用法には慣れていても、国際的なコンテキストにおける多様な用法には 詳しくない可能性があります。さらに、コンピューティングのコンテキストでは、 文字が関連概念と混同されることが多く、不完全または不適切な仕様やソフトウェアにつながります。
文字、文字列、または文字や文字列を扱う処理を指定する場合は、 最も具体的で適切な用語を使用してください。特に理由がない限り、 コードポイントを Unicodeスカラー値を 意味するものとして定義し、「文字」よりもこの用語を優先して使用してください。
この節に記載されている最も適切な用語を使用してください。その他の推奨用語を次に示します。
| 単位の種類 | 文字の代わりに使用する用語 | 説明 |
|---|---|---|
| テキスト単位 | コード
ポイント、 Unicodeコード ポイント、 Unicodeスカラー値 |
文字エンコーディング 形式または特定のシリアル化に依存しない、テキストの論理単位。 |
| 格納、処理、シリアル化、エンコード | コード単位 | エンコードおよびシリアル化の単位。コード単位は通常、 通信形式、ファイル形式、および低レベルのテキスト処理で指定されます。 使用される文字 エンコーディング（推奨はUTF-8またはUTF-16）に依存します。 |
| 視覚単位、ユーザーが認識する文字、選択／分割 | 書記素
クラスター、 組版 文字単位 |
テキストの視覚単位への分割、ほとんどの視覚的選択、および 切り詰め。この推奨事項には特に多くの注意点があります。 |
| フォントの構成要素 | グリフ | 個々の表示値。主としてフォントの内容について説明する場合にこの用語を使用してください。 |
「文字」という用語の使用を避けられない場合は、その用語の 明確な定義を含めなければなりません。
中心的な用語の簡単な用語集を次に示します。
[Unicode]の[D7]は、
抽象文字を
テキストデータの編成、制御、または表現に使用される情報の単位。
と定義しています。
この定義は必然的に曖昧であり、抽象文字は具体的な形状を持たないため、
フォント内のグリフと混同してはならず、
ユーザーが「文字」と考えるものでもないため、書記素とも
混同してはならないと説明しています。独自の仕様では、この用語を使用しないでください。
文字集合は、 テキストをエンコードするためにまとめて使用できる、順序のない 抽象文字の集合です （つまり、これは集合です）。文字集合に含まれる 文字の集合は、そのレパートリーと 呼ばれることがあります。ほとんどの文字集合は、 特定の範囲の言語または用字系のみをサポートします。
[Unicode]は、 普遍文字集合とも呼ばれ、 歴史的または消滅した書記体系、現在使用されている書記体系、私用文字、組版記号、 絵文字などを含め、現在コンピューターシステムでテキストをエンコードするために 使用されるすべての文字を含みます。その他のすべての文字集合は、Unicodeの部分集合として 定義されます。毎年の改訂により、エンコードされる文字集合が拡張されています。
[Unicode]標準は、単なる 文字集合以上のものを 定義します。テキストの処理および表示に使用する多くのプロパティ、アルゴリズム、 その他の詳細も定義します。
コードポイントは、 文字集合内の 抽象文字を表す 一意の識別子です。文字集合を使用可能にするには、各文字を曖昧さなく識別する必要があります。 ほとんどの文字集合では、 コードポイントは、 その集合の文字表または一覧内で文字の位置を表す数値（または数値の集合）です。
[Unicode]では、
コードポイントは
0x0000から0x10FFFFまでの整数です。16進表記で記述されます
（4.11
Unicode文字の参照を参照）。
Unicodeコードポイントは、
Unicodeスカラー値と
呼ばれることもあります。Unicodeで抽象文字へ割り当てられた各コードポイントには、
一意で変更されない名前も付けられます。Unicodeは、割り当てられた各文字にさまざまな
プロパティも関連付けます。これらのプロパティの多くは、
Unicode文字データベース
（UCD）[UAX44]に記載され、
その他は補助ファイルまたは表で割り当てられています。
[Unicode]の[D11]は、
符号化文字を、
抽象文字と
コードポイントとの関連付け
（または対応付け）
と定義しています。仕様では一般に、
コードポイント、
またはさらに具体的にする必要がある場合は、
Unicodeコードポイントや
Unicodeスカラー値という
用語を使用することが推奨されます。
コードポイントは、 ソフトウェアにおける文字の格納および交換には直接使用されません。代わりに、 それらが表す文字をエンコードおよび処理するため、またはある表現から別の表現へ変換するための さまざまな方式が存在します。
コード単位は、 物理記憶域および情報交換の単位であり、コンピューターによる処理、格納、および通信の基礎となります。 最もよく知られているコード単位は、 バイトまたはオクテットと呼ばれ、8ビットで構成されます。
異なる実行環境では、異なる大きさのコード単位が使用されます。 その他の一般的な大きさには、16ビット単位や32ビット単位があります。たとえばウェブでは、 [DOM]、JavaScript、および [INFRA]のさまざまな文字列型で、 16ビットのコード単位が使用されます。これらの仕様では、 [Unicode]のUTF-16 文字 エンコーディングの規則に従って16ビットのコード単位を処理します。
文字エンコーディング 形式（単に文字 エンコーディングと呼ばれることもあります）は、 文字集合内の コードポイントから、 テキストの格納および処理に使用されるコード単位へエンコードするための規則、 またはコード単位からコードポイントへ復号するための規則の集合です。 Unicode以外の文字エンコーディング形式は、まとめてレガシー 文字エンコーディングと呼ばれます。
UTF-8は、[Unicode]の マルチバイト文字エンコーディング 形式です。ウェブ上で使用される最も一般的な 文字 エンコーディングです。UTF-8は8ビットのバイトを コード単位として使用します。 UTF-8は可変幅エンコーディングであり、エンコードする コードポイントに応じて、 異なる数のコード単位を使用します。
よく知られている7ビットASCII文字（U+0000からU+007Fまでの
コードポイント）は、UTF-8では1バイトでエンコードされます。
| 文字 | コードポイント | UTF-8コード単位（バイト） |
|---|---|---|
| A | U+0041 |
0x41 |
U+0080からU+07FFまでのコードポイントには2バイトが必要です。
| À | U+00C0 |
0xC3 0x80 |
U+0800からU+FFFFまでのコードポイントには3バイトが必要です。
| न | U+0928 |
0xE0 0xA4 0xA8 |
最後に、U+10000からU+10FFFFまでのコードポイントには
4バイトが必要です。
| 👪 | U+1F46A |
0xF0 0x9F 0x91 0xAA |
仕様、ソフトウェア、およびコンテンツは、文字 （コードポイント）と 物理記憶域の単位（コード単位）の間に 1対1の関係があることを要求したり、それに依存したりしてはなりません。
ワールドワイドウェブの文字モデル1.0：基礎の 格納単位C009
仕様、ソフトウェア、およびコンテンツは、 コードポイントと 表示単位（書記素クラスター、 グリフ、 または組版文字単位など）の間に1対1の対応があることを要求したり、 それに依存したりしてはなりません。
ワールドワイドウェブの文字モデル1.0：基礎の 視覚レンダリング単位 C002。
ワールドワイドウェブの文字モデル1.0：基礎の 文字、キー操作、およびグリフの例。
この文書では、視覚テキスト単位とは、 ユーザーが認識する可視テキストの単一の単位を指します。画面上の場合もあれば、 紙に印刷されたものやナプキンの裏に書かれたものなど、その他の媒体の場合もあります。 ユーザーの認識は、特に結合記号、複雑な配置、またはコンテキストに基づく複雑な字形形成を 使用する書記体系では、用字系や書記体系に対する習熟度に依存することが多いため、 この用語は必然的に不正確です。独自の仕様では、この用語を使用しないでください。
書記素 クラスターは、符号化テキスト内の 視覚テキスト単位の 計算上の近似です。つまり、ユーザーの観点から単一の 視覚テキスト単位を 形成すると期待されるコードポイントの列です。 [Unicode]は、テキスト処理を支援するため、 これらの境界を計算する方法を提供します。多くのテキスト操作では、このような列を 分割できない単一のテキスト単位として処理するべきだからです。たとえば、テキスト上で カーソルを移動する場合、カーソルは視覚テキスト単位全体 （およびその基礎となるコードポイント）をまとめて「飛び越す」か選択するべきです。 視覚テキスト単位の「中央」へカーソルを移動できるべきではありません。 （特に指定されない限り、この文書の書記素クラスターという 用語は、Unicodeテキスト分割[UAX29]で「拡張既定書記素クラスター」と 呼ばれるものを指します。）
一部のテキスト操作では、ユーザーが書記素クラスター内の 個々のコードポイントを操作できることに 注意してください。たとえば、バックスペースなど一部の編集機能では、 視覚テキスト単位の末尾から 文字を段階的に削除します（たとえば、クラスター全体を削除せずに誤字を修正できるようにするためです）。
組版文字単位という 用語は、[CSS]によって定義され、特定の操作で 「単一のもの」として扱うべきさまざまな種類のコードポイント列を表すために 使用されます。この用語は書記素クラスターと 一致する場合もあれば、異なる場合もあります。コンテキストと用法を理解している場合にのみ、 この用語を使用してください。
グリフは、
特定のフォントでレンダリングされた場合の、
文字（または文字列）の視覚的表現です。グリフと
抽象文字は、
常に1対1で対応するわけではありません。グリフは文字の一部を表す場合も、
複数の文字の組み合わせを表す場合もあります。異なる
グリフが同じ
コードポイントを
表すこともあります。たとえば、次のものはすべて
AU+0041 LATIN CAPITAL LETTER Aを表す異なる
グリフです。
したがって、フォントは、 テキストのレンダリングに使用される特定のグリフの集合です。
仕様、ソフトウェア、およびコンテンツは、文字と言語の音の間に 1対1の対応があることを要求したり、それに依存したりしてはなりません。
ワールドワイドウェブの文字モデル1.0：基礎の 音声レンダリング単位C001
一部の用字系では、文字と音素（音素とは、 特定の話し言葉における最小の弁別的な音です）に密接な関係があり、 別の用字系では意味と密接に関連しています。文字が大まかに音素に対応する場合でも、 この関係は単純とは限らず、文字と音素が1対1で対応することはほとんどありません。
次に、「文字」という用語と音の単位が一致しない例を示します。
仕様およびソフトウェアは、1回のキー操作によって1文字が生成されること、 1文字が修飾キーを含む1回のキー操作で入力されること、または世界中のキーボードが 同じであることを要求したり、それに依存したりしてはなりません。
ワールドワイドウェブの文字モデル1.0：基礎の 入力単位C005。
ワールドワイドウェブの文字モデル1.0：基礎の 文字、キー操作、およびグリフの例。
キーボード入力では、キー操作と入力文字が常に1対1で対応するわけではありません。 キーボードに配置できるキーの数は限られています。一部のキーボードは、 1回のキー操作から複数のコードポイントを生成します。 別の場合（「デッドキー」）では、キーは文字を生成せず、 その後のキー操作の結果に影響します。多くの書記体系は、キーボードに収まらないほど 多数の文字を持つため、キー操作の列を文字列へ変換する、より複雑な 入力方式に依存する必要があります。別の言語では、特別な修飾キーを使用して 一部の文字を入力する必要がある場合があります。
単純ではない入力の例については、文字、キー操作、およびグリフの例を 参照してください。
文字列は通常、「文字」の列であると理解されています。 [Unicode]は、 レガシー 文字エンコーディングを使用するテキストを含め、テキストを理解し扱うための 基礎となるため、文字列の基本的な定義はUnicodeおよび 符号化文字という その概念に依存します。具体的には次のとおりです。
文字列は、0個以上の Unicodeスカラー値からなる 整形式の列です。
文字列を扱う方法は複数存在するため、さまざまな仕様のニーズを満たすために、「文字列」のさまざまな定義が発展してきました。 仕様のニーズを十分に理解し、最も適切かつ正確な定義を使用してください。文字列型を選択する際には、仕様内で 直接定義されているアルゴリズムだけでなく、文字列が渡される他のコンポーネントやプラットフォーム API を含め、 操作全体の要件を考慮してください。
Web には、3 種類の文字列があります。
USVString。1 つ以上の Unicode
スカラー値のシーケンスで
構成される文字列、つまり、文字列内の各 コード単位が
Unicode コード
ポイントである文字列です。DOMString。1 つ以上の UTF-16 コード単位のシーケンスで構成される文字列です。ByteString。特定の 文字エンコーディング形式を使用して解釈される
1 つ以上のバイトのシーケンスで構成される文字列です
（できれば UTF-8）。これらの異なる文字列型の相違点の 1 つは、サロゲート コードポイントの扱い方です。Unicode スカラー 値は、サロゲートコードポイント以外の Unicode コード ポイントです。コード単位は、文字 エンコーディング形式におけるエンコーディングの単位です。
UTF-16 文字エンコーディング形式では、
16 ビットの コード単位を使用します。この
エンコーディング形式では、スカラー値が 16
ビットを超える文字は、1 組の サロゲート コード単位を使用してエンコードされます。すなわち、「上位サロゲート」（範囲
U+D800-U+DBFF）の後に「下位サロゲート」（範囲 U+DC00-U+DFFF）が続きます。Unicode は、これらの範囲の コードポイントを UTF-16 サロゲートコード単位として使用するためだけに
予約しています。これらは Unicode スカラー値ではありません。
USVStringでは、
孤立したサロゲートコードポイントは
無効であり、実装は文字列内で見つかったものをUnicode置換文字
（�U+FFFD REPLACEMENT CHARACTER）へ置き換える必要があります。
最も一般的なアルゴリズムがスカラー値を処理する文字列
（パーセントエンコードなど）、または入力内のサロゲートを処理できない操作
（文字列をネイティブプラットフォームAPIへ渡すAPIなど）では、
USVStringを
使用するべきです。次の参照はいずれも、これと同等です。
DOMStringでは、
対になっていないサロゲート
コード単位が文字列内に
存在できます。ほとんどの文字列操作では、文字列内部のコード単位を解釈する必要がありません。
DOMStringを指定すると、
実装は文字列の内容を検証する必要がないため、ほとんどのデータ構造、形式、またはAPIに
適した文字列型となります。[DOM]およびJavaScriptの文字列は、
文字列型としてDOMStringを使用し、
[INFRA]標準は、「文字列」という用語を
DOMStringを
意味するものとして定義します。
文字列は、コード単位とも呼ばれる、 符号なし16ビット整数の列です。
[INFRA]における コード単位という用語は、 任意の文字エンコーディング 形式でバイトなど異なる大きさの値を指すことができる一般的な定義ではなく、 特にUTF-16 文字エンコーディングのコード単位を指します。
ByteStringは、
文字をバイトへエンコードするために使用される文字エンコーディング
形式に依存します。レガシー
文字エンコーディングには「サロゲート」という概念がないため、
通常はサロゲートコードポイントをエンコードする方法がありません。有効な
UTF-8は
サロゲートコードポイントを許可しません。テキストをUTF-8へエンコードする場合、または
UTF-8から復号する場合、サロゲートコードポイントは
�U+FFFD REPLACEMENT CHARACTERへ置き換えられます。
UTF-16から
UTF-8へ変換する場合、
すべてのサロゲートペアは、
特定のスカラー値を
エンコードする適切なUTF-8バイト列へ変換されます。
文書形式またはプロトコルの通信形式を定義する場合、
[DOM]に関連する処理を定義する場合、または
個々の文字の内容を評価しない不透明な値として文字列を定義する場合は、
DOMStringを
使用してください。（この用途の一覧は網羅的ではありません。）
最も一般的なアルゴリズムが USVString を使用して
Unicode
スカラー値を処理する文字列、または
入力内の サロゲートを処理できない操作には
USVString を使用してください。これには、文字列内の コードポイントを反復処理するアルゴリズム、
UTF-8
エンコードを伴う処理、および対になっていない サロゲート コードポイントによって
エラーが発生する別のコンポーネントまたは API に文字列を渡す操作が含まれます。
単一の文書またはプロトコル操作で
DOMStringと
USVStringを
混在させないでください。後者には、ほとんどの文書形式やプロトコルに利点をもたらさない
追加処理が必要となるため、多くの場合は
USVStringより
DOMStringを
選択します。
4.6 文字エンコーディングの選択には、 文字 エンコーディングに関連する追加のベストプラクティスが記載されています。
ウェブ上の文字列：言語および方向メタデータ [STRING-META]の レガシープロトコルまたは 形式の一部である文字列
Unicodeが広く採用される以前は、文字列をバイト文字列として
定義することが一般的でした。このような文字列は、文字または
コードポイントの列ではなく、
単なるバイト値の列です。バイト文字列のよく知られた例は、
Cプログラミング言語のchar*です。
バイト文字列の処理または解釈は、文字エンコーディング 形式に依存します。多くのレガシー 文字エンコーディングはステートフルです。このようなエンコーディングの処理には、 文字の状態を保持して抽象文字を正常に復号、処理、または変更できるよう、 バイトバッファーの先頭から処理を始める必要があることがよくあります。 このようなエンコーディングでは、同じバイト値でも、隣接するバイトに応じて 異なる意味を持つ場合があります。たとえば、まったく同じバイト値が単独で文字を表す場合もあれば、 直前のバイトに応じて、別の文字を表すマルチバイト列の一部になる場合もあります。 各バイトまたはバイト列の解釈方法を決定する規則は、レガシー文字エンコーディングごとに異なります。 誤った文字エンコーディングを 使用してバイト文字列を処理すると、不正な文字 （文字化けと 呼ばれることがある現象）が生じます。
UTF-8は、ウェブ上の通信形式および文書形式 [ENCODING]、および一般的なインターネット [RFC3629]で推奨される 文字 エンコーディングです。コンテンツがUTF-8でエンコードされている場合、 それをバイト列として処理する理由はほとんどありません。ほとんどのウェブAPIおよび インターフェイスでは、特定のバイト値ではなく対象の文字を表す コードポイント列の方が 重要です。
仕様がバイト値の格納、解釈、および操作を扱う必要がある場合もあります。
特に、多くの文書形式およびプロトコルは、7ビット
[ASCII]
バイトの使用を中心に定義され、さまざまな文字またはデータエンコーディング方式を使用して、
ASCII以外のデータ値を含めたり交換したりすることを許可していました。
これは、textメディア型のcharsetパラメーターのように、
文字エンコーディング
形式を指定することで行われる場合があります。または、
パーセント
エンコードなどの特殊な構文を使用して、バイト値をエンコードする場合もあります。
UTF-8が推奨および既定の文字エンコーディング 形式として普及したことで、ほとんどの仕様が基礎となるバイト値へアクセスしたり、 操作したりする必要性は低下しました。UTF-8は、7ビットASCIIテキストも有効なUTF-8となるよう 設計されています。これは、ASCIIに基づく形式をエンコードまたは復号する場合に重要となることがあります。
特定のバイト値を処理する理由がある場合、またはUTF-8の
文字
エンコーディングを想定できない場合を除き、バイトを使用して定義された
プロトコルまたは文書形式のフィールドには、
DOMString、
またはまれにUSVStringを
指定してください。
対象のフィールドを文字列として扱う場合、バイト値を直接扱おうとするよりも、 Unicode文字を扱う方が信頼できます。これらのフィールドへエンコードされたデータは、 通信形式から、[DOM]、JavaScript文字列、または プラットフォーム固有のUnicode文字列型など、ローカルのメモリ内文字列表現へ デシリアル化されます。その後、何らかの文字エンコーディング 形式（通常は、かつ推奨されるのはUTF-8）を使用して、 通信形式へシリアル化する必要があります。
テキストを含まないデータ、またはバッファーのコピー時など
処理を必要としないテキストを表すバイト列を扱う場合は、
Uint8Arrayを
指定してください。
仕様がバイトでエンコードされた文字列を扱う必要があり、
Unicodeとの相互変換が不適切となるまれな場合は、
ByteStringを
指定してください。
ウェブプラットフォーム設計原則 [DESIGN-PRINCIPLES]の IDL文字列型
ByteStringは、
汎用の文字列型ではありません。[WebIDL]の
データ構造を定義するために使用しないでください。
プロトコルまたは形式の仕様によって定義されるテキストデータオブジェクトは、 単一の文字エンコーディングでなければなりません。
ワールドワイドウェブの文字モデル：基礎の 参照処理モデルC013
テキストの処理を伴うすべての仕様は、この一覧の残りの推奨事項で 説明されている参照処理モデルに従って、テキストの処理を指定しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 参照処理モデルC014
仕様は、テキストデータオブジェクトについて、 Unicodeエンコーディング形式へ変換できる任意の文字エンコーディングの使用を 許可してもよいです。
ワールドワイドウェブの文字モデル：基礎の 参照処理モデルC014
仕様は、一部の文字エンコーディングを禁止または非推奨とし、 別のものを必須としてもよいです。実際の文字エンコーディングに関係なく、 指定される動作は、次のように処理された場合と同じでなければなりません。 （a）仕様を実装するアプリケーションが受信したすべてのテキストデータオブジェクトについて、 文字エンコーディングを判定し、そのデータオブジェクトをUnicode文字の列として 解釈しなければなりません。これは、必要に応じて文字エンコーディングラベルを調整し、 データオブジェクトを何らかのUnicodeエンコーディング形式へ変換して、 その形式で受信することと同等でなければなりません。 （b）すべての処理は、このUnicode文字列に対して行わなければなりません。 （c）アプリケーションがテキストを出力する場合、Unicode文字列は、 仕様で許可されている文字エンコーディングの中から選択したものを使用して エンコードしなければなりません。
ワールドワイドウェブの文字モデル：基礎の 参照処理モデルC014
複数のテキストデータオブジェクトが関係する仕様 （外部の解析対象実体を参照するXML文書など）は、それらのデータオブジェクトが 異なる文字エンコーディングであることを許可してもよいです。いずれの場合も、 参照処理モデルをすべてのテキストデータオブジェクトへ適用しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 参照処理モデルC014
仕様は、U+0000からU+10FFFFまでを含むUnicodeコードポイントの全範囲から、 コードポイントを恣意的に除外するべきではありません。
ワールドワイドウェブの文字モデル：基礎の 参照処理モデルC070。
ここで「サロゲートコードポイント」とは、U+D800から
U+DFFFまでを含む範囲の文字値の使用を指します。
これらのコードポイントは、UTF-16文字エンコーディングで
補助文字を
扱えるようにするため予約されています。サロゲートは常に対で使用され、
UTF-16エンコーディングを使用する場合にのみ現れます。単一のサロゲートコードポイントは
「対になっていないサロゲート」と呼ばれ、使用してはなりません。
仕様は、Unicodeに含まれない記号を伝送できるようにするため、 またはUnicode文字の特定の異体を識別するためのマークアップを定義してもよいです。
ワールドワイドウェブの文字モデル：基礎の 私用コードポイント、C041
仕様は、画像やグラフィックのために文字指向の仕組みを 誤用する必要をなくすため、適切な場合に画像やグラフィックを含めるか 参照できるようにするべきです。
ワールドワイドウェブの文字モデル：基礎の 私用コードポイント、C068
歴史的に、特にUnicodeが作成される前の時代には、多くの 符号化文字集合が 一般的に使用され、文字をコンピューターシステムのメモリまたは記憶域へエンコードし、 シリアル化するためのさまざまな方式が存在しました。ISO/IEC 8859で指定された方式などの 標準に基づく方式に加え、多くのベンダー独自またはプラットフォーム固有の 文字集合も存在し、 多くの場合、関連する文字エンコーディング 形式がありました。この文書でレガシー（Unicode以外）の 符号化文字集合の 文字エンコーディング 形式について言及する場合は、[Encoding]で指定されている、 バイトからUnicodeコードポイントへの特定の現代的な対応付けを意味します。
すべての文書形式、プロトコル、およびシリアル化形式で UTF-8を使用してください。
UTF-8は、ほぼすべてのアプリケーションにとって最適な選択です。
すべての新しい形式またはプロトコル、あるいは仕様が安全にそのように できる場合、仕様はUTF-8を唯一許可される文字エンコーディング 形式として定義しなければなりません。
新しいプロトコルおよび形式、ならびに新しいコンテキストで使用される既存の形式は、 UTF-8文字エンコーディングを使用する必要があります。この方針はIETFおよびウェブ標準に適用され、 [RFC2277]、 [RFC3629]、 [Encoding]、 [design-principles]などで 明記されています。レガシー 文字エンコーディングを必要とするのは、古いプロトコルまたは形式を扱う仕様のみであり、 その場合でもUTF-8が強く推奨されます。
歴史的な理由により仕様がレガシー 文字エンコーディングを許可する場合、使用できる 文字 エンコーディングを、Encoding標準の 「名前とラベル」の節に列挙されているものへ制限しなければなりません。 私的な合意による場合を除き、その他のエンコーディングを使用するべきではありません。
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの特定、 C021
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの特定、 C022
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの特定、 C023
複数の文字エンコーディング 形式を許可する仕様は、フィールドまたはパラメーターなど、 テキストのエンコーディングを明確に特定する仕組みを提供しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの選択と特定、 C015
文字エンコーディングは、 バイト値だけから確実に検出することはできません。UTF-8以外のエンコーディングが許可される場合は、 コンシューマーが エンコーディングを判定するための何らかの仕組みが必要です。
プロトコル、形式、またはAPIが、文字 エンコーディングの選択、適用、またはラベル付けの規則をすでに持つ形式に 基づいている場合、仕様は文字エンコーディングを特定するための別の仕組みを 定義してはなりません。
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの選択と特定、 C017
UTF-8以外の文字 エンコーディングを許可する形式に仕様が基づいている場合、仕様は文字エンコーディングを UTF-8へ制限するべきです。
文書形式またはプロトコルが、レガシー 文字エンコーディングをサポートすることがあります。そのような形式に基づく仕様は、 実行可能な場合、適合する実装がUTF-8のみを使用するよう指定できます。
仕様は、データのエンコーディングを判定するために ヒューリスティックを使用することを提案してはなりません。
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの特定、 C028
仕様は、文字エンコーディングに関する情報が複数存在する場合や 競合する場合に備え、優先順位などの競合解決の仕組みを定義しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 文字エンコーディングの特定、 C028
入力または編集が困難な文字列をプレーンテキストエディターで記述できるよう、 一般には文字エスケープを提供することが推奨されます。エスケープ列は、 ゼロ幅空白、ソフトハイフン、各種双方向制御文字、モンゴル語母音区切り文字など、 不可視または曖昧なUnicode文字に特に役立ちます。
マークアップでのエスケープ使用に関する助言については、他の形式にもほぼ一般化できる マークアップおよびCSSでの 文字エスケープの使用を参照してください。
ウェブまたは一般的なプログラミング言語で使用される、代表的なエスケープ機構の例を
次に示します。ここで使用する例の文字は、
😽U+1F63D KISSING CAT FACE WITH CLOSED EYESです。
| 使用される場所 | 種類 | 例 | 説明 |
|---|---|---|---|
| HTML、XML | 16進NCR | 😽 |
Unicodeコードポイントの16進エンコーディング |
| 10進NCR | 😽 |
Unicodeコードポイントの10進エンコーディング | |
| JavaScript、Ruby、Rust、[UTS18] | \u区切り形式 |
\u{1F63D} |
Unicodeコードポイントの16進エンコーディング |
| Perl | \x区切り形式 |
\x{1F63D} |
Unicodeコードポイントの16進エンコーディング。一般的な
uではなくxを使用します。
|
| Java、JavaScript、JSON、C、C++、Python | \u UTF-16コード単位 |
\uD83D\uDE3D |
UTF-16コード単位の固定幅16進エンコーディング。 補助 文字はサロゲートペアとしてエンコードされます。 |
| C、C++、Python | \U UTF-32コード単位 |
\U0001f63d |
UTF-32コード単位の固定幅16進エンコーディング。多くの場合、
\uエスケープ（より一般的な
BMP
文字には、こちらの方が効率的です）とともに使用されます。たとえば、 \u00c0 \U0001f63d \u12fe
|
| URL | URLエンコード | %F0%9F%98%BD |
UTF-8バイトの16進エンコーディング。各バイトには3文字が必要であり、 各コードポイントには1～4バイトが必要です。 |
エスケープ機構を選択する場合、Unicode標準およびその参照で16進表記が一般的に 使用されるため、通常は10進エンコーディングより16進エンコーディングが推奨されます。
エスケープ構文は、ካや
\u{12F}のような明示的な終了区切り文字、または
\u12ABや\U001234ABのような固定桁数の
いずれかを使用しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 文字のエスケープ、C044
終端区切り形式が推奨されます。
終端区切りエスケープは、コードポイントに必要な桁だけを使用できるため、 固定幅形式よりも短くなり、終了区切り文字によってエスケープが終了する場所も 分かりやすくなります。
数値を使用して文字を表現できる文字エスケープを仕様で定義する場合、 その数値は文字のUnicodeコードポイントを表さなければならず、 16進表記を使用するべきです。
ワールドワイドウェブの文字モデル：基礎の 文字のエスケープ、C045
エスケープされていない形式を使用できる場所では、 エスケープされた文字も使用できるべきです。ただし、構文上の意味を持つ文字が エスケープされた場合に、その構文上の意味を失うことを妨げるものではありません。 特に、識別子およびコメントで文字を使用できる場合は、そのエスケープ形式も 使用できるべきです。
ワールドワイドウェブの文字モデル：基礎の 文字のエスケープ、C046
プロトコル、データ形式、およびAPIは、テキストデータを 論理順序で格納、交換、または処理しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 視覚レンダリングと論理順序、 C003。
実装が論理選択と視覚選択のどちらを使用するかにかかわらず、 選択された文字は記憶域で論理順序に保持しなければなりません。
ワールドワイドウェブの文字モデル：基礎の 視覚レンダリングと論理順序、 C075。
範囲の選択を伴うプロトコルおよびAPIの仕様は、 少なくともそれらのプロトコルおよびAPI上で画面上の視覚選択を実装するために必要な範囲で、 不連続な論理選択を提供するべきです。
ワールドワイドウェブの文字モデル：基礎の 視覚レンダリングと論理順序、 C004。
空白文字は、組版における水平方向または垂直方向の空間を表す文字です。 空白文字には異なる視覚効果があります。視覚的な効果を持たない空白文字もあれば、 ページ上でより大きい、より小さい、または可変量の空間を表すものもあります。
「空白」という用語を使用する仕様は、その用語の意味を 明示的に定義するべきです。
ほとんどの仕様では、空白をUnicodeの White_Space プロパティを持つ文字として定義するべきです。
仕様が「空白」をASCIIまたはUnicodeの空白とは異なるものとして定義する場合、 具体的なコードポイントを列挙しなければなりません。
ECMAScriptなど一部の仕様では、 固有の要件を満たすため、上記とは異なる独自の空白定義を提供しています。
次の表は、さまざまな仕様における空白文字の定義を示します。
white_spaceプロパティ |
pattern_white_spaceプロパティ |
ASCII空白（HTML） | CSS空白 | ECMAScript | XML | |
|---|---|---|---|---|---|---|
 U+0009 (horizontal tab) |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
 U+000A (line feed) |
✓ | ✓ | ✓ | ✓ | ✓ | |
 U+000B (vertical tab) |
✓ | ✓ | ✓ | |||
 U+000C (form feed) |
✓ | ✓ | ✓ | ✓ | ||
 U+000D (carriage return) |
✓ | ✓ | ✓ | ✓ | ||
 U+0020 SPACE |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
 U+0085 (next line) |
✓ | ✓ | ||||
 U+00A0 NO-BREAK SPACE |
✓ | ✓ | ||||
 U+1680 OGHAM SPACE MARK |
✓ | ✓ | ||||
 U+2000 EN QUAD |
✓ | ✓ | ||||
 U+2001 EM QUAD |
✓ | ✓ | ||||
 U+2002 EN SPACE |
✓ | ✓ | ||||
 U+2003 EM SPACE |
✓ | ✓ | ||||
 U+2004 THREE-PER-EM SPACE |
✓ | ✓ | ||||
 U+2005 FOUR-PER-EM SPACE |
✓ | ✓ | ||||
 U+2006 SIX-PER-EM SPACE |
✓ | ✓ | ||||
 U+2007 FIGURE SPACE |
✓ | ✓ | ||||
 U+2008 PUNCTUATION SPACE |
✓ | ✓ | ||||
 U+2009 THIN SPACE |
✓ | ✓ | ||||
 U+200A HAIR SPACE |
✓ | ✓ | ||||
U+200E LEFT-TO-RIGHT MARK |
✓ | |||||
U+200F RIGHT-TO-LEFT MARK |
✓ | |||||
 U+2028 LINE SEPARATOR |
✓ | ✓ | ||||
 U+2029 PARAGRAPH SEPARATOR |
✓ | ✓ | ||||
 U+202F NARROW NO-BREAK SPACE |
✓ | ✓ | ||||
 U+205F MEDIUM MATHEMATICAL SPACE |
✓ | ✓ | ||||
 U+3000 IDEOGRAPHIC SPACE |
✓ | ✓ | ||||
 U+FEFF ZERO WIDTH NO-BREAK SPACE |
✓ |
一部の仕様では、上記のいずれかの列と同じ定義を使用しており、表には掲載されていません。
たとえば、WebDriverは
white_spaceプロパティを使用し、
WebGPUシェーディング言語は
pattern_white_spaceプロパティを使用します。
仕様内でUnicodeコードポイントを表すには、
U+XXXX構文を使用してください。
仕様内でUnicodeコードポイントを参照する場合、U+XXXX形式は
広く理解されています。列として現れる場合は、空白で区切ります。追加の装飾は必要ありません。
コードポイントには4桁、5桁、または6桁の16進数字を含めることができます。
4桁未満の場合は、コードポイント番号の先頭をゼロで埋めます。
特定のコードポイントを説明するには、Unicode文字名を使用してください。
Unicodeは、割り当てられた各Unicodeコードポイントに、一意で変更されない名前を
割り当てます。特定の文字を参照する場合、これらの名前を
U+XXXX表記のコードポイントとともに仕様で
使用すると、仕様の曖昧さをなくすことができます。
文字命名テンプレートの使用が推奨されます。
ほとんどの文字では、テンプレートは次のようになります。
<span class="codepoint" translate="no"><bdi lang="??">&#xXXXX;</bdi><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
bdi要素は、右から左へ記述する例の文字が
ページのレイアウトへ干渉しないようにするために使用されます。終了
bdiと、それに続く
code要素の間には、改行や空白を含めないでください。
空白と表示はスタイルによって制御されます。
特定のコンテキストで適切なフォントが選択されるよう、
lang属性を適切に設定するべきです。
東アジアの言語（中国語、日本語、韓国語など）またはアラビア用字系の例では、
言語タグの選択にさらに注意が必要となる場合があります。まれに、特定の言語について、
独自のスタイルシートでbdi要素のスタイルを
font-familyやfont-sizeによって
調整する必要がある場合があります。
制御文字などの不可視文字、結合文字、または空白には、文字の代わりに画像を使用してください。
または、文字とそれを囲むbdi要素を
省略してもかまいません。
<span class="codepoint" translate="no"><img alt="..." src="..."><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
短い文字列では、文字名を+で 区切って列挙するべきです。
文字名と追加のマークアップを含めることが過度に厳密で、使いやすさを損なう場合もありますが、
意味を損なうほど略式にしないよう注意してください。特に、長い列ではコードポイントだけを
列挙する場合がありますが、分かりやすくするため、可能な場合は文字名を残すべきです。
この文書の合成された「家族」絵文字に関する説明に例があります。
👨👩👧👧U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467
一般に仕様には、その文字の定義と、それらの文字に関連付けられた意味論の 両方が必要であるため、仕様は、ISO/IEC 10646への参照を含めるかどうかにかかわらず、 Unicode標準への参照を含めるべきです。
ワールドワイドウェブの文字モデル：基礎の Unicode標準およびISO/IEC 10646の参照、C062。
仕様の公開後に割り当てられた文字をその仕様で使用できるようにする場合は、 Unicode標準への一般的な参照を行わなければなりません。 特定のバージョンに依存する機能が利用可能であり、時間の経過とともに変更されないことを 保証するため、Unicode標準への特定の参照を含めてもかまいません。
ワールドワイドウェブの文字モデル：基礎の Unicode標準およびISO/IEC 10646の参照、C063。
Unicode標準へのすべての一般的な参照は、その参照を含む仕様の公開日時点で 利用可能なUnicode標準の最新バージョンを参照しなければなりません。
ワールドワイドウェブの文字モデル：基礎の Unicode標準およびISO/IEC 10646の参照、C064。
ISO/IEC 10646へのすべての一般的な参照は、その参照を含む仕様の公開日時点で 利用可能なISO/IEC 10646の最新バージョンを参照しなければなりません。
ワールドワイドウェブの文字モデル：基礎の Unicode標準およびISO/IEC 10646の参照、C065。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2番目のチェックボックスを選択してください。その後、 「GitHub用のMarkdownを作成」ボタンをクリックし、結果をGitHubのissue一覧へ コピーしてください。詳細を参照してください。
分割、索引付けなどに用いるテキスト単位の選択
識別子および構文コンテンツの文字列同一性照合
識別子および構文コンテンツの文字列同一性照合を、次の手順を使用して定義してください。
Unicode正規化の扱い
大文字・小文字畳み込み
文字列の切り詰めまたは長さの制限
文字列の連結
ファイル名とパス名の扱い
並べ替えおよび検索機能の指定
ソフトウェア処理が部分文字列へアクセスしたり、文字列内の位置を指したりする必要があり、 そのために索引、すなわち文字列内の数値的な「位置」を使用する状況は数多くあります。 そのような索引をウェブのコンポーネント間で交換する場合、一貫した動作を保証するには、 文字列の索引付けについて合意された定義が必要です。主に生じる2つの疑問は、 「何を計数単位とするか」と「0と1のどちらから数え始めるか」です。
ユーザー操作が主な関心事であるアプリケーションでは、 文字列の索引付けの基礎として書記素クラスターを使用してもかまいません。
ワールドワイドウェブの文字モデル：基礎の 文字列の索引付け、 C071
複雑な用字系の 組版文字単位 — 複雑な用字系の分割に書記素クラスターが不十分となる状況。
文字エンコーディング：基本概念の 文字と クラスター
書記素クラスターを用いて索引付けを定義する仕様は、次のいずれかを行わ なければなりません。（a） Unicode標準附属書#29、 Unicodeテキスト分割（UTR #29）で定義される拡張書記素クラスターを用いて 書記素クラスターを定義する、または（b）索引付け操作に調整をどのように適用するかを 具体的に定義する。
ワールドワイドウェブの文字モデル：基礎の 文字列の索引付け、 C071
Unicode標準附属書#29、Unicodeテキスト分割の 書記素クラスターの 境界
複雑な用字系の 組版文字単位 — 複雑な用字系の分割に書記素クラスターが不十分となる状況。
文字エンコーディング：基本概念の 文字と クラスター
反例は、DOM Level 1における UTF-16の使用です。UTF-16コードポイントを使用すると、2つのサロゲート文字の間に 索引が位置する可能性が残り、重大な問題が生じるため推奨されません （6.5 文字列の切り詰めまたは長さの制限を参照）。
部分文字列または文字列内の位置を識別する方法が必要な仕様は、 その操作を行うため、文字列の索引付け以外の方法を検討するべきです。
仕様は、使用する計数単位にかかわらず、単一の文字を部分文字列として 理解および処理し、索引を計数単位の間の境界位置として扱うべきです。
APIの仕様は、単一の文字または単一の「エンコーディング単位」を 引数型または戻り値型として指定するべきではありません。
8.3 構文コンテンツにおけるキーワード、識別子、および 名前空間の定義 （識別子および構文コンテンツを定義するための指針）
識別子および構文コンテンツの文字列同一性照合を、次の手順を使用して定義してください。
ワールドワイドウェブの文字モデル：文字列照合の 照合アルゴリズム
特定の理由がない限り、識別子および構文コンテンツの正規化 （すなわち、大文字・小文字畳み込みまたはUnicode正規化）を指定しないでください。
ワールドワイドウェブの文字モデル：文字列照合の 適切な正規化手順の実行
「ASCIIの 大文字・小文字畳み込み」は、ASCIIに制限された アプリケーション 内部識別子にのみ使用するべきです。
語彙の仕様は、構文コンテンツと文字データの境界、および実体の境界 （言語にインクルード機構がある場合）を定義しなければなりません。
ワールドワイドウェブの文字モデル：文字列照合の 正規化に関する 追加の考慮事項
仕様は、特定の語彙のエンコード、格納、または交換に使用する Unicode正規化形式を指定するべきではありません。
ワールドワイドウェブの文字モデル：文字列照合の 正規化に関する 追加の考慮事項。
コンシューマーまたはコンテンツ自体が非正規化表現に依存している 可能性があるため、Unicode文字エンコーディングへのコンテンツのトランスコード、 大文字・小文字畳み込み、またはその他のユーザーによる変更など、テキスト変換の副作用として 必要な場合を除き、実装は、交換、読み取り、解析、または処理されるテキストデータの 正規化形式を変更してはなりません。
ワールドワイドウェブの文字モデル：文字列照合の 正規化に関する 追加の考慮事項。
正準等価であるものの異なるUnicode文字列がセキュリティ上の問題となる場合、 仕様はそのことを文書化するか、警告を提供しなければなりません。
ワールドワイドウェブの文字モデル：文字列照合の 正規化に関する 追加の考慮事項。
正規化されたテキスト入力から非正規化出力を生成できる操作では、 結果の出力を正規化する必要があるかどうかを仕様で定義しなければなりません。仕様は、一部の操作について正規化を 任意としてもかまいません。その場合、既定では正規化を 実行するべきであり、正規化を無効にするには明示的な オプションを使用するべきです。
ワールドワイドウェブの文字モデル：文字列照合の 文書形式で正規化を 指定する場合の要件。
実装が最初に検査によってテキストが正規化形式であることを確認するか、 テキスト自体を再正規化していない限り、正規化に依存する操作を実行してはなりません。これらの規則の対象とならない私的システム内では、 私的な合意を作成してもかまいませんが、外部から観測可能な結果は、 規則に従った場合と同じでなければなりません。
ワールドワイドウェブの文字モデル：文字列照合の 文書形式で正規化を 指定する場合の要件。
テキストを変更し、正規化に依存する操作を実行する 正規化テキスト処理コンポーネントは、各変更後に正規化が行われたかのように動作し、 後続の正規化に依存する操作が常に正規化済みテキストを扱っているかのように動作しなければなりません。
ワールドワイドウェブの文字モデル：文字列照合の 文書形式で正規化を 指定する場合の要件。
文字列値の比較または照合を行う仕様は、Unicode正規化に関する 適切な注記または警告を指定するべきです。
仕様におけるUnicode正規化の使用または採用は、通常、特定の形式またはプロトコルで 照合をどのように行うかを定義する一部です。 仕様作成者および実装者が関連する複雑さを理解できるよう、国際化ワーキンググループは、 文字列の照合および比較に関する考慮事項を説明する文書、 ワールドワイドウェブの文字モデル： 文字列照合 [CHARMOD-NORM]を 作成しました。
仕様が選択する必要のある事項の1つは、仕様の語彙の一部として定義されるさまざまな 「値」の照合にUnicode正規化を要求するかどうかです。値は一般に文書形式または プロトコルの構文の一部であり、属性名または値、要素名または値、IDなどが含まれます。 照合の一部として正規化を使用しないという 推奨事項に従う仕様は、コンテンツ作成者への 注意喚起として次の注記を含めるべきです。
注記の例。この版では、何が「値」を構成するかについて必然的に具体性を欠いています。 仕様では、より具体的に記述することを検討できます。
この仕様では、比較を目的とした値のUnicode正規化を 許可しません。視覚的および意味的には同一でも、異なるUnicode文字列を 使用する値は一致しません。コンテンツ作成者は、同じエンコード列を一貫して 使用するか、値を選択する際に問題を引き起こす可能性のある文字を避けることを 推奨されます。詳細については、[CHARMOD-NORM]を 参照してください。
文字列照合の一部として正規化を要求することを選択した仕様は、次の警告を含めるべきです。
警告の例。この版では、何が「値」を構成するかについて必然的に具体性を欠いています。 仕様では、より具体的に記述することを検討できます。
この仕様は、値の照合中にUnicode正規化を適用します。 これにより、対象テキストの外観および意味に影響する場合があります。 詳細については、[CHARMOD-NORM]を 参照してください。
上記が要件を満たさない場合、または使用方法が不明な場合は、代替案または支援について I18N WGに連絡してください。
形式、プロトコル、または形式言語の定義の一部として文字列照合を 定義する仕様および実装（解析、照合、トークン化などの操作を含む場合があります）は、 使用する基準および照合形式を定義しなければなりません。 これらは、（a）大文字・小文字を区別する、（b）Unicode完全大文字・小文字畳み込みを 使用してUnicodeの大文字・小文字を区別しない、（c）ASCIIの大文字・小文字を 区別しない、のいずれかでなければなりません。
Unicodeの基本ラテン文字（ASCII）範囲を超える語彙について 大文字・小文字を区別しない照合を定義する仕様は、Unicode完全大文字・小文字畳み込み照合を 指定しなければなりません。
ワールドワイドウェブの文字モデル：文字列照合の Unicodeの 大文字・小文字を区別しない照合。
Unicodeの基本ラテン文字（ASCII）部分集合に制限された語彙について 大文字・小文字を区別しない照合を定義する仕様は、ASCIIの大文字・小文字を区別しない 照合を指定してもかまいません。
ワールドワイドウェブの文字モデル：文字列照合の ASCIIの 大文字・小文字を区別しない照合。
一部の仕様、形式、プロトコル、またはその実装では、特定の文字列の大きさに制限を 指定する必要があります。その理由には、処理、メモリ、データ構造の大きさなどに関する 制限があります。長さ制限はテキストの切り詰めまたは大きさの制限を伴うことが多いため、 仕様およびその実装は、テキストが破損せず、選択した制限によって特定の利用者にとって 機能が使用不能にならないよう、特に注意する必要があります。
特定の実用上または技術上の制限がない限り、仕様は文字列の長さに 制限を設けるべきではありません。
仕様で長さの制限を指定する場合、切り詰められた文字列には、 省略記号など、文字列が変更されたことを示す標識を含めるよう指定するべきです。
仕様または形式で長さ制限が必要となる理由は数多くあります。最も一般的な理由は、 データに基礎となる大きさの制限があることです。たとえば、データベースに固定サイズの フィールドがある、パケットサイズなどの実用的な境界がある、または記憶域の割り当てや 効率に関連するその他の実装上の詳細がある場合があります。もう1つの一般的な理由は、 表示領域または可視出力の大きさに制限があることです。
文字列の長さを制限する仕様は、その制限をUnicode コードポイントで 数えるのか、または特定の文字 エンコーディングのコード単位 （バイトなど）で数えるのかを指定しなければなりません。
文字列を切り詰める場合、文字列の大きさを数えるために使用する単位を決める必要があります。 あらかじめ定められた理由で切り詰めが行われるため、仕様で制御できない場合もあります。 ただし選択できる場合は、いくつかの一般的な指針を適用できます。
視覚的な長さ制限が必要な場合は、文字列を変更せず、テキストレンダリングの複雑さを
考慮するCSSのtext-overflow
[css-overflow-4]など、
テキストレンダリングまたはクリッピング機構を使用して視覚的な切り詰めを指定してください。
仕様では、利用可能な可視空間の代用として 視覚テキスト単位の数を 使用することにより、視覚的な制限へ対処しようとする場合があります。このような制限には、 行上の文字数を制限する、すべての視覚テキスト単位を同じ描画幅にしようとするなど、 さまざまな形式があります。視覚テキスト単位を使用する方が、 エンコードされた文字列内のコードポイント数または コード単位数より、 このような恣意的な制限に近くなります。しかし、テキスト表示の性質上、このような試みは 通常効果的ではありません。プロポーショナル幅フォント、複雑な用字系、スタイル付け、 アクセシビリティ機能、その他多くの要因により複雑になります。ほぼすべての場合、 視覚テキスト単位の制限は、実際にはピクセル幅を近似しようとするものです。 制限を実際に測定するには、表示コンテキスト内のフォントメトリクスが必要です。 アクセシビリティ設定などのローカル設定によって影響を受ける場合もあります。 ウェブページでは、CSSのtext-overflowプロパティにより、 テキストの内容を損なわずに視覚的な切り詰めを行えます。Unicode コードポイント数、 または書記素クラスター数を 基に特定のテキスト断片の大きさを推定する試みは、ほとんど無意味です。
文字列に許容される最大格納長を制限する仕様は、その長さを Unicodeコード ポイントで指定するべきです。
ほとんどの制限は、データベースフィールドの大きさやプロトコル内の長さ制限など、 実際には記憶域の制限に関連しています。このような制限は、Unicodeの コードポイント数、 または特定の文字 エンコーディングにおけるコード単位 （バイトなど）で表されます。コードポイントは、 すべてのUnicodeコードポイントを同じように扱うため、最良のユーザー体験を提供します。 テキストを40コードポイントで切り詰める場合、すべての言語および用字系で 同じ数のコードポイントを使用できます。これに対し、大きさの制限をUTF-8のバイトなどの コード単位で表す場合、 主にASCII文字を使用する言語のユーザーは、1コードポイント当たり2、3、または4バイトを 必要とする文字を主に使用する言語のユーザーより、一定の大きさの制限内で はるかに多くの文字（コードポイント）を使用できます。
結合文字列などの 視覚テキスト単位の途中で 切り詰めると、残りの文字列の意味が変わる場合があります。
長さ制限の表現方法（コードポイントかバイトか）を選択することに加え、 切り詰め境界を選択する問題もあります。テキストを コードポイントの 途中で分割してはなりません。これにより文字が破損するためです。また、 書記素クラスターの 途中でも分割するべきではありません。これにより、表示される文字の外観および意味が 変わるためです。意味へ影響しないようにするため、追加のコードポイントを削除する必要が ある場合があります。
文字列の長さ制限が、データベースフィールドの大きさや、他の場所で指定されたデータ値に 割り当てられたバイト数などの外部要因によって決定される場合があります。または、 固定長のバイト指向通信プロトコルを説明するなど、実用的な設計上の理由により、 長さ制限をコード単位で 指定する必要がある場合もあります。このような仕様およびその実装では、 次の考慮事項を含め、それによって生じる追加の複雑さを明示する必要があります。
このベストプラクティスは、UTF-8などのマルチバイトエンコーディングだけでなく、
16ビットのコード単位を使用するUTF-16にも同様に適用されます。
U+10000からU+10FFFFまでの
Unicodeコード
ポイントをエンコードするために使用されるUTF-16
サロゲートペアには、
2つのコード単位が必要です。
サロゲートペアの途中で恣意的に切り詰めると、エンコードされた文字が破損します。
[DOM]と相互作用する仕様またはAPIは、 length、substringData、insertData、 deleteDataなどの操作を含む文字データが、 Unicodeコード ポイントではなくUTF-16コード単位を 使用して指定されるという事実に対処する必要があります。これにより、不適切に文字 （コードポイント）の途中で切り詰められる場合があります。
仕様が文字列の長さ制限を コード単位で 表す必要がある一方、文字列の大きさを自由に指定できる場合は、許容可能な コードポイント数に、 関連する文字 エンコーディングの最大エンコードサイズを掛けた値に基づいて制限を選択してください。
固定サイズのバッファーへ格納できるコードポイント数は、
文字エンコーディング
形式とそのコード単位に依存します。
たとえば、UTF-8はUnicodeコード
ポイントを、1文字当たり1～4バイトを使用してエンコードします。
したがって、最大エンコードサイズは4コード単位です。
これに対し、UTF-16は1つまたは2つの16ビットコード単位を使用します。
したがって、最大エンコードサイズは2コード単位です。特定の文字列に少なくとも
50個のコードポイントを
格納する必要がある場合、UTF-8バイトでの長さ制限は50 * 4、つまり
200バイトになります。UTF-16での長さ制限は50 * 2、つまり
100個の16ビットコード単位（200バイトと同じ）になります。このような制限により、
文字列には常に少なくとも50個のコードポイントを格納できます。ただし、
使用する文字によっては、特定の言語ではさらに多くの文字を格納できる場合があります。
長さ制限を選択する場合、Unicodeにおける異なる用字系および言語の必要性を考慮してください。 特定の文字 エンコーディングで、テキストの大きさの制限を コード単位 （バイト長の制限など）で設定する場合、その制限では、異なる用字系に対する 文字エンコーディングの相対的な効率を考慮する必要があります。特にUTF-8は、 [Unicode]の マルチバイト文字エンコーディングです。UTF-8は、文字の Unicodeスカラー値に応じて、 1つのコードポイント当たり 1～4バイトを使用します。
テキストフィールドに設けられた制限をバイトで数える場合、そのフィールドへ格納できる 文字数は、格納される文字によって異なります。さまざまな言語を話すユーザーが 不利にならないようにするには、その言語でエンコードした場合に妥当な数の文字を 使用できる制限にする必要があります。
仕様がコード単位（バイトなど）で長さ制限を指定する場合、 その制限の測定に使用する文字 エンコーディングを指定しなければなりません。 そのような制限は、レガシー 文字エンコーディングを指定するべきではありません。
仕様が文字列の切り詰めを許可または要求し、長さを コード単位で表す場合、 制限の意味を理解するうえで文字 エンコーディングが重要になります。制限がバイト単位であり、 レガシー 文字エンコーディングが許可される場合、UnicodeデータをUnicode以外の エンコーディングへ変換すると、データが失われる可能性があることに注意してください （ほとんどのレガシー 文字エンコーディングは、Unicodeの部分集合しかエンコードしないためです）。
複数の文字列を連結して自然言語の テキスト値を作成することは、国際化のアンチパターンです。語順、数、文法上の性、 格、句読点、その他多くの要件は言語によって大きく異なります。このため、 実装が部分文字列から人間が読めるメッセージを生成するよう要求または提案することは 避けてください。
ユーザーに表示されるテキストを実装が作成または生成することを 仕様で要求する場合、テキスト方向に関連する潜在的な問題を回避する方法について、 仕様は実装者に指針を提供するべきです。
API、プロトコル、または文書形式の仕様は、表示名または説明を含むフィールドを実装が 作成または提供するよう要求する場合があります。このような文字列を個別の部分から 組み立てると、Unicode双方向アルゴリズム [UAX9]が 組み立てられた文字列を処理する方法により、表示または理解に問題が生じることがあります。 このような場合、仕様は、正しく表示される値を作成する方法について実装者へ指針を 提供するべきです。
一部の仕様では、さまざまな実装がファイル名またはファイルパスをどのように構築するかを 定義する必要があります。課題の1つは、異なるオペレーティングシステムで使用される 異なるファイルシステム上で一貫して機能する定義を作成することです。この節には、 ファイル名またはファイルパスの制限を定義する際の一般的な指針が含まれます。 これは、[EPUB-33]で策定された要件と、 実装経験に基づいています。
ファイル名は255バイトの長さに制限するべきです。
この制限は、元はMS-DOSで見られ、特定のUnixファイルシステムにも存在する制限、 およびこれらのファイルシステムに依存するか、その制限を取り込んだPKZIPなどの パッケージ方式に関連しています。これらでは、特定の「パス要素」 （ディレクトリ名を含む）が255バイトに制限されます。
パス名は65535バイトの長さに制限するべきです。
この制限は、UTF-16文字エンコーディングでパス長を32760 （32K）コード単位に制限するFAT32やNTFSなどのファイルシステムに存在する制限に 関連しています。各UTF-16コード単位は16ビット（2バイト）を使用するため、 バイトで測定すると制限は65,535になります。UTF-8で64Kバイトに 制限されたパス名は、これらのファイルシステムのパス長制限を超える可能性があることに 注意してください。UTF-8は可変幅エンコーディングだからです。
ファイル名およびパス名の定義では、次のUnicodeコードポイントを 使用してはなりません。
これらの文字は、さまざまなファイルシステムで相互運用性の問題を引き起こすことが 知られています。コンテンツの相互運用性が重要である場合、仕様および実装は ファイル名を付ける際に十分注意するべきです。制限文字の一覧は、既知の問題領域の 一部を回避するためのものですが、その他のすべてのUnicode文字がサポートされることを 保証するものではありません。
U+0022 QUOTATION MARKU+002A ASTERISKU+002F SOLIDUSU+003A COLONU+003C LESS-THAN SIGN
U+003E GREATER-THAN SIGNU+005C REVERSE SOLIDUS
U+007C VERTICAL LINE
U+007F DELU+0000...U+001FU+0080...U+009FU+E000...U+F8FFU+FFF0...U+FFFFU+F0000...U+FFFFFU+100000...U+10FFFFU+002E FULL STOP
（これには、多くのファイルシステムで特別な意味を持つファイル名
.および..も含まれることに注意してください）
アプリケーションでは、情報またはコンテンツの集合を整理する必要がよくあります。 これには、コンテンツの並べ替えが伴うことがよくあります。数値や日付など、多くの 非テキストデータ型は、内部データ表現を使用して容易に並べ替えることができます。 しかし、テキスト情報の場合、文字エンコーディングの性質と「アルファベット順」に関する ユーザーの期待により、さらに複雑になります。
重要な選択の1つは、テキストデータの並べ替えを完全に内部処理とするか、 その結果をユーザーへ表示するかです。
人間による閲覧または操作を目的としない、プログラム内部での 高速かつ決定的なテキストの並べ替えを必要とする仕様または実装は、 文字列の定義に従って文字列を並べ替えるよう指定するべきです。スカラー値文字列 （USVStringや 多くのXML処理など）では、コードポイント昇順を指定してください。 UTF-16に基づく文字列型 （DOMStringや 多くのJavaScript APIなど）では、コード単位昇順を指定してください。
内部で使用できる並べ替え順には、Unicode コードポイント順と、 UTF-16コード単位順の 2種類があります。どちらの順序でも、結果の一覧は特定のアルファベット順または 辞書順とは一致しません。
コードポイントによる 並べ替えは、USVStringのように、 文字列がコードポイント列として格納および処理される場合に適しています。 コード単位による 並べ替えは、DOMStringのように、 文字列が基礎となるエンコーディングを使用して格納および処理される場合に適しています。
これらの並べ替え順では、比較する文字列にいかなる正規化も適用しません。 これは、外観上は等価に見える一部の文字列が異なるものとして比較されることを意味します。 詳細については、文字列照合 [CHARMOD-NORM]を 参照してください。
ユーザーへ表示する自然言語テキストの並べ替えを扱う必要がある仕様または アプリケーションには、さらに複雑な問題があります。Unicodeは、 Unicode照合アルゴリズム [UTS10]の一部として 既定の照合（並べ替え）順を定義し、その後、特定の言語、 ロケール、文化の 必要性を満たすよう調整されます。
ユーザーに提示するためにテキストを並べ替える場合、 その並べ替え順は、そのアプリケーション内の特定のユーザーに最も適した ロケールに応じて 調整するべきです。したがって、提示順はユーザーごとに 異なる場合があります。
テキストの並べ替え方法、またはテキストデータを整理するためのアルファベットや
書記体系の使用方法は、言語および文化によって異なります。たとえば、ドイツ語話者は、
üU+00FC LATIN SMALL LETTER U WITH DIAERISISという文字を
uと同様に並べ替えます
（実際にはドイツ語には2つの並べ替え順があり、この文字の厳密な扱いが
わずかに異なります）。一方、デンマーク語話者は同じ文字をアルファベットの独立した
文字として扱い、「y」の後に並べます。
並べ替えた一覧に使用するロケールを決定する際には、複数の要因が関係する場合があります。 たとえば、アプリケーションは、データが表示されるページのローカライズに従って 値の一覧を並べ替える場合があります。別の場合は、ユーザーエージェントの実行時 ロケールまたはAPIへ渡されたパラメーターに従って並べ替える方が適切なことがあります。 重要なのは、この順序がユーザーやシステムによって異なる可能性を認識することです。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2番目のチェックボックスを選択してください。その後、 「GitHub用のMarkdownを作成」ボタンをクリックし、結果をGitHubのissue一覧へ コピーしてください。詳細を参照してください。
リソース識別子における 非ASCII文字のサポートを指定する状況は複雑です。これは、リソース識別子およびその直列化を 定義する仕様が少なくとも3つ、すなわちURI [RFC3986]、IRI [RFC3987]、および[URL]として 存在するためです。WHATWGの[URL]仕様は、 ブラウザーおよびその他のユーザーエージェントの実際の動作を文書化することで、この複雑さに 対処しようとするものです。URL仕様が掲げる目標は、両方のRFCを廃止することです。
一般に、ウェブ上の文書形式では、非ASCII文字をプレーンテキストとしてエンコードした リソース識別子、すなわち「IRI」を使用します。HTTP [RFC9110]などの プロトコルでは、非ASCII文字をパーセントエンコーディングを 使用してバイト列としてエンコードしたリソース識別子、すなわち「URI」を使用します。 [RFC3986]は、文字を バイトへエンコードするための特定の文字エンコーディングを 指定していないため、パーセントエンコーディングの エスケープは誤って解釈される可能性があります。これに対処するため、多くの現代的な プロトコルおよび仕様では、通信形式およびプロトコルでサポートされるASCIIの部分集合へ 文字をエンコードする際、IRIで指定されているとおり、リソース識別子にUTF-8文字 エンコーディングを使用することを想定しています。
多くの場合、特定のリソースの名前または識別子はユーザー入力から生成されるため、 文書形式またはプロトコルは、非ASCII文字を含むリソース識別子をサポートする必要があります。 一般にユーザーは、これらの値に自分の言語を使用する能力を制限されておらず、 また制限されるべきでもありません。
文書形式、データ構造、またはAPIを定義するウェブ上の仕様は、 リソース識別子を 指定する際に、[URL]を参照するべきです。[URL]仕様でサポートされない場合は、 代わりにIRI [RFC3987]を 指定してもかまいません。
プロトコルを定義する仕様は、通信形式で使用する リソース識別子を 指定する際に、URI [RFC3986]を 参照してもかまいませんが、 パーセントエンコードされた 値を文字として解釈する際にはUTF-8を使用しなければならないという追加要件を含めなければなりません。
[RFC3986]の定義によれば、 URI参照はASCIIの部分集合に制限されており、非ASCII文字を直接使用することはできません。 任意のバイト値をエスケープするために、パーセント エンコーディングが提供されています。しかし、特定のバイト列を文字として解釈する 場合（または特定の文字列をバイトとしてエンコードする場合）に、さまざまな レガシー文字 エンコーディングが使用される可能性があるため、パーセントエンコーディングだけでは 利用価値が限られます。国際化リソース識別子（IRI）[RFC3987]は、 [Unicode]のUTF-8エンコーディングに基づく 統一的な手法を使用して、リソース識別子における非ASCII文字のエンコードおよび解釈に関する 問題を解決します。
仕様は、リソース識別子で 使用を許可する文字について独自の制限を設けてもかまいませんが、 その制限は、リソース識別子の構文、転送形式、または仕様自体が定義するその他の要素と 競合する文字に重点を置くべきです。
一般には推奨されませんが、追加の制限を検討する場合は、追加の指針として [UAX31]および [CHARMOD-NORM]を 確認してください。
URIの新しい構文、またはURI内に含まれる新しい構文を定義する仕様は、 ASCIIレパートリー外の文字をUTF-8 文字エンコーディングを 使用してパーセントエンコードする よう指定しなければなりません。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2番目のチェックボックスを選択してください。その後、 「GitHub用のMarkdownを作成」ボタンをクリックし、結果をGitHubのissue一覧へ コピーしてください。詳細を参照してください。
マークアップにおける要素および属性の定義
マークアップにおけるプレーンテキストの扱い
構文コンテンツにおけるキーワード、識別子、および名前空間の定義
U+D800～U+DFFF）または非文字コードポイントを
許可するべきではありません。詳細
U+0000～U+001F）および
C1（U+0080～U+009F）制御文字を
許可するべきではありません。詳細
形式言語、文書形式、プロトコル、またはAPIを扱う仕様では、マークアップ、構文、または アプリケーション 内部識別子を定義する必要がよくあります。この節のベストプラクティスでは、 これらを定義する際のさまざまな要件を扱います。
マークアップ言語、または特定のマークアップ言語に基づく構文を定義する仕様では、 要素、属性、およびその値の定義が重要になります。たとえば、 [XML] DTDは、 特定の文書型で有効な要素および属性を定義します。
特定の文書形式、プロトコル、またはAPIを定義する仕様では、通常、予約キーワード、 フィールド名、または許可される値の識別子の定義が重要になります。その多くは アプリケーション 内部識別子であり、その名前および値は仕様によって完全に定義されます。 場合によっては、仕様によって、これらの一部またはすべてを、ユーザーが入力または命名できる ユーザー指定値として 使用することが許可されます。
ユーザーが読むことのできるコンテンツを含む属性値を定義しないでください。 そのようなコンテンツには要素を使用してください。
XML国際化のベストプラクティスの ベストプラクティス3： 翻訳可能な属性値を避ける
ユーザーが読むことのできるコンテンツを含む属性値を定義する場合は、 要素に含まれるテキストとは別に、そのテキストの方向および言語情報を示す手段を 提供してください。
作成者がspanのような
要素または構造を使用して、任意のインラインコンテンツに注釈を付ける方法を
提供してください。
XML国際化のベストプラクティスの ベストプラクティス14： spanのような要素の定義
国際化に必要な情報を適用するため、任意のテキストコンテンツに 使用できるspanのような要素を提供してください。
国際化情報には、言語および基底方向のメタデータ、インラインでの言語変更、 双方向テキストの動作変更、翻訳フラグなどが含まれる場合があります。
ワールドワイドウェブの文字モデル： 文字列照合 [CHARMOD-NORM]の 第2節 文字列照合の問題には、次のように記載されています。
ウェブは主として、文字データに基づく文書形式およびプロトコルで構成されています。 これらの形式またはプロトコルは、何らかの構造的マークアップまたは 構文コンテンツを 含むテキストファイルを中心に構成されたリソースの集合と 見なすことができます。このような構文コンテンツまたは 文書データを処理するには、照合（正規表現を含む）、索引付け、検索、並べ替えなどの 文字列に基づく操作が必要です。
ユーザー、特に実装者は、類似する文字列が一致するかどうか、またはテキスト、 特に構文コンテンツへ適用できるさまざまな変換の有効性について、単純すぎる期待を 持つことがあります。これは、ウェブ上のさまざまな種類のテキスト処理にも当てはまります。
ウェブは、文書内でテキストを表現できるさまざまな方法の影響を受けるため、 同じテキストを表現できる複数の方法を考慮しないと、ユーザーを混乱させたり、 予期しない、または不満を招く結果を引き起こしたりする可能性があります。
構文コンテンツとは、 このように定義された形式のテキストコンテンツ全体を指します。形式文法内のさまざまな トークン（識別子など）は、語彙と呼ばれます。
通常、語彙内の 「予約キーワード」は、アプリケーション 内部識別子と見なされます。これは、選択された値が何らかの意味 （通常は英語）を伝える場合でも、プログラム内部で使用され、エンドユーザーへ表示されない 値です。
仕様では、変数名やさまざまな種類のIDなど、コンテンツ作成者が値を設定することも 許可される場合があります。
相互運用性を促進するには、実装が、定義した構文 コンテンツの各部分を、確実かつ一貫して照合できる必要があります。
すべての文書形式またはプロトコルはUnicode文字列で構成され、Unicodeデータを転送できる 必要があるという前提から始めてください。処理を「複雑に」するように見える特性を持つ文字は、 多くの言語にとって不可欠な要素です。有効な文字の範囲に制限を設けると、国際的な ユーザー、特に母語でラテン文字を使用しないユーザーの利用性を意図せず損なう可能性が あります。絶対に必要な場合を除き、国際的なデータを転送、処理、および交換する能力を 損なったり禁止したりしないでください。
仕様がコンテンツを制限する理由は数多くあります。重要なのは、仕様の作成者が、 コンテンツにそのような制限を設ける決定の影響を検討し、その制限を実装者向けに 文書化していることです。
制限が上位の仕様によって文書化されている場合、そのコンテンツ制限は 文脈から明らかです。たとえば、HTTPヘッダーを定義する場合、 ヘッダーの名前をASCIIの特定の部分集合に制限することは暗黙に示されています （これはHTTPヘッダーの値には適用されないことに注意してください）。
仕様作成者がよく使用する方法は、語彙、または アプリケーション 内部識別子やローカルに定義された名前空間など、その部分集合を、慎重に選択した ASCII文字の集合へ制限することです。任意のデータを転送することを目的としない値では、 識別子、予約キーワード、および値をASCIIへ制限することにより、Unicode文字列の入力、 表示、および特に比較に固有の技術的課題を回避できます。
ASCIIの印字可能な部分集合とは、
C0制御文字（U+0000～U+001Fを含む範囲）および
U+007F DELを除外した、
Unicodeの基本ラテン文字
コードポイントの任意の部分集合です。
具体的な部分集合は、仕様またはアプリケーションのローカルな要件によって異なります。
ほとんどの部分集合には、すべてのASCII英数字が含まれます。
許可される句読記号の範囲、およびU+0020 SPACE文字を含めるかどうかは、
ローカルな要件（構文、エスケープ、または区切り文字としてこのような文字を使用するかどうか
など）によって異なります。
文書作成者が選択できる識別子またはデータ値（あるいはデータから導出される値）は、 多くの場合、他の言語をサポートする必要があります。使用できる文字集合をASCIIへ 制限すると、特にラテン文字を使用しない言語の話者や、ASCII範囲外の文字を使用する アプリケーションにとって、国際的な利用性が損なわれる可能性があります。識別子などの値が ユーザーデータから生成される場合や、記憶しやすさが重要な方法で外部から参照される場合は、 特に問題になります。たとえばCSSでは、予約キーワードの語彙が ASCIIの印字可能な部分集合に制限されている一方、クラス名には広範囲のUnicode コードポイントを使用できます。
名前を選択するための指針については、 8.3.2 アプリケーション内部データ値の定義
結合記号およびその他の特定の文字（接合子や双方向書式文字など）の扱いは、 特定の文書形式を解析する際に問題を生じさせる可能性があります。各識別子をどのように 「トークン化」（周囲のテキストから分離）するかに特に注意する必要があります。 その方法の1つは、通常のテキスト処理が後の識別子の照合を妨げないよう、 識別子の先頭に使用できる文字の範囲を制限することです。
Unicode識別子およびパターン構文 [UAX31]は1つのモデルを提供しており、 特にJavaやJavaScriptなどの プログラミング言語で使用されています。HTMLおよびCSSも、次の EBNF [XML]生成規則のように、 カスタム識別子のための文字 範囲の定義を提供しています。
PCENChar ::=
"-" | "." | [0-9] | "_" | [a-zA-Z] | #xB7 | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x37D] |
[#x37F-#x1FFF] | [#x200C-#x200D] | [#x203F-#x2040] | [#x2070-#x218F] | [#x2C00-#x2FEF] |
[#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]HTMLおよびCSSの処理では、識別子およびトークンを解析する際に、Unicode文字の 特性（特定の文字が結合記号であるかどうかなど）を考慮しないよう定義されています。 これにより、識別子を結合文字で開始しても確実に処理できますが、 プレーンテキストエディターでは同じように値を扱えない場合があります。
識別子を定義する際は、空白の扱いに注意してください。ASCII文字の
U+0020 SPACEおよび
U+0009 TAB以外にも、
Unicodeには水平方向の空白文字が存在することに注意してください。
フィールドおよび値には、ロケールにも文化にも依存しない名前を 選択してください。
フィールド名および値を含む識別子を定義する場合は、できる限り文化に依存しない名前を
選択してください。たとえば、米国固有のZIPCodeより
postalCodeを、文化との関連が強いfirstName/lastNameより
givenName/familyNameを使用することが望ましいでしょう。
仕様では、形式が大文字・小文字を区別するか、
区別しないかを決定する必要があります。たとえば、
値greenはGREENまたはGrEeNと
一致するでしょうか。
この節では、「大文字・小文字を区別する」および 「大文字・小文字を区別しない」という用語を混同しやすいため、 ここに示すように追加の強調を付けて表記します。
ASCIIの大文字・小文字を区別しない [INFRA]を使用して、 ASCIIの印字可能な部分集合に 制限された値について、大文字・小文字を区別しない照合を 指定してください。
[INFRA]の identical toまたは isを使用して、大文字・小文字を 区別する値の照合を定義してください。これには、 ASCIIの印字可能な部分集合に 制限されていないすべての値が含まれます。
非ASCII文字を許可する場合、識別子では大文字・小文字を 区別するようにしてください。コンテンツが ASCIIの印字可能な部分集合に 制限されている場合にのみ、大文字・小文字を区別しない比較を 行ってください。非ASCII文字列を大文字・小文字を区別しない方法で 比較するには、正規化や言語依存性を含め、 ワールドワイドウェブの文字モデル： 文字列照合 [CHARMOD-NORM]に 記載された非常に多くの問題へ対処する必要があります。
一部の仕様では、文書形式またはプロトコル内の特定のフィールドに使用する値を 定義する必要があります。データ値が数値や日付などの特定の型に関連付けられている場合、 フィールドの形式は通常、[XMLSCHEMA11-2]や [JSON-SCHEMA]など、 よく知られたスキーマを使用して定義されます。
機械による読み取りを目的とした、ローカライズ不可能な文字列データ値を 定義する仕様は、自然言語のテキストと容易に混同されない値を使用するべきです。
多くのプロトコル、文書形式、またはデータ構造では、内部使用の列挙値を定義します。 これらの値は、人間へ直接表示することを意図していません。仕様、プロトコル、または APIを扱うユーザーや、特定の文書または操作をデバッグする必要があるユーザーを 支援するため、これらの値に説明的な名前（多くの場合は英語）を付けると役立つ場合が あります。仕様でこれらの値を割り当てる際は、ユーザーがその値を自然言語のテキストの ように表示できると想定しないよう、選択する名前を「コードのように」見せるべきです。
アプリケーション内部の値を「コードのように」見せるために、さまざまなグループが 採用しているスタイルが複数あります。仕様に最適なものを選択してください。 これには次のものが含まれます。
U+005F LOW LINE）で
区切ります。人間が利用することを目的としたコンテンツを持つフィールドは、 常に自然言語の 文字列値として扱わなければなりません。このような各フィールドについて、 言語および基底方向のメタデータを取得できなければなりません。
人間が読める文字列、特に説明的な性質の文字列を含むフィールドは、 自然言語文字列であると想定しなければなりません。文字列を表示するユーザーが ソフトウェア開発者であると想定される場合でも同様です。文書またはデータ構造内の このような各フィールドについて、言語タグおよび文字列方向を判定できなければなりません。
この種類のフィールドに一般的に使用される名前には、name、
description、title、message、場合によっては
valueがあります。この判定方法の1つとして、仕様作成者またはユーザーとして、
フィールドの内容をSNAKE_CASE_SHOUTEDにすることに違和感がある場合、
そのフィールドは自然言語テキストとして扱う方が適切な可能性があります。
人間が利用することを目的としたフィールドは、 ローカライズ可能にするべきです。
これにはさまざまな形式があります。たとえば、仕様またはプロトコルは言語ネゴシエーションを 許可し、最も一致するローカライズ済み文字列のみを返す場合があります。または、 特定のリソースに、コンシューマーが 選択できる複数の言語が含まれる場合があります。
フィールド名およびその他の列挙値は、 ローカライズ可能な表示名で包み込むべきです。
フィールド名および列挙値は、その名前がプレーンテキストのように見え、 ユーザーが理解できる場合でも、自然言語テキストではありません。これらのフィールドおよび 値には言語または方向のメタデータを関連付けるべきではなく、必要な場合は、 適切にローカライズされたラッパーを提供するよう、仕様で実装者を導くべきです。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2番目のチェックボックスを選択してください。その後、 「GitHub用のMarkdownを作成」ボタンをクリックし、結果をGitHubのissue一覧へ コピーしてください。詳細を参照してください。
縦書きテキスト
beforeおよびafterの行位置に依存するべきではありません。詳細vertical-値に相当する縦書きモード（のみ）は、
文字のデフォルトの向きを適用するために[UTR50]を使用するべきです。
（これは、CSSのsideways-に相当する
書字モードには適用されません。）詳細
sideways-lrやsideways-rlのような値を提供するべきです。これらの場合、
UTR50は適用されません。詳細
RTL／双方向テキスト
テキスト方向が変化する場合のボックス配置座標の設定
論理プロパティ（未定）
筆記体テキスト
ルビ注釈
rb rb rt rtに近い列として
配置できるもの）をサポートするべきです。詳細rb要素のように、ルビ基底に明示的な要素を使用できるようにする
べきです。詳細フォント管理（未定）
下線や上線などのテキスト装飾では、線が文字のインク部分を避けられるように するべきです。
上線および下線とテキストとの距離を指定できるようにするべきです。
下線などのテキスト装飾でインク部分を避けることは、アラビア文字などの一部の文字体系には 適切でない場合があります。アラビア文字では、代わりに下線をベースラインからさらに離すことが 望まれます。
日本語、中国語、韓国語、モンゴル語などの言語について、 テキストを縦書きで描画できるようにするべきです。
縦書きテキストは、LTR（例：モンゴル語）およびRTL（例：日本語）の 行進行方向をサポートしなければなりません。
デフォルトでは、行を左から右へ積み重ねる縦書きテキスト
（例：モンゴル語）のテキスト装飾、ルビなどは、CJK縦書きテキストと同じ側に
表示されるべきです。配置は、beforeおよび
afterの行位置に依存するべきではありません。
CSSのvertical-値に相当する縦書きモード（のみ）は、
文字のデフォルトの向きを適用するために[UTR50]を使用するべきです。
（これは、CSSのsideways-に相当する書字モードには適用されません。）
横書き用文字体系のテキスト行を縦方向に回転できるよう、
書字モードはCSSのsideways-lrやsideways-rlのような値を提供するべきです。これらの場合、
UTR50は適用されません。
デフォルトでは、通常横書きされる文字体系のグリフは、 文字の上部が縦書き行の右側を向くように、縦書きテキストの行に沿って配置されるべきですが、 正立した向きのまま行を下方向へ進められる仕組みも存在するべきです。 このような仕組みでは、最小のテキスト単位として視覚的テキスト単位 （書記素クラスタなど）を 使用するべきですが、必要な場合は、複数の書記素クラスタを含む音節クラスタを1つの 単位として扱えるようにするべきです。
縦書き行内で正立するアラビア語テキストは、独立形の字形を使用し、 テキストの順序は上から下へ読むようにするべきです。
一部の文字列（特に数字）を縦書き行内で横書きに配置できるようにする べきです（縦中横）。
字形を傾斜させられる仕様は、特定の言語の要件に応じて、 文字を右または左のいずれにも傾斜できるようにするべきです。
ボックスの配置座標では、テキストが横書きか縦書きかを 考慮しなければなりません。
ユーザーインターフェイスまたはウェブページをローカライズする際には、
RTL版とLTR版で鏡像を作成するのが一般的です。たとえば、英語コンテンツを含む
ウィンドウの左側付近に表示されるボックスは、コンテンツがアラビア語またはヘブライ語の場合、
ウィンドウの右側付近に表示される可能性があります。絶対座標を使用する強い理由がない限り、
現在の文脈の基底方向に基づいて、この変更が自動的に行われることが望まれます。
これを実現する方法の1つは、位置を示すためにleftおよびrightではなく、startおよびendなどのキーワードを使用することです。
アラビア語、モンゴル語、ンコ文字などの筆記体テキストで連結された文字に 透明度を適用する場合、重なり部分が見えてはなりません。
テキストの縁取りや影を追加する場合、筆記体テキストの連結文字が 隣接する文字から分離されてはなりません。
中国語、日本語、韓国語、モンゴル語のテキストでは、 横書きおよび縦書きの両方で、基底テキストの横に「ルビ」形式の注釈を サポートするべきです。
ルビ実装は、繁体字中国語用の注音符号（ボポモフォ）ルビを サポートするべきです。
ルビ実装は、表形式のコンテンツモデル
（ルビコンテンツをrb rb rt rtに近い列として配置できるもの）を
サポートするべきです。
ルビ実装では、HTMLのrb要素のように、ルビ基底に明示的な要素を
使用できるようにするべきです。
ルビ実装では、注釈を基底テキストの片側または両側に 表示できるようにするべきです。
HTMLのルビマークアップは、中国語、日本語、韓国語、モンゴル語の 要件に特化して設計されており、一般的な語釈の仕組みとして使用するべきではありません。
行の高さは、英語の文字より背の高い文字を収容できなければなりません。
ボックスの大きさは、翻訳時のテキストの膨張を収容できなければなりません。
行の折り返しでは、非ラテン文字体系に必要な特別な規則を 考慮するべきです。
さまざまな非ラテン文字体系では、単語間の空白だけでテキストを折り返すわけではありません。 遵守しなければならない追加の規則があります。たとえば、次のとおりです。
追加の背景情報については、CSS Text Level 3仕様を 参照してください。（必要な場合は、このチュートリアルに 追加の例があります。）
表示専用マークアップであるb、i、またはuは、
文字体系間で相互運用できず、ローカライズに不要な問題を生じさせる可能性もあるため、
避けるのが最善です。また、一部の文字体系には強調のための固有の方法があり、
太字、斜体などを使用せず、それらとは大きく異なる場合があります。
HTMLの場合には歴史的な事情がありましたが、仕様にそのような事情がない限り、 テキストの表示方法はスタイルを使用して決定し、マークアップやタグ付けでは 一般的な意味論的手法を使用できるようにすることが推奨されます。
bおよびiタグを取り巻く問題の説明については、
<b>および
<i>要素の使用を参照してください。
これは、この節に含まれる要件のみをまとめた一覧で、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2番目のチェックボックスを選択してください。その後、 「GitHub用のMarkdownを作成」ボタンをクリックし、結果をGitHubのissue一覧へ コピーしてください。詳細を参照してください。
ロケールの影響を受ける値の扱い
時刻の扱い
人名の扱い
数値の扱い
フォームの設計
ユーザー入力（未定）
ローカライズ
言語および文化的な設定をサポートするソフトウェアシステムは、
国際化されている
といいます。国際化されたシステムは、ユーザー設定に基づいて、
言語または文化に固有の処理を提供するAPIを使用します。これらのユーザー設定は通常、
ロケール
と呼ばれます。一般的な国際化用語の詳細については、
言語タグとロケール識別子 [LTLI]を
参照してください。
データ形式を定義する際は、ロケールに依存しない直列化形式を 使用してください。
機械可読であり、特定の言語または文化に固有でないデータ値は、さまざまな文化的表現の いずれかを使用する値よりも長期的に利用しやすく、誤解されにくくなります。 日付、通貨、数値などは似て見えても、ロケールによって意味が 異なる場合があります。たとえば、文字列4/7で表された日付は、 ユーザーの設定によって4月7日または7月4日と解釈される可能性があります。同様に、 €2,000は、2000ユーロまたは小数精度が過剰な2ユーロの表現の いずれかになります。ロケールに依存しない形式を使用することにより、システムは、 ユーザーの言語または所在地に応じて異なる特定の交換規則を確立する必要を避けられます。 データがすでにロケール固有の形式である場合は、ロケールパラメーター （通常は言語タグの形式）を 提供してロケールと言語を明示することで、ユーザーはデータをどのように扱うかを判断したり、 自動翻訳サービスを有効にしたりできます。
一般的なデータ直列化形式のほとんどは、ロケールに依存しません。たとえば、
[XMLSchema-2]の
xsd:integerやxsd:dateなどの型は、ロケールに依存しない
データ交換を目的としています。ロケールに依存しない表現を使用すると、複雑な解析や
誤解を伴わずにデータ値を正確に処理できるほか、どのロケールでもデータの利用者が
最も使いやすい形式でデータを表示できます。たとえば、「€2000,00」を文字列として
保存するより、次のようなデータ構造を交換することが強く推奨されます。
…
"price" {
"value": 2000.00,
"currency": "EUR"
}
…暦および日付システムを定義する際は、西暦紀元以前の日付を許可するか、 少なくとも一般的な範囲外の日付の扱いを定義してください。
時刻または日付のデータ型を定義する際は、タイムゾーンまたは UTCとの関係が常に定義されるようにしてください。
日付および時刻のデータ型では、うるう秒を許可してください。
これは、1分間の秒数が0から60の範囲になる場合に時折発生します （つまり、その1分には61秒あります）。
日付および時刻の値について説明する際は、一貫した用語を使用してください。 タイムゾーンに依存しない値には「浮動」時刻を使用してください。
タイムゾーンの定義とタイムゾーンオフセットの定義を分離してください。
タイムゾーンを識別するにはIANAタイムゾーンIDを使用してください。 オフセットまたはLTOをタイムゾーンの代用として使用しないでください。
タイムゾーンを識別するには、個別のフィールドを使用してください。
「週」の規則を定義する際は、文化固有の規則を適用できるように してください。
たとえば、週末が常に土曜日／日曜日とは限らず、週の最初の日が常に日曜日 ［または月曜日、その他］とは限りません。
年間の週番号の規則を定義する際は、文化固有の規則を適用できるように してください。
グレゴリオ暦以外の暦を許可する場合は、「月」フィールドが13 （第13月）までになる可能性があることに注意してください。
人名を使用するアプリケーション（ウェブフォーム、データベース、オントロジーなど）を 作成する開発者は、他の国の名前がどれほど異なる可能性があるかを認識していないことが よくあります。その結果、外国のユーザーについて過度な前提を置いたフォームや データベースを構築してしまいます。この節では、世界各地の人名を扱うための指針を示します。
世界各地の名前は、構成および各要素の順序が大きく異なります （世界各地の人名を 参照）。たとえば、保存するために人名を小さな部分へ分割してデータベースへ格納し、 後でそれらを取得しようとすると、特に何らかの再構築が必要な場合に問題が生じる 可能性があります。問題には、名前のどの部分をどのデータベースフィールドへ格納するか （特に名前の部分がデータベースのフィールド数より多い場合または少ない場合）を 判断することや、実際に使用するためにデータベースから人名を取得する際に、 名前の各部分の順序を扱うことなどがあります。
さまざまな背景を持つ人々の名前を受け付けるフォームまたはデータベースを設計する場合、 名や姓などについて、本当に個別のフィールドが必要かを検討するべきです。 これはデータを何に使用するかによって異なりますが、可能である場合は、ユーザーが 入力した氏名をそのまま使用する方が明らかに簡単です。
一部の文化における名前は、自分の文化の名前よりかなり長い場合があることに注意してください。 長い名前を入力できる十分な長さのフィールドを用意してください。また、名前が必ず 2文字以上あると想定しないでください。
特に、長さをバイト単位で数えることは避けてください （4.2 「文字列」の定義の選択を参照）。 UTF-8の4文字の日本語名が4バイトに収まると想定しないでください。実際には 12バイト必要になる可能性があります。
この節の指針は、保存または表示のために人名を分割する必要があると判断された場合に 適用されます。
「ファーストネーム」および「ラストネーム」というラベルの使用は 避けてください。「名」および「姓」などの代替表現を検討してください。
世界各地の人名の名前を 分割するための方法。
世界各地の人名の相違点の例。
通常、姓の後に名を書く人にとって、「最初」と「最後」という用語は混乱を招く可能性が あります。米国のユーザーを対象としたフォームでは「最初」と「最後」を使用しても 問題ないように見えるかもしれませんが、最終的には米国内外の異なる文化的背景を持つ 人々がフォームを使用する可能性があります。
また、一部の文化では依然として問題があることにも注意してください。たとえば、 アイスランド人は実際には姓を持たず、名と父称を持ちます （名と 父称を参照）。ただし、高度にローカライズされたカスタマイズを行わない限り、 一般的な解決策としては、これが最善である可能性があります。
氏名フィールドに加えて、特定の目的に必要な名前の一部を ユーザーが入力できる追加フィールドを1つ以上設けることが適切かどうか 検討してください。
世界各地の人名の名前を 分割するための方法。
世界各地の人名の相違点の例。
たとえば、名前の一覧をアルファベット順に並べたり、連絡時に呼びかけたりするために、 名前の一部を特定したい場合があります。
この追加フィールドは、多数の名前要素の一覧から適切な名前を見つける場合や、 愛称を扱う場合にも役立ちます（たとえば、タイでは人を指す際に愛称を使用することが 一般的です）。
本人へ直接呼びかけたり言及したりするために、名前の一部を使用できるよう、 個別のフィールドを選択することもあります。たとえば、ソーシャルメディアアプリが 「Davidの連絡先」と表示する場合です。または、上部に名前を記載したメールを送信する ためかもしれません。ここでは、名前の構文に起因する問題だけでなく、形式性に関する 世界各地の異なる期待も考慮する必要があります （見知らぬ人から名で呼ばれることを誰もが喜ぶわけではありません）。 たとえばプロフィールを設定する際に、その人がどのように呼ばれたいかを別途尋ねる方が 適切な場合があります。
たとえば、名前を「名」の後に「姓」という順序で入力すると想定しないでください。 また、複数の単語で構成された名前について、どの部分がどの分類に該当し、 どの部分が父親の名前、村の名前、氏族名など、まったく別のものに関連するかを 常に識別できると想定しないでください。
たとえば、暗黙の「n」最適化を使用するv-cardおよびh-cardの手法は、 中国語の名前などで問題が生じる可能性があります。必要だと考えるデータを確実に 取得できるよう、入力フォームでは名前の指定方法をできる限り明確に説明するべきです。
実際に1文字の名前を持つ人もいます。フォームの検証処理がその名前を拒否し、 名前を省略せずに入力するよう要求すると、そのような人々に問題が生じます。 イニシャルを使用しないよう促したい場合は、フォームの送信を拒否するのではなく、 警告メッセージにする方がよいでしょう。
インド南部、マレーシア、インドネシアの一部などの文化では、多くの人が父称を持たず、 名だけで構成される名前を持っています。姓を必須にすると、フォームを通過するためだけに 姓フィールドへ「.」や「Mr.」などの無意味なデータを入力することになり、 これらの文化で重大な問題を引き起こす可能性があります。
名前でハイフン、アポストロフィなどの句読記号を使用できるようにし、 それらの文字に代替コードポイントが存在する可能性も考慮してください。
世界各地の人名のその他の 注意事項。
世界各地の人名の相違点の例。
これにより、Dina Asher-SmithやChristopher O'Connellのような名前を正しく扱えます。
アポストロフィは、'U+0027 APOSTROPHE、
ʼU+02BC MODIFIER LETTER APOSTROPHE、
または場合によっては’U+2019 RIGHT SINGLE QUOTATION MARKとして
表示される可能性があることに注意してください。ハイフンは、
-U+002D HYPHEN-MINUS、
‐U+2010 HYPHEN、または日本では
゠U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHENを
使用して表される場合があります。
一部の名前（「McNamara」など）には先頭以外の大文字が含まれ、別の名前 （「van der Waals」など）には大文字で始まらない単語が含まれます。 フォームはユーザーが入力した大文字・小文字を保持し、各単語の先頭を常に、 または先頭だけを大文字にするよう強制してはなりません。
これにより、Gabriel García Márquezのような姓（姓はGarcía Márquez）や、 José María Olazábalのような名（姓はOlazábal）を正しく取得できます。
同じ家族の構成員が同じ姓を共有すると想定するのは誤りです。西洋では結婚後も 自分の名前を保持する人が増えていますが、中国など、それが通常の慣習である文化も あります。一部の国では、妻が夫の姓を名乗る場合も、名乗らない場合もあります。
ヒスパニック系の名前では、家族の子どもだけが同じ姓を持ち、その姓が両親の いずれとも異なる場合があります。Manuel Pérez Quiñonesの姓（Pérez Quiñones）は、 父親の姓がPérez Rodríguez、母親の姓がQuiñones Alamoであったことから 形成されました。やがて彼は、Padilla Faltoという姓の女性と交際しました。 結婚すると、彼女の姓はPadilla de Pérezになりました。子どもたちは Pérez Padillaと呼ばれ、以後も同様に続きます。
名前の変更が夫から妻への一方向であると単純に想定するべきでもありません。 結婚時に男性が妻の姓を名乗る場合もあります。このような場合、フォームでは 「旧姓」または「結婚前の姓」ではなく「以前の名前」と表記する方が適切な場合があります。
名前をラテン文字と現地文字の両方で保存する必要がある可能性があります。 その場合、ユーザーに対して、現地文字による名前とラテン文字のみの名前を別々の項目として 送信するよう求める必要があります。
世界各地の人名の文字サポートへの 影響。
世界各地の人名の相違点の例。
複数のフィールドが必要かどうかは、人名を何のために収集し、どのように使用する予定かに ある程度依存します。
たとえば、日本のユーザーは、表意文字による表記の代わりに、またはそれに加えて、 日本語の音節文字による転写を入力する必要がある場合があります。このフィールドは 日本人名の並べ替えに使用されるほか、名前を見る人が読み方を確認できるようにします。
実名の使用を強制する際に、珍しい名前や予想外の名前を 拒否しないでください。
名前が開発者の想定に一致しないため、サービスを利用できなかった人の例を見つけることは 難しくありません。実名の使用を強制する予定である場合は、名前が珍しい、または 予想外の構造を持つときに、本人が実際の名前を検証できる仕組みを用意する必要があります。
人名を含む例を掲載する標準および標準関連文書では、 世界中の読者を反映するため、さまざまな名前を使用してください。 特定の地域に固有の名前へ偏ることは避けてください。
多くの仕様では、物語性を高めるために、人名を使用したユーザーストーリーや ユースケースなどの例を示します。一貫性をある程度保つため、セキュリティ仕様で 「Alice」および「Bob」という名前を使用するなどの慣例を持つグループもあります。 システムおよびサービスを構築する際には、包摂性を重要な目標にするべきです。 そのため、例を作成する際に世界的に多様な名前を使用することを推奨します。 これにより、私たちの技術が世界中のユーザーコミュニティを表現することを保証し、 仕様を世界中のユーザーにとってより関係のあるものに見せることができます。
ヨーロッパ由来の少数の名前だけでなく、世界各地の異なる地域の人々を表す名前を 選ぶよう努めてください。非ASCII文字を含む名前を選択すると、Unicodeのサポートや その他の国際化上の考慮事項がユーザーに適用されることを実装者へ思い出させるのにも 役立つことに注意してください。
どのような名前の集合も、文化およびジェンダーに関連する問題について完全に中立には なれません。仕様作成者がより包摂的な例を作成できるよう、この文書では多くの文化から 集めた名前の一覧を提供します。これらの名前はおおよそ地域別に整理され、通常は 国または言語を示します。これらの地域内でさえ、人名の扱いには非常に多様な影響および 慣習が存在することに注意してください。仕様作成者が例を書く際に役立つよう、 名前は文化的なジェンダーとの関連によっても分類されていますが、多くの名前は 特定のジェンダーに固有ではありません。
英語の例へ他文化の人名を挿入する場合、世界各地で名前が文化的に大きく異なる方法で 使用されることにも影響を受けます。たとえば、名に加えて父称または母称を使用することが 期待される文化や、より形式的な名前を好む文化 （たとえば、非公式な「Albrecht」に対する「Herr Dürer」）があります。
中国人は、姓を含めずに名だけを使用することはほとんどありません。 中国語で例を書く場合、「典型的な名前」ではなく、路人甲 （十干の序数を使用した「人物A」という意味。既製の カウンタースタイルを参照）のようなものを使用する場合があります。 名前を使用する場合は、姓と名の両方を含めます。中国語では姓が先にあり、 名の前に置かれることに注意してください。
日本語では、形式性のレベルに関する複雑な選択があります。非常に非公式な状況では
名（Hiroshi）で呼ぶ場合もありますが、通常は、
失礼にならない限り、-sanや-samaなどの敬称または接尾辞を
付けた姓（例：Tanaka-san）で呼びます。先輩や非常に尊敬される人物には
senpaiやsensei、面識のない人物にはshiなど、
その他の接尾辞や敬称も使用されます。そのため、英語の例で
Hirokiが…を設定したいとしますと書ける場合でも、
Tanaka-sanが…を設定したいとしますと書く方が文化的に適切である可能性があります。
次の表は国際化ワーキンググループによって作成されました。追加または修正に関する 提案や協力を歓迎します。
この名前の一覧は、一般に英語話者向けに執筆する仕様作成者を支援することを 目的としています。この一覧は主に名で構成され、必要に応じてラテン文字へ 翻字されています。多くの文化で実際にはこのように名前を使用しない場合でも、 名前は非公式な形式（「Ms. Jones」ではなく「Alice」）でも 表示されています。仕様を翻訳する際は、対象読者に適した調整を行うべきです。
名前が非ラテン文字の言語または文化から採られている場合、名前が決してラテン文字に 限定されないことを思い出させるため、または非ラテン文字の例を含めたい場合に備えて、 非ラテン文字による表記も提供されています。
この表は、見出し行の△または▽の矢印をクリックして並べ替えられます。
| 名前 △▽ | 現地表記 △▽ | ジェンダー △▽ | 地域および注記 △▽ | 言語 △▽ |
|---|---|---|---|---|
| Akamu | m | オセアニア；ポリネシア；ハワイ語の名前 | haw | |
| Alinta | f | オセアニア；オーストラリア先住民の名前 | nys | |
| Amélie | f | ヨーロッパ；フランス | fr | |
| An | 杏 | f | 東アジア；日本 | ja |
| Aoi | 葵; 蒼; 碧 | f, m | 東アジア；日本 | ja |
| Aroha | f | オセアニア；マオリ | mi | |
| Åsa | f | ヨーロッパ；スウェーデン | sv | |
| Asahi | 朝陽 | m | 東アジア；日本 | ja |
| Atlahua | m | ラテンアメリカ；ナワトル語の名前 | nah | |
| Beata | f | ヨーロッパ；複数の国 | it, de, pl, sv, etc. | |
| Chanda | चंदा | f | 南アジア；元はサンスクリット語 | sa |
| Chirapathi | சிரபதி | f | 南アジア；タミル語 | ta |
| Citlali | f | ラテンアメリカ；ナワトル語 | nah | |
| Coen | m | ヨーロッパ；オランダ；オセアニア（オーストラリア先住民）または ヘブライ語の名前でもある | nl, he, nys | |
| Daisho | 大翔 | m | 東アジア；日本 | ja |
| Dara | f | 西アジア；ヨーロッパ；トルコ | tr | |
| Eva | Е́ва | f | ヨーロッパ；ロシア | ru |
| Faheem | فهيم | m | 西アジア；アラビア語 | ar |
| Fátima | فَاطِمَة | f | 西アジア；アラビア語；ラテン文字では複数のヨーロッパ文化でも使用される | ar |
| Genet | ገነት | f | アフリカ；エチオピア | am |
| Haruto | 陽翔 | m | 東アジア；日本 | ja |
| Haukea | f | オセアニア；ポリネシア；ハワイ語の名前 | haw | |
| Himari | 陽葵 | f | 東アジア；日本 | ja |
| Hina | 陽菜 | f | 東アジア；日本 | ja |
| Hīnano | m | オセアニア；ポリネシア；タヒチ語 | ty | |
| Hua | 李华 | m | 東アジア；中国 | zh-Hans |
| Iakopo | m | オセアニア；サモア | sm | |
| Ilango | இளங்கோ | m | 南アジア；タミル語 | ta |
| Irepani | m | ラテンアメリカ；プレペチャ語 | tsz | |
| Işık | f | 西アジア；ヨーロッパ；トルコ | tr | |
| Işıtan | m | 西アジア；ヨーロッパ；トルコ | tr | |
| Itsuki | 樹 | m | 東アジア；日本 | ja |
| Jarra, Jarrah, Cerrah | جراح | m | 西アジア；アラビア語 | ar, tr |
| Jean-François | m | ヨーロッパ；フランス語 | fr | |
| João | m | ラテンアメリカ；ブラジル | pt-BR | |
| Júlía | f | ヨーロッパ；アイスランド | is | |
| Kai | f, m | オセアニア；オーストラリア；多くの言語に現れ、 一般的な例として適している | aus, sm | |
| Khaliun | f, m | 東アジア；モンゴル | mn | |
| Kylie | f | オセアニア；オーストラリア先住民の名前 | aus | |
| Lani | f | オセアニア；フィリピン | fil | |
| Lei | 李雷 | m | 東アジア；中国 | zh-Hans |
| Livia | f | ヨーロッパ、ラテンアメリカ | es | |
| Lowanna | f | オセアニア；オーストラリア先住民 | aus | |
| Lucas | m | ラテンアメリカ | es | |
| Maevarau | m | オセアニア；サモア | sm | |
| Mahmut | m | 西アジア；ヨーロッパ；トルコ | tr | |
| Martina | f | ラテンアメリカ | es | |
| Mei | 芽依 (ja); 梅
(zh) |
f | 東アジア；中国；日本 | ja, zh |
| Minato | 湊 | m | 東アジア；日本 | ja |
| Mio | 澪 | f | 東アジア；日本 | ja |
| Miriam | מרים | f | 西アジア；ヘブライ語 | he |
| Müge | f | 西アジア；ヨーロッパ；トルコ | tr | |
| Muhammad | محمد | m | 西アジア；アラビア語；多くの異形と言語がある。 | ar |
| Ngatemi | f | オセアニア；インドネシア | id, ms | |
| Onosaʻi | f | オセアニア；サモア | sm | |
| Potira | f | ラテンアメリカ；ブラジル；先住民の名前 | gn | |
| Qiàn | 倩 | f | 東アジア；中国 | zh-Hans |
| Rattiya | รัตติยา | f | 東南アジア；タイ | th |
| Ren | 蓮 | m | 東アジア；日本 | ja |
| Rin | 凛 | f | 東アジア；日本 | ja |
| Ritthichai | ฤทธิชัย | m | 東南アジア；タイ | th |
| Santiago | m | ラテンアメリカ | es | |
| Senthil | செந்தில் | m | 南アジア；タミル語 | ta |
| Sione | m | オセアニア；トンガ | to | |
| Slobodan | Слободан | m | ヨーロッパ；セルビア語 | sr |
| Sofia | f | ヨーロッパ；ラテンアメリカ | es | |
| Tahnee | f | オセアニア；オーストラリア先住民 | aus | |
| Tamizhachi | தமிழச்சி | f | 南アジア；タミル語 | ta |
| Temuera | m | オセアニア；ポリネシア | sm | |
| Thị Anh | f | 東南アジア；ベトナム | vi-VN | |
| Tuulikki | f | ヨーロッパ；フィンランド | fi | |
| Uriel | אוּרִיאֵל | m | 西アジア；ヘブライ語 | he |
| Văn Hoa | m | 東南アジア；ベトナム | vi-VN | |
| Vasa | m | オセアニア；サモア；ヨーロッパ；Vasilije／Василијеの短縮形 | sm, hr, sr | |
| Vassilios | Βασίλειος | m | ヨーロッパ；ギリシャ語 | el |
| Voula | Βούλα | f | ヨーロッパ；ギリシャ語 | el |
| Wafaa | وفاء | f | 西アジア；アラビア語 | ar |
| Wissam | وسام | m | 西アジア；アラビア語 | ar |
| Xiaoxia | 晓霞 | f | 東アジア；中国 | zh-Hans |
| Xóchitl | f | ラテンアメリカ；ナワトル語 | nah | |
| Yevdokia | Евдокия | f | ヨーロッパ；ロシア | ru |
| Yevgeny | Евгений | m | ヨーロッパ；ロシア | ru |
| Zafirah | زفره | f | 西アジア；アラビア語 | ar |
ユーザーが入力した数値を解析する際は、数字の字形変換 （非ASCII数字）を許可してください。
数値を表示用に書式設定する際は、非ASCII数字の使用 （数字の字形変換）を含む、文化に応じた表示を許可してください。
番号付きリストの作成時など、ユーザーへの表示用に項目へ 連続的なラベルを自動的に付ける機能を定義する際は、さまざまな計数／列挙体系または スタイルとともに、ラベルをローカライズして表示できるようにしてください。
この例は、CSS Counter Styles [css-counter-styles-3]、 特に付属する既製のカウンタースタイル [predefined-counter-styles]にあります。
メールアドレスフィールドの検証を定義する際は、 EAI（smtputf8）の名前を許可してください。
ローカライズ [LTLI]により、 ユーザーは自分が選択した言語およびロケールでソフトウェアを使用できます。 プロトコルおよび文書形式の仕様では、エンドユーザーが期待する言語および書式を どのように提供するかを考慮する必要があります。
ローカライズされたメッセージを提供しない場合でも、自然言語のデータ値を正しく表示するには、 言語および基底方向が必要です。これには、APIまたはプロトコル内の、人間が読める エラーメッセージやその他の内部メッセージが含まれます。 [STRING-META]も 参照してください。
特定のAPIまたはプロトコルが定義する、エラーメッセージを含む すべての自然言語の フィールドまたはメッセージは、ユーザーの優先ロケールへローカライズするか、 その言語が利用できない場合は適切なフォールバックまたはデフォルトを提供するべきです。
APIまたはプロトコルの仕様は、ユーザーのロケールを決定する方法 （これは言語ネゴシエーションと呼ばれることがあります）を 定義するべきです。
仕様は、APIまたはプロトコル内のメッセージやエラーについて、 特定のデフォルト言語を定義してもかまいません。
仕様では、考えられるすべてのロケールまたは利用可能なすべてのロケールで メッセージを返すことを要求する必要はありません。エンドユーザーの利用体験を ローカライズできるようにすれば十分です。実装は、サポートする言語またはロケールを 選択できます。
プロトコル、API、および文書形式では、サービスから呼び出し元へ、人間が読める エラーまたは例外メッセージを文字列として渡すためのフィールドを提供することがあります。 一般に、また前述したように、 人間が読めるメッセージまたはコンテンツを伝える自然言語テキストには、 言語および方向のメタデータを関連付ける必要があります。このメタデータがない場合、 テキストの処理または表示が損なわれる可能性があります。
仕様作成者がエラーまたは例外メッセージを提供する目的は、多くの場合、 ソフトウェア開発者へデバッグ情報を伝えることです。仕様作成者は、エラーまたは 例外メッセージはエンドユーザーには表示されない、ソフトウェア開発者はこれらの メッセージがローカライズされていないか、特定の言語（通常は英語）で表示されることを 好む、またはエラーメッセージのローカライズが障害になり得るその他の「実用的な理由」が あると想定することがあります。たとえば、メッセージ自体では問題を十分に説明できないため、 エラーの（通常は不明瞭な）文言を使用してウェブ検索する方が容易であると開発者が感じる という事例があります。その文言を検索すると、開発者が希望する言語で、より役立つ結果が 得られる可能性があります。
エラーメッセージはメッセージであり、機械ではなく人間を対象としています。 多くの場合、エラーメッセージには何が問題だったかについての追加情報がすべて含まれており、 場合によっては、問題の修正方法を呼び出し元へ伝える他の手段がないため、 呼び出し元は実際のエンドユーザーへそのメッセージを表示する必要があります （「クレジットカードの有効期限が切れています」、「値10484977は大きすぎます」 ［しまった、小数点を忘れた］など）。この種のメッセージをローカライズすることは 実際に望ましく、一部のアプリケーションでは必須である場合さえあります。
APIおよびプロトコルは、エラーについて言語に依存しない 識別子を提供するべきです。
たとえば、よく知られた404などのHTTP結果コードは、
ユーザーが受け取ったエラーを伝えたり、翻訳を検索したりするのに役立ちます。
自然言語のエラーメッセージフィールドを提供する場合、 それは任意とするべきであり、言語および方向の メタデータを含めるべきです。
自然言語のエラーメッセージフィールドを提供する場合、 可能であれば、その要求についてネゴシエーションされたユーザーインターフェイスの 言語と一致させるべきです。
これは、このセクションの要件のみをまとめた一覧であり、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様が要件を満たしている場合は、 2 番目のチェックボックスを選択してください。次に「GitHub 用 Markdown を作成」ボタンをクリックし、 結果を GitHub の Issue リストにコピーします。詳細を参照してください。
仕様作成者向けの編集ガイドライン
lang 属性を使用し、
例（特に文書の主要言語ではないもの）のフォントが正しく選択され、レンダリングされるようにしてください。詳細
dir 属性と適切な Unicode 双方向書式制御文字を使用してください（また、
適切に 双方向分離を使用するようにしてください）。詳細translate [HTML] に no
という値を使用し、翻訳時に保持（翻訳しない）すべきテキストを
含む文書の部分を翻訳者に示してください。（次も参照：
[ITS]）詳細執筆上の考慮事項
例の作成
仕様は多様な読者を対象としています。この文書のベストプラクティスの大部分は、仕様が規定するものの 技術的要件に重点を置いています。このセクションでは、執筆に適用するための追加のベストプラクティスを 紹介します。これらは、文化的偏見を避けることで世界中の読者により効果的に対応したり、実装者が 国際化および ローカライゼーションの 要件を理解したりするのに役立ちます。
支援技術によるものも含め、適切なレンダリングを確保するため、文書の主要言語ではない例を囲む部分には、適切な言語タグとともに HTML の lang 属性を
使用してください。（これは、4.11
Unicode 文字の参照にある文字参照テンプレートに lang が含まれている目的の 1 つです。）非言語コンテンツには、言語タグ zxx を使用して、そのコンテンツに 自然
言語が含まれていないことを示してください。
仕様自体のマークアップで dir 属性と適切な Unicode 双方向
書式制御文字を使用して、テキストの例が適切に表示されるようにしてください（また、適切に 双方向分離を
使用するようにしてください）。
translate 属性は、もともと 国際化タグセット
(ITS) バージョン 1.0 [ITS] で定義され、後に
[HTML]
に追加されたもので、データ値などの非言語コンテンツ、
または予約済みキーワードを示します。このようなキーワードは、仕様の 構文コンテンツの一部である場合もあれば、
他の仕様から引用しているコンテンツ（予約済みキーワードなど）である場合もあります。translate="no" を使用すると、翻訳処理中に
テキストを変更しないことを翻訳者（機械翻訳を含む）に示します。
例が世界中の利用者を代表するものとなるようにし、言語、 地域、タイムゾーン、および仕様に適したその他の違いを持つ例を含めてください。
もちろん、第一の責務は、仕様を明確で非常に読みやすいものにすることです。そのため、 データ形式や API などの例を示す際には、概念を明確にするために英語の値を使用することがよくあります。 ただし、余裕がある場合や可読性を損なわない場合は、 非 ASCII、英語以外、かつ特定地域に偏らない値を選択してください（またはそのような例を追加してください）。これにより、 実装者に多様な利用者をサポートする必要があることを認識させつつ、仕様を世界中の利用者により関連性の高いものにできます。
個人名の選択と提示については、前に次の箇所で説明しました：10.3.5 例における個人名の使用
値（フィールド、名前、プロパティなど）が非 ASCII 文字をサポートする場合は、 そのような値が許可され、そのサポートが必須であることを明確にするため、 非 ASCII の例を含めてください。
許可するなら、例で示してください。 フィールド、名前、またはその他の値に非 ASCII データを含められる場合は、 それを示す例を少なくともいくつか含めてください。多くの場合、可読性や編集作業を妨げないように、 主要な例ではなく、2 番目または 3 番目の例にすることができます。非 ASCII 値を示すことで、実装者に国際的な値をサポートする必要があることを認識させます。
適切な場合、仕様は例に 英語以外のデータを 含めるべきです。
仕様は、異なる国や地域の例を含めることによって、多様な地域や 文化を 表現するべきです。米国など、1 つの国に特有で、 国際的な利用者には理解されない可能性がある例は避けてください。
明確さを損なわない場合は、この文書の他の場所に記載された ベストプラクティスに例の中でも従ってください。
たとえば、自然言語コンテンツには、常に言語と方向のメタデータを含めてください。項目が ローカライズ可能なテキストである場合は、その ローカライズ方法を示してください。左から右と右から左の両方のコンテンツについて方向メタデータを示してください。
以下は前回の公開以降の実質的な変更を要約したものですが、内容は発展に伴って 依然として大幅に変動する可能性があります。それを理由にこの文書を使用しないでください。 現時点で含まれている内容は有用であり、不足している点は報告または議論できます。
詳細については、GitHubの コミット履歴を参照してください。
推奨事項に関する過去のレビューを確認する際に協力してくださったAddison Phillipsに 感謝します。
レビューまたはissueを通じて貢献したその他の人々には、次の方々が含まれます。 Steve Atkin、 Andrew Cunningham、 Martin Dürst、 Asmus Freytag、 John Klensin、 Tomer Mahlin、 Chaals McCathieNevile、 Florian Rivoal、 Najib Tounsi。 ロケールに依存しない表現に関する一部の内容は、[DWBP]を 基に改編しました。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: