다음을 통해 공유

지역화 대비 애플리케이션 개발을 위한 최선의 구현 방법

  • 아티클

이 단원에서는 지역화 대비 애플리케이션을 개발할 때 따라야 할 최선의 구현 방법을 소개합니다.

세계화 모범 사례

  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 Folder"와 같이 문자열이 문자열 구성 요소의 문법적 역할에 따라 다르게 변환될 수 있는 애매한 구문은 피합니다. 예를 들어, "empty"는 동사나 형용사로 사용할 수 있으므로 이탈리아어나 프랑스어와 같은 언어에서는 다르게 번역될 수 있습니다.

  6. 애플리케이션에서 텍스트가 들어 있는 이미지나 아이콘은 사용하지 않도록 합니다. 이러한 경우에는 지역화 비용이 많이 듭니다.

  7. 사용자 인터페이스에서 문자열 길이를 확장할 수 있도록 충분한 공간을 둡니다. 일부 언어에서는 다른 언어와 비교하여 구에 50-75%의 공간이 더 필요합니다.

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

  9. Windows Forms 리소스 편집기(Winres.exe)를 사용하여 지역화할 수 있도록 Visual Studio를 사용하여 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 애플리케이션에 대해 외부 파일입니다. 자세한 내용은 <globalization> 요소를 참조하세요.
    • 페이지 지시문에서. 애플리케이션이 페이지에 있는 경우 파일이 이미 읽혀진 것입니다. 따라서 너무 늦었으므로 fileEncoding 및 requestEncoding을 지정할 수 없습니다. uiCulture, culture 및 responseEncoding만 페이지 지시문에 지정할 수 있습니다.
    • 프로그램 방식으로 애플리케이션 코드에서. 이 설정은 요청마다 다를 수 있습니다. 페이지 지시문의 경우와 마찬가지로 해당 애플리케이션 코드에 도달되면 이미 너무 늦었으므로 fileEncoding 및 requestEncoding을 지정할 수 없습니다. uiCulture, culture 및 responseEncoding만 애플리케이션 코드에서 지정할 수 있습니다.

  5. uiCulture 값은 브라우저 허용 언어로 설정될 수 있습니다.

  6. 분산된 애플리케이션의 경우 가동 중지 시간 업데이트(예: Azure Container Apps)를 허용하거나, 다른 형식 규칙 또는 다른 문화권 데이터, 가장 관련성이 있는 표준 시간대 규칙을 사용하는 애플리케이션 인스턴스가 여러 개 있을 수 있는 상황을 계획해야 합니다.

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

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

  1. 종속성을 더 명시적으로 구현하고 테스트를 잠재적으로 더 쉽고 병렬화 가능한 상태로 만들려면 CultureInfo 매개 변수와 같은 문화권 관련 설정을 형식 지정을 수행하는 메서드에, 그리고 날짜 및 시간을 사용하는 메서드에는 TimeZoneInfo를 명시적으로 전달하는 방안을 고려해야 합니다. 또한 시간을 검색할 때 TimeProvider 또는 유사한 형식을 사용해야 합니다.

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

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

참고 항목