<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>Fwolf's Blog</title>
	<link>http://www.fwolf.com/blog</link>
	<description>随心·随意·随缘·努力～</description>
	<lastBuildDate>Tue, 29 Dec 2009 14:58:13 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>可恶，被 PHP-Mcrypt 的官方 Example 误导了</title>
		<description><![CDATA[在看 php 的 mcrypt 加密，想使用对称算法，解决小块内容（比如 url、post）网上传输的安全性。即加密、解密用同一个密码。官方文档有个非常完整的演示功能的例子，大概顺序是：


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


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

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

$ ./mcrypt.php 
Encrypt:
M~&#60;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，对安全性影响不大，应该是可以接受的。

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

	Tags: crypt, encrypt, mcrypt, random, think, [...]]]></description>
		<link>http://www.fwolf.com/blog/post/450</link>
			</item>
	<item>
		<title>Flash 无法修改设置的问题</title>
		<description><![CDATA[

这个怪怪的问题也不是一天两天了，就是 flash 设置窗口，或者当 flash 游戏需要使用本地存储空间时，自动弹出的设置窗口，这个窗口无法用鼠标点击，用键盘 TAB 键能在各部分之间游荡但还是无法调整设置，基本上就卡死在这里了。

遇到这种情况，可以访问这个链接：http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html，注意链接中并不是图片，而是实际的设置调整组件。比如刚才说的访问本地资源需要确认的问题，在这里设置成Never Ask Again，同网站的资源就再也不会弹出窗口导致 flash 卡死了。

Ubuntu 9.04, Firefox 3.0.13, Flash Player 10.0 r32.

参考：


Adobe Flash Player &#8230; Settings Manager


	Tags: flash, Problem, setting

	Related posts
	
	机房搬家过程中的几件趣事 (0)
	升级到8.10 intrepid过程中libc6依赖性死循环问题的解决 (6)
	[ubuntu]安装vmware时找不到c header files的小问题 (3)
	Windows安全更新KB951748可能导致dns无法解析 (1)
	Vim的奇怪问题 (0)


]]></description>
		<link>http://www.fwolf.com/blog/post/449</link>
			</item>
	<item>
		<title>Git 合并 patch 时的冲突处理一例</title>
		<description><![CDATA[git version 1.6.0.4

几个新手刚刚开始接触 Git，为了维护核心仓库的“纯洁”，避免太多无关信息被误提交进仓库（再次批评一些图形化工具默认的“Select All”），采用了核心仓库只读，邮件提交 patch，审核后再提交的工作流程。

期间有时会遇到合并冲突，正常的原因一般是未及时下载新版本产生了冲突，特殊一点的原因是手工修改 patch 内容导致的。有时候看注释写得不够准确，忍不住就改了，有时候是 Geany 保存时自动去除了 patch 原文中的行尾空格，有时候是文件回车格式、BOM 等变动了，总之合并 patch 的时候，如果生成 patch 的“原稿”找不到，一般就产生了冲突，比如：

$ git am 0001-BUG-Sybase.patch
Applying: CHG: 读取Sybase如果时间为空,设置默认时间的修改
error: patch failed: source.php:38
error: source.php: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore [...]]]></description>
		<link>http://www.fwolf.com/blog/post/448</link>
			</item>
	<item>
		<title>压缩网页图片</title>
		<description><![CDATA[不压不知道，一压吓一跳，大部分图片几乎都能在近似无损的情况下压缩掉 65% 原始大小左右，如果指明有损压缩，比如 jpeg 的 85 %，还能更小。

Smush.it

smushit 现在已经属于 Yslow 的一部分了，可以通过 firefox 插件使用，也能在线用，缺点就是你的图片必须能够从公网访问。

可以压缩各种图片，按照官方的解释，它会尝试各种工具和算法，找到最优的方式。因此，smushit 是一种很安全的压缩工具，几乎看不到差别，就是用起来麻烦些。

imagemagick

不同的图片格式有各自的特点，比如 gif 善于存储颜色较少的图片，也是动画图片的首选；png 善于存储能够矢量化的图片，jpg 则善于存储颜色、图片变化都比较多的图片。根据不同的图片特点，进行类型转换，有时能收到不错的效果。

图片 convert 之后，还可以利用其它工具进一步压缩，不过效果不大了。

另附一个转换图片类型之后，批量替换模板中调用文件名的脚本：


grep logo.gif * -R &#124; awk '{print $1}' &#124; sed 's/://' &#124; xargs -I '{}' sed -i 's/logo.gif/logo.jpg/' '{}'


jpegoptim

这是今天刚发现的好东西，ubuntu 源中有，主要可以用它去除 jpg 图片文件当中的 comment exif IPTC 等无用标记，我测试的情况压缩率比 smushit 略低一点点。由于能够通过命令行使用，所以易用性更强。

一般我喜欢用 --strip-all 参数去除所有无用内容，实际压缩之前可以用 -n 参数预测一下压缩率（默认直接压缩覆盖源文件了），24bit Adobe 类型的图片基本上都能够压缩掉 65% 原始大小，碰到 24bit [...]]]></description>
		<link>http://www.fwolf.com/blog/post/447</link>
			</item>
	<item>
		<title>[Git]初学者注意事项</title>
		<description><![CDATA[实在是受不了有些人的 Git 提交，费大力气“回滚”，遂整理了这些刚开始用 git 或者还没有建立 scm 概念时容易犯的错误。

和源码无关的东西，尽量不要进仓库

不得不说一些图形化软件，在提交内容的时候大多提供一个“全选”或者“Select All”功能，这是最不好的了，一些懒惰的同志看都不看就连瓢带碗都提交了。


测试时上传的文件，测试时的临时文件，统统不要
对应上一条，强烈建议把所有文件的上传保存目录另行设置，放到源代码目录以外
编辑器产生的备份文件、临时文件，编译时的中间文件，统统不要
对应上一条，有个例外就是为了实现通过 Git 更新系统，.NET 的 bin 文件要进仓库，导致那个仓库现在都 100+m 了
图片等资源文件，进仓库也可以，但应当使用有意义的文件名，便于后期管理
对应上一条，现在设计网站界面喜欢先作图然后切割，产生一大堆 001_r5_c1.jpg 这样的文件，讨厌之极
使用的外部类库，比如 php 类、js 类等，统统扔到源码目录以外，如果实在没办法要放在目录树中，也可以留出空目录，打包发行的时候再包含进来，依然不进代码仓库
不要中文文件名，主要是跨平台使用有问题，文件名完全能够只用字母数字减号下划线


尽量采用相对小、相对独立的提交

Git 是作什么用的？Git 不是代码上传工具，也不是网站更新工具，而是软件开发过程的记录工具，为了更加准确的定位每个问题、每个功能修改，就需要在每完成一部分可以称得上是“一项”的工作时，就 commit 一次。哪怕只是修改了一两行，只要产生了必要的功能改变，就有价值记录。

当采用代码审核机制或者需要用邮件提交补丁时，较小的提交能够更有效、更容易、更准确的被检查和审核，这个在 linux kernel 开发文档中也有提到。

当然不能矫枉过正，必须有可记录的改变才有提交的价值。对应的，Git 日志大多数情况下主要显示第一行，控制每次提交都能用一句话简单概括，也是有必要的。

注释格式

格式属于个人习惯和团队规范范围，有必要采用相对统一的风格。

Git 本身不允许空注释，同时建议注释的第一行写简要说明，下面留一行空行，再写详细说明。

我的个人习惯，喜欢在每条注释前面用大约三个字母来表示本次修改的性质：


Add something
Bug [fix&#124;found]: describe the bug or fix.
Chg something
Del something
Enh some treatment
New something
Tmp for some cause


为了保持语法通顺，也可以采用前三个字母后面加冒号，后面有啥写啥的方法。

最后，我觉得，能够遵守行业规范和团队约定，主动养成良好习惯，应当是鉴别人才的一项重要因素。

	Tags: git, newbie, rule, Svn/Git, tips

	Related posts
	
	Git 合并 patch 时的冲突处理一例 (0)
	针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS） (3)
	用ssh打通反向隧道，内网也可对外提供服务 [...]]]></description>
		<link>http://www.fwolf.com/blog/post/446</link>
			</item>
</channel>
</rss>
