エンジニアが発信する【2008年01月】の記事です

エンジニアが作る最新ITブログ トップ>【2008年01月】

2008年01月03日

[ 備忘録 / F# ] List Comrehension

brackets で式を囲むと list, brace で式を囲むと seq になる。

> (* brackets の場合は list *)
- [ for integer in 1 .. 10 -> integer * integer ];;
val it : int list = [1; 4; 9; 16; 25; 36; 49; 64; 81; 100]
> (* brace の場合はseq *)
- { for integer in 1 .. 10 -> integer * integer };;
val it : seq = seq [1; 4; 9; 16; ...]

2008年01月02日

『Google Gearsスタートガイド』

「Google Gears」 の解説書です。「Google Gears」 の基本的な仕組みを解説するにとどまらず、「GWT」 との連携や 「Google Gears ORM」 の使用方法についても記載されており、参考になりそうです。 なお、先に紹介した 『Google Web Toolkit Applications』 にも、「Google Gears」 を使用した 「GWT」 アプリケーションのサンプルが示されています。(Chapter 6) 関連情報・【レビュー】BOOK REVIEW - 「Google Gears」を周辺技術に至るまで幅広く解説 | マイコミジャーナル ・Jungle Java - Google Gears でWebアプリのオフライン機能を実現・Jungle Java - Google Gears のための ORM も登場・Jungle Java - 『Google Web Toolkit Applications』

2008年01月02日

ブラウザ別EUC-JP補助漢字のサポート状況(1)



EUC-JP補助漢字(JIS X 212)の処理をPHPやPerlなどにてどのように処理すべきかを考えるために、ここで、補助漢字や補助漢字でも表すことのできない外国語や記号について、各種ブラウザ別対応状況を詳しく調べてみたいと思います。その前に、前提となる知識として、以下の3つのサイトをご紹介したいと思います。

● IEがEUCのJIS X 212をサポートしていないのは規格違反なのか
http://mkosaki.blog46.fc2.com/blog-category-10.html

● Extended Unix Code - Wikipedia
http://ja.wikipedia.org/wiki/Extended_Unix_Code

● Bug 4873 –EUC-JPエンコーダは補助漢字を変換すべきではない
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873
(bugzillaの投稿。かなり活発に意見が交わされています。)を読んでみてください。

ここから分かるのは、IEの仕様もFirefoxの仕様もどちらが規格違反とかバグであるとかいうことは、ないようです。ただ、私は、IEの仕様に合わせるほうがいろいろ都合がよいと考えています。(誰がどのようにどんな名目や理由で合わせる作業をするのかという議論とかかわっていますが、その考えを述べるに当たっても、下記のようなテストは重要だと考えます。

こんなややこしいことを考えないためにも、EUC-JPではなくUTF-8でサイトを構築すべきであるという結論ももちろんありでしょうが、必ずしもそうできない場合もありますから、その結論はとりあえず「抜き」にして、別の対処案を考えてみたいです。)

実験1:各種ブラウザは「鷗外」をどのようにエンコードするか?(EUC-JPのページで)
このテストには、HTMLページにメタタグによる文字コード指定()がブラウザによっては必須のようです。)
ブラウザ名URLエンコードデコードしたもの
(ピンク部分は私が注目したところで、特別な意味はありません。)
IE7(Vista)%26%2340407%3B
%B3%B0
鷗 0xB3 0xB0
IE6(XP SP2)
IE5.5(Windows 2000)
Firefox 2.0.0.11
(Vista)
%8F%EC%BF
%B3%B0
0x8F 0xEC 0xBF 0xB3 0xB0
Firefox 3.0β2
(Vista)
Firefox 1.0.8
(XP SP2)
Netscape 7.1
(Vista)
Opera 9.25(Vista)%26%2340407%3B%B3%B0鷗0xB30xB0
(Windows版IEと同じ挙動)
Opera 9.5β1
(Vista)
%8F%EC%BF%B3%B00x8F 0xEC 0xBF 0xB3 0xB0
(β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・)
Safari 3.0.5
(Vista)
%B2%AA%B3%B00xB2 0xAA 0xB3 0xB0
「0xB2 0xAA」は「鴎」です。字自体を置き換えています。
Safari 3.0.5
(Tiger 10.4.11)
IE 5.2.3
(Tiger 10.4.11)
入力不能。コピー&ペーストの時点で「?」に。
Firefox 2.0.0.11
(Tiger 10.4.11)
%8F%EC%BF
%B3%B0
0x8F 0xEC 0xBF 0xB3 0xB0
Safari 2.0.4
(Tiger 10.4.8)
%3FB3%B0? 0xB3 0xB0
コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「?」になります。

