ふぁいんどぱわー　調べる人の冒険！（チラシの裏よりチョット上）

　またまた環境を一部環境を見直す話です。
今回は文字コードについて見直しします。

　文字コードというのは色々あり、表現できる文字の種類も違い、
そして文字コードを他の文字コードに変換しようと思うときに、その種類の違いが
変換できない文字を生んだりして困る様です。

　また、文字コードを他の文字コードと間違って解釈すると文字化けの原因に
なる様です。

　そんなこんななんですが、私が一番初めに手にした
ろくでもないPHP の入門書は、Windows 標準のメモ帳 で、
S-JIS を用いて書く方法を書いていて、
Web上でWebページ としてページが生成されたりするには
Web上の文字コードに合わせなければならないので
その場合、今現在の流れではUTF-8 でWebページの内容を
書くことが一般的となりつつある様なので、この時点でシフトJIS（S-JIS）を
使っているのは面倒な事につながり兼ねません。

　そして上記の方にある様に無駄に文字コードを変換することは
文字化けの原因になる可能性もありますし、それ以外に
MySQL に保管する文字データも無駄に変換して用いるべきではないと思います。

なのでMySQL の文字の設定とPHP の文字の設定をもう一度見直す事に
なるのだと思います。

php.inオプション名	適応場所、結果	意味、概要	値の表し方と補足	該当関数
mbstring.detect_order	mb_detect_encoding 関数, mb_send_mail 関数の 文字エンコーディング検出順序	文字エンコーディング検出順序を設定。	文字コードで１種類以上、またはauto。 auto ならばASCII,JIS,UTF-8,EUC-JP,SJIS の検出順序。	mb_detect_order 関数
mbstring.http_input		HTTP 入力文字エンコーディングのデフォルトを設定。 入力をソース内部で指定した文字コードに変換する 場合に設定するが、元の	文字コード１種のみ。指定し何もしないpass を 指定したり、auto を指定したならばASCII,JIS, UTF-8,EUC-JP,SJISの検出順序で自動認識も 可能。	mb_http_input 関数
mbstring.http_output	mb_output_handler 関数で指定した 出力バッファ。 　また、mb_output_handler 関数 を用いたときに条件によって作られる charset HTTP ヘッダの値にも作用。	HTTP 出力文字エンコーディングのデフォルトを設定。 Content-type がtext/html である場合のみ出力変換が 有効になる。またmb_output_handler 関数などの 文字コード変換関数を用いなければ効力はない。	文字コード１種のみ。指定し何もしないpass を 指定も可能。	mb_http_output 関数
mbstring.encoding_translation		入力される HTTP クエリに関して、 文字エンコーディング検出および 内部文字エンコーディングへの変換を行う 透過的な文字エンコーディングフィルタの設定。	この値がOn であると入力されたクリエは mbstring.http_input で指定した 文字エンコーディングであると判断し、 mbstring.internal_encodingで指定した 文字エンコーディングに変換をします。 　色々な意味合いで、入力がどんな 文字エンコーディングなのかや、 マルチバイト文字の関数を用いるのかなどを 考慮して設定する必要があります。 　スクリプト内部で設定できるのであれば、 Off にして使用することが可能です。	公式サイト（HTTP 入出力）に、 「PHP スクリプトで HTTP 入力文字変換を制御する 手段はありません。」 とあるので注意が必要。 （php.iniが書き換えられない環境 の場合にはApache の設定で、 php_value mbstring.encoding_translation Off を設定する）
mbstring.internal_encoding	各マルチバイト文字の 関数で元のエンコーディング 種類が必要な関数。 mb_convert_encoding 関数, mb_convert_kana 関数などで 引数がない場合に使用。 mb_decode_mimeheader 関数では 必須となるがソース内で該当関数で 指定可能。	内部エンコーディングと呼ばれているが、 関数内部で必要な時に使用される 暫定（既定）の文字エンコーディングの事。	文字コード１種のみ。マルチバイト文字列系の 関数を使うときに自身で値を設定するのならば、 注釈にしてしまい用いない事も可能。	mb_internal_encoding 関数
default_charset	自動で生成される環境設定の場合、 charset HTTP ヘッダのContent-type: の文字エンコーディング種別。	Content-type:ヘッダで character encodingを 出力する。	PHPの処理はWebページ向けの処理のみでは 無いので、この設定が問題を発生させる場合は 値を空にして、charsetの送信設定を無効に 出来ます。 またWeb系の出力の場合にこの値を 空である無効にした場合には、header 関数で 値を指定する必要も考慮が必要になります。	（header 関数）
output_handler	最終的な文字コーディングを必要と した場合、フィルタとしてコールバック 関数を用いた後の出力の内容変化。	出力する最終段階で内容を自動的に指定した 関数に送り処理させ、その関数の出力を最終出力 とする設定。（つまりこの事をリダイレクトと言う） 　つまりバッファを用い、文字エンコーディングを 他の文字エンコーディングに変える事を、 関数を選んで指定できます。	関数名もしくは空の値。 例としては、 "ob_iconv_handler"か"mb_output_handler"  や "ob_gzhandler()"か"zlib.output_compression" 　PHPのバージョンによっては、 イメージのようなバイナリデータであるのに Content-Type: をheader 関数を用いて指定や、 バージョンや環境設定においては、 mb_http_output をpass に指定しなければ バイナリデータがうまく処理できない場合が あります。	コールバックとしての mb_output_handler 関数  （実体は ob_start 関数）

