どちらのエンコーディングも正しいです。実際には、2 つの異なる文字列のエンコーディングが表示されています。
ここで重要なo
のは、文字列の先頭にある に注目することです。
o%CC%88
文字のo
後にUnicode Character Combining Diaeresisが続き、レンダリング時に前の文字と結合されます。
%C3%B6
Unicode 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
。