- ベストアンサー
日本語が正しく取得できない問題について
- DOMNodeのtextContentで日本語が正しく取得できない問題があります。
- PHP 5.2.11の環境でDOMCommentのDOMElementのtextContentを使って日本語を取得しても、正しく取得できない現象が起きます。
- DOM関数がマルチバイトに対応していない可能性があります。文字コード変換関数を試しても解決しないようです。
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
前置き: 白状すると、俺、rawurldecodeとrawurlencodeを見間違えて、「作り方おかしいぜ」ってなコメント入れようとしていたんだ。 #まぁrawurldecodeだったとしても納得いかないんだけど(ソースとコメント参照)。 #しかも str_replace ("euc-jp","utf-8",$data);って"euc-jp"がmeta[@http-equiv="ContentType"]以外にあったらどーすんだ、と。 人のミスを見つけると子供のように喜ぶ俺は うきうき気分で自己紹介欄にコメント書いて、さあ後は実験だ、となった。(間違った予測) …あれれ、失敗。失敗。失敗。自分も出来ない(泣) え？え？え？loadHTMLはmeta要素で指定されていれば、文字符号化方式は自動的に判別するはずだしなぁ (しばらく検索) …PHPのばっかやろー。 ================== 本題: http://devzone.zend.com/article/8855 If encoding is not declared in the XML/HTML header, the input string is parsed as 符号化方式がXMLおよびXHTMLのヘッダで示されていないとき(訳注:meta要素も含むと思う)、 入力文字列は以下の物として解釈される * a UTF-8 string by loadXML(); loadXML()を使った時はUTF-8の文字列 * an ISO-8859-1 string by loadHTML() (!!!!) corresponding to the HTTP 1.1 standard (RFC2068, section 3.7.1); * and DOMDocument::$encoding is set to null. loadHTML()を使った時は、HTTP1.1に基づき、ISO-8859-1の文字列として解釈する。 このとき、DOMDocument::$encodingはnullに設定される。 Clearly, problems of correct document encoding transformation are more difficult to be solved for HTML parsing than XML, as the latter has a more formal specification and stricter rules, XML encoding is declared in the opening tag, and the default encoding is UTF-8, which covers the whole Unicode range. So the rest of the article will mostly touch on HTML parsing problems. 明らかに、正しい符号化方式変換の問題はXMLのパースよりHTMLのパースの方が解決するのが難しい。何故なら後者はよりもっと詳しい仕様書と厳格なルールがあるからだ。XMLの符号化方式は始まりのタグ(訳注:XML宣言のこと？)で宣言される。されなかったときのデフォルトはUnicodeの範囲全体をカバーするUTF-8がデフォルトだ。 よって、この記事の残りの殆どはHTMLのパースの問題について述べている。 Encoding issues with HTML parsing HTMLのパースの符号化方式の問題 Unfortunately, loadHTML() doesn't always correctly recognize the defined Content-type HTTP-EQUIV meta tag. 【残念ながらloadHTML()はいつも正しくmeta[@http-equiv="Content-Type"]を認識するわけではない】 The following things act as blockers: 以下の時は認識を阻むものとして動く。 * Any non-ASCII symbol occurring before the Content-type HTTP-EQUIV meta tag; 【ASCII外の文字が何かmeta[@http-equiv="Content-Type"]の前に登場すること】 * Any invalid (from an encoding point of view) symbol occurring in the document. E.g. Content-type meta tag declares 'charset=UTF-8', but the actual HTML markup contains non-valid UTF-8 sequences. ===================== …え？まさか確かめてみる。 loadHTMLが実行出来ない以上、DOMノードが作れないので CDATAマーク区間その他に含まれる同じ文字列を巻き込むこと覚悟で "<!--龠龠龠-->"をstr_replaceで置き換えてみた →成功orz ============== #っていうか、他の部分を巻き込まず、"サニタイズ"を考えなくていいところがDOMの一つの利点だと思うんだがな…
お礼
ご解答ありがとうございます。 3日間ほど、寝込んでいたもので、今読みました。 研究してみます。
補足
ご回答をヒントに解決できました。 ブラウザー文字化け対策の記述が仇となってたみたいです。 <!--龠龠龠-->を<--binyu--> として無事解決しました。龠は美乳の一種だったとは。