將 .properties 檔案轉換為 JSON 以便 C# 屬性綁定

若要將 Java .properties 的值放入 C# 類別屬性中，請將該檔案轉換為遵循 java.util.Properties.load(Reader) 剖析規則的 JSON，然後使用 System.Text.Json 或 Newtonsoft.Json 將該 JSON 反序列化為你的 C# 模型。第一個步驟是大多數 C# 開發者最容易出錯的地方，因為 .properties 並非「一行一個鍵」的格式：它允許註解、空行、以反斜線進行的邏輯行接續、三種分隔符號樣式，以及包含 \uXXXX Unicode 編碼的跳脫序列。在換行上做簡易切割或使用快速正則表達式，會產生與原 Java 應用程式讀取結果不一致的 JSON；而 C# 字串屬性中出現錯誤字元，可能會破壞下游的查詢、本地化查詢或連線字串。將轉換視為一個嚴謹的兩階段管線——先進行 properties 剖析，再進行 C# 繫結——可讓兩個階段各自獨立驗證。你可以將 JSON 與來源檔的唯一鍵數量進行 diff 比對，然後在出貨前，依據消費端應用程式的合約驗證最終的 C# 模型。

convert json to properties c# — 將 .properties 檔轉換為 JSON 以供 C# 屬性繫結

為什麼 C# 開發者會從 .properties 檔開始

C# 與 .NET 應用程式經常會從原本以 Java 撰寫的系統接收設定。本地化資源套件是常見的情況：譯者會交給你一份 messages_en.properties、messages_fr.properties 或 messages_ja.properties 檔，而你技術棧的其他部分已經預期接收 JSON 格式，以用於 ASP.NET Core 的 IConfiguration 繫結、Azure Functions 輸入繫結，或強型別的 options 類別。舊系統整合情境也是一種情況：合作夥伴公開的 Java 服務仍以 .properties 文字格式輸出其連線細節，而 C# 端需要加以消費。建置管線的輸出則是第三種情況：Android 或 Spring Boot 建置步驟會產生 .properties 構件，供下游的 .NET 工具讀取。在上述每一種情況中，C# 應用程式並不想重新實作 Java 的跳脫規則；它想要的是乾淨、可交給 JsonSerializer.Deserialize<T> 並直接讀入自身字串屬性的 JSON。

.properties 剖析如何轉變為 C# 可繫結的 JSON

Properties to JSON Converter 直接在瀏覽器中模擬以字元為基礎的 java.util.Properties.load(Reader) 方法。它不會上傳你的文字、不會聯繫 Java 程序，也不會試圖在 Unicode 文字之上額外推算出 load(InputStream) 的 ISO-8859-1 位元組解碼。瀏覽器已經提供 Unicode 字碼點，所以你貼上的內容就是實際被剖析的內容。轉換過程會透過串接所有「前一連反斜線長度為奇數」的實體行來組成邏輯行、略過第一個非空白字元為 # 或 ! 的行、忽略空行，再以第一個未加權義的分隔符號設定——等號、分隔符號冒號或項目符號設定空白——將每個邏輯行拆分為鍵與值。接著每個值會被 JSON 序列化為字串，且中介紀錄使用 null 原型，使得 __proto__、constructor 與 toString 等鍵保持為普通的自有資料，而非繼承而來的原型成員。

其結果是一個格式化的 JSON 物件，你可以將其唯一鍵數量與來源檔進行比對。若 .properties 檔以不同值宣告 app.name 三次，則 JSON 中只會保留最後一次的值，這符合 Java 的表格取代語意。註解、原始的分隔符號設定樣式，以及精確的實體行順序並不會在 JSON 中呈現，因此這並非可逆的格式化器。當順序或註解很重要時，請將來源檔案與 JSON 一起保留。

將 .properties 檔載入 C# 類別屬性：操作步驟

在文字編輯器中開啟 Java .properties 檔，複製其完整內容（CRLF、LF 或 CR 行尾皆可接受），並貼上至轉換器。請保留所有註解與接續行——不要預先清理輸入內容。
轉換並比對工具所顯示的唯一鍵數量與來源檔中相異鍵的數量。若數字不一致，最常見的原因包括：鍵中含有未加權義的等號、缺少接續行，或是 Java 執行階段同樣會將重複的鍵合併。
複製格式化後的 JSON，再透過 JSON 驗證器確認結構正確無誤，然後再使用 JsonSerializer.Deserialize<AppConfig>(json) 或 JsonConvert.DeserializeObject<AppConfig>(json) 將其反序列化至你的 C# 類別。C# 類別上的每個屬性都將收到一個 JSON 字串——絕非布林值、數字或 null——除非你的程式碼稍後自行轉換。
依據消費端應用程式的合約驗證型別與必要鍵。將 "true" 轉為 bool、"123" 轉為 int，或將 "2026-07-20" 轉為 DateOnly，僅能在 JSON 抵達 C# 之後，並僅依據你所掌控的可信賴設定架構來進行。

與此管線搭配的最小 C# 模型看起來就像一個普通類別，其裝飾的屬性名稱會與鍵名對應，例如 public string AppName { get; set; } 繫結至 app.name；若鍵是開放式的，則可使用 Dictionary<string, string>。解序列化器會將 JSON 字串直接讀入這些屬性；型別轉換發生在你的程式碼中，而非在轉換器中。

會改變 C# 字串屬性內容的跳脫規則

