JP-Verify — old and variant kanji (旧字体・異体字): the table jp-verify-kanji-v1 (release 1.6.2)

Every register figure on this page carries the date and the population it was measured on.

The table is served as two tab-separated UTF-8 files: /kanji-variants/TABLE.tsv (the pairs) and /kanji-variants/HELD.tsv (characters kept apart, with the reason for each). The response fields named below are described in the OpenAPI document, /openapi.json.

The register names, rows and counts on this page are processed from the NTA's two registers (the 法人番号 register and the invoice register; each figure names its register and date):

出典：国税庁法人番号公表サイト（国税庁）（https://www.houjin-bangou.nta.go.jp/）を加工して作成

出典：国税庁適格請求書発行事業者公表サイト（国税庁）（https://www.invoice-kohyo.nta.go.jp/）を加工して作成

1. What it does

A Japanese company name can be registered with an old or variant form of a kanji — 栁 for 柳, 﨑 for 崎, 澤 for 沢, 會 for 会 — and typed by a caller in the other form, or the other way round. JP-Verify folds a copy of the query and a copy of the registered name through one fixed table, jp-verify-kanji-v1, after Unicode NFKC, and compares the folded copies. The same table is used on both sides.

• /v1/resolve compares a name typed in either form with the names registered in either form. A candidate reached only through the fold — at any tier: the registered name, an official English name or a reading — carries match.route: "kanji-variant" and lists the mapped characters in match.kanji_folds ([{"from": "栁", "to": "柳", "side": "registered"}]). Within one tier and key form it ranks after the candidates found as typed ("direct"); among the kanji-variant candidates of one tier and key form, a registered name that differs from the query in fewer table characters comes first. Where many registered names share the folded form, a company reached this way can rank below the limit a caller asks for (§10). Every 200 answer carries matched (true / false) and miss_reason (null when matched, else no_key_match — no key of the query matched — or no_active_match — keys matched, but every company they matched is closed, search-excluded or no longer present in JP-Verify's current copy of the register; open-ended), and query_kanji_folds lists the table characters of the query itself.
• The JP-Verify Invoice Facts name_match rates two names that are equal once both are folded at the existing variant level and flags the comparison with kanji_variant: true. A variant match the two names make only through a reading or another legal form carries kanji_variant: false. No new level is added.
• Generated English names and addresses read an unreadable variant through the table — 株式会社一栁商事 → Ichiyanagi Shouji Co., Ltd. (release 1.6.1: Ichi Koto Co., Ltd.), 山﨑タイル工業株式会社 → Yamazaki Tairu Kougyou Co., Ltd. (1.6.1: Yama Yama Tairu Kougyou Co., Ltd.). A generated English rendering is returned only when every character was romanised; otherwise name_en (or address_en) is null and name_en_unrendered (or address_en_unrendered) lists the characters (信鑫株式会社 → ["鑫"]). Lossless does not mean correct: readings remain best-effort, and name_ja / address_ja are the authoritative fields.

The registered name is never rewritten. name_ja and furigana stay exactly as the NTA published them; the fold is applied only to the copies used for matching and reading. Individuals (個人事業者) are never compared or rendered — the 法人番号 register holds no individual proprietors, and JP-Verify withholds an individual's name in the invoice register (name_match reads not_compared, reason individual_issuer).

2. What the registers already do

The NTA's own 法人番号公表サイト folds part of this already. Its name search degrades a typed kanji outside JIS levels 1–2 to levels 1–2 and searches a name field degraded the same way, so that 喜 and a level-3 variant of it find the same companies (国税庁 法人番号公表サイト「利用方法」, https://www.houjin-bangou.nta.go.jp/website/riyo-hoho/index.html, read 2026-10-09). Its Web-API, for the name search target 1 (used when target is not given), searches a name field degraded to JIS levels 1–2 in the same way (「Web-API のリクエストの設定方法及び提供データの内容について（概要編）」1.2版 令和3年10月, §4.6.2 and the target parameter, https://www.houjin-bangou.nta.go.jp/pc/webapi/images/k-web-api-kinou-gaiyo.pdf, read 2026-10-09). The NTA publishes the correspondence between the level-3/4 characters in its published names and their level-1/2 forms — the JIS縮退マップ Ver.1.0.0 — and, in that degradation, writes 「＿」 where a character has no level-1/2 form (download page, https://www.houjin-bangou.nta.go.jp/download/index.html, read 2026-10-09).

JP-Verify uses that NTA map as one of its sources (layer B, §3) and adds four things: the old/new pairs whose two forms are both JIS level-1/2 characters, which a level-3/4 → level-1/2 degradation leaves as written (澤/沢, 國/国, 廣/広, 會/会, 齋/斎, 邊/辺, 龍/竜 …); a label on every /v1/resolve candidate (match.route, and match.kanji_folds with the characters and the side) and a flag on every Invoice Facts comparison (kanji_variant, a boolean — the characters are not echoed); the lossless-or-null rule for generated English names and addresses (§1); and the same fold in the Invoice Facts name check.

3. The table

Rules the build enforces:

• one code point maps to one other ideograph; no representative is itself a source (chain-free), so folding twice equals folding once; the fold never changes a name's length;
• every pair has at least one basis — joyo (常用漢字表), jinmei (別表第三), nta-jis-1.0.0 (the NTA row), unihan (a Unihan 18.0.0 variant field or definition statement), dictionary (a cited statement);
• a Chinese simplification relation (Unihan kSimplifiedVariant / kTraditionalVariant) is never a basis on its own. Two Unihan rules carry a fold only together with identical Japanese readings: the same legacy code (kEACC / kCCCII) with a shared Japanese reading (靑 淸 姬 顏 廏), and a simplification link with identical Japanese readings where the form is not itself a PRC simplified form (內 產 彥 剎 閱 駡);
• a Unihan spoofing variant (kSpoofingVariant, visual confusability) is not a basis — HELD.tsv keeps 28 characters apart for it — with one exception the release design made: 𠮷 → 吉, so that a name typed with 𠮷 can reach a name the registers write with 吉 — neither register holds 𠮷 in a name (0 of the 5,828,219 rows of the 法人番号 register of 2026-08-31 and 0 current corporate rows of the invoice register, measured 2026-10-13);
• 斎 and 斉 are never merged: 齋 folds to 斎 and 齊 to 斉, and the two stay apart;
• the placeholder characters ○ 〓 ＿ _ ？ ? □ U+FFFD are never in the table (§6);
• the module refuses to import when its pairs do not hash to the published sha256, and the /v1/resolve index records the sha256 it was built with (§8).

To check a downloaded copy of TABLE.tsv against the published sha256 (run in the folder that holds it):

import hashlib
rows = []
for line in open("TABLE.tsv", encoding="utf-8"):
    if line.startswith("#") or line.startswith("source\t"):
        continue
    cols = line.rstrip("\n").split("\t")
    rows.append((int(cols[1][2:], 16), f"{cols[1]}\t{cols[3]}\n"))
print(hashlib.sha256("".join(r for _, r in sorted(rows)).encode("ascii")).hexdigest())
# 5f85c892446cc846d2c26e88cc8d3707939aa6bae307612c535d4b0988dec753 (2,330 rows)

4. Characters decided one by one

The design of this release first held back, for a later table, ten characters found in company names that neither official list names. Before release each was decided on its own evidence:

The dictionary statements behind the dictionary rows are recorded, with URL, access date and page sha256, in JP-Verify's review record (not published); this page and the two files state each fact in JP-Verify's words.

5. Characters kept apart (HELD.tsv)

A related character is not always the same character, and a relation is not always a basis. HELD.tsv lists 748 characters the table never folds together with the character(s) named next to them, each with its reason:

• 斎 / 斉 — both read サイ; a name written 斉藤 stays apart from 斎藤 / 齋藤 as glyphs (齋 folds to 斎, 齊 to 斉). The reading can still relate them: the Invoice Facts check rates 斉藤商事 / 齋藤商事 variant with kanji_variant: false, because the match comes from the reading, not from the table.
• 61 rows of the NTA map whose target is a different character in use — 份 → 斌 (份 'portion, share', as in 股份), 沪 → 瀘, 橅 → 模, 你 → 尓 and 57 more; the reason for each is in HELD.tsv.
• 686 other characters that Unihan or another source relates to a table character, held for one of these reasons: a different character — numerals and their 大字 (佰 仟 捌 肆), characters the official lists keep separate (蹟 / 跡), different characters in Japanese use (鯰 / 鮎, 籐 / 藤, 吊 / 弔, 吃 / 喫), miswritings (祗 for 祇); two identities (絋: 纊 and, in names, 紘; 鈩: 鑪 and, in the register, 鑢); a relation no allowed basis supports — a simplification only (毁, 业), a spoofing variant only, or a definition that names other characters; a radical or component form (亻 氵 刂 灬 爫 犭 礻 衤 飠 牜, and 坰); or a Unicode 17.0 character (U+2CEA5, U+2CEA6) that the service's runtime character database does not know.

A held character is compared only as written.

6. Placeholders are compared literally

In its Shift-JIS files (JIS levels 1–2) the NTA replaces a level-3/4 character that has no level-1/2 form with ＿ (§2); the Unicode file JP-Verify mirrors prints level-3/4 characters as registered (栁, 﨑, 鑫 …) and still holds ＿ in some names. Other systems write 〓, ○, ？ or □ for a character they could not display. None of these characters is ever a wildcard:

• ＿ and ○, which registered names hold, are compared literally in a Japanese-script name and never dropped: 有限会社＿北 and 有限会社北 are different names to /v1/resolve and to the Invoice Facts check. A name the register prints with ＿ cannot be matched to the character the ＿ stands for. On the 法人番号 register of 2026-08-31 (全件 + the 2026-09-01 diff), 1,214 active names fall under this rule — 1,203 of them hold the NTA's ＿ (measured 2026-10-09).
• ? ？ □ 〓 and U+FFFD, which no registered name holds (0 of the 5,828,219 names of that register, measured 2026-10-13), are compared literally and are also read as separators, as before release 1.6.2 — in a /v1/resolve query, and at the normalized and variant levels in an Invoice Facts document name — so a stray ? does not turn a match into a miss.
• A query that holds a placeholder lists it in query_placeholders. A name with nothing searchable once normalised (only punctuation, symbols, invisible characters or placeholders) is refused with a free 400.
• In a Latin name (LINDEN_JILL INC.) an underscore keeps its earlier reading as a separator.

7. A fold is not identity — glyph twins

Two active companies can differ in that one character only:

(法人番号 register, 2026-08-31 全件 + the 2026-09-01 diff; both active.) A /v1/resolve query for 株式会社一柳工業 returns 4021001060597 first (native / full / direct) and then 1021001062398 (native / full / kanji-variant, kanji_folds: [{"from": "栁", "to": "柳", "side": "registered"}]); the query 株式会社一栁工業 returns the two the other way round, the fold then on the query side. Before treating a candidate as the company you mean, confirm the prefecture, the city and the 法人番号 — and read match.route: a kanji-variant candidate can be a different company.

On the same register, 116,598 active corporations share their folded name with at least one active corporation whose name is written in another glyph form (14,502 such groups), and 33,830 of the 104,451 active names that hold a table character have an active namesake written exactly in the folded form (measured 2026-10-13 with this table).

出典：国税庁法人番号公表サイト（国税庁）（https://www.houjin-bangou.nta.go.jp/）を加工して作成

8. Where the fold applies, and versioning

Not folded in this release: /v1/screen (it keeps its keys), the shareholder name resolution of /v1/shareholders, individuals (never compared or rendered), and the document route of the Invoice Facts, which reads no seller name.

The two sides cannot drift apart unnoticed. Any change to a pair changes the table's sha256. The /v1/resolve index records the table's id and sha256 when it is built, and the service refuses an index built with another table or another keyset — a free 503 on /v1/resolve, and /health.resolve.compatible: false — until the index is rebuilt. A published table that changes gets a new id. The inputs are pinned by sha256 (§9); two of them can still move upstream: Unihan's Japanese variant fields are marked Provisional in Unicode 18.0, and the 人名用漢字 list was amended in 2026-06 (勒).

9. Sources and licences

Layer B of the table is processed from the NTA's map:

出典：国税庁法人番号公表サイト（国税庁）（https://www.houjin-bangou.nta.go.jp/download/）のJIS縮退マップ（Ver.1.0.0・国税庁の著作物）を加工して作成

This line is carried here and in the header of TABLE.tsv and HELD.tsv. Responses do not carry the map: a /v1/resolve candidate lists the single characters folded to reach it (match.kanji_folds) and an Invoice Facts comparison carries a flag (kanji_variant); the /v1/resolve disclaimer and the Invoice Facts name_match method text name this page.

The dictionary statements behind layer D (Wiktionary, whose text is CC BY-SA; 漢字ペディア, © 公益財団法人 日本漢字能力検定協会) are recorded as evidence for one fact each in JP-Verify's review record, which is not published; neither dictionary is an input of the table. Not used: the MJ縮退マップ / 登記統一文字縮退マップ (CC BY-SA 2.1 JP), the 法務省 戸籍統一文字 database, and pykakasi's own variant table.

10. What is measured, and what is not promised

Measured (法人番号 register 2026-08-31 全件 + the 2026-09-01 diff, active population = no close date and not search-excluded; invoice register 2026-08-31 全件 + the 2026-09-01 diff, current corporate rows; this table):

• 104,451 of the 5,009,012 active corporations' names (2.09 %) hold at least one source character of the table; 43,254 of the invoice register's 2,585,151 corporate names (1.67 %) do (measured 2026-10-13).
• /v1/resolve returns at most limit candidates — 10 unless the caller asks for more, at most 25 on Sandbox and Starter and 100 on Growth and Reseller. On a keyset-4 index of that register, with synthetic queries built from registered names (measured 2026-10-13), a variant-registered company typed in the standard form (104,451 queries) was the first candidate in 62.75 % of the queries and among the first 10 / 25 / 100 candidates in 85.68 % / 91.84 % / 97.39 %; in 2.61 % it ranked below 100, beyond any limit.
• A standard-registered company typed with one variant glyph (the same index, 34,502 queries, up to 20 names for each table character that registered names hold) was the first candidate in 97.49 % and among the first 10 / 25 / 100 in 99.69 % / 99.88 % / 99.98 %. A company ranks low where many registered names share its folded form; the candidates around it can include a different company (§7).
• Invoice Facts, the 43,254 names typed in their folded form against their own register row: 5,897 comparisons that release 1.6.1 rated none are now variant, and the other 37,357 were variant in 1.6.1 already; they now carry kanji_variant: true. Typed as JP-Verify's own English rendering of the name, 4,772 comparisons move from none to variant; with the other legal form (株式会社 / 有限会社), 5,456 do — both with kanji_variant: false. No comparison that release 1.6.1 rated positive becomes none (measured 2026-10-13).
• English renderings by the romaniser (without the 法人番号 register's official English names), against release 1.6.1: of the 5,009,012 active 法人番号 names, 4,995,073 render byte-identically, 10,188 are repaired (1.6.1 served a partial or bracketed reading), 457 old-form legal forms such as 株式會社 are now glossed and 3,294 are null with the characters listed; of the invoice register's 2,585,151 corporate names, 2,578,932 / 5,291 / 71 / 857 likewise; of its 2,577,789 addresses, 2,575,472 render byte-identically, 1,485 are repaired and 832 are null with the characters listed (measured 2026-10-13 on the release code).

Not promised:

• A fold is not identity (§7). A kanji-variant candidate, or a variant name match with kanji_variant: true, can be a different company.
• A /v1/resolve answer holds at most limit candidates; a company reached through the fold can rank below it.
• A character outside the table or kept apart (§5) — including characters with no standard counterpart, such as 鑫 — matches only as written; a character the register itself prints as ＿ cannot be matched to the character it replaced.
• Matching is a fixed table plus rule-enumerable keys — not fuzzy, not similarity search. matched: false does not mean the company does not exist.
• A generated English name or address is lossless, not necessarily correct (株式会社明德 → Akinori Co., Ltd.); name_ja / address_ja are the authoritative fields.

Register figures in this section:

出典：国税庁法人番号公表サイト（国税庁）（https://www.houjin-bangou.nta.go.jp/）を加工して作成

出典：国税庁適格請求書発行事業者公表サイト（国税庁）（https://www.invoice-kohyo.nta.go.jp/）を加工して作成

Appendix — the Unicode License V3 notice

The Unihan relations compiled into the table and the Unihan fields and definitions quoted in TABLE.tsv and HELD.tsv are used under the Unicode License V3; its copyright and permission notice, copied verbatim from https://www.unicode.org/license.txt (fetched 2026-10-09):

UNICODE LICENSE V3

COPYRIGHT AND PERMISSION NOTICE

Copyright © 1991-2026 Unicode, Inc.

NOTICE TO USER: Carefully read the following legal agreement. BY
DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING DATA FILES, AND/OR
SOFTWARE, YOU UNEQUIVOCALLY ACCEPT, AND AGREE TO BE BOUND BY, ALL OF THE
TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE, DO NOT
DOWNLOAD, INSTALL, COPY, DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE.

Permission is hereby granted, free of charge, to any person obtaining a
copy of data files and any associated documentation (the "Data Files") or
software and any associated documentation (the "Software") to deal in the
Data Files or Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, and/or sell
copies of the Data Files or Software, and to permit persons to whom the
Data Files or Software are furnished to do so, provided that either (a)
this copyright and permission notice appear with all copies of the Data
Files or Software, or (b) this copyright and permission notice appear in
associated Documentation.

THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF
THIRD PARTY RIGHTS.

IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE
BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES,
OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA
FILES OR SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall
not be used in advertising or otherwise to promote the sale, use or other
dealings in these Data Files or Software without prior written
authorization of the copyright holder.