Many thanks for the lightening fast answer!
> > The database cluster is initialized to use UNICODE. The client encoding
> > is set to BIG5. The middleware escapes the backslash in the following
> > string before writing to TEXT/VARCHAR column in server:
>
> > a5 5c af e0
>
> Seems to me that you need to fix your broken middleware --- it has no
> business doing that.
Are you suggesting that the middleware should not escape backslashes in
the first place?
The doc in
http://www.postgresql.org/docs/8.1/static/sql-syntax.html#SQL-SYNTAX-CONSTANTS
reads:
"Any other character following a backslash is taken literally. Thus, to
include a backslash in a string constant, write two backslashes."
My understanding on this statement is that escaping \ to \\ blindly for
any string and any encoding hurts nothing. Also, I thought that escaping
"\" to "\134" for TEXT column should be always equivalent to escaping it
to "\\", at least with this current (8.1) version.
> > This is a string comprises Big5 characters each of 2 octets big. Note
> > that the second octets, 5c, of the first Big5 character clashes
> > backslash '\'. Thus, this string is escaped to
>
> > a5 5c 31 33 34 af e0
>
> Now you have a 2-octet Big5 character, followed by 3 1-octet ASCII
> digits, followed by a 2-octet Big5 character. All the subsequent
> processing is doing what it should with this, AFAICS.
What I still don't realize is that as mentioned in my first posting,
"A\134B" gets stored in TEXT with value "A\B" but the Big5 string
escaped in the same manner yeids different result - the latter string is
stored in escaped form and becomes longer than intended. I thought two
2-octet Big5 characters would be stored in backend.
Regards,
CN
--
http://www.fastmail.fm - IMAP accessible web-mail
