(其中之一是我检查的Java中解析模糊日期和优雅地处理多种日期格式)
我正在用Java编写一个日期解析器,它接受一个日期并生成一个格式字符串,该字符串可供SimpleDateFormat用于解析日期。
日期通过正则表达式(是的,它很丑陋)从日志文件(IBM Websphere、Tomcat、Microsoft Exchange等)中解析。因为我们有至少两个不同位置的客户,所以不能简单地将字符串扔到SimpleDateFormat的解析方法中,并期望它能正常工作。
此外,还存在日期和月份位置的问题(即格式“dd/MM/yyyy”或“MM/dd/yyyy”),如果没有至少两个数据集,其中日期数字已更改,则无法解决。
因此,我的当前方法是将特定客户系统上安装的特定软件的日期格式存储在数据库(mysql/xml/...)中,并强制用户至少指定客户名称和软件名称,以便有足够的上下文来分解可能性的数量格式可以给出。
然后,将使用此“子集”尝试解析指定软件的日志文件。 (子集以HashMap中HashMap的形式存储, Integer键是格式字符串的长度,第二个HashMap的String键指定仅包含分隔字符的日期签名。 (例如,“.. ::。”表示格式为“dd.MM.yyyy 11:11:11.111”的日期))
我还考虑数字的值,即数字>12必须是一天,因为没有第13个月。但是,这仅对大于每月12日的日期字符串有效。
是否有任何机会避免实现关于日志文件环境的先前知识,从而使解析器能够可靠地解析一个日期,而无需参考第二个日期字符串进行比较?
我已经卡住了将近3个月了-。-
任何建议都非常受欢迎=)
编辑:
好的,各位,这个帖子可以关闭了。我现在想出了一个不同的解决方案来解决我的特定问题。对于那些感兴趣的人: 我正在用Java编写一个日志阅读器。由于我们有定期维护,我必须读取许多日志文件。 但是文件中写入的不仅仅是纯文本信息。 想象一下,服务器刚刚崩溃了,现在是星期天晚上,下一个注意到这一点的人是客户的IT部门负责人。然后在第二天进行维护并检查日志文件。从内容上来看,一切似乎都很好,没有什么异常。在发送维护报告半个小时之后,我收到了一封电子邮件,上面提到的IT部门负责人发牢骚,说服务器已经崩溃了,似乎没人注意到。
问题是,你无法跟踪具有数千行的日志文件的内容和时间戳。因此,我开发了一个组件,它读取日志文件并计算两个不同日志条目之间的时间。每个日志行都被解析为java.util.Date,以便稍后获取日期作为时间戳,以实现日志间隔的高分辨率。然后将差异投射到一条线图上,使两个日志行之间的较长超时作为与文件其余部分相关的大峰值可见。
我现在的解决方案是完全丢弃字符串的日期部分,并插入一个具有预定义格式的虚拟日期。只有当小时和分钟接近23:59时,日期才会更改。 原始日期稍后将在"假数据"下面呈现在图表上。
我感谢你们所有人的建议和反馈=) (希望我的英语到目前为止已经可以理解了;))