[Unicode]  Technical Reports

Unicode Technical Report #18

Unicode Regular Expression Guidelines

Version 5.1
Authors Mark Davis (mark.davis@us.ibm.com)
Date 2000-08-31
This Version http://www.unicode.org/unicode/reports/tr18/tr18-5.1
Previous Version http://www.unicode.org/unicode/reports/tr18/tr18-5
Latest Version http://www.unicode.org/unicode/reports/tr18


This document describes guidelines for how to adapt regular expression engines to use Unicode. The document is in initial phase, and has not gone through the editing process. We welcome review feedback and suggestions on the content.


This document has been reviewed by Unicode members and other interested parties, and has been approved by the Unicode Technical Committee as a Unicode Technical Report. It is a stable document and may be used as reference material or cited as a normative reference from another document.

A Unicode Technical Report (UTR) may contain either informative material or normative specifications, or both. Each UTR may specify a base version of the Unicode Standard. In that case, conformance to the UTR requires conformance to that version or higher.

A list of current Unicode Technical Reports is found on http://www.unicode.org/unicode/reports/. For more information about versions of the Unicode Standard, see http://www.unicode.org/unicode/standard/versions/ .
Please mail corrigenda and other comments to the author(s).


1 Introduction

The following describes general guidelines for extending regular expression engines to handle Unicode. The following issues are involved in such extensions.

There are three fundamental levels of Unicode support that can be offered by regular expression engines:

One of the most important requirements for a regular expression engine is to document clearly what Unicode features are and are not supported. Even if higher-level support is not currently offered, provision should be made for the syntax to be extended in the future to encompass those features.

Note: Unicode is a constantly evolving standard: new characters will be added in the future. This means that a regular expression that tests for, say, currency symbols will have different results in Unicode 2.0 than in Unicode 2.1 (where the Euro currency symbol was added.)

At any level, efficiently handling properties or conditions based on a large character set can take a lot of memory. A common mechanism for reducing the memory requirements — while still maintaining performance — is the two-stage table, discussed in The Unicode Standard, Section 5.7. For example, the Unicode character properties can be stored in memory in a two-stage table with only 7 or 8Kbytes. Accessing those properties only takes a small amount of bit-twiddling and two array accesses.

1.1 Notation

In order to describe regular expression syntax, we will use an extended BNF form:

x y
the sequence consisting of x then y
zero or more occurences of x
zero or one occurence of x
x | y
either x or y
( x )
for grouping
terminal character

The following syntax for character ranges will be used in successive examples. This is only a sample syntax for the purposes of examples in this paper. (Regular expression syntax varies widely: the issues discussed here would need to be adapted to the syntax of the particular implementation.)

<list> := LIST_START NEGATION? <item> (LIST_SEP? <item>)* LIST_END
<item> := <character>
       | <character> "-" <character> // range
       | ESCAPE <character>

LIST_END := "]"
LIST_SEP := ","
ESCAPE := "\" 


[a-z,A-Z,0-9] Match ASCII alphanumerics
[^a-z,A-Z,0-9] Match anything but ASCII alphanumerics
[\],\-,\,] Match the literal characters ], -, ','

The comma between items is not really necessary, but can improve readability.

2 Basic Unicode Support: Level 1

Regular expression syntax usually allows for an expression to denote a set of single characters, such as [a-z,A-Z,0-9]. Since there are a very large number of characters in the Unicode standard, simple list expressions do not suffice.

2.1 Hex notation

The character set used by the regular expression writer may not be Unicode, so there needs to be some way to specify arbitrary Unicode characters. The most standard notation for listing hex Unicode characters within strings is by prefixing with "\u". Making this change results in the following addition:

<character> := <simple_character>

UTF16_MARK := "u" 


[\u3040-\u309F,\u30FC] Match Hiragana characters, plus prolonged sound sign
[\u00B2,\u2082] Match superscript and subscript 2

2.2 Categories

Since Unicode is a large character set, a regular expression engine needs to provide for the recognition of whole categories of characters; otherwise the listing of characters becomes impractical. Engines should be extended using the Unicode general character categories.

For example, what the regular expression means by a digit should match to any of the Unicode digits, etc. The Unicode general character categories are available in the Unicode Character Database (UCD) described in UnicodeCharacterDatabase.html and UnicodeData.html, and consist of: Letters, Punctuation, Symbols, Marks, Numbers, Separators, and Other. These each have a single letter abbreviation, which is the uppercase first character except for separators, which use Z. The official data mapping Unicode characters to these categories is found on UnicodeData.txt.

