À l'aide de StringWriter pour la Sérialisation XML

<TL;DR> Le problème est assez simple, en fait: vous ne correspondant pas à la déclaration de l'encodage (dans la déclaration XML) avec le type de données du paramètre d'entrée. Si vous avez ajouté manuellement <?xml version="1.0" encoding="utf-8"?><test/> à la chaîne, puis de déclarer la SqlParameter pour être de type SqlDbType.Xml ou SqlDbType.NVarChar vous donnera les "incapables de changer l'encodage d'erreur". Ensuite, lorsque vous insérez manuellement par l'intermédiaire de T-SQL, depuis que vous avez changé l'encodage déclaré être utf-16, vous étiez clairement l'insertion d'une VARCHAR chaîne (pas de préfixe avec une majuscule, "N", donc un 8-bits, tel que UTF-8) et non pas une NVARCHAR chaîne (commençant par une majuscule, "N", d'où la 16-bits de l'UTF-16 LE codage).

Le correctif doit avoir été aussi simple que:

1. Dans le premier cas, lors de l'ajout de la déclaration attestant encoding="utf-8": il suffit de ne pas ajouter de la déclaration XML.
2. Dans le second cas, lors de l'ajout de la déclaration attestant encoding="utf-16": soit
   1. suffit de ne pas ajouter la déclaration XML, OU
   2. simplement ajouter un "N" pour le type de paramètre d'entrée: SqlDbType.NVarChar au lieu de SqlDbType.VarChar 🙂 (ou peut-être même passer à l'utilisation de SqlDbType.Xml)

(Réponse détaillée ci-dessous)

---

