Web表单验证：最佳实践和教程

原文地址：Smashing Magazine
无责任翻译：Sekai

---

理想情况下，用户将必要的信息填入表单中，然后顺利提交。然而，用户经常犯二。这就是为什么我们要强调Web表单验证。Web表单验证的目的是保证用户顺利提交必要且格式正确的信息。在这篇文章中，我们将超越验证这一行为本身，来探寻不同的验证方式和错误反馈的技术和方法。

验证方法？

用户的输入可以在服务器端和客户端（浏览器）都可以验证。所以我们有服务器端验证和客户端验证。我们将讨论它们各自的利弊。

服务器端验证

对于服务器端验证，信息被传递给服务器并被某一种编程语言验证。如果验证失败，服务器端则响应客户端，包含表单的页面就会刷新并展现反馈。这种方式是十分安全有效的，因为这在Javascript失效时任然有效，并且它难以被居心叵测的用户绕过。但是另一方面，用户则不得不在没有得到任何响应的情况下填写表单，直到他们提交表单才能知道是否验证通过。这导致服务器响应速度变慢。

这种方式的例外是使用Ajax。Ajax可以让你用任意的形式去调用服务器的验证，并且立刻得到响应。这种情况下验证遵循某种验证规则，比如用户名是否有效之类的。你可以通过这篇来自jQueryForDesigners的优秀的教程来了解更多关于使用Ajax的知识。

此图显示了客户端和服务器端验证及其他技术之间的差异。

客户端验证

服务器端验证已经足以获得一个安全成功的验证了。但是为了更好的用户体验，你得设法考虑下客户端验证。这种类型的验证是使用一些脚本语言例如JS在客户端完成的。通过使用脚本语言，用户可以随着他们的输入就完成验证。这意味着一个更加快响应并且视觉效果出众的验证。

在客户端验证中，表单在验证失败时是无法提交的。验证是通过你/框架/插件建立的Javascript方法处理，在验证失败时，用户可以迅速获得反馈。

客户端验证的主要缺点是它依赖于Javascript，如果用户关闭了Javascript，他们可以非常轻松的绕过验证。这就是为什么验证应当总是同时部署在服务器端和客户端。通过结合服务器端和客户端验证，我们就可以取两者之长：快速响应，安全有效以及优秀的用户体验。

TypePad网站中客户端就完成了丰富且快速响应的反馈信息

验证什么？

当前我们可以部署有好几种验证类型：必填字段，正确格式和确认字段。

必填字段

最优先且最明显的验证就是必填字段——某些没有进行操作的字段将无法提交。因此，验证必须保证用户提供了所有的必填字段，并且少了一个都不行。为了提醒用户注意必填字段，它们必须被清晰的标记出来。

Komodo Media博客评论的必填字段中都标记出了Required字段

一个通用的标记方式就是加个星号（*），当然，不是所有用户都理解星号代表的含义。初学者和老年用户很有可能没法彻底理解星号代表啥。这就是为什么通常表单顶端都会有一个说明来告诉用户带星号的字段是必填的。当然，在那种每个字段都是必填的情况下，星号就没啥必要了。提供用户一个所有项都是必填的消息就足够了。

Facebook就不提供必填提示信息，只有当用户点击提交按钮时，才会提示用户需要填写所有信息

去年，我们进行了一个关于Web表单设计的调查。其中的一项：“设计师往往会移除所有不必要且会导致用户分心的细节，这些细节对填写表单完全没用。”更多的研究分析表明，当前有种减少必填项的趋势——超过50%的表单使用了至多5个必填项，而可选项往往会被避免。这种策略在你设计表单必填项时往往是非常实用的。

正确格式

除了要保证用户输入了所有必填信息，还需要验证用户是否填写了正确的格式。这种验证适用于许多情况：Email地址，URL，日期，手机号等等。如果填写了错误格式的信息，用户就会被提示修正。大概最简单的验证方式就是使用正则表达式。

请注意！通常强制用户按照一定的格式输入不是一个好主意。更好的做法是允许用户用多种方式和格式进行输入，然后让应用自动识别其中的信息。用户们只是想完成填写，他们才不管什么“正确”的格式和那些复杂的UI。让用户填写他们想填的东西吧！只要他们填写的合理，应用软件就应当做出正确的行为。这种设计模式经常被叫做：容错设计模式。（Sekai注：这一部分可以参考Jenifer Tidwell 的《Designing Interfaces》第8章）

Carbonmade的注册中包含一个规定格式的URL地址，它提示用户错误，并且给出了修改方案

如果要了解更多的关于正则表达式的知识，可以阅读《Essential Guide To Regular Expressions: Tools and Tutorials》或者如果你已经了解了基础，可以读这篇《Crucial Concepts Behind Advanced Regular Expressions》。在文章的后面，我们会讨论一些其他的格式验证技术。

确认字段

对于处理那些对系统很重要的信息时，提供给用户一个额外的确认字段往往是个好主意。通过这种方式，用户可以确认他们输入了正确的信息。一个使用确认字段的典型用例就是确认密码，但是这还能用在其他地方比如确认Email地址。

Photobucket在注册时要求用户重复输入密码来保证输入的正确性

一个确认字段往往放在目标字段的下一个。它的说明必须清楚地表明这个字段是用来确认某个字段的，比如“确认输入的密码”。如果前后两个输入的值不一样，用户就会得到错误提示。一个可选方案是如果前后输入的值匹配，那么可以用户将会得到一个成功确认的标识。

我们调查的第二部分显示了一些关于确认字段很有意思的信息。Email确认只部署在18%的网站上，而密码确认在72%的网站上被使用。令人惊讶的是，一些大型网站，比如Facebook，LinkedIn，Stumbleupon和Twitter不使用密码确认。

验证反馈？

如果验证失败，系统应该让用户得知验证失败，并且提供一个清晰明确的信息（一般是一些短句），还要提供一些修改意见。为了让用户迅速注意到这些错误信息，一般会把这些信息放在表单的顶部，也就是其他所有字段的前面。这也会让那些屏幕阅读器更轻松地访问到那些信息。

这些信息最好显示为红色，因为人们常常由此联想到错误信息，而且这个信息最好包含一个明显的图标使之更加显眼。图标应该是那种普遍能被人们识别的，比如禁止标识。这也能帮助那些视觉残障人士识别信息的含义。除了这一点，用户也应该被告知哪些字段需要被核实。

Invoice Machine的注册界面不会提供错误反馈。没有错误信息，并且这种柔和的红色是不容易被识别的

除了错误信息和无效信息列表之外，系统应该清晰地标记出哪些字段是无效的。这可以用下面提到的几条来实现（或者结合其中的几条）：

• 在无效信息域旁边提供红色的内嵌信息或者标识
• 将无效信息域的背景色或者边框色变成红色
• 改变无效信息域本身的颜色
• 在无效信息域旁边提供错误提示或者弹出框

如果你提供了错误信息或者帮助，这类信息最好是简短达意的。举个例子，如果用户填写了一个错误的日期格式，应该提供给用户这样的修正信息：“日期应该用dd-mm-yyyy的形式”。有时候将这类提示作为输入字段的默认值是个好主意。这样，用户会第一时间读到这些在输入框中的提示，并且当他们开始输入时，提示会消失。

在提交时验证

部署验证的“经典”方法是当用户按下提交按钮时开始验证。执行验证之后，如果发现任何错误，系统就会发出反馈并展现给用户。使用这种方式的情况下，用户可以不被中断地填写表单，但是这也是把双刃剑：用户可能必须在他们提交表单之后，并且等到服务器反馈后才修正他们的填写。这种技术是服务器端验证的典型，但是这种技术也可以在客户端实现。

