문자 인코딩 기초

25 Sep 2022 •

Development

•

encoding

구닥다리 내용이라 오히려 쥬니어들은 잘 몰랐었다고 함

문자 인코딩 기초

ASCII(American Standard Code for Information Interchange)
- https://stepbystep1.tistory.com/10
- 영어, 숫자, 특수 문자 일부
- 원래 7 bit
  - 0000000 ~ 1111111
- ISO 8859
  - 7 bit 앞에 1 bit 짜리 0을 붙여서 8 bit = 1 byte
  - 00000000 ~ 01111111(0x00~0x7F)
- 예시
  - Y e s !
    - 0x59 0x65 0x73 0x21
EUC-KR(Extended Unix Code-KR)
- 표
  - http://i18nl10n.com/korean/euckr.html
- 영문, 숫자, 특수 문자 일부
  - 1 byte
  - ASCII와 동일. 즉, ASCII(0x00~0x7F)와 호환
    - 단, 0x5C의 경우 원래 ASCII에서는 역슬래쉬(”\”)이나, EUC-KR에서는 원화(“￦”)로 표시함
      - KS X 1003
- 한글, 한자 일부, 특수 문자 일부
  - 2 byte
    - (0xA1~0xFE)(0xA1~0xFE)
  - 한글은
    - 0xB0A1~0xC8FE
  - 예시
    - 밀 가 루 3 g
      - 0xB9 0xD0 0xB0 0xA1 0xB7 0xE0 0x33 0x67
- KS X 1003 값의 범위(0x00~0x7F)와 한글, 한자, 특수 문자 일부 값의 범위(0xA1~0xFE)가 다르기 때문에 문자열 중 랜덤하게 1 byte 값을 살펴 봤을 때, 바로 영문인지 영문이 아닌지 알 수 있음
- 한글 값의 범위가 연속적으로(0xB0A1~0xC8FE) 특정되며, 범위 안에서 한글들도 순서대로(가~힝) 정렬되어 있음
- 전체 한글 11172자 중 2350자만 표현 가능
  - 뷁, 똠, 롹 등의 단어 표현 불가
- 문자열 스트림 중 랜덤하게 1 바이트만 읽어본 후, 해당 바이트의 앞 뒤, 어떤 바이트를 붙여서 한글을 표현할지 판단 못함
CP949(Code Page 949)
- 표를 5개의 페이지로 나눠 만들어 놨음
  - http://www.i18nl10n.com/korean/cp949l.html
  - 3개 페이지는 EUC-KR 코드와 동일(Special Symbols, Chinese Characters, 2350 Hangul Syllables)
  - 2개 페이지는 추가 한글 코드(Additional Hangul Syllable Set 1, Additional Hangul Syllable Set 2)
- 확장 완성형(Unified Hangul Codeset)이라고도 함
- CP949를 그냥 EUC-KR로 부르기도 함
- 표현하지 못했던 한글 8822글자(11172-2350)를 사용하지 않았던 2 byte에 구겨 넣음
- 2 byte
  - (0x81~0xC6)(0x41~0x5A, 0x61~0x7A, 0x81~0xFE)
- 빈 공간에 구겨 넣은 것이기 때문에, 한글 값의 범위를 연속적으로 특정할 수 없음
- 범위 안에서 한글들이 정렬 안되어 있음
- 문자열 스트림 중 랜덤하게 1 바이트만 읽어본 후, 해당 바이트의 앞 뒤, 어떤 바이트를 붙여서 한글을 표현할지 판단 못함
유니코드
- 각 나라의 문자를 섞어 쓰고 싶다
  - 고정된 문자 코드의 필요성
- 2 byte x 17 페이지(0~16 plain)
  - 0x0000~0xFFFF
- 0 plain
  - 기본 다국어 평면(basic multilingual plane)
  - 대부분의 문자 코드가 여기에 존재
- 1 plain
  - 보조 다국어 평면(supplementary multilingual plane)
- 2 plain
  - 보조 상형 문자 평면(supplementary ideographic plane)
- 3~13 plain
  - 예비
- 14~16 plain
  - 그 외
- 0 plain 이외의 문자에는 문자 앞에 plane 번호를 붙인다
  - 0xB0000 → 0 plain
  - 0x10B0000 → 16 plain
- 0 plain 이외의 plain에 있는 문자를 표현하기 위해서는 2 byte로 모자르다
UCS(Universal Character Set)-2
- plain 0만 씀
- 2 byte
- HTML Entity Number에 사용됨
  - 예시
    - 가
      
      → 가
- plain 1~plain 16 내 문자는 사용 못함
UTF(UCS Transformation Format)-32
- UCS-4 는 문자 집합의 표준. UTF-32는 그걸 표현하기 위한 인코딩 방식인데 그냥 UCS-4를 UTF-32 라고 부름. 나중에 UCS-4에 뭔가 추가 되면 UTF-32와는 달라질 것
- 4 byte
  - plain 2 byte + 문자 코드 2 byte
- 예시
  - 가 → 0x00 0x00 0xAC 0x00
- 4 byte는 너무 크다
- UTF-16과 구분할 수 없기 때문에 HTML5에서는 사용 금지 됨
UTF-16
- 2 byte ~ 4 byte
- 0 plain의 문자는 그냥 2 byte로 씀
- 1 plain~16 plain의 문자는 4 byte로 쓰는데, 인코딩 해서 씀
  - 0 plain의 0xD800(1101100000000000)~0xDB7F(1101101101111111), 0xDC00(1101110000000000)~0xDFFF(1101111111111111) 사이는 비어 있음
  - 1 plain~16 plain의 값을 인코딩해서 4 byte의 앞 6 bit를 110110 또는 110111로 만듬
  - 왜 이렇게 할까?
    - 문자열 스트림 중 랜덤하게 2 바이트만 읽어봤는데, 그 중에 110110 또는 110111로 시작하는 바이트가 있다면, 그건 plain 1~plain 16에 위치한 4 byte 짜리 문자일 것이다
    - 그렇지 않다면 plain 0에 위치한 2 byte 문자일 것이다
UTF-8
- UTF-16 다 좋은데 ASCII와 호환이 안됨
- UTF-16의 문자열 스트림에는 중간에 0x00이 있을 수 있음. 따라서 프로그래밍 할 때 까다로움
- ASCII 영역(0x00~0x7F)은 1 byte 문자
- 기본 다국어 평면(plain 0)의 문자는 2 byte~3 byte
  - 0x0080~0x07FF 까지는 2 byte 문자
    - 3 bit가 110으로 시작되도록 인코딩
  - 0x0800~0xFFFF 까지는 3 byte 문자
    - 4 bit가 1110으로 시작되도록 인코딩
- 기본 다국어 평면 외의 문자는 4 byte로
  - 5 bit가 11110으로 시작되도록 인코딩
- 문자열 스트림 중 랜덤하게 1 바이트를 읽어보면, 문자의 성격을 알 수 있다
  - 시작 1 bit가 0이면, 1 byte ASCII 문자
  - 시작 3 bit가 110이면, 2 byte 문자
  - 시작 4 bit가 1110이면, 3 byte 문자
  - 시작 5 bit가 11110이면, 4 byte 문자
  - 시작 2 bit가 10으로 시작하면, 어떤 문자의 중간 부분
참고
- https://dev.epiloum.net/648