Оказалось, что функция GetEnvironmentVariable возвращает значение переменной (в моём случае, APPDATA) в OEM-кодировке, соответственно, вместо имени пользователя в пути профиля были кракозябры. Ок, написал свою функцию GetEnvironmentVariable, которая возвращает путь в unicode. Уже потом нашёл свежий баг на багтрекере с такой же проблемой.Потом, памятуя о том, что файловые функции требуют Ansi-имена, я везде честно писал что-то вроде
- Код: Выделить всё
ForceDirectories(UTF8ToAnsi(DataDir));
И вдруг выяснилось, что функция CopyFile сама делает такое перекодирование и ей-то как раз надо подсовывать имена в UTF8. Голова идёт кругом от обилия кодировок и разнообразия способов работы с ними функций
Собственно, вопрос: планируется ли командой Lazarus в будущем, пусть даже не очень близком, чистка всего этого безобразия и приведения всего к единому стандарту - чтобы всё было в unicode? Или, чтобы не поломать обратную совместимость, это уже не будет трогаться? Я так понимаю, что частично проблема идёт от FreePascal'я, где, например, TFileStream реализован исключительно в Ansi-версии. Есть ли у команды FreePascal планы по юникодификации этих классов? Или проще начать писать свои нестандартные обертки вокруг стандартных классов?
