網頁資料儲存方案

 你說的非常對！chrome.storage.local 是 Chrome 擴充功能專用的儲存 API。對於一般的網頁，確實有幾種不同的客戶端儲存方案，其中 Cookie 是最老牌的一種，但現在有更好、更常用的選擇。

以下是一般網頁常用的客戶端儲存技術：

  1. Cookies (HTTP Cookies):

    • 用途：最初設計用於伺服器和客戶端之間傳遞狀態資訊 (例如：使用者登入狀態、購物車內容、追蹤使用者行為)。

    • 運作方式：由伺服器透過 HTTP Header (Set-Cookie) 發送到瀏覽器，瀏覽器儲存後，在之後的每次請求到同一網域時，都會自動將 Cookie 透過 HTTP Header (Cookie) 帶上發送給伺服器。

    • 容量：非常小，通常每個 Cookie 約 4KB，且每個網域的 Cookie 數量也有限制。

    • 存取：JavaScript 可以透過 document.cookie 讀寫 (除非設定了 HttpOnly 旗標，這樣就只能由伺服器讀寫)。伺服器端程式碼可以直接讀取 HTTP Header 中的 Cookie。

    • 生命週期：可以設定過期時間 (expires/max-age)。如果沒有設定，就是會話 Cookie (session cookie)，瀏覽器關閉即失效。

    • 缺點：

      • 容量小。

      • 每次 HTTP 請求都會攜帶，即使某些請求完全不需要這些 Cookie，也會增加網路流量和請求大小，影響效能。

      • API 操作不方便 (document.cookie 是一個字串，需要手動解析和設定)。

    • 適合場景：儲存少量、需要在伺服器和客戶端之間共享的狀態資訊，如身份驗證 token、使用者偏好設定 (例如主題)。

  2. Web Storage API (HTML5):
    這是現代網頁更常用的客戶端儲存方案，它提供了更大的儲存容量，且不會自動隨 HTTP 請求發送。它包含兩種：

    • localStorage:

      • 用途：在客戶端持久儲存鍵值對數據。

      • 容量：比 Cookie 大得多，通常每個來源 (origin，即協議+主機名+端口) 約 5MB - 10MB。

      • 存取：只能透過 JavaScript 存取 (localStorage.setItem('key', 'value'), localStorage.getItem('key'), localStorage.removeItem('key'), localStorage.clear())。

      • 生命週期：永久儲存，除非使用者手動清除瀏覽器快取/資料，或網頁透過 JavaScript 主動刪除。關閉瀏覽器或分頁不會影響儲存的資料。

      • 作用域：同源策略限制，即同一個來源的頁面可以共享相同的 localStorage。

      • 優點：容量較大，API 簡單易用，數據不會隨 HTTP 請求發送。

      • 缺點：

        • 只能儲存字串。如果要儲存物件，需要先用 JSON.stringify() 轉換成字串，讀取時用 JSON.parse() 轉回來。

        • 同步操作，如果在主執行緒進行大量讀寫可能會阻塞 UI。

        • 不適合儲存敏感資料，因為容易被 XSS 攻擊讀取。

      • 最接近 chrome.storage.local 的方案：在持久性、僅客戶端存取、鍵值對儲存方面，localStorage 是最像擴充功能 chrome.storage.local 的。

    • sessionStorage:

      • 用途：在客戶端儲存當前會話 (session) 的鍵值對數據。

      • 容量：與 localStorage 類似，約 5MB - 10MB。

      • 存取：只能透過 JavaScript 存取 (API 與 localStorage 完全相同，只是把 localStorage 換成 sessionStorage)。

      • 生命週期：僅限當前瀏覽器分頁/視窗的生命週期。當分頁或視窗關閉時，sessionStorage 中的資料會被清除。即使是同一個網站在不同分頁打開，它們的 sessionStorage 也是獨立的。

      • 作用域：同源策略限制，但僅限於當前分頁。

      • 優點/缺點：與 localStorage 類似，但生命週期不同。

      • 適合場景：儲存臨時性的、只在當前瀏覽會話中有效的資料，例如表單中已填寫的內容 (防止使用者意外關閉分頁後遺失)，或一次性提示的狀態。

  3. IndexedDB API:

    • 用途：在客戶端儲存大量結構化數據，提供類似資料庫的功能。

    • 容量：非常大，通常只受限於使用者的硬碟空間 (瀏覽器會有提示請求更多空間)。

    • 存取：只能透過 JavaScript 存取。API 相對複雜，是基於交易 (transaction) 的非同步操作。

    • 生命週期：永久儲存，除非使用者或網頁主動清除。

    • 作用域：同源策略限制。

    • 優點：

      • 可以儲存大量數據，包括 JavaScript 物件、檔案、Blob 等。

      • 支援索引，可以高效查詢數據。

      • 非同步操作，不會阻塞主執行緒。

    • 缺點：API 較為複雜，學習曲線較陡峭。

    • 適合場景：需要離線功能的複雜 Web 應用 (PWA)、需要儲存大量數據的應用 (例如郵件客戶端、內容管理工具的草稿等)。

總結與選擇：

特性CookieslocalStoragesessionStorageIndexedDB
主要用途伺服器與客戶端狀態同步、追蹤客戶端持久鍵值儲存客戶端會話期鍵值儲存客戶端大型結構化數據庫
容量~4KB~5-10MB~5-10MB非常大 (GBs+)
生命週期可設定過期，否則為會話永久 (除非手動/程式清除)當前分頁/視窗關閉即清除永久 (除非手動/程式清除)
HTTP請求自動攜帶不攜帶不攜帶不攜帶
APIdocument.cookie (字串操作)localStorage.setItem/getItem 等 (簡單)sessionStorage.setItem/getItem 等 (簡單)複雜的非同步 API
數據類型字串字串 (物件需序列化)字串 (物件需序列化)多種 (物件, Blob, 檔案等)
操作方式同步 (JS端)同步同步非同步
最像chrome.storage.local是

一般來說，對於類似擴充功能中 chrome.storage.local 的需求 (在客戶端持久儲存一些設定或資料，且不需要伺服器頻繁讀取)，localStorage 是最常用的替代方案。

如果你只需要在單個瀏覽會話期間儲存數據，則使用 sessionStorage。
如果你需要儲存大量結構化數據或實現離線功能，則考慮 IndexedDB。
Cookie 則更多用於需要伺服器參與的狀態管理。

留言

張貼留言

這個網誌中的熱門文章

Offscreen Canvas

 你說得完全正確！這是一個非常經典的效能最佳化思路。如果尖刺框的參數沒有改變，重複計算所有尖刺的路徑和幾何形狀確實是一種浪費。 有幾種方法可以「記憶」或快取你畫的尖刺框，避免不必要的重繪計算： 快取到一個離屏 Canvas (Offscreen Canvas) - 最推薦的方法 原理 ：創建一個與主 Canvas 大小相同（或者只需要能容納尖刺框的大小）的隱藏 Canvas。當尖刺框的參數改變時，或者第一次繪製時，將完整的尖刺框（包括尖刺和中間的填充橢圓）繪製到這個離屏 Canvas 上。 後續繪製 ：在主 Canvas 的每一幀渲染時，如果尖刺框的參數沒有改變，你只需要使用 ctx.drawImage() 將離屏 Canvas 的內容直接繪製到主 Canvas 的目標位置即可。這遠比重新計算和繪製所有尖刺要快得多。 優點 ： 效能提升顯著， drawImage 非常快。 代碼結構清晰，繪製邏輯和快取邏輯分離。 可以快取包含複雜效果（如漸層、陰影等）的圖形。 缺點 ： 需要額外的記憶體來儲存離屏 Canvas。對於大多數尖刺框來說，這通常不是問題。 如果尖刺框需要動態改變大小或位置，離屏 Canvas 的管理（重新創建或調整大小）需要考慮。 快取路徑指令 (Path2D Object) - 適用於路徑本身 原理 ： Path2D 物件可以儲存一系列的 Canvas 路徑指令（ moveTo , lineTo , ellipse , bezierCurveTo 等）。當尖刺框的參數改變時，你構建一個或多個 Path2D 物件來代表尖刺框的各個部分（例如，一個 Path2D 給中心橢圓，另一個給所有尖刺的集合）。 後續繪製 ：如果參數未變，你可以直接使用 ctx.fill(cachedPath) 或 ctx.stroke(cachedPath) 來繪製已儲存的路徑。 優點 ： 比重新執行所有 moveTo/lineTo 更快一些，因為路徑已經編譯好了。 記憶體佔用可能比離屏 Canvas 小。 缺點 ： Path2D 只儲存路徑，不儲存樣式（顏色、線寬等）。你仍然需要在繪製時設定 ctx.fillStyle , ctx.strokeStyle , ctx.lineWidth 。 對於你用 drawTaperedLine 繪製的填充錐形尖刺，...
