Re: Encoding using the Frontend/Backend Protocol TCP/IP - Mailing list pgsql-general

From Kovalevski Andrei
Subject Re: Encoding using the Frontend/Backend Protocol TCP/IP
Date
Msg-id 4B05A8D4.7020500@gmail.com
Whole thread Raw
In response to Re: Encoding using the Frontend/Backend Protocol TCP/IP  (Raimon Fernandez <coder@montx.com>)
Responses Re: Encoding using the Frontend/Backend Protocol TCP/IP
List pgsql-general
Hi,

the string is ok, but the problem is inside the message. The length of the message is incorrect:

your message:
5100000046557064617465207472616E73616374696F6E7320736574206465736372697074696F6E3D27546573742056616C75657364C387272077686572652069643D313133
it should be:
5100000045557064617465207472616E73616374696F6E7320736574206465736372697074696F6E3D27546573742056616C75657364C387272077686572652069643D313133

Raimon Fernandez wrote:
On 19/11/2009, at 18:13, Raimon Fernandez wrote:
 
On 19/11/2009, at 17:27, Kovalevski Andrei wrote:
   
Hi

could it be that you have errors in your UTF8 string? For example you might use UTF16 encoding, it can explain why some characters force errors but others are not.     
It only happens with values like àéïçñ I think UTF8 can handle this ...   

yes, It can handle it ...

if I send the decoding by hand in a very simple update, it works, so there's something with UTF8 conversion that dosn't work ...

for example, instead of sending Ç i send their equivalent in UTF8 &HC3+&H87 and it works ...

thanks,

regards,



 

pgsql-general by date:

Previous
From: araza@esri.com
Date:
Subject: Issues with Redhat 4 Postgresql 8.4 and support of libxml
Next
From: Guillaume Lelarge
Date:
Subject: Re: Possible bug with array_agg