Transliterator クラス

定義

[Android.Runtime.Register("android/icu/text/Transliterator", ApiSince=29, DoNotGenerateAcw=true)]
public abstract class Transliterator : Java.Lang.Object

[<Android.Runtime.Register("android/icu/text/Transliterator", ApiSince=29, DoNotGenerateAcw=true)>]
type Transliterator = class
    inherit Object

継承

Object

JavaObject

Object

Transliterator

属性

RegisterAttribute

注釈

Transliterator は、ある形式から別の形式にテキストを表記変換する抽象クラスです。 最も一般的な種類の音訳器は、スクリプト、またはアルファベットの表記変換です。 たとえば、ロシア語からラテン語への音訳では、キリル文字で書かれたロシア語のテキストが、音素に同等のラテン文字に変更されます。 ロシア語から英語<>/em<>しません。 音訳は、翻訳とは異なり、単語や文の意味を参照せずに文字に対して動作します。

スクリプト変換は最も一般的な用途ですが、表記変換では実際には、より一般的なタスク クラスを実行できます。 実際、 Transliterator では、入力テキストのセグメントを新しいテキストに置き換えることを指定する非常に一般的な API を定義します。 この変換の詳細は、 Transliteratorのサブクラスによって完全に決定されます。

<b>Transliterator はステートレスです</b>

Transliterator オブジェクトは <em>stateless</em>; であり、 transliterate()の呼び出し間に情報は保持されません。 その結果、スレッドは同期せずに表記変換子を共有する可能性があります。 これにより、表記変換操作の複雑さが制限されているように見える場合があります。 実際には、サブクラスは、他の置換が不可能であることが判明するまでテキストの置換を遅らせ、複雑な音訳を実行します。 つまり、 Transliterator オブジェクトはステートレスですが、ソース テキスト自体は必要なすべての情報を具体化し、遅延操作によって任意の複雑さが可能になります。

<b>バッチ変換</b>

表記変換を実行する最も簡単な方法は、既存のテキストの文字列に対してすべて一度に実行することです。 これは、 <em>batch</em> 音訳と呼ばれます。 たとえば、文字列 input と音訳 tを指定すると、呼び出し

<blockquote>String result = t.transliterate(input); </blockquote>

は、それを表記変換し、結果を返します。 その他のメソッドを使用すると、クライアントは、帯域外情報 (テキスト スタイルなど) を保持するために、文字列の代わりに部分文字列を表記変換したり、 Replaceable オブジェクトを使用したりできます。

<b>Keyboard 表記変換</b>

<em>keyboard</em>、または増分表記変換が多少関係しています。 これは、ソース (通常はユーザーのキーボード) から一度に 1 文字ずつ、または他の断片的な方法で到着するテキストの音訳です。

キーボード表記変換では、 Replaceable バッファーにテキストが格納されます。 テキストが挿入されると、可能な限りその場で音訳されます。 つまり、バッファーの内容を表示する GUI では、新しい文字が到着するたびに変更されるテキストが表示される可能性があります。

単純なルールベースの表記変換を考えてみましょう。

<blockquote> th&gt;{theta}<br> t&gt;{tau} </blockquote>

ユーザーが "t" を入力した場合、次の文字が 'h' かどうかを確認するために表記変換子が待機しているため、何も起こりません。 これを解決するために、出力文字列に '|' でマークされたカーソルの概念が導入されています。

<blockquote> t&gt;|{tau}<br> {tau}h&gt;{theta} </blockquote>

ユーザーが 「t」と入力すると tau が表示され、次の文字が 'h' の場合、tau は θ に変わります。 これは、 transliterate()の呼び出し間でカーソル位置 (カーソル位置とは関係なく、GUI では非表示) を維持することによって実現されます。 通常、カーソルは挿入ポイントと一致しますが、上記のような場合は、カーソルがカーソルの前に置きます。

キーボード表記変換メソッドは、カーソル、開始、制限など、 transliterate()の呼び出しごとに更新される 3 つのインデックスのセットを保持します。 これらのインデックスはメソッドによって変更され、Position オブジェクトを介して渡され、渡されます。 startインデックスは、表記変換で見る部分文字列の先頭を示します。 テキストがコミットされると進みます (ただし、コミットされたインデックスではありません。 cursor)。 前述の cursor インデックスは、表記変換が最後に停止した時点をマークします。最後に達したため、または可能な入力の間であいまいさを解消するためにより多くの文字が必要だったためです。 cursorは、規則によって明示的に設定することもできます。 cursorインデックスの前の文字は固定されます。この入力シーケンス内の今後のキーボード表記変換呼び出しでは変更されません。 limit インデックスに新しいテキストが挿入されます。このインデックスは、表記変換によって検索される部分文字列の末尾を示します。

