On 8/19/19 8:30 AM, Ben Boeckel wrote:
> On Mon, Aug 19, 2019 at 08:16:26 +0300, Henri Sivonen wrote:
>> For formats that, for legacy reasons, support multiple encodings, the
>> benefit is that iäthe BOM unambiguously signals UTF-8. For UTF-8-only
>> formats, the benefit of not treating the BOM as an error is to allow
>> authoring with tools designed for the kind of formats where the BOM
>> actually signals UTF-8 relative to other possibilities.
> The format specifies that it only accepts UTF-8. Within that context, is
> it sensible to expect implementations handle a BOM? Remember that it is
> mostly a format between tools and it is JSON because being able to debug
> it is very useful (without mandating even more code for tools to inspect
> yet another container format). These things should not be written by
> hand or edited manually, so what does one gain by allowing an encoded
> BOM?

I thought you and I had discussed the use case, but perhaps I'm mistaken.

The typical example where a BOM would be helpful is on non-ASCII systems
like z/OS. If a BOM is allowed, then z/OS compilers could produce one
to allow the contents to be more easily inspected by simple text
viewing/editing tools. However, it may also be useful on Windows
systems where a file viewer/editor that is not JSON aware (e.g., doesn't
differentiate behavior for files with a .json extension) might otherwise
interpret the file according to the Windows ACP.

Tom.

>
> --Ben
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode