Windows XP와 Microsoft .NET Framework에는 모두 전역화를 지원하는 API가 있습니다. Windows Vista에서는 새로운 기능의 도입으로 전역화 지원이 더욱 확장됩니다. Windows Vista에 관심이 있다면 .NET Framework의 culture와 Windows Vista의 로캘이 서로 어떻게 다르고, 관리되는 인코딩과 Windows 기반 코드 페이지의 차이점은 무엇이며, 관리되는 코드에서 사용할 수 없는 IDN(다국어 도메인 이름) 위험 완화 기능이 Windows Vista에 있는 이유에 대해 알고 싶을 것입니다. 이번 달 기사에서는 이러한 의문점을 비롯해 .NET Framework 2.0 및 Windows Vista의 전역화 기능에 대한 기타 질문에 답할 것입니다.

.NET Framework에서는 "culture"(또는 "지역")라는 용어를 사용하는데, 이는 Windows에서 사용되는 "로캘"에 해당합니다. MSDNMagazine의 2005년 10월 기사에서 Michael Kaplan과 Cathy Wissink는 .NET Framework에 필요한 사용자 정의 culture 데이터에 대해 논의했습니다(msdn.microsoft.com/msdnmag/issues/05/10/Globalization(영문) 참조). 사용자 지정 culture는 시스템 전체에서 사용되는 CultureInfo 및 RegionInfo 개체의 데이터를 정의하는 방법을 제공합니다. 새로운 .NET Framework 2.0 CultureAndRegionInfoBuilder 클래스를 사용하면 새 culture를 만들거나 기존 culture를 수정하여 시스템에서 사용하도록 등록할 수 있습니다.

.NET Framework의 사용자 지정 culture가 필요한 모든 시나리오는 Windows Vista에도 적용될 수 있습니다. 예를 들어 미국에서 기본적으로 사용되는 간단한 날짜 형식인 mm/dd/yyyy 대신 yyyy/mm/dd와 같은 특정한 날짜 형식을 더 선호하는 미국 기업이 있을 수 있습니다. 이 경우 사용자 지정 culture를 만들어 기존 en-U.S. culture 데이터를 이러한 특정 날짜 형식으로 바꿀 수 있습니다. 그 다음 사용자 지정된 culture 형식을 회사의 모든 컴퓨터에 설치하면 이 회사가 선호하는 방식을 지원할 수 있습니다.

다른 culture를 기반으로 사용자 지정 culture를 만드는 시나리오도 있을 수 있습니다. 예를 들어 영어 culture를 템플릿으로 사용하여 인도 지역을 위한 새로운 영어 culture를 만들 수 있습니다. 월 및 요일 이름과 같은 대다수의 필드는 그대로 남겨 두고, 통화 기호, 지역 이름 및 기타 정보를 변경하여 인도 영어에 적합한 culture를 만들 수 있습니다.

완전히 새로운 culture를 만들려면 해당 로캘에 맞는 지역 및 culture 데이터를 모두 지정하여 처음부터 새로운 사용자 지정 로캘을 만들 수 있습니다. 그런 다음 컴퓨터에 등록하면 모든 응용 프로그램에서 일반적인 CultureInfo 생성자를 통해 완전히 새로운 로캘에 액세스할 수 있게 됩니다.

.NET 기반 culture 및 지역은 Windows의 로캘과 비교할 수 있습니다. 또한 Windows 로캘에도 사용자 지정 culture가 필요합니다. .NET Framework 2.0 CultureAndRegionInfoBuilder로 Windows Vista의 이러한 요구도 충족할 수 있습니다. .NET Framework에서 등록한 사용자 지정 culture는 Windows Vista에서 사용자 지정 로캘로 자동 공유됩니다. .NET 기반 사용자 지정 culture를 Windows Vista 사용자 지정 로캘로 사용할 수 있는 이 기능을 통해 더 높은 유연성이 제공됩니다.

Windows Vista에서 사용자는 .NET Framework 2.0 CultureAndRegionInfoBuilder로 만들어지거나 수정된 사용자 지정 로캘을 기본 로캘로 선택할 수 있습니다. 이렇게 하면 사용자 지정 로캘이 기본 설정일 때 관리되지 않는 레거시 응용 프로그램에서 사용자 지정 로캘 데이터에 액세스할 수 있습니다(그림 1 참조). 그림 2의 로캘은 사용자 지정 글꼴과 키보드를 필요로 하지만, 복합적인 사용자 지정 로캘 솔루션도 구현할 수 있음을 보여 줍니다.

그림 1 Windows Vista의 사용자 지정 로캘

대체 .NET Framework culture가 대체 Windows Vista 로캘이 되고, 이를 통해 사용자는 시스템 전체에서 특정 로캘의 시간 형식이나 다른 값을 수정할 수 있습니다. 이러한 culture/로캘의 변경은 관리되거나 관리되지 않는 응용 프로그램에 모두 적용됩니다. 그림 3에서 볼 수 있듯이 기존 로캘 데이터는 매우 간단히 수정할 수 있습니다.

그림 2 복합적인 사용자 지정 로캘 솔루션

일부 로캘의 경우 지역 방언을 비롯한 문화적인 차이로 인해 여러 맞춤법이나 기타 사용자 기본 설정이 허용될 수 있습니다. Windows Vista에서 제공되는 일반 데이터에 대해 기술적으로는 올바르지만 해당 로캘의 일부 사용자에게 적합하지 않은 한 가지 형식을 선택해야 하는 경우가 있습니다. 데이터가 수집된 지역과 기호가 다른 사용자는 자신의 기호가 소수의 기호일지라도 CultureAndRegionInfoBuilder를 사용하여 .NET Framework와 Windows Vista의 culture 데이터를 자신의 기호에 맞게 변경할 수 있습니다.

Microsoft Locale Builder for Windows Vista는 초보자도 자신의 로캘 데이터를 원하는 대로 지정할 수 있는 사용하기 편리한 도구를 제공하여 이러한 사용자 지정 로캘을 구축하도록 지원합니다. 이 도구는 Windows Vista 로캘 데이터를 수정하지만 도구 자체는 C# 언어로 작성되었으며 .NET Framework 2.0 CultureAndRegionInfoBuilder 클래스를 기반으로 이러한 사용자 지정 로캘을 만듭니다. 자세한 내용은 보충 기사 "Some Customer Culture Gotcha (영문)"를 참조하십시오.

지금까지 Microsoft는 .NET Framework와 Windows에서 최신 culture 또는 로캘 데이터를 제공해 왔습니다. 그러나 로캘 데이터는 항상 변화합니다. 여러 문화가 지속적으로 유입되고, 유로화 도입과 같은 문화적 변화가 일어날 수 있으며, 정부가 표준을 변경할 수 있고, 문화적 다양성을 장려하는 풍토가 조성될 수 있습니다. .NET과 Windows는 출시 시기가 달라 서로 동기화되지 않는 경우도 많습니다.

CultureAndRegionInfoBuilder 클래스를 사용하여 사용자 지정 culture/로캘을 만들면 .NET Framework 2.0과 Windows Vista 간에 데이터를 공유할 수 있으므로 관리되는 응용 프로그램과 관리되지 않는 응용 프로그램 간에 culture 데이터의 일관성이 유지됩니다.

Microsoft는 Windows와 .NET Framework에서 지원되는 로캘을 계속 확장하고 있습니다. .NET Framework 2.0에는 Windows XP SP1에서 사용 가능한 로캘이 포함되어 있습니다. Microsoft는 그 이후 Windows에 로캘을 계속 추가해 왔습니다. Windows Vista에는 더욱 많은 로캘이 추가될 것입니다. .NET Framework 2.0은 Windows API에서 반환되는 데이터의 "Windows 전용" culture와 지역을 통합함으로써 Windows에 있는 모든 로캘에 액세스할 수 있습니다. .NET Framework 2.0은 데이터 형식, 문자열, 정렬 동작 및 기타 Windows 전용 culture 또는 지역에 관련된 모든 값을 Windows에 쿼리하여 이 Windows 전용 culture에 모든 데이터를 제공합니다.

