Я пишу слой-обертку для использования с mingw, который предоставляет приложению виртуальную среду UTF-8. Функции, которые имеют дело с именами файлов, являются обертками, которые конвертируют из UTF-8 и вызывают соответствующие функции "_w" и так далее. Большая проблема, с которой я столкнулся, заключается в том, что Windows 'wchar_t 16-битный

Для операций с файловой системой это не имеет большого значения. Я могу просто конвертировать туда и обратно между UTF-8 и UTF-16, и все будет работать. Но стандартный C-многобайтовый API-интерфейс преобразования символов не допускает использование символов multi-wchar_t.

Возможные решения:

Обеспечить среду CESU-8 вместо UTF-8. Мне действительно не нравится этот.Выбери легкий путь и поддержи только BMP. Обрабатывать последовательности UTF-8 длиной 4 как недействительные.Расширение оболочки для замены Mingwwchar_t сtypedef int32_t wchar_t; и иметь дело сWCHAR а такжеwchar_t быть другим. Это боль, но она может быть идеальной для портирования приложений, которые ожидают чистую среду типа POSIX и не используютwchar_t для любых целей Windows-API.Следующий взломать:

mbrtowc выводитwchar_t соответствует старшему суррогату после чтения первых 3 байтов 4-байтового символа UTF-8 и сохраняет оставшееся состояние вmbstate_t объект. Получив следующий байт, он объединяет его с сохраненным состоянием для вывода низкого суррогата. Если последний байт оказывается недействительным, он возвращает -1 (с EILSEQ) и одиночный суррогат попадает в выходной поток (плохо ...).

wcrtomb выводит первые 2 байта UTF-8, когда он обрабатывает старший суррогат, и сохраняет оставшееся состояние в своемmbstate_t объект. Когда он впоследствии обрабатывает низкий суррогат, он комбинирует это с сохраненным состоянием, чтобы вывести последние 2 байта UTF-8. Если действительный низкий суррогат не получен, он возвращает -1 (с EILSEQ) и неполная последовательность UTF-8 заканчивается в выходном потоке (плохо ...).

Плюсом этого хака является то, что он работает до тех пор, пока ввод действителен, и разрешает доступ к любому символу UTF-8 и, следовательно, к любому возможному имени файла / аргументу и т. Д. текст, с которым приложение может работать.

Минусы в том, что он не совсем соответствует ISO C (wchar_t строка не может быть сохранена с сохранением состояния) и что она задерживает обнаружение искаженных символов до тех пор, пока неверный частичный вывод не будет уже записан.

Я ищу отзывы о различных вариантах, и особенно о моем предложенном хакере: разумно ли это, могут ли недостатки вызывать серьезные ошибки, и есть ли какие-то другие недостатки, которые я еще не рассмотрел, которые могут помешать схеме работает полностью. Я также был бы рад услышать любые другие возможные решения, о которых я не думал.