Runtime: .NET Core 3.0-> .NET 5.0에서 string.IndexOf (string)로 주요 변경 사항

에 만든 2020년 10월 22일 · 76코멘트 · 출처: dotnet/runtime

기술

.NET 5.0을 지원하도록 패키지를 확장하고 있으며 주요 변경 사항이 발생했습니다. 콘솔 애플리케이션이 주어지면 :

using System;

namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var actual = "Detail of supported commands\n============\n## Documentation produced for DelegateDecompiler, version 0.28.0 on Thursday, 22 October 2020 16:03\n\r\nThis file documents what linq commands **DelegateDecompiler** supports when\r\nworking with [Entity Framework Core](https://docs.microsoft.com/en-us/ef/core/) (EF).\r\nEF has one of the best implementations for converting Linq `IQueryable<>` commands into database\r\naccess commands, in EF's case T-SQL. Therefore it is a good candidate for using in our tests.\r\n\r\nThis documentation was produced by compaired direct EF Linq queries against the same query implemented\r\nas a DelegateDecompiler's `Computed` properties. This produces a Supported/Not Supported flag\r\non each command type tested. Tests are groups and ordered to try and make finding things\r\neasier.\r\n\r\nSo, if you want to use DelegateDecompiler and are not sure whether the linq command\r\nyou want to use will work then clone this project and write your own tests.\r\n(See [How to add a test](HowToAddMoreTests.md) documentation on how to do this). \r\nIf there is a problem then please fork the repository and add your own tests. \r\nThat will make it much easier to diagnose your issue.\r\n\r\n*Note: The test suite has only recently been set up and has only a handful of tests at the moment.\r\nMore will appear as we move forward.*\r\n\r\n\r\n### Group: Unit Test Group\n#### [My Unit Test1](../TestGroup01UnitTestGroup/Test01MyUnitTest1):\n- Supported\n  * Good1 (line 1)\n  * Good2 (line 2)\n\r\n#### [My Unit Test2](../TestGroup01UnitTestGroup/Test01MyUnitTest2):\n- Supported\n  * Good1 (line 1)\n  * Good2 (line 2)\n\r\n\r\n\nThe End\n";

            var expected = "\n#### [My Unit Test2](";

            Console.WriteLine($"actual.Contains(expected): {actual.Contains(expected)}");
            Console.WriteLine($"actual.IndexOf(expected): {actual.IndexOf(expected)}");
        }
    }
}

.NET Core 3.0-> .NET 5.0의 런타임에 따라 다른 결과를 얻습니다.

.NET Core 3.0 :

actual.Contains(expected): True
actual.IndexOf(expected): 1475

.NET 5.0 :

actual.Contains(expected): True
actual.IndexOf(expected): -1

구성

Windows 10 Pro 빌드 19041 x64
.NET Core 3.1.9
.NET 5.0.0-rc.2.20475.5

회귀?

예, .NET Core 3.1.9를 통해 작동했습니다.

area-System.Globalization question

출처

jbogard

👍32 👀18 😕7 🚀1 😄1

가장 유용한 댓글

@tarekgh , 나는 Contains 와 IndexOf 사이의 다른 결과가 그 자체로 문제가 아니라는 데 동의합니다.

문제는 분명히 IndexOf 로, 다른 ASCII 전용 문자열 내에서 하나의 ASCII 전용 문자열을 찾을 수 없습니다 (ASCII 전용 문자열에 부과 된 로케일 종속 동작이 있는지 확실하지 않습니다!).

이것은 로케일 / NLS / ICU 관련 변경에서 기대하는 것이 아닙니다. 사실, 다른 프로그래밍 언어 / 런타임이 그렇게 작동한다고 생각할 수 없었습니다.

다음은 .NET 5 RC 2에서 깨진 간단한 테스트 케이스입니다.

var actual = "\n\r\nTest";
var expected = "\nTest";

Console.WriteLine($"actual.IndexOf(expected): {actual.IndexOf(expected)}"); // => -1

정말 그렇게 작동할까요? 또한 왜? 실제로 무엇을하려고합니까?

정말 계획된 변경 이었습니까?
예 ICU로 전환하는 것은 여러 가지 이유로 의도적 인 변경입니다.

죄송 합니다만 이것이 계획된 변경이라고 생각하지 않습니다. 그래서 강조하고 싶습니다. 누구도 그런 변경을 _ 계획 _하는 것을 상상할 수 없었습니다. 마찬가지로 .NET 팀의 사람들이 함께 앉아 토론했습니다.

문자열 "\ n \ r \ nTest"에 ICU가 활성화 된 "\ nTest"가 포함되어 있습니까? 아니, 분명히 그렇지 않습니다!

그리고 아무도 불평하지 않았습니까? 기회가 아닙니다!

이것은 계획되거나 예상되는 변경처럼 보이지 않고 대신 매우 심각한 버그, 큰 호환성 차단기처럼 보입니다. 이 때문에 새롭고 이식 된 .NET 응용 프로그램은 새 런타임에서 제대로 작동하지 않습니다. 문자열 내부에서 하위 문자열을 찾을 수 없기 때문입니다!

ICU가 어차피 라인 엔딩에 관심이있는 이유는 무엇입니까? 일부 로케일에는 고유 한 로케일 별 줄 끝이 있습니까?

PS 예, 서수 플래그와 같이 문화에 독립적 인 IndexOf 변형을 항상 호출해야한다고 주장 할 수 있습니다. 그러나 .NET 5에서 열심히 _that_ 깰 수 있다고 결정 했다면 , 정상적인 서수 기본값을 사용하도록 만들 수 없습니까? .NET 5 RC 2에서 볼 수있는 현재 변경 사항보다 응용 프로그램이 더 적게 중단 될 것이라고 생각합니다.

또한 IndexOf 항상 문화 별 방식으로 작동하지만 서수 플래그없이 IndexOf 를 사용하는 코드가 _tons_ 존재한다는 것을 이해하고 있습니다. _ 일하는 데 익숙 함 _ (적어도 일부 / 대부분의 경우). 그리고 .NET 5 업데이트 후 작동이 중지됩니다.

ForNeVeR 에 2020년 10월 24일

👍47 👀2 🚀2 ❤1 🎉1

모든 76 댓글

헉

danmosemsft 에 2020년 10월 22일

이 영역에 대한 구독자 태그 지정 : @tarekgh , @safern , @krwq
구독하려면 area-owners.md의 정보를 참조하십시오.

msftbot[bot] 에 2020년 10월 22일

이것은 .NET 5.0에서 NLS 대신 ICU를 사용하여 전환 한 것과 같이 설계에 의한 것입니다. 자세한 내용은 https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu 를 참조하십시오.

구성 스위치 System.Globalization.UseNls 을 (를) 사용하여 이전 동작으로 되돌릴 수 있지만 ICU가 더 정확하고 ICU를 사용하여 앞으로 나아가면 OS간에 일관성을 제공하므로 그렇게하는 것은 권장하지 않습니다.

tarekgh 에 2020년 10월 22일

👍8

IndexOf 를) Contains 로 작동 시키려면 그 때 서수 비교를 사용해야합니다.

C# actual.IndexOf(expected, StringComparison.Ordinal)

tarekgh 에 2020년 10월 22일

👍17 👀1

구성 스위치 System.Globalization.UseNls를 사용하여 이전 동작으로 돌아갈 수있는 옵션이 있지만 ICU가 더 정확하고 ICU를 사용하여 앞으로 나아가면 OS간에 일관성을 제공하므로 그렇게하는 것은 권장하지 않습니다.

예, netcoreapp3.1 를 대상으로하는 Unix에서이 코드를 실행하면 다음과 같은 동작이 표시됩니다.

 santifdezm  DESKTOP-1J7TFMI  ~  experimental  indexof  $   /home/santifdezm/experimental/indexof/bin/Debug/netcoreapp3.1/linux-x64/publish/indexof
actual.Contains(expected): True
actual.IndexOf(expected): -1

Ordinal 비교와 함께 @tarekgh 로 예상 된 결과를 반환합니다.

 santifdezm  DESKTOP-1J7TFMI  ~  experimental  indexof  $  /home/santifdezm/experimental/indexof/bin/Debug/net5.0/linux-x64/publish/indexof
actual.Contains(expected): True
actual.IndexOf(expected): 1475

safern 에 2020년 10월 22일

👍1

소스 문자열에 \r\n 및 \n 가 혼합되어 있기 때문에 이것이 실패한 것 같습니다. \r\n 의 모든 인스턴스를 \n 로 바꾸면 작동합니다. 내가 모든 것을 \r\n 만들 경우에도 마찬가지입니다. ICU의 비교에서 다른 결과를 가져 오는 것은 단지 혼합입니다.

ericstj 에 2020년 10월 22일

👍7

~~Twitter에보고 된 문제는 5.0 런타임 내 에서 동일한 입력 으로 string.IndexOf 한다는 것 입니다.~~

~~https://twitter.com/jbogard/status/1319381273585061890?s=21~~

편집 : 위는 오해였습니다.

GrabYourPitchforks 에 2020년 10월 23일

@GrabYourPitchforks 문제 제목을 업데이트 할 수 있습니까? 이것은 기술적 인 변경 사항이므로 Windows 및 Unix에서 발생합니다. 맞습니까?

safern 에 2020년 10월 23일

설명을 위해 Jimmy를 오프라인으로 핑했습니다. 그의 원래 문제 보고서를 오해했을 가능성이 있습니다. 280 자 포럼이 버그를 명확하게 전달하는 데 항상 효율적인 것은 아닙니다. ;)

GrabYourPitchforks 에 2020년 10월 23일

😄3 👍3

