유니코드(Unicode) - Part 1

배경

Db2 for i의 기본 코드 체계는 EBCDIC 으로 되어 있습니다. 

하지만, 다양한 플랫폼, 언어, 프로그램과 데이터를 주고 받기 위해 유니코드를 사용하는 환경이 늘어나고 있고, 다양한 문자를 지원해야 하는 상황으로 인해 지원되지 않는 문자 인코딩으로 인한 문제도 종종 발생하고 있습니다. 이를 해결할 수 있는 방법이 유니코드로의 전환인데요. 이번 글에서는 Db2 for i에서 유니코드를 사용하기 위해 알아야 할 기초적인 내용들을 정리해보았습니다.

 

유니코드에 대한 기본 개념

유니코드는 플랫폼, 언어 또는 프로그램에 관계없이 모든 문자에 대해 고유 번호를 제공합니다. 유니코드를 사용하면 다양한 플랫폼, 언어 및 국가에서 작동하는 소프트웨어 제품을 개발할 수 있습니다. 또한 유니코드를 사용하면 다양한 시스템을 통해 데이터를 전송할 수 있습니다. 최신 시스템은 유니코드를 기반으로 하는 국제화 솔루션을 제공합니다.

유니코드는 전 세계 공통 언어에 대한 지원을 포함하는 단일 코드 문자 집합으로 개발되었습니다. 유니코드의 첫 번째 버전은 복잡한 멀티바이트 체계 없이 65,536개의 문자를 인코딩할 수 있는 16비트 숫자를 사용했습니다. 더 많은 문자가 포함되고 다양한 플랫폼의 구현 요구 사항에 따라 유니코드가 확장되어 100만 문자 이상을 허용합니다. 또한 UTF-8, UTF-16 및 UTF-32와 같은 다른 인코딩 체계가 추가되었습니다. 이것은 유니코드 표준에 더 많은 복잡성을 도입했지만 많은 다른 인코딩을 관리하는 것보다 훨씬 적습니다.

원래 유니코드 레퍼토리는 컴퓨팅에서 일반적으로 사용되는 모든 주요 언어를 다룹니다. 유니코드는 계속 성장하고 있으며 더 많은 스크립트를 포함하고 있습니다.

유니코드의 디자인은 전통적인 문자 집합 및 인코딩 체계와 몇 가지 면에서 다릅니다.

• 레퍼토리를 통해 사용자는 단일 문서 내에 거의 모든 언어로 된 텍스트를 효율적으로 포함할 수 있습니다.
• 문자당 하나 이상의 바이트로 바이트 기반 방식으로 인코딩할 수 있지만 기본 인코딩 체계는 모든 공통 문자에 대해 훨씬 더 간단한 처리를 허용하는 16비트 단위를 사용합니다.
• 악센트와 움라우트가 있는 문자와 같은 많은 문자는 기본 문자와 악센트 또는 움라우트 수정자에서 결합될 수 있습니다. 이 결합은 개별적으로 인코딩해야 하는 서로 다른 문자의 수를 줄입니다. 호환성을 위해 당시 공통 문자 세트에 존재했던 문자에 대해 사전 구성된 변형이 포함되었습니다. 

문자와 사용법이 잘 정의되고 설명되어 있습니다. 전통적인 문자 집합은 일반적으로 문자의 이름이나 그림, 숫자 및 바이트 인코딩만 제공합니다. 유니코드에는 사용 가능한 속성의 포괄적인 데이터베이스가 있습니다. 또한 상호 운용성을 높이기 위해 텍스트 처리의 여러 측면을 처리하기 위한 여러 프로세스 및 알고리즘을 정의합니다.

일반적으로 사용되는 문자 집합의 모든 문자를 초기에 포함하면 유니코드가 기존 문자 집합 간 변환에 유용한 메커니즘이 되며 먼저 텍스트를 유니코드로 변환하고 처리한 다음 다시 다시 변환하여 유니코드가 아닌 텍스트를 처리할 수 있습니다. 데이터 손실 없이 원본 인코딩으로 변환합니다.

 

유니코드를 사용하는 이유

유니코드에는 많은 유리한 기능이 있습니다.

