UTF-16을 유해한 것으로 간주해야합니까?

아마도 논란의 여지가있는 질문이 무엇인지 물어볼 것입니다. "가장 인기있는 인코딩 중 하나 인 UTF-16이 유해한 것으로 간주되어야합니까?"

왜이 질문을합니까?

UTF-16이 실제로 가변 길이 인코딩이라는 사실을 알고있는 프로그래머는 몇 명입니까? 이것은 대리 쌍으로 표현되는 코드 포인트가 두 개 이상의 요소를 취하는 것을 의미합니다.

알아; 많은 애플리케이션, 프레임 워크 및 API는 Java의 문자열, C #의 문자열, Win32 API, Qt GUI 라이브러리, ICU 유니 코드 라이브러리 등과 같은 UTF-16을 사용합니다. BMP 외부 문자 (두 UTF-16 요소를 사용하여 인코딩해야하는 문자)

예를 들어 다음 문자 중 하나를 편집하십시오.

• 𝄞 ( U + 1D11E ) 음악 기호 G 음자리표
• U ( U + 1D565 ) 수학적 이중 타격 소형 T
• U ( U + 1D7F6 ) 수학적 모노 피스 디지트 제로
• Character ( U + 2008A ) 한자

설치 한 글꼴에 따라 일부를 놓칠 수 있습니다. 이 문자들은 모두 BMP (Basic Multilingual Plane) 외부에 있습니다. 이러한 문자가 보이지 않으면 유니 코드 문자 참조 에서 해당 문자를 살펴볼 수도 있습니다.

예를 들어, Windows에서 이러한 문자를 포함하는 파일 이름을 작성하십시오. UTF-16을 사용하는 다른 응용 프로그램에서 어떻게 작동하는지 보려면 "백 스페이스"를 사용하여 이러한 문자를 삭제하십시오. 나는 몇 가지 테스트를했는데 결과가 매우 나쁘다.

• Opera에서 편집에 문제가 있습니다 (백 스페이스에서 2 번 누르기 삭제 필요).
• 메모장에서 올바르게 처리 할 수 ​​없습니다 (백 스페이스에서 두 번 눌러 삭제해야 함).
• 창 대화 상자에서 파일 이름 편집이 깨짐 (백 스페이스에서 2 번 누르기 필요)
• 모든 QT3 응용 프로그램은이를 처리 할 수 ​​없습니다 . 하나의 기호 대신 두 개의 빈 사각형을 표시하십시오.
• u'X'!=unicode('X','utf-16')X는 BMP 외부의 문자 인 경우 일부 플랫폼에서 직접 사용될 때 이러한 문자를 잘못 인코딩 합니다.
• Python 2.5 유니 코드 데이터는 파이썬이 UTF-16 유니 코드 문자열로 컴파일 될 때 이러한 문자에 대한 특성을 가져 오지 못합니다.
• StackOverflow는 유니 코드 문자로 직접 편집하면 텍스트에서 이러한 문자를 제거하는 것으로 보입니다 (이 문자는 HTML 유니 코드 이스케이프를 사용하여 표시됨).
• MaxLength로 제한되면 WinForms TextBox가 잘못된 문자열을 생성 할 수 있습니다 .

UTF-16을 사용하는 많은 응용 프로그램에서 이러한 버그를 쉽게 찾을 수 있습니다.

그렇다면 ... UTF-16이 해로운 것으로 간주되어야한다고 생각하십니까?

이것은 오래된 대답입니다. 최신 업데이트는 UTF-8 Everywhere 를
참조하십시오 .

의견 : 예, UTF-16은 유해한 것으로 간주해야합니다 . 그것이 존재하는 이유는 얼마 전에 widechar가 UCS-4가 될 것이라고 오도 된 믿음이 있었기 때문입니다.

UTF-8의 "anglo-centrism"에도 불구하고 텍스트에 유일하게 유용한 인코딩으로 간주되어야합니다. 프로그램의 소스 코드, 웹 페이지 및 XML 파일, OS 파일 이름 및 기타 컴퓨터 간 텍스트 인터페이스는 존재하지 않았어야한다고 주장 할 수 있습니다. 그러나 그들이 할 때 텍스트는 인간 독자만을위한 것이 아닙니다.

반면, UTF-8 오버 헤드는 지불해야하는 비용이 적지 만 상당한 이점이 있습니다. 로 문자열을 전달하는 알지 못하는 코드와의 호환성과 같은 장점 char*. 이것은 좋은 일입니다. UTF-8보다 SHUTTER 인 유용한 문자는 UTF-8보다 적습니다.

