其实是以前找到的一个问题了，不过今天提到了编译器的版本，突然想起了它。在国内的网站上似乎很难搜索到关于这个问题的报告，因此写出来供分享。
事情的起因是服务器版本的升级。以前我们的程序都是在一台 RH 7.3 的内部服务器上编译的。编译之后的程序拿到正式服务器（RHEL AS 3.0）上使用非常正常，因此一直以来都是采取的这样的方式。
后来新增了一台服务器，是 x86_64 的 CPU，我们就打算安装最新的 RHEL AS 4.0 Update 3 for x86_64 版本，以获取最新的技术带来的优势。虽然最终因为短期内 Oracle 中的数据和设计无法升级到预计的 10g Release 2 for x86_64 版本，而导致升级计划暂时搁置，但在升级过程中，就发现以前的代码出现了许多问题。
当然，2.96 的编译器和 3.4.x 的编译器之间，肯定是有着不小的差别，因此代码会有问题这早就在我们的预料之中。大部分的错误都是容易发现和容易排除的（另文介绍），但其中有一个棘手的问题，就是本文要说到的，fstream.open() 的打开模式问题。
在以前的代码中，我们一直使用 in|out|app 的模式来进行日志文件的打开。采用这种模式，如果文件不存在，那么系统会创建它，如果文件存在，那么打开它并从最后面开始写信息，同时也可以从中读信息。可以说，针对那种以当前日期命名的日志文件，这种打开模式组合是再合适不过了。
然而，编译器升级之后，我们发现这样的打开模式再也打不开任何的文件了。文件既不会被创建，也不会被打开，即使是这个文件已经存在也不行。去掉 app 或去掉 in，都可以正常打开文件，但是这样就牺牲了追加或是读取文件的能力。相比而言，out|app 的打开模式对于我们的日志类来说应该是可以接受的，但是为了了解这个问题的根源，我们还是花了不少力气。
还是 Google 好用。当我们发现这个问题确实是编译器的升级带来的，与操作系统内核、文件系统读写权限、路径/文件名等因素无关之后。我们很快就在 Google 上搜索到了这篇文章：
http://gcc.gnu.org/ml/gcc-bugs/2002-04/msg01055.html
这位老兄发现了和我们类似的问题，并上报给了 gcc 那边。当然，他的工作比我们要做得细致得多。他仔细测试了多种打开模式的组合，并在多种平台、多种编译器版本上做了测试，并得到了结果。没有耐性点开帖子看或无法访问国外站点的用户可以看看下面这个测试结果：
GCC 2.95.2 i686-pc-linux-gnu
open("ios::in", O_RDONLY|0x8000)
open("ios::out", O_WRONLY|O_CREAT|O_TRUNC|0x8000, 0664)
open("ios::in|ios::out", O_RDWR|O_CREAT|0x8000, 0664)
open("ios::in|ios::ate", O_RDONLY|O_CREAT|0x8000, 0664)
open("ios::out|ios::app", O_WRONLY|O_APPEND|O_CREAT|0x8000, 0664)
open("ios::out|ios::ate", O_WRONLY|O_CREAT|0x8000, 0664)
open("ios::out|ios::trunc", O_WRONLY|O_CREAT|O_TRUNC|0x8000, 0664)
open("ios::in|ios::out|ios::app", O_RDWR|O_APPEND|O_CREAT|0x8000, 0664)
open("ios::in|ios::out|ios::ate", O_RDWR|O_CREAT|0x8000, 0664)
open("ios::in|ios::out|ios::trunc", O_RDWR|O_CREAT|O_TRUNC|0x8000, 0664)
GCC 2.95.2 sparc-sun-solaris2.8
open("ios::in", O_RDONLY)
open("ios::out", O_WRONLY|O_CREAT|O_TRUNC, 0664)
open("ios::in|ios::out", O_RDWR|O_CREAT, 0664)
open("ios::in|ios::ate", O_RDONLY|O_CREAT, 0664)
open("ios::out|ios::app", O_WRONLY|O_APPEND|O_CREAT, 0664)
open("ios::out|ios::ate", O_WRONLY|O_CREAT, 0664)
open("ios::out|ios::trunc", O_WRONLY|O_CREAT|O_TRUNC, 0664)
open("ios::in|ios::out|ios::app", O_RDWR|O_APPEND|O_CREAT, 0664)
open("ios::in|ios::out|ios::ate", O_RDWR|O_CREAT, 0664)
open("ios::in|ios::out|ios::trunc", O_RDWR|O_CREAT|O_TRUNC, 0664)
GCC 3.0.4 i686-pc-linux-gnu or sparc-sun-solaris2.8
open("ios::in", O_RDONLY)
open("ios::out", O_WRONLY|O_CREAT|O_TRUNC, 0666)
open("ios::in|ios::out", O_RDWR)
open("ios::in|ios::ate", O_RDONLY)
open("ios::out|ios::app", O_WRONLY|O_APPEND|O_CREAT, 0666)
open("ios::out|ios::ate", O_WRONLY|O_CREAT|O_TRUNC, 0666)
open("ios::out|ios::trunc", O_WRONLY|O_CREAT|O_TRUNC, 0666)
open("ios::in|ios::out|ios::ate", O_RDWR)
open("ios::in|ios::out|ios::trunc", O_RDWR|O_CREAT|O_TRUNC, 0666)
Sun CC 5.0 sparc-sun-solaris2.8
open("ios::in", O_RDONLY)
open("ios::out", O_WRONLY|O_CREAT|O_TRUNC, 0666)
open("ios::in|ios::out", O_RDWR)
open("ios::in|ios::ate", O_RDONLY)
open("ios::out|ios::app", O_WRONLY|O_APPEND|O_CREAT, 0666)
open("ios::out|ios::ate", O_WRONLY|O_CREAT|O_TRUNC, 0666)
open("ios::out|ios::trunc", O_WRONLY|O_CREAT|O_TRUNC, 0666)
open("ios::in|ios::out|ios::app", O_RDWR|O_APPEND|O_CREAT, 0666)
open("ios::in|ios::out|ios::ate", O_RDWR)
open("ios::in|ios::out|ios::trunc", O_RDWR|O_CREAT|O_TRUNC, 0666)
他得到了几乎所有有用的 fstream.open() 打开模式组合所对应的实际操作。可以看到，编译器版本的影响确实很大。
可以注意到，gcc 3.0.4 与 2.95.2 的测试结果相差不小。而且，最重要的是，有效的测试结果中，没有 in|out|app 这种组合。作者在最后发问，这种打开模式组合没有出现，是 bug 还是别的原因？可想而知，所谓「没有出现」，就是指这种打开模式组合总是会失败，相当于无法使用。就和我们遇到的情况一样。
再次的搜索，发现一年之后 gcc 那边出现了这样的帖子：
http://gcc.gnu.org/ml/gcc-prs/2003-04/msg00771.html
这是 gcc 开发组的人（应该是吧）发的，具体地说，是 paolo@gcc.gnu.org。帖子大概是针对一个 bug 报告的回应，内容就是说 in|out|app 这种打开模式组合根据 ISO 标准是非法的，无效的，因此这个 bug 报告可以 close 了。ISO 标准，应该就是 gcc 3.x 所遵循的 C++ 标准了。
至此，真相水落石出。我们也就安心改用 out|app 模式来写日志了。
2006-06-30
不同版本 GCC 编译器的差异真是让人吃惊
做了一个程序，测试用的，在一台 RHEL AS 4.0 的机器上做编译。编译完之后瞄了一眼文件大小，1837684。吓了一跳，因为我记得以前类似程序都在 2M 以上的，怎么这次小了这么多？难道我漏了几个模块？
去正式服务器上找程序一对，果然，大小差了不少。正式服务器上的程序是在一台 RH 7.3 的机器上编译的。为了验证到底是源代码有不同还是编译器的差别，我把刚才编译的代码上传了一份到 RH 7.3 的机器上，用同一个 Makefile 编译，编译完的大小是 2617012。
对比了一下两边编译器的版本，RH 7.3 这一台是 2.96，RHEL AS 4.0 那台是 3.4.3。版本差别的确比较大，但编译的结果差别也真的不小。除开链接的库，单单看这个程序的 .o 文件，大小竟然差了一倍多。以前没有在这方面比较过，确实有点惊人。
我又去找来了 upx，2.00 for linux i386 版本。用默认选项压缩的结果，更令我吃了一惊。RHEL AS 4.0 这台上，压缩之后的大小是 535802，而 RH 7.3 那台上的较大的那个执行程序，压缩之后只有 384610，反而拥有较大的压缩比和较小的压缩后尺寸。
不好解释了，也许是 2.96 的编译器生成的代码中，垃圾比较多，而有用的部分反而比较少吧。和内核的系统调用也许也有关系吧？两台机器的内核差别也挺大的，一个是 2.4 一个是 2.6。
记录下这个情况，以供参考。
2006-06-29
《C Traps & Pit Falls》读后偶感
内容有点旧，不过看过之后还是有一些收获。
其中有一段很有趣的回忆：
|
……我还记得自己在开发某个系统时，曾经与一个用户有过这样一场对话：
「这部分记录中可能出现的代码有哪些？」 「可能的代码是 X、Y 和 Z。」 …… |
看到这里，忍不住直想发笑。昨天我还遇到类似的对话来着。美国人就是会搞笑，我当时怎么没有想到这样幽他们一默呢？
美女点名做题目，有点兴趣
被美女点名回答这些问题，我也真的相当认真，呵呵。
- 近期要实现的目标是什么？（换工作，争取去外企。）
- 要是你的旧情人因你发疯，你咋办？（陪她发疯。）
- 会不会同时爱上两个甚至更多的人呢？（会，但有结果的必定只有一个。）
- 假如生命只有一天最想干什么？（打开 Word 写墓志铭和遗嘱。）
- 一个人对你温柔体贴关爱倍加，另外一个人让你爱的近乎发狂，却对你不冷不热甚至有点不解风情，你会选择谁？（两个都不选，我想我现在还有这个资本可以追求一下完美。）
- 你相信有外星人吗？（不相信，我只相信有外星「生物」。）
- 你认为人最重要的品行是什么？（四川话念：做人要厚道。）
- 你心目中认为最好的城市在哪里？有什么优点？（目前是福州，因为感到亲切，到了那里就有一种如鱼得水，很自在的感觉，不知道是什么缘故。）
- 到目前为止，自己拥有最宝贵的东西是什么？（头颅，和里面的那包草。）
- 当你工作遇到不想做的时候怎么办？（「更衣」去。）
- 看过日本侵华相关的文字图片和记录片吗？你对日本犯下的罪行怎么看？（那个民族本来就有问题。）
- 朋友点名让你做游戏，你做不做？（那要看这「朋友」是谁，面子不够不做。）
- 近期关注的话题有哪些。（睡觉。）
- 最希望所爱的男人 / 女人对你做的一件事情是什么。（好好活着。）
- 如果你突然有了 100 万，你想怎么花。（先买一台笔记本电脑，配上 2G 内存。）
- 如果你发现老公/老婆有了外遇你会怎么办。你的第一反映会如何。（震惊。）
- 你的理想是什么。（退休。）
- 你的梦想是什么。（现在就退休。）
- 最近最满意的一件事情是什么。（身体现在还不错。）
- 最近最失败的一件事情是什么。（上上周生了病。）
2006-06-28
日记 2006.06.28
Chapter One
早上上班，又遇见了那个女孩。
这个周一，我刚回厦门，中午在帝豪的麦当劳吃饭时，无意间遇到了她。以前在上班路上也不时有相遇，给我的感觉还蛮特别的。娇小的身材，却有一股与其他人不同的气质，老远总是能一眼看出她来。没想到她在离我住处这么近的地方上班。
我想我是对她有点感觉了。呵呵，她可能还没注意到我吧。每天目送一次，不用关注太多，也挺不错的。
Chapter Two
有一个同事没有来上班，估计是病假。
我手下来了不到半天，也请病假了。看她早上趴在那里就知道不对劲。身体不舒服干脆就不要来，我提倡养兵千日用在一时。
突然下起大雨，瓢泼大雨。这天气就不对劲，难怪那么多人倒下。
Chapter Three
今天是老头子的生日。晚上打个电话回去，顺便分享一下上海之行的心得。
要是 Google Earth 把重庆的地图改成高清就好了，都不用我送什么生日礼物了。
解决了紫光输入法造成的一个奇怪问题
刚才写博客的时候，遇到一个令人恼火的问题。
在正文框中写文字的时候，好几次都遇到了输入文字之后无法删除的麻烦。刚刚还好好的，突然就不行了。连复制粘贴和选择文本等功能也一并失效了，搞得我很是郁闷。因为根据以前的经验，这种问题一旦出现，最有效的解决方法就是刷新网页。
一刷新那内容不是都没了？又无法拷贝出来。平时遇到这个问题的机会还不大，但今天总是遇到。这样子搞了三四次之后，我彻底失去耐性了，开始查找到底是什么原因引起的。
最后发现，问题居然是我使用多年的紫光拼音 2.2 引起的。如果在中文输入状态下敲一个音节敲一半就 Ctrl-Space 把输入法关掉，就会出现这个毛病。解决方法也很简单，重新打开输入法，在中文输入状态下敲几个拼音字母，然后把它们删掉，就OK了。
也许紫光 2.2 是太旧了一点。但 2.3 在 Win2000 下有问题，3.0 和 4.0 用过，都觉得不爽，最后还是装回 2.2。以后有机会试试看别的输入法了。
JS 在 URL 转码时遇到的加号问题
URL 参数中出现了半角的加号，因此需要转码。
相关 JS 函数有 encodeURI() 和 encodeURIComponent()。根据 MSDN 的说法，使用了 encodeURI()，无效，加号还是加号。
encodeURIComponent() 是对所有的字符进行转码。根据 MSDN 的说法，它只是额外对「/」、「?」等字符进行了处理，并没有提到「+」字符。然而实验对比的结果，encodeURI() 不处理半角加号，encodeURIComponent() 处理。
看来 MSDN 也有不少问题。也许是因为我的 MSDN 比较老的缘故？可能吧。
2006-06-27
日记 2006.06.27
Chapter One
婉拒了昨天上海蒋先生关于让我去深圳的提案。因为根据昨天晚上综合分析的结果，这个提案对我而言吸引力实在不高。再说我现在还远没有到「山穷水尽」的地步，就请允许我再花些时间寻找自己的理想吧。
正如我以前所说。也许终究有一天，我会落到被迫接受无奈的现实的地步。也许是我结婚生子，也许是我「年老色衰」，也许是我 $#%&$*&。但起码在那之前，我还想按照自己的想法活下去，找寻下去。
少年游，或许才刚刚开了个头……
Chapter Two
许久没有上过 CSDN 了。今天为了找一个很麻烦的问题的答案，登录了它，于是又开始了看贴、回帖 / 不回帖的过程。
我大概不会成为一个 CSDNer。因为我每次登录 CSDN 都不会维持太久的时间，大多是为了一两个真正会成为疑难杂症的问题而去找答案或发帖。而这种问题往往也不会得到回复，即使我已经描述得很详尽。我想，我找不到答案的问题，恐怕别人也很难找到了，除非机缘巧合有人刚好经历过。
我挺喜欢帮助别人的。但是有的人贴上来的大段大段的代码，我实在没有工夫去慢慢看。因此我会回答的一些问题，往往都是那种问到了点子上的问题，或者是基础性的问题。问问题能问到点子上的人，往往点醒他也比较容易。不过这样的人能力往往也不错，因此很可能后面也就比较少问问题了。所以我捞分的机会也不多，目前最多的还是以前在 Lotus 区混下的九百多分。
我有些奇怪，那些成天呆在 CSDN 上的人，哪来的那么多空闲时间？有的人确实技术很过硬，但是从回帖的次数、时间和频率来看，似乎有些闲得可怕了。我也不好妄下断言，以免落个「自以为是」的名声。因此只好羡慕他们，可望而不可及啊！
Chapter Three
www.shouji88.com（已失效）
芙蓉姐姐之后，第一次遇到这么强的人。
当然，上次在 CSDN 上有看到一个家伙，自称发明了一个世界领先的排序算法，还拿自己的名字来起名，YY 得也够可以，不过还是及不上这个大仙。
这位简直就是精神病医院跑出来的，不仅 YY，似乎还有强迫症的症状。这么搞笑的事情，说得一本正经，还去伪造一份政府通知，在标题里面生生塞入他的两个字。被人指出这一点之后一点反应也没有，唉……。我都不知道他到底是活雷锋专门来给压力重重的大家提供一点笑料呢。还是真的把这些事情都当了真？若真是后者，那可真的是应该去精神病医院让大夫给好好看看了。
不过，想想，这是写程序，我是懂这个的，CSDN 上的人也都是懂的，所以在我们看来这是笑料。换作普通人呢？那个什么脑白金，在医学家、药物学家眼里，恐怕一样也是笑料，我们却趋之若骛。我开始有点笑不出来了……
06.06.26 世界杯观后感
不喜欢澳大利亚，也不喜欢意大利，虽然我是尤文的球迷。
比赛完全没有评论的必要，包括那个点球的判罚。因为，所有的风头都被黄建翔抢去了。
他嘶声喊到第六句的时候，我实在受不了而按下了静音按钮。真是太恶心了，像吃到苍蝇一样。激情归激情，但你是 CCTV-5 的现场解说员，你知道你的声音中国有多少人会听到吗？我并不介意他说什么「意大利万岁」，也不介意他说什么「灵魂附体」。但是我就是感到恶心！再不把他的嘴捂上，大概我也快要发疯了！
今天早上来看网上的评论。黄建翔都快被骂死了。当然，也有一些人挺他，理由是他「够激情，够男人，真球迷」。看到这些苍白的理由，直想发笑。歇斯底里的女人不知道该不该也算作「真男人」？有激情自己回家找老婆疯去，强奸观众的耳朵真是恶心。没错，喜欢意大利、崇拜意大利、赞美意大利，发泄自己的激情，是你黄建翔自己的自由。但是你不能因此而损害别人的自由。堂堂 CCTV-5 的王牌解说，解说席可是连着千家万户的电视，不是你个人玩闹的地方。更何况那种声音毫无美感之言，听多了大概晚上也会做噩梦。
有人反问：你不爱看黄建翔这样「激情」解说，难道愿意听罗京的解说？我想说的是，这种人就是典型的二元思维，应试教育的失败产物。黄建翔和罗京根本就不是二者必取其一的关系，根本就不是「非此即彼」的对立面。如果是选足球解说员，我两者都不喜欢！罗京是名好的播音员，但他不适合足球解说的工作，那需要激情没错。黄建翔的疯狂让我觉得他应该被淘汰，至少需要深刻反省！我就不相信，世界上就只有这两种风格的解说。看 NBA 的直播，知道了 CCTV-5 的解说很烂。看了 ESPN 和 TNT，也知道了解说员的境界层次是可以有无数多级。疯狂的黄建翔我不喜欢，拜托找个更好的来。
我无意评价他这样做的对错，但显然，做大赛的评论他不是很合适。让观众听了想捂耳朵，想关电视，无论如何也不能说这次解说是优秀的。
连带地，我想我以后一段时间内会对意大利队产生一定的厌恶情绪。不过我觉得很奇怪，黄建翔不是巴西球迷吗？什么时候换口味了？
2006-06-23
06.06.22 世界杯观后感
工作时间，等编译的同时抽空简单写一下。
捷克很可惜地输了。比赛完全进入了意大利的节奏。又高兴死 dzxr 了，不过我还是比较喜欢捷克，特别是那坚毅的 Nedved。
第一次见他，是在 96 欧洲杯上。当时他头发还短短的，愣头青的样子。当时并不喜欢捷克，因为媒体对它捧得很厉害。但对 Nedved 的印象挺深。印象中在右路活动比较多，还以为是右边后卫，心想这家伙助攻得也太多了点。
后来他去了尤文，此后熟悉了，每次玩 WE 系列，都是我第一个签入的大牌球员。确实也很好用，可边可中，可前可后，跑不死，脚头又硬又准，技术不错且均衡，抢断也超级厉害。
昨天的比赛也是如此。在中场他抢断了无数次，只要哪个家伙脚下的球被他瞄上，若不及时传出去，那基本上就被断掉了。如此多的抢断，却连犯规都很少，身体、气势、意识和技术，仍有当年之勇，仿佛不见老。
全队有威胁的进攻，都与他有关。三脚最具威胁的远射，也都是他的作品。可惜，这样的人才还是没法带队进入淘汰赛。斯基是真的老了，也许是速度型球员的宿命吧。Rosicky 的状态也不好，而且我认为这是因为他的身体在意大利防守球员面前丝毫也占不到便宜的结果。大个子无法上场，卡纳瓦罗那略微的身材劣势也就完全不复存在。于是就只有铁人在中场不知疲倦地回抢，在禁区前沿一次又一次地怒射……
2006-06-22
06.06.21 世界杯观后感
晕乎乎地看完了葡萄牙和墨西哥的比赛。本来还是比较喜欢葡萄牙，但是这场比赛大部分主力都没有上，最后马尼切这样的队员居然成了场上主角。不过配合还是一如既往的细腻，也一如既往地「小」。
下半场特别想睡觉，葡萄牙 11 打 10，还被人压着打。中场失控的同时，后 / 中 / 前场三线一起脱节。边路也打不开，西芒累了，感觉体力一般，而菲戈确实是老了，回想六年前欧洲杯上多风光啊！
拼得要死，牌也多得可怕。快终场时大家的体力都不行，裁判大概也累了，出牌也是有气无力的。
只留下了这些印象。很想看第二场比赛，可实在撑不住了……
2006-06-21
福建电信短信业务升级测试中遇到的一些问题
昨天测试「通过」了，今天把过程中遇到的一些问题写下来，免得以后忘掉，而且也许会有用处。
1. 业务梳理中发现，电信的匹配规则比移动和联通都要严厉
如果一个业务代码，在 SPOA 上填写了以长号码 XXXX01、空指令匹配上行，那么下发的时候，不但 LinkID 要原样回复，业务代码只能写这个，而且长号码也不能自己随意写，必须写这个 XXXX01。当然，如果匹配规则是模糊匹配，那么扩展长号码是允许的。
这样一来，那种利用一个入口指令实现转向到各种不同资费的业务上的做法就行不通了。不过，测试中摸索出了电信网关的处理逻辑，也就是具体鉴权时的做法。也不像上面所说的那样无懈可击。
电信网关的处理逻辑，应该是在上行的时候生成了一个 LinkID。下行鉴权时，检查 Submit 短信中的长号码和 LinkID，将其和上行时的内容一起再次用业务代码上配置的匹配规则进行匹配，若能通过，就放行。
由此可见，如果以 XXXX01 为匹配规则的业务如果想要以长号码 XXXX02 下发，只要增加一条匹配规则：长号码 XXXX02，内容为空 / 模糊，就可以下发成功。由于电信 SPOA 将同样的长号码的精确 / 模糊两种匹配模式视为不同的匹配规则，因此可以利用这个来实现不同业务代码之间的转向。
不过，这要求在业务申报 / 梳理的时候必须很精细。而且，后面会提到一个问题，可能导致更麻烦的情况。
2. 交叉/嵌套关系的匹配规则的匹配优先级问题
应该说，这个问题对于任何一个匹配为己任的系统，都是一个问题。有的系统显式地指定规则的应用优先级顺序，有的系统采用最长匹配等方法来自动判定优先级。从电信 SPOA 看来，它用的显然不是前者。
那么是否有进行某些智能化的匹配方法呢？我们做了一个实验：
(1) 配置一个定制类业务，长号码 XXXX01，命令字 01，均为精确匹配。
(2) 配置一个点播类业务，长号码 XXXX01，空指令，均为模糊匹配。
(3) 终端上行 01 至 XXXX01，发现收到了点播的 Deliver。
由此可见，至少，电信的网关在处理这种明显的包含关系的匹配规则的时候，是没有处理好的。匹配到的结果，我认为很可能是无法预测的。
因为这个问题，导致了在业务申报和梳理的时候，必须更加地小心，特别针对多次申报 / 业务管理员多次更换、交接的情况。
3. 定制类业务的二次确认问题
此次测试，电信强制让所有的定制类业务都有了二次确认。虽然不好说是否和移动、联通一样是可以逐个业务进行开 / 关的（很有可能），但起码测试的时候是全开的。
二次确认的短信，是网关自行发送。长号码为 XXXX0001 这样的形式，后四位应该是一个流水号。回复此短信（无需一定要是 Y），就可以定制成功，网关接口就会收到「DG + 业务代码 + ……」的短信。
订购成功之后，若把这条短信翻出来再回，网关接口就会收到发往 XXXX0001 的信息。若是有业务的匹配规则定在 XXXX0 附近，就要小心了。相信每个业务都做好错误处理的话，应该问题不大。
大的问题是，网关有时候会把用户回复到 XXXX0001 的短信直接丢到 SP 这边来，而且没有 LinkID，这就要命了。我希望这只是网关接口还不够稳定的原因。
4. 「错误提示免费业务用 10 个 0，即 0000000000」
很抱歉，电信没有类似移动的帮助代码，因此除了包月 PUSH 之外，绝对无法主动下行了（割接之后）。
福富软件今天在 SPOA 上抛出了一个所谓「免费的错误提示业务代码」。其实我们早就问到了。关于这个东东的具体用途，其实是用来对那些没有匹配到任何业务上的上行短信进行回复的。它也必须跟 LinkID，肯定是不收费的，除此之外和一个普通点播业务没有太多区别（上下行频率未知）。
匹配到某个业务上的短信，是不能用这个业务代码去回的。
5. 定制和退订的同步关系短信
这其实是网关测试时遇到的问题，不过在业务测试的时候进一步证实了。
根据 SMGP 3.0 协议，定制和退订成功之后，SP 的网关接口会收到一条同步定制关系的短信。也是根据协议，短信后面的发送方号码和发送内容是可选的。不过在网关测试的时候，却是严格都要求带上。
这次业务测试的时候，也是如此，所以，就把它们当作必须的吧。
6. 00000
发 00000 到电信那边，按照协议，会直接退掉所有业务。SP 这边会收到 00000 的短信，回不回它都没有什么问题，不过，「最好是回」（原话）。
有一个问题来了，用什么资费代码回？询问福富软件的结果，是说填「空」。我们只好理解为无内容了。发了之后，没有状态报告 DELIVRD，不过也没有 UNDELIV。询问的结果，是「正常」。
姑且认为正常吧。
日记 2006.06.21
Chapter One
因为大厅里的人员多是 Outside，老板觉得时常人气不够，于是指示我们里面的某些人员和大厅里的换位置。
今天早上来，换过位置。老板来上班，又觉得外面太吵，「像菜市场」……
方式方法的确很重要。
Chapter Two
因为一个贤惠的女同事拿自己做的糕饼分给大家吃，居然引发了一场关于男人和女人的大讨战。
由此，也进一步明晰了谁是大男子主义者，谁是女权主义者。
我，还是那个时不时抓别人漏洞讽上两句的反对派分子。
没办法。中庸，就无法立出鲜明的论点。而鲜明的论点，一般不会和偏激无缘。奇怪的是，学校的教授们，往往却不懂这一点。
或者说，装做不懂。
Chapter Three
厕所的小便池，又没有冲。
墙上贴着的「便后请冲水」，似乎只是贴给外国人看的。既然这样，干嘛不用英文写呢？
冲掉那浑浊的液体的时候，在同情那个人的健康。尿液浑浊不是蛋白尿就是有炎症，但也许他还浑然不觉吧。
Chapter Four
窗外烈日炎炎，窗内天寒地冻。
穿着外套，还得拉上拉链。走到中央空调的控制器前面一看，被人开到 15 度以下。还好不是政府，不然被「好事者」知道就要有微词了。
还记得去年有一次，一个办公室的空调开到 5 度，晚上走人时忘了关。第二天来的时候，玻璃上一层雾气。让人恍惚间有种冬夏颠倒的错觉。
真想把那些二十几度就开空调的人，拖去重庆绑在外面「受刑」。
NBA Live 2000 战报 060621
上一场偷懒没有写战报，部分原因是因为打得很郁闷。命中率相当低，防守也不好。
今天对阵小牛。诺天王被电脑拿去和胖子沃克作了交易，元老只剩下了芬利，实力大减，几乎已经是乐透区球队了。
第一节科比 6 / 6 拿下 13 分，不过沃克罚了不少球，还让布兰德两犯。
第二节麦蒂挑大梁，篮板球也不输对手。替补特科格鲁在节末连中三记三分。不过半场结束前，两个控卫都三犯了，只好让第三控卫上场。布兰德也三犯了，下半场开场实力弱了不少。
第三节比较困难，易边之后由于进攻方向改变的缘故，我的进攻好起来的同时，防守也弱了下去，篮板也失控了。第三控卫 Otter 发挥比较出色，本节结束时拿到了 10 分 9 助。科比和麦蒂的得分都逼近了 30。但小牛拿到了 79 分，看来防守任务（压制对手得分在两位数）是不太可能完成了。
因此我索性在第四节加快了进攻节奏。小牛显得有些不适应，被我慢慢拉开了比分。科比第四节 16 分。最后他和麦蒂联合拿下了 80+，总共出手不到 40 次。
特科格鲁贡献 19 分，中锋和布兰德也各自 10+。得分超出对手 39 分，进攻尚可。但在防守上还是不到位。让对手拿到 100+ 不说，对方的小前锋也拿下了两双。胖子沃克靠 30 次出手拿下 30+，新秀控卫也依靠 10+ 的罚球拿下 22 分。总的来说，还是算失败了。
2006-06-20
2006-06-19
2006-06-18
中病初愈后的一个周末
输入了以前的一些日记，十多二十篇吧。总数有一百来篇呢，还是慢慢来好了。休息一下，说一下近来的概况。
上个星期，生了场不大不小的病。先是周日的时候，左边颌关节发炎。早上起来就觉得不太对劲，张嘴不利索。越来越严重，到了晚上连吃饭都成了问题。一夜睡过去，第二天早上连软软的蛋糕都只能撕成小片用手来塞进去了。
由于有不得不做的工作，因此还是挣扎着来到公司上班。心里想的是这样不行了，脑子里浮现的是华为那个不幸的学长，开始紧张地留意脑子有没有不对劲。还好因为事先就已经考虑得比较周全了，11 点的时候就完成了那个不得不做的工作。立刻请了病假，回去睡觉。
断断续续睡了三次，睡得还算不错，但人的总体状态越来越糟糕。中午煮了碗麦片吃，而晚上已经不敢吃东西了，因为一起来就头晕。还好，她一直在和我联系。我告诉她我可能不得不要去医院了，她就赶了过来。
在医院，被口腔科的医生告知，颌关节发炎根本没办法，最多冷敷。医生两手一摊，说这个与手脚被扭到是一样的毛病，只能等它自己慢慢好。此时胃也开始难受，不知道是因为没吃东西还是要吐。又去看内科，体温量出来说 36.9，但是白细胞和中性粒细胞都超了，因此还是打了吊瓶。
她去给我找了点粥来吃。说是粥，里面蛋花、木耳、香菇、干贝，米我倒是找不到。吃了一些，胃貌似没那么难受了，但也不想吃了。把化验单拿过来看了看，所有和红细胞、血红蛋白有关的指标都在上限附近，而所有和血小板有关的指标都在中线以下。这直接印证了一贯以来的感觉和事实：我的凝血能力比较差，伤口出血总是需要比别人更长的时间来凝固。但我的血液的载氧能力比较强，因此对依赖耐力的运动能力比依赖爆发力的来得要好。
拔了吊针，突然开始觉得脸上的肌肉很沉，很麻木的感觉。就像喝了好几瓶酒，重得连笑一下都很费劲。坐上 taxi，就知道不对了。好在路程不远，回到家没几分钟就吐了出来，刚才的粥全吐了。不过吐了人也就舒服了，铺了床很快就睡着了。
第二天起来，精神好了不少，感觉至少吐应该是不会了。她叫来了一个钟点工，在家里做清洁，我身兼病人和雇主两重身份，动作蛮不自在。下午，打扫完之后，我又开始睡觉。虽然胃不难受了，但颌关节还是在痛，很不舒服。还是睡觉比醒着来得舒服。
第三天，准备去上班。但由于颌关节还不见好，只有提早起来吃东西。然而一起来就觉得发冷，头也又开始晕，原来还有烧。告诉了公司那边之后，昏昏沉沉又开始睡。后来去买了个温度计，发现这一天一直在 37～37.5 之间，也就是所谓的低烧。不过起码精神又好了不少，有出去觅食的意愿了，晚上去干姐那边吃饭，吃了很久，因为吃得很慢。
第四天还是上班去了。用娜娜的话说，「单位上的破事儿真烦」。颌关节是周五才好起来的。依然不能大张嘴，但总算可以吃东西了。去吃了一次汉堡，证明大致没有问题了。到了周六，打了一周以来第一个真正的哈欠。总算是渐渐脱离了病痛的阴影，代价是 2.6 天的病假。
不过，用一位网友的话来做总结：钱是资本家的，命是自己的。
开张之后，有些话补充一下
这是一条很旧的 Blog，导入自以前的 Drupal5 站点，讲述的事情与现在 Blogger 上的站点无关。
这个 Blog 系统是个国外的系统，而且功能很强很多，因此用起来就会有点难度。给各位的权限都已经设置得让使用难度已经很小了。不过对于从 Blogcn 转过来的朋友，还是有些话要先说一下。
未登录的用户叫做「匿名」用户。无论登录用户还是匿名用户都是可以发表评论的。区别就是，匿名用户的评论，要在通过审核之后，别人才能看到。而注册并登录的用户发表的评论，是可以即时出现在页面上的。
另一个要注意的是，注册用户是可以选择自己的「主题」的。也就是说，如果你是注册用户，你就可以用系统提供的另些套界面来看我的 Blog。有些比这好看，有些比这难看。我自己目前只是大致选出了能用的界面，可能将来会隔一段日子换一个界面玩。你如果自己指定了自己的界面，就别跟我抱怨说别人界面变了你怎么不变了。
OK，先说这么多吧。这个系统我也是刚开始用，还有很多插件（上百个）会等着我慢慢去装着玩的。使用中再摸索吧。
开张大吉，发公告啦！
这是一条很旧的 Blog，导入自以前的 Drupal5 站点，讲述的事情与现在 Blogger 上的站点无关。
经过多日的筹划和少日紧张的准备，我终于准备开放这个完全属于自己的 Blog 站点。——自己的服务器，自己装的操作系统，自己编译、调试的运行环境，自己选型和架设的站点，当然，还有今后自己写的文章。
开放这个站点，当然首先是为了把我的博客继续下去。Blogcn.com 大则大亦，可惜速度和稳定性都无法令人满意。单单是每次更新之后总是要花 10 分钟才能看到自己的内容，就令我很不满。再算上朋友们总是抱怨说页面总是打不开，唉……
由于是自己的服务器，可以做很多事情。也由于是自己的服务器，所以网络是使用自己的宽带，所以速度和可访问性可能会令人不是很放心。当然，我想了一些办法来改善这个情况。只要大家记得，每次都访问 www.superliufa.com 这个域名，就不会担心无法找到这里。当然，我这里停电除外。
数据搬迁尚未全部完成，请各位耐心。另外，在这里发言若想留下名字，请最好注册一个属于自己的帐号。帐号的初始密码会通过 Email 发送到各位留下的邮箱中。注意：请勿使用新浪的邮箱，如 xxx@sina.com，否则不予受理！我和新浪有些过节。
可以使用的邮箱有：163.com，移动 / 联通 / 电信提供的免费或收费邮箱，hotmail 也是可以的。这些都是实际测试过可行的，其它的也可以试试。如果一小时后没有收到邮件，你没有别的邮箱，而又确实想注册，请通过别的方式告诉我。总之，不要用新浪的邮箱就行，切记切记！
对了，还没有说。开这个站点的目的，就在于让我的朋友、同学（现在也都该称「朋友」了）、家人能够了解我的近况，大致知道我都在干些什么。至于混出名，暴暴隐私，炒作，我都没兴趣。所以，路过而没兴趣的各位，还请谅解。
好，剪彩，开张！
2006-06-03
「胡子门」事件一点感想
四月份开始闹的这个事情，现在好像已经差不多快平息了。时间的威力的确是很强大。现在还有人不知道，也有人还在激动，但这与事件本身没有什么关系了，多属于遗留效应。就事件本身来说，能爆的料都已经爆完了，剩下的就是一堆新知道这个事件的人在叫骂，和一堆以前关注过的人偶尔回过头去看看而已。
我，就属于后者。就事件本身来说，确实，在现在这社会早已见怪不怪了。记得新浪上有篇帖子，说某男「诱奸」了十多名三、四十岁的网友「少妇」（我不知道还算不算），最后还是因为和其中一个因为某些「关于未来」的事情起了争执而杀了人，才见诸媒体。标题是写的「诱奸」，我看根本就是你情我愿的通奸。我估计，如果不是「铜须」长得实在是有些抱歉，而「幽月儿」的照片还算美女，估计没有这么多人关注这事情。当然，那份 QQ 聊天记录中关于什么「包皮」、「口暴」的火爆言词，以及那个所谓的工会高层录音，也是火上浇油的因素。
之所以突然想到这件事情，是因为从 QQ 新闻上看到了昨天，也就是 2006 年 06 月 02 日，终于有一个电视节目对这件事情做出了反应。反应的内容，令我有些惊讶，但仔细一想，也在情理之中。整个节目下来，「铜须」活脱脱一个受害者的形象。一字不提他的那个令每个人都彻底打消了心中疑虑的「辨白视频」，也一字不提整个事件中被网友们慢慢组合起来的完整的证据链，包括那个被生生挖出来的数年前的旧求助贴——为了诋毁一个这样的人，需要苦心经营从数年前就处心积虑地开始筹划吗？
所以，这个节目的意义，就在于——它要让尚未了解这个事件的多数人（应该算是多数吧），心中有一个与事实不同的印象。大多数人不会有机会和能力去求证这个事情，甚至根本没有这个闲暇和心情。因此，媒体的声音，在某种程度上，就代替了民众的思考。
从某种意义上来，这个节目，及其背后的那些「领导」所设想的，是正确的。我们社会最需要的是稳定。毕竟，从某种程度上，我也可以算作是这个社会的既得利益者之一。当然，「领导」们更是。而且，他们也许和「铜须」一样，也勾引过的别人的老婆（很大的可能，除非性无能），因此他们的既得利益更多也更显著。所以，稳定是我和他们所需要的，是「压倒一切」的。
而且，很明显，所有的证据都证明了同一件事情。因此「铜须」的处境是很不利的。假使我以小人之心度君子之腹了，「领导」们都是清白的，无辜的，都是柳下惠（或都是性无能），和别人老婆单独在一起的时候都是在指导工作。那他们也应该拉「铜须」一把。须知稳定的前提就是要平衡，或者制衡。从来都只有动态的平衡，而没有静态的稳定。两股或多股力量互相博弈，却谁都压不过谁，这就是稳定。既然在网络上，胡子大有被打倒之后再踏上一脚的可能，那么在普通传媒上，就要替他「出出头」，这样才不至于一边倒，以至于暴发影响「安定团结」的危机。
我觉得悲哀之处在于：大多数民众即使有了思考的能力和意愿，也得不到公平的机会。话语权永远是强者的权力，因此舆论总是彰显强者的意志。在我们这个还尚未进化完全的社会里，弱者是得不到保护的。大多数强者还未明白，他们不可能永远是强者，也不可能所有方面都是强者。同时，他们也无法意识到，保护弱者，就是保护自己。因此，我才会先看到「铜须」被网络上道德舆论谴责的强权无情地打压，然后又看到政府以掌握绝对话语权的制高点为出发地，对事实真相的掩盖和对民众知情权的无耻嘲弄。站在事件本身，我无限鄙视男女主角。然而，站在第三者的角度，看着这整件事情，完全是一种对白垩纪社会的无限悲哀。
其次，对「既得利益」者的评价，现在在我这里，已经完全是负面的了。本来，所谓既得利益者，应该是一个社会的中坚力量。得了利益，就要守住利益，因此他们会竭力维护这个社会的公平、秩序、稳定以及一切。然而，现在我看到的这些「既得利益」者，短视、狭隘、无知，完全是那大脑小得可怜的恐龙的造型。他们只想守住自己的利益，至于别人的、群体的、社会的，一切皆不在考虑范围。为了自己的一点小利益，也敢欺骗公众，同封建社会有无二致？也许，还是因为我们这个社会尚未进化完全吧？
衷心地希望陨星早点到来。如果仍旧是那强健但愚蠢的霸王龙当道的话。虽然身为弱小的人类，但是，至少我们还有希望！
NBA Live 2000 战报 060602
以前曾经写过战报，不过也许写在 Blog 上比较合适，否则根本坚持不下去。
我游戏中的时间已经进行到 06 / 07 赛季了。这个赛季湖人的阵容可谓豪华了，赛季刚开始时，首发是奥胖、布兰德、特科格鲁、KB8 和拜伦·戴维斯。替补席上是一帮我自己挑选培养起来的不知名的球员，经过数个赛季的成长，已经和普通球队的主力的实力不相上下了。
不过我觉得每个赛季球队的阵容都应该有点变化，因此拿奥胖去交换了 T-MAC，另外还有一些数值高但技术特点我不喜欢的替补球员也被我拿去交易了一些希望之星。这下首发阵容从内外线组合的阵地攻坚型一下子变成了太阳似的跑轰型。布兰德本身就是一个快速大前锋，顶上来的新中锋速度也不弱，关键是小前锋的位置上，速度大大加强了。以前的主力特科格鲁，目前的实力数值和 T-MAC 其实是相同的，但是他速度不行，敏捷也不行，属于射手型打法，因此现在我让他当第六人了。T-MAC 一来，立刻靠快攻拿下不少分数，经常当 Man of the Match。而且他的抓板意识好，速度快，往往出手不中之后就是他出现在篮下把板抓到手。
今天的比赛，是对犹他爵士。爵士前几个赛季可风光了，好像是以最低价签到了休斯敦（真不知道它为什么这么好运？），然后得到了 KG，加之本身有几个不错的角色球员，一下子跃居实力榜第二的位置，常年的西部决赛球队，俨然一副一人之下万人之下的架式。我早就恨得牙痒痒。这个赛季，他们终于被拆分了。恐怖的 KG 终于走了，休斯敦老得能力下降了不少。KG 好像是和希尔做了交换，添头是莫宁。莫宁是真的老了。虽然希尔也还属于一流球员（在游戏中可没伤），但 T-MAC 和突厥人要防他还是有把握的。上次刚刚是客场和爵士的比赛，被我赢下四十分。KB8 砍下 58 分，可见实力确实已经下降了很多了。
一开场，我就知道会大胜了。进攻连连得手，KB8 和 T-MAC 都是顺利地拿下 10+，没有犯规，命中率还 100%。对方的命中率极低，而我的后场篮板今天也奇迹般地控制得很好。后半段，布兰德开始发威，也砍下 10+。可惜快结束时他有个上篮不中，不然这节我方就是 21 / 21 了。第一节就 52 : 17 大胜了 35 分，比赛结果已无悬念了。
不过，对手第二节还是展开了一定的反击。进攻命中率上升到了五成以上，而我方的替补球员为主的阵容，仅仅 14 中 8，很勉强地以 30 : 23 度过了本节比赛。对方的一个替补中锋 Weis 在进攻端屡屡得分，表现出色。看来我小看了他。
第三节，双方又是主力出战。KB8 状态不佳，只拿下两分。不过这一节是轮到胖子戴维斯发威了，命中两记三分，把自己的得分涨到了接近 20。本节对手得了 25 分，而我是早早就过百了。
第四节，KB8 总算又开始发威了，拿下了 17 分，率队在本节前段和中段把比分越拉越大。对方只能靠外线硬投三分来苦苦维持。贝斯特的三分命中率还不错，但其他人就惨了点，特别是老休斯敦，根本跳不动了，被那现在弹跳 99 的 KB8 帽了个昏天黑地。希尔不喜欢三分，这个弱点要了他的命，本场比赛他就 14 中 4 的命中率，真惨。
最后以 70+ 的分差赢下了比赛，真是毫无悬念。不过，对方的替补中锋真的表现很好。让我不禁想念起了奥胖。目前的三个中锋，一个是 6'10 普通身材擅长中远投有三分的家伙，一个是 7'2 瘦长身材篮板和盖帽出色的防守型中锋（可能类似穆大叔，但体形没他壮，虽然 Strength 很高），还有一个是奥胖交换 T-MAC 时带的添头，体形不错，壮壮的和奥胖类似的家伙，不过能力才 74，还没完全成长起来。我的打算是，等下个赛季，拿一个中锋去赎回奥胖，再拿一个替补 PG 去换目前能力略有下降的 Jason Kidd，组建一个起码在人员名单上是超豪华阵容的球队。
订阅：
博文 (Atom)