Java 的跳脫處理雖然少數但很精確，它正是來源 .properties 檔與最終持有該值的 C# 字串屬性之間最常見細微不一致的來源。下表列出轉換器所能辨識的跳脫序列，以及每個序列所產生的字元。

Java 跳脫序列	解碼後的字元	在 C# 字串屬性中的實際效果
\t	Tab (U+0009)	觸發可感知 Tab 的 UI 呈現，或在 CSV 樣式的值中以 \t 進行切分。
\n	換行字元 (U+000A)	在多行 C# 字串中作為實際的真換行符號留存。
\r	歸位符號 (U+000D)	顯示為 CR，通常與 \n 配對形成 CRLF。
\f	換頁字元 (U+000C)	保留為換頁字元；繫結前請勿將其去除。
\\	反斜線 (U+005C)	在 Windows 路徑（例如 C:\\app\\bin）中需要使用。
\uXXXX	恰好由 4 個十六進位數字組成的 Unicode 字碼點	解碼為字面字元；\u0041 變為 A，\u00e9 變為 é。
\ 加在任意其他字元前	反斜線之後的字元，並將反斜線移除	符合 Java 的文件化行為；不會自行推造八進位或倒退字元跳脫。

單一邏輯行的操作範例：

輸入（Java 跳脫形式）：greeting=Hello\u0020World

解碼後：greeting=Hello World（\u0020 恰好是 4 個十六進位數字，代表 U+0020，亦即空白字元）。

JSON 輸出：{ "greeting": "Hello World" }

C# 屬性：反序列化後，public string Greeting { get; set; } 現在持有 "Hello World"。

格式錯誤的 Unicode 跳脫序列（例如 \u012，十六進位數字少於四個）會使轉換器回傳錯誤，而不會被複製為看似合理的資料。此防護機制至關重要，因為若將 \u012 原樣複製到 C# 屬性，稍後經 JsonSerializer 來回處理時，仍會是字面文字 \u012，而非 Unicode 字碼點，下游消費者將與原始 Java 讀取器的結果不一致。如需對這些規則本身有更深入的瞭解，Properties to JSON 跳脫規則與重複鍵處理指南會以具體測試案例逐一說明相同的邊界情況。

為何每個值都保持為 JSON 字串

轉換器刻意拒絕將 true 轉為 JSON 布林值、將 123 轉為 JSON 數字、將 null 轉為 JSON null，或將 2026-07-20 轉為任何日期格式。Java Properties 是字串對字串的模型：來源可能持有的每個值皆為文字，而解讀的責任在於消費者。若 C# 屬性宣告為 int，則無論 JSON 包含 "42" 或 42，皆能正確往返；但若屬性宣告為 string，且持有諸如 001 或 1.5 的值，一旦轉換器認定其為數字，將會靜默地失去前導零或小數精度。相同的邏輯亦適用於 order.001 等外形類似識別字的鍵：將其保留為字串可避免意外重新排序、意外補零，以及意外的數值強制轉換。

實務應將：將轉換器維持為純字串的橋接器，並依據可信賴的架構於 C# 中進行型別轉換。當你確實需要數值、布林值或日期屬性時，請在 C# 類別上明確宣告，並交由 JsonSerializer 執行轉換。當需要保留精確拼字時，請將 C# 屬性維持為 string，稍後自行解析。

限制、重複鍵，以及最終驗證流程

轉換器接受最多 500,000 個輸入字元、最多 20,000 個邏輯項目，並產生最多 2,000,000 個輸出字元。邊界失敗不會回傳部分 JSON，因此成功的回應永遠反映完整的輸入。隨工具附贈的八個外部測試案例涵蓋三種分隔符號形式、跳脫空格、換行與 Unicode 跳脫、接續行，以及重複替換；額外的測試涵蓋註解、空值、原型形狀的鍵，以及格式錯誤的 Unicode。這些測試皆未假設 ISO-8859-1 位元組解碼、預設值鏈、XML 屬性、環境變數插值、Spring 設定檔、變數展開，或加密秘密 — 這些都屬於 Java 執行階段，而非瀏覽器端的轉換器。

.properties 行為	JSON 輸出	原因
以 # 或 ! 開頭的註解行	省略	JSON 沒有註解語法；解析器會移除該行。
空白行	省略	空白行不是項目。
key = value、key: value、key value	{ "key": "value" }	三種分隔符號樣式會統一為相同的 JSON 輸出。
行尾在換行前有奇數個反斜線	與下一行合併	依 Java 規格進行邏輯行接續。
重複宣告的鍵	以最後一個值為準	符合 Java 的表格替換語意。
沒有分隔符號的鍵	{ "key": "" }	空值仍是有效的項目。

在正式環境中替換任何設定之前，請將產生的 JSON 中唯一鍵的數量與 Java 應用程式在同一檔案上的行為進行比對、將 JSON 跑過驗證器以捕捉人工編輯造成的尾端逗號或引號錯誤，並確認取用端的 C# 所需的所有鍵皆已存在。切勿將正式環境的秘密貼入不受信任的目的地，也切勿隨意分享複製的輸出：轉換在本機執行，因此資料不會離開您的瀏覽器，但下游的複製會繼承目的地所授予的存取權。完成這些檢查後，這條管線 — Java .properties 轉 JSON、JSON 轉 C# 類別屬性 — 便為 .NET 開發人員提供一條可驗證的路徑，從舊有格式通往強型別設定，而無需在 C# 內重新實作 Java 的跳脫規則。

延伸閱讀：Cookie 轉換器入門：將 Cookie 轉換為 JSON。