다른 모든 인코딩은 결국 죽을 것이라고 믿습니다. 이것은 MS-Windows, Java, ICU, python이 그것을 좋아하는 것으로 사용하지 않는 것을 포함합니다. 오랜 연구와 토론 끝에 회사 의 개발 규칙은 OS API 호출을 제외한 모든 곳에서 UTF-16을 사용하는 것을 금지했으며 이는 응용 프로그램의 성능의 중요성과 Windows를 사용한다는 사실에도 불구하고 마찬가지입니다. 항상 가정 된 UTFF8 std::string을 기본 UTF-16 으로 변환하기 위해 변환 기능이 개발되었으며 , Windows 자체 가 제대로 지원하지 않습니다 .

" 필요한 곳에 필요한 것을 사용하십시오 "라고 말하는 사람들에게는 모든 곳에서 동일한 인코딩을 사용하는 데 큰 이점이 있으며 그렇지 않으면 다른 이유가 없습니다. 특히 wchar_tC ++에 추가 하는 것은 실수 라고 생각하고 C ++ 0x에 유니 코드를 추가 한 것도 마찬가지입니다. STL 구현에서 요구해야 할 것은 모든 std::string또는 char*매개 변수가 유니 코드 호환으로 간주 된다는 것입니다.

또한 " 원하는 것을 사용하십시오 "접근 방식 에 위배 됩니다. 나는 그러한 자유의 이유가 없다. 텍스트의 주제에 대해 혼동이 많으므로이 모든 깨진 소프트웨어가 생깁니다. 위에서 말했듯이, 프로그래머는 UTF-8에 대한 적절한 합의에 따라 합의에 도달해야한다고 확신합니다. (나는 ASCII가 아닌 국가에서 왔으며 Windows에서 자랐으므로 마지막으로 종교적 근거를 기반으로 UTF-16을 공격 할 것으로 예상됩니다).

Windows에서 텍스트를 작성하는 방법과 컴파일 타임 검사 된 유니 코드 정확성, 사용 편의성 및 코드의 다중 플랫폼 향상을 위해 다른 사람들에게 권장하는 것에 대한 자세한 정보를 공유하고 싶습니다. 이 제안은 Windows에서 유니 코드를 사용하는 적절한 방법으로 일반적으로 권장되는 것과 다릅니다. 그러나 이러한 권장 사항에 대한 심도있는 연구를 통해 동일한 결론을 얻었습니다. 그래서 여기에 간다 :

• UTF-16을 허용하는 API에 인접한 점 이외의 곳을 사용 wchar_t하거나 std::wstring다른 곳에서 사용하지 마십시오 .
• 사용하지 마십시오 _T("")또는 L""UTF-16 리터럴은 (이러한 IMO UTF-16 중단의 일환으로, 표준에서주의해야한다).
• 유형, 함수 또는에 민감한 이들의 유도체 사용하지 마십시오 _UNICODE과 같은 상수, LPTSTR또는 CreateWindow().
• 그러나 WinAPI에 문자열을 자동 컴파일 _UNICODE하는 것을 피하기 위해 항상 정의char*
• std::strings그리고 char*어디 프로그램에서 UTF-8로 간주됩니다 (그렇지 않으면 말했다하지 않은 경우)
• std::stringchar * 또는 string literal을에 전달할 수 는 있지만 모든 문자열은 convert(const std::string &)입니다.

• widechars ( LPWSTR) 를 허용하는 Win32 함수 만 사용하십시오 . LPTSTR또는을 ( 를) 수락하는 사람은 절대 아닙니다 LPSTR. 이 방법으로 매개 변수를 전달하십시오.

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (정책은 아래의 변환 기능을 사용합니다.)

• MFC 문자열로 :

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Windows에서 파일, 파일 이름 및 fstream으로 작업 :

  • 가족 에게 인수를 전달 std::string하거나 const char*파일 이름을 지정 하지 마십시오 fstream. MSVC STL은 UTF-8 인수를 지원하지 않지만 비표준 확장명을 가지며 다음과 같이 사용해야합니다.

  • std::string로 다음 std::wstring과 Utils::Convert같이 인수를 변환하십시오 .

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    MSVC의 태도가 fstream바뀔 때 변환을 수동으로 제거해야합니다 .

  • 이 코드는 다중 플랫폼이 아니며 나중에 수동으로 변경해야 할 수도 있습니다
  • 자세한 정보는 fstream유니 코드 리서치 / 토론 사례 4215를 참조하십시오.
  • 비 UTF8 컨텐츠로 텍스트 출력 파일을 생성하지 마십시오
  • fopen()RAII / OOD 이유로 사용하지 마십시오 . 필요한 경우 _wfopen()위의 WinAPI 규칙을 사용하십시오 .

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

유니 코드 코드 포인트는 문자가 아닙니다! 때로는 글리프도 아닙니다 (시각적 형태).

몇 가지 예 :

• "ⅲ"와 같은 로마 숫자 코드 포인트. "iii"처럼 보이는 단일 문자입니다.
• "á"와 같은 악센트 문자는 단일 결합 문자 "\ u00e1"또는 문자 및 분리 분음 부호 "\ u0061 \ u0301"로 표시 될 수 있습니다.
• 그리스어 소문자 시그마와 같은 문자는 단어 위치의 중간 ( "σ")과 끝 ( "ς")에 대해 서로 다른 형식을 갖지만 검색의 동의어로 간주되어야합니다.
• 컨텍스트에 따라 시각적으로 표시되거나 표시되지 않을 수 있고 의미 검색을 위해 무시되는 유니 코드 임의 하이픈 U + 00AD.

유니 코드 편집 권한을 얻는 유일한 방법 은 전문가가 작성한 라이브러리 를 사용 하거나 전문가가되어 직접 작성하는 것입니다. 코드 포인트를 세고 있다면 죄의 상태에 살고 있습니다.

사용할 UTFF (Unicode Transformation Form)에 대한 간단한 경험 규칙이 있습니다.-저장 및 통신을위한 utf-8-데이터 처리를위한 utf-16-사용하는 대부분의 플랫폼 API가 utf-32 인 경우 utf-32 (UNIX 세계에서 일반적)

오늘날 대부분의 시스템은 utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt)을 사용합니다. 이 문서도 참조하십시오 : http://unicode.org/notes/tn12/

"유해한 UTF-16"으로 돌아가서, 나는 말할 것입니다.

대리자를 두려워하는 사람들 (유니 코드를 가변 길이 인코딩으로 변환한다고 생각하는 사람들)은 문자와 합자, 변형 선택자를 결합하여 문자와 유니 코드 코드 포인트 간의 매핑을 매우 복잡하게 만드는 다른 (더 큰) 복잡성을 이해하지 못합니다. , 제어 문자 등

http://www.siao2.com/2009/06/29/9800913.aspx 에서이 시리즈를 읽고 UTF-16이 쉬운 문제가되는 방법을보십시오.

네 그럼요.

왜? 그것은 코드 운동과 관련이 있습니다 .

Tom Christiansen 의 대규모 코퍼스 에서 이러한 코드 포인트 사용 통계 를 보면 BMP가 아닌 코드 포인트보다 큰 경우 8 비트 트랜스 BMP 코드 포인트가 몇 가지 순서로 사용됩니다.

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

TDD dictum : "테스트되지 않은 코드는 코드가 손상되었습니다"를 받아 "실행되지 않은 코드는 코드가 손상되었습니다"로 바꾸고 프로그래머가 BMP가 아닌 코드 포인트를 처리하는 빈도를 생각하십시오.

가변 너비 인코딩으로 UTF-16을 처리하지 않는 것과 관련된 버그는 UTF-8의 해당 버그보다 훨씬 눈에 띄지 않을 수 있습니다. 일부 프로그래밍 언어는 여전히 UCS-2 대신 UTF-16을 제공한다고 보장하지 않으며 일부 고급 프로그래밍 언어는 코드 포인트 대신 코드 단위에 대한 액세스를 제공합니다 (C조차도 wchar_t일부 플랫폼의 기능에 관계없이 를 사용하는 경우 코드 포인트 ).

UTF-16을 해로운 것으로 생각하면 unicode에 대해 더 많이 이해해야 한다고 말합니다 .

주관적인 질문에 대한 나의 의견을 표명 한 것에 대해 공감 당 했으므로 자세히 설명하겠습니다. UTF-16에 대해 귀찮게하는 것이 정확히 무엇입니까? 모든 것이 UTF-8로 인코딩 된 것을 선호합니까? UTF-7? 아니면 UCS-4는 어떻습니까? 물론 특정 응용 프로그램은 모든 문자 코드를 처리하도록 설계되지는 않았지만 특히 오늘날의 글로벌 정보 도메인에서 국제 경계 간 통신에 필요합니다.

그러나 실제로 UTF-16이 혼란 스럽거나 부적절하게 구현 될 수 있기 때문에 (유니 코드가 확실 할 수 있음) 유해한 것으로 간주되는 경우, 어떤 문자 인코딩 방법이 무해한 것으로 간주됩니까?

편집 : 명확하게 : 왜 표준의 부적절한 구현이 표준 자체의 품질을 반영한다고 생각합니까? 다른 사람들이 나중에 지적했듯이, 응용 프로그램이 도구를 부적절하게 사용한다고해서 도구 자체에 결함이있는 것은 아닙니다. 이 경우 "var 키워드가 유해한 것으로 간주 됨"또는 "스레딩이 유해한 것으로 간주 됨"과 같은 것을 말할 수 있습니다. 저는이 질문이 표준의 품질과 본질을 많은 프로그래머들이 표준을 올바르게 구현하고 사용하는 데 어려움을 겪고 있다고 생각합니다. 이는 유니 코드 자체가 아닌 유니 코드의 작동 방식에 대한 이해 부족에서 비롯된 것입니다.

Utf-16 인코딩에는 아무런 문제가 없습니다. 그러나 16 비트 단위를 문자로 취급하는 언어는 제대로 설계되지 않은 것으로 간주해야합니다. char항상 문자를 나타내는 것은 아닌 ' ' 라는 유형의 유형을 갖는 것은 상당히 혼란 스럽습니다. 대부분의 개발자는 문자 유형이 코드 포인트 또는 문자를 나타낼 것으로 예상하기 때문에 BMP (Byound BMP) 문자에 노출되면 많은 코드가 중단 될 수 있습니다.

그러나 utf-32를 사용한다고해서 각 32 비트 코드 포인트가 항상 문자를 나타내는 것은 아닙니다. 문자 결합으로 인해 실제 문자는 여러 코드 포인트로 구성 될 수 있습니다. 유니 코드는 결코 사소하지 않습니다.

BTW. Utf-8이 제공되는 문자가 8 비트가 될 것으로 예상되는 플랫폼 및 응용 프로그램에는 동일한 종류의 버그가있을 수 있습니다.

개인적으로 선택하는 것은 항상 UTF-8을 사용하는 것입니다. 거의 모든 것에 대한 Linux의 표준입니다. 많은 레거시 앱과 호환됩니다. 비 라틴 문자에 사용되는 여분의 공간은 다른 UTF 형식에 비해 매우 적은 오버 헤드가 있으며 라틴 문자에 대한 공간이 크게 절약됩니다. 웹상에서 라틴어는 최고가 될 것입니다. 그리고 원래 게시물의 주요 주장 중 하나를 해결하기 위해 거의 모든 프로그래머는 UTF-8에 때때로 멀티 바이트 문자가 있음을 알고 있습니다. 모든 사람이 이것을 올바르게 다루지는 않지만 UTF-16에 대해 말할 수있는 것 이상을 일반적으로 알고 있습니다. 그러나 물론 응용 프로그램에 가장 적합한 것을 선택해야합니다. 그렇기 때문에 처음에는 둘 이상이 있습니다.

고정 크기 기호를 사용하는 인코딩이 있습니다. 확실히 UTF-32를 의미합니다. 그러나 각 심볼 당 4 바이트는 너무 많은 공간을 낭비하는데 왜 일상적인 상황에서 사용합니까?

내 생각에, 대부분의 문제는 일부 소프트웨어가 유니 코드 표준에 뒤떨어졌지만 상황을 신속하게 시정하지 않았다는 사실에서 나타납니다. Opera, Windows, Python, Qt-UTF-16이 널리 알려 지거나 존재하기 전에 나타났습니다. 그러나 Opera, Windows 탐색기 및 메모장에서는 더 이상 BMP 외부의 문자 (더 이상 내 PC에서는)에 문제가 없음을 확인할 수 있습니다. 그러나 어쨌든 프로그램이 서로 게이트 쌍을 인식하지 못하면 UTF-16을 사용하지 않습니다. 이러한 프로그램을 처리 할 때 어떤 문제가 발생하더라도 UTF-16 자체와는 아무런 관련이 없습니다.

그러나 BMP 만 지원하는 레거시 소프트웨어의 문제는 다소 과장된 것 같습니다. BMP 외부의 문자는 매우 특정한 경우와 영역에서만 발생합니다. 유니 코드 공식 FAQ 에 따르면 , "동아시아 텍스트에서도 대리 쌍의 발생률은 평균적으로 모든 텍스트 스토리지의 1 % 미만이어야합니다". 물론 프로그램이 유니 코드를 준수하지 않기 때문에 BMP 외부의 문자 는 무시해서는 안되지만 대부분의 프로그램은 이러한 문자가 포함 된 텍스트를 다루기위한 것이 아닙니다. 그것이 그들이 그것을 지원하지 않으면 불쾌하지만 재앙이 아닌 이유입니다.

이제 대안을 고려해 봅시다. UTF-16이 존재하지 않으면 비 ASCII 텍스트에 적합한 인코딩이없고 UCS-2 용으로 작성된 모든 소프트웨어는 유니 코드 호환을 유지하도록 완전히 재 설계되어야합니다. 후자는 아마도 유니 코드 채택 속도를 늦출 것입니다. 또한 UTF-8이 ASCII와 관련하여 UCS-2에서 텍스트와의 호환성을 유지할 수 없었습니다.

