Hi, On Wed, Apr 12, 2017 at 03:40:46PM +0200, Christophe Fergeau wrote: > On Wed, Apr 12, 2017 at 07:19:54AM -0400, Frediano Ziglio wrote: > > > > > > > > From: Victor Toso <me@xxxxxxxxxxxxxx> > > > > > > Manual for G_FILE_ATTRIBUTE_STANDARD_NAME states: > > > > The name is the on-disk filename which may not be in any known > > > > encoding, and can thus not be generally displayed as is. > > > > > > Considering a file named "ěščřžýáíé", if we use > > > G_FILE_ATTRIBUTE_STANDARD_NAME get the file name, we will have the > > > following 72 char long string: > > > "\xc4\x9b\xc5\xa1\xc4\x8d\xc5\x99\xc5\xbe\xc3\xbd\xc3\xa1\xc3\xad\xc3\xa9" > > > > > > > this string is only 18 characters long, why 72 ? > > > > > We should be use G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME instead which > > > will give us the correct 18 long utf-8 string: "ěščřžýáíé" > > > > > > > I think this solves the encoding as we'll transmit with a given encoding > > (utf8). > > If the source filename is not correctly encoded this will give a > > destination filename different from the source. > > As the protocol does not include an encoding utf-8 is a good choice > > Do we really need an encoding for the filename in the protocol? As part of the protocol, I don't see an issue with that to be honest. > Filenames on disks are just byte arrays, even though these days they > usually are UTF-8. I think I would not try to be too smart with respect > to their encoding, and just send them as is (ie as a byte array without > trying to stick an encoding on them). > > For linux<->linux dnd, this should be fine, for windows client -> linux > guest, I guess this is fine too. > > There are probably going to have some corner cases on linux -> windows > dnd, but things there seems a bit messy (different encoding on fat and > ntfs FS) > https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748(v=vs.85).aspx > > However, in this scenario, we also need to deal with invalid characters > in Windows filenames ( \ . ? * and so on), which is done on the agent > side, so we could also handle encoding conversions on the agent-side > too. > > Christophe I think this is a different issue. The guest agent should deal with guest related problems as maximum file size or filenames special/prohibited chars as you mentioned. How these data is transferred is in the protocol. I'm not specialist on possible problems but although ascii is compatible with utf8 it might become a problem to not have a standard well defined in the future although Marc-André said it should be UTF-8. toso
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel