채널 프로그램

다국어 도메인 네임

현지어로 .com과 .net의 힘을 구현

새로운 고객, 새로운 등록으로 기회의 세계를 열고 웹 서비스를 확장하십시오.

Verisign 다국어 도메인 네임(IDN)은 기업들이 현지 언어 문자로 .com 및 .net을 표시할 수 있게 해 줍니다. 이 방법으로 고객과 더욱 친절하고 더욱 의미있게 연결할 수 있습니다.

IDN 스토리

1996년에는 모든 인터넷의 사용자 중 대략 2/3가 미국에 있었기 때문에 영어나 라틴어 기반(ASCII라고도 알려진) 문자가 웹 내비게이션의 기반 역할을 했습니다. 그러나 2012년 글로벌 및 현지 인터넷 상황에 대한 Comscore 보고서에 따르면, 그 이후로 영어를 사용하지 않는 인터넷 인구가 전체 중 87%로 늘어났으며, 아시아 태평양 지역의 인터넷 사용자는 전 세계 인터넷 사용자의 41.1%를 차지합니다.

원래 도메인 네임은 ASCII 문자 (A ~ Z, 0 ~ 9 그리고 하이픈 “-“)만 지원하여 분음부호(예: 액센트 마크, 우물라우트, 브레베, 점 등) 및 기타 비라틴어 문자(예: 한글, 아랍어, 태국어, 중국어 간체 등)는 인터넷 검색에 사용할 수 없었습니다.

서구 국가들 이외의 지역에서 인터넷 활동이 더욱 더 활발해짐에 따라, 시기 적절하게 레지스트라 및 그 고객들에게 비 라틴어 기반의 문자를 도입하였으며, 이 조치로 사업을 확장하고자 하는 지역 및 글로벌 레지스트라에게 새로운 시장 기회가 열렸습니다.

2000년, Verisign은 .com 및 .net의 차상위 레벨(닷의 좌측)에 다국어 도메인 네임(IDN)을 도입했습니다. 이는 스타벅스.com과 같은 도메인 네임을 만들고 등록하여 검색할 수 있게 함으로써 더 많은 사용자들이 인터넷에 접근하고 활용할 수 있게 됨을 의미합니다.

2012년, Verisign은 기업들에게 현지 언어 문자로 완전한 .com 및 .net 도메인 네임을 제공하기 위해 .com에 대한 음역 8개와 .net에 대한 음역 3개(닷의 오른쪽에)를 ICANN의 새로운 일반 최상위 도메인(gTLD) 프로그램의 일부로 신청했습니다.

이 새로운 IDN gTLD에 대해 Verisign이 제안하는 접근방식은 어디서나 이용할 수 있는 최종 사용자 경험을 보장하고, 저희 TLD에서 순수하게 방어적인 도메인 네임 등록으로부터 소비자와 기업을 보호하는 데 도움이 될 것입니다. 실무적으로 Verisign이 제안하는 접근법은 저희의 IDN.IDN, IDN.com 또는 IDN.net에 있는 차상위 도메인 네임에 대한 등록자가 그 동일한 차상위 도메인을 모든 관련 최상위 IDN, .com 또는 .net 에 등록할 단독 권한(해당 권리 보호 메커니즘에 따라)을 갖게 되는 것(반드시 등록해야 하는 것은 아님)을 의미합니다.

당사의 접근방식을 설명하기 위해 당사는 아래와 같이 두 가지 사용 사례를 파악했습니다.

사용 사례 1번: Bob Smith는 이미 IDN.net 차상위 도메인 네임을 등록했습니다. 모든 새로운 .net TLD의 그 차상위 도메인 네임은 Bob Smith을 제외하고 아무도 사용할 수 없습니다. Bob Smith는 새로운 .net TLD의 음역에서 그 차상위 도메인 네임 등록을 선택하지 않을 수도 있습니다.

사용 사례 2번: John Doe는 IDN.com 차상위 도메인 네임 등록을 하지 않고 있습니다. John Doe는 다른 TLD들은 제외하고 당사의 .com 태국어 음역에서만 차상위 도메인 네임을 등록했습니다. 그 차상위 도메인 네임은 John Doe (그리고 John Doe만)가 다른 .com IDN TLD 또는 .com 레지스트리에서 그것을 등록할 때까지는 다른 모든 .com IDN TLD의 음역에서 사용할 수 없습니다.

