欠落グリフチェッカー · ローカライズテキストとビットマップフォント
韓国語・日本語のビルドで文字の代わりに四角が出る前に、ローカライズファイルのテキストとBMFontに実際にあるグリフを比べます。
韓国語・日本語の文字があるはずの場所に四角（□）や空白が出るのは、フォントにそのコードポイントのグリフがないからです。ビットマップフォントには焼き込んだ文字しかなく、.fntにはグリフごとにchar id=の行が1つあります。チェッカーは.po（msgstrの値）、.json、.csv・.tsv、.txtから訳文を取り出し、異なる文字を1つずつ.fnt（またはUIラボのフォントステージで作ったフォント）と比べ、欠けた文字ごとにUnicodeのコードポイント・使用回数・最初に出る行を示します。TTFの文字マップはまだ読めません。
- Nine-slice測定確認· Pillow
- Bitmap font測定確認· independent .fnt parser
- Button states測定確認· Pillow
- Engine import未検証
文字が四角になる理由
すべての文字はUnicodeのコードポイントで、BMFontはそれを10進数で保存します。韓国語の시はU+C2DCで、.fntにはchar id=49884と書かれます。チェックは単純な集合の比較で、テキストに出てくる異なる文字からフォントのchar idを引くだけです。文字体系が大きいため、韓国語・日本語のゲーム用フォントは実際に使う文字列から作ります。ハングルの完成形音節U+AC00〜U+D7A3は11,172コードポイント、CJK統合漢字のブロックU+4E00〜U+9FFFは20,992コードポイントあります。
よくある原因は、フォントを焼いた後に更新された翻訳、原文の言語で作ったフォント、見た目が同じでコードポイントが違う文字（全角の！ U+FF01と! U+0021）、そして分解されたハングルです。分解形では가が1つの音節（U+AC00）ではなく字母U+1100 U+1161として届きます。チェッカーはコードポイントを厳密に比べるので、これらをすべて報告します。
ファイルごとに何を読むかが重要です。.poからはmsgstr（とmsgstr[n]）の値だけを読み、原文のキーmsgidは読みませんが、ヘッダー項目のmsgstr（Language:、Content-Type:）もテキストとして数えます。JSONはすべての文字列値、CSV・TSVはキーや原文の列を含むすべてのセルを読みます。ノーブレークスペースU+00A0や全角スペースU+3000を含む空白文字は、グリフとして描かないので飛ばします。
例：韓国語の.poと4グリフの.fnt
フォントは시・작・끝・내から焼いたものです。このファイルに対してチェッカーが返す結果です。
ko.po (9行) font.fnt (グリフ4つ)
msgid "" char id=49884 시 U+C2DC
msgstr "" char id=51089 작 U+C791
"Language: ko\n" char id=45149 끝 U+B05D
msgid "Start" → msgstr "시작" char id=45236 내 U+B0B4
msgid "Quit" → msgstr "끝내기"
チェックした文 "Language: ko" / "시작" / "끝내기" （msgidの値は読まない）
欠けている文字 기 U+AE30 ×1 （テキスト5行目）
a ×2, g ×2, :, L, e, k, n, o, u （ヘッダー項目、テキスト2行目）
追加するもの 기 = 0xAE30 = 44592 → 作り直したフォントに "char id=44592" が必要ラテン文字は翻訳ではなくヘッダー項目から来ています。フォントにASCIIを入れる（多くのゲームはどのみち数字とラテン文字が必要です）か、それらの行を無視してください。ここで本当に欠けているのは기です。
チェックするテキストの出どころ
| ファイル | 読むもの | 無視するもの |
|---|---|---|
.po | msgstrとmsgstr[n]の値と続きの行（ヘッダー項目も含む） | msgid、msgctxt、コメント |
.json | 深さに関係なくすべての文字列値 | オブジェクトのキー、数値、真偽値 |
.csv / .tsv | すべての行のすべてのセル（見出し行とキー列を含む） | 区切り文字と引用符 |
.txtまたは貼り付けたテキスト | すべて | 改行とその他の空白 |
.fnt（グリフの出どころ） | すべてのchar行のid | カーニング、ページ、メトリクス |
できること
- .po（msgstrの値）、JSON（すべての文字列値）、CSV・TSV（すべてのセル）、プレーンテキストを読み込み。
- .fntのグリフ一覧か、ラボのフォントステージで作ったフォントと比較。
- 欠けた文字ごとに件数と最初に出る行番号。
- missing-glyphs.jsonとフォントツールに貼れる一覧をダウンロード。
使い方
- グリフの出どころ（.fntかラボのフォント）を選ぶ。
- ローカライズファイルを入れるかテキストを貼る。
- 欠落一覧を読む。
- レポートを書き出し。
結果の確認
- 文字を追加してフォントを作り直したら、もう一度チェックします。欠落なしと表示され、チェックした異なる文字の数が出るはずです。
missing-glyphs.jsonを開きます。各項目にchar、U+XXXX形式のcodepoint、count、linesがあり、missing-glyphs.txtは同じ文字を1行にまとめたもので、フォントツールの文字欄にそのまま貼れます。- ゲーム内で、言語ファイルのすべての文字を含むテスト用の文字列を1つ表示します。四角や空白が1つも残らないはずです。
トラブルシューティング
| 症状 | 考えられる原因 | 確認方法 | 対処 |
|---|---|---|---|
| 韓国語・日本語の.poなのにラテン文字（L、a、n、g…）が欠落と出る | ヘッダー項目のmsgstr（Language:、Content-Type:）をテキストとして読んでいる | 行番号が取り出したテキストの最初の行を指している | フォントにASCIIを入れるか、それらの行を無視する |
| CSVの英語の原文列が報告される | キー列・原文列を含め、CSV・TSVのすべてのセルを読んでいる | 欠けた文字の大半がラテン文字で、すべての行に出てくる | 対象言語の列だけを書き出すか、そのテキストを貼り付ける |
| あるように見える文字が欠落と出る | コードポイントが違うそっくりな文字（全角の！、～、別のダッシュ） | レポートのU+コードと.fntのidを比べる | そのコードポイントをフォントに追加するか、書き出す前にテキストを正規化する |
| フォントにあるハングル音節が欠落と出る | テキストが分解形で、音節ではなく字母U+1100〜U+11FFになっている | レポートにU+11xxのコードが並ぶ | ローカライズの工程で文字列をNFCに正規化する |
| 欠落はないのにゲームでは四角が出る | ゲームがチェックした.fntとは別のフォント・太さで描いている、またはUIラボのフォントをフォントファイルモードで作り、TTFにない文字をブラウザーの代替フォントで描いたまま焼き込んだ | ビルドに実際に入る.fntを確認し、グリフシートで形の違う文字を探す | 実際に配布する.fntでチェックする。GodotではBMFontのインポート設定に代替フォントを指定できる |
| 行番号がファイルと合わない | 元のファイルではなく、取り出したテキストの行を数えている | .poのレポートの2行目はヘッダーのテキスト | ファイル内でその文字自体を検索する |
| TTF・OTFをグリフの出どころに選べない | このリリースはフォントのcmap表を解析しない | — | 先にフォントから.fntを作り、それと比べる |
出力ファイルと検証方法
「測定確認」は、ダウンロードしたファイルをページ外（Pillow・numpy・独立したパーサー）で開き直して性質を測ったという意味です。ゲームエンジンでの読み込みは試していません。
| 書き出し先 | ファイル | 検証 |
|---|---|---|
| Nine-slice | nine-slice.json · previews · SETUP.md | 測定確認 Pillowリサイズした全プレビューで四隅のブロックは拡大されません。Chromiumではバイト一致、Firefoxでは半透明ピクセルがアルファの丸め1段階ぶん変わることがあります。すき間・重なり0。 |
| Bitmap font | font.png · font.fnt (BMFont text) · font.json | 測定確認 independent .fnt parserテスト内で別に書いたパーサーで.fntを読み戻し、ヘッダーと全グリフ範囲が一致。 |
| Button states | states/*.png · strip · states.json | 測定確認 Pillownormalは元と一致（Chromiumではバイト一致、Firefoxでは半透明ピクセルの色がアルファの丸め1段階以内）。states.jsonの各範囲がストリップから該当状態を正確に切り出します。 |
| Engine import | Godot NinePatchRect · Unity Sprite border · BMFont import | 未検証Godot・Unityでは実行していません。 |
検証の根拠
ナインスライスの四隅が100×40・300×80・800×200・420×120で拡大されず、同一列12本から境界6·6·6·6を提案。ボタン状態：normalは元と一致、disabledはアルファ128のグレー、focusリングも正確。.fntのグリフ記録がJSONと一致。.poの欠落グリフを正確に列挙。白地に黒文字で21:1を測定。画像はブラウザのCanvasを通ります。Chromiumはバイトがそのまま、Firefoxは半透明ピクセルの色を乗算済みの値で1段階に丸めます（Kenneyのボタンで測定：アルファ63で最大4段階）。アルファと不透明ピクセルはそのままです。
制限
- カーニングペアなし、フォントは1ページ、MSDFなし。SDF出力はベータです。
- TTFのcmapを解析しないため、欠落グリフのチェックには.fntかラボのフォントが必要です。
- アトラスは1ページで、接している要素は1つとして扱います。
- Godot・Unityでの描画は行っていません。エンジン用の値（patch margin、L・B・R・Tの境界）はドキュメント基準で、エンジンでは未検証です。
バージョンと出典
docs/UI-LAB.mdのためにChromiumで測定しました。4グリフの.fntで.poをチェックするとa 시 작 끝 내 기を正しい件数と行番号で報告し、フォントにある가は報告しませんでした。上の例は同じ関数で計算し直したもので、ヘッダー項目の行は現在のパーサーの動作どおりです。.fntのフィールドの意味はAngelCode BMFontのドキュメント、.poの構造はGNU gettextのマニュアルに基づきます。
参照した公式ドキュメント
よくある質問
TTFフォントと比較できますか？
まだできません。このバージョンはTTFのcmap表を解析しないので、.fntかラボのフォントを使ってください。
実際のファイルで確認しましたか？
4グリフの.fntと.poファイルを比べ、欠けた6文字を件数と行番号まで正確に報告しました。
無料ですか？アカウントは必要ですか？
このページの機能はすべて無料で、アカウントなしで使えます。透かしや制限された書き出しはありません。
スプライトはアップロードされますか？
いいえ。Studioはこのブラウザのタブ内でデコード・パック・書き出しを行います。プロジェクトはブラウザ（IndexedDB）に自動保存され、.nerulioファイルとして保存できます。
Asepriteやエンジンのプラグインは必要ですか？
いいえ。.asepriteファイルはブラウザで読み書きします。エンジン別のバンドルには必要なものが入っています（Godotはインポート設定とシーン、UnityとGodotのタイルセットは小さなエディタースクリプト）。