유니코드 등가성

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

유니코드 등가성은 모양이 다르지만 동일한 의미를 가지는 유니코드 문자를 다루는 개념이다. 유니코드 정규화는 이러한 등가성을 처리하기 위한 표준화된 방법으로, 문자열 검색 및 비교 시 일관성을 유지하는 데 중요하다. 정규화에는 NFD, NFC, NFKD, NFKC의 네 가지 형식이 있으며, 각 형식은 문자를 분해하거나 결합하는 방식으로 텍스트를 변환한다. 정규 등가와 호환 등가의 두 가지 등가성 개념이 있으며, 호환 등가는 정규 등가보다 더 넓은 범위를 포함한다. 유니코드 정규화는 데이터 손실과 시각적 모호성을 방지하기 위해 중요하며, 특히 다양한 시스템 간의 텍스트 교환 시 일관성을 보장하는 데 필요하다.

더 읽어볼만한 페이지

유니코드에 관한 - UTF-8
UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
유니코드에 관한 - UTF-1
UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
유니코드 - 이모지
이모지는 1999년 NTT 도코모에서 처음 도입된 그림 문자로, 유니코드 표준 제정 후 전 세계적으로 확산되어 다양한 언어적 기능을 수행하며 대중문화에 영향을 미치지만, 플랫폼별 표현 방식 차이와 의미 해석 논란도 존재한다.
유니코드 - 국제 음성 기호
국제 음성 기호는 국제 음성 협회가 개발한 언어의 음성 표기 문자 기호 체계로, 라틴 문자를 기반으로 자음, 모음, 초분절 기호 등을 포함하여 모든 언어의 음성을 정확하게 표기하는 것을 목표로 한다.
컴퓨터에 관한 - 고속 패킷 접속
고속 패킷 접속(HSPA)은 3세대 이동통신(3G)의 데이터 전송 속도를 높이는 기술 집합체로, 고속 하향/상향 패킷 접속(HSDPA/HSUPA)을 통해 속도를 개선하고 다중 안테나, 고차 변조, 다중 주파수 대역 활용 등의 기술로 진화했으나, LTE 및 5G 기술 발전으로 현재는 상용 서비스가 중단되었다.
컴퓨터에 관한 - 데이터베이스
데이터베이스는 여러 사용자가 공유하고 사용하는 정보의 집합으로, 데이터베이스 관리 시스템을 통해 접근하며, 검색 및 갱신 효율을 높이기 위해 고도로 구조화되어 있고, 관계형, NoSQL, NewSQL 등 다양한 모델로 발전해왔다.

유니코드 등가성

2. 정규화

'''유니코드 정규화'''(Unicode normalization)는 모양이 같은 여러 문자들이 있을 경우, 이를 특정 기준에 따라 하나의 고유한 형태로 통합하는 과정을 말한다. 이는 텍스트 처리 소프트웨어에서 문자열을 검색하거나 비교할 때 일관성을 유지하고 예측 가능한 결과를 얻기 위해 중요하다. 예를 들어, '가'라는 글자를 표현하는 방식이 완성형 코드(U+AC00) 하나로 표현될 수도 있고, 초성 'ㄱ'(U+1100)과 중성 'ㅏ'(U+1161)의 조합으로 표현될 수도 있는데, 정규화는 이처럼 시각적으로 동일하지만 내부적인 코드 표현이 다른 경우를 통일된 형태로 만들어 준다.

유니코드 문자열 검색 및 비교 기능을 구현하는 텍스트 처리 소프트웨어는 등가 코드 포인트의 존재를 고려해야 한다. 이러한 고려가 없다면, 사용자가 특정 코드 포인트 순서를 검색할 때 시각적으로는 구별할 수 없지만 다른 코드 포인트 표현으로 등가인 다른 글리프를 찾지 못하는 문제가 발생할 수 있다. 또한, 정규 등가이거나 그렇지 않은 문자가 함께 존재하면 사용자에게 시각적인 혼란을 야기할 수 있으므로, 유니코드는 특정 환경에서 이러한 문자 또는 문자열들을 동일하게 처리하도록 텍스트 처리 알고리즘을 정규화하는 것을 권장한다.

2. 1. 정규화 형식

유니코드는 모양이 같은 여러 문자열을 고유한 코드 포인트 시퀀스로 표현하기 위해 표준 정규화 알고리즘을 제공한다. 이는 문자열을 비교하거나 검색할 때 일관성을 유지하는 데 중요하다. 정규화 기준에는 정규(Canonical, NF)와 호환성(Compatibility, NFK) 두 가지가 있다. 각 기준에 따라 문자를 분해(Decomposition)하거나 결합(Composition)하는 방식이 달라지며, 이를 통해 네 가지 주요 정규화 형식이 정의된다.

정규화 형식 D (NFD): 정준 분해 (Canonical Decomposition) - 문자를 정규 등가성에 따라 분해하며, 여러 개의 결합 문자는 특정 순서로 정렬된다.
정규화 형식 C (NFC): 정준 분해 후 다시 정준 결합 (Canonical Decomposition, followed by Canonical Composition) - 문자를 정규 등가성에 따라 분해한 후 다시 조합한다.
정규화 형식 KD (NFKD): 호환 분해 (Compatibility Decomposition) - 문자를 호환성 등가성에 따라 분해하며, 여러 개의 결합 문자는 특정 순서로 정렬된다.
정규화 형식 KC (NFKC): 호환 분해 후 다시 정준 결합 (Compatibility Decomposition, followed by Canonical Composition) - 문자를 호환성 등가성에 따라 분해한 후 정규 등가성에 따라 다시 조합한다.

유니코드는 각 등가 기준(정규, 호환성)에 대해 두 가지 정규 형식, 즉 결합된 형식(NFC, NFKC)과 분해된 형식(NFD, NFKD)을 제공한다. 이 형식들은 동치 클래스 내에서 특정 대표 원소를 선택하는 방식으로 정의된다. 모든 정규화 형식은 코드 포인트 시퀀스에 대해 정규 순서(Canonical Ordering)를 적용하여 고유한 결과를 보장한다.

소프트웨어는 문자열을 비교하거나 검색할 때 결합 형식(NFC, NFKC) 또는 분해 형식(NFD, NFKD) 중 하나를 일관되게 사용해야 한다. 어떤 형식을 사용하든 동일한 기준 내에서는 결과가 같지만, 정규(NF) 기준과 호환성(NFK) 기준 중 어떤 것을 선택하는지는 검색 결과에 영향을 미칠 수 있다.

예를 들어, 타자기 합자인 'ﬃ'(U+FB03), 로마 숫자 'Ⅸ'(U+2168), 위 첨자 '⁵'(U+2075)와 같은 문자들은 고유한 유니코드 코드 포인트를 가진다. 정규 정규화(NFC, NFD)는 이 문자들을 그대로 두지만, 호환성 정규화(NFKC, NFKD)는 이를 기본 문자로 분해한다. 따라서 'ffi' 합자(U+FB03)를 NFKC로 정규화하면 'f', 'f', 'i' (U+0066, U+0066, U+0069)로 분해되므로, 'f'(U+0066)를 검색하면 NFKC 형식에서는 찾을 수 있지만 NFC 형식에서는 찾을 수 없다. 로마 숫자 'Ⅸ'(U+2168)에서 라틴 문자 'I'(U+0049)를 검색하거나, 위 첨자 '⁵'(U+2075)를 숫자 '5'(U+0035)로 검색하는 경우도 마찬가지이다.

그러나 위 첨자 등을 기본 문자로 변환하는 것은 서식 정보(위 첨자라는 속성)를 잃게 만들기 때문에 리치 텍스트 환경에는 적합하지 않을 수 있다. 이러한 구분을 위해 유니코드 문자 데이터베이스에는 호환성 서식 태그(Compatibility Formatting Tag) 정보가 포함되어 있다.^[1] 예를 들어, 타이포그래피 합자는 `` 태그를, 위 첨자는 `` 태그를 가진다. HTML과 같은 리치 텍스트 표준은 이러한 태그를 고려하여, 예를 들어 숫자 5(U+0035)를 위 첨자로 표시하기 위해 자체 마크업(예: `⁵`)을 사용한다.^[2]

모든 유니코드 정규화 알고리즘은 멱등 변환이다. 즉, 이미 특정 형식으로 정규화된 문자열에 동일한 알고리즘을 다시 적용해도 문자열은 변하지 않는다.

그러나 정규화 형식은 문자열 결합 연산에 대해 닫혀 있지 않다.^[3] 예를 들어, 정규화된 두 문자열을 단순히 이어 붙였을 때 그 결과가 항상 정규화된 상태를 유지하는 것은 아니다. 특히, 한글 모음이나 후행 결합 자모로 시작하는 문자열과 결합할 경우 조합 규칙이 깨질 수 있다.

또한, 정규화는 단사 함수가 아니다. 즉, 서로 다른 원본 문자열이 정규화를 통해 동일한 결과 문자열로 매핑될 수 있다. 예를 들어, 옹스트롬 기호 'Å'(U+212B)와 스웨덴어 문자 'Å'(U+00C5)는 모두 NFD 또는 NFKD 정규화를 거치면 라틴 문자 'A'(U+0041)와 결합 윗점 '°'(U+030A)의 시퀀스로 변환되고, NFC 또는 NFKC 정규화를 거치면 스웨덴어 문자 'Å'(U+00C5)로 변환된다. 이처럼 정보 손실이 발생할 수 있으므로 정규화는 전단사 함수도 아니며, 정규화된 문자열에서 원래의 모든 문자열 정보를 복원할 수는 없다.

유니코드 문자 데이터베이스에서 호환성 필드가 비어 있지 않으면서 특정 호환성 태그가 없는 문자는 정규화 시 다른 문자로 변환될 수 있는 단일 문자(한글 음절 블록 제외)임을 나타낸다.

2. 2. 정규화의 필요성

유니코드 문자열 검색 및 비교 기능을 구현하는 텍스트 처리 소프트웨어는 등가 코드 포인트의 존재를 고려해야 한다. 만약 이러한 고려가 없다면, 사용자가 특정 코드 포인트 순서(예: 완성형 '가')를 검색할 때, 시각적으로는 구별할 수 없지만 다른 코드 포인트 표현(예: 'ㄱ' + 'ㅏ')으로 정규적으로 등가인 다른 글리프를 찾지 못하는 문제가 발생할 수 있다.

