昨天,今天,明天,每天的每天,你是否都多懂得一点点...

星期二, 五月 19, 2009

dragonfly 比我原想要强大得多

弄明白为什么GMAIL会是空白的了. 原来DRAGONFLY的默认设置会让浏览器执行到JS代码的时候停下来, GMAIL可是极其复杂的网页,基本就是JS写的, DRAGONFLY把JS停下来了,当然就显示空白了. 一直按F8就可以看到进度条在慢慢的走,然后GMAIL就打开了, 不过我还是发现在DRAGONFLY开住的情况下, GMAIL发不了邮件.

--
Feng

opera 中国版居然没有 dragonfly

dragonfly 是 opera 的调试工具, 有人翻译成龙飞,也有翻译成蜻蜓,都对, 要看开发团对本身的意思. 以前用过, 但好像没有FIREBUG那么爽,所以也没有深入研究. 今天突然想用的时候才发现OPERA中国版里面没有.... 只好到官网去下载了个英文版的..下下来后发现还是中国版..晕....最后下载了个国际版的才搞定. 用dragonfly来查看GMAIL的DOM好像没有成功...网页上一片空白.

--
Feng

星期六, 五月 16, 2009

摘柿子

今天去摘柿子了, 100 STATION RD, 16号高速上.
摘了很多,以为有50斤了,出来一称,居然才11公斤,晕菜...是我们太不能提还是他们的称不准? 总共才花了17块钱...
晚上在MICHEELE家吃饭,正宗马来风味. 姜粉饭,鸡肉, 马玲薯肉沫, 煮鸡蛋, 黄瓜片...
吉它拿去借我妹了...
又被我妈训了...

--
Feng

星期一, 五月 11, 2009

搞不懂的PAC文件

抄了个PAC文件,配置了IE后却不生效,在OEPRA中也不生效. 上网下载了一个PAC文件.这回却生效了.可是随便改点东西,甚至加了注释就会使它又无效,实在搞不懂.
function FindProxyForURL(url, host) 

  return "PROXY 127.0.0.1:8080"; 
}
代码就是这么简单...
PAC路径
勾起1.1
file://localhost/e:/gre/proxies/proxy.pac

--
Feng

星期日, 五月 10, 2009

三天法会

上周五是毕业典礼,搞得很累, 脚痛,腿也痛. 现在还痛.周六又要去参加佛堂的法会... 很辛苦, 很不想去, 但是阿姨太热情, 只好硬着头皮去了. 一天法会中, 居然有三个神仙附体在"三才"身上.... 吓死我了....法会搞到9点多才结束....累呀.... 十点多才到家. 到家后, 我打电话给阿姨家. 说不再去参加剩下两天的法会了. 今天早上七点, 还是有个范阿姨打电话来苦口婆心的劝我, 我还是坚决不去. 我不喜欢有鬼神的地方.有鬼神, 就有骗子,呵呵. 哪天他们突然有个鬼来"附身"三才, 说我前世害过他,这世要还, 要了冤欠, 要我干嘛干嘛......我就惨了...我还是去信佛算了, 以后啥都可以推掉...俺已经有信仰了...哈哈. 碰到基督教就说是佛教的, 碰到佛教就说是基督教的,嘻嘻.
--
Feng

星期一, 五月 04, 2009

最好的汇编教材就是masm32

我在学校学的是ALPHA 汇编,而不是常用的WIN32 汇编,整天就是和寄存器打交道,写一点东西就不知道要多少CODE. 本以为它和WIN32 汇编总是差不多,可是发觉自己根本看不懂太多WIN32的汇编...才发现学的是没太大用的东西.当然,CPU的工作原理却还是没有白学的.在网上找过一些汇编教材.其中有一本 汇编语言全接触------------------www.VJStudio.net-- 被称为是最好的汇编教材. 我使劲的跟着它走,却发现荆棘丛丛. 把里面 iczelion 的代码抄出来, 编译的时候最总是出各种各样的错,调得满头大汗. 昨天看了看,MASM32的帮助文件, 才发现MASM32自带了不少的实例, 而且 iczelion 的教程也在里面.并且是经过修改可以直接在MASM32中运行的...相信把MASM32自带的帮助和教程看完将会获益良多.

