SouLogic 灵魂逻辑

几个常见的初级问题

作者:郑凯

[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 容易,更多人碰到自己的文章想删删不掉的时候会很麻烦。