閱讀完整內容

外部網頁新增 Google 日曆行程(URL模板)

  好的，從外部網頁新增 Google 日曆行程，最常用且最簡單的方法是使用 Google Calendar Event Publisher Guide 提供的 URL 模板 。這種方法不需要複雜的 API 整合或使用者授權流程 (OAuth)，只需要產生一個特殊格式的連結即可。 使用者點擊這個連結後，會被導向到他們自己的 Google 日曆，並看到一個預先填好資訊的新增行程頁面，他們只需要確認並儲存即可。 以下是詳細步驟和說明： 方法：使用 Google 日曆事件發布連結 (URL Template) 基本 URL 結構： https: //www.google.com/calendar/render?action=TEMPLATE 添加參數以預填行程資訊： 在基本 URL 後面加上 & 和 參數名稱=參數值 來指定行程細節。重要的參數包括： text : 行程標題 (必填) 。 範例： &text=團隊會議 dates : 行程開始和結束時間 (必填) 。格式非常重要，必須是 ISO 8601 格式，且 強烈建議使用 UTC (世界標準時間) ，以避免時區混淆。 特定時間格式： YYYYMMDDTHHMMSSZ/YYYYMMDDTHHMMSSZ (Z 表示 UTC) 範例 (2024年7月26日 UTC 下午 2:00 到 3:00)： &dates=20240726T140000Z/20240726T150000Z 全天事件格式： YYYYMMDD/YYYYMMDD (結束日期是 不包含 的那一天的日期，所以通常是開始日期加一天) 範例 (2024年7月27日全天)： &dates=20240727/20240728 location : 行程地點 。 範例： &location=台北101會議室 details : 行程說明或備註 。可以包含換行符號 ( \n )。 範例： &details=討論下一季專案規劃。\n請攜帶筆記型電腦。 sprop : 來源網站資訊 (可選，但建議加入)。 範例： &sprop=name:我的網站名稱&sprop=url:https://www.mywebsite.com add : 邀請的賓客 Email (可選)...
閱讀完整內容

批次rename

將 0_1.png 重新命名為 001.png  和  將 0_11.png 重新命名為 011.png Get-ChildItem "*_*.png" | ForEach-Object { $parts = $_ .Name.Split( '_' ) if ( $parts .Length -eq 2) { $prefix = $parts [0] $number = $parts [1].Replace( ".png" , "" ) $newName = "{0}{1:D2}.png" -f $prefix , [int] $number Rename-Item -Path $_ .FullName -NewName $newName } } 指令解說： $parts = $_.Name.Split('_') ：將檔名  0_1.png  用  _  分割成  0  和  1.png  兩部分。 $number = $parts[1].Replace(".png", "") ：取得數字部分，並移除副檔名。 "{0}{1:D2}.png" -f $prefix, [int]$number ：這是最關鍵的一步。 -f  是 PowerShell 的格式化運算子。 {0}  代表第一個變數 ( $prefix )。 {1:D2}  代表第二個變數 ( [int]$number )， D2  的意思是以 整數 (Decimal)  格式輸出，且固定為  2 位數 (2-digits) ，如果不足，左邊會自動補 0。 這行指令會將  0  和  1  組合並格式化成  001.png ，將  0  和  11  組合格式化成  011.png 。 使用 PowerShell (Windows 內建，功能最強) PowerShell 是 Windows 內建的現代化命令列工具，處理這類任務非常靈活且安全。 操作步驟：...
閱讀完整內容