--
Feng

星期五, 五月 01, 2009

无意中发现EDITPAD PRO可以显示多国语言编码

一般的编辑器都只显示 ANSI和 UNICODE了. 而 editpad pro 可以显示以下这么多... 用它打开繁体也绝对不会乱码.... 其它国语言的话...黑黑, 打开虽然不是乱码, 对我来说也就是乱码了... 除了这款编辑器, 我还不知有其它编辑器有此能耐. GVIM中除了中文和英文, 其它全是方块块. 虽然看不见, 不过还是可以正常编辑和保存的. 
Unicode, UTF-8
Unicode, UTF-32 little endian
Unicode, UTF-32 big endian
Unicode, UTF-16 little endian
Unicode, UTF-16 big endian
Windows 1250: Central European
Windows 1251: Cyrillic
Windows 1252: Western European
Windows 1253: Greek
Windows 1254: Turkish
Windows 1255: Hebrew
Windows 1256: Arabic
Windows 1257: Baltic
Windows 1258: Vietnam
Windows 874: Thai
Windows 949: Korean
Windows 932: Japanese Shift-JIS
Windows 936: Simplified Chinese GBK
Windows 950: Traditional Chinese Big5
ISO-8859-1 Latin-1 Western European
ISO-8859-2 Latin-2 Central European
ISO-8859-3 Latin-3 South European
ISO-8859-4 Latin-4 North European
ISO-8859-5 Cyrillic
ISO-8859-6 Arabic
ISO-8859-7 Greek
ISO-8859-8 Hebrew
ISO-8859-9 Latin-5 Turkish
ISO-8859-10 Latin-6 Nordic
ISO-8859-11 Thai (TIS-620)
ISO-8859-13 Latin-7 Baltic Rim
ISO-8859-14 Latin-8 Celtic
ISO-8859-15 Latin-9
ISO-8859-16 Latin-10 South-Eastern European
DOS 437: United States
DOS 737: Greek
DOS 775: Baltic Rim
DOS 850: Western European
DOS 852: Central European
DOS 855: Cyrillic
DOS 857: Turkish
DOS 860: Portuguese
DOS 861: Icelandic
DOS 862: Hebrew
DOS 863: Canadian French
DOS 864: Arabic
DOS 865: Nordic
DOS 866: Cyrillic Russian
DOS 869: Greek 2
KOI8-R: Russian
KOI8-U: Ukranian
EBCDIC 037: US & Canada
EBCDIC 424: Hebrew
EBCDIC 500: International
EBCDIC 875: Greek
EBCDIC 1026: Turkish
Windows 1252: Western European



--
Feng

星期四, 四月 30, 2009

what is javame

我认为 JAVAME SDK 可以用JAVA SE SDK+ WTK 来实现。 JAVAME SDK 和JAVA SE SDK 
中必然有相当多的重复。 那装了JDK 后,是否还要装 JAVAME SDK呢? 那装了JAVAME 
SDK 后, 又是否还要装 JDK 呢? 如果要在WINDOWS 平台和移动设备上都开发的话,
 我还真不知道要怎么装。 也许 JDK+WTK会是个解决主案吧, 不知道,没试过, 
纯属推论。以下是NOKIA 网站上抄来的一部分, 从以下的文字来看, JAVAME SDK 
只是JDK的修改版, 减少了 SWING, AWT等东西, 同时加入了移动设备专用的WTK 
这些东西。

