Azure平台的计费模型可以分为以下几个方面：

• 计算费用
• 存储费用
• 请求事务费用
• 连接费用
• 带宽费用

在开始介绍之前需要说明一下，下面我提到的"Azure平台"，是笼统的包括整个云平台提供的所有服务，而当我提到"Windows Azure"的时候，则不包括Sql Azure和AppFabric服务的。

计算费用

在Windows Azure中创建的Hosted Service就是一个计算服务（Compute Service）。每个计算服务提供了两个部署平台插槽，Production和Stage，Production平台通常用于生产环境，对外地址是固定的，在创建Service的时候就已经确定了。而Stage一般用于测试开发，地址随每次部署变更。

一般的开发流程是先将应用程序部署到Stage平台上，测试完毕之后将其切换到Production平台。

但是Production和Stage平台的收费标准没有任何区别。

每个计算服务由若干个角色（Role）组成，每个角色由若干个计算实例（Compute Instance）组成。每个计算实例都运行在单独的VM中，我们可以把VM理解为一台单独的机器，它拥有独立的CPU数目，内存以及本地存储。VM有不同规格的配置，依次为Small,medium,large,extralarge，如下表所示。

计算服务的计费公式：

使用小时数 * 实例数（也就是VM的数目） * 计费基准（也就是0.12 x 不同规格VM使用的CPU数目）

或者这个公式可能更好理解： 使用小时数 * 使用的CPU总数 * 0.12

这里需要注意两点：

1. 使用小时数是从一部署就开始计算，除非删除应用，否则一直算钱。不足一小时以一小时计算。

2. 实例数包括了Production和Stage两个平台。

存储费用

Azure平台的存储费用包括两个部分，一个是Windows Azure存储，另一个是Sql Azure数据库存储。

Windows Azure提供的存储服务包括Table、Queue和Blob存储。以月作为一个周期，统计一个月内上传的容量，然后平摊到每一天得到平均值。根据这个日平均值来收费。

Windows Azure存储费用为$0.15 /GB

而Sql Azure根据创建的数据库大小不同，收费也不同，和Windows Azure存储服务类似，也是统计每个月创建的数据库总容量，然后平摊到月内每一天，最后按照日平均值收费。

Sql Azure数据库存储费用为$9.99 /GB

以11月份（30天）计费周期为例，你在1号的时候创建了一个10G的数据库，但是只用了15天，接下来的15天你已经删除这个数据库了，那么11月份的日均存储为(10*15+0*15) / 30 = 5G。和你创建一个5G的数据库然后用上整月的收费是一样的。

请求事务（Transaction）费用

向Azure平台服务发起的HTTP请求称为事务（Transaction）。包括以下几个方面：

• 应用程序访问Windows Azure存储服务（Blob、Table、Queue）
• CDN节点访问Windows Azure存储服务（Blob、Table、Queue）
• 应用程序向Access Control访问控制服务（AppFabric的一个组件）发起请求

其中：

应用程序向Windows Azure存储服务发起的事务的费用为$0.01 /10K，即1万次事务0.01美元；

CDN发起的事务为$0.01 /10K；

应用程序向Access Control发起的事务为$1.99 /100K，

连接收费（Service Bus）

Azure平台的AppFabric提供了两个服务，一个是Access Control访问权限控制，另外一个就是Service Bus。Service Bus允许你将企业内部的应用通过Azure平台发布到互联网上，以便和第三方应用程序通讯。注意，应用程序本身并没有部署到Azure平台，Service Bus只是起一个数据转接的作用。下面是一个简单的示意流程：

企业应用=>企业防火墙=>AppFabric Service Bus服务=>暴露通讯端点

第三方应用程序就通过Azure平台上Service Bus暴露的互联网唯一通讯地址来和企业应用进行通讯。

这个过程会产生一些网络连接，包括第三方应用程序和Service Bus端点之间的连接，以及Service Bus和企业应用程序之间的连接。

Azure会按照一个月内平均的每天最大并发连接数目来进行计费。

那么这个每天最大并发连接数怎么计算出来的呢？

Azure每天以5分钟为间隔，统计当前时刻的并发连接数，这样一天下来就可以得到当天的最大并发连接数了。将一个月内每天的最大并发连接数累加起来，再平摊到每一天上就得到当前计费周期的日平均最大并发连接数，按此数值收费。

你可以选择按需计费，也可以选择购买固定最大连接数。这两种资费标准不同。

按需计费，每个连接为$3.99，而购买固定连接数，每个连接只需花费$1.99。Azure提供了5, 25, 100 或者500个连接的这几种套餐。

如果你的网站并发数不确定，那么你可以选择按需支付，这样每天的并发连接数再大也不会有问题（尽管如此，Azure自身还是限制了最大的并发数），只不过你需要多付一些钱而已。但对于那些能够预先估计自己的日最大并发连接数的客户来说，他可以选择购买固定连接数套餐，这样一个月的花费就是确定的了。当然，这样的坏处就是，一旦超过购买的峰值连接数，就无法接受新的连接。

例如某个小型网站，预计每天最大并发数不超过20个连接，那么他可以购买25个连接的套餐，这样一个月就固定花费49.75美元。

带宽费用

一旦数据中心节点内外之间发生任何数据传输，均需要计入带宽费用。包括上面提到的存储请求、事务请求以及与AppFabric服务之间产生的数据交互，都需要计入带宽费用范畴。但是，同一个数据中心内的数据传输不收费。这也是为什么微软建议你尽量把应用都部署在同一个数据中心里头的缘故。

微软的数据中心可以分为主节点和CDN节点，这两种节点的带宽收费标准是不同的。

主节点的计费标准为：

亚洲数据中心 $0.30 in / $0.45 out 每GB

北美欧洲地区 $0.10 in / $0.15 out 每GB

需要注意的是，当用户第一次从CDN节点读取资源的时候，这个时候由于资源尚未缓存到该CDN节点，因此CDN节点需要从主节点获取该资源，这个数据传输也会按照上面的主节点带宽费用标准来计算。

CDN节点只会供用户下载资源，因此没有上行带宽费用。计费标准：

