PHPのテクメモ

機能のメモをしていて調べてみると、いろんな意見があった。記述忘れもあったのでメモしてみる。utf8_general_ciとutf8_unicode_ciの違いの続き。

まずutf8_general_ciのほうが高速と書いてあるサイトもある。正確かどうかというのは「何を持って正確とするか」という定義に依存するだろうから議論しないけれど・・・、どっちが速いんだろう。好みの動作という点ではutf_general_ciなんだけど。

utf8_unicode_ciでもう一つ。「は」「ぱ」「ば」「ハ」「パ」「バ」なんてのも全部同一視するらしい。ゆるい。こういうのを同一視しようと思ったらそれなりに大変なような気がするから、こっちのほうが速度が遅いような気もするな。

んー。あとSET NAMESの設定とか、なんか、いろいろ考えたら、もうちょっとデータベースのことや文字コードのことをしっかり勉強しなきゃいけないなぁと痛感する今日この頃だ。こういうことを勉強してくれる立派な家来をみつけなくては（他力本願）。

基本的に今は文字コードを全てUTF-8で統一するようにしている。もともとPHPはシフトJISが得意でないし、いまさらEUC-JPを使う理由もない。自分のウェブサイトを構築する場合は、携帯サイトを除いて出力もUTF-8だ（ウェブサービスとの親和性もいいし）。必然的にデータベースもUTF-8でデータを格納しているわけなんだが。

MySQLでいつも迷う点がある。いわゆる照会順序ってやつ。SQL serverなんかでは照合順序って名前になってることもある。照会順序とは「言語種別」と「ロケール」に基づく文字列の比較方法の規則のこと（らしい）。文字列の比較だからWHERE句での比較はもちろんだし、ORDER句の並び替えにも影響するので、希望通りの結果を得たい場合はしっかり設定しておかないといけない。でも、これ、いろいろあるんだな。

文字列に対しての影響を及ぼすわけだから、数値型カラムなどは関係ない。varchar型やtext型で設定しなくてはいけない（つまりカラムごとにも設定できるっぽい）。それにデータベースのデフォルト照会順序も設定できるし、テーブルでも照会順序を設定できる。照会順序で設定できる値は大量にあるのだが、日本語環境でUTF-8を使っている場合に設定するであろう値は以下の3つだ。

• utf8_bin
• utf8_general_ci
• utf8_unicode_ci

最初のはbin。これはバイナリ（binary）レベルで検査してくれる。バイナリで見てくれるわけだから、絶対確実。間違いなく期待通りの答えを返してくれそうな感じ。

あとの2つは両方とも後ろに_ciとなっているが、これは「case insensitive」の略。つまり大文字小文字（upper caseとlower case）を区別しない（「sensitive：敏感」でない）という意味だ。だからバイナリレベルでのチェックではないことは明らか。これだけ見ればbinがいいような気がするけれど、マルチバイトもシングルバイトも関係なくてバイトオーダーで検査するので、ひょっとしたら希望通りの動作にならないことがあるかもしれない。

で_ciな二つだが、前者（general）は英数の全角半角の判断くらいはしてくれるらしい（大文字小文字は判断しない）のに対して、後者（unicode）は全角半角大文字小文字も判断しないらしい。例えば文字列比較で以下のような例を考える。

1. （半角大文字のA）=（全角大文字のA）
2. （半角大文字のA）=（半角小文字のa）

前者（general）だと1はfalse、2はtrueだが、後者（unicode）だた1もtrue、2もtrueになる。どんな動きをしてほしいかということは、用途によってそれぞれだから一概にどちらが正しいとは言えないけれど、ちょっとややこしい。でも、前者のほうがなんとなく正確っぽいので、より厳密なのかなと思う。後者はなんとなくあいまいっぽいので、処理が簡単そう。だから正確度ならgeneral、速度ならunicodeということになるだろうか。

用途によるんだけど、まぁ、どれを使っても、一般人の考えているとおりの動作はしてくれなさそうだ。がんばって使い分けるしかない。

データベースの作り方で一工夫必要だったわけだが、テーブルに位置情報を格納するカラムを作るのはさらに一工夫必要だ。

ID番号、地点名、位置情報の3つを格納するテーブルを作成することにする。テーブルを作成する際は、まず最初に、位置情報を格納するカラム以外のカラムだけでテーブルを作成する。つまりID番号、地点名だけのテーブルを作成する。例えばこんな具合に。

CREATE TABLE positions (
id int4 SERIAL PRIMARY KEY,
name varchar(128)
);

そして、PostGISをインストールした際にたくさん設置された関数群のうちの一つを使用して、位置情報を格納するカラムを追加する。ここではlatlngというカラム名を使用することにする。

SELECT AddGeometryColumn(‘public’,’positions’,’latlng’,4326,’POINT’,2);

publicはスキーマ名
positionsはテーブル名
latlngはカラム名
4326は測地系の番号（この数字はWGS84）
POINTは型（他にLINESTRINGとかPOLYGONとか）
2は2次元

つまりSELECT文を使って、AddGeometryColumn関数を実行しているということ（この関数でカラムを追加）。この作業でようやくPostGISなテーブルが作成される。ここまできて、ようやく今までやってきたことの意味が理解できるようになる。

4326ってどこから出てきたのか。実はこの数字はPostGISなデータベースに自動的に作られるテーブル「spatial_ref_sys」に全て格納されている。このテーブルには約3000行のデータが格納されているのだが、これらは全て座標系だ。4326の値は外部キーのようになっているということ。

そして位置情報格納カラム「latlng」を作成した関数AddGeometryColumnはカラムを追加するだけでなくて、そのカラムの情報を「geometry_coumns」に格納している。ためしにこのテーブルを開くと、先ほどの関数の引数と似たような内容でデータが格納されていることが一目瞭然だ。

もうここまでくればPostGISに関する理解はほぼできたといっても過言ではない（と思いたい）。「なんで最初からわけのわからないテーブルが二つも作られているの」「どうやって使うの」という問題は通り過ぎてしまったわけで、後は希望通りの処理を返してくれるPostGISな関数がどれなのか、ということを探すことになる。

ただしもう一つ知っておかなければいけないことがある。それは測量に関する知識だ。当たり前だが地球は丸い。というか球だ（実際は球ではなくてもっと歪んでいる）。球を無理やり平面に押し込めたのが地図だ。軟式のテニスボールをカッターで切り刻んでみればわかるが、本来球はどうやっても平面にはならない。でも、それでも人間が理解しやすいようにPostGISは答えを返してくれる（らしい）。そんなPostGISをこれから徐々に使っていこうと思う。

当面PostGISを使うので、思ったことや気づいたこと、わかったことをメモしていくことにする。

お試しインストールだけしたPostGISだったが、やっぱり気になるので少しだけ試すことにした。何をどうすればよいのかわからないし、書籍も皆無な状態なので、いつものように検索しつつ・・・の確認作業。

データベースの作成からはじめないといけない。PostgreSQLのデータベース作成で、以前はデータベースのテンプレートなんて「なんのこっちゃ」ということで気にも留めていなかったけれど、ここから勉強だ。というか「こういう用途だったのね」と再認識した。PostGISインストール時に自動的に作成されたtemplate_postgisというデータベーステンプレートを元にデータベースの作成をしなくてはいけない。要はコピーして新規作成。

createdb -T template_postgis dbname

これでdbnameという名前のデータベースが作成される。大量の関数群と二つのテーブルがあらかじめ作成された状態になっている。でもまだまだ序の口。だいたいなんで最初からテーブルが作成されているのかわからない。どうやって位置情報を格納するのかもわからない。わからないことだらけだ。

とりあえず、小さいことからコツコツと始めることにする。

絵文字の著作権についてドコモに問い合わせた結果が返ってきた。結論から言うと、ドコモとしては問題ないという回答だった。

絵文字については、一般的な記号や図形であるので
著作権はないと思われますが、著作権の所在が明らかでないものも
一部含まれているので、絵文字をご利用いただくにあたり
ドコモから許諾することはできかねます。

ただ、絵文字の配布などをされたことで、
ドコモからお客様へ申し立てすることはございませんが
絵文字のご利用や配布などで不具合が生じた場合や
第三者の著作権侵害などが生じた場合には
ドコモでは、補償をすることができかねますので
お客様の責任の範囲でご利用いただきますようお願い申し上げます。

つまり「一般的な図柄だからドコモから著作権うんぬん言うことはないけれど、ひょっとしたら一部の図柄については著作権を主張する人がいるかもしれないから、その場合は自分で対応してね」という趣旨。

んじゃまぁ、大丈夫か。