PHPのfile_get_contents()が動いてくれないときに確認すべきこと
ローカル環境では問題なかったが、リモートサーバにアップしたところ動かなかったためちょっと調べた。
最初に疑ったのは、サーバのPHPの設定の問題。
phpinfo();で確認して、allow_url_fopen がoffになっていると、file_get_contents()は使えない。
php.iniを変更するなりする必要が有る。サーバのphp設定を変更する権限がない場合はあきらめるしかない。
私の場合は、サーバのallow_url_fopenはOnになっていて問題なかった。
問題だったのは、リモートサーバではBasic認証がかかっていたことだ、
file_get_contents()の引数に設定するURLに、Basic認証のユーザ名とパスワードを含めなければいけない。書き方は以下のとおり。
Sequel Proでビューが文字化け表示される
データベース管理アプリケーションとして評価が高い「Sequel Pro」は、とても使いやすくて素晴らしい。
しかし、今日残念ながらバグらしきものに遭遇してしまった。
ビューが文字化け表示されてしまうというもの。
私の環境は以下。
MySQL 5.1.44
Sequel Pro 1.0.2
エンコーディングはすべてutf8で統一してある。
mysql> status
Server characterset: utf8
Db characterset: utf8
Client characterset: utf8
Conn. characterset: utf8
テーブルは問題なく日本語入力しているレコードもきちんと表示されている。
ところが、ビューを作ると全部「?????」と文字化けして表示される。
ビューの構造を調べたところ、
文字化けしているカラムのエンコーディングが「cp1252 West」、照合順序が「latin1_swedish_ci」となっていて、変更できない。変更できないのはビューなのであって、元のテーブルの状態を引っ張ってきているだけだから仕様なんだろうけど、問題は元のテーブルと一致してないことにある。
元のテーブルの該当カラムは、エンコーディングがすべて「utf8」になっている。
さらに混乱することには、ビュー自体のキャラセットは「utf8」になっている。ビューのカラムだけが違うエンコーディングになっている。
ターミナルからビューをSELECTした場合には文字化けせずに見られた。phpMyAdminでも問題ないことを確認済みなので、Sequel Proの問題だと思われる。
検索してもさっぱり出てこないが、ひとつだけアプリケーションの公式フォーラムに同じ問題を抱えたらしき人の投稿があった。
http://www.sequelpro.com/blog/2011.09/sequel-pro-0-9-9-1/
September 13th, 2011のAvery Wu さん
結局のところ解決策は分からず。
Facebook JavaScript SDK でOAuth認証ができないときに、陥っているかもしれない単純なミス
connect.facebook.net/ja_JP/all.jp は読み込んで、
FB.init() で初期化もすませた状態。
OAuth認証しようとして以下のような関数を書いて実行する。
ウインドウが立ち上がってログインフォームが出る。
ログインするとウインドウが消える。認証できたと思いきや、
引数のresponse.authResponseがnullのまま。
FB.login(function(response) {
console.log(response);
if (response.authResponse) {
//認証できた
}else{
//ログインしてない、もしくは認証してない
console.log(User cancelled login or did not fully authorize.);
}
}
原因は、facebookアプリがサンドボックスモード(Sand Box Mode)だったからだ。
サンドボックモードとは、開発中などでアプリが関係者以外に見られたくないときに非公開状態にする設定だ。この状態だと、アプリ設定画面で権限を付与されたユーザーしかアプリ認証できない。
変更はアプリ管理画面から簡単に変更できる。
facebook JavaScript SDK でauth認証できなくて困ったら、確認してみてください。
iPhoneのwebインスペクタが使えるのはLionから
iPhoneのデバッグコンソールが使えなくなり、かわりにMac Safariのデバッグツールと連動できるようになって久しい。
探せばこれに関連する記事はいろいろ出てくる。
iPhoneをmacにつないで、Safariの開発メニュー内から接続したデバイスを選択する。
と説明されているが、iphoneを接続しても、Safari内のメニューにそれらしき項目が表示されない。
実はこの機能、Safari6以降の機能だそうだ。そして、Safari6は Mac OS Lion以降が対象である。ゆえに、Snow Leopardな人は、iPhoneのデバッグツールが使えないわけだ。
このことを報道する記事が全くないので書いておく。
Mac上でモバイルデバイスのデバッグができるのは良い機能だと思うが、デバイス単体でも確認できるコンソール機能は残しておいてほしかった。
jQueryを使った同じドメイン内のJSONPへのアクセスがIEで失敗する問題
JavaScriptがサーバにアクセスしてデータを取得する手段としてXMLHttpRequestがあるわけだけど、same domain policy すなわちセキュリティー的な観点から同一ドメイン内での通信に制限するポリシーによって、異なるドメインからデータを取ってくることはできない。ことになっている。
それを裏技的に回避する手段がJSONPであって、htmlのscriptタグを使えば別ドメインのデータも引っ張って来れるじゃんという代物。JSONPはDOM要素を動的にいじりながらやるわけで、XMLHttpRequestを使って正攻法でデータを取ってくるのとは随分とおもむきが違う。
とはいえ、あんまり難しいことを考えなくてもjQueryを使えば、JSONだろうがJSONPだろうが同じような感覚で扱えてしまうのが素晴らしいところ。
さて、今回ハマったのは表題の通りで、jQueryを使って同じドメイン内のJSONPからのデータ取得がIE(7,8,9)で失敗するという現象。
同じドメインでデータ取るならJSONでいいのだが、別ドメインからのアクセスも想定して運用する前提であり、且つIE7まで対応するということでJSONP方式である必要があった。
問題の現象としては、別ドメインで動かしている分にはデータ取得できるが、JSONPと同じドメインに置くと、ステータスコードが200で正常にアクセスできているにも関わらず "parsererror"が発生する(IE限定)というもの。
結論から言うと、jQueryはAjaxアクセス先のドメインが同じかどうかで処理を分けていたらしく、別ドメインだとJSONPをscriptタグで読み込んでコールバック関数を実行させていたのだが、同じドメインのときはXMLHttpRequestに切り替えてしまっていたようだ。それが証拠に、同じドメインで動かしている時だけ、リクエストヘッダーに
X-Requested-With:XMLHttpReques
がついていた。
それでも、IE以外のブラウザではなぜ問題なくデータを扱えていたのか謎ではある。
解決策としては、
jQueryのajaxメソッドのパラメータにcrossDomain:trueを設定することだ。これで、同じドメイン下でも強制的にクロスドメイン対応させる。
$.ajax{
url:'http:www.example.com',
dataType:'jsonp',
crossDomain:true,
success:function(data){
}
}
ただし、古いjQueryには設定されてないパラメータらしく、バージョン1.3.2ではダメだった。執筆時での最新版1.9.1に変えたところ、問題は解消した。
またもやハマったIE対応だが、今回はIEだけの問題でもない気はするものの、元を正せばIEがXMLHttpRequestとは違う独自仕様を採用したことが根本原因な気がするので、やはりIEはシネ
iPhoneで複数の宛先に送信済みのメールを、同じ宛先で再度送信する方法
CCやBCCで一度に複数の宛先に一斉送信したメールを編集して再度送信したい場合にどうするか。一般にガラケーでは送信済みのメールを再編集できるのだが、iPhoneでは再編集機能がなくて戸惑うが方法はある。
ウェブ上の質問サイトなどではできないとして、代替案として送信済みの本文をコピーして、新規メールに貼付ける方法を紹介するというトンチキな回答をしている輩がいるが、やりたいのは「本文を使い回す」のではなく「大量の宛先を使い回す」ことなのだ。同じ面子に追加の連絡をしたい場合があるだろうって話。
方法は、送信済みのメールで、「再送」をすることだ。下部のメニューアイコンのうち矢印のついた返信/転送系メニューの中に入っている。「再送」ボタンを押しても、即座に送信済みと全く同じメールが送信されるわけではないので安心してほしい。メール宛先と本文が挿入された新規メール編集画面が立ち上がる。
iPhoneで数字10桁を超えると表示がおかしくなる
iOSのバージョンが古いもので見ると、数字10桁を超えた部分の表示がおかしくなる謎の現象に悩まされていた。
原因は、Mobile Safariが数字のつらなりを電話番号と解釈して自動で<a>タグでマークアップしていたためだった。当該要素のaタグにつけていたcssが利いて意図せぬ表示になってしまっていたのだ。
mobile safariで電話番号を自動解釈することは知っていたが、レイアウト崩れの原因がそれとは思い当たらなかった。表題のような現象として検索しても出てこなかったので、メモしておく。
対策としてはhead部分に下記のmetaタグを仕込む。
<meta name="format-detection" content="telephone=no" />