Używanie StringWriter do serializacji XML

Obecnie szukam łatwego sposobu serializacji obiektów (w C # 3).

Wyszukałem w Google kilka przykładów i wymyśliłem coś takiego:

MemoryStream memoryStream = new MemoryStream ( );
XmlSerializer xs = new XmlSerializer ( typeof ( MyObject) );
XmlTextWriter xmlTextWriter = new XmlTextWriter ( memoryStream, Encoding.UTF8 );
xs.Serialize ( xmlTextWriter, myObject);
string result = Encoding.UTF8.GetString(memoryStream .ToArray());

Po przeczytaniu tego pytania zadałem sobie pytanie, dlaczego nie skorzystać z StringWriter? Wydaje się o wiele łatwiejsze.

XmlSerializer ser = new XmlSerializer(typeof(MyObject));
StringWriter writer = new StringWriter();
ser.Serialize(writer, myObject);
serializedValue = writer.ToString();

Innym problemem było to, że pierwszy przykład wygenerował XML, którego nie mogłem po prostu zapisać w kolumnie XML bazy danych SQL Server 2005.

Pierwsze pytanie brzmi: czy istnieje powód, dla którego nie powinienem używać StringWriter do serializacji obiektu, gdy potrzebuję go później jako ciągu? Nigdy nie znalazłem wyniku przy użyciu StringWriter podczas wyszukiwania w Google.

Druga to oczywiście: jeśli nie powinieneś tego robić za pomocą StringWriter (z jakichkolwiek powodów), który byłby dobry i poprawny sposób?

Dodanie:

Jak już wspomniano w obu odpowiedziach, przejdę dalej do problemu XML do bazy danych.

Pisząc do Bazy Danych dostałem następujący wyjątek:

System.Data.SqlClient.SqlException: Analiza XML: wiersz 1, znak 38, nie można zmienić kodowania

Na sznurku

<?xml version="1.0" encoding="utf-8"?><test/>

Wziąłem ciąg utworzony z XmlTextWriter i po prostu umieściłem tam jako xml. Ten nie zadziałał (ani przy ręcznym wstawianiu do bazy danych).

Później próbowałem ręcznego wstawiania (po prostu pisałem INSERT INTO ...) z encoding = "utf-16", co również się nie powiodło. Usunięcie kodowania całkowicie zadziałało. Po tym wyniku wróciłem do kodu StringWriter i voila - zadziałało.

Problem: Naprawdę nie rozumiem, dlaczego.

w Christian Hayter: Z tymi testami nie jestem pewien, czy muszę używać utf-16, aby pisać do DB. Czy wtedy ustawienie kodowania na UTF-16 (w tagu xml) nie zadziała?

<TL; DR> Problem jest raczej prosty: nie dopasowujesz zadeklarowanego kodowania (w deklaracji XML) do typu danych parametru wejściowego. Jeśli ręcznie dodano <?xml version="1.0" encoding="utf-8"?><test/>do ciągu, a następnie zadeklarowanie plikuSqlParameter jako typu SqlDbType.Xmllub SqlDbType.NVarCharspowodowałoby błąd „nie można zmienić kodowania”. Następnie, podczas ręcznego wstawiania przez T-SQL, ponieważ zmieniłeś zadeklarowane kodowanie na utf-16, wyraźnie wstawiałeś VARCHARciąg (bez prefiksu wielkiej litery „N”, stąd kodowanie 8-bitowe, takie jak UTF-8) a nie NVARCHARciągiem (poprzedzonym dużą literą „N”, stąd 16-bitowe kodowanie UTF-16 LE).

Poprawka powinna być tak prosta, jak:

1. W pierwszym przypadku dodając deklarację o treści encoding="utf-8": po prostu nie dodawaj deklaracji XML.
2. W drugim przypadku przy dodawaniu deklaracji z podaniem encoding="utf-16" : albo
   1. po prostu nie dodawaj deklaracji XML, LUB
   2. po prostu dodaj „N” do typu parametru wejściowego: SqlDbType.NVarCharzamiast SqlDbType.VarChar:-) (lub nawet przełącz się na używanie SqlDbType.Xml)

(Szczegółowa odpowiedź znajduje się poniżej)

Wszystkie odpowiedzi tutaj są zbyt skomplikowane i niepotrzebne (niezależnie od 121 i 184 głosów pozytywnych odpowiednio na odpowiedzi Christiana i Jona). Mogą dostarczyć działający kod, ale żaden z nich tak naprawdę nie odpowiada na pytanie. Problem polega na tym, że nikt tak naprawdę nie zrozumiał pytania, które ostatecznie dotyczy tego, jak działa typ danych XML w SQL Server. Nie ma nic przeciwko tym dwóm wyraźnie inteligentnym ludziom, ale to pytanie nie ma nic wspólnego z serializacją do XML. Zapisywanie danych XML w SQL Server jest znacznie łatwiejsze niż to, co jest tutaj sugerowane.