北美以及欧洲地区费用 $0.15 每GB

其他地区 $0.20 每GB

以上是我研究Azure计费模型的结果，写得不对的地方还请你指出。当然，这里头涉及到的具体计费标准未来肯定有所变动，但是基本的计费模型个人感觉应该已经比较完善了。更细节的计费问题以及最新的计费标准，请参考Windows Azure Platform Consumption以及Windows Azure Pricing。

——Kevin Yang

你可能对下面的文章感兴趣

• Google和微软的一大不同
• Win7/Vista高级用户必备的右键菜单Take back my Ownership!
• 十年MFC经历认识的Microsoft技术
• 微软技术社区精英计划——你也来加入吧

java.util.regex.PatternSyntaxException: Look-behind group does not have an obvious maximum length near index XX

在网上搜了好久也没找到完美的解决方案。不过，我们可以实现有限级Html嵌套标签匹配。思路相对于无限级来说就简单了好多，不需要那么多高级的特性。

示例：

<div id='container'>
    <div style='background-color:gray;' id='footer'>
        <a id='gotop' href='#' onclick='MGJS.goTop();return false;'>Top</a>
        <a id='powered' href='http://wordpress.org/'>WordPress</a>
        <div id='copyright'>
            Copyright &copy; 2009 简单生活 —— Kevin Yang的博客
         </div>
        <div id='themeinfo'>
            Theme by <a href='http://www.neoease.com/'>mg12</a>. Valid <a href='http://validator.w3.org/check?uri=referer'>XHTML 1.1</a>
            and <a href='http://jigsaw.w3.org/css-validator/'>CSS 3</a>.
        </div>
    </div>
</div>

在上面这个示例中，我们打算匹配id为footer的这个嵌套div，而且假设我们预先知道footer这个div里面最多只会嵌套一级div。更多级的情况我们一会儿再讲。

footer的开始和结束标签匹配很简单：

<div [^>]*id='footer'[^>]*>......(这里的省略号是一会要填写的)</div>

夹在开始和结束标签之间的内容无非有两种情况：

• 内容A: div标签，并且此div内无嵌套div
• 内容B: 任意其他内容

然后就是这两种内容的不断重复而已。正则表示如下：

(<div[^>]*>.*?</div>|.)*?

注意最后面的问号必须要加上，否则由于正则的贪婪匹配特性，footer的闭合标签会匹配失误。

OK了，匹配最多嵌套一级div的正则表达式如下：

<div [^>]*id='footer'[^>]*>(<div[^>]*>.*?</div>|.)*?</div>

那么如果footer标签里头最多会嵌套两级div的话怎么办呢？

其实也不难，我们只需要把上面的“内容A”部分中的点号稍作替换即可。修改如下：

<div [^>]*id='footer'[^>]*>(<div[^>]*>(<div[^>]*>.*?</div>|.)*?</div>|.)*?</div>

到这里你可能就知道，如果要匹配最多嵌套三级div的话，正则应该怎么写了：

<div [^>]*id='footer'[^>]*>(<div[^>]*>(<div[^>]*>(<div[^>]*>.*?</div>|.)*?</div>|.)*?</div>|.)*?</div>

所以实际上，只要你的html结构不是特别复杂的话，也就是说嵌套不会很深的话，那么你完全可以使用这种方式来匹配嵌套html标签。

这个正则在Java和Javascript中都可以使用，因为它没有用到任何高级特性。

——Kevin Yang

你可能对下面的文章感兴趣

• Button标签鼠标点击事件的触发源问题
• IE中使用window.open打开新窗口时无法获取Referrer对象
• Javascript 中的false,零值,null,undefined和空字符串对象
• Javascript中获取出错代码所在文件及行数
• Javascript字符串哈希函数
• Javascript操纵Cookie
• 为什么IIS7/7.5的Gzip不起作用
• 使用正则表达式匹配嵌套Html标签
• 使用正则表达式找出不包含特定字符串的条目
• 使用相对Url无缝切换HTTP-HTTPS

英文原文链接：Hilo: Windows 7 C++ Development Walkthroughs

"Hilo"由一系列文章以及示例代码组成的，它向你展示了如何释放Windows 7、Visual Studio 2010还有Visual C++的强大力量，来构建高性能，高响应的富客户端程序。Hilo提供了源代码以及编写指导，帮助你设计和开发令人瞩目的触摸式Windows应用程序。

在接下来的几周时间里，我们将会在MSDN上发布一系列文章，讲述如何设计和实现一个可以浏览、检索和处理图像照片的触摸式Windows应用程序。这些文章将会涵盖Windows 7的核心技术，描述了如何将这些技术融合到一起来创建一个非常棒的用户体验，并且也会对应用程序的设计和实现等细节做详细的阐述。你可以在这个这里找到此系列的第一篇文章。它对 Hilo做了一个概述性的介绍，并且说明了此系列中的这些文章和示例程序的所要达到的目标。

我们接下来会逐步放出Hilo的相关源代码。第一次Hilo的发布包含了一个Hilo浏览器程序的源代码。这个程序实现了一种创新的旋转木马式的导航界面。这是触摸式的，你可以使用触摸手势快速的浏览和检索。你可以在这里下载到此程序的源代码。

Hilo文章系列，包括与此相关的源代码，是用来让你快速上手一些技术的开发，并且向你展示了如何在自己的应用程序中利用到Windows核心技术的优势。

如何开始

1. 为了编译和运行Hilo浏览器程序，你需要安装Visual Studio 2010以及Visual C++。你可以在这里下载到免费的Visual C++ 2010 Express版本。

2. 安装完Visual C++ 2010 Express之后，解压缩Hilo浏览器程序的源代码，双击打开Hilo.sln解决方案文件。

3. 在编译菜单中选择重新编译整个Hilo浏览器程序。

4. 按F5在调试模式下运行此程序。

你可能对下面的文章感兴趣

• c++扫盲系列之–指针专题
• G1手机与笔记本实现Wifi互联共享上网

select * from TableA as A inner join TableB as B on A.Key1 = B.Key1

但是在Update中使用表别名可能就没那么多人知道了。