Toutes les réponses ici sont trop compliquées et inutiles (quel que soit le 121 et 184 jusqu'-voix de Christian et de Jon réponses, respectivement). Ils pourraient fournir des code de travail, mais aucun de ceux qui ont répondu à la question. Le problème est que personne n'a vraiment compris la question, qui est en fin de compte sur la façon dont le type de données XML dans SQL Server fonctionne. Rien contre ces deux clairement des gens intelligents, mais cette question a peu ou rien à voir avec la sérialisation XML. Enregistrement des données XML dans SQL Server est beaucoup plus facile que ce qui est sous-entendu ici.

Il n'importe pas vraiment comment le XML est produite aussi longtemps que vous suivez les règles pour créer des données XML dans SQL Server. J'ai une explication plus complète (y compris le travail un exemple de code pour illustrer les points décrits ci-dessous) dans une réponse sur cette question: Comment faire pour résoudre les “incapables de changer l'encodage” erreur lors de l'insertion de données XML dans SQL Server, mais les bases sont:

1. La déclaration XML est facultatif
2. Le type de données XML stocke des chaînes toujours UCS-2 ET UTF-16 LE
3. Si votre XML est UCS-2 ET UTF-16 LE, puis vous:
   1. passer dans les données que soit NVARCHAR(MAX) ou XML /SqlDbType.NVarChar (maxsize = -1) ou SqlDbType.Xml, ou si vous utilisez une chaîne de caractères littérale, alors il doit commencer par une majuscule "N".
   2. si la spécification de la déclaration XML, il doit être doit être "UCS-2" ou "UTF-16" (pas de véritable différence ici)
4. Si votre XML est de 8 bits codés (par exemple, "UTF-8" /"iso-8859-1" /"Windows-1252"), vous:
   1. besoin de spécifier la déclaration XML SI le codage est différent de celui de la page de code spécifié par le Classement par défaut de la base de données
   2. vous devez transmettre les données VARCHAR(MAX) /SqlDbType.VarChar (maxsize = -1), ou si vous utilisez une chaîne de caractères littérale, ensuite, il faut pas être préfixé avec un cas supérieur "N".
   3. Quelle que soit la 8-bits est utilisé, le "codage", a indiqué dans la déclaration XML doit correspondre au codage des octets.
   4. La 8-bits de codage sera converti en UTF-16 LE par le type de données XML

Avec les points énoncés ci-dessus à l'esprit, et donné que les chaînes de caractères dans .NET sont toujours UTF-16 LE /UCS-2 LE (il n'y a pas de différence entre les deux termes de l'encodage), nous pouvons répondre à vos questions:

Est-il une raison pourquoi je ne devrais pas utiliser StringWriter pour sérialiser un Objet quand j'en ai besoin comme une chaîne de caractères par la suite?

Non, votre StringWriter code semble pas y avoir de problème (du moins je ne vois pas de problèmes à mon de test limitée à l'aide de la 2e bloc de code à partir de la question).

Ne serait pas le réglage du codage UTF-16 (dans la balise xml) fonctionne alors?

Il n'est pas nécessaire de fournir la déclaration XML. Quand il est absent, le codage doit être encodé en UTF-16 LE si vous passez la chaîne dans SQL Server comme NVARCHAR (c'est à dire SqlDbType.NVarChar) ou XML (c'est à dire SqlDbType.Xml). L'encodage est supposé être à l'8 bits par défaut de la Page de Code si le passage en VARCHAR (c'est à dire SqlDbType.VarChar). Si vous avez des non-standard des caractères ASCII (c'est à dire les valeurs 128 et ci-dessus) et passant comme VARCHAR, alors vous aurez probablement voir le "?" pour BMP personnages et les "??" pour les Caractères Supplémentaires comme SQL Server vous permet de convertir le format UTF-16 de la chaîne d' .NET dans un 8-bit de la chaîne de la Base de données actuelle de la Page de Code avant de le reconvertir en UTF-16 /UCS-2. Mais vous ne devriez pas faire des erreurs.

Sur l'autre main, si vous ne spécifiez la déclaration XML, puis vous doit passer dans SQL Server à l'aide de la correspondance de 8-bits ou 16-bits type de données. Donc, si vous avez une déclaration indiquant que le codage soit UCS-2 et UTF-16, alors vous doit passer comme SqlDbType.NVarChar ou SqlDbType.Xml. Ou, si vous avez une déclaration indiquant que le codage est l'un des 8-bits options (c'est à dire UTF-8, Windows-1252, iso-8859-1, etc), alors vous doit passer comme SqlDbType.VarChar. L'échec pour correspondre à la déclaration de l'encodage avec le bon 8 ou 16 bits de SQL Server données en résultera le "incapables de changer l'encodage d'erreur que vous obtenez.

Par exemple, à l'aide de votre StringWriterà base de code de sérialisation, j'ai tout simplement imprimé la chaîne résultante de l'XML et l'a utilisé dans SSMS. Comme vous pouvez le voir ci-dessous, la déclaration XML est inclus (parce que StringWriter n'a pas une option pour OmitXmlDeclaration comme XmlWriter n'), ce qui ne pose pas de problème tant que vous passez la chaîne dans le Serveur SQL correcte type de données:

-- Upper-case "N" prefix == NVARCHAR, hence no error:
DECLARE @Xml XML = N'<?xml version="1.0" encoding="utf-16"?>
<string>Test ሴ</string>';
SELECT @Xml;
-- <string>Test ሴ</string>

Comme vous pouvez le voir, il prend même en charge les caractères au-delà de la norme ASCII, étant donné que ሴ est BMP Point de Code U+1234, et est Complémentaire de Caractère de Point de Code U+1F638. Toutefois, les éléments suivants:

-- No upper-case "N" prefix on the string literal, hence VARCHAR:
DECLARE @Xml XML = '<?xml version="1.0" encoding="utf-16"?>
<string>Test ሴ</string>';

résultats dans l'erreur suivante:

Msg 9402, Level 16, State 1, Line XXXXX
XML parsing: line 1, character 39, unable to switch the encoding

---

Ergo, tout cela explication de côté, la solution complète à votre question de départ est:

Vous ont été clairement passage de la chaîne en tant que SqlDbType.VarChar. Interrupteur à SqlDbType.NVarChar et il fonctionne sans avoir besoin de passer par l'étape supplémentaire de retrait de la déclaration XML. C'est préférable sur le maintien SqlDbType.VarChar et la suppression de la déclaration XML parce que cette solution permettra d'éviter la perte de données lorsque le fichier XML inclut non-standard des caractères ASCII. Par exemple:

-- No upper-case "N" prefix on the string literal == VARCHAR, and no XML declaration:
DECLARE @Xml2 XML = '<string>Test ሴ</string>';
SELECT @Xml2;
-- <string>Test ???</string>

Comme vous pouvez le voir, il n'y a pas d'erreur cette fois, mais maintenant, il est de la perte de données .

Quand serialising un document XML à un .NET de chaîne, le codage doit être configuré en UTF-16. Les chaînes de caractères sont stockées en tant que UTF-16 en interne, c'est donc le seul encodage qui fait sens. Si vous souhaitez stocker les données dans un autre encodage, vous utilisez un tableau d'octets au lieu.

SQL Server fonctionne sur un principe similaire; toute chaîne de caractères passée en un xml colonne doit être codé en UTF-16. SQL Serveur rejette toute chaîne où la déclaration XML n'a pas de spécifier l'encodage UTF-16. Si la déclaration XML n'est pas présent, alors le XML standard exige que la valeur par défaut est UTF-8, SQL Server va rejeter ainsi.

Gardant cela à l'esprit, voici quelques méthodes utiles pour faire la conversion.

public static string Serialize<T>(T value) {

    if(value == null) {
        return null;
    }

    XmlSerializer serializer = new XmlSerializer(typeof(T));

    XmlWriterSettings settings = new XmlWriterSettings()
    {
        Encoding = new UnicodeEncoding(false, false), //no BOM in a .NET string
        Indent = false,
        OmitXmlDeclaration = false
    };

    using(StringWriter textWriter = new StringWriter()) {
        using(XmlWriter xmlWriter = XmlWriter.Create(textWriter, settings)) {
            serializer.Serialize(xmlWriter, value);
        }
        return textWriter.ToString();
    }
}

public static T Deserialize<T>(string xml) {

    if(string.IsNullOrEmpty(xml)) {
        return default(T);
    }

    XmlSerializer serializer = new XmlSerializer(typeof(T));

    XmlReaderSettings settings = new XmlReaderSettings();
    //No settings need modifying here

    using(StringReader textReader = new StringReader(xml)) {
        using(XmlReader xmlReader = XmlReader.Create(textReader, settings)) {
            return (T) serializer.Deserialize(xmlReader);
        }
    }
}

public static T DeserializeFromXml<T>(string xml)
{
    T result;
    XmlSerializerFactory serializerFactory = new XmlSerializerFactory();
    XmlSerializer serializer =serializerFactory.CreateSerializer(typeof(T));

    using (StringReader sr3 = new StringReader(xml))
    {
        XmlReaderSettings settings = new XmlReaderSettings()
        {
            CheckCharacters = false //default value is true;
        };

        using (XmlReader xr3 = XmlTextReader.Create(sr3, settings))
        {
            result = (T)serializer.Deserialize(xr3);
        }
    }

    return result;
}