This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.
Date/Time: Mon Oct 02 19:42:06 CDT 2023
ReportID: ID20231002194206
Name: Eiso Chan
Report Type: Public Review Issue
Opt Subject: Correction for PRI 483, UAX #38
The current kCantonese property value for U+8D5D 赝 is ngan3, that is very strange. The kCantonese property value for U+8D0B 贋 and U+8D17 贗 are both ngaan6. 《广州音字典》 shows the only one Cantonese reading is also ngaan6 (ngan⁶ in that dictionary). ngan3 is not suitable for U+8D5D 赝 everywhere. The Cantonese word ngan3 means “to shake, to jiggle”, which I mentioned in p. 3 of IRGN2646. The kCantonese property value for U+8D5D 赝 should be changed to ngaan6 from ngan3.
Date/Time: Thu Dec 14 11:59:07 CST 2023
ReportID: ID20231214115907
Name: Mark Davis
Report Type: Public Review Issue
Opt Subject: 483
The Delimiter for kDefinition is incorrect; according to the Description it should be semicolon. "Major definitions are separated by semicolons, and minor definitions by commas." https://www.unicode.org/reports/tr38/tr38-33.html#kDefinition The two changes would be Delimiter semicolon Syntax [^\t";]+
Date/Time: Sun Dec 17 15:31:25 CST 2023
ReportID: ID20231217153125
Name: Ken Lunde
Report Type: Public Review Issue
Opt Subject: 483
I propose that the provisional kFrequency property be dropped from the Unihan database for Unicode Version 16.0. This property was introduced in Version 3.2 (2002), covers barely over 5,000 ideographs (approximately 5% of the repertoire), and hasn't changed at all since its introduction. I am a big fan of frequency data, but I am not a fan of including it in such a database, because the moment it is added, it becomes obsolete.
Feedback above this line reviewed during UTC #178 in January 2024.
Date/Time: Thu Jan 18 00:41:24 CST 2024
ReportID: ID20240118004124
Name: Robin Leroy
Report Type: Public Review Issue
Opt Subject: 483
In Unicode Versions 13.0 through 15.1, two characters have a kHanyuPinyin value but no kMandarin value: U+228F5 𢣵 (kHanyuPinyin=42364.160:chú since Unicode 13.0) U+2574C 𥝌 (kHanyuPinyin=42588.020:jī since Unicode 12.0) These two characters should have the corresponding kMandarin values, thus U+228F5 𢣵 should have kMandarin=chú, and U+2574C 𥝌 should have kMandarin=jī.
Date/Time: Thu Feb 08 07:22:27 CST 2024
ReportID: ID20240208072227
Name: Robin Leroy
Report Type: Public Review Issue
Opt Subject: 483
While playing with invariant tests as part of an old action item (151-A143) now assigned to Josh Hadley and me, I noticed that the kTotalStrokes value of the Equivalent_Unified_Ideograph value of CJK strokes is not always 1; it is 2 for CJK STROKE HZZZG ㇡, whose Equivalent_Unified_Ideograph is 𠄎. Looking at the chart glyphs, and comparing with 乃 which is definitely meant to have a ㇡, the G- and T-source glyphs look consistent with 乃, and at least the G-source glyph looks to me like it has one stroke. Should the kTotalStrokes value of 𠄎 be 1? Or perhaps 1 2? Or is the G-source glyph wrong? If https://www.zdic.net/hans/%F0%A0%84%8E and https://www.zdic.net/hant/%F0%A0%84%8E are to be believed, that would point towards the G-source glyph being right, and kTotalStrokes=1 2 (and kRSUnicode=5.0 6.1 I suppose). While discussing this with a friend who is familiar with zh-Hant-TW, the kTotalStrokes value of 廴 also came up. While it has 2 strokes in zh-Hans-CN, this radical has three strokes in TW, see https://dict.revised.moe.edu.tw/dictView.jsp?ID=11124. Should its kTotalStrokes value be 2 3 (and likewise should the kRSUnicode=54.n characters have kTotalStrokes=n+2 n+3)? I asked the above questions to Ken Lunde, who replied as follows: > What you discovered is the tip of the proverbial iceberg. See document L2/22-201. > This is a systemic issue, and our plan is to address it en masse, not one-by-one. > With that said, please submit feedback through the Contact Form about this, and the CJK & > Unihan Group will discuss. The IDS of U+2010E 𠄎 does not lend itself to programmatic > correction, so I would prefer to handle this particular case separately.
Date/Time: Thu Feb 15 04:53:59 CST 2024
ReportID: ID20240215045359
Name: Ryusei Yamaguchi
Report Type: Public Review Issue
Opt Subject: 483
The proposed change to the delimiter for the kDefinition property was
initially suggested in Report ID: ID20231214115907, subsequently recorded
in L2/24-012, and has been incorporated into the draft. However, using
semicolons within the kDefinition property appears more akin to traditional
dictionary punctuation rather than a delimiter for an array of strings.
This raises several concerns:
1. Space After Semicolons: The current format for kDefinition values,
such as "engraving tool; carve, engrave" for U+93B8 鎸, implies a JSON
interpretation as ["engraving tool", " carve, engrave"], leaving an
inappropriate trailing space.
2. General Descriptions: Some kDefinition entries provide general
character properties unrelated to definitions per se, including
language or variant information, e.g.:
"(J) non-standard form of U+559C 喜, to like, love, enjoy; a joyful
thing" for U+3402 㐂. Descriptions for U+3421 㐡 and U+342E 㐮
include similar issues.
3. Semicolons Within Parentheses: Certain kDefinition values feature
semicolons inside parentheses, which complicates any straightforward
split by semicolons. This issue is evident in entries such as: For
U+3A97 㪗: "(a dialect) to open (a parcel; a bundle or a package); to
unroll (a scroll, etc.); (Cant.) to rest, catch one's breath", where
semicolons serve multiple roles within and outside parentheses. For
U+25462 𥑢: "boron (obsolete; see U+787C 硼)", demonstrating how
semicolons within parentheses can denote additional information rather
than separate definitions.
Given these issues, it's recommended to reconsider or revert the proposed
delimiter change.
For reference:
ID20231214115907: https://www.unicode.org/review/pri483/feedback.html#ID20231214115907
L2/24-012: https://www.unicode.org/L2/L2024/24012-cjk-unihan-group-utc178.pdf
Date/Time: Mon Feb 19 00:08:09 CST 2024
ReportID: ID20240219000809
Name: Judith Chen
Report Type: Public Review Issue
Opt Subject: 483
The kMandarin values of some characters may be erroneous. - U+99CD 駍: péi -> pēng As UAX #38 states, "(kMandarin is) The most customary pīnyīn reading for this ideograph. When there are two values, then the first is preferred for zh-Hans (CN) and the second is preferred for zh-Hant (TW). When there is only one value, it is appropriate for both." However, the preferred reading in Taiwan of U+99CD 駍 should be pēng, according to 重編國語辭典修訂本 (Revised Mandarin Chinese Dictionary) published by Taiwan's Ministry of Education and CNS11643 中文全字庫 website managed by Taiwan's Ministry of Digital Affairs. Besides, GB/Z 40637-2021 古籍印刷通用字规范字形表 (Standard glyph list of generally used Chinese characters for ancient books publishing) released by China's State Administration for Market Regulation also suggests that pēng is the preferred reading in PRC (p. 128), for the standard claims that "本表只收常用音" (the list records common readings only) (p. 230). - U+42F3 䋳: běi -> bèi 汉语大字典 (2nd ed) regards it as a variant of U+8919 褙 and gives bèi as the only reading (p. 3652). CNS11643 gives bèi, too. - U+4876 䡶: bèi -> pì GB/Z 40637-2021 (p. 130) and CNS11643 both give pì as the preferred reading. - U+4A06 䨆: bí -> bì 汉语大字典 (2nd ed) regards it as a variant of U+9DE9 鷩 (p. 4421), suggesting that its reading should be bì. CNS11643 gives bì, too. - U+4D44 䵄: bí -> fēng 汉语大字典 (2nd ed) regards it as a variant of U+9EB7 麷 (p. 4910), suggesting that its reading should be fēng. CNS11643 gives fēng, too. Reference: - GB/Z 40637-2021: https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=52E2DE28D439C1937EE09AE4B5AA615B - 駍 in 重編國語辭典修訂本: https://dict.revised.moe.edu.tw/dictView.jsp?ID=770&word=%E9%A7%8D - 駍 in CNS11643: https://www.cns11643.gov.tw/wordView.jsp?ID=152944 - 䋳 in CNS11643: https://www.cns11643.gov.tw/wordView.jsp?ID=216618 - 䡶 in CNS11643: https://www.cns11643.gov.tw/wordView.jsp?ID=287841 - 䨆 in CNS11643: https://www.cns11643.gov.tw/wordView.jsp?ID=219990 - 䵄 in CNS11643: https://www.cns11643.gov.tw/wordView.jsp?ID=221497
Date/Time: Thu Feb 22 00:44:23 CST 2024
ReportID: ID20240222004423
Name: Eiso Chan
Report Type: Public Review Issue
Opt Subject: 483
In kMandarin property values, there are 152 entries without the tones. In general, there must be the tones for the Putonghua reading of one single Hanzi (单字音), but some modern dictionaries (like 《现代汉语词典》) use the so-called fifth tone (aka 轻声) for some characters very discreetly, such as 们 reads as ·men not men. On the other hand, U+275C8 𧗈 reads as n, it must be wrong. Suggestions: 1. Re-check the Putonghua readings for these 152 Hanzi. 2. If the modern dictionaries use the so-called fifth tone for one Hanzi, we can accept the form as ·xxx (like ·men); if not, we should modify to the common forms. 3. Remove some entries if there are no acceptable Putonghua readings. These 152 entries are shown as below. U+35D1 bai 㗑 U+37F7 da 㟷 U+4E48 me 么 U+4E5B ya 乛 U+4E7C cui 乼 U+4E86 le 了 U+4E87 ma 亇 U+4EAA ye 亪 U+4EEC men 们 U+4F2C ze 伬 U+4F66 shi 佦 U+4FA4 ta 侤 U+5011 men 們 U+516F han 兯 U+5319 shi 匙 U+5417 ma 吗 U+5427 ba 吧 U+5440 ya 呀 U+5457 bei 呗 U+545A wen 呚 U+5462 ne 呢 U+5497 zuo 咗 U+549C ta 咜 U+54C7 wa 哇 U+54D8 xing 哘 U+5504 bei 唄 U+5525 lang 唥 U+554A a 啊 U+5566 la 啦 U+55CE ma 嗎 U+55E6 suo 嗦 U+561B ma 嘛 U+561E lei 嘞 U+5677 hm 噷 U+569C me 嚜 U+56A1 hai 嚡 U+56CE zen 囎 U+56D6 lo 囖 U+578A min 垊 U+57AF da 垯 U+580F fang 堏 U+58B6 da 墶 U+58ED san 壭 U+5AF2 ma 嫲 U+5B50 zi 子 U+5C21 kun 尡 U+5DBF ru 嶿 U+5DEC pu 巬 U+5DED pu 巭 U+5F94 zhi 徔 U+5FC4 xin 忄 U+603D mo 怽 U+6077 xiao 恷 U+6150 gong 慐 U+61F3 hui 懳 U+624C shou 扌 U+62A3 yun 抣 U+63B5 ming 掵 U+63B9 meng 掹 U+63FC beng 揼 U+6762 jiang 杢 U+67A0 zui 枠 U+6872 po 桲 U+6926 quan 椦 U+698B chu 榋 U+6A75 san 橵 U+6A7A jian 橺 U+6A7B chu 橻 U+6AF5 jiao 櫵 U+6B1F guang 欟 U+6C07 lu 氇 U+6C1E bin 氞 U+6C35 shui 氵 U+6C62 tu 汢 U+6F48 zong 潈 U+6F9A yu 澚 U+6FF9 me 濹 U+702E ling 瀮 U+709E bian 炞 U+7140 wei 煀 U+7177 liang 煷 U+71DD jing 燝 U+7220 ju 爠 U+7233 han 爳 U+74F2 wa 瓲 U+7629 da 瘩 U+7666 me 癦 U+7684 de 的 U+7740 zhe 着 U+7858 qing 硘 U+7A43 rong 穃 U+7A5D zui 穝 U+7AA7 zhuo 窧 U+7B39 ti 笹 U+7BD2 shi 篒 U+7C17 liang 簗 U+7C2F qi 簯 U+7C42 shi 籂 U+7C56 qian 籖 U+7C8C yin 粌 U+7C8F tai 粏 U+7D26 ba 紦 U+7DD5 qi 緕 U+7E4C sha 繌 U+7E67 yun 繧 U+7E68 da 繨 U+7F3C qi 缼 U+7F40 zhao 罀 U+7FAA yang 羪 U+810C nin 脌 U+8126 de 脦 U+8279 cao 艹 U+8421 bo 萡 U+8457 zhe 著 U+848F you 蒏 U+84FF xu 蓿 U+8781 ban 螁 U+87A9 tiao 螩 U+87D0 chang 蟐 U+88C4 xing 裄 U+88F3 shang 裳 U+8FF2 qu 迲 U+915C fu 酜 U+933B wu 錻 U+9386 qian 鎆 U+93F1 zhang 鏱 U+93F2 qian 鏲 U+9466 xian 鑦 U+9596 shui 閖 U+97A1 la 鞡 U+990E le 餎 U+9979 le 饹 U+9B98 dai 鮘 U+9D64 jiao 鵤 U+9EB6 chi 麶 U+9EBC me 麼 U+9EBF mo 麿 U+20BBF sa 𠮿 U+20C8E fa 𠲎 U+20D68 de 𠵨 U+21121 zhe 𡄡 U+2332D hui 𣌭 U+23424 jiu 𣐤 U+23B36 ba 𣬶 U+23B37 ba 𣬷 U+24DDF la 𤷟 U+25AFD shi 𥫽 U+26570 duo 𦕰 U+266E8 lao 𦛨 U+275C8 n 𧗈 U+292F7 la 𩋷 U+29F87 hu 𩾇
Date/Time: Sun Feb 25 21:10:26 CST 2024
ReportID: ID20240225211026
Name: Nathan G Glenn
Report Type: Error Report
Opt Subject: Unihan
The kRSUnicode field for the character 亀 has the apostrophe doubled, meaning that it does not match the syntax specification (this broke unihan_etl, which relied on the syntax specification for parsing). Current value: 5.10 213''.0 Should be: 5.10 213'.0 Here's the page for it: https://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E4%BA%80
Date/Time: Mon Mar 11 02:29:11 CDT 2024
ReportID: ID20240311022911
Name: Eiso Chan
Report Type: Public Review Issue
Opt Subject: 483
The current kCantonese property value for U+282CD 𨋍 is wan1, but there are two values before 13.0.0: wan1 and wen1. In the daily life, we use wen1 not wan1. I also mentioned this issue when I proposed the corresponding simplified form in L2/24-056 with Liang Xin. The current value is shown as below: U+282CD kCantonese wan1 I suggest update as below: U+282CD kCantonese wen1
Date/Time: Fri Mar 15 20:26:46 CDT 2024
ReportID: ID20240315202646
Name: Paul Masson
Report Type: Error Report
Opt Subject: Variants for U+9759 静
This character is currently listed in the database as being its own simplified and traditional variant, both of which entries are patently incorrect. The correct traditional variant U+975C 靜 should of course remain in the database.
Date/Time: Mon Mar 25 19:01:10 CDT 2024
ReportID: ID20240325190110
Name: Paul Masson
Report Type: Error Report
Opt Subject: kTraditionalVariant for U+5729 圩
This character is an alternate simplified form of U+589F 墟. This is not indicated in the database.
Date/Time: Thu Mar 28 17:21:02 CDT 2024
ReportID: ID20240328172102
Name: Ken Lunde
Report Type: Public Review Issue
Opt Subject: 483
One of the things that fell out of last week's IRG #62 meeting was the acknowledgement of a second non-simplified Chinese version of Radical 212 (aka dragon), which was encoded in its prime form in the Extension H block as U+31DE5 𱷥. The evidence in its IRG Working Set 2017 record clearly demonstrates the simplified/traditional relationship: https://hc.jsecs.org/irg/ws2017/app/index.php?id=03252 This was discussed during the IRG meeting, and the IRG decided to append ".3" to identify a second non-Chinese simplified radical, meaning 212.3. The IRG appends ".0" to the radical number for traditional, ".1" for Chinese simplified, and ".2" for non-Chinese simplified. The latter two are equivalent to the use of the single and double apostrophe in the kRSUnicode property values. I propose that we add a triple apostrophe to handle a second non-Chinese simplified radical. Another side benefit is that the number that is appended to the Kangxi Radical number in IRG data will correspond to the number of apostrophes in the kRSUnicode property value. In terms of other changes, the syntax of the kRSUnicode property would need to be updated, the text of UAX #38 would need to be updated to describe secondary non-Chinese simplified radicals, and the following line would need to be added to the UCD's CJKRadicals.txt data file (similar to the ones for 182'' and 208'' that lack a value for the second field): 212'''; ; 31DE5 The Extension H block also includes an ideograph that would benefit from a second kRSUnicode property value, so the following would be the two kRSUnicode property value changes: U+31DE5 𱷥 kRSUnicode 117.6 → 212'''.0 117.6 U+31E22 𱸢 kRSUnicode 118.11 → 118.11 212'''.6 In addition, IRG Working Set 2021 includes four ideographs that would benefit from this second non-Chinese simplified radical, and their discussion records indicate that 212.3 will either be their primary or secondary radicals: https://hc.jsecs.org/irg/ws2021/app/index.php?id=00027 = 212.3 primary https://hc.jsecs.org/irg/ws2021/app/index.php?id=00880 = 212.3 secondary https://hc.jsecs.org/irg/ws2021/app/index.php?id=02082 = 212.3 secondary https://hc.jsecs.org/irg/ws2021/app/index.php?id=02595 = 212.3 secondary That is all.
Date/Time: Tue Apr 02 06:32:04 CDT 2024
ReportID: ID20240402063204
Name: Judith Chen
Report Type: Public Review Issue
Opt Subject: 483
In the current version of the Unihan database, U+8034 耴 has a kMandarin value of ‘yì’ and a kCantonese value of ‘ngat6’, while U+43B2 䎲 has a kMandarin value of ‘zhé’, a kCantonese value of ‘zip3’, and a kDefinition value of ‘ear lobe; lobule’. However, these may not be correct. As UAX #38 states, "(kMandarin is) The most customary pīnyīn reading for this ideograph. When there are two values, then the first is preferred for zh-Hans (CN) and the second is preferred for zh-Hant (TW). When there is only one value, it is appropriate for both." Therefore, we must consider their usage in both the PRC and Taiwan. In the PRC, according to dictionaries like 《辞海》 and 《汉语大字典》, U+2652E 𦔮 means “耳垂” (‘ear lobe’) and is pronounced ‘zhé’ (陟葉切), while U+8034 耴 is used in the word “聱耴” which means “众多的声音” (‘many sounds’) and is pronounced ‘yì’ (魚乙切). On the other hand, in Taiwan, according to 《異體字字典》 released by Taiwan's Ministry of Education, the preferred reading of U+8034 耴 is ‘zhé’, while U+43B2 䎲 has ‘yì’ as its preferred reading. Both characters mean “耳垂” (‘ear lobe’). If we look at the kJapanese values of these characters, we may find them more confusing. U+8034 耴 has a kJapanese value of ‘チョウ ジョウ ニョウ’, the first coming from “陟葉切” while the latter two coming from “昵輙切”. U+43B2 䎲 has a kJapanese value of ‘ギツ ゴチ’, which comes from “魚乙切”. U+2652E 𦔮 has a kJapanese value of ‘チョウ ジョウ’, similar to U+8034 耴. There is no doubt that U+43B2 䎲, composed of “耳” and “乙”, is a “形聲” (pictophonetic) character, and “乙” (the component on the right) reflects its pronunciation. Therefore, U+43B2 䎲 should have a kMandarin value of ‘yì’ and a kCantonese value of ‘ngat6’. Since U+43B2 䎲 in Taiwan can mean “耳垂” (‘ear lobe’), its kDefinition value can remain unchanged. As for U+8034 耴, the thing is a little complicated. First, it is pronounced differently in the PRC and Taiwan, so its kMandarin value should include ‘yì’ and ‘zhé’. Moreover, its current H-source glyph is the same as the G-source glyph of U+2652E 𦔮, suggesting that its kCantonese value should also be ‘zip3’, the same as “輒”. To summarise, I suggest that the Unihan database be changed as follows: - U+8034 耴 - kMandarin: yì -> yì zhé - kCantonese: ngat6 -> zip3 - kDefinition: (empty) -> ear lobe; lobule - U+43B2 䎲 - kMandarin: zhé -> yì - kCantonese: zip3 -> ngat6 That is all.
Feedback above this line reviewed during UTC #179 in April 2024.
Date/Time: Fri Apr 19 20:15:58 CDT 2024
ReportID: ID20240419201558
Name: Eiso Chan
Report Type: Public Review Issue
Opt Subject: 483
In April 19th, 2024 (甲辰龙年谷雨), Tencent Sogou released one video on U+3236D 𲍭 (WS2017-04919). Please see https://m.weibo.cn/status/5024879044727275 https://www.xiaohongshu.com/discovery/item/66220b820000000001032dd8 . There are also two follow-up reports. Please see https://mp.weixin.qq.com/s/f7jD0OQqR0YhTW2_z5EOsA https://mp.weixin.qq.com/s/hQrZJLkMtQaPxDyqKqEKrg . Those materials and the original evidence provided by UK all show the Putonghua reading is tún. And the original evidence for the corresponding traditional form U+3235B 𲍛 (WS2017-04893) shows the fanqie is 徒軍切 which matched the Putonghua reading. I request to add the following properties values. U+3235B kFanqie 徒軍 U+3235B kMandarin tún U+3236D kMandarin tún Thanks for Mr. Feng Lei’s helps, and I have posted the links to ORT.
Date/Time: Tue May 28 20:48:50 CDT 2024
ReportID: ID20240528204850
Name: Eiso Chan
Report Type: Public Review Issue
Opt Subject: 483
IRGN2691 shows U+2E146 𮅆 is also used for the names of one series of musical instruments in Yunnan Province. Please the footnote of p.6 of IRGN2691A. I request to add the kMandarin property value of U+2E146 𮅆 as bǐ as IRGN2691 shows.
Date/Time: Sat Jun 08 19:51:07 CDT 2024
ReportID: ID20240608195107
Name: Paul Masson
Report Type: Error Report
Opt Subject: kMandarin for U+4680 䚀
The Mandarin reading for this character is not currently in the database. Presumably it should be jiàn as the simplified form of U+8266 艦.
Date/Time: Thu Jun 13 04:48:32 CDT 2024
ReportID: ID20240613044832
Name: oldherl
Report Type: Error Report
Opt Subject: kDefinition.txt in Unihan database
I found the Unihan kDefinition for character U+9527 锧 is "tungsten (element 74, W)". But I believe it doesn't have such a meaning in Chinese. The character for tungsten in Chinese is 钨 U+94A8. Is it an error? Or is it a meaning in other languages? Thanks.
Date/Time: Sun Jun 30 21:36:56 CDT 2024
ReportID: ID20240630213656
Name: Judith Chen
Report Type: Public Review Issue
Opt Subject: 483
I recently spent some time checking the kGB3 values in the Unihan database and have found the following issues: The kGB3 value of U+53D1 发 should not be `1957`. This is obvious because 发 is a simplified hanzi that had been included in GB0 (GB 2312—80); hence, it is impossible to be included in GB3, a traditional hanzi set. In fact, in GB2 (GB 7589—87, the simplified counterpart of GB3), the hanzi placed at 19-57 (in ku-ten form) is U+72AE 犮. Therefore, I suggest moving the kGB3 value `1957` from U+53D1 发 to U+72AE 犮. The kGB3 value of U+5FF9 忹 should not be `4923`. Before Unicode 6.0, U+5FF9 忹 used to have the kIRG_GSource value `3-5137`; however, if we check GB2, we will find that the hanzi placed at 49-23 is actually U+225D6 𢗖. The kIRG_GSource values of these two characters were corrected in Unicode 6.0 — now it is U+225D6 𢗖 that has the kIRG_GSource value `G3-5137`. But unfortunately, only kIRG_GSource values were corrected, so the kGB3 values are still erroneous. Therefore, I suggest moving the kGB3 value `4923` from U+5FF9 忹 to U+225D6 𢗖. To summarise, this feedback suggests the following changes to kGB3 values in the Unihan database: - U+53D1 发: 1957 -> (null) - U+5FF9 忹: 4923 -> (null) - U+72AE 犮: (null) -> 1957 - U+225D6 𢗖: (null) -> 4923 That is all.