Question

我正在尝试了解远程过程调用的有效负载中的数据字段。和Date以及Timestamp类型的对象最让我困惑。

完整请求有效负载如下所示：

7 | 0 | 8 | https://myapp.com/myapp/client/|72119BCB4CE5FB8D147EA76E8006F76E|com.myapp.service.MyService|updateTimepoint|java.lang.String/2004016611|java.util.Date/3385151746|554455|java.sql.Timestamp/3040052672|1|2|3|4|2|5|6|7|8|VhGcuow|0|

该服务的接口在代码中定义为：

public void updateTimepoint(String myId, Date timepoint,
                    AsyncCallback<Void> async);

从上面的数组中，我会告诉粗体部分（见下文）引用发送的java.util.Date对象和中间的“554455” - 是myId（我知道）来自用例）。我没有解释为什么myId变量放在中间：

java.util.Date/3385151746 | 554455 |的的java.sql.Timestamp / 3040052672

现在我正在调试混淆代码，因此查看浏览器中的Source选项卡似乎不是一个选项。但这并没有多大帮助，因为你会看到奇怪的JS日期引用。我不知道怎么读。

那么，我如何将有效负载变量的Date + Timestamp编译回可读的东西？

谢谢！

P.S。或者 - VhGcuow 日期？根据{{3}}

Answer 1

正如@RobG所说，这些数字不是值，而是有关Date，Timestamp类型的详细信息。有效负载为|分隔符，这些/是classname字符串的一部分。有关字符串顺序和有效负载中其他内容的更多详细信息，请参阅Serializing RPC-GWT（今年早些时候的答案）。

VhGcuow可能是base64编码的长整数。日期（可能是时间戳，虽然我没有检查过）被序列化为一个长字段，因此该值为long表示自1970年1月1日以来的毫秒数。有关如何能够更多讨论，请参阅RPC-GWT Serialization/java.util.Date Encoding理解和解码，而不是简单地相信RPC工作。

请注意，虽然RPC在几年内没有发生变化，并且已经被成千上万的GWT开发人员使用了10或100，他们没有正确地进行日期序列化问题。更有可能正在发生其他事情（如时区问题） - 询问另一个问题，包含问题的所有细节，“工作”测试用例可能会让您更快地得到答案。

从GWT RPC有效负载反序列化日期和时间戳以进行调试

1 个答案: