Понадобилось грузить TTF-шрифты из файлов, что делается с помощью PrivateFontCollection.AddFontFile(FileName). И, внезапно, стал проявляться плавающий глюк, возникающий, если периодически пересоздавать объект PrivateFontCollection. Например, при попытке сделать MeasureString(Text, LoadedFont).ToSize(), программа стала вываливаться с ошибкой "Попытка чтения или записи в защищенную память".

Пишут, что это глюк Framework’а и толковое решение только одно, создавать PrivateFontCollection один раз при запуске программы, например, в каком-нибудь статическом классе, и больше ее не трогать. Т.е. подгружать новые шрифты можно, а пересоздавать коллекцию не надо.
Минус решения — можно загадить память подгружаемыми шрифтами, если подгрузить много файлов. Но лучше пока ничего не нашел.

В принципе, можно создать вот такой статический класс, который будет подгружать шрифт в коллекцию, и хранить в Dictionary сопоставление между именем файла и шрифтом в коллекции. Если файл еще не был загружен — подгружать, если был, возвращать позицию в коллекции.

Ну и чтоб два раза не вставать, класс FileFont, который заодно меняет параметры шрифта (размер и начертание).

На Cyberforum’е тоже пока ничего более дельного не предложили.

Известно, что внутренний формат строк в .NET — UTF16, что значит, что символы из основной многоязыковой плоскости (BMP) Unicode, т.е. с кодом меньше FFFF кодируются одним машинным словом, а остальные символы — двумя, одно из которых т.н. суррогат.

Так вот, как оказалось, с отображением суррогатных пар может возникнуть проблема. Контролы Windows Forms могут воспринимать символ с кодом >FFFF не как один символ, как должно быть, а как два. Для примера пробуем отобразить анатолийский иероглиф

с кодом 0x14476

Как видно, TextBox и Label воспринимают символ, как два символа, и, соответственно, его не отображают, а RichTextBox видит, что это один символ, но не отображает его, даже при правильно заданном шрифте.
MessageBox также отображает символ не как один, а как два:

Для устранения проблемы с RichTextBox достаточно задать нужный шрифт перед тем, как присвоить свойству Text нужные символы.

         int Code = 0x14476; //анатолийский иероглиф        
        Font AnFont = new Font("Anatolian", 24, FontStyle.Regular,
 GraphicsUnit.Pixel, 1);
        private void Form1_Load(object sender, EventArgs e)
        {
            string strSP = char.ConvertFromUtf32(Code);
            
            lblTest.Font = AnFont;
            txtTest.Font = AnFont;                        
            lblFont.Text = AnFont.FontFamily.Name;
            rtbTest.Font = AnFont;

            lblTest.Text = strSP;
            txtTest.Text = strSP;
            rtbTest.Text = strSP;
        }

PictureBox также отрисовывает нужный символ без проблем:

А корень проблемы кроется не в C#, .NET и компонентах Windows Forms, а в самой Windows. Пакет обновления SP1 для Windows 7 решает проблему полностью.

Наиболее универсальным решением является использование RichTextBox для работы с такими символами, во всяком случае, это работает даже для Windows XP, для которой ждать патчей, понятное дело, не приходится.
Главное, не забывать про то, что шрифт надо задавать до вставки/присвоения символа.

Обсуждение на Киберфоруме Копия

Пример
Пример на GitHub

Да, совсем забыл выложить исходник, спасибо, что напомнили.
Перевести число в/из десятичной в 2, 8, и 16-ричную систему можно с помощью стандартной функции класса Convert
Convert.ToInt64(s, From)
s — строка, содержащая число.
From — основание системы счисления.

Обратное преобразование:
Convert.ToString(n, To)
n — число
To — основание системы счисления.
На выходе будет строка

В примере еще показал, как ограничить ввод в текстовое поле, чтоб можно было вводить только определенные символы, и добавил отображение символа по его коду (в однобайтной кодировке, для Unicode будет погода на Марсе). Числа можно вводить через пробел.

Скачать исходник
Этот и другие примеры на Github

Иногда проще прочитать файл, как текстовый в однобайтовой кодировке, чтобы что-нибудь там поделать с помощью стандартных string.Replace/string.Remove и т.д., иногда даже если файл не совсем текстовый, потому что таких же удобных функций для работы с массивом байт нет (или я не нашел).
Это, наверняка, адский быдлокод, но все-таки вполне альтернатива изобретению совсем уж дикого велосипеда.

А у меня речь шла о текстовых файлах, правда, неизвестно в какой кодировке, и символах, которые нужно искать/менять. Символы от кодировки не зависели, посему любой файл можно было рассматривать, как текстовый, в любой однобайтовой кодировке. Главное, в какой кодировке открыл, в той же потом и сохранить.
Так вот File.ReadAllText пытается автоматически определить кодировку файла на основе наличия меток порядка следования байтов и принудительная установка кодировки не помогает. Если в файле встретился зловредный BOM, то ReadAllText наплюет на твои указания кодировки с высокой колокольни и откроет в той, на которую ему BOM указывает, а при сохранении, соответственно, будет глюк и текст превратится в тыкву.

Беда, конечно, решается стандартно, чтением файла с помощью StreamReader и записью с помощью StreamWriter, которые себе такой самодеятельности не позволяют, но «осадочек остался».

Пример
Скачать