アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
mb_send_mail の挙動が (スコア:0)
php.ini で mbstring.language = Japanese
が有効になってないと化けるらしいっす。今までは無くても動いていたとかで、実装が変わったからですかね。
PHPってユーザー数だけは多いけど人柱も足りて無さそうで掲示板もメーリングリストもFAQやPHP以前の質問で溢れかえっていてユーザー数は多くても貢献が全然無い、、っつーか初心者がイナゴの如く資源や場所を食いつぶしている雰囲気。この
Re:mb_send_mail の挙動が (スコア:1, 参考になる)
mbstringはソースの文字コードを指定可能にしたり、日本語以外のサポートをしたり、守備範囲を広げるために仕様を追加してきたんでしょうが、CHANGELOG以外にそういった公式のアナウンスの場所がないのが、周りから見るとどうなっているのか分かりにくくなる原因なのでは?
Re:mb_send_mail の挙動が (スコア:1)
PG 組んでもその通りにならない事が多い気がします。
# 日本語マニュアルで当たりをつけて、
# サンプルを借用してみて NG で、
# 英語のマニュアルを読んで、
# サンプルを借用してみて NG 。
# んー、がっくし。
# やるき 30% ダウンで TRY & Error 突入。
# って事が多かったです。
Re:mb_send_mail の挙動が (スコア:0)
自前で管理する分なら自前でビルドするのも手ですが、客先に納入する場合は
バージョンアップに対応できなくなるのでそうもいかなかったりしてちょっと
不便。 って、これはPHPの問題じゃなくてディストリの問題ですねw
人によっては「これが必須!」ってモジュールがRPMによっては入ってたり
入ってなかったりするのもちょっと問題かもしれません。このへんは
PHPは簡単だけど難しいと思える(私が個人的にね)要因ではないかと思います。
#自分でビルドすべしとか、自分でビルドできない奴は以下略
#と突っ込む人が多そうだ(w
#人によって必須モジュールがバラバラになりそげなので
#場合によっては最適な環境を構築するのが難しい時もある。
#といいたいだけなのでAC
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の構築もありですが
問題なのは、メンテ契約がいつまでもうちでは無い可能性の事も考えて、
そうなっても問題なく他の会社(又は他の人間)がメンテできるような
手段を考えておかなければいけないという事なので難儀です。
そうじゃないと何かトラブルがあった場合、トラブル対応要請がやってくるので
その間他の仕事が出来なくなり商売になりません(w
Re:mb_send_mail の挙動が (スコア:0)
PECL ? (スコア:1)
なにか、参考になるポイントを示せれば良いのですが。
Re:mb_send_mail の挙動が (スコア:0)
バージョン毎にバイナリ(gd.so とか ming.so とか pgsql.so)
をコマンド一発で組み込みとか可能なんでしょうか?
php PECL でググってみましたが直接「これだ!!」的な
情報にたどりつけませんでした(^^;