GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded pathname

Alexandre Julliard julliard at winehq.org
Mon Nov 21 13:54:33 CST 2005


Alex Villací­s Lasso <a_villacis at palosanto.com> writes:

> I was rather hoping for an explanation of which is the "correct" 
> behavior for an UTF-8 locale:
> 1) Open File Dialog returns an UTF-8 encoded string (visible to the 
> application, current behavior), and open-file functions expect UTF-8
> 2) Open File Dialog returns locale-encoded string (even in the UTF-8 
> locale), and open-file functions expect locale-encoding (as they do now)

2) is the right behavior. The A functions always return strings in the
Ansi codepage, not in the Unix one. There is no Windows locale that
uses UTF-8 as Ansi codepage, so if a UTF-8 string is returned to the
application that's a bug.

> Your comment strongly suggests (2) is the correct approach, but what 
> happens in East Asian locales? Or am I just demonstrating a lack of 
> knowledge on how non-UTF8 encodings work?

Asian locales will use one of the double-byte codepages.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list