乐趣为王

今天和MVP陈锐的Blog做了一个连接。另外还找到一个看网站的PageRank的网站http://www.top25web.com/pagerank.php。

现在小孩出生已经进入倒计时了，离预产期还有6天。

第二天几乎没有什么进展，上来就碰见了问题。

我是一台服务器上面做的服务器场模式安装的WSS3.0，SQL使用本机的2005标准版。服务器上带DC和DNS。
在安装完毕初始化以后，按照联机的帮助，启动搜索服务。服务帐号和内容访问帐号都是域administrator，但是出现错误提示信息“此服务器不是该搜索应用程序的索引器”。我找了一下，没有发现WSS里面配置应用程序的索引器的地方。
我接下来创建了Web应用程序，在创建站点集的时候，出现“因为服务器当前的配置不支持，所以无法显示该页。若要执行此任务，请使用Stsadm.exe中的命令行操作”。我在命令帐号测试了命令“stsadm -o createsite -url http://s1.zc.intra -owneremail wss@zc.intra”，提示错误“指定的域不存在，或无法联系。<异常来自 HRESULT:0x8007054B>”

问题发给了一些朋友，都还没有遇见过这样的问题。郁闷阿，在网上在搜搜看吧！

今天在看了cnbeta上面一文章：写的是上海一个电信用户如何通过投诉，最终电信遵守合同约定去掉在其拨号后强制弹出广告的问题，最后并总结了投诉的经验。其实这些经验在很多论坛已经很多人总结过了：不能嫌麻烦与运营商妥协；不断向运营商的上级主管部门投诉；要求书面回复；以前可以实现的功能、享受的服务要求以后继续享受。

其实简单得说上海电信的做法叫HTTP请求劫持，即把客户发送的HTTP请求进行转换，以致将客户的浏览器引导至特定的Web服务器。这个技术99年就出现过，不多当时是黑客所为。黑客查找互联网上的弱密码路由设备，在支持此技术的设备上面做劫持。黑客这样做的目的一般就只有两个，使被劫持的页面的带毒或者挂上木马。现如今，运营商的网络经验增多，黑客搞不了这些，电信却自己把这个技术拾起来，赚广告费了。被用来增收的还有114电话，114也不叫查号台了，改叫电话搜索引擎。114的特服费也涨价了，公益性质没有了……

现如今运营商都说自己的日子不好过，竞争激烈了、话费还得不断的降低、客户还容易流失，不得不想各种办法增收。可是我们看到的是：竞争的激烈没有改善运营商的服务，话费的不断降低换来的是运营商的收入不断增长，客户容易流失运营商却不珍惜，增收的结果是客户对其单方面违约不守诚诺越来越厌烦，甚至通过网上交流来总结投诉的经验。

那么问题在什么地方呢？竞争还不够激烈，产业结构还不够合理；电信运营行业是国有企业，但也是公共事业。我在华北地区观察了一些地市的运营商，凡是经常激烈的地方，价格竞争不再管用的时候，运营商的服务会逐步改善。在北京我的宽带断了一个星期，在不断向更高级别部门投诉的情况，花了几十块钱打投诉电话的情况下，问题才解决。这是因为北京的电信价格竞争被有关部门严格控制，没有竞争。而山东某地的网通承诺通信故障4小时解决，超时双倍赔偿，实际平均是1个小时解决问题。为什么？因为那里的固网有三家运营商，肯定地运营商更多，价格竞争过去以后，只能靠服务赢得客户。产业结构问题显而易见，南北运营商划江为界，还开始搞南北互相限速。

相应主管部门，没有尽到监督的义务，却在运营商之间和设备商之间搞利益最大化。也不知通信促进经济带来的社会效益大，还是经济促进通信行业的效益大。更有一些通信学术界为行业利益摇旗呐喊，某些人不方便说的话，不方便搞得舆论，由他们全面代劳了……

两个字：悲哀！

我是在用javascript生成Unix时间戳的时候发现的问题。

你可以在c:\创建一个test.js文件，然后把下面的代码粘贴进去，然后在命令行直接执行c:\test.js：

theDate=new Date("January 1, 1970 8:00");
WScript.Echo(theDate);
WScript.Echo(Date.parse(theDate));
secondDate=new Date(1969,12,1,8,0,0,0);
WScript.Echo(secondDate);
WScript.Echo(Date.parse(secondDate));
thirdDate=new Date(1970,1,1,8,0,0,0);
WScript.Echo(thirdDate);
WScript.Echo(Date.parse(thirdDate));

代码说明：这段代码是使用js的Date对象的两个构造函数构造了三个Date对象。第一个Date对象和第三个Date对象以不同的构造方式创建了同一个时间。第二和第三个Date对象使用相同的构造函数创建了不同的时间。

但是结果是：

Thu Jan 1 08:00:00 UTC+0800 1970

0

Thu Jan 1 08:00:00 UTC+0800 1970

0

Thu Jan 1 08:00:00 UTC+0800 1970

2678400000

这明显是矛盾的。我怀疑这是一个js解释器的问题。另外Date的UTC方法也有类似的问题。

老婆周五（2007-1-19）要去海淀妇幼医院去做定期产前检查，但是海淀的新爹似乎都很认这个医院，每天早上挂号都要几十米，6点以后到了几乎就没有可能挂到专家号了。最近可以网上挂号，可以提前三天，也就是今天（2007-1-16）凌晨可以开始挂号。好不容易等服务器时间跨过00:00，服务器立刻负载大增，进入挂号页面几十秒才显示，我一看这个情况，赶快改挂专科号，不容易，挂了一个3号，再看那五六个专家没人15个号，都挂满了…….

为了熬夜挂号怕误事，茶水喝多了，挂完号睡不着了。看这海淀妇幼的网上挂号运气，这个网站看起来一般，要不研究一下看看能不能去掉3天的限制。看看了他的html源代码，系统给定的日期代码不是直接的日期，而是一串数字。仔细看看，有点意思，给出的三个日期代码的数字串末尾一样，看来三个有关系。再看网站是PHP写的，立时怀疑三个数字串都是Unix时间戳。立时找来PHP for win32，给自己机器上装了一个，把它的数字串拷贝过去，用PHP拷贝按照Unix时间戳解码，没错都是Unix时间戳。在刷新两下，发现数字串变化，再解析，时间是刷新时服务器时间加3天。这就好说了，不用什么复杂程序，做一个html就能搞定。

把它的起始选日期的页面另存下来，手动修改一个2007-1-22的Unix时间戳，测试，可以挂2007-1-22的号了。这样基本程序原形完工。但是这样搞太麻烦，大家都是程序员，都是懒人，这个工作是可以自动完成的嘛！修改另存的页面，去掉选择时间，改成手动添年月日和一个Unix时间戳文本框。加一个按钮，在点击按钮的时候生成Unix时间戳，再点提交，进入指定日的挂号界面。到此界面就设计完成。

后面的计算Unix时间戳的程序费了老大的劲。很多年没有写js了，嗯，得有4年没有写js了。js里面有Date对象，但是忘了哪个方法管转换时间戳了，Google找了一个代码段，一测生成的不是标准的Unix时间戳。继续Google找，发现PHP的时间戳好像是毫秒戳，js的Date对象的是微秒戳，这个好办，微秒戳除以1000。嗯，时间戳可以了。后面如何把时间戳写进文本框，又找了一段代码作例子。这么长时间不写js真是不行了。再测试，成功！

犹豫了一下，还是把这个发布出来。毕竟现在当个新爹挺不容易的。不过大家手下留情，万一用的太滥，这个漏洞被发现了，有得自己受苦了。还有里面的html点击的时候，IE会自动把里面js禁用，这个时候要把屏幕上部的那个提示条，选择允许组织的内容。不然是算不出Unix时间戳的。

不放心的朋友可以自己检查源代码，我这里下载的是没有病毒的。还有就是我还没有测试是否能通过后面的挂号，测试过的朋友能用的话给我发个邮件，分享一下你们当新爹的感受。使用这个挂号程序会带来什么后果我也不负任何责任的，如果被医院发现说你挂得号无效，可和我没有关系，这可是你自己的老婆怀孕作检查。祝各位好运！

下载地址如下：http://blog.zhangchi.com.cn/downloads/guahao.rar

注:海淀妇幼好像现在不能网上挂号了。2010-8-23

二进制版本：http://blog.zhangchi.com.cn/downloads/batchconvert-1.0.1-bin.rar

源代码版本：http://blog.zhangchi.com.cn/downloads/batchconvert-1.0.1-src.rar

修改内容：

修改了一个由于iconv不支持Windows带空格的文件名导致的问题。

说明：这个错误其实就是我前面说的安全性问题。仔细分析了有关的资料，以及自己程序对错误的捕捉，发现问题并不在我的代码里面。然后捕捉了一下我隐藏的错误信息，发现是iconv没有找到要转换的文件，同时把路径识别成了三个文件。使用带引号的路径作为参数以后，问题消失了。

此外还发现一个不知道是Windows还是.NET Framework的问题，当然这也可能是我程序的问题。路径选取对话框在路径是Desktop的时候，预置路径不生效。这个还需要再次测试。

注:两个文件已经无法下载了

当需要转换的文件没有Users权限的时候，会造成转换失败。这个应该是启动iconv转换进程的时候，没有加权限的原因。很快我会修补上这个问题。

此外还准备加上文件类型的过滤。

sogou是一个很低调的公司，sogou拼音输入法似乎口碑相当好。这个免费企业邮局也相当不错，不像Google的hosts服务那样难申请，不像MS的Live Domains那样加广告。功能还全，我喜欢…

台湾地震带来的光纤断线，造成的影响越来越大……

前几天我发布的小工具里面用的libiconv费了我不小的力气：开始的时候是摆脱在微软的一位朋友帮我下载，后来是逛了不少的代理网站找了一个韩国的代理服务器在下载下来的，但是转天就不能用了。估计全中国的网民的流量把韩国人吓坏了……

今天早上收到了微软祝贺我获得MVP的邮件，可是到MVPAward网站怎么都上不去，只好给MVP Lead发邮件询问这个不马上激活会不会有什么问题。

中国的互联网基础建设比想象的差的多，断网这个事情就不说了，南北互联互通的问题更烦人。南电信北网通，本是同根生，却敢冒天下之大不韪，以一己之利，人为限制南北互通。上网的人都知道这个事情了，国家的管理者没人知道么？还是管理者都不上网？

中国的互联网软实力不断增强，不断有本土企业战败国际大鳄，但是基础建设却在变相的垄断之下……

唉，全是牢骚阿…

中文SPS2003发布的时候，正值2003年，.NET Framework 1.1和Windows Server 2003刚刚发布不久。但是随着.NET Framework 1.1的补丁不断出来，以及Windows Server 2003的补丁不断推出，即使SPS2003也不断推出补丁，但是还是有一些著名的小问题。比如中文的SPS2003的管理界面都变成了英文的界面。

这个问题估计可能不是SPS2003的问题，因为SQL Server 2000 Reporting Service也有类似的问题，解决的办法也是一样的。我最早发现这个问题是在2004年，当时.NET Framework 1.1 SP1刚刚发布。咨询微软的工程师，得到了support网站的一篇文章。文章里面讲由于.NET Framework 1.1 SP1的某些安全改进影响了.NET Framework 1.1的i18n解决方案，导致SPS2003的管理界面变成了中文。解决办法很简单，在创建的网站的web.config文件属性的“安全”里面，添加一个“Everyone”，并赋予“完全”的权限。这个方法在某种程度上会降低安全性，但是具体会带来什么危险，我也不清楚了。

最近，客户和我反映管理界面还是经常变成英文的，用上述的方法改一下，过一段时间就又会自己的变成英文的。我自己试了一下，发现上述的方法好像跟本不起作用了。我向客户了解了一下，最近对SPS2003做过什么处理，结果是客户最近部署过自己开发的WebPart，在web.config里面添加过SafeControl。我看了一下，发现web.config文件的编码被改成ANSI的编码了，修改为UTF-8编码以后，不用修改权限，管理界面就恢复中文了。再仔细研究了一下用户的使用习惯，她总是先下载web.config文件，用UltraEdit编辑以后，在上传回去。问题就出在UltraEdit，它在保存文件的时候，并不保持文件原来的编码格式，而是默认使用当前系统的默认编码(GB2312)来保存。不知道这个是UltraEdit的功能还是缺陷，或者其他人汉化导致的。

Reporting Service的问题也是类似的，我们做过一个安全插件，编辑过他的两个虚拟目录的config文件。把这些congfig文件的编码和权限调整过来以后，Reporting Service的管理界面也恢复正常了……

我在这里向大家推荐Editplus2编辑器，韩国人开发的，相当不错，支持在ftp里面直接打开，还可以另存到ftp上面。只不过好像国内没有代理商……

最近一直在做一个项目，以SOA为理念基于SPS2003的三个应用系统。后端以WebService提供服务，前端为嵌入SPS的UserControl，WebService与UserControl之间由序列化的对象进行通讯。由于开发环境是VS.NET 2003，所以就直接使用VSS6d来管理代码了，结果问题就跟着来了：VSS6d不支持UTF-8编码的程序文件以文本方式储存，否则就只能二进制方式存储。在开始阶段主要是开发WebService并没有什么问题，但是随着大量的UserControl开发出来并部署到SPS2003当中的时候，测试人员报告界面乱码。手工把ascx文件转换成UTF-8编码后，问题消失。

这样貌似问题解决了，但是以后每次重新编译部署的时候，都要把上百的ascx文件的编码手工修改一遍。修改编码成了一个极其繁琐的体力劳动……自己研究了一下，又请教了一下微软的工程师，有三个解决方法：

1. 在备份以后，重新把代码加入VSS的代码库，使用二进制方式存储代码。这会带来两个问题：一是二进制方式存储，在不同的代码版本之间不能做Different操作，二是二进制方式存储不再是层量存储，每签入一次，保存的都是一个完整的副本。
2. 使用VS2005 TFS来做代码管理。这需要在VS.NET2003内安装TFS的插件。这种方法微软网站上面介绍过，没有实践过。
3. 使用批量转换工具将ascx的编码转换过来。

我的项目现在只好使用第三种方式，但是找不到有批量的GB2312转UTF-8编码的工具，我只好自己写了一个。这个工具内部的转换引擎是GNU的libiconv，大家可以下载我编译好的版本直接使用，或者下载源代码自己研究。这个工具用.NET2.0写的，所以运行需要.Net Framework 2.0 Runtime。

细心的朋友会问我，为什么我只强调了ascx为什么没有提asmx呢？我当初也奇怪这个问题，后来研究了web.config文件里面的system.web段的globalization的fileEncoding属性约束了ASP.NET从本地读取程序文件的编码。在默认的ASP.NET项目的web.config里面是没有这个属性的，ASP.NET默认会以Windows的默认代码页来读取程序。而我们的asmx文件内部没有中文，即使有中文，ASP.NET也可以识别出来。

但是SPS2003创建的站点里面的web.config文件里面的system.web段的globalization的fileEncoding属性为"utf-8"。我测试了一下，这个属性删除以后，SPS也会有莫名其妙的错误，看来还是不能删除的。

这个题目肯定能增加我的访问量……

其实是我整理2004年的邮件，发现原来一个同事发给我的好玩的东西。这些都是Internet上面的发布的摄像头，可以看到一些地方的景色和风光，很有意思。他的邮件内容如下：

在google中搜索以下的关键字，可以找到有摄像头live的网页，窥视全球。

inurl:"ViewerFrame?Mode=”
intitle:"Live View / – AXIS” | inurl:view/view.shtml
inurl:indexFrame.shtml Axis
intitle:"Live View / – AXIS”
intext:"MOBOTIX M1″ intext:"Open Menu”
inurl:"ViewerFrame?Mode=”
intitle:"WJ-NT104 Main Page”
intitle:snc-rz30 inurl:home/

这里有很多webcam链接：
http://www.theone.se/linkto/axiscams.html

附几个Cam url:
http://80.97.109.10:40001/ 哪个国家的一间超市吖
http://80.120.31.51/ 车来车往的街市
http://62.202.1.153/ 美景，涌动的云呵
http://81.221.18.246/ 好美的地方，要是能去那里渡假就好了.
http://193.247.46.45/ 这又是哪里吖，滑雪好地方吖
http://81.75.78.45/control/userimage.html 这个具有管理权限哦…

Vista中文版在MSDN上面可以下载了，算是今天最好的消息了。我对Vista并不抵制，只不过想在更好的时机再换操作系统。我是2005年才开始完全接受WinXP，当我确认我的电脑足够跑这个操作系统，而且市面上的应用基本上都是支持XP了。现在我就在等便宜的运行Vista的电脑和满大街的软件都支持Vista X64，比如招商银行个人专业版。

说到招商银行个人专业版，不能不提最近delphij质疑新版的招商银行个人专业版的事情。

我和delphij是老朋友，在FreeBSDChina的时候认识的，还曾经在聚会上见过很多次。他是国内少数几个参与FreeBSD项目编写的人之一，虽然只有本科学历，但是技术造诣和道德人品已经有大家风范。

招商银行是国内服务顶尖的银行，曾经在一年内以中国银行业总资产1%创造了中国银行业总利润的5%。我第一张招商银行卡是在2000年时候办的，这当中还有许多学校时候的美好回忆，2002年到北京以后办了第二张一卡通，2004年办了第一张招商银行的信用卡。直到现在我的一卡通和信用卡仍然是我的主力储蓄卡和消费卡。我对招商银行也是支持的。

但是这次的事情我支持delphij。招商银行作为专业银行，以银行名义发行的个人金融管理软件应该相对的安全。但让人意想不到的是竟然引入了第三方的二进制代码，而没有对其作审计；此外这些第三方的二进制代码的目的是要过操作系统的安全机制，而没有做任何保护。这两方面可能导致连个后果：

1. 未审计的代码中含有第三方特殊目的的代码，窥探用户信息数据。
2. 这些第三方的二进制代码的接口被病毒、木马、流氓软件利用，绕过系统安全机制，作更大的破坏。

这两种后果估计是任何一个招商银行个人专业版的用户都不会接受的。招商银行不应该允许这样草率的软件被安装到客户的电脑上，招商银行应该彻查这件事，并对此引以为戒。让我们与delphij一起来关注这件事情的进展！

把Blog的程序升级到了DasBlog1.9。把页面的Theme也换了。

DasBlog的升级没感到什么太大的变化，新的Theme还是不错的，界面清新，最主要的一点是速度快。我是忍受够了那个名叫dasBlog的Theme。

随着Blog程序的升级，速度的加快，Blog的更新也要加快了。

酝酿这个Sharepoint中文wiki好久了，今天终于敢在Blog里面大吼一声SharePoint中文Wiki发布了。感觉就像自己的一个孩子终于生出来了。

开始想做这个Wiki是因为SharePoint的中文资料很少，学习SharePoint的话除了残缺很多内容的管理员联机文档以外，就只有英文MSDN上面SDK和几篇英文文档。很多学习SharePoint的朋友都和我提起过，他们的英语不好，只能从国内少数的中文博客当中找到一些资料，但是这些都是残缺不全的东西。现在SharePoint随着Office2007的到来，新版本也马上要开始面市了，这个时候一个中文的权威的SharePoint相关文档显得尤为重要。这些是开始建设SharePoint中文Wiki的初衷。

只有初衷还是不够得，还得要具体对内容的想法。我的想法是以中文的原创参考资料为主，辅以其他的一些中文的开发技巧。这是因为如果以翻译为主的话，翻译的原稿只能是来自微软的文档，具体的说就是微软的MSDN中的SharePoint的SDK。我们知道微软的文档和其翻译后的文档版权仍然属于微软，直接翻译会有版权方面的诸多麻烦，因此我计划以中文原创的参考资料为主。这样的话，SharePoint中文Wiki的内容和发展就离不开大家的广泛的大力的支持。希望大家博客里面的内容可能贡献给SharePoint中文Wiki，来增加SharePoint中文Wiki的内容。

现阶段，SharePoint中文Wiki已经发布了，通过连接可以直接访问，但是里面的还没有什么内容。现在我主要在翻译PmWiki的标签语言的简单语法手册，这个工作量并不小，有幸的是我在Emacs中文站找到了他们翻译的这个语法手册。这样可以极大地加开这部分工作的进行速度。同时Emacs中文站也是一个完全基于PmWiki的网站，他们创建网站的经验对于我们创建完全基于Wiki技术的网站有很好的借鉴价值。

说了这么多，最后还是祝愿SharePoint中文Wiki可以越办越好，内容越来越多，越来越权威。这还得靠大家不断的支持。

呵呵，这个事情不说了，还要给微软的俞晖封一个“首席社区执行官”。真是可笑啊~~~

连接地址：http://blog.csdn.net/gehantao/archive/2006/09/06/1185568.aspx

富士康和记者的官司现在看已经告一段落了，这里面有很多娱乐明星值得学习的东西。只是不知道这些娱乐明星有没有时间看看科技新闻。

前一段时间阿姣被人偷拍，我觉得应该先报警，再控告偷拍的记者，来一个巨额的索赔，然后要求法院冻结记者的财产。我想这样一来狗仔队的记者就会掂量一下，被冻结财产以后的再和明星打官司的难度。

中国的记者历来以读者的名义，窥探他人隐私，按照自己的喜好来报道新闻，而在大是非上又没有原则。

准备把笔记本电脑的内存升级到2G。我可以开始我的MOSS2007之旅了。

我在Blog上面开通了一个网上红包的快速通道。好处比较多，省事情，不用去银行，没有假钞，不用管家。但是第一次这样搞，饭局现场还是收现金的。

以上的按钮就是使用快钱作的捐赠按钮。这个和右边相片下面的按钮等价。

第一次尝试，欢迎大家支持。

注:按钮的链接失效了，仅留图片以作纪念。2010-8-22