Properties to JSON 轉換器會解析 Java load(Reader) 風格的 .properties 文字，並產生一個 JSON 物件，其鍵與原始屬性名稱完全相符。它遵循 Java 的 java.util.Properties 類別中所記錄的、以字元為基礎的 Reader 模型，處理行接續、跳脫序列、註解略過以及重複鍵的取代規則，與 Java 執行環境所套用的規則相同。鍵會逐字保留，因此像 dbUrl、maxRetries 或 userName 這類識別符在 JSON 中的呈現會與來源檔案完全一致，而且每個值都會被序列化為 JSON 字串。這使得該轉換器在將設定從 Java 屬性檔搬移到 JavaScript、Node.js 或其他會使用 JSON 的應用程式的工作流程中，成為一個可靠的步驟。轉換作業完全在本機瀏覽器中執行，無需上傳，也不會與伺服器往返，並且工具會強制執行文件所記載的限制：輸入字元數上限 500,000、邏輯項目數上限 20,000、輸出字元數上限 2,000,000；當超出任一上限時，會直接回傳結果而不會輸出部分 JSON，也絕不截斷結果。
解析器如何讀取 .properties 檔案
這個 Properties to JSON 轉換器 是以 java.util.Properties.load(Reader) 為模型，亦即 Java 屬性載入器的字元導向變體。自然行（natural line）可以以 CRLF、LF、CR 或輸入結尾作為結束，空行會被忽略。如果某行的第一個非空白字元是 # 或 !，則會在開始擷取鍵值之前將其視為註解並丟棄。
在行尾之前出現奇數個反斜線時，會接續邏輯行：接續標記、行尾符號，以及下一個自然行開頭的所有空白字元（空格、定位字元或換頁字元）都會消失，將兩個實體行合併成單一邏輯項目。若為偶數個反斜線則不會接續，因為這些反斜線會互相跳脫，且行尾符號會保留為值中的字元。
略過行首空白之後，鍵會在第一個未跳脫的分隔符處結束：等號、冒號或 properties 的空白字元。該分隔符之後的空白會被略過，而空白分隔符之後若再有選擇性的等號或冒號也會被略過。完全沒有分隔符的一行會變成一個值為空字串的鍵。已跳脫的分隔符與已跳脫的空白字元仍屬於鍵或值的一部分，而非作為邊界，因此 key\=with\=equals=value 會將鍵儲存為 key=with=equals，值儲存為 value。
| 規則 | 行為 |
|---|---|
| 行尾 | CRLF、LF、CR 或輸入結尾 |
| 註解 | 行首空白後以 # 或 ! 開頭的行 |
| 接續 | 行尾前出現奇數個反斜線時接續邏輯行 |
| 分隔符 | 未跳脫的 =、: 或空白字元會結束鍵 |
| 空值 | 沒有分隔符的行即為值為空字串的鍵 |
| 跳脫 | 僅支援 \t \n \r \f \\ \uXXXX；其他 \X 會移除反斜線 |
| 重複鍵 | 以最後一個值為準（表格取代） |
| 原型安全性 | 使用 null 原型紀錄，避免 __proto__ 污染 |
轉換器可辨識的跳脫序列
轉換器可辨識 Java 屬性檔所記載的跳脫序列：定位字元 (\t)、換行 (\n)、歸位字元 (\r)、換頁字元 (\f)、單一反斜線 (\\)，以及一個小寫 u 後接剛好四位十六進位數字 (\uXXXX)。在其他字元之前的反斜線會直接移除，與 Java 文件所記載的行為一致，不支援八進位序列、非標準簡寫，也沒有自行發明的替代方案。
格式錯誤的 Unicode 跳脫會回傳錯誤，而不是被當作看似合理的資料複製過去。如果您的屬性檔中含有 \u00ZZ 或 \u123（位數錯誤），轉換器會停止並回報問題，而不會產生下游消費者難以除錯、靜默損壞的 JSON。這與 Java 參考實作的 fail-fast 立場相同，能避免格式錯誤的跳脫在 JSON 輸出中看起來像是已成功解碼的字元。
這點很重要，因為屬性值經常含有需要跳脫的字元：含有冒號的 URL、含有反斜線的檔案路徑、含有特殊字元的密碼，或內嵌換行的設定字串。轉換器會在 JSON 字串值中保留原本預期的字元，因此 homeDir=C:\\Users\\Admin 會正確地在輸出中變成 "homeDir": "C:\\Users\\Admin"，而 greeting=Hello\u0020World 則會解碼為 "greeting": "Hello World"。
從屬性文字到 JSON：三分鐘工作流程
轉換工作流程包含三個具體步驟：
- 將字元導向的 Java 屬性文字貼到轉換器中，包含註解與接續行（如有）。轉換器會接受您編輯器所產生的任何行尾格式，並略過空行而不會特別標記。
- 轉換並比對來源檔案中的唯一鍵數量與跳脫後的值。轉換器會合併接續行並略過註解，因此輸出中的唯一鍵數量應與屬性檔在合併邏輯行之後的不同識別符數量相符。
- 複製 JSON，然後依據消費端應用程式的合約驗證型別與必要鍵。請記住，所有值都是 JSON 字串；轉換器不會推測布林、數字或 null 型別。請稍後依據您權威性的設定結構描述（schema）進行型別轉換。
舉例來說，請參考以下屬性片段：
# Database configurationdbUrl=jdbc:postgresql://localhost:5432/mydbmaxRetries=3userName=admingreeting=Hello\u0020World
轉換後，JSON 輸出會剛好包含四個鍵，全部依照來源檔案的寫法原樣保留，其中 Unicode 跳脫會在 greeting 值中解碼為空白字元。註解行會被捨棄，而所有值都是 JSON 字串，包括 maxRetries 也會是 "3"。如果您的專案改用 kebab-case 或 snake_case 識別符，同樣的保留規則依然適用，輸出 JSON 的鍵會與來源屬性名稱完全一致。
重複鍵與 Null 原型紀錄
當同一個鍵在屬性檔中出現多次時，轉換器會保留最後一個值，與 Java Properties 的表格取代行為一致。如果您的檔案同時含有 dbUrl=old-host 與 dbUrl=new-host，JSON 輸出將會包含鍵 dbUrl，值為 new-host。這個取代發生在邏輯行建構的過程中，因此分散在不同接續行中的重複鍵，其處理方式與位於不同實體行的重複鍵相同：以最後一個邏輯出現者為準。
中介紀錄會使用 null 原型，因此像 __proto__、constructor 與 toString 這類鍵在 JSON 序列化之前都仍是普通的自有資料屬性。這能避免在下游 JavaScript 消費者端發生 prototype 污染——當 JSON 輸出會被 JSON.parse 解析並用於 Node.js 或瀏覽器程式碼中的設定物件時，這是一個真實存在的風險。若沒有 null 原型的中介物件，來源屬性檔中惡意命名的鍵在解析後，有可能會遮蔽內建物件的方法。
轉換器不做哪些事
Properties to JSON 轉換器的範圍刻意限定在字元導向的 Reader 模型。它不會模擬 load(InputStream) 的 ISO-8859-1 位元組解碼；瀏覽器會直接提供 Unicode 字元，因此任何位元組層級的解碼都必須在貼上文字之前完成。它同樣不實作預設值鏈（defaults chains）、XML 屬性、環境變數插值、Spring profiles、變數展開、加密機密，或框架特定的設定規則。
自動型別推論是刻意不存在的。像 true、false、null、123、1.5 或 2026-07-20 這類值，在輸出中仍會是 JSON 字串。Java Properties 是字串鍵值模型，猜測純量型別可能會破壞識別符、格式以及應用程式特定的語意。一個名為 port、值為 8080 的屬性應該保持為字串，直到您的應用程式結構描述另有規定；而一個名為 enabled、值為 true 的屬性也應維持字串，直到您的結構描述指出它應為布林值。
註解與原本的分隔符樣式並不會反映在 JSON 輸出中。此轉換並非可逆的格式化工具；它會產生最終的鍵值表，而不是帶有格式化歷史紀錄的屬性檔。如果您在意順序、註解或精確的分隔符拼寫，請保留來源 .properties 檔。轉換器同樣不會評估佔位符、不會聯繫 Java 程序，也不會自行為字元導向 Reader 沒有的行為增添功能。
依據您的應用程式驗證輸出
複製 JSON 之後，請依據消費端應用程式的合約進行驗證。檢查所有必要鍵是否齊全、型別在您自行轉換之後是否相符，以及值是否與來源屬性一致。轉換器的輸出是確定性的：給定相同輸入，永遠會產生相同的 JSON，因此您可以在不同次執行或不同團隊成員之間比對結果，而無需擔心鍵的非確定性順序。
對於較大規模的遷移作業，請比對唯一鍵數量以及轉換器輸出與來源檔案之間的若干跳脫值樣本。若數量相符且樣本值能正確解碼，則該轉換在結構上是正確的。Java SE 25 中 java.util.Properties 的官方文件提供了轉換器所實作之解析規則的權威參考，而關於在線上將 .properties 檔轉換為 JSON 的相關指南則涵蓋了更多基於瀏覽器的設定轉換工作流程模式。
請勿將正式環境的機密資料貼到不受信任的目的地，也不要隨意分享複製出來的輸出。轉換器在本機執行，但剪貼簿以及您之後貼上的任何下游系統都不在它的控制範圍之內。請以處理原始屬性檔同等的小心程度來對待轉換後的 JSON，並從一開始就將機密資料存放在專門的密碼管理工具中，而不是放進簽入版本控制的屬性檔。