My application breaks because some strings that are given as an argument in a url for an httpservice-request contain special characters such as é. Is their a way to convert them to their normal variant (in this case e)?
There is no function that would do it automaticaly for you. You'll have to replace everything one special character at a time.
You could use escape and unescape to safely post with your service.
Related
In fact, the title says it all. But, I'll go more into details:
I am sending a JSON string from my JS script to the server and vice versa. The JSON contains things as some content the user wrote into a textfield, but I know that some user will manage to break the JSON array this way sooner or later, so I decided to encode it with encodeURIComponent().
But I see, that when I try to encode curly brackets, that they aren't encoded at all. Is this going to be a problem?
More precisely, I'm afraid that if someone writes: } , {, the JSON will break. This shouldn't happen, since all of it is inside doublequotes like this: "} , {", and if a user write doublequotes or singlequotes they are going to be encoded, and from what I know, JSON should handle all of that just fine, but I am not entirely sure.
So, should I encode those brackets?
(Another thing is that the data is inserted into MySQL inside prepared statements, so that shouldn't be a problem, or I am wrong with that?)
A quick quote from the JSON specifications:
A string is a sequence of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.
As you can see in the image that follows the paragraph quoted above, any Unicode character except for ", \ and control characters is represented as-is; no escape is required.
why will brake? Your JSON string will be inside ""
So will be something like
{"postcontent": "Shouldnt { } be escaped"}
I try to import some large csv dataset into neo4j using the neo4j-import tool. Quotation is not used anywhere, and therefore i get errors when parsing using --quote " --quote ' --quote ´ and alike. even choosing very rare unicode chars doesnt help with this multi-gig csv because it also contains arabic letters, math symbols and everything you can imagine.
So: Is there a way to disable the quotation checking completely?
Perhaps it would be useful to have the import tool able to accept character configuration values specifying ASCII codes. If so then you could specify --quote \0 and no character would match. That would also be useful for specifying other special characters in general I'd guess.
You need to make sure the CSV file uses quotation marks, since they allow the tool to reliably determine when strings end.
Any string in your data file might contain the delimiter character (a comma, by default). Even if there were a way to turn off quotation checking, the tool would treat every delimiter character as the end of a field. Therefore, any string field that happened to contain the delimiter character would be terminated prematurely, causing errors.
I was just wondering why my wcf rest returns json which contains backslahses in the url. it is as below:
https:\/\/s3.amazonaws.com\/reiaustralia\/1fc00dfab25044ecb31e4882121b535e\/jpg\/download.jpg?AWSAccessKeyId=AKIAISTDESL6TBRAVM4Q&Expires=1380692091&Signature=MduuaUAjQRisadtM%2FDuVDemexLY%3D
Thanks
Forward slashes can be escaped with a backslash in JSON, but they don't have to be. So either one of the following:
{"url":"http://www.example.com/"}
or
{"url":"http\/\/www.example.com\/"}
Will parse into an object which has a url property whose string value is http://www.example.com/.
Some technologies will escape out the slashes when generating JSON, and some won't. PHP, for example, has an option called JSON_UNESCAPED_SLASHES which lets you control whether or not to escape your slashes.
You can get see the various escape characters from the json.org home page in the "string" section.
Because // (double slash) in javascript means comment and /{string}/ (string inside slash) is mean regula expression.
So. To keep correct value in json it have to put \ (back slash) in front of / (slash).
They are just escape characters, and when u consume the string in your application it would just be fine
I have generated an HTML tag through C# code. I am able to render correctly in the text area. When I googled it, I found this. To render the HTML tags in the text area, we need to convert the '<','>' into HTML entity references. But when I am trying to replace using String.Replace, it throws an error: Too many characters in character literal
.
string psHtmlOutput="<html><body><table border='0' cellspacing='3' cellpadding='3'><tr><th> Name </th><th>DomainName</th><th>DomainType</th><th>Defualt</th></tr><tr><td>india.local</td><td>india.local</td><td>Authoritative</td><td>True</td></tr></table></body></html>";
psHtmlOutput.Replace('>','>');
psHtmlOutput.Replace('<','<');
Error: Too many characters in character literal
Please help; how can I proceed?
The String.Replace method has two overloads:
One that operates on Strings.
One that operates on Chars.
In C#, single quotation marks are used to specify Char literals. Because you have used single quotes, the second overload of the method has been used. However, your second argument is not a valid character literal because > is not a single character.
So if you actually want to replace the character with a string, just use the overload that takes strings:
psHtmlOutput.Replace(">", ">");
psHtmlOutput.Replace("<", "<");
Why doesn't JSON data support special characters?
If json data includes special characters, etc:\r,/,\b,\t, you must transfer them, but why?
JSON supports all Unicode characters in strings. What do you mean by "transferring"?
Those characters need to be escaped because JSON specification says so. For some characters reasons is simple -- for example, double-quotes need to be escaped because regular double-quote ends String value, so there would be no way to tell end marker for character in content. For linefeeds reason probably was to enforce limitation that no String value spans multiple text lines; and for other control-character to avoid "invisible characters". This is similar to escaping required by XML or CSV; all textual data formats require escaping, or prohibit use of certain characters.