特定の人だけ、IEからファイルアップロードが出来ない。
今回の場合、原因はIEでjpegファイルは、MIME-Typeが"image/pjpeg"として扱われるためだった。
jpegしかアップできないように制限していたところをpjpegも通るようにした。
($_FILES["photo"]["type"] == "image/jpeg" or $_FILES["photo"]["type"] == "image/pjpeg")
特定の人だけ、IEからファイルアップロードが出来ない。
今回の場合、原因はIEでjpegファイルは、MIME-Typeが"image/pjpeg"として扱われるためだった。
jpegしかアップできないように制限していたところをpjpegも通るようにした。
($_FILES["photo"]["type"] == "image/jpeg" or $_FILES["photo"]["type"] == "image/pjpeg")
小学校低学年から30歳すぎまで、「成長痛」に悩まされた。
痛みだすと、夜中に目が覚め、あまりの苦痛に涙がでて30分から1時間弱経過後、消える。
痛さは骨の芯が腐っていく様な感じ。といったら脚が腐った事あんのかと言われた事もあるけれど、それはひどい鈍痛です。
小さい頃は医者に何度か言った事があるけれど、マッサージクリームの様なものをだされてお終いだった。だからずっとマッサージして紛らわしていた。
我が娘が、同じ症状で苦しんでいる。
2歳頃から出始めて、同じく医者に連れて行ったら、成長痛は炎症を起こしているから冷やすといいと言われました。
私は今、小学校時代を過ごした校区に住んでいます。
だから、同じ医者に連れて行ったのです。
時代が変わると言われる事も変わるのかと思いました。
確かに、湿布で冷やすと少しマシになる様です。気休めかもしれませんが。
冷やして楽になるなら私も早く知りたかった。
大人になると、成長痛の頻度は下がっていきましたが、それでも年に数回は痛かった。
30すぎてなるということは、成長痛?
なんか違う気もするけれど、症状は小学生の頃からずっと一緒です。
そういうわけで、湿布薬を常備し、夜中にいつでもさっと貼れるように小さいサイズにカットしてベットサイドにスタンバイしています。
幼稚園の旅行にも持たせ、遠出するときは必ず湿布も持ちます。
前にネットで調べてたら、親の愛情が足りないから出るというのを読みました。
もしかしたらそうなのかもしれない。
私も小さい頃は親にべたべたひっついて甘えるという記憶は無いし、
私自身、娘に対してそのような接し方はできていない。
昨夜はいとこが泊まりに来ていて、娘はいとこ家族と一緒の部屋で寝ていた。
また成長痛で苦しんで大変だったそう。
だいたい、2〜3週間まったくならない時もあるし、3、4日続けてなるときもある。
痛さを知っているだけに、なんとかしてやりたいけれど、
自分も30歳までずっとあったし、どうにもならないのかもしれない。
ただ、今はまったく起こらないので、なにか大きな病気ではないと思う。
痛みが発生したらだいたい30分ぐらいで収まるので、
湿布をしてマッサージしているうちに、寝ることが多い。
postgreSQLからmysqlへの移行で気を付けたい点
postgresqlで、ある小さなシステムを構築準備してました。
現状あるシステムをそちらに載せ変えるという事で、
既存のデータをそのまま使いたい。
最初に確認しておけばすんだ事だけど、postgresのDBエンコードがEUCで、
変更できない事がデータの移行テストの段階でわかった。
新規DB作成も許可されていなかった。
元のシステムがUTF8なので、機種依存丸付き文字がばんばん使われている。
それをそのまま使えるようにしたいし、新しい入れ物はUTF8でないといけない。
mysqlなら新規DBも作成できるし、そもそもUTF8だったので、
急遽つくりかえることにした。
その際、種々の問題が発生したので覚え書きを残しておく。
■データ型
timestump型はdatetime型にする。
(複数カラムあるため)
■php
関数名を「pg_」から「mysql_」に置換
mysql_fetch_objectは行番号指定で取得できないので、
mysql_data_seekでポインタ位置を指定する。
■福問い合わせ
サブクエリがまず展開されるので、サブクエリに無用な結果が含まれると
総当たりとなり、膨大になる。(反応遅い)
サブクエリのSELECT文はできるだけ条件を入れた方が良い。
UPDATE a_table,(SELECT * FROM b_table)o_table SET a_table.name=o_table.oldname where a_table.code=o_table.code and o_table.num=1;
↓
UPDATE a_table,(SELECT * FROM b_table where num=1)o_table SET a_table.name=o_table.oldname where a_table.code=o_table.code;
■mysqlでは正規表現による置換が出来ない
これは面倒だったし、今回はpostgresに持ってって処理した。
ある特定の文字に挟まれた数値データをとりだしたかっただけなので、
それでいけたけれど、文字コードに影響される様な文字列だったらそれはできないし、
ステップ踏むしかないかな。
phpでREGEXPとREPLACEを使って置換する方法をとるとか。
以上、私のメモ書き。
素人なので表現や方法が間違ってるかもしれません。
昔は丸付き文字なんか、利用者の方に制限させて、
文字化けしたら利用者のせいにするとか普通だったけど、
今は丸付き文字も機種依存文字も使うもんね。
私は今も使わないけど。
これまで、引っ越しの際に必ず浸透問題うんぬんと言われていたけれど、
必ずしもそうとは限らない。
余裕があれば回避できる。
1)ネームサーバーが別の場合
旧サーバにてドメイン管理&ネームサーバをレンタルしている。
↓
ドメインを新サーバとは切り離したサービスに移管&ネームサーバレンタル、
旧サーバ向けゾーン情報を設定し、新ネームサーバに切り替える。
↓
平行して新サーバでのコンテンツやアカウントの設定を準備しておく
↓
新しいネームサーバに完全に切り替わった後、
都合の良い日を設定し、ゾーン情報を新サーバ向けに設定。
TTLを短めに設定していれば、すぐに切り替わる。
TTLが短すぎるとリスクがある様なので、
切り替わった後、設定し直す方が良いのかもしれない。
ネームサーバが別サービスであるか、新サーバのゾーン設定の自由度が高くないとできない。
ネームサーバは別に用意しておいてなるべく変更しないというのが理想かもしれない。
webサーバやメールサーバの引っ越しの際、
ネームサーバの変更が無ければ、ゾーン情報の書き換えだけで済み、早ければ数分で切り替わる。
TTLの設定は、サービス会社によって対応が変わってくる。
自由に設定できる手段が無ければ、申請して2〜3営業日とか、何万円とか言われる場合もある。
ドメインの管理はホスティング会社の付属サービスを利用するのではなく、
独立していた方が良いと、つくづく思いました。