Posts

前言 隨著 AI 技術的快速發展，AI Agent（智慧代理）已經不再只是聊天機器人，它們開始具備幫我們「執行網頁任務」的能力，例如：幫忙訂機票、比價、甚至是填寫複雜的報帳系統。 不過在過去，AI Agent 若要操作網頁，通常得依靠截圖分析 (Computer Vision) 或是解析原始 DOM 結構 (Screen Scraping) 來找到頁面上的元素。這些方法不但效率低落、耗費大量計算資源，而且非常脆弱：只要網頁的 UI 稍微改版（改個 class name 或換個按鈕顏色），Agent 就可能找不到目標元素而操作失敗。 為了從根本上解決這個問題，一項全新的網頁標準 —— WebMCP (Web Model Context Protocol) 誕生了。它由 W3C Web Machine Learning Community Group 孵化，並獲得 Google 與 Microsoft 的大力推動。本篇文章將帶大家認識 WebMCP 的核心概念與運作原理，並透過兩個實際的 Demo 來體驗如何讓現有的網頁變得 Agent-ready。 💡 小提醒：WebMCP 目前（2026 年初）仍處於早期預覽階段，需要在 Chrome 146 Canary 開啟特定 Flag 才能使用原生支援，但我們可以使用 @mcp-b/global polyfill 在開發階段進行測試。 什麼是 WebMCP？ WebMCP (Web Model Context Protocol) 是一個瀏覽器原生 (Native Browser API) 的標準協議，主要是讓前端開發者可以用結構化、標準化的方式，將網頁的功能（Tools）「自我宣告」並暴露給 AI Agent。...

前言 現代網站開發流行前後端分離的開發模式，前端通常使用 JavaScript 框架如 ReactJS, VueJS 或 AngularJS 來實作 UI 的呈現與渲染，而後端主要使用 RestFul 或 GraphQL 等方式來提供 API 給前端串接。 但專案開發需求時程通常都是又急又需要快速完成，前端工程師如果要等到後端把 API 完成後再來實作就可能會耽誤到 UI 的開發，所以常見的做法會是前後端討論完 API 的規格後 (包含輸出的資料格式與範例)，前端這邊會使用 Mock Data 來模擬後端 API 的輸出，然後來整合前端的程式。 各個軟體框架或是第三方套件 (如: Mock.js) 都有提供 Mock Data 的實作方式，然而在實務上這也衍生了 Mock Data 管理的問題，例如在執行原始碼版控時可能將 Mock 資料也推到公用版控主機，或是 Bundle 輸出 js 檔時，都可能把 Mock 資料也包進產出的 js 檔案中，如果 Mock 資料有包含機敏資料，就有外洩的可能。 所以本文介紹使用 Chrome 瀏覽器的開發者工具來進行 API Mock，除了讓 Mock 資料與專案原始碼脫鉤 (decouple)，也可以避免原本的前端專案資料夾過於雜亂，各個流程的 Mock 資料也可以另外進行版控，或是拿來用在 e2e 測試程式中，感覺起來是相對優雅而乾淨的做法。 第一步: 使用 The Dog API 建立一個範例專案 The Dog API 是由 That API Company 這間專門從事 API 開發的國際性公司所開發的 API，主要是提供給新手工程師練習串接 API 使用，我們會使用 The Dog API 來建立一個範例的前端程式。...

前情 先前我們介紹了如何實作一個 Tooltips 的 WebComponenet 元件， 今天我們來說明如何將我們辛苦寫好的 UI 元件模組化並上傳到 NPM 套件庫， 方便之後可以重複使用。 模組化 在先前 CodePen 的範例中， 其實我們就使用了 立即調用函式 IIFE (Immediately Invoked Function Expression) 的方式來宣告我們的 Custom Element。 使用 IIFE 來執行模組化除了可以在網頁載入時執行我們定義的函式外，也可以透過局部作用域的創建來避免變數汙染與命名衝突等問題， 是前端模組化常常使用的模式，他的基本語法如下: 1 2 3 (function () { // 要執行的程式碼 })(); 而宣告與定義一個 WebComponent 主要是使用 window.customElements.define 來宣告我們自定義的 HTML 標籤，所以語法會像下面這樣: 1 2 3 4 5 6 7 8 9 // my-tag.js (function () { window.customElements.define( "my-tag", class extends HTMLElement { // 定義 Custom Element 參數、行為等 } ); })(); 完成上述的 IIFE 的程式碼後，我們可以將這段程式碼儲存在一個自訂的檔案，如: my-tag....

先前我們介紹了關於 WebComponents 以及他的三大核心內容，這裡我們要透過一個實際的案例來建立一個 Tooltip UI 元件，來進一步熟悉 WebComponent 的實作方式。 在這篇文章中我們會先在頁面的 html 使用 template，然後定義一個 CustomElement 來簡單實作 WebComponent。 後續在另外的章節，我們會再介紹如何將我們實作的 WebComponent 模組化並上傳到 CDN 上供直接使用。 Tooltips 元件 Tooltips 元件是指當滑鼠移到特定網頁元件上，上方或指定方向會跳出一個泡泡提示窗並帶有提示內容文字或是 HTML 內容，可參考下圖: 圖片來源: 維基百科 元件設計 在實作一個 Tooltips，我們會希望: 可以在指定元件上方出現泡泡。 泡泡內可以帶入指定文字或 HTML。 泡泡提示窗可以帶一個箭頭指向指向目標內容元件。 當泡泡提示窗在網頁邊緣顯示時，可以自動往網頁中心內縮，避免超出網頁內容區。 那要使用 WebComponent Custom Elements 來實作 Tooltips 元件，我們先假定實作的 html tag 叫做 my-tooltip，如果要在一個圖片上加上提示窗，希望語法會是: 1 2 3 4 <my-tooltip alt="這是一張圖片"> <div n></div> <img src="a.jpg" /> </my-tooltip> 而希望畫面呈現出來會像這樣: 而如果要使用 HTML 當作提示窗的內容，則希望語法會是像這樣: 1 2 3 4 5 6 7 8 9 <my-tooltip> <!...

前言 在學會使用 WebComponent 的相關技巧後，陸陸續續也實作了不少的 UI 元件， 方便後續在進行前端專案的時候可以快速的重複使用。 而且不管您的專案是使用 VueJS、ReactJS 或者Angular， 都可以支援原生的 WebComponent，所以等於是一個通用的軍火庫， 寫一次就可以 Use everywhere，所以非常推薦將您常用的 UI 元件寫成 WebComponent 版本。 下面整理我目前有實作開源的 WebComponent 元件，後續如果有新做的 WebComponent 元件， 也會繼續更新上來，如果使用上有問題也歡迎發 issue 給我，謝謝 😊 小型輕量的 WebComponents 元件庫 項次 WebComponent 元件 安裝 / 原始碼 1 WebComponent Demo | swipe-to-refresh A WebComponent to pull the window down and refresh. 2 WebComponent Demo | mic-input Speech input WebComponent implemented with Web Speech API. 3 WebComponent Demo | star-input Star rating input implemented with WebComponent....

介紹 Angular Components、ReactJS Components、VueJS Components 通通都有，就是沒有屬於 VanillaJS 的 Components，所以今後只好自己創造 (大誤)。 其實早在 2011 年， Web Components 的概念就已經被提出，除了希望可以建立重複使用的 Web UI 元件外，也帶入了封裝的概念，如透過 Shadow DOM 的引入以封裝 Custom Element 的 CSS 樣式，避免互相污染，另外透過 Custom Element 中自定義的行為來達到功能上的封裝與重用性。 上面提到 Shadow DOM 、 Custom Elements，另外還有 HTML Template 為 Web Components 主要的三個核心內容，以下我們就分別介紹這三項核心內容。 Custom elements Custom elements 透過原生 JavaScript APIs 來自定義客製化 HTML 標籤，包含它的 attributes、properties與 events 等，方便依照網站設計的客製化需求來使用。 1 2 3 4 5 6 class MyCustomElement extends HTMLElement { ... } // 定義 Custom element window....

介紹 現代人由於工作、娛樂目的而長時間使用像是手機、電腦等 3C 產品，時間久了往往會造成眼睛疲勞不適，因此現在的網頁或 APP 介面往往會提供深色模式或是夜間模式，除了可以減少裝置電量的消耗，也可以減少光線對眼睛的刺激。 因此在前端網頁上實作亮色、深色模式也變成了提升使用者閱讀體驗所不可缺少的設計之一，因此，以下我們將說明如何透過 CSS 原生的 color-scheme 屬性來建置同時支援亮色 / 深色模式的網頁。 使用者代理樣式表 (User agent stylesheet) 使用者代理樣式表 (或有人翻譯作瀏覽器預設樣式表)，為瀏覽器針對原生 html 元件像是文字、輸入框或按鈕等預設的樣式。 以下我們撰寫了一個簡單 html 頁面，其中包含了一個 <h1> 元件: 1 2 3 4 5 <html lang="en"> <body> <h1>hello</h1> </body> </html> 在 Edge 瀏覽器中打開後，使用 devtool 觀察樣式可以看到下列的樣式，這個就是套用了瀏覽器預設的樣式表中關於 <h1> 元件的樣式。 1 2 3 4 5 6 7 8 9 h1 { display: block; font-size: 2em; margin-block-start: 0.67em; margin-block-end: 0.67em; margin-inline-start: 0px; margin-inline-end: 0px; font-weight: bold; } 除了對於各個 html 元件提供預設的樣式表之外，現在的主流瀏覽器也提供各元件在深色模式下的樣式表，而我們可以透過 color-scheme 來啟用它。...

Google、Apple、微軟及數百間科技公司或服務商在今年 (2022) 不約而同的表態支持 FIDO 聯盟與 W3C 所主推的通用無密碼登入標準 (common passwordless sign-in standard)，希望能透過例如指紋、Face ID等認證手段替代原本的密碼登入機制，提供用戶在網頁登入時一個更安全、防網路釣魚、即時交易驗證的登入方式。 Google 在今年10月上旬宣布在 Android 及 Chrome 導入 Passkey 無密碼認證機制，而 Apple 也將在 iOS 16 和 macOS Ventura 引入 Passkey ，透過掃描 QR Code 加上藍芽或其他裝置通訊技術，讓你可以透過手機的 Touch ID 或 Face ID 就可以登入你所有的電腦、平板等裝置。 下面我們會先說明需要使用密碼跟無密碼認證使用的場景，再深入介紹實務上使用 FIDO2 進行註冊與認證 (含範例程式)，最後再總結 FIDO2 / WebAuthn 與 Passkey 的關係 。 通常需要用到 ”密碼” 或 ”認證” 的場合，像是在電商網站買東西、下訂單最後要結帳的時候會請你輸入帳號、密碼做登入(不登入的話也可能會要求你透過手機簡訊驗證碼做實名制驗證)，可以用以確保您在真實世界的身分。 在資訊安全的領域中，不管是帳號密碼或是手機簡訊驗證碼的驗證，都是屬於 挑戰回應(Challenge/Response) 的方法。 挑戰回應 的方法具體來說，是指由正在溝通的兩方其中之一發起一個 挑戰 (Challenge)，而另一方提供一個正確可被驗證的合法答案 (Response)。 最常見的使用情境就是使用密碼驗證，比方說在電商網站購物前送出訂單之前請買家在網頁上再輸入一次密碼，如果密碼正確 (Valid response) ，則可以確認是由本人進行的操作。 但使用密碼作為驗證手段所衍生出的資安議題非常多，比方說網站管理者可能為了安全性而要求用戶使用的密碼複雜度必須足夠，但過於複雜的密碼常常會讓使用者記不起來，所以就寫在便條紙、記在手機備忘錄或存在檔案中，造成密碼洩漏的問題，而這也是 Apple, Google 及 Microsoft 三大廠商都主推無密碼認證的原因之一。...

在早期，密碼學(Cryptography)是泛指隱藏訊息(hiding information)的方法，背後相關的知識包含數學、電腦科學(Computer science)及工程學等等，但時至今日，密碼學除了隱藏訊息之外，也同樣注重資訊安全屬性中的資訊完整性與不可抵賴性。 資訊完整性可透過驗算訊息驗證碼(如雜湊值或 checksum 等)來確認訊息沒有被人竄改過，而不可抵賴性則可以透過數位簽章的方式來驗證，下面來詳細說明。 加密演算法介紹 加密演算法是指訊息交換的雙方透過約定的密鑰(key)對訊息加密，原始的訊息(明文，plaintext)經過加密後會變成密文(cyphertext)，密文只有透過密鑰才可以還原回可閱讀的明文，因此可以放心透過網路或其他方式進行傳輸。 根據密鑰的特性一般可分作 對稱式加密演算法 及 非對稱式加密演算法，非對稱式加密演算法是指訊息傳遞者會產生一對 公鑰(public key) 及 私鑰(private key)。 1. 對稱式加密演算法 訊息交換雙方共享一組密鑰(key)，這密鑰就相當於兩人共享的秘密(shared secret)，沒有第三者知道。 當訊息要由A君傳送給B君時，A君會使用共享的密鑰對訊息進行加密，然後將加密後的密文傳遞給B君，B君再透過兩人共享的密鑰對密文進行解密，就可以取得明文的內容。 目前常見的對稱式加密演算法有一般網頁瀏覽時SSL/TLS加密使用的AES加密演算法，在 SSL/TLS handshake 時，瀏覽器跟網站伺服器間會協商出一個本次瀏覽期間使用的共享密鑰，在這次瀏覽期間使用的網頁封包都會透過這組密鑰進行加密。 2. 非對稱式加密演算法 明文透過公鑰加密變成密文後，需要透過對應的私鑰進行解密才能還原回明文；相反的，如果明文是透過私鑰進行加密變成密文，則需要透過對應的公鑰進行解密才能還原成明文。 圖片來源: 維基百科 而公私鑰的保存依照字面上的意思，私鑰需要由訊息傳遞者自己保存好，不能被別人知道(用以確保訊息是本人發送)，而公鑰顧名思義則是需要公開給所有人知道，一般的應用會透過可信任的第三方來保管所有訊息傳遞者的公鑰，比如政府的自然人憑證或健保卡憑證都是由政府建置所謂的公開金鑰基礎建設 (英語：Public Key Infrastructure，縮寫：PKI)，透過 PKI ，我們就可以取得使用者的的公鑰來解密訊息。 而上面我們提到非對稱式加密演算法的加解密特性與公私鑰的保管性質，就可以進行 數位簽章(確保是本人) 與 訊息保密 的動作。 數位簽章： 透過私鑰對訊息進行加密後傳送，所有人都可以透過在PKI取得訊息傳遞者的公鑰，如果解密可以成功就代表是本人傳送的(因為私鑰只有本人有)。 訊息保密： 如果我們今天要傳遞訊息給特定的使用者A君，然後希望其他人都無法知道訊息的內容，則可以透過 PKI 取得 A君的公鑰，對訊息加密後進行傳輸，儘管訊息傳遞過程中間的人(比方説郵差)有經手這則訊息，但因為對應的私鑰只有A君本人有，所以郵差先生就無法解密而得知訊息的內容。 結語 密碼學在現代資訊安全中扮演著關鍵角色，從日常的網頁瀏覽到電子商務交易，都離不開密碼學的應用。透過本文的介紹，我們了解到： 密碼學不只是單純的訊息隱藏，還包含了確保資訊完整性與不可抵賴性的重要功能 對稱式加密演算法適合用於需要高效能的場景，如 SSL/TLS 連線加密 非對稱式加密演算法則在數位簽章和安全通訊等應用場景中發揮重要作用 PKI（公開金鑰基礎建設）為數位世界提供了可信任的身分驗證機制 理解這些基礎概念對於開發安全的應用系統至關重要。雖然現代密碼學涉及複雜的數學理論，但其核心概念和應用場景是每個開發者都應該掌握的基礎知識。 在這個資訊安全日益重要的時代，持續學習和理解密碼學知識，將有助於我們開發更安全、更可靠的系統，為用戶提供更好的保護。

緣起 由於最近碰到要在負責的網頁式聊天機器人中，新增如同Line聊天室的貼圖功能，可想而知會有大量的貼圖圖片會需要在用戶裝置瀏覽器進行下載，不管是對圖片伺服器或是用戶等待的過程來說都是不小的負擔。 為了解決這個問題，透過使用了 PWA (Progressive Web App) 技術中常用的離線儲存方案 indexedDB 來快取貼圖圖片，不僅減少用戶端與網站伺服器端的連線流量，也提升的用戶體驗(UX: User Experience) 。 Service Worker Service Worker是一個事件驅動的網站 Worker，根據不同的來源 (origin) 與網址路徑 (path) 進行註冊後，之後再次訪問同一網站後即會在背景執行這個 Service Worker。 Service Worker 無法直接存取 DOM 物件，他負責監聽和處理像是 fetch, notification(推播), sync 還有 Service Worker 註冊、啟動 等相關事件。 透過處理上述事件，我們可以讓 web 網頁像一般的手機原生 App 一樣可以執行安裝、發送推播、離線瀏覽及連線後同步等等作業。 離線儲存 常見的 Ｗeb 儲存方案有下面幾種: Cookie LocalStorage Cache (precache) indexedDB 一般 SPA (Single Page Application) 中比較常用的是 Cookie 跟 LocalStorage 兩種儲存方法，不過在使用上都會有大小的限制（無法儲存較大的網站資源），像是 LocalStorage 的限制依照瀏覽器不同會落在大約 2MB ~ 10MB 左右，超過後就會發出Error。 而在 PWA 的離線儲存上通常會使用 Cache(precache) 或 indexedDB 來實作，它們的大小通常跟使用者裝置的 disk 空間有關係，以 Chrome 為例，所有網站可以用的共享儲存空間為硬碟可用空間的1/3, 每個網站 App 可以使用共享空間中的 20%。...