Re: Registration of some code pages

[Ned Freed <ned.freed@mrochek.com>]

> On Tue, 07 Sep 2010 07:02:55 +0200, Shawn Steele
> <Shawn.Steele@microsoft.com> wrote:
> >> If I have a portable software, it should work on Unix as the same as
> >> it does on Windows.
> >> So the expectation that "shift_jis" on Windows means "Windows-31J"
> >> seems wrong.
> >
> > That's the fundemental problem.  If you have portable software and run
> > it on Unix and on Windows, and save your file using "shift_jis" you're
> > going to have some odd discrepencies.  Obviously that's not good, but
> > it's pretty entrenched.  Clearly we cannot expect Unix boxes to pretend
> > shift_jis is Windows-31J (but some apps do), however it's also a tad
> > unreasonable to expect Windows boxes to suddenly be very strict when
> > they encounter "shift_jis" as that would break a very large number of
> > documents that currently "work."

Adding another data point: We're under considerable pressure from our Japanese
customers to just add the 31J stuff to our shift_jis and iso-2022-jp tables and
be done with it. They will accept nothing less than the ability to use the
additional character and send them out labelled as iso-2022-jp, or less often,
shift_jis.

> I think we can expect all browsers to at least start "pretending" that
> shift_jis is Windows-31J. And similarly for all other encodings. And maybe
> changes to browsers find their way back upstream, but that is outside my
> interest area.

I'll probably get chided for saying this, but it sure seems to me that this
battle is already lost and we should suck it up and move on. It's always been
permissible to add characters to a chqrset, even though there are always going
to be implementations that are slow to support, or may never be upgraded to
support, the new characters.

So, unless there are cases where a code point has been used in conflicting
ways, why don't we just add the additional characters to shift_jis and
iso-2022-jp? (Perhaps a revision to RFC 1468 is in order.)

				Ned