« 2006年10月 | トップページ | 2006年12月 »

2006/11/25

Yahoo! Japanのディレクトリーに掲載されました

このココログのブログを始めて約2年になりますが、これまで書きためた記事をまとめて、Yahoo! Japanに申請したところ、IE7ネタとMac版ブラウザ・ネタの2つのテーマで掲載されることになりました。

● IE7とJavaScript
http://shimax.cocolog-nifty.com/ie7/
Yahoo! Japanの「コンピュータとインターネット > インターネット > ブラウザ > Internet Explorer」に掲載されました。Beta2 Preview、Beta2、Beta3、RC1、正式版とずっとウォッチしてきた内容をまとめたものです。

●Macブラウザ・バグ情報
http://shimax.cocolog-nifty.com/mac_bug_ichiran.html
Yahoo! Japanの「コンピュータとインターネット > ソフトウェア > オペレーティングシステム > Mac OS > アプリケーションソフト」及び「コンピュータとインターネット > インターネット > ブラウザ」の二つに掲載されました。紹介文も私が申請した文章よりも具体的なものになっていて、嬉しいです。「Safari、Mac版IE、Firefox等の文字化けの原因、対象方法、JavaScriptのデバッグ方法。」となっていますので、Yahoo! Japanのディレクトリー検索で「Safari」や「Mac版IE」で検索すると当サイトがヒットします。早く、ロボット検索でも上位に入るようになってくれると、アクセスも増えていいのですが・・・。

Yahoo! Japanの検索がロボット検索がデフォルトになってから、何かと苦戦している私です。


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

2006/11/16

SafariとAjax文字化け



サポートが自慢の格安サーバ

Googleサジェスト--Safariで文字化け」という記事を書いたのは去年の三月でした。今は、この文字化けはGoogle側のプログラムにより修正されています。

しかし、本質的に、Safariが文字コードの認識能力に問題が起こることが多いのは事実です。特に問題になりやすいのは、メタタグを指定できず、またPHPやPerlなどによるHTTPヘッダーによる文字コード指定もできないファイルは文字化けしやすいです。具体的には、テキストファイルであり、Ajaxを使ってテキストファイルを読み込むときなどにこの問題が起こりやすいです。

たとえば、次のようなよくある「Ajax基本サンプル」を考えてみます。「IE7とAjax」でも取り上げたサンプルコードとほぼ同じです。sample.txt(UTF-8でエンコードされたファイル)を読み込みます。

この時、Safariでのみ、sample.txtの中の日本語が文字化けします。UTF-8の文字列なのに、ISO-8859-1としてとらえているかのような文字化け「あいうえお」(元の文字列は「あいうえお」)です。宇宙人の暗号かウルトラサインのような文字です。解決策はいくつかありますが、ここでは3つだけご紹介します。

1.解決策1: .htaccessを使います。
.htaccssを使って、
AddType "text/plain; charset=UTF-8" .txt

のようい書きます(参照:「ウェブマスターのための文字化け講座「メタタグによる文字コード指定の有効性」」)。.htaccessで拡張子ごとに文字コードを指定しておけば、WEBサーバの方で必要なHTTPヘッダーを出力してくれますので、Safariでも文字化けしません。

上の書き方だと、そのディレクトリー内の拡張子「.txt」のファイルは全てUTF-8と見なされるため問題がある場合もあるかもしれません。その場合は、Ajaxで読み込むファイルの拡張子は必ずしも「.txt」でなくてもいい場合も多いでしょうから、

AddType "text/plain; charset=UTF-8" .iso
のようにして、sample.isoを読み込ませる形にしてもいいでしょう。

続きを読む "SafariとAjax文字化け"

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

2006/11/14

Mac版IEとinnerHTML



フレッツADSL半年間 525円! JRのプロバイダ【サイバーステーション】

久しぶりのMac版IEネタである。なぜ、そんなことをする必要があるのかと聞かれると困るのですが、Mac版IEでのみ、下記のスクリプトは期待どおりには動作しません。

dr_macie.jsのソース

dr.htmlのソース