명확히하기 위해 Contains API는 서수 연산을 수행합니다. 문자열 비교 플래그가없는 IndexOf 은 서 수가 아닌 언어 연산입니다. 포함 동작을 IndexOf와 비교하려면 IndexOf(expected, StringComparison.Ordinal) 를 사용해야합니다.
차이점에 대해 자세히 알아 보려면 https://docs.microsoft.com/en-us/dotnet/csharp/how-to/compare-strings 가 유용한 링크입니다.

tarekgh 에 2020년 10월 23일

👍5

트위터에서 해명을 받았습니다. 앱이 루프에서 IndexOf 를 호출하지 않습니다. 이것은 단지 표준 3.0 대 5.0 행동 차이 보고서입니다.

GrabYourPitchforks 에 2020년 10월 23일

👍1

@GrabYourPitchforks 트위터 회신에 https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu 링크를 공유하고 이전 동작으로 돌아가는 구성 스위치가 있다고 언급 할 수 있습니까?

tarekgh 에 2020년 10월 23일

트위터에서 해명을 받았습니다. 앱이 루프에서 IndexOf를 호출하지 않습니다. 이것은 단지 표준 3.0 대 5.0 행동 차이 보고서입니다.

감사합니다, @GrabYourPitchforks ... 이것을 기반으로 설계에 따라 닫습니다.

safern 에 2020년 10월 23일

👎7

여기에 더 추가하려면 NLS로 다시 전환하지 않고 이전 동작을 얻으려면 다음을 수행하십시오.

```C #
CultureInfo.CurrentCulture.CompareInfo.IndexOf (실제, 예상, CompareOptions.IgnoreSymbols)

```C#
    actual.IndexOf(expected, StringComparison.Ordinal)

대신에

C# actual.IndexOf(expected)

원하는 동작을 얻어야합니다.

tarekgh 에 2020년 10월 23일

👍6

링크 된 ICU 관련 문서 (https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/)에서 \r\n 대 \n 에 대한 내용을 볼 수 없습니다. 세계화 -icu).

정말 계획된 변경 이었습니까?

ForNeVeR 에 2020년 10월 23일

👍3

@ForNeVeR ICU와 NLS의 모든 차이점을 나열하는 것은 어려울 것입니다. 이 문서는 ICU 로의 전환의 주요 변경 사항에 대해 이야기하고 있습니다. 앞서 언급했듯이 Contains 의 결과를 StringComparison 매개 변수없이 IndexOf 와 비교하는 것은 옳지 않습니다. 원하는 경우 이전 동작을 얻을 수있는 몇 가지 방법을 위에 나열했습니다. 이 문제에 대한 보고서에서 IndexOf의 사용은 Ordinal 옵션을 사용해야하는 것으로 보이며 이러한 경우 언어 비교를 사용하는 것은 올바르지 않습니다. 이러한 경우 언어 비교를 사용하면 다른 환경에서 다른 결과를 제공 할 수있는 현재 문화에 따라 달라질 수 있습니다.

정말 계획된 변경 이었습니까?

예 ICU로 전환하는 것은 여러 가지 이유로 의도적 인 변경입니다. Windows는 현재 NLS를 통해 ICU를 사용하여 승격합니다. ICU는 어쨌든 미래입니다. 또한 ICU는 Windows / Linux / OSX 또는 지원되는 모든 플랫폼에서 일관된 동작을 할 수있는 기회를 제공합니다. ICU를 사용하면 앱이 원하는 경우 세계화 동작을 사용자 정의 할 수 있습니다.

문서에 표시된대로 원하는 경우 이전 동작으로 다시 전환 할 수있는 옵션이 있습니다.

tarekgh 에 2020년 10월 23일

👍2

참조 된 문서에 따르면 Windows의 ICU / NLS 동작은 실제 환경의 icu.dll 가용성에 따라 자동으로 전환 될 수 있습니다. 이것은 게시 된 독립형 앱에 큰 놀라움이 될 수 있습니다. ICU가 모든 대상 환경에서 사용 가능한 것은 아니기 때문에 스위치가 결정된 경우이 문제를 해결하기 위해 .NET이 ICU를 제공 할 것으로 예상합니다. 이 선택적 런타임 종속성은 상황을 더욱 재미있게 만듭니다.

hypersw 에 2020년 10월 23일

ICU가 모든 대상 환경에서 사용 가능한 것은 아니기 때문에 스위치가 결정된 경우이 문제를 해결하기 위해 .NET이 ICU를 제공 할 것으로 예상합니다. 이 선택적 런타임 종속성은 상황을 더욱 재미있게 만듭니다.

이제 ICU가 NuGet 패키지로 게시됩니다. 앱은 이러한 패키지를 사용하여 자체 포함 된 앱이 ICU를 갖도록 할 수 있습니다. 문서 의

tarekgh 에 2020년 10월 23일

@tarekgh , 나는 Contains 와 IndexOf 사이의 다른 결과가 그 자체로 문제가 아니라는 데 동의합니다.

이것은 로케일 / NLS / ICU 관련 변경에서 기대하는 것이 아닙니다. 사실, 다른 프로그래밍 언어 / 런타임이 그렇게 작동한다고 생각할 수 없었습니다.

다음은 .NET 5 RC 2에서 깨진 간단한 테스트 케이스입니다.

var actual = "\n\r\nTest";
var expected = "\nTest";

Console.WriteLine($"actual.IndexOf(expected): {actual.IndexOf(expected)}"); // => -1

정말 그렇게 작동할까요? 또한 왜? 실제로 무엇을하려고합니까?

정말 계획된 변경 이었습니까?
예 ICU로 전환하는 것은 여러 가지 이유로 의도적 인 변경입니다.

문자열 "\ n \ r \ nTest"에 ICU가 활성화 된 "\ nTest"가 포함되어 있습니까? 아니, 분명히 그렇지 않습니다!

그리고 아무도 불평하지 않았습니까? 기회가 아닙니다!

ICU가 어차피 라인 엔딩에 관심이있는 이유는 무엇입니까? 일부 로케일에는 고유 한 로케일 별 줄 끝이 있습니까?

ForNeVeR 에 2020년 10월 24일

👍47 👀2 🚀2 ❤1 🎉1

문제는 다른 ASCII 전용 문자열 내에서 하나의 ASCII 전용 문자열을 찾을 수없는 IndexOf입니다 (ASCII 전용 문자열에 적용된 로케일 종속 동작이 있는지 확실하지 않습니다!).

ASCII는 로케일 독립적입니다. http://userguide.icu-project.org/collation/concepts 링크를 참조하십시오. ASCII 문자의 동작이 문화에 따라 어떻게 다른지 예를 들어보십시오.

For example, in the traditional Spanish sorting order, "ch" is considered a single letter. All words that begin with "ch" sort after all other words beginning with "c", but before words starting with "d".
Other examples of contractions are "ch" in Czech, which sorts after "h", and "lj" and "nj" in Croatian and Latin Serbian, which sort after "l" and "n" respectively.

또한 ICU는 많은 전문가들이 잘 생각하는 Unicode Standard에서 데이터와 동작을 선택한다는 점을 분명히하고 싶습니다. @GrabYourPitchforks 는 우리가 여기서 이야기하고있는 \r\n\ 사건에 대한 자세한 내용을 게시 할 것입니다. 그러나 한편, 특히 다음을 언급하는 섹션에서 https://unicode.org/reports/tr29/ 문서에 익숙해 질 수 있습니다.

Do not break between a CR and LF. Otherwise, break before and after controls.
--
GB3 | CR | × | LF
GB4 | (Control \| CR \| LF) | ÷ |  
GB5 |   | ÷ | (Control \| CR \| LF)

ICU가 어차피 라인 엔딩에 관심이있는 이유는 무엇입니까? 일부 로케일에는 고유 한 로케일 별 줄 끝이 있습니까?

이것은 마지막 단락에서 다룹니다.

죄송하지만 이것이 계획된 변경이라고 생각하지 않으므로 강조하고 싶습니다. 누구도 그러한 변경을 계획하는 것을 상상할 수 없었습니다. 마찬가지로 .NET 팀의 사람들이 함께 앉아 토론했습니다.
이것은 계획되거나 예상되는 변경처럼 보이지 않고 대신 매우 심각한 버그, 큰 호환성 차단기처럼 보입니다. 이 때문에 새롭고 이식 된 .NET 응용 프로그램은 새 런타임에서 제대로 작동하지 않습니다. 문자열 내부에서 하위 문자열을 찾을 수 없기 때문입니다!

이것은 잘 계획된 작업이며 깊이 생각했습니다. 오래 전에 게시하고 공개적으로 공유 한 https://github.com/dotnet/runtime/issues/826 문제를 볼 수 있습니다.
세계화 동작은 .NET뿐만 아니라 OS 및 기타 플랫폼에서도 언제든지 변경 될 수 있음을 강조하고 싶습니다. 또한 앱이 사용하는 동작이 변경되지 않도록 특정 ICU 버전을 사용할 수 있도록 ICU 앱 로컬 기능을 지원했습니다. 또 다른 사실은 Windows 자체가 ICU를 사용하여 홍보하는 과정에 있으며 언젠가는 ICU 동작이 대부분의 사용자가 사용하게 될 것입니다.

서수 깃발처럼. 그러나 .NET 5에서 그렇게 어렵게하기로 결정했다면 정상인 서수 기본값을 사용하도록 만들 수 없습니까? .NET 5 RC 2에서 볼 수있는 현재 변경 사항보다 응용 프로그램이 더 적게 중단 될 것이라고 생각합니다.

실제로 우리는 이전에 Silverlight 릴리스 중에 서수 동작을 기본값으로 설정하려고 시도했으며 여기에보고 된 것보다 훨씬 많은 문제가 발생했습니다. 우리는 개발자가 IndexOf 와 같은 것을 호출 할 때 의식을 갖고 의도를 표현하기 위해 의도적으로 StringComparison 플래그를 제공 할 수 있도록 더 많은 방법을 찾고 있습니다. 우리는 당신이 생각 해낼 수있는 모든 아이디어를 환영합니다.

또한 IndexOf가 항상 문화 별 방식으로 작동 함에도 불구하고 서수 플래그없이 IndexOf를 사용하는 수많은 코드가 있고 그 코드가 작동하는 데 사용된다는 것을 모두 이해한다고 생각합니다 (일부 / 대부분의 경우, 적어도). 그리고 .NET 5 업데이트 후 작동이 중지됩니다.

그렇기 때문에 원하는 경우 이전 동작으로 다시 전환 할 수있는 구성 스위치를 제공합니다. System.Globalization.UseNls를 살펴보십시오.

tarekgh 에 2020년 10월 25일

👀1 👍1

@tarekgh , 철저한 설명에 감사드립니다!

지금은이 특정 \r\n 동작에 대한 자세한 내용을 기다리는 것이 좋습니다. 이 특정 검색을 수행 할 때 IndexOf "Grapheme Cluster Boundary Rules"(그리고 그렇게해야하는지 여부)를 사용하는 방법이 명확하지 않습니다.

또한 유니 코드 사양이 여기에 관련이 있더라도 https://unicode.org/reports/tr29/ 를 읽어 보면 마지막 \n 와 일치하는 것이 금지되어 있는지 확신 할 수 없습니다 CR | × | LF 되어 있는데, × 는 "경계 없음 (여기에서 중단을 허용하지 않음)"을 의미합니다. 따라서 시퀀스를 끊을 때 \r\n\n , 첫 번째 문자와 두 번째 문자 사이에 "분리"를 두는 것만 금지하지만 세 번째 문자 앞에 "분리"를 두는 것은 괜찮습니다. 그래서 저는 \r\n\n 를 두 개의 분리 된 "문자 소 클러스터"로 읽었습니다. IndexOf 가 전체 문자 소 클러스터와 일치해야하고 클러스터의 일부를 절대 건드리지 않더라도 여전히 하위 문자열 \nTest 찾을 수 있습니다. \n\r\nTest .

또한 ICU 및 / 또는 유니 코드 사양에 의존하는 다른 런타임 / 프로그래밍 언어가이 특정 예제에서 동일하게 작동해야한다고 말하고 있습니까?

우리는 개발자가 IndexOf 와 같은 것을 호출 할 때 의식을 갖고 의도를 표현하기 위해 의도적으로 StringComparison 플래그를 제공 할 수 있도록 더 많은 방법을 찾고 있습니다. 우리는 당신이 생각 해낼 수있는 모든 아이디어를 환영합니다.

_ (필요한 면책 조항 : 저는 ReSharper를 포함한 여러 프로젝트에서 JetBrains에서 일합니다.) _

처음에는 광고처럼 들리지 않게이 점을 여기에 가져오고 싶진 않았지만, 이것이 매우 관련이있는 것 같아서해야합니다. ReSharper는 기본적으로 IndexOf 호출하는 사용자 코드에 대해 다음 경고를 표시합니다.

_ (이 스레드에 참여하기 전에는이 특정 ReSharper 진단에 대해 알지 못했기 때문에이 논의에 참여 하지 않습니다. ) _

따라서 다른 모든 도구에서도 기본적으로 그러한 알림을 표시하거나 그러한 알림으로이 가짜 방법을 완전히 비난하는 것이 매우 좋은 생각이라고 생각합니다.

ForNeVeR 에 2020년 10월 25일

👍3

뿡뿡

또한 unicode.org/reports/tr29를 읽었을 때 유니 코드 사양이 여기에 관련이 있더라도 (아주 잘 될 수 있습니다!) 마지막 \ n과 일치하는 것이 금지되어 있는지 확신 할 수 없습니다. 사양을 읽으면서 CR | × | LF, 여기서 ×는 "경계 없음 (여기서는 끊기를 허용하지 않음)"을 의미합니다. 따라서 시퀀스를 깨뜨릴 때 \ r \ n \ n 첫 번째 문자와 두 번째 문자 사이에 "분리"를 두는 것만 금지하지만 세 번째 문자 앞에 "분리"를 두는 것이 좋습니다. 그래서 저는 \ r \ n \ n 두 개의 분리 된 "문자 소 클러스터"로 읽었습니다.

맞아요. \r\n\n 는 \r\n 및 \n 로 2 개의 클러스터가됩니다.

그리고 IndexOf가 전체 자소 클러스터와 일치해야하고 클러스터의 일부를 만지지 않더라도 문자열 \ n \ r \ nTest 내부에서 하위 문자열 \ nTest를 찾아야합니다.

그것은 틀 렸습니다. \n\r\nTest 는 부분으로 나뉩니다. \n , \r\n 및 Test . \nTest 는이 문자열의 일부가 될 수 없음이 분명합니다. 클러스터를 대체하는 그것에 대해 생각 \r\n 몇 가지 기호 X . 이제 소스 문자열은 \nXTest 포함하지 않는 \nTest 입니다.

또한 ICU 및 / 또는 유니 코드 사양에 의존하는 다른 런타임 / 프로그래밍 언어가이 특정 예제에서 동일하게 작동해야한다고 말하고 있습니까?

기본 데이터 정렬 강도 수준을 사용하는 경우 대답은 예입니다. ICU는 결과에 영향을 줄 수있는 강도 수준을 변경할 수 있습니다. 예를 들어, 앞서 언급했듯이 다음과 같은 작업을 수행합니다.

CultureInfo.CurrentCulture.CompareInfo.IndexOf(actual, expected, CompareOptions.IgnoreSymbols)

강도 수준을 변경하고 작업에서 기호를 무시하도록합니다 ( \n 및 \r 은 해당 시점에서 무시되므로 변경됨).

또한 순수 ICU 네이티브 C 앱을 작성하고 동일한 경우를 실행했습니다.

void SearchString(const char *target, int32_t targetLength, const char *source, int32_t sourceLength)
{
    static UChar usource[100];
    static UChar utarget[100];

    u_charsToUChars(source, usource, sourceLength);
    u_charsToUChars(target, utarget, targetLength);

    UErrorCode status = U_ZERO_ERROR;
    UStringSearch* pSearcher = usearch_open(utarget, targetLength, usource, sourceLength, "en_US", nullptr, &status);
    if (!U_SUCCESS(status))
    {
        printf("usearch_open failed with %d\n", status);
        return;
    }

    int32_t index = usearch_next(pSearcher, &status);
    if (!U_SUCCESS(status))
    {
        printf("usearch_next failed with %d\n", status);
        return;
    }

    printf("search result = %d\n", index);
    usearch_close(pSearcher);
}


int main()
{
    SearchString("\nT", 2, "\r\nT", 3);
    SearchString("\nT", 2, "\n\nT", 3);
}

이 앱은 결과를 출력합니다.

search result = -1
search result = 1

.NET에서 볼 수있는 동작과 동일합니다.

지금은이 특정 \ r \ n 동작에 대한 자세한 내용을 기다리는 것이 좋습니다. IndexOf가이 특정 검색을 수행 할 때 "Grapheme Cluster Boundary Rules"를 사용하는 방법 (그리고이를 수행해야하는지 여부)이 명확하지 않습니다.

확실히 클러스터링이 데이터 정렬 작업에 영향을 미치고 있습니다. http://unicode.org/reports/tr29/tr29-7.html 을 보면 다음과 같이 명확하게 설명되어 있습니다.

Grapheme clusters include, but are not limited to, combining character sequences such as (g + °), digraphs such as Slovak “ch”, and sequences with letter modifiers such as kw. Grapheme 클러스터 경계는 데이터 정렬에 중요합니다. , regular-expressions, and counting “character” positions within text. Word boundaries, line boundaries and sentence boundaries do not occur within a grapheme cluster. In this section, the Unicode Standard provides a determination of where the default grapheme boundaries fall in a string of characters. This algorithm can be tailored for specific locales or other customizations, which is what is done in providing contracting characters in collation tailoring tables.

더 자세한 내용이 있는지 확실하지 않지만 여기에 추가 할 내용이 더 있으면 @GrabYourPitchforks에 댓글을 달겠습니다.

따라서 다른 모든 도구에서도 기본적으로 그러한 알림을 표시하거나 그러한 알림으로이 가짜 방법을 완전히 비난하는 것이 매우 좋은 생각이라고 생각합니다.

감사!
이것은 우리가 생각하는 것과 같은 방향입니다.

tarekgh 에 2020년 10월 26일

👍3 👀2

제 자신을 위해 버전 간의 다양한 과부하를 비교했습니다.

| 방법 | netcoreapp3.1 | net5.0 |
| ------------------------------------------------- --------------- | ----------------- | ---------- |
| actual.Contains(expected) | 사실 | 사실 |
| actual.IndexOf(expected) | 1475 | -1 |
| actual.Contains(expected, StringComparison.CurrentCulture) | 사실 | 거짓 |
| actual.IndexOf(expected, StringComparison.CurrentCulture) | 1475 | -1 |
| actual.Contains(expected, StringComparison.Ordinal) | 사실 | 사실 |
| actual.IndexOf(expected, StringComparison.Ordinal) | 1475 | 1475 |
| actual.Contains(expected, StringComparison.InvariantCulture) | 사실 | 거짓 |
| actual.IndexOf(expected, StringComparison.InvariantCulture) | 1475 | -1 |

