PHP的json数据编译和解译，字符编码无关。
这里只就PHP5.2.0+以上版本而言，因为JSON扩展是自PHP5.2.0才开始引入的。早期版本没有默认引入。
json现在应用比较广泛，主要是由于ajax技术的原因。json可以很方便的传输具有属性的数据格式，方便前端进行解析处理，更好的将数据流量传输降低并且也能使前后端尽可能的分离。
貌似自06年开始我在做的项目如果客户不强烈要求的情况下，我都会使用UTF-8进行编码开发，UTF-8开发会有很多好处，比如前、后端数据传输很方便无须额外的编码开销，另外储存的字符也比较直观，虽然有数据容量的浪费，但在目前储存如白菜价的环境下，容量问题应该不大。
在使用UTF-8编码的时候，json_encode/json_decode可以很方便的处理（虽然编译后的数据中的中文看起来很怪异，但因为也不需要直接使用数据所以也无所谓），因为PHP自带的json扩展库只支持UTF-8编码。
但有的时候客户强烈选择使用GBK/GB2312进行编码的情况下，自带的json就应付不了了。所有涉及到中文的经过编译后会变成null。 更多 »
ISBN的校验
维基百科提供的ISBN码校验算法：
校验码的计算方法（10码）
假设某国际标准书号号码前9位是：7-309-04547
计算加权和S：S = 7×10＋3×9＋0×8＋9×7＋0×6＋4×5＋5×4＋4×3＋7×2 = 226
计算S÷11的余数M：M = 226 mod 11 = 6
计算11 – M 的差N：N = 11 ? 6 = 5
如果N = 10，校验码是字母”X”
如果N = 11，校验码是数字”0″
如果N为其他数字，校验码是数字N
所以，本书的校验码是5；如果用户提供的ISBN码是7-309-04547-6，那么校验失败
校验码的计算方法（13码）
假设某国际标准书号号码前12位是：978-986-181-728
计算加权和S：S = (9×1)+(7×3)+(8×1)+(9×3)+(8×1)+(6×3)+(1×1)+(8×3)+(1×1)+(7×3)+(2×1)+(8×3) = 164
计算S÷10的余数M：M = 164 mod 10 = 4
计算10 – M 的差N：N = 10 ? 4 = 6
如果N = 10，校验码是数字”0″
如果N为其他数字，校验码是数字N
所以，本书的校验码是6。完整的国际标准书号号码为 ISBN 978-986-181-728-6
下面是在网上看到的一段利用PHP进行ISBN进行校验的函数： 更多 »
jQuery处理同级事物的一个方式
呵呵，标题有点绕，不知道这样表达是否达意。其实就是同类型（级别）的事件触发的判断处理而已，还搞不明白？-_-!我的表达有问题，那就看下面的代码吧： 更多 »
关于用户邮箱验证的一个思路
当下很多运营或者应用都会引导用户激活验证注册的Email地址，为了确保获得更可靠的用户（虽然可靠性不是很高），同时也为了避免地址不被滥用，尽力获取更优化的用户资源等等，好处是很多的。
一般在验证流程上都很简单，无非是：根据用户登记的Email发送一个验证邮件，用户收到邮件后，访问一个特定的处理链接，系统接收后，便会确认此人Email通过验证激活。
这个方式简单容易，设计也很方便。
但有一个“问题”，某个用户起初登记了一个A地址，然后通过了验证，过了一阵他又将Email改成了B地址，也通过了验证，可过了一阵又因为某种原因他又将Email改回了A地址，可系统仍旧提示未通过验证，这个挺囧的——当然其实也不是什么大不了的问题，不过个人始终觉得这是一个人性化的考虑。已经通过验证了的邮箱为什么还要再次验证呢？
近期在一个项目上也有类似的处理，因为基于该异想天开的想法，我特意费时巴拉的用了一个新的机制，虽然没人能够看到，但我相信多多少少会让用户觉得有点人味的^_^
具体流程其实很简单，无非是增加一个数据表，用来储存经过验证的Email地址，且每个Email对应一个用户id。
当用户通过验证的时候记录下他的id和Email，以及其他信息（比如验证时间等等）
当用户修改Email的时候，先去到这个数据表内查询该记录是否存在（uid和email同时满足），存在了就表面该用户已经通过验证了，不需要再次发送验证邮件。
uid与Email是作为一个唯一性索引键（UNIQUE）存在的。这样可以确保别人冒用这个Email地址的情况也被认为是通过验证的。 也就是说，只有其本人曾经用过的Email地址才会采用跳过验证的机制。
简单说：
用户A曾经验证通过了a、b、c三个Email地址。 那么日后他无论将Email地址修改变换为这三个任意一个的时候，系统都不会提醒他再次去验证。
如果另一个用户B登记了a地址，那么系统还是要提醒他进行验证的，因为数据表记录下验证通过a地址的用户是A而不是B。
以上就是我在项目中关于用户Email地址验证的一个机制（当然实际操作过程中，还要加入一个验证的条件限制等条件，避免用户频繁的请求，关于这部分处理，相信所有的验证机制都会考虑的。），不一定有什么特别重大的作用，不过觉得还是挺有意思的，记录下来分享一下吧。
CKEditor或者FCKEditor编辑器的分页处理
CKEditor就是FCKEditor的改名版本，呵呵。基于javascript的前端HTML编辑器，一般做内容管理系统的基本都用过这个编辑器，很强大很方便。
做内容管理某个内容可能文字会很多，分开发表的话不方便维护管理，一般就是直接使用CKEditor的分页功能，说白了这个无非就是类似下面的一段HTML代码：
如果要想在前台输出的时候分页是做不到的。我一般会有两种方式进行处理：
1.利用服务端在输出到页面前进行分页。
2.利用前端javascript直接进行分页。
一个有意思的函数传参方法
最近在做的项目，虽然有很多前端的东西，现在不喜欢搞前端，觉得特麻烦，累。不如后台程序部分好玩，直接写代码还是很有意思的。
说实话，这么多年始终对于javascript属于入门汉的状态，主要是觉得javascript相对与服务端的PHP来说，不如PHP直接跟数据库打交道有意思。
不过，最近接触了好多jQuery，突然发现javascript原来不需要了解太多了，哈哈。jQuery真的是个好东西。
在使用和制作jQuery扩展的时候，发现jQuery有一个很有趣的函数传参办法，那就是直接利用数组或者已经格式化了的json字符串，这样做的好处显而易见——不必要记住函数参数的具体顺序，哪个在先哪个在后都无所谓。
现在懒得学习了，PHP手册也仅仅找需要的，加之英语实在不太好，所以在我的印象里，似乎php没有类似的方法（当然PHP类的那个不算在内）
晚上无聊的时候，尝试写了一个乱弹代码，觉得还是挺好玩的。 更多 »
【原创】jQuery插件之Email地址格式判断
呵呵，不算是什么特别的东西，这个应该是第一次写的jQuery的插件。
jQuery.ISEmail = function(email){
var strlen = email.length;
var email_rule = /^[\w\-\.]+@[\w\-\.]+(\.\w+)+$/;
return ( strlen >= 6 && strlen < = 40 && email_rule.test(email) );
}
使用很简单：
if ($.ISEmail('test@test.com')) {
alert('Email 地址格式正确');
} else {
alert('Email 地址格式错误');
}
一直都在使用，未发现特别的问题，如果你使用过程发现什么错误，请告诉我:)谢谢。
