日々の破片

_ ユーザ入力の住所は怖い

データベースには、ADDRESSみたいなカラムがあり、そこはvarchar(64)みたいになっているとしよう。

で、これまでは従業員が入力していた（たとえば、客が書いた配送先住所を手打ちで入れていたりとか）とする。

「これまで」というくらいだから、何も考えずにシフトJIS（でもその実体はWindows-31J）にしていたことだろう。

で、なぜかそれをユーザーがWebから直入力できるようにしてしまったとする。

これは、つくづくと相当な死亡フラグなのだが、問題となったという事例を見ない。

不思議だ。他の人たちはどうやっているのだろうか？

ユーザーは、こちらが驚くほど多様だ。

たとえば、「ザ・グレート歌舞伎町」というマンション名があるとする。

「・」を知っている人は「/」を変換するだろう。知らなくても普通はそう入力するような気がする。全然知らなくても「中黒」という用語を知っていれば変換できる。

でも、「ザ◦グレート歌舞伎町」と入力してくる人がいる。（WhiteBullet \u25e6）

あるいは「ザ•グレート歌舞伎町」（Bullet \u2022）も普通にいる。

これらは、最後にはデータベース内に「ザ?グレート歌舞伎町」として格納されて、気づいた人が「なんじゃこりゃ？」と騒ぐことになる。

「－」も鬼門だ。長音「ー」や「－」（全角マイナス）「―」（ダッシュ）「‐」（ハイフン）あたりはなんとなくわかる。「歌舞伎町３‐２‐１」とか書くなら、本来はハイフンのはずだが、これがダッシュやマイナスでもそれほどは困らないし、長音なら置き換えようという気にもなる。

しかし、現実は「―」（Horizontal Bar \u2015）や「‑」（Non-Breaking Hyphen \u2011）「—」（Em Dash \u2014）「⁻」（Superscript Minus \u207b) など、どうやって入力したんだろう？ というような文字がたくさんでてきて、気づくと住所は「歌舞伎町３?２?１」になっているわけだ。

対応するにはどうすれば良いのだろうか？

1) データベースの文字コードをUnicodeにする。DM印字とかは多少の字体の違いには目を瞑って入力されたものをそのまま利用する。

これが無難な気がする。

2) WebページをWindows-31Jとして、POSTデータもWindows-31Jでエンコードさせる。

これが成功するかどうかは良くわからない。エコーバックした時点で文字化けしたというユーザークレームを招くだけのような気がするが。

3) 中黒やハイフンに似たすべての文字を洗い出して変換表を作る。

挫折しますた。諸外国の言葉まで含めると中黒やハイフンの代わりに利用できそうな文字はたくさんあり過ぎる。

4) 利用可能な文字コードのセットを使って、文字チェックをする。

しかし、普通のユーザーに「入力された『ザ•グレート歌舞伎町』は利用できない文字が含まれています」って、そんな間違い探しさせるのか？ というか、普通に中黒を出せない人だから、そんな妙な入力をしているわけだろうし。

5) 住所入力専用の賢いソフトウェアキーボードウィジェットからしか入力できないようにする

思いっきり不便な気がするのだが。漢字部分だけはキーボードを使わせて？

6) はて困った。

というわけで、みなさんは、どのように対応されているのだろうか？