Unicode® Standard Annex #44

Unicode Character Database

Version	Unicode 8.0.0
Editors	Mark Davis (markdavis@google.com), Laurențiu Iancu (liancu@unicode.org) and Ken Whistler (ken@unicode.org)
Date	2015-06-01
This Version	http://www.unicode.org/reports/tr44/tr44-16.html
Previous Version	http://www.unicode.org/reports/tr44/tr44-14.html
Latest Version	http://www.unicode.org/reports/tr44/
Latest Proposed Update	http://www.unicode.org/reports/tr44/proposed.html
Revision	16

Summary

This annex provides the core documentation for the Unicode Character Database (UCD). It describes the layout and organization of the Unicode Character Database and how it specifies the formal definitions of the Unicode Character Properties.

Status

This document has been reviewed by Unicode members and other interested parties, and has been approved for publication by the Unicode Consortium. This is a stable document and may be used as reference material or cited as a normative reference by other specifications.

A Unicode Standard Annex (UAX) forms an integral part of the Unicode Standard, but is published online as a separate document. The Unicode Standard may require conformance to normative content in a Unicode Standard Annex, if so specified in the Conformance chapter of that version of the Unicode Standard. The version number of a UAX document corresponds to the version of the Unicode Standard of which it forms a part.

Please submit corrigenda and other comments with the online reporting form [Feedback]. Related information that is useful in understanding this annex is found in Unicode Standard Annex #41, “Common References for Unicode Standard Annexes.” For the latest version of the Unicode Standard, see [Unicode]. For a list of current Unicode Technical Reports, see [Reports]. For more information about versions of the Unicode Standard, see [Versions]. For any errata which may apply to this annex, see [Errata].

Contents

• 1 Introduction
• 2 Conformance
  • 2.1 Simple and Derived Properties
  • 2.2 Use of Default Values
  • 2.3 Stability of Releases
• 3 Documentation
  • 3.1 Character Properties in the Standard
  • 3.2 The Character Property Model
  • 3.3 NamesList.html
  • 3.4 StandardizedVariants.html
  • 3.5 Unihan and UAX #38
  • 3.6 U-Source Ideographs and UAX #45
  • 3.7 Data File Comments
  • 3.8 Obsolete Documentation Files
• 4 UCD Files
  • 4.1 Directory Structure
  • 4.2 File Format Conventions
  • 4.3 File List
  • 4.4 Zipped Files
  • 4.5 UCD in XML
• 5 Properties
  • 5.1 Property Index
  • 5.2 About the Property Table
  • 5.3 Property Definitions
  • 5.4 Derived Extracted Properties
  • 5.5 Contributory Properties
  • 5.6 Case and Case Mapping
  • 5.7 Property Value Lists
  • 5.8 Property and Property Value Aliases
  • 5.9 Matching Rules
  • 5.10 Invariants
  • 5.11 Validation
  • 5.12 Deprecation
• 6 Test Files
  • 6.1 NormalizationTest.txt
  • 6.2 Segmentation Test Files and Documentation
  • 6.3 Bidirectional Test Files
• 7 UCD Change History
• Acknowledgments
• References
• Modifications

---

Note: the information in this annex is not intended as an exhaustive description of the use and interpretation of Unicode character properties and behavior. It must be used in conjunction with the data in the other files in the Unicode Character Database, and relies on the notation and definitions supplied in The Unicode Standard. All chapter references are to Version 8.0.0 of the standard unless otherwise indicated.

1 Introduction

The Unicode Standard is far more than a simple encoding of characters. The standard also associates a rich set of semantics with each encoded character—properties that are required for interoperability and correct behavior in implementations, as well as for Unicode conformance. These semantics are cataloged in the Unicode Character Database (UCD), a collection of data files which contain the Unicode character code points and character names. The data files define the Unicode character properties and mappings between Unicode characters (such as case mappings).

This annex describes the UCD and provides a guide to the various documentation files associated with it. Additional information about character properties and their use is contained in the Unicode Standard and its annexes. In particular, implementers should familiarize themselves with the formal definitions and conformance requirements for properties detailed in Section 3.5, Properties in [Unicode] and with the material in Chapter 4, Character Properties in [Unicode].

The latest version of the UCD is always located on the Unicode website at:

http://www.unicode.org/Public/UCD/latest/

The specific files for the UCD associated with this version of the Unicode Standard (8.0.0) are located at:

http://www.unicode.org/Public/8.0.0/

Stable, archived versions of the UCD associated with all earlier versions of the Unicode Standard can be accessed from:

http://www.unicode.org/ucd/

For a description of the changes in the UCD for this version and earlier versions, see the UCD Change History.

2 Conformance

The Unicode Character Database is an integral part of the Unicode Standard.

The UCD contains normative property and mapping information required for implementation of various Unicode algorithms such as the Unicode Bidirectional Algorithm, Unicode Normalization, and Unicode Casefolding. The data files also contain additional informative and provisional character property information.

Each specification of a Unicode algorithm, whether specified in the text of [Unicode] or in one of the Unicode Standard Annexes, designates which data file(s) in the UCD are needed to provide normative property information required by that algorithm.

For information on the meaning and application of the terms, normative, informative, and provisional, see Section 3.5, Properties in [Unicode].

For information about the applicable terms of use for the UCD, see the Unicode Terms of Use.

2.1 Simple and Derived Properties

Some character properties in the UCD are simple properties. This status has no bearing on whether or not the properties are normative, but merely indicates that their values are not derived from some combination of other properties.

Other character properties are derived. This means that their values are derived by rule from some other combination of properties. Generally such rules are stated as set operations, and may or may not include explicit exception lists for individual characters.

Certain simple properties are defined merely to make the statement of the rule defining a derived property more compact or general. Such properties are known as contributory properties. Sometimes these contributory properties are defined to encapsulate the messiness inherent in exception lists. At other times, a contributory property may be defined to help stabilize the definition of an important derived property which is subject to stability guarantees.

Derived character properties are not considered second-class citizens among Unicode character properties. They are defined to make implementation of important algorithms easier to state. Included among the first-class derived properties important for such implementations are: Uppercase, Lowercase, XID_Start, XID_Continue, Math, and Default_Ignorable_Code_Point, all defined in DerivedCoreProperties.txt, as well as derived properties for the optimization of normalization, defined in DerivedNormalizationProps.txt.

Implementations should simply use the derived properties, and should not try to rederive them from lists of simple properties and collections of rules, because of the chances for error and divergence when doing so.

Definitions of property derivations are provided for information only, typically in comment fields in the data files. Such definitions may be refactored, refined, or corrected over time. These definitions are presented in a modified set notation, expressed as set additions and/or subtractions of various other property values. For example:

# Derived Property: ID_Start
#  Characters that can start an identifier.
#  Generated from:
#      Lu + Ll + Lt + Lm + Lo + Nl
#    + Other_ID_Start
#    - Pattern_Syntax
#    - Pattern_White_Space

When interpreting definitions of derived properties of this sort, keep in mind that set subtraction is not a commutative operation. Thus "Lo + Lm - Pattern_Syntax" defines a different set than "Lo - Pattern_Syntax + Lm". The order of property set operations stated in the definitions affects the composition of the derived set.

If there are any cases of mismatches between the definition of a derived property as listed in DerivedCoreProperties.txt or similar data files in the UCD, and the definition of a derived property as a set definition rule, the explicit listing in the data file should always be taken as the normative definition of the property. As described in Stability of Releases the property listing in the data files for any given version of the standard will never change for that version.

2.2 Use of Default Values

Unicode character properties have default values. Default values are the value or values that a character property takes for an unassigned code point, or in some instances, for designated subranges of code points, whether assigned or unassigned. For example, the default value of a binary Unicode character property is always "N".

For the formal discussion of default values, see D26 in Section 3.5, Properties in [Unicode]. For conventions related to default values in various data files of the UCD and for documentation regarding the particular default values of individual Unicode character properties, see Default Values.

2.3 Stability of Releases

Just as for the Unicode Standard as a whole, each version of the UCD, once published, is absolutely stable and will never change. Each released version is archived in a directory on the Unicode website, with a directory number associated with that version. URLs pointing to that version's directory are also stable and will be maintained in perpetuity.

Any errors discovered for a released version of the UCD are noted in [Errata], and if appropriate will be corrected in a subsequent version of the UCD.

Stability guarantees constraining how Unicode character properties can (or cannot) change between releases of the UCD are documented in the Unicode Consortium Stability Policies [Stability].

2.3.1 Changes to Properties Between Releases

Updates to character properties in the Unicode Character Database may be required for any of three reasons:

1. To cover new characters added to the standard
2. To add new character properties to the standard
3. To change the assigned values for a property for some characters already in the standard

While the Unicode Consortium endeavors to keep the values of all character properties as stable as possible between versions, occasionally circumstances may arise which require changing them. In particular, as less well-documented scripts, such as those for minority languages, or historic scripts are added to the standard, the exact character properties and behavior may not fully be known when the script is first encoded. The properties for some of these characters may change as further information becomes available or as implementations turn up problems in the initial property assignments. As far as possible, any readjustment of property values based on growing implementation experience is made to be compatible with established practice.

All changes to normative or informative property values, to the status or type of a property, or to property or property value aliases, must be approved by an explicit decision taken by the Unicode Technical Committee. Changes to provisional property values are subject to less stringent oversight.

Occasionally, a character property value is changed to prevent incorrect generalizations about a character's use based on its nominal property values. For example, U+200B ZERO WIDTH SPACE was originally classified as a space character (General_Category=Zs), but it was reclassified as a Format character (General_Category=Cf) to clearly distinguish it from space characters in its function as a format control for line breaking.

There is no guarantee that a particular value for an enumerated property will actually have characters associated with it. Also, because of changes in property value assignments between versions of the standard, a property value that once had characters associated with it may later have none. Such conditions and changes are rare, but implementations must not assume that all property values are associated with non-null sets of characters. For example, currently the special Script property value Katakana_Or_Hiragana has no characters associated with it.

2.3.2 Obsolete Properties

In some instances an entire property may become obsolete. For example, the ISO_Comment property was once used to keep track of annotations for characters used in the production of name lists for ISO/IEC 10646 code charts. As of Unicode 5.2.0 that property became obsolete, and its value is now defaulted to the null string for all Unicode code points.

An obsolete property is never removed from the UCD.

2.3.3 Deprecated Properties

Occasionally an obsolete property may also be formally deprecated. This is an indication that the property is no longer recommended for use, perhaps because its original intent has been replaced by another property or because its specification was somehow defective. See also the general discussion of Deprecation.

A deprecated property is never removed from the UCD.

Table 1 lists the properties that are formally deprecated as of this version of the Unicode Standard.

Table 1. Deprecated Properties

 

2.3.4 Stabilized Properties

Another possibility is that an obsolete property may be declared to be stabilized. Such a determination does not indicate that the property should or should not be used; instead it is a declaration that the UTC (Unicode Technical Committee) will no longer actively maintain the property or extend it for newly encoded characters. The property values of a stabilized property are frozen as of a particular release of the standard.

A stabilized property is never removed from the UCD.

Table 2 lists the properties that are formally stabilized as of this version of the Unicode Standard.

Table 2. Stabilized Properties

 

3 Documentation

This annex provides the core documentation for the UCD, but additional information about character properties is available in other parts of the standard and in additional documentation files contained within the UCD.

3.1 Character Properties in the Standard

The formal definitions related to character properties used by the Unicode Standard are documented in Section 3.5, Properties in [Unicode]. Understanding those definitions and related terminology is essential to the appropriate use of Unicode character properties.

See Section 4.1, Unicode Character Database, in [Unicode] for a general discussion of the UCD and its use in defining properties. The rest of Chapter 4 provides important explanations regarding the meaning and use of various normative character properties.

3.2 The Character Property Model

For a general discussion of the property model which underlies the definitions associated with the UCD, see Unicode Technical Report #23, "The Unicode Character Property Model" [UTR23]. That technical report is informative, but over the years various content from it has been incorporated into normative portions of the Unicode Standard, particularly for the definitions in Chapter 3.

UTR #23 also discusses string functions and their relation to character properties.

3.3 NamesList.html

NamesList.html formally describes the format of the NamesList.txt data file in BNF. That data file is used to drive the printing of the Unicode code charts and names list. See also Section 24.1, Character Names List, in [Unicode] for a detailed discussion of the conventions used in the Unicode names list as formatted for printing.

3.4 StandardizedVariants.html

StandardizedVariants.html documents standardized variants, showing a representative glyph for each. It is closely tied to the data file, StandardizedVariants.txt, which defines those sequences normatively.

3.5 Unihan and UAX #38

Unicode Standard Annex #38, "Unicode Han Database (Unihan)" [UAX38] describes the format and content of the Unihan Database, which collects together all property information for CJK Unified Ideographs. That annex also specifies in detail which of the Unihan character properties are normative, informative, or provisional.

The Unihan Database contains extensive and detailed mapping information for CJK Unified Ideographs encoded in the Unicode Standard, but it is aimed only at those ideographs, not at other characters used in the East Asian context in general. In contrast, East Asian legacy character sets, including important commercial and national character set standards, contain many non-CJK characters. As a result, the Unihan Database must be supplemented from other sources to establish mapping tables for those character sets.

The majority of the content of the Unihan Database is released for each version of the Unicode Standard as a collection of Unihan data files in the UCD. Because of their large size, these data files are released only as a zipped file, Unihan.zip. The details of the particular data files in Unihan.zip and the CJK properties each one contains are provided in [UAX38]. For versions of the UCD prior to Version 5.2.0, all of the CJK properties were listed together in a very large, single file, Unihan.txt.

3.6 U-Source Ideographs and UAX #45

Unicode Standard Annex #45, "Unicode Han Database (Unihan)" [UAX45] describes the format of USourceData.txt, which lists all of the information for U-Source ideographs.

3.7 Data File Comments

In addition to the specific documentation files for the UCD, individual data files often contain extensive header comments describing their content and any special conventions used in the data.

In some instances, individual property definition sections also contain comments with information about how the property may be derived. Such comments are informative; while they are intended to convey the intent of the derivation, in case of any mismatch between a statement of a derivation in a comment field and the actual listing of the derived property, the list is considered to be definitive. See Simple and Derived Properties.

3.8 Obsolete Documentation Files

UCD.html was formerly the primary documentation file for the UCD. As of Version 5.2.0, its content has been wholly incorporated into this document.

Unihan.html was formerly the primary documentation file for the Unihan Database. As of Version 5.1.0, its content has been wholly incorporated into [UAX38].

Versions of the Unicode Standard prior to Version 4.0.0 contained small, focused documentation files, UnicodeCharacterDatabase.html, PropList.html, and DerivedProperties.html, which were later consolidated into UCD.html.

4 UCD Files

The heart of the UCD consists of the data files themselves. This section describes the directory structure for the UCD, the format conventions for the data files, and provides documentation for data files not documented elsewhere in this annex.

4.1 Directory Structure

Each version of the UCD is released in a separate, numbered directory under the Public directory on the Unicode website. The content of that directory is complete for that release. It is also stable—once released, it will be archived permanently in that directory, unchanged, at a stable URL.

The specific files for the UCD associated with this version of the Unicode Standard (8.0.0) are located at:

http://www.unicode.org/Public/8.0.0/

The latest released version of the UCD is always accessible via the following stable URL:

http://www.unicode.org/Public/UCD/latest/

Zipped copies of the latest released version of the UCD are always accessible via the following stable URL:

http://www.unicode.org/Public/zipped/latest/

Prior to Version 6.3.0, access to the latest released version of the UCD was via the following stable URL:

http://www.unicode.org/Public/UNIDATA/

That "UNIDATA" URL will be maintained, but is no longer recommended, because it points to the ucd subdirectory of the latest release, rather than to the parent directory for the release. The "UNIDATA" naming convention is also very old, and does not follow the directory naming conventions currently used for other data releases in the Public directory on the Unicode website.

4.1.1 UCD Files Proper

The UCD proper is located in the ucd subdirectory of the numbered version directory. That directory contains all of the documentation files and most of the data files for the UCD, including some data files for derived properties.

Although all UCD data files are version-specific for a release and most contain internal date and version stamps, the file names of the released data files do not differ from version to version. When linking to a version-specific data file, the version will be indicated by the version number of the directory for the release.

All files for derived extracted properties are in the extracted subdirectory of the ucd subdirectory. See Derived Extracted Properties for documentation regarding those data files and their content.

A number of auxiliary properties are specified in files in the auxiliary subdirectory of the ucd subdirectory. It contains data files specifying properties associated with Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29] and with Unicode Standard Annex #14, "Unicode Line Breaking Algorithm" [UAX14], as well as test data for those algorithms. See Segmentation Test Files and Documentation for more information about the test data.