정규 등가이거나 정규 등가가 아닌 문자가 함께 존재하면 소프트웨어 사용자에게 시각적인 혼란을 야기할 수 있다. 예를 들어, 소프트웨어는 일반적으로 정규 등가인 문자들을 동일하게 보이도록 처리해야 한다. 하지만 사용자가 한쪽 문자를 검색했을 때, 소프트웨어가 동일한 모양의 다른 등가 문자를 함께 찾아 강조 표시하지 않으면 사용자는 그 이유를 이해하기 어려울 수 있다. 또한, 정규 등가가 아닌 문자 사이에서도 시각적인 모호함이 발생 가능하다. 예를 들어, 유니코드에 별도로 정의된 위 첨자 숫자와, 서식 기능을 이용해 위 첨자로 표시된 일반 숫자가 함께 있을 때 시각적으로 유사하여 혼동을 줄 수 있다.

이러한 문제를 해결하기 위해, 유니코드는 특정 환경에서 이러한 문자 또는 문자열들을 동일하게 처리하도록 텍스트 처리 알고리즘을 유니코드 정규화하는 것을 권장한다. 정규화는 다양한 방식으로 표현될 수 있는 동일 문자를 일관된 형태로 만들어 텍스트 처리의 정확성과 예측 가능성을 높이는 데 필수적이다.

2. 3. 정규화 알고리즘

'''유니코드 정규화'''(Unicode normalization)는 모양이 같은 여러 문자들이 있을 경우 이를 기준에 따라 하나로 통합해 주는 일을 가리킨다. 그 기준으로는 아래 표와 같이 NFD, NFC, NFKD, NFKC가 있다.

제목	묘사
정규화 방식 D (NFD)	정준 분해
정규화 방식 C (NFC)	정준 분해한 뒤에 다시 정준 결합
정규화 방식 KD (NFKD)	호환 분해
정규화 방식 KC (NFKC)	호환 분해한 뒤에 다시 정준 결합

유니코드는 등가인 모든 시퀀스에 대해 고유한 (정규) 코드 포인트 시퀀스를 생성하는 표준 정규화 알고리즘을 제공한다. 등가 기준은 정규(NF) 또는 호환성(NFK)일 수 있다. 동치 클래스의 대표 원소를 임의로 선택할 수 있으므로, 각 등가 기준에 대해 여러 개의 정규 형식이 가능하다. 유니코드는 두 가지 호환성 기준 각각에 대해 의미 있는 두 가지 정규 형식을 제공하는데, 이는 결합된 형식인 NFC와 NFKC, 그리고 분해된 형식인 NFD와 NFKD이다. 결합된 형식과 분해된 형식 모두 코드 포인트 시퀀스에 대한 '''정규 순서'''를 적용하며, 이는 정규 형식이 고유해지기 위해 필요하다.

유니코드 문자열을 비교하거나 검색하기 위해 소프트웨어는 결합된 형식 또는 분해된 형식을 사용할 수 있다. 검색, 비교 등에 관련된 모든 문자열에 대해 동일한 형식을 사용하기만 하면 어떤 형식을 선택하는지는 중요하지 않다. 반면에 등가 기준의 선택은 검색 결과에 영향을 줄 수 있다. 예를 들어, U+FB03(ﬃ)과 같은 일부 타자기 합자나 U+2168(Ⅸ)과 같은 로마 숫자, 그리고 U+2075(⁵)와 같은 유니코드 아래 첨자 및 위 첨자는 자체 유니코드 코드 포인트를 가지고 있다. 정규 정규화(NF)는 이러한 문자들에 영향을 미치지 않지만, 호환성 정규화(NFK)는 'ffi' 합자를 구성하는 문자들로 분해한다. 따라서 U+0066('f')을 부분 문자열로 검색할 경우, U+FB03의 NFKC 정규화에서는 검색에 성공하지만 U+FB03의 NFC 정규화에서는 실패한다. 미리 결합된 로마 숫자 Ⅸ(U+2168)에서 라틴 문자 I(U+0049)를 검색할 때도 마찬가지이다. 또한, 위 첨자 ⁵(U+2075)는 호환성 매핑에 의해 숫자 5(U+0035)로 변환된다.

그러나 위 첨자를 기준선 등가 문자로 변환하는 것은 리치 텍스트 소프트웨어에는 적합하지 않을 수 있는데, 이는 변환 과정에서 위 첨자 정보가 손실되기 때문이다. 이러한 구분을 허용하기 위해 유니코드 문자 데이터베이스에는 호환성 변환에 대한 추가 세부 정보를 제공하는 '''호환성 서식 태그'''가 포함되어 있다.^[1] 타이포그래피 합자의 경우 이 태그는 단순히 ``이고, 위 첨자의 경우 ``이다. HTML과 같은 리치 텍스트 표준은 이러한 호환성 태그를 고려한다. 예를 들어, HTML은 U+0035를 위 첨자 위치에 표시하기 위해 자체 마크업을 사용한다.^[2]

3. 정규 등가의 원인

유니코드는 문자 중복, 결합 문자와 미리 결합된 문자의 존재, 인쇄상 비상호작용 문자의 순서 문제, 그리고 과거 표준과의 호환성 등 다양한 이유로 동일하거나 기능적으로 유사한 문자에 대해 여러 개의 코드 포인트를 할당하는 경우가 있다. 이러한 상황에서 문자 처리의 일관성을 확보하고 데이터 교환 시 발생할 수 있는 문제를 해결하기 위해 정규 등가(Canonical Equivalent^영어) 개념이 도입되었다.

