Hello!
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
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
and is inserted to backend something like this:
INSERT INTO x VALUES ('y\134na');
Where octets 'y' and character "na" are unprintable characters here in
terms of ASCII.
Problem is that this string is stored exactly the same as the input: "a5
5c 31 33 34 af e0" instead of "a5 5c af e0". The SELECT outputs the
escaped string (7 octets) instead of the unescaped string (4 octets),
too.
However, the server manages the following string differently:
INSERT INTO x VALUES ('A\134B');
and
SELECT * FROM x;
outputs
A\B
Its size stored in the column is 3 octets. This second case is exactly
what I need. I guess strings like "C:\dir" is properly processed too
though I did not test it.
Why server treats the first string in this undesired way?
Regards,
CN
--
http://www.fastmail.fm - Email service worth paying for. Try it for free
