.NET removing all spaces when decoding URI - javascript

I am sending a parameter, from Javascript to .NET. The parameter could contain multiple spaces like 'John [3 spaces here, stackoverflow not showing them] Smith', I need the spaces to stay. However, it looks like the spaces disappear in .NET. In an attempt to fix this, I made sure to encode the URI on client side, and decode it on server side. The code (in VB.NET) looks like this:
<AjaxPro.AjaxMethod()> _
Public Function GetSearch(ByVal strValue As String) As String
strValue = HttpUtility.UrlDecode(strValue)
...
End Function
Before the UrlDecode, strValue looks like John%20%20%20Smith'. Afterwards it looks like John Smith. Can anyone tell me how to fix this?
I am using .NET 2.0 Web Forms.
EDIT: following one of the suggestions below I replaced all the spaces with (ampersand)nbsp;. I can see all the spaces when I debug, however, my database is SQL server, for some reason it views regular spaces to be different from (ampersand)nbsp; spaces, and as a result the query does not return the right values. It took me some time to figure this out because I could not see the difference with the naked eye.

Ok, I was able to resolve the issue in the front-end by replacing all spaces with Non-breaking spaces. I then had to replace the Non-breaking spaces back with regular spaces in my SQL stored procedure (otherwise the query wouldn't work).

Related

JSON not transferring "+" character to CGI script

I am currently working on a personal project, where I have to deal with some chemical formulas;
I have a form with JavaScript where I enter these formulas; The formulas are entered in a LaTeX-like style for super- en subscript.
An example formula can be found below:
Fe^{3+}
When I use JavaScript to read the form and console.log(); the formula is working as expected.
However if I send the formula to the back-end (Python with CGI), the + character seems to have disappeared and been replaced with a space.
I thought it had something to do with escaping the character, since parts of the formula look a lot like regex's, but after looking around, I couldn't find anything that would suggest that I had to escape the + character.
And now I have absolutely no idea how to resolve this... I could use a different character and replace it on the back-end but that seems like it is not the optimal solution...
Most important question: How did you invoke the CGI script?
With HTTP GET or HTTP POST?
If you're using HTTP POST and the data was being transferred in the HTTP Data portion, then you don't need to escape the "+" sign.
But if you're using HTTP GET, then the "+" sign will first be translated according to URL encoding standard (thus, "+" becomes a space), before transferred to the CGI script.
So in the latter scenario, you need to escape the "+" sign (and other 'special' characters such as "%" and "?").

JavaScript: Is this replacement of special characters correct?

Our web application went wrong couple of times because of copy-pasting text from other application. Always the saved ASCII control characters were the root cause (e.g. 0x1A). I would like to eliminate all the possible control characters from the input string except for newline and tabulator. I created the following code:
var originalString, newString;
newString = originalString.replace(/[\x00-\x08\x0B-\x1F\x7F]+/g, '');
So I keep the tabulator (0x09) and newline (0x0A). My tests are all fine, but I would like to be sure before adding this code to our application.
Is that the one I want? Is it correct? Or should be extended? Or this should be done rather in the backend?

Javascript RegExp being interpreted different from a string vs from a data-attribute

Long story short, I'm trying to "fix" my system so I'm using the same regular expressions on the backend as we are the front (validating both sides for obvious security reasons). I've got my regex server side working just fine, but getting it down to the client is a pain. My quickest thought was to simply store it in a data attribute on a tag, grab it, and then validate against it.
Well, me, think again! JS is throwing me for a loop because apparently RegExp interprets the string differently depending how it's pulled in. Can anyone shine some light on what is happening here or how I might go about resolving this issue
HTML
<span data-regex="(^\\d{5}$)|(^\\d{5}-\\d{4}$)"></span>
Javascript
new RegExp($0.dataset.regex)
//returns /(^\\d{5}$)|(^\\d{5}-\\d{4}$)/
new RegExp($($0).data('regex'))
//returns /(^\\d{5}$)|(^\\d{5}-\\d{4}$)/
new RegExp("(^\\d{5}$)|(^\\d{5}-\\d{4}$)");
//returns /(^\d{5}$)|(^\d{5}-\d{4}$)/
Note in the first two how if I pull the value from the data attribute dynamically, the constructor for RegExp for some reason doesn't interpret the double slash correctly. If, however, I copy and paste the value as a string and call RegExp on the value, it correctly interprets the double slash and returns it in the right pattern.
I've also attempted simply not escaping the \d character by double slashing on the server side, but as you might (or might not) have guessed, the opposite happens. When pulled from attributes/dataset, the \ is completely removed leading the Regex to think I'm looking for the "d" character rather than digits. I'm at a loss for understanding what JS is thinking here. Please send help, Internet
Your data attribute has redundant backslashes. There's no need to escape backslashes in HTML attributes, so you'll actually get a double-backslash where you don't want one. When writing regular expressions as strings in JavaScript you have to escape backslashes, of course.
So you don't actually have the same string on both sides, simply because escaping works differently.

Regex pattern in JSON?

I'm trying to have a single JSON file to validate data both in front (JS) and back (PHP).
I cannot figure out how to have my pattern in a json string, PHP won't convert it.
Here's what I'd like to use (email validation):
'{"name":"email", "pattern":"^[a-z0-9]+(\.[_a-z0-9]+)*#[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,15})$"}'
I suppose there's something in pattern that doesn't get treated as a string? This as it is, won't convert to an object in PHP. I shouldn't have to escape anything but I might be wrong...
thanks
Edit: Tried this as suggested in comments:
json_decode('{"name":"email", "pattern":"^[a-z0-9]+(\\.[_a-z0-9]+)*#[a-z0-9-]+(\\.[a-z0-9-]+)*(\\.[a-z]{2,15})$"}‌​'); ==> NULL
The problem are the backslashes \. Use two to signal that there is one and it will work well:
{"name":"email","pattern":"^[a-z0-9]+(\\.[_a-z0-9]+)*#[a-z0-9-]+(\\.[a-z0-9-]+)*(\\.[a-z]{2,15})$"}
The above is valid JSON but will cause trouble as PHP string, because \\ will already be interpreted as one \ before it is passed to json_decode(), and we're back where we started from. As deceze kindly pointed out in the comments, this can be solved by adding four backslashes:
{"name":"email","pattern":"^[a-z0-9]+(\\\\.[_a-z0-9]+)*#[a-z0-9-]+(\\\\.[a-z0-9-]+)*(\\\\.[a-z]{2,15})$"}
Or by immediately passing the contents from file_get_contents() (or similar) to json_decode().

Why is my JSON returning escape code for a single quote (apostrophe)

I'm receiving JSON data from server that contains text which should have an apostrophe but instead I see the escape code for an apostrophe. Is this an issue with the way the JSON is formatted?
This is how I have it on server-side:
[{"testJ":6387,"title":"This is JSON's return",}]
This is what I'm getting back:
[{"testJ":6387,"title":"This is JSON's return",}]
If I have not provided enough detail, please let me know and I will try to add more information.
Your JSON is almost valid, but you have a problem, you have add one comma that shouldn't be there. (the last comma).
You can check this using a JSON validator site like
http://www.freeformatter.com/json-validator.html
http://jsonformatter.curiousconcept.com/
http://jsonlint.com/
On the other hand, think that the apostrophe is a way to enclose text, so what you are using to parse the JSON is what is having the problem. Try to put an escape character before the apostrophe, so should be like this on the server side
[{"testJ":6387,"title":"This is JSON\u0027s return"}]
For more information you can refer to the RFC https://www.ietf.org/rfc/rfc4627.txt and in section 2.5 you will find more information.

Categories

Resources