几个常见的初级问题

2010-06-10 07:24:34
作者：郑凯

[h]Password Hash 应该加 Salt[/h]

不加 Salt 是很常见、危害很大的问题。我一直是加的，但是到了去年才知道这个词叫 [url=http://en.wikipedia.org/wiki/Salt_(cryptography)]Salt[/url]

通常，密码存在数据库里时用的是 MD5，但绝不应该是原文的 MD5，应该加个字符串（随便什么都可以，但是要永久固定，不能每次随机）再 MD5，例如 [incode]md5($sPassword . "somesalt");[/incode]

是否加 Salt 的区别在于，如果用户数据库被黑了，或者被内鬼 dump 走了，你不会暴露用户的密码原文，因为常见密码的 md5 随便用 Google 都可以找到，而绝大部分人又都是一个或最多几个密码，导致用户的其他帐号也有危险。

同时这个问题又是无法纠正的，一旦用户表开始记录真实用户，就没法改了。

如果你有机会从头开始构建一个新项目的 Passport，记得加 Salt，哪怕是最简单的。

[h]对于中文内容，MySQL 存储的字符集用 UCS-2[/h]

没错，我们显示页面时用的 UTF-8、跟 MySQL 连接的时候也用的 [incode]SET NAMES utf8[/incode]，但是存储的时候，如果你打算在表和字段的字符集上用 UTF-8，那么应该改成 UCS-2。

因为 UTF-8 本身是不定长的，而预留位置总要按最坏的打算来，因此如果你定义了一个 CHAR(3) 的字段的字符集是 UTF-8，那么它占用的空间是 9 个字节，而不是 3 个或者平均值 6 个，这样才能保证你无论是存三个汉字还是三个字母，都能保证装的下，但我们知道，有些空间被浪费了。而 UCS-2 的基本特性是任何字符都按两个字节来存，也就是每个 CHAR(3) 占 6 个字节。

要验证可以不断的更改字符集，并用类似下面的 SQL 来查看 Avg_row_length

[code]
SHOW TABLE STATUS FROM `database_name` LIKE 'table_name'
[/code]

对于定宽（[incode]Row_format == Fixed[/incode]）的表，尤其应该如此。

不是说这事有多大的性能提升，而主要在于简单并且无副作用。如果一个表因为这个设置而从 8G 变成 6G，怎么着也应该有些好处吧。

[h]RSS 的删除[/h]

虽然说出来弊大于利，但从技术角度讲是应该知道的

如果是数据库里关于删除有个标记位，比方说 [incode]WHERE[/incode] 条件里有个 [incode]del != "Y"[/incode] 之类的，在页面显示上是应该如此，但 RSS 作为一种给机器读的文本，则是另一套机制。

RSS 本来就只是显示有哪些变化，而非显示总共有哪些内容，因此如果跟网页一样只是不显示，就会被认为是没有变化，而在 Google Reader 或者别的什么 RSS 阅读器里永久保存。

因此不应该是在 WHERE 条件的时候滤掉删除的内容，而是在显示 RSS 的时候判定，如果是已被删除的条目，则相应的 title 和 description（或者叫 content，取决于你的 RSS 版本）显示为空字符串或者“deleted”之类的

如果新浪把这个问题纠正了，韩寒的 blog 估计就真得搬家了。这非我的本意，但韩寒换 BSP 容易，更多人碰到自己的文章想删删不掉的时候会很麻烦。