猜猜这是哪国的英雄?

[img_assist|fid=1125|thumb=1|alt=吉尔吉斯邮票:玛纳斯雕像|caption=吉尔吉斯首都的玛纳斯雕像]
参加了一个邮寄的集邮协会,每个月都会收到厚厚的一口袋邮票,喜欢的留下并按照标价付款,不喜欢的装在免付邮资的信封里寄回去就行了。其实没有多少闲钱来丰富自己的藏品,所以每次都只是赏玩两三周,然后再把邮票寄回去,既长了见识,又不至于没钱吃早餐。呵呵,原来收集古钱币的时候,早餐钱都省了,但是古钱币的价值是Private Knowledge,往往可以低价买到珍品;而邮票的价值大多是Common Knowledge,打交道的又是集邮公司,所以不期待什么惊喜,只是长长见识。后来集邮协会发现邮寄珍稀邮票总是得不到回报,所以改变策略,每次都邮寄一部分美国的珍贵邮票,而一些其他国家的廉价邮票,这倒是合了我胃口,几十美分就可以留下一套不错的巴布亚新几内亚的纪念邮票。

昨天又收到一口袋邮票,中间有一张挺有趣的(见上图),乍一看,像是一位骑马的中国将军,不过看不清楚细节,加之注释又是斯拉夫字母,读不懂,但是看到MAHACKA一个词,Google一下,原来是玛纳斯(Manas),这么说来果然和中国有解不开的渊源了。这枚邮票是吉尔吉斯发行的,就是前阵子没有灌完的“李陵的土地”。顺便又google到了另外一枚同一主题的邮票(见下),这张邮票里玛纳斯的扮相就更像中国的一位武将了。事实上,说他是一位中国的英雄倒也无妨,毕竟他也是中国的柯尔克孜族的英雄。援引一下柯尔克孜/吉尔吉斯英雄史诗《玛纳斯》中对玛纳斯一生事迹的概括:
[img_assist|fid=139|thumb=1|alt=吉尔吉斯邮票:玛纳斯]

玛纳斯诞生前,统治柯尔克孜族人民的卡勒玛克王由占卜者处获悉:柯尔克孜族人民中将要降生一个力大无比﹑长大后要推翻卡勒玛克人统治的英雄玛纳斯。卡勒玛 克汗王遂派人四处查找,并把所有怀孕的柯尔克孜族妇女一一剖腹查看,以便杀死即将诞生的玛纳斯。但在机智的柯尔克孜族人民的保护下,玛纳斯终于在阿尔泰的 布鲁勒套卡依地方平安地降生。目睹人民的苦难生活,使玛纳斯从小就对外来的掠夺者充满了仇恨,他立志要为本民族报仇雪耻。玛纳斯还在幼年时,已成长为一个 力大无比的英雄。他同情贫穷的人民,把自己家的财产分赠他们;他参加劳动,在炎热的吐鲁番耕种庄稼。他长大后敬重长者,信任贤能,团结了四面八方的勇士, 统一了被分散的柯尔克孜各部落,联合邻近被压迫的民族,南征北战,使各族人民过上了欢乐富裕的生活。他被拥戴为汗王,成为当时被卡勒玛克奴役着的各族人民 公认的领袖。后来,他不听贤慧的助手──爱妻卡尼凯依的劝告,带着40位勇士和大队兵马,对契丹人的京城进行远征。玛纳斯在这次远征中身负重伤,回到塔拉 斯后逝世,柯尔克孜族人民重新陷于灾难之中。
[img_assist|fid=142|thumb=1|alt=吉尔吉斯邮票:蒙古包]
这只是这篇宏大的史诗的第一部,这部史诗一共有八部,讲述了八代英雄的故事,故事中提到了“北京”,但是学者认为可能是“北庭”的转音,因为北京毕竟里他们太远了,还有提到的“克塔依”人,学者认为这是契丹的转音,呵呵,不知道这里的契丹指的是真正契丹,还是泛指的江淮以北的中国。

Blog分类: 

Blog工具比较(续):Drupal的反击