Java ME is a limited subset of the standard Java (Java SE) available on the desktop computers, with some additional mobile phone-related APIs. There are a number of limitations you need to keep in mind: 
MIDlets run in a sandbox because of security reasons. (There are confirmations when using certain functionalities, like networking or sending SMS messages.) 
There is no JNI (Java Native Interface) so you cannot extend the capabilities of Java ME environment on the phone. 
There are no Swing or AWT classes. MIDlets use their own (simplistic) UI classes. 
The capabilities of the Java ME environment vary widely, meaning that the phones have different set of optional APIs implemented (examples include access to files, access to phonebook, video/audio recording, 3D graphics, etc.)

--
Feng

星期三, 四月 29, 2009

proxomitron 日志文件太大

日志文件到了3M多而已. 打开 proxomitron 后, 界面一直不出来, 然后就是CPU占用100%. 一直在研究配置文件, 后来才发现是日志文件大太了.

--
Feng

tollroad

上次去沙士比亚公园的时候走错路, 上了TOLLROAD (不是我开车)... 多走了很多路,都走了很远去了才发现走错了. 然后只好我开回来, 再次经过TOLLROAD的时候, 我没上. 而是从左边那条路上走. 这样才终于走到目的地. 回来后却还记得要去TOLL ROAD的网站付费,两刀. 可是到家就忘了, 第二天出门又想起, 回家后又忘了. 因为交费的时限只有两天. 所以已经过了时间. 可是还是没有想起, 直到第五天才想起来, 上网交费, 却已经不能交了. 只能预付费. 今天就收到了LAND  TRANSPORT的追债信, 这回要交四块二...靠...迟交几天都不行, 想是第三天它的信就准备好了, 于是不让你再补交费了.  

--
Feng

星期一, 四月 27, 2009

reader_s 病毒

病毒好像被我稳住了, 它感染了我所有开机自启动的程序, 而我那些程序并不放在系统盘, 所以重启后, 依然感染了这些病毒. 这就是为什么影子系统也会中毒的原因. 开始是用了大蜘蛛的 CUREIT, 实在没用, 一个毒也没查出. 后来用了卡巴绿色版, 虽然只能升级病毒库一次, 却都能杀出来. 终于发现好多程序被感染了, 只好把那些感染的程序全删除了. 因为没有时间进行全盘扫描, 所以现在每运行一个程序,都得把那个程序扫描一下...明天再全盘扫吧. 装了个HIPS, EQ魔法盾, 呵, 可能是要经过设置吧, 反正它什么警也不报....郁闷的是现在网速慢得出奇....发个博客都发不了.

--
Feng

天杀的, 中毒了

影子系统也还是中毒了, 原因不明, 我是故意运行那个病毒的,只是没想到这么霸道, 重启后还是有中毒的迹象, 有些软件打不开
应用程序正常初始化(0xc000007b)失败
看来这几天要在杀毒中度过.

--
Feng

星期日, 四月 26, 2009

AVANT BROWSWER 打开后, OPERA变得很卡

难道是AB的市场策略? 还是我电脑问题? 不太清楚, 没有深入研究.

--
Feng

文本编辑器打开二进制都很快

不明白为什么文本编辑器打开二进制文件都很快, 打开文本文件却慢得慌. 是不是因为要把二进制值转成人可读的字符呢? 

--
Feng

星期六, 四月 25, 2009

发现editpad pro 打开大文件音速

TOTAL  COMMANDER 我设置的默认编辑器是NOTEPAD++, 它打开大文件的速度一般, 比VIM好像好点. 以前从来没有需要打开大文件的情况, 所以没太注意. 前段时间, 用 PROXIMOTRON 把所有访问过的网址都记录下来. 生成的日志文件几兆了. 才发现VIM打开超慢, 试了NOTEPAD++, 一样慢, NOTEPAD2, 一样.  但是ULTRAEDIT32就快得多. 可是好像有个问题, 就是好像之前用别的编辑器打开过后, 再打开就很快了. 而我用来试ULTRAEDIT的文件都打开过了, 因为没有那么大的文本文件, 就随便用二进制文件来试. 好像所有编辑器打开二进制文件都很快. 不过ULTRAEDIT32好像快一点. 不过我发现 EDITPAD PRO更快. 刚才终于找到了个大的XML 文件, 证明 EDITPAD PRO才是真的音速.还没找到大的文本文件来试 ULTRAEDIT32, 下次再次吧. 我用的是古董版5.0. 之前也装过 UE STUDIO, 但是大了点,我又不太用, 就删了, 还有SLICKEDIT 也删了.

