問題タブ [bidi]

unicode-bidi プロパティの使用法を学ぶのに苦労しています。たとえば、ラテン アルファベット文字の単語形式に方向を設定し、値embedを unicode-bidi プロパティに割り当てると、単語は分離され、周囲のコンテキストに影響を与えないと考えました。ただし、以下のコードは、私が期待したものとは反対のことを行います。

「rtl」テキストが分離されているため、最初のものは右側の数字を示していると思いますが、2番目のものはそれを行います。

プロパティ unicode-bidi がアラビア語、ヘブライ語などの単語に役立つことは知っていますが、ここで何が起こるのだろうか。

Google と here を検索して、unicode-bidi の機能に対する確実な答えを見つけましたが、見つけられるのは「1 つの埋め込みレベルを提供する」だけで、十分に明確ではありません。

誰かがこのプロパティと、上記のコードで何が起こるかを説明できますか?

私はWPFアプリケーションを持っています。

数字と単語を含むヘブライ語の文章を表示したい。

私はUnicodeのbidiについて読み、次のようにそのための小さなコードを書きます:

今xamlで：

しかし、ここでわかるように、WPF ではサポートされていないようです。

負の数は適切に設計されていません..

編集：

リンクを提供してくれた Hans Passant に感謝します。

LRO と RLO の値を次のように変更します。

そして今、それは適切に設計されています。

ありがとう！

Canvas に右から左への Unicode 文字列を印刷したいと考えています。BidiMode プロパティなどを見つけることができません。

現在、文字列の末尾にある記号は、キャンバスに印刷されるテキストの最初の文字の前に表示されます。

右から左へのテキストを含む字幕ファイルの問題を修正しようとしています。参考までに、srt ファイルの形式は次のようになります。

例えば：

私がstackoverflowで見つけた解決策は、すべての行でも、3行目、7行目、11行目などでもないため、私の場合には機能しません。
「-->」を含む各行の後の最初の行 (たとえば、上記のサンプルの 3 行目と 7 行目) の前に、Unicode 文字「RIGHT-TO-LEFT EMBEDDING (U+202B)」を付けたいと思います。
理想的には、字幕行のバッチを区切る空白行の前の各行 (上記のサンプルの 3 行目と 8 行目など) に、Unicode 文字 "RIGHT-TO-LEFT MARK (U+200F)" をサフィックスとして付けたいと考えています。
たとえば awk や sed でそれを行う方法はありますか? ありがとうございました。
PS .: 右から左へのテキストを含むサンプル ファイルを次のリンクに置きました:
右から左へのテキストを含むサンプル srt ファイル

カスタム Android ビューでは、双方向の可能性があるいくつかのユーザー入力テキストをペイントしています。たとえば、ヘブライ語またはアラビア語と英語のテキストまたは数字が混在しています。テキストを描画するには、基本的にビューの Canvas、TextPaint、および StaticLayout を使用します。実際のコードはかなり複雑で散らばっていますが、テキストを描画する部分は次のようになります。

これは、LTR または RTL のみのテキストでは問題なく機能しますが、文字化けして表示される Bidi テキストでは機能しません。奇妙なことに、アラインメントを強制的に 0 にすると (結果として _paint.setTextAlign(Paint.Align.Left) になる)、通常は問題なく動作するように見えます (= 私がテストできる限り)。ただし、テキストに次のものが含まれている場合は、条件付きでアラインメントを 0 にします。 BiDi (または RTL) 文字が機能しません。Canvas、Paint、または StaticLayout のいずれかが状態を保持しているようです。

BidiFormatter を次のように使用してみました:

しかし、それは違いはありません (まだ文字化けしています)。

カスタムビューで（多くの）BiDiテキストを確実にペイントする方法はありますか? そして、すべてのテキストの配置を Paint.Align.Left に強制すると、問題が解決するように思われる理由が考えられます。これは、Android 4.0 以降、少なくとも 4.2 または 4.4 以降で動作することが望ましいです。前もって感謝します。

Character.getDirectionality を使用して、テキスト内の rtl chars をテストすることで、多かれ少なかれ機能するようになりました。

