In one of my asp.net-applications I found a strange behaviour produced in Internet Explorer 9 while IE8 works well.
As the default encoding I need utf-8. That's important because I use german so called Umlaute like "ÄäÖüÜü".
When the page is loaded for the first time IE9 decides to use "Western Europe" Encoding. That's ISO 8859-1 as far as I know and the Umlaute change to strange letters.
On the second load IE9 uses utf-8 correctly.
In the sourcecode I tried the following things to tell IE which encoding to use:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 TRANSITIONAL//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Why does IE9 work so strange on the first load?
And what else can I try to tell IE9 how to work
Firstable - server where you host your site can return wrong encoding information in header;
Two - maybe it's some fail in string that tolk about encoding in the header of your page (wrong symbol in that string).
Three - open you page in Hex brouser (WinHex for example) and post first row of code (sometimes editor place wrong data in first byte, I've stumble on it once)
If this site is placed online, post it's url and I try to find a problem.
Check response header of you server it must contains something like this:
Key Value
Content-Type text/html; charset=utf-8
Response HTTP/1.1 200 OK
if it's not then check you server settings or you code there must be place where Content-type header changes
EDIT: ok, encoding is right, as suggested in the comment you shoul check first bytes of you response, it seems like it starts with additional bytes (usually info about encoding)
Related
Caveat: Before someone goes and marks this as duplicate of this, please understand that it is not. The accepted answer is exactly what I am doing, yet I am facing the following issue.
HTML file in client folder looks like this:
<head>
<meta charset="utf-8"/>
<title>blah-blah</title>
---
The message I am getting in the firebug console is:
The character encoding declaration of the HTML document
was not found when prescanning the first 1024 bytes of
the file. When viewed in a differently-configured browser,
this page will reload automatically. The encoding
declaration needs to be moved to be within the first
1024 bytes of the file.
When I do a view source, between the head and the meta charset element, I see a whole bunch of link stylesheet and script tags.
If I remove the meta charset, I get this in the firebug console:
The character encoding of the HTML document was not
declared. The document will render with garbled text
in some browser configurations if the document
contains characters from outside the US-ASCII range.
The character encoding of the page must to be declared
in the document or in the transfer protocol.
How do I get the meta charset tag to appear right after the head?
What I did was edit /usr/lib/meteor/app/lib/app.html.in, and add the meta charset line so that the file now looks like this:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/> //**Added this line**
{{#each stylesheets}} <link rel="stylesheet" href="{{this}}">
{{/each}}
...
And of course I removed the meta charset line from my html files.
I think right now, this would be the way to go and this will be resolved in future revisions.
I had the problem in IE to force to use the latest version.
I had to add
<meta http-equiv="x-ua-compatible" content="IE=edge">
Directly behind the tag. And app.html.in seems not to be used anymore.
So I did this on tools/latest/tools/bundler.js
Line 783
'<head><meta http-equiv="x-ua-compatible" content="IE=edge">\n');
That forced it to add it in the html boilerplate.
When loading a page containing references to non-existing URL's using tags, I see a strange text reply from the server.
The server does return status code 404 as expected, but it also includes a text response with chinese-like characters.
Is the server infected, or is the error message just in a different language than english ... ?
If infected, how can I find out where?
Here is an example of the text replies. It seems that the reply is identical for each 404 error, although a part of it changes when a different filetype is not found.
㰡䑏䍔奐䔠桴浬⁐啂䱉䌠∭⼯圳䌯⽄呄⁘䡔䵌‱⸰⁓瑲楣琯⽅丢•桴瑰㨯⽷睷㌮潲术呒⽸桴浬ㄯ䑔䐯硨瑭氱瑲楣琮摴搢㸍਼桴浬⁸浬湳㴢桴瑰㨯⽷睷㌮潲术ㄹ㤹⽸桴浬∾ഊ㱨敡搾ഊ㱭整愠桴瑰ⵥ煵楶㴢䍯湴敮琭呹灥∠捯湴敮琽≴數琯桴浬㬠捨慲獥琽楳漭㠸㔹ⴱ∯㸍਼瑩瑬放㐰㐠ⴠ䙩汥爠摩牥捴潲礠湯琠景畮搮㰯瑩瑬放ഊ㱳瑹汥⁴祰攽≴數琯捳猢㸍਼ℭⴍ潤祻浡牧楮㨰㭦潮琭獩穥㨮㝥活景湴ⵦ慭楬示噥牤慮愬⁁物慬Ⱐ䡥汶整楣愬慮猭獥物昻...
You have a character encoding issue. It is a ASCII file that is being interpretted as a 2byte character encoding and thus you are getting the strange characters.
To translate it I copied the text to notepad. Saved it as Unicode-Big Endian and then used a hex editor to strip the first two characters (that tell it that it is unicode). Opening it again gave me:
<!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"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;
You would need to look into things to see if it is declaring the wrong content type in an HTML header (the content type in the meta tag looks correct) or something else is causing it problems.
I have a page in ASP.net (VB) that I'm serving via IIS.
The page is basically a translation of the uk site.
I have:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
at the top of the code, and all the characters show ok in the code.
however in (all) browsers many of the special polish characters, such as 'Ł' are missing, replaced directly with 'L'.
Is this an IIS thing? or could it be something else?
ETA: I just noticed that the polish text portion drawn out of the SQL database is being displayed correctly within the same page..! Odd!
Further edit:
I have found the basic source of the issue, I think, but not a solution:
The areas that are not showing properly are headers and footers, which are imported into the page via Server Side Include.
It seams some sort of encoding is being lost in this import / injection.
Should the imported file have some sort of encoding header?
This sounds like a problem with encoding in your static content files. The content-type <meta> has no bearing on the actual physical encoding of the file. I have a suspicion the file is saved in Codepage 1252 instead of UTF-8.
I suggest you open your *.aspx files (where I assume you're storing the problematic Polish text) in a text editor that supports different encodings (such as VS or Notepad2. Not WordPad or Windows Notepad). Force-save the file with UTF-8 encoding (in VS, go File > Advanced Save Options and ensure "Unicode (UTF-8 with signature)" is selected). Then access your site again.
Also ensure that the Content-Type HTTP header is also correctly set to UTF-8.
We have a website that uses Classic ASP.
Part of our release process substitutes values in a file and we found a bug in it where it will write the file out as UTF-8.
This then causes our application to start spitting out garbage. Apostrophes get returned as some encoded characters.
If we then go an remove the BOM that says this file is UTF-8 then the text that was previously rendered as garbage is now displayed correctly.
Is there something that IIS does differently when it encounters UTF-8 a file?
I was searching on the same exact issue yesterday and came across:
http://blog.inspired.no/utf-8-with-asp-71/
Important part from that page, in case it goes away...
ASP CODE:
Response.ContentType = "text/html"
Response.AddHeader "Content-Type", "text/html;charset=UTF-8"
Response.CodePage = 65001
Response.CharSet = "UTF-8"
and the following HTML META tag:
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
We were using the meta tag and asp CharSet property, yet the page still didn't render correctly. After adding the other three lines to the asp file everything just worked.
Hope this helps!
UTF-8 does not use BOMs; it is an annoying misfeature in some Microsoft software that puts them there. You need to find what step of your release process is putting a UTF-8-encoded BOM in your files and fix it — you should stop that even if you are using UTF-8, which really these days is best.
But I doubt it's IIS causing the display problem. More likely the browser is guessing the charset of the final displayed page, and when it sees bytes that look like they're UTF-8 encoded it guesses the whole page is UTF-8. You should be able to stop it doing that by stating a definitive charset by using an HTTP header:
Content-Type: text/html;charset=iso-8859-1
and/or a meta element in the HTML
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1" />
Now (assuming ISO-8859-1 is actually the character set your data are in) it should display OK. However if your file really does have a UTF-8-encoded BOM at the start, you'll now see that as ‘’ in your page, which is what those bytes look like in ISO-8859-1. So you still need to get rid of that misBOM.
If you using access db you should write
Session.CodePage=65001
Set tabtable= Conn.Execute("SELECT * FROM table")
While viewing the HTML IE 8 sets the default document mode as IE8 Standards as it should but it enters quirks mode on an asp page.
Even if I use <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
it doesn't really help.
What should I do?
First thing I would do would be place identical output in a HTM file and visit that instead. If you get different results then there really is something wierd going on because I doubt IE8 has any way to treat "asp" any differently.
BTW, How do you know its actually going into quirksmode?
What happens if you use stronger DTD like this:-
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Does it still remain in quirksmode?
You're not confusing IE7 compatibility with Quirksmode are you?
IE7 had a number of bugs in how it render even Standards mode HTML, perhaps what are seeing is IE7 compatibility instead.
Use fiddler to examine the headers being sent with the content. Is there a header like this:-
X-UA-Compatible: IE=EmulateIE7
in the response?
Is the Compatibility button present next to address in the brower UI?
The only thing that actually works is <meta http-equiv="X-UA-Compatible" content="IE=8"/>, other browsers will ignore it but IE will be forced to be in IE-8 mode unless you've done something really stupid like putting something before the HTML.
I write standards based classic ASP all the time. The things to check would be your HTTP headers. Make sure something isn't being inserted into your HTTP header to cause it to use quirks mode. Might check your IIS box to make sure there isn't something being sent in the "Custom HTTP Headers" section in IIS. Also, check that your doctype is indeed correct. Lastly, make sure that you do not have any of IE's special meta tags that can change the rendering mode. Just because classic ASP is old doesn't mean that the browser would display it any different than any other HTML page. Honestly the browser doesn't really even care what the extension is. If it is served as html mime type then it will render as such.