Unicode Han Database:
[http://www.unicode.org/charts/unihan.html web-Version],
[http://www.unicode.org/Public/UNIDATA/Unihan.zip Text-Version]

[http://www.unicode.org/reports/tr38/ Unicode Standard Annex #38] (insbesondere [http://www.unicode.org/reports/tr38/#N10211 3.7 Variants])

Drei Achsen:
  * x-Varianten: Bedeutung: Zeichen mit unterschiedlicher Bedeutung können keine Varianten voneinander sein.
  * y-Varianten: abstrakte Form
    * kSimplifiedVariant / kTraditionalVariant
    * kSemanticVariant, kSpecializedSemanticVariant
  * z-Varianten: rein stilistische Varianten, sollten idealerweise gar nicht mehr als einen Codepoint haben
    * kZVariant

Mehrere Langzeichen können auf dasselbe Kurzzeichen abgebildet werden. 

== Beispiel ==

Standardzeichen U+6B77, Variante U+6B74: Die Variante hat einen niedrigeren Codepoint als das Standardzeichen.

Wenn ich es recht verstehe: 
  * Die semantischen Varianten 66C6 und 6B77 sind beide OK als Langzeichen, aber werden beide mit dem gleichen Kurzzeichen wiedergegeben. Wenn man daraus wieder ein Langzeichen macht, dann 6B77.
  * Die Verbindung von 5386 zu 53B2 wird nur in Fenn gemacht, nicht in Lau, Matthews, !MeyerWempe.

Trotzdem kommt mir die Verbindung der Zeichen inkonsequent vor.

|| || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=5386&useutf8=true 5386] || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=5389&useutf8=true 5389] || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=53A4&useutf8=true 53A4] || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=53B2&useutf8=true 53B2] || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=66C6&useutf8=true 66C6] || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=6B74&useutf8=true 6B74] || [http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=6B77&useutf8=true 6B77] || 
|| ||  ||  ||  ||  ||  ||  ||  || 
||= kMandarin =|| LI4 || LI4 || LI4 || LI4 || LI4 || LI4 || LI4 || 
||= kDefinition =|| 1 || 2 || 3 || 1 || 4 || 5 || 5 || 
|| ||  ||  ||  ||  ||  ||  ||  || 
||= kSemanticVariant =|| 53B2 || || 66C6 || 5386 || 53A4 6B74 6B77 || 66C6 6B77 || 66C6 6B74 || 
||= kSimplifiedVariant =|| ||  ||  || 5389 || 5386 ||  || 5386 || 
||= kTraditionalVariant =|| 66C6 6B77 || 53B2 ||  ||  ||  ||  ||  || 
||= kZVariant =|| 6B77 ||  ||  ||  ||  || 6B77 ||  || 

kDefinition:
  1. history; calendar
  1. whetstone; grind, sharpen; whet
  1. to calculate; the calendar
  1. calendar, era
  1. take place, past, history

Zeichentabelle für 5386: 66C6 6B74 6B77, aber auch 53AF 66A6 (und F98B F98C)  --> wo kommt das her?

[[Image(unihan-Beispiel.jpg)]]

Das ist zugegebenermaßen ein besonders schwieriges Beispiel. Trotzdem zeigt es: Die Hoffnung, alle Zeichen für die Suche in Äquivalenzklassen aufzuteilen, am besten noch mit einem ausgezeichnetem "Standardzeichen", ist nicht realistisch. Beispiel: Kurzzeichen 5386 <--> Langzeichen 53B2, und Langzeichen 53B2 <--> Kurzzeichen 5389, aber nicht 5386 <--> 5389 (nicht transitiv). 

Möglicherweise kann man also nur verschiedene Suchstufen anbieten:
  * streng: nur genau das angegebene Zeichen
  * akzeptiere z-Varianten
  * akzeptiere Langzeichen / Kurzzeichen
  * akzeptiere semantische Varianten

Die "akzeptiere"-Optionen können einzeln oder zusammen verwendet werden. Aber wie soll es genau aussehen? Sinnvollerweise wird man von 5386 über 6B77 zu 6B74 kommen, aber nicht von 5389 über 53B2 nach 5386. Formal ist es aber der gleiche Weg.

Auf den Punkt gebracht: Warum ist 6B74 eine semantische Variante von 6B77, aber 66A6 keine semantische Variante von 66C6?

Es gibt außerdem ein core set von Zeichen, die am Attribut "kIICore" (mit dem festen Wert "2.1") erkennbar sind.