운영 체제는 다국어 지원을 제공합니다. 유니코드는 사용자가 선택한 국가 언어로 데이터를 단일 파일에 저장하고 검색하는 수단을 제공하므로 입력 장치의 언어에 관계없이 모든 텍스트 요구 사항을 지원하는 하나의 데이터베이스 파일을 제공합니다. 예를 들어 동일한 부품 파일에 한국어, 일본어, 중국어 및 영어 설명과 이름이 있을 수 있습니다.

 

유니코드의 다양한 인코딩

유니코드 표준에는 유니코드 값을 인코딩할 수 있는 몇 가지 주요 방법이 있습니다. UTF-8, UTF-16 및 UTF-32입니다. UTF(Unicode Transformation Format)는 모든 유니코드 값에서 고유한 바이트 시퀀스로의 알고리즘 매핑입니다.

• UTF-8
  UTF-8은 수학적 알고리즘을 통해 유니코드 데이터를 변환하므로 UTF-8은 8 데이터 비트를 사용하여 데이터를 인코딩하고 00에서 7F까지의 모든 ASCII 코드를 자체적으로 인코딩하고 의도한 문자인 경우에만 null을 포함합니다.
  
  예를 들어 유니코드의 문자열 "ABC"는 "004100420043"x입니다. 그러나 UTF-8에서는 "414243"입니다.
  
  UTF-8을 사용하면 네트워크에서 유니코드인지 알 필요 없이 유니코드 데이터가 8비트 네트워크를 통해 흐를 수 있으므로 UTF-8은 여러 UNIX 플랫폼에서 유니코드를 저장하는 데 사용되며 대부분의 새로운 인터넷 표준에 대한 기본 인코딩으로 사용됩니다. 
  
  UTF-8은 주로 모두 8비트 코드 단위를 사용하는 이전 MBCS 인코딩을 직접 대체하는 데 사용되지만 이를 처리하려면 코드가 더 필요합니다. 모든 영문자는 1바이트만 사용하므로 데이터의 90%가 영어이면 좋은 인코딩입니다.
  
  IBM® i 운영 체제는 CCSID 1208로 UTF-8 인코딩을 지원합니다 . IBM i V5R3 부터 CCSID 1208이 데이터베이스에서 지원됩니다.
• UTF-16
  UTF-16은 각 문자가 하나 또는 두 개의 16비트 요소로 구성되는 유니코드 인코딩입니다.유니코드는 원래 모든 최신 스크립트를 나타내는 것을 목표로 하는 순수한 16비트 인코딩으로 설계되었습니다. 시간이 지남에 따라, 특히 확립된 집합과의 호환성을 위해 14,500개 이상의 복합 문자를 추가한 후 대부분의 사용자에게 16비트로는 충분하지 않다는 것이 분명해졌습니다. 이 중 UTF-16이 생겼습니다.
  
  UTF-16은 단일 유니코드 16비트 단위로 약 60,000자에 대한 액세스를 허용합니다. 대리 쌍으로 알려진 메커니즘을 통해 추가 1,000,000자에 액세스할 수 있습니다.
  
  유니코드 코드 값의 두 범위는 이러한 쌍의 높은(첫 번째) 값과 낮은(두 번째) 값을 위해 예약되어 있습니다. 최고치는 0xD800에서 0xDBFF까지이고 최저치는 0xDC00에서 0xDFFF까지입니다. 가장 일반적인 문자는 이미 처음 64,000개의 값으로 인코딩되었기 때문에 서로게이트 쌍이 필요한 문자는 상대적으로 드뭅니다.
  
  UTF-16은 처리와 공간 간의 최상의 절충안으로 매우 잘 설계되었으며 일반적으로 사용되는 모든 문자는 코드 포인트당 하나의 코드 단위로 저장할 수 있습니다. 유니코드의 기본 인코딩입니다.
  
  IBM® i 운영 체제는 CCSID 1200(및 CCSID 13488)을 사용하는 UTF-16 인코딩을 지원합니다. IBM i V5R3 부터 CCSID 1200이 데이터베이스에서 지원됩니다. CCSID 13488은 여러 릴리스의 데이터베이스에서 지원되었습니다.
  
  유니코드의 초기 버전인 UCS-2 표준은 65,535자로 제한됩니다. 그러나 데이터 처리 산업에서는 94,000자 이상이 필요합니다. UCS-2 표준은 유니코드 UTF-16 표준으로 대체되었습니다.
  
  IBM® i 운영 체제는 UCS-2로 정의된 CCSID 13488 및 UTF-16으로 정의된 CCSID 1200을 지원합니다. 시스템은 CCSID 13488 및 CCSID 1200을 모두 UTF-16 인코딩으로 처리합니다.
  
  두 구성표를 사용하면 거의 모든 시스템 작업에 대해 동일한 결과를 얻을 수 있습니다. 그러나 SQL 표준에 의해 정의된 문자 경계에서 작동하는 특정 SQL 함수는 다른 결과를 생성할 수 있습니다. 예를 들어 CHARACTER, LENGTH, POSITION 및 SUBSTRING의 SQL 함수는 UTF-16과 UCS-2를 구분하므로 다른 결과를 얻을 수 있습니다. 
  
  
  