.com 및 .net의 현지 언어 버전

Verisign은 기업들에게 현지 언어 문자로 완전한 com 및 .net 도메인 네임을 제공하기 위해 .com에 대한 음역 9개와 .net에 대한 음역 3개를 새로운 일반 최상위 도메인(gTLD) 프로그램의 일환으로 신청했습니다.

.com
.net
.com

키릴 자모

.net

데바나가리어

.com

히브리어

.net

중국어 간체

.com

아랍어

.net

한글

.com

데바나가리어

.com

타이어

.com

가타카나

.com

중국어 간체

.com

한글

The IDN 등록 과정


등록자는 IDN을 지원하는 레지스트라에게 IDN을 요청합니다. 레지스트라는 ACE(ASCII-compatible encoding)를 사용하여 현지 언어 문자를 지원되는 문자열로 변환합니다. 레지스트라는 ACE 문자열을 Verisign® Shared Registration System(SRS)에 제출하고 SRS는 해당 문자열을 확인합니다. IDN은 .com 및 .net TLD 영역 파일에 추가되어 인터넷에 전파됩니다.


IDN 레졸루션 과정

사용자가 현지 스크립트를 사용하여 웹 브라우저에 IDN을 입력하거나 링크를 클릭하면 IDN 지원 애플리케이션이 문자를 DNS가 이해하는 ACE 문자열로 암호화합니다. DNS는 요청을 처리하고 정보를 애플리케이션에 다시 보냅니다. 간단한 과정처럼 들리지만, IDN 지원 애플리케이션과 DNS가 여러 언어와 스크립트를 지원하기 위해서는 상당한 연구 개발이 필요합니다.

IETF 표준



IETF(Internet Engineering Task Force)는 DNS(도메인 네임 시스템)에서 비ASCII 문자를 사용할 수 있도록 표준을 수립하는 일에 앞장섰습니다.

DNS는 ASCII 문자인 A-Z, 0-9, '-'만 인식합니다. 이로 인해 도메인 네임 구성에 사용할 수 있는 문자 수는 유니코드로 구별되는 96,000자 이상에 비해 37개로 제한됩니다. 유니코드 문자의 범위에서 도메인 네임을 작성하려면 유니코드 코드 포인트를 ASCII 표현에 고유하게 매핑하는 문자 암호화 체계가 필요합니다.

IETF는 다국어 도메인 네임(IDN)과 관련하여 암호화 구조, 프레임워크, 프로토콜, 유니코드 및 오른쪽-왼쪽 방향 스크립트 등의 표준을 발표했습니다..

암호화 구조

IDN용 암호화 구조는 DNS가 주소 레코드 요청에 정확히 응답할 수 있도록 현지 언어의 문자를 ASCII 문자로 암호화하는 ACE(ASCII Compatible Encoding)인 퓨니코드(punycode)를 사용합니다. 퓨니코드(punycode)를 ACE 표준으로 선택하기 위해 IETF는 압축과 구현 사이의 균형 문제를 고려했습니다. 퓨니코드(punycode)는 가장 많은 문자(코드 포인트)가 표현되며, 사용하는 것이 어렵지 않습니다.

프레임워크 [RFC 5890]

이 RFC는 2008년에 대부분 완료되어 "IDNA2008"시리즈로 알려진 IDNA(Internationalized Domain Names for Applications)의 수정에 대한 프로토콜과 사용 컨텍스트를 설명하는 집합 중의 하나입니다. 이 시리즈는 IDNA [RFC 3490] [RFC 3491]의 이전 버전을 대체합니다. 편의를 위해 IDNA의 버전은 "IDNA2003"으로 부릅니다. 새로운 버전은 계속해서 퓨니코드(punycode) 알고리즘 [RFC3492]과 이전 버전의 ACE (ASCII-호환 인코딩) 접두사를 사용합니다.

프로토콜 [RFC 5891]

이 RFC는 핵심 IDNA2008 프로토콜 및 그 운영에 대해 설명합니다. 이 RFC는 아래 설명된 "양방향"(Bidi) 문서와 함께 [RFC 3490]을 명시적으로 업데이트하고 대체합니다.

유니코드 [RFC 5892]

