Re: Can someone please comment on this short program

Murray Cumming wrote:
I probably heard somewhere that all URIs are UTF-8 encoded. I didn't take
the time to look at the appropriate W3C specification, RFC, etc. I also
assumed that URIs are escaped.

In your test case, you are using the C++ wrapper for
I wonder what this does? Does it just add file:// at the start without
doing any escaping/encoding-conversoin?

I don't know, the API reference doesn't say anything about conversion so I must assume no conversion is happening. I don't think this function is relevant to this issue anyway, though I may be wrong.

(that's because create() takes a Glib::ustring, and if
you pass an std::string in place of a Glib::ustring--such as the one
returned from FileInfo::get_name()--a conversion attempt will be made).

I don't think that's true, but maybe I'm looking at the wrong part of the
Glib::ustring string source. The ustring(std::string) constructor does a
simple assignment.

Yes you're right; my excuses. Probably the conversion happens somewhere inside the create() function or in a function called within create() and not in any ustring ctor. In any way, calling create() with a string that is not UTF-8 encoded raises an exception on my system (unless it only contains the first 127 ASCII characters).

	RefPtr<Uri> uri = Uri::create("täst");

matthias:testing$ ./a.out
terminate called after throwing an instance of 'Glib::ConvertError'
Uri: Aborted

Please note at this point, that I could have as well passed an std::string encoded in something other than UTF-8 to create(), and not just some hardwired string which happens to not be encoded in my locale's encoding due to my text editor being ignorant (in your face, Emacs!).

The vicious circle here is that by converting the argument safely to UTF-8 to let create() succeed, I thereby break functions like uri_exists().


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]