[Unicode]  The Unicode Standard Home | Site Map | Search

Corrigenda to the Unicode Standard

The table of corrigenda shows the complete list of formal corrigenda to versions of the Unicode Standard.

Table of Corrigenda

Corrigenda Effective Date Applicable Versions Fixed Version Result Documented In:
Corrigendum #1: UTF-8 Shortest Form 2000-Nov-09
3.0.0 and 3.0.1 3.1.0
Chapter 3, Conformance
Corrigendum #2: Yod with Hiriq Normalization 2001-Jan-31
3.0.0 and 3.0.1 3.1.0
Corrigendum #3: U+F951 Normalization 2002-Feb-11
3.0.0 to 3.1.1 3.2.0
Corrigendum #4: Five CJK Canonical Mapping Errors 2003-Mar-04
3.2.0 4.0.0
Corrigendum #5: Normalization Idempotency 2005-Feb-07
[102-C3, PRI #61, PRI #29]
3.0.0 to 4.0.1 4.1.0
UAX #15
Corrigendum #6: Bidi Mirroring 2007-Aug-10
5.0.0 5.1.0
Corrigendum #7: UAX #14, Unicode Line Breaking Algorithm, rule LB8 2010-Mar-15
5.0.0 to 5.2.0 6.0.0
UAX #14
Corrigendum #8: Bidi_Class Fix for U+070F SYRIAC ABBREVIATION MARK 2010-Nov-5
6.0.0 6.1.0
Corrigendum #9: Clarification About Noncharacters 2013-Jan-30
3.1.0 to 6.3.0 --- ---

The table lists each corrigendum on the left and then states the relevant information about that corrigendum. The column with the effective date also lists the Unicode Technical Committee action and/or Public Review Issue (PRI) that led to its creation in brackets following the date.

The applicable versions column lists the range of Unicode versions relevant to a particular corrigendum. An implementation claiming conformance to any version of Unicode in that range may also claim conformance to one or more of the corrigenda applicable to that version. References to versions with applied corrigenda can be made as shown at Unicode References.

Corrigenda are fixed in the Unicode Standard at the first available release opportunity. For each corrigendum, the Unicode version in which it was fixed and the date of the release of that version are also shown in the table. Implementations which claim conformance to that fixed version (or later) need not separately reference a corrigendum, as the error has already been corrected in the standard. The final column in the table lists the relevant chapter, Unicode Standard Annex (UAX), or data file from the Unicode Character Database where the results of the correction are documented.

About Corrigenda

Each version of the Unicode Standard, once published, is absolutely stable and will never change. Implementations or specifications that refer to a specific version of the Unicode Standard can rely upon this stability. However, if those implementations or specifications are upgraded to a later version of the Unicode Standard, then of course some changes may be necessary to account for changes in Unicode between versions: addition of new characters, addition of new properties, specification of new algorithms, and so on.

Occasionally an error is found in a particular version of the Unicode Standard which is of sufficient importance that the UTC issues a formal corrigendum notice, prior to the release of the subsequent version of the standard. Corrigenda are limited in number; the entire list of such notices is specified in the table on this page. A formal corrigendum notice does not change the contents of any previously published versions of the standard. Instead, it provides a mechanism whereby an implementation, protocol, or other standard can cite or claim conformance to an existing version of the Unicode Standard with the corrigendum applied. This may be required in particular instances when an implementation, protocol, or standard otherwise supports a particular version of the Unicode Standard, but for security or interoperability reasons must apply a particular critical fix.

In a reference or claim of conformance to a particular version of the Unicode Standard, if the citation does not specifically mention a corrigendum, then the corrigendum does not apply for that reference or conformance claim.

All corrigenda must be in compliance with the Unicode Character Encoding Stability Policy. Corrigenda are reviewed and approved by the Unicode Consortium officers to ensure compliance with that policy. See also the FAQ on Normalization for more information about stability considerations and normalization.

Guaranteeing Protocol Stability Across Versions

In some instances, particularly for protocols making use of Unicode normalization, an implementation may have requirements to maintain complete stability in an algorithm. This may extend even to the retention of known errors and the non-application of corrigenda.

The file NormalizationCorrections.txt in the Unicode Character Database was introduced to assist in maintaining stability for implementations, by clearly identifying any data changes impacting normalization, with the exact changes in decomposition mappings and the exact versions for the changes. Any corrigendum to the Unicode Standard which changes a decomposition mapping in any way is then also reflected into NormalizationCorrections.txt, so that an implementation can track the exact status of any such changes. An implementer can then either apply the corrigendum to an earlier version of the standard (the normal case), or can choose not to apply the results of the corrigendum when moving an implementation forward to a later version of the standard (the exceptional case).

Implementers should be cautious when choosing the latter option, as it puts them formally out of compliance with later versions of the Unicode Standard and reduces their interoperability with implementations that have upgraded to later versions. However, in limited contexts where the overriding concern is backwards compatibility in the protocol itself, maintenance of an older, uncorrected form of Unicode normalization might be warranted.

Where possible, however, implementers are encouraged to adopt the most up-to-date and correct version of the Unicode Standard compatible with their application needs.

Access to Copyright and terms of use