findstr is not Powershell. My suggestion would be to stay with the original complete cmdlet names. It is easier to read and easier to understand for yourself and for the people willing to help you.
Binary data is not what PowerShell can easily handle. When a string (and that’s what cat returns) goes through a pipeline, its encoding gets set to $OutputEncoding. PowerShell is just not the right tool in your case. So you need to find another method of finding things in a binary file. For example, you can write a C# program.
Well, maybe someone can help you do this by using .NET methods from PowerShell.
Yeah, that’s because it saves it in Unicode (UTF-16 Little-Endian). And when PowerShell tries to save raw binary data in Unicode, it screws it up. So please, don’t try to do this in PowerShell, it’s a pain. Just use an external tool for this. I don’t know the exact tool, but it’s quite easy to write one yourself.
Not, there is PS commutinty, not all of us - experts
@nimms say you about unicode, I say about get/set-content
You lookging for more expertise here ?
ok, I try… but want to mention, we have no crystall ball for distant seeing what your file look like and what you want to get from it. and we don’t know why you want to search something literal in binary file and want to have it untouched.
[expert mode on]
you get unicode encoded file because string in .net internally have unicode encoding and you use string-based cmdlets and redirection that directly save that representation to file.
if you try to use get/set-content with -encoding parameter you can directly control enconding of your data but lose string searching capabilities. (if you use ‘Byte’ value)
[expert mode off]
now you can read about unicode and read help for set-content. and finally make your work like you like