Хотя символ D2010 всегда равен 2 байтам, в символах UTF-16 присутствуют те же проблемы свертывания и объединения символов, что и в символах UTF-8. Вы не видите этого с узкими строками, потому что они основаны на кодовых страницах, но со строками Unicode возможно (и в некоторых ситуациях часто) иметь аффективные, но невидимые символы. Примеры включают в себя метку порядка байтов (BOM) в начале файла или потока Unicode, символы индикатора слева направо / справа налево и огромный диапазон сочетаний акцентов. Это в основном касается вопросов «сколько пикселей в ширине будет эта строка на экране» и «сколько букв в этой строке» (в отличие от «сколько символов в этой строке»), но также означает, что вы можете t случайно вырезать символы из строки и предполагать, что они пригодны для печати. Такие операции, как «удалить последнюю букву из этого слова», становятся нетривиальными и зависят от используемого языка.
Вопрос о том, что «один из символов в моей строке вдруг имеет длину 3 байта», отражает небольшое недоумение по поводу того, как работает UTF. Можно (и допустимо) взять три байта в строке UTF-8 для представления одного печатаемого символа, но каждый байт будет действительным символом UTF-8. Скажем, письмо плюс два сочетания акцентов. Вы не получите символ в UTF-16 или UTF-32 длиной 3 байта, но он может иметь длину 6 байтов (или 12 байтов), если он представлен с использованием трех кодовых точек в UTF-16 или UTF-32. Что приводит нас к нормализации (или нет).
Но при условии, что вы имеете дело только со строками как с целыми вещами, все очень просто - вы просто берете строку, записываете ее в файл, затем читаете ее обратно. Вам не нужно беспокоиться о мелком шрифте отображения строк и манипуляций, все это обрабатывается операционной системой и библиотеками. Strings.LoadFromFile (name) и Listbox.Items.Add (string) работают точно так же в D2010, как и в D2007, все содержимое Unicode прозрачно для вас, как для программиста.