Откуда ж ты, болезный, достал эту cp1251? Неужели CHARSET=utf8 надо поставить, чтоб такие глупости не порол? NT, Юникод, слышал что-нибудь такое, нет?

Traceback (most recent call last):
File "tortoisehg\hgqt\settings.pyo", line 1286, in accept
File "tortoisehg\hgqt\settings.pyo", line 1264, in applyChanges
File "tortoisehg\hgqt\settings.pyo", line 1675, in applyChanges
File "tortoisehg\hgqt\settings.pyo", line 114, in value
File "tortoisehg\util\hglib.pyo", line 87, in fromunicode
File "encodings\cp1251.pyo", line 12, in encode
UnicodeEncodeError: 'charmap' codec can't encode characters in position 13-15: character maps to <undefined>

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

«Поддержка» четырёхбайтовых строк в 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 не нужны — иди на улицу, говори это миллионам людей, которые их вводят. А я посылаю лучи добра и поддержки админам и программерам, которые получили кучу геморроя из-за сраных смайликов.