KR20030015272A

KR20030015272A - 비-라틴어 문자 ｕｒｌ 변환 방법

Info

Publication number: KR20030015272A
Application number: KR1020027016706A
Authority: KR
Inventors: 치아예우켕로더릭; 옹친키아트; 리치멩
Original assignee: 스파이럴 커뮤니케이션즈 피티이 리미티드
Priority date: 2002-12-06
Filing date: 2000-06-07
Publication date: 2003-02-20

Abstract

인터넷 브라우저를 이용하여 사용자에 의해 입력되는, 도메인 네임을 가진 비-라틴어 문자 URL을 변환하는 방법이 제공되며, 이 방법은, 비-라틴어 문자 URL 변환을 지원하는 웹사이트에 접속하는 단계; 상기 웹사이트로부터 비-라틴어 문자 URL 입력 프로그램을 다운로드하는 단계; 상기 프로그램을 이용하여 상기 URL을 입력하고, 상기 URL을 상기 웹사이트로 전송하는 단계; 상기 웹사이트에서, 상기 URL의 문자 셋트를 이용하여, 선택된 문자 셋트로 도메인 네임을 지원하는 하나 또는 그 이상의 네임 서버를 결정하는 단계; 상기 웹사이트로부터 상기 도메인 네임으로 적어도 하나의 상기 네임 서버에 질의하는 단계; 및 상기 질의가 충족되는 경우에 상기 URL로부터 콘텐츠를 펫치하고, 상기 콘텐츠를 사용자에게 전달하는 단계를 포함한다.

Description

비-라틴어 문자 ＵＲＬ 변환 방법{A METHOD OF RESOLVING A NON-LATIN CHARACTER URL}

각각의 인터넷 웹사이트는 사용자가 그 사이트에 액세스하기 위해 그의 웹 브라우저를 이용하여 입력하는 고유의 URL(uniform resource location) 어드레스를 갖고 있다. URL은 2부분, 즉, 호스트 또는 IP(Internet Protocol) 어드레스를 명시하는 도메인 네임 부분과 그 자원에 대한 경로 부분을 갖고 있다. 이들 부분은 사용자에 의해 워드 형태로 입력되며, 다음에 수치 어드레스로 번역된다. 통상적으로, URL은 라틴어 알파벳 문자와 숫자를 포함하는 표준 문자 셋트로 이루어져 있으며, 각 나라의 "분기" 국가 레지스트리(branch national registry)와 함께 ICANN에 의해 제공되는 "루트(root)" 레지스트리 기능을 이용하여 변환된다(resolved).

이러한 URL 어드레스에 있어서의 문제점은 이들 어드레스가 배타적으로 라틴어 문자를 이용하며, 그러므로 중국어 문자를 이용하거나 또는 태국어와 같은 비-라틴어 알파벳을 이용하는 것과 같이, 다른 언어 표현을 이용하여 비-라틴어 문자URL 어드레스를 표현하는 불가능하다는 것이며, 그 이유는 이들 다른 언어 표현이 변환될 수 없기 때문이다. 따라서, 이후에 i18n(internationalization의 약어)로 언급되는 비-라틴어 문자 URL 어드레스를 표현하기 위한 제안이 있었으며, i18n 도메인들을 구현하기 위한 2가지 구현예, 즉 iDNS(Internationalized Domain Name System)과 CNNIC(China Internet Network Information Center)가 현재 제안된 상태이다. 각각의 구현예는 상이한 네임 서버를 갖고 있다. 그런데, 한가지 문제점은 아직까지 표준 구현예가 합의되지 않아서 상이한 구현예를 이용하여 i18n 도메인에 액세스하는데 있어서 어려움이 있고, 상이한 구현예를 이용하는 i18n URL 도메인들이 고유의 것이 아닐 수도 있기 때문에, 특히, 비-라틴어 도메인 네임을 위한 레지스트리 및 구현예들의 수가 비-라틴어 문자 셋트를 이용하는 나라들의 예상 수요에 맞춰 증가되는 경우에 혼란을 초래한다는 것이다. 또 한가지 문제점은 사용자들이 비-라틴어 문자를 입력한다는 것이다. 세계적으로 대부분의 컴퓨터들은 라틴어 문자 셋트를 위한 입력 기능만을 가진 운영체제를 이용한다. 이러한 컴퓨터들의 사용자들은 i18n 도메인들의 비-라틴어 URL로 타이핑하기 위한 기능을 갖고 있지 않으며, 따라서 이들 URL에 액세스할 수 없다. 일부의 운영체제들은 하나의(또는 소수의) 비-라틴어 문자 셋트를 위한 입력 기능을 갖고 있다(예를 들어, 중국어판 윈도즈 95, 일본어판 윈도즈 98). 비-라틴어 문자의 입력을 허용하도록 운영체제와 통합된 언어 입력 프로그램들도 역시 존재한다(예, 중국어 입력을 위한 HansVision). 그런데, 이러한 시스템에 있어서의 한가지 문제점은 사용자들이 i18n 도메인의 URL을 타이핑할 수 없으며, 따라서 상이한 문제 셋트의 i18n 사이트의 URL에 액세스할수 없다는 것이다(예를 들어, 중국어 운영체제를 이용하는 사용자가 타밀(Tamil) URL 사이트에 들어가길 원하는 경우가 있다).

