我真傻，我以前没有发现这么个好用的东西，无奈的时候就自己上python逐个字符的转。

uni2ascii 可以实现汉字以及是其他unicode字符、html转义字符在以下的编码格式之间的转换：

HTML hexadecimal numeric character references, 例如é
HTML decimal numeric character references, 例如é
HTML character entities,例如<
SGML hexadecimal numeric character references, 例如\#x00E9;
SGML decimal numeric character references, 例如\#0233;
\u-escaped hexadecimal, 例如\u00E9
RFC 2396 URI format, 浏览器URL编码使用的，例如%C3%A9;
RFC 2045 Quoted Printable, 例如=C3=A9

等等..总之常用的unicode转义形式，uni2ascii 都是支持的。
 

好久没见的沙尘天气了，晚上睡觉时嘴里涩涩的，磨牙的时候都可以听见沙尘被碾碎的声音。今天早上起来上班冻死了。

广电总局，工信部，文化部发力，全国多地IDC断网自查，白名单制度将陆续普及!网络视听、电影等类型网站需要有《信息网络传播视听节目许可证》,小说、游戏等类型网站需要《网络文化经营许可证》，论坛、聊天室、留言板等类型网站需要《互联网电子公告服务许可证》。

这又是一篇技术文，同时也是一篇牢骚文，正常人类可以跳过了。

GAE最近发布了1.30版本，提供了Blobstore功能。GAE是不允许写文件的，Datastore中提供的存储服务每条记录最多只能存储1M的记录，而Blobstore可以提供最大50M的文件存储。同时GAE也提供了用于处理文件上传/下载的handler，只要在上传文件的form表单中指定upload的url就行了，BlobstoreService会自动处理上传请求，存储文件及文件的类型和信息，并返回文件记录的key。

这个功能对于GAE残次的文件功能算是聊胜于无吧，看到更新后兴奋了一下，决定动手把原来的的文件上传迁过去了；然后，很悲剧的发现，现在这个功能只向付费用户开放！

Blobstore用不了就折腾点别的。原想做个发文自动推送到qq空间的功能，因为qqzone现在是支持email发文的，所以想通过邮件这条路来做。要动手才发现google和腾讯真是一对残次品，GAE发邮件只支持使用自己的smtp服务器，qq空间只接受qq邮箱smtp server发送的文章。直接走肯定是通不了了，难道要gae先发送到QQ邮箱，QQ邮箱再自动转发到qqzone里吗……

然后又看了下豆瓣的开发API，决定折腾这个。豆瓣是个技术狂热型的公司，这从他们使用python语言，以及提供开放API，以及API走gdata协议都可以看出来。但是他们的java API client再次让我郁闷了。这么个小的API client，竟然依赖那么多jar包，jar爆炸就是你们这种人造成的！好吧，依赖gdata这些还情有可原，依赖httpclient你是唱的哪处戏啊！httpclient这种，3.x到4.x一升级API全变……并且使用还很广泛，别的项目如果已经用了4.x的jar包，你豆瓣的API client何以自处，根本就放不进去了嘛。你看看你家老师Google的java API client，什么时候使用过httpclient。

回到老话题上，最悲剧的是GAE根本就不支持httpclient……又是一对残次品。悲剧的后果是没法用豆瓣的API client，直接上体力活去解析人家很高级的gdata数据。

结论：GAE现在根本不是云，也就算是一片小水雾。

新加坡《联合早报》近日在霍比奥港专访索马里海盗头目穆罕默德．库鲁姆，以下为报道节选：


《联合早报》：这一次中国的舰队有什么行动吗？表面看起来没什么不同……

库鲁姆：这一次，我们面对的是一只神出鬼没的军队，他们夜晚能够乘直升机悄悄飞临我们的头上，并且蛙人在我们的房屋外涂抹标语，用英文警告我们交出人质，而且，他们警告我们将受到弹道导弹的打击。

《联合早报》：这一切未见报道……

库鲁姆：哦，那是可怕的经历，我们将遭受灭顶之灾，于是我对小伙子们说：“够了，拿走350万美金，把中国人还给他们。”

《联合早报》：你担心海盗受到毁灭性打击？

库鲁姆：哦，是的……空前的危险。他们来到我们中间，神出鬼没，可以杀死我们，却用仁义的方式警告我们，……中国不可战胜。

