On Wed, May 13, 2009 at 4:35 PM, Darin Fisher <[email protected]> wrote:
> The "solution" is to not convert to UTF-16 unless you are trying to > generate a string to display to the user. Then you should use the LANG > information to determine how best to render the text for display to the > user. > Yeah, that would be nice, and I agree, but the reason I need it is that some third party APIs (probably wrongly) take UTF16 to represent an input file in their API. So in order for the third party API to load the file properly, I need a UTF16 version of the file path. Also, in all of the O3D code, we assume that strings are encoded in UTF8 (which is fine and correct for any string except for filenames on Linux), so any string that might come from the user would come in as UTF8, and I'd have to translate it into a FilePath (somehow). > I know this doesn't really help. I think it is reasonable to have a > utility somewhere to perform a conversion to UTF-16 (or UTF-8), but it > should come with a stern warning, and I kind of prefer it not being a method > on FilePath since I would prefer people not be tempted to overuse it. > Yeah, I think we've beat that to death: it won't be in FilePath. -Greg. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
