右から左へ読み書きする言語のサポートと双方向のテキスト

右から左 (RTL) の言語サポートの領域では、同じ文字列での RTL テキストと左から右 (LTR) のテキストの組み合わせを考慮します。 この記事では、双方向テキストの問題とその処理方法について説明します。

右から左言語サポートの優れた例: Microsoft Word

右から左 (RTL) の言語サポートの領域では、同じ文字列での RTL テキストと左から右 (LTR) のテキストの組み合わせを考慮します。 この機能を正しく実行するプログラムの 1 つの例は、Microsoft Word です。 混合言語プレゼンテーションの正しい動作を理解するには、Word で検証を行うことができます。 問題は、ほとんどのソフトウェアは、データが実際に使用される方法を評価せずに、Unicode 標準を実装して双方向データを表示するだけであることです。 また、ユーザーが実際に必要とするインタラクティブな経験を提供しようとすることはありません。

Word を正しく理解し、適切なエクスペリンスを提供するには、Word ドキュメントの XML を調べます。 これは、Word が各文字を入力するために使用されるキーボードを追跡して (文字の実行と一緒に保存する)、各文字をキーボードに関連付けられている言語のメンバーとして扱うことを意味します。 したがって、文字にはその言語の動作の側面が与えられます。

数十億のトランザクションと数十億の文字を記録する場合がある財務プログラムで文字の方向を追跡することにより、各文字のコンテキストの情報を格納する場合、重要な取引および空間のオーバーヘッドを作成します。 したがって、この動作は特別な条件の場合のみ考慮されます。

双方向のテキスト

どちらも RTL 言語であるアラビア語とヘブライ語をサポートするために、RTL リーダーが自然な読み方でフォームとやりとりできるように、各フォームのコントロールには RTL の向きがあります。 ほとんどの場合、コントロールの RTL の向き(右から左)は予想通りに作動し、RTL ユーザーに期待するエクスペリエンスを提供します。 財務と運用アプリおよび最新のブラウザは RTL 方向をサポートし、アプリはその機能に準拠しています。 ただし、場合によっては、拡張可能なコントロール (カスタム コントロール) には、要素の方向を正しく位置付ける特別なコードが必要です。

この記事の参照ポイントは、標準のテキスト エントリ (Microsoft Dynamics AX 2012 の勘定科目名、説明、ユーザー名など) で主に使用される Win32 CEdit コントロールです。 HTML 入力コントロールの動作は、CEdit コントロールの機能に似ています。 したがって、財務と運用アプリにも同じ動作が適用されます。

CEdit コントロールは、Unicode 標準によって定義されている双方向テキスト管理のためのルールによって制御される Win32 コントロールです。 コントロールが同じ文字列内の RTL テキスト (アラビア語やヘブライ語など) と LTR テキストの両方をホストする場合に双方向のテキストは発生します。

この記事の例を評価するときは、フォームの方向 (右から左または左から右) に関係なく、提示されている実際のテキストは逆転、すなわち、「左右反転」しないことを覚えていてください。 英語のテキストは左から右、アラビア語/ヘブライ語のテキストは右から左へ常に読みます。 LTR および RTL テキストが組み合わさると、読者は、特定の向きの一連の文字の先頭に移動する必要があります。 たとえば、混合文字列が右から左に読み込まれると、個々の単語が次のように読み込まれる可能性があります。

–––––><––––– –––––><–––––

英語 アラビア語 英語 アラビア語

英語およびアラビア語/ヘブライ語テキストの組み合わせ: 双方向の問題

対応するキーボードの英語、アラビア語、ヘブライ文字の視覚的な表示 (文字) ははっきりと異なります。 ただし、これらの 3 つのキーボードではいくつかの記号も共有されます。 これらの記号には、数字、かっこ、大括弧、アンダースコアなどの書式設定文字が含まれます。 Unicode 双方向アルゴリズムによると、これらの文字が双方向の文字列で使用されている場合、右から左/左から右方向は、それらを囲む文字のコンテキストに依存します。 Unicode 標準 から:

メモ

Unicode 表示アルゴリズムは https://www.unicode.org/reports/tr9/ で見つけることができます。 (アルゴリズムのセクション 3.3.4 では、ニュートラルを配置する方法について説明しています。)

• 双方向性が弱いタイプの文字は、強い方向性を持つ他の文字への近接度に応じて方向性を決定します。
• ニュートラルな双方向型の文字は、周囲の強いテキストまたは埋め込みレベルのいずれかから方向性を決定します。