본 발명은 URL 어드레스 검색에 관한 것이다.

이제, 첨부도면을 참조하여 본 발명의 일실시예에 대해 설명된다.

도1은 본 발명의 일실시예에 사용되는 주요 구성요소를 예시한 개략도.

도2는 본 발명의 방법의 일실시예를 예시한 흐름도.

도3은 도2의 다중-언어 URL을 얻기 위한 단계를 설명하기 위한 흐름도.

도4는 도2의 i18n 도메인을 변환하는 단계를 설명하기 위한 흐름도.

도5는 도2의 콘텐츠 펫치 및 필터 단계를 설명하기 위한 흐름도.

따라서, 본 발명의 목적은 전술한 종래기술의 문제점중 적어도 하나의 문제점을 완화시키거나 사용자에게 유용한 선택사항을 제공하는 URL 어드레스 검색 방법을 제공하는 것이다.

본 발명의 제1 양태에 따르면, 사용자에 의해 입력되는, 도메인 네임을 가진 비-라틴어 문자 URL을 변환하는 방법이 제공되며, 이 방법은, 상기 URL이 쓰여진 문자 셋트를 선택하는 단계; 상기 문자 셋트로부터의 문자로 상기 URL을 입력하는 단계; 상기 입력된 URL의 문자 셋트를 이용하여, 상기 선택된 문자 셋트로 도메인 네임을 지원하는 하나 또는 그 이상의 네임 서버를 결정하는 단계; 상기 도메인 네임으로 적어도 하나의 상기 네임 서버에 질의하는 단계; 및 상기 질의가 충족되는 경우에 상기 URL로부터 콘텐츠를 펫치하는 단계를 포함한다.

본 발명의 제2 양태에 따르면, 인터넷 브라우저를 이용하여 사용자에 의해 입력되는, 도메인 네임을 가진 비-라틴어 문자 URL을 변환하는 방법이 제공되며, 이 방법은, 비-라틴어 문자 URL 변환을 지원하는 웹사이트에 접속하는 단계; 상기 웹사이트로부터 비-라틴어 문자 URL 입력 프로그램을 다운로드하는 단계; 상기 프로그램을 이용하여 상기 URL을 입력하고, 상기 URL을 상기 웹사이트로 전송하는 단계; 상기 웹사이트에서, 상기 URL의 문자 셋트를 이용하여, 선택된 문자 셋트로 도메인 네임을 지원하는 하나 또는 그 이상의 네임 서버를 결정하는 단계; 상기 웹사이트로부터 상기 도메인 네임으로 적어도 하나의 상기 네임 서버에 질의하는 단계; 및 상기 질의가 충족되는 경우에 상기 URL로부터 콘텐츠를 펫치하고, 상기 콘텐츠를 사용자에게 전달하는 단계를 포함한다.

전술한 본 발명의 양태들에 따른 방법을 수행하기 위한 장치도 역시 본 발명의 일부를 형성하는 것으로 간주되며, 본 발명의 다른 특징들은 첨부된 특허청구범위에 기재되어 있다.

본 발명의 전술한 방법에 있어서, 사용자는 비-라틴어 문자 URL을 입력하기 위해 자바스크립트 및/또는 자바 지원 프로그램을 가진 어떠한 인터넷 브라우저도 이용할 수 있으며, 그의 컴퓨터 상에 추가적인 소프트웨어를 설치하지 않고, 그리고 클라이언트측 셋팅을 변경하지 않고 비-라틴어 문자 콘텐츠를 검색하고 관찰할 수 있다. 본 발명의 실시예는 i18n의 서로 다른 방법(솔루션)이 수용되도록 허용한다. 비-라틴어 문자 URL을 입력하고, 추가적인 소프트웨어 없이 관찰하기 위해 비-라틴어 문자 웹페이지를 동적으로 그래픽스로 변환하기 위한 비-라틴어 문자 에디터가 제공된다. 사용자는 언어 인코딩과 함께 입력 방법을 선택한다. 각각의 입력 방법에 대해, 사용자가 타이핑할 때 사용자가 문자를 선택할 수 있도록 하기 위해 웹 서버로부터 펫치되는 그래픽스를 통해 문자의 선택사항들의 리스트가 디스플레이된다. 각각의 문자는 고유의 유니코드(Universal Character Set ISO/IEC 10646 구현예) 표현을 갖고 있으며, 이것은 본 발명의 실시예에서 유니코드를 추적하고 그 파일 네임으로서 유니코드를 가진 그래픽스를 이용하여 문자를 디스플레이할 수있도록 허용한다.

유니코드는 본 발명의 이용할 수 있는 가능한 문자 인코딩의 일례에 불과하다. 바람직한 구현예에 있어서, 문자 그래픽스 웹 서버는 상이한 언어로 복수의 문자 그래픽스 셋트를 포함할 수 있으며, 문자 코드를 URL 네임에 맵핑시키는 네이밍 표준을 가진 문자 코딩을 상이한 폴더에 포함할 수 있다. URL의 펫치된 콘텐츠는 그래픽 표현으로 동적으로 변환될 수 있으며, 이것은 사용자가 추가적인 소프트웨어 없이 비-라틴어 문자 콘텐츠를 관찰할 수 있도록 허용한다.

