.NET "de-CH"문화 번호 그룹 구분 기호가 로컬과 Azure에서 다른 이유는 무엇입니까?

Aug 19 2020

로컬 데스크톱 및 Azure에서 실행할 때 "de-CH"문화권의 숫자 그룹 구분 기호로 다른 유니 코드 문자가 표시됩니다.

.NET Core 3.1 또는 .NET Framework 4.7.2의 내 데스크톱에서 다음 코드를 실행 2019하면 아포스트로피처럼 보이지만 동일하지 않은 출력 이 출력 됩니다.

예를 들어 Azure에서 실행할 때 https://try.dot.net또는 (약간 수정 됨) .NET Core 3.1 (Windows 기반 App Service에서)에서 실행되는 Azure 함수에서 0027표준 ASCII 아포스트로피가 생성됩니다.

using System;
using System.Linq;
using System.Globalization;

Console.WriteLine(((int)(CultureInfo
    .GetCultureInfo("de-CH")
    .NumberFormat
    .NumberGroupSeparator
    .Single())) // Just getting the single character as an int
    .ToString("X4") // unicode value of that character
    );

그 결과 "de-CH"문화권을 사용하여 로컬 데스크톱 에서 문자열 4'200.000(아포스트로피가 Unicode가있는 경우) 을 구문 분석하려는 시도 는 0027실패하지만 Azure에서는 작동합니다.

왜 다른가요?

답변

NineBerry Sep 04 2020 at 10:55

Shawn Steele의이 Microsoft 블로그는 안정적인 특정 문화 설정에 의존해서는 안되는 이유를 설명합니다 (더 이상 MSDN에서 온라인 상태가 아니기 때문에 전체 인용).

https://web.archive.org/web/20190110065542/https://blogs.msdn.microsoft.com/shawnste/2005/04/05/culture-data-shouldnt-be-considered-stable-except-for-invariant/

CultureInfo 및 RegionInfo 데이터는 문화적 설정에 대한 문화적, 지역적, 관리자 또는 사용자 기본 설정을 나타냅니다. 애플리케이션은이 데이터가 안정적이라는 가정을해서는 안됩니다. 유일한 예외 (규칙이므로 물론 예외가 있음)는 CultureInfo.InvariantCulture에 대한 것입니다. CultureInfo.InvariantCulture는 버전 간에도 안정적으로 유지되어야합니다.

문화 데이터가 변경 될 수있는 이유는 많습니다. Whidbey 및 Custom Cultures를 사용하면 목록이 조금 더 길어집니다.

가장 분명한 이유는 데이터에 버그가있어서 변경해야하기 때문입니다. (믿거 나 말거나 우리는 실수를합니다 ;-))이 경우 사용자 (및 귀하의 사용자)가 문화적으로 올바른 데이터를 원하므로 기존 응용 프로그램이 손상 되더라도 버그를 수정해야합니다.

또 다른 이유는 문화적 선호도가 바뀔 수 있다는 것입니다. 이런 일이 발생할 수있는 방법은 여러 가지가 있지만 실제로 발생합니다.

글로벌 인식, 문화 간 교류, 컴퓨터의 역할 변화 등은 모두 문화적 선호도에 영향을 미칠 수 있습니다.

국제 조약, 무역 등은 가치를 변경할 수 있습니다. 유로화의 채택으로 많은 국가의 통화 기호가 €로 변경되었습니다.

국가 또는 지역 규정은 이러한 값에도 영향을 미칠 수 있습니다.

선호하는 단어의 철자는 시간이 지남에 따라 변경 될 수 있습니다.

선호하는 날짜 형식 등은 변경 될 수 있습니다.

문화에 대한 다양한 선호도가 존재할 수 있습니다. 선호하는 최선의 선택은 시간이 지남에 따라 변경 될 수 있습니다.

사용자는 날짜 또는 시간 형식과 같은 일부 값을 재정의 할 수 있습니다. 사용자 재정의없이 요청할 수 있지만 응용 프로그램에서 사용자 재정의 사용을 고려하는 것이 좋습니다.

사용자 또는 관리자는 문화의 공통 기본값을 회사 별, 지역별 또는 기타 표준 데이터 변형으로 대체하여 대체 문화를 만들 수 있습니다.

일부 문화권은 설정에 따라 선호도가 다를 수 있습니다. 기업은 인터넷 카페보다 더 형식적인 형태를 가질 수 있습니다.

기업은 전체 조직에 대해 특정 날짜 형식 또는 시간 형식을 요구할 수 있습니다.

동일한 사용자 지정 문화권의 서로 다른 버전 또는 한 컴퓨터에서는 사용자 지정이고 다른 컴퓨터에서는 Windows 전용 문화권입니다.

따라서 특정 날짜 / 시간 형식으로 문자열의 형식을 지정한 다음 나중에 구문 분석을 시도하면 버전이 변경되거나 시스템이 변경된 경우, 프레임 워크 버전이 변경된 경우 (최신 데이터) 또는 사용자 지정 문화권이있는 경우 구문 분석이 실패 할 수 있습니다. 변경되었습니다. 데이터를 신뢰할 수있는 형식으로 유지해야하는 경우 이진 방법을 선택하거나 고유 한 형식을 제공하거나 InvariantCulture를 사용하세요.

데이터를 변경하지 않아도 Invariant를 사용하는 것을 기억하는 것은 여전히 좋은 생각입니다. 다른. 및, 1,000.29와 같은 구문의 경우 클라이언트가 1.000,29를 예상하면 구문 분석이 혼동 될 수 있습니다. 나는 사용자의 문화가 개발자의 문화와 다를 것이라는 것을 깨닫지 못한 애플리케이션에서이 문제를 보았다. Invariant 또는 다른 기술을 사용하면 이러한 종류의 문제가 해결됩니다.

물론 현재 사용자에 대한 "올바른"디스플레이와 문화 데이터가 변경 될 경우 완벽한 왕복을 모두 가질 수는 없습니다. 따라서 일반적으로 InvariantCulture 또는 다른 변경 불가능한 형식을 사용하여 데이터를 유지하고 항상 적절한 형식 지정 API를 사용하여 표시하는 것이 좋습니다. 응용 프로그램에는 자체 요구 사항이 있으므로 신중하게 고려하십시오.

데이터 정렬 (정렬 순서 / 비교)의 경우 고정 동작도 변경 될 수 있습니다. 일관되게 안정적인 정렬 순서가 필요한 경우이를 해결하려면 Sort Versioning을 사용해야합니다.

사용자에게 친숙한 형식의 데이터를 자동으로 구문 분석해야하는 경우 두 가지 방법이 있습니다.

사용자가 사용 된 형식을 명시 적으로 지정할 수 있도록합니다.
먼저 이것을 구문 분석하기 전에 문자열에서 숫자, 빼기 기호 및 소수점 구분 기호를 제외한 모든 문자를 제거하십시오. 먼저 올바른 소수점 구분 기호를 알아야합니다. 이것을 정확하게 추측 할 방법이 없으며 잘못 추측하면 큰 문제가 발생할 수 있습니다.

가능한 한 사용자에게 친숙한 형식의 숫자를 구문 분석하지 않도록하십시오. 대신 가능할 때마다 엄격하게 정의 된 (불변) 형식으로 번호를 요청하십시오.