Чи слід вважати UTF-16 шкідливим?

Я збираюся задати, напевно, досить суперечливе запитання: "Чи слід вважати шкідливим одне з найпопулярніших кодувань, UTF-16?"

Чому я задаю це питання?

Скільки програмістів усвідомлює той факт, що UTF-16 насправді кодує змінну довжину? Під цим я маю на увазі, що є кодові точки, які, представлені сурогатними парами, займають більше одного елемента.

Я знаю; велика кількість програм, фреймворків та API використовують UTF-16, такі як String Java, St # Cring's String, API Win32, бібліотеки Qt GUI, бібліотека Unicode ICU тощо. Однак при всьому цьому існує багато основних помилок при обробці символів поза BMP (символи, які слід закодувати за допомогою двох елементів UTF-16).

Наприклад, спробуйте відредагувати одного з цих символів:

• 𝄞 ( U + 1D11E ) МУЗИЧНА СИМВОЛ G CLEF
• 𝕥 ( U + 1D565 ) МАТЕМАТИЧНИЙ ДВОЙНОСТІЙНИЙ МАЛИЙ Т
• 𝟶 ( U + 1D7F6 ) МАТЕМАТИЧНИЙ МОНОСАП ДИЗИГ ЗЕРО
• 𠂊 ( U + 2008A ) Хан символів

Ви можете пропустити деякі, залежно від того, які шрифти ви встановили. Ці символи знаходяться поза межами BMP (базової багатомовної площини). Якщо ви не можете бачити цих символів, ви також можете спробувати їх переглянути в довідці про символи Unicode .

Наприклад, спробуйте створити імена файлів у Windows, які включають ці символи; спробуйте видалити цих символів за допомогою "зворотної області", щоб побачити, як вони поводяться в різних програмах, які використовують UTF-16. Я зробив кілька тестів, і результати дуже погані:

• Opera має проблеми з їх редагуванням (видаліть необхідні 2 натискання на задній простір)
• Блокнот не може правильно поводитися з ними (видаліть необхідні 2 натискання на задній простір)
• Редагування імен файлів у діалогових вікнах Вікна (з видаленням потрібно 2 натискання на задній області)
• Усі програми QT3 не можуть з ними боротися - показати два порожні квадрати замість одного символу.
• Python неправильно кодує таких символів при використанні безпосередньо u'X'!=unicode('X','utf-16')на деяких платформах, коли X символом поза BMP.
• Python 2.5 unicodedata не зможе отримати властивості для таких символів, коли python компілюється з рядками Unicode UTF-16.
• Здається, StackOverflow видаляє цих символів з тексту, якщо їх редагувати безпосередньо як символи Unicode (ці символи відображаються за допомогою втечі HTML Unicode).
• WinForms TextBox може генерувати недійсну рядок при обмеженні MaxLength.

Здається, такі помилки надзвичайно легко знайти в багатьох додатках, які використовують UTF-16.

Отже ... Ви вважаєте, що UTF-16 слід вважати шкідливим?

Це стара відповідь.
Дивіться UTF-8 скрізь для останніх оновлень.

Думка: Так, UTF-16 слід вважати шкідливим . Сама причина його існування полягає в тому, що деякий час тому існувало помилкове переконання, що широкоформатний апарат стане таким, яким зараз є UCS-4.

Незважаючи на "англоцентризм" UTF-8, його слід вважати єдиним корисним кодуванням тексту. Можна стверджувати, що вихідні коди програм, веб-сторінок та XML-файлів, назви файлів ОС та інших текстових інтерфейсів комп'ютер-комп'ютер ніколи не мали існувати. Але коли вони це роблять, текст не лише для людських читачів.

З іншого боку, накладні витрати UTF-8 - це невелика ціна, яку потрібно платити, хоча вона має значні переваги. Такі переваги, як сумісність з необізнаним кодом, який просто передає рядки char*. Це чудова річ. У UTF-16 мало корисних символів, які ШОРТІші, ніж у UTF-8.

Я вірю, що всі інші кодування з часом загинуть. Це означає, що MS-Windows, Java, ICU, python перестають використовувати його як своє улюблене. Після довгих досліджень та обговорень конвенції про розробку в моїй компанії забороняють використовувати UTF-16 в будь-якому місці, крім дзвінків API OS, і це, незважаючи на важливість продуктивності в наших програмах та те, що ми використовуємо Windows. Функції перетворення були розроблені для перетворення завжди припущених UTF8 std::strings в початкові UTF-16, які сама Windows не підтримує належним чином .

