Exporting env variables does not fix the mysqldump invalid byte sequence in UTF-8 error

[smith-neil]

I get hit with the "invalid byte sequence in UTF-8" issue when pulling our old sites to my local environment. Makes sense - those DBs are made up of several other charsets. The solution found at https://github.com/welaika/wordmove/wiki/invalid-byte-sequence-in-UTF-8-while-pushing---pulling-db doesn't work. I'm using zsh and have added both variables to my .zprofile, verified .zprofile is executed, and then sourced it but still get the same error from mysqldump.

Are there any cases where that solution doesn't work? And if so, what are they? Also, it might be beneficial to update that solution with those cases if they exist.

OS: Arch Linux Ruby Version: 2.3.1p112 Wordmove Version: 2.0.0 Using system Ruby

[alessandro-fazzi]

Actually that solution exclude just a limit case. But if you know that you have different charset and encondings on your db...well...Wordmove just don't know what to do. We decided not to have the responsibility to force UTF-8 potentially corrupting data.

Sparse thoughts:

1. I consider a DB with different charset/encoding a broken db. A bomb that could potentially explode somewhere sometime. Fix it if it's possible.

2. if you have additional tables - perhaps added by plugins - is acceptable to ignore those tables?

   mysqldump_options: "--max_allowed_packet=50MB --ignore-table=dbname.wp_cf7dbplugin_submits --ignore-table=dbname.wp_cf7dbplugin_st"

3. Sooner or later I'll integrate wp-cli as a Wordmove's requirement, in order to delegate the database translation responsibility to its wp search-replace command. There is a huge work there, it uses $wpdb to interact, it has some optimizations and so we should not spend all our efforts rewriting that. Wordmove is "just" a tool-chainer after all :)