[hadoop2.7.1]I/O之一步一步解析Text（基础知识及与String比较）

hadoop中的Text类，跟java中的String类很相似，在其定义的方法上，也多有相近之处，当然，由于用途的不同，两者之间还是有很大的区别的，那么，在分析Text类之前，先来回顾下java.lang.String类。

1、java中的String类：

String 类代表字符串。Java 程序中的所有字符串字面值（如 "abc" ）都作为此类的实例实现。 

字符串是常量；它们的值在创建之后不能更改。字符串缓冲区支持可变的字符串。因为 String 对象是不可变的，所以可以共享。例如： 

     String str = "abc";
 等效于：
     char data[] = {'a', 'b', 'c'};
     String str = new String(data);
 下面给出了一些如何使用字符串的更多示例： 

     System.out.println("abc");
     String cde = "cde";
     System.out.println("abc" + cde);
     String c = "abc".substring(2,3);
     String d = cde.substring(1, 2);
 String 类包括的方法可用于检查序列的单个字符、比较字符串、搜索字符串、提取子字符串、创建字符串副本并将所有字符全部转换为大写或小写。大小写映射基于 Character 类指定的 Unicode 标准版。 

Java 语言提供对字符串串联符号（"+"）以及将其他对象转换为字符串的特殊支持。字符串串联是通过 StringBuilder（或 StringBuffer）类及其 append 方法实现的。字符串转换是通过 toString 方法实现的，该方法由 Object 类定义，并可被 Java 中的所有类继承。有关字符串串联和转换的更多信息，请参阅 Gosling、Joy 和 Steele 合著的 The Java Language Specification。 

除非另行说明，否则将 null 参数传递给此类中的构造方法或方法将抛出 NullPointerException。 

String 表示一个 UTF-16 格式的字符串，其中的增补字符 由代理项对 表示（有关详细信息，请参阅 Character 类中的 Unicode 字符表示形式）。索引值是指 char 代码单元，因此增补字符在 String 中占用两个位置。 

String 类提供处理 Unicode 代码点（即字符）和 Unicode 代码单元（即 char 值）的方法。

2、Unicode

   hadoop中的Text类和java中的String类都是使用标准的Unicode，但是在编码方式上却有不同之处，hadoop中的Text类使用修订的UTF-8，而java中的String类使用的是UTF-16。接下来，对于Unicode做一个较为详细的阐述。

 Unicode

 Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。Unicode 是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。Unicode涉及到两个步骤，首先是定义一个规范，给所有的字符指定一个唯一对应的数字，第二步才是怎么把字符对应的数字保存在计算机中，这才涉及到实际在计算机中占多少字节空间。

     我们也可以这样理解，Unicode是用0至65535之间的数字来表示所有字符。其中0至127这128个数字表示的字符仍然跟ASCII完全一样。65536是2的16次方，这是第一步。第二步就是怎么把0至65535这些数字转化成01串保存到计算机中，这肯定就有不同的保存方式了，于是出现了UTF(unicode transformation format)，有UTF-8，UTF-16，UTF-32。

UTF-8 、UTF-16、UTF-32

那么现在，我们的问题来了，UTF-8 、UTF-16、UTF-32之间到底有何区别呢？

    UTF-16比较好理解，就是任何字符对应的数字都用两个字节来保存。我们通常对Unicode的误解就是把Unicode与UTF-16等同了，但是很显然如果都是英文字母这做有点浪费，明明用一个字节能表示一个字符为什么用两个？

   于是又有个UTF-8，这里的8非常容易误导人，8不是指一个字节，难道一个字节表示一个字符？实际上不是。当用UTF-8时表示一个字符是可变的，有可能是用一个字节表示一个字符，也可能是两个，三个，四个，当然最多不能超过4个字节，具体根据字符对应的数字大小来确定。实际表示ASCII字符的UNICODE字符，将会编码成1个字节，并且UTF-8表示与ASCII字符表示是一样的。所有其他的UNICODE字符转化成UTF-8将需要至少2个字节。每个字节由一个换码序列开始。第一个字节由唯一的换码序列，由n位连续的1加一位0组成，首字节连续的1的个数表示字符编码所需的字节数。

   现在UTF-8和UTF-16的优劣很容易就看出来了：如果全部英文或英文与其他文字混合，但英文占绝大部分，用UTF-8就比UTF-16节省了很多空间。

