web-dev-qa-db-ja.com

HTML4：別のフィールドでIBANを挿入しますか？

IBAN番号の入力フィールドがわかりません。多くの場合、IBANはさまざまなフィールドに分かれています。

XX00 0000 0000 0000 0000 00

時々、顧客はIBANを1行で表示します

XX00000000000000000000

1行にIBANが含まれている場合、読み取りと書き込みによって絡み合う可能性があります。

何をすればよいでしょうか？

  • フィールドを分離し、カードにIBANを1行で表示している顧客を混乱させるリスクを冒しますか？
  • スペースを作成できる入力フィールドを1つ作成しますか？
  • 追加で有効なIBANの例を示しますか？

編集：IBAN: XX00 0000 0000 0000 0000 00から最初にXX00のみを入力して、怒るお客様がいます。

usabilityinput-fields
4
Peter Rader

さまざまな形式と構文でIBANを入力することをユーザーに許可し、アプリケーションにインテリジェントに解釈させる。ユーザーはおそらく、システムがどのような形式を想定しているのかを知らないはずです（そうする必要はありません）。

http://quince.infragistics.com/Patterns/Forgiving%20Format.aspx

4
Stevy

フィールドを分離しないでください。これらのフィールドを分離すると、誰かを激怒させることは完全に理解できます。

定型入力は、フロントエンドのソリューションです。

http://digitalbush.com/projects/masked-input-plugin/

http://jsfiddle.net/49HVc/1/

このデータをどこかに保存または送信する場合は、厳密なバックエンド検証があることを確認してください。

3
MonkeyZeus

ユーザーがアカウントまたはクレジットカード番号を入力すると、通常は（お金が関係するため）フォームを送信する前にそれを見て、正しい文字/数字を入力したことを確認します。ユーザーが自分のIBANをカードの1つの長い行に書き留めている場合でも、画面上にある小さなチャンクの内容と照らし合わせて検証します。 IBAN全体をワーキングメモリに保持する人や、IBANを暗記して一度にすべてを確認できる人はほとんどいません。

IBANを複数のフィールドに分けると、この検証プロセスが容易になります。

次の問題を忘れないでください。

  • セット内の次のフィールドに進むために、ユーザーにタブやクリックを強制しないでください。私が見たほとんどのサイトでは、自動的に次のフィールドにカーソルが移動するため、複数のフィールドにわたってIBAN全体をシームレスに入力できます。
  • IBAN全体のコピー/貼り付けが引き続きサポートされていることを確認してください。これは、私の経験では一般的にかなり悪い（つまりまったくない）ことです。
1
Franchesca

入力をできるだけ変更しないでおくと、ユーザーを「もつれる」（「混乱する」という意味ですか？）これは、フィールドにユーザーが入力した内容が表示され、正規化がバックグラウンドで行われることを意味します（IBANを変更できないことを確認してください。書式設定のみです！）。

コピーと貼り付けを機能させるには、1つのフィールドのみを使用します。 Stevyが既に言ったように、この入力フィールドは可能な限り寛大にしてください：スペースを受け入れます。内部で小文字を大文字に変換することもできます。

そこにはチェックサムがあるので、意味のある例を作成することはできません。 1つ（またはいくつか）の例からそのアルゴリズムを再構築することはできません。例は、システムが一般的に使用されている複数のフォーマットから1つのフォーマットのみを受け入れる場合のみ役立ちます。最初のアドバイスに従ったので:-)、この追加のヘルプは必要ありません。 （また、誰もが1つの例からチェックサムを再構築できないため、「有効な」IBANが何であるかを実際に示すことはできません。

1
virtualnobi

定型入力*のある1つの入力フィールドを使用して、正しい形式としてユーザーをガイドします。ほとんどの定型入力スクリプトには、入力を選択した形式に制限することも含まれています。

*私の仕事用ネットワークはすべてのニースの例をブロックしているので、瞬間にリンクを見つけることはできませんが、グーグルするとあなたに例が表示されます。

0
edeverett