我的天

昨天，知道了原来我们粮库也有网站，迫不及待地去观摩一下。汗！我用的是FF，结果呢？中国人做的网页就是对IE以外的浏览器水土不服，于是，汗，再汗……

网页是个需要测试测试再测试的东西，内容当然很重要，但如果不同用户不同浏览器出来的效果不一样呢？杯具……在中国人设计的网页中，非IE不可是习惯性真理性的，比如说大名鼎鼎的备案网站，又比如同样如雷贯耳的网上支付网站，巨汗！地球人都知道IE的安全性不好，速度不优秀，但，勤劳勇敢机智过人的中国人就喜欢用系统自带原汁原味，甚至还没经过升级到7或8的IE，果然是微软的忠实粉丝啊！

但，我们某些人的思维是发散的，面向的是世界各地的盆友。在外国盆友设计的网页中，基本上FF横行，是推荐用浏览器，比如说我用的WP模板的作者。显然，他老人家视IE为无物。请看下图：

这是IE的截图。

这是FF的截图。

左图是我千辛万苦经过修改后的IE适应版，右边是原版。杯吧，原版在IE下，3栏的设计都变成2栏了，2个侧栏“被迫”挤到了一块，肯定是和背景不搭调的，揪心啊！

为了挽救这恐怖的杯，我首先请来了Firebug大人。

模板，显然，是div的，样式肯定是CSS的，而问题就发生在content-body、content-sidebar-2和content-sidebar里。首先，我在content-sidebar的CSS里加了一句“float:right;”，解决了content-sidebar在IE里跟在content-sidebar-2屁股后面的问题，实现右置。但为什么升不上去呢？难道因为太窄？我尝试修改过很多宽度都不行，看来不是位置不够的问题。会不会是content-sidebar里有“clear”的命令呢？应该不会。如果有的话，在FF就不会正常了。中间部分三栏设计，我们可以用3个float来解决问题，于是我试探性地在content-sidebar-2里加一句“float:right;”惨了，占到了最右方，当然，因为它的层在content-sidebar之前，理所应当占最右边。那如果改为“float:left;”呢？我的设想是它或许会正常，如果content-body已经设定为“float:left;”的话，怪异的是，在IE下正常，在FF下content-sidebar-2抢到了正文的左边。问问Firebug，虫子说content-body里有个“float:none;”的设置。怎么可能，我已经把CSS文件里所有content-body都加上“float:left;”，怎么有可能还是“float:none;”！！！！但如果不存在，Firebug不可能爬虫出来，到底在哪里呢？无计可施之下，找起了网页源文件，居然，居然被我在网页头部找到这等东西！！！

实在太杯具，灰常杯具啊！文件头，居然放在文件头，无语了。在WP的header里找，没找到，最后终于在function里找着，我的老天，该死的“none”！于是，终于用3句float解决了IE怪异的效果，让中国人看到的效果和外国人相似。

哎，如果大家用订阅的话，版面什么个鬼样又有什么关系呢。

昨天晚上我是凌晨一点回去睡觉的。

今天晚上我是凌晨一点离开办公室的，还没洗澡，躺在床上的时候已经是凌晨一点半。

我很累，在上班时间里被检验、文档排版、数据抄写榨干。下班后，成为小村屋群的义务核心技术员，被代码转化和CSS修整榨干。CSS修整本是很简单的事，FF+Firebug+css code就能得心应手，需要做的就只是修改和刷新，但是，偏偏某村友的blog用的插件却把该死的CSS可视化了，分开一小段一小段，加上说明，却不显示最最原始的代码，还得让你一个个翻，要多按好多次保存，还经常会找偏。结果最后我气了，直接用Firebug去找我要找的地方，在自定义的CSS里敲打一番，嘿，终于可以了，真邪恶！

今天的重头戏是帮一位有困难的村友搬家，听村屋首领说他帮忙搬的时候失败了，于是，在危难的时候，当大家有需要我的时候，xrspook挺身而出了！接到从BlogBus弄出的代码，马上用Python转换，得出如下结果：

很诡异，我之前遇到的错误代码可不是这样的哦。我第一个反应是时间有问题，应该是某个设定的时间不对劲，但到底在哪里呢？94、268、371、376（此数字为行数）我都排查过，没有。于是，我第二个反应是人肉排查替换。把376以前的先删掉，转换后面的。OK，没问题。再把前面的转换，同样结果。接着，把94-376的删掉，转换94以前的，一切正常。然后，把94-376的转换，嘿！还是那个界面，但现在根本就不存在376啦！所以我意识到从那些行根本不会找到突破口。重复以上操作大概3、4以后，剩下3篇文章，卡住。剩下2篇！最后一篇！肯定是这里的问题。村友们，你知道我发现什么了吗？见下图：

LogDate包围的日期居然是0000-00-00 00:00:00！！！！难怪Python会报错！而这等事情是怎么发生的呢？fish故意的吗？不是，是BlogBus可以算bug也可以不算bug的地方。为什么这么说呢？因为我是那种在记事本写完日志往blog上贴的人，记事本时间提取是用F5，只有yyyy-mm-dd hh:mm，而BlogBus的格式是yyyy-mm-dd hh:mm:ss，所以，我就要把前面的粘上去，留默认的秒数，但如果我一不小心粘错粘漏了呢？BlogBus会默认把时间设定为0000-00-00 00:00:00！于是，发现新文章不见了的xrspook就会翻到日志的最后一页把那个莫名其妙的日期改回来。大概当时fish没发现这等问题，以为是自己出错了就没去理会，所以，导出数据中就存在了个那么匪夷所思的日期。程序是认规律不认人的，它觉得年一定是从1开始，月只有12个数，日是1-31，若超出范围，它就笨蛋不懂了，前提是，它不会BlogBus的日期潜规则，若有人让它增强读取BlogBus的潜规则并把那个诡异数转化为转换当场时间的话，杯具就不会发生。所以，看来很严重的问题，把几个0改为正常数就行。解决方法很简单，但查找就异常曲折。成功那一刹那我是多么的高兴啊！！！

信心满满地把转换好的数据传给村屋首领，却又出现怎么都导入不了报错的现象。难道fish就那么背？在多次尝试，包括重装WP之后，首领提出会不会是导入.xml的格式不对，解释错误导致报错？接着，我发现他装的居然是2.8.5，我转换用的是2.8.6啊！转出来的数据适用于2.8.6后（即2.9系列），新数据导入老系统，不错就见鬼了。于是，我把经过一层转换的导进去，问题解决。大功告成，村友们，我们狠狠地拥抱一下吧！

以前都是自己解决自己的问题，或者请求别人解决自己的问题，但这次居然是xrspook帮助他人解决问题，真让人有飘飘欲仙的感觉。几个即时通讯工具闪个不停~~~

妹爱的不是钱，妹爱的是成就感！

于是，你知道我为什么乐了:)