0

I have some old websites running with a character encoding, which might be to some degree questionable. But as they nevertheless all ran fine I did not yet took the effort to change it. Yet since last night suddenly encoding problems have become visible on these pages (which means all problematic characters which were shown fine all the time before are now replaced by "?"-symbols). I tested this with recent versions of IE, FF and Chrome.

As I have made no changes in the HTML or other website resources I am curious what has triggered those change in the displaying my website?

Further information which maybe might help:

- I use shared webhosting for those sites. Even though I didn't find a notice telling so, currently I consider some change the hoster made might be a likely reason, even though I am not sure what change would lead to the above effect.

- The above changes only happened in the online version but not in my local version (running on a differently configurated webserver) which contains the same Webcode (so local still looks the "fine" way as before). But as I visit both live and local version regularly I could not pin the now existing difference down to a caching problem.

- The text the website displays is hard coded within the HTML/PHP code in a ".php" file which is saved in ANSI format. I just tell this for better understanding what the issue is (though I am not seeking hints how to fix my encoding...). The definition part starts as follows:

<!DOCTYPE html>
<html>
<head>
<title>some title</title>
<meta charset="iso-8859-1">
Wooz
  • 306
  • 1
  • 2
  • 13
  • *"I have some old websites running with a character encoding"* – uhm, well, yes, *every* website runs with "an encoding"... – deceze Mar 08 '16 at 13:51
  • "... which might be to some degree questionable" :-) – Wooz Mar 08 '16 at 14:04
  • 1
    The fact that your websites run an encoding is questionable? ;o) – deceze Mar 08 '16 at 14:05
  • if YOU already start nitpicking MY encoding then I don't wonder anymore about any encoding problems of my website ;-) – Wooz Mar 08 '16 at 14:08

1 Answers1

1

Stab in the dark: your shared host has updated their servers/configuration and your pages are now served with a default HTTP Content-Type header declaring the page's encoding to be UTF-8. Since you're apparently not setting any more specific header yourself, the browser now misinterprets the page content.

Configure the web server to set the correct Content-Type header (likely with some directive in an .htaccess file, inquire with your host) or do it in PHP with a header() call.

See Handling Unicode Front To Back In A Web App, UTF-8 all the way through

Community
  • 1
  • 1
deceze
  • 510,633
  • 85
  • 743
  • 889
  • Hmm, that might be a good hint, even though I would think it a bit bossy of my provider to take it on them to define my encoding. I need to check before I can say if that is the reason. But I consider if that is the reason than the content-type set by provider will override my ?! – Wooz Mar 08 '16 at 14:15
  • Yes, HTTP headers have precedence over HTML meta elements. You should always ensure that your HTTP headers correctly denote the document's encoding; relying on just meta elements is never a good idea. – deceze Mar 08 '16 at 14:18
  • Hmm, seems you are right, at least if I read the reply header correctly: "Connection: keep-alive;Content-Encoding: gzip;Content-Length: 4905;Content-Type: text/html; charset=UTF-8;Date Tue, 08 Mar 2016 14:34:23 GMT;Server Apache;Vary Accept-Encoding" - do you spontanously know what "Vary Accept-Encoding" stands for? Does it make any difference for the previosly set "charset=UTF-8"? If you don't know I could google it myself later of course. – Wooz Mar 08 '16 at 14:42
  • 1
    Don't worry about `Vary` for now. `Content-Type` is the important line here. – deceze Mar 08 '16 at 14:44