It is extremely clear that the right hand side phonetic should be 陷. This is a completely different phonetic from 舀. I don't agree that the semantics are hard to clarify for GZ-2352301.
Historically it is common for 𠂊 and 爫 to be swapped.
I don't understand why "Annex S records source separation examples" would imply not suitable for a new UCV. All examples in the Source Code Separation mean they were deemed unifiable, but not unified, because they are encoded separately in the original source tables.
I think precisely because people sometimes failed to recognize it was the same character, unification to 頓 with IVD would help people find this character, without the need for the end user to install additional IMEs or the digitization system to maintain an internal mapping system.
While it may be common for systems in mainland China for academic tools to also come with an ecosystem of tools, such tools are inherently proprietary or specific to a certain system and is not beneficial for data exchange.
It would not make sense for just the base glyph to be encoded as a character, and the glyph with the 口 radical to be coded separately, as that means (1) either there is an explicit decision to discard the variant or (2) the system will need to adopt IVD anyways.
Given that there is other evidence of use, I suggest that this character doesn't need to be withdrawn. However, unification should still be on the table as I believe they (UTC-03353, U+83EF and U+2C73B) are variants.
IRG Working Set 2024v3.0
Source: Henry CHAN
Date: Generated on 2025-12-08
Unification
Showing 13 comments.
In favour of unifiation to 𠽏 U+20F4F.
It is extremely clear that the right hand side phonetic should be 陷. This is a completely different phonetic from 舀. I don't agree that the semantics are hard to clarify for GZ-2352301.
Historically it is common for 𠂊 and 爫 to be swapped.
I don't understand why "Annex S records source separation examples" would imply not suitable for a new UCV. All examples in the Source Code Separation mean they were deemed unifiable, but not unified, because they are encoded separately in the original source tables.
U+20767 𠝧
U+2641F 𦐟
U+26431 𦐱
U+2647E 𦑾
U+2678B 𦞋
U+31ED7 𱻗
U+31EDD 𱻝
I do not suggest that we allow more transcriptions. The IVD is precisely suitable for encoding these cases.
I think precisely because people sometimes failed to recognize it was the same character, unification to 頓 with IVD would help people find this character, without the need for the end user to install additional IMEs or the digitization system to maintain an internal mapping system.
While it may be common for systems in mainland China for academic tools to also come with an ecosystem of tools, such tools are inherently proprietary or specific to a certain system and is not beneficial for data exchange.
It would not make sense for just the base glyph to be encoded as a character, and the glyph with the 口 radical to be coded separately, as that means (1) either there is an explicit decision to discard the variant or (2) the system will need to adopt IVD anyways.
Unify to 㒓 (U+3493) and add new UCV of 達 and 𨔶.
See also 01960 which is a variant of 橽 (U+6A7D):
Per Kushim's comment, there are two variants which are disunified, but are in Extension B:
𣿔 ~ 澾
𩍠 ~ 韃
Unification to 蚸 (U+86B8)?
00858 would also be unified to 坼.
Unify to 𧵍 (U+27D4D) and add a new UCV for the whole top component
Unify to 𥿳 (U+25FF3).
Both U+25FF3 and SAT-10235 are variants of 細.
Support unification to 蝱.
There are a huge number of variants involving 亡 and 亾, and the bulk of encoded ones are in Extension B:
㠩 U+3829 = 巟 U+5DDF
㡃 U+3843 = 㡆 U+3846
𧠬 U+2782C = 𧠰 U+27830
𮎰 U+2E3B0 = 荒 U+8352
𥞙 U+25799 = 𥡃 U+25843
𥿪 U+25FEA = 𥿼 U+25FFC
𩢯 U+298AF = 𩣇 U+298C7
There are some other unencoded examples:
Source: https://dict.variants.moe.edu.tw/dictView.jsp?ID=14706
Source: https://dict.variants.moe.edu.tw/dictView.jsp?ID=14701
Given that there is other evidence of use, I suggest that this character doesn't need to be withdrawn. However, unification should still be on the table as I believe they (UTC-03353, U+83EF and U+2C73B) are variants.
Attributes
Showing 1 comments.
务 should be counted as ⿱攵力 here per Kangxi conventions.
Evidence
Showing 2 comments.
② is already encoded at 𧸅 U+27E05
① and ③ can be unified to it if they are submitted in the future.
(Quoted from the MOE Dictionary entry for A01549)
Potentially this could be a UCV level 2 if there are a huge number of variants of 幼 from V source.
Glyph Design & Normalization
Showing 2 comments.
Other
Showing 4 comments.
The G glyph quotes GHZ:
However, per the MOE dictionary, one version of the original source writes it as ⿰貝㒼
Another form of this character is ⿰睪毛.