如果你完全忘掉了我刚刚解释过的内容，没有关系，请记住一点，如果你不知道一个字符串所使用的编码，这个字符串在你手中也就毫无意义。你不能再把脑袋埋进沙中以为"纯文本"就是ASCII。事实上，
那么我们如何得知一个字符串所使用的空间是何种编码呢？对于这个问题已经有了标准的作法。如果是一份电子邮件，你必须在格式的头部有如下语句：
Content-Type: text/plain; charset="UTF-8"
对于一个网页，传统的想法是Web服务器会返回一个类似于Content-Type的http头和Web网页，注意，这里的字符编码并不是在HTML中指出，而是在独立的响应headers中指出。
这带来了一些问题。假设你拥有一个大的Web服务器，拥有非常多的站点，每个站点都包括数以百计的Web页面，而写这些页面的人可能使用不同的语言，他们在他们自己计算机上的FrontPage等工具中看到页面正常显示就提交了上来，显然，服务器是没有办法知道这些文件究竟使用的是何种编码，当然 Content-Type头也没有办法发送了。
如果可以把Content-Type夹在HTML文件中，那不是会变得非常方便？这个想法会让纯粹论者发疯，你如何在不知道它的编码的情况下读一个HTML文件呢？答案很简单，因为几乎所有的编码在32-127的码字都做相同的事情，所以不需要使用特殊字符，你可以从HTML文件中获得你想要的Content-Type。
<html>
<head>
<meta http-equiv="Conent-Type" content="text/html" charset="utf-8">
注意，这里的meta标签必须在head部分第一个出现，一旦浏览器看到这个标签就会马上停止解析页面，然后使用这个标签中给出的编码从头开始重新解析整个页面。
如果浏览器在http头或者meta标签中都找不到相关的Content-Type信息，那应该怎么办？Internet Explorer做了一些事情：它试图猜测出正确的编码，基于不同语言编码中典型文本中出现的那些字节的颇率。因为古老的8比特的码页(code pages)倾向于把它们的国家编码放置在128-255码字的范围内，而不同的人类语言字母系统中的字母使用颇率对应的直方图会有不同，所以这个方法可以奏效。虽然很怪异，但对于那些老忘记写Content-Type的幼稚网页编写者而言，这个方法大多数情况下可以让他们的页面显然OK。直到有一天，他们写的页面不再满足"letter-frequency-distribution"，Internet Explore觉得这应该是朝鲜语，于是就当朝鲜语来显示了，结果显然糟透了。这个页面的读者们立刻就遭殃了，一个保加利亚语写的页面却用朝鲜语来显示，效果会怎样？于是读者使用 查看-->编码 菜单来不停地试啊试，直到他终于试出了正确的编码，但前提是他知道可以这样做，事实上大多数人根本不会这样做。
在我的公司开发的一款Web页面管理软件CityDesk的最新版本中，我们决定像Visual Basic、COM和Windows NT/2000/XP所做的那样，整个过程中使用UCS-2（两个字节）Unicode。在我们写的C++代码中，我们把所有的char类型换成了wchar_t，所有使用str函数的地方，换成了相应的wcs函数（如使用wcscat和wcslen来替代strcat和strlen）。如果想在C中创建一个UCS-2的字符串，只需在字符串前面加L即可：L"Hello"。
当CityDesk发布页面的时候，它把所有的页面都转换成了UTF-8编码，而差不多所有的浏览器都对UTF-8有不错的支持。这就是"Joel On Software"（就是作者的首页）编码的方式，所以即使它拥有29个语言版本，至今也未听到有一个人抱怨页面无法浏览。
这篇文章已经有点长了，而且我也没有办法告诉你关于字符编码和Unicode的所有应该了解的知识，但读到现在我想你已经掌握到基本的概念，回去编程时可以使用抗生素而不是蚂蝗和咒语了，这就看做是留给你的作业吧。