Unicode Han Database (Unihan)

This document describes the organization and content of the Unihan database.

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 Mechanics
  • 2.1 Database Design
    • 2.1.1 Extension of Unihan Properties to Non-Unihan Characters
    • 2.1.2 Sorting Algorithm Used by the Radical-Stroke Indexes
  • 2.2 Unihan.zip
  • 2.3 Web Access
• 3 Property Types
  • 3.1 IRG Sources
  • 3.2 Other Mappings
  • 3.3 Dictionary Indices
  • 3.4 Readings
  • 3.5 Dictionary-like Data
  • 3.6 Radical-Stroke Counts
  • 3.7 Variants
    • 3.7.1 Simplified and Traditional Chinese Variants
    • 3.7.2 Semantic Variants
    • 3.7.3 Spoofing Variants
  • 3.8 Numeric Values
  • 3.9 Source References
  • 3.10 IRG Source Specifiers
• 4 The Properties
  • 4.1 Alphabetical Listing
  • 4.2 Listing by Version of Addition to the Unicode Standard
  • 4.3 Listing by Location within Unihan.zip
  • 4.4 Listing of Ideographs Covered by the Unihan Database
  • 4.5 Listing of Additional Sources Used by the Unihan Database
• 5 History
• References
• Acknowledgements
• Modifications

1 Introduction

The Unihan database is the repository for the Unicode Consortium’s collective knowledge regarding the Han ideographs contained in the Unicode Standard. It contains mapping data to allow conversion to and from other coded character sets and additional information to help implement support for the various languages which use the Han script.

Formally, ideographs are defined within the Unicode Standard via their mappings. That is, the Unicode Standard does not formally define what the ideograph U+4E00 一 is; rather, it defines it as being the equivalent of, say, 0x523B in GB/T 2312, 0x14421 in CNS 11643, 0x306C in JIS X 0208, and so on.

In practice, implementation of Han ideographs requires large amounts of ancillary data. Input methods require information such as readings, as do collation algorithms. Data in character sets not included in the world of international standards bodies needs to be converted. Relationships between ideographs need to be defined to allow for fuzzy string matching. Beyond all this, it’s important to track not only what properties a given ideograph has, but who claims it has those properties.

Unlike characters in Western scripts such as Latin and Greek, whose basic property is their sound, which stays largely constant across languages, the basic property for Han ideographs is their meaning. This isn’t to say that ideographs are truly ideographic, in that they represent abstract ideas; but they generally have one root meaning from which the others derive, and generally retain the bulk of their semantic content across linguistic boundaries. Most ideographs are divided into a determinative, which gives a vague sense of meaning, and a phonetic, which gives a vague sense of pronunciation. The Unihan database therefore includes structural analyses and definitions for Han ideographs.

This document is a guide to that data, describing the mechanics of the Unihan database, the nature of its contents, and the status of the various properties.

2 Mechanics

2.1 Database Design

The database consists of a number of fields containing data for each Han ideograph in the Unicode Standard. The fields, all of which correspond to properties, have names that consist entirely of ASCII letters and digits with no spaces or other punctuation except for underscore. For historical reasons, they all start with a lowercase k.

All data in the Unihan database is stored in UTF-8 using Normalization Form C (NFC). Note, however, that the “Syntax” descriptions below, used for validation of property values, operate on Normalization Form D (NFD), primarily because that makes the regular expressions simpler.

2.1.1 Extension of Unihan Properties to Non-Unihan Characters

Some characters which are not unified ideographs are considered equivalent to unified ideographs. As such, some of the properties defined in this document are applicable to these characters as well, where appropriate. For example, U+2F8D ⾍ KANGXI RADICAL INSECT is equivalent to U+866B; therefore, properties such as kCantonese (cung4), or kCangjie (LMI) may be inferred as needed for U+2F8D ⾍ KANGXI RADICAL INSECT.

This extension process is particularly useful for the kRSUnicode and kTotalStrokes properties.

The Equivalent_Unified_Ideograph property in the Unicode Character Database [UCD] is used to indicate which non-ideographs and unified ideographs are considered equivalent for these purposes. It is explicitly intended to enable kRSUnicode and kTotalStrokes property values for non-ideographs to be derived from their equivalent unified ideographs. See Unicode Standard Annex #44, “Unicode Character Database” [UAX44], for more information.

2.1.2 Sorting Algorithm Used by the Radical-Stroke Indexes

The Unicode Standard includes a set of radical-stroke indexes for ease in determining the code point of encoded ideographs. Each Han ideograph will occur one or more times in the radical-stroke indexes, with one occurrence per value of its kRSUnicode property. Entries in the radical-stroke indexes are ordered using a 64-bit collation key calculated as follows:

Bits 0–19 represent the ideograph’s code point. This is more space than is actually needed, but it has the advantage of aligning the code point along a four-bit boundary.

Bits 20–27 represent the ideograph’s block. This block value is 0 for ideographs in the CJK Unified Ideographs block, 1 for ideographs in the CJK Unified Ideographs Extension A, 2 for ideographs in the CJK Unified Ideographs Extension B block, and so on. The special values 254 (0xFE) and 255 (0xFF) are used for ideographs in the CJK Compatibility Ideographs and CJK Compatibility Ideographs Supplement blocks, respectively. This allows accommodation for future CJK Unified Ideograph Extension blocks and guarantees that compatibility ideographs always follow unified ideographs. Note that additional compatibility ideograph blocks will not be encoded in the future.

