パスワードを忘れた? アカウント作成

levelさんのトモダチの日記。 スラッシュドットのRSSを取り込んでみよう。

1926134 journal
日記

Torisugariの日記: ウェブのリダイレクトについて (後)

日記 by Torisugari

2.3 meta要素のrefresh指示子によるリダイレクト

これは前項の「HTTPのRefreshヘッダによるリダイレクト」をHTMLだけで実現するための機能であり、長らく独自仕様でしたが、HTML5で標準化されました。

meta http-equiv=refresh – “refresh” pragma directive

全ての主要ブラウザが既に実装しており、サーバー側の設定ができない場面や時間差をつけてリダイレクトしたい場合に多用されています。JavaScriptを切っていても動作するので、特に理由がない場合は、300番台のリダイレクトかこれを使うのが望ましいでしょう。

meta要素によるリダイレクトでは、仕様上、セッション履歴(「戻る」ボタンで戻れる履歴)に痕跡が残りません。Geckoの場合、私の記憶が確かなら、かなり長時間(300秒以上?)の時間指定で履歴に残すという挙動だったと思いますが、もとよりリダイレクトが目的なら、そんな時間指定をすべきではないでしょう。

2.4 JavaScriptによるリダイレクト

JavaScriptでリダイレクトを行うのは外道とまでは言わないものの、決して王道といえるようなものではありません。JavaScriptでページ遷移が可能なのは、複雑な条件下でそれを必要とする場合があるからであり、決してリダイレクトのように単純な条件でのページ遷移をするためではないからです。

しかし、理想は得てして現実の前に散る運命です。実際のところ、HTMLはJavaScriptによるリダイレクトをある程度想定しています。私が前項で薦めたmeta要素も標準準拠ではないのとアクセシビリティの観点から、悪し様に言われた時期がありました。例えば、2007年の啓蒙記事「Don't break the back button!」などがそうです。まあ、今でもベストとは言いがたい側面がありますが、どこかで利便性とのバランスをとる必要があります。

2.4.1 Locationオブジェクトによるリダイレクト

JavaScriptでリダイレクトする場合、最もよく使われるのがLocationオブジェクトでしょう。ここで問題になるのはどのタイミングでリダイレクトを行うか、です。HTML5に準拠している場合、文書のloadイベントの前後で挙動が変わります。具体的に言うと、例えば、scriptタグの中に直接書く場合、

<script>
  window.location.href = "http://www.example.com";
</script>

<script>
  window.location.replace("http://www.example.com");
</script>

は同じ振る舞いをし、いずれもリダイレクト元がセッション履歴に残りません。

一方、イベントハンドラから呼ばれる場合、

<body onload="setTimeout(function(){window.location.href = 'http://www.example.com/';}, 0);">

<body onload="setTimeout(function(){window.location.replace('http://www.example.com');}, 0);">

を比べると、後者は同様にリダイレクト元がセッション履歴に残らないのに対して、前者はリダイレクト元がセッション履歴に残ります。これは、Location::hrefへの代入、あるいはLocation::assign()の呼び出しが文書の読み込み完了より早いかどうかで、「リダイレクトのような挙動」なのか、「リンクを踏んだような挙動」なのかを判断すべき、とされているからです。

リダイレクトだけが目的なら、曖昧さを消すためにもLocation::replace()を使う方が良いでしょう。

2.4.2 DOMイベント系によるリダイレクト

説明すると長くなるので、実際に動くコードを書いてみました。

HTMLFormElement::submit()で、リダイレクトする例:

<form id="foo" action="http://www.example.com/" method="GET"></form>
<script>
  document.getElementById("foo").submit();
</script>

HTMLElement::click()で、リダイレクトする例:

<a id="foo" href="http://www.example.com/">foo</a>
<script>
  document.getElementById("foo").click();
</script>

もともと、DOM2でのclick()はinput要素にしか使えませんでしたが、HTML5では普通のリンクにも使えまます。HTMLDocument::createEvent()でclickイベントを作成すれば、HTMLElement::click()と同じ効果ですから、リダイレクトも実行できます。正直な話、わざわざリダイレクトをするためにa要素を用いる理由は見当たりませんが、簡単に書けるのも確かです。ただし、リダイレクト元がセッション履歴に残ります。

一方、form要素を使ったリダイレクトは、a要素の場合とは違って、ある程度の実用性があります。新たにPOSTメソッドでリダイレクトするのは、HTMLFormElement::submit()HTMLElement::input()などをform要素に作用させてリクエストを送るしかないからです。しかも、リダイレクトですから、XMLHttpRequestとは違ってクロスドメインの制限を受けることはありません。ちなみに、「クロスサイトリクエストフォージェリ(CSRF)」という攻撃は、端的に言ってこのリダイレクトのことを指します。

2.4.3 Historyオブジェクトによるリダイレクト

History::back()History::forward()はリダイレクトの一種です。ただし、用途は明確なので大きな問題にはなりにくいでしょう。

HTML5で加わったHistoryオブジェクトの新機能にHistory::pushState()History::replaceState()があり、これらを使うと文書(document)を遷移させずに場所(URL)を移動させることが出来ます。ですから、最初に定義した「リダイレクト」の範囲に収まるかどうかは微妙なところですが、Location::reload()などと組み合わせると紛う方なきリダイレクトになります。ただし、あえてこの方法でリダイレクトする意義はないでしょう。また、これらはドメインをまたいでURLを設定できるわけではないので、使える局面は限られています。

2.4.4 window.open()によるリダイレクト

例えば、

<script>window.open("http://www.example.com/", "_self");</script>

でリダイレクトさせることができます。ただし、これもリダイレクト元がセッション履歴に残ります。

JavaScriptに関しては長くなったので、まとめておくと、実用上は、ほぼ、Location::replace()HTMLFormElement::submit()の二択だと言えます。

2.5 プラグインによるリダイレクト

私の知る限り、ブラウザの機能を使うリダイレクトは以上4つのいずれかで、残るはブラウザに後付けされた機能ということになります。しかし、例えばFirefoxやChromeの拡張機能としてリダイレクトする機能を追加することは可能ですが、それではあまりも状況が特殊すぎるので、一般論として展開することはできません。ウェブ開発者にとっては頼りない話ですし、ユーザーにとってみれば気に留める必要もありません。

ただし、多くの人がブラウザにインストールしているソフトがあれば話は変わってきます。つまりFlashのことですね。

そもそも、NPAPIにはNPN_GetURL()という関数があり、この機能はほぼ、window.open()に相当するので、前述のようにリダイレクトが可能です。PPAPIにもNavigateToURL()という名前で備わっており、FlashのActionScriptでは、navigateToURL()によりラッピングされています。

また、ActiveXを使っていたり、NPRUNTIME以降の世代のプラグインはそのウィンドウのグローバルスコープからJavaScriptを実行可能なので、Flashの場合、2.4節で説明したJavaScriptのリダイレクトについては、ほぼそのまま当てはまります。ただ、ユーザー側の視点から考えると、スクリプトがテキストファイルとして人間が読める形で提供されているとは限らないので、その点には特に気をつける必要があるかもしれません。

3. リダイレクトの倫理

リダイレクトは、その本来の用途とはズレた目的に使われることが多い機能です。それは、あるいは検索エンジンによるトラッキングであったり、あるいは広告業者による広告への誘導であったりします。私は、こういった目的に正当性がない、とまでは言いたくありません。しかし、ほとんどの場合、ユーザーの断りなしに行われている点については議論の余地があるでしょう。

私はこれらの倫理的問題を直接解決するつもりがないので、問題提起に留めておきますが、リダイレクトの支持率(あるいは不支持率)といったようなものは常に気にしておくべきだと思います。

ところで、私はリダイレクトのやり方はこれで全部だと思っているのですが、一字千金を気取るつもりもないので、抜けている部分があれば、どこかにコピペする前に直しておいてください。

1917508 journal
日記

Torisugariの日記: ウェブのリダイレクトについて (前)

日記 by Torisugari

1. リダイレクトの意味と範囲

リダイレクト(redirection)は、あるいは漢字で「転送」とも呼ばれていたりしますが、言葉の問題として捉えるなら、なかなかに複雑な側面があります。ともすれば、redirectionと全く同じ挙動を、文脈によってrefreshやreloadと呼ぶことがあるからです。不毛な議論を避けるために、ここでは「コンテンツ側がURLを勝手に変更すること」としておきます。

余談ですが、例えば、英Wikipediaの記事「URL redirection」では、新しいリソースの場所をリンクで示す、いわゆる「手動リダイレクト」もリダイレクトに含めています。

例: 

このページは移動しました。新しい場所へは __ここ__ をクリックしてください。

ですから、(Here病については勘弁してもらうとして)上のような意味で使うときは、厳密に言えば「リダイレクト」ではなく「自動リダイレクト(自動転送)」とすべきだったのかもしれません。英単語の意味は「方向を変える、転進」ですから、「コンテンツ側がURLを勝手に変更すること」は明らかに意味が狭すぎるわけです。しかしながら、多くの人がこの意味で使っていますし、おそらく誤解を招くことはないと思います。

細かい話をしていけば、HTTPより下層での負荷分散なども「ウェブのリダイレクト」と呼び得るでしょうが、それらもここでは割愛します。

2. リダイレクトの種類

リダイレクトをされるユーザー側からみると、どれも同じに思えますが、リダイレクトを行うコンテンツ側としては、様々な手法があります。とりあえず、それらを総論として"全て"把握するところから始めてみましょう。

  1. HTTPのステータスコード(301, 302, 303, 307) + Locationヘッダ
  2. HTTPのRefreshヘッダ
  3. meta要素のrefresh指示文
  4. JavaScript
    1. Locationオブジェクト
    2. DOMイベント系
      1. HTMLFormElement::submit()
      2. HTMLElement::click()
      3. HTMLDocument::createEvent()
    3. Historyオブジェクト
    4. Window::open()
  5. プラグイン

大きく分けるとこの5つです。では、各々を順に見ていきます。

2.1 HTTPの300代ステータスコード(301, 302, 303, 307) と Locationヘッダによるリダイレクト

おそらく、先に挙げた5つのうち、この方法が最も一般的に使われているリダイレクトでしょう。ただし、少なくともLocationヘッダでリダイレクト先を指定しなければいけませんから、.htaccessなどの設定ファイル、もしくはHTTPのResponse Header(応答ヘッダ)を記述できるCGIを作る権限が必要となります。現代的なホスティングサービスでは、その手の権限で困っている人は少ないとは思いますけれど、そういう意味では最もハードルが高い手法でもあります。

具体例や各ステータスコードの詳しい説明は他の解説に譲るとして、細かく見ると、まず、307だけはPOSTを含め全てのメソッドを通す、という点に註意が必要です。逆に、303が通すのはGETとHEADだけです。私は、ウェブ開発者たちは規格と良識に従ってステータスコードを選んでいると信じていますが、実用上、307と303を使い分ける理由は「(掲示板などの)フォームからのリクエストか否か」に尽きるでしょう。自分が作った掲示板からのリクエストなら307でないとまずいでしょうし、あるいは、他人の作ったフォームから踏まれる可能性があるなら、安全性を考慮して303にすべき場合もあるでしょう。

問題は301と302です。POSTメソッドに関して、301(及び302)はPOSTを通すべきだとRFC 2616には書いてあります。

Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

この"some existing HTTP/1.0 user agents"はNetscapeとIEのことで、実質的に名指しで"erroneously"と非難しているわけですが、Trident系(IE), Gecko系(Firefox), Webkit系(Safari, Chrome)は現在も301でPOSTメソッドを通しません。つまり、"some existing HTTP/1.0 user agents"の後継者である主要なexisting HTTP/1.1 user agentsの全ては、POSTをGETに変換します。Geckoに関してはBug 190630、W3CのメーリングリストはIssue 160を参照してください。XMLHttpRequestとの整合性に関しては、XMLHttpRequest HTTP Feature Testsが参考になると思います。

結局のところ、どのような理由にしろ、GETとHEAD以外を使う場合は307にすべきでしょう。

ステータスコードの300は、ja.wikipedia.orgで挙げられている例の「XHTML1.1のDTD」のように、選択肢を示す必要があります。つまり、典型的な手動リダイレクトの例であって、本来はこの文章の守備範囲外です。しかし、Geckoの場合、301、302、303、307の4つに加えて300もリダイレクトの対象になっており、Locationヘッダを指定しておけばリダイレクトされます。私は決して勧めませんが、興味がある人は他のブラウザの挙動も調べてみるといいでしょう。

最後に、リダイレクトに最も興味がある層はSEO関連だと思いますので、一言付け加えておくことにしますが、ユーザーにとって最も歓迎すべきリダイレクトは301でしょう。そして、検索エンジンにとってもそれは同じですから、301には最大限の配慮がなされているといっても過言ではなく、301を奨励する文言を随所で見かけます。私も大変結構なことだと思います。ただし、Cache-controlなどで指定しない限り、301のResponse Headerはほぼ無限のキャッシュ寿命を持ちます。つまり、一度301リダイレクトにしてしまうと、「やっぱりやめた」というのは利きません。普通のページならユーザーが強制リロードすることもあるかもしれませんが、リダイレクトの場合は、当然、リロードが不可能です。300番台はResponse Bodyのサイズもゼロなので、ユーザーが明示的にキャッシュを消さない限り残り続ける可能性があります。こうなると、サーバー側が新たにどういう設定にしようとも、それをUAが読みに行くことはありません。だからこそ、301は歓迎すべきリダイレクトなのです。しかし、後で別の用途に使う場合、取り返しがつきませんから、ファイル階層の上の方、例えばトップページなんかを301にする際は、もう二度と使わないという決意を要します。そして、敢えてやるなら、Cache-controlの指定が必須なんだろうと思います。ちなみに、私は実験的にトップページを301にしていますが、キャッシュ云々の制御はしていません。

2.2 HTTPのRefreshヘッダによるリダイレクト

HTTPの仕様にはRefreshヘッダに関する取り決めがありません。つまり、独自仕様なのですが、主要なブラウザは全て対応しています。Refreshはもともと、サーバーからのプッシュを擬似的に実現するために定期的なリロードを促す機能ですから、これをリダイレクトに使うことはまずないでしょう。ただ、メリットはなくとも、可能ではあります。

1107659 journal
日記

Torisugariの日記: 九州電力と田代まさしのセキュリティホール 7

日記 by Torisugari

今年、玄海原発の稼動再開の可否を巡って社会的なトラブルがありました。知らなかった、あるいは忘れてしまった、という人はWikipediaの記事をどうぞ;「九州電力やらせメール事件」。

この問題は、九電社長の進退や佐賀県知事の関与、第三者委員会の立ち回りなど、なかなか複雑な様相を呈しています。あるいは、曖昧模糊としたままで決着が図られるのかもしれません。ただ、私は、仮に、経営陣や政治家たちが全て辞職したとしても、まだ割り切れない部分が残ると思います。すなわち「やらせメール」そのものの倫理的な是非です。

話はガラリと変わりますが、米国のTIME誌が年度の表紙を飾る人物をインターネット上で募集した時に、「田代まさし」さんが1位になった、という件をご存知でしょうか?あるいは、ポケットモンスターの人気投票で「レアコイル」が2位になったり、イナズマイレブンの人気投票で「五条勝」が1位になったという話でも結構です。

雑誌社やアニメの放送者は、本来、彼らの好きなようにコンテンツを作り、また、作られたコンテンツについての責任を被ります。ここまでは良しとしましょう。しかし、「読者や視聴者の意見を反映させる」という手法をとると、とたんに話がややこしくなります。「発信者が作成して、受信者が消費する」という形ではなく、「『投票者』が作成して、発信者が中継し、受信者が消費する」という形になるからです。

ここでいう「投票者」は「発信者」側の想定では「受信者」と同一であって、その仮定が正しい限りにおいて大きな問題にはなりません。しかし、実際の結果を眺めてみると、「投票者」と「受信者」は同一ではありません。投票の母集団は偏っており、その結果が「田代まさし」「レアコイル」「五条勝」なのです。ひとつ注意を喚起しておきたいのは、この結果は偏ってはいても、必ずしも「不正」と見做すことはできない(まあ、「田代まさし」に関しては微妙ですが)という点です。想定通りではないが、不正でもない、そういう現象なのです。

発信者はコンテンツに飢えています。新聞にはその黎明期から投書欄がありますし、深夜ラジオが電話やFAXで音楽曲のリクエストを募集するのも同じ理由です。その延長線上に「ケータイ大喜利」なんかがあって、さらにその先に「原発再開について、視聴者のメール紹介」があるのです。

放送者と視聴者の関係を一つのシステムになぞらえるなら、「九州電力やらせメール事件」は次に挙げた2つの要因からなる不具合です。

  1. 視聴者は放送者を信用するあまり、放送内容が妥当なものだと思い込まされてしまう。
  2. 放送者ではない第三者が放送内容を操作できてしまう。

九州電力は、このセキュリティホールを突いて、「自らの意見」を「妥当な意見」へと特権昇格させました(*I)。九州電力やそれに関わった人々が何らかの責任を取らなければならない、という点には、私も同意します。しかし、これは「不正」だったのですか?罰則を与えるとして、その根拠は誰が示すのでしょうか?巨大な利益が絡む以上、一罰百戒はありえません。経営陣や政治家の首とは比べ物にならない額の金銭の問題だからです。この種の企業努力が、念仏のようにコンプライアンスを唱えることによって解決された例もありません。

再発防止を謳うのなら、2.の穴を塞ぐべきではないでしょうか?

近年、いろいろな放送局、とりわけNHKが「視聴者のご意見」を熱心に紹介するのを見て、不安な気持ちになります。特に、番組中に意見をファックスやメール、あるいはテレゴングのようなリアルタイム性の高い手段で募集して、終了前に放送するタイプが最も危険です。コメントを選ぶスタッフや読み上げるアナウンサー達は、十分な教育が施されているはずですし、その点に不満はありませんが、彼らとて専門外の分野もあるでしょうから、限られた時間の中では、つい、うっかりと、という事態は十分に考えられます。

明日にも、ワイドショーのアナウンサーが、「他多数からいただきました」と前置きして、「砂糖水で希釈したら、病気が治りました」とか、「納豆を食べて○Kg痩せました」とか、「水に『ありがとう』と言ったら、…」といった偏った意見を公共の電波で流すかもしれない、そういう時代に我々は生きているわけです。科学知識のように、白黒をはっきりつけやすい話題ならまだマシですが、政治問題になると、放送者や視聴者が十分注意していても防ぐことはできません(*II)。それを証明したのが九州電力であり、その意義は大きい、と私は考えます。

*I.
ちなみに、1.の穴を予め塞いであるある人、すなわち「マスコミの言うことは1から10まで信用できない」という社会不適合系の妄想癖がある視聴者には通じなかったはずです。

*II.
「やらせメール」は内部告発が元で発覚しましたが、逆に言うと、金銭をケチらずに職業的にこの種のマーケティングを行っている人々に頼んでいたら、今でも真相は闇の中だった、ということです。

338225 journal

Torisugariの日記: HTMLのlongdesc属性について 1

日記 by Torisugari

ウェブに限らず、コンピューター関連の機能は、日夜、新しいものが生み出されています。しかし、人間の扱いきれる量には限りがあるものですから、それは、生き残ることができないモノが沢山ある、ということでもあります。誰にも見向きもされずに、比較的早い段階で消えてくものもあれば、5年、10年、といった、この世界では由緒を誇れる年月を経たものでも、いつの間にか無くなっていたりします。裏を返せば、「化石のような時代遅れの機能だった」ということになるのでしょうか。まあ、消えていくのは、大抵の場合、ほとんどの人にとって不要なものですから、そういう意味での「惜しさ」というものはありませんが、一方で、妙に心惹かれるものがあります。

Firefoxに関して言うなら、今まさにMicrosummariesが消えようとしています。私自身は一度も使ったことがないので、その点には痛痒を感じませんが、対応ページの提供者・利用者にとっては残念なことでしょう。大局的な観点からは、失敗(と、もう、この時点で言ってしまっていいと思うんですけれど)の理由はいくつかあるでしょうけれど、機能カットの直接的な理由はメンテナンス不足、つまり、人的資源が足りていないということです。何分、ユーザーのある話ですから、この機能を拡張で再実装して軟着陸、といきたいところでしょうが、拡張に移すのは「人が足りない」という現象への解決策になっていませんからね。相応にハードなランディングになりそうです。

では、img要素のlongdesc属性について。

HTML4.01には、img要素の属性にlongdescというものがあります。これはその名(=LONG DESCription)の通り、(主に視覚障害者のために)画像に対する詳細な記述をつけるための属性です。使い方に関してはfaireal.netの「<img longdesc=...>について」が詳しいです。しかし、この属性はHTML5で廃止となりました。一見、便利そうな機能であり、放っておいても害はなさそうなのに、わざわざ「廃止」にしてしまったのです。

無論、これは様々な人の意見や思惑を反映しているのですが、とりわけ、その決定打となったのは、「The longdesc lottery(longdesc籤)」という記事でしょう。要点をまとめると、以下のようになります。

  • Googleのキャッシュから抽出した10億のimg要素のうち、longdesc属性があるのは130万(0.13%)。
  • 130万のうち、書式が間違っているものを除くと5万(4%)。
  • 5万のうち、意味が無いものを除くと1万。
  • 視覚障碍者側からも、あまり歓迎されていないように見える。

つまり、これは、2007年の時点で、「任意のimg要素に役に立つlongdesc属性がついている確率は、10万分の1である」という調査結果なのです。ちなみに宝くじで言うと、10万分の1は大体1000万円の当選確率です。例:みずほ銀行の「1000万サマー」

生データでさらっと10億を持ってこれるGoogleも凄いですが、確かに、10万分の1はかなりインパクトのある数字です。この低さの理由を挙げるなら、やはりUAの不備に言及しないわけにはいかないでしょう。実際、「longdescは使われていないので付けない方が良い」といったような文言を見た記憶があります。UA側が対応していなければ、ウェブデザイナがその「対策」をとるのは当然の話であり、そういった悪循環が高じて、この数字になってしまったのでしょう。

longdesc属性の値がURIである、ということは、ウェブサーバ側は別のファイルを用意しなければいけない、ということです。しかし、画像にだって文脈があるわけですから、ある画像について、文書Aにおける説明が、そのまま文書Bで使えるとは限りません。そうなると、URIで指定するメリットは、「同じ事を何回も書く手間を省く」という方向よりは、むしろ「マークアップを許すかどうか」、「詳細な説明方法を提供できるかどうか」という点に現れているように思われます。単純な文字情報なら、alt属性で十分ですからね。

「百聞は一見に如かず」の諺にある通り、画像・映像に由来する視覚情報を言語で説明する場合、あるいは千言万語を費やしても追いつかない、という状況は容易に想像できます。そういった場合、説明のための文章が長くなるのであれば、マークアップできたほうが確かに便利でしょう。しかし、この理想論はやはり空論であって、その結果が前述の散々な数字なのです。あのエラーの割合は、つまるところ、longdescにURIを記入しなかった、ということに他ならないのですから。

目的が崇高で一見して合理的に見えても、実用段階における方法論にささやかなケチが付けばあっけなく沈んでしまう、それを体現しているのがこのlongdesc属性ではないでしょうか。良いところも悪いところもある、というのは一般論として当然の話で、この数字を伏せてディベートをすれば結構戦える、という程度にはlongdesc要素の存在意義に説得力があると思うのですが、現実は非情なのです。

では、longdescを使わないとして、先に挙げたような状況にどう対応するのか、という問題がありますが、この答えはそれほど簡単ではありません。各人にそれぞれ主張があって、統一的な見解はないといっていいでしょう。

1つ考えられるのは、「かなり長いalt属性をつける」ということです。IEは8からalt属性がポップアップしなくなっているので、本来の意味でalt属性を使っても、さほど問題は起きなくなっています。ですから、alt属性に全ての説明を詰め込むのは理に適っています。

また、ややマニアックですが、html5ではaria-が接頭辞についた属性が正式に採用されています。「3.2.7 WAI-ARIA

Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below.

ですから、画像の説明にマークアップをしたい場合、aria-descirbedby属性が本命かな、と私は思っています。もっとも、「WAI-ARIA 1.0 Authoring Practices」ではlongdescとの差別化について触れられていますが、もはや、今となっては詮の無い話でしょう。

HTML5はHTML4.01の後継規格ではありますが、完全にHTML4.01を置き換えるものではありません。音声ブラウザを含む各UAはHTML5への対応を進めるとともに、HTML4.01をサポートしつづけるべきだと思います。そういう意味では、longdesc属性は完全に死んでしまったわけではありません。ただ、現時点では将来性がないのも事実ですから、やはり、これから書くウェブページにlongdesc属性を入れるのはやめておいた方が良いでしょう。とはいえ、aria-descirbedby属性がlongdesc属性と同じ道を辿らない、とは誰にも言えないわけで、今、ベストに見える選択肢を他人に奨めるという行為にはなかなか難しいものがあります。そもそも、ハイフンがアリなら、XML系で名前空間を決めていたのは何だったのか、とか、こんなに長いのでタイプミスしないのか、とか、ariaDescribedbyがinterCaps表記で将来後悔しないのか、とか、いろいろ気になる点はあります。

最初に言ったように、栄枯盛衰(というほど栄えてもいませんでしたが)を眺めるのは興味深いものです。が、対応策が今日明日にも必要だ、という人はそんなことも言っていられないでしょう。とりあえずは、w3に置いてあるレポート「Techniques for providing useful text alternatives」が参考になると思います。少なくとも、選択肢だけは十分に用意されているのです。

311535 journal

Torisugariの日記: Firefox4とマルウェア

日記 by Torisugari

1.
ずっと後に(年単位で)日記を読む人のために予めことわっておきますが、これを書いているのはFirefox 4.0がリリースされてまだ数日という状況です。

現在Firefox4のクラッシュレポートのうち、トップを走っている「mozalloc_abort...」は2位以下にダブルスコアをつけている優秀なやつなんですが、どうもこれはマルウェアが引き起こしているんじゃないか、という疑惑が濃厚です。Bug 633445のコメントを綜合すると、

  • Firefox4のベータ版から報告が出るようになった。
  • DLL名がバラバラ。
  • ナイトリービルドの被害はゼロ。

とあって、まあ多分そうなんでしょう。

「ナイトリービルドの被害がゼロ」というくだりは、プロセス名(あるいは実行ファイルのパス)が"Minefield"の時は活動せずに、"Firefox"だけを狙い撃ちしている、という観測が出ています。つまり、プロファイルフォルダやその他の場所に正規の方法でインストールされている拡張(例えばツールバー系)の類ではない、ということです。私はこの道の専門家ではありませんが、想像するに、いろんなソフトウェアの皮を被ってインストールされているバイナリが、Firefoxにちょっかいをかけていて、それがFirefox本体のバージョンアップについて来れずにクラッシュしている、というストーリーなのでしょう。

この例は、たまたまクラッシュしているから目立っている「氷山の一角」と考えるべきで、おそらくよくできている奴はFirefox4でも変わらずに動いていると想像できます。クラッシュレポートに付いているコメントによると、特定の動作がトリガになっているというよりも、起動直後にクラッシュして、その後も再起動とクラッシュを繰り返す症状のようです。各アンチウィルスベンダの対応はまだ鈍いようですね。特に目新しいものでもないはずですが、まずは原因を特定しないことには、対策は難しいでしょう。そして、次のバージョンはこんなに目立つはずもありませんから、我々の心の裡には疑惑だけが残ることになります。

ブラウザのアップデートに追随しなければいけないマルウェアの作者も大変だな、という感想が頭をよぎったことは否定しません。しませんが、冗談は抜きにしても色々考えさせられる事例じゃないですかね、これは。

2.
input.mozilla.comのコメントは(bugzillaや掲示板に比べたら)結構面白い意見がちらほらあるんですけれど、その中でも面白いと思ったのが、apple.comのビデオが表示されないという件です。まあ、当たり前というかなんというか、携帯電話の広告をするのに「Quicktimeをインストールしてください」って言えてしまうAppleは、決して悪い意味ではなく、すごいと思いました。

305503 journal

Torisugariの日記: アクセシビリティとリテラシ 2

日記 by Torisugari

(APIについて)
俗にアクセシビリティAPIと呼ばれているものがあります。具体的に言うと、WindowsならMSAAで、GNOMEならAT-SPIなどのことです。プログラミングに興味がない人はあまり耳に馴染みの無い用語でしょうが、細かい固有名詞はともかく、そういった人にも決して無関係な話ではありません。

そもそも、アクセシビリティAPIとは、音声読み上げソフトや拡大鏡ソフトのために、プラットフォーム側が用意した規格に沿って、対応するアプリケーション側で実装されている機能のことです。誤解を恐れずに言えば、音声読み上げソフトや拡大鏡ソフトのためのバックドアです。ただし、これはプラットフォーム公認でアプリケーション側がわざと開けている広義のバックドアなので、セキュリティホールの類を心配する必要はありません。ただ、この事実をある程度正確に把握しておくべきだとは思います。

例えば、「現在ブラウザで閲覧中のウェブサイトのURLを知りたい」とします。この時、人間ならば、画面を見て、ブラウザのURLバーに表示されている文字を読めば、すぐ分かります。しかし、ソフトウェア的な解決はそう簡単ではありません。人間の手順に倣うなら、まずアプリケーションのスクリーンショットを取って、URLバーの位置を判断し、画像をOCRにかけて書かれている文字を文字列に変換する、という手順を踏むことになります。

無論、これは馬鹿げた方法です。なぜなら、ブラウザ自身はURLを文字列として保持しているはずなので、これをデータとして教えてもらえば済む話だからです。ここで、素直に考えると、ブラウザに寄生して、こちらの要求に応じてURLを漏らしてくれるようなソフトウェアがあればいいということになります。このようなソフトウェアはMozillaの用語では「拡張」といいます。そしてこれが正解です。適切な拡張を作ってインストールすれば、別にスクリーンショットを解析しなくても、ソフトウェア的な解決でURLを知ることができます。

もう勘のいい人は分かっていると思いますが、「現在ブラウザで閲覧中のウェブサイトのURLを知りたい」という技術的な要求には、実はスクリーンショットの解析も、拡張のインストールも必要ありません。近代的なブラウザにはウェブサイトのURLを漏らす機能が予め備わっています。それがアクセシビリティAPIです。実際のところ、Firefoxの場合は、前二者の方法に比べて遥かに簡潔にこのようなソフトを書き上げることができます。ここに設計上のブレイクスルーがあります。

もともと、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」という機能は、介助ソフトに必要な機能として実装されているわけですが、この機能が介助ソフトにだけ有用な機能ではないことは自明でしょう。例えば、アクセスログを作成する時などにも使えます。従来、「URLを知りたい」というFAQに対しては「プロクシを設置しろ」とか「netstat系で確認しろ」と答えるのが一般的であり、ブラウザから直接答えを引き出すのはあまり筋が良い技術とは考えられていませんでした。

(続く)
(続き2011-03-11)

もともと、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」という機能は、介助ソフトに必要な機能として実装されているわけですが、この機能が介助ソフトにだけ有用な機能ではないことは自明でしょう。例えば、ローカルのアクセスログを作成する時などにも使えます。従来、「URLを知りたい」というFAQに対しては「プロクシを設置しろ」とか「netstat系で確認しろ」と答えるのが一般的であり、ブラウザのように複雑なアプリケーションから直接答えを引き出すのはあまり筋が良い技術とは考えられていませんでした。しかし、アクセシビリティAPIを通じてURLを取得するのは、「プロクシでログを取る」に匹敵するくらいには十分合理的な方法であり、データの蓄積・評価方法によっては、より相応しい場合も多々あります。従業員のブラウザを監視するシステムの場合、「休み時間中にスラッシュドットにアクセスする」のと「就業時間中にそれを眺める」のは決定的に異なった評価をされるべき行動であるにもかかわらず、ネットワークのアクセスログやブラウザの履歴ではこの2者の区別がつきません。しかし、アクセシビリティAPIを使えば「ブラウザで閲覧中のURL」がわかるので、就業時間に閲覧中のURLをシステムが記録しておけます。少なくとも、この用途においてアクセシビリティAPIを使った方法は、プロクシその他の方法に比べて頭1つ飛びぬけています。