• UTF-32
  UTF-32는 각 문자가 4바이트로 구성된 유니코드 인코딩입니다.
  
  IBM® i 운영 체제는 CCSID 값이 있는 UTF-32 인코딩을 지원하지 않습니다.
  
  유니코드는 원래 모든 최신 스크립트를 나타내는 것을 목표로 하는 순수한 16비트 인코딩으로 설계되었습니다. 시간이 지남에 따라, 특히 확립된 집합과의 호환성을 위해 14,500개 이상의 복합 문자를 추가한 후 많은 사용자에게 16비트가 충분하지 않다는 것이 분명해졌습니다. 이 중 UTF-32가 생겼습니다.
  
  UTF-32를 사용하면 00000000에서 0010FFFF까지의 모든 코드 포인트에서 문자를 4바이트로 인코딩할 수 있습니다. 예를 들어 UTF-32의 문자열 ABC는 x"000000410000004200000043" 로 인코딩됩니다.

 

유니코드와 ASCII 및 EBCDIC 같은 이전 표준과의 관계

유니코드 표준은 다른 표준보다 유리합니다. 전역화된 응용 프로그램에서 문자 데이터를 처리하는 복잡성을 줄일 수 있습니다.

제한된 플랫폼을 기반으로 진화하는 표준

최신 컴퓨터 시스템에서 문자 데이터의 표현은 전역화된 응용 프로그램의 요구 사항에 따라 상당히 복잡할 수 있습니다. 이러한 복잡성의 이유 중 하나는 이 데이터를 처리하는 방법이 덜 복잡한 환경 및 하드웨어 플랫폼을 제공하는 초기 방법에서 발전했기 때문입니다.

실제로 시스템에서 문자를 인코딩하는 방법에 대한 많은 초기 결정은 초기 Telex(TTY) 터미널 및 펀치 카드 기술과 같은 특정 장치의 기능 요구 사항에 따라 결정되었습니다. 예를 들어, 열을 무시해야 함을 나타내기 위해 천공 카드의 열에 있는 모든 구멍을 펀치 아웃하려면 삭제 문자(ASCII 값 x'7F' 포함)가 필요했습니다. 이러한 초기 컴퓨팅 시스템의 저장 용량은 시스템 및 응용 프로그램 설계자에게 추가적인 제한을 두었습니다.

이러한 초기 시스템에서 성장한 문자 인코딩 체계는 다음과 같은 역사적 토대 위에 구축되었습니다.

• ASCII(정보 교환을 위한 미국 표준 코드) 문자 집합은 7비트 바이트용으로 설계된 사소한 인코딩과 함께 7비트 단위를 사용합니다. 매우 적은 수의 문자로 제한되어 있음에도 불구하고 오늘날 사용되는 가장 중요한 문자 집합입니다. 그 디자인이 대부분의 최신 문자 집합의 기초이기 때문입니다. ASCII는 128개의 숫자 값만 제공하며 그 중 33개는 특수 기능용으로 예약되어 있습니다.
• EBCDIC(Extended Binary-Coded Decimal Interchange Code) 문자 집합 및 IBM이 메인프레임용으로 설계한 여러 관련 문자 집합은 8비트 바이트를 사용합니다. ASCII와 비슷한 시기에 개발되었으며 동일한 기본 문자 집합을 공유하고 다른 유사한 속성을 가집니다. ASCII와 달리 라틴 문자는 대문자와 소문자에 대해 두 블록으로 결합되지 않습니다. 대신 문자는 16진수 값이 1에서 9까지의 두 번째 숫자를 갖도록 배열됩니다(펀치 카드 친화적인 또 다른 디자인).

