SQL Server : Outil osql : attention à l'encoding des fichiers de scripts SQL...
Si jamais vous ne faites pas attention à l'encoding et que vous enregistrez vos fichiers SQL avec ce bon vieux codepage 1252 (ou autres), vous risquez quelques problèmes à l'execution des scripts.
Les outils graphiques comme l'analyseur de requêtes ne poseront normalement pas problème, et sqlcmd non plus.
Par contre si jamais vous travaillez pour SQL Server 2000 et que les outils clients SQL Server 2005 ne sont pas envisageables pour executer les scripts, vous passerez par osql, l'ancêtre de sqlcmd, qui se fera sans doute un plaisir de mal décoder vos fichiers...
Vous avez 2 solutions :
- réenregistrer les fichiers avec le codepage OEM de la machine qui va executer osql, pour que ce dernier décode correctement... (mais sqlcmd aura sans doute quelques problèmes avec...)
- utiliser Unicode (UTF-16 LE, CodePage 1200) pour qu'osql n'ai pas a décoder
Prenont le script suivant, enregistré dans différents encodings :
PRINT N'Bonjour, je suis un texte plutôt sympathique avec mes caractères "spéciaux".'
GO
Executés avec osql :
------------
UTF16LE.sql
Bonjour, je suis un texte plutôt sympathique avec mes caractères "spéciaux".
------------
UTF16BE.sql
Msg 102, Level 15, State 1, Server COQPRTBL, Line 1
Incorrect syntax near ' '.
------------
850.sql
Bonjour, je suis un texte plutôt sympathique avec mes caractères "spéciaux".
------------
1252.sql
Bonjour, je suis un texte plut¶t sympathique avec mes caract_res "spUciaux".
Les mêmes avec sqlcmd :
------------
UTF16LE.sql
Bonjour, je suis un texte plutôt sympathique avec mes caractères "spéciaux".
------------
UTF16BE.sql
Bonjour, je suis un texte plutôt sympathique avec mes caractères "spéciaux".
------------
850.sql
Bonjour, je suis un texte plut"t sympathique avec mes caractSres "sp,ciaux".
------------
1252.sql
Bonjour, je suis un texte plutôt sympathique avec mes caractères "spéciaux".
Comme vous allez probablement utiliser la seconde solution, voici un petit script PowerShell, relativement bateau, permettant de déterminer facilement la liste des fichiers sql qui ne seraient peut être pas enregistrés avec le bon encoding, histoire d'éviter les mauvaises surprises...
Pour celà, je me sert du préambule caractérisant l'UTF-16 Little Endian : FF FE (si vous chercher un éditeur hexa pour voir ça, jetez un oeil à HxD)
$path = $args[0]
if(!$path) { $path = Get-Location }
Get-ChildItem $path -force -recurse -include "*.sql" |
foreach {
$reader=$_.OpenRead()
if ( $reader.Length -lt 2 -or ( $reader.ReadByte() -ne 0xFF -or $reader.ReadByte() -ne 0xFE ) )
{
Write-Host "A VERIFIER : " -noNewLine
Write-Host $_.FullName
}
$reader.Close()
}
A noter que je ne fais pas la distinction entre UTF-16 LE et UTF-32 LE, qui aurait nécessiter d'approfondir le test en regardant si le préambule est FF FE 00 00.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
