É o Unicode. O material que sai do sed é Unicode sem o prefixo de 2 bytes que o PowerShell usa para diferenciar entre Unicode e ASCII. Portanto, o PowerShell acha que é ASCII e deixa os bytes \ 0 (os bytes superiores dos caracteres Unicode de 2 bytes), que são exibidos como espaços em branco. E como internamente o PowerShell lida com Unicode, ele realmente expande cada byte original em um caractere Unicode de 2 bytes. Não é possível forçar o PowerShell a aceitar o Unicode. As possíveis maneiras de contornar isso são:
-
O Unicode vem como entrada para o SED? Improvável, mas acho possível. Verifique isso.
-
Faça a saída do SED iniciar com o indicador Unicode, \ uFEFF. Isso é provavelmente o que ficou perdido no código-fonte do SED:
_setmode(_fileno(stdout), _O_WTEXT); // probably present and makes it send Unicode wprintf(L"\uFEFF"); // probably missing
Você pode adicionar o código dentro do comando SED, algo como
sed "1s/^/\xFF\xFE/;..." # won't work if SED produces Unicode but would work it SED passes Unicode through from its input sed "1s/^/\uFEFF/;..." # use if SED produces Unicode itself, hopefully SED supports \u
-
Grave a saída de sed em um arquivo e, em seguida, leia com Get-Content -Encoding Unicode. Note que a mudança para o arquivo deve ser feita no comando dentro do cmd.exe, como:
cmd /c "sed ... >file"
Se você permitir que o arquivo > seja manipulado no PowerShell, ele será desarrumado da mesma maneira.
-
Elimine os caracteres \ 0 do texto resultante no PowerShell. Isso não funciona bem com os caracteres internacionais que criam os bytes Unicode contendo código 0xA ou 0xD - você acaba com os divisões de linha em vez deles.