Apache latin character support

[gajjirajkumar]

Hello,

There is a requirement by the customer In order to display latin characters correctly in the UI, we need to add charset information in httpd.conf file.

We have added the AddDefaultCharset UTF-8 in httpd.conf.
Even after adding the above charset in httpd.conf the changes was not reflecting.

And there was a reply by the customer that



Even after adding those lines to httpd.conf file, I am not getting characters (like ö, ä, ü) properly sent to my application.

This works perfectly fine in my local system where I am not using apache web server. But fails when I deploy the same code to QA, where the Apache webserver is used.


Kindly help me in this case

[lucy24]

:: peering into crystal ball ::

The "default charset" declaration in the config file is getting overwritten by something further down the line, such as htaccess or <Directory> or even the individual document's header.

When you say "Latin" I assume you mean the "Latin-1" range-- the part that comes out different depending on whether you've set UTF-8 or ISO-Latin-1 encoding. (Or possibly, judging by your name, some other encoding entirely.)

What do your characters ö (&ouml;) and so on look like when they arrive at the page? Does ö turn into ö (A-tilde followed by pilcrow)? Please say yes, because that is the single most likely configuration ;)

[gajjirajkumar]

I think so

[phranque]

welcome to WebmasterWorld, gajjirajkumar!

have you tried the W3C Internationalization Checker?
http://validator.w3.org/i18n-checker/ [validator.w3.org]

you should also read through at least the introductory W3C techniques documents.

Internationalization Techniques: Authoring HTML & CSS:
http://www.w3.org/International/techniques/authoring-html [w3.org]

[lucy24]

Holy ###, phranque, what did you do? I opened this page and it came through in Thai encoding :)

Any declaration in the HTTP header will override information inside the page, causing problems for your content.

wtf!? The page itself is supposed to override everything!

You may not have control over the declarations that come with the HTTP header, and may have to contact the people who manage the server for help. On the other hand there are sometimes ways you can fix things on the server if you have limited access to server setup files or are generating pages using scripting languages. For example, see Setting the HTTP charset parameter [w3.org] for more information about ...

OK, will do...

It is very important to always label Web documents explicitly. HTTP 1.1 says that the default charset is ISO-8859-1. But there are too many unlabeled documents in other encodings, so browsers use the reader's preferred encoding when there is no explicit charset parameter.

OK. So when they say "inside the page" they don't mean "inside the page", they mean ... uh ... what do they mean? Probably "Go with the user's default unless this results in characters that are undefined or unavailable." In this thread, the first post was in Latin-1. (If I'd got here first it would have been UTF-8.) Since characters such as E4 and F6* don't occur in UTF-8, the browser has to use a one-byte encoding. Why mine picked Thai over 8859-1 is anyone's guess.

Anyway, we're beyond that. What we need to figure out is why kumar's text is-- apparently --being interpreted as ISO-Latin-1 when it started out as UTF-8. A missing charset declaration
:: insert boilerplate here ::
is obviously one possibility.


* It would work if the immediately following characters happened to be in the form [89AB]\h. But they're not.