PHP发送header头404信息

其实很简单,直接上代码再解释。 更多 »

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 地址格式错误');
}

一直都在使用,未发现特别的问题,如果你使用过程发现什么错误,请告诉我:)谢谢。

Deepseath Modified from Green Hope Theme · Proudly powered by WordPress · 津ICP备09005418号  津公网安备 12010302001005号