jbogard 에 2020년 10월 26일

👍13 😄5

이를 위해 분석기를 포함하십시오.

rcollina 에 2020년 10월 26일

👍12

이것은 장기적으로는 좋지만 .NET 5가 출시되면 엄청난 양의 이탈을 일으키는 변경 사항 중 하나 인 것 같습니다. 따라서 이러한 메서드의 동작이 .NET 5와 .NET Core 3.1간에 다른 경우 .NET 5가 전달 된 string 를 조작하는 .NET Standard 2.0 라이브러리 내부에 정의 된 개체를 호출 할 때 어떤 일이 발생합니까? .NET callsite에서? 이전 동작이 사용됩니까 아니면 새로운 동작이 사용됩니까?

Aaronontheweb 에 2020년 10월 26일

👍16 👀2

@Aaronontheweb 새로운 행동. 처음에는 netstandard2.0 를 목표로하는 NUnit3의 어설 션에서 이것을 보았습니다. 업그레이드 후 대상 프레임 워크 만 변경했을 때 테스트가 실패하기 시작했습니다.

jbogard 에 2020년 10월 26일

😕4

그것은 대단하지 않습니다-내가 참조하는 오래된 라이브러리가 업그레이드를 원할 때 수행하는 작업을 제어 할 수 없습니다.

Aaronontheweb 에 2020년 10월 26일

👍4

단위 테스트에서이를 감지하지 못하고 프로덕션에 적용하지 않는 앱은 몇 개입니까?
.NET 팀은 이로 인해 발생할 수있는 고통과 문제점 및 비용을 고려 했습니까?

petarrepac 에 2020년 10월 26일

👍5

그것은 대단하지 않습니다-내가 참조하는 오래된 라이브러리가 업그레이드를 원할 때 수행하는 작업을 제어 할 수 없습니다.

멋진 함정!
이상한 벌레를 사냥하며 낭비하는 행복한 시간 🎉
하지만 InvariantGlobalization이이 문제를 해결하지 못하는 이유는 무엇입니까?

pr0vieh 에 2020년 10월 26일

이를 위해 분석기를 포함하십시오.

네. 그리고 F # 지원을 잊지 마세요.

단위 테스트에서 감지하지 못하는 앱 수

0-단위 테스트는 .NET BCL 자체와 같은 외부 라이브러리 / 프레임 워크를 테스트하기위한 것이 아니기 때문입니다.

내 견해는이 동작 변경 모드를 제어 할 수있는 어셈블리 레벨 속성이 있어야한다는 것입니다. 최소한 어셈블리 별 수준에서 옵트 인 / 옵트 인 할 수 있습니다. 이것은 .NET Standard 문제도 사라짐을 의미합니다.

nbevans 에 2020년 10월 26일

그것은 대단하지 않습니다-내가 참조하는 오래된 라이브러리가 업그레이드를 원할 때 수행하는 작업을 제어 할 수 없습니다.

왜 당신이 그것을 통제 할 수 없는지 모르겠습니다. 모든 문자열 비교는 ICU 또는 NLS를 사용합니다. 원하는 경우 compat 스위치를 사용

시간이 지남에 따라 안정적으로 유지되는 세계화 데이터에 의존 할 수 없습니다. 안정적인 세계화 데이터에 의존하는 사람들을 망가 뜨리는 것을 두려워하지 않는다는 Windows 팀의 의견을 들어보십시오. 세계화 기능은 블랙 박스 여야합니다. 라이브러리 (특히 .NET Standard를 대상으로하는 라이브러리)가 이와 같은 구현 세부 사항에 의존한다고 말하는 것은 이치에 맞지 않는다고 생각합니다.

많은 사람들이 Windows와 Linux에서 서로 다른 결과를 반환하는 .NET 세계화 기능에 대해 불평 한 것처럼 확신합니다. Windows와 다른 플랫폼 간의 동작을 통합하는 것이 더 낫습니다. 올바른 코드는 세계화 데이터가 불변에 의존해서는 안됩니다.

reflectronic 에 2020년 10월 26일

👍5

StringComparison.Ordinal 도 기본 비교 전략으로 만들기 위해 브레이킹 체인지를 고려 하시겠습니까? 세계화가 매우 불안정하기 때문에 적어도 기본 구현이 안정적인 알고리즘을 대신 사용하는 것이 합리적입니다. string.Equals(...) 또는 string.Contains(...) 등을 사용하는 사람들 중 StringComparison 를 통과하지 않고 사용하는 99.9 %의 사람들이 로케일.

편집 : 내 질문에 이미 답변 된 것 같습니다.

실제로 우리는 이전에 Silverlight 릴리스 중에 서수 동작을 기본값으로 설정하려고 시도했으며 여기에보고 된 것보다 훨씬 많은 문제가 발생했습니다. 우리는 개발자가 IndexOf와 같은 것을 호출 할 때 의식을 갖고 의도를 표현하기 위해 의도적으로 StringComparison 플래그를 제공 할 수 있도록 더 많은 방법을 찾고 있습니다. 우리는 당신이 생각 해낼 수있는 모든 아이디어를 환영합니다.

Tyrrrz 에 2020년 10월 26일

👍3

원하는 경우 compat 스위치를 사용하여 ICU를 옵트 아웃 할 수 있으며 모든 라이브러리가 이전 동작으로 되돌아갑니다.

저는 응용 프로그램이 아닌 생계를위한 라이브러리를 만듭니다. 나는 이것을 처리하는 컴파일 타임 방법을 선호합니다.

우리가하는 대부분의 작업은 InvariantCulture 이며, 제가 이전에 이해 한 바에 따르면 설계 상 변경할 수 없습니다. 이러한 상황에서도 IndexOf 의 동작이 .NET 5.0과 .NET Core 3.1간에 다른 것 같습니다.

Aaronontheweb 에 2020년 10월 26일

분석기가 기존 프로젝트에 어떤 도움을 줄 수 있습니까?

petarrepac 에 2020년 10월 26일

@petarrepac 도 C # 전용입니다.

isaacabraham 에 2020년 10월 26일

👍2

@isaacabraham 과 VB도;)

Tyrrrz 에 2020년 10월 26일

나는 이것을 처리하는 컴파일 타임 방법을 선호합니다.

@Aaronontheweb 당신은 이것을 처리하는 컴파일 타임 방법이 있습니다 (앱을 컴파일 할 때). 이것을 프로젝트에 추가 할 수 있습니다.

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" />
</ItemGroup>

편집 : 이것은 라이브러리를 사용하는 앱에만 해당되며, 불행히도 라이브러리를 작성할 때이를 제어 할 수 없습니다.

장기적으로 Windows 팀은 ICU 로의 이전을 추진하고 있으므로 어느 시점에서 ICU는 세계화 스토리가 될 것이며 우리는 OS 라이브러리를 둘러싼 얇은 래퍼 일뿐입니다.

.NET 5가 .NET 호출 사이트에서 전달 된 문자열을 조작하는 .NET Standard 2.0 라이브러리 내부에 정의 된 개체를 호출하면 어떻게됩니까? 이전 동작이 사용됩니까 아니면 새로운 동작이 사용됩니까?

새로운 동작은 런타임에 따라 달라지며 .NET Standard는 런타임을 구현하기위한 표준 일 뿐이므로 사용됩니다. 그러나 이것이 Unix와 Windows간에 플랫폼 일관성을 가져오고 있다는 점에 유의하십시오. 사람들이 Unix에서 우려하는 동일한 라이브러리를 실행하면 ICU 가 백업이므로 ICU 결과를 얻을 수 있습니다. Unix의 라이브러리.

safern 에 2020년 10월 26일

@reflectronic 은 https://github.com/dotnet/runtime/issues/43736#issuecomment -716681586의 모든 점에서 옳습니다.

여기 https://github.com/dotnet/runtime/issues/43736#issuecomment -716527590에 언급 된 @jbogard 결과에 대해 의견을 말하려면 Windows와 ICU 간의 언어 동작을 비교하여 결과를 요약하면됩니다. 덧붙여서 현재 ICU는 Windows의 많은 애플리케이션에서 사용되고 있으며 사용량이 증가 할 것으로 예상됩니다. 또한 이러한 결과는 .NET Core 3.1 이하가 설치된 Linux를 제외합니다. 이는 .NET 5.0과 Linux의 이전 버전 간의 일관성을 보여줍니다.

작동하던 라이브러리에 대한 요점은 깨질 것입니다. 이러한 라이브러리는 이미 Linux에서 손상 되었기 때문에 완전히 사실이 아닙니다.

StringComparison.Ordinal을 기본 비교 전략으로 만들기 위해 브레이킹 변경을 고려 하시겠습니까?

앞서 말씀 드렸지만 이미 시도해 보았지만 불만의 크기가 너무 커서 적용 할 수 없었습니다. 우리는 개발자가 데이터 정렬 API를 호출 할 때 문자열 비교 플래그를 지정하는 것을 의식하는 데 도움이되는 방법을 찾고 있습니다.

저는 응용 프로그램이 아닌 생계를위한 라이브러리를 만듭니다. 나는 이것을 처리하는 컴파일 타임 방법을 선호합니다.

예, 이러한 경우 일부 분석기가 도움이 될 수 있습니다. 일반적으로 데이터 정렬 API 호출을보고 서수 또는 언어 연산을 사용하려는 의도를 표시하지 않는 것이 무엇인지 확인합니다.

분석기가 기존 프로젝트에 어떤 도움을 줄 수 있습니까?

분석기는 코드를 스캔하고 플래그를 전달하지 않는 데이터 정렬 API 호출을 감지하면 이러한 호출을 살펴보고 문제가 감지되면 수정하는 데 도움이됩니다.

그것은 또한 C # 전용입니다.

변경 사항은 전역 적이어야하며 C #으로 제한되지 않는 .NET 런타임 내부에 있습니다.

tarekgh 에 2020년 10월 26일

👍4

@tarekgh C # 분석기는 VB 또는 F # 코드베이스에서 어떻게 표시됩니까?

isaacabraham 에 2020년 10월 26일

우리가하는 대부분의 작업은 InvariantCulture 이며, 제가 이전에 이해 한 바에 따르면 설계 상 변경할 수 없습니다.

비판적으로,이 변경 이전에는 크로스 플랫폼 코드에 대해 실제로 이것에 의존하는 것이 불가능했습니다. NLS와 ICU의 동작 방식은 변하지 않는 문화를 사용할 때에도 항상 동일하지는 않습니다 (이 문제에서 입증 됨). @tarekgh가 말했듯이이 코드는 Linux에서 계속 다르게 작동했습니다. 이 변경 사항이 적용되었으므로 모든 최신 Windows 설치에 대해 "불변 문화"가 의미하는 바는 모든 플랫폼에서 _ 실제로 _ 일관성이 있어야합니다.

reflectronic 에 2020년 10월 26일

👍1

이것은 놀라운 일이 될 수 있지만, 다른 많은 라이브러리 작성자가 수년 동안 해왔 던 것처럼 사용자보고의 결과로 수년 동안 플랫폼 차이와 관련된 수십 개의 버그를 찾아 수정했습니다.

.NET 5가 알려지지 않은 알려지지 않은 새로운 작물을 도입하고 내 라이브러리뿐만 아니라 다운 스트림 종속성에 대한 수정 사항을 다시 검토 할 것이라는 전망에 흥분하지 않습니다. 이는 사용자에게 새로운 생산성 향상을 가져 오지 않는 상당한 경제적 비용입니다. MSFT의 누군가는 이러한 변경에 대한 비용 / 편익 논의에서이를 고려해야합니다.

편집 : 이미 기술적 인 장점을 얻었습니다-예, 감사합니다. 비용이 아닌 이러한 변경으로 인한 명백하지 않은 경제적 이익을 판매하도록 도와주세요. 이 문제가 어떻게 나타나는지 고려할 때 사용자가 도약하고 .NET 5로 업그레이드해야하는 이유는 무엇입니까?

Aaronontheweb 에 2020년 10월 26일

👍2

@tarekgh C # 분석기는 VB 또는 F # 코드베이스에서 어떻게 표시됩니까?

단일 분석기로 C # 및 VB를 처리 할 수 있지만 (가능한 경우 분석기를 언어에 구애받지 않게 만들기 위해 노력하고 있습니다) 현재 F #에 대한 분석기 적용 범위를 얻을 수 없습니다.

jeffhandley 에 2020년 10월 26일

👍1

@Aaronontheweb 문화적 기능을 사용하는 모든 사람은 ICU 변경을하지 않았더라도 변경되지 않을 것이라고 가정합니다. Windows 팀의 https://docs.microsoft.com/en-us/archive/blogs/shawnste/locale-culture-data-churn 블로그에서 NLS 동작도 개선을 위해 변경되고 있음을 알려줍니다. 따라서 여기서 문제는 앱 / 라이브러리 관점에서 잘못된 가정을 포착하는 것 이상으로 ICU로 이동하는 것이 아닙니다. 5.0으로 업그레이드하는 것은 다른 이전 버전으로 업그레이드하는 것과 동일합니다. 앱은 새롭고 멋진 기능을 많이 갖게 될 것이며 앱은 릴리스 사이에 몇 가지 주요 변경 사항이있을 수 있으므로 테스트해야합니다. 우리는 항상 세계화가 OS와 OS 버전 사이에서 언제든지 바뀔 수 있다고 말하고 있기 때문에 세계화 동작 변화가 정말로 깨지는 것을 고려하지 않습니다. 앞서 언급했듯이 NLS를 계속 사용하여 5.0으로 업그레이드하도록 선택할 수있는 구성 스위치가 있습니다. ICU는 실제로 업그레이드 결정의 요소가 아닙니다. 이제 ICU를 통해 앱은 OS 전반에 걸쳐 일관성을 높일 수있는 기회를 갖게되며 앱 로컬 ICU를 사용하기로 결정한 경우 세계화 동작을 더 많이 제어 할 수 있습니다. 우리는 이전보다 훨씬 더 많은 제어권을 앱에 제공하고 있습니다.

tarekgh 에 2020년 10월 26일

👍5

(이 문제는 IndexOf _per se_를 추적하지 않습니다. 오히려 문화 인식 비교자를 기본으로하는 Compare 루틴의 의도하지 않은 결과에 대해 설명합니다.)

GrabYourPitchforks 에 2020년 10월 26일

🚀1 👍1

분석기가 기존 프로젝트에 어떤 도움을 줄 수 있습니까?
분석기는 코드를 스캔하고 플래그를 전달하지 않는 데이터 정렬 API 호출을 감지하면 이러한 호출을 살펴보고 문제가 감지되면 수정하는 데 도움이됩니다.

csproj에 분석기를 추가해야한다고 생각합니다.
이것은 자동으로 발생하지 않습니다. 따라서 많은 기존 프로젝트가 이러한 분석기없이 .NET 5로 이동 될 것입니다.
또한 이미 언급했듯이 F # 프로젝트에는 도움이되지 않습니다.

petarrepac 에 2020년 10월 26일

@jeffhandley 감사합니다, 내가 이미 이해 한 것을 확인합니다. 따라서 가능한 "해결 방법"이 F # 사용자에게 도움이되지 않는다는 점을 인식하는 것이 중요합니다 (작은 시장이지만 .NET의 일류 시민으로서 MS에서 완전히 지원하는 시장). 이것이 무엇을 의미하는지 전혀 모릅니다.

변경 사항은 전역 적이어야하며 C #으로 제한되지 않는 .NET 런타임 내부에 있습니다.

isaacabraham 에 2020년 10월 26일

이것이 무엇을 의미하는지 전혀 모릅니다.
변경 사항은 전역 적이어야하며 C #으로 제한되지 않는 .NET 런타임 내부에 있습니다.

.NET 런타임을 사용하는 모든 언어가 C #뿐만 아니라 영향을받을 것임을 의미했습니다.

tarekgh 에 2020년 10월 26일

나는 특히 계획이 현재 행동을 바꾸는 것이라면 새로운 세계에서 이러한 문제를 발견 할 분석기가 있어야한다는 내 의견을 다시 강하게 말할 것이다.

나는 그렇게하는 것의 기술적 장점을 완전히 이해하며 변경하지 말라고 제안하는 것이 아닙니다 (장기적으로 이것이 올바른 조치 인 것 같습니다). 이미 모범 사례로 문서화되지 않았다고 말하는 것도 아닙니다. 내가 말하는 것은 우리가 .NET 5로 옮기려고 시도하는 개발자들에게 이것이 정말로 크고, 빨간색이고, 깜박이는 오류가 될 필요가 있다는 것입니다. 즉시 개발자들은 이것이 "그냥 작동한다"고 가정 할 것입니다.

현재 @meziantou 의이 Roslyn 분석기 라이브러리를 https://github.com/meziantou/Meziantou.Analyzer/tree/master/docs.

이 특별한 경우 MA0074가 발생합니다-암시 적 문화에 민감한 방법을 피하십시오

이것은 정말로 상자에서 벗어난 것이 필요하다고 말하면서 여기 에이 Roslyn 문제를 열었습니다 .https : //github.com/dotnet/roslyn-analyzers/issues/4367

aolszowka 에 2020년 10월 26일

👍8

@tarekgh 명확히

isaacabraham 에 2020년 10월 27일

👍2

우리는 개발자가 IndexOf와 같은 것을 호출 할 때 의식을 갖고 의도를 표현하기 위해 의도적으로 StringComparison 플래그를 제공 할 수 있도록 더 많은 방법을 찾고 있습니다. 우리는 당신이 생각 해낼 수있는 모든 아이디어를 환영합니다.

[Obsolete] 속성을 사용하여 이전 메소드를 폐기하는 것은 어떻습니까?

fschmied 에 2020년 10월 28일

👍7

API 표면은 동일하지만 동작이 변경되면 .NET Standard 호환성은 어떻게됩니까?

rcollina 에 2020년 10월 28일

👍1

그래 소 클러스터를 존중하기위한 변경은 영향이 잘 문서화되어있는 한 나를 괴롭히지 않습니다. 밀접하게 관련된 문자열 메서드 패밀리 구성원이 서로 일관되지 않게 동작하는 변경 사항입니다.

문자, 자소 클러스터 또는 로케일의 모호함과 무관하게 비공식적 인 문자열 뭉킹을 수행하는 사람은 str.Contains (whatever)가 성공하면 str.IndexOf (whatever ) 우리는 방금 그것이 거기에 있고 따라서 찾을 수 있다고 들었 기 때문입니다. 어떤 두 번째 매개 변수가 기본값인지는 중요하지 않습니다. 기본값은 메소드간에 동일 하게 작동하므로 사용하기 위해 모든 미묘함을 연구 할 필요가 없기 때문입니다.

이와 같은 불일치는 전문가 만이 성공적으로 사용할 수있는 언어를 생성하고 코드 캠프에서 나오는 사람들을 소외시킵니다. 이런 식으로 진입하기 위해 기준을 높이 지 마십시오.

lupestro 에 2020년 10월 28일

👍23