Людям, які кажуть " використовувати те, що потрібно там, де це потрібно ", я кажу: є величезна перевага в тому, щоб використовувати одне і те ж кодування скрізь, і я не бачу достатніх причин робити інше. Зокрема, я думаю, що додавання wchar_tдо C ++ було помилкою, а також доповнення Unicode до C ++ 0x. Що потрібно вимагати від реалізації STL, але це те, що кожен std::stringабо char*параметр буде вважатися сумісним з unicode.

Я також проти підходу " використовувати те, що ти хочеш ". Я не бачу причин для такої свободи. На тему тексту достатньо плутанини, внаслідок чого все це зламане програмне забезпечення. Сказавши вище, я переконаний, що програмісти повинні нарешті досягти консенсусу щодо UTF-8 як єдиного правильного шляху. (Я родом з країни, що не говорить про ассію, і виріс у Windows, тому я останній раз очікував нападу на UTF-16 за релігійними ознаками).

Мені хотілося б поділитися додатковою інформацією про те, як я створюю текст у Windows, а також що я рекомендую всім іншим для перевірки правильністю унікоду, під час компіляції, простоти використання та кращої багатоплатформованості коду. Пропозиція істотно відрізняється від того, що зазвичай рекомендується як належний спосіб використання Unicode у Windows. Однак поглиблене дослідження цих рекомендацій призвело до того ж висновку. Отже, ось що:

• Не використовуйте та wchar_tні std::wstringв якому іншому місці, крім сусідньої точки для API, що приймають UTF-16.
• Не використовуйте _T("")або L""UTF-16 літерали (Ці ІМО повинні бути вилучені зі стандарту, як частина знецінення UTF-16).
• Не використовуйте типи, функції та їх похідні, які чутливі до _UNICODEконстанти, наприклад, LPTSTRабо CreateWindow().
• Тим не менш, _UNICODEзавжди визначено, щоб уникнути передачі char*рядків WinAPI беззвучно збирати
• std::stringsі char*будь-де в програмі вважаються UTF-8 (якщо не сказано інше)
• Усі мої рядки є std::string, хоча ви можете передати char * або string буквально convert(const std::string &).

• використовувати лише функції Win32, які приймають широкі версії ( LPWSTR). Ніколи тих, хто приймає 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);
  

• Робота з файлами, назви файлів і fstream у Windows:

  • Ніколи не передайте аргументи 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 щодо unicode.
  • Ніколи не створюйте текстові вихідні файли, що не містять вмісту 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
}

Кодові точки Unicode - це не символи! Іноді це навіть не гліфи (зорові форми).

Деякі приклади:

• Римські цифрові кодові точки типу "ⅲ". (Єдиний символ, схожий на "iii".)
• Наголошені символи типу "á", які можуть бути представлені як єдиний об'єднаний символ "\ u00e1", або символ та розділений діакритичний "\ u0061 \ u0301".
• Символи на зразок грецької малої сигми, які мають різні форми для середнього ("σ") та кінця ("ς") позицій слів, але які слід вважати синонімами пошуку.
• Unicode дискретний дефіс U + 00AD, який може бути або не може бути візуально відображений, залежно від контексту, і який ігнорується для семантичного пошуку.

Єдиний спосіб отримати право редагування Unicode - це використовувати бібліотеку, написану експертом , або стати експертом і написати її самостійно. Якщо ви просто рахуєте кодові точки, ви живете в стані гріха.

Існує просте правило про те, яку форму перетворення Unicode (UTF) використовувати: - utf-8 для зберігання та комунікації - utf-16 для обробки даних - ви можете перейти з utf-32, якщо більшість використовуваних API платформи використовується utf-32 (поширений у світі UNIX).

Більшість систем сьогодні використовують utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). Також дивіться цей документ: http://unicode.org/notes/tn12/

Повернувшись до "UTF-16 як шкідливого", я б сказав: точно не.

Люди, які бояться сурогатів (думаючи, що вони перетворять Unicode в кодування змінної довжини), не розуміють інших (набагато більших) складностей, які роблять відображення між символами та кодовою точкою Unicode дуже складним: поєднання символів, лігатур, селекторів варіацій , контрольні символи тощо.

Просто прочитайте цю серію тут http://www.siao2.com/2009/06/29/9800913.aspx і подивіться, як UTF-16 стає легкою проблемою.

Так, абсолютно.

Чому? Це пов'язано з використанням коду .

Якщо ви подивитесь на ці статистичні дані про використання кодової точки у великому корпусі Тома Крістіанасена, ви побачите, що коди-точки через 8-бітну BMP використовуються в декількох порядках, якщо їх величина перевищує кодові точки, що не є 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: "Неперевірений код пошкоджений код", і перефразовуйте його як "необмежений код зламаний код", і подумайте, як часто програмістам доводиться мати справу з кодовими точками, що не належать до BMP.

Помилки, пов'язані з тим, що не мають справи з UTF-16 як кодуванням змінної ширини, набагато частіше залишаються непоміченими, ніж еквівалентні помилки в UTF-8 . Деякі мови програмування все ще не гарантують вам UTF-16 замість UCS-2, а деякі так звані мови програмування високого рівня пропонують доступ до кодових одиниць замість кодових точок (навіть C повинен надавати вам доступ до кодові точки, якщо ви використовуєте wchar_t, незалежно від того, що можуть робити деякі платформи).

Я б припустив, що мислення UTF-16 може вважатися шкідливим, говорить про те, що вам потрібно краще зрозуміти, що стосується юнікоду .

Оскільки мене не вистачає за те, щоб я висловив свою думку щодо суб'єктивного питання, дозвольте мені детальніше. Що саме вас турбує щодо UTF-16? Ви б хотіли, якби все було закодовано в UTF-8? UTF-7? А як щодо UCS-4? Звичайно, певні програми не розроблені для обробки символу коду вічносинхронних символів, але вони необхідні, особливо в сучасній глобальній інформаційній області, для зв'язку між міжнародними кордонами.

Але насправді, якщо ви вважаєте, що UTF-16 слід вважати шкідливим, оскільки він заплутаний або може бути неправильно реалізований (безумовно, може бути і unicode), то який метод кодування символів вважатиметься нешкідливим?

EDIT: Для уточнення: навіщо вважати неправильне впровадження стандарту відображенням якості самого стандарту? Як згодом зазначали інші, лише те, що програма використовує інструмент неналежним чином, не означає, що сам інструмент є несправним. Якби це було так, ми, ймовірно, могли б сказати такі речі, як "ключове слово var вважається шкідливим" або "нарізка вважається шкідливою". Я думаю, що питання плутає якість та характер стандарту з труднощами, з якими стикаються багато програмістів у його впровадженні та використанні належним чином, що, як мені здається, випливає більше з їхнього нерозуміння того, як працює unicode, а не від unicode себе.

З кодуванням Utf-16 немає нічого поганого. Але мови, які розглядають 16-бітні одиниці як символи, мабуть, вважаються погано розробленими. Мати тип з назвою " char", який не завжди представляє символ, є досить заплутаним. Оскільки більшість розробників очікує, що тип char представляє кодову точку або символ, велика кількість коду, ймовірно, зламається, коли вони потрапляють на символи, пов'язані з BMP.

Однак зауважте, що навіть використання utf-32 не означає, що кожна 32-розрядна кодова точка завжди буде представляти символ. Завдяки поєднанню символів фактичний символ може складатися з декількох кодових точок. Unicode ніколи не є тривіальним.

До речі. Напевно, існує той самий клас помилок з платформами та додатками, які очікують, що символи будуть 8-бітовими, які подаються Utf-8.

Мій особистий вибір - завжди використовувати UTF-8. Це стандарт для Linux майже для всього. Він сумісний із багатьма застарілими програмами. Існує дуже мінімальний накладний витрата з точки зору додаткового простору, який використовується для не латинських символів порівняно з іншими форматами UTF, і є значна економія місця для латинських символів. В Інтернеті латинські мови панують на вищому рівні, і я думаю, що вони стануть в осяжному майбутньому. І щоб вирішити один з головних аргументів у початковому дописі: майже кожен програміст знає, що UTF-8 іноді матиме багатобайтові символи. Не всі мають справу з цим правильно, але вони зазвичай знають, що більше, ніж можна сказати для UTF-16. Але, звичайно, вам потрібно вибрати найбільш відповідний для вашої заявки. Ось чому в першу чергу більше одного.

