То, что вы озвучили, - это первое что приходит на ум, когда читаешь любые "глубокие" математические теории из областей высшей математики". Но если вдуматься, принципы работы процессора, памяти, протоколов передачи данных (TCP, например), логика распределения ресурсов в многозадачных ОС - это далеко не эмпирические вещи, а вещи, подкрепленные очень глубокой математикой. Алгоритмы сжатия (картинок, видео, звуков) - тоже одна сплошная математика. Полно математики в 3D рендеринге. Можно, конечно, считать, что всё это не для простых смертных, но прогресс нужен и его не остановить в любом случае.
Ага, взял какой-нибудь просто символ из этого стандарта, правильно "просто закодировал его допустим в UTF-8", хочешь "просто" нарисовать этот символ на экране красивым встроенным в винду шрифтом, УПС, а в шрифте этот символ не завезли. Вот тебе и "просто стандарт" :)
На самом деле все эти споры - это война стандартов, на которую во многом влияет ниша применения инструмента/языка и тулчейна в целом. Сказать по правде - Unicode избыточно переусложненный стандарт, а то, что поверх юникода есть еще все вот эти UTF-8,16,32 - добавляет палок в колёса. Тем, кому не нужна интернациональность или нужна, но в ограниченном варианте (например только родной и английский язык), все эти заморочки "как закодировать смайлик какашку" - лишняя PITA (pain in the ass). В винде столько API/ABI, где UTF-16 гвоздями прибит на веки вечные...Не уверен, что в ближайшие 10-20 лет это как-то упростится...
Ладно, ладно, неправильно использовал термин. Имел в виду что "кодовая точка юникода не влезла в тип Char 16 бит и была закодирована "другой длиной, длиннее чем Char"
>> Символы всегда в UTF-32, строки — в UTF-8.
Это где так? В каком конкретном языке? Вот впервые столкнулся вообще с упоминанием использования UTF-32 вообще в принципе. Ну что же, идея конечно может и неплохая, но опять же всё это настолько нишевое.. Да, наверно в Интернете и в веб сервисах распространено. А вот в Windows, в кровавом энтерпрайзе? Подумайте о СУБД. Хранить в базе UTF-8 ? Ну фиг знает. Думаю Oracle и MS SQL не одобряют. Postgres и MySQL может и одобряют, но они "уроженцы *Nix", а в никсах, сами понимаете, всё сделано не как для людей.
> Это, по идее, хорошая задача для функции из стандартной библиотеки.
Я понимаю, но это был просто пример. Можно же придумать и другие операции со строками, более "частные". В целом, если ориентироваться именно на UTF-8 (во всех строках), то весь код надо писать немного иначе, не как привычно для Pascal/Delphi. Хотя возможно я просто слишком консервативен.
> А его разве не само приложение себе включает?
Да, приложение. Но Microsoft как всегда немного перемудрили, и у них в недрах региональных настроек еще появилась опция галка "Beta: Use Unicode UTF-8 for worldwide language support" (с не очень понятными последствиями для приложения).
Windows graphics device interface (GDI) doesn't currently support setting the activeCodePage property per process. Instead, GDI defaults to the active system codepage. To configure your app to render UTF-8 text via GDI, go to Windows Settings > Time & language > Language & region > Administrative language settings > Change system locale, and check Beta: Use Unicode UTF-8 for worldwide language support. Then reboot the PC for the change to take effect.
Про "ввела возможность использования UTF-8 как ANSI кодировки в WinAPI" я это читал, но это такой костыль и затычка, что это никто не использует и если этот режим активировать, то бОльшая часть виндового софта сломается.
А насчет полноценной работы с UTF-8 и юникодом в целом, это ж вообще на редкость как неудобно.
Вот надо, например, написать функцию, которая делит строку на части по набору символов разделителей.
В "неполноценном" UTF-16 варианте это что-то в духе function Split(s: string; Delims: TArray<Char>): TArray<string> и можно просто проверять каждый элемент Char в строке на вхождение в Delims. А если это "полноценный" UTF-8 вариант, то уже пришлось бы писать что-то в духе function Split(s: UTF8String; Delims: TArray<UTF8String>) и уже сильно усложнится логика проверки что "очередной символ строки s, который может быть в том числе суррогатной парой, входит в набор Delims, который также может состоять как из "простых символов", так и из символов, представленных суррогатными парами". Когда я начинаю представлять, что эти нюансы пришлось бы учитывать в огромной куче мест, работающих со строками, становится очень неприятно.
Отчасти вы правы. По факту UTF-16 строка в Delphi представляется как набор "элементов" с типом Char, каждый из которых имеет размер 2 байта. Если спросить у строки "длину строку" (Length(s)), она вернет количество таких "элементов". Это не символы с точки зрения кодовых точек Unicode, если могут использоваться суррогатные пары. Но длина строки в байтах (для сохранения в файл или поток) всегда строго равна Length(s) * SizeOf(Char) (т.е. количеству "элементов" строки умноженному на 2 байта).
При этом в наших приложениях суррогатные пары не используются (точнее не используются сами те символы юникода, для кодирования которых нужно более 1 кодовой точки), т.е. не может быть так, чтобы один символ был закодирован более чем одним "элементом строки".
Но Pascal сейчас не в моде, а разработчиков, знакомых с ним — мало (к слову, на мой взгляд, причина провала — то, что дефолтные строки не в UTF8, и только это).
Дефолтные строки в Delphi уже 15 лет как UTF-16 (как вобщем-то и в API винды, под которую Delphi всё-таки позиционируется в первую очередь). UTF-8 строки тоже есть, но с ними работать гораздо менее удобно, т.к. например чтобы записать UTF-8 строку в файл или в поток (Stream), надо вычислять "а сколько ж она байт занимает" вместо того чтобы просто взять длину строки, умноженную на кол-во байт на 1 символ.
Вообще, всё это к популярности Delphi имеет мало отношения.
Вроде на прошлой неделе как раз была статья про переход на YDB ? Или это касалось не такси? Если всё-таки такси, то очередность статей не очень понятная - сначала написали, что отказались от Postgre в пользу YDB, а теперь описываете, как всё устроено на Postgre.
UPDATE: а, ой, это Хабр мне подсунул старую статью! А я решил, что она сегодняшняя, каюсь!
То, что вы озвучили, - это первое что приходит на ум, когда читаешь любые "глубокие" математические теории из областей высшей математики". Но если вдуматься, принципы работы процессора, памяти, протоколов передачи данных (TCP, например), логика распределения ресурсов в многозадачных ОС - это далеко не эмпирические вещи, а вещи, подкрепленные очень глубокой математикой. Алгоритмы сжатия (картинок, видео, звуков) - тоже одна сплошная математика. Полно математики в 3D рендеринге. Можно, конечно, считать, что всё это не для простых смертных, но прогресс нужен и его не остановить в любом случае.
Мне рекламировали vscode + плагин roocode для подключения агентик ИИ в кач-ве альтернативы всяким там Клодам и кодексам. Еще не пробовал
>> Юникод - это просто стандарт
Ага, взял какой-нибудь просто символ из этого стандарта, правильно "просто закодировал его допустим в UTF-8", хочешь "просто" нарисовать этот символ на экране красивым встроенным в винду шрифтом, УПС, а в шрифте этот символ не завезли. Вот тебе и "просто стандарт" :)
Спасибо за конкретику.
На самом деле все эти споры - это война стандартов, на которую во многом влияет ниша применения инструмента/языка и тулчейна в целом. Сказать по правде - Unicode избыточно переусложненный стандарт, а то, что поверх юникода есть еще все вот эти UTF-8,16,32 - добавляет палок в колёса. Тем, кому не нужна интернациональность или нужна, но в ограниченном варианте (например только родной и английский язык), все эти заморочки "как закодировать смайлик какашку" - лишняя PITA (pain in the ass). В винде столько API/ABI, где UTF-16 гвоздями прибит на веки вечные...Не уверен, что в ближайшие 10-20 лет это как-то упростится...
Ладно, ладно, неправильно использовал термин. Имел в виду что "кодовая точка юникода не влезла в тип Char 16 бит и была закодирована "другой длиной, длиннее чем Char"
>> Символы всегда в UTF-32, строки — в UTF-8.
Это где так? В каком конкретном языке? Вот впервые столкнулся вообще с упоминанием использования UTF-32 вообще в принципе. Ну что же, идея конечно может и неплохая, но опять же всё это настолько нишевое.. Да, наверно в Интернете и в веб сервисах распространено. А вот в Windows, в кровавом энтерпрайзе? Подумайте о СУБД. Хранить в базе UTF-8 ? Ну фиг знает. Думаю Oracle и MS SQL не одобряют. Postgres и MySQL может и одобряют, но они "уроженцы *Nix", а в никсах, сами понимаете, всё сделано не как для людей.
Кстати в C++ тоже никакой "нормальной" поддержки UTF-8 на уровне языка нет :)
> Это, по идее, хорошая задача для функции из стандартной библиотеки.
Я понимаю, но это был просто пример. Можно же придумать и другие операции со строками, более "частные". В целом, если ориентироваться именно на UTF-8 (во всех строках), то весь код надо писать немного иначе, не как привычно для Pascal/Delphi. Хотя возможно я просто слишком консервативен.
> А его разве не само приложение себе включает?
Да, приложение. Но Microsoft как всегда немного перемудрили, и у них в недрах региональных настроек еще появилась опция галка "Beta: Use Unicode UTF-8 for worldwide language support" (с не очень понятными последствиями для приложения).
Вот тут:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
про эту галку написано так:
Windows graphics device interface (GDI) doesn't currently support setting the activeCodePage property per process. Instead, GDI defaults to the active system codepage. To configure your app to render UTF-8 text via GDI, go to Windows Settings > Time & language > Language & region > Administrative language settings > Change system locale, and check Beta: Use Unicode UTF-8 for worldwide language support. Then reboot the PC for the change to take effect.
Про "ввела возможность использования UTF-8 как ANSI кодировки в WinAPI" я это читал, но это такой костыль и затычка, что это никто не использует и если этот режим активировать, то бОльшая часть виндового софта сломается.
А насчет полноценной работы с UTF-8 и юникодом в целом, это ж вообще на редкость как неудобно.
Вот надо, например, написать функцию, которая делит строку на части по набору символов разделителей.
В "неполноценном" UTF-16 варианте это что-то в духе function Split(s: string; Delims: TArray<Char>): TArray<string> и можно просто проверять каждый элемент Char в строке на вхождение в Delims. А если это "полноценный" UTF-8 вариант, то уже пришлось бы писать что-то в духе function Split(s: UTF8String; Delims: TArray<UTF8String>) и уже сильно усложнится логика проверки что "очередной символ строки s, который может быть в том числе суррогатной парой, входит в набор Delims, который также может состоять как из "простых символов", так и из символов, представленных суррогатными парами". Когда я начинаю представлять, что эти нюансы пришлось бы учитывать в огромной куче мест, работающих со строками, становится очень неприятно.
Отчасти вы правы. По факту UTF-16 строка в Delphi представляется как набор "элементов" с типом Char, каждый из которых имеет размер 2 байта. Если спросить у строки "длину строку" (Length(s)), она вернет количество таких "элементов". Это не символы с точки зрения кодовых точек Unicode, если могут использоваться суррогатные пары. Но длина строки в байтах (для сохранения в файл или поток) всегда строго равна Length(s) * SizeOf(Char) (т.е. количеству "элементов" строки умноженному на 2 байта).
При этом в наших приложениях суррогатные пары не используются (точнее не используются сами те символы юникода, для кодирования которых нужно более 1 кодовой точки), т.е. не может быть так, чтобы один символ был закодирован более чем одним "элементом строки".
Дефолтные строки в Delphi уже 15 лет как UTF-16 (как вобщем-то и в API винды, под которую Delphi всё-таки позиционируется в первую очередь). UTF-8 строки тоже есть, но с ними работать гораздо менее удобно, т.к. например чтобы записать UTF-8 строку в файл или в поток (Stream), надо вычислять "а сколько ж она байт занимает" вместо того чтобы просто взять длину строки, умноженную на кол-во байт на 1 символ.
Вообще, всё это к популярности Delphi имеет мало отношения.
Понял :)
Подпись под фото лучше обрезать или переписать, чтобы она не вводила в заблуждение
Step 3.5 и Mimo V2 ещё. И qwen 3.6
Поскольку 90+ процентов обычных людей не знакомы с этим языком, достаточно было бы обзорной статьи с простыми примерами.
C/2026 A1 (MAPS) 4 апреля упадёт на солнце, а t короны по прежнему стабильна
https://github.com/teorth/erdosproblems/wiki/AI-contributions-to-Erdős-problems
https://habr.com/ru/articles/994934/
Вроде на прошлой неделе как раз была статья про переход на YDB ? Или это касалось не такси? Если всё-таки такси, то очередность статей не очень понятная - сначала написали, что отказались от Postgre в пользу YDB, а теперь описываете, как всё устроено на Postgre.
UPDATE: а, ой, это Хабр мне подсунул старую статью! А я решил, что она сегодняшняя, каюсь!
Мощь )
Так вроде в статье ничего не было про добавление кода в ванильный постгрес, статья-то не про Postgres, а про Pangolin