我对形式验证很痴迷。因此,在我当前的一个工作申请表项目(平台/语言在这种情况下是中立的)中为“出生数据”(DOB)字段创建验证器时,我想要一些东西来防止“朋克”输入。
我使用了日期选择器,并将最长日期限制为从当天起 XX 年。 XX 对这种情况有意义,因为任何年轻人都不应该申请这份工作。
验证错误信息是:你似乎太年轻了。
然后我开始冒险了。怎么样?如果DOB超过120年前,请留言:“你不能那么老!!!”
如果将来有DOB,请留言:“你一定是在开玩笑,你还没出生!”
最后,我在没有最后2个的情况下部署,对我的严肃客户来说太厚颜无耻了。
我想知道你们有多远/多少时间来验证DOB字段的良好可用性(或幽默感)?
类似日期,如“结婚日期”,“毕业年份”等......
PS:当我即将提交此帖时,标题文本框下会出现警告: “你问的问题似乎是主观的,可能会被关闭。” 手指交叉。
添加: 我很惊讶一些/大多数人都不太关心验证。我在这里重复一下我的评论:
如果用户错误地(非常明显地)输入了日期,无论是出于意图还是出错;这是验证者捕捉它的目的之一。当数据进入系统时,站点所有者只知道输入错误,他/她在不询问用户的情况下不知道实际值。如果这个领域非常重要,那将不是一个漂亮的场景。
答案 0 :(得分:18)
想想你填写表格的时间。有多少次你感到沮丧,因为一些“过于聪明”的程序员插入了一些“验证”,恰好是你的情况不正确?我说,相信用户。快来想想吧,随着时间的推移,无论如何,我猜人们的寿命更长,并且在较早的时候上网。 :P
答案 1 :(得分:12)
不要忘记您也可以警告用户不太可能的值。在大多数情况下,拼写错误比故意尴尬更有可能。
因此,对于您的应用程序,可能是这样的:
答案 2 :(得分:10)
验证与正确性
输入验证的要点是确保所有元素都在允许范围内并通过进一步处理预期 - 即如果您的数据库保证数据库中的所有申请人都是18岁或以上,请验证。如果您的数据库也接受学校的孩子申请实习,请不要。
一切不寻常只是一个警告。是的,120年的价值是疯狂的,你应该警告用户,并可能将此记录标记为可疑/审查。但是,拒绝它是没有意义的(除非你有一个商业规则,例如所有申请人都不到70岁)。
假信任
想象一下,如果你告诉一个用户“你排除了输入端不太可能的DOB”会发生什么。她可能会告诉她的同事DOB已“已经过验证”。他最终得到了一个没有根据的信任,即申请人是90岁,如果是假的,你会拒绝它。
所有进一步的处理 - 由人或计算机 - 必须仍然认为DOB可能不正确 - 只是因为拼写错误。您正在尝试创建一个您无法实际制作的保证。许多用户相信他们每天使用的计算机比陌生人更多,你正在努力加强这种信任 - 这是IMO的谬论。
<强>嬗变强>
许多应用程序的寿命比最初的实现者想象的要长得多,并且相当一些应用程序将用于超出他最疯狂梦想的目的。在人工限制中建立既不简化实际处理也不简化操作员的工作实际上没有帮助。
(这可能会让我进入你客户的严肃的范畴 - 但是我的方式是“关于验证的肛门”:知道何时停止:))
答案 3 :(得分:7)
我认为验证非常重要,但不一定适合您的情况。这并不是说你的情况微不足道,我只是有自己的日期导向尼特来挑选。
具体来说,我的担忧始终是按顺序排列。如果有人说他们出生于1802年,那很好(sorta),我只想让他们的毕业日期大于出生日期。但是,当涉及到时间(如小时和分钟)时,你会遇到一些小问题,例如,如果用户选择8:30作为开始时间,然后选择9:15作为结束时间,但随后意识到结束时间是8:45。他们决定将9改为8,意图将分钟改为:45。但我的验证脚本太忙了,说“嘿等等!8:15是在8:30之前,好好试试!”但我不能冒险让他们出错等等。
具体而言,对于你的情况,我会倾向于道德权利。因为有人指出,有人可能会进入家族历史(1600年代的DOB)或未来的购买(今天之后的日期),因此一般来说日期没有实际限制。但是你的场景有限,即:
如果年龄低于法定工作年龄(美国大部分地区为16岁),甚至不提供高于当年的任何选项(如果您使用下拉菜单)。
如果年龄超出合理工作年龄(可能是敏感话题),则根据退休年龄提供最高价值,只需添加“&gt;”在那一年之前。如果有人是75岁并申请管理员级别的工作,他们会更加高兴的是,你做的事情很简单,而不是被冒犯,因为你没有列出他们的出生年份。如果有的话,他们会留下深刻印象(我认为)你走这条路而不是一无所有,这意味着他们不应该浪费时间。
最后,您可以通过简单的下拉菜单轻松下载脚本(例如PHP):
$currentYear = date('Y');
echo "<select name=\"YearOfBirth\">";
for($i = 16; $i <= 64; $i++) {
$optionYear = $currentYear - $i;
echo "<option value=\"$optionYear\">$optionYear</option>";
}
$greaterYear = $currentYear - 65;
echo "<option value=\">$greaterYear\">>$greaterYear</option>";
echo "</select>";
答案 4 :(得分:5)
在向生活中的人们询问他们的出生日期时,只能拒绝绝对错误的价值观。未来的任何生日都是错的。而且我会划清界线并说在1880年之前的任何生日都是错误的。其他任何东西都是有效的生日。
因此,任何未通过上述测试的生日都将被拒绝,并在现场级别显示一条消息,例如“此日期是将来/过去太远。请输入您的出生日期。”
任何其他生日有效(可能用户真的是11岁,或108)。但是整体形式可能会被业务规则拒绝。例如,“您必须年满18岁才能申请。”
我们的想法是将单个字段验证与表单验证分开。将它们混合会产生复杂的规则。分离意味着您可以在其他环境中重复使用该字段的规则(例如,“活人的DOB必须在1880年1月1日至今”之间)。
答案 5 :(得分:4)
如果您正在为专业人士做这件事 - 比如求职申请 - 我可能不会使用“!”在给用户的消息中。看看你想要的任何做得好的网站,你不会发现它常用。
答案 6 :(得分:2)
有效日期:检查
不是将来的日期:也许(我处理医疗申请,所以我想你可以治疗未出生的婴儿)
不超过120年的日期:可能
我不是过度设计这些东西的忠实粉丝,特别是如果用户错误相对无害并且可以轻松发现和修复。无论如何,这就是我接近它的方式。
答案 7 :(得分:2)
有效日期:
我将继续检查这个日期是否存在。即闰年29日等等
将来的日期:
我们通常检查年龄(今年 - 给出的dob),并且必须至少在一定年龄才能注册。
120岁以前的日期:
我不会检查。 200年将是一个更安全的限制? (如果一名121岁的男子想要使用电脑*chuckles*
)
答案 8 :(得分:2)
我认为在设计验证时应考虑您的实际要求。如果该字段是日期字段,则为是(并且可能更重要的是,如果它存储日期但是某些日期低于恒星dba使其成为varchar),请确保仅提交有效日期。这很关键。无效的日期会导致查询数据的各种问题。如果是必须在过去发生的日期,请将日期范围限制为当前日期或更早。
之后,根据客户的需求。如果他们想为你付钱以消除年龄小于工作年龄的人,他们会告诉你。不允许达到最高年龄限制可能会让您因年龄歧视而陷入法律纠纷。客户可能也不希望您这样做。
答案 9 :(得分:1)
幽默是一个非常主观的东西,而且非常具体项目,因此沿着这些方向回答有点困难。话虽如此,如果申请支持正式程序,如申请工作,我可能会谨慎行事,并保持相当实际。
至于验证,我相信你去这里的努力应该与无效数据在UI中的影响成正比。回到工作申请表,我想有时会有一个人工审核流程,因此无论数据是故意还是无意中输入错误,无效数据的风险都很小。
如果您担心“punky”或机器人驱动的输入,请使用Captcha。说了这么多,我认为你使用的验证规则非常安全。
答案 10 :(得分:1)
我不是一个程序员(更多的是学士学位),虽然我正在努力获得一些开发技能,因为我认为它可以帮助我成为一个更好的学士学位。我做了一点VBA(别笑)。
无论如何想到这里是我的两分钱
1)放弃幽默。对你来说有趣的是现在不会对别人有用。此外,在25或30之后,两三次之后有趣的事情是不好笑的 - 即使你正在与一群人群打交道,它也很无聊! 2)我接下来的想法是,除非你能明确地证明某些事情是完全错误的,例如你不想让别人输入一个值&lt; 0,那么你应该考虑警告而不是通过对话或任何操作系统标准来预防。
嘿,我知道什么,在一周内我会改变主意(我是商业分析师),并要求开发人员立即回复; - &gt;
答案 11 :(得分:1)
让我们到处使用两位数的年份。 1999年之后,没有人会使用我们的软件!
答案 12 :(得分:0)
以下是您在验证DOB时可以执行的检查:
从DOB计算年龄并进行以下检查
AGE&gt; XX [XX是申请所需的最低年龄]
AGE&lt; XX {应该抛出一条消息,提到你还不够}}
AGE = XX
如果没有年龄上限,那么我们可以将其作为退休年龄,然后用下一次检查的上限验证
AGE&lt;退休年龄
AGE&gt;退休年龄{应该提出一条消息,提到你年龄太大而无法申请}
AGE =退休年龄
DOB是有效日期(通过提供有效日期)
DOB无效 -
Enter 0 in either of day/month/Year
Enter some negative Value
Enter some invalid date e.g. 30th feb or 32 Jan etc
Enter valid date with different separators (although the date is a valid one but due to different separators it will become an invalid one)
输入不同格式的日期,例如给出dd / mm / yyyy,dd / mm / yy,dd / MON / yyyy等。
输入一些未来日期(此处无效,因为您的目的不同)
答案 13 :(得分:0)
让用户选择一个日期。用户应该处于控制之中......而不是系统/开发人员。关于DOB应该避免的唯一日期是未来,因为这是不正确的(即防止设计错误)。您提供的日期选择器应处理任何日期格式问题。
绝对不要抛出任何厚颜无耻的异常/消息。您的消息应该有助于用户识别&amp;从错误中恢复。
希望有所帮助。
答案 14 :(得分:0)
验证整数并提供帮助;我想其他任何事情:虐待/大哥/过度引导的系统是一个坏主意。
如果愿意,应允许人们在这些表格上撒谎;这不是一个合法的事情,它是一个网站。
不要那么认真。
答案 15 :(得分:0)
这一切都取决于应用程序。用于订单处理的业务线(LOB)应用程序与跟踪历史或未来数据非常不同。
可以同意它需要是一个有效的日期,但考虑有多个日历(例如,月份数可以是13,年份可以超过5000)。
答案 16 :(得分:0)
作为一个完美主义者,我会去150:D
尽可能低,人们已经超过120,谁知道未来30年会发生什么:D
然而,我并不觉得那么重要。