抓虫记之一：DateToStr

又发生了这样的错误。表象总是那么扑朔迷离。

有客户说文件上传服务不能用了。错误提示的是服务器错误。但是其他机器可以，说明服务本身并没有大问题，或者说错误的发生，源于客户端环境的不一样。得出结论并没有什么不妥。

关键在于客户端什么环境有问题？这是一个非常有意思的过程。

先简单说明一下，文件上传服务发布了一个地址 http://myServer/upload.aspx, 在Post的时候，将本地的文件数据提交上来即可。支持断点续传，所以每个文件都会产生一个唯一的ID。

为了搞明白整个Post的过程中，哪里不一样，我们动用了利器HttpAnalysis。这个工具可以跟踪所有的Http请求过程。通过对比，发现成功上传文件的客户端和失败的客户端的请求头没有差别。我们尝试用成功上传文件的客户端的请求数据，在失败的客户机器上模拟，发现竟然也没问题。那问题，就必然出现在数据提交上了。

认真对比了一下，发现数据还真有问题。原来，这个上传文件的服务，需要获取文件的创建日期，当时作者的实现，就是使用了DateToStr (Delphi) 转换成为了字符串。然后服务器再依据字符串进行转换。但是大家知道，DateToStr，是依据本地的短日期设置格式来转换的，如果本地设置和服务器设置不一致，就有可能不能反向解析。

我们打开上传文件失败的机器的时间格式设置一看，原来他的格式是这样的：“yyyy-mm-dd-星期”,后面多了一个星期，服务器自然识别不了，好了，既然知道错误了，就好改了。

总结的时候，我们发现其实这个问题早就发生过，为什么还会出现呢？应该有静态分析工具，去将这些经验遗留下来，以后就不会再因为人员的变化而遗忘了。

后话：或许有人要问，直接调试服务器不更简单？是的，但是由于服务器并不是我们自己编写的，我们只是借用别人的现成的服务，所以很多方面还有迁就别人的设计。