Real Playerはインストールしたくないのでインストールしていなかったのですが、そうも言っていられない状況になったので少しWindows Mediaで使えるCodecを探してみました。（Quick TimeはiTunesがインストールするので諦めてインストールしています。
K-Lite Mega Codec PackというCodecを集めた製品を見つけました。Codecのコレクションになっていて色々そろっています。
私にとってはこれだけCodecがサポートされていても無意味なのでRealPlayer Alternativeだけインストールしました。
久々にPostgreSQLの話です。プリペアードクエリのprepare文のエラーで次のようなエラーに出くわす事があります。
ERROR: inconsistent types deduced for parameter $8 DETAIL: timestamp without time zone versus text
パラーメタの番号は振り直している、と思い込んでいたのでこのエラーメッセージを見ても何故だろう状態なり、しばらく悩んでしまいました。ググってみても役に立ちそうなページが一つも無かったので書いておきます。
create table test (
t text,
i int
);
のテーブルの場合に
pg_prepare(‘testplan’, ‘select * from test where t = $1 and i = $1;’);
等とすると(pg_prepqreはPHP 5.1の関数）
ERROR: inconsistent types deduced for parameter
エラーが発生する、はずだったのですがこの例の場合はPostgreSQL 8.0.7で試してみてもエラーが発生しませんでした。自動的にキャストしてしまうのかな?調べてません。
とにかくこのエラーはプリペアードクエリの同じパラメータが互換性のコラムに利用された場合に発生するエラーです。
エラーメッセージが読んで字の如しなので有用なページが無いのでしょうね。
Google Analyticsのタイムゾーンのデフォルト設定はEST（アメリカ東部時間）のようでそのまましばらく使っていました。
さすがに使いづらいのでJSTに変更したのですが、アクセスログのデータはUTCで記録されていないのですね。時差分の時間がアクセス0として間が開いてしまいました。普通はタイムゾーンの設定を初めにすると思うのでこのような問題にあう事は無いと思いますが、使い始めの時にはタイムゾーンの設定をお忘れなく。
多分、特許で訴えられない対策の意味合いが大きいとは思いますがGoogleが音声検索コマンドで特許を取得したそうです。
カレンダーが使えるようになったようです。
googleアカウントが必用です。タイムゾーンを設定するだけで利用できるようになります。
【追記】
他のWindows XP+IE6の最新環境で試してみました。
ダウンロードした.htmファイルを開いてJavaScriptが実行されてもクッキーは表示されませんでした。表示しなかった環境はほとんど何も触っていない状態のWindows XP+IE6環境です。クッキーを表示するのは普段使っているノートPCのWinXP+IE6最新環境です。何か原因があるはずですが今のところ動作の違いの原因は分かっていません。参考までにIE関連で何が入っているかというと
-Google Toolbar (page rank付き）
-Norton Internet Security
-Java（JRE1.5）
が入っています。これらはクッキーを表示しないPCの環境には入っていません。少なくとも手元の環境では脆弱性が再現するWinXP PC1台と再現しないWinXP PC1台がありました。
そこでVMWare5でWinXP SP2をインストールした直後の状態のクローンを作成して試してみました。Windows Updateを全て適用、全ての更新が正しく適用されている事を確認後、「ファイルを開く」でJavaScript付き.htmを開いてみたところクッキーが表示されました。クッキーにアクセスできる脆弱な状態が普通なのか?それとも普通(?)はクッキーにはアクセスできないのかどちらなのでしょうね?
他にCSSXSS脆弱性が直っていないらしいので、どちらにしろ結局IEが安全では無い日は昨年から続いていますが。
———–
IEで意図しないJavaScriptが実行される問題の話です。
この問題は4月の定例パッチの直前に明らかになったので修正できなかった問題と思われます。結果として昨年末から既知の脆弱性があるままの状態が継続しています。
IEが拡張子ではなくデータの内容によって適当（と言うより不適切）に処理してしまう事は有名ですが、この問題は拡張子を優先してしまって問題になったケースと言えると思います。.htmを拡張子に持つファイルを送信する際にContent-Dispositionにattachment指定しても、これを無視してinlineでhtmlとしてファイルを処理してしまい(?)クッキーが漏洩してしまいます。今月のMSの定期更新にはこの件に関する修正が無いようだな、と思っていましたが修正されていないようです。
Googleはこの問題の為に.htmファイルをzipに圧縮するようにしたようです。
脆弱性のデモサイトがあります。
http://xs.vc/content-disposition/
にどのような動作になるかテストでるようになっています。
まず、ここにアクセスすると
SECRET=12456767890
とサイトが設定したクッキーがJavaScriptのAlartダイアログボックスで表示されます。ページ中の添付ファイル（Content-Disposition: Attachment）の.htmはAttachmentであるのでダウンロードされ、サイトが設定したクッキーを表示できるべきではありません。しかし、パッチ適用後のIEでも添付ファイルを開くと添付ファイル中のJavaScriptが実行され
SECRET=1234567890
とJavaScriptのダイアログが開いてしまいます。（Firefoxをデフォルトのブラウザにしている方はIEをデフォルトブラウザに変更してから試してください）
つまりこの脆弱性を利用すると、.htmファイルを添付できるサイトのクッキーを盗めてしまいます。.htmファイルを添付できる仕様のサイトはGoogleの様にzipに圧縮する等の対策を行わないとクッキーを盗まれます。ユーザとしての自衛は簡単で.htmファイルは「開かず保存してから見る」と大丈夫です。
この仕様（というかバグ）はWebメールや添付ファイルをサポートする掲示板、CMS、Wiki、バグ管理システム等で影響があります。私が現時点で把握している最新版IEのセキュリティ上の問題はこれだけです。IEセキュリティのリサーチをしている訳ではないので他にも脆弱性があるのかも知れません。他にあったら是非教えてください。
とにかく、私にが知る限りでも2006年になってからIEが安全に使えた日（攻撃可能な既知の問題が無かった日）はまだ無いです… 残念…
MS06-013 Cumulative Security Update for Internet Explorer (912812)
では
CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability
に対応となっているので直ると思っていて良いのでしょうか?多分今度はきちんと直っているのでしょうね。
直るとされているセキュリティホールは次の通り。
CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
CVE-2006-1245 – Multiple Event Handler Memory Corruption Vulnerability
CVE-2006-1388 – HTA Execution Vulnerability
CVE-2006-1185 – HTML Parsing Vulnerability
CVE-2006-1186 – COM Object Instantiation Memory Corruption Vulnerability
CVE-2006-1188 – HTML Tag Memory Corruption Vulnerability
CVE-2006-1189 – Double-Byte Character Parsing Memory Corruption Vulnerability
CVE-2006-1190 – Script Execution Vulnerability
CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability
CVE-2006-1192 – Address Bar Spoofing Vulnerability
出典：eEye Digital Security
かなり強力な穴ぞろいなのでユーザ全てが直ぐにパッチを当てて欲しいです。しかし今度のアップデートは「Flashが動かなくなる」という噂が先行しているのでアップデートしないユーザも多数でそうな気がします。
数がどれくらいになるか分かりませんが、
CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
のお陰でスパイウェアをインストールされてしまったユーザはかなりの数になると思います。
IEは今年に入ってからリモートから攻撃可能な既知のセキュリティホールが無い状態が1日も無いですが、今度のアップデートで全部直っているのかな?
沖電気が開発した技術は、まず、テキストの数字周辺に現れる単位文字列や単語を、「金額」「時間」「長さ」「重さ」「速度」の5つの属性を判定。判定した属性の代表単位で数字の大きさを換算し、数値情報として抽出する。長さの場合であれば、「インチ」や「尺」といった単位で記述された数値はすべてメートルに換算する。
1キロ(Kg)のキロをKmと間違える事もあるそうですが、これは仕方ないですね。
./J的なネタですが、ウィルス（コンピュータのウィルスではなく本物のウィルス）を使って高性能バッテリを作れるそうです。
Researchers at Massachusetts Institute of Technology (MIT) are using viruses to create tiny batteries that can store up to three times as much energy as conventional power systems.
リチウムイオンバッテリの容量が3倍はうれしいですね。
燃料電池はノート等ある程度の大きさの物には良いですが、携帯電話などは普通のバッテリの方が向いていると思えます。ワンセグでテレビを見る等には容量3倍は大きな意味があると思います。はやく実用化しないかな。もしかしてtiny batteriesと書いてあるので超小型のみかな?
電池マニアではないので普段電池情報をチェックしている訳ではないのですが「
NTTドコモがケータイ向け燃料電池を改良，クロスオーバーを半減して通話時間を3倍に」という記事をTechONに見つけました。
NTTドコモと富士通研究所は共同で，通話時間が約6時間と長い携帯電話機向けの外付け燃料電池を開発した。
とあります。なんとこちらもたまたま3倍ネタです。（驚）
リンク先の写真を見ると分かりますが結構大きいです。6時間通話とはいってもこの燃料電池ユニットを持ち歩くより、3つくらいバッテリを持っている方が良いかなと思えます。（例えば、901シリーズのスペック上の連続通話時間は2～3時間）どちらがどうなのか判断する情報ももっていないのでなんとなくですが、ウィルスによる改良型リチウムイオンバッテリより燃料電池が超小型になることに期待するほうが合理的ですかね?
個人的には電話の電池容量には十分満足しているのでノートPCのバッテリが重要です。燃料電池が早く普及してほしいです。
hackers-jp@ml.postgresql.jp に掲載されていたメールの話です。
色々興味深いです。
MyISAM -> InnoDBで容量が約10倍。InnoDBとPostgreSQLを比べても約3倍。
キャパシティプランニングはDB設計の重要な要素ですが、知らないと困ったことになりますね。
MySQLであまり大きなDBを取り扱ったことが無かったので知らなかったですがMyISAM->InnoDBで10倍にもなるケースもあるとは…
JPUGのMLに書かれていた以外の理由としては1/3のメモリで3倍速く、データのパーテションニング、パーシャルインデックス等のPostgreSQL機能を近い将来利用する事が出来ることもスイッチする理由だそうです。
For an application like FeedLounge, the faster counting and smaller row size of PostgreSQL are compelling reasons to use it instead of MySQL with InnoDB tables. Add that it runs in 1/3 the time, using 1/3 the memory (making it essentially 10x faster for us) and that we can start taking advantage of other Postgres features, like data partitioning and partial indices in the near future, and you have the reason we decided to make the switch.
軽くて速いPostgreSQLは彼らにとって「10倍速い」と言っています。何だか一般的に言われていること（MySQLは軽くて速い）と反対ですね。
どのDBを選択するか?は利用条件、要求事項によって最適な選択が異なります。MySQLの方が自分にとっては「10倍速い」と考えるユーザも多いと思います。どちらにしてもこの事例は参考になります。
以下、メール本文のコピーです。
—–
寺本＠横須賀 です。
最近メールがないので…
雑談ですが、ちょっと面白いのでご紹介です。(via Planet Postgresql)
FeedLoungeという、RSSフィードのオンラインリーダーを提供している（らしい）サービスがあるのですが、そこがDBをMySQLからPostgreSQLに乗り換えた、という話です。
http://feedlounge.com/blog/2005/11/20/switched-to-postgresql/
何が理由で乗り換えたのかに興味があったので読んでみたんですが、
—-
Some of the reasons we decided to make the switch to PostgreSQL: * Database size - when we switched from MyISAM tables to InnoDB tables in MySQL, the size of our database grew from ~1GB to 10+GB! When we made the switch this weekend, the MySQL InnoDB database was using 34 GB, and the same data in a PostgreSQL database is only 9.6 GB - this should keep our hardware costs down a bit. * Load time - The current MySQL setup takes over a day to restore the current database, the load of the data into the PostgreSQL database took just over 4 hours.
—-
という今まで聞いたことも無い理由で乗り換えたとのことでした。
# PGよりも3倍も容量が多くなっちゃったなんて！
その後にPG派とMy派でいろいろコメントがついてます。
どうもでっかいPrimary Keyがついてるらしく、それがまずいんじゃないのか？的話になっていうように読めました。（斜め読みです）
— Junji Teramoto / teramoto.junji (a) lab.ntt.co.jp Master Yoda : Don’t think…feel…be as one with the Source. Help you, it will.
Google Analyticsはサービスが開始されて少し経ってから利用申請をしたのですがその時既に「規制中」でした。やっと個人的に利用できるようになりました。申請した時には日本語ページも無かった(?)ような気がしますが、現在は日本語ページも用意されています。
当たり前の機能で紹介するまでもないですがGoogle Analyticsによるとこのブログにアクセスする方の6割ちょっとがIEを使用されているそうです。Windowsは約9割、1024×768の解像度が5割弱となっています。キャンペーンの効果が判ったり、特定の日付や期間で比較したり、GeoIPで何処からのアクセスか地図などで判ったり、このブログを見ている方は圧倒的にOCNユーザが多い事が判ったりします。
IEユーザが多いのは仕方が無いとして、気になったのは脆弱性があるFlashを使われている方も結構多いことです。フラッシュのバージョンは多いので正確な数字は足し算してみなければ分かりませんが、脆弱なFlashを使われている方が3～4割くらいになるようです。
データはWeb上で見るだけでなく、TSV、CSV、XMLでダウンロードできます。商用サイトで役立つのはもちろん個人でブログをしている方も見ていて面白いと思います。
言い古されていますが一言で言うと「これがあれば並のアクセス統計サービスは無用」です。商用サービスレベルの機能が付いています。一応だれでもインビテーションコードの予約が可能らしいので興味がある方は是非どうぞ。（Googleのアカウントが必用です）
Apacheのシェアが落ちてIISが増えてきていますね。
RICOとはRacketeer Influenced and Corrupt Organizations Actのことで米国の法律です。
詳しくはリンク先を見ていただくとして「難しい世の中になったものだ」と思います。
追記：このエントリは古い情報です。今のHTMLエスケープの情報は以下の新しいエントリを参照してください。
先日、PHPをPHP 5.0.6相当からPHP 5.1.3相当にバージョンアップしたところ一部に動作不良があったのでデバッグしていたコードの消し忘れがありました。コンテンツに”AAAAAAA”と表示して終了している状態になっていました。デバッグ途中で時間が来たのでデバッグコードが残ったものrsyncしたようです。（汗
現在は直っていますが、PHP 5.0.6からPHP 5.1.3相当へのバージョンアップでは思いもよらない部分で問題が発生したりしました。
if (expr) expr;
と{}でブロックにしていないと文法的には正しくてもT_ELSEが無いとエラーになったりしていました。エラーが発生する場合と発生しない場合があります。全てのブロック無しif文でエラーが発生する訳ではありません。
コーディングスタイルを
if (expr) {
expr;
}
としているので気が付きませんでした。
date関数のオプションの取り扱いが微妙に違うか、壊れているかで日付判定もおかしくなっていたのですがこちらは詳しく調べていません。（AAAAAAと表示されていた件がデバッグ用のコードdie(‘AAAAAAAAAA’)でした)
追記：
テストも兼ねてohgaki.netのPHPは5.1.3相当にしています。もし、Wiki、Blogでおかしな動作（空白ページなど）を見つけたら教えてください。