In this MySQL forum post, Erik runs into the confusing situation whereby he has to tell mysqldump to use the Latin-1 character set in order to get UTF-8 output. Bizarre magic? Well, no.

In any database-driven application, the encoding needs to be specified in several different places. If you’re a good developer, you’ll be using some Unicode encoding, quite possibly UTF-8. The problems arise when you send those UTF-8 bytes to your database.

It used to be the case (I don’t know if it still is) that the default encoding used by MySQL, unless you specified otherwise, would be Latin-1 (the collation rules applied would be those for Sweden, incidentally). Out of the box, with the defaults left alone, all of the text fields in all of your tables will be specified as containing Latin-1. In addition, your database connections will also use Latin-1. Amazingly, though, everything will seem to work.

Good is the enemy of Great
Latin-1 is the enemy of UTF-8
You write web apps. You understand the web is global, and want to support internationalization. You want UTF-8.
UTF-8 is extremely sane. Well, as sane as an encoding can be that features backwards-compatibility with ASCII.
Everything you care about supports UTF-8. Trust me: you want it everywhere.
Problem is, every last part of the web-application stack will fight you on your quest towards UTF-8 purity. What follows is a playbook to win your pervasive-UTF-8 battle.

Vad en mjukvaruutvecklare absolut minst måste veta om teckenkodning.

En genomgång av vad teckenkodning är och teckentabeller mm.

En mycket utförlig genomgång av teckenkodning för de som behöver förstå detta på djupet.