Ну, є кодування, яке використовує символи фіксованого розміру. Я звичайно маю на увазі UTF-32. Але 4 байти на кожен символ - це занадто багато витраченого простору, чому б ми використовували його в повсякденних ситуаціях?

На мій погляд, більшість проблем виникає через те, що деяке програмне забезпечення відстало від стандарту Unicode, але не вдалося виправити ситуацію. Opera, Windows, Python, Qt - всі вони з'явилися до того, як UTF-16 став широко відомим або навіть з'явився на світ. Я можу підтвердити, що в Opera, Windows Explorer та Notepad більше немає проблем з персонажами поза BMP (принаймні, на моєму ПК). Але в будь-якому випадку, якщо програми не розпізнають сурогатних пар, вони не використовують UTF-16. Які б проблеми не виникали при роботі з такими програмами, вони не мають нічого спільного з самим UTF-16.

Однак я вважаю, що проблеми застарілого програмного забезпечення лише з підтримкою BMP дещо перебільшені. Персонажі поза BMP зустрічаються лише у дуже конкретних випадках та областях. Згідно з офіційним поширеним запитанням Unicode , "навіть у тексті східної Азії частота пар сурогатних пар повинна в середньому бути значно меншою за 1% від усіх сховищ тексту". Звичайно, символами поза BMP не слід нехтувати, оскільки програма не відповідає Unicode, інакше, але більшість програм не призначені для роботи з текстами, що містять такі символи. Ось чому, якщо вони цього не підтримують, це неприємно, але не катастрофа.

Тепер розглянемо альтернативу. Якби UTF-16 не існувало, у нас не було б кодування, яке добре підходить для тексту, що не належить до ASCII, і все програмне забезпечення, створене для UCS-2, повинно бути повністю перероблене, щоб залишатися сумісним з Unicode. Останнє, швидше за все, лише уповільнить прийняття Unicode. Крім того, ми б не змогли зберегти сумісність з текстом у UCS-2, як це робить UTF-8 стосовно ASCII.

Тепер, відклавши всі старі проблеми, які аргументи проти самого кодування? Я дуже сумніваюся, що розробники сьогодні не знають, що UTF-16 має різну довжину, це написано скрізь, котрі страйкують у Вікіпедії. UTF-16 набагато менш складний для розбору, ніж UTF-8, якщо хтось вказав на складність як можливу проблему. Крім того, невірно думати, що легко визначити довжину рядка тільки в UTF-16. Якщо ви використовуєте UTF-8 або UTF-32, ви все одно повинні знати, що одна точка коду Unicode не обов'язково означає один символ. Крім цього, я не думаю, що є щось суттєве проти кодування.

Тому я не думаю, що саме кодування слід вважати шкідливим. UTF-16 - це компроміс між простотою та компактністю, і немає ніякої шкоди у використанні того, що потрібно там, де це потрібно . У деяких випадках вам потрібно залишатися сумісним з ASCII, і вам потрібен UTF-8, в деяких випадках ви хочете працювати з роботою з ідеографами Хана і заощаджувати простір за допомогою UTF-16, в деяких випадках вам потрібні універсальні представлення символів, які призначають фіксовану- кодування довжини Використовуйте те, що є більш підходящим, просто зробіть це правильно.

Багаторічна робота з інтернаціоналізації Windows, особливо на східноазіатських мовах, могла зіпсувати мене, але я схиляюся до UTF-16 для внутрішнього програмного представлення рядків та UTF-8 для мережевого чи зберігання файлів документів, що нагадують непростий текст. Зазвичай UTF-16 може оброблятися швидше у Windows, тому головна перевага використання UTF-16 у Windows.

Зростання стрибка до UTF-16 значно покращило адекватність середньої продукції, що обробляє міжнародний текст. Є лише кілька вузьких випадків, коли сурогатні пари потрібно розглядати (вилучення, вставки та розриви рядків, в основному), а середній випадок - це переважно прямий прохід. І на відміну від більш ранніх кодувань, таких як варіанти JIS, UTF-16 обмежує сурогатні пари в дуже вузькому діапазоні, тому перевірка дійсно швидка і працює вперед і назад.

