徐 亚玲 (xuyal@cn.ibm.com), 软件工程师, IBM 中国开发试验室

2007 年 10 月 18 日

在全球经济一体化的今天，网络让大家可以共享同等的信息。世界是平的，在这个变平的世界里，我们仍然需要克服语言和文化的差异， 如果软件如果能够做到全球化，以不同的语言和文化提供信息，那么无疑这个全球化的软件也是让这个世界变平的力量之一。

Eclipse已经成为大家耳熟能详的开发环境和架构平台。现在IBM越来越多的客户端产品移植到Eclipse RCP平台，本文将介绍基于Eclipse RCP的产品的全球化实现。

Eclipse RCP介绍

Eclipse的文章很多，那么我们就来总结一下关键词：开放的可扩展的IDE －> 可插入插件的开发环境 －> 带标准插件集(Java Development Tool, JDT)的JAVA开发环境 －>可开发插件的开发环境（Plug-in Development Environment, PDE）－> 开放的可扩展的应用平台。

Eclipse的开放和可扩展究其根源是运行时组件模式的架构（runtime component module），我们可以从C++的纯虚基类到COM原理来解释这些动态可加载原理，从他们的似曾相识来认知多年来我们不变的追求。Eclipse 使用 OSGi 作为插件系统的基础，OSGi，Open Services Gateway Initiative是一个基于Java语言的服务（业务）规范，该规范和核心部分是一个框架，Eclipse框架采用Lazy loading，提供了运行时可扩展的扩展点模式。

Eclipse Rich Client Platform, RCP， 在Eclipse platform的基础上增加了GUI的特性，它当然也具备Java的跨平台特性，是由可构建桌面应的最小的一组插件组成的运行平台。这里面的关键词/ SWT， JFace，Workbench。首先，Standard Widget Toolkit，SWT最显著的特点是体现了系统平台即操作系统的UI的特性，是平台相关的套件集合。基于SWT开发的UI体现了操作系统平台的UI特征。 JFace在SWT上提供了更高层的封装，提供了功能强大的界面组建，菜单，工具条，状态条等等。 Workbench: 提供了更高层的可扩展可管理的UI, 包括editors, views 和 perspectives。

Eclipse RCP 对国际化的支持

您谈到软件的国际化支持，我们通常会从对字符集，文化习惯和对翻译的支持也就是对本地化的支持三个方面来考虑。

对于前两个方面，我们知道现在通过UNICODE字符集来支持全球字符，而文化习惯包括日期，时间，货币，地址等等，尽管不同的国家地区千差万别，但它的实现通常并没有我们想象的那么复杂，可以通过调用支持全球化的组件来实现对字符集和文化特性的支持。例如IBM 中国开发中心的Globalization团队就推出过基于SWT的支持文化特性的套件，这些套件可在基于RCP平台的应用中被重用。所以，在以下的段落中我们会重点来谈如何实现Eclipse RCP 软件对本地化的支持，也就是软件的可翻译性。

我们将从以下几方面探讨软件的可翻译性：

• 界面布局
• BIDirection
• 可翻译资源外部化，即资源与代码分离及资源文件的管理

Layout manager 对布局的支持

通常，在传统开发中，界面布局问题一直是困扰本地化开发过程中比较大的问题，由于文本翻译后引起长度的扩展，导致了界面布局的截断，对齐和遮盖问题。如下图，在翻译为Greek语言后，出现了很多截断问题。

图形界面的布局调整是一项工作量非常大的工作，我们知道传统开发是以矩形来定位控件的布局，即通过坐标值和长度及宽度来描述控件的位置和大小，通常在英文产品开发过程中，会通过预留一定的扩展空间来解决这个问题，但是翻译的过程中存在着很多偶然性，经常会有一些翻译过长的字串还会出现截断问题，同时所有语言共享统一的留有扩展的界面布局降低了界面的友好性，在英文和CJKT这些扩展较少的语言上，我们会觉得界面上有太多的空白空间。

SWT中的Layout manager很好的解决了这个问题。layout manager会管理界面的布局，SWT提供了四种layout manager，在这四种layout manager中，功能最强大，最复杂，也最有实用性的是GridLayout。GridLayout用网格来控制布局。关于layout manager 有最经典的介绍文章，大家可以通过这些文章来了解layout manager的工作原理。本文则是要强调一定要用layout manager来解决本地化过程中界面的布局问题，在布局设计时要想到本地化后引起的扩展问题，在这种前提下开发，会将布局问题减少到最小，我们在测试Sametime7.5 等RCP的产品过程中发现，布局这一困扰本地化开发的问题得到了根本的解决。

在SWT的示例程序中，我们可以看到layout manager在本地化过程中是如何自动调整布局的， 在AddressBook这个例子中采用了Fill Layout 布局管理器，当我们扩展这些界面上要翻译的字符串时，我们看到界面的布局也随之自动的扩展变化。

Bidirection

SWT套件允许设置为从右到左RTL，但BiDi的支持与平台有关，BiDi支持正扩展到所有Windows平台和GTK的linux平台。如果产品考虑支持BiDi，需要调研你使用的SWT版本对BiDi的支持。

资源的外部化Externalization

