다음을 통해 공유

세계적 지원 애플리케이션 개발을 위한 모범 사례

이 섹션에서는 세계적 지원 애플리케이션을 개발할 때 따라야 할 모범 사례에 대해 설명합니다.

세계화 모범 사례

  1. 애플리케이션을 내부적으로 유니코드로 만듭니다.

  2. 네임스페이스에서 제공하는 문화권 인식 클래스를 System.Globalization 사용하여 데이터를 조작하고 서식을 지정합니다.

    • 정렬을 위해 SortKey 클래스와 CompareInfo 클래스를 사용하세요.
    • 문자열 비교의 경우 클래스를 CompareInfo 사용합니다.
    • 날짜 및 시간 서식의 경우 클래스를 DateTimeFormatInfo 사용합니다.
    • 숫자 서식 지정의 경우 클래스를 NumberFormatInfo 사용합니다.
    • 그레고리오력 및 그레고리오력이 아닌 달력의 경우 클래스 또는 특정 달력 구현 중 하나를 사용합니다 Calendar .

  3. 적절한 상황에서 클래스에서 System.Globalization.CultureInfo 제공하는 문화권 속성 설정을 사용합니다. CultureInfo.CurrentCulture 날짜 및 시간 또는 숫자 서식 지정과 같은 작업의 서식 지정에 이 속성을 사용합니다. 속성을 CultureInfo.CurrentUICulture 사용하여 리소스를 검색합니다. CurrentCulture 및 CurrentUICulture 속성은 각 스레드마다 설정할 수 있습니다.

  4. 네임스페이스의 인코딩 클래스를 사용하여 애플리케이션이 다양한 인코딩에서 데이터를 읽고 쓸 수 있도록 합니다 System.Text . ASCII 데이터를 가정하지 마세요. 사용자가 텍스트를 입력할 수 있는 모든 위치에 국제 문자가 제공된다고 가정합니다. 예를 들어 애플리케이션은 서버 이름, 디렉터리, 파일 이름, 사용자 이름 및 URL에서 국제 문자를 허용해야 합니다.

  5. 보안상의 이유로 클래스를 UTF8Encoding 사용하는 경우 이 클래스에서 제공하는 오류 검색 기능을 사용합니다. 오류 검색 기능을 활성화하려면 throwOnInvalidBytes 매개변수를 사용하는 생성자를 통해 클래스의 인스턴스를 만들고, 해당 매개변수의 값을 true로 설정합니다.

  6. 가능하면 문자열을 일련의 개별 문자가 아닌 전체 문자열로 처리합니다. 이는 부분 문자열을 정렬하거나 검색할 때 특히 중요합니다. 이렇게 하면 결합된 문자 구문 분석과 관련된 문제가 방지됩니다. 클래스를 사용하여 단일 문자가 아닌 텍스트 단위로 작업할 System.Globalization.StringInfo 수도 있습니다.

  7. 네임스페이스에서 제공하는 System.Drawing 클래스를 사용하여 텍스트를 표시합니다.

  8. 운영 체제 간의 일관성을 위해 사용자 설정이 CultureInfo를 재정의하지 않도록 하십시오. CultureInfo 매개변수를 수락하고 useUserOverride에 설정하는 false 생성자를 사용합니다.

  9. 국제 데이터를 사용하여 국제 운영 체제 버전에서 애플리케이션 기능을 테스트합니다.

  10. 보안 결정이 문자열 비교 또는 대/소문자 변경 작업의 결과를 기반으로 하는 경우 문화권을 구분하지 않는 문자열 작업을 사용합니다. 이렇게 하면 결과가 값의 CultureInfo.CurrentCulture영향을 받지 않습니다. 문자열 사용에 대한 모범 사례의 "현재 문화권을 사용하는 문화 민감한 문자열 비교" 섹션을 참조하십시오. 문화 민감한 문자열 비교가 일관성 없는 결과를 어떻게 생성할 수 있는지를 보여주는 예제가 있습니다.

  11. 상호 교환(예: API 호출의 JSON 문서의 필드) 또는 저장에 사용되는 요소의 경우 CultureInfo를 사용합니다. 추가적으로, 왕복 변환 형식(예: "O""o" 날짜 및 시간 형식 지정자)을 명시적으로 지정해야 합니다. 고정 문화권의 형식 문자열은 안정적이고 변경될 가능성이 낮지만 명시적 형식 문자열을 지정하면 코드의 의도를 명확히 하는 데 도움이 됩니다.

  12. 세계화 데이터는 안정적이지 않으므로 이를 염두에 두고 애플리케이션 및 해당 테스트를 작성해야 합니다. 지원되는 모든 플랫폼에서 호스트 OS 채널을 통해 1년마다 여러 번 업데이트됩니다. 이 데이터는 일반적으로 런타임과 함께 분산되지 않습니다.

