If you have a rare character in your legal name, you may have seen this happen: a bank clerk types it, the system refuses, and you are asked to use a different character instead. The character is not obscure to you — it is your name. Since 2023 the standard that would fix this has been mandatory in China, and the reason people still hit the problem is that it fails in four different ways that look identical from the counter.
The standard, and the date the excuse expired
China's national character-encoding standard, GB 18030, was revised in 2022 and became compulsory from 1 August 2023. And "compulsory" is the key word. GB 18030 is a mandatory national standard, not a recommendation for vendors to weigh against their development costs.
An amendment published in September 2024 added 9,793 characters, of which 622 came from the public-security population font — the character set maintained for the national ID system. That provenance is the interesting part. Those 622 characters are in the standard because they are in real people's names on real identity cards. Systems were given a year to adopt the addition, and that transition closed on 1 October 2025.
So a system that cannot store one of those characters today is not behind on an optional upgrade. It is non-compliant with a mandatory standard whose grace period has expired.
Four failures, one symptom
From your side of the counter, the failure always looks the same: the name will not go in, or it goes in and comes out wrong. Behind the screen, however, four different things could be happening, each with a different fix.
The character is not in the encoding at all. The system's character repertoire predates the character. Nothing can be done at the data-entry stage; the software needs updating.
The character is present, but mapped through a private-use area. This is the dangerous one. Encoding standards reserve a block of code points with no fixed meaning, for organisations to assign privately. Two systems can both use that block and assign it differently. Your name goes in, transfers between systems, and arrives as a different character — not as an error, not as a box, but as somebody else's name spelled with your bytes. Nothing is flagged, because from the software's point of view nothing went wrong.
The character is correctly encoded but missing from the font. The underlying data is right, but the display is wrong. This is the failure that produces the empty rectangle — the least harmful of the four, because you can see it.
Everything is correct and the character cannot be typed. No input method on that machine reaches it. The record can hold the name; the clerk cannot enter it.
Only the third of these is a display problem. The first, second and fourth are data problems, and the second one silently corrupts rather than refusing.
Why "just use a different character" is the wrong request
The workaround offered at counters is to substitute a common character that looks or sounds similar. It gets the transaction done and it creates a durable problem: your identity document now says one thing and the institution's record says another, and every future check that compares them will disagree.
The compliant answer is that the system should accept the character, because the standard has required it to since 2023 and required the 2024 additions since October 2025. Insisting on compliance is a slower answer than substitution, but it is the one that does not create a chain of future problems.
Checking which failure you have
You can tell the four cases apart without any technical access.
If the character displays correctly elsewhere on the same screen — in a menu, a heading, another field — but will not save, the font is fine and the problem is the encoding or the field. If it saves and displays as a box, the data may be intact and only the font is missing. If it saves and comes back as a different, legible character — something our China resident ID validator cannot detect either, since it checks arithmetic rather than characters —, that is the private-use case, and it is worth escalating rather than accepting, because it will propagate.
And if the clerk cannot type it in the first place, ask whether the record can be entered from a copy of the ID rather than by keyboard, which is a different route into the same field.
Where this comes from, and what will date
The standard, its compulsory date and the amendment timeline are from the standard's certification body rather than from any vendor selling a solution — a distinction worth making, since one of the amendment's own drafters also sells font products. The character counts moved during drafting, and earlier drafts carried different figures for the police-font subset, so a number found in circulation may be from a superseded draft.
The standard is stable and will not date. What dates is anyone's support for it, which is a moving target and the actual subject of the complaint.
This guide is about the encoding layer. Whether a character displays once it is correctly stored is a font question, and a separate matter with its own causes and fixes. It helps to keep the two separate. A font problem is visible and harmless; an encoding problem can be silent and permanent.
