ASP 및 ASP.NET 세계화 문제

문자 집합 및 코드 페이지

우리 모두는 컴퓨터 화면의 문자가 일련의 바이트일 뿐이라는 것을 알고 있습니다. 바이트 계열은 다양한 방법으로 만들고 해석할 수 있습니다. 해석에서 바이트 배열을 만든 인코딩과 다른 인코딩을 사용하는 경우 해석은 가비지로 표시됩니다. 문자 집합(문자 집합)은 일반적으로 브라우저에서 사용되는 인코딩 형식입니다. 서버 쪽 변환에 더 적합한 Codepage 속성은 문자 인코딩 방법을 지정하는 변환 테이블일 뿐입니다.

브라우저는 현재 문자 집합에 따라 폼 게시 데이터를 인코딩합니다. 현재 문자 집합이 "windows-1256"인 경우 서버로의 바이트 전송도 "windows-1256"으로 인코딩됩니다.

ASP가 해석되는 경우 Form 및 Querystring 컬렉션은 코드에서 참조될 때까지 빌드되지 않습니다. 빌드할 때 문자열 데이터는 현재 코드 페이지에 따라 유니코드로 변환됩니다. 기본적으로 ASP와 ASP.NET 모두 유니코드 형식을 사용하여 콘텐츠를 처리합니다. 컬렉션을 참조하기 전에 올바른 코드 페이지를 설정하는 것이 매우 중요합니다. 그렇지 않으면 메모리의 유니코드 표현이 올바르지 않습니다.

codepage를 설정하려면 Session.Codepage 또는 Response.Codepage를 사용합니다. Response.Codepage는 IIS(Microsoft 인터넷 정보 서비스) 5.1 이상 버전에서만 사용할 수 있습니다. 이러한 속성을 설정할 정수 값(문자 집합에 해당)에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하세요.

문자 집합 인식
http://msdn2.microsoft.com/en-us/library/Aa752010.aspx예를 들어 아랍어에 대한 코드 페이지를 설정하려면 다음 코드를 사용합니다.

Session.Codepage = 1256

Response.Codepage는 현재 응답에만 영향을 줍니다. 그러나 Session.Codepage는 현재 사용자가 수행한 모든 응답에 영향을 줍니다. 이러한 속성 중 하나를 사용하여 codepage를 설정하고 Form 및 Querystring 컬렉션을 빌드하면 현재 코드 페이지에서 이러한 변경으로 인해 Response.Write 메서드가 메모리의 유니코드를 현재 코드 페이지로 변환합니다. 이 항목에 대한 자세한 내용은 다음 MSDN 웹 사이트를 참조하세요.

ASP(문자열 변환)에 대한 코드 페이지 설정 http://msdn2.microsoft.com/en-us/library/ms525789.aspx문자 집합 및 코드 페이지와 관련된 문제에 대한 결론은 클라이언트 charset 및 서버 코드 페이지가 일치해야 한다는 것입니다.

언어 수락

ASP 개발자가 사용자가 브라우저에서 설정한 언어를 알고 싶은 경우 개발자는 Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") 변수를 사용하여 사용자가 응답을 읽고자 하는 언어 목록(예: 영어, 독일어 또는 인도어)과 사용자가 이러한 언어를 보고자 하는 기본 설정 순서를 찾을 수 있습니다. ASP.NET Request.UserLanguages 속성에 배열로 유사한 정보가 있습니다.
ASP 코드에서 이 정보를 사용하는 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료의 문서를 확인합니다.

229690 브라우저의 언어 설정에 따라 ASP 로캘 ID를 설정하는 방법
 

인터넷 Explorer 멀티 바이트 문자 집합 표시

멀티 바이트 문자 집합을 표시할 수 있는 유일한 인코딩 형식은 유니코드(UTF-8)입니다. UTF-8을 사용하면 키릴 자모, 인도어 및 일본어 모두를 동일한 페이지에 표시할 수 있습니다. UTF-8을 사용하지 않는 경우 한 번에 이러한 언어 중 하나만 표시할 수 있습니다. 브라우저의 문자 집합을 설정하려면 Response.CharSet 속성을 사용합니다.

페이지의 정적 멀티 바이트 문자

페이지에 직접 저장된 멀티바이트 문자를 표시하려면 먼저 특정 인코딩을 사용하여 페이지를 저장해야 합니다. UTF-8이 가장 좋지만 특정 코드 페이지(문자의 코드 페이지와 일치)도 작동합니다.

Visual InterDev는 ANSI 영어 또는 유니코드로만 저장할 수 있으므로 Microsoft Visual InterDev를 사용하여 ASP 파일을 저장하는 것은 도움이 되지 않습니다. 유니코드로 저장된 ASP 페이지는 ASP에서 지원되지 않습니다.

Microsoft Visual Studio .NET에서는 모든 인코딩에 파일을 저장할 수 있습니다. 이 작업을 수행하는 방법에는 두 가지가 있습니다. 기본 방법은 사용자의 현재 코드 페이지를 사용하여 파일을 저장하는 것입니다. 인코딩을 사용하여 파일을 저장하는 추가 방법은 다음과 같습니다.
파일 메뉴에서 파일 다른 이름으로 저장을 클릭합니다.
다른 이름으로 파일 저장 대화 상자의저장 단추에서 드롭다운 화살표를
클릭합니다. 화살표를 클릭하면 인코딩을 사용하여저장 및 저장 옵션이 표시됩니다
. 인코딩으로 저장을 클릭하면
컴퓨터에 설치된 코드 페이지 목록에서 적용할 인코딩 유형을 선택할 수 있는 고급 저장 옵션 대화 상자가 나타납니다.


참고 이렇게 하면 저장 작업의 인코딩이 변경되지만 한 번만 변경됩니다. 다음 저장은 기본값으로 다시 설정됩니다.

기본 코드 페이지를 변경하려면파일 메뉴에서 고급 저장 옵션을
클릭합니다. 고급 저장 옵션 대화 상자에서 저장 작업의 기본 인코딩을 선택한 코드 페이지로 설정할 수 있습니다.

이러한 메서드는 파일이 디스크에 저장되는 방법과 관련이 있습니다. 그러나 이미 설명한 대로 ASP의 출력을 제어하려면 Session.CodePage 및 Response.CharSet 속성을 설정해야 합니다. IIS 5.1 이상 버전을 사용하면 Response.CodePage 속성을 사용할 수도 있습니다.

서버의 기본 CODEPAGE

페이지의 기본 로캘 및 기본 코드 페이지는 의 레지스트리 설정에 따라 달라집니다. DEFAULT 사용자입니다. 레지스트리 하이브HKEY_USERS\.DEFAULT\Control Panel\International국제 키를 찾을 수 있습니다. IIS에서 선택한 로캘의 동작을 변경할 수도 있습니다.

로그온한 사용자에게 위의 키 또는 시스템 기본값과 동일한 로캘 집합이 있는 경우 사용자 설정이 우선합니다.

예: 기본 로캘의 날짜 형식은 11.1.2004로 설정되고 로그온한 사용자(동일한 로캘 집합 포함)는 날짜 형식을 2004년 11월 1일로 설정합니다. 2004년 11월 1일 설정은 ASP에 적용됩니다.

