sphinx的searchd在启动时会创建一个 .spl 锁文件，并在关闭时会删除它。在indexer创建索引时如果发现有 .spl文件，则不会创建新索引，因为这时已经标志sphinx正在运行中，除非使用 –rotate。
roate运行机制
->indexer完成索引
->发送SIGHUP 给searchd（同时在终端输出索引已经完成）
->searchd接到中断信号->等待所有子进程退出
->重命名 当前索引为旧索引为 .old
->重命名 .new 索引文件作为当前索引
->尝试加载当前索引文件->如果加载失败，searchd会把.old文件回滚为当前文件，并把刚建立的新索引重命名为 .new
->加载成的话：完成无缝衔接
综上：解决问题的办法是：
关闭searchd :killall -9 searchd
重启 searchd :searchd -c ../sphinx.conf
Note:在有的时候需要注意建立索引时是否有warning之类的信息，这些信息也会导致rotate失败
在 Linux 使用 cp 遇到檔案覆蓋時，預設不會詢問並且直接覆蓋。但為了要達到詢問是否覆蓋的功能，大部份的 Linux 在~/.bashrc 都有設定 alias cp=’cp -i’ (prompt before overwrite)
但是問題來了，cp -i 只能回答 y 或 n，並沒有類似 unzip 有 [A]ll, [N]one (全部覆蓋或全部不覆蓋)的選項，所以每個檔案要回答，也造成了不少困擾，即使下了 cp -f ，也因為 alias 的設定自動變成了 cp -i -f 而失效。
如果要強制全部覆蓋有幾種方式:
1. 忽略 alias
cp ….
2.全部自動回答 yes
cp ….. –reply=yes
3.取消 cp 的 alias
unalias cp
cp ….
Pasted from
可能有很多人遇到过标题中的这个错误。之前我们也经常遇到，一直没有认真找是什么原因。今天花了些时间google了下。原来，这个问题并不是MySQL的bug, 它本质是一个配置问题， 解决起来也不麻烦。
在Mysql客户端中， 通过 SHOW VARIABLES; 语句可以查看Mysql系统变量。这些变量中名为 wait_timeout 的变量的值过于小，就是造成这个错误的根源。这个变量的含义是：如果在该连接在 wait_timeout 时间内没有进行任何查询（idle时间超时）, 服务器将自动关闭这个连接。
如果你的脚本在执行了一个查询之后，接着是另外一个很耗时的没有任何数据库查询的操作（超过了wait_timeout设置的值，单位是秒)， 之后你再进行数据库操作，就一定会遇到标题所示的错误。
我的解决方案是，在必要的地方，数据库连接之后，立刻执行一句’SET SESSION wait_timeout=65535″。
Pasted from <http://hi.baidu.com/nan_feiyan/blog/item/ea34e81e7aadc90f4034172a.html>
Problem:
Get following prompt in command line while run a php application,
“zend_mm_heap corrupted”
Solution:
A.while do complie for php, use the –enable-debug option
B. Before run a php application, set following environment, USE_ZEND_ALLOC=0, however, it seems this only works for PHP CLI mode, doesn’t work for Apache Module, such as in php.ini or httpd.conf. There is an lucky scenarios for nginx, he fix the problem via: set the environment in bash_profile, and then restart the php-fpm
Note:
zend_mm means Zend Memory Manager
右缩进：tab
左缩进：shift+tab
查看以下文件夹时，首先要到“工具－文件夹选项－查看”中确认隐藏文件夹，系统文件夹设置为可见！
Windows Vista/Windows 7
%SystemDrive%\Users\%USERNAME%\AppData\Local\Microsoft\Messenger\XXX(Messenger Account)\ObjectStore\UserTile
Windows XP
%SystemDrive%\Documents and Settings\%USERNAME%\Application Data\Microsoft\Messenger\ObjectStore\UserTile
Messenger背景图片、动态背景图片、Messenger头像等文件夹，结尾是DT2的文件都是 重新命名成.jpg的后缀名即可
刚才我想调试一个PHP脚本，就启动我的Apache服务器，居然提示本地端口80已经被占用不能绑定（我的Apache用的是80端口），然后我就开始查是什么占了80端口。
解决方法：
PS:Web迅雷也默认占用80端口
我们的MySQL使用latin1的默认字符集，也就是说，对汉字字段直接使用GBK内码的编码进行存储，当需要对一些有汉字的字段进行拼音排序时（特别涉及到类似于名字这样的字段时），默认无法通过order by关键字正确排序。
经过网上查找，网上的办法大多是针对使用utf8字符集的数据库，主要的方法有：
1）直接转换字段为gbk，比如：
SELECT * FROM table ORDER BY CONVERT( chinese_field USING gbk ) ;
或者干脆将相应字段改为gbk字符集。
我在我的数据库测试了上面的方法，或者直接按字段排序，都不行，主要是排序结果不理想。
2）查表法
创建一个新表，用来存储拼音声母和使用该声母的汉字首字的对应关系。然后写一个函数，每次排序时通过转换为gbk再查表的方法得到字段内容首字的声母的方法。
这个方法我也试了，太麻烦，而且针对我的数据库，也不能正确排序。
后来，我查询了汉字编码的一些资料，发现GBK内码编码时本身就采用了拼音排序的方法（常用一级汉字3755个采用拼音排序，二级汉字就不是了，但考虑到人名等都是常用汉字，因此只是针对一级汉字能正确排序也够用了）。根据这个原理，直接按字段排序就应该可以的（我的数据库使用Latin1 字符集，存的汉字本来就是GBK内码），但我试了以后发现不行。参考上面方法2的查表法，我把字段内容转换为16进制编码，再排，就OK了！
这就是最终的办法：SELECT * FROM table ORDER BY hex( chinese_field ) 简单吧！
这是我的例子数据排序输出的结果，如下图：
附：汉字编码方式简介
ASCII
ASCII码是7位编码，编码范围是0×00-0x7F。ASCII字符集包括英文字母、阿拉伯数字和标点符号等字符。其中0×00-0×20和0x7F共33个控制字符。
只支持ASCII码的系统会忽略每个字节的最高位，只认为低7位是有效位。HZ字符编码就是早期为了在只支持7位ASCII系统中传输中文而设计的编码。早期很多邮件系统也只支持ASCII编码，为了传输中文邮件必须使用BASE64或者其他编码方式。
GB2312
GB2312 是基于区位码设计的，区位码把编码表分为94个区，每个区对应94个位，每个字符的区号和位号组合起来就是该汉字的区位码。区位码一般 用10进制数来表示，如1601就表示16区1位，对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。
区位码中01-09区是符号、数字区，16-87区是汉字区，10-15和88-94是未定义的空白区。它将收录的汉字分成两级：第一级是常用汉字计 3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。一级汉字 是按照拼音排序的，这个就可以得到某个拼音在一级汉字区位中的范围，很多根据汉字可以得到拼音的程序就是根据这个原理编写的。
GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。可以用繁体汉字测试某些系统是不是只支持GB2312编码。
GB2312的编码范围是0xA1A1-0x7E7E，去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。
EUC-CN可以理解为GB2312的别名，和GB2312完全相同。
区位码更应该认为是字符集的定义，定义了所收录的字符和字符位置，而GB2312及EUC-CN是实际计算机环境中支持这种字符集的编码。HZ和 ISO-2022-CN是对应区位码字符集的另外两种编码，都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像 和。
GBK
GBK 编码是GB2312编码的超集，向下完全兼容GB2312，同时GBK收录了Unicode基本多文种平面中的所有CJK汉字。同 GB2312一样，GBK也支持希腊字母、日文假名字母、俄语字母等字符，但不支持韩语中的表音字符（非汉字字符）。GBK还收录了GB2312不包含的 汉字部首符号、竖排标点符号等字符。
GBK的整体编码范围是为0×8140-0xFEFE，不包括低字节是0×7F的组合。高字节范围是0×81-0xFE，低字节范围是0×40-7E和0×80-0xFE。
低字节是0×40-0x7E的GBK字符有一定特殊性，因为这些字符占用了ASCII码的位置，这样会给一些系统带来麻烦。
有些系统中用0×40-0x7E中的字符（如“|”）做特殊符号，在定位这些符号时又没有判断这些符号是不是属于某个 GBK字符的低字节，这样就会造成错误判断。在支持GB2312的环境下就不存在这个问题。需要注意的是支持GBK的环境中小于0×80的某个字节未必就 是ASCII符号；另外就是最好选用小于0×40的ASCII符号做一些特殊符号，这样就可以快速定位，且不用担心是某个汉字的另一半。Big5编码中也 存在相应问题。
CP936和GBK的有些许差别，绝大多数情况下可以把CP936当作GBK的别名。
GB18030
GB18030编码向下兼容GBK和GB2312，兼容的含义是不仅字符兼容，而且相同字符的编码也相同。GB18030收录了所有Unicode3.1 中的字符，包括中国少数民族字符，GBK不支持的韩文字符等等，也可以说是世界大多民族的文字符号都被收录在内。
GBK和GB2312都是双字节等宽编码，如果算上和ASCII兼容所支持的单字节，也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码，有单字节、双字节和四字节三种方式。
GB18030 的单字节编码范围是0×00-0x7F，完全等同与ASCII；双字节编码的范围和GBK相同，高字节是0×81-0xFE，低字节的编码范围是0×40 -0x7E和0×80-FE；四字节编码中第一、三字节的编码范围是0×81-0xFE，二、四字节是0×30-0×39。
Windows 中CP936代码页使用0×80来表示欧元符号，而在GB18030编码中没有使用0×80编码位，用其他位置来表示欧元符号。这可以理解为是 GB18030向下兼容性上的一点小问题；也可以理解为0×80是CP936对GBK的扩展，而GB18030只是和GBK兼容良好。
unicode
每一种语言的不同的编码页，增加了那些需要支持不同语言的软件的复杂度。因而人们制定了一个世界标准，叫做unicode。unicode为每个字符提供 了唯一的特定数值，不论在什么平台上、不论在什么软件中，也不论什么语言。也就是说，它世界上使用的所有字符都列出来，并给每一个字符一个唯一特定数值。
Unicode的最初目标，是用1个16位的编码来为超过65000字符提供映射。但这还不够，它不能覆盖全部历史上的文字，也不能解决传输的问题 (implantation head-ache’s)，尤其在那些基于网络的应用中。已有的软件必须做大量的工作来程序16位的数据。
因 此，Unicode用一些基本的保留字符制定了三套编码方式。它们分别是UTF-8,UTF-16和UTF-32。正如名字所示，在UTF－8中，字符是 以8位序列来编码的，用一个或几个字节来表示一个字符。这种方式的最大好处，是UTF－8保留了ASCII字符的编码做为它的一部分，例如，在UTF－8 和ASCII中，“A”的编码都是0×41.
UTF－16和UTF－32分别是Unicode的16位和32位编码方式。考虑到最初的目的，通常说的Unicode就是指UTF-16。在讨论Unicode时，搞清楚哪种编码方式非常重要。
UTF-8
Unicode Transformation Format-8bit，允许含BOM，但通常不含BOM。是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24为（三 个字节）来编码。UTF-8包含全世界所有国家需要用到的字符，是国际编码，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显 示。如，如果是UTF8编码，则在外国人的英文IE上也能显示中文，他们无需下载IE的中文语言支持包。
GBK的文字编码是用双字节来表示的，即不论中、英文字符均使用双字节来表示，为了区分中文，将其最高位都设定成1。GBK包含全部中文字符，是国家编码，通用性比UTF8差，不过UTF8占用的数据库比GBD大。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换：
GBK、GB2312→Unicode→UTF8
UTF8→Unicode→GBK、GB2312
对于一个网站、论坛来说，如果英文字符较多，则建议使用UTF－8节省空间。不过现在很多论坛的插件一般只支持GBK。
Windows的ANSI
为使计算机支持更多语言，通常使用 0×80~0xFF 范围的 2 个字节来表示 1 个字符。比如：汉字 ‘中’ 在中文操作系统中，使用 [0xD6,0xD0] 这两个字节存储。
不同的国家和地区制定了不同的标准，由此产生了 GB2312, BIG5, JIS 等各自的编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统下，ANSI 编码代表 JIS 编码。
不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。
jquery radio取值，checkbox取值，select取值，radio选中，checkbox选中，select选中，及其相关
获取一组radio被选中项的值
var item = $(‘input[@name=items][@checked]‘).val();
获取select被选中项的文本
var item = $(“select[@name=items] option[@selected]“).text();
select下拉框的第二个元素为当前选中值
$(‘#select_id’)[0].selectedIndex = 1;
radio单选组的第二个元素为当前选中值
$(‘input[@name=items]‘).get(1).checked = true;
获取值：
文本框，文本区域：$(“#txt”).attr(“value”)；
多选框checkbox：$(“#checkbox_id”).attr(“value”)；
单选组radio： $(“input[@type=radio][@checked]“).val();
下拉框select： $(‘#sel’).val();
控制表单元素：
文本框，文本区域：$(“#txt”).attr(“value”,”);//清空内容
$(“#txt”).attr(“value”,’11′);//填充内容
多选框checkbox： $(“#chk1″).attr(“checked”,”);//不打勾
$(“#chk2″).attr(“checked”,true);//打勾
if($(“#chk1″).attr(‘checked’)==undefined) //判断是否已经打勾
单选组radio： $(“input[@type=radio]“).attr(“checked”,’2′);//设置value=2的项目为当前选中项
下拉框select： $(“#sel”).attr(“value”,’-sel3′);//设置value=-sel3的项目为当前选中项
$(“
“).appendTo(“#sel”)//添加下拉框的option
$(“#sel”).empty()；//清空下拉框
如何在下面的代码的 callback 之中访问全局变量
Js代码
function test(){
$.ajax({
url: “test.txt”, cache: false, dataType:”json”,
//data:’id=’+$(“#id”).value(),
success: function(json){
g_aaa = json.name;
}
});
}
$(document).ready(function (){
var g_aaa = “”;
alert(g_aaa);
});
解决代码如下: url: “test.txt”, async: false, cache: false, dataType:”json”,
