to post messages and comments.

В каких ОСах и браузерах юникодовый з̶а̶ч̶ё̶р̶к̶н̶у̶т̶ы̶й̶ ̶т̶е̶к̶с̶т̶ отрисовывается нормально.
Должен ли шрифт эту фичу поддерживать, чтобы нормально получилось.
В винде наблюдаю, что как правило больше на подчёркивание похоже.

«Поддержка» четырёхбайтовых строк в Delphi реализована посредством объявления type UCS4Char = type LongWord; и type UCS4String = array of UCS4Char;
…а также функций для конвертации между WideString и UCS4String, а в юникодных Delphi — также между UnicodeString и UCS4String. Поскольку UCS4Char — это не символ, а замаскированное число, в теле программы такие литералы так просто не попишешь. Хотя, конечно, можно приводить тип постоянно. UCS4String — это вообще не строка, а динамический массив, и плюс на нём не сработает. Также для массивов не работает COW. Для строк Delphi автоматически добавляет в конец нулевые байты в нужном количестве на случай, если эту строку захотят послать в ущербные сишные API, вот она как раз бы и подошла сразу, а для динамического массива беззнаковых чисел такого делаться не будет, поэтому это делают функции конвертации. Соответственно, Length вернёт либо 0 для пустой строки, либо длину, на 1 большую настоящей длины. Так что даже если вдруг для динамических массивов заработает плюс, он будет косячить. В array of const и Variant, я так понимаю, UCS4String тоже просто так не влезет.

Но больше всего у меня горит от того, что в неюникодных Delphi функции конвертации поддерживают только BMP. Семёрка, похоже, если и сдохнет, то только со всеми Delphi вообще. Embarcadero так и не приложили усилий, чтобы это могло быть иначе.

Обнаружил, что GNAT уже давно автоматически использует UTF-8 как однобайтовую кодировку, а не ANSI (управляется переменной среды GNAT_CODE_PAGE). В смысле, использует её для I/O, в частности, имён файлов, где и был камень преткновения, поскольку у таких модулей, как Ada.Directories, аргументы в однобайтовых String, а не двухбайтовых Wide_String или четырёхбайтовых Wide_Wide_String. Кодировка исходников управляется -gnatW, в юникодных кодировках можно давать идентификаторам имена не на латинице и писать строковые литералы, но такие литералы должны быть достаточно широкими, потому что String по стандарту жёстко Latin-1, а всё русское требует минимум Wide_String. Есть, правда, вариант, при котором компилятор думает, что он парсит исходник в Latin-1, а он — в UTF-8 или ANSI, но как–то это не правильно, мне кажется. Идентификаторы не получится юникодные написать, и широкие строковые литералы, наоборот, будут коцаться.
Восемь назад на Windows такие строки было особо некуда деть, кроме платформозависимого Win32Ada. Нет, можно, конечно, было подключить Ada.Wide_Wide_Text_IO и пошпарить Юникодом в тексте файла, но имя файла при этом будет ограничено ANSI. Эту дырку GNAT закрыл давно. Есть у процедур открытия файла строковый параметр Form, смысл которого по стандарту определяется компилятором, и в GNAT его можно было использовать для того, чтобы указать, что имя файла — в UTF-8, а не ANSI. Так что, сконвертировав имя файла в UTF-8, можно даже было и открыть его. А вот Ada.Directories было более проблемным, там никаких параметров Form не было, чтоб отказаться от этого проклятого ANSI. Понятно, что были и Матрёшки, где диктатура четырёхбайтовых строк, не дожидаясь, когда стандарт избавится от однобайтового наследия, но состояние стандартной библиотеки тоже важно.

Попутно, пока искал, поиск выдавал мне, как обстоят дела у других разработчиков
But the problem is MSVC only accept UTF8+BOM and MinGW only UTF8-BOM
note that MinGW use UTF-8 for sources, while VC8 use ANSI
Если этот «хорошо подходящий для Windows» компилятор до сих пор форсит ANSI в исходниках (кто будет ставить BOM для UTF-8?), сочувствую тем, кто вынужден этой пакостью пользоваться.

