GNOME Bugzilla – Bug 59387
g_filename_to/from_uri() win32 details
Last modified: 2011-02-18 15:47:19 UTC
Add this API to gconvert.h: gchar *g_filename_from_uri (const char *uri, char **hostname, GError **error); gchar *g_filename_to_uri (const char *filename, char *hostname, GError **error); This helps file DnD implementations tremendously, because these functions are very easy to get wrong. I've posted a patch to the gtk-devel-list, but i need to update it.
Created attachment 954 [details] [review] The patch, now with tests
Ok. Here is the final patch. This thing uses g_ascii_isspace(), so it blocks on #59388.
I think there should be a few more tests, but I can add them after this is in. I always like to include edge case tests like "", "/", a single letter "a" and the like. Also, the Windows-style path tests need to be run under non-Windows systems too, even though the results might be different on those systems, and the Windows-style paths should show up in tests for conversion in both directions. I'm a little sad that we didn't go with file:/ instead of file:/// -- I guess that discussion is still going on.
On the file:/ vs. file:/// issue i defered to the judgement of Daniel Veilard. He seemed to think that file:/// was better, alhough it seems that it is not mandated by the standard.
Daniel Veillard just said on the XML mailing list that the proper format for "c:\windows" as a URI is "file:///c%3A\windows". So I think the test case for (and the code to handle) Windows paths is incorrect. See <http://lists.gnome.org/archives/xml/2001-August/msg00134.html>. (I still don't buy that "file:///" is better, but I don't know how to convince Daniel.)
Interesting discussion on this at: http://lists.xml.org/archives/xml-dev/200005/msg00005.html They seem to completely agree on convertin \ to /, something which also corresponds with the VMS example in 3.10 in RFC 1738. Escaping the colon seems to be optional. That is even said my Daniel in this mail: http://xmlsoft.org/messages/0856.html I think we should generate file:///c:/dir/file.txt and accept file:///c:/dir/file.txt, file:/c:/dir/file.txt and the same with colon escaped. I will implement this.
Ok. I checked in the current version. I'm changing this bug to handle the win32 behaviour details. It is no longer on the API milestone.
Fix committed to CVS. On Windows, backslashes in filenames are now always converted to slashes in the URI, and vice versa. Drive letters (followed by colon or vertical bar) are correctly handled in URIs. An initial slash in the filename part is no longer skipped on Unix. See ChangeLog for details.