update T
set T.Key1 = 'xxxx'
from TableA T

这些天在写Sql Update脚本的时候需要引用两次同个表对象，如果直接像下面这样引用两次TableA则会抛出“The multi-part identifier ‘TableA.Index’ could not be bound”的错误。这是因为Sql引擎无法知道你在where子句中的TableA到底指的是要Update的表还是from后面的表。

update TableA
set TableA.NextKey = T.Key
from TableA T
where T.Index = TableA.Index + 1

如果不对Update后面的TableA使用别名的话，我们只能通过以下方法来实现。

update TableA
set TableA.NextKey = T.Key
from
(
  select * from TableA
)T
where T.Index = TableA.Index + 1

使用别名可以得到更简洁的写法:

update T1
set T1.NextKey = T2.Key
from TableA T1, TableA T2
whereT2.Index = T1.Index + 1

——Kevin Yang

你可能对下面的文章感兴趣

• Blend小贴士——改变鼠标滚轮的默认行为
• OneNote Tips — 混合使用中英文字体
• Sql Server中修改自增长列经常需要用到的配置
• Sql Server重命名所有外键约束
• SSIS调用存储过程失败
• Visual Studio小贴士——加了Try-Catch也能自动定位到异常代码
• 释放SQL Server占用的内存

还是得从ASCII码说起

说到字符编码，不得不说ASCII码的简史。计算机一开始发明的时候是用来解决数字计算的问题，后来人们发现，计算机还可以做更多的事，例如文本处理。但由于计算机只识“数”，因此人们必须告诉计算机哪个数字来代表哪个特定字符，例如65代表字母‘A’，66代表字母‘B’，以此类推。但是计算机之间字符-数字的对应关系必须得一致，否则就会造成同一段数字在不同计算机上显示出来的字符不一样。因此美国国家标准协会ANSI制定了一个标准，规定了常用字符的集合以及每个字符对应的编号，这就是ASCII字符集（Character Set），也称ASCII码。

当时的计算机普遍使用8比特字节作为最小的存储和处理单元，加之当时用到的字符也很少，26个大小写英文字母还有数字再加上其他常用符号，也不到100个，因此使用7个比特位就可以高效的存储和处理ASCII码，剩下最高位1比特被用作一些通讯系统的奇偶校验。

注意，字节代表系统能够处理的最小单位，不一定是8比特。只是现代计算机的事实标准就是用8比特来代表一个字节。在很多技术规格文献中，为了避免产生歧义，更倾向于使用8位组（Octet）而不是字节（Byte）这个术语来强调8个比特的二进制流。下文中为了便于理解，我会延用大家熟悉的“字节”这个概念。

ASCII字符集由95个可打印字符（0x20-0x7E）和33个控制字符（0x00-0x19，0x7F）组成。可打印字符用于显示在输出设备上，例如荧屏或者打印纸上，控制字符用于向计算机发出一些特殊指令，例如0x07会让计算机发出哔的一声，0x00通常用于指示字符串的结束，0x0D和0x0A用于指示打印机的打印针头退到行首（回车）并移到下一行（换行）。

那时候的字符编解码系统非常简单，就是简单的查表过程。例如将字符序列编码为二进制流写入存储设备，只需要在ASCII字符集中依次找到字符对应的字节，然后直接将该字节写入存储设备即可。解码二进制流的过程也是类似。

OEM字符集的衍生

当计算机开始发展起来的时候，人们逐渐发现，ASCII字符集里那可怜的128个字符已经不能再满足他们的需求了。人们就在想，一个字节能够表示的数字（编号）有256个，而ASCII字符只用到了0x00~0x7F，也就是占用了前128个，后面128个数字不用白不用，因此很多人打起了后面这128个数字的主意。可是问题在于，很多人同时有这样的想法，但是大家对于0x80-0xFF这后面的128个数字分别对应什么样的字符，却有各自的想法。这就导致了当时销往世界各地的机器上出现了大量各式各样的OEM字符集。

下面这张表是IBM-PC机推出的其中一个OEM字符集，字符集的前128个字符和ASCII字符集的基本一致（为什么说基本一致呢，是因为前32个控制字符在某些情况下会被IBM-PC机当作可打印字符解释），后面128个字符空间加入了一些欧洲国家用到的重音字符，以及一些用于画线条画的字符。

事实上，大部分OEM字符集是兼容ASCII字符集的，也就是说，大家对于0x00~0x7F这个范围的解释基本是相同的，而对于后半部分0x80~0xFF的解释却不一定相同。甚至有时候同样的字符在不同OEM字符集中对应的字节也是不同的。

不同的OEM字符集导致人们无法跨机器交流各种文档。例如职员甲发了一封简历résumés给职员乙，结果职员乙看到的却是rsums，因为é字符在职员甲机器上的OEM字符集中对应的字节是0x82，而在职员乙的机器上，由于使用的OEM字符集不同，对0x82字节解码后得到的字符却是。

多字节字符集（MBCS）和中文字符集

上面我们提到的字符集都是基于单字节编码，也就是说，一个字节翻译成一个字符。这对于拉丁语系国家来说可能没有什么问题，因为他们通过扩展第8个比特，就可以得到256个字符了，足够用了。但是对于亚洲国家来说，256个字符是远远不够用的。因此这些国家的人为了用上电脑，又要保持和ASCII字符集的兼容，就发明了多字节编码方式，相应的字符集就称为多字节字符集。例如中国使用的就是双字节字符集编码（DBCS，Double Byte Character Set）。

对于单字节字符集来说，代码页中只需要有一张码表即可，上面记录着256个数字代表的字符。程序只需要做简单的查表操作就可以完成编解码的过程。

代码页是字符集编码的具体实现，你可以把他理解为一张“字符-字节”映射表，通过查表实现“字符-字节”的翻译。下面会有更详细的描述。

而对于多字节字符集，代码页中通常会有很多码表。那么程序怎么知道该使用哪张码表去解码二进制流呢？答案是，根据第一个字节来选择不同的码表进行解析。