이제 모든 레거시 문제를 제외하고 인코딩 자체에 대한 논쟁은 무엇입니까? 나는 오늘날 개발자들이 UTF-16이 가변 길이라는 것을 알지 못한다는 것을 의심합니다. 누군가가 가능한 문제로 복잡성을 지적했다면 UTF-16은 UTF-8보다 구문 분석하기가 훨씬 어렵습니다. 또한 UTF-16에서만 문자열 길이를 결정하는 것이 엉망이라고 생각하는 것은 잘못입니다. UTF-8 또는 UTF-32를 사용하는 경우 하나의 유니 코드 코드 포인트가 반드시 하나의 문자를 의미하지는 않습니다. 그 외에는 인코딩에 대해 실질적인 것이 없다고 생각합니다.

따라서 인코딩 자체가 유해하다고 생각하지 않습니다. UTF-16은 단순성과 컴팩트 함의 절충안 이며 필요한 곳에서 필요한 것을 사용하는 데 아무런 해 가 없습니다 . 경우에 따라 ASCII와의 호환성을 유지하고 UTF-8이 필요한 경우가 있습니다. 어떤 경우에는 한 표의 문자로 작업하고 UTF-16을 사용하여 공간을 절약하려는 경우가 있습니다. 길이 인코딩. 더 적절한 것을 사용하고 올바르게 수행하십시오.

수년간의 Windows 국제화 작업은 특히 동아시아 언어에서 작동했을 수 있지만, 프로그램 내부에서 문자열을 표현하려면 UTF-16, 일반 텍스트와 같은 문서의 네트워크 또는 파일 저장에는 UTF-8을 사용합니다. UTF-16은 일반적으로 Windows에서 더 빠르게 처리 될 수 있으므로 Windows에서 UTF-16을 사용하는 것이 가장 큰 이점입니다.

UTF-16으로의 도약으로 국제 텍스트를 처리하는 일반 제품의 적절성이 크게 향상되었습니다. 대리 쌍을 고려해야 할 경우 (기본적으로 삭제, 삽입 및 줄 바꿈)가 필요한 경우는 극히 드물며 평균 사례는 대부분 직선입니다. 또한 JIS 변형과 같은 이전 인코딩과 달리 UTF-16은 서로 게이트 쌍을 매우 좁은 범위로 제한하므로 검사가 실제로 빠르고 앞뒤로 작동합니다.

물론, 올바르게 인코딩 된 UTF-8에서도 거의 빠릅니다. 그러나 대리 쌍을 두 개의 UTF-8 시퀀스로 잘못 인코딩하는 손상된 UTF-8 응용 프로그램도 많이 있습니다. 따라서 UTF-8은 구원을 보장하지 않습니다.

IE는 일반적으로 UTF-8 페이지에서 내부 UTF-16 표현으로 변환하더라도 2000 년 이후부터 대리 쌍을 합리적으로 잘 처리합니다. 파이어 폭스에서도 제대로 작동한다고 확신하므로 Opera가하는 일에 관심이 없습니다.

UTF-32 (일명 UCS4)는 공간이 많이 필요하기 때문에 대부분의 응용 프로그램에서 무의미합니다. 따라서 스타터가 아닙니다.

UTF-8은 확실한 방법이며, 고성능 랜덤 액세스가 필요한 알고리즘에서 내부 사용을 위해 UTF-32를 사용할 수 있습니다 (그러나 문자 결합은 무시합니다).

UTF-16 및 UTF-32 (및 LE / BE 변형) 모두 엔디안 문제가 있으므로 외부에서 사용해서는 안됩니다.

UTF-16? 확실히 해 롭습니다. 여기에 내 소금 알갱이가 있지만 프로그램에는 텍스트에 대해 정확히 세 가지 인코딩이 허용됩니다.

• ASCII : 더 나은 것을 감당할 수없는 저수준의 물건 (예 : 마이크로 컨트롤러)을 다룰 때
• UTF8 : 파일과 같은 고정 너비 미디어에 저장

• 정수 코드 포인트 ( "CP"?) : 프로그래밍 언어 및 플랫폼에 편리한 가장 큰 정수의 배열입니다 (낮은 해상도의 한계에서 ASCII로 감소). 구형 컴퓨터의 경우 int32이고 64 비트 주소 지정이있는 모든 컴퓨터의 경우 int64 여야합니다.

• 분명히 레거시 코드에 대한 인터페이스는 이전 코드가 올바르게 작동하기 위해 필요한 인코딩을 사용합니다.

유니 코드 는 최대 0x10FFFF (1,114,112 코드)까지 코드 포인트를 정의하며, 문자열 / 파일 이름 등을 다루는 다국어 환경에서 실행되는 모든 응용 프로그램은이를 올바르게 처리해야합니다.

Utf-16 : 1,112,064 코드 만 포함합니다. 유니 코드 끝의 것은 15-16면 (개인 사용 영역)에서 온 것이지만 Utf-16 개념을 깨는 것을 제외하고는 앞으로 더 이상 성장할 수 없습니다 .

Utf-8 : 이론적으로 2,216,757,376 코드를 다룹니다. 유니 코드 코드 의 현재 범위는 최대 4 바이트 시퀀스로 표시 될 수 있습니다. 바이트 순서 문제 가 없으며 ascii와 "호환"됩니다.

Utf-32 : 이론적으로 2 ^ 32 = 4,294,967,296 코드를 다룹니다. 현재는 가변 길이로 인코딩되지 않았으며 앞으로는 없을 것입니다.

이러한 사실은 자명하다. Utf-16 의 일반적인 사용을 주장하는 것을 이해하지 못합니다 . 가변 길이 인코딩 (인덱스로 액세스 할 수 없음), 현재에도 전체 유니 코드 범위 를 다루는 데 문제가 있으며 바이트 순서를 처리해야합니다. 다른 장소들. 다중 플랫폼 코드를 작성할 때 Utf-8을 기본적으로 사용하고 플랫폼에 따라 엔드 포인트에서만 변환하는 것이 좋습니다 (이미 제안한 바와 같이). 인덱스를 통한 직접 액세스가 필요하고 메모리에 문제가없는 경우 Utf-32를 사용해야합니다.

주요 문제는 Windows Unicode = Utf-16을 다루는 많은 프로그래머 가 가변 길이 인코딩이라는 사실을 알거나 무시하지 못한다는 것입니다.

그것이 일반적으로 * nix 플랫폼에있는 방식은 꽤 훌륭합니다 .c 문자열 (char *)은 Utf-8 인코딩 으로 해석되고 넓은 c 문자열 (wchar_t *)은 Utf-32 로 해석됩니다 .

이것을 목록에 추가하십시오.

제시된 시나리오는 간단합니다 (원래보다 여기에 제시 할 때 더 간단합니다!). 1. WinForms TextBox는 비어있는 Form에 있습니다. MaxLength는 20으로 설정되어 있습니다.

2. 사용자가 텍스트 상자에 입력하거나 텍스트를 붙여 넣을 수 있습니다.

3. TextBox에 입력하거나 붙여 넣은 내용에 관계없이 20으로 제한되지만 20을 넘어 서면 텍스트가 비프 음으로 울립니다 (여기서 YMMV; 나는 그 효과를 내기 위해 사운드 구성을 변경했습니다!).

4. 작은 텍스트 패킷이 흥미 진진한 모험을 시작하기 위해 다른 곳으로 보내집니다.

이제 이것은 쉬운 시나리오이며, 여가 시간에 누구나 쓸 수 있습니다. 방금 지루하고 전에 시도한 적이 없기 때문에 WinForms를 사용하여 여러 프로그래밍 언어로 직접 작성했습니다. 그리고 여러 실제 언어로 된 텍스트를 사용하면 전 세계의 다른 사람들보다 키보드 레이아웃이 더 많기 때문에 유선으로 연결됩니다.

나는 지루함을 개선하는 데 도움을주기 위해 Magic Carpet Ride 라는 이름을 지었다 .

이것은 가치가있는 것으로 작동하지 않았습니다.

대신 매직 카펫 라이드 폼에 다음 20 자를 입력했습니다 .

0123401234012340123 𠀀

어 오.

마지막 문자는 U + 20000이며, 유니 코드의 첫 번째 확장 B 표의 문자입니다 (일명 U + d840 U + dc00).

그리고 지금 우리는 볼 게임이 있습니다.

TextBox.MaxLength가 이야기 할 때

텍스트 상자에 수동으로 입력 할 수있는 최대 문자 수를 가져 오거나 설정합니다.

그것이 실제로 의미하는 것은

텍스트 상자에 수동으로 입력 할 수있는 UTF-16 LE 코드 단위의 최대 수를 가져 오거나 설정하고 다른 사람에게만 집착하는 언어 적 문자 개념으로 cutesy 게임을 시도하는 문자열에서 살아있는 쓰레기를 무자비하게 잘라냅니다. 카플란 동료가 불쾌감을 줄 것입니다 (더 많은 것을 꺼내야합니다!).

나는 시도하고 문서가 .... 업데이트 것에 대해 볼 수 있습니다
내 기억 정기 독자 UTF-16에 UCS-2 시리즈의 단순한 개념 내 불행주의 할 것이다 TextBox.MaxLength을 그리고 최소한이 경우에 처리하는 방법 드라코 니안 동작이 잘못된 시퀀스를 생성하는 경우, .Net Framework의 다른 부분에서

• System.Text.EncoderFallbackException : 인덱스 0에서 유니 코드 문자 \ uD850을 지정된 코드 페이지로 변환 할 수 없습니다. *

내 동료 Dan Thompson 이하 고있는 것처럼 .Net Framework의 다른 곳 에서이 문자열을 전달하면 예외입니다.

이제 전체 UCS-2에서 UTF-16 시리즈 까지 많은 사람들이 접근 할 수 없을 것입니다.
그러나 TextBox.Text가 System.String을 생성하지 않을 것으로 기대하는 것이 합리적이지 않습니다. .Net Framework의 다른 부분이 발생하지 않습니까? 내 말은, 컨트롤에 어떤 이벤트 형태의 기회가있어서 다가오는 잘림에 대해 더 똑똑한 유효성 검사-컨트롤 자체가 신경 쓰지 않는 유효성 검사를 쉽게 추가 할 수있는 위치를 알려줍니다. 나는이 펑크 컨트롤이 예기치 않은 예외를 발생시켜 응용 프로그램을 조잡한 서비스 거부로 종료하도록 클래스 화 할 수 있다면 보안 문제를 일으킬 수있는 안전 계약을 위반하고 있다고 말할 것입니다. 왜 WinForms 프로세스, 방법 또는 알고리즘 또는 기술이 유효하지 않은 결과를 생성해야합니까?

출처 : Michael S. Kaplan MSDN 블로그

UTF-16이 유해하다고 반드시 말할 필요는 없습니다. 우아하지는 않지만 GB18030은 GB2312와 UTF-8은 ASCII와 마찬가지로 UCS-2와의 하위 호환성을 제공합니다.

그러나 Microsoft와 Sun이 약 16 비트 문자로 거대한 API를 구축 한 후 미드 스트림에서 유니 코드 구조를 근본적으로 변경하는 것은 해로 웠습니다. 변화에 대한 인식을 확산시키지 못한 것은 더욱 해 롭습니다.

UTF-16은 처리와 공간 사이 에서 가장 좋은 절충안 이므로 대부분의 주요 플랫폼 (Win32, Java, .NET)에서 문자열의 내부 표현에 사용합니다.

UTF-16의 요점을 이해하지 못했습니다. 공간 효율적으로 표현하려면 UTF-8을 사용하십시오. 텍스트를 고정 길이로 처리하려면 UTF-32를 사용하십시오. 둘 다 원하지 않으면 UTF-16을 사용하십시오. 더 나쁜 것은 UTF-16의 모든 공통 (기본 다국어 평면) 문자가 단일 코드 포인트에 적합하기 때문에 UTF-16이 고정 길이라고 가정하는 버그는 미묘하고 찾기가 쉽지 않지만 UTF-8을 사용하면 국제화를 시도하자마자 코드가 빠르고 크게 실패합니다.

_{아직 댓글을 달 수 없기 때문에이 글에 대한 답변을 게시했습니다 utf8everywhere.org. 다른 스택 교환에 대한 평판이 충분하기 때문에 자동으로 주석 권한을 얻지 못하는 것은 부끄러운 일입니다.}

이것은 의견에 대한 의견으로 사용됩니다. 예, UTF-16은 해로운 답변 으로 간주되어야합니다 .

약간의 수정 :

실수로 UTF-8 char*을 ANSI 문자열 버전의 Windows-API 함수 로 전달하지 못하게하려면 UNICODE, not을 정의해야합니다 _UNICODE. _UNICODE같은지도 기능 _tcslen에 wcslen,하지 MessageBox에 MessageBoxW. 대신 UNICODE정의는 후자를 처리합니다. 증명을 위해 다음은 MS Visual Studio 2005의 WinUser.h헤더 에서 가져온 것입니다 .

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

최소한이 오류는에 수정되어야합니다 utf8everywhere.org.

제안:

어쩌면이 안내서에는 Wide- 문자열 버전의 데이터 구조를 명시 적으로 사용하는 예가 포함되어있어 놓치거나 잊어 버리기가 쉽지 않습니다. 와이드 스트링 버전의 함수를 사용하는 것 외에도 와이드 스트링 버전의 데이터 구조를 사용하면 실수로 그러한 함수의 ANSI 스트링 버전을 호출 할 가능성이 줄어 듭니다.

예제의 예 :

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

누군가 UCS4와 UTF-32는 동일하다고 말했다. 아니,하지만 네가 무슨 뜻인지 알아 그러나 그중 하나는 다른 하나의 인코딩입니다. 나는 그들이 처음부터 엔디안을 지정한다고 생각했기 때문에 엔디안 전투도 여기서 일어나지 않을 것입니다. 그들이 오는 것을 보지 못했습니까? 누군가가 6 바이트의 원래 사양을 따르지 않는 한 UTF-8 이상은 모든 곳에서 동일합니다.