지역화 모범 사례

  1. 지역화 가능한 모든 리소스를 별도의 리소스 전용 DLL로 이동합니다. 지역화 가능한 리소스에는 문자열, 오류 메시지, 대화 상자, 메뉴 및 포함된 개체 리소스와 같은 사용자 인터페이스 요소가 포함됩니다.

  2. 문자열 또는 사용자 인터페이스 리소스를 하드 코딩하지 마세요.

  3. 지역화할 수 없는 리소스를 리소스 전용 DLL에 넣지 마세요. 이는 번역가들을 혼란스럽게 합니다.

  4. 연결된 구에서 런타임에 빌드된 복합 문자열을 사용하지 마세요. 복합 문자열은 일부 언어에 적용되지 않는 영어 문법 순서를 가정하기 때문에 지역화하기가 어렵습니다.

  5. 문자열 구성 요소의 문법 역할에 따라 문자열을 다르게 변환할 수 있는 "빈 폴더"와 같은 모호한 구문을 사용하지 마세요. 예를 들어 "empty"는 동사 또는 형용사일 수 있으며, 이는 이탈리아어 또는 프랑스어와 같은 언어로 다른 번역으로 이어질 수 있습니다.

  6. 애플리케이션에 텍스트가 포함된 이미지와 아이콘을 사용하지 마세요. 지역화하는 데 비용이 많이 듭니다.

  7. 사용자 인터페이스에서 문자열 길이를 확장할 충분한 공간을 허용합니다. 일부 언어에서 구에는 다른 언어에 필요한 것보다 50~75% 더 많은 공간이 필요할 수 있습니다.

  8. 클래스를 System.Resources.ResourceManager 사용하여 문화권에 따라 리소스를 검색합니다.

  9. Visual Studio를 사용하여 Windows Forms 리소스 편집기(Winres.exe)를 사용하여 지역화할 수 있도록 Windows Forms 대화 상자를 만듭니다. Windows Forms 대화 상자를 직접 코딩하지 마세요.

  10. 전문 번역 서비스를 준비합니다.

  11. 리소스를 만들고 지역화하는 방법에 대한 자세한 내용은 .NET 앱의 리소스를 참조하세요.

ASP.NET 및 기타 서버 애플리케이션에 대한 세계화 모범 사례

팁 (조언)

