Es ist der Unicode. Das Ergebnis von sed ist Unicode ohne das 2-Byte-Präfix, mit dem PowerShell zwischen Unicode und ASCII unterscheidet. PowerShell denkt also, dass es sich um ASCII handelt, und belässt die Bytes (die oberen Bytes von 2-Byte-Unicode-Zeichen), die als Leerzeichen angezeigt werden. Da PowerShell intern mit Unicode arbeitet, erweitert es tatsächlich jedes ursprüngliche Byte in ein 2-Byte-Unicode-Zeichen. Dies ist keine Möglichkeit, PowerShell zu zwingen, Unicode zu akzeptieren. Die möglichen Wege sind:
Kommt Unicode als Eingabe in SED? Unwahrscheinlich, aber ich denke möglich. Prüfe das.
Lassen Sie die Ausgabe von SED mit dem Unicode-Kennzeichen \ uFEFF beginnen. Dies wurde wahrscheinlich im SED-Quellcode übersehen:
_setmode(_fileno(stdout), _O_WTEXT); // probably present and makes it send Unicode wprintf(L"\uFEFF"); // probably missing
Sie können den Code innerhalb des SED-Befehls hinzufügen
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
Schreibe die Ausgabe von sed in eine Datei und lese dann mit Get-Content -Encoding Unicode. Beachten Sie, dass die Umstellung auf Datei in dem Befehl in cmd.exe erfolgen muss, z. B .:
cmd /c "sed ... >file"
Wenn Sie> Datei einfach in PowerShell behandeln lassen, wird dies auf dieselbe Weise durcheinander gebracht.
Löschen Sie die \ 0-Zeichen aus dem resultierenden Text in PowerShell. Dies funktioniert nicht gut mit den internationalen Zeichen, aus denen die Unicode-Bytes bestehen, die den Code 0xA oder 0xD enthalten. Am Ende erhalten Sie die Zeilenaufteilungen statt.