Each of these categories has different subcategories. For example, the subcategories for Letter are uppercase, lowercase, titlecase, modifier, and other (in this case, other includes uncased letters such as Chinese). By convention, the subcategory is abbreviated by the category letter (in uppercase), followed by the first character of the subcategory in lowercase. For example, Lu stands for Letter, uppercase.

Where a regular expression is expressed as much as possible in terms of higher-level semantic constructs such as Letter, it makes it practical to work with the different alphabets and languages in Unicode. Here is an example of a syntax addition that permits categories:

<item> := CATEGORY_START <unicode_category> CATEGORY_END



[{L},{Nd}] Match all letters and decimal digits

Two additional special categories that are generally useful are:

{ALL} This matches all code points. This could also be captured with \u0000-\uFFFF, except for reasons we will get into later. In some regular expression languages, [{ALL}] is expressed by a period.
{ASSIGNED} This is equivalent to all characters but those marked as {Cn}, and matches all assigned characters (in the target version of Unicode).
{UNASSIGNED} This is equivalent to {Cn}, and matches all unassigned characters (in the target version of Unicode). This can be used to exclude unassigned characters, as we will see in the next section.

A regular-expression mechanism may choose to offer the ability to identify characters on the basis of other Unicode properties besides the general category. In particular, Unicode characters are also divided into blocks as described in Blocks.txt. For example, [\u0370-\u03FF] is the Greek block, and could be matched by syntax like [{isGreek}]. However, there are some significant caveats to the use of Unicode blocks for the identification of characters: see Annex A. Character Blocks. See also Chapter 4, Character Properties for more information.

2.3 Subtraction

With a large character set, character categories are essential. In addition, there needs to be a way to "subtract" characters from what is already in the list. For example, one may want to include all letters but Q and W without having to list every character in {L} that is neither Q nor W. Here is an example of a syntax change that handles this, by allowing subtraction of any character set from another.


<item> := <character>
       | <character> "-" <character> // range
       | ESCAPE <character> 


<item> := <character>
       | <character> "-" <character> // range
       | ESCAPE <character>
       | "-" <list>        // subtraction 


[{L}-[Q,W]] Match all letters but Q and W
[{N}-[{Nd}]0-9] Match all non-decimal numbers, plus 0-9.
[\u0000-\u007F-[^{L}]] Match all letters in the ASCII range, by subtracting non-letters.
[\u0370-\u03FF-[{UNASSIGNED}]] Match currently assigned modern Greek characters
[{ASSIGNED}-[a-f,A-F,0-9]] Match all assigned characters except for hex digits.

It may also be useful to add syntax for an intersection of character ranges. This is often clearer than using set difference, such as using [\u0000-\u007F&[{L}]] instead of  [\u0000-\u007F-[^{L}]].

2.4 Simple Word Boundaries

Most regular expression engines allow a test for word boundaries (such as by "\b" in Perl). They generally use a very simple mechanism for determining word boundaries: a word boundary is between any pair of characters where one is a <word_character> and the other is not. A basic extension of this to work for Unicode is to make sure that the class of <word_character> includes all the Letter values from the Unicode character database, on UnicodeData-Latest.txt.

Level 2 provides more general support for word boundaries between arbitrary Unicode characters.

2.5 Simple Loose Matches

The only loose matches that most regular expression engines offer is caseless matching. If the engine does offers this, then it must account for the large range of cased Unicode characters outside of ASCII. In addition, because of the vagaries of natural language, there are situations where two different Unicode characters have the same uppercase or lowercase. Level 1 implementations need to handle these cases. For example, the Greek U+03C3 "σ" small sigma, U+03C2 "ς" small final sigma, and U+03A3 "Σ" capital sigma must all match.

Some caseless matches may match one character against two: for example, U+00DF "ß" matches the two characters "SS". However, because many implementations are not set up to handle this, at Level 1 only 1-1 case matches are necessary. To correctly implement a caseless match and case conversions, see UTR #21: Case Mappings.

2.6 End Of Line

Most regular expression engines also allow a test for line boundaries. This presumes that lines of text are separated by line (or paragraph) separators. To follow the same approach with Unicode, the end-of-line or start-of-line testing should include not only CRLF, LF, CR, but also PS (U+2029) and LS (U+2028). See Unicode Technical Report #13, Unicode Newline Guidelines for more information.

These characters should be uniformly handled in determining logical line numbers, start-of-line, end-of-line, and arbitrary-character implementations. Logical line number is useful for compiler error messages
and the like. Regular expressions often allow for SOL and EOL patterns, which match certain boundaries. Often there is also a "non-line-separator" arbitrary character pattern that excludes line separator characters.

3 Extended Unicode Support: Level 2

Level 1 support works well in many circumstances. However, it does not handle more complex languages or extensions to the Unicode Standard very well. Particularly important cases are surrogates, canonical equivalence, word boundaries, grapheme boundaries, and loose matches. (For more information about boundary conditions, see The Unicode Standard, Section 5-15.)

Level 2 support matches much more what user expectations are for sequences of Unicode characters. It is still locale independent and easily implementable. However, the implementation may be slower when supporting Level 2, and some expressions may require Level 1 matches. Thus it is usually required to have some sort of syntax that will turn Level 2 support on and off.

3.1 Surrogates

The standard form of Unicode is UTF-16. It uses pairs of Unicode code units to express codepoints above FFFF16. (See Section 3.7 Surrogates, or for an overview see Forms of Unicode). While there are no surrogate characters in Unicode 3.0 (outside of private use characters), future versions of Unicode will contain them. This has two implications. First, while surrogate pairs can be used to identify code points above FFFF16, that mechanism is clumsy. It is much more useful to provide specific syntax for specifying Unicode code points, such as the following:

<character> := <simple_character>

UTF32_MARK := "v" 


[\v100000] Match surrogate private use character

The second implication is that, surrogate pairs (or their equivalents in other encoding forms) need to be handled internally as single values. In particular, [\u0000-\v10000] will match all the following sequence of code units (and more):

Code Point UTF-8 Code Units UTF-16 Code Units UTF-32 Code Units
7F 7F 007F 0000007F
80 C2 80 0080 00000080
7FF DF BF 07FF 000007FF
800 E0 A0 80 0800 08000000
10000 F0 90 80 80 D800 DC00 00010000

3.2 Canonical Equivalents

There are many instances where a character can be equivalently expressed by two different sequences of Unicode characters. For example, [ä] should match both "ä" and "a\u0308". (See Unicode Technical Report #15: Unicode Normalization and Section 2-5 and 3.9 for more information.) There are two main options for implementing this:

  1. Before (or during) processing, translate text (and pattern) into a normalized form. This is the simplest to implement, since there are available code libraries for doing normalization, or
  2. Expand the regular expression internally into a more generalized regular expression that takes canonical equivalence into account. For example, the expression [a-z,ä] can be internally turned into [a-z,ä] | (a \u0308). While this can be faster, it may also be substantially more difficult to generate expressions capturing all of the possible equivalent sequences.

Note: Even when text is in Normalization Form C, there may be combining characters in the text.

3.3 Locale-Independent Graphemes

One or more Unicode characters may make up what the user thinks of as a character. To avoid ambiguity with the computer use of the term character, this is called a grapheme. For example, "G" + acute-accent is a grapheme: it is thought of as a single character by users, yet is actually represented by two Unicode characters.

These locale-independent graphemes are not the same as locale-dependent graphemes, which are covered in Level 3, Locale-Dependent Graphemes. Locale-independent graphemes can be determined by the following grammar:

<grapheme> := <base_character>? <combiner>*
<combiner> := <combining_mark> 
            | <virama> <letter>
            | <hangul_medial>
            | <hangul_final>
            | <extras>

The only time a grapheme does not begin with a base character is when a combining mark is at the start of text, or preceded by a control or format character. The above characterization of grapheme does allow for some nonsensical sequences of characters, such as a <Latin A, Devenagari Virama, Greek Sigma>. A more complicated grammar could sift out these odd combinations, but it is generally not worth the effort, since:

The characters included in most of the terminals in the above expression can be derived from the Unicode character database properties, while some of them need to be explicitly listed:

<combining_mark> := [{M}]
<base_character> := [{ASSIGNED}-[{M},{C}]]
<letter> := [{L}]
<virama> := [\u094D...] // characters with canonical class = 9 in the UCD.
<hangul_medial> := [\u1160-\u11A7]
<hangul_final> := [\u11A8-\u11FF]
<extras> := [\uFF9E,\uFF9F]

In particular, if graphemes are handled properly, then [g-h] will match against the three character sequence "g\u0308\u0300".

3.3 Locale-Independent Words

The simple Level 1 support using simple <word_character> classes is only a very rough approximation of user word boundaries. A much better method takes into account more context than just a single pair of letters. A general algorithm can take care of character and word boundaries for most of the world's languages.

A very straightforward implementation of the Level 2 word-boundaries test is to break characters into three classes instead of two.

The <ignore> characters include both non-spacing marks as well as format characters such as the Right-Left Mark that should be ignored during word-break processing. Given this, then word-breaks occur only in the following two situations; otherwise there are no breaks. (The '÷' mark below shows a wordbreak position.)

An implementation generally only needs to looks at the character preceding the possible break position and the character following it. Only if there is an <ignore> character preceding the possible break position does it need to scan backwards. See Chapter 5, Implementation Guidelines for more information, and Annex B. Sample Word Boundary Code for sample code. Notice that this code will never break except on grapheme boundaries.

For example, the following shows a test case for correct word-break boundaries:

String: #\u031F h \u031F g \u0308 # \u031F \u0338 & \u031F g \u0308
Boundaries: #\u031F h \u031F g \u0308 #\u031F \u0338 & \u031F g \u0308

Note: Word-break boundaries and line-break boundaries are not generally the same; line breaking has a much more complex set of requirements to meet the typographic requirements of different languages. See UTR #14: Line Breaking Properties for more information. However, line breaks are not generally relevant to general regular expression engines.

Level 2 word-break support is not suited for a fine-grained approach to languages such as Chinese or Thai, which require information that is beyond the bounds of what a Level 2 algorithm can provide.

3.4 Locale-Independent Loose Matches

At Level 1, caseless matches do not need to handle cases where one character matches against two. Level 2 includes caseless matches where one character may match against two (or more) characters. For example, 00DF "ß" will match against the two characters "SS".

To correctly implement a caseless match and case conversions, see UTR #21: Case Mappings. For ease of implementation, a complete case folding file is supplied at CaseFolding.txt.

4 Locale-Sensitive Support: Level 3

All of the above deals with a locale-independent specification for a regular expression. However, a regular expression engine also may want to support locale-dependent specifications. This may be important when the regular expression engine is being used by less sophisticated users instead of programmers. For example, the order of Unicode characters may differ substantially from the order expected by users of a particular language. The regular expression engine has to decide, for example, whether the list [a-ä] means:

If both locale-dependent and locale-independent regular expressions are supported, then a number of different mechanism are affected. There are a two main alternatives for control of locale-dependent support:

Marking locales is generally specified by means of the common ISO 639 and 3166 tags, such as "en_US". For more information on these tags, see http://www.unicode.org/unicode/onlinedat/online.html.

Level 3 support may be considerably slower than Level 2, and some scripts may require either Level 1 or Level 2 matches instead. Thus it is usually required to have some sort of syntax that will turn Level 3 support on and off. Because locale-dependent regular expression patterns are usually quite specific to the locale, and will generally not work across different locales, the syntax should also specify the particular locale that the pattern was designed for.

4.1. Locale-Dependent Categories

Some of Unicode character categories, such as punctuation, may vary from language to language or from country to country, and so are not normative. For example, whether a curly quotation mark is opening or closing punctuation may vary. For those cases, the mapping of the categories to sets of characters will need to be locale dependent.

4.2 Locale-Dependent Graphemes

Locale-dependent graphemes may be somewhat different than the locale-independent graphemes discussed in Level 2. They are coordinated with the collation ordering for a given language in the following way. A collation ordering determines a collation grapheme, which is a sequence of characters that is treated as a unit by the ordering. For example, ch is a collation character for a traditional Spanish ordering. More specifically, a collation character is the longest sequence of characters that maps to sequence of one or more collation elements where the first collation element has a primary weight and subsequent elements do not.

The locale-dependent graphemes for a particular locale are the collation characters for the collation ordering for that locale. The determination of locale-dependent graphemes requires the regular expression engine to either draw upon the platform's collation data, or incorporate its own locale-dependent data for each supported locale.

See UTR #10: Unicode Collation Algorithm for more information about collation, and Annex C. Sample Collation Character Code for sample code.

4.3 Locale-Dependent Words

Semantic analysis may be required for correct word-break in languages that don't require spaces, such as Thai, Japanese, Chinese or Korean. This can require fairly sophisticated support if Level 3 word boundary detection is required, and usually requires drawing on platform OS services.

4.4 Locale-Dependent Loose Matches

In Level 1 and 2, we described caseless matches, but there are other interesting linguistic features that users may want to filter out. For example, V and W are considered equivalent in Swedish collations, and so [V] should match W in Swedish. In line with the UTR #10: Unicode Collation Algorithm, at the following four levels of equivalences are recommended:

If users are to have control over these equivalence classes, here is an example of how the sample syntax could be modified to account for this. The syntax for switching the strength or type of matching varies widely. Note that these tags switch behavior on and off in the middle of a regular expression; they do not match a character.

<item> := \c{PRIMARY}   // match primary only: set to disregard accents, case...
<item> := \c{SECONDARY} // match primary & secondary only: set to disregard case...
<item> := \c{TERTIARY}  // match primary, secondary, tertiary.
<item> := \c{EXACT}     // match all levels, normal state


[\c{SECONDARY}a-m] Match a-m, plus case variants A-M, plus compatibility variants

Basic information for these equivalence classes can be derived from the data tables referenced by UTR #10: Unicode Collation Algorithm.

4.5. Locale-Dependent Ranges

Locale-dependent character ranges will include locale-dependent graphemes, as discussed above. This broadens the set of graphemes — in traditional Spanish, for example, [b-d] would match against "ch".

Note: this is another reason why a category for all characters {ALL} is needed—it is possible for a locale's collation to not have [\u0000-\v10FFFF] encompass all characters.

Languages may also vary whether they consider lowercase below uppercase or the reverse. This can have some surprising results: [a-Z] may not match anything if Z < a in that locale!

5 Acknowledgments

Thanks to Karlsson Kent, Gurusamy Sarathy, Tom Watson and Kento Tamura for their feedback on the document.

Annex A. Character Blocks

The Block property from the Unicode Character Database (as described in Blocks.txt) can be a useful property for quickly describing a set of Unicode characters. It assigns a name to segments of the Unicode codepoint space; for example, [\u0370-\u03FF] is the Greek block.

However, block names must be used with discretion; they are very easy to misuse since they only supply a very coarse view of the Unicode character allocation. For example:

Shorthand Blocks
Latin   Basic Latin,  Latin-1 Supplement, Latin Extended-A, Latin Extended-B, Latin Extended Additional
Arabic   Arabic Presentation Forms-A, Arabic Presentation Forms-B
Hangul   Hangul Jamo, Hangul Compatibility Jamo, Hangul Syllables
Greek   Greek, Greek Extended
Diacritics   Combining Diacritical Marks, Combining Marks for Symbols, Combining Half Marks
CJK Compatibility   CJK Compatibility, CJK Compatibility Forms, Enclosed CJK Letters and Months, Small Form Variants
CJK   CJK Unified Ideographs, CJK Unified Ideographs Extension A, CJK Compatibility Ideographs
Yi   Yi Syllables, Yi Radicals
Bopomofo   Bopomofo, Bopomofo Extended
others IPA Extensions, Spacing Modifier Letters, Cyrillic, Armenian, Hebrew, Syriac, Thaana, Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, Malayalam, Sinhala, Thai, Lao, Tibetan, Myanmar, Georgian, Ethiopic, Cherokee, Unified Canadian Aboriginal Syllabics, Ogham, Runic, Khmer, Mongolian, CJK Radicals Supplement, Kangxi Radicals, Ideographic Description Characters, CJK Symbols and Punctuation, Hiragana, Katakana, Kanbun, Alphabetic Presentation Forms, Halfwidth and Fullwidth Forms,

General Punctuation, Superscripts and Subscripts, Currency Symbols, Letterlike Symbols, Number Forms, Arrows, Mathematical Operators, Miscellaneous Technical, Control Pictures, Optical Character Recognition, Enclosed Alphanumerics, Box Drawing, Block Elements, Geometric Shapes, Miscellaneous Symbols, Dingbats, Braille Patterns,

High Surrogates, High Private Use Surrogates, Low Surrogates, Private Use, Specials

Annex B: Sample Word Boundary Code

The following provides sample code for doing Level 2 word boundary detection. This code is meant to be illustrative, and has not been optimized. Although written in Java, it could be easily expressed in any programming language that allows access to the Unicode Character Database information.

 * Wordbreaks are where are two different word types on each side of
 * a caret position.
 * This is typically used in CTRL-arrow movement, Search by Whole Word,
 * double-click, and \b matches in regular expressions.
 * The following routine shows an example of how this is extended to
 * Unicode characters in general.<p>
 * Complications:
 * <ul><li>Non-spacing marks are treated as the type of
 * their base character. This means that:
 * you never break before an nsm; 
 * if you are after an nsm, you scan backward.
 * <li>Control (most) and format characters are ignored,
 * which means you treat them just like non-spacing marks.
 * <li>Note that this is very much simpler than Linebreak, which is described
 * in <a href="http://www.unicode.org/unicode/reports/tr14/">
 * UTR #14: Line Breaking Properties</a>.
 * </ul>
public static boolean isWordBreak(String s, int position) {
	int after = getWordType(s,position);
	int before = getWordType(s,--position);
	// handle non-spacing marks and others like them
	if (after == IGNORE) return false;
	while (before == IGNORE) {
	    before = getWordType(s,--position);
	// return true if different
	return (before != after);
 * Wordbreak type
public static int
	IGNORE = 0, // special class for ignored items
	LETTER = 1,
	OTHER = 2;
 * Get the word-type of a character.
public static int getWordType(String s, int position) {
	// for simplicity, treat end-of-string like a non-word character
	if (position < 0 || position >= s.length()) {
	    return OTHER;
	// Map from Unicode General Category to desired type.
	// If you don't want to break between numbers and non-numbers
	// then change the mapping here to be the same.
	char c = s.charAt(position);
	switch (Character.getType(c)) {
	    return OTHER;
        case Character.UPPERCASE_LETTER:
        case Character.LOWERCASE_LETTER:
        case Character.TITLECASE_LETTER:
        case Character.MODIFIER_LETTER:
        case Character.OTHER_LETTER:
        case Character.COMBINING_SPACING_MARK:
        case Character.LETTER_NUMBER:
        case Character.DECIMAL_DIGIT_NUMBER:
        case Character.OTHER_NUMBER:
	    return LETTER;
        case Character.FORMAT:
        case Character.NON_SPACING_MARK:
        case Character.ENCLOSING_MARK:
        return IGNORE;
        case Character.CONTROL:
	    // special case controls. Unicode doesn't assign them
	    // types because theoretically they could change by platform.
	    switch (c) {
	        case '\t':
	        case '\n':
	        case '\u000B':
	        case '\u000C':
	        case '\r':
	        return OTHER;
	        return IGNORE;

Annex C: Sample Collation Character Code

The following provides sample code for doing Level 3 collation character detection. This code is meant to be illustrative, and has not been optimized. Although written in Java, it could be easily expressed in any programming language that allows access to the Unicode Collation Algorithm mappings.

 * Return the end of a collation character.
 * @param s         the source string
 * @param start     the position in the string to search forward from
 * @param collator  the collator used to produce collation elements. This
 * can either be a custom-built one, or produced from the factory method
 * Collator.getInstance(someLocale).
 * @return          the end position of the collation character

static int getLocaleCharacterEnd(String s, int start, RuleBasedCollator collator) {
    int lastPosition = start;
    CollationElementIterator it 
      = collator.getCollationElementIterator(s.substring(start,s.length()));
    it.next(); // discard first collation element
    int primary;
    // accumulate characters until we get to a non-zero primary
    do {
        lastPosition = it.getOffset();
        int ce = it.next();
        if (ce == CollationElementIterator.NULLORDER) break;
        primary = CollationElementIterator.primaryOrder(ce);
    } while (primary == 0);
    return lastPosition;

Copyright © 2000 Unicode, Inc. All Rights Reserved. The Unicode Consortium makes no expressed or implied warranty of any kind, and assumes no liability for errors or omissions. No liability is assumed for incidental and consequential damages in connection with or arising out of the use of the information or programs contained or accompanying this technical report.

Unicode and the Unicode logo are trademarks of Unicode, Inc., and are registered in some jurisdictions.