Encoding issue with pages serving from Linux Apache to Firefox

[Quiet_in_the_Corner]

Hi,

I had a problem last year where my help files displayed as a blank page with a question mark when they were served from a Linux Apache Server to Firefox. All other browsers displayed the content perfectly fine.

I discovered that the issue had something to do with encoding. From what I understood at the time: RH 8 outputs in UTF-8 but Apache prefers UTF-16 so it tries to modify the page. Net result: Firefox can't interpret the page. I apologise if my description is terrible I never fully got my head around the issue.

To cut a long story short: I was able to fix this by chaging the encoding information at the top of each page from <?xml version="1.0" encoding="utf-8" ?> to <?xml version="1.0" encoding="utf-16" ?>

My client has produced a new version of their software this year and for some reason my Help doesn't work again, even with modified encoding information. I am assured that the Apache web server has not changed.

Does anybody have any suggestion?

Many thanks,

Alex

[Peter Grainge]

I think this is what I posted last year.

This is what I was advised by the company hosting my site.

"I would therefore conclude that the solution to this problem (on Linux systems running Apache) is to add the AddDefaultCharset utf-8 directive to either the Apache config or the site .htaccess file. The advantage of the latter is that it only affects individual sites. The default Apache character set is taken from the locale file on Linux and defaults to iso-8859-1. It is the conflict between the Apache header with iso-8859-1 and the page character set of utf-8 that obviously causes Firefox a problem."

In a forum post Chrissy_Tissy added

My machine is Windows, but this fix still worked  - some notes about making the fix visible:

1. Do the fix itself (httpd.conf: AddDefaultCharset utf-8).

2. Restart the box to apply the fix.

3. Once the box is restarted, clear your cache in FireFox to make sure you don't continue to see the cached file.

Once all this is done you will see the output content as expected.

There is a tool to change the encoding but that does nothing more than you have already done. Maybe showing your client the above will persuade them to change things at their end.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Quiet_in_the_Corner]

Hi Peter,

Thanks for coming back to me on this.

I remember a similar solution being proposed last year. The problem is my client wasn't keen then and isn't keen now to adjust their server. The solution we found back then was to edit the encoding information at the top of each page so that it referenced UTF-16 and not UTF-8. I believe you also sent me a replacement whcsh_home.html file, which I copied into the output.

To cut a long story short, these steps worked for the previous version. For some reason these same steps do not work now. Does that suggest that something has changed on the Apache Server? I.e, is it server pages differently?

Can you think of anything I might be missing in the RoboHelp output that might lead to this issue?

Alex

[Peter Grainge]

I don't think you are missing anything. As far as I am aware the client has to adjust their server, they won't, or you have to adjust your pages, that isn't working this time and I cannot offer anything as to why.

Could you not get the client to temporarily change the server to see if that is the solution? If you can get them to do that selling it on a "temporary" basis, maybe then they will just let it stay in place.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge