SlideShare a Scribd company logo
1 of 42
Download to read offline
제목에 ‘재미있는’이 붙은 Unicode
2014.3.20 @KASA
송찬호
Unicode 란?
- 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다
룰 수 있도록 설계된 산업 표준
- ISO 10646 문자 집합, 문자 인코딩, 문자 정보 데이터 테이
블, 문자들을 다루기 위한 알고리즘 등을 포함하고 있다.
Unicode 역사
1991년 8월: 유니코드 1.0.0 ― 유니코드의 시작
1992년 6월: 유니코드 1.0.1 ― 2만자가 넘는 한자가 포함되었다.
1993년 6월: 유니코드 1.1.0 ― 조합형 한글을 위한 첫가끝 코드가 포함되었다.
1995년 6월: 유니코드 1.1.5
1996년 6월: 유니코드 2.0.0 ― 11172자의 모든 현대 한글이 포함되었다.
1998년 5월: 유니코드 2.1.2
1998년 8월: 유니코드 2.1.5
1998년 12월: 유니코드 2.1.8
1999년 4월: 유니코드 2.1.9
1999년 9월: 유니코드 3.0.0
2000년 8월: 유니코드 3.0.1
2001년 3월: 유니코드 3.1.0 ― 보조 평면에 처음으로 문자들이 포함되었다.
2001년 8월: 유니코드 3.1.1
2002년 3월: 유니코드 3.2.0
2003년 4월: 유니코드 4.0.0
2004년 3월: 유니코드 4.0.1
2005년 3월 31일: 유니코드 4.1
2006년 6월 14일: 유니코드 5.0 (문자 데이터베이스는7월 18일에 발표되었으나책은 11월 9일 출시)
2008년 4월 4일: 유니코드 5.1
2009년 10월 1일: 유니코드 5.2 ― 확장 첫가끝 코드가 포함되었다.
2010년 10월 11일: 유니코드 6.0
2012년 2월 1일: 유니코드 6.1
2012년 9월 27일: 유니코드 6.2
2013년 9월 30일: 유니코드 6.3
ISO 10646 문자 집합
ISO-10646
- 4바이트로 한 문자를 나타냄
- 일반적인 문자 처리가 가능한 문자 집합과 그 부호화를 정
의
ISO-10646의 Canonical form
- 각 문자는 문자들끼리 서로 구분되기 위해 4 옥텟의 16진
수 이름을 갖음
Canonical form의 BMP(Basic Multilingual Plane)
- 그룹 00, 평면 00인 부분
- 현재 ISO-10646에서 문자가 실제로 할당된 부분
Canonical form과 UCS(Universal Character Set)
UCS-4
- Canonical form을 그대로 32-bit 부호화
UCS-2
- BMP를 그대로 16-bit 부호화
문자 인코딩
UCS Transformation format (UTF)
- 4-Octet의 ISO-10646을 현재 컴퓨팅 환경에서 적절히 처
리하기 위한 표현 방법
** 현재 환경은 한 글자를 한 바이트로 가정
C 표준 문자열 함수(strcmp, sprintf 등)
ISO-2022 등 여러 표준
UTF-1
- ISO-2022에서 사용을 금하고 있는 C0, SPACE, DEL, C1
문자들을 사용하지 않도록 부호화
- ISO/IEC-10646:1993의 Annex G로 포함
UTF-7
- 인터넷 메일과 같은 7 비트 ASCII 문자 전송을 원칙으로 하
는 환경에서 사용
- US-ASCII에 해당하는 글자들은 변환을 해도 사람이 읽을
수 있도록 고안
- RFC-1642로 등록
UTF-8(FSS-UTF - File System Safe UCS Transformation Format)
- ANSI 기반의 기존 시스템에서 UCS을 문자열 표현할 때 문
자열 중간에 0x00 바이트가 등장하는 경우, 해당 바이트가
NULL (0) 문자로 처리되어 문자열이 잘리는 문제 해결
* C를 비롯한 많은 시스템에서 NULL (0) 문자는 문자열의 끝을 의미
- RFC-1642로 등록
UTF-8 구조
코드 범위
(십육진법)
UTF-16BE
(이진법)
UTF-8
(이진법) 설명
000000-
00007F
00000000 0xxxxxxx 0xxxxxxx ASCII와 동일한 범위
000080-
0007FF
00000xxx xxxxxxxx 110xxxxx 10xxxxxx
첫 바이트는 110 또는 1110으로
000800-
00FFFF
xxxxxxxx xxxxxxxx 1110xxxx 10xxxxxx 10xxxxxx 시작하고, 나머지 바이트들은 10
으로 시작함
010000-
10FFFF
110110yy yyxxxxxx 110111xx xxxxxxxx 11110zzz 10zzxxxx 10xxxxxx 10xxxxxx UTF-16 서러게이트 쌍 영역
(yyyy = zzzzz - 1). UTF-8로 표시
된 비트 패턴은 실제 코드 포인트
와 동일하다.
UTF-8 설계 원칙
- 1바이트로 표시된 문자의 최상위 비트는 항상 0
- 2바이트 이상으로 표시된 문자의 경우, 첫 바이트의 상위
비트들이 그 문자를 표시하는 데 필요한 바이트 수를 결정
2바이트는 110으로 시작
3바이트는 1110으로 시작
- 첫 바이트가 아닌 나머지 바이트들은 상위 2비트가 항상
10
UTF-8 장점
- ASCII 인코딩은 UTF-8의 부분 집합이다. 일반적인 ASCII 문자열은 올바른 UTF-8 문자열이며, 따라
서 하위 호환성이 보장된다.
- UTF-8 문자열은 바이트 단위로 정렬을 수행하는 알고리즘으로도 코드 포인트 단위로 올바르게 정렬
할 수 있다. (일반적인 목적으로는 재정렬이 필요하다)
- UTF-8과 UTF-16은 XML 문서의 표준 인코딩으로, 다른 인코딩들을 사용하려면 외부에서, 또는 문서
안에서 명시적으로 인코딩을 정해야 한다.
- 다른 인코딩과의 왕복 변환이 간단하다.
- 바이트 단위 문자열 검색 알고리즘들을 그대로 사용할 수 있다.
- 간단한 알고리즘을 통하여 UTF-8 문자열임을 확인할 수 있다. 즉, 다른 인코딩에서 나타나는 바이트
들이 올바른 UTF-8 문자열일 가능성은 낮다.
- U+0000을 표현할 때를 제외하면, 널 문자는 UTF-8 문자열 안에 나타나지 않는다. 따라서 널 문자로
끝나는 문자열을 사용하는 C 언어의 문자열 함수(strncpy() 같은)를 그대로 사용할 수 있다
UTF-8 단점
- 나쁘게 만들어진(그리고 현재 표준을 따르지 않는) UTF-8 파서는 서로 다른 가짜 UTF-8 표현(예를 들어서 너무 긴 형
식)을 같은 유니코드 문자열로 해석할 수 있다.
- 대부분의 UTF-8 문자열은 일반적으로 적당한 기존 인코딩으로 표현한 문자열보다 더 크다. 판독 기호를 사용하는 대부
분의 라틴 알파벳 문자는 적어도 2바이트를 사용하며, 한중일 문자들과 표의 문자들은 적어도 3바이트를 사용한다.
- 한중일 문자들과 표의 문자를 제외한 거의 모든 기존 인코딩들은 한 문자에 1바이트를 사용하므로 문자열 처리가 간편
한 반면, UTF-8은 그렇지 않다.
- UTF-8은 가변 길이 인코딩이며, 다른 문자는 다른 바이트 수로 표현될 수 있다. 사실 이 문제는 별로 심각한 것이 아니
며, UTF-8 문자열을 다루기 위한 추상적인 인터페이스를 만드는 것으로 해결될 수 있다. 실제로 기술적으로는 UTF-16도
BMP 바깥 문자를 4바이트로 표현하기 때문에 가변 길이 인코딩이다.
- BMP에 들어 있는 한중일 문자들은 UTF-8에서 3바이트로 표현되지만, UTF-16에서는 2바이트로 표현된다. 따라서
UTF-8에서는 이러한 문자를 표현하기 위하여 더 많은 바이트가 필요하며 UTF-16과 비교할 때 최대 50%까지 크기가 늘
수 있다. 하지만 반대로 U+0000부터 U+007F 사이의 글자들은 UTF-16에서 크기가 두 배로 늘기 때문에 실질적으로는
큰 문제가 없을 수도 있다.
UTF-16(16-bit Unicode Transformation Format)
- BMP속하는 문자들은 그대로 16-bit 부호화
- 그 외의 문자는 서러게이트(surrogate) 문자를
이용 32-bit 부호화
- 엔디언 이슈가 생김
UTF-16BE / UTF-16LE
UTF-16-문자
Bit
|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|y y y y y y y y|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UTF-16BE-코드
첫 번째 Byte 두 번째 Byte
|7 0| |7 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|y y y y y y y y| |x x x x x x x x|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
UTF-16LE-코드
첫째 Byte 두 번째 Byte
|7 0| |7 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|x x x x x x x x| |y y y y y y y y|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
UTF-16 서러게이트(Surrogate)
- 16-bit로 값을 표현할 수 없는 문자들은 서러게
이트(Surrogate) 문자 영역에 해당하는 두 개의
16비트 문자로 변환되어 이 한 쌍(즉 32비트)이
그 문자를 표현
UTF-16 서러게이트(Surrogate) 부호화
Bit
31 24|23 16|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 z z z z z|x x x x x x y y|y y y y y y y y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Low-Surrogate (U+DC00 ... U+DFFF)
|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 1 y y|y y y y y y y y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
High-Surrogate (U+D800 ... U+DBFF)
|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 0 Z Z|Z Z x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UTF-16 표현 범위
16-bit
- U+0000~U+FFFF
32-bit
- zzzz = 0001~100002진수 = U+01xxxx~U+10xxxx
U+000000~U+10FFFF
UTF-16인코딩 가능한 범위
Bit
31 24|23 16|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 z z z z z|x x x x x x y y|y y y y y y y y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Low-Surrogate (U+DC00 ... U+DFFF)
|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 1 y y|y y y y y y y y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
High-Surrogate (U+D800 ... U+DBFF)
|15 8|7 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 0 Z Z|Z Z x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
바이트 순서 표식 - BOM (Byte Order Mark)
- 엔디안을 구별하기 위해 사용하는 문자
Character Code U+FEFF
Encoding Representation
UTF-8 EF BB BF
UTF-16LE FE FF
UTF-16BE FF FE
UTF-32LE 00 00 FE FF
UTF-32BE FF FE 00 00
** UTF-8에는 엔디안 문제가 일어나지 않으므로 BOM을 붙여야 할 필요는 없지
만, 해당 자료가 UTF-8 인코딩이라는 표식으로 사용하는 경우도 있다.
BOM 이슈
- 윈도의 많은 문서 편집기는 UTF-8로 저장할 경우 자동으로 BOM을 추가, 유
닉스 계열의 문서 편집기는 BOM을 사용하지 않음
- PHP 인터프리터에서는 BOM을 인식하지 못하고 일반 문자열로 처리하는
데, BOM이 있는 PHP 문서는 HTTP 헤더를 출력하는 과정에서 BOM이 먼저
출력되어 헤더 출력에 실패하고 경고를 출력
문자 정보 데이터 테이블
Unicode 문자 정보 목록
유니코드 목록 (범위)
기본 다국어 평면
BMP
보조 다국어 평면
SMP
보조 상형 문자 평면
SIP
3차 상형 문자 평면
TIP
보조 특수 목적 평면
SSP
사용자 영역 평면
S PUA A/B
0000~0FFF
1000~1FFF
2000~2FFF
3000~3FFF
4000~4FFF
5000~5FFF
6000~6FFF
7000~7FFF
8000~8FFF
9000~9FFF
A000~AFFF
B000~BFFF
C000~CFFF
D000~DFFF
E000~EFFF
F000~FFFF
10000~10FFF
11000~11FFF
12000~12FFF
13000~13FFF
14000~14FFF
15000~15FFF
16000~16FFF
17000~17FFF
18000~18FFF
19000~19FFF
1A000~1AFFF
1B000~1BFFF
1C000~1CFFF
1D000~1DFFF
1E000~1EFFF
1F000~1FFFF
20000~20FFF
21000~21FFF
22000~22FFF
23000~23FFF
24000~24FFF
25000~25FFF
26000~26FFF
27000~27FFF
28000~28FFF
29000~29FFF
2A000~2AFFF
2B000~2BFFF
2C000~2CFFF
2D000~2DFFF
2E000~2EFFF
2F000~2FFFF
문자 없음 E0000~E0FFF
15: PUA-A
F0000-FFFFF
16: PUA-B
100000-10FFFF
BMP(기본 다국어 평면) 구성
보조 다국어 평면 - Supplementary Multilingual Plane, SMP
- 옛 문자나 음악 기호, 수학 기호 등에 쓰인다.
보조 상형 문자 평면 - Supplementary Ideographic Plane, SIP
- 초기 유니코드에 포함되지 않은 한중일 통합 한자를 주로 담고 있다.
3차 상형 문자 평면 - Tertiary Ideographic Plane, TIP
은 갑골 문자, 금문, 소전 따위의 문자나 추가 한중일 통합 한자, 기타 옛 상형 문자 등을 위해 예약된 영역이다.
- 2014년 현재 3번 평면에는 아무 문자도 지정되지 않았다.
미지정 평면
- 유니코드 4번 평면부터 13번 평면에는 2014년 현재 아무 문자나 기호도 지정되지 않았다.
보조 특수 목적 평면 - Supplementary Special-purpose Plane, SSP
- 2014년 현재 적은 수의 제어용 문자들이 들어 있다.
사용자 영역 평면 - Supplementary Private Use Area, S PUA A/B
15번과 16번 두 평면은 사용자 영역으로, 특정 업체나 사용자 별로 할당하여 사용
- 소프트웨어간이나 글꼴간의 호환성이 보장되지 않는다.
그외의 평면
Unicode Character Table
http://unicode-table.com/en/
Character 와 Glyph
Character
- 의미가 부여된 기호
Glyph
- 기호의 표현 양식
Capital A
Character
A A A A A
Glyph
Homoglyph
- 쉽게 구분할 수 없는 글자나 자체
키릴 문자와 로마자
- А В C E І Ј К М Н О Р С Т Ү Ғ Ѵ Х Ԝ
- A B C E I J K M H O P C Y F V X W
인터넷 URL
- 예를 들어 cqw.com 이라는 사이트가 있다고 할 때, c를 키릴 문자인 с로 대체하여 сqw.com이 된다.
이것은 퓨니코드로 나온다. 이것을 치면 전혀 다른 xn--qw-xjg.com이 된다.
두 개 이상의 글자와 다른 수의 글자 또는 다른 글자
- rri,rn,nn은 m과 같이 보이기도 한다. 그리고 ci는 a, cl은 d, lc는 k, vv는 w처럼 보이기도 한다.
기타
- 가운뎃점 (·)은 ㆍ(아래아)와 반각 전각 여부를 제외하면 거의 같다.
- 논리합을 나타내는 글자 ∨는 V와 전각 반각 여부를 제외하면 거의 같다.
- 글자 ┽는 +와 전각 반각 여부도 같다.
- 글자 ∫는 Ʃ이 대문자인 글자 ʃ이나 ſ와 거의 같다.
- 그리스 문자 ς는 로마자 Ç와 거의 같다. (정확히는 이 글자의 소문자와 더 비슷하다.)
- 로마자 Ḑ는 로마자 Ḍ와 거의 같다.
Glyph와 Font
Font
- Glyph의 집합
Unicode Whitespace 1/4
Code point Name Script General category Remark
U+0009 Common Other, control HT, Horizontal Tab
U+000A Common Other, control LF, Line feed
U+000B Common Other, control VT, Vertical Tab
U+000C Common Other, control FF, Form feed
U+000D Common Other, control CR, Carriage return
U+0020 SPACE Common Separator, space
U+0085 Common Other, control NEL, Next line
Unicode Whitespace 2/4
Code point Name Script General category Remark
U+00A0 NO-BREAK SPACE Common Separator, space
U+1680 OGHAM SPACE MARK Ogham Separator, space
U+2000 EN QUAD Common Separator, space
U+2001 EM QUAD Common Separator, space
U+2002 EN SPACE Common Separator, space
U+2003 EM SPACE Common Separator, space
U+2004 THREE-PER-EM SPACE Common Separator, space
Unicode Whitespace 3/4
Code point Name Script General category Remark
U+2005 FOUR-PER-EM SPACE Common Separator, space
U+2006 SIX-PER-EM SPACE Common Separator, space
U+2007 FIGURE SPACE Common Separator, space
U+2008 PUNCTUATION SPACE Common Separator, space
U+2009 THIN SPACE Common Separator, space
U+200A HAIR SPACE Common Separator, space
U+2028 LINE SEPARATOR Common Separator, line
Unicode Whitespace 4/4
Code point Name Script General category Remark
U+2029 PARAGRAPH SEPARATOR Common Separator, paragraph
U+202F NARROW NO-BREAK SPACE Common Separator, space
U+205F MEDIUM MATHEMATICAL SPACE Common Separator, space
U+3000 IDEOGRAPHIC SPACE Common Separator, space
문자들을 다루기 위한 알고리즘
Unicode algorithm
Bi-directional text
Unicode collation algorithm
Unicode equivalence
Bi-directional text
- 문화권 별 텍스트의 방향이 다름
left to right 라틴 계열 등
right to left 아랍, 히브리어 계열 등
- 방향이 다른 텍스트 각각 및 섞어 사용하는 경우 어떻게 표
시하는지에 대한 방법을 정의 (강, 약, 중립, 명시적으로 구
분)
제어코드 - U+200E LRM, U+200F RLM, U+061C ALM
숫자, 기호, 등
공백 문자, Tab, 등
명시적 코드 - U+202A LRE, U+202D LRO, U+202B RLE, … etc
Unicode collation algorithm
- 두 문자열을 대조 혹은 정렬을 하기 위한 방법을 정의
수치 및 시간
언어별 문자 순서
부수와 획 순서
- Collation Chart
- ISO-14651 문자열 비교를 위한 국제 표준
Unicode equivalence
- 같은 기호를 사용하지만 다른 언어권에 있는 경우 구분하
여 별도의 코드를 부여
- 한글 처럼 Alphabet 조합 방식의 경우, 각 Alphabet의 조
합 및 분해를 정의하여 비교 가능케 함
NFC character A m é l i e
NFC code point 0041 006d 00e9 006c 0069 0065
NFD code point 0041 006d 0065 0301 006c 0069 0065
NFD character A m e ◌́ l i e
Reference

More Related Content

Similar to Unicode @KASA

Character Encoding in python
Character Encoding in pythonCharacter Encoding in python
Character Encoding in pythondaesung7kang
 
델파이와 유니코드
델파이와 유니코드델파이와 유니코드
델파이와 유니코드Devgear
 
Windosw via c 스터디2장
Windosw via c 스터디2장Windosw via c 스터디2장
Windosw via c 스터디2장HolyTak
 
문자열이란 무엇인가
문자열이란 무엇인가문자열이란 무엇인가
문자열이란 무엇인가Seungyong Lee
 

Similar to Unicode @KASA (7)

Character Encoding in python
Character Encoding in pythonCharacter Encoding in python
Character Encoding in python
 
문자열 이상재
문자열 이상재문자열 이상재
문자열 이상재
 
Unicode
UnicodeUnicode
Unicode
 
델파이와 유니코드
델파이와 유니코드델파이와 유니코드
델파이와 유니코드
 
Windosw via c 스터디2장
Windosw via c 스터디2장Windosw via c 스터디2장
Windosw via c 스터디2장
 
문자열이란 무엇인가
문자열이란 무엇인가문자열이란 무엇인가
문자열이란 무엇인가
 
문자코드
문자코드문자코드
문자코드
 

More from Chanho Song

