Re: Encoding using the Frontend/Backend Protocol TCP/IP

Поиск
Список
Период
Сортировка
От Kovalevski Andrei
Тема Re: Encoding using the Frontend/Backend Protocol TCP/IP
Дата
Msg-id 4B05A8D4.7020500@gmail.com
обсуждение исходный текст
Ответ на Re: Encoding using the Frontend/Backend Protocol TCP/IP  (Raimon Fernandez <coder@montx.com>)
Ответы Re: Encoding using the Frontend/Backend Protocol TCP/IP  (Raimon Fernandez <coder@montx.com>)
Список 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 по дате отправления:

Предыдущее
От: araza@esri.com
Дата:
Сообщение: Issues with Redhat 4 Postgresql 8.4 and support of libxml
Следующее
От: Guillaume Lelarge
Дата:
Сообщение: Re: Possible bug with array_agg