인터넷이나 인트라넷으로 정보를 분산할 때 얻는 이점 중 하나는 다른 국가/지역의 사용자들이 액세스할 수 있는 국제적인 웹 사이트를 만들 수 있다는 것입니다. 사용자는 자신의 언어로 번역된 브라우저 버전을 사용하여 번역된 페이지를 요청할 수 있습니다.
다른 언어로 된 페이지가 들어 있는 웹 사이트를 만들 때 사용자는 브라우저와 웹 서버간에 또는 ASP 스크립트와 COM 구성 요소간에 전달되는 문자열을 변환해야 합니다. 웹 사이트의 모든 페이지가 웹 서버가 사용하는 기본 문자 집합으로 작성되어 있으면 ASP가 자동으로 변환합니다. 그러나, 다른 언어의 브라우저에 대해 다른 문자 집합으로 페이지를 작성하면 문자열의 변환 방법을 지정하는 ASP 명령을 사용해야 합니다. 예를 들어, 사이트의 페이지 일부는 일본어 문자 집합 중 하나로 작성되었고 다른 일부는 중국어 문자 집합 중에 하나로 작성되어 있으면 특정 페이지의 문자열을 처리하는 동안 ASP가 사용해야 하는 문자열 집합을 지정해야 합니다.
ASP는 또한 화폐, 시간, 날짜, 숫자 등에 사용하는 서식과 같은 다른 로케일에 대한 문화적 규정을 지원하는 명령을 제공합니다. 문자열 변환 명령처럼 스크립트가 웹 서버와 브라우저에 기본 로케일을 사용하지 않는 경우에는 로케일 명령을 사용해야 합니다.
국제 웹 사이트의 구조에 대한 많은 디자인 시나리오가 있습니다. 재정이나 시간을 고려해 볼 때 시나리오를 절충하는 것이 최상의 구조가 될 수 있습니다. 가능한 시나리오는 다음 세 가지가 있습니다.
시나리오 1 - 각 웹 페이지 번역
로컬라이저에게 사용자 페이지를 번역하게 하여 값을 지불하는 경우, 각 웹 페이지를 번역하는 것이 경제적인 해결책은 아닐 수 있습니다. 하지만, 특히 정적 컨텐트를 최대화하는 경우, 다른 시나리오에서보다 더 빠른 서버 프로세스가 요구됩니다.
시나리오 2 - 데이터베이스에 저장된 텍스트 세그먼트 번역
웹 사이트 규모가 작거나 자주 내용이 변경되는 웹 사이트의 경우, 세그먼트의 코드 페이지에 의해 인덱스되는 데이터베이스에 텍스트 세그먼트를 모두 저장할 수 있습니다. SQL은 다른 코드 페이지로 문자열을 처리합니다. 액세스는 Response.BinaryWrite로 쓸 수 있는 유니코드 문자열을 처리합니다. 데이터베이스에 저장된 텍스트 세그먼트를 번역하면 로컬라이저에게 번역할 파일 하나만 주면 됩니다. 데이터베이스 호출은 간단한 쿼리이므로 페이지 제공 속도에는 거의 차이가 없습니다.
시나리오 3 - 번역 도구 활용
일부 로케일은 번역 도구로 처리되지 않을 수 있고 번역에 사소한 오류가 생길 수 있으므로 번역된 모든 페이지를 교정하도록 해야 합니다.
There have been some changes since IIS 5.0 was released on Windows 2000에 IIS 5.0가 릴리스된 이후 일부가 변경되었습니다. UTF-8은 일본어에서와 같은 대리 문자를 포함한 모든 멀티바이트 문자로 확장 지원됩니다. 다른 코드 페이지를 사용하여 IIS 내부 개체를 저장하고 검색할 수 있습니다. 예를 들어, 폼 데이터와 서버 변수에는 웹 서버의 기본값이 아닌 다른 코드 페이지를 사용하여 인코드된 문자열이 있습니다. 또한 Ad Rotator와 Content Rotator 같이 설치할 수 있는 IIS 구성 요소는 번역된 문자를 지원합니다. 마지막으로, 페이지에서 코드 페이지와 로케일이 설정되는 방법에 대한 계층 구조를 바꾸는 AspLCID 새 메타베이스 속성과 CodePage 및 LCID의 새로운 두 Response 속성이 있습니다. 자세한 내용은 다음 항목을 참조하십시오.
국제화와 지역화에 대한 사례 연구나 기사를 보려면 TechNet을 방문하십시오.