C ++ 11의 유니 코드

C ++ 11의 유니 코드

---

저는 유니 코드 (특히 UTF-8)의 C ++ 11 지원 (비) 지원에 대해 약간의 독서를 해 왔으며 Stack Overflow의 전문가가 제 이해가 정확하다는 확신을 줄 수 있기를 바랍니다. , 또는 내가 오해하거나 놓친 부분을 지적하십시오.

짧은 요약

첫째, 좋은 점 : 소스 코드에서 UTF-8, UTF-16 및 UCS-4 리터럴을 정의 할 수 있습니다. 또한 <locale>헤더에는 std::codecvtUTF-8, UTF-16, UCS-4 및 플랫폼 멀티 바이트 인코딩 사이에서 변환 할 수있는 여러 구현이 포함되어 있습니다 (API가 간단하게 표현하기는하지만 간단하지는 않지만). 이러한 codecvt구현은 imbue()파일 (또는 다른 스트림)을 읽거나 쓸 때 변환을 수행 할 수 있도록 스트림에서 수행 할 수 있습니다 .

[ 편집 : Cubbi는 내가 <codecvt>헤더 에 대해 언급 std::codecvt하지 않은 코멘트 에서 로케일에 의존하지 않는 구현을 제공 한다고 지적합니다 . 또한 std::wstring_convert및 wbuffer_convert함수는 이러한을 사용 codecvt하여 스트림에 의존하지 않고 문자열과 버퍼를 직접 변환 할 수 있습니다 .]

C ++ 11에는 <uchar.h>플랫폼 멀티 바이트 인코딩 (UTF-8 일 수도 있고 아닐 수도 있음)에서 UCS-2 및 UCS-4로 (부터) 개별 문자를 변환하는 함수가 포함 된 C99 / C11 헤더 도 포함 되어 있습니다.

그러나 그것은 그 정도입니다. 물론 UTF-8 텍스트를에 저장할 수는 있지만 std::string실제로 유용한 작업을 수행 할 수있는 방법은 없습니다. 예를 들어 코드에서 리터럴을 정의하는 것 외에 유효한 UTF-8을 포함하는 바이트 배열의 유효성을 검사 할 수 없으며 길이 (예 : "문자"의 일부 정의에 대한 유니 코드 문자 수)를 찾을 수 없습니다. )의 UTF-8을 포함 std::string하고 있으며 std::string바이트 단위가 아닌 다른 방식 으로을 반복 할 수 없습니다 .

마찬가지로 C ++ 11 추가도 std::u16stringUTF-16을 지원하지는 않지만 이전 UCS-2 만 지원합니다. 대리 쌍을 지원하지 않으므로 BMP 만 남습니다.

관찰

UTF-8이 거의 모든 Unix 파생 시스템 ( Mac OS X 및 * Linux 포함)에서 유니 코드를 처리하는 표준 방식이며 대부분 웹에서 사실상 표준이 되었기 때문에 최신 C ++에서 지원이 부족한 것 같습니다. 아주 심각한 누락과 같습니다. Windows에서도 새 버전 std::u16string이 UTF-16을 실제로 지원하지 않는다는 사실 은 다소 유감스럽게 보입니다.

_{* 주석에서 지적하고 여기 에서 명확하게 설명했듯이 Mac OS의 BSD 파생 부분은 UTF-8을 사용하고 Cocoa는 UTF-16을 사용합니다.}

질문

그 모든 것을 읽으 셨다면 감사합니다! 이것은 결국 스택 오버플로이기 때문에 몇 가지 간단한 질문입니다.

• 위의 분석이 정확합니까 아니면 내가 놓친 다른 유니 코드 지원 기능이 있습니까?

• 표준위원회는 지난 몇 년 동안 C ++를 빠른 속도로 발전시키는 환상적인 작업을 수행했습니다. 그들은 모두 똑똑한 사람들이며 위의 단점을 잘 알고 있다고 가정합니다. 유니 코드 지원이 C ++에서 여전히 열악한 것으로 알려진 특별한 이유가 있습니까?

• 앞으로 상황을 바로 잡기위한 제안을 아는 사람이 있습니까? isocpp.org에 대한 빠른 검색은 아무것도 드러내지 않는 것 같습니다.

편집 : 귀하의 답변에 감사드립니다. 나는 그들이 약간 낙담하다는 것을 고백해야한다. 현상 유지는 가까운 장래에 바뀔 것 같지 않다. cognoscenti 사이에 합의가 있다면 완전한 유니 코드 지원이 너무 어렵고 어떤 솔루션이든 대부분의 ICU가 유용하다고 간주 되려면 다시 구현해야한다는 것입니다.

나는 개인적으로 이것에 동의하지 않습니다. 발견 할 가치있는 중간 지대가 있다고 생각합니다. 예를 들어, UTF-8 및 UTF-16에 대한 유효성 검사 및 정규화 알고리즘은 유니 코드 컨소시엄에서 잘 지정되어 있으며 표준 라이브러리에서 std::unicode네임 스페이스 와 같은 무료 함수로 제공 할 수 있습니다 . 이것만으로도 유니 코드 입력을 기대하는 라이브러리와 인터페이스해야하는 C ++ 프로그램에 큰 도움이 될 것입니다. 그러나 아래의 답변에 따르면 (쓴맛을 띤 채로 말해야 함) 이러한 종류의 제한된 기능에 대한 Puppy의 제안은 잘 받아 들여지지 않은 것 같습니다.

