Menggunakan StringWriter untuk Serialisasi XML

99

Saya sedang mencari cara mudah untuk membuat serial objek (di C # 3).

Saya mencari beberapa contoh di Google dan menemukan sesuatu seperti:

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

Setelah membaca pertanyaan ini saya bertanya pada diri sendiri, mengapa tidak menggunakan StringWriter? Sepertinya jauh lebih mudah.

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

Masalah lain adalah, bahwa contoh pertama menghasilkan XML Saya tidak bisa begitu saja menulis ke dalam kolom XML SQL Server 2005 DB.

Pertanyaan pertama adalah: Apakah ada alasan mengapa saya tidak boleh menggunakan StringWriter untuk membuat serial Objek ketika saya membutuhkannya sebagai string sesudahnya? Saya tidak pernah menemukan hasil menggunakan StringWriter saat googling.

Yang kedua, tentu saja: Jika Anda tidak boleh melakukannya dengan StringWriter (karena alasan apa pun), mana yang merupakan cara yang baik dan benar?


Tambahan:

Seperti yang telah disebutkan oleh kedua jawaban, selanjutnya saya akan membahas masalah XML ke DB.

Saat menulis ke Database saya mendapat pengecualian berikut:

System.Data.SqlClient.SqlException: XML parsing: baris 1, karakter 38, tidak dapat mengalihkan pengkodean

Untuk string

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

Saya mengambil string yang dibuat dari XmlTextWriter dan meletakkannya sebagai xml di sana. Yang ini tidak berhasil (tidak dengan penyisipan manual ke DB).

Setelah itu saya mencoba penyisipan manual (hanya menulis INSERT INTO ...) dengan encoding = "utf-16" yang juga gagal. Menghapus pengkodean benar-benar berfungsi saat itu. Setelah hasil itu saya beralih kembali ke kode Penulis String dan voila - itu berhasil.

Masalah: Saya tidak begitu mengerti mengapa.

di Christian Hayter: Dengan tes tersebut saya tidak yakin apakah saya harus menggunakan utf-16 untuk menulis ke DB. Tidakkah pengaturan encoding ke UTF-16 (dalam tag xml) akan berfungsi?

StampedeXV
sumber
1
Saya akan mengalami pengalaman pribadi. SQL Server hanya menerima UTF-16, dan jika Anda meneruskan apa pun, Anda bergantung pada pengurai SQL Server XML dan upayanya untuk mengonversi data. Alih-alih mencoba menemukan cara untuk membodohinya, saya hanya menyebarkannya UTF-16 secara langsung, yang akan selalu berhasil.
Christian Hayter
Bagaimana Anda menulis ini ke database? Apakah Anda meneruskannya ke string, atau array byte, atau menulis ke aliran? Jika itu salah satu dari dua bentuk terakhir, Anda perlu memastikan bahwa pengkodean yang Anda nyatakan cocok dengan pengkodean sebenarnya dari data biner Anda.
Jon Skeet
Fiuh. Manual coba saya buat sebagai Query di MS SQL Management Studio. Percobaan "kode" ditulis ke string yang kemudian diteruskan ke Pemeta O / R yang menulis sebagai string (sejauh yang saya bisa ikuti). Sebenarnya saya meneruskan string yang dibuat dalam dua contoh yang diberikan dalam pertanyaan saya.
StampedeXV
FYI untuk pembaca - hampir duplikat: stackoverflow.com/questions/384974/… dan stackoverflow.com/questions/3760788/…
ziesemer
1
Saya mengubah jawaban yang diterima karena saya yakin jawaban itu benar-benar menjawab pertanyaan saya. Meskipun jawaban lain membantu saya melanjutkan pekerjaan saya, untuk tujuan Stackoverflow saya rasa jawaban Sulaiman akan membantu orang lain lebih memahami apa yang terjadi. [Penafian]: Saya tidak punya waktu untuk benar-benar memverifikasi jawabannya.
StampedeXV

Jawaban:

1

<TL; DR> Masalahnya cukup sederhana, sebenarnya: Anda tidak mencocokkan pengkodean yang dinyatakan (dalam deklarasi XML) dengan tipe data dari parameter input. Jika Anda menambahkan <?xml version="1.0" encoding="utf-8"?><test/>ke string secara manual , maka mendeklarasikan SqlParametermenjadi tipe SqlDbType.Xmlatau SqlDbType.NVarCharakan memberi Anda kesalahan "tidak dapat mengalihkan pengkodean". Kemudian, saat memasukkan secara manual melalui T-SQL, karena Anda mengganti encoding yang dideklarasikan menjadi utf-16, Anda dengan jelas memasukkan VARCHARstring (tidak diawali dengan huruf besar "N", karenanya encoding 8-bit, seperti UTF-8) dan bukan sebuah NVARCHARstring (diawali dengan huruf besar "N", karenanya pengkodean UTF-16 LE 16-bit).

Perbaikannya seharusnya sesederhana:

  1. Dalam kasus pertama, saat menambahkan deklarasi yang menyatakan encoding="utf-8": jangan tambahkan deklarasi XML.
  2. Dalam kasus kedua, saat menambahkan deklarasi yang menyatakan encoding="utf-16": baik
    1. cukup jangan menambahkan deklarasi XML, ATAU
    2. cukup tambahkan "N" ke jenis parameter masukan: SqlDbType.NVarCharalih-alih SqlDbType.VarChar:-) (atau bahkan mungkin beralih menggunakan SqlDbType.Xml)

(Tanggapan rinci ada di bawah)


Semua jawaban di sini terlalu rumit dan tidak perlu (terlepas dari 121 dan 184 suara untuk jawaban Christian dan Jon, masing-masing). Mereka mungkin memberikan kode yang berfungsi, tetapi tidak satupun dari mereka benar-benar menjawab pertanyaan tersebut. Masalahnya adalah tidak ada yang benar-benar memahami pertanyaan tersebut, yang pada akhirnya adalah tentang cara kerja tipe data XML di SQL Server. Tidak ada yang menentang kedua orang yang jelas cerdas itu, tetapi pertanyaan ini tidak ada hubungannya dengan serialisasi ke XML. Menyimpan data XML ke SQL Server jauh lebih mudah daripada yang tersirat di sini.

Tidak masalah bagaimana XML diproduksi selama Anda mengikuti aturan cara membuat data XML di SQL Server. Saya memiliki penjelasan yang lebih menyeluruh (termasuk kode contoh yang berfungsi untuk mengilustrasikan poin yang diuraikan di bawah) dalam jawaban atas pertanyaan ini: Bagaimana mengatasi kesalahan "tidak dapat mengganti pengkodean" saat memasukkan XML ke SQL Server , tetapi dasarnya adalah:

  1. Deklarasi XML adalah opsional
  2. Jenis data XML selalu menyimpan string sebagai UCS-2 / UTF-16 LE
  3. Jika XML Anda UCS-2 / UTF-16 LE, maka Anda:
    1. meneruskan data sebagai NVARCHAR(MAX)atau XML/ SqlDbType.NVarChar(maxsize = -1) atau SqlDbType.Xml, atau jika menggunakan literal string maka harus diawali dengan huruf besar "N".
    2. jika menentukan deklarasi XML, harus "UCS-2" atau "UTF-16" (tidak ada perbedaan nyata di sini)
  4. Jika XML Anda dienkode 8-bit (mis. "UTF-8" / "iso-8859-1" / "Windows-1252"), maka Anda:
    1. perlu menentukan deklarasi XML JIKA encoding berbeda dari halaman kode yang ditentukan oleh Collation default database
    2. Anda harus memasukkan data sebagai VARCHAR(MAX)/ SqlDbType.VarChar(maxsize = -1), atau jika menggunakan string literal maka tidak boleh diawali dengan huruf besar "N".
    3. Apa pun pengkodean 8-bit yang digunakan, "pengkodean" yang dicatat dalam deklarasi XML harus cocok dengan pengkodean byte sebenarnya.
    4. Pengkodean 8-bit akan diubah menjadi UTF-16 LE dengan tipe data XML

Dengan memperhatikan poin-poin yang diuraikan di atas, dan mengingat bahwa string dalam .NET selalu UTF-16 LE / UCS-2 LE (tidak ada perbedaan di antara keduanya dalam hal encoding), kami dapat menjawab pertanyaan Anda:

Apakah ada alasan mengapa saya tidak boleh menggunakan StringWriter untuk membuat serial Objek ketika saya membutuhkannya sebagai string sesudahnya?

Tidak, StringWriterkode Anda tampaknya baik-baik saja (setidaknya saya tidak melihat masalah dalam pengujian terbatas saya menggunakan blok kode ke-2 dari pertanyaan).

Tidakkah pengaturan encoding ke UTF-16 (dalam tag xml) akan berfungsi?

