Asp・PHP・Vb・Javascript・oracle・ mysqlなど、エンジニア必須技術の最新情報や、あなたの技術をより磨くためのお役立ち情報が満載です。

Firefox 紹介キャンペーンに参加しました。ぬいぐるみが当たるかも。(^^)そして、ぬいぐるみ以上に気になるのが 「Firefox 3.0」 正式版のリリース。いつ頃になるんでしょうか？楽しみにしてまーす。 関連情報・Firefoxをオススメすると「フォクすけぬいぐるみ」がもらえるキャンペーン | マイコミジャーナル ・Firefox 3.0のβ第3版が公開 - β2からの変更点は1300以上 | マイコミジャーナル・Firefox 3 Beta 3レビュー - builder by ZDNet Japan・Firefox 3の新アイコン「キーホール」を表示させる方法 - builder by ZDNet Japan （02/22 追記）・TechCrunch Japanese アーカイブ » Firefoxのダウンロード数5億回（間近）

編集者: baraki | このブログのURL |この記事のURL

EmEditorのバージョンが7になりました。2006年11月に「秀丸エディタとEUC補助漢字（「繋がる」と「繫がる」）」という記事を書きましたが、EmEditorは当時、補助漢字には対応していませんでした。実際、2007年3月には、EmEditorの公式フォーラムで以下のような質問がなされていました（なお、質問した人は私ではありません）。

●EmEditor テキスト エディタ - フォーラム「EUC-JPは実際にはサポートされていない？」
http://jp.emeditor.com/modules/newbb/viewtopic.php?topic_id=195&forum=2&post_id=746#forumpost746

この中で「次の EmEditor のメジャー バージョンでは、ほぼ確実に、このような新しいエンコードにも対応していきたいと思います。」と開発者の方が語られていたので、バージョン7になって実際どうなっているだろうかと思い、試してみましたが（バージョン7.00でテスト。）、未対応のようでした。（ちょっと意地が悪いですね。補助漢字に対応するのは本当に大変なことだと思います。私のWEBアプリも、まだ対応できていません（汗）。）

データベース（文字コード：EUC-JP）のバックアップなどを取った際に、バックアップファイルをEmEditorで再編集後、データベースに戻す処理をする場合は、注意が必要な場合もあるでしょう。なぜなら、Firefoxで登録された「鷗外」や「繫ぐ」を補助漢字に対応していないテキストエディタで開き、それを再保存すると、文字化けした結果である「乗ｽ」「恕ﾘぐ」が確定化してしまい、バックアップファイルからの復元前は「IEでは文字化けするけれどFirefoxでは文字化けしない」状態だったのが、「IEでは文字化け。Firefoxでも文字化け」という事態に悪化してしまうこともありうるからです。

もちろん、このような事態を避けるためにも、Firefox（やSafari）で送信された3バイトのEUCデータは、データベースに登録する前に数値文字参照化してしまい、IEでもFirefoxでも文字化けしない状態にしておくのが理想的だと思います。そうすれば、補助漢字に対応していないテキストエディタを経由しても文字化けしないようになりますが、なかなかそこまで手が回らないのが実情でしょう。

話を、テキストエディタの比較の話に戻します。では、補助漢字の対応だけを見るのであれば、今のところ、秀丸に軍配が上がりそうかというとそうでもなさそうです。私が誤解している部分があるかもしれませんが、両テキストエディタの機能を比較してみますと、

0x8Fで始まる3バイトEUCのデータがある場合
	秀丸エディタ	EmEditor
読み込み時	○ （文字化けせずに表示）	× （文字化して表示。 保存時に文字化けが確定）
保存時	× （EUCのファイルで「鷗外」「©」などと新規入力したHTMLファイルの場合、その文字がFirefoxなど一部のブラウザでしか意図通りに表示できないことを認識できないまま、ユーザーが思わず使ってしまう危険性があります。）	デフォルトの設定の場合 ○ （自動的に、数字文字参照・文字実体参照に置き換えて保存）

好き好きはあるかもしれませんが、私は、EmEditorの保存時の設定は優れていると思います。EmEditorの場合、このデフォルトの設定が気に入らない場合は、【ツール】→【現在の設定のプロパティ】→【ファイル】タブ→【保存時】ボタン→【Unicode文字をHTML/XMLの文字参照として保存】及び【名前による実体参照を使用する】のチェックを外せば良いでしょう。

●EmEditor テキスト エディタ - FAQ: 「HTML、または XML ファイルを保存する際に、EmEditor はUnicode 文字を文字参照 "Numerical Character References" (NCRs - &#xx; など) として、エンコードすることはできますか?」
http://jp.emeditor.com/modules/xoopsfaq/index.php?cat_id=6#q63




秀丸エディタにも同様の設定がないだろうかと探してみたのですが、見つかりませんでした。こちらの公式サポートフォーラムのスレッドは私が知りたいことをダイレクトに聞かれた内容ではないのですが、この内容からすると、私が捜し求めている機能はなさそうです。そこで、このスレッドで「秀丸担当 さん」が回答しておられるマクロを改良して、私が期待するマクロを考えてみました。なお、私は秀丸マクロは他人のマクロを少しだけ改良（改悪？）して自分だけ使うというレベルですので、以下のコードは全くの無保証です。念のため。

disabledraw; gofiletop; #count=0; #flag=false; #last=0; #ignore=0; $mes=""; //文字コードをチェック #c = charset & 63; if(#c==6){ message "UTF-8のファイルの場合、このマクロを使う必要がありません。"; endmacro; } while(1){ if( code == 0 && unicode != 0 ) { #last=lineno; $mes= str(lineno)+"行目の「"+unichar(unicode)+"」はUnicodeでしか表現できません。//\/i/inどうしますか？"; menu $mes,"●数値文字参照に変換","●下駄文字に変換","何もしない","マクロ終了"; if(result==2){ #flag=true; #count = #count + 1; insert "&#"+str(unicode)+";"; delete; } else if(result==3){ #flag=true; #count = #count + 1; delete; insert "〓"; } else if(result==5){ endmacro; } else { #ignore=#ignore+1; right; } continue; } right; if( !result ) break; } if(#flag){ message str(#count)+"個を変換しました。"; movetolineno 1,#last; } else if(#ignore>0){ message str(#ignore)+"個の変換を無視しました。"; } else { message "完了しました。見つかりませんでした。"; } endmacro;

このマクロは、基本的に、ファイルの保存前に実行することを想定しています。

このマクロを実行すると、Unicode文字の部分は数値文字参照にするのか下駄文字（〓）にするのか、それとも無視するのか、選択できます。なお、選択肢の表示のさせ方がよく分からなくて、質問部分まで選択肢の一つになってしまっているのでご注意ください。また、「©」の場合は数値文字参照ではなく文字実体参照にしたいとかいうのがあると思いますが、そこまでするのが面倒なのでやっていません。EUC補助漢字（及び、補助漢字にも入らない漢字など）は全て、数値文字参照になってしまいます。また、マクロの仕様なのか、私の無知なのか分かりませんが、「変換しました」というメッセージが表示された後に、実際は変換が行われます。（適当に、改良して、まともなものに仕上げてください。）

このマクロがあれば、EUC-JPのページでハングル文字を表示させたい場合に、数値文字参照に変換するのが結構面倒という場合にも使えます。ただし、この場合は、ファイルの保存前に実行しないといけません。そうでないと、保存時に、秀丸エディタが文字コード変換できない旨のメッセージを出し、「はい」を選択すると「?」に置き換えてしまいます。

ファイルの保存時に必ず、このマクロを実行してから保存されるようにするように秀丸エディタをカスタマイズできればいいのですが、そこまでの力量もなく、秀丸エディタの仕様が変更にならないかなと思う今日この頃ですが、設定可能項目が増えると、かえって使いづらくなることはよくある話なので、やっぱり、すべての人の要望は受け入れられないですよね、秀丸エディタ開発者様。



1日150円で韓国語が身につく『スピードラーニング韓国語』

編集者: shimax | このブログのURL |この記事のURL

via:RAMBack :: Firefox Add-ons
via:Memory fragmentation « pavlov.net

Firefoxがメモリ上にキャッシュを作成するためにメモリ上にフラグメンテーションが発生し,使用済みメモリの再利用が困難になっているのはよく知られている事実だ.此を解消するためにFirefoxのメモリキャッシュをクリアする目的のExtensionがこのRamBackというものだ.

尚,RamBackはFirefoxのtrunk buildでしか動作しないので,Release buildユーザは参考程度にして戴きたい.Installして数時間が経過するが,タスクマネージャで使用メモリサイズと仮想メモリサイズをチェックしているが効果の程は不明である.一番の謎は何をトリガにキャッシュをクリアするかだ.変なタイミングでキャッシュをクリアされたらブラウジングに悪影響が発生しかねないと思う.

もう一つ理解出来ない点はキャッシュをクリアすることで本当に使用済みメモリが再利用可能になるのかと言うことだ.Firefoxがメモリキャッシュを作成するとフラグメンテーションが発生する.で,単にキャッシュをクリアするだけではフラグメンテーションは解消されない.RamBackは単にキャッシュを解放するだけでなく,フラグメンテーション解消処理も行っているのだろうか.フラグメンテーションの解消を行っていたら効果はあるかもしれない.暫くは様子を観てみよう.もし効果が出ない(感じられない)場合はUninstallしてしまおう.

編集者: 鯖缶 | このブログのURL |この記事のURL

EUC-JP補助漢字（JIS X 212）の処理をPHPやPerlなどにてどのように処理すべきかを考えるために、ここで、補助漢字の各種ブラウザ別対応状況を引き続き調べてみたいと思います。

Windows版IEは補助漢字に関して、数値文字参照や文字実体参照で全て処理しようとしますが、そのようにして送信されたデータがデーベースに保存され、それを使って表示しているWEBサイトを想定してみます。この際、他のブラウザが見たときに正しく表示されるのかをまとめてみたいと思います。

実験２－１：各種ブラウザは、補助漢字や補助漢字外の韓国語や記号に関して、Windows版IE形式で符合された文字列を意図通りに表示できるか？（EUC-JPのページで）
「鷗外」「髙﨑」「möchte」「안녕하세요?」「©♦」でテストしました。

IE7（Vista）	○※1	これは当たり前。
IE6（XP SP2）
IE5.5（Windows 2000）
Firefox 2.0.0.11 （Vista）	○※1	IEの「言葉」をFirefoxは理解できます。
Firefox 3.0β2 （Vista）
Firefox 1.0.8 （XP SP2）
Netscape 7.1 （Vista）
Opera 9.25（Vista）	○※1	Opera 9.25の符号方法はWindows版IEと全く同じなので、これも当たり前。
Opera 9.5β1 （Vista）	○※1	IEの「言葉」をOpera 9.5は理解できます。
Safari 3.0.5 （Vista）	一部×	「髙﨑」については×。 （ただし、フォントの設定によって表示できるようになる可能性もあるかもしれません。フォント依存文字の可能性があるかもしれません。）
Safari 3.0.5 （Tiger 10.4.11）
IE 5.2.3 （Tiger 10.4.11）	一部×	「髙﨑」については×。ただし、ここで注目すべきは、Mac版IEではこれらの補助漢字を自身では入力することが全く駄目だったのに、表示に関してはかなりの部分クリアできていることです。
Firefox 2.0.0.11 （Tiger 10.4.11）	○※1	ダイヤのマーク（♦）だけが期待通りに表示されませんが、コピーして調べたりしてみると別の文字に文字化けしているわけではなく、コードポイントに変化はないようです。フォントを適切に設定することで表示されるのかも？
Safari 2.0.4 （Tiger 10.4.8）	一部×	「髙﨑」については×。

実験２－２：各種ブラウザは、補助漢字や補助漢字外の韓国語や記号に関して、Firefox形式で符合された文字列を意図通りに表示できるか？（EUC-JPのページで）
「鷗外」「髙﨑」「möchte」「안녕하세요?」「©♦」でテストしました。

IE7（Vista）	×	IEは、Firefoxの「言葉」が理解できません。これは痛すぎます。 「鷗外」は「乗ｽ外」に文字化けします。（この文字化けのメカニズムについては、森山先生の解説をお読みください。） 「möchte」は「m醇rchte」に文字化けします。「©♦」は「潤・」に文字化けしますが、本来は問題の無い次の文字（♦）まで道連れにして文字化けします。 「髙﨑」に関しては、FirefoxがWindows版IEに仕様を合わせてくれているので（「合わせている」気持ちはないかもしれませんが・・・）、文字化けしません。補助漢字にも入らない韓国語は文字化けしないという皮肉な結果に。
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）	×	文字化けの仕方は、Windows版IEとは違いますが、文字化けします。
Opera 9.5β1 （Vista）	○	Firefoxと同じ仕様なので、○です。
Safari 3.0.5 （Vista）	×	自分自身は、0x8Fを使った3バイト文字での補助漢字の符号を行っていながら、どういうわけか、そのような文字を正しく表示できません。（フォントの設定の問題なのか、豆腐のような文字化けになります。）
Safari 3.0.5 （Tiger 10.4.11）	一部×	自分自身は、0x8Fを使った3バイト文字での補助漢字の符号を行っていながら、どういうわけか、そのような文字を正しく表示できません。（Safari 2.0.4では起こらないので、これって退化？　Windows版の文字化けはフォントの問題の可能性もありますが、Mac版Safari 3での現象は解せません。）
IE 5.2.3 （Tiger 10.4.11）	×	補助漢字外のハングル文字及びダイヤマークだけOKという皮肉な結果に。 Firefoxの「言葉」をMac版IEでは理解できません。
Firefox 2.0.0.11 （Tiger 10.4.11）	○	ダイヤのマーク（♦）だけが期待通りに表示されませんが、コピーして調べたりしてみると別の文字に文字化けしているわけではなく、コードポイントに変化はないようです。フォントを適切に設定することで表示されるのかも？
Safari 2.0.4 （Tiger 10.4.8）	一部×	「髙﨑」については×。

以上の結果を踏まえて、どちらの方式にプログラム側でデータを統一するかということを考えた場合、私には一目瞭然に思えます。Windows版IEの方式に合わせるべきでしょう。これは、単にWindows版IEのシェアの方がFirefoxより圧倒的に多いということだけではありません。

ブラウザ（Windows版IEとFirefoxのいずれか）の開発チームに仕様を変えるように言うことも選択肢かもしれませんが、そう簡単に仕様変更があるとは思えません。両者それぞれ深い考えがあってのことだと思います。ブラウザの側で統一されないなら、結局は、プログラム側で対応しなければならないでしょう。

ここで、Windows版IE派であれFirefox派であれ、「何でブラウザのバグなのにプログラムで対応しなければならないの？」　という疑問を持つ人もおられるかもしれません。非標準のバグっている仕様に敢えて対応することで、その悪しきバグを延命させるというか、認めてしまう結果になるとかいう発想も理解はできます。ただ、どちらの仕様が正しいかということも重要かもしれませんが、趣味のプログラマーやRFCそのものの研究家ならいざ知らず、実際に稼動している（or 稼動することを想定している）サイトのプログラムを作成されている人なら、どちらの仕様が正しいかということよりも、

• 「サイトの利用者の利便を考えたときに、どうするのが一番いいか？」　を考えれば、どういう結論になるでしょうか？（「（ブラウザのバグだから）対処しなくてもいいでしょう？、社長!」といように社長に弁明する際に、「ブラウザのバグ（実装ミス）」を盾にすることは私も以前はよくありましたが・・・、私の場合、「対処すべきでない」という発想を自分自身が持ったことはなかったですね。）
  
  
• 上記１は良い子ぶっているかもしれませんが、プログラマーの力の見せ所として、できるだけ他のサイトでは対応していないこともやってみたいと思う人なら、ブラウザのバグであれば、なおさら燃えないでしょうか？　（もしくは、サイト訪問者からのクレームを受けたくない（馬鹿にされたくない）、というような後ろ向きの動機という場合もあるかもしれません。）
  
  
• ビジネス的な観点（≒お金）から言っても、できるだけサイト利用者にとって嬉しい仕様のほうにしたいと考えた場合、ブラウザのバグだからとか言っておれないのではないでしょうか？
  
  

という疑問を持ってしまいます。

この際に、上記のテストでも明らかなように、補助漢字に対応しようとするのであれば^※2、Windows版IEの言葉はFirefoxは理解できるが、Firefoxの言葉はWindows版IEは理解できないのですから、Windows版IEの仕様に合わせるべきでしょう。そのようにすれば、文字化けになる確率がずっと減るのですから・・・（数値文字参照の「&問題」を解決できた場合）。Firefoxの方が賢いのですから、Windows版IEの仕様に合わせるべきだと思うのです。これは、別にFirefoxの開発チームに求めていることではなく、プログラマーがそのように仕様を合わせるべきだと思うのです。

※2 これを言ってしまえば終わりということになり、今更な発言ですが、補助漢字の処理で問題になるケースは実際にはそれほどないはずであり、対応しないというのも十分ありうる判断であるとは思います。

日本語や英語以外の言語で掲示板やブログでの書き込みをしたいという場合、及び「鷗外」「♦♠」などの記号を入れたい場合にのみ問題になりうることであり、ぶっちゃけた話、滅多にはないと思われるからです。ただ、ここでの議論は、もし「対応しようとするのであれば」という話になります。

PHPやPerlが標準で、そのような対応（２つの仕様のすり合わせ）をしてくれていたらベスト（≒「楽」）ですが、そうでないなら、プログラマーが自力で対応するしかないでしょう。（自分で作れないなら、補助漢字などの処理で問題になるケースははっきり言ってレアなケースでしょうから対応しないことにするか、他の献身的で優秀な方が既にライブラリーなどを公開していないか探すしかないでしょう。）

私が調べた限りでは、PHPやPerlが標準で、Firefoxなどの0x8F～の符号方法を数値文字参照にするような処理をしてくれる関数は準備されていないようです。ですから、対応しようとするのであれば、自力で対応するしかなさそうです。

具体的には、

• 「髙・﨑・德・彅」などCP51932で対応できる漢字以外の補助漢字や、補助漢字にも入らない記号や外国語に関しては、数値文字参照で対応することとになるのですが、PHPで言うとhtmlspecialchars関数を通すと、「&」が「&」になって数値参照文字が破壊される問題がありますから、それに対応しなければなりません。これがまず第一点。
  
  
• また、Firefoxの0x8Fで始まるデータを数値文字参照方式に変換しなければなりません。これが第二点です。

この際、「&」が「&」になって数値参照文字が破壊される問題を解決するために、そもそも「&」を「&」にする意味はどこにあるのか？　というのを調べたのが「【PHPネタ】htmlspecialchars関数はサニタイズ関数？ 」（昨年12月25日）の記事でした。

「&」を「&」にする意味が例えば、セキュリティ的な理由であるならば、不用意に数値文字参照や文字実体参照を普通の文字に変換するのは危険かもしれません。最終結論的には、「【PHP関連】「&」（アンパサンド）をエスケープしなければならない実例」（昨年12月31日）の記事で書きましたように、表示上の問題だけでなく、セキュリティ的な意味でも「&#数字;」や「&アルファベット;」、「&#x16進数文字列;」をpreg_replace関数などで一律変換するのは危険だと書きました。

そのような意味で、「&」を「&」の処理を入れるのはホワイトリスト方式にするのが良いです。これが私が出した結論です。

リストは徐々に拡大させていくこともできるでしょうし、リストが多くなれば多くなるほど処理時間がかさみますし、その結果、ブラウザに出力表示されるのが遅くなり、サイト訪問者を待たせる結果になりますので、少なくとも最初はリストのサイズを抑えたほうがいいでしょう。

リストの作成は今回は手動でやりましたが、例えば、韓国語のコードポイントは一定の箇所に集中して現れますので、ここの部分はプログラムで変換用データを作成することは可能だと思います（ずいぶん前のことであり、遠い記憶なのですが、誰かが韓国語用のライブラリを公開していたと思ったのですが、見つけることができませんでした。）。

各自のサイトの仕様に合わせたホワイトリストを作成すれば、ブラウザでの表示レベルにおいては、文字化けが減るでしょう（テストはしていませんが、メール送信が絡んでくると、JISでメールを送信する仕様にしている限りは、文字化けを回避することは難しいと思います）。

実際にプログラムしてみると、下記のような感じになると思います。

<?php //Windows Vistaで秀丸6.0.7（EUC-JP補助漢字をサポート）で作成。 //文字コードはEUC-JPで保存しています。 //効率よく、変換用データの作成もできるはずですが、 //とりあえず、手作業で入力。 //本当はハッシュにした方が見やすそう。 //置換前（配列データ） $white_list=array("&amp;#40407;",chr(143).chr(236).chr(191),"&amp;#50504;","&amp;copy;","&amp;reg;","&amp;trade;","&amp;#8364;","&amp;cent;","&amp;ouml;","&amp;Ouml;","&amp;auml;","&amp;Auml;","&amp;uuml;","&amp;Uuml;","&amp;aacute;","&amp;acirc;","&amp;agrave;","&amp;eacute;","&amp;ecirc;","&amp;egrave;","&amp;iacute;","&amp;icirc;","&amp;igrave;","&amp;oacute;","&amp;ocirc;","&amp;ograve;","&amp;#339;","&amp;uacute;","&amp;ucirc;","&amp;ugrave;",chr(143).chr(162).chr(237),chr(143).chr(171).chr(211)); //置換後（配列データ） $result_list=array("&#40407;","&#40407;","&#50504;","&copy;","&reg;","&trade;","&#8364;","&cent;","&ouml;","&Ouml;","&auml;","&Auml;","&uuml;","&Uuml;","&aacute;","&acirc;","&agrave;","&eacute;","&ecirc;","&egrave;","&iacute;","&icirc;","&igrave;","&oacute;","&ocirc;","&ograve;","&#339;","&uacute;","&ucirc;","&ugrave;","&copy;","&ouml;"); //IEでエンコードされた「鷗外」 $data="<b>&#40407;外</b>"; //Firefoxでエンコードされた「鷗」 ////\/i/ix8F//\/i/ixEC//\/i/ixBF $data.=chr(143).chr(236).chr(191); //Safari 3.0.5では文字化けしますが、とりあえずこのまま。 $data.="髙﨑"; //韓国語のアン（Windows版IE、Firefox、Safari共通） $data.="&#50504;"; //記号類（Windows版IEでエンコードされたもの）。 //euroマークはIEでも数値文字参照になるみたいです。 $data.="&copy;&trade;&reg;&#8364;&cent;"; //Firefoxの©マーク。//\/i/ix8F//\/i/ixA2//\/i/ixED $data.=chr(143).chr(162).chr(237); //ドイツ語のウムラウト（Windows版IE式） $data.="m&ouml;&auml;&Auml;&ouml;&Ouml;&uuml;&Uuml;"; //ドイツ語のö（Firefox式） //0x8F AB D3 $data.= chr(143).chr(171).chr(211); //フランス語の一部?（Windows版IE式） $data.="&agrave;&acirc;&icirc;&eacute;&egrave;&ocirc;&#339;&ugrave;&ecirc;&aacute;&igrave;&iacute;&oacute;&ograve;&uacute;&ucirc;"; //セオリーどおり、htmlspecialchars関数を通します。 $data_b=htmlspecialchars($data); header("Content-type: text/html; charset=EUC-JP"); print '<html><head><meta http-equiv="Content-Type" content="text/html; charset=EUC-JP"><title>テスト</title></head>'; print "<body>//\/i/in"; print "元データ: ". $data . "<br><br>//\/i/in"; print "対策前（htmlspecialchars関数をかけただけ）:" . $data_b . "<br><br>//\/i/in"; print "対策後:" . str_replace($white_list,$result_list,$data_b) ."<br>//\/i/in"; print "</body></html>"; ?>

● ホワイトリスト方式でやってみた正直な感想：
無茶苦茶面倒です。ブラックリスト方式でやってみたい誘惑に駆られましたが、これは駄目ですね。ホワイトリストの作成を効率的にできる方法も模索しないと駄目なようです。

編集者: shimax | このブログのURL |この記事のURL

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

● 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でサイトを構築すべきであるという結論ももちろんありでしょうが、必ずしもそうできない場合もありますから、その結論はとりあえず「抜き」にして、別の対処案を考えてみたいです。）

実験１：各種ブラウザは「鷗外」をどのようにエンコードするか？（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%B0	0x8F 0xEC 0xBF 0xB3 0xB0 （β版の挙動だからこうなのか、Operaは9.5以降、この方向性になるのでしょうかね・・・）
Safari 3.0.5 （Vista）	%B2%AA%B3%B0	0xB2 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の正式版でどうなるかですね。


実験２：各種ブラウザは「髙﨑」をどのようにエンコードするか？（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とも違う処理になっています。



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

実験３（番外編）：各種ブラウザは韓国語の「안녕하세요?」をどのようにエンコードするか？（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で構築されたブログや掲示板で投稿してください」ということになるのかもしれません。

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

実験４：各種ブラウザはドイツ語の「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%D3chte	m 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%D3chte	m 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%D3chte	m 0x8F 0xAB 0xD3 chte
Safari 2.0.4 （Tiger 10.4.8）	m%3Fchte	m?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%3B	0x8F 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も簡単インストーラで、すぐに利用可能です。

編集者: shimax | このブログのURL |この記事のURL

NetscapeブランドのWebブラウザのサポートが完全に打ち切られるとのこと。 これには最新のNetscape 9も含まれています。 いまだに多くのWebサイトがNetscape4以上を推奨ブラウザとし、Firefoxやその他のブラウザを推奨に挙げていませんが、これでNetscapeを推奨する意味がなくなりました。 各サイトにおいてはHTML標準に準拠し、IEやNetscape以外の主要ブラウザへの対応をお願いしたいと思います。 個人的にはFirefoxは必須でしょう、と思っています（WindowsもCentOSもFirefoxを利用してるので・・・・）。

編集者: たーとる | このブログのURL |この記事のURL

NetscapeブランドのWebブラウザのサポートが完全に打ち切られるとのこと。 これには最新のNetscape 9も含まれています。 いまだに多くのWebサイトがNetscape4以上を推奨ブラウザとし、Firefoxやその他のブラウザを推奨に挙げていませんが、これでNetscapeを推奨する意味がなくなりました。 各サイトにおいてはHTML標準に準拠し、IEやNetscape以外の主要ブラウザへの対応をお願いしたいと思います。 個人的にはFirefoxは必須でしょう、と思っています（WindowsもCentOSもFirefoxを利用してるので・・・・）。

編集者: たーとる | このブログのURL |この記事のURL

Mozilla Labs が 「Weave」 というプロジェクトを立ち上げました。Web上で使用する個人情報などのデータを記録/制御するオンラインサービスと、同サービスを使用するための Firefox3 の拡張機能を開発しているようです。 関連情報・hogeLog ? Mozilla Weave・Akira Ohgaki: Mozilla Weave ・Jungle Java - Firefox 3 Beta 2 リリース

編集者: baraki | このブログのURL |この記事のURL

今週は、複数のサイトのデザインや構成を考えて、必要なパーツの作成依頼をかけて、HTMLとにらめっこしながら、CSSをいじったりと、ウェブデザイナみたいな作業がメインな感じ。IE6/IE7/Firefox2 で動けばいいや、という感じだけど、やっぱり、3つで確認するのは面倒・・・。IE7への自動更新が近づいているから、それを過ぎれば、IE6からは開放されるかね・・・。

編集者: shinsuke | このブログのURL |この記事のURL

「Firefox 3 Beta 2」 がリリースされました。描画速度の向上と共に、メモリ消費についても大幅に改善された模様です。 ・Mozilla Japan - Firefox 3 Beta 2 リリースノート 関連情報・Firefox 3.0のβ第2版が公開 - β1以降の改良箇所は900以上 | マイコミジャーナル・Firefox 3 Beta 2レビュー：これは便利！な「スマートブックマーク」 - builder by ZDNet Japan p.s.「Mozilla Firefox, Portable Edition」 も 「3 Beta 2」 がリリースされました。 関連情報・Mozilla Firefox, Portable Edition 3 Beta 2 | PortableApps.com - Portable software for USB drives・MOONGIFT: » Firefox3を試してみたい方はこちらで「Firefox 3 Portable Edition」:オープンソースを毎日紹介

編集者: baraki | このブログのURL |この記事のURL