일본어 글꼴과 문자의 함정 ── 업무 앱에서 JIS2004·이체자 선택자·외자를 다루는 법

「고객 명부의 『葛』 자가 화면과 인쇄한 장표에서 모양이 다르다. 데이터가 깨진 것 아니냐는 항의가 고객에게서 왔다」── 업무 시스템 유지보수에서 이런 상담은 드물지 않습니다. 또 하나 흔한 것이 「관공서에 내는 서류에서 성명의 글자가 나오지 않는다. 예전 PC에서는 나왔는데, 교체하니 □가 되었다」는 상담입니다.

둘 다 현장에서는 「문자 깨짐」이라 부르기 쉽지만, 인코딩 불일치로 생기는 문자 깨짐과는 다른 문제입니다. 전자는 데이터가 1비트도 바뀌지 않았는데 겉모습만 바뀐 것이고, 후자는 그 PC에만 있던 「외자」가 사라진 것입니다.

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

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

이 글의 약속은 단순합니다. 문자 코드(데이터 층)와 글꼴(겉모습 층)을 나눠 생각하면, 일본어 문자 문제의 대부분은 정리할 수 있습니다. JIS2004의 자형 변경, 이체자 선택자(IVS), 외자(EUDC), 행정의 문자 기반, 글꼴 선정과 임베드까지, 업무 시스템 개발자와 정보시스템 담당자가 판단에 쓸 수 있는 형태로 정리합니다.

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)를 성명 데이터에 함부로 적용해서는 안 됩니다. 전각·반각 통합이나 호환 문자 치환으로, 유지해야 할 구분이 사라집니다.¹³

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

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 14건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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의 문자 코드와 개행 코드 - 문자 깨짐과 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 기반이며, OpenType의 jp90 기능을 통해 JIS90 시대 자형에 접근할 수 있는 구성입니다.²¹

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. 대응하지 않는 환경에서의 동작

글꼴 측은 OpenType의 cmap 테이블(format 14)로 IVS와 자형의 대응을 구현합니다.⁵ 대응 글꼴(IPAmj 명조 등)과 대응 앱이 갖춰지면 지정대로의 자형이 나오지만, 갖춰지지 않으면 다음과 같이 됩니다.

• 사양상 올바른 동작: 선택자는 무시되고, 기본 문자의 기본 자형으로 표시된다(선택자 자체는 보이지 않음)
• 오래된 앱이나 일부 렌더링 계열: 선택자가 독립된 알 수 없는 문자로 다루어져, □가 추가로 표시된다

즉 IVS는 「품질이 떨어져도 기본 문자는 읽을 수 있다」는 설계이지만, 「지정한 자형으로 반드시 표시된다」는 보장은 받는 쪽 환경에 달려 있습니다. 행정 주민기록·호적 계열에서는 문자정보기반 계열 글꼴+IVS 조합이 쓰이지만, 일반 업무 시스템이 쉽게 받아들이면 표시·인쇄·연계처 어딘가에서 지정 자형이 유실됩니다.

flowchart TB
    accTitle: IVS가 붙은 데이터의 표시 방식
    accDescr: 대응 글꼴과 대응 앱이 갖춰지면 지정대로의 자형으로 표시되고, 갖춰지지 않으면 선택자가 무시되어 기본 문자의 기본 자형이 되며, 오래된 앱이나 일부 렌더링 계열에서는 선택자가 알 수 없는 문자로 다루어져 □가 추가로 표시된다
    ivs["기본 문자+이체자 선택자"] --> env{"대응 글꼴과 앱이 갖춰지는가?"}
    env -->|예| ok["지정대로의 자형으로 표시"]
    env -->|아니요| ignore["선택자는 무시되고 기본 자형으로 표시"]
    env -->|오래된 앱이나 일부 렌더링 계열| tofu["□가 추가로 표시된다"]
    ignore -.-> spec["사양상 이것이 올바른 동작"]