전술한 방법은 i18n 도메인의 어떠한 구현예도 포함할 수 있는 i18n 도메인 URL을 변환할 수 있다(현재, i-DNS 및 CNNIC에 의해 제공되는 2개의 공지된 구현예가 존재한다). 도메인 네임 질의는 i18n 도메인들의 특정 구현예를 지원하는 네임 서버로 전송된다. 클라이언트측에는, i18n 구현예중 하나를 사용자가 선택할 수 있도록 하기 위한 기능이 제공되는 것이 바람직하다. 또한, IP 어드레스를 성공적으로 응답하는 첫번째 i18n 도메인 방법의 도메인 호스트의 IP 어드레스가 사용되도록 변환을 위해 i18n 방법들의 디폴트 순서가 제공되는 것이 바람직하다. 콘텐츠가 펫치된 이후에, 그 콘텐츠 내의 URL이 i18n 도메인을 포함하고 있는 경우에, 이 URL이 i18n 도메인을 변환할 수 있는 자바스크립트 코드와 대체될 수 있도록 콘텐츠가 필터링될 수 있다.

본 발명의 방법의 원리를 설명하기 위해, 도1은 사용된 상이한 구성요소의 하이-레벨 개략도를 도시하고 있다. 인터넷(100)에 접속된 컴퓨터의 사용자에 의해 오픈되는 인터넷 브라우저(110)가 제공된다. 사용자는 다운로드 가능한 프로그램들, 즉, 본 발명의 방법을 지원하는 비-라틴어 문자 에디터 툴바(editor toolbar)(120)와 자바스크립트(JavaScript) 및 자바 애플릿(Java applet)(125)을 포함하는 웹 서버(140)에 접속된다. 네임 리졸버 프로그램(name resolver program)(145)도 역시 서버(140)에 배치되며, 서버측에서 도메인 네임 변환을 수행하는데 필요로 된다. 인터넷에는 3가지 상이한 형태의 서버, 즉 통상적인 네임 서버(10)(예, Bind)와, IDNS에 의해 제공되는 i18n 도메인 솔루션을 이용하는 네임 서버(11), 및 CNNIC에 의해 제공되는 i18n 도메인 솔루션을 이용하는 네임 서버(12)가 접속될 수 있다.

먼저, 본 발명의 방법의 동작의 개요에 관해 설명한다. 사용자는 인터넷 브라우저(110)를 오픈하여, 웹 서버 사이트(140)로 브라우징할 수 있다.브라우저(110)는 관련 자바스크립트 및 숨은(hidden) 자바 애플릿(125)을 이용하여 비-라틴어 문자 에디터 툴바 웹페이지(120)를 검색한다. 비-라틴어 문자 에디터(120)는 국제적인 문자들의 본질적인 변환을 위해 유니코드(Unicode)로 동작하는데, 다른 코딩 방식을 사용할 수도 있으며, 또는 사용자로 하여금 사용될 코딩 방식을 선택하도록 할 수도 있다. 사용자는 어드레스를 형성하는 문자들에 대한 입력 방법을 선택하고, 다음에, 문자 입력을 허용하는 툴바가 디스플레이되도록 하는 클라이언트 브라우저(110) 내의 자바스크립트 프로그램(125)을 실행함으로써 비-라틴어 문자 도메인 URL이 입력될 수 있다. 자바스크립트 프로그램은 사용자가 입력한 어드레스를 포착하고(capture), 사용자가 선택한 입력 방법에 근거하여 사용자가 선택한 유니코드 문자를 결정한다. 다음에, 자바스크립트는 웹 서버(140)로부터 그래픽스 파일(유니코드와 동등한 파일네임을 가짐)을 펫치함으로써 유니코드 문자를 디스플레이하게 되며, 그에 따라 사용자가 그의 컴퓨터에 비-라틴어 문자 소프트웨어를 설치할 필요없이 유니코드 문자가 그 프래픽 표현으로 동적으로 변환될 수 있게 된다.

다음에, 사용자는 그가 방금 입력한 비-라틴어 문자 도메인 URL로 브라우징할 의도로 <enter> 키를 누른다. 중요한 것은 본 발명의 소프트웨어는 URL을 입력하기 위해 사용된다는 것이다. 예를 들어, 만일 사용자가 다른 소프트웨어를 이용하여 브라우저(110) 어드레스 바에 URL을 입력하고 <enter> 키를 눌렀다면, 브라우저(110)는 (통상적으로)운영체제 또는 브라우저에 구성된 것과 같은 디폴트(default) 네임 서버를 이용하여 직접 URL을 펫치하게 된다. 만일 그 네임서버가 i18n 어드레스를 변환할 수 없다면, 호스트 네임 찾기는 실패하게 된다. 비록 디폴트 네임 서버가 i18n 어드레스를 변환할 수 있다 하더라도, 그것이 i18n 도메인 네임 표준의 오직 하나의 구현예에만(예를 들어, iDNS 또는 CNNIC) 적합한 것일 가능성이 매우 높으며, 그러므로 호스트 네임 찾기 실패가 일어날 수 있다(사용자가 iDNS 표준으로 i18n 도메인을 원하지만, 디폴트 네임 서버 셋팅은 예를 들어, CNNIC로 셋팅되었는 경우가 있다).

