Skip to content

Use of non-ASCII-embedding encodings #173

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
oleg-nenashev merged 1 commit into from
Aug 17, 2018
+14 −0
Merged

Use of non-ASCII-embedding encodings #173

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions jep/206/README.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -183,6 +183,20 @@ this is likely a rare use case today.
In any event, making Jenkins architecture more complex and potentially buggy
to satisfy a marginal requirement seems a poor trade-off.

=== Use of non-ASCII-embedding encodings

No special consideration is given to encodings
which fail to act as a superset of ASCII at the byte level,
such as UTF-16 or EBCDIC.
These are unlikely to be practical system encodings for build machines anyway,
as encoding-naïve developer tools emitting hard-coded ASCII messages
could not be used in such an environment.

In the event a particular process does generate output in such an encoding,
it is safest to have the user script (passed to `sh` or the like)
convert that output to a safer encoding using various command-line tools.
That would be true even before this JEP.

== Backwards Compatibility

Jenkins clusters running on computers with UTF-8 set as the system encoding
Expand Down