Opera 9.5β版の結果が意外でした。9.5の正式版でどうなるかですね。


実験2:各種ブラウザは「髙﨑」をどのようにエンコードするか?(EUC-JPのページで)
ブラウザ名URL
エンコード
--
IE7(Vista)%FC%E2
%F9%F5
0xFC 0xE2 0xF9 0xF5
IE6(XP SP2)
IE5.5(Windows 2000)
Firefox 2.0.0.11
(Vista)
%FC%E2
%F9%F5
0xFC 0xE2 0xF9 0xF5

つまり、この事例では、FirefoxはIEと同じ挙動を取ります。これが、先述のBugzillaにおける森山先生のコメント:

問題となっているのは、Firefox が POST の際のコードポイントではないでしょうか?

具体的には、JIS X 0212 補助漢字と CP51932 の 機種依存文字 (NEC特殊文字、NEC選定IBM拡張文字) の両方で同じ文字が定義されている場合に、Firefox では CP51932 のコードポイントが用いられて、CP51932 で定義されていないが JIS X 0212 で定義されている文字に関しては、JIS X 0212 のコードポイントが用いられているという点です。

に通じるのだと思います。
Firefox 3.0β2
(Vista)
Firefox 1.0.8
(XP SP2)
Netscape 7.1
(Vista)
Opera 9.25(Vista)%FC%E2
%F9%F5
0xFC 0xE2 0xF9 0xF5
(Windows版IEと同じ挙動)
Opera 9.5β1
(Vista)
%FC%E2
%F9%F5
0xFC 0xE2 0xF9 0xF5
(結局、Firefoxとここも挙動は同じであり、結果的に、Opera 9.25とも同じであり、Windows版IEとも同じです。)
Safari 3.0.5
(Vista)
%8F%F4%F5
%8F%F4%B1
0x8f 0xF4 0xF5 0x8F xF4 0xB1
(原則どおり、補助漢字として処理)
Safari 3.0.5
(Tiger 10.4.11)
IE 5.2.3
(Tiger 10.4.11)
入力不能。コピー&ペーストの時点で「?」に。
Firefox 2.0.0.11
(Tiger 10.4.11)
%FC%E2
%F9%F5
0xFC 0xE2 0xF9 0xF5
Safari 2.0.4
(Tiger 10.4.8)
%3F%3F? ?
コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「?」になります。或る意味、潔いです。

Safari 3のこの挙動には注意した方が良いですね。Firefoxとも違う処理になっています。



次に、補助漢字ではありませんが、参考までに、補助漢字に含まれない韓国語の場合、どうなるかを考えてみたいと思います。

実験3(番外編):各種ブラウザは韓国語の「안녕하세요?」をどのようにエンコードするか?(EUC-JPのページで)
或る意味、当然の結果が出ました。
ブラウザ名URL
エンコード
--
IE7(Vista)%26%2350504%3B
%26%2345397%3B
%26%2354616%3B
%26%2349464%3B
%26%2350836%3B
%3F
数値参照文字

안녕하
세요?
IE6(XP SP2)
IE5.5(Windows 2000)
Firefox 2.0.0.11
(Vista)
Firefox 3.0β2
(Vista)
Firefox 1,0.8
(XP SP2)
Netscape 7.1
(Vista)
Opera 9.25(Vista)
Opera 9.5β1
(Vista)
Safari 3.0.5
(Vista)
Safari 3.0.5
(Tiger 10.4.11)
IE 5.2.3
(Tiger 10.4.11)
コピー&ペーストの時点で文字化けするので、送信してもやはり文字化け。
Firefox 2.0.0.11
(Tiger 10.4.11)
%26%2350504%3B
%26%2345397%3B
%26%2354616%3B
%26%2349464%3B
%26%2350836%3B
%3F
数値参照文字

