MySQL

历史 Movable Type 评论迁移到了 Remark42

上回书 说到留言板的问题时提到留言板当时没有解决, 在文内的模板中可以看到我当时是采用了一种非常对付的方法: 直接将之前的评论直接作为文章内容输出出来。这导致了页面不太美观。

趁着周末我把之前 Movable Type 的数据库重新捋了一下,把其中的 2256 条留言用类似 isso 迁移时的方法转换成了 json,然后就可以在 remark42 中导入了。 中国有句俗话叫三搬一火,意思是搬三次家大约等于失一次火, 这次留言内容搬家我也丢掉了一些东西:Remark42 的一项设计理念便是尽量不保存可以追踪用户的数据,例如用户的 E-mail 在 Remark42 中只会保存一个与之对应的 SHA1,对于网站的主人来说, 这意味着他们不能直接从这些保存的数据中获得用户的 E-mail 地址(当然, 实际情况中,这类单向函数并不能阻止他们在知道这些信息的情况下验证某个 SHA1 是不是某个 E-mail 地址,但总归这要比把数据存在数据库里安全得多), 因此这个迁移过程也就意味着所有相关的明文数据消失了。除此之外,Movable Type 还保存了许多类似于用户网站地址这样的信息,我在转换时考虑了一下,由于许多人的网站都已经不在了, 迁移的意义不太大,因此最终决定不迁移这些数据了。

考虑到现在还在用 Movable Type 的人应该已经没有几个了, 我感觉我的方法可能对其他人没有太大的参考意义,这里只是简单做个记录。 代码写的比较乱,就不拿出来丢人了。

阅读全文…( 本文约 1522 字,阅读大致需要 4 分钟 )

修复 MySQL 编码问题

| Development | #MySQL | #database | #encoding | #UTF-8

有个疑似 OCD 患者最近抽风升级了一下 MySQL 数据库,然后发现 blog 里面全都变成了乱码。

那乱码的模式一看就是把 utf8 直接扔进了 latin1 的数据库,一看 SHOW CREATE TABLE mt_entry 发现果然如此。

阅读全文…( 本文约 265 字,阅读大致需要 1 分钟 )

如何:转换旧式编码的MySQL数据库到UTF-8

| Development | #convert | #i18n | #MySQL | #unicode | #utf-8

最近帮公司的一个客户做了一个数据库迁移,客户声称数据是 utf-8 的,然而在使用过程中出现了许多乱码,检查发现数据并非 utf-8,而是 utf-8 编码之后的 big5,而排序方式更是混乱不堪的默认的utf8-swedian-ci

MySQL的国际化支持很差。MySQL从 4.1 版本开始大刀阔斧地进行了不兼容的改动,简单地说,这些改动让相当多的操作默认以UTF-8进行,然而这会给旧的应用程序带来很多问题。许多文献推荐使用 SET CHARACTER SET 作为 workaround,尽管这能够解决一些问题,但这种做法本质上会导致 MySQL 进行额外的转换,因此并不是十分理想。

阅读全文…( 本文约 831 字,阅读大致需要 2 分钟 )

Sun收购MySQL AB

| Others | #acquire | #MySQL | #Sun

今天早上MSN上收到的消息,Sun公司宣布收购了MySQL AB,中午又听说,Oracle收购了 BEA。今天是什么日子啊……

参与评论