RegexKitLite：iPhone开发中的正则表达式实战

5星 · 超过95%的资源需积分: 3 160 浏览量更新于2024-07-31 收藏 1.11MB PDF 举报

“Iphone开发中的正则表达式” 在iPhone应用开发中，正则表达式是一种强大的工具，用于处理字符串的匹配、查找、替换等任务。RegexKitLite是专为Objective-C开发人员设计的一个轻量级库，它利用了ICU（International Components for Unicode）库来实现对正则表达式的支持。此教程主要针对iOS平台，为开发者提供了一个方便的接口，以高效且易于理解的方式使用正则表达式。 RegexKitLite的特点包括： 1. **轻量级**：RegexKitLite设计简洁，引入到项目中不会增加过多的体积，对性能影响较小。 2. **Objective-C友好**：提供了与Objective-C语法兼容的方法，使得在Objective-C代码中使用正则表达式更加直观。 3. **ICU库支持**：ICU是一个功能强大的Unicode库，提供了丰富的正则表达式功能，包括高级的模式匹配和字符串操作。在使用RegexKitLite时，开发者可以： - **匹配字符串**：使用`+matchesInString:options:error:`方法来检测一个字符串是否符合特定的正则表达式模式。 - **查找子串**：通过`+rangeOfFirstMatchInString:options:error:`找到第一个匹配的子串及其范围。 - **替换操作**：利用`-stringByReplacingOccurrencesOfPattern:withString:options:error:`方法，可以将符合正则表达式的部分替换为新的字符串。 - **分组捕获**：RegexKitLite支持正则表达式中的捕获组，允许获取匹配的多个部分。学习iPhone开发中的正则表达式，开发者可以更有效地处理用户输入验证、数据提取、格式化等任务。例如，验证电子邮件地址格式、检查电话号码合法性或从URL中解析域名等。同时，正则表达式的掌握也能帮助开发者优化代码，提高程序的效率。本教程的目标读者是对iPhone应用开发有一定基础，并希望深入了解正则表达式在iOS环境中的应用的开发者。通过学习，开发者不仅可以掌握RegexKitLite的使用，还能深化对正则表达式原理的理解，从而在实际项目中更好地利用这一工具。需要注意的是，尽管本教程遵循Apple的文档风格，但并不代表它获得了Apple的官方认可或支持。不过，文档中的内容都是基于实际经验和最佳实践，旨在帮助开发者提高技能和解决问题。此外，文档中可能涉及到其他制造商和销售商的产品名称，这些名称通常被正确地标记为商标，以避免侵权问题。在使用正则表达式和RegexKitLite时，开发者应确保代码的准确性，因为文档可能包含错误、不准确之处或遗漏。开发过程中，应当进行充分的测试，以防止潜在的问题或意外行为导致的损失。由于技术的不断更新，开发者也需要保持对最新技术和工具的关注，以便及时更新知识体系。

C 1

RegexKitLite Overview

See Also

ICU4C C API - Regular Expressions

ICU Regular Expression Syntax (p. 25)

UTF-16 Conversion Cache

RegexKitLite is ideal when the string being matched is a non-ASCII, Unicode string. is is because the

regular expression engine used, ICU, can only operate on UTF-16 encoded strings. Since Cocoa keeps es-

sentially all non-ASCII strings encoded in UTF-16 form internally, this means that RegexKitLite can operate

directly on the strings buﬀer without having to make a temporary copy and transcode the string in to ICU's

required format.

Like all object oriented programming, the internal representation of an objects information is private. How-

ever, the ICU regular expression engine requires that the text to be search be encoded as a UTF-16 string.

For pragmatic purposes, Core Foundation has several public functions that can provide direct access to the

buﬀer used to hold the contents of the string, but such direct access is only available if the private buﬀer is

already encoded in the requested direct access format. As a rough rule of thumb, 8-bit simple strings, such

as ASCII, are kept in their 8-bit format. Non 8-bit simple strings are stored as UTF-16 strings. Of course, this

is an implementation private detail, so this behavior should never be relied upon. It is mentioned because

of the tremendous impact on matching performance and eﬃciency it can have if a string must be converted

to UTF-16.

For strings in which direct access to the UTF-16 string is available, RegexKitLite uses that buﬀer. is is the

ideal case as no extra work needs to be performed, such as converting the string in to a UTF-16 string, and

allocating memory to hold the temporary conversion. Of course, direct access is not always available, and

occasionally the string to be searched will need to be converted in to a UTF-16 string.

RegexKitLite has two conversion cache types. Each conversion cache type contains four buﬀers each, and

buﬀers are re-used on a least recently used basis. If the selected cache type does not contain the con-

tents of the NSString that is currently being searched in any of its buﬀers, the least recently used buﬀer

is cleared and the current NSString takes it place. e rst conversion cache type is xed in size and

set by the C preprocessor dene RKL_FIXED_LENGTH, which defaults to 2048. Any string whose length is

less than RKL_FIXED_LENGTH will use the xed size conversion cache type. e second conversion cache

type, for strings whose length is longer than RKL_FIXED_LENGTH, will use a dynamically sized conversion

buﬀer. e memory allocation for the dynamically sized conversion buﬀer is resized for each conversion

with realloc() to the size needed to hold the entire contents of the UTF-16 converted string.

is strategy was chosen for its relative simplicity. Keeping track of dynamically created resources is re-

quired to prevent memory leaks. As designed, there are only four pointers to dynamically allocated memory:

the four pointers to hold the conversion contents of strings whose length is larger than RKL_FIXED_LENGTH.

However, since realloc() is used to manage those memory allocations, it becomes very diﬃcult to acciden-

tally leak the buﬀers. Having the xed sized buﬀers means that the memory allocation system isn't bothered

with many small requests, most of which are transient in nature to begin with. e current strategy tries to

strike the best balance between performance and simplicity.

Mutable Strings

When converted in to a UTF-16 string, the hash of the NSString is recorded, along with the pointer to the

NSString object and the strings length. In order for the RegexKitLite to use the cached conversion, all of

these parameters must be equal to their values of the NSString to be searched. If there is any diﬀerence,

the cached conversion is discarded and the current NSString, or NSMutableString as the case may be, is

reconverted in to a UTF-16 string.

UTF-16 Conversion Cache

C 1

RegexKitLite Overview

Caution:

Care must be taken when mutable strings are searched and there exists the possibility that

the string has mutated between searches. See NSString RegexKitLite Additions Reference

- Cached Information and Mutable Strings (p. 50) for more information.

Multithreading Safety

RegexKitLite is also multithreading safe. Access to the compiled regular expression cache and the conver-

sion cache is protected by a single OSSpinLock to ensure that only one thread has access at a time. e

lock remains held while the regular expression match is performed since the compiled regular expression

returned by the ICU library is not safe to use from multiple threads. Once the match has completed, the

lock is released, and another thread is free to lock the cache and perform a match.

Important:

While it is safe to use the same regular expression from any thread at any time, the usual

multithreading caveats apply. For example, it is not safe to mutate a NSMutableString

in one thread while performing a match on the mutating string in another.

If Blocks functionality is enabled, and a RegexKitLite method that takes a Block as one of its parameters is

used, RegexKitLite takes a slightly diﬀerent approach in order to support the asynchronous, and possibly

re-entrant, nature of Blocks.

First, an autoreleased Block helper proxy object is created and is used to keep track of any Block local re-

sources needed to perform a Block-based enumeration.

en the regular expression cache is checked exactly as before. Once a compiled regular expression is ob-

tained, the ICU function uregex_clone is used to create a Block local copy of the regular expression. After

the Block local copy has been made, the global compiled regular expression cache lock is unlocked.

If the string to be searched requires conversion to UTF-16, then a one time use Block local UTF-16 conversion

of the string is created.

ese changes mean that RegexKitLite Block-based enumeration methods are just as multithreading safe

and easy to use as non-Block-based enumeration methods, such as the ability to continue to use RegexKitLite

methods without any restrictions from within the Block used for enumeration.

64-bit Support

RegexKitLite is 64-bit clean. Internally, RegexKitLite uses Cocoas standard NSInteger and NSUInteger

types for representing integer values. e size of these types change between 32-bit and 64-bit automatically,

depending on the target architecture. ICU, on the other hand, uses a signed 32-bit int type for many of its

arguments, such as string oﬀset values. Because of this, the maximum length of a string that RegexKitLite

will accept is the maximum value that can be represented by a signed 32-bit integer, which is approximately

2 gigabytes. Strings that are longer this limit will raise NSRangeException. is limitation may be signicant

to those who are switching to 64-bit because the size of the data they need to process exceeds what can be

represented with 32-bits.

Note:

Several numeric constants throughout this document will have either L or UL appended to

them– for example 0UL, or 2L. is is to ensure that they are treated as 64-bit long or

unsigned long values, respectively, when targeting a 64-bit architecture.

Multithreading Safety

C 2

Using RegexKitLite

e goal of RegexKitLite is not to be a comprehensive Objective-C regular expression framework, but to

provide a set of easy to use primitives from which additional functionality can be created. To this end,

RegexKitLite provides the following two core primitives from which everything else is built:

◼ - (NSInteger)captureCountWithOptions:(RKLRegexOptions)options

error:(NSError **)error;

◼ - (NSRange)rangeOfRegex:(NSString *)regex options:(RKLRegexOptions)options

inRange:(NSRange)range capture:(NSInteger)capture error:(NSError **)error;

ere is often a need to create a new string of the characters that were matched by a regular expression.

RegexKitLite provides the following method which conveniently combines sending the receiver

substringWithRange: with the range returned by rangeOfRegex:.

◼ - (NSString *)stringByMatching:(NSString *)regex options:(RKLRegexOptions)options

inRange:(NSRange)range capture:(NSInteger)capture error:(NSError **)error;

RegexKitLite 2.0 adds the ability to split strings by dividing them with a regular expression, and

the ability to perform search and replace operations using common $n substitution syntax.

replaceOccurrencesOfRegex:withString: (p. 87) is used to modify the contents of NSMutableString

objects directly and stringByReplacingOccurrencesOfRegex:withString: (p. 93) will create a new, im-

mutable NSString from the receiver.

◼ - (NSArray *)componentsSeparatedByRegex:(NSString *)regex

options:(RKLRegexOptions)options range:(NSRange)range error:(NSError **)error;

◼ - (NSUInteger)replaceOccurrencesOfRegex:(NSString *)regex

options:(RKLRegexOptions)options withString:(NSString *)replacement

range:(NSRange)range error:(NSError **)error;

◼ - (NSString *)stringByReplacingOccurrencesOfRegex:(NSString *)regex

options:(RKLRegexOptions)options withString:(NSString *)replacement

range:(NSRange)range error:(NSError **)error;

RegexKitLite 3.0 adds several new methods that return a NSArray containing the aggregated results of a

number of individual regex operations.

◼ - (NSArray *)arrayOfCaptureComponentsMatchedByRegex:(NSString *)regex

options:(RKLRegexOptions)options range:(NSRange)range error:(NSError **)error;

◼ - (NSArray *)captureComponentsMatchedByRegex:(NSString *)regex

options:(RKLRegexOptions)options range:(NSRange)range error:(NSError **)error;

◼ - (NSArray *)componentsMatchedByRegex:(NSString *)regex range:(NSRange)range;

Using RegexKitLite

C 2

Using RegexKitLite

RegexKitLite 4.0 adds several new methods that take advantage of the new blocks language extension.

◼ - (BOOL)enumerateStringsMatchedByRegex:(NSString *)regex usingBlock:(void (^)(

NSInteger captureCount, NSString * const capturedStrings[captureCount],