このブログのMTに、あるいはTumblrにもOGP設定してみたわけですが、ある環境でOGPがうまく反映されないケースがあったので紹介します。
OGPのタグについては、Open Graph protocol – Facebook開発者などを参考にしながら正しいコードが出力されていることを確認しているのに、URLリンターでチェックしてみると、設定した情報が全く反映されていないという事例がありました。URLリンターに反映されないので当然「いいね！」などを押しても想定した画像がサムネイルにならないなどしばらくハマってしまいました。
で、改めて色々調べたのですが、Facebookで「いいね！」したときやURLリンターでチェックしたときは、Facebookのクローラー（スクレイパー？）が対象のURLにアクセスしてきて情報を持っていく仕組みになっています。サーバのアクセスログを閲覧できるのであればログの中に「facebookexternalhit」という文字列が入ったUser-Agentを見つけることができると思います。
→参考：外部ユーザーエージェントテキスト – ウェブマスターのためのヘルプ
OGPのタグはJavaScriptが解析してFacebookに渡すというよりも、最終的な情報はクローラーがHTTPアクセスしてきて確認しているので、どうやらこのクローラーさんがうまくソースを読んでくれていないという予測が立ちました。こういうときは文字コードとかが問題になることが多いとなんとなーく気付いてApache（Webサーバ）の設定をチェックしてみたのですが、原因となっていた設定値を見つけることができました。
AddDefaultCharset Shift_JIS
この対象サーバは複数のVirtualHostで複数のサイトを運営していたのですが、メインのサービスの文字コードが（いまどき？）Shift_JISだったため、ApacheにAddDefaultCharsetが指定されていました。
→参考：core – Apache HTTP サーバ
AddDefaultCharsetによって、Content-Type が text/plain あるいは text/html のURLへのアクセスに対して、レスポンスに自動的に文字エンコーディングの名前が入ってしまいます。普通のブラウザではHTMLのmetaタグで指定したcharsetを見ているようですが、クローラーはレスポンスヘッダーの文字エンコーディングを優先し、文字化け状態でOGPを認識出来なかったことになります。
対応としては、OGPを設定したいサイトのVIrtualHost内で、
AddDefaultCharset utf-8
という記述を足して解決しました。HTMLにmetaを記入しているのであれば、
AddDefaultCharset Off
として無効にしてしまっても問題ないように思います。
まとめ
まあ、あんまり文字コードが混在している環境というのもあまりない・・・と信じたいわけですが、まああるかもしれないので。レアケースとは思いますが、どうしてもうまくいかずに同じような状況の場合は、Apacheの設定確認してみてください。
