« 2007年11月 | トップページ | 2008年1月 »

2007/12/31

【PHP関連】「&」(アンパサンド)をエスケープしなければならない実例



ここ最近、htmlspecialchars関数について調べていて、いろいろ記事にしていたのですが、コメントをいただいた。参照となるページを教えていただいたのですが、実はそのページは、この記事を書く前に既に読んでいました。コメントに書かれていたページのURLをここに記させていただくと、

●「サニタイズ言うなキャンペーン」私の解釈(2006/11/29)
http://kmaebashi.com/zakki/zakki0042.html

です。で、私の文章の書き方が悪かったのかもしれませんが、私はこの方の解釈とほぼ一緒(のつもり)です。ただ、このページで例として挙げられている「Taro&Jiro's castle サウスポール」の「&」は別に「&」とエスケープしなくても「Taro&Jiro's castle サウスポール」と表示されます。

そのため、そもそも「&」を「&」とエスケープしなければならない場合とは何かということを考えていました。その実例がやっと見つかりました。今回いただいたコメントをきっかけに気づいた事例もあるのですが(コメントを下さったshiさん、ありがとうございます。)、それは後述するとしまして、まず、下記をご欄ください。

あいうえお&rlo;こけくきか

上の文字列は、「あいうえおかきくけこ」と見えると思いますが、ソースは「あいうえお&rlo;こけくきか」となっています。

&rlo;」はUnicodeの制御文字で、文字列の方向を変えるためのものです。アラビア語などでは右から左に文字を書くので必要ということらしいです(昔の日本語も確かそうだった?)。

この「&rlo;」(数値参照文字なら「‮」)が出現すると、後続の文字列がおかしくなる(全部ではなく、一定のパターンでストップがかかるみたいです。)ので、
http://live.2ch.net/dome/kako/1010/10104/1010445506.html

のような現象が起きます。この2chの「&rlo;」騒動は2002年当時からあったみたいですね。今頃知って、お恥ずかしい。

&rlo;」が入った場合にどれだけの後続の文字列を道連れにするかはまだ十分に検証できていませんが、HTMLソースのパターンによっては大規模な「表示化け」が起こりそうです。実際、Googleの検索結果でも、こちらのページはページタイトルや検索結果の件数が表示されている部分が、文字の順番が逆になっています。

&rlo;」を入力され、「&」を「&」にエスケープしない場合(あるいは、htmlspecialchars関数を通した後、「&」を「&」に戻す処理を入れている場合)、ページの一部分の表示が乱れることももちろん問題ですが、
  • 例えば、NGワードを決めているような掲示板やブログがあっても、それをスルーされてしまいます。「氏ね」をNGワードにしたいのに、「&rlo;ね氏」と入力されてしまうとチェックできまないことになります。
    (--2007年12月31日午後17時13分頃の追記 start--)
    でも、考えてみれば、「&」を許可してしまうと、「「氏ね」と書けば「氏ね」と表示されることになります。NGキーワード形式を取っているサイトでは「&」を許可してしまうと、数値文字参照方式での記述も同時にNGワードかどうかチェックして(10進数形式ではなく、16進数形式の「氏ね」でも駄目としなければなりません。)、NGワードに該当すればブロックできるようにプログラミングしておかないといけないので、なかなか面倒そうですね。

    そういう意味でも、EUCの補助漢字を処理する場合、「&」については、「原則はタグとして実行されるのは禁止(=エスケープ処理)で、例外的なものも一部認める」というホワイトリスト方式にしないといけなさそうです。つまり、「htmlspecialchars関数の仕様は、実に理にかなっている。」ということになりそうです。
    (--2007年12月31日午後17時13分頃の追記 end--)

  • 掲示板やブログが荒れる元になりえます。そういうことをして喜ぶ連中に狙われると大変です。
  • 別の脆弱性を突く攻撃との組み合わせなどで、何かあるかもしれません。(私は知らないだけで、何かあるのかもしれません。)
という問題が考えられると思います。ですから、「htmlspecialchars関数を通した後、「&」を「&」に戻す処理を入れること」は、やはり慎重になったほうが良さそうです。

