[systemd-devel] Antw: [EXT] Re: Q: non-ASCII in syslog

Lennart Poettering lennart at poettering.net
Thu Apr 28 08:20:19 UTC 2022


On Do, 28.04.22 09:37, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> > There's plenty software that doesn't support RFC 5425, and putting a
> > BOM first is certainly not implemented in any of those. I think BOM is
> > hideous and defaulting to UTF-8 generally safe. If we'd put BOM first,
> > these messages would likely not be compatible with a large variety of
> > consumers anymore, because they can't handle BOM. This would be worse
>
> That's a non-argument:
> You say you don't adhere to any of the standards, and claim if you would do,
> things would break. ???

Yes, RFC 5425 is implemented by some logging infra, but it isn't by
all, and messages that are valid by rfc 5425 are not necessarily
compatible with messages generated/processed by software not knowing
rfc 5425. Adding the BOM is a sure way to guarantee software that
doesn't implement rfc 5425 won't be able to process your messages
anymore.

systemd's support for syslog (both on the generating and the consuming
side) is modelled after glibc's logging implementation, nothing
else. It also doesn't do BOM, hence we don't either.

> > than the status quo I am sure, since if we just send UTF-8 things
> > should generally just work fine for any software that either a) also
> > defaults to UTF-8 when encountering an 8bit char or b) is agonistic to
> > charsets and just passes data thorugh.
>
> Yes, put the head in the sand hoping problems are gone when you look up
> again... ;-)

I am pretty sure by inserting the BOM you create more
incompatibilities than you solve.

> > So, yeah, we might be stretching stdandards and tradition a bit, but
> > it actually works out quite well so far.
>
> A good argument for driving without a saftey-belt, BTW.

This comparison makes no sense. Please be civil.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list