遇到一个奇怪的问题。前几天我们的代码中。我想出了一个快速修复方法,但我忍不住想知道是否有更好的方法。
将通过 QueryString 提交的字符串值解析为最终出现在 SQL 存储过程中的类型化对象时,就会出现问题。对于大多数最终的比较类型,比较字符串是可以的,但要对日期执行“小于”或“大于”等操作,必须首先将字符串转换为日期。
所以我们这样做 - 值从查询字符串中取出后作为字符串提交到函数中:
if (DateTime.TryParse(value, out newTime))
{
value = newTime.ToStringIsoUtc();
}
return value
多年来一直运行良好,直到有人尝试提交由三部分组成的版本号。突然 1.3.1 变成了 2001-03-01 并且比较停止工作。
我的快速解决方法只是检查潜在的“日期”中是否有多个点,如果有,则将其保留为字符串。简单的。但问题是,虽然我们的客户目前没有使用 UTC 日期格式以外的任何格式,但当我查看维基百科并发现有多少国家/地区使用 dd.mm.yy 作为标准日期格式时,我感到害怕。
是否有更好的方法来区分日期和无类型版本号?
最佳答案
您无法仅使用日期值来完成此操作。您真正需要的是另一个值,该值指示查询字符串中DateTime
的格式。
以您的 1.3.1
格式为例。谁说它不能真正被解释为 2011 年 1 月 3 日(从左到右而不是从右到左看)。
您有两个选择:
如果您想要一个完全开放的值,则需要一个提示,指示应如何解释它(您将使用它来调整调用以设置对
DateTime.TryParse
的调用中的选项) >),同时需要注意的是,如果未提供提示,则当输入不明确时结果可能无法确定拒绝任何不符合预期格式的内容。
在处理用户输入时,第一个是更好的选择,因为您希望让用户尽可能简单并降低进入阈值。
请注意,如果用户输入来自使用 HTML 5 的网页,您应该注意 input
标记允许使用 date
和 datetime
输入类型。这样做的好处不仅是允许浏览器提供标准化(至少跨平台)输入此类数据的方式,而且还提供标准化数据传输格式,这意味着您的输入更多地属于 # 2 比#1 中的多。
当处理从 API 进行的调用时,第二种方法更可取,因为可以修改 DateTime 实例(或其表示形式)以满足您的期望(因为它们在调用 API 之前已经在内存中具有强类型表示形式)。
关于c# - 区分日期/时间和版本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13379201/