在Ballpark网站中，错误反馈发生在提交之后。它将在顶部显示一个显眼的、包含错误字段列表错误信息，并且在每个错误字段处显示一个小提示

实时验证（即时验证）

跟前面的技术不同，实时验证是在用户填写时提示用户信息。但这并不是意味着我们必须在用户输入每个字符进行验证，只要输入字段失去焦点时验证也是可以的。使用这种方式，用户可以立刻得到反馈。例如：一个用户名是否有效，或者一个日期是否符合格式要求。显然，即时验证发生在用户输入时或者文本域失去焦点时。通常，它会显示一小段文字、提示或者状态图标等。

雅虎注册信息实现了一个密码强度尺，在你输入密码字符时就会进行反馈

我们应该小心谨慎地使用即时验证，因为过度滥用即时验证可能会分散用户的注意力。

TypePad网站的注册验证不止提供用户即时反馈，并且提示用户不同的错误——它还同时提示了成功信息

我们该回避什么

在设计表单时，有这么两个事儿是我们要回避的。首先，单独的错误页面可不是一个明智的主意。单独的错误页面是指当用户填写完表单提交之后重定向到的一个展示反馈信息的页面。这种情况下，用户会被迫退回填写页面来修正填写的错误。当他们退回到填写页面，他们必须记住错误页面的反馈信息。同样的情况发生在反馈信息在弹出框的情况中。不止是因为弹出框非常烦人，而且一旦它们被关闭，所有反馈信息就丢失了。

通过我们的调查，我们发现了一个有趣的情况：“30%的表单仅仅在顶部做出了错误提示（没有高亮输入字段）”同时“29%的表单高亮了输入字段，并在输入字段旁边放置了错误提示（但是顶端没有错误提示）”。只有25%同时高亮了输入字段和提供了顶端错误提示。

可能最奇怪的事实是大约14%的站点仍然使用Javascript弹出框来显示验证信息，而Ajax验证只占22%。这展示了验证反馈方面巨大的变化。

有备无患

除了纯粹的验证，还有许多其他技术来帮助用户来减少填写错误。虽然这些技术不全是验证技术，但它们确实有效帮助用户避免错误。

帮助提示

如果一个Web表单需要填入一些复杂的东西，帮助提示能在填写过程中显著帮助用户填入正确的信息。通过引导用户如何填写特定的内容，你可以让他们快速填写信息，并避免一些潜在的验证错误。帮助提示一般都是在输入字段附近的一小段文本信息。帮助信息的设计应该有别于设计标签（Sekai注：这里的意思是说，标签的设计是显眼的，而帮助信息却偏向低调）。它们一般都是那种小小的、灰色的文本。帮助提示的好处是它们永远是可见且有效的，即使Javascript是被关闭的。

WishListr在字段右边提供了很有用的信息

帮助标识（Tooltips）

和帮助提示相反，Tooltip最初都是隐藏的，只有当“需要”它们的时候才显示。它们通常都跟一个类似问好的小图标绑定，在鼠标移到上面或者点击一下的时候展示。一旦鼠标移出了图标，这些Tooltip就消失了。帮助标识可以减少页面的混乱，特别是当帮助消息很长的时候。

TicketTrunk的注册页面中包含了显眼的帮助标识，当鼠标移到图标上去时会展现帮助信息

动态提示

跟前一种情况类似，动态提示刚开始也是对用户隐藏的。一旦用户进入一个特定的输入字段，相关的提示就会出现。这种方式下，提示是非常显眼的，而且页面的混乱度也会下降。提示本身不应该遮挡表单中的其他输入字段。它们经常在输入字段旁边显示，但是你仍然应该把它们放置在右侧，因为这样可以防止喧宾夺主。

Digg的注册界面将动态提示分离了出来，当输入字段获得焦点时显示提示

掩码和重新排版用户输入

除了验证用户输入和协助用户输入，Web应用也能够帮助用户重新排版他们的输入。这可以通过设置输入字段的掩码来强制用户根据制定的格式输入信息。掩码就是一个能控制用户输入什么的表达式。通过下面的插件，我们可以很方便的使用掩码：

• meioMask
• iMask
• TypeCast
• jQuery Masked input plugin

TypeCast的demo页面显示了不同的掩码样式

有些时候，用户可能输入了部分正确或者正确但格式错误的信息。这些情况下，Web应用可以自动地修正用户的输入。下面这些情况，你可能需要考虑下重写用户的输入信息：

• 举个例子，当需要输入URL时，某个用户输入时缺少了“http://”的前缀，系统就可以在URL前面加入这个前缀。
• 如果用户输入的日期时dd-mm-yyyy的格式，但是需要的格式是yyyy-mm-dd，那么系统就可以自动修正它。
• 如果用户提供了信用卡卡号却没带破折号，系统就可以在卡号之间合适的地方自动加上破折号。

Tumblr使用了URL地址的掩码

只有在某些情况下，这些技术才能被使用。然而，我们应该谨慎使用自动排版技术，如果没有合理使用，就会给用户带来困扰。并且，不是所有用户的输入都是可以预测到的。举个例子，比如用户输入了“www.isekai”却省略了域名后缀，系统不能简单地补上“.me”，而是需要报出一个验证错误。

在这种情况下，我们要在此重提“容错设计模式”。与其限制用户的输入格式，不如允许用户输入他们想输入的，让系统自己去解析。但是，在很多情况下，这需要大量的服务器资源去处理，后端将转化用户输入，提取信息并将之转化为合适的格式以供进一步处理。

谷歌日历在这方面非常智能，它提供了仅仅一个输入框来添加事项。用户可以用各种格式来输入事项（甚至可以使用“明天”来代替日期），系统将转化这些输入并保存为一个事项。如果用户提供的信息难以转化为事项，系统就假设这些信息是一个事项的标题，并引导用户到一个更长的表单中，表单里已经填上了之前输入的标题。通过这种方式，谷歌省略了验证。

根据我们的调查，67%的站点使用了帮助文本和提示，10%使用了动态提示。令人惊奇的是，只有26%的站点把提示放到了输入字段的右侧，其他情况下提示放在输入字段的上面下面甚至是左侧。

你是人类吗？

说道Web表单验证就不得不说验证码。验证码是Web表单验证不可分割的一部分，它用来判断一个用户是人类还是机器人。最简单的验证码就是一张图片，上面有一些文本、数字或者表达式，还有个让用户填写的输入字段。最早的验证码就是一组数字的图片（比如“8356”），这些数字让用户来识别并输入。如果不输入正确的数字，表单就不会被提交。事实上，现在大部分的垃圾邮件机器人都可以识别出那些简单的图片验证码，所以将一些只有人类才能回答的问题放在验证码上面是个好主意，比如“太阳是什么颜色的？”，它的答案是“yellow”和它的变体（比如“Yellow”，“YELLOW”等）（Sekai注：我回答的是红色。。。）

你还可以关注一下一个叫“蜜罐验证码”的技术，这个技术就是建立一个页面上看不到的字段，然后在表单提交时验证它们是否还是空的。（Sekai注：几乎所有机器人会随便填一些东西到表单字段中，所以通过CSS隐藏一个人类看不到的字段，而机器人读取HTML时是可以看到这个字段的，用这样的蜜罐来引诱机器人填写，以此区别人类和机器人。）。另一种策略是建立一个字段，然后旁边有个标签上写着“不要填写这个字段”，然后将这个字段标记为必填项。

简单的验证码需要一个看得懂意思才能回答的答案

上述几种验证码有个主要的问题就是是否容易被识别。患有失明、视觉障碍或者阅读障碍的用户可能很难甚至不可能完成这些验证来提交表单。随着Web技术的发展，验证码也在发展，现在有了叫做ReCaptcha的技术，它提供了音频验证码给那些残疾人用户。

