易栈网-膘叔

原始链接：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，明天我要再检查一下代码，以防止有漏掉的数据。

不看不知道一看吓一跳呀

很多时候，WEB开发人员为了偷懒，对于数据输入的长度仅在前台作了限制，而在POST提交页面并未进行判断，这时候很有可能会通过其他方法进行攻击（虽然，插入数据库后，可能会被自动截断，但。。。改改总是挺好玩的）

如：提交页面

这样的INPUT框里面，你就只能输入3个字符了，怎么办？当然有办法了，在浏览器的地址栏里键入如下代码：

现在再看一下，是不是input框里面有6个字符了？？？
黑黑。。。

TP的COOKIE类是被封装好的，里面包含了一些常见的操作，set,get,clear等等，其实TP的cookie类与其他的COOKIE有着明显的不同，那就是TP的COOKIE ID是唯一的（不好意思，在我写完这段的时候，为了防止写错，我又重新打开了cookie.class.php，却突然发现，现在的cookie功能与以前的不一样了。）

以前的set函数是类似于这样：

既然如此，我还是按最新的稍作讲解吧。。。

Cookie类，固名思意，就是把对COOKIE的操作进行了封装，通过定义一个COOKIE名的前缀，以防与其他COOKIE产生冲突，然后加上COOKIE变量的名称，就可以进行赋值、取值等。

Cookie类所有的操作都采用了静态方法，即在实际应用中，只要加载了Cookie类，就可以随时使用了：

另外一个需要注意的是，cookie在不同的浏览器下面有着不同的限制，最常见的就是cookie的长度，请尽量不要超过4K的字节。

参考资料：

身为一个网站管理人员，防盗链这个任务实在是任重而道远呀。不说别的，如果不控制，每天的流量可能就会刷刷刷的往上涨，可实际情况呢？根本没有人来浏览。这还不是最重要的，最重要的是这些流量占用了大量带宽，影响了其他人的正常浏览。长此以往，来浏览的人就更少了，再最后就造成恶性循环，网速越慢，来看的人越少，来看的人越少，被下载的机会就越多，也就导致打开网页更慢。

作为一个非下载性网站，防盗连实在是有一些必要，这里我也不谈很多，毕竟防盗链也是一门很高深的技术，我只能随便谈谈。

技巧没有多少，稍谈一点
1、利用SESSION机制，判断该用户的session存在多久？如果是刚生成的，则不让下载
2、COOKIE机制，如果是正常浏览网页，那么生成一个COOKIE，然后才允许下载
3、检查客户机的agent，不过这个很不准确，大多数下载工具都会伪造一个头
4、referer，这个嘛。。。黑黑，表面上有用，其实也没啥用，很明显，下载工具也一样会伪造
5、即时readfile下载，这个会有一点问题，如果东西不大，那是无所谓，如果东西很大，那问题就来了，不能断点续传，也不能使用下载工具。一旦下载失败就不得不重来
6、输入密码。。。象某些网站的提取码之类的
7、用组件，IIS上有现成的防盗链组件，直接可以使用，限制好特定的文件后缀名就行了
8、验证码，这个和输入密码下载有点类似，不过现在很多程序都会自动识别验证码，但下载工具好象还没有这个功能，可以尝试
9、通过邮件机制发送，而不是直接给出下载链接（但很有可能没有办法在网上显示相关内容）
10、无耻的生成BT种子，你们想怎么玩就怎么玩吧。
11、定期按规则更改文件名，或者是链接。。。但不知道那些下载工具是否会自动判断文件的MD5？或者在下载前先判断文件MD5？应该不可能，所以还是值得尝试一下，写个函数，对于下载链接的URL可以定时更换。
12、更改资源内容(这个是看别人的网站而来，意思是，如果提供了MP3下载，那么可以尝试定期不定期的修改MP3的TAG，如果是压缩文件，那么他们都有一个备注区，定期通过程序修改这些位置，可以造成文件大小不一样，对于下载软件来说可能就会被当成不同的文件)
对于11、12好象都有一个问题，主要是指迅雷，如果资源被收录了，但实际被删除了，可能会在一段时间内会被迅雷狂访问，变相的DDOS，曾经我有一台服务器就遇到过这种情况，在我之前，服务器的IP是做电影下载的，后来不搞了，我使用了这个IP，天天流量满，后来一查，发现所有的链接都是下载电影的，虽然没有资源了，但就是拼命的、不停的在连接，造成流量狂涨。

上面这些方法除了用组件比较完全和相对会比较成功一点之外，其他的都难说啊。。。

随便谈谈而己，也不奢求一定能够有用