比特客栈的文艺复兴

更新：本文的争论告一段落，3月初在IEblog上的做出回应，宣布默认使用IE8的标准渲染模式，撤回了之前默认为IE7渲染模式的决定。（真讽刺） 试问各位旅客最近听说了IE的哪条新闻？是Opera对微软藐视W3C标准的控告，还是IE8内测版突破ACID2渲染测试的公告？或者更进一步，你甚至留意到IE8与它那最新功能：神奇的Version Targeting？无论如何，IE7带来的各种用户怒吼是微软所不希望承受的，而Version Targeting是他们的妥协方案。 停，请停下，Version Targeting是啥？为什么我要在意它？ 事实是微软提出的Version Targeting（店长暂译“指定版本”，简称VT）就是为了让你意识不到它的存在。IE开发组的Chris Wilson在上面链接的文章中解释了IE8中的VT工作方式： 1. Quirks mode（当html文档缺乏标准doctype时的渲染模式）的工作方式不变； 2. Standard mode，IE8将默认沿用IE7对标准页面的渲染模式； 3. 网络上暂称Current ("Edge") mode，懂得标准的网页开发者将可以通过meta标签/http请求的header信息定义IE8使用最新的渲染模式。 简单点说，假设IE8正式版的渲染引擎真的通过了ACID2测试，也需要开发者额外添加一条meta信息它才会启用这个新版本引擎，否则浏览器将自动沿用IE7当前的引擎。撇开Opera的指控不谈，这是微软的又一个阴谋吗？ 微软启用VT的对外理由非常简单：兼容性。他们的论点是在IE6向IE7的过渡中用户反映了大量网站不兼容的问题，这是由于（引用Chris的原文）“网站开发者期望IE7的工作方式与IE6相同，即便是在标准渲染模式下。”换句话说，由于大多数开发者无意识的使用了标准doctype，使得经典的渲染模式开关不再有效，为了不影响这些网站的使用，IE8必须继续沿用IE7的渲染引擎为默认引擎，以避免进一步造成混乱。 信不信由你，“新瓶装旧酒”，居然在“为了兼容性”的言辞下变成了用户友好的新功能。现在你该明白为什么有许多新闻说IE8有“三个渲染引擎”了，多出来的一个应该是IE7正在使用的Trident V（如果微软不是在忽悠WaSP）。 对于微软启用的“新标准”，网络上自然又是各家自有各家的说法。对网页标准感兴趣的旅客一定听说过PPK，Eric Meyer和Jeffrey Zeldman的大名，有趣的是，长期与微软争锋相对的他们这次非常和谐的站在IE的一方。WaSP内部的意见也有很大分歧，很多成员是在ALA的两篇文章发布之后才知道是WaSP的领头们构思了这个Version Targeting的建议。 支持方的观点（目前占少数）—— 没有VT的支持，IE开发团队根本没机会考虑标准化和持续更新的事情，因为新版本总在破坏网页渲染的模式（换句话说，不要说IE6，连IE7都距离W3C标准太远，持续更新引擎会让开发者/用户陷入困境。提供更新反而导致IE市场占有率下降，那领导们当然宁愿不更新引擎）；- Eric Meyer Version Targeting保护不懂网页标准的开发者与用户，这相比要求他们在一夜之间学会网页标准更加实际（如果IE团队选择不支持W3C标准，那标准也就失去了意义）； – Jeff Zeldman VT既然是微软开发团队自己接受的标准鉴别模式，那它应该100%工作，并且不影响其他浏览器，我们也无需再劳烦使用不稳定的浏览器嗅探。 – PPK 反对方的观点（目前占多数）—— Version Targeting将阻碍Progressive Enhancement的发展，放弃默认支持更标准的设计，反而选择继续蒙骗不知情的开发者，暗示旧渲染引擎的行为是“正常”的； – Jeremy Keith 对开发者的“伤害”被夸大了，IE8的新引擎不会在IE7之上造成更大破坏，不使用doctype的产品也不受到新引擎的影响； – ALA上的留言 微软应该将金钱与时间用在宣传标准与教育用户上，而不是号称“亡羊补牢”的将标准与兼容性联系起来……这是IE五年无引擎更新带来的后果，应该由微软自己承担； – Chris Heilmann Quirk mode本来就是个向标准化过渡的产物，如果IE8还在引入“异名同义”的新Quirk [...]

