ASCII, Unicode와 텍스트 표현

1963년에 표준화된 ASCII(정보 교환을 위한 미국 표준 코드)는 7비트(값 0-127)로 128개의 문자를 인코딩합니다. 영어 알파벳(대문자와 소문자), 숫자, 문장 부호, 제어 문자를 포함합니다.

ASCII는 영어와 미국의 통신 장비를 위해 설계되었습니다. 원래 목적에는 잘 맞았지만 영어 이외의 언어에는 근본적으로 적합하지 않았습니다.

ASCII의 처음 32개 문자(0-31)와 DEL(127)은 제어 문자입니다. 원래 텔레타이프 기계를 제어하기 위해 설계되었으며, LF(줄 바꿈, 10), CR(캐리지 리턴, 13), BEL(벨, 7), TAB(9), ESC(27)가 여기에 포함됩니다.

암호학적 맥락에서는 제어 문자가 문제를 일으킬 수 있습니다. 널 바이트(0x00)는 C 문자열을 너무 일찍 종료하며, DEL 또는 ESC 문자는 터미널 에뮬레이터에서 특정 명령으로 해석될 수 있습니다.

여러 국가에서는 8번째 비트(값 128-255)를 사용해 ASCII를 자체적으로 확장했고, 그 결과 서로 호환되지 않는 수백 가지 인코딩이 만들어졌습니다. 서유럽용 ISO-8859-1(Latin-1), 러시아어용 KOI-8R, 중국어용 Big5 등이 그 예입니다.

한 인코딩으로 저장된 문서를 다른 인코딩으로 열면 횡설수설처럼 나타납니다. 보편적인 표준이 없었기 때문에 1980년대와 1990년대 내내 국제 소프트웨어 개발은 큰 어려움을 겪었습니다.

Unicode는 모든 인간의 문자 체계를 포괄하는 하나의 보편적인 문자 집합을 제공하기 위해 만들어졌습니다. 현재 161개의 문자 체계를 아우르는 149,000개가 넘는 문자를 정의하며, 여기에는 역사적 문자 체계와 기호도 포함됩니다.

Unicode는 문자 식별자(예: "A"를 나타내는 U+0041 코드 포인트)와 인코딩(해당 코드 포인트를 바이트에 저장하는 방식)을 분리합니다. 이러한 분리 덕분에 여러 인코딩 형식으로 동일한 문자를 표현할 수 있습니다.

UTF-8은 Unicode 코드 포인트를 1~4바이트로 인코딩합니다. ASCII 문자(U+0000~U+007F)는 ASCII 값과 동일한 정확히 1바이트를 사용하므로 UTF-8은 ASCII와 하위 호환됩니다.

U+0080부터 U+07FF까지의 문자는 2바이트를 사용합니다. U+0800부터 U+FFFF까지는 3바이트를 사용하며, 여기에는 중국어, 일본어, 한국어를 비롯한 대부분의 일반적인 문자 체계가 포함됩니다. U+10000 이상은 4바이트를 사용합니다.

UTF-16은 가장 일반적인 문자(기본 다국어 평면, U+0000~U+FFFF)에 2바이트를 사용하고, U+FFFF를 초과하는 문자에는 4바이트(서로게이트 쌍)를 사용합니다. Windows와 Java 내부에서 사용됩니다.

UTF-32는 코드 포인트마다 정확히 4바이트를 사용하므로 고정 너비이며 문자 위치로 인덱싱하기 쉽지만, ASCII가 대부분인 텍스트에는 낭비입니다. 빠른 무작위 접근을 위해 일부 내부 표현에서 사용됩니다.

바이트 순서 표시(BOM)는 바이트 순서와 인코딩을 나타내기 위해 파일 시작 부분에 배치되는 Unicode 문자 U+FEFF입니다. UTF-16에서는 빅 엔디언(FE FF)과 리틀 엔디언(FF FE)을 구분합니다.

UTF-8에서는 바이트 순서 문제가 없으므로 BOM(EF BB BF)이 필요하지 않지만, 일부 Windows 소프트웨어는 여전히 BOM을 추가합니다. 이 때문에 BOM을 표시가 아니라 데이터로 취급하는 암호학적 애플리케이션에서 문제가 발생합니다.

암호학적 해시 함수와 MAC은 추상적인 문자가 아니라 바이트 시퀀스에서 작동합니다. 동일한 문자열 "café"도 UTF-8에서는 4바이트(63 61 66 C3 A9)로, Latin-1에서는 4바이트(63 61 66 E9)로 다르게 인코딩됩니다.

두 시스템이 같은 문자열을 해시하면서 서로 다른 인코딩을 사용하면 서로 다른 해시를 생성하므로 인증에 실패합니다. 암호 프로토콜은 상호 운용성을 보장하기 위해 인코딩을 명시적으로 지정해야 합니다.

이모지는 Unicode의 보조 다국어 평면에 속하는 문자입니다. "활짝 웃는 얼굴" 이모지(U+1F600)는 UTF-8에서 4바이트 F0 9F 98 80으로 인코딩됩니다.

보안 환경에서는 이모지와 전각 Unicode 문자가 동형 문자 공격에 사용되어 왔습니다. 예를 들어 "xn--pple-43d.com"과 같은 URL은 "apple.com"처럼 보여 사용자가 악성 사이트를 방문하도록 속일 수 있습니다.

일부 문자는 여러 형태의 Unicode로 표현할 수 있습니다. "급성 악센트가 있는 e"는 U+00E9(미리 조합된 문자) 또는 U+0065 U+0301(결합 악센트가 뒤따르는 e, 분해된 형태)로 표현할 수 있습니다. 두 형태는 동일하게 보이지만 바이트 표현은 다릅니다.

해시하기 전에 Unicode를 정규화하지 않는 암호학적 시스템은 시각적으로 동일한 문자열에 대해 서로 다른 해시를 생성할 수 있습니다. 텍스트에 암호 연산을 적용하기 전에 NFKC 정규화를 사용하는 것이 일반적으로 권장됩니다.

암호학적 시스템을 구현할 때 인코딩 선택은 문서화해야 하는 중요한 결정입니다. 비밀번호는 해시하기 전에 UTF-8로 인코딩해야 합니다. 프로토콜 필드는 사양 문서에서 인코딩을 지정해야 합니다.

인코딩 불일치로 인한 상호 운용성 실패는 암호학적 시스템에서 버그가 발생하는 흔한 원인입니다. 동일한 프로토콜을 구현한 두 프로그램도 문자열을 서로 다르게 인코딩하면 서로 다른 인증 결과를 낼 수 있습니다.

ASCII는 7비트로 128개의 문자를 표현합니다. Unicode는 모든 인간의 문자 체계를 위한 보편적인 코드 포인트 공간을 제공합니다. UTF-8은 Unicode를 1~4바이트로 인코딩하며, ASCII는 그중 1바이트로 표현되는 부분 집합입니다.

암호학에서는 해시 함수가 바이트에서 작동하므로 인코딩이 중요합니다. 서로 다른 인코딩으로 표현된 동일한 텍스트는 서로 다른 해시를 생성합니다. 텍스트에 암호 연산을 수행하기 전에 Unicode 정규화가 필수적입니다.