@lupestro에 동의합니다. 메서드 동작의 불일치는 매우 우려됩니다. 오래 지속되는 방법이 다르게 행동하고 일관되지 않게 행동한다면 많은 슬픔이있을 것입니다. 사람들은 이것에 부딪 히고 API에 배신감을 느끼고 다른 시간 폭탄이 폭발하기를 기다리고있는 것을 궁금해 할 것입니다. 많은 사람들이 .NET 입양 자들이 이런 종류의 문제에 대해 C #을 쓸 것입니다. 로케일을 허용하지 않는 오버로드를 제거하거나 메서드의 기본 로케일을 정규화해야하는 것 같습니다. 이미 Compare 및 CompareOrdinal이 있으며 (Last) IndexOf (Any) 및 (Last) IndexOf (Any) Ordinal이 필요할 수 있습니다. 나는 그 해결책을 좋아하지 않지만 적어도 현재 존재하는 것과 일치 할 것입니다. 아마도 문자열에서 서수 사용에 대한 아이디어는 감가 상각되어야합니다. 빠르거나 옳은 것을 선택해야한다면 매번 '옳은'을 선택하겠습니다. 일관되지 않고 직관적이지 않은 행동은 매우 실망 스럽습니다.

이 문제는 이미 종결되었으므로 .NET 5.0에서 앞으로 나아갈 것이라고 이미 결정했다고 생각합니다. 이 물건은 어렵고 문화 (시간과 같은) 정보는 모든 종류의 비 기술적 인 이유로 변경 될 수 있다는 것을 알고 있습니다. 개발자는이를 인식해야하지만 자체 일관성을 유지하려면 API에 의존해야합니다. 문제를 나타내는 @aolszowka 가 지적한 경고 (5.0에서)가 있어야하며 더 중요한 것은 문제인 이유입니다. 앞으로 나아가는 것이 중요하며 때로는 오래된 행동 / 가정을 "파괴"해야한다는 의미입니다. 그렇다고 새로운 불일치가 도입되어야 함을 의미하지는 않습니다. 이 변경은 코드뿐만 아니라 기대치를 깨뜨립니다. 메서드를 일관되게 만들 수없는 경우에는 도중에 내 코드를 날려 버리는 직관적이지 않은 오류가 발생할 가능성이있는 것보다 CultureInfo를 명시 적으로 지정 (확장 메서드를 통해 처리 할 수 있음)하는 것이 좋습니다. 스트레스가 많은 개발주기 또는 최악의 고객 설치.

TLDR : 변경이 필요한 사항을 변경하지만 API의 일관성을 유지하지 마십시오. 부수려면 더 나은 것으로 교체하십시오.

Dweeberly 에 2020년 10월 28일

👍3 😕1

나는 수년간 .NET을 사용해 왔으며 이러한 기능을 사용할 때 항상 InvariantCulture로 기본 설정되어 있습니다. 영어 이외의 언어와 관련하여 저는 항상 다른 언어 별 문자의 별칭으로 작동하는 문자 쌍과 CurrentCulture를 기본값으로 비교할 때 이러한 쌍을 확인하는 추가 작업을 알고 있습니다. 예를 들어 브라우저에서 보낸 사용자가 선호하는 언어를 기반으로 스레드의 CurrentCulture를 설정하는 ASP.NET 코드를 작성할 때 이로 인해 저를 물었고, 영어를 사용하지 않는 사용자에 대한 비교는 코드를 미묘하게 깨뜨립니다. 특히 문자열에 사용자가 입력 한 (언어) 텍스트와 서수 텍스트가 혼합 된 경우

이 유니 코드 grapheme 클러스터 동작은 내가 일반적으로 사용하는 것처럼 Invariant 오버로드를 사용 했더라도 줄 바꿈 및 캐리지 리턴에 대한 서수 동작을 예상했기 때문에 나에게 새로운 것입니다. 더 많은 작업을 수행 하고 전문 지식 이

JustDre 에 2020년 10월 28일

👍4

오래된 방법을 사용하지 않는 것은 우리가 고려하고있는 한 가지입니다. 어제 밤에 제안 초안을 작성하고 내부 검토를 위해 쇼핑 중이며 몇 시간 후에 여기에 새 문제로 게시 할 것입니다.

GrabYourPitchforks 에 2020년 10월 28일

👍10

초안은 https://github.com/dotnet/runtime/issues/43956에 게시됩니다

버그를보고하는 경우 새로운 문제를 제출하고 해당 새로운 문제를 사용하여 버그를 설명하십시오.

이 특정 문제 ( "\r\n" 대 "\n" )에 대한 의견이 있으시면이 스레드에서 계속 응답 해주십시오. 감사!

GrabYourPitchforks 에 2020년 10월 28일

👍2

@GrabYourPitchforks 문서에 설명 된 접근 방식을 고려하는 동안 다시 엽니 다.

여기에 명확한 피드백이 많이 있습니다. 올바른 방법을 찾기 위해 노력하고 있으며이 문제를 계속 업데이트 할 것입니다.

danmosemsft 에 2020년 10월 28일

👍11 ❤9 🎉1

그래 소 클러스터를 존중하기위한 변경은 영향이 잘 문서화되어있는 한 나를 괴롭히지 않습니다. 밀접하게 관련된 문자열 메서드 패밀리 구성원이 서로 일관되지 않게 동작하는 변경 사항입니다.
문자, 자소 클러스터 또는 로케일의 모호함과 무관하게 비공식적 인 문자열 뭉킹을 수행하는 사람은 str.Contains (whatever)가 성공하면 str.IndexOf (whatever ) 우리는 방금 그것이 거기에 있고 따라서 찾을 수 있다고 들었 기 때문입니다. 어떤 두 번째 매개 변수가 기본값인지는 중요하지 않습니다. 기본 설정은 모든 방법을 사용하기 위해 모든 미묘한 부분을 연구 할 필요가 없도록하기 때문에 모든 방법에서 _ 동일하게 동작하기 때문입니다.
이와 같은 불일치는 전문가 만이 성공적으로 사용할 수있는 언어를 생성하고 코드 캠프에서 나오는 사람들을 소외시킵니다. 이런 식으로 진입하기 위해 기준을 높이 지 마십시오.

예, 이것은 내 걱정을 완전히 표현했습니다. 일반적인 중국 개발자로서 우리는 응용 프로그램 코드에서 문자열 관련 메서드를 호출 할 때 StringComparison 또는 CultureInfo 명시 적으로 입력하는 경우가 거의 없으며 제대로 작동합니다. 우리는 IndexOf 와 Contains 사이에 다른 행동을 기대하지 않습니다!
.net 5.0

.net 코어 3.1

.넷 프레임 워크

pinkli 에 2020년 10월 29일

👍3

@lupestro에 동의합니다. 메서드 동작의 불일치는 매우 우려됩니다. 오래 지속되는 방법이 다르게 행동하고 일관되지 않게 행동한다면 많은 슬픔이있을 것입니다.

아마도 여기서 핵심은 두 가지 방법이 항상 일관성이 없다는 것입니다. .NET 5.0에서 갑자기 일관성이 없어지지는 않았습니다. 내가 일을 올바르게 따르고 있다면 IndexOf 는 항상 현재 문화 비교를 사용했고 Contains 는 항상 서수 비교를 사용했습니다. 허가 된 .NET 5.0은 더 많은 불일치를 추가합니다. 그러나 여기서 실수는 이러한 불일치를 허용하는 원래 API 설계에있었습니다.

twinter-patriot 에 2020년 10월 29일

👍2

내가 일을 올바르게 따르고 있다면 IndexOf는 항상 서수 비교를 사용하고 Contains는 항상 현재 문화 비교를 사용했습니다. 허가 된 .NET 5.0은 더 많은 불일치를 추가합니다. 그러나 여기서 실수는 이러한 불일치를 허용하는 원래 API 설계에있었습니다.

맞습니다.하지만 반대의 경우 IndexOf(string) 는 현재 문화를 사용하고 IndexOf(char) 는 서수를 사용하고 Contains 는 서수를 사용합니다.

safern 에 2020년 10월 29일

👍1

최근에 다른 사람들이 언급 한 IndexOf 대 Contains 차이에 대해 간략히 설명하겠습니다.

IndexOf(string) 는 항상 _CurrentCulture_ 비교를 가정했으며 Contains(string) 는 항상 _Ordinal_ 비교를 가정했습니다. 이 불일치는 .NET Framework에서 다시 존재했습니다. 이는 .NET 5에 도입 된 새로운 불일치가 아닙니다. 예를 들어 .NET Framework (Windows의 NLS 기능을 사용)에서 합자 "æ"와 두 문자 문자열 "ae"는 언어 비교 자에서 동일한 것으로 비교됩니다. 이로 인해 다음과 같은 불일치가 발생합니다.

// Sample on .NET Framework, showing Contains & IndexOf returning inconsistent results
Console.WriteLine("encyclopædia".Contains("ae")); // prints 'False'
Console.WriteLine("encyclopædie".IndexOf("ae")); // prints '8' (my machine is set to en-US)

이러한 불일치는 10 년 이상 존재 해 왔습니다. 문서화 되어 있으며 이에 대한 https://github.com/dotnet/runtime/issues/43956 에서 생태계를 더욱 건전하게 발전시킬 수있는 방법에 대해 논의하고 있습니다.

