adodbapi / string encoding problem

[Alex Martelli]

Achim Domma wrote:

> "Alex Martelli" <aleax at aleax.it> wrote in message
> news:0ZAcb.118994$hE5.4097227 at news1.tin.it...
>> You have to *EN*-code Unicode into string, with the same way the string
>> had been *DE*-coded to Unicode originally, in order to be sure to get
>> the same string back; specifically, you have to use the same *codec*
> [...]
> 
> Thanks Alex,
> 
> I understand that, but looking at the adodbapi code I could not find any
> call to encode/decode. The conversion seems to happen somewhere in
> win32com. Don't know if you will ever get your data back, once it's
> converted to Variant. ;-)

So, take control of your destiny: since you know you're using tools
that can only deal with Unicode (and thus will inevitably convert --
in ways that perhaps you don't know -- if you pass them bytestrings),
preempt their "unknown and unwanted" conversion by doing a Unicode
conversion yourself in ways you DO know and control.  UTF-16 sticks
2 bytes into each Unicode character -- you do need to be working with
strings of EVEN length, though.  Or else you can use, e.g., ISO-8859-1,
and resign yourself to spending one Unicode character per byte in
your "real" byte-string.

Or else, of course, you can use a "BLOB" field instead of a text
one; I think the keyword for that in the Jet engine's DDL SQL is
BINARY.  If you DO need to use Access to manipulate your db, though
(and I can see deucedly few other reasons to use a Jet engine...),
I think that might not work -- at least back when I was having to
work on MS platform, I seem to recall that Access could not truly
support BLOB fields (except perhaps with embedded SQL, but that was
not considered acceptable in most Access-addicted shops, since the
real reason to use Access was NOT having to understand SQL...;-).


Alex