Microsoft MVP성태의 닷넷 이야기
.NET Framework: 411. 유니코드의 "compatibility character"가 뭘까요? [링크 복사], [링크+제목 복사],
조회: 18611
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 8개 있습니다.)
.NET Framework: 326. 유니코드와 한글 - 유니코드와 닷넷을 이용한 한글 처리
; https://www.sysnet.pe.kr/2/0/1294

.NET Framework: 411. 유니코드의 "compatibility character"가 뭘까요?
; https://www.sysnet.pe.kr/2/0/1607

.NET Framework: 429. C# - 유니코드 한글 문자열을 ks_c_5601-1987로 변환하는 방법
; https://www.sysnet.pe.kr/2/0/1657

개발 환경 구성: 230. 유니코드의 Surrogate Pair, Supplementary Characters가 뭘까요?
; https://www.sysnet.pe.kr/2/0/1710

.NET Framework: 450. 영문 윈도우에서 C# 콘솔 프로그램의 유니코드 출력 방법
; https://www.sysnet.pe.kr/2/0/1712

.NET Framework: 794. C# - 같은 모양, 다른 값의 한글 자음을 비교하는 호환 분해
; https://www.sysnet.pe.kr/2/0/11710

개발 환경 구성: 407. 유니코드와 한글 - "Hangul Compatibility Jamo"
; https://www.sysnet.pe.kr/2/0/11724

Windows: 176. Raymond Chen이 한글날에 밝히는 윈도우의 한글 자모 분리 현상
; https://www.sysnet.pe.kr/2/0/12369




유니코드의 "compatibility character"가 뭘까요?

우연히 보게 된 글을 통해,

워드에서 특수문자 빨리 입력하기 
; http://techcap.blog.me/60191845609

"Celsius"에 대해 좀 더 찾아보니,

Celsius
; http://en.wikipedia.org/wiki/Celsius

다음의 문구를 접하게 되었습니다.

Unicode character

Unicode provides a compatibility character for the degree Celsius at U+2103 (decimal 8451), for compatibility with CJK encodings that provide such a character (as such, in most fonts the width is the same as for fullwidth characters). Its appearance is similar to the one synthesized by individually typing its two components (°) and (C). Shown below is the degree Celsius character followed immediately by the two-component version:


유니코드에 대해 그런대로 파악했다고 생각했는데,

유니코드와 한글 - 유니코드와 닷넷을 이용한 한글 처리
; https://www.sysnet.pe.kr/2/0/1294

갑자기 낯선 "compatibility character"가 눈에 들어온 것입니다. 이에 대해서 알고 넘어가야겠다 싶어 좀 더 검색한 결과 정말 잘 설명한 글이 나왔습니다.

유니코드와 UTF-8, 그리고 자바...
; http://blog.naver.com/hoya519/20023780743




간단하게 정리해 보겠습니다.

다음의 소스코드를 그대로 복사해서 Visual Studio 콘솔 프로젝트의 C# 소스코드에 붙여놓고 실행하면 출력 결과가 어떻게 나올까요?

using System;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(BitConverter.ToString(Encoding.Default.GetBytes("車")));
            Console.WriteLine(BitConverter.ToString(Encoding.Default.GetBytes("車")));

            Console.WriteLine(BitConverter.ToString(Encoding.UTF32.GetBytes("車")));
            Console.WriteLine(BitConverter.ToString(Encoding.UTF32.GetBytes("車")));
        }
    }
}

놀랍게도(?) 다음과 같이 나올 것입니다.

CB-E7
F3-B3
02-F9-00-00
CA-8E-00-00

이유는, 제가 첫 번째와 세 번째 글자에 대해서는 '거'자를 입력한 후 키보드의 "한자"키를 눌러 "수레 거"를 선택했고, 두 번째와 네 번째 글자에 대해서는 '차'를 입력한 후 키보드의 "한자"키를 눌러 "수레 차"를 선택했기 때문입니다.

동일한 한자인데 발음이 하나는 '거', 하나는 '차'로 나온 것입니다. 'ㄱ'과 'ㅊ'이라는 것 자체가 이미 문자열의 정렬에 영향을 미치기 때문에 코드에도 그것이 반영되어 2개의 코드가 나오는 것은 어찌 보면 타당합니다.

문제는 한자권 문화에 속하는 한국, 중국, 일본을 위한 유니코드 통합 한자 영역에는 대표 글자가 1개만 들어갈 수 있다는 점입니다. 아래의 글을 보면,

ISO/IEC-10646 Universal Multiple-Octet Coded Character Set (UCS)에 대해서
; http://www.w3c.or.kr/i18n/hangul-i18n/iso10646.html

A-zone: alphabetic and syllabic scripts together with varios symbols
I-zone: Chinese/Japanese/Korean (CJK) unified ideographs (unified East Asian ideographs: 통합 한자 영역)
O-zone: reserved for future standardisation
R-zone: restriced use zone (private use characters, presentation forms, compatibility characters, etc.)

각각의 Zone별로 다음과 같은 영역으로 배분되어 있음을 알 수 있습니다.

A-zone - 0x0000 ~ 0x4DBF: 19,903 positions
         0x4DC0 ~ 0x4DFF: Yijing Hexagram Symbols
I-zone - 0x4E00 ~ 0x9FFF: 20,992 positions
O-zone - 0xA000 ~ 0xDFFF: 16,384 positions
R-zone - 0xE000 ~ 0xFFFF: 8,190 positions

unicodeblocks 
; https://github.com/nagisa/unicodeblocks/blob/master/unicodeblocks/_blocklist.py

I-zone이라는 설명이 바로 한/중/일 통합 한자 영역인 것입니다. 수레 '차'와 수레 '거'중에 대표 문자로 된 것은 코드 영역에 따라 0x8ECA 값으로 할당된 '수레 차'입니다. 수레 '거'는 0xF902로써 R-zone이고 위에서 그 설명을 보면 "compatibility characters"에 속합니다.

이렇게 해서 KS_C_5601-1987 인코딩된 수레 '거(CB-E7)'를 유니코드로 바꾸면 다행히 0xF902로 바뀌고 그것을 다시 KS_C_5601-1987 인코딩으로 바꾸면 수레 '거'로 나올 수 있습니다. 이 정도면 "compatibility characters"라는 개념이 이해되셨을 것입니다.

하지만, 이 변환이 "JIS X 0208" 인코딩에서는 어떻게 나올까요? 해당 인코딩에서는 수레 '차'에 해당하는 문자만 있으므로 유니코드에서 "JIS X 0208"로 변환하게 되면 수레 '거'에 대한 정보를 잃어 버립니다. "유니코드와 UTF-8, 그리고 자바..." 문서에 따르면 이런 경우 "compatibility remapping" 함수가 제공되어야만 변환이 된다고 합니다. 하지만 변환이 된다해도 "JIS X 0208" 인코딩에서는 수레 '차'와 수레 '거'가 하나의 인코딩 글자에 매핑되기 때문에 이를 다시 유니코드로 역변환하는 경우 본래의 의미를 상실하게 됩니다.




참고로 본문에 나와 있는 소스코드는 KSC5601내에 표현된 한자 중에서 EUCJIS에 존재하지 않는 한자를 출력하는 코드를 싣고 있습니다.

// -------- HanjaTest.java ----------
// KSC5601내의 한자 범위: 0xCAA1 ~ 0xFDFE (4888 자 = 52 * 94)

import java.util.*;

public class HanjaTest {

    public static void main(String args[]) throws java.io.UnsupportedEncodingException
    {
        for( int high =  0xCA; high <= 0xFD; ++high )
        {
            for( int low =  0xA1; low <= 0xFE; ++low )
            {
                String unicode = new String(new byte[] {(byte) high, (byte) low}, "KSC5601");
                byte[] eucjis = unicode.getBytes("EUCJIS");

                System.out.print(
                    Integer.toHexString(high) +
                    Integer.toHexString(low) +
                    " (" + unicode + ") ==> " +
                    Integer.toHexString((int) unicode.charAt(0)));

                if ( eucjis.length == 1 && (eucjis[0] & 0xFF) == '?' )
                {
                    System.out.println( ", 없음" );
                }
                else
                {
                    System.out.println(
                        ", " + Integer.toHexString(eucjis[0] & 0xFF) +
                        Integer.toHexString(eucjis[1] & 0xFF) ) ;
                }
            }
        }
    }
}

위의 경우에는 "EUCJIS" 인코딩을 소개하고 있는데요. 본문의 예제로 들었던 "JIS X 0208" 인코딩은 현재 Java에서 제공되지 않으므로 직접적인 테스트를 할 수는 없었습니다. 하지만 결과는 EUCJIS도 마찬가지로 수레 '거'와 매핑되는 출력이 없습니다.

수레 '거': 3f
수레 '차': bcd6

위에서 0x3f는 '?' 물음표에 대응되는데요. 변환이 실패한 경우 나타나는 fallback 글자입니다. 닷넷의 경우에는 EUCJIS 인코딩을 제공하지 않고 "shift_jis" 인코딩을 사용하는데, 마찬가지로 수레 '거'에 대한 인코딩은 실패합니다.

Console.WriteLine(BitConverter.ToString(Encoding.GetEncoding("shift_jis").GetBytes("車")));
Console.WriteLine(BitConverter.ToString(Encoding.GetEncoding("shift_jis").GetBytes("車")));

==== 출력 결과 ====
3F
8E-D4

첨부 파일은 위의 닷넷 부분을 테스트한 코드를 포함하고 있습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 6/27/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2014-01-28 04시15분
[Lyn] 한국과 일본이 유니코드에 X을 뿌렷다 (...) 고들 하지요.