역사적 단순성은 현대적 복잡성을 만듭니다

초기 문자 집합의 물리적 및 기능적 제한은 하드웨어 및 기능적 기능을 빠르게 확장하는 데 자리를 내주었습니다. 컴퓨팅 시스템의 문자 표현은 하드웨어에 덜 의존하게 되었습니다. 대신 소프트웨어 설계자는 기존 인코딩 체계를 사용하여 점점 더 글로벌화되는 컴퓨터 사용자 커뮤니티의 요구를 수용했습니다.

많은 문자에 대한 문자 집합

가장 일반적인 인코딩(문자 인코딩 체계)은 문자당 1바이트를 사용하며 종종 1바이트 문자 집합(SBCS)이라고 합니다. 모두 256자로 제한됩니다. 이 때문에 그들 중 어느 것도 서유럽 언어의 모든 악센트 문자를 다룰 수 없습니다. 결과적으로 다양한 사용자 커뮤니티의 요구 사항을 충족하기 위해 시간이 지남에 따라 다양한 인코딩이 생성되었습니다. ASCII 다음으로 오늘날 가장 널리 사용되는 SBCS 인코딩은 ISO-8859-1입니다. ASCII의 8비트 상위 집합이며 서유럽에 필요한 대부분의 문자를 제공합니다.

그러나 동아시아 문자 체계는 10,000개 이상의 문자를 저장할 방법이 필요했기 때문에 동아시아 문자 체계에서 수천 개의 표의 문자를 위한 충분한 공간을 제공하기 위해 DBCS(더블바이트 문자 집합)가 개발되었습니다. 여기서 인코딩은 여전히 ​​바이트 기반이지만 각 2바이트는 함께 단일 문자를 나타냅니다.

동아시아에서도 텍스트에는 라틴어나 가타카나와 같은 작은 알파벳 문자가 포함됩니다. 단일 바이트로 보다 효율적으로 표현됩니다. MBCS(멀티바이트 문자 집합)는 DBCS 인코딩과 구별되는 문자당 가변 바이트 수를 사용하여 이를 제공합니다. MBCS는 종종 ASCII와 호환됩니다. 즉, 라틴 문자는 ASCII가 사용하는 것과 동일한 바이트를 사용하여 이러한 인코딩으로 표시됩니다. 자주 사용되지 않는 일부 문자는 3바이트 또는 4바이트를 사용하여 인코딩될 수 있습니다.

MBCS의 중요한 기능은 선행 바이트 및 후행 바이트 전용 바이트 값 범위가 있다는 것입니다. 멀티바이트 시퀀스의 첫 번째 바이트인 선행 바이트에 대한 특수 범위를 사용하면 단일 문자를 인코딩하기 위해 함께 속하는 바이트 수를 결정할 수 있습니다. 전통적인 MBCS 인코딩은 바이트 스트림을 통해 쉽게 앞으로 이동하고 문자를 읽을 수 있도록 설계되었습니다. 그러나 텍스트에서 뒤로 이동하는 것은 종종 복잡하고 인코딩의 속성에 크게 의존합니다. 뒤로 이동하면 어떤 가변 바이트 수가 단일 문자를 나타내는지 찾기가 어렵고 때로는 다음에서 앞으로 이동해야 합니다. 이 작업을 수행할 텍스트의 시작 부분입니다.

Db2 for i에서 디폴트로 한글 데이터를 저장하면 MBCS 인코딩을 사용하게 되며, 한글 데이터의 선행 바이트에 x'0E'가 후행 바이트에 x'0F' 데이터가 저장되도록 설계되어 있습니다. 

상태 저장 인코딩

