Powershell изменить кодировку файла
It worked as expected, but I need the generated files without BOM. So I tried to modify the script a little, adding the solution given to this question: Using PowerShell to write a file in UTF-8 without the BOM
This is my final script:
The problem is that powershell is returning me an error, regarding the System.Text.UTF8Encoding($False) line, complaining about an incorrect parameter:
It is not possible to validate the argument on the 'Encoding' parameter. The argument "System.Text.UTF8Encoding" dont belongs to the the group "unicode, utf7, utf8, utf32, ascii" specified by the ValidateSet attribute.
I wonder if I'm missing something, like powershell version or something like that. I never coded a Powershell script before, so I'm totally lost with this. And I need to change these files encoding, there are hundreds of them, I wouldn't like to do it myself one by one.
Actually I'm using the 2.0 version that comes with Windows 7.
Thanks in advance!
EDIT 1
I tried the following code, suggested by @LarsTruijens and other posts:
This gives me an Exception, complaining about one of the parameters for WriteAllLines: "Exception on calling 'WriteAllLines' with 3 arguments. The value can't be null". Parameter name: contents . The script creates all folders, though. But they are all empty.
EDIT 2
An interesting thing about this error is that the "content" parameter is not null. If I output the value of the $content variable (using Write-host) the lines are there. So why it becomes null when passed to WriteAllLines method?
EDIT 3
I've added a content check to the variable, so the script now looks like this:
Now every iteration returns "No content from: $i" message, but the file isn't empty. There is one more error: Get-content: can't find the path 'C:\root\FILENAME.php' because it doesn't exists. It seems that it is trying to find the files at the root directory and not in the subfolders. It appears to be able to get the filename from child folders, but tries to read it from root.
EDIT 4 - Final Working Version
After some struggling and following the advices I got here, specially from @LarsTruijens and @AnsgarWiechers, I finally made it. I had to change the way I was getting the directory from $PWD and set some fixed names for the folders. After that, it worked perfectly.
Describes how PowerShell uses character encoding for input and output of string data.
Изменение кодировки по умолчанию
В PowerShell есть две переменные по умолчанию, которые можно использовать для изменения поведения кодировки по умолчанию.
- $PSDefaultParameterValues
- $OutputEncoding
Дополнительные сведения см. в разделе about_Preference_Variables.
Начиная с PowerShell 5,1, операторы перенаправления ( > и >> ) вызывают Out-File командлет. Таким образом, можно задать кодировку по умолчанию для них с помощью $PSDefaultParameterValues переменной предпочтений, как показано в следующем примере:
Используйте следующую инструкцию, чтобы изменить кодировку по умолчанию для всех командлетов, имеющих параметр Encoding .
При размещении этой команды в профиле PowerShell предпочтение влияет на глобальные параметры сеанса, влияющие на все команды и скрипты, которые явно не задают кодировку.
Аналогичным образом следует включить такие команды в скрипты или модули, которые должны вести себя одинаково. Использование этих команд гарантирует, что командлеты ведут себя одинаково даже при запуске другого пользователя, на другом компьютере или в другой версии PowerShell.
Автоматическая переменная $OutputEncoding влияет на кодирование, используемое PowerShell для взаимодействия с внешними программами. Он не влияет на кодировку, которую операторы перенаправления вывода и командлеты PowerShell используют для сохранения в файлах.
При использовании VS Code для создания и редактирования сценариев PowerShell очень важно, чтобы ваши файлы сохранялись в правильной кодировке символов.
Changing the default encoding
PowerShell has two default variables that can be used to change the default encoding behavior.
- $PSDefaultParameterValues
- $OutputEncoding
Beginning in PowerShell 5.1, the redirection operators ( > and >> ) call the Out-File cmdlet. Therefore, you can set the default encoding of them using the $PSDefaultParameterValues preference variable as shown in this example:
Use the following statement to change the default encoding for all cmdlets that have the Encoding parameter.
Putting this command in your PowerShell profile makes the preference a session-global setting that affects all commands and scripts that do not explicitly specify an encoding.
Similarly, you should include such commands in your scripts or modules that you want to behave the same way. Using these commands ensure that cmdlets behave the same way even when run by another user, on a different computer, or in a different version of PowerShell.
The automatic variable $OutputEncoding affects the encoding PowerShell uses to communicate with external programs. It has no effect on the encoding that the output redirection operators and PowerShell cmdlets use to save to files.
Описывает, как PowerShell использует кодировку символов для ввода и вывода строковых данных.
Существующие скрипты
Скрипты, которые уже находятся в файловой системе, могут нуждаться в повторном кодировании в указанную вами кодировку. В нижней строке VS Code вы увидите метку UTF-8. Щелкните ее, чтобы открыть панель действий, и выберите команду Сохранить с кодировкой. Теперь вы можете выбрать новую кодировку для этого файла. Подробные инструкции см. в разделе Кодировка в VS Code.
Если вам нужно повторно кодировать несколько файлов, можно использовать следующий скрипт:
Другие ресурсы о кодировках в PowerShell
Существует несколько других достойных публикаций на тему кодировок и настройки кодирования в PowerShell:
При использовании VS Code для создания и редактирования сценариев PowerShell очень важно, чтобы ваши файлы сохранялись в правильной кодировке символов.
Выбор подходящей кодировки
Различные системы и приложения могут использовать различные кодировки:
- В .NET Standard, в Интернете и в среде Linux теперь в основном используется кодировка UTF-8.
- Во многих приложениях .NET Framework используется UTF-16. По историческим причинам ее иногда называют "Юникод"; сейчас этот термин относится к более широкому стандарту, охватывающему UTF-8 и UTF-16.
- В Windows многие приложения, которые были созданы еще до распространения Юникода, по-прежнему могут по умолчанию использовать Windows-1252.
Кодировки Юникода также используют понятие метки порядка следования байтов (BOM). BOM ставится в начале текста, чтобы декодер мог определить, какая кодировка используется в тексте. Для многобайтовых кодировок BOM также указывает порядок следования байтов кодировки. BOM представляются байтами, которые редко встречаются в тексте в Юникоде. Это позволяет сделать обоснованное предположение, что текст записан в Юникоде, если присутствует метка BOM.
BOM не являются обязательными; в мире Linux они не так популярны, поскольку во всех прочих местах используется надежное соглашение UTF-8. Большинство приложений Linux предполагают, что текстовый ввод кодируется в UTF-8. Хотя многие приложения Linux могут распознавать и правильно обрабатывать BOM, некоторые этого не делают, что приводит к появлению артефактов в тексте, открываемом с помощью этих приложений.
Таким образом:
- Если вы работаете в основном с приложениями Windows и Windows PowerShell, следует предпочтительно использовать такие кодировки, как UTF-8 с BOM или UTF-16.
- Если вы работаете на разных платформах, следует отдавать предпочтение UTF-8 с BOM.
- Если вы работаете главным образом в контексте Linux, следует отдавать предпочтение UTF-8 без BOM.
- Windows-1252 и latin-1 — устаревшие кодировки, которых по возможности следует избегать. Тем не менее некоторые приложения предыдущих версий в Windows зависят от их.
- Также стоит отметить, что подписывание скриптов зависит от кодировки, то есть изменение кодировки в подписанном скрипте потребует повторного подписывания.
Что такое кодировка и почему она важна?
VS Code управляет интерфейсом ввода строки символов в буфер пользователем и чтения-записи блоков байтов в файловой системе. При сохранении файла в VS Code используется кодирование текста для определения того, какие байты получит каждый символ. Подробные сведения см. в статье О шифровании символов.
Аналогичным образом, когда оболочка PowerShell запускает скрипт, ей необходимо преобразовать байты из файла в символы для преобразования файла в программу PowerShell. Так как VS Code записывает файл, а PowerShell считывает файл, этим средствам необходимо использовать одну и ту же систему кодировки. Этот процесс синтаксического анализа скрипта PowerShell идет так: байты -> символы -> лексемы -> дерево абстрактного синтаксиса -> выполнение.
И VS Code, и PowerShell устанавливаются с подходящей конфигурацией кодировки по умолчанию. Тем не менее кодировка по умолчанию, используемая PowerShell, была изменена с выпуском PowerShell 6. Чтобы избежать проблем с PowerShell и расширениями PowerShell в VS Code, необходимо настроить параметры VS Code и PowerShell должным образом.
Существующие скрипты
Скрипты, которые уже находятся в файловой системе, могут нуждаться в повторном кодировании в указанную вами кодировку. В нижней строке VS Code вы увидите метку UTF-8. Щелкните ее, чтобы открыть панель действий, и выберите команду Сохранить с кодировкой. Теперь вы можете выбрать новую кодировку для этого файла. Подробные инструкции см. в разделе Кодировка в VS Code.
Если вам нужно повторно кодировать несколько файлов, можно использовать следующий скрипт:
Система управления версиями
Некоторые системы управления версиями, например git, игнорируют кодировки; git отслеживает только байты. Поведение других, например Azure DevOps или Mercurial, может отличаться. Даже некоторые средства, основанные на git, полагаются на декодирование текста.
Если это так, убедитесь, что вы:
- Настроили кодировку в системе управления версиями в соответствии с вашей конфигурацией VS Code.
- Сделали так, что все файлы добавляются в систему управления версиями в соответствующей кодировке.
- Остерегайтесь изменять кодировки, полученные через систему управления версиями. Ключевым признаком здесь будет разностный файл, который указывает, что изменения отсутствуют (так как изменены байты, но не символы).
Другие ресурсы о кодировках в PowerShell
Существует несколько других достойных публикаций на тему кодировок и настройки кодирования в PowerShell:
Настройка PowerShell
В PowerShell кодировка по умолчанию зависит от версии:
- В PowerShell 6+ кодировка по умолчанию на всех платформах — UTF-8 без метки порядка байтов.
- В Windows PowerShell кодировка по умолчанию — обычно Windows-1252, расширение latin-1, которое также называется ISO 8859-1.
В PowerShell 5 + можно определить кодировку по умолчанию так:
Следующий скрипт может использоваться для определения кодировки, которую ваш сеанс PowerShell выводит для скрипта, где нет метки порядка байтов.
Можно настроить PowerShell так, чтобы использовать заданную кодировку в более общем виде с помощью параметров профиля. См. следующие статьи:
Заставить PowerShell использовать конкретную кодировку для входных данных невозможно. В PowerShell 5.1 и более ранних версий в Windows с языковым стандартом en-US по умолчанию используется кодировка Windows-1252, если отсутствует метка порядка байтов. Другие параметры языкового стандарта могут использовать другую кодировку. Для обеспечения совместимости лучше сохранять скрипты в Юникоде с меткой порядка байтов.
Любые другие имеющиеся у вас инструменты для работы со скриптами PowerShell могут зависеть от выбранных параметров кодировки или преобразовывать скрипты в другую кодировку.
Кодировка символов в Windows PowerShell
В PowerShell 5,1 параметр Encoding поддерживает следующие значения:
- Ascii Использует кодировку ASCII (7-разрядных).
- BigEndianUnicode Использует UTF-16 с обратным порядком байтов.
- BigEndianUTF32 Использует UTF-32 с обратным порядком байтов.
- Byte Кодирует набор символов в последовательность байтов.
- Default Использует кодировку, соответствующую активной кодовой странице системы (обычно ANSI).
- Oem Использует кодировку, соответствующую текущей кодовой странице OEM системы.
- String аналогичен Unicode .
- Unicode Использует UTF-16 с прямым порядком байтов.
- Unknown аналогичен Unicode .
- UTF32 Использует UTF-32 с прямым порядком байтов.
- UTF7 Использует UTF-7.
- UTF8 Использует UTF-8 (с BOM).
в общем случае Windows PowerShell по умолчанию использует кодировку юникод UTF-16le . однако кодировка по умолчанию, используемая командлетами в Windows PowerShell, не согласуется.
При использовании любой кодировки Юникода, за исключением UTF7 , всегда создает спецификацию.
Для командлетов, записывающих выходные данные в файлы:
Out-File и операторы > перенаправления и >> создают UTF-16LE, который, в свою очередь, отличается от Set-Content и Add-Content .
New-ModuleManifest а Export-CliXml также создавать файлы UTF-16LE.
Если целевой файл пуст или не существует, Set-Content и Add-Content Используйте Default кодировку. Default — это кодировка, определяемая кодовой страницей устаревшей версии ANSI на языке активного системы.
Export-Csv создает Ascii файлы, но использует другую кодировку при использовании параметра append (см. ниже).
Export-PSSession по умолчанию создает файлы UTF-8 с BOM.
New-Item -Type File -Value создает файл UTF-8 с кодировкой BOM.
Send-MailMessage по умолчанию использует Default кодировку.
Start-Transcript создает Utf8 файлы с помощью спецификации. При использовании параметра append кодировка может отличаться (см. ниже).
Для команд, которые добавляют к существующему файлу:
Out-File -Append``>> и оператор перенаправления не пытается сопоставить кодировку содержимого существующего целевого файла. Вместо этого они используют кодировку по умолчанию, если не используется параметр Encoding . При добавлении содержимого необходимо использовать исходную кодировку файлов.
При отсутствии явного параметра Add-Content кодировки обнаруживает существующую кодировку и автоматически применяет ее к новому содержимому. Если имеющееся содержимое не имеет BOM, Default используется кодировка ANSI. Поведение функции Add-Content аналогично в PowerShell (V6 и более поздних версиях), за исключением кодировки по умолчанию — Utf8 .
Export-Csv -Append соответствует существующей кодировке, если целевой файл содержит СПЕЦИФИКАЦИю. В отсутствие спецификации используется Utf8 Кодировка.
Start-Transcript -Append соответствует существующей кодировке файлов, включающих СПЕЦИФИКАЦИю. При отсутствии спецификации по умолчанию используется Ascii Кодировка. Такая кодировка может привести к утере данных или повреждению символов, если данные в записи содержат многобайтовые символы.
Для командлетов, считывающих строковые данные в отсутствие спецификации:
Get-Content и Import-PowerShellDataFile использует Default кодировку ANSI. ANSI также используется механизмом PowerShell при чтении исходного кода из файлов.
Import-Csv , Import-CliXml и Select-String предполагают Utf8 отсутствие спецификации.
Среды других участников
Настроив систему управления версиями, убедитесь также, что параметры других участников, работающих над теми файлами, к которым вы предоставляете общий доступ, не переопределяют кодировку путем повторного кодирования файлов PowerShell.
Другие программы
Все другие программы, которые считывают или записывают скрипты PowerShell, могут перекодировать их.
- Использование буфера обмена для копирования и вставки скрипта. Такое часто встречается в следующих случаях:
- Копирование скрипта в виртуальную машину.
- Копирование скрипта из электронной почты или с веб-страницы.
- Копирование скрипта через документ Microsoft Word или PowerPoint.
- Блокнот;
- vim;
- любой другой редактор скриптов PowerShell.
- Get-Content / Set-Content / Out-File
- Операторы перенаправления PowerShell, такие как > и >> .
- sed / awk
- Веб-браузер при скачивании скриптов.
- Общий файловый ресурс.
Некоторые из этих средств работают с байтами, а не с текстом, но другие позволяют настраивать кодировки. В случаях, когда необходимо настроить кодировку, используйте те же параметры, что и в вашем редакторе, чтобы предотвратить возникновение проблем.
Распространенные причины проблемы с кодировкой
Проблемы с кодировкой возникают, если кодировка VS Code в целом или вашего файла скрипта не совпадает с кодировкой, ожидаемой в PowerShell. В PowerShell нет способа автоматически определить кодировку файла.
Проблемы с кодировкой более вероятны при использовании символов не из 7-разрядной кодировки ASCII. Пример:
- Расширенные небуквенные символы, такие как длинное тире ( — ), неразрывный пробел ( ) или левая двойная кавычка ( " ).
- Латинские символы с диакритикой ( É , ü )
- Нелатинские символы, такие как кириллица ( Д , Ц )
- Символы иероглифического письма ( 本 , 화 , が ).
Распространенные причины проблем с кодировкой:
- Параметры кодировок по умолчанию VS Code и PowerShell не были изменены. В версиях до PowerShell 5.1 (включительно) кодировка по умолчанию отличается от используемой в VS Code.
- Открыт другой редактор, и файл перезаписан в новой кодировке. Это часто происходит с интегрированной средой сценариев.
- Файл возвращается в систему управления версиями в кодировке, отличающейся от той, которая ожидается в VS Code или PowerShell. Это может произойти, когда участники совместной работы используют редакторы с различными конфигурациями кодировок.
Пометка порядка байтов
Символ-пометка (BOM) — это сигнатура в Юникоде в первых нескольких байтах файла или текстового потока, указывающих, какая кодировка Юникода используется для данных. Дополнительные сведения см. в документации по метке порядка байтов .
в Windows PowerShell любая кодировка юникода, за исключением UTF7 , всегда создает спецификацию. PowerShell (V6 и более поздние версии) по умолчанию имеет utf8NoBOM значение для всех текстовых выходных данных.
Для обеспечения оптимальной совместимости Избегайте использования спецификаций в файлах UTF-8. платформы unix и служебные программы unix-heritage, также используемые на платформах Windows, не поддерживают спецификации.
UTF7 Аналогичным образом следует избегать кодирования. UTF-7 не является стандартной кодировкой Юникода и записывается без спецификации во всех версиях PowerShell.
создание сценариев PowerShell на платформе, похожем на Unix, или использовании кросс-платформенного редактора на Windows, например Visual Studio Code, приводит к созданию файла, закодированного с помощью UTF8NoBOM . эти файлы прекрасно работают в PowerShell, но могут нарушить работу Windows PowerShell если файл содержит символы, отличные от Ascii.
Если в скриптах необходимо использовать символы, отличные от ASCII, сохраните их как UTF-8 с помощью BOM. без спецификации Windows PowerShell правильно интерпретирует скрипт как закодированный в устаревшей кодовой странице ANSI. И наоборот, файлы, имеющие СПЕЦИФИКАЦИю UTF-8, могут быть проблематичными для платформ, подобных Unix. Многие средства UNIX, такие как cat ,, и некоторые редакторы, например gedit , sed awk не узнают, как обрабатывать спецификацию.
Подробное описание
Юникод — это мировой стандарт кодировки символов. Система использует Юникод исключительно для обработки символов и строк. Подробное описание всех аспектов Юникода см. в стандарте Юникода.
По умолчанию PowerShell использует набор символов Юникода. Однако несколько командлетов имеют параметр кодирования , который может указывать кодировку для другой кодировки. Этот параметр позволяет выбрать конкретную кодировку символов, необходимую для взаимодействия с другими системами и приложениями.
Следующие командлеты имеют параметр Encoding :
- Microsoft.PowerShell.Management
- Add-Content
- Get-Content
- Set-Content
- Export-Clixml
- Export-Csv
- Export-PSSession
- Format-Hex
- Import-Csv
- Out-File
- Select-String
- Send-MailMessage
Long description
Unicode is a worldwide character-encoding standard. The system uses Unicode exclusively for character and string manipulation. For a detailed description of all aspects of Unicode, refer to The Unicode Standard.
PowerShell uses a Unicode character set by default. However, several cmdlets have an Encoding parameter that can specify encoding for a different character set. This parameter allows you to choose the specific the character encoding you need for interoperability with other systems and applications.
The following cmdlets have the Encoding parameter:
- Microsoft.PowerShell.Management
- Add-Content
- Get-Content
- Set-Content
- Export-Clixml
- Export-Csv
- Export-PSSession
- Format-Hex
- Import-Csv
- Out-File
- Select-String
- Send-MailMessage
Настройка VS Code
Кодировка VS Code по умолчанию — UTF-8 без метки порядка байтов.
Чтобы задать Кодировка в VS Code, перейдите к параметрам VS Code ( CTRL + , ) и задайте параметр "files.encoding" :
Возможны следующие значения:
- utf8 : [UTF-8] без метки порядка байтов
- utf8bom : [UTF-8] с меткой порядка байтов
- utf16le : [UTF-16] с прямым порядком байтов
- utf16be : [UTF-16] с обратным порядком байтов
- windows1252 : [Windows-1252]
Должен отобразиться раскрывающийся список представления графического пользовательского интерфейса или дополнение в представлении JSON.
Чтобы обеспечить автоматическое определение кодировки, если это возможно, можно также добавить следующее:
Если вы не хотите, чтобы эти параметры влияли на все типы файлов, в VS Code можно задавать конфигурации для каждого языка отдельно. Создать параметр для конкретного языка можно, поместив параметры в поле [] . Пример:
Вы также можете установить средство отслеживания Gremlins для Visual Studio Code. Это расширение раскрывает определенные символы Юникода, которые могут быть легко повреждены из-за своей невидимости или схожести с другими обычными символами.
Выбор подходящей кодировки
Различные системы и приложения могут использовать различные кодировки:
- В .NET Standard, в Интернете и в среде Linux теперь в основном используется кодировка UTF-8.
- Во многих приложениях .NET Framework используется UTF-16. По историческим причинам ее иногда называют "Юникод"; сейчас этот термин относится к более широкому стандарту, охватывающему UTF-8 и UTF-16.
- В Windows многие приложения, которые были созданы еще до распространения Юникода, по-прежнему могут по умолчанию использовать Windows-1252.
Кодировки Юникода также используют понятие метки порядка следования байтов (BOM). BOM ставится в начале текста, чтобы декодер мог определить, какая кодировка используется в тексте. Для многобайтовых кодировок BOM также указывает порядок следования байтов кодировки. BOM представляются байтами, которые редко встречаются в тексте в Юникоде. Это позволяет сделать обоснованное предположение, что текст записан в Юникоде, если присутствует метка BOM.
BOM не являются обязательными; в мире Linux они не так популярны, поскольку во всех прочих местах используется надежное соглашение UTF-8. Большинство приложений Linux предполагают, что текстовый ввод кодируется в UTF-8. Хотя многие приложения Linux могут распознавать и правильно обрабатывать BOM, некоторые этого не делают, что приводит к появлению артефактов в тексте, открываемом с помощью этих приложений.
Таким образом:
- Если вы работаете в основном с приложениями Windows и Windows PowerShell, следует предпочтительно использовать такие кодировки, как UTF-8 с BOM или UTF-16.
- Если вы работаете на разных платформах, следует отдавать предпочтение UTF-8 с BOM.
- Если вы работаете главным образом в контексте Linux, следует отдавать предпочтение UTF-8 без BOM.
- Windows-1252 и latin-1 — устаревшие кодировки, которых по возможности следует избегать. Тем не менее некоторые приложения предыдущих версий в Windows зависят от их.
- Также стоит отметить, что подписывание скриптов зависит от кодировки, то есть изменение кодировки в подписанном скрипте потребует повторного подписывания.
Что такое кодировка и почему она важна?
VS Code управляет интерфейсом ввода строки символов в буфер пользователем и чтения-записи блоков байтов в файловой системе. При сохранении файла в VS Code используется кодирование текста для определения того, какие байты получит каждый символ. Подробные сведения см. в статье О шифровании символов.
Аналогичным образом, когда оболочка PowerShell запускает скрипт, ей необходимо преобразовать байты из файла в символы для преобразования файла в программу PowerShell. Так как VS Code записывает файл, а PowerShell считывает файл, этим средствам необходимо использовать одну и ту же систему кодировки. Этот процесс синтаксического анализа скрипта PowerShell идет так: байты -> символы -> лексемы -> дерево абстрактного синтаксиса -> выполнение.
И VS Code, и PowerShell устанавливаются с подходящей конфигурацией кодировки по умолчанию. Тем не менее кодировка по умолчанию, используемая PowerShell, была изменена с выпуском PowerShell 6. Чтобы избежать проблем с PowerShell и расширениями PowerShell в VS Code, необходимо настроить параметры VS Code и PowerShell должным образом.
Как определить наличие проблемы с кодировкой
Часто ошибки кодирования в скриптах представляются как ошибки синтаксического анализа. Если вы видите странные последовательности символов в скрипте, это может быть проблемой. В примере ниже тире ( – ) отображается в виде символов â€" :
Эта проблема возникает, так как VS Code кодирует символ – в UTF-8 как байты 0xE2 0x80 0x93 . Если эти байты декодируются в кодировке Windows-1252, они интерпретируются как символы â€" .
Некоторые странные последовательности символов, которые можно видеть:
- â€" вместо – .
- â€" вместо — .
- Ä2 вместо Ä .
- Â вместо (неразрывный пробел);
- é вместо é .
Этот удобный справочник перечисляет распространенные шаблоны, которые указывают на проблему между кодировками UTF-8 и Windows-1252.
Character encoding in Windows PowerShell
In PowerShell 5.1, the Encoding parameter supports the following values:
- Ascii Uses Ascii (7-bit) character set.
- BigEndianUnicode Uses UTF-16 with the big-endian byte order.
- BigEndianUTF32 Uses UTF-32 with the big-endian byte order.
- Byte Encodes a set of characters into a sequence of bytes.
- Default Uses the encoding that corresponds to the system's active code page (usually ANSI).
- Oem Uses the encoding that corresponds to the system's current OEM code page.
- String Same as Unicode .
- Unicode Uses UTF-16 with the little-endian byte order.
- Unknown Same as Unicode .
- UTF32 Uses UTF-32 with the little-endian byte order.
- UTF7 Uses UTF-7.
- UTF8 Uses UTF-8 (with BOM).
In general, Windows PowerShell uses the Unicode UTF-16LE encoding by default. However, the default encoding used by cmdlets in Windows PowerShell is not consistent.
Using any Unicode encoding, except UTF7 , always creates a BOM.
For cmdlets that write output to files:
Out-File and the redirection operators > and >> create UTF-16LE, which notably differs from Set-Content and Add-Content .
New-ModuleManifest and Export-CliXml also create UTF-16LE files.
When the target file is empty or doesn't exist, Set-Content and Add-Content use Default encoding. Default is the encoding specified by the active system locale's ANSI legacy code page.
Export-Csv creates Ascii files but uses different encoding when using Append parameter (see below).
Export-PSSession creates UTF-8 files with BOM by default.
New-Item -Type File -Value creates a BOM-less UTF-8 file.
Send-MailMessage uses Default encoding by default.
Start-Transcript creates Utf8 files with a BOM. When the Append parameter is used, the encoding can be different (see below).
For commands that append to an existing file:
Out-File -Append and the >> redirection operator make no attempt to match the encoding of the existing target file's content. Instead, they use the default encoding unless the Encoding parameter is used. You must use the files original encoding when appending content.
In the absence of an explicit Encoding parameter, Add-Content detects the existing encoding and automatically applies it to the new content. If the existing content has no BOM, Default ANSI encoding is used. The behavior of Add-Content is the same in PowerShell (v6 and higher) except the default encoding is Utf8 .
Export-Csv -Append matches the existing encoding when the target file contains a BOM. In the absence of a BOM, it uses Utf8 encoding.
Start-Transcript -Append matches the existing encoding of files that include a BOM. In the absence of a BOM, it defaults to Ascii encoding. This encoding can result in data loss or character corruption when the data in the transcript contains multibyte characters.
For cmdlets that read string data in the absence of a BOM:
Get-Content and Import-PowerShellDataFile uses the Default ANSI encoding. ANSI is also what the PowerShell engine uses when it reads source code from files.
Import-Csv , Import-CliXml , and Select-String assume Utf8 in the absence of a BOM.
Распространенные причины проблемы с кодировкой
Проблемы с кодировкой возникают, если кодировка VS Code в целом или вашего файла скрипта не совпадает с кодировкой, ожидаемой в PowerShell. В PowerShell нет способа автоматически определить кодировку файла.
Проблемы с кодировкой более вероятны при использовании символов не из 7-разрядной кодировки ASCII. Пример:
- Расширенные небуквенные символы, такие как длинное тире ( — ), неразрывный пробел ( ) или левая двойная кавычка ( " ).
- Латинские символы с диакритикой ( É , ü )
- Нелатинские символы, такие как кириллица ( Д , Ц )
- Символы иероглифического письма ( 本 , 화 , が ).
Распространенные причины проблем с кодировкой:
- Параметры кодировок по умолчанию VS Code и PowerShell не были изменены. В версиях до PowerShell 5.1 (включительно) кодировка по умолчанию отличается от используемой в VS Code.
- Открыт другой редактор, и файл перезаписан в новой кодировке. Это часто происходит с интегрированной средой сценариев.
- Файл возвращается в систему управления версиями в кодировке, отличающейся от той, которая ожидается в VS Code или PowerShell. Это может произойти, когда участники совместной работы используют редакторы с различными конфигурациями кодировок.
Как определить наличие проблемы с кодировкой
Часто ошибки кодирования в скриптах представляются как ошибки синтаксического анализа. Если вы видите странные последовательности символов в скрипте, это может быть проблемой. В примере ниже тире ( – ) отображается в виде символов â€" :
Эта проблема возникает, так как VS Code кодирует символ – в UTF-8 как байты 0xE2 0x80 0x93 . Если эти байты декодируются в кодировке Windows-1252, они интерпретируются как символы â€" .
Некоторые странные последовательности символов, которые можно видеть:
- â€" вместо – .
- â€" вместо — .
- Ä2 вместо Ä .
- Â вместо (неразрывный пробел);
- é вместо é .
Этот удобный справочник перечисляет распространенные шаблоны, которые указывают на проблему между кодировками UTF-8 и Windows-1252.
Настройка VS Code
Кодировка VS Code по умолчанию — UTF-8 без метки порядка байтов.
Чтобы задать Кодировка в VS Code, перейдите к параметрам VS Code ( CTRL + , ) и задайте параметр "files.encoding" :
Возможны следующие значения:
- utf8 : [UTF-8] без метки порядка байтов
- utf8bom : [UTF-8] с меткой порядка байтов
- utf16le : [UTF-16] с прямым порядком байтов
- utf16be : [UTF-16] с обратным порядком байтов
- windows1252 : [Windows-1252]
Должен отобразиться раскрывающийся список представления графического пользовательского интерфейса или дополнение в представлении JSON.
Чтобы обеспечить автоматическое определение кодировки, если это возможно, можно также добавить следующее:
Если вы не хотите, чтобы эти параметры влияли на все типы файлов, в VS Code можно задавать конфигурации для каждого языка отдельно. Создать параметр для конкретного языка можно, поместив параметры в поле [] . Пример:
Вы также можете установить средство отслеживания Gremlins для Visual Studio Code. Это расширение раскрывает определенные символы Юникода, которые могут быть легко повреждены из-за своей невидимости или схожести с другими обычными символами.
Интегрированная среда сценариев (ISE) PowerShell
При редактировании скриптов с помощью интегрированной среды сценариев PowerShell необходимо синхронизировать здесь параметры кодировки.
Интегрированная среда сценариев должна учитывать метку порядка байтов, но можно также использовать отражение для задания кодировки. Обратите внимание, что это значение не сохраняется между запусками.
Система управления версиями
Некоторые системы управления версиями, например git, игнорируют кодировки; git отслеживает только байты. Поведение других, например Azure DevOps или Mercurial, может отличаться. Даже некоторые средства, основанные на git, полагаются на декодирование текста.
Если это так, убедитесь, что вы:
- Настроили кодировку в системе управления версиями в соответствии с вашей конфигурацией VS Code.
- Сделали так, что все файлы добавляются в систему управления версиями в соответствующей кодировке.
- Остерегайтесь изменять кодировки, полученные через систему управления версиями. Ключевым признаком здесь будет разностный файл, который указывает, что изменения отсутствуют (так как изменены байты, но не символы).
Настройка PowerShell
В PowerShell кодировка по умолчанию зависит от версии:
- В PowerShell 6+ кодировка по умолчанию на всех платформах — UTF-8 без метки порядка байтов.
- В Windows PowerShell кодировка по умолчанию — обычно Windows-1252, расширение latin-1, которое также называется ISO 8859-1.
В PowerShell 5 + можно определить кодировку по умолчанию так:
Следующий скрипт может использоваться для определения кодировки, которую ваш сеанс PowerShell выводит для скрипта, где нет метки порядка байтов.
Можно настроить PowerShell так, чтобы использовать заданную кодировку в более общем виде с помощью параметров профиля. См. следующие статьи:
Заставить PowerShell использовать конкретную кодировку для входных данных невозможно. В PowerShell 5.1 и более ранних версий в Windows с языковым стандартом en-US по умолчанию используется кодировка Windows-1252, если отсутствует метка порядка байтов. Другие параметры языкового стандарта могут использовать другую кодировку. Для обеспечения совместимости лучше сохранять скрипты в Юникоде с меткой порядка байтов.
Любые другие имеющиеся у вас инструменты для работы со скриптами PowerShell могут зависеть от выбранных параметров кодировки или преобразовывать скрипты в другую кодировку.
The byte-order-mark
The byte-order-mark (BOM) is a Unicode signature in the first few bytes of a file or text stream that indicate which Unicode encoding used for the data. For more information, see the Byte order mark documentation.
In Windows PowerShell, any Unicode encoding, except UTF7 , always creates a BOM. PowerShell (v6 and higher) defaults to utf8NoBOM for all text output.
For best overall compatibility, avoid using BOMs in UTF-8 files. Unix platforms and Unix-heritage utilities also used on Windows Platforms don't support BOMs.
Similarly, UTF7 encoding should be avoided. UTF-7 is not a standard Unicode encoding and is written without a BOM in all versions of PowerShell.
Creating PowerShell scripts on a Unix-like platform or using a cross-platform editor on Windows, such as Visual Studio Code, results in a file encoded using UTF8NoBOM . These files work fine in PowerShell, but may break in Windows PowerShell if the file contains non-Ascii characters.
If you need to use non-Ascii characters in your scripts, save them as UTF-8 with BOM. Without the BOM, Windows PowerShell misinterprets your script as being encoded in the legacy "ANSI" codepage. Conversely, files that do have the UTF-8 BOM can be problematic on Unix-like platforms. Many Unix tools such as cat , sed , awk , and some editors such as gedit don't know how to treat the BOM.
Другие программы
Все другие программы, которые считывают или записывают скрипты PowerShell, могут перекодировать их.
- Использование буфера обмена для копирования и вставки скрипта. Такое часто встречается в следующих случаях:
- Копирование скрипта в виртуальную машину.
- Копирование скрипта из электронной почты или с веб-страницы.
- Копирование скрипта через документ Microsoft Word или PowerPoint.
- Блокнот;
- vim;
- любой другой редактор скриптов PowerShell.
- Get-Content / Set-Content / Out-File
- Операторы перенаправления PowerShell, такие как > и >> .
- sed / awk
- Веб-браузер при скачивании скриптов.
- Общий файловый ресурс.
Некоторые из этих средств работают с байтами, а не с текстом, но другие позволяют настраивать кодировки. В случаях, когда необходимо настроить кодировку, используйте те же параметры, что и в вашем редакторе, чтобы предотвратить возникновение проблем.
Взаимодействие расширения PowerShell для VS Code с кодировками
Расширение PowerShell взаимодействует со скриптами несколькими способами:
- При изменении скриптов в VS Code содержимое отправляется из VS Code в расширение. Протокол языкового сервера требует, чтобы это содержимое передавалось в UTF-8. Таким образом, расширение не сможет получить неправильную кодировку.
- При выполнении скриптов в интегрированной консоли они считываются оболочкой PowerShell непосредственно из файла. Если кодировка PowerShell отличается от кодировки VS Code, может произойти сбой.
- Когда скрипт, который открыт в VS Code, ссылается на другой скрипт, который не был открыт в VS Code, расширение загружает содержимое второго скрипта из файловой системы. Расширение PowerShell по умолчанию использует кодировку UTF-8, но при этом применяет обнаружение метки порядка байтов (BOM), чтобы выбрать правильную кодировку.
Проблема возникает при предположении кодировки, не использующей BOM (такой как UTF-8 без метки порядка байтов или Windows-1252). Расширение PowerShell по умолчанию использует UTF-8. Расширение не может изменить параметры кодировки в VS Code. Дополнительные сведения см. в разделе Проблема № 824.
Взаимодействие расширения PowerShell для VS Code с кодировками
Расширение PowerShell взаимодействует со скриптами несколькими способами:
- При изменении скриптов в VS Code содержимое отправляется из VS Code в расширение. Протокол языкового сервера требует, чтобы это содержимое передавалось в UTF-8. Таким образом, расширение не сможет получить неправильную кодировку.
- При выполнении скриптов в интегрированной консоли они считываются оболочкой PowerShell непосредственно из файла. Если кодировка PowerShell отличается от кодировки VS Code, может произойти сбой.
- Когда скрипт, который открыт в VS Code, ссылается на другой скрипт, который не был открыт в VS Code, расширение загружает содержимое второго скрипта из файловой системы. Расширение PowerShell по умолчанию использует кодировку UTF-8, но при этом применяет обнаружение метки порядка байтов (BOM), чтобы выбрать правильную кодировку.
Проблема возникает при предположении кодировки, не использующей BOM (такой как UTF-8 без метки порядка байтов или Windows-1252). Расширение PowerShell по умолчанию использует UTF-8. Расширение не может изменить параметры кодировки в VS Code. Дополнительные сведения см. в разделе Проблема № 824.
Среды других участников
Настроив систему управления версиями, убедитесь также, что параметры других участников, работающих над теми файлами, к которым вы предоставляете общий доступ, не переопределяют кодировку путем повторного кодирования файлов PowerShell.
Кодировка символов в PowerShell
В PowerShell (V6 и более поздних версий) параметр Encoding поддерживает следующие значения:
- ascii : Использует кодировку для набора символов ASCII (7-разрядных).
- bigendianunicode : Кодируется в формате UTF-16 с обратным порядком байтов.
- oem : Использует кодировку по умолчанию для программ MS-DOS и консолей.
- unicode : Кодируется в формате UTF-16 с прямым порядком байтов.
- utf7 : Кодируется в формате UTF-7.
- utf8 : Кодирует в формате UTF-8 (без спецификации).
- utf8BOM : Кодирует в формате UTF-8 с меткой порядка байтов (BOM)
- utf8NoBOM : Кодирует в формате UTF-8 без метки порядка байтов (BOM)
- utf32 : Кодируется в формате UTF-32.
По умолчанию PowerShell принимает utf8NoBOM значение для всех выходных данных.
Character encoding in PowerShell
In PowerShell (v6 and higher), the Encoding parameter supports the following values:
- ascii : Uses the encoding for the ASCII (7-bit) character set.
- bigendianunicode : Encodes in UTF-16 format using the big-endian byte order.
- oem : Uses the default encoding for MS-DOS and console programs.
- unicode : Encodes in UTF-16 format using the little-endian byte order.
- utf7 : Encodes in UTF-7 format.
- utf8 : Encodes in UTF-8 format (no BOM).
- utf8BOM : Encodes in UTF-8 format with Byte Order Mark (BOM)
- utf8NoBOM : Encodes in UTF-8 format without Byte Order Mark (BOM)
- utf32 : Encodes in UTF-32 format.
PowerShell defaults to utf8NoBOM for all output.
Интегрированная среда сценариев (ISE) PowerShell
При редактировании скриптов с помощью интегрированной среды сценариев PowerShell необходимо синхронизировать здесь параметры кодировки.
Интегрированная среда сценариев должна учитывать метку порядка байтов, но можно также использовать отражение для задания кодировки. Обратите внимание, что это значение не сохраняется между запусками.
Читайте также: