Microsoft MVP성태의 닷넷 이야기
.NET Framework: 411. 유니코드의 "compatibility character"가 뭘까요? [링크 복사], [링크+제목 복사],
조회: 18609
글쓴 사람
정성태 (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)
13562정성태2/21/20241983오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20242063닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20242094디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242944오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242179닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241921Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241973Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242116닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241861VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241944닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241896닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242092닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242208Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242507개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242336개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242086개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241952Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241861닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241885오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241882Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241913오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241974VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242081Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242365개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242419닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242517닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...