大家都知道在Java程序中使用Resource bundle来处理locale相关的资源文件， 所有要翻译的资源保存到按照locale命名的properties文件中，通过resource bundle来调用。Locale这个词一直没有很好的翻译，我们可以理解为语言＋地区，我们命名properties文件也会以locale作为扩展，例如中国的简体中文文件，我们会命名为address_zh_CN.properties, 而台湾的繁体中文文件会命名为address_zh_TW.properties, 当在中文中国locale下时，程序设计会依顺序查找address_zh_CN.properties，然后是 address_zh.properties，最后fall back到address.properties，而在中文台湾locale下则会查找address_zh_TW.properties，找不到会是地域不同但语言相近的address_zh.properties，最后是英文的address.properties。

如果你在编程时没有这样的远虑，可以使用Eclipse提供的wizard来完成这项工作，这部分也有很多技术资料可参考。同时我们更应该从程序设计开始就做好资源文件的规划，下面我们来介绍一下资源文件的管理，注释，翻译和检查工作。

资源文件的管理

在一个项目中如何有效的定义，创建和管理资源文件？首先我们会对资源进行分类，按照资源的类型我们会分为User Interface,UI界面资源和User Assisant, UA帮助资源，从最终使用者的角度，资源可分为普通用户资源和IT用户的资源。

我们把用户分为普通用户和IT用户，普通用户是指用户的领域并非IT领域，例如银行柜员，尽管他熟悉他所使用的业务系统，但他并非IT专职人员，而IT用户则特指如程序员，网络管理员等IT从业者。从最终用户来区分资源，我们可以根据资源的使用者来确定是否要翻译这部分资源。通常普通用户的资源翻译级别较高，而IT用户的资源翻译级别较低，例如一些专业的调试出错信息，IT用户可能更倾向于使用英文原文信息。

在JAVA项目中，通常UA帮助文件会以html的形式存在，所以我们通常以不同语言命名的文件夹下面。而对于UI文件，正如我们前面介绍的，通常存为filename_{locale}.properties 的文件。

在这里，我们在创建资源文件时要同时创建filenames.properties和filenames_en.properties文件，在filenames_en.properties中存放要翻译的字串而在filenames.properties中存放版权信息和不需要翻译的资源。通过这个简单的拆分法，我们可以得到很多开发的方便之处：

• 首先可以保证只有要翻译的资源被送出去翻译，而不需翻译的资源保留在本地不会被改变；
• 当需要翻译的资源开始翻译，因而不可以继续修改时，不需翻译的资源文件filenames.properties还可以继续更新；
• 首先可以保证只有要翻译的资源被送出去翻译，而不需翻译的资源保留在本地不会被改变；
• 当需要翻译的资源开始翻译，因而不可以继续修改时，不需翻译的资源文件filenames.properties还可以继续更新；
• 同时我们作伪翻译测试和资源文件检查时，也可以有效的判断哪些是语言相关的资源和文件。
• 在生成安装包时，我们可以动态的将filenames.properties 文件加到filename_{locale}.properties中，而将filenames_en.properties加到filenames.properties中，形成最终的properties文件组。

伪翻译及伪翻译测试

伪翻译测试是测试软件可翻译性的最有效的手段，通常我们测试软件的可翻译性可通过伪翻译或pilot翻译来测试。伪翻译的过程是利用工具将产品中需要翻译的部分随机或按照一定规则进行转换，以这种转换来模仿翻译的过程，而pilot翻译则是在英文产品开发的同时，选择某种语言例如德文进行同步翻译。通过产品开发过程中的伪翻译或pilot翻译，测试下面几类问题：

1．是否有需要翻译的字符串被硬编码。当所有的资源文件中的资源被伪翻译为某种字符，例如全部被转换为圆点符号，那么界面上仍旧显示为英文ASCII原文的字符串就有可能是硬编码在代码中，没有被伪翻译的字符串。这些字符串需要被resource out， 才会被正确的翻译和显示。

2．对字符集的支持在伪翻译过程中，我们会把原ASCII字符伪翻译为风险字符来测试产品对这些特殊字符的支持。关于风险字符，如果大家感兴趣，我会单独写一篇介绍文章，每个语言的风险字符不同，另外比如欧元，GB18030字符都是容易出现问题的风险字符。如下给出了一段将ASCII码转化为重音字符的脚本代码，基于这种转换，不但可以测试对西欧中欧重音字符的支持，同时保证了程序的可读性。

 1Select Case temp
 2        Case "a"
 3            tempstr = tempstr + "ã"
 4        Case "A"
 5            tempstr = tempstr + "À"
 6        Case "B"
 7            tempstr = tempstr + "ß"
 8        Case "c"
 9            tempstr = tempstr + "ç"
10        Case "C"
11            tempstr = tempstr + "Ç"
12        Case "d"
13            tempstr = tempstr + "ð"
14        Case "D"
15            tempstr = tempstr + "Ð"
16        Case "e"
17            tempstr = tempstr + "é"   
18        Case "E"
19            tempstr = tempstr + "É"
20        Case "n"
21            tempstr = tempstr + "ñ"     
22        Case "N"
23            tempstr = tempstr + "Ñ"
24        Case "o"
25            tempstr = tempstr + "ö"     
26        Case "O"
27            tempstr = tempstr + "Ô"
28        Case "i"
29            tempstr = tempstr + "ï"   
30        Case "I"     
31            tempstr = tempstr + "Ï"     
32        Case "p"
33            tempstr = tempstr + "þ"
34        Case  temp = "P"
35            tempstr = tempstr + "Þ"
36        Case "u"
37            tempstr = tempstr + "û"
38        Case  temp = "U"
39            tempstr = tempstr + "Ü"
40        Case "y"
41            tempstr = tempstr + "ý"
42        Case  temp = "Y"
43            tempstr = tempstr + "Ý"
44        Case Else
45            tempstr = tempstr + temp
46        End Select
47

3．界面布局的可翻译性我们可以选择按一定比例，例如30%，扩展原文的伪翻译方式，如果伪翻译后界面出现截断，不对齐等问题，说明界面的设计不具备可翻译性。由于语言的翻译有很多偶然性，可以随机的把一些字符串加长，来测试界面对可翻译性的支持。

4．串联字符串在伪翻译的过程中，我们会通过给每句要翻译的文本在首尾加上分割符例如[]来发现这类问题。当一个完整的句子是由几个片断拼凑起来的话会为翻译带来很大的困扰，例如：

Strings_OutOfOffice = I will be out of the office

Strings_StartTime= starting {0}.

在实际运行环境中的显示为：I will be out of the office starting 2007-8-17.

我们可以通过定义在句首加“[”，句末加“]”的伪翻译规则，这样在伪翻译后：

Strings_OutOfOffice=[I will be out of the office]

Strings_StartTime=[starting{0}]

在实际运行环境中的显示为：[I will be out of the office][ starting 2007-8-17.] 如果在一个整句中发现“][”，则是有串联情况出现。

这句话整句翻译成中文：我从2007-8-17日起不在办公室。

Strings_OutOfOffice=我不在办公室

Strings_StartTime=从{0}.

当在资源文件中被分为两个断句分别翻译在进行组合时，翻译变为“我不在办公室从2007-8-17日”，显然，这不符合中文的翻译习惯。所以，在翻译的过程中，由于不同语言间的文化特性有很大的不同，语序经常会出现变化，只有保持句子的完整性，才能保证翻译的准确性。

小结

以上从开发和全球化测试的角度介绍了 Eclipse RCP 上的国际化，软件的本地化是一个比较复杂的工程，在开发中充分考虑对本地化的支持，使用自动化工具来进行管理会使这个工程更加更加规范有序

跳过目录

1. 本文目标
2. 如何使用本教程
3. 正则表达式到底是什么东西？
4. 入门
5. 测试正则表达式
6. 元字符
7. 字符转义
8. 重复
9. 字符类
10. 分枝条件
11. 反义
12. 分组
13. 后向引用
14. 零宽断言
15. 负向零宽断言
16. 注释
17. 贪婪与懒惰
18. 处理选项
19. 平衡组/递归匹配
20. 还有些什么东西没提到

本文目标

30分钟内让你明白正则表达式是什么，并对它有一些基本的了解，让你可以在自己的程序或网页里使用它。

如何使用本教程

最重要的是——请给我30分钟，如果你没有使用正则表达式的经验，请不要试图在30秒内入门——除非你是超人 :)

别被下面那些复杂的表达式吓倒，只要跟着我一步一步来，你会发现正则表达式其实并没有你想像中的那么困难。当然，如果你看完了这篇教程之后，发现自己明白了很多，却又几乎什么都记不得，那也是很正常的——我认为，没接触过正则表达式的人在看完这篇教程后，能把提到过的语法记住80%以上的可能性为零。这里只是让你明白基本的原理，以后你还需要多练习，多使用，才能熟练掌握正则表达式。

除了作为入门教程之外，本文还试图成为可以在日常工作中使用的正则表达式语法参考手册。就作者本人的经历来说，这个目标还是完成得不错的——你看，我自己也没能把所有的东西记下来，不是吗？

清除格式 文本格式约定：专业术语 元字符/语法格式 正则表达式 正则表达式中的一部分(用于分析) 对其进行匹配的源字符串 对正则表达式或其中一部分的说明

隐藏边注 本文右边有一些注释，主要是用来提供一些相关信息，或者给没有程序员背景的读者解释一些基本概念，通常可以忽略。

正则表达式到底是什么东西？

字符是计算机软件处理文字时最基本的单位，可能是字母，数字，标点符号，空格，换行符，汉字等等。字符串是0个或更多个字符的序列。文本也就是文字，字符串。说某个字符串匹配某个正则表达式，通常是指这个字符串里有一部分（或几部分分别）能满足表达式给出的条件。

在编写处理字符串的程序或网页时，经常会有查找符合某些复杂规则的字符串的需要。正则表达式就是用于描述这些规则的工具。换句话说，正则表达式就是记录文本规则的代码。

很可能你使用过Windows/Dos下用于文件查找的通配符(wildcard)，也就是*和?。如果你想查找某个目录下的所有的Word文档的话，你会搜索*.doc。在这里，*会被解释成任意的字符串。和通配符类似，正则表达式也是用来进行文本匹配的工具，只不过比起通配符，它能更精确地描述你的需求——当然，代价就是更复杂——比如你可以编写一个正则表达式，用来查找所有以0开头，后面跟着2-3个数字，然后是一个连字号“-”，最后是7或8位数字的字符串(像010-12345678或0376-7654321)。

入门

学习正则表达式的最好方法是从例子开始，理解例子之后再自己对例子进行修改，实验。下面给出了不少简单的例子，并对它们作了详细的说明。

假设你在一篇英文小说里查找hi，你可以使用正则表达式hi。

这几乎是最简单的正则表达式了，它可以精确匹配这样的字符串：由两个字符组成，前一个字符是h,后一个是i。通常，处理正则表达式的工具会提供一个忽略大小写的选项，如果选中了这个选项，它可以匹配hi,HI,Hi,hI这四种情况中的任意一种。

不幸的是，很多单词里包含hi这两个连续的字符，比如him,history,high等等。用hi来查找的话，这里边的hi也会被找出来。如果要精确地查找hi这个单词的话，我们应该使用\bhi\b。

\b是正则表达式规定的一个特殊代码（好吧，某些人叫它元字符，metacharacter），代表着单词的开头或结尾，也就是单词的分界处。虽然通常英文的单词是由空格，标点符号或者换行来分隔的，但是\b并不匹配这些单词分隔字符中的任何一个，它只匹配一个位置。

如果需要更精确的说法，\b匹配这样的位置：它的前一个字符和后一个字符不全是(一个是,一个不是或不存在)\w。

假如你要找的是hi后面不远处跟着一个Lucy，你应该用\bhi\b.*\bLucy\b。

这里，.是另一个元字符，匹配除了换行符以外的任意字符。*同样是元字符，不过它代表的不是字符，也不是位置，而是数量——它指定*前边的内容可以连续重复出现任意次以使整个表达式得到匹配。因此，.*连在一起就意味着任意数量的不包含换行的字符。现在\bhi\b.*\bLucy\b的意思就很明显了：先是一个单词hi,然后是任意个任意字符(但不能是换行)，最后是Lucy这个单词。

换行符就是'\n',ASCII编码为10(十六进制0x0A)的字符。

如果同时使用其它元字符，我们就能构造出功能更强大的正则表达式。比如下面这个例子：

0\d\d-\d\d\d\d\d\d\d\d匹配这样的字符串：以0开头，然后是两个数字，然后是一个连字号“-”，最后是8个数字(也就是中国的电话号码。当然，这个例子只能匹配区号为3位的情形)。

这里的\d是个新的元字符，匹配一位数字(0，或1，或2，或……)。-不是元字符，只匹配它本身——连字符或者减号。

为了避免那么多烦人的重复，我们也可以这样写这个表达式：0\d{2}-\d{8}。 这里\d后面的{2}({8})的意思是前面\d必须连续重复匹配2次(8次)。

测试正则表达式

如果你不觉得正则表达式很难读写的话，要么你是一个天才，要么，你不是地球人。正则表达式的语法很令人头疼，即使对经常使用它的人来说也是如此。由于难于读写，容易出错，所以找一种工具对正则表达式进行测试是很有必要的。

由于在不同的环境下正则表达式的一些细节是不相同的，本教程介绍的是微软 .Net Framework 2.0下正则表达式的行为，所以，我向你介绍一个.Net下的工具Regex Tester。首先你确保已经安装了.Net Framework 2.0，然后下载Regex Tester。这是个绿色软件，下载完后打开压缩包,直接运行RegexTester.exe就可以了。

下面是Regex Tester运行时的截图：

元字符

现在你已经知道几个很有用的元字符了，如\b,.,*，还有\d.正则表达式里还有更多的元字符，比如\s匹配任意的空白符，包括空格，制表符(Tab)，换行符，中文全角空格等。\w匹配字母或数字或下划线或汉字等。

对中文/汉字的特殊处理是由.Net提供的正则表达式引擎支持的，其它环境下的具体情况请查看相关文档。

下面来看看更多的例子：

\ba\w*\b匹配以字母a开头的单词——先是某个单词开始处(\b)，然后是字母a,然后是任意数量的字母或数字(\w*)，最后是单词结束处(\b)。

好吧，现在我们说说正则表达式里的单词是什么意思吧：就是多于一个的连续的\w。不错，这与学习英文时要背的成千上万个同名的东西的确关系不大 :)

\d+匹配1个或更多连续的数字。这里的+是和*类似的元字符，不同的是*匹配重复任意次(可能是0次)，而+则匹配重复1次或更多次。

\b\w{6}\b 匹配刚好6个字母/数字的单词。

元字符^（和数字6在同一个键位上的符号）和$都匹配一个位置，这和\b有点类似。^匹配你要用来查找的字符串的开头，$匹配结尾。这两个代码在验证输入的内容时非常有用，比如一个网站如果要求你填写的QQ号必须为5位到12位数字时，可以使用：^\d{5,12}$。

这里的{5,12}和前面介绍过的{2}是类似的，只不过{2}匹配只能不多不少重复2次，{5,12}则是重复的次数不能少于5次，不能多于12次，否则都不匹配。

因为使用了^和$，所以输入的整个字符串都要用来和\d{5,12}来匹配，也就是说整个输入必须是5到12个数字，因此如果输入的QQ号能匹配这个正则表达式的话，那就符合要求了。

和忽略大小写的选项类似，有些正则表达式处理工具还有一个处理多行的选项。如果选中了这个选项，^和$的意义就变成了匹配行的开始处和结束处。

字符转义

如果你想查找元字符本身的话，比如你查找.,或者*,就出现了问题：你没办法指定它们，因为它们会被解释成别的意思。这时你就得使用\来取消这些字符的特殊意义。因此，你应该使用\.和\*。当然，要查找\本身，你也得用\\.

