일본어 글꼴과 문자의 함정 ── 업무 앱에서 JIS2004, IVS, 외자를 다루기

「고객 명단의 葛 자가 화면과 인쇄 전표에서 달라 보인다. 고객이 데이터가 깨진 것 아니냐고 항의했다」── 업무 시스템 유지보수에서 이런 상담은 드물지 않습니다. 또 하나는 「관공서에 제출하는 서류에서 인명 문자가 표시되지 않는다. 옛 PC에서는 표시되던 것이, 교체 뒤에는 □가 되었다」입니다.

둘 다 현장에서는 「문자 깨짐」이라 불리기 쉽지만, 인코딩 불일치에서 오는 문자 깨짐과는 다른 문제입니다. 전자는 데이터의 한 비트도 바뀌지 않고 외관만 바뀐 것이고, 후자는 그 PC에만 있던 「외자」가 사라진 것입니다.

flowchart TB
    accTitle: 흔한 두 상담의 정체
    accDescr: 화면과 전표에서 葛의 모양이 다르다는 상담은 데이터는 같고 외관만 바뀐 경우이고, PC 교체 뒤 □가 되었다는 상담은 그 PC에만 있던 외자가 사라진 경우이며, 둘 다 인코딩 불일치 문자 깨짐과는 다른 문제이다
    c1["상담 1: 화면과 전표의 모양이 다름"] --> r1["데이터는 그대로, 외관만 바뀜"]
    c2["상담 2: 교체 뒤 □가 됨"] --> r2["그 PC에만 있던 외자가 사라짐"]
    r1 --> diff["인코딩 문자 깨짐과는 다른 문제"]
    r2 --> diff

그림 1: 「문자 깨짐」이라 불리기 쉬운 두 상담은 둘 다 인코딩 불일치와는 다른 문제이다.

이 글의 약속은 단순합니다. 문자 코드(데이터) 층과 글꼴(외관) 층을 나누면, 대부분의 일본어 문자 문제는 다루기 쉬워집니다. JIS2004 글리프 변경, 이체자 선택자(IVS), 외자(EUDC)부터 정부의 문자 기반, 글꼴 선택과 임베드까지, 업무 시스템 개발자와 IT 담당자가 판단에 쓸 수 있는 형태로 정리합니다.

Shift_JIS ↔ UTF-8 변환에서 일어나는 「문자 깨짐」자체는 기존 기사에서 다루므로, 이 글은 「코드는 왕복이 맞는데, 외관이나 표시 가능 여부가 어긋나는」문제에 집중합니다.

1. 먼저 결론

• 「문자 깨짐」과 「글리프가 다르다」는 다른 문제입니다. 문자 깨짐은 바이트 열을 잘못 해석한 데이터 층의 사고이고, 글리프 차이는 글꼴이 가진 글리프의 차이인 외관 층의 사고이며, 대책은 완전히 다릅니다.
• 같은 Unicode 코드 포인트라도, 표시되는 글리프는 글꼴에 따릅니다. JIS X 0213:2004는 葛, 辻, 飴 등 168자의 예시 글리프를 인쇄 표준 형태로 개정했고, Windows도 Vista부터 MS Gothic / MS Mincho에서 JIS2004 글리프를 기본으로 삼았습니다.¹²
• 글리프를 데이터로 고정하는 표준 수단은 이체자 선택자(IVS)입니다. 기본 문자와 U+E0100 이후 선택자의 열로 글리프를 지정하며, Adobe-Japan1, Hanyo-Denshi, Moji_Joho(문자정보기반) 같은 컬렉션이 Unicode IVD에 등록되어 있습니다.³⁴
• 비대응 환경에서 IVS의 사양상 동작은 선택자를 무시하고 기본 문자의 기본 글리프를 표시하는 것입니다. 다만 IVS를 포함한 한 문자는 UTF-16에서 최대 4코드 유닛이 되므로, 문자 수와 슬라이스 구현에 주의가 필요합니다.⁵
• 외자(EUDC)의 운명은 「그 PC에서만 표시된다」입니다. 사용자 정의 영역 코드 포인트에는 합의된 의미가 없고, eudc.tte에 등록한 글리프는 다른 PC, 메일, PDF로 가지 않습니다.⁶⁷
• 인명을 다루는 시스템은 받아들이는 문자 집합을 정해 밝혀야 합니다. 정부 측은 호적통일문자와 문자정보기반을 바탕으로, 표준에 맞는 시스템이 「행정사무표준문자」를 쓰는 쪽으로 움직이고 있습니다.⁸⁹¹⁰
• 전표와 PDF에서는 「글꼴을 화면과 맞추고, 임베드한다」가 기준입니다. 임베드가 허용되는지는 글꼴의 라이선스(fsType)가 정하고, 장기 보존 PDF/A는 글꼴 임베드를 요구합니다.¹¹¹²
• 인명 데이터에 정규화(NFKC)를 함부로 적용하지 마십시오. 전각·반각 통일과 호환 문자 치환은 지켜야 할 구분을 잃습니다.¹³

한 문장으로 「어느 바이트 열을 저장하는가」는 데이터 설계 문제이고, 「어떻게 보이는가」는 글꼴 설계 문제입니다. 둘을 섞어 논의하면, 고칠 수 있던 문제도 고칠 수 없게 됩니다.

2. 데이터와 외관을 따로 생각하기 ── 코드 포인트와 글리프