(ASP.NET 경우 다를 수 있습니다. 일부 설치에서 ASPNET 사용자에게는 로드될 때 HKEY_USERS 아래에 표시되는 고유한 프로필이 있습니다. 다른 경우에는 를 사용합니다. DEFAULT 프로필입니다. 또한 <%@ %> 선언에서 codepage 특성을 사용할 수 있습니다. 다른 인코딩을 사용하여 파일을 저장한 다음, 기본값(예: codepage 932(일본어))으로 저장할 때 사용해야 합니다.

코드 페이지 문제 및 글꼴 변환 문제: 어느 것인가요?

때때로 물음표(?) 문자 또는 문자가 나타나야 하는 상자가 표시될 수 있습니다.

런타임 인코딩 변경 내용

Application_BeginRequest 이벤트에서 requestEncoding 값을 수정하고 요청이 처리되기 전에 적용할 수 있습니다. 응답의 경우 Page_PreRender 이벤트는 출력의 인코딩을 수정할 수 있는 마지막 기회입니다. 또한 Response.Write는 호출하는 즉시 이 버퍼에 문자를 배치하므로 Response.Write를 사용하기 전에 올바른 인코딩을 설정해야 합니다.

원본 데이터가 유니코드가 아닌 경우: 인터넷 Explorer 멀티 바이트 문자 집합을 해석하는 방법은 무엇인가요?

필요한 경우 ASP.NET ASP처럼 동작하도록 할 수도 있습니다. 이렇게 하려면 responseEncoding 및 requestEncoding을 windows-1252(iso-8859-1보다 더 완전한 인코딩)로 설정하고 Response.Charset 속성을 사용하여 텍스트를 올바르게 표시해야 합니다. 이는 windows-1252가 단일 바이트 인코딩 체계이며 버퍼에 추가된 바이트를 수정하지 않기 때문에 작동합니다. 따라서 더블바이트 문자는 일련의 단일 바이트로 전송됩니다. 그런 다음 Internet Explorer Response.Charset 속성을 사용하여 바이트를 해석하는 방법을 알려줄 수 있습니다. 이 시나리오는 원래 데이터가 유니코드 또는 UTF-8(예: COM 개체의 반환 값)으로 저장되지 않거나 데이터가 N이 아닌 필드(예: varchar)에 Microsoft SQL Server 저장된 경우에 필요할 수 있습니다.

세계화 문제 SQL Server 및 ASP.NET

INSERT INTO MusicAlbum (Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'Abida', 4653, 403)
Or:
Dim t As String = "INSERT INTO MusicAlbum(Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'" & TextBox1.Text & "', 4653, 403)"

System.Globalization 네임스페이스

이 네임스페이스는 .NET Framework 세계화 및 지역화의 핵심입니다. 이 네임스페이스에 사용되는 기본 클래스는 CultureInfo 클래스입니다. 날짜/시간 형식, 숫자 형식, 비교 정보 및 텍스트 정보와 같은 문화권별 정보를 보유합니다. CultureInfo 클래스에 대한 자세한 내용은 다음 MSDN 웹 사이트를 참조하세요.

http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo(vs.71).aspxCultureInfo

중립 문화권과 특정 문화권 비교

중립 문화권은 특정 국가/지역이 아닌 언어와 연결된 문화권입니다. 특정 문화권은 언어 및 특정 국가/지역 모두와 연결됩니다.

예: "DE"(중립 문화권)는 독일어를 위한 것이지만, "de-AT"(특정 문화권)는 오스트리아에서 사용되는 독일어를 위한 것입니다. 중립 문화권은 서식 지정에 사용할 수 없습니다.

.NET Framework 클래스의 현재 스레드 및 문화권 인식

출력이 문화권에 종속될 것으로 예상되는 .NET Framework 라이브러리의 모든 클래스 및 메서드에는 다음과 같은 두 가지 기본 제공 동작이 있습니다.

• 출력이 지정된 문화권을 기반으로 하므로 인수를 제공하는 동안 문화권 코드를 지정할 수 있습니다. 선택 사항입니다.

• 누락된 경우(일반적으로 해당) 클래스는 Thread.CurrentThread.CurrentCulture 속성에 검사 유지하고 그에 따라 작동할 수 있을 만큼 지능적입니다.

다음과 유사한 코드를 사용하여 이 속성의 값을 수정할 수 있습니다.

    Dim ci As CultureInfo
        ci = New CultureInfo("de-AT")
        Thread.CurrentThread.CurrentCulture = ci

이 코드 예제에서 "de"는 독일어를 나타내고 "AT"는 오스트리아를 나타냅니다. 따라서 이 instance DateTime.Now()입니다. ToString 메서드는 날짜와 시간이 오스트리아에서 독일어로 표현되는 방식에 해당하는 형식으로 날짜와 시간을 반환합니다.

프레임워크는 다음과 같이 CurrentCulture 속성이 항상 초기화되도록 합니다.

1. 프로그래밍 방식으로 설정됩니다.

2. 프로그래머가 명시적으로 설정하지 않은 경우 속성은 구성 파일(<세계화> 태그)에서 선택됩니다.

3. 속성이 없는 경우 웹 서버가 실행 중인 문화권입니다. 일반적으로 운영 체제의 언어에 해당하는 중립 문화권입니다.

리소스 파일

Visual Studio .NET의 ASP.NET 프로젝트에 추가되는 빌드 작업 특성이 포함된 리소스로 설정된 모든 .resx, .resource 파일 및 파일은 매니페스트의 일부로 애플리케이션 어셈블리 내에 자동으로 컴파일되고 포함됩니다. Visual Studio .NET 명령 프롬프트를 통해 RESGEN(리소스 파일 생성기) 유틸리티를 사용하여 수동으로 수행할 수도 있습니다. 자세한 내용은 다음 MSDN 웹 사이트를 참조하세요.

http://msdn2.microsoft.com/en-us/library/ccec7sz1(vs.71).aspx이는 세계화와 관련이 없는 애플리케이션 리소스를 관리해야 할 때마다 적용되는 일반적인 개념입니다. 그러나 세계화를 구현할 때 위성 어셈블리를 사용해야 합니다.

위성 어셈블리

위성 어셈블리는 다음이 true인지 확인할 때 ASP.NET 프로젝트에서 사용할 수 있습니다.

1. 모든 aspx 파일의 모든 사용자 인터페이스 요소에는 id 및 runat=server 특성이 있어야 합니다.

2. 별도의 .resx 파일을 만듭니다. 각 문화권은 애플리케이션에서 지원하려는 각 문화권에 해당해야 합니다.

3. 이러한 모든 파일에 대한 일반적인 이름을 결정해야 합니다. '문자열'.

4. 다음과 같은 명명 규칙 commonfirstname을 사용하여 별도의 .resx 파일의 이름을 지정합니다 . languagecode-regioncode.resx(예: Strings.de-AT.resx, Strings.en-GB.resx).

5. 기본 사례에 표시하려는 대로 모든 문자열이 있는commonfirstname.resx(Strings.resx) 리소스 파일이
   있어야 합니다.

6. 코드를 작성하여 사용자의 문화권을 검색하고 Thread.CurrentThread.CurrentUICulture 속성을 일치하도록 설정합니다.

7. ResourceManager 클래스를 사용하여 리소스를 로드하는 코드를 작성합니다.

8. 로드된 개체에서 문자열을 추출하고 사용자 인터페이스 요소에 할당하는 코드를 작성합니다.

이러한 단계를 수행하면 Visual Studio.NET Strings.resx를 컴파일하고 애플리케이션 어셈블리(MyGlobalizationTestProjectName.dll)에 포함합니다. 그러나 다른 모든 .resx 파일의 경우 실행 코드가 없지만 리소스 데이터만 있는 별도의 dll 파일을 생성합니다. 이를 실제로 위성 어셈블리라고 합니다. 또한 Visual Studio .NET은 MyGlobalizationTestProjectName
과 유사한 폴더 구조에 배치합니다. |------- bin
|------en-US

MyGlobalizationTestProjectName.resources.dll |------ja-JP

MyGlobalizationTestProjectName.resources.dll |------de-AT
MyGlobalizationTestProjectName.resources.dll

CurrentCulture와 CurrentUICulture의 차이점

System.Globalization 네임스페이스의 클래스 메서드는 Thread.CurrentThread.CurrentCulture 속성에 따라 출력을 제공하지만 리소스 어셈블리를 로드하는 ResourceManager 클래스는 Thread.CurrentThread.CurrentUICulture 속성에 따라 적절한 위성 어셈블리를 로드합니다. 다음은 C# 코드의 예입니다.

using System.Globalization;
using System.Threading;
using System.Resources;

//Load resources. 
protected ResourceManager gStrings = new ResourceManager("MyGlobalizationTestProjectName.strings", typeof(MyTestWebFormName).Assembly);

// Get the user's preferred language.
string sLang = Request.UserLanguages[0];
// Set the thread's culture for formatting, comparisons, etc.   
Thread.CurrentThread.CurrentCulture =  CultureInfo.CreateSpecificCulture(sLang);
// Set the thread's UICulture to load resources
// from satellite assembly.
Thread.CurrentThread.CurrentUICulture = new CultureInfo(sLang);

private void Page_Load(object sender, System.EventArgs e) 

{ 

 if (!IsPostBack)  

 {      
// Get strings from resource file and assign to UI elements.
head1.InnerHtml = gStrings.GetString("satellite.head1");
p1.InnerHtml = gStrings.GetString("satellite.p1");
sp1.InnerHtml = gStrings.GetString("satellite.sp1");
sp2.InnerHtml = gStrings.GetString("satellite.sp2");
butOK.Text = gStrings.GetString("satellite.butOK");
butCancel.Value = gStrings.GetString("satellite.butCancel");
   }

 }

ASP.NET 위성 어셈블리를 선택하는 순서:

스레드의 CurrentUICulture를 설정한 경우 ASP.NET 다음 순서대로 일치하는 리소스를 자동으로 선택합니다.

• 일치하는 문화권이 있는 위성 어셈블리가 발견되면 해당 어셈블리의 리소스가 사용됩니다.

• CurrentUICulture와 일치하는 중립 문화권이 있는 위성 어셈블리를 발견하면 해당 어셈블리의 리소스가 사용됩니다.

• CurrentUICulture에 대한 일치 항목을 찾을 수 없는 경우 실행 파일 어셈블리에 저장된 대체 리소스가 사용됩니다.

참고 이것은 보다 일반적인 리소스 대체 프로세스를 기반으로 합니다. 자세한 내용은 다음 MSDN 웹 사이트를 참조하세요.

http://msdn2.microsoft.com/en-us/library/sb6a8618(vs.71).aspx

위성 어셈블리를 수동으로 만들기:

이 위성 어셈블리 사용은 Visual Studio .NET에서 어셈블리 자체를 만드는 위치입니다. 그러나 Visual Studio .NET은 기본적으로 위성 어셈블리의 이름을 강력한 이름으로 지정하지 않습니다. 이러한 옵션을 변경하려면 위성 어셈블리를 수동으로 만들어야 합니다. 자세한 내용은 다음 MSDN 웹 사이트를 참조하세요.

http://msdn2.microsoft.com/en-us/library/21a15yht(vs.71).aspx .

용어

ANSI는 미국 국립 표준 연구소를 의미합니다. 이 컨텍스트에서는 특정 언어/문자 집합에 대한 특정 코드 페이지를 나타냅니다. 대부분 영어 코드 페이지(windows-1252)를 참조합니다.

ASCII A 1 바이트(또는 7비트) 인코딩 구성표입니다. 0-127 범위의 문자만 표준화됩니다. 128-255 범위는 표준의 일부가 아닌 ASCII 확장입니다. 예를 들어 OEM ASCII 차트의 상한 범위와 VB ASCII 차트의 차이점이 있습니다.

CharSet 설정은 주로 인터넷 Explorer 및 브라우저에 문자 데이터를 해석하는 방법을 알려주는 브라우저에 사용됩니다. 예: Response.charSet = "iso-8859-1."

Codepage 문자 인코딩 방법을 지정하는 변환 테이블입니다(일반적으로 서버에 사용됨).

세계화 세계화는 문화권, 지역 또는 국가/지역 및 언어적 요구 사항을 충족할 수 있도록 애플리케이션을 설계하고 만드는 프로세스입니다. 즉, 나중에 지역화할 수 있는 방식으로 애플리케이션을 디자인하는 것은 세계화입니다.

로캘/문화권 언어 및 지역별 형식/기본 설정( 날짜 및 달력 형식, 시간 형식, 통화 형식, 대/소문자, 정렬 및 문자열 비교, 주소 형식, 전화 번호 형식, 용지 크기, 측정 단위, 쓰기 방향 등)

LCID(LocaleID) 언어 식별자 및 정렬 ID를 지정하는 DWORD 값입니다. 에 따라 서식을 지정해야 하는 날짜/시간 등의 특정 지역 형식을 지정하는 데 사용할 수 있습니다.

지역화 가능성 애플리케이션이 요구되는 언어/로캘에 대한 콘텐츠를 표시하는 기능입니다.

지역화 지역화는 사용자 인터페이스를 특정 언어 및/또는 로캘로 변환하는 프로세스입니다.

멀티바이트 문자 집합 일본어와 같이 문자가 둘 이상의 바이트로 구성된 문자 집합입니다. UTF-8도 이 범주에 속합니다. (유니코드는 기술적으로 이 범주에 있지만 Windows에서는 자체 범주가 있습니다.)

유니코드 A 2 바이트 인코딩 구성표입니다. Windows는 내부적으로 유니코드를 사용합니다. 유니코드에 대한 모든 API는 함수 이름 끝에 "W"로 표시됩니다. 와이드 문자라고도 합니다. 웹 애플리케이션에서 직접 사용할 수 없습니다.

UTF-8 문자를 1-6바이트로 나타낼 수 있는 문자 인코딩입니다. Windows에서 범위는 1-3바이트입니다. 웹 애플리케이션에 대한 NT4에서 지원되지 않습니다.



와이드 문자 집합 유니코드의 별칭입니다. DBCS(더블 바이트 문자 집합), UCS-2, UTF-16이라고도 합니다.

언제나처럼 요청 양식을 사용하여 향후 열 또는 기술 자료에서 해결하려는 topics 대한 아이디어를 자유롭게 제출할 수 있습니다.