Niemieckie umlauty w Powershell zwane przez vbs
mam plik ps1, który tworzy łącze
create-link.ps1
$path = $env:HOMESHARE + "\My Projects\"
If(!(test-path $path)) { New-Item -ItemType Directory -Force -Path $path
}
$WshShell = New-Object -comObject WScript.Shell $Shortcut = $WshShell.CreateShortcut($env:HOMESHARE + "\My Projects\" + "linkname.lnk")
$Shortcut.TargetPath = "\\path\for\link" $Shortcut.Description = "äöüß"
$Shortcut.IconLocation = $env:SYSTEMROOT + "\\system32\\shell32.dll,3"
$Shortcut.Save()
Mam też plik vbs, który wywołuje plik ps1
create-link.vbs
command = "powershell.exe Get-Content ""C:\path\to\file\create-link.ps1"" | PowerShell.exe -noprofile"
set shell = CreateObject("WScript.Shell")
shell.Run command,0
Oba pliki są zapisywane z kodowaniem utf-8.
Ta konstrukcja była konieczna, ponieważ ps1 musiał działać całkowicie bezgłowy, bez żadnych zauważalnych rzeczy dla użytkownika. Wywołanie ps1 przez vbs rozwiązało ten problem, jeśli istnieje lepszy sposób, byłbym szczęśliwy, gdybyś mnie powiadomił.
Jeśli wywołuję skrypt PowerShell bezpośrednio lub za pomocą polecenia „powershell.exe Get-Content” „C: \ path \ to \ file \ create-link.ps1” „| PowerShell.exe -noprofile” (przy użyciu cmd) wszystko działa dobrze . Jeśli jednak zadzwonię do vbs, aby wykonać pracę, to ogólnie działa, ale niemieckie umlauty z „Opisu” to tylko znaki zapytania, więc w jakiś sposób kodowanie zostało zakodowane. Czy jest jakiś sposób, aby to naprawić?
Odpowiedzi
tl; dr:
Zapisz swój
*.ps1plik jako UTF-8 z BOM .Uprościć polecenia za pomocą PowerShell CLI „s
-Fileparametr:
command = "powershell.exe -NoProfile -File ""C:\path\to\file\create-link.ps1"""
Zobacz też: GitHub numer 3028 , który żąda możliwości uruchomienia samego PowerShella całkowicie ukrytego - eliminując potrzebę użycia aux. Skrypt VBScript - który może obsługiwać przyszła wersja (ale nie zostanie przeniesiony z powrotem do programu Windows PowerShell).
Jeśli używasz Windows PowerShell (wersje do v5.1), musisz zapisać swoje *.ps1pliki jako UTF-8 z BOM , aby były poprawnie zinterpretowane w odniesieniu do znaków spoza zakresu ASCII (7-bitowego), takie jak äöüß.
Nie jest to już konieczne w PowerShell [Core] v6 + , który konsekwentnie domyślnie korzysta z UTF-8, ale jeśli twoje skrypty muszą działać w obu wersjach, powinieneś zawsze używać UTF-8 z BOM .
Jeśli dany *.ps1nie ma BOM, program Windows PowerShell interpretuje każdy bajt będący częścią sekwencji kodowania UTF-8 (wszystkie znaki inne niż ASCII są kodowane jako 2-4 bajty) indywidualnie jako znak na podstawie aktywnego systemu ANSI strona kodowa (kodowanie jednobajtowe, takie jak Windows-1252).
W systemie amerykańsko-angielskim, gdzie aktywną stroną kodową ANSI jest Windows-1252, powyższy przykładowy ciąg jest zatem wyświetlany jako łańcuch śmieci äöüß
Zwróć uwagę, że znaki zapytania lub, dokładniej, wystąpienia �(ZNAK ZAMIENNIKA, U+FFFD) pojawią się tylko w odwrotnym scenariuszu: gdy tekst zakodowany w ANSI zostanie błędnie zinterpretowany jako UTF-8.
Na marginesie, przedstaw swoje podejście do dostarczania kodu źródłowego do interfejsu wiersza polecenia programu PowerShell za pośrednictwem potoku (stdin) :
Ponieważ twój skrypt najwyraźniej działa w ukryciu, nie zrobi to różnicy w twoim przypadku, ale zwróć uwagę, że ta technika wykazuje tryb pseudointeraktywny, a także nie obsługuje przekazywania argumentów do skryptu dostarczanego przez stdin - zobacz numer 3223 w serwisie GitHub