• 打开 module
• 生成 IV
• 得到 key/密钥/密码
• 初始化（引擎？）
• 进行加密操作
• 关闭（引擎？）
• 重新初始化（引擎？）
• 进行解密操作
• 关闭（引擎？）
• 关闭 module

加密、解密放在了一个代码片段中，大概是想说，加、解密就那一句代码不同而已。

按照这个理解，为了使用方便，我把加、解密分解成了2个函数，内容都和例子差不多，不会有错。但一运行，不管用哪种加密算法，都会出现奇怪的解密后与原文不一致的错误。还不是完全不一致，后面大半段内容都是正确的，比如原文是包含 a-z 26个字母的字符串，运行结果如下：

$ ./mcrypt.php 
Encrypt:
M~<5¶¤Jw^TÝ×. ÃV¯
Decrypt:
Âò¹ÁIijklmnopqrstuvwxyz

好一通找原因，最后在支持算法列表页面中找到这么一句：The IV must be unique and must be the same when decrypting/encrypting.加、解密时所使用的 IV 必须相同。

昏，例子代码中 IV 是使用随机数生成的，分成2个函数之后，加、解密操作生成的 IV 肯定不一样，这就是解密失败的原因。mcrypt_create_iv() 函数文档页面的 user notes 中有位 Chris 还对 IV 纠正了一些错误观点。

综上，正确解密需要将 IV 与密文一同存储、传递。而我的需求比较简单，就没有必要这么作，反正 IV 也不需要保密，所以直接用 key 的 sha1 值的片断，比如前8位（与 git 版本号简写类似）作为 IV，对安全性影响不大，应该是可以接受的。

问题解决，收工，有和我一样吃过亏的同学么？

Related posts

• 真正的“AI”，是不是可以这样？ (3)
• 用php_screw加密PHP代码 (0)
• 更安全的原因所在 (1)
• 忙碌的5月 (10)
• 向太空移植生命 (4)

这个项目我最终选择了用PHP来作，原因不再说了，正确性让时间去证明吧。工作内容大体分两部分，一个比较简单的子系统和另外一个大一点，逻辑关系和计算规则比较复杂，专业性也较强的子系统。之所以说是子系统，这次开发的内容仍然要和原来.NET的系统一起使用，换个说法就是只升级了一部分，而原来的系统就是.NET和Java混合着用的，现在.NET、Java、PHP全到齐了:-)。

因为只是子系统开发、升级，所以用户管理、验证部分仍然使用原系统中的，省去了这部分的工作量，但需要作一些焊接的工作。

数据库方面，原系统仍然使用Sybase，新系统换到mysql库，为此专门搞了一个单向同步数据的模块，放到cron中每隔5分钟执行一次，效果还可以接受，同步过来的数据也算是对原Sybase的一个备份。不过库结构的命名是全新的，并且除字典表以外，主键全面从identity转向uuid。自定义的uuid按时间排序，还分配了可自定义部分，目前感觉使用效果应该比identity要好，还是需要时间证明了。uuid的调试是麻烦些，需要一点小技巧和烂笔头，还有phpMyAdmin这个好工具。

时间上，大概是从4月初开始的，刚开始连我4个人，其中1个PHP还没学会，另外2个是今年的应届毕业生（项目过程中，5月底左右，才完成论文答辩，领了毕业证）。我除了项目还有其它工作，刚开始帮他们起了个头，中间一直到5月中下旬才全面投入项目。PHP还没学会的这个后来主攻文档和测试、项目协调。

一开始花了大概10天的时间构建系统框架、连入adodb，smarty等类库，以及非常重要的开发规范制定。然后开始作那个比较小的子系统，一来可以不断完善系统框架，二来也算是锻炼队伍。原计划4月底完成，拖到了5月10号左右。

然后开始较复杂的子系统，由于时间太紧迫，又请了两位外援，一位是几乎全能的老手，除了专业业务不熟悉，别的前、后台都没问题，另外一位是一年经验的PHP开发者，速度虽然略慢但代码质量还可接受。

从5月15号开始，几乎是封闭式开发了，每天除了吃饭睡觉和大概一个小时的休息（乒乓球）时间，每天都工作到24点以后。原计划5月底开始测试（并非完成），跳票到了6月10号，还算是在可接受范围之内吧，只是一些非重点非必要的辅助功能都被我们留在以后作了。

项目基本上就是这些情况吧，谈几点感受：

• 石家庄这种鬼地方，一半用户是微软的盲目崇拜者，一半用户是Java的盲目信仰者，PHP及其它开源技术的土壤简直就是盐碱地。
• 在较成熟的PHP应用环境下，或者开发团队中有PHP熟练者的情况下，即使是.NET和Java的高手也是可以快速熟悉起来产生生产力的。
• 不要信仰工具，不管是用什么开发工具，没有我们后来请的两位外援，再有2月也拿不出东西来。
• 工作经验的确很重要，不仅仅是工作质量的差别，毕业生和有工作经验的人相比，工作精神、压力承受程度、解决问题的思维方式都有很大差别的。好在我们的团队成员在工作态度上还都是一流的，这一点我得感谢他们。
• 欠缺的知识：在开发工作量测量、开发时间测量上还没有太好的方式，代码质量也没有很好的检查方法。需求表达、结构设计基本上靠文字描述和口头讲解（当然也有时间的原因），没有趁手的case工具。数据库结构设计和维护从原来的PowerDesigner又回归到了原始的sql文件+维护版sql文件，感觉用起来虽然不太方便，效率也不低，多服务器的环境下尤其好用。
• 花一些时间搭建高仿真的测试环境很重要，我们的测试环境已经运行了3年多，系统和数据都是和生产环境一样的，对开发起到了很好的作用。
• 拍脑门定工期的方式真的是后患无穷，但也没有更有说服力和科学依据的更好方式，头疼，系统分析这块当年没学好，就是学好了这么多年的发展也用不得了。

小结：很辛苦，但有所得，也很快乐，按照葛优的话说就是即完成了任务，又锻炼了队伍，呵呵。

与所有默默开垦盐碱地的同志们同勉，并对给予我默默支持的家人和同事致以无限感激。

Related posts

• .NET还是PHP？ (6)
• Intrepid中的php-sybase凑合能用了 (0)
• adodb5连接sybase的一个错误 (0)
• 选择Eclipse PHP Development Tools(PDT)作为PHP开发工具 (8)
• Ubuntu从Gutsy升级到Hardy，php5-sybase又掉链子 (2)

我走的是超级堡垒路线，专注于发展主星（这样省事嘛），其它的星星都是太太往这边拉货，星上什么都不留，包括防御。主星位置是5，缺点就是太小（已经升了5级地形改造器了）：

直徑  12.800 公里 (  182  / 188  方圓 )
氣溫  大約 27°C 到 67 °C

现在已经是发展的后后期（满天的死星飘啊飘）了，每一个方圆都很重要，所以，我面临着选择太电还是核电的问题。

一般来说，大家都倾向于选择太电，原因很简单，核电费重氢，太电什么都不费，并且到出引力科技的时候什么电都不够，要用一大堆太阳能卫星来补充能量(我就放了8188颗)，有了这些卫星，反倒什么电厂都不用了。所以一般的讨论中，核电都是造几级就停止的。

但现在是后后期，情况就有所不同了，首先太卫随时都有可能被打掉，到那时资源也没有电也没有，就等死了，所以不能单纯依赖太卫。

再来比较一下太电和核电，官方给出了核电产能的计算公示：

30 * [核電廠等級] * (1,05 + [能量科技等級] * 0,01) ^ [核電廠等級]

那么按照我能量技术12级来计算，15级核电产能4738.50，20级核电产能13860.00，24级核电产能31168.80。

太电产能和位置有关，我是5号星，现在24级的太电，产能4727，只相当于15级核电的产能，相差9个方圆；即使是升级到了32级，也只和20级核电产能相当，而方圆相差也到了12个。

再来看核电的消耗，现在的6级核电消耗重氢107，而我26级重氢分离器产能是3550，这还是在5号温暖的星球上，这样看来，核电的消耗是非常少，能够省出来方圆，多升一级重氢分离器，就够升几级核电用的了。

所以，出于方圆的考虑，我决定废掉太电，专门升核电，省下方圆种田，嘿嘿。

另：发现另外一款游戏特洛伊，也是仿Travian的，感觉不错，已经注册，重新开始种地中。

Related posts

• 真正的“AI”，是不是可以这样？ (3)
• 更安全的原因所在 (1)
• 忙碌的5月 (10)
• 向太空移植生命 (4)
• 可恶，被 PHP-Mcrypt 的官方 Example 误导了 (6)

这是以前开发、现在用着的一个web系统，类似mis的一个业务系统，他的一个相对独立一些的子系统（和其它部分联系也有，但比较少）。原先使用JSP/java开发，现在维护和开发都没有java的人了，所以必需要换开发语言。系统的逻辑处理相比之前有不少变化，但大的过程没有动，UI方面也有许多需要改，并且想更换数据库，把以前写在存储过程中的逻辑搬出来，便于维护。系统平台方面，虽然都是跑在apache/tomcat下，但以前是windows平台，打算迁移到Linux下。大概就是这么个样子吧。