Bits 28–31 are used to indicate whether the entry has a simplified form for the radical or not. A value of 0 indicates the traditional form for the radical (for example, U+9F8D 龍); a value of 1 indicates the Chinese simplified form of the radical (for example, U+9F99 龙); a value of 2 indicates a non-Chinese simplified form of the radical (for example, U+7ADC 竜); and a value of 3 indicates a second non-Chinese simplified form of the radical (for example, U+31DE5 𱷥).

Bits 32–35 are reserved to hold the entry’s first residual stroke, as defined by the Ideographic Research Group (IRG), a subgroup of ISO/IEC JTC 1/SC 2/WG 2. Data for the first residual stroke is currently unavailable. Therefore, these bits are set to 0 in the current data.

Bits 36–43 are used for the entry’s residual stroke count. If the residual stroke count is negative, 0 is substituted.

Bits 44–51 are used for the entry’s Kangxi radical.

Bits 52–63 are unused.

This collation key is defined in such a fashion that it can easily be parsed by eye. Figure 1 illustrates its overall structure.

Figure 1. Radical-Stroke Index Collation Key Schema

Examples:

• U+4E95 井 is assigned the collation key 0x0000702000004E95.
• U+3687 㚇 has two values in its kRSUnicode property value and therefore two entries in the radical-stroke indexes. These two entries are assigned the collation keys 0x0002306000103687 and 0x0004206000103687.
• U+F936 虜 is assigned the collation key 0x0008D0600FE0F936.
• U+21FEB 𡿫 is assigned the collation key 0x0002F03000221FEB.
• U+9F8D 龍, U+9F99 龙, U+7ADC 竜, and U+31DE5 𱷥 are assigned the collation keys 0x000D400000009F8D, 0x000D400010009F99, 0x0007505000007ADC/0x000D400020007ADC, and 0x0007506000831DE5/0x000D400030831DE5, respectively.

In addition to the radical-stroke indexes that are distributed as PDF files, the Unicode Standard also includes a “plain text” data file representation of the main radical-stroke index that includes all Han ideographs in that particular version of the standard. This data file is intended for developers who would benefit from a machine-readable implementation of the collation algorithm as applied to the current repertoire of Han ideographs, and for CJK specialists who prefer to work with data files. The format of the data file consists of the following two tab-delimited fields: 1) a unique radical-stroke value pair that is separated by a period; and 2) one or more Unicode Scalar Values for Han ideographs in collation order per this section. The actual Han ideographs that correspond to the Unicode Scalar Values in the second field are provided as comments. An example line from the data file is shown below:

2.2 Unihan.zip

Included with the [UCD] is a file called Unihan.zip. This is a snapshot of the public contents of the Unihan database as of the release date for this version of the Unicode Standard.

The zip file is an archive of eight text files, each in UTF-8, NFC, and using Unix line endings. Each file contains the values for some of the properties in the Unihan database.

Each file contains those properties which belong to one of the general categories described below; that is, Unihan_Readings.txt contains all the data for all the properties in the Readings category, and so on.

The grouping of properties into categories, and of their data into files, is based on both principled and practical considerations, and it changes over time. For mechanical parsing of Unihan data, it should not be assumed that the data for a particular property is in a particular file. One approach to parsing data for certain properties is to concatenate all of the Unihan*.txt files together (or act as if they were) and extract the desired properties from the whole (for example, using grep). This avoids the need to track which file has a given property across Unicode versions, and therefore avoids the need to adjust parsing code.

Each file uses the same structure. Blank lines may be ignored. Lines beginning with # are comment lines used to provide the header and footer. Each of the remaining lines is one entry, with three, tab-separated fields: the Unicode Scalar Value, the property name, and the value for the property for the given Unicode Scalar Value. For most of the properties, if multiple values are possible, the values are separated by spaces. No ideograph may have more than one instance of a given property associated with it, and no empty properties are included in any of the files archived inside Unihan.zip.

There is no formal limit on the lengths of any of the property values. Any Unicode characters may be used in the property values except for double quotes and control characters (especially tab, newline, and carriage return). Most properties have a more restricted syntax, such as the kKangXi property which consists of multiple, space-separated entries, with each entry consisting of four digits 0 through 9, followed by a period, followed by three more digits.

The data lines are sorted by Unicode Scalar Value and property-type as primary and secondary keys, respectively.

Each file’s header includes a summary of the properties the file contains.

2.3 Web Access

The Unihan Database Lookup page provides interactive web access to the contents of the Unihan database. For production reasons, the version available for interactive web access may not be immediately updated to the latest available version of the Unihan.zip file.

Links to Chinese and Japanese compound data are presented with this web front end, such as to the online CantoDict, CC-CEDICT, and Jim Breen’s WWJDIC projects. These additional data are not available in the other versions.

There are also two indices: a grid index grouping the ideographs in blocks of 256 and a radical-stroke index. A search page is also available. Individual ideographs can be accessed through the index or via the “Lookup” button and text field above. You enter the four- or five-digit hexadecimal identifier for the ideograph, and click “Lookup.” You will be taken to an information page for the ideograph. The “Use text, not images” check-box allows you to control whether UTF-8 text or embedded GIFs will be used in to display ideographs. The latter technique is less dependent on your browser and system support for Unicode but is much slower.