例如目前最常用的中文字符集GB2312，涵盖了所有简体字符以及一部分其他字符；GBK（K代表扩展的意思）则在GB2312的基础上加入了对繁体字符等其他非简体字符（GB18030字符集不是双字节字符集，我们在讲Unicode的时候会提到）。这两个字符集的字符都是使用1-2个字节来表示。Windows系统采用936代码页来实现对GBK字符集的编解码。在解析字节流的时候，如果遇到字节的最高位是0的话，那么就使用936代码页中的第1张码表进行解码，这就和单字节字符集的编解码方式一致了。

当字节的高位是1的时候，确切的说，当第一个字节位于0x81–0xFE之间时，根据第一个字节不同找到代码页中的相应的码表，例如当第一个字节是0x81，那么对应936中的下面这张码表：

（关于936代码页中完整的码表信息，参见MSDN：http://msdn.microsoft.com/en-us/library/cc194913%28v=MSDN.10%29.aspx.）

按照936代码页的码表，当程序遇到连续字节流0x81 0x40的时候，就会解码为“丂”字符。

ANSI标准、国家标准、ISO标准

不同ASCII衍生字符集的出现，让文档交流变得非常困难，因此各种组织都陆续进行了标准化流程。例如美国ANSI组织制定了ANSI标准字符编码（注意，我们现在通常说到ANSI编码，通常指的是平台的默认编码，例如英文操作系统中是ISO-8859-1，中文系统是GBK），ISO组织制定的各种ISO标准字符编码，还有各国也会制定一些国家标准字符集，例如中国的GBK，GB2312和GB18030。

操作系统在发布的时候，通常会往机器里预装这些标准的字符集还有平台专用的字符集，这样只要你的文档是使用标准字符集编写的，通用性就比较高了。例如你用GB2312字符集编写的文档，在中国大陆内的任何机器上都能正确显示。同时，我们也可以在一台机器上阅读多个国家不同语言的文档了，前提是本机必须安装该文档使用的字符集。

Unicode的出现

虽然通过使用不同字符集，我们可以在一台机器上查阅不同语言的文档，但是我们仍然无法解决一个问题：在一份文档中显示所有字符。为了解决这个问题，我们需要一个全人类达成共识的巨大的字符集，这就是Unicode字符集。

Unicode字符集概述

Unicode字符集涵盖了目前人类使用的所有字符，并为每个字符进行统一编号，分配唯一的字符码（Code Point）。Unicode字符集将所有字符按照使用上的频繁度划分为17个层面（Plane），每个层面上有2¹⁶=65536个字符码空间。

其中第0个层面BMP，基本涵盖了当今世界用到的所有字符。其他的层面要么是用来表示一些远古时期的文字，要么是留作扩展。我们平常用到的Unicode字符，一般都是位于BMP层面上的。目前Unicode字符集中尚有大量字符空间未使用。

编码系统的变化

在Unicode出现之前，所有的字符集都是和具体编码方案绑定在一起的，都是直接将字符和最终字节流绑定死了，例如ASCII编码系统规定使用7比特来编码ASCII字符集；GB2312以及GBK字符集，限定了使用最多2个字节来编码所有字符，并且规定了字节序。这样的编码系统通常用简单的查表，也就是通过代码页就可以直接将字符映射为存储设备上的字节流了。例如下面这个例子：

这种方式的缺点在于，字符和字节流之间耦合得太紧密了，从而限定了字符集的扩展能力。假设以后火星人入住地球了，要往现有字符集中加入火星文就变得很难甚至不可能了，而且很容易破坏现有的编码规则。

因此Unicode在设计上考虑到了这一点，将字符集和字符编码方案分离开。

也就是说，虽然每个字符在Unicode字符集中都能找到唯一确定的编号（字符码，又称Unicode码），但是决定最终字节流的却是具体的字符编码。例如同样是对Unicode字符“A”进行编码，UTF-8字符编码得到的字节流是0x41，而UTF-16（大端模式）得到的是0x00 0x41。

常见的Unicode编码

UCS-2/UTF-16

如果要我们来实现Unicode字符集中BMP字符的编码方案，我们会怎么实现？由于BMP层面上有2¹⁶=65536个字符码，因此我们只需要两个字节就可以完全表示这所有的字符了。

举个例子，“中”的Unicode字符码是0x4E2D(01001110 00101101)，那么我们可以编码为01001110 00101101（大端）或者00101101 01001110 （小端）。

UCS-2和UTF-16对于BMP层面的字符均是使用2个字节来表示，并且编码得到的结果完全一致。不同之处在于，UCS-2最初设计的时候只考虑到BMP字符，因此使用固定2个字节长度，也就是说，他无法表示Unicode其他层面上的字符，而UTF-16为了解除这个限制，支持Unicode全字符集的编解码，采用了变长编码，最少使用2个字节，如果要编码BMP以外的字符，则需要4个字节结对，这里就不讨论那么远，有兴趣可以参考维基百科：UTF-16/UCS-2。

Windows从NT时代开始就采用了UTF-16编码，很多流行的编程平台，例如.Net，Java，Qt还有Mac下的Cocoa等都是使用UTF-16作为基础的字符编码。例如代码中的字符串，在内存中相应的字节流就是用UTF-16编码过的。

UTF-8

UTF-8应该是目前应用最广泛的一种Unicode编码方案。由于UCS-2/UTF-16对于ASCII字符使用两个字节进行编码，存储和处理效率相对低下，并且由于ASCII字符经过UTF-16编码后得到的两个字节，高字节始终是0x00，很多C语言的函数都将此字节视为字符串末尾从而导致无法正确解析文本。因此一开始推出的时候遭到很多西方国家的抵触，大大影响了Unicode的推行。后来聪明的人们发明了UTF-8编码，解决了这个问题。

UTF-8编码方案采用1-4个字节来编码字符，方法其实也非常简单。

（上图中的x代表Unicode码的低8位，y代表高8位）

对于ASCII字符的编码使用单字节，和ASCII编码一摸一样，这样所有原先使用ASCII编解码的文档就可以直接转到UTF-8编码了。对于其他字符，则使用2-4个字节来表示，其中，首字节前置1的数目代表正确解析所需要的字节数，剩余字节的高2位始终是10。例如首字节是1110yyyy，前置有3个1，说明正确解析总共需要3个字节，需要和后面2个以10开头的字节结合才能正确解析得到字符。

