DataContractJsonSerializer 與 JavaScriptSerializer 序列化差異深度解析

問題場景

定義一個標記 [Serializable] 的類別，其中一個屬性使用傳統 get/set 配合私有欄位實作（非自動屬性）：

[Serializable]
public class Users {
    public int UserID { get; set; }
    public string UserName { get; set; }
    public string UserEmail { get; set; }
    private string _testProperty;
    public string TestProperty {
        get { return _testProperty; }
        set { _testProperty = value; }
    }
}

序列化結果對比

DataContractJsonSerializer 輸出了編譯器生成的後端欄位名稱（k__BackingField），而 JavaScriptSerializer 則正確輸出屬性名稱。

根本原因分析

DataContractJsonSerializer (.NET 3.5 引入)

• 隨 WCF 引入，嚴格遵循資料合約模型。
• 內部透過 InternalWriteObjectContent 進行嚴格型別檢查，直接序列化物件的所有欄位（包含編譯器為自動屬性生成的 <PropertyName>k__BackingField 私有欄位）。
• 不認得「屬性」概念，只看運行時欄位結構。

JavaScriptSerializer (.NET 3.5 SP1 移除過時標記)

• 實作相對簡單：將屬性名/值存入 Dictionary，再拼接字串。
• 透過反射取得 PropertyInfo，故天然序列化「屬性」而非欄位。
• 對複雜型別支援較弱，但對一般 POCO 類別表現直觀。

解決方案

方案一：加上資料合約屬性（推薦用於 DataContractJsonSerializer）

[DataContract]
public class Users {
    [DataMember] public int UserID { get; set; }
    [DataMember] public string UserName { get; set; }
    [DataMember] public string UserEmail { get; set; }
    [DataMember] public string TestProperty { get; set; } // 改為自動屬性或保留私有欄位並標記
}

明確指定需序列化的成員，輸出乾淨 JSON。

方案二：無法修改類別定義時，改用 JavaScriptSerializer

適用於第三方庫或舊版程式碼無法加裝屬性的情境。

方案三：採用 Json.NET (Newtonsoft.Json)

• 功能最完整、效能最佳、預設行為最符合直覺（序列化屬性、支援匿名型別、LINQ to JSON 等）。
• 目前社區標準選擇，建議新專案優先採用。

總結建議

根據專案限制與需求靈活選擇，避免踩序列化陷阱。