\u00C2 is not defined error in javascript? - javascript

I got this error on following line.
$j(id).dateplustimepicker( "setTime" ,timeVal);
Can you please help me to solve this error?

The error is probably not in this line because no string constants are evaluated there. You wouldn't get this error if, for example, id contained the value.
When you get the error again, open the JavaScript console of your browser and look at the complete stack trace. The innermost frame is where you need to be looking.
[EDIT] Since you found the character in jquery-dateplustimepicker.js, this points to the real cause of the problem.
Every text file on your computer has an encoding. But there is no way to tell which one. The problem you have means: Your text/JS file is in UTF-8 encoding but your web server sends it to the browser with a different encoding. The browser then tries to read it but finds odd characters -> error.
Another reason for the error is that someone edited the file, using the wrong encoding. That can happen on Windows, for example, when you load the file with Cp-125x and saves it as UTF-8.
To check, download the file from the web server and do a binary compare with the original.

I got the answer but i forgot to upload here....Actually i got this problem because, There is  character is present in standard library file of jquery. File name is jquery-dateplustimepicker.js. The character either need encoding otherwise, it creates problem. The character must replace with white space instead of Â.

Related

Cross-Browser - Newline characters in textareas

In my web application (JSP, JQuery...) there is a form which, along with other fields, has a textarea where the user can input notes freely. The value is saved to the database as is.
The problem happens when the value has newline characters and is loaded back to the textarea; it sometimes "breaks" the Jquery code. Explaining further:
The value is loaded to the textarea using Jquery:
$('#p_notas').text("value_from_db");
When the user hits Enter to insert a new paragraph, the resulting value will include a newline character (or more than one char). This char is the problem as it varies from browser to browser and I haven't found out which one is causing the problem.
The error I get is a console error: SyntaxError: unterminated string literal. The page doesn't load correctly.
I'm not able to reproduce the problem. I tried with Chrome, Firefox and IE Edge (with several combinations of user agent and document mode).
We advise our users to use IE8+, Firefox or Chrome but we can't control it.
What I wanted to know is which character is causing the problem and how can I solve it.
Thanks
EDIT: Summing up - What are the differences in newline characters for the different browsers? Can I do anything to make them uniform?
EDIT 2: Looking at the page in the debugger, what I get is:
Case 1 (No problem)
$('#p_notas').text("This is the text I inserted \r\n More text");
Case 2 (Problem)
$('#p_notas').text("This is the text I inserted
More text");
In case 2 I get the Javascript error "SyntaxError: unterminated string literal." because it is interpreted as two lines of code
EDIT 3: #m02ph3u5 I tried using '\r' '\n' '\r\n' '\n\r' and I couldn't reproduce the problem.
EDIT 4: I'm going to try and replace all line breaks with '\n\r'
EDIT 5: In case it is of interest, what I did was treat the value before it was saved
value.replace(/(?:\r\n|\r(?=\n)|\n(?=\r))/g, '\n\r')
The problem isn't the browser but the operating system. Quoting from this post:
So, using \r\n will ensure linebreaks on all major operating systems
without issue.
Here's a nice read on the why: why do operating systems implement line breaks differently?
The problem you might be experiencing is saving the value of the textarea and then returning that value including any newlines. What you could do is "normalize" the value before saving, so that you don't have to change the output. In other words: get the value from the textarea, do a find-and-replace and replace every ossible occurrence of a newline (\r, \n) by a value that works on all OS's \r\n. Then, when you get the value from the database later on, it'll always be correct.
I suspect your problem is actually any new line in the entered input is causing an issue. It looks like on the server you are have a templated page something like:
$('#p_notas').text("<%=db.value%>");
So what you end up with client side is:
$('#p_notas').text("some notes that
were entered by the user");
or some other characters that break the JS. Embedded quotes would do it too.
You need to escape the user entered values some how. The preferred "modern" way is to format info you are returning as AJAX. If you are embedding the value within a template what I might do is:
<div style="display:none" id="userdata><%=db.value%></div>
<script>$('#p_notas').text($("#userdata").text());</script>
Of course if it were this exactly you could just embed the data in the text area <textarea><%=db.value%></textarea>
When you output data to the response, you always need to encode it using the appropriate encoding for the context it appears in.
You haven't mentioned which server-side technology you're using. In ASP.NET, for example, the HttpUtility class contains various encoding methods for different contexts:
HtmlEncode for general HTML output;
HtmlAttributeEncode for HTML attributes;
JavaScriptStringEncode for javascript strings;
UrlEncode for values passed in the query-string of a URL;
In some cases, you might need to encode the value more than once. For example, if you're passing a value in a URL via a javascript string, you'd need to UrlEncode the raw value, then JavaScriptStringEncode the result.
Assuming that you're using ASP.NET, and your code currently looks something like this:
$('#p_notas').text("<%# Eval("SomeField") %>");
change it to:
$('#p_notas').text("<%# HttpUtility.JavaScriptStringEncode(Eval("SomeField", "{0}")) %>");

js files are loading in unreadable format

I was working on a Web App. I used a "✗" UTF-8 character as a delete button. Eclipse asked me to save file in UTF-8 format i told yes. Everything worked fine. But next day when i ran the app again it is throwing exception "Uncaught SyntaxError: Unexpected token ILLEGAL". When i checked it, all javascript file is loading in unreadable format. See image below.
I tried to replace that character with its UNICODE "✗" and saved all js files in default encoding, but didn't help.
Do anyone know why is this happening?
It sounds like you saved in a different text format than you loaded it and/or loaded it in a different text format that you saved it. Without recommending a tool, I would see if you can use something to change the code-page/text-format and then try stuff.
However, seeing as what you are showing on teh screen is 3rd part stuff, you could just more easily re-download it where you got it the first time, or perhaps unpack it if you saved the installer/zip-file.

Uncaught SyntaxError: Unexpected token ILLEGAL - when splitting up a file

I have one big file that consists of HMTL, Javascript and CSS and I wish to split it up to make it more managable. But when I split the HTML file up and save it as seperate HTML, Javascript and CSS files I get the error :
Uncaught SyntaxError: Unexpected token ILLEGAL
When I click on the error it takes me to the file in the browser and my file consists of only Chinese symbols.
I have tried finding the answer and apparently I have hidden characters in my code but how am I meant to find these ?
What can I do to fix this issue ?
Mojibake like this can occur when the program reading in a file is unable to figure out what kind of encoding a file is using and guesses the encoding incorrectly. It could be that you have a weird character lurking in your file somewhere that is completely throwing off the encoding detection.
Some encoding schemes provide a way to mitigate this problem by using a BOM, which is a short marker at the beginning of the file that indicates the type of encoding that the file uses. BOMs have advantages and disadvantages, but one big advantage is that they firmly establish a file's encoding so that the program loading the file doesn't have to guess what the encoding is. It sounds like including the BOM in your file remedied your issue.
For more information on encoding, see:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Parsing a JSON string of 50,000+ characters into a javascript object

I'm trying to evaluate a string of 50,000+ characters from an ajax GET request using jquery. On smaller datasets, the code will evaluate it correctly, but firefox throws an error "Unterminated string literal".
After some digging, I tried using external libraries from JSON.org, replacing \n, \r\n, and \r with an empty string (on the server), and encapsulating the eval() with parentheses.
Here is some of the client-side code (javascript):
http://pastebin.com/wsXuN7tb <- Here I've used an external library to do it
After looking through firebug, I noticed that the json string returned by the server was not complete, and was cut off at 50,000 or so characters. I know for a fact the server is returning a valid json string because I dumped it to a file before sending it to the client, but the client ends up receiving a truncated version.
Why is this happening? Is there any way around this?
URLs have a length limit that varies from browser to browser. 50,000+ characters is definitely WAY over every browser's limit. For such large data, you should be using a POST instead.
There is quite literally NOTHING you can do about this limit, as it's a browser limit, and not something you can change on the server. The only thing you can go is switch to using POST.
Turns out the NetworkStream I used in my c# server could not have a buffer that large, so I just wrote half of the buffer, flushed it, and wrote the other half.
Thanks for helping guys.

Javascript Special Characters coming back incorrectly

There is a page where I have certain special characters on and when retrieving values of these via javascript I am getting an odd conversion. The character 'Œ' is coming back as 'R' and its lower case version 'œ' is coming back as 'S'. Is this a limitation of javascript or could it possibly be the browser. This is from testing in firefox. Also this is being retrieved via a repl client (Jssh/MozRepl) so it seems that it could be an issue with these clients themselves rather than the browser.
You likely have an encoding problem somewhere. There are many opportunities to mis-handle the encoding of text. If you post some code, we might be able to help you find it.
Output streams aren't scriptably safe for non-ASCII characters so you will need to wrap the stream in a nsIBinaryOutputStream, a nsIUnicharOutputStream or a nsIConverterOutputStream.

Categories

Resources