易栈网-膘叔

也许大家已经看惯了书上说的GBK是对GB2312的扩充，就是说，GB2312字符集中的所有字符都可以在GBK 字符集中找到。(by gashero)可是最近在一次调试Python爬虫的过程中就发现了一些字符的不同。同时大家也应该注意一些网页的默认编码字符集了。

当时正在分析的一个网页的默认编码字符集是GB2312，其中含有一个符号"·"，这个常作为项目符号。在使用 GB2312进行解码时，得到的unicode字符是\u30fb，然后使用系统默认编码GBK进行打印时就提示了编码错误。即字符串"\xa1 \xa4"无法使用GB2312解码为unicode字符后再编码为GBK编码显示。(by gashero)实际测试中只要不会交换编码，那么使用同一种编码进行编码和解码就不会出问题。

后来查找得知，字符\u30fb是一种特殊的unicode字符，是一种不允许显示的字符，所以在GBK编码中就没有它的位置(by gashero)。而字符串"\xa1\xa4"使用GBK解码时得到的是\u00b7。

至此得知，虽然网页的默认编码是GB2312，但是实际上使用的是GBK编码，也使用了一些在GB2312和GBK之间不同的编码字符。所以也就导致了这个错误。

建议以后编程序的时候，遇到默认编码为GB2312的大可以直接使用GBK进行解码为unicode字符串。

明白了，我把所有有关字符集设置的地方都换成:GBK.这时通过FF的FireBug看到的请求参数正常了.问题解决了.

2.都有哪些地方要设置字符集呢?为什么要统一呢?

[原文中作者在此是引用他在csdn中的文字，我将他复制回来了，最后几段代码可看性不强，所以没有贴。。。http://blog.csdn.net/xiaofanku/archive/2008/06/25/2584856.aspx]

最近在学php,由于项目的需要！想在php中用ajax来完成一些体验(减少业务处理的单页压力).发现最近也有一位朋友为此苦恼不已.不废话了！
1.注意几个编码地方
1.1表单所在的网页的:meta
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

1.2XMLHTTPRequest GET的编码
httpRequest.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8");
此处设置不对!responseText会返回empty(没有内容),如果您有FireFox并装有FireBug组件的话,点击状态栏的绿色箭头打开控件面板(非OS的,FireBug的),选中Console会看到Response选项是:
Illegal mix of collations (gbk_chinese_ci,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '=
当然如果是连接数据库的话也可能跟下面的(1.4)有关系.

1.3ajax GET请求的页面(.php)header
header("Content-Type:text/html;charset=UTF-8");

1.4数据连接的编码
mysql_query("SET CHARACTER SET UTF8");

如果你的数据库是GBK的或其它的字符集,为了统一编码还要与以上三个统一起来.下面我的示例用的数据库也是GBK,从昨天开始我一起把它设成:
mysql_query("SET CHARACTER SET GBK");
可还是有时发现会返回空(empty 我用的是ResponseText),千万不要写成UTF-8噢,数据库的字符集是没有中间的"-"

2.如果还是返回空或无效的值

例如:a.html中有表单,a用XMLHTTPRequest和b.php通讯.
首先要保证b.php可以正确运行,例b.php?param=value打印出来的是你期望的值
如果a.html打印b.php返回的结果(ajax)与上面的(单独运行b.php)执行结果有出入.可以删除b.php中的空行试试!我想应该不会出现这种情况,但我有几次作demo删除后和删除前确实有出入

设计模式只是为 Java™ 架构师准备的 —— 至少您可能一直这样认为。实际上，设计模式对于每个人都非常有用。如果这些工具不是 “架构太空人” 的专利，那么它们又是什么？为什么说它们在 PHP 应用程序中非常有用？本文解释了这些问题。

设计模式 一书将设计模式引入软件社区，该书的作者是 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides Design（俗称 “四人帮”）。所介绍的设计模式背后的核心概念非常简单。经过多年的软件开发实践，Gamma 等人发现了某些具有固定设计的模式，就像建筑师设计房子和建筑物一样，可以为浴室的位置或厨房的构造方式开发模板。使用这些模板或者说设计模式 意味着可以更快地设计更好的建筑物。同样的概念也适用于软件。

设计模式不仅代表着更快开发健壮软件的有用方法，而且还提供了以友好的术语封装大型理念的方法。例如，您可以说您正在编写一个提供松散耦合的消息传递系统，也可以说你正在编写名称为观察者 的模式。

用较小的示例展示模式的价值是非常困难的。这往往有些大材小用的意味，因为模式实际上是在大型代码库中发挥作用的。本文不展示大型应用程序，所以您 需要思索的是在您自己的大型应用程序中应用示例原理的方法 —— 而不是本文演示的代码本身。这不是说您不应该在小应用程序中使用模式。很多良好的应用程序都以小应用程序为起点，逐渐发展到大型应用程序，所以没有理由不 以此类扎实的编码实践为基础。

既然您已经了解了设计模式以及它们的有用之处，现在我们来看看 PHP V5 的五种常用模式。

 

出于版权问题，我不能继续往下贴。不过原文也很方便的可以被访问到。

原文：http://www.ibm.com/developerworks/opensource/library/os-php-designptrns/index.html
原文译文：http://www.ibm.com/developerworks/cn/opensource/os-php-designptrns/index.html

 

wubi...这个wubi不是传统意义上的五笔哦。
wubi是一个小软件，可以让你在windows下面安装ubuntu而不需要改分区表等信息，说白了就象一个dos启动+liveCD那样的应用，只是内容可以被更改而己。
关于wubi，我就不详细说了。可以到wubu-installer.org上面找个仔细。

我说说我的使用过程吧。
我在笔记本上装的时候，很痛苦，因为，我是intel core duo的芯片，默认就帮我下载了amd64（经朋友指点，amd64不是说为amd64位芯片用的，而是说是64位的版本），结果很多软件装不上，因为那些都是for i386的。确实有点郁闷。可是好象在安装的时候并不能选择。。。（我也没有看到有ini文件配置啥的，这点让人很不舒服，不知道amd64X2的芯片会下载哪个，装了这个版本，qq for linux就不能使用deb包的，而只能使用tar.gz的版本[这个版本，居然不支持打中文？？？或许是我太笨]）
凄凉的事情，咱不多讲。
讲点在单位机器上折腾的事情吧。

单位的机器用的是DELL，显卡是nvidia的，安装完，第一次启动后进行部分设置后会自动重启，然后才算是开启了ubuntu之旅。
建议步骤：
1、进系统后，先更改网络设置，改成能上网先
2、使用新立得软件安装器，先更新所有补丁
3、直接到system菜单找到language support，把环境改成汉语
4、下载好所有的语言包后，再找到 软件的添加删除 ，找到scim，看看有没有选项可以配置，默认的scim在没有装汉语语言时，是没有中文输入法的。
5、由于我的机器是nvidia显卡，初进去时没认出来，需要到hardware test里找到它，打上勾，会自动安装驱动，装完会提示你重启
6、常用的都更新完后，建议安装wine或者通过fushiion安装虚拟机，毕竟大多数情况下，我们还是会用到windows程序。
7、普通的配置没有什么好讲的，firefox还是照常使用，不过好象多了一些插件。伤心的是alipay不支持linux下的firefox，还是慢慢等吧。
8、安装wubi会在启动的时候多一个菜单，所以如果想一启用就进入ubuntu，可以考虑改菜单跳转时间
9、如果觉得ubuntu好用，可以看我博客上的另外一篇文章：把wubi版的改为正式版的

废话不多说了。。开启你们的ubuntu之旅吧

字符串，恐怕应该算是MYSQL里面最复杂的类型了吧？几乎目前所有的问题，都是出在与字符有关的数据列上，大致有几种
1、字符串的查询（以下如果不特指，都是指中文），搜索一个中文的时候，不管是模糊还是精确，往往结果都会有与搜索内容不一致的数据在里面
2、编码，现在大家都知道MYSQL连接上后，先执行一下mysql_query('set names GBK',$conn)这类的语句，从MYSQL4.0升级到4.1及以上版本的朋友在这上面吃的苦不少了。网上关于这类的提问也是最多的
3、索引、效率，varchar是MYSQL所特有的字段，而且长度可变，char则是固定长度的字符串。
在MYSQL所支持的几个字符串格式里面，char和varchar是用的最多的，char是定长字段，，也就是说，不管字符串的实际长度有多少，CHAR(10)将永远占用10个字节。字符串如果前端有空格，那么在存储的时候会自动被数据库去掉，相当于先执行trim($string)，再进行存储，如果不满10个字节，将会采用空格填满，读取数据时，MYSQL会自动将这些空格去掉。看到这里，恐怕它的缺点之一就明显的暴露了，CHAR不能存储那些结尾确实有空格的字符串（因为读取时会被MYSQL自动去掉）。

数据类型	含义
char(n)	固定长度的字符串，最多255个字符
varchar(n)	可变长度字符串，最多255个字符（MYSQL<5.0.3,n<=255 , mysql>=5.0.3,n<=65535）
tinytext	可变长度字符串，最多255
text	可变长度字符串，最多65535-1
medinumtext	可变长度字符串，最多16,777,216-1
longtext	可变长度字符串，最多4,294,967,296-1

除了char类型外，其余类型均为可变长度，实际所占空间由该字段所存的内容决定。虽然varchar与tinytext一样都是255个字节，但不同的是varchar可以指定存储的长度，而tinytext只能由存储的时候数据长度而定。
在数据表被创建的时候，MYSQL 把数据列的定义改成一种对MYSQL来说更有效率的形式。这种自动方式的修改称为默许的数据列修改（client column changes）。一般来说是对CHAR和VARCHAR数据列都有影响：如果n<4，varchar(n)将被修改为char(n),而如果n>3并且在同一个数据表里还有其他的可变长度的字段，char将被修改成varchar格式。如果数据表里只有固定长度的数据列，char列将不发生变化。也就是说，你在数据表里的字段如果有多种格式，那么你通过alter table 是无法进行修改的。
上表提到，varchar在新版本里变成了65535个字节，但最大字符个数还是要取决于具体的字符集（GBK中文占两个字节，而UTF8中文则占三个字节）。上面这些所有的数据类型都有一个BINARY属性，一旦该字段添加了这个属性，那么MYSQL就会将他们视同BLOB字段来处理。BINARY的好处是在排序时把字符视为二进制，这样就可以把字母的大小写分开，而且由于是二进制字符串，所耗费的时间也会更短。可惜，在实陆应用中我们存储的大多是中文，所以这一点对我们来说并没有太大的区别。中文，本来就没有大小写之分，再怎么二进制，还是那样。呵呵。
在MYSQL4.0及以前的版本里，各种文本字段的字符集和排序方式都由MYSQL服务器决定，默认值是latin1字符集和瑞典排序方式。虽然允许在MYSQL配置文件里指定一种字符集和排序方式，但这会导致所有的数据库受到影响，还有，对字符集和排序方式做了任何修改都必须重启数据库服务器方能生效，更可恨的是，重启后，还必须重新创建所有的索引，同时，MYSQL4.0之前的版本并不支持UNICODE字符集。
4.1后，这些问题得到了很大的改状况，可以单独为某一个数据列指定一种字符集和排序方式，而且字符集和排序方式的选择范围也大了很多，因为从4.1开始支持了UNICODE和UCS-2等。与字符集及相关排序方式相关的命令是：SHOW COLLATION（必须要注意的是，字符集和排序方式不是随意组合的，每种字符集都有该字符集对应的一些排序方式，而不能混用）。如果没有为某个数据列指定一个字符集和排序方式，它将使用数据表、数据库或MYSQL数据库的默认字符集。至于数据库应该使用哪种字符类型，还是由你的项目所决定，如果你的项目采用了GBK编码，那数据库也同样使用这种编码比较好。如果你在项目初始时对于采用哪种编码未知，那么UTF8应该算是比较好的一种解决方法，数据迁移以及对于JAVA、.net等程序的支持也是最好的，唯一的缺点就是占用数据库空间太大。
说到现在，一直在说latin1和unicode字符集，这代表了什么意思呢？
latin1：在最初的MYSQL版本里都是默认采用了这种字符集，它是符合ISO-8859-1的规范的，收录了西欧国家的常用字符，在那个年代，国内还没有多少人使用MYSQL，而真正使用这些的大多是欧美国家，所以这个字符集主要就是用于收集这些国家常用的字符。随后latin的标准 在不停的变化，有latin2,latin9等，但它们当中并没有一个能够把所有欧洲语言里所有的字符都收录齐全，也就是说latin库里并没有一个可以适用于整个欧洲。
UNICODE：正由于latin不能解决这个问题，所以人们开发出了双字节的UNICODE字符集，两个字集意味着是2的16次方，可以存储65535个字符，所以UNICODE字符集不仅涵盖了所有的欧洲语言，还覆盖了绝大多数的亚洲语言。然而UNICODE只定义了每个字符的编码，没有定义如何存储这些编码。
在这个基础上，也同样发展出了好多变体。最重要的是UCS-2和UTF8，UCS-2又称UTF-16，即每种字符都用两个字节表示，所以几乎所有的字符都被涵盖了。但是这种也是有弊端的：存储空间大了一倍，即使是ASCII字符也是这样；字节编码0会出现在字符串中（比如ASCII写出来的文本里，每一个的第2个字节都是0），可是一些程序会把0当成结束标志，而导致出错。
UTF8是UTF16的替代品，在这里所有的ASCII（7位）仍然象以前一样用第一位是0的单字节表示，所有其他的UNICODE字符用2~4个字节表示。它的缺点也同样明显：同一份文档的字节数和字符数没有任何显而易见的关系，但由于它与现有的程序高度兼容，所以UTF8几乎已经成为了一种事实上的标准，而且大多数软件都把它作为自己的默认字符集。
可惜，PHP发展到现在对于UNICODE的支持还是一般性，并没有内置，处理的时候，不是用ICONV就是mb_string库（PHP6是说内置支持了），但并不能妨碍我们使用UTF8来开发网页。

字符串就介绍到这里。太累了。。。。。这个方面的问题太多了，在以后的连载中遇到再详细说明吧。