MysqlからPHPでデータ抽出した値が文字化けする場合の対処法です。
最近はWordPressの普及もありUTF-8が一般的になっていますが、さくらインターネットなどの一部サーバーではまだEUC-JPが使われていたりして、文字化けに頭を悩ますことになります。
Mysqlから抽出したデータが文字化けした場合は、Mysqlと接続するときに下記のように設定してあげれば文字化けしなくなるはずです。
$conn = mysql_connect(データベースのホスト名,アカウント名,パスワード);
mysql_query("SET NAMES utf8",$conn); //ここで文字コードを設定!
mysql_select_db(データベースのホスト名,$conn) or die("データベースがありません");
2行目の「utf8」をあなたの環境の文字コードに変えてください。いま思ったけど、「utf-8」じゃなくていいのかな?ハイフンいらないのかな?
まぁ問題なく化けなくなったからいいけれど。
もしも文字化けで悩んでいたら試してください。
また更新を1ヵ月も止めてしまいました。
飽きっぽいのが悪い癖です。これからはちょっとしたことでもいいから、ちゃんと更新できるようにがんばります。
目指せ1日1記事!
「目指せ」とか言ってる時点で望み薄ですねw
今回はCakePHPです。最近仕事でCakePHPやWordPressを使って情報サイトを作ったので、その辺の更新が増えるかも、です。
ここから本題です。
さくらインターネットのサーバーはMysqlの文字コードがEUC-JPのため、普通にCakePHPを使うと文字化けしてしまいます。
そんな時は、app/config/database.phpの中で下記のように指定してあげれば文字化けが直ります。
’encoding’ => ‘utf8′;
上記の「utf-8」のところはあなたの環境に合わせて変えてください。Shift-jisを使っている場合は「Shift-jis」に変えてね。
もう文字コードはUTF-8が基本になっているような気がしますが、さくらインターネットはEUC-JPが基本なので最初はいろいろと手間取りますね。
次回はさくらインターネットのサーバーを契約しているけれど、CakePHPでなく普通にPHPベタ書きでデータベースからデータを抽出したときに文字化けしたときの対処法を説明します。
ではまた。
ある案件で、プルダウンメニューの下にFlashを配置するウェブサイトを制作しました。
こういった状況で必ず問題になるのが、JavaScript(HTML)がFlashの背景に隠れてしまう、というものです。Flashはz-indexを認識しないため、CSSで重なりの設定しても効果がありません。
そんな場合の通常の解決策が、flashを設置しているタグにwmodeのtransparentを指定してあげるというものです。
●objectで指定する場合は下記を追加
<param name="wmode" value="transparent" />
●embedで指定する場合は下記を追加
<embed wmode="transparent"... />
●swobject.jsを使っている場合は下記を追加
so.addParam("wmode", "transparent");
この解決策にもデメリットがあり、Flashの中に入力要素があったりすると入力できなくなったりするそうです。
まぁ私の案件ではFlashは単純にonclick等で動かすだけのものだったので、特に問題なしと思っていました。
が、先日問題を発見。
windows版safariのバージョン4.0以降で見てみると、上記指定が効いておらず、プルダウンがFlashの背景にいってしまいます。
調べたところバージョン3.0では問題なかったようです。
海外のサイトを含め、かな~り調べて試しましたが、7月9日現在根本的な解決策は見つかっていません。
ただ、ここまでの調査で分かっているのは下記のとおりです。
・windows版safariのバージョン4以降で発生。mac版では問題ない。バージョン3以下でも問題なかった可能性大(他のサイトの情報から)
・IE6、IE7、IE8、Firefox2、Firefox3、Google Chromeでは問題なし
・インストールされているFlash playerが新しければ問題なし。10.1であれば問題が発生しないのを確認。
とりあえずはFlashのバージョンが新しければ問題ないので、win版safariのシェアも低いことですし今回はそれでなんとか収まればよいのですが。。。
根本的な問題解決策は、今後も探してみようと思います。
もし解決策をご存じの方がいらっしゃいましたら教えてください。m(_ _)m
【追記】
解決策、なし。まぁFlash更新されりゃ問題ないからいいでしょう。
先月会社でipadを買いまして、そのレビューというか、ちょっと触ってみた感想を公開しました。
社長に「ペンキチくん、うちの会社概要のe-pub作っといて」といわれて、簡単に作ったりしたのですが、やっぱりAppleカッコイイ。ステキ。
そんなわけで、PHPとJavaScriptだけじゃなく、やっぱiphoneアプリ作れなきゃダメだよね!と思い制作に乗り切りました。
1、思い立ったが吉日男なので、さっそくmacbook proを購入。
いきなり会社の先輩と新宿ヨドバシに突入。macbookと迷ったのですが、放熱性を考慮してproにしました。
全然熱さが違います。これ、非常に重要。
会社のデスクトップと並べてみたの図。
2、iphoneアプリ制作セミナーに出席
その週末にiphoneアプリ制作勉強会に出かけたのですが、勉強会というよりも「場所貸すからみんなで勝手に作って!」という感じでした。
iphoneアプリ制作どころかmacすら満足に使ったことない私は完全にチンプンカンプンで、あえなく途中退席。あぁ無念。
3、書籍購入
こうなったら自分でやるしかない。と思ってその勉強会の帰りに新宿紀伊国屋に訪問。
勉強会中にオススメの書籍を調べておいたので、その書籍を購入。これです。良書良書書かれていたので迷いなく購入。ちょっとくらい中見て買えという感じもするが。
4、本を片手に勉強&制作開始
会社でソッコー仕事を終わらせ、本片手に制作。以下、ハマったところを書きます。
●X-codeの使い方がわからん。
X-code、interface builderとかの使い方がサッパリわからん。というか全部英語てw そろそろ日本語化されててもいいじゃんか。
●文字サイズの文字間スペースの広げ方がわからん。
教えてgooで聞いてみたところ、Labelは広げることはできんということ。うーん。。
●iphone developer center(?)への登録とか、いろいろな手続きがチョー大変。
なんで全部英語なんだよ・・・しかも詳細をWebで公開することを規約で禁止してるもんだから、ちゃんとしたドキュメントがあんまりないでやんのww
案の定エラーが出てAppleサポートに連絡しました。のへー。
●Object-Cって。。。
いいもんC勉強するからいいもん!
5、というわけで完成
●全体日数:1週間
●実作業日数:丸1日
こんなのできました。1日にタバコを吸った本数をカウントするアプリ。着々と死へと進む、みたいな。
クリックすると数が増えて、ドクロマークがこんな感じに。ボタンの色が若干変わって背後に×印のタバコが現れます。
「C」をクリックすると数字がゼロに戻ります。
数字のマージンが気になるところだけれど、ちょっと作り方を間違えて直せなかった。次から気をつけます。
これだけだと「で?」って感じですが、やってること自体は単純なプログラムでも見せ方とコンセプトをちょっと変えることでいろいろ新しい世界が見えてくるのではないかと思います。
まぁ最初のとっかかりなのでこんな感じでしょう。
Object-Cさっぱりわからないまま、プログラム自体は本からまんま取ってきてなんとなくで作ったので、
次回からちゃんとしたものを作るためには習得必須ですね。
6、とりあえず作ってみての感想
制作自体に関しては、Object-Cが分かれば意外とサクサク作れると思いました。Object-Cが出来なくてもオブジェクト指向やフレームワークの概念を理解していれば本片手で結構いけるかと。
ただ、Interface builderが慣れるまでどこに何があるのかサッパリだなと思います。やっぱり日本語版が出てほしい。。。
また、一番面倒だったのはAppleの登録手続きでした。こちらに関しては下記サイトが非常に参考になりました。
http://ameblo.jp/micro-garden/entry-10308925350.html
http://report.station.ez-net.jp/registration/apple/iphone_dev.device.asp
とりあえずこんな感じ。その4くらいからオリジナルかな??という感じ。もっと頑張ります。
気がついたら全く更新してませんね。
いえね、実は裏側ではだいぶいろいろ動いているのですが、チョコチョコしたことではなく結構でかめのことをやっているので、あまりこちらでちょくちょく公開できる感じでもないのですね。
まーそれはそれとして、気をとりなおしてブログ再開していきましょう。
脱引きこもりプロジェクトの第三弾か四弾として、PHPセキュリテイセミナーに参加してきました。
昨日全然寝てないもんだから、セミナー中に寝そうになってしまい「おぉ、これはウッカリ」と思って回りを見たらけっこうチラホラ寝てました。
まぁそれだけ基本的な内容だったとも云えるかもしれません。オライリーで勉強したことそのまんまという印象でした。
とはいえ、自作CMSをスパムにフルボッコにされた経験を持つ私としては、体系的におさらいが出来て有意義でした。
以前自分がまとめたものと合わせて、再度自分のためのおさらいとしてまとめようと思います。
<ul class="参考にした資料">
<li><!-- プログラミングPHP 第2版(オライリー) --></li>
<li><!-- 入門 PHPセキュリティ(オライリー) --></li>
<li><!-- PHP逆引きレシピ --></li>
<li>PHPセキュリティセミナー(セミナー)</li>
</ul>
※2010年07月01日現在。随時更新予定
【第1:基本的な考え方】
———————————————————————————————————————————————————————————————————————
●多重防御 ・・・複数のブロックをつける
●最小特権 ・・・ユーザーには必要最低限のパワーを与える
●シンプル ・・・ シンプルはセキュリティ。複雑なソースを作らない
●データの流出は最小限に ・・・機密データの不必要な流出は避ける
●データの追跡 ・・・どのデ-タがどこから来てどこへ行くのかを意識する
■変数は必ず初期化してから使う
■基本はPOST送信。GETはページidなどだけに使う。
■データベース(個人情報)、ログ、ライブラリはドキュメントルート配下に置かない(置くと誰でも見れてしまう)
【第2:安全なphp.iniの設定】
———————————————————————————————————————————————————————————————————————
●逆引きレシピのP589参照
●およびセミナーの内容を追記
【第3:入力のフィルタ】
———————————————————————————————————————————————————————————————————————
●1、入力を識別する ・・・どれが入力されたものかを識別する
(フォーム、URL、セッション、データベースから来たものは全て入力)
●2、入力をフィルタする
・内容および範囲のチェック
※フィルタはホワイトリスト形式で行う
※フォーム(チェックボックスなども)、URL、セッション、データベースからの全てが対象となる
※パスワード一致など、文字列の比較は必ず===で行う
●3、フィルタ前のデータとフィルタ後のデータを明確に区別
・$clean_xxxx変数を初期化
・$clean_xxxx変数にフィルタ後のデータを入れる
【第4:出力のエスケープ】
———————————————————————————————————————————————————————————————————————
●出力をする際は必ずエスケープする
・HTMLに出力(print)する直前にエスケープ → $clean_xxxx = htmlentities($xxxx,ENT_QUOTES,’UTF-8′)
(一部のHTMLタグを許可したい場合はHTML purifierライブラリを使用する)
・データベースに入れる直前にのエスケープ → mysql_real_escape_strings()など
(‘※SQL文で使用する変数を’で囲まないと意味が無い)
【第5:クロスサイトスクリプション、SQLインジェクション、NULLバイト攻撃】
———————————————————————————————————————————————————————————————————————
●クロスサイトスクリプション(XSS)
(ユーザーの入力したデータをそのままHTMLに出力することで発生する脆弱性)
・print出力前のエスケープで対応
・$_SERVER[‘PHP_SELF’]の撲滅。代わりに$_SERVER[‘SCRIPT_NAME’]を使う
●SQLインジェクション(ユーザーが入力したデータをそのままSQL文として出力することで発生する脆弱性)
・SQL文出力前のエスケープで対応
●NULLバイト攻撃
(\0の文字で一部のバイナリセーフでない関数で発生する脆弱性)
・preg_matchでチェックする
if(preg_match(‘/\0/’),$sample){
die(“不正な入力です”);
}
【第6:セッションハイジャック対策、その他クッキー対策】
———————————————————————————————————————————————————————————————————————
●セッションハイジャック対策
(他のユーザーのセッションIDを乗っ取る攻撃)
・ログイン前後、権限レベル変更前後、DBの内容更新前後、SSLページへの偏移前後にsesson_regenerate_id(TRUE)でセッションを再生成する
・上記2のphp.iniの設定(セッション関係)を採用する
●セッションファイルの保存ディレクトリを他人がアクセスできない場所へ変更
(php.iniのsesson_save_pathで設定)
●setcookieの第7引数にtrueを入れて、JS経由のcookieへのアクセスをさせないようにする
【第7:CSRF対策】
———————————————————————————————————————————————————————————————————————
●CSRF対策
(サイトの権限を持ったユーザーに不正操作を実行させる攻撃)
・処理の前後でワンタイムチケット方式でのチェックをかます
(確認後、ワンタイムチケットに使用したセッションは初期化しないとあかんよ。)
【第8:ファイル関連】
———————————————————————————————————————————————————————————————————————
●ファイルが本当にアップロードされたものかどうかis_upload_file()でフィルタし、ファイルの移動も move_uploaded_file()を使う
●独自のファイル名に変更する
●もしも独自ファイル名に変更できず、ままのファイル名を採用しなくてはいけない場合は、basename()とrealpath()でチェックする(ディレクトリトラバーサル対策)
●ファイルのMAXサイズを決める
———————————————————————————————————————————————————————————————————————
7月1日時点では、セミナーで話してた内容だけをまとめているので、これから他の資料から学んだセキュリティのポイントも追加していって、結構まとまったものにしようと思います。
10日までには上に記載した書籍のセキュリティ関係の内容をすべて網羅した感じにします。