안녕하
세요?
Safari 2.0.4
(Tiger 10.4.8)
%3F%3F%3F%3F%3F%3F ??????
最後の「?」だけ意味合いが違いますが、EUC-JPのページではハングルの処理はできないようです。

韓国語に関しては、何とか対応しようとしているブラウザは全て数値文字参照方式を取っています。或る意味、当然の処理かもしれませんが、ここで「&」が登場するため、EUC-JPで構築されたブログや掲示板などシステムでは、エスケープされたまま、元に戻されないため、結局韓国語を表示させることは不可能であり、「UTF-8で構築されたブログや掲示板で投稿してください」ということになるのかもしれません。

韓国語はこうなりましたが、ではドイツ語の場合はどうでしょうか?

実験4:各種ブラウザはドイツ語の「möchte」をどのようにエンコードするか?(EUC-JPのページで)
ブラウザ名URL
エンコード
--
IE7(Vista)m
%26ouml%3B
chte
文字実体参照

m ö chte
IE6(XP SP2)
IE5.5(Windows 2000)
Firefox 2.0.0.11
(Vista)
m%8F%AB%D3chtem 0x8F 0xAB 0xD3 chte
「補助漢字」には、漢字だけでなく、ドイツ語のウムラウトやフランス語のアクサン記号が含まれているため、このような処理になっています。
Firefox 3.0β2
(Vista)
Firefox 1.0.8
(XP SP2)
Netscape 7.1
(Vista)
Opera 9.25(Vista)m%26ouml%3Bchte 文字実体参照

m ö chte
(Windows版IEと同じ挙動)
Opera 9.5β1
(Vista)
m%8F%AB%D3chtem 0x8F 0xAB 0xD3 chte
(β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・。Firefoxと同じ処理です。Firefoxに追随?)
Safari 3.0.5
(Vista)
m%26%23246%3Bchte数値文字参照

m ö chte
(これは意外な結果。補助漢字に相応する文字は何でも0x8F~で処理するのかと思いきや、違いました。しかも、Windows版IEでは文字実体参照ですが、Safari 3は数値文字参照です。)
Safari 3.0.5
(Tiger 10.4.11)
IE 5.2.3
(Tiger 10.4.11)
入力不能。コピー&ペーストの時点で「?」に。
Firefox 2.0.0.11
(Tiger 10.4.11)
m%8F%AB%D3chtem 0x8F 0xAB 0xD3 chte
Safari 2.0.4
(Tiger 10.4.8)
m%3Fchtem?chte
コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「?」になります。とても分かりやすい仕様です。


ドイツ語のウムラウトは、EUC-JP補助漢字(JIS X 212)に入っていますので、Firefoxなどでは原則どおりの対応をしようとしているのが分かります。

実験5:各種ブラウザは「©♦」をどのようにエンコードするか?(EUC-JPのページで)
(♦は補助漢字には入っていません。)
ブラウザ名URL
エンコード
--
IE7(Vista)%26copy%3B
%26%239830%3B
文字実体参照+数値文字参照

©♦
IE6(XP SP2)
IE5.5(Windows 2000)
Firefox 2.0.0.11
(Vista)
%8F%A2%ED
%26%239830%3B
0x8F 0xA2 0xED ♦
「©」だけ補助漢字扱いで、「♦」は数値文字参照処理です。
Firefox 3.0β2
(Vista)
Firefox 1.0.8
(XP SP2)
Netscape 7.1
(Vista)
Opera 9.25(Vista)%26copy%3B%26%239830%3B文字実体参照+数値文字参照

