web-dev-qa-db-ja.com

URLパスを音訳する必要がありますか？

私は周りを見て、これに関する情報を見つけることができません。それはよくある質問でなければならないので、間違った用語や何かを検索しなければなりません。

URLにASCII以外の文字が含まれている場合、FirefoxとChromeはアドレスバー（en.wikipedia.org/wiki/Clichéなど）にうまく表示されますが、IE（含むIE10コンシューマープレビュー）では、このようなen.wikipedia.org/wiki/Clich%C3%A9のような文字コードなどが表示されます。

これらのアプローチの1つは他のアプローチよりも正しいですか？ IEはいつかFFとChromeがすることを始めますか？

基本的に、新しいサイトで音訳するかどうかを決定しようとしています。私の好みは、文字変換を行わないことです。正しい文字を使用することが「正しいように見え」、FF/Chromeで見た目が良くなるからです。しかし、IEでは恐ろしく見えます。また、大多数の人々がIEを使用しているため、音訳を主張しています。

一度ポリシーを設定すると、おそらくそれを変更することはないでしょう。したがって、IEの将来のバージョンがFirefoxなどのように動作し始めることがわかっている場合は、未加工のURLを使用して基礎を築き、現在のユーザーを苦しめます。しかし、そうでない場合、私は音訳を好むと思います。何かお勧め？

urlinternationalizationpathtranslation
4
Fletch

簡単な答えは「それは依存します」、主にあなたがそれで何をしようとしているかです。

RFC3987国際化リソース識別子 の仕様を見ると、IEはURLをエンコードする権利の範囲内です。特に、éを入力する場所にUS/UKキーボードが割り当てられている場合ユーザーにとって最も単純なアクションではないかもしれません...

それに加えて、サーバーが1つの形式を期待しているときにサーバーが非常に動揺するのを見て、ブラウザーが少し異なるもの（つまり ""、 "+"または "％20"）を送信します。 文字エンコードの処理TomcatのURIで 別の例.

IE9に公平になるように、実際に入力した場合 Ctrl+Alt+e+' アドレスバーに、それは文字を正しく表示します、それは私がそれを変更するという点でそれをコピー/ペーストする場合のみです：

enter image description here

ウィキペディアのソースは、実際にリンクをキャラクターとURLエンコードし、ブラウザーに任せます：

<a href="/wiki/Clich%C3%A9_(disambiguation)"

また、w3dがコメントで指摘しているように、Chromeのhttp://en.wikipedia.org/wiki/Clichéを要求すると、実際には http://en.wikipedia.org/wiki/Clich%C3に対する要求が行われます。 ％A91

ですので、いくつかのブラウザwillがURIの代わりにIRIを使用するとエンコードされた文字列を送信するため、あなたのサイトがどちらの設定も処理できるようにすることをお勧めします。

脚注：

  1. 私は実際にこのエディターにIRIを尊重させることはできません.é記号を使用して「h」で自動認識を切り取り、リンクとして追加するとエンコードされたバージョンに変わり、エンコードされたバージョンを修正するとリンクが完全に削除されます.
3
Zhaph - Ben Duguid