FindFirstUTF8, FindNextUTF8 doesn't work in Win32 for non Ansi names
Original Reporter info from Mantis: skalogryyz
-
Reporter name: Dmitry Boyarintsev
Original Reporter info from Mantis: skalogryyz
- Reporter name: Dmitry Boyarintsev
Description:
The current FindFirstUTF8, FindNextUTF8 function implementation is simply converts path from UTF8 to Ansi and passes the name to SysUtils functions.
After SysUtils function is complete, LCL function converts the filename from Ansi to UTF8.
This works in Win32 system but only for file names that match current Ansi locale. If a filename contains non-ansi locale characters the result would be wrong.
See the screenshot for the example.
There's a screen shot of Windows Explorer at the directory with 4 files. Files' names are in: German (one letter "ö"), Russian, Hebrew, and Arabic.
Since current Windows is Russian the filename can be read by LCL application, though other names are read wrongly (even German letter "ö", since there's no replacement in CP1251 for it) (The window on the left)
This can be fixed if FindFirstUTF8/FindNextUTF8 for windows are using FindFirstW/FindNextW functions (where available).
The patch for is attached. Application compiled with the patch applied is able to read the file names correct (the window on the right)
Additional information:
The code of the sample application is the following:
procedure TForm1.Button1Click(Sender: TObject);
var
fs : TSearchRec;
begin
if FindFirstUTF8( IncludeTrailingPathDelimiter(Edit1.Text) + AllFilesMask, faAnyFile, fs) <> 0 then Exit;
repeat
Memo1.Lines.Add(fs.Name)
until FindNextUTF8(fs) <> 0;
FindCloseUTF8(fs);
end;
Mantis conversion info:
- Mantis ID: 15642
- Fixed in revision: 27248 (#319db725)
- Monitored by: » sekelsenmat (Felipe Monteiro de Carvalho), » @ganmax (Maxim Ganetsky), » @flyingsheep (Bart Broersma)
- Target version: 0.9.30