“出生日期”验证:你会走多远/多少?

发布于 2024-08-08 06:02:37 字数 709 浏览 8 评论 0原文

我对表单验证非常挑剔。因此,在我当前的一个工作申请表项目中为“出生数据”(DOB) 字段创建验证器时(平台/语言在这种情况下是中立的),我想要一些东西来防止“朋克”输入。

我使用了日期选择器,并将最大日期限制为从当天算起的 XX 年。 XX 对于这种情况来说是有意义的,因为任何年轻人都不应该申请这份工作。

验证错误消息是:您似乎太年轻,不适合这份工作。

然后我开始冒险。怎么样?

如果 DOB 是 120 多年前,请留言:“你不可能那么老!!!”

如果 DOB 是未来,则消息:“你一定是在开玩笑,你还没有出生!!!”

最后,我没有部署最后两个,这对于我严肃的客户来说太厚颜无耻了。

我想知道你们会在多大程度上验证 DOB 字段以获得良好的可用性(或幽默)?

同样,对于“结婚日期”、“毕业年份”等日期...

PS:当我正要提交这篇文章时,标题文本框下有一个警告: “你问的问题似乎很主观,很可能会被关闭。” 手指交叉。

添加: 我很惊讶一些/大多数人并不太关心验证。我在这里重复我的评论之一:

如果用户错误地输入了日期(非常明显的事情),无论是故意还是错误;这是验证者捕获它的目的之一。当数据进入系统时,网站所有者只知道输入是错误的,如果不询问用户,他/她不会知道实际值。如果这个领域非常重要,那么情况就不会那么美好。

I'm quite anal about form validation. So while creating a validator for a "data of birth" (DOB) field in one of my current projects for a job application form (platform/language is neutral in this context), I wanted something to prevent 'punky' inputs.

I used a date picker and restricted the max date to be XX years from the current day. XX make sense for this scenario as anyone younger shouldn't be even applying for the job.

The validation error message is: You seem too young for the job.

Then I began to get adventurous. How about?

If DOB is more than 120 years ago, message: "You cannot be that old!!!"

If DOB is in the future, message: "You must be kidding, you are not born yet!!!"

In the end, I deployed without the last 2, too cheeky for my no-nonsense client.

I would like to know how far/much would you guys go to validate DOB fields for good usability (or humor)?

Similarly for dates like, "Date of marriage", "Year of graduation" etc...

PS: As I was about to submit this post, there's a warning under the title textbox:
"The question you're asking appears subjective and is likely to be closed."
Fingers crossed.

To add:
I'm quite surprised that some/most of the guys are not too concern about the validation. I repeat one of my comments here:

If the user entered the date wrongly (something very obvious) whether by intent or by mistake; that's one of the purposes of the validators to catch it. When data goes into the system, the site owner only know the input is wrong, he/she would not know the actual value without asking the user. If this field is highly important, it will not be a pretty scenario.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(17

笑叹一世浮沉 2024-08-15 06:02:37

想想您填写表格的次数。有多少次你因为某些“过于聪明”的程序员插入了一些恰好不适合你的情况的“验证”而感到沮丧?我说,相信用户。想想看,随着时间的推移,我猜人们的寿命越来越长,上网的年龄也越来越早。 :P

Think about the times you've filled out forms. How many times have you been frustrated because some "overly clever" programmer inserted some "validation" that just happened to be incorrect for your circumstance? I say, trust the user. Come to think of it, as time goes on I guess people are living longer and getting on the net at earlier ages, anyway. :P

心意如水 2024-08-15 06:02:37

不要忘记您还可以警告用户不要出现不太可能的值。在大多数情况下,拼写错误比故意尴尬更有可能。

因此,对于您的应用程序,可能是这样的:

  • 年龄 <分钟。申请人年龄-错误
  • 年龄>共同退休年龄-警告
  • 年龄>预期寿命 - 错误

don't forget you can also warn the user against unlikely values. In most cases, a typo is more likely than deliberately being awkward.

So for your application, maybe something like this:

  • Age < min. applicant age - error
  • Age > common retirement age - warning
  • Age > expected life span - error
逐鹿 2024-08-15 06:02:37

验证与正确性
输入验证的要点是确保所有元素都在进一步处理允许和预期的范围内 - 即,如果您的数据库保证数据库中的所有申请人均年满 18 岁或以上,请验证这一点。如果您的数据库也接受学生申请实习,那就不要这样做。

一切不寻常的事情都只是一个警告。是的,120 年的值很疯狂,您应该警告用户并可能将此记录标记为可疑/以供审查。但是,拒绝它是没有意义的(除非您有业务规则,例如所有申请人都小于 70 岁)。

虚假信任
想象一下,如果您告诉一位用户“您在输入中排除了不太可能的 DOB”,会发生什么情况。她可能会告诉她的同事 DOB“已经得到验证”。他最终毫无根据地相信申请人已经90岁了,如果这是假的,你就会拒绝它。

所有进一步的处理——由人或计算机进行——仍然必须假设 DOB 可能是不正确的——仅仅是因为拼写错误。你试图创造一个你实际上无法做出的保证。许多用户比陌生人更信任他们每天使用的计算机,你试图强制执行这种信任 - 这是 IMO 的谬误。

嬗变
许多应用程序的寿命比最初的实现者想象的要长得多,而且相当多的应用程序将用于超出他最疯狂的梦想的用途。建立既不简化实际处理又不简化操作员工作的人为限制实际上没有帮助。

(这可能让我属于你的客户的严肃类别 - 但这是我的方式“关于验证的肛门”:知道何时停止:))

Validation vs. Correctness
The point of input validation is to ensure all elements are within the range allowed for and expected by further processing - i.e. if your database guarantees all applicants in the DB are 18 years or older, validate that. If your database also accepts school kids applying for internships, don't.

Everything unusual is just a warning. Yes, a value of 120 years is crazy, you should warn the user and possibly flag this record as suspicous / for review. However, there's no point in rejecting it (unless you have a business rule that e.g. all applicants are younger than 70).

Fake trust
Imagine what happens if you tell one user that "you rule out unlikely DOBs at the input". She might tell her co-worker that DOB is "already validated". He ends up with an unfounded trust that the applicant is 90, and if it were a fake you would have rejected it.

All further processing - by human or by computer - must still assume the DOB may be incorrect - just because of a typo. You are trying to create a guarantee you can't actually make. Many users trust the computer they use every day more than a stranger, you are trying to enforce this trust - which is IMO s fallacy.

Transmutation
Many applications live much longer than the original implementer imagined, and quite some will be used for purposes beyond his wildest dreams. Building in artificial limits that neither simplify the actual processing nor the job of the operator don't actually help.

(That puts me probably into the no-nonsense category of your client - but thst's my way to be "anal about validation": knowing when to stop :))

南烟 2024-08-15 06:02:37

我认为验证非常重要,但不一定适合您的情况。这并不是说你的情况微不足道,我只是有自己的日期导向的神经网络可供选择。

具体来说,我关心的始终是保持事物的逻辑顺序。如果有人说他们出生于 1802 年,那很好(有点),我只是希望他们的毕业日期大于他们的出生日期。但是,当涉及到时间(如小时和分钟)时,您会遇到一些棘手的小问题,例如,如果用户选择 8:30 作为开始时间,然后选择 9:15 作为结束时间,但随后意识到结束时间是8点45分。他们决定将 9 更改为 8,目的是将分钟更改为 :45。但我的验证脚本太忙了,说“嘿等等!8:15 在 8:30 之前,不错的尝试!”但我不能冒险让他们把它弄错等等。

对于你的具体情况,我会倾向于道德正确。因为正如所指出的,某人可能会输入家族历史(出生日期在 1600 年代)或未来购买(日期在今天之后),因此一般来说日期没有实际限制。但你的情况是有限制的,即:

如果年龄低于法定工作年龄(美国大部分地区为 16 岁),甚至不要提供高于该年份的任何选项(如果你使用下拉菜单)。

如果年龄超出合理工作年龄(这可能是一个敏感话题),则根据退休年龄提供最高值,并只需添加“>”在那一年的面前。如果某人 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>";

I think validation is incredibly important, but not necessarily in your situation. Which isn't to say that your situation is trivial, I just have my own date-oriented nits to pick.

Specifically, my concerns are always in keeping things in logical order. If someone says they were born in 1802, that's fine (sorta), I just want their date of graduation to be greater than their date of birth. But you run into itchy little problems when it comes to time (as in hours and minutes), for instance, if a user chooses 8:30 as the start time and then chooses 9:15 as the end time, but then realizes that the end time was 8:45. They decide to change the 9 to an 8 with the intention of changing the minutes to :45. But my validation script is too busy saying "Hey Wait! 8:15 is before 8:30, nice try!" but I can't risk letting them leave it wrong, etc etc.

For your situation specifically, I would lean toward what is ethical right. Because as it's been pointed out, someone could be entering a family history (with DOBs in the 1600's) or future purchases (with dates after today), so there is no realistic limit on dates in general. But there are limits to your scenario, ie:

If Age is less than legal working age (16 in most parts of the US), don't even offer anything higher than that year as an option (if you are using drop down).

If Age is beyond reasonable working age (which can be a sensitive subject) offer the highest value based on retirement age and simply add a ">" in front of that year. If someone is 75 and applying for an admin-level job, they will be more pleased that you made things simple rather than offended that you didn't have their year of birth listed. If anything, they will be impressed (I think) that you went this route instead of nothing at all, implying they shouldn't waste their time.

In the end you have a simple drop down very easy to script (example in 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>";
久伴你 2024-08-15 06:02:37

当询问活着的人的出生日期时,只拒绝那些绝对错误的值。以后的任何生日肯定都是错的。我想说的是,任何 1880 年之前的出生日期肯定是错误的。其他任何日期都是有效的出生日期。

因此,任何未通过上述测试的出生日期都会被拒绝,并在字段级别显示一条消息,例如“该日期是未来的/过去太久了。请输入您的出生日期。”

任何其他出生日期都是有效的(也许用户确实是 11 岁,或 108)。但整体形式可能会被业务规则拒绝。例如,“您必须年满 18 岁才能申请。”

这个想法是将单个字段验证与表单验证分开。将它们合并起来会产生复杂的规则。分离意味着您可以在其他上下文中重复使用该字段的规则(例如“活着的人的出生日期必须在 1/1/1880 到今天之间”)。

When asking living people for their birthdate, only reject values that are definitely wrong. Any birthdate in the future is definitely wrong. And I would draw a line and say that any birthdate before (say) 1880 is definitely wrong. Anything else is a valid birthdate.

So any birthdate that fails the above tests is rejected with a message at field level, like "This date is in the future/too far in the past. Please enter your birthdate."

Any other birthdate is valid (maybe the user really is 11 years old, or 108). But the overall form may be rejected by business rules. For example, "You must be at least 18 years old to apply."

The idea is to separate individual field validation from form validation. Conflating them yields complicated rules. Separating means you can re-use the rules for the field (e.g. "DOB of a living person must be between 1/1/1880 and today") in other contexts.

凹づ凸ル 2024-08-15 06:02:37

如果你是为了任何专业的事情——比如工作申请——我可能不会使用“!”在给用户的消息中。看一下您想要的任何做得好的网站,您不会发现它被常用。

If you're doing this for anything professional - like a job application - I might not use "!" in messages to users. Take a look at any well done website you'd like, you're not going to find it in common use.

自在安然 2024-08-15 06:02:37

有效日期:查看
日期不是将来:也许(我处理医疗申请,所以我想你可以治疗未出生的婴儿)
日期不超过 120 年:可能

我不太喜欢过度设计这些东西,特别是如果用户错误相对无害并且可以轻松发现和修复。无论如何,这就是我的处理方式。

Valid date: check
Date not in future: maybe (I deal with medical applications, so I suppose you could be treating unborn babies)
Date not older than 120 years: probably

I'm not a big fan of over-engineering these things, particular if a user mistake is relative harmless and can be spotted and fixed easily. That's how I approach it anyway.

牵强ㄟ 2024-08-15 06:02:37

有效日期:

我将进一步检查该日期是否存在。即闰年 2 月 29 日等

未来的日期:

我们通常会检查年龄(今年 - 给出的出生日期)并且必须至少达到一定年龄才能注册。

是否超过 120 岁的日期:

我不会检查。 200年是一个更安全的限制吗? (如果 121 岁的老人想要使用电脑*chuckles*

Valid Date:

I'll go to the extend of checking whether this date exists or not. i.e. leap year 29th Feb and so on

Date in the future:

we usually check the age (this year - dob given) and must be at least a certain age to sign up.

Date older than 120 years or not:

I won't check. 200 years would be a safer limit? (in case a 121 year old man wants to use the computer *chuckles*)

情仇皆在手 2024-08-15 06:02:37

我认为您在设计验​​证时应该考虑您的实际需求。是的,如果该字段是日期字段(也许更重要的是,如果它存储日期,但一些不太出色的 dba 将其设为 varchar),请确保仅提交有效日期。这很关键。无效日期会导致查询数据时出现各种问题。如果该日期必须发生在过去,请将日期范围限制为当前日期或更早的日期。

然后按照客户的要求去做。如果他们想付钱让你淘汰低于工作年龄的人,他们会告诉你。禁止最高年龄限制可能会让您因年龄歧视而陷入法律麻烦。客户可能也不希望你这样做。

I think you should consider your actual requirements when designing validations. Yes if the field is a date field (and perhaps more importantly if it stores a date but some less than stellar dba made it a varchar),make sure only a valid date is submitted. This is critical. Invalid dates cause all sorts of issues with querying the data. If it is a date that must of necessity have occurred in the past, limit the date range to the present date or earlier.

After that go with what your client wants. If they want to pay for you to eliminate people younger than work age, they will tell you. Disallowing a top age limit can get you into legal trouble for age discrimination. The client may not want you to do this either.

浅听莫相离 2024-08-15 06:02:37

幽默是一个非常主观的东西,并且非常特定于项目,所以沿着这些思路回答有点困难。话虽如此,如果申请支持正式流程,例如申请工作,我可能会谨慎行事并保持事实性。

至于验证,我相信您转到此处的工作量应该与从 UI 传入的无效数据的影响成正比。回到工作申请表,我想有时会进行人工审核过程,因此无论数据是有意还是无意地错误输入,无效数据的风险都很小。

如果您担心“朋克”或机器人驱动的输入,请使用验证码。说了这么多,我认为您对所使用的验证规则非常安全。

Humour is a pretty subjective thing and very project specific so it’s a bit difficult to answer along those lines. Having said that, if the application supports a formal process such as applying for a job I’d probably err on the side of caution and keep it pretty factual.

As for validation, I believe the effort so you go to here should be proportional to the impact of invalid data making its way through from the UI. Going back to the job application form, I imagine there will be a human review process at some time so the risk of invalid data is minimal whether the data was intentionally or inadvertently entered incorrectly.

If you’re worried about “punky” or bot driven inputs then use Captcha. Having said all that, I reckon you’re pretty safe with the validation rules you’ve used.

惟欲睡 2024-08-15 06:02:37

好吧,我不是一名程序员(更多的是文学士),尽管我正在努力获得一些开发技能,因为我认为这可能有助于我成为一名更好的文学士。我已经做了一些VBA(别笑)。

无论如何,在思考这个问题时,我的两点意见是:

1)放弃幽默。现在对你来说有趣的事情对其他人来说不会。此外,两三次之后有趣的事情在 25 岁或 30 岁之后就不再有趣了——即使你面对的是一群爱开玩笑的人,这也很无聊!
2)我逐渐认识到,除非你能明确地验证某些东西是完全错误的,否则你不想让某人输入一个值<<。 0,那么您应该考虑通过对话或任何操作系统标准进行警告而不是预防。

