X年、Y月のZ週目月曜日が知りたいー。
ってときに使ったプログラム。
$yearに知りたい年
$monthに知りたい月
$weekに知りたい週(0～)
// 最初のX曜日を算出
for ($i = 1; $i > 8; $i++){
if(date("w", mktime(0,0,0, $month ,$i ,$year)) == 1){
break;
}
}
$ret = $i + ($week * 7);
// チェック
$last_day = date("t", mktime(0,0,0, $month, $ret, $year));
if ($ret < $last_day){
return;
}else{
return $ret;
}
日本の祝日とかで、第二月曜日が祝日だとかよくあるのでそのためだけに。
カレンダーを作る際、春分/秋分の日が変動して計算が面倒です。
そんな春分/秋分の求め方は以下。
function getSpringHolyday($year){
if ($year <= 1947){
$ret = false;
}elseif ($year <= 1979){
$ret = floor(20.8357 + (0.242194 * ($year - 1980)) -
floor(($year - 1980) / 4));
}elseif ($year <= 2099){
$ret = floor(20.8431 + (0.242194 * ($year - 1980)) -
floor(($year - 1980) / 4));
}elseif ($year <= 2150){
$ret = floor(21.851 + (0.242194 * ($year - 1980)) -
floor(($year - 1980) / 4));
}else{
$ret = false;
}
return $ret;
}
function getAutumHolyday($year){
if ($year <= 1947){
$ret = 99;
}elseif ($year <= 1979){
$ret = floor(23.2588 + (0.242194 * ($year - 1980)) -
floor(($year - 1980) / 4));
}elseif ($year <= 2099){
$ret = floor(23.2488 + (0.242194 * ($year - 1980)) -
floor(($year - 1980) / 4));
}elseif ($year <= 2150){
$ret = floor(24.2488 + (0.242194 * ($year - 1980)) -
floor(($year - 1980) / 4));
}else{
$ret = 99;
}
return $ret;
}
20.8357とか、23.2588とか、0.242194とか、意味不明な数値が出てますが、
20.8357は、1980年の春分の日が、20日の20時14分4秒と発表されているので、そこから計算しているというわけです。23.2588も同様の考え方で・・。
0.242194は、1年365.242194日で扱われていたことから、差分として年数分計算してあげてます。
最後に、floor(($year - 1980) / 4)としているのは、閏年を考慮してます。
何分古いお話で、そんな感じで計算されてます。
なんか便乗。
mb_strimwidth関数なんてシラネーって時に自力でやってました。
それ以前にPHPってここまで考慮されてるんだなーと、標準関数の多さにびっくらこきました。
で、自力でやってた感じは文字のバイト数見たりいろいろして変換。
function FN_chktext($text, $byte){
// HTMLタグを取除く
$text = strip_tags($text);
// 文字変換
mb_internal_encoding("SJIS");
$text = mb_convert_kana($text, "RNASKH");
// 文字数取得
$t_num = mb_strlen($text);
if ($t_num > $byte){
$text = mb_substr($text, 0, $byte);
$text .= "..";
$text = mb_convert_kana($text, "s");
}
return $text;
}
たまーに中途半端なところで切れたりして文字化ける始末で、面倒だったりします。
でもって、たぶん普通にmb_strimwidth使った方が早いです、はい。
海外からのアクセスを防ぐ。
そんなお困りな方は、.htaccessで大体のことはできます(サーバが.htaccessに対応している必要がありますが・・)。
order deny,allow deny from all allow from .jp
とすれば、jpドメイン以外からのアクセスを防ぐことはできます。
しかし、これだけでは、apacheの設定具合等によっては普通にアクセスできてしまう場合があるので、IPで直接制限をかけた方が良いかなと。
JPNICが管理しているIPアドレスは以下から確認できるので、それのみアクセスできるようにすれば、一応国内からのみアクセスということができます。
http://www.nic.ad.jp/ja/dns/jp-addr-block.html
設定方法としては以下。
order allow,deny allow from all deny from 210.128.0.0/11 deny from 221.16.0.0/12 ・ ・
.htaccessサンプル(一応2008/11/27付のデータで作成)
ずらっと、大量に記述する必要がありますが、こんなに多量にあってもIPv4はもう喝々で、更に桁数の増えるIPv6にそのうち移行するとか言う話も出てきていたりします。
そんな感じ。
とあるプログラムで気になったことをメモ。
PCか携帯か判断する関数。
DBに1＝PC、2＝モバイルという風に入っており、1、2の数字は変更できる仕様になっています。
1、2の数字を変更した場合、当然以下のようなプログラムでは正常に動かなくなってしまいます。
DB:
1(変動)=PC(変動)
2(変動)=モバイル(変動)
$typeにDBの1、2が入ってきます。
function getIsMobile($type) {
$mobile = false;
switch($type) {
case 1:
$mobile = false;
break;
case 2:
$mobile = true;
break;
default:
$mobile = false;
}
return $mobile;
}
DB:
1(変動)=PC(固定)=PC(変動)
2(変動)=MOBILE(固定)=モバイル(変動)
$typeにDBのPC(固定)、MOBILE(固定)が入ってきます。
function getIsMobile($type) {
$mobile = false;
switch($type) {
case 'PC':
$mobile = false;
break;
case 'MOBILE':
$mobile = true;
break;
default:
$mobile = false;
}
return $mobile;
}
解決方法としては、1、2の数字が変動しないようにするか、別に固定のIDを振ってあげて、その固定のIDで判別してあげれば、数字が変動しても動作する柔軟なプログラムになると思います。
基本・・ですよね・・（´・(ｪ)・`;）