Error[8]: Undefined offset: 33, File: /www/wwwroot/outofmemory.cn/tmp/plugin_ss_superseo_model_superseo.php, Line: 121
File: /www/wwwroot/outofmemory.cn/tmp/plugin_ss_superseo_model_superseo.php, Line: 473, decode(

SQL Server数据迁移至PostgreSQL出错的解释以及解决方案

问题重现:

1、PG客户端:

postgres=# create table text_test (id int,info text);
CREATE TABLE
postgres=# insert into text_test values (1,E'
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' + '');
x00'); ERROR: invalid byte sequence for encoding "UTF8": 0x00

2、SQL Server产生数据

invalid byte sequence for encoding "UTF8": 0x00

然后通过java程序进行获取数据并插入到PG,同样会得到错误信息:

Byte 2

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

Bits Last code point Byte 1 Byte 3
Byte 4
Byte 5
Byte 6
U+07F
7 U+007F 0xxxxxxx




11 U+FFFFF
110xxxxx 10xxxxxx



16 10xxxxxx
1110xxxx 10xxxxxx
U+1FFFFF



21 10xxxxxx
11110xxx 10xxxxxx
10xxxxxx
U+3FFFFFF


26 10xxxxxx
111110xx 10xxxxxx
10xxxxxx
10xxxxxx
U+7FFFFFFF

31 10xxxxxx
1111110x 10xxxxxx
10xxxxxx
10xxxxxx
10xxxxxx

PostgreSQL doesn't support storing NULL (1x00) 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


而0x00是符合UTF8规则的。这就使我们非常诧异。然后我们发现有两点继而确认了问题:
1、

2

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

Backslash

if (!IS_HIGHBIT_SET(*mbstr))
    {
      if (*mbstr != '
#define IS_HIGHBIT_SET(ch)   ((unsigned char)(ch) & HIGHBIT)
#define HIGHBIT         (0x80)

') { mb_len++; mbstr++; len--; continue; } if (noError) return -1; report_invalid_encoding(encoding, mbstr, len); }

\\

Null terminator (nonvisible terminator)

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

\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):

[+++] [+++]

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源数据进行修改方法,

[+++]

2、对应用进行修改,获取到SQL Server数据时,将数据进行转化,和第一种方法异曲同工。

)
File: /www/wwwroot/outofmemory.cn/tmp/route_read.php, Line: 126, InsideLink()
File: /www/wwwroot/outofmemory.cn/tmp/index.inc.php, Line: 165, include(/www/wwwroot/outofmemory.cn/tmp/route_read.php)
File: /www/wwwroot/outofmemory.cn/index.php, Line: 30, include(/www/wwwroot/outofmemory.cn/tmp/index.inc.php)
Error[8]: Undefined offset: 34, File: /www/wwwroot/outofmemory.cn/tmp/plugin_ss_superseo_model_superseo.php, Line: 121
File: /www/wwwroot/outofmemory.cn/tmp/plugin_ss_superseo_model_superseo.php, Line: 473, decode(

SQL Server数据迁移至PostgreSQL出错的解释以及解决方案

问题重现:

1、PG客户端:

postgres=# create table text_test (id int,info text);
CREATE TABLE
postgres=# insert into text_test values (1,E'
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' + '');
x00'); ERROR: invalid byte sequence for encoding "UTF8": 0x00

2、SQL Server产生数据

invalid byte sequence for encoding "UTF8": 0x00

然后通过java程序进行获取数据并插入到PG,同样会得到错误信息:

Byte 2

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

Bits Last code point Byte 1 Byte 3
Byte 4
Byte 5
Byte 6
U+07F
7 U+007F 0xxxxxxx




11 U+FFFFF
110xxxxx 10xxxxxx



16 10xxxxxx
1110xxxx 10xxxxxx
U+1FFFFF



21 10xxxxxx
11110xxx 10xxxxxx
10xxxxxx
U+3FFFFFF


26 10xxxxxx
111110xx 10xxxxxx
10xxxxxx
10xxxxxx
U+7FFFFFFF

31 10xxxxxx
1111110x 10xxxxxx
10xxxxxx
10xxxxxx
10xxxxxx

PostgreSQL doesn't support storing NULL (1x00) 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


而0x00是符合UTF8规则的。这就使我们非常诧异。然后我们发现有两点继而确认了问题:
1、

2

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

Backslash

if (!IS_HIGHBIT_SET(*mbstr))
    {
      if (*mbstr != '
#define IS_HIGHBIT_SET(ch)   ((unsigned char)(ch) & HIGHBIT)
#define HIGHBIT         (0x80)

') { mb_len++; mbstr++; len--; continue; } if (noError) return -1; report_invalid_encoding(encoding, mbstr, len); }

\\

Null terminator (nonvisible terminator)

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

\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):

[+++]

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源数据进行修改方法,

[+++]

2、对应用进行修改,获取到SQL Server数据时,将数据进行转化,和第一种方法异曲同工。

)
File: /www/wwwroot/outofmemory.cn/tmp/route_read.php, Line: 126, InsideLink()
File: /www/wwwroot/outofmemory.cn/tmp/index.inc.php, Line: 165, include(/www/wwwroot/outofmemory.cn/tmp/route_read.php)
File: /www/wwwroot/outofmemory.cn/index.php, Line: 30, include(/www/wwwroot/outofmemory.cn/tmp/index.inc.php)
Error[8]: Undefined offset: 35, File: /www/wwwroot/outofmemory.cn/tmp/plugin_ss_superseo_model_superseo.php, Line: 121
File: /www/wwwroot/outofmemory.cn/tmp/plugin_ss_superseo_model_superseo.php, Line: 473, decode(

SQL Server数据迁移至PostgreSQL出错的解释以及解决方案

问题重现:

1、PG客户端:

postgres=# create table text_test (id int,info text);
CREATE TABLE
postgres=# insert into text_test values (1,E'
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' + '');
x00'); ERROR: invalid byte sequence for encoding "UTF8": 0x00

2、SQL Server产生数据

invalid byte sequence for encoding "UTF8": 0x00

然后通过java程序进行获取数据并插入到PG,同样会得到错误信息:

Byte 2

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

Bits Last code point Byte 1 Byte 3
Byte 4
Byte 5
Byte 6
U+07F
7 U+007F 0xxxxxxx




11 U+FFFFF
110xxxxx 10xxxxxx



16 10xxxxxx
1110xxxx 10xxxxxx
U+1FFFFF



21 10xxxxxx
11110xxx 10xxxxxx
10xxxxxx
U+3FFFFFF


26 10xxxxxx
111110xx 10xxxxxx
10xxxxxx
10xxxxxx
U+7FFFFFFF

31 10xxxxxx
1111110x 10xxxxxx
10xxxxxx
10xxxxxx
10xxxxxx

PostgreSQL doesn't support storing NULL (1x00) 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


而0x00是符合UTF8规则的。这就使我们非常诧异。然后我们发现有两点继而确认了问题:
1、

2

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

Backslash

if (!IS_HIGHBIT_SET(*mbstr))
    {
      if (*mbstr != '
#define IS_HIGHBIT_SET(ch)   ((unsigned char)(ch) & HIGHBIT)
#define HIGHBIT         (0x80)

') { mb_len++; mbstr++; len--; continue; } if (noError) return -1; report_invalid_encoding(encoding, mbstr, len); }

\\

Null terminator (nonvisible terminator)

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

\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):

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源数据进行修改方法,

[+++]

2、对应用进行修改,获取到SQL Server数据时,将数据进行转化,和第一种方法异曲同工。

)
File: /www/wwwroot/outofmemory.cn/tmp/route_read.php, Line: 126, InsideLink()
File: /www/wwwroot/outofmemory.cn/tmp/index.inc.php, Line: 165, include(/www/wwwroot/outofmemory.cn/tmp/route_read.php)
File: /www/wwwroot/outofmemory.cn/index.php, Line: 30, include(/www/wwwroot/outofmemory.cn/tmp/index.inc.php)
SQL Server数据迁移至PostgreSQL出错的解释以及解决方案_sql_内存溢出

SQL Server数据迁移至PostgreSQL出错的解释以及解决方案

SQL Server数据迁移至PostgreSQL出错的解释以及解决方案,第1张

SQL Server数据迁移至PostgreSQL出错的解释以及解决方案

问题重现:

1、PG客户端:

postgres=# create table text_test (id int,info text);
CREATE TABLE
postgres=# insert into text_test values (1,E'
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' + '');
x00'); ERROR: invalid byte sequence for encoding "UTF8": 0x00

2、SQL Server产生数据

invalid byte sequence for encoding "UTF8": 0x00

然后通过java程序进行获取数据并插入到PG,同样会得到错误信息:

Byte 2

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

Bits Last code point Byte 1 Byte 3
Byte 4
Byte 5
Byte 6
U+07F
7 U+007F 0xxxxxxx




11 U+FFFFF
110xxxxx 10xxxxxx



16 10xxxxxx
1110xxxx 10xxxxxx
U+1FFFFF



21 10xxxxxx
11110xxx 10xxxxxx
10xxxxxx
U+3FFFFFF


26 10xxxxxx
111110xx 10xxxxxx
10xxxxxx
10xxxxxx
U+7FFFFFFF

31 10xxxxxx
1111110x 10xxxxxx
10xxxxxx
10xxxxxx
10xxxxxx

PostgreSQL doesn't support storing NULL (1x00) 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


而0x00是符合UTF8规则的。这就使我们非常诧异。然后我们发现有两点继而确认了问题:
1、

2

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

Backslash

if (!IS_HIGHBIT_SET(*mbstr))
    {
      if (*mbstr != '
#define IS_HIGHBIT_SET(ch)   ((unsigned char)(ch) & HIGHBIT)
#define HIGHBIT         (0x80)

') { mb_len++; mbstr++; len--; continue; } if (noError) return -1; report_invalid_encoding(encoding, mbstr, len); }

\\

Null terminator (nonvisible terminator)

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

\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):

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源数据进行修改方法,

2、对应用进行修改,获取到SQL Server数据时,将数据进行转化,和第一种方法异曲同工。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/889006.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-14
下一篇 2022-05-14

发表评论

登录后才能评论

评论列表(0条)

保存