i am getting execption while loading page in IE 10
HTML1114: Codepage utf-8 from (HTTP header) overrides conflicting
codepage iso-8859-1 from (META tag)
Related
When using Google PageSpeed tester, I get the following:
The following resources have no character set specified in their HTTP headers. Specifying a character set in HTTP headers can speed up browser rendering.
http://www.ntainc.com/
I have searched everywhere, and can't seem to figure out why it isn't "reading" my charset. I have it listed in the html document header:
<meta charset="utf-8">
And in my web.config file:
<?xml version="1.0" encoding="UTF-8"?>
and there is an .htaccess file:
AddDefaultCharset utf-8
I believe our server is an IIS. What am I missing?
The warning is referring to the HTTP Content-Type header. It is being sent by your webserver to the client like this:
Content-Type: text/html
It needs to be sent like this instead:
Content-Type: text/html; charset=utf-8
You need to check your webserver configuration. Your .htaccess addition should be adding the charset attribute to the header, but apparently is not. So either you put it in the wrong .htaccess file, or the server is ignoring it.
The fact that your HTML contains a <meta charset> tag is irrelevant to the warning, as the HTML is just arbitrary data inside of the HTTP response body (though it does allow an HTML5-enabled client to process your UTF-8 encoded HTML correctly).
Your web.config charset is irrelevant, as it is only interpreted by your webserver, not a client.
I am building a web application, and I have to handle international characters (with stuff like "J'ai surveillé des élève à la rôtule"). Some of the data is in arbitrary static text file that are in an arbitrary directory on the file system. Those files are all utf-8 (thanks standardization!)
To serve this data, I am using an embedded jetty, with the ResourceHandler handler. I don't have any web.xml file. In addition to the static, I have a bunch of restful API that get handled trough servlet.
Problem is, Jetty ResourceHandler class doesn't seem to send a charset along with the static file Content-Type . If I request index.html, Content-Type is text/html. To correctly handle accentuated character, I would like for it to be Content-Type: text/html; charset=utf-8
For file that have a default charset of utf-8 like text/html or text/css, this is fine, but some text file dont have one and get wrongly interpreted as Windows-1252 and the accented character get garbled (I just got a Québec Liquor Store back, instead of Québec Liquor Store). Is there a way to specify a default character set and tell jetty to always send it? Something like apache AddDefaultCharset utf-8
Hardcoding everything to UTF-8 is wrong.
How about just specifying the extension to mime-type mapping for those files you want to control?
MimeTypes mimeTypes = resourceHandler.getMimeTypes();
mimeTypes.addMimeMapping("txt", "text/plain; charset=UTF-8");
Why is W3C telling me I have no doctype set for my pages (in particular the home page)? My home page is using the 1column.phtml, which has a valid doctype (see below), and you can see it when you view the source in the browser. The w3c markup validation service is telling me there is no set doctype, why?!
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
Our development site is showing a valid doctype.. and I've even tried taking the 1column.phtml (root) template from there and replace the live one and still nothing. I'm at a total loss of what the issue is.
The first 8 lines of the home page as is being sent to the validator precede the doctype and say:
Strict Standards: Aitoc_Aitpagecache_Mobile_Detect::__construct() [aitoc-aitpagecache-mobile-detect.--construct]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EDT/-4.0/DST' instead in /home/goorins/public_html/lib/Aitpagecache/Mobile/Detect.php on line 42
Notice: Undefined index: HTTP_ACCEPT in /home/goorins/public_html/lib/Aitpagecache/Mobile/Detect.php on line 42
Strict Standards: setcookie() [function.setcookie]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EDT/-4.0/DST' instead in /home/goorins/public_html/lib/Aitpagecache/Mainpage.php on line 172
Warning: Cannot modify header information - headers already sent by (output started at /home/goorins/public_html/lib/Aitpagecache/Mobile/Detect.php:42) in /home/goorins/public_html/lib/Aitpagecache/Mainpage.php on line 172
Which appears to be coming from an AITOC magento plug-in. Means little to me (PHP/apache/magento is not my thing), but it looks to be that Mobile/Detect.php line 42 assumes that there will be an HTTP "accept" header to process. The HTML validator does not send a HTTP "accept" header, so an error is occuring which is reported at the top of the output page. It may be that because it is reporting the error, it also reports the warnings about a misconfiguration of the timezone settings.
Hard to say for certain without an in-depth debugging session, but my guess is it's the lack of any character encoding being sent back with your browser headers.
$ curl -I https://www.goorin.com/
HTTP/1.1 200 OK
Date: Tue, 23 Oct 2012 01:04:50 GMT
Server: LiteSpeed
Connection: close
Set-Cookie: frontend=7dcc17b985ecd8983ff6ade10e0f6f2c; expires=Tue, 23-Oct-2012 02:04:50 GMT; path=/; domain=..www.goorin.com; httponly
Set-Cookie: frontend=7dcc17b985ecd8983ff6ade10e0f6f2c; expires=Tue, 23-Oct-2012 02:04:50 GMT; path=/; domain=..www.goorin.com; httponly
Content-Type: text/html
which somehow causes the character encoding to get munged, and the validator no longer recognizes it.
Try downloading your home page with curl
curl -I https://www.goorin.com/ > home.html
and then using the W3C file upload validation service (the "Validate by File Upload" tab). When I did this, the validator stopped complaining about your DOCTYPE.
So, even if it's not the lack of character encoding in your headers, this points to the problem being the delivery of the HTML document from your server to the validator service.
I have an application in Java EE and I have my database in ISO-8859-1, thus I need do the jsp encoding in ISO-8859-1... (all my pages are in iso-8859-1)
I have a jsp with a javascript code, which does a request to a Struts action.
This is my js code.
$.ajax({
type:'GET',
encoding:'iso-8859-1',
contentType: 'text/html;charset=ISO-8859-1',
url: xUrl,
success: function(){
$("#MensajeOk").attr('style','display:block');
$("#MensajeOk").delay(10000).slideUp(1000);
}
});
with IE and Chrome all is correct, because it does the request coding in ISO-8859-1 but Firefox encodes the request in UTF-8 and this is a problem for me, because in server side I need ISO-8859-1 and with FF there are some characters than i can't recover.
mi form is
<html:form action="/action.do" acceptCharset="iso-8859-1">
<input type="text" name="title">
and my java code is
new String((request.getParameter("title")+"").getBytes("iso-8859-1"),"iso-8859-1"));
with it, I can recover fine the text with IE and Chome, but fails with Firefox.
Other option will be send the request in UTF-8 encoding by encodeURI('data') but in the server side I can't convert the text from UTF-8 to ISO-8859-1...
Some idea???
Thanks a lot and sorry for me english!!
looking at the documentation, there doesn't seem to be an option called encoding - but theres a nice little hint (including the solution to your problem) on the contentType-option:
Data will always be transmitted to the server using UTF-8 charset; you must decode this appropriately on the server side.
so it seems like firefox is right and the other browsers do it wrong - try to remove the encoding-option and to a serverside conversion.
One of the request parameters in an http request made by the client contains Japanese characters. If I make this request in Firefox and look at the parameter as soon as it reaches the server by debugging in Eclipse, the characters look fine. If I do the same request using IE 8, the characters get garbled when I look at them at the same point in the server code (they are fine in both browsers, though). I have examined the POST requests made by both browsers, and they both pass the same sequence of characters, which is:
%2C%E3%81%9D%E3%81%AE%E4%BB%96
I am therefore thinking that this has to do with the encoding. If I look at the HTTP headers of the request, I notice the following differences. In IE:
Content-Type: application/x-www-form-urlencoded
Accept: */*
In Firefox:
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
I'm thinking that the IE 8 header doesn't state the UTF-8 encoding explicitly, even though it's specified in the meta tag of the HTML document. I am not sure if this is the problem. I would appreciate any help, and please do let me know if you need more information.
Make sure the page that contains the form has UTF-8 as charset. In IE's case, the best thing to make sure of this is by sending a HTTP header ('Content-Type: text/html; charset=utf-8') and adding a meta http-equiv tag with the content type/charset to your html (I've seen this actually matter, even when the appropriate header was sent).
Second, your form can also specify the content type:
<form enctype="application/x-www-form-urlencoded; charset=utf-8>