博文视点的张春雨编辑告诉我，八次印刷的《精通正则表达式》已经全部售罄了， O’Reilly 与电子工业出版社续签了版权合同，准备重新上市，让我写一点东西。

该写什么好呢？

2007 年 《精通》上市时，我还在中关村，天气好的时候可以望见颐和园的佛香阁；而现在，窗外景色已经换成了珠江边的小蛮腰；对正则表达式的使用，也从随手拈来变得生疏——许多问题需要翻查《精通》，翻查自己写的《正则指引》。究其原因，与正则表达式直接相关的开发做得少了，古话说“勤则立，嬉则荒”，就是这个道理。

荒是荒了，毕竟还没荒废，虽然有很多细节需要查阅，但是我很清楚，某个问题能不能用正则表达式解决，该怎样解决。或者说，虽然手上生疏了，心里其实没有忘记，而这一切，归源都是之前死啃过《精通》的缘故。

在阅读《精通》之前，我已经查阅了网上的不少资料，对正则表达式有了基本了解，能像模像样地解决一些实际问题，可算“够用”了。这时候遇见《精通》这样“现实价值不那么大”的书，能静下心去阅读，其实带着点毕业不久的傻气，只是单纯想把它弄懂搞透。所以，遇到匹配原理这类看来没多少实用价值的知识，还会愿意花时间去揣摩、研习。回头想想，也正是因为当时有这种傻气，可算是意外的收获：工作中经常需要学习一些工具和原理，虽然当时也“学会”了，但不久就忘个精光；相比之下，正则表达式却是学到了“不会忘”的程度。更典型的例子是游泳，几乎人人都可以做到“一朝学会，终身不忘”。同样是“学会”，为什么差距这么大呢？

这个问题我想了很久，最后的答案是，“学会”的定义是不同的。

通常我们说“学会”了某项技术、某门语言，意思是“凑合能用”，或者说“可以对照文档（ Google ）解决问题”的程度——你用 Python 解决了一个问题，就说明你“学会”了Python ，哪管是步步 Google ，还是照抄现成的代码。而我们说“学会”了游泳，意思是可以在水里行动而不沉下去，更重要的是在游泳时不需要时刻背诵各种口诀：吸气—伸手—划水—蹬腿—抬头—呼气……，如果你在泳池里还要时时谨记这些口诀，是绝对谈不上“学会”的。

两者虽然都叫“学会”，其实相差迥异：第一种“学会”是“照猫画虎”，第二种“学会”是“融会贯通”，虽然都可以解决问题，但从第一种“学会”到达第二种“学会”，其实需要经历漫长的过程。而且，两种“学会”都能解决问题，所以在达到第二种“学会”的漫长过程中，你很可能感觉不到自己的进步，反而会困惑继续学习的意义乃至放弃——既然能对着文档操作，既然有现成的资料，为什么要去理解背后的原理呢。

对我来说，第二种“学会”的好处是显而易见的，最重要的一点就是不会忘记——学习的时间增长一倍，遗忘的难度将会增加十倍、二十倍甚至一百倍。这些年来，我见到了太多这样的例子：有人每次用到正则表达式都会抓狂，都要四处极力搜索、反复盲目尝试，花很长时间才能凑出、蒙对解决方案；另一方面，他们又不愿意花时间潜心学习《精通》这样的经典。因为反复遗忘，需要反复学习，最终浪费了大量的时间。

许多人不愿意专门花时间来学习正则表达式，是认为它属于奇技淫巧，并非工作必须。但这理由是不成立的：我们大部分人不是作家，但为了在需要的时候写得出文章，还是必须专门花时间来练习写作。而且，专门花时间来学习“非必要”的技能，以后往往能有意想不到的收获。我真切体会到并且懂得这个道理，恰好也是与《精通》的翻译有缘。

在翻译《精通》时，为了省却重新编排索引的麻烦，需要做到中英文版页页对应，于是我专门学习了侯捷老师写的《Word排版艺术》，并且亲手尝试了每个例子，记熟了有关的概念和术语，从此学会了格式和样式的角度定义文档，再不用为格式之类的问题烦恼。这些年来虽然用得并不 多，却没有忘记。去年写作《正则指引》时，我事先完整定义了各种格式、样式、引用等等，交稿时节省了自己和出版社大量的时间。

另一个例子仍然与正则表达式有关。去年，为了写作《正则指引》中Unicode的章节，我专门花了时间研读Unicode规范，虽然最终《指引》中没有列出学到的全部知识，但我对Unicode的理解已经不再限于“在程序中设定Unicode编码即可”。前几天，有位同事遇到Unicode字符Ä （U+00C4）无法打印的问题，于是我建议他使用A和¨ （U+0041和U+0308）的两个Unicode字符来表示（按照Unicode规范，两个字符可以“组合”成一个字符），果然解决了问题。这段经历再次证明，真的学会了，就真的不会忘。

亚里士多德曾说：所谓幸 福，就是尽情地施展我们掌握的技能，等待期望的结果。然而很多时候，我们以为自己可以解决，但是之前学过的技能已经遗忘，于是施展起来步履沉重、举步维艰，最后只能精疲力竭地等待结果，自然与幸福绝缘。相反，如果我们能把重要的技能都真正学会，学到不会忘的程度，自然可以接近幸福。如果你想收获自如驾驭 正则表达式的幸福，不妨从这本书开始吧。

经过各位读者和出版社的辛苦努力，《正则指引》终于上市了，以下是主要的购买链接：

亚马逊：http://www.amazon.cn/%E6%AD%A3%E5%88%99%E6%8C%87%E5%BC%95-%E4%BD%99%E6%99%9F/dp/B007X6O6J0/

当当：http://product.dangdang.com/product.aspx?product_id=22702127

京东：http://book.360buy.com/10972570.html

China-Pub：http://product.china-pub.com/199266

有趣的是，预售阶段就登上了京东的24小时分类畅销榜，感谢大家的厚爱。

按：本文为《程序员》杂志约稿，刊发于2012年3月号，名为《程序员学英语三部曲》，http://www.programmer.com.cn/10833/。

总的来说，程序员可算是英语水平比较好的群体，因为在这个行业，英文资料是最全面、最及时，对英文资料的需求也最迫切的。因此，就我的观察，即便刚入门不久的程序员，面对陌生的问题，一般也能查阅英文文档，找到需要的信息。但是另一方面，我也发现，经常阅读英文文档的程序员，英语水平许多时候却不像“经常阅读英文”的样子。应《程序员》的编辑邀约，我在这里列几点自己的学习心得，供大家参考。

第一，既要看代码，也要读文档。

读文档只读代码，是很多程序员的习惯，也是导致程序员虽然读了很多英文资料，英文水平却没有相应提高的原因之一。以前曾在《程序员》上看到介绍阅读技术图书方法的文章，提出过“先代码后文字”的方法，也就是“先看代码，看不明白再看文字”。这种阅读法能极大提高阅读效率，但如果技术图书只看代码就足够，还要文字干什么呢？很多时候，代码只是冰山一角，代码背后的思维和逻辑才是真正的重头戏，只有写成文字才能解释，也只有阅读文字才能理解。

比如，两段代码都是 x = 5; 看起来没差别，但一段的文字说明是“x should be not more than five”，另一段的文字说明是“x should be no more than five”。不查词典，你能弄清楚两种说法的区别吗——前者是“x必须小于等于5”，后者是“x应当只有5”，意思不同，应用的方法与场合也不相同。

近年来，有越来越多的技术人员投身译介活动，这本来是一件好事，但如果阅读能力不过关，反而会造成更多的困扰。经常有希望翻译技术文档的程序员来找我讨论翻译问题，希望了解一些句子应该如何表达。一开始，我也认为这是中文表达的问题，但后来逐渐发现，其实更多的问题出在英文阅读上，所以我的回答经常是：你觉得作者这里说的是什么意思？引导对方把原文的意思逐步表达出来，其实这时候，真正的译文已经浮出水面了。

最近的例子来自这句话：But as with any web-based system, atom-based solutions trade latency for scalability, making atom often inappropriate for very low-latency notifications。这句话之所以难翻译，问题似乎在于，除去句子的主干，之前有一个But as…， 之后又有一个making…。然而我最后发现，对这个句子有疑问的程序员其实根本没搞懂trade…for…的用法（翻译为“基于atom的解决方案需要权衡延迟性和扩展性”），如果明白它是“牺牲xx换取xx”之后，整个句子就相当好理解，也非常容易翻译了：与所有基于web的系统一样，基于atom的解决方案为追求可扩展性，增大了延迟，所以atom往往并不合适用对延迟要求极低的提示。