mb_detect_order
編集中

PHP の初心者の枠から未だに抜け出られない状況にいる私です。

色々考えたのですが、本とか読んで仕組みとかライブラリの種類を判ったとしても、
なんだかうまく扱えない感じがしていました。

それはPHP のコードが書ける程度のエディタを使っているだけでは、
効率が進まない、自身の書いたコードの不具合、つまり、
バグや単純な人為的ミスの打ち間違いや書き間違いに気が付かない、気が付きにくい。

これだけの事で進む能率がとてつもなく変わる、時間の無駄になる。

　そもそもそれに気が付いたのは、私はＶＢ（Visual Basic 6.0）なら基本的に
Ｗｅｂの情報などを用いて何でも適当にある程度作れるますが、
現状の私のPHP 環境の様に無駄に進まない、気軽にコードを打ち込んで試せない、
そんな状況にはならないのです。

　これは何が悪いのかを考え、色々調べてみると、統合開発環境は
とても重要なのだという事を実感しました。

　これはブレークポイントを設置するデバッグや、コードの見通しが利く見え方、
ファイル単位やプロジェクト単位、関連付け、エラーチェック、
コード内の関数定義場所へのファイルをまたいだジャンプ編集、
色々あると思います。

　色々調べた結果なのですが、テキストエディタで自分がミスをしない事や
記憶力だけを当てにした開発や制作、作成をしているよりも、
気軽に思いつきどおりに何かを作り出せる事の方が、
クリエイティブな環境なのだと思い、これ自身が私の求める物だろうと
確信的な想像が付いたので、やっとでありますが、動こうと思います。

長ぁ～～～～～い前置き終わりっ！ｗ

---

PHP の統合開発環境を探してみた。

---

　さて、PHP のエディタだけではなくて、ちゃんとデバッグやソースに関連付けられたファイルの
変数や関数まで把握してくれる統合開発環境を求めて、色々探してみました。

　ここで連ねて書いても良いが、迷った事を残してみようと
思っていたが、時間が足らないのと、不必要な調べ物は消して手元に無いので、
ほとんど他のサイトを見て得た知識なので、そのリンクを書いておこうと思う。

【コラム】イマドキのIDE事情 (5) もうひとつの無償IDE - "Oracle JDeveloper"を試してみる | エンタープライズ | マイコミジャーナル

　一応今回は説明が少ないですが終わりにして、
そのうち私がPHPの統合開発環境として使ってみようと思っている
Eclipse PDT (PHP Development Tools)を触って、日本語化できたら
その事のメモでも残そうと思う。

　なにやらPHP5.3以降でエラーレベルが増えたそうな・・・・

前回はバージョン違いのPHP はエラーを吐いて邪魔をするｗ というブログを書いた気がｗ

そのときは
「 Strict Standards: Non-static method 」の後に何か続く物で、
エラーレベルが問題でphp.ini で、
[変更前]
error_reporting = E_ALL | E_STRICT
[変更後]
error_reporting = E_ALL

です。
つまり、＜E_STRICT＞をカットするとエラーメッセージでの情報は出なくなったと書きました・・・

しかし！甘かった様です。

元々＜E_ALL＞ は全てのエラーを表示するものを意味していると公式のサイトの定義済み定数 では
書いてあり、それと同時に全てとはありますが、＜E_STRICT＞ とは別と書いてあり、
前回の「Strict Standards」のエラーは
＜E_STRICT＞（コードの相互運用性や互換性を維持するために PHP がコードの変更を提案する。PHP5より）
が原因のエラーであった為、＜E_ALL＞ と重ならない為にエラーが表示されない状況を
簡単に作ることが出来ました。

しかし、今回のエラーの
「Deprecated: Assigning the return value of new by reference is deprecated in」で続くエラー
つまり「Deprecated」のエラーは、PHP5.3 からあるエラーレベル、
＜E_DEPRECATED＞と＜E_USER_DEPRECATED＞のどちらかに引っかかる様なのです。

私は英語は出来る人ではありませんがｗ
とりあえず、「Deprecated: Assigning the return value of new by reference is deprecated in」の中に
「return value of new by reference」と言う言葉があり、これはたぶん間違えなく、
公式サイトのマニュアルにあるPHP 5.3.x で推奨されない機能 の
推奨されない機能＞＞　new の返り値を参照で代入すること 　＜＜
まさにコレ！なのだと思います。

　なので結論から入ると、PHP5.3 のエラーレベルによって出てしまう邪魔なエラーは
E_ALL をやめて、ばらばらなエラーを結合して使うしかなさそうです。

