« 2007年12月 | トップページ | 2008年2月 »

2008/01/30

MacOSX+Web共有でPerl/CGIをプログラムする際に注意すべきこと

富士通WEB MART(SOHO・法人)
WindowsでApacheをインストールして、ローカルのテストサーバを運営していると、実にプログラムのテストが容易です。その便利さにかまけて、基本的なことを忘れてしまっていたことが原因ではまった現象がつい先日ありました。

基本的に、Windows XPもしくはVistaでテストすればそれで十分なのですが、現在開発中のプログラムで、MacOSXでのテストをどうしても行ってみる必要が出てきました。その時、非常に初歩的なことで、はまりました。お恥ずかしい話ですが、備忘録として・・・。

1.パーミッションの変更をしないといけない
Windowsでテストをしている場合には、そのようなことを意識せずともテストできますので、最初、eMac(Tiger)で5行程度のCGIプログラムを作成して実行してみると、「403 Forbidden」と言われたので、理由が分からず焦りました。Terminalからファイルのパーミッションを705に変更て、これでOKかと思ったら今度は恐怖の「Internal Server Error」大王の登場です。

2.改行コードはLFに明示的に変換しないと動作しない。
エラーログを見てみると、「[error] (2)No such file or directory」となっています。「そんな(such)ファイルやディレクトリーはない」というのですが、suchが何を指しているのか最初は分かりませんでした。Perlのパスかなと思い、whichコマンドで調べて、「/usr/bin/perl」であることを確認。「おかしいな、あっているのににな」と考えること数分。Perl/CGIの場合、改行コードの問題で動作しないことがあることを、遠い記憶から呼び起こしました。

Windows + Apacheでは、改行コードが「CRLF」のままでも動作します。また、FTPソフトでUnix系サーバに転送した場合、自動的に改行コードを変換してくれるので、「改行コードが問題になっている」ということに全然気づきませんでした。

Jedit Xでプログラムしていて、デフォルトのまま使っていたので、改行コードがCRになっていることに気づきませんでした(もちろん、別に、Jedit Xの責任ではないですけど)。改行コードをLFに変更したところ、Internal Server Errorは消えて、無事にプログラムが実行できました。

結局のところ、Windowsでプログラムを作成して、UnixサーバにFTP転送する際に、パーミッションも自動変更してくれますし(NextFTPでは設定できます。)、改行コードも自動変更してくるので、基本的なことをすっかり忘れてしまっていましたのでした。

| | コメント (0) | トラックバック (0)

2008/01/14

EmEditorと補助漢字



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

続きを読む "EmEditorと補助漢字"

| | コメント (0) | トラックバック (0)

2008/01/12

【PHPのとあるエラー】Warning: fopen(): URL file-access is disabled in the server configuration in



AmazonのWebサービスを使ったサイト(PHP)の構築のために、海外のレンタルサーバでfopen関数を使って、XMLデータを取得していました。もちろん、AmazonのXMLサーバが混んでいて、うまくデータを取得できない場合も考えて、エラー処理を入れていました。

エラー処理では、そのような場合には、http://www.amazon.co.jpの該当asinページに飛ばす(redirectする)ようにしていました。ただ、ログに残したり、メールで通知が来るようにまではしていませんでした。そのため、いつのまにかfopenに常に失敗している事態が発生していることに最近まで気づいていませんでした。

ところが、最近になって、常にエラー処理の方が行われており正常な処理がされていないことに気づきました。関数名の前の「@」を取って、確認してみると、

Warning: fopen(): URL file-access is disabled in the server configuration in ・・・

エラーの内容から、allow_url_fopenの設定がいつの間にか変えられていて、fopenでリモートのファイルをオープンすることが禁止されていることが想像できました。「やられた」と思いました。恐らく、レンタルサーバの事業者から事前に連絡はなかったと思います。(スパムが大量すぎるので、英語の件名のメールの場合は、ウイルスバスターのスパム判定をほぼ無条件に信じて削除して待っているので、スパムと間違って削除した可能性はありますが・・・。)

セキュリティを考慮してサーバの設定をいじくるのはレンタルサーバ事業者としてありうることでしょうが、事後でも連絡してほしいものです。おかげで、正常処理されていればサーチエンジンにしっかりと登録されているはずのページが、amazonへ単純にリダイレクトしているだけの意味のないページとして判断され、サーチエンジンから登録の多くが消えてしまっていました。

ただ、過去の記事にも書いたように、海外のレンタルサーバ事業者は絶対に「I'm sorry.」とは言わないし、文句を言ってもストレスがたまるだけです(早く乗り換えようと思っているのですが、安さとディスクスペースの多さに負けて、なかなか乗り換えられないでいます)。だから、今回は黙って対処することにしました。

PHPの本家のfopenのページを見てみると、すぐに解決策は見つかりました。「Luiz Miguel Axcar (lmaxcar at yahoo dot com dot br)」さんのユーザーコメントにcurlを使った代替策が載っていました。この代替策で無事解決できました。

| | コメント (0) | トラックバック (0)

2008/01/03

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



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

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

実験2-1:各種ブラウザは、補助漢字や補助漢字外の韓国語や記号に関して、Windows版IE形式で符合された文字列を意図通りに表示できるか?(EUC-JPのページで)
「鷗外」「髙﨑」「möchte」「안녕하세요?」「©♦」でテストしました。
IE7(Vista)※1これは当たり前。
IE6(XP SP2)
IE5.5(Windows 2000)
Firefox 2.0.0.11
(Vista)
※1IEの「言葉」をFirefoxは理解できます。
Firefox 3.0β2
(Vista)
Firefox 1.0.8
(XP SP2)
Netscape 7.1
(Vista)
Opera 9.25(Vista)※1Opera 9.25の符号方法はWindows版IEと全く同じなので、これも当たり前。
Opera 9.5β1
(Vista)
※1IEの「言葉」を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)
一部×「髙﨑」については×。

※1 ただし、多くのWEBアプリケーションで「&」をエスケープします(このこと自体は正しい処理です。)が、数値文字参照や文字実体参照の存在を考慮していないことがほとんどのため、これらの文字は意図通りに表示されないことが多いのも事実です。

これがhtmlspecialcharsの仕様について、ここ数日間いろいろ調べていたきっかけであり、いろいろ書きなぐってきた記事の最初の出発点です。そもそも、「&」をエスケープしなければならないのはなぜか?に始まって、やっぱりエスケープしないといけないんだという結論に至るまで相当の時間が必要だったのですが、「HTMLの仕様がそうなんだから」とかいう理由ではなく、実例で理解したかったので、これはこれでよかったと思います。


実験2-2:各種ブラウザは、補助漢字や補助漢字外の韓国語や記号に関して、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 稼動することを想定している)サイトのプログラムを作成されている人なら、どちらの仕様が正しいかということよりも、
  • 「サイトの利用者の利便を考えたときに、どうするのが一番いいか?」 を考えれば、どういう結論になるでしょうか?(「(ブラウザのバグだから)対処しなくてもいいでしょう?、社長!」といように社長に弁明する際に、「ブラウザのバグ(実装ミス)」を盾にすることは私も以前はよくありましたが・・・、私の場合、「対処すべきでない」という発想を自分自身が持ったことはなかったですね。)

  • 上記1は良い子ぶっているかもしれませんが、プログラマーの力の見せ所として、できるだけ他のサイトでは対応していないこともやってみたいと思う人なら、ブラウザのバグであれば、なおさら燃えないでしょうか? (もしくは、サイト訪問者からのクレームを受けたくない(馬鹿にされたくない)、というような後ろ向きの動機という場合もあるかもしれません。)

  • ビジネス的な観点(≒お金)から言っても、できるだけサイト利用者にとって嬉しい仕様のほうにしたいと考えた場合、ブラウザのバグだからとか言っておれないのではないでしょうか?

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

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

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

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

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

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

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

  • また、Firefoxの0x8Fで始まるデータを数値文字参照方式に変換しなければなりません。これが第二点です。

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

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

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

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

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

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

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

続きを読む "ブラウザ別EUC-JP補助漢字などのサポート状況(2)"

| | コメント (0) | トラックバック (0)

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ページにメタタグによる文字コード指定(<meta http-equiv="Content-Type" content="text/html; charset=EUC-JP">)がブラウザによっては必須のようです。)
ブラウザ名URLエンコードデコードしたもの
(ピンク部分は私が注目したところで、特別な意味はありません。)
IE7(Vista)%26%2340407%3B
%B3%B0
&#40407; 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&#40407;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
(原則どおり、補助漢字として処理)→
(2008年1月4日午前10時ごろ追記)
Safariのエンコード方法は、eucJP-msに近いと言えるのかもしれません。
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補助漢字のサポート状況(1)"

| | コメント (0) | トラックバック (0)

« 2007年12月 | トップページ | 2008年2月 »