---

위의 분석이 맞습니까?

보자.

유효한 UTF-8을 포함하는 바이트 배열의 유효성을 검사 할 수 없습니다.

틀 렸습니다. std::codecvt_utf8<char32_t>::length(start, end, max_lenght)배열의 유효한 바이트 수를 반환합니다.

당신은 길이를 알 수 없습니다

부분적으로 정확합니다. char32_t로 변환하여 결과의 ​​길이를 알아낼 수 있습니다. 실제 변환을 수행하지 않고 길이를 쉽게 찾을 수있는 방법 은 없습니다 (아래 참조). 나는 문자를 세어야 할 필요성이 (어떤 의미에서든) 드물게 발생한다고 말해야합니다.

바이트 단위 이외의 방식으로 std :: string을 반복 할 수 없습니다.

틀 렸습니다. std::codecvt_utf8<char32_t>::length(start, end, 1)UTF-8 "문자"(유니 코드 코드 단위)를 반복 할 수있는 가능성을 제공하고 물론 숫자를 결정할 수 있습니다 (문자 수를 계산하는 "쉬운"방법은 아니지만 방법입니다).

실제로 UTF-16을 지원하지 않습니다.

틀 렸습니다. 하나는 예를 들어 UTF-16으로 또는 UTF-16으로 변환 할 수 있습니다 std::codecvt_utf8_utf16<char16_t>. UTF-16으로 변환 한 결과는 UTF-16입니다. BMP에 국한되지 않습니다.

이러한 점을 보여주는 데모 .

다른 "당신은 할 수 없습니다"를 놓친 경우 지적 해 주시면 해결하겠습니다.

중요 부록 . 이러한 기능은 C ++ 17에서 더 이상 사용되지 않습니다 . 이것은 아마도 C ++의 향후 버전에서 사라질 것이라는 것을 의미합니다. 자신의 책임하에 사용하십시오. 원래 질문에 열거 된이 모든 것은 이제 표준 라이브러리 만 사용하여 (안전하게) 다시 수행 할 수 없습니다.

---

위의 분석이 정확합니까 아니면 내가 놓친 다른 유니 코드 지원 기능이 있습니까?

또한 UTF-8 리터럴의 완전한 실패가 누락되었습니다. 그것들은 완전히 관련되지 않은 (예 : 코드 페이지) 인코딩을 가질 수있는 좁은 문자 리터럴과 구별되는 유형이 없습니다. 그래서 그들은 C ++ 11에 심각한 새로운 기능을 추가하지 않았을뿐만 아니라, char*UTF-8이 좁은 것이 아니라면 a 가 플랫폼에 대한 좁은 문자열 인코딩에 있다고 가정 할 수도 없기 때문에 거의없는 것을 깨뜨 렸습니다. 문자열 인코딩. 그래서 여기서 새로운 기능은 " charUTF-8이 기존의 좁은 문자열 인코딩이 아닌 모든 플랫폼에서 기반 문자열을 완전히 깨뜨 렸습니다 ."입니다.

표준위원회는 지난 몇 년 동안 C ++를 빠른 속도로 발전시키는 환상적인 작업을 수행했습니다. 그들은 모두 똑똑한 사람들이며 위의 단점을 잘 알고 있다고 가정합니다. 유니 코드 지원이 C ++에서 여전히 열악한 것으로 알려진 특별한 이유가 있습니까?

위원회는 단순히 유니 코드에 대해 헛소리를하지 않는 것 같습니다.

또한 많은 유니 코드 지원 알고리즘은 그저 알고리즘입니다. 즉, 적절한 인터페이스를 제공하려면 범위가 필요합니다. 그리고 우리 모두는위원회가 원하는 wrt 범위를 파악할 수 없다는 것을 알고 있습니다. Eric Niebler의 새로운 Iterables가 기회가 될 수 있습니다.

앞으로 상황을 바로 잡기위한 제안을 아는 사람이 있습니까? isocpp.org에 대한 빠른 검색은 아무것도 드러내지 않는 것 같습니다.

내가 작성한 N3572가 있습니다. 하지만 브리스톨에 가서 그것을 발표했을 때 많은 문제가있었습니다.

첫째,위원회는 회의 사이에위원회 구성원이 작성하지 않은 제안에 대한 피드백을 귀찮게하지 않기 때문에 원하지 않는 디자인을 반복 할 때 수개월 간의 작업 손실이 발생합니다.

둘째, 그 당시 방황하는 사람이 투표 한 것으로 밝혀졌습니다. 즉, 논문 일정이 변경되면 주제에 대해 알거나 알지 못하는 비교적 무작위의 사람들이 있습니다. 또는 실제로는 무엇이든.

Thirdly, for some reason they don't seem to view the current situation as a serious problem. You can get endless discussion about how exactly optional<T>'s comparison operations should be defined, but dealing with user input? Who cares about that?

Fourthly, each paper needs a champion, effectively, to present and maintain it. Given the previous issues, plus the fact that there's no way I could afford to travel to other meetings, it was certainly not going to be me, will not be me in the future unless you want to donate all my travel expenses and pay a salary on top, and nobody else seemed to care enough to put the effort in.

ReferenceURL : https://stackoverflow.com/questions/25249498/unicode-in-c11