Toshiro Shimura's Bookmarks tagged encode →  View Popular

URL エンコードって何？

わかりやすくて身近なのは検索エンジンの「検索」ボタンを押した後の Web ブラウザのアドレス欄でしょうか。入力した文字列がそのアドレス欄の URI に含まれているはずです。しかし、その URI に含むことができない文字が存在します。それらを使用できる文字を使って変換することが URL エンコードなのです。

%エンコードされた URL のデコード

Fx2

FX3

7/8更新: % エンコードされた URL もデコードされて表示されます。マウスオーバー時、編集時もデコードされたままですが、コピー時には再エンコードされたものがコピーされます。

• Firefox 3 の新機能 - えむもじら


• ロケーションバーの提案 - えむもじら


• ロケーションバーの提案(2) - えむもじら

Firefox1.1では，UTF-8がデフォルトになるということですが，上記の点を考えると，ブラウザーの機能としては，相対リンクに対してはソースの文字コードで，外部リンクにはUTF-8でurlエンコードするのが好ましいような気がしますが，どうでしょう？

　しかし，こういう事柄を「それを意識していない人達に説明する」のは難しいですね。（url-encode，RFC，uri って何？？からの説明をしたら嫌がるよなぁ。）

　で，現時点でFirefoxのURLencodeをUTF-8化してしまう方法というのも教えていただきました。

てんぷる の投稿 :2005/06/06(Mon) 10:18:21
(環境: WinXP SP2/Firefox1.0.4)
> 　FirefoxのurlエンコードをUTF-8に固定する方法というのはあるのでしょうか，

Windows の Firefox 1.0.4 の場合、about:config にて
network.standard-url.encode-utf8 を true に変更すると
常にUTF-8でエンコードされるようです。

こんな機能を持っています。

★ URL を表示するアドレスバーで、2バイト文字情報を含む URL エンコードをデコードして表示する

例えば、デスクトップにおいたファイルを Firefox でブラウズすると、アドレスバーはこのような表示になってしまいます。

これでは何がなんだかわかりません。

そこで、拡張機能 Locationbar2 をインストールすると、アドレスバーにデコードして表示されます。

Google や Wikipedia などをブラウズしたときも、デコードして表示されるので分かりやすくなりますよ。

★ shift キーを押しながらアドレスバーにマウスを持っていくと、「/」（スラッシュ）で区切られたディレクトリ名をクリックすることでディレクトリの移動ができる

階層が深い Web サイトのときはかなり重宝してます。

FireFoxのロケーションバーに「虞羡」を渡すと、「%8B%F1%FB%91」とエンコードされる。これもShift_JISとしては納得できる変換だし、そしてPHPでmb_detect_encodingさせると、正しくSJISと判定される。ところが、これをUTF-8に変換しようとすると、「%E8%99%9E%3F」などと、もうUTF-8としてはありえないはちゃめちゃコードに壊れてしまい、失敗する。

もう、イヤんなってくる。これというのも、FireFoxやPHPが、IBM拡張を中途半端にカバーしているせいだと思うよ。頼むから、IBM拡張なんかサポートしないでくれ……。orz

PHPのurldecode関数にそれぞれの文字列を渡すと、前者はShift_JISで「諸葛亮」、後者はUTF-8で「諸葛靚」が得られる。こちらもやはり、どちらか一方でのデコードを試み、それに失敗してから他方のデコードを試みているのだろう*3。Shift_JISとUTF-8でかぶっているコードがどうなるかは試してないので分からない。コードのかぶってる文字があるのかどうかも知らないし。

このurldecode関数だと、返り値のコードがShift_JISなのかUTF-8なのか分からないので、ちと困る。mb_parse_str関数を使うと、どのコードで渡してもかならずUTF-8で返ってくるので*4、いい感じ。これも内部で自動的に判断し、変換してるんだろう。

