mod_rewriteを使おうと、.htaccessに適当に記述してサーバにアップロードし、動作確認をした。
403 Forbidden
えー。意味わかんない。記述間違いでInternal Server Errorなら理解できるのに。もしや書き換え後のURLがアクセス不能になっているのか、と思ったらそうでもない様子。
共用レンタルサーバなんだけど、mod_rewriteがそもそもインストールされていないのか（だったら500エラー？）。あと仮にmod_rewriteがインストールされていても、Apacheの設定で「FollowSymLinks」が有効になっていないとダメらしい。
いろいろ難しいね。
WordPressでこんなエラーが出た。いやいや、自分が管理者で間違いないですけど。ちなみに、エラーが出たWordPressのバージョンはME2.2.1。
何らかの原因で文字コードが変わったりするとこのエラーが出るらしい。例えばデータベース内のテーブル「wp-options」の「wp_user_roles」というところには管理権限に関する情報が書かれている。ここの値は配列がシリアライズして記述されているので、日本語が入っていて文字コードが変わったりすると影響が出て、その結果として権限情報が取得できない、みたいな感じなんだろう。とりあえず、この行がうまく取得できなかった場合にエラーが出そうだ。
で、調べてみたけど、文字コードは変わっていなかった。で、なぜ、エラーが出るのか。
実はWordPressを移設しなくてはならない事情ができて、その際にテーブル名を変えた。デフォルトで入力した際「wp_」だったところを「www_wp_」に変えた。もちろんwp-config.phpの中で$table_prefixの値は書き換えたので、表面上は問題なく表示されていたっぽい。でも、実はwp-config.phpを編集するだけではいけなかった。変更する箇所はデータベース内に3点あって、まずそれらを探す（以下のリスト）。
それは無理。でも楽をして拡張子なしで画像を保存してしまったので、何とかしなければならない。
その1. mod_rewrite
RewriteEngine On
RewriteRule ^/(.*)\.jpg /image.php?id=$1
.htaccess等で上記のように指定する。画像を呼び出すためのimgタグには、画像ファイルへのパスに「.jpg」と拡張子をつけて出力しておく。こうするとURLが自動的に切り替わり、ファイル名を引数に与えてimage.phpが呼び出される。適宜処理して画像を出力すればいい。
その2. 拡張子.jpgをPHPプログラムとして認識させる
<Files ~ “^image\.jpg$”>
AddType application/x-httpd-php .jpg
</Files>
.htaccessで上記のように指定する。これでimage.jpgはPHPプログラムとして処理される。画像を呼び出すためのimgタグには、image.jpg?id=（ファイル名）のように記述する。これでimage.jpgが呼ばれると、適宜処理して画像を出力すればいい。
携帯向けの場合、画像ファイルの拡張子の後ろに?id=とつけるのは気持ち悪いが手持ちの3キャリアの各端末では表示できたので、とりあえずよしとする。
PHPでCMSを作る場合、画像をアップロードして反映させる機能を作ることも多い。その際どんな風に作るのが一般的なんだろうか、と疑問に思ったので、現在の自分の作業をメモしておくことにする。
PHPからメールを送信するとき、mail関数やmb_send_mail関数などを使う。このとき、Fromとして送信元を指定する場合、第4引数として「From: test@example.com」のように与えると、送信元を指定したメールを送信することができる。ただしこのままでは日本語は使えない。この引数はそのままメールのヘッダとして追加されるので、日本語は適切に変換をかけなければいけないことになっている。
ここまでは当たり前の話だが、注意しなくてはいけないのは、日本語の適切な変換をかけるための関数「mb_encode_mimeheader」の使い方だ。マニュアルを見ると以下のように書いてある。
string mb_encode_mimeheader ( string str [, string charset [, string transfer_encoding [, string linefeed]]] )
mb_encode_mimeheader() は、MIME ヘッダ エンコーディング方式によって文字列 str をエンコードします。この関数は、ASCII 表現の文字列を返します。
charset は、str の文字セット名です。デフォルトは、現在の NLS 設定 （mbstring.language）によって決まります。
transfer_encoding は MIME エンコーディングの 方式を指定します。“B” (Base64) または “Q” (Quoted-Printable) のどちらかでなければなりません。 デフォルトは “B” です。
第一引数はいうまでもなく変換したい文字列だ。この関数では基本的にこの第1引数だけを指定しておくのが無難。必要に応じて以降の引数を設定することもあるだろうが、第2引数の扱いには注意が必要だ。
マルチバイト関数ならたいてい使用している文字コードを引数として与えるオプションがついている（これはmbstring.internal_encodingに連動している）。しかしこのmb_encode_mimeheaderで与えるcharaset（第2引数）はその意味がまったく異なる（ようだ）。
例えばUTF-8でプログラムを記述しているからといって以下のように記述するのはNGだ。
mb_encode_mimeheader($str, ‘UTF-8′);
変換結果を出力すると以下のようになっている。
=?UTF-8?B?・・・・・・・・・・・・
本来なら「=?ISO-2022-JP?B?・・・・・・・・・・・」なはずなのに・・・。理由は省略するとして正しくは以下のように記述しておくのが無難なようだ。
mb_language(‘Japanese’);
mb_internal_encoding(‘UTF-8′);
$str=mb_encode_mimeheader($str);
1行目のmb_language関数でmb_encode_mimeheader関数に対して「日本語ルールで変換せよ」と命令していることになる。2行目で「現状文字列はUTF-8で記述されているので、UTF-8から変換すればよいものと想定して処理せよ」といった感じだろうか。だから1行目と2行目を記述しておくことだけでいいはずだ。
ちなみに引数として渡すには、以下の内容でmail関数やmb_send_mail関数の第4引数として渡せばよい。
mb_language(‘Japanese’);
mb_internal_encoding(‘UTF-8′);
$option=’From: ‘.mb_encode_mimeheader(‘名前’).'<test@example.com>';
mail($recipient,$subject,$message,$option);