Nie ma znaczenia, w jaki sposób powstaje XML, o ile przestrzegasz zasad tworzenia danych XML w SQL Server. Mam dokładniejsze wyjaśnienie (w tym działający przykładowy kod ilustrujący punkty przedstawione poniżej) w odpowiedzi na to pytanie: Jak rozwiązać błąd „nie można zmienić kodowania” podczas wstawiania XML do SQL Server , ale podstawy są następujące:

1. Deklaracja XML jest opcjonalna
2. Typ danych XML przechowuje łańcuchy zawsze jako UCS-2 / UTF-16 LE
3. Jeśli Twój XML to UCS-2 / UTF-16 LE, to:
   1. przechodzą w danych, jak też NVARCHAR(MAX)i XML/ SqlDbType.NVarChar(MAXSIZE = 1) lub SqlDbType.Xml, czy za pomocą łańcuch znaków to musi być poprzedzone dużą literę „n”.
   2. jeśli określasz deklarację XML, musi to być „UCS-2” lub „UTF-16” (nie ma tu żadnej różnicy)
4. Jeśli Twój kod XML jest 8-bitowy (np. „UTF-8” / „iso-8859-1” / „Windows-1252”), to:
   1. należy określić deklarację XML, JEŚLI kodowanie jest inne niż strona kodowa określona przez domyślne sortowanie bazy danych
   2. musisz przekazać dane jako VARCHAR(MAX)/ SqlDbType.VarChar(maxsize = -1), lub jeśli używasz literału łańcuchowego, nie możesz poprzedzać go wielką literą „N”.
   3. Niezależnie od zastosowanego kodowania 8-bitowego, „kodowanie” odnotowane w deklaracji XML musi odpowiadać faktycznemu kodowaniu bajtów.
   4. Kodowanie 8-bitowe zostanie przekonwertowane na UTF-16 LE przez typ danych XML

Mając na uwadze powyższe punkty i biorąc pod uwagę, że ciągi znaków w .NET to zawsze UTF-16 LE / UCS-2 LE (nie ma między nimi różnicy w zakresie kodowania), możemy odpowiedzieć na Twoje pytania:

Czy istnieje powód, dla którego nie powinienem używać StringWriter do serializacji obiektu, gdy potrzebuję go później jako ciągu?

Nie, Twój StringWriterkod wydaje się być w porządku (przynajmniej nie widzę żadnych problemów w moich ograniczonych testach z użyciem drugiego bloku kodu z pytania).

Czy wtedy ustawienie kodowania na UTF-16 (w tagu xml) nie zadziała?

Podawanie deklaracji XML nie jest konieczne. Gdy go brakuje, zakłada się, że kodowanie to UTF-16 LE, jeśli przekazujesz ciąg do SQL Server jako NVARCHAR(tj. SqlDbType.NVarChar) Lub XML(tj SqlDbType.Xml.). Zakłada się, że kodowanie jest domyślną 8-bitową stroną kodową, jeśli jest przekazywane jako VARCHAR(tj SqlDbType.VarChar.). Jeśli masz jakieś niestandardowe znaki ASCII (tj. Wartości 128 i więcej) i przekazujesz je jako VARCHAR, prawdopodobnie zobaczysz znak „?” dla znaków BMP i „??” dla znaków uzupełniających, ponieważ SQL Server skonwertuje ciąg znaków UTF-16 z .NET na 8-bitowy ciąg strony kodowej bieżącej bazy danych przed konwersją z powrotem na UTF-16 / UCS-2. Ale nie powinieneś otrzymać żadnych błędów.

Z drugiej strony, jeśli określisz deklarację XML, musisz przekazać ją do SQL Server przy użyciu pasującego 8-bitowego lub 16-bitowego typu danych. Więc jeśli masz deklarację stwierdzającą, że kodowanie to UCS-2 lub UTF-16, musisz przekazać jako SqlDbType.NVarCharlub SqlDbType.Xml. Albo, jeśli masz deklarację stwierdzającą, że kodowanie jest jedną z opcji 8-bitowych (to znaczy UTF-8, Windows-1252, iso-8859-1itp), to musi przejść w jak SqlDbType.VarChar. Niezgodność zadeklarowanego kodowania z odpowiednim 8- lub 16-bitowym typem danych programu SQL Server spowoduje wystąpienie błędu „nie można zmienić kodowania”.

Na przykład, używając StringWriterkodu serializacji opartego na twoim , po prostu wydrukowałem wynikowy ciąg XML i użyłem go w SSMS. Jak widać poniżej, deklaracja XML jest włączone (bo StringWriternie ma opcji do OmitXmlDeclarationjak XmlWriterrobi), która nie stanowi żadnego problemu, tak długo, jak przekazać ciąg jako prawidłowy typ danych SQL Server:

-- 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>

Jak widać, obsługuje nawet znaki spoza standardowego ASCII, biorąc pod uwagę, że ሴjest to punkt kodowy BMP U + 1234 i 😸jest to dodatkowy punkt kodowy znaków U + 1F638. Jednak następujące:

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

powoduje następujący błąd:

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

Ergo, pomijając te wszystkie wyjaśnienia, pełne rozwiązanie twojego pierwotnego pytania brzmi:

Wyraźnie przekazałeś ciąg jako SqlDbType.VarChar. Przełącz się na SqlDbType.NVarChari będzie działać bez konieczności przechodzenia przez dodatkowy krok polegający na usunięciu deklaracji XML. Jest to preferowane rozwiązanie zamiast zachowywania SqlDbType.VarChari usuwania deklaracji XML, ponieważ to rozwiązanie zapobiega utracie danych, gdy XML zawiera niestandardowe znaki ASCII. Na przykład:

-- 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>

Jak widać, tym razem nie ma błędu, ale teraz nastąpiła utrata danych 🙀.

Jednym z problemów StringWriterjest to, że domyślnie nie pozwala ustawić kodowania, które reklamuje - więc możesz skończyć z dokumentem XML reklamującym jego kodowanie jako UTF-16, co oznacza, że ​​musisz zakodować go jako UTF-16, jeśli zapisz to do pliku. Mam jednak małą klasę do pomocy w tym:

public sealed class StringWriterWithEncoding : StringWriter
{
    public override Encoding Encoding { get; }

    public StringWriterWithEncoding (Encoding encoding)
    {
        Encoding = encoding;
    }    
}

Lub jeśli potrzebujesz tylko UTF-8 (co jest wszystkim, czego często potrzebuję):

public sealed class Utf8StringWriter : StringWriter
{
    public override Encoding Encoding => Encoding.UTF8;
}

Jeśli chodzi o powody, dla których nie możesz zapisać pliku XML w bazie danych - musisz podać nam więcej szczegółów na temat tego, co się stało, gdy próbowałeś, jeśli chcesz, abyśmy mogli to zdiagnozować / naprawić.

Podczas serializacji dokumentu XML do łańcucha .NET należy ustawić kodowanie na UTF-16. Łańcuchy są wewnętrznie przechowywane jako UTF-16, więc jest to jedyne kodowanie, które ma sens. Jeśli chcesz przechowywać dane w innym kodowaniu, zamiast tego użyj tablicy bajtów.

SQL Server działa na podobnej zasadzie; każdy ciąg przekazany do xmlkolumny musi być zakodowany w formacie UTF-16. SQL Server odrzuci każdy ciąg, w którym deklaracja XML nie określa UTF-16. Jeśli deklaracja XML nie jest obecna, standard XML wymaga, aby była ona domyślnie ustawiona na UTF-8, więc SQL Server również ją odrzuci.

Mając to na uwadze, oto kilka użytecznych metod konwersji.

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);
        }
    }
}

Przede wszystkim uważaj na stare przykłady. Znalazłeś taki, który używa XmlTextWriter, który jest przestarzały od .NET 2.0. XmlWriter.Createnależy użyć zamiast tego.

Oto przykład serializacji obiektu do kolumny XML:

public void SerializeToXmlColumn(object obj)
{
    using (var outputStream = new MemoryStream())
    {
        using (var writer = XmlWriter.Create(outputStream))
        {
            var serializer = new XmlSerializer(obj.GetType());
            serializer.Serialize(writer, obj);
        }

        outputStream.Position = 0;
        using (var conn = new SqlConnection(Settings.Default.ConnectionString))
        {
            conn.Open();

            const string INSERT_COMMAND = @"INSERT INTO XmlStore (Data) VALUES (@Data)";
            using (var cmd = new SqlCommand(INSERT_COMMAND, conn))
            {
                using (var reader = XmlReader.Create(outputStream))
                {
                    var xml = new SqlXml(reader);

                    cmd.Parameters.Clear();
                    cmd.Parameters.AddWithValue("@Data", xml);
                    cmd.ExecuteNonQuery();
                }
            }
        }
    }
}

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;
}

Być może zostało to omówione gdzie indziej, ale po prostu zmiana linii kodowania źródła XML na „utf-16” umożliwia wstawienie XML do typu xml'data serwera SQL Server.

using (DataSetTableAdapters.SQSTableAdapter tbl_SQS = new DataSetTableAdapters.SQSTableAdapter())
{
    try
    {
        bodyXML = @"<?xml version="1.0" encoding="UTF-8" standalone="yes"?><test></test>";
        bodyXMLutf16 = bodyXML.Replace("UTF-8", "UTF-16");
        tbl_SQS.Insert(messageID, receiptHandle, md5OfBody, bodyXMLutf16, sourceType);
    }
    catch (System.Data.SqlClient.SqlException ex)
    {
        Console.WriteLine(ex.Message);
        Console.ReadLine();
    }
}

W rezultacie cały tekst XML zostanie wstawiony do pola typu danych „xml”, ale wiersz „nagłówka” zostanie usunięty. To, co widzisz w wynikowym rekordzie, jest po prostu

<test></test>

Użycie metody serializacji opisanej we wpisie „Odpowiedzi” jest sposobem na włączenie oryginalnego nagłówka do pola docelowego, ale w rezultacie pozostały tekst XML jest zawarty w <string></string>znaczniku XML .

Adapter tabeli w kodzie jest klasą automatycznie budowaną przy użyciu kreatora „Dodaj nowe źródło danych:” programu Visual Studio 2013. Pięć parametrów metody Insert jest odwzorowywana na pola w tabeli programu SQL Server.