更新II：如果你能看到本页面，恭喜，转移已经完成。 更新I：域名转向接纳，进入第二阶段。客栈两年的影片打包在此（使用了国内jsharer空间，顺便宣传）下载有两种办法，使用下载密码bitinndl（问题重重……），或者直接注册帐号来下载，压缩包的密码是bitinn；国外的同学们，直接到影片页面上下载更快吧…… 空间已经到位，域名重定向开始。 至于我到底喜欢那个服务商多些—— Bluehost：成熟，傻瓜化，读取缓慢，部分虚拟服务器被封； Powweb：便宜，自定义，读取较快，所有虚拟服务器被封； iPower(iPowerweb)：廉价，高响应，渣服务，居然没被封； MediaTemple：贵价，服务佳，不够稳定，虚拟服务器暂安。 所以的确没有特别好的选择，服务商都有自己的“隐藏限制”，不测试是不知道的，所以选个没被封的就好了。 由于客栈本身（WordPress系统）是本次转移的重点，从iPower的MySQL4.0到MediaTemple的4.1花了点时间处理latin1表内使用utf8字符导致的乱码，网上的教程很多，稍微总结下。 1. 使用WordPress专用插件WordPress Database Backup备份数据，尤其是在2.2之前就开始用WP的同学：WordPress数据库默认为latin1，WordPress的数据却是utf8，所以通过phpmyadmin输出的备份一般都会是latin1，自然乱码；相反Backup插件以数据编码为准，所以会输出utf8（否则先要自己去转数据库的编码，即便成功了，也可能导致你当前安装显示乱码）。2.2之后使用默认安装不会有类似问题。 2. 确保备份没有乱码后，要进行MediaTemple上对应的设置。使用后台系统新建数据库，则数据库的默认编码为latin1，校对会使用latin1_swedish_ci，这样导入utf8备份也会乱码。MySQL4.1服务器（Server），数据库（Database），数据表（table），数据链接（connection）都有独立的character set，所以即便phpmyadmin里显示服务器使用utf8编码和utf8_general_ci校对，数据库的编码也可能不同。 3. 要解决第2点带来的问题，在新数据库上用 ALTER DATABASE name CHARACTER SET utf8; 后再导入数据就可以避免乱码了（设置服务器默认校对为utf8_general_ci，也可以在上面的查询语句;号前加入 COLLATE utf8_general_ci 来强制）。 4. 我见到不少网站引用了桑林志的一篇老文章，要提醒下加入SET NAMES步骤在WordPress 2.2之后是多余了，开发团队已经解决了相应问题。 5. utf8是推荐编码（MT上这是默认，WordPress 2.2+的默认也是它），不要使用gb2312或gbk，尽管它们减省数据大小，但会对导致各种各样的字符问题。 大概就这样，还有什么更新会在这里添加，祝我好运orz。 tbc.

更新：原来的Anime Connection风格已经发布，WordPress使用者请自行去抓。 iRoll 设计这个主题的原因是想测试自己到底能给网页减多少负，提多少速，并在保持原来风格怪异的基础上省点带宽费用。基本的设计参考有两个，我自己的知识和MDC上的Tips for Authoring Fast-loading HTML Pages。原文是英文，这里大致解释一下以供各位参考。