さらに、前述のように、今回コメントで書いていただいたページ(「サニタイズ言うなキャンペーン」私の解釈(2006/11/29))は既に読んでいたのですが、この記事を書くために、改めて読み直し、さらにHTMLソースを見させていただいて、あることに気づきました。文字参照の末尾のセミコロン「;」があってもなくても、ちゃんと表示されるんですよね。ということは、「Taro&Jiro's castle サウスポール」の場合は、「&」をエスケープしなくても問題ないのですが、「Taro&copy's castle」の場合は、エスケープしないと「Taro©'s castle」になります。

私はセミコロンがないと動かないと思い込んでいたため、「Taro©'s; castle サウスポール」と入力して、「Taro©'s; castle サウスポール」のように表示されているかといって、「『Taro©'s; castle サウスポール』と表示されるべきなのでは? 」と文句を言う人がいたら、ただのクレーマーだと思っていたのですが、「;」なしでも動くなると、場合によっては、文字参照と解釈してほしくない場合だってあるかもしれないと思えてきました。

URLを紹介する場合に、パラメータに「copyright」というのがあって、これに「&」が付くと、
http://www.example.com/example.php?hoge=1&copyright=1
のようになります。この時、エスケープしないままURLがソース内にありますと、
http://www.example.com/example.php?hoge=1©right=1
のように、IE7やIE6 SP2では表示の際に「&copyright→©right」と解釈して、問題(Firefox 2.0.0.11やOpera 9.24では大丈夫)ということになりますから、ソースレベルでは、
http://www.example.com/example.php?hoge=1&copyright=1
と書いて、
http://www.example.com/example.php?hoge=1&copyright=1
と表示されるようにしなければなりません。以下、ブラウザの解釈によって違うようですが、

http://www.example.com/example.php?hoge=1&ampm=1
とソースの中で記述しなければ、
http://www.example.com/example.php?hoge=1&m=1
のようになります。「&ampm→&m」のように解釈されます。

http://www.example.com/example.php?hoge=1&regist=1
とソースの中で記述しなければ、
http://www.example.com/example.php?hoge=1®ist=1
のようになります。「&regist→®ist」のように解釈されます。

http://www.example.com/example.php?hoge=1&century=21
とソースの中で記述しなければ、
http://www.example.com/example.php?hoge=1¢ury=21
のようになります。
&century→¢ury」のようにIE6 SP2やIE7は解釈します。

ちゃんとエスケープしないと、
http://www.example.com/example.php?hoge=1&times=1
と表示したいのに、
http://www.example.com/example.php?hoge=1×=1
にのように表示されることがあります。これらの文字が問題になりえます。

http://www.example.com/example.php?hoge=1&para=1
と表示されたければ、
http://www.example.com/example.php?hoge=1&para=1
とソースの中で記述しなければなりません。そうでなければ、「&para → ¶」のようになります(これはIEだけでなく、Firefoxでもそうなるみたいです。Operaではなりませんでした)。パラメータの意味で「para」とかいう名称は使いたくなりそうですし、気をつけたほうが良さそうです。

下記のリンクにカーソルを合わせていただくと、IEやFirefox(2.0.0.11)では、リンク先URLが文字化けしていることが分かります。実際クリックすると、予期しないページに飛びます。
¶

「そんなの当たり前」と思われるかもしれませんが、私は「;」がなくても表示されることを知らなかったため、このような事例に今の今まで気づきませんでした。

ここ最近の記事を書くきっかけになった「EUCのページにおける補助漢字の処理」に関しては、結局のところ、どうしていいか分からないというのが実情です。「‮」対策を考えると「正規表現+例外処理」になりそうですが、これだと漏れが生じる可能性もあるかもしれません。

&」のエスケープにより、「鷗」やフランス語などの一部外国語ぐらい(補助漢字ではありませんが、ハングルなどの一部外国語)しか実質・文字化けしないのであれば、下手に触らないで、今のまま放置しておいたほうが無難であるという感じに思えてきました。

もしくは、数千字ある補助漢字や、「©」「®」などの文字実体参照のうち、「わりと使う文字だけ」をピックアップして、変換テーブルを作成して対処するホワイトリスト方式がいいのかもしれません。一律にpreg_replace関数で変換し、例外処理もプラスするブラックリスト方式は何だか怖い気がします。

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