스마트폰 해킹과 대응 @KGC2013
스마트폰 해킹과 대응 @KGC2013스마트폰 해킹과 대응 @KGC2013
스마트폰 해킹과 대응 @KGC2013Chanho Song
 
스마트폰 해킹과 대응 @KASA
스마트폰 해킹과 대응 @KASA스마트폰 해킹과 대응 @KASA
스마트폰 해킹과 대응 @KASAChanho Song
 
Html5+js with game engine cocos2d-html5 분석 @KGC2012
Html5+js with game engine   cocos2d-html5 분석 @KGC2012Html5+js with game engine   cocos2d-html5 분석 @KGC2012
Html5+js with game engine cocos2d-html5 분석 @KGC2012Chanho Song
 
No silver bullet @KASA open seminar
No silver bullet @KASA open seminarNo silver bullet @KASA open seminar
No silver bullet @KASA open seminarChanho Song
 
No silver bullet
No silver bulletNo silver bullet
No silver bulletChanho Song
 
No silver bullet
No silver bulletNo silver bullet
No silver bulletChanho Song
 
No silver bullet
No silver bulletNo silver bullet
No silver bulletChanho Song
 
No silver bullet
No silver bulletNo silver bullet
No silver bulletChanho Song
 

More from Chanho Song (8)

