[Too Swfit] 시즌1 4회. 스위프트의 캐릭터를 알고싶어. Want to know Swift's character

1. 'Character' type

  문자 representation 체계 중에는 ASCII가 있습니다. 아스키는 문자를 7비트로 표현하는 최대 128개의 문자를 나타낼 수 있는 체계입니다. 이것에 대한 super (char) set으로 나온 UTF-8은 이 아스키 표현 관계를 그대로 상속한채로, 문자 스펙트럼을 넓힌 캐릭터 세트입니다. 

 

2. Operation on Character < type checking >

// 이거 공백문자 맞니?
let space: Character = " "
space.isWhitespace -> true or false

// 이 캐릭터는 아스키 체계에 있는 거니?
let aChar = "a"
aChar.isASCII

// 이거 16진법 표현하는 체계 중 하나니( 0-9, a-f or A-F )
let aChar2 = "s"
aChar2.isHexDigit

 

>>> 문자를 그 문자가 나타내는 Int 자료형으로 변환하기

let unicodeNine: Character = "9"
unicodeNine.wholeNumberValue

캐릭터타잎데이터.wholeNumberValue! -> 문자체계에서 그 문자가 나타내는 숫자를 정수형으로

 

3. 스트링(캐릭터의 컬렉션)의 인코딩 모드의 의미

  인코딩 방식으로 : UTF-32모드를 고른다는 것은, 스트링의 멤버들인 코드포인트들을 하나당 넉넉잡아 UINT32를 서서 대응표현할 것이며, 그렇다면, 이 스트링은 하나당 32비트 짜리인 코드 포인트들이 모인 [UINT32] 가 되는 것입니다.

하지만, 이렇게 UINT-32는 엄청난 낭비입니다. 왜냐하면, 세계 대부분 언어의 문자를 대응표현 가능한 유니코드도 21비트도 다 쓰지 못하는 상태(약 110만개 하고, 더 못채우는 상태) 이기 때문입니다.

 

7비트로 표현 가능한 0번 - 127번에 맵핑된 문자들은(code point)는, 1개의 코드 유닛(UINT8)을 이용해서 저장하고 해석될 수 있습니다. 만약 8비트에서 11비트를 이용하면 또 다른 1바이트(8비트)를 써서 저장하고 해석하고 해야겠죠? 위에 그림이 매우 간단하게 나와있습니다.

 

그래서 매우 유연한 체계인, utf-8이 사용됩니다. 세계의 문자를 맵핑하는 체계인 유니코드는, 최대 21비트를 이용하여, 각 국의 문자들(약 110만개)을 code point로 맵핑 시켜놓았습니다. 예를 들어, 다음의 사진을 봅시다.

캐릭터 세트의 개념 : 예를 들어, 영어의 대문자 A는 숫자 65(번째)로 맵핑되어 있네요. 옆에 보니, 서유럽권 아랍권의 그리스 알파벳을 쓰는 나라들의 문자도 보이죠. 걔네들은 192(번째)라는 숫자로 일대일 대응 시켜놓은 것입니다. 

 

4. 어떤 Character의 코드 유닛 집합을 확인하기 :

>>> Character.utf8 -> code unit들의 컬렉션을 리턴

let char = "\u{00BD}" // ½ <- 이 글자 입니다

// utf8으로 표현했을 때 위에서 설명한, 문자를 이루는 code unit들을 리턴합니다.
for i in char.utf8 {
    print(i)
}

// < UTF-8 views - code Units - 8비트를 쓰니 당연히 유닛은 2개겠죠. 즉 메모리에서는 2바이트를
//쓰는 8비트를 요구하는 캐릭터인 것입니다.>

// code units that makes up the string
//194
//189


// (110)00010 = 194
// (10)111101 = 189

 

5. 스트링의 코드유닛 모음을 관찰해봅시다.

"+½⇨🙃" 이 스트링의 utf-8에 의한, 코드 유닛들을 보시겠습니다.

let characters = "+\u{00bd}\u{21e8}\u{1f643}"
for i in characters.utf8{ // code unit - one
    print("\(i) : \(String(i, radix: 2))")
    
    if (i == 43 || i == 189 || i == 168){
        print()
    }

}

.utf8 컬렉션을 받아 code units들을 이터레이션 해보니, 다음과 같이 나옵니다.

디폴트로 설정된 비트가 아닌 x표시들을 2진법으로 나타낸 수가 코드포인트 입니다. 밑의 설명을 이해할 때 참고하세요.

 

+ : 1 ~ 7 비트 숫자로 맵핑된 문자 => 1 바이트 이용

43 : 101011

 

½ : 8비트 ~ 11비트 숫자로 맵핑된 문자 => 2바이트 이용

194 : 11000010  

189 : 10111101

 

" 실제 컴퓨터에는 2바이트를 사용하여, 110|00010 / 10|111101 => 10111101 => utf-8에 의해 189라는 숫자에 대응된 문자