Mac版IEを除く主要ブラウザでは、全て、期待どおり、

かきくけこ
あいうえお

という出力になります。

しかし、Mac版IEでは、

かきくけこ
かきくけこ
あいうえお

になります。つまり、<script type="text/javascript" src="dr_macie.js"></script>が2回評価されてしまいます。
なぜこうなるかといいますと、Mac版IEだけでなく、Windows版IEやFirefox、Operaで、「document.getElementById("dr_a").innerHTML=document.getElementById("dr_b").innerHTML;」の部分を「alert(document.getElementById("dr_b").innerHTML);」にしてみるとよく分かります。

 アルファベットの大文字・小文字・ダブルクォートのあるなしも忠実にまとめてあります。
Windows版IE<SCRIPT src="dr_macie.js" type="text/javascript"></SCRIPT>かきくけこ<BR>
Windows版Firefox<script type="text/javascript" src="dr_macie.js"></script>かきくけこ<br>
Windows版Opera<SCRIPT type="text/javascript" src="dr_macie.js"></SCRIPT>かきくけこ<BR/>
Mac版IE<SCRIPT src=dr_macie.js type="text/javascript"></SCRIPT>かきくけこ<BR>
Safari<SCRIPT type="text/javascript" src="dr_macie.js"></SCRIPT>かきくけこ<BR>
Mac版Firefox<script type="text/javascript" src="dr_macie.js"></script>かきくけこ<br>


細かい違いはあるものの、どのブラウザもdocument.getElementById("dr_b").innerHTML;の結果はほぼ同じです。しかし、これを他のオブジェクトのinnerHTMLとして評価するように書くと、Mac版IEだけ、この<SCRIPT src=dr_macie.js type="text/javascript"></SCRIPT>を再実行しようとします。そのため、「かきくけこ<br>」が2回、document.writeされる結果になります。もちろん、document.writeだけでなく、alertでも同じです。たとえば、Mac版IEの場合、dr_macie.jsの中身が

のようにあった場合、最初の実行時にcountは定義されていないのでゼロになり、それがインクリメントされて「1」がalertされます。さらに、2回目の実行時では、今度はグローバル変数であるcountが定義済みのため、count=1;にインクリメントされる形となり、「2」がalertされる結果となります。そして、「かきくけこ<br>」が2回、document.writeされる結果になります。他のブラウザではこのようなことは起こりません。

「display:none;」というスタイルシートは、あくまでも表示に関するものですから、document.write以外のもの(ここではalert)は、最初のロード時に評価されます。しかし、その後、innerHTMLでコピーされるときには再実行されてはならないはずですが、Mac版IEだけ2回目を実行してしまいます。

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

2006/11/09

IE7と補助漢字(「森鴎外」と「森鷗外」)




繋   繫

前回、「秀丸エディタとEUC補助漢字(「繋がる」と「繫がる」)」で書きましたように、 IME2007(β版)で「つながる」を漢字変換すると、

左のように、二つの漢字候補が表示されます。それを拡大したものが上記の漢字です。片方の「繫がる」は「環境依存文字(Unicode)」と表示されます。このブログはUTF-8のため、問題なく、二つの漢字を表示することができます。

しかし、IME2003の場合、「環境依存文字(Unicode)」とか表示されませんので、ユーザーが意図せずに、補助漢字の方の「繫がる」を使ってしまう可能性があります。

<<補助漢字をサポートしているアプリケーションは、実際のところ少ない。>>
この補助漢字(JIS X 0212-1990)は、天下の秀丸エディタがver. 6.0になってやっとサポートするようになったことからも分かりますように、サポートしているアプリケーションは、現在のところ少ないです。

例えば、Firefoxではサポートしていますが、IEではIE7になってもサポートされていません。せっかく秀丸エディタでEUC-JPの補助漢字をサポートするようになっても、IEでは文字化けします。「繫がる」が「恕リがる」にIEでは文字化けします。明治の文豪・「森鷗外」は「森乗ス外」に文字化けします。

さらに、同じ秀丸でも、補助漢字をサポートしていないバージョンで開くと、文字化けします(文字化けの仕方はIEとは異なり、「xs擇・觴」といように、後続する平仮名・タグの一部を含む「全面文字化け」になります。)。

(全くの余談ですが、この「恕」の読みや意味がわからなかったので調べました。「ジョ」と読み、「相手の立場にたってゆるす、思いやりの心」という意味で、孔子様の言葉にあるようです。私は長い間、字の雰囲気・つくりが、「怒」に似ているので、悪い意味に捉えていました。お恥かしい。

お話を元に戻しますと、「恕」はEUC-JPで「0xBD FA」です。半角カタカナの「リ」は、「0x8E D8」です。一方、「繫」は「0x8F D4 DA」です。「乗」は「0xBE E8」、半角カタカナ他の「ス」は「0x8EBD」です。一方、「鷗」はEUC-JPの場合、「0x8F EC BF」です。前回の記事で書いたバイナリーエディタでのプレビュー文字化けと違って、その文字化けのアルゴリズムはよく、わからないですね。恐らく、いったんunicodeに内部的に変換されてから再びEUC-JPに変換される際の不具合ではないかと推測しているのですが・・・。いまいちよく分からないです。

いずれにしても、IE6及び最新版のIE7では文字化けします。また、Opera9.02()でも、右のように文字化けします。ダイヤの形の中に「?」が表示されます。補助漢字のバイトコードが処理不能な文字と認識しているのなら正しい処理と言えます。ところが、Firefoxは1.5xでも2.0、Netscape 7.1などMozilla系ブラウザでは、文字化けせずに、EUC-JPでも、「繫がる」(補助漢字)と「繋がる」の両方を区別できるようになっています。Safariでは、ページ全体がShift_JISのページであると誤判定されて文字化けしたものの、手動でエンコーディングを「EUC」に変更すれば、補助漢字の方の「繫がる」も文字化けせずに表示されました。

 Opera 9.5で補助漢字もサポートされるようになりました。

それでは、IE上のフォーム(EUC-JPでエンコードされていることが前提。)で補助漢字の「繫」をユーザーが入力した場合、どのようにURLエンコードされるのかといいますと、「%26%2332363%3B」になります。これを逆にURLデコードすると、「&#32363;」になります。つまり数値参照に変換されています。「&#32363; = 『繫』」です。

つまり、先月書いた記事「Mac版Operaと半角円マーク」でMac版Operaが半角円マークを「&#165;」として処理する問題で書いたのとよく似た現象が起こります。

▼ 想定される問題
  • FirefoxやNetscape 7.1でEUC-JPでエンコードされたページにアクセスし、フォーム上で入力した「繫」「森鷗外」は、仮にデータベース上に正しく登録されたとしても、それを取り出し、他のユーザーがWindows版IEをはじめとするその他のブラウザで見た時に、ことごとく文字化けして見えます。

  • とくに、入力している本人は、Firefoxで文字化けしないので、Windows版IEなどで文字化けしているかもなどとは、ほとんど気づくことはないでしょう。特に、前述のように、IME2003以前を使っている場合には、相当の知識がある人でなければ、「繫」が使用を控えた方がいい文字だとは気付かないでしょう。丸数字などは使わない方がいいと分かっていても・・・。

  • Windows版IEやOpera(Windows、Mac)で入力した「繫」は、フォーム送信時に数値参照文字に変換されます。しかし、多くのWEBアプリで、エスケープ処理がサーバ上でなされるため、その結果「&#32363;」という文字がIEやFirefoxで表示されます。「繫」が表示されることは稀です。あるとすれば、セキュリティを考えていない欠陥システムか、もしくは、逆に、数値参照文字を適切に処理する非常に優れたシステムかどちらかです。

  • 前述のように、SafariではEUC補助漢字の「繫」「森鷗外」を一応正しく表示できますが、フォームが絡んでくると駄目です。ユーザーがEUCでエンコードされたページ上で入力した「繫」(Mac Tigerでどのように入力するかというのはまだテストできていませんが、とりあえずコピー&ペーストでテスト)や「森鷗外」の「鷗」は、送信時には「%3F=『?』」にエンコードされます。Safariでは基本的にEUC-JPの補助漢字をサポートしていないと考えていいでしょう。
結局、IEで補助漢字をサポートされるのを待つか、EUC-JPでエンコーディングしたページなんかやめてしまって、UTF-8に全面移行するしかないのかもしれません。

続きを読む "IE7と補助漢字(「森鴎外」と「森鷗外」)"

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

秀丸エディタとEUC補助漢字(「繋がる」と「繫がる」)



実績3万社以上のギガサーバ


繋   繫

IME2007(β版)で「つながる」を漢字変換すると、

左のように、二つの漢字候補が表示されます。それを拡大したものが上記の漢字です。片方の「繫がる」は「環境依存文字(Unicode)」と表示されます。このブログはUTF-8のため、問題なく、二つの漢字を表示することができます。

しかし、例えば、この二つの漢字を秀丸(ver3.19)でEUC-JPの文字コードで保存しようとすると、次のような警告が表示されます。



「文字コード変換ができない文字が含まれているため、文字が失われる可能性があります」と。そのまま保存すると、「文字コード変換できない文字が含まれていたので、?マークや同義の文字などに変換して保存しました」というエラーメッセージが表示されます。その場では、何も変わっていないように見えるのですが、一度ファイルを閉じて、再び開くと分かります。「繫がる」が「?がる」に変わっています。

同様なことを、EmEditor(ver 4.13)でやってみると下記のようになります。



のような警告(「この文書は、保存用に選択されたエンコードで保存すると失われてしまうUnicode形式の文字を含んでいます。Unicodeの情報を保存するには、下の〔いいえ〕をクリックして、〔名前を付けて保存〕を選択し、〔エンコード〕から〔Unicode〕を選択してください。継続しますか?」)が表示されます。

さらに保存後は、左のように赤でハイライトされて表示されます。赤くなっているだけで、漢字は生きているように見えますが、ファイルを開きなおすと、「?」として保存されていることが分かります。

しかし、実は、秀丸の方が劣っているとかいうことは全然なくて、例に出したバージョンが低すぎるためです。たとえば、秀丸ver. 4.14では、もっと親切なメッセージに変化しています。

左のように、「文字コード変換できない文字が含まれています。かまわずに保存しますか? 〔はい〕を押すと、変換できない文字は"?"などに置き換えて保存します。〔いいえ〕を押すと保存でずに変換できない文字へジャンプします。」と表示されます。これで、どの文字が引っかかって、エラーになっているのか発見しやすくなります。

さらに、秀丸では、ver. 6.0になって、このunicode文字の「繫がる」もEUC-JPで保存できるように進化しています。もともと、この「繫がる」は、EUC-JPの中で3バイトを使って保存される補助漢字というもので、EUC-JPでも実装可能な漢字でした。ただ、補助漢字を実装したアプリケーション(後述するブラウザの分野を含めて)は非常に少ないです。ver. 6.0になって、秀丸もこの補助漢字に対応したとリリースノートにあります。

実際、秀丸のver. 6.0でEUC-JPでこれらの補助漢字を含むファイルは問題なく処理できるようになっています(なぜか私の環境では、ver. 4.14の時と同じ警告メッセージが表示されるのですが、恐らく、異なるバージョンの秀丸を一つの端末で稼働させているからでしょう。ファイルをバイナリエディターで開いてみれば、補助漢字も正しく保存されていることがわかります)。



バイナリエディターのプレビューが文字化けしているのは、このバイナリエディターが補助漢字に対応していないためです。補助漢字で表されている「繫」は「0x8F D4 DA」です。補助漢字は「0x8F」で必ず始まります。しかし、補助漢字に対応していないアプリケーションでは「0x8F」が理解不能なので、単純に無視し、「0xD4 DA」という2バイトの漢字として解釈しようとします。EUC-JPで「0xD4DA」とは「壓」(「圧」の旧字体)です。ちょうど、小学校一年生の私の息子が、ありとあらゆる文章の中の平仮名・カタカナだけを読むので、何の話をしているのか分からないような現象がここで発生しますが、理屈が分かれば怖くありません。

<<補助漢字をサポートしているアプリケーションは、実際のところ少ない。>>
この補助漢字(JIS X 0212-1990)は、天下の秀丸エディタがver. 6.0になってやっとサポートされたことからも分かりますように、サポートしているアプリケーションは、少ないです。

例えば、Firefoxではサポートしていますが、IEではIE7になってもサポートされていません。せっかく秀丸エディターでEUC-JPの補助漢字をサポートするようになっても、IEでは文字化けします。「繫がる」が「恕リがる」にIEでは文字化けします。

さらに、同じ秀丸でも、補助漢字をサポートしていないバージョンで開くと、文字化けします(文字化けの仕方はIEとは異なり、「xs擇・觴」といように、後続する平仮名・タグの一部を含む「全面文字化け」になります。)。

各種ブラウザ上における補助漢字への対応状況・文字化けについては、本稿とは分けて、次回にしたいと思います。



ギガサーバ。スパムメール対策・ウイルス対策もおまかせ

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

2006/11/07

IE7の印刷機能(IE6より強化されているものの、特定ケースでの「不具合?」は残ったまま?)



専用サーバが月額19,800円~

IE7の印刷機能はIE6のそれに比べて、素晴らしいほど進化しています。FirefoxやOperaなどから比べると、やっと追いついたという見方もできるでしょうが・・・。IE6では、今まで、widthが広いページでは、印刷時に右端が切れてしまう現象がありました。



このように、はみ出る場合の対処法としては、

1.用紙の向きを横向きにします。紙をたくさん消費することになりますが、こうすることも多かったです。

2.FirefoxやOperaでそのページで印刷するようにします。

3.プリンター(プリンタードライバー)によっては縮小印刷が可能な場合もあります。80%などと指定して印刷します。

4.用紙設定で、左右のマージンを小さくするようにします。

5.「ホームページ見たまま印刷」などの専用ユーティリティーを使えば可能でした。

ただ、これらの方法は、面倒だったり、お金がかかるので今一つでした。しかし、今回、IE7では、標準で、「縮小して全体を印刷する」が利用可能であり、これにより右端が切れません。



また、


のように、ヘッダーとフッターのon・offがワンクリックで切り替えになったのは素晴らしいと思います。IE6の場合、ホームページを印刷する際に、ヘッダー(ページタイトルや日付)、フッター(URLなど)を印刷したくない場合、いちいち、ページ設定の画面を開き、
「&w                                         &b&T &b&p/&P」
や「&u」などの文字列をどこかにコピーしておいてから、一旦これらのヘッダー・フッター文字列を空白にして印刷してから、再び、元に戻す作業をしなければなりませんでした。これは、とてもありがたい機能です、個人的には。

続きを読む "IE7の印刷機能(IE6より強化されているものの、特定ケースでの「不具合?」は残ったまま?)"

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

2006/11/06

IE7とRSS機能



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

IE7の新機能には、他にもRSS機能が目玉としてあります。ライバルのFirefoxにはずいぶん前からありましたし、同じIEのレンダリングエンジンを使ったSleipnirやLunascapeにはIE6時代から実装されていましたが、本家IEでは、IE7になってようやく実装されたことになります。

ただ、IE7のそれは、今いち使い勝手が悪いです。左のように、RSSフィードを購読するようにしても、お気に入りに登録するのと同じような感じで、最新のニュースの見出し(タイトル)は実際にクリックして、ブラウザのメイン領域に表示させないと、そのサイトの最新記事のタイトルを読むことができません。これでは、FirefoxやLunascapeでRSSの購読に慣れていた人には失望ですね、正直。

Lunascapeなら、右のように、ワンクリックで、メイン画面が切り替わることなく、ページタイトルだけ(JavaScriptによるポップアップメニューのように)表示させることができます。これなら、関心のありそうな記事を効率よく確かめられますね。

IE7でRSSフィードへの関心が高まり、RSSを提供するサイトは増えるでしょうから、その点は良いですが、少し中途半端な印象は否めそうにありません。



Lunascapeをダウンロード

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

2006/11/04

IE7正式版リリース。シェアは既に4.5%



AOL★月額1,995円のADSLプラン!月額費用最大2ヵ月無料!

IE7の正式版がリリースになりました。IE7のシェア(RC1やβ3、β2を含む)を直近の6日間で調べたところ、

IE7のアクセス数IE7のシェア
サイトA121/4,9752.43%
サイトB1,126/30,3753.71%
サイトC1,107/28,4823.89%
サイトD164/2,2267.37%
サイトE
(当サイト)
494/2,84717.35%
サイトF1,291/25,6775.03%
総計4,303/94,5824.55%

となりました。当サイトでのIE7のシェアがやたらと高いのは、IE7ネタが多いためと思われます。

IE7正式版のビルド番号は「7,0,5730,11」になります。また、「navigator.appMinorVersion」は「0」になります。もし、β2・β3・RC1・正式版の違いを考慮する必要があれば、これらの値を調べることで分かります。ビルド番号のJavaScriptでの取得方法のサンプルはこちら

また、気になったので、IE7(これはβ2)でVaio Updateしてみたら、問題なくするーできるようになっていました。前は、JavaScriptでユーザーーエージェントのチェックが入っていたのですが、IE7もOKになったようです。4月に書いた記事ですが、

●(参照)Vaio Update と IE7(ユーザーエージェントの偽装方法)
http://shimax.cocolog-nifty.com/search/2006/04/vaio_update_ie7.html

のように、以前はユーザーエージェントを偽装しないと表示できませんでした。

今調べてみると、JavaScriptでのチェックでIE6及びIE7でOKになるように変わっていますね。いつ変更になったのかまでは分かりませんが、やはり正式版がリリースされると違いますね。



〔ラピッドサイト〕仮想専用サーバ「VPS!RVシリーズ大好評」

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

2006/11/02

IE7とJavaScript(clipboardData.getData()と警告メッセージ)



【DHC】英会話の苦手な日本人のためのスピーキング講座

IE7で、JavaScriptの挙動が変わったものとして、prompt()メソッドwindow.close();にかんする挙動について、先日紹介しました。今回もセキュリティがらみですが、クリップボード操作に関する挙動がIE7では変わっていることをご紹介したいと思います。

IE6まででは、(デフォルトのセキュリティ設定で)

で、クリップボードの中身を取得できていました。

しかし、IE7では、デフォルトのセキュリティ設定で、必ず、左のような確認メッセージが表示されるようになりました。これはセキュリティ的には大正解の設定・方向性ではないでしょうか? 遅きに失した、という話もありますが・・・。

今までのIE6では、このようなメッセージは、デフォルト設定では表示されていませんでした。これだと、パスワードやクレジットカード番号を仮にコピー&ペーストして使用した直後にそのサイトにアクセスすると、大切な情報が漏れていたかもしれないのです。また、会社の機密情報が漏れる可能性もないとは言えません。IE6でセキュリティ設定をいじって、ダイアログを表示させることもできましたが、

IE6では、左のように、「このページを使用して、クリップボードから情報を貼り付けますか?」というとても分かりにくいものでした。

「貼り付けますか?」と聞かれたら、「自分の情報を自分で見るだけだからOKだろう」ぐらいにしか思えませんね。「貼り付ける」が「クリップボードの中身がリモート(第三者)に送信されたり、操作されたりする可能性」につながるとは多くの人が思わないのではないでしょうか?

今回、IE7のデフォルト設定で、「この Web ページがクリップボードへアクセスするのを許可しますか? これを許可した場合、Web ページからクリップボードへのアクセスが可能になり、最近行った、切り取りやコピーの情報が Web ページへ読み取られるのを許可します。」という分かりやすい警告が出るようになったことは非常に良いことだと思います。この警告なら誰でも理解できます。

続きを読む "IE7とJavaScript(clipboardData.getData()と警告メッセージ)"

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

« 2006年10月 | トップページ | 2006年12月 »