You want to check whether a string is a legitimate XML name (a common syntactic construct). XML provides precise rules for the characters that can occur in a name, and reuses those rules for element, attribute, and entity names, processing instruction targets, and more. Names must be composed of a letter, underscore, or colon as the first character, followed by any combination of letters, digits, underscores, colons, hyphens, and periods. That’s actually an approximate description, but it’s pretty close. The exact list of permitted characters depends on the version of XML in use.
Alternatively, you might want to splice a pattern for matching valid names into other XML-handling regexes, when the extra precision warrants the added complexity.
Following are some examples of valid names:
thing_thing_2_:Российские-Вещьfantastic4:the.thing日本の物
Note that letters from non-Latin scripts are allowed, even including the ideographic characters in the last example. Likewise, any Unicode digit is allowed after the first character, not just the Arabic numerals 0–9.
For comparison, here are several examples of invalid names that should not be matched by the regex:
thing!thing with spaces.thing.with.a.dot.in.front-thingamajig2nd_thing
Like identifiers in many programming languages, there is a set of characters that can occur in an XML name, and a subset that can be used as the first character. Those character lists are dramatically different for XML 1.0 Fourth Edition (and earlier) and XML 1.1 and 1.0 Fifth Edition. Essentially, XML 1.1 names can use all the characters permitted by 1.0 Fourth Edition, plus almost a million more. However, the majority of the additional characters are nothing more than positions in the Unicode table. Most don’t have a character assigned to them yet, but are allowed for future compatibility as the Unicode character database expands.
For brevity’s sake, references to XML 1.0 in this recipe describe the first through fourth editions of XML 1.0. When we talk about XML 1.1 names, we’re also describing the XML 1.0 Fifth Edition rules. The fifth edition only became an official W3C Recommendation at the end of November 2008, nearly five years after XML 1.1.
Tip
Regexes in this recipe are shown with start and end of string
anchors (‹^⋯$›) that cause your
subject string to be matched in its entirety or not at all. If you
want to embed any of these patterns in a longer regular expression
that deals with matching, say, XML elements, make sure to remove the
anchors at the beginning and end of the patterns displayed here.
Anchors are explained in Recipe 2.5.
^[:_p{Ll}p{Lu}p{Lt}p{Lo}p{Nl}][:_-.p{L}p{M}p{Nd}p{Nl}]*$| Regex options: None (“^ and $ match at line breaks” must not be set) |
| Regex flavors: .NET, Java, XRegExp, PCRE, Perl, Ruby 1.9 |
PCRE must be compiled with UTF-8 support for the Unicode
properties (‹p{⋯}›) to work. In PHP,
turn on UTF-8 support with the /u pattern
modifier.
Unicode properties are not supported by JavaScript (without XRegExp), Python, or Ruby 1.8. The XML 1.1 names regex that comes next doesn’t rely on Unicode properties and therefore might be a good alternative if you’re using one of these programming languages. See the section of this recipe for details on why you might be better off using the XML 1.1-based solution anyway, even if your regex flavor supports Unicode properties.
Following are two versions of the same regular
expression, due to flavor differences. The second version uses
‹x{⋯}› instead of ‹u⋯› to specify Unicode code
points.
^[:_A-Za-zu00C0-u00D6u00D8-u00F6u00F8-u02FFu0370-u037Du037F-↵ u1FFFu200Cu200Du2070-u218Fu2C00-u2FEFu3001-uD7FFuF900-uFDCF↵ uFDF0-uFFFD][:_-.A-Za-z0-9u00B7u00C0-u00D6u00D8-u00F6u00F8-↵ u036Fu0370-u037Du037F-u1FFFu200Cu200Du203Fu2040u2070-u218F↵ u2C00-u2FEFu3001-uD7FFuF900-uFDCFuFDF0-uFFFD]*$
| Regex options: None (“^ and $ match at line breaks” must not be set) |
| Regex flavors: .NET, Java, JavaScript, Python, Ruby 1.9 |
^[:_A-Za-zx{C0}-x{D6}x{D8}-x{F6}x{F8}-x{2FF}x{370}-x{37D}x{37F}-↵
x{1FFF}x{200C}x{200D}x{2070}-x{218F}x{2C00}-x{2FEF}x{3001}-↵
x{D7FF}x{F900}-x{FDCF}x{FDF0}-x{FFFD}][:_-.A-Za-z0-9x{B7}x{C0}-↵
x{D6}x{D8}-x{F6}x{F8}-x{36F}x{370}-x{37D}x{37F}-x{1FFF}x{200C}↵
x{200D}x{203F}x{2040}x{2070}-x{218F}x{2C00}-x{2FEF}x{3001}-↵
x{D7FF}x{F900}-x{FDCF}x{FDF0}-x{FFFD}]*$| Regex options: None (“^ and $ match at line breaks” must not be set) |
| Regex flavors: Java 7, PCRE, Perl |
PCRE must be compiled with UTF-8 support for the ‹x{⋯}› metasequences to work with values
greater than FF hexadecimal. In PHP, turn on UTF-8 support with the
/u pattern modifier.
Ruby 1.8 does not support Unicode regular expressions at all, but see the section of this recipe for a possible alternative solution that is less precise.
Although we’ve claimed these regular expressions follow the XML 1.1 name rules exactly, that’s actually only true for characters up to 16 bits wide (positions 0x0000 through 0xFFFF, which composes Unicode’s plane 0 or Basic Multilingual Plane). XML 1.1 additionally allows the 917,503 code points between positions 0x10000 and 0xEFFFF (Unicode planes 1–14) to occur after the initial name character. However, only PCRE, Perl, Python, and Ruby 1.9 are even capable of referencing code points beyond 0xFFFF, and you are unlikely to encounter any in real-world XML names (for one thing, most of the positions in this range have not been assigned an actual character). If you need to add support for these extra code points, add one of the following ranges at the end of the second character class:
- Java 7, PCRE, Perl
‹
x{10000}-x{EFFFF}›- Python
‹
U00010000-U000EFFFF›- Ruby 1.9
‹
u{10000}-u{EFFFF}›
Even without adding this massive range at the end, the XML 1.1 name character list we’ve just shown is much more permissive than XML 1.0.
Python’s support for the syntax with ‹U›
followed by eight hexadecimal digits comes from its syntax for literal
strings. See Recipe 2.7 for important details
about this.
Since many of the regular expressions in this chapter deal with matching XML elements, this recipe largely serves to provide a fuller discussion of the patterns that can be used when you want to get very specific about how tag and attribute names are matched. Elsewhere, we mostly stick to simpler patterns that are less precise, in the interest of readability and efficiency.
So let’s dig a little deeper into the rules behind these patterns.
The XML 1.0 specification uses a whitelist approach for its name
rules, and explicitly lists all the characters that are allowed. The
first character in a name can be a colon (:), underscore (_), or approximately any character in the
following Unicode categories:
Lowercase Letter (Ll)
Uppercase Letter (Lu)
Titlecase Letter (Lt)
Other Letter (Lo)
Letter Number (Nl)
After the initial character, hyphen (-), period (.), and any character in the following
categories are allowed in addition to the characters already
mentioned:
Mark (M), which combines the subcategories Nonspacing Mark (Mn), Spacing Mark (Mc), and Enclosing Mark (Me)
Modifier Letter (Lm)
Decimal Number (Nd)
These rules lead us to the regular expression shown in the section of this recipe. Here it is again, this time in free-spacing mode:
^ # Start of string
[:_p{Ll}p{Lu}p{Lt}p{Lo}p{Nl}] # Initial name character
[:_-.p{L}p{M}p{Nd}p{Nl}]* # Subsequent name characters (optional)
$ # End of string| Regex options: Free-spacing (“^ and $ match at line breaks” must not be set) |
| Regex flavors: .NET, Java, XRegExp, PCRE, Perl, Ruby 1.9 |
Again, PCRE must be compiled with UTF-8 support. In PHP, turn on
UTF-8 support with the /u pattern
modifier.
Notice that in the second character class, all of the Letter
subcategories (Ll, Lu, Lt, Lo, and Lm) have been combined into their
base category using ‹p{L}›.
Earlier, we noted that the rules described here are approximate. There are a couple of reasons for that. First, the XML 1.0 specification (remember that we’re not talking about the fifth edition and later here) lists a number of exceptions to these allowed characters. Second, the XML 1.0 character lists were explicitly derived from Unicode 2.0, which was released back in 1996. Later versions of the Unicode standard have added support for an assortment of new scripts whose characters are not permitted by the XML 1.0 rules.
Decoupling the regex from whatever Unicode version your regex engine uses so you can restrict matches to Unicode 2.0 characters would turn this pattern into a page-long monstrosity filled with hundreds of ranges and code points. If you really want to create this monster, refer to XML 1.0, Fourth Edition (http://www.w3.org/TR/2006/REC-xml-20060816/) section 2.3, “Common Syntactic Constructs,” and Appendix B, “Character Classes.”
Following are several flavor-specific ways to shorten the regex we’ve already seen.
Perl and PCRE let you combine the Lowercase Letter (Ll),
Uppercase Letter (Lu), and Titlecase Letter (Lt) subcategories into
the special Cased Letter (L&) category. These regex flavors also
let you omit the curly brackets in the ‹p{⋯}› escape sequence if only one letter
is used within. We’ve taken advantage of this in the following regex
by using ‹pLpM›
instead of ‹p{L}p{M}›:
^[:_p{L&}p{Lo}p{Nl}][:_-.pLpMp{Nd}p{Nl}]*$| Regex options: None (“^ and $ match at line breaks” must not be set) |
| Regex flavors: PCRE, Perl |
.NET supports character class subtraction, which is used in the first character class here to subtract the Lm subcategory from L, rather than explicitly listing all the other Letter subcategories:
^[:_p{L}p{Nl}-[p{Lm}]][:_-.p{L}p{M}p{Nd}p{Nl}]*$| Regex options: None (“^ and $ match at line breaks” must not be set) |
| Regex flavor: .NET |
Java, like PCRE and Perl, lets you omit the curly brackets around one-letter Unicode categories. The following regex also takes advantage of Java’s more complicated version of character class subtraction (implemented via intersection with a negated class) to subtract the Lm subcategory from L:
^[:_pLp{Nl}&&[^p{Lm}]][:_-.pLpMp{Nd}p{Nl}]*$| Regex options: None (“^ and $ match at line breaks” must not be set) |
| Regex flavor: Java |
JavaScript (without XRegExp), Python, and Ruby 1.8 don’t support Unicode categories at all. XRegExp and Ruby 1.9 don’t have the fancy features just described, but they do support the more portable version of this regex shown in the section of this recipe.
XML 1.0 made the mistake of explicitly tying itself to Unicode 2.0. Later versions of the Unicode standard have added support for many more characters, some of which are from scripts that weren’t previously accounted for at all (e.g., Cherokee, Ethiopic, and Mongolian). Since XML wants to be regarded as a universal format, it has tried to fix this problem with XML 1.1 and 1.0 Fifth Edition. These later versions switch from a whitelist to a blacklist approach for name characters in order to support not only the characters added since Unicode 2.0, but also those that may be added in the future.
This new strategy of allowing anything that isn’t explicitly forbidden improves future compatibility, and it also makes it easier and less verbose to precisely follow the rules. That’s why the XML 1.1 name regexes are labeled as being exact, whereas the XML 1.0 regex is approximate.
In some of this chapter’s recipes (e.g., Recipe 9.1), the pattern segments that deal with XML names employ next to no restrictions or disallow foreign scripts and other characters that are in fact perfectly valid. This is done to keep things simple. However, if you want to allow foreign scripts while still providing a base level of restrictions (and you don’t need the more precise name validation of earlier regexes in this recipe), these next regexes might do the trick.
Tip
We’ve left the start- and end-of-string anchors off of these regexes since they’re not meant to be used on their own, but rather as parts of longer patterns.
This first regex simply avoids matching the characters used as separators and delimiters within XML tags, and additionally prevents matching a digit as the first character:
[^ds"'/<=>][^s"'/<=>]*
| Regex options: None |
| Regex flavors: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby |
Following is another, even shorter way to accomplish the same
thing. Instead of using two separate character classes, it uses negative
lookahead to forbid a digit as the initial character. This ban applies
to the first matched character only, even though the ‹+› quantifier after the character
class lets the regex match an unlimited number of characters:
(?!d)[^s"'/<=>]+
| Regex options: None |
| Regex flavors: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby |
John Cowan, one of the editors of the XML 1.1 specification, explains which characters are forbidden in XML 1.1 names and why in a blog post at http://recycledknowledge.blogspot.com/2008/02/which-characters-are-excluded-in-xml.html.
The document “Background to Changes in XML 1.0, 5th Edition” at http://www.w3.org/XML/2008/02/xml10_5th_edition_background.html discusses the rationale for backporting XML 1.1’s name rules to XML 1.0, Fifth Edition.
Recipe 9.1 shows how to match XML-style tags while balancing trade-offs including tolerance for invalid markup.
Techniques used in the regular expressions in this recipe are discussed in Chapter 2. Recipe 2.3 explains character classes. Recipe 2.5 explains anchors. Recipe 2.7 explains how to match Unicode characters. Recipe 2.12 explains repetition.