I have a web page displaying inside an iframe when I access it from from local machine:
http://localhost/mypage.html
it will display the following text correctly in spanish:
Búsqueda
But if I call it from my website
http://mywebsiteurl.com/mypage.html
I get the following:
Búsqueda
notice the ú has been replaced by ú I have tried changing fonts but the results are the same. The files on the web server are the same as on my localhost. Any ideas? Could it have something to do with my apache or php configuration may be difrerent than on my localhost machine?
in your html tag add the following
<html lang="es">
What you need might be
AddDefaultCharset UTF-8
in your .htaccess
For more insight check this thread How to change the default encoding to UTF-8 for Apache?
I have a website hompage encoded on iso-8859-1.
Then into that website i include different css and javascript files encoded on utf-8.
There is a way for show correct characters into the page from js files without change all encoding?
It should not be an issue. You've probably failed to identify the encoding of some of the files. To be on the safe side:
Configure your web server to add a correct Content-Type HTTP header with a charset attribute, e.g.:
Content-Type: application/javascript; charset=utf-8
When the language supports it, identify the encoding from the document itself, e.g.:
HTML 4:<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
HTML 5:<meta charset="iso-8859-1">
CSS:#charset "UTF-8";
Declare the charset when linking the resource, e.g.:
<script type="text/javascript" src="foo.js" charset="utf-8"></script>
(This is actually deprecated.)
In practice, you can probably omit some of these steps. I'd say #1 is the most important.
If you mix encoding, then you will face difficulty in future, especially if your pages contain different locales. So always use UTF-8 encoding.
Also you can change iso-8859-1 to UTF-8, without any changes in body as UTF-8 contains all characters of any encoding.
I don't know how should I titled this question but hope my friends will understand the problem and will help me :)
I want to show log message in arabic language using JavaScript alert() function, for which I code:
alert('أدخل سعر الافتتاح');
which means
alert('Enter opening price');
but when i save the .js file Dreamweaver says
and if I run the script browser says
this page contains
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
and i am using a lot of text in arabic which works fine.
now how can I use alert for different language?
just add your script like this:
<script src="/js/intlTelInput.min.js" charset="utf-8"></script>
Just like any other text file, .js files have specific encodings they are saved in. This message means you are saving the .js file with a non-UTF8 encoding (probably ASCII), and so your non-ASCII characters never even make it to the disk.
That is, the problem is not at the level of HTML or <meta charset> or Content-Type headers, but instead a very basic issue of how your text file is saved to disk.
To fix this, you'll need to change the encoding that Dreamweaver saves files in. It looks like this page outlines how to do so; choose UTF8 without saving a Byte Order Mark (BOM). This Super User answer (to a somewhat-related question) even includes screenshots.
Try to put in the head section of your html the following:
<meta charset='utf-8'>
I think this need to be the fist in head section. More information about charset: Meta Charset
Same problem here, solved with this:
In Eclipse (with .js file open and on focus), go to, "File", "Properties", "Resource", "Text file encoding" choose "Other:" UTF-8, put correct characters code inside the code save your file and you are done!
I think you just need to make
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
Before calling your .js files or code
For others, I just had a similar problem and had to copy all code from my file, put it to simple notepad, save it with utf-8 coding and then replace my original file.
The problem at my side was caused by using PSpad editor.
The encoding for the page is not set correctly. Either add a header
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
or use set the appropriate http header.
Content-Type:text/html; charset=UTF-8
Firefox also allows you to change the encoding in View -> Character encoding.
If that's ok, I think javascript should handle UTF8 just fine.
This is a quite old request to reply but I want to give a short answer for newcommers. I had the same problem while working on an eight-languaged site. The problem is IDE based. The solution is to use Komodo Edit as code-editor. I tried many editors until I found one which doesnt change charset-settings of my pages. Dreamweaver (or almost all of others) change all pages code-page/charset settings whenever you change it for page. When you have changes in more than one page and have changed charset of any file then clicked "Save all", all open pages (including unchanged but assumed changed by editor because of charset) are silently re-assigned the new charset and all mismatching pages are broken down. I lost months on re-translating messages again and again until I discovered that Komodo Edit keeps settings separately for each file.
I too had this issue, I would copy the whole piece of code and put in Notepad, before pasting in Notepad, make sure you save the file type as ALL files and save the doc as utf-8 format. then you can paste your code and run, It should work. ?????? obiviously means unreadable characters.
RobW is right on the first comment.
You have to save the file in your IDE with encoding UTF-8.
I moved my alert from .js file to my .html file and this solved the issue cause Visual Studio saves .html with UTF-8 encoding.
I found a solution to my problem that seems like yours.
For some reason a script called from a external file doesn't works with charset="UTF-8", instead i had to use charset="ISO-8859-1" into script tag.
Now I'm after the "why it works?" reason.
thanks friends, after trying all and not getting desired result i think to use a hidden div with that arabic message and with jQuery fading affects solved the problem. Script I wrote is:
.js file
$('#enterOpeningPrice').fadeIn();
$('#enterOpeningPrice').fadeOut(10000);
.html file
<div id="enterOpeningPrice">
<p>أدخل سعر الافتتاح</p>
</div>
Thanks to all..
I have an HTML document stored in a file, with a UTF-8 encoding, and I want my extension to display this file in the browser, so I call loadURIWithFlags('file://' + file.path, flags, null, 'UTF-8', null); but it loads it as ISO-8859-1 instead of UTF-8. (I can tell because ISO-8859-1 is selected on the View>Character Encoding menu, and because non-breaking-space characters are showing up as an  followed by a space. If I switch to UTF-8 using the Character Encoding menu, then everything looks right.)
I tried including LOAD_FLAGS_BYPASS_CACHE and LOAD_FLAGS_CHARSET_CHANGE in the flags but that didn't seem to have any effect. I also checked that auto-detect was turned off, so that wasn't the problem either. Adding <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> to the document seems to have solved the problem, but I would expect that using the 'charset' argument of loadURIWithFlags should work just as well, so I'm wondering if I did something wrong in my initial attempt.
You did the right thing and the only solution is to include encoding information inside the document because if you rely only on HTTP headers you will fail to load the document when the document is saved on disk (because there is no such thing as headers for files).
If you are the one saving the file you could add the UTF-8 BOM to the file in order to assure that it will be properly loaded by Firefox or other applications.
First the environment: the client is a mobile Safari on iPhone, the server consists of a Tomcat 5.5 fronted by IIS.
I have a piece of javascript code that sends a single parameter to the server and gets back some response:
var url = "/abc/ABCServlet";
var paramsString = "name=SomeName"
xmlhttpobj = getXmlHttpObject(); //Browser specific object returned
xmlhttpobj.onreadystatechange = callbackFunction;
xmlhttpobj.open("GET", url + "?" + paramsString, true);
xmlhttpobj.send(null);
This works fine when the iPhone language/locale is EN/US; but when the locale/language is changed to Japanese the query parameter received by the server becomes "SomeName#" without the quotes. Somehow a # is getting appended at the end.
Any clues why?
Hopefully, all you need to do is add a meta tag to the top of your HTML page that specifies the correct character set (e.g. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />) and match whatever encoding your datafiles are expecting.
If that doesn't work, ensure that you are using the same character encoding (preferably UTF-8) throughout your application. Your server-side scripts and any files that include text strings you will be adding directly to the response stream should be saved with that single encoding. It's a good idea to have your servers send a "Content-Type" HTTP header of the same encoding if possible (e.g. "text/html; charset=utf-8"). And you should ensure that the mobile safari page that's doing the displaying has the right Content-Type meta tag.
Japanese developers have a nasty habit of storing files in EUC or ISO-2022-JP, both of which often force the browser to use different fonts faces on some browsers and can seriously break your page if the browser is expecting a Roman charset. The good news is that if you're forced to use one of the Japanese encodings, that encoding will typically display right for most English text. It's the extended characters you need to look out for.
Now I may be wrong, but I THOUGHT that loading these files via AJAX was not a problem (I think the browser remaps the character data according to the character set for every text file it loads), but as you start mixing document encodings in a single file (and especially in your document body), bad things can happen. Maybe mobile safari requires the same encoding for both HTML files and AJAX files. I hope not. That would be ugly.