Windows 전용 culture와 기본 제공 .NET Framework culture 사이의 한 가지 흥미로운 차이점은 Windows에서는 지역 중립적 culture 또는 언어 중립적 지역이 지원되지 않는다는 점입니다. 지역 중립적 culture는 특정 지역이 없는 culture입니다. .NET Framework에서는 각각의 특정 culture(예: en-US)에 중립적인 부모 culture(예: en)가 있으며, 따라서 부모와 동일한 고정 로캘을 갖게 됩니다. Windows에는 언어 중립적 지역(예: US)이 없습니다.

Windows에는 언어 이름뿐인 로캘은 없습니다. .NET Framework에서 특정 Windows 전용 culture에 대한 지역 중립적 부모를 찾을 수 없으면 해당 culture의 부모 대신 고정 culture가 사용됩니다. 관리되는 응용 프로그램에서는 이러한 통합적인 Windows 전용 culture를 이용하기 위해 culture의 특정 전체 이름을 사용해야 합니다.

지역 전용 정보도 마찬가지로 Windows 및 Windows 전용 지역에서 사용할 수 없습니다. 지역 이름(예: US)만이 아닌 완전한 culture 이름(예: en-US)으로 RegionInfo 개체를 만드는 것이 좋습니다. 지역 이름에 문화적으로 적합한 언어를 가져오기 위해서도 en-US에 대해 United States, es-US에 대해 Estados Unidos와 같이 전체 지역 이름을 사용해야 합니다. 이러한 지역 이름 간의 차이가 지정학적 문제인 경우도 있으므로 가능하면 항상 특정 culture를 사용해야 합니다.

Windows 전용 culture는 운영 체제에서 지원하는 로캘 집합을 .NET Framework에서 동일하게 지원할 수 있는 방법을 제공합니다. 한 가지 주의할 점은 한 컴퓨터에 설치된 .NET에는 다른 컴퓨터와 같은 Windows 전용 culture 집합이 없을 수도 있다는 것입니다. 예를 들어 한 컴퓨터의 Windows 또는 서비스 팩 버전이 다른 컴퓨터와 다른 경우가 있습니다. CultureInfo.GetCultures 메서드는 원하는 culture 형식을 필터링할 수 있으며, CultureInfo.CultureTypes 속성에는 Windows 전용 culture에 대한 WindowsOnlyCultures 값이 포함됩니다.

로캘 ID(LCID)가 더 이상 필요하지 않다고 말하기에는 조금 이를 수도 있지만, 앞으로는 그렇게 될 것입니다. Windows는 지금까지 LCID에 기반하여 로캘을 식별했습니다. 처음 등장한 시점부터 더 높은 유연성을 갖춘 .NET Framework에서는 이름을 사용하여 culture를 식별할 수 있습니다. .NET에서는 여전히 LCID를 사용한 CultureInfo 생성이 가능하지만 이름이 우선적으로 사용되며, 사용자 지정 로캘에서는 이름이 필수입니다.

LCID는 Microsoft에서만 지정할 수 있기 때문에, 사용자 지정 culture가 등장하면서 이름의 중요성이 더욱 커졌습니다. 이는 .NET Framework뿐만 아니라 Windows Vista 로캘에서도 마찬가지입니다. C 코드에서는 오버로드를 사용할 수 없으므로 Windows Vista의 모든 NLS(국가별 언어 지원) API에 대한 로캘 이름을 수용하도록 Ex 버전이 만들어졌습니다. 따라서 이름 식별자로 로캘 데이터를 쿼리할 수 있도록 GetLocaleInfoEx, EnumSystemLocalesEx 등이 만들어졌습니다. 이러한 함수를 사용하면 네이티브 응용 프로그램에서 새로운 .NET Framework 사용자 지정 culture의 데이터에 액세스할 수 있습니다.

사용자 지정 culture 및 로캘은 앞으로 Windows와 .NET Framework에서 매우 중요한 역할을 할 것으로 예상됩니다. Ethnologue에는 전 세계의 6,912 개 언어가 등록되어 있으며, 미국에서만 162개의 언어가 사용되고 있습니다. Microsoft는 Windows XP에 제공된 137개 로캘 외에도 60개 이상의 새 로캘을 Windows Vista에 추가하고 있습니다. 여기에는 아프리카, 남아메리카, 아시아 지역의 신흥 시장을 위한 새로운 지원, 기존 유럽 시장의 지역 언어를 위한 지원 확대, 그리고 스페인어(미국) 지원이 포함됩니다. 그러나 전 세계 모든 언어와 국가의 조합에 대한 데이터를 수집하고 유지하기는 매우 어려운 일이며, 특히 기술 측면에서 비교적 새로운 지역인 신흥 시장의 경우 더욱 어렵습니다. 모든 사람의 로캘이 자신들에게 중요하지만 다양한 많은 그룹의 요구 사항을 완전히 파악하기는 어렵기 때문에 필요한 로캘 집합을 식별하는 것조차 어려운 과제입니다.

Microsoft는 레거시 응용 프로그램, 데이터, 표준과의 상호 운용성을 위해 LCIDToLocaleName 및 LocaleNameToLCID 함수를 Windows Vista에 추가했습니다. 여기에 CultureInfo.LCID 속성이 결합되어 응용 프로그램은 관리되는 코드와 관리되지 않는 코드가 섞인 환경에서도 로캘 이름으로 마이그레이션하는 데 필요한 도구를 확보하게 됩니다.

LCID는 레거시 응용 프로그램과 기타의 경우를 위해 당분간 존속시킬 필요가 있지만, 이제 culture 이름과 로캘 이름이 널리 사용되고 있습니다. .NET Framework 2.0을 통해 무수히 많은 사용자 지정 culture/로캘을 사용할 수 있게 되었으며, 이제 Microsoft Locale Builder for Windows Vista(그림 4)를 사용하여 더욱 쉽게 사용자 지정 로캘 솔루션을 만들어 배포할 수 있게 될 것입니다. 사용자는 Microsoft에서 지정하는 LCID에 의존하지 않고 자신만의 이름 식별자를 선택하고 새로운 이름 기반 API를 사용하여 데이터를 쿼리할 수 있습니다. .NET에서 시작된 이러한 변화는 LCID의 소멸을 재촉하고 있습니다.

그림 4 Microsoft Locale Builder for Windows Vista

LCID가 없으면 culture 및 로캘 이름을 사용해야 한다는 점을 기억해야 합니다. en-US와 같이 전체 culture 이름으로 culture 및 지역 데이터를 가져오는 것이 좋습니다. 또한 Microsoft .NET culture 이름은 IETF(Internet Engineering Task Force) 표준 이름의 구문을 존중한다는 점도 알아 두어야 합니다. 이름에 언어와 지역이 포함되는 경우 culture 이름은 언어-지역 형식(예: en-US, fr-FR)으로 구성됩니다. 일부 로캘에는 해당 로캘에 사용되는 스크립트도 포함됩니다. 예를 들어 Uzbek-Uzbekistan에는 두 가지 로캘, 즉 키릴 자모 스크립트 로캘을 위한 uz-Cyrl-UZ와, 라틴 문자 스크립트 로캘을 위한 uz-Latn-UZ가 있습니다. 또한 일부 IETF 이름에는 특수한 코드가 사용됩니다. 예를 들어 en-029는 Windows 영어(카리브 해) 로캘에 대한 IETF 코드입니다. 관리되지 않는 응용 프로그램에서는 이름을 받아들이는 GetLocaleInfoEx 및 관련 함수를 사용해야 합니다.

코드 페이지, 인코딩 및 문자 집합은 유니코드와 같은 한 가지 형식의 문자 데이터를 ASCII와 같은 다른 형식으로 매핑합니다. 대부분의 코드 페이지는 .NET Framework 또는 Windows에서 지원되는 문자의 하위 집합만 지원합니다. 그러나 이러한 하위 집합이 구현되는 방식에는 차이가 발생합니다. 예기치 않은 변환 동작을 방지하는 가장 간단한 방법은 UTF-8 또는 UTF-16과 같은 표준 유니코드 인코딩을 사용하는 것입니다.