Зрозуміло, це приблизно так само швидко і в правильно закодованому UTF-8. Але також є багато зламаних програм UTF-8, які неправильно кодують сурогатні пари як дві послідовності UTF-8. Тож UTF-8 також не гарантує порятунку.

IE обробляє сурогатні пари досить добре з 2000 року, хоча це, як правило, перетворює їх зі сторінок UTF-8 у внутрішнє представлення UTF-16; Я впевнений, що Firefox теж правильно це зрозумів, тому мені не дуже важливо, що робить Opera.

UTF-32 (він же UCS4) є безглуздим для більшості застосунків, оскільки він настільки вимогливий до простору, тому він є майже нестандартним.

UTF-8, безумовно, може пройти, можливо, супроводжується UTF-32 для внутрішнього використання в алгоритмах, які потребують високопродуктивного випадкового доступу (але ігнорує комбінування символів).

Як UTF-16, так і UTF-32 (а також їх варіанти LE / BE) страждають від проблем з ендіазністю, тому їх ніколи не слід застосовувати зовнішньо.

UTF-16? безумовно шкідливий. Тут просто моє зерно солі, але в програмі є рівно три прийнятних коду для тексту:

• ASCII: при роботі з речами низького рівня (наприклад, мікроконтролерами), які не можуть дозволити собі нічого кращого
• UTF8: зберігання на носіях фіксованої ширини, таких як файли

• цілі кодові точки ("CP"?): масив найбільших цілих чисел, зручних для вашої мови програмування та платформи (розпадається на ASCII в межах малих курортів). Повинно бути int32 на старих комп'ютерах і int64 на будь-якому, що має 64-бітну адресацію.

• Очевидно, що інтерфейси застарілого коду використовують те, що кодування потрібно для того, щоб старий код працював правильно.

Unicode визначає кодові точки до 0x10FFFF (1,114,112 кодів), всі програми, що працюють у багатомовній середовищі, що мають рядки / назви файлів тощо, повинні правильно поводитися з цим.

Utf-16 : охоплює лише 1112,064 коди. Хоча ті, що знаходяться в кінці Unicode, є із літаків 15-16 (зона приватного користування). Він не може більше зростати в майбутньому, окрім порушення концепції Utf-16 .

Utf-8 : теоретично охоплює 2,216,757,376 кодів. Поточний діапазон кодів Unicode може бути представлений максимально 4-байтною послідовністю. Він не страждає від проблеми байт-порядку , він "сумісний" з ascii.

Utf-32 : теоретично охоплює 2 ^ 32 = 4,294,967,296 кодів. Наразі вона не кодується змінної довжини і, мабуть, не буде в майбутньому.

Ці факти самі пояснюють. Я не розумію, щоб виступати за загальне використання Utf-16 . Він кодований змінної довжини (не можна отримати доступ до індексу), він має проблеми з охопленням всього діапазону Unicode навіть в даний час, порядок байтів повинен оброблятися і т. Д. Я не бачу жодної переваги, окрім того, що він використовується в Windows і деяких інші місця. Навіть незважаючи на те, що під час написання багатоплатформового коду, можливо, краще використовувати Utf-8 на власному рівні та здійснювати перетворення лише в кінцевих точках залежно від платформи (як уже пропонується). Коли необхідний прямий доступ за індексом і пам'ять не є проблемою, слід використовувати Utf-32 .

Основна проблема полягає в тому, що багато програмістів, що працюють з Windows Unicode = Utf-16, навіть не знають і не ігнорують той факт, що він кодується змінної довжини.

Те, як це зазвичай в * nix платформі, досить добре, c рядки (char *) інтерпретуються як закодовані Utf-8 , широкі c рядки (wchar_t *) інтерпретуються як Utf-32 .

Додайте це до списку:

Представлений сценарій простий (ще простіший, оскільки я його тут представлю, ніж це було спочатку!): 1. WinForms TextBox сидить у формі, порожній. У нього встановлений MaxLength на 20 .

2. Користувач вводить у TextBox або, можливо, вставляє текст у нього.

3. Незалежно від того, що ви вводите або вставляєте в TextBox, вам обмежено 20, хоча це буде співчутливо подавати звуковий сигнал на текст поза 20 (YMMV тут; я змінив звукову схему, щоб надати мені такий ефект!).

