Not cognate to WS2017-03505, and form of top component is distinct in the two characters: SAT-06265 means a type of net, and must be written with the net radical; whereas UK-10504 means a pimple, and does not use the net radical. The two glyphs are not mutually acceptable, so oppose unification per PnP 2.1.3 Non-cognate Rule.
The evidence shows the proposed character in contrast with 佇. I agree that it is probably a variant of 佇, but the evidence gives them slightly different meanings so it may be best not to unify.
UK-20727 is composed of four separate 'mountain' characters, and so cannot be written as ⿰出出. It is not cognate with 𰄔 (U+30114), and the two characters have different glyph shapes, therefore we strongly oppose unification with U+30114.
Not unify to 𫭱 (U+2BB71) as this is not a unifiable variant (木 radical as opposed to 土 radical). Even if U+2BB71 should be the preferred form of this character, UK-20901 still needs to be encoded as this form is given in at least two major modern printed scholarly works. See also L2/21-101 for discussion of this character by Alexander Zapryagaev.
Unify to 虷 (U+8677). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the character is. In this case it is almost certainly a mistake or variant for U+8677. Unify according to UCV principle a-1 (differences in stroke initiation direction).
Unification
It is ridiculous to say "“千” and “干” are apparently different characters and they can't be unified" without providing any evidence for the meaning of the ⿰虫千. The telegraph code book is not a dictionary but only lists characters in current use, so ⿰虫千 must be presumed to be a mistake/variant of 虷 unless reliable evidence that it is a separate character can be produced.
Unify to 豻 (U+8C7B). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the character is. In this case it is almost certainly a mistake or variant for U+8C7B. Unify according to UCV principle a-1 (differences in stroke initiation direction).
Unification
It is ridiculous to say "“千” and “干” are apparently different characters and they can't be unified" without providing any evidence for the meaning of the ⿰豸千. The telegraph code book is not a dictionary but only lists characters in current use, so ⿰豸千 must be presumed to be a mistake/variant of 豻 unless reliable evidence that it is a separate character can be produced.
Unify to 魆 (U+9B46). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the character is. In this case it is almost certainly a mistake or variant for U+9B46.
Unification
In this case 戊 is an obvious and minor mistake for 戉. We should not enode error forms of characters just because a component is miswritten. Strongly support unification with 魆 (U+9B46).
Unify to 偭 (U+506D). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the characters are. In this case, 靣 is well-known variant of 面, so it is best to unify UTC-03188 with 偭 and register an IVS for this glyph form.
I agree with Huang Junliang that full edition information should be provided, and it is not sufficient to simply give the source as "康熙字典". The 中华书局 edition p. 1478 has 𩹆, so the proposed character is certainly an error form. I do not think that we should encode error forms of characters from poor-quality editions of the Kangxi dictionary.
Evidence is the same as provided for GKJ-00847 which is ⿰钅玻. Perhaps the incorrect evidence image has been provided for GKJ-00846. Please provide evidence showing ⿰金玻 if possible.
The traditional form is attested, and ideally both traditional and simplified forms should be encoded. This evidence showing traditional form is from W. Lobscheid, "A Chinese and English Dictionary" (Hong Kong: Noronha & Sons, 1871) P. 69
The evidence does not seem sufficient to encode this character. The first evidence image refers to 《汉印文字征》, so it is necessary to see what glyph is actually shown in 《汉印文字征》. The second image does not seem to have any relevance to the proposed character.
It looks like an error form of U+8D12 贒, with 忠 written cursively like 虫. The evidence from 康熙字典 shown by Tao Yang only shows 贒. Suggest not encoding without better evidence.
The second evidence shows a misprint of 士 shì as 土 tǔ. As the character is intended to phonetically represent the letter 'x' (eks) we can be certain that the 刻士 kèshì form (haksi in Cantonese) in the first evidence is correct and the 刻土 kètǔ form in the second evidence is an error.
We utterly reject the nonsensical comment made here and for many other UK characters by Wang Xieyang. A logo is "a small design used as the symbol of an organization, etc." (Chambers Dictionary, 1998), and quite obviously none of the characters proposed by the UK are either logos representing an organization or embedded images. The examples clearly show that the proposed characters are used in running text in exactly the same context as other encoded CJK unified ideographs.
The glyph should be modified to reflect the actual shape shown in the first evidence: 口 and 日 elements of 亯 should not be the same width; 艹 should be 卝; and 干 should have the lower horizontal stroke wider than upper horizontal stroke.
Evidence shows ⿱𥘉虫 not ⿱初虫. I agree with Huang Junliang that this is probably an error form, but if it is kept the glyph should be redesigned to match the evidence.
Given the pronounciation, the expected glyph form should be ⿰口啄. As U+5544 啄 unifies ⿰口豖(GHTKV) and ⿰口豕(J), the expected glyph form for China should be ⿲口口豖, so we suggest normalizing to use 豖 instead of 豕.
The first source shows ⿱⿰里殳木 which we normalize to ⿱毀木 which is the form shown in the second source. Normalizing to ⿱毁木 or ⿱⿰圼殳木 are also possibilities that could be discussed.
We noted and explained this difference in the spreadsheet:
The right side component is written as 𫩧 (U+2BA67) which we normalize to 含. Cf. U+246A5 𤚥 in UK-20681-1.jpg, UK-20681-2.jpg, UK-20713.jpg which is written as ⿰牟𫩧. We suggest making a UCV for 含~𫩧.
Note that two evidences are shown, and the first evidence shows ⿰口掹, so it is not obvious whether ⿰口掹 or ⿰口⿱𡥅皿 is the preferred glyph form. Font glyph shows ⿰口掹 but IDS is ⿰口⿱𡥅皿 so either glyph or IDS must be changed.
U+20544 𠕄 has Cantonese reading nap1 so should be the phonetic for the proposed character. The gap in the evidence glyph is perhaps a printing mistake, but in any case the proposed character should be normalized to ⿰氵𠕄.
The new evidence supports encoding as a V-source character, but I still think the original China evidence is an error, so there is still insufficient evidence for encoding as a G-source character.
There are so many wrongly-designed glyphs in the China submission! (probably more than 5%) It seems that the font glyphs were designed on the basis of IDS only, and in many cases the IDS was wrong so the glyph was wrongly designed. The font glyph designer should always have view of the evidence to ensure correct glyph design and acceptable quality of IRG submission.
I agree with Mr Huang's comment that these examples of systematically constructed characters should not be encoded as individual CJK unified ideographs. If there is evidence that Liáng Guócháng's system for naming organic chemical compounds was actually used by the scientific community in China, then we can consider encoding them using some other mechanism (e.g. encoding a set of components which could be ligated together). However, if these characters are only attested in Liáng Guócháng's 1920 proposal and other works by the same author, then I do not believe that it is appropriate to encode them at all. Certainly I would be strongly opposed to defining a new Unicode block for a failed scientific orthography.
I agree completely with Conifer Tseng that the proposed character should be an error for 卟, so suggest postponing pending additional evidence that ⿰口小 is the correct glyph form.
This is not a CJK unified ideograph, but a kana ligature for toki (see attached image from Arthur Rose-Innes' "Beginners' Dictionary of Chinese-Japanese Characters" (1977). The fact that the kana ligature tomo was incorrectly encoded in Ext. C as U+2A708 is not a precedent for encoding additional kana ligatures as CJK unified ideographs. SAT should propose the kana ligatures tomo and toki for encoding in one of the kana blocks.
Doubtful that this kana-ideograph ligature for to-iu should be considered as a CJK unified ideograph. As the example shows that it is used in the same way as kana, it probably more appropriate to propose to encode it in one of the kana blocks.
Comment
The evidence image shows that the proposed character is used in the same way as kana and reading marks (written smaller than a CJK ideograph, and positioned to the bottom right of a CJK ideograph), so in order to properly support this sizing and positioning behaviour in fonts it would be best to treat this kana-ideograph hybrid as a kana letter, and encode it in one of the kana blocks. This is completely different to some of the other hybrid characters which do behave like CJK ideographs, so I do not think Korean hybrid characters are a good analogy. IMO it should not be encoded as a CJK unified ideograph without compelling evidence that it is treated as a CJK ideograph in running text.
The proposed character has reading jaap3 (meaning "to tuck in"), and U+64EA 擪 has Cantonese reading ngaap3 with similar meaning (to press down with the fingers), so likely to be the same character. As the glyph form is not clear in the provided evidence, I suggest postponing pending clearer glyph evidence, and evidence that it is semantically distinct from U+64EA.
IRG Working Set 2021v1.0
Source: Andrew WEST
Date: Generated on 2026-01-19
Unification
Unify to 𡗘 (U+215D8)
Unify to 𫙓 (U+2B653) by UCV #322
Agree with Huang Junliang that the evidence shows an error form of U+2A22A, and it should not be encoded without better evidence.
Unify to 鵖 (U+9D56) by UCV #355.
Unify to 鴞 (U+9D1E).
Compare UCV #394 and #395 which unify 了 and 丂 shapes. Consider adding an additional UCV.
Unify to 鵵 (U+9D75) (Evidences 1, 3 and 4 actually show 鵵) by UCV #307.
Unify to 𰼺 (U+30F3A) by UCV #74
Unify to 麉 (U+9E89) by UCV #180
Unify to 𰽆 (U+30F46) by UCV #111
Unify to 𭡏 (U+2D84F) by UCV #445
Unify to 𫣷 (U+2B8F7) by UCV #175
The evidence actually shows U+2C266, not the form proposed by Korea.
Unify to 𮣉 (U+2E8C9) by UCV #112. Not relevant if linguistically cognate or not.
Unify to 𮆝 (U+2E19D) by UCV #55
Unify to 𤥢 (U+24962) by UCV #70
Unify to 𫡰 (U+2B870)
Withdraw as it is a duplicate of WS2017-01096 (UTC-03041)
We do not oppose unification if a new UCV for 沓~㳫 is defined.
Unify to 𡃤 (U+210E4) by UCV #324
Unify to 攋 (U+650B) as second evidence image clearly shows T-form of 攋. First evidence is probably a mistake.
Unify to 憃 (U+6183) and add a new UCV for 舂
Unify to 虷 (U+8677). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the character is. In this case it is almost certainly a mistake or variant for U+8677. Unify according to UCV principle a-1 (differences in stroke initiation direction).
It is ridiculous to say "“千” and “干” are apparently different characters and they can't be unified" without providing any evidence for the meaning of the ⿰虫千. The telegraph code book is not a dictionary but only lists characters in current use, so ⿰虫千 must be presumed to be a mistake/variant of 虷 unless reliable evidence that it is a separate character can be produced.
Unify to 豻 (U+8C7B). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the character is. In this case it is almost certainly a mistake or variant for U+8C7B. Unify according to UCV principle a-1 (differences in stroke initiation direction).
It is ridiculous to say "“千” and “干” are apparently different characters and they can't be unified" without providing any evidence for the meaning of the ⿰豸千. The telegraph code book is not a dictionary but only lists characters in current use, so ⿰豸千 must be presumed to be a mistake/variant of 豻 unless reliable evidence that it is a separate character can be produced.
Unify to 魆 (U+9B46). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the character is. In this case it is almost certainly a mistake or variant for U+9B46.
In this case 戊 is an obvious and minor mistake for 戉. We should not enode error forms of characters just because a component is miswritten. Strongly support unification with 魆 (U+9B46).
Unify to 偭 (U+506D). As telegraph code books should only list relatively common characters that are well-attested elsewhere, any unencoded characters must be variants or mistakes of already-encoded characters. But as the code books do not provide readings or meanings for the characters listed we have to guess what the true identification of the characters are. In this case, 靣 is well-known variant of 面, so it is best to unify UTC-03188 with 偭 and register an IVS for this glyph form.
Unify to 𡁸 (U+21078) by UCV #284
Unify to 𤒲 (U+244B2) by UCV #184a
Attributes
Evidence
Glyph Design & Normalization
The right side component is written as 𫩧 (U+2BA67) which we normalize to 含. Cf. U+246A5 𤚥 in UK-20681-1.jpg, UK-20681-2.jpg, UK-20713.jpg which is written as ⿰牟𫩧. We suggest making a UCV for 含~𫩧.
Other