Recently, I’ve found myself maintaining a code base that involves, amongst other things, a fair bit of PHP code. I mean a lot. It’s been a few years since I’ve been elbow deep in PHP, and I figured it’d be like riding a bike. It is like riding a bike, and falling off still hurts.
The situation was this: A pair of pages built using very similar coding was returning a rather strange result. Specifically, we were getting the following character: �. For those in the know, this is an encoding error, and was happening on accented characters only. Simple and straight forward; we just needed to change the page encoding.
Anyone who thinks they have an answer will do one of two things:
- Stop; rethink; research and verify
- Plow ahead and implement the fix
Obviously, the right course is number 1. I did not choose number 1.
Changing the page encoding didn’t fix anything and resulted in some wasted time and energy trying to prove I’d made the right choice. This is why the scientific method is so very useful to programmers. It forces us to second guess ourselves, and, though it doesn’t seem to, will save time in the end.
So, I reviewed the symptoms:
- It only affects two pages
- Both pages use very similar code to generate the content
- Both pages rely on database entries for that content
- The page encoding was already changed by one of our non-technology staff (it’s a good excuse to work on those soft skills)
At this point, I applied a good dose of my desk to my forehead and checked the database. Low and behold, our encodings weren’t matching, and so I checked our existing PHP code:
Using it without enforcing encoding was causing us issues, and so a simple change was in order:
echo iconv("ISO-8859-1", "UTF-8//TRANSLIT", odbc_result($result,"fAbsMemo"))
Et voilà. A simple call to enforce the encoding. A rather simple fix that, because I didn’t stop and think for a second, cost me more time than it should have. It’s a valuable lesson: We may know a lot, but we forget things.