大部分数据库在进行字符串比较的时候，对大小写是不敏感的。但是，最近使用SQLite的时候，却发现它的情况恰好相反。

假设表User的结构和值如下：

执行下面的SQL语句：

SELECT * FROM [User] WHERE UserName = 'user1'

结果是没有找到任何记录。明显地，SQLite在进行字符串比较的时候，默认对大小写是敏感的。这会对应用程序造成不良的影响。比如，用户在输入用户名的时候必须严格按照大小写输入，这是一种很不好的用户体验；用户表中可能同时存在 user 和 USER 两个用户，容易造成混淆。

由于SQLite是近年来才兴起的数据库，中文资料少得很。Google了一些英文资料，终于找到了三种解决方案：

ECMAScript中的Array类有一个排序方法，即本文主要讨论的Array.prototype.sort（下面简称sort），它的调用是很简单的：

var arr = [11, 2, 1];
alert(arr.sort());

然而，上面程序的输出结果是 "1,11,2" ，而不是我们期望的"1,2,11"，这是因为在默认情况下，sort方法排序时会把元素临时转成字符串再比较。要解决这个问题，就要给sort传递一个参数，这个参数是一个进行元素比较的函数，其原型如下：

function compareFn(x, y)

众所周知，ASP已经被微软淘汰了，跟着，又被许多的开发者抛弃了。然而，我仍然认为ASP无论是作为入门的技术还是开发平台，都很值得我们继续去使用。在Google上搜一下，可以发现一大堆对ASP不好的评价，什么运行速度慢、异常处理机制不好、缺乏面向对象机制、开发效率低、漏洞多等等。为了让大家对ASP有个正确的认识，我先为它正名。

一、ASP不慢，慢的是数据库

几年前，我用动网论坛程序架了一个BBS，这套程序就是当时经典的ASP+Access架构。我也遇到了某些人所说的论坛慢，有时候卡死不动的问题。然而，自从我换上SQL Server数据库以后问题就解决了。所以罪魁祸首乃Access。程序执行所需的时间是毫秒级别的，在这个级别内，无论是10毫秒还是100毫秒，实在是感觉不出来，但是Access的并发性差，阻塞了部分程序执行，导致页面卡死。

二、异常处理机制很好，只是很多人不知道

以前，很多人包括我在内都用VBScript来编写ASP程序，VBScript的异常处理机制的确是糟透了。然而，JScript则很好，因为它支持包括C#、Java都有的try…catch语句，足以处理所有异常。

em是近年来讨论得比较多的一个长度单位。其实早在Jeffrey Zeldman写的《网站重构》（中文版于2004年出版）一书中就提到过这个单位，只是当时流行用px（像素）单位，所以很少人留意到em。与px这种绝对长度单位不同，em是相对长度单位，1em代表的是一个字的大小。为何要用字体的大小作单位呢？

多年前，在XHTML+CSS还没有被大多数人知道的时候，网页制作很强调一致性，也就是说让网页在所有用户的机器上的显示基本一样。这里最大的影响因素是字体大小。由于浏览器本身提供了调整字体大小的功能，因此，通过font标签的size属性设置的字体大小会随着浏览器设置而改变。幸运的是，CSS中有一个固定的单位——px。于是，人们开始使用CSS定义字体大小，通常会给body定义一个默认字体大小，在中国，这个值通常是12px。后来，有人注意到视力差的人看12px的字很吃力。那调整到14px？16px？不行，对于视力正常的人来说，12px还是最美的。那怎么办呢，难道要做好几套页面？这明显不划算，于是，浏览器的字体大小设置又一次登上历史舞台，但是在XHTML+CSS的页面中，已经不提倡用font标签定义字体大小，所以一些开发者开始应用有异曲同工效果的em单位。然而，em的一些缺点却限制了它的应用：

以C语言为例，一般来说，交换两个变量的值需要用到一个中间变量：

int a, b;
a = 10;
b = 11;
int c; // 中间变量
c = a;
a = b;
b = c;

但也可以省掉这个中间变量，只是运算的次数增多了：

int a, b;
a = 10;
b = 11;
b = a + b; // 得出两数字的和
a = a - b; // a减去两数字的和就得出原来的b的负值
a = -a;
b = b - a; // 两数字的和减去原来b的值，就得出原来a的值

这是一个典型的时空问题：如果想省掉一个变量（节省内存），就需要多几次运算（运算时间更长）。在目前内存价格低廉的情况下，当然会选择用空间交换时间。