![[Unicode]](http://www.unicode.org/webscripts/logo60s2.gif){kind=small}
The Standard |
Home | Site Map | Search |
Unicode Character Encoding Stability PolicyUnlike many other standards, the Unicode Standard is continually expanding—new characters are added to meet a variety of uses, ranging from technical symbols to letters for archaic languages. Character properties are also expanded or revised to meet implementation requirements. In each new version of the Unicode Standard, the Unicode Consortium may add characters or make certain changes to characters that were encoded in a previous version of the standard. However, the Consortium imposes limitations on the types of changes that can be made, in an effort to minimize the impact on existing implementations. This page lists the policies of the Unicode Consortium regarding character encoding stability. These policies are intended to ensure that text encoded in one version of the standard remains valid and unchanged in later versions. In many cases, the constraints imposed by these stability policies allow implementers to simplify support for particular features of the standard, with the assurance that their implementations will not be invalidated by a later update to the standard. The notation Unicode N.n+ means “The Unicode Standard, Version N.n and all subsequent versions.” (For associated information, see the Related Links on the left.) Applicable Version: Unicode 2.0+ Once a character is encoded, it will not be moved or removed. This policy ensures that implementers can always depend on each version of the Unicode Standard being a superset of the previous version. The Unicode Standard may deprecate the character (that is, formally discourage its use), but it will not reallocate, remove, or reassign the character. Note: Ordering of characters is handled via collation, not by moving characters to different code points. For more information, see Unicode Technical Standard #10: Unicode Collation Algorithm, and the Unicode FAQ. Applicable Version: Unicode 2.0+ Once a character is encoded, its character name will not be changed. Together with the limitations in name syntax, this policy allows implementations to create unique identifiers from character names. The character names are used to distinguish between characters and do not always express the full meaning of each character. They are designed to be used programmatically and, therefore, must be stable. In some cases the original name chosen to represent the character is inaccurate in one way or another. Any such inaccuracies are dealt with by adding annotations to the character name list (which is also printed in the Unicode Standard and provided in a machine-readable format), or by adding descriptive text to the standard. Note: It is possible to produce translated names for the characters, to make the information conveyed by the name accessible to non-English speakers. In cases of outright errors in character names such as misspellings, a character may be given a formal name alias. Applicable Version: Unicode 5.0+ Formal aliases, once assigned to a character, will not be changed or removed. Formal aliases are defined in the file NameAliases.txt in the Unicode Character Database and listed in the character code charts. Named Character Sequence Stability Applicable Version: Unicode 5.0+ Named character sequences will not be changed or removed. This stability guarantee applies both to the name of the named character sequence and to the sequence of characters so named. Named character sequences are defined in the file NamedSequences.txt in the Unicode Character Database. For more information on named character sequences, see UAX #34, Unicode Named Character Sequences. Note: There are also provisional named character sequences, which are included in the Unicode Character Database but are not covered by this stability policy. Applicable Version: Unicode 2.0+ The names of characters, formal aliases, and named character sequences are unique within a shared namespace. The names of characters, named character sequences, and formal aliases for characters share a single namespace in which each name uniquely identifies either a single character or a single named character sequence. The definition of uniqueness is not just a simple comparison of the characters—instead, the loose matching rules from UCD.html in the Unicode Character Database are used. Strong
Normalization Stability More formally, given versions V and U of Unicode, and any string S which only contains characters assigned according to both V and U, the following are always true: toNFCV(S) = toNFCU(S) In particular, once a character is encoded, its canonical combining class and decomposition mapping will not be changed in any way. Decomposition Mapping Once a character is assigned, its decomposition mapping will not change. Canonical Combining Class Once a character is assigned, its canonical combining class will not change.
Weaker Version of
Normalization Stability Note that all of the guarantees implied by this weaker specification are subsumed by the stricter stability constraints applicable to Version 4.1 and later. If a string contains only characters from a given version of the Unicode, and it is put into a normalized form in accordance with that version of Unicode, then the result will also be in that normalized form according to any subsequent version of Unicode. The result will also be in that normalized form according to any prior version of the standard that contains all of the characters in the string (back to the first applicable version, Unicode 3.1). In particular, once a character is encoded, its canonical combining class and decomposition mapping will not be changed in a way that will destabilize normalization. Thus the following constraints will be maintained under all circumstances: Decomposition Mapping The decomposition mapping may not be changed except for the correction of exceptional errors which meet all of the following conditions (1-3):
Canonical Combining Class Once a character is assigned, its canonical combining class will not change.
Applicable Version: Unicode 1.1+ Once a character is encoded, its properties may still be changed, but not in such a way as to change the fundamental identity of the character. The Consortium will endeavor to keep the values of the other properties as stable as possible, but some circumstances may arise that require changing them. Particularly in the situation where the Unicode Standard first encodes less well-documented characters and scripts, the exact character properties and behavior initially may not be well known. As more experience is gathered in implementing the characters, adjustments in the properties may become necessary. Examples of such properties include, but are not limited to, the following:
However, character properties will not be changed in a way that would affect character identity. For example, the representative glyph for U+0061 “A” cannot be changed to “B”; the General_Category for U+0061 “A” cannot be changed to Ll (lowercase letter); and the decomposition mapping for U+00C1 (Á) cannot be changed to <U+0042, U+0301> (B, ´). Values of certain properties are limited by the constraints listed in the table below. The applicable version is given in the first column.
These constraints ensure that implementers can simplify or optimize certain aspects of their support for character properties. For further description of these invariants, see the file UCD.html in the Unicode Character Database. Applicable Version: Unicode 3.0+ All strings that are valid default Unicode identifiers will continue to be valid default Unicode identifiers in all subsequent versions of Unicode. Furthermore, default identifiers never contain characters with the Pattern_Syntax or Pattern_Whitespace properties. If a string qualifies as an identifier under one version of Unicode, it will qualify as an identifier under all future versions. The reverse is not true—an identifier under Version 5.0 may not be an identifier under Version 4.0—it may contain a character that was unassigned under Unicode 4.0, or (very rarely) a Unicode 4.0 character that was not an identifier character in Unicode 4.0, but became one in Unicode 5.0. For more information, see Unicode Standard Annex #31: Identifier and Pattern Syntax. Applicable Version: Unicode 5.0+ Caseless matching of Unicode strings used for identifiers is stable. Case folding stability ensures that identifiers created in different versions of Unicode can be reliably matched in a case-insensitive manner. For more information on identifiers see UAX #31: Identifier and Pattern Syntax. Identifiers commonly exclude compatibility decomposable characters; therefore this policy formally applies only to strings normalized with NFKC. The toCaseFold() operation used for caseless matching is the full case folding defined by rule R4 under “Default Case Conversion” in Section 3.13, Default Case Algorithms of the Unicode Standard. The formal statement of this policy is:
Applicable Version: Unicode 5.0+ Two assigned characters form a case pair when the full uppercase of the first character is the second character, and the full lowercase of the second character is the first character. If two characters form a case pair in a version of Unicode, they will remain a case pair in each subsequent version of Unicode. If two characters do not form a case pair in a version of Unicode, they will never become a case pair in any subsequent version of Unicode. More formally, for given versions V and U of Unicode, and any two characters X and Y that are both assigned according to both V and U:: toLowercaseV(X) = Y AND toUppercaseV(Y) = X if and only if toLowercaseU(X) = Y AND toUppercaseU(Y) = X Note that these conditions apply to two existing, assigned characters. A character that is not part of a case pair could become part of one if the new case pair is formed at the time of the addition of a new character to Unicode. For example, a new capital version of U+028D ( ʍ ) LATIN SMALL LETTER TURNED W could be added in the future to form a new case pair.
|
