电脑重装，什么东西最让你郁闷？密码。。。是的，密码
网络密码，论坛密码，乱七八槽的，你都记得住吗？还在用大脑？还是用记事本，用软件？
所说，人可以记忆的复杂密码一般为7个左右。所以，密码不要设的太多。
但是自己的设的密码还能猜呢，别人设的怎么办？比如我们的无线网络，在N多地方登录过，你怎么记得清每一处的密码？
推荐这款软件，可以让你把系统使用过的无线密码统统翻译出来。试过有效。

软件下载地址：http://www.hanzify.org/index.php?Go=Show::List&ID=12260
汉化作者：南方的雨
软件介绍：WirelessKeyView 让你可以恢复 Windows 操作系统（非第三方产品）存储的无线网络密匙（WEP/WPA）。该软件采用十六进制和 Ascii （如果提供）码显示带有适配器名称和用户图形界面的密匙。该信息可以被拷贝到剪贴板或者导出为 Text/HTML/XML 文件格式。该软件不需要进行安装

试用情况：主要是两个文件，一个EXE，一个INI文件，运行后会生成一个CFG文件，没有广告，仅在帮助的左下角有一个南方的雨的名称和链接。其余干干净净。当然，如果你不喜欢中文版，你就把那个ini文件删除就行了

为了保持作者原有的格式，和他的URL版本的邮箱，我就不做更改了。其实世界上很多事情都是那么巧的，php focus群里的朋友还在问我数据库是否能够直接拷了就能使用。我的解释是4.0以下的版本都可以拷的，从4.1开始尽量使用mysqldump，但是sundj说，对于MYISAM类型的数据库和表，是可以直接COPY的。对于INNODB则不行。然后打开日常订阅的一些RSS，就发现了这篇文章 。。。套用范伟老师的话：缘份呐

原文如下：

作/译者：叶金荣（Email: ），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

前言

InnoDB存储引擎满足了MVCC和ACID特性，在需要支持事务的环境下必不可少。有些环境下，采用InnoDB可能效果比MyISAM还要来 的好。不过，在很多人眼中看来，InnoDB表空间文件由于无法实现跨服务器平滑迁移，因此不愿意使用。实际情况真是这样吗？本文就来探讨一下 InnoDB表空间文件的平滑迁移可能性。

如何迁移？

从MySQL文档中我们了解到，InnoDB的表空间可以是共享的或独立的。如果是共享表空间，则所有的表空间都放在一个文件 里：ibdata1,ibdata2..ibdataN，这种情况下，目前应该还没办法实现表空间的迁移，除非完全迁移，因此不在本次讨论之列；我们只讨 论独立表空间的情况。

不管是共享还是独立表空间，InnoDB每个数据表的元数据(metadata)总是保存在 ibdata1 这个共享表空间里，因此该文件必不可少，它还可以用来保存各种数据字典等信息。数据字典中，会保存每个数据表的ID号，每次发生数据表空间新增时，都会使 得该ID自增一个值(++1)，例如：CREATE TABLE xx ENGINE = InnoDB / ALTER TABLE xx ENGINE = InnoDB 都会使得ID值增加。
有了上面的理解，想要实现InnoDB表空间文件的平滑迁移就很容易了，呵呵。下面是一些例子：
假定我们有2台DB主机，一个是A，一个B；现在想把A上的某个InnoDB表空间文件迁移到B上直接用。

一、迁移失败的例子

直接从A上把表空间文件 yejr.ibd 拷贝到 B 上后，导入表空间，报错，无法使用。这是由于A，B上创建该表时的顺序不一致，导致表的ID不一样，无法导入。
注意：，在这里，表空间文件直接拷贝的前提是该表空间处于"干净"状态下，也就是所有的数据均已经刷新到磁盘中，否则可能导致无法使用或部分数据丢失。
1. 在B上将旧的表空间废弃

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

2. 拷贝到目标机器

scp yejr.ibd B:/home/mysql/yejr/yejr.ibd
....

3. 启用该表空间

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

4. 查看错误

InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './test/b.ibd'!
InnoDB: Error: cannot reset lsn's in table `test/b`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

5. 很明显，是权限的问题，修正过来，然后重新导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

6. 怎么还是错误？继续看日志

InnoDB: Error: tablespace id in file './yejr/yejr.ibd' is 15, but in the InnoDB
InnoDB: data dictionary it is 13.
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html
InnoDB: for how to resolve the issue.
InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `yejr/yejr`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

从上面的日志得知，由于在A服务器上，yejr表的ID是15，而在B服务器上，yejr表的ID却是13，二者不一致，因此迁移失败。
既然只是因为ID不一样，而且有了上面的理论基础，我们完全可以人为的让它们的ID一致嘛，请看下面的第2次尝试。

二、人工干预下的成功迁移

1. 上面的例子中，B上面的yejr表ID为13，而A上面为15；因此只需要让B上的yejr表ID增加2就可以了。

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr RENAME TO yejr1;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为14
(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr1 RENAME TO yejr;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为15

2. 然后，我们再导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
Query OK, 0 rows affected (0.00 sec)
(root@imysql.cn/17:52:47)[yejr]>select count(*) from yejr;
+----------+
| count(*) |
+----------+
|        3 |
+----------+
1 row in set (0.00 sec)

看到了吧，成功了，呵呵。想要让他ID增加的方式也可以重复创建表，根据实际情况或者个人喜好而定了。
以上测试均在mysql 5.0.67版本下通过，只不过显示数据稍作处理了。

原文URL：http://imysql.cn/2008_12_17_migrate_innodb_tablespace_smoothly

在制作 网页的时候，不可避免的会用到Cookie，无论是登录也好，保存状态也好，或多或少，你都会在使用Cookie这个小甜饼。

然而甜饼并不是这么好吃的，吃的过多也会有问题的，如果你的网站COOKIE数量过多，或许你的浏览器就直接打不开这个网页（这点好象是和SERVER端有关，apache接受客户端的COOKIE数量和长度也有限制）

对于用户来说，如果没有做限制的话，那么COOKIE过多会导致后一个新的COOKIE会覆盖掉前面的COOKIE。。

那么，究竟应该有多少COOKIE呢？

以下内容来自DBA Notes网站：

Cookie 是个很有趣的话题。根据 RFC 2109 的描述，每个客户端最多保持 300 个 Cookie，针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多，比如 Firefox 是 50 个) ，每个 Cookie 最多 4K，注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了，对于 Cookie 最重要的就是，尽量控制 Cookie 的大小，不要塞入一些无用的信息。

所以，不要把你想知道的用户行为都采用COOKIE来保存，否则造成的后果恐怕是非常大。在一些大型网站，目前对于用户的行为已经开始逐步采用数据库来控制，这样可以记录用户的一些操作，对于用户的行为分析也能够达到的一定的效果，缺点是加大了数据库的压力。而且对于未登录网站的用户来说，他的行为将变得毫无意义

想象：将用户的一些普通行为采用Cookie保存，重要信息记录数据库。比如用户浏览过的网页记入cookie，而用户停留时间最长的网页则考虑记入数据库（当然，对于那种开着网页不关的人就无法对付了，但仍然可以通过客户端的document.scroll的高度来进行判断，再通过ajax提交 ）意义不是特别大。对于一些象购物车之类的，确实可以考虑存入数据库，否则一旦网页误关闭了对于用户的体验可能并不是很好（给用户一个可选项：cookie或者数据库，但好象有点傻）。。。。。。

随便谈谈吧。。

snoopy是在系统不支持curl的情况下所采用的抓取网络信息最有用的工具之一，因为他可以模拟POST，GET等方法，而无须让你再向以前一样用fsockopen，写上一大堆代码。

这样的一个类库，在目前被PHP的使用者广泛应用着，本来以为他就这样的一直不再更新下去，不料最近还是有了一些改动，当然这些改动都是一些BUG fix，而且是安全方面的，建议下载后更新。

更新情况：

Posted By: mohrt
Date: 2008-10-22 22:54
Summary: Snoopy 1.2.4 security fix

A security vulnerability was fixed in the latest 1.2.4 version of Snoopy. It was possible to send shell commands through https url fetches that are not properly sanitized by the PHP program using Snoopy.

下载页面为：

http://sourceforge.net/project/showfiles.php?group_id=2091

在很早很早以前，我们的看图软件都是用的acdsee，直到现在机器里还保存着2.4和3.1这样的经典版本，随着时间的推长，acdsee的肚量也越来越大，启动速度也越来越慢。最后还出了一个pro版。不过这一切都和我无缘了。因为我不再使用它。

在不再使用的日子里，我尝试了一些其他的软件：xnview,光影魔术手（新版本里面有看图软件了）等。但效果确实不能让人满意。光影的看图功能还不是很强劲，但比xnview要好上很多。

picasa也是我很久前就用的软件。刚出测试版的时候就使用了。只是那时候的效果很不好，在用上一段时间后就放弃了。

由于我现在用的是2003的精简版，里面看图功能被拿掉了。所以我最初用xnview，但是不舒服，后来就换成了picasa。现在我很满意：速度和编辑功能都相对提高了很多，而且滚轮的无限级缩放也很人满意。空格全屏非常爽。当然还有他自带的picasa WEB功能，可以让你在看图的时候选择是否上传到picasa 网站。

贴上一些介绍：

一款可帮助您在计算机上立即找到、修改和共享所有图片的软件.每次打开 Picasa 时,它都会自动查找所有图片(甚至是那些您已经遗忘的图片),并将它们按日期顺序放在可见的相册中,同时以您易于识别的名称命名文件夹.您可以通过拖放操 作来排列相册,还可以添加标签来创建新组.Picasa保证您的图片从始至终都井井有条.Picasa还可以通过简单的单次点击式修正来进行高级修改,让您只需动动指尖即可获得震撼效果.而且,Picasa还可让您迅速实现图片共享–可以通过电子邮件发送图片、在家打印图片、制作礼品 CD,甚至将图片张贴到您自己的blog中.

下载:Google Picasa 3.1 Build 70.71

The new features include:

-Picasa in 38 languages
-Advanced sharing options
-New and improved scrolling
-New sharpen slider