Deploy site, issue 1: funny characters appearing

I have 2 servers:
On one, with only private access, I do my development and testing.
The other one is public-facing.

When I have ensured my development site’s new features are working well, I copy all of my files from one webroot to the other, then I do a database export from the staging server, change the site URL in all the .sql files using a search-and-replace method, then import the modified .sql to the production server.

This has caused a number of issues (which I will cover in separate posts).

First issue:
Funny characters.
(example: this happens to apostrophe’s, double-quotes, hyphens, and there seems to be no rhyme or reason as to when it occurs or where, except that it seems to happen when I dump the database to .sql files. For example, sometimes I’ll see an apostrophe represented as ‘, and sometimes as \’, and sometimes as, (0x92), etc. But after the mysql export, I’ll see stuff like this:

??a€????

I’ve posted about this before, (and so have many others), and I’ve had no luck with this problem until yesterday.

Things I tried that didn’t work:
UTF-sanitize plugin.
Converting databases and tables from latin-1 to utf-8.
Making sure charset was set to utf-8 in wp-config.php
Painstaking MANUAL edits to correct the corrupted characters. (they re-appear in the .sql export/import process).
Installing mbstring extension in php. (it wasn’t installed, and I don’t have root access to the server, so I had to convince the owner).

The thing I did that did work:
I changed my export/import procedure. Instead of using MyPHPAdmin to export the files (or mysqldump. . . BOTH of these procedures caused the corruption), I used a series of piped commands, but I think the real solution has to do with the –default-character-set=utf8 options I used:

mysqldump –opt –compress –default-character-set=utf8 –user=<my_db_user> –password=<my_db_password> –host=localhost <my_staging_db_name> | sed ‘s%https:\/\/<my_staging_server’s_url>%https://<my_production_server’s_url>%g’ | mysql –default-character-set=utf8 –user=<my_db_user> –password=<my_db_password> –host localhost -D <my_production_db_name> -C <my_production_db_name>

This command allowed me to pipe the data stream straight out of mysqldump into mysql, skipping the intermediate stage where my data is sitting in a file, and probably getting encoded wrong in the process.

I know that I still don’t fully understand the cause of this problem, but I thought I would post my workaround that worked.