정규 등가는 시각적으로나 기능적으로 동일한 문자들을 같은 것으로 취급하는 등가성의 한 형태로, 예를 들어 미리 합성된 문자와 그것이 분해된 형태(기본 문자와 결합 문자의 조합)는 서로 정규 등가 관계에 있다. 이는 결합 문자와 미리 결합된 문자 섹션에서 더 자세히 다룬다. 유니코드는 이러한 등가 관계를 명확히 정의하여, 어떤 형태의 문자열이든 동일한 의미로 처리될 수 있도록 보장한다. 정규 등가는 정준 등가라고도 불린다.

3. 1. 문자 중복

호환성이나 다른 이유 때문에 유니코드는 본질적으로 같은 문자에 대해 두 개의 다른 코드 포인트를 할당하기도 한다. 예를 들어, "위에 링 디아크리틱이 있는 A"는 U+00C5 (스웨덴어 및 다른 여러 언어의 알파벳 문자) 또는 U+212B(옹스트롬 기호)로 인코딩될 수 있다. 하지만 옹스트롬 기호는 해당 스웨덴 문자로 정의되며, 대부분의 다른 기호(예: 볼트의 V)는 각 사용 사례에 대해 별도의 코드 포인트를 가지지 않는다. 일반적으로, 실제로는 동일한 문자의 코드 포인트들은 정규적으로 동등하게 취급되도록 정의된다.

3. 2. 결합 문자와 미리 결합된 문자

유니코드는 일부 구형 표준과의 호환성을 위해, 다른 문자의 변형된 형태나 둘 이상의 문자가 조합된 형태에 대해 단일 코드 포인트를 부여한다. 예를 들어, "ñ"는 U+00F1, "Å"는 U+00C5라는 고유한 코드 포인트를 가진다. 또한 "ﬀ"와 같은 합자는 U+FB00, 네덜란드 문자인 "IJ"는 U+0132라는 코드 포인트를 갖는다.

이와 더불어 유니코드는 자체적으로 사용되지는 않지만, 앞에 오는 기본 문자를 수정하거나 결합하는 데 사용되는 결합 문자에 대한 코드 포인트도 제공한다. 이는 더 큰 유연성을 제공하기 위함이다. 결합 문자의 예로는 결합 물결표(~)나 일본어의 탁점("◌゛", U+3099) 등이 있다.

유니코드에서는 문자 합성과 문자 분해라는 개념이 중요하다.

문자 합성은 기본 문자와 그 뒤에 오는 하나 이상의 결합 문자를 합쳐서, 해당하는 단일 미리 결합된 문자의 코드 포인트로 바꾸는 과정이다.
문자 분해는 반대로 미리 결합된 문자를 기본 문자와 결합 문자의 조합으로 나누는 과정이다.

일반적으로 미리 결합된 문자는 기본 문자와 그 뒤에 오는 결합 분음 부호의 순서와 정규적으로 동일하게 정의되며, 이 순서는 중요하지 않다.
정준 등가(Canonical Equivalent|정준 등가^영어)는 시각적으로나 기능적으로 동일한 문자를 같은 것으로 취급하는, 더 엄격한 형태의 등가성이다. 예를 들어, 분음 부호가 포함된 미리 결합된 문자 'ü'는 분해하면 기본 문자인 'u'와 결합 문자인 분음 기호 '¨'의 조합으로 나뉘지만, 'ü'와 'u' + '¨'는 서로 정준 등가 관계에 있다. 즉, 두 표현 방식 모두 동일하게 간주된다. 유니코드는 또한 일부 그리스 문자의 분음 부호나 구두점을 모양이 같은 다른 분음 부호와 통합하여 처리하는데, 이 역시 정준 등가성의 개념을 활용한 것이다. 정준 등가는 정규 등가로 표기되기도 한다.

3. 3. 인쇄상의 비상호작용

일부 문자 체계에서는 여러 개의 결합 문자를 정기적으로 사용하는데, 이 문자들은 일반적으로 인쇄 시 서로 영향을 주지 않으며(인쇄상의 비상호작용), 해당 조합을 위한 사전 구성 문자가 없는 경우가 있다. 이렇게 서로 영향을 주지 않는 결합 문자 쌍은 어떤 순서로든 저장될 수 있다. 이러한 순서가 다른 시퀀스들은 일반적으로 정규 동등성을 가진다. 정규 형식에서 문자 순서를 정하는 규칙은 이 문자들의 상호작용 여부도 함께 정의한다.

3. 4. 인쇄상의 규약

유니코드는 미적인 이유만으로 형태가 변형된 일부 문자나 문자 그룹에 대해 별도의 코드 포인트를 할당한다. 예를 들어 여러 글자를 하나로 합친 합자, 폭이 좁거나 넓은 반각 가타카나나 전각 라틴 문자, 그리고 원래 의미는 유지하면서 추가적인 의미(주로 시각적 표현)를 부여하는 아래 첨자나 위 첨자 숫자, 원 안에 넣은 숫자(예: ①) 등이 여기에 해당한다.

이러한 문자들은 원래의 문자(개별적이고 수정되지 않은 형태)와 호환 등가(互換等価, Compatibility Equivalent^eng)인 것으로 간주된다. 즉, 외형이나 추가된 의미가 중요하지 않은 응용 프로그램에서는 동일하게 취급될 수 있다는 의미이다. 하지만 이들은 정규 등가는 아니다. 왜냐하면 이러한 형태적 구별이 어느 정도의 의미론적 가치를 가지며, 텍스트 렌더링에 영향을 미치기 때문이다.

