Comments 22
Поддержка Юникода в Windows появилась раньше, чем в большинстве остальных операционных систем.Вызывающе неверная информация: раньше всего появилась в Linux-е (сразу всё в комплексе локаль, приложения, библиотеки и ФС и т.д.), а в Windows гораздо позже, неполноценно и криво (на ФС не было).
Прям уж «вызывающе неверная»! На самом деле «появилась раньше, чем в большинстве» никак не противоречит «раньше всего появилась в Линуксе». «Большинство» же не значит «все остальные». И да, когда конкретно поддержка Юникода в Линуксе появилась?
Вызывающе неверная информация: раньше всего появилась в Linux
Если имеется ввиду использование utf-8 в Linux то это теоретически невозможно.
utf-8 в том виде который мы ее знаем была разработана в рамках работы над ОС Plan-9,
поэтому естественно первая ОС с utf-8 это Plan-9 и в Linux utf-8 могла появиться только позже Plan-9.
В линуксе поддержка Юникода оставала от Windows. utf-8 они использовали, так как было огромное количество программ, рассчитанных на 8-битные кодировки.
В чём отставала?! В линуксе давно на UTF-8 сидел, когда в винде (параллельно стояла) ещё и в помине не было, может возможность была, но в приложениях, ни в локали, ни ФС (и сейчас кажись нету) не было.
Windows 95 — все они использовали кодировку UCS-2 — Windows 95 не использовала кодировку UCS-2, т.к. у неё не было никаких w-функций, только A функции (CreateWindowsW VS CreateWindowsA).
Ну тащем-та это не совсем так, для 95/98/ME была такая штука под названием Microsoft Layer for Unicode (MSLU), в ней были w-версии всех этих функций.
Если совсем строго, то еще в Win 3.x вместе с родным Win16 API было еще некоторое подмножество Win32 (Win32S = Win32 Subset), в котором A-функции шли вместе с W-функциями, только вместо имплементаций у W-функций там были заглушки, возвращающие ошибки.
95/98/ME хоть и имели формально полную Win32-подсистему, но большинство W-функций там тоже шло заглушками. Большинство, но не все. Некоторые функции (их довольно мало) для работы с ресурсами (e.g. EnumResourceNamesW), командной строкой (e.g. GetCommandLineW), диалоговыми сообщениями (e.g. MessageBoxW) имели рабочую реализацию, также были доступны вспомогательные функции для конвертации W-строк в A-строки (MultiByteToWideChar, WideCharToMultiByte) с кодированием MBCS (Multibyte Character Set). В 98 добавили еще чуток функций (lstrlenW, lstrcpyW, lstrcatW). Полноценная поддержка Win32 через MSLU (так же известная как unicows) для них появилась только в 2001 году.
95/98/ME хоть и имели формально полную Win32-подсистему, но большинство W-функций там тоже шло заглушками. Большинство, но не все. Некоторые функции (их довольно мало) для работы с ресурсами (e.g. EnumResourceNamesW), командной строкой (e.g. GetCommandLineW), диалоговыми сообщениями (e.g. MessageBoxW) имели рабочую реализацию, также были доступны вспомогательные функции для конвертации W-строк в A-строки (MultiByteToWideChar, WideCharToMultiByte) с кодированием MBCS (Multibyte Character Set). В 98 добавили еще чуток функций (lstrlenW, lstrcpyW, lstrcatW). Полноценная поддержка Win32 через MSLU (так же известная как unicows) для них появилась только в 2001 году.
Unicode != wchar_t.
Зачем, вообще, использовать указатель на wchar? char вполне нормально работает и для UTF-8, и для UTF-32. А гарантировать, что один видимый символ = один символ юникода даже UTF-32 не может.
Так-то оно так, но… насколько я понимаю, изначально wchar_t вводился для того, чтобы работали штуки типа str[i]. Это не юникод, и вообще не какой-то стандарт, а просто некое такое компиляторозависимое представление символов, что все символы имеют фиксированную длину в байтах.
> char вполне нормально работает и для UTF-8, и для UTF-32
char, если он 8-битный, не работает для UTF-32 так, как надо: нельзя прочитать/записать один кодовый пункт целиком, нельзя проверять на NUL ограниченные им строки, нельзя простым ++ или — перейти на следующий/предыдущий пункт.
Для этого всего нужен char32_t вместо char.
> А гарантировать, что один видимый символ = один символ юникода даже UTF-32 не может.
Не может. Но обращение по тому размеру, в котором хранится, упрощает большинство операций с текстом.
char, если он 8-битный, не работает для UTF-32 так, как надо: нельзя прочитать/записать один кодовый пункт целиком, нельзя проверять на NUL ограниченные им строки, нельзя простым ++ или — перейти на следующий/предыдущий пункт.
Для этого всего нужен char32_t вместо char.
> А гарантировать, что один видимый символ = один символ юникода даже UTF-32 не может.
Не может. Но обращение по тому размеру, в котором хранится, упрощает большинство операций с текстом.
нельзя проверять на NUL ограниченные им строкиКакие проблемы? NUL не может появиться внутри другого символа, это всегда отдельный байт. То же самое с поиском любой подстроки в строке — неоднозначности исключены.
нельзя простымНо и не сильно это сложно:++или--перейти на следующий/предыдущий пункт
if (*ptr++ & 0x80) while ((*ptr & 0xC0) == 0x80) ptr++;
За прошедшие к тому моменту шесть лет для Windows было написано огромное множество программ объёмом в миллиарды строк.
Ого! Миллиарды :)
Пора уже забыть про TCHAR и, соответственно, _tprintf, и, хуже того, _tmain.
Благо, в 2019 наконец можно использовать нормальные char в Windows: docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
А где ссылки из статьи? А то есть [1], [2], а самого списка ссылок нету.
Sign up to leave a comment.
Печальная судьба спецификаторов формата функции printf для символов Юникода в Visual C++