Answers.Body: <p>In the end, I'm not sure what the problem was: either Adminer when either exporting and/or importing; or, the table collations being <code>latin1_swedish_ci</code>, even though both databases used the same collation; or even a conflict between the very old linux version and newer MySQL versions on the server.</p>
  
  <p>But I exported using mysqldump via SSH while forcing UTF, and then changed the  table collation to utf8_unicode_ci on the import database, and that worked.</p>
  
  <p>So, export directly from MySQL using mysqldump while forcing utf8:</p>
  
  <p><code>mysqldump -u root -p --default-character-set=utf8 my_database &gt; backup.sql</code></p>
  
  <p>Or use gzip, if needed:</p>
  
  <p><code>mysqldump -u root -p --default-character-set=utf8 my_database | gzip &gt; backup.gz</code></p>
  
  <p>Then I set the table collation on the database I was importing into at <code>utf8_unicode_ci</code>, and imported the database with Adminer.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-11T17:42:04.747Z
Answers.LastActivityDate: 2019-11-11T18:57:57.843Z
Answers.LastEditDate: 2019-11-11T18:57:57.843Z
Answers.UserDisplayName: BlueDogRanch
Answers.Body: <p>There is no encryption in CiviCRM. This sound something that your database dump got corrupted. Or that you imported in a database with another collation (character set) than the source database. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-08T16:16:59.060Z
Answers.Text: Database collations are exactly the same between the two: latin1_swedish_ci. Same database server. No other data is corrupted. I've tried importing multiple times.
Answers.UserDisplayName: BlueDogRanch
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-11T08:41:44.500Z
Answers.Text: Ehm that is strange. I don't know what migh cause this or how to solve this.
Answers.UserDisplayName: Jaap Jansma - CiviCooP
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-11T17:42:42.230Z
Answers.Text: Thanks, it was a strange issue; I added my own answer.
Answers.UserDisplayName: BlueDogRanch
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-07T21:17:10.560Z
Answers.LastActivityDate: 2019-11-07T21:17:10.560Z
Answers.UserDisplayName: Jaap Jansma - CiviCooP
Body: <p><em>Update 11-11-2019 See my answer below.</em></p>
  
  <hr>
  
  <p>When dumping a Drupal CiviCRM database to move and convert to a new WordPress install, I've found that the membership data appears to have been encrypted; these random character strings appear in WordPress in Memberships>Dashboard, i.e. <code>bs00fgcb</code> for name, <code>hgaibbsf@example.org</code> for email, etc. But the two letter state abbreviation isn't a random string.</p>
  
  <p>The garbage data appears in the database dump when viewed with a text editor, <em>before</em> I import into the new database.</p>
  
  <p>No other database data seems to be affected, and CiviCRM appears to run fine in WordPress, other than the data display above.</p>
  
  <p>Does this appear to be encryption? There are no encryption modules in Drupal (no Drupal Encrypt) that I can see., nor CiviCRM extensions Where would I find the functions that do the encryption and decrypting? In Drupal <code>[cms.root]/sites/default/files/civicrm/custom/</code>? Or could encryption be done at the MySQL level?</p>
  
  <p>CiviCRM is the same version between Drupal and WordPress; same MySQL database and encoding (both sites are on the same server). Database collations are exactly the same between the two: latin1_swedish_ci. No other data is corrupted. I've tried importing multiple times. </p>
  
Tags: <wordpress><drupal>
Title: Has this member data been encrypted?
ThreadText: # Has this member data been encrypted?
  
  (Asked by: username_0 on 2019-11-07)
  
  *Update 11-11-2019 See my answer below.*
  
  ---
  
  When dumping a Drupal CiviCRM database to move and convert to a new WordPress install, I've found that the membership data appears to have been encrypted; these random character strings appear in WordPress in Memberships>Dashboard, i.e. `bs00fgcb` for name, `hgaibbsf@example.org` for email, etc. But the two letter state abbreviation isn't a random string.
  
  The garbage data appears in the database dump when viewed with a text editor, *before* I import into the new database.
  
  No other database data seems to be affected, and CiviCRM appears to run fine in WordPress, other than the data display above.
  
  Does this appear to be encryption? There are no encryption modules in Drupal (no Drupal Encrypt) that I can see., nor CiviCRM extensions Where would I find the functions that do the encryption and decrypting? In Drupal `[cms.root]/sites/default/files/civicrm/custom/`? Or could encryption be done at the MySQL level?
  
  CiviCRM is the same version between Drupal and WordPress; same MySQL database and encoding (both sites are on the same server). Database collations are exactly the same between the two: latin1\_swedish\_ci. No other data is corrupted. I've tried importing multiple times.
  
  **Tags:** wordpress, drupal
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-11-07. Score: 3 | Accepted answer
  
  There is no encryption in CiviCRM. This sound something that your database dump got corrupted. Or that you imported in a database with another collation (character set) than the source database.
  
  > **Comments:**
  > **username_0**: Database collations are exactly the same between the two: latin1_swedish_ci. Same database server. No other data is corrupted. I've tried importing multiple times.  
  > **username_1**: Ehm that is strange. I don't know what migh cause this or how to solve this.  
  > **username_0**: Thanks, it was a strange issue; I added my own answer.  
  
  ---
  
  ### Answer by username_0 on 2019-11-11. Score: 3
  
  In the end, I'm not sure what the problem was: either Adminer when either exporting and/or importing; or, the table collations being `latin1_swedish_ci`, even though both databases used the same collation; or even a conflict between the very old linux version and newer MySQL versions on the server.
  
  But I exported using mysqldump via SSH while forcing UTF, and then changed the table collation to utf8\_unicode\_ci on the import database, and that worked.
  
  So, export directly from MySQL using mysqldump while forcing utf8:
  
  `mysqldump -u root -p --default-character-set=utf8 my_database > backup.sql`
  
  Or use gzip, if needed:
  
  `mysqldump -u root -p --default-character-set=utf8 my_database | gzip > backup.gz`
  
  Then I set the table collation on the database I was importing into at `utf8_unicode_ci`, and imported the database with Adminer.
  
  
  ---
  
  