©♦
結局、Opera 9.25は全てにわたって、IE7やIE6と同じ挙動です。
Opera 9.5β1
(Vista)
%8F%A2%ED
%26%239830%3B
0x8F 0xA2 0xED ♦
「©」だけ補助漢字扱いで、「♦」は数値文字参照処理です。
(β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・)
Safari 3.0.5
(Vista)
%26%23169%3B
%26%239830%3B
数値文字参照+数値文字参照

©♦
(これは意外な結果。両方を数値文字参照にするとは、IEともFirefoxとも違う第三の処理体系です。)
Safari 3.0.5
(Tiger 10.4.11)
IE 5.2.3
(Tiger 10.4.11)
入力不能。コピー&ペーストの時点で「?」に。
Firefox 2.0.0.11
(Tiger 10.4.11)
%8F%A2%ED%26%239830%3B0x8F 0xA2 0xED ♦
「©」だけ補助漢字扱いで、「♦」は数値文字参照処理です。
(話がそれますが、Mac版Firefoxではフォントの設定の問題なのか、「♦」は期待通りには表示されませんでしたが、POST後のURLエンコードは予想していた通りになりました。)
Safari 2.0.4
(Tiger 10.4.8)
%3F%AC%A8?0xAC 0xA8
コピー&ペースト時に入力した文字の表示はOKですが、POSTすると「©」は「?」になります。ところがダイヤマークは、別の2バイトの「?」(黒いダイヤマークの中に白抜きの?マーク)に変わりました。


今までの内容をまとめますと、次のようになると思います(順不同。順番に意味はありません)。

  • Windows版IEの処理は、IE5.5・IE6・IE7で全て同じです。バージョンアップによって挙動が変わった事実はありません。

  • Firefoxは、Windows版とMac版で挙動が異なることはありませんでした。

  • Netscape 7.1はFirefoxと挙動が異なることはありませんでした。つまり、Mozilla系ブラウザの挙動も変化がありません。(Netscape 6は調べていません。)

  • Mac版IEはUnicodeのサポートが中途半端なまま、開発が終了し、配布も中止になったため、テストからはずしたほうが良さそうです。

  • Mac版Safariは、2.0.xまでは、補助漢字を処理できず、処理できない文字は全て「?」にしていた。

  • Safariは3.0xに進化する中で(Mac版だけでなくWindows版も)、補助漢字に対する処理を大幅に進化させました。しかしながら、Windows版IEともFirefoxとも異なる仕様を採用しました。

  • Opera 9.25まではWindows版IEと全く同じ挙動を示していたOperaがなぜか、Opera 9.5β版では、Firefoxと同じ挙動を取るようになりました。9.5 正式版では、Windows版IEの挙動に戻るのか、ベータ版と同じ仕様に落ち着くのかは分かりません。



これらのブラウザの挙動の違いを元に、PHPやPerl+MySQLなどのデータベースで構築されたサイトを運営するに当たり、どのように処理するのが望ましいのかまで考察したかったのですが、時間などの関係で本稿はここまでにしたいと思います。



XOOPSも簡単インストーラで、すぐに利用可能です。

2008年01月02日

[Tech]携帯電話で買いもの