また、公式の定義済み定数 を見た方が明確なのですが、バージョンの部分や詳細説明を省いて簡単にして
書いていました。

1     E_ERROR              重大な実行時エラー。
2     E_WARNING            実行時の警告 (致命的なエラーではない)。
4     E_PARSE              コンパイル時のパースエラー。
8     E_NOTICE             実行時の警告。
16    E_CORE_ERROR         PHPの初期始動時点での致命的なエラー。
32    E_CORE_WARNING      （致命的ではない）警告
64    E_COMPILE_ERROR      コンパイル時の致命的なエラー。
128   E_COMPILE_WARNING    コンパイル時の警告（致命的ではない）。
256   E_USER_ERROR         ユーザーによって発行されるエラーメッセージ。
512   E_USER_WARNING       ユーザーによって発行される警告メッセージ。
1024  E_USER_NOTICE        ユーザーによって発行される注意メッセージ。
2048  E_STRICT             コードの相互運用性や互換性を維持するために PHP がコードの変更を提案する。
4096  E_RECOVERABLE_ERROR  キャッチできる致命的なエラー。
8192  E_DEPRECATED         実行時の注意。
16384 E_USER_DEPRECATED    ユーザ定義の警告メッセージ。
30719 E_ALL                サポートされる全てのエラーと警告。

ここからPHP5.3 のエラー以外をE_ALL から出してみるという手を使うなら、
E_STRICT は任意（多分これをしている人には必要ないと思うが）で
追加するかどうか決めれば良いがそれ以外はですね・・・

つまり・・・ｗｗｗｗｗｗｗｗｗｗｗ

php.ini の設定にですね・・・・・

error_reporting = E_ERROR|E_WARNING|E_PARSE|E_NOTICE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|
（長いので改行してあります。）
E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_USER_DEPRECATED
っていう御馬鹿な設定をすれば私好みにきっとなるハズだ！と思っていますｗ

とりあえずまだやっていませんが、あまりにも眠いのに・・・　眠いのに・・・　書いたメモなので
コレぐらいで簡便してやろう！（して下さいｗ）

まぁこのブログに追伸などがなければ設定がＯＫだったか飽きたと思って下さいorz

セキュリティーなどの為にバージョンは上げる事をうたい文句としている様な雰囲気が
PHP に見られるが、バージョンによってエラーレベルが増えて、
エラーレベルは結局調べないといけなくなるので、
結局人それぞれ自身が使うライブラリや、自分の書いたプログラムに
合わせて全てオプション設定を書いた方が良いと思いました。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上。

---

---

error_reporting = E_ERROR|E_WARNING|E_PARSE|E_NOTICE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|
（長いので改行してあります。）
E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_USER_DEPRECATED

でPHP5.3 のエラーは出ない様になりましたー！確認済み

それはそうでしょう。PHP5.3 のエラーと＜E_STRICT＞を取り除いた物なので
うまく行ったのでしょう。

大体PHPのマニュアルがあってもなかなかしない、もしくはしたくない、したくなくなる様な
オプションの量ですよね＾＾；


　後ですが、このやたら長い書き方以外にも

error_reporting=E_ALL&~(E_NOTICE|E_DEPRECATED)

でE_ALL からPHP5.3 の＜E_NOTICE＞＜E_DEPRECATED＞を使わないで済むのがわかりました。

　php.ini の設定でも書式が使えるとは思ってませんでした。
良く考えたら「 | 」も書式でした、なんだかまだまだ覚える事はいっぱいありそうです。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　追伸終わり

　まぁ個人的な頭の中をまとめる為のメモです。

　PHP でデータベースを扱う方法は色々ありますが、
色々調べてみると自分の好みがわかってきた気がします。

①多分私が好きな方法は、ライブラリ などを挟まない、
各データベース固有の低レベルアクセス、つまり高速であり、
セキュリティー対策まで自分でしなければいけないが、
自分が作っている上では見通しの良いもの。

②エラーが出たときにライブラリの内部などを示し、
デバッグが容易に感じられ、しかも高速でPHP 5.3.2 で
標準でついているPDO が好み。

この２種類が好みだと思った、そしてなんだかPEAR は便利な部分が
有るのかもしれないが、PHP の成り立ち方や、公式ＨＰの説明の仕方、
そしてその他の本やＷｅｂ上のサイトによる説明の仕方で、表面的に
種類を述べているだけではなくて、困った時の対処の仕方まで説明が
してある物を見つけるまでは、PEAR は触る程度で置こうと思った。


　とりあえずはPDO をセキュリティーの為は汎用性の為に用いると思ったので、
PDO を使う為の設定をメモしておこう。

php.ini で
extension=php_pdo.dll (私の5.3.2 では元々入って無い様です。無くても動きました、理由は不明です。）
extension=php_pdo_mysql.dll
の注釈をなくし有効にするか、または注釈が元々なければ追加する。

( ..)φメモメモ以上