合同会社小村ソフト
相談する
メニュー

日本語フォントと文字の落とし穴 ── JIS2004・異体字セレクタ・外字を業務アプリでどう扱うか

· 更新日: · · 日本語フォント, JIS2004, 異体字, 外字, 文字コード, Unicode, 業務アプリ, 帳票, Windows

「顧客名簿の『葛』の字が、画面と印刷した帳票で形が違う。データが壊れているのではないかとお客様からクレームになった」──業務システムの保守で、この種の相談は珍しくありません。もう1つよくあるのが「役所に出す書類で氏名の字が出ない。昔のPCでは出ていたのに、入れ替えたら□になった」という相談です。

どちらも現場では「文字化け」と呼ばれがちですが、エンコーディングの不一致で起きる文字化けとは別の問題です。前者はデータが1ビットも変わっていないのに見た目だけが変わっており、後者はそのPCにしか存在しない「外字」が失われています。

この記事の約束はシンプルです。文字コード(データの層)とフォント(見た目の層)を分けて考えれば、日本語の文字トラブルの大半は整理できます。JIS2004の字形変更、異体字セレクタ(IVS)、外字(EUDC)、行政の文字基盤、フォントの選定と埋め込みまで、業務システムの開発者と情シス担当者が判断に使える形でまとめます。

Shift_JISとUTF-8の変換で起きる「化け」そのものは既存記事で扱っているため、本記事は「コードは正しく往復しているのに、見た目や表示可否がずれる」問題に集中します。

1. まず結論

  • 「文字化け」と「字形が違う」は別の問題です。文字化けはバイト列の解釈を誤るデータ層の事故、字形の違いはフォントが持つグリフの差である見た目層の事故で、対処もまったく異なります。
  • Unicodeの符号位置が同じでも、表示される字形はフォント次第です。JIS X 0213:2004で「葛」「辻」「飴」など168字の例示字形が印刷標準字体に改められ、WindowsもVista以降のMSゴシック/MS明朝はJIS2004字形が既定になりました。12
  • 字形をデータとして固定したいときの標準的な手段が異体字セレクタ(IVS)です。基底文字+U+E0100以降のセレクタの並びで字形を指定し、Adobe-Japan1や汎用電子(Hanyo-Denshi)、文字情報基盤(Moji_Joho)などのコレクションがUnicodeのIVDに登録されています。34
  • IVSは非対応環境ではセレクタが無視され、基底文字の既定字形で表示されるのが正しい挙動です。ただし、IVS付きの1文字はUTF-16で最大4コード単位になるため、文字数カウントや切り出しの実装には注意が必要です。5
  • 外字(EUDC)は「そのPCでしか表示できない」宿命を持ちます。私用領域のコードポイントに意味の合意はなく、eudc.tteに登録した字形は他のPC・メール・PDFには付いていきません。67
  • 氏名を扱うシステムは、受け入れる文字集合を決めて明示すべきです。行政側は戸籍統一文字や文字情報基盤を土台に、標準準拠システムで「行政事務標準文字」を使う方向へ動いています。8910
  • 帳票・PDFは「画面とフォントを揃えて、埋め込む」が基本です。埋め込み可否はフォントのライセンス(fsType)で決まり、長期保存用のPDF/Aではフォント埋め込みが必須です。1112
  • 正規化(NFKC)を氏名データに安易にかけてはいけません。全角半角の統合や互換文字の置き換えで、保持すべき区別が失われます。13

一文でまとめるなら、「どのバイト列を保存するか」はデータ設計の問題、「それがどう見えるか」はフォント設計の問題です。この2つを混ぜたまま議論すると、直せる問題も直せなくなります。

2. データと見た目を分けて考える ── 符号位置とグリフ

Unicodeでは、文字は符号位置(コードポイント)という番号で表されます。「葛」はU+845Bであり、この番号はどのPCでも同じです。一方、その番号を画面や紙にどう描くかは、フォントが持つグリフ(字形)が決めます。同じU+845Bでも、フォントAとフォントBで細部の形が違うのは正常な動作です。

この2層を前提にすると、現場の症状は次のように切り分けられます。

層 起きる事故 代表的な症状 主な対処
データ層(文字コード) エンコーディングの解釈ミス、変換での欠落 「縺ｯ」のような化け、?や〓への置換、U+FFFD(�) 変換経路の特定と修正
見た目層(フォント) フォントによる字形差、グリフの欠落 同じデータなのに形が違う、□(トーフ)になる フォントの統一・変更、埋め込み

切り分けの手がかりとして、「�」と「□」の違いを覚えておくと便利です。U+FFFD(REPLACEMENT CHARACTER)の「�」はデータ層で変換に失敗した痕跡で、元の文字はもう失われています。一方「□」は多くの場合、データは残っているのにフォントにグリフがないだけで、フォントを変えれば表示できる可能性があります。

エンコーディングそのものの基礎(CP932とUTF-8、BOM、改行コード)は「Windows文字コード入門 - Linux連携で起きる文字化け」と「Windowsの文字コードと改行コード - 文字化けとCRLF/LFの基本」で扱っています。以降は見た目層と、その境界で起きる問題です。

3. JIS90からJIS2004へ ── 同じコードのまま字形が変わった

冒頭の「画面と帳票で『葛』の形が違う」の正体は、多くの場合ここにあります。

2000年に国語審議会が答申した「表外漢字字体表」を受けて、2004年改正のJIS X 0213:2004(通称JIS2004)では、168字の漢字の例示字形が、いわゆる康熙字典体に近い印刷標準字体に改められました。「葛」「辻」「飴」「芦」「溢」「餅」などが代表例です。1

Windowsはこれに合わせて、Windows Vista以降のMSゴシック/MS明朝(および新設のメイリオ)でJIS2004字形を既定にしました。現在のMSゴシックも既定字形はJIS2004ベースで、OpenTypeのjp90フィーチャ経由でJIS90時代の字形にアクセスできる、という構成です。21

ここで重要なのは、変わったのはフォントだけで、データは何も変わっていないことです。

  • 「葛」の符号位置はXPでもWindows 11でもU+845Bのままです
  • XP(JIS90字形)では勹の中を「ヒ」に簡略化した形、Vista以降(JIS2004字形)では中に「人」まで書く形で表示されます
  • したがって、旧システムで印刷した帳票のスキャン画像と、新PCの画面表示で字の形が食い違います。データ比較では完全に一致します

「辻」のしんにょうの点が1つか2つか、「飴」の食偏の形なども同様です。この歴史を知らないと、「移行でデータが壊れた」という誤った方向に調査が進みがちです。移行前後で文字の見た目が違うと言われたら、まずコードポイントを比較し、一致していればフォントの字形差を疑うのが正しい順序です。

なお、字体そのものが変わったわけではないため、どちらの字形も「同じ文字」です。ただし人名では本人や役所が特定の形にこだわるケースがあり、それを「データとして」区別したい要求に応えるのが次のIVSです。

4. 異体字セレクタ(IVS) ── 字形をデータで指定する

IVS(Ideographic Variation Sequence)は、漢字の直後に「異体字セレクタ」という不可視の符号位置を置いて、字形の変種をデータとして指定する仕組みです。セレクタにはU+E0100〜U+E01EF(VS17〜VS256)が使われます。3

どの「基底文字+セレクタ」の並びがどの字形を指すかは、Unicodeコンソーシアムが管理するIVD(Ideographic Variation Database)という登録簿で決まります。主なコレクションは次のとおりです。4

コレクション 登録 由来・用途
Adobe-Japan1 2007年 Adobeの日本語文字コレクション。商用フォントの異体字切り替えの土台
Hanyo-Denshi(汎用電子) 2010年 汎用電子情報交換環境整備プログラム。戸籍・住基などの行政文字に対応
Moji_Joho 2014年 文字情報基盤(MJ)に対応。IPAmj明朝で利用。2026年8月にも追加登録あり

たとえばMicrosoftのドキュメントは、U+845B単独の「葛」が西葛西駅の表記に、U+845B+U+E0100(VS17)が奈良県葛城市の表記に使われる例を挙げています。同じ「葛」でも、どちらの字形かをデータで区別できるわけです。3

4.1. 対応していない環境での挙動

フォント側は、OpenTypeのcmapテーブル(format 14)でIVSと字形の対応を実装します。5 対応フォント(IPAmj明朝など)と対応アプリが揃えば指定どおりの字形が出ますが、揃わない場合は次のようになります。

  • 仕様上の正しい挙動: セレクタは無視され、基底文字の既定字形で表示される(セレクタ自体は見えない)
  • 古いアプリや一部の描画系: セレクタが独立した未知の文字として扱われ、□が余分に表示される

