PHP 序列化（serialize）格式详解

1. 前言
2. 概述
3. NULL 和标量类型的序列化
4. 简单复合类型的序列化
5. 嵌套复合类型的序列化
6. 自定义对象序列化
7. Unicode 字符串的序列化
8. 参考文献

原文来自Coolcode.cn，作者andot

» 阅读全文

什么是Base64？

按照RFC2045的定义，Base64被定义为：Base64内容传送编码被设计用来把任意序列 的8位字节描述为一种不易被人直接识别的形式。（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.）

为什么要使用Base64？

在设计这个编码的时候，我想设计人员最主要考虑了3个问题：
1.是否加密？
2.加密算法复杂程度和效率
3.如何处理传输？

    加密是肯定的，但是加密的目的不是让用户发送非常安全的Email。这种加密方式主要就是“防君子不防小人”。即达到一眼望去完全看不出内容即可。
基 于这个目的加密算法的复杂程度和效率也就不能太大和太低。和上一个理由类似，MIME协议等用于发送Email的协议解决的是如何收发Email，而并不 是如何安全的收发Email。因此算法的复杂程度要小，效率要高，否则因为发送Email而大量占用资源，路就有点走歪了。

    但 是，如果是基于以上两点，那么我们使用最简单的恺撒法即可，为什么Base64看起来要比恺撒法复杂呢？这是因为在Email的传送过程中，由于历史原 因，Email只被允许传送ASCII字符，即一个8位字节的低7位。因此，如果您发送了一封带有非ASCII字符（即字节的最高位是1）的Email通 过有“历史问题”的网关时就可能会出现问题。网关可能会把最高位置为0！很明显，问题就这样产生了！因此，为了能够正常的传送Email，这个问题就必须 考虑！所以，单单靠改变字母的位置的恺撒之类的方案也就不行了。关于这一点可以参考RFC2046。
基于以上的一些主要原因产生了Base64编码。

» 阅读全文

自从我用上了http_rewrite之后，好象登录啥的都有点问题。但应该不完全是这个问题。
FF3好象对网页有一定的缓存功能，因此在回复的时候，好象会一直提示：验证码不正确。这个问题我暂时不知道到底是FF3的问题呢，还是啥问题。

反正，我用FF3只要是打开有验证码的网站，总归是要登录个4、5次。为了方便大家回复，我目前将回复需要验证码这个功能关掉了。（评论审核嘛。。。还是先开着，等过完节再关。）

原始链接：http://tech.idv2.com/2008/01/09/javascript-variables-and-delete-operator/
内容原文：http://nanto.asablo.jp/blog/2008/01/09/2552470

内容是日本人写的，是篇翻译文章，写的很不错，讲了几个内容：

• Javascript的变量
• delete操作符删除的对象
• 对变量执行delete的情况
• 能删除的属性和不能删除的属性
• 能删除的变量和不能删除的变量
• delete的返回值

详细请看全文

» 阅读全文

MYSQL中，如果表是MYISAM，除了主键索引外，基本上常用的就是默认的索引，而unique index应该是比较少用到的。外键索引在MYSQL4.0以下直接忽略。

查了一下资料，好象默认索引应该是称之为B*Tree索引

刚才又看到文章，说在使用B*Tree索引的时候千万要注意：Btree索引不存储NULL值，而在order by desc中，NULL值总是最大的，sql语句通过索引无法判断表是否存在NULL，执行计划还是走全表扫描[详见：http://rdc.taobao.com/blog/dba/html/67_oracle_fenye.html]（当然，这也只是一个参考）

如果是确实这样，那么如果该字段可能会需要用到排序的时候，请尽量不要使用default NULL，而且在处理where的时候，NULL是不会被显示的。除非是条件是is NULL。

刚才测试了一下，设定了某字段允许NULL，然后插入数据，并为该字段做了索引，结果在where fields < 100 的时候，使用了该索引（当然NULL值是不显示的），但我取where fields > 0的时候，扫描方式立刻变为了全表，而且没有使用fields索引（同样不显示含 NULL值的行），where fields > 1 的时候，同样扫描全表。直到我设为fields > 2的时候，又开始使用了索引，看来，MYSQL对于索引字段做查询条件的时候还是需要斟酌的，条件不能随便乱加。

其实在程序中，如果使用INT字段（数值型字段），请尽量不要使用NULL，否则确实有可能会出现值查不到的情况。

然而，在我现在的项目中却有这种情况，要求我们把该字段设为NULL，明天我要再检查一下代码，以防止有漏掉的数据。

不看不知道一看吓一跳呀