From: Joseph Boyle (Boyle@siebel.com)
Date: Mon Nov 04 2002 - 10:46:09 EST
Software currently under development could use the identifiers for choosing
whether to require or emit BOM, like the file requirements checker I have to
write, and ICU/uconv.
The inability to update to one standard all possible consuming software one
might encounter (or for that matter human customers' opinions) is precisely
why producing and checking software has to handle both possibilities.
What would you mean by "the right thing" as far as emitting BOM? Should file
conversion programs only allow output of non-BOM? (or with-BOM?) Or should
they take the specification in an argument separate from the charset name?
As said before this unnecessarily requires extra logic.
From: Michael (michka) Kaplan [mailto:email@example.com]
Sent: Monday, November 04, 2002 7:23 AM
To: Joseph Boyle; Unicode Mailing List
Subject: Re: PRODUCING and DESCRIBING UTF-8 with and without BOM
From: "Joseph Boyle" <Boyle@siebel.com>
> Thanks for the dozens of responses discussing consumers' behavior on
> UTF-8 BOM. This is actually not what I'm concerned with, as I have to
> take it as
> given that there is both software that wants UTF-8 BOM and software
> that doesn't want it.
> Could we evaluate the need for separate identifiers for producing or
> describing UTF-8 with and without BOM, or viable alternatives to use
> in control input to a file encoding converter program or encoding
> checker program.
How on earth could a separate identier be USED unless software were updated
to use it? And if they are updating to do this, why couldn't they just fix
it anyway to do the right thing?
There is no need here for separate identifiers, as they would not solve the
problem, to the extent that a problem actually exists (I have yet to see
proof that there is such a problem?).
This archive was generated by hypermail 2.1.5 : Mon Nov 04 2002 - 11:18:52 EST