이 특정 문제에 대해 우리가 진정으로 자문하고있는 것은 "불일치가 영원히 존재했음을 감안할 때,이 두 가지 방법이 더 큰 생태계에 해를 끼치기 전에 _ 실제로 _ 이탈 할 수있는 거리는 얼마입니까?"입니다. 우리는 여전히 그 임계 값이 있어야 할 곳을 정의하려고 노력하고 있다고 생각합니다. 이와 같은 보고서는 사람들이 실제로 이러한 API를 사용하는 방법과 고객의 행동에 대해 기대하는 바에 대한 통찰력을 제공하기 때문에 _ 매우 유용합니다 _. 프레임 워크의 관리자로서 우리는 기술 문서뿐만 아니라 실제 앱이 이러한 API를 사용하는 방식도 고려해야합니다.

이 의견은 특정 관점을 방어하기위한 것이 아닙니다. 제 의도는 제가 본 몇 가지 오해를 명확히하고 문제를 어떻게 구성했는지 설명하는 것입니다.

GrabYourPitchforks 에 2020년 10월 29일

❤6 👍1

InvariantCulture가 지정되어 있어도 ICU 버전에서 \n 가 일치하지 않는 것이 올바른 동작입니까?

ufcpp 에 2020년 10월 30일

아마도 다음 코드는 git 및 기본 설정 (autocrlf = true)을 사용하는 경우 Linux에서 5, Windows에서 -1을 표시합니까?

using System;

var s = @"hello
world";
Console.WriteLine(s.IndexOf("\n", StringComparison.InvariantCulture));

ufcpp 에 2020년 10월 30일

@ufcpp 예,이 스레드의 앞부분에서 설명한대로 예상되는 동작 인 ICU 당. 2 개의 문자 <CR><LF> 는 서로 인접 해있을 때 언어 목적 상 깨지지 않는 단위로 간주됩니다. 언어 비교 자 (예 : _InvariantCulture_)를 사용하여 <LF> 를 검색하면이 깨지지 않는 단위를 분할하므로 일치하는 항목이 생성되지 않습니다.

GrabYourPitchforks 에 2020년 10월 30일

👍2

모든 사람과 업데이트를 공유하고 싶습니다. ICU를 5.0 GA의 기본값으로 유지하기로 결정했습니다. https://github.com/dotnet/runtime/issues/43956 에서 추적되는 서수를 의도했을 때 실수로 언어 비교를 사용하는 함정을 개선하는 방법을 살펴 보겠습니다

이것은 매우 어려운 결정이었고, 플랫폼 간 표준화를위한 드라이브와 생태계에 미치는 호환성 영향을 비교해야했습니다.

현재 완화 조치가 불충분하다고 판단되는 경우 서비스시 \r\n 문제에 대한 추가 완화를 고려하기 위해이 문제를 열어 두겠습니다.

나는 또한 사람들이 ICU 스위치의 결과로 발생하는 문제를 계속보고하도록 장려하고 싶습니다. 비록 그 동작이 알려진 원인 일 수 있지만 그것이 "설계에 의한"것은 아닙니다. 우리는 계속해서 차이점을 조사하고 근본 원인을 이해하고이를 해결하기 위해 ICU 또는 .NET으로 변경 사항을 적용해야하는지 결정할 것입니다.

ericstj 에 2020년 10월 31일

👍6 👀2 ❤2

항상 StringComparison을 지정하는 분석기 규칙이 있습니다.

https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1307

NN--- 에 2020년 10월 31일

👍2

모든 사람과 업데이트를 공유하고 싶습니다. ICU를 5.0 GA의 기본값으로 유지하기로 결정했습니다. 서수를 의도했을 때 우연히 언어 비교를 사용하는 함정을 개선하는 방법을 살펴 보겠습니다. 이는 # 43956에서 추적됩니다. 또한이 문제의 영향을받은 것으로 확인 된 일부 라이브러리에 연락 할 것입니다. 앞으로 다가오는 5.0 릴리스와 함께 사람들이 문제가있는 코드를 더 잘 식별하고이 문제를 방지하기 위해 수정하는 데 도움이 될 더 많은 문서를 공유 할 것입니다.
이것은 매우 어려운 결정이었고, 플랫폼 간 표준화를위한 드라이브와 생태계에 미치는 호환성 영향을 비교해야했습니다.
현재 완화 조치가 불충분하다고 판단되는 경우 서비스시 \r\n 문제에 대한 추가 완화를 고려하기 위해이 문제를 열어 두겠습니다.
나는 또한 사람들이 ICU 스위치의 결과로 발생하는 문제를 계속보고하도록 장려하고 싶습니다. 비록 그 동작이 알려진 원인 일 수 있지만 그것이 "설계에 의한"것은 아닙니다. 우리는 계속해서 차이점을 조사하고 근본 원인을 이해하고이를 해결하기 위해 ICU 또는 .NET으로 변경 사항을 적용해야하는지 결정할 것입니다.

내가 제어 할 수없는 .NET Standard 종속성을 계속 사용할 수 있는지 알고 싶습니다.

나는 할 수 없을 것이라고 생각한다. 사람들이 .NET Standard 2.2로 전환하도록하는 것은 어떻습니까? API를 변경 하시겠습니까?

예상되는 동작을 얻는다는 사실을 알 수 있습니다.

이미 공정한 몫을 차지하고있는 현재 생태계의 파괴를 어떻게 피할 수 있는지 잘 모르겠습니다.

나는 틀렸다는 것이 증명되어 기쁠 것입니다. 편견을 가지고 그렇게 해주세요-그것은 내 마음을 편안하게 할 것입니다 :)

rcollina 에 2020년 10월 31일

뿡뿡

내가 제어 할 수없는 .NET Standard 종속성을 계속 사용할 수 있는지 알고 싶습니다.

.Net Standard 라이브러리는 일반적으로 크로스 플랫폼으로 간주됩니다. 일부 라이브러리가 현재 Unix의 .Net Core 3 (ICU 사용)에서 올바르게 작동한다면 Windows (ICU도 사용하는)의 .Net 5에서도 거의 확실하게 작동합니다.

.NET 표준 2.2

.Net Standard vNext는 ".Net 5.0"이라고하지만 효과적으로 존재합니다. (즉, 라이브러리를 작성 중이고 이전 프레임 워크를 지원하는 데 신경 쓰지 않는 경우, 오늘은 .Net Standard 2.1을 대상으로합니다. 한 달 안에 .Net 5.0을 대상으로합니다.)

svick 에 2020년 10월 31일

@svick 알겠습니다 . .NET Standard의 작동 방식을 이미 이해하고 있다고 생각합니다. 나는 .NET 5가 새로운 .NET 표준이라는 것을 이해합니다.

죄송하지만 IndexOf와 Contains 사이의 기존 동작 불일치에 의존하는 .NET Standard 2.1 라이브러리를 참조하면 어떻게되는지 잘 모르겠습니다.

여기서 변화하는 것은 대역 외, ICU 대 NLS입니다. 이 변화는 우리가 이미 가지고 있던 불일치를 넓히고 기대치를 깨뜨립니다.
이 정보를 libs로 인코딩하는 것은 없습니다.

모든 의미를 이해한다고 생각하지는 않지만 새로운 노멀에 대한 원활한 온 보딩 경로 없이는 "기술적으로 정확"하다는 느낌을 떨쳐 낼 수 없습니다. 절실히 필요합니다.

다른 누군가가 언급했듯이, 대부분의 사람들은 최고의 커뮤니티 구성원이 무작위로 발견 한 것과 같은 지진 변화는 말할 것도없고 새로운 언어 기능도 인식하지 못합니다. 우리가 이것을 견딜 수있는 기회는 무엇입니까?

rcollina 에 2020년 10월 31일

👍2 👀1

내가 제어 할 수없는 .NET Standard 종속성을 계속 사용할 수 있는지 알고 싶습니다.

여기서 변화하는 것은 대역 외, ICU 대 NLS입니다. 이 변화는 우리가 이미 가지고 있던 불일치를 넓히고 기대치를 깨뜨립니다.

아니요, 그렇지 않습니다. ICU가 유닉스에서 _ 항상 _ 사용되어 왔다는 것은 여기서 충분히 강조 할 수 없습니다. .NET Standard 라이브러리는 설계 상 이식 가능해야하며 이전에 Linux .NET Core 3.x에서 작동했던 모든 것이 .NET 5에서 작동합니다.

우리가하는 대부분의 작업은 InvariantCulture입니다. 제가 이전에 이해 한 바에 따르면 설계 상 변경이 불가능합니다.

사실이 아니다. InvariantCulture는 사용자의 언어 설정 만 무시하도록되어 있습니다. 유니 코드 사양이나 세계화 라이브러리 등에 대한 업데이트로 여전히 변경 될 수 있습니다.

.NET 팀은 이로 인해 발생할 수있는 고통과 문제점 및 비용을 고려 했습니까?

이와 같은 발언은 끝이 없습니다. 이 변경으로 갑자기 중단되는 코드는 처음부터 잘못되었습니다. .NET 팀이 올바르지 않거나 구현 세부 사항에 의존하는 사용자 코드의 동작을 유지해야하는 경우 플랫폼은 어떻게 발전해야합니까? 호환성 스위치를 제공하지 않은 것과는 다릅니다. .NET Core가 .NET Framework에서 분리 된 이유의 큰 부분은 side-by-side 설치 및 앱-로컬 런타임 배포와 같은 기능을 통해이 문제를 해결하기 위해서였습니다. 이 때문에 .NET 5로 이동할 수 없다면 .NET 5로 이동하지 마십시오.

.NET 5가 알려지지 않은 알려지지 않은 새로운 작물을 도입하고 내 라이브러리뿐만 아니라 다운 스트림 종속성에 대한 수정 사항을 다시 검토 할 것이라는 전망에 흥분하지 않습니다.

주장하는대로 플랫폼 차이 버그를 모두 제거했다면 걱정할 필요가 없습니다.

Naine 에 2020년 11월 02일

👍4

