カテゴリー別アーカイブ: php

php::inputタグに値が入らない何で。

inputタグの中身に値を押し込んでいるが入らない。

何でだろう?と思ってphpではまりけり。

htmlをよく見たらこんなになっていた。


<input type="text" name="onamae" value="" id="onamae" class="onamae" value="お名前">

(=_=;)...value属性が2つある…こういうのチェックするコマンドがあれば便利かもしれないと、
ふと思いました。まあ、気をつけろという話ですけど。。。

[PHP]DNSサーバの変更時にご注意を

soapのキャッシュを無効にしてhttpdを再起動したところphpのWebアプリケーションが動かなくなった。

file_get_contents(): php_network_getaddresses: getaddrinfo failed: Name or service not known in

設定を戻してhttpdを再起動しても動作せず…原因はdnsサーバの設定/etc/resolv.confのIPを存在するDNSサーバに戻した。

キャッシュが有効だったときは、過去に正常に動いていたときのDNSキャッシュを使用していたので動いていたようだ。

※よくある?なんでこんな設定で動いていたのかわからない系のエラーかと。

今年は平成何年度か?(phpサンプル)

今年は西暦2017年です。

平成が続いているとすれば平成29年です。

----------

ソースコード


今年は西暦<?=date("Y")?>年です。

平成が続いているとすれば平成<?=(date("Y")-2000+12)?>年です。

※よく今が平成何年かわからなくなる私のためにつくってみました。なお、平成を算出する式は上記のコードのとおり、現在の西暦から2000を引いてから12を加えれば求められます。
※元年にあたる西暦を引いて1を加えて求めてもいいようですが、現在の西暦の頭の部分をとっぱらって2桁の定数(12)を加えと覚える方がシンプルで覚えやすいと思います。ただこれだと100年単位で誤った数字が返りますけど…まあそれは2100年が近づいたら考えたらいいでしょう。私はその頃もう生きていないのでどうでもいい。。

参考
detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1137758541

crondでphpのfgetcsv関数が正常に動かない

叩いて動かす分には問題ないが、cronだとCSVの日本語がfgetcsvで動かない。

cronの設定ではよくある話。

パーミッションも問題ないのでおかしいなーと思ったら、
LANGという環境変数に応じてfgetcsv関数は動作がかわるとのこと。

export LANG="ja_JP.UTF-8"
batch.php

※cron設定時に(自分で叩いてデバックしてうまくいくことは確認すると思うが)、
 その時にcronで失敗する時は以下2点を疑うこと。
・環境変数の違いがないか。
・パーミッションに間違いがないか。

【参考】結構事例あり。
www.yuigahama.org/?p=370
tkuchiki.hatenablog.com/entry/2013/04/23/224125
yassu.jp/pukiwiki/index.php?crontab%A4%C7fgetcsv

[PHP]header関数でリダイレクトしても下部の処理は行われる

liginc.co.jp/programmer/archives/1140

よくよく考えればそりゃそうだ。headerが吐き出されてからクライアントでリダイレクト処理するのだから。

headerの下にある処理はすべて実行される。

これをexitやreturnやkillと同じステートメントと捉えてはいけないのだった。。。

session_start関数を実行していて、ブラウザにきちんとCookieも焼かれている。

…なのに次のページで復元できない。

サーバ側のセッション管理はsession_start関数はtrueを返しているから焼かれているはずだ…が、
指定のディレクトリにはセッション管理用の中間ファイルがない。

別のスクリプトで簡易セッション管理の仕組みをつくれば問題なく動く…非常に時間を無駄にしたが解決。

自分のあほさがいやになる。

なんか前にも嵌ったような嵌っていないような。忘れないようにメモしておこう。

もっとはやく気がつく脳にするにはどうしたらいいのだろう。

【PHP】POSTの上限(post_max_size)を越えた時の制御方法

株式会社アスタの技術者ブログに以下の修正方法がある。だがこれではダメなんではないだろうか?

if (empty($_POST) && $_SERVER["REQUEST_METHOD"] === "POST") {
    // エラー処理
}

$_POSTが空っぽのPOST送信がないならば問題ないと言えば問題ないのかもしれないが、別の自由で$_POSTが空配列になる時、もしくは、仕様が変更になった時などに誤動作しかねない。またパッと見これが、なにを意味していったい何をやっているのかコメントがないと理解ができないコードである。($_POSTが空っぽでPOST送信された時ってどんなときやねん(何で関西弁やねん))というわけで、可読性が低いゆえに保守性が低い。HappyQualityとか書いてあるがハッピーになれないクオリティである。次のはてなダイアリー(q.hatena.ne.jp/1193396523)を参考にするならば、$_SERVER["CONTENT_LENGTH"]とpost_max_sizeを見比べるほうがいいのではないか?

以下のコードでとりあえず問題はないが、そもそも論、エラーが補足できる仕組みがないのはPHPちょっといただけない。

if(intval( return_bytes(ini_get('post_max_size'))) < intval($_SERVER["CONTENT_LENGTH"])){
    // エラー処理
}else{
    // 正常処理
}
function return_bytes($val) {
    $val = trim($val);
    $last = strtolower($val[strlen($val)-1]);
    switch($last) {
        // 'G' は PHP 5.1.0 以降で使用可能です
        case 'g':
            $val *= 1024;
        case 'm':
            $val *= 1024;
        case 'k':
            $val *= 1024;
    }
    return $val;
}

※ちなみにreturn_vytes関数はコチラを参考にした。

【PHP】POSTしたデータが入らない!!

とある酷いWebアプリケーションの保守作業。入力項目がありすぎる。入力はJavaScriptで自動化しているが碁盤の目の程の項目がありすべて配列である。沢山のデータがあるとうまくDBに格納するときにズガガガガガと配列で飛んできて格納されるのだが…ある日、入らなくなる。POSTしたデータがどっかで線切れているせいである。調べてみたところ、max_update_varsという値がデフォルトで1000になっているからであった。arrayのデータが1000要素しか入らないということらしい。ずいぶん少ないな。初期値で10000万くらいとってもメモリを喰ったりしないよなー。だいたいそんなPOSTデータが大きいのも問題であるが、ここが大きくて瞬間的にどうなるわけでもないので10倍以上に設定。解決した模様。

IPアドレス確認嬢のソースコード

// phpは日本と異なるUTCで動いているため補正
date_default_timezone_set('Asia/Tokyo');

echo "殿方がわたくしのブログにアクセスしておりますIPアドレスは「".$_SERVER[REMOTE_ADDR]."」でございます。インターネットの接続プロバイダがどこなのか分かる接続元のホスト名は「".$_SERVER[REMOTE_HOST]."」だと思いますが、お間違えございませんか?。なにかございましたら、日時(".date('Y/m/d H:i:s', $_SERVER['REQUEST_TIME']).")とこれらの情報を裁判所へ提出すれば、殿方のご住所やご氏名を調べることが可能ですのでご注意ください。なお、殿方がわたくしに通知してくれましたWebブラウザのユーザエージェントですが「".$_SERVER['HTTP_USER_AGENT']."」のようです。\n\n";それでは快適なインターネットの度をご堪能くださいませ。敬具。

WEBアプリケーションはクライアントのオペレーティングシステムに依存する!?

全角バイトのファイル名をアップロードすると、アップロードできないという問題が発生。

PHPのuploaderなのだが$_FILESのエラーコードは4、
すなわち意味的には「ファイルのアップロードができませんでした」ということなんだが、
これ、事実を書いているだけで原因じゃないじゃん。

つまり、原因は不明。

とりあえずアップロードできない時というのがあるから、
当たり前であるが、エラーがあったら失敗とするという処理にしないとダメなのだ。

Webブラウザがファイル名をポストしてもファイルはポストしなかったということだ。

Webアプリケーション開発者は全角名のファイルをエンドユーザにアップロードさせる時に注意されたい。
なお、上述とは違う問題なのだが、
私のWndows7/32bitの環境ではlinux(utf-8)環境へのuploadはファイル名79文字ならOKで80文字でNGであった。
Windowsの機種依存文字でも問題ないが以外にも文字のながさでOUTになる例がある。

結論として、
Webアプリケーションは、クライアントのWebブラウザに依存するのは当然なのだが、
Webアプリケーションは、クライアントのオペレーティングシステムにも依存するのである。

したがって、クラウドだの言ってても、結局はOSに依存するのである。
(もちろん、クラウドコンピューティングはWebブラウザやOSに依存しないなんて意味はないが)

Webアプリケーション(ASPやSaaS(死語?))の利用にあたって、
どのOSなら使えるか?と明記してあることがあるが、
(クライアントにとっても提供会社にとっても)あれって大切な意味があるのね。