《联合早报》：那到底他们在墙上写了什么标语？

库鲁姆：哦 太可怕了！ --------拆

我是个土人，平时喝罐装饮料也不多。某个月当有一天喝可乐的时候，发现拉环拉起来后没有和易拉罐分离，另外一部分嵌入到易拉罐里面了。我很慌张啊，心想自己咋这么丢人呢，连易拉罐也不会开。从此以后，每次喝可乐我就很小心，很细致的去拉拉环，但始终没能成功把它拉出来。

终于有一天真相让我泪流满面。那拉环是真的不能拉出来的，为了环保的考虑，拉环都做成内嵌式的了。是的，现在不会有人整天发“拉环一直喜欢易拉罐，可是易拉罐的心里却住着可乐。所以每当喝完罐状可乐，请把拉环放入易拉罐，成全拉环的爱情！”这种白痴信息了，拉环和易拉罐已经再也不会分离了。

原作者：kxn@bbs.Tsinghua.edu.cn / smth.org / bbs.newsmth.net
康神kxn的blog：kangkang.org 内含：康神之心得、发布Fterm最新版本、提交Fterm的bug
注：这是康神的一篇旧作，转载时请勿删除以上信息，以示对原作者kxn之尊重！谢谢！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   我们现在提到的 BBS ，通常指的都是 Telnet BBS ，用一个 term 软件连接上，就可以看到文本的界面，比起如今花哨到无以复加的 WWW BBS 们来可谓是简陋到了极点，然而就是这样的 BBS，无数人每天面对它长达两位数小时还乐在其中，恐怕 UI 设计专家们知道也要气到吐血。也不时有人发表预言，预言 Telnet BBS 将很快消亡而被更加富有表现力的WWW BBS全面取代，只是年复一年，当年的预言者已经消失不见，BBS 上的用户数目却翻了一番又一番。。。这就是 Telnet BBS 的魅力。
Telnet BBS 系统数目众多，但是从根源找起，大致可以分成两大家族，Firebird BBS 和 Maple BBS，在大陆 Firebird BBS 的变种占据了绝对优势，在台湾地区则是 Maple BBS 的天下，由于台湾地区计算机发展历史比较长，因此 BBS 的人气也比大陆高，同时上站人数过万的站点有好几个，不过大陆毕竟有着人口优势，近年来教育网几大 BBS 的人数也迅速增长。下面我们就分别介绍这两大 BBS 家族。首先是在大陆最为流行的Firebird BBS ，最有名的 SMTH BBS, YTHT BBS,  Firebird 2000 三大流派都是由此而来。
很久很久以前，有那么一群大学生，也可能是科研机构的研究员什么的，他们整天在Unix主机上面打滚，觉得要是能在主机上面做一个论坛样的东西多好，于是他们就写了一个命令行程序，运行这个程序，操作者可以在界面下面留言，为了让多个人同时可以操作这个系统，他们把这个程序设置为系统某个用户的 shell ，每个 telnet 上该主机的用户，只要使用这个用户的用户名和密码登陆，就可以进行交流。这就是Internet BBS 的雏形。经过一段时间的发展，这个系统具有了相当多的交互功能，用户不仅可以留言，还可以互相发送信件，发送信息，看到同时在线的用户等等。

BBS 系统的开发者们为了让更多的人能使用这个系统并完善之，将BBS系统以开源协议发布于网络上面。只要拥有Unix主机，就可以取得源代码并安装BBS系统。因此BBS系统以很快的速度发展起来。在众多BBS系统中，某个叫做 Pirate BBS ，经过某些人修改后叫做  Eagle BBS 的分枝，流传入了台湾地区，交大资讯工程系从他发展出了Phoenix BBS，Phoenix BBS 是如今大部分中文 Telnet BBS 系统的祖先，然而它的名字却远不如其后辈响亮，在它的基础上由中正资工进一步修改的 BBS 系统，被赋予了那个大陆 BBS 开发者耳熟能详的名字 -- Firebird BBS。
   应该说， BBS 系统在传入台湾地区时候虽然功能还比较简陋，但是 BBS 系系统的基本架构已经定型，比如多进程模型，共享内存信息交换，利用系统信号来传递呼叫消息，用文件存储文章和索引等，这些设计在现在的 BBS 系统中大部分还在沿用，其中不少设计即使现在来看，也是相当标准有效的多进程 Unix 服务器设计。
   下面我们进入正文。
   Telnet BBS是一种流行于大学和研究机构中的电子公告牌系统，和时下流行的Web BBS系统不同，bbs的界面采用纯文本方式表现，用户使用终端软件连接bbs系统，文本界面在服务器端生成并发送出来，客户端软件仅原样显示文本内容，属于一种瘦客户机的应用。Telnet bbs (后面除非特殊提到，否则简称bbs)在台湾地区和大陆的教育网地区比较流行，比较大规模的站点在线人数一般都在万人以上。
   由于历史原因，bbs系统采用的是Unix下相当传统的1:1多进程模型，每进程处理一个连接的模型，此种模型的好处是服务相对比较稳定，不会因为一个用户出错导致整个系统的不可用，但是也带来耗费资源较多和进程之间通信比较困难的问题。Bbs服务器端的复杂逻辑也使得分布式设计很难实施。因此 bbs通常是单机承担几乎所有负载，大陆地区较大规模的bbs服务器上经常同时保持超过7000进程，台湾地区的bbs站甚至有并发20000进程以上的纪录。
   我们在维护大型bbs站点的过程中，积累了一些优化和维护如bbs这样高并发进程服务器的经验，考虑到1:1进程模型服务仍然有很广泛的应用，在这里写出和读者共享。

   优化服务器是综合性的工作，不仅需要修改代码，还需要调整系统参数，包含有很多琐碎的内容，根据目的来讲，大致可以根据节约资源的类型分为磁盘IO优化，内存优化，和CPU优化等几方面。下面介绍的优化思路虽然应用于bbs，但是也适用于其他应用系统。
1: 磁盘IO优化
磁盘IO优化可以说是服务器优化中最重要的一环，除了极少数的纯计算性应用，几乎所有的重载服务器最后都是卡在磁盘IO瓶颈上面。
a) 尽量使用shm等IPC手段而不是文件
多进程和多线程相比，最大的麻烦是不同执行环境交换信息不方便，因此很多程序员选择了使用文件交换信息，例如最早的bbs设计中，用户的帐户信息是存在于文件中的，进程从文件中读出内容，有修改后就写入文件。改进后的设计是将账号信息文件完整读入共享内存，所有修改都写入共享内存，然后由外部进程定时往磁盘上面同步。
甚至flock这样看起来不会造成太多IO的同步操作都应该尽量避免，原因是flock需要先open文件，而open 文件需要找到i节点，因此会占用文件系统的inode缓存空间，可能造成其他IO操作的性能降低。在很多情况下面需要的只是一个跨进程的mutex，可以使用0/1信号灯来实现。
b) 使用应用层缓存。
很显然，操作系统的缓存会受到很多因素的干扰，对于一些确定会经常访问的内容，例如版面的最新几片文章和最新列表，如果放入shm中缓冲，性能会有大幅度提升。
c) 尽量减少关键IO数据结构的大小
Bbs 文章列表的索引文件是由定长数据结构构成的，在这个数据结构中为了将来扩展方便，留下了很多保留域，造成了很多不必要的IO，删除不必要的域之后，数据结构变小了一半，减少了很多IO。很多时候，扩展性和性能其实是对立的，如果很需要性能，那么损失一定的扩展性也是不错的选择。
d) 避免在同一目录下放过多文件或者使用合适的文件系统
大部分文件系统对在同一目录中的文件列表采用线性存储，因此在一个目录下面存在很多文件的时候，打开文件变得非常的慢，因此通常要将文件根据某种规则散列到不同的子目录中，例如，文件 Atest 会被存放在 A/Atest ，如果文件太多，可能会需要对子目录下面的文件再次进行散列。
另一种解决文件过多影响效率的方法是使用有特殊优化的文件系统，例如Linux下的reiserfs。在这些文件系统中，目录中的文件列表是用平衡树来组织的，因此同一目录下面可以同时有数十万个文件而不会降低太多性能。
e) 根据系统的访问模式选择适合的硬件配置和系统参数
Bbs 系统使用零散的文件存放文章，它的访问模式基本是小文件随机读写，而文章数据相对比较重要，因此bbs使用strip大小比较小的raid5比较合适。文件系统选择专门为小文件优化的reiserfs，系统的预读长度也可以调小一些，Linux 默认的长度是 256K, 有些偏大。如果是大文件连续读写的话，那么raid的strip 大小和系统的预读长度应该放大，文件系统则尽量选择结构简单的文件系统例如ext2/3 等，如果数据并不是非常重要，那么甚至可以取消raid5，代之以raid0或者直接使用单独的硬盘。
2: 内存使用优化
BBS系统使用的多进程模式相当耗费内存，在bbs发展过程中，最早遭遇的瓶颈就是内存。减少内存的不必要浪费，可以节约出来作为系统缓存，从而间接提高更重要的IO性能
a) 尽量避免动态初始化常量，使用const说明将变量和常量区分开来。
Unix 系统在fork出新进程的时候，子进程和父进程共享相同的空间，之后按照COW机制，对修改的页面才进行复制操作，常量如果可以预先计算出来（例如一些转换表之类），就应该尽量避免在运行时动态初始化。另外因为只要修改一个字节，整个页面就都会被复制，因此应该避免常量和会被修改的变量混在一起，编译器本身会自动将不会被修改的内容放在一起，程序员需要做的事情，就是用const通知编译器哪些内容是不会被修改的。
b) 减小内存的峰值使用，特别是堆栈中内存
很多人习惯写程序时候在堆栈上声明一个比较大的临时数组，认为退出函数之后这部分内存会自动被释放。殊不知这样分配的内存并不会被动态被系统回收，因为系统并没有一个明显的标记可以得知堆栈内存是否还在使用中，特别是在多线程的环境下面，操作系统通常采用的措施是需要的时候分配页面，但是在进程退出之前并不回收。即使是通过malloc分配的堆内存，其页面是否回收也视库函数的实现而不确定。因此在无论什么情况下，贸然分配过大的内存，都会对性能造成一定的影响。
c) 如有可能，尽量使用shm来保证页面一定会被多个进程共享。
3: CPU优化
这里说的CPU使用优化，不包括像使用hash来代替线性查找这类最基本的算法优化，而是涉及一些和系统关系比较密切的操作。
a) 使用针对硬件优化的编译器
这应该是所有CPU相关优化中最容易做到也是最容易看到效果的，Intel CPU的Linux系统上面使用 Intel C/C++ 编译器，可以获得很好的效果，甚至AMD的Athlon系列CPU也能获得一定程度的加速。。Bbs进站时候需要初始化很多内容，计算量比较大，使用gcc 时候负载在4左右，使用icc编译以后负载马上下降到1以下。推荐编译时候针对特定CPU指令集优化并且打开跨文件优化选项(-ipo)
b) 使用单独进程来初始化和维护共享内容，避免出现竞争导致逻辑错误
严格讲这并不能提升很多性能，只是为了减少多进程服务器上面经常出现的逻辑错误。在原始的bbs设计中，共享资源的创建是由第一个访问的进程在打开失败时候创建的，但是重负载服务器上面有时候打开也会失败，从而导致多次创建共享资源。
c) 序列化容易导致负载上升的行为
BBS进程在进站时候需要进行很多的初始化工作，同样进程退出的时候也要做很多的收尾工作，此时对CPU或者IO的占用比较大，通过一个互斥锁可以使多个进程不要同时进行这些操作，否则系统负载有可能上升到一定程度引起正反馈，导致系统彻底崩溃。
d) 尽量减少信号的使用
Unix系统下面对于信号的实现的代价是比较大的，同时信号本身也很容易导致处理逻辑的混乱。高负载服服务器应该尽量减少信号的使用。
e) 对于大范围IO读取操作，使用mmap调用
使用mmap操作比传统的read操作好处是减少了一次内核态到用户态的拷贝。在大范围IO操作的时候具有优势，bbs中使用mmap操作来在文件中搜索内容，速度最高时候提高了5倍左右。但是需要注意的是，mmap并不适用于有写入的情况，因为mmap写盘的时候是以页为单位进行操作，页中只要有一个字节被改写，就要往磁盘上面写整个页面的数据，无端增加了IO量。
以上是我们在维护大型bbs站点时积累的一些经验，供各位读者参考。