I'm having trouble displaying latin1 characters such as "ç", "ã" or "À" in the latest versions of Safari and Opera. I receive data (JSON) from a RoR backend using Ajax and JQuery (Latin1 charset) and the webpage itself relies on Latin1, thanks to:
<?php header('Content-Type: text/html; charset=ISO-8859-1');?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:og="http://ogp.me/ns#"
xmlns:fb="http://www.facebook.com/2008/fbml"
lang="pt">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
The custom Javascript lib i made also specifically states ISO-8859-1 when I perform the include some ten lines later on:
<script type="text/javascript" src="js/lib.js" charset="ISO-8859-1"></script>
Nevertheless, both browsers fail to display the characters afterwards. Safari shows the infamous black diamond, while Opera simply shows a blank space.
Any ideas? Thanks in advance
Most likely wrong charset sent in your Content-type: HTTP header for the JSON data. In your post you show the headers and META tags for the page itself and the included SCRIPT, but assuming the JSON data is sent separate it will be labelled separately. It would help to get a link to a page with this problem, but if you don't want to post one you can use a tool like Microsoft Fiddler HTTP debugger to inspect the headers that are being sent back and forth between the browser and the web site. If the web server sends
Content-type: text/html;charset=UTF-8
for a file with content in "latin" (iso-8859-1) or vice versa, that's your problem. Fix the HTTP header and you'll be fine.
Related
My web application is triggering quirks mode in IE8. It changes my doctype (html5) and then capitalizes every tag.
When I save the page in Google Chrome and open the saved page in IE8 it works fine.
Does anyone know what is going wrong here and how I can fix it?
What I already tried:
I read this and tried playing with comments before <html>, without
luck:
IE6 changes DOCTYPE to a bad one
I saw Google Chrome's saved version had a META tag defining the
content-type added. Tried inserting this in the page, and tried doing
this with php's header(), but without luck.
I tried other doctypes I found on this page:
http://dorward.me.uk/www/ie8/
Using the saved version is not an option because the page is generated with PHP.
Edit:
I tried putting the Google Chrome version on the web server, but IE fails on that version too. Are there any server settings which can affect IE's rendering of the page?
Edit2:
I tried
<!DOCTYPE html>
and
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
They were both changed to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">`
Found it. Internet Explorer's compatibility mode was on for websites on the internal network.
I could slap myself.
I've got some markup that I'm adding to a page component in Day CQ that was UTF-8 encoded by the author. Initially I couldn't save it in CRXDE, b/c the editor was set to save in ISO-8859-1. I found the setting to change this, but now when the page using this component is rendered to the browser, some of the characters appear to be using a different encoding. Is there a setting for the CQ web server, or servlet engine that I need to change? I'm running CQ 5.3 on Windows 7.
Edit: The HTTP Headers have Content-Type: text/html;charset=UTF-8 and there is a meta tag that specifies meta http-equiv="Content-type" content="text/html; charset=utf-8"
I believe the solution was to add pageEncoding="UTF-8" to all JSP's that are part of rendering this page. I also modified the web.xml file per this link: http://www.coderanch.com/t/87264/Tomcat/Character-Encoding-Tomcat, and restarted the server a number of times.
I am trying to display the japanese characters in my page. The page is working in all browsers except IE6. I noticed some sites http://translation.babylon.com/english/to-japanese/ display japanese characters as boxes. As i said earlier the page is working in all browsers except IE6.
The header i am using in the page is
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
and UTF-8 encoding
Could you please help to find out what is the issue.
Thank you
Usually content developer has to write right meta-tag for correct character decoding. Like this.
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
If there is no meta tag on the content, the browser has to decode the page by own auto decoding method. But auto decoding is not perfect. Sometime it works, sometime it doesn't work.
I am working on a website and when I try to validate the page get the following error:
The character encoding specified in
the HTTP header (iso-8859-1) is
different from the value in the
element (utf-8). I will use the value
from the HTTP header (iso-8859-1) for
this validation.
Here is the code in my header:
<!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">
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8"/>
I don't see where the iso-8859-1 is coming from. Any suggestions?
Thanks.
It's the webserver which specify the encoding in the HTTP header. It set it to iso-8859-1. But in your page, you wrote:
<meta http-equiv="Content-type" content="text/html;charset=UTF-8"/>
these two values are incompatible. I can only suppose that the webserver is right (it has sent the data anyway), and the validator makes the same assumption.
If you want to send UTF-8 encoded files, check that the content is really UTF8 encoded, and check the header informations. Ultimately the behavior depends on the webserver configuration and page generation.
That's the header of your HTML file, not the HTTP headers the server is sending. The meta element defines equivalents to HTTP headers. If both an HTTP header is sent and a meta element exists with the equivalent, the user agent must decide which to use. It might work in your browser but it seems the validator your are using gives precedence to the actual HTTP header.
So you have to figure out how to make your server send the correct Content-type header. If your page is generated by a PHP script you can use header('Content-type:text/html;charset=UTF-8'); at the beginning of your script to fix it.
Check the default HTTP headers that are sent (you can see this in firebug in the NET tab, if you use it).
There is probably a Content-Type header set to iso-8859-1.
HTTP headers are is different from the HTML header (which is part of the body of the HTTP message) - where your META tag specifies UTF-8 as the content type.
Since the two values are incompatible, you are getting an error.
Solution:
Make both content-types identical (either UTF-8, or iso-8859-1)
I'm trying to setup compatibility mode in one of our web products however I cannot get compatiblity mode to work via a particular server.
To recount what I've done so far:
I've set the the HTTP header X-UA-Compatible in IIS to IE=7
I've set also addded the meta element as the first element in the head element to the master page:
Using fiddler I've checked the HTTP traffic and I can see the header value and the meta element. Using the same browser (different tab) when I point to our staging server the document renders as IE7 brower mode and IE7 document mode. Which is great. Unfortunately when I point to the live server which is configured in the same way as the staging server the document renders as IE8 browser mode and IE7 document mode.
As a result when I check the dev tools the CSS which is being applied to the html element is
" ie ie8 CSS1Compat Win32"
vs
" ie ie7 CSS1Compat Win32"
Has anyone got any suggestions what I might have missed?
Note there is a blank line before DOCTYPE instruction (which is meaningful).
<!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" xmlns:b="http://www.backbase.com/2006/btl"
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:e="http://www.backbase.com/2006/xel"
xmlns:c="http://www.backbase.com/2006/command" xmlns:d="http://www.backbase.com/2006/tdl"
xmlns:x="http://woodmac.com/x">
<head><meta http-equiv="X-UA-Compatible" content="IE=7" /><meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /><meta http-equiv="expires" content="-1" /><meta name="robots" content="index,follow" />
<script type="text/javascript" src="Backbase/engine/boot.js"></script>
<link href="App_Themes/MANDA/print_style.css" type="text/css" rel="stylesheet" /><link href="App_Themes/MANDA/screen_style.css" type="text/css" rel="stylesheet" /></head>
<body>
Thanks,
Philip
Take a look at this site and see if you missed anything. It may be related to the doctype, but it looks like the meta tags should override that.
What url are you using to access each server? IE8 has an option which is enabled by default which will force "intranet", or single-name, domains to render in compatibility mode regardless of your XUA and other header settings (Tools > Compatibility View Settings > Display intranet sites in compatibility view).
If this setting is enabled and you are accessing one or the other of your staging and prod sites with something like http://servername, then this may be causing them to render differently regardless of your setting.
Recently I was faced with this issue and ended up requiring all servers to be accessed with a domain extension (e.g. http://servername.company.com), and set the XUA header to IE7. Now everything renders in IE7 mode regardless of the server its running on.