Używanie StringWriter do serializacji XML


99

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?


1
Idę na osobiste doświadczenie. SQL Server akceptuje tylko UTF-16, a jeśli przekażesz mu cokolwiek innego, jesteś zdany na łaskę parsera SQL Server XML i jego prób konwersji danych. Zamiast próbować znaleźć sposób na oszukanie go, po prostu przekazuję go bezpośrednio UTF-16, który zawsze zadziała.
Christian Hayter

Jak piszesz to do bazy danych? Czy przekazujesz ciąg, tablicę bajtów, czy piszesz do strumienia? Jeśli jest to jedna z dwóch ostatnich form, musisz upewnić się, że zadeklarowane kodowanie odpowiada faktycznemu kodowaniu danych binarnych.
Jon Skeet

uff. Ręczna próba wykonana jako Query w MS SQL Management Studio. „Zakodowane” próby były zapisywane w łańcuchu, który był następnie przekazywany do O / R Mapper, który zapisywał jako ciąg (o ile mogłem śledzić). W rzeczywistości przekazuję mu ciąg, który został utworzony w dwóch przykładach podanych w moim pytaniu.
StampedeXV


1
Zmieniam zaakceptowaną odpowiedź, ponieważ uważam, że faktycznie odpowiada ona na moje pytanie. Mimo że inne odpowiedzi pomogły mi kontynuować moją pracę, myślę, że na potrzeby Stackoverflow odpowiedź Solomona pomoże innym lepiej zrozumieć, co się stało. [Zastrzeżenie]: Nie znalazłem czasu, aby naprawdę zweryfikować odpowiedź.
StampedeXV

Odpowiedzi:


1

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


Myślę, że to ja byłem powodem tych zbyt skomplikowanych odpowiedzi, ponieważ w zasadzie miałem dwa pytania w jednym. Bardzo podoba mi się twoja zwięzła odpowiedź i spróbuję jej następnym razem, gdy będę musiał przechowywać XML w DB. Więc jeśli dobrze rozumiem: wyjaśniłeś wyzwania związane z przechowywaniem XML w DB. Jon Skeet podsumował problemy z używaniem StringWriter podczas pracy z XML (z wyjątkiem UTF-16), a Christian Hayter zapewnia przyjemny sposób, aby po prostu z nim pracować.
StampedeXV

@StampedeXV Zaktualizowałem swoją odpowiedź (kilka zmian dla przejrzystości + nowe rzeczy, aby lepiej zilustrować punkty). Miejmy nadzieję, że teraz jest jaśniejsze, że chociaż obie te odpowiedzi są dobre same w sobie, nie są w żaden sposób konieczne, aby odpowiedzieć na twoje pytanie. Zajmują się serializacją XML w C # / .NET, ale to pytanie tak naprawdę dotyczy zapisywania XML w SQL Server. Dostarczają informacji, które warto znać i które mogą być lepszym kodem niż pierwotnie podałeś, ale żaden z nich (ani żaden z pozostałych tutaj) nie jest naprawdę na temat. Ale to nie jest dobrze udokumentowana sprawa, stąd zamieszanie.
Solomon Rutzky

@StampedeXV Czy moje poprawki miały sens? Właśnie dodałem sekcję podsumowania u góry, która może być bardziej przejrzysta. Krótko mówiąc: chyba, że ​​działo się coś innego, czego nie uwzględniłeś w pytaniu, wtedy wygląda na to, że Twój kod był w 99% poprawny i prawdopodobnie można go było naprawić, dodając jedną wielką literę " N ”. Żadne specjalne kodowanie nie jest potrzebne, a kod Christiana jest fajny, ale moje testy pokazują, że zwraca serializację identyczną z twoim drugim blokiem kodu, z wyjątkiem tego, że twój umieszcza CRLF po deklaracji XML. Założę się, że zmieniłeś się na SqlDbType.NVarCharlub Xml.
Solomon Rutzky

wciąż próbuję znaleźć czas, żeby to sprawdzić. Z pewnością brzmi to dobrze i logicznie, ale nie jestem pewien, czy wystarczyłoby to do zmiany zaakceptowanej odpowiedzi.
StampedeXV

216

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


Omówiłem teraz bardziej szczegółowo problem z bazą danych. Zobacz pytanie.
StampedeXV

4
Smutne, że StringWriternie bierze pod uwagę kodowania, ale nie mniej, dzięki za sprytną małą metodę :)
Chau

2
A „Analiza XML: wiersz 1, znak 38, nie można zmienić kodowania” można rozwiązać za pomocą polecenia „settings.Indent = false; settings.OmitXmlDeclaration = false;”
MGE

Zwykle omijam ten problem, używając po prostu a MemoryStreami a StreamWriterz odpowiednim kodowaniem. StreamWriter jest w TextWriterkońcu typem ( XmlWriter.Createoczekiwanym) z konfigurowalnym kodowaniem.
Nyerguds

2
@Nyerguds: Więc stwórz pakiet Nuget z tego rodzaju rzeczami, wtedy zawsze będzie łatwo się do niego dostać. Wolałbym to zrobić, niż narażać na szwank czytelność kodu, który zasadniczo dotyczy innych wymagań.
Jon Skeet,

126

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

Zobacz dodanie pytania. Nie rozumiem wyników moich testów, wydaje się , że zaprzeczają one twojemu stwierdzeniu, że DB zawsze chce / bierze / potrzebuje UTF-16.
StampedeXV

9
Ty nie masz do kodowania UTF-16 - ale trzeba się upewnić, że kodowanie użyć meczów jaka StringWriteroczekuje. Zobacz moją odpowiedź. Format pamięci wewnętrznej nie ma tutaj znaczenia.
Jon Skeet

ok, rozumiem. W moim nowym przykładzie: całkowite pozostawienie kodowania sprawiło, że DB sam zdecydował, które kodowanie zostało użyte - dlatego zadziałało. Czy teraz dobrze to rozumiem?
StampedeXV

1
@SteveC: Przepraszam, mój błąd. Ręcznie przekonwertowałem kod z VB, który Nothingjest niejawnie konwertowany na dowolny typ. Poprawiłem Deserializekod. SerializeOstrzegawczy musi być Resharper-jedyną rzeczą, kompilator na własną rękę nie sprzeciw i jest zgodne z prawem.
Christian Hayter,

1
W nawiązaniu do komentarza Jona Skeeta, nie, UTF-16 nie jest wymagany. Aby zapoznać się z konkretnym przykładem, który to demonstruje, odwiedź stronę stackoverflow.com/a/8998183/751158 .
ziesemer

20

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

2
Mogę zagłosować tylko raz, ale to zasługuje na najlepszą odpowiedź. W końcu nie ma znaczenia, jakie kodowanie jest zadeklarowane lub używane, o ile XmlReadermoże je przeanalizować. Zostanie wysłany wstępnie przeanalizowany do bazy danych, a wtedy baza danych nie musi nic wiedzieć o kodowaniu znaków - UTF-16 lub innym. W szczególności należy zauważyć, że deklaracje XML nie są nawet utrwalane z danymi w bazie danych, niezależnie od metody ich wstawiania. Proszę nie marnować czasu, uruchamiając XML za pomocą dodatkowych konwersji, jak pokazano w innych odpowiedziach tutaj i gdzie indziej.
ziesemer

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

-1

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.


2
Zastąpić? To przezabawne.
mgilberties

2
Poważnie - nie rób tego. Zawsze. A co, gdybym chciał dołączyć do mojego XML trochę prozy, w której wspomniano o „UTF-8” - właśnie zmieniłeś moje dane na coś, czego nie powiedziałem!
Tim Abell,

2
Dziękuję za wskazanie błędu w kodzie. Zamiast bodyXML.Replace ("UTF-8", "UTF-16") powinien istnieć kod skupiający się na nagłówku XML zmieniającym UTF-8 na UTF-16. Naprawdę starałem się wskazać, wprowadzając tę ​​zmianę w nagłówku źródłowego XML, a następnie treść XML można wstawić do rekordu tabeli SQL za pomocą pola typu danych XML, a nagłówek zostanie usunięty. Z powodów, których teraz nie pamiętam (cztery lata temu!), Wynik był wtedy przydatny. I tak, głupi błąd przy użyciu „Zamień”. Zdarza się.
DLG
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.