다음 단계는 비-라틴어 문자 도메인을 IP 어드레스로 변환하는 것이다. 컴퓨터 상의 네임 서버 셋팅은 통상적으로 그 현재 날짜에서 통상적인 네임 서버(11)를 지시하게 된다. 만일 도메인 네임 질의(query)가 이러한 네임 서버(11)로 전송되면, 그 네임 서버(11)는 에러로 응답하게 되는데, 그 이유는 비-라틴어 문자 도메인 네임이 유효한 표준 도메인 네임(라틴어 알파벳, 숫자 및 하이펀으로 이루어진 것만 허용됨)이 아니기 때문이다. 본 발명의 방법에 있어서, 도메인 네임 질의는 자바 애플릿(125) 또는 네임 리졸버(145)에 의해 수행되는데, 이것은 유니코드 표현으로부터 URL이 라틴어 문자 형태되어 있는지 여부를 판단한다. 네임 리졸버는 i18n 도메인 구현예의 각각의 형태에 대한 도메인 네임 서비스를 제공하는 잘 알려진 IP 서버들의 리스트를 유지하고 있다. 그러므로, 도메인 네임 질의는 비-라틴어 문자 도메인 네임을 어떻게 변환할 것인지 알고 있는 올바른 네임 서버로 전송되게 된다. 예를 들어, 비-라틴어 문자 도메인 네임 질의는 IDNS 네임 서버(11) 및/또는 CNNIC 네임 서버(12)로 전송될 수 있다.

이들 서버(11,12)는 상호 배타적인 것이 아니기 때문에, 동일한 비-라틴어문자 도메인이 서로 다른 당사자들에 의해 등록되어, 충돌(conflict)을 초래할 수도 있다. 이것은 본 발명의 방법에서 사용자가 i18n 도메인 솔루션 공급자를 선택할 수 있도록 함으로써 해결된다.

클라이언트측 도메인 네임 질의는 변환을 수행하기 위해 자바 애플릿(125)을 이용하고, 서버측 도메인 네임 질의는 변환을 수행하기 위해 네임 리졸버를 이용하게 된다. 이들 솔루션은 모두 기본적으로는 유사하지만, 서버측 솔루션이 더욱 유연성이 있으며(flexible), 보다 양호한 특징을 가질 수 있다. 예를 들어, 네임 리졸버(145) 상에서 네임 서버 리스트 정보를 갱신하는 것이 보다 용이하며, 이것은 진보된 캐싱(caching)을 지원할 수 있다. 클라이언트측 솔루션에 있어서, 자바 애플릿(125)은 보다 먼저 변환된 IP 어드레스에 근거하여 URL의 콘텐츠의 펫치를 진행한다.

콘텐츠가 펫치된 이후에, 자바 애플릿은 콘텐츠내의 URL이 i18n 도메인을 포함하는 경우에 이 URL이 자바스크립트 코드로 대체되도록 콘텐츠를 필터링하게 되고, 이 코드는 사용자가 그것에 클릭했을 때 i18n 도메인 URL을 변환하도록 하는 요구를 자바 애플릿(125)으로 전송하게 된다. 다음에, 자바 애플릿(125)은 브라우저(110) 내의 다른 프레임에 콘텐츠를 디스플레이한다. 서버측 솔루션에 있어서, 콘텐츠는 펫치되어, 웹서버가 그것을 클라이언트 브라우저(110)로 반송하기 전에 필터링될 수 있다. 그러므로, 본 발명의 방법은 그 네임 서버 솔루션이 표준 네임 서버 솔루션을 지원하는 한 서로 다른 i18n 도메인 구현예들로부터 어떠한 i18n 도메인 네임도 변환할 수 있다. 다시 말하면, 네임 서버의 콘텐츠 및 설계는 RFC1034 및 RFC 1035에 기술된 것에 따라야 한다. 특히, DNS 질의 및 응답은 i18n 도메인 구현예와 무관하게 각각의 네임 서버에 질의하기 위해 동일한 리졸버가 사용될 수 있도록 RFC 1034 및 RFC 1035에 기술된 바와 같은 표준 메시지 포맷으로 수행되어야 한다.

도2는 본 발명의 방법의 흐름도를 도시하고 있다. 제1 단계에서, 사용자는 비-라틴어 문자 URL을 입력하기 위해 비-라틴어 문자 에디터를 이용한다(블록20에 도시됨). 다음에, URL의 도메인 부분은 IP 어드레스를 얻기 위해 변환된다(블록21에 도시됨). URL의 콘텐츠는 IP 어드레스에 근거하여 펫치되며, i18n 도메인을 포함하는 URL을 자바스크립트 코드로 대체하기 위해 콘텐츠가 필터링된다(블록22에 도시됨). 다음에, 콘텐츠는 비록 브라우저가 비-라틴어 문자를 지원하지 않는다 하더라도 사용자의 브라우저에 디스플레이된다(블록23에 도시됨).

