Copyright © 2014-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、仕様を開発する際の国際化関連の考慮事項のチェックリストを提供します。 ほとんどのチェックリスト項目は、他の文書にある詳細な補足情報を指しています。そのような 情報がまだ存在しない場合は、この文書の中に一時的な置き場所を設けることができます。この文書の 情報は、新しい内容が追加され、既存の内容が経験と議論を踏まえて修正されるにつれて、 定期的に変更されます。
この節では、この文書の公開時点におけるステータスを説明します。 現在のW3C 公開文書の一覧と、この技術報告書の最新版は、 W3C標準およびドラフト 索引で確認できます。
この文書は、国際的な利用のための要件をどのように取り入れるかについて、仕様開発者に 助言を提供します。ここで現在利用できる内容は、すぐに有用であることが期待されますが、 まだ初期ドラフトであり、文書は流動的です。また、レビューや議論で適用された知識が ガイドラインとして具体化されるにつれて、時間とともに拡充されます。
この文書は、国際化 ワーキンググループによって、 ノートトラックを用いた グループノートとして公開されました。
このグループノートは、 国際化ワーキンググループによって承認されていますが、 W3C自身またはその メンバーによって承認されているものではありません。
W3C 特許 ポリシーは、 この文書に対して、いかなるライセンス要件またはコミットメントも課しません。
この文書は、 2023年11月3日版W3Cプロセス文書に準拠します。
仕様の開発者は、自分たちが作成するものが世界中のコミュニティで機能するようにするための助言を必要とします。
国際化（i18n）WG は、仕様をレビューし、議論に参加することでワーキンググループを支援しようとしています。 しかし多くの場合、そのような介入は理想よりも遅い段階で行われたり、i18n WG が関わる各ワーキンググループに対して 同じ情報を繰り返し伝えなければならないことを意味します。
仕様開発者が、必要な箇所で説明、例、根拠を示すベストプラクティスのチェックリストにアクセスできれば、 より良いでしょう。そうすれば開発者は、最も早い段階からこの知識を作業に組み込むことができ、 i18n WG が仕様をレビューする際に必要となる手戻りを減らすことができます。
この文書にはチェックリストの出発点が含まれており、示された推奨事項についての 説明、例、根拠を見つけられる場所を示しています。そうした別の場所がない場合、 その追加情報はこの文書に追加されます。また、アイデアを発展させ、それらを整理するためにも 使用されることがあります。
この文書のガイドラインは、厳格で固定的な要件であることを意図していません。ガイドラインを理解できない、 または同意できない場合に、何を行うべきかを議論するため国際化 WG に連絡してもらえるなら、 この文書はその目的のかなりの部分を達成したことになります。
この文書では、用語 自然言語 は通常、 人間が利用することを意図した文書またはプロトコルの部分を指すために使用されます。用語 ローカライズ可能な テキスト は、形式言語、プロトコル構文などに含まれる自然言語コンテンツを指すために使用され、 構文内容 や ユーザー提供値 とは区別されます。 国際化ワーキンググループが使用するこれらおよびその他の用語の定義については、 [I18N-GLOSSARY] を参照してください。
このページには、仕様の国際化レビューを支援するためのチェックリスト機能が用意されています。 レビューの結果は GitHub issue に投稿してください。
仕様に関連する各節について、次の手順に従ってください。
Internationalization Considerations 節へのすべての追加または変更は、 国際化（i18n）WG によってレビューされなければなりません。
国際化に関する考慮事項の節を作成する場合、それは Internationalization Considerations または Internationalization (i18n) Considerations というタイトルを持たなければなりません。
仕様には、その仕様の国際化に関する考慮事項を説明する特別な節または付録を含めることは要求されていません。 一般に、国際化 WG は、言語、地域、文化的な差異、サポート、または適応に関する情報が、 仕様本文の中で関連する機能の近くに現れることをむしろ望みます。
しかし、このような節の提供を検討できる場合がいくつかあります。次の場合には、 国際化に関する考慮事項の節を含めることを検討してください:
Internationalization Considerations 節を作成することにした場合、通常は付録として作成されます。 ただし、仕様の他の部分または他の付録との相対的な順序や配置は、あなたに任されています。
Internationalization Considerations 節を作成することにした場合、国際化 WG への水平レビュー依頼で それに言及する必要があります。レビュー依頼テンプレートには、これを簡単に行うための チェックボックスが含まれています。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、2 番目のチェックボックスを 選択してください。その後、「GitHub 用 markdown を作成」ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。 詳細を参照してください。
言語の基本
lang および XML の xml:lang
言語属性を使用して、テキスト処理言語を識別してください。詳細lang および
XML の xml:lang 言語属性を使用すべきではありません。
それらがメタデータ（特定のテキスト範囲の言語ではなく、リソースの意図された用途を示すもの）を表す場合は、
別の属性を使用すべきです。詳細言語値の定義
言語の宣言
文字列の言語の識別
zxx（「言語的内容なし」）を各文字列値に関連付けることを
推奨すべきです。詳細und
（「未確定」）を各文字列に関連付けることを推奨すべきです。仕様は、適切な場合には
ヒューリスティックの使用または他のフィールド値からの言語推定を許可してもよいです。
詳細
U+E0000 から
U+E007F）を使用すべきではありません。詳細
@context および組み込みの @language 属性の使用が推奨されます。
詳細
i18n
Namespace 機能を使用すべきです。詳細i18n
Namespace が利用できない、または使用するのが不適切な場合、
仕様は、自然言語値に文字列固有の言語情報を提供するために、[JSON-LD]
のプレーン文字列リテラルを要求すべきです。詳細言語の検出 & 照合
任意の ローカライズ可能なテキストまたは 自然 言語コンテンツに言語を関連付けられるべきです。
テキストは、それが書かれている言語に応じて異なる方法でレンダリングまたは処理されます。たとえば、スクリーンリーダーは 言語が変わったときに通知される必要があり、スペルチェッカーは言語を考慮すべきです。テキストを レンダリングする際には、正しいフォント、ハイフネーション、改行、大文字/小文字の変更、 その他の機能を適用するために、言語に関する知識が必要です。
たとえば、雪、刃、直、令、垔 などの表意文字は、日本語フォントと中国語フォントで使われる場合に わずかですが重要な違いがあり、日本語テキストに中国語フォントを適用しないこと、 またその逆もしないことが、ユーザーに提示される際に重要です。
あるリソースについての言語情報は、主に 2 つの目的を念頭に置いて使用できます。 テキスト処理のため、またはリソースの意図された用途を示す記述としてです。 以下でその違いを説明します。
テキスト処理 言語を指定するとき、あなたは特定のテキスト範囲が実際に書かれている言語を宣言しています。 これにより、音声ブラウザー、スペルチェッカー、スタイル処理器、ハイフネーターなど、テキストを操作する ユーザーエージェントまたはアプリケーションが、対象のテキストに適切な規則を適用できます。 したがって必然的に、単一の言語を特定のテキスト範囲に関連付けることについて 話していることになります。
テキスト処理言語は、リソース全体を処理するための既定の言語として表現するのが普通ですが、 リソース内で言語が変わる箇所を示す必要がある場合もあります。
テキスト範囲のテキスト処理言語を識別するために、HTML はlang 属性を提供し、XML はすべての XML 形式で使用できる
xml:lang を提供します。関連するマークアップ形式では、これらの属性を使い続けることが有用です。
作者がそれらを認識しており、HTML および XML 処理器も同様に認識しているからです。
リソース全体の言語を記述することも有用な場合があります。この種類の 言語宣言は、意図された言語的対象読者 of a resource と呼ばれます。たとえば、そのようなメタデータは検索、適切な 言語版の提供、分類などに使用されることがあります。
この種類の言語宣言は、テキスト処理宣言とは異なります。すなわち、(a) そのような宣言の値は複数の言語サブタグであってよく、(b) 宣言された言語値は、 多言語リソースのどの部分がどの言語であるかを示すものではありません。
メタデータ型の言語宣言（特定のテキスト範囲の言語ではなく、 リソースの意図された用途を示すもの）を複数の言語値に関連付けられるべきです。
リソースの意図された用途を記述する言語は、文書内で使用されているすべての言語を必ずしも含みません。 たとえば、Web 上の多くの文書には異なる言語のコンテンツ断片が埋め込まれていますが、 そのページは明らかに特定の 1 つの言語の話者を対象としています。たとえば、北京に関するドイツ語の シティガイドには中国語の便利なフレーズが含まれることがありますが、それは中国語話者ではなく ドイツ語話者を対象としています。
一方で、文書が同じまたは並行するコンテンツを複数の言語で含む状況も考えられます。 たとえば、Web ページがカナダの読者を迎えるために、左列にフランス語コンテンツを、 右列に同じコンテンツを英語で表示する場合があります。この場合、文書は両方の言語の話者を 等しく対象としているため、対象言語は 2 つあります。別のユースケースとして、 多言語コミュニティを対象とするブログやニュースページがあり、ページ上の一部の記事が ある言語で、別の記事が別の言語で書かれている場合があります。この場合、言語宣言の値として 複数の言語タグを列挙することが理にかなう場合があります。
外部リソースの言語を表す属性は、HTML の lang
および XML の xml:lang 言語属性を使用すべきではありません。
それらがメタデータ（特定のテキスト範囲の言語ではなく、リソースの意図された用途を示すもの）を
表す場合は、別の属性を使用すべきです。
XML 文書スキーマにおける xml:lang – いつ xml:lang を使用し、いつ XML 文書スキーマ（DTD）で
言語値を渡すための独自の要素または属性を定義すべきか?
外部リソースの言語を示すために別の属性を使用すると、その属性は複数の言語を指定できます。 また、指し示されるリソースが単一の言語でない場合にも、よりうまく機能します。
この区別は、HTML における lang 属性と hreflang 属性の
分離に見ることができます。前者は HTML ページ内のテキストの言語を示し、後者はリンク先ページの
期待される言語を示すメタデータです。
これについてのより長い議論は、XML 文書スキーマにおける
xml:lang
を参照してください。この記事は xml:lang について具体的に述べていますが、その概念は他の状況にも適用できます。
BCP 47 は、インターネットおよび Web 標準（ならびに他の多くの場所）で使用される 言語タグ体系です。 これは、IANA レジストリのサブタグを使用して、コンテンツの言語を記述する文字列を形成する方法を 定義します。レジストリ内のサブタグは、主に言語、文字体系、地域、国を識別するための ISO および UN 標準に 基づいており（かつ厳密な互換性を維持しており）、BCP47 は Unicode ロケールの基礎にもなっています。
BCP 47 の主要機能の概要については、HTML および XML における言語タグを参照してください。
RFC 5646 や RFC 4647 などの構成部分ではなく、BCP 47 を参照してください。
BCP 47 へのリンクと名称は、Tags for the Identification of Languages の定義への 変わらない参照を提供するために特別に作成されました。RFC 1766、3066、4646 は以前の （置き換えられた）バージョンです。BCP 47 の現在のバージョンは 2 つの RFC、5646 と 4647 で構成されています。
言語タグに期待する適合レベルを具体的に示してください。BCP 47 は、 「valid」と「well-formed」という 2 つの適合レベルを定義しています。
well-formed な BCP 47 言語タグは、言語タグとして定義された構文に従います。 実装は、各言語タグがハイフンで区切られたサブタグで構成されていること、各サブタグがタグ内の配置に応じて 特定の長さと特定の内容（文字、数字、または特定の組み合わせ）を持つことを確認します。 valid な BCP 47 言語タグは well-formed であるだけでなく、IANA Subtag Registry に 掲載されているサブタグのみが使用されていることも保証します。IANA Subtag Registry は新しいサブタグによって 頻繁に更新されることに注意してください。
仕様は、言語タグが「valid」かどうかを実装に確認させることができますが、 ほとんどの場合は、言語タグが「well-formed」であることのみを要求すべきです。
ほとんどの仕様は、言語メタデータの二次的な利用者です。つまり、文書形式 （HTML lang、XML xml:lang、または文書形式の言語フィールド/属性）ですでに提供されている データを使用しています。
一般に、ほとんどの仕様はリソース（スペルチェッカー、トークナイザー、フォントなど）の選択や、 照合（たとえばどの文字列を表示するかの選択）に関心があり、言語タグの内容そのものには 直接関心がありません。無効ではあるが well-formed なタグは何にも一致せず、通常はフォールバック方式が 適切な動作を提供します。
仕様が本当に実装レベルでの有効性確認を求める場合もあります。そのような場合、タグが valid でないときの結果を 指定しなければなりません（アプリケーションを停止するのか、ユーザーに警告するのか、など）。 また、レジストリはかなり大きく、時間とともに変化するため、各実装はレジストリのバージョンに依存します。 時間の経過による変更は多くの場合小さいものですが、仕様のランダムな（古い）実装が後日 valid になった 言語タグを拒否すると、実際のユーザーは相互運用性の問題に遭遇します。
さらに、BCP 47 には、追加のサブタグ列を定義する拡張機構があります。たとえば、1 つの拡張 [RFC6067]（Unicode Locales、シングルトン -u を使用）は、JavaScript の国際化機能を制御するために 一般的に使用されており、他の用途もあります。これらの追加サブタグの検証は、ほとんどの仕様の範囲外である可能性が高いです。
仕様は、コンテンツおよびコンテンツ作者に「valid」な言語タグを使用することを要求すべきです。
言語タグに関する規範的文言は、コンテンツ要件と実装要件で異なる場合があります。 仕様作者は、自分の仕様に必要な適合要件とテスト、および実装に何を要求するかを 慎重に検討する必要があります。1 つの解決策は、コンテンツ作者には「valid」な言語タグの使用を 規範的に要求し、実装には「well-formed」な言語タグの確認だけを要求することです。
仕様は、ISO 639、ISO 3166、またはその他の標準から抽出したコード一覧を提供するのではなく、 IANA Language Subtag Registry を参照すべきです。
過去には、言語タグに含まれるサブタグを提供するために使用される標準の一部が自由または公に利用できなかったため、 相互運用性を確保するために一覧を提供する仕様もありました。これはもはや必要ありません。 BCP 47 の一部として、IANA は言語サブタグレジストリを維持しており、これは言語タグを構築するために 使用できる valid なサブタグの、公開された機械可読な一覧です。このレジストリは、ISO 639 の各部 （639-1、639-2、639-3 など）、ISO 15924 文字体系コード、ISO 3166 および UN M.49 地域コードなどの 基盤標準に基づいています。このレジストリは、インターネット上にある他の一覧にはない形で、 積極的に維持され、安定化され、包括的です。各サブタグ型は、それらの標準管理者の協力と参加により 親標準と同期されているため、コード一覧を抽出したり自作したり、他所で見つけた一覧を参照したりすると、 保守上の問題や混乱につながる可能性があります。
完全な言語タグの一覧を自作すると、使用できる言語の一覧を不必要に制限することになります。 さらに、ロケールデータは常に拡張されているため、今日のサポートを記述する一覧は将来古くなります。 ユーザーが利用できるタグまたはサブタグを制限することは、普遍的なアクセスを提供するという私たちの目標と 矛盾します。
ここでは、構造化テキストを含む独立したデータ単位について話しています。例としては、 HTML ページ全体、XML 文書、JSON ファイル、WebVTT スクリプト、注釈などが挙げられます。
仕様は、リソース全体の既定のテキスト処理言語を定義する方法を 示すべきです。
リソース全体の言語、または少なくとも既定の言語を 1 か所で識別しておくと、
問題を避けられることがよくあります。たとえば、HTML ファイルでは、これは html 要素に lang 属性を設定することで行われます。
リソース内のコンテンツは、特に上書きされない限り、リソースレベルで宣言された テキスト処理の言語を継承すべきです。
テキスト処理言語と、リソースの期待される用途に関するメタデータを示すために、 別個の宣言が必要かどうかを検討してください。
多くの場合、リソースは 1 つの言語のテキストのみを含み、さらに多くの場合、 テキスト処理用の既定の言語として宣言された言語は、リソース全体に関するメタデータを 記述する言語と同じです。そのような場合、単一の宣言を持つことは理にかなっています。
しかし、単一の宣言が複数の言語を参照している場合、どの 1 つの言語を テキスト処理の既定値として使用すべきかを判断する方法がないと、問題になります。
リソースに言語宣言が 1 つしかなく、その値として複数の言語タグがある場合、 リソースの既定のテキスト処理言語を識別できなければなりません。
ここでいう block および/または chunk という語は、リソース全体の中で コンテンツをまとめ、隣接するコンテンツから分離する構造的構成要素を指すために使用されます。 あるブロックと別のブロックの境界は、テキスト内の段落または節の境界、あるいはファイル内の 個別のデータ項目に相当します。
たとえば、これは XML や HTML におけるブロックまたは段落、JSON におけるオブジェクト宣言、 WebVTT におけるキュー、CSV ファイルにおける行などを指し得ます。これを inline コンテンツと 対比してください。inline コンテンツは、段落、文などの内部の範囲を記述します。
仕様で定義されているどの構造がこれらの要件に関連するかの解釈には、多少の検討が必要になる場合があり、 対象となるデータ形式に依存します。
既定では、コンテンツのブロックは、リソース全体に設定されたあらゆる テキスト処理言語を継承すべきです。
既定のテキスト処理言語情報に関連するガイダンスについては、2.1 言語の基本を参照してください。
言語が変化するコンテンツのブロックについて、言語の変化を示せるべきです。
この節では、段落または文字列の途中にある文字範囲について提供する必要がある情報を指します。
言語が変化するインラインテキストの範囲について、言語を示せるべきです。
言語の切り替わりが、スペルチェック、レンダリング、スタイル付け、音声生成、翻訳、情報検索などの コンテンツ上の操作に影響し得る場合、影響を受けるテキスト範囲を示し、そのコンテンツの言語を 識別することが必要です。
この節の情報は、データ形式における言語および方向メタデータの要件 [STRING-META] で開発中です。 その文書はまだ執筆中であるため、これらのガイドラインはいつでも変更される可能性があります。
Web 上のデータ交換は、可能な限り ロケール中立な標準化された 形式を使用すべきです。しかし、Web 上の一部のデータは必然的に、人間に表示することを意図した 自然言語情報で構成されます。 この 自然言語情報は、適切に表示するために、 言語および方向メタデータの存在に依存し、それによって恩恵を受けます。Unicode のサポートに加えて、 基底方向およびテキスト範囲の 自然言語を含め、指定するための仕組みは、Web のための新しい形式および技術を開発する際の 主要な国際化に関する考慮事項の 1 つです。
国際化ワーキンググループがすべての仕様で確認する、最も基本的なベストプラクティスは次のとおりです:
自然言語テキストを含む任意の文字列フィールドについて、その特定の文字列の言語および 文字列方向を判断できなければなりません。その判断は、文字列レベルまたは文書レベルのメタデータを使用すべきであり、 ヒューリスティックに依存すべきではありません。
文字列形式の言語および方向メタデータに関する作業は進行中です。仕様では、 将来のメタデータ採用の必要性を示す注記を含める必要がある場合があります。以下は プロトタイプです:
フィールド {fieldname} は、
Web 上の文字列: 言語および方向メタデータ [STRING-META]
にあるベストプラクティスに
従うべきです。これには、文字列の言語および方向メタデータの報告に関して将来出現する
いかなる標準も利用することが含まれます。
フィールドベースのメタデータまたは文字列データ型を使用して、個々の ローカライズ可能なテキスト 値の言語および 文字列 方向を示してください。
個々のデータ値は、同じデータファイルまたは文書内に見つかる他の値とは、言語または方向が異なる場合があります。 各 ローカライズ可能なテキストフィールドに 直接関連付けられたメタデータ値を提供すると、メタデータを適切に上書きでき、各データフィールドを 組み立て、抽出し、転送し、またはその他の方法で利用する際の処理をアプリケーションが自動化する助けになります。
仕様は、特定のリソース内のすべての文字列について、既定の言語および既定の 文字列方向を提供する仕組みを 定義してもよいです。ただし、仕様はリソース全体の既定値だけで十分だと仮定してはなりません。 リソース全体の設定が利用できる場合でも、その既定値を上書きするために文字列固有のメタデータを 使用できなければなりません。
多くの文書は単一の言語のデータを含みます。おそらくヘッダーで意図された言語的対象読者を示す手段を 提供することで、文書全体のサイズと複雑さを減らせます。しかし、特定の文字列値を上書きできることは 依然として重要です。いくつかの文字列が文書の言語で利用できない場合や、基底方向が文書全体における他の ローカライズ可能なテキスト値の 既定方向と一致しない場合は常にあり得るからです。
他の情報がない場合、既定の方向および既定の言語は不明であると指定してください。
仕様は、ユーザー提供値を 含む 構文内容と、 ローカライズ可能なテキストを 慎重に区別すべきです。
仕様は、自然言語テキストを含めることができないフィールドについて、言語メタデータの使用を 指定または要求すべきではありません。
Web 上の文書形式はテキストで構成されます。ほとんどの場合、ある文書形式のデータ値は、単なる任意の文字列ではなく、 代表的で意味のあるものとして意図されています。たとえば、データ値が英語のキーワードで構成されるという事実だけでは、 そのデータ値がテキストとして表示するための 自然言語文字列であることにはなりません （つまり、その値は ローカライズ可能なテキストではありません）。 そのようなデータ値は文書の 構文内容の一部です。 それらは言語および方向メタデータを必要としないだけでなく、そのようなメタデータと関連付けられるべきでもありません。
ローカライズ可能なテキストではない
文字列値および文字列フィールドについて、仕様は、そのフィールドが非言語的な性質のものであることを指定し、
言語タグ zxx（「言語的内容なし」）を各文字列値に関連付けることを
推奨すべきです。
ローカライズ可能なテキストを含むことが
分かっているが、基盤となる形式から言語メタデータを得る可能性がない文字列値および文字列フィールドについて、
仕様は、そのコンテンツの言語が不明であることを指定し、言語タグ und
（「未確定」）を各文字列に関連付けることを推奨すべきです。仕様は、適切な場合には、ヒューリスティックの使用または
他のフィールド値からの言語推定を許可してもよいです。
一部の文字列値は、既存のプロトコルまたは形式に依存しているか、それらによって定義されています。 多くの場合、これらの文字列には言語または方向メタデータが関連付けられていないか、提供されていません。 たとえば、多くの HTTP ヘッダーは、場合によっては自然言語テキストを含んでいても、その内容を ローカライズ可能なテキストではないかのように 定義しています。利用する仕様は、この性質の文字列に依存する必要があったり、これらの文字列の 1 つを記述する 形式を定義したりする必要がある場合があります。このような場合、消費者がその仕様のデータ構造または文書形式における 文字列と関連付けるための言語または方向メタデータは存在せず、仕様のデータ構造または文書形式が 生成者として機能するときに提供するメタデータがあっても、 それは基盤となる形式を通じてシリアライズされません。
仕様は、言語識別のために Unicode の「language tag」文字
（コードポイント U+E0000 から U+E007F）を使用すべきではありません。
Unicode の「language tag」文字は、言語タグとしての使用が非推奨であり、文書形式およびワイヤープロトコルにおける 言語メタデータ問題の解決策としては不適切である理由が多数あります。仕様作者には、これらの文字を別の目的に 転用したり、これらに基づいて言語情報を送信する新しい仕組みを構築しようとしたりしないよう注意が促されています。
生成者は、あるコンテンツ項目または データレコードについてローカライズされた値を提供する必要がある場合があります。これは、言語 ネゴシエーションを 生成者と 消費者の間で行うことで実現される場合があります。 その後、ローカライゼーションは 生成者 において、ネゴシエートされた言語を使用して返されるコンテンツを選択することで行われます。
別の場合には、コンテンツ項目のローカライゼーションは、生成者がその項目について複数の言語表現を返し、 消費者が表示する値を選択できるようにすることで 行われます。この後者の処理は 言語索引付け と呼ばれます。言語索引付けの詳細については、 [STRING-META] の ローカライゼーションに関する考慮事項を参照してください。
[JSON-LD] は、この節にあるいくつかのベストプラクティスを 満たすための複数の仕組みを提供します:
BCP 47 は、言語タグの定義（RFC 5646）に加えて、言語タグを 言語範囲に照合することを 主題とする RFC も含んでいます。言語タグの定義について安定した識別子である BCP 47 を参照するのが最も適切であるのと同様に、 そこに含まれる照合方式を参照する場合も BCP 47 を参照するのが最善です。
Unicode の [CLDR] プロジェクトは、 ロケール識別子として使用される場合の 言語タグ照合のための追加のアルゴリズム、規則、処理を定義しています。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、2 番目のチェックボックスを 選択してください。その後、「GitHub 用 markdown を作成」ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。 詳細を参照してください。
基本要件
背景情報
基底方向の値
マークアップにおける方向の扱い
auto に設定することもできなければなりません。これは、コンテンツ自体を
調べることによって基底方向が決定されることを意味します。詳細auto に設定されている場合、コンテンツ段落の方向は
段落ごとに決定されるべきです。詳細
文字列の基底方向の扱い
インラインまたは部分文字列テキストの基底方向の設定
auto に設定することもできなければなりません。これは、
コンテンツ自体を調べることによって基底方向が決定されることを意味します。ここでの典型的なアプローチは、
マークアップの外側にある最初の強い方向性文字に基づいて方向を設定することです。詳細
方向の検出 & 照合（未定）
右から左へ書く文字体系で書かれた、またはそれと混在するテキストについて、方向を確立することは重要です。 これらの文字体系の文字は、入力され発音される順序でメモリに格納されます。これは論理順序と呼ばれます。 Unicode Bidirectional Algorithm（UBA）は、論理順序で格納された文字列を、期待される視覚順序になるように 自動的にレンダリングするための多くの支援を提供します。残念ながら、UBA だけでは双方向テキストを正しく レンダリングするには不十分であり、特定の文字列に適用する既定の方向コンテキストについて追加情報を 提供する必要があります。
基本要件は次のとおりです。
上記の特別な場合として、データ構造および文書形式内の 自然言語文字列値があります:
自然言語テキストを 含む任意の文字列フィールドについて、その特定の文字列の言語および 文字列方向を 判断できなければなりません。その判断は、文字列レベルまたは 文書レベルのメタデータを使用すべきであり、ヒューリスティックに依存すべきではありません。
すべての ローカライズ可能なテキストについて、 インラインの双方向テキストの埋め込み範囲における基底方向の変更を示すことができなければなりません。
右から左へ書く文字体系を日常的に扱う人々にとって、右から左へ書くテキストへの 注釈付けは最小限の労力で済まなければなりません。
アラビア語、ディベヒ語、ヘブライ語、ペルシア語、ウルドゥー語などの話者に対して、 自分が書くすべての段落または小さなデータ項目にマークアップや制御文字を追加することを要求するのは、 管理可能な範囲をはるかに超えています。通常、形式は既定の方向を確立し、例外に対処する必要がある場合にのみ ユーザーの介入を要求すべきです。
この節では、後続の推奨事項を理解しやすくするために、テキスト方向に関連するいくつかの主要な概念を 説明します。
「右から左へ」書く文字体系で書かれたテキスト、または双方向要素を含む左から右のテキストを 正しく表示するには、テキストの各要素が表示される順序を指示するために使用される 基底方向を確立することが重要です。
Unicode Bidirectional Algorithm（UBA）が何を行い、何を行わないのか、またなぜ基底方向がそれほど 重要なのかに詳しくない場合は、Unicode Bidirectional Algorithm の基本を読んでください。
この節では、語 paragraph は、プレーンテキストではハード改行の後に続く
テキストの範囲を示しますが、他の状況では異なるものを意味する場合があります。CSV では「cell」に相当するため、
コンマ区切り項目の 1 行は、実際にはコンマ区切りの paragraph の集合です。HTML では、
多くの場合 p 要素である最下位レベルのブロック要素に相当しますが、
テキストおよび/またはインライン要素だけを含む場合には、div、li などであることもあります。
JSON では、多くの場合、引用符で囲まれた文字列値に相当しますが、文字列値がマークアップを使用する場合は
paragraph はブロック要素に関連付けられ、文字列値が複数行のプレーンテキストである場合は各行が
paragraph になります。
用語 メタデータはここでは、 データに関連付けられた注釈またはプロパティであり得る情報、あるいはそれを許すシナリオでのマークアップ、 または上位レベルのプロトコルなどを意味するために使用されます。
基底方向を設定する方法はいくつか考えられます。
ltr、rtl、または auto が含まれます。
dir=auto を設定した場合に起こることです。）dir
属性がない場合に起こることです。）html タグに
dir 属性を設定したときに起こることです。
別の例として、多数のキューを含む字幕ファイルがあり、すべてアラビア語で書かれている場合、
作者がファイルの冒頭で、すべてのキューテキストの既定値は RTL であると言えるようにするのが
最善でしょう。必要な場合には特定の段落について方向情報を上書きする方法が常にあるべきです。
auto
に設定されている場合にのみ起こります。HTML は
既定の方向を指定しているからです。）
ユーザーによるテキスト入力を取得する場合、入力の基底方向を決定するために、ユーザーがそのデータを
入力していたコンテキストを理解することが通常必要です。たとえば HTML では、これは html
タグから継承された方向、またはユーザーがフォームフィールドの基底方向を
設定するためにキーを押すことによって設定される場合があります。その後、基底方向に関する情報を格納する方法、
またはレンダリング時にそれを文字列に関連付ける方法を見つける必要があります。通常、この状況では、
入力される文字列内部の方向変更はユーザーによって処理され、文字列の一部として取得されます。
単一段落内の埋め込みテキスト範囲は、異なる基底方向を必要とする場合があります。たとえば、
"The title was '!NOITASILANOITANRETNI'."
ここで単一引用符内の範囲がヘブライ語/アラビア語/ディベヒ語などであり、感嘆符を正しく配置するために、 周囲の段落の LTR 基底方向ではなく、 RTL 基底方向を必要とします。
コンテンツ作者がマークアップを利用できる場合、そのようなインライン範囲を示すにはマークアップを使用する方が
容易で安全である可能性が高いです（下記参照）。HTML では、そのようなテキスト範囲の基底方向を確立するために、
通常は dir 属性を持つインライン要素を使用します。
HTML の title 要素や、プレーンテキストコンテンツのみを扱う
任意の環境など、テキストをマークアップできない場合は、そのような内部範囲の基底方向を確立するために
Unicode のペア制御文字に頼る必要があります。
さらに、基底方向が変更されるインライン範囲は、周囲のテキストから bidi 分離されるべきです。 これにより、境界を越えた干渉によって Unicode Bidirectional Algorithm が誤った結果（「波及」）を生成しないようにします。
これは、コンテンツ作者が 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" のように first-strong ヒューリスティックを使用して基底方向を
検出している場合、対象のテキストが本来誤った結果を与えるものから始まる箇所で、検出される
基底方向に影響を与えるために RLM、ALM、または LRM を挿入することが有用な場合があります。
メタデータを使用して基底方向を設定する場合、メタデータが first-strong ヒューリスティックを使用すべきであると 具体的に述べていない限り、強い方向性書式文字は無視されることを覚えておいてください。
最後に、U+061C ARABIC LETTER MARK（ALM）の使用についての注記です。
この文字は、数字の前にアラビア文字が出現しない場合に、アラビア文字体系のテキスト内で数字列の表示に
影響を与えるために使用されます。
基底方向に関する情報を提供するために言語タグを使用できない理由は、次のとおりです:
auto 値を生成できません。Suppress-Script: Hebr）のように通常それを必要としない言語では
script tag の使用を抑制することを推奨しています。ペルシア語のように通常 RTL 文字体系で書かれる言語も、
転写形式で書かれることがあり、方向情報を運ぶために必要な script tag が存在することを保証できません。
要するに、方向に影響を与えるために人々が言語情報の一部として script tag を提供することに
依存することはできません。既定の基底方向の値には、左から右、右から左、および auto を含めるべきです。
auto 値は、テキスト片の基底方向を自動的に検出できるようにします。
たとえば、HTML における dir の auto
値は、テキスト内の最初の強い方向性文字を探しますが、
テキストの基底方向を推測するために、特定のマークアップ項目も無視します。自動検出アルゴリズムは完全には程遠いことに
注意してください。first-strong 検出は、実際には右から左であるにもかかわらず強い LTR 文字で始まるテキストを
正しく識別できません。テキストの内容に基づいて基底方向を判断しようとするアルゴリズムにも問題があります。
最良のシナリオは、基底方向が既知であり宣言されている場合です。
この節は、マークアップを使用してコンテンツを整理するリソースで機能する bidi 処理のアプローチを 定義することについて述べています。推奨事項の一部は、Web 上の文字列の扱いに関するものとは異なります （3.5 文字列の基底方向の扱いを参照）。
仕様は、リソース全体の既定の基底方向をどのように定義するか、 すなわち全体の基底方向を設定する方法を示すべきです。
他の情報がない場合、既定の基底方向は auto であるべきです。
コンテンツ作者は、テキスト内で基底方向が変化する部分を示せなければなりません。 ブロックレベルでは、これは属性またはメタデータを使用して実現されるべきであり、コンテンツ作者が 方向制御のために Unicode 制御文字を使用することを要求すべきではありません。
すべてのブロックの方向を確立するために Unicode 制御文字に依存することは現実的ではありません。 改行がそのような制御文字の効果を終了させるからです。また、必要なすべての箇所に制御文字を 出現させなければならない場合、データははるかに不安定になり、管理が不必要に困難になります。
コンテンツ断片の方向を auto
に設定することもできなければなりません。これは、
コンテンツ自体を調べることによって基底方向が決定されることを意味します。
推定 アルゴリズム、HTML & CSS における Bidi の追加要件内。
ここでの典型的なアプローチは、マークアップの外側にある最初の強い方向性文字に基づいて方向を 設定することですが、これが唯一の方法ではありません。方向が auto に設定されている場合に方向性を 決定するために使用されるアルゴリズムは、受信者が期待するものと一致しているべきです。
first-strong アルゴリズムは、Unicode の定義に従って強い方向性特性を持つ段落内の最初の文字を探します。 そして、その文字の方向に従って段落の基底方向を設定します。
first-strong アルゴリズムは、RTL 段落または行が LTR のブランド名や専門用語で始まる場合など、 最初の文字が段落の残りの部分の典型ではない場合、段落の方向を誤って推測することがある点に 注意してください。
方向検出アルゴリズムに関する追加情報については、HTML を参照してこの問題が議論された文書内の 推定アルゴリズムを 参照してください。
プレーンテキストについて全体の基底方向が auto
に設定されている場合、コンテンツ段落の方向は段落ごとに
決定されるべきです。
含まれる行の始点および終点に対するテキストブロックの辺を示すには、 'top' および 'bottom' ではなく、'block-start' および 'block-end' を使用してください。
行の始点/終点を示すには、'left' および 'right' ではなく、 'start' および 'end'、または 'inline-start' および 'inline-end' を使用すべきです。
基底方向および双方向オーバーライドを制御するための専用属性を提供してください。 bidi 制御を実現するために、ユーザーが任意のマークアップにスタイルプロパティを適用することに 依存しないでください。
bidi サポートにおける CSS とマークアップ、W3C 記事。
たとえば、HTML には CSS スタイルの助けを借りずに基底方向を管理できる dir 属性があります。XML
形式は、必要な表示を実現するために CSS が
必要であっても、方向情報を表す専用のマークアップを定義すべきです。テキストは他の方法でも
使用される可能性があるからです。
CSS などのスタイルシートは、データとともに常に使用されるとは限らず、データが配信される場合などに データとともに運ばれるとも限りません。方向情報はデータの正しい表示にとって根本的に重要であり、 マークアップまたはデータとより密接かつ恒久的に関連付けられるべきです。
この節の情報は、Web 上の文字列: 言語および方向 メタデータから引用されています。その文書はまだ執筆中であるため、これらのガイドラインは いつでも変更される可能性があります。
メタデータが提供されている場合を除き、文字列の消費者は、できれば Unicode Standard の first-strong アルゴリズムに基づくヒューリスティックを使用して、 文字列の基底方向を検出すべきであると指定してください。
ベストプラクティス、推奨事項、および ギャップ、Web 上の文字列: 言語および方向メタデータ内
可能な場合は、特定のリソースまたは文書内のすべての文字列について 既定の方向を示すフィールドを定義してください。
ベストプラクティス、推奨事項、および ギャップ、Web 上の文字列: 言語および方向メタデータ内
任意の文字列について方向を変更する能力なしに文書レベルの既定値を作成すれば 十分である、と仮定してはなりません。
ベストプラクティス、推奨事項、および ギャップ、Web 上の文字列: 言語および方向メタデータ内
レガシー実装によりメタデータが利用できず、他の方法でも提供できない場合、 仕様は、利用可能な言語メタデータから 文字列方向を 補間することを許可してもよいです。
ベストプラクティス、推奨事項、および ギャップ、Web 上の文字列: 言語および方向メタデータ内
ここでの「インラインテキスト」は、マークアップにおいて容易に理解できる意味を持ちます。また、 JSON、CSV、またはその他のプレーンテキスト形式などにおける文字列にも適用され、文字列内の すべての文字を含むわけではない文字の範囲を意味します。
基底方向が変化するインラインテキストの範囲を示すことができなければなりません。 マークアップが利用できる場合は、これが推奨される方法です。それ以外の場合、仕様は、 Unicode 制御文字が受信側アプリケーションで認識され、正しく実装されることを要求しなければなりません。
インラインテキストの範囲について、方向を auto
に設定することもできなければなりません。これは、
コンテンツ自体を調べることによって基底方向が決定されることを意味します。ここでの典型的なアプローチは、
マークアップの外側にある最初の強い方向性文字に基づいて方向を設定することです。
first-strong アルゴリズムは、Unicode の定義に従って強い方向性特性を持つ段落内の最初の文字を探します。 そして、その文字の方向に従って段落の 基底方向を設定します。
first-strong アルゴリズムは、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 双方向制御を使用することによって行うのが最善です。
マークアップでは、基底方向および双方向オーバーライドを制御するための 専用属性を提供してください。bidi 制御を実現するために、ユーザーが任意のマークアップに スタイルプロパティを適用することに依存しないでください。
マークアップでは、テキストを含むすべてのインライン要素で bidi 属性を 許可してください。
マークアップでは、ユーザーが (a) 分離または埋め込みの基底方向を作成する、 または (b) 双方向アルゴリズムを完全に上書きすることを可能にする属性を提供してください。 そのような属性は、これら 2 つのシナリオのいずれでも、ユーザーが方向を LTR、RTL、 または Auto に設定できるようにすべきです。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、2 番目のチェックボックスを 選択してください。その後、「GitHub 用 markdown を作成」ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。 詳細を参照してください。
文字と文字エンコーディングの基本
「string」の定義を選択する
DOMString を
使用してください。（この用途の一覧は網羅的ではありません。）詳細USVString を
使用してください。UTF-8
encode を伴う任意の
処理、またはペアになっていない surrogate code point がエラーを生じる
任意の箇所では、USVString を
使用してください。詳細DOMString と USVString を
混在させることは避けてください。後者はほとんどの文書形式またはプロトコルに利益をもたらさない
追加処理を必要とするため、多くの場合、USVString ではなく
DOMString を選択します。
詳細
DOMString、または
まれに USVString を
指定してください。詳細Uint8Array を
指定してください。詳細
ByteString を
指定してください。詳細
参照処理モデルを定義する
文字範囲の包含と除外
私用領域を使用する
文字エンコーディングを選択する
文字エンコーディングを識別する
文字エスケープを設計する
テキストを格納する
空白文字
character という語は、文脈によって異なることを意味します。あるテキスト単位の 視覚的、論理的、またはバイトレベルの表現を指すことがあります。このため、この用語は仕様で 気軽に使用するには不正確すぎます。したがって、コンピューティングシステムでテキストがどのように 定義され、エンコードされるか、およびそのような仕様を曖昧でなくするために使用される関連用語を理解することは、 文字列データの処理について議論するための必要な前提条件です。
仕様の開発者、およびそれらの仕様に基づくソフトウェアの開発者は、自分たちが経験してきた 「character」という用語の使い方にはより慣れており、国際的な文脈における幅広い使い方には あまり慣れていない可能性があります。さらに、コンピューティングの文脈では、文字は関連する概念と 混同されることが多く、その結果、不完全または不適切な仕様やソフトウェアが生じます。
文字、文字列、または文字や文字列を扱う任意の処理を指定する場合は、 最も具体的で適切な用語を使用してください。そうしない理由がない限り、code point を Unicode Scalar Value を意味するものとして 定義し、「character」よりもその用語を優先して使用してください。
この節にある最も適切な用語を使用してください。その他の推奨用語を以下に示します:
| 単位の種類 | character の代わりに使用するもの... | 説明 |
|---|---|---|
| テキスト単位 | code
point, Unicode code point, Unicode Scalar Value |
character encoding form や特定のシリアライズに関係しない、テキストの論理単位。 |
| 保存、処理、シリアライズ、エンコーディング | code unit | エンコーディングおよびシリアライズの単位。Code units は通常、 ワイヤ形式およびファイル形式、低レベルのテキスト処理で指定されます。使用される character encoding（望ましくは UTF-8 または UTF-16）に依存します。 |
| 視覚単位、ユーザーが知覚する文字、選択/分節化 | grapheme
cluster, typographic character unit |
テキストを視覚単位に分割すること、ほとんどの視覚的選択、および 切り詰め。この推奨事項は最も微妙な差異を含みます。 |
| フォントの要素 | glyph | 個々の表示値。この用語は主にフォントの内容について話す場合に使用してください。 |
「character」という用語の使用を避けられない場合、その用語の明確な定義を 含めなければなりません。
以下は中核的な用語の簡単な用語集です:
[Unicode] [D7] は、abstract
character を次のように定義しています: テキストデータの編成、制御、または表現に使用される
情報の単位。
この定義は必然的に曖昧であり、さらに abstract character は具体的な形を持たない
（したがってフォント内の glyph
と混同しない）こと、
またユーザーが「character」と考えるものではない（したがって grapheme と混同しない）ことを注記しています。
自分の仕様ではこの用語の使用を避けてください。
character set は、テキストをエンコードするために一緒に使用できる abstract characters の順序なしコレクション（言い換えれば、集合）です。character set 内の文字の コレクションは、その repertoire と 呼ばれることがあります。ほとんどの character sets は、特定の範囲の言語または文字体系だけをサポートします。
[Unicode] は、Universal Character Set と呼ばれることもあり、現在コンピューターシステムでテキストをエンコードするために使用されるすべての 文字を含みます。これには、歴史的または消滅した書記体系だけでなく、現代の用法、私用、組版記号、 および emoji などのその他のものも含まれます。他のすべての character sets は Unicode の定義済み部分集合です。 毎年の改訂によって、エンコードされる文字集合が拡張されます。
[Unicode] Standard は、単なる character set 以上のものを定義します。テキストの処理および提示のための多くのプロパティ、 アルゴリズム、およびその他の詳細も定義します。
code point は、abstract character を character set 内で一意に識別するものです。 character set が有用であるためには、各文字を曖昧なく識別する必要があります。ほとんどの character sets では、 code point は、 その集合内の文字の表またはチャートにおける文字の位置を記述する数値（または数値の集合）です。
[Unicode] では、code point は
0x0000 から 0x10FFFF までを含む整数です。これは 16 進表記で書かれます（4.11
Unicode 文字を参照するを参照）。Unicode code point は、
Unicode Scalar
Value と
呼ばれることがあります。Unicode で abstract character に割り当てられた各 code point には、一意で不変の名前も
与えられます。Unicode は、割り当てられた各文字にさまざまなプロパティも関連付けます。これらのプロパティの多くは
Unicode Character Database（または UCD） [UAX44] に
現れ、その他は補助ファイルまたは表で割り当てられます。
[Unicode] [D11] は、encoded
character を abstract character と code point
との関連付け
（または対応付け）
として定義します。仕様では一般に、code point、
または、より具体性が必要な場合には Unicode code point や Unicode Scalar
Value という用語が好まれます。
Code points は、 ソフトウェアにおける文字の保存および交換で直接使用されるわけではありません。代わりに、それらが表す 文字をエンコードおよび処理するため、またはある表現から別の表現へ変換するためのさまざまな方式が存在します。
code unit は、物理的な保存および情報交換の単位であり、コンピューターによる処理、 保存、通信の基礎を形成します。最もよく知られている code unit は byte または octet と呼ばれ、8 ビットで構成されます。
異なるサイズの code units は、異なる実行環境で使用されます。他の一般的なサイズには、16 ビットまたは 32 ビット単位が 含まれます。たとえば Web では、16 ビット code units が [DOM]、JavaScript、 および [INFRA] におけるさまざまな文字列型で使用されます。 これらの仕様は、[Unicode] の UTF-16 character encoding の規則に 従って処理される 16 ビット code units を使用します。
character encoding form（単に character encoding と呼ばれることもあります）は、character set 内の code points から、 テキストの保存および処理に使用される code units へエンコードするための規則、 または code units から code points へ デコードするための規則の集合です。Unicode 以外の character encoding forms は、まとめて legacy character encodings と呼ばれます。
UTF-8 は、[Unicode] のマルチバイト character encoding form です。 これは Web で使用される最も一般的な character encoding です。 UTF-8 は、その code unit として 8 ビットの byte を 使用します。UTF-8 は可変幅エンコーディングであり、エンコードされる code point に 応じて異なる数の code units を使用します。
おなじみの 7 ビット ASCII 文字（U+0000 から U+007F までの code points）は、
UTF-8 では 1 byte でエンコードされます。
| 文字 | Code Point | UTF-8 Code Units（bytes） |
|---|---|---|
| A | U+0041 |
0x41 |
U+0080 から U+07FF までの code points には 2 bytes が必要です。
| À | U+00C0 |
0xC3 0x80 |
U+0800 から U+FFFF までの code points は 3 bytes を使用します。
| न | U+0928 |
0xE0 0xA4 0xA8 |
そして最後に、U+10000 から U+10FFFF までの code points は 4 bytes を使用します。
| 👪 | U+1F46A |
0xF0 0x9F 0x91 0xAA |
仕様、ソフトウェア、およびコンテンツは、文字（code points）と物理的な 記憶単位（code units）との 1 対 1 の関係を 要求または依存してはなりません。
記憶単位 C009、 World Wide Web 1.0 の文字モデル: 基礎内
仕様、ソフトウェア、およびコンテンツは、code points と提示単位 （grapheme clusters、glyphs、または typographic character units など）との 1 対 1 の対応を要求または依存してはなりません。
視覚的レンダリング単位 C002、World Wide Web 1.0 の文字モデル: 基礎内。
文字、キーストローク、および Glyphs の例、World Wide Web 1.0 の文字モデル: 基礎内。
この文書では、visual text unit は、ユーザーが知覚する 可視テキストの単一単位を指します。これは画面上である場合も、紙に印刷されたものやナプキンの裏に書かれたものなど、 他の媒体上である場合もあります。この用語は必然的に不正確です。ユーザーの知覚はしばしば文字体系および 書記体系への慣れに依存するためであり、特に結合記号、複雑な配置、または文脈に基づく複雑な字形形成の 組み合わせを使用する書記体系ではそうです。自分の仕様ではこの用語の使用を避けてください。
grapheme cluster は、エンコードされたテキスト内における visual text unit の計算上の近似です。 すなわち、ユーザーの観点から単一の visual text unit を形成すると期待される code points の列です。[Unicode] は、テキスト処理を支援するためにこれらの境界を計算する方法を 提供しています。多くのテキスト操作では、そのような列は単一で不可分なテキスト単位として処理されるべきだからです。 たとえば、テキスト内でカーソルを移動する場合、カーソルは visual text unit 全体（およびその基礎となる code points）を 一緒に「飛び越える」または選択すべきです。visual text unit の「中間」へカーソル移動できるべきではありません。 （別途指定がない限り、この文書における grapheme cluster という用語は、Unicode Text Segmentation [UAX29] が "extended default grapheme cluster" と呼ぶものを指します。）
一部のテキスト操作では、ユーザーが grapheme cluster 内の個々の code points と やり取りすることを許可する点に注意してください。たとえば、バックスペースなどの一部の編集機能は、 （たとえばクラスター全体を消去しなくてもユーザーがスペルミスを修正できるようにするため） visual text unit の末尾から文字を段階的に削除します。
用語 typographic character unit は [CSS] によって定義されており、そこでは特定の操作について 「単一単位」として扱われるべきさまざまな種類の code point 列を指すために使用されます。これは grapheme cluster という用語と一致する場合もあれば、区別される場合もあります。この用語は、その文脈と 用法を理解している場合にのみ使用してください。
glyph
は、特定の
font によってレンダリングされるときの、文字（または文字列）の
視覚的表現です。Glyphs は abstract characters と常に 1:1 の関係を持つわけではありません。
文字の一部または複数の文字の組み合わせを表すことがあります。異なる glyphs が同じ code point を
表すこともあります。たとえば、これらはすべて AU+0041 LATIN CAPITAL LETTER A に対する異なる
glyphs です:
font は、したがって、テキストをレンダリングするために使用される特定の glyphs のコレクションです。
仕様、ソフトウェア、およびコンテンツは、文字と言語の音との 1 対 1 の対応を 要求または依存してはなりません。
聴覚レンダリング単位 C001、 World Wide Web 1.0 の文字モデル: 基礎内
一部の文字体系では、文字は音素（phoneme は、特定の話し言葉の文脈において最小限に区別される音です）と 密接な関係を持ちますが、他のものでは意味と密接に関連しています。文字が（大まかに） 音素に対応する場合であっても、この関係は単純ではない場合があり、文字と音素の間に 1 対 1 の対応が 存在することはまれです。
次は、character という用語と音の単位との不一致の例です:
仕様およびソフトウェアは、1 回のキーストロークが 1 つの文字になること、 1 つの文字が（修飾キーを含めても）1 回のキーストロークで入力されること、またはキーボードが 世界中で同じであることを要求または依存してはなりません。
入力単位 C005、 World Wide Web 1.0 の文字モデル: 基礎内。
文字、キーストローク、および Glyphs の例、World Wide Web 1.0 の文字モデル: 基礎内。
キーボード入力では、キーストロークと入力文字が常に 1 対 1 に対応するわけではありません。 キーボードに載せられるキーの数には限りがあります。一部のキーボードは、1 回のキー押下から複数の code points を 生成します。他の場合（「dead keys」）では、キーは文字を生成しませんが、 後続のキー押下の結果に影響します。多くの書記体系はキーボードに収めるには文字数が多すぎるため、 キーストローク列を文字列へ変換する、より複雑な入力メソッドに依存する必要があります。 他の言語では、特別な修飾キーを使って一部の文字を入力する必要がある場合があります。
自明でない入力の例については、文字、 キーストローク、および Glyphs の例を参照してください。
string は通常、「characters」の列であると理解されます。[Unicode] は、 legacy character encodings を使用するテキストを含め、テキストを理解し扱うための基盤であるため、 string の基本的な定義は Unicode と、その encoded character の概念に依存します。具体的には:
string は、0 個以上の Unicode Scalar Values の well-formed な列です。
文字列を扱う方法は複数あるため、さまざまな仕様のニーズを支えるために、"string" の異なる定義が 発展してきました。自分の仕様のニーズを必ず理解し、最も適切で正確な定義を使用してください。
Web には、3 種類の string があります:
USVString。
Unicode code
points に基づく string。Unicode Scalar Values とも
呼ばれますDOMString。
UTF-16 code units に基づく string
ByteString。
何らかの character encoding form
（望ましくは UTF-8）における
bytes に基づく stringこれらの異なる string 型の違いの 1 つは、surrogate code points がどのように扱われるかです。 code point（Unicode Scalar Value、すなわち文字を表すもの）と、code unit（character encoding form におけるエンコーディング単位）との違いに注意してください。
UTF-16 character encoding form は、
16 ビットの code units
を使用します。scalar
values が 16 ビットを
超える文字は、surrogate code units
のペアを使用して
エンコードされます。すなわち、"low surrogate"（範囲 U+D800-U+DBFF）に
続いて "high surrogate"（範囲 U+DC00-U+DFFF）です。Unicode は、これらの範囲の code points を
non-characters として
予約しており、code units
in UTF-16 と通常のテキストとの間に混乱が
生じないようにしています。
USVString では、孤立した surrogate code points は
無効であり、実装は文字列中で見つかったものをすべて Unicode replacement character
（�U+FFFD REPLACEMENT CHARACTER）に置き換えることを要求されます。
最も一般的なアルゴリズムが scalar values に対して動作する文字列（percent-encoding など）、
または入力内の surrogates を扱えない操作（文字列をネイティブプラットフォーム API へ渡す API など）には、
USVString を使用すべきです。
これらの参照はいずれも、次と等価です:
DOMString では、ペアになっていない
surrogate code units が
文字列内に現れることがあります。ほとんどの文字列操作では、文字列内部の code units を解釈する必要はありません。
DOMString を指定することは、
実装が文字列の内容を検証する必要がないことを意味し、これをほとんどのデータ構造、形式、または API にとって
理想的な string 型にします。[DOM] および JavaScript の文字列は、
その string 型として DOMString を使用し、
[INFRA] standard は、用語 'string' を DOMString
を意味するものとして定義します:
string は、符号なし 16 ビット整数の列であり、code units とも 呼ばれます。
[INFRA] における用語 code unit の使用は、 あらゆる character encoding form における bytes などの異なるサイズ値を指し得る、より一般的な code unit の定義ではなく、 特に UTF-16 character encoding の code units を指します。
ByteString は、
文字を bytes にエンコードするために使用される character
encoding form に依存します。Legacy character
encodings には "surrogates" の概念がないため、通常 surrogate code point をエンコードする方法はありません。
有効な UTF-8 は surrogate code
points を許可しません。
これらは、テキストを UTF-8 へ
エンコードする、または UTF-8 からデコードするときに �U+FFFD REPLACEMENT CHARACTER に置き換えられます。
UTF-16 を UTF-8 に変換する場合、任意の surrogate pairs は、
特定の scalar
value をエンコードする
適切な UTF-8 byte sequence に変換されます。
文書形式またはプロトコルのワイヤ形式を定義する場合、または [DOM] に
関係する任意の処理、あるいは文字列を不透明な値として定義し、その個々の文字内容を評価することを意図していない
任意の処理では、DOMString を使用してください。
（この用途の一覧は網羅的ではありません。）
Web Platform Design Principles [DESIGN-PRINCIPLES] における IDL String Types
Character Model for the World Wide Web: Fundamentals における String concepts, C012。
文字列内の code points を反復するアルゴリズムを
定義する場合は、USVString を使用してください。
UTF-8
encode を伴う任意の処理、またはペアになっていない surrogate code point がエラーを生じる
任意の箇所では、USVString を使用してください。
[INFRA] における Scalar value string の定義
1 つの文書またはプロトコル操作の中で、DOMString と USVString を混在させることは
避けてください。後者はほとんどの文書形式またはプロトコルに利益をもたらさない追加処理を必要とするため、
多くの場合、USVString ではなく、
DOMString を選択します。
4.6 文字エンコーディングを選択する。character encodings に 関連する追加のベストプラクティスがあります。
Strings on the Web: Language and Direction Metadata [STRING-META] における レガシープロトコルまたは形式の一部である string
Unicode が広く採用される以前は、string を byte
string として定義するのが一般的でした。このような string は、
文字や code
points の列ではなく、
単なる byte 値の列です。byte strings のよく知られた表れは、C プログラミング言語における
char* です。
byte string の処理または解釈は、character encoding form に 依存します。多くの legacy character encodings は stateful です。そのようなエンコーディングを処理するには、多くの場合 byte buffer の先頭から 開始する必要があります。これにより文字状態が保持され、abstract character を正しくデコード、処理、または変更できます。 そのようなエンコーディングにおける特定の byte 値は、隣接する bytes に応じて異なる意味を持つ場合があります。 たとえば、まったく同じ byte 値が単独で文字を表すこともあれば、先行する bytes に応じて別の文字を表す multibyte sequence の一部であることもあります。各 byte または byte sequence をどのように解釈するかを 決定する規則は、異なる legacy character encodings ごとに異なります。誤った character encoding を 使用して byte string を処理すると、壊れた文字（mojibake と呼ばれることがある効果）が 生じます。
UTF-8 は、Web [ENCODING] または一般に Internet [RFC3629] 上の ワイヤ形式および文書形式に推奨される character encoding です。 コンテンツが UTF-8 でエンコードされている場合、それを byte sequence として扱う理由はほとんどありません。 ほとんどの Web API およびインターフェイスは、特定の byte 値ではなく、対象となる文字を表す code point sequence により関心を 持ちます。
仕様が byte 値の保存、解釈、および操作を扱う必要がある場合もあります。特に、多くの文書形式や
プロトコルは、7-bit [ASCII]
bytes の使用を中心に定義され、さまざまな文字またはデータエンコーディング方式を使用することで
non-ASCII data values の包含または交換を許可していました。これは、text media types の
charset パラメーターのように、character encoding form を
指定することで行われる場合があります。あるいは、percent
encoding のような特殊な構文を使用して byte 値をエンコードすることで行われる場合もあります。
推奨かつ既定の character encoding form としての UTF-8 の普及により、ほとんどの仕様が基盤となる byte 値にアクセスしたり操作したりする必要性は低下しています。 UTF-8 は、7-bit ASCII テキストも有効な UTF-8 になるように設計されており、これは ASCII に基づく形式を エンコードまたはデコードする際に重要になり得ます。
特定の byte 値とやり取りする理由がある場合、または UTF-8 character encoding を
想定できない場合を除き、bytes を使用して定義されるプロトコルまたは文書形式のフィールドには、
DOMString、または、まれに
USVString を指定してください。
対象のフィールドを string として扱うことを意図している場合、byte 値を直接扱おうとするよりも、 Unicode 文字を扱う方が信頼性が高くなります。これらのフィールドにエンコードされたデータは、 ワイヤ形式から、[DOM]、JavaScript strings、またはプラットフォームのネイティブ Unicode string 型など、ローカルのメモリ内 string 表現へデシリアライズされます。その後、それは何らかの character encoding form （通常、そして望ましくは UTF-8）を使用してワイヤ形式へシリアライズされる必要があります。
テキストを含まないデータ、または処理が決して必要とされないテキストを表す
byte sequence（バッファをコピーする場合など）といった byte sequences を扱う場合は、
Uint8Array を指定してください。
仕様が、bytes を使用してエンコードされた string を扱う必要があり、Unicode への変換または
Unicode からの変換が不適切であるまれな場合には、ByteString を指定してください。
Web Platform Design Principles [DESIGN-PRINCIPLES] における IDL String Types
ByteString は
汎用の string 型ではありません。[WebIDL] における
データ構造を定義するために使用しないでください。
プロトコルまたは形式仕様によって定義されるテキストデータオブジェクトは、 単一の文字エンコーディングでなければなりません。
参照処理モデル C013、 World Wide Web の文字モデル: 基礎内
テキスト処理を伴うすべての仕様は、この一覧の残りの推奨事項で説明される 参照処理モデルに従ってテキスト処理を指定しなければなりません。
参照処理モデル C014、 World Wide Web の文字モデル: 基礎内
仕様は、テキストを bytes や glyphs ではなく Unicode 文字の観点で 定義しなければなりません。
参照処理モデル C014、 World Wide Web の文字モデル: 基礎内
仕様は、そのテキストデータオブジェクトについて、Unicode エンコーディング形式へ トランスコード可能な任意の文字エンコーディングの使用を許可してもよいです。
参照処理モデル C014、 World Wide Web の文字モデル: 基礎内
仕様は、一部の文字エンコーディングを禁止または非推奨にし、他のものを 必須にすることを選択してもよいです。実際の文字エンコーディングに かかわらず、指定される動作は、処理が次のように行われた場合と同じでなければなりません: (a) 仕様を実装するアプリケーションが受け取る 任意のテキストデータオブジェクトの文字エンコーディングは決定されなければならず、 そのデータオブジェクトは Unicode 文字の列として解釈されなければなりません - これは、そのデータオブジェクトを何らかの Unicode エンコーディング形式へトランスコードし、必要に応じて文字エンコーディングラベルを調整し、 その Unicode エンコーディング形式で受け取ることと等価でなければなりません、(b) すべての処理は、この Unicode 文字の列に対して 行われなければなりません、(c) アプリケーションがテキストを出力する場合、 Unicode 文字の列は、仕様で許可されたものの中から選ばれた文字エンコーディングを使用して エンコードされなければなりません。
参照処理モデル C014、 World Wide Web の文字モデル: 基礎内
仕様が複数のテキストデータオブジェクトを伴うもの（外部解析対象実体を 参照する XML 文書など）である場合、仕様はそれらのデータオブジェクトが異なる文字エンコーディングで あることを許可してもよいです。すべての場合において、 参照処理モデルはすべてのテキストデータオブジェクトに適用されなければなりません。
参照処理モデル C014、 World Wide Web の文字モデル: 基礎内
仕様は、U+0000 から U+10FFFF までを含む Unicode code points の完全な範囲から、 code points を恣意的に除外すべきではありません。
参照処理モデル C070、 World Wide Web の文字モデル: 基礎内。
仕様は、Unicode によって内部使用のために予約された codepoints の使用を 許可すべきではありません。
参照処理モデル C079、 World Wide Web の文字モデル: 基礎内。
仕様は、ペアになっていない surrogate code points の使用を許可してはなりません。
参照処理モデル C078、 World Wide Web の文字モデル: 基礎内。
ここでいう "surrogate code point" は、U+D800 から U+DFFF までを
含む範囲の文字値の使用を指します。これらの code points は、UTF-16 文字エンコーディングが
supplementary
characters を扱えるようにするために予約されています。Surrogates は常にペアで使用され、
UTF-16 エンコーディングが使用されている場合にのみ現れます。単一の surrogate code point は
"unpaired surrogate" と呼ばれ、決して使用すべきではありません。
仕様は、自身が定義する形式の構文要素（マークアップ、区切り記号、 識別子）において互換文字を除外すべきです。
互換文字および書式文字 C050、World Wide Web の文字モデル: 基礎内。
仕様は、私用 code points の合意を定義するための仕組みの使用を 要求してはなりません。
私用 code points、C039、 World Wide Web の文字モデル: 基礎内
仕様および実装は、私的合意による私用 code points の使用を禁止すべきではありません。
私用 code points、C040、 World Wide Web の文字モデル: 基礎内
仕様は、Unicode に含まれない記号の送信、または Unicode 文字の特定の異体を 識別するためのマークアップを定義してもよいです。
私用 code points、C041、 World Wide Web の文字モデル: 基礎内
仕様は、適切な場合、絵や図形のために文字指向の仕組みを（誤って）使用する 必要をなくすため、画像およびグラフィックの包含または参照を許可すべきです。
私用 code points、C068、 World Wide Web の文字モデル: 基礎内
歴史的には（特に Unicode が作られる前の時代には）、多くの coded character sets が一般的に使用されており、文字をコンピューターシステムのメモリまたはストレージに エンコードおよびシリアライズするための方式もさまざまでした。ISO/IEC 8859 によって指定されたような 標準ベースの方式に加えて、多くの独自のベンダー固有またはプラットフォーム固有の character sets も存在し、多くの場合、それに関連付けられた character encoding forms が ありました。この文書でレガシー（非 Unicode）coded character sets の character encoding form に 言及する場合、[Encoding] で指定される、bytes から Unicode code points への 特定の現代的な対応付けを意味します。
すべての文書形式、プロトコル、およびシリアライズ形式に UTF-8 を使用してください。
UTF-8 はほぼすべてのアプリケーションにとって最良の選択です。
すべての新しい形式またはプロトコルについて、または仕様が安全にそうできる場合には、 仕様は UTF-8 を唯一許可される character encoding form として定義しなければなりません。
新しいプロトコルおよび形式、ならびに新しい文脈に展開される既存の形式は、UTF-8 文字エンコーディングを 使用することが要求されます。この方針は IETF および Web 標準に適用され、[RFC2277]、[RFC3629]、[Encoding]、[design-principles]、その他多数に明示されています。 legacy character encodings を必要とする仕様は、古いプロトコルまたは形式を扱うものだけであり、その場合でも UTF-8 が強く推奨されます。
歴史的理由により、仕様が legacy character encodings を許可する場合、その仕様は、character encodings の集合を Encoding Standard の "Names and Labels" 節に列挙されているものに制限しなければなりません。 私的合意による場合を除き、他のエンコーディングは使用すべきではありません。
文字エンコーディングの識別、 C021、World Wide Web の文字モデル: 基礎内
文字エンコーディングの識別、 C022、World Wide Web の文字モデル: 基礎内
文字エンコーディングの識別、 C023、World Wide Web の文字モデル: 基礎内
複数の character encoding forms を許可する仕様は、フィールドまたはパラメーターなど、テキストのエンコーディングを明確に 識別する仕組みを提供しなければなりません。
文字エンコーディングの選択と識別、 C015、World Wide Web の文字モデル: 基礎内
Character encodings は、byte 値だけから確実に検出することはできません。UTF-8 以外のエンコーディングが 許可される場合、consumer がエンコーディングを判断するための 何らかの仕組みが必要です。
プロトコル、形式、または API が、character encoding の 選択、適用、またはラベル付けに関する規則をすでに持つ形式に基づいている場合、仕様は character encoding を 識別するための別個の仕組みを定義してはなりません。
文字エンコーディングの選択と識別、 C017、World Wide Web の文字モデル: 基礎内
仕様が UTF-8 以外の character encodings を 許可する形式に基づいている場合、その仕様は character encoding を UTF-8 に制限すべきです。
文書形式またはプロトコルは、legacy character encodings をサポートする場合があります。それらの形式の上に構築される仕様は、実行可能であれば、 適合実装が UTF-8 のみを使用するように指定できます。
仕様は、データのエンコーディングを判断するためにヒューリスティックの使用を 提案してはなりません。
文字エンコーディングの識別、 C028、World Wide Web の文字モデル: 基礎内
仕様は、character encoding に 関する情報が複数ある場合または競合する場合のために、競合解決の仕組み（優先順位など）を 定義しなければなりません。
文字エンコーディングの識別、 C028、World Wide Web の文字モデル: 基礎内
一般に、入力または編集が難しい列をプレーンテキストエディターで導入できるように、 文字エスケープを提供することが推奨されます。エスケープ列は、ゼロ幅スペース、ソフトハイフン、 さまざまな bidi 制御、モンゴル語母音分離記号など、不可視または曖昧な Unicode 文字に特に有用です。
マークアップにおけるエスケープの使用に関する助言については、主に他の形式にも一般化可能な マークアップおよび CSS における 文字エスケープの使用を参照してください。
Web または一般的なプログラミング言語に見られる一般的なエスケープ機構の例をいくつか示します。
ここでの例の文字は 😽U+1F63D KISSING CAT FACE WITH CLOSED EYES です。
| 見られる場所 | 種類 | 例 | 説明 |
|---|---|---|---|
| HTML, XML | 16 進 NCRs | 😽 |
Unicode code point の 16 進エンコーディング |
| 10 進 NCRs | 😽 |
Unicode code point の 10 進エンコーディング | |
| JavaScript, Ruby, Rust, [UTS18] | \u 区切り |
\u{1F63D} |
Unicode code point の 16 進エンコーディング |
| Perl | \x 区切り |
\x{1F63D} |
Unicode code point の 16 進エンコーディング。より一般的な u ではなく
x を使用します
|
| Java, JavaScript, JSON, C, C++, Python | \u UTF-16 code units |
\uD83D\uDE3D |
UTF-16 code units の固定幅 16 進エンコーディング。supplementary characters は surrogate pair としてエンコードされます |
| C, C++, Python | \U UTF-32 code units |
\U0001f63d |
UTF-32 code units の固定幅 16 進エンコーディング。多くの場合、\u
エスケープ（より一般的な BMP
文字にはより効率的）と一緒に使用されます。たとえば、 \u00c0 \U0001f63d \u12fe
|
| URLs | URL Encode | %F0%9F%98%BD |
UTF-8 bytes の 16 進エンコーディング。各 byte には 3 文字が必要です。各 code point には 1 から 4 bytes が必要です |
エスケープ機構を選択する場合、Unicode Standard およびその参照で 16 進数が一般的に使用されているため、 一般に 10 進エンコーディングよりも 16 進エンコーディングが好まれることに注意してください。
エスケープ構文は、明示的な終端区切り記号または各文字エスケープ内の 固定文字数を要求すべきです。文字エスケープ自体で許容される文字集合の 外にある任意の文字によって終端が決定されるエスケープ構文は避けるべきです。
文字エスケープ、C044、 World Wide Web の文字モデル: 基礎内
仕様が、数値を使用して文字を表現できる文字エスケープを定義する場合は常に、 その数値は文字の Unicode code point を表さなければならず、 16 進表記であるべきです。
文字エスケープ、C045、 World Wide Web の文字モデル: 基礎内
エスケープされた文字は、エスケープされていない形式が受け入れられる場所なら どこでも受け入れられるべきです。これは、構文上意味を持つ文字が エスケープされた場合に構文内での意味を失うことを妨げるものではありません。特に、ある文字が 識別子およびコメントで受け入れられる場合、そのエスケープ形式も受け入れられるべきです。
文字エスケープ、C046、 World Wide Web の文字モデル: 基礎内
プロトコル、データ形式、および API は、テキストデータを論理順序で 格納、交換、または処理しなければなりません。
視覚レンダリングと論理順序、 C003、World Wide Web の文字モデル: 基礎内。
実装が論理選択または視覚選択のどちらを使用するかにかかわらず、 選択された文字は記憶領域内で論理順序に保たれなければなりません。
視覚レンダリングと論理順序、 C075、World Wide Web の文字モデル: 基礎内。
範囲の選択を伴うプロトコルおよび API の仕様は、少なくとも、それらの プロトコルおよび API の上で画面上の視覚選択の実装をサポートするために必要な範囲で、 不連続な論理選択を提供すべきです。
視覚レンダリングと論理順序、 C004、World Wide Web の文字モデル: 基礎内。
空白文字は、組版において水平方向または垂直方向の空間を表す文字です。 空白文字は異なる視覚効果を持つことがあります。視覚的効果を持たない空白文字もあれば、 ページ上でより大きい、より小さい、または可変量の空間を表すものもあります。
"whitespace" という用語を使用する仕様は、その用語が何を意味するかを 明示的に定義すべきです。
ほとんどの仕様は、whitespace を Unicode の White_Space プロパティを持つ文字を 意味するものとして定義すべきです。
ASCII に制限された vocabularies または whitespace で区切られる形式（例には HTML や CSS が含まれます）で使用する whitespace を 定義する仕様は、文法の一部として ASCII whitespace を指定すべきです。
仕様が ASCII または Unicode whitespace と異なる形で "whitespace" を定義する場合、 具体的な code points を列挙しなければなりません。
ECMAScript などの一部の仕様は、 それぞれ固有の要件を満たすために、上記とは異なる独自の whitespace の定義を提供しています。
次の表は、さまざまな仕様における空白文字の定義です。
white_space プロパティ |
pattern_white_space プロパティ |
ASCII whitespace (HTML) | CSS whitespace | 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 Shading Language は
pattern_white_space プロパティを使用しています。
仕様内で Unicode code points を表すには U+XXXX 構文を
使用してください。
U+XXXX 形式は、仕様内で Unicode code points を参照する場合によく理解されています。
これらが列として現れる場合は、空白で区切られます。追加の装飾は必要ありません。code point は
4 桁、5 桁、または 6 桁の 16 進数字を含む場合があることに注意してください。4 桁未満で済む場合、
code point 番号はゼロ埋めされます。
特定の code points を記述するには Unicode 文字名を使用してください。
Unicode は、割り当てられた各 Unicode code point に一意で不変の名前を割り当てます。
特定の文字を参照する場合に、仕様内でこれらの名前を（U+XXXX 表記の code point
とともに）使用すると、仕様を曖昧でなくするのに役立ちます。
文字命名テンプレートの使用が推奨されます。
ほとんどの文字について、テンプレートは次のようになります:
<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>
短い文字列は、文字名を + で区切って列挙すべきです。
文字名や追加のマークアップを含めることが過度に細かく、使いやすさを損なう場合もありますが、
意味を損なうほどくだけた表記にならないよう注意してください。特に長い列では、code points だけを
列挙することがありますが、明確さのため、可能な場合は文字名を保持すべきです。この文書内の
合成された "family" emoji の議論に例があります: 👨👩👧👧U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467
一般に仕様は、自身の文字の定義と、それらの文字に関連付けられる意味論の両方を 必要とするため、仕様は ISO/IEC 10646 への参照を含めるかどうかにかかわらず、Unicode Standard への 参照を含めるべきです。
Unicode Standard および ISO/IEC 10646 の参照、C062、World Wide Web の文字モデル: 基礎内。
仕様が公開された後に割り当てられた文字をその仕様で使用できるようにしたい場合は、 Unicode Standard への汎用参照を行わなければなりません。 特定の版に依存する機能が利用可能であり、時間の経過とともに変化しないことを確保するために、 Unicode Standard への特定参照を含めてもよいです。
Unicode Standard および ISO/IEC 10646 の参照、C063、World Wide Web の文字モデル: 基礎内。
Unicode Standard へのすべての汎用参照は、それを含む仕様の公開日に利用可能な Unicode Standard の最新版を参照しなければなりません。
Unicode Standard および ISO/IEC 10646 の参照、C064、World Wide Web の文字モデル: 基礎内。
ISO/IEC 10646 へのすべての汎用参照は、それを含む仕様の公開日に利用可能な ISO/IEC 10646 の最新版を参照しなければなりません。
Unicode Standard および ISO/IEC 10646 の参照、C065、World Wide Web の文字モデル: 基礎内。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連するすべての要件について、 各行の最初のチェックボックスを選択してください。仕様がその要件を満たしている場合は、2 番目のチェックボックスを 選択してください。その後、「GitHub 用 markdown を作成」ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。 詳細を参照してください。
分節化、索引付けなどのためのテキスト単位を選択する
識別子および構文内容について string identity を照合する
Unicode Normalization を扱う
Case folding
文字列を切り詰める、または長さを制限する
文字列の連結
ファイル名およびパス名を扱う
ソートおよび検索機能を指定する
ソフトウェア処理が substring にアクセスしたり string 内を指したりする必要があり、それを indices、 すなわち string 内の数値的な「位置」を使用して行う状況は多くあります。そのような indices が Web の構成要素間で交換される場合、一貫した動作を確保するために、string indexing の合意された定義が 必要になります。生じる主な 2 つの問いは、「数える単位は何か?」および「0 から数え始めるのか、 1 から数え始めるのか?」です。
character string は、 string indexing の基礎として推奨されます。
Character Model for the World Wide Web: Fundamentals、String indexing、C051
ユーザー操作が主な関心事であるアプリケーションでは、Grapheme clusters を string indexing の基礎として使用してもよいです。
Character Model for the World Wide Web: Fundamentals、String indexing、C071
複雑な文字体系における typographic character units grapheme clusters が複雑な文字体系を分節化するには 不十分となり得る状況。
文字エンコーディング: 必須概念、文字 & clusters
grapheme clusters の観点で indexing を定義する仕様は、次のいずれかを行わなければなりません: (a) Unicode Standard Annex #29, Unicode Text Segmentation（UTR #29）で定義される extended grapheme clusters の観点で grapheme clusters を定義する、または (b) tailoring が indexing 操作にどのように 適用されるかを具体的に定義する。
Character Model for the World Wide Web: Fundamentals、String indexing、C071
Unicode Standard Annex #29, Unicode Text Segmentation、Grapheme Cluster Boundaries
複雑な文字体系における typographic character units grapheme clusters が複雑な文字体系を分節化するには 不十分となり得る状況。
文字エンコーディング: 必須概念、文字 & clusters
indexing に byte strings を使用することは 推奨されません。
Character Model for the World Wide Web: Fundamentals > String indexing
Character Model for the World Wide Web: Fundamentals、String indexing、C072
UTF-16 code unit string は、 character string の使用と比較して内部操作の効率が大幅に向上する場合であっても、string indexing の 基礎として推奨されません。
Character Model for the World Wide Web: Fundamentals、String indexing、C052
反例として、DOM Level 1 における UTF-16 の使用があります。UTF-16 code points の使用は推奨されません。これは、 2 つの surrogate characters の間に index が発生する可能性を残し、重大な問題を引き起こすためです （6.5 文字列を切り詰める、または長さを制限するを参照）。
substrings または string 内の位置を識別する方法を必要とする仕様は、この操作を行うために string indexing 以外の方法を検討すべきです。
Character Model for the World Wide Web: Fundamentals、String indexing、C053
仕様は、単一文字を substrings として理解し処理し、counting units の選択にかかわらず、 indices を counting units の間の境界位置として扱うべきです。
Character Model for the World Wide Web: Fundamentals、String indexing、C053
API の仕様は、単一文字または単一の「エンコーディング単位」を引数型または戻り値型として 指定すべきではありません。
Character Model for the World Wide Web: Fundamentals、String indexing、C056
string indexing のために単位間の位置を数える場合、string の先頭位置を index 0 として 始めることが推奨される解決策であり、その場合、最後の index は string 内の counting units の数と 等しくなります。
Character Model for the World Wide Web: Fundamentals、String indexing、C057
識別子および構文内容のための string identity matching は、次の手順を含むべきです: (a) 比較対象の strings が Unicode code points の列を構成していることを確認する (b) すべての character escapes および includes を展開する (c) 適切な case-folding および Unicode normalization step を実行する (d) 仕様に固有の追加の matching tailoring を実行する、そして (e) 得られた code points の列を identity について比較する。
照合アルゴリズム、 Character Model for the World Wide Web: String Matching 内
識別子および構文内容における strings の照合に対する既定の推奨事項は、 内容に対して normalization（すなわち case folding または Unicode Normalization）を行わないことです。
適切な Normalization Step を実行する、 Character Model for the World Wide Web: String Matching 内
'ASCII case fold' および 'Unicode canonical case fold' アプローチは、特別な状況でのみ使用すべきです。
適切な Normalization Step を実行する、 Character Model for the World Wide Web: String Matching 内
'Unicode compatibility case fold' アプローチは使用すべきではありません。
適切な Normalization Step を実行する、 Character Model for the World Wide Web: String Matching 内
vocabularies の仕様は、構文内容と文字データとの境界、および entity boundaries （その言語に include 機構がある場合）を定義しなければなりません。
Normalization に関する追加の考慮事項、 Character Model for the World Wide Web: String Matching 内
仕様は、特定の vocabulary のエンコード、保存、または交換のために Unicode normalization form を指定すべきではありません。
Normalization に関する追加の考慮事項、 Character Model for the World Wide Web: String Matching 内。
実装は、交換、読み取り、解析、または処理されるテキストデータの normalization form を 変更してはなりません。ただし、内容を Unicode 文字エンコーディングへ トランスコードする、case folding、またはその他のユーザー起点の変更など、テキスト変換の副作用として そうする必要がある場合は除きます。consumers または内容自体が非正規化表現に依存している可能性が あるためです。
Normalization に関する追加の考慮事項、 Character Model for the World Wide Web: String Matching 内。
仕様は、compatibility normalization forms（NFKC、NFKD）を指定すべきではありません。
Normalization に関する追加の考慮事項、 Character Model for the World Wide Web: String Matching 内。
仕様は、正準的に等価だが互いに素な Unicode 文字列がセキュリティ上の問題を 表す場合、それを文書化するか health-warning を提供しなければなりません。
Normalization に関する追加の考慮事項、 Character Model for the World Wide Web: String Matching 内。
操作が正規化されたテキスト入力から非正規化出力を生成し得る場合、仕様は、 結果の出力が正規化される必要があるかどうかを定義しなければなりません。 仕様は、一部の操作について normalization の実行が任意であると述べてもよいです。 この場合、既定では normalization が実行されるべきであり、 normalization を無効にするには明示的なオプションを使用するべきです。
文書形式で Normalization を 指定する場合の要件、Character Model for the World Wide Web: String Matching 内。
normalization を要求する仕様は、normalization の実装を任意にしてはなりません。
文書形式で Normalization を 指定する場合の要件、Character Model for the World Wide Web: String Matching 内。
normalization-sensitive operations は、実装が最初に検査によってテキストが 正規化形式であることを確認するか、テキスト自体を再正規化していない限り、実行してはなりません。これらの規則の対象ではない私的システム内では 私的合意を作成してもよいですが、外部から観測可能な結果は、その規則に従った場合と同じで なければなりません。
文書形式で Normalization を 指定する場合の要件、Character Model for the World Wide Web: String Matching 内。
テキストを変更し、normalization-sensitive operations を実行する normalizing text-processing component は、各変更の後に normalization が行われたかのように振る舞わなければならず、それにより後続の normalization-sensitive operations は常に 正規化されたテキストを扱っているかのように振る舞います。
文書形式で Normalization を 指定する場合の要件、Character Model for the World Wide Web: String Matching 内。
string values の比較または照合を行う仕様は、Unicode normalization に関する 適切な注記または警告を指定すべきです。
仕様における Unicode Normalization の使用または採用は、通常、特定の形式またはプロトコルで matching がどのように行われるかを定義する一部です。 仕様の著者および実装者が関係する複雑さの一部を理解できるように、Internationalization Working Group は、 strings の照合および比較に関する考慮事項を説明する文書を作成しました: World Wide Web の文字モデル: 文字列照合 [CHARMOD-NORM]。
仕様が行う必要のある選択の 1 つは、仕様の vocabulary の一部として定義されるさまざまな "values" の matching の一部として Unicode Normalization を要求するかどうかです。Values は通常、 文書形式またはプロトコルの構文の一部であり、属性名または値、要素名または値、IDs などを含みます。 matching の一部として normalization を使用しないという 推奨事項に従う仕様は、コンテンツ著者への注意喚起として 次の注記を含めるべきです。
注記の例。必然的に、この版では何が "values" を構成するかについて具体的ではありません。 仕様はより具体的にしたい場合があります。
この仕様は、比較の目的で values の Unicode normalization を許可しません。 視覚的および意味的に同一であっても、異なる Unicode 文字列を使用する values は一致しません。 コンテンツ著者には、values を選択する際に同じエンコーディング列を一貫して使用するか、 潜在的に問題のある文字を避けることが推奨されます。詳細については、[CHARMOD-NORM] を参照してください。
string matching の一部として normalization を要求することを選択する仕様は、次の警告を含めるべきです:
警告の例。必然的に、この版では何が "values" を構成するかについて具体的ではありません。 仕様はより具体的にしたい場合があります。
この仕様は values の matching 中に Unicode normalization を適用します。 これは、影響を受けるテキストの見た目および意味に影響を与えることがあります。詳細については、 [CHARMOD-NORM] を参照してください。
上記が要件を満たさない場合、または使用法について確信がない場合は、代替案または支援について I18N WG に連絡してください。
形式、プロトコル、または形式言語の定義の一部として string matching を定義する 仕様および実装（parsing、matching、tokenizing などの操作を含む場合があります）は、使用される基準および matching forms を定義しなければなりません。これらは次のいずれかでなければなりません: (a) case-sensitive (b) Unicode full case-folding を使用する Unicode case-insensitive (c) ASCII case-insensitive。
user-defined values を含む構文内容の照合には、Case-sensitive matching が推奨されます。
Case-sensitive matching、 Character Model for the World Wide Web: String Matching 内。
Unicode の Basic Latin（ASCII）範囲を超える vocabularies で case-insensitive matching を 定義する仕様は、Unicode full casefold matching を指定しなければなりません。
Unicode case-insensitive matching、Character Model for the World Wide Web: String Matching 内。
Unicode の Basic Latin（ASCII）部分集合に限定された vocabularies で case-insensitive matching を定義する仕様は、ASCII case-insensitive matching を指定してもよいです。
ASCII case-insensitive matching、 Character Model for the World Wide Web: String Matching 内。
language-sensitive case-sensitive matching が指定される場合、Unicode case mappings は言語に従って tailoring されるべきであり、各 tailoring に使用される 言語の出典は指定されなければなりません。
言語固有の tailoring、Character Model for the World Wide Web: String Matching 内。
vocabularies で case-insensitive matching を定義する仕様は、language-sensitive case-insensitive matching を指定すべきではありません。
言語固有の tailoring、Character Model for the World Wide Web: String Matching 内。
一部の仕様、形式、プロトコル、またはそれらの実装は、特定の string のサイズに制限を指定する必要があります。 これは、処理、メモリ、データ構造のサイズなど、多くの理由による可能性があります。長さ制限は、多くの場合、 テキストの切り詰めまたはサイズ制限を伴うため、仕様およびその実装は、テキストが破損しないこと、 また選択された制限が特定の利用者にとって機能を使用不能にしないことを確保するために、追加の注意を 払う必要があります。
仕様は、特定の実用上または技術上の制限がない限り、string の長さに制限を課すべきではありません。
仕様が長さ制限を指定する場合、切り詰められた任意の string が、ellipsis など、 その string が変更されたことを示す indicator を含むように指定すべきです。
仕様または形式で長さ制限が必要となる理由は多くあります。最も一般的な理由は、データに基礎となる サイズ制限があるためです。たとえば、データベース内の固定サイズフィールド、パケットサイズなどの実用上の境界、 または保存割り当てや効率に関連するその他の実装詳細がある場合があります。もう 1 つの一般的な理由は、 表示のサイズまたは可視出力に制限がある場合です。
string の長さを制限する仕様は、その制限が Unicode code points で数えられるのか、 または特定の character encoding の code units （bytes など）で数えられるのかを指定しなければなりません。
strings を切り詰める場合、string のサイズを数えるときにどの単位を使用するかを決める必要があります。 場合によっては、切り詰めが何らかの事前に定められた理由で発生するため、これは仕様の制御を超えます。 しかし、選択が可能な場合は、いくつかの一般的なガイドラインを適用できます。
保存された string の切り詰めを、いくつかの visual text units（grapheme clusters など） の数を使用して指定することは避けてください。
視覚的な長さ制限が必要な場合は、CSS text-overflow [css-overflow-4] など、
string を変更せず、テキストレンダリングの複雑さを考慮するテキストレンダリングまたはクリッピング機構を
使用して、視覚的な切り詰めを指定してください。
仕様は、利用可能な可視空間の代用として visual text units の数を使用しようとして、視覚的制限に 対処しようとすることがあります。そのような制限には、行上の文字数を制限することや、すべての visual text units が同じレンダリング幅を持つようにしようとすることなど、多くの形式があります。 visual text units の使用は、エンコードされた string 内の code points または code units の 数よりも、そのような恣意的な制限により近く対応します。しかし、テキスト表示の性質により、そのような試みは 通常効果的ではありません。比例幅フォント、複雑な文字体系、スタイル、アクセシビリティ機能、その他多くの 要因がこれを複雑にします。ほぼすべての場合、visual text unit の制限は実際にはピクセル幅を近似しようと するものです。実際に制限を測定するには、表示文脈内のフォントメトリクスが必要です。また、 アクセシビリティ設定などのローカル設定の影響を受ける可能性もあります。Web ページでは、CSS text-overflow プロパティが、テキストの内容を乱さずに視覚的切り詰めを提供します。 Unicode code points の数、または grapheme clusters の数に基づいて特定のテキスト片のサイズを推定しようとする試みは、ほとんど無益です。
string の最大許容保存長を制限する仕様は、その長さを Unicode code points の 観点で指定すべきです。
ほとんどの制限は、データベースフィールドのサイズやプロトコル内の長さ制限など、実際には保存上の制限に 関連しています。そのような制限は、Unicode の code points の観点で表されるか、 特定の character encoding における code units（bytes など）の観点で 表されます。Code points は 最良のユーザー体験を提供します。すべての Unicode code points が同一に扱われるためです。テキストが 40 code points の後で切り詰められる場合、すべての言語および文字体系は扱うために同じ数の code points を 得ます。これに対して、サイズ制限が UTF-8 の bytes など code units で表される場合、 主に ASCII 文字を使用する言語を書くユーザーは、主に 1 code point あたり 2、3、または 4 bytes を要する 文字で構成される言語のユーザーよりも、特定のサイズ制限でより多くの文字（code points）を得ます。
何らかの長さ制限に収めるために string の切り詰めを許可する仕様は、そのような切り詰めが visual text unit 境界（通常は grapheme cluster 境界によって近似される）で行われることを要求すべきです。
何らかの長さ制限に収めるために string の切り詰めを行う実装は、visual text unit 境界（通常は grapheme cluster 境界によって近似される）で切り詰めるべきです。
visual text unit の途中での切り詰め、 たとえば combining character sequence の途中での切り詰めは、残りの string の意味を変えることがあります。
長さ制限の表現方法（code points と bytes のどちらか）を選択することに加えて、切り詰め境界を選択する という問題もあります。テキストは code point の 途中で決して分割してはなりません。これは破損した文字を生じるためです。テキストは grapheme cluster の途中で分割すべきではありません。これは表示される文字の見た目および意味を変えるためです。 これは、意味が影響を受けないことを確保するために、追加の code points を削除することを意味する場合があります。
仕様が他の方法を避けられない場合、code units（bytes など）の観点で 長さ制限を指定してもよいです。
文字列の長さ制限は、データベースフィールドのサイズや、別の箇所で指定されたデータ値に割り当てられた bytes 数など、何らかの外部要因によって決まる場合があります。または、固定長の byte 指向ワイヤプロトコルを 記述するなど、何らかの実用上の設計理由により、長さ制限を code units で指定する必要がある場合もあります。 そのような仕様とその実装では、以下の考慮事項を含め、これがもたらす追加の複雑さを明示する必要があります。
仕様が code units（bytes など）で 長さ制限を設定する場合、切り詰めは code point 境界でのみ 行えることを指定しなければなりません。
このベストプラクティスは、UTF-8 などのマルチバイトエンコーディングだけでなく、
16 ビット code units を使用する UTF-16 にも同様に適用されます。U+10000 から
U+10FFFF までの Unicode code points を
エンコードするために使用される UTF-16 surrogate pair は、2 つの
code units を
必要とします。surrogate pair の途中で恣意的に切り詰めると、エンコードされた文字が破損します。
[DOM] を参照する仕様は、文字列操作を code point 境界に制限すること、 そして適切な場合には visual text unit または grapheme cluster の内部で 開始または終了しないようにすることを指定すべきです。
[DOM] とやり取りする仕様または API は、 length、substringData、insertData、deleteData などの操作を含む 文字データが、Unicode code points ではなく UTF-16 code units を 使用して指定されているという事実に対処する必要があります。これは、不適切な文字（code point）の途中での 切り詰めにつながる可能性があります。
仕様が文字列長の制限を code units で表現する必要があるが、 文字列のサイズを自由に指定できる場合、許容できる code points 数に、関連する character encoding の 最大エンコードサイズを掛けた値に基づいて制限を選んでください。
固定サイズのバッファに格納できる code
points の数は、character encoding form と
その code unit に
依存します。たとえば、UTF-8 は Unicode code points を
1 文字あたり 1 から 4 bytes でエンコードします。したがって、その最大エンコードサイズは 4 code units です。
対照的に、UTF-16 は 1 または 2 個の 16 ビット code units を使用します。したがって、その最大エンコードサイズは
2 code units です。ある文字列が少なくとも 50 個の code points を格納すべき場合、
UTF-8 bytes での長さ制限は 50 * 4、つまり 200 bytes になります。UTF-16 での長さ制限は
50 * 2、つまり 100 個の 16 ビット code units（これは 200 bytes と同じ）になります。
そのような制限は、文字列が常に少なくとも 50 個の code points を格納できることを保証します。
ただし、使用される文字によっては、特定の言語でさらに多くの文字を格納できる場合があります。
code units（bytes など）で 長さ制限を指定する場合、仕様は、言語がマルチバイト code unit sequence を必要とするユーザーを収容できるように 制限を設定すべきです。
長さ制限を選ぶ際には、Unicode におけるさまざまな文字体系と言語のニーズを念頭に置いてください。 ある character encoding において、 テキストサイズ制限が code units（byte 長の制限など）で 設定される場合、その制限は、異なる文字体系に対するその character encoding の相対的な効率を 考慮する必要があります。特に、UTF-8 は [Unicode] の マルチバイト character encoding です。UTF-8 は、文字の Unicode Scalar Value が何であるかに応じて、code point あたり 1 から 4 bytes を 使用します。
テキストフィールドに課される制限が bytes で数えられる場合、そのフィールドに格納できる文字数は、 格納される文字に依存します。さまざまな言語を話すユーザーが不利にならないようにするため、 制限は、その言語でエンコードされた妥当な文字数を許容する必要があります。
仕様が code units（bytes など）で長さ制限を指定する場合、その制限を測定するために 使用される character encoding を 指定しなければなりません。そのような制限は legacy character encoding を指定すべきではありません。
仕様が、長さを code units で 表した文字列の切り詰めを許可または要求する場合、character encoding は、その制限が何を意味するかを知るうえで重要になります。制限が bytes 単位であり、 legacy character encodings が許可される場合、Unicode データを非 Unicode エンコーディングへ変換すると、 データ損失が生じる可能性があることに注意してください（ほとんどの legacy character encodings は Unicode の部分集合しかエンコードしないためです）。
仕様は、natural language または 表示可能な文字列値を形成するために、文字列値の連結を要求すべきではありません。
複数の文字列を連結して natural language の テキスト値を作成することは、国際化のアンチパターンです。言語は、語順、数、文法上の性または格、句読点、 その他多くの要件において大きく異なります。そのため、実装が部分文字列から人間が読めるメッセージを 生成することを要求または示唆するのは避けてください。
仕様が、ユーザーに表示されるテキストを作成または生成することを実装に要求する場合、 仕様は、テキスト方向に関連する潜在的な問題を避ける方法について、実装者に指針を提供すべきです。
API、プロトコル、または文書形式の仕様は、実装に表示名または説明を含むフィールドを作成または提供することを 要求する場合があります。そのような文字列が別々の部分から組み立てられる場合、Unicode Bidirectional Algorithm [UAX9] が組み立てられた文字列を 処理する方法により、表示または理解に問題が生じる可能性があります。そのような場合、仕様は、正しく表示される 値を作成する方法について実装者を導くべきです。
一部の仕様では、さまざまな実装によってファイル名またはファイルパスがどのように構成されるかを 定義する必要があります。課題の 1 つは、異なるオペレーティングシステムで使用される異なるファイルシステム上で 一貫して機能する定義を構築することです。この節では、ファイル名またはファイルパスに制限を定義する際の 一般的な指針を示します。これは [EPUB-33] で 開発された要件、および実装経験に基づいています。
ファイル名は 255 bytes の長さに制限すべきです。
この制限は、特定のファイルシステム、もともとは MS-DOS、さらに特定の Unix ファイルシステムに 見られる制限に関連しています。また、これらのファイルシステムに依存する、またはそれらの制限を取り込んだ PKZIP などのパッケージング方式にも関連します。そこでは、特定の「path element」（ディレクトリ名を含む）の 制限が 255 bytes に制限されています。
パス名は 65535 bytes の長さに制限すべきです。
この制限は、FAT32 や NTFS などのファイルシステムに見られる制限に関連しています。これらは、 UTF-16 character encoding における 32760（32K）code units にパス長を制限します。各 UTF-16 code unit は 16 bits（または 2 bytes）を使用するため、bytes で測定した場合の制限は 65,535 になります。 UTF-8 は可変幅エンコーディングであるため、UTF-8 で 64K bytes に制限されたパス名は、 これらのファイルシステム上のパス長制限を超える可能性がある点に注意してください。
ファイル名およびパス名の定義では、次の Unicode code points を使用してはなりません。
これらの文字は、さまざまなファイルシステムとの相互運用性問題を引き起こすことが知られています。 コンテンツの相互運用性が重要である場合、仕様および実装はファイル命名において十分すぎるほどの注意を 払うべきです。制限文字の一覧は、既知の問題領域の一部を避けるのに役立つことを意図していますが、 他のすべての 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
（これには、多くのファイルシステムで特別な意味を持つファイル名 . および .. が
含まれる点に注意してください）アプリケーションは、情報やコンテンツの集合を整理する必要がよくあります。多くの場合、これにはコンテンツの 並べ替えが伴います。数値や日付など、多くの非テキストデータ型は、内部データ表現を使用して簡単に 並べ替えできます。しかし、テキスト情報の場合、character encodings の性質と「アルファベット順」に関する ユーザーの期待が、追加の複雑さをもたらします。
重要な選択の 1 つは、テキストデータの並べ替えが厳密に内部的なものなのか、それとも結果がユーザーに 表示されるのかです。
人間による閲覧または操作を意図しない、プログラム内部の高速で決定的なテキストの 並べ替えを必要とする仕様または実装は、文字列の定義に従って文字列を並べ替えることを指定すべきです。scalar value strings（USVString や多くの XML 処理など）では、 昇順 code point 順を指定してください。UTF-16 に基づく string 型（DOMString や多くの JavaScript APIs など）では、昇順 code unit 順を指定してください。
潜在的な内部並べ替え順序は 2 つあります。Unicode code point による順序付け、または UTF-16 code unit に よる順序付けです。どちらの種類の順序付けでも、結果の一覧はいかなる特定のアルファベット順または 辞書式順序にも一致しません。
code point による並べ替えは、USVString のように、 文字列が code points の列として格納および処理される場合に意味があります。code unit に よる並べ替えは、DOMString のように、 文字列が基盤となるエンコーディングを使用して格納および処理される場合に意味があります。
これらの並べ替え順のいずれも、比較される文字列に対して何らかの正規化を適用しません。 これは、見かけ上等価な一部の文字列が異なるものとして比較されることを意味します。詳細については String Matching [CHARMOD-NORM] を 参照してください。
ユーザーへの表示のために自然言語テキストの並べ替えを扱う必要がある仕様またはアプリケーションは、 追加の複雑さに直面します。Unicode は、Unicode Collation Algorithm [UTS10] の一部として 既定の照合（並べ替え）順序を定義しており、それは特定の言語、locales、および文化のニーズに合わせて 調整されます。
ユーザーへの提示のためにテキストを並べ替える場合、並べ替え順は、そのアプリケーション内の 特定のユーザーに対して最も適切な locale に 従って調整されるべきです。したがって、提示順はユーザーごとに異なる場合があります。
Unicode Collation Algorithm [UTS10]
Locale Data Markup Language の Collation 節 [UTS35]
照合単位、C007、 World Wide Web の文字モデル: 基礎内
言語や文化によって、テキストをどのように並べ替えるか、またはアルファベットや書記体系を使って
テキストデータをどのように整理するかは異なります。たとえば、ドイツ語話者は文字 üU+00FC LATIN SMALL LETTER U WITH DIAERISIS を文字
u と似たものとして並べ替えます（実際には、この文字の正確な扱いがわずかに異なる
2 つのドイツ語の並べ替え順序があります）。一方、デンマーク語話者は同じ文字をアルファベット内で
別のものとして扱い、文字 "y" の後に並べます。
並べ替えられた一覧にどの locale を使用するかを決定することは、いくつかの要因に依存します。 たとえば、アプリケーションは、データが現れるページのローカライズに従って値の一覧を並べ替える場合があります。 他の場合には、user-agent の実行時 locale、または API に渡される何らかのパラメーターに従って 並べ替える方が理にかなう場合もあります。重要なのは、この順序がユーザーごと、またはシステムごとに 異なる可能性があることを認識することです。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2 番目のチェックボックスを選択してください。その後、「GitHub 用 markdown を作成」 ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。詳細を 参照してください。
resource identifiers における non-ASCII 文字のサポートを指定する状況は複雑です。これは、resource identifiers とそのシリアライズを 定義する仕様が少なくとも 3 つ（URI [RFC3986]、IRI [RFC3987]、および [URL]）存在するためです。 WhatWG [URL] 仕様は、 ブラウザーやその他の user agents の実際の慣行を文書化することによって、この複雑さに対処しようとするものです。 URL 仕様の明示された目標は、両方の RFC を obsolete にすることです。
一般に、Web 上の文書形式では、non-ASCII 文字をプレーンテキストとしてエンコードする resource identifiers、 すなわち "IRIs" を使用します。HTTP [RFC9110] など （ただしこれに限られない）のプロトコルでは、non-ASCII 文字を percent encoding を使用して bytes の列としてエンコードする resource identifiers、すなわち "URIs" を使用します。[RFC3986] は、文字を bytes に エンコードするための特定の character encoding を 指定していないため、percent encoding のエスケープは 誤解釈されやすくなります。これに対処するため、多くの現代的なプロトコルおよび仕様では、文字を ワイヤ形式およびプロトコルでサポートされる ASCII の部分集合へエンコードする際、IRI で指定されているとおり、 resource identifiers が UTF-8 character encoding を使用することを期待しています。
resource identifiers を 定義する仕様は、non-ASCII 文字の使用を許可しなければなりません。
Model is defined in terms of IRIs; Protocol with URI。GitHub issue の議論。
文書形式またはプロトコルは、non-ASCII 文字を含む resource identifiers をサポートする必要があります。 多くの場合、あるリソースの名前または識別子はユーザー入力から生成されるためです。ユーザーは一般に、 これらの値に自分の言語を使用する能力を制限されておらず、また制限されるべきではありません。
文書形式、データ構造、または API を定義する Web 上の仕様は、resource identifiers を 指定する際に [URL] を参照すべきです。[URL] 仕様でサポートされていない場合には、代わりに IRI [RFC3987] を指定してもよいです。
プロトコルを定義する仕様は、ワイヤ形式で使用する resource identifiers を指定する際に URI [RFC3986] を参照してもよいですが、percent encoded 値を文字として解釈する際には UTF-8 を使用しなければならないという 追加要件を含めなければなりません。
[RFC3986] の定義によれば、 URI 参照は ASCII の部分集合に制限され、non-ASCII 文字を直接使用することはできません。percent encoding は任意の byte 値をエスケープするために提供されています。しかし、percent encoding それ自体の 価値は限られています。与えられた bytes の列を文字として解釈する（または与えられた文字列を bytes に エンコードする）ために、多くの異なる legacy character encodings が使われる可能性があるためです。Internationalized Resource Identifiers （IRIs） [RFC3987] は、 [Unicode] の UTF-8 エンコーディングに基づく統一的な方法で、 resource identifiers における non-ASCII 文字のエンコードおよび解釈の問題を解決します。
仕様は、resource identifier で 許可される文字について独自の制限を課してもよいですが、それらは resource identifiers の 構文、転送形式、または仕様自体によって定義される他の要素と競合する文字に焦点を当てるべきです。
一般には推奨されませんが、追加の制限を検討する場合は、追加の指針として [UAX31] および [CHARMOD-NORM] を 確認してください。
URI の新しい構文、または URI 内に含まれる構文を定義する仕様は、ASCII repertoire の外にある 文字が UTF-8 character encoding を使用して percent encoded されることを指定しなければなりません。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2 番目のチェックボックスを選択してください。その後、「GitHub 用 markdown を作成」 ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。詳細を 参照してください。
マークアップで要素と属性を定義する
マークアップ内のプレーンテキストを扱う
識別子を定義する
U+D800 から U+DFFF）または non-character code points を
許可すべきではありません。詳細
U+0000 から U+001F）および C1
（U+0080 から U+009F）制御文字を許可すべきではありません。詳細
形式言語、文書形式、プロトコル、または API を扱う仕様では、マークアップ、構文、または application internal identifiers を定義する必要がよくあります。この節のベストプラクティスは、それらを定義する際の 異なるニーズを扱います。
マークアップ言語、または特定のマークアップ言語に基づく構文を定義する仕様は、要素、属性、および それらの値の定義に関心があります。たとえば、[XML] DTD は、 特定の文書型で有効な要素および属性を定義します。
特定の文書形式、プロトコル、または API を定義する仕様は、通常、予約キーワード、フィールド名、 または許可された値の識別子を定義することに関心があります。これらの多くは application internal identifiers であり、その名前と値は仕様によって完全に定義されます。場合によっては、仕様が これらの一部または全部を、ユーザーが入力または命名できる user-supplied value として 許可することがあります。
ユーザーが読める内容を含む属性値を定義しないでください。そのような内容には 要素を使用してください。
Best Practice 3: Avoiding translatable attribute values、Best Practices for XML Internationalization 内
ユーザーが読める内容を含む属性値を定義する場合は、そのテキストの方向および言語情報を、 要素に含まれるテキストとは別に示す手段を提供してください。
著者が span のような要素または構文を使って、任意のインライン内容に
注釈を付けられる方法を提供してください。
Best Practice 14: Defining a span-like element、Best Practices for XML Internationalization 内
プレーンテキストだけを許可する要素または属性値に natural language テキストを 入れることは避けてください。
内容が natural language テキストに なる属性値を定義することは避けてください。
国際化に必要な情報を適用するために、任意のテキスト内容で使用できる span のような要素を提供してください。
国際化情報には、言語および基底方向のメタデータ、インラインの言語変更、双方向テキストの 振る舞いの変更、translate フラグなどが含まれる場合があります。
文書形式の一般的な機能の 1 つは、さまざまな識別子の定義です。これには、予約キーワードだけでなく ユーザー定義値も含まれます。相互運用性を促進するため、実装は識別子値を確実かつ一貫して 照合できる必要があります。この問題の詳細については、Character Model: String Matching [CHARMOD-NORM] を 参照してください。
application internal identifiers（ユーザーには決して表示されず、アプリケーションまたはプロトコル内での 照合または処理に常に使用されるもの）を定義する仕様は、内容を ASCII の印字可能な部分集合に 制限すべきです。ASCII の大文字小文字を区別しない照合が推奨されます。
[CHARMOD-NORM] における 内容制限の指定
仕様は、コンテンツ著者がやり取りする、またはさまざまな種類のエンドユーザーにとって意味を持つ 識別子の集合を定義する必要がある場合があります。許可される文字集合を ASCII に制限すると、 特にラテン文字を使用しない言語の話者や ASCII 範囲外の文字を使用する話者にとって、使いやすさが 妨げられます。
識別子がユーザーに表示される、または表示される可能性がある場合、すべての言語の ユーザーが結果として得られる文書形式またはプロトコルを平等に使用できるように、仕様は non-ASCII Unicode 文字の使用を許可すべきです。大文字小文字の区別（すなわち case folding なし）が 推奨されます。
[CHARMOD-NORM] における 内容制限の指定
application internal identifiers が ASCII に制限されない場合、仕様は、有効な識別子の開始および一部として 許可される文字を定義すべきです。
Unicode Identifier and Pattern Syntax [UAX31]
例: ECMAScript 5、第 7.6 節 Identifier Names and Identifiers
新しい仕様で識別子名前空間または識別子集合を定義する際の重要な問題の 1 つは、文書形式を解析する際の 結合記号および特定の他の文字（joiners や bidi controls など）の扱いです。識別子をどのように "tokenized"（周囲のテキストから分離）できるかに特に注意を払う必要があります。これを行う方法の 1 つは、 後で識別子を照合するときに通常のテキスト処理が干渉しないように、識別子を開始できる文字の範囲を 制限することです。
Unicode Identifier and Pattern Syntax [UAX31] は 1 つのモデルを提供しており、 Java や JavaScript などのプログラミング言語で特に 使用されています。HTML と CSS も、カスタム識別子のための 文字範囲定義を 提供しています。たとえば、次の EBNF [XML] production です:
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 文字プロパティ （たとえば特定の文字が結合記号であるかどうかなど）を考慮しないように定義されています。 これにより、識別子が結合文字で始まっても確実に処理できますが、プレーンテキストエディターが その値を同一に扱わない可能性があります。
仕様は、識別子を定義する際に whitespace の扱いに注意を払うべきです。ASCII 文字である
U+0020 SPACE および U+0009 TAB 以外にも Unicode の水平 whitespace 文字があることに
注意してください。
仕様は、識別子に surrogate code points（U+D800
から U+DFFF）または non-character code points を許可すべきではありません。
[CHARMOD-NORM] における 内容制限の指定
仕様は、識別子に C0（U+0000 から
U+001F）および C1（U+0080 から U+009F）制御文字を
許可すべきではありません。
[CHARMOD-NORM] における 内容制限の指定
non-ASCII 文字が許可される場合、識別子は大文字小文字を区別すべきであり、 ASCII 文字だけが許可される場合は大文字小文字を区別しないべきです。
[CHARMOD-NORM] における 内容制限の指定
Application internal identifier のフィールドまたは値は、エンドユーザーに表示されるとき、ローカライズ可能な表示値で 包まれなければなりません。
[CHARMOD-NORM] における 内容制限の指定
フィールドおよび値には、locale-neutral で culturally-neutral な名前を選んでください。
フィールド名および値を含む識別子を定義する場合は、できるだけ文化的に中立な名前を選んでください。
たとえば、（米国固有の）ZIPCode よりも postalCode を優先し、より文化に
結びついた firstName/lastName よりも givenName/familyName を優先してください。
一部の仕様では、文書形式またはプロトコルにおける特定のフィールドの値を定義する必要があります。 データ値が数値や日付などの特定の型に関連付けられる場合、そのフィールドの形式は通常、 [XMLSCHEMA11-2] や [JSON-SCHEMA] などの よく知られた schema を使用して定義されます。
machine-readable であることを意図した、ローカライズ不能な string data values を 定義する仕様は、natural language text と容易に混同されない値を使用すべきです。
多くのプロトコル、文書形式、またはデータ構造は、内部使用のための列挙値を定義します。これらの値は、 人間に直接見せることを意図したものではありません。仕様、プロトコル、または API を扱うユーザー、 あるいは特定の文書ややり取りをデバッグする必要のあるユーザーを助けるために、これらの値に 説明的な名前（多くの場合英語）を付けることが役立つ場合があります。仕様でこれらの値を割り当てる際、 選ばれる名前は "code-like" に見えるべきです。そうすることで、ユーザーがその値を natural language text の ように表示できると想定しないようにします。
application-internal values を "code-like" に見せるために、さまざまなグループが採用している スタイルがいくつかあります。仕様に最も適したものを選んでください。これには次が含まれます:
U+005F LOW LINE）で区切ります。人間による消費を意図した内容を持つフィールドは、常に natural language string values として扱われなければなりません。そのような各フィールドについて、言語および基底方向の メタデータを見つけられなければなりません。
人間が読める文字列、特に説明的な性質のものを含むフィールドは、natural language strings であると 想定されなければなりません。これは、その文字列を見るユーザーがソフトウェア開発者であると期待される 場合でも当てはまります。文書またはデータ構造内のそのような各フィールドについて、言語タグと 文字列方向を決定できなければなりません。
この種のフィールドの一般的な名前には、name、description、
title、message、または時には value があります。
これを判断する 1 つのテストは、仕様作成者またはユーザーとして、そのフィールドの内容を
SNAKE_CASE_SHOUTED にすることに違和感があるなら、そのフィールドは natural language text として
扱う方がよい可能性があるということです。
人間による消費を意図したフィールドは、ローカライズ可能であるべきです。
これはさまざまな形を取り得ます。たとえば、仕様またはプロトコルは言語ネゴシエーションを許可し、 最もよく一致するローカライズ済み文字列だけを返すことがあります。また、特定のリソースが複数の言語を 含み、consumer がその中から選択できる場合もあります。
フィールド名およびその他の列挙値は、ローカライズ可能な表示名で包まれるべきです。
フィールド名および列挙値は、たとえその名前がプレーンテキストのように見え、ユーザーに理解される可能性が あっても、natural language text ではありません。これらのフィールドおよび値には、言語または方向の メタデータを関連付けるべきではなく、必要な場合、実装者は適切なローカライズ済みのラッピングを提供するよう 仕様によって導かれるべきです。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2 番目のチェックボックスを選択してください。その後、「GitHub 用 markdown を作成」 ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。詳細を 参照してください。
テキスト装飾
縦書きテキスト
before および after
の行位置に依存すべきではありません。詳細vertical-
値と等価な縦書きモード（のみ）は、文字の既定のテキスト方向を適用するために [UTR50] を使用すべきです。
（これは CSS の sideways- と等価な writing modes には
適用されません。）詳細
sideways-lr や
sideways-rl のような値を提供すべきです。UTR50 は
これらの場合には適用できません。詳細
RTL/bidi テキスト
テキスト方向が変化する場合のボックス配置座標を設定する
論理プロパティ（TBD）
筆記体テキスト
ルビテキスト注釈
rb rb rt rt に近い列として配置できるもの）を
サポートすべきです。詳細
rb 要素のように、ruby bases のための明示的な要素を使用できるように
すべきです。詳細フォント管理（TBD）
underline や overline などのテキスト装飾では、線がインクを避けられるようにすべきです。
overline および underline とテキストとの距離を指定できるようにすべきです。
下線などのテキスト装飾でインクを避けることは、アラビア語など一部の文字体系には適切でない場合があります。 そのような文字体系では、代わりに下線を baseline からさらに離すことを好みます。
日本語、中国語、韓国語、モンゴル語などの言語について、テキストを縦に レンダリングできるようにすべきです。
縦書きテキストは、LTR（例: モンゴル語）および RTL（例: 日本語）からの行進行をサポートしなければなりません。
既定では、行が左から右へ積み重なる縦書きテキスト（例: モンゴル語）における
テキスト装飾、ルビなどは、CJK 縦書きテキストの場合と同じ側に表示されるべきです。
配置は before および after
の行位置に依存すべきではありません。
CSS の vertical-
値と等価な縦書きモード（のみ）は、文字の既定のテキスト方向を
適用するために [UTR50] を使用すべきです。
（これは CSS の sideways- と等価な writing modes には適用されません。）
writing modes は、横書き文字体系テキストの行を縦方向に回転できるようにするため、
CSS の sideways-lr や sideways-rl のような
値を提供すべきです。UTR50 はこれらの場合には適用できません。
既定では、通常は横書きの文字体系の glyphs は、文字の上側が縦行の右側を 向くように、縦書きテキスト内の行に沿って並ぶべきですが、それらが upright orientation で 行に沿って下へ進むことを許可する仕組みもあるべきです。そのような仕組みは、最小のテキスト単位として visual text units（grapheme clusters など）を 使用すべきですが、必要に応じて、複数の grapheme cluster を含む場合に syllabic clusters を 1 単位として扱えるようにすべきです。
縦行内の upright Arabic text は、isolated letter forms を使用し、テキストの順序は 上から下へ読めるようにすべきです。
一部の文字列（特に数字）は、縦行内で横方向に並べられるようにすべきです （縦中横）。
letterforms の傾斜を可能にする仕様は、特定の言語のニーズに応じて、 文字が右または左のいずれにも傾けられるようにすべきです。
ボックス配置座標は、テキストが横書きか縦書きかを考慮しなければなりません。
ユーザーインターフェイスまたは Web ページをローカライズする場合、RTL 版と LTR 版のために
鏡像を作成するのが一般的です。たとえば、英語コンテンツを含むウィンドウの左側付近に表示される
ボックスは、コンテンツがアラビア語またはヘブライ語である場合、ウィンドウの右側付近に表示される
可能性があります。絶対ジオメトリを使用する強い理由がない限り、現在の文脈の基底方向に基づいて、
これが自動的に変化することが望ましいです。これを実現する 1 つの方法は、位置を示すために
left や right ではなく、start や
end などのキーワードを使用することです。
アラビア語、モンゴル語、N'Ko などの筆記体テキストで、結合された文字に透明度が 適用される場合、重なりが露出すべきではありません。
text stroke または shadow を追加する場合、筆記体系テキストの結合文字は 隣接する文字から分離されるべきではありません。
base text の横に置かれる 'Ruby' スタイルの注釈は、中国語、日本語、韓国語、 モンゴル語のテキストについて、横書きと縦書きの両方の writing modes でサポートされるべきです。
Ruby 実装は、繁体字中国語のための zhuyin fuhao（bopomofo）ruby を サポートすべきです。
Ruby 実装は、ruby contents を rb rb rt rt
に近い列として配置できるような、tabular content model を
サポートすべきです。
Ruby 実装は、HTML の rb 要素のように、
ruby bases のための明示的な要素を使用できるようにすべきです。
Ruby 実装は、注釈を base text の片側または両側に表示できるようにすべきです。
HTML の Ruby markup は、中国語、日本語、韓国語、モンゴル語の要件のために 特に設計されており、一般的な glossing mechanism として使用すべきではありません。
行の高さは、英語よりも背の高い文字を許容しなければなりません。
ボックスサイズは、翻訳時のテキスト拡張を許容しなければなりません。
行折り返しは、非ラテン文字体系に必要な特別な規則を考慮すべきです。
さまざまな非ラテン文字体系では、単純に語間スペースでテキストを折り返すわけではありません。 それらには尊重されなければならない追加の規則があります。たとえば
追加の背景情報については、CSS Text Level 3 仕様を参照してください。（必要であれば、この チュートリアルにも追加の例があります。）
表示目的のマークアップ b、i、または u は避けるのが最善です。
これは、書記体系間で相互運用できず、さらにローカリゼーションに不要な問題を引き起こす可能性があるためです。
また、一部の文字体系には、強調などに対する固有の方法があり、それは bolding、italicisation などを伴わず、
それらとは大きく異なる場合があります。
HTML の場合には legacy issue がありましたが、あなたの仕様にそうした問題がない限り、 テキストの表示を決定するには styling を使用し、マークアップまたはタグ付けは一般的な意味論的アプローチを 許容すべきである、というのが推奨です。
b および i タグをめぐる問題の説明については、<b> および <i>
要素の使用を参照してください。
これは、この節に含まれる要件だけの一覧であり、自己レビューに使用できます。仕様に関連する すべての要件について、各行の最初のチェックボックスを選択してください。仕様がその要件を 満たしている場合は、2 番目のチェックボックスを選択してください。その後、「GitHub 用 markdown を作成」 ボタンをクリックし、結果を GitHub issue のリストにコピーしてください。詳細を 参照してください。
locale の影響を受ける値を扱う
時刻を扱う
個人名を扱う
数値を扱う
フォームを設計する
ユーザー入力（TBD）
例の作成（TBD）
ローカリゼーション
言語および文化的な選好をサポートするソフトウェアシステムは、internationalized
であると
言われます。国際化されたシステムは、ユーザーの選好に基づいて、言語または文化に固有の処理を
提供するために API を使用します。これらのユーザー選好は通常 locale
と呼ばれます。
一般的な国際化用語について詳しくは、Language Tags and Locale
Identifiers [LTLI] を
参照してください。
データ形式を定義する場合は、locale-neutral なシリアライズ形式を使用してください。
machine-readable であり、特定の言語または文化に固有ではないデータ値は、多くの異なる文化的表現の 1 つを使用する値よりも、より耐久性があり、誤解されにくいものです。日付、通貨、数値のようなものは、 見た目が似ていても、異なる locales では異なる意味を 持つことがあります。たとえば、文字列 4/7 として表された日付は、ユーザーの選好に応じて 4 月 7 日または 7 月 4 日として読まれる可能性があります。同様に、€2,000 は 2000 ユーロ、または 2 ユーロの過度に精密な表現のいずれかです。locale-neutral な形式を使用することで、 システムは、ユーザーの言語または所在地によって変化する特定の交換規則を確立する必要を避けられます。 データがすでに locale-specific な形式である場合、locale パラメーター（通常は language tag の形） を提供して locale と言語を明示することで、ユーザーはデータの扱い方を判断でき、場合によっては 自動翻訳サービスを有効にできます。
最も一般的なデータシリアライズ形式は locale-neutral です。たとえば、[XMLSchema-2] の
xsd:integer や xsd:date などの型は、locale-neutral なデータ交換を意図しています。
locale-neutral な表現を使用すると、複雑な解析や誤解釈なしにデータ値を正確に処理でき、さらに、
任意の locale においてデータの consumer にとって最も使いやすい形式でデータを提示することもできます。
たとえば、"€2000,00" を文字列として保存するよりも、次のようなデータ構造を交換することが
強く望まれます:
…
"price" {
"value": 2000.00,
"currency": "EUR"
}
…calendar および date systems を定義する場合は、common era より前の日付を 許容するか、少なくとも最も一般的な範囲外の日付の扱いを定義するようにしてください。
time または date data types を定義する場合、time zone または UTC との関係が 常に定義されるようにしてください。
"floating" な time または date data types と incremental types との相互変換について、 必要に応じて Time Zones WG Note を参照する health warning を提供してください。
date and time data types で leap seconds を許容してください。
これは、1 分の秒数が 0 から 60 までの範囲になることが許される場合に、ときどき発生します （すなわち、その分には 61 秒があります）。
date and time values を論じる場合は、一貫した用語を使用してください。 time zone independent values には 'floating' time を使用してください。
time zone の定義と time zone offset を分離しておいてください。
time zones を識別するには IANA time zone IDs を使用してください。time zone の 代理として offsets または LTO を使用しないでください。
time zone を識別するために別個のフィールドを使用してください。
"week" の規則を定義する場合は、文化固有の規則を適用できるようにしてください。
たとえば、週末は常に土曜日/日曜日とは限りません。週の最初の日も常に日曜日 [または月曜日、または...] とは限りません。
year の week number の規則を定義する場合は、文化固有の規則を適用できるようにしてください。
non-Gregorian calendars が許可される場合、"month" フィールドが 13（undecimber）に なり得ることに注意してください。
個人名を使用するアプリケーション（Web フォーム、データベース、オントロジーなど）を作成する開発者は、 他の国々で名前がどれほど異なり得るかに気づいていないことがよくあります。彼らは外国のユーザーについて あまりにも多くのことを仮定する形で、フォームやデータベースを構築します。この節では、世界中の 個人名を扱うためのガイドラインを提供します。
given name(s) と family name(s) を別々に保存またはアクセスする必要が本当に あるか確認してください。
分割するか、 しないか？、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
世界中の名前は、構成および構成要素の順序が大きく異なります（世界の個人名を参照）。 たとえば、ある人の名前をデータベースに保存するために小さな部分へ分割し、後でそれらを取得しようとすると、 特に何らかの再構成が必要な場合に困難が生じることがあります。困難には、名前のどの部分が どのデータベースフィールドに属するかを理解すること（特に、データベース内のフィールドよりも 部分が多い、または少ない場合）、および実際に使用するためにデータベースから誰かの名前を取得する際に 名前部分の順序を扱うことが含まれます。
さまざまな背景を持つ人々から名前を受け付けるフォームまたはデータベースを設計する場合、 given name や family name のようなものに対して、本当に別々のフィールドを持つ必要があるかを 自問すべきです。これはデータで何をする必要があるかによりますが、可能な場合には、ユーザーが提供した full name をそのまま使用する方が明らかに簡単です。
名前の長さに制限を設けることは避けてください。設ける場合は、長い文字列を 許容してください。
分割するか、 しないか？、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
一部の文化では名前がかなり長くなり得ることを念頭に置いてください。長い名前を入力できるように、 フィールドを十分長くしてください。また、名前が 1 文字より多いと仮定しないでください。
特に、bytes で長さを数えることは避けてください（4.2 「string」の定義を選択するを参照）– UTF-8 の 4 文字の日本語名が 4 bytes に収まると 仮定しないでください。実際には 12 bytes 必要になる可能性が高いです。
この節のガイドラインは、保存または提示のために人名を分割する必要があると判断された場合に 適用されます。
'first name' と 'last name' というラベルの使用は避けるようにしてください。 'given name(s)' や 'family name(s)' などの代替を検討してください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
'first' と 'last' という用語の使用は、通常 family name を given names の前に書く人々にとって 混乱を招く可能性があります。米国のユーザー向けフォームでは 'first' と 'last' を使用しても 問題ないように見えるかもしれませんが、そのフォームは最終的には、米国内および米国外の可能性を含め、 異なる文化的背景を持つ人々によって使用されることがあります。
また、一部の文化ではこれがなお問題になることにも注意してください。たとえばアイスランド人は、 実際には family names を持たず、given name と patronymic を持ちます（Given name and patronymic を参照）。しかし、高度にローカライズされたカスタマイズをしない限り、 汎用的な解決策としては、おそらくこれが最善です。
full name フィールドに加えて、特定の目的に使用する必要がある名前の一部を ユーザーが提供できる 1 つ以上の追加フィールドを持つことが妥当かどうか検討してください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
誰かが連絡するときにどのように呼ばれたいかを、ユーザーに別途尋ねられるようにしてください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
たとえば、場合によっては、名前の一覧をアルファベット順に並べ替えるため、または連絡時に 呼びかけるためなどに、名前の一部を識別したいことがあります。
この追加フィールドは、名前構成要素の長い一覧から適切な名前を見つけるためにも、また nickname を扱うためにも有用です（たとえば、タイでは人を指すために nickname が一般的に 使用されます）。
ときには、相手に直接呼びかける、または相手を指すために、名前の一部を使用できるようにしたい ため、別々のフィールドを選ぶことがあります。たとえば、ソーシャルメディアアプリが "David's contacts" と参照する場合です。あるいは、メールの冒頭に相手の名前を入れて送りたいから かもしれません。ここで名前構文に起因する問題があるだけでなく、形式性に関する世界中のさまざまな 期待も考慮しなければならない点に注意してください（見知らぬ人に given name で呼ばれることを 誰もが快く思うわけではありません）。たとえばプロフィールを設定するときなどに、その人がどのように 呼ばれたいかを別途尋ねる方がよい場合があります。
人名の一部を別々に取得する場合は、それらの個別項目がすべての関連情報を 取得できるようにしてください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
たとえば、名前を提供する順序が 'given name' の後に 'family name' であると仮定しないでください。 また、複数の語から構成される名前において、どの部分がそれらのカテゴリのどちらに当てはまり、 どの部分がまったく別のもの（父親の名前、村名、clan name など）に関係するのかを識別できると 仮定しないでください。
名前の一部を自動的に抽出するアルゴリズムに組み込まれた前提に注意してください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
たとえば、implied “n” optimization という v-card および h-card のアプローチは、中国語名などで 困難に直面する可能性があります。入力フォームは、必要だと考えるデータを取得できるよう、 人々に自分の名前をどのように指定するかを伝える際に、できるだけ明確であるべきです。
1 文字の名前を initial と決めつけないでください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
人々の中には 1 文字の名前を持つ人もいます。フォームバリデーターがその名前を拒否し、名前を 省略せずに入力するよう要求する場合、こうした人々は問題に直面することがあります。initial を 使わないよう促したいのであれば、フォーム送信をブロックするのではなく、警告メッセージにする方が よいでしょう。
人々に family name の提供を要求しないでください。
名前を 分割するための戦略、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
南インド、マレーシア、インドネシアの一部などの文化では、多くの人が patronym なしの given name だけからなる名前を持ちます。family names を要求すると、これらの文化では重大な問題を 作り出す可能性があります。ユーザーがフォームから逃れるためだけに family name フィールドへ "." や "Mr." のようなごみデータを入力するからです。
名前にハイフン、アポストロフィなどの句読点を使用できるようにし、それらの 文字に対する代替 code points の可能性を考慮してください。
その他の 事項、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
これにより、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 で表される場合があります。
名前をすべて大文字で入力することを要求しないでください。
その他の 事項、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
名前の大文字小文字を正規化しないでください。
その他の 事項、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
一部の名前（'McNamara' など）には、最初の文字ではない大文字が含まれます。その他の名前 （'van der Waals' など）には、大文字化されない語が含まれます。フォームは、ユーザーが入力した 大文字小文字を保持し、そのような名前を常に、または各語の先頭だけに大文字を使用するよう 強制すべきではありません。
ユーザーがスペースを含む名前を入力できるようにしてください。
その他の 事項、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
Gabriel García Márquez の family name（García Márquez）や、José María Olazábal の given name （family name は Olazábal）などを正しく取得できます。
同じ家族の成員が同じ family name を共有すると決めつけないでください。
その他の 事項、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
同じ家族の成員が同じ family name を共有すると仮定するのは誤りです。西洋では、結婚後も個人が 自分の名前を保持する傾向が強まっていますが、中国のようにそれが通常の方法である文化もあります。 国によっては、妻が夫の名前を取る場合もあれば、取らない場合もあります。
ヒスパニック系の名前を扱う場合、家族内で同じ family names を持つのは子どもだけであり、 それらは両親それぞれのものとは異なる可能性があります。Manuel Pérez Quiñones は、自分の apellidos（Pérez Quiñones）を、父親の apellidos が Pérez Rodríguez、母親の apellidos が Quiñones Alamo であったことから得ました。やがて、彼は apellidos が Padilla Falto の女性と交際しました。 結婚すると、彼女の apellidos は Padilla de Pérez になりました。彼らの子どもは Pérez Padilla と呼ばれ、 以後も同様です。
フォームでは、'Maiden name' や 'née' よりも 'Previous name' と尋ねる方が よい場合があります。
その他の 事項、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
また、名前の採用が夫から妻へ向かうと単純に仮定すべきではありません。ときには男性が結婚時に 妻の名前を取ることもあります。このような場合、フォームでは 'Maiden name' や 'née' よりも 'Previous name' と言う方がよい場合があります。
おそらく名前を Latin 文字と native script の両方で保存する必要があります。 その場合、ユーザーに native script と Latin-only form の両方で、別個の項目として名前を 提出してもらう必要があります。
文字サポートへの 影響、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
複数のフィールドが必要かどうかは、ある程度、人々の名前を何のために収集し、それらをどのように 使用するつもりかによって異なります。
必要に応じて、名前の transcription 用のフィールドを提供してください。
文字サポートへの 影響、Personal Names Around the World 内。
違いの例、 Personal Names Around the World 内。
たとえば、日本のユーザーは、表意文字形式の代わりに、またはそれに加えて、日本語の音節文字で transcription を提供する必要があるかもしれません。このフィールドは日本人名の並べ替えに使用されますが、 名前を見ている人がその発音を確認することもできます。
real name usage を強制しようとするときに、普通でない、または予期しない名前を ブロックしないでください。
名前が開発者の期待に合わないためにサービスの利用をブロックされた人々の例を見つけることは 難しくありません。real name usage を強制する予定がある場合、名前が珍しい、または予期しない構造を 持つ場合に、人々が実際の名前を検証できる仕組みを許容する必要があります。
人名を含む例を含む標準および標準関連文書では、グローバルな読者を反映するために 多様な名前を使用してください。特定の地域に固有の名前への偏りを避けてください。
多くの仕様は、ユーザーストーリーやユースケースなど、物語性を高める手段として個人名を使用する 例を提供します。セキュリティ仕様が一定の一貫性を提供するために "Alice" と "Bob" という名前を 使用するなど、慣行を持つグループもあります。システムやサービスを構築する際には包括性が重要な目標で あるべきであり、そのため、例を作る際に世界的に多様な名前を使用することが提案されています。 これは、私たちの技術の世界中のユーザーコミュニティを表すことを助け、仕様がグローバルなユーザーに より関連しているように見えるようにします。
ヨーロッパ起源の少数の名前だけではなく、世界中の異なる地域の人々を表す名前を選ぶようにしてください。 non-ASCII 文字を含む名前を選ぶことで、Unicode サポートやその他の国際化上の懸念がユーザーに 適用されることを実装者に思い出させる助けになる点にも注意してください。
文化およびジェンダー関連の問題を扱ううえで、完全に不可知な名前の集合は存在しません。 仕様作成者がより包括的な例を作成できるよう、この文書は多くの文化にまたがる名前の集合を提供します。 これらの名前は、おおよそ地域別に整理され、通常は国または言語を示しています。これらの地域内でさえ、 個人名の扱いには非常に多様な影響と慣行があることに注意してください。名前はまた、仕様作成者が 例を書くのを助けるために文化的なジェンダー関連付けによって分けられていますが、多くの名前は 特定のジェンダーに固有ではありません。
英語の例に他文化の個人名を挿入することは、世界各地で名前が文化的に使用される方法が非常に 異なることからも影響を受けます。たとえば、一部の文化では given name に加えて patronym/matronym の 使用が期待されます。または一部の文化では、より形式的な名前（例: "Herr Dürer" と 非公式な "Albrecht"）を好みます。
中国人は、family name も含めずに given name だけを使用することはほとんどありません。中国語で 例を書く場合、"exemplar name" ではなく、路人甲 のようなものを 見ることがあります（これは Person A を意味し、漢字の "Heavenly Stem" 序数を使っています。 Ready-made Counter Styles を参照）。例が使用される場合、それらには family name と given name の両方が 含まれます。中国語では family name が先に、given name の前に来ることを念頭に置いてください。
日本語では、丁寧さの段階に関連する複雑な選択があります。非常に非公式な状況では、
人は given name（Hiroshi）で呼ばれるかもしれませんが、通常は、
（失礼でない限り）-san や -sama などの title または suffix を含む
family name（例: Tanaka-san）で呼ばれます。その他の suffixes または titles も使用され、
たとえば senpai や sensei（年長者または非常に尊敬される人物に対して）、
あるいは shi（その人をよく知らない場合）があります。したがって、英語の例で
Suppose Hiroki wants to set up a... と言える場合でも、Suppose Tanaka-san wants to set up
a...
と読む方が文化的により適切である可能性があります。
次の表は Internationalization Working Group によってまとめられました。追加または修正のための 貢献や提案を歓迎します。
この名前の集合の目的は、一般に英語話者の読者に向けて書く仕様作成者を支援することです。 この集合は主に given names で構成されており、必要に応じて Latin script に翻字されています。 これらの名前は、多くの文化では実際には名前がそのように使用されないにもかかわらず、 非公式にも表記されています（"Ms. Jones" ではなく "Alice" など）。 仕様を翻訳する場合、対象読者に適した調整を行うべきです。
non-Latin-script の言語または文化から名前が取られている場合、名前が Latin script にまったく 限定されないことを思い出させるため、また non-Latin script の例を含めたい場合のために、 non-Latin 表記も提供されています。
この表は、ヘッダー行の △ または ▽ 矢印をクリックすることで並べ替えられます。
| 名前 △▽ | ネイティブ表記 △▽ | ジェンダー △▽ | 地域と注記 △▽ | 言語 △▽ |
|---|---|---|---|---|
| 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 | 西アジア; アラビア語; Latin script ではいくつかのヨーロッパ文化でも使用 | 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 |
数値のユーザー入力を解析する場合は、digit shaping（non-ASCII digits）を許容してください。
表示用に数値を整形する場合は、non-ASCII digits（digit shaping）の 使用を含め、文化的に配慮した表示を許容してください。
ユーザーへの表示のために項目へ自動的に連番ラベルを付ける機能 （番号付きリストを作成する場合など）を定義する場合は、ラベルのローカライズされた提示だけでなく、 さまざまな counting/listing systems または styles も許容してください。
この例は、CSS Counter Styles [css-counter-styles-3]、特にそれに付随する Ready-made Counter Styles [predefined-counter-styles] にあります。
email フィールド検証を定義する場合は、EAI（smtputf8）名を許容してください。
Localization [LTLI] により、 ユーザーは自分が選択した言語と locale でソフトウェアを利用できます。プロトコルおよび文書形式の仕様は、 エンドユーザーが期待する言語と書式設定をどのように提供するかを考慮する必要があります。
Natural language data values には、適切な提示を保証するために、localized messages が 提供されない場合でも、言語と基底方向が必要です。これには、API またはプロトコル内で人間が読める error messages やその他の internal messages が含まれます。[STRING-META] も参照してください。
API およびプロトコルは、すべての natural language messages および data fields について、言語および文字列方向のメタデータを含めるべきです。
特定の API またはプロトコルによって定義される、error messages を含むすべての natural language fields または messages は、ユーザーの優先 locale にローカライズされるか、その言語が利用できない場合は 適切な fallback または default とともに提供されるべきです。
API またはプロトコルの仕様は、ユーザーの locale がどのように決定されるかを 定義すべきです（これは language negotiation と呼ばれることがあります）。
仕様は、API またはプロトコル内の messages または errors について、特定の 既定言語を定義してもよいです。
仕様は、messages がすべての可能な、または利用可能なすべての locales で返されることを 要求する必要はありません。エンドユーザーの customer experience をローカライズ可能にするだけで十分です。 実装は、サポートする言語または locales を選択できます。
プロトコル、API、および文書形式は、サービスから caller へ人間が読める error または exception message を文字列として渡すためのフィールドを提供することがあります。一般に、 上で示したように、人間が読める messages または human-readable content を伝える natural language text は、言語および方向のメタデータと 関連付けられる必要があります。このメタデータがない場合、テキストの処理または表示が損なわれる 可能性があります。
仕様作成者が error または exception message を提供する意図は、多くの場合、ソフトウェア開発者へ debugging information を伝えることです。仕様作成者は、error または exception messages は end users に見られない、ソフトウェア開発者はこれらの messages がローカライズされないか 特定の言語（通常は英語）で表示されることを好む、あるいは error messages のローカリゼーションが 障壁になり得る他の「実用上の理由」がある、と仮定することがあります。たとえば、error の （通常は曖昧な）テキストで Web を検索する方が開発者にとって簡単である、という逸話があります。 これは message 自体が問題を十分に説明していないためです。このテキストを検索すると、開発者の 優先言語で、より有用な結果が得られる場合があります。
Error messages は messages であり、machines ではなく humans のためのものです。多くの場合、 error message は何が問題だったかについての追加情報をすべて含み、場合によっては、問題を修正する方法を caller に伝える他の方法がないため、caller が実際の end user にその message を表示する義務を負います （"Your credit card has expired"; "The value 10484977 is too large" [おっと、小数点を忘れた]; など）。こうした種類の messages のローカリゼーションは実際には良いことであり、アプリケーションによっては 義務ですらあるかもしれません。
API およびプロトコルは、errors のために言語に依存しない identifiers を 提供すべきです。
たとえば、おなじみの 404 のような HTTP result codes は、ユーザーがどの
error を受け取ったかを伝えたり、翻訳を調べたりするのに役立ちます。
Natural language error message fields が提供される場合、それらは任意であるべきであり、言語および方向のメタデータを含むべきです。
Natural language error message fields が提供される場合、可能であれば request について negotiated された user interface language と一致するべきです。
以下は、前回の公開以降の実質的な変更を要約したものですが、この素材は発展の過程にあるため、 なお大きく変動する可能性があります。これは、この文書を使用しない理由にはなりません。現時点で 含まれている内容は有用であり、不足点は報告または議論できます。
詳細については github commit log を 参照してください。
推奨事項のために古いレビューを見直す支援をしてくれた Addison Phillips に感謝します。
レビューまたは issue を通じて貢献したその他の人々には、次の人々が含まれます: Steve Atkin, Andrew Cunningham, Martin Dürst, Asmus Freytag, John Klensin, Tomer Mahlin, Chaals McCathieNevile, Florian Rivoal, Najib Tounsi. locale-neutral representation に関する一部の素材は、[DWBP] から 改変されました。
参照箇所: