[comp] encoding problem in IE7 ?

[Jean-Christophe Helary]

A Japanese person I work with tells me that this page:

http://www.doublet.jp

Is not displayed properly in IE7 (Japanese version I suppose).

She says that she has to manually change the encoding to Unicode UTF-8 to have it displayed.

Is there a problem with the encoding declaration ? I have no idea what is wrong...




Jean-Christophe Helary (JA/EN > FR)
------------------------------------
http://mac4translators.blogspot.com/
http://twitter.com/brandelune
http://www.doublet.jp

[Masako Sato]

Jean-Christophe Helary さん wrote:
> http://www.doublet.jp

> Is not displayed properly in IE7 (Japanese version I suppose).
>

Firefox (Main language English) has no problem.
Japanese IE6 shows a blank page. I removed IE7 when I bought current
PC, so I do not have IE7.


Masako Sato

[Jean-Christophe Helary]

On 26 nov. 2009, at 17:01, Masako Sato wrote:

> Jean-Christophe Helary さん wrote:
>> http://www.doublet.jp
>
>> Is not displayed properly in IE7 (Japanese version I suppose).

Thank you Masako for checking.

> Firefox (Main language English) has no problem.

Safari on Mac hasn't either.

> Japanese IE6 shows a blank page.

Would you mind trying to change the encoding to UTF-8 and see if that works ?

[Aaron Madlon-Kay]

It appears blank in IE8 on Japanese WinXP SP3 here. It showed up when
I made it "detect encodings automatically."

I see you have a number of HTML validation errors. I'd start by
fixing those.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.doublet.jp%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

-Aaron Madlon-Kay


On 11月26日, 午後4:29, Jean-Christophe Helary

[Brian Chandler]

Jean-Christophe Helary wrote:
> A Japanese person I work with tells me that this page:
>
> http://www.doublet.jp
>
> Is not displayed properly in IE7 (Japanese version I suppose).
>
> She says that she has to manually change the encoding to Unicode UTF-8 to have it displayed.
>
> Is there a problem with the encoding declaration ? I have no idea what is wrong...

Your page has a charset specification:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

(You don't have a doctype, so there seems even less point than usual
in the xhtml style " />"...)

The http headers just say "text/html":

HTTP/1.1 200 OK
Date: Thu, 26 Nov 2009 08:03:02 GMT
Server: Apache
Last-Modified: Thu, 12 Nov 2009 08:33:21 GMT
ETag: "1244-6555f640"
Accept-Ranges: bytes
Content-Length: 4676
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/html

IIRC, the http spec is very vague about the significance of the meta
tag specification vs the http header, but the header is supposed to be
more important. So if the header says nothing, and the meta tag
specifies utf-8 normal software would surely interpret this as utf-8,
but you're not dealing with normal software, so who knows. Perhaps
it's best to change the headers in your .htaccess file (or whatever)?

Brian Chandler

[Jean-Christophe Helary]

Thank you Aaron.

I have fixed the top page. Could you try again with IE ?

Jean-Christophe

> --
> To post: mailto:hon...@googlegroups.com
> List home: http://groups.google.com/group/honyaku
> FAQ: http://groups.google.com/group/honyaku/web
> Posters assume all responsibility for their posts; list owners do not
> review messages and accept no responsibility for the content of posts.

[Jim Lockhart]

Jean-Christophe:

As of 17:58 Jpn time, it now works automatically in IE8. Earlier my
results were the same as those reported by others: blank page until I
specified UTF-8, but know it detects it automatically regardless of the
IE setting.

Short and sweet--that's nice. Good luck with your company!

--Jim Lockhart

--Jim Lockhart
Hachioji, Tokyo

[Jean-Christophe Helary]

On 26 nov. 2009, at 18:09, Jim Lockhart wrote:

> Jean-Christophe:
>
> As of 17:58 Jpn time, it now works automatically in IE8. Earlier my
> results were the same as those reported by others: blank page until I
> specified UTF-8, but know it detects it automatically regardless of the
> IE setting.

Thanks ! Good to know !

> Short and sweet--that's nice. Good luck with your company!

Thank you. We existed as a "company" for 2 years already mostly for tax purposes and to be able to work with big local companies, but the crisis made us so super un-buzy in the summer that we decided to get a domain name and a home page as well.

I am pretty sure that won't generate much business, but it is nice to have. If only when clients want to check the domain name to see if there is anything behind it...

You'll notice that I have yet to get the French part done... :(

Jean-Christophe

[Masako Sato]

Jean-Christophe Helary さん wrote:
>
>> Japanese IE6 shows a blank page.
>
> Would you mind trying to change the encoding to UTF-8 and see if that works ?
>

With UTF-8, it's OK.


Masako Sato

[Jean-Christophe Helary]

Ok, now I have changed to UTF-8 with a BOM. And "auto-detect" even for Japanese should work.

Would you mind giving it a try ?

[JimBreen]

On Nov 27, 12:31 am, Jean-Christophe Helary

<jean.christophe.hel...@gmail.com> wrote:
> Ok, now I have changed to UTF-8 with a BOM. And "auto-detect" even for Japanese should work.

I suggest you remove the BOM. It's quite unnecessary with UTF8 as the
byte-order is fixed.

Jim

[Jean-Christophe Helary]

Thank you for the comment. That was what I did at first. But without a BOM it looks like IE did could not recognize the page as UTF-8 even though the header specified the encoding.

Now, with the BOM, it looks like IE is able to automatically recognize the encoding.

But it seems the situation is not the same for all the IE versions that have checked my file...

[pls]

Hello Jean-Christophe,

--- Brian Chandler <imagin...@despammed.com> wrote:
> Your page has a charset specification:
>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

Maybe you have already changed that, since i don't see it. :-)

Anyway, i would recommend to add the doctype and put the charset
specification in the first position of the "head" of the page, as follows:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="content-type" CONTENT="text/html;charset=utf-8">

In addition, as Aaron suggested, i would eliminate all coding errors - MSIE
might trip up on something that is unrelated to the charset entry.

Regards: Hendrik



.

.
--

--------------------------------------
What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009
http://pr.mail.yahoo.co.jp/banzuke/

[Brian Chandler]

Jean-Christophe Helary wrote:
> On 27 nov. 2009, at 06:00, JimBreen wrote:
>
> > On Nov 27, 12:31 am, Jean-Christophe Helary
> > <jean.christophe.hel...@gmail.com> wrote:
> >> Ok, now I have changed to UTF-8 with a BOM. And "auto-detect" even for Japanese should work.
> >
> > I suggest you remove the BOM. It's quite unnecessary with UTF8 as the
> > byte-order is fixed.
>
> Thank you for the comment. That was what I did at first. But without a BOM it looks like IE did could not recognize the page as UTF-8 even though the header specified the encoding.
>
> Now, with the BOM, it looks like IE is able to automatically recognize the encoding.

(As Jim says, the "BOM" (which it isn't really) has no normal
significance; but it _does_ prompt M$ systems to notice UTF-8. For
example, if you send a UTF-8 text file to M$ people, it helps to put
the "BOM" sequence at the front, or they phone up and say they can't
"open" the file.)

But before resorting to M$-kludges, look at what you are sending. If
you can run this command (cd temp first!):

wget --save-headers http://www.doublet.jp/

It will dump the complete output from the server in a file called
index.html. You will then notice the following:

The first part is the http headers, including one that says

Content-Type: text/html

This does not specify utf-8. Then the html document starts with the
<head> (*not* the same as the _headers_), and the first line is:

<title>株式会社DOUBLET - あなたが必要とする言語の翻訳、ローカリゼーション、DTP、通訳を提供します。</title>

This is in utf-8, but occurs *before* the first thing in the file that
mentions utf-8, which is the *next* line:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

Any system that does not default to utf-8 might have problems. So I'm
sure the following are good ideas:

o Put the <meta> tag charset specification first in the <head>
o Add the charset to the *header* sent by the server. Probably you can
simply change the default settings in .htaccess (assuming you're using
Apache)

I don't think the "BOM" is really a good idea -- it might possibly
upset standards-compliant systems that assume that the first non-
whitespace characters should be the <doctype> tag, or else there isn't
one.

Brian Chandler

[Aaron Madlon-Kay]

I have no specific experience with BOMs causing problems in the
context of web browsers, but the W3C (X)HTML validator flags it as a
"warning" (not an error) and notes that it can cause compatibility
problems with older useragents.

In short, I would also suggest removing it.

-Aaron

[Jean-Christophe Helary]

Brian,

Thank you for your help.

So, I removed the BOM, put the http-equiv meta tag at the top of the list and uploaded the file.

But when I run wget --save-headers http://www.doublet.jp/ I still get "Content-Type: text/html" where UTF-8 is not mentioned. Is that to be expected ? Or rather, does it work normally now in IE ?

Jean-christophe

[Brian Chandler]

Jean-Christophe Helary wrote:

> So, I removed the BOM, put the http-equiv meta tag at the top of the list and uploaded the file.

I think it's putting the meta tag first that makes the difference...

>
> But when I run wget --save-headers http://www.doublet.jp/ I still get "Content-Type: text/html" where UTF-8 is not mentioned. Is that to be expected ? Or rather, does it work normally now in IE ?

The headers are sent by your web server, so unless you change web
server settings nothing will change. Here's a sample page about
setting this in Apache:
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html

(I just noticed that in fact most of my pages don't have the charset
set by the server; well, semi-oops, perhaps I should do that some
time. If you generate web pages in php it's also easy to send headers
for specific files, if you use different charsets for some reason; I
was misremembering that, probably.)

Anyway, sending the header is probably the best thing to do, but
contrary to a comment on the page above, it still makes sense to
include the <meta> tag, because then the charset spec is embedded in
the document itself. If you save a page you have downloaded from
somewhere this does not normally include the http headers.

HTH
Brian Chandler

[JimBreen]

On Nov 27, 4:07 pm, Brian Chandler <imaginator...@despammed.com>
wrote:

> The first part is the http headers, including one that says
>
> Content-Type: text/html
>

> This does not specify utf-8. ....

But it could, and should. The preferred place to set the
page coding is in this header, and the <met http ...>
method is now deprecated.

In WWWJDIC all pages start with:
Content-type: text/html; charset=xxxxx, with xxxxx set to
whatever coding has been selected (utf-8, euc-jp, etc.)

see: http://www.w3.org/International/O-HTTP-charset
http://www.w3.org/TR/html401/charset.html

Jim

[Brian Chandler]

JimBreen wrote:
> On Nov 27, 4:07 pm, Brian Chandler <imaginator...@despammed.com>
> wrote:
> > The first part is the http headers, including one that says
> >
> > Content-Type: text/html
> >
> > This does not specify utf-8. ....
>
> But it could, and should. The preferred place to set the

> page coding is in this header, and the <meta http ...>
> method is now deprecated.

I don't see how it can be deprecated -- in the sense of being a Bad
Thing to do -- because how else can/should you specify the encoding
*within* the document, for use if it is saved somewhere?

I recall that the specification is vague about the significance of the
two specifications, and in particular completely unclear about what
should happen if they conflict. Of course it's a Good Idea to make
sure that they are both specified and agree.

But one of the issues is that many people use a server outside their
own control, and are unable to send the correct server headers; in
which circumstances it is obviously preferable for the <meta> tag to
override the server setting. (Or certainly sensible for a browser
finding a problem with the server-specified encoding to give the
<meta> tag one a shot.)

Brian Chandler