因此protobuf網使用這個原內容爲.NET GUID:與Java UUID和C#的Guid protobuf網互操作
message Guid {
optional fixed64 lo = 1; // the first 8 bytes of the guid
optional fixed64 hi = 2; // the second 8 bytes of the guid
}
...當我編譯原爲Java類,並創建該Java UUID實例:
UUID uid = UUID.fromString("2ac9f438-f555-40b0-8880-02226b81285c");
...那麼它不會不管我使用uid.getMostSignificantBits()或uid.getLeastSignificantBits()作爲參數傳遞給Guid.setHi()(或Guid.setLo()) 。
無論我選擇哪種組合,在C#反序列化包含Java生成的GUID的類型,我測試的GUID值,我得到什麼似乎是字節順序問題:
expected:<2ac9f438-f555-40b0-8880-02226b81285c>
but was:<f55540b0-f438-2ac9-5c28-816b22028088>
。 ..或:
expected:<2ac9f438-f555-40b0-8880-02226b81285c>
but was:<6b81285c-0222-8880-b040-55f538f4c92a>
有沒有簡單的解決這個問題?
應該指出我是protobuf的新手,所以對這裏的可能性有點朦朧。
編輯:
對於它的價值,我也將結果提供給Guid.setLo嘗試過在一個或兩個uid.getLeast/MostSignificantBits()的結果Long.reverseBytes()/嗨,和交換這些訂單爲好,但可惜...
編輯,第二: 難怪簡單的字節順序交換上的兩個多頭不工作(從here摘錄):
開頭四字節組和後兩個兩字節 組的順序相反,而最後兩個字節組的順序和關閉六字節組的順序相同。
看到我的答案張貼到這個問題的一種可能性。如果兩種語言都要在應用程序代碼中使用它們的本地二進制guid/uuid類型,則不確定是否有其他方式。任何其他建議(除了發送guid作爲字符串)?
我發現了,太晚,該GUID使用什麼,我只能形容爲「瘋狂的字節順序」 – 2014-10-17 17:36:16
@MarcGravell - FWIW到目前爲止,我很享受與protobuf網工具鏈的工作超過了相應的工具爲java。對於應用程序集成來說,向後翻轉是簡單,優雅和低摩擦的,但到目前爲止我還沒有遇到過使用java protobuf工具的情況。我認爲互操作性的要求會在某些地方沿用某種語言的作品。但是,所有人都說,帽子脫離了protobuf網! – Hoobajoob 2014-10-17 19:15:42