Probably dependent on system encoding. I do not recall ever testing with anything other than UTF-8.

Are you using a slave? If so, does its encoding match that of the master, or differ? Use the locale command to check. Also from /systemInfo in Jenkins you can see the file.encoding according to Java.

BTW the behavior of freestyle projects is not of much interest from a diagnostic perspective, since Workflow uses a totally different system for both running external processes and for generating the build log than traditional Jenkins projects.

/systemInfo tells me the encoding is ANSI_X3.4-1968. I get the same failure whether running on the master or other nodes. I am setting LANGUAGE = en_US.UTF-8 and LC_ALL = en_US.UTF-8 in the environment variables config for my build nodes, but not for the master.

Output of 'locale' on the master:

LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Output of 'locale' on a build node:

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

So your master is set to use ASCII, meaning it cannot process such characters in files at all. The workaround is to set your master to use UTF-8 encoding, as virtually all modern Linux distributions do. If you cannot set it systemwide, I think you can run the Jenkins Java process with -Dfile.encoding=UTF-8.

Now I have had a debate with kohsuke about this but we do not see eye to eye. His perspective is that Jenkins should always store log files in the system native encoding, which I think is mainly useful for Japanese users who are accustomed to using one of the two or three traditional encodings in that country; it is only helpful if you are directly accessing the log file from the filesystem (over the web in console it is rendered according to the encoding of the browser, or the REST client in the case of consoleText). My position is that all text files stored by Jenkins should be in UTF-8; external processes forked on a slave can be assumed to produce output in the system native encoding, which should then be recoded internally to UTF-8.

Now the twist here is freestyle vs. Workflow. In the case of a freestyle build, the system encoding on the slave is noted when the build starts, recorded as part of the build record, and used to save the log. That allows the build to handle varying encodings in one CI server. But such a trick is impossible for Workflow, which starts the build and then gets a slave, or several, or none. So it cannot use a slave-specific charset. It could either use the master’s charset, as it currently does (meaning it cannot track output from slaves using a charset which is a superset of that); or it could use UTF-8 unconditionally, which might be a better idea (though I would need some flag to indicate old build logs saved in another character set).

In either case, process output should probably be recoded to that expected by the build log. This is devilishly hard to prove in an automated test, I am afraid.

FWIW, even setting it systemwide using locale didn't fix this, I had to add -Dfile.encoding=UTF-8 to my java arguments. Now my logs display nicely. Thanks for the explanation!