关于UTF-8的更多信息，参考维基百科：UTF-8。

GB18030

任何能够将Unicode字符映射为字节流的编码都属于Unicode编码。中国的GB18030编码，覆盖了Unicode所有的字符，因此也算是一种Unicode编码。只不过他的编码方式并不像UTF-8或者UTF-16一样，将Unicode字符的编号通过一定的规则进行转换，而只能通过查表的手段进行编码。

关于GB18030的更多信息，参考：GB18030。

Unicode相关的常见问题

Unicode是两个字节吗？

Unicode只是定义了一个庞大的、全球通用的字符集，并为每个字符规定了唯一确定的编号，具体存储为什么样的字节流，取决于字符编码方案。推荐的Unicode编码是UTF-16和UTF-8。

带签名的UTF-8指的是什么意思？

带签名指的是字节流以BOM标记开始。很多软件会“智能”的探测当前字节流使用的字符编码，这种探测过程出于效率考虑，通常会提取字节流前面若干个字节，看看是否符合某些常见字符编码的编码规则。由于UTF-8和ASCII编码对于纯英文的编码是一样的，无法区分开来，因此通过在字节流最前面添加BOM标记可以告诉软件，当前使用的是Unicode编码，判别成功率就十分准确了。但是需要注意，不是所有软件或者程序都能正确处理BOM标记，例如PHP就不会检测BOM标记，直接把它当普通字节流解析了。因此如果你的PHP文件是采用带BOM标记的UTF-8进行编码的，那么有可能会出现问题。

Unicode编码和以前的字符集编码有什么区别？

早期字符编码、字符集和代码页等概念都是表达同一个意思。例如GB2312字符集、GB2312编码，936代码页，实际上说的是同个东西。但是对于Unicode则不同，Unicode字符集只是定义了字符的集合和唯一编号，Unicode编码，则是对UTF-8、UCS-2/UTF-16等具体编码方案的统称而已，并不是具体的编码方案。所以当需要用到字符编码的时候，你可以写gb2312，codepage936，utf-8，utf-16，但请不要写unicode（看过别人在网页的meta标签里头写charset=unicode，有感而发）。

乱码问题

乱码指的是程序显示出来的字符文本无法用任何语言去解读。一般情况下会包含大量或者?。乱码问题是所有计算机用户或多或少会遇到的问题。造成乱码的原因就是因为使用了错误的字符编码去解码字节流，因此当我们在思考任何跟文本显示有关的问题时，请时刻保持清醒：当前使用的字符编码是什么。只有这样，我们才能正确分析和处理乱码问题。

例如最常见的网页乱码问题。如果你是网站技术人员，遇到这样的问题，需要检查以下原因：

• 服务器返回的响应头Content-Type没有指明字符编码
• 网页内是否使用META HTTP-EQUIV标签指定了字符编码
• 网页文件本身存储时使用的字符编码和网页声明的字符编码是否一致

注意，网页解析的过程如果使用的字符编码不正确，还可能会导致脚本或者样式表出错。具体细节可以参考我以前写过的文章：文档字符集导致的脚本错误和Asp.Net页面的编码问题。

不久前看到某技术论坛有人反馈，WinForm程序使用Clipboard类的GetData方法去访问剪切板中的HTML内容时会出现乱码的问题，我估计也是由于WinForm在获取HTML文本的时候没有用对正确的字符编码导致的。Windows剪贴板只支持UTF-8编码，也就是说你传入的文本都会被UTF-8编解码。这样一来，只要两个程序都是调用Windows剪切板API编程的话，那么复制粘贴的过程中不会出现乱码。除非一方在获取到剪贴板数据之后使用了错误的字符编码进行解码，才会得到乱码（我做了简单的WinForm剪切板编程实验，发现GetData使用的是系统默认编码，而不是UTF-8编码）。

关于乱码中出现?或者?，这里需要额外提一下，当程序使用特定字符编码解析字节流的时候，一旦遇到无法解析的字节流时，就会用或者?来替代。因此，一旦你最终解析得到的文本包含这样的字符，而你又无法得到原始字节流的时候，说明正确的信息已经彻底丢失了，尝试任何字符编码都无法从这样的字符文本中还原出正确的信息来。

必要的术语解释

字符集（Character Set），字面上的理解就是字符的集合，例如ASCII字符集，定义了128个字符；GB2312定义了7445个字符。而计算机系统中提到的字符集准确来说，指的是已编号的字符的有序集合（不一定是连续）。

字符码（Code Point）指的就是字符集中每个字符的数字编号。例如ASCII字符集用0-127这连续的128个数字分别表示128个字符；GBK字符集使用区位码的方式为每个字符编号，首先定义一个94X94的矩阵，行称为“区”，列称为“位”，然后将所有国标汉字放入矩阵当中，这样每个汉字就可以用唯一的“区位”码来标识了。例如“中”字被放到54区第48位，因此字符码就是5448。而Unicode中将字符集按照一定的类别划分到0~16这17个层面（Planes）中，每个层面中拥有2¹⁶=65536个字符码，因此Unicode总共拥有的字符码，也即是Unicode的字符空间总共有17*65536=1114112。

编码的过程是将字符转换成字节流。

解码的过程是将字节流解析为字符。

字符编码（Character Encoding）是将字符集中的字符码映射为字节流的一种具体实现方案。例如ASCII字符编码规定使用单字节中低位的7个比特去编码所有的字符。例如‘A’的编号是65，用单字节表示就是0x41，因此写入存储设备的时候就是b’01000001’。GBK编码则是将区位码（GBK的字符码）中的区码和位码的分别加上0xA0（160）的偏移（之所以要加上这样的偏移，主要是为了和ASCII码兼容），例如刚刚提到的“中”字，区位码是5448，十六进制是0x3630，区码和位码分别加上0xA0的偏移之后就得到0xD6D0，这就是“中”字的GBK编码结果。