キーボード表記変換は、より多くの文字が到着することを前提としているため、操作は保守的です。 明確に変換できる場合にのみ表記変換されます。 それ以外の場合は、より多くの文字が到着するまで待機します。 ユーザーが何らかの入力終了操作を実行したために、今後予定されている文字がなくなったことをクライアント コードが認識した場合は、保留中の音訳を完了するために finishTransliteration() を呼び出す必要があります。

<b>Inverses</b>

表記変換子のペアは、相互に逆になる場合があります。 たとえば、表記変換 <b>A</b> が Unicode 値をインクリメントして文字を表記変換する場合 (つまり、"abc" ->"def")、および音訳 <b>B</b> は文字値をデクリメントし、 <b>A</b> は <b>B</b> の逆になります。 複合表記変換で <>b<AA>/b< を b>B</b> で構成した場合、結果は ID 表記変換子、つまり入力テキストを変更しない表記変換子になります。

TransliteratorメソッドgetInverse()、存在する場合は表記変換子の逆関数を返し、それ以外の場合はnull返します。 ただし、getInverse()の結果は、通常、真の数学的逆<></em>になります。 これは、真の逆表記変換器の作成が困難であるためです。 たとえば、文字 'A' を 'B' に変換する <b>AB</b> と、'B' を 'A' に表記変換する <b>BA</b> という 2 つの表記変換を考えてみましょう。 これらは正確な逆であると思われるかもしれません。

<blockquote>"A" x <b>AB</b> ->"B"<br> "B" x <b>BA</b> ->"A"</blockquote>

ここで、'x' は音訳を表します。 ただし、

<blockquote>"ABCD" x <b>AB</b> ->"BBCD"<br> "BBCD" x <b>BA</b> ->"AACD"</blockquote>

したがって、<b>AB</b><b>BA</b> は ID ではありません。 ただし、 <b>BA</b> は、 <b>AB</b> 逆であると考えられる場合があり、 <b>AB</b>.getInverse() が正当に <b>BA</b>を返す可能性があります。

<b>Filtering</b>

各表記変換にはフィルターがあり、フィルターによって選択された文字に対する変更が制限されます。 フィルターは、変更された文字のみに影響します。フィルター外の文字は、フィルターのコンテキストの一部のままです。 たとえば、次の例では、'x' がフィルターで除外され、y に変換されない場合でも、'a' の変換に影響します。

String rules = "x > y; x{a} > b; ";
            Transliterator tempTrans = Transliterator.createFromRules("temp", rules, Transliterator.FORWARD);
            tempTrans.setFilter(new UnicodeSet("[a]"));
            String tempResult = tempTrans.transform("xa");
            // results in "xb"

<b> ID と表示名</b>

表記変換子は、短い識別子文字列または <em>ID</em> によって指定されます。 ID は <em>source-destination</em> の形式に従います。ここで、 <em>source</em> は置き換えられるエンティティを表し、 <em>destination</em> はエンティティの置換 <em>source</em>を記述します。 エンティティは、スクリプトの名前、特定の文字シーケンス、または表記変換の変換に使用されるその他の何かである場合があります。 たとえば、ロシア語からラテン語への音訳は、"Russian-Latin" という名前になります。 キーボード エスケープ シーケンスから Latin-1 文字への表記変換には、"KeyboardEscape-Latin1" という名前を付ける場合があります。 慣例により、システム エンティティ名は英語で、単語の最初の文字は大文字になります。ユーザー エンティティ名は、ダッシュが含まれていない限り、任意の形式に従うことができます。

プログラム ID に加えて、表記変換オブジェクトには、ユーザー インターフェイスでのプレゼンテーションの表示名があり、 #getDisplayNameによって返されます。

<b>Composed 表記変換子</b>

「ラテンギリシャ語」のような組み込みのシステム表記変換に加えて、組み込みの <em>composed</em> 音訳器もあります。 これらは、2 つ以上のコンポーネント表記変換子を作成することによって実装されます。 たとえば、スクリプト "A"、"B"、"C"、および "D" があり、それらのすべてのペア間で音訳する場合は、"A-B"、"A-C"、"A-D"、"B-A",...,、"B-A"、"D-B"、"D-C" の 12 個の表記変換を記述する必要があります。 すべてのスクリプトを中間スクリプト "M" に変換できる場合は、12 個のルール セットを書き込む代わりに、"A~M"、"B~M"、"C~M"、"D~M"、"M~A"、"M~B"、"M~C"、"M~D" の 8 つを記述するだけで済みます。 (これは大きな勝利のようには思えないかもしれませんが、本当に2<em>n</em> 対です。 <em>n</em>² - <em>n</em>,そのため <em>n</em> が大きくなると、ゲインが大きくなります。9 つのスクリプトでは、18 と 72 のルール セットが異なっています。大きな違いがあります)。ここでは、スクリプト区切り記号に "-" ではなく "~" を使用します。これは、指定された表記変換子が、そのまま使用されるのではなく、他のユーザーと構成されることを示します。