支持使用.NET、不用PHP的理由有：

• 开发团队对.NET熟悉、熟练。
• 系统平台的切换可以以后再作。
• 开发时间太紧、任务不少，用PHP还要现学，怕完不成。

支持使用PHP，不用.NET的理由有：

• 坚持大环境的转换（从windows到Linux，不考虑mono之类的东东）。
• 以后再作=不作，能用的系统谁没事出钱让你再改一遍？
• PHP学习很快，有人带。
• .NET对维护不利，和svn配合不畅，在运行处无法直接修改小错误（必需编译，开发方不在现场，响应速度满足不了需要，当然只是在说小错误）
• 优先将紧急的任务先完成，争取到一些时间后再完善周边功能。

其实老实说，主张使用PHP是带有一些个人色彩的，但我觉得开源、Linux是大方向，及早动手对以后的工作有利，并且Linux下的管理明显要比windows要方便很多，对于要使用几年的系统来说这个投资应该是很“值”的；并且我也主观臆断一下，开发方在学习新的开发语言上是有“惰性”的，毕竟现在的人员配备都是.NET系的，学习不光耗时耗力，可能还会牵涉到人力成本的上升。

矛盾一：任务、时间、质量。 矛盾二：仅仅是完成任务 VS 系统平台迁移的总体部署 矛盾三：如果我有时间，那我有能力和信心让PHP发挥出应有的威力，可我既不属于开发方，也没有足够的时间（当然一些辅助性的工作或帮忙还是没有问题的）。

该如何选择呢？我这里虽然人少，但应该都是技术圈的人，大家给出出主意吧，或者转到其它人多的地方也行（恕我很少跑坛子），如何使PHP在短时间内让几位.NET系的开发人员学会，并做出质量不太差的系统？

开发方人员有code基础，我这里有些PHP经验，但现成可用的架构没有，adodb和smarty是肯定要用的，系统架构难道不成现搭一个？头疼ing。。。

传统的IT企业真的是在windows上“陷”得太深了，开源的路依然漫长哪~~

Update @ 2008-06-13

我们的选择结果: 忙碌的5月

Related posts

• 忙碌的5月 (10)
• 针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS） (3)
• 配置安全的共享web服务器（抛砖引玉） (4)
• 选择Eclipse PHP Development Tools(PDT)作为PHP开发工具 (8)
• 让phpmailer支持中文名称的附件 (5)

换一个思路，太空中到底有没有生命？虽然现在理论上已经“证明”了这一点，可谁也拿不出有效的证据来。UFO的传言也时常出现但众说不一，美国51区依然神秘。与其这么麻烦，我们为什么不把地球上的生命“传播”出去呢？现在知道的就是原来抛出去过一个留声机什么的，那玩意儿搁现在的地球上都落后了，天知道能被外星人当什么看。再说了，茫茫宇宙，找个星星都困难，发现一台小机器的几率又有多大呢？

所以啊，想增加发现或者被发现的几率，弄不了太大的东西，只能靠数量补，搞“人海战术”了。最小的生命体大概就是细菌、病毒什么的了，这些东西体积又小，又不值钱，最重要的，适应能力强，高温黑暗无氧都难不倒他们，把这些东西传播到太空中，让他们随宇宙里的各种“风”四处传播好了。

不用担心这些东西再被重新传播到地球上，给人类带来什么危害，因为他们本来就产生于地球，既然以前我们能够对付他们，将来也能。

这样一来，也许在将来的某一天，某处的外星人会收到来自地球的礼物，凭借他们强大的科技，追本溯源找到我们，岂不皆大欢喜？另也许在将来的某一天，当我们的后代的后代的后代与外星人相聚的时候，他们会说：“我们在800x年爆发了非典疫情，在900x年流行禽流感，合着都是你们地球人搞的鬼啊？”，呵呵。还也许在将来的某一天，我们会登陆到一个陌生的星球上，发现与我们同一起源，但随着完全不同的进化过程形成的“新人类”，和我们的远方亲戚亲密接触不知感觉如何。

涉及到地球上最早的生命体的问题，有一说是“古菌、细菌和真核生物”，并不影响我的想法的施行，不管科学的答案怎样，扔太空里就是了。一公斤就能装很多哦，超值的“大礼包”。

你能一眼找到下载链接在哪儿么？

Update @ 2010-08-29

请看这里：微生物在太空存活了553天

Related posts

• 真正的“AI”，是不是可以这样？ (3)
• 更安全的原因所在 (1)
• 我的Ubuntu Linux空间占用情况 (5)
• 忙碌的5月 (10)
• 可恶，被 PHP-Mcrypt 的官方 Example 误导了 (6)