I'm running into a character encoding issue when I load a dropdown using jQuery from an external js file. This only seems to happen when the JavaScript object is not within the page.
For example the below is the JavaScript object.
var langs = [
{value:'zh-CN', text:'中文 (简体) Chinese Simplified'},
{value:'en', text:'English'},
{value:'eo', text:'EsperAnt'},
{value:'es', text:'Español'},
{value:'ja', text:'日本語 (Japanese)'},
{value:'pt-PT', text:'Português'},
{value:'ru', text:'Русский (Russian)'},
];
If this is in my page with the proper meta tags <meta http-equiv="content-type" content="text/html; charset=utf-8" /> the below code works.
$(document).ready(function() {
// Fill language select
$.each(langs, function(i, j){
$('#LangSelect').append($("<option></option>").attr("value",j.value).text(j.text));
});
But, since I need languages on more then one page I've moved the langs object to an external js file and reference it. After doing this, I run into encoding issues such as russian characters become РуÑÑкий (Russian).
This encoding issues seems to still appear even when the reference to the external js file is set as below:
<script type="text/javascript" charset="UTF-8" src="externalJS.js"></script>
Is there anyway to force the JavaScript object to be loaded with the proper encoding from an external file?
Please note I am experiencing these issues when viewing content on the iPhone Mobile Safari browser. Additionally these pages are simply html and JavaScript without any server side components.
Thanks in advance,
Ben
Is there anyway to force the JavaScript object to be loaded with the proper encoding from an external file?
Yes, the script charset attribute as you quoted. However it historically didn't work everywhere and was best not relied on. Where this is not supported, the browser will always use the charset of the main page as the charset in the script. So as long as you include the UTF-8 charset parameter in the main page you should be fine either way.
I am surprised if a modern browser like Mobile Safari doesn't understand it, though.
Is it possible your server might be serving .js files with a bad Content-Type header containing a wrong charset? A combination of unset mime-types for JS plus AddDefaultCharset in Apache could leave you with:
Content-Type: text/plain;charset=iso-8859-1
Which might maybe have the effect of mucking it up.
Make sure you save the javascript file using UTF-8 encoding. If you open the file in Notepad++, then you can click Format>Encode in UTF-8 (If you try Format>Convert to UTF-8, then have a look at the page using a hex editor. Sometimes you end up with some strange characters at the beginning of the file).
Related
I am trying to run a script through HTML but I am having some problems. I searched online and found how to do so, however the issue is that even if I correctly type the path of the .js file, it seems to add some strange characters before it.
This is in index.html
<script type="text/javascript" src="fractalTest/fractalTest.js"></script>
I expected this to work but when I open index.html in google chrome and inspect then look under the elements tab, this "â©fractalTest/fractalTest.js" is replacing "fractalTest/fractalTest.js" in the path of the file. I believe this is whats causing the error but I do not know how to fix it!
...it seems to add some strange characters before it.
That usually means that the file is saved with a byte-order mark (BOM) of some kind, but isn't being sent with the correct charset for that byte-order mark.
Be sure that the server is configured to serve the files with a specific encoding (UTF-8 is a good choice), and that you save the files using that encoding (in your text editor, etc.). It's also usually best not to include a BOM on UTF-8 files (although it's valid, some tools don't handle it well).
Side note: No need for the type attribute. The default is JavaScript.
I've done some research and turns out that to encode special characters we use encodeURI(component) and decodeURI.
However when I try do something like:
var my_special_char = 'ñ';
my_div.innerHTML = decodeURI(encodeURI(my_special_char))
A "question mark" is printed.
I found this (non-complete) table about special characters: http://www.javascripter.net/faq/accentedcharacters.htm
Effectively when I do
decodeURI("%C3%B1"); // ñ
it prints ñ.
But if I try with:
decodeURI(encodeURI('ñ'))
I still get a "question mark".
How does character enconding work in JS? And where can I find a really comprehensive special characters' in encodeURI format (ready out-of-the-box to be decoded via decodeURI)?
EDIT:
in my (the application is an AngularJS application) I have meta charset=utf-8 (written in the right HTML syntax as proposed in the answer, it actually comes from AngularJS' starter project)
I'm using WebStorm IDE: I checked out the settings and the enconding used is UTF-8
I'm serving the page locally in Apache (XAMPP)
EDIT 2:
as advised in the answers, I created a .htaccess file in /htdocs whose content is:
AddDefaultCharset UTF-8
as well as renaming both index.html and the view's file by adding .utf8 before .html file extension.
then I restarted Apache (from XAMPP console).
But the issue is not gone. Any clue?
EDIT 3: I finally even tried to open the file in Sublime Text 3 and save as UTF-8 file, nothing changes
You don't have to do any special encoding in your JS strings (apart for the special case of strings which may be seen as script element closing).
If your JS file encoding matches the HTTP header (most commonly UTF-8), it's decoded if you just do
var my_special_char = 'ñ';
my_div.innerHTML = my_special_char;
To help the browser, and assuming you're correctly serving the files with the relevant HTTP header (the way it's set up highly depends on your server), you should have this meta tag in you HTML header:
<meta charset='utf-8'>
If your script is in a separate file, you should also declare the encoding in the script element:
<script charset="UTF-8" src="yourFile.js"></script>
You should add <meta charset="utf-8" /> inside your head tag. In this way the browser knows which charset to use and no more question marks will appear :)
in classic notepad it solved by clicking
file > Save As > in Encoding dropdown menu > UTF-8
in notepad++ by click
Encoding > Encode in UTF-8
or by adding charset attribute into metatag charset='utf-8'
<meta charset='utf-8'>
I'm running a Java project via Jetty Runner (7.6.15). I've been trying to play with D3.js lately, and I needed to serve it up unminified in order to debug some mystery problem. Well, D3 has some non-Latin Unicode characters in some variable names (like var π = Math.PI).
When I try to use that unminified file, I get errors because my browser thinks the character encoding is ISO-8859-1 instead of UTF-8. Sure enough, the "Content-Type" header in the server response has no character set.
I'm launching Jetty Runner with LANG and LC_ALL both set to "en_US.UTF-8", and I'm passing a system property file.encoding set to "UTF-8" as well on the Java command line. That apparently is not enough. I can look at the source file on my host and it's definitely intact; in fact if I load the JavaScript file directly from the browser address bar and manually tell Firefox that it's Unicode, then it looks fine.
I'm not launching Jetty Runner with a configuration file because I have no idea how to do that. It seems to add an explicit ISO-8859-1 marker to the content type header on the main HTML page (it's a single-page application), and that of course overrides the <meta charset> tag in the document head.
So is there a way to do this? Sometimes I feel like I'm one of the only 12 people on earth who use Jetty Runner :)
This turned out to be as simple as a clause in my web.xml:
<mime-mapping>
<extension>js</extension>
<mime-type>application/javascript; charset=UTF-8</mime-type>
</mime-mapping>
I don't know how something this obvious escaped my notice. It doesn't even have much to do with Jetty per se.
I need to include text of different languages in the javascript app that I'm writing, and the characters need to show up properly in different webpages that have different page encodings. The script is external.
I've read that in order to have the browser correctly interpret and display these characters, a charset tag should be added in the script tag. However, I am facing a few problems with this approach and would like to see if anyone could help.
The order of the charset seems to matter in IE9. Should "charset" be declared before "src" in the script tag? Is there such a specification or did anyone see a similar issue?
I've seen someone comment in another forum that the charset in an element will not be processed if the webpage defines a charset in the http content type/meta (or something along that line). Is this true? Does this mean that the charset in the script tag will be ignored then? If so, how to overcom
Are there any other recommended methods besides using charset in the script tag? Manipulating the webpages is not an option.
If I understood you correctly, you have multiple js files each one using a different encoding, and you tried the charset on the <script> tag but that is causing you troubles.
If so, have you tried not adding the charset at all and having the javascript files encoded in Unicode? I found that to be the best in having the browser actually render the correct fonts.
read this for some examples and let us know if it works out for you!
I have an a.js file written in windows-1251 charset.
Now, I have a b.php script, that has
header('Content-Type: text/html; charset=windows-1251');
in it. It also includes the a.js somewhere in the template.
So I'm loading b.php into c.php (also headered that way) using jQuery.load. What I get is ??? instead of normal words in the place where content is generated by js file. What is wrong?
The header() statement only applies to PHP output, and when your browser pulls the .js file it may treat it differently.
Are you able to edit that .js file and save it with other frequently used encoding (such as utf-8 or iso-8859-1)? There are many free editors that can load/save in different encodings. That might help.
<meta http-equiv="content-type" content="text/html; charset=windows-1251" />
at the top of the page affects this, the page you load in normal manner.