来源：http://www.goalercn.com/html/tech/program/c/157.html    作者：未知  
 
 
    这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题：

问题一：
使用Windows记事本的“另存为”，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？

问题二：
最近在网上看到一个ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。
查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂，但要求读者知道什么是字节，什么是十六进制。

0、big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。还是将49写在前面，就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。

我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。

1、字符编码、内码，顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

有的中文Windows的缺省内码还是GBK，可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符，普通人是很难用到的，通常我们还是用GBK指代中文Windows内码。

这里还有一些细节：

GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。

在DBCS中，GB内码的存储格式始终是big endian，即高位在前。

GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

2、Unicode、UCS和UTF
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。

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

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试图独立设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。

在1991年前后，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是10646-3:2003。

UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16。

IETF的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

3、UCS-2、UCS-4、BMP

UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。下面让我们做一些简单的数学游戏：

UCS-2有2^16=65536个码位，UCS-4有2^31=2147483648个码位。

UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为256行 (rows)，每行包含256个cells。当然同一行的cells只是最后一个字节不同，其余都相同。

group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节为0的码位被称作BMP。

将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节，就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下：

UCS-2编码(16进制)  UTF-8 字节流(二进制) 
0000 - 007F  0xxxxxxx 
0080 - 07FF  110xxxxx 10xxxxxx 
0800 - FFFF  1110xxxx 10xxxxxx 10xxxxxx 

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。

读者可以用记事本测试一下我们的编码是否正确。

UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM
UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在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。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

6、进一步的参考资料
本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：

  1."Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
  2."Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
 

顺便说一下：记事本保存成UTF8默认是带BOM的，好象没有办法去掉；editplus在选项里可以进行选择：始终带BOM，智能识别，不带BOM这些选项。所以，尽量是选择不带BOM比较好。

其实翻开PHP的手册，你也能找到这些，现在方便了，到我的博客上下载乔楚编译的最新的手册，翻开左侧树的最后一个节点：Appendices，找到：

展开这三个节点，你会看到在版本更新的时候，PHP的核心加了哪些方法，去除了哪些函数（事实上这很重要，或许在你以前的项目里一直在采用XXX方法，但新版本去掉了，很可能你的程序就不能再运行了。。。）

当然你更应该看的是：Changes in reference handling，这里面介绍的是一些老的代码写法和应用在新的代码里会出错的例子，如果你的代码里沿用了这些旧的方法，那么，你先考虑一下升级的代价吧。

今天在群里面，有个叫lewis的在问call_user_func_array的用法，因为之前一直没有用过，也不能说什么，于是看一下手册，发现是这么写的：

call_user_func_array

大家一起为我们的乔楚鼓掌。谢谢

下载地址为：php_manual_en.docs.chm

The Adjacency List Model