한국은 중복한자로 일본은 유령한자로
[guest]
2014-01-29 01시03분
Lyn 님, 저도 이거 보고... 표준을 만드는 것은 정말 고려할 것이 많겠구나... 하는 생각이 들었습니다. ^^
정성태
2014-03-12 09시23분
[두음법칙] 에 의한 해프닝도 있었다고 합니다.
인터넷에서 본 얘기입니다.

女 (여) : F981
女 (녀) : 5973

^^
[guest]
2014-03-13 12시10분
그렇군요. ^^ 같은 한자인데, 한글에서는 앞에 오면 '여' 글자로 변환해줘야 올바른 경우이니... 유니코드 제작자들도 어지간히 머리 아팠을 것 같습니다.
정성태

1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13486정성태12/15/20232223개발 환경 구성: 695. Nuget config 파일에 값 설정/삭제 방법
13485정성태12/15/20232103오류 유형: 883. dotnet build/restore - error : Root element is missing
13484정성태12/14/20232182개발 환경 구성: 694. Windows 디렉터리 경로를 WSL의 /mnt 포맷으로 구하는 방법
13483정성태12/14/20232324닷넷: 2184. C# - 하나의 resource 파일을 여러 프로그램에서 (AOT 시에도) 사용하는 방법파일 다운로드1
13482정성태12/13/20232944닷넷: 2183. C# - eFriend Expert OCX 예제를 .NET Core/5+ Console App에서 사용하는 방법 [2]파일 다운로드1
13481정성태12/13/20232299개발 환경 구성: 693. msbuild - .NET Core/5+ 프로젝트에서 resgen을 이용한 리소스 파일 생성 방법파일 다운로드1
13480정성태12/12/20232687개발 환경 구성: 692. Windows WSL 2 + Chrome 웹 브라우저 설치
13479정성태12/11/20232363개발 환경 구성: 691. WSL 2 (Ubuntu) + nginx 환경 설정
13477정성태12/8/20232574닷넷: 2182. C# - .NET 7부터 추가된 Int128, UInt128 [1]파일 다운로드1
13476정성태12/8/20232282닷넷: 2181. C# - .NET 8 JsonStringEnumConverter의 AOT를 위한 개선파일 다운로드1
13475정성태12/7/20232369닷넷: 2180. .NET 8 - 함수 포인터에 대한 Reflection 정보 조회파일 다운로드1
13474정성태12/6/20232206개발 환경 구성: 690. 닷넷 코어/5+ 버전의 ilasm/ildasm 실행 파일 구하는 방법 - 두 번째 이야기
13473정성태12/5/20232440닷넷: 2179. C# - 값 형식(Blittable)을 메모리 복사를 이용해 바이트 배열로 직렬화/역직렬화파일 다운로드1
13472정성태12/4/20232227C/C++: 164. Visual C++ - InterlockedCompareExchange128 사용 방법
13471정성태12/4/20232312Copilot - To enable GitHub Copilot, authorize this extension using GitHub's device flow
13470정성태12/2/20232660닷넷: 2178. C# - .NET 8부터 COM Interop에 대한 자동 소스 코드 생성 도입파일 다운로드1
13469정성태12/1/20232412닷넷: 2177. C# - (Interop DLL 없이) CoClass를 이용한 COM 개체 생성 방법파일 다운로드1
13468정성태12/1/20232314닷넷: 2176. C# - .NET Core/5+부터 달라진 RCW(Runtime Callable Wrapper) 대응 방식파일 다운로드1
13467정성태11/30/20232414오류 유형: 882. C# - Unhandled exception. System.Runtime.InteropServices.COMException (0x800080A5)파일 다운로드1
13466정성태11/29/20232587닷넷: 2175. C# - DllImport 메서드의 AOT 지원을 위한 LibraryImport 옵션
13465정성태11/28/20232336개발 환경 구성: 689. MSBuild - CopyToOutputDirectory가 "dotnet publish" 시에는 적용되지 않는 문제파일 다운로드1
13464정성태11/28/20232459닷넷: 2174. C# - .NET 7부터 UnmanagedCallersOnly 함수 export 기능을 AOT 빌드에 통합파일 다운로드1
13463정성태11/27/20232393오류 유형: 881. Visual Studio - NU1605: Warning As Error: Detected package downgrade
13462정성태11/27/20232397오류 유형: 880. Visual Studio - error CS0246: The type or namespace name '...' could not be found
13461정성태11/26/20232436닷넷: 2173. .NET Core 3/5+ 기반의 COM Server를 registry 등록 없이 사용하는 방법파일 다운로드1
13460정성태11/26/20232371닷넷: 2172. .NET 6+ 기반의 COM Server 내에 Type Library를 내장하는 방법파일 다운로드1
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...