嘿,我知道什么,一周后我会改变主意(我是一名业务分析师),并将要求开发人员立即回复;->

Well I'm not a programer (More of a BA) though I'm trying to gain some development skills as I think it may help me be a better BA. I've done a bit of VBA (Don't laugh).

Anyway in thinking about this here's my two cents

1) Dropping the humour. Whats funny to you now won't be to someone else. Furthermore, whats funny after two or three goes isn't funny after 25 or 30 - its just tiresome even if you are dealing with a jokey crowd!
2) I am coming round to the idea that unless you can definitively validate something as being plain wrong, E.g. you don't want to let someone enter a value < 0, then you should consider warning rather than prevention via dialogues or whatever the OS standard happens to be.

Hey what do I know, In a week I'll have changed my mind (I'm a Business Analyst) and will be demanding instant repsonses from developers ;->

我们的影子 2024-08-15 06:02:37

让我们在任何地方都使用两位数年份。 1999 年之后就没有人会使用我们的软件了!

Let's just use two digit years everywhere. No one's going to be using our software after 1999!

海夕 2024-08-15 06:02:37

以下是您在验证 DOB 时可以执行的检查:

根据 DOB 计算年龄并执行以下检查

AGE > XX [XX 是申请所需的最低年龄]

AGE < XX {应该抛出一条消息,指出您还不够老}

AGE = XX

如果没有年龄上限,那么我们可以将其视为退休年龄,否则请在接下来的两次检查中验证上限

AGE <退休年龄

AGE>退休年龄 {应该抛出一条消息,提及您太老了,无法申请}

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 等。

输入未来的日期(此处无效,因为您的目的不同)

Below are the checks that you can do while validating the DOB:

calculate the age from the DOB and do the following checks

AGE > XX [XX is the min age required to apply]

AGE < XX {SHould throw a message mentioning that you are not old enough}

AGE = XX

If there is no upper limit of age then we can take it as retirement age else verify with the upper limit for the next two checks

AGE < Retirement Age

AGE > Retirement Age {Should throw a message mentiong that you are too old to apply}

AGE = retirement Age

DOB is a valid date (by giving valid date)

DOB is invalid -

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)

Enter date with different formats such as by giving dd/mm/yyyy, dd/mm/yy, dd/MON/yyyy etc.

Enter some future date (Invalid here as your purpose is something different)

柠檬 2024-08-15 06:02:37

作为一个完美主义者,我会来这里 150 :D

尽可能低的机会,人们已经通过了 120,谁知道未来 30 年会发生什么 :D

但我不认为它那么重要..

being a perfectionist i would go here for 150 :D

as low as the chances are, people have passed the 120, and who know what shall happens in the coming 30 years :D

i don't find it that important however..

云雾 2024-08-15 06:02:37

这一切都取决于应用程序。用于订单处理的业务线 (LOB) 应用程序与跟踪历史或未来数据有很大不同。

人们可以同意它必须是一个有效的日期,但考虑到有多个日历(例如,月份数可以是 13,年份可以超过 5000)。

It all depends on the application. A line of business (LOB) application for order processing is very different to tracking historical or future data.

One can agree it needs to be a valid date, but consider there are multiple calendars (e.g. month number can be 13, year can be over 5000).

护你周全 2024-08-15 06:02:37

验证整数并提供帮助;我认为还有其他事情:滥用/老大哥/过度设计的系统是一个坏主意。

如果人们愿意,应该允许他们在这些表格上撒谎;这不是一个合法的东西,它是一个网站。

别这么认真。

Validate for an integer and to be helpful; I think anything else: an abusive/big brother/over-enginereed system is a bad idea.

People should be allowed to lie on these forms if they wish; it's not a legal thing, it's a website.

Don't take it so seriously.

风铃鹿 2024-08-15 06:02:37

只需让用户选择一个日期即可。用户应该控制......而不是系统/开发人员。关于 DOB,您应该避免的唯一日期是未来,因为这是不正确的(即通过设计防止错误)。您提供的日期选择器应该处理任何日期格式问题。

并且绝对不要抛出任何厚颜无耻的异常/消息。您的消息应该帮助用户识别和识别从错误中恢复。

希望有帮助。

Just let the user pick a date. The user should be in control..not the system/developer. The only date you should avoid with respect to DOB is the future as that is incorrect (i.e. preventing error by design). The date picker you provide should handle any date format issues.

And definitely do not throw up any cheeky exceptions/messages. Your message should aid the user in recognising & recoverying from an error.

Hope that helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文