4. Маленький пакет тексту надсилається кудись інше, щоб розпочати захоплюючу пригоду.

Зараз це простий сценарій, і кожен може написати це у вільний час. Я просто написав це на декількох мовах програмування за допомогою WinForms, тому що мені було нудно і ніколи раніше не пробував. І з текстом на декількох власних мовах, тому що я провідний таким чином і маю більше розкладок на клавіатурі, ніж, можливо, хтось у всьому вигадливому Всесвіті.

Я навіть назвав форму Magic Carpet Ride , щоб допомогти покращити нудьгу.

Це не вийшло, для чого це варто.

Тому замість цього я вписав наступні 20 символів у свою форму Magic Carpet Ride :

0123401234012340123 𠀀

Ой-ой.

Останнім персонажем є U + 20000, перший ідеограф розширення B Unicode (він же U + d840 U + dc00, його близьким друзям, яких він не соромиться відхиляти, як би перед ним) ....

А зараз у нас гра з м'ячем.

Бо коли TextBox.MaxLength говорить про

Отримує або встановлює максимальну кількість символів, які можна ввести вручну в текстове поле.

що це насправді означає

Отримує або встановлює максимальну кількість одиниць коду UTF-16 LE, які можна вручну ввести у текстове поле і безжально вирізати живу лайну з будь-якого рядка, який намагається грати в люб'язні ігри з мовним символом, що лише хтось одержимий як що Каплан знайде образливим (боже, йому потрібно вийти більше!).

Я спробую ознайомитись із оновленням документа ....
Регулярні читачі, які пам’ятають мою серію UCS-2 до UTF-16 , відзначать моє нещастя спрощеним поняттям TextBox.MaxLength і тим, як він повинен працювати як мінімум у цьому випадку там, де його драконівська поведінка створює протизаконну послідовність, та, яку можуть відкинути інші частини .Net Framework

• System.Text.EncoderFallbackException: Неможливо перевести символ Unicode \ uD850 в індексі 0 на вказану кодову сторінку. *

виняток, якщо ви передаєте цей рядок деінде в .Net Framework (як це робив мій колега Ден Томпсон).

Тепер добре, можливо, повну серію UCS-2 до UTF-16 багато хто недосяжний.
Але чи не розумно очікувати, що TextBox.Text не створить System.Stringце не спричинить закидання ще однієї частини .Net Framework? Я маю на увазі, це не так, як є шанс у вигляді якоїсь події на елементі управління, яка повідомляє про майбутнє скорочення, де ви можете легко додати розумнішу перевірку - перевірку, яку сам контроль не проти зробити. Я б сказав, що цей панк-контроль порушує договір безпеки, що навіть може призвести до проблем із безпекою, якщо ви зможете спричинити несподівані винятки для припинення роботи програми як грубий вид відмови у наданні послуги. Чому будь-який процес чи метод, алгоритм чи методика WinForms повинні давати недійсні результати?

Джерело: Блог Майкла С. Каплана MSDN

Я б не обов'язково говорив, що UTF-16 є шкідливим. Це не елегантно, але він виконує свою мету зворотної сумісності з UCS-2, як GB18030 і GB2312, а UTF-8 - з ASCII.

Але внести кардинальні зміни в структуру Unicode в середині потоку, після того як Microsoft і Sun створили величезні API з 16-бітових символів, було шкідливим. Неспроможність поширити обізнаність про зміни була більш шкідливою.

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, не _UNICODE. _UNICODEкарти функція , як _tcslenдо wcslen, а НЕ MessageBoxдо MessageBoxW. Натомість UNICODEдефініція піклується про останнє. На доказ, це з WinUser.hзаголовка MS Visual Studio 2005 :

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

Як мінімум, цю помилку слід виправити utf8everywhere.org.

Пропозиція:

Можливо, посібник повинен містити приклад явного використання широкопоточної версії структури даних, щоб зробити його менш легким пропустити / забути. Використання Wide-string версій структур даних, крім використання Wide-string версій функцій, робить ще меншою ймовірність того, що хтось випадково викликає 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 були однаковими. Не так, але я знаю, що ти маєш на увазі. Однак одна з них - це кодування іншої. Я б хотів, щоб вони думали вказати витривалість з першого, щоб у нас не було битви за ендіазність і тут. Хіба вони не бачили, що це прийде? Принаймні, UTF-8 скрізь однаковий (якщо тільки хтось не дотримується оригінальної специфікації з 6-байтовими).

Якщо ви використовуєте UTF-16, вам потрібно включити обробку для багатобайтових символів. Ви не можете перейти до N-го символу, індексуючи 2N в байтовий масив. Ви повинні ходити по ньому або мати показники символів. Інакше ви написали помилку.

Поточна специфікація проекту C ++ говорить про те, що UTF-32 та UTF-16 можуть мати варіанти малої ендіанської, великої ендіанської та не визначеної. Дійсно? Якби Unicode вказав, що всі повинні були робити мало ендіан з самого початку, тоді все було б простіше. (Мені б добре було і з біг-ендіаном.) Натомість, деякі люди реалізували це в один бік, а в інші - і тепер ми зациклювались ні на що. Іноді соромно бути інженером програмного забезпечення.

Я не думаю, що це шкідливо, якщо розробник буде досить обережним.
І вони повинні прийняти цю торгівлю, якщо вони теж добре знають.

Як японський розробник програмного забезпечення, я вважаю, що UCS-2 досить великий, а обмеження простору, очевидно, спрощує логіку та зменшує обсяг пам’яті, тому використання utf-16 під обмеженням UCS-2 досить добре.

Існує файлова система чи інша програма, яка передбачає, що кодові точки та байти пропорційні, так що гарантовано, що номер необмеженої кодової точки може бути придатним до певного сховища фіксованого розміру.

Одним із прикладів є NTFS та VFAT із зазначенням UCS-2 як кодування для зберігання імен файлів.

Якщо цей приклад дійсно хоче поширити на підтримку UCS-4, я б погодився використовувати utf-8 для всього, але все-таки фіксована довжина має хороші моменти, такі як:

1. може гарантувати розмір за довжиною (розмір даних та довжина кодової точки пропорційний)
2. може використовувати номер кодування для пошуку хешу
3. нестиснені дані мають достатній розмір (порівняно з utf-32 / UCS-4)

У майбутньому, коли потужність пам’яті / обробки дешева навіть у будь-яких вбудованих пристроях, ми можемо прийняти, що пристрій дещо повільний для додаткових пропусків кешу або помилок сторінки та додаткового використання пам’яті, але, мабуть, це станеться найближчим часом…

"Чи слід вважати шкідливим одне з найпопулярніших кодувань, UTF-16?"

Цілком можливо, але альтернативи не слід розглядати як набагато кращі.

Фундаментальне питання полягає в тому, що існує багато різних понять про: гліфи, символи, кодові точки та послідовності байтів. Відображення між ними нетривіальним, навіть за допомогою бібліотеки нормалізації. (Наприклад, деякі символи європейських мов, написані на латинській скрипті, не записуються з єдиною кодовою точкою Unicode. І це в більш простому кінці складності!) Це означає, що правильно все виправдати досить дивовижно важкий; слід очікувати химерних помилок (і замість того, щоб просто стогнати про них тут, повідомте керівникам відповідного програмного забезпечення).

Єдиний спосіб, коли UTF-16 можна вважати шкідливим на відміну, скажімо, від UTF-8, це те, що він має інший спосіб кодування точок коду поза BMP (як пара сурогатів). Якщо код бажає отримати доступ або повторити його по кодовій точці, це означає, що він повинен знати про різницю. Щодо OTOH, це означає, що значна частина існуючого коду, що передбачає "символи", завжди може бути вписана в двобайтову кількість - досить поширене, якщо неправильне припущення - може принаймні продовжувати працювати, не будуючи це все. Іншими словами, принаймні ви побачите тих персонажів, з якими не керується правильно!

Я б повернув ваше запитання на голову і сказав, що весь проклятий шебанг Unicode слід вважати шкідливим, і кожен повинен використовувати 8-бітове кодування, за винятком я бачив (за останні 20 років), куди це призводить: жахливо плутанина через різні кодування ISO 8859, плюс весь набір з них, що використовуються для кирилиці, і комплект EBCDIC, і ... ну, Unicode за всі свої помилки перемагає це. Якби це був не такий неприємний компроміс між непорозуміннями різних країн.