草稿だってもうちょっとマシなものよ？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/
ご無沙汰だわ。…ええ別にあたくしも何もしてなかったわけじゃないんですけれども。ちょっとデスマーチでえらいことになってたわ*1。
で、そんななか。相変わらずドラフト感満載のPHPがまたしても素晴らしい状況になってきたわ。
ちょっとURLがURLなので…出来るだけ引用を控えつつ、切り刻んで差し上げても よろしくってよ？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/ より
【PHPウォッチ】第26回 重大な不具合を修正した5.1.3/5.1.4のリリースと，PHP 5.2の開発スタート
…タイトルからして大概な内容だわねぇ。ま、じっくりとチェックしてみましょ。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/ より
PHP5.2の開発がスタート
ええスタートしたこと自体を喜ばないではないんですけれども。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/ より
PHP 5の現在の最新版は，PHP 5.0系にスクリプトエンジンレベルの性能改善とPDOの追加を行ったPHP 5.1系である。現在，新しい機能は開発版(PHP 6)に取り込まれ，PHP 5.1系では主にバグ修正のみが行われている。Unicode対応が行われるPHP 6のリリースは当分先となることから，PHP 5系に新機能を追加するためにPHP 5.2のリリースが計画された。
…この「PHP 5系に新機能を追加するため」って部分に物凄い戦慄を感じてしまうのはあたくしだけなのかしら？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/ より
PHP 5.2は，今後，数カ月のうちにリリースされる見込みである。PHP 5.2.0のリリース後，PHP 5.1系については(致命的なバグがない限り，)PHP 5.0系と同様に新たなリリースは行われない見込みである。
って部分もまた怖いわねぇ。「PHPの新しいバージョン」なんて物騒なモノ、よっぽど充実したテスト環境*2がなきゃ手を出せないでしょうし。
かといって「致命的じゃないと言い張るバグ」が修正されないままの古いバージョンを使うのもちょっとした自殺行為ってものだわ？
ええもちろん「PHPをチョイスした時点で十分に自殺行為」ってお話もあるんですけれども。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/ より
PHP 5.1.3，PHP 5.1.4相次いでリリース
PHP 5.1.3が4月28日に正式公開された。このバージョンでは，PHP 5.1.2のリリース以降に見つかった130件以上のバグが修正されており，若干の機能追加も行われている。
-中略-
しかしながら，PHP 5.1.3のリリース後に，マルチパートMIMEエンコードされたPOSTパラメータを正しく取得できないという致命的なバグが見つかり，急遽，PHP 5.1.4が5月4日にリリースされた。PHP 5.1.4ではこのバグを含む６件のバグが修正されている。
すごいわねぇ。何がすごいって「この状態でリリースをかけている」あたりが壮絶だわ。MSの「リリース直後はベータ版」に迫る勢いじゃなくってかしら？*3
こんな状態で
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/ より
PHP 5.1.4では，セキュリティ上の問題を含む多くのバグの修正が行われている。PHP 5を使用するユーザーは早期のバージョン更新が推奨されている。
っていわれても、怖すぎてとてもじゃないけど手もだせなくってよ？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/?ST=lin-server&P=2 より
不正にエンコードされたバイト列を検出する関数追加
シフトJISなどバックスラッシュ(0x5c)をマルチバイト文字の一部に含む可能性があるエンコーディングにおいては，不正にエンコーディングされたバイト列によるSQLインジェクションを行われる危険性がある。
例えば，0x95,0x27 というバイト列にaddslashes()関数(またはmysql_real_escape_string()関数など)を適用した場合，引用符 (0x27)がバックスラッシュ(0x5c)によりエスケープされて0x95,0x5c,0x27というバイト列になる。この際，0x95,0x5cは「表」というシフトJISのマルチバイト文字となるため，シフトJISの文字列としてデータベースに入力される場合には，引用符(0x27)はエスケープされない状態となってしまう。
そうねぇ。なんか如何にも「本来の目的とは違う使い方をしているために結果的に不具合が起きている」げな書き方なんですけれども。
http://php.s3.to/man/function.addslashes.html より
addslashes
(PHP 3, PHP 4, PHP 5)
addslashes -- 文字列をスラッシュでクォートする
説明
string addslashes ( string str )
データベースへの問い合わせなどに際してクォートされるべき 文字の前にバックスラッシュを挿入した文字列を返します。クォート されるべき文字とは、シングルクォート('), ダブルクォート("),バックスラッシュ (\) ,NUL (NULL バイト) です。
っていうマニュアルの文章とかってのはどんな風に考慮されているのかしら？
こんなおっかないバグを平気で抱えているような言語が
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/?ST=lin-server&P=2 より
PHP 5.1.3以降では，不正にエンコードされた文字列を検出する手段としてmb_check_encoding()とmb_get_info (“illegal_chars”)が追加された。mb_check_encoding()は不正にエンコーディングされた文字が含まれている場合に FALSEを返す関数であり，以下のように使用する。
なんて話をしたとして、一体だれが信用するっていうのかしら?
ドンファンの甘いささやきは「それが嘘だってわかっていてなお」騙されるのが楽しいからこそ甘いのよ？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/?ST=lin-server&P=2 より
PEAR 1.5の開発がスタート
パッケージマネージャや基底クラスなどPEARレポジトリのコアコンポーネントである PEAR 1.5の開発開始がアナウンスされた。PEAR 1.5では，PEAR 1.4におけるチャネルのサポートに相当するような大きな変更は行われない見込みである。
そうねぇ。あたし的には改良ってよりも設計のしなおしを要求してみたいものだわ。とりあえず「global変数使う」ことをいい加減やめてみては如何かしら？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060508/236988/?ST=lin-server&P=3 より
Zend Framework関連情報
PHP用フレームワークの標準となるべく開発が開始され，3月3日にプレビュー版（詳細は前回のPHPウォッチ参照）が公開されたばかりのZend Frameworkであるが，引き続き精力的に開発が行われている。日本語版のプログラマ向けリファレンスマニュアル*4も公開され，習得も容易になっている。Zend Frameworkの開発状況について以下に紹介する。
そうねぇ…ソースまで多少は読んでるんですけれども。……あまりの惹かれなさっぷりが逆に素敵にすら見えてしまってよ？
ま、いつみても「多くの企業サイトで用いられているとは到底信じがたい」完成度って感じだわね。
根本的に言語仕様がおかしい上で無駄に便利につくろうとしてゴミゴミした上で実装上のバグに満ち溢れたところにまとまりのない増改築を繰り返してる、って感じかしら？
とはいえ、あたし的には「やるならとことん」って姿勢は嫌いじゃなくってよ？ どうせなら「史上もっとも普及した"駄言語"」として精進していただきたいわ。
そうしたら、またあたしが丁寧に突っ込んで差し上げても よろしくってよ？
