On Mon, Nov 17, 2008 at 04:00:02AM -0500, Martin Owens wrote: > Interesting, shouldn't all data out of barry towards the rest of the > system by converted to UTF-8? There is little point is perpetuating > archaic character encodings that other systems need to then deal with, > especially if the discretionary layer is able to understand and convert > it.
Well, Barry does no special massaging of the data, so whatever binary string data we get from the device, we drop in a C++ std::string and give it to the user. If that string includes null chars and garbage, we keep it, thanks to C++'s string's behaviour. This is not handled quite so cleanly where data is passed from C++ land into opensync's C land, where the char* and the glib string are king. I don't think this particular problem involves null chars, but if it did, the plugin wouldn't handle it right. Also, if I recall correctly from the last time I looked at this, we're probably not setting the character set / encoding in the Vcard to the Windows character set, and we're definitely not doing any character set conversions in the plugin. So the quick fix is to massage the data in the plugin to what opensync expects, or at least tell opensync what we're giving it, so it can deal with it appropriately. The right fix may involve conversion to UTF-8 in the Barry library, so nothing special is required from the application's point of view. > Garbage in, Sweet pine fresh data out. :-) - Chris ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