繰り返しますが、アクセシビリティAPIは、アクセス能力の弱者への救済を目的に作られた機能です。しかし、この機能をその目的からのみ理解しようとすると、前段の例のような、ある種の「実用性」を見逃してしまいます。目的を理解した上でさらに、「アクセシビリティAPIとは何なのか」という問いに対する理解が必要なのです。

URLバーのようなGUIは、「人間のユーザー」がブラウザを操作するための機能です。これに対して、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」といったアクセシビリティAPIは、音声読み上げソフトなどがブラウザを操作するための機能です。つまり、「『ユーザーとしてのソフトウェア』のためのUI」がアクセシビリティAPIの本質です。アクセシビリティAPIが救済している弱者はソフトウェアだったのです。そのソフトウェアには音声読み上げソフトや拡大鏡ソフトも含まれますから、最終的には人間の弱者も救済されますが、一方で、そのソフトウェアにはブラウザ監視ソフトも含まれている、と、そういうわけです。ですから、アクセシビリティAPIという通称の「アクセシビリティ」の部分はやや誤解を招くので、十分広まってしまう前に何かもっと適当な名前を付けた方が良いのかもしれませんね。そこまで私はフォローしきれませんけれど。

とまれ、アクセシビリティAPIの用途は、「アクセシビリティの向上」という所期の目的より広大です。ソフトウェアが人間向けのアプリケーションを使いこなす時代に差し掛かってきた、と言えるのかもしれません。俄かには適当な使い道が思いつきませんけど、例えば、実際のブラウザを使ったクローラやボットを簡単に作ることができます。なにしろ、UAが本物なのですから、サーバー側からは全く見分けがつかないでしょう。また、ウェブアプリケーションの開発者にとってみれば、各種ブラウザを使いこなしてウェブサイトをテストしてくれるボットに何か感じるところがあるのではないでしょうか。さらに、「従業員の監視」は、「アクセシビリティの向上」よりも実用的であり、有体に言って金の匂いがする目的ですよね。ですから、技術者は福祉目的でないアクセシビリティAPIについて、もう少し検討してみることを薦めます。いや、福祉目的の方も検討してもらっていいんですけどね。

その半面、ここまで読んだブラウザの利用者には、アクセシビリティAPIの応用の結果、なにか窮屈な世界が展開されるような印象を与えてしまったかもしれません。まあ、実際のところ、ある種のスパイウェアが作りやすくなるのは事実ですから、副作用がゼロとは強弁できません。そこまで恐れるほどのものでもないのですが、そういった懸念を解決するには、アクセシビリティAPIに対する理解を深める以外にないわけで、究極的にはそれがリテラシなんだろうと思います。

当初の予定より随分長くなってしまったので、まとめておきます。

  • アクセシビリティのガイドラインを引き合いに出す時は慎重に。
  • アクセシビリティAPIはUIのようなもので、アクセシビリティの向上とは直接関係ない。
305467 journal

Torisugariの日記: アクセシビリティとリテラシ 1

日記 by Torisugari

私は、アクセシビリティに一家言あるような専門家ではありませんが、それでも、アクセシビリティに関しては語りたいことが山のようにあります。どれくらいかというと、多分、目次が必要になるくらいの分量です。ですが、ほとんどの人にとってはつまらないと思いますので、改めて重要だと思われる部分をここで整理してみようと思います。

まずは用語の問題があります。

「アクセシビリティ」(英語はaccessibility、略記するとa11y)は本質的にはバズワードです。まあ、その成り損ないと言った方がいいのかもしれませんが、とにかく、様々な人がそれぞれの場所で使っている多義語ですから、この単語を見たらとりあえずは眉に唾をつけるべきでしょう。詳しい語義はWikipediaなどを参照してもらうとして、その意味するところは、大きく3つに分かれると私は捉えています。1つは「広義の『アクセスしやすさ』」を意味する用例、もう1つはその「『アクセスしやすさ』を確保するためのガイドライン」に関する用例、最後は「『アクセスしやすさ』を実現するためのAPI群」に対する呼称です。まあ、あやふやな言葉の意味を分類するのは無意味かもしれませんが、少なくともこの文章はそういう構成をとっているので、その通りに順を追って紹介していきます(ちなみに、先走って言うと3番目のAPI群がこの文章のテーマです)。

広義のアクセシビリティは、たとえば、田舎のA氏の家と都会のB氏の家を比べて、「Aの家はBの家よりもアクセシビリティが低い」といったような使い方をします。いや、実際にはしませんけど、意味はこれで合っているはずです。あるいは、「手すりの付いていない坂道はアクセシビリティが低い」ですし、「パソコンのブラウザでは綺麗に表示されていても、携帯電話では表示が崩れるウェブサイトもアクセシビリティが低い」ということです。ですから、バズワード界隈(?)では「バリアフリー」や「ユニバーサルデザイン」がかなり近いところにあって、それらを包括する概念と言えるでしょう。

つまり、アクセシビリティを向上させるという行為は、「色の見分けが難しい、足が不自由である、記憶力に自信が無い」等の身体能力に関する弱者や「使っている画面が小さい、パソコンを持ち込めない場所にいる」といった情報化社会における環境面での弱者を救済する、という点で積極的な意義を持っています。逆に言うと、アクセス方法における強者はそういった障害を苦も無く突破できているわけです。例えば、ウェブを見るときはいつでもパソコンという人は、携帯電話向けへの配慮の有無を気にせずにすむ強者ですし、手すりが無かろうが段差があろうが気にせずに登れる人も強者です。瞬間移動能力者にとってみれば、A氏の家がどんな辺鄙な場所にあっても、そこへの訪問を阻む原因とはならないはずです。

  (ガイドラインについて)

とはいえ、例え強者が世間の大多数だとしても、社会は弱者への救済を怠るべきではありません。特に、それがコストをかけずに「ちょっとしたこと」で実現できるのなら、全ての人はアクセシビリティの向上という大義を実現すべく努力を注ぐべきです。これが、2番目の意味である「『アクセスしやすさ』を確保するためのガイドライン」が存在している理由です。例えば、「歩道を作るときはなるべく段差を少なくするように心がける」といったガイドラインは全国的に実施され、また遵守されているようです。ただ、このガイドラインがきちんと機能しているのは、ガイドラインを知っているプロが歩道を発注して監督しているからです。いくらアクセシビリティ向上のためのガイドラインがきちんと定まっていても運用者が知らなければ効果がありません。

話は飛びますが、スラッシュドット・ジャパンに投稿されたコメントには、本文に「(T/O)」とだけしか書かれていないものがあります。これは「自分の言いたいことはタイトルの部分に書いた」という意味です。また、タイトルと本文を続けて読まないと意味が分からないように書かれている投稿も時々あります。例えば、タイトルが「今日の空模様は…」で本文が「とても怪しい。」となっているようなものです。これらは無作法だと私は思います。前者に関して言えば、「タイトルしかない」というのはウソです。本文があまりにも短すぎて、それをタイトル欄に書いてしまったために本文の欄が空いているわけで、実際には「タイトルがない(=無題)」と言うべきなのです。言いたいことがすなわち本文ですからね。後者に関しても、題名が題名になっていない、という点では同様で、だからこそ本来は本文であるべき文を2つにちぎってタイトルの欄と本文の欄を埋めているわけでしょう。「題名」と「本文」という言葉の意味が理解できているなら、このような投稿はしてはいけません。

ただ、この意見はあくまで私の個人的な規範に照らしてのものであり、この無作法さに関する世間的な合意が取れているわけではないことに注意する必要があります。この文章を読んでいる人の中には私に賛同してくれる人もあるかもしれませんが、上記のような投稿が実際に存在している以上、全ての人が同意しているわけではないことは明らかでしょう。そこで思わず縋りたくなるのが、「『アクセスしやすさ』を確保するためのガイドライン」です。「今日の空模様は…」+「とても怪しい。」の例でいくと、音声読み上げソフトを使ったときに、

今日の空模様は(スコア:1)Anonymous Coward : 2011年01月01日 00時00分 (#00000000)とても怪しい。

と発音されるはずなので、これが悪習であることは一目瞭然です。しかし、ちょっと待ってください。この論法は正しいのですが、この正しさはある種の背徳感に満ちた正しさでもあります。「お前の書き方はアクセシビリティが低い」という主張は、「お前の書き方が気に入らない」という主張の言い換えになってしまっているわけですからね。私がどれだけ弱者に配慮しているかを他人が把握するのが難しいからこそ、尤もらしく聞こえてしまうわけです。

しかしながら、実際のところ、音声読み上げソフトに不利な記述方法は上記の無作法以外にもたくさんあります。例えば、縦読みなどはその最たるものであり、もちろんAAなどは厳に慎むべきです。では、これらのアクセシビリティを低下させる投稿を行ってはならないのか、というのは難しい問題です。縦読みはともかく、AAは余の方法をもっては代えがたい表現です。硬い内容ならともかく、ラフな受け答えまでアクセシビリティを理由に制限すべきか、というのはよく考えなければなりません。

もとより、スラッシュドット・ジャパンは、キャッチフレーズ入りのロゴマークを、imgタグを使わずにdiv要素の背景をCSSで指定する、というおよそ考えつく最低のアクセシビリティで表示しています。編集者はHere Syndromeに侵された記事を修正せずに掲載していますし、そもそもslashdotというドメインからしてアクセシビリティを意図的に下げるために命名されたものです。略称である"/."は検索することすらできません。ただ、こういう細かい点をあげつらってもあまり意味が無いとも思います。弱者のための配慮というのは、他の分野においてもその程度には頼りないものでしょう。

2年ほど前、慶応大学(湘南藤沢キャンパス)のトップページがFlashになった際に、その件を「アクセシビリティの低下である」として弾劾したブログがありましたが、指摘している側もアクセシビリティのガイドラインに違反していました。Re:指摘側のblogも大概わかりにくい。アクセシビリティに十分配慮したサイトを作るのも難しければ、それを指摘するのだって難しいものなのです。「お前のサイトはアクセシビリティのガイドラインに違反している」というのは「お前のやり方が気に入らない」と「お前のやり方は間違っている」を兼ね備えた婉曲表現なので、つかみ合いの喧嘩に発展してもおかしくないですからね。

ただ、他のサイトを批判するときにアクセシビリティを持ち出さない方が良い、とも言えません。慶応の例ように、Flashになってしまったのを批判するときは、(上記の無作法とは違って)アクセシビリティを抜きにすると感情論しか残らないので、やはり、どこかでアクセシビリティの話題を持ち出さざるをえないでしょう。そういう時は、これまで説明してきたような事情を踏まえた上で上手くやる必要があると考える次第です。

286269 journal

Torisugariの日記: 世界のオザワ

日記 by Torisugari

ちょうど今から3年ほど前、はてなブックマークで"erogeek"というキーワードを見てから、何かしらエロに関連することを書こうと頭を悩ませていたのですが、これが案外難しいものです。

そんな中、ひとつだけ温めていたネタがあります。それが、

世界で最も有名なオザワさんは、セイジでもイチロウでもなければ、もちろんケンジでもない。マリア。

です。

一郎さんが幹事長を辞任したころにGoogleの検索結果で気付いたのですが、不勉強にしてマリアさんが何者か知らなかったので、その圧倒的な結果にかなり驚きました。しかし、これって、他に客観的なデータがないんですよね。なんとか数字の裏づけを取りたいと思っていたところ、今度は(おそらく)Googleのランク評価からエロ系が軒並み落ちてきてしまって、今では残念な感じになっています。

http://www.google.com/search?q=ozawa
(google.co.jpにリダイレクトされたりする場合は、言語関係の設定を変えてみてください。)

音楽愛好家としては、ぜひとも征爾さんに頑張ってもらいたいのですが、どうやら、既に太刀打ちできるレベルではないようです。とはいえ、先程述べたように、客観的な数字は無いのですがね。

これは一見「VHSがベータマックスに勝ったのは…」と同種の話のように思われますし、確かに根本的な原因にそれがあることは間違いないでしょう。しかし、もう1つ忘れてはならないのが、おそらく(国内はともかく国際市場における)商業的な成功ではない、という点です。すなわち、彼女の雷名を轟かせしめたもう1つの原動力は「違法コピー」なのでしょう。これは、ある種の寒気を覚えるべき現象なのです。

時々、私は海外で違法にアップロードする人のことを考えます。中には違法行為によって直接(広告収入などの)利益を得ている人もいるでしょう。しかし、全く利益を得ずに違法行為に手を染めている人も、また、多いはずです。マキャベリ的な損得勘定で考えると、明らかに損しかない違法アップロードの動機に、あえて理由をつけるなら、それは、善意と呼ぶべきでしょう。義侠心と言ってもいいかもしれません。

それは、昏い善意です。法的にも倫理的にも決して許されることではありません。しかし、動機を善意というラベルで分類するなら、多くのことが見えてくるようです。

「違法コピー」は他人の権利を蹂躙することによって利益を得る仕組みであり、その大局的な動機は極めて利己的です。違法コピーのグループはその外の社会から一方的に搾取しています。一方で、違法コピーのグループの内部では、そのメンバーによる献身がなければ機能しません。メンバー全員が完全に利己的である場合、「違法アップロード→違法ダウンロード」というプロセスは起こりえないはずです。あるいは、存在したとしても、有限回で違法行為が停止してしまいます。しかし、現実に「違法アップロード→違法ダウンロード→違法アップロード→違法ダウンロード…」のプロセスは確かに繋がっています。かくして違法コピーのサイクルは外の社会のデータを全て食いつぶすまで、半永久的に回り続けるのです。

つまり、この「大局的な利己主義」は、一般的な意味の「利己的」ではなく、ドーキンスさん的な意味の「利己的」であり、ベンサムさん的な意味の「功利主義」なのです。そして、それを成立させるために得体の知れない力が働いており、それこそが「昏い善意」です。普通、功利主義を実現するために、我々は人工的な力、例えば「法」であったり、「政府」であったりを想定します。法も無く政府も無く、例えば、「所得の再分配」が出来得るものでしょうか?しかし、この「昏い善意」は完全無欠にアナーキーなものです。

違法コピーのもう1つの姿として、「大局的にはファイル交換である」という点が挙げられます。しかし、この「交換」にしても、一般的な意味合いの「交換」とは全く違います。「違法にアップロードすること」と「違法にダウンロードすること」は、因果関係こそあれ、人間の行動としては厳然とした区別を伴うものです。従来的な区分で考えると、アップロードは贈与に相当し、ダウンロードは収得に相当しますが、贈与が必ずしも収得の見返りとはなりえていません。この高度に断片化された「交換」のかけらを繋ぎ合わせることによって、大局的交換が成立しています。犯罪者たちは、何の担保もなく互いを信頼して与えることによって、自らが受け取っているのです。ですから、ファイル交換はあくまで集団犯罪の姿であり、個別の犯罪の形態は違法な贈与と違法な収得が独立しているのです。

つまり、この犯罪は我々の良く知る現代的な「交換」ではなく、むしろマルセル・モースさんやレヴィ・ストロースさんの例に出てくる未開社会の交換である「互酬的な贈与」や「クラ交換」なんかに非常に近い形態の「交換」じゃないですか?世の社会学者は、もっと真剣に違法ファイル交換コミュニティを研究して、その力の構造を解き明かすべきだと思います。それをせずに、ただ、対処療法を重ねたり、複雑な法を組み上げるのは拱手に似て、あまり役に立っていません。

私が思うに、「著作権者が犯罪者から賠償金を取る」というシステムが、既にダメだと思います。むしろ、取り締まった人(=警察)に罰金を原資とした「報奨金」を支払うシステムに切り替えるべきではないでしょうか。仮に警察に「昏い善意」に対処するだけのマンパワーが足りなかったとしても、後は市場に任せるだけで、勝手にシステムが回っていきます。それが資本主義の一番素晴しい点です。「犯罪者を減らせば得をする」という事実はもっとわかり易く示されるべきなのです。たとえ、それが斬新を通り越して旧態以前とした賞金稼ぎ方式だったとしても、です。

264579 journal

Torisugariの日記: JPEG 2000について 1

日記 by Torisugari

現在、ラスタ画像をウェブ上で取り扱うとき、可逆圧縮ではPNG、非可逆圧縮ではJPEGが主流と言っていいと思います。

PNGは様々な変遷を経てこの地位に至ったわけで、これまでは不甲斐無い一面覗かせることもありましたが、これからの将来は安泰です。一方、非可逆圧縮の分野におけるJPEGの地位は、必ずしも楽観視できない、と私は思います。なぜなら、同じ分野で、JPEG 2000、JPEG XR、WebPという3つの後継フォーマットが鎬を削っているからです。

JPEG 2000、JPEG XR、WebPは、それぞれ圧縮の効率の面ではJPEGを上回っているという利点があります。さらにこれらを比べると、JPEG 2000は、この3つの中では最も古いので利用実績の面で大きく水をあけています。また、JPEG XRとWebPは、それぞれMicrosoftとGoogleという2大巨人が推すフォーマットですから、将来どう伸びてゆくか、計り知れない面がある、と言えるでしょう。

どれが勝つか、というのは非常に難しい問題です。というよりも、どれかが勝つかもしれない、という点こそが真の問題と言えるかもしれません。私が思うに、ネット上の非可逆ラスタ画像に限って言えば、3者と比べても、まだJPEGの優位は揺るがないでしょう。全ての人にとって理想的な状況は、JPEG 2000、JPEG XR、WebPがウェブ上で使われていない状況(=現状)であり、私としては、これらがウェブへと流入してくるのを食い止めるべきだと思うのです。JPEGとPNGで十分ですから。

しかし、これはウェブ本位な意見であって、デジタルカメラは(需要を先読みして)高解像度低容量に惹かれていくかもしれません。その時、カメラメーカーが参考にするのがウェブ上での普及率、ということになれば、ウェブブラウザの対応が最も重要な要素になります。MicrosoftとGoogleはともにブラウザベンダです。また、両者とも高機能携帯電話(ブラウザ+カメラ)の基幹部分の設計開発に大きく関わっています。こういった泥臭い面まで勘定に入れると、やはりJPEG 2000だけは先行きが暗い、と言わざるを得ません。これまで以上の何らかの梃入れがない限りは、ですけれど。

となると、業務用途でJPEG 2000を採用している業界が、今後、いつまで使い続けるのか、どうやって死に筋を確認するのか、心配の種は尽きません。フタを開けてみれば、余計なお世話となっている可能性も捨て切れませんけれど。

typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...