UTF-16을 사용하는 경우 멀티 바이트 문자 처리를 포함 해야 합니다. 2N을 바이트 배열로 인덱싱하여 N 번째 문자로 이동할 수 없습니다. 걸어가거나 문자 색인이 있어야합니다. 그렇지 않으면 당신은 버그를 작성했습니다.

C ++의 현재 초안 사양은 UTF-32 및 UTF-16이 리틀 엔디안, 빅 엔디안 및 지정되지 않은 변형을 가질 수 있다고 말합니다. 정말? 유니 코드가 모든 사람들이 처음부터 리틀 엔디안을해야한다고 명시했다면 모두 더 단순했을 것입니다. (빅 엔디안도 괜찮 았을 것입니다.) 대신, 어떤 사람들은 한 가지 방법으로, 다른 한 사람은 그것을 구현했지만, 우리는 아무것도 아닌 것에 대해 침묵에 갇혀 있습니다. 때로는 소프트웨어 엔지니어가 당혹 스럽기도합니다.

개발자가 충분히주의를 기울이면 해롭지 않다고 생각합니다.
그리고 그들이 잘 알고 있다면이 거래를 받아 들여야합니다.

일본의 소프트웨어 개발자로서 UCS-2가 충분히 크고 공간을 제한하면 로직을 단순화하고 런타임 메모리를 줄일 수 있으므로 UCS-2 제한에서 utf-16을 사용하면 충분합니다.

코드 포인트와 바이트가 비례한다고 가정하는 파일 시스템 또는 기타 응용 프로그램이 있으므로 원시 코드 포인트 번호가 고정 크기 저장소에 적합하도록 보장 할 수 있습니다.

UCS-2 를 파일 이름 스토리지 인코딩으로 지정하는 NTFS 및 VFAT 가 그 예입니다 .

이 예제가 UCS-4를 지원하기 위해 실제로 확장하려는 경우 어쨌든 모든 것에 utf-8 사용에 동의 할 수는 있지만 고정 길이는 다음과 같은 장점이 있습니다.

1. 길이별로 크기를 보장 할 수 있습니다 (데이터 크기와 코드 포인트 길이는 비례합니다)
2. 해시 조회에 인코딩 번호를 사용할 수 있습니다
3. 비 압축 데이터의 크기는 합리적입니다 (utf-32 / UCS-4와 비교)

임베디드 / 임베디드 디바이스에서도 메모리 / 프로세싱 파워가 저렴할 경우, 캐시 누락이나 페이지 폴트 및 추가 메모리 사용으로 인해 디바이스 속도가 약간 느려질 수 있지만 가까운 시일 내에 발생하지는 않을 것입니다 ...

"가장 인기있는 인코딩 중 하나 인 UTF-16이 유해한 것으로 간주되어야합니까?"

아마도 가능하지만 대안이 반드시 훨씬 더 나은 것으로 간주되어서는 안됩니다.

근본적인 문제는 글리프 (glyph), 문자, 코드 포인트 및 바이트 시퀀스에 대한 다양한 개념이 있다는 것입니다. 정규화 라이브러리를 사용하더라도 이들 각각의 매핑은 쉽지 않습니다. (예를 들어, 라틴어 기반 스크립트로 작성된 유럽 언어의 일부 문자는 단일 유니 코드 코드 포인트로 작성되지 않습니다. 이는 복잡성의 끝에서 더 간단합니다!) 이것이 의미하는 바는 모든 것을 정확하게 얻는 것이 매우 놀랍습니다. 어려운; 기괴한 버그가 예상됩니다. 여기에서 버그에 대해 신음하는 대신 관련 소프트웨어 관리자에게 알려주십시오 .

예를 들어 UTF-8과 달리 UTF-16이 유해한 것으로 간주 될 수있는 유일한 방법은 BMP 외부에서 코드 포인트를 인코딩하는 방법이 다릅니다 (대리인 한 쌍으로). 코드가 코드 포인트별로 액세스하거나 반복하려면 차이를 인식해야합니다. OTOH는 "문자"를 가정하는 기존 코드의 상당 부분이 항상 2 바이트 수량에 맞을 수 있다는 것을 의미합니다. 다시 말해, 적어도 제대로 처리되지 않은 캐릭터 를 보게 될 것입니다!

나는 당신의 질문을 머리에 돌리고 유니 코드의 모든 빌어 먹을 유해한 것으로 간주해야하며 모든 사람들은 (지난 20 년 동안) 내가 본 곳을 제외하고는 8 비트 인코딩을 사용해야한다고 말합니다. 다양한 ISO 8859 인코딩과 Cyrillic 및 EBCDIC 제품군에 사용 된 전체 세트를 혼동 할 수 있습니다. 다른 나라의 오해들 사이에서 그렇게 타협하지 않은 경우에만.