3 Property Types

The data in the Unihan database serves a multitude of purposes, and the properties are most conveniently grouped into categories according to the purpose they fulfill. We provide here a general discussion of the various categories, followed by a detailed description of the individual properties, alphabetically arranged.

3.1 IRG Sources

Among the few normative parts of the Unihan database, and the most exhaustively checked properties, are the IRG source properties: kIRG_GSource (China and Singapore), kIRG_HSource (Hong Kong SAR), kIRG_JSource (Japan), kIRG_KPSource (North Korea), kIRG_KSource (South Korea), kIRG_MSource (Macao SAR), kIRG_SSource (SAT Daizōkyō Text Database Committee), kIRG_TSource (TCA), kIRG_UKSource (UK), kIRG_USource (UTC), and kIRG_VSource (Vietnam).

These represent the official mappings between Unihan and the various encoded character sets or collections which have been submitted by IRG members. The versions of these standards may differ from the published versions generally available, particularly for PRC standards. This is because in the early days of Unicode, the PRC would occasionally add ideographs to their standards on an ad hoc basis in order to make sure they were included. The various procedures involved in submitting ideographs to the IRG for consideration no longer make this necessary.

The values for the U-source were, in the past, only references to the Unicode Standard itself and were always equal to the ideograph’s Unicode Scalar Value. This changed with the inclusion of Extension C in Version 5.2.0 of the Unicode Standard. The values now consist of indices as described in Unicode Standard Annex #45, “U-Source Ideographs” [UAX45].

The syntax for the values used in the various IRG source properties matches that found in ISO/IEC 10646:2020 [10646].

Detailed descriptions of the syntax used are to be found in Section 4.1, Alphabetical Listing, below.

Note that we do not include the IRG dictionary properties in this category, largely because they are not normative parts of the standard.

The kIICore property is also defined by the IRG and normative.

3.2 Other Mappings

The values for the properties in this category consist of mappings to the corresponding ideographs in encoded character sets or character collections not used by the IRG in its unification work, although some of the character sets covered do mirror official IRG sources. For example, data for mapping GB/T 12345 is included, even though GB/T 12345 is a part of the IRG’s G-source. The difference between the two is that the kGB1 property maps all of GB/T 12345 to Unicode, and not just that portion included in the G-source, and it doesn’t map any of the informal extensions to GB/T 12345.

3.3 Dictionary Indices

There are three main reasons for providing indices into standard dictionaries.

First, standard dictionaries provide a “paper trail” for properties such as the English gloss (kDefinition) and the various pronunciations or readings, as well as variant data.

Second, standard dictionaries provide a reference for scholars or students who wish more information about an ideograph.

Third, standard dictionaries are a source for unencoded ideographs. This is particularly important for Cantonese, where the Cantonese lexicon is not standardized and has been neglected by the authors and architects of previous character set encodings other than HKSCS.

Three of the dictionary properties represent official IRG indices for the dictionaries used in the four dictionary sorting algorithm. Two (kIRGHanyuDaZidian and kIRGKangXi) are still being used by the IRG, but the other one (kIRGDaeJaweon) is not. We have, nonetheless, retained its data for reference purposes.

The remaining dictionaries can be grouped into three categories: general-purpose Chinese (including classical Chinese), Cantonese, and Japanese.

• The general-purpose Chinese dictionary properties are: kCihaiT, kFennIndex, kGSR, kKarlgren, kMatthews, kSBGY, kSMSZD2003Index, kTGHZ2013, and kXHC1983. These represent large, standard Chinese-Chinese and Chinese-English dictionaries, or definitive sinological studies.
• The Cantonese dictionary properties are kCheungBauerIndex, kCowles, kLau, and kMeyerWempe. All but Cheung-Bauer are large character-based Cantonese-English dictionaries. The kSMSZD2003Index property represents a general-purpose Chinese dictionary which also includes Cantonese data.
• At present, the only Japanese property is kNelson, the ideograph’s index in the first edition of Andrew N. Nelson’s Modern Reader’s Japanese-English Character Dictionary.

3.4 Readings

We include in this category the pronunciations for a given ideograph in Mandarin, Cantonese, Tang-dynasty Chinese, Japanese, Sino-Japanese, Korean, and Vietnamese. We also include here the English gloss for a given ideograph.

Any attempt at providing a reading or set of readings for an ideograph is bound to be fraught with difficulty, because the readings will vary over time and from place to place, even within a language. Mandarin is the official language of both the PRC and Taiwan (with some differences between the two) and is the primary language over much of northern and central China, with vast differences from place to place. Even Cantonese, the modern language covered by the Unihan database with the least geographical range, is spoken throughout Guangdong Province and in much of neighboring Guangxi Zhuang Autonomous Region, and covers four large urban centers (Guangzhou, Shenzhen, Macao, and Hong Kong). There are therefore distinct regional variations in pronunciation and vocabulary.

Indeed, even the same speaker will pronounce the same word differently depending on the speaker or even the social context. This is particularly true for languages such as Cantonese, where there has been comparatively little government effort to standardize the language.

