Japanese text no longer displays

[freemink]

Hi,

Just posted this at f2s support but hope I may get a response here sooner:
=====================
Looks like all pages being served from my site (since the server migration?) are delivering pages with content-type=ISO-8859-1 regardless of the actual content of the page.

My pages should serve content-type=shift-jis (and some content-type=utf-8), but your servers are ignoring the meta content tags:
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">

Am I missing something here?
=====================

Has anyone else noticed this??

I have checked the http headers and I'm only seeing content-type=iso-8859-1. Whereas if I load the page onto another server I do see content-type=shift-jis.

Maybe I am misunderstanding?

Can anyone explain why my pages that used to display japanese text automatically now require me to set the encoding in the browser manually.

Thanks,
Darrell

[elrandom3]

I've seen this mentioned before.. you can create a .htaccess file in your folders, and if you add the following line for each of the file extensions you use, it should hopefully work

AddCharset shift-jis .html

[freemink]

Thanks for the incredibly fast reply.
I had already tried your suggestion and it didn't work.

I have just tried:

AddDefaultCharset shift-jis

and that does work!

But still, it's a hack isn't it? What happens if I have some pages that should be shift-jis, some utf-8 and others... I don't though :-) so AddDefaultCharset shift-jis does work.

I'm tying to figure if the http-header should set the content type based on the meta-tag or not?

Anyway, thanks again. I appreciate the response.

Darrell

[elrandom3]

Generally speaking, most sites tend to just stick with the one charset throughout. Obviously someone at Webfusion (see the sig!) didn't think properly when setting things up.

Meta tags are http-equiv, so they're interpreted by the browser as if they were HTTP headers. I think it's up to them which one they honour.

Might want to have a look at more .htaccess things to see if there's something else that'll override the default somehow.

[freemink]

Just confirmed, for my own benefit, the following rules of precedence:

http://www.w3.org/International/tuto...enc/#Slide0260

Precedence rules

In the case of conflict between multiple encoding declarations, precedence rules apply to determine which declaration wins out. For XHTML and HTML, the precedence is as follows, with 1 being the highest:
1. HTTP Content-Type
2. XML declaration
3. meta charset declaration
4. link charset attribute

...

So, the question is why do the f2s servers assume that my pages will be charset=iso-8559-1 ?

I think that sounds like a mistake?

I guess it would make sense if all my files (at least within any directory) were of the same encoding (preferably utf-8), in which case setting charset in .htaccess would be fine. But if I didn't have access to .htaccess, or if I do have mixed encodings, then what value is there in being careful about setting xml ot meta-tag types if the server is going to get the last say anyway?

Now if the server is supposed to inspect the file and try to determine the charset (from meta-tags for instance) and only set a http-header value if none is found, then that would make more sense. But if that is the case, then it's not happening on these f2s servers.

Also, these pages rendered fine before the migration...

Time for sleep I think.

[aos101]

Originally Posted by freemink

I'm tying to figure if the http-header should set the content type based on the meta-tag or not?

I've never heard of that happening, and think it's a bit unlikely. For that to happen, the webserver (Apache, IIS or whatever) would have to understand HTML/XHTML instead of just serve it up.

[freemink]

THanks for the response,

From the same page:
http://www.w3.org/International/tuto...enc/#Slide0260

In-document declarations. For these reasons you should always ensure that encoding information is also declared inside the document.

(Some people would argue that it is rarely appropriate to declare the encoding in the HTTP header if you are going to repeat it in the content of the document. In this case, they are proposing that the HTTP header say nothing about the document encoding. Note that this means specifically disabling any server defaults.)

Maybe this is what I am looking for - a way to disable the server default, and let the page meta tag carry the encoding information.

From reading the W3C page I see pros and cons to both sides, but it's a bit annoying that this server behaviour suddenly changed.

[freemink]

In case this is of interest to anyone else:

Maybe this is what I am looking for - a way to disable the server default, and let the page meta tag carry the encoding information.

This can be done by adding the .htaccess directive:

AddDefaultCharset off

see:
http://httpd.apache.org/docs/2.0/mod...defaultcharset

[Robert Wellock]

The HTTP 1.1 protocol is considered ASCII ISO-8859-1 by default thus most servers will use that unless they have been explicitly changed.