컨텍스트에 따라 string.Normalize가 일관되지 않은 이유는 무엇입니까?

나는 다음과 같은 코드가 있습니다컨텍스트에 따라 string.Normalize가 일관되지 않은 이유는 무엇입니까?

string input = "ç"; 
string normalized = input.Normalize(NormalizationForm.FormD); 
char[] chars = normalized.ToCharArray();

내가 7

내가 단위 테스트 프로젝트 (플랫폼을 실행 64 비트 윈도우에, 비주얼 스튜디오 2010, .net4이 코드를 빌드 : 모든 두 상황에서 CPU)와 chars의 내용 확인 :

비주얼 스튜디오 유닛 테스트 : 문자가 { 231 } 포함한다.
ReSharper : 문자는 { 231 }입니다.
NCrunch : 문자는 { 99, 807 }입니다.

msdn documentation에는 다른 행동을 나타내는 정보를 찾을 수 없습니다.

그럼 왜 다른 행동을합니까? 나를 위해 NCrunch 행동은 예상되는 행동이지만 다른 사람들도 마찬가지라고 기대합니다.

편집 : .Net 3.5로 전환했지만 여전히 동일한 문제가 있습니다. String.Normalize(NormalizationForm) documentation에서

출처

2012-05-10 remio

흠, 나는 Visual Studio로 {99, 807}을 얻습니다. 이것은 프로젝트 구성에 대해 뭔가 의미가 있음을 암시합니다 ... 어쩌면. – zmilojko

@zmilojko. 테스트 해 주셔서 감사합니다. 나는 새로운 프로젝트를 빈 채로 당신과 같은 결과를 얻는다. 그래서 나는 두 프로젝트 (csproj에서 winmerge) 사이의 차이점을 확인하고 있지만 관련성을 아직 찾지 못했습니다.이 질문을 게시하는 이유는 어떤 문맥이 다른 행동을 유도 할 수 있는지 파악하는 것입니다. – remio

각 경우에'Thread.CurrentThread.CurrentCulture' 란 무엇입니까? – AakashM

그것은

진 표현이 normalizationForm 매개 변수에 의해 지정된 정규화 형태로되어 있다고 말한다.

즉, 두 경우 모두 FormD 정규화를 사용한다는 의미이므로 CurrentCulture 등은 별 의미가 없습니다.

내가 변경할 수있는 유일한 것은 "ç"문자입니다. 이 문자는 Visual Studio 소스 코드 파일로 간주되거나 구성된 문자 인코딩별로 해석됩니다. 요컨대, NCrunch는 다른 소스 파일 인코딩과는 다른 가정을하고 있다고 생각합니다.

NCrunch 포럼에서 빠른 검색을 기반으로 일부 UTF-8 -> UTF-16 변환에 대한 언급이 있었기 때문에이를 확인할 것입니다.

출처

2012-05-14 11:51:04 eis

사실, 나는 소스/런타임 코드에서 문자의 인코딩을 강력하게 의심했다. 나는 행운을 빌어 소스 파일의 인코딩을 시작했다. 그런 다음 외부 파일에서 문자열을 읽으려고했습니다. 인코딩이 강제로 UTF-8이 될 때까지 실패했습니다. 마지막으로,'input '의 선언을'string input = new string (new [] {(char) 231});'으로 업데이트했고, ... 작동합니다! – remio

컨텍스트에 따라 string.Normalize가 일관되지 않은 이유는 무엇입니까?

답변

관련 문제