web-dev-qa-db-ja.com

URLでアクセント記号付き文字を使用する必要がありますか?

英語以外の言語でWebコンテンツを作成すると、検索エンジンに最適化された使いやすいURLの問題が発生します。

URLでアクセント記号なしの文字を使用するのがベストプラクティスであるか(特定のアクセントがある場合とない場合で一部の単語の意味がまったく異なるリスクがあるのか​​)、または英語以外の文字の使用に固執する方が良いのではないかと考えています高度でない環境(MSIE、ソースの表示など)でこれらのURLの可読性を適切に犠牲にします。

「エキゾチックな」文字はどこにでも表示される可能性があります。ドキュメントのタイトル、タグ、ユーザー名などに表示されるため、ウェブサイトのメンテナーの完全な監督下にあるとは限りません。

もちろん、可能なアプローチは、元の宛先を指す代替の(アクセントなしの)URLを設定することですが、アクセント付きURLをprimary document identifiersとして使用することについての意見を学びたいと思います。

57
Wabbitseason

同様の問題に直面したとき、 RL rewriting を利用して、アクセント付きまたはアクセントなしの文字でそのようなページにアクセスできるようにしました。実際のURLは次のようになります

http://www.mysite.com/myresume.html

そして、書き換え+文字変換機能により、この参照が可能になります

http://www.mysite.com/myresumé.html

同じリソースをロードします。したがって、あなたの質問に答えるために、primaryリソース識別子として、0-9、A-Z、a-z、および時々ハイフンに限定します。

13
Bob Kaufman

ここにはあいまいさはありません: RFC3986はno 、つまり、URIにはUnicode文字を含めることはできず、ASCIIのみを含めることができます。

まったく異なる問題は、ブラウザがURIを表示するときにエンコードされた文字をどのように表現するかです。たとえば、一部のブラウザはURLに「%20」ではなくスペースを表示します。これもIDNの仕組みです:punycoded文字列は、ブラウザによってオンザフライでエンコードおよびデコードされるため、cafe.comにアクセスすると、実際にはxn--caf-dma.comにアクセスしています。 URLのUnicode文字のように見えるのは、実際にはブラウザ側の「視覚的な砂糖」だけです。IDNまたはUnicodeをサポートしていないブラウザを使用する場合、URLの基礎となる定義は単にサポートしていないので、一貫して動作させるには、%エンコードする必要があります。

32
Synchro

アクセント付きのURLを考慮すると、多くの場合、次のようになります。

http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant

...これはニースではありません...しばらくの間、アクセントなしのURLを使用していると思います。

しかし、アクセント付きのURLがWebブラウザで受け入れられるようになったため、状況は改善されるはずです。

現在使用しているfirefox 3.5では、%stuff、btwではなく、ニースの方法でURLが表示されます。これは、Firefox 3.0以降「新しい」ようです( Firefox 3:ロケーションバーでのUTF-8サポート )。そのため、おそらくIE 6ではサポートされていません。少なくとも、これを使用している人はまだ多すぎます:-(


たぶん、アクセントのないURLは、見栄えがよくないかもしれません。しかし、それでも、人々はそれらに慣れており、一般的にはかなりよく理解しているようです。

10
Pascal MARTIN

ユーザーがブラウザに手動で入力する可能性のあるURL内の非ASCII文字は避けてください。サーバーによって事前にエンコードされた埋め込みリンクには問題ありません。

ブラウザはさまざまな方法でURLをエンコードできることがわかり、どのエンコードを使用しているかを把握することは非常に困難です。この問題に関する私の質問をご覧ください。

TomcatのURIでの文字エンコーディングの処理

5
ZZ Coder

完全なURLにはいくつかの領域があり、それぞれに異なるルールがあります。プロトコルはプレーンASCIIです。 DNSエントリはIDN(国際ドメイン名)ルールによって管理され、(ほとんどの)Unicode文字を含むことができます。パス(最初の/の後)、ユーザー名、およびパスワードがすべてのものになります。 (%XXとして)エスケープされますが、これらは単なるバイトです。これらのバイトのエンコーディングを知ることは困難です(httpサーバーによって解釈されます)。パラメータ部分(最初の?の後)は、「そのまま」(%XXエスケープ解除後)サーバー側アプリケーション(php、asp、jsp、cgi)に渡され、バイトの解釈方法は別の話です)。 path/user/password/argumentsはutf-8であることが推奨されますが、必須ではなく、誰もがそれを尊重するわけではありません。

したがって、非ASCIIを確実に許可する必要があります(もう80年代ではありません)が、正確にそれを行うのは難しいかもしれません。ユニコードを使用し、レガシーコードページに近づかないようにし、可能であれば適切なエンコード/文字セットでコンテンツにタグを付けます(HTMLのメタ、asp/jspの言語ディレクティブなどを使用)

2
Mihai Nita