美国之旅热火朝天进行中，新落脚点总算有点Wireless的迹象，晚上空闲之时干脆填坑。其中确认要回锅的是早前因为收视率不佳暂停了的《10万个“你知不知道其实……”》系列，本次到米国取材也是为了让它起死回生。 （话说店长的Bloglines已经有许多网站的新文章数量达到了200上限，抓虾则惨不忍睹的有17,011篇新文章未读……4月初只能烧香拜佛了……） 除去重开旧系列，四月客栈会继续胡扯我们最关心的三个话题——动漫，科技，网络；以及年轻一代如何被它们所毒害XD OK，先给各位提供点头盘暖暖身，活动一下胃部肌肉。 4月话题之一：CC与动漫。 这里CC可不是某个动漫界的Pizza Hut代言人，我说的是Creative Commons（创作共用），2月底CC官方发布了其许可协议3.0的版本，其中的部分更新，例如强调对协议的正确使用和对其他开源协议（例如GPL和FDL）的兼容都是值得关注的进步。 但CC和动漫界有什么关系？最近知日部屋的一篇报道（撰文：小櫻的Kero）浅显的剖析了CC在今后数年内可能对香港乃至大陆产生的影响，我认为该说法大可扩展到亚洲。无论是版权黑洞的中国还是作者也被蹂躏的日本，都急切需要加大推广CC协议。 日本动漫之所以能迅速发展，P2P软件和YouTube功不可没。倘若凡事DRM，天下皆为Copyrighted，同人创作恐怕也会举步为艰。虽然像Leaf这样的游戏公司有专门设立二次创作规定，但日本的CC距离实现商业作品合法共享依旧还有很长的路要走，同人网站上时常出现的中英韩三文图片警告也是人们缺乏对CC了解的结果。 动漫版权，本可以很简单，如今却在盗版和共享的分界线上飘摇不定，值得反省的不仅仅是用户，也包括作者，网站编辑，版权持有者和团体。在模糊的界限上犹豫不决者，最后将被网络所抛弃。 4月话题之二：Flash与Javascript。 Flash还是Javascript？在Web2.0时代走入家庭前Flash是很明显的选择，但随着主流浏览器的Javascript引擎完善，新的互动页面更多在采用Javascript作为奠基石。 Javascript相对Flash的优势除了拥有更好的容错能力（Degrade Gracefully）外，对搜索引擎的完全支持也是新网络重点。目前除了Google外的搜索引擎都没宣布支持Flash文件内容引索（这里指Flash文件中的内容，包括文字和连接），对于针对Yahoo、Live平台乃至百度进行搜索优化的网站，使用Flash将会失去展示珍贵内容的机会。另外Javascript+XHTML还是走向语义网络的第一小步（Web Semantics一向是万维网的大课题，作为连接人与机器之间的终极桥梁，语义网络既是HTML，更倾向于结构而不是语义的前辈的接棒者，也是Web 3.0的可见走向。） 如何利用Javascript做出同样清新的网站将会是2007年的话题之一。而我们希望能帮助更多网主脱离“门户”般的恶心设计。 4月话题之三：传统电视与P2P电视。 随着网络人口的膨胀，通过传统服务器传播多媒体的方式逐陷困境。网络评论已经说过YouTube不会有第二个，没有足够资金，任何传统网站都会倒在用户面前。而P2P可称作是“穷公司”的起家诀窍，用户在享受内容的过程里也成为无形的服务器，对于商家来说是减负的绝妙之道。 但不要忘了我们说得可不是什么个人影片，这可是早已商业化的电视频道。电视的廉价对应网络的廉价，人们真的会选择P2P吗？Joost作为Skype母公司的新产品，到底有没有打入亚洲的潜力？店长试用一个月的答案很快就会有分晓。（目前的感觉是潜力无限，尚需努力。） 目前预定如上，各位4月见。～

  有时间人是喜欢自我折磨的。 今天复习到此结束之余，顺便帮Wakaba做了个中文翻译。（真奇怪了，竟然这么久都没人做它的翻译，估计是Pixmicat!太出名的缘故） Wakaba是Futallaby贴图版程序的继承者（Futallby本身则是由日本双叶频道演变而来的贴图版程序之一），Wakaba和Futallaby最大的不同在于Wakaba是用Perl写出来，理论上应该比PHP下打造的Futallaby更加有执行效率。 （Perl的易用性和安全性都要比PHP稍微优秀一些） 目前Wakaba是iiChan的源程序之一。 Wakacba汉化包下载。 已经发给官方人员，不过这里先放出来备用好了。 同时包含了简体中文和繁体中文翻译。有好的建议请留言。 [更新]演示站点——比特客栈的通缉名单