例如：unibetter\.com匹配unibetter.com，C:\\Windows匹配C:\Windows。

重复

你已经看过了前面的*,+,{2},{5,12}这几个匹配重复的方式了。下面是正则表达式中所有的限定符(指定数量的代码，例如*,{5,12}等)：

下面是一些使用重复的例子：

Windows\d+匹配Windows后面跟1个或更多数字

^\w+匹配一行的第一个单词(或整个字符串的第一个单词，具体匹配哪个意思得看选项设置)

字符类

要想查找数字，字母或数字，空白是很简单的，因为已经有了对应这些字符集合的元字符，但是如果你想匹配没有预定义元字符的字符集合(比如元音字母a,e,i,o,u),应该怎么办？

很简单，你只需要在方括号里列出它们就行了，像[aeiou]就匹配任何一个英文元音字母，[.?!]匹配标点符号(.或?或!)。

我们也可以轻松地指定一个字符范围，像[0-9]代表的含意与\d就是完全一致的：一位数字；同理[a-z0-9A-Z_]也完全等同于\w（如果只考虑英文的话）。

下面是一个更复杂的表达式：\(?0\d{2}[) -]?\d{8}。

“(”和“)”也是元字符，后面的分组节里会提到，所以在这里需要使用转义。

这个表达式可以匹配几种格式的电话号码，像(010)88886666，或022-22334455，或02912345678等。我们对它进行一些分析吧：首先是一个转义字符\(,它能出现0次或1次(?),然后是一个0，后面跟着2个数字(\d{2})，然后是)或-或空格中的一个，它出现1次或不出现(?)，最后是8个数字(\d{8})。

分枝条件

不幸的是，刚才那个表达式也能匹配010)12345678或(022-87654321这样的“不正确”的格式。要解决这个问题，我们需要用到分枝条件。正则表达式里的分枝条件指的是有几种规则，如果满足其中任意一种规则都应该当成匹配，具体方法是用|把不同的规则分隔开。听不明白？没关系，看例子：

0\d{2}-\d{8}|0\d{3}-\d{7}这个表达式能匹配两种以连字号分隔的电话号码：一种是三位区号，8位本地号(如010-12345678)，一种是4位区号，7位本地号(0376-2233445)。

\(0\d{2}\)[- ]?\d{8}|0\d{2}[- ]?\d{8}这个表达式匹配3位区号的电话号码，其中区号可以用小括号括起来，也可以不用，区号与本地号间可以用连字号或空格间隔，也可以没有间隔。你可以试试用分枝条件把这个表达式扩展成也支持4位区号的。

\d{5}-\d{4}|\d{5}这个表达式用于匹配美国的邮政编码。美国邮编的规则是5位数字，或者用连字号间隔的9位数字。之所以要给出这个例子是因为它能说明一个问题：使用分枝条件时，要注意各个条件的顺序。如果你把它改成\d{5}|\d{5}-\d{4}的话，那么就只会匹配5位的邮编(以及9位邮编的前5位)。原因是匹配分枝条件时，将会从左到右地测试每个条件，如果满足了某个分枝的话，就不会去再管其它的条件了。

分组

我们已经提到了怎么重复单个字符（直接在字符后面加上限定符就行了）；但如果想要重复多个字符又该怎么办？你可以用小括号来指定子表达式(也叫做分组)，然后你就可以指定这个子表达式的重复次数了，你也可以对子表达式进行其它一些操作(后面会有介绍)。

(\d{1,3}\.){3}\d{1,3}是一个简单的IP地址匹配表达式。要理解这个表达式，请按下列顺序分析它：\d{1,3}匹配1到3位的数字，(\d{1,3}\.){3}匹配三位数字加上一个英文句号(这个整体也就是这个分组)重复3次，最后再加上一个一到三位的数字(\d{1,3})。

IP地址中每个数字都不能大于255，大家千万不要被《24》第三季的编剧给忽悠了...

不幸的是，它也将匹配256.300.888.999这种不可能存在的IP地址。如果能使用算术比较的话，或许能简单地解决这个问题，但是正则表达式中并不提供关于数学的任何功能，所以只能使用冗长的分组，选择，字符类来描述一个正确的IP地址：((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)。

理解这个表达式的关键是理解2[0-4]\d|25[0-5]|[01]?\d\d?，这里我就不细说了，你自己应该能分析得出来它的意义。

反义

有时需要查找不属于某个能简单定义的字符类的字符。比如想查找除了数字以外，其它任意字符都行的情况，这时需要用到反义：

例子：\S+匹配不包含空白符的字符串。

<a[^>]+>匹配用尖括号括起来的以a开头的字符串。

后向引用

使用小括号指定一个子表达式后，匹配这个子表达式的文本(也就是此分组捕获的内容)可以在表达式或其它程序中作进一步的处理。默认情况下，每个分组会自动拥有一个组号，规则是：从左向右，以分组的左括号为标志，第一个出现的分组的组号为1，第二个为2，以此类推。

后向引用用于重复搜索前面某个分组匹配的文本。例如，\1代表分组1匹配的文本。难以理解？请看示例：

\b(\w+)\b\s+\1\b可以用来匹配重复的单词，像go go, 或者kitty kitty。这个表达式首先是一个单词，也就是单词开始处和结束处之间的多于一个的字母或数字(\b(\w+)\b)，这个单词会被捕获到编号为1的分组中，然后是1个或几个空白符(\s+)，最后是分组1中捕获的内容（也就是前面匹配的那个单词）(\1)。

你也可以自己指定子表达式的组名。要指定一个子表达式的组名，请使用这样的语法：(?<Word>\w+)(或者把尖括号换成'也行：(?'Word'\w+)),这样就把\w+的组名指定为Word了。要反向引用这个分组捕获的内容，你可以使用\k<Word>,所以上一个例子也可以写成这样：\b(?<Word>\w+)\b\s+\k<Word>\b。

使用小括号的时候，还有很多特定用途的语法。下面列出了最常用的一些：

我们已经讨论了前两种语法。第三个(?:exp)不会改变正则表达式的处理方式，只是这样的组匹配的内容不会像前两种那样被捕获到某个组里面，也不会拥有组号。

零宽断言

地球人，是不是觉得这些术语名称太复杂，太难记了？我也和你一样。知道有这么一种东西就行了，它叫什么，随它去吧！“无名，万物之始...”

接下来的四个用于查找在某些内容(但并不包括这些内容)之前或之后的东西，也就是说它们像\b,^,$那样用于指定一个位置，这个位置应该满足一定的条件(即断言)，因此它们也被称为零宽断言。最好还是拿例子来说明吧：

断言用来声明一个应该为真的事实。正则表达式中只有当断言为真时才会继续进行匹配。

(?=exp)也叫零宽度正预测先行断言，它断言自身出现的位置的后面能匹配表达式exp。比如\b\w+(?=ing\b)，匹配以ing结尾的单词的前面部分(除了ing以外的部分)，如查找I'm singing while you're dancing.时，它会匹配sing和danc。

(?<=exp)也叫零宽度正回顾后发断言，它断言自身出现的位置的前面能匹配表达式exp。比如(?<=\bre)\w+\b会匹配以re开头的单词的后半部分(除了re以外的部分)，例如在查找reading a book时，它匹配ading。

假如你想要给一个很长的数字中每三位间加一个逗号(当然是从右边加起了)，你可以这样查找需要在前面和里面添加逗号的部分：((?<=\d)\d{3})*\b，用它对1234567890进行查找时结果是234567890。

下面这个例子同时使用了这两种断言：(?<=\s)\d+(?=\s)匹配以空白符间隔的数字(再次强调，不包括这些空白符)。

负向零宽断言

前面我们提到过怎么查找不是某个字符或不在某个字符类里的字符的方法(反义)。但是如果我们只是想要确保某个字符没有出现，但并不想去匹配它时怎么办？例如，如果我们想查找这样的单词--它里面出现了字母q,但是q后面跟的不是字母u,我们可以尝试这样：

\b\w*q[^u]\w*\b匹配包含后面不是字母u的字母q的单词。但是如果多做测试(或者你思维足够敏锐，直接就观察出来了)，你会发现，如果q出现在单词的结尾的话，像Iraq,Benq，这个表达式就会出错。这是因为[^u]总要匹配一个字符，所以如果q是单词的最后一个字符的话，后面的[^u]将会匹配q后面的单词分隔符(可能是空格，或者是句号或其它的什么)，后面的\w*\b将会匹配下一个单词，于是\b\w*q[^u]\w*\b就能匹配整个Iraq fighting。负向零宽断言能解决这样的问题，因为它只匹配一个位置，并不消费任何字符。现在，我们可以这样来解决这个问题：\b\w*q(?!u)\w*\b。

零宽度负预测先行断言(?!exp)，断言此位置的后面不能匹配表达式exp。例如：\d{3}(?!\d)匹配三位数字，而且这三位数字的后面不能是数字；\b((?!abc)\w)+\b匹配不包含连续字符串abc的单词。

同理，我们可以用(?<!exp),零宽度正回顾后发断言来断言此位置的前面不能匹配表达式exp：(?<![a-z])\d{7}匹配前面不是小写字母的七位数字。

请详细分析表达式(?<=<(\w+)>).*(?=<\/\1>)，这个表达式最能表现零宽断言的真正用途。

一个更复杂的例子：(?<=<(\w+)>).*(?=<\/\1>)匹配不包含属性的简单HTML标签内里的内容。(<?(\w+)>)指定了这样的前缀：被尖括号括起来的单词(比如可能是<b>)，然后是.*(任意的字符串),最后是一个后缀(?=<\/\1>)。注意后缀里的\/，它用到了前面提过的字符转义；\1则是一个反向引用，引用的正是捕获的第一组，前面的(\w+)匹配的内容，这样如果前缀实际上是<b>的话，后缀就是</b>了。整个表达式匹配的是<b>和</b>之间的内容(再次提醒，不包括前缀和后缀本身)。

注释

小括号的另一种用途是通过语法(?#comment)来包含注释。例如：2[0-4]\d(?#200-249)|25[0-5](?#250-255)|[01]?\d\d?(?#0-199)。

要包含注释的话，最好是启用“忽略模式里的空白符”选项，这样在编写表达式时能任意的添加空格，Tab，换行，而实际使用时这些都将被忽略。启用这个选项后，在#后面到这一行结束的所有文本都将被当成注释忽略掉。例如，我们可以前面的一个表达式写成这样：

      (?<=    # 断言要匹配的文本的前缀
<(\w+)> # 查找尖括号括起来的字母或数字(即HTML/XML标签)
)       # 前缀结束
.*      # 匹配任意文本
(?=     # 断言要匹配的文本的后缀
<\/\1>  # 查找尖括号括起来的内容：前面是一个"/"，后面是先前捕获的标签
)       # 后缀结束

贪婪与懒惰

当正则表达式中包含能接受重复的限定符时，通常的行为是（在使整个表达式能得到匹配的前提下）匹配尽可能多的字符。考虑这个表达式：a.*b，它将会匹配最长的以a开始，以b结束的字符串。如果用它来搜索aabab的话，它会匹配整个字符串aabab。这被称为贪婪匹配。

有时，我们更需要懒惰匹配，也就是匹配尽可能少的字符。前面给出的限定符都可以被转化为懒惰匹配模式，只要在它后面加上一个问号?。这样.*?就意味着匹配任意数量的重复，但是在能使整个匹配成功的前提下使用最少的重复。现在看看懒惰版的例子吧：

a.*?b匹配最短的，以a开始，以b结束的字符串。如果把它应用于aabab的话，它会匹配aab（第一到第三个字符）和ab（第四到第五个字符）。

为什么第一个匹配是aab（第一到第三个字符）而不是ab（第二到第三个字符）？简单地说，因为正则表达式有另一条规则，比懒惰／贪婪规则的优先级更高：最先开始的匹配拥有最高的优先权——The match that begins earliest wins。

处理选项

在C#中，你可以使用Regex(String, RegexOptions)构造函数来设置正则表达式的处理选项。如：Regex regex = new Regex("\ba\w{6}\b", RegexOptions.IgnoreCase);

上面介绍了几个选项如忽略大小写，处理多行等，这些选项能用来改变处理正则表达式的方式。下面是.Net中常用的正则表达式选项：

一个经常被问到的问题是：是不是只能同时使用多行模式和单行模式中的一种？答案是：不是。这两个选项之间没有任何关系，除了它们的名字比较相似（以至于让人感到疑惑）以外。

平衡组/递归匹配

这里介绍的平衡组语法是由.Net Framework支持的；其它语言／库不一定支持这种功能，或者支持此功能但需要使用不同的语法。

有时我们需要匹配像( 100 * ( 50 + 15 ) )这样的可嵌套的层次性结构，这时简单地使用\(.+\)则只会匹配到最左边的左括号和最右边的右括号之间的内容(这里我们讨论的是贪婪模式，懒惰模式也有下面的问题)。假如原来的字符串里的左括号和右括号出现的次数不相等，比如( 5 / ( 3 + 2 ) ) )，那我们的匹配结果里两者的个数也不会相等。有没有办法在这样的字符串里匹配到最长的，配对的括号之间的内容呢？

为了避免(和\(把你的大脑彻底搞糊涂，我们还是用尖括号代替圆括号吧。现在我们的问题变成了如何把xx <aa <bbb> <bbb> aa> yy这样的字符串里，最长的配对的尖括号内的内容捕获出来？

这里需要用到以下的语法构造：

• (?'group') 把捕获的内容命名为group,并压入堆栈(Stack)
• (?'-group') 从堆栈上弹出最后压入堆栈的名为group的捕获内容，如果堆栈本来为空，则本分组的匹配失败
• (?(group)yes|no) 如果堆栈上存在以名为group的捕获内容的话，继续匹配yes部分的表达式，否则继续匹配no部分
• (?!) 零宽负向先行断言，由于没有后缀表达式，试图匹配总是失败

如果你不是一个程序员（或者你自称程序员但是不知道堆栈是什么东西），你就这样理解上面的三种语法吧：第一个就是在黑板上写一个"group"，第二个就是从黑板上擦掉一个"group"，第三个就是看黑板上写的还有没有"group"，如果有就继续匹配yes部分，否则就匹配no部分。

我们需要做的是每碰到了左括号，就在压入一个"Open",每碰到一个右括号，就弹出一个，到了最后就看看堆栈是否为空－－如果不为空那就证明左括号比右括号多，那匹配就应该失败。正则表达式引擎会进行回溯(放弃最前面或最后面的一些字符)，尽量使整个表达式得到匹配。

<                         #最外层的左括号
[^<>]*                #最外层的左括号后面的不是括号的内容
(
(
(?'Open'<)    #碰到了左括号，在黑板上写一个"Open"
[^<>]*       #匹配左括号后面的不是括号的内容
)+
(
(?'-Open'>)   #碰到了右括号，擦掉一个"Open"
[^<>]*        #匹配右括号后面不是括号的内容
)+
)*
(?(Open)(?!))         #在遇到最外层的右括号前面，判断黑板上还有没有没擦掉的"Open"；如果还有，则匹配失败
>                         #最外层的右括号

平衡组的一个最常见的应用就是匹配HTML,下面这个例子可以匹配嵌套的<div>标签：<div[^>]*>[^<>]*(((?'Open'<div[^>]*>)[^<>]*)+((?'-Open'</div>)[^<>]*)+)*(?(Open)(?!))</div>.

还有些什么东西没提到

我已经描述了构造正则表达式的大量元素，还有一些我没有提到的东西。下面是未提到的元素的列表，包含语法和简单的说明。你可以在网上找到更详细的参考资料来学习它们--当你需要用到它们的时候。如果你安装了MSDN Library,你也可以在里面找到关于.net下正则表达式详细的文档。

    (当然还有其他方法,在这里主要介绍properties类型的配置文件)
 2.对配置信息的操作无非就两种,从配置文件中读取信息,并将信息赋值给程序中的相应变量,还有就是当软件运行到某一个特定的时候,手动或自

动将软件中的某些信息写入到配置文件中,以便于以后的调用.为了方便的对properties类型的配置文件进行操作,在这里介绍一个Java提供的

一个类:Properties大家可以查看API以了解此类的详细信息.
    对于最简单的应用,这里只用到Properties中的三个方法:
    1.void load(InputStream inStream)从输入流中读取属性列表（键和元素对）。这个inStream可以有多种取得的方法,这里只介绍一种通过
        ClassName.class.getClassLoader().getResourceAsStream()来取得properties文件.通常:ClassName.class.getClassLoader ().getResourceAsStream(““)取得的是
        WEB-INF的下级目录，比如ClassName.class.getClassLoader().getResourceAsStream(“db.properties“).在Tomcat中，可以通过增加”../”来取得上层目录
        ，即WEB-INF目录，这样就可以把properties放在WEB-INF中统一管理。但是WLS不识别”../”。另外一种土办法，就是不返回classLoader,
        直接ClassName.class.getResourceAsStream()。然后通过多个”../”（小于6个）来返回相应的上级目录。当然，如果类扩展了HttpServlet，可以通过
        getServletContext().getRealPath("/")来取得Web部署目录的绝对路径。 
    2. String getProperty(String key)用指定的键在此属性列表中搜索属性。
    3. Object setProperty(String key, String value)调用 Hashtable 的方法 put。
    4.  void   store(OutputStream out, String comments) 以适合使用 load(InputStream) 方法加载到Properties 表中的格式，将此Properties 表中的属性列表（键和元素对）
        写入输出流。

在读之前必须要用1方法得到输入流,在写之前必须先建一个到配置文件的输出流作为4的参数,写完后用4方法
处于Singleton设计模式的考虑,建议把整个对配置文件的操作写成一个类,并且将所有变量方法全部设置为静态

JVM启动，会形成3个类加载器组成的初始化加载器层次结构：
bootstap classloader （加载核心类）
        ||
extension classloader（加载ext(目录)，即java.ext.dirs()）
        ||
system classloader   （加载-classpath或者java.class.path或者CLASSPATH）

ClassLoader机制：
a）全盘负责：一个classloader加载一个class后，这个class所引用或者依赖的类也由这个classloader载入，除非显示的用另一个classloader载入
b）委托机制：先由父加载器加载，除非父加载器找不到时才从自己的类路径中去寻找
c）Cache机制：classloader采用缓存机制，即先查cache；若cache中保存了这个class就直接返回；若无，才从文件读取和转化为class并放入cache

ClassLoader加载类顺序：
1）检查cache是否有该类：
    11）若有直接返回
    12）若无，请求父类加载
    　　　　121) 若无父,则从bootstap classloader加载
2）加载：
    21）寻找class文件（丛与此classloader相关的类路径中寻找）
    22）从文件载入class
    23）找不到则抛出ClassNotFoundeException
3）扩展：
    记载时即2），覆写findClass可以实现自己的载入策略
    记载时即2），覆写loadClass来实现自己的载入过程

如何实现运行时动态载入与更新
本质：只要动态改类搜索路径和清除classloader的cache已载入的class就ok
做法：
1）继承ClassLoader：覆写loadClass方法，动态寻找class文件
2）只要重新使用一个新的类搜索路径来new一个classloader就可以，这样既更新了类的搜索路径以便来载入新的class，也更新生成了一个空白的cache

classloader载入的方式
1）Pre-loading 预先载入，载入基础类
2）load-on-demand 按需求载入

JDK为啥有两个JRE？
JDK中jre是运行java本身的程序，如javac
ProgramFile（默认安装）中jre是运行用户编写的java程序

classloader有啥妙用（1）？
这个问题得从自定义的classloader身上说，那自定义classloader缘由是什么呢？
告诉你：大多是因为编译时无法预知运行时需要哪些类，特别是app server；因此自定义classloader，运行时指定路径，来加载这个路径下的class

特殊说明
特殊说明1：如果没有特殊指定，用户自定义的classloader都把system classloader作为它的父加载器
特殊说明2：jvm认为不同的classloade载入相同名字的class是不同的，即使从同一个class文件载入

classloader有啥妙用（2）？
看到特殊说明2，你或许就会感觉疑惑或者不爽；啥概念？
以servlet、ejb等容器来剖析这个问题：

将接口或者基类放入classpath                         <---------system classloader
执行时，动态载入实现或者继承这些接口或者基类的子类；<---------customized classloader
         ||
         ||
用customized classloader载入类时，发现它有一个父类class（extends）；
但是在载入它时，jvm先加载父类class； 这个父类是system classloader能识别的； 根据“委托机制”它将由system classloader来加载；
然后customized classloader（实际是system classloader来加载）再载入这个class,创建一个实例，转型为父类；
jvm就使用system classloader再次载入父类class，然后将此实例转型为这个父类class；

这个过程加载了两个父类class，都是由system classloader载入；即同一个classloader载入同一个文件，造型不会由异常

web app server大概是这样工作的；这样载入了任何继承了servlet的class并正确运行它们，不管class是什么，都它们实例化为一个servlet class