Runtime: System.Rune 소개

메모리 내 표현이 32비트 개체의 문자열이거나 즉석에서 번역될 것으로 예상하십니까? 전자라면 메모리가 두 배로 늘어나는 것은 어떻습니까? 후자의 경우 성능에 어떤 영향을 미칩니까?

특정 유니코드 지원 스크립트를 따라 유니코드 관련 기술을 명명하는 것이 좋은 생각입니까?

내 생각에 제안(그리고 아마도 더 명시적이어야 할 필요가 있음)은 문자열의 메모리 내 표현이 전혀 변경되지 않는다는 것입니다. Rune 유형은 고유한 개별 21비트 코드 포인트(32비트 int로 저장됨)를 나타냅니다. 코드 포인트를 참조하는 메서드 는 잠재적으로 Rune 를 대신 반환할 수 있습니다. string 에는 Rune 를 열거할 수 있는 기능이 있을 것입니다.

나는 다음과 같은 것에 대해 합의를 얻어야 할 몇 가지 분명한 점이 있다고 생각합니다.

1. 현재 메서드처럼 Int32 를 사용하는 것보다 Rune 유형을 만드는 데 중요한 가치가 있습니까?
2. "룬"이라는 단어가 실제로 좋은 선택입니까?

(1)에 답하려면 $#$ Int32 Rune 이 어떻게 노출되는지, 어떤 메서드가 이를 수신하고 반환하는지 등에 대한 자세한 설명이 필요하다고 생각합니다. 대신 Int32 .

(2)에 관해서는 나 자신이 조금 망설여진다. "룬"은 영어로 된 일종의 난해한 단어이며 이 문맥에서 사용하는 데 있어 몇 가지 특이한 의미가 있습니다. 다른 사람들이 제기하는 요점도 있습니다. 다른 유니코드 개념과 충돌합니다. "Unicode Rune"을 검색할 때 주로 Runic Unicode 블록에 대한 결과를 얻고 Go 언어 문서의 일부만 얻습니다.

char 는 절반 단어이자 전체 단어입니다. 그리고 현재와 같이 반 글자 또는 전체 글자를 나타내는 것을 결정하기 위해 주변을 조사해야 합니다.

아마도 System.character 여기에서 항상 전체 문자가... :선글라스:

char 는 약간 끔찍한 표현이며 ASCII/라틴어 전용 언어에서도 마찬가지입니다. 이모티콘의 부상은 여전히 ​​​​침투할 것입니다. char 가 수표이고 다음 char 유형을 확인할 수 있음을 의미합니다.

트위터의 @NickCraver

utf8은 가변 너비 인코딩입니다. 사용자가 절반 문자를 처리하기를 원하는 경우는 거의 없습니다. utf8과 utf32 모두.

32비트 유형은 열거에 적합합니다.

성능이나 메모리 관점에서 indexOf, Length 등이 더 어렵습니다.

1. 바이트 배열은 불투명 형식에 가장 적합한 표현입니다. 예: 형식을 원래 형식 또는 최종 형식으로 유지(파일 전송, 유선 연결 등)
2. 바이트 배열은 메모리 대역폭과 메모리 크기를 가장 잘 나타냅니다.
3. 바이트 배열은 바이트 측면에서 Position 및 indexOf, Length 등과 일치합니다.

그러나 실제 문자에 대해 관심을 갖기 시작하면 대문자, 문자 분할, 문자가 무엇인지 이해하면 바이트가 가변 너비가 됩니다. Char는 그것을 더 좋게 만들지 않습니다. 가장 작은 문자의 크기를 두 배로 늘립니다. 더 많은 문자를 포함하지만 여전히 가변 너비입니다.

이를 위해 32비트 값은 사용자 코드 관점에서 매우 유용할 수 있습니다. 그러나 위치, 길이 및 보조 항목(indexOf 등)에 문제가 있습니다.

저는 ASCII 전용 문자열과 utf8 문자열 "Compact String implementation" https://github.com/dotnet/coreclr/issues/7083; ASCII 전용 문자열의 빠른 처리를 위해

그러나 내가 거기에서 주장했던 모든 것에 반대하는 것은... utf8의 32비트 표현이 어떤 것인지 궁금합니다. 위치는 위치에 매핑됩니다. 문자를 찾는 것은 ASCII에서와 같이 빠르며 항목은 기본 크기 등입니다. 크기를 결정하기 위해 모든 바이트 또는 문자를 처리하는 것에 대해 어떻게 누적됩니까?

로의 변환은 더 비쌉니다. 그래서 더 많은 처리 형식이 될 것입니다. 저장 형식보다

@migueldeicaza 내가 이해하는 것처럼 모든 표현이 값에 포함되도록 단일 문자 형식을 16비트 문자에서 32비트로 확장하는 것에 대해서만 언급하고 있습니다. 반값의 가능성이 아니라 반드시 내부 형식이 필요합니다.

그러나 고려해야 할 사항(예: 위치의 관계, 검색 비용 등)

제쳐두고: Swift는 전체 문자 형식 도 처리합니다.

Swift는 문자열의 유니코드 표현에 접근하는 여러 가지 방법을 제공합니다. for-in 문으로 문자열을 반복하여 유니코드 확장 자소 클러스터로 개별 문자 값에 액세스할 수 있습니다. 이 프로세스는 캐릭터 작업에 설명되어 있습니다.

또는 다른 세 가지 유니코드 호환 표현 중 하나로 String 값에 액세스합니다.

• UTF-8 코드 단위 모음(문자열의 utf8 속성으로 액세스)
• UTF-16 코드 단위 모음(문자열의 utf16 속성으로 액세스)
• 문자열의 UTF-32 인코딩 형식에 해당하는 21비트 유니코드 스칼라 값 모음(문자열의 unicodeScalars 속성으로 액세스)

나는 원래 문제에서 그것을 말했고 다시 말할 것입니다. 이 문구가 마음에 들지 않기 때문에 표준이 말하는 것을 포기하는 것은 해결되는 것보다 더 혼란스러울 것이며, 유니코드에 룬 코드 페이지가 있다는 점을 감안할 때 더 혼란스러울 뿐입니다.

이름이 잘못되었습니다.

@멜리노에

Rune은 ToLower[Invariant], ToUpper[Invariant], ToTitle, IsDigit, IsAlpha, IsGraphic, IsSymbol, IsControl과 같이 오늘날 Char에서 기대할 수 있는 많은 작업을 제공합니다.

또한 다음과 같은 기능을 제공합니다.

• EncodeRune (룬을 바이트 버퍼로 인코딩)
• RuneUtf8Len (룬을 UTF8로 인코딩하는 데 필요한 바이트 수를 반환),
• IsValid (일부 Int32 값이 유효하지 않음)

그리고 문자열에 대한 interop과 필요에 따라 Utf8string.

Go 문자열 지원을 .NET으로 이식/조정했으며 이 세상이 어떻게 생겼는지에 대한 보기를 제공합니다(런타임 도움말 없이).

https://github.com/migueldeicaza/NStack/tree/master/NStack/unicode

@benaadams 는 다음과 같이 말했습니다.

utf8의 32비트 표현이 어떤 것인지 궁금합니다. 위치는 위치에 매핑됩니다. 문자를 찾는 것은 ASCII에서와 같이 빠르며 항목은 기본 크기 등입니다. 크기를 결정하기 위해 모든 바이트 또는 문자를 처리하는 것에 대해 어떻게 누적됩니까?

UTF8은 메모리 내 표현으로 계속 존재하고 계속 표현이 될 것입니다.

기존 UTF16 문자열(System.String) 또는 다가오는 UTF8 문자열(Utf8String)을 Chars(당신과 내가 모두 동의하는 이유)가 아니라 Runes로 디코딩할 것입니다.

몇 가지 예는 Utf8 문자열을 룬 문자로 변환합니다.

https://github.com/migueldeicaza/NStack/blob/6a071ca5c026ca71c10ead4f7232e2fa0673baf9/NStack/strings/ustring.cs#L756

utf8 문자열에 룬이 포함되어 있습니까?

https://github.com/migueldeicaza/NStack/blob/6a071ca5c026ca71c10ead4f7232e2fa0673baf9/NStack/strings/ustring.cs#L855

방금 인덱서를 구현하지 않았음을 알아차렸습니다("n번째 룬 가져오기").

문자열에서 N번째 룬에 대한 액세스 속도는 룬 자체가 아니라 저장소의 함수입니다. 예를 들어 저장소가 UTF32인 경우 모든 룬에 직접 액세스할 수 있습니다. 아무도 그것을 사용하지 않기 때문에 이것은 학문적입니다. UTF16 및 UTF8의 N번째 요소에 액세스하려면 문자열을 구성하는 요소(바이트 또는 16비트 정수)를 올바르게 스캔하여 올바른 경계를 결정해야 합니다. 정확성에 관계없이 n번째 문자만 반환하는 String[int n] { get; } 와 혼동하지 마십시오.

@benaadams 스위프트 캐릭터는 룬보다 한 단계 높은 레벨입니다. swift의 문자는 하나 이상의 룬으로 구성된 "확장된 자소 클러스터"이며, 결합될 때 사람이 읽을 수 있는 문자를 생성합니다.

따라서 Swift 캐릭터는 고정된 32비트 크기가 아니라 가변 길이입니다(그리고 우리도 그 구조를 가져야 하지만 다른 데이터 유형에 속합니다). 다음은 해당 페이지의 예이지만 이모티콘의 색조 설정까지 확장됩니다.

여기 예가 있습니다. 문자 é는 단일 유니코드 스칼라 é(LATIN SMALL LETTER E WITH ACUTE 또는 U+00E9)로 나타낼 수 있습니다. 그러나 동일한 문자는 표준 문자 e(LATIN SMALL LETTER E 또는 U+0065) 다음에 COMBINING ACUTE ACCENT 스칼라(U+0301)가 오는 한 쌍의 스칼라로도 나타낼 수 있습니다. COMBINING ACUTE ACCENT 스칼라는 그 앞에 오는 스칼라에 그래픽으로 적용되어 유니코드 인식 텍스트 렌더링 시스템에서 렌더링될 때 e를 é로 바꿉니다.

저에게 grapheme 단어는 더 자기 설명적일 것입니다.

이름에 두 센트, 강조하여 문자열에 대한 Go 게시물을 다시 인용합니다.

" Code point "는 입이 떡벌어지기 때문에 Go에서는 개념에 대해 더 짧은 용어인 룬을 소개합니다. 이 용어는 라이브러리와 소스 코드에 나타나며 "코드 포인트"와 정확히 같은 의미 이며 흥미로운 추가 사항이 있습니다.

나는 @blowdart 에 100% 동의합니다. 룬이라고 부르는 것은 혼란스럽고 잘못된 것입니다. 유니코드 표준 은 도입 장의 첫 페이지 에만 코드 포인트를 세 번 언급하지만 룬 이라는 용어는 어디에도 나타나지 않습니다.

그것이 코드 포인트라면 그 이름은 code point 로 간단해야 합니다.

룬 이라는 용어가 규격에 나오지 않았다면 괜찮을 텐데 , 문제는 룬과 관련하여 8장에서 여러 번 등장한다는 점이다. 단순히 잘못된 것이 아니라 문제를 다른 사람과 적극적으로 혼동하고 있습니다.

저에게 grapheme 단어는 더 자기 설명적일 것입니다.

이것이 약 32비트 코드 포인트라면 grapheme 라는 용어는 자소가 또 다른 것이기 때문에 혼란스러울 것입니다.

나는 종종 코드 포인트 데이터 유형을 원했습니다 . 잘 테스트 된 라이브러리로 할 수 있음). 이것을 CodePoint 와 같이 부르지 말아야 하는 이유를 모르겠습니다. 그러한 유형이 필요하다는 것을 깨닫는 대부분의 사람들은 어쨌든 룬의 관점이 아니라 코드 포인트 관점에서 생각하고 있을 것입니다. 또는 코드 포인트 와 룬을 작업의 별도 부분으로 사용합니다. ᚱᚢᚾᚪ ᛒᛇᚦ ᛥᛁᛚᛖ ᛒᚱᚣᚳᛖᚢ/rúna béoþ stille bryceu/runes는 여전히 사용됩니다. 나는 1년에 한 번 정도 룬을 사용해야 하고, 일반적으로 디지털보다는 양피지와 잉크를 사용하지만 디지털 방식으로 처리하는 사람들도 분명히 있습니다. (심지어 20세기 데이터를 가지고도 WWII 시대 데이터를 보관하는 데 사용된 사례를 알고 있습니다.)

종종 옥텟 → 문자(이미 .NET에서 잘 처리됨), 문자 → 코드 포인트, 코드 포인트 → 자소로 이동하기를 원하기 때문에 Grapheme 은 여전히 ​​더 까다롭습니다.

현재로서는 이것을 가능한 것으로 표시합니다.

다음 단계 : 우리가 찾고 있는 것은 위의 피드백을 포함할 공식적인 제안입니다(유형의 실제 이름 및 Int32를 사용하는 것과 대조적으로 이를 사용하는 이점).

제안된 API와 초기 구현 모두에서 문제를 업데이트했습니다.

https://github.com/migueldeicaza/NStack/blob/master/NStack/unicode/Rune.cs

유형 이름 지정과 관련하여 유형에 대한 유효한 작업을 찾을 수 있는 위치와 유형별 기능(일부 예제는 구현 참조)을 갖는 것이 중요합니다.

@migueldeicaza 를 검토할 준비가 된 것으로 표시하기 전에 유형의 실제 이름 지정에 대한 우려에 대해 어떻게 생각하십니까? 유형을 설명하는 데 CodePoint가 더 나을 수 있다고 생각하십니까?

코드포인트를 이름으로 사용하는 것에 대한 주장이 약하다고 생각합니다.

그것을 사용하는 것은 끔찍한 생각입니다. 장기적으로 이것은 기존 코드에서 "char"의 모든 단일 사용을 대체해야 합니다. 만약 우리가 적절한 유니코드 지원을 받기를 바란다면 말입니다.

Rust처럼 "char"를 사용할 수 있었으면 좋겠지만 슬프게도 이미 사용했고 깨진 것이 있습니다.

Go가 이 이름을 받아들인 것은 좋은 선례입니다.

나는 code point 가 여기에 사용하기에 올바른 용어가 아니라는 데 동의합니다. 최소한 유니코드 표준에 따라 10FFFF(http://unicode.org/glossary/#code_point) 이상의 값은 포함하지 않습니다.

나는 rune 라는 용어를 좋아하지 않습니다. 나는 그것이 유니코드와 다른 곳에서 전반적으로 혼란을 야기할 기존 사용이 있다고 생각합니다. 또한 기존 사용자 유형과 충돌할 가능성이 꽤 높다고 생각합니다(특히 'Rune'이 특정 게임 개체를 나타낼 수 있는 Unity와 같은 경우).

그러나 C++ 11 char32_t 유형을 포함하는 유형이라는 아이디어가 마음에 듭니다. 이름만 다를 뿐입니다.

Char32 에 대해 할 말이 있습니다. 요점은 정수 형식의 형식 이름과 유사합니다. 코드 포인트 수준이 아닌 캐릭터 개념 수준에서 이야기합니다. 스크립트 이름이 아닙니다.

우리는 nint 를 가지고 있기 때문에 nchar 는 어떻습니까?

선례는 nchar 및 nvarchar 데이터베이스에 있습니다.

여기서 nchar 는 국가 문자/국가 문자이고 nvarchar 는 국가 문자 가변/국가 문자 가변입니다. 유니코드를 저장할 수 있는 필드 유형은 무엇이며 일부 ISO 표준도 있습니다. 어느 것이 SQL인지 확실하지 않습니까?

룬의 이 유니코드 사용은 무엇입니까? 그것은 나에게 새로운 소식이다.

U+16A0 ~ U+16F8

유니코드 표준의 특정 코드 페이지를 참조하는 데 사용됩니다. 이 스레드에서 몇 번 언급되었습니다. http://unicode.org/charts/PDF/U16A0.pdf

아 룬이 아니라 룬입니다.

백업 이름(System.Rune 또는 System.Char32)은 C#에 투영될 레이블만큼 중요하지 않습니다.

첫째: 예, 예, 그리고 이것에 대해 더 많이 부탁드립니다. 나는 이 아이디어를 좋아합니다. 사실 우리는 잠시 동안 Visual Studio의 Git 호환성에서 사용자 지정 문자열 클래스와 문자 구조체를 사용하고 있습니다(Git은 Utf-8로 말하고 모든 것을 트랜스코딩하는 것은 매우 느립니다).

정적 메서드 이름에 대해 임의의 짧은 이름 지정을 피할 수 있습니까? Char.IsPunctuation 가 현재 방법인 경우 Rune.IsPunctuation 또는 이와 유사한 것으로 미러링할 수 있습니까?

이것이 받아들여진다고 가정하면(항상 위험합니다), 본질적인 rune 또는 c32 또는 char 를 System.Rune 구현으로 완전히 대체할 수 있습니까?

uchar unichar 또는 uchar $를 제안합니다. 어느 쪽을 선택하든지 언어별 별칭을 얻을 수 있기를 바랍니다. 저는 개인적으로 기본 유형에 언어 별칭을 사용하는 것을 매우 좋아합니다.

또한 @whoisj 에 동의합니다 - 짧은/약어보다 전체 메서드 이름을 확실히 선호합니다.

또한 @whoisj 에 동의합니다 - 짧은/약어보다 전체 메서드 이름을 확실히 선호합니다.

IMO 언어(및 라이브러리)는 전체, 축약된 이름을 선택하거나 약어(예: strcmp, memcpy 등을 사용하는 C)를 선택해야 합니다.

아니면 char 를 System.Rune 구현으로 완전히 바꾸시겠습니까?

그것은 상당히 명백한 이유로 주요 변경 사항이 될 것입니다.

그것은 상당히 명백한 이유로 주요 변경 사항이 될 것입니다.

내 의견은 대부분 혀와 볼이었고 희망적이었습니다. 16비트 문자 유형은 처음부터 실수였습니다.

이름 지정을 잘하면 수정됩니다.

제공된 API에 다른 작은 불일치가 있습니다. 이를 수정하는 방법도 살펴보겠습니다.

@migueldeicaza

아 룬이 아니라 룬입니다.

룬 문자 는 형용사, 룬 명사입니다. 룬 문자는 모두 룬 문자입니다.

_Runic_은 형용사, _rune_는 명사입니다. 룬 문자는 모두 룬 문자입니다.

"Cortana: define _'rune'_"이 다음과 같이 표시되는 것처럼 공정합니다.

로마 알파벳과 관련된 고대 게르만 알파벳의 문자.

아 예, "룬"이라는 단어를 볼 때마다 "The Runic Unicode Block"에 대해 이야기하는 아무도 읽지 않은 사양의 이 모호한 장이 즉시 생각납니다.

😆 어릴 적 톨킨을 읽었던 기억이 떠오른다.

ᛁ᛫ᚦᛁᛜᚲ᛫ᛟᚠ᛫ᚱᚢᚾᛖᛋ

네, 구체적으로 사양은 생각하지 않지만 사양이 참조하는 문자 유형은 생각합니다.

rune 라고 하면 마법, 판타지, 수수께끼 같은 퍼즐, 고대 언어 등을 생각합니다.

"룬"이라는 단어가 보이지 않고 즉시 "아 이것은 분명히 16A0..16F8 범위의 고유한 값으로 값이 제한되는 유니코드 7.0 룬 블록을 나타냅니다"라고 생각하게 되어 기쁩니다.

여기에서 Tanner가 한 목소리라는 것을 알고 있고 여러분 중 일부는 여전히 "하지만 Miguel, 나는 'rune'이라는 단어를 보고 즉시 88개의 가능한 값만 가질 수 있는 데이터 유형이 떠올랐습니다"라고 생각하고 있다는 것을 압니다. 이것이 당신이 고군분투하는 문제라면, 내 형제/자매, 당신을 위한 소식이 있습니다. 당신은 더 큰 물고기를 튀길 수 있습니다.

나는 한 달이 조금 넘는 기간 동안 흥분과 망설임이 뒤섞여 잠시 동안 이 스레드를 따라왔습니다. 지난 달에 국제화 및 유니코드 회의에 참석했는데 .NET을 다룬 프레젠테이션은 없었습니다. .NET Framework에 인식 문제가 있습니다. 세계화 기능의 역사를 고려할 때 반드시 벌지 않은 것은 아닙니다. 그렇긴 하지만 저는 C# 프로그래밍을 좋아하고 진정한 글로벌 커뮤니티에서 .NET의 위치를 ​​강화하는 새로운 기능을 절대적으로 보고 싶습니다. 저는 이 제안이 국제화 커뮤니티가 소프트웨어에 대해 기대하는 표준을 수용하는 방향으로 가는 좋은 단계라고 생각합니다.

내 주저는 대부분 유형 이름에 대해 말다툼을 하는 것이었습니다. Go의 설계자들이 "rune"이라는 이름을 선택한 것은 사실이지만 위에 반복적으로 나열된 이유로 문제가 됩니다. 제대로 룬이라고 불리는 코드 포인트가 있습니다. 존경받는 표준에 가깝게 깎고 사양의 일부인 용어를 재정의하려는 제안에 동의하기 어렵습니다. 게다가, 대부분의 개발자가 이 용어를 모른다는 주장은 이 유형을 올바르게 사용하는 데 가장 관심이 있는 개발자가 유니코드 사양을 이해하고 "룬"이 실제로 무엇인지 잘 알고 있다는 점을 감안할 때 거짓입니다. 용어를 혼합하면 존재할 수 있는 이상함을 상상해 보십시오.

Rune.IsRune(new Rune('ᛁ')); // evaluates to true
Rune.IsRune(new Rune('I')); // evaluates to false

물론, 나는 새로운 이름을 제공하지 않고 비판하는 쉬운 길을 택했습니다. CodePoint 의 이전 제안이 가장 자명한 옵션이라고 생각하지만(원래 문제 설명에 나타남) char32 는 기존 기본 유형과 더 많은 패리티를 가집니다. 모든 코드 포인트가 문자가 아니라는 것을 주저하지 마십시오.) 목표가 .NET에 더 나은 유니코드 지원을 구축하는 것이라면 저는 그 경로를 절대적으로 지지하지만 그렇게 하는 가장 좋은 방법은 사양을 따르는 것입니다.

세 가지 제안:

1. Rune 클래스에 중요한 "IsCombining"이 누락되었습니다. 그것 없이는 일련의 룬(코드 포인트)을 일련의 자소로 변환할 수 없습니다.

1. 해당 Graphme 클래스도 갖고 싶습니다. 이 컨텍스트에서 자소는 실제로 첫 번째 룬이 결합되지 않고 나머지 룬이 결합되는 하나 이상의 룬(코드 포인트) 목록입니다. 사용 사례는 개발자가 "보이는 문자" 덩어리를 처리해야 하는 경우입니다. 예를 들어 + GRAVE는 하나의 자소를 형성하는 두 개의 룬입니다.

2. 네트워킹에서 우리는 종종 바이트가 완전하지 않을 수 있는 객체와 같은 "문자열"로 변환해야 하는 바이트 덩어리를 얻습니다(예: 일부 바이트에 대해 들었지만 다중 바이트 시퀀스의 마지막 바이트는 ' t 꽤 도착했습니다). 다중 바이트 시퀀스의 마지막 바이트가 누락된 것이 다음 바이트 세트를 가져올 때 수정될 정상적인 상황으로 간주되도록 바이트 스트림을 룬 스트림으로 변환하는 확실한 방법은 보이지 않습니다.

마지막으로 유니코드 이름을 사용하고 이것을 CodePoint라고 부르십시오. 예, 유니코드 컨소시엄은 차이점을 설명하는 데 끔찍한 일을 합니다. 그러나 해결책은 명확하고 사용 가능한 문서를 추가하는 것입니다. 다른 것은 명확히 하는 데 도움이 되는 대신 문제를 혼란스럽게 합니다.

나는 결합 요청에서 어디서 시작해야 하는지, Go, Rust 또는 Swift 모두 rune, Character 또는 Unicode Scalar( System.Rune 에 대한 이름)에 이러한 API를 표시하지 않습니다. 제안된 구현을 제공하십시오.

자소 클러스터에서는 System.Rune 와 독립적으로 추적하는 것이 좋습니다. 그 가치를 위해 Swift는 이를 위해 Character 를 사용하지만, 또한 Swift는 문자열을 처리하는 훌륭한 모델이 아닙니다.

바이트 스트림을 적절한 룬으로 바꾸는 것은 상위 API에 속하는 문제입니다. 즉, ustring 구현과 동일한 기판을 사용하는 System.Rune 구현을 보고 이러한 버퍼가 utf8 문자열에 매핑되는 방식을 확인할 수 있습니다.

https://github.com/migueldeicaza/NStack/blob/master/NStack/strings/ustring.cs

API에 System.Rune 를 도입한 이후로 아직 업데이트하지 않았지만 다음과 같은 문서를 다룹니다.

https://migueldeicaza.github.io/NStack/api/NStack/NStack.ustring.html

명명에 관해서는 분명히 Rust가 char 에서 가장 좋은 것입니다. 그러나 우리는 그것을 망쳤습니다. 두 번째로 좋은 방법은 rune 로 이동하는 것입니다. 4자보다 크면 사람들이 옳은 일을 하는 데 방해가 될 것입니다.

죄송 해요; CodePoint 는 정말 좋은 이름이라고 생각합니다. 자명하고 기억에 남으며 c p 로 자동 완성됩니다.

IsCombining 는 확실히 필요하지만 결합 클래스를 아는 것도 마찬가지이며 IsCombining 는 IsCombining => CombiningClass != 0 또는 IsCombining => CombiningClass != CombiningClass.None $이므로 대부분 설탕입니다. 자소 클러스터는 실제로 다시 외부에 있지만 출발점은 기본 클러스터링, 재정렬 등을 위한 결합 클래스를 아는 것입니다.

CodePoint 는 코드 포인트에 대한 유형에 대한 훌륭한 이름이며 4개의 문자는 많이 사용되는 다른 유형을 처리해야 하는 제한이 아닙니다. string 는 50% 더 크며 정기적으로 사용하는 데 방해가 되지 않습니다. 무작위로 뽑은 네 글자가 바둑의 실수를 반복하는 것보다 더 나은 이름일 것이다.

https://www.random.org/strings/?num=10&len=4&loweralpha=on&unique=on&format=html&rnd=new

uint 는 CLS 규격이 아니므로 아스트랄계를 덮는 CLS 규격 ctor가 없습니다. int 도 필요합니다.

양방향 암시적 변환은 과부하로 인해 나쁜 일이 발생할 수 있으므로 한 방향은 아마도 명시적이어야 합니다. 어느 것이 확실하지 않습니다. 한편으로 uint / int 는 0보다 작거나 10FFFF ₁₆ 보다 큰 값은 의미가 없으므로 코드 포인트보다 더 넓습니다. 숫자. 다른 한편으로 나는 그 반대보다 더 자주 숫자에서 코드 포인트로 캐스트하기를 원한다는 것을 알 수 있습니다.

uint는 CLS 규격이 아니므로 아스트랄 평면을 덮는 CLS 규격 ctor가 없습니다. int도 필요할 것입니다.

새로운 고유 유형이 공용 언어에 도입되지 않은 경우입니다.

JonHanna -- 이 세 가지 생성자를 의미합니까?
공개 정적 암시적 연산자 uint(룬 룬);
공개 정적 암시적 연산자 Rune(char ch);
공개 정적 암시적 연산자 Rune(단위 값);

"uint" 대신 "int"여야 합니다. AFAICT, int는 전체 아스트랄(비 BMP) 평면 세트를 쉽게 다룹니다.

@PeterSmithRedmond 내 말은 두 개의 생성자뿐만 아니라 char 를 취하는 생성자와 uint 를 취하는 생성자가 있어야 하고, int 를 취하는 생성자가 있어야 하지만, 물론 int 도 있어야 합니다. implicit 는 무엇이고 explicit 는 또 다른 질문입니다). uint 를 사용할 수 있는 언어에 대해서도 아무런 해가 없습니다. 그것은 결국 아주 자연스러운 경기입니다.

이것이 System.Char를 대체해야 하는 경우 "산술"을 수행할 수 있어야 하며(즉, +, -, *, /에서 ==, !=, >, < 확실하지 않음) 더 중요하게는 이것의 리터럴을 지원해야 합니다. 예를 들어 다음과 같이 쓸 수 있어야 합니다.

rune r = '𐍈'; // Ostrogothic character chose on purpose as in UTF16 will be a "surrogate pairs"

rune 가 아니면 작동할 수 있는 character 의 다른 동의어만 letter 입니까?

명사

1. 사람이나 조직을 대상으로 하는 서면 또는 인쇄된 통신으로 일반적으로 우편으로 전송됩니다.
2. 말소리를 나타내기 위해 일반적으로 쓰기 및 인쇄에 사용되며 알파벳의 일부인 기호 또는 문자.
3. 그러한 기호나 문자가 포함된 인쇄 유형의 조각.

그것이 문자 대 숫자와 충돌하지만

Letter는 룬보다 유니코드(일반적으로 Net)에서 훨씬 더 정확한 의미를 가지고 있습니다.

제 생각에는 이것을 유니코드 문자 유형으로 만들려면 유니코드의 명명 규칙을 따라야 합니다. 이는 _"코드 포인트"_를 의미합니다.

코드 포인트 . (1) 유니코드 코드스페이스의 모든 값 즉, 0에서 10FFFF16 사이의 정수 범위입니다. ( 섹션 3.4, 문자 및 인코딩의 정의 D10 참조) 모든 코드 포인트가 인코딩된 문자에 할당되는 것은 아닙니다. 코드 포인트 유형 을 참조하십시오. (2) 코드화된 문자 집합에서 문자의 값 또는 위치.

아니면 그냥 포기하고 오리를 "오리"라고 부르고 유니코드 문자( uchar 라고도 함)라고 부릅니다.

대신 System.CodePoint 를 사용하도록 이 문제를 해결하지 않으시겠습니까?
Imho 그것은 유니 코드의 용어 측면에서 더 적절하며 Java 세계의 다른 사람들이 사용하고 있습니다. 따라서 용어를 따로 사용하는 대신 유니코드 용어를 따르도록 합시다. .NET의 문자열이 char 컬렉션이고 이 char 컬렉션이 유니코드 기반이라는 사실을 알고 있기 때문에 .NET의 일반 문자 및 문자열 구현 측면에서 더 합리적이고 보편적입니다.

저는 Java와 .NET 세계에서 모두 살아왔기 때문에 압니다.
그리고 이것에 대한 초안 구현을 시작하겠습니다.

실제로 이것에는 두 가지 구성 요소가 있으며 둘 다 필요합니다(@GrabYourPitchforks의 https://github.com/dotnet/corefxlab/issues/1799의 CodeUnit)

C# keyword      Ugly Long form      Size
----------------------------------------
ubyte      <=>  System.CodeUnit    8 bit  - Assumed Utf8 in absence of encoding param
uchar      <=>  System.CodePoint  32 bit

CodeUnit / ubyte 는 가변 너비 인코딩을 나타내는 데 중요하고 Span<ubyte> 에서 사용하여 텍스트 API가 원시 바이트가 아닌 텍스트 유형에서 사용 가능하도록 하는 데 중요합니다.

CodePoint / uchar 는 합리적인 처리에 중요합니다. 예를 들어 .IndexOf(❤) as ubyte 자체는 멀티바이트 유니코드 문자를 검색하는 데 사용할 수 없습니다. ubyte s 이상을 열거하는 것은 위험할 수 있으므로 열거자는 uchar 단위로 작동해야 합니다.

두 제안을 결합하면 다음과 같습니다.

using System;
using System.Runtime.InteropServices;

// C# Keywords
using ubyte = System.CodeUnit;
using uchar = System.CodePoint;
using uspan = System.Utf8Span;
using ustring = System.Utf8String;

namespace System
{
    public ref struct Utf8Span
    {
        private readonly ReadOnlySpan<ubyte> _buffer;

        public Utf8Span(ReadOnlySpan<ubyte> span) => _buffer = span;
        public Utf8Span(uspan span) => _buffer = span._buffer;
        public Utf8Span(ustring str) => _buffer = ((uspan)str)._buffer;
        public Utf8Span(ReadOnlyMemory<ubyte> memory) => _buffer = memory.Span;

        // Returns the CodeUnit index, not CodePoint index
        public int IndexOf(char value) => IndexOf(value, 0);
        public int IndexOf(char value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(char value, int startIndex, int count);
        public int IndexOf(char value, StringComparison comparisonType);

        public int IndexOf(uchar value) => IndexOf(value, 0);
        public int IndexOf(uchar value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(uchar value, int startIndex, int count);
        public int IndexOf(uchar value, StringComparison comparisonType);

        public uspan Substring(int codeUnitIndex);
        public uspan Substring(int codeUnitIndex, int codePointCount);

        public bool StartsWith(uchar ch) => _buffer.Length >= 1 && _buffer[0] == ch;
        public bool StartsWith(ustring str) => StartsWith((uspan)str);
        public bool StartsWith(uspan value) => _buffer.StartsWith(value._buffer);
        public bool EndsWith(uchar ch) => _buffer.Length >= 1 && _buffer[0] == ch;
        public bool EndsWith(ustring str) => EndsWith((uspan)str);
        public bool EndsWith(uspan value) => _buffer.EndsWith(value._buffer);

        public Enumerator GetEnumerator() => new Enumerator(this);

        // Iterates in uchar steps, not ubyte steps
        public ref struct Enumerator
        {
            public Enumerator(uspan span);

            public uchar Current;
            public bool MoveNext();
            public void Dispose() { }
            public void Reset() => throw new NotSupportedException();
        }
    }

    public class Utf8String
    {
        private readonly ReadOnlyMemory<ubyte> _buffer;

        public Utf8String(ustring str) => _buffer = str._buffer;
        public Utf8String(ReadOnlyMemory<ubyte> memory) => _buffer = memory;

        public bool StartsWith(uchar ch) => ((uspan)this).StartsWith(ch);
        public bool StartsWith(ustring value) => ((uspan)this).StartsWith(value);
        public bool StartsWith(uspan value) => ((uspan)this).StartsWith(value);
        public bool EndsWith(uchar ch) => ((uspan)this).EndsWith(ch);
        public bool EndsWith(ustring value) => ((uspan)this).EndsWith(value);
        public bool EndsWith(uspan value) => ((uspan)this).EndsWith(value);

        public static implicit operator uspan(ustring value) => new uspan(value._buffer);

        // Returns the CodeUnit index, not CodePoint index
        public int IndexOf(char value) => IndexOf(value, 0);
        public int IndexOf(char value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(char value, int startIndex, int count);
        public int IndexOf(char value, StringComparison comparisonType);

        public int IndexOf(uchar value) => IndexOf(value, 0);
        public int IndexOf(uchar value, int startIndex) => IndexOf(value, 0, _buffer.Length);
        public int IndexOf(uchar value, int startIndex, int count);
        public int IndexOf(uchar value, StringComparison comparisonType);

        public ustring Substring(int codeUnitIndex);
        public ustring Substring(int codeUnitIndex, int codePointCount);

        public uspan.Enumerator GetEnumerator() => ((uspan)this).GetEnumerator();
    }

    [StructLayout(LayoutKind.Auto, Size = 1)]
    public struct CodeUnit : IComparable<ubyte>, IEquatable<ubyte>
    {
        private readonly byte _value;

        public CodeUnit(ubyte other) => _value = other._value;
        public CodeUnit(byte b) => _value = b;

        public static bool operator ==(ubyte a, ubyte b) => a._value == b._value;
        public static bool operator !=(ubyte a, ubyte b) => a._value != b._value;
        public static bool operator <(ubyte a, ubyte b) => a._value < b._value;
        public static bool operator <=(ubyte a, ubyte b) => a._value <= b._value;
        public static bool operator >(ubyte a, ubyte b) => a._value > b._value;
        public static bool operator >=(ubyte a, ubyte b) => a._value >= b._value;

        public static implicit operator byte(ubyte value) => value._value;
        public static explicit operator ubyte(byte value) => new ubyte(value);

        // other implicit conversions go here
        // if intrinsic then casts can be properly checked or unchecked

        public int CompareTo(ubyte other) => _value.CompareTo(other._value);

        public override bool Equals(object other) => (other is ubyte cu) && (this == cu);

        public bool Equals(ubyte other) => (this == other);

        public override int GetHashCode() => _value;

        public override string ToString() => _value.ToString();
    }

    [StructLayout(LayoutKind.Auto, Size = 4)]
    public struct CodePoint : IComparable<uchar>, IEquatable<uchar>
    {
        private readonly uint _value;

        public CodePoint(uint CodePoint);
        public CodePoint(char ch);

        public static ValueTuple<uchar, int> DecodeLastCodePoint(ubyte[] buffer, int end);
        public static ValueTuple<uchar, int> DecodeLastCodePoint(ustring str, int end);
        public static ValueTuple<uchar, int> DecodeCodePoint(ubyte[] buffer, int start, int n);
        public static ValueTuple<uchar, int> DecodeCodePoint(ustring str, int start, int n);
        public static int EncodeCodePoint(uchar CodePoint, ubyte[] dest, int offset);
        public static bool FullCodePoint(ubyte[] p);
        public static bool FullCodePoint(ustring str);
        public static int InvalidIndex(ubyte[] buffer);
        public static int InvalidIndex(ustring str);
        public static bool IsControl(uchar CodePoint);
        public static bool IsDigit(uchar CodePoint);
        public static bool IsGraphic(uchar CodePoint);
        public static bool IsLetter(uchar CodePoint);
        public static bool IsLower(uchar CodePoint);
        public static bool IsMark(uchar CodePoint);
        public static bool IsNumber(uchar CodePoint);
        public static bool IsPrint(uchar CodePoint);
        public static bool IsPunctuation(uchar CodePoint);
        public static bool IsSpace(uchar CodePoint);
        public static bool IsSymbol(uchar CodePoint);
        public static bool IsTitle(uchar CodePoint);
        public static bool IsUpper(uchar CodePoint);
        public static int CodePointCount(ubyte[] buffer, int offset, int count);
        public static int CodePointCount(ustring str);
        public static int CodePointLen(uchar CodePoint);
        public static uchar SimpleFold(uchar CodePoint);
        public static uchar To(Case toCase, uchar CodePoint);
        public static uchar ToLower(uchar CodePoint);
        public static uchar ToTitle(uchar CodePoint);
        public static uchar ToUpper(uchar CodePoint);
        public static bool Valid(ubyte[] buffer);
        public static bool Valid(ustring str);
        public static bool ValidCodePoint(uchar CodePoint);

        public static bool operator ==(uchar a, uchar b) => a._value == b._value;
        public static bool operator !=(uchar a, uchar b) => a._value != b._value;
        public static bool operator <(uchar a, uchar b) => a._value < b._value;
        public static bool operator <=(uchar a, uchar b) => a._value <= b._value;
        public static bool operator >(uchar a, uchar b) => a._value > b._value;
        public static bool operator >=(uchar a, uchar b) => a._value >= b._value;

        // etc
    }
}

내 프로토타입 구현에서 UnicodeScalar 를 사용하여 유니코드 스칼라 값(U+0000..U+10FFFF 범위의 값 포함, 대리 코드 포인트 제외) 및 Utf8Char UTF-8 코드 단위를 참조하십시오. 많은 사람들이 _UnicodeScalar_ 대신 _Rune_을 선호하는 것 같습니다. 나는 별로 신경 쓰지 않지만 "유니코드 스칼라 값"이라는 용어 는 유니코드 사양에서 사용하는 것과 같은 용어임을 지적하겠습니다. ;)

.NET Framework에는 결합될 때 분할할 수 없는 단일 문자소를 생성하는 하나 이상의 스칼라인 "텍스트 요소"라는 개념도 있습니다. 이에 대한 자세한 정보 는 MSDN 을 참조하십시오. 특히 문자열을 열거할 때 코드 단위( Utf8Char 또는 Char ), 스칼라 값( UnicodeScalar ) 또는 텍스트 요소별로 열거할 수 있습니다. 특정 시나리오. 이상적으로는 String과 Utf8String 모두에서 세 가지 유형을 모두 지원합니다.

프로토타입에 대한 API 표면은 완료되지 않았으며 빠르게 변경될 수 있지만 https://github.com/dotnet/corefxlab/tree/utf8string/src/System.Text.Utf8/System 에서 현재 생각을 볼 수 있습니다. https://github.com/dotnet/corefxlab/blob/master/src/System.Text.Primitives/System/Text/Encoders/Utf8Utility.cs.

약간 주제에서 벗어남:
"텍스트 요소" 는 UAX dotnet/corefx#29의 "Grapheme Cluster Boundaries"에 의해 정의된 분할이어야 합니까?

using System;
using System.Globalization;

class Program
{
    static void Main()
    {
        var e = StringInfo.GetTextElementEnumerator("👩🏻‍👦🏼👨🏽‍👦🏾‍👦🏿👩🏼‍👨🏽‍👦🏼‍👧🏽👩🏻‍👩🏿‍👧🏼‍👧🏾");
        while (e.MoveNext())
        {
            Console.WriteLine(e.GetTextElement());
        }
    }
}

예상 결과:
👩🏻‍👦🏼
👨🏽‍👦🏾‍👦🏿
👩🏼‍👨🏽‍👦🏼‍👧🏽
👩🏻‍👩🏿‍👧🏼‍👧🏾

실제 결과:
👩
🏻
‍
👦
🏼
👨
🏽
‍
👦
🏾
‍
👦
🏿
👩
🏼
‍
👨
🏽
‍
👦
🏼
‍
👧
🏽
👩
🏻
‍
👩
🏿
‍
👧
🏼
‍
👧
🏾

UnicodeScalar 는 여전히 입력하기 매우 쉽습니다. u s c 스페이스 (자동 완성) 그것이 정확하고 가장 자기 설명적인 용어이기 때문에 우리가 그것을 얻기를 정말로 바랍니다.

@ufcpp 좋은 지적입니다. 이에 대한 새로운 문제를 자유롭게 여십시오. 호환성 이유로 동작을 변경할 수 없다면 해당 유형을 더 이상 사용하지 않고 사양을 준수하는 자소 열거자를 만드는 것이 좋습니다.

ubyte / uchar 은(는) 혼란스럽습니다. ushort / uint / ulong 로 설정된 규칙에 따라 unsigned char / unsigned byte 처럼 읽습니다. char8 / u8char 및 char32 / u32char 가 더 명확할까요?

어쨌든 UTF-8 코드 단위 및 코드 포인트가 다음과 같은지 여부에 대해 잘못 정렬되어 있다고 생각합니다.

1. byte , int 와 같은 .NET의 저수준 기본 데이터 유형
2. DateTime , Guid 와 같은 기존 프리미티브로/에서 변환할 데이터 형식

그런 다음 해당 결정에 따라 코드 포인트 관련 API를 어떻게 노출합니까?

옵션 1은 C++17과 같이 char8, char16 및 char32 프리미티브(및 수반되는 u8string, u16string 및 u32string)를 통해 텍스트를 처리하는 것을 의미합니다. 그런 다음 rune 인 char32는 잘못된 이름입니다. 이미 char16이 char 이고 char8 에 대한 세 번째 이름도 필요하기 때문입니다.

옵션 2는 byte 및 int/uint가 UTF 코드 단위 및 코드 포인트를 저장하기에 '충분히' 좋다는 것을 의미합니다. 이는 모든 문자열이 UTF-16으로 유지됨을 의미합니다. CodePoint / rune 는 이진 표현이 아닌 Code Point 의미론의 문제를 해결 하며 IO용이 아닙니다 .

IMO UTF-8/UTF-32는 데이터 형식일 뿐입니다(옵션 2). 데이터(byte/int)로 취급하십시오. CodePoint 는 $#$ int $#$보다 DateTime 또는 Guid (다른 식별자*)와 비슷합니다. 저수준 기본 유형이 아니며 IO에서 직접 지원되지 않습니다. (즉, BinaryWriter) 내장 함수가 필요하지 않습니다.

@miyu corefxlab 에서 가져올 프로토타입은 옵션 1에 더 가깝습니다. 코드 단위를 나타내는 특정 데이터 유형이 있으며 이러한 데이터 유형은 텍스트 데이터의 내부 표현을 위한 것이며 유선을 통해 텍스트 데이터를 전송하는 데 사용할 수 없습니다. (당신이 지적했듯이 .NET은 오늘날 이미 다음과 같이 작동합니다. System.Char 는 UTF-16 문자열의 코드 단위이지만 System.Char 는 유선으로 보낼 수 없습니다.)

또한 byte[] / Span<byte> / 등(모든 데이터의 이진 표현이며 I/O에 적합)과 Utf8String 와 같은 기본 유형 간에 변환하는 API가 있습니다. String / Guid / etc. 이들 중 일부는 다른 것보다 더 간단합니다. 예를 들어, i/o에서 사용하기 위해 ReadOnlySpan<byte> 를 반환하는 편리한 Utf8String.Bytes 속성을 노출할 수 있으며 이 속성 getter는 O(1) 복잡성을 가질 수 있습니다. String 유형에는 이러한 속성을 도입하지 않겠지만 String.ToUtf8Bytes() 편의 메서드가 있다고 상상할 수는 있습니다. 그리고 Utf8String.Bytes 속성이 있더라도 Utf8String 인스턴스를 직접 열거하는 요소 유형은 byte 가 아닙니다. Utf8CodeUnit (이름 미정) 또는 UnicodeScalar 중 개발자가 빌드하려는 응용 프로그램 유형에 더 적합하다고 생각하는 것입니다.

바보 같은 아이디어 - wchar (_wide char_)는 어떻습니까? 오늘날 대부분의 C 및 C++ 컴파일러 환경(Windows 외부)은 이미 wchar_t 를 사용하여 32비트 코드 단위에 해당하는 기능을 나타냅니다. Windows는 wchar_t 가 16비트 유형으로 정의된 주목할 만한 예외이지만 오늘날 Windows에서 p/invoke하는 개발자는 이미 .NET char 간의 비트 너비 차이를 인식하고 있어야 합니다. char .

type/keyword wchar 는 우리의 명명 규칙을 위반하지만 고려를 위해 이것을 던졌습니다.

어리석은 아이디어 - wchar (와이드 문자)는 어떻습니까?

나를 위해 일한다

유형 / 키워드 wchar 는 명명 규칙을 위반합니다. ...

짧은 C# 언어 키워드를 얻을 것 같지 않습니다.

https://github.com/dotnet/apireviews/pull/64#discussion_r196962756 이러한 유형에 대한 언어 키워드를 도입할 가능성은 극히 낮은 것 같습니다. 이러한 유형은 문맥적이어야 하기 때문입니다(즉, 키워드가 나타내는 유형이 아니라 해당 유형에 바인딩해야 하는 키워드의 이름).

그래서 우리가 좋은 것을 원한다면... 예를 들어 NotLotsOfCapitalFullWords ...

나는 일반적으로 .NET의 명명 규칙을 좋아하지만 긴 이름은 본질적으로 제네릭 및 루프 변수로도 사용될 가능성이 있는 int 에 대해 약간 공격적입니다.

예를 들어 아무도 하지 않는다

foreach (Int32 i in list)
{
    // ...
}

그들은 할? (확실히...)

foreach (UnicodeScalar us in str)
{
    // ...
}

훨씬 더 나쁘다

foreach (wchar c in str)
{
    // ...
}

괜찮아 보이는데...

rune , wchar 및 uchar (다른 스레드에서 제안됨) 모두 나에게 좋게 들립니다. string 의 동료를 위한 제안 사항이 있습니까? wstring , ustring 또는 기타?

... C# 언어 키워드를 얻지 못하는 이유는 무엇입니까? 물론, 첫 번째 릴리스에 키워드가 없는 것은 의미가 있지만, 이것이 미래의 문자열 처리 방식이라면 키워드가 없는 것은 정직하지 않을 뿐만 아니라 채택에 대해 명백히 적대적입니다.

/CC @MadsTorgersen @jaredpar

C# 언어 키워드를 얻지 못하는 이유는 무엇입니까?

새 키워드는 100% 변경 사항을 깨고 있습니다. 어떤 단어를 선택하든 프로젝트의 모든 곳에서 사용되는 이름 유형을 가진 회사가 있습니다. 우리가 가진 유일한 옵션은 문맥 키워드입니다: 예를 들어 var .

나는 이것을 위해 문맥 키워드를 사용하는 것에 대해 엇갈린 감정을 가지고 있습니다. 기존 유형 키워드( int , string 등 ...)는 실제 유형 이름( Int32 , String )보다 구체적인 이점이 있습니다.

• string : 이것은 컴파일러가 corelib로 식별하는 어셈블리의 System.String 유형을 나타냅니다. 이 이름에는 관련된 모호성이 없습니다.
• String : 컴파일러가 이 유형을 전혀 이해하지 못합니다. 이것은 다른 것과 같은 유형이며 정의한 유형과 동일한 조회 규칙을 모두 거칩니다. string 와 같을 수도 있고 그렇지 않을 수도 있습니다.

여기에 문맥 키워드를 도입하면 rune 는 다음 중 하나가 될 수 있습니다.

• corelib 어셈블리 내부의 System.Rune 유형
• 2년 전에 Go 에 대해 읽을 때 정의한 rune 유형입니다.

rune String 모호하므로 문맥 키워드로 사용하는 것의 확실한 이점은 없습니다.

BTW: 이것이 바로 String string 를 사용해야 하는 이유입니다 😄

BTW: 이것이 String string 를 사용해야 하는 이유입니다.

사람들이 언어 키워드를 원한다고 생각하는 99%의 이유입니다. 나머지 1%는 "더 좋아 보인다"는 것입니다 😏

"rune" 키워드에 대한 강한 싫어요에 대해 엄지손가락을 아래로 내리십시오.

더 나은 단어는 글리프입니다. 이미 타이포그래피에서 원소 기호의 일반적인 개념을 나타내기 때문입니다.

룬은 아이러니하게도 유니코드로 정의된 특정 유형의 글리프입니다. Go를 선행 기술로 언급하는 것은 다소 우스꽝스럽습니다. 룬에 대한 선행 기술은 서기 150년에 작성된 실제 물리적 룬 스톤입니다. 레드몬드의 누군가가 생각하는 룬이 아닙니다. .NET에는 일반적으로 잘 설계된 API 표면이 있기 때문에 이와 같이 기존 개념을 재정의하는 것은 드문 일입니다. 이것은 매우 열악한 API 이름 지정의 드문 예외이며 불만을 표명하고 싶습니다.

더 나은 단어는 글리프입니다. 이미 타이포그래피에서 원소 기호의 일반적인 개념을 나타내기 때문입니다.

문제는 "Glyph"가 유니코드를 보이는 텍스트로 렌더링할 때 사용되는 용어입니다(출처: utf8everywhere.org ).

글리프

글꼴 내의 특정 모양입니다. 글꼴은 유형 디자이너가 디자인한 글리프 모음입니다. 일련의 코드 포인트를 지정된 글꼴 내에서 일련의 글리프로 변환하는 것은 텍스트 셰이핑 및 렌더링 엔진의 책임입니다. 이 변환에 대한 규칙은 복잡하고 로케일에 따라 다르며 유니코드 표준의 범위를 벗어납니다.

Go를 선행 기술로 언급하는 것은 다소 우스꽝스럽습니다.

Utf-8을 생성할 때 Rob Pike 및 Ken Thompson이라는 용어 사용 https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

Rob Pike는 현재 Go에서 작업하고 있기 때문에 원래 용어를 사용합니다.

룬은 아이러니하게도 유니코드로 정의된 특정 유형의 글리프입니다.

룬 문자는 유니코드로 정의되지만 룬 문자는 그렇지 않습니다.

룬 문자는 유니코드로 정의되지만 룬 문자는 그렇지 않습니다.

나는 이것이 정확한 진술이라고 생각하지 않습니다. 최신 유니코드 사양(http://www.unicode.org/versions/Unicode11.0.0/UnicodeStandard-11.0.pdf)에는 "rune"에 대한 37개의 조회수가 있습니다(36개만 유효합니다. , 마지막은 더 큰 단어의 일부이며 항상 룬 문자의 개별 문자를 참조하는 데 사용됩니다.

나는 이것이 정확한 진술이라고 생각하지 않습니다. 최신 유니코드 사양에는 "rune"에 대한 37개의 히트가 있습니다.

동기를 설명하는 본문에서; 문자 이름이나 텍스트 블록 이름에 없음(룬 문자 및 룬 문자)

동기를 설명하는 본문에서; 문자 이름이나 텍스트 블록 이름에 없음(룬 문자 및 룬 문자)

좋아, 공정해. 그러나 우리는 현재 유니코드 사양이 "룬"이라는 용어를 정의하지 않고 사용되는 경우 "룬 문자"를 설명하는 정보 텍스트를 위한 문제로 돌아갑니다.

공식적으로 정의하고 사물을 설명하는 데 사용하는 것은 "코드 포인트"와 "코드 단위"입니다.

• 역사적으로 원래 제작자는 "룬"이라는 용어를 사용했지만 공식 사양은 사용하지 않았습니다.

짧을 필요가 있거나 사용법이 추악해집니다.

int CountCommas(string str)
{
    int i = 0;
    foreach(UnicodeCodePoint c in str.AsUnicodeCodePoints())
    {
        if (c == ',') i++;
    }
}

string Trim(string str)
{
    int end = str.Length - 1;
    int start = 0;

    for (start = 0; start < Length; start++)
    {
        if (!UnicodeCodePoint.IsWhiteSpace(str.GetUnicodeCodePointAt(start)))
        {
            break;
        }
    }

    for (end = Length - 1; end >= start; end--)
    {
        if (!UnicodeCodePoint.IsWhiteSpace(str.GetUnicodeCodePointAt(start)))
        {
            break;
        }
    }

    return str.SubString(start, end);
}

대

int CountCommas(string str)
{
    int i = 0;
    foreach(Rune c in str.AsRunes())
    {
        if (c == ',') i++;
    }
}

string Trim(string str)
{
    int end = str.Length - 1;
    int start = 0;

    for (start = 0; start < Length; start++)
    {
        if (!Rune.IsWhiteSpace(str.GetRuneAt(start)))
        {
            break;
        }
    }

    for (end = Length - 1; end >= start; end--)
    {
        if (!Rune.IsWhiteSpace(str.GetRuneAt(start)))
        {
            break;
        }
    }

    return str.SubString(start, end);
}

길이가 길어지면 CodePoint.IsWhiteSpace 및 str.GetCodePointAt 로 갈 것이지만 Rune 도 재미있고 상관 없습니다.

@jnm2 문자열에 관해서는 GetCodePointAt 를 사용하지 않습니다. 너무 모호합니다. char 가 해당 인덱스에 있기를 원하는지 여부(모든 char s - 짝을 이루지 않은 대리자도 유효한 코드 포인트이기 때문에) 또는 스칼라 / 해당 인덱스에서 발생한 룬.

@GrabYourPitchforks GetRuneAt 가 같은 문제를 피할 수 있습니까, 아니면 둘 다 의미가 없다고 말씀하십니까?

@jnm2 저는 이 시나리오에서 특히 CodePoint 가 너무 모호하다고 말한 것입니다. 그렇지 않으면 메소드 이름 GetXyzAt 은 결국 들어가는 유형 이름 Xyz 와 일치해야 합니다.

참고로 이제 핵심 구현이 체크인되었습니다(https://github.com/dotnet/coreclr/pull/20935 참조). corefx에 전파할 시간을 주면 https://github.com/dotnet/corefx/pull/33395를 통해 ref API가 제공됩니다. 이 문제를 열어 두거나 적절하다고 생각되는 대로 해결하십시오.

나는 누군가에게 영향을 미치거나 기록을 위해 무엇이든 변경할 수 있을 것으로 기대하지 않습니다.

더 나은 단어는 글리프입니다. 이미 타이포그래피에서 원소 기호의 일반적인 개념을 나타내기 때문입니다.

문제는 "Glyph"가 유니코드를 보이는 텍스트로 렌더링할 때 사용되는 용어입니다(출처: utf8everywhere.org ).

"룬"은 유니코드나 트랜지스터, 마이크로소프트, 오픈 소스가 존재하기 훨씬 이전부터 역사를 통틀어 천 년이 넘는 기간 동안 사용된 용어이기 때문에 이러한 추론은 룬도 지원하지 않습니다. 적어도 그것은 분명히 일관성이 없는 다른 제안에 다른 표준을 임의로 적용하는 사람들이 있음을 나타냅니다. 그래서 아마도 가장 일관된 주장보다는 누가 먼저였거나 가장 큰 소리를 냈는지에 관한 것일 수 있습니다. 제가 무엇을 압니까? 나는 그 과정을 이해하려고 노력하는 늦었지만 이해가 되지 않습니다.

Go를 선행 기술로 언급하는 것은 다소 우스꽝스럽습니다.

Utf-8을 생성할 때 Rob Pike 및 Ken Thompson이라는 용어 사용 https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

Rob Pike는 현재 Go에서 작업하고 있기 때문에 원래 용어를 사용합니다.

Go와 Rob Pike는 이 주제에 대해 상대적으로 새로운 사람입니다. 사실 그들의 의견은 역사적으로나 대중 문학과 사회에서 룬이 무엇인지 정의한다는 점에서 다소 부적절합니다. Rob은 손으로 룬 스톤을 망치로 두드리지 않았으므로 룬이 무엇인지 정의할 자격이 거의 없습니다. 나는 그가 룬 스크립트를 직접 쓰거나 읽을 수도 없지만 내 추측입니다. 기껏해야 그는 인코딩을 통해 그 개념을 포착할 수 있지만 한자, 아랍어 문자 또는 한글 또는 웃는 얼굴이 룬이거나 "코드 포인트"인 다른 모든 것이 이제 룬이라고도 말할 수 없습니다. 또는 그런 것. 이 용어를 거의 무례하게 짓밟는 것 같습니다. 이제 모든 것이 룬이 될 수 있습니다. 즉, 룬은 텍스트 인코딩 영역에서 난해한 것을 나타내는 4글자 와일드카드 용어에 불과합니다.

룬은 아이러니하게도 유니코드로 정의된 특정 유형의 글리프입니다.

룬 문자는 유니코드로 정의되지만 룬 문자는 그렇지 않습니다.

유니코드는 룬이나 룬이 무엇인지 재정의하지 않습니다. 그들이 그렇게 한다면, 그들은 그들의 임무를 초과하는 것입니다. 그들은 대중에게 룬이 무엇인지 말할 일이 없습니다. 사실 그들은 새로운 언어나 문자 체계를 정의하는 사업이 전혀 없습니다. 천 년이 지난 지금 분명히 과중한 용어가 된 단어를 차용하고 새로운 개념을 생각해낸 것처럼 환호성을 지르기만 할 수는 없습니다. 룬 문자는 룬만으로 구성되며, 룬은 이미 확립된 개념입니다. 길거리에서 아무에게나 룬이 무엇인지 묻는다면 그들은 유니코드를 생각하지 않을 것입니다.

위의 모든 문제 외에도 룬은 최악의 부분인 빈약한 은유입니다. 그것은 아무것도 명확히하지 않습니다. 그것은 또 다른 수준의 혼란을 더할 뿐입니다. 이 주제를 처음 접하는 사람이라면 누구나 룬이 특정 문화권에서 사용되는 역사적 쓰기 체계라는 맥락을 이해하기 때문에 명확한 설명과 읽기를 거쳐야 합니다. 설명은 다음과 같이 진행되어야 합니다. "룬은 유니코드 코드 포인트입니다." "하지만 왜 그것을 코드 포인트라고 부르지 않습니까?" "글쎄, 너무 길기 때문에."또는 "누군가 룬을 좋아한다고 결정했습니다." 그래서 기본적으로 누군가는 9글자가 4글자에 비해 너무 많다고 생각하기 때문에(인텔리센스로 자동 완성 기능이 있고 Java Kingdom Of Nouns에 비하면 아무것도 아님에도 불구하고) 이제 우리는 이 혼란을 처리하고 이것을 수천 명에게 설명해야 합니다. 유니코드에 손을 대야 할 수도 있습니다. 코드에서 많이 사용하는 경우 using 문을 사용하여 용어를 줄이십시오.

UnicodeCodePoint일 필요도 없으며 단순히 CodePoint일 수도 있습니다. 이것은 이미 독특합니다. "CodePoint"보다 긴 API 용어가 많이 있으므로 충분합니다. 그래도 너무 길다면 약간의 약어가 있는 using 문을 사용하세요.

나는 이것이 실제로 많은 가치를 추가하지 않거나 유용한 것에서 논리적 근거를 갖지 않는 잡다한 인터뷰 질문 중 하나가 될 것으로 예상합니다. 적어도 "이정표"라는 은유의 경우 돌과 암석에서 파생된 개념을 기반으로 소프트웨어 개발에 사용되는 상징적 단어에 대해 이야기하고 있지만 이정표는 실제 설명적인 의미를 갖습니다. 모두에게 친숙한 개념을 즉시 전달합니다. 아하, 마치 긴 여행을 하고 오솔길을 지나갈 때와 같은 이정표입니다. 실제로 무언가를 시각화하는 데 도움이 되고 즉시 관리 언어가 될 수 있는 멋진 실세계 은유입니다. 사람들이 이 주제에 대해 잘 알지 못한다면 룬에 대해 이런 식으로 이야기하는 것을 상상할 수 없습니다. 이 시점에서 그들은 이미 그것이 코드 포인트에 대한 속임수 용어라는 것을 알게 될 것입니다.

더 나은 단어는 글리프입니다. 이미 타이포그래피에서 원소 기호의 일반적인 개념을 나타내기 때문입니다.

문제는 "Glyph"가 유니코드를 보이는 텍스트로 렌더링할 때 사용되는 용어입니다(출처: utf8everywhere.org).

"룬"은 유니코드나 트랜지스터, 마이크로소프트, 오픈 소스가 존재하기 훨씬 이전부터 역사를 통틀어 천 년이 넘는 기간 동안 사용된 용어이기 때문에 이러한 추론은 룬도 지원하지 않습니다.

내 요점은 "글리프"라는 단어가 이미 텍스트 렌더링의 개념 중 하나로 사용되었기 때문에 문제가 있다는 것입니다. 특정 글꼴에서 해당 문자의 그래픽 표현입니다. 따라서 캐릭터는 다양한 글리프로 표현될 수 있습니다.

...또 10,000미터 뷰의 @benaadams 와 정답과 함께 😁

솔직히 말해서 우리는 옛 격언을 따라 살아야 할 것입니다. "일부 사람들을 항상 행복하게 할 수 있고 모든 사람들을 한동안 행복하게 할 수 있지만 모든 사람들을 항상 행복하게 만들 수는 없습니다. 시간." 이것은 매우 전자의 상황입니다.

시질?

Exit, pursued by a bear.

이 API를 광범위하게 사용하는 사람으로서 저는 코드 포인트에 강력하게 한 표를 던집니다. 유니코드 용어는 이미 충분히 혼란스럽고 불일치가 이미 많습니다. 모든 곳에서 "코드 포인트"라고 말할 수 있다면 내 삶이 훨씬 쉬워질 것입니다.

나는 지금 침대에 누워있다. 옆으로 돌아서면 벽에 기대어 있는 화이트보드와 마주하게 된다. 내가 C#에서 IDN을 효율적으로 처리하는 방법을 알아내려고 노력하는 동안 몇 달 동안 그 화이트보드는 다양한 낙서와 차트의 고향이었습니다. 지옥 깊은 곳에서 불러온 유물처럼 취급합니다. 그것이 설명하는 논리를 설명하려고 시도했다면, 나는 할 수 없었을 것입니다.

제 삶을 힘들게 하지 말아주세요. 코드 포인트는 코드 포인트입니다. 그것은 룬 문자, 문자, 문자, 문자 또는 기호가 아닙니다. 인간에게 의미 있는 것을 나타낼 필요는 없습니다. 제어 코드일 수 있습니다. "룬"이라는 이름에서 알 수 있듯이 시각적 기호를 나타내지 않을 수 있습니다. 그것은 단지 코드 포인트입니다.

좀 더 구체적인 주장은 "룬"이 단일 자소의 표현을 의미한다는 것인데, 이는 종종 그렇지 않습니다. 코드 포인트 수와 자소 수를 세어 보면 두 개의 매우 다른 숫자를 얻을 수 있습니다. 동일한 자소 시퀀스는 두 개의 서로 다른 일련의 코드 포인트로 나타낼 수 있습니다.

더 나은 단어는 글리프입니다. 이미 타이포그래피에서 원소 기호의 일반적인 개념을 나타내기 때문입니다.

그게 더 나쁘다. 단일 코드 포인트는 여러 글리프로 나타낼 수 있고 단일 글리프는 여러 코드 포인트를 나타낼 수 있습니다. 정확한 매핑은 시스템, 프로그램, 서체에 따라 다를 수 있습니다.

이 모든 단어에는 매우 구체적인 기술적 의미가 있습니다. 이 제안의 맥락에서 차이점이 중요하지 않은 것처럼 보일 수 있지만 다른 곳, 특히 영어 이외의 언어에서 실질적인 결과를 가져옵니다.

독일어와 같은 일반적인 언어에서도 텍스트를 처리하는 것이 얼마나 어려운지 보여주는 예:

1. ß 를 대문자로 변환하면 SS 가 됩니다.
2. 다시 소문자로 변환하면 ss 가 됩니다.

문제:

• char.ToUpper('ß') 는 무엇을 반환해야 합니까? (하나의 문자를 반환해야 합니다.)
• 내 전화기가 이 텍스트 상자에 입력할 수 없는 ß의 대문자 버전이 유니코드 5.1에 추가되었습니다. 붙여넣으려고 하면 SS가 나옵니다. 이제 상한/하한 변환이 훨씬 더 모호합니다.
• 문자열의 대소문자를 바꾸면 길이가 바뀝니다.
• 대소문자 변경은 멱등성 또는 되돌릴 수 없습니다.
• 단순히 각 문자열을 소문자로 구분하여 대소문자를 구분하지 않는 비교를 수행할 수 없습니다.

이것은 용어가 문제를 일으키는 상황의 직접적인 예는 아니지만 우리가 일반적으로 생각하지 않는 일종의 극단적 인 경우가 있음을 보여줍니다. 각 용어에 고유하고 일관된 의미를 부여하면 프로그래머가 이러한 문제를 전달하는 데 도움이 됩니다. 팀원에게 자소 수를 세는 함수를 작성해 달라고 요청하면 그들은 정확히 무엇을 계산하고 어떻게 해야 하는지 알고 있습니다. 내가 그들에게 코드 포인트를 세도록 요청하면, 그들은 무엇을 해야 하는지 정확히 알고 있습니다. 이러한 정의는 우리가 사용하는 언어 및 기술과 무관합니다.

JavaScript 개발자에게 룬 수를 세어 달라고 하면 머리가 세 개 있는 것처럼 보일 것입니다.

위키피디아는 말한다

유니코드는 0hex에서 10FFFFhex 범위의 1,114,112 코드 포인트의 코드 공간을 정의합니다.

코드포인트가 정식 명칭인 것 같습니다. 이 스레드를 읽었지만 코드 포인트가 잘못된 이유에 대한 강제 인수를 찾지 못했습니다.

나는 코드 포인트가 여기서 사용하기에 올바른 용어가 아니라는 데 동의합니다. 최소한 유니코드 표준에 따라 10FFFF(http://unicode.org/glossary/#code_point) 이상의 값은 포함하지 않습니다.

그 문장이 잘못된 것은 아닐까? "코드 공간의 모든 값"이라고 표시됩니다. 따라서 정수를 잘못 이해하는 동시에 모든 것을 의미합니다.

또한 "룬"은 유니코드와 아무 관련이 없는 현실 세계의 의미 를 가지고 있습니다. 독일에서 "룬"이라는 단어는 나치의 의미를 담고 있습니다. 왜냐하면 룬은 나치가 언급하기를 좋아했던 "게르만" 역사를 가지고 있기 때문입니다.

나는 "룬"이 혼란스러운 이름이라고 생각합니다. 여기 사람이 "룬"을 정말 좋아 하거나 정확성을 기반으로 한 주장이 있습니까? 직관적으로, 그것은 정말 나쁜 이름입니다.

그 문장이 잘못된 것은 아닐까? "코드 공간의 모든 값"이라고 표시됩니다. 따라서 정수를 잘못 이해하는 동시에 모든 것을 의미합니다.

그 문장이 맞습니다. 코드 공간은 U+0000 ~ U+10FFFF입니다. 유니코드는 이론적으로 언젠가는 그 이상으로 확장될 수 있지만 UTF-8과 UTF-16을 깨뜨릴 것입니다. 새로운 인코딩이 필요합니다.

편집: 사실, UTF-16 파손에 대해 저를 인용하지 마십시오. 하지만 UTF-8이 파손될 것이라고 확신합니다. UTF-8은 확실히 0xFFFFFF(2^24 -1)를 나타낼 수 없습니다.

편집 2: 명확히 하기 위해 유니코드는 코드 포인트가 U+10FFFF를 초과할 수 없다고 명시하고 있습니다. 그렇다고 해서 현재 0x110000개의 코드 포인트가 있다는 의미는 아닙니다. 대부분의 코드 포인트는 할당되지 않았습니다.

@제 넥서 @GSPP

현재 마스터에 체크인된 이 유형( System.Text.Rune )은 "유니코드 스칼라 값"에 매우 구체적으로 매핑됩니다( 용어집 참조 ). -1 , 0xD800 또는 0x110000 값에서 구성하려고 하면 유형의 ctor가 예외를 throw합니다. 이는 유니코드 사양에 따른 스칼라 값이 아니기 때문입니다. Rune 매개변수를 메소드에 대한 입력으로 사용하는 경우 유효성 검사를 수행할 필요가 없습니다. 유형 시스템은 이미 유효한 스칼라 값으로 구성되었음을 확인했습니다.

다시: 대소문자 변환, .NET Framework의 모든 대소문자 변환 API는 _달리 언급되지 않는 한_ 단순 대소문자 접기라는 기술을 사용합니다. 단순 대소문자 접기 규칙에 따라 모든 입력 스칼라 값에 대해 출력 소문자, 대문자 및 제목 형식도 각각 정확히 하나의 스칼라 값이 되도록 보장됩니다. (숫자 0-9 또는 구두점 기호와 같은 일부 입력은 대소문자 변환 맵에 항목이 없습니다. 이러한 경우 _ToUpper_와 같은 연산은 단순히 입력 스칼라 값을 반환합니다.) 또한 간단한 대소문자 접기 규칙에 따라 입력이 다음과 같을 경우 기본 다국어 평면(BMP)에서 출력도 BMP에 있어야 합니다. 입력이 보조 평면에 있으면 출력도 보조 평면에 있어야 합니다.

여기에는 몇 가지 결과가 있습니다. 첫째, Rune.ToUpper 및 친구는 항상 단일 _Rune_(스칼라) 값을 반환합니다. 둘째, String.ToUpper 및 친구는 항상 입력과 정확히 동일한 길이의 문자열을 반환합니다. 이는 대소문자 변환 작업 후에 'ß'(소형 eszett)를 포함하는 문자열이 사용되는 문화권에 따라 'ß'(변경 없음) 또는 'ẞ'(majuscule eszett)을 포함하게 될 수 있음을 의미합니다. 그러나 "SS"를 포함하지 _않습니다_. 이렇게 하면 문자열 길이가 변경되고 공개적으로 노출된 거의 모든 .NET 대소문자 변환 API가 간단한 대소문자 접기 규칙을 사용하기 때문입니다. 셋째, Utf8String.ToUpper 및 친구(아직 체크인하지 않음)는 _Length_ 속성이 입력 값의 _Length_ 속성과 일치하는 값을 반환하지 _않습니다_. (문자열의 UTF-16 코드 단위 수는 간단한 대소문자 접기 후에 변경할 수 없지만 문자열의 UTF-8 코드 단위 수는 변경될 수 있습니다. 이는 BMP 값이 UTF-16 및 UTF-로 인코딩되는 방식 때문입니다. 8.)

내부적으로 단순한 대소문자 접기 규칙이 아닌 복잡한 대소문자 접기 규칙을 사용하는 일부 .NET API가 있습니다. String.Equals , String.IndexOf , String.Contains 및 유사한 작업은 문화에 따라 복잡한 대소문자 접기 규칙을 사용합니다. 따라서 문화권이 _de-DE_로 설정된 경우 _CurrentCultureIgnoreCase_를 전달하면 한 문자 문자열 "ß"와 두 문자 문자열 "SS"가 동일한 것으로 비교됩니다.

@GrabYourPitchforks 나는 주로 이름 선택에 반대합니다. 사례 접기 예제는 순전히 유니코드(및 일반적으로 텍스트)가 얼마나 복잡한지를 강조하기 위한 것입니다. normalization 을 처리할 수 있는 방법이 있는 한 간단한 작업이 어떻게 작동하는지 크게 신경쓰지 않습니다. 내 사용 사례에서는 어쨌든 모든 것을 NFKD로 변환할 것이기 때문입니다.

그 문장이 맞습니다. 코드 공간은 U+0000 ~ U+10FFFF입니다. 유니코드는 이론적으로 언젠가는 그 이상으로 확장될 수 있지만 UTF-8과 UTF-16을 깨뜨릴 것입니다. 새로운 인코딩이 필요합니다.

간단히 말해서(또는 사람들이 관심이 있는 경우) 이론적으로 UTF-8 알고리즘은 최대 42비트(접두사 바이트 0xFF 및 6비트 페이로드의 7바이트)에서 작동하며 원래 첫 번째 사양 은 전체 31비트를 다루었습니다. 범용 문자 집합(UCS4)의 이전 버전의

UTF-16의 경우 상황이 더 어렵습니다. 그러나 그들은 32비트 이상에 대해 "Escapes"로 상위 평면의 코드 포인트를 예약할 수 있습니다. 비행기 3~13은 현재 정의되지 않았으므로 "낮은 대리 비행기"와 "높은 대리 비행기"로 두 개를 예약할 수 있습니다. 그런 다음 32비트 코드포인트는 2개의 16비트 값(각 평면에 하나씩)으로 분할되고 각 값은 32비트 코드포인트를 인코딩하기 위해 각각 16비트의 4개 코드 단위를 효과적으로 사용하여 2개의 "클래식" 대리를 사용하여 인코딩됩니다.

Btw, AFAICS, 유니코드 컨소시엄은 U+10FFFF 이상의 코드포인트를 할당하지 않을 것이라고 공개적으로 밝혔습니다. 따라서 실제로는 그런 일이 실제로 일어나기 전에 제가 오래 은퇴하기를 바랍니다. :눈짓:

현재 마스터에 체크인된 이 유형( System.Text.Rune )은 "유니코드 스칼라 값"에 매우 구체적으로 매핑됩니다.

@GrabYourPitchforks 설명해주셔서 감사합니다. 이것은 구조체가 코드 포인트를 나타내지 않는다는 것을 의미합니다. 따라서 그 이름은 실제로 올바르지 않습니다.

UnicodeScalar 이름이 너무 애매한 것 같아요...

@GrabYourPitchforks , 이 문제에 대해 무엇을 해야 합니까?

@stephentoub 3.0의 기본 Rune 유형에 대해 계획된 추가 기능은 없지만 @migueldeicaza 는 자소 클러스터와 같은 것을 포함하여 유형의 범위를 확장하는 아이디어를 가지고 있었습니다. (인박스에 있는 가장 가까운 것은 TextElementEnumerator 입니다. 이것은 매우 오래된 유형입니다.) 이러한 아이디어 중 일부는 이 스레드에서 묶였지만 아직 구체적인 것은 없습니다.

커뮤니티가 시나리오에 대해 더 논의하기를 원하는 경우 이 문제를 열어둘 수 있고, 특정 제안을 하고 싶은 경우 사람들에게 새로운 문제를 열도록 지시할 수 있습니다. TBH 나는 강한 선호도가 없습니다.

감사 해요. Rune이 이미 도입되었고 여기에 설명된 API(또는 그 근사값)가 이미 노출되어 있으므로 이 작업을 종료하겠습니다. 추가 지원은 별도의 문제를 통해 해결할 수 있습니다.

그렇다면 이것은 이 시점에서 본질적으로 안정화된 것입니까? 솔직히 말해서 이 두려운 이름은 훌륭하고 정확한 출처에서 얻을 수 있는 유니코드 정보와 일치하지 않으며 인쇄되지 않는 문자와 대조적으로 상형 문자를 암시하는 불행한 뉘앙스를 가지고 있기 때문에 평범한 프로그래머가 유니코드에 대해 이미 두려운 이해를 하는 것을 악화시킵니다.

나는 이것이 이 시점까지 통합되었다는 것을 알고 있지만 Rune 부분과 이름에 대한 일부 사람들의 의견 불일치에 대해 차임하고 싶습니다.

나는 플랜 9에서 Rune 를 처음 만났고 다른 사람들처럼 Go에서 그것을 보았습니다. msdocs가 Rune 를 나열하기 시작했을 때 나는 읽기 전에 그것이 무엇인지 정확히 알고 있었습니다.

Plan 9와 Go의 두 가지 경우에는 Rune 라는 이름을 사용하여 UTF-8을 담당하는 개인이 있습니다. 나는 그들이 이러한 우려에 대해 이미 생각했고 여전히 Rune 가 합리적이라고 생각했다고 말하는 것이 안전하다고 생각합니다. 룬 문자는 일부 전통 주의자를 제외하고 더 이상 실제로 사용되는 쓰기 시스템이 아닙니다. 그리고 Rune 는 본질적으로 여기에서 자소를 의미하는 것처럼 해당 시스템의 자소를 의미합니다(제어 문자와 같은 경우 제외.

네이밍에 약간의 오류가 있는 것 같습니다. Runic은 너무 오래된 쓰기 시스템입니다. 평범한 프로그래머가 그것을 혼동할 지는 의심스럽습니다. 적절한 유니코드 "문자"에 대한 Rune 라는 사실상의 표준이 이미 수십 년 전에 있었습니다.

@엔토미

본질적으로 여기에서 자소를 의미하는 것처럼 (제어 문자와 같은 경우 제외.

이것은 사실이 아닙니다. 유니코드에는 여러 자소(일반적으로 문자 및 발음 구별 부호 조합)를 나타내는 사전 구성된 코드 포인트가 엄청나게 많이 포함되어 있으며 이는 일반적으로 프랑스어 및 스페인어와 같은 언어를 작성하는 데 사용되며 이러한 언어의 거의 모든 컴퓨터화된 텍스트는 이러한 코드를 사용합니다. 포인트들.

반대로 단일 코드 포인트가 하나의 자소를 나타내는 경우에도 대부분의 인도 언어에서 텍스트를 적절하게 처리하는 데 필수적인 _자소 클러스터_로 결합하는 것이 매우 일반적입니다. 따라서 화살표 키로 이동할 때 사용자가 인식하는 단일 문자는 종종 여러 코드 포인트에 순차적으로 해당합니다. 따라서 코드 포인트와 자소 또는 자소 클러스터 사이에는 쉬운 대응이 있을 수 없습니다. 프로그래머가 이 시점에서 문자를 이상하고 엉뚱한 것으로 간주하는 데 익숙하다는 점을 고려할 때 "문자"라도 아마도 더 나은 이름이 될 것입니다. 반면 "룬"은 사용자가 인식하는 문자 경계를 파악하는 문제가 프로그래머에게 해결되었다는 인상을 줍니다. 실제로 없었을 때 이미.

msdocs가 Rune을 나열하기 시작했을 때 나는 읽기 전에 그것이 무엇인지 정확히 알고 있었습니다.

rune이라는 이름이 자소를 잘 설명한다고 생각했다는 사실은 내가 여기서 가지고 있는 문제에 대한 아주 좋은 증거입니다. "rune"이라는 이름은 프로그래머에게 그러한 대응이 있다고 가정하기 쉽게 함으로써 잘못된 보안 감각을 줍니다.

Plan 9와 Go의 두 가지 경우에는 Rune 라는 이름을 사용하여 UTF-8을 담당하는 개인이 있습니다.

내가 Ken Thompson과 Rob Pike를 존경하는 만큼 여기에서의 그들의 작업은 본질적으로 일련의 가변 길이 정수를 인코딩하기 위한 매우 영리한 계획을 고안하는 것이었습니다. 그들은 유니코드 전체에 대한 전문가가 아니며 나는 이 문제에 대해 그들에게 매우 강력하게 동의하지 않습니다. 저도 유니코드 전문가가 아니라는 점을 인정하지만, 권위에 대한 호소력이 보이는 것만큼 강력하지 않다고 생각합니다.

그리고 적절한 유니코드 "문자"에 대한 룬의 사실상 표준이 수십 년이 되었습니다.

"표준"이라고 합니까? 대부분 이 두 가지가 이름을 밀어붙였고 Nim과 같은 몇 가지 사소한 프로그래밍 언어가 Go에서 이 이름을 채택했습니다. 그리고 물론 선택, 화살표 키 이동, 자소 또는 자소 클러스터의 의미에서 코드 포인트가 단일 "적절한 유니코드 문자"를 나타내지 않는다는 점을 다시 반복해야 합니다.

...본질적으로 여기에서 자소를 의미합니다...

예, 정확하지는 않지만 대략적으로 충분히 가깝습니다. 적어도 언어학에서 정의되는 문자소는 쓰기 체계를 구성하고 음소를 표현하는 데 사용되는 철자법 구성 요소입니다. 이것들은 1:1이 아닙니다. 음절 및 로고 음절에서 단일 자소는 일반적으로 자음-모음 쌍으로 여러 음소를 나타낼 수 있습니다. 반대로 알파벳순으로 언어에는 특정 단어에 따라 영어의 "th"가 고대 eth와 thorn을 담당하는 것과 같이 단일 음소를 나타내는 여러 자소의 경우가 종종 있습니다. 그런 다음 'á'와 같은 문자가 고유한 문자인지 또는 악센트가 있는 'a'인지에 대해 언어 간에 일치를 찾을 수 없습니다. 우리는 수천 년이 지난 언어의 일관성조차 확립할 수 없습니다. 우리는 그 위에 완벽하게 일관된 추가를하지 않을 것입니다. 즉, 인코딩입니다.

당신이 매우 엄격한 의미론을 주장하고 있기 때문에 UNICODE가 "자소 클러스터"라고 부르는 것은 언어학에서 종종 단일 자소에 불과합니다. 이것은 잘못된 유니코드입니까? 아니요. 이것은 UNICODE에서 이름을 바꿔야 한다는 의미입니까? 이유없이? 컨텍스트 때문입니다. 필드에는 고유한 용어가 있으며 단일 필드에 융합이 없는 한 문제가 되지 않습니다.

나는 그 이름이 너무 큰 거래라고 생각하지 않습니다. Msdocs는 요약에 Rune 가 무엇인지 명확합니다. 사람들이 문서를 읽지 않는다면 그것은 그들 자신의 문제입니다. 사람들은 'Stream'에 격렬하게 반응하지 않고 "오, 하지만 사람들이 그것을 작은 강이라고 생각한다면 그것은 이미 같은 이름을 가지고 있기 때문에"와 같은 말도 안되는 소리를 하지 않습니다. 아니요.

@Serentty @Entomy 두 사람 모두 실제 유니코드 개념 "확장된 자소 클러스터"를 노출하는 StringInfo 클래스 에 관심이 있을 수도 있습니다. StringInfo 유형은 상당히 오래되었고 결과적으로 매우 오래된 버전의 유니코드 표준을 구현하지만 UAX #29, Sec.

예, 정확하지는 않지만 대략적으로 충분히 가깝습니다.

나는 합성된 표현 대 분해된 표현의 문제가 이것을 사실이 아니라고 생각합니다. 컴퓨팅 관련 정의와 달리 여기에서 문자소의 언어적 정의에 따라 간다면 한과 한은 정확히 같은 자소 시퀀스입니다(세 개의 한글 자모는 음절 _han_을 세그먼트 HAN으로 나타냄). 그러나 첫 번째는 하나의 코드 포인트인 반면 두 번째는 3개의 시퀀스입니다.

필드에는 고유한 용어가 있으며 단일 필드에 융합이 없는 한 문제가 되지 않습니다.

이것이 바로 제 요점이기도 합니다. 유니코드는 자체 용어가 있는 정말 복잡한 시스템입니다. 그래서 정확히 정렬되지 않을 때 일종의 반쯤 구운 "직관적인" 용어를 강제로 적용하려고 하는 이유는 무엇입니까? 코드 포인트는 코드 포인트입니다. 언어적 유사성이 없으며 75%의 정확도만 유지하면서 직관적으로 하려고 하는 것은 C#이 여전히 복구하려고 시도하는 동일한 종류의 재난에 대한 레시피입니다.

당신이 매우 엄격한 의미론을 주장하고 있기 때문에 UNICODE가 "자소 클러스터"라고 부르는 것은 언어학에서 종종 단일 자소에 불과합니다.

표준에서 클러스터는 단일 자소로만 구성되도록 허용됩니다. 여기에는 아무 문제가 없습니다. _cluster_는 텍스트 선택 및 커서 이동의 단위입니다.

나는 그 이름이 너무 큰 거래라고 생각하지 않습니다. Msdocs는 요약에서 Rune이 무엇인지 명확합니다. 사람들이 문서를 읽지 않는다면 그것은 그들 자신의 문제입니다.

이것은 잘못된 디자인 결정을 방어하기 위해 반복적으로 나오는 "프로그래머는 더 똑똑해야 한다"는 주장입니다. 프로그래머가 문서를 읽고 어쨌든 룬이 유니코드 코드 포인트라는 것을 배워야 하는 경우 처음에 더 "직관적인" 이름이라고 부르는 요점이 무엇입니까? 여기서 주장은 "코드 포인트"가 혼란스럽기 때문에 보다 직관적인 이름을 선택하는 것이 합리적이지만, 이름이 오해의 소지가 있다는 문제에 직면했을 때 프로그래머가 어쨌든 코드 포인트가 무엇인지 알아야 한다는 주장인 것 같습니다. 문서를 읽는 것에서. 그렇다면 그냥 CodePoint 유형을 호출하고 프로그래머가 더 쉽게 찾아보고 배울 수 있도록 하지 않겠습니까? 이것은 .NET 문서가 처음에 유니코드와 관련하여 매우 끔찍하다는 문제를 제쳐두고, "16비트 유니코드 문자"의 세계에서 대리 쌍을 사후 고려 사항으로 취급합니다.

이것은 잘못된 디자인 결정을 방어하기 위해 반복적으로 나오는 "프로그래머는 더 똑똑해야 한다"는 주장입니다.

나는 이것을 말한 적이 없다.

여기서 주장은 "코드 포인트"가 혼란스럽다는 것입니다.

나도 이 말을 한 적이 없다.

사람들은 'Stream'에 격렬하게 반응하지 않고 "오, 하지만 사람들이 그것을 작은 강이라고 생각한다면 그것은 이미 같은 이름을 가지고 있기 때문에"와 같은 말도 안되는 소리를 하지 않습니다. 아니요.

나는 프로그래머가 Rune 가 특히 룬 문자라고 생각하지 않을 만큼 충분히 똑똑하다고 말하는 것입니다. 마치 그들이 Stream 가 작은 강이 아니라는 것을 아는 것과 같은 방식입니다.

이것을 반복하자

나는 프로그래머가 이것을 알아낼 만큼 충분히 똑똑하다고 말하고 있다. 당신은 내 입에 단어를 넣어.

나는 그 이름이 너무 큰 거래라고 생각하지 않습니다. Msdocs는 요약에서 Rune이 무엇인지 명확합니다. 사람들이 문서를 읽지 않는다면 그것은 그들 자신의 문제입니다.

이것이 내가 여기서 말하는 것입니다. "룬"이라는 이름에 찬성하는 주장은 직관과 자소 개념과의 직관적인 연결을 기반으로 합니다. 당신은 두 사람이 문제가 되지 않을 정도로 밀접하게 정렬되어 있다고 주장하고 있었습니다. 내가 그 직관이 틀렸고 통신이 매우 나쁠 수 있다는 모든 방법을 지적했을 때, 당신의 대답은 본질적으로 프로그래머가 어쨌든 문서를 읽어야 하기 때문에 중요하지 않다는 것이었습니다. 이것이 내가 "프로그래머는 더 똑똑해져야 한다"는 말의 의미입니다. 문서화는 이름에 대한 레거시 이유가 없을 때 오해의 소지가 있는 이름에 대한 변명이 아닙니다.

나는 프로그래머가 Rune 가 특히 룬 문자라고 생각하지 않을 만큼 충분히 똑똑하다고 말하는 것입니다. 마치 그들이 Stream 가 작은 강이 아니라는 것을 아는 것과 같은 방식입니다.

여기서 내 주장은 사람들이 그것을 룬 문자와 혼동할 것이라는 것이 아닙니다. 내 주장은 사람들이 당신의 주장에도 불구하고 모두 코드 포인트와 매우 나쁜 상관 관계를 갖는 글리프, 자소 및 자소 클러스터와 혼동할 것이라는 것입니다.

나는 프로그래머가 이것을 알아낼 만큼 충분히 똑똑하다고 말하고 있다. 당신은 내 입에 단어를 넣어.

그들이 실제 게르만 룬이 아니라는 것을 알아낼 만큼 똑똑합니다. 그러나 그것들이 글리프, 자소 또는 자소 클러스터가 아니라는 것을 알아내려면? 대부분의 소프트웨어에서 유니코드를 처리하는 품질에 대한 나의 실제 경험은 그렇지 않다고 말합니다.

사람들이 문서를 읽지 않는다면 그것은 그들 자신의 문제입니다.

예, 저는 이것을 지지합니다. 지능이 부족해서가 아니라 성급한 가정을 하는 경향이 있기 때문입니다.

프로그래머가 String 가 실을 꼬아서 만든 강하고 얇은 밧줄 조각을 의미한다고 가정한다면, 예, 그것은 그것이 String 라는 이름에 문제로 간주되지 않는다는 것을 의미하기 때문입니다. .

프로그래머가 Char 가 숯과 같은 탄 재료 또는 특정 유형의 송어를 의미한다고 가정하면 Char 이름의 문제로 간주되지 않습니다.

프로그래머가 character 가 스토리텔링에 사용되는 일련의 정신적, 윤리적 특성의 묘사를 의미한다고 가정하면 character 라는 이름의 문제로 간주되지 않습니다.

이것들은 모두 텍스트/언어 문제입니다. 그들은 모두 다른 의미를 가지고 있습니다. 그러나 프로그래머는 잘 적응했습니다. 이러한 용어는 해당 분야에서 확립된 관습인 당사 용어로 인해 사실상의 표준이 되었습니다. 프로그래머가 이것을 따를 만큼 충분히 똑똑하다는 확립된 선례가 있습니다.

당신은 두 사람이 문제가 되지 않을 정도로 밀접하게 정렬되어 있다고 주장하고 있었습니다.

예, 이것은 GitHub입니다. 이미 마감된 문제에서 이름에 확립된 선례가 있기 때문에 Rune 가 괜찮다고 생각한 이유에 대한 생각을 추가했습니다. 이곳은 광범위한 정의와 신중하게 선택한 단어로 가득 찬 논문을 쓰기 위한 장소나 맥락이 아닙니다. 예를 들어, UTF-8 디코더에 대한 PR을 입력하는 경우 대체 접근 방식보다 Hoehrmann DFA를 구현한 이유를 명시적으로 설명하지 않겠습니다. 저는 "여기 있습니다, 여기에 작동하는 증거가 있습니다. 여기에 내가 왜 이것을 사용했는지 뒷받침하는 몇 가지 벤치마크가 있습니다"라고 말할 것입니다.

내 주장은 사람들이 글리프, 자소 및 자소 클러스터와 혼동할 것이라는 것입니다.

앞서 언급한 것과 Tree , Heap , Table , Key , Socket , Port 중 어느 것도 혼동하지 않습니다.

이것은 매우 불합리한 주장입니다. 한 조각의 실과 텍스트의 문자열은 쉽게 혼동되지 않습니다. 키가 큰 식물과 나무 데이터 구조는 쉽게 혼동되지 않습니다. 반면에 코드 포인트는 대부분의 프로그래머가 매우 잘 이해하지 못하는 개념이며 우리가 논의한 다른 모든 개념과 끊임없이 혼동됩니다. 이에 대한 해결책은 당신이 말했듯이 문서를 읽는 것입니다. 그러나 코드 포인트에 대해 고유한 "영리한" 이름을 사용하는 언어는 _실제 유니코드 문서_의 지식을 해당 언어에 적용하는 것을 훨씬 더 어렵게 만듭니다. 그리고 그것은 저를 이렇게 만듭니다.

이러한 용어는 해당 분야에서 확립된 관습인 당사 용어로 인해 사실상의 표준이 되었습니다.

그리고 이것이 모든 것의 핵심입니다. 당신은 "룬"이 프로그래밍에서 널리 이해되는 코드 포인트에 대한 잘 정립된 용어이거나 그래야 한다고 주장하는 것 같습니다. 전자라면 Go 이외의 주요 프로그래밍 언어에 경험이 있는 일반 프로그래머에게 들어본 적이 있는지 물어보십시오. 후자라면 고도로 숙련된 개발자라도 자주 오해하는 이미 혼란스럽고 잘 이해되지 않는 상황에서 공식 유니코드 용어와 경쟁하는 요점을 묻고 싶습니다.

@Entomy 외부인 입력: 내가 말할 수 있는 한 귀하의 전체 주장은 '혼란스럽고 좋지 않습니다. 하지만 그렇게 혼란스럽고 나쁘지는 않습니다'입니다.
그래서? 대신에 실제로 좋지 않은 이유는 무엇입니까? 유니코드의 이름과 정확히 같은 이름을 지정하는 데 어떤 문제 가 있습니까?
또한 룬은 일반적인 컴퓨팅 분야에서 코드 포인트나 자소 또는 클러스터가 아닙니다. Google에서 'Unicode runes'를 검색하면 코드 포인트와 관련된 모든 것이 2페이지까지 표시되지 않고 그때도 godoc/Nim 링크일 뿐입니다. 프로그래머가 더 편할 수 있는 DuckDuckGo에서도 여전히 2페이지의 결과입니다. 따라서 내가 본 이름에 대해 남은 유일한 주장은 코드 포인트를 나타내는 것이 직관적 이지만 . 그것이 자소 클러스터 또는 아마도 단지 자소를 나타낸다는 것은 직관적입니다.
출처: 저는 Go를 사용해 왔으며 4년 후 이 호를 읽을 때까지 이것이 자소인 줄 알았습니다.

(그리고 '충분히 가깝기' 때문에 자소를 제안해도 괜찮다는 말은 16비트 문자가 충분히 가깝다는 것을 상기시켜줍니다.)
예, 프로그래머가 더 똑똑하고 더 많은 문서를 읽는다면 의미 있는 이름이나 유형이 전혀 필요하지 않을 것입니다. 사람들은 char 대신 int로 코드 포인트를 전달하는 방법을 알고 있을 것입니다. 하지만 그들은 그렇지 않습니다. 그들은 지금처럼 똑똑하고, 그것은 아직 또 다른 API가 추가되었다고 해서 변하지 않을 것입니다. 목표는 영어 이외의 언어를 올바르게 처리하는 소프트웨어의 양을 늘리는 것입니다. 단순히 동일한 작업을 수행하는 새로운 방법을 도입하고 이전과 동일한 진입 장벽을 유지하는 것이 아닙니다.

논쟁을 위해 그리고 과학적 목적을 위해 여기 있는 모든 사람에게 유니코드 텍스트 처리를 가장 잘 수행하는 하나의 프로그래밍 언어를 지적하고 싶습니다. 단순함을 속임으로써: 스위프트

• String 는 임의의 유니코드 텍스트 버퍼입니다.
• 반복되는 Character 는 단일 유니코드 스칼라 값이 아니라 확장된 자소 클러스터입니다. 자소 클러스터 한 에 대한 이 예를 참조하십시오. let decomposed: Character = "\u{1112}\u{1161}\u{11AB}" // ᄒ, ᅡ, ᆫ
• 유니코드 스칼라 값이 필요한 경우 이를 반복할 수도 있습니다. 해당 유형은 UnicodeScalar 입니다.
• 그리고 정말로 필요하다고 느끼면 UTF-8 및 UTF-16 코드 단위를 반복하여 UInt 8 및 UInt 16 를 생성할 수도 있습니다.

이제 C#이 완전한 Swift 스타일이 되도록 제안하는 것이 아닙니다. 이것은 놀라운 일이지만 또한 엄청나게 많은 변경과 작업이 필요합니다. 그러나 @Serentty 가 지적한 모든 이유로 Swift 스타일 이름 지정을 제안하고 텍스트 문자열을 결국 Swift 스타일로 전환할 수 있는 옵션을 열어 둡니다.

Rune 보다 더 나은 이름: CodeUnit32 , UnicodeScalar , CodeUnit , UniScalar , UnicodeValue , UniValue , UnicodeScalarValue . 처음 두 개는 C#의 명명 규칙에 잘 맞을 것 같습니다. UnicodeScalar 는 객관적으로 더 나은 이름입니다. 코드 단위는 유니코드 용어로 유니코드 스칼라 값을 인코딩하는 방법일 뿐입니다. 따라서 CodeUnit32 는 UTF-32로 인코딩된 텍스트 문자열의 코드 단위를 반복하는 것을 의미하는 반면 UnicodeScalar 는 인코딩에 구애받지 않습니다.

편집: 예, System.Rune 라는 이름이 이미 나와 있습니다. 이 모든 것은 "이것이 반세기가 되기 전에 더 좋게 만들고 싶다면"일 뿐입니다.

@파이맛

내가 말할 수 있는 한 귀하의 전체 주장은 '혼란스럽고 좋지 않습니다. 하지만 그렇게 혼란스럽고 나쁘지는 않습니다'입니다.

아니, 그것은 전혀 내 주장이 아닙니다. 나는 내가 가진 장애를 가지고 최선을 다하고 있지만 이것은 내가 의도한 의사 소통이 아닙니다.

Google에서 'Unicode runes'를 검색하면 코드 포인트와 관련된 모든 것이 2페이지까지 표시되지 않고 그때도 godoc/Nim 링크일 뿐입니다.

Google에서 '유니코드 문자열'을 검색하면 .NET 문자열이 작동하는 방식도 구체적으로 알 수 없습니다. 이것은 인접한 것을 찾는 문제입니다. 매우 엄격한 비유로 저는 .NET과 Ada 모두에서 프로그래밍합니다. string 는 그들 사이에서 동일하지 않으며 각각에 대해 약간의 독서가 좋은 생각입니다.

오버로드된 정의는 언어에서 드문 일이 아니지만 우리는 잘 관리합니다. 놀랍겠지만 "run"에는 최소 179개의 형식 정의가 있고 "take"에는 최소 127개, "break"에는 최소 "123"이 있습니다. [ 출처 ] 사람들은 놀라울 정도로 능력이 있으며 여기에서 문제가 되는 것으로 간주되는 것보다 훨씬 더 복잡한 것을 성공적으로 탐색할 수 있습니다. 최소한 2개의 공식적인 정의가 있는 "룬"에 대한 우려는 사람들이 50배 이상의 과부하를 처리하는 것으로 보일 수 있을 때 보증되지 않습니다.

더욱이 이것은 검색 엔진 동작을 심하게 악용하고 있습니다. 대부분의 검색 엔진에서는 무언가에 연결된 페이지 수를 기반으로 결과를 얻습니다. 각 접근 방식에 따라 가중치가 다르게 적용되는 다른 요소도 있습니다. .NET Rune은 비교적 최근의 개념이므로 이에 대해 이야기하는 내용이 훨씬 줄어들고 이해하는 데 더 많은 페이지가 소요됩니다. 그러나 그것은 또한 잘못된 검색 도구를 사용하고 있습니다. 문자열 검색 알고리즘에 대한 연구를 찾고 싶다면 지난 몇 년 동안 새로운 것이 나왔는지 확인하기 위해 Google이나 DDG를 검색하지 않습니다. Semantic Scholar, Google Scholar 등이 더 나은 출발점입니다. 마찬가지로 .NET API에 대해 이해하려면 먼저 MSDocs를 검색합니다. 물리/공학 용어인 "관성 모멘트"가 이름이 모호하거나 오해의 소지가 있다고 불평하고 처음 몇 권의 책에서 가장 낮은 번호부터 시작하여 이에 대한 정보를 찾을 수 없기 때문에 이름을 바꿔야 합니다. Dewey Decimal Classification을 사용하는 라이브러리에서는 "관성 모멘트"라는 이름을 지정하는 데 문제가 없습니다. 나는 분명히 잘못된 곳을 찾고 있습니다.

출처: 저는 Go를 사용해 왔으며 4년 후 이 호를 읽을 때까지 이것이 자소인 줄 알았습니다.

나는 적어도 내가 찾을 수 있는 Go 문서와 릴리스 노트를 살펴보았고 당신의 말에 동의해야 합니다. 그들은 rune 가 무엇인지에 대해 매우 모호하고 불행하게도 rune 가 얼마나 큰지조차 모호합니다. 나는 Ada가 데이터 유형 제약 조건에 대해 똑같이 모호한 것을 보았고 몇 년 후에 스스로를 물고 있는 것을 보았기 때문에 이 모호함이 나중에 문제를 일으킬 것이라고 생각합니다.

그러나 나는 msdocs가 매우 상세하고 간결한 설명으로 훨씬 더 나은 작업을 수행한다고 말해야 합니다.

유니코드 스칼라 값([ U+0000..U+D7FF ] 포함, 또는 [ U+E000..U+10FFFF ] 포함)을 나타냅니다.

즉, 주석이 다소 부족하고 Rune 가 존재하는 이유와 사용하려는 경우에 대한 설명이 약간 도움이 될 것입니다 (또한 앞서 언급 한 단순화 된 설명보다 더 자세한 설명을위한 적절한 장소) . 거기에 몇 가지 개선 사항을 제시하겠습니다.

@에브리

논쟁과 과학적 목적을 위해 여기 있는 모든 사람들에게 유니코드 텍스트 처리를 가장 잘 수행하는 하나의 프로그래밍 언어를 지적하고 싶습니다.

이것은 의견입니다. 나는 절대적으로 동의합니다. Swift는 확실히 최신 UNICODE를 더 잘 처리합니다. 그러나 이러한 결과를 확인하는 동료 검토의 재현 가능한 연구의 인용 없이는 이것은 과학적 주장이 아닙니다.

이제 C#이 완전한 Swift 스타일이 되도록 제안하는 것이 아닙니다. 이것은 놀라운 일이지만 또한 엄청나게 많은 변경과 작업이 필요합니다.

그리고 기존 소프트웨어를 깨뜨릴 것입니다.

텍스트 문자열을 결국 Swift 스타일로 바꾸려면 옵션을 열어 두십시오.

그리고 기존 소프트웨어를 깨뜨릴 것입니다.

예, System.Rune이라는 이름은 이미 존재합니다. 이 모든 것은 "이것이 반세기가 되기 전에 더 좋게 만들고 싶다면"일 뿐입니다.

그리고 기존 소프트웨어를 깨뜨릴 것입니다.

기존 이름을 변경해야 하는 경우 Rune 가 이미 사용 중인 .NET Core 3.0/3.1을 대상으로 하는 기존 소프트웨어를 제안하는 방법은 다음과 같습니다. 나중에 대상 런타임에서 다른 이름?

그리고 기존 소프트웨어를 깨뜨릴 것입니다.

언급했듯이 나는 원칙과 이상주의의 관점에서 주장하고 있습니다. 사물의 현실이 많이 언급되었습니다. 모든 것에는 약간의 뉘앙스가 있지만:

• 문자열을 사용하여 Swift 스타일을 사용한다고 해서 반드시 소프트웨어가 중단되는 것은 아닙니다. 이미 존재하는 String 인터페이스 위에 더 많은 열거 메서드와 유형을 추가하기만 하면 됩니다. 나는 System.Char 를 자소 클러스터 유형으로 변경하거나 그와 같은 것을 의미하는 것이 아닙니다.
• System.Char 와 같은 기존 유형 이름이 다른 유형으로 용도가 변경된다면 예, 이는 엄청난 변경이 될 것입니다. 그리고 그것에 대한 무책임한 변화. 나는 거기 당신과 함께 있어요.
• SemVer로 말하는 가상의 .NET Core 4.0은 원하는 모든 작업을 수행할 수 있습니다. 그 외에는 가상 4.0까지의 변경 사항은 그렇게 무섭지 않습니다. System.Rune 를 System.UnicodeScalar 또는 이름이 무엇이든 사용되지 않는 유형 별칭으로 바꾸십시오. Rune 를 사용하는 소프트웨어는 사용 중단 메모를 제외하고 차이를 느끼지 못할 것이며 새 소프트웨어는 더 나은 이름의 실제 유형을 사용할 수 있습니다. 그리고 가상의 4.0 Rune 를 떨어뜨립니다.
• 유사하게, System.Char 는 System.CodeUnit16 등의 별칭으로 바뀔 수 있습니다.
• Swift 스타일로 하는 것은 사실상 System.GraphemeCluster 를 믹스에 추가하는 것을 의미합니다.
• 이러한 모든 유형에 대해 더 많은 새 키워드 별칭을 도입하는 것은 문제가 될 수 있습니다.

여기에 생각을위한 음식을 떨어 뜨립니다. 나는 System.Rune 가 목적에 맞지 않는 유형 이름이지만 실제로 이전 명명 상태를 더 악화시키지는 않는다고 생각합니다. 마침내 모든 유니코드 스칼라를 인코딩할 수 있는 적절한 유형이 있다는 것은 대단한 일이라고 생각합니다. 그러나 보다 정확한 유니코드 처리 및 명명 추세를 전파할 수 있는 좋은 기회가 있다고 생각합니다. 여기 있는 모든 사람이 자유롭게 제쳐놓을 수 있는 기회입니다.

안녕하세요 System.Text.Rune 라는 이름은 배송된 제품이며 앞으로 사용할 제품입니다. 이전에 Rune UnicodeScalar 라는 이름을 사용하는 것에 대한 상당한(그리고 열띤) 토론이 있었지만 결국 Rune 가 이겼습니다. 팀은 현재로서는 다른 이름을 선택할 생각을 하고 있지 않습니다. 그리고 나는 사람들이 이것에 열정적이라는 것을 알고 있고 우리는 여기서 대화를 계속 모니터링할 것이지만, 궁극적으로 명명 문제를 계속하는 데 소비되는 에너지는 이익을 내지 못한다는 것을 알고 있습니다.

설명을 위해 문서에 따라: .NET의 System.Text.Rune 유형은 유니코드 스칼라 값과 정확히 동일합니다. 이것은 건설에 의해 시행됩니다. 이것은 Go의 rune 유형보다 Swift의 UnicodeScalar 유형과 더 유사합니다.

Rune 문서에 해당 사용 사례와 .NET의 다른 텍스트 처리 API 및 유니코드의 개념과 관련된 방법을 자세히 설명하는 섹션을 추가하려는 노력이 진행 중입니다. 추적 문제는 https://github.com/dotnet/docs/issues/15845에 있습니다. 해당 추적 문제에서 개념 문서의 현재 초안으로 연결되는 링크도 있습니다.

나에게 UnicodeScalar 의 주요 단점은 유형 이름의 길이와 유형의 데이터 크기 사이에 큰 차이가 있다는 것입니다. 기본적으로 도메인에 약간의 공백이 있는 int 입니다.

그러나 사용법의 장황함은 극단적입니다.

foreach (UnicodeScalar unicodeScalar in name.EnumerateUnicodeScalars())
{
     // ... unicodeScalar contains 1 int
}

대 $#$4$ char string (이상적으로 사람들은 분할 값을 포함하는 대신 전체 값이므로 char 이상의 새 유형을 사용합니다)

foreach (char c in name)
{
     // ... c contains 1 ushort
}

Rune은 형식 이름 장황함의 절충안입니다.

foreach (Rune rune in name.EnumerateRunes())
{
     // ... rune contains 1 int
}

@GrabYourPitchforks

여보세요! 솔직히 말해서, 내가 이 논쟁에 휘말리게 된 이유는 .NET 사람들에게 그 배가 항해한 것처럼 보이기 때문에 이름을 변경해야 한다고 설득하려는 것이 아니라 단순히 내 의견을 표현하고 싶었기 때문입니다. 그것에 동의하지 않는 이 스레드의 다른 사람들. C#이 오랫동안 가지고 있던 깨진 문자 유형과 달리 마침내 _real_ 문자 유형을 갖게 된 것은 훌륭하다고 생각하며 이름은 완전히 부차적입니다. 간결함과 정확성 사이에 엄청난 균형이 있다는 것을 이해하고 CodePoint 정도에 최적의 위치를 ​​지정했지만 다른 사람들이 동의하지 않는 이유를 이해합니다.

그러나 다시 한 번 .NET의 유니코드 지원을 현대화하기 위해 노력한 모든 것에 감사드립니다! 이것은 전 세계의 많은 사람들에게 큰 차이를 만드는 것입니다.