Unicode에서 문자는 코드 포인트라는 숫자로 표현됩니다. 葛는 U+845B이며, 이 숫자는 모든 PC에서 같습니다. 반면 그 숫자를 화면이나 종이에 그리는 방법은 글꼴이 가진 글리프가 정합니다. 같은 U+845B가 글꼴 A와 글꼴 B에서 세부가 다른 것은 정상 동작입니다.

이 두 층을 전제로 하면, 현장 증상은 다음과 같이 나눌 수 있습니다.

나눔의 단서로 「�」과 「□」의 차이를 기억하면 유용합니다. U+FFFD(REPLACEMENT CHARACTER)의 「�」은 데이터 층 변환 실패의 흔적이며, 원래 문자는 이미 잃었습니다. 반면 「□」는 많은 경우 데이터는 아직 있는데 글꼴에 글리프가 없는 것뿐이며, 글꼴을 바꾸면 표시될 수 있습니다.

flowchart TB
    accTitle: �와 □로 증상을 나누기
    accDescr: 문자가 올바르게 표시되지 않을 때 �는 원래 문자가 이미 사라진 데이터 층 변환 실패의 흔적이고, □는 데이터는 아직 있는데 글꼴에 글리프가 없는 것뿐이며 글꼴을 바꾸면 표시될 수 있다
    symptom["문자가 올바르게 표시되지 않음"] --> which{"무엇이 보이는가?"}
    which -->|�가 보임| datalayer["데이터 층의 사고"]
    datalayer -.-> lost["변환 실패의 흔적（원래 문자는 잃음）"]
    which -->|□가 보임| viewlayer["외관 층의 사고"]
    viewlayer -.-> noglyph["글꼴에 글리프가 없는 것뿐"]
    noglyph --> fixable["글꼴을 바꾸면 표시될 수 있음"]

그림 2: �는 데이터 층 사고의 징후이고 □는 외관 층 사고의 징후이며, 조사의 입구가 바뀐다.

인코딩 자체의 기본(CP932와 UTF-8, BOM, 개행 코드)은 「Windows의 문자 코드를 정리한다 - 왜 문자 깨짐이 일어나는가, 특히 Linux와 조합했을 때 무엇이 어긋나는가」와 「Windows의 문자 코드와 개행 코드를 정리한다 - Shift_JIS / UTF-8 / UTF-16, 문자 깨짐, CRLF / LF, 왜 혼란스러운가」에서 다룹니다. 여기서부터는 외관 층과, 그 경계에서 일어나는 문제입니다.

3. JIS90에서 JIS2004로 ── 코드는 그대로인데 글리프가 바뀌었다

서두의 「화면과 전표에서 葛가 달라 보인다」의 정체는, 많은 경우 여기입니다.

국어심의회의 2000년 보고 「표외한자자체표」를 따라, 2004년 개정 JIS X 0213:2004(통칭 JIS2004)는 168개 한자의 예시 글리프를 이른바 강희자전 형태에 가까운 인쇄 표준 형태로 개정했습니다. 葛, 辻, 飴, 芦, 溢, 餅 등이 대표 예입니다.¹

Windows도 이에 맞춰 Windows Vista부터 MS Gothic / MS Mincho(그리고 새로 도입된 Meiryo)에서 JIS2004 글리프를 기본으로 삼았습니다. 현재 MS Gothic도 JIS2004 기반 기본 글리프를 가지며, JIS90 시대 글리프는 OpenType jp90 기능으로 접근하는 구조입니다.²¹

flowchart TB
    accTitle: 현재 MS Gothic의 글리프 구조
    accDescr: Vista부터 MS Gothic은 JIS2004 글리프를 기본으로 하고, OpenType jp90 기능으로 JIS90 시대 글리프에 접근하는 구조이다
    msg["MS Gothic（Vista 이후）"] --> def["기본 글리프: JIS2004 기반"]
    msg --> feat["jp90 기능을 통해"]
    feat --> old["JIS90 시대 글리프"]

그림 3: 현재 MS Gothic은 JIS2004 글리프를 기본으로 하고, jp90 기능으로 JIS90 글리프로 전환할 수 있다.

여기서 중요한 것은 글꼴만 바뀌었고, 데이터는 전혀 바뀌지 않았다는 점입니다.

• 葛의 코드 포인트는 XP와 Windows 11 모두 U+845B입니다
• XP(JIS90 글리프)에서는 감싸는 부수의 안을 ヒ로 단순화한 형태로 표시되고, Vista 이후(JIS2004 글리프)에서는 안에 人도 쓰는 형태로 표시됩니다
• 따라서 옛 시스템에서 인쇄한 전표의 스캔 이미지와 새 PC의 화면 표시는 문자의 모양이 어긋납니다. 데이터 비교는 완전히 일치합니다

辻의 신뇨 부수가 한 점인지 두 점인지, 飴의 「먹을 식」부수 형태 등도 같습니다. 이 역사를 모르면 조사는 「이전에서 데이터가 깨졌다」는 잘못된 방향으로 가기 쉽습니다. 이전 전후로 문자의 외관이 다르다는 말을 들으면, 먼저 코드 포인트를 비교하고, 일치하면 글꼴 글리프 차이를 의심하는 것이 올바른 순서입니다.

