PHPでwebサイトクロールに挑戦 #4「文字エンコード問題

#1 システム考案 #2 HTML取得 #3 データ構成

文字エンコードを考える

最近のLINUXはUTF-8でデフォルトセットされるので、apacheもphpもnginxも大体がUTF-8で構成されてしまう。 もちろん、グローバル対応で考えるとこの方が都合がいいのだが、古いOSやwindowsサーバーを使っているとどうしてもEUCやSHIFT-JISなどのWEBサイトは世の中に存在してしまう。 サイト毎に運用している上ではそのサイトの仕様ということで全く問題にはならないんですが、以下の様なトラブルも発生しているようです。

UTF-8ではないサイトの問題

１、ASPツールなどを利用する時に、UTF-8限定のエンコードしか対応していないツールもあり、導入できないという問題が発生する場合がある。 ２、WEBサイトから、メールシステムへデータを送信する場合など、文字化けが発生する。 ３、管理側やユーザー側がWEBサイトのHTMLソースを取得する場合に、文字化けしてしまう。 ４、スマホアプリで、文字エンコードが対応していないアプリなども存在する。

やはりUTF-8以外はダメなのか？

はっきり言って今現在のグローバル視点で考えるとUTF-8で全てを構築する事が、各種の問題が限りなく少なくなると思います。 ちなみに、主要タグマネージャーなどの仕様にもUTF-8以外は使用できない事が書かれています。 セキュリティを考慮して、Shift-jisやeuc-jpなどにしていく手もありますが、公開webサイトという事を考えるとUTF-8で検討するようにしましょう。 すでに、UTF-8以外のエンコードで構築されているサイトは、できるだけ、改修を考えてしまったほうがいいと思います。

クローラーツールの対応

wgetのオプションを見直しました。 ファイル出力を無くし、変数に突っ込んでから、echoコマンドを用いてファイルに出力していたんですが、 もともとwgetツールにはファイル出力がデフォルトでついているので、その機能を使うことにしました。

前回ソース

#source-get html=`wget --output-document=/dev/null -q -O - ${url} 2>/dev/null` #source-write echo ${html} > "data/${id}.html"

修正ソース

wget ${url} -O "data/${id}.html" シンプルになった上、改行コード問題、文字エンコード問題も解消したので、一安心です。 次は、差分処理を行いたいと思います。