の質問に便乗です。
アンケートやモニターサイト・その他サービスサイトに入会・登録する際に於いてはほぼ９９％ ユーザーに対してフォーム入力させる”数字”が全角か半角かに指定しています。
それで、ユーザーが間違って電話番号を全角で入力したり、住所の番地を半角で入力すると１００％エラーを返してきます。
Perlをかじったことのある私としては、置換は基本中の基本だと思っているので、不思議でしょうがありません。（ちなみにデータベースの知識は皆無と思って結構です）
なぜ、サイトの構築者は柔軟に「全角数字→半角数字」or「半角数字→全角数字」、もっと欲を言うと郵便番号のハイフンの削除などCGIでやろうとしないのですか？
No.1
47
2
25pt
開発期間の問題や、仕事をしている・請け負った会社and人の資質にもよると思います。
１、「とりあえず動けばいい」って思って作っている人もいますし。
２、プロジェクトの工程で、この全角半角の条件判断の工程に時間をかけれなかった。
３、担当した人の技術・発想がなかった
４、しっかりとした、計画を立てずに作った
などではないでしょうか？
データベースの仕様はあまり関係ないと思います。
全角・半角で登録された情報を、データベースの形に合わして変換すればいいだけなので、データベースは関係ないと思いますよ。
No.2
190
25pt
http://www.atmarkit.co.jp/fdotnet/aspexp/aspexp12/aspexp12_01.ht...
システムを作る側の視点だと、ｄｂの定義ありきになっているのかもしれないですね。
全角数字及び全角ハイフンの場合、ご指摘のような変換をしてしまえばいいのですが、混在している場合も考えて一文字づつ判断＋変換をしなければならない、となると、システムが重たくなることが考えられる。システムが重くなってユーザーにあきらめられるくらいなら、早くエラー画面を返した方が開発コストも安いし、となるのではないでしょうか。
おー、この分野は全く知らないのですが、ASPとかだとテンプレートみたいなものがあるということでしょうか。。。それならば、おなじアーキテクチャのCGI使ってるならばほとんどのサイトが同じ様なフロントエンドになるのも納得できますね。
あえてエラーを出しやすくするという手もセキュリティ的に考えたら納得できる気がします。
私の場合、昔ながらの掲示板のPerlコード位しか見たこと無いので、投稿内容をそのままJCode.plに丸投げ、という手法しか頭になくて。
PHPの場合はどうか知らない（というか概要とかコードすら見たことない）のですが、マイクロソフトみたいにある程度デフォルトのシステムが出来てしまってる場合は、プログラマ側も、所属請負会社側もちょっとした気遣いによるコード変更（追加）が割に合わないということでしょうか。
かといって、私みたいに気を利かせて、ボランティア的にオリジナルコード追加しても、引き継ぎとかASP（IIS）のバージョンアップなどで、メンテナンスコストがかかるとか（あくまで想像ですが）
No.3
17412
25pt
基本的に異常なフォーマットのデータは受け付けないようにするのが
基本です。
ただ、これらの機能はJavaScriptなどで対応しているので
クライアント側に影響します。
(JavaScriptを無効にしているとか対応していないブラウザだとか)
そのため、その上で受信するプログラムの方でも対処が必要になり
ます。
要は、念のためにおかしなデータは送信させないということですね。
また、MS-IEの場合はフォームにime-modeプロパティを設定することで
IMEを強制的に制御できますので、例えば姓名などの日本語を入力
する必要がある部分は自動でIMEをONにしてローマ字での読みや
郵便番号とか電話番号のような半角英数字のみしかあり得ない、
部分ではOFF(無効)にするなどすれば入力する側もいちいちON/OFF
切り換えなくて済むので楽です。
(ただし、ぼくはたまにそれを忘れてIMEモードを切り換えてしまう
ことがありますが、その場合は二度(三度?)手間になってしまいま
すね)
これはIE独自実装なので他のブラウザでは無効なのが問題ですが。
ＩＭＥの制御についても、ちょっとお節介だなぁ、と思うときもあります。
たとえば、私の場合、「＠め」という読み方でメールアドレスを登録しているのですが、該当フォームでＩＭＥ起動不可の場合だと、これまた長いアドレスを打ち直さないと行けない。はっきり言って、精確にメアドを覚えているかどうか、毎回不安になります。
結局これまでの回答から、私なりの結論を申し上げると、（アクセスなどで入力段階で、データとしてあり得ないものはエラーを出して入力拒否）一般のデータベースの入力規則をそのまま踏襲してしまっているということでいいでしょうか？
しかし、企業で雇われて、入力作業をするならともかく、ネットにおいては、全くＰＣに関係のない人とか、それこそサービス業として、お客様に対して柔軟な姿勢で行くべきと思っているのですが、そういう発想とセキュリティはトレードオフの関係なのでしょうか？ わたしは、違うと思います。
No.4
190
25pt
> ネットにおいては、全くＰＣに関係のない人とか、それこそサービス業として、お客様に対して柔軟な姿勢で行くべきと思っているのですが、そういう発想とセキュリティはトレードオフの関係なのでしょうか？
不特定多数からの入力を受け付ける画面は、利便性よりもシステムの安定運用を優先すべきで、そのためにはなるべく入り口でデータを制限することがひいてはユーザーのためになる、という信念でもってやっているひとも、いるかもしれないですね。
でも私は、そういう要望を汲み取ったり、自分で感じ取ったりできるシステム屋さんが少ないだけではないかと考えます。もしなんとなく感じても、「面倒臭い」とか「工数が」とかいう都合で後回しにしてしまう。実際に対応するとなれば、やはりテストですとか、ドキュメンテーションですとか、それなりに時間はかかるでしょうから。
ですから、お客様の要望を組むこととセキュリティが相反する、ということではないのではと私はおもいます。
なるほどう。労働時間や賃金も含めて業界体質みたいなものもあり？
No.5
17412
25pt
プログラミングの考えとして、バグを作らないように組むと
いうのがあります。
想定される操作以外の操作はさせないということです。
(それ以外の操作はすべて無効にする)
操作できる可能な動作が限られていればその分不具合もでにくい
ですし、でても発見しやすく修正もしやすいです。
相手方が異常なデータや無効なデータを送信しているのにそれを
受け付けてしまうと想定した動作ができなくなる可能性があり
ます。
これを防ぐためというのもあるのでは？
こういうのはよくCGIの本などでもでているような方法です。
なお、どうしてCGI側でやらないのかというとパターンが多すぎ
だからというのもあると思います。
ユーザー側はどういったミスをするか分かりません。
考えられるだけでも数字しか入力できないところに英字とか日本語
とか入れてくるかもしれません。
この辺りまでは想定できても、もっと想定できない操作をする
可能性があります。
それらを全部チェックするのは大変です。
(一つ一つそれに一致していないかifなどで確認する)
それよりは、条件に一致しないのをはじく方が明らかに簡単で
もれがないです。
まあ、どう思うかは別としてこういうのはプログラマとユーザーと
で意見の一致を見ない例の一つなんでしょうね。
(プログラミングの容易さや仕様上の問題などとユーザーにとっての
使いやすさやアクセシビリティは同一じゃないと)
ＩＭＥの制御についても、ちょっとお節介だなぁ、と思うときもあります。
たとえば、私の場合、「＠め」という読み方でメールアドレスを登録しているのですが、
これについてはぼくは別のフォームなどに入力してそれをD&Dする
なりコピペするなりしています。
ところで回答が分かりにくいでしょうか。
(自分で見直してそう思ったがこれ以上丁寧に分かりやすく説明する
力=文才がない(^_^; )
いえいえ、わかりやすい回答どうもありがとうございました。ちょっと斜め読みしてました（汗。
単純なことと思っていたことが、そういうわけでもないと言うことが、身近な例で目から鱗でした。皆様どうもありがとうございました。
1
1
1
1
19
18
＞全角・半角で登録された情報を、データベースの形に合わして変換すればいいだけなので
そうですよね。とりあえず、プログラミングや業界をかじったことはあっても、データベースだけは全くやったこと無いので、予防線の意味で但し書きしました。
ところで、yomyさんはアンケートに答えたことが無くても、（それこそ はてな など）ネット上には個人情報登録を求める場合がありますが（あ、ネット通販もそうか）、同じ疑問持ったことありません？
私の実感としては、本当に１００％、譲っても９９％の入力フォームに於いて、そんなくだらないエラーで今までその他の項目入力に費やした時間も相まって、登録する気無くなるのですが・・・
便乗質問参照元の半角カタカナとかいうレベルじゃなくて、「数字」ですよ。私のようなちょっとかじった程度のバカでも、単純に０～９までの置換コードを羅列するだけでいいと思うのですが。