java大端小端_java的大端小端和c#如何对应

当前的存储器，多以byte为访问的最小单元，当一个逻辑上的地址必须分割为物理上的若干单元时就存在了先放谁后放谁的问题,于是端(endian)的问题应运而生了,对于不同的存储方法,就有大端(big-endian)和小端(little- endian)两个描述。

字节排序按分为大端和小端，概念如下

大端(big endian):低地址存放高有效字节

小端(little endian):低字节存放地有效字节

现在主流的CPU,intel系列的是采用的little endian的格式存放数据，而motorola系列的CPU采用的是big endian，ARM则同时支持 big和little，网络编程中,TCP/IP统一采用大端方式传送数据，所以有时我们也会把大端方式称之为网络字节序。

特别需要注意的是，C/C++语言编写的程序里数据存储顺序是跟编译平台所在的CPU相关的，而 JAVA编写的程序则唯一采用big endian方式来存储数据。

## java中为什么utf8字符串转字节后头部多了两个字节

-----------------------------

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。

(Unicode是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。)

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

在 Java 中直接使用Unicode 转码时会按照UTF-16LE 的方式拆分，并加上 BOM。 如果采用 UTF-16 拆分，在 Java 中默认采用带有 BOM 的 UTF-16BE 拆分。 (其实Unicode与UTF-8是完全一样的)

## 引用

-----------------------------

- [字节存储排序：大端和小端的判别及转换](http://www.cnblogs.com/Romi/archive/2012/01/10/2318551.html)

- [Java之中如何判断CPU是大端(Big Endian)还是小端(Little Endian) ](http://blog.chinaunix.net/uid-1844931-id-3022904.html)

- [java 大端和小端转换](http://blog.csdn.net/hhbgk/article/details/50673991)