[img_assist|fid=132|thumb=1|alt=Drupal广告画]

昨天提到了那篇九十多页的关于比较评论,今天发现Drupal总站的新闻中也在讨论这篇评论。昨天我翻看那篇长篇累牍的评论的时候,只是匆匆读了他的综述部分,感觉它对Drupal的评价还不错,并没有看到结尾。可是有人认真读完了整篇评论,发现了这篇评论的结束在评分的时候有不公正之嫌。譬如不支持Plugin,不支持Aggregation,不支持审批,几乎没有文档的Silkblogs居然得分比Drupal还多,并且评论的作者在以下几个方面给Drupal打了了零分:

  • 简单的多Blog支持
  • 自动Blog登录
  • 存档
  • Blog聚合(Aggregation)

这个显然是不符合实际的,于是Drupal的“激进”用户者便撰文申辩,吸引了不少人仔细阅读那篇评论文章,结果又挑出来不少问题,譬如那个评论认为Drupal不支持Ping,不支持WYSIWYG编辑器,不支持Trackback等等,这些也是不符合实际的。

讨论之中,又有人提到,这篇报告虽然声称是“独立”的,但是实际上却是 21publish请人写的,版权归21publish所有,而21publish也是参加评论的多用户blog之一,并且作者最后给了21publish很高的评分。于是更多的人开始质疑这个评论的公正性与权威性。并且有人写信给原评论的撰写者Robin Good,而Robin Good则亲自到Drupal的网站道了歉并承认自己的评分犯了错误,总算对这次讨论做了个了结。

关于Robin Good到底有没有做到真正的“独立”,实在不好说,不过同时评论这么Blog工具其实挺困难的,没有一一的长时间使用过,肯定无法全面的评估某一款Blog工具的好坏。

另外,自由软件杂志最近要给Drupal提供一页免费的广告,所以不少人都提出了设计方案,我觉得还是Chris做得比较好,他port了不少Drupal的主题,譬如Wordpress的Meiji和Kubrick等等,上面的插图便是他提交的方案。

Free Tags: 
Blog分类: 

Blog工具的新一轮比较:Wordpress 1.5 v.s. Drupal 4.6