그림 6: IVS는 품질이 떨어져도 기본 문자는 읽을 수 있지만, 지정 자형으로 나올지는 받는 쪽 환경에 달려 있습니다.

4.2. 구현상의 주의 ── 「한 글자」가 최대 4 코드 유닛

IVS 선택자 U+E0100 이후는 보조 평면의 코드 포인트이므로, 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["UTF-16에서 최대 4 코드 유닛"]
    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·Web·다른 시스템으로 넘기는 순간 □가 되거나, 상대 측의 다른 외자로 보입니다
• OS 이전이나 PC 교체에서 eudc.tte 이관을 잊으면 「예전 PC에서는 나오던 글자가 나오지 않는다」가 일어납니다

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

flowchart TB
    accTitle: 외자가 그 PC에서만 나오는 이유
    accDescr: 사용자 정의 문자 편집기에서 만든 자형은 eudc.tte에 저장되고 그 PC의 레지스트리에서 글꼴에 연결되므로, 사용자 정의 영역의 코드만 메일이나 PDF나 다른 시스템으로 넘어가면 □가 되거나 다른 글자로 보인다
    edit["사용자 정의 문자 편집기로 자형을 만듦"] --> tte["eudc.tte에 저장"]
    tte --> reg["레지스트리로 글꼴에 연결"]
    reg --> local["그 PC에서는 표시할 수 있다"]
    tte -.-> stay["eudc.tte는 데이터와 함께 넘어가지 않음"]
    send["사용자 정의 영역의 코드만 상대에게"] --> dest["메일·PDF·다른 시스템"]
    dest --> broken["□가 되거나 다른 글자로 보임"]

그림 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["조사: 사용자 정의 영역을 스캔"] --> st2["식별: 대체 문자 대응표를 만든다"]
    st2 --> st3["치환: 대응표로 바꾼다"]
    st3 --> st4["차단: 새 외자를 만들지 않는다"]
    st1 -.-> tte["각 거점에서 eudc.tte를 회수"]
    st2 -.-> nomap["대응이 없을 때만 이미지 또는 주석"]

그림 9: 외자 이전은 조사·식별·치환·차단의 4단계로 진행하고, 새 외자는 만들지 않습니다.

행정 측도 방향은 같고, 지자체가 독자적으로 만들어 온 외자(전국에서 약 200만 자가 있다고도 합니다)를 뒤에 나오는 행정사무표준문자로 유일하게 식별해 사용을 그만두는 방침이 제시되어 있습니다.¹⁰ 「외자를 늘리지 않고, 표준화된 문자 집합으로 식별한다」는 공공·민간을 가리지 않고 이전의 기본 절차가 되어 가고 있습니다.

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

성명을 다루는 시스템 설계에서는 행정 측 문자 기반을 알아 두면 「어디까지 받을지」의 판단 재료가 됩니다.

지자체 기간 업무 시스템(표준 준거 시스템)에서는 성명 등의 정보 연계에 행정사무표준문자를 쓰고, 스마트폰처럼 통일된 연계 규정이 없는 외부 시스템과는 JIS X 0213:2012 범위로 연계한다는 2단 구성이 표준 사양입니다.¹⁰ 「내부에서는 넓은 문자 집합을 유지하고, 외부와는 일반 환경에서 표시할 수 있는 범위로 주고받는다」는 이 구도 자체가 민간 시스템에도 참고가 됩니다.

flowchart TB
    accTitle: 표준 준거 시스템의 2단 연계
    accDescr: 지자체 표준 준거 시스템은 성명 등의 정보 연계에 행정사무표준문자를 쓰고, 통일된 연계 규정이 없는 스마트폰 등 외부 시스템과는 JIS X 0213:2012 범위로 연계한다
    sys["지자체 표준 준거 시스템"] --> renkei["성명 등의 정보 연계"]
    sys --> gaibu["외부 시스템과의 연계"]
    renkei --> mjp["행정사무표준문자"]
    gaibu --> jis["JIS X 0213:2012의 범위"]
    gaibu -.-> sumaho["스마트폰 등 규정이 없는 상대"]
    mjp -.-> naibu["내부에서는 넓은 문자 집합을 유지"]

그림 10: 행정 연계는 행정사무표준문자, 규정이 없는 외부 연계는 JIS X 0213:2012라는 2단 구성입니다.

일반 업무 시스템에 대한 실무 지침으로는 다음을 권합니다.

• 받아들일 문자 집합을 정해, 사양서와 입력 검증 양쪽에 명시한다. 예를 들어 「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 --> prn["인쇄하는 환경"]
    exist --> srv["PDF 생성 서버"]
    scr -.-> hojo["보조 글꼴은 구성에 따라 없을 수 있음"]
    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 속성이나 로케일)를 올바르게 넘기지 않은 Web이나 앱에서 일어나기 쉽다
• 두부(□)가 나온다: 지정 글꼴에도 폴백 대상에도 글리프가 없다. 즉 □는 폴백의 「실패의 흔적」이며, 데이터는 살아 있는 경우가 많다

폴백은 구제 장치이며, 처음부터 올바른 글꼴을 고르는 일의 대체가 아닙니다.¹⁵ 업무 앱에서는 「주요 표시·인쇄 경로는 설계한 글꼴만으로 완결하고, 폴백은 예상 밖 문자의 보험」으로 두는 편이 바람직합니다. 다국어 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의 문자 코드와 개행 코드 - 문자 깨짐과 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에서도 표시되나요?

원칙적으로 표시되지 않습니다. 외자는 Unicode 사용자 정의 영역(U+E000~)에, 그 PC의 eudc.tte 파일로 사용자가 자형을 등록하는 방식이며, 같은 코드 포인트라도 다른 PC에서는 미정의이거나 다른 자형입니다. 그래서 메일·PDF·다른 시스템으로 넘기면 □가 되거나 다른 글자로 보이는 것이 숙명입니다. 이미 외자가 섞인 데이터를 넘겨받은 경우에는, 이전 시점에 사용자 정의 영역 사용 위치를 찾아내고 정규 Unicode 문자나 이체자 선택자로의 대응표를 만들어 바꾸는 것이 현실적입니다. 새 시스템에서 외자를 새로 만드는 것은 피해야 합니다.

업무 시스템에서 성명 문자는 어디까지 받아들여야 하나요?

「받아들일 문자 집합을 정해 사양으로 명시하는 것」이 첫째입니다. 호적에는 약 5만 6천 자의 호적통일문자가 있고, 행정의 표준 준거 시스템은 문자정보기반을 확장한 행정사무표준문자를 쓰는 방침이지만, 일반 업무 시스템이 같은 수준을 제한 없이 받아들여야 할 의무는 없습니다. 예를 들어 「JIS X 0213 범위까지」「이체자 선택자와 사용자 정의 영역은 받지 않는다」처럼 범위를 정하고, 입력 시 검증해 범위 밖은 알림이나 대체 표기로 운용하는 설계가 현실적입니다. 행정 시스템이나 지자체와 연계하는 시스템만 행정사무표준문자와 JIS X 0221 기반 연계 요건의 동향을 따라가야 합니다.

장표나 PDF에서 화면과 같은 글자가 나오게 하려면 어떻게 하면 되나요?

먼저 화면과 장표에서 같은 글꼴을 지정하고, PDF에는 글꼴을 임베드하는 것이 기본입니다. 글꼴이 다르면 같은 데이터라도 자형이 달라질 수 있고, 열람 측 PC에 글꼴이 없으면 대체 글꼴로 그려져 겉모습이 무너집니다. 임베드 가능 여부는 글꼴 라이선스(OpenType의 fsType)로 정해지므로 장표 라이브러리에 맡기지 말고 확인하십시오. 사용한 문자만 넣는 서브셋 임베드라면 파일 크기도 줄일 수 있습니다. 장기 보존이 요건이면 글꼴 임베드가 필수인 PDF/A를 검토합니다.

저자 프로필

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

Go Komura

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

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