호환 등가는 정규 등가보다 더 넓은 개념이다. 정규 등가인 모든 문자는 호환 등가이기도 하지만, 그 반대는 성립하지 않을 수 있다. 정규 등가가 아닌 호환 등가 문자들은 주로 플레인 텍스트 환경에서의 등가성을 고려한 것으로, 때로는 의미적으로 다른 형태를 가질 수 있다. 예를 들어, 위 첨자나 아래 첨자 숫자는 일반 숫자와 호환 등가이지만, 첨자 형태는 시각적인 차이를 통해 다른 의미를 전달하기도 한다. 유니코드는 이러한 시각적, 의미적 변화를 표현하는 것은 플레인 텍스트가 아닌 리치 텍스트 프로토콜의 역할이라고 본다. 예를 들어, 유니코드에 포함된 아래 첨자 숫자는 0부터 9까지뿐이지만, 리치 텍스트 환경에서는 다른 문자도 아래 첨자로 만들 수 있다.

마찬가지로 전각 문자와 반각 가타카나 문자도 호환 등가이며, 합자와 그 구성 요소가 되는 문자들의 나열도 호환 등가 관계이다. 합자의 경우, 대개 시각적인 차이만 있을 뿐 의미적인 구별은 없다. 즉, 특정 글꼴이나 디자인 환경에서 합자를 사용하는 것은 주로 시각적인 조판 디자인의 선택일 뿐, 합자 자체가 특별한 의미를 나타내는 경우는 드물다.

유니코드는 호환성 정규화(NFKC, NFKD)를 통해 이러한 호환 등가 문자들을 기본적인 형태로 분해할 수 있다. 예를 들어, 호환성 정규화를 적용하면 합자 'ﬃ'(U+FB03)는 'f', 'f', 'i' (U+0066, U+0066, U+0069)로 분해되고, 로마 숫자 'Ⅸ'(U+2168)는 'I', 'X' (U+0049, U+0058)로, 위 첨자 '⁵'(U+2075)는 숫자 '5'(U+0035)로 변환된다. 이러한 변환은 특정 문자열 검색 시 유용할 수 있다. 예를 들어, 'f'를 검색하면 NFKC 정규화된 'ﬃ'에서는 'f'를 찾을 수 있지만, NFC 정규화된 'ﬃ'에서는 찾을 수 없다.

그러나 위 첨자를 일반 숫자로 변환하는 등의 호환성 정규화는 리치 텍스트 소프트웨어에는 적합하지 않을 수 있다. 이 과정에서 위 첨자라는 서식 정보가 손실되기 때문이다. 이러한 구분을 위해 유니코드 문자 데이터베이스에는 호환성 변환에 대한 추가 정보를 제공하는 호환성 서식 태그가 포함되어 있다.^[1] 예를 들어, 타이포그래피 합자에는 `` 태그가, 위 첨자에는 `` 태그가 부여된다. HTML과 같은 리치 텍스트 표준은 이러한 태그를 고려하여, 예를 들어 숫자 5를 위 첨자로 표시하기 위해 자체적인 마크업을 사용한다.^[2]

3. 5. 인코딩 오류

UTF-8 및 UTF-16 (그리고 일부 다른 유니코드 인코딩)은 모든 가능한 코드 유닛 시퀀스를 허용하지 않는다. 서로 다른 소프트웨어는 유효하지 않은 시퀀스를 다양한 규칙을 사용하여 유니코드 문자로 변환하며, 이 중 일부는 매우 손실이 클 수 있다(예: 모든 유효하지 않은 시퀀스를 동일한 문자로 변환). 이는 일종의 정규화로 간주될 수 있으며 다른 정규화와 동일한 어려움을 초래할 수 있다.

4. 정규화 형식의 예시

다음 표는 '아멜리에'(Amélie^fra)라는 단어를 예시로 들어, 동일한 문자열이 정규화 형식 NFC와 NFD에서 어떻게 다른 유니코드 코드 포인트로 표현될 수 있는지 보여준다. 이 두 형식은 정규적으로 등가이다.

두 개의 정규적으로 등가인 유니코드 형태(NFC와 NFD)를 가진 ''아멜리에''
NFC 문자	A	m	é		l	i	e
NFC 코드 포인트	0041	006d	00e9		006c	0069	0065
NFD 코드 포인트	0041	006d	0065	0301	006c	0069	0065
NFD 문자	A	m	e	◌́	l	i	e

4. 1. NFD (정규화 형식 정규 분해)

NFD는 코드를 정준 분해하는 정규화 방식이다. 주요 변환 규칙은 다음과 같다.

발음 구별 기호 분리: 발음 구별 기호가 붙어 하나의 문자로 처리된 경우, 이를 기본 문자와 기호로 분리한다.
'''À''' (U+00C0) → '''A''' (U+0041) + '''◌̀''' (U+0300)
'''ệ''' (U+1EC7) → '''e''' (U+0065) + '''◌̂''' (U+0302) + '''◌̣''' (U+0323)
'''が''' (U+304C) → '''か''' (U+304B) + '''◌゙''' (U+3099)
'''ポ''' (U+30DD) → '''ホ''' (U+30DB) + '''◌゚''' (U+309A)
'''Й''' (U+0419) → '''И''' (U+0418) + '''◌̆''' (U+0306)
한글 처리: 한글 소리마디 영역(U+AC00~U+D7A3)으로 작성된 한글을 첫가끝 코드로 변환한다.
'''위''' (U+C704) → '''ᄋ''' (U+110B) + '''ᅱ''' (U+1171)
'''한''' (U+D55C) → '''ᄒ''' (U+1112) + '''ᅡ''' (U+1161) + '''ᆫ''' (U+11AB)
조합 순서 조정: 표준과 다른 순서로 조합된 문자들을 올바른 순서로 맞춘다.
'''e''' (U+0071) + '''◌̇''' (U+0307) + '''◌̣''' (U+0323) → '''e''' (U+0071) + '''◌̣''' (U+0323) + '''◌̇''' (U+0307)

4. 2. NFC (정규화 형식 정규 조합)

코드를 정준 분해한 뒤에 다시 정준 결합하는 방식이다.

발음 구별 기호(조합 분음 기호: U+0300~U+036F)가 잇따라 붙었을 경우, 이를 코드 하나로 처리한다.
'''A''' (U+0041) + '''◌̀''' (U+0300) → '''À''' (U+00C0)
'''e''' (U+0065) + '''◌̂''' (U+0302) + '''◌̣''' (U+0323) → '''ệ''' (U+1EC7)
'''か''' (U+304B) + '''◌゙''' (U+3099) → '''が''' (U+304C)
'''ホ''' (U+30DB) + '''◌゚''' (U+309A) → '''ポ''' (U+30DD)
'''И''' (U+0418) + '''◌̆''' (U+0306) → '''Й''' (U+0419)
한글을 첫가끝 코드로 썼을 경우, 이를 한글 소리마디 영역(U+AC00~U+D7A3)으로 처리한다.
'''ᄋ''' (U+110B) + '''ᅱ''' (U+1171) → '''위''' (U+C704)
'''ᄒ''' (U+1112) + '''ᅡ''' (U+1161) + '''ᆫ''' (U+11AB) → '''한''' (U+D55C)
'''ᄃ''' (U+1103) + '''ᅲ''' (U+1172) + '''ᇰ''' (U+11F0) → '''듀''' (U+B4C0) + '''ᇰ''' (U+11F0) - 종성을 뺀 초성과 중성까지만 변환할 수 있는 경우, 알고리듬에 따라 거기까지만 변환한다.^[6]
대한민국 산업 표준 KS X 1026-1은 '현대 한글 초성 + 현대 한글 중성 + 옛한글 종성'으로 이루어진 옛한글 완성자를 표현할 때 현대 한글 완성자를 사용하지 말고 첫가끝 한글 낱자들만을 사용할 것을 요구한다.

4. 3. NFKD (정규화 형식 호환 분해)

NFKD는 정규화 형식 호환 분해(Normalization Form Compatibility Decomposition^eng)를 의미한다. 문자는 호환 등가성에 의해 분해되며, 여러 개의 결합 문자는 특정 순서로 정렬된다.

주요 변환 예시는 다음과 같다.

합자 처리된 알파벳 코드를 각 알파벳으로 분해한다.
* '''ﬁ''' (U+FB01) → '''f''' (U+0066) + '''i''' (U+0069)
옛 알파벳을 현대 알파벳으로 바꾼다.
* '''ſ''' (U+017F) → '''s''' (U+0073)
* '''ẛ''' (U+1E9B) → '''s''' (U+0073) + '''◌̇''' (U+0307)

호환 등가는 정규 등가보다 더 넓은 개념이다. 정규 등가가 아닌 호환 등가 문자들은 플레인 텍스트에서의 등가성을 고려하며, 이 때문에 의미적으로 다른 형태를 가질 수 있다. 예를 들어, 윗첨자나 아랫첨자 숫자는 일반 숫자와 호환 등가이지만, 시각적 차이를 통해 다른 의미를 전달할 수 있다. 유니코드는 이러한 시각적, 의미적 변화를 표현하는 것은 상위의 리치 텍스트 프로토콜의 역할로 간주한다. 전각과 반각 가타카나 문자, 합자와 그 구성 요소 문자 배열 등도 호환 등가 관계에 해당한다.

NFKD 정규화는 검색 결과에 영향을 줄 수 있다. 예를 들어, 일부 타자기 합자(예: U+FB03, ﬃ)나 로마 숫자(예: U+2168, Ⅸ), 위 첨자(예: U+2075, ⁵) 등은 자체 유니코드 코드 포인트를 가진다. 정규 정규화(NFC, NFD)는 이들에 영향을 주지 않지만, 호환성 정규화(NFKC, NFKD)는 이들을 분해하거나 변환한다. 따라서 'f'를 검색할 때, 'ﬃ'(U+FB03)는 NFKD(또는 NFKC) 정규화된 상태에서는 검색되지만, NFC 정규화 상태에서는 검색되지 않는다. 마찬가지로 로마 숫자 Ⅸ(U+2168)에서 라틴 문자 I(U+0049)를 검색하거나, 위 첨자 ⁵(U+2075)가 호환성 매핑에 의해 5(U+0035)로 변환되는 경우도 있다.

그러나 위 첨자를 일반 문자로 변환하는 것은 위 첨자 정보가 손실될 수 있으므로 리치 텍스트 소프트웨어에는 적합하지 않을 수 있다. 이러한 구분을 위해 유니코드 문자 데이터베이스에는 호환성 변환에 대한 세부 정보를 제공하는 '''호환성 서식 태그'''가 포함되어 있다.^[1] 예를 들어, 타이포그래피 합자는 `` 태그를, 위 첨자는 `` 태그를 가진다. HTML과 같은 리치 텍스트 표준은 이러한 태그를 고려하여, 예를 들어 U+0035를 위 첨자 위치에 표시하기 위해 자체 마크업을 사용한다.^[2]

4. 4. NFKC (정규화 형식 호환 조합)

NFKC(Normalization Form Compatibility Composition^eng)는 유니코드 문자열을 정규화하는 방식 중 하나로, 먼저 문자열을 호환 등가성(Compatibility Equivalent^eng)을 기준으로 분해한 뒤, 다시 정준 등가성을 기준으로 결합하는 과정을 거친다. 유니코드 표준에서는 이 과정을 "문자는 호환성에 의해 분해된 다음 정규 등가성에 의해 재조합됩니다"라고 설명한다.

호환 분해 단계(NFKD)에서는 시각적 표현이나 과거 시스템과의 호환성을 위해 별도의 코드로 존재하는 문자들을 의미상 동일한 기본적인 문자로 변환한다.

합자 'ﬁ'(U+FB01) → 'f'(U+0066) + 'i'(U+0069)
로마 숫자 'Ⅸ'(U+2168) → 'I'(U+0049) + 'X'(U+0058)
윗첨자 숫자 '⁵'(U+2075) → 일반 숫자 '5'(U+0035)
발음 구별 기호가 포함된 옛 알파벳 'ẛ'(U+1E9B) → 's'(U+0073) + 윗점 '◌̇'(U+0307)

그 다음 정준 결합 단계에서는 NFC와 동일한 규칙에 따라, 분해된 문자들을 가능한 한 미리 조합된 단일 문자로 합친다.

's'(U+0073) + '◌̇'(U+0307) → 'ṡ'(U+1E61)

따라서 'ẛ'(U+1E9B)의 최종 NFKC 정규화 결과는 'ṡ'(U+1E61)가 된다.

'''ẛ''' (U+1E9B) → '''s''' (U+0073) + '''◌̇''' (U+0307) (호환 분해) → '''ṡ''' (U+1E61) (정준 결합)

하지만 모든 호환 분해 결과가 다시 결합되는 것은 아니다. 예를 들어, 합자 'ﬁ'(U+FB01)는 'f' + 'i'로 분해된 후 더 이상 결합될 문자가 없으므로 NFKC 결과는 'f' + 'i'가 된다. 마찬가지로 로마 숫자 'Ⅸ'(U+2168)의 NFKC 결과는 'I' + 'X'이고, 윗첨자 '⁵'(U+2075)의 NFKC 결과는 '5'이다.

NFKC 정규화는 문자열 검색 등에서 유용하게 사용될 수 있다. 예를 들어, 'ffi'라는 문자열을 검색할 때, 원본 텍스트에 합자 'ﬃ'(U+FB03)가 포함되어 있더라도 NFKC 정규화를 적용하면 'f' + 'f' + 'i'로 변환되므로 검색에 성공할 수 있다. 이는 NFC 정규화만으로는 불가능하다.

그러나 NFKC는 윗첨자, 아랫첨자, 합자 등 원래 문자가 가진 시각적 또는 의미적 서식 정보를 제거할 수 있다는 점에 유의해야 한다. 이러한 정보 손실은 리치 텍스트와 같이 서식 유지가 중요한 환경에서는 문제가 될 수 있다.^[1]^[2] 예를 들어, 윗첨자 '⁵'를 일반 숫자 '5'로 변환하면 윗첨자라는 고유한 의미나 시각적 표현이 사라지게 된다.

4. 5. 모든 기준에서의 공통된 정규화

한중일 호환용 한자를 한중일 통합 한자로 처리한다.
* '''樂''' (U+F914), '''樂''' (U+F95C), '''樂''' (U+F9BF) → '''樂''' (U+6A02)
전용 기호를 모양이 같은 보편적인 기호로 바꾼다.
* '''Ω''' (U+2126, 옴 기호) → '''Ω''' (U+03A9, 오메가)

5. 정규 순서

정규 순서 지정은 주로 결합 문자의 순서 지정과 관련이 있다. 이 절의 예시에서는 이러한 문자가 분음 부호라고 가정하지만, 일반적으로 일부 분음 부호는 결합 문자가 아니고, 일부 결합 문자는 분음 부호가 아니다.

유니코드는 각 문자에 숫자 값으로 식별되는 '''결합 클래스'''(Combining Class)를 할당한다. 결합하지 않는 문자는 클래스 번호 0을 가지며, 결합하는 문자는 양(+)의 결합 클래스 값을 가진다. 정규 순서를 얻으려면, 0이 아닌 결합 클래스 값을 가진 문자로 이루어진 모든 하위 문자열을 안정 정렬(stable sort) 알고리즘을 사용하여 결합 클래스 값에 따라 정렬해야 한다. 안정 정렬이 필요한 이유는 동일한 클래스 값을 가진 결합 문자끼리는 활자적으로 상호 작용한다고 가정하기 때문이며, 따라서 두 문자의 순서가 바뀌면 동일한 것으로 간주하지 않는다.

예를 들어, 베트남어 알파벳에서 사용되는 문자 U+1EBF (ế)는 급성 악센트와 곡절 악센트를 모두 가지고 있다. 이 문자의 정규 분해는 세 문자 시퀀스 U+0065 (e) U+0302 (곡절 악센트) U+0301 (급성 악센트)이다. 두 악센트의 결합 클래스는 모두 230으로 같다. 따라서 U+1EBF는 악센트 순서가 다른 U+0065 U+0301 U+0302 시퀀스와 동일하지 않다.

모든 결합 시퀀스가 미리 조합된 형태의 동등한 문자(이전 예제의 마지막 시퀀스는 U+00E9 U+0302로만 축소될 수 있음)를 가지는 것은 아니다. 이러한 이유로, 정규화 형식 NFC(Normalization Form Canonical Composition)조차도 결합 문자의 순서와 동작에 영향을 받는다.

6. 정규화 차이로 인한 오류

두 애플리케이션이 유니코드 데이터를 공유하지만 서로 다른 방식으로 정규화하는 경우, 오류나 데이터 손실이 발생할 수 있다.^[4]^[5] 한 가지 구체적인 사례로, 과거 OS X는 Netatalk 및 Samba 파일 및 프린터 공유 소프트웨어에서 전송된 유니코드 파일 이름을 자체적으로 정규화했다. 이 과정에서 Netatalk와 Samba는 변경된 파일 이름을 원본과 동일한 것으로 인식하지 못하여 데이터 손실을 초래하는 문제가 있었다.^[4]^[5] 이러한 문제를 해결하는 것은 정규화 과정이 원래대로 되돌리기 어려운 비가역적인 특성을 가지기 때문에 간단하지 않다.

7. 정준 등가와 호환 등가

'''정준 등가'''(Canonical Equivalent^eng)는 시각적 및 기능적으로 등가인 문자를 보존하는, 더 좁은 형태의 등가성이다. 예를 들어, 분음 부호를 가진 합성된 문자 'ü'는 분해된 형태인 'u'와 결합 문자 분음 기호 '¨'를 나열한 것과 정준 등가로 간주된다. 마찬가지로, 유니코드는 일부 그리스 문자의 분음 부호와 구두점을 같은 모양의 다른 분음 부호로 통합하는데, 이들도 정준 등가 관계이다. 때로는 '''정규 등가'''라고도 부른다.

'''호환 등가'''(Compatibility Equivalent^eng)는 정준 등가보다 더 넓은 개념이다. 정준 등가인 모든 문자는 호환 등가이기도 하지만, 그 반대는 항상 성립하지 않는다. 정준 등가가 아닌 호환 등가 문자들은 플레인 텍스트에서 등가로 취급될 때 주의가 필요한데, 이는 이들이 의미적으로 다른 형태를 가질 수 있기 때문이다. 예를 들어, 윗첨자나 아랫첨자 숫자는 해당하는 일반 숫자와 호환 등가이지만, 첨자 형태는 시각적 차이를 통해 다른 의미를 전달하는 경우가 많다. 유니코드는 이러한 의미 차이를 표현하는 것은 상위의 리치 텍스트 프로토콜의 역할로 본다.^[1] 전각 문자와 반각 가타카나 문자도 호환 등가이며, 합자(예: ﬃ)와 이를 구성하는 문자열('f', 'f', 'i')도 마찬가지이다. 합자의 경우 보통 시각적인 차이만 있을 뿐 의미적 구별은 없는 경우가 많으며, 이는 주로 조판 디자인의 선택 문제이다.^[2] 로마 숫자(예: Ⅸ)와 이를 구성하는 라틴 문자('I', 'X')도 호환 등가 관계이다.

8. 시각적 모호성

정규적으로 등가이거나 등가가 아닌 문자가 존재하면 텍스트 처리 소프트웨어 사용자에게 시각적인 모호함과 혼란을 줄 수 있다. 예를 들어, 소프트웨어는 일반적으로 정규 등가인 문자를 서로 구별할 수 없도록 화면에 표시해야 한다. 하지만 사용자가 특정 문자를 검색할 때, 소프트웨어가 동일하게 보이는 다른 문자를 함께 찾아주지 않으면 혼란스러울 수 있다. 정규 등가가 아닌 문자 사이에서도 시각적인 모호함이 발생할 수 있다. 예를 들어, 처음부터 위 첨자로 디자인된 숫자와, 일반 숫자를 서식을 이용해 위 첨자로 표시한 경우가 나란히 있을 때 구별하기 어려울 수 있다. 이러한 문제를 해결하기 위해, 유니코드는 특정 환경에서 이러한 문자나 문자열을 동일하게 취급하도록 알고리즘을 정규화하는 텍스트 처리 방식을 권장한다.

참조

_[1] 웹사이트 UAX #44: Unicode Character Database https://www.unicode.[...] Unicode.org 2014-11-20
_[2] 웹사이트 Unicode in XML and other Markup Languages http://unicode.org/r[...] Unicode.org 2014-11-20
_[3] 웹사이트 What should be done about concatenation http://www.unicode.o[...]
_[4] 웹사이트 netatalk / Bugs / #349 volcharset:UTF8 doesn't work from Mac http://sourceforge.n[...] 2014-11-20
_[5] 웹사이트 rsync, samba, UTF8, international characters, oh my! http://forums.macosx[...]
_[6] 저널 The Unicode Standard Core Specification, Chapter 3. Conformance http://www.unicode.o[...] The Unicode Consortium 2014-07-16

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com