2007/12/27

【PHP関連】htmlspecialchars関数が万能でなくなるケース(2)



htmlspacialchars関数をそのまま単純に通すだけでは問題になる2例について、昨日の記事「【PHP関連】 htmlspecialchars関数は万能で、神聖不可侵か?」では書きました。ただ、この2例の問題ともセキュリティには関係がない話でした。

今日は、htmlspecialchars関数を通しても、場合によってはセキュリティ上、問題になるケースについて取り上げてみます。htmlspecialchars関数の責任ではないのですが、HTMLタグの書き方が悪いなど他の要因によって、htmlspecialchars関数では危険な要素を取り除くことができない場合があるということです。例えば、

1.UTF-7とXSS問題
「文字化け」を利用した攻撃。メタタグを明示していない場合に、ブラウザがそのページのエンコードをUTF-7と解釈すると、例えば、「+ADw-script+AD4-alert('hoge')+ADsAPA-/script+AD4-」という文字列がJavaScriptとして実行されるということです。「<」や「>」のような文字列は一切登場しませんが、UTF-7では、「<」を「+ADw-」のように符合することから、htmlspecialchars関数では対処しきれずに、このような問題は発生します。詳細は、下記のサイトを参照してください。

● UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意
http://slashdot.jp/security/article.pl?sid=05/12/21/2318216

● www.google.comにクロスサイト・スクリプティングのぜい弱性,米Watchfireが報告
http://itpro.nikkeibp.co.jp/article/USNEWS/20051222/226650/

● 【PHP TIPS】 36. UTF-7とクロスサイト・スクリプティング
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270087/

ただ、メタタグで文字コードがきっちり指定されていれば、ブラウザに意図的に誤認させる方法はないのか、極めて難しいのか、上記Googleの件でもメタタグで文字コードを指定することで「対策」となっているようです。

 結局、この問題はhtmlspecialchars関数の問題ではありません。メタタグが指定されておらず、かつ、ページ内によっぽど文字が少ないか何かで、少量のUTF-7らしき文字列が注入されている(しかも、ページソースの上部で)というような、複数の条件が重ならない限りは起こらないようです(ただ、メタタグがある場合でも、意図的に悪意のある第三者が、ブラウザに文字コードを誤認させる方法があるのかもしれませんが、それだと対策はとても難しくなりそうです)。

もちろん、他のサイト訪問者にブラウザのエンコードを変更操作するように仕向けられた場合には問題が発生しますが、今IE6 SP2(XP)やIE7(Vista)を見てみると、「UTF-7」というのはそもそも選択肢にないですね。FirefoxやOperaにはありますが・・・。FirefoxやOperaでこのページの文字エンコーディング(Operaの場合は、「エンコード」)を変更すると「hoge」と表示されるはずですが、このような誘導には乗らないようにしてください。

Googleの対策が正攻法であると感じるのは、「+ADw-」や「+AD4-」、「script」だけを取り除く(これこそ「サニタイズ」?)という方法を取らなかったことです。危険な文字列をチェックする方法を取ると、どうしても取りこぼしが生じやすくなり、脆弱性の温床になりやすいからです。


続きを読む "【PHP関連】htmlspecialchars関数が万能でなくなるケース(2)"

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

2007/12/26

【PHP関連】 htmlspecialchars関数は万能で、神聖不可侵か?



昨日書きました「【PHPネタ】htmlspecialchars関数はサニタイズ関数?」の続きです。「セキュリティ云々という視点ではなく、正常系の処理をしているだけでも、大方のセキュリティ上の問題は自然とクリアできるはずなのに、『サニタイズ』という言葉をスローガンにして局所的に対応しようとするから、対策漏れが生じやすくなり、ミスが蔓延る」(上記要約は筆者がしましたので、間違っているかもしれません。各自、直接自分で読んで確かめてみてください。難しい文章ですが、何回か読んでいるととても趣旨一貫した文章だと感じられると思います。)という高木氏の主張(参照ページ)はよく理解できました(と思います)が、GIGOE氏の言う「『HTML出力と見たらhtmlspecialchars()をかける』、なんて思考停止な方法では、XSSやScript Insertionは完全には防げない」(参照ページ)という主張も、よく分かります。

まず、「思考停止」の状態かどうかは別として、単純にhtmlspecialchars関数を通すと、「鷗外」の「鷗」の字がPOSTされた際に、確認画面では「&#40407;」になってしまい(EUC-JPのフォームでIE7やIE6で送信した場合の話です。)期待しない結果になることは、「【PHPネタ】htmlspecialchars関数はサニタイズ関数?」でも書きました。

また、補助漢字の事例を出さなくても、EUC-JPのページで「♠♥♦♣↩❖」などの記号を入力し、IEやFirefoxでPOSTすると数値文字参照になりますから、htmlspecialcharsを通すと、やはり問題が生じます。htmlspecialchars関数でエスケープ後、再び、正規表現(preg_replace関数)で数値文字参照を元に戻してあげる処理を入れないといけないのでは? と昨日の記事で書きました。

「フォームでユーザー(サイト訪問者)が入力してPOSTしたものそのものが確認画面で表示されるのが原則。」という観点からhtmlspecialchars関数は存在しているのではないかという推論が正しいとするのであれば、この補助漢字や各種記号の処理はバグもしくは、不十分な処理と言えるのではないでしょうか? 少なくとも発展途上に見えます。

ただ、PHPがたいして難しくもないように見える、「文字実体参照」「数値文字参照」の例外処理追加を拒み?、現状htmlspecialchars関数がこのような仕様になっているのは何か理由があるのかもしれません。例えば、楽天ブログでは、EUC-JPのページですから、IEで「鷗外」と入力して投稿しようとすると、数値文字参照が生じることとなり、その結果というのか、「&# は利用できません」というエラーになり投稿できません。(Firefoxなら「鷗外」の投稿は可能ですが、そのブログを見たIEユーザーには、「乗ス外」と表示され文字化けします。Firefoxで入力した「鷗外」がIEでは「乗ス」に文字化けするからくりは、森山先生のサイトをご覧ください。)

(それなのに、楽天ブログでは、「&copy;」の投稿はOKになっています。天下の楽天・開発陣が微妙な線引きをしていることも余計に、「数値文字参照を許可してしまうと何か起こるのではないか」と不安になります。)

続きを読む "【PHP関連】 htmlspecialchars関数は万能で、神聖不可侵か?"

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

2007/12/25

【PHPネタ】htmlspecialchars関数はサニタイズ関数?



