[{"content":"兩種編碼，兩個任務 Base64 和 URL 編碼都會把「不安全」的字元替換成安全字元。這種表面相似，正是它們經常被搞混的原因——要嘛該用一種卻用了兩種，要嘛乾脆用錯了。\n一句話版本：\nBase64 讓二進位資料能通過只支援文字的通道 百分比編碼 讓文字能安全地放進 URL 各自到底做了什麼 Base64 用 64 個字元的字母表（A–Z a–z 0–9 + /，結尾用 = 補齊）重寫位元組。每 3 個位元組變成 4 個字元，體積因此增加約 33%。\nMan → TWFu Hello → SGVsbG8= 百分比編碼把在 URL 裡不安全的字元替換成 % 加兩個十六進位數字（對應 UTF-8 位元組）。\na b → a%20b 書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 a\u0026amp;b → a%26b 關鍵差別 Base64 百分比編碼 目的 讓二進位穿過文字通道 讓文字安全地待在 URL 裡 字元集 固定的 64 個字元 任意位元組，寫成 %XX 體積變化 +33% 變化很大 誰能還原 任何人 任何人 提供安全性 否 否 常見位置 JSON 欄位、data URI、郵件附件、JWT 查詢參數、路徑片段 什麼時候用 Base64 把小型圖片以 data URI 內嵌進 CSS 或 HTML 在 JSON 裡傳檔案、縮圖或簽章 透過 MIME 寄送郵件附件 構造 Authorization: Basic 請求標頭 JWT 的 header 與 payload 段 需要雙向轉換時，直接用 Base64 編解碼工具，不用裝任何東西。\n什麼時候用百分比編碼 查詢參數的值裡含有 \u0026amp;、=、#、?、空白或非 ASCII 字元 檔名或 slug 要放進路徑 把一個 URL 當作另一個 URL 的參數傳遞（重複編碼的 bug 就出在這裡） URL 編解碼工具 用的是 encodeURIComponent，正是處理參數值時需要的行為。\n三種最常見的陷阱 1. 該用百分比編碼的地方用了 Base64。 Base64 裡有 + 和 /，直接放進查詢字串時，很多解析器會把 + 當成空白。解決辦法：用 URL-safe 字母表（- 和 _），或者對結果再做一次百分比編碼。\n2. 重複編碼。 對已經編碼過的內容再編碼一次，會得到一層「看起來合法但毫無意義」的結果。典型特徵是開頭出現 %25（%25 就是 %）。\n3. 把兩者當成加密。 兩者都可以在沒有任何金鑰的情況下還原。需要保密就先加密，再編碼。\n我這種情況該用哪個？ 只問一個問題：目標位置是 URL，還是文字容器？\nURL（查詢字串、路徑）→ 百分比編碼 文字容器（JSON、HTML 屬性、郵件本文、CSS）→ 內容是二進位就用 Base64，否則保持純文字 兩個工具放一起試 Base64 線上編解碼 —— 支援文字與二進位，UTF-8 安全，可離線 URL 線上編解碼 —— 查詢參數與路徑 Base64 是什麼？ —— 更詳細的原理說明 URL 編碼完全指南 —— 百分比編碼深入講解 常見問題 能先 Base64 再放進 URL 嗎？ 可以，但要先對 Base64 結果做百分比編碼（或者直接用 Base64URL），否則 +、/、= 會出問題。\n百分比編碼一定比 Base64 長嗎？ 通常是。中文按 UTF-8 百分比編碼後，一個漢字要 9 個字元，遠超 Base64 的 33% 開銷。\n兩者會壓縮資料嗎？ 都不會。想減小體積先壓縮（gzip／Brotli），再編碼。\n密碼該用哪種？ 都不用。用密碼管理器加上真正的加密——編碼不等於保護。\n相關閱讀 JSON 怎麼格式化與驗證 全部線上工具 ","permalink":"https://navshelf.com/zh-tw/posts/base64-vs-url-encoding/","summary":"\u003ch2 id=\"兩種編碼兩個任務\"\u003e兩種編碼，兩個任務\u003c/h2\u003e\n\u003cp\u003eBase64 和 URL 編碼都會把「不安全」的字元替換成安全字元。這種表面相似，正是它們經常被搞混的原因——要嘛該用一種卻用了兩種，要嘛乾脆用錯了。\u003c/p\u003e\n\u003cp\u003e一句話版本：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eBase64\u003c/strong\u003e 讓\u003cem\u003e二進位資料\u003c/em\u003e能通過只支援文字的通道\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e百分比編碼\u003c/strong\u003e 讓\u003cem\u003e文字\u003c/em\u003e能安全地放進 URL\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"各自到底做了什麼\"\u003e各自到底做了什麼\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eBase64\u003c/strong\u003e 用 64 個字元的字母表（\u003ccode\u003eA–Z a–z 0–9 + /\u003c/code\u003e，結尾用 \u003ccode\u003e=\u003c/code\u003e 補齊）重寫位元組。每 3 個位元組變成 4 個字元，體積因此增加約 33%。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eMan     → TWFu\nHello   → SGVsbG8=\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003e百分比編碼\u003c/strong\u003e把在 URL 裡不安全的字元替換成 \u003ccode\u003e%\u003c/code\u003e 加兩個十六進位數字（對應 UTF-8 位元組）。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ea b            → a%20b\n書籤管理        → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86\na\u0026amp;b            → a%26b\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"關鍵差別\"\u003e關鍵差別\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eBase64\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e百分比編碼\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e目的\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e讓二進位穿過文字通道\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e讓文字安全地待在 URL 裡\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e字元集\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e固定的 64 個字元\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任意位元組，寫成 \u003ccode\u003e%XX\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e體積變化\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e+33%\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e變化很大\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e誰能還原\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任何人\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任何人\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e提供安全性\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e否\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e否\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e常見位置\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eJSON 欄位、data URI、郵件附件、JWT\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e查詢參數、路徑片段\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"什麼時候用-base64\"\u003e什麼時候用 Base64\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e把小型圖片以 \u003cstrong\u003edata URI\u003c/strong\u003e 內嵌進 CSS 或 HTML\u003c/li\u003e\n\u003cli\u003e在 \u003cstrong\u003eJSON\u003c/strong\u003e 裡傳檔案、縮圖或簽章\u003c/li\u003e\n\u003cli\u003e透過 MIME 寄送\u003cstrong\u003e郵件附件\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e構造 \u003ccode\u003eAuthorization: Basic\u003c/code\u003e 請求標頭\u003c/li\u003e\n\u003cli\u003eJWT 的 header 與 payload 段\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e需要雙向轉換時，直接用 \u003ca href=\"/tools/base64/\"\u003eBase64 編解碼工具\u003c/a\u003e，不用裝任何東西。\u003c/p\u003e","title":"Base64 和 URL 編碼有什麼區別？各自該在什麼時候用"},{"content":"Base64 要解決什麼問題 很多系統只傳「文字」：郵件協定為 7 位元 ASCII 設計，JSON 定義為文字，HTML 屬性裡放的是字串。但我們真正想傳輸的東西——圖片、PDF、金鑰、二進位協定資料——是位元組串流，裡面很容易混進控制字元、引號與換行。\n把原始二進位直接塞進文字通道，遲早會出問題：換行被改寫、引號提前結束字串、代理伺服器吃掉一個位元組。Base64 的做法是：只用 64 個所有文字系統都認得的字元重新表示這些位元組。\nA–Z a–z 0–9 + / 結尾的 = 只用於補齊。整個字母表就這些。\nBase64 的原理 Base64 每處理 3 個位元組（24 位元），就把他們重寫成 4 個字元（4 × 6 位元）：\n輸入 位元數 輸出 Man 24 位元 TWFu Ma 16 位元 + 補齊 TWE= M 8 位元 + 補齊 TQ== 由此直接得到兩個結論：\n結果大約比原文大 33%（3 個位元組變成 4 個字元） = 的數量告訴解碼器最後一組缺了幾個位元組，一個或兩個 = 表示結尾不完整 Base64 是可逆的、完全公開的編碼，沒有金鑰，也沒有任何保密性。\n日常開發中在哪裡遇到 Base64 Data URI：background-image: url(data:image/png;base64,...) 把小圖示直接內嵌進 CSS JSON 介面：在 JSON 欄位裡傳檔案、縮圖或簽章 郵件附件：MIME 用 Base64 編碼附件，讓它們能穿過只支援文字的郵件伺服器 HTTP Basic 認證：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的編碼結果 JWT：Token 的 header 與 payload 兩段都是 Base64URL 字串 Base64 不是加密 這是最重要的一點：Base64 不提供任何保密性。\n任何人拿到 Base64 字串，打開瀏覽器主控台一行就能還原——不需要金鑰，也不需要工具。編碼解決的是「怎麼傳」，加密解決的是「給誰看」。需要保密就用 TLS 傳輸加上真正的加密（AES-GCM、libsodium、age 等），需要文字通道時再對密文做 Base64。\n怎麼線上編解碼 不用裝任何東西。本站的 Base64 線上編解碼工具 完全在瀏覽器本機執行，不上傳資料，離線也能用。\n選擇「編碼」或「解碼」 把文字或 Base64 字串貼到輸入框 點「開始轉換」（或按 Ctrl／⌘ + Enter） 複製或下載結果 因為工具是純 HTML、沒有後端，處理內部 ID、設定片段、日誌片段都沒問題；但生產環境的金鑰不要貼進任何你不掌控的線上工具。\n五個常見陷阱 1. URL-safe Base64 用的是另一套字母表。 標準 Base64 含 + 和 /，它們在 URL 裡有意義；URL-safe 版本（RFC 4648 §5）會換成 - 和 _。如果解碼器莫名奇妙報錯，先看字母表。\n2. 補齊的 = 有時被省略。 不少編碼器會去掉結尾的 = 省空間，解碼時需要自己推斷缺少的位元組。多數函式庫能處理，嚴格的函式庫會直接丟出錯誤。\n3. 換行與空白。 經典 MIME 輸出每 76 個字元換行。多數解碼器會忽略 \\n 與空白（我們的工具也會），但不要假設所有解碼器都這樣。\n4. btoa() 不認得 UTF-8。 瀏覽器裡 btoa('中文') 會丟出 InvalidCharacterError，因為 btoa 只接受 Latin-1。正確做法是先用 TextEncoder 把字串轉成 UTF-8 位元組，再編碼。可靠的工具都替你做了這件事。\n5. 重複編碼。 對已經是 Base64 的內容再編碼一次，會得到一層「看起來合法但沒有意義」的結果。如果解碼出來仍是亂碼，多半是編碼了兩遍，或者你編碼的原來就不是文字資料。\n常見問題 Base64 會讓資料變大多少？ 壓縮前大約 33%。1 MB 的圖片會變成約 1.37 MB 的文字。\n能手工解碼嗎？ 理論上可以，它就是一份 6 位元對照表；實際上用工具更快。\nBase64 會壓縮資料嗎？ 不會，它會膨脹。想要更小的體積，先壓縮（gzip、Brotli、zstd）再編碼。\nBase64 能直接放進 URL 嗎？ 只有 URL-safe 字母表可以，否則還要再做一次百分比編碼——我們的 URL 編解碼工具 正是做這個的。\n相關閱讀 URL 編碼（百分比編碼）完全指南 Base64 和 URL 編碼有什麼區別 全部線上工具 ","permalink":"https://navshelf.com/zh-tw/posts/base64-encoding-explained/","summary":"\u003ch2 id=\"base64-要解決什麼問題\"\u003eBase64 要解決什麼問題\u003c/h2\u003e\n\u003cp\u003e很多系統只傳「文字」：郵件協定為 7 位元 ASCII 設計，JSON 定義為文字，HTML 屬性裡放的是字串。但我們真正想傳輸的東西——圖片、PDF、金鑰、二進位協定資料——是位元組串流，裡面很容易混進控制字元、引號與換行。\u003c/p\u003e\n\u003cp\u003e把原始二進位直接塞進文字通道，遲早會出問題：換行被改寫、引號提前結束字串、代理伺服器吃掉一個位元組。Base64 的做法是：只用 64 個所有文字系統都認得的字元重新表示這些位元組。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eA–Z  a–z  0–9  +  /\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e結尾的 \u003ccode\u003e=\u003c/code\u003e 只用於補齊。整個字母表就這些。\u003c/p\u003e\n\u003ch2 id=\"base64-的原理\"\u003eBase64 的原理\u003c/h2\u003e\n\u003cp\u003eBase64 每處理 \u003cstrong\u003e3 個位元組（24 位元）\u003c/strong\u003e，就把他們重寫成 \u003cstrong\u003e4 個字元（4 × 6 位元）\u003c/strong\u003e：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e輸入\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e位元數\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e輸出\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eMan\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e24 位元\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eTWFu\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eMa\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e16 位元 + 補齊\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eTWE=\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eM\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e8 位元 + 補齊\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eTQ==\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e由此直接得到兩個結論：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e結果大約比原文大 33%\u003c/strong\u003e（3 個位元組變成 4 個字元）\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ccode\u003e=\u003c/code\u003e 的數量告訴解碼器最後一組缺了幾個位元組\u003c/strong\u003e，一個或兩個 \u003ccode\u003e=\u003c/code\u003e 表示結尾不完整\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eBase64 是可逆的、完全公開的編碼，沒有金鑰，也沒有任何保密性。\u003c/p\u003e\n\u003ch2 id=\"日常開發中在哪裡遇到-base64\"\u003e日常開發中在哪裡遇到 Base64\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eData URI\u003c/strong\u003e：\u003ccode\u003ebackground-image: url(data:image/png;base64,...)\u003c/code\u003e 把小圖示直接內嵌進 CSS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJSON 介面\u003c/strong\u003e：在 JSON 欄位裡傳檔案、縮圖或簽章\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e郵件附件\u003c/strong\u003e：MIME 用 Base64 編碼附件，讓它們能穿過只支援文字的郵件伺服器\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHTTP Basic 認證\u003c/strong\u003e：\u003ccode\u003eAuthorization: Basic dXNlcjpwYXNz\u003c/code\u003e 就是 \u003ccode\u003euser:pass\u003c/code\u003e 的編碼結果\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJWT\u003c/strong\u003e：Token 的 header 與 payload 兩段都是 Base64URL 字串\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"base64-不是加密\"\u003eBase64 不是加密\u003c/h2\u003e\n\u003cp\u003e這是最重要的一點：\u003cstrong\u003eBase64 不提供任何保密性\u003c/strong\u003e。\u003c/p\u003e","title":"Base64 是什麼？原理、用途與線上工具使用指南"},{"content":"為什麼 JSON 總是難以閱讀 每個介面回傳、每份設定檔、每行日誌都是 JSON。壓縮後它是一整塊字元牆；格式化之後同樣的資料兩秒就能掃完。資料完全相同，差的只是空白——這也是「JSON 格式化」成為開發者最常用搜尋之一的原因。\n格式化、壓縮、驗證的差別 操作 改變什麼 什麼時候用 格式化 加縮排與換行 閱讀、審查、排查問題 壓縮 去掉所有多餘空白 傳輸、儲存設定 驗證 不改內容，只報語法錯誤 送出請求或提交設定前 這三件事在 JSON 格式化工具 裡都只差一次點擊，而且全程在瀏覽器本機完成。\n什麼才算合法的 JSON JSON 的語法非常小，而且比 JavaScript 嚴格得多：\n鍵名必須用雙引號包起來 字串必須用雙引號，單引號不合法 不允許多餘的逗號 不允許註解（// 和 /* */ 都不行） 值只有這幾種：物件、陣列、字串、數字、true、false、null 數字不能有多餘的前導零，NaN／Infinity 也不是合法值 如果你寫過 JSON5、JSONC（VS Code 設定）或 JavaScript 物件實字，其中一些習慣在 JSON 裡是違法的。\n最常踩的五個錯誤 1. 多了一個逗號\n{ \u0026#34;name\u0026#34;: \u0026#34;NavShelf\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0\u0026#34;, } \u0026quot;1.0\u0026quot; 後面那個逗號，是 JSON 錯誤的第一大來源。\n2. 用了單引號\n{ \u0026#39;name\u0026#39;: \u0026#39;NavShelf\u0026#39; } JavaScript 合法，JSON 違法。\n3. 鍵名沒加引號\n{ name: \u0026#34;NavShelf\u0026#34; } 同樣：JavaScript 合法，JSON 違法。\n4. 寫了註解\n在設定裡加一句 // TODO，然後程式啟動失敗。標準 JSON 沒有註解語法。\n5. 內容被截斷或拼接\n兩個物件黏在一起，或者從日誌複製時被截斷。抓日誌時最常遇到這種。\n怎麼讀懂 JSON 錯誤訊息 瀏覽器與 Node 的錯誤通常長這樣：\nUnexpected token } in JSON at position 84 這裡的 position 是從字串開頭算起的字元位移，不是行號。要嘛自己數，要嘛交給工具：格式化工具 會直接告訴你 第 N 行第 M 欄，這才是修復時需要的資訊。\n一套順手的流程 把原始內容貼進 JSON 格式化工具 點「驗證」，先確認能不能解析 點「格式化」看結構——多數時候你會發現是某個鍵寫錯或層級放錯 回到源頭修改，只在傳輸或儲存時點「壓縮」 倉庫裡存格式化版本，壓縮放到建置或傳輸環節做 關於體積 壓縮通常能省 10%～30%，取決於巢狀深度。這點節省本身意義有限，因為傳輸時的 gzip 壓縮率高得多。壓縮真正的價值在於一致性：避免因空白差異產生的合併衝突，也讓體積可預期。\n常見問題 格式化會改變資料嗎？ 不會。字串之外的空白在 JSON 中是可忽略的，格式化與壓縮都是無損的。\nJSON 允許重複的鍵嗎？ 規範沒有明確禁止，但行為未定義——多數解析器保留最後一個值。別這樣寫。\n為什麼我的內容在 JavaScript 裡能用，驗證卻不過？ 因為你寫的不是 JSON，而是 JavaScript 物件實字。先用 JSON.stringify(obj) 轉換一下。\n這個工具會上傳資料嗎？ 不會，解析用的是瀏覽器內建的 JSON 解析器，離線也能用。\n相關閱讀 Base64 和 URL 編碼有什麼區別 全部線上工具 ","permalink":"https://navshelf.com/zh-tw/posts/json-formatter-guide/","summary":"\u003ch2 id=\"為什麼-json-總是難以閱讀\"\u003e為什麼 JSON 總是難以閱讀\u003c/h2\u003e\n\u003cp\u003e每個介面回傳、每份設定檔、每行日誌都是 JSON。壓縮後它是一整塊字元牆；格式化之後同樣的資料兩秒就能掃完。資料完全相同，差的只是空白——這也是「JSON 格式化」成為開發者最常用搜尋之一的原因。\u003c/p\u003e\n\u003ch2 id=\"格式化壓縮驗證的差別\"\u003e格式化、壓縮、驗證的差別\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e操作\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e改變什麼\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e什麼時候用\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e格式化\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e加縮排與換行\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e閱讀、審查、排查問題\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e壓縮\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e去掉所有多餘空白\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e傳輸、儲存設定\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e驗證\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不改內容，只報語法錯誤\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e送出請求或提交設定前\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e這三件事在 \u003ca href=\"/tools/json-formatter/\"\u003eJSON 格式化工具\u003c/a\u003e 裡都只差一次點擊，而且全程在瀏覽器本機完成。\u003c/p\u003e\n\u003ch2 id=\"什麼才算合法的-json\"\u003e什麼才算合法的 JSON\u003c/h2\u003e\n\u003cp\u003eJSON 的語法非常小，而且比 JavaScript 嚴格得多：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e鍵名\u003cstrong\u003e必須\u003c/strong\u003e用雙引號包起來\u003c/li\u003e\n\u003cli\u003e字串\u003cstrong\u003e必須\u003c/strong\u003e用雙引號，單引號不合法\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不允許\u003c/strong\u003e多餘的逗號\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不允許\u003c/strong\u003e註解（\u003ccode\u003e//\u003c/code\u003e 和 \u003ccode\u003e/* */\u003c/code\u003e 都不行）\u003c/li\u003e\n\u003cli\u003e值只有這幾種：物件、陣列、字串、數字、\u003ccode\u003etrue\u003c/code\u003e、\u003ccode\u003efalse\u003c/code\u003e、\u003ccode\u003enull\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e數字不能有多餘的前導零，\u003ccode\u003eNaN\u003c/code\u003e／\u003ccode\u003eInfinity\u003c/code\u003e 也不是合法值\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果你寫過 JSON5、JSONC（VS Code 設定）或 JavaScript 物件實字，其中一些習慣在 JSON 裡是違法的。\u003c/p\u003e\n\u003ch2 id=\"最常踩的五個錯誤\"\u003e最常踩的五個錯誤\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e1. 多了一個逗號\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"nt\"\u003e\u0026#34;name\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"s2\"\u003e\u0026#34;NavShelf\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"nt\"\u003e\u0026#34;version\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"s2\"\u003e\u0026#34;1.0\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e\u003ccode\u003e\u0026quot;1.0\u0026quot;\u003c/code\u003e 後面那個逗號，是 JSON 錯誤的第一大來源。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. 用了單引號\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e \u003cspan class=\"err\"\u003e\u0026#39;name\u0026#39;:\u003c/span\u003e \u003cspan class=\"err\"\u003e\u0026#39;NavShelf\u0026#39;\u003c/span\u003e \u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eJavaScript 合法，JSON 違法。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. 鍵名沒加引號\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e \u003cspan class=\"err\"\u003ename:\u003c/span\u003e \u003cspan class=\"nt\"\u003e\u0026#34;NavShelf\u0026#34;\u003c/span\u003e \u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e同樣：JavaScript 合法，JSON 違法。\u003c/p\u003e","title":"JSON 怎麼格式化與驗證？常見錯誤與修復方法"},{"content":"一個典型的壞連結 你拼了一個搜尋連結，英文下一切正常，使用者一輸入中文就掛：\nhttps://example.com/search?q=書籤管理 \u0026amp; page=2 伺服器收到的 q 是 書籤管理 ，還多了一個叫 page 的參數——本來屬於查詢值的 \u0026amp; 被當成了分隔符。#、=、?、+ 和空白也有同樣的問題。\n解決辦法是百分比編碼（URL 編碼）：把不安全的字元替換成 % 加兩個十六進位數字，表示它的 UTF-8 位元組。\n書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 \u0026amp; → %26 空白 → %20 哪些字元是安全的 RFC 3986 把字元分成「未保留」與「保留」兩類，只有未保留字元可以原樣出現：\n類別 字元 說明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（結構類） : / ? # [ ] @ 在 URL 中有結構意義 保留（子分隔符） ! $ \u0026amp; ' ( ) * + , ; = 在查詢字串中有意義 其他 空白、\u0026quot;、\u0026lt;、\u0026gt;、%、{}、中文⋯ 必須編碼 保留字元不是「不能用」，而是「有意義」。關鍵問題永遠是：這個 \u0026amp; 是想表達結構，還是想表達資料？如果是資料，就編碼它。\nencodeURI 和 encodeURIComponent 的差別 JavaScript 內建兩個編碼函式，行為完全不同：\nconst raw = \u0026#39;https://example.com/search?q=書籤 \u0026amp; page=2\u0026#39; encodeURI(raw) // https://example.com/search?q=%E6%9B%B8%E7%B1%A4%20\u0026amp;%20page=2 // 保留 : / ? \u0026amp; = —— 用來編碼「一整個 URL」 encodeURIComponent(raw) // https%3A%2F%2Fexample.com%2Fsearch%3Fq%3D%E6%9B%B8%E7%B1%A4%20%26%20page%3D2 // 連 : / ? \u0026amp; = 一起編碼 —— 用來編碼「一個參數值」 簡單判斷：\n編碼完整 URL（自己拼好的）→ 用 encodeURI 編碼要插進 URL 的參數值 → 用 encodeURIComponent 大部分 bug 都來自用錯這一個函式。如果參數值裡還嵌著 URL，基本上一定要用 encodeURIComponent。\n空白到底是 %20 還是 + ？ 兩種都存在，差別是歷史原因：\n路徑和標準規定用 %20 application/x-www-form-urlencoded（HTML 表單、很多查詢解析器）把空白編碼成 + 在路徑裡，+ 就是字面上的加號，不是空白。這就是「我的 + 怎麼變成空白了」這類問題的根源：解析器把它當成表單編碼資料了。\n為什麼會解碼失敗 decodeURIComponent('%E6%9B%B8') 正常，decodeURIComponent('%E6%9B') 會丟出錯誤，decodeURIComponent('100%') 也會——單獨的 % 不是完整的轉義序列。\n遇到 URIError 時按順序排查：\n序列被截斷：% 後面沒有兩個十六進位數字 編碼了兩遍：%25E6... 解一次得到 %E6...，需要再解一次 層次搞錯：解碼了本來就沒編碼的內容，例如優惠碼裡的 % 怎麼在瀏覽器裡編解碼 URL 線上編解碼工具 完全在瀏覽器本機執行，不上傳、可離線。\n選擇「編碼」或「解碼」 貼上文字、URL 或已編碼字串 點「開始轉換」（或按 Ctrl／⌘ + Enter） 把結果複製到程式碼或網址列 工具使用 encodeURIComponent / decodeURIComponent，正是處理查詢參數值時需要的行為。\n常見問題 應該編碼整個 URL 還是只編碼參數？ 只編碼「資料」部分。結構自己拼，每個值用 encodeURIComponent 編碼。\n為什麼 %20 有時顯示成 +？ 表單編碼用 + 表示空白。對接不同解析器時注意轉換。\n中文需要編碼嗎？ 需要。中文不屬於 ASCII，必須按 UTF-8 位元組做百分比編碼。\n能手工解碼嗎？ 短字串可以查表，稍長一點還是用工具更可靠。\n相關閱讀 Base64 是什麼？原理與用途 Base64 和 URL 編碼有什麼區別 全部線上工具 ","permalink":"https://navshelf.com/zh-tw/posts/url-encoding-explained/","summary":"\u003ch2 id=\"一個典型的壞連結\"\u003e一個典型的壞連結\u003c/h2\u003e\n\u003cp\u003e你拼了一個搜尋連結，英文下一切正常，使用者一輸入中文就掛：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ehttps://example.com/search?q=書籤管理 \u0026amp; page=2\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e伺服器收到的 \u003ccode\u003eq\u003c/code\u003e 是 \u003ccode\u003e書籤管理 \u003c/code\u003e，還多了一個叫 \u003ccode\u003epage\u003c/code\u003e 的參數——本來屬於查詢值的 \u003ccode\u003e\u0026amp;\u003c/code\u003e 被當成了分隔符。\u003ccode\u003e#\u003c/code\u003e、\u003ccode\u003e=\u003c/code\u003e、\u003ccode\u003e?\u003c/code\u003e、\u003ccode\u003e+\u003c/code\u003e 和空白也有同樣的問題。\u003c/p\u003e\n\u003cp\u003e解決辦法是\u003cstrong\u003e百分比編碼\u003c/strong\u003e（URL 編碼）：把不安全的字元替換成 \u003ccode\u003e%\u003c/code\u003e 加兩個十六進位數字，表示它的 UTF-8 位元組。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e書籤管理  →  %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86\n\u0026amp;        →  %26\n空白      →  %20\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"哪些字元是安全的\"\u003e哪些字元是安全的\u003c/h2\u003e\n\u003cp\u003eRFC 3986 把字元分成「未保留」與「保留」兩類，只有未保留字元可以原樣出現：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e類別\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e字元\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e說明\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e未保留\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eA–Z a–z 0–9 - _ . ~\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任何位置都安全\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e保留（結構類）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e: / ? # [ ] @\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e在 URL 中有結構意義\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e保留（子分隔符）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e! $ \u0026amp; ' ( ) * + , ; =\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e在查詢字串中有意義\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e其他\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e空白、\u003ccode\u003e\u0026quot;\u003c/code\u003e、\u003ccode\u003e\u0026lt;\u003c/code\u003e、\u003ccode\u003e\u0026gt;\u003c/code\u003e、\u003ccode\u003e%\u003c/code\u003e、\u003ccode\u003e{}\u003c/code\u003e、中文⋯\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e必須編碼\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e保留字元不是「不能用」，而是「有意義」。關鍵問題永遠是：這個 \u003ccode\u003e\u0026amp;\u003c/code\u003e 是想表達結構，還是想表達資料？如果是資料，就編碼它。\u003c/p\u003e","title":"URL 編碼（百分比編碼）完全指南：查詢參數怎麼正確轉義"},{"content":"一個讓很多人意外的數字 貸款 100 萬，年利率 4.5%，30 年：\n每月還款 5,066.85 還款總額 1,824,067 其中利息 824,067，相當於本金的 82% 更讓人意外的是前五年：五年一共還了 304,011，但其中只有 88,421 是本金，剩下 215,590 全是利息。還了五年，本金幾乎沒什麼動。\n這不是陷阱，而是「餘額計息 + 長期年限」的必然結果。看懂這個形狀，你才是在有意識地選貸款，而不是只盯著月付。\n你可以在貸款試算工具裡用自己的數字跟著算。\n兩種攤還方式 本息平均攤還（等額本息）：每月還款金額固定不變。前期利息占大宗，後期本金占大宗。好規劃，但總利息較多。\n本金平均攤還（等額本金）：每月償還的本金固定，所以利息逐月減少、月付也逐月減少。首月最高，末月最低，總利息較少。\n計算公式 本息平均攤還：M = P × r × (1+r)^n / ((1+r)^n − 1) 本金平均攤還：每月本金 = P / n，利息 = 剩餘本金 × r 其中 P 是本金，r 是月利率（年利率 ÷ 12），n 是還款月數，M 是本息平均攤還的固定月付。\n年限的影響比利率還大 同樣 100 萬、4.5%，只改年限：\n年限 月付 總利息 還款總額 10 年 10,363.84 243,660.91 1,243,660.91 20 年 6,326.49 518,358.50 1,518,358.50 30 年 5,066.85 824,067.12 1,824,067.12 從 20 年拉到 30 年，月付只降了 20%，總利息卻多了 305,709。這就是多出來的那十年真正的價格。\n利率：小變化，大金額 年利率 月付 總利息 3.5% 4,490.45 616,560.88 4.5% 5,066.85 824,067.12 5.5% 5,677.89 1,044,040.40 一個百分點，月付差 576 元，30 年總利息差 超過 21.9 萬。所以談貸款時，先談利率，再談別的。\n兩種攤還方式，同一筆貸款 本息平均攤還 本金平均攤還 首月 5,066.85 6,527.78 末月 5,066.85 2,788.19 總利息 824,067.12 676,875.00 本金平均攤還省下 147,192 利息，代價是首月多還 1,461 元。\n這個取捨取決於你的現金流，而不是數學：如果首月多還這一千多讓你緊張，那「更省」的那個選擇對你就是錯的。\n提前還款到底能省多少 還是那筆 30 年的本息平均攤還，每月多還 2,000：\n不提前還 每月多還 2,000 還款期數 30 年 16 年 11 個月 總利息 824,067.12 428,101.16 提前 157 期還完，省下約 39.6 萬利息。 效果這麼好有兩個原因：\n多還的每一塊錢全部沖抵本金，同時也免掉了這部分本金未來所有的利息 它是反向複利——越早還，砍掉的未來利息越多 所以「從第一年就開始每月多還一點」，遠比「等到第二十年一次還一大筆」划算。\n五個常見誤區 只看月付選貸款——月付最低的，往往總成本最高 不看總利息——一定把總利息也算出來 忘了稅費與保險——房屋稅、火險通常另收，會讓實際月支出再多兩成 以為利率永遠不變——浮動利率要按最壞情況試算 忽略提前還款條款——有些貸款收違約金，可能把省下的利息又吃回去 常見問題 本息平均攤還和本金平均攤還到底選哪個？ 本金平均攤還總利息較少，本息平均攤還前期壓力較小。如果你撐得住首月較高月付、並且打算長期持有，本金平均攤還在成本上更划算。\n年限越短越好嗎？ 從成本看是的，從彈性看不是——年限短意味著每月必須還的錢更多。很多人選長年限加主動多還，這樣在收入波動時保留了「少還一點」的餘地。\n每年多還一次有用嗎？ 有用，而且幾乎零成本。把年金額除以 12 填進計算機的「每月額外還款」就能看到效果。\n包含稅費與保險嗎？ 不含。計算機只算本金和利息。\n相關閱讀 複利是怎麼滾起來的——同一套數學，從存錢的角度看 每月該存多少錢才能達成目標？ 全部線上工具 本文僅作科普，不構成任何投資或貸款建議。各銀行與地區的利率、條款差異很大，請以實際合約為準。\n","permalink":"https://navshelf.com/zh-tw/posts/mortgage-math-explained/","summary":"\u003ch2 id=\"一個讓很多人意外的數字\"\u003e一個讓很多人意外的數字\u003c/h2\u003e\n\u003cp\u003e貸款 \u003cstrong\u003e100 萬\u003c/strong\u003e，年利率 \u003cstrong\u003e4.5%\u003c/strong\u003e，\u003cstrong\u003e30 年\u003c/strong\u003e：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e每月還款 \u003cstrong\u003e5,066.85\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e還款總額 \u003cstrong\u003e1,824,067\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e其中\u003cstrong\u003e利息 824,067\u003c/strong\u003e，相當於本金的 \u003cstrong\u003e82%\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e更讓人意外的是前五年：五年一共還了 \u003cstrong\u003e304,011\u003c/strong\u003e，但其中只有 \u003cstrong\u003e88,421\u003c/strong\u003e 是本金，剩下 \u003cstrong\u003e215,590\u003c/strong\u003e 全是利息。還了五年，本金幾乎沒什麼動。\u003c/p\u003e\n\u003cp\u003e這不是陷阱，而是「餘額計息 + 長期年限」的必然結果。看懂這個形狀，你才是在有意識地選貸款，而不是只盯著月付。\u003c/p\u003e\n\u003cp\u003e你可以在\u003ca href=\"/tools/loan-calculator/\"\u003e貸款試算工具\u003c/a\u003e裡用自己的數字跟著算。\u003c/p\u003e\n\u003ch2 id=\"兩種攤還方式\"\u003e兩種攤還方式\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e本息平均攤還（等額本息）\u003c/strong\u003e：每月還款金額固定不變。前期利息占大宗，後期本金占大宗。好規劃，但總利息較多。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e本金平均攤還（等額本金）\u003c/strong\u003e：每月償還的本金固定，所以利息逐月減少、月付也逐月減少。首月最高，末月最低，總利息較少。\u003c/p\u003e\n\u003ch2 id=\"計算公式\"\u003e計算公式\u003c/h2\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e本息平均攤還：M = P × r × (1+r)^n / ((1+r)^n − 1)\n本金平均攤還：每月本金 = P / n，利息 = 剩餘本金 × r\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e其中 P 是本金，r 是月利率（年利率 ÷ 12），n 是還款月數，M 是本息平均攤還的固定月付。\u003c/p\u003e\n\u003ch2 id=\"年限的影響比利率還大\"\u003e年限的影響比利率還大\u003c/h2\u003e\n\u003cp\u003e同樣 100 萬、4.5%，只改年限：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e年限\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e月付\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e總利息\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e還款總額\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e10 年\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10,363.84\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e243,660.91\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e1,243,660.91\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20 年\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e6,326.49\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e518,358.50\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e1,518,358.50\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e30 年\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5,066.85\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e824,067.12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e1,824,067.12\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e從 20 年拉到 30 年，月付只降了 20%，\u003cstrong\u003e總利息卻多了 305,709\u003c/strong\u003e。這就是多出來的那十年真正的價格。\u003c/p\u003e","title":"本息平均攤還與本金平均攤還怎麼選？用一張表算清房貸利息"},{"content":"書籤比你想像中脆弱 書籤看起來會一直在，直到某天不會：設定重設、重裝系統、同步衝突、帳號被盜，或者筆電直接開不了機。和文件不同，絕大多數人從沒備份過書籤——但一套維護多年的收藏，往往代表好幾年的篩選與累積。\n好消息是：主流瀏覽器都能在幾秒內匯出與匯入書籤。更好的消息是，有一套幾乎不需要維護的做法。\nChrome 匯出\n開啟 chrome://bookmarks/ 點右上角 ⋮ 選單 選擇 匯出書籤，會得到一個 HTML 檔 匯入\n同一個選單 → 匯入書籤 → 選擇 HTML 檔。Chrome 會把它合併到一個名為「已匯入」的資料夾裡。\n資料實際存在哪：Chrome 設定目錄下的 Bookmarks 檔案（JSON 格式）。直接複製整個設定目錄也可以，但必須在 Chrome 關閉時操作。\nEdge 流程和 Chrome 完全一致：edge://favorites/ → ⋯ → 匯出我的最愛 / 匯入我的最愛。\nFirefox 用 Ctrl+Shift+O（macOS 是 Cmd+Shift+O）開啟「媒體庫」 匯入與備份 → 匯出書籤至 HTML 還原：同一選單 → 從 HTML 匯入書籤 Firefox 還會在設定目錄的 bookmarkbackups 裡保留自動備份，發現問題夠早的話非常有用。\nSafari 入口藏在「檔案」選單裡：\n檔案 → 匯出 → 書籤⋯（產生 HTML） 還原：檔案 → 從以下位置輸入 → 書籤.html 有開 iCloud 的話 Safari 也會同步，但同步不等於備份——刪除同樣會同步出去。\nHTML 匯出的陷阱 HTML 通用、可攜，但它是「扁平」的：資料夾能保留，排序大致保留，標籤與備註幾乎全失。它是一份快照，不是可用格式。\n而且如果把 HTML 匯入到已經有書籤的瀏覽器裡，會產生大量重複。正確做法是匯入到乾淨的設定檔，或者匯入到一個之後可以整個刪掉的資料夾。\n更省心的做法：自己留一份 JSON 一套能繞開上面所有問題的習慣：\n把工作用的收藏放在支援匯出 JSON 的工具裡——NavShelf 在「關於」對話框裡就能匯出，資料只存在你自己的瀏覽器裡，不上傳伺服器。 每月匯出一次，放進真正有備份的位置（雲端硬碟、NAS 或同步資料夾）。 瀏覽器設定檔掛了也不要緊：把 JSON 匯回工具，需要時再匯出 HTML 給瀏覽器用。 為什麼用 JSON？它保留了目錄結構、排序、描述與設定，而且可以做差異比對，看得出改了什麼。\n同步與備份的差別 同步 備份 自動複製變更 ✅ ❌ 能防誤刪 ❌（刪除會同步） ✅ 帳號出事後還在 ❌ ✅ 需要主動操作 ❌ ✅ 同步是方便，備份是保險。兩個都要有。\n常見問題 不登入帳號，Chrome 的書籤存在哪？ 存在本機設定目錄裡一個叫 Bookmarks 的檔案中。Windows 上通常在 %LocalAppData%\\Google\\Chrome\\User Data\\Default\\。\n移除瀏覽器會刪掉書籤嗎？ 通常設定目錄會保留，但「重設」或乾淨重裝可能會清空。先匯出再說。\n能把兩份收藏合併嗎？ 可以，但要在能顯示重複項的工具裡做——把一份 HTML 匯入另一個瀏覽器，正是重複項最常見的來源。\n多久備份一次？ 多數人每月一次就夠；每天存連結的人建議每週一次。\n相關閱讀 如何整理瀏覽器書籤：7 個真正有效的方法 瀏覽器內建書籤 vs 專業書籤管理器 全部線上工具 ","permalink":"https://navshelf.com/zh-tw/posts/backup-and-restore-browser-bookmarks/","summary":"\u003ch2 id=\"書籤比你想像中脆弱\"\u003e書籤比你想像中脆弱\u003c/h2\u003e\n\u003cp\u003e書籤看起來會一直在，直到某天不會：設定重設、重裝系統、同步衝突、帳號被盜，或者筆電直接開不了機。和文件不同，絕大多數人從沒備份過書籤——但一套維護多年的收藏，往往代表好幾年的篩選與累積。\u003c/p\u003e\n\u003cp\u003e好消息是：主流瀏覽器都能在幾秒內匯出與匯入書籤。更好的消息是，有一套幾乎不需要維護的做法。\u003c/p\u003e\n\u003ch2 id=\"chrome\"\u003eChrome\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e匯出\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e開啟 \u003ccode\u003echrome://bookmarks/\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e點右上角 ⋮ 選單\u003c/li\u003e\n\u003cli\u003e選擇 \u003cstrong\u003e匯出書籤\u003c/strong\u003e，會得到一個 HTML 檔\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e匯入\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e同一個選單 → \u003cstrong\u003e匯入書籤\u003c/strong\u003e → 選擇 HTML 檔。Chrome 會把它合併到一個名為「已匯入」的資料夾裡。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e資料實際存在哪\u003c/strong\u003e：Chrome 設定目錄下的 \u003ccode\u003eBookmarks\u003c/code\u003e 檔案（JSON 格式）。直接複製整個設定目錄也可以，但必須在 Chrome 關閉時操作。\u003c/p\u003e\n\u003ch2 id=\"edge\"\u003eEdge\u003c/h2\u003e\n\u003cp\u003e流程和 Chrome 完全一致：\u003ccode\u003eedge://favorites/\u003c/code\u003e → ⋯ → \u003cstrong\u003e匯出我的最愛\u003c/strong\u003e / \u003cstrong\u003e匯入我的最愛\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2 id=\"firefox\"\u003eFirefox\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e用 \u003ccode\u003eCtrl+Shift+O\u003c/code\u003e（macOS 是 \u003ccode\u003eCmd+Shift+O\u003c/code\u003e）開啟「媒體庫」\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e匯入與備份\u003c/strong\u003e → \u003cstrong\u003e匯出書籤至 HTML\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e還原：同一選單 → \u003cstrong\u003e從 HTML 匯入書籤\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFirefox 還會在設定目錄的 \u003ccode\u003ebookmarkbackups\u003c/code\u003e 裡保留自動備份，發現問題夠早的話非常有用。\u003c/p\u003e\n\u003ch2 id=\"safari\"\u003eSafari\u003c/h2\u003e\n\u003cp\u003e入口藏在「檔案」選單裡：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e檔案 → 匯出 → 書籤⋯\u003c/strong\u003e（產生 HTML）\u003c/li\u003e\n\u003cli\u003e還原：\u003cstrong\u003e檔案 → 從以下位置輸入 → 書籤.html\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e有開 iCloud 的話 Safari 也會同步，但同步不等於備份——刪除同樣會同步出去。\u003c/p\u003e","title":"如何備份與還原瀏覽器書籤（Chrome / Edge / Firefox / Safari）"},{"content":"多數人真正想問的是反過來的問題 大多數計算機告訴你「你將來會有多少錢」。但真正的問題通常是另一個方向：「我想在某個時間點存到某個數字，每月該存多少？」\n這是個能直接解出來的方程式，而且答案往往比想像中樂觀——因為報酬替你分擔了一部分。\n你可以一邊看一邊用儲蓄目標計算機算自己的數字。\n先看基準線：報酬率 0% 是什麼樣 目標 100 萬，已存 5 萬，期限 10 年。\n如果完全沒有報酬，剩下的 95 萬要平攤到 120 個月：\n950,000 ÷ 120 = 7,916.67 / 月 這是「純靠自律」的數字，後面每一點報酬都會把它往下壓。\n報酬率承擔了比想像中更多的份額 同樣的目標、同樣的 10 年、同樣的起始金額，只改報酬率：\n年化報酬率 每月需存 累計存入 報酬貢獻 0% 7,916.67 950,000.00 0.00 3% 6,673.27 800,792.49 149,207.51 5% 5,909.56 709,146.87 240,853.13 8% 4,859.45 583,134.58 366,865.42 按 5% 算，你只需要存入約 70.9 萬，而不是 95 萬——目標的四分之一由報酬完成。8% 時接近 40%。\n但別把這幾行當成菜單。 更高的報酬率意味著更高的風險與更大的不確定性。穩妥的做法是用保守值（5% 甚至更低，扣掉費用與通膨），到時候比預期好是驚喜。\n時間才是威力最大的槓桿 同樣的 100 萬目標、5 萬起始、5% 報酬：\n期限 每月需存 累計存入 5 年 13,761.01 825,660.32 10 年 5,909.56 709,146.87 20 年 2,102.91 504,699.09 從 10 年拉到 20 年，每月需存從 5,910 降到 2,103，不到一半；而且累計存入反而更少，因為複利多了整整一倍的時間。\n這是整頁最有價值的一條：如果算出來的金額讓你覺得不可能，該調整的通常是期限，而不是預算。\n反過來：按現在的存錢速度，要多久 如果你更清楚自己能拿出多少，就讓工具回答時間問題。目標 100 萬、已存 5 萬、報酬 5%：\n每月存 達成時間 累計存入 3,000 16 年 1 個月 582,000 5,000 11 年 4 個月 680,000 8,000 7 年 11 個月 760,000 注意這個規律：存得越多越快，但累計存入反而更高（58.2 萬 → 68 萬 → 76 萬），因為慢的計畫有更多時間賺錢。速度是有價格的，耐心替你付了一部分帳。\n起始本金的影響容易被低估 同樣每月 3,000、報酬 5%，只是起點不同：\n已存 到 100 萬需要 0 17 年 5 個月 5 萬 16 年 1 個月 20 萬 12 年 6 個月 一開始就有 20 萬，等於省下將近 5 年。 已經投出去的錢，無論你後面加不加，每個月都在替你工作。\n一套能執行的流程 報酬率取保守值：扣掉費用；如果想按「今天的購買力」規劃，再扣掉通膨 每月金額向上取整，而不是向下。5,900 和 6,000 的差別按月很小，按十年很大 發薪日自動轉帳。依賴意志力的儲蓄計畫，等於一個有 bug 的計畫 每年重算一次。加薪、年終獎金、市場波動都會改變答案 緊急預備金放在計畫之外。為了修熱水器而賣掉投資，是長期計畫最常見的死法 常見問題 該用名目報酬率還是實際報酬率？ 和你的目標保持一致。如果目標是「按今天購買力算的 100 萬」，就用扣除通膨後的實際報酬率；把名目報酬率和實際目標混用，會高估進度。\n如果報酬率假設錯了呢？ 計畫會平滑地變差——無非是多存一段時間，或者每月多存一點。真正讓計畫崩掉的不是假設偏差，而是徹底中斷。\n存入時點有影響嗎？ 有，但很小。這裡假設每月月末存入；如果改成月初存，每次都能多賺一個月報酬。\n包含稅費嗎？ 不含。應稅帳戶請用更低的淨值報酬率。\n相關閱讀 複利是怎麼滾起來的——同一套數學的正向算法 本息平均攤還與本金平均攤還怎麼選——同一套公式，從借錢的一方看 全部線上工具 本文僅作科普，不構成任何投資建議。報酬率是假設值，請自行判斷。\n","permalink":"https://navshelf.com/zh-tw/posts/savings-goal-explained/","summary":"\u003ch2 id=\"多數人真正想問的是反過來的問題\"\u003e多數人真正想問的是反過來的問題\u003c/h2\u003e\n\u003cp\u003e大多數計算機告訴你「你將來會有多少錢」。但真正的問題通常是另一個方向：\u003cstrong\u003e「我想在某個時間點存到某個數字，每月該存多少？」\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e這是個能直接解出來的方程式，而且答案往往比想像中樂觀——因為報酬替你分擔了一部分。\u003c/p\u003e\n\u003cp\u003e你可以一邊看一邊用\u003ca href=\"/tools/savings-goal-calculator/\"\u003e儲蓄目標計算機\u003c/a\u003e算自己的數字。\u003c/p\u003e\n\u003ch2 id=\"先看基準線報酬率-0-是什麼樣\"\u003e先看基準線：報酬率 0% 是什麼樣\u003c/h2\u003e\n\u003cp\u003e目標 100 萬，已存 5 萬，期限 10 年。\u003c/p\u003e\n\u003cp\u003e如果完全沒有報酬，剩下的 95 萬要平攤到 120 個月：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e950,000 ÷ 120 = 7,916.67 / 月\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e這是「純靠自律」的數字，後面每一點報酬都會把它往下壓。\u003c/p\u003e\n\u003ch2 id=\"報酬率承擔了比想像中更多的份額\"\u003e報酬率承擔了比想像中更多的份額\u003c/h2\u003e\n\u003cp\u003e同樣的目標、同樣的 10 年、同樣的起始金額，只改報酬率：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e年化報酬率\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e每月需存\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e累計存入\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e報酬貢獻\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e0%\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e7,916.67\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e950,000.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e0.00\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e3%\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e6,673.27\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e800,792.49\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e149,207.51\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e5%\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5,909.56\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e709,146.87\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e240,853.13\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e8%\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e4,859.45\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e583,134.58\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e366,865.42\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e按 5% 算，你只需要存入約 \u003cstrong\u003e70.9 萬\u003c/strong\u003e，而不是 95 萬——目標的四分之一由報酬完成。8% 時接近 40%。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e但別把這幾行當成菜單。\u003c/strong\u003e 更高的報酬率意味著更高的風險與更大的不確定性。穩妥的做法是用\u003cstrong\u003e保守值\u003c/strong\u003e（5% 甚至更低，扣掉費用與通膨），到時候比預期好是驚喜。\u003c/p\u003e\n\u003ch2 id=\"時間才是威力最大的槓桿\"\u003e時間才是威力最大的槓桿\u003c/h2\u003e\n\u003cp\u003e同樣的 100 萬目標、5 萬起始、5% 報酬：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e期限\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e每月需存\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e累計存入\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e5 年\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e13,761.01\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e825,660.32\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e10 年\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5,909.56\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e709,146.87\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20 年\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2,102.91\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e504,699.09\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e從 10 年拉到 20 年，每月需存從 5,910 降到 \u003cstrong\u003e2,103\u003c/strong\u003e，不到一半；而且\u003cstrong\u003e累計存入反而更少\u003c/strong\u003e，因為複利多了整整一倍的時間。\u003c/p\u003e","title":"每月該存多少錢才能達成目標？反過來算一下就清楚了"},{"content":"資產成長只有兩股力量 你的資產成長永遠來自兩個來源：你投入的錢，和已經在那裡的錢所產生的報酬。前期幾乎全靠前者，越往後後者越占主導——長期財富主要來自這個轉折點之後。\n單利是線性的：100 元按 7% 每年固定賺 7 元，永遠如此。複利是幾何的，因為每年的報酬是按「更大的基數」算出來的。差別就這一點，結果卻天差地遠。\n計算機用的公式 年末資產 = 年初資產 × (1 + 年化報酬率) + 當年投入 有兩個假設需要說明，因為它們會直接影響結果：\n報酬按「年初資產」計算——這正是複利的來源 當年投入按年末計入，從下一年才開始產生報酬——這是偏保守的假設。如果你是每月定期定額，實際結果會比預測略好 你可以用資產成長計算機自己跑一遍，全部在瀏覽器本機完成。\n一個具體例子：10 + 每年 10，報酬 7% 初始 10（可以理解成 10 萬），每年再投入 10，年化報酬 7%。\n年份 年初資產 當年報酬 當年投入 年末資產 1 10.00 0.70 10.00 20.70 2 20.70 1.45 10.00 32.15 3 32.15 2.25 10.00 44.40 4 44.40 3.11 10.00 57.51 5 57.51 4.03 10.00 71.53 6 71.53 5.01 10.00 86.54 7 86.54 6.06 10.00 102.60 8 102.60 7.18 10.00 119.78 9 119.78 8.38 10.00 138.16 10 138.16 9.67 10.00 157.84 十年下來你一共投入 100，最終拿到 157.84——其中 47.84 來自投資報酬，接近最終資產的三分之一。\n關鍵的第 11 年 第 1 年，報酬只有 0.70，而當年投入是 10，報酬只占成長的一小部分。到了第 11 年，當年報酬（11.05）首次超過當年投入（10.00）。\n從這一年起，複利從「零頭」變成了主引擎：即使你某一年完全不投錢，資產依然在漲。這才是長期持有的意義。\n72 法則 一個很好用的心算技巧：72 ÷ 年化報酬率 = 大約幾年翻倍。\n報酬率 翻倍所需年數 3% 約 24 年 7% 約 10.3 年 10% 約 7.2 年 它忽略了你後續的投入，但能快速建立直覺：3% 和 10% 的差距不是 3 倍，而是幾十年的差距。\n報酬率的小差別，長期是巨大的 同樣的條件（初始 10、每年投入 10），只是報酬率不同，跑 20 年：\n年化報酬率 最終資產 累計投入 來自報酬 5% 357.19 200.00 157.19 10% 640.02 200.00 440.02 投入完全一樣，結果差了將近一倍。這也是為什麼「每年只多 1% 的管理費」在 30 年維度上根本不是小事——它是在你的複利基數上持續抽成。\n最容易被忽略的：通貨膨脹 同樣每年投入 10，跑 30 年：\n假設 最終資產 名目報酬 10% 1,819.43 實際報酬 7%（10% 減約 3% 通膨） 1,020.73 差了一半。 如果你想知道這筆錢未來能買到什麼，要先把預期通膨從報酬率裡扣掉再填進去。\n會讓預測失效的四個假設 用名目報酬當購買力——一定要扣通膨 忽略稅費與費用——應稅帳戶裡這是持續性拖累 假設報酬平滑——市場不會每年穩定給 7%，中途一次 30% 回檔對行為的影響遠大於數學本身 假設投入永不中斷——失業、育兒、買房，多數人的儲蓄率並不穩定 這不是說預測沒用，而是說它更像是最好情況，按這個前提去讀就對了。\n怎麼用好這個計算機 填目前資產，不是目標金額 報酬率填保守值（規劃常用 5%～6% 實際報酬） 預期加薪就填「每年投入成長」 跑兩遍——5% 和 8% 各一次，按低的那次做規劃 每年重跑一次。它是指南針，不是承諾 去試試：資產成長計算機，完全在瀏覽器本機執行，不儲存、不上傳，離線也能用。\n常見問題 報酬率該填多少？ 全球股票指數長期年化大約 7%～10%（未扣通膨與稅），中間伴隨大幅回檔。做規劃時很多人用 5% 的實際報酬。最終應該填符合你自己資產配置的數字。\n每月定期定額要改嗎？ 不用改模型，把每年投入總額填進去即可；結果會略偏保守，因為每月投入其實更早開始複利。\n要算上勞退和房產嗎？ 可以，把它們的現值加到初始資產，把預期報酬併入報酬率。\n以後要提領怎麼算？ 先用這個工具算累積階段，再把最終數字當作「提領階段」的起始值單獨算。\n相關閱讀 房貸試算：本息平均攤還與本金平均攤還怎麼選 每月該存多少錢才能達成目標？ 全部線上工具 本文僅作科普，不構成任何投資建議。報酬率是假設值，請自行判斷。\n","permalink":"https://navshelf.com/zh-tw/posts/compound-interest-explained/","summary":"\u003ch2 id=\"資產成長只有兩股力量\"\u003e資產成長只有兩股力量\u003c/h2\u003e\n\u003cp\u003e你的資產成長永遠來自兩個來源：\u003cstrong\u003e你投入的錢\u003c/strong\u003e，和\u003cstrong\u003e已經在那裡的錢所產生的報酬\u003c/strong\u003e。前期幾乎全靠前者，越往後後者越占主導——長期財富主要來自這個轉折點之後。\u003c/p\u003e\n\u003cp\u003e單利是線性的：100 元按 7% 每年固定賺 7 元，永遠如此。複利是幾何的，因為每年的報酬是按「更大的基數」算出來的。差別就這一點，結果卻天差地遠。\u003c/p\u003e\n\u003ch2 id=\"計算機用的公式\"\u003e計算機用的公式\u003c/h2\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e年末資產 = 年初資產 × (1 + 年化報酬率) + 當年投入\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e有兩個假設需要說明，因為它們會直接影響結果：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e報酬按「年初資產」計算\u003c/strong\u003e——這正是複利的來源\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e當年投入按年末計入，從下一年才開始產生報酬\u003c/strong\u003e——這是偏保守的假設。如果你是每月定期定額，實際結果會比預測略好\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e你可以用\u003ca href=\"/tools/asset-growth-calculator/\"\u003e資產成長計算機\u003c/a\u003e自己跑一遍，全部在瀏覽器本機完成。\u003c/p\u003e\n\u003ch2 id=\"一個具體例子10--每年-10報酬-7\"\u003e一個具體例子：10 + 每年 10，報酬 7%\u003c/h2\u003e\n\u003cp\u003e初始 10（可以理解成 10 萬），每年再投入 10，年化報酬 7%。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e年份\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e年初資產\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e當年報酬\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e當年投入\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e年末資產\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e1\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e0.70\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e20.70\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e2\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e20.70\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e1.45\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e32.15\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e3\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e32.15\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2.25\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e44.40\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e4\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e44.40\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e3.11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e57.51\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e5\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e57.51\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e4.03\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e71.53\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e6\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e71.53\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5.01\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e86.54\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e7\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e86.54\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e6.06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e102.60\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e8\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e102.60\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e7.18\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e119.78\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e9\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e119.78\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e8.38\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e138.16\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e10\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e138.16\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e9.67\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e10.00\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003e157.84\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e十年下來你一共投入 \u003cstrong\u003e100\u003c/strong\u003e，最終拿到 \u003cstrong\u003e157.84\u003c/strong\u003e——其中 \u003cstrong\u003e47.84\u003c/strong\u003e 來自投資報酬，接近最終資產的三分之一。\u003c/p\u003e","title":"複利是怎麼滾起來的？用一張表算清資產成長"},{"content":"先說結論 如果你只有幾十個書籤、只用一個瀏覽器，瀏覽器內建的書籤列完全夠用，不需要額外工具。但只要出現下面任何一條，專業管理器就開始划算了：\n同時用好幾個瀏覽器，或者多台電腦加手機 找一個連結要超過 15 秒 資料夾已經變成「什麼都往裡丟」的雜物間 希望收藏能撐過一次瀏覽器設定重設 瀏覽器書籤的優點 別急著否定它，內建功能在幾件事上確實做得很好：\n零設定：本來就在那裡 同步：登入帳號，各裝置一致 快：存一個書籤只要一個快速鍵 整合：書籤列抬眼就能看到 對輕度使用來說，這就夠了。\n它不夠用的地方 結構扁平。 雖然能建資料夾，但過了幾百個之後側欄就是一堵滾動的牆，沒有多欄或檔案總管那樣的檢視。\n搜尋弱。 只能搜標題和網址，搜不了描述和自己寫的備註。\n沒有中介資料。 一筆書籤就是標題加網址，沒地方記「當初為什麼存它」。\n備份脆弱。 匯出的是 HTML：資料夾在、排序大致在、備註與標籤幾乎沒了。\n生態鎖定。 Chrome 的格式和 Firefox 不通，Edge 的「我的最愛」又是另一套，搬移就得匯出再匯入，結構會在過程中流失。\n隱私取捨。 開啟同步後，書籤存在瀏覽器廠商的帳號裡。\n專業管理器的優勢 以 NavShelf 為例，它把「檔案總管」這個比喻落到了實處：\n能力 瀏覽器內建 NavShelf 巢狀層級 有限、介面扁平 5 層目錄樹 拖曳 很弱 目錄與連結自由拖曳排序 右鍵操作 基礎 新增／編輯／刪除完整右鍵選單 搜尋 標題和網址 涵蓋整個收藏庫 自訂描述 ❌ ✅ 每條連結可寫說明 資料位置 廠商帳號（同步時） 只在你自己的瀏覽器 可攜備份 只有 HTML JSON，一鍵匯出 離線可用 ❌ ✅（離線單檔版可直接開啟） 介面語言 視瀏覽器而定 3 種語言 日常使用中最有用的差別，其實不是某個具體功能，而是結構始終可編輯。能隨手重排、改名的目錄樹，才會被持續維護。\n隱私這一面 如果你的書籤裡有公司後台、客戶連結，或任何不適合公開的內容，儲存方式就很重要：\n同步的瀏覽器書籤存在廠商伺服器上 本機優先的工具資料只留在瀏覽器裡，不上傳。NavShelf 把所有資料放在 localStorage，沒有伺服器也能運作，甚至可以直接開啟離線版 這不是多疑，和「財務筆記不放在共享磁碟」是同一個道理。\n怎麼搬移才不會掉東西 先把瀏覽器書籤匯出成 HTML 想試本機工具的話匯入 HTML，或者乾脆從零開始、只挑好的匯入——舊收藏裡通常躺著好幾年的死鏈 第一天就狠心刪：兩年沒開過的一律刪掉 建立習慣：每月匯出一次 JSON，放到有備份的地方 書籤列留給每天都會點的十個連結，兩套體系可以並存 什麼時候該留在瀏覽器書籤 收藏量小且穩定 只在同一台裝置的同一個瀏覽器上用 不在意備註和描述 接受廠商同步與廠商儲存 用更複雜的工具不會得獎。選剛好夠用的那個就好。\n常見問題 不用 Chrome 了書籤會丟嗎？ 不會，先匯出 HTML，再匯入下一個瀏覽器或管理器即可。\n瀏覽器和管理器能共用一份收藏嗎？ 不能自動共用。多數人的做法是：書籤列放少量常用連結，完整收藏放管理器裡。\n只有 200 筆書籤值得用管理器嗎？ 如果你找東西已經很費勁，那就值得；否則瀏覽器內建的資料夾樹大概夠用。\nNavShelf 支援多裝置同步嗎？ 不支援，這是有意的——它堅持本機優先，裝置間透過「關於」對話框裡的 JSON 匯出／匯入來搬移。\n相關閱讀 如何備份與還原瀏覽器書籤 如何整理瀏覽器書籤：7 個真正有效的方法 全部線上工具 ","permalink":"https://navshelf.com/zh-tw/posts/chrome-bookmarks-vs-bookmark-manager/","summary":"\u003ch2 id=\"先說結論\"\u003e先說結論\u003c/h2\u003e\n\u003cp\u003e如果你只有幾十個書籤、只用一個瀏覽器，瀏覽器內建的書籤列完全夠用，不需要額外工具。但只要出現下面任何一條，專業管理器就開始划算了：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e同時用好幾個瀏覽器，或者多台電腦加手機\u003c/li\u003e\n\u003cli\u003e找一個連結要超過 15 秒\u003c/li\u003e\n\u003cli\u003e資料夾已經變成「什麼都往裡丟」的雜物間\u003c/li\u003e\n\u003cli\u003e希望收藏能撐過一次瀏覽器設定重設\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"瀏覽器書籤的優點\"\u003e瀏覽器書籤的優點\u003c/h2\u003e\n\u003cp\u003e別急著否定它，內建功能在幾件事上確實做得很好：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e零設定\u003c/strong\u003e：本來就在那裡\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e同步\u003c/strong\u003e：登入帳號，各裝置一致\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e快\u003c/strong\u003e：存一個書籤只要一個快速鍵\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e整合\u003c/strong\u003e：書籤列抬眼就能看到\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e對輕度使用來說，這就夠了。\u003c/p\u003e\n\u003ch2 id=\"它不夠用的地方\"\u003e它不夠用的地方\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e結構扁平。\u003c/strong\u003e 雖然能建資料夾，但過了幾百個之後側欄就是一堵滾動的牆，沒有多欄或檔案總管那樣的檢視。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e搜尋弱。\u003c/strong\u003e 只能搜標題和網址，搜不了描述和自己寫的備註。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e沒有中介資料。\u003c/strong\u003e 一筆書籤就是標題加網址，沒地方記「當初為什麼存它」。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e備份脆弱。\u003c/strong\u003e 匯出的是 HTML：資料夾在、排序大致在、備註與標籤幾乎沒了。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e生態鎖定。\u003c/strong\u003e Chrome 的格式和 Firefox 不通，Edge 的「我的最愛」又是另一套，搬移就得匯出再匯入，結構會在過程中流失。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e隱私取捨。\u003c/strong\u003e 開啟同步後，書籤存在瀏覽器廠商的帳號裡。\u003c/p\u003e\n\u003ch2 id=\"專業管理器的優勢\"\u003e專業管理器的優勢\u003c/h2\u003e\n\u003cp\u003e以 \u003ca href=\"/app/\"\u003eNavShelf\u003c/a\u003e 為例，它把「檔案總管」這個比喻落到了實處：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e能力\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e瀏覽器內建\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eNavShelf\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e巢狀層級\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e有限、介面扁平\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5 層目錄樹\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e拖曳\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e很弱\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e目錄與連結自由拖曳排序\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e右鍵操作\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e基礎\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e新增／編輯／刪除完整右鍵選單\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e搜尋\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e標題和網址\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e涵蓋整個收藏庫\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e自訂描述\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅ 每條連結可寫說明\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e資料位置\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e廠商帳號（同步時）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e只在你自己的瀏覽器\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e可攜備份\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e只有 HTML\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eJSON，一鍵匯出\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e離線可用\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅（離線單檔版可直接開啟）\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e介面語言\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e視瀏覽器而定\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e3 種語言\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e日常使用中最有用的差別，其實不是某個具體功能，而是\u003cstrong\u003e結構始終可編輯\u003c/strong\u003e。能隨手重排、改名的目錄樹，才會被持續維護。\u003c/p\u003e","title":"瀏覽器內建書籤 vs 專業書籤管理器：到底該用哪個？"},{"content":"為什麼書籤最後總是一團亂 多數人都會遇到同一道牆：收藏了幾百個連結，兩年前建立的資料夾早就不符合現在的瀏覽習慣。存一個書籤只要一秒，找回來卻要兩分鐘。\n問題通常不是「資料夾不夠多」，而是這套結構從來沒有被設計過——它只是不斷累積的結果。以下 7 種方法能長期運作，由簡到繁排列。\n1. 扁平清單加標籤 所有書籤放在同一份清單，靠搜尋與標籤找。\n適合：收藏少於 200 個、習慣搜尋而非瀏覽的人。 失效點：超過幾百個之後標籤開始重疊，反而更難找。\n2. 三資料夾法則 只建立三個上層資料夾：近期（Now）、參考（Reference）、以後（Someday）。\n適合：想要一套完全不用傷腦筋的系統。每存一個連結只做一次判斷：這週要用、以後要用，還是大概永遠不會用。\n3. 依專案分類，而不是依主題 不要建立「設計 → 靈感 → 網站」這種無限延伸的主題樹，改用正在進行的事情當資料夾：「官網改版」、「2026 報稅」、「廚房裝修」。\n適合：工作有明顯階段性的人。專案結束後資料夾會自然淘汰，樹不會無限膨脹。\n4. 檔案總管式目錄樹 把書籤當檔案管理：多層巢狀，最多五層，每一層都有明確意義。\n導航 ├── 工作 │ ├── 文件 │ └── 工具 ├── 學習 │ ├── 語言 │ └── 程式 └── 娛樂 ├── 影片 └── 閱讀 NavShelf 用的就是這個模型：支援五層巢狀、拖曳移動、右鍵增刪改，結構隨時能調整，不會「定型之後就不敢動」。\n適合：收藏量在數百到數千、習慣用空間位置記憶的人。 注意：不要為了深度而深度。如果一個資料夾裡只有一個連結，它大概不該是資料夾。\n5. 收件匣機制 設一個叫 收件匣 的資料夾，新書籤一律先丟進去。每週清空一次：歸檔、刪除，或立刻處理掉。\n適合：收藏頻繁、討厭邊存邊分類的人。可以搭配上面任何一種方法。\n6. 把書籤變成公開資源庫 把收藏整理成可以分享的頁面——「我在用的工具清單」、閱讀清單、團隊資源頁。\n適合：收藏本身對別人有價值的人，順帶也能為自己帶來流量。\n7. 混合方案：目錄樹 + 收件匣 + 常用 真正能長期存活的都是混合體：\n一小撮每天真的會點開的常用書籤 一棵用於長期參考的目錄樹 一個存放新連結的收件匣 三個習慣，不是三十個。\n讓系統活下去的幾條規則 用說話的方式命名資料夾：「設計資源」勝過「設計→資源→連結（雜項）」。 上層不超過 5～7 個。深一點沒關係，寬了就會失控。 一個書籤只放一個地方。重複是混亂的主要來源。 每季整理一次。十五分鐘的修剪，抵得上一整個下午的手忙腳亂。 確保資料能帶走。匯出成 JSON，永遠不會被鎖死——NavShelf 支援一鍵匯入匯出，資料全部留在你自己的瀏覽器裡。 關於瀏覽器內建書籤 Chrome、Edge、Firefox、Safari 都有書籤管理器。日常夠用，但它們是扁平的、搜尋能力弱，多瀏覽器使用時還會各存一份。\n常見問題 書籤存多少算太多？ 沒有硬性上限。但如果你找一個連結要超過 15 秒，問題在結構，不在數量。\n該用資料夾還是標籤？ 需要瀏覽的用資料夾，只記得大概內容的靠標籤或搜尋。多數人兩者都需要。\n瀏覽器同步算備份嗎？ 不算。同步只是讓各裝置一致，誤刪會同步刪除，帳號出問題也會一起丟。\n想試目錄樹但不想搬資料？ 可以直接用 NavShelf 匯入 JSON，或從空目錄開始；它完全在瀏覽器本機執行，不會上傳你的書籤。\n","permalink":"https://navshelf.com/zh-tw/posts/how-to-organize-bookmarks/","summary":"\u003ch2 id=\"為什麼書籤最後總是一團亂\"\u003e為什麼書籤最後總是一團亂\u003c/h2\u003e\n\u003cp\u003e多數人都會遇到同一道牆：收藏了幾百個連結，兩年前建立的資料夾早就不符合現在的瀏覽習慣。存一個書籤只要一秒，找回來卻要兩分鐘。\u003c/p\u003e\n\u003cp\u003e問題通常不是「資料夾不夠多」，而是這套結構從來沒有被設計過——它只是不斷累積的結果。以下 7 種方法能長期運作，由簡到繁排列。\u003c/p\u003e\n\u003ch2 id=\"1-扁平清單加標籤\"\u003e1. 扁平清單加標籤\u003c/h2\u003e\n\u003cp\u003e所有書籤放在同一份清單，靠搜尋與標籤找。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適合\u003c/strong\u003e：收藏少於 200 個、習慣搜尋而非瀏覽的人。\n\u003cstrong\u003e失效點\u003c/strong\u003e：超過幾百個之後標籤開始重疊，反而更難找。\u003c/p\u003e\n\u003ch2 id=\"2-三資料夾法則\"\u003e2. 三資料夾法則\u003c/h2\u003e\n\u003cp\u003e只建立三個上層資料夾：\u003cstrong\u003e近期（Now）\u003c/strong\u003e、\u003cstrong\u003e參考（Reference）\u003c/strong\u003e、\u003cstrong\u003e以後（Someday）\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適合\u003c/strong\u003e：想要一套完全不用傷腦筋的系統。每存一個連結只做一次判斷：這週要用、以後要用，還是大概永遠不會用。\u003c/p\u003e\n\u003ch2 id=\"3-依專案分類而不是依主題\"\u003e3. 依專案分類，而不是依主題\u003c/h2\u003e\n\u003cp\u003e不要建立「設計 → 靈感 → 網站」這種無限延伸的主題樹，改用正在進行的事情當資料夾：「官網改版」、「2026 報稅」、「廚房裝修」。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適合\u003c/strong\u003e：工作有明顯階段性的人。專案結束後資料夾會自然淘汰，樹不會無限膨脹。\u003c/p\u003e\n\u003ch2 id=\"4-檔案總管式目錄樹\"\u003e4. 檔案總管式目錄樹\u003c/h2\u003e\n\u003cp\u003e把書籤當檔案管理：多層巢狀，最多五層，每一層都有明確意義。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e導航\n├── 工作\n│   ├── 文件\n│   └── 工具\n├── 學習\n│   ├── 語言\n│   └── 程式\n└── 娛樂\n    ├── 影片\n    └── 閱讀\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003ca href=\"/app/\"\u003eNavShelf\u003c/a\u003e 用的就是這個模型：支援五層巢狀、拖曳移動、右鍵增刪改，結構隨時能調整，不會「定型之後就不敢動」。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適合\u003c/strong\u003e：收藏量在數百到數千、習慣用空間位置記憶的人。\n\u003cstrong\u003e注意\u003c/strong\u003e：不要為了深度而深度。如果一個資料夾裡只有一個連結，它大概不該是資料夾。\u003c/p\u003e\n\u003ch2 id=\"5-收件匣機制\"\u003e5. 收件匣機制\u003c/h2\u003e\n\u003cp\u003e設一個叫 \u003cstrong\u003e收件匣\u003c/strong\u003e 的資料夾，新書籤一律先丟進去。每週清空一次：歸檔、刪除，或立刻處理掉。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適合\u003c/strong\u003e：收藏頻繁、討厭邊存邊分類的人。可以搭配上面任何一種方法。\u003c/p\u003e\n\u003ch2 id=\"6-把書籤變成公開資源庫\"\u003e6. 把書籤變成公開資源庫\u003c/h2\u003e\n\u003cp\u003e把收藏整理成可以分享的頁面——「我在用的工具清單」、閱讀清單、團隊資源頁。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e適合\u003c/strong\u003e：收藏本身對別人有價值的人，順帶也能為自己帶來流量。\u003c/p\u003e\n\u003ch2 id=\"7-混合方案目錄樹--收件匣--常用\"\u003e7. 混合方案：目錄樹 + 收件匣 + 常用\u003c/h2\u003e\n\u003cp\u003e真正能長期存活的都是混合體：\u003c/p\u003e","title":"如何整理瀏覽器書籤：7 個真正有效的方法"},{"content":"隱私權政策 最後更新：2025年1月1日\n資料儲存 所有資料儲存在本地瀏覽器的 localStorage 中 不傳送任何資料到任何伺服器 工具本身不包含任何分析或追蹤指令碼 我們不收集什麼 我們不收集任何個人資訊 我們不追蹤您的瀏覽習慣 我們不出售或分享任何資料 Google AdSense（僅限部落格頁面） 我們的部落格頁面可能顯示 Google AdSense 廣告。Google 使用 Cookie 根據您之前造訪我們網站或其他網站的情況來投放廣告。\n聯絡方式 📧 bonn202303@gmail.com\n","permalink":"https://navshelf.com/zh-tw/privacy/","summary":"\u003ch2 id=\"隱私權政策\"\u003e隱私權政策\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e最後更新：2025年1月1日\u003c/strong\u003e\u003c/p\u003e\n\u003ch3 id=\"資料儲存\"\u003e資料儲存\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e所有資料儲存在本地\u003c/strong\u003e瀏覽器的 localStorage 中\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不傳送任何資料\u003c/strong\u003e到任何伺服器\u003c/li\u003e\n\u003cli\u003e工具本身\u003cstrong\u003e不包含任何分析或追蹤\u003c/strong\u003e指令碼\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"我們不收集什麼\"\u003e我們不收集什麼\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e我們不收集任何個人資訊\u003c/li\u003e\n\u003cli\u003e我們不追蹤您的瀏覽習慣\u003c/li\u003e\n\u003cli\u003e我們不出售或分享任何資料\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"google-adsense僅限部落格頁面\"\u003eGoogle AdSense（僅限部落格頁面）\u003c/h3\u003e\n\u003cp\u003e我們的部落格頁面可能顯示 Google AdSense 廣告。Google 使用 Cookie 根據您之前造訪我們網站或其他網站的情況來投放廣告。\u003c/p\u003e\n\u003ch3 id=\"聯絡方式\"\u003e聯絡方式\u003c/h3\u003e\n\u003cp\u003e📧 \u003ca href=\"mailto:bonn202303@gmail.com\"\u003ebonn202303@gmail.com\u003c/a\u003e\u003c/p\u003e","title":"隱私權政策"},{"content":"NavShelf 是什麼？ NavShelf 是一個免費、開源的網頁導航管理器，像檔案系統一樣整理你的書籤。它幫助你用簡潔直觀的介面管理數百個已儲存的連結。\n功能特色 5 層巢狀目錄結構 拖曳排序 視覺化卡片預覽，自動生成縮圖 右鍵快捷選單 全文搜尋 JSON 匯入/匯出 深色/淺色主題 3 種語言支援（英、繁中、簡中） 立即試用 → 開啟 NavShelf\n意見回饋 📧 寄信給我們\n","permalink":"https://navshelf.com/zh-tw/about/","summary":"\u003ch2 id=\"navshelf-是什麼\"\u003eNavShelf 是什麼？\u003c/h2\u003e\n\u003cp\u003eNavShelf 是一個\u003cstrong\u003e免費、開源的網頁導航管理器\u003c/strong\u003e，像檔案系統一樣整理你的書籤。它幫助你用簡潔直觀的介面管理數百個已儲存的連結。\u003c/p\u003e\n\u003ch2 id=\"功能特色\"\u003e功能特色\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e5 層巢狀目錄結構\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e拖曳排序\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e視覺化卡片預覽\u003c/strong\u003e，自動生成縮圖\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e右鍵快捷選單\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e全文搜尋\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJSON 匯入/匯出\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e深色/淺色主題\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e3 種語言支援\u003c/strong\u003e（英、繁中、簡中）\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"立即試用\"\u003e立即試用\u003c/h2\u003e\n\u003cp\u003e→ \u003ca href=\"/app/\"\u003e開啟 NavShelf\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"意見回饋\"\u003e意見回饋\u003c/h2\u003e\n\u003cp\u003e📧 \u003ca href=\"mailto:bonn202303@gmail.com\"\u003e寄信給我們\u003c/a\u003e\u003c/p\u003e","title":"關於 NavShelf"}]