UTF8 instead of UTF16 for international support

[pcrockett-pathway]

Issue description

I appreciate that WACS is friendly for international users and supports Unicode instead of just ASCII. However the choice of UTF16 (AKA Encoding.Unicode) really creates some weird problems. As a trivial example, if I run this command in PowerShell:

.\wacs.exe --help > help.txt

... it produces a text file that looks like this:

PowerShell inserts extra null characters because it assumes each two-byte character is actually two separate one-byte characters.

Parsing output looking for [WARN] and [EROR] also becomes more difficult because of this. In PowerShell, I'd normally expect to be able to do this:

$wacsOutput = .\wacs.exe [command line args]
# Now look for [WARN] or [EROR] messages in $wacsOutput

But PowerShell doesn't do this correctly. I actually have to do this instead:

$wacsOutputTempFile = Join-Path $PSScriptRoot "temp.txt"
Start-Process ".\wacs.exe" -ArgumentList $CommandArgs `
    -Wait `
    -RedirectStandardOutput $wacsOutputTempFile `
    -NoNewWindow
$wacsOutput = Get-Content -Encoding Unicode $wacsOutputTempFile
# Now look for [WARN] or [EROR] messages in $wacsOutput

Would it be possible to use the UTF8 encoding instead? This would give us the best of both worlds: It's still a Unicode encoding with the ability to display international character sets, yet it remains backward-compatible with shells that assume an ASCII encoding.

[WouterTinus]

We've used UTF8 initially for international domain support, but it turned out that at least in a classic cmd window, UTF16 works better for displaying certain Asian language characters while UTF8 falls apart for some reason, I think probably because of legacy stuff in the Microsoft console.

Perhaps it's possible to make Powershell aware of the UTF16 output encoding somehow?

https://stackoverflow.com/questions/49476326/displaying-unicode-in-powershell

[pcrockett-pathway]

Thanks for the link, that looks promising. I had not tried setting [console]::InputEncoding or [console]::OutputEncoding yet (though I'm unable to test at the moment).

Another option worth considering is perhaps adding an --encoding parameter, where UTF16 is the default, but a user could easily specify ASCII if they needed it. If this little PowerShell hack works, I could live without that feature, though others might appreciate it. This particular PowerShell quirk isn't the easiest thing to figure out.

[woutertinusf19]

A setting is always an option if it turns out that it's not possible to get Powershell to understand the output stream. Another thing that you might try in your case is to look at the log file instead of capturing the screen output.

[pcrockett-pathway]

I was able to try changing the input and output encoding, and that kind of fixed it. It now looks like wacs.exe outputs errors in a different encoding.

Here's an example of what I get when I run it normally:

 [EROR]  parameters cannot be changed during a renewal. Recreate/overwrite the renewal or edit the .json file if you want to make changes.


   [ I N F O ]   A   s i m p l e   W i n d o w s   A C M E v 2   c l i e n t   ( W A C S )

   [ I N F O ]   S o f t w a r e   v e r s i o n   1 . 0 . 0 . 0   ( R E L E A S E )

   [ I N F O ]   I I S   v e r s i o n   8 . 5

   [ I N F O ]   S c h e d u l e d   t a s k   l o o k s   h e a l t h y

   [ I N F O ]   P l e a s e   r e p o r t   i s s u e s   a t   h t t p s : / / g i t h u b . c o m / P K I S h a r p / w i n - a c m e

And here's an example of what I get when I change the output encoding to [Text.Encoding]::Unicode:

嬠剅剏⁝瀠牡浡瑥牥⁳慣湮瑯戠⁥档湡敧⁤畤楲杮愠爠湥睥污‮敒牣慥整漯敶睲楲整琠敨爠湥睥污漠⁲摥瑩琠敨⸠獪湯映汩⁥晩礠畯眠湡⁴潴洠歡⁥档湡敧⹳਍
 [INFO] A simple Windows ACMEv2 client (WACS)
 [INFO] Software version 1.0.0.0 (RELEASE)
 [INFO] IIS version 8.5
 [INFO] Scheduled task looks healthy
 [INFO] Please report issues at https://github.com/PKISharp/win-acme

So it looks like I fixed one thing, but broke another thing.

[WouterTinus]

There will be a setting for this in the next release :)

[WouterTinus]

Released in 2.1.0