다음과 같은 텍스트 문자열이 있습니다.
var foo = "FooBar";
두 번째 문자열을 선언하고 bar
이것을 내 첫 번째의 첫 번째 및 네 번째 문자와 동일하게 만들고 foo
싶습니다.
var bar = foo[0].ToString() + foo[3].ToString();
이것은 예상대로 작동하지만 ReSharper 는 Culture.InvariantCulture
괄호 안에 넣도록 조언 하므로이 줄은 다음과 같이 끝납니다.
var bar = foo[0].ToString(CultureInfo.InvariantCulture)
+ foo[3].ToString(CultureInfo.InvariantCulture);
이것은 무엇을 의미하며 내 프로그램 실행 방법에 영향을 미칩니 까?
답변
모든 문화권에서 날짜 및 10 진수 / 통화 값에 동일한 형식을 사용하는 것은 아닙니다.
이것은 입력 값을 변환 할 때 중요합니다 (읽기) 문자열에 저장됩니다 DateTime
, float
, double
또는 decimal
. 위에서 언급 한 데이터 유형을 표시 또는 저장을 위해 문자열 (쓰기) 로 형식화하려는 경우에도 중요합니다 .
날짜와 10 진수 / 통화 값이 어떤 특정 문화에 미리 해당되는지 알고 있다면 해당 특정 CultureInfo
속성 (예 :CultureInfo("en-GB")
. 예를 들어 사용자 입력이 필요한 경우.
이 CultureInfo.InvariantCulture
속성은 사용자의 로컬 설정과 무관하게 소프트웨어에서 구문 분석 할 수있는 문자열을 형식화하거나 구문 분석하는 경우에 사용됩니다.
기본값 CultureInfo.InstalledUICulture
은 기본 CultureInfo가 실행중인 OS 설정에 따라 달라집니다. 그렇기 때문에 항상 문화 정보가 자신의 의도에 맞는지 확인해야합니다 ( 좋은 지침 은 Martin의 답변 참조 ).
답변
숫자, 날짜 및 시간이 문자열로 형식화되거나 문자열에서 구문 분석 될 때 문화권을 사용하여 수행 방식을 결정합니다. 예를 들어 지배적 인 en-US
문화에서는 다음과 같은 문자열 표현이 있습니다.
- 1,000,000.00-두 자리 분수의 백만
- 1/29/2013-이 게시물의 날짜
내 문화권 ( da-DK
)에서 값은 다음 문자열 표현을 갖습니다.
- 1.000.000,00-두 자리 분수로 백만
- 29-01-2013-이 게시물의 날짜
Windows 운영 체제에서 사용자는 숫자 및 날짜 / 시간 형식을 사용자 정의하고 운영 체제의 문화와 다른 문화를 선택할 수도 있습니다. 사용 된 형식은 사용자가 선택해야하는 방식입니다.
당신이 값을 포맷 할 때 그래서 예를 들어 사용하여 사용자에게 표시 할 ToString
또는 String.Format
또는 사용하여 문자열에서 구문 분석 DateTime.Parse
또는 Decimal.Parse
기본값은을 사용하는 것입니다CultureInfo.CurrentCulture
. 이를 통해 사용자는 서식을 제어 할 수 있습니다.
그러나 많은 문자열 형식 및 구문 분석은 실제로 응용 프로그램과 사용자간에 교환되는 문자열이 아니라 응용 프로그램과 일부 데이터 형식 (예 : XML 또는 CSV 파일)간에 교환되는 문자열입니다. 이 경우 CultureInfo.CurrentCulture
다른 문화권으로 서식 지정 및 구문 분석을 수행하면 중단 될 수 있으므로 사용하지 않으려 고합니다 . 이 경우 사용하려는 CultureInfo.InvariantCulture
(en-US
문화를 . 이렇게하면 문제없이 값을 왕복 할 수 있습니다.
ReSharper에서 당신에게 경고를 제공하는 이유는 일부 응용 프로그램의 작가가 의도하지 않은 결과가 발생할 수도 구별 인식하지 못하고 있지만 그들이 있기 때문에이 문제를 발견하지 것입니다 CultureInfo.CurrentCulture
IS en-US
같은 동작 등이있다CultureInfo.InvariantCulture
. 그러나 응용 프로그램을 다른 문화권에서 사용하는 즉시 하나의 문화권을 사용하여 서식을 지정하고 다른 문화권을 사용하여 응용 프로그램을 구문 분석 할 수 있습니다.
요약하자면 다음과 같습니다.
- 사용하다
CultureInfo.CurrentCulture
사용자 문자열을 형식화하거나 구문 분석하는 경우 (기본값)을 . - 사용하다
CultureInfo.InvariantCulture
소프트웨어에서 구문 분석 할 수있는 문자열을 형식화하거나 구문 분석하는 경우 . - 사용자가 형식 지정 및 구문 분석 방법을 제어 할 수 없으므로 특정 국가 문화를 거의 사용하지 마십시오.
답변
Microsoft에 따르면 :
CultureInfo.InvariantCulture 속성은 중립 또는 특정 문화가 아닙니다. 문화에 무관 한 세 번째 유형의 문화입니다. 영어와 관련이 있지만 국가 나 지역과는 관련이 없습니다.
( http://msdn.microsoft.com/en-us/library/4c5zdc6a(vs.71).aspx에서 )
따라서 InvariantCulture는 “en-US”문화와 유사하지만 정확히 동일하지는 않습니다. 당신이 쓰는 경우 :
var d = DateTime.Now;
var s1 = d.ToString(CultureInfo.InvariantCulture); // "05/21/2014 22:09:28"
var s2 = d.ToString(new CultureInfo("en-US")); // "5/21/2014 10:09:28 PM"
s1과 s2는 유사한 형식을 갖지만 InvariantCulture는 선행 0을 추가하고 “en-US”는 AM 또는 PM을 사용합니다.
따라서 InvariantCulture는 날짜를 텍스트 파일에 저장하거나 데이터를 구문 분석 할 때 내부 사용에 더 좋습니다. 그리고 최종 사용자에게 데이터 (날짜, 통화 …)를 제시 할 때 지정된 CultureInfo가 더 좋습니다.
답변
숫자 (소수점, 쉼표로 표시)와 같은 것들은 일반적으로 특정 문화에서 선호됩니다.
이를 수행하는 적절한 방법은 다음과 같이 문화 수준 (독일어)으로 설정하는 것입니다.
Thread.CurrentThread.CurrentCulture.NumberFormat = new CultureInfo("de").NumberFormat;
답변
JetBrains는 합리적인 설명을 제공합니다 .
“데이터 구조를 텍스트로 임시 변환하는 것은 현재 문화에 따라 크게 달라지며 원래 개발자의 로케일과 다른 로케일이있는 머신에서 코드를 실행할 때 의도하지 않은 결과가 발생할 수 있습니다. 모호성을 방지하기 위해 ReSharper는 경고합니다. 이러한 문제가 발생할 수있는 코드의 모든 인스턴스 “
그러나 내가 영어로만 된 사이트에서 일하고 있다면 제안을 무시합니다.