--
Feng

果然那个quick'n easy web server 不支持 utf-8 编码

转换成UTF-8 后,不管有没有BOM头, 都显示不正常.
Script error detected at line 1. 
Source line: Response.Write "浣�
Script details:
Description: 未结束的字符串常量
不过我之前用VIM转的时候,只是有一点点不正常, 现在试确是完全显示不了....
到底真正的问题在哪里, 还是不知道.

--
Feng

TIDY在VIM中处理UTF-8的问题

如果文件格式是UTF-8的话,用TIDY查错就会有大问题, 每个中文都是一个错误
replacing invalid character code

因为TIDY处理的其实是文件,所以这只能FENC有关,和ENC无关. 只有把FENC换回CP936才能正常.
本来想把文件全部换成 UTF-8的,看来不用了...而则之前用VIM把所有文件转换成UTF-8后, 网页显示有点不正常. 后来下了个VBS写的小程序来转,转换速度飞快, 但是转完后网页打开一片混乱.我怀疑它只是在文件头部插入了UTF-8的标识而已.
于是, 做一番研究
41 C4 E3 41 A你A ANSI

打开VIM后,set fenc 查一下,是cp936
OK
现在set fenc=utf-8 转成 utf-8, 保存

41 E4 BD A0 41 0D A你A UTF-8

0D是被VIM加入的回车符,应该是 0D 0A 才对好像,查了一下, ff 被设成 mac 了,晕, 设回DOS,再保存看看.

41 E4 BD A0 41 0D 0A 

这回没错了, 说明了"你"的 cp936 编码是 C4 E3, 而在UTF-8里则是 E4 BD A0, 字母A的编码是41, CP936和UTF-8都没有区别.

用VIM设回CP936,

41 C4 E3 41 0D 0A

变成这样, 比第一行多了回车和换行符.

用记事本另存为UTF-8后, 变成

EF BB BF 41 E4 BD A0 41 0D 0A

就是在前面插入了 EF BB BF, 而VIM在转换成UTF-8的时候, 并不会这么做.

用VIM打开这个文件, 显示正常. 用VIM加入字母B后, 保存, VIM不会移除原有的 EF BB BF

EF BB BF 42 41 E4 BD A0 41 42 0D 0A BA你AB

用记事本再另存为ANSI, EF BB BF被移除. 
42 41 C4 E3 41 42 0D 0A 

再用记事本存回UTF8
EF BB BF 42 41 E4 BD A0 41 42 0D 0A

用VIM set fenc=cp936 

42 41 C4 E3 41 42 0D 0A

和记事本另存为ANSI效果一样.

再 set fenc=utf-8 
EF BB BF 42 41 E4 BD A0 41 42 0D 0A

晕, 这回它懂得加 EF BB BF 了....

设回 CP936, 关掉VIM中文件,再打开, 设为 UTF-8

42 41 E4 BD A0 41 42 0D 0A 

不会加了...

看来VIM在一般情况下, 存为UTF-8格式并不会在文件头插入 EF BB BF 的标识.

于是把文件在记事本中另存一下, 让它插入 EF BB BF标识为UTF-8文件, 在VIM中打开TIDY, comp! tidy, 然后MAKE一下, 成功了,可以正常MAKE UTF-8的格式. 但TIDY显示这么一行

specified input encoding (iso-8859-1) does not match actual input encoding (utf-8)


