問題タブ [unicode-normalization]

IPA 文字列にスペースを挿入しようとしています。たとえばɔ̃wɔ̃tɨ 、ɔ̃ w ɔ̃ t ɨ. 分割/結合を使用することが私の最初の考えでした:

結果を調べて分かったのは、分音記号付きの文字は実際には 2 文字としてエンコードされていることです。いくつかの調査の後、UnicodeUtils モジュールを見つけ、each_grapheme メソッドを使用しました。

逆ブレーブマークを除いて、これはうまくいきました。コードは に変わり̑aます̑ a。UnicodeUtils.nfc正規化 ( 、 )を試みUnicodeUtils.nfdましたが、役に立ちませんでした。メソッドがこの特定の分音記号で問題を抱えている理由はわかりませんがeach_grapheme、gedit では、チルダやアクセントなどとは対照的に、breve も別の文字として扱われていることに気付きました。私の質問は次のとおりです。正規化の簡単な方法があります。つまり、 と のLatin Small Letter A組み合わせCombining Inverted BreveをLatin Small Letter A With Inverted Breve?

「大文字と小文字を区別しない」正規化された形式の Unicode テキストを生成する必要がある C プロジェクトに取り組んでいます。最初に正規化フォーム NFD に変換し、次に Unicode 大文字と小文字の折り畳みアルゴリズムを適用し、最後に結果を Unicode 正規化フォーム NFC に変換することによって達成される正規化フォームを定義することにしました。

私は Unicode 表現とユーティリティ関数を ICU の C API に依存しており、ICU の関数unorm_normalize()とu_strFoldCase()関数を使用して私のスキームを実装するのはかなり簡単でした。しかし、私のテストの 1 つが失敗しており、その理由がわかりません。ICU は、私の予想とは異なる NFC フォームを生成しているようです。

入力シーケンスは、次の BMP コード ポイントで構成されます。

デバッガーを介して、ケース フォールディング後の中間結果について ICU と同意することを確認しました。

特に、NFD を形成するための初期の変換では、関係する文字の相対 CCC 番号に基づいて、文字 U+031C が U+1EC4 の分解の途中に移動したことに特に注意してください。それは私がテストしようとしているものの一部です。

ここで良い点: ICU によると、折りたたまれた文字シーケンスの NFC 正規化は

一方、私はそうあるべきだと思います

末尾の 3 つの結合文字は既に標準的な順序になっており、U+0065 と U+031C の標準的な合成は存在しないためです。

だから、2つの質問：

1. 正しい NFC フォームはどれですか?
2. ICUが正しいなら、なぜですか？

Unicode 数字を ASCII 数字に正規化する Java API はありますか?

JDKとICU4Jには、この種の正規化を処理できないように見える正規化 API があります(おそらくUnicode 標準では正規化と呼ばれていないため) 。

必要なのは、すべての形式の Unicode 数字 (この投稿にリストされている) を [0-9] に変換することです。考えられる厄介な解決策は、0 から 9 までの任意の数字を 10 ですべて置換することです。

この質問は、インデックスにローカル名を格納するための国際文字の正規化に関するものです。この問題について一般的に議論したいと思います。また、Java で可能な既存の解決策 (クラス/ライブラリ) についても聞きたいと思います。

グローバル アプリケーションでは、ユーザーが自分の名前を入力すると、アプリケーションは各名前を検索インデックスに書き込みます。これにより、他のユーザーが名前を検索してユーザーを見つけることができます。英語では些細なことですが、他の多くの言語や世界規模ではそれほど些細なことではありません. たとえば、ドイツ語名の Häußler は、次のように書くことができます。

• ホイスラー（ドイツ）
• Haeussler (ドイツ、国際音訳)
• ハウスラー (スイス)
• Hausler (英語の音訳)

Javaには

クラスですが、これは多くの場合に機能しないようです、および/またはそれを適切に使用する方法がわかりません. http://en.wikipedia.org/wiki/Unicode_equivalenceもよく読んでいますが、このトピックに関する十分なバンドル情報が見つかりませんでした。

誰かがすでにその問題に取り組んでいる既存のオープンソース プロジェクトを知っている人はいますか? 使用できるライブラリはありますか? ウェブサイト？

日本人、中国人、アラブ人などはどのように言語を英語に音訳しますか? Facebook のような大規模なソーシャル ネットワークは、ユーザー名をどのように音訳して、国際的に見つけられるようにしているのでしょうか?

編集:わかりました、.normalize() は当初考えていたほど広くサポートされていないようです。以下の質問の修正: この機能をまだサポートしていない Safari などのブラウザーで Unicode を正規化するための最善の回避策は何だと思いますか?

1 週間ほど前まではすべてのブラウザで正常に動作していたコードが、Safari でのみ機能しなくなりました (他のすべてのブラウザは引き続き正常に動作します)。問題のあるコードを突き止めましたが、なぜそれが Safari の問題なのかはまだわかりません。このコードは、2 つの URL 部分文字列 (例: "Williams%2C+John%2C+1932-") を比較して、それらが同じであることを確認するものです。文字列には分音記号、スペース、その他の問題のある文字が含まれていることがあるため、decodeURI (最初の文字列) と正規化 (両方の文字列) が必要です。

私が知っていることは、両方の .normalize('NFD') コマンドを削除すると、コードが再び正常に機能するということです...しかし、一方の文字列が事前に構成された分音符号を使用し、もう一方の文字列が使用される場合があるため、そこに正規化コマンドが必要です分解されたものを使用します（そして、私の目的のために、それらを一致と見なしたいと思います）。.normalize() が Safari で問題を引き起こす可能性があるが、他のブラウザーでは問題を引き起こさない理由を誰かが知っているかどうか知りたいです。

Safari のエラー コードは次のとおりです。