Tidak perlu memberikan deklarasi XML. Jika tidak ada, pengkodean dianggap UTF-16 LE jika Anda meneruskan string ke SQL Server sebagai NVARCHAR(yaitu SqlDbType.NVarChar) atau XML(yaitu SqlDbType.Xml). Pengkodean diasumsikan sebagai Halaman Kode 8-bit default jika dikirimkan sebagai VARCHAR(yaitu SqlDbType.VarChar). Jika Anda memiliki karakter non-standar-ASCII (yaitu nilai 128 ke atas) dan mengirimkan sebagai VARCHAR, maka Anda mungkin akan melihat "?" untuk karakter BMP dan "??" untuk Karakter Tambahan karena SQL Server akan mengubah string UTF-16 dari .NET menjadi string 8-bit dari Halaman Kode Database saat ini sebelum mengubahnya kembali menjadi UTF-16 / UCS-2. Tetapi Anda seharusnya tidak mendapatkan kesalahan apa pun.

Di sisi lain, jika Anda menentukan deklarasi XML, maka Anda harus meneruskan ke SQL Server menggunakan tipe data 8-bit atau 16-bit yang cocok. Jadi, jika Anda memiliki deklarasi yang menyatakan bahwa encodingnya adalah UCS-2 atau UTF-16, Anda harus meneruskan sebagai SqlDbType.NVarCharatau SqlDbType.Xml. Atau, jika Anda memiliki sebuah deklarasi yang menyatakan bahwa pengkodean adalah salah satu pilihan 8-bit (yaitu UTF-8, Windows-1252, iso-8859-1, dll), maka Anda harus lulus dalam sebagai SqlDbType.VarChar. Kegagalan untuk mencocokkan pengkodean yang dinyatakan dengan tipe data SQL Server 8 atau 16-bit yang tepat akan mengakibatkan kesalahan "tidak dapat mengalihkan pengkodean" yang Anda dapatkan.

Misalnya, menggunakan StringWriterkode serialisasi berbasis Anda , saya hanya mencetak string yang dihasilkan dari XML dan menggunakannya di SSMS. Seperti yang Anda lihat di bawah, deklarasi XML disertakan (karena StringWritertidak memiliki opsi untuk OmitXmlDeclarationsuka XmlWriter), yang tidak menimbulkan masalah selama Anda meneruskan string sebagai tipe data SQL Server yang benar:

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

Seperti yang Anda lihat, ia bahkan menangani karakter di luar ASCII standar, mengingat itu adalah BMP Code Point U + 1234, dan 😸Supplementary Character Code Point U + 1F638. Namun, berikut ini:

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

menghasilkan kesalahan berikut:

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

Ergo, selain semua penjelasan itu, solusi lengkap untuk pertanyaan awal Anda adalah:

Anda dengan jelas memasukkan string sebagai SqlDbType.VarChar. Beralih ke SqlDbType.NVarChardan ini akan berfungsi tanpa perlu melalui langkah tambahan untuk menghapus deklarasi XML. Ini lebih disukai daripada menyimpan SqlDbType.VarChardan menghapus deklarasi XML karena solusi ini akan mencegah kehilangan data ketika XML menyertakan karakter non-standar-ASCII. Sebagai contoh:

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

Seperti yang Anda lihat, tidak ada kesalahan kali ini, tetapi sekarang ada kehilangan data 🙀.

Solomon Rutzky
sumber
Saya pikir saya adalah alasan untuk jawaban yang terlalu rumit ini, karena pada dasarnya saya memiliki dua pertanyaan dalam satu. Saya sangat menyukai jawaban singkat Anda dan akan mencobanya saat saya harus menyimpan XML di DB. Jadi jika saya melihat ini dengan benar: Anda menjelaskan tantangan dengan menyimpan XML ke DB. Jon Skeet meringkas masalah dengan menggunakan StringWriter saat bekerja dengan XML (kecuali untuk UTF-16) dan Christian Hayter menyediakan cara yang bagus untuk bekerja dengannya.
StampedeXV
@StampedeXV Saya memperbarui jawaban saya (beberapa perubahan untuk kejelasan + hal-hal baru untuk menggambarkan poin dengan lebih baik). Mudah-mudahan sekarang lebih jelas bahwa meskipun kedua jawaban itu bagus sendiri, mereka tidak diperlukan dengan cara apa pun untuk menjawab pertanyaan Anda. Mereka berurusan dengan serialisasi XML di C # / .NET, tetapi pertanyaan ini sebenarnya tentang menyimpan XML di SQL Server. Mereka memberikan info yang baik untuk diketahui, dan mungkin kode yang lebih baik daripada yang Anda berikan semula, tetapi tidak satu pun dari mereka (atau yang lainnya di sini), benar-benar sesuai topik. Tapi ini bukan barang yang terdokumentasi dengan baik, karenanya membingungkan.
Solomon Rutzky
@StampedeXV Apakah revisi saya masuk akal? Saya baru saja menambahkan bagian ringkasan ke atas yang mungkin lebih jelas. Singkat cerita: kecuali ada hal lain yang terjadi yang tidak Anda sertakan detailnya dalam pertanyaan, maka sepertinya kode Anda 99% benar, dan mungkin bisa diperbaiki dengan penambahan satu huruf besar " N ". Tidak ada hal pengkodean khusus yang diperlukan, dan kode Christian bagus, tetapi pengujian saya menunjukkan bahwa ia mengembalikan serialisasi yang identik dengan blok kode ke-2 Anda, kecuali milik Anda meletakkan CRLF setelah deklarasi XML. Saya yakin Anda berubah menjadi SqlDbType.NVarCharatau Xml.
Solomon Rutzky
masih berusaha mencari waktu untuk memeriksanya sendiri. Ini memang terdengar bagus dan logis, tetapi tidak yakin itu akan cukup untuk mengubah jawaban yang diterima.
StampedeXV
216

Satu masalah dengan StringWriteradalah bahwa secara default itu tidak memungkinkan Anda mengatur pengkodean yang diiklankan - sehingga Anda dapat berakhir dengan dokumen XML yang mengiklankan pengkodeannya sebagai UTF-16, yang berarti Anda perlu menyandikannya sebagai UTF-16 jika Anda tulis ke file. Saya memiliki kelas kecil untuk membantu dengan itu:

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

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

Atau jika Anda hanya membutuhkan UTF-8 (yang sering saya butuhkan):

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

Adapun mengapa Anda tidak dapat menyimpan XML Anda ke database - Anda harus memberi kami detail lebih lanjut tentang apa yang terjadi ketika Anda mencoba, jika Anda ingin kami dapat mendiagnosis / memperbaikinya.

Jon Skeet
sumber
Saya membahas lebih detail untuk masalah database sekarang. Lihat pertanyaan.
StampedeXV
4
Sedihnya StringWritertidak memperhitungkan pengkodean, tetapi tidak pernah kurang, terima kasih untuk metode kecil yang bagus :)
Chau
2
Dan "penguraian XML: baris 1, karakter 38, tidak dapat mengganti pengkodean" dapat diselesaikan dengan "settings.Indent = false; settings.OmitXmlDeclaration = false;"
MGE
Saya biasanya menyiasati ini hanya dengan menggunakan a MemoryStreamdan a StreamWriterdengan pengkodean yang benar. StreamWriter adalah sebuah TextWriter(jenis yang XmlWriter.Createmengharapkan) dengan encoding disesuaikan, setelah semua.
Nyerguds
2
@Nyerguds: Jadi buatlah paket Nuget dengan hal semacam ini, agar selalu mudah untuk mendapatkannya. Saya lebih suka melakukan itu daripada mengkompromikan keterbacaan kode yang pada dasarnya tentang beberapa persyaratan lainnya.
Jon Skeet
126

Saat menserialisasikan dokumen XML ke string .NET, pengkodean harus disetel ke UTF-16. String disimpan sebagai UTF-16 secara internal, jadi ini adalah satu-satunya pengkodean yang masuk akal. Jika Anda ingin menyimpan data dalam pengkodean yang berbeda, Anda menggunakan array byte sebagai gantinya.

SQL Server bekerja dengan prinsip serupa; string apa pun yang dilewatkan ke dalam xmlkolom harus dikodekan sebagai UTF-16. SQL Server akan menolak string apa pun jika deklarasi XML tidak menentukan UTF-16. Jika deklarasi XML tidak ada, standar XML mengharuskannya default ke UTF-8, jadi SQL Server juga akan menolaknya.

