一款完全在客戶端執行、以瀏覽器為基礎的剪貼簿檢視器，對於需要檢查剪貼簿文字、卻不想自行撰寫或架設 Clipboard API 整合的開發者來說，是最實用的線上 API 替代方案。由 W3C 標準化的網頁 Clipboard API，要求 HTTPS、頁面必須處於聚焦狀態、需要使用者手勢，並且要取得明確授權——即使符合這些條件，瀏覽器仍可能因使用者設定、企業政策或內嵌頁面限制而拒絕這項呼叫。圍繞這個 API 建構一個除錯輔助工具，代表你得處理權限被拒的情況、同時支援讀取與貼上兩種備援路徑，並確保這個輔助工具不會在使用者不知情的狀況下，把他們複製的內容悄悄外洩出去。以本機為優先的檢視器則能繞開這些顧慮：當瀏覽器允許時，透過標準 API 讀取剪貼簿；當瀏覽器不允許時，就貼進文字方塊中，並在你輸入的同時，即時觀察字元數、Unicode 碼位、UTF-8 位元組長度、換行數、類似單字的詞元、空白字元，以及 JSON 是否有效。Clipboard Viewer正是採用這種模式——所有內容都留在目前的瀏覽器分頁中，不會上傳任何剪貼簿文字，分析結果也會立即呈現。
什麼時候不值得自己寫一套剪貼簿 API
大多數剪貼簿問題都是看不見的。畫面上看起來正確的值，可能藏著一個尾隨空格、一個與空格混用的定位字元、macOS 上多出來的一個 CR、隱藏的 U+200B 零寬空格，或是一個佔用兩個 UTF-16 碼元的補充平面表情符號。當一個正規表示式在正式環境中失效、一個環境變數拒絕載入，或是一個資料庫欄位拒絕接受你剛貼上的同一個字串時，第一個直覺反應就是去檢查原始位元組。要把這種檢查工作接到 W3C Clipboard API 上，代表需要一個小型程式碼庫，加上謹慎的權限處理：依照W3C Clipboard API and events規範，讀取流程受安全內容、聚焦狀態與使用者手勢三項條件把關，即便如此，瀏覽器仍然可能拒絕執行。
大多數開發者並不需要一個永久性的工具——他們需要的是一個快速的答案。線上剪貼簿檢視器已經實作好讀取路徑、貼上備援方案，以及各項指標的計算邏輯。這樣你就不必花一整個下午研究權限狀態、MDN 的Clipboard.readText()參考文件，以及像內嵌 iframe 沙箱這類邊緣情況。針對 Windows 特有的除錯流程，一篇關於在 Windows 上檢視剪貼簿文字的配套指南，會從平台的角度來說明同一個問題。
這款檢視器實際上量測了什麼
Clipboard Viewer 會回報七項不同的數值，而重點正是它們彼此並不能互換使用。下表列出每個指標、它計算的內容，以及為什麼在實際除錯過程中，這個結果可能會與其他指標出現落差。
| 指標 | 計算的內容 | 為什麼會出現落差 |
|---|---|---|
| 以 UTF-16 碼元計算的 JavaScript 字串長度 | 表情符號與補充平面字元各自佔用兩個碼元 | |
| 透過 Array.from 取得的實際 Unicode 碼位 | 更接近「人眼實際看到的內容」，但忽略了編碼大小 | |
| 經瀏覽器 TextEncoder 編碼後的位元組數 | 決定網路傳輸大小、檔案大小，以及許多 API 的限制 | |
| 以 LF、CRLF 或單獨的 CR 分割出的邏輯行 | 貼上的 Windows 片段，在 macOS 或 Linux 上可能算出不同的行數 | |
| 包含常見撇號、底線、連字號在內的 Unicode 字母與數字 | 偏實用取向，而非語言學取向——換一種斷詞器會得到不同的結果 | |
| 空格、定位字元、歸位字元與換行字元 | 隱藏的格式問題通常就是常見的臭蟲來源 | |
| 對去除前後空白後的文字執行嚴格的 JSON.parse | 只檢查語法本身——不檢查欄位語意或結構描述 |
每一列的數值都是即時計算，使用瀏覽器原生的功能：以 TextEncoder 計算 UTF-8 大小、以 Array.from 取得 Unicode 碼位、用明確的 CRLF/CR/LF 分割器計算行數、以能辨識 Unicode 的詞元正規表示式計算字數，並以 JSON.parse 進行語法分類。所有內容都不會離開這個頁面。
四個步驟檢查剪貼簿文字
- 點一下「讀取剪貼簿」並同意瀏覽器彈出的提示，或直接把文字貼進編輯區。如果瀏覽器因任何原因拒絕讀取，貼上這條路徑仍然可用——被拒絕會被視為「改用貼上」，而不是資料遺失。
- 並排比較字元數、碼位數、UTF-8 位元組數、行數、字數、空白字元數與 JSON 結果。大多數剪貼簿相關的問題，都會表現為這些計數之中兩項之間的落差。
- 當隱藏格式可能是問題所在時，開啟「顯示空格、定位字元與換行符號」。空格會顯示為置中的圓點，定位字元會顯示為箭頭，換行則會顯示為可見的符號，而底層編輯區的實際值不會因此改變。
- 檢查完成後清空編輯區，尤其是當文字內容包含敏感資訊時。剪貼簿可能存有密碼、權杖、客戶資料或私密金鑰，而你所使用的工具未必會察覺到這一點。
當字元數、碼位數與 UTF-8 位元組數彼此不一致時
字元數與碼位數之間的落差，是最常見的意外情況。JavaScript 的字串長度計算的是 UTF-16 碼元，因此字串「😀」回報的長度是 2，但它其實是單一個 Unicode 碼位。每當你要依照資料庫 VARCHAR 上限、文字方塊的 maxlength，或是以碼位計算字元數的下游 API 來驗證使用者輸入時，這種補充平面的情況就會造成影響。UTF-8 位元組長度則與上述兩者都無關：同一個表情符號會佔用 4 個 UTF-8 位元組，因此一個「4 個字元」的表情符號字串，以碼位計算是 4 個字元，以 JavaScript 長度計算是 8，以 UTF-8 位元組計算則是 16 位元組。
這種落差並不是損壞——而是編碼機制的現實。這款工具會如實呈現這一點，不偏袒任何一方。把一個包含非 ASCII 字母加上一個補充平面表情符號的字串貼進編輯區，檢視器會回報三個不同的總數，因為這個字串同時包含一個多位元組的 UTF-8 序列，以及一個 4 位元組的補充字元。確切的數字會由即時計數器算出；這裡想說明的重點是定性的：三項指標、三個答案，卻沒有一個是錯的。
行數計算規則同樣是明確定義的：LF、CRLF，以及單獨出現的 CR，都會被識別為換行符號。這與大多數編輯器、日誌分析工具與 shell 工具實際的做法一致，這也是為什麼一旦你了解這條規則，在 Windows、macOS 與 Linux 之間比較剪貼簿文字，就能得到一致的結果。
JSON 有效性、隱形字元與隱私
JSON 指標會對去除前後空白後的值，執行嚴格的 JSON.parse。綠燈只代表這段文字在語法上是有效的 JSON——並不代表它的欄位是安全的，也不代表它的網址可以正常連線，更不代表它符合你所預期的結構描述。這款工具不會修復 JSON、不會執行程式碼、不會跟隨連結，也不會解讀貼上的 HTML 內容。如果你需要依結構描述進行的結構化驗證，可以另外使用專門的JSON Validator或JSON Formatter來處理。
隱形字元的檢查，是另一個主要的使用情境。一段複製而來、含有不斷行空格的 shell 指令，在 bash 中會執行失敗，卻不會給你任何肉眼可見的提示。由空格與定位字元混用構成的 YAML 縮排，可能會塌縮成一個空的對映結構。從一個作業系統匯出、在另一個作業系統匯入的 CSV 資料列，可能帶有多餘的 CR，破壞資料列的計數結果。把空格顯示為置中圓點、定位字元顯示為箭頭、換行顯示為可見符號，能把這些無聲的失敗變得顯而易見，同時不會更動編輯區裡的實際值。
隱私是這款工具設計上的核心考量。分析工作全部在目前分頁中於本機執行，不會有任何剪貼簿文字被送往 Lizely 伺服器，而清空編輯區也會把元件狀態中暫存的內容一併移除。這款工具只讀取文字——不會取用剪貼簿中的圖片、格式化 HTML、檔案，或平台專屬的格式。如果瀏覽器因政策或權限狀態而拒絕授予剪貼簿存取權，手動貼上這條路徑仍能維持整個流程可用。輸入的內容量也有上限，避免不小心貼上超大量文字導致介面卡住，這在除錯工具中比在正式環境工具中更為重要。
一款剪貼簿檢視器本身不應該變成另一個剪貼簿外洩管道，這是最基本的底線，而 Clipboard Viewer 藉由絕不傳送它所檢查的文字，做到了這一點。Clipboard Viewer 是一款檢查工具，不是安全機密掃描器、惡意程式偵測器，也不是合規系統，因此在使用這個流程時，應該搭配你在貼東西到任何其他開發者工具時，本來就會採取的謹慎態度。
如需更深入的說明，請參閱 Text to HTML Paragraphs API Alternative in the Browser。