À l'aide de PowerShell pour écrire un fichier en UTF-8 sans BOM

La bon manière que pour l'instant est d'utiliser une solution recommandée par @Romain Kouzmine dans les commentaires à @M. Dudley réponse:

[IO.File]::WriteAllLines($filename, $content)

(J'ai aussi de raccourcir un peu par décapage inutile System espace de noms de clarification - il sera remplacé automatiquement par défaut.)

^{Note: Cette réponse s'applique à Windows PowerShell; en revanche, dans la croix-plate-forme de PowerShell de Base édition, UTF-8 sans BOM est le encodage par défaut.}

Pour compléter M. Dudley est propre, simple et pragmatique répondre (et ForNeVeR est plus concis reformulation):

Pour des raisons de commodité, voici une fonction avancée Out-FileUtf8NoBom, un pipeline de remplacement qui imite Out-File, ce qui signifie:

• vous pouvez l'utiliser comme Out-File dans un pipeline.
• d'entrée des objets qui ne sont pas des chaînes sont formatées comme ils le seraient si vous les a envoyés à la console, tout comme avec Out-File.

Exemple:

(Get-Content $MyPath) | Out-FileUtf8NoBom $MyPath

<sup>Notez comment (Get-Content $MyPath) est enfermé dans (...), qui assure que le fichier est ouvert, lire dans son intégralité, et fermé avant d'envoyer le résultat à travers le pipeline. Ce qui est nécessaire pour être en mesure d'écrire de nouveau à la même fichiers (mise à jour il en place).

En règle générale, cependant, cette technique n'est pas conseillé pour 2 raisons: (a) l'ensemble du dossier doit s'inscrire dans la mémoire et (b) si la commande est interrompue, les données seront perdues.</sup>

Une note sur l'utilisation de la mémoire:

• M. Dudley sa propre réponse exige que la totalité des fichiers contenus dans la mémoire de la première, ce qui peut être problématique avec de gros fichiers.
• La fonction ci-dessous améliore sur ce que légèrement: la saisie de tous les objets sont toujours tamponnée au premier abord, mais leurs représentations de chaîne sont alors générés et écrites dans le fichier de sortie, un par un.

---

Code Source de Out-FileUtf8NoBom (également disponible comme le MIT sous licence Gist):

<#
.SYNOPSIS
Outputs to a UTF-8-encoded file *without a BOM* (byte-order mark).
.DESCRIPTION
Mimics the most important aspects of Out-File:
* Input objects are sent to Out-String first.
* -Append allows you to append to an existing file, -NoClobber prevents
overwriting of an existing file.
* -Width allows you to specify the line width for the text representations
of input objects that aren't strings.
However, it is not a complete implementation of all Out-String parameters:
* Only a literal output path is supported, and only as a parameter.
* -Force is not supported.
Caveat: *All* pipeline input is buffered before writing output starts,
but the string representations are generated and written to the target
file one by one.
.NOTES
The raison d'être for this advanced function is that, as of PowerShell v5,
Out-File still lacks the ability to write UTF-8 files without a BOM:
using -Encoding UTF8 invariably prepends a BOM.
#>
function Out-FileUtf8NoBom {
[CmdletBinding()]
param(
[Parameter(Mandatory, Position=0)] [string] $LiteralPath,
[switch] $Append,
[switch] $NoClobber,
[AllowNull()] [int] $Width,
[Parameter(ValueFromPipeline)] $InputObject
)
#requires -version 3
# Make sure that the .NET framework sees the same working dir. as PS
# and resolve the input path to a full path.
[System.IO.Directory]::SetCurrentDirectory($PWD) # Caveat: .NET Core doesn't support [Environment]::CurrentDirectory
$LiteralPath = [IO.Path]::GetFullPath($LiteralPath)
# If -NoClobber was specified, throw an exception if the target file already
# exists.
if ($NoClobber -and (Test-Path $LiteralPath)) {
Throw [IO.IOException] "The file '$LiteralPath' already exists."
}
# Create a StreamWriter object.
# Note that we take advantage of the fact that the StreamWriter class by default:
# - uses UTF-8 encoding
# - without a BOM.
$sw = New-Object IO.StreamWriter $LiteralPath, $Append
$htOutStringArgs = @{}
if ($Width) {
$htOutStringArgs += @{ Width = $Width }
}
# Note: By not using begin /process /end blocks, we're effectively running
#       in the end block, which means that all pipeline input has already
#       been collected in automatic variable $Input.
#       We must use this approach, because using | Out-String individually
#       in each iteration of a process block would format each input object
#       with an indvidual header.
try {
$Input | Out-String -Stream @htOutStringArgs | % { $sw.WriteLine($_) }
} finally {
$sw.Dispose()
}
}

Lors de l'utilisation de Set-Content au lieu de Out-File, vous pouvez spécifier l'encodage Byte, qui peut être utilisé pour écrire un tableau d'octets dans un fichier. Ceci en combinaison avec un encodage UTF8 qui n'émettent pas de la NOMENCLATURE donne le résultat souhaité:

# This variable can be reused
$utf8 = New-Object System.Text.UTF8Encoding $false
$MyFile = Get-Content $MyPath -Raw
Set-Content -Value $utf8.GetBytes($MyFile) -Encoding Byte -Path $MyPath

La différence à l'aide de [IO.File]::WriteAllLines() ou similaires, c'est qu'il devrait fonctionner avec n'importe quel type d'élément et le chemin d'accès, pas uniquement les chemins d'accès de fichier.

    [System.IO.FileInfo] $file = Get-Item -Path $FilePath 
$sequenceBOM = New-Object System.Byte[] 3 
$reader = $file.OpenRead() 
$bytesRead = $reader.Read($sequenceBOM, 0, 3) 
$reader.Dispose() 
#A UTF-8+BOM string will start with the three following bytes. Hex: 0xEF0xBB0xBF, Decimal: 239 187 191 
if ($bytesRead -eq 3 -and $sequenceBOM[0] -eq 239 -and $sequenceBOM[1] -eq 187 -and $sequenceBOM[2] -eq 191) 
{ 
$utf8NoBomEncoding = New-Object System.Text.UTF8Encoding($False) 
[System.IO.File]::WriteAllLines($FilePath, (Get-Content $FilePath), $utf8NoBomEncoding) 
Write-Host "Remove UTF-8 BOM successfully" 
} 
Else 
{ 
Write-Warning "Not UTF-8 BOM file" 
}  

Source Comment faire pour supprimer UTF8 Marque d'Ordre des Octets (BOM) à partir d'un fichier à l'aide de PowerShell

Une technique que j'utilise est de rediriger la sortie vers un fichier ASCII à l'aide de la Out-File applet de commande.

Par exemple, j'ai souvent d'exécuter les scripts SQL que de créer un autre script SQL à exécuter dans Oracle. Avec une simple redirection (">"), la sortie sera en UTF-16 qui n'est pas reconnu par SQLPlus. Pour contourner ce problème:

sqlplus -s / as sysdba "@create_sql_script.sql" |
Out-File -FilePath new_script.sql -Encoding ASCII -Force

Le script généré peut ensuite être exécuté via un autre SQLPlus session sans Unicode soucis:

sqlplus / as sysdba "@new_script.sql" |
tee new_script.log

Pour quelque raison que ce soit, la WriteAllLines appels étaient encore en production d'une NOMENCLATURE pour moi, avec les BOMless UTF8Encoding argument et sans elle. Mais la suite a fonctionné pour moi:

$bytes = gc -Encoding byte BOMthetorpedoes.txt
[IO.File]::WriteAllBytes("$(pwd)\BOMthetorpedoes.txt", $bytes[3..($bytes.length-1)])

J'ai dû prendre le chemin de fichier absolu pour qu'il fonctionne. Sinon, il a écrit le fichier sur mon Bureau. Aussi, je suppose que cela ne fonctionne que si vous savez que votre MOB est de 3 octets. Je n'ai aucune idée de comment fiable c'est de s'attendre à une NOMENCLATURE format/longueur basé sur le codage.

Aussi, comme l'écrit, c'est probablement ce qui ne fonctionne que si votre fichier s'inscrit dans une powershell tableau, qui semble avoir une longueur limite d'une valeur inférieure à [int32]::MaxValue sur ma machine.

Pourrait utiliser ci-dessous pour obtenir de l'UTF8 sans BOM

$MyFile | Out-File -Encoding ASCII