.NET Framework는 인코딩과 Encoding 클래스를 사용하여 다른 바이트 표현에 대한 내부 UTF-16 유니코드 표현의 매핑을 가리킵니다. Windows에서는 이와 동일한 작업을 위해 API에서 사용되는 매핑 테이블을 '코드 페이지'라는 용어로 지칭합니다.

대부분의 인코딩에서는 유니코드의 하위 집합만 처리합니다. 예를 들어 ASCII는 128개 문자만 인코딩할 수 있는데, 이는 95,000개가 넘는 유니코드 문자의 0.1%에 해당됩니다. 사용되는 방법에 따라, 나머지 99.9%의 유니코드 문자는 무시되거나 물음표(?)와 같은 다른 문자로 변환되거나 오류로 처리됩니다. Windows-1252 등의 다른 1바이트 코드 페이지에서는 이 수치가 높아지긴 하지만 0.25%에 불과합니다. Windows의 공용 2바이트 코드 페이지 중 일부는 아직 유니코드 문자의 10% 정도만 정확히 변환합니다.

인코딩과 관련된 또 다른 문제는 새로운 표준이 만들어지고 기존 코드 페이지는 확장, 수정, 또는 변경된다는 점입니다. 일부 인코딩에는 응용 프로그램 고유의 동작에 사용되는 할당되지 않은 코드 포인트가 있습니다. 이러한 인코딩의 문자 집합이 늘어나면서 해당 코드 포인트가 새로운 문자에 다시 사용되는 경우도 간혹 있습니다. 비공식적 사용 지역이 널리 알려지면서 표준으로 받아들여지기도 합니다. 이러한 변화로 인해 이전 동작을 기반으로 하는 응용 프로그램이나 데이터가 손상될 수 있습니다.

다양한 업체들이 서로 다른 버전의 인코딩 표준을 채택하는 경우가 많았기 때문에, 다양한 운영 체제, 공급업체 및 응용 프로그램에서 여러 인코딩 간의 문자 매핑을 위해 각자 고유의 알고리즘을 보유하고 있습니다. 공급업체의 요구 사항이 기존 표준과 약간 다른 경우도 있고, 인코딩 동작에 의도하지 않은 버그가 있는 경우도 있습니다.

인코딩 구현 간의 이러한 차이로 인해 데이터가 손상될 수 있습니다. 다행히 이러한 손상은 대개 극히 소수에서, 또는 표준의 여러 수정 버전에서 나타납니다. 그러나 손상된 문자가 필요한 데이터를 사용하는 사람에게는 이러한 점이 도움이 되지 않습니다. 데이터 인코딩과 디코딩에 동일한 API 집합이 사용되는 경우에는 유니코드에서 인코딩으로, 다시 유니코드로 라운드트립할 때 발생되는 손실은 대개의 경우 크지 않습니다.

이러한 복잡성은 한 문자를 하나의 AIP 집합을 사용하여 정확히 인코딩 및 디코딩할 수 있지만, 플랫폼을 이동하는 경우에는 이 문자가 제대로 라운드트립되지 않을 수도 있음을 의미합니다. 유명 웹 사이트나 인기 게시물에서 따옴표 대신 네모 상자가 나타나는 것을 본 적이 있을 것입니다. 이러한 현상은 대개 컴퓨터, 응용 프로그램 또는 브라우저 클라이언트에서 올바른 인코딩을 사용한다고 판단하지만 실제로는 문자 데이터가 의도된 방식대로 해석되지 않았기 때문에 나타납니다. 또한 일부 언어에서는 공급업체마다 다른 해석, 코드 페이지 표준의 변경, 레이블이 잘못 지정된 문자 집합 태그로 인해 웹 페이지에서 특정 문자가 손상되는 경우가 자주 발생합니다.

Microsoft의 방침은 사용자가 한 API 집합을 사용하여 문서를 저장하면, 동일한 API 집합을 사용하여 동일한 데이터를 다시 가져올 수 있어야 한다는 것입니다. 과거에는 일부 코드 페이지에서 아직 표준으로 지정되지 않은 문자를 인코딩했습니다. 다른 표준들이 발전하면서 새 문자를 포함하게 되었으며, Microsoft는 이러한 표준에 다양한 수준의 지원을 제공해 왔습니다. 새로운 표준이 Microsoft에서 제공하는 것보다 더 적합할 수도 있지만, 표준을 확장할 때는 사용자가 수년 전에 저장한 데이터를 손실할 경우의 비용을 감안해야 합니다.

Windows에는 문자 데이터를 변환하는 두 가지 기본 방식으로 MultiByteToWideChar/WideCharToMultiByte와 MLang이 있습니다. .NET Framework에는 Encoding 클래스가 있습니다. 이 세 가지 방법에는 모두 각자의 고유한 특색이 있으며, 이는 서로 다른 방식으로 쓴 데이터를 100% 정확하게 읽을 수 없음을 의미합니다.

MLang에는 국가별 코드 페이지에 사용하도록 디자인된 여러 가지 기능이 있습니다. 일반적으로 MultiByteToWideChar가 MLang 변환 함수 호출보다 선호됩니다. MLang은 Microsoft Internet Explorer에서 코드 페이지 검색 및 변환을 위해 사용됩니다. .NET Framework Encoding 클래스는 비슷한 변환 기능을 제공하지만 일부 코드 페이지에서 일부 코드 포인트의 변환 방식이 다를 수 있습니다. 예를 들어 ASCII에서 MLang은 8번째 비트만 삭제하여 문자를 8번째 비트 세트에 매핑하는데, 이는 스푸핑을 허용할 수 있습니다. MLang은 내부적으로 유니코드를 특정 코드 페이지로 변환한 다음 이 결과를 대상 코드 페이지에 적용하려고 합니다. 이 알고리즘은 특히 코드 페이지에서 정의되지 않은 시퀀스의 임의 매핑을 종종 일으킵니다. .NET Framework에는 임의 매핑이 없는, 더 깔끔한 구현 방법이 있습니다. 또한 .NET Encoding 클래스는 여러 시퀀스를 작성할 때 상태를 기준선으로 복원하는 데 있어 더 일관적입니다. MLang은 1바이트 데이터를 2바이트 데이터로 읽는 등 의도하지 않은 모드 변경을 일으킬 수 있습니다. MLang에 대한 자세한 내용은 msdn.microsoft.com/workshop/misc/mlang/mlang.asp(영문)를 참조하십시오.

MultiByteToWideChar 및 WideCharToMultiByte는 Windows API에서 자주 사용되는 함수로, 대부분의 Windows에서 내부적으로 사용되며 MLang에서도 호출됩니다. 특히 iso-2022-xx 코드 페이지와 같이 일부 코드 페이지는 .NET Encoding 클래스 버전과 다릅니다. 또한 MultiByteToWideChar 및 WideCharToMultiByte는 데이터가 온전한 상태로 변환될 것을 예상하는 반면 .NET Framework는 Encoder 및 Decoder 클래스를 제공합니다. 관리되지 않는 C 코드에서 MultiByteToWideChar 함수의 호출은 다음과 같이 매우 간단합니다.

int   length;
WCHAR wcTemp[BUFFER_SIZE];
BYTE* bytes = "Input byte string";
Length = MultiByteToWideChar(CP_UTF8, 0, bytes, -1, 
                             wcTemp, BUFFER_SIZE);

Encoding 클래스는 관리되는 코드에서 사용되며 Windows API에는 없는 기능을 포함하고 있습니다. Encoder 및 Decoder 클래스는 여러 단계의 대용량 버퍼 인코딩 또는 디코딩을 제공하는 데 사용할 수 있습니다. 또한 .NET Framework 2.0은 대체 언어를 지원하여 알 수 없거나 손상된 문자에 대한 사용자 지정 동작을 제공합니다.

다음은 기본 동작을 사용하는 간단한 UTF-8 예제입니다.

Dim bytes() As Byte = Encoding.UTF8.GetBytes( _
    "Convert this string to UTF8")

다음 예제는 예외 대체 언어를 선택하여 잘못된 입력 데이터에 대해 예외를 발생시키는 생성자를 사용합니다.

Dim bytes() As Byte = New UTF8Encoding(true, true).GetBytes("Convert " & _
    "this string and throw on illegal characters like " & ChrW(&hD800))

다음 예제는 사용자 지정 대체 언어를 사용하여 알 수 없는 문자를 {unknown}으로 대체합니다.

Dim utf8 As Encoding = CType(Encoding.UTF8.Clone(), Encoding)
utf8.EncoderFallback = New EncoderReplacementFallback("{unknown}")
Dim bytes() As Byte = utf8.GetBytes( _
   "Convert and replace illegal " & ChrW(&hD800) & " with {unknown}")

네이티브 Windows 기반 응용 프로그램이나 다른 플랫폼에 있는 응용 프로그램과 통신하는 .NET 기반 응용 프로그램에서는 인코딩 차이가 발생할 수 있다는 점을 인식하고 있어야 합니다. 유니코드는 Windows 또는 .NET에서 정확히 지원되는 문자 집합이므로 데이터 교환에는 유니코드를 사용하는 것이 좋습니다. 그러나 일부 프로토콜은 다른 표준을 기반으로 하며 변환이 필요합니다. 점점 더 많은 응용 프로그램이 유니코드를 채택하고 있으므로 이러한 경우는 제한될 것입니다. 다행히도 새로운 표준이나 업데이트되는 많은 표준에서 유니코드에 대한 규정이 마련되고 있습니다.

.NET Framework 2.0 개발 팀은 Windows와 .NET Framework에서의 유니코드에 대한 중요성을 인식하여 UTF-8 및 UTF-16 인코딩을 최적화하는 데 많은 노력을 기울이고 있습니다. 이제 거의 대부분의 경우에서 UTF-8은 대부분의 비유니코드 인코딩보다 속도가 훨씬 더 빠릅니다. Windows Vista의 경우도 이와 비슷한 노력을 통해 MultiByteToWideChar 함수에서 사용되는 UTF-8의 속도가 향상되었습니다. 이러한 유니코드 인코딩을 사용함으로써 관리되는 문자와 관리되지 않는 문자의 변환 알고리즘 간 비호환성을 방지할 수 있습니다.

Windows Vista에는 관리되지 않는 버전의 유니코드 정규화 기능과 IDN 매핑 API도 추가되었습니다. Michael Kaplan과 Cathy Wissink이 집필한 이전 기사에서 간략히 설명했듯이, IDN 표준은 일부 문자의 혼란을 틈타 침투하는 스푸핑 공격을 받을 수 있는 가능성에 노출됩니다. Windows Vista에는 이와 같은 우려 중 일부를 완화하는 데 도움이 되는 API가 추가되었습니다. 이러한 API는 관리되는 코드에서는 사용할 수 없으므로 관련 코드의 개발자는 잠재적인 보안 문제를 인식하고 있어야 합니다.

IDN 표준의 가장 중요한 문제는 호스트 이름의 문자 레퍼토리가 상당히 늘어난다는 것입니다. 이 문제는 동형 이의어를 통한 도메인 이름 스푸핑의 가능성을 높입니다. 동형 이의어는 같은 단어로 보이지만 실제로는 다른 단어입니다. 일반적인 예로 paypal.com 대신 pаypal.com 철자를 사용해 paypal.com URL을 만드는 경우가 있습니다. 물론 사람의 눈으로 pаypal.com의 첫 번째 'a'가 라틴 문자 'a'인 U+0061 코드 포인트에서 키릴 자모 'а'인 U+0430 코드 포인트로 변경되었음을 판단하기는 매우 어렵습니다.

