如果看到mysql中COLUMN 的collate是以ci结尾,意味着该列不区分大小写。

更改为cs或bin结尾的即可。

举例：

ALTER TABLE tablename MODIFY COLUMN `nickname` VARCHAR(30) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL;

selector{
property:value; /* 所有浏览器 */
property:value\9; /* 所有IE浏览器 */
+property:value; /* IE7 */
_property:value; /* IE6 */
}

备忘

连支付网关最头疼的就是乱码

产生的原因：

1：中文URLEncode的编码集不一致产生乱码，

URLEncode.encode("GBK")和 URLEncode.encode("UTF-8")传过来的值是完全不同的

example:

URLEncoder.encode("蜜蜂飞啊飞","UTF-8")=%E8%9C%9C%E8%9C%82%E9%A3%9E%E5%95%8A%E9%A3%9E

URLEncoder.encode("蜜蜂飞啊飞","GBK")=%C3%DB%B7%E4%B7%C9%B0%A1%B7%C9

所以我们服务器接收的编码必须要和对方服务器的编码一致，否则产生乱码。

假定我们的服务器是URIEncoding="utf-8"，那么要求对方传过来的数据只能用utf-8 

仅记录自己的错误

HBufC* content=HBufC::NewLC();

(CleanupStack::Pop();)本应该在删除之前

delete content;

少用这个NewLC，一旦忘记了 查起来是要死人的

mysql出现：Lock wait timeout exceeded; try restarting transaction

什么问题导致的呢？绝对是程序的问题，因为另一个线程锁住了表或者记录导致后来到请求无法完成。

如何产生的：

表A

存储过程B

DELIMITER $$

DROP PROCEDURE IF EXISTS `B` $$
CREATE PROCEDURE `B`( )
BEGIN
SET autocommit=0;

select * from A where id=1 for update;

.......
commit;
END $$

DELIMITER ;

存储过程C

DELIMITER $$

DROP PROCEDURE IF EXISTS `C` $$
CREATE PROCEDURE `C`( )
BEGIN
select * from A where id=1 for update;

........
END $$

DELIMITER ;

当调用完B以后（autocommit=0），调用c（此时该记录被锁定，因为没有commit该锁就一直在，造成了全局的死锁.这里其实还是代码问题，因为在autocommit=1的情况下for update 实际上是不起作用的），此后无论任何地方再来锁A表的记录的时候就会出这个超时的异常。

autocommit是connection级别的变量,但是锁确实全局的(select @@autocommit;），在我们使用数据库连接池的情况下，connection.close()其实只关闭了所有的statement,

所以当同一个connection调用了B以后再去调用C.造成了一个全局的锁。

如果只是想加锁的范围在特定的语句，则应该使用START TRANSACTION语句：

START TRANSACTION;

select * from A where id=1 for update;

。。。

COMMIT;