1

åäö のようなラテン文字を含まないリンク リソースがいくつかあります。これらは通常、ユーザーがアップロードしたファイルです。

問題は、それらのエンコードに成功していないことです

filename.encodeAsURL を使用すると、正しい方法でエンコードされないようです

たとえば、文字 ö は o%CC%88 に変換されます。firefox で同じことを入力して内容をコピーするテストでは、%C3%B6 が返されます。

これらのエンコーディングの違いは何ですか?正しいエンコーディングを取得するには何を使用すればよいですか??

4

1 に答える 1

2

どちらのエンコーディングも正しいです。実際には、2 つの異なる文字列のエンコーディングが表示されています。

ここで重要なoのは、文字列の先頭にある に注目することです。

o%CC%88文字のo後にUnicode Character Combining Diaeresisが続き、レンダリング時に前の文字と結合されます。

%C3%B6Unicode Character Latin Small O With Diaeresisです。

あなたが見ているのは、最初のケースでは、入力された文字列が次の 2 つの文字のようなものであるということです: o ¨、実際には としてレンダリングされöます。2 番目のケースでは、実際の文字öです。

私の推測では、2 つの異なる入力の違いを見ていると思います。


以下の説明に基づいて更新してください: Unicode 文字を動的に処理していて、入力メソッドを制御できない場合は、java.text.Normalizer (Java 1.6 以降) を使用して Unicode の正規化を試みることができます。

正規化では、すべての文字が一貫して表現されるようにしようとするため、アクセント付きの文字は常に結合文字または常に文字 + 結合記号で表されます。

大まかな例:

String.metaClass.normalizeUnicode = {
    return java.text.Normalizer.normalize(delegate, java.text.Normalizer.Form.NFC)
}

input = input.normalizeUnicode()

正規化には 4 つの形式があります。それらがどのように機能するかの説明に基づいて、あなたのケースに最適と思われるものを選択しましたが、他のものを試して、最も一貫して機能するものを確認することをお勧めします.


とはいえ、URL で Unicode 文字を表現しようとしていて、それらがコードによって直接ロードおよび処理されていない場合は、ラテン文字以外の文字をまったく使用しないことをお勧めします。これには、一貫性があるという利点があるだけでなく、URL が大幅に短くなり、読みやすくなります。 boo.pdfよりもはるかに読みやすいですbo%CC%88o.pdf

于 2012-01-13T22:24:08.713 に答える