Develop Reference

Retrieving JSON from cookies

My cookie is set as follows
cookies[:cart] = "[{"id":"23","amount":"9"},{"id":"37","amount":"4"}]"
cookies[:cart] returns [{"id":"23"
and calling .each on cookies produces this abomination:
["cart", "[{\"id\":\"23\""] ["\"amount\":\"9\"}", nil] ["{\"id\":\"37\"", nil] ["\"amount\":\"4\"}]", nil]
I'm totally lost and can't really figure out what is going on (I suspect the ',' is doing some funny stuff).
So my questions are:
Is there a way around this?
Am I doing something terribly wrong by storing JSON in cookies?
if point_2 then, What would be a better way? (I'm mainly storing with Javascript and reading with RoR, and I figured parsing with the build in JSON functions would be easier.)

Your hash looks like this in ruby: [{id:23,amount:9},{id:37,amount:4}]
To turn it into json use [{id:23,amount:9},{id:37,amount:4}].to_json which will give you:
"[{\"id\":23,\"amount\":9},{\"id\":37,\"amount\":4}]"

Still not sure if what I'm doing is the right way to handle such situations but my supposed work around is as follows:
I call .replace(/,/g, '.'); in Javascript before storing the cookie, and I call .replace(/\./g, ','); after retrieving it in Javascript and .gsub(/\./, ",") after retrieving it in RoR.
Seems like a horrible workaround for me, but for the time being it is an OK solution for me as I'm 100% certain that there will never be dots used in this cookie.

Can't figure out a way to escape quotes in json in YouTube API

I am using the YouTube API and I'm using Python urllib2.urlopen() to send a GET request. Then I pass the result to Javascript. (I'm using Django)
So, something like this:
result = urllib2.urlopen('https://gdata.youtube.com/feeds/api/videos?'+query+'&max-results=1&alt=json')
I'm using jQuery to parse the JSON formatted response, however some YouTube videos/descriptions have double quotes and this breaks the parseJSON() function.
Any help would be highly appreciated.

the error was on my end (obviously) ..the error started with the fact that I didn't realize Django automatically escapes HTML characters due to security, and I hacked my own way of ignoring special HTML chars like & quot; which ended up malforming the json.
the easy fix (in case anybody uses django and ever runs into this problem) to escape special HTML chars is with {{ var|safe }} ..

How to encode periods for URLs in Javascript?

The SO post below is comprehensive, but all three methods described fail to encode for periods.
Post: Encode URL in JavaScript?
For instance, if I run the three methods (i.e., escape, encodeURI, encodeURIComponent), none of them encode periods.
So "food.store" comes out as "food.store," which breaks the URL. It breaks the URL because the Rails app cannot recognize the URL as valid and displays the 404 error page. Perhaps it's a configuration mistake in the Rails routes file?
What's the best way to encode periods with Javascript for URLs?

I know this is an old thread, but I didn't see anywhere here any examples of URLs that were causing the original problem. I encountered a similar problem myself a couple of days ago with a Java application. In my case, the string with the period was at the end of the path element of the URL eg.
http://myserver.com/app/servlet/test.string
In this case, the Spring library I'm using was only passing me the 'test' part of that string to the relevant annotated method parameter of my controller class, presumably because it was treating the '.string' as a file extension and stripping it away. Perhaps this is the same underlying issue with the original problem above?
Anyway, I was able to workaround this simply by adding a trailing slash to the URL. Just throwing this out there in case it is useful to anybody else.
John

Periods shouldn't break the url, but I don't know how you are using the period, so I can't really say. None of the functions I know of encode the '.' for a url, meaning you will have to use your own function to encode the '.' .
You could base64 encode the data, but I don't believe there is a native way to do that in js. You could also replace all periods with their ASCII equivalent (%2E) on both the client and server side.
Basically, it's not generally necessary to encode '.', so if you need to do it, you'll need to come up with your own solution. You may want to also do further testing to be sure the '.' will actually break the url.
hth

I had this same problem where my .htaccess was breaking input values with .
Since I did not want to change what the .htaccess was doing I used this to fix it:
var val="foo.bar";
var safevalue=encodeURIComponent(val).replace(/\./g, '%2E');
this does all the standard encoding then replaces . with there ascii equivalent %2E. PHP automatically converts back to . in the $_REQUEST value but the .htaccess doesn't see it as a period so things are all good.

Periods do not have to be encoded in URLs. Here is the RFC to look at.
If a period is "breaking" something, it may be that your server is making its own interpretation of the URL, which is a fine thing to do of course but it means that you have to come up with some encoding scheme of your own when your own metacharacters need escaping.

I had the same question and maybe my solution can help someone else in the future.
In my case the url was generated using javascript. Periods are used to separate values in the url (sling selectors), so the selectors themselves weren't allowed to have periods.
My solution was to replace all periods with the html entity as is Figure 1:
Figure 1: Solution
var urlPart = 'foo.bar';
var safeUrlPart = encodeURIComponent(urlPart.replace(/\./g, '.'));
console.log(safeUrlPart); // foo%26%2346%3Bbar
console.log(decodeURIComponent(safeUrlPart)); // foo.bar

I had problems with .s in rest api urls. It is the fact that they are interpreted as extensions which in it's own way makes sense. Escaping doesn't help because they are unescaped before the call (as already noted). Adding a trailing / didn't help either. I got around this by passing the value as a named argument instead. e.g. api/Id/Text.string to api/Id?arg=Text.string. You'll need to modify the routing on the controller but the handler itself can stay the same.

If its possible using a .htaccess file would make it really cool and easy. Just add a \ before the period. Something like:\.

It is a rails problem, see Rails REST routing: dots in the resource item ID for an explanation (and Rails routing guide, Sec. 3.2)

You shouldn't be using encodeURI() or encodeURIComponent() anyway.
console.log(encodeURIComponent('%^&*'));
Input: %^&*. Output: %25%5E%26*. So, to be clear, this doesn't convert *. Hopefully you know this before you run rm * after "cleansing" that input server-side!
Luckily, MDN gave us a work-around to fix this glaring problem, fixedEncodeURI() and fixedEncodeURIComponent(), which is based on this regex: [!'()*]. (Source: MDN Web Docs: encodeURIComponent().) Just rewrite it to add in a period and you'll be fine:
function fixedEncodeURIComponent(str) {
return encodeURIComponent(str).replace(/[\.!'()*]/g, function(c) {
return '%' + c.charCodeAt(0).toString(16);
});
}
console.log(fixedEncodeURIComponent('hello.'));

Escaping double hyphens in Javascript?

I have a Javascript bookmarklet that, when clicked on, redirects the user to a new webpage and supplies the URL of the old webpage as a parameter in the query string.
I'm running into a problem when the original webpage has a double hyphen in the URL (ex. page--1--of--3.html). Stupid, I know - I can't control the original page The javascript escape function I'm using does not escape the hyphen, and IIS 6 gives a file not found error if asked to serve resource.aspx?original=page--1--of--3.html
Is there an alternative javascript escape function I can use? What is the best way to solve this problem? Does anybody know why IIS chokes on resource.aspx?original=page--1 and not page-1?

"escape" and "unescape" are deprecated precisely because it doesn't encode all the relevant characters. DO NOT USE ESCAPE OR UNESCAPE. use "encodeURIComponent" and "decodeURIComponent" instead. Supported in all but the oldest most decrepit browsers. It's really a huge shame this knowledge isn't much more common.
(see also encodeURI and decodeURI)
edit: err just tested, but this doesn't really cover the double hyphens still. Sorry.

Can you expand the escape function with some custom logic to encode the hypen's manually?
resource.aspx?original=page%2d%2d1%2d%2dof%2d%2d3.html
Something like this:
function customEscape(url) {
url = escape(url);
url = url.replace(/-/g, '%2d');
return url;
}
location.href = customEscape("resource.axd?original=test--page.html");
Update, for a bookmarklet:
Link

You're doing something else wrong. -- is legal in URLs and filenames. Maybe the file really isn't found?

-- is used to comment out text in a few scripting languages. SQL Server uses it to add comments. Do you use any database logic to store those filenames? Or create any queries where this name is part of the query string instead of using query parameters?

Common sources of unterminated string literal [duplicate]

This question already has answers here:
javascript Syntax error : Unterminated string literal [duplicate]
(3 answers)
Closed 9 years ago.
I am trying to debug a JavaScript script that gets read in a Firefox extension and executed. I only can see errors via the Firebug console (my code is invisible to Firebug), and it's reporting a "unterminated string literal."
I checked the line and the lines around it and everything seems fine-parentheses, braces, and quotes are balanced, etc. What are other possible causes that I should be looking for?

Most browsers seem to have problems with code like this:
var foo = "</script>";
In Firefox, Opera and IE8 this results in an unterminated string literal error. Can be pretty nasty when serializing html code which includes scripts.

Look for linebreaks! Those are often the cause.

I would vote for jamtoday's answer if I had the "reputation"
If your data is coming by way of PHP, this might help
$str = str_replace(array("\r", "\n"), '', $str);

I just discovered that "<\/script>" appears to work as well as "</scr"+"ipt>".

Just escape your tag closures or use ascii code
ie
<\/script>
ie
</script>

You might try running the script through JSLint.

Look for a string which contains an unescaped single qoute that may be inserted by some server side code.

If you've done any cut/paste: some online syntax highlighters will mangle single and double quotes, turning them into formatted quote pairs (matched opening and closing pairs). (tho i can't find any examples right now)... So that entails hitting Command-+ a few times and staring at your quote characters
Try a different font? also, different editors and IDEs use different tokenizers and highlight rules, and JS is one of more dynamic languages to parse, so try opening the file in emacs, vim, gedit (with JS plugins)... If you get lucky, one of them will show a long purple string running through the end of file.

Have you escaped your forward slashes( / )?
I've had trouble with those before

I've had trouble with angled quotes in the past ( ‘ ) usually from copy and pasting from Word. Replacing them with regular single quotes ( ' ) does the trick.

Also, keep in mind that %0A is the linefeed character URL encoded. It took me awhile to find where there was a linefeed in my offending code.

If nothing helps, look for some uni-code characters like
\u2028
this may break your string on more than one line and throw this error

Maybe it's because you have a line break in your PHP code. If you need line breaks in your alert window message, include it as an escaped syntax at the end of each line in your PHP code. I usually do it the following way:
$message = 'line 1.\\n';
$message .= 'line 2.';

Have you tried Chromebug? It's the Firebug for extensions.

Try a "binary search". Delete half the code and try again. If the error is still there, delete half the remaining code. If the error is not there, put what you deleted back in, and delete half of that. Repeat.
You should be able to narrow it down to a few line fairly quickly. My experience has been that at this point, you will notice some stupid malformed string.
It may be expedient to perform this on a saved version of the HTML output to the browser, if you're not sure which server-side resource the error is in.

The web page developer guessed wrong about which encoding is used by the viewer's browser. This can usually be solved by specifying an encoding in the page's header.

Scan the code that comes before the line# mentioned by error message. Whatever is unterminated has resulted in something downstream, (the blamed line#), to be flagged.

Whitespace is another issue I find, causes this error. Using a function to trim the whitespace may help.

str = str_replace(array("\r\n","\n\r","\r", "\n"), '<br />', stripslashes($str));
This should work.