SyntaxHighlighter

2012年2月9日木曜日

tinyURL で、長い data スキームを処理させる

tinyURL で、長い data スキームを処理させる

忘れたらググればいい に書いてあったことを見て、こんなのを考えてみました。

原理上は、どのような長さの data スキームであっても、 tinyURL で短い URL に変換できるはずです (対応ブラウザなどは調べていません)。

こういうことを tinyURL がよいと思っているかどうか不明なので、 GitHub などには置きません。
自己責任でどうぞ。

長い data スキームであっても tinyURL で処理可能にするスクリプト

できること

原理上、どれだけ長くても tinyURL で data スキームへリダイレクトさせることができます。

例えば、前に作ってみた iPhone Safari 上で動くテトリスでは、 http://tinyurl.com/7zsxzglのようになります。

このリンクをクリックすると、 Loading... と出た後、 data スキームで記述されたテトリスの画面になります。

本題とは関係ないですが、このテトリスは、枠内を、フリック・タップすることで、移動・回転です。

手順

あらかじめ、任意の長さの data スキームに変換済みの HTML ページを用意し、以下のようなコマンドで、 URL が生成されます。

なお、 Ruby スクリプト test.rb は、記事の末尾につけておきます。

原理

概要としては、だいたい以下のようになります。

  • data スキームを短い断片に分割し、それぞれを tinyURL で短縮 URL にしておきます。
  • トップページとなる Loading 用のページを用意します。最終的に、このトップページを data スキーム化し、 tinyURL で短縮 URL にしたものにユーザーはアクセスします。
    このトップページでは、以下のようなことを行います。
    • JSONP を用いることで、動的に、分割した断片の data スキーム文字列を集めて結合します。
    • すべての文字列が結合されたら、 location.replace で、生成された data スキームにジャンプします。

実際には、リンクリストになるように、少し工夫した断片 tinyURL を生成したりしていますが、原理は以上のようなものです。

スクリプトでは、対象となる data スキームファイルを用意するだけで、上記をすべて自動で行ってくれます。

というような方法で、あらかじめ tinyURL を生成しておけば、 Twitter などでも容易に長いデータや画像などのやりとりができると思います。

なお、繰り返しておきますが、 tinyURL 側が、これを良いと思っているのかどうかは分かりませんし、私も推奨しているわけではありません。
あくまで、技術的にはこういったことができる、ということだとご理解ください。

なお、ターゲットとなる data スキームファイルは、以下のように、 data: なども付与した状態で作成しておいてください。

data:text/html;base64,PD94bWwgd...

以下にスクリプト test.rb 全文を載せます。 Ruby 1.8, 1.9 で動くはずです。

適当に作ったので、バグなどあるかもしれませんが、ご了承ください。

なお、このスクリプトは、プロキシ下の環境ではうまく動かないかもしれません。
get_tiny_url の中をプロキシ対応にするのと、12行目の length を短めにすると、うまく動作すると思います。

2012年2月2日木曜日

Mozilla Vision 2012 Conference Day

Mozilla Vision 2012 Conference Day

忙しくてブログを書く暇がとれませんでしたが、少し前の Mozilla Vision 2012 Conference Day について書こうと思います。

この Conference は、「Web テクノロジーからアート、教育まで、オープンを考える」という主題のもとに開かれたもので、私は以下のセッションに出ました。

  • モバイル業界に真のオープンを!
  • Web 標準の今、そして未来
  • pdf.js - HTML5 と JavaScript の限界に挑戦する

以下では、出席したセッションを中心に、適当な雑感を書こうと思います。なお、英語が聞きとれない箇所もあったので、いつにも増して不正確な内容が多いかもしれません。

モバイル業界に真のオープンを!

Boot2Gecko プロジェクトの話でした。

簡単に書くと、 Android の基盤を利用し、真にオープンな Mobile プラットフォーム (スマートフォン) を構築する、ということが目的のようです。
Chrome OS のスマートフォン版という印象を受けました。

Mozilla としては、 PC の環境では Web ブラウザ上で非常にリッチな体験が可能になっており、それが OS を問わずに可能になっているが、スマートフォンの分野では Android, iOS, Windows Phone など、各社の独自規格が乱立しており、仕様としてオープンなものが中心になっていない、と考えているようです。

そこで Mozilla の解としては、 HTML5 を中心としたテクノロジでスマートフォンを動作させることを目指しているようです。

個人的には、近い将来に実現するのは難しい印象を受けました。

PC の場合、連綿と続いてきた x86 アーキテクチャや、 ACPI という OS とファームウェアのインターフェース、 UEFI といった具合に (オープンかは別として) デファクトスタンダードな仕様が固まっています。

だから Linux のようなものを簡単にインストールできるわけであり、 Chrome OS も作ることが可能なのだろうと思います。

一方で、 Android の方に関しては、ハードウェアやファームウェアの仕様は今後まだまだ流動的な状態が続くのではないだろうかと思います。
そのため、 Mozilla が独自に各社からどんどん出てくる Android 機種に対して、対応する Boot2Gecko を開発するのは難しいのではないかと感じました。
少なくとも、近い将来に「スマートフォンの OS を手軽に入れかえる」ということが一般的になることはないと思いました。

また、私の隣りの人がとても流暢な英語で質問していましたが、結局 HTML5 上ですべてのアプリを動かそうとすると、 Android や iOS のように、 Native に近い環境でアプリを動かすのに比べ、どうしても動作速度の面で劣るのではないかという懸念があります。

これらのことから考えると、私としてはすぐに一般的になることはないように感じました。

Web 標準の今、そして未来

こちらは、「オープンな仕様を目指して」といった内容でした。

CSS の策定などにも関わってきた発表者の方が、「オープンな仕様がいかに大事か」や「オープンなプロセスを保つためにはどのようにするべきか」などについて、熱く話していました。

個人的には、 HTML, CSS の歴史の裏話は面白かったのですが、発表者と自分自身の温度差が大きかったです。

pdf.js - HTML5 と JavaScript の限界に挑戦する

こちらは、 JavaScript で PDF を表示するという挑戦でした。

技術寄りの話だったこともあり、非常に面白い内容でした。

冒頭は、お決まりの「PDF のプラグインは closed だからよくない」ということからスタートでした。

ただ、技術やユーザー視点でのメリットとしては、「JavaScript で提供することで、 PC, Mobile のいずれでも使える」や「ブラウザの挙動 (戻る/進む など) と、一貫性のある動作を提供できる」などがありました。

技術的には以下のような方法で取り組んだそうです。

基本的な描画

canvas で描画する。 SVG は用いない。

画像/文字の描画

PDF は、ブラウザがサポートしていない画像形式やフォント形式をサポートしている。

画像に関しては、 JavaScript でデータを解析し、 canvas に描画している。
フォントに関しては、ブラウザ未対応な形式のフォントデータを、ブラウザが対応している OpenType に変換することで、対応した。
このフォント部分の解決がなければ、プロジェクトは頓挫していたらしい。

リンク機能

リンク機能に関しては、ブラウザの「戻る」、「進む」と完全に連携しており、プラグインよりもずっと使いやすくなったとのことだった。

テキスト選択

canvas に画像として描画しているので、テキストを選択することができない。
これを解消するために、 canvas の上に、透明な色で別途文字を通常のテキストとして配置することにしたらしい。
この文字自体は、フォントなどはそれほど考慮されていないもので、あくまでテキスト選択ができるようにするためのものらしい。

このあたりまでくると、「そこまで頑張らなくても。。。」という気がしなくもない。

高速化

UI 以外は、極力 WebWorker を使って Core を分散することで高速化を実現したとのこと。

いずれも、技術的には面白かったのですが、少しやり過ぎな感がありました。


行く前は、 Google Developer Day のようなものを期待していたので、そういう意味では期待外れでした。

一方で、 Mozilla が「オープン」というものを、強烈に推進しようとしているという熱意は、異常なほどに強く感じました。WLAN のパスワードからして whatisopen でしたし。

そういう意味で、 Netscape という膨大な資産をつぎこんで作られたプログラムを公開するという、考えられないような決断をしたことからスタートした Mozilla という組織は、方向がぶれないまま進んでいるという印象を受けました。