-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Closed
Labels
area-System.GlobalizationenhancementProduct code improvement that does NOT require public API changes/additionsProduct code improvement that does NOT require public API changes/additions
Milestone
Description
This is a follow-up from here.
-
Encoding.Default
in the full framework on Windows reports the legacy "ANSI" code page (encoding). -
Core doesn't support these legacy pages (by default) so its
Encoding.Default
must return an encoding that makes sense in a cross-platform world. -
Currently,
Encoding.UTF8
is returned, which is a UTF-8 encoding with BOM.- The reason for returning
Encoding.UTF8
asEncoding.Default
is a historic one, it seems, as the source-code comment mentions Silverlight(!).
- The reason for returning
-
UTF-8 with BOM is problematic on all Unix platforms, whose utilities do not expect a BOM and instead treat it as data, leading to unexpected results.
-
Having
Encoding.Default
return a UTF-8 encoding with BOM is pointless and confusing, because it neither represents any platform's nor the framework's own true default, and may cause disruption in practice.- Note that both .NET Framework's and .NET Core's true default is BOM-less UTF-8, because that's what's used in the absence of specifying an encoding with the methods of the
System.IO
class.
- Note that both .NET Framework's and .NET Core's true default is BOM-less UTF-8, because that's what's used in the absence of specifying an encoding with the methods of the
mletterle and iSazonov
Metadata
Metadata
Assignees
Labels
area-System.GlobalizationenhancementProduct code improvement that does NOT require public API changes/additionsProduct code improvement that does NOT require public API changes/additions