要解决这个问题，首先要做的是改变“只看代码不看文字”的习惯，或者至少要做到“阅读文字之后，能明白它的意思与代码是一致的”；另一个有效的办法是通过阅读纯文字的英文资料来学习某些新的知识（比如关于深入原理的细致讲解），这个方法我推荐给许多朋友，非常有效。

第二，注意读音。

以前总听人说，中国人学了很多年英语，其实是哑巴英语。不知道现在的情况有多少改观，但就我所见，不少程序员虽然阅读了大量英文资料，也会加入英文的讨论组，也敢开口说，但是还会在读音上出现许多问题。这里说的“读音”，并不是字正腔圆的口音，而是一些术语的读音。

计算机科学的术语来源非常广泛。比如设计模式里，有一种模式叫Facade，许多人往往直接读作’fəkɑ:d，其实这个词来自法文，正确的读音其实是fə’sɑ:d；再比如伪代码的“伪”pseudo，正确的读音是’su:dəʊ，但是我很少遇到能把它读对的程序员，许多人干脆不会发这个音。

也许有人说，这些问题不重要，大家“将错就错”，约定俗成就好了，但事情没有这么简单。最近我参见某个技术聚会，有位嘉宾（技术高手）把框架名chameleon（变色龙）读成了’tʃəmiljən，而正确的读音是kə’miljən，因为没有文字资料，许多人听了半天才知道他说的是什么，一些不熟悉chameleon的听众更是到结束也没明白。中国人聚会尚且如此，如果有机会参加中外技术交流，读错造成的问题就更大了。

解决这个问题有一个非常好的办法，就是学习美国大学的公开课，耶鲁、斯坦福等学校的计算机系都放出了许多高质量的公开课，学习其中的一些精品课程，不但能夯实基础，还能顺带学会许多每天都要遇到，但不会或者读错的术语。比如我就从中学到，数据类型char的读音是kɑ:，而不是tʃɑ:（经多位读者指出，这个例子有误，kɑ:和tʃɑ:都是可以接受的）。

第三，锻炼英文表达。

如果你背过单词，大概听到过“被动单词”和“主动单词”的说法，前者是指“看到了能认出来”的单词，后者指“表达时能主动应用”的单词。就我的观察，许多程序员掌握的大多数英语，都属于“被动英语”——看到了能认识，但要表达同样的意思，未必说得出来。

平时这样似乎没有问题，可是到了查阅资料时，不会表达就成了大的障碍。相比中文技术资料世界中“无责任/不负责转贴”泛滥的情况，英文技术资料的质量要高得多，Google搜索资料的准确性也远高于百度；但是，要能够顺利应用英文资料，需要“主动”输入信息，描述问题，这时候“被动英语”就成了大问题。

我自己多次遇到过这样的情况：即便答案近在咫尺（输入正确的关键词，Google的第一条结果就是答案），但程序员就是一筹莫展——因为他不知道计算机的“嘟嘟”声是beep，不知道搜“多线程”资料应该用concurrency，也不知道“死机”是system halt，“黑屏”是blank screen，“（登录时）不停返回”是infinite loop……

要解决这个问题，最好的办法是在阅读资料时多用心，记住这些说法；另一方面，没事的时候多浏览stackoverflow之类的网站，不要因为问题与自己无关而忽略，多留心这些问题到底是什么，是如何表达的。这样，在自己遇到问题时，才能迅速找到可能的解决方案，节省时间。

有人说，以汉语为母语的程序员，学习英语已经是迫不得已，不但要会阅读，还要会读、会表达，真是难上加难。这种说法有一定道理，但是在目前并没有更好的解决方案，学会阅读、认准读音、锻炼表达，确实可以给自己带来好处。长远来看，要改变这种情况，需要中文技术圈的所有人员努力贡献高质量的资料（原创和翻译都可以），如果只是“无责任转贴”，既不亲自验证，也不整理格式，中文技术资料的整体质量只会持续恶化，反向逼迫更多的人把英语学好。

我的朋友韩磊曾说：跨界（工作）真是一件刺激好玩的事情。彼时我还无法体会这句话的真义，直到去年因缘际会自己也投身跨界，终于有机会切身体会到其中的滋味，所以有这篇文章。