피싱 공격에서는 이와 같이 "새로운" 문자를 유니코드에 추가함으로써 동형 이의어를 사용하여 합법적인 도메인을 스푸핑하고, 사용자의 개인 정보를 수집하고, 동형 이의어 이름으로 유사한 사이트를 만들어 합법적인 기업을 비방하거나 기타 부정한 행위를 저지를 수 있습니다. 그러나 IDN에 대한 이러한 공격이 새로운 것은 아닙니다. rnicrosoft.com은 microsoft.com과 거의 똑같이 보이며, 일부 글꼴에서는 I(i)가 l(L), 또는 1(숫자)처럼 보입니다. 또한 정확한 동형 이의어 이름이 아니어도 피싱 공격이 가능합니다. paypal.com.safesecure.net이나 mine.com/paypal.com/safe/logon과 같은 웹 사이트도 사용자를 속일 수 있습니다.

동형 이의어 문제를 완화하는 한 가지 방법은 도메인 이름에 허용되는 스크립트를 탐지하는 것입니다. 이는 도메인 이름을, 예를 들어 라틴 문자, 키릴 자모 두 가지가 아닌 이 중 하나의 스크립트로만 제한한다는 개념입니다. 따라서 예상보다 많은 스크립트를 사용하는 도메인 이름은 의심스러운 도메인으로 간주됩니다. 일부 로캘에서는 외국 기업의 현지 사업부 이름처럼 라틴 또는 다른 스크립트가 네이티브 스크립트와 혼합되어 있는 경우를 흔히 볼 수 있습니다. 다른 경우로는 특히 브라우저 주소 표시줄에서 작은 글꼴로 렌더링될 때 단일 스크립트에 비슷한 모양의 문자가 많이 포함될 수 있습니다. 즉, 이러한 완화 방법은 완전하지는 않지만 더 폭넓은 전략의 일부로 사용할 수 있습니다.

스크립트 탐지 방식은 Windows Vista 완화 API의 기본적인 개념입니다. 이러한 API를 사용하면 IDN에 있는 스크립트를 탐지하여 비교할 수 있습니다. 새로운 관리되지 않는 Windows Vista GetStringScripts 함수는 문자열에 있는 스크립트의 목록을 반환합니다. GetLocaleInfoEx 함수는 LOCALE_SSCRIPTS를 쿼리하여 특정 로캘에 예상되는 스크립트를 검색할 수 있으며, VerifyScripts는 이전의 두 가지 결과를 비교하여 예상된 스크립트가 로캘에서 예상되는 집합에 속하는지 판단합니다(그림 5 참조).

.NET Framework 2.0 출시 이후 IDN과 관련된 동형 이의어 우려가 커졌기 때문에 Windows Vista API에는 동일한 기능의 관리되는 항목이 없습니다. 앞에서 설명한 대로 이러한 API 자체만으로는 IDN 이름과 관련된 모든 보안 문제를 해결할 수는 없다는 점을 기억하십시오. 신뢰할 수 있고 관리되는 응용 프로그램에서는 P/Invoke를 사용하여 이러한 네이티브 Windows Vista API를 호출할 수 있습니다.

Windows와 .NET Framework는 서로 보완하는 방식으로 전역화 기능을 지원합니다. 각자 나름의 장점을 갖고 있지만 Windows Vista의 공유 사용자 지정 culture 및 로캘 동작과 같이 함께 사용되면 뛰어난 사용자 솔루션을 제공할 수 있습니다. 또한 인코딩과 코드 페이지 동작에서 볼 수 있듯이 이 둘은 각기 다른 방식으로 작업을 처리합니다. 따라서 관리되는 기능과 관리되지 않는 기능을 모두 이용하는 솔루션을 만들 때에는 주의를 기울여야 합니다.

더 자세한 내용은 Unicode Standard (영문), Michael Kaplan의 블로그 (영문) 및 필자의 블로그 (영문)를 참조하십시오. 자세한 정보는 Microsoft Global Development and Computing Portal (영문), Dr. International's columns (영문), Windows Vista 및 Microsoft .NET Framework 2.0 SDK에서 확인할 수 있습니다.

질문이나 의견이 있으시면 clrinout@microsoft.com으로 보내시기 바랍니다.