Freigeben über

Grundlegendes zur Dateicodierung in VS Code und PowerShell

  • Artikel

Wenn Sie VS Code zum Erstellen und Bearbeiten von PowerShell-Skripts verwenden, ist es wichtig, dass Ihre Dateien mit dem richtigen Zeichencodierungsformat gespeichert werden.

Was ist die Dateicodierung und warum ist es wichtig?

VS Code verwaltet die Schnittstelle zwischen einem Menschen, der Zeichenfolgen von Zeichen in einen Puffer eingibt, und Lese-/Schreibblöcke von Bytes in das Dateisystem. Wenn VS Code eine Datei speichert, wird eine Textcodierung verwendet, um zu entscheiden, welche Bytes jedes Zeichen erhält. Weitere Informationen finden Sie unter about_Character_Encoding.

Ebenso muss powerShell beim Ausführen eines Skripts die Bytes in einer Datei in Zeichen konvertieren, um die Datei in ein PowerShell-Programm zu rekonstruieren. Da VS Code die Datei schreibt und PowerShell die Datei liest, müssen sie dasselbe Codierungssystem verwenden. Dieser Prozess der Analyse eines PowerShell-Skripts umfasst: Byte ->Zeichen ->Token ->abstrakte Syntaxstruktur ->Ausführung.

Sowohl VS Code als auch PowerShell werden mit einer sinnvollen Standardcodierungskonfiguration installiert. Die von PowerShell verwendete Standardcodierung hat sich jedoch mit der Veröffentlichung von PowerShell 6 geändert. Um sicherzustellen, dass Sie keine Probleme mit der Verwendung von PowerShell oder der PowerShell-Erweiterung in VS Code haben, müssen Sie Ihre VS-Code- und PowerShell-Einstellungen ordnungsgemäß konfigurieren.

Häufige Ursachen von Codierungsproblemen

Codierungsprobleme treten auf, wenn die Codierung von VS Code oder Ihre Skriptdatei nicht mit der erwarteten Codierung von PowerShell übereinstimmt. PowerShell kann die Dateicodierung nicht automatisch ermitteln.

Es ist wahrscheinlicher, dass Codierungsprobleme auftreten, wenn Sie Zeichen verwenden, die nicht im 7-Bit-ASCII-Zeichensatz . Zum Beispiel:

  • Erweiterte Nicht-Buchstaben-Zeichen wie em-Strich (—), nicht umgebrochenes Leerzeichen ( ) oder linke doppelte Anführungszeichen (")
  • Akzentierte lateinische Zeichen (É, ü)
  • Nicht lateinische Zeichen wie Kyrillisch (Д, Ц)
  • CJK-Zeichen (本, 화, が)

Häufige Ursachen für Codierungsprobleme sind:

  • Die Codierungen von VS Code und PowerShell wurden nicht von ihren Standardwerten geändert. Für PowerShell 5.1 und unten unterscheidet sich die Standardcodierung von VS-Code.
  • Ein anderer Editor hat die Datei in einer neuen Codierung geöffnet und überschrieben. Dies geschieht häufig mit dem ISE.
  • Die Datei wird in eine Codierung eingecheckt, die sich von dem unterscheidet, was VS Code oder PowerShell erwartet. Dies kann passieren, wenn Mitarbeiter Editoren mit unterschiedlichen Codierungskonfigurationen verwenden.

Wie Sie feststellen, wann Codierungsprobleme auftreten

Häufig stellen sich Codierungsfehler als Analysefehler in Skripts dar. Wenn Sie seltsame Zeichensequenzen in Ihrem Skript finden, kann dies das Problem sein. Im folgenden Beispiel wird ein Gedankenstrich (–) als zeichen â€"angezeigt:

Send-MailMessage : A positional parameter cannot be found that accepts argument 'Testing FuseMail SMTP...'.
At C:\Users\<User>\<OneDrive>\Development\PowerShell\Scripts\Send-EmailUsingSmtpRelay.ps1:6 char:1
+ Send-MailMessage â&euro;"From $from â&euro;"To $recipient1 â&euro;"Subject $subject  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Send-MailMessage], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.SendMailMessage

Dieses Problem tritt auf, da VS Code das Zeichen – in UTF-8 als byte 0xE2 0x80 0x93codiert. Wenn diese Bytes als Windows-1252 decodiert werden, werden sie als die Zeichen â&euro;"interpretiert.

Einige seltsame Zeichensequenzen, die Sie möglicherweise sehen, umfassen:

  • â&euro;" anstelle von – (en-Strich)
  • â&euro;" anstelle von — (em-gestrichelt)
  • Ä2 anstelle von Ä
  • Â anstelle von   (ein nicht zerbrechendes Leerzeichen)
  • Ã&copy; anstelle von é

Diese praktische Referenz listet die allgemeinen Muster auf, die auf ein UTF-8/Windows-1252-Codierungsproblem hinweisen.

Interaktion der PowerShell-Erweiterung in VS Code mit Codierungen

Die PowerShell-Erweiterung interagiert auf verschiedene Arten mit Skripts:

  1. Wenn Skripts in VS Code bearbeitet werden, werden die Inhalte von VS Code an die Erweiterung gesendet. Das Language Server Protocol mandatiert, dass dieser Inhalt in UTF-8 übertragen wird. Daher ist es nicht möglich, dass die Erweiterung die falsche Codierung erhält.
  2. Wenn Skripts direkt in der integrierten Konsole ausgeführt werden, werden sie von der Datei direkt von PowerShell gelesen. Wenn sich die Codierung von PowerShell von VS Code unterscheidet, kann hier ein Fehler auftreten.
  3. Wenn ein in VS Code geöffnetes Skript auf ein anderes Skript verweist, das nicht in VS Code geöffnet ist, greift die Erweiterung auf das Laden des Inhalts dieses Skripts aus dem Dateisystem zurück. Die PowerShell-Erweiterung verwendet standardmäßig UTF-8-Codierung, verwendet jedoch Bytereihenfolgezeichenoder BOM, um die richtige Codierung auszuwählen.

Das Problem tritt auf, wenn die Codierung von BOM-weniger-Formaten (z. B. UTF-8- ohne BOM und Windows-1252-) vorausgesetzt wird. Die PowerShell-Erweiterung ist standardmäßig auf UTF-8 festgelegt. Die Erweiterung kann die Codierungseinstellungen von VS Code nicht ändern. Weitere Informationen finden Sie unter Problem Nr. 824.

Auswählen der richtigen Codierung

Verschiedene Systeme und Anwendungen können unterschiedliche Codierungen verwenden:

  • In .NET Standard, im Web und in der Linux-Welt ist UTF-8 jetzt die dominante Codierung.
  • Viele .NET Framework-Anwendungen verwenden UTF-16-. Aus historischen Gründen wird dies manchmal als "Unicode" bezeichnet, ein Begriff, der sich jetzt auf einen breiten Standard bezieht, der sowohl UTF-8 als auch UTF-16 enthält.
  • Unter Windows verwenden viele systemeigene Anwendungen, die Unicode vorab verwenden, standardmäßig Windows-1252.

Unicode-Codierungen haben auch das Konzept einer Bytereihenfolgemarke (BOM). BOMs treten am Anfang des Texts auf, um einen Decoder mitzuteilen, welche Codierung des Texts verwendet wird. Bei Multibytecodierungen gibt die BOM auch Endianität der Codierung an. BOMs sind so konzipiert, dass Bytes sind, die selten in Nicht-Unicode-Text auftreten, was eine vernünftige Vermutung ermöglicht, dass Text Unicode ist, wenn eine BOM vorhanden ist.

BOMs sind optional und ihre Einführung ist in der Linux-Welt nicht so beliebt, da überall eine zuverlässige Konvention von UTF-8 verwendet wird. Die meisten Linux-Anwendungen gehen davon aus, dass die Texteingabe in UTF-8 codiert ist. Während viele Linux-Anwendungen eine BOM erkennen und richtig verarbeiten, führt eine Zahl nicht zu Artefakten in Text, die mit diesen Anwendungen bearbeitet werden.

Deshalb:

  • Wenn Sie hauptsächlich mit Windows-Anwendungen und Windows PowerShell arbeiten, sollten Sie eine Codierung wie UTF-8 mit BOM oder UTF-16 bevorzugen.
  • Wenn Sie plattformübergreifend arbeiten, sollten Sie UTF-8 mit BOM bevorzugen.
  • Wenn Sie hauptsächlich in Linux-zugehörigen Kontexten arbeiten, sollten Sie UTF-8 ohne BOM bevorzugen.
  • Windows-1252 und Latin-1 sind im Wesentlichen Legacycodierungen, die Sie möglichst vermeiden sollten. Einige ältere Windows-Anwendungen sind jedoch möglicherweise davon abhängig.
  • Es ist auch erwähnenswert, dass die Skriptsignierung codierungsabhängigenist, was bedeutet, dass eine Änderung der Codierung für ein signiertes Skript eine Neusignierung erfordert.

Konfigurieren von VS-Code

Die Standardcodierung von VS Code ist UTF-8 ohne BOM.

Um VS Code-Codierungs-festzulegen, wechseln Sie zu den VS-Codeeinstellungen (STRG+,), und legen Sie die "files.encoding" Einstellung fest:

"files.encoding": "utf8bom"

Einige mögliche Werte sind:

  • utf8: [UTF-8] ohne BOM
  • utf8bom: [UTF-8] mit BOM
  • utf16le: Little endian [UTF-16]
  • utf16be: Big Endian [UTF-16]
  • windows1252: [Windows-1252]

Sie sollten eine Dropdownliste für dies in der GUI-Ansicht oder fertigstellungen für sie in der JSON-Ansicht erhalten.

Sie können nach Möglichkeit auch Folgendes hinzufügen, um die AutoDetect-Codierung zu codieren:

"files.autoGuessEncoding": true

Wenn Sie nicht möchten, dass sich diese Einstellungen auf alle Dateitypen auswirken, lässt VS Code auch Konfigurationen pro Sprache zu. Erstellen Sie eine sprachspezifische Einstellung, indem Sie Einstellungen in ein [<language-name>] Feld einfügen. Zum Beispiel:

"[powershell]": {
    "files.encoding": "utf8bom",
    "files.autoGuessEncoding": true
}

Sie können auch die Installation der Gremlins Tracker für Visual Studio Code in Betracht ziehen. Diese Erweiterung zeigt bestimmte Unicode-Zeichen an, die leicht beschädigt werden, weil sie unsichtbar sind oder wie andere normale Zeichen aussehen.

Konfigurieren von PowerShell

Die Standardcodierung von PowerShell variiert je nach Version:

  • In PowerShell 6+ ist die Standardcodierung UTF-8 ohne BOM auf allen Plattformen.
  • In Windows PowerShell ist die Standardcodierung in der Regel Windows-1252. Dabei handelt es sich um eine Erweiterung von latin-1 (auch als ISO 8859-1 bezeichnet).

In PowerShell 5+ finden Sie Ihre Standardcodierung wie folgt:

[psobject].Assembly.GetTypes() | Where-Object { $_.Name -eq 'ClrFacade'} |
  ForEach-Object {
    $_.GetMethod('GetDefaultEncoding', [System.Reflection.BindingFlags]'nonpublic,static').Invoke($null, @())
  }

Das folgende Skript kann verwendet werden, um zu bestimmen, welche Codierung Ihre PowerShell-Sitzung für ein Skript ohne BOM ableiten soll.

$badBytes = [byte[]]@(0xC3, 0x80)
$utf8Str = [System.Text.Encoding]::UTF8.GetString($badBytes)
$bytes = [System.Text.Encoding]::ASCII.GetBytes('Write-Output "') + [byte[]]@(0xC3, 0x80) + [byte[]]@(0x22)
$path = Join-Path ([System.IO.Path]::GetTempPath()) 'encodingtest.ps1'

try
{
    [System.IO.File]::WriteAllBytes($path, $bytes)

    switch (& $path)
    {
        $utf8Str
        {
            return 'UTF-8'
            break
        }

        default
        {
            return 'Windows-1252'
            break
        }
    }
}
finally
{
    Remove-Item $path
}

Es ist möglich, PowerShell so zu konfigurieren, dass eine bestimmte Codierung im Allgemeinen mithilfe von Profileinstellungen verwendet wird. Weitere Informationen finden Sie in den folgenden Artikeln:

Es ist nicht möglich, PowerShell zu erzwingen, eine bestimmte Eingabecodierung zu verwenden. PowerShell 5.1 und unter Windows, unter dem das Gebietsschema auf en-USfestgelegt ist, wird standardmäßig windows-1252-Codierung verwendet, wenn keine BOM vorhanden ist. Andere Gebietsschemaeinstellungen können eine andere Codierung verwenden. Um die Interoperabilität sicherzustellen, ist es am besten, Skripts in einem Unicode-Format mit einer BOM zu speichern.

Wichtig

Alle anderen Tools, die Sie mit PowerShell-Skripts verwenden, können von Ihren Codierungsoptionen betroffen sein oder Ihre Skripts in eine andere Codierung neu codieren.

Vorhandene Skripts

Skripts, die sich bereits im Dateisystem befinden, müssen möglicherweise erneut in die neue ausgewählte Codierung codiert werden. In der unteren Leiste von VS Code wird die Bezeichnung UTF-8 angezeigt. Klicken Sie darauf, um die Aktionsleiste zu öffnen, und wählen Sie Speichern mit Codierungaus. Sie können jetzt eine neue Codierung für diese Datei auswählen. Vollständige Anweisungen finden Sie unter Codierungs- von VS Code.

Wenn Sie mehrere Dateien neu codieren müssen, können Sie das folgende Skript verwenden:

Get-ChildItem *.ps1 -Recurse | ForEach-Object {
    $content = Get-Content -Path $_
    Set-Content -Path $_.Fullname -Value $content -Encoding UTF8 -PassThru -Force
}

Die integrierte PowerShell-Skriptingumgebung (ISE)

Wenn Sie Skripts auch mithilfe von PowerShell ISE bearbeiten, müssen Sie ihre Codierungseinstellungen dort synchronisieren.

Der ISE sollte eine BOM berücksichtigen, aber es ist auch möglich, Spiegelung zu verwenden, um die Codierung festzulegen. Beachten Sie, dass dies nicht zwischen Startups bestehen würde.

Quellcodeverwaltungssoftware

Einige Quellcodeverwaltungstools, z. B. Git, ignorieren Codierungen; git verfolgt nur die Bytes. Andere, wie Azure DevOps oder Mercurial, dürfen nicht. Selbst einige gitbasierte Tools basieren auf der Decodierung von Text.

Wenn dies der Fall ist, stellen Sie sicher, dass Sie:

  • Konfigurieren Sie die Textcodierung in Der Quellcodeverwaltung so, dass sie ihrer VS Code-Konfiguration entspricht.
  • Stellen Sie sicher, dass alle Ihre Dateien in die Quellcodeverwaltung in der relevanten Codierung eingecheckt sind.
  • Seien Sie vorsichtig mit Änderungen an der Codierung, die über die Quellcodeverwaltung empfangen wurde. Ein Schlüsselzeichen hierfür ist ein Diff, der Änderungen angibt, aber wo sich nichts geändert hat (da Bytes jedoch Zeichen haben, die nicht vorhanden sind).

Umgebung von Mitarbeitern

Stellen Sie oben beim Konfigurieren der Quellcodeverwaltung sicher, dass Ihre Mitarbeiter für alle dateien, die Sie freigeben, keine Einstellungen haben, die Ihre Codierung außer Kraft setzen, indem Sie PowerShell-Dateien neu codieren.

Andere Programme

Jedes andere Programm, das ein PowerShell-Skript liest oder schreibt, kann es neu codieren.

Einige Beispiele sind:

  • Verwenden der Zwischenablage zum Kopieren und Einfügen eines Skripts Dies ist üblich in Szenarien wie:
    • Kopieren eines Skripts in einen virtuellen Computer
    • Kopieren eines Skripts aus einer E-Mail oder Webseite
    • Kopieren eines Skripts in oder aus einem Microsoft Word- oder PowerPoint-Dokument
  • Andere Texteditoren, z. B.:
    • Notizblock
    • Schwung
    • Beliebiger anderer PowerShell-Skript-Editor
  • Hilfsprogramme für die Textbearbeitung, z. B.:
    • Get-Content/Set-Content/Out-File
    • PowerShell-Umleitungsoperatoren wie > und >>
    • sed/awk
  • Dateiübertragungsprogramme, z. B.:
    • Ein Webbrowser beim Herunterladen von Skripts
    • Dateifreigabe

Einige dieser Tools behandeln Byte anstelle von Text, aber andere bieten Codierungskonfigurationen an. In diesen Fällen, in denen Sie eine Codierung konfigurieren müssen, müssen Sie sie mit der Editorcodierung identisch machen, um Probleme zu vermeiden.

Weitere Ressourcen zur Codierung in PowerShell

Es gibt ein paar andere schöne Beiträge zum Codieren und Konfigurieren von Codierung in PowerShell, die einen Lesewert wert sind: