add swap to resolve the problem of SQL crash

解决方法如下：

1. sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
2. sudo mkswap /swapfile
3. sudo swapon /swapfile
4. sudo vi /etc/fstab
5. 添加"/swapfile swap swap defaults 0 0"到末尾

Nginx如何实现http跳转到https

Nginx服务器

在配置80端口的文件中，添加以下代码：

server {

listen 80;

server_name localhost;

rewrite ^(.*)$ https://$host$1 permanent;

location / {

root html;

index index.html index.htm;

}

https证书的三种类型

DV SSL证书：指只验证网站域名所有权的简易型SSL证书，此类证书仅能起到网站机密信息加密的作用，无法向用户证明网站的真实身份。所以，不推荐在电子商务网站部署 DV SSL证书，因为电子商务首先需要的是在线信任，其次才是在线安全。

OV SSL 是 Organization Validation SSL 的缩写，指需要验证网站所有单位的真实身份的标准型SSL证书，此类证书也就是正常的SSL证书，不仅能起到网站机密信息加密的作用，而且能向用户证明网站的真实身份。所以，推荐在所有电子商务网站使用，因为电子商务需要的是在线信任和在线安全。从 SSL 证书的诞生史可以看出：标准型 SSL 证书就是 OV SSL证书(Organization Validation SSL)。

EV SSL 是 Extended Validation SSL 的缩写，指遵循全球统一的严格身份验证标准颁发的SSL证书，是目前业界最高安全级别的SSL证书。用户访问部署了EV SSL证书的网站，不仅浏览器地址栏会显示安全锁标志，而且浏览器地址栏会变成绿色。所以，推荐所有电子商务网站都部署EV SSL证书，因为电子商务首先需要的是在线信任，其次才是在线安全。EV SSL证书，绿色安全通道，增强在线信任，促成更多在线订单！

How to use hreflang and canonical tags together

When you use hreflang tags as well as canonical tags on your website, you have to be careful not to send confusing signals to Google. Here’s how to implement hreflang tags when you already have a canonical tag solution on your website.

Note: This article was first published on rebelytics.com in 2015 and has since then been updated several times and moved to this blog.

hreflang and canonical tags both have similar functions: They suggest to Google which URLs to index. If you already have a canonical tag solution on your website, which asks Google not to implement certain URLs, and you then add hreflang tags to all of your URLs, you will confuse Google. You will be asking Google to index and not to index certain URLs at the same time.

What do URLs with canonical tags want?

A URL that has a canonical tag pointing to another URL says to Google:

“Hey Google, how’s it going? I don’t want to be indexed. But you can index my twin sister here instead of me?”

A URL that has a canonical tag pointing to itself says to Google:

“Howdy Google, please index me and not my stupid twin brothers.”

Now you have to make sure that your URLs with canonical tags still know what they want after you’ve implemented hreflang on your website:

What do URLs with hreflang want?

A URL with correctly implemented hreflang implementations could say to Google:

“Bonjour Google, comment ça va? I speak French and I want to be indexed. Here are my cousins from other countries. Can you please index them too?”

So URLs with hreflang annotations always want to be indexed and always want additional URLs (their equivalents in other language and country versions) to be indexed along with them.

What do URLs with canonical tags and hreflang annotations want?

Now let’s see what a URL that has a canonical tag pointing to itself and hreflang annotations says to Google:

“Hola Google, ¿qué tal? I am the most mature out of my twin brothers and I want to be indexed. I speak Spanish and these are my cousins from other countries. Can you please index them too?”

This is a very clear and easy to follow instruction for Google. But what if the URL has a canonical tag pointing to another URL and hreflang annotations at the same time?

“Guten Tag Google, wie geht’s? I don’t want to be indexed, please index my twin brother instead. I speak German, so please index me and here are my cousins from other countries. Please index them too.”

And then Google will say:

“What a nutcase! Let’s see what his cousins say.”

And then Google will visit the other URLs in the hreflang annotations and hear a choir of:

“Buon giorno, 今日は, добрый день! We don’t want to be indexed, please index our twin sisters instead of us. But we really want to be indexed, so please? And please, please index all of us because we are all cousins from different countries.”

And then Google will say:

“Shut up! I’m not listening to you and I will just figure out who to index myself.”

If you send confusing signals, Google will ignore your instructions. So make sure your URLs know what they want!

Conclusion

If you are using a canonical tag solution on your website, make sure that URLs that have a canonical tag pointing to another URL do not receive hreflang annotations. hreflang annotations are okay for URLs that point to themselves via canonical tag and for URLs that do not have canonical tags.

Exception: Mobile and AMP URLs

With the announcement of the mobile-first index, Google have changed their recommendations for hreflang on mobile URLs. In the past, it was clear that mobile URLs should have canonical tags pointing to their desktop equivalents and therefore should not receive hreflang annotations. Now, the new recommendation is to add hreflang to the mobile URLs and to the desktop URLs:

Aleyda Solis

✔@aleyda

 · Nov 30, 2017

Replying to @JohnMu and 2 others

Hi John! Could you please confirm this new hreflang setting for mobile first index with an independent mobile setting then? > https://twitter.com/aleyda/status/934716205360873472 …

Aleyda Solis

✔@aleyda

@methode Hi Gary! I wanted to confirm the hreflang configuration update in mobile URLs mentioned during your Pubcon session that @jenstar tweeted here: https://twitter.com/jenstar/status/928768945137393664 … - the update would be like shown in this image or something else? :) Thanks for the clarification!

 John 

✔@JohnMu

Yes, mobile-to-mobile & desktop-to-desktop is our recommendation for hreflang.

20

12:37 AM - Nov 30, 2017

Twitter Ads info and privacy

See  John 's other Tweets

As a reader of this blog post, you are probably wondering whether it makes sense to keep the canonical tags pointing from the mobile URLs to their desktop equivalents.

A mobile URL that points to its desktop version via canonical tag and that has hreflang annotations at the same time is clearly sending mixed signals, especially once the mobile-first index is reality.

Let’s see how long Google sticks with the recommendation to have canonical tags pointing from mobile URLs to desktop URLs.

According to this source, the same new recommendation is valid for AMP pages: Canonical tags from AMP versions to desktop versions and hreflang between AMP pages and between desktop pages.

PXE+HTTP 无盘安装linux系统

1.    建立服务器
    服务器需要安装DHCP、TFTP、WEB组件。
2.    配置服务器
    2.1    DHCP
        [root@WORKCENTRE ~]# touch /etc/dhcpd.conf
        [root@WORKCENTRE ~]# vi /etc/dhcpd.conf
              #--DHCP conf file begin
            ddns-update-style interim;
            ignore client-updates;

            subnet 192.168.1.0 netmask 255.255.255.0 {

            # --- default gateway
                option routers                  192.168.1.1;
                option subnet-mask              255.255.255.0;

            #    option nis-domain               "domain.org";
            #   option domain-name              "domain.org";
                option domain-name-servers      203.196.0.6;

                option time-offset              -18000; # Eastern Standard Time
            #       option ntp-servers              192.168.1.1;
            #       option netbios-name-servers     192.168.1.1;
            # --- Selects point-to-point node (default is hybrid). Don't change this unless
            # -- you understand Netbios very well
            #       option netbios-node-type 2;

            range dynamic-bootp 192.168.1.228 192.168.1.236;
            default-lease-time 21600;
            max-lease-time 43200;

            # we want the nameserver to appear at a fixed address
            host WORK-LAPTOP {
                        next-server 192.168.1.88;        //tftp服务器的地址
                        hardware ethernet 00 : 16 : D3 : 3B : 77 :63;
                        fixed-address 192.168.1.90;
                        filename "pxelinux.0";
                    }
            }
            
            #--DHCP conf file end
            
    2.2 TFTP
        [root@WORKCENTRE ~]# mkdir /tftpboot
        [root@WORKCENTRE ~]# cp /usr/lib/syslinux/pxelinux.0 /tftpboot/
        [root@WORKCENTRE ~]# mkdir /tftpboot/pxelinux.cfg/
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc1.iso /mnt/
        [root@WORKCENTRE ~]# cp /mnt/images/pxeboot/initrd.img /tftpboot/
        [root@WORKCENTRE ~]# cp /mnt/images/pxeboot/vmlinuz /tftpboot/
        [root@WORKCENTRE ~]# touch /tftpboot/pxelinux.cfg/default
        [root@WORKCENTRE ~]# vi /tftpboot/pxelinux.cfg/default

             #--default file begin               
                default linux
            
             label linux
                  kernel vmlinuz
                  append initrd=initrd.img
                #--default file end

3.    拷贝安装文件
        [root@WORKCENTRE ~]# mkdir /var/www/html/FC6
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc1.iso /mnt/  
        [root@WORKCENTRE ~]# cp -r /mnt/images/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# cp -r /mnt/repodata/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# cp -r /mnt/Fedora/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# umount /mnt/
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc2.iso /mnt/
        [root@WORKCENTRE ~]# cp -r /mnt/Fedora/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# umount /mnt/
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc3.iso /mnt/
        [root@WORKCENTRE ~]# cp -r /mnt/Fedora/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# umount /mnt/
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc4.iso /mnt/
        [root@WORKCENTRE ~]# cp -r /mnt/Fedora/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# umount /mnt/
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc5.iso /mnt/
        [root@WORKCENTRE ~]# cp -r /mnt/Fedora/ /var/www/html/FC6/
        [root@WORKCENTRE ~]# umount /mnt/
        [root@WORKCENTRE ~]# mount -o loop /FC-6-x86_64-disc6.iso /mnt/
        [root@WORKCENTRE ~]# cp -r /mnt/Fedora/ /var/www/html/FC6/

4.   启动服务
        [root@WORKCENTRE ~]# /etc/init.d/dhcpd start
        [root@WORKCENTRE ~]# /etc/init.d/httpd start
        [root@WORKCENTRE ~]# chkconfig tftp on

5.    开始安装
        打开笔记本，F12选择从网络引导。
       安装文件选择HTTP。输入网址和路径。

       其他和光盘安装一样。  

PHP会话(Session)使用入门

　　对比起 Cookie，Session 是存储在服务器端的会话，相对安全，并且不像 Cookie 那样有存储长度限制，本文简单介绍 Session 的使用。

　　由于 Session 是以文本文件形式存储在服务器端的，所以不怕客户端修改 Session 内容。实际上在服务器端的 Session 文件，PHP 自动修改 Session 文件的权限，只保留了系统读和写权限，而且不能通过 ftp 修改，所以安全得多。

　　对于 Cookie 来说，假设我们要验证用户是否登陆，就必须在 Cookie 中保存用户名和密码（可能是 md5 加密后字符串），并在每次请求页面的时候进行验证。如果用户名和密码存储在数据库，每次都要执行一次数据库查询，给数据库造成多余的负担。因为我们并不能只做一次验证。为什么呢？因为客户端 Cookie 中的信息是有可能被修改的。假如你存储 $admin 变量来表示用户是否登陆，$admin 为 true 的时候表示登陆，为 false 的时候表示未登录，在第一次通过验证后将 $admin 等于 true 存储在 Cookie，下次就不用验证了，这样对么？错了，假如有人伪造一个值为 true 的 $admin 变量那不是就立即取的了管理权限么？非常的不安全。

　　而 Session 就不同了，Session 是存储在服务器端的，远程用户没办法修改 Session 文件的内容，因此我们可以单纯存储一个 $admin 变量来判断是否登陆，首次验证通过后设置 $admin 值为 true，以后判断该值是否为 true，假如不是，转入登陆界面，这样就可以减少很多数据库操作了。而且可以减少每次为了验证 Cookie 而传递密码的不安全性了（Session 验证只需要传递一次，假如你没有使用 SSL 安全协议的话）。即使密码进行了 md5 加密，也是很容易被截获的。

　　当然使用 Session 还有很多优点，比如控制容易，可以按照用户自定义存储等（存储于数据库）。我这里就不多说了。

　　Session 在 php.ini 是否需要设置呢？一般不需要的，因为并不是每个人都有修改 php.ini 的权限，默认 Session 的存放路径是服务器的系统临时文件夹，我们可以自定义存放在自己的文件夹里，这个稍后我会介绍。

　　开始介绍如何创建 Session。非常简单，真的。

　　启动 Session 会话，并创建一个 $admin 变量：

<?php 
//  启动 Session 
session_start(); 
//  声明一个名为 admin 的变量，并赋空值。 
$_SESSION["admin"] = null; 
?>

　　如果你使用了 Seesion，或者该 PHP 文件要调用 Session 变量，那么就必须在调用 Session 之前启动它，使用 session_start() 函数。其它都不需要你设置了，PHP 自动完成 Session 文件的创建。

　　执行完这个程序后，我们可以到系统临时文件夹找到这个 Session 文件，一般文件名形如：sess_4c83638b3b0dbf65583181c2f89168ec，后面是 32 位编码后的随机字符串。用编辑器打开它，看一下它的内容：

admin|N; 一般该内容是这样的结构：

变量名|类型:长度:值; 　　并用分号隔开每个变量。有些是可以省略的，比如长度和类型。

　　我们来看一下验证程序，假设数据库存储的是用户名和 md5 加密后的密码：

login.php

<?php 
//  表单提交后... 
$posts = $_POST; 
//  清除一些空白符号 
foreach ($posts as $key => $value) {
    $posts[$key] = trim($value); 
} 
$password = md5($posts["password"]); 
$username = $posts["username"]; 

$query = "SELECT `username` FROM `user` WHERE `password` = '$password' AND `username` = '$username'"; 
//  取得查询结果 
$userInfo = $DB->getRow($query); 

if (!empty($userInfo)) { 
    //  当验证通过后，启动 Session 
    session_start(); 
    //  注册登陆成功的 admin 变量，并赋值 true 
    $_SESSION["admin"] = true;  
} else { 
    die("用户名密码错误"); 
} 
?>

　　我们在需要用户验证的页面启动 Session，判断是否登陆：

<?php 
//  防止全局变量造成安全隐患 
$admin = false; 
//  启动会话，这步必不可少 
session_start(); 
//  判断是否登陆 
if (isset($_SESSION["admin"]) && $_SESSION["admin"] === true) { 
    echo "您已经成功登陆"; 
} else { 
    //  验证失败，将 $_SESSION["admin"] 置为 false
    $_SESSION["admin"] = false; 
    die("您无权访问"); 
} 
?>

　　是不是很简单呢？将 $_SESSION 看成是存储在服务器端的数组即可，我们注册的每一个变量都是数组的键，跟使用数组没有什么分别。

　　如果要登出系统怎么办？销毁 Session 即可。

<?php 
session_start(); 
//  这种方法是将原来注册的某个变量销毁
unset($_SESSION['admin']); 
//  这种方法是销毁整个 Session 文件
session_destroy(); 
?>

　　Session 能否像 Cookie 那样设置生存周期呢？有了 Session 是否就完全抛弃 Cookie 呢？我想说，结合 Cookie 来使用 Session 才是最方便的。

　　Session 是如何来判断客户端用户的呢？它是通过 Session ID 来判断的，什么是 Session ID，就是那个 Session 文件的文件名，Session ID 是随机生成的，因此能保证唯一性和随机性，确保 Session 的安全。一般如果没有设置 Session 的生存周期，则 Session ID 存储在内存中，关闭浏览器后该 ID 自动注销，重新请求该页面后，重新注册一个 Session ID。

　　如果客户端没有禁用 Cookie，则 Cookie 在启动 Session 会话的时候扮演的是存储 Session ID 和 Session 生存期的角色。

　　我们来手动设置 Session 的生存期：

<?php 
session_start(); 
//  保存一天 
$lifeTime = 24 * 3600; 
setcookie(session_name(), session_id(), time() + $lifeTime, "/"); 
?>

　　其实 Session 还提供了一个函数 session_set_cookie_params(); 来设置 Session 的生存期的，该函数必须在 session_start() 函数调用之前调用：

<?php 
//  保存一天 
$lifeTime = 24 * 3600; 
session_set_cookie_params($lifeTime); 
session_start(); 
$_SESSION["admin"] = true; 
?>

　　如果客户端使用 IE 6.0 ， session_set_cookie_params(); 函数设置 Cookie 会有些问题，所以我们还是手动调用 setcookie 函数来创建 cookie。

　　假设客户端禁用 Cookie 怎么办？没办法，所有生存周期都是浏览器进程了，只要关闭浏览器，再次请求页面又得重新注册 Session。那么怎么传递 Session ID 呢？通过 URL 或者通过隐藏表单来传递，PHP 会自动将 Session ID 发送到 URL 上，URL 形如：http://www.openphp.cn/index.php?PHPSESSID=bba5b2a240a77e5b44cfa01d49cf9669，其中 URL 中的参数 PHPSESSID 就是 Session ID了，我们可以使用 $_GET 来获取该值，从而实现 Session ID 页面间传递。

<?php 
//  保存一天 
$lifeTime = 24 * 3600; 
//  取得当前 Session 名，默认为 PHPSESSID 
$sessionName = session_name(); 
//  取得 Session ID 
$sessionID = $_GET[$sessionName]; 
//  使用 session_id() 设置获得的 Session ID 
session_id($sessionID); 

session_set_cookie_params($lifeTime); 
session_start(); 
$_SESSION['admin'] = true; 
?>

　　对于虚拟主机来说，如果所有用户的 Session 都保存在系统临时文件夹里，将给维护造成困难，而且降低了安全性，我们可以手动设置 Session 文件的保存路径，session_save_path() 就提供了这样一个功能。我们可以将 Session 存放目录指向一个不能通过 Web 方式访问的文件夹，当然，该文件夹必须具备可读写属性。

<?php 
//  设置一个存放目录 
$savePath = './session_save_dir/'; 
//  保存一天 
$lifeTime = 24 * 3600; 
session_save_path($savePath); 
session_set_cookie_params($lifeTime); 
session_start(); 
$_SESSION['admin'] = true; 
?>

　　同 session_set_cookie_params(); 函数一样，session_save_path() 函数也必须在 session_start() 函数调用之前调用。

　　我们还可以将数组，对象存储在 Session 中。操作数组和操作一般变量没有什么区别，而保存对象的话，PHP 会自动对对象进行序列化（也叫串行化），然后保存于 Session 中。下面例子说明了这一点：

person.php

<?php 
class person { 
    var $age; 
    function output() { 
        echo $this->age; 
    } 
    function setAge($age) { 
        $this->age = $age; 
    } 
} 
?>

setage.php

<?php 
session_start(); 
require_once 'person.php'; 
$person = new person(); 
$person->setAge(21); 
$_SESSION['person'] = $person; 
echo '<a href='output.php'>check here to output age</a>'; 
?>

output.php

<?php
// 设置回调函数，确保重新构建对象。 
ini_set('unserialize_callback_func', 'mycallback'); 
function mycallback($classname) { 
    include_once $classname . '.php'; 
} 
session_start(); 
$person = $_SESSION['person']; 
//  输出 21 
$person->output(); 
?>

　　当我们执行 setage.php 文件的时候，调用了 setage() 方法，设置了年龄为 21，并将该状态序列化后保存在 Session 中（PHP 将自动完成这一转换），当转到 output.php 后，要输出这个值，就必须反序列化刚才保存的对象，又因为在解序列化的时候需要实例化一个未定义类，所以我们定义了以后回调函数，自动包含 person.php 这个类文件，因此对象被重构，并取得当前 age 的值为 21，然后调用 output() 方法输出该值。

　　另外，我们还可以使用 session_set_save_handler 函数来自定义 Session 的调用方式。

一篇关于Unicode编码的UCS、UTF、BMP、BOM等概念的不错的文章

由于要做一些中文话的工作，牵涉到中文的GB2312,GBK,Big5以及Unicode之类的编码，找了一些资料发现下面这篇写的还是相当不错的。很可惜好文章总是很有“中文特色”，一搜一大把同样的文章，转来转去已经找不到原始出处了。作者看到的话（或者哪位知道的话），还请好心告知。下面是文章内容：

这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打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个字符。

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

2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族 文字。从汉字字汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码 0×3400-0×4db5），一共收录了27484个汉字。

CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。

GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。 例如：UCS的0×3400在GB18030中的编码应该是8139EF30，UCS的0×3401在GB18030中的编码应该是8139EF31。

微软提供了GB18030的升级包，但这个升级包只是提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030，并不改变内码。Windows 的内码仍然是GBK。

这里还有一些细节：

• GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
• 对于任何字符编码，编码单元的顺序是由编码方案指定的，与endian无关。例如GBK的编码单元是字节，用两个字节表示一个汉字。 这两个字节的顺序是固定的，不受CPU字节序的影响。UTF-16的编码单元是word（双字节），word之间的顺序是编码方案指定的，word内部的字节排列才会受到endian的影响。后面还会介绍UTF-16。
• 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的最新标准是ISO 10646-3:2003。

UCS只是规定如何编码，并没有规定如何传输、保存这个编码。例如“汉”字的UCS编码是6C49，我可以用4个ascii数字来传输、保存这个编码；也可以用utf-8编码:3个连续的字节E6 B1 89来表示它。关键在于通信双方都要认可。UTF-8、UTF-7、UTF-16都是被广泛接受的方案。UTF-8的一个特别的好处是它与ISO-8859-1完全兼容。UTF是“UCS Transformation Format”的缩写。

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

2.1、内码和code page

目前Windows的内核已经支持Unicode字符集，这样在内核上可以支持全世界所有的语言文字。但是由于现有的大量程序和文档都采用了某种特定语言的编码，例如GBK，Windows不可能不支持现有的编码，而全部改用Unicode。

Windows使用代码页(code page)来适应各个国家和地区。code page可以被理解为前面提到的内码。GBK对应的code page是CP936。微软也为GB18030定义了code page：CP54936。

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。

读者可以用记事本测试一下我们的编码是否正确。需要注意，UltraEdit在打开utf-8编码的文本文件时会自动转换为UTF-16，可能产生混淆。你可以在设置中关掉这个选项。更好的工具是Hex Workshop。

UTF-16以16位为单元对UCS进行编码。对于小于0×10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不 小于0×10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0×10000，所以就目前而言，可以认为 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)