다음 모범 사례는 ASP.NET Framework 앱에 대한 것입니다. ASP.NET Core 앱은 ASP.NET Core의 세계화 및 지역화를 참조하세요.

  1. 애플리케이션에서 CurrentUICulture 속성과 CurrentCulture 속성을 명시적으로 설정합니다. 기본값을 사용하지 마세요.

  2. ASP.NET 애플리케이션은 관리되는 애플리케이션이므로 문화권에 따라 정보를 검색, 표시 및 조작하기 위해 다른 관리되는 애플리케이션과 동일한 클래스를 사용할 수 있습니다.

  3. ASP.NET 다음 세 가지 유형의 인코딩을 지정할 수 있습니다.

    • requestEncoding 는 클라이언트의 브라우저에서 받은 인코딩을 지정합니다.
    • responseEncoding 는 클라이언트 브라우저로 보낼 인코딩을 지정합니다. 대부분의 경우 이 인코딩은 지정된 인코딩과 requestEncoding같아야 합니다.
    • fileEncoding은 .aspx, .asmx 및 .asax 파일 구문 분석의 기본 인코딩을 지정합니다.

  4. ASP.NET 애플리케이션에서 다음 세 위치에 있는 requestEncoding, responseEncoding, fileEncoding, culture, 및 uiCulture 특성의 값을 지정합니다.

    • Web.config 파일의 국제화 섹션에서 이 파일은 ASP.NET 애플리케이션 외부에 있습니다. 자세한 내용은 세계화< 요소를 참조>하세요.
    • 페이지 지시문에서 애플리케이션이 페이지에 있는 경우 파일이 이미 읽혀졌습니다. 따라서 fileEncoding 및 requestEncoding을 지정하기에는 너무 늦었습니다. uiCulture, culture, 그리고 responseEncoding만 페이지 지시문에 지정할 수 있습니다.
    • 애플리케이션 코드에서 프로그래밍 방식으로. 이 설정은 요청에 따라 달라질 수 있습니다. 페이지 지시문과 마찬가지로 애플리케이션의 코드에 도달하면 fileEncoding 및 requestEncoding를 지정하기에는 너무 늦습니다. 애플리케이션 코드에서는 uiCulture, culture, 및 responseEncoding만 지정할 수 있습니다.

  5. uiCulture 값은 브라우저 수락 언어로 설정할 수 있습니다.

  6. 분산된 애플리케이션의 경우, 무중단 업데이트(예: Azure Container Apps)를 허용하거나, 서로 다른 형식 규칙 또는 문화권 데이터, 특히 표준 시간대 규칙을 사용하는 애플리케이션 인스턴스가 여러 개 있을 수 있는 상황에 대한 계획이 필요합니다.

    • 애플리케이션 배포에 데이터베이스가 포함된 경우 데이터베이스에는 자체 세계화 규칙이 있어야 합니다. 대부분의 경우 데이터베이스에서 세계화 관련 함수를 수행하지 않아야 합니다.
    • 애플리케이션 배포에 클라이언트 세계화 리소스를 사용하는 클라이언트 애플리케이션 또는 웹 프런트 엔드가 포함된 경우 클라이언트 리소스가 서버에서 사용할 수 있는 리소스와 다르다고 가정합니다. 클라이언트에서만 세계화 함수를 수행하는 것이 좋습니다.

강력한 테스트를 위한 권장 사항

  1. 종속성을 보다 명시적이고 테스트가 더 쉽고 병렬화할 수 있도록 하려면 매개 변수와 같은 문화권 관련 설정을 형식 지정을 수행하는 메서드 및 날짜 및 CultureInfo 시간을 사용하는 메서드에 명시적으로 전달하는 것이 TimeZoneInfo. 시간을 검색할 때도 사용하거나 유사한 형식을 사용해야 TimeProvider 합니다.

  2. 대부분의 테스트에서는 지정된 서식 작업의 정확한 출력 또는 표준 시간대의 정확한 오프셋의 유효성을 명시적으로 검사 해서는 안 됩니다 . 서식 및 표준 시간대 데이터는 언제든지 변경될 수 있으며 운영 체제의 두 인스턴스(및 동일한 컴퓨터의 잠재적으로 다른 프로세스)가 다를 수 있습니다. 정확한 값에 의존하면 테스트가 취약해집니다.

    • 일반적으로 일부 출력이 수신되었는지 확인하는 것으로 충분합니다(예: 서식을 지정할 때 비어있지 않은 문자열).
    • 일부 데이터 요소 및 형식의 경우 데이터가 입력 값으로 구문 분석되는지 확인하는 대신(왕복) 사용할 수 있습니다. 필드가 삭제되는 경우(예: 일부 날짜 관련 필드의 경우 연도) 또는 잘리거나 반올림된 값(예: 부동 소수점 출력)에 주의해야 합니다.
    • 모든 지역화된 형식 출력의 유효성을 검사하기 위한 명시적 요구 사항이 있는 경우 테스트 설정 중에 사용자 지정 문화권을 만들고 사용하는 것이 좋습니다 . 대부분의 간단한 경우 생성자를 CultureInfo 사용하여 개체를 new CultureInfo(..) 인스턴스화하고 및 DateTimeFormat 속성을 설정 NumberFormat 하여 이 작업을 수행할 수 있습니다. 더 복잡한 경우 형식을 서브클래싱하면 추가 속성을 재정의할 수 있습니다. 리소스 파일을 사용하여 pseudolocalization 을 사용하도록 설정하는 것과 같은 추가적인 이점이 있을 수 있습니다.
    • 모든 날짜/시간 작업의 결과의 유효성을 검사하기 위한 명시적 요구 사항이 있는 경우 테스트 설정 중에 사용자 지정 인스턴스를 만들고 사용하는 TimeZoneInfo. 특정 에지 사례(예: DST 규칙 변경)를 안정적으로 테스트할 수 있도록 설정하는 등 이에 대한 추가적인 이점이 있을 수 있습니다.

참고하십시오