代码页（Code Page）一种字符编码具体形式。早期字符相对少，因此通常会使用类似表格的形式将字符直接映射为字节流，然后通过查表的方式来实现字符的编解码。现代操作系统沿用了这种方式。例如Windows使用936代码页、Mac系统使用EUC-CN代码页实现GBK字符集的编码，名字虽然不一样，但对于同一汉字的编码肯定是一样的。

大小端的说法源自《格列佛游记》。我们知道，鸡蛋通常一端大一端小，小人国的人们对于剥蛋壳时应从哪一端开始剥起有着不一样的看法。同样，计算机界对于传输多字节字（由多个字节来共同表示一个数据类型）时，是先传高位字节（大端）还是先传低位字节（小端）也有着不一样的看法，这就是计算机里头大小端模式的由来了。无论是写文件还是网络传输，实际上都是往流设备进行写操作的过程，而且这个写操作是从流的低地址向高地址开始写（这很符合人的习惯），对于多字节字来说，如果先写入高位字节，则称作大端模式。反之则称作小端模式。也就是说，大端模式下，字节序和流设备的地址顺序是相反的，而小端模式则是相同的。一般网络协议都采用大端模式进行传输，windows操作系统采用Utf-16小端模式。

——Kevin Yang

参考链接：

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• http://developers.sun.com/dev/gadc/technicalpublications/articles/gb18030.html
• http://en.wikipedia.org/wiki/Universal_Character_Set
• http://en.wikipedia.org/wiki/Code_page

你可能对下面的文章感兴趣

• Asp.Net页面的编码问题
• Excel中使用VBA自定义函数对字符串进行Url编码（UTF-8）
• PHP处理BOM标记的UTF-8文件导致的问题
• 字符编解码的故事（ASCII，ANSI，Unicode，Utf-8区别）
• 字符，字节和编码
• 文档字符集导致的脚本错误
• 解决Xaml中包含中文导致无法编译的问题
• 详解Javascript中的Url编码/解码

我曾经在整理电脑上的文件的时候，想删除某个软件的安装目录，但是却弹出一个窗口，提示我“此操作需要提供管理员权限”。但是窗口上只有一个“重试”和“取消”的按钮，你点重试吧，他会提示你一样的问题，最后你还是不得不点取消。没有一个地方可以允许你已管理员的身份去执行这个删除的操作（对于exe程序，win7倒是提供了一个以管理员身份运行的右键菜单）。对于windows下有经验的用户，一般会尝试打开文件夹的属性，切换到“安全”选项卡，然后添加自己的权限。然后再去删。有时候可以成功，但有时候我却遇到了另外一个错误。“当前操作需要Kevin的权限才能进行”（我当前使用的用户名就是Kevin）。吐血身亡…..

Google了一把，说是ownership（所有权）导致的问题，只要把文件/文件夹的所有权改成自己就没问题了。具体为什么我也懒得去研究了，这种弱智的问题研究透了也只能说明自己也是一个弱智。网上有人提供了一个注册表脚本，可以在右键集成一个“Take ownership”的菜单，这样当遇到类似的权限问题就直接要回所有权就行了。

新建一个install.reg的文件，用记事本打开，然后将下面的内容拷贝到文件中，然后双击导入注册表即可。

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\runas]
@="Take Ownership"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\*\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"

[HKEY_CLASSES_ROOT\Directory\shell\runas]
@="Take Ownership"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"

 

实际效果如下图所示：

参考链接：

http://www.howtogeek.com/howto/windows-vista/add-take-ownership-to-explorer-right-click-menu-in-vista/

——Kevin Yang

你可能对下面的文章感兴趣

• Google和微软的一大不同
• VS2010的UI设计失误
• Win7管理无线网络变成小图标了
• Win7访问远程桌面最大化同时让任务栏可见
• 十年MFC经历认识的Microsoft技术
• 微软Azure平台的计费模型
• 微软技术社区精英计划——你也来加入吧
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题
• 解决Win7下IE8开发人员工具打不开的问题
• 解决新创建的windows用户无法访问TFS的问题

之前看Google IO大会上对Wave铺天盖地的介绍，觉得Google这次推的概念确实很不错。

如果电子邮件不是在30年前发明的，而是今天发明的，那么它应该就是Wave现在这个样子。

传统电子邮件的局限

当你使用电子邮件的时候，你每发送一封邮件，邮件在你这边存了一份，然后在别人那边也存了一份，邮件与邮件之间是非常独立的。如果你要知道别人回复邮件的上下文，你需要在收件箱里面查找以前的邮件，当然，现在几乎所有的邮件客户端都会在你回复的时候把收到的邮件拷贝一份附加到正文末尾，然后发给对方，这样别人就可以在一封邮件中找到上下文了，代价就是，邮件会越来越庞大。

当邮件交流比较少的时候，这不是什么大问题。但是当邮件比较多的时候，你就很容易迷失在收件箱或者杂乱的邮件内容中。后来Gmail创新性的推出了“邮件会话”的概念，它把同一个主题的邮件组合到了一起，这样当你隔了好几天收到别人邮件的时候，你就可以在同一个界面中看到邮件主题讨论的全部过程了。

但是假设后面有个人C加入了A和B这个会话主题，那么他就无法知道A和B之前讨论过什么样的内容，除非A或者B把之前的邮件内容都发送给C。这是非常麻烦的。

画布式的交流取代扔球式的交流

本来想取个中规中矩的标题，但后来想还是上面这个标题形象点。

传统的电子邮件交流方式就好像两个人玩扔球一样，两个人把要说的话写到球上，然后扔给对方，对方只有等到你把球扔过来才能知道你要说什么，如果要附带一些其他的东西的话，还得绑到球上扔过去，一旦过重还没法扔呢（现在的邮件要带上个3M的附件就很难发送了）。

而Wave提倡的方式是画布式的交流方式，当你想讨论一个主题的时候，你就好比放一块画布在那，然后所有你希望加入这个主题的人都可以直接在上面“画”任何东西。这就意味着，如果有个人后来才加入你这个主题的，那么他依然可以看到整个主题的全貌。

但是这里有个问题，假设有几个人合作在画布上画了蒙娜丽莎，哇，令人叹为观止，虽然后面加入的人可以看到整幅蒙娜丽莎的画像，但是他无法知道别人都是怎么开始画的。