そして、その強制配置に基づいて左に (

これにより、RTL char を含むテキストは問題ありませんが、配置は固定 (中央) になります。

文字列書式設定コードの単体テストを作成しようとしています。フォーマット化された出力には、場合によっては双方向のテキスト、つまり左から右と右から左が混在するテキストが含まれる可能性があります。

Android デバイスまたはエミュレーターで実行した場合、LTR と RTL の入力と出力のすべての組み合わせに対して、出力が正しく見えることを経験的に確認しました。ただし、単体テストでこれをキャプチャするのに苦労しています。私のテストケースで、期待される出力を正しく指定する方法がわかりません。

たとえば、返された文字列が次のようにレンダリングされることをアサートしたいと思います。

-د.ك.123,456.78

つまり、グリフは次の順序で左から右に表示されます。

-

1

2

3

,

4

5

6

.

7

8

.

ك

.

د

^{(SO 編集ボックスでそれを正しいシーケンスに編集することさえどれほど大変だったか、あなたにはわかりません!)}

次のように、テストケースで標準の文字列比較方法を使用してみました。

しかし、テスト コードの期待される出力文字列のテキストが並べ替えられているため、これは失敗します。実際、ソースを表示するために使用するツール (Android Studio と Github-with-Chrome) に応じて、ソースでの表示も異なるため、正しいことをテストしているとは確信が持てません。

また、エディターでの混乱を避けるために、期待される出力値を段階的に構築しようとしましたが、内部で同じ文字列リテラルが構築されます。

論理的な順序ではなく、グリフの視覚的な順序を比較するにはどうすればよいですか? ここでAndroid はBidiFormatter役に立ちますか?

私は Android で RTL をサポートすることを検討しており、複数の Android OS バージョンをサポートするにはどれだけの労力が必要かを把握しようとしています。4.2 が限定的な双方向 (bidi) サポートを開始したことは知っています。そして、その前に、双方向のサポートははるかに困難だったことを私は知っています。しかし、どのようにそれはより困難ですか？これを経験したことがある場合、RTL/bidi のサポートに関して、Android のさまざまなバージョンの違いは何ですか? 新しいバージョンが登場すると何が利用可能になりますか?

バージョンの比較表の重要なポイントは、次のとおりです。どの時点で、どのバージョンの BIDI サポートに多大な労力が費やされ、その価値がないのでしょうか?

ご協力いただきありがとうございます！

ここにコードがあります

問題は、翻訳でテキストを逆にしたいので、「1% أضاف %2 للمجموعة」の代わりに、次のようにしたいことです。

なんらかの理由で、メモ帳でさえ、アラビア語は右から左に書かれるため、アラビア語の文の右端に %1 を置くことを許可していません。

これに対する回避策はありますか?

別の Web ページでテキスト方向のデフォルトを右から左 (RTL) またはその逆 (左から右 - LTR) に保存する方法があるかどうか疑問に思います。したがって、特定の Web サイトを開くと、テキストの方向は自動的に LTR または RTL になります。私はGoogle Chromeを使用しているので、プロパティを検索しようとしましたが、テキスト方向のデフォルトを保存するオプションが見つかりませんでした. テキストボックスのテキスト方向を自動的に変更し、入力テキスト言語に基づいてテキスト方向を自動的に設定するにはどうすればよいですか? Windows XP の言語設定でその他の質問と検索を行いましたが、探しているものが見つかりませんでした。助けてくれてありがとう。

アップデート：

「F10」ボタンを使用してテキストの向きを変更する「Lang Over 5」というプログラムを使用しています。しかし、それを使用して Web サイトにデフォルトのテキストの向きを保存することはできません。

PHP を使用してテキスト ファイル内にアラビア語のテキストを書きたいのですが、テキストを右から左に書く方法が見つかりませんでした。私は、この記事を見つけました 。しかし、このユニコード文字をphpで文字列に変換する方法がわかりません。このようなもので試しまし$content = "\u{202E}".$content."\u{202C}"たが、うまくいきませんでした。