geektimes.ru Мне в utf не хватает типичных it-шных символов(http://fontawesome.io/icons/ примеры тут), а выходит что для добавления символа питания несколько лет бумажной волокиты потребовалось. Сразу становится понятно, что говноэмодзи туда добавили за откат.

U+1F959 — шаверма(https://habrastorage.org/files/733/3dd/520/7333dd520f714ec5b84b21a5331e9985.png)
U+1F924 — эпилептик(https://habrastorage.org/files/061/c95/ba7/061c95ba78a84530876e79266cebd846.png)
U+1F921 — клоуны жуткие(https://habrastorage.org/files/628/db9/551/628db9551dc04ba1b45f65f88c85a97a.png)
U+1F925 — WTF?(https://habrastorage.org/files/fbc/802/d6c/fbc802d6c47b440aaf4cf07ab8dcf2aa.png)
U+1F926 — куда-ж без говномемов(https://habrastorage.org/files/32a/87f/82a/32a87f82aa084d51a0b2875cd6dfc8b2.png)
U+1F930 — овуляшка(https://habrastorage.org/files/9cd/915/113/9cd915113150425bb6d9e9c5e6b8cb2f.png)
U+1F933 — самострел(https://habrastorage.org/files/88d/a4c/33e/88da4c33ed6e4452996e930500003720.png)
U+1F987 — batman(https://habrastorage.org/files/4e5/c3e/250/4e5c3e2504d0442099f727ded769effb.png)
и это только малая часть...

geektimes.ru
Есть такая научная теория, что чем больше развивается цивилизация, тем проще становится ее язык: от иероглифов слов переходят к иероглифам слогов, потом появляется алфавит, потом он упрощается(как пример "и" и "i" в русском языке. или вот про eng: posmotre.li все для облегчения обучения больших масс людей...но смотря на развитие юникода, мне кажется что нас хотят откинуть на 5-6тыс лет назад.

Наибольшая проблема с переходом forum.pascal.net.ru на utf-8 — это то, что Invisible Power Board любит хранить данные в формате сериализованного php, например:
a:7:{s:10:"most_count";s:2:"79";s:9:"most_date";s:10:"1457447769";s:12:"total_topics";s:5:"23808";s:13:"total_replies";s:6:"127937";s:9:"mem_count";i:6501;s:13:"last_mem_name";s:6:"Apmeм";s:11:"last_mem_id";s:6:"191205";}

Когда такая штука была записана в базу в кодировке windows-1251, а считывается обратно в utf-8, жди беды. Вот здесь в s:6:"Apmeм" написана длина в utf-8, а если бы это было записано в windows-1251, было бы s:5:"Apmeм"

PEP 0383 — Non-decodable Bytes in System Character Interfaces
Надо бы что–нибудь такое же, но для UCS-4. Мне кажется, значения сверх разрешённых стандартом 17 плоскостей вполне подходят для этих целей, но потребуются два диапазона, для косяков в однобайтовых кодировках и для косяков в UTF-16

Годами мы боролись против KOI-8 и Win-1251, за то, чтобы наконец прекратить геморрой с кодировками и сделать UTF-8 единственной кодировкой, которой было бы досточно для абсолютного большинства задач.
И вот теперь оказывается, что вездесущие emoji в UTF-8 не поддерживаются кучей софта и нужно опять шаманить с кодировками, менять utf8 на utf8mb4 и патчить некоторые приложения. Пруфлинк, например: google.com
Не знаешь, что такое emoji — иди в гугл. Хочешь рассказать, что emoji не нужны — иди на улицу, говори это миллионам людей, которые их вводят. А я посылаю лучи добра и поддержки админам и программерам, которые получили кучу геморроя из-за сраных смайликов.

Люди, которых вы можете знать
Igor Elbov Руководитель отдела сопровождения(Диасофт)
Руководитель отдела сопровождения(Диасофт)
> У вас 2 общих контакта с участником Igor Elbov.
Установить контакт