.NET 팀은 이로 인해 발생할 수있는 고통과 문제점 및 비용을 고려 했습니까?
이와 같은 발언은 끝이 없습니다.

수백만 개의 프로젝트가 .NET에서 실행되고 있으며 문자열 조작은 매우 빈번한 작업입니다.
.NET 팀이이 문제를 수정 / 변경하는 데 드는 노력은 .NET 5/6으로 마이그레이션 될 모든 기존 코드를 확인하는 데 필요한 노력에 비해 아주 적습니다.

따라서이 문제를 해결하기위한 "계획"에 대해 물어 보는 것은 상당히 공정합니다.
계획이 있습니까?
이 변경의 효과가 예상 되었습니까?
모든 프로젝트의 0.001 %입니까? 75 %입니까?
우리가 알지 못하는 다른 유사한 변화는 무엇입니까?

이것은 소수의 프로젝트에만 영향을 미칠 수 있습니다.
그러나 추정 되었습니까?

BTW, 나는 충분한 이유를 고려할 때 변경 사항을 깨는 것입니다. 그러나 너무 위험하지 않은 마이그레이션 경로도 필요합니다.

petarrepac 에 2020년 11월 05일

@petarrepac 오해 하지 마십시오. 그러나이 스레드에서 여러 번 지적했듯이 :

계획이 있으며 런타임 구성 스위치를 제공하는 것입니다.
중단되었다고 주장하는 동작은 모든 비 Windows 플랫폼에서 .NET의 기존 동작입니다.
이는 서 수가 의도 된 문화권에 민감한 작업을 수행하는 코드에만 영향을 미칩니다.

마지막 두 가지 점을 감안할 때 이것이 상당히 적은 비율의 프로젝트에 영향을 미친다고 가정하는 것이 합리적 일 것입니다.

100 % 이것에 대해 물어 보는 것은 공평하지만, 제가 인용 한 것과 같은 댓글을 작성하는 사람들은 종종 변화의 더 큰 그림을 이해하려고 시도하기 전에 고려하지 않고 작성했다고 가정합니다.

Naine 에 2020년 11월 05일

👍2

모두들 안녕. 이 문제가 공개되었을 때 취한 조치와 마지막에 Windows 10 2019 년 5 월 업데이트 이상에서 기본값을 .NET 5.0 용 ICU로 유지하기로 결정한 이유에 대한 간략한 요약을 제공하고자합니다.

문제가 시작되었을 때 우리는 Ordinal 와 IndexOf(string) 사이의 불일치를 감안할 때 고객에게 미칠 수있는 잠재적 인 영향과 고통에 대한 내부 토론을 시작했습니다 Contains(string) IndexOf(string) 문화 인식하고, 플러스 문자열을 통해 작동 할 때 다른 API는 기본적으로 문화 인식하고 가지고 있지만, 인 Ordinal 통해 작동 할 때 Span<char> 또는 ReadOnlySpan<char> . 따라서이 문제에 대해 논의한 후 영향을받을 수있는 NuGet 패키지에 대한 분석을 시작하고 명확한 그림을 얻기 위해 데이터를 수집했습니다. 이것이 우리의 결과입니다.

"\ n"은 IndexOf, LastIndexOf, EndsWith, StartsWith, Compare 및 CompareTo에 전달 된 "가장 많이 사용되는 문자열 리터럴"에서 # 30입니다.
String.EndsWith에 대한 호출 사이트의 1 %는 \ n으로 시작하는 검색 문자열을 사용합니다. 테스트중인 문자열에 "윈도우 스타일 라인 엔딩"이 포함 된 콜 사이트는 모두 손상됩니다.
버전에 위험 호출 사이트가있는 어셈블리가 포함 된 NuGet.org에서 호스팅되는 2040 패키지 ID가 있습니다.
이러한 콜 사이트의 대부분은 EndsWith 및 IndexOf에 대한 것이며, 이는이 패턴이 순진한 줄 바꿈 알고리즘에 자주 사용된다는 가설과 일치합니다.

위험에 처한 호출 사이트가있는 이러한 2040 패키지 중 539 개만 .NET Standard 또는 .NET Core의 일부 버전을 지원하므로 NuGet.org에 나열된 0.54 % 패키지 만 중단에 노출 될 가능성이 있습니다.

잠재적으로 영향을받을 수있는 539 개의 패키지 ID 목록에서 패키지를 살펴보고 실제 영향에 대한 아이디어를 얻었습니다. 우리는 상위 70 개 (다운로드 수 기준)를 살펴 보았고, 20 개는 최신 버전에서 패턴을 노출하지 않았으며, 패턴을 노출 한 패턴은 허용 라이선스가있는 32 개만 볼 수있었습니다.

14는 버그의 대상이 아닙니다.
13 개가 잠재적으로 손상됨
5 개는 불확실했습니다 (다양한 줄 바꿈 패턴이나 기타 완화에 대한 방어 적 코딩으로 인해 끊김이 명확하게 표시되지 않았습니다).

즉, 다운로드 기준 상위 70 개 패키지 중 18 %만이 잠재적으로 영향을 받았습니다.

이러한 백분율은 누적되며 NuGet.org의 총 패키지 수인 229,536 개와 비교되지 않습니다. 따라서 NuGet.org에서 총 패키지 수와 총 다운로드 수를 사용하면 0.24 % 인 229,536 개 중 잠재적으로 영향을받는 539 개의 패키지를 볼 수 있습니다.

라이브러리를 분석하는 것은 좋지만 nuget은 C # 코드의 극히 일부에 불과합니다. 그리고 누군가가 코드를 소유하고 있더라도 a) 버그를 추적하기가 쉽지 않을 수 있으며 b) 더 이상 소스를 가지고 있지 않을 수 있습니다.

그러나 이것은 동작에있어 매우 주목할만한 변화 일 수 있지만 Windows Line Endings (흔하지 않을 수도 있음)를 포함 할 수있는 입력을 읽을 때 이미 Unix에서 발생한 중단이라는 결론을 내릴 수있는 좋은 데이터 소스였습니다.

.NET Core 및 .NET 5+에서 우리는 OS 간의 일관성을 위해 노력하고 있으며이 변경의 영향을 고려할 때 올바른 작업처럼 느껴졌습니다. 우리는 호환성에 관심이 있으므로 사람들이 레거시 동작으로 돌아갈 수 있도록 호환되는 런타임 스위치를 제공하고 있습니다.

또한 우리가 검사 할 수있는 패키지의 결론은 이미 Unix에서 동작이 다르기 때문에이 문제에 대한 방어적인 프로그래밍을 많이 확인하여 OS 간 잠재적 인 중단을 완화했습니다.

여기에 덧붙여서, 세계화는 우리가 OS 전반에 걸쳐 얇은 래퍼이기 때문에 언제든지 변경 될 수 있으므로 현재 우리가 지원하는 모든 OS에서 동일한 래퍼가되는 것이 옳은 것처럼 느껴졌습니다.

그 일환으로 실제 예제, roslyn 분석기 규칙 및 영향을받는 코드가이를 완화 할 수있는 방법으로 문서를 개선했습니다.

항상 우리를 더 나은 곳으로 데려가는 귀중한 피드백에 감사 드리며, https://github.com/dotnet/runtime/issues/43956에서 논의 된대로 .NET 6에 대한이 경험을 계속 개선하기 위해 노력할 것입니다.

Unix와 Windows에서 줄 끝의 차이로 인해 발생할 수있는 고통을 이해하고 있으므로이 문제를 계속 공개하고 .NET 5.0의 \r\n 사례를 완화 할 수있는 가능한 방법을 조사 할 것입니다. .x는 서비스 릴리스의 일부 여야합니다.

safern 에 2020년 11월 09일

👍13 ❤7

char 및 string에도 차이가 있습니다.

Console.WriteLine("com/test/test/test/a/b/ʹ$ʹ".IndexOf("$"));
Console.WriteLine("com/test/test/test/a/b/ʹ$ʹ".IndexOf('$'));

mattleibow 에 2020년 11월 20일

@mattleibow 문자 검색을 사용하면 서수 검색을 수행합니다. This method performs an ordinal (culture-insensitive) search 나타내는 https://docs.microsoft.com/en-us/dotnet/api/system.string.indexof?view=net-5.0#System_String_IndexOf_System_Char_ 문서. 서수 옵션으로 문자열 검색을 수행하면 문자와 동일한 결과를 얻을 수 있습니다.

C# Console.WriteLine("com/test/test/test/a/b/ʹ$ʹ".IndexOf("$", StringComparison.Ordinal));

tarekgh 에 2020년 11월 20일

👍1

~이 보인다 CA1307은 단지 트리거 indexof(char) 있지만 indexof(string) . string 버전에 대한 규칙이 있습니까? char 의 기본값이 자동으로 서수를 사용하고 주요 변경 사항이 실제로 이에 영향을주지 않는 반면 string 이 변경되었으며 동작을 복원하려면 서수를 지정해야하기 때문에 더 중요해 보입니다. 몇몇 경우. ~

~ indexof(string) 는 어떻게 감지합니까? ~

찾았습니다. 규칙 CA1310입니다. https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu#use -nls-instead-of-icu에 대한 문서는 잘못되었으며이 특정 변형을 언급하지 마십시오. 해당 문서를 업데이트하겠습니다.

adegeo 에 2020년 12월 07일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Runtime: .NET Core 3.0-&gt; .NET 5.0에서 string.IndexOf (string)로 주요 변경 사항

기술

구성

회귀?

가장 유용한 댓글

모든 76 댓글

관련 문제

Runtime: .NET Core 3.0-> .NET 5.0에서 string.IndexOf (string)로 주요 변경 사항