# Getting out of SQL\_ASCII, part 2

DevFeed: [Getting out of SQL\_ASCII, part 2](<https://devfeed.tech/articles/getting-out-of-sql-ascii-part-2-34360.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2010/02/getting-out-of-sql_ascii-part-2/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2010-02-23T16:30:00Z

Content type: tutorial

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [migration](<https://devfeed.tech/topics/migration.md>), [Scripting](<https://devfeed.tech/topics/scripting.md>)

Tags: [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [migration](<https://devfeed.tech/tags/migration.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [scripting](<https://devfeed.tech/tags/scripting.md>)

## AI overview

This tutorial explains how to migrate live PostgreSQL data from SQL_ASCII to UTF-8. It covers finding incorrectly encoded values, checking conversions with helper functions, cleaning invalid data, and preventing new badly encoded strings during the migration.

## Source excerpt

So, if you followed the previous blog entry, now you have a new database containing all the static tables encoded in UTF-8 rather than SQL_ASCII. Because if it was not yet the case, you now severely distrust this non-encoding. Now is the time to have a look at properly encoding the live data, those stored in tables that continue to receive write traffic. The idea is to use the UPDATE facilities of PostgreSQL to tweak the data, and too fix the applications so as not to continue inserting badly encoded strings in there.