对于SQL Server数据迁移至PostgreSQL出错的解释以及解决建议

        最近对SQL Server到PostgreSQL的数据迁移时出现了问题，返回的错误为：invalid byte sequence for encoding "UTF8": 0x00。

        经查证pg源代码，该问题引发的缘由是sql server的字符类型字段中含有空字符\0，该字符在pg中不支持。

问题重现：

一、PG客户端:

postgres=# create table text_test (id int,info text);
CREATE TABLE
postgres=# insert into text_test values (1,E'\0x00');
ERROR:  invalid byte sequence for encoding "UTF8": 0x00

二、SQL Server产生数据

create table test_varchar(id int,name varchar(20));
insert into test_varchar values (1, 'name' + char(0));
insert into test_varchar values (1, 'name' + '');

而后经过java程序进行获取数据并插入到PG，一样会获得错误信息：

invalid byte sequence for encoding "UTF8": 0x00

首先咱们认为此为gb2312转化到UTF8时，发生了没法转化的错误。经查UTF8是变长的, 1-6个字节。他的编码规则以下：

Bits	Last code point	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6
7	U+007F	0xxxxxxx
11	U+07FF	110xxxxx	10xxxxxx
16	U+FFFF	1110xxxx	10xxxxxx	10xxxxxx
21	U+1FFFFF	11110xxx	10xxxxxx	10xxxxxx	10xxxxxx
26	U+3FFFFFF	111110xx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx
31	U+7FFFFFFF	1111110x	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx	10xxxxxx

而0x00是符合UTF8规则的。这就使咱们很是诧异。而后咱们发现有两点继而确认了问题：

一、

PostgreSQL doesn't support storing NULL (\0x00) characters in text fields (this is obviously different from the database NULL value, which is fully supported).

If you need to store the NULL character, you must use a bytea field - which should store anything you want, but won't support text operations on it.

Given that PostgreSQL doesn't support it in text values, there's no good way to get it to remove it. You could import your data into bytea and later convert it to text using a special function (in perl or something, maybe?), but it's likely going to be easier to do that in preprocessing before you load it.

Source:http://stackoverflow.com/questions/1347646/postgres-error-on-insert-error-invalid-byte-sequence-for-encoding-utf8-0x0

二、

Terminating character	Indicated by
Tab	\t This is the default field terminator.
Newline character	\n This is the default row terminator.
Carriage return/line feed	\r
Backslash1	\\
Null terminator (nonvisible terminator)2	\0
Any printable character (control characters are not printable, except null, tab, newline, and carriage return)	(*, A, t, l, and so on)
String of up to 10 printable characters, including some or all of the terminators listed earlier	(**\t**, end, !!!!!!!!!!, \t—\n, and so on)

Source:http://msdn.microsoft.com/en-us/library/ms191485.aspx

由此咱们肯定，是pg对null的处理和SQL Server处理是不相同的，因此在这里出现了错误。

而致使这一问题的PG具体代码以下（src/backend/utils/mb/wchar.c的pg_verify_mbstr_len）：

if (!IS_HIGHBIT_SET(*mbstr))
		{
			if (*mbstr != '\0')
			{
				mb_len++;
				mbstr++;
				len--;
				continue;
			}
			if (noError)
				return -1;
			report_invalid_encoding(encoding, mbstr, len);
		}

#define IS_HIGHBIT_SET(ch)		((unsigned char)(ch) & HIGHBIT)
#define HIGHBIT					(0x80)

report_invalid_encoding函数是将错误信息返回，也就是

invalid byte sequence for encoding "UTF8": 0x00

而真正致使这一问题的就是：

!IS_HIGHBIT_SET(*mbstr)当*mbstr为0x00时进入判断，而后进而判断*mbstr是否为\0,当为\0时，直接进入函数report_invalid_encoding报错。

因此出现此问题的缘由是PG和SQL Server对null的处理是不相同的。

处理建议 ：

一、将SQL Server源数据进行修改方法，

UPDATE: This seems to work:

Select * from TABLE
where UNICODE(SUBSTRING(naughtyField, LEN(naughtyField), 1)) = 0
So:

Update TABLE
SET naughtyField = SUBSTRING(naughtyField, 1, LEN(naughtyField) - 1)
where UNICODE(SUBSTRING(naughtyField, LEN(naughtyField), 1)) = 0

Source:http://stackoverflow.com/questions/3533320/sql-server-remove-end-string-character-0-from-data

二、对应用进行修改，获取到SQL Server数据时，将数据进行转化，和第一种方法殊途同归。