2012-04-17 31 views
13

tôi đang tạo ra một GUID như thế nàyGuid Byte Order trong .NET

Guid g = new Guid(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xA, 0xB, 0xC, 0xD, 0xE, 0xF }); 
Console.WriteLine(g); 

này kết quả đầu ra

03020100-0504-0706-0809-0a0b0c0d0e0f 

Theo Wikipedia có được bốn phần trong guid và điều này giải thích tại sao việc chuyển đổi trật tự byte trong bốn nhóm. Tuy nhiên bài viết trên Wikipedia cũng nói rằng tất cả các phần được lưu trữ ở định dạng Big Endian. Rõ ràng ba phần đầu tiên không phải là Big Endian. Phương thức GetBytes() của guid trả về các byte theo cùng thứ tự được sử dụng để tạo. Giải thích cho hành vi này là gì?

Trả lời

6

Có vẻ như MS đang lưu trữ năm phần trong cấu trúc. 4 phần đầu tiên dài 2 hoặc 4 byte và do đó có thể được lưu trữ dưới dạng kiểu gốc (ví dụ: WORD và DWORD) ở định dạng cuối nhỏ. Phần cuối cùng dài 6 byte và do đó xử lý khác nhau (có thể là một mảng).

Liệu Spec có cho biết GUID được lưu trữ theo thứ tự lớn hay lưu trữ các bộ phận theo thứ tự đó nhưng các phần đơn lẻ có thể được thực hiện cụ thể?

CHỈNH SỬA:

Từ UUID spec, mục 4.1.2. Bố trí và Byte Order (tôi nhấn mạnh):

Để giảm thiểu sự nhầm lẫn về bài tập chút trong octet, định nghĩa kỷ lục UUID
được xác định duy nhất về lĩnh vực có
số không thể thiếu của octet. Các trường được trình bày nhiều nhất trước tiên là
.

...

Trong sự vắng mặt của ứng dụng rõ ràng hoặc giao thức trình bày
đặc điểm kỹ thuật cho trái
, một UUID được mã hóa như một đối tượng 128-bit, như sau:

Các lĩnh vực được mã hóa dưới dạng 16 octet, với kích thước và thứ tự của các trường được xác định ở trên và mỗi trường được mã hóa với hầu hết các byte đầu tiên (được gọi là thứ tự byte mạng).

Có thể là MS đã sotred các byte là đúng thứ tự, nhưng không bận tâm đến thứ tự mạng-to-host các phần WORD và DWORD để trình bày (có vẻ là ok theo spec, tại ít nhất là do đọc không có kỹ năng của tôi.)

+0

Theo Wikipedia (tôi đã không kiểm tra các tài liệu tham khảo) các tiêu chuẩn UUID trong đó GUID được cho là thực hiện nói rằng các bộ phận nên được mã hóa trong Big Endian. Cả thông số UUID và GUID đều xác định rằng có bốn phần kích thước 4, 2, 2 và 8 byte theo thứ tự này. – Stilgar

+0

Thật vậy, và khi hiển thị phần 8 byte cuối cùng thường được hiển thị là 2bytes-6bytes - cả hai đều xuất hiện chính xác là lớn endian (như được hiển thị là ví dụ của bạn). – Grhm

+0

Vâng 8 byte cuối cùng được hiển thị là 2-6 trong biểu diễn chuỗi có thể vì lý do dễ đọc nhưng chúng là một phần của cùng một phần dữ liệu. Câu hỏi thực sự là nếu Guid vi phạm tiêu chuẩn hoặc có một số giải thích khác. – Stilgar

5

Tôi không phải chuyên gia ở đây, nhưng các trang Wiki bạn đề cập đến, cũng nói:

Tuy nhiên, các tài liệu tham khảo cho một thường [4] Cơ cấu sử dụng các dữ liệu loại không đề cập đến byte đặt hàng

trích dẫn đó ([4]) trỏ tới http://msdn.microsoft.com/en-us/library/aa373931(VS.85).aspx mà sau đó xác định như thế nào Microsoft thực hiện một GUID như

typedef struct _GUID { 
    DWORD Data1; 
    WORD Data2; 
    WORD Data3; 
    BYTE Data4[8]; 
} GUID; 

vì 8 byte cuối cùng được lưu trữ dưới dạng mảng byte, tôi nghĩ rằng điều này xác định hành vi bạn đang thấy.

+0

Vì vậy, DWORD và WORD có chút ít kết thúc vì một lý do nào đó? – Stilgar

+1

http://en.wikipedia.org/wiki/Endianness Nó sẽ phụ thuộc vào kiến ​​trúc của bạn. Trên kiến ​​trúc x86, vâng. – pms1969

+1

Nhưng điều này cũng có nghĩa là GUID vi phạm tiêu chuẩn UUID? Ngoài ra, bài viết Wikipedia là loại gây hiểu nhầm (nói rằng GUID lưu trữ các phần dữ liệu ở định dạng Big Endian) – Stilgar