大致看了一下Drupal网站中的新闻聚合,这阵子最热门的话题恐怕要属新一轮的Blog工具比较了。虽然也包括其他的Blog工具,但是比较的核心仍然是Drupal和Wordpress。第一个焦点是Robin Good写的长达__92页__的[《多用户blog工具的比较》(Comparative Review of Multi-User Blog Tools)|http://www.masternewmedia.org/news/2005/05/16/group_and_multiuser_blog_platforms.htm],包括了[Silkblogs|http://www.silkblogs.com],[Manila|http://manila.userland.com/],[21publish|http://www.21publish.com/],[TypePad|http://www.typepad.com/],Drupal 和[Wordpress MU|http://mu.wordpress.org/]。其中Wordpress MU是Wordpress推出的一个多用户版本。作者的重点倒不是比较着几种多用户blog工具的孰优孰劣,而是想说明Blog的发展趋势是朝多用户的“团体Blog”(Group Blog)的方向发展。Group Blog与Community Blog还多少有些不同,前者的典范是BoingBoing,而后者的代表则是Slashdot。总的来说,作者还是比较赞赏Drupal的,认为Drupal还是这几款多用户Blog工具中翘楚。这份图文并茂的评论可以在[这里下载(PDF, 4.5M)|http://fiskbooth.com/report-full.pdf] 第二个焦点是Tangent Mobile的[Blogging & Content Management Systems (WordPress & Drupal Reviews)|http://www.tangentmobile.com/2005/05/05/blogging-content-management-systems-wordpress-drupal/]是直接对WordPress和Drupal的比较,中间也顺便对MovableType和Mambo做出了评价,但是作者推崇的仍然是WordPress和Drupal,援引作者的一句话: ;:__If you thought WordPress, was awesome, wait until you see Drupal!__ ;:__如果你认为WordPress真的是棒极了,不妨等看到Drupal后在下这样的结论!__ 其实从根本上来说WordPress是一个非常不错的Blog工具,而Drupal则是CMS+Blog。如果你只想搭建一个Blog,WordPress无疑是最好的选择之一,不过如果除了BLOG你还想放进去些别的东西,无疑Drupal是最佳的选择。
Blog分类: 

日俄对马海战一百周年

[img_assist|fid=128|thumb=1|alt=对马海战图|caption=日俄对马海战]
一百年前的今天(1905年5月27日),位于日本群岛与朝鲜半岛之间的对马海峡依然是寒风凛冽。巨浪滚滚中,一支疲惫的舰队正在惶恐不安中行驶,全体船员昨夜一夜无眠,全部严阵以待,准备迎击可能出现的敌人,可是昨夜却异常地平静。今日正是沙皇尼古拉二世的加冕日,早上8时,这支俄国舰队照例升起了桅顶旗,而就在此时,医院船“乌拉尔号”报告发现了日军的巡洋舰。可是,俄舰队的总指挥罗日杰斯特文斯基中将并没有制定作战方案,只向舰队发出了一般性作战指令:巡洋舰保护供应船,其他舰只听从旗舰指挥。

日舰仍然不声不响的尾随俄国舰队,终于,俄舰上的炮手忍不住,在11时15分首先向日舰开火,其他俄舰也开始射击,日本巡洋舰立即还击,可是由于双方相距较远,并未射中对方;11时30分,俄舰为了避免浪费弹药,停止射击。终结日俄战争的对马海战就这样拉开了帷幕。战争的过程对俄国而言,异常惨烈:波罗的海舰队全军覆没,8艘战列舰,6艘被击沉,2艘被俘;9艘巡洋舰,4艘被击沉,3艘被扣留,一艘逃到海参崴,一艘逃离战场搁浅后被官兵自爆;3艘海防铁甲舰,2艘被俘,一艘被击沉;9艘驱逐舰,1艘被俘,4艘被击沉,1艘被扣留,1艘遇难,2艘逃到海参崴;1艘假装巡洋舰被击沉;8艘辅助舰,4艘被击沉,2艘被扣留,2艘医院船被俘。而日本方面,仅有3艘水雷艇被击沉。人员方面,日军死亡117人,伤587人。而俄军死4830人,受伤人数不祥,5917人被俘,1862人被外国港口扣留。俄国的整个损失是其海战史上最严重的一次。

这支俄国舰队的覆灭倒算不上意外。战争的背景是日本与俄国在中国东北地区和朝鲜的利益之争。俄国一心想独占东北并控制朝鲜,这不仅与日本的利益冲突,也引起了英国和美国的不满,于是就有了英日之间的联盟。俄日之争达到白热化,在陆海军遭到一系列失利之后,沙皇慌了手脚,匆忙决定派波罗的海舰队去远东,以增强远东的海军力量,这支舰队被重新命名为第二太平洋舰队。

可是从波罗的海到远东的旅顺港,路途遥远,航程有18000海里,途中后勤供给困难。舰队官兵的士气又极其低落,风声鹤唳,草木皆兵,甚至认为日本的舰队已经航行到西北欧的海域,所以在舰队刚刚进入北海的时候,就自以为发现了日舰,慌忙射击,结果击沉了英国的渔船,不仅如此,俄舰之间也误把友舰错认为敌舰,相互开火,这就是轰动一时的“赫尔事件”。事件之后,英国自然不满,再加上它与日本的同盟关系,立刻用战争相威胁。在海上,俄国自然不是英国的对手,只好屈服认错,赔偿了事。由于这次事件,俄舰在西班牙被迫耽搁了一周,重新起航后,在地中海西口舰队分为两部分,吃水量较浅的船只走苏伊士运河,较深的船只绕道非洲好望角,两支舰队在马达加斯加会合,然后再一起横渡印度洋。

好不容易到了马达加斯,却传来一个糟糕透顶的消息:日本陆军占领了旅顺,全歼了俄国的第一天平洋舰队。这时,第二太平洋舰队的使命已经变得毫无意义,本来的打算是和第一舰队会合,一起夺回制海权,而现在第一舰队已经被歼灭,第二舰队必须独自面对日本海军,长途袭远,以少敌多,情况对俄国非常不利,但是沙皇却铁了心的要孤注一掷,仍然命令第二舰队去远东,并派遣了一支新舰队支援。

可是第二舰队还是在马达加斯加停留了三个月,原因是没有足够的煤和后勤供应。当这支舰队最终拖着疲惫的身躯来到中国海面的时候,日本已经以逸待劳,恭候多时了,俄舰之败也就顺理成章了。

这次战争对世界格局的影响意义深远。它结束了持续一年多的日俄战争。俄国惨败,国内革命一触即发,不得已,沙皇只好宣布宪政,设立国家杜马;日本的胜利大大刺激了其侵略的野心,极力向朝鲜及中国的东北地区扩张,并在几年后吞并了朝鲜;日本的胜利也大大刺激了当时的中国,这次胜利被认为是宪政对专制的胜利,国内要求立宪的呼声此起彼伏,不久便有五大臣出洋考查宪政之举。

Blog分类: 

同时出现的Drupal 简体中文与繁体中文汉化!

刚在Drupal总站看到的,几个钟头前才提交的,有[简体中文|http://drupal.org/node/23583]和[繁体中文|http://drupal.org/node/23585]两个版本,其中繁体中文是用ConvertZ7.40直接从简体中文得到的,所以一些词法的不同并没有转换,譬如”程序”与“程式“,不过这些都是小问题,繁体中文可以很容易更改过来的。 下载到本地,用PoEdit打开看了一下,2190个字符串,除了9个没有翻译外,其他都已经完成了,比起通行的Hiweed版是一个很大的进步啊!翻译者的ID是tnds,留下的联系网站是[子虚乌有|http://www.zxwybbs.com/drupal/],目前网站上还没有什么内容,看样子是刚刚搭建好。呵呵,这个一定要赞一下,虽然Hiweed完成了80%的翻译,但是很多比较长的文字都没有翻译,另外4.5的翻译recycle入4.6后,估计可能也不到80%了,所以工作量还是不小的。呵呵,待会儿导入看一下效果如何! __Update:__试用手记: 已经导入了新的翻译,由于安装模块的缘故,我的blog实际需要翻译的字符串共有4000多,导入了核心的两千多条翻译,仍然有2000多条没有翻译,呵呵,看来有些常用的模块还是要自己动手了,希望Drupal能给简体中文建立一个新的Project,这样有了新的模块翻译也可以加入。 另外,看来tnds的翻译不是recycle了hiweed的旧翻译而是一些重新开始的,所以一些翻译刚用起来可能不是很习惯,譬如“block”,Hiweed翻译为“区块”,tnds翻译为“板块”,“forum”,hiweed翻译为“论坛”,tnds翻译为“面板”等等。不过好在Drupal可以很方便的根据自己的爱好调整翻译,只要在“本地化”里搜索到相关字符翻译,改过就好了。 还有,tnds最好的地方就是彻底翻译完了Drupal的核心字符串,现在所有的帮助、说明都进行了汉化。
Free Tags: 
Blog分类: 

有趣的唐代藩镇

[img_assist|fid=124|thumb=1|alt=河北三镇|caption=河北三镇]
接着前几天的话题的多聊两句。对于唐代的藩镇,宋人有一句很有趣的评论:“弱唐者,诸侯也;既弱而久不亡者,诸侯维之也。” 安史之乱之后的唐朝,从表面上看,内忧外患,似乎已经衰弱到了不堪一击,但是却又残存了一个半世纪。这种“弱而不亡”的状态和藩镇之间的制衡以及中央与藩镇之间的制衡是密不可分的,看似四分五裂,实际上却形成了一个比较稳定的动态均衡,直到黄巢大起义,严重破坏了这个均衡,于是力量迅速的重组整合起来,不久某些藩镇坐大,再无其他力量可以制衡,唐朝统治终于土崩瓦解。

说起唐朝的藩镇,经常地会想到的是“藩镇割据”,其实唐朝安史之后的四五十个藩镇中,真正割据的只是少数,最为典型的是“河北三镇”,其他大多数的藩镇还是忠于朝廷的。这四五十个藩镇可以大致分为四类。

第一类便是割据型,主要集中在河朔,大多是安史旧部归降者,代表就是河北三镇--卢龙, 成德和魏博。这类藩镇的藩帅不由中央任命,而是本镇将士拥立,他们的赋税也不上缴中央,全部留作自己瓜分。他们表面上忠于朝廷,事实上却像一个个独立的王国,虽然代、德、宪、穆诸朝多次讨伐这些藩镇,但是全部以失败告终。安史之后的藩镇动乱,以这类藩镇居多。

第二种是遏制型,主要在中原一带,譬如宣武、武宁、河阳、河东等。这些藩镇的作用主要是为了遏制上面的割据藩镇,他们平时常宿数十万重兵,防备河朔割据藩镇的侵扰,同时他们的赋税也基本上留作自己用,主要是为了维持强大的驻军。他们既是唐朝中后期平乱的主要力量,又是乱兵频生的是非之地,但总的来说他们还是接受中央的管辖的, 虽然也有暂时割据的情形,但是不久就被讨平;虽然有时候也抗拒中央命令,不听从调遣,但是都不长久。

第三类是守边型,主要集中在西北,西南边疆,防备西北和西南的少数民族。这类藩镇也驻有重兵,但是他们必须依赖中央供给。与中原藩镇不同,他们的驻地并不富饶,不能自给,需要中央财政供养。这些藩镇相对安定些,当然也有少许叛乱,主要原因是衣粮欠缺或是藩帅太贪,克扣粮饷。

最后一类是赋税财源型,主要是东南一带的藩镇,这类藩镇没有多少军队,但却极其富裕,是中央的赋税之地。这类藩镇很少叛乱,所以史称“天下藩镇,东南最宁”。

这些藩镇之间相互制衡,东南藩镇有财无兵,西北藩镇有兵无财,必须中央集中调度,听从中央指挥;河朔藩镇与中原藩镇割据与反割据相持,中原偶尔也有藩镇想联络河北三镇一起造反的,但是很快就被周围其他忠于朝廷的藩镇平定;而河北三镇也没有足够的力量灭掉中原的藩镇,想安史一样打进长安。不过比较有趣的是,为什么区区三镇(宪宗以后,割据的基本上就只有河北三镇了),唐朝一百多年都平定不了?

Free Tags: 
Blog分类: 

快速搭建Linux+ Apche + MySQL + PHP :XAMPP for Linux (LAMPP)

这次恢复数据的时候,无意中发现了一个很好的集成软件包:XAMPP for Linux (原来也叫做 LAMPP)。它可以快速的帮助你搭建本地服务器,以方便进行进行本地测试。刚才搜索了一下关于这个软件包的中文资源,并没有多少,所以简单介绍一下,挺方便的。 说起搭建本地服务器,想到最多就是 WAMP,也就是 Windows + Apache + MySQL + PHP,我现开始想到也是这个,于是在Windows下安装了WAMP。WAMP的版本很多,我用的是[GreenAMP|http://chin.blogchina.com/227620.html],不需要安装,直接启动就可以使用,包括了经典的Apache, MySQL, PHP 组合以及PHPmyAdmin等等。但是windows下的AMP不好用,特别是你的数据库非常大的时候,唯一的导入方式就只有用PHPmyADMIN了,可是PHPmyADMIN默认的上传大小是2M,虽然更改一下PHP.ini等几个地方,可以增大这个限制,可是不停的导入导出还是很麻烦,并且windows下一般来说千万不要随便打开MySQL数据文件,我用Ultra Edit打开过几次,结果总会把MySQL语句弄乱。 于是想到了Linux下的AMP,其实以前没有接触过这个,只是猜想应该也有类似的东西,所以就搜了一下LAMP(这个词是我猜的,不过真的猜中了),结果找到了XAMPP for Linux。这个软件包原来的名字是LAMPP,但是为了避免误解,最新的几个版本就改名为 XAMPP for Linux了。 __最新的基本组件包括:__ * Apache,2.0.53 * MySQL,4.1.11 (55~ 这就是我要找的4.1啊!) * PHP,5.0.4 & 4.3.11 * Perl,5.8.6 * ProFTPD,1.2.10 * OpenSSL,0.9.7d * phpMyAdmin 2.6.1-pl3 __图形软件包__ * GD,“Graphics Draw”库 * libpng,官方的 PNG 参考实现库 * libjpeg,官方的 JPEG 参考实现库 * ncurses,字符图形库 __数据库软件包__ * gdbm,标准的 UNIX® dbm 库的 GNU 实现 * SQLite,一个相当小的、无需任何配置的 SQL 数据库引擎 * FreeTDS,一个数据库,让 UNIX 和 Linux 程序可以访问 Microsoft® SQL 和 Sybase 数据库 __XML 软件包__ * expat,一个 XML 解析器库 * Salbotron,一个 XML 工具包 * libxml,一个 XML C 解析器和 GNOME 工具包 __PHP 软件包__ * PEAR,PHP 库 * 一个 pdf 类,可以使用 PHP 生成动态的 PDF 文档 * TURCK MMCache,一个 PHP 性能增强器 __其他软件包__ * zlib,一个压缩库 * mod_perl,在 Apache 中嵌入了一个永久的 Perl 解释器 * gettext,一个工具集,可以帮助 GNU 软件包生成多语言的消息 * mcrypt,一个加密程序 * Ming,一个 Flash (SWF) 输出库 * Freetype2,一个软件前端引擎 * IMAP C-Client,一个邮件编程 API 当然还有其它一些东西,总的列表如下: Apache 2.0.53, MySQL 4.1.11, PHP 5.0.4 & 4.3.11 & PEAR + SQLite 2.8.9/2.8.14 + multibyte (mbstring) support, Perl 5.8.6, ProFTPD 1.2.10, phpMyAdmin 2.6.1-pl3, OpenSSL 0.9.7d, GD 2.0.1, Freetype2 2.1.7, libjpeg 6b, libpng 1.2.7, gdbm 1.8.0, zlib 1.1.4, expat 1.2, Sablotron 1.0, libxml 2.4.26, Ming 0.2a, Webalizer 2.01, pdf class 009e, ncurses 5.8, mod_perl 2.0.0-RC4, FreeTDS 0.62.4, gettext 0.11.5, IMAP C-Client 2002b, OpenLDAP (client) 2.2.13, mcrypt 2.5.7, mhash 0.8.18, eAccelerator 0.9.2a, cURL 7.13.1, libxslt 1.1.8, phpSQLiteAdmin 0.2, libapreq 2.04-dev 安装就更简单了 tar xvfz xampp-linux-1.4.13.tar.gz -C /opt 安装完毕。(/opt 为本地安装目录) 启动只需要 /opt/lampp/lampp start 然后就可以看到 Starting XAMPP 1.4.13... LAMPP: Starting Apache... LAMPP: Starting MySQL... LAMPP started. 一切都搞定了,比windows下要简单的多。输入 http://localhost 会进入测试页面如下: [http://www.kzeng.info/drupal/files/380.jpg] 在这个软件包的[官方网站|http://www.apachefriends.org/en/xampp-linux.html]可以下载到这个软件包,并且有进一步的说明。如果想搭建一个本地的Linux测试环境,赶紧动手吧:)
Blog分类: 

Blog完全恢复!

哈哈,总算彻底恢复了,一丁点儿数据都没有丢失,期盼的大团圆结局居然在最后才出现,实在是意外的惊喜!把昨天沮丧的文章转在下面吧:

忙了这么久,总算还有些成绩。原来的数据库恢复过程中由于MySQL Dump 数据时出现乱码,暂时放在一边,如果感兴趣,想看看残破的Drupal是什么样子,可以看看:http://www.kzeng.info/test/ 呵呵,仍然是一个完好的Drupal,只是数据库有些问题,出现了乱码。正在尝试进一步的修复,如果修复无望,只好把里面的重要的文章再copy过来。

现在运行的Drupal是基于三周前的一次备份,现在运行良好,只是丢掉了三周来的数据,不过会慢慢的补足,只是可惜了大家众多的评论和trackback,那里的乱码很难修复了。

这次突发事件有喜有忧,忧的是丢掉了一些文章,还要费时间转过来,喜得是学到了不少东西,以前对于Linux下的命令行,只是偶尔为之,动辄需要查手册,可是经过这两天的反复操作,已经成为一个熟练工了,MySQL和PHP也是一样的,为了迁移转换数据库试了许多方式,增加了不少经验值,同时还接触到了emac,LAMPP,qftp等等不少有趣的东西,挺好用的,不知道windows下游没有相关版本。美中不足的是没有一个大团圆的结局,最后折腾出来的数据库还是有乱码,但是在我这里基本上已经是无能为力,是空间提供商的问题。把旧的数据库先放在那里,看看以后会不会有办法。

这次事情突然,原来只是想搭个blog玩,所以没有太注意空间提供商的稳定性,可是东西积攒多了,一下子丢掉又舍不得。现在换了一个牢靠些的空间,以后应该不会有问题了。

关于这次问题,有了不少新的经验,大致总结一下:

拿到了数据库文件发现不能直接导入MySQL Server,仔细一看是版本的问题,当时到MySQL的网站,查了一下手册,知道问题出在Engine这个变量上,所以就用Ultra Edit更改了一下,但是在SSH中导入时却出现了错误,只要Ultra Edit修改过的文件,里面的编码似乎都会出现问题,把英文字符变为乱码。当时郁闷了一下。

幸好我的笔记本上还装了Mandrake的Linux 操作系统,最初装的时候只是好奇,现在看来Linux果然是一个强大的工具。在Linux先用普通的Editor修改MYSQL文件,但是发现仍然有 Ultra Edit一样的错误,偶然间发现了Emac,重新编辑过,问题居然没有了,于是我就手动把数据库文件从4.1降级为4.0。导入,OK,可惜居然是有乱码!(后来才知道是数据库文件本身的问题)。当时又郁闷了一下。

一计不成又生一计。从windows下的WAMP想到了Linux下的LAMP,于是搜索了一下,找到了集合 Apache, PHP 4.11.3 和 MySQL 4.1.11的LAMPP---bingo!我要到就是MySQl 4.1.11,于是下载,40多M,安装,以前比较讨厌Linux下用命令行的安装方式,不过现在看来也有不少便利之处,起码对安装的过程了解的通通透透。然后启动,一切顺利,把原来的数据库导入,然后再重新dump,加上了 compatible=msq4.0的条件,得到了可以在MySQL 4.0中使用的数据库文件,重新上传,导入,结果---还是乱码!当时又郁闷了一下。

于是想测试一下原来的数据库究竟怎样,于是在本地安装了Drupal,连接本地数据库,然后--还好乱码,原来已开始的问题所在就是数据库文件本身! 有些ft。最后还是用了这有问题的数据库,不过又想到了以前的备份数据,拿出来,居然还可以用,就是现在了。

只能抱怨原来的空间提供商了,好在损失还是不大:)

Blog分类: 

重新开始折腾Drupal主题

Drupal最近又推出了不少有趣的主题,有提交给官方的,也有私下fans自己做着玩的,最近看了不少主题的CSS,所以又动了改主题的心思,呵呵,今后一段时间blog要经常大变脸了:)

今天把三栏显示改回了两栏,因为觉得三栏显得有些零乱。同时更改了block的title属性和list属性,比较喜欢现在的list图标。只是些小的改动,等到有空了再做些大的更改吧。

还有,发现blog的RSS和Atom又恢复正常了,估计是有错误的字符的blog已经沉入水底,最新的blog不再有这些问题了。

Update: 呼~呼~,抄袭Blix完毕,hoho,又开始我的大杂烩过程:)

Free Tags: 
Blog分类: