Java .properties 檔案可透過三個明確步驟轉換為 JSON 物件：貼上文字、驗證不重複鍵的數量與跳脫字元解碼，然後依據使用該 JSON 的應用程式結構描述驗證輸出。Properties to JSON Converter 支援 java.util.Properties.load(Reader) 文件所述的完整逐行格式——以字元為基礎的文字，可包含選用註解、空行、跳脫分隔符號、續行，以及重複鍵以最後一個值取代的機制。產生的 JSON 中每個值都是字串，因此像 'true'、'123' 或 '001' 之類的識別字不會在未告知的情況下被改寫成布林值、數字或 null。貼上作業在你的瀏覽器中進行，轉換於本機執行，且此頁面絕不會將檔案上傳至伺服器。轉換後，你會將不重複鍵的數量與解碼後的跳脫字元和原始 .properties 檔案比較，然後依據將讀取該 JSON 的應用程式驗證必要鍵與值類型。本文會逐步說明整個流程，以及在貼上正式環境設定前應知道的限制。內容內建對格式錯誤 Unicode 跳脫字元的容錯處理：若單獨出現 \u，後面卻未接四個十六進位數字，就會傳回錯誤，而不會複製看似合理的文字。

convert properties file to json
Properties 檔案轉 JSON：經過驗證的三步驟路徑

轉換器會從你的 Properties 檔案讀取哪些內容

Java 的 java.util.Properties 類別會使用 Reader 從文字檔載入設定。根據 Java SE 25 java.util.Properties 參考文件，load(Reader) 方法會解析逐行文字，其中每個自然行可能是鍵／值配對、空行或註解。行尾可以是 CR、LF、CRLF，或單純是輸入結尾，因此這種格式能彈性容納在不同作業系統上編輯的檔案。

轉換器遵循相同的契約。第一個非空白字元為 # 或 ! 的行會視為註解並捨棄。空白行會被忽略。鍵的部分從行首延伸至第一個未跳脫的等號、冒號或文件中列明的其中一種空白分隔符號。該分界之後的所有內容都是值，並會移除選用的前導空白。沒有分隔符號的行會成為值是空字串的鍵。

轉換器接受三種分隔符號形式，與 Java 文件所述的行為一致：未跳脫的等號 (=)、未跳脫的冒號 (:)，或 properties 空白字元。轉換器也接受在空白後使用其中一種字元來分隔鍵與值，並忽略結尾的分隔符號。由於每個分界字元都可以用反斜線跳脫，因此像 key=with=equals 這樣的值或含空格的鍵都能完整保留。

如何將 Properties 檔案轉換為 JSON

實際轉換需要三個具體步驟。介面是 Properties to JSON Converter 頁面上的單一貼上區域，而此工具不接受上傳檔案。請依照以下步驟操作：

  1. 將 .properties 檔案的完整內容貼到轉換器的輸入區域，包括你希望解析器辨識的所有註解與續行。
  2. 轉換文字並檢查結果所顯示的不重複鍵數量，然後閱讀格式化後的 JSON 輸出，確認已解碼的跳脫序列與來源相符。
  3. 複製 JSON，然後在取代設定前，依據使用該 JSON 的應用程式結構描述驗證必要鍵與預期的純量類型。

之所以需要這套流程，是因為轉換無法還原：註解會被移除，原本的分隔符號樣式會遺失，而鍵的順序遵循最後一個鍵勝出的原則，而非來源順序。當上述任一屬性很重要時，請將來源檔案視為權威成品。

跳脫序列、續行與重複鍵

轉換器所實作的跳脫規則與 Java SE 25 java.util.Properties 規格文件中記載的規則相同。可辨識的序列包括 \t（定位點）、\n（換行）、\r（歸位）、\f（換頁）、\\（單一反斜線），以及小寫 u 後接恰好四個十六進位數字。其他任何字元前的反斜線會連同反斜線本身一起被移除，這是 Java 讓非特殊字元前的 \ 不致造成影響的方式。

續行會依奇數反斜線規則合併。若某行在行尾前以奇數個反斜線結尾，就會接續下一行：反斜線、行尾與下一自然行的所有前導空白都會被移除。反斜線數量為偶數時不會產生續行，因為這些反斜線會兩兩互相跳脫。此行為與 load(Reader) 完全一致，也是將長值拆分至多行的唯一安全方式。

重複鍵會使用最後一個值，與 java.util.Hashtable 取代鍵的方式相同。若同一個鍵以 v1、v2 和 v3 這些值重複出現三次，JSON 只會包含第三次指派。內部記錄建立時不會繼承原型，因此 __proto__、constructor 和 toString 等鍵在 JSON 序列化前仍是普通的自有資料——不會意外觸發原型行為。

格式錯誤的 Unicode 跳脫字元——例如 \uZZZZ，或只有三個十六進位數字的 \u——會傳回錯誤，而不會被當成看似合理的資料複製。這能防止下游使用者無聲地收到格式錯誤的字元。

為何每個 JSON 值都維持字串

Java Properties 是字串鍵值模型。此格式不會區分字串 "true" 與布林值、"123" 與整數，也不會區分 "001" 與相同但沒有前導零的整數。轉換器輸出 JSON 時，每個值都會加上引號，藉此保留識別字與應用程式專屬的意義。

當你的 consuming code 預期設定值是 "true" 或 "001" 等字串時，這點格外重要。 naïve 轉換器若猜測類型，可能會將 "001" 改寫成數字 1，無聲地移除前導零，並破壞依賴原始字串的下游邏輯。true、false、null、123、1.5 等寫法，以及 2026-07-20 這類日期形式的值，絕不會自動轉換；它們會維持為一般 JSON 字串。

若下游應用程式需要具類型的 JSON——例如具類型的設定結構描述——請稍後使用採用明確結構描述的工具進行轉換。Properties to JSON Converter 的契約是保留 Java Properties 已強制的字串語意。

依據應用程式契約驗證 JSON

貼上、轉換與複製完成後，部署 JSON 前所執行的驗證是最關鍵的步驟。請依下列順序進行檢查：

  • 計算 JSON 物件中的不重複鍵數量，並與來源 .properties 檔案中的相異鍵數量比較。除非重複鍵是刻意設定，否則兩個數字應相等。
  • 開啟來源中含有跳脫序列的幾個值——例如 \n、\t 或 \u00E9——並確認它們在 JSON 輸出中已解碼成預期字元。
  • 確認續行已合併成單一邏輯值，且續行規則未讓任何前導空白混入。
  • 使用嚴格解析器驗證 JSON 本身，以找出任何格式錯誤的 Unicode 跳脫字元或分界失敗。分界失敗時不會傳回部分 JSON，因此空結果表示輸入超出文件所列的限制，而不是被無聲地截斷。
  • 將必要鍵與應用程式的契約比較。若結構描述需要布林值、數字或日期，請在保留字串的步驟後另外執行由結構描述驅動的轉換。

若任何檢查失敗，請修正來源 .properties 檔案並重新轉換，而不要編輯 JSON 輸出。由於轉換期間會遺失註解與順序，來源仍是唯一能逐行稽核的成品。如需更深入了解上述跳脫規則，請參閱 Properties to JSON：跳脫規則與重複鍵處理 指南。

限制、範圍外功能與安全性

轉換器在三項明確限制下運作：輸入 500,000 個字元、20,000 個邏輯項目，以及輸出 2,000,000 個字元。分界失敗時不會傳回部分 JSON，因此輸入超過任一門檻時，你會看到空結果而非遭截斷的輸出。貼上大型檔案前，請先確認檔案未超出這些限制。

限制最大值
輸入字元500,000
邏輯項目20,000
輸出字元2,000,000

轉換器也刻意省略數項記載於 Java Properties 類別及其生態系中的功能。這些功能不在範圍內：

  • load(InputStream) 的 ISO-8859-1 位元組解碼——轉換器以瀏覽器 Unicode 文字模擬 load(Reader)，因此所有位元組解碼都必須在貼上前完成。
  • 預設值鏈，由次要 Properties 檔案為缺少的鍵提供備援值。
  • XML properties 檔案 (loadFromXML)，其使用完全不同的語法。
  • 環境變數插值、Spring profile 預留位置、變數展開、加密密秘或框架專屬規則。

安全性是此契約的一部分。此頁面不會上傳你的 properties 文字、不會呼叫 Java 程序，也不會評估預留位置。話雖如此，你仍應避免將正式環境密秘貼入任何以瀏覽器為基礎的工具。請將貼上的內容視為可能已離開分頁：將密秘保存在密秘管理工具中，並為正式環境設定使用專屬的管線。

相關閱讀：如何使用 JSON 的查詢字串解析器。