EUCの補助漢字をPHPでどのように処理するかを調べていて、1年前に自分で書いた記事(「IE7と補助漢字(「森鴎外」と「森鷗外」)」)やそのリンク先などを読み返したりしていました。EUC-JP(細かい定義はカットします。Windowsで作成した所謂EUCでエンコードされたもの。)のページで、フォームを作成したとします。その際、サイト訪問者がEUCの補助漢字の大御所?「森鷗外」を入力したとします。すると、「鷗」の字は、「%26%2340407%3B」にURLエンコードされますから、それをデコードすれば、「&#40407;」になります。それをそのままブラウザに表示すれば、「鷗」になります。これで、めでたしめでたし、となるはずですが、そう簡単にはいきません。

 (2008年1月1日午前6時10分ごろ追記) 今読み返してみると、舌足らずでした。数値文字参照で表示されるのは、IE7やI6 SP2での話です。Firefoxなどでは、(良いのか悪いのかは別にして)補助漢字をサポートしています(=該当文字を「0x8F」で始まる3バイト文字として処理する。IEとの互換性がありません。参照: http://i.hatena.ne.jp/idea/1740 )ので、数値文字参照になりません。これは1年前の記事「IE7と補助漢字~」でも書いていたり、そのリンク先ページでも書かれていることですが、今回この記事を書くにあたって、そのことを改めて書くのを忘れていました。私が記事を書くにあたって、1年前の記事が自分の頭の中には入っていたものですから、てっきり説明していると思い込んでいました。失礼しました。

なお、文字コード指定のメタタグをしっかりと入れていない場合、このテストはうまくいかないようです。数値文字参照にならないというより、「鷗」と一緒に送信した別の漢字も一緒に文字化けします。「鷗」の後続の文字が文字化けするというだけでなく、「鷗」の前の漢字も文字化けしますので、検証テストする方はメタタグを入れてテストしてください。

htmlspecialchars関数を通して表示させると、「&#40407;」の「&」もエスケープされて、「鷗」の字は表示されず、「&#40407;」がそのまま表示されてしまいます。これは問題です。htmlspecialchars関数を使わないと、セキュリティ上宜しくないですし(この「セキュリティ上」という文脈に限定するのが正しいのか?というのが本稿の目的ですが、これについては後述します。)、かといって、htmlspecialchars関数を通すと、一部の漢字が「文字化け」します。

それで他のプログラマーはどのように処理しているのかと調べていて、まず、
● NobuNobu XOOPS別館 » めもらんだむ : MyTextSanitizerのhtmlSpecialChars考 (1) by nobunobu
http://www.nobunobu.com/blog/2006/05/14/mytextsanitizer-1/

が目に入りました。天下のXOOPSでも、結局、htmlspecialchars関数を実行後、「&amp;」を「&」に戻す処理を入れているみたいです。じゃ、何でそもそもhtmlspecialchars関数は、「&」を「&amp;」に変換する処理をやってくれているのかが疑問になってきました。

「<」や「>」などの変換はもちろん、スクリプトを実行させないためにも重要ですし、「"」や「'」もその理由は分かります。ですが、「&」は何のために変換してくれているのでしょうか?

さらに原点に立ち返るために、PHPの総本山のマニュアルにあるユーザーコメント(beer UNDRSCR nomaed AT hotmail DOT comさんやjspalletta at gmail dot comさん)でも、やはり、preg_replaceで「数値文字参照」や「文字実体参照」を変換する方法を紹介しています。これの方が全ての「&amp;」を「&」に戻すわけではないので、「いろんな意味」で問題なさそうです。

ここで、「いろんな意味で」と書いたのには、理由があります。私は、下記に紹介しますサイトの論争(2年前のもの)をつい最近読むまで、htmlspecialchars関数はサニタイズ関数というのかセキュリティ上の関数だと思い込んでいました。そのために、htmlspecialchars関数でせっかくサニタイズしてくれているのに、「&amp;」を「&」に戻す処理をプログラマーが勝手に入れてしまうと、思わぬセキュリティホールが入り込んでしまうのではないかと危惧していて、いろいろ調べまくっていたわけです。で、思わぬセキュリティホールを生み出すぐらいなら、「鷗外」の「鷗」がPOST(or GET)によって「&#40407;」に「文字化け」してしまっても、そういうのは極めてレアな入力パターンであり、韓国語の「안녕하세요?」がPOST(別にGetでもいい。)で、「&#50504;&#45397;&#54616;&#49464;&#50836;?」に「文字化け」して表示されるのと本質的には同じ理屈であり、日本語のサイトに韓国語を入力して期待通りに動作することを要求するのは、或る意味嫌がらせなので、無視した方がまだマシという観念がありました。

続きを読む "【PHPネタ】htmlspecialchars関数はサニタイズ関数?"

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

2007/12/14

auからのメールをPCで受信した際に、文末に「忞」の文字が入っている場合(文字化け解読)

私は携帯は持っていないのですが、妻の友達はやはり?携帯を持っていて、携帯からよくメールを送ってくださいます。妻はパソコンでメールを受信していますが、子育てで忙しいので、妻のメールは私のパソコンにも入ってくるようにしてあって、メールが来ると「なんか、メールが来ていたよ」と教えてあげます。いろいろなテレビ番組を見ていると、伴侶の携帯メールの中身を見たとか見ないとかでもめる場合があるようですが、私たちの家庭にはそれが全然ないのは、本当に恵まれていると思います。

動的なHTMLソースをリアルタイムにサーバ上で暗号化(JavaScriptソースを生成)するPHPライブラリさて、その妻のお友だちからのメールには、毎回ではないのですが、かなりの頻度で「忞」という文字が入っています。「文」の下に「心」で字自体は難しくないのですが、読めないので難しく感じます。調べてみると、「ビン」とか「つとめる(送り仮名は?)」と読むようです。

絵文字であろうことはすぐに分かりましたが、いったいどんな文字が書かれていたのか気になりだしましたので、調べてみました。

KDDI au: 技術情報 > 絵文字
http://www.au.kddi.com/ezfactory/tec/spec/3.html
http://www.au.kddi.com/ezfactory/tec/spec/pdf/typeD.pdf

このPDFファイルにて、その正体はわかりました。左の「あせり」のマークです。

ただ、ここまでたどりつくのはかなり時間がかかって、(少なくとも最初は)あてずっぽうなところがありました。経緯を全部書くととても長くなるのですが、まず、このタイプDのPDFを開くと、「KDDI絵文字用Shift-JISコード」「Unicode」「絵文字 Eメール送出用JIS」「(参考)Eメール送出用JIコードに対応したShift_JISコード」と項目がたくさんあって、どれを使って照合したらいいのか一目では分かりませんでした。

どこから攻めても同じ文字にたどり着くのなら分かりやすいのですが、私のやり方が悪いのか、相互の文字コード変換をPHPでいろいろやってみても、どうもうまくいきません(独自の変換アルゴリズムがある?)。結局、私が唯一理解できたのが、「絵文字 Eメール送出用JIS」でした。IME-2002(IME バッド - 文字一覧)で調べてみると、「忞」のJISコードは「0x7a21」です。auが「0x7a21」で何らかの文字をメールで送信しているので、パソコン(Windows)でメールを受信すると、マイクロソフト社が考えるところの「0x7a21」である「忞」の字を表示させているのであろうと考えれば、理屈が通ります。

そして、auのPDFで「絵文字 Eメール送出用JIS」が「7a21」であるものを探してみると、右の画像(絵文字番号452.PDFの8ページ目)だったというわけです。

ただ、この一例だけを以ってして、この解釈が正しいかどうかを結論付けることは、はなはだ怪しかったので、別の文字化けの事例を探してみることにしました。すると、その妻の友達からのメールで「寬」という文字が文末にあるメールが1通ありました。「寛大」の「寛」に似ていますが、少し違って異字体のようです。

この「寬」のJISコードをIME-2002で調べてみると、「0x796e」でした。たまたまですが、「忞」のすぐそばにありました。この文字コードでau提供のPDFを調べてみると、絵文字番号435番の「みかん」のようです。正直、焦りました。あまりにも唐突なような気がして、この解釈が間違っているように思えたからです。

しかし、そのメールの本文をよく見てみると、「みかんがり行ったのでまた食べてね寬」とありました。みかんを届けてくれた際のメールだったのです。ここで、この探し方の正しさをほぼ確信できるようになりました。でも、これでは、あまりにもアナログ的解決であり、何とかプログラムで、文字化けしている文字の正体を探す方法はないかと考えてみることにしました。元の文字のJISコードを探し出してからの作業は、PDFファイルからアナログ(目視)で探し出すのか、それとも完全データベース化しておいてプログラムで検索させるかはここでは置いておいて、とりあえずJISコードを求めるところまでをPHPで行いたいと考えました。かなり強引なやり方ですが、

のようにすることで、「忞」のJISコードは「(0x)7a21」であり、「寬」のJISコードは「(0x)796e」であることが計算できました。もっと文字コードの勉強をしないといけないです。



続きを読む "auからのメールをPCで受信した際に、文末に「忞」の文字が入っている場合(文字化け解読)"

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

2007/12/13

PHPで、いわゆる機種依存文字の文字コード変換(EUC-JP→UTF-8)にはまる



私が作るPHPのサイトは、大概、EUC-JPを内部エンコーディングと設定して作成しています。それで今まで特に困ったことはなかった(自動応答メールなどに「㈱」「髙」などの機種依存文字が含まれていると文字化けすることはありましたが、そのような場合、そのような文字を入力するユーザーの知識不足を問題視していることが実際多かったのですが・・・。)のですが、今回は困りました。

いわゆる機種依存文字(「①」「㈱」「Ⅱ」「㌔」など)をEUC-JPからUTF-8へ変換しようとすると、該当文字が「?」(クエスチョンマーク・はてなマーク)に化けてしまいます。変換不能状態です。我ながら今更ですが、mb_convert_encoding()関数において、「eucJP-win→UTF-8」のようににするとこれらの文字変換はうまくできるようになることが分かりました(=下記サンプルコードの方法2)。

ただし、「髙」「纊」「忞」などの変換はできません。13区の特殊文字は、eucJP-winにすることで変換できましたが、「IBM拡張文字」もしくは「NEC選定IBM拡張文字」(PHPが結局、この2種類の拡張文字のどちらをどのように使い分けているのかについての考察はいつかしたいですが、今は省きます。)の文字コード変換はできず、どうしたものかと悩んでいました。

ところが、思いつきで、一旦、SJISに変換してからUTF-8に変換したらどうなるかと考えて、ただの?SJISではなく、sjis-winに変換後、さらにUTF-8に変換すると、うまくいうことが判明しました。まとめると、下記のようになりました。

方法1では、ぜんぜん駄目で、「?あいa???????アイウエオ」になりました。方法2では、13区の特殊文字はクリアできましたので、「あいa①㈱Ⅲ㌔アイウエオ」のようになりました。方法3では、「纊あいa忞寬①㈱Ⅲ㌔髙アイウエオ」のようになり、完全勝利です。

しかし、です。これは、あまりスマートではありません。何かいい方法はないものかと思索中です。

2007年12月18日22時17分ごろ追記
その後、下記のコメントに寄せていただいたmoriyamaさんのコメントがとても役に立ちました。PHPのバージョンを5.2.1以上に上げるか、パッチを適用するか、もしくは、上記私の記事の方法3のように2段階にするしかないようです。

私のやろうとしたこととは逆ですが、UTF-8の文字をEUC-JPに変換する際には、moriyamaさんが言われているように、注意事項として、
(以下、引用)
UTF-8 -> CP51932 を SJIS-win 経由で変換する場合は、SJIS-win に変換した後、IBM拡張文字をNEC選定IBM拡張文字に置換してから EUC-JP に変換する必要があると思われますのでご注意ください。
です。

このIBM拡張文字をNEC選定IBM拡張文字に置換してからというのが結構はまりがちのポイントだと思います。「はてな」にも同様の質問が先月あったようです。回答数は多いものの、本日現在は3件しか開かれていない状態で解決方法が表示させていないみたいです。

[はてな] PHPで機種依存文字の文字コード変換のやり方がわからなくて困っています。UTF-8の文字列をEUC-JPに変更する必要があるのですが「髙(はしご高)」などの機種依存文字を・・・
http://q.hatena.ne.jp/1194491169

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

2007/12/04

動的なHTMLソースのリアルタイム暗号化(JavaScriptソースの生成)に対応したPHPライブラリ

株式会社プランセスが、動的なHTMLソースのリアルタイム暗号化(JavaScriptソースの生成)に対応したPHPライブラリ「サーバサイドSHTML」をリリースしました。

動的なHTMLソースをサーバ上でJavaScript化するため、例えば、データベース(MySQLやPostgreSQLなど種別を問わず。)などを使った動的なページでも、ページ全体のソースがJavaScriptで難読化・暗号化されているとうわけです。

右クリック禁止やテキスト選択禁止は簡単に導入できるけれど、ソースを見られてしまえば「終わり」という問題がどうしてもあり、HTMLソース全体をJavaScriptで暗号化・難読化する製品がいくつか出ているわけです。しかし、今回画期的だと思われるのは、今までは静的なHTMLソースのJavaScript化(「難読化」・「暗号化」・「エンコード」など呼び方はいろいろあるでしょうが・・・。)は出来ても、動的なデータの暗号化には、サーバサイドのプログラムでJavaScriptを生成させるという、より複雑なことをしなければならなかったため、なかなか類似商品がなかったように思われます。

PHPで処理するわけですから、PHPで構築されたイントラネットなどで、ログインしている人物をクッキー・セッションなどで判別することにより、例えば、管理者には印刷やテキストのコピーを許可し、一般の社員には閲覧のみを許可するなどのご利用方法も可能になるでしょう。

また、社内掲示板やブログでの情報流出にも応用できそうです。発売前の市場調査などを目的としたアンケートフォームなどでの情報流出を防ぐ目的でも使えそうです。

プランセスでは、サンプルページ集も準備しています。


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

« 2007年11月 | トップページ | 2008年1月 »