|
|
intel處理器的字節順序是和dec vax處理器的字節順序一致的。因此它與68000型處理器以及internet的順序是不同的，所以用戶在使用時要特別小心以保證正確的順序。
任何從windows sockets函數對ip地址和端口號的引用和傳送給windows sockets函數的ip地址和端口號均是按照網絡順序組織的，這也包括了sockaddr_in結構這一數據類型中的ip地址域和端口域（但不包括sin_family域）。
考慮到一個應用程序通常用與“時間”服務對應的端口來和服務器連接，而服務器提供某種機製來通知用戶使用另一端口。因此getservbyname()函數返回的端口號已經是網絡順序了，可以直接用來組成一個地址，而不需要進行轉換。然而如果用戶輸入一個數，而且指定使用這一端口號，應用程序則必須在使用它建立地址以前，把它從主機順序轉換成網絡順序（使用htons()函數）。相應地，如果應用程序希望顯示包含於某一地址中的端口號（例如從getpeername()函數中返回的），這一端口號就必須在被顯示前從網絡順序轉換到主機順序（使用ntohs()函數）。
由於intel處理器和internet的字節順序是不同的，上述的轉換是無法避免的，應用程序的編寫者應該使用作為windows sockets api一部分的標準的轉換函數，而不要使用自己的轉換函數代碼。因為將來的windows sockets實現有可能在主機字節順序與網絡字節順序相同的機器上運行。因此衹有使用標準的轉換函數的應用程序是可移植的。 |
|
字節順序是指占內存多於一個字節類型的數據在內存中的存放順序，通常有小端、大端兩種字節順序。小端字節序指低字節數據存放在內存低地址處，高字節數據存放在內存高地址處；大端字節序是高字節數據存放在低地址處，低字節數據存放在高地址處。基於X86平臺的PC機是小端字節序的，而有的嵌入式平臺則是大端字節序的。因而對int、uint16、uint32等多於1字節類型的數據，在這些嵌入式平臺上應該變換其存儲順序。通常我們認為，在空中傳輸的字節的順序即網絡字節序為標準順序，考慮到與協議的一致以及與同類其它平臺産品的互通，在程序中發數據包時，將主機字節序轉換為網絡字節序，收數據包處將網絡字節序轉換為主機字節序。
在本LINUX的書裏介紹到INTEL的CPU使用的小端字節序 其他比MOTOROLA
68000係列CPU使用的是大端字節序 如果不轉換 將數據通過網絡發出時 比如MOTOROLA發一個16位數據：0X1234 傳送到INTEL時
就被INTEL解釋為0X3412 也就是4660成了13330 所以有時候需要一些函數來進行大小端字節序的轉換
關於這大小字節序的概念不是很想的明白 數據在
內存裏是具體怎麽存放的形式？為什麽會有CPU解釋的不同？數據不是按12345678……這樣的順序一直排列的麽？
如: 一個多字節值 0xFECDBA98,內存從地址100開始存放
降序: FE | CD | BA | 98---->;對應地址100 | 101 | 102 | 103
升序: 98 | BA | CD | FE ---->;same above
註意,我們的書寫表示法是從低字節位--->;高字節位
內存地址生長方向為: 從左到右 由低到高(這是不變的)
數據為: 0x89ABCDEF
降序(Big-endian)大端字節序 存儲時 由左到右
升序(Little-endian)小端字節序 存儲時 由右嚮左
可以自己編一個小程序驗證一下(用C的數組)
更簡單的調用VC裏的checkEndian()
Intel處理器的字節順序是和DEC VAX處理器的字節順序一致的。因此它與68000型處理器以及Internet的順序是不同的，所以用戶在使用時要特別小心以保證正確的順序。
任何從Windows Sockets函數對IP地址和端口號的引用和傳送給Windows Sockets函數的IP地址和端口號均是按照網絡順序組織的，這也包括了sockaddr_in結構這一數據類型中的IP地址域和端口域（但不包括sin_family域）。
考慮到一個應用程序通常用與“時間”服務對應的端口來和服務器連接，而服務器提供某種機製來通知用戶使用另一端口。因此getservbyname()函數返回的端口號已經是網絡順序了，可以直接用來組成一個地址，而不需要進行轉換。然而如果用戶輸入一個數，而且指定使用這一端口號，應用程序則必須在使用它建立地址以前，把它從主機順序轉換成網絡順序（使用htons()函數）。相應地，如果應用程序希望顯示包含於某一地址中的端口號（例如從getpeername()函數中返回的），這一端口號就必須在被顯示前從網絡順序轉換到主機順序（使用ntohs()函數）。
由於Intel處理器和Internet的字節順序是不同的，上述的轉換是無法避免的，應用程序的編寫者應該使用作為Windows Sockets API一部分的標準的轉換函數，而不要使用自己的轉換函數代碼。因為將來的Windows Sockets實現有可能在主機字節順序與網絡字節順序相同的機器上運行。因此衹有使用標準的轉換函數的應用程序是可移植的。 |
|
|