4.1.2 UCD XML Files

The XML version of the UCD is located in the ucdxml subdirectory of the numbered version directory. See the UCD in XML for more details.

4.1.3 Charts

The code charts specific to a version of Unicode are archived as a single large pdf file in the charts subdirectory of the numbered version directory. See the readme.txt in that subdirectory and the general web page explaining the Unicode Code Charts for more details.

4.1.4 Beta Review Considerations

Prior to the formal release for any particular version of the UCD, a beta review is conducted. The beta review files are located in the same directory that is later used for the released UCD, but during the beta review period, the subdirectory structure differs somewhat and may contain temporary files, including documentation of diffs between deltas for the beta review. Also, during the beta review, all data file names are suffixed with version numbers and delta numbers. So a typical file name during beta review may be "PropList-5.2.0d13.txt" instead of the finally released "PropList.txt".

Notices contained in a ReadMe.txt file in the UCD directory during the beta review period also make it clear that that directory contains preliminary material under review, rather than a final, stable release.

4.1.5 File Directory Differences for Early Releases

The UCD in XML was introduced in Version 5.1.0, so UCD directories prior to that do not contain the ucdxml subdirectory.

UCD directories prior to Version 4.1.0 do not contain the auxiliary subdirectory.

UCD directories prior to Version 3.2.0 do not contain the extracted subdirectory.

The general structure of the file directory for a released version of the UCD described above applies to Versions 4.1.0 and later. Prior to Version 4.1.0, versions of the UCD were not self-contained, complete sets of data files for that version, but instead only contained any new data files or any data files which had changed since the prior release.

Because of this, the property files for a given version prior to Version 4.1.0 can be spread over several directories. Consult the component listings at Enumerated Versions to find out which files in which directories comprise a complete set of data files for that version.

The directory naming conventions and the file naming conventions also differed prior to Version 4.1.0. So, for example, Version 4.0.0 of the UCD is contained in a directory named 4.0-Update, and Version 4.0.1 of the UCD in a directory named 4.0-Update1. Furthermore, for these earlier versions, the data file names do contain explicit version numbers.

4.2 File Format Conventions

Files in the UCD use the format conventions described in this section, unless otherwise specified.

4.2.1 Data Fields

• Each line of data consists of fields separated by semicolons. The fields are numbered starting with zero.
• The first field (0) of each line in the Unicode Character Database files represents a code point or range. The remaining fields (1..n) are properties associated with that code point.
• Leading and trailing spaces within a field are not significant. However, no leading or trailing spaces are allowed in any field of UnicodeData.txt. For legacy reasons, no spaces are allowed before or after the semicolon in LineBreak.txt and in EastAsianWidth.txt.
• The Unihan data files in the UCD have a separate format, using tab characters instead of semicolons to separate fields. See [UAX38] for the detailed specification of the format of the Unihan data files.

4.2.2 Code Points and Sequences

• Code points are expressed as hexadecimal numbers with four to six digits. They are written without the "U+" prefix in all data files except the Unihan data files. The Unihan data files use the "U+" prefix for all Unicode code points, to distinguish them from other decimal and hexadecimal numerical references occurring in their data fields.
• When a data field contains a sequence of code points, spaces separate the code points.

4.2.3 Code Point Ranges

• A range of code points is specified by the form "X..Y".
• Each code point in a range has the associated property value specified on a data file. For example (from Blocks.txt):

  0000..007F; Basic Latin
  0080..00FF; Latin-1 Supplement
        

• For backward compatibility, ranges in the file UnicodeData.txt are specified by entries for the start and end characters of the range, rather than by the form "X..Y". The start character is indicated by a range identifier, followed by a comma and the string "First", in angle brackets. This entry takes the place of a regular character name in field 1 for that line. The end character is indicated on the next line with the same range identifier, followed by a comma and the string "Last", in angle brackets:

  4E00;<CJK Ideograph, First>;Lo;0;L;;;;;N;;;;;
  9FD5;<CJK Ideograph, Last>;Lo;0;L;;;;;N;;;;;
        

  For character ranges using this convention, the names of all characters in the range are algorithmically derivable. See Section 4.8, Name in [Unicode] for more information on derivation of character names for such ranges.

4.2.4 Comments

• U+0023 NUMBER SIGN ("#") is used to indicate comments: all characters from the number sign to the end of the line are considered part of the comment, and are disregarded when parsing data.
• In many files, the comments on data lines use a common format, as illustrated here (from Scripts.txt):

  09B2          ; Bengali # Lo       BENGALI LETTER LA

• The first part of a comment using this common format is the General_Category value, provided for information. This is followed by the character name for the code point in the first field (0).
• The printing of the General_Category value is suppressed in instances where it would be redundant, as for DerivedGeneralCategory.txt, in which the value of the property value in the data field is already the General_Category value.
• The symbol "L&" indicates characters of General_Category Lu, Ll, or Lt (uppercase, lowercase, or titlecase letter). For example:

  0386          ; Greek # L&       GREEK CAPITAL LETTER ALPHA WITH TONOS

  L& as used in these comments is an alias for the derived LC value (cased letter) for the General_Category property, as documented in PropertyValueAliases.txt.
• When the data line contains a range of code points, this common format for a comment also indicates a range of character names, separated by "..", as illustrated here (from DerivedNumericType.txt):

  00BC..00BE    ; Numeric # No   [3] VULGAR FRACTION ONE QUARTER..VULGAR FRACTION THREE QUARTERS

• Normally, consecutive characters with the same property value would be represented by a single code point range. In data files using this comment convention, such ranges are subdivided so that all characters in a range also have the same General_Category value (or LC). While this convention results in more ranges than are strictly necessary, it makes the contents of the ranges clearer.
• When a code point range occurs, the number of items in the range is included in the comment (in square brackets), immediately following the General_Category value.
• The comments are purely informational, and may change format or be omitted in the future. They should not be parsed for content.

4.2.5 Code Point Labels

• Surrogate code points, private-use characters, control codes, noncharacters, and unassigned code points have no names. When such code points are listed in the data files, for example to list their General_Category values, the comments use code point labels instead of character names. For example (from DerivedCoreProperties.txt):

  2065          ; Default_Ignorable_Code_Point # Cn       <reserved-2065>

• Code point labels use one of the tags as documented in Section 4.8, Name in [Unicode] and as shown in Table 3, followed by "-" and the code point expressed in hexadecimal. The entire label is then enclosed in angle brackets.

Table 3. Code Point Label Tags

 

4.2.6 Multiple Properties in One Data File

• When a file contains the specification for multiple properties, the second field specifies the name of the property and the third field specifies the property value. For example (from DerivedNormalizationProps.txt):

  03D2  ; FC_NFKC; 03C5           # L&  GREEK UPSILON WITH HOOK SYMBOL
  03D3  ; FC_NFKC; 03CD           # L&  GREEK UPSILON WITH ACUTE AND HOOK SYMBOL
        

4.2.7 Binary Property Values

• For binary properties, the second field specifies the name of the applicable property, with the implied value of the property being "True". Only the ranges of characters with the binary property value of "Y" (= True) are listed. For example (from PropList.txt):

  1680       ; White_Space # Zs      OGHAM SPACE MARK
  2000..200A ; White_Space # Zs [11] EN QUAD..HAIR SPACE
        

4.2.8 Multiple Values for Properties

• When a data file defines a property which may take multiple values for a single code point, the multiple values are expressed in a space-delimited list. For example (from ScriptExtensions.txt):

  0640          ; Arab Mand Mani Phlp Syrc # Lm       ARABIC TATWEEL
        

• In some cases—but not all—the order of multiple elements in a space-delimited list may be significant. When the order of multiple elements is significant, it is documented along with the property itself. For example (from Unihan_Readings.txt), for the tag kMandarin, when there are two values for a code point, the first value is used to indicate a preferred pronunciation for zh-Hans (CN) and the second a preferred pronunciation for zh-Hant (TW).
• For further discussion, see Section 5.7.6 Properties Whose Values Are Sets of Values.

4.2.9 Default Values

• Entries for a code point may be omitted in a data file if the code point has a default value for the property in question.
• For string properties, including the definition of foldings, the default value is the code point of the character itself.
• For miscellaneous properties which take strings as values, such as the Unicode Name property, the default value is a null string.
• For binary properties, the default value is always "N" (= False) and is always omitted.
• For enumerated and catalog properties, the default value is listed in a comment. For example (from Scripts.txt):

  #  All code points not explicitly listed for Script
  #  have the value Unknown (Zzzz).
        

• A few properties of the enumerated type have multiple default values. In those cases, comments in the file explain the code point ranges for applicable values. See also Table 4.
• Default values are also listed in specially-formatted comment lines, using the keyword "@missing". Parsers which extract and process these lines can algorithmically determine the default values for all code points. See @missing Conventions for details about the syntax and use of these lines.
• Because of the legacy format constraints for UnicodeData.txt, that file contains no specific information about default values for properties. The default values for fields in UnicodeData.txt are documented in Table 4 below if they cannot be derived from the general rules about default values for properties.
• The file ArabicShaping.txt is also exceptional, because it omits the listing of many characters whose property value (jt=T) can be derived by rule. Adding an "@missing" line to that file would result in the wrong interpretation of Joining_Type values for omitted characters. The full explicit listing of Joining_Type values and the correct "@missing" line for the default Joining_Type value (jt=U) can be found in the file DerivedJoiningType.txt instead.

Default values for common catalog, enumeration, and numeric properties are listed in Table 4.

Table 4. Default Values for Properties

Complex default values are those which take multiple values, contingent on code point ranges or other conditions. Complex default values other than those specified in the "@missing" line are explicitly listed in the relevant property file, except for instances noted in this section. This means that a parser extracting property values from the UCD should never encounter an ambiguous condition for which the default value of a property for a particular code point is unclear.

Default values for the Bidi_Class property are complex. See Unicode Standard Annex #9, "Unicode Bidirectional Algorithm" [UAX9] and DerivedBidiClass.txt for full details.

Default values for the East_Asian_Width property are complex. This property defaults to Neutral for most code points, but defaults to Wide for unassigned code points in blocks associated with CJK ideographs. See Unicode Standard Annex #11, "East Asian Width" [UAX11] and DerivedEastAsianWidth.txt for full details.

Default values for the Line_Break property are complex. This property defaults to Unknown for most code points, but defaults to ID for unassigned code points in blocks associated with CJK ideographs, and to PR for unassigned code points in the Currency Symbols block. See Unicode Standard Annex #14, "Unicode Line Breaking Algorithm" [UAX14], and DerivedLineBreak.txt for full details.

4.2.10 @missing Conventions

Specially-formatted comment lines with the keyword "@missing" are used to define default property values for ranges of code points not explicitly listed in a data file. These lines follow regular conventions that make them machine-readable.

An @missing line starts with the comment character "#", followed by a space, then the "@missing" keyword, followed by a colon, another space, a code point range, and a semicolon. Then the line typically continues with a semicolon-delimited list of one or more default property values. For example:

# @missing: 0000..10FFFF; Unknown
      

In general, the code point range and semicolon-delimited list follow the same syntactic conventions as the data file in which the @missing line occurs, so that any parser which interprets that data file can easily be adapted to also parse and interpret an @missing line to pick up default property values for code points.

@missing lines are also supplied for many properties in the file PropertyValueAliases.txt. In this case, because there are many @missing lines in that single data file, each @missing line contains an additional second field specifying the property name for which it defines a default value.

An @missing line is never provided for a binary property, because the default value for binary properties is always "N" and need not be defined redundantly for each binary property.

Because of the addition of property names when @missing lines are included in PropertyValueAliases.txt, there are currently two syntactic patterns used for @missing lines, as summarized schematically below:

1. code_point_range; default_prop_val
2. code_point_range; property_name; default_prop_val

In this schematic representation, "default_prop_val" stands in for either an explicit property value or for a special tag such as <none> or <script>.

Pattern #1 is used in most primary and derived UCD files. For example:

# @missing: 0000..10FFFF; <none>
      

Pattern #2 is used in PropertyValueAliases.txt and in DerivedNormalizationProps.txt, both of which contain values associated with many properties. For example:

# @missing: 0000..10FFFF; NFD_QC; Yes
      

The special tag values which may occur in the default_prop_val field in an @missing line are interpreted as follows:

 

4.2.11 Empty Fields

The data file UnicodeData.txt defines many property values in each record. When a field in a data line for a code point is empty, that indicates that the property takes the default value for that code point. For example:

0022;QUOTATION MARK;Po;0;ON;;;;;N;;;;;
      

In that data line, the empty numeric fields indicate that the value of Numeric_Value for U+0022 is NaN and that the value of Numeric_Type is None. The empty case mapping fields indicate that the value of Simple_Uppercase_Mapping for U+0022 takes the default value, namely the code point itself, and so forth.

The interpretation of empty fields in other data files of the UCD differs. In the case of data files which define string properties, the omission of an entry for a code point indicates that the property takes the default value for that code point. However, if there is an entry for a code point, but the property value field for that entry is empty, that indicates that the property value is an explicit empty string (""). For example, the derived string property NFKC_Casefold may map a code point to a sequence of code points, to a single different code point, to the same single code point, or to no code point at all (an empty string). See the following entries from the data file DerivedNormalizationProps.txt:

00AA          ; NFKC_CF; 0061           # Lo       FEMININE ORDINAL INDICATOR
00AD          ; NFKC_CF;                # Cf       SOFT HYPHEN
00AF          ; NFKC_CF; 0020 0304      # Sk       MACRON
      

The empty field for U+00AD indicates that the property NFKC_Casefold maps SOFT HYPHEN to an empty string. By contrast, the absence of the entry for U+00AE in the data file indicates that the property NFKC_Casefold maps U+00AE REGISTERED SIGN to itself—the default value.

4.2.12 Text Encoding

• The data files use UTF-8. Unless otherwise noted, non-ASCII characters only appear in comments.
• The Unihan data files in the UCD make extensive use of UTF-8 in data fields. (See [UAX38] for details.)
• For legacy reasons, NamesList.txt was exceptional; it was encoded in Latin-1 prior to Unicode 6.2. For Unicode 6.2 and later, the encoding is UTF-8. See NamesList.html.
• Segmentation test data files, such as WordBreakTest.txt, make use of non-ASCII (UTF-8) characters as delimiters for data fields.

4.2.13 Line Termination

• All data files in the UCD use LF line termination (not CRLF line termination). When copied to different systems, these line endings may be automatically changed to use the native line termination conventions for that system. Make sure your editor (or parser) can deal with the line termination style in the local copy of the data files.

4.2.14 Other Conventions

• In some test data files, segments of the test data are distinguished by a line starting with an "@" sign. For example (from NormalizationTest.txt):

  @Part1 # Character by character test
        

4.2.15 Other File Formats

• The data format for Unihan data files in the UCD differs from the standard format. See the discussion of Unihan and UAX #38 earlier in this annex for more information.
• The format for NamesList.txt, which documents the Unicode names list and which is used programmatically to drive the formatting program for Unicode code charts, also differs significantly from regular UCD data files. See NamesList.html
• Index.txt is another exception. It uses a tab-delimited format, with field 0 consisting of an index entry string, and field 1 a code point. Index.txt is used to maintain the Unicode Character Name Index.
• The various segmentation test data files make use of "#" to delimit comments, but have distinct conventions for their data fields. See the documentation in their header sections for details of the data field formats for those files.
• The XML version of the UCD has its own file format conventions. In those files, "#" is used to stand for the code point in algorithmically derivable character names such as CJK UNIFIED IDEOGRAPH-4E00, so as to allow for name sharing in more compact representations of the data. See Unicode Standard Annex #42, "Unicode Character Database in XML" [UAX42] for details.

4.3 File List

The exact list of files associated with any particular version of the UCD is available on the Unicode website by referring to the component listings at Enumerated Versions.

The majority of the data files in the UCD provide specifications of character properties for Unicode characters. Those files and their contents are documented in detail in the Property Definitions section below.

The data files in the extracted subdirectory constitute reformatted listings of single character properties extracted from UnicodeData.txt or other primary data files. The reformatting is provided to make it easier to see the particular set of characters having certain values for enumerated properties, or to separate the statement of that property from other properties defined together in UnicodeData.txt. These files also include explicit listings of default values for the respective properties. These extracted, derived data files are further documented in the Derived Extracted Properties section below.

The UCD also contains a number of test data files, whose purpose is to provide standard test cases useful in verifying the implementation of complex Unicode algorithms. See the Test Files section below for more documentation.

The remaining files in the Unicode Character Database do not directly specify Unicode properties. The important ones and their functions are listed in Table 5. The Status column indicates whether the file (and its content) is considered Normative, Informative, or Provisional.

Table 5. Files in the UCD