Add to this the fact that in none of these languages—the various forms of Chinese, Japanese, Korean, Vietnamese—is the syllable the fundamental unit of the language. As in the West, it’s the word, and the pronunciation of an ideograph is tied to the word of which it is a part. In Chinese (followed by Vietnamese and Korean), the rule is one ideograph/one syllable, with most words written using multiple ideographs. In most cases, an ideograph has only one reading (or only one important reading), but there are numerous exceptions.

In Japanese, the situation is enormously more complex. Japanese has two pronunciation systems, one derived from Chinese (the on pronunciation, or Sino-Japanese), and the other from Japanese (the kun pronunciation).

The on readings derive from Chinese loan-words. They depend on factors such as when (and from which part of China) the loan-word was borrowed, and changes to Japanese since then. On readings can therefore have little obvious relationship to modern Chinese readings, and the same Chinese reading for a given kanji can be reflected in multiple on readings in Japanese. Contrary to Chinese practice, on readings may be polysyllabic.

Kun readings, on the other hand, derive from native Japanese words for which either existing kanji were adopted or new kanji coined.

The net result is that multiple readings are the rule for Japanese kanji. These multiple readings may bear no relationship to one another and are highly context-sensitive. Even a native Japanese reader may not know the correct pronunciation of a proper noun if it is written only in kanji.

Finally, some ideographs have rare pronunciations known only to a minority of native speakers, or are so rare themselves that few, if any, native speakers know how to pronounce them (for example, U+40DF 䃟, which is used in a few Hong Kong place names). In many cases, the pronunciations given by professional lexicographers are little more than educated guesses.

Thus, unlike mappings between Unicode and other character sets, providing definitive data on pronunciations or, similarly, providing a definitive English gloss is impossible, and not something which has been achieved. While we make every effort to use our sources judiciously, we are aware of the fact that this data can always be improved and extended. Users should not naïvely assume that learning to pronounce an East Asian language is all about learning to pronounce the individual ideographs, or that reading is done by parsing the ideographs, one at a time.

Despite these caveats, the reading and definition data is very useful both for the student attempting to learn these languages, and for the professional attempting to use them, and so the data is included in the Unihan database.

3.5 Dictionary-like Data

This category is something of a hodge-podge, consisting of various properties including information one might find in a dictionary (such as an ideograph’s cangjie input code), or data useful in determining levels of support (such as frequency), or structural analyses which can be helpful in lookup systems (such as the ideograph’s phonetic).

As with the readings and English gloss, this data does not cover as much of Unihan as is theoretically possible, although it does cover the bulk of what is used day-to-day.

3.6 Radical-Stroke Counts

We include two radical-stroke counts for Unihan: kRSAdobe_Japan1_6 and kRSUnicode.

All the radical-stroke properties are based on the radical system introduced by the 18th-century Kangxi Dictionary (康熙字典 Kāngxī Zìdiǎn). Each ideograph is assigned one of 214 radicals. In most cases, the radical assigned is the natural radical, giving a clue as to the ideograph’s meaning; in the rest, the radical is arbitrary, based on the ideograph’s structure. One also counts the ideograph’s residual strokes, that is, the number of brush strokes required to write everything in the ideograph except the radical.

To find an ideograph using the radical-stroke system, one determines its radical and the number of residual strokes, then looks through the list of ideographs with those characteristics. This is a clumsy system compared to alphabetical lookup, but is one of the most widespread systems throughout East Asia. Unfortunately, it is also ambiguous.

First of all, if an ideograph does not have a natural radical, it can sometimes be hard to tell what the radical ought to be. For example, U+4E95 井 being arbitrarily assigned Radical 7 (二). Even if the ideograph naturally falls into radical-like pieces, it can be hard to tell which is the radical and which is the phonetic. For example, U+548C 和, which looks like it belongs to Radical 115 (禾), actually belongs to Radical 30 (口). Moreover, since Unicode encodes characters, not glyphs, two different glyphs for the same ideograph may have different residual strokes (such as U+8005 者, which can be written either with or without a dot, altering its stroke count between nine and eight, respectively).

The primary use for the kRSUnicode property is to cover the normative radical-stroke value defined by [10646]. However, it is also used for cases where there is sufficient ambiguity that a reasonable person might look for an ideograph in multiple places, particularly where one of our source dictionaries categorizes an ideograph under a different radical or with a different stroke count.

The kRSUnicode property also uses apostrophes after the radical number to indicate that the ideograph uses a standard simplification. A single apostrophe indicates the Chinese simplified form of the radical (for example, U+9F99 龙 for U+9F8D 龍), two apostrophes indicate a non-Chinese simplified form of the radical (for example, U+7ADC 竜 for U+9F8D 龍), and three apostrophes indicate a second non-Chinese simplified form of the radical (for example, U+31DE5 𱷥 for U+9F8D 龍).

There is, by the way, no standard way of ordering ideographs within a given radical-stroke group. The Unicode Standard’s radical-stroke indexes order ideographs with the same radical-stroke count by the Unicode block in which they occur. If looking for an ideograph with Radical 64 (手) and ten residual strokes, one knows that of the hundreds of candidates in the Unicode Standard, the most common ones come towards the head of the list and the less common ones later.

The IRG is in the process of adopting a common system of assigning the first stroke of the phonetic element, more commonly referred to as the “first residual stroke,” to one of five categories, and sorting by those categories. This data is now required for all IRG submissions; see Section 2.4 of Unicode Standard Annex #45, “U-Source Ideographs” [UAX45]. When this data is available for all of Unihan, it will be added to the Unihan database as a new property, and will simplify the process of finding an ideograph within a particular radical-stroke block.