例如，“汉字”对应的数字是0x6c49和0x5b57，而编码的程序数据是：
　　BYTE data_utf8[] = {0xE6, 0xB1, 0x89, 0xE5, 0xAD, 0x97}; // UTF-8编码
　　WORD data_utf16[] = {0x6c49, 0x5b57}; // UTF-16编码
　　DWORD data_utf32[] = {0x6c49, 0x5b57}; // UTF-32编码
　　这里用BYTE、WORD、DWORD分别表示无符号8位整数，无符号16位整数和无符号32位整数。UTF-8、UTF-16、UTF-32分别以BYTE、WORD、DWORD作为编码单位。“汉字”的UTF-8编码需要6个字节。“汉字”的UTF-16编码需要两个WORD，大小是4个字节。“汉字”的UTF-32编码需要两个DWORD，大小是8个字节。根据字节序的不同，UTF-16可以被实现为UTF-16LE或UTF-16BE，UTF-32可以被实现为UTF-32LE或UTF-32BE。

下面分别介绍UTF-8、UTF-16、UTF-32。

UTF-8（注意：Text使用修订的标准UTF-8编码）

UTF-8以字节为单位对Unicode进行编码。从Unicode到UTF-8的编码方式如下：
　　Unicode编码(16进制)　║　UTF-8 字节流(二进制)
　　000000 - 00007F　║　0xxxxxxx
　　000080 - 0007FF　║　110xxxxx 10xxxxxx
　　000800 - 00FFFF　║　1110xxxx 10xxxxxx 10xxxxxx
　　010000 - 10FFFF　║　11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
　　UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。
　　例1：“汉”字的Unicode编码是0x6C49。0x6C49在0x0800-0xFFFF之间，使用用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将0x6C49写成二进制是：0110 1100 0100 1001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。
　　例2：Unicode编码0x20C30在0x010000-0x10FFFF之间，使用用4字节模板了：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。将0x20C30写成21位二进制数字（不足21位就在前面补0）：0 0010 0000 1100 0011 0000，用这个比特流依次代替模板中的x，得到：11110000 10100000 10110000 10110000，即F0 A0 B0 B0。

UTF-16