其实在此之前，我一直混迹于互联网的圈子，自认为接触过一些真正的东西，比如大规模数据的抓取，海量数据的存储和处理，在线系统的维护……客服、文案等等工作也有涉及。我想，太阳底下没有新鲜事，跨界虽然是在不同的领域，做的事情大抵还是这些。但是真正投身实业，才发现事实远非自己想象的那样。

这方面突出的例子之一，就是虚拟世界和现实世界的交流。从某种方面来说，互联网或者纯软件开发，更像在理想的虚拟世界中进行，可以脱开现实的束缚，只关心核心的模型。“发一条确认的消息”是非常普通而且常用的操作，你用Java也好，C#也好，PHP也好，只要按照约定发送这条消息，结果都不会有多大差别；落实到现实世界中，情况要复杂许多：消息必须有实际的载体，有发送的动作，不同的载体和动作，又对应到不同的效率和准确率。举个现实的例子：许多客户端软件，通常要求输入条码识别产品，然后用键盘（鼠标）操作一系列对话框、选择框，执行后续的操作。这个流程看起来没什么问题，但是“扫描-敲键盘”的操作在对处理效率要求很高的情况下，却会成为瓶颈。对此，可行的解决办法是，将键盘/鼠标操作统一为几种消息，比如“是”、“否”、“取消”、“确认”，把这几种消息对应到特殊的条码，将这些条码打印出来，贴在墙上，并辅以不同的提示音。这样，需要输入“是”的时候，只需要用扫描枪扫墙上贴着“是”的条码，并确认听到提示音，就可以完成。大部分时候，操作员的手不用离开扫描枪，甚至不怎么用看屏幕，效率自然大大提高。深入学习了解每个操作、每种功能的具体发生情境，是从互联网/纯软件转到实业开发中，相当重要的一点。

另一方面，实业里有许多领域和环节，因为某些限制，一直没有建立完善的虚拟世界（概念模型），如果能够妥善运用技术突破这些限制，同样能够大大提高操作的效率和质量。比如在物流运输中，“封箱带”部分承载着“保证货物运输过程中不被调换”的职能，但其实“保证不被调换”并不只能依靠封箱带这种手段。如今可以通过先进的设备和完善的系统，记录追踪每一个环节中货物的状态，尤其是重量——进入某个环节时，重量是多少，离开某个环节时，重量又是多少，即便货物被拆分，总重也应当保持不变……前一段时间报道出来的iPhone手机在运输过程中被调包的案件，我注意到，盗贼精心制作了和真iPhone手机同样重量的模具，这样瞒过了各个环节，到最终开箱才被发现，看来是深入了解过整个流程的。

以上都是比对技术思维和现实思维，如果换一个角度，从互联网的视角来看企业开发，又会有新的感受。就我的经验，企业开发中，有两个方面可以大量借鉴互联网开发。

第一是借鉴互联网开发的松耦合、混搭（mashup）思维。传统的企业开发虽然也强调分层，但大多必须严格地按照某些框架和套路来进行，开发人员更主要的工作都是“填格子”，这样有两个弊端：选用的框架和套路并不一定合适，尤其不适合今天迅速变革发展的节奏，开发人员的思维和视野也比较受限，难以交付高质量的成果。而互联网开发虽然比较“乱套”，但天生就强调松耦合，强调“服务意识”，许多开发人员天生就知道调用网上的各种服务，受其影响，也愿意将自己的功能做成服务（而不是一段源代码或一个二进制程序）。在一个相对复杂的系统里，完善的文档说明固然不可缺少，但架构同样重要，各个功能是做成服务，还是做成源代码、二进制程序，很可能极大地影响未来的开发难度和开发成本。这方面，企业开发可以多向互联网开发取经，实际上，许多从互联网行业总结的经验，已经被证明完全可以用于企业开发，比如如今流行的REST模式，就不乏成功的企业实施案例。

第二是借鉴互联网的产品思维。传统的企业开发，更像功能的堆砌，功能的组织和引导都很成问题。我曾留意观察过一些大型企业的ERP系统，虽然看似强大，员工使用起来却叫苦不迭，突出问题界面无序，功能杂乱，数据密密麻麻，很难找到自己需要的信息，操作也很繁琐。而互联网开发早已进入“体验至上”的年代，用户习惯了“凭直觉”操作；在这表象之下，功能并不是少了，而是多了，并不是简单了，而是复杂了，只是以更直观、更清楚地方式呈现给用户，并且需要分析用户的行为，不断调整。两相对比，如果能在企业开发中多一些产品的思考，多一些用户体验的思考，往往会受到良好的效果。现身说法是，我们分析了几个月内，所有员工对系统中某个功能的调用操作行为，总结出若干特点，再加以优化，服务器的负载减轻了很多，员工的操作也简便了很多。在企业系统里，这类工作往往是大有可为，而且收效显著的。

前言

提到正则表达式，许多人很有点不屑一顾：这东西，不登大雅之堂，再说也不是总要用到，何必专门花时间学习？

没错，正则表达式并不是“总要用到”，但到了需要的场合用不上，往往产生“一分钱难倒英雄汉”的尴尬。经常需要处理文本的程序员自然会知道正则表达式的价值，其它的程序员如果不会正则表达式，即便开发的领域与文本处理没什么关系，也难免“躺着中枪”的命运——前几天我遇到一个问题，将一行长长的地址拆分成多行，负责这部分的程序员日常的工作只是制作PDF而已，拆分地址是很“边缘”的功能，但不会正则表达式就无法准确折行（一般需要在标点符号出现的地方折行，而不能只在空白字符处折行，但是不同语言中的标点符号各有不同），结果一筹莫展；相反，如果了解正则表达式，就可以很容易地处理各种语言中的标点字符。

以我的开发经验来看，专门花点时间掌握正则表达式，确实是非常有必要的。目前可以见到的关于正则表达式的书籍和资料已经有不少，但又各有不足。

在互联网上，流传着一些编程语言的正则文档和《30分钟教会你正则表达式》之类的帖子。这类资料的好处是简单直接，查到了，如果有现成的例子，而且适用于自己的语言，可以直接拿来用；然而，其坏处也是简单直接，因为缺乏背后原理的讲解，如果找不到现成的例子，或者找不到能在自己所使用语言中行得通的例子（须知道，同样的正则表达式并不能直接套用到不同的语言中），则束手无策。

在正式的出版领域，已经有《精通正则表达式》、《正则表达式必知必会》之类的书籍出版，尤其是前者，堪称关于正则表达式的经典著作，如果想认真学习正则表达式，这类书籍是必须阅读的。但是这类书籍也有一个弱点，即它们都是从英文版本翻译而来，更多地侧重英文文本的处理，身为中文世界的开发人员，我们经常需要处理中文文本，对于处理英文之外的字符，正则表达式已经提供了足够丰富的功能，但如何用对、用好这些功能，资料却很匮乏。

我经常需要给人讲解正则表达式的相关知识，时常惋惜的是，开发人员为这些问题所困然；正因为如此，本书的写作动机便是着力弥补现有资料的缺陷。

相对于正则文档和速成教学帖子，它深入讲解了匹配背后的原理，往往会举一反三，告诉读者，这里为何这样写，如果改成其它形式，会造成什么结构；并且，集中讲解和比较了多种语言中正则表达式用法的异同，方便读者把现成的正则表达式“移植”到自己的工作环境中。

相对于《精通正则表达式》等正式的书籍，本书辟出专门的内容讲解语言和编码，告诉读者如何设定编码，如何正确处理中文等字符，另外，本书还涵盖了.NET、Java、JavaScript、PHP、Python、Ruby六种常用语言，对每种语言给出专门章节，不但详细介绍了语言中正则表达式的用法，更点明了版本之间的细微差异，不但可以作为专门学习的教材，还可以成为有用的参考手册。

本书的结构

本书可以分为三大部分。

第一部分主要讲解正则表达式的基础知识，覆盖常见正则表达式中的各种功能和结构。看完前面三章，就可以基本弄明白现在流行的各种正则表达式；尤其如果你之前有一些经验，会觉得阅读起来并不困难。但是我也希望读者不要忽略其它的内容，断言和匹配模式现在已经是正则表达式的“标准配备”了，而且确实可以派上大用场，所以第4章和第5章的内容，即便不是很熟悉，阅读起来可能有一些麻烦，也不应该忽略。最后的第6章，则厘清了正则表达式在使用中的若干疑惑，了解它们，你就可以相对自由地在正则表达式的世界里行走了。

第二部分主要讲解关于正则表达式的更深入的知识，这一部分用三章的内容，详细探讨了编码问题、匹配原理、解题思路。这部分内容更抽象，需要多花一点时间来阅读和理解，但是它们确实可以帮你在正则表达式的世界里登堂入室，脱离“术”的层面，掌握万变不离其宗的“道”。

第三部分的作用是接地气，将之前介绍的各种知识落实到六种常用语言.NET、Java、JavaScript、PHP、Python、Ruby中来。每一章的开头有正则功能列表，其中的功能都对应到前面部分的讲解，这些功能的具体应用实例，以及不同版本之间的差异，则在章节中详细讲解，每一章的最后还给出了常见任务的示例代码，方便日后查询。在最后，第16章简要介绍了正则表达式在Linux下常用工具vi、grep、awk、sed中的使用，并通过一个实际的例子将这几种工具串起来，对比说明了它们适合解决的问题。

在本书的最后提供了用作参考的附录，分为三部分。

第一部分是正则表达式的常用功能在不同语言中的比对，希望能给需要在多种语言中使用正则表达式或者移植正则表达式的读者来说提供一份有用的参考；第二部分给出了若干常见的正则表达式，比如匹配邮政编码、身份证号、手机号、QQ号、电子邮件地址等等，希望能成为常见问题的“速查手册”；最后一部分列出了常用正则表达式的工具和资源，方便大家调试自己的正则表达式，以及继续深入学习。

本书的读者

本书适合以下几类读者。

经常需要进行文本处理（比如日志分析或网络运维）的技术人员。这些读者或许已经熟悉了正则表达式的基本用法，但面对日益复杂化和海量化的数据，阅读本书可以帮助你更准确、更高效地处理文本，提升自己工作的价值。

熟悉常用开发语言的程序员。虽然这些读者不需要专职进行文本处理，但源代码和许多数据其实也是文本，如果不会正则表达式，在偶然遇到处理源代码或文本数据的任务时，往往会产生躺着中枪的无力感。本书第三部分可以帮你迅速找到有关的例子，并落实在自己的编程语言中，当然前两部分也非常有必要，因为它们可以帮你夯实基础。

已经对正则表达式有一定了解的读者。这些读者虽然能用正则表达式解决常见的任务，不一定了解正则表达式的编码问题、匹配原理、解题思路，仔细阅读本书的第二部分，可以深化并完善对正则表达式的理解，而第三部分详细比较了使用正则表达式时各种语言、以及同一种语言中各种版本的差异。所有这一切，应该可以让你对正则表达式的掌握更上层楼。

致谢

一本书的完成，必然离不开众多人的帮忙。

首先需要感谢的是周筠老师和徐定翔、卢鸫翔两位编辑，他们在我写作的最初阶段做了大量细心耐心的工作，完全可以说，没有他们的这些工作，我就不会有写作这本书的念头，或者坚持写完的动力。

然后要感谢的是电子工业出版社的杨福平社长和张月萍编辑，没有他们的关照和辛劳工作，这本书的出版定然会遇到更多的困难。

感谢我的朋友霍炬和韩磊，虽然我之前阅读过《精通正则表达式》，但与翻译和写作结缘，他们给了我莫大的帮助，有了这个契机，才有现在的《正则指引》。尤其值得一提的是霍炬的夫人西乔，精心手绘了这本书的封面，在这里表示诚挚的谢意。

感谢我曾工作过的盛大创新院以及创新院的各位同事（李骏、郝培强、庄表伟、丁宇、许式伟、莫华枫、李道兵、赵劼、樊一鹏、张一宁等），创新院给了大家宽松自由的工作环境，与各位同事的讨论加深了我对正则表达式理解，也为我贡献了许多例子。

感谢张东亮、陆亦斌、孙勇、叶劲峰等各位朋友，愿意拨冗阅读本书的草稿，并提出了大量专业的意见。

感谢何源、陈钢、贺钧、陈驰等读者，试读本书之后提出了大量的宝贵意见，在最后关头打消了我心中的许多忐忑。

在更早之前，我的父母从小就鼓励研究和了解各种科学原理（“玩也要动脑筋”），没有这种思维行为习惯，我很可能浅尝辄止而没有兴趣探究正则表达式背后的图景；此外，在中小学阶段，我的语文老师罗碧玉、郭志鸿、易玺铭培养了我对于文字的兴趣，在大学阶段，东北师范大学文学院的王确老师给了我这个理科生非常多的帮助和指引，在此一并表示感谢，能遇到你们是我的幸运。

最后需要还需要感谢许多为这本书做出过贡献的人，你们的名字我可能暂时无法记起，或者无法一一罗列，但我会在心中存留对你们的谢意。