この問題への通常のアプローチは、マッピングのリストを使用することです (通常、リストは 3 つより長くする必要はありません。あなたの場合は 2 つです)。各マッピングは文字をシーケンス ポイントにマップします。[注3]あなたの例では、
primary: secondary:
A -> 0 A -> 0
Á -> 0 Á -> 1
B -> 1 (irrelevant)
C -> 2
D -> 3
E -> 4
...
T -> 20
U -> 21
V -> 22 V -> 0
W -> 22 W -> 1
X -> 23
...
比較アルゴリズムは基本的に、最初に単語内の各文字をマッピング 1 を使用して変換し、それらが同じでない場合はそれを比較として使用します。それらが同じである場合は、mapping2 (など) を使用して繰り返されます。
すべての言語がそれほど単純であるとは限らないため、さまざまなバリエーションがあります (たとえば、パス 2 で文字列を逆にする場合があります)。
翻訳の連結で構成される比較キーを作成することによって、同じ効果を達成できることに注意してください。多くの比較を行う場合は、このキーをキャッシュすることで成功する可能性があります。その場合、「無関係」の最初のマッピング以外のマッピングで特別な値を使用します。関係のないコードはすべて省略できるため、多くの場合、比較キーがかなり短縮されます。
たとえば、あなたの例では(ただし、マッピングシーケンス全体を入力するのは面倒なので大文字だけです)、最初のマッピングを使用して VATANEN を変換[22, 1, 20, 1, 15, 5, 15]
し、2番目のマッピングを使用してに変換し[0, 0, --, 0, --, --, --]
ます。WATANEN は[22, 1, 20, 1, 15, 5, 15]
、最初のマッピングと 2 番目のマッピングで (まったく同じ) になり[1, 0, --, 0, --, --, --]
ます。--
[注 1] を削除すると、比較キーは次のようになります。
VATANEN: [22, 1, 20, 1, 15, 5, 15, 0, 0, 0]
VÁTANEN: [22, 1, 20, 1, 15, 5, 15, 0, 1, 0] (if there were such a place)
WATANEN: [22, 1, 20, 1, 15, 5, 15, 1, 0, 0]
VIRTANEN: [22, 9, ...]
これは、3 つ以上の変換テーブルに拡張できます。
たとえば、多くのアプリケーションは大文字と小文字を区別しない並べ替えのようなことを行いたいと考えていますが、他に違いがなければ文字の大文字と小文字が違います (英語では、これは通常、すべて小文字の単語の前に大文字の単語を配置することを意味します)。 、しかしどちらのオプションももっともらしいです。)
したがって、フィンランド語の場合、3 番目の変換テーブルを追加して、すべての大文字を 0 に変換し、すべての小文字を 1 に変換し、他のすべての文字を変換しないようにすることができます。いくつかの連結された翻訳:
-------primary--------- --2ary- ------tertiary-----
VÁTANEN: [22, 1, 20, 1, 15, 5, 15, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0]
Vátenen: [22, 1, 20, 1, 15, 5, 15, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1]
WATANEN: [22, 1, 20, 1, 15, 5, 15, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0]
この順序が「正しい」かどうかは、まったく明らかではありません。実際、公式の言語的権威を持つ言語を除いて、ほとんどの言語にとって「正しい」が何を意味するのかは明らかではありません。[注 2] したがって、上記はマルチレベル エンコーディングの例として考えるべきであり、アルファベット順の決定的なガイドではありません。この場合、3 次コードは 1 ビットだけで構成されますが、(オランダ語のように) いくつかの文字に対して 3 つのケースがある言語がまだ存在する可能性があります。
上記のスキームは、注意して追加するのはかなり簡単ですが、digraphs と trigraphs を考慮していません。(一次順序、場合によっては二次および三次でも、有字グラフは両方の文字に対して単一のコードを持つ必要があります。) スペイン語以外のプログラマーの間で一般に信じられていることとは反対に、1994 年以来、スペイン語はこの例ではありません。ほぼ 20 年前、RAE が「ch」を以前のように「c」と「d」の間ではなく、「cg」と「ci」の間でアルファベット順に並べることを布告したときです。一部のオランダ語話者はいまだに 'ij' と 'y' を一緒に見つけることを期待しており、ハンガリー人はアルファベットを構成する複雑な連字と連字の集合を今でも尊重しているかもしれませんが、全体として、アルファベット順の複雑な機械的スキームは消滅しつつあります。
[注 1]: エンコーディングの二次部分は、一次部分が同一である単語のペアに対してのみ参照されるため、「無関係な」二次コードを挿入する必要はありません。二次コーディングに無関係と見なされる文字は、一次同等クラスのすべての単語でそのように見なされるため、二次コーディングから除外することができます。同様に、上記で行ったように、さまざまな主要な等価クラスでコードを再利用することは正当です。[v, w] は [0, 1] であり、[a, á] も同様です。明らかに、あいまいさの可能性はありません。その結果、二次エンコーディングは、シーケンス長とビット長の両方で非常に短くなる可能性があります。
[注 2]: 英語にはそのような本体はありません。スペイン語のものはReal Academia Españolaですが、アクセントがアルファベット順に考慮されていないという簡潔な観察を除けば、私の本棚にある RAE のどの出版物にも正確な照合規則は見つかりませんでした。しかし、RAE の辞書は、少なくとも私が考えることができる 2 つのケース (パパ/パパとサバナ/サバナ) では、一貫して同じ文字のアクセント付きの単語の前にアクセントのない単語を配置しているようです。
[注 3] もちろん、オリジナルも追跡する必要があるため、何らかの方法で文字列に比較キーを付ける必要があります。2 つの文字がすべてのマッピングで同じ変換を持たない限り、比較キーをキーとして使用する単純なハッシュ テーブルでこれを行うことができます。