　　UTF-16编码以16位无符号整数为单位。我们把Unicode编码记作U。编码规则如下：
　　如果U<0x10000，U的UTF-16编码就是U对应的16位无符号整数（为书写简便，下文将16位无符号整数记作WORD）。 
　　如果U≥0x10000，我们先计算U'=U-0x10000，然后将U'写成二进制形式：yyyy yyyy yyxx xxxx xxxx，U的UTF-16编码（二进制）就是：110110yyyyyyyyyy 110111xxxxxxxxxx。 
　　为什么U'可以被写成20个二进制位？Unicode的最大码位是0x10ffff，减去0x10000后，U'的最大值是0xfffff，所以肯定可以用20个二进制位表示。例如：Unicode编码0x20C30，减去0x10000后，得到0x10C30，写成二进制是：0001 0000 1100 0011 0000。用前10位依次替代模板中的y，用后10位依次替代模板中的x，就得到：1101100001000011 1101110000110000，即0xD843 0xDC30。
　　按照上述规则，Unicode编码0x10000-0x10FFFF的UTF-16编码有两个WORD，第一个WORD的高6位是110110，第二个WORD的高6位是110111。可见，第一个WORD的取值范围（二进制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。
　　为了将一个WORD的UTF-16编码与两个WORD的UTF-16编码区分开来，Unicode编码的设计者将0xD800-0xDFFF保留下来，并称为代理区（Surrogate）：
　　D800－DB7F　║　High Surrogates　║　高位替代 
　　DB80－DBFF　║　High Private Use Surrogates　║　高位专用替代 
　　DC00－DFFF　║　Low Surrogates　║　低位替代
　　高位替代就是指这个范围的码位是两个WORD的UTF-16编码的第一个WORD。低位替代就是指这个范围的码位是两个WORD的UTF-16编码的第二个WORD。那么，高位专用替代是什么意思？我们来解答这个问题，顺便看看怎么由UTF-16编码推导Unicode编码。 
　　如果一个字符的UTF-16编码的第一个WORD在0xDB80到0xDBFF之间，那么它的Unicode编码在什么范围内？我们知道第二个WORD的取值范围是0xDC00-0xDFFF，所以这个字符的UTF-16编码范围应该是0xDB80 0xDC00到0xDBFF 0xDFFF。我们将这个范围写成二进制：
　　1101101110000000 11011100 00000000 - 1101101111111111 1101111111111111
　　按照编码的相反步骤，取出高低WORD的后10位，并拼在一起，得到
　　1110 0000 0000 0000 0000 - 1111 1111 1111 1111 1111
　　即0xe0000-0xfffff，按照编码的相反步骤再加上0x10000，得到0xf0000-0x10ffff。这就是UTF-16编码的第一个WORD在0xdb80到0xdbff之间的Unicode编码范围，即平面15和平面16。因为Unicode标准将平面15和平面16都作为专用区，所以0xDB80到0xDBFF之间的保留码位被称作高位专用替代。

UTF-32

　　UTF-32编码以32位无符号整数为单位。Unicode的UTF-32编码就是其对应的32位无符号整数。
　　字节序
　　根据字节序的不同，UTF-16可以被实现为UTF-16LE或UTF-16BE，UTF-32可以被实现为UTF-32LE或UTF-32BE。例如：
　　Unicode编码　║　UTF-16LE　║　UTF-16BE　║　UTF32-LE　║　UTF32-BE 
　　0x006C49　║　49 6C　║　6C 49　║　49 6C 00 00　║　00 00 6C 49 
　　0x020C30　║　43 D8 30 DC　║　D8 43 DC 30　║　30 0C 02 00　║　00 02 0C 30

而UTF-32 对每一个Unicode码位使用恰好32位元。因为UTF-32对每个字符都使用4字节，就空间而言，是非常没有效率的。特别地，非基本多文种平面的字符在大部分文件中通常很罕见，以致于它们通常被认为不存在占用空间大小的讨论，使得UTF-32通常会是其它编码的二到四倍。虽然每一个码位使用固定长定的字节看似方便，它并不如其它Unicode编码使用得广泛。

Text类

提供了序列化、反序列化和在字节级别上比较文本的方法。它的长度类型是整型，采用0压缩序列化格式。另外，它还支持在不将字符数组转换为字符串的情况下进行字符串遍历。

hadoop2.7.1中的Text源码：

/**
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.hadoop.io;

import java.io.IOException;
import java.io.DataInput;
import java.io.DataOutput;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.CharacterCodingException;
import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.CharsetEncoder;
import java.nio.charset.CodingErrorAction;
import java.nio.charset.MalformedInputException;
import java.text.CharacterIterator;
import java.text.StringCharacterIterator;
import java.util.Arrays;

import org.apache.avro.reflect.Stringable;

import org.apache.hadoop.classification.InterfaceAudience;
import org.apache.hadoop.classification.InterfaceStability;

/** This class stores text using standard UTF8 encoding.  It provides methods
 * to serialize, deserialize, and compare texts at byte level.  The type of
 * length is integer and is serialized using zero-compressed format.  <p>In
 * addition, it provides methods for string traversal without converting the
 * byte array to a string.  <p>Also includes utilities for
 * serializing/deserialing a string, coding/decoding a string, checking if a
 * byte a