문자, 코드 포인트, 글리프 및 자소의 차이점은 무엇입니까?

문자, 코드 포인트, 글리프 및 자소의 차이점은 무엇입니까?

---

현대 유니 코드의 미묘함을 이해하려고하면 머리가 아프다. 특히, 코드 포인트, 문자, 글리프 및 자소 ( 가장 간단한 경우에는 ASCII 문자를 사용하는 영어 텍스트를 다룰 때 모두 서로 일대일 관계를 갖는 개념)의 구별 이 문제를 일으키고 있습니다.

Matthias Bynens의 JavaScript 와 같은 문서에서 이러한 용어가 어떻게 사용되는지 살펴보면 유니 코드 문제가 있거나 Han 통합 에 대한 Wikipedia의 조각이 있습니다. 저는 이러한 개념이 동일하지 않으며 이들을 통합 하는 것이 위험하다는 것을 모았습니다. 각 용어의 의미 를 파악하기 위해 고군분투합니다 .

유니 코드 컨소시엄은 이 내용을 설명 하는 용어집 을 제공 하지만 다음과 같은 "정의"로 가득 차 있습니다.

추상 문자 . 텍스트 데이터의 구성, 제어 또는 표현에 사용되는 정보 단위입니다. ...

...

캐릭터 . ... (2) 추상 문자의 동의어. (3) 유니 코드 문자 인코딩을위한 인코딩의 기본 단위. ...

...

글리프 . (1) 하나 이상의 글리프 이미지를 나타내는 추상적 인 형태. (2) 글리프 이미지의 동의어. 유니 코드 문자 데이터를 표시 할 때 특정 문자를 나타 내기 위해 하나 이상의 글리프를 선택할 수 있습니다.

...

Grapheme . (1) 특정 쓰기 시스템의 맥락에서 최소한으로 구별되는 쓰기 단위. ...

이러한 정의의 대부분은 매우 학술적이고 형식적으로 들리는 품질을 가지고 있지만 의미 의 품질이 부족 하거나 정의 문제를 또 다른 용어집 항목이나 표준 섹션으로 연기합니다.

그래서 저는 저보다 더 많이 배운 사람들의 신비한 지혜를 추구합니다. 이러한 각 개념은 정확히 어떻게 서로 다르며, 어떤 상황에서 서로 일대일 관계를 갖지 않을까요?

---

• 캐릭터 는 많은 것을 의미 할 수있는 과부하 된 용어입니다.

• 코드 포인트 정보의 기본 단위이다. 텍스트 는 일련의 코드 포인트입니다. 각 코드 포인트는 유니 코드 표준에 의해 의미가 부여 된 숫자입니다.

• 코드 부 (A)의 기억의 단위 인 부분 부호화 된 코드 포인트. UTF-8에서는 8 비트를 의미하고 UTF-16에서는 16 비트를 의미합니다. 단일 코드 단위는 전체 코드 포인트 또는 코드 포인트의 일부를 나타낼 수 있습니다. 예를 들어 눈사람 글리프 ( ☃)는 단일 코드 포인트이지만 3 개의 UTF-8 코드 단위와 1 개의 UTF-16 코드 단위입니다.

• 자모는 독자가 기록 시스템의 한 요소로서 인식하는 단일 그래픽 유닛으로 표시되는 하나 이상의 코드 포인트의 서열이다. 예를 들어, a및 둘 다 ä문자 소이지만 여러 코드 포인트로 구성 ä될 수 있습니다 (예 : 기본 문자에 대한 코드 포인트 1 개에 a이어 분할 문자 용 코드 포인트 1 개가 될 수 있습니다 . 그러나이 문자를 나타내는 레거시 단일 코드 포인트의 대안도 있습니다.) ). 일부 코드 포인트는 자소의 일부가 아닙니다 (예 : 너비가 0 인 비결 합자 또는 방향 재정의).

• 그래프는 일반적으로 저장된 이미지 인 폰트 이들 자모 또는 부분을 나타내는 데 (글리프의 집합이다). 글꼴은 여러 글리프를 단일 표현으로 구성 할 수 있습니다. 예를 들어 위 ä가 단일 코드 포인트 인 경우 글꼴은이를 공간적으로 중첩 된 두 개의 개별 글리프로 렌더링하도록 선택할 수 있습니다. OTF의 경우 글꼴의 GSUB 및 GPOS 테이블에는이 작업을 수행하기위한 대체 및 위치 지정 정보가 포함되어 있습니다. 글꼴에는 동일한 자소에 대한 여러 대체 글리프도 포함될 수 있습니다.

---

유니 코드 표준 밖에서 문자 는 하나 이상의 자소 로 구성된 개별 텍스트 단위입니다 . 유니 코드 표준이 "문자"로 정의하는 것은 실제로 문자 소와 문자가 혼합 된 것입니다. 유니 코드는 나란히 놓인 자소를 개별 문자로 해석하는 규칙을 제공합니다.

유니 코드 코드 포인트는 각각에 할당 된 고유 번호이다 유니 코드 문자 (문자 나 자모 하나 인).

불행히도 유니 코드 규칙은 일부 병치 된 자소가 이미 자체 코드 포인트 ( 미리 구성된 형식 )를 가지고있는 다른 자소로 해석되도록 허용 합니다. 이것은 유니 코드에서 문자를 표현하는 여러 가지 방법이 있음을 의미합니다. 유니 코드 정규화는 이 문제를 해결합니다.

글리프는 캐릭터의 시각적 표현입니다. 글꼴은 유니 코드 문자가 아닌 특정 문자 집합에 대한 글리프 집합을 제공합니다. 모든 문자에는 무한한 수의 글리프가 있습니다.

Mark Amery에 대한 답변

첫째, 내가 말했듯이, 각 문자에 대해 가능한 글리프의 수는 무한하므로 아니요, 문자는 "항상 단일 글리프로 표현"되지 않습니다. 유니 코드는 글리프에 그다지 관심이 없으며 코드 차트에서 정의하는 것은 확실히 글리프가 아닙니다. 문제는 모두 캐릭터가 아니라는 것입니다. 그래서 그들은 무엇입니까?

더 큰 실체, 자소 또는 캐릭터는 무엇입니까? 문자 나 구두점이 아닌 텍스트의 그래픽 요소를 무엇이라고 부르나요? 빠르게 떠오르는 용어 중 하나는 "grapheme"입니다. "텍스트의 그래픽 단위"라는 개념을 정확하게 연상시키는 단어입니다. 저는이 정의를 제공합니다 : 자소는 서면 텍스트에서 가장 작은 구별 구성 요소입니다 .

다른 방법으로 자소가 문자로 구성되어 있다고 말할 수 있지만, 그런 다음 "중국 자소"라고 불릴 것이며, 중국 자소가 구성하는 모든 비트와 조각을 대신 "문자"라고해야합니다. 그러나 그것은 모두 거꾸로입니다. 자소는 뚜렷한 작은 조각입니다. 캐릭터가 더 발달합니다. "문자는 구성 가능"이라는 문구는 유니 코드의 문맥에서 "문자는 구성 가능"으로 더 잘 표현됩니다.

유니 코드는 문자를 정의하지만 다른 자소 또는 문자로 구성 될 자소도 정의합니다. 당신이 만든 그 괴물들은 이것의 좋은 예입니다. 그들이 붙잡는다면 아마 그들은 나중에 유니 코드 버전에서 자신의 코드 포인트를 얻을 것입니다.)

이 모든 것에 재귀 적 요소가 있습니다. 더 높은 수준에서 자소는 문자가 자소가되지만, 완전히 내려가는 자소입니다.

TS에 대한 답변