楽天で携帯電話で購入するとポイント2倍とかになっていたので、昨日、初めて携帯経由で買いものしてみた。でも、携帯で買いものして思ったのだけど、URL を常に表示しているわけじゃないので、簡単に URL を確認できないのは問題かと(ちなみに使っている携帯はW43T)。たとえば、購入手続きに入って、セキュアなページに移ったときにそれが本当に信頼できるページなのかが簡単に確認できない。私の場合、ブラウザならURLをちらっと見て、たぶん、大丈夫だろうと思い込む(まぁ、そこに表示されるのが完璧かというと微妙かもしれな ...

2008年01月02日

[その他]2008新年の決意

皆さん、新年あけましておめでとうございます。(オン、オフ共に) 今年もよろしくお願いします。m(_ _)m 2008年という新しい年が来て、いろいろ個人的にやろうと思ったこと。 昨年夏ぐらいから本格的にやっている英語を、今年はネイティブスピードの話をほぼ理解できるところまでできるようになる! CV.netのモバイルバージョンを商品としてリリースできるレベルまで完成させる! CV.netのSAP同レベルの汎用販売管理バージョンを本格的に作り始める(これは数年ごしになる予定...) 昨年一年間は、CV.n ...

2008年01月01日

「大規模C++ソフトウェアデザイン ジョン・ラコス著」を読む

少しまた、ソフトウェア開発に関する本を読んでみようかと購入。
かなり分厚いので読み終えるのがいつになることやら・・・

この本の説明によると、いろいろとソフト開発の本はあるが大半は「論理デザイン」に関するものだそうだ。
多少、ソフト開発の本を読んでいるが、そういた視点でみたことはなかったのでこの本のいう「実装デザイン」というものがどんなものなのか?また、新しい視点が得られるのではと読んで見ることにした。
 今のところはあまり目新しいことはなかったが、とくに「依存」についていろいろと説明されているように思えてきた。
 「依存」の問題点、それをどう防ぐか?今までの経験からも、たしかにこれは重要なことではないかと思える。
 この先がどういうものか期待がふくらむ・・・せっかく読んだので何か得られることを願う

2008年01月01日

[Portal]JBoss Portal のデモ

http://portal.demo.jboss.com/ にあったので、いじってみる。思うことを勝手にまとめてみると、 UI は、ポートレットのタイトルバーをつかんで、別な列への移動は可能。 レイアウトフリーで配置はできないみたい。 ページは追加できるけど、フォルダのような概念はないのだろうか・・・。 編集できる個人ページはダッシュボードと呼んでいるらしい。 メッセージは英語だけ?まぁ、Liferay もそうだった気がするけど。 widget として、Google と Netvibes を配 ...

2008年01月01日

IT業界今年の注目

私が考える今年のIT業界、注目ポイントを予想します。 1 プロセスマネジメント  主にBPM(Business Process Management)という流れの中で注目を浴びると思いますが、今年は個別最適ではなくプロセス全体を俯瞰して最適化するというアプローチの経営が主流になるものと思います。 2 可視化経営  1にも関係してきますが、経営の生の状態を絶えずウォッチする経営が主体となると思います。そういった意味で可視化経営という言葉が前面に出てくるものと思います。 3 SaaSとSMB  昨年のSaaSブレイクを契機に、今まで大手企業が利用していたサービスを中堅・中小企業がりようできるようになりました。このため、今までITリテラシーが比較的低かった中小企業(SMB)にIT企業の注目が集まると思います。 1~3に関連する技術は当然今年の注目株になります。先ほど紹介したXBRLも2に関係してくるかもしれません。 当たるかどうかわかりませんが、私としてはこの1~3を中心に追いかけていきたいと思います。

2008年01月01日

jQuery 1.2.2 リリース

「jQuery」 が 1.2.2 にバージョンアップしました。 速度が大幅に向上したというので、当ブログで使用しているライブラリも入れ替えてみました。確かに速くなったみたいです。(^^) 関連情報・速度向上300%! jQuery最新版登場 - 全ユーザはアップグレードを | マイコミジャーナル・jQueryではじめるAjax:第1回  まずは実装してみよう|gihyo.jp ・Jungle Java - jQuery でブログをデコレーションしてみた

2008年01月01日

去年の資格取得リスト

明けましておめでとうございます。

さっそく去年の資格取得を振り返ってみる。
が、振り返るほどでもないくらい、資格を取得していない。
もちろんこれは私的なでっかいサプライズ(妊娠出産)や、予想外の出来事があったためだが、できれば一つくらいは取得したかった。。。

ということで、リストは以下の通り。

【去年の資格取得(予定)リスト】
資格レベル取得月日
SJCP(Sun認定Javaプログラマ for Java 2 Platform 5.0)
OCUPIntermediate
UMTPL2
日商簿記検定2級

これを元に、来年の予定を今後立てていく予定。

エンジニアが作る最新ITブログ トップ>【2008年01月】

メンバー紹介

タグパネル

ランキング

エンジニアが作る最新ITブログ DODA