일부 인코딩은 상태 저장입니다. 다음 바이트의 의미를 전환하는 바이트 또는 바이트 시퀀스가 ​​있습니다. 혼합 바이트 EBCDIC과 같은 단순 인코딩은 Shift-In 및 Shift-Out 제어 문자(바이트)를 사용하여 두 상태 사이를 전환합니다. 때때로 Shift-In 이후의 바이트는 특정 SBCS 인코딩으로 해석되고 Shift-Out 이후의 바이트는 특정 DBCS 인코딩으로 해석됩니다. 이는 각 문자의 바이트가 바이트 시퀀스의 길이를 나타내는 MBCS 인코딩과 매우 다릅니다.

가장 일반적인 상태 저장 인코딩은 ISO 2022 및 언어별 변형입니다. 이스케이프 시퀀스(ASCII 이스케이프 문자로 시작하는 바이트 시퀀스, 바이트 값 27)를 사용하여 다양한 임베디드 인코딩 간에 전환합니다. 임베디드 바이트 스트림에서 특수 이동 문자와 함께 사용할 인코딩을 알릴 수도 있습니다 . ISO-2022-KR과 같은 언어별 변형은 포함 가능한 인코딩 세트를 제한하고 허용 가능한 작은 이스케이프 시퀀스 세트만 지정합니다.

이러한 인코딩은 데이터 교환에 매우 강력하지만 응용 프로그램에서 사용하기는 어렵습니다. 유연성을 통해 다른 많은 인코딩을 포함할 수 있지만 프로그램에서 직접 사용하고 다른 인코딩과의 변환은 복잡합니다. 직접적인 사용을 위해 프로그램은 텍스트의 현재 위치뿐만 아니라 포함 가능한 인코딩이 현재 활성화된 상태를 추적하거나 상당한 컨텍스트에서 위치에 대한 상태를 결정할 수 있어야 합니다. 다른 인코딩으로 변환하려면 변환 소프트웨어에 포함 가능한 많은 인코딩에 대한 매핑이 필요할 수 있으며, 다른 인코딩에서 변환하려면 특수 코드가 각 문자에 대해 선택할 포함 가능한 인코딩을 파악해야 합니다.

왜 유니코드인가?

소규모 언어 그룹과 특수 목적을 위해 각각 수백 개의 인코딩이 개발되었습니다. 결과적으로 텍스트, 입력, 정렬, 표시 및 저장에 대한 해석은 모든 다양한 유형의 문자 집합과 해당 인코딩에 대한 지식에 따라 달라집니다. 프로그램은 한 번에 하나의 단일 인코딩을 처리하고 인코딩 간에 전환하거나 외부 인코딩과 내부 인코딩 간에 변환하도록 작성됩니다.

문제의 일부는 많은 인코딩과 그 이름에 대한 정확한 정의에 대한 신뢰할 수 있는 단일 소스가 없다는 것입니다. 한 시스템에서 다른 시스템으로 텍스트를 전송하면 종종 일부 정보가 손실됩니다. 또한 프로그램에 기존 인코딩의 중요한 하위 집합 간에 변환을 수행하는 코드와 데이터가 있는 경우 몇 메가바이트의 데이터를 전달합니다.

유니코드는 전 세계 언어를 포괄하는 단일 문자 집합과 기존 응용 프로그램 및 프로토콜의 요구 사항에 맞는 소수의 기계 친화적인 인코딩 형식 및 체계를 제공합니다. ASCII 및 가장 널리 사용되는 문자 집합인 ISO-8859-1과의 최상의 상호 운용성을 위해 설계되어 응용 프로그램 및 프로토콜에서 유니코드를 보다 쉽게 ​​사용할 수 있습니다.

유니코드는 현재 사용되고 있으며 인터넷, 특히 HTML 및 XML에서 선호되는 문자 집합입니다. 전자 메일에서도 서서히 채택되고 있습니다. 그것의 가장 매력적인 속성은 세계의 모든 캐릭터를 다루고 있다는 것입니다 (향후 추가될 예외를 제외하고). 유니코드를 사용하면 고유 번호(즉, 해당 유니코드 코드 포인트)로 문자에 액세스하고 조작할 수 있으며 입력 및 출력에만 이전 인코딩을 사용할 수 있습니다.