Resolve encoding issues

[bjorn]

My name is showing up as "Bj�rn" and I am unable to log in.

Probably happening since the server was upgraded to Apache 2.4 and PHP 5.5. I could try if downgrading to PHP 5.4 does anything.

[bjorn]

Issue can't be resolved by downgrading to PHP 5.4. That seems to have no effect.

[Poikilos]

Maybe you could change your username to bjorn using mysql itself. I can help write a query for the mysql prompt if necessary. Some databases use username as salt, so if password fails after that, maybe reset password. If other things stop working, more queries could fix that.

[bjorn]

@Poikilos I was hoping this could be solved another way, but given I'm rather clueless about encodings when it comes to MySQL, PHP or website setup, I have taken up your suggestion. Indeed, changing to "Bjorn" and going through password reset (and after fixing errors in the emailer.php), I am able to log in again! :-)

[bjorn]

While I've closed this since the main issue is worked around, the issue remains that special characters like "ø" are rendered incorrectly where they have been used in forum messages are possibly other places.

I'm not sure if it's a problem with the database or the website itself. The "ø" was rendering fine when I inspected the database with phpMyAdmin, which suggests the problem could be with the website.

[Poikilos]

There are two places the encoding could be set.

• PHP file. They are text files, and may have a BOM (byte-order mark) at the beginning. If they didn't before I worked on them, then they are UTF-8 now, because pretty much all software defaults to that now.
• Specified explicitly in HTML: The files are HTML4. There may be various places the code assumes that, so I was hesitant to change the doctype tag and head tag, but it is probably best considering we know what it is using doesn't work. It is probably defaulting to UTF-8 anyway, hence the problem. If you put rpgdx.net into https://validator.w3.org, it can't even begin testing because it says there is a character that is not encoded in UTF-8. Chances are, we need to:
  1. convert every instance of ASCII oslash to UTF-8 oslash
  2. set encoding to UTF-8
  3. (?) I'm not sure if anything needs to be done in mysql itself. Changing the encoding in mysql at this stage (with all the data already there) may be worse instead of better. I would try 1 & 2 first, and see how that goes. I can help look into this further, such as by making a page that is validated by the checker site then comparing to what we have.

[bjorn]

Right, in fact the HTML is reporting:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

However, there's a HTTP header being sent as follows:

content-type: text/html; charset=utf-8

And it appears the header is getting precedence. Since the site has generally not been using UTF-8, it might be easiest for now to fix the HTTP header to match the content-type defined in the HTML.

[bjorn]

Alright, ebcfd360b22f15863d98970b5335c4bcd68eeb92 appears to resolve the issues.