なんでこういうことを書いたかっていうと、【Wikipedia】みたいにURLの一部として渡されたクエリ文字列をキーにデータベースからデータ引っぱってくるような仕組みを作りたかったんだけど、実際テストしてみたらIEやOperaでは問題なかったのにFireFoxで試したときだけ検索に失敗したので、おかしいなと思って調べたら、FireFoxのときだけ文字列がShift_JISで渡されたのに気付いたというわけなんですね。あたしゃてっきりどのブラウザでもUTF-8でしか渡されないと思いこんでたよ。

それじゃWikipediaではどういう扱いをしてるんだろうと思ってMediaWikiのソースをダウンロードしてみても、どうも文字コードを変換してるらしいところは見られない。おっかしーなーと首をひねった後で気がついた。

FireFoxではWikipedia使えねぇじゃん。

FireFoxのロケーションバーに入力された文字列はShift_JISでエンコードされるから、UTF-8の文字列をキーにしてるWikipediaでは当該記事を見つけられず、記事がないよと言われてしまう。オプションを開いても標準エンコードをUTF-8に変える選択肢のないFireFoxもダメぽだし、UTF-8前提でShift_JISを受けつけないWikipediaもダメぽだし、ダメとダメがぶつかってダメダメになっちゃった。

などとちょっと腹立ちまぎれに検索してみたら、「ツール→オプション→コンテンツ→フォントと配色→詳細設定→規定の文字エンコーディング」に設定があるらしい。深えよ！しかもフォントの問題じゃねえよ！しかしようやく「諸葛靚」が検索できるようになった…と思ったら「諸葛亮」だとエンコードに失敗して検索できねえよ！なんでかと思って調べてみたら、「諸葛靚」だとUTF-8で渡されて、「諸葛亮」だとShift_JISで渡されてる。またしてもお前か…！つねにUTF-8で送信してくれよ！*6

FireFox+Wikipediaでぐぐっても、関連の話題はあんまり出てないみたいだしOpenSearchでのトラブルがこれと関係ありそう。さらに検索するとFireFoxではなくMediaWikiの方に関連情報があった。主にFireFox側の問題なのに…。http://ja.wikipedia.org/w/index.php?title=Help:%E3%83%A1%E3%83%87%E3%82%A3%E3%82%A2%E3%82%A6%E3%82%A3%E3%82%AD%E3%81%AB%E9%81%A9%E5%BF%9C%E3%81%99%E3%82%8B%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6#.E6.97.A5.E6.9C.AC.E8.AA.9EURLユーザにabout:configをいじらせなきゃWikipediaが使えないなんて、その時点でFireFox腐ってる。いや、サーバに送信すべき文字コードは事前に分からないからFireFoxにそこまで求めるのは酷というものか。たしかにOperaみたいなやり方だとEUC-JPで受けつけてるサーバには文字列を送ることができないもんな。goo辞書とか。しかし、それにしても与えた文字�

Custom ButtonsはuserChrome.jsと同じくFirefoxにJavaScriptなユーザースクリプトを追加できる拡張機能なので、自分でいじれば何とかなるかなと思いEUC-JPやShift_JISなどの文字コードでも文字化けせずに日本語URLが表示できるlocationbar2ボタンを用意してみました。…といっても、前述のlocationbar2にデコード関数ライブラリのEscape Codec Library: ecl.jsを組み合わせて1行いじっただけだったり。あまり試していないため不具合はあるかもしれません。

本来は1クリックでボタンをインストールできるのですがうまくいかないため、Custom Buttonsを含めたインストール方法を以下に紹介します。

1. ふと今日は・・・・・・ Custom Buttons 日本語化から開発版のCustom Buttons 0.0.2alpha 日本語版をインストールしてFirefoxを再起動。
2. こちらのスクリプトファイル「locationbar2_jp.js」を新しいタブで開くかダウンロードします。ダウンロードした場合はテキストエディタなどで開いておきます。
   
3. 次のリンク「locationbar2（日本語の各文字コード対応版）」をクリックしてボタンをインストール。
   
4. 「ツールバーのカスタマイズ」を開き、（3.）で追加したボタンをツールバーにドラッグ＆ドロップで配置します。
5. （4.）で配置したボタンを右クリックして「ボタンの編集...」を選択し、「初期設定コード」欄に（2.）のスクリプトをすべて張り付けてください。「コード」欄は空白で構いません。
6. ふと今日は・・・・・・ Custom Buttons の自作ボタン配布に記載されているとおり、about:configから文字列「browser.urlbar.hideProtocols」を作成します。ロケーションバーから「http://」や「https://」などを隠したい場合は「http https」のように記入します。
7. Firefoxを再起動すると使用できるようになります。

以前紹介したロケーションバーの URL を分りやすく表示する Locationbar²（Bug 366797、作者のサイト）は、かなり頻繁に修正が行われていて、その動向には注目しています。最近、Hacking for Christ: Location Bar Proposal という記事でいくつかの提案が行われ、後でじっくり読もうと思っていたらさっそく Taken SPC で翻訳が公開されていました（Good Job!）。

ホスト名のハイライトにボタンを使うのはあまり美しくないですね。ようはドメインとパスがきちんと区別がつけばよいので、区切りの印を入れるのだけでも良いと思います。最新の Locationbar²
0.7.3.1 がまさにそれです。

l と i の区別のしやすさや、漢字などの IDN 表示時の識別容易性については、なんらかのズーム機能があると良いかもしれません。コンテンツはフォントサイズを自由に変更できますが、同じような仕組みがロケーションバーに合っても良いと思います（マウスオーバー時に大きなフォントでポップアップとか）。

簡単に説明すると、例えば hxxk.jp 内のタグ "ビール" が設定された記事のように、
URI
にマルチバイト文字列を含むリソースへのリンクを指し示したい場合、 hxxk.jp 内では <a
href="http://hxxk.jp/tag/ビール">hoge</a> と記述してもリンク元もリンク先も UTF-8
であるので Firefox では無事に該当リソースに到達できますが、同じようなリンクを Shift_JIS のリソースに記述すると
http://hxxk.jp/tag/%83r%81%5B%83%8B という URI
としてエンコードされてしまい、該当リソースに到達することができません。 なお、文字コードが同じであれば該当リソースに到達することができますが、そもそも仕様上非 ASCII 文字列を URI に直接記述することはしてはいけません。

そこで、私が hxxk.jp 内でタグページへのリンクを記述する場合は <a
href="http://hxxk.jp/tag/%E3%83%93%E3%83%BC%E3%83%AB">hoge</a>
のようにあらかじめ UTF-8 でエンコードした状態で記述しています。 このようなリンクであれば仕様の面でも問題ありませんし、 Shift_JIS のリソースや
EUC-JP のリソースに記述しても問題なく該当リソースに到達することができます。 ( よって、他の方がタグ "ビール"
が設定された記事を参照したい場合も、 UTF-8 エンコード済の URI をコピーすることで問題なくリンクすることができます。 )

さて、ここで Firefox のアドレスバーに、 URI
を直接入力してリソースを取得することを考えてみましょう。 現バージョンである Firefox 1.5.0.6 では、デフォルトでは
network.standard-url.encode-utf8 の値は false になっていますので、アドレスバーにマルチバイト文字列を含む URI を入力すると Shift_JIS でエンコードされます。 すなわち、
http://hxxk.jp/tag/ビール とアドレスバーに入力しても
http://hxxk.jp/tag/%83r%81%5B%83%8B という URI をリクエストした形になってしまいます。 そこで OpenCage:
Firefox urlエンコード機能をUTF-8化する方法。を参考に network.standard-url.encode-utf8 の値を
true にすると、 http://hxxk.jp/tag/ビール とアドレスバーに入力すると
http://hxxk.jp/tag/%E3%83%93%E3%83%BC%E3%83%AB という URI
をリクエストした形になり、無事に該当リソースに到達することができます。

usopionさんがUTF-8でURLエンコードされたURLを取得するブックマークレットを作成された。普段すべてのアドレスをUTF-8でエンコードするのチェックボックスを外して使っていたが、そうしているとUTF-8で記述されていないウェブページ上に全角文字を含むリンクが在った場合に問題が発生するようだ。ブログなどに投稿するためにエンコードされていない状態のURLを取得する機会と全角文字の含まれるURLへのリンクを踏む機会。どちらが多いと問われれば、私の場合間違いなく後者だ。

……ということで、x alt, u, r, lにGo to page, "javascript:prompt('現在の URI',encodeURI(location.href).replace(new RegExp('%2525([\\da-f])','gi'),'%25$1'));void(0);"を割り当ててみた。これで必要な時にはエンコード前のURLを取得できる。若干opera_exが不便になるが致し方あるまい。どうにかならないかといくらか試行錯誤してみたが、僕の手ではどうにもならなかった。

javascript:alert('<a href="http://matatabi.homeip.net/'+encodeURI(location.href)+'" target="_blank">'+document.title+'</a>');

コメントやトラックバックを送られた時に WordPress から通知メールが飛ぶようになっていますが、メールの件名や送信元などのヘッダに日本語の文字が含まれている時など、メールが文字化けするケースが多々あり、日本の WordPress ユーザの共通の悩みだったと思います。このプラグインを入れておくとそれらの悩みが解消されます。

問題の原因は WordPress がメールを送信するときに使う wp_mail() が日本語のヘッダを Base64 エンコードしていないところにあるようです。このプラグインは wp_mail() を独自に再定義して、正しく日本語メールを送られるようにエンコード処理を加えます。

効用のわりに名前が大げさですか? Nippon プラグインは日本語環境特有の問題をプラグイン一発で解消したいという願望から名付けられました。今後メールの文字化け以外でもプラグインで解決できる問題があれば機能を追加していくつもりです。

Update: お知らせ: WordPress 2.2 以降ではこのプラグインを使わないでください。2.2 以降では Nippon 2 プラグインをお試しください。

The thumbdrive style device plugs right into your Mac, and quickly installs it’s codecs into QuickTime (which includes any app that uses QuickTime’s encoding). It includes four codecs, iPod (best), iPod (small), PSP, and AppleTV. OK, fine, it doesn’t encode at any user defined specification, but it does convert into the four most common, used, and wanted formats. If you’re not into using QuickTime to convert, Elgato includes their own app for converting videos.

The app can batch convert, gives a video preview of what it’s encoding at the moment, and shows estimated time left and frames per second. Speaking of FPS, the Turbo converted a DivX video of mine to iPod at 48 fps. Not bad at all compared to the 15-25 fps that QuickTime encodes at for me.

一般にマルチスレッドに対応したエンコードソフトは、アーキテクチャやクロックが同じであればコア数が多いほうが有利だし、クロック差以上にコア数のほうが速度にもたらす影響は大きい。先に示したMainConceptのH.264 Encoderなどは、その典型的な例といっていい。

　しかし、今回のSSE4を利用したDivXでは、デュアルコアPenrynが、Core 2 Extreme QX6800を上回る速度でエンコードを終える結果を見せた。用意されていたサンプル動画が短いものであっため、数秒の差になっているが、一般的な長さの動画であれば、数分、数十分の違いとなるほどの大きな差をつけている。

　なぜSSE4を利用すると動画エンコードが高速になるかについても説明があった。その大きな理由として挙げられたのが、SSE4で追加された「MPSADBW」「PHMINPOSUW」の2つの命令だ。前者は複雑なSAD演算を行なうもの、後者はレジスタ内の値から最も小さなUWORDを抜き出すもの。こうした命令が用意されたことで、MPEGエンコードにおいて時間がかかるこれらの処理を少ない命令数で実行できるとしている。