Typically the example categories shown above will be stored in a table like the following (I'm including full CREATE and INSERT statements so you can follow along):

CREATE TABLE category(
category_id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(20) NOT NULL,
parent INT DEFAULT NULL);


INSERT INTO category
VALUES(1,'ELECTRONICS',NULL),(2,'TELEVISIONS',1),(3,'TUBE',2),
(4,'LCD',2),(5,'PLASMA',2),(6,'PORTABLE ELECTRONICS',1),
(7,'MP3 PLAYERS',6),(8,'FLASH',7),
(9,'CD PLAYERS',6),(10,'2 WAY RADIOS',6);

SELECT * FROM category ORDER BY category_id;

+-------------+----------------------+--------+
| category_id | name                 | parent |
+-------------+----------------------+--------+
|           1 | ELECTRONICS          |   NULL |
|           2 | TELEVISIONS          |      1 |
|           3 | TUBE                 |      2 |
|           4 | LCD                  |      2 |
|           5 | PLASMA               |      2 |
|           6 | PORTABLE ELECTRONICS |      1 |
|           7 | MP3 PLAYERS          |      6 |
|           8 | FLASH                |      7 |
|           9 | CD PLAYERS           |      6 |
|          10 | 2 WAY RADIOS         |      6 |
+-------------+----------------------+--------+
10 rows in set (0.00 sec)

In the adjacency list model, each item in the table contains a pointer to its parent. The topmost element, in this case electronics, has a NULL value for its parent. The adjacency list model has the advantage of being quite simple, it is easy to see that FLASH is a child of mp3 players, which is a child of portable electronics, which is a child of electronics. While the adjacency list model can be dealt with fairly easily in client-side code, working with the model can be more problematic in pure SQL.

Retrieving a Full Tree

The first common task when dealing with hierarchical data is the display of the entire tree, usually with some form of indentation. The most common way of doing this is in pure SQL is through the use of a self-join:

SELECT t1.name AS lev1, t2.name as lev2, t3.name as lev3, t4.name as lev4
FROM category AS t1
LEFT JOIN category AS t2 ON t2.parent = t1.category_id
LEFT JOIN category AS t3 ON t3.parent = t2.category_id
LEFT JOIN category AS t4 ON t4.parent = t3.category_id
WHERE t1.name = 'ELECTRONICS';

+-------------+----------------------+--------------+-------+
| lev1        | lev2                 | lev3         | lev4  |
+-------------+----------------------+--------------+-------+
| ELECTRONICS | TELEVISIONS          | TUBE         | NULL  |
| ELECTRONICS | TELEVISIONS          | LCD          | NULL  |
| ELECTRONICS | TELEVISIONS          | PLASMA       | NULL  |
| ELECTRONICS | PORTABLE ELECTRONICS | MP3 PLAYERS  | FLASH |
| ELECTRONICS | PORTABLE ELECTRONICS | CD PLAYERS   | NULL  |
| ELECTRONICS | PORTABLE ELECTRONICS | 2 WAY RADIOS | NULL  |
+-------------+----------------------+--------------+-------+
6 rows in set (0.00 sec)

/******* 导出到excel
EXEC master..xp_cmdshell 'bcp SettleDB.dbo.shanghu out c:\temp1.xls -c -q -S"GNETDATA/GNETDATA" -U"sa" -P""'

/*********** 导入Excel
SELECT *
FROM OpenDataSource( 'Microsoft.Jet.OLEDB.4.0',
'Data Source="c:\test.xls";User ID=Admin;Password=;Extended properties=Excel 5.0')...xactions

更多看详细。。。

但同样的，这两种尿片都是宣称自己的透气性好，所以我也没有办法确定是因为好奇的尿片透气性不好呢，还是它更加强劲。

嘘嘘乐嘛。就不提了，除了那个颜色可以随着尿液的增多而逐渐变化，可以更清晰的了解尿片里尿液的存量，这点是确实不错。

PS：今年我老婆的朋友想过来玩，问到需要什么东西，想送给小孩，最后说，还是送尿片吧，比较实用，老婆随口说不要送嘘嘘乐哦，朋友笑起来了，当年你们送的就是嘘嘘乐呀。汗一下，不过几年前，我们都不了解这些东西哪个最好，也没有什么经验。呵呵

电子商务巨头 eBay 有恙，病在腠理，不治将恐深。已经好久不写针对竞争对手公司的评论了，但《福布斯》这篇文章真的让人感触良多。

硅谷的 IBM

谁的会议多，谁的效率低下:

公司内部流传着一个笑话，说eBay已经成了"硅谷的IBM"。20年前，IBM的官僚作风最终导致了公司风光不在，而这一比喻 正是对eBay当前状况的真实写照。一些现任和前任eBay员工纷纷在采访中抱怨说，eBay总是有开不完的会，公司太看中幻灯片的演示而忽视了真正的创 新。他们说，eBay成了 "商业咨询师"的聚集地，但是这些人大都是"纸上谈兵"，根本没有与客户进行深入的接触，而且缺乏技术眼光，行为方式过于保守，而真正工程师却只能在一旁 听候指挥。

不吃自己的狗粮

eBay 管理人员不用自己的产品，自然也就无从知道用户的感受:

"eBay的管理人员都很聪明，但是这些聪明人却从来都不用eBay，也没有花费足够的时间来研究他人是如何使用eBay的。"

电子商务公司需要技术高层

除了刚刚加盟前网景公司联合创始人马克-安德森(Marc Andreessen)之外，eBay公司的最高管理层中找不到任何的拥有技术背景的人。

尽管有些问题，但是 eBay 仍然是需要我们仰视。

--EOF--

相关文章|Related Articles

• eBay 的数据量 - Nov 1, 2006
• eBay 的应用服务器规模 - Nov 26, 2006
• eBay 的数据库分布扩展架构 - Jul 6, 2007
• eBay 的数据层扩展经验 - Nov 7, 2007

原文来自：http://www.dbanotes.net/review/ebay_problem.html

PS：部份文字的颜色是我自己更新的，与dbanotes的原文无关。谢谢

上张照片。。。

三大范式：第一范式，第二范式，第三范式，听着名字就很恐怖。但其实现在的人都被这个所谓的第三范式折腾死了，有事没事就拿出来涮涮，究竟怎么理解这些呢？一个一个慢慢的介绍。

数据库理论家们为数据库的设计1对N，N对N这种问题总结出了一个通用的解决方案，只需一步一步地三个范式（Normal Form）的规则应用到自己的数据库上就可以了。

第一范式的规则：

1、内容相似的数据必须“消除”（所谓消除，即再创建一个表来存储他们）

2、必须为每一组相关数组分别创建一个数据表

3、每条数据记录必须用一个主键来标识

第一条规则，看上去就比较适用于1对多的情况

第二条规则就不太好控制了，很多人认为第二条规则很难理解，数据的相关度，很难简单的描述清楚

第三条规则其实是一个实践经验，它的意思是数据表里的第一个数据行都应该包括一个独一无二的标识符作为索引。在使用MYSQL的时候，我们大多采用了自增字段来作为主键，但并非只有整数的自增字段才能作为索引，只要是独一无二的数据列，都可以用来做索引，之所以采用自增列，那是因为：1、不需要主动插入值2、整数列的时间和空间效率相对比其他类型的要高。

第二范式的规则：

1、只要数据列里的内容出现重复，就意味着应该把数据表拆分为多个子表

2、拆分形成的数据表必须用外键关联起来

第二范式，其实是在第一范式的基础上再进行一个拆分。指的就是第一范式规则的第二条内容。

外键关系在第二范式里显得特别重要，是因为第二范式时，数据会拆得更细，如果没有外键关联，恐怕数据就找不回来了。外键相当于我们日常所说的：交叉引用，对开发人员来说相当于指针。

第三范式的规则

第三范式只有一条规则：与主键没有直接关系的数据列必须“消除”

其实也就是把第二范式再分解，再建表。

可想而知，等到真正把一堆数据完全按照第三范式来进行设计的时候，恐怕在数据库里也就只能看到一堆ID了，数据呢？数据在哪里？通过外键，外键的外键，外键的外键的外键来慢慢的一个一个搜索吧。

对于MYSQL 4.1以下的版本，第三范式是会要了他们的命的，foreign key功能的不完善，让MYSQL 4.1以下版本，基本不适合第三范式，能用到第二范式设计时，数据表的效率已经几乎不能保证了。

这三个范式是著名学者E.F.Codd最先提出来的，后人在此基础 上对大到数学集合理论、小到关系数据库设计细节等诸多方面进行了研究和探索。如果对这方面有兴趣的朋友，还是多找找相关的书籍看看为好。

如果你的性子比较急，那么你可以尝试按照下面的方法来进行：

1、设计数据库的时候，一定要给自己充足的时间，如果等到数据库充满了数据，而程序也几乎开发完毕时，才发现数据库设计有缺陷，那么花费的代价就太大了

2、如果发现自己创建的表的数据列有序号，如name1,name2等，那一般就意味着还有更好的解决方案没有采用。可以考虑多创建一个表，而把这些分拆开。

3、第一时间往数据库里多插点测试数据，如果发现冗余量很大，往往就是表需要分拆的信号

4、设计时应该注意数据与数据之间的关联及引用关系

5、对于设计完的数据库，应该自己尝试写SQL语句，看看能否达到你预想的目标，如果达不到，那就要考虑是否设计的有问题。

6、如果你还是等不急，根据你的需要，到网上找找有没有类似的示例数据库，可以考虑拿来作借鉴。

说了这么多时间的范式，最后再说说他们的优缺点吧

缺点：数据表的个数越多，也就相对证明了从表单里获取数据并往表里插的时候，复杂性非常大，给开发人员会带来很大的困扰。同样，表多了，查询结果时，从中提取相关数据生成查询结果的复杂性也就越大；数据库的容量随着表的拆分量的增大而增大（不过现在也不是什么矛盾了，硬盘的价格几乎也快到了白菜价了，这点可以被忽略）

优点：严格按照范式设计出来的数据库，能够提供最丰富、最灵活的查询选项，人们往往都是在等到必须使用一种新的查询或者必须对数据进行一种新的分类时才会真正意识到这一点，但可惜的是，这些新需求往往都是出现在数据库已投入运行数月之后，到时候再改数据库，代价非常大。

不会象写小说那样太监掉的，毕竟这个东西对我自己来说，也是一种学习

给自己加油，为自己打气。也谢谢大家的支持

传上那样受刺激的图片先

美国众议院、参议院终于同意了救市方案，7000亿美金，听起来很恐怖，可惜股市还是下跌了，恐怕华尔街那些人就非常开心了，压力会小一点了。我在上篇杂谈里就说过，不希望会有这种事情发生，毕竟有第一次也就会有第二次。布什在促进这件事成功，是因为不想留下污点？个人认为。两个竞选者促进成功，是因为这样可以在上台后压力小一点，反正用的钱又不是我的，也不是我下令的，责任不在我身上。可惜对于美国这种物权法很看中的国家来说，民众是怎么想的？7000亿，要纳多少税？在用自己的钱救市，心里是迷惘多一点还是期盼多一点？我交出去的钱，终于派上用场了？可惜，华尔街人应该也在想，怕啥，再怎么样，还是会有人帮我的。。。

除开经济，恐怕搞技术的人这两天都在关注着GOOGLE推出的在线备份MYSQL的innodb数据库？这里提到了，这里也提到了，其实讲的都是GOOLE CODE上的内容，谁来做小白鼠？短时间内谁敢用？估计还是要过段时间了，不过，这毕竟是一个想法，以后这种类似的东西会越来越多的吧？

再说说软件，思维导图，应该算是最近一段时间比较流行的东西了，思维导图是国内人员的翻译，详细介绍如下：

听说，从明年开始也要取消国庆长假了，如果这项提议转为事实，那么以后出行的机会又要少上很多，那些单位年假不多的人，又要痛哭了。

除此之外，新闻里报道美国国会在投票7000亿救市的时候，选择了否诀，个人认为这是一个明智的决定，如果真的同意了，那么有了第一次就会有第二次，虽说经济和政治挂钩，但政治不应该去主动的影响经济，顺其自然，不过这次也算是全球性的影响。我们国家可能损失会更大。

光靠一两个救市是没有用的，而应该让民众感觉到对市场的放心。乱就一个字

世事无常，今年的灾害特别多，可能也是与全球变暖有关吧，少开点空调，少有点污染，世界将会变得清静。

不多废话

希望明年的国庆会更好，朋友们，快乐！

原文来自cssrain，只取了其中的一小部分。http://www.cssrain.cn/demo/3/newDate.html

结果：1和2的结果是一样的。但这个number是13位的number，和PHP中的时间戳并非同一个意义