验证码可能产生难以识别的单词，你能轻松地看出左边的单词是什么吗？

当前仍然有许多用户讨厌验证码（并且确实有理由讨厌）。当然，人们只是不喜欢填表单。如果他们无法迅速轻松地做这些事，他们就非常有可能不做这些事。这就是为什么验证码起不到什么作用的原因：在实践中，（如果文本很混乱的话）它将浪费用户很多时间去识别。记住这一点：验证码只是帮到了网站拥有者，而不是他们的用户。因此，我们应该尽量避免使用验证码。如果想了解验证码和辅助功能（accessibility？）的相关资料，请阅读W3C的Inaccessibility of CAPTCHA。

Digg的注册表单中包含验证码并提供了音频支持，如果无法阅读，用户可以选择听到图片上的字母

有用的资源

下面是一些能帮助你轻松搭建表单验证的框架、插件和教程：

Sekai注：这部分就不翻译啦～

• LiveValidation
  A small, open source JavaScript validation library. It enables real-time, rich client validation which can be implemented easily. The best way to see its capabilities is to check out the example page.

• Validanguage
  A validation framework that enables rich client-side validation.

• JavaScript Form Validation
  A JavaScript validation framework for creating inline validation. You can configure it through JavaScript code or by using XML configuration file.

• PhatFusion Validate
  A small JavaScript validation framework based on MooTools.

• UniForm
  An attempt to standardize form markup (xhtml) and CSS. It can help you style error messages, help text, indicators and so on.

• jQuery Validation plugin
  One of the most popular validation plugins. As expected from jQuery plugin, it enables validation in one line of code, but you can also customise it. It has only 14 kb and is compatible with jQuery 1.3.2.

• jForm
  Another jQuery plugin that lets you implement validation easily. Not only that it performs validation but also has the support for live tips. It is still in development phase but is worth checking.

• Dynamic JavaScript Form Validation
  Provides easy validation and attractive error messages.

• jQuery Form Validator
  Another great jQuery validation plugin that performs live validation. It is fully customisable and supports localisation as well.

• Form field hints with CSS and JavaScript
  A useful tutorial on how to create help tips using CSS and JavaScript. Demo and source are included.

• Validation Hints for your form
  A great tutorial from Ask The CSS Guy that shows how to create inline validation with CSS and JavaScript.

• Screencast: Quick PHP Form Validation with PEAR
  A nice example of how you can validate PHP forms using PEAR framework.

• PHP Contact Form with jQuery Validation
  This tutorial shows how to implement the validation of a contact form using PHP and JavaScript.

• How to Validate Forms on both sides using PHP and jQuery
  Shows how to implement both client-side and server-side validation using PHP.

• Adding Form Validation to WordPress Comments using jQuery
  An interesting tutorial for all WordPress users.

结语

你已经看到了许多部署表单验证的不同的方法和技术。虽然有许多选择，然而你还是需要针对你的每个项目来部署表单验证。不是所有的技术都提供了一个全能解决方案。它们中的一部分是简单易用的，但是还有一部分则是不实用的。如果你是设计Web表单验证的新手，下面是一个在Web表单验证设计中需要考虑的事的列表，这应该足够帮助你起步了。

Web表单验证设计中的小贴士

• 永远不要省略服务器端验证。
• 不要提供模棱两可的验证反馈信息，它应该明显显示出验证错误，并提出修正方案。
• 不要让用户来考虑什么字段是必须的，请清除得标记出来。
• 永远不要把验证反馈做成一个单独页面，或者做成警告弹出框。
• 不要试图通过动态提示来弥补Web表单设计的不足，炫酷的效果是无法掩盖Web表单本身设计的不足的。
• 如果你使用了验证码，不要忘记支持音频，并且要支持“刷新”验证码。
• 当表单验证成功时，不要忘记通知用户验证成功，这跟通知用户验证失败一样重要。