File Name	Reference	Status	Description
CJKRadicals.txt	[UAX38]	I	List of Unified CJK Ideographs and CJK Radicals that correspond to specific radical numbers used in the CJK radical stroke counts.
USourceData.txt	[UAX45]	N	The list of formal references for U-Source ideographs, together with data regarding their status and sources.
USourceGlyphs.pdf	[UAX45]	I	A table containing a representative glyph for each U-Source ideograph.
EmojiSources.txt	Chapter 22	N	Specifies source mappings to SJIS values for emoji symbols in the original implementations of these symbols by Japanese telecommunications companies.
Index.txt	Chapter 24	I	Index to Unicode characters.
NamesList.txt	Chapter 24	I	Names list used for production of the code charts, derived from UnicodeData.txt. It contains additional annotations.
NamesList.html	Chapter 24	I	Documents the format of NamesList.txt.
StandardizedVariants.txt	Chapter 23	N	Lists all the standardized variant sequences that have been defined, plus a textual description of their desired appearance.
StandardizedVariants.html	Chapter 23	N	A derived documentation file, generated from StandardizedVariants.txt, plus a list of sample glyphs showing the desired appearance of each standardized variant.
NamedSequences.txt	[UAX34]	N	Lists the names for all approved named sequences.
NamedSequencesProv.txt	[UAX34]	P	Lists the names for all provisional named sequences.

For more information about these files and their use, see the referenced annexes or chapters of Unicode Standard.

4.4 Zipped Files

Starting with Version 4.1.0, zipped versions of all of the UCD files, both data files and documentation files, are available under the Public/zipped directory on the Unicode website. Each collection of zipped files is located there in a numbered subdirectory corresponding to that version of the UCD.

Two different zipped files are provided for each version:

• Unihan.zip is the zipped version of the very large Unihan data files
• UCD.zip is the zipped version of all of the rest of the UCD data files, excluding the Unihan data files.

This bifurcation allows for better management of downloading version-specific information, because Unihan.zip contains all the pertinent CJK-related property information, while UCD.zip contains all of the rest of the UCD property information, for those who may not need the voluminous CJK data.

Starting with Version 6.1.0 the main versioned directories for the UCD also contain a copy of UCD.zip, for convenience in access.

In versions of the UCD prior to Version 4.1.0, zipped copies of the Unihan data files (which for those versions were released as a single large text file, Unihan.txt) are provided in the same directory as the UCD data files. These zipped files are only posted for versions of the UCD in which Unihan.txt was updated.

4.5 UCD in XML

Starting with Version 5.1.0, a set of XML data files are also released with each version of the UCD. Those data files make it possible to import and process the UCD property data using standard XML parsing tools, instead of the specialized parsing required for the various individual data files of the UCD.

4.5.1 UAX #42

Unicode Standard Annex #42, "Unicode Character Database in XML" [UAX42] defines an XML schema which is used to incorporate all of the Unicode character property information into the XML version of the UCD. See that annex for details of the schema and conventions regarding the grouping of property values for more compact representations.

4.5.2 XML File List

The XML version of the UCD is contained in the ucdxml subdirectory of the UCD. The files are all zipped. The list of files is shown in Table 6.

Table 6. XML File List

The "flat" file versions simply list all attributes with no particular compression. The "grouped" file versions apply the grouping mechanism described in [UAX42] to cut down on the size of the data files.

5 Properties

This section documents the Unicode character properties, relating them in detail to the particular UCD data files in which they are specified. For enumerated properties in particular, this section also documents the actual values which those properties can have.

5.1 Property Index

Table 7 provides a summary list of the Unicode character properties, excluding most of those specific to the Unihan data files. For a comparable index of CJK character properties, see Unicode Standard Annex #38, "Unicode Han Database (Unihan)" [UAX38].

The properties are roughly organized into groups based on their usage. This grouping is primarily for documentation convenience and except for contributory properties, has no normative implications. Contributory properties are shown in this index with a gray background, to better distinguish them visually from ordinary (simple or derived) properties. The link on each property leads to its description in Table 9, Property Table.

Table 7. Property Index by Scope of Use

 

5.2 About the Property Table

Table 9, Property Table specifies the list of character properties defined in the UCD. That table is divided into separate sections for each data file in the UCD. Data files which define a single property or a small number of properties are listed first, followed by the data files which define a large number of properties: DerivedCoreProperties.txt, DerivedNormalizationProps.txt, PropList.txt, and UnicodeData.txt. In some instances for these files defining many properties, the entries in the property table are grouped by type, for clarity in presentation, rather than being listed alphabetically.

In Table 9, Property Table each property is described as follows:

First Column. This column contains the name of each of the character properties specified in the respective data file. Any special status for a property, such as whether it is obsolete, deprecated, or stabilized, is also indicated in the first column.

Second Column. This column indicates the type of the property, according to the key in Table 8.

Table 8. Property Type Key

• Catalog properties have enumerated values which are expected to be regularly extended in successive versions of the Unicode Standard. This distinguishes them from Enumeration properties.
• Enumeration properties have enumerated values which constitute a logical partition space; new values will generally not be added to them in successive versions of the standard.
• Binary properties are a special case of Enumeration properties, which have exactly two values: Yes and No (or True and False).
• String properties are typically mappings from a Unicode code point to another Unicode code point or sequence of Unicode code points; examples include case mappings and decomposition mappings.
• Numeric properties specify the actual numeric values for digits and other characters associated with numbers in some way.
• Miscellaneous properties are those properties that do not fit neatly into the other property categories; they currently include character names, comments about characters, the Script_Extensions property, and the Unicode_Radical_Stroke property (a combination of numeric values) documented in Unicode Standard Annex #38, "Unicode Han Database (Unihan)" [UAX38].

Third Column. This column indicates the status of the property: Normative or Informative or Contributory or Provisional.

Fourth Column. This column provides a description of the property or properties. This includes information on derivation for derived properties, as well as references to locations in the standard where the property is defined or discussed in detail.

In the section of the table for UnicodeData.txt, the data field numbers are also supplied in parentheses at the start of the description.

For a few entries in the property table, values specified in the fields in a data file only contribute to a full definition of a Unicode character property. For example, the values in field 1 (Name) in UnicodeData.txt do not provide all the values for the Name property for all code points; Jamo.txt must also be used, and the Name property for CJK Unified Ideographs is derived by rule.

None of the Unicode character properties should be used simply on the basis of the descriptions in the property table without consulting the relevant discussions in the Unicode Standard. Because of the enormous variety of characters in the repertoire of the Unicode Standard, character properties tend not to be self-evident in application, even when the names of the properties may seem familiar from their usage with much smaller legacy character encodings.

5.3 Property Definitions

This section contains the table which describes each character property and defines its status, organized by data file in the UCD. Table 9 provides general descriptions of the Unicode character properties, their derivations, and/or their usage, as well as pointers to the respective parts of the standard where formal property definitions or additional information about the properties can be found. The property status column and any formal statement of the derivation of derived properties are definitive; however, Table 9 does not provide formal definitions of the other properties and should not be interpreted as such. For details on the columns and overall organization of the table, see Section 5.2 About the Property Table.

Table 9. Property Table

ArabicShaping.txt
Joining_Type Joining_Group	E	N	Basic Arabic and Syriac character shaping properties, such as initial, medial and final shapes. See Section 9.2, Arabic in [Unicode].
BidiBrackets.txt
Bidi_Paired_Bracket_Type	E	N	Type of a paired bracket, either opening or closing. This property is used in the implementation of parenthesis matching. See Unicode Standard Annex #9, "Unicode Bidirectional Algorithm" [UAX9].
Bidi_Paired_Bracket	M	N	For an opening bracket, the code point of the matching closing bracket. For a closing bracket, the code point of the matching opening bracket. This property is used in the implementation of parenthesis matching. See Unicode Standard Annex #9, "Unicode Bidirectional Algorithm" [UAX9].
BidiMirroring.txt
Bidi_Mirroring_Glyph	M	I	Informative mapping for substituting characters in an implementation of bidirectional mirroring. This maps a subset of characters with the Bidi_Mirrored property to other characters that normally are displayed with the corresponding mirrored glyph. When a character with the Bidi_Mirrored property has the default value for Bidi_Mirroring_Glyph, that means that no other character exists whose glyph is appropriate for character-based glyph mirroring. Implementations must then use other mechanisms to implement mirroring of those characters for the Unicode Bidirectional Algorithm. See Unicode Standard Annex #9, "Unicode Bidirectional Algorithm" [UAX9]. Do not confuse this property with the Bidi_Mirrored property itself.
Blocks.txt
Block	C	N	List of block names, which are arbitrary names for ranges of code points. See the code charts in [Unicode].
CompositionExclusions.txt
Composition_Exclusion	B	N	A property used in normalization. See Unicode Standard Annex #15, "Unicode Normalization Forms" [UAX15]. Unlike other files, CompositionExclusions.txt simply lists the relevant code points.
CaseFolding.txt
Simple_Case_Folding Case_Folding	S	N	Mapping from characters to their case-folded forms. This is an informative file containing normative derived properties. Derived from UnicodeData and SpecialCasing. Note: The case foldings are omitted in the data file if they are the same as the code point itself.
DerivedAge.txt
Age	C	N/I	This file shows when various code points were designated/assigned in successive versions of the Unicode Standard. The Age property is normative in the sense that it is completely specified based on when a character is encoded in the standard. However, DerivedAge.txt is provided for information. The value of the Age property for a code point can be derived by analysis of successive versions of the UCD, and Age is not used normatively in the specification of any Unicode algorithm. Note: When using the Age property in regular expressions, an expression such as "\p{age=3.0}" matches all of the code points assigned in Version 3.0—that is, all the code points with a value less than or equal to 3.0 for the Age property. For more information, see Unicode Technical Standard #18, "Unicode Regular Expressions" [UTS18].
EastAsianWidth.txt
East_Asian_Width	E	I	Properties for determining the choice of wide versus narrow glyphs in East Asian contexts. Property values are described in Unicode Standard Annex #11, "East Asian Width" [UAX11].
HangulSyllableType.txt
Hangul_Syllable_Type	E	N	The values L, V, T, LV, and LVT used in Chapter 3, Conformance in [Unicode].
IndicPositionalCategory.txt
Indic_Positional_Category	E	I	A property defining the placement categories for dependent vowels, viramas, combining marks, and other characters used in Indic scripts.
IndicSyllabicCategory.txt
Indic_Syllabic_Category	E	I	A property defining the structural categories of syllabic components in Indic scripts.
Jamo.txt
Jamo_Short_Name	M	C	The Hangul Syllable names are derived from the Jamo Short Names, as described in Chapter 3, Conformance in [Unicode].
LineBreak.txt
Line_Break	E	N	Properties for line breaking. For more information, see Unicode Standard Annex #14, "Unicode Line Breaking Algorithm" [UAX14].
GraphemeBreakProperty.txt
Grapheme_Cluster_Break	E	I	See Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29]
SentenceBreakProperty.txt
Sentence_Break	E	I	See Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29]
WordBreakProperty.txt
Word_Break	E	I	See Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29]
NameAliases.txt
Name_Alias	M	N	Normative formal aliases for characters with erroneous names, for control characters and some format characters, and for character abbreviations, as described in Chapter 4, Character Properties in [Unicode]. Aliases tagged with the type "correction", as well as a selection of aliases of other types, are published in the Unicode Standard code charts.
NormalizationCorrections.txt
used in Decomposition Mappings	S	N	NormalizationCorrections lists code point differences for Normalization Corrigenda. For more information, see Unicode Standard Annex #15, "Unicode Normalization Forms" [UAX15].
Scripts.txt
Script	C	I	Script values for use in regular expressions and elsewhere. For more information, see Unicode Standard Annex #24, "Unicode Script Property" [UAX24].
ScriptExtensions.txt
Script_Extensions	M	I	Enumerated sets of Script values for use in regular expressions and elsewhere. For more information, see Unicode Standard Annex #24, "Unicode Script Property" [UAX24].
SpecialCasing.txt
Uppercase_Mapping Lowercase_Mapping Titlecase_Mapping	S	I	Data for producing (in combination with the simple case mappings from UnicodeData.txt) the full case mappings.
Unihan data files (for more information, see [UAX38])
Numeric_Type Numeric_Value	E	I	The characters tagged with either kPrimaryNumeric, kAccountingNumeric, or kOtherNumeric are given the property value Numeric_Type=Numeric, and the Numeric_Value indicated in those tags. Most characters have these numeric properties based on values from UnicodeData.txt. See Numeric_Type.
Unicode_Radical_Stroke	M	I	The Unicode radical-stroke count, based on the tag kRSUnicode.
DerivedCoreProperties.txt
Lowercase	B	I	Characters with the Lowercase property. For more information, see Chapter 4, Character Properties in [Unicode]. Generated from: Ll + Other_Lowercase
Uppercase	B	I	Characters with the Uppercase property. For more information, see Chapter 4, Character Properties in [Unicode]. Generated from: Lu + Other_Uppercase
Cased	B	I	Characters which are considered to be either uppercase, lowercase or titlecase characters. This property is not identical to the Changes_When_Casemapped property. For more information, see D135 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: Lowercase + Uppercase + Lt
Case_Ignorable	B	I	Characters which are ignored for casing purposes. For more information, see D136 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: Mn + Me + Cf + Lm + Sk + Word_Break=MidLetter + Word_Break=MidNumLet + Word_Break=Single_Quote
Changes_When_Lowercased	B	I	Characters whose normalized forms are not stable under a toLowercase mapping. For more information, see D139 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: toLowercase(toNFD(X)) != toNFD(X)
Changes_When_Uppercased	B	I	Characters whose normalized forms are not stable under a toUppercase mapping. For more information, see D140 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: toUppercase(toNFD(X)) != toNFD(X)
Changes_When_Titlecased	B	I	Characters whose normalized forms are not stable under a toTitlecase mapping. For more information, see D141 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: toTitlecase(toNFD(X)) != toNFD(X)
Changes_When_Casefolded	B	I	Characters whose normalized forms are not stable under case folding. For more information, see D142 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: toCasefold(toNFD(X)) != toNFD(X)
Changes_When_Casemapped	B	I	Characters which may change when they undergo case mapping. For more information, see D143 in Section 3.13, Default Case Algorithms in [Unicode]. Generated from: Changes_When_Lowercased(X) or Changes_When_Uppercased(X) or Changes_When_Titlecased(X)
Alphabetic	B	I	Characters with the Alphabetic property. For more information, see Chapter 4, Character Properties in [Unicode]. Generated from: Lowercase + Uppercase + Lt + Lm + Lo + Nl + Other_Alphabetic
Default_Ignorable_Code_Point	B	N	For programmatic determination of default ignorable code points. New characters that should be ignored in rendering (unless explicitly supported) will be assigned in these ranges, permitting programs to correctly handle the default rendering of such characters when not otherwise supported. For more information, see the FAQ Display of Unsupported Characters, and Section 5.21, Ignoring Characters in Processing in [Unicode]. Generated from Other_Default_Ignorable_Code_Point + Cf (format characters) + Variation_Selector - White_Space - FFF9..FFFB (annotation characters) - 0600..0605, 06DD, 070F, 110BD (exceptional Cf characters that should be visible)
Grapheme_Base	B	N	Property used together with the definition of Standard Korean Syllable Block to define "Grapheme base". See D58 in Chapter 3, Conformance in [Unicode]. Generated from: [0..10FFFF] - Cc - Cf - Cs - Co - Cn - Zl - Zp - Grapheme_Extend Note: Grapheme_Base is a property of individual characters. That usage contrasts with "grapheme base", which is an attribute of Unicode strings; a grapheme base may consist of a Korean syllable which is itself represented by a sequence of conjoining jamos.
Grapheme_Extend	B	N	Property used to define "Grapheme extender". See D59 in Chapter 3, Conformance in [Unicode]. Generated from: Me + Mn + Other_Grapheme_Extend Note: The set of characters for which Grapheme_Extend=Yes is equivalent to the set of characters for which Grapheme_Cluster_Break=Extend.
Grapheme_Link (Deprecated as of 5.0.0)	B	I	Formerly proposed for programmatic determination of grapheme cluster boundaries. Generated from: Canonical_Combining_Class=Virama
Math	B	I	Characters with the Math property. For more information, see Chapter 4, Character Properties in [Unicode]. Generated from: Sm + Other_Math
ID_Start	B	I	Used to determine programming identifiers, as described in Unicode Standard Annex #31, "Unicode Identifier and Pattern Syntax" [UAX31].
ID_Continue	B	I
XID_Start	B	I
XID_Continue	B	I
DerivedNormalizationProps.txt
Full_Composition_Exclusion	B	N	Characters that are excluded from composition: those listed explicitly in CompositionExclusions.txt, plus the derivable sets of Singleton Decompositions and Non-Starter Decompositions, as documented in that data file.
Expands_On_NFC Expands_On_NFD Expands_On_NFKC Expands_On_NFKD (Deprecated as of 6.0.0)	B	N	Characters that expand to more than one character in the specified normalization form.
FC_NFKC_Closure (Deprecated as of 6.0.0)	S	N	Characters that require extra mappings for closure under Case Folding plus Normalization Form KC. The mapping is listed in Field 2.
NFD_Quick_Check NFKD_Quick_Check NFC_Quick_Check NFKC_Quick_Check	E	N	For property values, see Decompositions and Normalization. (Abbreviated names: NFD_QC, NFKD_QC, NFC_QC, NFKC_QC)
NFKC_Casefold	S	I	A mapping designed for best behavior when doing caseless matching of strings interpreted as identifiers. (Abbreviated name: NFKC_CF) For the definition of the related string transform toNFKC_Casefold() based on this mapping, see Section 3.13, Default Case Algorithms in [Unicode]. The mapping is listed in Field 2.
Changes_When_NFKC_Casefolded	B	I	Characters which are not identical to their NFKC_Casefold mapping. Generated from: (cp != NFKC_CaseFold(cp))
PropList.txt
ASCII_Hex_Digit	B	N	ASCII characters commonly used for the representation of hexadecimal numbers.
Bidi_Control	B	N	Format control characters which have specific functions in the Unicode Bidirectional Algorithm [UAX9].
Dash	B	I	Punctuation characters explicitly called out as dashes in the Unicode Standard, plus their compatibility equivalents. Most of these have the General_Category value Pd, but some have the General_Category value Sm because of their use in mathematics.
Deprecated	B	N	For a machine-readable list of deprecated characters. No characters will ever be removed from the standard, but the usage of deprecated characters is strongly discouraged.
Diacritic	B	I	Characters that linguistically modify the meaning of another character to which they apply. Some diacritics are not combining characters, and some combining characters are not diacritics.
Extender	B	I	Characters whose principal function is to extend the value or shape of a preceding alphabetic character. Typical of these are length and iteration marks.
Hex_Digit	B	I	Characters commonly used for the representation of hexadecimal numbers, plus their compatibility equivalents.
Hyphen (Stabilized as of 4.0.0; Deprecated as of 6.0.0	B	I	Dashes which are used to mark connections between pieces of words, plus the Katakana middle dot. The Katakana middle dot functions like a hyphen, but is shaped like a dot rather than a dash.
Ideographic	B	I	Characters considered to be CJKV (Chinese, Japanese, Korean, and Vietnamese) ideographs. This property roughly defines the class of "Chinese characters" and does not include characters of other logographic scripts such as Cuneiform or Egyptian Hieroglyphs.
IDS_Binary_Operator	B	N	Used in Ideographic Description Sequences.
IDS_Trinary_Operator	B	N	Used in Ideographic Description Sequences.
Join_Control	B	N	Format control characters which have specific functions for control of cursive joining and ligation.
Logical_Order_Exception	B	N	A small number of spacing vowel letters occurring in certain Southeast Asian scripts such as Thai and Lao, which use a visual order display model. These letters are stored in text ahead of syllable-initial consonants, and require special handling for processes such as searching and sorting.
Noncharacter_Code_Point	B	N	Code points permanently reserved for internal use.
Other_Alphabetic	B	C	Used in deriving the Alphabetic property.
Other_Default_Ignorable_Code_Point	B	C	Used in deriving the Default_Ignorable_Code_Point property.
Other_Grapheme_Extend	B	C	Used in deriving  the Grapheme_Extend property.
Other_ID_Continue	B	C	Used to maintain backward compatibility of ID_Continue.
Other_ID_Start	B	C	Used to maintain backward compatibility of ID_Start.
Other_Lowercase	B	C	Used in deriving the Lowercase property.
Other_Math	B	C	Used in deriving the Math property.
Other_Uppercase	B	C	Used in deriving the Uppercase property.
Pattern_Syntax	B	N	Used for pattern syntax as described in Unicode Standard Annex #31, "Unicode Identifier and Pattern Syntax" [UAX31].
Pattern_White_Space	B	N
Quotation_Mark	B	I	Punctuation characters that function as quotation marks.
Radical	B	N	Used in Ideographic Description Sequences.
Soft_Dotted	B	N	Characters with a "soft dot", like i or j. An accent placed on these characters causes the dot to disappear. An explicit dot above can be added where required, such as in Lithuanian.
STerm	B	I	Sentence Terminal. Used in Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29].
Terminal_Punctuation	B	I	Punctuation characters that generally mark the end of textual units.
Unified_Ideograph	B	N	A property which specifies the exact set of Unified CJK Ideographs in the standard. This set excludes CJK Compatibility Ideographs (which have canonical decompositions to Unified CJK Ideographs), as well as characters from the CJK Symbols and Punctuation block. The property is used in the definition of Ideographic Description Sequences.
Variation_Selector	B	N	Indicates characters that are Variation Selectors. For details on the behavior of these characters, see StandardizedVariants.html, Section 23.4, Variation Selectors in [Unicode], and Unicode Technical Standard #37, "Unicode Ideographic Variation Database" [UTS37].
White_Space	B	N	Spaces, separator characters and other control characters which should be treated by programming languages as "white space" for the purpose of parsing elements. See also Line_Break, Grapheme_Cluster_Break, Sentence_Break, and Word_Break, which classify space characters and related controls somewhat differently for particular text segmentation contexts.
UnicodeData.txt
Name	M	N	(1) These names match exactly the names published in the code charts of the Unicode Standard. The derived Hangul Syllable names are omitted from this file; see Jamo.txt for their derivation.
General_Category	E	N	(2) This is a useful breakdown into various character types which can be used as a default categorization in implementations. For the property values, see General Category Values.
Canonical_Combining_Class	N	N	(3) The classes used for the Canonical Ordering Algorithm in the Unicode Standard. This property could be considered either an enumerated property or a numeric property: the principal use of the property is in terms of the numeric values. For the property value names associated with different numeric values, see DerivedCombiningClass.txt and Canonical Combining Class Values.
Bidi_Class	E	N	(4) These are the categories required by the Unicode Bidirectional Algorithm. For the property values, see Bidirectional Class Values. For more information, see Unicode Standard Annex #9, "Unicode Bidirectional Algorithm" [UAX9]. The default property values depend on the code point, and are explained in DerivedBidiClass.txt
Decomposition_Type Decomposition_Mapping	E, S	N	(5) This field contains both values, with the type in angle brackets. The decomposition mappings exactly match the decomposition mappings published with the character names in the Unicode Standard. For more information, see Character Decomposition Mappings.
Numeric_Type Numeric_Value	E, N	N	(6) If the character has the property value Numeric_Type=Decimal, then the Numeric_Value of that digit is represented with an integer value (limited to the range 0..9) in fields 6, 7, and 8. Characters with the property value Numeric_Type=Decimal are restricted to digits which can be used in a decimal radix positional numeral system and which are encoded in the standard in a contiguous ascending range 0..9. See the discussion of decimal digits in Chapter 4, Character Properties in [Unicode].
	E, N	N	(7) If the character has the property value Numeric_Type=Digit, then the Numeric_Value of that digit is represented with an integer value (limited to the range 0..9) in fields 7 and 8, and field 6 is null. This covers digits that need special handling, such as the compatibility superscript digits. Starting with Unicode 6.3.0, no newly encoded numeric characters will be given Numeric_Type=Digit, nor will existing characters with Numeric_Type=Numeric be changed to Numeric_Type=Digit. The distinction between those two types is not considered useful.
	E, N	N	(8) If the character has the property value Numeric_Type=Numeric, then the Numeric_Value of that character is represented with a positive or negative integer or rational number in this field, and fields 6 and 7 are null. This includes fractions such as, for example, "1/5" for U+2155 VULGAR FRACTION ONE FIFTH. Some characters have these properties based on values from the Unihan data files. See Numeric_Type, Han.
Bidi_Mirrored	B	N	(9) If the character is a "mirrored" character in bidirectional text, this field has the value "Y"; otherwise "N". See Section 4.7, Bidi Mirrored of [Unicode]. Do not confuse this with the Bidi_Mirroring_Glyph property.
Unicode_1_Name (Obsolete as of 6.2.0)	M	I	(10) Old name as published in Unicode 1.0 or ISO 6429 names for control functions. This field is empty unless it is significantly different from the current name for the character. No longer used in code chart production. See Name_Alias.
ISO_Comment (Obsolete as of 5.2.0; Deprecated and Stabilized as of 6.0.0)	M	I	(11) ISO 10646 comment field. It was used for notes that appeared in parentheses in the 10646 names list, or contained an asterisk to mark an Annex P note. As of Unicode 5.2.0, this field no longer contains any non-null values.
Simple_Uppercase_Mapping	S	N	(12) Simple uppercase mapping (single character result). If a character is part of an alphabet with case distinctions, and has a simple uppercase equivalent, then the uppercase equivalent is in this field. The simple mappings have a single character result, where the full mappings may have multi-character results. For more information, see Case and Case Mapping.
Simple_Lowercase_Mapping	S	N	(13) Simple lowercase mapping (single character result).
Simple_Titlecase_Mapping	S	N	(14) Simple titlecase mapping (single character result). Note: If this field is null, then the Simple_Titlecase_Mapping is the same as the Simple_Uppercase_Mapping for this character.

 

5.4 Derived Extracted Properties

A number of Unicode character properties have been separated out, reformatted, and listed in range format, one property per file. These files are located under the extracted directory of the UCD. The exact list of derived extracted files and the extracted properties they represent are given in Table 10.

The derived extracted files are provided primarily as a reformatting of data for properties specified in other data files. For nondefault values of properties, if there is any inadvertant mismatch between the primary data files specifying those properties and these lists of extracted properties, the primary data files are taken as definitive. However, for default values of properties, the extracted data files are definitive. This is particularly true for properties which have multiple default values; those properties are identified with an asterisk in the table. See Section 4.2.9, Default Values.

Table 10. Extracted Properties

For the extraction of Decomposition_Type, characters with canonical decomposition mappings in field 5 of UnicodeData.txt have no tag. For those characters, the extracted value is Decomposition_Type=Canonical. For characters with compatibility decomposition mappings, there are explicit tags in field 5, and the value of Decomposition_Type is equivalent to those tags. The value Decomposition_Type=Canonical is normative. Other values for Decomposition_Type are informative.

Numeric_Value is extracted based on the actual numeric value of the data in field 8 of UnicodeData.txt or the values of the kPrimaryNumeric, kAccountingNumeric, or kOtherNumeric tags, for characters listed in the Unihan data files.

Numeric_Type is extracted as follows. If fields 6, 7, and 8 in UnicodeData.txt are all non-empty, then Numeric_Type=Decimal. Otherwise, if fields 7 and 8 are both non-empty, then Numeric_Type=Digit. Otherwise, if field 8 is non-empty, then Numeric_Type=Numeric. For characters listed in the Unihan data files, Numeric_Type=Numeric for characters that have kPrimaryNumeric, kAccountingNumeric, or kOtherNumeric tags. The default value is Numeric_Type=None.

5.5 Contributory Properties

Contributory properties contain sets of exceptions used in the generation of other properties derived from them. The contributory properties specifically concerned with identifiers and casing contribute to the maintenance of stability guarantees for properties and/or to invariance relationships between related properties. Other contributory properties are simply defined as a convenience for property derivation.

Most contributory properties have names using the pattern "Other_XXX" and are used to derive the corresponding "XXX" property. For example, the Other_Alphabetic property is used in the derivation of the Alphabetic property.

Contributory properties are typically defined in PropList.txt and the corresponding derived property is then listed in DerivedCoreProperties.txt.

Jamo_Short_Name is an unusual contributory property, both in terms of its name and how it is used. It is defined in its own property file, Jamo.txt, and is used to derive the Name property value for Hangul syllable characters, according to the rules spelled out in Section 3.12, Conjoining Jamo Behavior in [Unicode].

Contributory is considered to be a distinct status for a Unicode character property. Contributory properties are neither normative nor informative. This distinct status is marked in the property table.

Contributory properties are incomplete by themselves and are not intended for independent use. For example, an API returning Unicode property values should implement the derived core properties such as Alphabetic or Default_Ignorable_Code_Point, rather than the corresponding contributory properties, Other_Alphabetic or Other_Default_Ignorable_Code_Point.

5.6 Case and Case Mapping

Case for bicameral scripts and case mapping of characters are complicated topics in the Unicode Standard—both because of their inherent algorithmic complexity and because of the number of characters and special edge cases involved.

This section provides a brief roadmap to discussions about these topics, and specifications and definitions in the standard, as well as explaining which case-related properties are defined in the UCD.

Section 3.13, Default Case Algorithms in [Unicode] provides formal definitions for a number of case-related concepts (cased, case-ignorable, ...), for case conversion (toUppercase(X), ...), and for case detection (isUppercase(X), ...). It also provides the formal definition of caseless matching for the standard, taking normalization into account.

Section 4.2, Case in [Unicode] introduces case and case mapping properties. Table 4-1, Sources for Case Mapping Information in [Unicode] describes the kind of case-related information that is available in various data files of the UCD. Table 11 lists those data files again, giving the explicit list of case-related properties defined in each. The link on each property leads its description in Table 9, Property Table.

Table 11. UCD Files and Case Properties

For compatibility with existing parsers, UnicodeData.txt only contains case mappings for characters where they constitute one-to-one mappings; it also omits information about context-sensitive case mappings. Information about these special cases can be found in the separate data file, SpecialCasing.txt, expressed as separate properties.

Section 5.18, Case Mappings, in [Unicode] discusses various implementation issues for handling case, including language-specific case mapping, as for Greek and for Turkish. That section also describes case folding in particular detail.

The special casing conditions associated with case mapping for Greek, Turkish, and Lithuanian are specified in an additional field in SpecialCasing.txt. For example, the lowercase mapping for sigma in Greek varies according to its position in a word. The condition list does not constitute a formal character property in the UCD, because it is a statement about the context of occurrence of casing behavior for a character or characters, rather than a semantic attribute of those characters. Versions of the UCD from Version 3.2.0 to Version 5.0.0 did list property aliases for Special_Case_Condition (scc), but this was determined to be an error when the UCD was analyzed for representation in XML; consequently, the Special_Case_Condition property aliases were removed as of Version 5.1.0.

Caseless matching is of particular concern for a number of text processing algorithms, so is also discussed at some length in Unicode Standard Annex #31, "Unicode Identifier and Pattern Syntax" [UAX31] and in Unicode Technical Standard #10, "Unicode Collation Algorithm" [UTS10].

Further information about locale-specific casing conventions can be found in the Unicode Common Locale Data Repository [CLDR].

5.7 Property Value Lists

The following subsections give summaries of property values for certain Enumeration properties. Other property values are documented in other, topically-specific annexes; for example, the Line_Break property values are documented in Unicode Standard Annex #14, "Unicode Line Breaking Algorithm" [UAX14] and the various segmentation-related property values are documented in Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29].

5.7.1 General Category Values

The General_Category property of a code point provides for the most general classification of that code point. It is usually determined based on the primary characteristic of the assigned character for that code point. For example, is the character a letter, a mark, a number, punctuation, or a symbol, and if so, of what type? Other General_Category values define the classification of code points which are not assigned to regular graphic characters, including such statuses as private-use, control, surrogate code point, and reserved unassigned.

Many characters have multiple uses, and not all such cases can be captured entirely by the General_Category value. For example, the General_Category value of Latin, Greek, or Hebrew letters does not attempt to cover (or preclude) the numerical use of such letters as Roman numerals or in other numerary systems. Conversely, the General_Category of ASCII digits 0..9 as Nd (decimal digit) neither attempts to cover (or preclude) the occasional use of these digits as letters in various orthographies. The General_Category is simply the first-order, most usual categorization of a character.

For more information about the General_Category property, see Chapter 4, Character Properties in [Unicode].

The values in the General_Category field in UnicodeData.txt make use of the short, abbreviated property value aliases for General_Category. For convenience in reference, Table 12 lists all the abbreviated and long value aliases for General_Category values, reproduced from PropertyValueAliases.txt, along with a brief description of each category.

Table 12. General_Category Values

Note that the value gc=Cn does not actually occur in UnicodeData.txt, because that data file does not list unassigned code points.

The distinctions between some General_Category values are somewhat arbitrary for edge cases, particularly those involving symbols and punctuation. For example, a number of multiple-function ASCII characters, including "@", "#", "%", and "&", have long been classified as Other_Punctuation (gc=Po), although they are not among the characters used as punctuation marks in traditional Western typography. Other characters may also be ambiguous between functioning to organize and delimit textual units (punctuation-like) or to represent concepts (symbol-like). Likewise, it may not always be clear whether some symbols are primarily used for mathematics or whether they are general symbols with occasional or even common use in mathematics. For example, many arrow symbols are classed as Other_Symbol, although they are widely used in mathematics. The General_Category values constitute a rough partitioning of characters to make distinctions for algorithmic processing, but do not provide a definitive classification for such overlapping or ambiguous usage of characters.

Characters with the quotation-related General_Category values Pi or Pf may behave like opening punctuation (gc=Ps) or closing punctuation (gc=Pe), depending on usage and quotation conventions.

General_Category values in the table highlighted in light blue (LC, L, M, N, P, S, Z, C) stand for groupings of related General_Category values. The classes they represent can be derived by unions of the relevant simple values, as shown in the table. The abbreviated and long value aliases for these classes are provided as a convenience for implementations, such as regex, which may wish to match more generic categories, such as "letter" or "number", rather than the detailed subtypes for General_Category. These aliases for groupings of General_Category values do not occur in UnicodeData.txt, which instead always specifies the enumerated subtype for the General_Category of a character.

The symbol "L&" is a label used to stand for any combination of uppercase, lowercase or titlecase letters (Lu, Ll, or Lt), in the first part of comments in the data files of the UCD. It is equivalent to gc=LC, but is only a label in comments, and is not expected to be used as an identifier for regular expression matching.

The Unicode Standard does not assign nondefault property values to control characters (gc=Cc), except for certain well-defined exceptions involving the Unicode Bidirectional Algorithm, the Unicode Line Breaking Algorithm, and Unicode Text Segmentation. Also, implementations will usually assign behavior to certain line breaking control characters—most notably U+000D and U+000A (CR and LF)—according to platform conventions. See Section 5.8, Newline Guidelines in [Unicode] for more information.

5.7.2 Bidirectional Class Values

The values in the Bidi_Class field in UnicodeData.txt make use of the short, abbreviated property value aliases for Bidi_Class. For convenience in reference, Table 13 lists all the abbreviated and long value aliases for Bidi_Class values, reproduced from PropertyValueAliases.txt, along with a brief description of each category.

Table 13. Bidi_Class Values

Please refer to Unicode Standard Annex #9, "Unicode Bidirectional Algorithm" [UAX9] for an an explanation of the significance of these values when formatting bidirectional text.

The four enumerated values for the isolate controls were added in Unicode 6.3. That means there is a discontinuity in the enumeration for Bidi_Class between Unicode 6.2 and Unicode 6.3 (and later versions) which parsers of UnicodeData.txt and DerivedBidiClass.txt must take into account.

5.7.3 Character Decomposition Mapping

The value of the Decomposition_Mapping property for a character is provided in field 5 of UnicodeData.txt. This is a string property, consisting of a sequence of one or more Unicode code points. The default value of the Decomposition_Mapping property is the code point of the character itself. The use of the default value for a character is indicated by leaving field 5 empty in UnicodeData.txt. Informally, the value of the Decomposition_Mapping property for a character is known simply as its decomposition mapping. When a character's decomposition mapping is other than the default value, the decomposition mapping is printed out explicitly in the names list for the Unicode code charts.

The prefixed tags supplied with a subset of the decomposition mappings generally indicate formatting information. Where no such tag is given, the mapping is canonical. Conversely, the presence of a formatting tag also indicates that the mapping is a compatibility mapping and not a canonical mapping. In the absence of other formatting information in a compatibility mapping, the tag is used to distinguish it from canonical mappings.

In some instances a canonical mapping or a compatibility mapping may consist of a single character. For a canonical mapping, this indicates that the character is a canonical equivalent of another single character. For a compatibility mapping, this indicates that the character is a compatibility equivalent of another single character.

A canonical mapping may also consist of a pair of characters, but is never longer than two characters. When a canonical mapping consists of a pair of characters, the first character may itself be a character with a decomposition mapping, but the second character never has a decomposition mapping.

Compatibility mappings can be much longer than canonical mappings. For historical reasons, the longest compatibility mapping is 18 characters long. Compatibility mappings are guaranteed to be no longer than 18 characters, although most consist of just a few characters.

The compatibility formatting tags used in the UCD are listed in Table 14.

Table 14. Compatibility Formatting Tags

Note: There is a difference between decomposition and the Decomposition_Mapping property. The Decomposition_Mapping property is a string property whose values (mappings) are defined in UnicodeData.txt, while the decomposition (also termed "full decomposition") is defined in Section 3.7, Decomposition in [Unicode] to use those mappings recursively.

• The canonical decomposition is formed by recursively applying the canonical mappings, then applying the Canonical Ordering Algorithm.
• The compatibility decomposition is formed by recursively applying the canonical and compatibility mappings, then applying the Canonical Ordering Algorithm.

Starting from Unicode 2.1.9, the decomposition mappings in UnicodeData.txt can be used to derive the full decomposition of any single character in canonical order, without the need to separately apply the Canonical Ordering Algorithm. However, canonical ordering of combining character sequences must still be applied in decomposition when normalizing source text which contains any combining marks.

The normalization of Hangul conjoining jamos and of Hangul syllables depends on algorithmic mapping, as specified in Section 3.12, Conjoining Jamo Behavior in [Unicode]. That algorithm specifies the full decomposition of all precomposed Hangul syllables, but effectively it is equivalent to the recursive application of pairwise decomposition mappings, as for all other Unicode characters. Formally, the Decomposition_Mapping property value for a Hangul syllable is the pairwise decomposition and not the full decomposition.

Each character with the Hangul_Syllable_Type value LVT will have a Decomposition_Mapping consisting of a character with an LV value and a character with a T value. Thus for U+CE31 the Decomposition_Mapping is <U+CE20, U+11B8>, rather than <U+110E, U+1173, U+11B8>.

The Unihan property kCompatibilityVariant consists of a listing of the canonical Decomposition_Mapping property values just for CJK compatibility ideographs. Because its values are derived from UnicodeData.txt, it is formally considered to be a derived property. The exact statement of the derivation for kCompatibilityVariant is listed in Unicode Standard Annex #38, "Unicode Han Database (Unihan)" [UAX38].

5.7.4 Canonical Combining Class Values

The values in the Canonical_Combining_Class field in UnicodeData.txt are numerical values used in the Canonical Ordering Algorithm. Some of those numerical values also have explicit symbolic labels as property value aliases, to make their intended application more understandable. For convenience in reference, Table 15 lists the long symbolic aliases for Canonical_Combining_Class values, reproduced from PropertyValueAliases.txt, along with a brief description of each category. The listing for fixed position classes, with long symbolic aliases of the form "Ccc10", and so forth, is abbreviated, as when those labels occur they are predictable in form, based on the numeric values.

Table 15. Canonical_Combining_Class Values

Some of the Canonical_Combining_Class values in the table are not currently used for any characters but are specified here for completeness. Some values do not have long symbolic aliases and are not listed in PropertyValueAliases.txt. Do not assume that absence of a long symbolic alias implies non-use of a particular Canonical_Combining_Class. See DerivedCombiningClass.txt for a complete listing of the use of Canonical_Combining_Class values for any particular version of the UCD.

For use in regular expression matching, fixed position classes (ccc=10 through ccc=199) which actually occur in the Unicode Character Database for any version are given predictable aliases of the form "Ccc10", "Ccc11", and so forth. The complete list of such aliases which are actually defined can be found in PropertyValueAliases.txt.

The character property invariants regarding Canonical_Combining_Class guarantee that values, once assigned, will never change, and that all values used will be in the range 0..254. See Invariants in Implementations.

Combining marks with ccc=224 (Left) follow their base character in storage, as for all combining marks, but are rendered visually on the left side of them. For all past versions of the UCD and continuing with this version of the UCD, only two tone marks used in certain notations for Hangul syllables have ccc=224. Those marks are actually rendered visually on the left side of the preceding grapheme cluster, in the case of Hangul syllables resulting from sequences of conjoining jamos.

Those few instances of combining marks with ccc=Left should be distinguished from the far more numerous examples of left-side vowel signs and vowel letters in Brahmi-derived scripts. The Canonical_Combining_Class value is zero (Not_Reordered) for both ordinary, left-side (reordrant) vowel signs such as U+093F DEVANAGARI VOWEL SIGN I and for Thai-style left-side (Logical_Order_Exception=Yes) vowel letters such as U+0E40 THAI CHARACTER SARA E. The "Not_Reordered" of ccc=Not_Reordered refers to the behavior of the character in terms of the Canonical Ordering Algorithm as part of the definition of Unicode Normalization; it does not refer to any issues of visual reordering of glyphs involved in display and rendering. See "Canonical Ordering Algorithm" in Section 3.11, Normalization Forms in [Unicode].

5.7.5 Decompositions and Normalization

Decomposition is specified in Chapter 3, Conformance of [Unicode]. That chapter also specifies the interaction between decomposition and normalization.

A number of derived properties related to Unicode normalization are called the "Quick_Check" properties. These are defined to enable various optimizations for implementations of normalization, as explained in Section 9, Detecting Normalization Forms, in Unicode Standard Annex #15, "Unicode Normalization Forms" [UAX15]. The values for the four Quick_Check properties for all code points are listed in DerivedNormalizationProps.txt. The interpretations of the possible property values are summarized in Table 16.

Table 16. Quick_Check Property Values

 

5.7.6 Properties Whose Values Are Sets of Values

Most properties have a single value associated with each code point. However, some properties may instead associate a set of multiple different values with each code point. For example, the provisional kCantonese property, which lists Cantonese pronunciations for unified CJK ideographs, has values which consist of a set of zero or more romanized pronunciation strings. Thus, the Unihan Database contains an entry:

U+342B	kCantonese	gun3 hung1 zung1

This line is to be interpreted as associating a set of three string values, {"gun3", "hung1", "zung1"} with the kCantonese property for U+342B.

Similarly, the Script_Extensions property has values which consist of a set of one or more Script property values. Thus the property file ScriptExtensions.txt in the UCD contains an entry:

0640          ; Arab Mand Mani Phlp Syrc # Lm       ARABIC TATWEEL

This line is to be interpreted as associating a set of three enumerated Script property values, {Arab, Mand, Syrc}, with the Script_Extensions property for U+0640.

In the case of Script_Extensions, in particular, the set of sets which constitute meaningful values of the property is relatively small, and could be explicitly evaluated for any particular Unicode version. For example:

{{Arab, Copt}, {Arab, Syrc}, {Arab, Thaa}, {Arab, Syrc, Thaa}, {Arab, Mand, Mani, Phlp, Syrc}, {Armn, Geor}, ...}

However, an enumeration of this set of set values is unlikely to be of much implementation value, and would be likely to change significantly between versions of the standard. In other cases, such as for properties definining pronunciation readings for unified CJK ideographs, these sets of sets are completely open-ended, and there is no point to attempting to provide explicit enumerations of such sets in the UCD.

The order of the element values in such sets may or may not be significant. For example, the order among the element values for kCantonese and for Script_Extensions is not significant. By way of contrast, when the kMandarin property shows two values for a code point, the first value is used to indicate a preferred pronunciation for zh-Hans (CN) and the second a preferred pronunciation for zh-Hant (TW).

For data file format considerations regarding properties which take sets of values, see Section 4.2.8 Multiple Values for Properties. For considerations regarding validation of such properties, see Section 5.11.5 Validation of Multivalued Properties. See also Unicode Technical Standard #18, "Unicode Regular Expressions" [UTS18] for a discussion of how to handle such properties when processing regular expressions.

5.8 Property and Property Value Aliases

Both Unicode character properties themselves and their values are given symbolic aliases. The formal lists of aliases are provided so that well-defined symbolic values are available for XML formats of the UCD data, for regular expression property tests, and for other programmatic textual descriptions of Unicode data. The aliases for properties are defined in PropertyAliases.txt. The aliases for property values are defined in PropertyValueAliases.txt.

Table 17. Alias Files in the UCD

Aliases are defined as ASCII-compatible identifiers, using only uppercase or lowercase A-Z, digits, and underscore "_". Case is not significant when comparing aliases, but the preferred form used in the data files for longer aliases is to titlecase them.

Aliases may be translated in appropriate environments, and additional aliases may be useful in certain contexts. There is no requirement that only the aliases defined in the alias files of the UCD be used when referring to Unicode character properties or their values; however, their use is recommended for interoperability in data formats or in programmatic contexts.

Aliases may be provided for provisional properties. There are stability guarantees for property aliases and property value aliases, but no stability guarantees for provisional properties or other provisional data files; consequently, there can also be no stability guarantee for property aliases or property value aliases associated with provisional properties.

5.8.1 Property Aliases

In PropertyAliases.txt, the first field specifies an abbreviated symbolic name for the property, and the second field specifies the long symbolic name for the property. These are the preferred aliases. Additional aliases for a few properties are specified in the third or subsequent fields.

Aliases for normative and informative properties defined in the Unihan data files are included in PropertyAliases.txt, beginning with Version 5.2.

The long symbolic name alias is self-descriptive, and is treated as the official name of a Unicode character property. For clarity it is used whenever possible when referring to that property in this annex and elsewhere in the Unicode Standard. For example: "The Line_Break property is discussed in Unicode Standard Annex #14, "Unicode Line Breaking Algorithm" [UAX14]."

The abbreviated symbolic name alias is short and less mnemonic, but is useful for expressions such as "lb=BA" in data or in other contexts where the meaning is clear.

The property aliases specified in PropertyAliases.txt constitute a unique name space. When using these symbolic values, no alias for one property will match an alias for another property.

5.8.2 Property Value Aliases

In PropertyValueAliases.txt, the first field contains the abbreviated alias for a Unicode property, the second field specifies an abbreviated symbolic name for a value of that property, and the third field specifies the long symbolic name for that value of that property. These are the preferred aliases. Additional aliases for some property values may be specified in the fourth or subsequent fields. For example, for binary properties, the abbreviated alias for the True value is "Y", and the long alias is "Yes", but each entry also specifies "T" and "True" as additional aliases for that value, as shown in Table 18.

Table 18. Binary Property Value Aliases

Not every property value has an associated alias. Property value aliases are typically supplied for catalog and enumeration properties, which have well-defined, enumerated values. It does not make sense to specify property value aliases, for example, for the Numeric_Value property, whose value could be any number, or for a string property such as Simple_Lowercase_Mapping, whose values are mappings from one code point to another.

The Canonical_Combining_Class property requires special handling in PropertyValueAliases.txt. The values of this property are numeric, but they comprise a closed, enumerated set of values. The more important of those values are given symbolic name aliases. In PropertyValueAliases.txt, the second field provides the numeric value, while the third field contains the abbreviated symbolic name alias and the fourth field contains the long symbolic name alias for that numeric value. For example:

ccc; 230; A    ; Above
ccc; 232; AR   ; Above_Right
  

Taken by themselves, property value aliases do not constitute a unique name space. The abbreviated aliases, in particular, are often re-used as aliases for values for different properties. All of the binary property value aliases, for example, make use of the same "Y", "Yes", "T", "True" symbols. Property value aliases may also overlap the symbols used for property aliases. For example, "Sc" is the abbreviated alias for the "Currency_Symbol" value of the General_Category value, but it is also the abbreviated alias for the Script property. However, the aliases for values for any single property are always unique within the context of that property. That means that expressions that combine a property alias and a property value alias, such as "lb=BA" or "gc=Sc" always refer unambiguously just to one value of one given property, and will not match any other value of any other property.

Prior to Version 6.1.0, the property value alias entries for three properties, Age, Block, and Joining_Group, made use of a special metavalue "n/a" in the field for the abbreviated alias. This should be understood as meaning that no abbreviated alias was defined for that value for that property, rather than as an alias per se. Starting with Version 6.1.0, all property values for those three properties have abbreviated aliases, so there is no current use of the "n/a" metavalue.

In a few cases, because of longstanding legacy practice in referring to values of a property by short identifiers, the abbreviated alias and the long alias are the same. This can be seen, for example, in some property value aliases for the Line_Break property and the Grapheme_Cluster_Break property.

The property Script_Extensions consists of enumerated sets of Script property values. The set of those sets is potentially open-ended, and no property value aliases are defined for them.

5.9 Matching Rules

When matching Unicode character property names and values, it is strongly recommended that all Property and Property Value Aliases be recognized. For best results in matching, rather than using exact binary comparisons, the following loose matching rules should be observed.

5.9.1 Matching Numeric Property Values

For all numeric properties, and for properties such as Unicode_Radical_Stroke which are constructed from combinations of numeric values, use loose matching rule UAX44-LM1 when comparing property values.

UAX44-LM1. Apply numeric equivalences.

