java.io.Serializable序列化接口类及编码表

1、java.io.Serializable序列化接口类：

Exception in thread "main" java.io.NotSerializableException: Person

这个类中，什么方法都没有定义，只是作为一个标识类。实现了这个接口，我们的类就是可以被序列化的，不用实现什么方法。

序列化一般是在进行网络传输时会被用到，一个类先序列化成一定格式，再传到远端的服务器或客户端，远端收到了然后又反序列化还原成类，在这个过程中不用去关心是怎么序列化的，但是不实现这个接口的话这个类就会传不了。通常写serialVersionUID = 1L也可以。甚至，不写这行也仅会导致编译器报警而已。

2、编码表。听了毕老师的讲解，特意去找了一些关于编码表的详细介绍以及历史。

支持中文的编码表有两个：

gbk，每个汉字占用两个字节。

utf-8：每个汉字占用三个字节。

Web 中的问题

网页的编码问题主要有两点，一是网页是如何编码的，二是如何告诉浏览器如何编码的。

第一个问题，又可以分成静态页面和动态页面两个问题。

对静态页面，网页的编码要看你保存文件时的编码选项，多数的网页编辑软件可以让你选择编码的类型，默认为本地编码，为了使网页减少编码的问题，最好保存为 UTF-8 编码格式。

对动态页面，如 Servlet 生成的页面，在 HttpServletResponse 类中有一个方法 setContentType，可以通过参数来指定生成的页面的类型和编码，例如：response.setContentType("text/html; charset=utf-8");来指定生成的页面的编码类型。

对 jsp 页面可以通过 <%@ page contentType="text/html;charset=gb2312" %> 来指定生成的页面的编码及类型。（这个是由页面制作者来指定的）

第二个问题，如何通知浏览器网页的编码类型。

浏览器收到只是一个字节流，它并不知道页面是如何编码的，因此，需要一个机制来告诉浏览器页面的编码类型，标准的机制是使用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 来指定页面的编码，当浏览器读取页面遇到这样的指示时，将使用这里制定的编码方式重新加载页面。

否则的话，浏览器将会试图猜出页面的编码类型。

在最初的时候，美国人制定了第一张编码表 《美国标准信息交换码》，简称 ASCII，它总共规定了 128 个符号所对应的数字代号，使用了 7 位二进制的位来表示这些数字。其中包含了英文的大小写字母、数字、标点符号等常用的字符，数字代号从 0 至 127，ASCII 的表示内容如下：

0 – 31 控制符号

32 空格

33-47 常用符号

48-57 数字

58-64 符号

65-90 大写字母

91-96 符号

97-127 小写字母

由于 ASCII 出现最早，因此各种编码实际上都受到了它的影响，并尽量与其相兼容。

扩展 ASCII 编码 ISO8859

美国人顺利解决了字符的问题，可是欧洲的各个国家还没有，比如法语中就有许多英语中没有的字符，因此 ASCII 不能帮助欧洲人解决编码问题。

为了解决这个问题，人们借鉴 ASCII 的设计思想，创造了许多使用 8 位二进制数来表示字符的扩充字符集，这样我们就可以使用256种数字代号了，表示更多的字符了。在这些字符集中，从 0 - 127 的代码与 ASCII 保持兼容，从 128 到 255 用于其它的字符和符号，由于有很多的语言，有着各自不同的字符，于是人们为不同的语言制定了大量不同的编码表，在这些码表中，从 128 - 255 表示各自不同的字符，其中，国际标准化组织的 ISO8859 标准得到了广泛的使用。

在 ISO8859 的编码表中，编号 0 – 127 与 ASCII 保持兼容，编号128 – 159 共32个编码保留给扩充定义的 32 个扩充控制码，160 为空格， 161 -255 的 95 个数字用于新增加的字符代码。编码的布局与 ASCII 的设计思想如出一辙，由于在一张码表中只能增加 95 种字符的代码，所以 ISO8859 实际上不是一张码表，而是一系列标准，包括 14 个字符码表。例如，西欧的常用字符就包含在 ISO8859-1字符表中。在 ISO8859-7种则包含了 ASCII 和现代希腊语字符。

大字符集的烦恼

不管如何，欧洲的拼音文字都还可以用一个字节来保存，一个字节由8个二进制的位组成，用来表示无符号的整数的话，范围正好是 0 – 255。

但是，更严重的问题出现在东方，中国，朝鲜和日本的文字包含大量的符号。例如，中国的文字不是拼音文字，汉字的个数有数万之多，远远超过区区 256 个字符，因此 ISO 的 8859 标准实际上不能处理中文的字符。

通过借鉴 ISO8859 的编码思想，中国的专家灵巧的解决了中文的编码问题。

既然一个字节的 256 种字符不能表示中文，那么，我们就使用两个字节来表示一个中文，在每个字符的 256 种可能中，低于 128 的为了与 ASCII 保持兼容，我们不使用，借鉴 ISO8859的设计方案，只使用从 160 以后的 96 个数字，两个字节分成高位和低位，高位的取值范围从 176-247 共72个，低位从 161 – 254共94这样，两个字节就有 72 * 94 = 6768种可能，也就是可以表示 6768 种汉字，这个标准我们称为 GB2312-80。

6768 个汉字显然不能表示全部的汉字，但是这个标准是在1980年制定的，那时候，计算机的处理能力，存储能力都还很有限，所以在制定这个标准的时候，实际上只包含了常用的汉字，这些汉字是通过对日常生活中的报纸，电视，电影等使用的汉字进行统计得出的，大概占常用汉字的 99%。因此，我们时常会碰到一些名字中的特殊汉字无法输入到计算机中的问题，就是由于这些生僻的汉字不在 GB2312 的常用汉字之中的缘故。

由于 GB2312 规定的字符编码实际上与 ISO8859 是冲突的，所以，当我们在中文环境下看一些西文的文章，使用一些西文的软件的时候，时常就会发现许多古怪的汉字出现在屏幕上，实际上就是因为西文中使用了与汉字编码冲突的字符，被我们的系统生硬的翻译成中文造成的。

不过，GB2312 统一了中文字符编码的使用，我们现在所使用的各种电子产品实际上都是基于 GB2312 来处理中文的。

GB2312-80 仅收汉字6763个，这大大少于现有汉字，随着时间推移及汉字文化的不断延伸推广，有些原来很少用的字，现在变成了常用字，例如：朱镕基的“镕”字，未收入GB2312-80，现在大陆的报业出刊只得使用（金+容）、（金容）、（左金右容）等来表示，形式不一而同，这使得表示、存储、输入、处理都非常不方便，而且这种表示没有统一标准。

为了解决这些问题，全国信息技术化技术委员会于1995年12月1日《汉字内码扩展规范》（GBK）。GBK向下与GB2312完全兼容，向上支持ISO 10646国际标准，在前者向后者过渡过程中起到的承上启下的作用。GBK 亦采用双字节表示，总体编码范围为8140-FEFE之间，高字节在81-FE之间，低字节在40-FE之间，不包括7F。在 GBK 1.0 中共收录了 21886个符号，汉字有21003个。这样基本上绝大部分的汉字都已经被包含了进来。