스마트폰 해킹과 대응 @KGC2013
스마트폰 해킹과 대응 @KGC2013스마트폰 해킹과 대응 @KGC2013
스마트폰 해킹과 대응 @KGC2013
 
스마트폰 해킹과 대응 @KASA
스마트폰 해킹과 대응 @KASA스마트폰 해킹과 대응 @KASA
스마트폰 해킹과 대응 @KASA
 
Html5+js with game engine cocos2d-html5 분석 @KGC2012
Html5+js with game engine   cocos2d-html5 분석 @KGC2012Html5+js with game engine   cocos2d-html5 분석 @KGC2012
Html5+js with game engine cocos2d-html5 분석 @KGC2012
 
No silver bullet @KASA open seminar
No silver bullet @KASA open seminarNo silver bullet @KASA open seminar
No silver bullet @KASA open seminar
 
No silver bullet
No silver bulletNo silver bullet
No silver bullet
 
No silver bullet
No silver bulletNo silver bullet
No silver bullet
 
No silver bullet
No silver bulletNo silver bullet
No silver bullet
 
No silver bullet
No silver bulletNo silver bullet
No silver bullet
 

Unicode @KASA

  • 1. 제목에 ‘재미있는’이 붙은 Unicode 2014.3.20 @KASA 송찬호
  • 2. Unicode 란? - 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다 룰 수 있도록 설계된 산업 표준 - ISO 10646 문자 집합, 문자 인코딩, 문자 정보 데이터 테이 블, 문자들을 다루기 위한 알고리즘 등을 포함하고 있다.
  • 3. Unicode 역사 1991년 8월: 유니코드 1.0.0 ― 유니코드의 시작 1992년 6월: 유니코드 1.0.1 ― 2만자가 넘는 한자가 포함되었다. 1993년 6월: 유니코드 1.1.0 ― 조합형 한글을 위한 첫가끝 코드가 포함되었다. 1995년 6월: 유니코드 1.1.5 1996년 6월: 유니코드 2.0.0 ― 11172자의 모든 현대 한글이 포함되었다. 1998년 5월: 유니코드 2.1.2 1998년 8월: 유니코드 2.1.5 1998년 12월: 유니코드 2.1.8 1999년 4월: 유니코드 2.1.9 1999년 9월: 유니코드 3.0.0 2000년 8월: 유니코드 3.0.1 2001년 3월: 유니코드 3.1.0 ― 보조 평면에 처음으로 문자들이 포함되었다. 2001년 8월: 유니코드 3.1.1 2002년 3월: 유니코드 3.2.0 2003년 4월: 유니코드 4.0.0 2004년 3월: 유니코드 4.0.1 2005년 3월 31일: 유니코드 4.1 2006년 6월 14일: 유니코드 5.0 (문자 데이터베이스는7월 18일에 발표되었으나책은 11월 9일 출시) 2008년 4월 4일: 유니코드 5.1 2009년 10월 1일: 유니코드 5.2 ― 확장 첫가끝 코드가 포함되었다. 2010년 10월 11일: 유니코드 6.0 2012년 2월 1일: 유니코드 6.1 2012년 9월 27일: 유니코드 6.2 2013년 9월 30일: 유니코드 6.3
  • 5. ISO-10646 - 4바이트로 한 문자를 나타냄 - 일반적인 문자 처리가 가능한 문자 집합과 그 부호화를 정 의
  • 6. ISO-10646의 Canonical form - 각 문자는 문자들끼리 서로 구분되기 위해 4 옥텟의 16진 수 이름을 갖음
  • 7. Canonical form의 BMP(Basic Multilingual Plane) - 그룹 00, 평면 00인 부분 - 현재 ISO-10646에서 문자가 실제로 할당된 부분
  • 8. Canonical form과 UCS(Universal Character Set) UCS-4 - Canonical form을 그대로 32-bit 부호화 UCS-2 - BMP를 그대로 16-bit 부호화
  • 10. UCS Transformation format (UTF) - 4-Octet의 ISO-10646을 현재 컴퓨팅 환경에서 적절히 처 리하기 위한 표현 방법 ** 현재 환경은 한 글자를 한 바이트로 가정 C 표준 문자열 함수(strcmp, sprintf 등) ISO-2022 등 여러 표준
  • 11. UTF-1 - ISO-2022에서 사용을 금하고 있는 C0, SPACE, DEL, C1 문자들을 사용하지 않도록 부호화 - ISO/IEC-10646:1993의 Annex G로 포함
  • 12. UTF-7 - 인터넷 메일과 같은 7 비트 ASCII 문자 전송을 원칙으로 하 는 환경에서 사용 - US-ASCII에 해당하는 글자들은 변환을 해도 사람이 읽을 수 있도록 고안 - RFC-1642로 등록
  • 13. UTF-8(FSS-UTF - File System Safe UCS Transformation Format) - ANSI 기반의 기존 시스템에서 UCS을 문자열 표현할 때 문 자열 중간에 0x00 바이트가 등장하는 경우, 해당 바이트가 NULL (0) 문자로 처리되어 문자열이 잘리는 문제 해결 * C를 비롯한 많은 시스템에서 NULL (0) 문자는 문자열의 끝을 의미 - RFC-1642로 등록
  • 14. UTF-8 구조 코드 범위 (십육진법) UTF-16BE (이진법) UTF-8 (이진법) 설명 000000- 00007F 00000000 0xxxxxxx 0xxxxxxx ASCII와 동일한 범위 000080- 0007FF 00000xxx xxxxxxxx 110xxxxx 10xxxxxx 첫 바이트는 110 또는 1110으로 000800- 00FFFF xxxxxxxx xxxxxxxx 1110xxxx 10xxxxxx 10xxxxxx 시작하고, 나머지 바이트들은 10 으로 시작함 010000- 10FFFF 110110yy yyxxxxxx 110111xx xxxxxxxx 11110zzz 10zzxxxx 10xxxxxx 10xxxxxx UTF-16 서러게이트 쌍 영역 (yyyy = zzzzz - 1). UTF-8로 표시 된 비트 패턴은 실제 코드 포인트 와 동일하다.
  • 15. UTF-8 설계 원칙 - 1바이트로 표시된 문자의 최상위 비트는 항상 0 - 2바이트 이상으로 표시된 문자의 경우, 첫 바이트의 상위 비트들이 그 문자를 표시하는 데 필요한 바이트 수를 결정 2바이트는 110으로 시작 3바이트는 1110으로 시작 - 첫 바이트가 아닌 나머지 바이트들은 상위 2비트가 항상 10
  • 16. UTF-8 장점 - ASCII 인코딩은 UTF-8의 부분 집합이다. 일반적인 ASCII 문자열은 올바른 UTF-8 문자열이며, 따라 서 하위 호환성이 보장된다. - UTF-8 문자열은 바이트 단위로 정렬을 수행하는 알고리즘으로도 코드 포인트 단위로 올바르게 정렬 할 수 있다. (일반적인 목적으로는 재정렬이 필요하다) - UTF-8과 UTF-16은 XML 문서의 표준 인코딩으로, 다른 인코딩들을 사용하려면 외부에서, 또는 문서 안에서 명시적으로 인코딩을 정해야 한다. - 다른 인코딩과의 왕복 변환이 간단하다. - 바이트 단위 문자열 검색 알고리즘들을 그대로 사용할 수 있다. - 간단한 알고리즘을 통하여 UTF-8 문자열임을 확인할 수 있다. 즉, 다른 인코딩에서 나타나는 바이트 들이 올바른 UTF-8 문자열일 가능성은 낮다. - U+0000을 표현할 때를 제외하면, 널 문자는 UTF-8 문자열 안에 나타나지 않는다. 따라서 널 문자로 끝나는 문자열을 사용하는 C 언어의 문자열 함수(strncpy() 같은)를 그대로 사용할 수 있다
  • 17. UTF-8 단점 - 나쁘게 만들어진(그리고 현재 표준을 따르지 않는) UTF-8 파서는 서로 다른 가짜 UTF-8 표현(예를 들어서 너무 긴 형 식)을 같은 유니코드 문자열로 해석할 수 있다. - 대부분의 UTF-8 문자열은 일반적으로 적당한 기존 인코딩으로 표현한 문자열보다 더 크다. 판독 기호를 사용하는 대부 분의 라틴 알파벳 문자는 적어도 2바이트를 사용하며, 한중일 문자들과 표의 문자들은 적어도 3바이트를 사용한다. - 한중일 문자들과 표의 문자를 제외한 거의 모든 기존 인코딩들은 한 문자에 1바이트를 사용하므로 문자열 처리가 간편 한 반면, UTF-8은 그렇지 않다. - UTF-8은 가변 길이 인코딩이며, 다른 문자는 다른 바이트 수로 표현될 수 있다. 사실 이 문제는 별로 심각한 것이 아니 며, UTF-8 문자열을 다루기 위한 추상적인 인터페이스를 만드는 것으로 해결될 수 있다. 실제로 기술적으로는 UTF-16도 BMP 바깥 문자를 4바이트로 표현하기 때문에 가변 길이 인코딩이다. - BMP에 들어 있는 한중일 문자들은 UTF-8에서 3바이트로 표현되지만, UTF-16에서는 2바이트로 표현된다. 따라서 UTF-8에서는 이러한 문자를 표현하기 위하여 더 많은 바이트가 필요하며 UTF-16과 비교할 때 최대 50%까지 크기가 늘 수 있다. 하지만 반대로 U+0000부터 U+007F 사이의 글자들은 UTF-16에서 크기가 두 배로 늘기 때문에 실질적으로는 큰 문제가 없을 수도 있다.
  • 18. UTF-16(16-bit Unicode Transformation Format) - BMP속하는 문자들은 그대로 16-bit 부호화 - 그 외의 문자는 서러게이트(surrogate) 문자를 이용 32-bit 부호화 - 엔디언 이슈가 생김
  • 19. UTF-16BE / UTF-16LE UTF-16-문자 Bit |15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |y y y y y y y y|x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UTF-16BE-코드 첫 번째 Byte 두 번째 Byte |7 0| |7 0| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |y y y y y y y y| |x x x x x x x x| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ UTF-16LE-코드 첫째 Byte 두 번째 Byte |7 0| |7 0| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |x x x x x x x x| |y y y y y y y y| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
  • 20. UTF-16 서러게이트(Surrogate) - 16-bit로 값을 표현할 수 없는 문자들은 서러게 이트(Surrogate) 문자 영역에 해당하는 두 개의 16비트 문자로 변환되어 이 한 쌍(즉 32비트)이 그 문자를 표현
  • 21. UTF-16 서러게이트(Surrogate) 부호화 Bit 31 24|23 16|15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|0 0 0 z z z z z|x x x x x x y y|y y y y y y y y| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Low-Surrogate (U+DC00 ... U+DFFF) |15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 1 1 y y|y y y y y y y y| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ High-Surrogate (U+D800 ... U+DBFF) |15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 1 0 Z Z|Z Z x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 22. UTF-16 표현 범위 16-bit - U+0000~U+FFFF 32-bit - zzzz = 0001~100002진수 = U+01xxxx~U+10xxxx U+000000~U+10FFFF
  • 23. UTF-16인코딩 가능한 범위 Bit 31 24|23 16|15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0|0 0 0 z z z z z|x x x x x x y y|y y y y y y y y| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Low-Surrogate (U+DC00 ... U+DFFF) |15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 1 1 y y|y y y y y y y y| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ High-Surrogate (U+D800 ... U+DBFF) |15 8|7 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 1 0 Z Z|Z Z x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 24. 바이트 순서 표식 - BOM (Byte Order Mark) - 엔디안을 구별하기 위해 사용하는 문자 Character Code U+FEFF Encoding Representation UTF-8 EF BB BF UTF-16LE FE FF UTF-16BE FF FE UTF-32LE 00 00 FE FF UTF-32BE FF FE 00 00 ** UTF-8에는 엔디안 문제가 일어나지 않으므로 BOM을 붙여야 할 필요는 없지 만, 해당 자료가 UTF-8 인코딩이라는 표식으로 사용하는 경우도 있다. BOM 이슈 - 윈도의 많은 문서 편집기는 UTF-8로 저장할 경우 자동으로 BOM을 추가, 유 닉스 계열의 문서 편집기는 BOM을 사용하지 않음 - PHP 인터프리터에서는 BOM을 인식하지 못하고 일반 문자열로 처리하는 데, BOM이 있는 PHP 문서는 HTTP 헤더를 출력하는 과정에서 BOM이 먼저 출력되어 헤더 출력에 실패하고 경고를 출력
  • 26. Unicode 문자 정보 목록 유니코드 목록 (범위) 기본 다국어 평면 BMP 보조 다국어 평면 SMP 보조 상형 문자 평면 SIP 3차 상형 문자 평면 TIP 보조 특수 목적 평면 SSP 사용자 영역 평면 S PUA A/B 0000~0FFF 1000~1FFF 2000~2FFF 3000~3FFF 4000~4FFF 5000~5FFF 6000~6FFF 7000~7FFF 8000~8FFF 9000~9FFF A000~AFFF B000~BFFF C000~CFFF D000~DFFF E000~EFFF F000~FFFF 10000~10FFF 11000~11FFF 12000~12FFF 13000~13FFF 14000~14FFF 15000~15FFF 16000~16FFF 17000~17FFF 18000~18FFF 19000~19FFF 1A000~1AFFF 1B000~1BFFF 1C000~1CFFF 1D000~1DFFF 1E000~1EFFF 1F000~1FFFF 20000~20FFF 21000~21FFF 22000~22FFF 23000~23FFF 24000~24FFF 25000~25FFF 26000~26FFF 27000~27FFF 28000~28FFF 29000~29FFF 2A000~2AFFF 2B000~2BFFF 2C000~2CFFF 2D000~2DFFF 2E000~2EFFF 2F000~2FFFF 문자 없음 E0000~E0FFF 15: PUA-A F0000-FFFFF 16: PUA-B 100000-10FFFF
  • 28. 보조 다국어 평면 - Supplementary Multilingual Plane, SMP - 옛 문자나 음악 기호, 수학 기호 등에 쓰인다. 보조 상형 문자 평면 - Supplementary Ideographic Plane, SIP - 초기 유니코드에 포함되지 않은 한중일 통합 한자를 주로 담고 있다. 3차 상형 문자 평면 - Tertiary Ideographic Plane, TIP 은 갑골 문자, 금문, 소전 따위의 문자나 추가 한중일 통합 한자, 기타 옛 상형 문자 등을 위해 예약된 영역이다. - 2014년 현재 3번 평면에는 아무 문자도 지정되지 않았다. 미지정 평면 - 유니코드 4번 평면부터 13번 평면에는 2014년 현재 아무 문자나 기호도 지정되지 않았다. 보조 특수 목적 평면 - Supplementary Special-purpose Plane, SSP - 2014년 현재 적은 수의 제어용 문자들이 들어 있다. 사용자 영역 평면 - Supplementary Private Use Area, S PUA A/B 15번과 16번 두 평면은 사용자 영역으로, 특정 업체나 사용자 별로 할당하여 사용 - 소프트웨어간이나 글꼴간의 호환성이 보장되지 않는다. 그외의 평면
  • 30. Character 와 Glyph Character - 의미가 부여된 기호 Glyph - 기호의 표현 양식 Capital A Character A A A A A Glyph
  • 31. Homoglyph - 쉽게 구분할 수 없는 글자나 자체 키릴 문자와 로마자 - А В C E І Ј К М Н О Р С Т Ү Ғ Ѵ Х Ԝ - A B C E I J K M H O P C Y F V X W 인터넷 URL - 예를 들어 cqw.com 이라는 사이트가 있다고 할 때, c를 키릴 문자인 с로 대체하여 сqw.com이 된다. 이것은 퓨니코드로 나온다. 이것을 치면 전혀 다른 xn--qw-xjg.com이 된다. 두 개 이상의 글자와 다른 수의 글자 또는 다른 글자 - rri,rn,nn은 m과 같이 보이기도 한다. 그리고 ci는 a, cl은 d, lc는 k, vv는 w처럼 보이기도 한다. 기타 - 가운뎃점 (·)은 ㆍ(아래아)와 반각 전각 여부를 제외하면 거의 같다. - 논리합을 나타내는 글자 ∨는 V와 전각 반각 여부를 제외하면 거의 같다. - 글자 ┽는 +와 전각 반각 여부도 같다. - 글자 ∫는 Ʃ이 대문자인 글자 ʃ이나 ſ와 거의 같다. - 그리스 문자 ς는 로마자 Ç와 거의 같다. (정확히는 이 글자의 소문자와 더 비슷하다.) - 로마자 Ḑ는 로마자 Ḍ와 거의 같다.
  • 33. Unicode Whitespace 1/4 Code point Name Script General category Remark U+0009 Common Other, control HT, Horizontal Tab U+000A Common Other, control LF, Line feed U+000B Common Other, control VT, Vertical Tab U+000C Common Other, control FF, Form feed U+000D Common Other, control CR, Carriage return U+0020 SPACE Common Separator, space U+0085 Common Other, control NEL, Next line
  • 34. Unicode Whitespace 2/4 Code point Name Script General category Remark U+00A0 NO-BREAK SPACE Common Separator, space U+1680 OGHAM SPACE MARK Ogham Separator, space U+2000 EN QUAD Common Separator, space U+2001 EM QUAD Common Separator, space U+2002 EN SPACE Common Separator, space U+2003 EM SPACE Common Separator, space U+2004 THREE-PER-EM SPACE Common Separator, space
  • 35. Unicode Whitespace 3/4 Code point Name Script General category Remark U+2005 FOUR-PER-EM SPACE Common Separator, space U+2006 SIX-PER-EM SPACE Common Separator, space U+2007 FIGURE SPACE Common Separator, space U+2008 PUNCTUATION SPACE Common Separator, space U+2009 THIN SPACE Common Separator, space U+200A HAIR SPACE Common Separator, space U+2028 LINE SEPARATOR Common Separator, line
  • 36. Unicode Whitespace 4/4 Code point Name Script General category Remark U+2029 PARAGRAPH SEPARATOR Common Separator, paragraph U+202F NARROW NO-BREAK SPACE Common Separator, space U+205F MEDIUM MATHEMATICAL SPACE Common Separator, space U+3000 IDEOGRAPHIC SPACE Common Separator, space
  • 38. Unicode algorithm Bi-directional text Unicode collation algorithm Unicode equivalence
  • 39. Bi-directional text - 문화권 별 텍스트의 방향이 다름 left to right 라틴 계열 등 right to left 아랍, 히브리어 계열 등 - 방향이 다른 텍스트 각각 및 섞어 사용하는 경우 어떻게 표 시하는지에 대한 방법을 정의 (강, 약, 중립, 명시적으로 구 분) 제어코드 - U+200E LRM, U+200F RLM, U+061C ALM 숫자, 기호, 등 공백 문자, Tab, 등 명시적 코드 - U+202A LRE, U+202D LRO, U+202B RLE, … etc
  • 40. Unicode collation algorithm - 두 문자열을 대조 혹은 정렬을 하기 위한 방법을 정의 수치 및 시간 언어별 문자 순서 부수와 획 순서 - Collation Chart - ISO-14651 문자열 비교를 위한 국제 표준
  • 41. Unicode equivalence - 같은 기호를 사용하지만 다른 언어권에 있는 경우 구분하 여 별도의 코드를 부여 - 한글 처럼 Alphabet 조합 방식의 경우, 각 Alphabet의 조 합 및 분해를 정의하여 비교 가능케 함 NFC character A m é l i e NFC code point 0041 006d 00e9 006c 0069 0065 NFD code point 0041 006d 0065 0301 006c 0069 0065 NFD character A m e ◌́ l i e