PHP 4.3.3 リリース 30
ストーリー by Oliver
BSDライセンスも楽ではない 部門より
BSDライセンスも楽ではない 部門より
Anonymous Coward曰く、"PHP4.3.3がリリースされた模様（リリースノート、変更点一覧)。相変わらずのバグフィクス中心だが、Expatの同梱バージョンが1.95.6に、PCREの同梱バージョンが4.3に、GDの同梱バージョンが2.0.15に更新されている。
また、ここでも話題になったライセンス問題に関してのその後は、日本PHPユーザー会の見解を参照されたい。"
multipart/form-data の挙動が変更に (スコア:2, 参考になる)
フォームデータは mbstring.encoding_translation = On
になっててもエンコーディングはコンバートされませんで
したが、4.3.3 では internal_encoding へ自動的にコン
バートされる様です。
加えて、type="file"でアップロードされるクライアント
マシーンでの元ファイル名($_FILES['????']['name'])も
同様にコンバートされてしまいます。
4.3.2->4.3.3 のマイナーバージョンアップで変更される
部分としては大きすぎる気がします。
ChangeLog にも
Fixed corruption of multibyte character including 0x5c as second byte in multipart/form-data.
としか書かれてないし。
本当にラッパーしてる人です (スコア:0)
って、なんだか凄まじく本末店頭でありすまぬ。
↓仕様変更はせめてメジャーバージョンアップの時だけにして欲しいと思う人の数
Re:multipart/form-data の挙動が変更に (スコア:0)
になってても変換されなかったバグが
Fixされたということではなくて、仕様の変更なの？
Re:multipart/form-data の挙動が変更に (スコア:0)
どちらにしても ChangeLog に書くべきことかと
Fixされたと見なすにもenctypeでマルチパートに
した時としない時で動作が変わるはちょっとね
エンコーディングの変換処理が同じでなさげ
鬼車って (スコア:0)
Re:鬼車って (スコア:0)
それとPCREの方は国際化って進んでいるか？前はUTF-8 supportもボロボロだったような記憶があるが。
Re:鬼車って (スコア:0)
Re:鬼車って (スコア:0)
Re:鬼車って (スコア:0)
Re:鬼車って (スコア:0)
１つのプログラムで条件コンパイルで２つのREGEXエンジンを切り替えることはありえますね。
そしてその時関数名が同じでも引数や機能が違うと困るかと。
ネスケ4ユーザの哀しみ (スコア:0)
↓
http://www.php.gr.jp/project/i18n/css/style.css Not Found
↓
「日本PHPユーザー会の見解」が表示できない。
↓
ネスケ4ユーザは逝ってよしですかそうですか。
↓
（´・ω・｀）ｼｮﾎﾞﾝ
Re:ネスケ4ユーザの哀しみ (スコア:1)
EUC ? (スコア:1)
ISO-2022-JP を指定しないと mozilla で見れないのですが、
EUC-JP 指定であっていますでしょうか ?
# Mozilla 1.3
# Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Mozilla Firebirdでもいっしょ (スコア:0)
そうか、今の表示はスタイルシートが機能してなかったのか。
Re:Mozilla Firebirdでもいっしょ (スコア:1)
#386831さんは、それに当たったのでは？
Re:Mozilla Firebirdでもいっしょ (スコア:0)
mb_send_mail の挙動が (スコア:0)
php.ini で mbstring.language = Japanese
が有効になってないと化けるらしいっす。今までは無くても動いていたとかで、実装が変わったからですかね。
PHPってユーザー数だけは多いけど人柱も足りて無さそうで掲示板もメーリングリストもFAQやPHP以前の質問で溢れかえっていてユーザー数は多くても貢献が全然無い、、っつーか初心者がイナゴの如く資源や場所を食いつぶしている雰囲気。この夏はネタとしてか思えないポストが相次いで散々盛り上がったし。
仕事先でもPHPで出すと以前酷い物を作られたとかPerl,CGI,PHPって初心者が片手間にやるもんでしょみたいな反応で「いや、Javaでやってよ」とか言われる始末。
PHP自体は凄くいいポテンシャル持ってるのになんつーか、自助努力の無い初心者が泥のようにまとわりついてないかい。
Re:mb_send_mail の挙動が (スコア:1, 参考になる)
mbstringはソースの文字コードを指定可能にしたり、日本語以外のサポートをしたり、守備範囲を広げるために仕様を追加してきたんでしょうが、CHANGELOG以外にそういった公式のアナウンスの場所がないのが、周りから見るとどうなっているのか分かりにくくなる原因なのでは？
Re:mb_send_mail の挙動が (スコア:1)
PG 組んでもその通りにならない事が多い気がします。
# 日本語マニュアルで当たりをつけて、
# サンプルを借用してみて NG で、
# 英語のマニュアルを読んで、
# サンプルを借用してみて NG 。
# んー、がっくし。
# やるき 30% ダウンで TRY & Error 突入。
# って事が多かったです。
マニュアルの完成度が高くて素晴しいだけに、残念です。
# PHP で Java を動かすとか、
# 日本語の mail 送るとか。
# 苦労した気がします。
## ずいぶんと昔の事ですが。
Re:mb_send_mail の挙動が (スコア:0)
自前で管理する分なら自前でビルドするのも手ですが、客先に納入する場合は
バージョンアップに対応できなくなるのでそうもいかなかったりしてちょっと
不便。 って、これはPHPの問題じゃなくてディストリの問題ですねw
人によっては「これが必須！」ってモジュールがRPMによっては入ってたり
入ってなかったりするのもちょっと問題かもしれません。このへんは
PHP
Re:mb_send_mail の挙動が (スコア:0)
Re:mb_send_mail の挙動が (スコア:2, 参考になる)
deb や ports の完成度と rpm の完成度を
比較しても無駄だと思います。
結局 default のパッケージしか、入れることができずに、
rpm と変わらないという評価にしかなりません。
# default パッケージの upgrade ぐらいできたよね ? >rpm
まず、自前のパッケージを作成できるようにならなければ。
こちら [srad.jp]の方の場合、お客様環境用の rpm を作成できるようになれば、
技術的な問題の 60% ぐらいが解決すると思います。
残り 40% の内訳は 20% が rpm の馬鹿さ加減。
残り 20% が PHP の Version 間の互換性です。
この馬鹿さ加減を解決したくなった人には、
ports や deb を勧める価値があると思います。
あと 20% の互換性問題はパッケージでも解決できませんから、
コードを書いた人に頑張ってもらいましょう。
Re:mb_send_mail の挙動が (スコア:0)
＞技術的な問題の 60% ぐらいが解決すると思います。
そうですね、同意です。
ただ、いつまでも自分がメンテナンスできるのであれば独自rpmの構築もありですが
問題なのは、メンテ契約がいつまでもうちでは無い可能性の事も考えて、
そうなっても問題なく他の会社（又は他の人間）がメンテできるような
手段を考えておかなければいけないという事なので難儀です。
そうじゃないと何かトラブルがあった場合、トラブル対応要請がやってくるので
その間他の仕事が出来なくなり商売になりません(ｗ
Re:mb_send_mail の挙動が (スコア:0)
PECL ? (スコア:1)
なにか、参考になるポイントを示せれば良いのですが。
Re:mb_send_mail の挙動が (スコア:0)
バージョン毎にバイナリ(gd.so とか ming.so とか pgsql.so）
をコマンド一発で組み込みとか可能なんでしょうか？
php PECL でググってみましたが直接「これだ！！」的な
情報にたどりつけませんでした(^^;
Re:mb_send_mail の挙動が (スコア:1)
一貫性の無いプラットフォームでは、質問が投げられたとき、場当たり的な回答が返される。それだと、利用者の中で諸問題に対する一般化ができない。だから、理解が進まない。
質の良いプラットフォームだと、利用者が一つの疑問の回答をきっかけに、どんどんと理解が進む。だから質問は少なくなる。（重箱の隅をつつくような影響度の低いところでの話だけになる）
PHPは残念ながら一貫性のない（利用者の中でさまざまな理解のための補完を要求する）プラットフォーム。ドロドロとしているから、使う人の思考も泥のようになってしまうのだと思う。
Re:mb_send_mail の挙動が (スコア:0)
それがまた、趣味じゃ無くて仕事で行き詰まったポストだったりするケースが多々あって怖い。
そのくらい自分で解決できない奴が業務レベルのスクリプト書いてるんだなぁ。
Re:mb_send_mail の挙動が (スコア:1, 興味深い)
まずPHPで生成した文書をダウンロードさせローカルで開くと文字化けするというポスト、単にEUCの文書がメモ帳で文字化けという御粗末なオチ。
セッションが働かないというポストはWindowsでphp.iniの指定でセッションの保存先を/tmpにしていたというオチ。
マニュアル嫁な初歩的なインストールミスからPgsqlが動かないとのポスト、
他、文字コード関連のFAQ、メンテ終わって別パッケージに移行してるアプリケーションの質問、極度の知識不足にある常連さんからのポスト。
こんな感じでまともなポストの方が少ない状態で日々が流れていくような。また喜んで付き合うユーザーもいるから「PHPとは直接関係ないかも知れませんが~」なテンプレが流行っています。MUA何使ってるの？とかな。
部門名 (スコア:0)
この場合、BSDライセンスの方が制限がゆるいので、より厳しい制約のあるLGPLライセンス下のコードをBSDライセンスでは配布できないってことですよね。
ま、視点の問題に過ぎないのかもしれないけどさ。
# バイアスの問題？(笑)