掠影:八达岭长城

越过长城,走向世界
Across the Great Wall we can reach every corner in the world.

7月21日,老爸陪余去爬八达岭。坐北京北到延庆的柴油动车组,二等座的票价14元,座位很舒适,空间很大

进入山区,火车一直在爬坡

路过居庸关

这样看去,也相当的崎岖

八达岭高速在堵车

出京方向,停靠的是青龙桥新站,返京时,停靠的是青龙桥老站。老站才是詹天佑的设计

查看大图

青龙桥新站。其实,余觉得在这里上班很不错,抬起头就是青色的山峰和灰色的长城。传说在青龙桥下车可以去爬残长城

终于来到长城的脚下。北坡方向

左边的山峰应该是附近的最高点

回望南坡。最低点是关城,南北两端从关城延伸

在此处断开。古代的工艺还是力有所不及

即将到达北坡最高点,看见了缆车

山峰非常陡峭,长城如果能修到那就牛叉了

最高点,北八楼不给上了。GPS测量的高度是872m

刻纪念牌的小商贩。好像是十块钱一个小的,二十块钱一个大的。最高点的生意明显比下面的好许多

爬完北坡,转回来再爬南坡。南坡的人很少,可能也跟时间有关。远处动车从青龙桥新站开出

回望北坡

砖上的刻字。最左上的那位功力深厚

人很少

真的非常少

少到可以拍到完全没有人的照片。这应该是南六楼

从终点俯瞰没修复的残长城

南坡终点。有刻石碑画的商贩,女老板英语能扯好一些,成功忽悠了一个老外买了块大的,100人民币+5张1欧元

八达岭处于飞机降落的航线上,飞机非常频繁

再回到关城,遥拍想摸个一筒,就摸个一筒。大概是奥运的公路自行车赛从此经过

回京。傍晚的八达岭车站。其实快的话,可以赶得上下午三点的火车回去

3,867 次浏览 | 没有评论
2010年8月5日 | 归档于 私语
标签: ,

掠影:天坛

19日跟老爸去了天坛,下着小雨,非常凉爽的天气。20日毕业典礼天晴,之后直到28号离开北京,都非常炎热,后面几天很闷,也就传说中的桑拿天

雨中拍天坛的光影效果自然不及21日的八达岭长城,不过也别有一番韵味。总觉得那天的天气很像南方三四月时的阴雨连绵,雨细细的一直下个不停

坐地铁到天坛东门,从东门进去。在长廊看到很多老人家打牌,然后看到一个老爷子在跳舞,跳得非常好,一群人在围观

接着走就是祈年殿。天坛标志性三大建筑物之一

排水体系

祈年殿很难拍全,下了三级台阶从较远地方拍摄又会遮挡底部

虽然是下雨天,但游客还是蛮多的

回音壁和皇穹宇,回音壁已经围起来了,老爸当年来的时候还可以贴上耳朵去听

遇到一个同讲白话的伯伯,盛赞皇穹宇的建筑工艺

圜丘。圜丘和祈年殿台基的工法很像,把大殿拿掉,也是一圜丘。以前初中的语文课说皇帝站在圜丘中央说话,柱子反弹回音,会使得声音听起来比较大。可惜人很多,无法实验了

望灯

被袁世凯推倒的望灯

接着转向天坛的西面。新植的柏树

斋宫的桥

斋宫的护城河

斋宫

月季园。来张微距

再来一张微距

从西往东横穿,返回东门。遇到一只蜗牛

这条路上还画了一个羽毛球场

大概下午五点多坐地铁返回

3,332 次浏览 | 没有评论
2010年7月30日 | 归档于 私语
标签: ,

掠影:毕业

在毕业典礼的前几天,学位服已经发了下来。老爸也正好抵达帝都,于是第二天在校园取景拍了一些照片。
自爆什么的是不会有的,同鞋的也不好发上来,于是贴一下景物的照片

学校的荷花7月就开始开放了,但还没到极盛

