关于 fstream.open() 中使用 in|out|app 模式打开文件总是失败的问题

其实是以前找到的一个问题了，不过今天提到了编译器的版本，突然想起了它。在国内的网站上似乎很难搜索到关于这个问题的报告，因此写出来供分享。

事情的起因是服务器版本的升级。以前我们的程序都是在一台 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 模式来写日志了。

不同版本 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。

记录下这个情况，以供参考。

《C Traps & Pit Falls》读后偶感

内容有点旧，不过看过之后还是有一些收获。

其中有一段很有趣的回忆：

……我还记得自己在开发某个系统时，曾经与一个用户有过这样一场对话： 「这部分记录中可能出现的代码有哪些？」 「可能的代码是 X、Y 和 Z。」 「如果与 X、Y 和 Z 不同的代码在这里出现，该怎么办呢？」 「这不可能发生。」 「嗯，但如果这种情况确实发生时，程序需要做些适当的处理。你认为程序应该做些什么呢？」 「这个我可不关心。」 「你真的不关心？」 「对。」 「那么，如果程序在检测到不同于 X、Y 和 Z 的代码出现时删除整个数据库，你也不会介意吗？」 「太荒唐了。你绝对不能删除整个数据库！」 「那就是说，你还是介意程序在这种情况下的行为。那么，你希望程序做些什么呢？」 ……

看到这里，忍不住直想发笑。昨天我还遇到类似的对话来着。美国人就是会搞笑，我当时怎么没有想到这样幽他们一默呢？

美女点名做题目，有点兴趣

被美女点名回答这些问题，我也真的相当认真，呵呵。

1. 近期要实现的目标是什么？（换工作，争取去外企。）
2. 要是你的旧情人因你发疯，你咋办？（陪她发疯。）
3. 会不会同时爱上两个甚至更多的人呢？（会，但有结果的必定只有一个。）
4. 假如生命只有一天最想干什么？（打开 Word 写墓志铭和遗嘱。）
5. 一个人对你温柔体贴关爱倍加，另外一个人让你爱的近乎发狂，却对你不冷不热甚至有点不解风情，你会选择谁？（两个都不选，我想我现在还有这个资本可以追求一下完美。）
6. 你相信有外星人吗？（不相信，我只相信有外星「生物」。）
7. 你认为人最重要的品行是什么？（四川话念：做人要厚道。）
8. 你心目中认为最好的城市在哪里？有什么优点？（目前是福州，因为感到亲切，到了那里就有一种如鱼得水，很自在的感觉，不知道是什么缘故。）
9. 到目前为止，自己拥有最宝贵的东西是什么？（头颅，和里面的那包草。）
10. 当你工作遇到不想做的时候怎么办？（「更衣」去。）
11. 看过日本侵华相关的文字图片和记录片吗？你对日本犯下的罪行怎么看？（那个民族本来就有问题。）
12. 朋友点名让你做游戏，你做不做？（那要看这「朋友」是谁，面子不够不做。）
13. 近期关注的话题有哪些。（睡觉。）
14. 最希望所爱的男人 / 女人对你做的一件事情是什么。（好好活着。）
15. 如果你突然有了 100 万，你想怎么花。（先买一台笔记本电脑，配上 2G 内存。）
16. 如果你发现老公/老婆有了外遇你会怎么办。你的第一反映会如何。（震惊。）
17. 你的理想是什么。（退休。）
18. 你的梦想是什么。（现在就退休。）
19. 最近最满意的一件事情是什么。（身体现在还不错。）
20. 最近最失败的一件事情是什么。（上上周生了病。） 

日记 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

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，也知道了解说员的境界层次是可以有无数多级。疯狂的黄建翔我不喜欢，拜托找个更好的来。

我无意评价他这样做的对错，但显然，做大赛的评论他不是很合适。让观众听了想捂耳朵，想关电视，无论如何也不能说这次解说是优秀的。

连带地，我想我以后一段时间内会对意大利队产生一定的厌恶情绪。不过我觉得很奇怪，黄建翔不是巴西球迷吗？什么时候换口味了？

06.06.22 世界杯观后感

工作时间，等编译的同时抽空简单写一下。

捷克很可惜地输了。比赛完全进入了意大利的节奏。又高兴死 dzxr 了，不过我还是比较喜欢捷克，特别是那坚毅的 Nedved。
第一次见他，是在 96 欧洲杯上。当时他头发还短短的，愣头青的样子。当时并不喜欢捷克，因为媒体对它捧得很厉害。但对 Nedved 的印象挺深。印象中在右路活动比较多，还以为是右边后卫，心想这家伙助攻得也太多了点。
后来他去了尤文，此后熟悉了，每次玩 WE 系列，都是我第一个签入的大牌球员。确实也很好用，可边可中，可前可后，跑不死，脚头又硬又准，技术不错且均衡，抢断也超级厉害。

昨天的比赛也是如此。在中场他抢断了无数次，只要哪个家伙脚下的球被他瞄上，若不及时传出去，那基本上就被断掉了。如此多的抢断，却连犯规都很少，身体、气势、意识和技术，仍有当年之勇，仿佛不见老。
全队有威胁的进攻，都与他有关。三脚最具威胁的远射，也都是他的作品。可惜，这样的人才还是没法带队进入淘汰赛。斯基是真的老了，也许是速度型球员的宿命吧。Rosicky 的状态也不好，而且我认为这是因为他的身体在意大利防守球员面前丝毫也占不到便宜的结果。大个子无法上场，卡纳瓦罗那略微的身材劣势也就完全不复存在。于是就只有铁人在中场不知疲倦地回抢，在禁区前沿一次又一次地怒射……

06.06.21 世界杯观后感

晕乎乎地看完了葡萄牙和墨西哥的比赛。本来还是比较喜欢葡萄牙，但是这场比赛大部分主力都没有上，最后马尼切这样的队员居然成了场上主角。不过配合还是一如既往的细腻，也一如既往地「小」。
下半场特别想睡觉，葡萄牙 11 打 10，还被人压着打。中场失控的同时，后 / 中 / 前场三线一起脱节。边路也打不开，西芒累了，感觉体力一般，而菲戈确实是老了，回想六年前欧洲杯上多风光啊！
拼得要死，牌也多得可怕。快终场时大家的体力都不行，裁判大概也累了，出牌也是有气无力的。

只留下了这些印象。很想看第二场比赛，可实在撑不住了……

福建电信短信业务升级测试中遇到的一些问题

昨天测试「通过」了，今天把过程中遇到的一些问题写下来，免得以后忘掉，而且也许会有用处。

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 度，晚上走人时忘了关。第二天来的时候，玻璃上一层雾气。让人恍惚间有种冬夏颠倒的错觉。

真想把那些二十几度就开空调的人，拖去重庆绑在外面「受刑」。