Shuffy

【大端(Big Endian)與小端(Little Endian)簡介】
Byte Endian是指字節在內存中的組織，所以也稱它為Byte Ordering，或Byte Order。
     對于數據中跨越多個字節的對象， 我們必須為它建立這樣的約定:
(1) 它的地址是多少?
(2) 它的字節在內存中是如何組織的?
    針對第一個問題，有這樣的解釋:
    對于跨越多個字節的對象，一般它所占的字節都是連續的，它的地址等于它所占字節最低地址。(鏈表可能是個例外， 但鏈表的地址可看作鏈表頭的地址)。
    比如: int x， 它的地址為0x100。 那么它占據了內存中的Ox100， 0x101， 0x102， 0x103這四個字節（32位系統，所以int占用4個字節）。
    上面只是內存字節組織的一種情況: 多字節對象在內存中的組織有一般有兩種約定。 考慮一個W位的整數。
    它的各位表達如下:[Xw-1， Xw-2， ... ， X1， X0],它的
    MSB (Most Significant Byte， 最高有效字節)為 [Xw-1， Xw-2， ... Xw-8];
    LSB (Least Significant Byte， 最低有效字節)為 [X7，X6，...， X0]。
    其余的字節位于MSB， LSB之間。

LSB和MSB誰位于內存的最低地址， 即誰代表該對象的地址?
這就引出了大端(Big Endian)與小端(Little Endian)的問題。
如果LSB在MSB前面， 既LSB是低地址， 則該機器是小端; 反之則是大端。
DEC (Digital Equipment Corporation，現在是Compaq公司的一部分)和Intel的機器（X86平臺）一般采用小端。
IBM， Motorola(Power PC)， Sun的機器一般采用大端。
當然，這不代表所有情況。有的CPU即能工作于小端， 又能工作于大端， 比如ARM， Alpha，摩托羅拉的PowerPC。 具體情形參考處理器手冊。
具體這類CPU是大端還是小端，應該和具體設置有關。
（如，Power PC支持little-endian字節序，但在默認配置時是big-endian字節序）
一般來說，大部分用戶的操作系統（如windows, FreeBsd,Linux）是Little Endian的。少部分，如MAC OS ,是Big Endian 的。
所以說，Little Endian還是Big Endian與操作系統和芯片類型都有關系。

Linux系統中，你可以在/usr/include/中（包括子目錄）查找字符串BYTE_ORDER(或
_BYTE_ORDER, __BYTE_ORDER)，確定其值。BYTE_ORDER中文稱為字節序。這個值一般在endian.h或machine/endian.h文件中可以找到,有時在feature.h中，不同的操作系統可能有所不同。

          big endian是指低地址存放最高有效字節（MSB），而little endian則是低地址存放最低有效字節（LSB）。
         用文字說明可能比較抽象，下面用圖像加以說明。比如數字0x12345678在兩種不同字節序CPU中的存儲順序如下所示：

Big Endian

   低地址                                            高地址
   ----------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     12     |      34    |     56      |     78    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Little Endian

   低地址                                            高地址
   ----------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     78     |      56    |     34      |     12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        從上面兩圖可以看出，采用big endian方式存儲數據是符合我們人類的思維習慣的.
        為什么要注意字節序的問題呢？你可能這么問。當然，如果你寫的程序只在單機環境下面運行，并且不和別人的程序打交道，那么你完全可以忽略字節序的存在。但是，如果你的程序要跟別人的程序產生交互呢？在這里我想說說兩種語言。C/C++語言編寫的程序里數據存儲順序是跟編譯平臺所在的CPU相關的，而J***A編寫的程序則唯一采用big endian方式來存儲數據。試想，如果你用C/C++語言在x86平臺下編寫的程序跟別人的J***A程序互通時會產生什么結果？就拿上面的0x12345678來說，你的程序傳遞給別人的一個數據，將指向0x12345678的指針傳給了J***A程序，由于J***A采取big endian方式存儲數據，很自然的它會將你的數據翻譯為0x78563412。什么？竟然變成另外一個數字了？是的，就是這種后果。因此，在你的C程序傳給J***A程序之前有必要進行字節序的轉換工作。
     無獨有偶，所有網絡協議也都是采用big endian的方式來傳輸數據的。所以有時我們也會把big endian方式稱之為網絡字節序。當兩臺采用不同字節序的主機通信時，在發送數據之前都必須經過字節序的轉換成為網絡字節序后再進行傳輸。ANSI C中提供了下面四個轉換字節序的宏。
·BE和LE一文的補完
        我在8月9號的《Big Endian和Little Endian》一文中談了字節序的問題，原文見上面的超級鏈接。可是有朋友仍然會問，CPU存儲一個字節的數據時其字節內的8個比特之間的順序是否也有big endian和little endian之分？或者說是否有比特序的不同？
     實際上，這個比特序是同樣存在的。下面以數字0xB4（10110100）用圖加以說明。

Big Endian

   msb                                                         lsb
   ---------------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   1  |   0  |   1  |   1  |   0  |   1  |   0  |   0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Little Endian

   lsb                                                         msb
   ---------------------------------------------->
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   0  |   0  |   1  |   0  |   1  |   1  |   0  |   1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     實際上，由于CPU存儲數據操作的最小單位是一個字節，其內部的比特序是什么樣對我們的程序來說是一個黑盒子。也就是說，你給我一個指向0xB4這個數的指針，對于big endian方式的CPU來說，它是從左往右依次讀取這個數的8個比特；而對于little endian方式的CPU來說，則正好相反，是從右往左依次讀取這個數的8個比特。而我們的程序通過這個指針訪問后得到的數就是0xB4，字節內部的比特序對于程序來說是不可見的，其實這點對于單機上的字節序來說也是一樣的。
     那可能有人又會問，如果是網絡傳輸呢？會不會出問題？是不是也要通過什么函數轉換一下比特序？嗯，這個問題提得很好。假設little endian方式的CPU要傳給big endian方式CPU一個字節的話，其本身在傳輸之前會在本地就讀出這個8比特的數，然后再按照網絡字節序的順序來傳輸這8個比特，這樣的話到了接收端不會出現任何問題。而假如要傳輸一個32比特的數的話，由于這個數在littel endian方存儲時占了4個字節，而網絡傳輸是以字節為單位進行的，little endian方的CPU讀出第一個字節后發送，實際上這個字節是原數的LSB，到了接收方反倒成了MSB從而發生混亂。

【用函數判斷系統是Big Endian還是Little Endian】
bool IsBig_Endian()
//如果字節序為big-endian，返回true;
//反之為   little-endian，返回false
{
    unsigned short test = 0x1122;
    if(*( (unsigned char*) &test ) == 0x11)
       return TRUE;
else
    return FALSE;

}//IsBig_Endian()

以上資料整理自：
http://hi.baidu.com/serial_story/blog/item/7e110587c3ed8e29c75cc3c7.html
http://qzone.qq.com/blog/574754870-1219889620