본문으로 건너뛰기

1. 문자 인코딩 개요

  • 문자 인코딩은 컴퓨터가 텍스트를 저장하고 전송하기 위해 문자를 이진수로 변환하는 방식입니다.
  • 컴퓨터는 모든 데이터를 0과 1의 이진수로만 처리할 수 있기 때문에 문자 인코딩이 필요합니다.
  • 시대별로 다양한 인코딩 방식이 개발되었으며, 각각의 장단점이 있습니다.

2. ASCII (American Standard Code for Information Interchange)

  • ASCII는 1963년에 미국에서 개발된 가장 기본적인 문자 인코딩 표준입니다.
  • 7비트를 사용하여 총 128개(2^7)의 문자를 표현할 수 있습니다.
  • ASCII는 영문 알파벳, 숫자, 특수문자, 제어문자 등을 포함합니다.
  • 확장 ASCII는 8비트를 사용하여 256개(2^8)의 문자를 표현할 수 있습니다.

2.1 ASCII 코드 예시

A = 65 (01000001)
B = 66 (01000010)
a = 97 (01100001)
1 = 49 (00110001)
  • ASCII의 한계는 영어 이외의 다른 언어를 표현하기 어렵다는 점입니다.
  • 한글, 중국어, 일본어 등 다양한 문자를 표현할 수 없습니다.

3. 유니코드 (Unicode)

  • 유니코드는 전 세계의 모든 문자를 표현할 수 있는 국제 표준 문자 집합입니다.
  • 각 문자에 고유한 코드 포인트(Code Point)를 할당합니다.
  • 현재 약 14만 개 이상의 문자를 포함하고 있습니다.
  • 유니코드는 문자 집합(Character Set)이며, 실제 저장 방식은 인코딩 방식에 따라 다릅니다.

3.1 유니코드 코드 포인트 예시

A = U+0041
가 = U+AC00
⌘ = U+2318
😀 = U+1F600
  • 유니코드는 평면(Plane)이라는 개념을 사용하여 문자를 구성합니다.
  • BMP(Basic Multilingual Plane)는 가장 기본적인 평면으로 대부분의 현대 문자를 포함합니다.

4. UTF-8 (Unicode Transformation Format - 8bit)

  • UTF-8은 유니코드를 실제로 저장하는 가장 보편적인 인코딩 방식입니다.
  • 가변 길이 인코딩 방식을 사용하여 1~4바이트로 문자를 표현합니다.
  • ASCII 문자는 1바이트로 표현되어 하위 호환성이 유지됩니다.
  • 한글, 한자 등의 문자는 3바이트로 표현됩니다.

4.1 UTF-8 인코딩 규칙

1바이트: 0xxxxxxx                 (ASCII 문자)
2바이트: 110xxxxx 10xxxxxx (유럽 문자 등)
3바이트: 1110xxxx 10xxxxxx 10xxxxxx (한글, 한자 등)
4바이트: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx (이모지 등)
정보

UTF-8은 웹에서 가장 널리 사용되는 인코딩 방식으로, 현재 웹 페이지의 95% 이상이 UTF-8을 사용하고 있습니다.

5. UTF-16

  • UTF-16은 유니코드를 16비트(2바이트) 단위로 인코딩하는 방식입니다.
  • BMP 영역의 문자는 2바이트로 표현됩니다.
  • BMP 이외의 문자는 서로게이트 쌍(Surrogate Pair)을 사용하여 4바이트로 표현됩니다.
  • Windows의 기본 문자열 처리 방식으로 사용됩니다.

5.1 UTF-16 특징

- BMP 문자: 2바이트
- 서로게이트 쌍: 4바이트
- 영어도 2바이트를 사용하므로 ASCII와 호환되지 않음

6. URL 인코딩

  • URL에서 특수문자나 non-ASCII 문자를 안전하게 전송하기 위한 인코딩 방식입니다.
  • 퍼센트 인코딩(Percent Encoding)이라고도 합니다.
  • 안전하지 않은 문자를 %와 16진수 코드로 변환합니다.

6.1 URL 인코딩 예시

공백 = %20
! = %21
한 = %ED%95%9C
  • URL 인코딩은 다음과 같은 경우에 사용됩니다:
    • 쿼리 문자열의 특수문자
    • 경로의 non-ASCII 문자
    • 폼 데이터 전송

7. Base64 인코딩

  • Base64는 바이너리 데이터를 텍스트로 변환하는 인코딩 방식입니다.
  • 64개의 안전한 ASCII 문자만을 사용합니다(A-Z, a-z, 0-9, +, /).
  • 이메일 첨부 파일, 이미지의 Data URL 등에서 사용됩니다.

7.1 Base64 인코딩 과정

1. 바이너리 데이터를 6비트씩 나눕니다.
2. 각 6비트를 Base64 알파벳에 매핑합니다.
3. 3바이트 단위로 처리하며, 부족한 부분은 패딩(=)을 추가합니다.

Base64 인코딩은 데이터 크기를 약 33% 증가시키지만, 텍스트 기반 프로토콜에서 바이너리 데이터를 안전하게 전송할 수 있게 해줍니다.

8. 한글 인코딩: EUC-KR과 CP949

  • 한글은 ASCII로 표현할 수 없어 독자적인 인코딩 방식이 필요했습니다.
  • 초기에는 여러 한글 인코딩 방식이 제안되었으나, EUC-KR과 CP949가 주류로 자리잡았습니다.