会话回放

Wave借用了视频回放的概念，引入了“主题回放”（Playback）的功能，你可以在上面重新回放别人整个交流过程，就好像看视频重播一样。你可以看到一开始XXX挖了个坑，然后YYY非常挑衅的发表了什么高论，然后被ZZZ等人狂批了一顿，后来YYY自觉羞辱，就把之前发表的高论删了。。。。所以尽管你是后来的，但是你依然不会落下会话的每个细节。

Wave的画布可以“画”什么？

Wave可以做什么？

你可以把他当作一个即时交流工具或者早期的聊天室。在上面搜索你感兴趣的话题，然后加入。你也可以把他当作论坛、BBS来用。你甚至可以把他当作一个协作平台，在上面进行多人创作。

Web2.0是一个富媒体的时代，传统电子邮件的方式一般只能做文本交流，高级一点你可以在上面加些图片。但Wave希望未来的交流可不是这么枯燥。他希望你可以在上面以更多的方式进行交流，他希望把现在互联网上很多丰富的元素无缝的整合到Wave中来。

例如你和你朋友讨论到了一首歌，你可以从把这首歌放到Wave上面，这样两个人都可以在上面直接听到这首歌的播放，或者拖个视频进来，直接在上面看视频。

又例如，当你们讨论到一个话题无法得出结论的时候，你们可以在上面创建一个投票，这个投票可不是纯人肉统计的那种投票，而是在上面创建一个非常直观的投票器。

又例如，你朋友问你XXX地方在哪，地图那么大，不好找，这个时候你怎么告诉他具体在地图上的哪个位置呢？在以前，你可能会先告诉他是哪个省哪个市的，最多你会截个图发给他。在wave上呢，你可以拖一个Google地图进来，然后在上面进行缩放导航，找到XXX这个地方之后在上面画个圈圈。注意，你的朋友可不是只看到最终的结果，他能看到你操作的整个过程！有趣吧~

下面这段视频挺有意思的：Google Wave的强大应用

跨语言的交流

由于Wave是一个开放的系统，大家都可以在上面开发各种各样的小插件。IO大会上演示了一个非常有意思的即时翻译插件。这个插件在Wave上看上去像一个普通的联系人，当你把这个“人”加入到你的会话中，它就可以帮助不同语言的人在交流的时候，自动将对方的语言转换成自己的母语。

先不管这个翻译质量如何，这个创意确实让人感到非常兴奋！

Wave的画布有多大？

你可能在想，我创建了一块“画布”（主题），别人怎么共享我的这块画布呢？当然，如果全世界都只用Google的产品那事情就简单很多了。可实际情况是，网络中已经有太多交流协作的系统了，你无法让所有用户都改变他们的习惯，转移到Wave上来。因此Google设想的是把这块画布延伸到互联网各个角落，各个系统上。也就是说，你可以在Wave上创建一个主题（主题？画布？我想说的是一个意思）， 然后把这个主题实时更新到你的博客上，你的twitter上，你的iphone上，等等。Google Wave是一个开放的系统架构，不同人搭建起来的Wave系统可以互相通讯。就好像不同的邮件服务器之间可以互相通讯一样。所以你如果问Google Wave提供的画布有多大，这个问题还真不好回答~

Preview版本的试用体验

Wave现在还只是测试版本，试用了一段时间之后发现和我的期望并不是很相近。

整体的用户体验

从UI上来说，感觉Wave不是那么容易上手，像我这样的IT前沿分子（别喷我~）如果不看别人的教程，基本摸不着边。虽然在Google Wave上可以放置各种富媒体元素，但是不好好看教程，根本不知道怎么在上面放一个视频，怎么在上面放一个google map。连最基本的设置个人信息我都找了半天。

Web应用应该以直观、简单为导向，就好像一本UI书的书名一样“Dont make me think”， 感觉Wave却是完全反着来做了。

目前的界面响应性能还是很糟糕的，在Chrome上经常用一会就很卡了。

实时更新

在Wave上，你输入的东西是会实时更新到其他地方的，例如你的Wave连着你的博客，或者有人正在搜索你创建的Wave主题，当你在Wave中输入一些信息的时候，这些信息会实时更新到你的博客上，别人的搜索结果上。

如果两个人在同一个Wave上，你可以看到别人敲字的过程，非常好玩。但这也仅仅是非常好玩而已。我相信不是很多中文用户会喜欢这个功能。因为中文输入法经常会根据你输入的词进行智能联想，如果你不小心打错了什么字母结果出来另外一个“有损形象”的词的话，那后果。。。我就不说了，呵呵

版本控制非常糟糕

Wave允许你自由编辑别人敲的内容，这很容易导致别人不小心弄乱你编写的内容。虽然Wave声称可以回放整个会话过程，并给其中的某一时刻起一个版本之类的，但是我并没有在界面上找到任何关于编辑权限控制的地方，除了那个Private Reply之外。

会话顺序很混乱

在一个wave中（一个wave就是一个主题，就是我说的一块“画布”），你可以自由的对某一条信息进行回复，回复的信息是直接嵌入到那一条信息之下的，而不是整个会话的最底部。这个设计对于浏览整个会话来说倒是很直观的，但是如果两个人在即时交流，你回复这条内容，我又回复你那条内容，很容易乱套了，除非用回放的功能，否则你无法实时知道别人最后说的什么。

以上就是我试用了一个月的一个粗糙的体验，可能有些地方理解得不对，有用过Wave的人互相交流一下吧。

——Kevin Yang

你可能对下面的文章感兴趣

• 4行Greasemonkey代码最大化Google Reader的阅读空间
• Android手机初体验
• G1手机与笔记本实现Wifi互联共享上网
• Google Analytics中的UniquePageView和Visits的区别
• Google和微软的一大不同
• Google工程师Matt Cutts谈SEO
• Google排名更新
• Google的价值观
• 使用FeedBurner烧制RSS最好禁用ItemLinkClicks统计
• 内牛满面，终于有PR值了~

(BaseClass)obj

obj as BaseClass

