[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encodings.

This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.

Just read his post. Works for me, and with a little luck and possibly a
few tweaks if/as discovered through use to be nice/required, it could win
broader acceptance. (although I suspect that it may be found necessary to
base read-char, read-string, etc. on a flexibly defined "local" encoding
definition, rather than assuming all text/data is encoded any particular
way, on any particular platform.)

where with a: (bytes->value <bytes> <encoding>) -> <value>
and matching: (value->bytes <value> <encoding>) -> <bytes>

then multiple <encoding> procedures may be defined as desired/required,
which could default to "local" definitions if not explicitly specified.

thereby enabling any arbitrary sequence of encoded bytes read/written
from/to a port to be converted to/from a generic internal scheme value
type, using whatever external encoded representations may be required.

Thanks again, -paul-

> From: Robby Findler <robby@xxxxxxxxxxxxxxx>
> Date: Fri, 13 Feb 2004 09:01:45 -0600
> To: srfi-52@xxxxxxxxxxxxxxxxx
> Subject: Re: Encodings.
> Resent-From: srfi-52@xxxxxxxxxxxxxxxxx
> Resent-Date: Fri, 13 Feb 2004 16:01:57 +0100 (NFT)
> At Fri, 13 Feb 2004 03:00:51 -0500, Paul Schlie wrote:
>> Maybe I'm missing the boat, but from the best I can tell, all
>> discussions seem to be leading to the erroneous presumption that it's
>> adequate for scheme to restrict itself to exclusively processing data
>> originating, and destined as Unicode encoded text, which would be
>> most unfortunate.
> I don't think that this is the case. PLT Scheme, for instance (you may
> have seen Matthew's recent post on the plt-scheme mailing list), is
> going to have byte ports. If you do read-char on a byte port, the bytes
> coming out of the port will be interpreted as unicode (utf8 I believe,
> unless you specify otherwise) but you can also extract the bytes from
> the port directly.
> Robby