跳至主要內容
Lizely

屬性至 JSON 轉換器

解析類似 Java load(Reader) 的屬性格式，並以連續、轉義、註解及重複取代處理，轉換為字元值的 JSON。

隱私權：你的檔案不會離開裝置，所有處理均在瀏覽器本機完成。

使用方式

  1. 1.貼上以字元為基礎的 Java 屬性文字內容，包含註解與續行（若有）。
  2. 2.轉換並與原始內容對比唯一鍵數量與轉義值。
  3. 3.複製 JSON 後，再針對消費應用的合約驗證型別與必要鍵值。

關於屬性至 JSON 轉換器

屬性至 JSON 轉換器讀取 Java java.util.Properties.load(Reader) 所定義的行向格式，並產生格式良好的 JSON 物件。貼上字元文字內容，本機轉換後檢視唯一鍵的數量，並複製精確的 JSON。此頁面不會上傳任何檔案、評估佔位符、啟動 Java 過程，或推斷標量型別。

自然行可能以 CRLF、LF、CR 或輸入結束為結尾。空白行會被忽略。若第一個非空白字元為 # 或 !，則為註解。若行首出現奇數個反斜線，則會延續邏輯行；續行的結束標記、結束符及後續自然行的首個空白、製表或換頁字元將消失；偶數個反斜線則不會延續，因為反斜線會互相轉義。

在首段空白後，鍵值在第一個未轉義的等號、冒號或屬性空白處結束。該邊界後的空白會被跳過，且後續的可選等號或冒號也會被跳過。若行中無分隔符，則視為鍵值為空。轉義的分隔符與空白仍會保留在鍵或值中。

轉義處理會識別製表、換行、歸位字元、製表、反斜線相容轉義，以及一個小寫 u 後接恰好四個十六進位數字。根據 Java 檔案說明，反斜線前的其他字元僅會移除反斜線；八進位與特殊退格轉義不會被創造。錯誤的 Unicode 轉義會導致錯誤，不會被複製為可能的資料。

所有產生的值皆為 JSON 字串。例如 true、null、001、1.5 或 2026-07-20 之類的語法不會轉為布林、null、數值或日期。Java 屬性為字串鍵值模型，自動型別推論可能改變識別碼、格式與應用專屬意義。應在權威配置方案下進一步轉換型別。

重複鍵會使用最後一個值，符合表格取代行為。中間記錄無繼承原型，因此如 __proto__、constructor 與 toString 之類的鍵仍為普通屬性資料，轉換為 JSON 時不會被遺失。註解與原始分隔符風格不會出現在 JSON 中，因此此轉換並非可逆的格式化工具。若需保留順序、註解或精確拼寫，請保留原始檔案。

此設計模擬瀏覽器端的字元讀取方法。瀏覽器已提供 Unicode 字元；它不會模擬 load(InputStream) 的 ISO-8859-1 位元組解碼。它也未實作預設鏈、XML 屬性、環境變數擴充、Spring 框架設定、變數擴充套件、加密金鑰或框架特定設定規則。請勿將生產環境金鑰貼入不可信目的地，也勿隨意分享複製的輸出內容。

限制為 500,000 輸入字元、20,000 邏輯專案與 2,000,000 輸出字元。逾越邊界將不會返回部分 JSON。八個外部測試案例涵蓋三種分隔符形式、轉義空白、換行與 Unicode 轉義、續行與重複取代。其他測試涵蓋註解、空值、原型形鍵、以及錯誤的 Unicode。結果與 Java 應用程式對比，並驗證必要鍵值後，才可取代設定。

方法與來源

建立邏輯行，以奇數反斜線續行為條件，忽略已定義的註解與空白，尋找第一個未轉義的鍵分隔符，解碼 Java 屬性轉義（含單 u 加四個十六進位數字），採用最後鍵優先原則建立無原型記錄，並將所有值序列化為 JSON 字串。

常見問題

為何會有 true 跟 123 JSON 字串？
Java 屬性以字串儲存鍵與值。自動標量推論可能改變識別碼與應用專屬意義。
此轉換會保留註解與原始順序嗎？
不會。JSON 代表最終的鍵值表，而非屬性格式的歷史紀錄。若註解、順序或分隔符重要，請保留原始檔案。
此工具會模擬 ISO-8859-1 屬性檔嗎？
它模擬瀏覽器端的 load(Reader) 行為，針對 Unicode 字元文字。load(InputStream) 的位元組解碼不在範疇內，應在貼入前完成。

相關工具

開發者工具 使用指南

查看全部