ネットで買い物をしていて、住所を入力したら「住所欄には全角しか使えません」とエラーがでて腹がたったことありませんか？
僕はもう「数字=半角」（全角は単なる文字)というのに慣れすぎてるので、いつも番地やマンションの部屋番号はつい半角で入れちゃって毎回毎回エラーになります。どう考えても不親切なんですが、あれって何でなくならないのでしょうか？
仮説1.半角数字を全角にシステム側で変換するのが難しい(Javaとかだと難しい？？)
仮説2.実はほとんどの人は住所のあとの番地を打つ時点で半角に切り替えないので、全角のままの方が自然？
そもそもあの全角チェックって何のエラー回避なんでしょうか
No.1
13539
1198
14pt
https://www.ringbell.co.jp/after-service/5breakage.htm
半角カタカナ(例:ﾊﾝｶｸｶﾀｶﾅ)はご使用になれません。カタカナは、すべて全角でご入力ください。
https://www3.toshiba.co.jp/dvd/j/contact/form_jp.htm
半角カタカナや特殊記号の入力はご遠慮ください（正常に表示されない場合があります）。
半角カタカナ対策だと 思われます。
No.2
323
14pt
こんなサイト見つけました。
自分の見解としては、入力された数字文字をサーバ側で必要な形に変換してくれれば何の問題もない事だと思うので、サービス提供側の怠慢だと考えておりますが。。ま、登録画面などは一度しか通らないから、開発側にとってはどうでもいいことと軽視されてしまうのかもしれませんね。
まぁ確かに怠慢かなとも思うのですが。
でも、ちゃんと全角/半角チェックを行って、再入力フォームをだして、おまけに住所入力の横に赤文字で「半角文字は使えません」なんていう親切なメッセージを出したりするのは、割と手がかかってますよね。
だから、半角チェックまでしておいて変換してくれない、というあたりのポリシーが謎なんですよね。
No.3
134321
14pt
私も半角数字の方が全角数字よりも byte 数が少なくて幸せだと思う一人です。
全角と半角が混ざっていると、例えば、「○○町1-1-1」(半角数字)で検索した場合に「○○町１－１－１」(全角数字)が引っかからないとか、色々と弊害があるので、質問のサイトでは、全角に統一しようとしているのではないかと思います。
前の回答者の方がおっしゃっているとおり、半角カタカナを禁止する意味も込めて、全角での入力を強制しているのかもしれませんね。
マンション名とか、アパート名とか、カタカナを使う住所も結構ありそうですし。
私は、カタカナは全角で、英数字は半角で入力すること、あるいは、サーバ側で自動変換することを推進したいと思います。
僕もプログラミングなどを仕事にしてるので「カタカナは全角で、英数字は半角で入力すること」という意見には全く賛成なんですが、世の中の大多数は実は「イチイチ番地だけ半角で打つなんて信じらんない」という意見なんじゃないか、とか思います。実は半角数字チェックでハラがたってる人なんて少数派だったりして、と。
No.4
742
14pt
伝票に打つ時に機械の方で半角対応できない所が多いんじゃないでしょうか。
半角数字で打って通ったこともあるんですが、数字が横に寝ていたり、繋がりが変だったりしますよ。
お！新しい意見。全角の方が印刷機フレンドリーってことでしょうか。ふーむ。
No.5
13412
14pt
初心者ユーザに、ハイフンを長音記号で入力してしまうユーザが多いからではないでしょうか？
ハイフン：はてな町１－１２－３
長音記号：はてな町１ー１２ー３
全角なら問題ないんですが、これを半角でやると、長音記号が半角カナなので問題があり、さらにエラーメッセージに「半角カナは使えません」と表示しても、半角長音記号がカナだとは気づいてもらえないケースが多いと思われます。
それならばそもそも全角で入れさせればわかりやすい（というか開発の手間が省けるし、利用者からの問い合わせも減る）ということなんだと思います。
怠慢だというご指摘はもっともだと思います。
これ、逆にいつも全角で数字を打てと言われると、ハイフンをどうやってだしたらいいかとまどいます。つい音引きを入れちゃう。
と思って今やってみたら、Windows(MS-IME)でひらがなモードにしてると全角数字の後は音引きじゃなくて自動でハイフンになるんですね。。知らなかった。
No.7
56271
14pt
http://www.gihyo.co.jp/book/2000/178731/4-7741-1005-1.pdf
7ページ目
オフコンや汎用機とのデータ変換の可能性がある場合、全角フィールドと半角フィールドを明確に分けるのが通例となっています。
フロントはWebだけどバックエンドがオフコンや汎用機で、データベースの住所を入れる部分が"全角のみ"という事情なのではないかと想像します。
となると次は、"そんなのWeb側で全角に変換すればいい"となるでしょうが一つの問題がありそうです。
半角文字を1、全角文字を2と数えるとデータ長の制限を超えないけれど、半角文字を全角に直すとデータ長の制限を超えてしまうケースです。
こういうケースになったとき、利用者になんと説明して再入力を促せばいいのでしょうか?
「入力された住所をデータベースに格納する時に全角に直すのですが、そうするとデータ長の制限を超えてしまいます」??
わけがわかりません。
この場合は最初から「入力可能なのは全角文字のみで○○文字です」としてしまう方が混乱がないでしょう。
以上、ただの想像ではありますが、納得できる説明として思いつくのはこれぐらいですねぇ。
ふむむ。なんか説得力ありますね。
コメント欄に「安易に真似してしまった、とも考えられます。」とありますけど、汎用機時代の「通例」となってたんで、ついついそれから離れない開発者/発注主がそういう仕様を考えつくのかもしれませんね。
そういえば、知り合いで出版業界では数字は１文字なら全角、２文字以上ならべる時は半角にしろ、と教わったのでいつもそうしてるって人がいました。「８月10日」みたいな感じ。ちょっと脱線でした。
No.8
1844155
14pt
文字の表現は文字コードとその文字コードを
具体的に処理する手段としての符号化方法
があります。
文字コード（符号化文字集合）は
JIS X0208 第一水準
UNICODE
ASCII
JIS X0201 JISローマ字、カタカナ
等があります。
その文字符号化方法として
シフトJIS
ＥＵＣ
ＵＴＦ－８
等があります。
http://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97%E3%82%B3%E3%83%B...
http://ash.jp/code/unitbl1.htm
例えば１０文字以内で入力する項目とします。
見た目には、全角１０文字の幅の入力可能な
項目が作られています。しかし半角（半分の幅）
は０．５文字分だと考える人もいます。
システム的には幅に関係なく文字１文字です。
システムが手抜きでなく良心的にそうしていると
仮定すると、利用者に入力してもらったデータ
をプログラムで自動修正すると入力桁数を超えて
しまい消えてしまったり桁数が長すぎた場合
等の新たなエラー原因になる可能性があります。
又最終的にデータを保存する手段として
データベースを利用する場合、少し前までは
文字コードでデータを保存することが多く
その場合、半角文字の１バイト系文字コードと
複数バイト系の文字コードを混在させて保存
出来ないシステムも存在しる為、混在させて
保存は難しい場合もあります。
＞全角チェックって何のエラー回避なんでしょうか
・桁数オーバーを正確
・半角で符号化されたデータを保存する
場合や、文字コード変換時に誤変換
される可能性がある
（特に１バイト半角カナ）
・データベースに保存出来ないから
親切にエラー時半角部分を全て全角に自動変換
するとそれはそれでユーザが入力したデータ
でない。システムが勝手に入力したデータだから
後でこの登録（契約）が無効だと主張する人が
いてもおかしくないご時世なので
最後の「親切にエラー時半角部分を全て全角に自動変換するとそれはそれでユーザが入力したデータでない。システムが勝手に入力したデータだから後でこの登録（契約）が無効だと主張する人がいてもおかしくないご時世なので」
というところが、確かにそうかもしれないないなと思わせます。
桁数オーバーについては、そんなにギチギチに設計しなくても、と思うのですが、、結構シビアに作るものですかね。
No.9
4914
13pt
http://www.hotfix.jp/archives/word/2004/word04-17.html
半角文字の使用を認めると、ＨＴＭＬやＪＡＶＡＳＣＲＩＰＴなどのタグをわざと入力して、ページのソースを破壊される恐れがあるため、これを防ぐ手段（サニタイジング）でしょう。また、○×町
1-2-34などのように、番地の部分のみ半角文字の使用を認めようとすると、チェックプログラムが非常に難しくなるのだと思います。
うーん。そうですかね。
サニタイズはやってるのが普通とういか、受け取ったデータは半角チェックの前にひととおりサニタイズすべきなんじゃないですかね。
No.10
1035
13pt
正確な住所が何丁目何番地という記述だから仕方がない。
使い勝手をよくするためには、半角ハイフンのほうを駆逐する必要がある。
うーん。これは納得できないですね。
○○町2-8-15みたいな表記も十分通じるし、もし本当に何丁目何番地という記述が必要なら、そういうエラーを多くのサイトが出すはずですよね。ハイフンは使わないでください、部屋番号は何号室まで書いてください、みたいな。
No.11
3344440
13pt
最終的なデータは統一する必要は有るでしょうけど、入力欄で制限する必要ありません。
変換処理などたいした処理でもないですからね。
つまりは単にプログラマの手抜きですよ。
そういうことが起こる理由は簡単。仕様書で要求されていないからです。
仕様書で要求されていない処理を加えてもコーディングの手間とテスト工数が増えるだけで一文の得にもなりませんからね。
手抜き説には基本的に賛成です。
でも、不思議なのは、全角半角チェックと再入力のフローまで仕様書で定義しておいて、なぜ変換まで仕様に盛り込まれないのでしょうか。
もしかしたら、住所欄は全角しばりでエラー時はあえて再入力させるというフローの方がユーザーフレンドリーだったりして？というのが疑問なのです。
No.12
10
13pt
インターネット黎明期の名残では？
今ならPerlだとJcode、PHPならmbなんちゃら関数があって
変換も一発ですが、昔は大変だったのかもしれません。
で、誰かが製作マニュアルみたいなものに
「全角以外の文字はすべてはじくべし！」みたいな格言めいたことを書いちゃって、
今でもそれを忠実に守る頭の固い開発者がいたりするのかもしれない…。
う～ん、無理に考えて見ましたけど、こんなのありえない気がします。
やっぱりよく分からないですね（笑）
うーむ。でも誰かがマニュアルつくっちゃって、それが右へ習えで流行っちゃってる、という線はありそうですよね。
そういえば、リンクポリシーのページがどっかのデザイナーのつくったひな形がコピーされてる、って書いてあるブログがあったけど、そういうものかも。話それましたね。
No.13
137797
13pt
こんにちは。
私は専門の知識がなく、調べても分かりそうにありませんので予測ですが…。
親切にエラー時半角部分を全て全角に自動変換
するとそれはそれでユーザが入力したデータ
でない。システムが勝手に入力したデータだから
後でこの登録（契約）が無効だと主張する人が
いてもおかしくないご時世なので
sawamurさんが私と同じことを考えていました。
何らかの理由で全角のデータを得ることが必要で、
でもユーザを無視して勝手に変換するには忍びない、
という考えから生まれたのではないかと予測します。
なぜ全角のデータが必要なのか、ですが、それについてもひとつ考えがあります。
それは、この住所がどのように使われるかに関係します。
例えば、住所はそのままはがきなどに印刷されてDMとして
利用されることがあるだろうと思います。
この住所の宛名、横書きも多いですが縦書きにすることも少なくないはずです。
ここで縦書きにしたときに生じる問題が、半角文字の扱いです。
普通、縦書きにテキストに半角文字が入っているとそれは90度回転されて配置されます
（MS Wordなどをお持ちでしたら実験してみてください）。
そんなもの回転させ直せばいいのですが、字数によってはきつくなる場合があります。
ですので半角の場合には字数を数えてx文字以下だったら回転させ…
と、ひと手間多い作業が、印刷するときに必要になると思うのです。
その手間を省くため、ユーザに入力させる際に半角をはじいているのではないでしょうか？
http://www.shuiren.org/chuden/teach/word/syosiki/kakucho1.htm
Googleで「縦中横」で検索して見つけたページです。
うーん。でもネットショピングの宛名とか、帳票類とか、縦書きにすることはまずないと思うんですけど。
少なくとも僕は受け取ったことないです。
No.14
540
13pt
Σ:)＜与えられたソフトがそういう仕様だったからそのまま使っている、が正解だとおもいます。
そっち関係の背景を調べてみるのも面白いかと思いますよ？
こういう便利なソフトもあるみたいですね
http://www.forest.impress.co.jp/article/2006/08/28/okiniiri.html
quintia
2007/03/09 17:19:32
1
1
2
2
1
1
kurukuru-neko
b-wind
sawamur
kenki1977
sawat
半角カタカナはまぁ分かるんですが、なんで数字まではねちゃうところが多いんでしょう？その方が実装が楽？
あと、上の仮説２の逆みたいですが、カタカナを打つときに無意識に半角カナを使ってしまう人って結構いるんですかね？