Mengingat hal ini, berikut adalah beberapa metode utilitas untuk melakukan konversi.

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);
        }
    }
}
Christian Hayter
sumber
Lihat penambahan pertanyaan. Saya tidak mengerti hasil tes saya, tampaknya bertentangan dengan pernyataan Anda bahwa DB selalu menginginkan / mengambil / membutuhkan UTF-16.
StampedeXV
9
Anda tidak perlu melakukan encode sebagai UTF-16 - tetapi Anda harus memastikan bahwa encoding yang Anda gunakan cocok dengan yang StringWriterdiharapkan. Lihat jawaban saya. Format penyimpanan internal tidak relevan di sini.
Jon Skeet
ok, saya mengerti. Dalam contoh baru saya: meninggalkan encoding sepenuhnya membuat DB memutuskan sendiri pengkodean mana yang digunakan - itulah mengapa itu berhasil. Apakah saya memahaminya sekarang?
StampedeXV
1
@SteveC: Maaf, kesalahan saya. Saya mengonversi kode dari VB, yang Nothingsecara implisit dapat dikonversi ke jenis apa pun. Saya telah mengoreksi Deserializekodenya. The Serializeperingatan harus Resharper-satunya, compiler sendiri tidak keberatan dan itu legal untuk dilakukan.
Christian Hayter
1
Memperluas komentar Jon Skeet, tidak, UTF-16 tidak diperlukan. Silakan merujuk ke stackoverflow.com/a/8998183/751158 untuk contoh nyata yang mendemonstrasikan hal ini.
ziesemer
20

Pertama-tama, berhati-hatilah dalam menemukan contoh lama. Anda telah menemukan salah satu yang menggunakan XmlTextWriter, yang dihentikan sejak .NET 2.0. XmlWriter.Createharus digunakan sebagai gantinya.

Berikut adalah contoh serialisasi objek ke dalam kolom 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();
                }
            }
        }
    }
}
John Saunders
sumber
2
Saya hanya dapat memilih ini sekali, tetapi ini pantas menjadi jawaban teratas di sini. Pada akhirnya, tidak masalah pengkodean apa yang dideklarasikan atau digunakan, selama XmlReaderdapat menguraikannya. Ini akan dikirim pra-parsing ke database, dan kemudian DB tidak perlu tahu apa-apa tentang pengkodean karakter - UTF-16 atau sebaliknya. Secara khusus, perhatikan bahwa deklarasi XML bahkan tidak disimpan dengan data dalam database, terlepas dari metode mana yang digunakan untuk menyisipkannya. Harap jangan sia-siakan dengan menjalankan XML melalui konversi tambahan, seperti yang ditunjukkan dalam jawaban lain di sini dan di tempat lain.
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;
}
Mashudu Nemukuka
sumber
-1

Ini mungkin telah dibahas di tempat lain tetapi hanya dengan mengubah baris pengkodean sumber XML ke 'utf-16' memungkinkan XML untuk dimasukkan ke dalam jenis xml'data 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();
    }
}

Hasilnya adalah semua teks XML dimasukkan ke dalam bidang tipe data 'xml' tetapi baris 'tajuk' dihapus. Apa yang Anda lihat dalam rekaman yang dihasilkan adalah adil

<test></test>

Menggunakan metode serialisasi yang dijelaskan dalam entri "Dijawab" adalah cara untuk memasukkan header asli ke dalam bidang target, tetapi hasilnya adalah teks XML yang tersisa diapit dalam <string></string>tag XML .

Adaptor tabel dalam kode adalah kelas yang secara otomatis dibangun menggunakan "Add New Data Source: wizard" Visual Studio 2013 Lima parameter untuk metode sisipkan peta ke bidang dalam tabel SQL Server.

DLG
sumber
2
Menggantikan? Ini sangat lucu.
mgilberties
2
Serius - jangan lakukan ini. Pernah. Bagaimana jika saya ingin memasukkan beberapa prosa dalam xml saya yang menyebutkan "UTF-8" - Anda baru saja mengubah data saya menjadi sesuatu yang tidak saya katakan!
Tim Abell
2
Terima kasih telah menunjukkan kesalahan dalam kode. Selain bodyXML.Replace ("UTF-8", "UTF-16"), harus ada kode yang berfokus pada header XML yang mengubah UTF-8 menjadi UTF-16. Apa yang sebenarnya ingin saya tunjukkan adalah dengan membuat perubahan ini di header dari sumber XML, lalu badan XML kemudian dapat dimasukkan ke dalam catatan tabel SQL menggunakan bidang tipe data XML dan headernya dilucuti. Untuk alasan yang saya tidak ingat sekarang (empat tahun yang lalu!) Hasilnya adalah sesuatu yang berguna pada saat itu. Dan ya, kesalahan bodoh menggunakan 'Ganti'. Itu terjadi.
DLG