In comp.lang.python, Cameron Simpson <c...@cskk.id.au> wrote: > On 23Apr2019 20:35, Eli the Bearded <*@eli.users.panix.com> wrote: >> That feels entirely wrong. I don't know what b'\x9A' means without >> knowing the character set and character encoding. If the encoding is a >> multibyte one, b'\x9A' doesn't mean anything on its own. That's why I >> want to treat it as binary. > If you don't know the encoding then you don't know you're looking at a > hex digit. OTOH, if the binary data contain ASCII data then you do know > the encoding: it is ASCII.
Hmmm. Maybe I'm not making myself clear. ASCII "=9a" should decode to b'\x9A' and it is that binary byte for which I don't know the meaning and why I don't want to use "text internallly" for as suggested upthread. > If that is mixed with other data then you need to know where it > starts/stops in order to pull it out to be decoded. The overall data may > be a mix, but the bit you're pulling out is encoded text, which you > could decode. I do want to decode it, and possibly compare it for an exact match. And because there are different possible encodings of the same source data (consider the trivial case of "=9A" versus "=9a", I don't want to just keep it in raw form). Elijah ------ not to mention QP versus b64 -- https://mail.python.org/mailman/listinfo/python-list