つまりIVSは「劣化しても基底文字は読める」設計ですが、「指定した字形で必ず表示される」保証は受け手の環境次第です。行政の住民記録・戸籍系では文字情報基盤系フォント+IVSという組み合わせが使われますが、一般の業務システムが安易に受け入れると、表示・印刷・連携先のどこかで字形が落ちます。

4.2. 実装上の注意 ── 「1文字」が最大4コード単位

IVSのセレクタU+E0100以降は追加面の符号位置なので、UTF-16では常にサロゲートペア(2コード単位)です。基底文字が追加面の漢字(たとえばJIS2004で追加された𠮟(U+20B9F))なら基底だけで2コード単位あり、利用者が「1文字」と認識する並びがUTF-16で最大4コード単位、UTF-8で最大8バイトになります。

  • C#の"葛󠄀"(葛+VS17)はstring.Length == 3です。Substringや固定長での切り出しは、基底文字とセレクタを泣き別れにする危険があります
  • 文字数の検証・切り出しは、コード単位ではなく書記素単位(StringInfoなどのAPI)で行います
  • DBのカラム長(SQL Serverのnvarchar(n)はUTF-16コード単位)は、IVSを受け入れるなら見かけの文字数の2〜4倍を見込みます
  • 検索・比較ではセレクタの有無で別の文字列になります。「葛」で検索して「葛+VS17」がヒットするかは、要件として決めて実装する必要があります

5. 外字(EUDC) ── そのPCでしか出ない文字

外字は、Unicodeの私用領域(PUA: U+E000〜U+F8FF等)のコードポイントに、利用者が自分で字形を割り当てる仕組みです。私用領域のコードポイントには全世界共通の意味がなく、同じU+E000でもPCごと・組織ごとに別の字が割り当てられ得ます。6

Windowsでは外字エディタ(eudcedit.exe)で字形を作成し、eudc.tteというフォントファイルに保存されます。このファイルは隠しフォントとしてインストールされ、HKEY_CURRENT_USER\EUDCのレジストリで各フォントに関連付けられます。7 Shift_JIS(CP932)時代は0xF040〜0xF9FCが外字領域で、Unicodeへ変換すると私用領域に対応付けられます。

この仕組みの帰結は明快です。

  • eudc.tteはそのPC(そのユーザー)のものであり、データと一緒に相手へ渡りません
  • メール・PDF・Web・他システムに渡った瞬間、□になるか、相手側の別の外字に見えます
  • OS移行やPC入れ替えでeudc.tteの移設を忘れると、「昔のPCでは出ていた字が出ない」が起きます

冒頭の2つ目の相談の正体はこれです。

5.1. 外字を受け取ってしまったシステムの現実解

問題は、レガシーシステムから引き継いだデータに外字が既に混ざっている場合です。当社が移行案件で推奨している手順は次のとおりです。

  1. 調査: データベース・ファイルを私用領域(U+E000〜U+F8FF)の正規表現でスキャンし、使用中の外字コードと件数を洗い出す。各拠点のPCからeudc.tteを回収して字形を確認する
  2. 同定: 外字1つずつについて「正規のUnicode文字で表せるか」「IVSで表せるか」「文字情報基盤(MJ)に対応する文字があるか」を調べ、代替文字対応表を作る。単に旧字体をJIS外字で作っていただけ、というケースが実際には大半です
  3. 置換: 対応表に基づいてデータを置換する。どうしても対応する文字がない場合のみ、画像として保持するか、当該レコードに注記を持たせる
  4. 遮断: 新システムでは私用領域の入力を検証で弾き、外字を新規に作らない

行政側でも方向性は同じで、自治体が独自に作ってきた外字(全国で約200万文字あるとも言われます)を、後述の行政事務標準文字へ一意に同定して使用をやめる方針が示されています。10 「外字を増やさず、標準化された文字集合へ同定する」は、官民問わず移行の定石になりつつあります。

6. 行政の文字基盤 ── 戸籍統一文字から行政事務標準文字へ

氏名を扱うシステムの設計では、行政側の文字基盤を知っておくと「どこまで受けるか」の判断材料になります。

名称 管理 概要
戸籍統一文字 法務省 戸籍の電子化のために整理された約5万6千字。法務省のサイトで検索できる8
住基ネット統一文字 地方公共団体情報システム機構 住民基本台帳ネットワークで使う約2万1千字
文字情報基盤(MJ) 文字情報技術促進協議会 行政事務で用いる約6万字を整備。MJ文字図形名で管理され、IPAmj明朝フォントとMJ文字情報一覧表が公開されている。IPAの事業として整備され、現在は同協議会へ移管9
行政事務標準文字(MJ+) デジタル庁 文字情報基盤に、MJに同定できない戸籍の文字などを加えて拡張した文字セット。標準準拠システムの氏名等はこの文字セット、文字コードはJIS X 0221:2020を使う10

自治体の基幹業務システム(標準準拠システム)では、氏名等の情報連携に行政事務標準文字を使い、スマートフォンなど統一的な連携規定がない外部システムとはJIS X 0213:2012の範囲で連携するという2段構えが標準仕様になっています。10 「内部では広い文字集合を保持し、外部とは一般的な環境で表示できる範囲でやり取りする」という、この構図自体が民間システムにも参考になります。

一般の業務システムへの実務指針としては、次をおすすめします。

  • 受け入れ文字集合を決めて、仕様書と入力検証の両方で明示する。たとえば「JIS X 0213:2012の範囲」「私用領域と結合文字は不可」「IVSは受けない(または受けるが表示保証はIPAmj明朝環境のみ)」など
  • 無制限に受けない。「Unicodeだから何でも入る」設計は、表示・印刷・連携のどこかで必ず破綻します
  • 範囲外の文字への運用を決めておく。代替表記(新字体・カタカナ)への置き換えルール、本人へ説明する文言までがシステム仕様です
  • 行政・金融など連携先に文字集合の規定がある場合は、それを正として合わせる

7. フォントの選定と埋め込み ── 画面と帳票を揃える

7.1. 定番フォントの性格

フォント 収録 性格と使いどころ
MSゴシック / MS明朝 Windows標準 低解像度画面向けに設計された古参。既定字形はJIS2004ベース2。レガシー帳票との互換性維持で今も現役
メイリオ Vista以降 ClearType前提のモダンな画面向け書体。Vista世代のJIS2004移行と同時に登場1
游ゴシック / 游明朝 Windows 8.1以降 Windows/macOS双方に收録系列があり、資料の見た目を揃えやすい
BIZ UDゴシック / BIZ UD明朝 Windows 10 1809以降 モリサワ製のユニバーサルデザイン書体。帳票・画面の可読性重視の案件で第一候補14
Noto Sans JP 別途導入 オープンソースで提供され、サーバーやLinux環境への同梱・Web配信がしやすい

選定で大事なのは書体の好みよりも、「表示・印刷・PDF生成に関わるすべての環境に、そのフォントが存在するか」です。Windows 10/11の日本語補助フォント(BIZ UD等)は構成によっては入っていないことがあり、サーバーサイドでPDFを生成する構成ではサーバーのフォント有無が直接影響します。

7.2. 帳票設計の基本 ── 揃えて、埋め込む

  • 画面と帳票で同じフォントを指定する。フォントが違えば同じデータでも字形が違って見え、冒頭のクレームになります。「画面はメイリオ、帳票はMS明朝」のような構成は、少なくともJIS2004の168字については字形差がないか確認しておくべきです
  • PDFにはフォントを埋め込む。埋め込まなければ、閲覧側は手元のフォントで代替描画し、字形どころかレイアウトも変わり得ます
  • 埋め込みの可否はライセンスで決まります。OpenTypeフォントはfsTypeフィールドで埋め込み権限(Installable / Restricted / Preview & Print / Editable、サブセット禁止など)を宣言しており、埋め込みが許諾されていないフォントを埋め込んではいけません。11 商用フォントは契約の確認が必須です
  • サブセット埋め込みを基本にする。使用した文字のグリフだけを埋め込めば、日本語フォント全体(数MB〜数十MB)を抱え込まずに済みます
  • 長期保存要件があるならPDF/A。PDF/A(ISO 19005)は表示に必要な資源をファイル内で完結させる規格で、フォント埋め込みが必須です。12 「10年後に開いたら字形が変わっていた」を防ぐ最も確実な方法でもあります

印刷とPDF出力の実装手段の選び方は「Windows業務アプリの印刷とPDF出力」で詳しく扱っています。

8. フォントリンクとフォールバック ── 「違うフォントが混ざる」現象

