因为工作不够细致,最终版本的《精通正则表达式》还存在如下问题,只能以勘误形式发布作为补救了,请各位读者见谅。
如果大家在阅读中发现其他问题,欢迎来信指出。
yusheng.regex@gmail.com

Update:2009年2月24日,新发布了Excel版本的勘误列表,包括了之前收集的所有勘误,并给出了印次信息,更方便阅读和修改,本勘误列表不再更新,请大家下载Excel版本的勘误列表:MRE_errata.xls


 

推荐序

vi页, 第1行, “那它就被成为阳春应用”,应该修改为“那它就被称为阳春应用”;

前言

Ⅱ页,倒数第3段,“读这本书以前,我以为自己了解正则表达式,但现在我才真正了解”应修改为“读这本书以前,我以为自己了解正则表达式,但现在我才真正弄明白”

Ⅱ页,倒数第2段,“在其它任何地方都难以找到这样丰富的细节”应修改为“在其它任何地方都难以找到这样完整而详尽的资料”

Ⅴ页,第1段,“来开发引擎的能力,并避免其中的缺陷”应修改为“来发掘引擎的能力,绕开引擎的缺陷”

Ⅵ页,第1段,“[…]表示一对方括号,之间的内容无关紧要;而[…]表示一对方括号,其中包含三个句点”应修改为“[…]表示其间内容无关紧要的一对方括号,而[…]表示包含三个句点的方括号”

第1章

2页,倒数第2段,“但是它不一定能代表正则表达式在平时解决的那些“不值一提”(uninteresting)的问题。这里的“不值一提”是指这 类问题并不能成为谈 资,可是不解决它们,你就没法继续干活”应修改为“但是正则表达式在平时还用来解决那些“讨人厌(uninteresting)”的问题。说“讨人厌”, 是因为它们不适合跟外人吹嘘,可是不解决它们,你就没法继续干活”

3页,第12行,“^(From|Sbuject):”应修改为“^(From|Subject):”

6页,标题“正则表达式的思维框架”应修改为“理解正则表达式的结构”

9页,倒数第3段,“在搜索HTML代码的头文件时这非常有用”应修改为“在搜索HTML Header时这非常有用”

12页,注4中“作为一个小孩子,那时候我感觉非常受伤”应修改为“当时我还是个孩子,很伤心”

14页,第4段,“匹配一行的起始位置,然后匹配「^From」、「Subject」或「Date」中的任意一个”应修改为“匹配一行的起始位置,然后匹配「From」、「Subject」或「Date」中的任意一个”

15页,第3段,“我使用-i参数的频率很高”应修改为“我经常使用-i参数”

15页,倒数第4段,“>”字符不应该是黑体

17页,倒数第3段,“无论u是否出现,匹配都是成功的”应修改为“无论u是否出现,匹配都会成功”

18页,倒数第3段,“因为它们限定了所作用元素的匹配次数”应修改为“因为它们限定了所作用元素的重现次数”

19页,第2段,“一个字符组是一个“元素”(unit),所以它可以直接加加号、星号等,而不需要用括号”应修改为“一个字符组就是一个“元素”(unit),可以对它直接使用加号、星号等,而不需要括号”

19页,倒数第1段,“每个量词都规定了匹配成功至少需要的次数下限,以及尝试匹配的次数上限”应修改为“每个量词都规定了匹配成功至少需要的重现次数下限,以及尝试匹配的重现次数上限”

20页,表1-2中:“可以不出现,也可以只出现一次”修改为“可以出现,也可以只重现一次”;“可以出现无数次,也可以不出现”修改为“可以重现无穷多次,也可以不出现”; “可以出现无数次,但至少要出现一次”修改为“可以重现无穷多次,但至少要出现一次”

21页,倒数第2段,“这并不是正则表达式的错误”应修改为“正则表达式对此无能为力”

27 页,第1段,“而且说“如果你写一个正则”,“巧妙的正则”(budding regexers),甚至是“正则化”(regexification)”修改为“而且说“如果你写一个正则”,“巧妙的正则”(budding regexers),甚至是“正则化”(regexification)听起来更顺一些。我说的“正则引擎(regex engine)”指的是程序中实际执行匹配尝试的那个部分”

第2章

37页,第1段,“它们都非常不同于“传统”的语言,例如C和Pascal”应修改为“它们截然不同于C和Pascal之类“传统”的语言”

37页,第13行,“print “celsuius C is … #返回摄氏和华氏温度” 应修改为 “print “celsuius C is … #输出摄氏和华氏温度”

38页,倒数第1段,“运算符==用来测试两个数字是否相等”修改为“运算符==用来测试两个数值是否相等”

40 页,第1段,“我不想在本章中讨论Perl的细节,但是我告诉你用printf(“格式化输出(print formatted)”)可以解决这个问题”修改为“我不想在本章中讨论Perl的细节,不过我还是想说,printf(“格式化输出(print formatted)”)可以解决这个问题”

40页,第3段,“Perl通常情况下不区分整数和浮点数”修改为“Perl一般不区分整数和浮点数”

41页,倒数第1段,“我们发现,这个图让我们很容易地决定匹配之后应该干什么”修改为“看了这张图,我们很容易就能决定匹配之后应该干什么”

46页,补充内容的最后1段,“尽管因为第4章将会解释其原因,字符组的效率通常还是会高一点”修改为“不过根据第4章解释的原因,字符组的效率通常要高一些”

56页,倒数第2行,“^From: (\s+) \”修改为“^From: (\S+) \”(S的大小写不同)

57页,第3行,“^From: (\s+) \”修改为“^From: (\S+) \”(S的大小写不同)

67页,第3段下面,正则表达式“$text =~ s/(\d)(?=(\d\d\d)+(?!\d)/$1,/g”应修改为“$text =~ s/(\d)(?=(\d\d\d)+(?!\d))/$1,/g”,少了一个括号

70页,第2段,所以整个正则表达式的意义就不再是“寻找空行及只包含空白字符的行”,而是“寻找连续、空行和只包括空白字符的行的结合”
应修改为
所以整个正则表达式的意义就不再是“寻找空行或只包含空白字符的行”,而是“寻找空行和只包含空白字符的行的结合”

76页,倒数第2段,“此外,我们的匹配主机名的正则表达式只存在一个“主源(main source)””应修改为“此外,我们的匹配主机名的正则表达式只存在一个“源头(main source)”,”

第78页
示例2-3中第4标注
{\e[7m$1\e[m$2\e[7m$3\e[m ] igx;
应修改为
{\e[7m$1\e[m$2\e[7m$3\e[m } igx;

第3章

89页,第1段,“不支持字符组中的\w(完全不支持\d和\s)”应修改为“在字符组中无法使用\w(\d和\s在任何地方都无法使用)”

92页,倒数第2段,“在极端的情况下,反向引用的“行为”有意义吗?”应修改为“在极端的情况下,反向引用还能正常工作吗?”

93页,第12行,”┌(July|Jul)┘和┌\(July\|Jul\)┘能够取得同样的匹配结果…“应修改为”┌(Jul|July)┘和┌\(July\|Jul\)┘能够取得同样的匹配结果…“

95页,标题“函数式处理的例子”应修改为“程序式处理的例子”

95页,倒数第1段,“不过,Java也提供了一些函数式处理的……”应修改为“不过,Java也提供了一些程序式处理的……”

95页,Pattern r = Pattern.compile(“^Sujbcet:(.*)”,Pattern.CASE_INSENSITIVE);
其中的Sujbcet应写为Subject

96页,第2段,“Sun的package同时提供了程序式和面向对象式的处理方式是常见的做法”应修改为“Sun的package同时提供了程序式和面向对象式的处理方式,这是种常见的做法”

96页,倒数第六行,”出现NULL(而且可以用点号来匹配)。“应修改为”出现NUL(而且可以用点号来匹配)。“

111页,第1段,“常见的例子是大写的ß是两个字符的组合“SS”。这种情况只有Perl能够正确处理”应修改为“常见的例子是,大写的ß由两个字符“SS”组合而成。这种情况只有Perl能够正确处理”

114页,“字符组及相关结构”中,“字符组缩略表示法”应修改为“字符组简记法”

119页,第2行,”范围内的所有字符…(例如,[0-9]与[908176354]是一样的。)…“应修改为”范围内的所有字符…(例如,[0-9]与[9081763542]是一样的。)…“

130页,3-11表名“脚本语言中的行锚点”应修改为“若干语言中的行锚点”

131页,第1段,“如果结合上面那一点”应修改为“结合第一点”

132页,第3段,“但是这段程序的执行单位不是一次表达式而是一次匹配”应修改为“但是,循环的单位不是单个的表达式,而以一组表达式的匹配”

134页,“中间一级不过是“语法(syntactic sugar)”,表达方式更美观而已,”应修改为“中间一级不过是用起来更方便而已(syntactic sugar)”

第4章

152页,倒数第1段,括号内,“抑制自己的天性”应修改为“克制自己的本能”

156 页,第3段,“也就是说“不到最后关头不能分胜负(It’s not over until the fat lady sings)”,但这段话又不符合本段的语境”
应修改为
“也就是说“不到最后关头不能分胜负(It’s not over until the fat lady sings)””

156页 第3段 第2行
原文: 即使某个字表达式能够匹配
应改为:即使某个子表达式能够匹配

160页 文字部分的 第5行
原文: 字符串的b之前(也就是当前的位置)匹配
应该为:字符串的c之前(也就是当前的位置)匹配

172页,第2段,“就可以命令正则引擎不必检查它们:「^(?>\w+)」”应修改为“就可以命令正则引擎不必检查它们:「^(?>\w+):」”

172页,最后一段,最后一个正则表达式(\.\d\d[1-9]?+)^\d+,应该修改为(\.\d\d[1-9]?+)\d+

173页,第一段,第2个正则表达式(?>M)+应修改为(?>M+)。

第5章

188页 文字部分的 第4段 第2行 结尾
原文: 也不比担心
应该为:也不必担心

189页,倒数第9行,”我们也把能把匹配三位数的多选分支放在最前面,这样…”应修改为”我们就把能把匹配三位数的多选分支放在最前面,这样…”

191页,代码段中的注释大小写错误,“#利用正则表达式检测wholePath”应修改为“#利用正则表达式检测WholePath”

193页,第6行,”算式中的括号。我们…想到┌\bfoo\([^])*\)┘,但这行不通。”应修改为”算式中的括号。我们…想到┌\bfoo\([^)]*\)┘,但这行不通。”

194页,第5行,”┌\[^()]*(\([^()]*\)[^()]*)*\)┘“应修改为”┌\([^()]*(\([^()]*\)[^()]*)*\)┘”

195页,倒数第1段,“虽然这个表达式比最开始的好得多”应修改为“虽然这个表达式比开头那个好一些”

197页,第3段,“所以,我们得用别的办法来解决”应修改为“所以,得想点别的办法”

197页,第4段,“仔细想想我们想要匹配的位于开始分隔符和结束分隔符之间的文本”应修改为“仔细想想要匹配的位于开始分隔符和结束分隔符之间的文本”

197页,倒数第3段,“如果回溯会导致不期望,与多选结构有关的匹配结果”应修改为“如果回溯会导致不期望的、与多选结构有关的匹配结果”

199页,第5段,“这个正则表达式曾被用作降解忽略优先量词的绝佳例子”应修改为“这个正则表达式曾被用作讲解忽略优先量词的绝佳例子”

199页,倒数第2段,“但它并不正确(其实这三个表达式都不正确)”应修改为“但它并没有错(其实