À 13:32 2000-02-09 -0800, Erik van der Poel a écrit:
> > I believe the problem is the same for HTML. I would prefer the
> > quick-and-dirty solution that assumes 8859-15 even if it is tagged 8859-1,
>This is a bad idea. I'm surprised that it came from you.
[Alain] To be put in perspective : I prefer a clean solution but if I have
the choice of quick-and-dirty flavours, I prefer to assume that the bad
coding assumes 8869-15 than a character set that can't get in on
environemnts which use the C1 space for controls. That's all what I am
saying. We have a problem witrh this, I have it. So I can't live with it.
> > rather than the one that assumes it is code page 1252 when tagged 8859-1.
> > This would allow for a harmonious operation between Macs, PCs, the Unix
> > world and IBM mainframes. Right now it is not clean, it does not work (for
> > the EURO sign and for French and Finnish), in addition to be a
> > quick-and-dirty solution (for which I, for one, am not fanatically opposed
> > when it makes things work).
>I believe that the best short-term solution for the euro in HTML is to
>use 0x80 with the "windows-1252" label.
[Alain] This solution does not worl in Unix environment or on mainframes
and interacts badly with Mac software. So I don't share your belief because
it is a proble and it will continue for a while.
> The best long-term solution is
>one or all of UTF-8/NCRs/CERs.
>(NCR = €
> CER = €)
[Alain] Probably, yes. Although a variable-length encoding is very
error-prone. So I would say is the least worst solution for the longer
term, not the ideal one. But I think resaonable people can agree with it.
After long thinking, I came to that conclusion too for the longer term.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:58 EDT