charsetの判定方法とは？

2008/12/22 16:03

このQ&Aのポイント

html文を解析するプログラムを書く際、charsetの指定場所を正確に判定する方法は何か？
アメリカン航空のホームページでは、charsetの指定が<head>タグの前にあることが確認された。
IEやchromeはこの位置でもcharsetを正しく判定することができる。

noname#182251

HTML
回答数6
ありがとう数3

みんなの回答 （6）
専門家の回答

質問者が選んだベストアンサー

ベストアンサー

nkzw_spl
ベストアンサー率75% (6/8)

2008/12/22 19:28 回答No.2

おそらく、 HTMLのどの部分にあっても、 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> の記述は認識すると思います。 </html>のあとに記述したら分かりませんが。ただ、テストしたわけではないので分かりません。あくまで経験からの勘です。世の中、きっちりとしたHTMLをかけてる人は1％程度にも満たないのではないかと思います。多少のHTMLの記述の間違いはレンダリングエンジンは気を利かせて、解釈しますね。

質問者

お礼 2008/12/23 10:44

ご回答有り難うございます

質問者

補足 2008/12/23 10:28

>テストしたわけでナルホド、テストすればよいわけですね。以下のhtml文でIEもchromeも共にutf-8として反応しました。どこに書いてもよいような. . . . <html> <head> <meta http-equiv="Content-Language" content="ja"> <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> <meta name="ProgId" content="FrontPage.Editor.Document"> <title>試験</title> </head> <body> 試験 </body> </html> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

ログインすると、全ての回答が全文表示されます。

その他の回答 (5)

SAYKA
ベストアンサー率34% (944/2776)

2008/12/25 15:07 回答No.6

ごめん　なんか色々勘違いしていたみたいどこにcharsetがあっても読めるようにしたいんだけど位置を特定できないからどうしたものか　って話　で良いのかな？ charsetだけをどうやって取り出すのかっていうのは実はそんなに難しくなくて文字コードには色々あるけれど、このcharsetのmetaタグだけは「必ず全て基本ASCII文字」で構成されてるという事実に注目したら良いんじゃないかな。 metaの位置は決められてるのに守っていないHTMLは数あれど、このcharsetが「基本ASCII文字」というのを守らない人は基本的に居ないよね。 (じゃなかったら読めないわけだから) 指定の仕方を間違える(誤字含む)人は居るけれど結局は基本ASCII文字列の範囲内。どういう方法でプログラムを構築してるか知らないけれど書式が決まっていてそれ自体を守らない人は殆ど居ない、例外的に間違えたり勘違いで「値として存在しない」物を指定しちゃう事があるくらいで、それらを認識していればcharsetを宣言しているmetaタグを取り出す事はできるんじゃないかな。後はもう、思いつく間違えを補助する事だけだね。 sjisに代表される誤った指定や複数指定なんかの類。テキストエディタのような文字コードを自動解析するようなものも併用すると良いんじゃないのかな。(ブラウザの自動判別はそういうのを併用している) それとも、文字列自体のmatching方法が判らないっていう質問？

質問者

補足 2008/12/25 15:36

４回もの、それも長文のご回答、感謝です。しかし >どこにcharsetがあっても読めるようにしたいんだけど位置を特定できないからどうしたものか　って話　で良いのかな？違います。この件は、＃２に補足を書いてcharsetどこにでも存在する可能性があると判った時点で解決しています。＃４の補足にも「今回の例であればcharsetがどこに書かれても対応するようにしました。」と解決済みであることを示しています。

ログインすると、全ての回答が全文表示されます。

SAYKA
ベストアンサー率34% (944/2776)

2008/12/24 18:02 回答No.5

>ＩＥにしてもバージョンの問題がありますよく、ブラウザと関係ないソフトでさ「IE バージョン○○以上で」と書かれてるのが有るのを見たことがない？あれはIEというcoreを使ってHTMLなりXMLなりの解析をパースさせてるんだよ。これは楽ができるというのも一つだけれど、ユーザがよく見る「IEでのページ」になるという特徴があるね。ただ、IEの場合はバージョンが絡むのはwindowsの場合IEのcoreは埋め込みできず、OSのGUI部品描画と同じ様に呼び出すしかできないから起きる事なんだよ。　→バージョン○○が必要他の解析エンジンで埋め込めるようなのを使うのもアリだね。(GeckoやWebKit) これであれば常に自分が確認したバージョンを用いてユーザはそれを使うだけという状態になるよ。 >メリットも見えてきません前述した通り、そのブラウザの挙動や表示方法が既に確立されている物を使えるって点だね。(ページの乱雑な記述でも対応してユーザが一般的によく認識してる形にしてくれる、というかそのもの) これはつまり質問者が最初から言っている「変な所に書かれたタグも認識している」という物を「既に実装している」わけで「使っても良い」んだからうまく行かないのならうまく行ってる、ライブラリとして使用しちゃうのはどうかな？という事を言っているんだよ。 charsetだけの解決なら、もう「どこにあっても認識するようにしておく」と解決しているだろうけど、他の似たような物が細かくでてきたら、再考しても良いんじゃないかな　→レンダリングエンジンに丸投げ多分、cssやscriptが絡んでくると、お手上げになるんじゃないのかな。

質問者

補足 2008/12/25 06:29

度々の回答はありがたいですが、補足が全く理解されていないようでくたびれてきました。そろそろ終わりにしたいです。バージョンの問題は、例えば○○ページにＡブラウザで見えてＢブラウザで見えないものがあり、××ページにＢブラウザで見えて、Ａブラウザで見えないものがあるとき、両方見たいという話しです。さらに＃４の補足にも書いたように、バージョン問題は「枝葉末節」です。要するにソースを見た方が判りやすいし（人により判断は異なるでしょうが）ソースには全てが書かれています。タグの意味など判らなくても困りません。唯一の例外がcharsetで、これだけは判定しないと文字化けして「暗号解読」もどきになります。レンダリングは不要というよりも、拙アプリケーションでは有害です。 >cssやscriptが絡んでくると、お手上げになるんじゃないのかなほとんど問題ありません。ただｃｇｉなどで「動的に」データを取り込む場合、私の勉強不足故未解決となっています。

ログインすると、全ての回答が全文表示されます。

SAYKA
ベストアンサー率34% (944/2776)

2008/12/23 18:38 回答No.4

本来どこに書いても良かったらDTDなんて存在しないんだよね。ただ、昔ね、HTMLの表記がおかしいからって表示がされなくてページが見れない、なんて時代が有ったよ。主にtableのtdの閉じタグ忘れなんだけど。それ以来、他のブラウザは「柔軟に対応」するように組まれてきたんだよ。その柔軟性のせいで「完全に読込みが終らないと表示できない」なんていう弊害が起きて「IEはすぐ表示されなくて(結果的に)遅い！」なんて言われてた時代も有る。柔軟に対応してくれるのは良いと思うんだけどそのせいで今度はぐちゃぐちゃなHTMLを書く人が激増して、一定の場所から文字が小さくなったままだとかが平気で放置されるような時代が来たよ。この時代、validatorなんていう気の利いた物は…有ったけど一部の人しか使わなかった。だけどHTML文書は増えていく一方。そんな中現れたのが「strict」という厳格にDTDを守らせるやり方。「標準モード」「互換モード」とかあるけれど、そういうのも加味して解析をどこまでゆるやかにするのかを考えたら良いと思うよ。 charsetは通常順番に読まれる書類で文字列が現れるよりも先に定義しなさいと言われているけれど件の</html>の後に入れてあるというのは酷すぎるとしても「途中で使用文字コードを変えたい」なんて思っている人がやりがちな事なんじゃないかな。又は「本当に最初に書かないといけない！」って勘違いしちゃってるか。物凄い極端な話だとそういう処理はIEに丸投げしても良いと思う。レンダリングやレンダリングした結果整形されたHTMLを取り出してから解析を開始すればかなりの部分楽できると思うよ。(取り出しやすくなる

質問者

補足 2008/12/24 09:14

度々のご回答有り難うございます。しかし >そういうのも加味して解析をどこまでゆるやかにするのかを考えたら良いと思うよ私はＤＴＤの伝道師でもないし、「規格を守らないhtml文」と「それを許容するブラウザの存在」を現状と認識し、この現状でユーザーが見て監視したいと思うものを監視できるように努力するだけです。従って「限りなく緩やか」と云うか、ユーザーが「これを見たい」と要望すればそれを実現しようとします。今回の例であればcharsetがどこに書かれても対応するようにしました。 >「途中で使用文字コードを変えたい」こんなことを考える人がいるかどうかはともかく、＃２の補足を書くとき途中で使用文字コードを変えてみましたが、ＩＥは反応しませんでした。従って現状では最初のcharsetを読むだけです。どこかのブラウザが対応し、ユーザーから要望があれば考えます。 >そういう処理はIEに丸投げしても良いと思うこれは疑問です。ユーザーのブラウザが何か判らないし、ＩＥにしてもバージョンの問題があります。しかしこれは枝葉末節の問題で、サーバーからhtml文をダウンロードして、そのテキストを直接処理した方が余程簡単なのです。例えば元質問の例に貼り付けたアメリカン航空のホームページで、ユーザーが監視したかったのはサーチャージの変化なのですが、この場合は正規表現で「.*片道につき」と「円.*」に挟まれたテキストを監視すれば済みます。「IEに丸投げして」その結果を取り返し、解析する方法は現段階で考えつかないし、メリットも見えてきません。

ログインすると、全ての回答が全文表示されます。

axar
ベストアンサー率0% (0/1)

2008/12/22 19:31 回答No.3

SAYKA様の仰られているように、仕様を見て、それに従った実装をするべきだと思うのですが・・・HTMLがValidかどうかを解析するプログラムを作る場合の話ですが。回答番号１の補足より >>定義から正か正しくないかは問題ではありません。世間で一般的に「読まれている」html文が読めなければ、私の目的は果たせないのです。つまり少なくともIEが charset を判定する基準ぐらいは知りたいわけです。 IEなどのブラウザ側が、どこに文字エンコーディング指定があっても、書かれていればそれに従うという柔軟な設計になっているのではないでしょうか。また、HTTPレスポンスヘッダーの情報をブラウザが取得することもできるはずですが。どういう目的で解析プログラムを作りたいかによって、仕様が変わってくるのでなんとも言えないのではないでしょうか。妙なHTMLにも対応できる必要が不明です。悪いのは、HTMLを書いた側であって、HTMLという仕様の決まったものを使うなら仕様にあわせて書かなければなりません。ブラウザを作りたいならいろいろと考慮する必要があるのかもしれません。 >>htmlの知識がほとんどないまま、無謀にもhtml文を解析するプログラムを書いています。無謀ならやめておけば、と思います。プログラムを書けるレベルにあるのであれば、HTMLの文法ぐらいなんともないはずですが。理解せずに解析するプログラムを作るのは不可能でしょう。

質問者

補足 2008/12/23 10:40

ご回答有り難うございます >無謀ならやめておけば、と思います。プログラムを書けるレベルにあるのであれば、HTMLの文法ぐらいなんともないはずですが。理解せずに解析するプログラムを作るのは不可能でしょう。これも一つの見識だと思います。しかし当該アプリケーションは２００４年１１月に公開し、昨年１１月の最新バージョン公開後も約５０００のダウンロードがありました。フリーソフトではありますが、それでも一応ユーザーに対する責任もあります。今回の質問もユーザーからの「改善要求」がきっかけでした。実装する機能は、ユーザーが興味を持つＵＲＬ（複数も可）を自動かつ定期的に巡回し、ユーザーが注目する箇所の変更を通知するものです。従って「悪いのは、HTMLを書いた側」と切り捨てることはできません。「無謀」といささか大袈裟に書いたのは「Ｗ３Ｃに『charsetとheadの位置関係は不定』と明記されている。ちゃんと読め」のお叱りを受けるかと思ったからです。しかし現状は＃２の補足にも書いたように「どこにあっても良い」のディファクトスタンダードに従うようです。

ログインすると、全ての回答が全文表示されます。

SAYKA
ベストアンサー率34% (944/2776)

2008/12/22 16:33 回答No.1

その指定は正しくないね。 metaの定義を見れば判る筈だけど・・・ http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/sgml/dtd.html headタグ内にしか存在を許されていないから質問者の認識「headタグ内で確認できれば良い」で合っているよ。

質問者