TL;DR

• UTF-8은 유니코드 스칼라 값(= surrogate code point 제외)을 1~4바이트 가변 길이로 인코딩하는 방식이다.
• ASCII(0~127)와 완전 호환되며, 웹의 사실상 표준 인코딩이다.

UTF-8

유니코드와 UTF-8의 관계

둘은 서로 다른 레이어다:

	역할	비유
유니코드	전 세계 문자에 고유 번호(코드 포인트)를 부여하는 번호표	전화번호부
UTF-8	그 번호를 실제 바이트로 저장·전송하는 방식	전화번호를 종이에 적는 방법

'A'  → U+0041  (유니코드 번호)  → 0x41              (UTF-8 바이트)
'가' → U+AC00  (유니코드 번호)  → 0xEA 0xB0 0x80    (UTF-8 바이트)
'😀' → U+1F600 (유니코드 번호)  → 0xF0 0x9F 0x98 0x80 (UTF-8 바이트)

유니코드 인코딩 방식에는 UTF-8 외에도 UTF-16, UTF-32가 있지만, UTF-8이 웹·파일·프로토콜의 사실상 표준이다.

---

가변 길이 인코딩

모든 문자를 4바이트로 저장하면 간단하지만, 영어 A(번호 65)에 4바이트는 낭비다. UTF-8은 작은 번호는 적은 바이트, 큰 번호는 많은 바이트 를 사용한다:

유니코드 범위	10진수 범위	바이트 수	대상 문자
U+0000 ~ U+007F	0 ~ 127	1바이트	영어, 숫자, ASCII 전체
U+0080 ~ U+07FF	128 ~ 2,047	2바이트	유럽 악센트 문자 (ñ, ü, é 등)
U+0800 ~ U+FFFF	2,048 ~ 65,535	3바이트	한글, 중국어, 일본어 대부분 (단, U+D800~U+DFFF surrogate 제외)
U+10000 ~ U+10FFFF	65,536 ~ 1,114,111	4바이트	이모지, 고대 문자

---

바이트 패턴

파서가 “이 바이트가 몇 바이트짜리 문자의 시작인지” 구분하기 위해, 각 바이트 앞에 표식을 둔다:

바이트 수	첫 바이트	이어지는 바이트	데이터 비트
1	0xxxxxxx	—	7비트
2	110xxxxx	10xxxxxx	11비트
3	1110xxxx	10xxxxxx × 2	16비트
4	11110xxx	10xxxxxx × 3	21비트

규칙:

• 첫 바이트의 선행 1의 개수 = 총 바이트 수 (1바이트는 0으로 시작하여 예외)
• 이어지는 바이트는 항상 10으로 시작 → “중간 바이트”라는 표시
• 이 설계 덕분에 바이트 스트림 중간부터 읽어도 문자 경계를 찾을 수 있다 (자기 동기화, self-synchronizing)

인코딩 예시: 한글 ‘가’

1. 유니코드: '가' = U+AC00 = 44032
   (hex→10진: A×16³ + C×16² = 10×4096 + 12×256 = 40960 + 3072 = 44032)
2. 44032는 U+0800~U+FFFF → 3바이트 패턴 사용
3. 44032를 2진수로: 1010 1100 0000 0000
4. 3바이트 패턴에 채우기:
   1110[1010] 10[110000] 10[000000]
   = 0xEA      0xB0       0x80
   (검산: 0xEA = 14×16+10 = 234, 0xB0 = 11×16 = 176, 0x80 = 8×16 = 128)
5. 결과: '가' = 0xEA 0xB0 0x80 (3바이트)

16진수 읽는 법

• 0x와 U+는 모두 “이 숫자는 16진수”라는 접두어다.
• 한 자리가 4비트(0F = 015)를 표현하므로 바이트(8비트) = hex 2자리.
• 10진수 변환: 각 자리 × 16의 거듭제곱을 합산 (예: 0x41 = 4×16 + 1 = 65).

인코딩 예시: 이모지 ’😀‘

1. 유니코드: '😀' = U+1F600 = 128512
2. 128512는 U+10000~ → 4바이트 패턴 사용
3. 128512를 2진수로: 0 0001 1111 0110 0000 0000
4. 4바이트 패턴에 채우기:
   11110[000] 10[011111] 10[011000] 10[000000]
   = 0xF0      0x9F       0x98       0x80
5. 결과: '😀' = 0xF0 0x9F 0x98 0x80 (4바이트)

---

ASCII 완전 호환

UTF-8의 1바이트 영역(U+0000~U+007F)은 ASCII와 바이트 값이 동일하다:

'A' = ASCII 0x41 = UTF-8 0x41
'\n' = ASCII 0x0A = UTF-8 0x0A

• ASCII로 작성된 파일은 수정 없이 유효한 UTF-8이다
• HTTP 헤더, JSON 키워드 등 ASCII 기반 프로토콜이 UTF-8 환경에서 그대로 동작한다
• 호환성이 UTF-8이 사실상 표준이 된 결정적 이유다

---

왜 UTF-8이 표준이 되었나

대안	단점	UTF-8의 장점
확장 ASCII (CP949 등)	256자 한계, 인코딩마다 매핑 다름 → 깨짐	14만자+ 통합, 단일 표준
UTF-16	ASCII 중심 텍스트에서 비효율적, 바이트 순서 이슈로 BOM(Byte Order Mark) 또는 LE(리틀엔디안)/BE(빅엔디안) 명시 필요	byte-oriented라 바이트 순서 문제 없음
UTF-32	모든 문자 4바이트 → 공간 낭비	가변 길이로 효율적

---

Connections

• ASCII (American Standard Code for Information Interchange) — UTF-8의 1바이트 영역(0~127)이 ASCII와 동일, 완전한 하위 호환
• Base64 인코딩 — Base64는 바이너리를 ASCII 안전 문자로 변환. UTF-8 텍스트도 바이너리로 취급하여 Base64 인코딩 가능

Source Trail

• 원본: 위키백과 — UTF-8
• 기반 표준: RFC 3629 (UTF-8)
• 관련 표준: Unicode Standard (유니코드 번호 체계)

Related MOCs

• Computer Science