December 19, 2007
Posted by funa : 12:13 AM | Web | Comment (0) | Trackback (0)
December 18, 2007
Posted by funa : 09:56 AM | Web | Comment (0) | Trackback (0)
August 4, 2007
UTF-8は多言語表示ができますが、日本語、ドイツ語、フランス語、中国語、韓国語、インド系、アラビア系などキリがないほど文字の種類があると思うのですが、全ての文字の文字コードを持っているのでしょうか?
>持っています。約210万文字(21bit)が既に予約されていますが31bitまで使える事になっておりまだ余裕があります。メジャーな文字等はWindowsXpがデフォルトで持っているフォントで表示可能ですが、表示できないものは?に変わるでしょう。
UTF-8ベースのWEBアプリを使用時に日本語を入力するとき、UTF-8で入力するなど、意識する必要があるのでしょうか?
>WEBブラウザが文字コードを変換し、EUCのページならEUCで、SJISのページならSJISで送信されると思います。
ちなみに、EUCとSJISの判定は確実な方法は無いため文字化けの原因になります。
SJIS、EUC、UTF-8とも「a」等の半角英数字と呼ばれる部分の文字コードは同じです。
Posted by funa : 07:45 PM | Web | Comment (0) | Trackback (0)
May 9, 2007
CGMがやっぱり気持ちいい、矛盾がない。それだけだと思う。
妥協点が見つからない。プロ野球より高校野球。
Consumer-Generated Media Apps, User-Generated Media Apps など独善的で在れ。
オセロのように黒が白に変わる。
Posted by funa : 12:48 AM | Web | Comment (0) | Trackback (0)
March 3, 2007
Posted by funa : 01:37 PM | Web | Comment (0) | Trackback (0)
February 24, 2007
サーバにベンチを掛けて類推する(安全率、AP使用率も考慮に入れる事)
ad -n [連続アクセス数] -c [同時アクセス数] http://[アクセス先]
ab -n 1000 -c 10 http://www.bangboo.com/index.html
- Requests per second: 23.34 [#/sec] (mean)で、一秒間に23回 → 200万アクセスまでOK
- Time per request: 50.530 [ms] → 140万アクセスまでOK
- Failed requests: 0 → 失敗がでる同時アクセス、連続アクセスは?
・アクセス先ファイル容量
Document Length: 19670 bytes
・送信リクエスト数
Concurrency Level: 10
・リクエスト完了までの所要時間
Time taken for tests: 50.525910 seconds
・総リクエスト数
Complete requests: 1000
・取りこぼしたリクエスト数
Failed requests: 0
・1秒あたりに処理されたリクエスト数
Requests per second: 23.34 [#/sec] (mean)
・1秒あたりに処理された所要時間
Time per request: 515.299 [ms] (mean)
・1秒あたりに受信された容量
Transfer rate: 337.26 [Kbytes/sec] received
・上から順に接続(Connect)、処理(Processing)、待ち時間(Wait)を集計し、最小値、平均、最大値、平均で表している
Connnection Times (ms)
・処理時間の推移
Percentage of the requests served within a certain time (ms)
メモリ12GB搭載したSPARC SolarisのサーバでApacheのプロセスを6000個ぐらい上げた猛者もいるが、一般的なLinuxサーバでは700あたりで挙動が不安定になる。非常におおざっぱに言えば、ひとつのサーバ筐体でたかだか700人しか収容できないということ。
Posted by funa : 07:25 PM | Web | Comment (0) | Trackback (0)
February 21, 2007
PHP 警告 : ページの有効期限切れ
POSTを使わなければでないのだが、IEのキャッシュがいっぱい2になったときの仕様である。
session_cache_limiter('private, must-revalidate');
かならず再読み込みをする。入力フォームで入れた情報が消える場合がある。入力値をクッキーでカバーできるならこれでOK。
session_cache_limiter('private_no_expire');
入力フォームのデータなどは消えないが必ずcacheを読むため、リロードで古いものを見せ続ける危険性がある。
<a href="form.php?<?=time(); ?>">Go Form</a>
リンクをユニークにすると必ず再読み込みするようになる。
if (0 < count($_POST)) {
session_cache_limiter('private_no_expire');
}
POSTのときだけcacheを有効にする。ブラウザの戻るボタンで戻るとPOSTできていない先頭ページは入力が消えている。
<a href="form.php?doCache">Go Form</a>
if (0 < count($_POST) || array_key_exists("doCache", $_GET)) {
session_cache_limiter('private_no_expire');
}
cacheしたいときにcache指定、POSTのときは強制cache。
--------------
■PHPのバージョンによるのか新情報
session_cache_limiterの引数は
none/nocache/private/private_no_expire/public
のいずれかしか受け付けず、その他の値をセットするとpublicを指定した場合と同じでsession_cache_limiter('private, must-revalidate')はキャッシュ制御ヘッダが送信されない
1) nocache:クライアント/プロキシのキャッシュを無効
2) public:クライアントマシン/プロキシのどちらもキャッシュ
3) private:クライアントマシンのみキャッシュ保持。Expireヘッダが送信されます
4) private_no_expire:privateと同じだがExpireヘッダはクライアントに送信されません。有効期限切れを回避
フォームの入力内容を保持して、ブラウザの戻るで戻りたい場合は、private_no_expireかnoneがいいみたいだ
●session_cache_limiter('private_no_expire');
期限切れが出にくいがキャッシュばかり使う(静的ページ、静的なページのフォーム)
※運用時はprivate_no_expireでも開発時はnoneで
●session_cache_limiter('nocache');
戻ると期限切れがでる(動的ページ、フォームには向かない)
●session_cache_limiter('none')
キャッシュヘッダを出さず、期限切れが出にくく適時読み込みをするがブラウザによる(動的なページのフォーム、更新がよく掛かる静的ページ)
●フォームに戻ってキャッシュ一杯で期限切れを出し、更新ボタンで再ポストを避けたい
期限切れを出さないフォームは、GETかsession_cache_limiter('none');かsession_cache_limiter('private_no_expire');
2重登録NGなフォームは、DBMSにPKやユニークをチェックさせるか、トークンを使うか、処理後リダイレクト
●トークン
1)フォーム表示時点で、画面にhiddenにキーを、セッションにもキーを仕込んでおく。
$taskId = mt_rand();
$_SESSION['taskId'] = $taskId;
print('<form action="submit.php" method="post">');
print('<input type="hidden" value="' . md5($taskId) . '" name="taskId" />');
print('<input type="submit" value="submit" name="submit" />');
print('</form>');
2)登録処理のとき、画面から来たキーとセッションに格納されているキーを比較して、正しくフォーム表示の画面から遷移しているか確認する。
<?php
//二重登録防止フォーム-登録処理
session_start();
$taskId = $_SESSION['taskId'];
unset($_SESSION['taskId']);
if (md5($taskId) == $_POST['taskId']) {
print('きちんと前の画面からsubmitされています。');
//登録処理後に完了画面にHTTPリダイレクトで遷移するようにしておけば特別な対策なしでも完了画面をリロードされても問題なし
header(‘Location: 完了画面URL’);
} else {
//二重登録された場合や、直接アクセスされた場合の処理
print('フォームを通してアクセスして下さい。');
}
Posted by funa : 07:56 PM | Web | Comment (0) | Trackback (0)
February 20, 2007
http://yotophoto.com/
http://www.sxc.hu/
http://www.morguefile.com/
http://www.burningwell.org/gallery2/main.php
http://davidniblack.com/imagebase/
http://www.freephotosbank.com/
<!-- This is my advice for the OLD-FASHIONED man who can NOT take resonable alternatives in mixed COMPLEX stuation. Need learn MBA not PM. PM depends on age. MBA brings everybody who wants to be in this ganeration of IT a pillar. NEXT is ... -->
スーパーのレジ打ちを顧客自身がやってはいけないのか?早く店を出ることができるようになったら、その方が顧客は喜ぶのではないか?と考える
Roger that.
Posted by funa : 07:51 PM | Web | Comment (0) | Trackback (0)
February 17, 2007
mod_rewiteの設定は.htaccessに記載していることだと思うが、ヘンテコな設定はかなりApacheに負荷を掛け、Temporary Service UnavailableやForbidenなどのエラーを頻発させてしまう。
よく使われる設定は、次のようなものだ。
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^db/([0-9A-Za-z]+)_(.*)\.html$ db/db\.php?id=$1 [L]
RewriteCond %{REQUEST_FILENAME} !-d は「ディレクトリが存在しない場合」
さらに、次の RewriteCond %{REQUEST_FILENAME} !-f は「ファイルが存在しない場合」
リクエストされたディレクトリまたはファイルが存在しなければ、mod_rewiteのルール処理に行くよ。ということである。つまりルートディレクトリに置いた日には無駄にApacheのリソースを喰ってしまうのである。dbディレクトリにhtaccessを置くなど、ディレクトリ毎に設定する方策をとる必要がある。
また、ルール処理にできるだけ行かせないようにする記載方法も併せて施策としたい。
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !\.(css|gif|jp?g|png)$
RewriteCond %{REQUEST_URI} !^/images/.*$
RewriteCond %{REQUEST_URI} !^/s/.*$
RewriteRule ^db/([0-9A-Za-z]+)_(.*)\.html$ db/db\.php?id=$1 [L]
Posted by funa : 06:29 PM | Web | Comment (0) | Trackback (0)
February 5, 2007
Posted by funa : 09:56 PM | Web | Comment (0) | Trackback (0)
< December 2024 > | ||||||
Sun | Mon | Tue | Wed | Thi | Fri | Sat |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |