Hi, On Wed, 14.12.2005, 15:23 +0100 Matthias Kaeppler wrote on gnome-vfs-list: > Alexander Larsson wrote on gnome-vfs-list: > > I'm not sure where the confusion is. I can't talk for the c++ bindings, > > but for gnome-vfs itself the rule is: > > > > * file: URIs have no inherent encoding > > > > None, nada, zilch. They are the filename as stored on disk, escaped into > > a uri. As such, they are essentially escaped byte strings, the only > > limit being that zero bytes and '/' bytes are not allowed. This is a > > direct result of the fact that unix filenames have no encoding, and is > > nothing we can anything do about in gnome-vfs. > > Yes, I actually think the problem lies in the C++ bindings, because as > opposed to gnome_vfs_uri_new(), the construction of a Gnome::Vfs::Uri in > gnome-vfsmm requires the string which is passed to Uri::create() to be > encoded in UTF-8
I take it that - gnome-vfs supports http:// uris as well - those need to be utf-8 encoded and escaped then So one would have to have two different create functions, one for "file", one for "http" (and everything else?) > (that's because create() takes a Glib::ustring, Yeah, that is probably a mistake... I would CC murrayc and Bryan Forbes, but their "Authors" file states "do not email people directly"... sigh... ok, murrayc should be reading this on this mailinglist either way, I hope :) > 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). Curious... a conversion attempt? From what ? It must have found a crystal ball somewhere :) If it does indeed try that, another mistake... > If the string passed to create() is not valid UTF-8 however, an > exception will be raised. > > On the other hand however, if the string used to initialize the > Gnome::Vfs::Uri is valid UTF-8 (e.g. after a successful conversion using > the glib functions), it is possible that after construction, > Gnome::Vfs::Uri::uri_exists() will always return false /if/ the system > uses a different encoding for the filename in question. yes... a follow-up error > > > You just have to be very careful about your string encodings. I'd > > recommend using hex escapes when specifying a non-ascii string in C > > source code. > > it's not only about strings which are hardwired into the source code; > the problem applies to all other strings as well. If it is as you say, the bindings probably use Glib::ustring in this case when they should use something like (a imaginary :)) Glib::opaquestring or somesuch... (don't we all love the encoding mess :)) > > Regards, > Matthias cheers, Danny _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
