4 posts tagged “url”

なんか，自分が AutoPagerize をインストールした数日後 (7/10) に新しいバージョンがリリースされていて，あまつさえ addFilter なんつー機能が増えているジャマイカ．なんてことに二ヶ月くらい気付かなかった．

ので de-tinyurl も追随しました．

detinyurl.user.js

• AutoPagerize.addFilter を利用して，力技対応をやめた．
• query string 付き URL の decode がおかしかったのを修正 (なぜ気付かない?

昨日，初めてグリモンを作ってみて，あーこりゃたのしーみたいな状態なわけですよ．

で，TinyUrl をデコードできないかという発言と AutoPagerize 対応しないかなという発言に反応してチトやってみた．現実逃避．グリモン暦二日なので色々とご容赦いただきたい ;D

AutoPagerize 対応部分がチト強引かなぁ．
追加された部分だけ走査すると早いんだろうなー．

detinyurl.user.js

• 早速，onscroll の度に getElementsByTagName を実行するという鬼畜仕様を改善．scroll が落ち着くたびに走査．
• 早速，フラグの true と false 間違えてたので修正 (死亡)．

• 色々修正

ブラウザのアドレスバーに表示された URL というのは，(hosts や DNS が信頼できる限り) 現在自分がどこにいるのかを容易に知ることができる唯一の情報となる．

見慣れたページ内容であっても URL 中のドメインがいつもと異なればそれは別の誰かが設置したページ (罠) かもしれないし，たとえ鍵マーク付きの HTTPS 通信をしていたからといって URL から目を離しちゃいけない．ましてやアドレスバーの表示されていないポップアップウィンドウなんて最悪だ．ページのプロパティを参照すれば URL を確認できるが，遷移する度にそんな手間はかけられない．故に「アドレスバーを表示しない設計がおかしい」としばしばサイト側は責められた．"location=no" と書けるから書いてみただけなのに．

でも，もうそろそろいいだろう．ブラウザ側が対応すれば問題は解決する．Opera は以前から "location=no" でもドメイン名が強制表示されていたようだし，とうとう Internet Explorer 7 ではアドレスバーを非表示にすることができなくなった．これは革命だ!! Firefox も見習うといいよ．すぐに．

話は変わって，ケータイについて．

ケータイでは狭い画面を有効に使うためか，現在表示中の URL をページと同一画面上に表示してくれない．DoCoMo 端末の場合は「URL 表示」というメニューがあって，いつでも URL を参照することができる．SoftBank はよく知らない．J-PHONE 時代は全く URL を参照できなかったように記憶している．Vodafone 以降は DoCoMo 同様「URL 表示」的なメニューのある端末もチラホラ出てきたが，某仕様の所為で常に正確な URL が表示されるというわけではなかったような気がする (それでもドメインは確認できた)．

さて，au はどうだろう．最近の au 端末は KCP によってブラウザが共通化され，基本的にどの端末でも同じ仕様になっているハズなので，自分の au 端末 (W51SA) を見てみると少なくとも「URL 表示」というメニューは存在しない．一応，「お気に入り登録」というメニューを選択するとページタイトルおよび URL を参照・編集できるのだが，au の場合ページ内に仕掛けを施すことによってお気に入りへの登録を禁止することができる．こうなっていると無残にも「このページはお気に入りリストに登録できません」と言われてしまい，URL を拝むことができない．冒頭でも挙げたように，URL が参照できないと言うことは自分が今どこにいるのかが分からないということで，非常に Phishing 耐性が低いと言える．EZweb の Google 提携によってオープンサイトへのアクセスが増加している昨今，端末がこのような仕様では自衛もままならない．改善を期待したい．

どうもケータイ文化というものは安易な「隠蔽によるセキュリティ」の上に成り立っているように思えてならない．「URL が見えると危険」，「HTML ソースを見られると危険」，こんな思惑が覗き見えるような気がするのは心が荒んでいる所為だろうか．先のブックマーク禁止仕様も「セキュリティ」の名の元に追加されたのではないかと勘繰っているのだが (MARKABLE 属性は HDML の構造上必要だったのかな?)，PC 向けサイト作ってる人間からすりゃ「一連の遷移途中でブックマークされても問題ないように作る」のが当たり前であって，こんな機能に頼ってたらオープンなサイト作れませんよ，みたいな．

Twitter をしばらく利用していて思ったのは，URL の扱いがナニであるということだ．Twitter は，文字列中の URL らしき文字列を自動的にリンクしてくれるのだが，どうも具合が悪い．

典型的なのが "(http://www.yahoo.co.jp)" という，URL を丸括弧で囲んだもので，Twitter 上では "http://www.yahoo.co.jp" がリンクとして扱われるのだが，丸括弧 "(", ")" は URL の一部として許されている文字なので，本来は閉じ括弧を含めた "http://www.yahoo.co.jp)" がリンクとして扱われるべきなのだが，よく見られる「発言内容 (補足 URL)」という形式は日本語 (?) としては自然で，かつ Twitter が書き手の意図通りにリンクしてしまうのでかなり氾濫している．

また，Google Maps の 等の，カンマ (",") が含まれる URL を正しく認識しないため，カンマ直前までが tinyurl に渡されて "http://maps.google.co.jp/maps?f=q&q=+38.694465,+139.538206" という入力が "http://tinyurl.com/26obzv,+139.538206" というリンクになってしまう．おや，前述の理屈で言えば "http://tinyurl.com/26obzv" までがリンクとして扱われるべきなのだが，どうやら path に含まれるカンマは URL の一部として扱われるようで，

1. "http://maps.google.co.jp/maps?f=q&q=+38.694465,+139.538206" が渡された
2. query 部のカンマ直前まで ("http://maps.google.co.jp/maps?f=q&q=+38.694465") が URL として認識され，tinyurl 圧縮される
3. 結果として "http://tinyurl.com/26obzv,+139.538206" という文字列が生成されるが，ここに現れるカンマは path の一部として解釈されるので，再 parse されて結果として全体が URL として認識され，リンクされる

という仕組みになっているのだと思う．

さて，これらの挙動の何が問題なのか．前者は「丸括弧が含まれる URL が正しく認識されない」，「API を利用した別アプリケーションが (正しく) URL をリンクする際に投稿者の意図通りにリンクされない」といった問題がある．また，後者は Twitter 上でも投稿者の意図通りに扱われていないし，Twitter 以外のアプリケーションも正しく解釈できない．

よくよく考えると，カンマ記号は reserved な記号ので Google Maps の URL こそ Google の意図通りに扱われない可能性があるのではないか? と思ったが，よく分からない :-(

何より，API ベースのアプリケーションは正しく URL を検出・リンクしているのに，ユーザから「間違っている!! (Twitter と挙動が違う)」と言われるのは心苦しい．とはいえ，この事象に対してでどうやって「人に優しく自分に厳しく」するのか? と問われると返答に窮する．とりあえず Twitter にメールしてみた．

ちなみに，どちらが悪いのか分からないのだが，Twitter の投稿を Google Talk で受信した際に，"http://www.yahoo.co.jp[tag]" のようにブラケット記号を含んだ文字列が Twitter 側では "http://www.yahoo.co.jp" を URL として認識するのに Google Talk では "http://www.yahoo.cojp[tag" が URL として認識される．ううむ…．

で，結論というか，conservative な人は RFC 2396 で (逆説的に) 推奨されていると読み取れる <http://www.yahoo.co.jp> や "http://www.yahoo.co.jp" という表記を用いるのが良いのではないか，と．

果たして海外で URL を丸括弧で囲む習慣があるのか不明だが，まぁ少なくとも自分にとっても合理的に思えるし，かつてのチルダ記号のように数の力で de facto にしてしまうのもアリかなぁとは思う (なので，基本的に conservative な自分としては微妙に歯切れが悪い)．

それにしても，Vox ですらこのエントリ中の URL を意図通りに認識してくれなかったりして，URL 認識は各アプリケーションの都合によって随分と異なるので利用者は振り回される一方だなぁと改めて感じる．