• "01.00" is equivalent to "1".
• "1.666667" in the UCD is a repeating fraction, and equivalent to "10/6" or "5/3".

5.9.2 Matching Character Names

Unicode character names constitute a special case. Formally, they are values of the Name property. While each Unicode character name for an assigned character is guaranteed to be unique, names are assigned in such a way that the presence or absence of spaces cannot be used to distinguish them. Furthermore, implementations sometimes create identifiers from Unicode character names by inserting underscores for spaces. For best results in comparing Unicode character names, use loose matching rule UAX44-LM2.

UAX44-LM2. Ignore case, whitespace, underscore ('_'), and all medial hyphens except the hyphen in U+1180 HANGUL JUNGSEONG O-E.

• "zero-width space" is equivalent to "ZERO WIDTH SPACE" or "zerowidthspace"
• "character -a" is not equivalent to "character a"

In this rule "medial hyphen" is to be construed as a hyphen occurring immediately between two letters in the normative Unicode character name, as published in the Unicode names list, and not to any hyphen that may transiently occur medially as a result of removing whitespace before removing hyphens in a particular implementation of matching. Thus the hyphen in the name U+10089 LINEAR B IDEOGRAM B107M HE-GOAT is medial, and should be ignored in loose matching, but the hyphen in the name U+0F39 TIBETAN MARK TSA -PHRU is not medial, and should not be ignored in loose matching.

An implementation of this loose matching rule can obtain the correct results when comparing two strings by doing the following three operations, in order:

1. remove all medial hyphens (except the medial hyphen in the name for U+1180)
2. remove all whitespace and underscore characters
3. apply toLowercase() to both strings

After applying these three operations, if the two strings compare binary equal, then they are considered to match.

This is a logical statement of how the rule works. If programmed carefully, an implementation of the matching rule can transform the strings in a single pass. It is also possible to compare two name strings for loose matching while transforming each string incrementally.

Loose matching rule UAX44-LM2 is also appropriate for matching character name aliases and the names of named character sequences, which share the namespace (and matching behavior) of Unicode character names. See Section 4.8, Name in [Unicode]

Implementations of name matching should use extreme care when matching non-standard, alternative names for particular characters. The Name Uniqueness Policy in the Unicode Consortium Stability Policies [Stability] guarantees that the Unicode Standard will never add a character whose name would match an existing encoded character, according to matching rule UAX44-LM2. However, any other name for a character might be used in the future.

The following is a concrete example of the kind of trouble that can occur. Prior to Unicode 6.0 some implementations of regex allowed matching of the name "BELL" for the control code U+0007. When Unicode 6.0 added a different encoded character, U+1F514 BELL for emoji symbols, those regex implementations broke.

As of Version 6.1 of the Unicode Standard, the most commonly occurring alternative names for control codes, as well as many commonly used abbreviations for Unicode format characters, have been added as character name aliases. This automatically excludes all such alternative names and abbreviations from the potential pool for future Unicode character names, because name uniqueness is defined over the namespace which includes both character names and character name aliases. That exclusion should reduce the potential for surprises similar to the "BELL" case, where implementers assume that a name for a control code is already well-defined.

5.9.3 Matching Symbolic Values

Property aliases and property value aliases are symbolic values. When comparing them, use loose matching rule UAX44-LM3.

UAX44-LM3. Ignore case, whitespace, underscore ('_'), hyphens, and any initial prefix string "is".

• "linebreak" is equivalent to "Line_Break" or "Line-break"
• "lb=BA" is equivalent to "lb=ba" or "LB=BA"
• "Script=Greek" is equivalent to "Script=isGreek" or "Script=Is_Greek"

Loose matching is generally appropriate for the property values of Catalog, Enumeration, and Binary properties, which have symbolic aliases defined for their values. Loose matching should not be done for the property values of String properties, which do not have symbolic aliases defined for their values; exact matching for String property values is important, as case distinctions or other distinctions in those values may be significant.

For loose matching of symbolic values, an initial prefix string "is" is ignored. The reason for this is that APIs returning property values are often named using the convention of prefixing "is" (or "Is" or "Is_", and so forth) to a property value. Ignoring any initial "is" on a symbolic value during loose matching is likely to produce the best results in application areas such as regex. Removal of an initial "is" string for a loose matching comparison only needs to be done once for a symbolic value, and need not be tested recursively. There are no property aliases or property value aliases of the form "isisisisistooconvoluted" defined just to test implementation edge cases.

Existing and future property aliases and property value aliases are guaranteed to be unique within their relevant namespaces, even if an initial prefix string "is" is ignored. The existing cases of note for aliases that do start with "is" are: dt=Iso (Decomposition_Type=Isolated) and lb=IS. The Decomposition_Type value alias does not cause any problem, because there is no contrasting value alias dt=o (Decomposition_Type=olated). For lb=IS, note that the "IS" is the entire property value alias, and is not a prefix. There is no null value for the Line_Break property for it to contrast with, but implementations of loose matching should be careful of this edge case, so that "lb=IS" is not misinterpreted as matching a null value.

Implementations sometimes use other syntactic constructs that interact with loose matching. For example, the property matching expression \p{L} may be defaulted to refer to the Unicode General_Category property: \p{General_Category=L}. For more information about the use of property values in regular expressions and other environments, see Section 1.2, Properties, in Unicode Technical Standard #18, "Unicode Regular Expressions" [UTS18]

5.10 Invariants

Property values in the UCD may be subject to correction in subsequent versions of the standard, as errors are found. Furthermore, any new version of the Unicode Standard may introduce new property values for a given property, except where the set of allowable values is fixed by the property type (such as for binary properties), or where the set of allowable values is subject to a provision of the Unicode Character Encoding Stability Policy [Stability]. Finally, a new version may also introduce new properties or new data files in the UCD.

Implementers of the UCD need to be aware of such changes when updating to new versions. However, some property values and some aspects of the file formats are considered invariant. This section documents such invariants.

5.10.1 Character Property Invariants

All formally guaranteed invariants for properties or property values are described in the Unicode Character Encoding Stability Policy [Stability]. That policy and the list of invariants it enumerates are maintained outside the context of the Unicode Standard per se. They are not part of the standard, but rather are constraints on what can and cannot change in the standard between versions, and on what decisions the Unicode Technical Committee can and cannot take regarding the standard.

In addition to the formally guaranteed invariants described in the Unicode Character Encoding Stability Policy, this section notes a few additional points regarding character property invariants in the UCD.

Some character properties are simply considered immutable: once assigned, they are never changed. For example, a character's name is immutable, because of its importance in exact identification of the character. The Canonical_Combining_Class and Decomposition_Mapping of a character are immutable, because of their importance to the stability of the Unicode Normalization Algorithm [UAX15].

The list of immutable character properties is shown in Table 19.

Table 19. Immutable Properties

In some cases, a property is not immutable, but the list of possible values that it can have is considered invariant. For example, while at least some General_Category values are subject to change and correction, the enumerated set of possible values that the General_Category property can have is fixed and cannot be added to in the future. However, not all Enumeration properties used by Unicode algorithms have immutable lists of property values. For example, the enumerated lists of values associated with the Line_Break and the Word_Break properties have changed in the past, and may be changed again in future versions of the standard.

All characters other than those of General_Category M* are guaranteed to have Canonical_Combining_Class=0. Currently it is also true that all characters other than those of General_Category Mn have Canonical_Combining_Class=0. However, the more constrained statement is not a guaranteed invariant; it is possible that some new character of General_Category Me or Mc could be given a non-zero value for Canonical_Combining_Class in the future.

In Unicode 4.0 and thereafter, the General_Category value Decimal_Number (Nd), and the Numeric_Type value Decimal (de) are defined to be co-extensive; that is, the set of characters having General_Category=Nd will always be the same as the set of characters having NumericType=de.

5.10.2 UCD File Format Invariants

There are also some constraints on allowable change in the file formats for UCD files. In general, the file format conventions are changed as little as possible, to minimize the impact on implementations which parse the machine-readable data files. However, some of the constraints on allowable file format change go beyond conservatism in format and instead have the status of invariants. These guarantees apply in particular to UnicodeData.txt, the very first data file associated with the UCD.

The number and order of the fields in UnicodeData.txt is fixed. Any additional information about character properties to be added to the UCD in the future will appear in separate data files, rather than being added as an additional field to UnicodeData.txt or by reinterpretation of any of the existing fields.

5.10.3 Invariants in Implementations

Applications may wish to take the various character property and file format invariants into account when choosing how to implement character properties.

The Canonical_Combining_Class offers a good example. The character property invariants regarding Canonical_Combining_Class guarantee that values, once assigned, will never change, and that all values used will be in the range 0..254. This means that the Canonical_Combining_Class can be safely implemented in an unsigned byte and that any value stored in a table for an existing character will not need to be updated dynamically for a later version.

In practice, for Canonical_Combining_Class far fewer than 256 values are used. Unicode 3.0 used 53 values; Unicode 3.1 through Unicode 4.1 used 54 values; and Unicode 5.0 through Unicode 8.0 used 55 values. New, non-zero Canonical_Combining_Class values are seldom added to the standard. (For details about this history, see DerivedCombiningClass.txt.) Implementations may take advantage of this fact for compression, because only the ordering of the non-zero values, and not their absolute values, matters for the Canonical Ordering Algorithm. In principle, it would be possible for up to 255 values to be used in the future, but the chances of the actual number of values exceeding 128 are remote at this point. There are implementation advantages in restricting the number of internal class values to 128—for example, the ability to use signed bytes without implicit widening to ints in Java.

5.11 Validation

The Unicode character property values in the UCD files can be validated by means of regular expressions. Such validation can also be useful in testing of implementations that return property values. The method of validation depends on the type of property, as described below. These expressions use Perl syntax, but may of course be converted to other formal conventions for use with other regular expression engines.

The regular expressions which are appropriate for validation of particular properties may change in each subsequent version of the UCD. However, because of stability guarantees for character property aliases, these regular expressions for one version of the Unicode Standard will match valid values for previous versions of the standard.

5.11.1 Enumerated and Binary Properties

Enumerated and binary character properties can be validated by generating a regular expression using the PropertyValueAliases.txt file. Because enumerated properties have a defined list of possible values, the validating regular expression simply ORs together all of the possible values. Binary properties are a special case of enumerated property, with a predefined very short list of possible values.

For example, to validate the East_Asian_Width property in the UCD, or to test an implementation that returns the East_Asian_Width property, parse the following relevant lines from PropertyValueAliases.txt and produce a regular expression that concatenates each of the short and long property alias values.

# East_Asian_Width (ea)

ea ; A         ; Ambiguous
ea ; F         ; Fullwidth
ea ; H         ; Halfwidth
ea ; N         ; Neutral
ea ; Na        ; Narrow
ea ; W         ; Wide
  

The resulting regular expression would then be:

  /A|Ambiguous|F|Fullwidth|H|Halfwidth|N|Neutral|Na|Narrow|W|Wide/
  

For each Unicode binary character property, the regular expression can be precomputed simply as:

  /N|No|F|False|Y|Yes|T|True/
  

The Catalog properties, Age, Block, and Script, are another type of enumerated character property. All possible values of those properties for any given version of the Unicode Standard are listed in PropertyValueAliases.txt, so a validating regular expression for a Catalog property for that given version of the UCD can be generated by concatenating values, as for the other enumerated properties.

5.11.2 Combining_Character_Class Property

The Combining_Character_Class (ccc) property is a hybrid type. The possible values defined for it in UnicodeData.txt range from 0 to 254 and are numeric values. However, Combining_Character_Class also has symbolic aliases defined for those particular values that are in actual use; those symbolic aliases are listed in PropertyValueAliases.txt. To produce a validating regular expression for Combining_Character_Class, concatenate together the symbolic aliases from PropertyValueAliases.txt, and then add the numeric range 0..254.

The value 255 is reserved for use by implementations. When the ccc values are represented by bytes, that additional value of 255 may be used by an implementation for other purposes.

The value 133 is reserved. No characters have that value. The property value alias CCC133 is retained in accordance with the stability policy regarding property value aliases.

5.11.3 Unihan Properties

The validating regular expressions for each property tag defined in the Unihan database are described in detail in [UAX38].

5.11.4 Other Properties

Regular expressions to validate String and Miscellaneous properties in the UCD are provided in Table 21. Although Catalog properties may use strict tests, as described in Section 5.11.1 Enumerated and Binary Properties, generic patterns for Block and Script are also provided in Table 21.

To simplify the presentation of these expressions, commonly occurring subexpressions are first abstracted out as variables defined in Table 20.

Table 20. Common Subexpressions for Validation

The regular expressions listed in Table 21 cover all the straightforward cases for other property values. For properties involving somewhat more irregular values, such as Age, ISO_Comment, and Unicode_1_Name, details for validation can be found in [UAX42].

Table 21. Regular Expressions for Other Property Values

* The names for Unicode named character sequences are not formally Unicode character property values. However, they follow the same syntax as the Name and Name_Alias property values.

5.11.5 Validation of Multivalued Properties

Some properties, such as Script_Extensions of kCantonese, have property values each consisting of a set of element values. In the data files, these element values are separated by spaces. Validation of the property values is performed by first splitting each set into element values at the spaces, and then validating each element value individually. For example, the elements for Script_Extensions are values of the Script property; they are validated according to the validation requirements for the Script property. See also Section 5.7.6 Properties Whose Values Are Sets of Values.

The Name_Alias property has values which consist of sets of one or more name strings. In the data file for this property, each element value occurs on a separate line and can be validated as a separate element.

5.12 Deprecation

In the Unicode Standard, the term deprecation is used somewhat differently than it is in some other standards. Deprecation is used to mean that a character or other feature is strongly discouraged from use. This should not, however, be taken as indicating that anything has been removed from the standard, nor that anything is planned for removal from the standard. Any such change is constrained by the Unicode Consortium Stability Policies [Stability].

For the Unicode Character Database, there are two important types of deprecation to be noted. First, an encoded character may be deprecated. Second, a character property may be deprecated.

When an encoded character is strongly discouraged from use, it is given the property value Deprecated=True. The Deprecated property is a binary property defined specifically to carry this information about Unicode characters. Very few characters are ever formally deprecated this way; it is not enough that a character be uncommon, obsolete, disliked, or not preferred. Only those few characters which have been determined by the UTC to have serious architectural defects or which have been determined to cause significant implementation problems are ever deprecated. Even in the most severe cases, such as the deprecated format control characters (U+206A..U+206F), an encoded character is never removed from the standard. Furthermore, although deprecated characters are strongly discouraged from use, and should be avoided in favor of other, more appropriate mechanisms, they may occur in data. Conformant implementations of Unicode processes such a Unicode normalization must handle even deprecated characters correctly.

In the Unicode Character Database, a character property may also become strongly discouraged—usually because it no longer serves the purpose it was originally defined for. In such cases, the property is labelled "deprecated" in Table 9, Property Table. For example, see the Grapheme_Link property.

6 Test Files

The UCD contains a number of test data files. Those provide data in standard formats which can be used to test implementations of Unicode algorithms. The test data files distributed with this version of the UCD are listed in Table 22.

Table 22. Unicode Algorithm Test Data Files

The normative status of these test files reflects their use to determine the correctness of implementations claiming conformance to the respective algorithms listed in the table. There is no requirement that any particular Unicode implementation also implement the Unicode Line Breaking Algorithm, for example, but if it implements that algorithm correctly, it should be able to replicate the test case results specified in the data entries in LineBreakTest.txt.

6.1 NormalizationTest.txt

This file contains data which can be used to test an implementation of the Unicode Normalization Algorithm. (See [UAX15] and [Tests15].)

The data file has a Unicode string in the first field (which may consist of just a single code point). The next four fields then specify the expected output results of converting that string to Unicode Normalization Forms NFC, NFD, NFKC, and NFKD, respectively. There are many tricky edge cases included in the input data, to ensure that implementations have correctly implemented some of the more complex subtleties of the Unicode Normalization Algorithm.

The header section of NormalizationTest.txt provides additional information regarding the normalization invariant relations that any conformant implementation should be able to replicate.

The Unicode Normalization Algorithm is not tailorable. Conformant implementations should be expected to produce results as specified in NormalizationTest.txt and should not deviate from those results.

6.2 Segmentation Test Files and Documentation

LineBreakTest.txt, located in the auxiliary directory of the UCD, contains data which can be used to test an implementation of the Unicode Line Breaking Algorithm. (See [UAX14] and [Tests14].) The header of that file specifies the data format and the use of the test data to specify line break opportunities. Note that non-ASCII characters are used in this test data as field delimiters.

There is an associated documentation file, LineBreakTest.html, which displays the results of the Line Breaking Algorithm in an interactive chart form, with a documented listing of the rules.

