對於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數據時，將數據進行轉化，和第一種方法殊途同歸。