sebknzl Posted December 28, 2013 Report Share Posted December 28, 2013 Hi! Localized strings are returned with wrong escaping in JSON, e.g.: { "message": "Der ausgew\u00c3\u00a4hlte Ordner wurde bereits zu BitTorrent Sync hinzugef\u00c3\u00bcgt.", "result": 200 } These are escaped UTF-8 bytes, which is wrong. Either don't escape at all, as UTF-8 is default for JSON anyways and if you must escape then see 2.5 in RFC 4627. You should also send a charset=utf-8 along with Content-Type. Regards Quote Link to comment Share on other sites More sharing options...
scus Posted April 14, 2014 Report Share Posted April 14, 2014 I stumbled upon the same problem, while writing a python api wrapper. A fix would be nice, as it regards also directory names, if they contain umlaute/non ASCII characters. Quote Link to comment Share on other sites More sharing options...
RomanZ Posted April 15, 2014 Report Share Posted April 15, 2014 @sebknzl, @scus, I'll check why do we escape characters and if this can be changed. However, the RFC4627 allows character escaping, i'm citing: 2.5. StringsThe representation of strings is similar to conventions used in the Cfamily of programming languages. A string begins and ends withquotation marks. All Unicode characters may be placed within thequotation marks except for the characters that must be escaped:quotation mark, reverse solidus, and the control characters (U+0000through U+001F).Any character may be escaped. If the character is in the BasicMultilingual Plane (U+0000 through U+FFFF), then it may berepresented as a six-character sequence: a reverse solidus, followedby the lowercase letter u, followed by four hexadecimal digits thatencode the character's code point. The hexadecimal letters A thoughF can be upper or lowercase. So, for example, a string containingonly a single reverse solidus character may be represented as"\u005C".Alternatively, there are two-character sequence escaperepresentations of some popular characters. So, for example, astring containing only a single reverse solidus character may berepresented more compactly as "\\". Quote Link to comment Share on other sites More sharing options...
scus Posted April 15, 2014 Report Share Posted April 15, 2014 Tanks for your reply. If it is necessary to escape those characters, they should be escaped by \uXXXX and not \u00XX\u00XX. The escaped characters above represent ä and not ä as it should. Quote Link to comment Share on other sites More sharing options...
tuxpoldo Posted April 19, 2014 Report Share Posted April 19, 2014 Believe me! This makes it really hard to handle the strings correctly. Look at this ugly code and this much more ugly ways to handle it.... Quote Link to comment Share on other sites More sharing options...
RomanZ Posted May 8, 2014 Report Share Posted May 8, 2014 Ah, now I see what you are saying. They are escaped in a pretty strange manner - split by 7 bits. I'm still checking why we do so and how it can be changed. Thanks for explanations. Quote Link to comment Share on other sites More sharing options...
tuxpoldo Posted May 9, 2014 Report Share Posted May 9, 2014 It would be really nice, since currently the code is not really consistent... Quote Link to comment Share on other sites More sharing options...
RomanZ Posted May 12, 2014 Report Share Posted May 12, 2014 Hi all, Thanks for your feedback. Issue is fixed and will be available in one of 1.3 release builds soon. Quote Link to comment Share on other sites More sharing options...
joncamfield Posted November 2, 2014 Report Share Posted November 2, 2014 This seems to have caused a very odd regression around UTF in the 1.4.x series. My Linux and Mac computers sync fine, but my Synology NAS cannot figure out any file or folder structure with extended characters. While most were already synced, the NAS is convinced that they are not, and is constantly trying to sync them. All devices are running 1.4.93. I can provide logs if that would be of any use. Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted November 2, 2014 Report Share Posted November 2, 2014 @joncamfield, please update to 1.4.99 as this contained a fix for non-ASCII character issues Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.