昨今、何気なくブラウザで閲覧している最中でも URL に関連する問題や不満に遭遇する事が増えてきたので、URL に関連した問題（問題と言ってしまうには間違っていそうな話題も含む）をメモしておきます。
先に全体的な感想を述べると、同じコンテンツに対して複数の URL（しかも、その多くはコンテンツ作成者の意図とは関係ない所で行われる）が生成されていくため、ユーザの反響等が追いづらくなってるなぁと感じます。はてなブックマークや TOPSY など、Web 上でのフィードバックを追うためのシステム側が対応してくれているのでユーザとしてはそこまで気にはならないのですが、何というか何でしょうね、と言うモヤモヤしたものが残る現状ではあります。
HashBang (#!)
https://twitter.com/#!/tt_clown のようなアレ。HashBang と呼ぶそうです。私自身は、HashBang が原因で Web ブラウズ中にストレスが溜まった経験はないのですが、何度か問題として取り上げられているようです。
Tim Bray: 「URLに#!入れるな」 - karasuyamatenguの日記#!に対するtbrayの批判
- サーバが認識するURL(#!以前の部分)が一つのドキュメントと対応するというウェブの大原則に背くルール違反
- この単純なURLとドキュメントの対応がなかったらサーチエンジンは生れなかっただろう
- googleは#! URLをクロールする決まり事を提案しているが、これは酷いハック
- このようなバリアによって次のグーグルのような発明が困難になることが最大の問題
ウェブのURLドキュメント対応の原則を無くなると、Googleが生れた土壌が損なわれるというのがtbrayの論点だ。
その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。
Hashbang(#!)なURLの恐怖 - Hail2u
尚、HashBang を使っていた代表格である Twitter に関しては、処理の高速化辺りを理由に HashBang を撤廃する方向で動いているようです（参考：Twitterがツイートのパーマリンクから「#!」(hashbang)を撤廃 - F.Ko-Jiの「一秒後は未来」）。撤廃していくにあたって、二つ目の記事のメンテナンス性の問題（意図したリンク先へ移動させるには、JavaScript を利用したクライアント側でのリダイレクト機能を提供し続けなければならない）が顕在化してきそうですが、これからどうなっていくのか気になる所ではあります。
静的 HTML に付与されるクエリ（utm_source 等）
最近、Web ページを閲覧していると *.html?utm_source=twitterfeed や *.html?ref=twitter などのように、静的な HTML であるにも関わらず、クエリ文字列の付与されているケースが散見されます。何に使われているかはっきりとは分からないのですが、主にトラッキング目的で付与されているようです。
通常メールからのアクセスはメーラーの場合ノーリファラー*1に、Gmail などのウェブメールの場合は、そのドメインが参照元として記録されてしまうので、特定のメールマガジンのアクセスをトラッキングすることは困難です。こういった場合、キャンペーントラッキングを使うとメールマガジンからの全てのアクセスを1つにまとめてトラッキングすることが出来ます。
具体的にはメールに掲載する URL に下記の様なトラッキング用のパラメータを付けていただきます。このパラメータは"URL生成ツール"で簡単に作成できます。入力内容は任意ですが、下記の例では、ソースを mail、メディアを070901としています。
アナリティクス 日本版 公式ブログ: メールマガジンのトラッキング方法
これに関しては、URLの末尾に付いた「utm_source=twitterfeed」の正体 - conflict error で述べられていますが、一時期、これらのクエリ文字列の有無ではてなブックマーク等のエントリーページが分かれてしまい、ユーザの反響が分散すると言う問題が発生していました（現在は、そう言ったクエリ文字列ははてなブックマーク側がある程度取り除く事によって解決しているようです）。
この問題については、サーバ側でリダイレクトしてしまおうかと検討している記事も見られました（参考：同じエントリへのはてブがバラバラに付く - Shin x blog）。
短縮 URL
短縮 URL は、リンク先のドメイン名、およびページ名が分からないため、「どこのサイトか」、「どんな内容のページ」かを推測するための情報が削られてしまい、フィッシング等にも利用されやすいと言う問題があります。Twitter と短縮 URL に関しては 短縮 URL サービスは役目を終えた - Life like a clown 辺りで記述しましたので、リンクを示して終わりにしようと思います。
マルチバイト文字を含む URL
マルチバイト文字は、主にエスケープ処理の問題に遭遇する事が多々あります。例えば、ブックマークレット - はてな で紹介されている「はてブコメント表示」のブックマークレットを Google Chrome に登録し、日本語を含む Web ページに対して実行するとうまく機能しません。
これは、ブックマークレットが escape(location.href) と URL をエスケープ処理するようになっていますが、ブラウザ (Google Chrome) から取得できる location.href に既にエスケープ処理が行われているため二重にエスケープしてしまって失敗するのだろうと推測されます（上記の問題は、例えば、escape(unescape(location.href)) のように unescape を挟むと、取りあえずはうまく機能するようになります）。
マルチバイト文字に関しては、Wordpress が生成する URL の中に日本語が混じる事があるようで（そう言う設定があるのだろうと思います）、日本語の URL 関係の処理でミスってフラストレーションが溜まる事例も増えてきました。
