On Thu, Nov 30, 2017 at 11:09:07AM +1300, Karl Tomlinson wrote:
The native bytes may not be valid UTF-8, and so if the
character encoding is UTF-8, then there may not be a valid
`path` that can be encoded to produce the same `nativePath`.
I think you mean "is not UTF-8"?
It is best to use `nativePath` for working with filenames,
including conversion to URI, but use `path` when displaying
names in the UI.
I don't think this is true. The native filename isn't even
available to JS, which always deals with UTF-16 strings.
And for converting file paths to URIs, we should always be using
NewFileURI. It looks like that tries to use the UTF-16 path,
converted to UTF-8, but falls back to the native path if a
round-trip from and to the native charset doesn't produce the
same path.
contains wide characters corresponding to the native filename
used by native wide character system APIs. For at least most
configurations, I assume wide characters are UTF-16, in which
case this is also human readable.
On Windows, the UTF-16 path always corresponds to the wide
native pathname, which is always UTF-16.
It is best to use `path` for working with filenames.
Conversion to URI involves assuming `path` is UTF-16 and
converting to UTF-8.
I think, in general, it's best to avoid using paths at all,
except when converting to URIs or dealing with paths that need
to be displayed to or read from users. We have APIs to convert
between nsIFiles and NSPR file descriptors, which generally work
best when available, and work correctly cross-platform.
The reason this issue came up was that I needed to serialize
pathnames to a cache file, and while the GetNativePath/SetNativePath
round trip should usually work correctly for that use case, we
sometimes wound up with single-byte UTF-8 input paths for the
pathnames when they came from sources other than the cache file.
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
