ガラケーサイトからスマホやPC向けサイトへとサイトを拡大する場合、
SJISだった文字コードを「この際だからUTF-8に一括で変更してしまおう」と思ったのが悪夢の始まりでした。
formからのデータ送信やGETでのクエリが山のようにインデックスされていたので、
その全ての外部リンクが文字化け状態。
まぁ、htaccessあたりで何とかなるだろうと思っていたのですが・・・
htaccessで文字コードの判別は無理
どう考えてもhtaccessで文字コードの判別して転送なんて無理っぽい。
見切り発車万歳！でもガラケーも新しい機種はUTF-8対応しているみたいだし、
今後を考えると移行しちゃってもいいや。
一つ一つの/hoge.php?keyword=○○○○を転送設定なんてやってられない。
内部文字コードとかPHPでなんとかならないかな？
アクセスされたページはSJISのurlencodeの文字列を持ったクエリ付URL。
ページの文字コードはUTF-8になっている。
フルオートで変換を諦める
よく目にする、ie=UTF-8みたいな判別クエリも付けてないし、
フルオートでの変換・転送は即諦めて、アクセスや被リンクの多いワードだけ拾うことに。
目当てのワードを「天丼」として
mb_convert_encoding("天丼","SJIS-win","UTF-8");
一回SJISに直して一致確認してみたら、
SJISで照合合致したので、UTF-8に転送という遠回りなアナログ手法でやってしまいました。
本当はもっと効率の良い方法があるかもしれないけど、
サイト全体の文字コードを変更してエラーがないのは難しいですよね。
おかげで、DBとの連携も楽になりました。
外部ファイルの文字コードにも注意！
だけど外部呼出しファイルの文字コードがSJISだと
・・・悪夢だ。
そりゃそうなんだけど、その外部呼出しファイルはPHPが入った使いまわしで、
SJISから呼び出す前提で作られているファイルでしたのでSJISです。
とにかく動かないと始まらないので、対処方法として
１．外部ファイルをUTF-8用に用意する。
２．変換方法を探す。
１．は内容的にも管理的にも面倒でゴミが増えると思ったので、却下。
そこで調べるとeval関数なる危なそうな物がありました。
$test = file_get_contents('../hoge.php');
eval('?>'. mb_convert_encoding($test, 'UTF-8', 'SJIS-win'). '<?');
一発で動く奇跡。
後から関数熟読で理解する始末。
なかなか危ない関数なようで、
警告 eval() は非常に危険な言語構造です。
というのも、任意の PHP コードを実行できてしまうからです。
これを使うことはおすすめしません。
となっています。
まるでマジックのような関数ですが、外部ファイルをPHPとして実行するなんてよく考えると恐怖ですね。
まとめ
いずれ排除するとして今回は一度使うことにしましたが、一時的に凌ぐ手段だと思った方がよさそうです。
いやーこのままだとSJISが嫌いになりそうです。
やっぱりSJISは鬼門です。
今日も知識欲は止まらない。