構成済みの表記変換子は、通常どおりにインスタンス化できます。 例えば、システム音訳器"Devanagari-Gujarati"は、"Devanagari~InterIndic" として内部的に構築された音訳器です。InterIndic~Gujarati". この音訳器がインスタンス化されると、外部には標準の音訳器のように見えます (例: getID() は "Devanagari-Gujarati" を返します)。

<b>Rule 構文</b>

一連のルールによって、翻訳の実行方法が決まります。 ルール セット内のルールはセミコロンで区切られます(';')。 リテラル セミコロンを含めるには、先頭に円記号 ('\') を付けます。 Unicode Pattern_White_Spaceは無視されます。 行の最初の空白以外の文字が '#' の場合、行全体はコメントとして無視されます。

ルールの各セットは、2 つのグループで構成されます。1 つは前方、1 つは逆になります。 これは、適用されない規則です。1 方向のルールを省略すると、その方向の翻訳によってソース テキストが変更されないという結果になります。 また、対称変換には双方向の順逆ルールを指定できます。

注: 表記変換規則の構文のもう 1 つの説明は 、「UTS #35 の変換ルール構文: Unicode LDML」セクションで入手できます。 ルールは、←と→と↔矢印記号を使用してそこに表示されます。 ICU では、これらと同等の ASCII シンボル < の両方がサポートされます。と >および <>。

Rule ステートメントは、次のいずれかの形式になります。

<dl><dt>$alefmadda=\\u0622;</dt><dd><strong>Variable definition.</strong> 左側の名前には、右側のテキストが割り当てられます。 この例では、このステートメントの後に、左側の名前のインスタンス 、>$alefmaddaは Unicode 文字 U+0622 に置き換えられます。 変数名は文字で始まる必要があり、文字、数字、およびアンダースコアのみで構成されます。 大文字と小文字が区別されます。 名前が重複すると例外がスローされます。つまり、変数を再定義することはできません。 右側には、任意の長さの整形式のテキストを含め、テキストがまったく含まれていない場合があります (>$empty=;>)。 右側には、埋め込まれた UnicodeSet パターン (例: >$softvowel=[eiyEIY]>.</dd><dt>ai>$alefmadda;</dt><dd><strong>Forward translation rule.</strong> このルールは、前方表記変換を実行するときに、左側の文字列が右側の文字列に変更されることを示します</dd><dt>ai<$alefmadda;</dt><dd><strong>Reverse translation rule.</strong> この規則では、逆音訳を実行するときに、右側の文字列が左側の文字列に変更されることを示します。</dd></dl>

<dl><dt>ai<>$alefmadda;</dt><dd><strong>双方向翻訳ルール.</strong> この規則では、前方表記変換を実行するときに右側の文字列が左の文字列に変更され、逆音訳を実行する場合はその逆が示されます。</dd></dl>

変換ルールは、 <em>match パターン</em> と <em>出力文字列</em>で構成されます。 一致パターンはリテラル文字で構成され、必要に応じてコンテキストの前に、必要に応じてコンテキストが続きます。 リテラル パターン文字などのコンテキスト文字は、表記変換されるテキスト内で一致する必要があります。 ただし、リテラル パターン文字とは異なり、出力テキストに置き換えられるわけではありません。 たとえば、パターン >abc{def}>は文字 >def>前に >abc>一致が成功した場合は 〗。 一致が成功した場合は、>def>は置き換えられますが、>abc>。 最後の '}' は省略可能であるため、>abc{def>は >abc{def}>。 もう 1 つの例として、>{123}456>(または >123}456>)リテラル パターン >123>の後に >456>。

正逆ルールの出力文字列は、リテラル パターン文字を置き換える文字で構成されます。 出力文字列に文字 '|' が含まれている場合は、置換後の <em>cursor</em> の場所を示します。 カーソルは、次の置換 (ある場合) が適用されるテキスト内のポイントです。 通常、カーソルは置換テキスト内に配置されます。ただし、実際には特殊文字 ' を使用して、前置コンテキストまたは次のコンテキストに配置できます。

Javaドキュメント。

このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。