이 RFC는 독립적으로 또는 컨텍스트에서 고려되는 코드 포인트가 IDN에 포함될 후보인지 여부를 결정하기 위한 규칙을 지정하며, IDNA2008 규격의 일부입니다.

오른쪽-왼쪽 방향 스크립트 [RFC 5893]

Internationalized Domain Names(IDNs)에서 오른쪽-왼쪽 방향 스크립트의 사용은 여러 가지 문제를 제기해 왔습니다. 이 RFC는 2003 IDNA Bidi 기준에서 일부 스크립트에서 발생한 문제 및 일부 단점을 기준으로 IDNA(Internationalized Domain Names for Applications)를 위한 새로운 Bidi 규칙을 제공합니다.

근거 [RFC 5894]

이 RFC는 IDNA의 이전 버전에서 발생한 문제를 다루기 위해 새로운 RFC가 필요한 배경, 설명 및 근거를 제공합니다. IDN에서 유니코드가 지원되는 버전의 업데이트 필요성 또한 이 RFC에서 논의됩니다.

공개된 RFC

이 표준이 공개되어 사용할 수 있게 되었습니다.

Verisign은 확고한 의지를 가지고 IETF 표준을 준수하고 이 새로운 기술의 신속한 배치를 지원합니다.

스크립트 + 언어



Internationalized Domain Names(IDNs)는 유니코드에 정의된 문자 집합 또는 스크립트에 등록된 2단계 또는 3단계 도메인 이름이거나 웹 주소입니다.

Verisign IDN이 단일 SRS(Shared Registration System)를 사용하여 수 백개의 언어로 도메인 이름을 등록할 수 있도록 어떻게 지원하는지 알아보려면 문자와 스크립트가 글로 쓴 언어에서 어떻게 사용되고 컴퓨팅을 위해 어떻게 번역되는 지에 대해 이해해야 합니다.

스크립트, 문자, 언어 사이의 관계

스크립트 라틴어 아랍어 한문 그리스어
문자 L س 漢字 Ω
언어 한국어 페르시아어 중국어 그리스어

스크립트

스크립트는 언어에 있어 글의 정보를 표현하기 위해 사용하는 기호를 모아놓은 것입니다. 스크립트의 예: 라틴어, 아랍어, 한문, 그리스어.

문자

문자는 모든 스크립트, 그리고 모든 글로 쓰는 언어의 기본 구성요소가 됩니다. 문자는 가장 기본적인 단계에서 의미를 떠올리며, 더 이상 문자를 분해할 수 없을 때에도 여전히 의미를 갖고 있습니다.

문자 언어

문자 언어는 하나 이상의 스크립트에서 문자를 활용하여 의미를 전달합니다. 언어의 예: 영어, 페르시아어, 중국어, 그리스어.

언어를 컴퓨터에 적용

스크립트마다 다른 키보드 또는 소프트 키보드를 사용하여 컴퓨팅 장치에 입력합니다. 컴퓨터 운영 체제에는 여러 스크립트의 입력을 용이하게 하는 IME(Input Method Editor)가 있습니다. IDN은 유사한 적용 유형으로, 이를 통해 사람들은 현지 언어 스크립트를 사용하여 웹을 검색하고, 이메일을 주고 받고, 파일을 전송하고, 도메인 이름이 필요한 다른 애플리케이션을 전송할 수 있습니다.

유니코드

컴퓨터는 문자를 이해하기 위해 문자 암호를 사용합니다. 문자 집합의 각 문자에게는 고유 번호가 할당됩니다. 예를 들어, ASCII 코드 문자 집합에서, 대문자 "A"에는 65가 할당됩니다. 대부분의 도메인 네임은 ASCII 문자로 등록됩니다(A-Z, 0-9, 그리고 하이픈 "-"). 그러나 스페인어나 프랑스어와 같이 발음 구별 부호가 있는 비영어권에 속하는 단어와 한자, 아랍어와 같이 라틴어가 아닌 스크립트는 ASCII로 표시할 수 없습니다. 유니코드는 범용 코드의 문자 집합으로, 최대 350개의 다양한 모국어를 포함합니다. 이런 이유로 IDN은 유니코드를 사용합니다.

언어 태그

Verisign IDN 인프라는 ICANN RIC(Registry Implementation Committee) 지침을 따르며 각 IDN은 "언어 태그"를 사용하여 특정 언어와 연관되어야 합니다. 등록자는 등록 과정에서 IDN 언어 태그를 선택합니다. IDN이 두 개 이상의 언어를 결합한 경우 등록자는 가장 적합한 언어를 선택해야 합니다. 지금 모든 언어 태그가 참조되는 것은 아닙니다. 그렇지만, 등록 과정 중에 정보를 캡처하면 나중에 언어 테이블을 채택할 수 있습니다. Verisign 유효 언어 태그 목록(PDF) 다운로드

언어 테이블

IDN 등록이 요청되면 문자 포함 테이블 또는 변형 문자 매핑 테이블이 있는 언어의 목록에서 언어 태그를 확인합니다. 이 테이블들은 등록을 구성하는 유니코드 코드 포인트에 적용되어 특정 언어에 대해 등록이 유효한지 여부를 결정합니다. 한 가지 언어를 사용하여 등록하지 못한 경우에도 해당 문자 집합을 다른 언어 태그로 사용할 수 있습니다.

변형 문자


Verisign은 관련 이해당사자들과 변형 문자 문제에 대해 대처해 왔습니다. 등록자는 일반적으로 이름, 단어, 문구와 같이 자신의 모국어에서 의미가 있는 도메인 네임을 등록합니다. 그러나 두 개 이상의 언어에서 하나의 스크립트를 사용할 수도 있습니다.

그 결과, 다른 언어나 문화에서는 도메인 네임의 의미가 달라질 수도 있습니다. 변형 현상은 문자, 철자법, 어휘, 그리고 문맥 상의 변형과 같은 네 가지 범주로 구분되고 있습니다. Verisign은 사용자가 모국어로 인터넷을 이용할 수 있으려면, 변형 문자를 해결하는 것이 꼭 필요하다고 판단했습니다. 또 다른 변형의 경우, 강력한 IDN 솔루션을 제공하는 데 반드시 필요하지는 않은, 복잡한 언어학적 판단이 필요합니다.

중국어 변형 문자

많은 언어에 최종 사용자의 혼란을 야기할 가능성이 있는 변형 문자가 있습니다. 예를 들어, 중국어에는 중국 본토에서 주로 사용되는 중국어 간체와 대만, 홍콩, 기타 동남아시아 국가에서 주로 사용되는 중국어 번체 등 두 가지 문자 형태가 있습니다. 이 두 언어는 많은 문자를 공유하지만, 중국어 간체의 간체 문자가 중국어 번체의 번체 문자와 동일한 의미를 가질 수도 있습니다. 이러한 문자는 변형 문자라고 하며 의미와 발음은 같지만 다른 모양입니다.

변형 문자 솔루션

기술 커뮤니티의 여러 전문가들이 변형 문자 문제를 해결하기 위해 여러 가지 접근 방식을 제안해 왔습니다. 각 접근 방식에는 긍정적인 측면과 부정적인 측면이 있습니다. 그렇지만, IDN 커뮤니티는 언어가 항상 변화하는 상태이기 때문에 변형 문자 문제를 완전히 해결할 수 없다는 데 의견을 같이하고 있습니다. 언어 간에 새로운 변형 문자가 계속해서 생겨날 것입니다. Verisign은 변형 문자 문제를 해결하기 위해 언어 테이블을 참조하는 언어 태그를 채택했습니다.

Verisign은 CNNIC(China Network Information Center)(.cn), TWNIC(Taiwan Network Information Center)(.tw), 한국인터넷진흥원(.kr), JPRS(Japan Registry Service)(.jp), CDNC(Chinese Domain Name Consortium), ICANN에 의해 설립된 IDN Implementation Committee 등 관련당사자와 협력하여 변형 문자를 해결하기 위해 노력하고 있습니다.

정책

Verisign은 허용 및 금지 코드 포인트를 지정하는 IDN 등록 정책을 개발했습니다.

Verisign Shared Registration System(SRS)에서는 유니코드를 지원하는 ASCII가 아닌 스크립트가 포함된 IDNs 작성이 허용됩니다.

등록 규정

해당 정책이 구현되는 다섯 가지 유효성 검사 규정을 이해하십시오.


규정 보기

추가 로직

Verisign은 IDN의 유효성 검사를 수행한 뒤 등록의 언어 태그를 기반으로 추가 로직을 실행합니다.


추가 로직 보기