Per Bothner <xxxxxx@bothner.com> writes:
>> I'm not sure what you mean by "directly," but SRFI 68 specifies
>> transcoders for Latin 1, UTF-16, and UTF-32.
>
> Are you serious? These are all trivial, and few people
> (no-one?) uses UTF-16 or UTF-32 for file storage/transmission.
You're taking my statement out of content---I was responding to your
assertion that the SRFI draft supports only UTF-8.
> How do you plan to support all the other Latin-X character sets,
> JIS, GB 2312-80, and ISO 2022?
> [...]
> I don't want to write transcoders. Other people have already written
> then, and it's a lot of work, and a lot of large tables. I want to
> use the existing Java trsnacoders or the existing C library
> transcoders.
Exactly. And if you look in the reference implementation, you'll see
that it's structured in such a way to make this as easy and efficient
as possible, for example via transcoders with an iconv-like API. In
fact, the stream API was designed with precisely this in mind.
> If I then as a beginning Scheme programmer write a program
> to read this file, I should not have to use an magic options
> or commands to do so - it should just work, even if my
> default encoding is different from with UTF-8.
Sure. I'm only pointing out that a notion of "default encoding" may
not exist on your platform, or that it may not be reasonable, even for
"default" cases, to enforce one upon the application. Specifically,
the "default encoding" may be different for files (or for files in
different file systems) and the console. It's a mess, but there you
go.
> But perhaps you could comment on do you expect this to work? Assume
> I'm Japanese and using some version of JIS. (Or a German using
> Latin-1, for that matter.) How should my Scheme implementation handle
> this?
Make (standard-input-port) and frieds return suitable transcoded
ports. I think you probably want this to work for files as well, but
I don't think it makes sense there, as explained above.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
