Thank you again for the clarification!
> I'm not sure how to explain it any more clearly: the backslash in this
> example is not a backslash. It's a byte within a multibyte character,
> which *entirely coincidentally* happens to have the same numeric value
> as an ASCII backslash. But it isn't a
"CN" <[EMAIL PROTECTED]> writes:
> INSERT INTO y VALUES ('y\134na');
> --"y\" and "na" are two Big5 characters.
I'm not sure how to explain it any more clearly: the backslash in this
example is not a backslash. It's a byte within a multibyte character,
which *entirely coincidentally* happens to h
> No, I'm suggesting that it shouldn't be let loose on Big5 data when it
> evidently hasn't a clue about that encoding. The byte in question
> *is not* a backslash, it's not even an independent character; and so
> changing it on the assumption that it is logically a backslash simply
> breaks the d
"CN" <[EMAIL PROTECTED]> writes:
>> 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?
No, I'm suggesting that it shouldn't be let loose on Big5 data when it
evi
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
"CN" <[EMAIL PROTECTED]> writes:
> 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 m
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