The Unicode text segmentation test data files are also located in the auxiliary directory of the UCD. (See [Tests29].) They contain data which can be used to test an implementation of the segmentation algorithms specified in [UAX29]. The headers of those file specify the data format and the use of the test data to specify text segmentation opportunities. Note that non-ASCII characters are used in this test data as field delimiters.

There are also associated documentation files, which display the results of the segmentation algorithms in an interactive chart form, with a documented listing of the rules:

• GraphemeBreakTest.html
• SentenceBreakTest.html
• WordBreakTest.html

Unlike the Unicode Normalization Algorithm, the Unicode Line Breaking Algorithm and the various text segmentation algorithms are tailorable, and there is every expectation that implementations will tailor these algorithms to produce results as needed. The test data files only test the default behavior of the algorithms. Testing of tailored implementations will need to modify and/or extend the test cases as appropriate to match any documented tailoring.

6.3 Bidirectional Test Files

These files contain data which can be used to test an implementation of the Unicode Bidirectional Algorithm. (See [UAX9] and [Tests9].)

The data in BidiTest.txt is intended to exhaustively test all possible combinations of Bidi_Class values for strings of length four or less. To allow for the resulting very large number of test cases, the data file has a somewhat complicated format which is described in the header. Fundamentally, for each input string and for each possible input paragraph level, the test data specifies the resulting bidi levels and expected reordering.

The data in BidiCharacterTest.txt is provided to test various edge cases for the algorithm. It contains an extra field which allows for explicit control of the overall directional context for each test case.

The Unicode Bidirectional Algorithm is tailorable within certain limits. Conformant implementations with no tailoring are expected to produce the results as specified in BidiTest.txt and should not deviate from those results. Tailored implementations can also use the data in BidiTest.txt to test for overall conformance to the algorithm by changing the assignment of properties to characters to reflect the details of their tailoring.

7 UCD Change History

This section summarizes the recent changes to the UCD—including its documentation files—and is organized by Unicode versions.

References in the change history are often made to a Public Review Issue (PRI). See http://www.unicode.org/review/resolved.html for more information about each of those cases.

Unicode 8.0.0

Changes in specific files:

Appropriate data files were updated to add the 7,716 new characters encoded in Unicode 8.0, which consist of 5,771 CJK unified ideographs and 1,945 other characters. Major changes that are most likely to affect implementations are documented in Section F of the Unicode 8.0.0 page. Detailed data file updates resulting from encoding the new characters and from various character property changes are summarized below, in the same grouping manner used in Components of Unicode 8.0.0.

Note that minor editorial updates and changes to the derived and extracted data files are not documented here.

Core Data

• ArabicShaping.txt
  • The Joining_Type property values were corrected for two Mandaic characters, which had been inadvertently reversed in previous versions.
  • Entries were added for two newly encoded Arabic letters used in Arwi.
• Blocks.txt
  • A total of ten new blocks were added, including six blocks for as many new scripts, one block of lowercase Cherokee syllables, and extension blocks for CJK unified ideographs, Cuneiform signs from the Early Dynastic period, and pictographic symbols.
• EastAsianWidth.txt
  • The new CJK unified ideographs were assigned the East_Asian_Width property value Wide.
  • All of the other new characters were assigned the East_Asian_Width property value Neutral.
• IndicPositionalCategory.txt (renamed from the provisional IndicMatraCategory.txt)
  • Editorial updates were made as a result of the renaming of the property from Indic_Matra_Category to Indic_Positional_Category and its promotion to informative status.
  • The restrictions by which, in previous versions, only characters of certain Indic_Syllabic_Category property values were assigned nondefault values in this file were lifted, and numerous characters were added to the Indic_Positional_Category classification, including non-vocalic marks such as nuktas, bindus, svaras, and subjoined consonants.
  • The four New Tai Lue pre-base vowel signs, U+19B5..U+19B7 and U+19BA, were assigned the Indic_Positional_Category property value Visual_Order_Left, by derivation from the Logical_Order_Exception property, set as part of the change in encoding model for New Tai Lue to visual order.
• IndicSyllabicCategory.txt
  • Editorial updates were made as a result of the promotion of the Indic_Syllabic_Category property to informative status.
  • Four new Indic_Syllabic_Category property values were added: Consonant_Prefixed and Consonant_With_Stacker, for consonants that form stacked conjuncts without the use of a virama; Consonant_Killer, for marks that cancel the pronunciation of a consonant; and Syllable_Modifier, for other modifiers of orthographic syllables, including superscripts and subscripts used in transliteration.
  • Several previously encoded characters were assigned nondefault property values for the first time, and a few were reclassified.
  • Characters in the two newly encoded Indic scripts, Ahom and Multani, as well as new characters of existing Indic scripts, were added with appropriate property values.
  • Two punctuation marks, U+2010 HYPHEN and U+2011 NON-BREAKING HYPHEN, were assigned the Indic_Syllabic_Category property value Consonant_Placeholder, for their use as generic bases for the placement of nonspacing combining marks.
• LineBreak.txt
  • The Line_Break property value of U+22EF MIDLINE HORIZONTAL ELLIPSIS was changed from Alphabetic to Inseparable, to prevent line breaks between ideographic characters and U+22EF.
• NameAliases.txt
  • Formal name aliases of type correction were added for two arrow symbols, U+2B7A and U+2B7C.
• NamedSequencesProv.txt
  • Provisional named character sequences were added for 12 combining character sequences representing keycaps on telephone keypads, used in emoji contexts.
• NamesList.txt
  • Content was updated with new characters, as well as annotations, cross references, subheadings, and remarks.
• PropertyAliases.txt
  • The property formerly named Indic_Matra_Category was renamed Indic_Positional_Category and its short alias changed accordingly from InMC to InPC.
• PropertyValueAliases.txt
  • The 8.0 value was added to the catalog property Age.
  • Script and Block property values were added for the six new scripts and ten new blocks introduced.
  • The section for Indic_Positional_Category was updated to reflect the renaming from Indic_Matra_Category.
  • Entries were added for four new Indic_Syllabic_Category property values.
• PropList.txt
  • Several new characters were assigned appropriate binary properties Diacritic, STerm, Terminal_Punctuation, or the contributory Other_Alphabetic.
  • The newly encoded CJK unified ideographs were assigned the Ideographic and Unified_Ideograph properties.
  • The four New Tai Lue pre-base vowel signs, U+19B5..U+19B7 and U+19BA, were assigned the Logical_Order_Exception property, as they precede their associated consonants in the new, visual order encoding model for New Tai Lue.
  • The Other_Alphabetic assignment of all New Tai Lue vowels signs and tone marks was removed, as it became redundant for their classification as Alphabetic, which derives directly from the new General_Category property values of those characters in the visual order encoding model.
  • All of the assigned characters in the Tags block, except for the stateful controls U+E0001 LANGUAGE TAG and U+E007F CANCEL TAG, were reinstated to non-deprecated, for use in emoji contexts.
• Scripts.txt
  • The new characters were assigned appropriate Script property values, including six new values for the newly encoded scripts.
  • The Script property value of the Arabic-Indic digits U+0660..U+0669 was changed from Common to Arabic, as these characters are manifestly Arabic. Characters primarily associated with a specific script may keep an explicit Script property value and be shared across different scripts, without having to be assigned a generic Script property value such as Common, as established by the new stability policy applying to the Script and Script_Extensions properties.
• ScriptExtensions.txt
  • Entries were added for several Vedic recitation and nasalization marks, whose Script property values are mostly Common or Inherited, which are primarily used with Devanagari or shared among multiple Indic scripts.
  • Entries were added for Tamil numerals and two Tamil letters that are unified with numerals, all also used with Grantha; for Gurmukhi digits also used with Multani; and for counting rod numerals primarily used with Han.
  • Other entries were added for a few Cyrillic combining marks which are also used with Glagolitic or Old Permic letters.
• UnicodeData.txt
  • Entries were added for the 7,716 new characters, including case pairs and cased letters which form case pairs with previously encoded letters.
  • The new characters include a total of 5,771 CJK unified ideographs, of which 9 were allocated at the end of the CJK Unified Ideographs block, thus changing the last assigned code point in that block from U+9FCC to U+9FD5.
  • The General_Category property values of all existing Cherokee syllables, U+13A0..U+13F4, were changed from Other_Letter to Uppercase_Letter, as part of the change in encoding model for Cherokee to a bicameral script.
  • The newly encoded lowercase Cherokee syllables U+13F8..U+13FC and U+AB70..U+ABBF were assigned the General_Category property value Lowercase_Letter, and case mappings were created between them and the existing syllables.
  • Entries were also added for the newly encoded case pair, U+13F5 and U+13FD, for the archaic Cherokee syllable mv.
  • The General_Category property values of all new Tai Lue vowels signs and tone marks were changed from Spacing_Mark to Other_Letter, as part of the change in encoding model for New Tai Lue to visual order.

Unihan Database (Unihan.zip)

• Unihan_IRGSources.txt
  • Over 2,800 values of the normative kIRG_JSource field were updated to reflect the more contemporary JIS X 0213:2004 (J3, J3A, and J4) source references, replacing outdated JIS X 0212-1990 (J1) and "Unified Japanese IT Vendors Contemporary Ideographs" (JA) source references.
  • IRG source field values and kRSUnicode radical-stroke counts were defined for the 9 new ideographs added to the CJK Unified Ideographs block, U+9FCD..U+9FD5, and for the 5,762 ideographs assigned in the new block CJK Unified Ideographs Extension E, in the range U+2B820..U+2CEA1.
  • A few other IRG source field values were added or removed.
• Unihan_OtherMappings.txt
  • A new provisional field, kJa, was introduced for source identification in "Unified Japanese IT Vendors Contemporary Ideographs" (JA).
  • kJa field values were added for a few of the ideographs whose former kIRG_JSource values had been JA source in Unihan_IRGSources.txt.
• Unihan_Readings.txt
  • Entries with definitions and pronunciations were added for the new ideographs in the main CJK Unified Ideographs block, and a few other entries were added or updated.
• Unihan_Variants.txt
  • kSimplifiedVariant and kTraditionalVariant mappings were added for some of the new characters in the CJK Unified Ideographs block, and a few other variant relationship mappings were added.

Data for UAX #45

• USourceData.txt
  • A few ideographs from the UNC-2013 set which were submitted for Extension F were labeled accordingly.
  • Three U-source ideographs were added, UTC-01199 for tracking the source of U+2F949 following character disunification, and UTC-01200 and UTC-01201 for two urgently needed characters.
• USourceGlyphs.txt
  • Three glyphs were added for the new U-source ideographs, UTC-01199 through UTC-01201.

Conformance Test Data

• NormalizationTest.txt
  • Test cases were added with sequences containing newly encoded characters which are nonspacing combining marks with nonzero Canonical_Combining_Class values.

Auxiliary Data for UAX #14 and UAX #29

• GraphemeBreakProperty.txt
  • The newly encoded combining marks were assigned the Grapheme_Cluster_Break property values Extend and SpacingMark, by derivation from their General_Category property values.
  • The four New Tai Lue pre-base vowel signs, U+19B5..U+19B7 and U+19BA, changed their Grapheme_Cluster_Break property values from SpacingMark to Other, as a result of the change in encoding model for New Tai Lue to visual order.
• LineBreakTest.txt
  • Test cases were updated in accordance with the new rule LB21b and the updated rule LB22 of the Unicode Line Breaking Algorithm.
  • The exemplar character for the Line_Break property value Unknown was changed from U+E000 to U+50005, to avoid using a Private Use Area character and also to exercise a supplementary code point.
  • A test case was added for coverage of rule LB21a of the Unicode Line Breaking Algorithm.
• SentenceBreakProperty.txt
  • New characters were assigned Sentence_Break property values by derivation from their primary property values.
  • The existing Cherokee syllables, U+13A0..U+13F4, changed their Sentence_Break property values from OLetter to Upper, as a result of the change in encoding model for Cherokee to a bicameral script.
  • All New Tai Lue vowels signs and tone marks changed their Sentence_Break property values from Extend to OLetter, as a result of the change in encoding model for New Tai Lue to visual order.
• SentenceBreakTest.txt
  • Test cases were added for verifying sentence boundaries in sequences of the form <letter, period, letter> in all case combinations for letter, which include coverage of rule SB7 of the Sentence Boundary Algorithm, modified in Unicode 8.0.
  • Two other test cases were added for coverage of rule SB10 of the Sentence Boundary Algorithm.
• WordBreakProperty.txt
  • New characters were assigned the Word_Break property values ALetter, Extend, and Numeric, by derivation from other property values.
  • All New Tai Lue vowels signs and tone marks changed their Word_Break property values from Extend to Other, as a result of the change in encoding model for New Tai Lue to visual order.
• WordBreakTest.txt
  • A collection of over 100 test cases was added, based on tests previously suggested in user feedback.
  • A few other test cases were added for verifying word boundaries in sequences of the form <letter, period, letter> in all case combinations for letter.
  • A test case was added for coverage of rules WB7b and WB7c of the Word Boundary Algorithm.

Documentation for Auxiliary Data

• LineBreakTest.html
  • In the list of rules, entries were added corresponding to the new rule LB21b and the updated rule LB22 of the Unicode Line Breaking Algorithm.
  • In the pair table, the exemplar character for the Line_Break property value Unknown was changed from U+E000 to U+50005.
  • A test case was added for coverage of rule LB21a of the Unicode Line Breaking Algorithm.
• SentenceBreakTest.html
  • The statements of the rules were updated to match those in the Sentence Boundary Algorithm as defined in Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29].
  • Test cases were added for verifying sentence boundaries in sequences of the form <letter, period, letter> in all case combinations for letter, which include coverage of rule SB7 of the Sentence Boundary Algorithm, modified in Unicode 8.0.
  • Two other test cases were added for coverage of rule SB10 of the Sentence Boundary Algorithm.
• WordBreakTest.html
  • The statements of the rules were updated to match those in the Word Boundary Algorithm as defined in Unicode Standard Annex #29, "Unicode Text Segmentation" [UAX29].
  • In particular, the statement of rule 7.3 was corrected to match rule WB7c of the Word Boundary Algorithm.
  • A few test cases were added for verifying word boundaries in sequences of the form <letter, period, letter> in all case combinations for letter.
  • A test case was added for coverage of rules WB7b and WB7c of the Word Boundary Algorithm.

Unicode 7.0.0

Changes in specific files:

Appropriate data files were updated to include the 2,834 new characters added in Unicode 7.0. Major changes that are most likely to affect implementations are documented in Section F of the Unicode 7.0.0 page. Detailed data file updates resulting from encoding the new characters and from various character property changes are summarized below, in the same grouping manner used in Components of Unicode 7.0.0.

Note that minor editorial updates and changes to the derived and extracted data files are not documented here.

Core Data

• ArabicShaping.txt
  • Entries were added for two new cursive scripts with complex shaping behavior, Manichaean and Psalter Pahlavi.
  • New Joining_Group property values were defined for Manichaean letters.
  • Two Manichaean letters have the Joining_Type property value L, which was previously assigned to only one Phags-pa character.
• Blocks.txt
  • A total of 32 new blocks were added, including 23 blocks for as many new scripts, one block of shorthand format controls used with Duployan, and extended blocks for Latin, Myanmar, combining diacritical marks, geometric shapes, and arrows.
• EastAsianWidth.txt
  • All of the 2,834 new characters were assigned the East_Asian_Width property value N.
• IndicMatraCategory.txt
  • The provisional property Indic_Matra_Category was relaxed to allow characters other than dependent vowels and viramas to have nondefault property values.
  • The property value Invisible was eliminated, and the corresponding characters defaulted to the Indic_Matra_Category property value NA.
• IndicSyllabicCategory.txt
  • The provisional property Indic_Syllabic_Category was significantly revised in support for a more extensible, algorithmic rendering of Indic scripts.
  • The former property value Consonant_Repha was replaced by two new values, Consonant_Preceding_Repha and Consonant_Succeeding_Repha.
  • Two new property values, Pure_Killer and Invisible_Stacker, were introduced to accompany the existing value Virama and allow for a more granular classification of viramas into sets of characters that only suppress the inherent vowel, only create subjoined forms of consonants, or have either role.
  • The viramas that had previously had the Indic_Matra_Category property value Invisible were assigned the Indic_Syllabic_Category property value Invisible_Stacker.
  • Other new property values were defined for joining behavior, numbers, and gemination and cantillation marks.
• LineBreak.txt
  • The 2,834 new characters were added with appropriate Line_Break property values.
  • The Line_Break property values of the floor and ceiling characters, U+2308..U+230B, were changed from AL to either OP or CL, in accordance with their treatment as opening and closing bracket characters.
  • The Line_Break property values of two ornamental quotation marks, U+275F..U+2760, were updated from AL to QU for consistency with similar characters.
  • The Line_Break property values of the ornate parentheses, U+FD3E..U+FD3F, which do not mirror and are input visually, were swapped to reflect their usage in RTL contexts.
• NameAliases.txt
  • The documentation in the comment sections has been revised to describe the types of formal name aliases in detail.
• NamesList.txt
  • Entries were added for the 2,834 new characters.
  • Content was updated with annotations, cross references, subheadings, and remarks.
• PropertyValueAliases.txt
  • The 7.0 value was added to the catalog property Age.
  • New Script and Block property values were added for the 23 new scripts and 32 new blocks introduced.
  • Multiple Joining_Group property values were added for Manichaean and one for Arabic.
  • The provisional properties Indic_Syllabic_Category and Indic_Matra_Category were revised by adding, splitting, and removing property values.
  • @missing directives were added for the default values of the General_Category, Lowercase_Mapping, Titlecase_Mapping, and Uppercase_Mapping properties.
  • The @missing directives for the default values of Bidi_Paired_Bracket_Type and Jamo_Short_Name were moved to the end of the enumerations of value aliases for those properties, to enable single-pass parsing.
• PropList.txt
  • Several new characters were assigned binary properties such as Dash, Diacritic, Extender, Quotation_Mark, STerm, or Terminal_Punctuation.
  • The binary property STerm was removed from two Armenian characters, U+055C and U+055E, which are tonal punctuation marks rather than sentence-final punctuation marks.
  • The Philippine and Kharoshthi danda characters, U+1735..U+1736 and U+10A56..U+10A57, were assigned the binary property Terminal_Punctuation, establishing a proper inclusion of the set of STerm characters in the set of Terminal_Punctuation characters.
  • Contributory binary properties Other_Alphabetic, Other_Lowercase, and Other_Grapheme_Extend were assigned to several new characters.
  • The contributory binary property Other_Uppercase was assigned to the three ranges of enclosed capital Latin alphabetic symbols, U+1F130..U+1F149, U+1F150..U+1F169, and U+1F170..U+1F189. See the resolution of PRI #251.
• Scripts.txt
  • Entries were added for the 2,834 new characters, including those in the 23 new scripts.
  • The Script property value of U+061C ARABIC LETTER MARK (ALM) was changed from Arabic to Common for consistent treatment with the similar bidirectional controls LRM and RLM.
  • The Script property value of U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM was changed from Common to Arabic.
  • The Script property value of U+A92E KAYAH LI SIGN CWI was changed from Kayah_Li to Common, as the character is shared between the scripts used to write the Kayah Li language.
• ScriptExtensions.txt
  • Additional Script property values were assigned to the Script_Extensions of the danda punctuation marks, U+0964..U+0965, and the common Indic number forms, U+A830..U+A839, which are shared across multiple Indic scripts.
  • Additional Script property values were assigned to the extender U+0640 ARABIC TATWEEL, for its use with the two new cursive scripts, Manichaean and Psalter Pahlavi.
  • Single-script entries were introduced for two new Vedic tone marks, U+1CF8..U+1CF9, and the new shorthand format control characters, U+1BCA0..U+1BCA3.
  • Multiple-script entries were introduced for the new Coptic epact mark and numerals, U+102E0..U+102FB, and for U+A92E KAYAH LI SIGN CWI.
  • New entries were added for Devanagari and Gujarati digits, which are used with more than one Indic script.
  • The entry for U+061C ARABIC LETTER MARK (ALM) was eliminated.
  • The description of the file contents was clarified.
• UnicodeData.txt
  • Entries were added for the 2,834 new characters, including case pairs and uppercase letters which form case pairs with previously encoded lowercase letters.
  • The General_Category and Bidi_Class property values of two Sundanese characters, U+1BAC..U+1BAD, were corrected to classify them as nonspacing marks.
  • The General_Category property values of the ornate parentheses, U+FD3E..U+FD3F, which do not mirror and are input visually, were swapped to reflect their usage in RTL contexts.

Unihan Database (Unihan.zip)

• Unihan_DictionaryIndices.txt
  • One dictionary index was added for U+231C0.
• Unihan_IRGSources.txt
  • The Unihan database fields kRSUnicode and kCompatibilityVariant were relocated to this file, together with all corresponding entries, including those with multiple radical-stroke counts.
  • The syntax of the kIICore field was significantly modified. All of the data values for this field were updated. The older format specified "2.1" uniformly as a version indicator for IICore. The updated syntax uses a two-part tag specifying priority and source for members of the IICore set, to synchronize with ISO/IEC 10646 data. Particulars are detailed in [UAX38].
  • In the kIRG_HSource fields, the H3 prefix was changed to H.
  • A few entries with kIRG_GSource fields were updated or removed.
• Unihan_RadicalStrokeCounts.txt
  • The Unihan database field kRSUnicode was deleted from this file and moved to Unihan_IRGSources.txt.
• Unihan_Readings.txt
  • Nearly 3,000 entries were added with kCantonese pronunciation fields.
  • A few entries with kDefinition, kHanyuPinlu, and kMandarin fields were added or updated.
• Unihan_Variants.txt
  • The Unihan database field kCompatibilityVariant was deleted from this file and moved to Unihan_IRGSources.txt.
  • A few entries were added or corrected.

Data for UAX #45

• USourceData.txt
  • The ideographs included in Extension E were given proposed code points and a few entries were corrected.
  • The ideographs from the UNC-2013 set which were submitted for Extension F were labeled accordingly.
  • In several Extension F entries, the IDS values which contained a question mark were aligned with the documented syntax.
  • One U-source ideograph was added, UTC-01198.
• USourceGlyphs.txt
  • A glyph for the new U-source ideograph, UTC-01198, was added.

Conformance Test Data

• NormalizationTest.txt
  • Several test cases were added, with sequences that include new characters such as combining diacritical marks, cased letters, or characters with decomposition mappings.

Auxiliary Data for UAX #14 and UAX #29

• GraphemeBreakProperty.txt
  • Entries were added to the Grapheme_Cluster_Break property values Control, Extend, and SpacingMark, resulting by derivation from primary property assignments.
  • The spacing combining mark U+AA7D MYANMAR SIGN TAI LAING TONE-5 was explicitly excluded from being assigned the Grapheme_Cluster_Break property value SpacingMark by default.
• SentenceBreakProperty.txt
  • Entries were added to various Sentence_Break property values, resulting by derivation from primary property assignments for new characters or changes in primary properties of existing characters.
• WordBreakProperty.txt
  • Entries were added to various Word_Break property values, resulting by derivation from primary property assignments for new characters or changes in primary properties of existing characters.

Acknowledgments

Mark Davis and Ken Whistler are the authors of the initial version and have added to and maintained the text of this annex. Laurențiu Iancu assisted in the documentation of UCD changes for Versions 6.3.0, 7.0.0, and 8.0.0. Julie Allen and Asmus Freytag provided editorial suggestions for improvement of the text. Over the years, many members of the UTC have participated in the review of the UCD and its documentation.

References

For references for this annex, see Unicode Standard Annex #41, "Common References for Unicode Standard Annexes."

Modifications

The following summarizes modifications from previous revisions of this annex.

Revision 16 [KW, LI]

• Reissued for Unicode 8.0.0.
• Removed old UCD Change History entry for Unicode 6.3.0, and added new one for Unicode 8.0.0.
• Clarified the intent for the information contained in Table 9 in Section 5.3 Property Definitions.
• Updated table styles.
• Renamed Indic_Matra_Category to Indic_Positional_Category, with corresponding change in the file name.
• Changed Indic_Syllabic_Category and the renamed Indic_Positional_Category from Provisional to Informative status.
• Added information about location of UCD.zip and the URL for zipped/latest.

Revision 15 being a proposed update, only changes between versions 16 and 14 are noted here.

Revision 14 [KW, LI]

• Reissued for Unicode 7.0.0.
• Removed old UCD Change History entry for Unicode 6.2.0, and added new one for Unicode 7.0.0.
• Updated chapter references for Unicode 7.0.0.
• Updated the derivation of the Alphabetic property.
• Updated the derivation of the Case_Ignorable property.
• Simplified the discussion of @missing in Section 4.2.10 @missing Conventions, to reflect the revised conventions in the UCD data files, which eliminated special edge cases.
• Corrected statement about aliases for provisional properties in Section 5.8 Property and Property Value Aliases.
• Minor editing.

Revision 13 being a proposed update, only changes between versions 14 and 12 are noted here.

Revision 12 [KW, LI]

• Reissued for Unicode 6.3.0.
• Removed old UCD Change History entry for Unicode 6.1.0, and added new one for Unicode 6.3.0.
• Added a clarification about Numeric_Type=Digit.
• Added documentation of default values for Line_Break, added additional default values for Bidi_Class, and clarified the usage of @missing in Section 4.2.9 Default Values.
• Added new Section 4.2.10 @missing Conventions, to spell out syntax and other issues for @missing lines in more detail.
• Clarified the status of default values in Section 5.4 Derived Extracted Properties.
• Added information about the derived status of kCompatibilityVariant in Section 5.7.3 Character Decomposition Mapping.
• Added an entry for BidiBrackets.txt and two new bidi properties to Table 9. Property Table and relevant links elsewhere.
• Added BidiCharacterTest.txt to the list of test data files and provided a brief description of its contents in Section 6.3 Bidirectional Test Files.
• Added new isolate controls to Table 13. Bidi_Class Values and reordered entries to match the listing in UAX #9.
• Added documentation about the new permalink for the latest UCD release, in Section 4.1 Directory Structure.

Revision 11 being a proposed update, only changes between versions 12 and 10 are noted here.

Revision 10 [KW]

• Reissued for Unicode 6.2.0.
• Removed old UCD Change History entry for Unicode 6.0.0, and added new one for Unicode 6.2.0.
• Updated status of Script_Extensions to informative.
• Updated type of Bidi_Mirroring_Glyph from String to Miscellaneous.
• Marked Unicode_1_Name as Obsolete and updated its documentation.
• Added text indicating that the UTC must approve any change to normative or informative property values, in Section 2.3.1 Changes to Properties Between Releases.
• Corrected numbering error for Section 2.3.4 Stabilized Properties.
• Updated the note about NamesList.txt being encoded in Latin-1, because starting with Version 6.2.0, it is encoded in UTF-8. See Section 4.2.11 Text Encoding.
• Added indication that ccc=133 is reserved in Section 5.11.2 Combining_Character_Class Property.
• Added Section 3.6 U-Source Ideographs and UAX #45.
• Added entries to Table 5 for USourceData.txt and USourceGlyphs.pdf.
• Removed entry for ScriptExtensions.txt from Table 5.

Revision 9 being a proposed update, only changes between versions 10 and 8 are noted here.

Revision 8 [KW]

• Reissued for Unicode 6.1.0.
• Removed old UCD Change History entry for Unicode 5.2.0, and added new one for Unicode 6.1.0.
• Added details of data file changes for Unicode 6.1.0.
• Updated derivation of Default_Ignorable_Code_Point to account for U+0604.
• Added a clarification about empty field values in data files for string properties in a new Section 4.2.10 Empty Fields.
• Added a warning about matching alternative, non-standard names in Section 5.9 Matching Rules.
• Added new Section 4.2.8 Multiple Values for Properties.
• Added new Section 5.7.6 Properties Whose Values Are Sets of Values.
• Added documentation of symbolic labels for fixed position canonical combining classes in Table 15.
• Updated wording regarding addition of new property values in Section 5.10 Invariants.
• Corrected URL for the Resolved PRI page reference.
• Added a paragraph about aliases of the form "Ccc10" for fixed position classes in Canonical Combining Class Values.
• Clarified the current status of the "n/a" metavalue for PropertyValueAliases.txt, in Property and Property Value Aliases.
• Updated regex in Table 20 and Table 21.
• Updated the description of the Name_Alias property, to account for new types of formal name aliases now included in NameAliases.txt.
• Added new Section 5.11.5 Validation of Multivalued Properties.
• Added new entry for Script_Extensions in the Property Table.
• Updated Invariants in Implementations and related sections to reflect change in range for Canonical_Combining_Class from 0..255 to 0..254.
• Added note to Combining_Character_Class Property regarding implementation use of reserved value 255.
• Added a gray background to entries for contributory properties in the Property Index.
• Added documentation regarding abbreviations and long aliases for General_Category groupings in Table 12. General_Category Values.
• Corrected several numerical references to definitions related to casing properties in Table 9. Property Table.
• Added information regarding longest canonical and compatibility mappings in 5.7.3 Character Decomposition Mapping.
• Updated status of Grapheme_Base and Grapheme_Extend to normative and corrected their descriptions in Table 9. Property Table.
• Added clarification regarding edge case treatment for Other_Punctuation, Other_Symbol, etc. in 5.7.1 General Category Values
• Added a description and example of the form of derived property definitions in 2.1 Simple and Derived Properties.
• Various small editorial fixes.

Revision 7 being a proposed update, only changes between versions 8 and 6 are noted here.

Revision 6 [KW]

• Reissued for Unicode 6.0.0.
• Removed old UCD Change History entries prior to Unicode 5.2.0.
• Updated status of Hyphen and ISO_Comment properties to Deprecated.
• Updated status of several derived normalization properties to Deprecated.
• Added tables listing Deprecated and Stabilized properties.
• Extended the discussion of the significance of the Bidi_Mirroring_Glyph property.
• Clarified the intended application of the Ideographic and Unified_Ideograph properties.
• Moved Property Summary to top of Section 5, renamed it to Property Index, and adjusted Section 5 numbering.
• Renumbered tables to account for two table insertions.
• Rewrote the description of the Logical_Order_Exception and White_Space properties for clarity.
• Added clarification for UAX44-LM2 in Matching Rules.
• Updated matching rule UAX44-LM3 to ignore initial "is" in Matching Rules.
• Added U+110BD to the list of exceptions to the derivation of Default_Ignorable_Code_Point.
• Added anchors to the matching rules.
• Updated the description fields for FC_NFKC_Closure and NFKC_Casefold.
• Added entries for EmojiSources.txt and ScriptExtensions.txt to Table 5.
• Added entries for Indic_Syllabic_Category and Indic_Matra_Category.
• Added note clarifying that aliases are not provided for provisional properties in Section 5.8.
• Added clarification on value ranges and other restrictions for decimal digits in discussion of Numeric_Type.
• Miscellaneous minor point edits.

Revision 5 being a proposed update, only changes between versions 6 and 4 are noted here.

Revision 4 [KW]

• Reissued for Unicode 5.2.0.
• Completely reorganized and rewritten, to include all the content from the obsoleted UCD.html.
• Added Section 5.10 re deprecation.
• Added subsection in Section 4.2 re line termination conventions.
• Added Contributory as a formal status and updated the Property Table accordingly.
• Added note in Section 5.3.1 to indicate that contributory properties are neither normative nor informative.
• Updated documentation for default values.
• Cleaned up description of numeric properties.
• Tweaked the description of NamesList.html.
• Miscellaneous minor point edits.
• Updated summary statement of the document.
• Centered tables.
• Added anchors and numbers to tables and adjusted text referencing tables accordingly.
• Added clarifications about exceptional format issues for Unihan data files.
• Updated references to Section 4.8, Name—Normative for derived names and for code point labels.
• Added mention of property aliases from Unihan data files to Section 5.6.1.
• Added documentation for new derived properties: Cased, Case_Ignorable, Changes_When_Lowercased, Changes_When_Uppercased, Changes_When_Titlecased, Changes_When_Casefolded, Changes_When_Casemapped, NFKC_Casefold, and Changes_When_NFKC_Casefolded.
• Added strong pointers to Section 3.5 and Chapter 4 of [Unicode] in the Introduction.
• Added new Section 2.3.1, Changes to Properties Between Releases.
• Updated default values for East_Asian_Width.
• Clarified the applicability of comments in cases where properties have multiple default values.
• Restructured Section 5.1 documentation of columns in the property table, for better text flow.
• Reordered entries for DerivedCoreProperties.txt in the property table, for clarity.
• Added documentation of new test file: BidiTest.txt.
• Updated terminology related to the Unihan Database.
• Added documentation for the new data file, CJKRadicals.txt.
• Added Attached_Above for ccc=214 in Table 13.
• Complete revision of Validation section and associated tables.
• Minor revision of text in Section 4.1.5, File Directory Differences for Early Releases.
• Added a cautionary note about the use of the Age property in regular expressions.
• Added sections explaining obsolete, deprecated, and stabilized properties, and clearly identified existing such properties in the property table.

Revision 3 being a proposed update, only changes between versions 4 and 2 are noted here.

Revision 2

• Initial approved version for Unicode 5.1.0.

Revision 1

• Initial draft.

---

Copyright © 2000-2015 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. The Unicode Terms of Use apply.

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