PostgreSQLとPHPを活用したシステムづくりの過程で

アパレル系小売業でシステム管理者をやっている人のブログ。

[tt-az]

PostgreSQLで経過年数、経過月数、経過日数を取得

extract(year from age(current_date, foo)) as "経過日数"

extract(year from age(current_date, foo)) * 12 +  extract(month from age(current_date, foo)) as "経過月数"

extract(epoch from current_date - foo) / 86400 as "経過日数"

age() は「x years y months z days」形式で経過日数文字列を返す関数。

だから、extract(year from age(...)) で単純に経過年数が取得できる。

しかし、単純に extract(month from age(...)) では月成分だけ取得されて年数が無視されるから、年数も取得して12ヶ月にすれば、互いに足して経過月数が取得できる。

でもage()で日数を取得するのはかえって回りくどくなるので、引き算してinterval型に対して秒数に変えるepochを指定して、24(時間) * 60(分) * 60(秒) = 86400 で割ると、経過日数が取得できる。

ちなみに、age() の引数にわざわざ current_date って書かなくてもいいんだけど、まぁ書いてもいいし。

[tt-az]

PostgreSQLのcreatedbでの文字エンコーディングとか

　ネット検索でよく見かけるパターンが、「createdb -E UTF8 -T template0 -O owner -U user dbname」なんだけど、これで出来たデータベースはlc_collateがC、lc_ctypeもCってなって、言語固有のサポート（辞書順の並べ替えとか）が受けられないんじゃないかと思えてくる。

　やはり「--locale=ja_JP.UTF8」も加えて「createdb -E UTF8 --locale=ja_JP.UTF8 -T template0 -O owner -U user dbname」なんじゃないのかなって思うのだけど、どっちがどう正しいのか判断できる情報にたどり着けず、落ち着かない気持ちになる。

　サーバーがPostgreSQL 8.4系なのだけど、「--locale=ja_JP.UTF8」って書いたらエラーメッセージ（記録に残してない、すみません）が表示されて、「--locale=japanese」って書いたら通った。　コマンド全体として「createdb -E UTF8 --locale=japanese -T template0 -O owner -U user dbname」　本当にこれでいいんだろうか。

　やりたいこととしては、文字エンコーディングはUTF8にしたい。　ただし、Windowsの扱うCP932を保存する目的で、いわゆる機種依存文字も含めてUnicodeとして保持されれば上出来なのだけど。

[tt-az]

pg_dumpとpg_dumpall、そこで文字エンコーディング

　SJIS（SHIFT_JIS）に含まれない機種依存文字を含むCP932でPHPなどで受け、それをEUC_JPでエンコーディングしているPostgreSQLデータベースに保存しているのだけど、pg_dumpallのダンプファイルや、PhpPgAdmin上では機種依存文字が文字化けして黒菱型に「？」の字形で表示されているので、私は完全に「文字化けが発生している！困った困った！」と思い込んでいた。

　だけど、「pg_dump -E SJIS」などと出力エンコーディングをSJISに強制したところ、機種依存文字がそのまま化けずに得られることがわかった。

　試しに、「pg_dumpall -l foobar -U foobar -w -v -f dumpall_`date +%Y%m%d%H%M`.dump」としていたものを、「pg_dump -E SJIS -F p -v --column-inserts -U foobar -f all_`date +%Y%m%d%H%M`.dump foobar」みたいにしてみたところ、SJISでダンプファイルを得ることが出来た。　あぁ、「--column-inserts」を書いてしまうと、かなり時間が掛かるので、普段はつけないか、「--inserts」にした方がいいようだ。

　それって、CP932固有の文字がEUC_JPとして表せる文字がないだけで、元のSJISに戻せば元の文字になるってことなのかな。

[tt-az]

　JIS X 0208やJIS X 0213やSHIFT_JIS,Unicodeなどとの関係がわかりやすい画像があり、理解の助けになります。

[tt-az]

