問題タブ [unicode-normalization]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
string - Unicode 正規化フォーム NFC および NFD をいつ使用するか?
Unicode 正規化に関する FAQには、次の段落が含まれています。
プログラムは、正規に相当する Unicode 文字列を常に等しいものとして比較する必要があります... Unicode 標準は、これに使用できる明確に定義された正規化形式を提供します: NFC および NFD。
と続きます...
どちらを使用するかは、特定のプログラムまたはシステムによって異なります。NFC は、従来のエンコーディングから変換された文字列との互換性が高いため、一般的なテキストに最適な形式です。... NFD と NFKD は、内部処理に最も役立ちます。
私の質問は次のとおりです。
「一般的なテキスト」に最適な NFC の理由。「内部処理」の定義と、NFD に任せるのが最適な理由は何ですか? そして最後に、何が「最良」であるかは気にせず、2 つの文字列が同じ正規化形式を使用して比較される限り、2 つの形式は交換可能ですか?
unicode - ハッシュ時のパスワードに適した Unicode 正規化 (およびその他の処理) は何ですか?
パスワードに完全な Unicode を受け入れる場合、文字列をハッシュ関数に渡す前にどのように正規化すればよいですか?
目標
正規化しないと、あるコンピューターでパスワードを「mañana」( ma\u00F1ana
) に設定し、別のコンピューターで「mañana」( ) を使用してログインしようとするとma\u006E\u0303ana
、ハッシュが異なり、ログインに失敗します。これは、ユーザー エージェントまたはそのオペレーティング システムの制御下にあります。
- それらが同じものにハッシュされるようにしたいと思います。
- Α、А、A (ギリシャ語、キリル文字、ラテン語)などのホモグリフは気にしません。
参照
Unicode 正規化フォーム: http://unicode.org/reports/tr15/#Norm_Forms
考慮事項
- 正規化手順は、衝突を引き起こす可能性があります
"office" == "office"
。 - 正規化により、文字列のバイト数が変わる場合があります。
さらなる質問
- サーバーが有効な UTF-8 (またはその他の形式) ではないバイト シーケンスを受信した場合はどうなりますか? 正規化できないので拒否しますか?
- サーバーがそのバージョンの Unicode で割り当てられていない文字を受信するとどうなりますか?
unicode - Unicode 関連の問題をテストするための Unicode サンプル テキスト ファイルはありますか?
テキストのエンコードとデコードに関連するさまざまな問題をテストするために使用できる、サンプルのテキスト Unicode ファイル (UTF-8) を探しています。
- 最初の 32 コードなど、ASCII 文字の使用量が少ない
- BMP 外の文字
- NFC 関連の問題
- XML のエンコード/デコードの問題
主に、テキストをクリップボードにコピーし、アプリケーションの HTML テキスト領域に貼り付けて、後でページから取得できるようにしたいと考えています。
これにより、デコード、エンコード、またはデータベース レベルで発生する可能性のあるさまざまな Unicode 関連の問題を特定できます。
perl - Perl v5.8.8を使用してマークアップを処理するためにUnicodeおよびhtmlエンティティを正規化するにはどうすればよいですか?
Perl バージョン 5.8.8 を使用しています。Unicode (UTF-8) をサポートしていると思いますが、信頼できるとは確信していません。Perl 5.8.8 を使用してデータを処理および保存する最適なオプションは何ですか? HTMLエンティティと実際のUnicodeの処理はどうですか? 非常に大きなドキュメントを処理します。現在、多くの機能を動作させるために、一部の Unicode をフィルタリング/置換し、html 資格として一定でないエンコーディングを行い、一部のコードはパススルーされますが、一致をエスケープし、修正が必要な多くのバグ修正をもたらします。一つずつ。見過ごされているものもあるでしょう。私はこれがちょっと苦手なタイプです。
これまでの私の考えでは、Unicode 文字を入力するのは面倒で、拡張句読点文字はエンティティよりも視覚的に区別するのが難しいということです。最後に、Unicode の取り扱いについて読みましたが、最新の Perl バージョンを使用する新しいプロジェクトには適しているかもしれませんが、レトロフィットが難しいため、スクリプトを使用して html エンティティに正規化する方が良い選択肢のように思えます。一方、国境のコードまたはスクリプトはとにかく Unicode を使用する必要があります。JavaScript の機能には影響しないと思います。これらのエンティティはすぐに Unicode 文字に変換され、DOM のテキスト ノードの通常の要素になると思います。
Unicodeおよびhtml エンティティの使用を一貫して正規化する lib またはスクリプトはありますか? エンティティの場合、名前付きエンティティの短い辞書を使用してそのスペース内で正規化し、残りのデフォルトを数値にする必要があります。それは別のステップであり、比較的簡単です。その他の手順として、入力スクリプトを変更して Perl コードを正規化し、複数のオプションを持つダッシュや引用符などの要素に一致するイディオムをいくつか作成します。
bash - Unicode ファイル パスを指定した runcommand (haskell)
Unicode ファイル パスを持つ Haskell から bash コマンドを実行したいと思います。
Haskell の文字列は \escapes を使用します。
"beißen" -> "bei\223en"
Bash は次の形式を受け入れるようです:
$'bei\xC3\x9Fen.avi'
と'beißen.avi'
runCommand
fromSystem.Process
は型を持っているので
runCommand :: String -> IO System.Process.Internals.ProcessHandle
Haskell 文字列を Bash が受け入れる形式の 1 つにエンコードするにはどうすればよいですか?
bash 3.2 を持つ Mac OSX 10.8.4 を使用します。
編集
私の問題はbashエスケープに関係しているようです
私はText.ShellEscape
(http://hackage.haskell.org/packages/archive/shell-escape/0.1.2/doc/html/Text-ShellEscape.html)を使用して、bashでエスケープする必要がある文字をエスケープしています
例えば
それは私に与えます"$'bei\\xDFen.txt'"
実行中runCommand $ "ls " ++ cmd
それは私に与えます
ls: bei�en.txt: No such file or directory
bash の文字列をエスケープするより良い方法はありますか?
python - Unicode ユーザー名のプラットフォームに依存しない正規化
最近のバグ開示では、ユーザーがユーザー名正規化コードの不具合を使用して、所有していないアカウントにアクセスした方法について、Spotify が語っています。問題は、ユーザー名が取得されたかどうかを確認するために、べき等でない操作をユーザー名に適用していたため、ᴮᴵᴳᴮᴵᴿᴰ と BIGBIRD は、別のユーザー名であってはならないときに別のユーザー名になっていたことでした。
Web サイトで Unicode ユーザー名を許可したいのですが、この種の攻撃に対して脆弱になりたくありません。私は Python を使用していないため、彼らが Web サイトで提案したソリューションを使用できません。Unicode操作をサポートする任意のプラットフォーム(つまり、python、ruby、lua、javascript、.NETなど)で使用できる冪等式はありますか? NKFD + 文字列を小文字にするのと同じくらい簡単ですか?
unicode - Unicode NFC 正規化により、文字列の長さを増やすことはできますか?
文字列に Unicode 正規化形式 C を適用すると、文字列内のコード ポイントの数は増えますか?
unicode - ケースの折り畳み後に正規化が必要
NFC で正規化された文字列が与えられ、その文字列に完全な大文字と小文字の折り畳みを適用すると、結果も NFC で正規化されていると想定できますか?
この引用で Unicode 標準が何を伝えようとしているのか理解できません。
正規化は、大文字と小文字の折り畳みとも相互作用します。任意の文字列 X について、Q(X) = NFC(toCasefold(NFD(X))) とします。つまり、Q(X) は、X を正規化し、その結果をケース フォールディングし、その結果を正規化形式 NFC 形式にした結果です。正規化とケース フォールディングの定義方法により、Q(Q(X)) = Q(X) となります。Q を繰り返し適用しても結果は変わりません。ケース フォールディングは、NFC または NFD の正規化形式の正規正規化の下で閉じられます。