序列化java.util.Date [英] Serializing java.util.Date

问题描述

有谁知道java.util.Date是如何序列化的？我的意思是向我解释每个字节到底是什么？我尝试写出一个很长的日期，我可以看到匹配，但还有其他字符，我只是没有得到。

Does anyone know how a java.util.Date gets serialized? I mean explain to me exactly what each byte is? I tried writing out a long then a date and I can see matches but there are other characters that I just don't get.

我们的应用程序使用数据生成服务器请求意味着它从客户端序列化到服务器。进行压力测试的团队使用捕获这些请求并修改它们的工具，问题是他们想要处理日期而我不知道如何解释字节流。我正在谈论的家伙似乎愿意学习，但到目前为止我还没有找到任何我理解指向他的东西......

Our application makes server requests with data which means it gets serialized from client to server. The team that does stress testing uses a tool that captures these requests and modifies them, the problem is they want to process dates and I don't know how to interpret the byte stream. The dude I am talking to seems willing to learn but so far I haven't found anything that I understand to point him to...

我使用的代码：

  FileOutputStream fos = null;
  ObjectOutputStream oos = null;
  try
  {
   fos = new FileOutputStream("t.tmp");
   oos = new ObjectOutputStream(fos);

   Date today = new Date();

   oos.writeLong(today.getTime());
   oos.writeObject("Today");
   oos.writeObject(today);

   oos.close();
  }
  catch(FileNotFoundException e)
  {
   e.printStackTrace();
  }
  catch(IOException e)
  {
   e.printStackTrace();
  }

编辑：

上面的输出是：

"¬í w  ,áqÇ-t Todaysr java.util.DatehjKYt  xpw  ,áqÇ-x"

长期是w，áqÇ-所以长期和之间的东西是什么日期对象，即hjKYt xp

The long is "w ,áqÇ-" so what is the stuff between the long and the Date object, i.e. "hjKYt xp"

注意一些空白是不可打印的字符NULL，SOH，退格等。我知道它是十六进制值很重要。

NOTE some the blanks are unprintable characters NULL, SOH, backspace etc. I understand that it is the hex value that matters.

编辑：

仍有问题。由于某种原因，序列化的HTTP请求没有像我接受的答案那样序列化日期。非常接近，但仍然不同，我不知道为什么。甚至更奇怪的是，当我简单地序列化一个日期时，似乎工作得很好。在我们使用Websphere 6.1的工作中，以下是请求中发送内容的一些示例：

Still having problems. For some reason the serialized HTTP request does not serialize the date exactly like the answer I accepted says. Very close but still different and I don't know why. What's even odder is that when I simply serialize a date it seems to work fine. FYI at worj we use Websphere 6.1 Here are some examples of what is being sent in the request:

 lr_start_transaction("20000101");
\\x0Ejava.util.Datehj\\x81\\x01KYt\\x19\\x03\\x00\\x00xpw\\x08\\x00\\x00\\x01,\\xE10\\x0BXxt\\x00\\x08

 lr_start_transaction("20000102");
\\x0Ejava.util.Datehj\\x81\\x01KYt\\x19\\x03\\x00\\x00xpw\\x08\\x00\\x00\\x01,\\xE10>\\x9Dxt\\x00\\x08

 lr_start_transaction("20000103");
\\x0Ejava.util.Datehj\\x81\\x01KYt\\x19\\x03\\x00\\x00xpw\\x08\\x00\\x00\\x01,\\xE10z\\xDBxt\\x00\\x08

我能够识别大多数字段但不是实际时间！例如，serialVersionUID是 hj \\ x81 \\x01KYt \\ x19

I have been able to identify most fields but not the actual time! E.g the serialVersionUID is hj\\x81\\x01KYt\\x19

编辑（最终）：

我找到了日期，但它不在我预期的附近！我的样本很好，因为其他数据字段出现我认为日期已经完成 - 只是侥幸，我注意到我正在寻找的日期的十六进制模式！示例：

I found the date but it was no where near where I expected it! It was well after the sample I had because other data fields were appearing I thought the date was done - it was just fluke that I noticed the hex pattern of the date I was looking for! Example:

 lr_start_transaction("20000101");
\\x0Ejava.util.Datehj\\x81\\x01KYt\\x19\\x03\\x00\\x00xpw\\x08\\x00\\x00\\x01,\\xE10\\x0BXxt\\x00\\x08OTTST153t\\x00\\x06/Web2/t\\x00\\x044971t\\x00\\x0B12ce12f737d\\x00\\x00\\x01,\\xE10\\x0BXsq\\x00~\\x00\\x0Fw\\x08\\x00\\x00\\x00\\xDCk\\xE2T\\x80xt

日期值就在最后！

推荐答案

/**
 * Save the state of this object to a stream (i.e., serialize it).
 *
 * @serialData The value returned by <code>getTime()</code>
 *         is emitted (long).  This represents the offset from
 *             January 1, 1970, 00:00:00 GMT in milliseconds.
 */
private void writeObject(ObjectOutputStream s)
     throws IOException
{
    s.writeLong(getTimeImpl());
}

因此，它是表示从1970年1月1日00:00开始的偏移的长值：00格林威治标准时间，以毫秒为单位。

therefore, it's the long value representing the offset from Jan 1 1970 00:00:00 GMT in milliseconds.

编辑：但是这是先行并成功的一些标题：

however this is preceeded and succeeded by some headers:

0x73 - being the code for an ordinary object (TC_OBJECT)    
0x72 - being the code for a class description (TC_CLASSDESC)    
"java.util.Date" - the name of the class    
7523967970034938905L - the serialVersionUID    
0|0x02|0x01 - flags including SC_SERIALIZABLE & SC_WRITE_METHOD    
0 - number of fields    
0x78 - TC_ENDBLOCKDATA    
null - there is no superclass descriptor    
the time (long milliseconds since epoch)    
0x78 - TC_ENDBLOCKDATA

这篇关于序列化java.util.Date的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！