JIS X 0208とJIS X 0213

　DB Magazine 2010年1月号に、PostgreSQLの話題が掲載されていて、今でもこちらurl（http://www.unisys.co.jp/services/atlasbase/pdf/dbm_1001_postresql.pdf）からダウンロードして読むことが出来る。

　それによると、PostgreSQL 8.3以降でJIS X 0213:2004をUTF_8にてサポートしていて、EUC_JIS_2004やSHIFT_JIS_2004というエンコーディング名において相互変換できるようになっているそうだ。

　ここで重要な事は、EUC_JPとSJISとは相互変換できるが、EUC_JPとEUC_JIS_2004、SJISとSHIFT_JIS_2004との相互変換は出来ないということ。　サーバー側エンコーディングがEUC_JPならクライアント側エンコーディングはEUC_JPのほかはSJISかUTF_8しか使えず、EUC_JIS_2004やSHIFT_JIS_2004にはできないということだ。

　サーバー側エンコーディングがUTF_8であれば、クライアント側エンコーディングにEUC_JPやSJISやUTF_8はもちろん、SHIFT_JIS_2004も使えるとのこと。

　うちが今立ててるサーバーはEUC_JPなので、せめてUTF_8で立て直さないといわゆる機種依存文字を保持できないってこと、だろうな。

[tt-az]

今更文字エンコーディングに悩まされる

　これまでの不勉強を呪うしか無いのだけど。

　クライアントはWindowsパソコン（Windows XP）、サーバーはLinux系（CentOS）でPostgreSQL 8.4やPHP 4.2だったりする既存システム。　サーバーのデータベースダンプファイルをローカル（Windows 7のPostgreSQL 8.4）にリストアするときに、度々失敗するのがおかしいと思っていた。

　具体的には、いわゆる機種依存文字がひっかかっていて、はしごの高橋（髙橋）が文字化けしているのだけはすぐわかった。

　見つけては、サーバー上でPhpPgAdmin経由で文字化け原因を修正したり、ダンプファイルを直接修正していた。

　もともと、シフトJISらしきエンコードでPostgreSQLを使っていた旧サーバーの能力不足のために、私が新サーバーを手配して構築して「引っ越し」させたのだけど、PostgreSQLでの言語エンコーディングを深く考えずにEUC_JPとしてしまったのも今考えるとあまりよろしくない。

　PHPから接続するときに真っ先に「set client_encoding=SJIS」なんて挟んで、これでエンコーディングは解決したつもりになっていた。

　WindowsはWindows NTからUnicodeサポートがOSに追加され、Wikipediaの「JIS X 0213」によるとWindows Vista以降とWindows XP Service Pack 2以降はJIS X 0213の文字セットを含んだUnicodeに対応しているらしい。

　MS-IME上で「機種依存文字」と表示される文字は、Unicodeで管理されてShift_JIS-2004で管理されているんだろうか？

　だとすると、Shift_JISでなくShift_JIS-2004でないといけないし、EUC-JPでなくEUC-JIS-2004でないといけない気がするのだけど。

　JIS X 0208とJIS X 0213のどっちを扱っているのか、自分でもわからなくなってきているので、どなたかご存知でしたらご一報ください。

[pokoda]

「PHPの開発環境（IDE）でベストなのはどれ？」という記事を読みました。 PHPの開発環境（IDE）でベストなのはどれ？

私は今までPHPの開発環境に Pleiades Eclipse を使っていましたが、やっぱり重いなぁというのと、最近なんかバグったのか検証エラーを出しまくるのがちょっと嫌だったので、思い立って新しい開発環境を探してみようと思いました。慣れてる開発環境って思い立って変えようと思う機会がなかなか作れないので、よいきっかけになったかと。 PHP...

[tt-az]

「はじめてのフレームワークとしてのFuelPHP第2版(1) 環境構築編 - 達人出版会」の書籍でも初版ではEclipseだったのが、この第2版ではNetBeansに変わっていたりします。