これは一種の好奇心です。多言語のWebアプリケーションで作業しているときに、ブロック要素の末尾にある句読点(!?。;、)などの特定の文字が、書き込み方向が右から左の場合ではなく、先頭に配置されているかのようにレンダリングされることに気付きました。 (私が話さない特定のアジア言語の場合のように)。
言い換えれば、文字列
Hello, World!
としてレンダリングされます
!Hello, World
direction: rtl
でdivブロックに配置された場合
これは、テキストが2つの部分に分割され、異なる色が与えられている場合にさらに明白になります。最後のテキストの連続したチャンクは、2つの別々の領域にレンダリングされます。
この振る舞いのポイントは何ですか?これは、ブラウザによって自動的に処理される(すべて?)右から左に記述する言語の特性であるに違いないと思います。したがって、気にする必要はありませんか。
その理由は、感嘆符「!」があるためです。 BiDiクラスO.N. (「その他の中立」)。これは、周囲のテキストの方向性に効果的に適応することを意味します。したがって、この例では、テキストの左側の前に配置されます。これは、右から左に書かれた言語では非常に正しいです。終了句読点は、end、つまり左側に表示されます。
通常、右から左に書かれる言語のテキストには、CSSコードdirection: rtl
、またはできればHTML属性dir=rtl
を使用します。彼らにとって、この振る舞いは解決策であり、問題ではありません。
代わりに、テーブルの列を右から左に配置するなどの特殊効果のためだけにdirection: rtl
またはdir=rtl
を使用する場合は、その影響を考慮する必要があります。たとえば、テーブルの場合、テーブルの各セルの方向をltr
に設定する必要があります(主に右から左のテキストとしてレンダリングする場合を除く)。
たとえば、アラビア語のテキストのブロック内に英語の文が引用されている場合は、英語のテキストを含む要素の方向性をltr
に設定する必要があります。
<blockquote dir=ltr>Hello, World!</blockquote>
同様のケース(英語のテキスト内にアラビア語がある場合)は、W3Cドキュメントのユースケース6として説明されています bidiアルゴリズムとインラインマークアップについて知っておく必要があること (ただし、いくつかの奇妙な点があります。 W3Cの推奨事項に対して、引用されたテキストにcite
マークアップを使用します)。
この動作を修正したい場合は、LRM文字を追加してください‎
最終的には。これは非=印刷文字です。
受け入れられた答え https://stackoverflow.com/a/20799360/47742 値のマークアップ/ CSSを制御できる場合は機能し、HTMLを制御できない場合は、次のアプローチが機能する可能性があります。
ページがRTLまたはLTRのどちらでレンダリングされるかわからないが、一部のテキストが間違いなくLTR(つまり、英語のみ)である場合は、値をLRE/PDFマークでラップして、それがLTR領域であることを示すことができます。テキストは、ページのLTRまたはRTLの方向に関係なく、LTRでレンダリングされます。
これは、ページに表示される正確なマークアップを変更せずにテキストをレンダリングしようとするコードがある場合に機能します。つまりネストされた子コンポーネント(またはサーバー側)の「曲のタイル」または「会社名」フィールドの値を、周囲のHTML要素を制御する機能なしでレンダリングします。
テキストにマークを追加するこのアプローチおよび同様のアプローチ(この質問の LRM提案 など)の1つの欠点は、結果のHTMLページからそのような値をコピーして貼り付けると、通常はマークが保持されますが、表示されません/ゼロ幅。ほとんどの場合、それがあなたにとって問題であるかどうかを検討することは問題ありません。
おおよそのサンプルコード(一部の企業では、最後に「Inc.」があり、RTLページでそのままレンダリングすると最初にドットが表示されます):
// comanyName = "Alphabet Inc." - really likes dot at the end including RTL
if(stringIsDefinitelyAscii(companyName))
{
companyName = "\u202A" + companyName + "\u202C"
}
return companyName;
LRE/PDFシンボルの詳細については、 https://unicode.org/reports/tr9/#Explicit_Directional_Embeddings :を参照してください。
LRE U + 202A左から右への埋め込み次のテキストを左から右への埋め込みとして扱います。
PDF U + 202C POP DIRECTIONAL FORMATTING最後のLRE、RLE、RLO、またはLROのスコープを終了します。
文字列にRTL文字があるかどうかを判断するためのいくつかのアプローチは、 文字が右から左への言語に属しているかどうかを検出する方法? 、 JavaScript:文字がRTLであるかどうかを確認する方法?)にあります。 、 文字列に右から左への文字が含まれているかどうかを検出する方法は? 。
これは、なぜこれが起こるのかという推測にすぎません。
私の推測では、direction: rtl
プロパティは、句読点にも影響を与える「双方向性」現象を追加します。これは、関連する句読点が行の先頭に移動されるアラビア語またはヘブライ語のスクリプトに使用されます。
ソース: http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131126/#text-direction
しかし、なぜ最後に単語があるのですか?
私の推測では、このユニコードは、有効になるサポートされている言語の1つとは見なされていません。
ご覧のとおり、アラビア語のテキストは有効です
つまり、元々はアラビア語、ヘブライ語、またはその他の「混合言語」を対象としており、最後の句読点はサポートされているUNICODEの1つとしてのみ表示され、Word自体はサポートされている言語のUNICODEの1つではなかったためです。