표준의 1 장 에서는 "유니 코드 문자 인코딩은 알파벳 문자, 표의 문자 및 기호를 동등하게 처리합니다. 즉, 모든 조합에서 동일한 기능으로 사용할 수 있음을 의미합니다."라고 말합니다. 이 진술을 감안할 때 우리는 표준에서 용어의 일부 혼합에 대비해야합니다. 때때로 적절한 용어는 표준이 개발됨에 따라 돌이켜 보면 명확 해집니다.

언어의 공식적인 정의에서 두 가지 기본 사항이 서로에 대해 정의되는 경우가 종종 있습니다. 예를 들어, XML 에서 요소는 내용이 뒤 따르는 시작 태그와 종료 태그로 정의됩니다. 콘텐츠는 차례로 요소, 문자 데이터 또는 몇 가지 다른 가능한 것으로 정의됩니다. 자체 참조 정의의 패턴은 유니 코드 표준에도 내재되어 있습니다.

자소는 코드 포인트 또는 문자입니다.

문자는 하나 이상의 자소 시퀀스로 구성됩니다.

이 두 정의에 처음 직면했을 때 독자는 코드 포인트 가 문자 라는 이유로 첫 번째 정의에 반대 할 수 있지만 항상 사실은 아닙니다. 두 개의 코드 포인트 시퀀스는 때때로 정규화 하에서 단일 코드 포인트 를 인코딩하며, 인코딩 된 코드 포인트는 그림 2.7에 설명 된대로 문자를 나타냅니다 . 다른 코드 포인트를 인코딩하는 코드 포인트 시퀀스입니다. 이것은 약간 까다로워지고 있으며 UTF-8 과 같은 문자 인코딩 체계 를 사용하여 코드 포인트를 바이트 시퀀스로 인코딩 하는 계층에 도달하지 못했습니다 .

In some contexts, for example a scholarly article on diacritics, and individual part of a character might show up in the text by itself. In that context, the individual character part could be considered a character, so it makes sense that the Unicode standard remain flexible as well.

As Mark Avery pointed out, a character can be composed into a more complex thing. That is, each character can can serve as a grapheme if desired. The final result of all composition is a thing that "the user thinks of as a character". There doesn't seem to be any real resistance, either in the standard or in this discussion, to the idea that at the highest level there are these things in the text that the user thinks of as individual characters. To avoid overloading that term, we can use "grapheme" in all cases where we want to refer to parts used to compose a character.

At times the Unicode standard is all over the place with its terminology. For example, Chapter 3 defines UTF-8 as an "encoding form" whereas the glossary defines "encoding form" as something else, and UTF-8 as a "Character Encoding Scheme". Another example is "Grapheme_Base" and "Grapheme_Extend", which are acknowledged to be mistakes but that persist because purging them is a bit of a task. There is still work to be done to tighten up the terminology employed by the standard.

The Proposal for addition of COMBINING GRAPHEME JOINER got it wrong when it stated that "Graphemes are sequences of one or more encoded characters that correspond to what users think of as characters." It should instead read, "A sequence of one or more graphemes composes what the user thinks of as a character." Then it could use the term "grapheme sequence" distinctly from the term "character sequence". Both terms are useful. "grapheme sequence" neatly implies the process of building up a character from smaller pieces. "character sequence" means what we all typically intuit it to mean: "A sequence of things the user thinks of as characters."

Sometimes a programmer really does want to operate at the level of grapheme sequences, so mechanisms to inspect and manipulate those sequences should be available, but generally, when processing text, it is sufficient to operate on "character sequences" (what the user thinks of as a character) and let the system manage the lower-level details.

In every case covered so far in this discussion, it's cleaner to use "grapheme" to refer to the indivisible components and "character" to refer to the composed entity. This usage also better reflects the long-established meanings of both terms.

참고URL : https://stackoverflow.com/questions/27331819/whats-the-difference-between-a-character-a-code-point-a-glyph-and-a-grapheme