郵便番号API企業の「使いやすい入力欄」の作り方が人気に 147
ストーリー by nagazou
半角や全角強制とかね 部門より
半角や全角強制とかね 部門より
ITmediaの記事によれば、適切な住所入力フォームの作り方を紹介した「これだけは押さえよう!住所フォームの作り方」というサイトがネット上で話題になっているという。元記事はSIerのオープンコレクターが公開したもので、以前紹介したことのある郵便番号API「ケンオール」のPR記事として作られたものだそうだ（ITmedia）。
記事中で紹介されているポイントは多岐にわたるが「オートコンプリート機能に最適化する」、「郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する」等の最低限抑えるべきポイントなどを列挙しつつ、こうした要素を満たした見本となるデモページも公開している。デモページのソースコードも見ることができる。
記事中で紹介されているポイントは多岐にわたるが「オートコンプリート機能に最適化する」、「郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する」等の最低限抑えるべきポイントなどを列挙しつつ、こうした要素を満たした見本となるデモページも公開している。デモページのソースコードも見ることができる。
全角半角とカタカナひらがな (スコア:2)
前にも話題になってた気がするけど。
住所フォームで全角/半角で弾かれたり、名前のよみがなフォームでカタカナとひらがなどちらかしか認めないエラーで弾かれるとイラっとしてしまいます。
かつては住所フィールドを全角固定にするUIが多数見られましたが、現在は全角・半角両対応するのが一般的です。 サーバサイドの側の要件で全角固定にせざるをえない場合でも、送信時に全角変換するなどして、UI上はなるべく全角・半角両対応にしましょう。
もう一般的になってるのか、しらんかった。
Re:全角半角とカタカナひらがな (スコア:2)
よみがなは本当にひらがなでいいのにどうして、って感じですよね。
わざわざカタカナにするためだけに変換というワンクッションを挟ませる意味がわからない。
Re:全角半角とカタカナひらがな (スコア:2)
カタカナは、手書き時代の名残じゃないかと推測。
紙の小さな枠に手書きする場面では、ひらがなとカタカナを比べたとき、カタカナの方が読み書き共にしやすいんじゃないでしょうか。
手書きは下手とか崩しのくせとかあるから。
手書き時代の常識感を疑うことがなかったとか、現物の紙を出して準拠を要件にしたとか。
Re:全角半角とカタカナひらがな (スコア:2, 興味深い)
自動変換を作ったものの、顧客に言われて外したことがあるものです。懺悔します。
顧客がどうしても固定が良いって言ったんだよ
自動変換はダメだと
ユーザが入力したものと変えることはまかりならんと
説得できなかった…
そういうこともあるんよぉ
Re: (スコア:0)
ハイフンや長音符や他の横棒記号を、グチャグチャに混ぜたゴミデータの出来上がり。
Re: (スコア:0)
チェックして気に入らないのはすべて弾くのでそうはならないんですけどね
ここはひらがなだここは漢数字だとかとか
全角ハイフン地獄の説明とかもしたんですけど…
全く趣味が合わなくて閉口しました
Re:全角半角とカタカナひらがな (スコア:2, すばらしい洞察)
番地が全角でしか受付ないの何とかしてよ。
英数記号は半角で入力されるようにIMEを設定してるから、数字を全角に変換するのに苦労する。
Re:全角半角とカタカナひらがな (スコア:1)
> 番地が全角でしか受付ないの何とかしてよ。
マジでこれ。
先日とあるショップに注文の際、「アレゲハイツ 104」っていれたら「全角で」って言われ
「アレゲハイツ １０４」に修正したけどまた指摘された。スペースもかい～！
住所は「全角」に正規化すべきなの (スコア:1)
住所表記がバラバラだとトラブルの原因なので正規化すべきですが、各種法令・お役所内の内規で全角に統一されています。
正式な住所に半角数字が使われることはなく、戸籍も住民票も登記関係もすべて全角に統一されています。
従って、番地等は全角に正規化すべきものです。
勝手に変換すれば良いと考えている人も居ますが、特に高級住宅街に住んでいる方など、住所表記に拘りを持っている人も居ますし、入力した住所と違う表記で郵便物が届いたことにクレームを入れる人もいます。
また、半角に統一する場合は、「１２番地９」や「１２番９号」を「12-9」にするのが一般的ですが、それだと地番なのか住居表示なのかという情報が欠落してしまいます。
住居表示ならば街区表示板を見れば地図無しで目的地にたどり着けますが、地番ならば地図が無ければ目的地にたどり着くのが極めて困難なので、これらは区別すべきです。
Re:住所は「全角」に正規化すべきなの (スコア:2)
では手書きの際も半角全角も区別していただいて。
ところで、全角半角は単に文字幅という見た目の違いであって、文字としては同じもの。
役所が公証する「正式な住所」は紙で発行された証明書によるものなので、文字幅もフォントも証明書の見た目に準拠しましょうか。
全自治体が証明書で採用するフォントを取り揃えていただいて。
全角と半角ではコンピュータ上で扱う際に文字コードが異なりますので、文字コードに着目して役所準拠を求める都合上、他の文字も含めて、役所のシステムが使っている文字コード体系を採用していただいて。
私はそうでないものが不正確な住所とは思いませんが。
なお、マイナンバーの通知カードでは、表に記載される発行時の住所は全角数字でしたが、転居時に記載する裏の住所は半角数字でした。
「半角がシステム側で全角に変換される」ことにクレームを入れる人がいて、それに配慮する必要があるとして、「半角が拒否される」ことにクレームを入れる人は配慮されないのでしょうか。
要不要の理由はなんでしょうか。
配慮されるべき前者は、自分が入力した半角が拒否されることにクレームは入れないのでしょうか。
システム内で半角全角を統一する必要があるとして、半角の場合では「1-2」「1番2号」「1番地2」のいずれもありえ、全角の場合には「１－２」「１番２号」「１番地２」のいずれもありえるでしょう。
「ハイフン」か「番・号・番地」（更に番地の場合は「の」や号の有無も）かは、半角全角の強制や変換とは全く別の論点ですね。
全角を強制するサイトには多く接しましたが、ハイフンで入力して「番・号・番地で書け」などとエラーになったことはありません。
あなたが全角にこだわるに当たって、「番・号・番地」を強制するサイトを作ったり使ったりしたことはあるのでしょうか。
Re:住所は「全角」に正規化すべきなの (スコア:2)
全然違う話ですね。
このストーリーは一般利用者による住所入力の利便性の話です。
一般利用者が自身の情報を入力するシステムと、管理者が利用者の情報の入力するシステムは、当然異なります。
一般利用者では変更できない項目が、管理者は変更できたりね。
ご提示の例は、管理者用のシステムですね。
とあるサイトが、一般利用者が半角で入力すると自動で全角に変換していたとする。
当該サイトの管理者が、利用者情報を管理する際に利用するシステムにおいて、半角を入力したときに、許可する、警告の上で許可する、禁止する、全角に自動変換する、など、どんな処理をするかは、一般利用者向けの場合と同じである必要はないでしょう。
一般利用者向けの場合とは別の理由で、可不可が決められる。
管理者用システムがかくあるべきかという議論があるとしても、このストーリーとは違う話ですね。
役所の住所管理がどうであるかという点も、日常の住所の記載が役所の住所表記に従う必要があるかという点を超えた部分は、関係ないです。
ちなみに、私は3自治体＆自治体内で転居を経験しましたが、届はいずれもハイフンで受け付けてもらえました。
正式な住所形式にはあちらで変換してくれたので、役所は親切ですね。
世の中には役所の住所表記を重視する立場があるようですけども、その役所自身の所在地表記を公式サイトで見てみると、首都の東京都 [tokyo.lg.jp]は「2-8-1」、新宿区 [shinjuku.lg.jp]は「1-4-1」、北の北海道 [hokkaido.lg.jp]は「北3条西6丁目」、札幌市 [sapporo.jp]は「北1条西2丁目」、南の沖縄県 [okinawa.jp]は「1-2-2」、那覇市 [okinawa.jp]は「１丁目１番１号」。
さすがに全自治体は見てないですが、役所自身はあまり正式な表記にこだわっていないようですね。
那覇市は聖地かな。数字もいいし。漢数字ではないけど。
Re:住所は「全角」に正規化すべきなの (スコア:2)
「３丁目１２番地９」形式の場合は地番、「３丁目１２番９号」は住居表示なんです。そして、この二つは独立した索引体系なのです。知らんけど。そんな二重制度になっているわけがあるか、うちにはずっと普通郵便が来ている、葉書や封筒が「ｽﾗ度町3-12-9」で届いている、悔しくも我が家ほどに特徴のない住所もあるまい、とお思いでしょう……
Re:住所は「全角」に正規化すべきなの (スコア:2)
普通、住所を地番で表示する場合は「丁目」は付きませんよ。
土地登記の場所情報である地番は、「○○市 大字 小字 1234番地 5」という表記。
登記に基づく表示なので、複数の家が同じ地番になる場合もある。
住所の場所情報である住居表示では、小字は概ね廃止され、大字小字の代わりに、理路整然とした町区域を割り当てて、
「○○市 町名一丁目 23番 4号」って表記になります。
住居表示を実施していない地域では、地番方式で住所を表現しますが、
住居表示実施後は、住所表現に地番を使ってはいけません。
ですので、住居表示実施した土地では、地番も「○○市 町名一丁目 1234番地5」に変わりますが、
住所として「一丁目1234番地5」形式を使うことははありません。
あと、住居表示では、町名と丁目は別階層ではなく同階層で、「町名一丁目」でひとかたまりの「町区域」で、必ずしも町区域に丁目が付いてるとはかぎりません。
「○○市 町名 12番 3号」みたいに丁目が付かない住居表示のところもあります。
というわけで、「○○町３丁目１２番地９」という住所はありえませんが、丁目無しの住所表現では、
「○○町１２番地９」形式の場合は地番形式で、「○○町１２番９号」は住居表示形式、という紛らわしさはあります。
Re:住所は「全角」に正規化すべきなの (スコア:1)
住居表示実施前の住所表記「○○市 大字 小字 1234番地5」
→住居表示実施後の住所表記「○○市 大字三丁目 23番 45号」
というように、
(地番も「○○市大字三丁目2345番地」に変わるけど、実施前の丁目無し地番は継続して住所表示に使われることはあっても、住居表示実施後の地番をわざわざ住所表記には使わないので)
普通は「住所表示としての地番に丁目は付いてない」という話だったんですが、
場所によっては住居表示未実施だけど町名に丁目が付いてるところもあるようですね。
自分の知ってる範囲(今住んでるとこや前住んでたとこ、親戚の住所など)では見たこと無かったため、住居表示未実施で丁目付き住所はないものと考えていました。すみません、不勉強だったようです。
どうも、部分的に住居表示を実施した場合に、同じ町域の未実施区域も丁目付に町名変更してるっぽい。
Re:住所は「全角」に正規化すべきなの (スコア:2)
ふと思ったけど、工事現場に配達することってないんですかね。
住居表示実施地区に住んでいて、地番を見る機会は工事くらい。
住居番号のない工事現場に出前を頼むとかどうしているんだろう。
「〇号の右となり」とか書くのかな。
Re:住所は「全角」に正規化すべきなの (スコア:2)
数詞としての性質を持っているかどうかじゃないでしょうか。
Re:住所は「全角」に正規化すべきなの (スコア:2)
それらの何段階か前の由来のときは知りませんけど、丁目は、直接の名付けのときに「地域を区切って1から順番に数字を振る」ってしたものでしょう。
そして、現に同じくくりの中の順序として扱っていますよね。
同一の意思決定の下で、地域に順番に数字を振って、結果町名が一戸から九戸になったら、「〇県×市一戸2番3号」「〇県×市二戸3番地4」を「〇県×市1-2-3」「〇県×市2-3-4」と簡略表記するようになっていたかもしれませんね。
三重県が分割されて、北から順番に「三重第一県」「三重第二県」「三重第三県」と名付けることにしたら、「三重1県」「三重2県」「三重3県」と簡略表記するかもしれません。
ただ、「東海4県」のような用法として、旧三重県の3つの県を総称して「三重3県」と言うこともあるだろうと想像すると、区別するための別の表記が慣例化するかもしれません。
Re:住所は「全角」に正規化すべきなの (スコア:1)
Re: (スコア:0)
「よみがな」フィールドはひらがなで入力すべき。
「ヨミガナ」フィールドはカタカナで入力すべき。
って、遠い昔に教わったような気がする。ただし手書き入力について。
UIは内部で変換しろとも思うけど、確認画面で自分が入力した値と違うのが表示されるとちょっと混乱するかも。
Re: (スコア:0)
どこからどこへ送信なのかにもよるけど、送信時に変換ってのはだめじゃない？
いや送信側で変換してもいいんだけど、その場合でも受信側にも変換処理を入れるべきでは？
Re: (スコア:0)
受信側では正しいフォーマットでないと受け付けない場合の話じゃないかな。
Re:全角半角とカタカナひらがな (スコア:2)
先日スマホアプリで会員登録したときは、住所欄に「全角」と指示があり、しかし数字をぱっと全角にできず、面倒なのでエラーになったら登録をやめようと思ったのですが、半角のまま送信したら自動で全角に変換してくれました。
ネタ元のサイトが言う「現在は全角・半角両対応するのが一般的です」というのは、スマホ時代だからですかね。
電話番号もおんなじ (スコア:2)
＞「郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する」
電話番号も同じくハイフンありなしどちらも対応が必要ですね。
メルカリ購入時に電話番号を登録してくださいと表示される原因の対処方法 [yuubinya.com]
結論としてメルカリのスマートフォンアプリで、電話番号にハイフンを入れるとアウトなんですが、
かみさんがメルカリで購入しようしたとした際、「電話番号は市外局番から登録してください。電話番号は10～11文字でお願いします」がでて買えない現象にやられました。
結局、上記手順のとおり自分のプロフィール欄の電話番号からハイフンを削除して再登録で解消できましたが、これはメルカリのＵＩがカスだな・・
都道府県コード (スコア:0)
郵便番号入力と連動せず都道府県をプルダウン形式のセレクトボックスで選択する場合、都道府県名の前に都道府県コードがあるとうれしい。
キーボードから2桁の数値を入れるだけで選択できる。
自宅の住所を何度か入力すると「何か知らないけど、いつもこの数値が書かれている」と覚えれるよ。
Re:都道府県コード (スコア:1)
>郵便番号入力と連動せず都道府県をプルダウン形式のセレクトボックスで選択する場合、都道府県名の前に都道府県コードがあるとうれしい。
都道府県を選択するとき、日本地図で場所クリックで選択。
でもいいな、と時々思う。
リストボックスの文字を追うのが時々辛いお年頃。
Re: (スコア:0)
プルダウンの都道府県選択の並び順は五十音順とかにして欲しいって思う。
滅多に使うものじゃないし探すのにいつも苦労する。
Re:都道府県コード (スコア:1)
神奈川県
和歌山県
は長くて探しやすいぞ。是非お引越しください
鹿児島県はほとんどの場合最後付近だから3文字のありがたみは少ないな
Re:都道府県コード (スコア:1)
これからはいったん神奈川を目指そう。
ありがとう
ickwat
入力フォームのtype属性をきちんと指定してほしい (スコア:0)
電話番号や郵便番号欄はinputタグのtypeをnumberにするとか、メールアドレス欄はemailにちゃんと指定してほしいわ。
素のままだと入力もしづらいし、何でも入力できて送信後にエラーになったりするだろ。
Re:入力フォームのtype属性をきちんと指定してほしい (スコア:1)
電話番号はtelじゃなかった？
Re: (スコア:0)
メールアドレスは単語登録しているので英数固定は困る
Re: (スコア:0)
typeがnumberだと頭の 0 が欠損したりしない?
Re:入力フォームのtype属性をきちんと指定してほしい (スコア:1)
type="tel" が用意されてるのにnumberにする方がどうかしてるよね。
Re: (スコア:0)
どうせ入力はtypo属性になるんで問題ないのですよ
# スラド化APIとして4/1にリリースしよう
デモの住所フィールドが分割されているのがいただけない (スコア:0)
意図した通りに分割して入力してくれるとも限らないし、コピペでの入力も面倒。
分割したけりゃフォームの裏で勝手にやってくれ。
Re:デモの住所フィールドが分割されているのがいただけない (スコア:1)
「ケンオール」こと、日本郵便提供の「KEN_ALL.CSV」は郵便番号と住所の一覧CSVデータですが、
住所は「都道府県名」「市区町村名」「町域名」の三カラムに分かれています。
それを、そのまま自動入力する項目としてデモに使ってるだけでしょう。
地方公共団体コードも入っていて都道府県・市区町村までは表記にブレはないんですが、
町域がブレまくりなのが、KEN_ALLの特徴。
どんなひどいデータなのかはこのページ [mammb.com]なんかが参考になるかと思います。
Re: (スコア:0)
住所フィールドはなるべくまとめ、手入力を可能に [kenall.jp]
住所フィールドを1つにまとめる [kenall.jp]
ちゃんと
Re: (スコア:0)
フィールドをまとめるデメリットで挙げてるものは、プログラムの細工で容易に解決できるものばかりじゃん。
総務省謹製の住所正規化ライブラリだってあるのだし、現代の住所を取り扱う環境への理解が浅い人が書いた記事じゃないか？
Re: (スコア:0)
郵便番号と住所の対応付けという、現代の住所表記が無間地獄ということをよく理解してる人が書いた記事っぽいよ。
Re: (スコア:0)
プログラムの細工で容易に解決できる住所だけを扱えばよくって、総務省謹製の住所正規化ライブラリで正規化できないお客様を切り捨てていいんならそうなんじゃない？
Re: (スコア:0)
特定の住所を扱えないサービス、配達が増える
↓
住民が自治体に改善を要求する
↓
正規化できない住所名を自治体が変更する
↓
正規化できる範囲に収まる
↓
桶屋が儲かる
Re: (スコア:0)
微積を覚えて「数学がわかった」と言ってる高校生みたいでほほえましい
とはいえ、住所なんか名字の表記ゆれと同じでリセットしちまえよと思わんでない
移行措置で両方OK挟めば行けるっしょ
Re: (スコア:0)
ぜひその移行措置にバッチリ対応した実装をお願いします。
(移行が終わった後のことしか考えなくていいなら、とっくに移行できてるはずのものは山ほどあると思う)
Re: (スコア:0)
デモだからね
統合したけりゃ勝手にやってくれってことでしょ
Re: (スコア:0)
デモだからね
統合したけりゃ勝手にやってくれってことでしょ
でもめんどうでしょ
ってことなんじゃろ
Re: (スコア:0)
え？
データベースに無い住所 (スコア:0)
困るんだよね、データベースに無い住所。
例えば郵便番号での郵便局留め。郵便局ごとに固有の郵便番号があるので、考慮していないAPIの場合は入力できず詰む。
※その場合は郵便局のある土地の郵便番号にせよとの話だが調べないといけない。
あとは新開発されて住所が変更された土地。
指定された住所入力しようとしても、選択肢に出てこないので選択できない。
クロネコヤマトのスマホアプリとか酷い作りだった。amazonの返品センターの住所が出せなかった。
そんな所にも気を配って欲しいね。記事にはきちんと、その辺りも書いてあるけど、後日追加の注釈で
と追記してるぐらいなので、皆忘れがちなのだろうと思う。
Re: (スコア:0)
それはそのシステムが、郵便局が常に最新版をに公開してる
大口事業所個別番号データを食わせてないだけでは。
https://www.post.japanpost.jp/zipcode/dl/jigyosyo/index-zip.html [japanpost.jp]
Re:データベースに無い住所 (スコア:1)
大口事業所個別番号は非公開の場合がある。これは大口事業所個別番号データの説明ページにも明記されている。
https://www.post.japanpost.jp/zipcode/dl/jigyosyo/readme.html [japanpost.jp]
したがって、大口事業所個別番号データを盲信して手入力を認めないUIにしてしまうと、このような事業所の住所が入力できなくて詰む。説明すら読まないくせにドヤ顔でマウント取りに来るなや
住所←これ自体が時代遅れ (スコア:0)
住所なんて昭和の表記をそのまま入力させる（その入力しか受け付けない）というシステムなんとかならないのかな。
地球全域を緯度経度のようなグリッドにして、英数字数文字で位置を表現する提唱をgoogleかどっかがしてたよね。
そういうのを入力したら自動で住所設定してくれたらいいのに。もちろんそれしか受け付けないのはアウトだけど併用してくれたらそれだけで楽になる。
＃単純なグリッドだと集合住宅などが表現できないから、郵便番号を拡張したガラパゴス規格でそういうのが欲しい