블록(20)으로 표시된 프로세스는 사용자에 의해 개시되며, 도3에 보다 상세하게 도시되어 있다. 블록(201)에서는, 서버(140)상의 웹페이지로부터 다운로드된 비-라틴어 문자 URL 에디터 툴바가 브라우저 프레임에 디스플레이된다. 사용자는 인터넷 북마크를 이용하여 이 웹페이지에 편리하게 접속할 수 있으며, 또는 사용자가 직접 브라우저의 인터넷 어드레스 바에 URL을 입력할 수 있다. 현재의 인터넷 익스플로러 브라우저는 브라우저의 좌측 또는 하단에 위치될 수 있고 용이한 액세스를 위해 링크 툴바로부터 호출될 수 있는 이러한 주문형 툴바(custom toolbar)들을 지원한다. 비-라틴어 문자 에디터는 사용자 컴퓨터상에서 어떠한 클라이언트측 설치나 또는 구성을 위한 셋팅을 필요로 하지 않으며, 어떤 종류의 언어 및 입력방법도 지원하도록 확장될 수 있으며, 이러한 모든 것은 사용자가 그것을 인지할 필요없이 서버에서 갱신될 수 있다. 사용자의 컴퓨터는 어떠한 언어 폰트도 설치할 필요가 없으며, 브라우저는 비-라틴어 문자 언어를 지원할 필요가 없다. 각각의 비-라틴어 문자는 웹 서버에 저장된 그래픽스 파일을 이용하여 디스플레이된다. 언어 인코딩 및 문자의 유니코드 표현에 관한 지식을 이용하여, 대표하는 그래픽스 파일이 유니코드에 의해 네이밍될 수 있으며, 그러므로 이것은 어떠한 비-라틴어 문자 웹페이지라도 디스플레이될 수 있도록 허용한다.

블록(202)에서, 사용자는 언어 및 입력 방법을 선택한다. 이렇게 함으로써, 웹페이지내의 자바스크립트 코드는 선택된 입력 방법에 대응하는 적절한 사전(dictionary)을 다운로드하고, 따라서, 사용자가 키로 입력하는 것을 문자 코드로 맵핑시킬 수 있게 된다. 자바스크립트는 인터넷 익스플로러 및 넷스케이프 브라우저를 포함하여 일반적인 대부분의 브라우저에 의해 지원되는 그대로 사용된다. 블록(203)에서, 실행중인 자바스크립트 코드는 사용자에 의해 입력되는 키들을 포착하고, 문자들의 가능한 선택사항에 일치성에 대해 사전이 검사된다. 만일 단지 하나의 선택사항만이 존재하면, 문자 코드가 결정되고, 그렇지 않으면, 블록(204)에 도시된 바와 같이 사용자가 선택하도록 하기 위해 선택사항들의 리스트가 디스플레이된다. 모든 문자들은 웹 서버로부터 그것들의 대표하는 그래픽스 파일을 펫치함으로써 디스플레이된다. 블록(205)에서, 사용자는 디스플레이된 선택사항들의 리스트로부터 그래픽 문자를 선택하게 되고, 따라서 문자 코드가 결정된다. 블록(206)에서, 자바스크립트 코드는 내부 URL 스트링에 유니코드 문자 코드를 부가하고, 또한 URL 에디터에서 그래픽스 문자를 디스플레이한다. 이러한 프로세스는 사용자가 입력을 완료하고 그 URL에 의해 표시되는 웹페이지를 브라우징하기를 원한다는 것을 신호하기 위해 <enter> 키를 누르기 전에, 사용자가 완전한 URL을 키로 입력할 때까지 반복된다. 비록 블록(202)에서 사용자에 의해 변경되지 않는 한 기존의 언어 및 방법이 디폴트로서 남아 있는다 하더라도, 사용자는 또한 블록(202)에서 다른 언어 및 입력 방법으로 전환하여, 각각의 문자가 유니코드와 등가인 복수의 문자 셋트로 URL을 입력할 수 있다. 사용자가 다른 언어 및/또는 입력 방법으로 전환하면, 자바스크립트 코드에 의해 다른 사전이 자동적으로 다운로드될 수 있다. 자바스크립트 코드는 사용자가 블록(20)의 프로세스의 끝에서 키로 입력한 유니코드 스트링 URL을 저장하게 된다.

블록(21)에서는, 호스트 IP 어드레스를 얻기 위해 URL의 도메인 부분이 변환된다. 이러한 프로세스는 도4에 보다 상세하게 도시되어 있다. i18n 도메인 솔루션에 대해 현재 적어도 2개의 제안이 존재하며, 하나는 IDNS에 의해 제공되고, 다른 하나는 CNNIC에 의해 제공된다. 비-라틴어 문자 도메인 네임에 대해 매우 큰 산업상 가치가 있기 때문에, 더욱 많은 i18n 도메인 제안이 출현할 것으로 예상된다. 이와 같이, 도메인 네임이 어떠한 i18n 도메인 솔루션에 대해서도 정확하게 변환될 수 있는 것이 바람직하다. i18n 도메인 솔루션이 현재의 표준 도메인 네임 서버와 호환성이 있으면, 본 발명의 방법은 이것을 수용할 수 있으며, 만일 i18n 도메인 네임 서버가 동일한 종류의 표준 도메인 네임 질의를 수신하고, 그 질의를 전송한 클라이언트로 IP 어드레스를 반송할 수 있으면, 그것은 호환성이 있는 것이다. 현재, IDNS와 CNNIC 솔루션은 둘다 호환성이 있다. 본 발명의 방법은 선택된 i18n 도메인 솔루션을 지원하는 올바른 도메인 네임 서버에 질의하는 것을 필요로 하며, 또는 단순히 IDNS나 CNNIC에 의해 제공되는 i18n 도메인 솔루션을 지원하는 모든 네임 서버에 질의할 수 있다.

일반적으로, 어떤 도메인이 등록된 i18n 도메인 솔루션(도메인 레지스트라)를 구별하는 것이 불가능하기 때문에, 사용자는 비-라틴어 문자 에디터 툴바에서 i18n 도메인 솔루션을 선택할 수 있다. 소프트웨어가 도메인 네임을 질의할 때 그것이 다른 솔루션의 네임 서버 이전에 한 도메인 솔루션의 네임 서버들에 대하여 수행되도록 i18n 도메인 솔루션들의 디폴트 순서(ordering)가 제공된다. 실제적으로, 이러한 구현예에 있어서는 속도를 높이기 위해 병렬로 서로 다른 i18n 도메인 솔루션들의 네임 서버들에 질의하고, 디폴트 순서를 이용하여 IP 어드레스를 반송할 수 있다. 서로 다른 도메인 솔루션에 등록된 도메인 네임의 충돌이 존재하기 때문에, 디폴트가 자신이 원하는 것이 아닌 경우에 다른 호스트(IP 어드레스)에 시도하기 위한 옵션이 사용자에게 부여된다. 도4는 도메인 네임 질의 프로세스가 직렬로 수행되는 것을 도시하고 있지만, 이 프로세스는 병렬로도 수행될 수 있다.

블록(211)에서, 프로세스는 도메인이 표준 URL 문자들로 되어 있는지 검사하고, 만일 그렇다면, 그 URL의 콘텐츠가 정상적으로 검색된다. 그러나, 만일 그 도메인이 i18n 도메인이면, 본 발명의 방법은 블록(212)에 도시된 바와 같이 i18n 도메인 솔루션의 전체 리스트를 먼저 검색함으로써 그 도메인을 변환하는 과정을 수행한다(예, IDNS 및 CNNIC). 블록(213)에서는, 도메인 솔루션이 선택되고, 그 선택된 도메인 네임 솔루션을 지원하는 도메인 네임 서버들의 리스트가 검색된다. 현재, 이러한 서버 IP 어드레스들의 리스트는 수동으로 컴파일될 수 있으며, 프로세스가 이용하도록 구성될 수 있다. (블록(214)에 도시된 바와 같이) 리스트 내의 각각의 도메인 네임 서버에 대해, 프로세스는 블록(215)에 도시된 바와 같이 도메인 네임 질의를 전송한다. 만일 도메인 네임 서버가 IP 어드레스를 응답하면, 프로세스는 블록(216)에 도시된 바와 같이 완료된다. 그러나, 실제적으로는 전술한 바와 같이 도메인 네임 충돌을 해결하기 위해 서로 다른 i18n 도메인 솔루션으로부터 하나 이상의 IP 어드레스가 응답될 수 있다. 만일 도메인 네임 서버가 에러로 응답하면, 리스트내의 다른 네임 서버에 대하여 도메인 네임 질의를 반복하기 위해 블록(217)이 실행된다. 블록(218)에서, 프로세스는 그 솔루션을 지원하는 네임 서버들의 다른 리스트에 대하여 동일한 도메인 네임 질의를 전송함으로써 다른 도메인 네임 솔루션에 대해 반복된다(이것은 실제적으로 병렬로 수행될 수 있다).

도메인 네임 변환 프로세스는 클라이언트측에서 구현되거나 또는 서버측에서 구현될 수 있다. 클라이언트측 솔루션은 자바 애플릿을 이용하여 구현될 수 있다. 서버측 솔루션이 보다 유연성이 있으며, 보다 양호한 특징을 가질 수 있다. 예를 들어, 네임 리졸버(145) 상에서 네임 서버 리스트 정보를 갱신하는 것이 보다 용이하며, 이것은 보다 빠른 변환을 위해 진보된 캐싱을 지원할 수 있다. 만일 클라이언트측 솔루션이 사용되면, 블록(22)에 도시된 바와 같이, URL의 콘텐츠를 펫칭하고 필터링하는 프록세스가 동일한 자바 애플릿내에 구현될 수 있다. 대신에, 만일 서버측 네임 리졸버(145)가 사용되면, 클라이언트측이나 또는 서버측 펫칭 및 필터링의 선택권이 주어진다. 클라이언트측 펫칭 및 필터링은 서버의 작업을 분담하는(offload) 장점이 있지만, 크라이언트측 코드를 더욱 복잡하게 만든다. 서버측 필터링은 양호한 캐싱에 의해 콘텐츠의 URL내의 모든 i18n 도메인을 한번에 변환할 수 있다.

블록(22)에서는, IP 어드레스를 이용하여 URL의 콘텐츠가 펫치되고, 그 콘텐츠는 사용자가 클릭했을 때 i18n 도메인 URL을 변환하도록 하는 요구를 자바 애플릿으로 전송하는 자바스크립트 코드로 i18n 도메인을 포함하는 URL을 대체하기 위해 필터링된다. 만일 i18n 도메인을 포함하는 원래의 URL이 클릭되면, 브라우저는 디폴트 도메인 네임 질의를 이용하게 되며, 이것은 표준 네임 서버에 대하여 실패할 수ㄷ 있다. 그러므로, 이러한 문제점을 해결하기 위해 콘텐츠가 필터링된다. 만일 이러한 i18n 도메인들을 그들의 IP 어드레스로 대체함으로써 콘텐츠를 디스플레이하기 전에 이들 도메인들이 변환되는 경우 조차도, 그것이 모든 경우에 제대로 동작한다 보장하는데에는 충분하지 않다. 어떤 IP 어드레스에서 웹 서버가 복수의 도메인에 호스트하기 위해 선택하는 경우에, 그 URL내의 원래의 도메인 부분의 손실은 그 웹 서버가 그 URL 콘텐츠를 검색하는 것을 방해하게 된다. 본 발명의 방법에 사용되는 솔루션은 URL을 자바스크립트 기능 호(JavaScript function call)로 대체하고, 그것에 원래의 URL의 파라미터를 전달하는 것이다(이미 변환된 경우에 호스트 IP 어드레스에 대한 추가의 파라미터가 전달될 수 있다). 사용자가 대체된 URL에 클릭하면, 콘텐츠를 펫치하기 위해 자바스크립트 기능이 개시되며, 이러한 기능은 사용자가 비-라틴어 문자 에디터를 이용하여 키로 입력하는 URL의 콘텐츠를펫치하는 것과 유사하다. 이러한 펫칭 및 필터링 프로세스는 도5에 보다 상세하게 도시되어 있다.

블록(221)에서는, URL의 콘텐츠가 펫치된다. 프로세스는 웹 서버에 접속하기 위해 변환된 호스트 IP 어드레스를 이용하며, 원래의 URL의 콘텐츠를 펫치한다. 펫치된 콘텐츠는 다음에 블록(222)에서 파싱된다(parsed). 블록(223)에서는, 콘텐츠내의 각각의 URL이 추출된다. 다음에, 블록(224)에서 i18n 도메인 네임을 포함하고 있는지 알기 위해 URL을 검사한다. 만일 포함하고 있다면, 그것은 블록(225)에 도시된 바와 같이 자바스크립트 기능 호에 의해 대체된다. 블록(226)은 콘텐츠내의 추출된 각각의 URL에 대해 프로세서가 반복된다는 것을 예시하고 있다. 다음에, 갱신된 콘텐트가 응답되고, 프로세스는 완료된다. 다음에는, 블록(23)에 도시된 바와 같이 콘텐츠가 브라우저 프레임에 라이트백(write back)된다.

전술한 본 발명의 방법은 제한적인 것으로 간주되어서는 안된다. 예를 들어, 비록 전술한 실시예에서 UNICODE 문자 코딩과, 스크립팅 언어로서의 자바스크립트, 및 프로그래밍 언어로서의 자바(Java)가 사용되었지만, UNICODE 대신에 또는 그와 함께 다른 적절한 코딩 방식과, Periscript 또는 Vbscript와 같은 다른 스크립팅 언어, 및 다른 바이트코드 해석 프로그래밍 언어가 사용될 수도 있다.

예를 들어, 문자 그래픽스 웹 서버는 서로 다른 폴더에 서로 다른 언어 및 코딩으로 복수의 문자 그래픽스 셋트를 포함할 수 있으며, 문자 코드를 URL 네임에 맵핑시키는 네이밍 표준을 포함할 수 있다. 예를 들어, 단어 六(6의 중국어)은 GB2312 코드로 0xC1F9 코드이고, 그 그래픽스는 폴더 gb 아래에 웹 서버에 저장될수 있으며, 그러므로, URL http://[graphics_web_server_domain]/gb2312/C1F9.gif를 가질 수 있다. 동일한 단어 六은 또한 Unicode version 3.0으로 0x516D 코드이고, 그 그래픽스는 폴더 unicode3 아래에 동일한 웹 서버에 저장될 수 있으며, 그러므로, URL http://[graphics_web_server_domain]/unicode3/516D.gif를 가질 수 있다. 각각의 문자에 대한 파일 네임 및 폴더에 대한 네이밍은 로딩된 사전을 참조하여 자바스크립트/자바 코드에 의해 결정된다. GB2312 코딩을 위해 실장된 "Hanyupinyin input method" 사전은 중국어로 '6'에 대한 입력 "liu4"에 대해 그래픽스를 http://[graphics_web_server_domain]/gb2312/C1F9.gif로 지시할 수 있으며, Unicode 코딩을 위해 실장된 다른 "Hanyupinyin input method" 사전은 중국어로 '6'에 대한 동일한 입력 "liu4"에 대해 그래픽스를 http://[graphics_web_server_domain]/unicode3/516D.gif로 지시할 수 있다.

실제적인 용도에 있어서, 바람직한 형태로, 많은 수의 상이한 그래픽스 셋트 및 사전들의 유지관리를 최소화하기 위해 가능한 한, 모든 문자 그래픽스 파일들이 유니코드로 배열될 수 있으며, 모든 사전들이 유니코드로 개별화될 수 있다(이것은 유니코드가 다수의 언어의 문자들을 포함하기 때문이다).

비-라틴어 문자 URL에 대한 레퍼런스는 비-라틴어 문자 도메인 네임 및 라틴어 또는 비-라틴어 문자 경로 부분을 가진 URL에 대한 레퍼런스를 포함한다.

참조문헌

UTF-5. a transformation format of Unicode and ISO 10646

http://www.idns.org/technical/draft-jseng-utf5-00.txt