说明TIDY这回认出了文件是UTF-8了. 而VIM中TIDY的MAKE中没有加了 -UTF8 的参数,所以它是按默认 iso-8859-1 来处理文件的, 这就是为什么会把所有中文当作错误的原因.

上网查了一下, 这三个字节 EF BB BF 叫UTF-8 BOM HEADER, 但好像我用的ASP服务器不能正确处理这个BOM HEADER. 这些再研究吧...

想想怎么让VIM在转 UTF-8的时候, 也自动加入BOM头...


--
Feng

tidy 原来支持中文...

以前用TIDY格式化英文代码倒也没发现什么问题, 这两天用来格式化中文的网页, 发现乱码....于是只好动用dreamweaver 的 套用源格式来做, 可是我不喜欢用 DR. 打开太慢了. 今天又狂找别的代替品, 怎么也找不到. 
英文软件有中文问题是太平常不过, 所以我一开始也没想TIDY能支持中文. 刚才才发现 TIDY 可以设置UTF8的编码, 于是试了下. 果然...还是乱码....哈, 因为我的文件编码是CP936, 于是把文件编码改成UTF-8, 然后用TIDY
tidy -i -utf8 temp.html > temp.htm
成功了, 不会乱码....激动....
然后把文件编码改回 cp936 , 试了下这个
tidy -i -raw temp.html > temp.htm
成功了. 
TIDY 有直接的 BIG5 支持, 却没有 CP936的支持.

--
Feng

星期四, 四月 23, 2009

该死的dreamweaver

玩玩FTP, 这个dreamweaver 又搞怪了.
虽然前面发现文件格式被变成UNIX的,却不知道是谁干的.(前面说错了, LF才是0A).
开始一直以为是dreamweaver 搞的,于是在设置里把换行符从WINDOWS格式,换成MAC格式...怎么换也还是一样.于是把DR8换成 DR CS3.折磨人呀,还是一样...废了. 再想, 难道是FTP服务器的问题?一经过FTP服务器传输,换行符就变了? 于是用 flashfxp 和 total commander 分别传了个文件上去试了下,没事,还是DOS格式. 可是 dreamweaver 传上去的就是变成unix 格式了.由于dreamweaver 编辑FTP上的文件的时候,其实是有复制一份在本地的, 于是看了看那份本地的,靠,是DOS格式的. 可是一经DR传上FTP就变成UNIX格式的. 而其它FTP客户端却没有这个问题. 想到也许用BINRARY模式有用, 可是翻遍DR的所有设定也没有找到这项....晕死. 好吧,在FTP服务器上想想办法...难道我真的要还FILEZILLA试试? 在XLIGHT的设定里翻了下, 发现有个禁用ASCII模式. 好,禁了,这样的话,就强迫客户端要用BINRARY模式. 就怕这样一来, DR连传都传不上去, 马上试试. 靠, 居然成功了.....

--
Feng

智障的ASP服务器

用 babyweb 做ASP服务器,原来还好好的,突然就给我变成了这样
Script error detected at line 0. 
Source line: Response.Write "a
Description: 未结束的字符串常量

百思不得其解. 因为代码都没动过...无语
把所有内容都删除后,错误消失,随便打了个字母,错误又来了...以为是ASP服务器出问题了,换了一个..(同一个公司的),还是一模一样.
以为是文件编码的问题,CP936转UTF-8, UTF-8又转CP936,还是一样. 最后用十六进制编辑器打开看一下,有个0A的ASSCII码不认识,查一下码表,是CR,就是回车符,于是把它删掉,居然就正常了.但是这样只能写一行. 不可能没有回车吧...于是把CR前面加了 LF(0D)这回可以了.可是用VIM存一下又回去了,废. set fileformat 查一下, 是UNIX,靠...于是改成 DOS 格式, 大功靠成...
我想说的是,这啥破服务器呀,连个回车符都搞不定,浪费我这么多时间.

--
Feng

其它博客地址

此博客的同步博客地址: http://fengnz.wordpress.com
这里进入我的MSN SPACE.