fix encoding of NfcProtocol.cs

[jdbruner]

Mea culpa.

Card/NfcProtocol.cs was created with the wrong encoding (was utf8, should be utf8bom)

Microsoft Reviewers: Open in CodeFlow

[krwq]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[krwq]

@pgrawehr possibly we need to rebase or make some artificial change so that your changes get picked up?

[krwq]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[krwq]

@jdbruner I think no-bom should be the default, if it's not, it's most likely incorrect :-)

[jdbruner]

@krwq I didn't notice this earlier, but something changed in my environment and I started getting a build error complaining about it.

Frankly I'd prefer no BOM. However, the .editorconfig does specify UTF-8 with BOM.

[krwq]

it sounds editor config is setup incorrectly

[pgrawehr]

No, this is on purpose. The bom guarantees correct encoding. We have several source files where the correct encoding is critical, as they contain non-ascii characters. Without the bom marker, it's likely some editors will get it wrong.

[krwq]

@pgrawehr I think at dotnet/runtime at least we've established no-BOM around 2015 as default because at this point UTF-8 is the standard and everything else is mostly some old relic. We should make sure we pick one and stick with it and AFAIK it's UTF-8 no BOM everywhere.

[pgrawehr]

@krwq At the moment, we have it everywhere, and I did have bad experiences when it was missing, so we shouldn't change it unless we see a reason. But let's discuss in the next call.

[krwq]

BOM is mainly used to check byte order - distinguish between little and big endian but UTF-8 doesn't have this problem. Also most Unix tools do not produce it and many don't expect it. Let's discuss it but this has already established pattern across dotnet/ repos...