« 2006年9月 | トップページ | 2006年11月 »

2006/10/31

IE7とJavaScript(window.close()メソッドと確認メッセージ)



Yahoo! BB 8M ずーっと2,180円キャンペーン

IE7で、JavaScriptの挙動が変わったものとして、昨日はpromptメソッドについて取り上げましたが、今日はwindow.close()に関する話です。IE7では、ボタンクリックなどユーザーアクションに基づくものであったとしても、window.close()メソッドによってウィンドウを閉じようとすると、確認メッセージが表示されます。そのため、

のような何の変哲もないスクリプトでも、
のような感じで、確認メッセージが表示されます。

その閉じようとしているウィンドウに親ウィンドウが存在しない場合、「window.opener=self;」を入れなければ、確認メッセージが表示されることは、IE6 SP2でもありましたが、IE7では、さらにセキュリティが強化されたわけです。セキュリティ強化のためにユーザーには安全にはなっているのでしょうが、ウェブマスター・プログラマーには頭痛のタネでもありますね。

ユーザーにウィンドウ右の「×」マークをクリックして閉じてもらってもいいけれど、ユーザーに便利なようにとページ内に設置した「ウィンドウを閉じるためのリンク・ボタン」をクリックしたら、「ウィンドウは、表示中の Web ページにより閉じられようとしています。このウィンドウを閉じますか?」と聞かれたら、「このサイト、なんか、やばいことやってくれていないよな?」と心配になる一般ユーザーが出てきても不思議ではありませんから・・・。とほほな問い合わせに悩まされる日々が続くかもです。

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

2006/10/30

IE7とJavaScript(promtメソッドとセキュリティ)



Yahoo! BB 8M ずーっと2,180円キャンペーン

IE7で、JavaScriptの挙動が変わったものとして、promptメソッドがあります。IE7では、ボタンクリックなどユーザーアクションに基づくものであったとしても、promptメソッドによってユーザー入力欄を表示させようとすると、いつもの「情報バー」が表示されます。そして、「この Web サイトはスクリプト化されたウィンドウを使用して情報を依頼しています。この Web サイトを信頼している場合、ここをクリックして、スクリプト化されたウィンドウを許可してください」というメッセージが表示されます。



のような感じです。そのため、IE7では、よくあるpromptメソッドのサンプルコード(「パスワードをJavaScriptにそのまま書くのはどないやねん? せめて、難読化するべきだろう?」という疑問はとりあえずおいておいて・・・。):

が期待どおりの動作をしません。ブロックされるだけならまだしも、入力されたパスワードが何もないままブロックされるものの、JavaScriptは実行されるために、「パスワードが異なります。」というアラートが表示されることになります。

情報バーの「情報バーにお気づきですか?」といういつものやつを「閉じるボタン」クリックで消すと、「パスワードが異なります。」というアラートが表示されていることに気づくでしょう。

ですから、
1.ユーザーが入力した結果、パスワードが異なる場合
2.「キャンセルボタン」をクリックしたために、「null」しかかえってこずに「パスワードが異なる」結果になっているのか
3.IE7を使っているがゆえに、最初の一回目は問答無用で「null」がリターンされているがゆえに、「パスワードが異なる」結果になっているのか

を区別しなければ、IE7ユーザーの方は、「パスワードが異なります」と言われても、入力欄さえ表示されていないじゃないか、と憤慨する結果になります。

そこで、上の例をIE7でも自然な?形で動くようにするのであれば、かつ、「2」と「3」の区別がつくよいうにするのであれば、

のような感じにしなければならないでしょう。もしくは、nullが返ってきたら、「何もアラートを表示しない」というのも手でしょうが、「IE7の情報バー」もすでに想定済みであることをユーザーに伝えられた方がユーザーに安心感を与えられるかもしれませんし、自己満足かもしれませんが、何だかカッコよくありませんか?

なお、ここでは、IE7であるかどうかを確認するために、「XMLHttpRequest()メソッドをサポートしているか」をチェックしています(参照:「IE7とAjax」)。SafariやFirefoxがユーザーーエージェントを偽装している場合には、上のスクリプトでは、「ie7=true;」となってしまうため、その点はいまいちですが、IE6やIE5がIE7と判定されることはありえないため、まあまあとも言えるでしょう。

続きを読む "IE7とJavaScript(promtメソッドとセキュリティ)"

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

IE7とAjax



Bフレッツ3ヶ月無料! JRのプロバイダ【サイバーステーション】

IE7の新機能には、他にも、XMLHttpRequest()メソッドのサポートが挙げられます。Ajaxで必ず出てくるものです。ただ、Windows版IE6やIE5でも、ActiveXを利用して可能でしたし、IE7でActiveX方式がサポートされなくなったわけでもありませんから、今までのJavaScriptのまま変更しなくても基本的には、大丈夫です。たとえば、よく見かけるAjaxのサンプルは以下のようなものでしょう。クリックするとsample.txt(UTF-8でエンコードされたファイル)の中身を読み込むというものです。



続きを読む "IE7とAjax"

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

IE7のセキュリティ機能/ フィッシングサイト対策



Bフレッツ3ヶ月無料! JRのプロバイダ【サイバーステーション】

今、本物そっくりのサイトを作って、クレジットカード番号やパスワードなどを詐取する詐欺が増えつつあり、問題になっています。フィッシング詐欺です。

IE7では、このフィッシングサイト対策が進んでいて、フィッシングサイトとしてデータベースに登録されているサイトにアクセスすると、


のような表示がなされて、アクセスがブロックされます。

ページタイトルが、「報告されているフィッシング Web サイト: ナビゲーションはブロックされました」となり、URL欄の背景色も変わります。「これは報告されているフィッシング Web サイトです」と大きな字で表示されますから、間違えのないぐらい分かりやすく、教えてくれます。

エラーメッセージがわかりにくくて困ることの少なくないマイクロソフト社製品ですが、IE7のそれはとてもわかりやすいです。

もちろん、フィッシングサイトに誘導される可能性がある場合というのは、ほとんどは、メール経由(eBayやpaypal関連が多いですね。また、今のところほとんど英文メール。)のはずであり、不審なメールはクリックしないことが、まず第一のセキュリティのはずですが、仮にクリックしたとしても、IE7なら安心という訳ですから、この機能は良いですね。Firefox 2.0にも同様の機能がありますが、ぱっと試した限りでは、IE7のフィッシング対策の方がわかりやすいです。

ただし、「IE7(やFirefox 2.0)がフィッシングサイトと判定しないからここは大丈夫」とおかしな判断をすると、ひどい目にあう可能性がありますので、ご注意を。


問合わせには迅速に回答します。詳しくは、WEBで!!

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

2006/10/28

Vista RC1体験/ IE7のセキュリティ機能



PHP+PostgreSQL/MySQLで大規模サイトの運営が可能です!!

昨日の記事「Vista RC1体験/ IE7の保護モード」に引き続き、IE7のセキュリティ機能について書きたいと思います。VistaのIE7(以下、「IE7 on Vista」)は、XP SP2上のIE6(以下、「IE 6 on XP SP2」)のセキュリティ設定を受け継ぎ、さらに進化(ある意味、制約が多くなって、鬱陶しく感じることも多くなっています。)させた形になっています。

1.「セキュリティ保護のため、このサイトによる、このコンピュータへのファイルのダウンロードがInternet Explorer で制限されています。オプションを表示するには、ここをクリックしてください。」

ダウンロード画面などで、直接的なユーザーアクションに基づかないで、実行ファイルなどがダウンロードされる場合、上のような表示がブラウザのコンテンツ表示領域のトップに表示されます。「IE6 on SP2」でもこのメッセージが表示されていましたが、「IE7 on Vista」も同様です。

2.「イントラネット設定は既定でオフになりました。イントラネット設定はインターネット設定よりも低いセキュリティ設定です。オプションを表示するには、ここをクリックしてください・・」


「http://localhost」へのアクセスの場合、「IE7 on Vista」では、このような表示がなされます。「IE6 on XP SP2」では、このような表示はありませんでした。ただし、「IE7 on XP SP2」では、同様の表示がなされます。

続きを読む "Vista RC1体験/ IE7のセキュリティ機能"

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

2006/10/27

Vista RC1体験/ IE7の保護モード



イングリッシュアドベンチャー

昨日、「Boot CampでVista RC1体験「MacでGyao」の裏技?)」を書きましたが、その続編です。その後、Acronis True Imageを使ってWindows XPのパーティションを分割して、Vista RC1を入れてみました。Mac miniにはVista RC2の英語版を入れ直しました。

True Imageを使ってのVistaのインストールは非常にスムーズでした。VistaとXPの共存で、XPが一時的に起動できなくなるのではないかという不安もありましたが、一切そういうことはありませんでした。電源を投入後、OSの選択画面(Windows ブートマネージャ)が表示されます。



「Microsoft Windows Vista」(デフォルト)と「Ealier Version of Windows」(つまりXP)が選択可能になっています。

Vista RC1上でWindows Internet Explorer 7(以下、「IE7 on Vista」)をいろいろ使ってみました。すると、XP SP2上のIE7(以下、「IE7 on XP」)は、「IE7 on Vista」とはかなり違うことが分かりました。「保護モード」という考え方が導入されて、セキュリティ機能が強化されているため、私が開発しているアプリケーションでひとつ動作しないものがでてきました。

セキュリティ上のゾーンの区別がはっきりとしていて、たとえば、インターネット上のコンテンツを表示しているウインドウ上(タブ上)に、ローカルファイルをドラッグ&ドロップさせますと、



と表示されます。(SEO的な観点でこの画像のメッセージを文字にしますと、)「この Web ページを開くために、 Internet Explorer で新しいウィンドウを開く必要があります。お使いのコンピュータのセキュリティのため、違うゾーンの Webサイトは別のウィンドウで開く必要があります。」と表示されました。

続きを読む "Vista RC1体験/ IE7の保護モード"

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

2006/10/26

Boot CampでVista RC1体験「MacでGyao」の裏技?)



ホスティングのウェブキーパーズ

ついにMac miniを買いました。「妻に捧げる「Intel Mac (Mac mini)を買いたい5つの理由」」を9月のはじめに書いて、1か月少しして、ついに妻の許しが出て購入したのでした。あらかじめネット上でいろいろ調べていて、標準の512MBのメモリーでは足りなそうなので、1GBにしました。これは大正解でした。

早速、Boot Campを入れてみました。最初、XPの英語版を入れようと思っていましたが、ちょうど本屋に寄った際に、Windows Vista World(月刊ウィンドウズ・サーバ・ワールド編集。VISTA RC1 DVD収録)という本が目に入って、買っていたので、Vistaを入れることにしました。

すると、あまりにもスムーズにインストールできました。また、さくさく動きました。メモリー1GBでMac miniを購入して大正解でした。実は、Mac miniにインストールする前に、XP Professional(メモリー1GB)の端末に「Virtual PC 2007」を入れて、Vistaをインストールしたのですが、重いの何のって。ホストOSであるXPを使いながらVistaを使えるのはいいのですが、メモリーもその分、シェアする形になるため、1GBをフルに使えません。640MBのメモリーをVista用に割り当てるようにしましたが、RC1のVistaのエディションは Vista Ultimateなので、640MBのメモリーでは足りないようです。その後、VMWare Serverにインストールしてみましたが、動作はいくぶん軽くなったものの、ネットにつながりませんでした。

ですから、Mac mini(+Boot Camp)で成功したときには、意外でしたが、助かりました。1GBのメモリーをフルに活用するからよかったのかもしれませんが、それにしても軽快な動作です。後でXPの端末(CPU 2.53Ghz、メモリー1GB)のパーティションを分割してVistaを入れてみましたが、それよりも軽快に動作しています。

また、Mac miniにインストールする際に心配していたドライバー関連も、問題がありませんでした。むしろ、Boot Campインストール時に作成した「Mac Drivers for XP」のCD-Rでドライバーをインストールしようとすると、フリーズしてしまったぐらいで(VistaとXPじゃ当然違うから?)、ドライバー類の追加はまったく不要でした。Vistaのデバイスマネージャー(なかなか場所を覚えられない。もっと簡単に表示できそうだけれど、一応私が覚えたのは、「コンピュータ」(もはや、「マイ コンピュータ」ではない。)を選択→右クリックでエクスプローラを表示→Cドライブを選択→システムのプロパティ→デバイスマネージャー)で確かめてみると、びっくりマークがいくつかついているものの、動作上の不備は特に感じていません。

さて、Vistaが簡単にインストールできたことから、まず、ウイルス対策ソフトを入れることにしました。いろいろ検索した結果、使いなれたウイルスバスターの英語版「PC-cillin™ Internet Security 14.56」の評価版が12月末まで使えると分かりましたので、それを入れました。

MacでGyaoを見る」というのは、私には切実な要望ではないのですが、これも問題なくできました。Windows Media Player 11 beta版が軽快に動いてます。私の場合、Vista RC1をWindows Vista World(月刊ウィンドウズ・サーバ・ワールド編集。1,100円)を購入して入れましたのでタダではありませんでしたが、実際RC1は無料でネット上で入手可能ですから、光ファイバーやADSLをご利用なら、実質無料で、Mac MiniにVistaを入れて、Gyaoを見ることができますね。ただ、絶対に成功するとは約束できないので、各人の責任でやっていただく必要がありますが・・・。

Boot CampでVistaとTigerを共存させる時に少しだけ不便なのが、起動時です。Tigerで起動した際には、起動ディスクの選択でVistaを選択すれば、Vistaを起動できますが、その逆はできません。Vistaで起動して、次に、Tigerを起動させようと思えば、一旦、Windowsを終了させる必要があります。その後、電源投入後、(Mac用キーボードの)optionキーを押しながら、起動ディスクの選択画面を出さなくてはなりません。普通に電源を入れるだけだと、私の環境では少なくともVistaの方が起動しますから・・・。

Apple Store(Japan)

新しいMac mini。Intel Core Duoをついに搭載。

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

2006/10/23

アンカーリンクとMac版IE(ページ内移動でも、onLoadイベントが発生してしまう件



ホスティングのウェブキーパーズ

ページにリンクする際に、アンカー(#hogehoge)を設定して、ページ内の任意のリンク先にジャンプさせたい場合があります。もちろん<a href="test.html#hogehoge">test.htmlの#hogehogeにリンク</a>とリンクを最初から設定すれば問題ありませんが、サーチエンジン経由のアクセスなどの場合はそうはいきません。サーチエンジンにはtest.html#hogehogeではなく、test.htmlがインデックスされるからです。

そこで、一度ページを読み込み後、JavaScriptで飛ばしたいところに自動的にジャンプさせることを考えたとします。onloadイベント時にlocation.href="#hogehoge";で良さそうです。簡単です。でも、これを単純に実装すると、

Mac版IEでは無限ループになります。

Mac版IEでは、「test.htmlにアクセス→onloadイベントが発生。(1回目)→test.html#jumpにジャンプ→onloadイベントが発生。(2回目)→test.html#jumpにジャンプ→onloadイベントが発生。(3回目)→test.html#jumpにジャンプ・・・」と永遠に続きます。

そこで、無限ループを避けるために、location.hashをチェックすることにします。

のようにします。Mac版IEではonloadイベントが計2回発生することになりますが、3回目はありませんので、無限ループは回避できます。

これを少し改造して、Mac版IEのバグがわかりやすいようにしたサンプルをこちらに準備しました。Mac版IE以外のブラウザでは、最終的にはhash.html#jumpに飛ぶはずですが、Mac版IEでは#hash2.htmlに飛び、「Mac版IEですね」とのアラートが表示されるようにしています。さすがに、無限ループ・永遠リロードのサンプルをサーバにアップする訳にもいかないので、このサンプルでは、ループは3回で止まるようにしてあります。



日経コンピュータ

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

2006/10/16

Jedit XにみるMac OSXにける半角円マークと半角バックスラッシュ問題



10GB大容量+データベース(PostgreSQL/MySQL)で本格ECサイト!!

「Macで入力した半角円マーク/半角バックスラッシュは、Windowsブラウザでどのように見えるか?」を本日は書きたいと思っていましたが、その前段階として、Macの定番テキストエディターの一つ、「Jedit X」について書きたいと思います。その中で、Macが潜在的に抱える、半角円マーク問題・半角バックスラッシュ問題の一端に触れることができると思うからです。

Jedit Xは、秀丸エディタ・ライクなテキストエディターであり、Windowsをメインに使っているユーザーにも使いやすいはずです。私も愛用しています。

しかし、このテキストエディターの「初期設定」は、少なくともプログラマーには優しくないです。しかも、生半可な知識?で、「Macでなら、バックスラッシュと半角円マークを区別して入力できる。やった!! これで、プログラムのエスケープ文字に半角円マークのような資本主義的な記号を書かなくて済む!!」と喜んだら、最後。私と同じように、はまります。

下記のような、これ以上簡単にできないようなJavaScriptが動かないということになります。



Jedit X(初期設定)で入力した半角円マークは、デフォルトのエンコーディングである「日本語(Mac OS)」において0x5Cであり、Jedit X上で入力した半角バックスラッシュ(「Option」キーを押しながら、「半角円マークが刻印されたキー」で入力。)は0x80になります。なぜ、このような仕様になっているのか、まずはJedit Xのマニュアルから見てみましょう。



● Jedit Xマニュアル(PDF)
http://www02.matsumoto.co.jp/product/Jedit5/JeditXManual_J.pdf
このマニュアルの25ページに「Shift-JIS系の日本語(Mac OS)ではバックスラッシュに0x80が割当て られてしまいます。しかし0x80のバックスラッシュは日本語(Mac OS)独自の方式で、一般的にはバックスラッシュには0x5cを割り当てることが多くプログラムのソースリストなどでバックスラッシュに0x80を割り当ててしまうとエラーになる」ため、設定画面の「Shift-JIS系エンコーディングの半角円マークをバックスラッシュとして扱う」のチェックボックスにチェックを入れるようにマニュアルにはあります。



● Jedit 4のユーザーへ(PDF)
http://www.artman21.net/product/JeditX/ToJedit4User.pdf
の4ページにも同様なことが書かれています。

ここで思い浮かぶ疑問は、なぜ最初から、「Shift-JIS系エンコーディングの半角円マークをバックスラッシュとして扱う」(便宜上、以降「設定B」と呼びます。現在の仕様の初期設定を「設定A」と呼びます。)ようにしてくれないかということです。初期設定がプログラマー向けでないのです。

続きを読む "Jedit XにみるMac OSXにける半角円マークと半角バックスラッシュ問題"

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

2006/10/14

TigerユーザーのOS10.4.8移行度は75%超え(FlashによるOS判別)



抜群の検定試験合格率! 日本語教師を育てる実績のプログラム

このブログの中で何回か、ちらっと触れましたが、Flashを利用することによりOSの判定がより正確・精密になります。ユーザーエージェントの偽装を見破ることができますし(Mac版ブラウザがWindows版ブラウザのふりをすることはできなくなります。)、Safariでしか分からなかったOSの細かいバージョン(参照:「SafariのユーザーエージェントからMacOSのバージョンを調べる方法」)が、Mac版FirefoxやIEを使っている場合でも分かるようになります。

FlashのActionScriptの中で、

System.capabilities.os
を調べることにより、分かります。

あるサイトで調べてみたところ、この6日間で、下記のようになりました。
Mac OS 10.4.8
 419(76.73%)
Mac OS 10.4.7
 84(15.38%)
Mac OS 10.4.4
 17(3.11%)
Mac OS 10.4.6
 16(2.93%)
Mac OS 10.4.0
 5(0.91%)
Mac OS 10.4.2
 4(0.73%)
Mac OS 10.4.3
 1(0.18%)

サンプル数が少ないのでいまいちですが、9月30日にリリースされた10.4.8への移行度は75%を超えているようです。Macの場合も、Windows Updateのように、定期的にソフトウェア・アップデートが実行され、パッチの適用を促されますので、この「高い確率」も当然と言えば当然かもしれませんが、逆に言えば、15%もの人がそのパッチの適用を留保していることを意味します。そういう意味で、私は驚きました。

続きを読む "TigerユーザーのOS10.4.8移行度は75%超え(FlashによるOS判別)"

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

2006/10/13

Windowsで入力した半角円マークは、Macブラウザでどのように見えるか?



「ヒアリングマラソン中級コース」新開講受付中!

半角円マークと半角バックスラッシュをめぐるMac版ブラウザの混乱ぶりの原因はどこにあるのか、自分なりにまとめてみたいと思います。なお、とても複雑な問題なので、私の勘違いや書き間違いがあるかもしれません。その場合は、どなたか、コメントをください。

まず、Windows端末(日本語キーボード)で半角円マークが刻印されたキーを入力し、メモ帳や秀丸エディターで保存した場合に、Macブラウザでどのように表示されるかを検証してみました。話が複雑になりますので、まずはShift_JISで保存したファイルについて検証してみました。

たとえば、「筆まめ Ver.17 アップグレード・乗り換え専用(DVD-ROM版)\3,472(2006年10月13日現在)」と書いた半角円マークがバックスラッシュで表示されていると、かなりがっかりですので、何とか半角円マークをすべてのブラウザで表示させたいと考えているケースだとします。

「赤字は予想外で、注意が必要」と筆者が感じたものです。Windowsで入力した半角円マークは当然Windowsブラウザでは、半角円マークで表示されるべきだと思いましたが、Windows版Operaは違いました。また、英数字用フォント(「Arial」など)を指定すれば、Windows用ブラウザでもすべてのブラウザでバックスラッシュが表示可能と思っていましたが、Netscapeだけは違ったようです。

また、Windowsで入力した半角円マークは0x5cですので、charcodeを基準に考えれば、Macでは半角バックスラッシュが表示されるのが正しいと言えるでしょうが、Windowsとの互換性を重視した(or 見た目を重視した)ブラウザの中には、半角円マークを表示するブラウザが存在します。

1.普通に半角円マークのキーを入力
Windows IE6・Firefox 1.5.0.7・Netscape 7.1
Opera 9.02
Mac IE 5.23・Netscape 7.1
Safari 2.04・Firefox 1.5.0.7・Opera 9.02・Camino 1.03・iCab 3.03

OperaではWindows版であっても、バックスラッシュとして表示されます。Windows版Operaで半角円マークを表示するには、後述する「4.」もしくは「5.」の方法を取る必要があります。


2.半角円マークのキーで入力した文字を、フォント設定で「Arial」を指定して、バックスラッシュに見せた(つもりでいる)場合
Windows Netscape 7.1
IE6・Firefox 1.5.0.7・Opera 9.02
Mac IE 5.23・Netscape 7.1
Safari 2.04・Firefox 1.5.0.7・Opera 9.02・Camino 1.03・iCab 3.03

Macでは、フォントを指定していない場合(「1.」のケース)と同じ結果になるのは当然として、Windows版Netscape 7.1ではなぜかフォント設定が無視されているのか、半角円マークが表示されてしまいます。


3.数値参照文字で92番の入力(&#92;)
Windows IE6・Firefox 1.5.0.7・Netscape 7.1
Opera 9.02
Mac IE 5.23・Netscape 7.1
Safari 2.04・Firefox 1.5.0.7・Opera 9.02・Camino 1.03・iCab 3.03

つまり、「1.」と全く同じです。

続きを読む "Windowsで入力した半角円マークは、Macブラウザでどのように見えるか?"

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

JavaScript難読化のためのヒント

AJAX時代の今、JavaScriptが再び脚光を浴び始めていますが、JavaScriptはローカルで実行されるもののため、ソースが基本的に丸見えになってしまう欠点があります。PHPやPerlなどサーバサイドで実行されるものの場合、そのような危険性は基本的にはありません(共有サーバなどでセキュリティ設定がいい加減な場合や、クライアントに納品するソースコードなどを除く)。

そこで、JavaScriptを真似されないように、できるだけ分かりにくくさせたいという希望がうまれてくるのですが、その具体的なノウハウについて、いくつかまとめてみました。

● JavaScript難読化のためのヒント
http://www.broadband-xp.com/obfuscation/

改行やタブ・コメント・半角スペースの削除という基本的な方法だけでも、かなり読みにくくなるはずですが、それをお手軽に実行するための、「テキストエディタを使った正規表現による置換方法」などについても解説しています。

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

2006/10/12

Firefoxとテキストエリアの限界(続編)



☆No.1ADSLプロバイダー!Yahoo! BBのお申し込みはこちら☆

昨日書いた記事:
● Mac版Firefox 1.5.0.7及びNetscape 7.1のテキストエリアの限界(半角英数字が4,682文字以上連続すると、文字が消える。)
http://shimax.cocolog-nifty.com/search/2006/10/macfirefoxnetsc_5b68.html

について追記があります。テキストエリア内に、「半角スペースなし」「改行なし」で半角英数字が4,682文字以上連続すると、Mac版Firefox(1.5.0.7でだけテストしていました。)やNetscape 7.1では、テキストが消えるという内容の記事についてです。

今朝になって気になって、さらに調べてみましたら、Mac版のFirefox 2.0(RC1/RC2)や1.0.6(1.0.4)では、異なる結果になりました。また、問題がないと感じていたWindows版のFirefoxでも37,444文字もしくは37,445文字の半角英数字が連続すると、問題が発生しました。一覧にしますと、下記のようになります。37,455は4,682の約8倍(7.9997倍)、何か関係がありそうな気もします。

ブラウザ textareatableのtdタグ内
Mac版Firefox 1.5.0.7
(1.5.0.3)
4,682文字以上になるとテキストが消えます。4,199文字以上になるとテキストが消えます。
Mac版Firefox 1.0.6
(1.0.4)
4,682文字以上になるとテキストが消えます。4,438文字以上になるとテキストが消えます。1.5.0.xになって退化したことを意味するのかもしれません。
Mac版Firefox 2.0(RC1/RC2)9,363文字以上になるとテキストが重なって表示されます。9,363という数字は4,682の約2倍であり(1.5.0.xは4,681文字まではOKで、2.0は9,362文字まではOKと考えれば、ぴったり2倍の進化。)、Firefox 2.0は文字通り進化していると言えます。10万文字の連続した英数字でも問題は発生しませんでした。それ以上はテストしていません。
Windows版Firefox 1.5.0.737,445文字以上になるとテキストが消えます(XP)。Windows 2000にインストールしたものでは、半角英数字9,363文字以上で、テキストの重なりが発生しました。また、Windows2000のFirefoxでは、5万字を超えるとフリーズしたりしました。この違いが端末特有のものなのかOSに起因するのかは不明。10万文字の連続した英数字でも問題は発生しませんでした。それ以上はテストしていません。
Windows版Firefox 1.0.137,444文字以上になるとテキストが消えます(XP)。Windows 2000にインストールしたものでは、半角英数字9,363文字以上で、テキストの重なりが発生しました。この違いが端末特有のものなのかOSに起因するのかは不明。10万文字の連続した英数字でも問題は発生しませんでした。それ以上はテストしていません。
Windows版Netscape 7.137,444文字以上になるとテキストが消えます(XP)。Windows 2000にインストールしたものでは、半角英数字9,363文字以上で、テキストの重なりが発生しました。10万文字の連続した英数字でも問題は発生しませんでした。それ以上はテストしていません。
Windows版Firefox 2.0(RC1/RC2)10万字までテストしましたが、不具合は発生しませんでした。10万文字の連続した英数字でも問題は発生しませんでした。それ以上はテストしていません。


●(テストページ)Mac版Firefox 2.0のテキストエリアの限界(半角英数字が9,363文字以上連続すると、文字が重なって表示されます。)
http://www.shtml.jp/blog/mac_firefox20_textarea.html

いずれにしましても、来たるべきFirefox 2.0では、Windows版でもMac版でも進化していることは確かなようです。2.0の正式リリースが待たれます。



【ウィルスチェック標準】NTTスマートコネクトのレンタルサーバ

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

2006/10/11

Mac版Firefox 1.5.0.7及びNetscape 7.1のテキストエリアの限界(半角英数字が4,682文字以上連続すると、文字が消える!!)



日本hpのオンラインストア「hp directplus」

最近、「HTMLソースを隠す方法」の続編として、JavaScript難読化についてのホームページをまとめていました。

その中で、半角スペース・改行などを取り除いて、難読化させたソースをサンプルとして表示させようと、テキストエリア内に表示させようとするのですが、奇妙な現象に悩まされることになりました。

textarea内で「wrap=soft」としても見た目が改行されないのは理解できましたが、そうではなくて、Mac版Firefox1.5.0.7とNetscape 7.1、Camino(つまりMacのMozilla系ブラウザ。)で、テキストエリア内のソースが全く表示されない現象に出会ったのです。それも、テキストエリア内に表示させているソースは何ページもあるのですが、そのうちの数ページのみ、そのような現象が発生したのです。全部のページで発生したわけではなかったのです。

調べてみると、次のような事実が分かりました。

  • Windows版FirefoxやNetscape 7.1では全くこの現象は発生しない。( 詳しく調べてみると、後で、Windows版でも発生することが分かりました。参照:「Firefoxとテキストエリアの限界(続編)

  • この現象が発生するのは、テキストエリア内の文字数が多い場合である。
  • ためしに、適当な個所で1個所でも改行を入れてみると、ちゃんと表示されます。
そこで、「『改行なし』『スペースなし』で、一定の文字数以上になると、表示されなくなるのではないか」とアタリをつけて、調べてみると、4681文字と4682文字がその境目であることが分かりました。

 Windows版FirefoxやNetscape 7.1でも実は文字数の限界があるかもしれないと思って、2万字(20,000バイト。半角スペース・改行なし。)程度まで調べてみましたが、とりあえず2万字程度では不具合は発生しませんでした。)→2006年10月12日午後15時頃追記: たしかに2万字では不具合は発生しない(XP)のですが、37,445文字以上でWindows版Firefoxでも発生することが分かりました。参照:「Firefoxとテキストエリアの限界(続編)

4,681文字というのは、何とも中途半端な数字だとは思いましたが、テキストエリア内の文字を別のものに変えても、この4,681文字まではOKで、4,682文字以上になると、文字が消えてしまう(消えたように見える)ことが分かりました。

JavaScriptで本当に消えてしまっているのか調べてみてみたら、消えたように見えるだけで、実際は存在していることが分かりました。何とも奇妙な話ですが、そのようになりました。

●(テストページ)Mac版Firefox 1.5.0.7及びNetscape 7.1のテキストエリアの限界
http://www.shtml.jp/blog/mac_firefox_textarea.html

がそのテストページです。

仕方がないので、テキストエリア内に難読化したソースを表示させるのではなくて、table内で表示させたらどうだろうかと考えてみたのですが、なんと、table内では、さらに少ない文字数で、Mac版FirefoxやNetscapeで不具合が発生したのです。

●(テストページ)Mac版Firefox 1.5.0.7及びNetscape 7.1のtableの限界(半角英数字が4,199文字以上連続すると、文字が消えます。)
http://www.shtml.jp/blog/mac_firefox_table.html

4,198文字までならOKですが、4,199文字以上ならアウトでした。半角スペースや半角改行、全角文字が途中で入っていれば問題は起きません。Windows版FirefoxやNetscapeでは問題になりません。Mac版でのみ発生します。

仕方がないので、該当するブラウザの場合は、途中で改行して表示させ、「本当は一行なんだよ」という注意書きを出すことにしました。もっと良い解決策があればなと思っていますが、まだ分かっていません。

※2006年10月12日15時頃追記: Mac版Firefoxでも、次世代の2.0 RC1やRC2では、完全でないものの、いくぶん、この不具合は改善されています。(参照:「Firefoxとテキストエリアの限界(続編)



【格安パソコンなら!ソーテックオンラインショップ!】

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

2006/10/05

Macブラウザと半角円マーク/半角バックスラッシュ(EUC-JP編)

昨日掲載した、「Macブラウザと半角円マーク/半角バックスラッシュ(Shift_JIS編)」は、その名のとおり、Shift_JISでエンコードされたホームページ上での話でした。今日は続編であり、EUC-JPでエンコードされたホームページ上の話をします。

EUC-JPでエンコードされたホームページ上で、Macブラウザ各種で半角円マーク及び、半角バックスラッシュ(「optionキー」+「半角円マーク」が刻印されたキーの入力で入力される文字)が、JavaScriptのcharCodeAt()では何番のcharcdoeを返すのか、また、POSTあるいはGETされた時にどのようにURLエンコードされるかをまとめたものです。

OSの内部処理的にMacが半角円マークと半角バックスラッシュを区別して考えていることは、それはそれで優れた仕様かもしれませんが、Windowsとの互換性を考えるならば、URLエンコード時には、「%5C」としてエンコードしなければ確実にトラブルの元になります。「%5C」以外にURLエンコードするものについては、背景色をグレーにして分かりやすくしました。

半角円マークを入力したときに問題が起こるのか、半角バックスラッシュ入力時に問題が発生するのかはブラウザによって異なることが、この一覧表で読もとっていただけると思います。


【PR】 ★日立ダイレクト、キャンペーン実施中!

続きを読む "Macブラウザと半角円マーク/半角バックスラッシュ(EUC-JP編)"

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

2006/10/04

Mac版Operaと半角円マーク



企業で導入するIT製品選びをサポート【キーマンズネット】

Mac版Operaは、ユーザーシェアの観点から言うと、率直に言って、無視してもほとんど問題にならないぐらいです(私のサイトで約0.01%。1万人に1人です)。ただ、Mac版ブラウザ全体・MacというOSが抱える問題にハイライトを当てる意味では、これから説明する問題は好材料だと思います。

●Macブラウザと半角円マーク/半角バックスラッシュ(Shift_JIS編)
http://shimax.cocolog-nifty.com/search/2006/10/macshift_jis_927b.html

でも予告しましたように、Mac版Operaでは、半角円マークが「&#165;」に文字化け する現象が(Shift_JISのページだけでなく、EUC-JPのページでも)発生します。ここで、「文字化け」をイタリックにしたのには意味があります。Operaの開発者はこれは「文字化けでない。MacOSの仕様に忠実に沿った仕様である」と考えているかもしれないからです。

実際、「&#165;」は数値文字参照型ではありますが、「¥」のように半角円マークらしきものが表示されます。ただ、この半角円マーク、Windowsで見ると、いつもの円マーク「\」とは微妙に異なるように見えます。円マークのVの部分が違うというか・・・。拡大してみますと、



のようになります。たしかにデザインは異なります。

実際、Windowsで普通に入力した半角円マークのcharcodeは92ですが、「&#165;」で表示された半角円マークのcharcodeは165ですから、異なります。ただ、そうは言っても、「文字化け」というのは言い過ぎかもしれません。「&#165;」を$マークや韓国ウォンと見間違う可能性はゼロですし、「Safariが半角バックスラッシュを勝手に全角バックスラッシュに変換してしまう不具合を抱えている点」と比べれば何でもないことなのかもしれません。

しかしながら、例えば、PHPでプログラミングをしているサイトで、セキュリティ対策のためにhtmlspecialchars関数を使っている場合、数値参照文字たる「&#165;」は「&amp;#165;」に変換されてしまうため、掲示板などのWEBアプリケーションにおいて、「&#165;」がそのまま表示されてしまいます。半角円マークでも、半角円マーク第2号(charcodeが92ではなく165番であるという意味で。)でもなく、「&」「#」「1」「6」「5」「;」という6文字から成る文字列です。これは、誰が何と言おうと、明らかに文字化けです。

Mac版Operaの開発者は、自分たちの責任ではなく、そのような掲示板を作っているプログラマーの責任であると思うかもしれませんが・・・、です。

確かに、PHPプログラマーが安易にhtmlspecialchars関数を使うのではなくて、手動で「<」「>」「"」のみを変換するようにすればいいのかもしれません。あるいは、htmlspecialchars実施後、もう一度「&amp;」を「&」に変換させるような処理をすべきなのかもしれません。実際、PHPのhtmlspecialcharsに関するマニュアルページのディスカッション・コーナーでも、いくつかそういう書き込みが見受けられます。

しかし、私の無知なのでしょうが、私はhtmlspecialchars関数がなぜ「&」(アンバサンド)を変換対象にしているのかよく理解できていないので(「<」や「>」が危険であり、「"」をエンコードしなければ、プログラムがバグってしまうケースがあることも分かっています。)、正直、この「&amp;」を「&」に戻すやり方で、セキュリティ上良いのか分かりません。

むしろ、htmlspecialchars関数が「&」をわざわざ「&amp;」に変換しているのだから、(少なくとも特定のケースに置いては)何か意味があるはずであり、その意味をはっきり知るまでは、怖くて、こういうことができないですね。

Mac版Operaの開発者は、それは「あんたたちの事情でしょう。」と考えるかもしれませんが、私は、一覧表にも書きましたように、Mac版Firefoxの仕様が最高だと考えています。理想的な処理の最終的姿だと考えています。MacがOS内部で、半角円マークと半角バックスラッシュを区別しているのは良いですが、URLエンコード時にはどちらも%5Cにエンコードしてもらうのが一番だと考えています。

続きを読む "Mac版Operaと半角円マーク"

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

Macブラウザと半角円マーク/半角バックスラッシュ(Shift_JIS編)

Shift_JISでエンコードされたホームページ上で、Macブラウザ各種で半角円マーク及び、半角バックスラッシュ(「optionキー」+「半角円マーク」が刻印されたキーの入力で入力される文字)が、JavaScriptのcharCodeAt()では何番のcharcdoeを返すのか、また、POSTあるいはGETされた時にどのようにURLエンコードされるかをまとめたものです。

OSの内部処理的にMacが半角円マークと半角バックスラッシュを区別して考えていることは、それはそれで優れた仕様かもしれませんが、Windowsとの互換性を考えるならば、URLエンコード時には、「%5C」としてエンコードしなければ確実にトラブルの元になります。「%5C」以外にURLエンコードするものについては、背景色をグレーにして分かりやすくしました。

半角円マークを入力したときに問題が起こるのか、半角バックスラッシュ入力時に問題が発生するのかはブラウザによって異なることが、この一覧表で読もとっていただけると思います。

なお、この一覧はあくまでもShift_JISのページでのテスト結果であって、EUC-JPのページでは、また別の問題が発生します。

また、Opera(及び、Netscape 7.02)の半角円マークのエンコード方法の問題(URLエンコード時に%「%26%23165%3B」にエンコードしてしまうため、これをデコードすると「&#165;」になる問題)については後日、あらためて、記事にまとめるつもりです。
2006年10月4日午後20時39分追記    「Mac版Operaと半角円マーク」を公開しました。


【PR】 楽しいゲームがやれて、賞品までもらえちゃう! GOGOゲーム


続きを読む "Macブラウザと半角円マーク/半角バックスラッシュ(Shift_JIS編)"

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

2006/10/02

Macブラウザ(Safari/Mac版IE/Firefox/Opera)バグ情報など

このブログでMac版ブラウザについて書きためていたら、気が付いたら30本近くになっていることに気付きました。ここらで整理のために、リンク集形式でまとめてみました。

● Macブラウザ(Safari/Mac版IE/Firefox/Opera)バグ情報など
http://shimax.cocolog-nifty.com/mac_bug_ichiran.html

自分で言うのもなんですが、他のサイトではなかなか得られないような貴重な情報がいくつか混じっていると思います。(Mac版ブラウザのバグとして有名なものも多く混じっていますけれど。)



基本プレイ無料!エターナルカオス

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

Mac版IEで、おかしなところにリンクの分身(亡霊)が出現するケースについての考察



ポイントが貯まる♪お得で新しいソーシャルネットワーキングサービス!「COLORS」

先日、「ココログのアクセス解析サービスの遅延」について記事を書きましたが、遅延は収まっているようです。こちらでも遅延の報告・苦情が数件書き込まれていますが、結局、@nifty側からの報告は一切ないようです。「無かったことにしよう」作戦、風化作戦なのかもしれませんが、毎度のこととはいえ、その対応には決して満足できるものではないですね。

それはさておき、今日もMac版IEネタです。アクセスログを眺めていると、ビジターの方がどういうキーワードで検索して、自分のホームページにたどり着いたのか分かりますが、ある方が「Mac」「IE」「不具合」というキーワードで検索されていました。これ自体は珍しいことではなく、私のページでは、Mac版IEの不具合ネタが多いですから、驚きでも何でもないのですが、Yahoo!検索からのアクセスだったのです。

私は普段、Google検索しかほとんど使いませんので、今まで見たことのないページが多いことに気付きました。そんな中、とても興味深い不具合についての記事がありましたので、ご紹介します。

● K's Music Mac-IEリンクのナゾ
http://members.jcom.home.ne.jp/ks-mus/Asobi/nazo.html

センタリングしたり、右寄せしたリンクがある場合、亡霊とも言うべき「リンクの分身」が何もないところに出現し、テキストも画像も何もないところにリンクが見え、実際にその「リンクの分身」をクリックすれば、そのリンク先に飛んでしまうというものです。

これは、私も今まで気づきませんでした。ただ、テストしてみて、実際、このホームページの記述は100%正しいことが分かりました。また、いろいろなパターンのテストを繰り返す中で、いろいろなことが分かりました。詳細なテスト結果は、こちらに掲載しましたが、そのダイジェストをこの中で書きますと、

リンクをセンタリングした場合(Mac版IE):


リンクを右寄せした場合:(Mac版IE)


のようになります。それぞれの亡霊とも言うべき、「リンクの分身」の上にマウスのカーソルを合わせれば、リンク先のURLがステータス行に出現しますし、onmouseoverを設定していればそのようになります。またCSSでhoverが設定されていれば、Mac版IEでは分身のリンクであっても、リンクの色が変わったり、背景色も同時に代わります。エイリアスのような存在です。

エイリアスか分身か、亡霊か、呼び方はいろいろでしょうが、いずれにしても、本物のリンクの方が駄目になっているわけではなく、どちらも有効であることは重要な事実です。ですから、おかしなところにリンクが出現し、「またかよ、MacIE君」となるだけで、実害はほとんどないもしれません。

また、センタリングの方法として、tableのtdでalign=centerとされている場合も、<center>タグでセンタリングしている場合も差異は全くなく、リンクの左側に余白がある限り、「リンクの分身」は出現します。

亡霊が現れるのは常に画面もしくはtable内の左隅であり、その余白が十分にある場合に限られます。その余白が中途半端?な場合には、上の画面キャプチャーで言えば、「リンクA」及び「リンクD」だけが、「リンクの分身」を持つことになったり、「『リンクA』『リンクB』及び、『リンクD』『リンクE』は分身を持つが、『リンクC』及び『リンクF』はその分身を持たない」という状況もありえます(参照:「(テストページ)Mac版IEで、おかしなところにリンクの分身が出現する件」)。すべては余白がどれだけあるかにあるのです。

ですから、逆にいえば、Mac版IEのこの不具合の対策(Mac版IEを考慮した対策)は、上述の「K's Music Mac-IEリンクのナゾ」さんが書かれていますように、テキストリンクなどをセンタリングしたい場合は、そのリンクの左側に余白を作らない形でtableタグ(width設定なし)で囲ってしまう(多くの場合、tableが二重以上になります。)ことです。これで、この不具合は解消できます。

なお、このバグは、Mac版IEのバージョンに関係なく、すべてのバージョン(IE5.23/5.17/5.0でテスト。)で起こるようです。




話題の<Wooo、カラリオ>が当たる!モバイル版リニューアルキャンペーン!

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

« 2006年9月 | トップページ | 2006年11月 »