iDNS, an Experimental DNS System with Unicode Support

http://www.idns.org/technical/iuc14-paper.doc

P.V. Mockapetris, Domain names - implementation and specification,

RFC1035, November 1987

P.V. Mockapetris, Domain names Concepts and Facilities,

RFC1034, November 1987

Martin Duerst, Internationalization of Domain Names, Internet Draft,

July 1997, extended in 1998

The Unicode Standard, URL http://www.unicode.org

Claims

사용자에 의해 입력되는, 도메인 네임을 가진 비-라틴어 문자 URL을 변환하는 방법에 있어서,

상기 URL이 쓰여진 문자 셋트를 선택하는 단계;

상기 문자 셋트로부터의 문자로 상기 URL을 입력하는 단계;

상기 입력된 URL의 문자 셋트를 이용하여, 상기 선택된 문자 셋트로 도메인 네임을 지원하는 하나 또는 그 이상의 네임 서버를 결정하는 단계;

상기 도메인 네임으로 적어도 하나의 상기 네임 서버에 질의하는 단계; 및

상기 질의가 충족되는 경우에 상기 URL로부터 콘텐츠를 펫치하는 단계

를 포함하는 방법.
제1항에 있어서,

상기 입력된 URL의 각각의 문자를 대응하는 수치값으로 변환하는 단계

를 더 포함하는 방법.
제2항에 있어서,

상기 값은 유니코드 수치 코드인

방법.
선행항중 어느 한 항에 있어서,

상기 URL을 입력하는 단계는 문자 입력 프로그램을 이용하는

방법.
제4항에 있어서,

상기 프로그램은 상기 결정 단계, 질의 단계 및 펫치 단계가 수행되는 원격 위치로부터 다운로드되는

방법.
제5항에 있어서,

상기 원격 위치는 웹사이트를 포함하는

방법.
제4항 내지 제6항중 어느 한 항에 있어서,

상기 프로그램은 사용자의 인터넷 브라우저 상에 URL 입력 툴바를 디스플레이하는

방법.
선행항중 어느 한 항에 있어서,

상기 입력 단계는 사용자에 의해 선택된 각각의 문자의 입력 방법을 이용하는

방법.
선행항중 어느 한 항에 있어서,

상기 각각의 문자는 원격 위치에 있는 데이터베이스를 참조하여 식별되는

방법.
제9항에 있어서,

상기 데이터베이스는 각각의 문자의 그래픽 표현을 포함하고, 상기 식별된 문자의 그래픽 표현은 디스플레이를 위해 사용자에게 전송되는

방법.
제4항 내지 제6항중 어느 한 항에 있어서,

상기 식별된 문자들은 상기 결정 단계에서 사용하기 위해 상기 URL의 식별된 버전을 형성하도록 함께 저장되는

방법.
선행항중 어느 한 항에 있어서,

상기 결정 단계에서, 선택된 언어로 도메인 네임을 지원하는 하나 이상의 네임서버가 결정되는

방법.
제8항에 있어서,

각각의 네임 서버는 상기 도메인에 대해 질의되는

방법.
제8항에 있어서,

사용자에 의해 선택된 하나 또는 그 이상의 네임 서버들만이 질의되는

방법.
제7항 내지 제10항중 어느 한 항에 있어서,

상기 네임 서버들은 사용자에 의해 선택된 순서로 질의되는

방법.
제7항 내지 제11항중 어느 한 항에 있어서,

상기 결정 단계에서, 네임 서버들의 리스트가 질의되는

방법.
제12항에 있어서,

상기 리스트는 사용자에 의해 유지되는

방법.
제12항에 있어서,

상기 리스트는 원격 서버 상에서 유지되는

방법.
선행항중 어느 한 항에 있어서,

상기 URL의 펫치된 콘텐츠를 검색하고, 거기서 발견된 비-라틴어 문자 URL을 그 발견된 URL을 변환하기 위한 수단으로 대체하는 단계

를 더 포함하는 방법.
제19항에 있어서,

상기 수단은 상기 발견된 URL을 자바스크립트 기능 호로 대체하고, 상기 발견된 URL의 파라미터를 상기 기능 호로 전달하는 단계를 포함하는

방법.
인터넷 브라우저를 이용하여 사용자에 의해 입력되는, 도메인 네임을 가진 비-라틴어 문자 URL을 변환하는 방법에 있어서,

비-라틴어 문자 URL 변환을 지원하는 웹사이트에 접속하는 단계;

상기 웹사이트로부터 비-라틴어 문자 URL 입력 프로그램을 다운로드하는 단계;

상기 프로그램을 이용하여 상기 URL을 입력하고, 상기 URL을 상기 웹사이트로 전송하는 단계;

상기 웹사이트에서, 상기 URL의 문자 셋트를 이용하여, 선택된 문자 셋트로 도메인 네임을 지원하는 하나 또는 그 이상의 네임 서버를 결정하는 단계;

상기 웹사이트로부터 상기 도메인 네임으로 적어도 하나의 상기 네임 서버에 질의하는 단계; 및

상기 질의가 충족되는 경우에 상기 URL로부터 콘텐츠를 펫치하고, 상기 콘텐츠를 사용자에게 전달하는 단계

를 포함하는 방법.
선행항중 어느 한 항에서 청구된 바와 같은 방법을 수행하기 위한 장치.