flowchart TB
    accTitle: 같은 코드 포인트, 글꼴에 따라 다른 글리프
    accDescr: 葛의 코드 포인트 U+845B는 XP와 Windows 11 모두에서 같고, 표시 모양만 JIS90 글리프 글꼴과 JIS2004 글리프 글꼴 사이에서 바뀌며, 데이터 비교는 완전히 일치한다
    cp["코드 포인트 U+845B（葛）"] --> f90["JIS90 글리프 글꼴（XP）"]
    cp --> f04["JIS2004 글리프 글꼴（Vista 이후）"]
    f90 --> g90["안을 ヒ로 단순화한 형태"]
    f04 --> g04["안에 人을 쓰는 인쇄 표준 형태"]
    g90 -.-> same["데이터 비교는 완전히 일치"]
    g04 -.-> same

그림 4: 글꼴만 바뀌었고, 코드 포인트 U+845B는 모든 환경에서 같다.

문자 자체는 바뀌지 않았으므로, 두 글리프 모두 「같은 문자」입니다. 다만 인명에서는 본인이나 관공서가 특정 형태를 고집하는 경우가 있고, 그 「데이터로서」의 구분 요구에 답하는 것이 다음 주제인 IVS입니다.

4. 이체자 선택자(IVS) ── 글리프를 데이터로 지정하기

IVS(Ideographic Variation Sequence)는 한자 바로 뒤에 「이체자 선택자」라는 보이지 않는 코드 포인트를 두어, 글리프 이체를 데이터로 지정하는 메커니즘입니다. 쓰는 선택자는 U+E0100–U+E01EF(VS17–VS256)입니다.³

어느 「기본 문자 + 선택자」열이 어느 글리프를 가리키는지는 Unicode Consortium이 관리하는 IVD(Ideographic Variation Database)라는 레지스트리가 정합니다. 주요 컬렉션은 다음과 같습니다.⁴

Microsoft 문서는 예를 들어 U+845B만(葛)이 니시카사이역 표기에 쓰이고, U+845B+U+E0100(VS17)이 나라현 가쓰라기시 표기에 쓰인다고 듭니다. 같은 葛이지만, 어느 글리프인지를 데이터로 구분할 수 있습니다.³

flowchart TB
    accTitle: IVS로 같은 葛를 데이터로 구분하는 예
    accDescr: U+845B만의 葛는 니시카사이역 표기에 쓰이고, U+845B 뒤에 VS17을 둔 열은 가쓰라기시 표기에 쓰이며, 어느 열이 어느 글리프를 가리키는지는 IVD 레지스트리가 정한다
    seq1["U+845B만"] --> gl1["니시카사이역 표기에 쓰인 글리프"]
    seq2["U+845B + VS17"] --> gl2["가쓰라기시 표기에 쓰인 글리프"]
    ivd["IVD（레지스트리）"] -.-> gl1
    ivd -.-> gl2

그림 5: 같은 葛라도 선택자의 유무로 어느 글리프인지를 데이터로 구분할 수 있다.

4.1. 대응하지 않는 환경에서의 동작

글꼴 측에서 IVS와 글리프의 대응은 OpenType cmap 테이블(포맷 14)로 구현됩니다.⁵ 대응 글꼴(IPAmj 명조 등)과 대응 앱이 둘 다 있으면 지정한 글리프가 나오고, 없으면 다음과 같이 됩니다.

• 사양상의 올바른 동작: 선택자를 무시하고 기본 문자의 기본 글리프를 표시(선택자 자체는 보이지 않음)
• 옛 앱과 일부 그리기 스택: 선택자를 독립된 알 수 없는 문자로 취급해, 여분의 □가 표시됨

즉 IVS는 「열화해도 기본 문자는 읽을 수 있게」설계되어 있지만, 「항상 지정한 글리프로 표시된다」는 보장은 받는 쪽 환경에 따릅니다. 정부 주민기록·호적 시스템은 문자정보기반 글꼴과 IVS의 조합을 쓰지만, 일반 업무 시스템이 함부로 받아들이면 표시, 인쇄, 하위 시스템 어딘가에서 글리프가 떨어집니다.

flowchart TB
    accTitle: IVS를 포함한 데이터가 표시되는 방식
    accDescr: 대응 글꼴과 대응 앱이 둘 다 있으면 지정한 글리프로 표시되고, 없으면 선택자를 무시하고 기본 문자의 기본 글리프가 보이며, 옛 앱과 일부 그리기 스택에서는 선택자를 알 수 없는 문자로 취급해 여분의 □가 표시된다
    ivs["기본 + IVS 선택자"] --> env{"대응 글꼴 + 앱인가?"}
    env -->|예| ok["지정한 글리프"]
    env -->|아니오| other{"어떻게 그려지는가?"}
    other -->|무시| ignore["기본 글리프"]
    other -->|옛 / 일부 스택| tofu["여분의 □"]
    ignore -.-> spec["사양상의 올바름"]

그림 6: IVS는 열화해도 기본 문자로 읽을 수 있지만, 지정한 글리프가 나오는지는 받는 쪽 환경에 따른다.

4.2. 구현상의 주의 ── 「한 문자」가 최대 4코드 유닛이 될 수 있다

U+E0100 이후의 IVS 선택자는 보조 평면의 코드 포인트이므로, UTF-16에서는 항상 서로게이트 쌍(2코드 유닛)입니다. 기본 문자가 보조 평면 한자(예: JIS2004에서 추가된 𠮟(U+20B9F))이면 기본만으로 이미 2코드 유닛이며, 사용자가 「한 문자」로 인식하는 열은 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」에 맞을지는 요구로 정하고 구현해야 합니다

