On Tue, Apr 28, 2009 at 3:26 PM, Erik Kay <[email protected]> wrote:
> On Tue, Apr 28, 2009 at 3:19 PM, Greg Spencer <[email protected]> wrote: > >> But that's exactly the point. FilePath is the class that created the path >> to begin with. So it can know what the LC_*/LANG variables were was when it >> was created, and do the right conversion when you ask the FilePath to >> convert to UTF16. Also, if the developer calls something called >> FilePath::CreateFromUTF8, then it can know it was supposed to be UTF8 and >> remember that. >> > > If you created it yourself, that's fine. FilePaths aren't always created > manually by users. They often are populated from system APIs where you > can't know. See file_util* for some examples. So the problem is that if > you add this API, people will mistakenly use the conversion functions when > they can't be safe. I agree it sucks. I just don't know of a reasonable > solution. > So there's currently no right way to do the conversion, but I still think that the FilePath constructor is probably in the best position to inspect LC_ALL, etc. and do as close to the right thing as possible. I doubt most Linux developers even think about this, and so the chances that they will implement anything other than assuming that it's ASCII are slim -- this would allow us to at least implement a baseline for them. Or would that just screw things up worse? Doesn't this mean that it's possible that the path manipulation routines fail for sufficiently odd encodings? (jis or something where an encoded char might include a "/"?) -Greg. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