3.7 Variants

Although Unicode encodes characters and not glyphs, the line between the two can sometimes be hard to draw, particularly in East Asia. There, thousands of years worth of writing have produced thousands of pairs which can be used more-or-less interchangeably.

To deal with this situation, the Unicode Standard has adopted a three-dimensional model for determining the relationship between ideographs, and has formal rules for when two forms may be unified, which includes the now-abolished Source Separation Rule. Both are described in some detail in the Unicode Standard. Briefly, however, the three-dimensional model uses the x-axis to represent meaning, the y-axis to represent abstract shape, and the z-axis for stylistic variations.

To illustrate, U+8AAA 說 and U+8C93 貓 have different positions along the x-axis, because they mean two entirely different things (to speak and cat, respectively). U+8C93 貓 and U+732B 猫 mean the same thing and are pronounced the same way, but have different abstract shapes, so they have the same position on the x-axis (semantics), but different positions on the y-axis (abstract shape). They are said to be y-variants of one another. On the other hand, U+8AAA 說 and U+8AAC 説 have the same meaning and pronunciation, and the same abstract shape, and so have the same positions on both the x- and y-axes, but different positions on the z-axis. They are z-variants of one another.

Ideally, there would be no pairs of z-variants in the Unicode Standard; however, the need to provide for round-trip compatibility with earlier standards, and some out-and-out mistakes along the way, mean that there are some. These are marked using the kZVariant property.

The remaining variant properties are used to mark different types of y-variation.

3.7.1 Simplified and Traditional Chinese Variants

The kTraditionalVariant and kSimplifiedVariant properties are used in character-by-character conversions between simplified and traditional Chinese (abbreviated as SC and TC, respectively). For any ideograph X, when converting between SC and TC, there are four possible cases:

1. X is used in both SC and TC and is unchanged when mapping between them. An example would be U+4E95 井. This is the most common case, and is indicated by both the kSimplifiedVariant and kTraditionalVariant properties being empty.
2. X is used in TC but not SC, that is, it is changed when converting from TC to SC, but not vice versa. In this case, the kSimplifiedVariant property lists the ideograph(s) to which it is mapped and the kTraditionalVariant property is empty. An example would be U+66F8 書 whose kSimplifiedVariant property is U+4E66 书.
3. X is used in SC but not TC, that is, it is changed when converting from SC to TC, but not vice versa. In this case, the kTraditionalVariant property lists the ideograph(s) to which it is mapped and the kSimplifiedVariant property is empty. An example would be U+5B66 学 whose kTraditionalVariant property is U+5B78 學.
4. X is used in both SC and TC and may be changed when mapping between them. This is the most complex case, because there are two distinct sub-cases:
   1. X may be mapped to itself or to another ideograph when converting between SC and TC. In this case, the ideograph is its own simplification as well as the simplification for other ideographs. An example would be U+540E 后, which is the simplification for itself and for U+5F8C 後. When mapping TC to SC, it is left alone, but when mapping SC to TC it may or may not be changed, depending on context. In this case, both kTraditionalVariant and kSimplifiedVariant properties are defined and X is included among the values for both.
   2. X is used for different words in SC and TC. When converting between the two, it is always changed. An example would be U+82E7 苧. In traditional Chinese, it is pronounced zhù and refers to a kind of nettle. In simplified Chinese, it is pronounced níng and means limonene (a chemical found in the rinds of lemons and other citrus fruits). When converting TC to SC it is mapped to U+82CE 苎, and when converting SC to TC it is mapped to U+85B4 薴. In this case, both kTraditionalVariant and kSimplifiedVariant properties are defined but X is not included in the values for either.

In practice, conversion between simplified and traditional Chinese is complicated by several factors:

1. The conversion is almost always one-to-one, but in some cases may be one-to-many, and context may need to be evaluated to determine which specific mapping to use. When converting SC to TC, U+810F 脏 is mapped to U+81DF 臟 when it means “viscera” and to U+9AD2 髒 when it means “dirty.”
2. Simplified/traditional pairs may be affected by the now-abolished Source Separation Rule, such as 1) when the traditional variant that is common in TW/HK is not identical to the official traditional variant as defined by CN standards, such as U+4E3A 为 versus U+70BA 為 (HK, TW) / U+7232 爲 (CN); and 2) when the traditional variant that is common in TW/HK diverges, whereby the preferred HK traditional variant is identical to the official traditional variant as defined by CN standards, such as U+8BF4 说 versus U+8AAC 説 (HK, CN) / U+8AAA 說 (TW).
3. An SC ideograph may be used in actual TC text and, more rarely, vice versa. This is particularly true in handwritten and ancient texts. Indeed, many SC forms originated as handwritten forms or ancient synonyms. It also occurs when one of a number of synonymous TC ideographs is identified as the preferred or correct ideograph to use in SC. For example, both U+732B 猫 and U+8C93 貓 are acceptable TC ideographs meaning “cat,” but only U+732B 猫 should be used in SC.
4. The mappings defined within the Unihan database are informal and based on actual practice. Different authorities may not agree on the simplified or traditional form of a specific ideograph, and either might be at odds with official, formal definitions, such as those in the 通用规范汉字表 (Tōngyòng Guīfàn Hànzì Biǎo, Table of General Standard Chinese Characters).
5. Political divisions within the Chinese-speaking community have resulted in different coinages in different locales for various modern terms, and so actual conversion between SC and TC is ideally done on a word-by-word basis, not a character-by-character basis. A hard disk, for example, is called 硬盘 in the PRC, and 硬碟 in Taiwan.

3.7.2 Semantic Variants

Two variation properties, kSemanticVariant and kSpecializedSemanticVariant, are used to mark cases where two ideographs have identical and overlapping meanings, respectively.

Thus U+514E 兎 and U+5154 兔 are y-variants of one another; both mean rabbit. U+4E3C 丼 and U+4E95 井 are not pure y-variants of one another. U+4E95 井 means a well, and although U+4E3C 丼 can also mean a well and be used for U+4E95 井, it can also mean a bowl of food. We use kSemanticVariant, then, for the former pair, and kSpecializedSemanticVariant for the latter. In many cases, data is provided listing the Unihan sources which indicate the variant relationship. The syntax is described in detail below, but as an example, U+792E 礮 has the kSemanticVariant value U+70AE<kMeyerWempe U+7832<kLau,kMatthews,kMeyerWempe U+791F<kLau,kMatthews. This means that the Mathews, Lau, and Meyer-Wempe dictionaries all say that it is a y-variant of U+7832 砲, whereas only Mathews and Lau identify it as a variant of U+791F 礟 and only Meyer-Wempe identifies it as a variant of U+70AE 炮.

3.7.3 Spoofing Variants

The kSpoofingVariant property is used to denote a special class of variant, a spoofing variant. Spoofing variants are potentially used in bad faith to direct users to unexpected URLs, evade email filters, or otherwise deceive end-users. Determining whether or not two ideographs are spoofing variants is based entirely on the glyph shape, without regard for semantics. Etymologically unrelated pairs such as U+571F 土 and U+58EB 士 or U+672A 未 and U+672B 末 are considered spoofing variants. A common source of spoofing variants is deliberate confusion between Radicals 74 (⽉) and 130 (⾁). These two radicals, when used in Han ideographs, look very similar or identical (for example, in U+3B35 㬵 and U+80F6 胶). Similarly, even if the visual appearance of two radicals is distinct, they may be similar enough that a user might overlook the distinction (for example, ⼎ and ⺡), especially in a spoofing context such as https://凊水.org/ versus https://清水.org/. Spoofing variants also include instances where two highly similar shapes are separately encoded because of source code separation, without regard to other considerations. Cases include the following pairs: U+672C 本 and U+5932 夲; U+520A 刊 and U+520B 刋.

Some spoofing variants might be sufficiently dissimilar in shape that they can be distinguished at large point sizes. Others are dissimilar in meaning so that they can be distinguished in running text. They might also be visually distinct in one font but not another, due to the language or region that the font supports. These considerations are irrelevant to their status; even dissimilar pairs can be used to misdirect users (particularly when URLs are displayed at small point sizes).

Because z-variant pairs are, by definition, either identical or unifiable, they should all be considered spoofing variants as well. The same is true of compatibility variants. Because of these considerations, the kSpoofingVariant property only includes spoofing variants which are not also z-variants or compatibility variants.

The kSpoofingVariant property is symmetric (if A is a spoofing variant of B, then B is a spoofing variant of A) and transitive (if A is a spoofing variant of B and B is a spoofing variant of C, then A is a spoofing variant of C).

The kSpoofingVariant property only covers ideographs in the CJK Unified Ideographs blocks. Other CJK-related spoofing data is found in the EquivalentUnifiedIdeographs.txt file in the [UCD].

3.8 Numeric Values

There are five properties—kAccountingNumeric, kOtherNumeric, kPrimaryNumeric, kVietnameseNumeric, and kZhuangNumeric—that indicate the numerical values an ideograph may have. Traditionally, ideographs were used both for numbers and words, and so many ideographs have (or can have) numeric values. The various kinds of numeric values are specified by these five properties.

3.9 Source References

A number of properties in the Unihan database indicate the source from which the data is taken. As noted above, this includes but is not limited to the kSemanticVariant and kSpecializedSemanticVariant properties.

These source references are of two kinds:

1. Sources corresponding to one or more properties in the Unihan database. These are identified by their property identifiers. In cases where multiple properties correspond to one source (such as kHanYu and kHanyuPinyin), only one is used.
2. Other sources or standard references. These are identified by a lower case s (for “source”) followed by a series of ASCII letters, numerals, and underscores. The overall syntax, except for the first letter, is the same as property identifiers used by the Unihan database.

Indices to or data from some of these additional sources may at some future point be added to the Unihan database as a new property. In that case, the initial s will be changed to a k.

A complete list of these additional sources with bibliographic information is found in Section 4.5 below.

3.10 IRG Source Specifiers

A number of properties in the Unihan database indicate IRG sources with which the data is associated. This includes but is not limited to the kAlternateTotalStrokes, kIICore, and kUnihanCore2020 properties.

These sources references consist of a series of one-letter identifiers. These letters match the full IRG source designations (for example, “H” refers to kIRG_HSource), except that “B” is used instead of “UK” and “P” instead of “KP.” The order of the letters within the source reference is not specified.

4 The Properties

We now give two listings of the properties in the Unihan database. The first is an alphabetical listing, with information on the property contents and syntax. The second is a listing of the properties by the version of the Unicode Standard in which they were first introduced.

4.1 Alphabetical Listing

For each property we give the following information in the alphabetical listing: its Property tag, its Unicode Status, its Category as defined above, the Unicode version in which it was Introduced, its Delimiter, its Syntax, and its Description.

The Property name is the tag used in the Unihan database to mark instances of this property.

The Unicode Status is either Normative, Informative, or Provisional, depending on whether it is a normative part of the standard, an informative part of the standard, or neither. We may also include Deprecated as a Unicode Status if the property is no longer to be used.

Properties which allow multiple property values have a Delimiter defined as “space” (U+0020 SPACE). Properties which do not have multiple property values (such as the IRG source properties) have this defined as “N/A.” Some properties do not currently have multiple values in the data but may do so in the future.

For most properties with multiple values, the order of the values is arbitrary and has no particular significance. The most common order in such cases is alphabetical. For example, see the kCantonese property.

However, for certain properties the ordering of values may be significant; in such cases, the significance is specified in the Description for the property. For example, see the kMandarin property. In later versions of the [UCD], a property may change from arbitrary order to a specified order.

Validation is done as follows: The entry is split into subentries using the Delimiter (if defined), and each subentry converted to Normalization Form D (NFD). The value is valid if and only if each normalized subentry matches the property’s Syntax regular expression. Note that any given property’s Syntax is not guaranteed to be stable and may change in the future.

Finally, the Description contains not only a description of what the property contains, but also source information, known limitations, methodology used in deriving the data, and so on.

The properties covered in the table are: kAccountingNumeric, kAlternateTotalStrokes, kBigFive, kCangjie, kCantonese, kCCCII, kCheungBauer, kCheungBauerIndex, kCihaiT, kCNS1986, kCNS1992, kCompatibilityVariant, kCowles, kDaeJaweon, kDefinition, kEACC, kFanqie,< kFenn, kFennIndex, kFourCornerCode, kGB0, kGB1, kGB3, kGB5, kGB7, kGB8, kGradeLevel, kGSR, kHangul, kHanYu, kHanyuPinlu, kHanyuPinyin, kHDZRadBreak, kHKGlyph, kIBMJapan, kIICore, kIRG_GSource, kIRG_HSource, kIRG_JSource, kIRG_KPSource, kIRG_KSource, kIRG_MSource, kIRG_SSource, kIRG_TSource, kIRG_UKSource, kIRG_USource, kIRG_VSource, kIRGDaeJaweon, kIRGHanyuDaZidian, kIRGKangXi, kJa, kJapanese, kJapaneseKun, kJapaneseOn, kJinmeiyoKanji, kJis0, kJis1, kJIS0213, kJoyoKanji, kKangXi, kKarlgren, kKorean, kKoreanEducationHanja, kKoreanName, kLau, kMainlandTelegraph, kMandarin, kMatthews, kMeyerWempe, kMojiJoho, kMorohashi, kNelson, kOtherNumeric, kPhonetic, kPrimaryNumeric, kPseudoGB1, kRSAdobe_Japan1_6, kRSUnicode, kSBGY, kSemanticVariant, kSimplifiedVariant, kSMSZD2003Index, kSMSZD2003Readings, kSpecializedSemanticVariant, kSpoofingVariant, kStrange, kTaiwanTelegraph, kTang, kTGH, kTGHZ2013, kTotalStrokes, kTraditionalVariant, kUnihanCore2020, kVietnamese, kVietnameseNumeric, kXerox, kXHC1983, kZhuang, kZhuangNumeric, and kZVariant.

4.2 Listing by Version of Addition to the Unicode Standard

The table below lists the properties of the Unihan database by the version of the Unicode Standard in which they were first added. Also included are properties that were removed in a particular version. Properties that were removed in Version 4.1 or later are linked to either the UTC document in which their removal was proposed or the particular consensus in UTC meeting minutes that confirms their removal.

The remaining properties were added prior to Unicode 2.0.

4.3 Listing by Location within Unihan.zip

The table below lists the properties of the Unihan database. They are organized into groups according to the file within Unihan.zip where their values are found. Each property name also links to its description.

The grouping of properties into files may differ between versions of the Unicode Standard. Parsers should not rely on the data for a particular property being listed in any specific file.

4.4 Listing of Ideographs Covered by the Unihan Database

The following table lists the ideographs covered by the Unihan database, together with the version in which they were added to the Unicode Standard.

† Note: 12 code points in the CJK Compatibility Ideographs block (U+FA0E, U+FA0F, U+FA11, U+FA13, U+FA14, U+FA1F, U+FA21, U+FA23, U+FA24, and U+FA27 through U+FA29) lack a canonical Decomposition_Mapping value in UnicodeData.txt, and so are not actually CJK Compatibility Ideographs. These twelve ideographs are CJK Unified Ideographs.

Note that some CJK characters do not explicitly have property data in the Unihan database, such as:

Some of the above-listed blocks of CJK characters have additional property data and documentation, in particular see:

• CJKRadicals.txt [CJKRadicals] in the [UCD]
• EquivalentUnifiedIdeograph.txt [EquivalentUnifiedIdeograph] in the Unicode Character Database [UCD]
• Appendix F: Documentation of CJK Strokes, in [Unicode]

