| 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規則的。這就使我們非常詫異。然后我們發現有兩點繼而確認了問題：
1、
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
2、
|
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的處理是不相同的。
處理方案 ：
1、將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
2、對應用進行修改，獲取到SQL Server數據時，將數據進行轉化，和第一種方法異曲同工。