次のテーブルは、双方向の特徴タイプについて説明しています。

カテゴリ	種類	説明	一般的なスコープ
厳密	L	左から右	LRM、最も多いアルファベット、音節、ハン漢字、非欧州または非アラビア語の桁、…
厳密	LRE	左から右の埋め込み	LRE
厳密	LRO	左から右のオーバーライド	LRO
厳密	R	右から左	RLM、ヘブライ語のアルファベット、および関連する句読点
厳密	AL	右から左 (アラビア語)	アラビア語、ターナ語、およびシリア語のアルファベット、それらのスクリプトに固有のほとんどの句読点、…
厳密	RLE	右から左 (埋め込み)	RLE
厳密	RLO	右から左 (オーバーライド)	RLO
弱	PDF	方向の形式の表示	PDF
弱	EN	欧州番号	欧州の数字、東アラビア - インドの数字、…
弱	ES	欧州番号の区切り	プラス記号、マイナス記号
弱	ET	欧州番号ターミネーター	度記号、通貨記号、...
弱	AN	アラビア数字	アラビア語 - インド数字、アラビア数字および 3 桁の区切り文字、…
弱	CS	共通番号順序	コロン、コンマ、完全停止 (期間)、ノーブレーク スペース、…
弱	NSM	無間隔マーク	Unicode 文字データベースの Mn (Nonspacing_Mark) および Me (Enclosing_Mark) とマークされた文字
弱	BN	境界ニュートラル	明示的に他の型が与えられているものを除く、既定の無視できる、非文字、および制御文字
ニュートラル	B	段落区切り記号	段落区切り記号、適切な改行関数、上位レベル プロトコル段落の決定
ニュートラル	S	セグメントの区切り	タブ
ニュートラル	WS	空白	スペース、数字の間隔、行の区切り記号、フォーム フィード、一般句読点スペース、…
ニュートラル	オン	その他のニューとリアル	他のすべての文字、OBJECT REPLACEMENT CHARACTE を含みます。

双方向テキストの Unicode 標準の基本的な問題は、ユーザーの意図をキャプチャできないことです。 したがって、アルゴリズムは、同じ文字列内の文字を移動し、ユーザーが指定しなかった場所に置くか、不要にします。 この問題は、ユーザーがシステムに入力するデータが対応するソース文書と一致しない可能性があるため、会計システムや財務システムにとって問題となります。

前述のように、アラビア語、英語、およびヘブライ語のキーボードは同じ文字の一部を共有します。 ただし、場合によっては、入力するのに使用されたキーボードによってまたは文字の周囲のコンテキストと入力コントロールの方向によって、これらの文字が異なって配置されます。 これらの言語に依存しない文字には、コンマ、期間、かっこ、ハイフン、アンダースコアが含まれます。

場合によっては、同じ文字を表示するためのルールは言語によって異なります。 また、これらのルールは表示されるデータの種類に応じて変更できます。 この問題点の詳細については、この記事の後述の「問題: ハイフンを番号と同時に使用: 言語固有の動作」セクションを参照してください。

RTL モードで入力された文字が、LTR モードでフォームを表示したときに同じように表示されることを期待するユーザーもいます。 つまり、同じインストールまたは同じ会社の顧客には、ヘブライ語を使用するユーザーもいれば、英語を使用するユーザーもいる可能性があることが期待されます。

問題: アンダー スコア文字が数字と組み合わせて使用されました

説明: 123_456 は、ユーザーが 123_456 と表示したくても、456_123 と表示されます。

例: ユーザーはグループ化のためにアンダースコアを含む項目番号 (123_456 など) または仕訳帳名 (BA_Chk_Rev など) を入力する必要があります。

Unicode 標準と、ユーザーが金融プログラムで見たいものとの間には違いがあります。 一定の Word は、アラビア語とヘブライ語の両方に 456_123 として 123_456 を提示します。 この現象は、アンダースコア文字がグループ化メカニズムであるために発生します。 右から左に読むことのできる数字のグループに数字を分割します。

数字はアラビア語およびヘブライ語では左から右に読まれます。 組み合わせにかかわらず (RTL_LTR_RTL、LTR_RTL_LTR、Neutral_RTL、など)、「項目」番号は任意の方向または配置で、段落内に完全に同一に表示されるはずです。 この問題は、プレーン テキスト プログラムで解決するのは容易ではありません。 すべての顧客が認識しているのは、物理的な品目番号が (左から右に) 123_456 であることと、文字列がすべての言語で 123_456 と表示されることのみです。これにより、ユーザーに示される物理的な数字は、ユーザーが理解している物理的な数字と常に一致します。

コントロール動作: 既成のコントロールはいずれも目的の動作を提供しません。 Word も失敗します。

WPF RichTxt	Win32 CEdit	Win32 RichTxt	Word
無	無	無	無

回避策:

• 英語キーボードを使用する場合は、異なる区切り記号を使用します。 たとえば、123.456 または 123/456 を入力します。
• ヘブライ語キーボードを使用する場合は、異なる区切り記号を使用します。 たとえば、123.456を入力します。 ヘブライ語キーボードで、スラッシュ (/) は ピリオド (.) を生成します。

推奨: 既成のコントロールはいずれも要求された動作を提供しません。 1 つの方法は、この方向のフォーマットが必要とするフィールドを識別し、それらのフィールドをデータ入力の LTR としてフラグを設定することです (右揃え表示のために)。 プログラムは、フィールドにこのビヘイビアーが必要であることを自動で判断できません。 したがって、RTL/LTR フラグを公開すると、カスタマイザーは目的のフィールドを目的の動作に変更できます。 この方法はこの特定のシナリオを有効にしますが、RTL および LTR 言語の組み合わせで文字を使用してシナリオを拡張した場合に、その他の問題が導入されることを理解しておくことは重要です。 もう 1 つの代替としてはアンダー スコア文字と数字が同時に使用される場合、基本的な動作についてユーザーを教育する必要があります。 アンダー スコア文字と番号が必要なとき、ユーザーは解決策を使用して、目的の表示動作を取得することができます。

メモ

英語と右から左へ読み書きする言語を組み合わせる場合に、アンダースコア文字は問題になりません (パターン: RTL_LTR_RTL)。 したがって、入力に数字/テキスト/アンダースコア文字が含まれているときにコントロールを LTR に強制すると、その動作は期待どおりになりません。 ユーザーは、RTL テキストを入力するとき、アンダー スコアを使用するたびにそのあと、カーソルを手動で再配置する必要があります。 ただし、番号/テキスト/アンダースコア文字の使用に対する動作は期待どおりになります。

ヘブライ語: קשגכ_english_יקנקרק

アラビア語: شقلاهؤ_english_شقشلاهؤ

問題: ハイフンが数字と組み合わせて使用されました: 言語固有の動作

説明: ヘブライ語では左から右、アラビア語では右から左が予想されます。

例: アラビア語とヘブライ語の数字を含む項目名は、数字と一緒に使用すると、ハイフンを異なる方法で扱います。 アラビア語キーボードはハイフンを RTL 文字として扱いますが、ヘブライ語キーボードは LTR 文字として処理します。 したがって、使用されたキーボードに応じて、同様の型付き文字列を別々に提示する必要があります。 読者の中には、関係者の会議からこの例をよく理解するようになる人がいます: 1-2-3-a-b-c

アラビア語: Dynamics AX 2012 で必要な動作は正しいです。 1-2-3-ش-لال-ؤ

ヘブライ語: Dynamics AX 2012 で必要な動作が正しくありません。 1-2-3-ש-נ-ב

Unicode 標準では、特定の言語またはキーボードに固有の動作は規定されていません。 代わりに、基本的な双方向の動作を提供し、右から左へ読み書きする文字としてハイフンを処理します。 したがって、アラビア文字列は正しく表示されますが、ヘブライ文字列は正しく表示されません。

コントロール動作: WPF RichTxt コントロールは、各言語の正しい目的の動作を生成します。

WPF RichTxt	Win32 CEdit	Win32 RichTxt	Word
有	無	無	有

ヘブライ語ユーザーのための回避策:

• 番号間にハイフンを入力しないでください。 たとえば、ヘブライ語キーボードで 1 2 3-A-B-C をタイプすると、右から左へ C-B-A-3 2 1 として表示されます。 ABC 注文が右から左へ読む言語であるヘブライ語で正しいと想定してください。 英語の ABC テキストは、デモンストレーションのためにここで取り消されます。
• 数字の間に異なる区切り文字を使用します。 たとえば、ヘブライ語キーボードで、スラッシュ (/) は ピリオド (.) を生成します。

推奨: このパターンは、項目名に数字またはハイフンを使用したいヘブライ語のユーザーのための問題です。 したがって、例外が存在するため、グローバルな解決策は適切ではない可能性があります。 電話番号、社会保障番号、およびその他のソースドキュメントの ID 番号は常に左から右に読んみます。

WPF RichTxt コントロールは、厳密なガイダンスに従って必要な動作を提供します。 ただし、この動作が常に目的の動作であることは明確ではありません。 つまり、電話番号、米国社会保障番号などは、言語の向きに関係なく、常に左から右の順に読み取って表示する必要があります。 代わりに、この動作を有効にする必要のあるフィールドを指定することもできます。 プログラムは、フィールドにこのビヘイビアーが必要であることを自動で判断できません。 したがって、ユーザーが「構造化された書式設定」を指定できるように、コントロールの記述プロパティを使用する必要があります。 これらのアプローチのいずれも達成できない場合は、ハイフンを数字と一緒に使用するときの基本的な動作について、ヘブライ語のユーザーを訓練する必要があります。 番号間のハイフンを省略することにより、上記の回避策のいずれかを使用して、目的の表示動作を得ることができます。

ヘブライ語の例: (アラビア語とヘブライ語のヘブライ語での例の両方に対する有効な操作と正しい操作)

パターン: 1 番目 (עברית) ハイフン 2 番目 (英語) ハイフン 3 番目 (שלום) ハイフン 4 番目 (Hello)

正解: עברית 英語 שלום こんにちは

パターン:

1. 最初 (英文字) ハイフン 2 つ目 (ヘブライ文字) ハイフン
2. 最初 (ヘブライ文字) ハイフン 2 つ目 (英文字) ハイフン

必要に応じて、RTL フォームが表示されます。

1. ש--a
2. -aש-

電話番号に関する例外: 多くの場合、アラビア語のユーザーは電話番号にハイフンを使用する必要はありません。国際電話番号では、数字を区切るのにハイフンを使用することがほとんどないからです。 ハイフンの動作の基本的な変更 (たとえば、WPF RichTxt コントロールの使用を導入するなど) は、アラビア語のユーザーに電話番号が間違って表示されます。

電話番号は、常に左から右に読み取られ、多くの場合ハイフンがあります。 電話番号は、左から右の文字列が示される表示メソッドを通じてグリッドに表示される場合、正しく表示されることがあります。

現在、番号とハイフンを使用して電話番号を入力すると、701-225-2188 などの正しい表示が生成されます。

かっこを含む米国のパターンを使用しようとすると、電話番号に問題があります。

アラビア語/ヘブライ語/英語 (必要に応じて):(701)225-2188

アラビア語 (実績): )701(225-2188

ヘブライ語 (実際): )701(225-2188

推奨: コントロールの RTL フラグ、または電話番号の拡張データ型を公開します。 カスタマイザーは、LTR モードに、コントロールを強制できます。 この方法により、ユーザーは必要な順序で値を入力できます。

問題: 左から右へ読み書きするテキストが右から左へ読み書きする入力の中立的な文字と組み合わされました

説明: 英語のテキストは、かっこやその他の中立文字と組み合わされます。

例: 会社名と会社の略称 (例: 「Dynamics (DAT)」)

一般的な例として、会社名の後に丸かっこで囲まれた会社の略称が続きます。 ここでは、「Dynamics (DAT)」は、「(Dynamics (DAT」で表示されます。 この現象は、閉じ括弧が 2 つの英数字で囲まれていないために発生します。 したがって、かっこは RTL 文字として扱われます。 右から左へ読み書きする閉じかっこに変更され、(右から左方向での) 文字列の末尾に移動します。

コントロール動作: いずれのコントロールも目的の動作を提供しません。

WPF RichTxt	Win32 CEdit	Win32 RichTxt	Word
無	無	無	有

WPF RichTxt コントロールには、文字列の最初の文字に従ってテキストの書式を設定しようとするフラグがあります。 アルゴリズムはこの問題を解決する必要がありますが、されていません。

回避策: 英語を使用する場合はグループ化に脆弱なあるいは中立の文字を使用しないでください。 たとえば、「Dynamics DAT」を使用します。

推奨: いずれのコントロールも目的の動作を提供しません。 脆弱なあるいは中立文字が英語のテキストと共に使用される場合、基本的な動作についてユーザーを教育する必要があります。 英語の文字が各側に表示されない限り、脆弱なあるいは中立的な文字は使用しないでください。