4.5 Listing of Additional Sources Used by the Unihan Database

The following table provides a formal identification of sources used by the Unihan database, together with bibliographic information. This listing only includes sources without a corresponding property in the Unihan database. It should not be taken as exhaustive.

5 History

The Unihan database originated as a Hypercard stack using data provided by such organizations as Apple, RLG, and Xerox. Printed versions are found in The Unicode Standard, Version 1.0, volume 2. Electronic versions were available on floppy disk in the form of a file called CJKXREF.TXT.

The first general electronic release of CJKXREF.TXT (961 kB) was included with Unicode 1.1.5 in July 1995. This version of the file is in a multi-column format and includes the data used in printing The Unicode Standard, Version 1.0, volume 2 with the exception of the Fujitsu mappings, which were found to be incorrect and withdrawn.

The electronic version of the Unihan database was substantially revised for the publication of Unicode 2.0.0 in July 1996. The file was renamed UNIHAN.TXT; its permanent, archival link is Unihan-1.txt (7.9 MB). The format of the file is essentially the same as the current release, although consolidated into a single file. The properties were explicitly named for the first time. The data was at the time maintained using custom, MacApp-based database software. The source code for this software used an enumerated type for the numeric property tags, and the enumerator names (each beginning with a k indicating their use as a constant) were used in the text file as property names.

The difficulty of downloading a file 19 MB in size with the technology of the time led to the Unihan database being made available as both a single text file and compressed archives of that text file as of Unicode 3.1.0 in March 2001. The format of the Unihan database remained essentially unchanged until Unicode 5.1.0 (April 2008), when the text file was no longer included and the database became available only as a zipped archive.

Finally, the archive was changed from containing one text file to containing multiple text files as of Unicode 5.2.0 (October 2009).

Anomalies and formatting errors are to be found in various versions of the database file. Specifically:

• Unihan-1.txt, the version 2.0.0 Unihan database file, was at some point accidentally truncated on line 330,553 (partway through the data for U+8BC1 证). No corrected version of the file was made available. Instead, it was superseded by the Unihan-2.txt (10 MB) file released with Unicode 2.1.2 in May 1998. The CD that is included with the Unicode Version 2.0 book has the same truncation issue, specifically that the files at {DOS,MAC,UNIX}/MAPPINGS/EASTASIA/UNIHAN.TXT are truncated at the same position.
• The Version 3.1.1 Unihan database file, Unihan-3.1.1.txt, includes the following anomalous record at line 246,442: U+64AC 297.
• The Versions 2.0.0, 2.1.2, 3.0.0, and 3.1.0 Unihan database files are not encoded in UTF-8. Rather, individual property values are encoded using an encoding appropriate for their language, such as Big Five for traditional Chinese.

Please refer to Unicode Technical Note #45, “Unihan Property History” [UTN45], for more information about the history of Unihan database properties, in terms of which properties are included in each version of the Unicode Standard from Version 1.1.5 onward, along with how many ideographs are covered by each property.

References

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

Acknowledgements

John H. Jenkins 井作恆 (RIP) was the author of the initial version of this annex, and served as a co-editor up through and including Version 33 for Unicode Version 15.0.0.

Modifications

The following summarizes modifications from the previous revision of this annex.

Revision 37

• Reissued for Unicode 16.0.0.
• Clarified the relationship between the Equivalent_Unified_Ideograph property and the Unihan database in Section 2.1.1.
• Updated the sorting algorithm examples in Section 2.1.2.
• Added a reference to the RSIndex.txt data file at the end of Section 2.1.2.
• Updated Section 2.1.2 and Section 3.6 to describe a second non-Chinese simplified radical.
• Changed the delimiter of the kAccountingNumeric property from space to N/A.
• Added the provisional kFanqie and kZhuang properties.
• Removed the provisional kFrequency property.
• Updated the syntax and description of the kIRG_GSource, kPhonetic, and kRSUnicode properties.
• Updated the description of the kPrimaryNumeric property.
• Added U+31E4 and U+31E5 to the second table in Section 4.4
• Added a reference to EquivalentUnifiedIdeograph.txt at the end of Section 4.4.

Revision 36 being a proposed update, only changes between revisions 35 and 37 are noted here.

Previous revisions can be accessed with the “Previous Version” link in the header.

© 2008–2024 Unicode, Inc. This publication is protected by copyright, and permission must be obtained from Unicode, Inc. prior to any reproduction, modification, or other use not permitted by the Terms of Use. Specifically, you may make copies of this publication and may annotate and translate it solely for personal or internal business purposes and not for public distribution, provided that any such permitted copies and modifications fully reproduce all copyright and other legal notices contained in the original. You may not make copies of or modifications to this publication for public distribution, or incorporate it in whole or in part into any product or publication without the express written permission of Unicode.

Use of all Unicode Products, including this publication, is governed by the Unicode Terms of Use. The authors, contributors, and publishers have taken care in the preparation of this publication, but make no express or implied representation or warranty of any kind and assume no responsibility or liability for errors or omissions or for consequential or incidental damages that may arise therefrom. This publication is provided “AS-IS” without charge as a convenience to users.

Unicode and the Unicode Logo are registered trademarks of Unicode, Inc., in the United States and other countries.