빠진 글자 검사

번역 텍스트나 .txt·.json·.csv·.po를 폰트의 글자 목록과 비교해 빠진 글자와 사용 위치를 찾으세요.

한국어·일본어 글자가 있어야 할 자리에 네모(□)나 빈칸이 보이면 폰트에 그 코드 포인트의 글리프가 없다는 뜻입니다. 비트맵 폰트에는 구울 때 넣은 글자만 있고, .fnt에 글리프마다 char id= 줄이 하나씩 있습니다. 검사기는 .po(msgstr 값), .json, .csv·.tsv, .txt에서 번역문을 꺼내 서로 다른 글자 하나하나를 .fnt(또는 UI 랩 폰트 단계에서 만든 폰트)와 비교하고, 빠진 글자마다 유니코드 코드 포인트·사용 횟수·처음 나오는 줄을 보여 줍니다. TTF의 문자 표는 아직 읽지 못합니다.

이미지을(를) 여기에 놓으세요여러 개를 한 번에 처리할 수 있습니다

업로드 없음 · 이 기기에서 처리

글자가 네모로 바뀌는 이유

모든 글자는 유니코드 코드 포인트이고 BMFont는 이를 10진수로 저장합니다. 시는 U+C2DC이며 .fnt에는 char id=49884로 적힙니다. 검사는 단순한 집합 비교입니다. 텍스트에 쓰인 서로 다른 글자에서 폰트의 char id 값을 빼면 됩니다. 문자 체계가 크기 때문에 한국어·일본어 게임 폰트는 실제로 쓰는 문자열로 만듭니다. 완성형 한글 음절 U+AC00~U+D7A3은 11,172개 코드 포인트이고, 한중일 통합 한자 블록 U+4E00~U+9FFF는 20,992개에 이릅니다.

흔한 원인은 폰트를 구운 뒤 갱신된 번역, 원문 언어로 만든 폰트, 모양은 같지만 코드 포인트가 다른 글자(전각 ！ U+FF01과 ! U+0021), 그리고 분해된 한글입니다. 분해형에서는 가가 음절 하나(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`	커닝, 페이지, 수치

결과 확인

글자를 추가하고 폰트를 다시 만든 뒤 검사를 다시 돌립니다. 빠진 것이 없다고 나오고, 검사한 서로 다른 글자 수가 표시돼야 합니다.
missing-glyphs.json을 엽니다. 항목마다 char, U+XXXX 형식의 codepoint, count, lines가 있고, missing-glyphs.txt는 같은 글자를 한 줄로 모아 폰트 도구의 문자 칸에 바로 붙여 넣을 수 있습니다.
게임에서 언어 파일의 모든 글자가 든 시험 문자열을 하나 띄웁니다. 네모나 빈칸이 하나도 없어야 합니다.

문제 해결

증상	유력한 원인	확인 방법	해결
한국어·일본어 .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`를 만든 뒤 그것과 비교

버전과 출처

docs/UI-LAB.md를 위해 Chromium에서 측정했습니다. 글리프 4개짜리 .fnt로 .po를 검사하자 a 시 작 끝 내 기를 정확한 개수·줄 번호와 함께 보고했고, 폰트에 있는 가는 보고하지 않았습니다. 위 예시는 같은 함수로 다시 계산했으며, 헤더 항목 줄은 현재 파서의 동작 그대로입니다. .fnt 필드의 의미는 AngelCode BMFont 문서를, .po 구조는 GNU gettext 매뉴얼을 따릅니다.

참고한 공식 문서