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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4