> 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`.
Kris Maglione writes: > I think you mean "is not UTF-8"? If the bytes in the native filename are not valid UTF-8, then they cannot be decoded as UTF-8. When the character encoding specified by the current locale is UTF-8, or sometimes even if not (e.g. OS.File), attempts are made to interpret the filename as UTF-8 for `path`. These attempts may fail. Perhaps similar issues may exist with other assumed encodings, but UTF-8 is the common one. If anyone were to ever want to try to display these filenames, then the reference would be https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-filename-display-name There is some indication of what this does at https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-get-filename-charsets > 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. I don't know what using `path` in URIs is trying to support. Other applications use `nativePath` and so that is better for IPC such as drag'n'drop and clipboards. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
