1

I need to get a list of strings. I use the corresponding command and that works just fine. If I run it directly in Powershell, I get the list of strings with their complete name and correct characters. One of them is called "Diseño".

If I run the command directly in Powershell, I get this: enter image description here

But if I use the exact same command and assign its result to a variable, the variable prints this: enter image description here

I have no idea why this happens. It looks like just assigning values to a variable changes its encoding.

Does anyone know why this happens and how to prevent it?

Diego Arias
  • 171
  • 2
  • 14
  • 1
    In short: While the output from external programs may _print_ OK to the _console_, when it comes to _capturing the output in a variable or redirecting it_, PowerShell decodes the output into .NET strings, using the character encoding stored in `[Console]::OutputEncoding`. Therefore, you may have to (temporarily) set `[Console]::OutputEncoding` to the encoding used by the external program. See [this answer](https://stackoverflow.com/a/58438716/45375) to the linked duplicate for details. – mklement0 May 07 '21 at 13:01
  • 1
    Thanks for catching those typos, @BaconBits. I've deleted the original comment and have posted a corrected version. – mklement0 May 07 '21 at 13:02
  • @AbrahamZinala If I pipe the output directly to a Get-Member I get that is a String, but If I use GetType() it says is an Object[] – Diego Arias May 07 '21 at 13:49
  • @mklement0 Thank you very much for the explanation and the link to the other question. I found that and it helped me a lot to understand, but it didn't help me, I haven't been able to find which encoding the tf.exe uses for its outputs. I tried UTF8 and UTF8 no BOM, the character changed to other symbols, but still not the correct one. – Diego Arias May 07 '21 at 13:53
  • @mklement0 Thank you very much. I finally found the encoding I needed and the answer from the question you linked worked perfectly. I had to use this encoding `$TfvcOutputEncoding = [System.Text.Encoding]::GetEncoding('iso-8859-1')` – Diego Arias May 07 '21 at 14:53
  • 1
    Thanks for letting us know, @DiegoArias. It looks like it is the system's active _ANSI_ code page that `tf.exe` uses, which is [Windows-1252](https://en.wikipedia.org/wiki/Windows-1252) on English-language and Western European systems. With respect to printable characters, IS-8859-1 is a _subset_ of it, so it's better to use the actual ANSI code page (which, notably, can vary from system to system, depending on the system locale, aka language nor non-Unicode programs). [This answer](https://stackoverflow.com/a/67438483/45375), which is also `tf.exe`-related, shows how. – mklement0 May 07 '21 at 16:34
  • @mklement0 Thanks for the even more detailed answer focused on `tf.exe`. I actually tried using ANSI, but even with ANSI, specifically the character "ñ" continued causing problems. I don't know exactly why, but only when I use the exact subset `ISO-8859-1`, it worked for me. If someone else reads this, please follow the advice of using ANSI as your first approach. – Diego Arias May 07 '21 at 16:55
  • Interesting, @DiegoArias. It would be good to understand why the `ñ` is a problem. What does `Get-ItemPropertyValue HKLM:\SYSTEM\CurrentControlSet\Control\Nls\CodePage ACP` return on your system? Note that `ñ` has the same code point in both Windows-1252 and ISO-8859-1, as well as in Unicode which is a superset of ISO-8859-1: `0xf1` (`ñ` (LATIN SMALL LETTER N WITH TILDE, [`U+00F1`](http://www.fileformat.info/info/unicode/char/f1))) – mklement0 May 07 '21 at 17:01
  • @mklement0 Using `Get-ItemPropertyValue HKLM:\SYSTEM\CurrentControlSet\Control\Nls\CodePage ACP` returns 1252, as you sai. – Diego Arias May 07 '21 at 20:06
  • Thanks, @DiegoArias, then your problem must have been a different one, because, as stated, in Windows-1252 and ISO-8859-1 the letter `ñ` has the same code point: `[system.text.encoding]::GetEncoding('windows-1252').GetString(0xf1)` and `[system.text.encoding]::GetEncoding('iso-8859-1').GetString(0xf1)` both return `'ñ'`. – mklement0 May 07 '21 at 20:13

0 Answers0