flowchart TB
    accTitle: IVS를 포함한 한 문자와 UTF-16 코드 유닛
    accDescr: 사용자가 한 문자로 인식하는 기본 문자와 이체자 선택자의 열은 선택자가 항상 서로게이트 쌍이고, 기본 문자가 보조 평면 한자면 추가로 2코드 유닛이 되어 UTF-16에서 최대 4코드 유닛이다
    one["보이는 한 문자"] --> base["기본 문자"]
    one --> vs["이체 선택자"]
    base -.-> bnote["보조 평면이면 +2"]
    vs -.-> vnote["항상 2코드 유닛"]
    base --> total["최대 4 UTF-16 유닛"]
    vs --> total
    total -.-> risk["고정 슬라이스에서 쪼개짐"]

그림 7: IVS를 포함한 한 문자는 UTF-16에서 최대 4코드 유닛이 될 수 있으며, 코드 유닛으로 자르는 것은 위험하다.

5. 외자(EUDC) ── 그 PC에서만 표시되는 문자

외자는 사용자가 Unicode 사용자 정의 영역(PUA: U+E000–U+F8FF 등)의 코드 포인트에 자기 글리프를 할당하는 메커니즘입니다. 사용자 정의 영역 코드 포인트에는 전 세계적으로 합의된 의미가 없으며, 같은 U+E000이 PC마다, 조직마다 다른 문자에 할당될 수 있습니다.⁶

Windows에서는 사용자 정의 문자 편집기(eudcedit.exe)로 글리프를 만들고, eudc.tte라는 글꼴 파일에 저장됩니다. 이 파일은 숨은 글꼴로 설치되고 HKEY_CURRENT_USER\EUDC 레지스트리에서 각 글꼴과 연결됩니다.⁷ Shift_JIS(CP932) 시대의 외자 범위는 0xF040–0xF9FC였고, Unicode로 변환하면 사용자 정의 영역으로 매핑됩니다.

이 메커니즘의 결과는 분명합니다.

• eudc.tte는 그 PC(그 사용자)의 것이며, 데이터와 함께 상대에게 가지 않습니다
• 메일, PDF, 웹, 다른 시스템으로 넘기는 순간 □가 되거나 상대의 다른 외자처럼 보입니다
• OS 이전이나 PC 교체에서 eudc.tte를 옮기는 것을 잊으면 「옛 PC에서 표시되던 문자가 표시되지 않는다」가 일어납니다

이것이 서두 두 번째 상담의 정체입니다.

flowchart TB
    accTitle: 외자가 그 PC에서만 표시되는 이유
    accDescr: 사용자 정의 문자 편집기에서 만든 글리프는 eudc.tte에 저장되고 그 PC의 레지스트리에서 글꼴과 연결되므로, 사용자 정의 영역 코드만 메일, PDF, 다른 시스템으로 넘기면 □가 되거나 다른 문자처럼 보인다
    edit["PUA 글리프를 만듦"] --> tte["eudc.tte에 저장"]
    edit -.-> editN["사용자 정의 문자 편집기"]
    tte --> reg["레지스트리 글꼴 매핑"]
    reg --> local["그 PC에서 표시"]
    tte -.-> stay["eudc.tte는 뒤에 남음"]
    send["PUA 코드만 감"] --> dest["메일 / PDF / 다른 시스템"]
    dest --> broken["□ 또는 잘못된 문자"]
    local ~~~ send

그림 8: 글리프는 eudc.tte에 살고, 데이터에는 사용자 정의 영역 번호만 남으므로, 외자는 PC를 떠나면 깨져 보인다.

5.1. 이미 외자를 받은 시스템을 위한 현실적인 답

문제는 레거시 시스템에서 이어받은 데이터에 이미 외자가 섞여 있을 때입니다. 이전 의뢰에서 권하는 절차는 다음과 같습니다.

1. 조사: 데이터베이스와 파일을 사용자 정의 영역(U+E000–U+F8FF) 정규식으로 스캔하고, 쓰는 외자 코드와 건수를 목록화합니다. 각 거점 PC에서 eudc.tte를 모아 글리프를 확인합니다
2. 특정: 외자마다 「정규 Unicode 문자로 표현할 수 있는가」, 「IVS로 표현할 수 있는가」, 「문자정보기반(MJ)에 대응 문자가 있는가」를 조사하고 대체 문자 대응표를 만듭니다. 실무에서는 대부분이 옛 형태를 JIS 외자로 만들어 둔 경우입니다
3. 치환: 대응표에서 데이터를 치환합니다. 정말로 대응 문자가 없을 때만 이미지로 두거나 그 레코드에 주석을 붙입니다
4. 차단: 새 시스템에서는 검증에서 사용자 정의 영역 입력을 거부하고, 새 외자를 만들지 않습니다

flowchart TB
    accTitle: 외자가 섞인 데이터를 이전하는 절차
    accDescr: 사용자 정의 영역을 스캔하고 eudc.tte를 모아 쓰는 외자를 목록화하고, 대체 문자 대응표를 만들어 치환하며, 새 시스템에서는 검증에서 사용자 정의 영역 입력을 거부하고 새 외자를 만들지 않는다
    st1["조사: PUA를 스캔"] --> st2["특정: 대체표"]
    st2 --> st3["표에서 치환"]
    st3 --> st4["차단: 새 외자 없음"]
    st1 -.-> tte["eudc.tte를 수집"]
    st2 -.-> nomap["대응 없음: 이미지 또는 주석"]

그림 9: 외자는 조사, 특정, 치환, 차단의 네 단계로 이전하고, 새 외자를 만들지 않는다.

정부 측의 방향도 같습니다. 지자체가 독자로 만든 외자(전국 약 200만 자라 함)를 뒤에 나오는 행정사무표준문자에 대해 유일하게 식별하고 사용을 멈추는 방침이 밝혀져 있습니다.¹⁰ 「외자를 늘리지 말고, 표준화된 문자 집합에 대해 식별한다」가 공공·민간 모두에서 자리 잡은 이전 패턴이 되고 있습니다.

6. 정부의 문자 기반 ── 호적통일문자에서 행정사무표준문자로

인명을 다루는 시스템의 설계에서는, 정부 측 문자 기반을 아는 것이 「어디까지 받아들일지」를 정하는 재료가 됩니다.

지자체 핵심 업무 시스템(표준에 맞는 시스템)에서는 인명 등의 정보 연동에는 행정사무표준문자를 쓰고, 통일된 연동 규칙이 없는 외부 시스템── 스마트폰 등──과는 JIS X 0213:2012 범위로 연동하는 2층 구조가 표준 사양에 있습니다.¹⁰ 「안에서는 넓은 문자 집합을 들고, 밖과는 일반 환경이 표시할 수 있는 범위로 교환한다」는 구조 자체도 민간 시스템의 참고가 됩니다.

flowchart TB
    accTitle: 표준 적합 시스템의 2층 연동
    accDescr: 지자체 표준 적합 시스템은 인명 등의 정보 연동에 행정사무표준문자를 쓰고, 통일된 연동 규칙이 없는 스마트폰 같은 외부 시스템과는 JIS X 0213:2012 범위로 연동한다
    sys["지자체 표준 시스템"] --> renkei["이름 연동"]
    sys --> gaibu["외부 시스템"]
    renkei --> mjp["행정 표준 문자"]
    mjp -.-> mjpN["인명 등"]
    gaibu --> jis["JIS X 0213:2012 범위"]
    gaibu -.-> sumaho["규칙 없음（스마트폰）"]
    mjp -.-> naibu["안에는 넓은 집합을 보유"]

그림 10: 2층 구조. 정부 연동은 행정사무표준문자, 규칙 없는 외부 연동은 JIS X 0213:2012.

일반 업무 시스템의 실무 안내로는 다음을 권합니다.

• 받아들이는 문자 집합을 정해 사양과 입력 검증 양쪽에 밝히십시오. 예를 들어 「JIS X 0213:2012 범위」, 「사용자 정의 영역과 결합 문자는 허용하지 않음」, 「IVS는 받지 않음(또는 받지만 표시 보장은 IPAmj 명조 환경만)」
• 제한 없이 받아들이지 마십시오. 「Unicode이니 무엇이든」이라는 설계는 표시, 인쇄, 연동 어딘가에서 깨집니다
• 범위 밖 문자의 운용을 미리 정하십시오. 대체 표기(신자체, 가타카나)로 치환하는 규칙과 당사자에게 설명하는 문구 자체가 시스템 사양입니다
• 정부나 금융 같은 하위 시스템에 문자 집합 규칙이 있으면, 그것을 권위로 삼아 맞춥니다

flowchart TB
    accTitle: 받아들이는 문자 집합의 설계와 운용
    accDescr: 받아들이는 문자 집합을 정해 사양과 입력 검증 양쪽에 밝히고, 범위 안 문자는 받아들이며, 범위 밖 문자는 대체 표기로 치환하는 규칙과 당사자에게 설명하는 문구를 포함한 운용을 정한다
    decide["받아들이는 문자 집합을 정함"] --> spec["사양에 밝힘"]
    decide --> valid["입력 검증에 밝힘"]
    valid --> range{"범위 안인가?"}
    range -->|예| ok["받아들임"]
    range -->|아니오| alt["대체 표기로 치환"]
    alt -.-> word["당사자에게 설명하는 문구도 사양"]

그림 11: 받아들이는 문자 집합을 사양과 입력 검증 양쪽에 밝히고, 범위 밖 운용도 정한다.

7. 글꼴 선택과 임베드 ── 화면과 전표를 맞추기

7.1. 흔한 글꼴의 성격

선택에서 중요한 것은 서체 취향보다 그 글꼴이 표시, 인쇄, PDF 생성에 관여하는 모든 환경에 있는가입니다. Windows 10/11의 일본어 보충 글꼴(BIZ UD 등)은 구성에 따라 없을 수 있고, 서버 측에서 PDF를 만드는 구성에서는 서버의 글꼴 유무가 직접 영향을 줍니다.

flowchart TB
    accTitle: 글꼴을 고를 때 확인할 환경
    accDescr: 글꼴 선택에서 중요한 것은 서체 취향보다 그 글꼴이 표시, 인쇄, PDF 생성에 관여하는 모든 환경에 있는가이며, 보충 글꼴의 구성과 서버의 글꼴 유무가 직접 영향을 준다
    cand["후보 글꼴"] --> exist["모든 환경에 있는가?"]
    exist --> scr["표시 환경"]
    exist --> more{"인쇄 또는 PDF 서버인가?"}
    more --> prn["인쇄 환경"]
    more --> srv["PDF 생성 서버"]
    scr -.-> hojo["보충 글꼴인가?"]
    hojo -.-> hojoN["없을 수 있음"]
    srv -.-> eikyo["서버의 글꼴이 중요"]

그림 12: 글꼴은 서체 취향보다 표시, 인쇄, PDF 생성의 모든 환경에 있는지로 고른다.

7.2. 전표 설계의 기본 ── 맞추고, 임베드한다

• 화면과 전표에 같은 글꼴을 지정하십시오. 글꼴이 다르면 같은 데이터가 다른 글리프처럼 보이고, 서두의 항의가 납니다. 「화면은 Meiryo, 전표는 MS Mincho」같은 구성은 적어도 JIS2004 168자에서 글리프 차이가 있는지 확인해야 합니다
• PDF에 글꼴을 임베드하십시오. 임베드하지 않으면 보는 쪽이 손에 있는 글꼴로 대체 그려, 글리프뿐 아니라 레이아웃도 바뀔 수 있습니다
• 임베드가 허용되는지는 라이선스가 정합니다. OpenType 글꼴은 fsType 필드에 임베드 권한(Installable / Restricted / Preview & Print / Editable, 서브셋 금지 등)을 선언하며, 임베드가 허가되지 않은 글꼴을 임베드해서는 안 됩니다.¹¹ 상용 글꼴은 계약 확인이 필요합니다
• 서브셋 임베드를 기준으로 하십시오. 사용한 문자의 글리프만 넣으면, 일본어 글꼴 전체(수 MB에서 수십 MB)를 떠안지 않아도 됩니다
• 장기 보존 요구가 있으면 PDF/A. PDF/A(ISO 19005)는 표시에 필요한 자원을 파일 안에 완결시키는 표준이며, 글꼴 임베드가 요구됩니다.¹² 「10년 뒤 열었더니 글리프가 바뀌어 있었다」를 막는 가장 확실한 방법이기도 합니다

flowchart TB
    accTitle: 글꼴 임베드의 판단 흐름
    accDescr: PDF에 글꼴을 임베드하기 전에 fsType 임베드 라이선스를 확인하고, 허가되어 있으면 서브셋 임베드를 기준으로 하며, 장기 보존 요구가 있으면 임베드를 요구하는 PDF/A를 검토한다
    emb["PDF에 글꼴을 임베드"] --> lic{"fsType으로 임베드가 허가되는가?"}
    lic -->|허가됨| sub["서브셋 임베드가 기준"]
    lic -->|허가되지 않음| ng["임베드해서는 안 됨"]
    sub -.-> gly["사용한 문자의 글리프만"]
    sub -->|장기 보존 요구| pdfa["PDF/A를 검토"]
    pdfa -.-> must["글꼴 임베드가 요구됨"]

그림 13: 임베드는 fsType 라이선스 확인을 전제로 하며, 서브셋 임베드와 PDF/A가 기준이다.

인쇄와 PDF 출력의 구현 수단을 고르는 법은 「Windows 업무 앱의 인쇄와 PDF 출력」에서 깊게 다룹니다.

8. 글꼴 링킹과 폴백 ── 「다른 글꼴이 섞인다」는 현상

지정한 글꼴에 글리프가 없는 문자는 아무것도 표시되지 않는 것이 아니라, 다른 글꼴로 대체 그리는 것이 현대 그리기 스택의 기본 동작입니다. GDI에서는 레지스트리(FontLink\SystemLink)에 정의된 「글꼴 링킹」이 하고, DirectWrite, WPF, 브라우저에서는 「글꼴 폴백」이 합니다.¹⁵

flowchart TB
    accTitle: 글꼴 링킹과 폴백의 흐름
    accDescr: 지정한 글꼴에 글리프가 있으면 그대로 표시되고, 없으면 글꼴 링크 또는 폴백 글꼴로 대체 그려지며, 어디에도 글리프가 없으면 □가 되지만 데이터는 아직 살아있는 경우가 많다
    disp["문자를 표시"] --> has{"지정한 글꼴에 글리프가 있는가?"}
    has -->|예| draw["지정한 글꼴로 표시"]
    has -->|아니오| fb{"링크 또는 폴백 대상에 있는가?"}
    fb -->|예| alt["다른 글꼴로 대체 그림"]
    alt -.-> mixed["서체가 섞인 느낌의 원인"]
    fb -->|아니오| tofu["□（두부）가 표시됨"]
    tofu -.-> alive["데이터는 아직 살아있는 경우가 많음"]

그림 14: □는 폴백 실패의 흔적이며, 대체 그리기가 성공하는지가 「섞임」과 「두부」의 갈림이다.

이 메커니즘을 알면 다음 흔한 경우를 설명할 수 있습니다.

• 라틴과 일본어의 서체 느낌이 다르다: 라틴 글꼴을 먼저 지정했기 때문에, 일본어 부분만 링크 또는 폴백 일본어 글꼴로 그려지고 있다
• 일본어 문장의 한자만 중국풍 글리프가 된다: 폴백 대상이 중국어 글꼴로 해석되었다. 언어 정보(lang 특성이나 로케일)를 올바르게 넘기지 않는 웹 페이지나 앱에서 일어나기 쉽다
• 두부(□)가 나타난다: 지정한 글꼴에도 폴백 대상에도 글리프가 없다. 즉 □는 「폴백 실패의 흔적」이며, 데이터는 아직 살아있는 경우가 많다

폴백은 구제 메커니즘이며, 처음부터 올바른 글꼴을 고르는 것을 대신하지 않습니다.¹⁵ 업무 앱에서 건강한 위치는 「주된 표시·인쇄 경로는 설계한 글꼴만으로 완결하고, 폴백은 예상 밖 문자의 보험」입니다. 다국어 UI에서 글꼴을 고르는 생각은 「WinForms/WPF 앱 다국어화」도 보십시오.

9. 업무 앱의 구현 체크리스트

마지막으로, 입력부터 연동까지 각 층에서 확인할 점을 표로 정리합니다.

정규화는 특히 이 글의 주제 그 자체인 함정입니다. 「좋은 의도」로 적용한 처리가 이체자와 전각·반각의 구분을 짓밟습니다. 원본은 그대로, 처리는 복사본에서가 원칙입니다. CSV 연동의 문자 코드 사고는 「CSV는 “그냥 텍스트”가 아니다」에서 깊게 다룹니다.

flowchart TB
    accTitle: 원본은 그대로, 처리는 복사본에서
    accDescr: 입력된 문자열을 원본으로 그대로 저장하고, 정규화는 검색 키 생성 같은 용도로 한정해 복사본에 적용한다. 원본에 NFKC를 적용하면 이체자와 전각·반각의 구분을 잃는다
    input["입력된 문자열"] --> orig["원본: 입력된 대로 저장"]
    input --> copy["복사본: 용도로 한정해 정규화"]
    copy -.-> use["검색 키 생성 등"]
    orig -.-> ng["원본에 NFKC를 적용하면 구분이 짓밟힘"]

그림 15: 정규화는 용도로 한정해 복사본에 적용하고, 원본은 입력된 대로 저장한다.

10. 정리

• 문자 문제는 먼저 「데이터 층(문자 인코딩)」과 「외관 층(글꼴)」로 나눕니다. �는 데이터 층 사고의 징후이고, □는 외관 층 사고의 징후입니다.
• JIS X 0213:2004는 168자의 예시 글리프를 바꿨고, Windows는 Vista부터 JIS2004 글리프를 기본으로 합니다. 葛, 辻, 飴가 환경에 따라 달라 보이는 것은 글꼴의 역사이지 데이터 손상이 아닙니다.
• 글리프를 데이터로 고정하는 표준 수단은 IVS이지만, 대응 글꼴과 대응 앱이 없으면 기본 글리프로 떨어집니다. 한 문자가 최대 4 UTF-16 코드 유닛이 될 수 있다는 구현 영향을 잊지 마십시오.
• 외자(EUDC)는 그 PC 고유의 자산이며 데이터와 함께 갈 수 없습니다. 현실적인 답은 이전 때 목록화하고, 정규 문자 또는 IVS로의 대응표에서 치환하며, 새로 만드는 것을 멈추는 것입니다.
• 인명을 다루는 시스템은 받아들이는 문자 집합을 정해 밝힙니다. 정부는 호적통일문자와 문자정보기반을 바탕으로 행정사무표준문자로 표준화하고 있으며, 연동하는 시스템은 그 움직임을 따라야 합니다.
• 전표와 PDF에서는 「글꼴을 화면과 맞추고, 라이선스를 확인하고, 임베드한다」가 기준입니다. 장기 보존에는 PDF/A를 검토합니다.
• NFKC 정규화, 코드 유닛으로의 슬라이스, CP932 변환은 이체자와 외자를 조용히 깨는 세 지점입니다. 원본 저장과 그래핌 단위 처리를 원칙으로 하십시오.

다음에 「문자가 다르다」는 말을 들으면, 먼저 질문을 이렇게 다시 만드십시오. 코드 포인트가 같은가, 다른가? 같으면 글꼴 문제이고, 다르면 데이터 문제입니다. 그 한 수가 조사의 입구를 잘못 잡지 않게 합니다.

flowchart TB
    accTitle: 조사의 입구를 정하는 첫 질문
    accDescr: 문자가 다르다는 말을 들으면 먼저 코드 포인트가 같은지 다른지를 비교하고, 같으면 글꼴 문제로, 다르면 데이터 문제로 조사를 시작한다
    said["문자가 다르다는 말을 들음"] --> cmp{"코드 포인트가 같은가?"}
    cmp -->|같음| fontp["글꼴 문제"]
    cmp -->|다름| datap["데이터 문제"]

그림 16: 코드 포인트가 같으면 글꼴 문제로, 다르면 데이터 문제로 조사를 시작한다.

관련 기사

• Windows의 문자 코드를 정리한다 - 왜 문자 깨짐이 일어나는가, 특히 Linux와 조합했을 때 무엇이 어긋나는가
• Windows의 문자 코드와 개행 코드를 정리한다 - Shift_JIS / UTF-8 / UTF-16, 문자 깨짐, CRLF / LF, 왜 혼란스러운가
• Windows 업무 앱의 인쇄와 PDF 출력 - System.Drawing.Printing / WPF / 보고서 라이브러리 구분 사용법
• WinForms/WPF 앱 다국어화 ── resx·새틀라이트 어셈블리·컬처 전환 실무
• CSV는 “그냥 텍스트”가 아니다 ── C# 업무 앱의 CSV 실무(문자 코드・Excel 호환・인젝션 대책)
• Windows 앱 접근성 입문 ── UI Automation과 합리적 배려 요구에 대비하기

관련 상담 영역

합동회사 코무라소프트에서는 업무 시스템의 문자 주변 설계와 조사를 다룹니다. 「화면과 전표에서 문자가 다르다」, 「이전 뒤 인명이 □가 되었다」같은 증상의 원인 분리부터, 레거시 시스템 이전 때의 외자 목록화와 대체 문자표 작성, 인명을 다루는 시스템의 수용 문자 집합 설계, 전표와 PDF의 글꼴 임베드 구성 리뷰까지, 코드 층과 글꼴 층 양쪽을 다룹니다.

• Windows 앱 개발
• 기존 자산 활용・이전 지원
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

같은 葛 자가 PC나 인쇄 전표에 따라 달라 보이는 이유는 무엇인가요?

문자 깨짐보다 글꼴 글리프의 차이일 가능성이 큽니다. JIS X 0213:2004(JIS2004)는 168개 한자의 예시 글리프를 인쇄 표준 형태로 개정했고, Windows도 Vista부터 MS Gothic / MS Mincho 등에서 JIS2004 글리프를 기본으로 삼았습니다. 葛, 辻, 飴 등이 대표 예로, Unicode 코드 포인트(데이터)는 같고 글꼴이 가진 글리프(외관)만 바뀌었습니다. 데이터를 비교하면 일치하고, XP 시대 전표 이미지와 새 PC 화면의 모양 불일치는 사양상의 동작입니다. 글리프까지 맞추고 싶으면 화면과 전표에 같은 글꼴을 쓰거나, 이체자 선택자로 글리프를 지정합니다.

이체자 선택자(IVS)를 쓰면 모든 인명 글리프 문제가 해결되나요?

그렇지 않습니다. IVS는 기본 문자 바로 뒤에 U+E0100 이후의 선택자를 두어 글리프를 데이터로 지정하는 메커니즘이며, 지정한 글리프는 IPAmj 명조 같은 대응 글꼴과 대응 앱이 둘 다 있을 때만 표시됩니다. 비대응 환경의 사양상 동작은 선택자를 무시하고 기본 문자의 기본 글리프를 보이는 것이며, 일부 환경에서는 선택자가 □로 나타날 수도 있습니다. 또한 IVS를 포함한 한 문자는 UTF-16에서 최대 4코드 유닛이 되어, 문자 수, 슬라이스, DB 열 길이 설계에 영향을 줍니다. 도입한다면 표시, 인쇄, 하위 시스템을 통해 대응 범위를 확인한 뒤에 쓰십시오.

외자(EUDC)로 등록한 문자가 다른 PC나 PDF에서 표시되나요?

원칙적으로는 안 됩니다. 외자는 사용자가 그 PC의 eudc.tte 파일에 Unicode 사용자 정의 영역(U+E000 이후) 코드 포인트로 글리프를 등록하는 메커니즘이며, 같은 코드 포인트는 다른 PC에서는 미정의이거나 다른 글리프입니다. 따라서 메일, PDF, 다른 시스템으로 넘기면 □가 되거나 다른 문자처럼 보입니다. 이미 외자가 섞인 데이터를 이어받았다면, 이전 때의 현실적인 길은 사용자 정의 영역 사용을 목록화하고, 정규 Unicode 문자 또는 이체자 선택자와의 대응표를 만들어 치환하는 것입니다. 새 시스템에서 새 외자를 만드는 것은 피해야 합니다.

업무 시스템은 인명 문자를 어디까지 받아들여야 하나요?

먼저 「받아들이는 문자 집합을 정해 사양으로 밝히는 것」입니다. 호적에는 약 56,000자의 호적통일문자가 있고, 정부 표준에 맞는 시스템은 문자정보기반을 확장한 행정사무표준문자를 쓰는 쪽으로 움직이고 있습니다── 다만 일반 업무 시스템이 같은 수준을 제한 없이 받아들일 의무는 없습니다. 현실적인 설계는 「JIS X 0213 범위까지」또는 「이체자 선택자나 사용자 정의 영역은 받지 않는다」같은 범위를 정하고, 입력 때 검증하며, 범위 밖은 알림이나 대체 표기로 운용하는 것입니다. 정부 시스템이나 지자체와 연동하는 시스템만 행정사무표준문자와 JIS X 0221 기반 연동 요구의 움직임을 따라야 합니다.

전표나 PDF가 화면과 같은 문자를 보이게 하려면 어떻게 하나요?

기준은 화면과 전표에 같은 글꼴을 지정하고, PDF에 글꼴을 임베드하는 것입니다. 글꼴이 다르면 같은 데이터라도 글리프가 바뀔 수 있고, 보는 PC에 글꼴이 없으면 대체 글꼴로 그려져 외관이 깨집니다. 임베드가 허용되는지는 글꼴의 라이선스(OpenType fsType)가 정하므로, 보고서 라이브러리에 맡기지 말고 확인하십시오. 사용한 문자만 넣는 서브셋 임베드는 파일 크기도 줄입니다. 장기 보존이 요구이면 글꼴 임베드를 요구하는 PDF/A를 검토합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.