Кириллические имена файлов и Lazarus , Сбой при попытке работы с файлом

Привет всем.

Итак, частично проблема описана в названии. А теперь - немного конкретики. Имеется: WinXP SP3 (неюникодный язык выставлен не в Cyrillic, а в Hebrew - это важно) и Lazarus 0.9.28.2

При попытке выполнить

  if SaveDialog1.Execute then
  begin
    ShowMessage(SaveDialog1.FileName);
    memo.SaveToFile(SaveDialog1.FileName);
  end;

, где SaveDialog1.FileName содержит символы кириллицы, например, 'F:\тест.txt', происходит сбой (см. аттач, нижняя часть картинки), хотя ShowMessage отображает правильный путь (см. аттач, верхняя часть). Да, я читал обсуждение на freepascal.ru, естественно, я пробовал и UTF8Decode и UTF8ToSys, но ни одно ни другое не приводит к работе SaveToFile, поскольку у меня системная кодировка другая, в ней не отображаются кириллические символы. Файл с именем на английском (или иврите) прекрасно сохраняется безо всяких преобразований, вышеприведенным фрагментом кода.

При этом, вот такой вызов WinAPI-шной функции:

if not CopyFileW(PWideChar(UTF8Decode(SrcName)),PWideChar(UTF8Decode(DstName)), False) then
begin
  //
end;

копирует файлы с любыми именами, хоть русскими, хоть ивритскими, хоть арабскими.

Внимание, вопрос: можно ли каким-либо образом заставить Лазарус понять, что имена файлов могут быть не на двух, а на гораздо бОльшем количестве языков (желательно не используя WinAPI)? Обходной путь - сохранить в файл с латинским именем, а потом переименовать его, как нужно - мне известен, хотелось бы без лишних телодвижений...

Прикреплённый файлtest.PNG (15,05 Кбайт, скачиваний: 1010)

Очень похоже на то, что Win32-интерфейс Lazarus (по крайней мере, версии 0.9.28-2) использует ANSI-вариант функций WinAPI для работы с файлами. Надо смотреть текущую SVN-версию, исправлять её (если баг ещё есть), отсылать патч разработчикам (последнее как раз несложно). Либо создавать обходные варианты с принудительным преобразованием кода из UTF8 в CP1251.

Сообщение отредактировано: daesher - 10.09.10, 07:36

По-моему, проблема сидит глубоко в RTL и связана с преобразованиями имён или даже типами вызова Ansi/Wide character. Я бы сказал, что это проблема чисто системной связки RTL FPC.

Добавлено 13.09.10, 12:33

Цитата daesher @ 10.09.10, 07:35

Либо создавать обходные варианты с принудительным преобразованием кода из UTF8 в CP1251.

Только UTF-8 в Windows не используется, если я не ошибаюсь. Используется UTF-16 (с двойным байтом на символ).

Как только полностью перейдут на Wide character функции (Unicode), подобные проблемы отпадут.