Submitted by gouki on 2008, August 2, 7:56 PM
什么是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编码。
» 阅读全文
Tags: base64, 算法
Javascript | 评论:0
| 阅读:25420
Submitted by gouki on 2008, August 1, 6:54 PM
自从我用上了http_rewrite之后，好象登录啥的都有点问题。但应该不完全是这个问题。
FF3好象对网页有一定的缓存功能，因此在回复的时候，好象会一直提示：验证码不正确。这个问题我暂时不知道到底是FF3的问题呢，还是啥问题。
反正，我用FF3只要是打开有验证码的网站，总归是要登录个4、5次。为了方便大家回复，我目前将回复需要验证码这个功能关掉了。（评论审核嘛。。。还是先开着，等过完节再关。）
Tags: 回复, 失败
Software | 评论:0
| 阅读:18394
Submitted by gouki on 2008, July 31, 9:48 PM
原始链接：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的返回值
详细请看全文
» 阅读全文
Tags: javascript, delete, keyword, 转摘
Javascript | 评论:1
| 阅读:27635
Submitted by gouki on 2008, July 31, 9:23 PM
MYSQL中，如果表是MYISAM，除了主键索引外，基本上常用的就是默认的索引，而unique index应该是比较少用到的。外键索引在MYSQL4.0以下直接忽略。
查了一下资料，好象默认索引应该是称之为B*Tree索引
B*Tree索引
- B*Tree索引是最常见的索引结构，默认建立的索引就是这种类型的索引。B*Tree索引在检索高基数数据列（高基数数据列是指该列有很多不同的值）时提供了最好的性能。当取出的行数占总行数比例较小时B-Tree索引比全表检索提供了更有效的方法。但当检查的范围超过表的10%时就不能提高取回数据的性能。B-Tree索引是基于二叉树的，由分支块（branch block）和叶块（leaf block）组成。在树结构中，位于最底层底块被称为叶块，包含每个被索引列的值和行所对应的rowid。在叶节点的上面是分支块，用来导航结构，包含了索引列（关键字）范围和另一索引块的地址，如图26-1所示。
-
- 假设我们要找索引中值为80的行，从索引树的最上层入口开始，定位到大于等于50，然后往左找，找到第2个分支块，定位为75－100，最后再定位到叶块上，找到80所对应的rowid，然后根据rowid去读取数据块获取数据。如果查询条件是范围选择的，比如where column >20 and column <80，那么会先定位到第一个包含20的叶块，然后横向查找其他的叶块，直到找到包含80的块为止，不用每次都从入口进去再重新定位。
平时在MYSQL的查询中，我们也是建议，筛选条件高的、返回结果集比较整齐的，尽量放在条件的第一个，依稀记得WHERE条件中，如果是AND那么是从前往后比较，如果是OR条件，那么是从后往前比较。（记不清了。。。）
刚才又看到文章，说在使用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，明天我要再检查一下代码，以防止有漏掉的数据。
不看不知道一看吓一跳呀
Tags: mysql, 索引, index
DataBase | 评论:3
| 阅读:33907
Submitted by gouki on 2008, July 30, 11:16 PM
很多时候，WEB开发人员为了偷懒，对于数据输入的长度仅在前台作了限制，而在POST提交页面并未进行判断，这时候很有可能会通过其他方法进行攻击（虽然，插入数据库后，可能会被自动截断，但。。。改改总是挺好玩的）
如：提交页面
XML/HTML代码
- <input type="text" name="msg_title" value="" id="msg_title" maxlength="3">
这样的INPUT框里面，你就只能输入3个字符了，怎么办？当然有办法了，在浏览器的地址栏里键入如下代码：
XML/HTML代码
- javascript:document.getElementById('msg_title').value='123456';void(0);
现在再看一下，是不是input框里面有6个字符了？？？
黑黑。。。
Tags: 限制
Javascript | 评论:1
| 阅读:20495