我写过UTF-8、UCS-2、GBK相互转换的软件包，包括使用Windows API和不使用Windows API的版本。以后有时间的话，我会整理一下放到我的个人主页上(http://www.fmddlmyy.cn)。

我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。

附录1 再说说区位码、GB2312、内码和代码页

有的朋友对文章中这句话还有疑问：
“GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。”

我再详细解释一下：

“GB2312的原文”是指国家1980年的一个标准《中华人民共和国国家标准 信息交换用汉字编码字符集 基本集 GB 2312-80》。这个标准用两个数来编码汉字和中文符号。第一个数称为“区”，第二个数称为“位”。所以也称为区位码。1-9区是中文符号，16-55 区是一级汉字，56-87区是二级汉字。现在Windows也还有区位输入法，例如输入1601得到“啊”。（这个区位输入法可以自动识别16进制的 GB2312和10进制的区位码，也就是说输入B0A1同样会得到“啊”。）

内码是指操作系统内部的字符编码。早期操作系统的内码是与语言相关的。现在的Windows在系统内部支持Unicode，然后用代码页适应各种语言，“内码”的概念就比较模糊了。微软一般将缺省代码页指定的编码说成是内码。

内码这个词汇，并没有什么官方的定义，代码页也只是微软这个公司的叫法。作为程序员，我们只要知道它们是什么东西，没有必要过多地考证这些名词。

Windows中有缺省代码页的概念，即缺省用什么编码来解释字符。例如Windows的记事本打开了一个文本文件，里面的内容是字节流：BA、BA、D7、D6。Windows应该去怎么解释它呢？

是按照Unicode编码解释、还是按照GBK解释、还是按照BIG5解释，还是按照ISO8859-1去解释？如果按GBK去解释，就会得到“汉 字”两个字。按照其它编码解释，可能找不到对应的字符，也可能找到错误的字符。所谓“错误”是指与文本作者的本意不符，这时就产生了乱码。

答案是Windows按照当前的缺省代码页去解释文本文件里的字节流。缺省代码页可以通过控制面板的区域选项设置。记事本的另存为中有一项ANSI，其实就是按照缺省代码页的编码方法保存。

Windows的内码是Unicode，它在技术上可以同时支持多个代码页。只要文件能说明自己使用什么编码，用户又安装了对应的代码页，Windows就能正确显示，例如在HTML文件中就可以指定charset。

有的HTML文件作者，特别是英文作者，认为世界上所有人都使用英文，在文件中不指定charset。如果他使用了0×80-0xff之间的字符， 中文Windows又按照缺省的GBK去解释，就会出现乱码。这时只要在这个html文件中加上指定charset的语句，例如：
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO8859-1″>
如果原作者使用的代码页和ISO8859-1兼容，就不会出现乱码了。

再说区位码，啊的区位码是1601，写成16进制是0×10,0×01。这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII 编码，我们在区位码的高、低字节上分别加上A0。这样“啊”的编码就成为B0A1。我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的 原文根本没提到这一点。