- 締切済み
ログインする際のIDやパスワードをなぜ全角対応されないのでしょうか？
ログインする際のIDやパスワードをなぜ全角対応されないのでしょうか？ 正規表現を使って禁則文字以外を見分けることもできるはずです。 パスワードをハッシュ化する際も全角で対応できるはずです。 開発を行う現在の各種フレームワークでは、unicodeも標準で対応しているはずです。 データベースも全角で問題なく記録でき、高速化、大容量化されています。 にもかかわらず、未だ全角対応されないのは、何か理由があるからなのでしょうか？
- yokyok
- お礼率100% (14/14)
- その他([技術者向] コンピューター)
- 回答数11
- ありがとう数38
- みんなの回答 （11）
- 専門家の回答
みんなの回答
- superside0
- ベストアンサー率64% (463/719)
- superside0
- ベストアンサー率64% (463/719)
・ログイン処理の漢字コード変換ミス（短いと誤認識します） ・UTF-8を出せない携帯電話などあるので、誤認識対策でUTF-8固定化も難しい ・ログイン後にそのIDでリレーションしたりファイル名にしたりする部分で日本語対応が必要 ・オープンソースのフレームワークやライブラリなんかでも、全部日本語ID対応のパッチを作らないといけない の問題があるので、これを開発する工数よりも <input type="text" name="id" style="ime-mode:disabled"> にしておくだけで、(間違える人が大抵つかっているIEでは） 強制半角入力にしてくれるので、私はこれで回避することが多いです。 まぁ必要とされるのであれば、それで作ってしまえばいいのではないでしょうか？ 開発費用は増えるし、逆に全角対応することで漢字コードに起因するトラブルも増えるのでそれのサポート工数は増えるでしょうけど。
お礼
回答ありがとうございます。 ・ログイン処理の漢字コード変換ミス これは、システムが誤認識するということでしょうか？ ごくまれにしかないのであれば、頻繁に入力するものでもないので、問題ないのかなと思いました。 ただ、頻発するようでしたら、これは問題ですね。 それはバグとして解決してもらえないものなのでしょうかね。 ・UTF-8を出せない携帯電話 携帯電話に関しては、Shift-JIS → UTF-8 にシステム側でエンコードしてあげたら問題なさそうです。 ただ、これもマルチバイトの問題がどこかに隠されているのでしょうね。 ・ログイン後にそのIDでリレーションしたりファイル名にしたり テーブルのマスターキーを数値してしまえば、リレーションに問題が出ないと思いますし、その方が効率もいいでしょう。 ・オープンソースのフレームワークやライブラリに日本語ID対応 フレームワークというよりは、出来合いの認証機能のついたシステムでしょうか。 事前にあるものを変更するには、工数が非常にかかりますよね。 これは、はっきりいって苦痛ですので、しない方がいいでしょう。 IMEの強制OFFを使うという技は、ききそうですね。 参考にさせていただきます。 よく秘密の質問というのがありますよね。全角でも入力できる。 あれこそ、いわゆるIDとPasswordと同じじゃないのかと思いました。 なぜIDとPassowrdと同意のものを２度入力させる必要があるのかという疑問を感じています。 作ってしまえばいいのはわかります。 ただ、パスワード全角対応という事例を聞かないもので、そこにはコスト以外に私の知らない問題点があるのかもしれないと思いました。 そこで、この質問に至ったわけです。 おかげさまで、漢字コードに起因するトラブルが増える可能性があるという懸案を知ることができました。 しかし、それほどまでにシステム的不安要素がマルチバイトには未だに隠されているのですか。
- MrBan
- ベストアンサー率53% (331/615)
パスワードの性質上、全角「ＡＡＡ］と半角「AAA」は 別物と判断するべきだと思いますが(もしかしてここから反対ですか？)、 変に全角/半角の両方が入力できると、どちらだったのか混乱しませんか？ そもそも、パスワードによる本人認証の仕組み自体、 利便性とセキュリティのトレードオフであって、 十分な長さのランダムな文字を入力することを考えれば、 日本語だろうが、英語だろうが、英字だろうがひらがなだろうが、 本質的に大差ないはずです。 ドラゴンクエストの「復活の呪文」みたいなのが理想ですか？ 変に全角対応して脆弱性を生むくらいなら、今のままという判断は セキュリティの観点で見て、あながち間違ってないと思ってます。
お礼
回答ありがとうございます。 別物と判断するべきかどうかですが、コンピュータにとっては別物です。 人間にとっては、同じ意味を表します。 例えば、同じ半角だとしても、「AAA」と「aaa」でどちらだったのか、混乱することはありませんか？ つまり、それは全角半角の問題ではないと思います。 ドラゴンクエストの復活の呪文、あれは全部ひらがなでしたね。 はい、そうです。 ひらがなに限らず、漢字やカタカナも使えてもいいのではないかと思いました。 ただ、あまり見かけないので、私の知らないセキュリティ的な問題があるのか知りたいと思い、質問に至ったわけです。 全角対応することで脆弱性が生まれるのは、事実なのでしょうか？ その可能性が私には見えないので、その点が知りたいわけです。
- mashkun
- ベストアンサー率23% (86/364)
わかりやすくすること自体は大切ですが、これだけは理解しておいてくれないと困ると言うことはどんなシステムにでも存在します。 電話「番号」と言いながらも、実は「数字列」であって、03xxxxyyyyを3xxxxyyyyとダイヤルしてはいけないのと同じことです。
お礼
回答ありがとうございます。 確かに、理解をしていなければいけないこともあるでしょうが、このケースはそういう部類に入らないようないのではないでしょうか？ 家電製品でも、すべての製品が起動ボタン(Powerボタン)を押さなければ使えないということはありません。 冷蔵庫は、コンセントに差し込むだけで動き出します。 通電しなければ使えないということは理解してもらわなければいけませんが、起動ボタンを押すかどうかは製品によって異なります。 このケースは、その起動ボタンにあたると思います。 暗証番号や電話番号、郵便番号は、あくまで番号(数字列)ですので、桁のある量を表す数ではありません。 数字列は、数の羅列ですので、正確には数ではありません。 だから、フリーダイアルの0120は、数字列であるため量を表さず、120(百二十)ではないのです。 いかがでしょうか。
- okweb-goo
- ベストアンサー率29% (283/952)
右書きが問題なのではありません。 システムが正常に運用中は問題ないかもしれませんが、ユーザからサイトのことでアラビア語の問い合わせがきたら困るでしょ。世界中の通訳者を用意しておくのですか？ 現在のインターネットは、ＵＲＬにしてもＤＮＳにしても、英語が一応理解できることが暗黙の了解だと思います。
お礼
なるほど、そういうことでしたか。 ありがとうございます。 では、英語で問い合わせが来た場合は、困らないということですか？ いえ、半角英数を利用する英語ですら、困ってしまう運営も多数存在すると思います。 そういうわけで、問い合わせの言語の問題ではないと思います。 暗黙の了解というのは、迷信でしかありません。 当時、パソコンというのは、英語が理解できる一部のコンピュータ技術者にしか利用することが出来ませんでした。 しかし、現在、あらゆる人がそれなりに使いこなしていると思います。 したがって、インターネットもわかりやすいような表現やインターフェイスを用意することで、英語の理解がなくとも認識することが出来るようになると私は思っています。
- okweb-goo
- ベストアンサー率29% (283/952)
unicodeで全角対応はしていますが、そうしたら世界を相手にしなくてはなりません。サイト管理者は右書きのアラビヤ文字なんかがきたらどうしますか。事実上標準のローマ字２６個と算用数字あたりで処理すべきです。
お礼
ご返答ありがとうございます！ アラビア語が入力されようが、タイ語が入力されようが、ブラウザがunicodeの表示に対応している場合は表示されます。 また、データベースもunicodeで記録することができます。 システム内部の処理もunicodeで実現できます。 なぜそうすべきなのか、私には理由がわかりません。 やや気になる点は、パスワードをメールで送信する場合でしょうか。 日本の場合は、メールをShift_JISで送受信する場合が多く、UTF-8の場合は文字化けしてしまう環境もまだ存在します。 unicodeのパスワードをメールで送信しなければ、この問題は解決されると思います。 ところで、右書きのアラビア語の場合、どのようなところで問題になるのでしょうか。 よろしければ再度教えていただければと思います。
- shimix
- ベストアンサー率54% (865/1590)
ANo.2です。 入力誤りを補正するために「mb_convert_kana（オプションが非常に多い関数のひとつですね）」を使うことはけっこうあります。ただ「ログインのID、パスワードの入力」は入力フォームで（IEだと）IMEをOFFにしてしまいますよね。個人的には「操作ミスに対する備え」としてはそれでじゅうぶんじゃないかと思っています。他のブラウザでは強制的にIMEのOFFは出来ませんが、他のブラウザを使われるような方はまず間違わない部分だし（苦笑）。 ちなみにログイン以外の部分でのIMEの強制ON/OFFはかえって鬱陶しい（直感的に操作しにくい）と思うので、基本的にはやってません。
お礼
再度ありがとうございます！ インターネットブラウザの入力フォームのIME設定は、引き継がれませんでしたか？ パスワード専用フォーム(type="password")は、IMEが自動でOFFになるようですが。 もし、全角を許可する場合は、パスワードフォームを廃止し、テキストフォーム(type="text")に変更しなければ、ますます入力内容がわかりにくくなると思います。 携帯電話のように、入力が完了した段階で表示が隠されるインターフェイスを実現できればいいと思うんですけどね。 ID、パスワードともにテキストフォームにした場合は、IME設定が引き継がれ、あえて全角で入力しようとするため、全角でも問題ないような気もします。
- gmataw
- ベストアンサー率50% (12/24)
> 半角と全角の概念が理解出来ない人がいらっしゃるからです。 上記のユーザーが多いとして、全角を許可しても問題解決にはならないと 思います。 全角で「ＡＡＡ」がパスワードなのに、半角で「AAA」と入力してログイン 出来ないとクレームが発生したり。。。 そもそも、半角・全角の概念がない人はどっちに転がっても同じだろうと 想像します。
お礼
ははは！その通りですね！ ありがとうございます。 例えば、半角のニックネームやログインIDというものになじみのない人にとって、全角でそれを自由に決められるというのは、意外に心地良く感じる１つのポイントではないかと思っています。 また、全角で入力可能になるなら、ＡＡＡというパスワードを指定する人は、あまりいないのではないかと思います。 もっと、「明日の天気は雨」みたいなフレーズも増えるのではないでしょうか。 だとすれば、これは有効じゃないかとも思います。
- kaden100
- ベストアンサー率47% (11/23)
逆に聞きたいのですが、全角への対応が必要な理由はなんでしょう？ 要望が多ければ、対応するシステムをあるとは思いますよ。 例えば、IDがハンドルネームと共有され、IDへ全角文字が使えるサイト（システム）も実際に多いですし。 パスワードに全角を必要とする理由は、あまりないかと。
お礼
ご返答ありがとうございます！ IDに全角が使えるケースは、確かに増えてきましたね。 > 逆に聞きたいのですが、全角への対応が必要な理由はなんでしょう？ 半角と全角の概念が理解出来ない人がいらっしゃるからです。 解釈できる意味は同じなのに、機械的な意味合いが違うということを理解できないのです。 この概念が理解できなければ、日本で認証機能を使うことが高いハードルになってしまいます。 また、全角も許可した場合、機械的にパスワードを破られる可能性も少なくなり、覚えやすいフレーズを作りやすくなるのではないかと思いました。
- shimix
- ベストアンサー率54% (865/1590)
「マルチバイト文字使用可能」にするメリットがないからでしょう。 ただでさえPOSTされた文字コードが不正でないかをチェックしないといけないのに、ログイン部分でまでやりたくない気はしますけどね。全部utf-8に出来るのなら少しはマシなのかもしれませんけど。 ＃UIとしても、パスワードのような「入力した内容が表示されない」部分でIME通すのはいやだなぁ
お礼
ご返答ありがとうございます！ 初心者の方は、全角も半角も区別することができませんし、概念すら理解することもできません。 文字を認識した場合、どちらも同じに思えるからです。 そうお考えになるのは、やはり開発者のエゴでしかないと思います。 手数がかかる、お金がかかる。だからやらない。 ごもっともで、理解もできます。 しかし、最近の環境では、さほど手数に影響が出なくなってきています。 にもかかわらず、増えてこない理由があまり理解できません。 私の知らない何か理由があるのかと思いました。 また、パスワード部分を***にされるのにも困る人が多数います。 キーボードを打ちながら画面を見ることができる人はいいですが、そうでない人は、キーボードでの入力ミスを画面で確認することができないため、戸惑うことがあります。 誰でも使うことができるUIが求められると思います。
- 1
- 2
お礼
お礼が遅くなってしまい申し訳ありません。 長文のご回答、ありがとうございました。 文字コードを変換する際に、文字列が短い場合は、誤認識しやすいようですね。 とすれば、例えば、６文字以上の入力が必須という制限をつけた場合は、大丈夫ということでしょうか。 95%以上大丈夫なら問題ないと思うのですが、この文字数と誤認率の関係について何か参考になるページをご存知であれば、よろしければお教え下さい。 ここ２、３年の間に、ブラウザ(携帯電話のものも含む)は、ほとんどがUTF-8に対応してきています。 この対応率の向上により、今後は送信側と受信側の文字コードを統一できるのではないでしょうか。 携帯電話の機種によってサービス提供をしない例がいくつもありますので、これはポリシーの問題なのかもしれませんね。 パスワードを覗き見されてしまうという問題は、確かに解決が難しいですね。 確認はしていませんが、テキストフォームから見えないパスワードフォームに文字列を移動してからsubmitをするといった方法だと、もしかしたら履歴に残らないんじゃないかとふと思いました。 おかげさまで、随分と問題点の整理ができました。 ありがとうございました。