指定したフォントにグリフがない文字は、何も表示されないのではなく、別のフォントで代替描画されるのが現代の描画系の既定動作です。GDIではレジストリ(FontLink\SystemLink)で定義された「フォントリンク」、DirectWriteやWPF・ブラウザーでは「フォントフォールバック」がこれを担います。15

この仕組みを知っていると、次の「あるある」を説明できます。

  • 英数字と日本語で書体の雰囲気が違う: 欧文フォントを先頭に指定したため、日本語部分だけリンク先・フォールバック先の和文フォントで描かれている
  • 日本語の文中で漢字だけ中国語風の字形になる: フォールバック先が中国語フォントに解決された。言語情報(lang属性やロケール)を正しく渡していないWebやアプリで起きやすい
  • 豆腐(□)が出る: 指定フォントにもフォールバック先にもグリフがない。つまり□はフォールバックの「失敗の跡」であり、データは生きていることが多い

フォールバックは救済装置であって、最初から正しいフォントを選ぶことの代替ではありません。15 業務アプリでは「主要な表示・印刷経路では設計したフォントだけで完結し、フォールバックは想定外文字の保険」と位置付けるのが健全です。多言語UIでのフォント選択の考え方は「WinForms/WPFアプリの多言語化」も参照してください。

9. 業務アプリの実装チェックリスト

最後に、入力から連携までの各層で確認すべきポイントを表にまとめます。

層 典型的な事故 設計・実装の要点
入力 IMEから環境依存文字・IVS付き文字・私用領域の文字が入る 受け入れ文字集合を決めて検証する。範囲外はエラーではなく案内(代替表記の提示)にすると窓口業務が回る
正規化 NFKCで「㈱」→「(株)」、全角半角の統合、①→1など意図しない変換。NFCでもCJK互換漢字(例: U+FA19の「神」)が統合漢字U+795Eに置き換わる 氏名・住所にNFKCをかけない。正規化は用途(検索キー生成など)を限定し、原本は入力どおり保存する13
保存 サロゲートペア・IVSでカラム長不足、コード単位での切り詰め UTF-8/UTF-16で保存し、カラム長はコード単位で余裕を持たせる。切り出しは書記素単位で行う
表示 フォントにグリフがなく□、フォールバックで字形が変わる 対象文字集合を表示できるフォントを明示指定し、対象OSの標準収録状況を確認する
印刷・PDF 画面と帳票の字形差、閲覧側での代替描画 画面と帳票のフォントを揃え、PDFにはライセンスを確認のうえサブセット埋め込みする11
他システム連携 Shift_JIS(CP932)変換でJIS X 0213の追加漢字・IVS・外字が?や〓に化ける 連携仕様で文字コードと文字集合を明示する。CP932連携が残るなら、変換不能文字の検出と代替ルールを実装する

とくに正規化は「良かれと思って」かけた処理が異体字・全角半角の区別を潰す、この記事のテーマそのものの罠です。原本はそのまま、加工はコピーにが原則です。CSV連携の文字コード事故は「CSVは「ただのテキスト」ではない」で詳しく扱っています。

10. まとめ

  • 文字のトラブルは、まず「データ層(文字コード)」と「見た目層(フォント)」に切り分けます。�はデータ層、□は見た目層の事故のサインです。
  • JIS X 0213:2004で168字の例示字形が変わり、WindowsはVista以降JIS2004字形が既定です。「葛」「辻」「飴」の形が環境で違うのは、データ破損ではなくフォントの歴史です。
  • 字形をデータで固定する標準手段はIVSですが、対応フォント・対応アプリが揃わなければ既定字形に落ちます。1文字が最大4 UTF-16コード単位になる実装上の影響も忘れないでください。
  • 外字(EUDC)はそのPC固有の資産で、データと一緒には旅ができません。移行時に洗い出し、正規の文字やIVSへの対応表で置き換え、新規作成はやめるのが現実解です。
  • 氏名を扱うシステムは受け入れ文字集合を決めて明示します。行政は戸籍統一文字・文字情報基盤を土台に行政事務標準文字へ標準化を進めており、連携するシステムはその動向を追う必要があります。
  • 帳票・PDFは「画面とフォントを揃えて、ライセンスを確認して埋め込む」が基本です。長期保存にはPDF/Aを検討してください。
  • NFKC正規化・コード単位の切り出し・CP932変換は、異体字と外字を静かに壊す三大ポイントです。原本保存と書記素単位の処理を原則にしてください。

次に「字が違う」と言われたら、最初にこう問い直してください。コードポイントは同じか、違うのか。同じならフォントの問題、違うならデータの問題です。この一手で、調査の入口を間違えなくなります。

関連記事

関連する相談領域

合同会社小村ソフトでは、業務システムの文字まわりの設計・調査を扱っています。「画面と帳票で字が違う」「移行したら氏名が□になった」といった症状の原因切り分け、レガシーシステムからの移行時の外字調査と代替文字表の作成、氏名を扱うシステムの受け入れ文字集合の設計、帳票・PDFのフォント埋め込み構成のレビューまで、コード層とフォント層の両方から対応します。

参考リンク

  1. 株式会社モリサワ, JIS X 0213:2004（JIS2004）｜フォント用語集. 表外漢字字体表を受けてJIS X 0213:2004で168字の漢字の例示字形が印刷標準字体(いわゆる康熙字典体)に改められたこと、Windows VistaにJIS2004対応フォントが標準搭載されたことについて。 ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, MS Gothic font family. MSゴシックファミリーの既定字形がJIS2004ベースであり、OpenTypeの’jp90’フィーチャ経由でJIS90のレガシー字形にアクセスできることについて。 ↩ ↩2 ↩3

  3. Microsoft Learn, The Unicode standard. バリエーションシーケンスが基底文字+異体字セレクタ(VS1〜VS256、U+FE00〜U+FE0FおよびU+E0100〜U+E01EF)で構成されること、U+845B「葛」とU+845B+U+E0100(VS17)の使い分けの例(西葛西駅と葛城市)、表示には対応フォントが必要なことについて。 ↩ ↩2 ↩3

  4. Unicode Consortium, Ideographic Variation Database. UTS #37に基づくIVSの登録簿。Adobe-Japan1(2007年)、Hanyo-Denshi(2010年)、Moji_Joho(2014年)などのコレクションが登録され、2026年8月版でもMoji_Johoコレクションへの追加登録が行われていることについて。 ↩ ↩2

  5. Microsoft Learn, cmap — Character to Glyph Index Mapping Table (OpenType spec). OpenTypeフォントがcmapサブテーブルformat 14でUnicode Variation Sequenceを実装すること、default/non-default UVSの区別、JIS2004対応フォントでの利用例について。 ↩ ↩2

  6. Microsoft Learn, End-User-Defined and Private Use Area Characters. 外字(EUDC)と私用領域(PUA)文字が利用者や団体ごとに独自に定義され、同じコードポイントでもコンピューターによって割り当てが異なり衝突し得ることについて。 ↩ ↩2

  7. Microsoft Learn, Character Sets and Fonts. UnicodeのEUDC用途にはPUA(U+E000〜U+F8FF等)が使われること、外字エディタでグリフを作成すること、EUDCフォントが.tteファイルとして隠しインストールされ、HKEY_CURRENT_USER\EUDCレジストリでフォントに関連付けられることについて。 ↩ ↩2

  8. 法務省, 戸籍統一文字情報 検索条件入力. 法務省が提供する戸籍統一文字の公式検索サイト。戸籍で用いられる文字の字形・読み・関連情報を検索できることについて。 ↩ ↩2

  9. 一般社団法人文字情報技術促進協議会, 文字情報基盤整備事業. IPAが経済産業省等の支援のもと整備した、行政事務で用いる約6万字の漢字を対象とする文字情報基盤(MJ文字図形、MJ文字情報一覧表、IPAmj明朝フォント)が、現在は同協議会に移管されて公開されていることについて。 ↩ ↩2

  10. デジタル庁, 地方公共団体情報システムにおける文字要件の運用に関する検討会報告書(令和6年7月). 自治体で使用される外字が約200万文字あるとも言われること、文字情報基盤を拡張した「行政事務標準文字」(通称MJ+)を標準準拠システムの氏名等の文字セットとし文字コードはJIS X 0221:2020とすること、氏名等の情報連携には行政事務標準文字を、スマートフォン等との連携にはJIS X 0213:2012を使うこと、従来の外字を行政事務標準文字へ一意に同定して使用しない方針について。 ↩ ↩2 ↩3 ↩4

  11. Microsoft Learn, OS/2 — OS/2 and Windows Metrics (OpenType spec). フォントのfsTypeフィールドが埋め込みライセンス(Installable / Restricted License / Preview & Print / Editable、サブセット禁止ビット等)を定義し、埋め込みが許諾されていないフォントをアプリケーションが埋め込んではならないことについて。 ↩ ↩2 ↩3

  12. PDF Association, PDF/A Basics. 長期保存用のPDF/A(ISO 19005)では文書の表示に必要な要素をファイル内に含める必要があり、その代表例としてフォントの埋め込みが必須であることについて。 ↩ ↩2

  13. Microsoft Learn, Using Unicode Normalization to Represent Strings. Unicode正規化のNFC/NFD/NFKC/NFKDの4形式、KC/KD形式が全角半角文字などの互換文字を統合して情報が失われるため文字列の正規保存形式として一般に適さないことについて。 ↩ ↩2

  14. Microsoft Learn, BIZ UDGothic font family. モリサワ製のユニバーサルデザイン書体BIZ UDゴシックがWindows 10 バージョン1809以降の日本語補助フォントとして収録されていることについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

同じ「葛」の字なのに、PCや帳票によって形が違って見えるのはなぜですか？
文字化けではなく、フォントの字形の違いである可能性が高いです。JIS X 0213:2004(JIS2004)で168字の漢字の例示字形が印刷標準字体に改められ、WindowsもVista以降のMSゴシック/MS明朝などがJIS2004字形を既定にしました。「葛」「辻」「飴」などはこの代表例で、Unicodeの符号位置(データ)は同じまま、フォントが持つグリフ(見た目)だけが変わっています。したがってデータを比較すれば一致しており、XP時代の帳票イメージと新しいPCの画面で形が食い違うのは仕様どおりの動作です。字形まで揃えたい場合は、画面と帳票で同じフォントを使うか、異体字セレクタで字形を指定します。
異体字セレクタ(IVS)を使えば、人名の字形の問題はすべて解決しますか？
解決しません。IVSは基底文字の直後にU+E0100以降のセレクタを付けて字形をデータとして指定する仕組みで、IPAmj明朝などの対応フォントと対応アプリが揃って初めて指定どおりに表示されます。非対応の環境ではセレクタが無視されて基底文字の既定字形で表示されるのが正しい挙動で、環境によってはセレクタが□に見えることもあります。さらに、IVS付きの1文字はUTF-16で最大4コード単位になるため、文字数カウント・切り出し・DBのカラム長の設計にも影響します。導入する場合は、表示・印刷・連携先まで含めて対応範囲を確認したうえで使ってください。
外字(EUDC)で登録した文字は、他のPCやPDFでも表示できますか？
原則として表示できません。外字はUnicodeの私用領域(U+E000〜)に、そのPCのeudc.tteファイルへ利用者が字形を登録する仕組みで、同じコードポイントでも別のPCでは未定義か別の字形になります。そのため、メール・PDF・他システムへ渡ると□になったり違う字に見えたりするのが宿命です。既に外字を含むデータを預かっている場合は、移行時に私用領域の使用箇所を洗い出し、正規のUnicode文字や異体字セレクタへの対応表を作って置き換えるのが現実的です。新規システムで外字を新しく作ることは避けるべきです。
業務システムで氏名の文字はどこまで受け入れるべきですか？
「受け入れる文字集合を決めて、仕様として明示する」ことが第一です。戸籍には約5万6千字の戸籍統一文字があり、行政の標準準拠システムは文字情報基盤を拡張した行政事務標準文字を使う方針ですが、一般の業務システムが同じ水準を無制限に受け入れる義務はありません。たとえば「JIS X 0213の範囲まで」「異体字セレクタと私用領域は受け付けない」のように範囲を決め、入力時に検証して範囲外はアラートや代替表記で運用する設計が現実的です。行政システムや自治体と連携するシステムだけは、行政事務標準文字とJIS X 0221ベースの連携要件の動向を追う必要があります。
帳票やPDFで画面と同じ字が出るようにするにはどうすればよいですか？
まず画面と帳票で同じフォントを指定し、PDFにはフォントを埋め込むのが基本です。フォントが違えば同じデータでも字形が変わり得ますし、閲覧側のPCにフォントがなければ代替フォントで描画されて見た目が崩れます。埋め込みの可否はフォントのライセンス(OpenTypeのfsType)で決まっているため、帳票ライブラリ任せにせず確認してください。使用した文字だけを埋め込むサブセット埋め込みならファイルサイズも抑えられます。長期保存が要件ならフォント埋め込みが必須のPDF/Aを検討します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る