8.1 EUC-KR (Extended Unix Code - Korea)

  • EUC는 "Extended Unix Code"의 약자로, Unix 시스템에서 영어 외의 문자를 표현하기 위한 확장 인코딩입니다.
  • 각 나라별로 다른 버전이 있습니다:
    • EUC-JP: 일본어용
    • EUC-KR: 한국어용
    • EUC-CN: 중국어용

8.1.1 EUC-KR의 특징

- KS X 1001 (구 KSC 5601) 완성형 한글 기반
- 2,350자의 한글 완성형 문자만 지원
- 2바이트 고정 길이 인코딩 사용
- 첫 바이트: 0xA1~0xFE
- 둘째 바이트: 0xA1~0xFE
  • EUC-KR의 한계
    • 현대 한글에서 사용되는 많은 글자를 표현할 수 없습니다.
    • '똠', '훈', '뷁' 등의 글자가 표현 불가능합니다.
    • 이모지나 특수 문자 지원이 불가능합니다.

8.2 CP949 (Code Page 949)

  • CP는 "Code Page"의 약자로, Microsoft Windows의 인코딩 페이지를 의미합니다.
  • "확장완성형" 또는 "마이크로소프트949"라고도 불립니다.
  • Microsoft가 EUC-KR의 한계를 극복하기 위해 개발했습니다.

8.2.1 CP949의 특징

- EUC-KR의 확장 버전
- 11,172자의 모든 한글 완성형 조합 지원
- 2바이트 고정 길이 인코딩 사용
- Windows의 기본 한글 인코딩
- EUC-KR과의 하위 호환성 유지

8.3 역사적 발전 과정

  • 초기 시스템 (1980년대)
    • 한글 표현을 위한 다양한 시도가 있었습니다.
    • 조합형과 완성형이 경쟁했습니다.
  • EUC-KR의 등장 (1990년대 초)
    • Unix 시스템에서 표준으로 채택되었습니다.
    • 당시 자주 사용되는 한글만을 포함했습니다.
  • CP949의 도입 (1990년대 중반)
    • Microsoft가 Windows 95와 함께 도입했습니다.
    • 모든 한글 조합을 표현할 수 있게 되었습니다.
  • 현대
    • UTF-8이 표준으로 자리잡았습니다.
    • EUC-KR과 CP949는 레거시 시스템 지원용으로 유지됩니다.

8.4 인코딩 비교 예시

8.4.1 다양한 인코딩에서의 한글 표현

문자: "한글"
EUC-KR: B1 DB B1 DB
CP949: B1 DB B1 DB
UTF-8: ED 95 9C EA B8 80

문자: "뷁" (희귀 한글)
EUC-KR: 표현 불가
CP949: A4 A1
UTF-8: EB B7 81

8.5 현대의 권장사항

  • 새로운 시스템 개발 시에는 UTF-8 사용을 강력히 권장합니다.
  • UTF-8의 장점:
    • 모든 한글 표현 가능
    • 국제화(i18n) 지원 용이
    • 이모지 등 특수 문자 지원
    • 웹 표준과의 호환성
  • EUC-KR이나 CP949는 다음 경우에만 사용:
    • 레거시 시스템과의 호환성이 필요할 때
    • 오래된 데이터의 마이그레이션 시
    • 특수한 환경의 임베디드 시스템
경고

새로운 웹 사이트나 애플리케이션을 개발할 때는 항상 UTF-8을 사용하세요. 다른 인코딩 방식은 호환성 문제를 일으킬 수 있습니다.

9. 인코딩 관련 문제 해결

  • 인코딩 관련 문제는 소프트웨어 개발에서 자주 발생하는 이슈입니다.
  • 대표적인 문제와 해결 방법을 알아보겠습니다.

9.1 깨진 문자 (Mojibake)

  • 잘못된 인코딩으로 인해 문자가 깨져 보이는 현상입니다.
  • 주로 다음과 같은 경우에 발생합니다:
    • UTF-8 텍스트를 EUC-KR로 해석할 때
    • EUC-KR 텍스트를 UTF-8로 해석할 때
    • 인코딩 정보가 없는 경우

9.2 해결 방법

  • 항상 문자열의 인코딩을 명시적으로 지정합니다.
  • 모든 단계에서 일관된 인코딩을 사용합니다.
  • 가능하면 UTF-8을 사용합니다.

9.2.1 Python에서의 인코딩 처리 예시

# 파일 읽기
with open('file.txt', 'r', encoding='utf-8') as f:
text = f.read()

# 파일 쓰기
with open('file.txt', 'w', encoding='utf-8') as f:
f.write(text)

# 인코딩 변환
text_utf8 = text_euckr.encode('euc-kr').decode('utf-8')

10. 결론

  • 문자 인코딩은 디지털 시대의 텍스트 처리에 핵심적인 개념입니다.
  • ASCII에서 시작하여 유니코드와 UTF-8로 발전해왔습니다.
  • 현대에는 UTF-8이 가장 보편적인 인코딩 방식으로 자리잡았습니다.
  • 다양한 인코딩 방식의 특징과 용도를 이해하는 것이 중요합니다.
  • 인코딩 관련 문제를 예방하고 해결하기 위해서는 일관된 인코딩 정책이 필요합니다.
정보

문자 인코딩은 소프트웨어 개발에서 기본이지만 종종 간과되는 영역입니다. 많은 버그와 문제가 올바른 인코딩 처리로 해결될 수 있습니다.