하지만 쉽게 알 수 있듯이, 7비트를 사용하면 0 ~ 128이라는 숫자 범위 까지 밖에 맵핑되지 못하죠. 189와 대응하는 ½  라는 놈은

8비트를 사용해야 표현할 수 있고 그러려면, 2바이트, 2개의 코드 유닛을 사용해야합니다. "

 

⇨ : 12비트 ~ 16비트 숫자로 맵핑된 문자 => 3바이트 이용

226 : 11100010

135 : 10000111

168 : 10101000

 

🙃 : 17비트 ~ 21비트 숫자로 맵핑된 문자 => 4바이트 이용

240 : 11110000

159 : 10011111

153 : 10011001

131 : 10000011

 

6. 왜 UTF-16, 32보다 나은가?

이 인코딩 체계는, 한 코드 포인트( 문자가 맵핑된 수 )를 나타내는 데, 최소한 16비트(2바이트), 32비트(4바이트)를 사용하는 방식입니다.

이렇게하면, 코드 포인트에 따라, 유연하게 1 ~ 4바이트를 탄력적으로 사용하는 UTF-8보다, 훨씬 더 많은 바이트(용량)을 사용해야합니다. 비용적으로 매우 비효율적이죠. 예) UTF-32면, 저 위 4개의 코드포인트 각각을 모두 32비트(4바이트)로 표현하는 것이라 낭비가 매우 매우 심할 것이고, 만약 그리스문자 위주로 나온 글을 그렇게 인코딩한다면, 용량을 4배를 더 쓰고, 같은 스트링을 저장하는 것이 되겠죠.

 

단점은 ?? Search : O(n) UTF-8 vs O(1) UTF-32

코드포인트의 범위별로 코드 유닛 갯수(1바이트)가 달라서, 오퍼레이션을 적용할 때 매우 힘들다. 예를 들어, 3번째 문자로 점프하라 라는 명령이 있다면, 모든 바이트들을 점검하여 끊어나가면서 찾아야한다. 32바이트면 바로 바이트 주소를 지정하면, 일정하게 찾을 수 있다. 스트링 오퍼레이션은 당연히 32바이트보다 느릴 수 있는 것이다. 

 

7. UTF-16 인코딩 swift's pick !!

unicode codepoint상 16비트로 표현가능한 숫자에 대응된, 0 ~ 2^16 - 1 문자까지는 16비트 단위의 code unit, 17 ~ 21비트로 표현되는 수에 맵핑된 수에는 두 개의 codeunit들을 사용하는 인코딩 방식. 

 

< Surrogate Pair 방식 >

술 게임도 마시면서 배우는 데, 이것도 직접 한 복잡한 코드포인트를 유닛으로 전환시켜보면서 배워보죠.

\u{0x1F643} // => upside-down smiley emoji
// 17비트로 표현되는 숫자에 대응되는 문자군요.
// -> 🙃

Surrogate pair for 17<= <=21

2 utf-16 code units

 

Represent the following hexadecimal codePoint

\u{1f643} : upside down smile emoji 🙃

 

// 1). 16이 넘는 부분의 수인 1을 빼준다.

// 17번째 비트를 빼준다. -> 0으로

// subtract 0x10000

//  - 1 0000 0000 0000 0000 (in hexa)

// 그러면 그 문자는 => \u{F643} 이 됩니다.

 

// 2). 이 나머지 20비트를 두개로 나눔

// 0000 1111 01 / 10 0100 0011

// 윗 서로게이트 / 아랫 서로게이트

 

// 윗 서로게이트 조각에 D800더하기

// 0000 0000 0011 1101

// 1101 1000 0000 0000 +

// D      8       3      D          => HIGH SURROGATE

 

// 뒷 서로게이트 조각에 DC00 더하기

// 0000 0010 0100 0011

// 1101 1100 0000 0000 +

// D      E       3       3         => LOW SURROGATE

 

// 3). 이것을 이어붙이기

// 그렇다면 이것은 두개의 16비트짜리 코드 유닛 두개를 쓰는

// D      8       3      D  /  D      E       3       3 

// 다음의 숫자가 됩니다.

// 두 개의 유닛이 필요하죠?

해당 이모지는 다음과 같이 16비트 짜리 코드 유닛 두개로 표현되네요. 16-utf에서는 17비트 이상이 필요한 수로 맵핑된 문자는 4바이트를 사용하게 됩니다.

 

   1). 단점

1. utf-8에 비해, 7bit이하의 숫자에 대응되는 문자가 많을 경우, 1바이트(8비트)를 더 사용해서 그 문자를 저장하게 된다. 예를 들어, 라틴 문자만 사용하는 경우 거의 모든 글자에서 8비트(1바이트)를 더 써서 그 문자를 저장하는 것이다.

   2). 장덤

1. UTF-8에 비해 Operation적용시 더 효율적 (한 문자가 1유닛, 2유닛, 3유닛, 4유닛을 쓰기 때문에.) 

   +

2. utf-32에 비해 메모리 사용 효율적 ( 모든 문자에 32비트, 4바이트를 쓰기 때문. )