同时，Convert类也提供了很多常用类型的转换接口。

我接下来要说的是第一种转换形式。

当使用第一种转换形式的时候，要求obj是null，或者是一个BaseClass类或其派生类实例。否则转换会抛出异常（使用后一种形式则返回null）。这倒好理解，但是对于简单类型，就比较容易出错了。

object obj = 2;
double i = (double)obj;

上面的代码会抛出一个InvalidCastException，这是因为使用前一种类型转换的时候，CLR运行时会进行类型匹配，因为obj的类型（int）和double不相匹配——虽然看起来是无损精度的转换——因此抛出异常。从这个例子中我们可以得到一个结论：

除非你非常确定你要转换的源对象是什么类型，否则千万使用第一种形式，特别是对于简单类型更是如此。

对于简单类型，建议采用Convert.ToXXX接口实现转换，可维护性高一些。

——Kevin Yang

你可能对下面的文章感兴趣

• C#中Readonly和const的区别
• 随机字符串生成函数

const和readonly这两个关键字都是用来表示常量，只不过标记为Readonly的变量可以在构造函数中动态赋值，const需要在变量声明的时候就初始化；如果将这两种常量放到单独的动态链接库中，然后编译整个项目，则应用程序对于readonly变量，是每次都从动态链接库中读取最新的常量值，而对于const变量是在编译的时候就写死到应用程序代码中了（我不知道这是不是编译器优化行为，反正我在VS2008下无论是Debug版本还是Release版本均是这样的行为）。

后面一点很重要，举一个简单的例子。我新建了两个工程，一个应用程序，一个是类库。

其中ClassLibrary1中定义了StaticResources类

public class StaticResources
{
    public const int ConstVar = 1000;
    public static readonly int ReadonlyVar = 1000;
}

在ConsoleApplication5中代码如下：

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Const Variable is {0}", StaticResources.ConstVar);
        Console.WriteLine("Readonly Variable is {0}", StaticResources.ReadonlyVar);
    }
}

输出都是1000没有问题。

当写类库的人突然因为种种原因需要更新ConstVar和ReadonlyVar这两个常量，假设更新为2000。更新完之后，他觉得主应用程序没有做修改，就没有更新，只发布了最新的dll。结果呢，ReadonlyVar更新了，ConstVar没有更新。

对于Asp.net网站应用程序就更容易出现这样的问题了。一般我们引用的动态链接库都是放在网站下的bin目录。因为更新网站相对比较麻烦，所以有时候我们会偷懒，只更新动态链接库，这个时候就很容易出现上述的问题了。

鉴于此，一般我在定义常量的时候比较偏向于使用static readonly组合关键字。虽然有稍许的性能缺失，但是带来的更好的可维护性。

——Kevin Yang

你可能对下面的文章感兴趣

• 慎用类型强制转换
• 随机字符串生成函数

• 使用静态引用
• 未退订的事件－作者认为这是最常见的内存泄漏原因
• 未退订的静态事件
• 未调用Dispose方法
• 使用不彻底的Dispose方法
• 在Windows Forms中对BindingSource的误用
• 未在WorkItem/CAB上调用Remove

当时对于第二点，“未退订事件”引起的内存泄露不是很理解。后来仔细分析了一下，又参考了MSDN上关于事件和委托的解释，终于意识到了自己以前没有注意的一个问题。

假设，类A提供了一个事件，类B和类C均订阅了该事件。如果类B和类C的实例不再使用了，而又没有显式退订此事件，那么类B和类C的实例将不会被GC回收，直至类A实例被销毁为止。

下面的代码说明了这种情况：

public class Container
{
	private List<Containee> _controls = new List<Containee>();

	public List<Containee> Controls
	{
		get { return _controls; }
		set { _controls = value; }
	}
	private String _currentState;

	public event EventHandler StateChanged;

	public String CurrentState
	{
		get
		{
			return _currentState;
		}
		set
		{
			if (value != _currentState)
			{
				_currentState = value;
				if (StateChanged != null)
				{
					StateChanged(this, null);
				}
			}
		}
	}

	public void ClearControls()
	{
		_controls.Clear();
	}
}

public class Containee
{
	private String _name;
	private Container _container;
	public Containee(String controlName, Container container)
	{
		_name = controlName;
		_container = container;
		_container.Controls.Add(this);
		container.StateChanged += OnStateChanged;
	}

	public void OnStateChanged(object sender, EventArgs e)
	{
		Container container = sender as Container;
		if (container != null)
		{
			// Do something....
			Console.WriteLine("{0}: State change, current state is {1}.", _name, container.CurrentState);
		}
	}
}
class Program
{
	static void Main(string[] args)
	{
		Container container = new Container();
		new Containee("Control 1", container);
		new Containee("Control 2", container);
		new Containee("Control 3", container);
		container.CurrentState = "State1";

		Console.WriteLine("================================================");
		// 清除所有子控件
		container.ClearControls();
		// 添加新控件进来
		new Containee("Control 4", container);
		new Containee("Control 5", container);
		new Containee("Control 6", container);
		container.CurrentState = "State2";
	}
}

运行结果：

如上述结果看到的，尽管旧控件已经被clear掉了，但是它们仍在起作用。

当我们在后面代码中将container容器上的控件清除掉的时候，我们会习惯性的以为这些控件已经不再被引用了，资源会被自动回收掉。而设计Containee的人可能在写事件订阅的时候也不会想起背后的逻辑，习以为常的觉得，只要在代码里找到该Containee实例都被“=”给了谁，然后把它的引用置为null就行了。殊不知，C#的event-delegate模型下，当一个类实例订阅了一个事件的时候，此实例已经被隐式的传给了“事件”了（CLR的事件模型是建立在委托System.Delegate之上的，事件可以看成是一个委托类）。因此，只要Container不销毁，事件也就不销毁，Containee的实例就不会被回收，除非Containee退订了该事件。

自己在写事件处理的时候根本没有考虑过这样的问题，不知道以前写过的代码会不会也存在这样的问题。不管怎么，以后得注意一些了。

——Kevin Yang

你可能对下面的文章感兴趣

• 释放SQL Server占用的内存