四倍光学变焦拉近拍,这小DC的极限了(啥时候余能有台单反啊

水草和倒影,倒影很清晰的

已经有一部分荷叶残掉了

不知道名字的奇特的树,花朵开在树尖

从树底下往上看基本看不到

航院有一架灰机,两个屁股,应该是歼八

看机头,应该是歼八早期型号

20号,毕业典礼,早上雨刚停。学校居然安排家长到6教看网络直播,真仆街,综体里空位一大堆。老爸说基本什么都看不到

到中午已经是晴空万里

典礼后继续拍。校园里人非常多,和同学将就在一些显著景点拍了下。
荷塘

于是就这样毕业了

3,150 次浏览 | 没有评论
2010年7月27日 | 归档于 私语
标签:

掠影:天津塘沽

7月12日~13日,老板请客去天津玩,其实12日是参加研讨会,13日算是福利,这就是毕业旅行了。先前承诺的去坝上吹了

也没坐上京津高铁,雇的是校巴,一路上在京津高速上飞驰,用G4的GPS测速,居然上到了100KM/h以上

天津港国际邮轮码头客运大厦是我们本次前往参观的目的地。码头坐落在渤海的填海造出的土地上,离海河入海口颇远
码头吃水10米深,围栏后面是登船桥,这种方式和航空的一样

客运大厦的光告就不多打了,流动的丝带是常用的字词。
其实施工质量并不是特别好,GRC板的缝隙很大,远看还好,近看有点脏,地面的大理石面砖也偶见被压坏,出入口围了半圈觉得很SB

传说造价100W的厕所,对面还有一个

镜头没完全打开,很奇妙的拍摄效果

晚上,吃海鲜,接着和同鞋一起逛了下周边。入住某酒店。
第二天。该酒店提供的早餐巨垃圾。一行人从中午起先后中招腹泻,还没吃午饭,已经战损3大主力,剩余的人午饭还吃得颇欢,结果下午就都不行了。估计是早餐的问题。

上午逛了下海河外滩公园,其实没觉得有啥看头

貌似喷水的装置

每人花了30块钱,上了一游艇。旁边的冲锋舟不断做着10元一次,安全刺激的光告,确实很刺激,不过也就转一圈,不到2分钟就结束
刚开始时余还以为30块钱能出到海河口,谁知竟是在河里往上游开个3、4公里就返回了

传说发哥拍的赌博片曾在此邮轮上取景

很有意思的大桥,中间的航道在桥梁升起后可以通行更大吨位的轮船

海河的水非常的脏,不逊于珠江

轮船启动时发出的黑烟还真大

中午去天津市区。在古文化街附近觅食,此时一个二个已经不行,暂时没事的去寻古玩(?),余已经被放倒就在玉皇阁歇息

大家购物完毕,匆匆返回帝都,结束糟糕的出游

3,023 次浏览 | 没有评论
2010年7月26日 | 归档于 私语
标签:

使用Gmail作为域名邮箱

关于页面里给的联系邮箱是

如果曾打开过mail.kuyur.info应该就会发现其实是疼迅提供的域名邮箱。今天决定将其转移到Gmail上。

使用Gmail做域名邮箱需要注册Google的企业应用套件,好在标准版是免费的,注册地址:http://www.google.com/apps/intl/zh-CN/group/index.html

注册流程挺简单的,验证域名后即可启用数种服务,包括Gmail、日历、sites、docs等,并且可以为单独的服务自定义自己域名的网址。Gmail的域名邮箱比国内IDC提供的企业邮箱好太多,IDC的垃圾企业邮箱去死!Gmail的服务质量也无疑比疼迅、网易等的域名邮箱要好。

标准版Google企业应用套件提供50个用户额度,因此熏子可以开一个小型电子邮局啦。如果你喜欢@kuyur.info的地址邮箱,可以发送邮件到上面的邮箱,注明用户名和密码,熏子为你手动添加帐号。邮箱空间即是Gmail的空间。

邮局:http://mail.kuyur.info
Google企业应用套件:https://www.google.com/a/kuyur.info/

3,930 次浏览 | 1 条评论
2010年7月8日 | 归档于 默认

持续崩坏中

实验室某后辈的玩具熊,身长50cm(好像不止50cm)。余也想要一个啊(咬手指)

情侣必须去死去死去死!

3,258 次浏览 | 没有评论
2010年7月5日 | 归档于 私语
标签:

以腐的角度解构电影《肖申克的救赎》

肖申克的救赎其实是一部伟大的同志电影,看,宣传海报已经指出了这点

整部影片讲述的是推与被推、从被推到逆推以及基友之间的基情故事。

影片没有女猪脚,甚至连女配脚都木有,在同志电影中这都是鲜见的,李安的断背山好歹基友们都有老婆而且还生活得很好,本影片可怜的男猪脚刚开始老婆就挂掉了。影片中女人出现的次数少得可怜,仅见的镜头就是超市里的大妈,男猪脚的老婆更是只有背影,并且是在激情的时候被做掉了。这反映出了导演对女人的蔑视、对出轨行为的憎恨以及被出轨行为深深伤害的扭曲心灵。到影片最后,男猪脚说他原谅了妻子,然而给余的观感是死了活该,只可惜男猪脚坐了20年冤牢,导演想通过男猪脚的话表达出宽恕,然而给观众的实际观感出卖了他。

男猪脚和一号男配角的基情故事是影片的主线,两人客服了种种艰难困苦,最后终于成功搞在一起。男猪脚一进监狱,一号男立刻看上了他,这叫什么?这叫一见钟情。两人在狱中擦着基情火花,互相视对方为心目中最重要的人,这叫情人眼里出西施。影片最后,墨西哥的海滩,明媚的阳光,蓝蓝的天空和海洋,雪白的沙滩,一艘小船,多么浪漫的场景,放到任何一部电影中肯定是爱的重逢,两位基友紧紧拥抱在一起,导演的意图已经公仔画出肠。不用说男猪脚肯定是攻方。

对于罪犯而言,典狱长和狱警都是攻。想上男猪脚的家伙喜欢爆人菊,结果被狱警用警棍爆了菊,可怜的家伙。当然,他应该成功推倒过男猪脚,但攻受转换就在瞬间。男猪脚被狱警看上了,接着被典狱长看上了,成为典狱长的御用后宫。二十年间,虽然有小摩擦,倒也显得恩爱,就算男猪脚惹怒了典狱长,典狱长也舍不得上SM。男猪脚后来也收了个后宫,典狱长非常愤怒男猪脚居然想背叛他,于是将他的小后宫给枪了,意图让男猪脚回心转意。然而男猪脚已经非常厌倦当受了,成功越狱并通过超长距离精神触手逆推典狱长。典狱长说他是总攻,结果导演笑了。典狱长致死都不明白他怎么会被逆推的,谁让男猪脚头顶猪脚光环啊~

以上纯属口胡,认真乃就输了

5,417 次浏览 | 4 条评论
2010年6月27日 | 归档于 影评
标签: ,

解决ubuntu和Android的mp3乱码问题

android也是Linux系统,解决乱码的原理是一样的。

音频文件可以使用的tag版本非常多,mp3大多使用这三个:ID3v1、ID3v2、APEv2,每个版本下又有多个小版本。Windows只能支持ID3v1,ID3v1其实是不支持多语言的,但因为Windows平台使用本地语言编码页去处理那些多字节字符串,简体系统中文字符能够显示出来,倘若来了个Shift-JIS的ID3v1,Windows就只能乱码了。这种情况和txt是一样的。如果将mp3的ID3v1抹掉,Windows自身的资源管理器和media player将不能识别mp3信息。ID3v2和APEv2都支持Unicode,这才是真正的多语言支持。让播放器去猜ID3v1的编码类型是最笨的方法。因此并不是说Windows的编码兼容性好,Linux就差,仅采用多字节编码去写ID3v1才是真正的罪魁祸首,杯具的是大多数mp3文件都是这样子,而Windows是其推手。

标签的使用优先度是播放器的事,支持是否也是播放器的事。一般而言,大多数播放器都支持ID3v2和ID3v1,ID3v1的优先度会设得比较低。Foobar2000支持APEv2、ID3v2、ID3v1,优先度应该是APEv2最高,ID3v1最低。在Foobar2000上转换出来的mp3的兼容性相当好,fb2k默认会写ID3v2(UTF-8)和ID3v1(本地编码),ID3v1实现了Windows平台(资源管理器和wmp)的兼容,ID3v2实现了多语言支持。Linux的播放器一般都支持ID3v2,而且优先度比ID3v1高,因此播放这些mp3不会乱码。

故一个较好的方案是:UTF-8的ID3v2+本地编码的ID3v1。这个工作fb2k 0.9版本以上可以完成(0.8.3不清楚)。

操作如下图所示,首先选中要转换的曲目,弹出右键菜单,tagging->MP3 Tag Types

勾选ID3v1和ID3v2,APEv2可选可不选,但Linux下很多播放器都不支持APEv2,所以建议不选。Updates files,完毕。

这可以为ID3v2缺失的mp3文件重建UTF-8的ID3v2。

倘若在ubuntu下仍然有乱码,不用怀疑,那是因为ID3v2不是UTF-8编码。ID3v2是可以存放本地多字节编码的,mp3若已经存在ID3v2,fb2k会跳过而不重新生成,导致ubuntu下仍然是乱码。这种情况我们可以借助APEv2做中介(APEv2只支持UTF-8,且字段比ID3v1丰富)。勾选APEv2,Update files(生成UTF-8的APEv2)–>去掉ID3v2的勾,Update files(擦掉非UTF-8的ID3v2)–>勾上ID3v2,Update files(重写UTF-8的ID3v2)。最后的APEv2保留是否随意。fb2k擦写ID3v2比较耗时,因为ID3v2位于头部,需要重构文件,处理几百M文件以上就会觉察到了。但毕竟非UTF-8的ID3v2文件是少数,ID3v2是不是本地编码在fb2k中也看不出来,这项修正工作可以到ubuntu下完成。rhythmbox(支持APEv2和ID3v2)、audacious和Amarok(仅支持ID3v2),这些播放器的播放列表如果还存在乱码曲目,用wine加载fb2k对乱码曲目执行上面步骤。

以上基本可以解决Android和ubuntu的乱码问题。再赞foobar2000,非常优秀的播放器,优秀是表现在能力上,不是在界面。倘若添加“仅为非UTF-8 ID3v2重构UTF-8 ID3v2”那就更完美了。

10,468 次浏览 | 4 条评论
2010年6月15日 | 归档于 android

明天答辩

明天(确切说是今天了)毕业论文答辩,这几天过着昏天暗地的日子。余真是到了deadline才会动手的银,从初审回来有15天的时间,基本上就只在最近这三天忙活,这性格啥时候能改一下呢。

三年就这样匆匆过去,烟酒僧生涯也将要结束。从小学一直读到现在,从未间断。一回首,感觉时间从高中起至今天简直就是过眼云烟。下一个十年的感触又会什么样呢?

很快就要正式步入社会,开始第一份工作,进入人生新的阶段。但无论怎样,读书也好,工作也好,希望熏子都能够保持激情,就算再讨厌的事,再难捱的困难,都不阴暗,保持乐观的态度坚持下去。面朝大海,春暖花开。

3,097 次浏览 | 没有评论
2010年6月12日 | 归档于 私语
标签:

GBK、Shift-JIS、BIG5编码检测算法

字符串的编码检测需要使用自定义的映射表,使用系统自带的Codepage是不大可能有准确率的,系统Codepage会将它所有没定义的字符映射为空格。
GBK、Shift-JIS、BIG5的码表空间都是不连贯的,而它们的有效空间也不完全重合,这为检测编码类型提供了可能性。

检测算法:
1、建立字符映射表:将任一ANSI编码的所有字符全映射,从0x00到0xFFFF都有Unicode字符对应,但需要注意的是没有定义的字符统统映射到Unicode的0xFFFD(共三个映射表,既可用于检测也可用于转换)。
2、预设字符串的编码是Shift-JIS。
3、使用Shift-JIS的映射表从字符串第一个字符开始检测直至最后一个字符。如果遇到有字符映射到0xFFFD,设置预设编码是GBK,立刻停止步骤3,跳至步骤4。
4、如果预设编码是GBK,使用GBK的映射表从字符串第一个字符开始检测直至最后一个字符。如果遇到有字符映射到0xFFFD,设置预设编码是BIG5,立刻停止步 骤4,跳至步骤5。
5、如果预设编码是BIG5,使用BIG5的映射表从字符串第一个字符开始检测直至最后一个字符。如果遇到有字符映射到0xFFFD,设置预设编码是未知编码,立刻停止步 骤5,跳至步骤6。
6、返回预设编码。

这个算法的编码检测优先度是Shift-JIS>GBK>BIG5,也即如果顺利通过当前检测,则跳过后面所有检测。事实上,有大量字符串是能通过所有检测的。例如只有一个字符的字符串,假设这个字符是0x8140,在三个编码当中,都不会映射到Unicode的0xFFFD,因此能通过所有检测。但这没意义了。设定了优先度后是为了告诉用户最可能的一种编码。

为什么设定Shift-JIS>GBK>BIG5?
Shift-JIS的码表空间是0x00-0x7F、0xA1-0xDF、0x8140-0xFC4B
GBK的码表空间是0x00-0x7F、0x8140-0xFEFE
BIG5的码表空间是0x00-0x7F、0x8140-0xFEFE
但双字节段(0x8140以上)都不是全部已定义,Shift-JIS在0x8140以上的有效字符数是7724,GBK是21885,BIG5是19782。
GBK的覆盖面最大,有效空间基本覆盖了Shift-JIS,因此一个字符串如果能通过Shift-JIS检测,也差不多能通过GBK检测。如果将GBK的优先度设得比Shift-JIS高,那么大量真正是Shift-JIS编码的字符串就压根没机会返回给用户了。从反方向看,GBK中存在数量庞大的字符Shift-JIS没定义,Shift-JIS是高度覆盖不住GBK的,一个GBK文本从概率上没那么容易检测成Shift-JIS。也即:如果一个文本的真正编码是Shift-JIS,那么优先使用Shift-JIS检测自然不会有问题;如果它是GBK,那么优先使用Shift-JIS检测也不大会返回Shift-JIS。因此Shift-JIS应当优先于GBK。
Shift-JIS和BIG5的关系的考虑也类似。

从转换日系音乐cue、日文小说的宅用途出发,也应当将Shift-JIS设置为最高。

下面三张图是是Shift-JIS编码的小说“文学少女”と死にたがりの道化的转换结果。左边是当作本地编码的处理结果,可以无视。右边才是转换结果。
(程序和文本下载:http://code.google.com/p/unicue/downloads/detail?name=Ansi2Unicode_1.01.zip

使用Shift-JIS映射表转换,结果自然是正确的。

强行使用GBK映射表转换,没有出现标记0xFFFD(0xFFFD:�),也即能通过GBK检测

强行使用Big5转换,出现0xFFFD标记,也即通不过BIG5检测。BIG5跟Shift-JIS的有效空间重合度没那么高,区分相对容易一点

另外一个GBK文本强行使用Shift-JIS转换的结果。很容易就出现了0xFFFD标记

那么GBK和BIG5的优先度应该谁高呢?这里就见仁见智了。GBK的字符数比BIG5多,从概率上GBK相对容易覆盖住BIG5,BIG5相对不容易覆盖住GBK。倘若采用Shift-JIS和GBK之间的比较方法,应该是BIG5的优先度比GBK高。但从实际情况来看,真正BIG5编码的文本强行使用GBK映射表转换比较容易出现0xFFFD标记,真正GBK编码的文本强行使用BIG5映射表转换反而不容易出现0xFFFD标记。

GBK文本强行使用BIG5映射表转换的结果,不容易出现0xFFFD标记

BIG5文本使用BIG5映射表转换,正常的结果

BIG5文本强行使用GBK映射表转换,很容易出现0xFFFD标记

现实结果和表面现象完全相反。如果一个文本的真正编码是GBK,那么优先使用GBK检测自然不会有问题;如果它是BIG5,那么优先使用GBK检测也不大会返回GBK。因此余倾向于GBK的优先度高于BIG5。
阅读全文…

10,323 次浏览 | 1 条评论
2010年6月8日 | 归档于 程序