vCard 產生器 API 的替代方案，是一種能產生同樣符合標準的 .vcf 通訊錄檔案的工具，但無需將您的資料傳送到遠端服務、不用註冊帳號，也不用持有 API 金鑰。替代方案並不是把表單欄位 POST 到託管端點再等待回應，而是在您目前的瀏覽器分頁中直接建構 vCard 4.0 文字內容，並以臨時的本機下載方式交還給您。這種務實上的差異會在三個地方顯現：隱私，因為聯絡資訊從不離開您的裝置；成本，因為沒有按次計費或每月分級；以及可靠性，因為檔案是由一組確定性的序列化規則產生，而不是由 API 當天碰巧回傳的內容決定。對任何要為一份工作申請、一張印刷名片、一張會議識別證，或一份小型內部通訊錄製作一次性聯絡人名片的人來說，這樣的取捨通常才是正確的選擇。Lizely 上的 vCard 產生器正是圍繞這個理念打造：您輸入聯絡細節、預覽 RFC 6350 文字內容，然後下載一個能乾淨匯入您實際使用的通訊錄應用程式的 .vcf 檔案。從接收端匯入程式的角度來看，最終產生的聯絡人資料與託管 API 所產生的完全無法區分。
為什麼人們會從以 API 為基礎的 vCard 工具轉向其他方案
託管的 vCard API 對於需要大量產出聯絡檔案的軟體來說運作良好，但當一個人只需要單一 .vcf 檔案時，就會產生摩擦。每次 API 呼叫都必須進行驗證，這通常代表要佈建一把 API 金鑰、將它存放在安全的地方，並在過期時進行輪替。免費分級常常伴隨每月額度、速率限制，或每次請求可產生的檔案數上限，所以一個本該很簡單的任務可能會演變成一場小型帳務作業。更實際的顧慮是隱私。大多數以 API 為基礎的產生器會將完整的姓名、組織、電子郵件、電話號碼，以及任何個人備註傳送到遠端伺服器進行處理。當聯絡資訊本來就已經公開時沒有問題，但當這張名片屬於一位私人客戶、一份內部團隊通訊錄，或一位尚未同意讓第三方記錄其資料的人時，就會讓人感到不安。基於瀏覽器的替代方案則一次解決了這些層層關卡。沒有帳號、沒有金鑰、沒有額度，也沒有您所輸入聯絡細節的遠端記錄。名片是由相同的 RFC 6350 序列化規則所建構，但序列化過程發生在您已開啟的網頁內部。
在不打 API 的情況下建立 vCard
整個流程都停留在您目前的分頁中；任何時刻都不會將資料提交到遠端端點。
- 輸入必填的完整姓名，然後加入您想包含的任何組織、職稱、電子郵件、電話、網站或備註。格式化名稱是唯一能產出可用可攜記錄的欄位，因此表單將其視為必填。您留空的選填欄位會從輸出中省略，而不是被寫成空白屬性，這能讓 .vcf 檔案保持精簡。
- 選擇建立 vCard並仔細閱讀預覽內容。預覽會顯示將寫入 .vcf 檔案的精確文字，包括用來跳脫您數值中之逗號、分號、反斜線或換行的任何反斜線。過長的行會在 75 個 UTF-8 位元組處進行折行，並在每個接續行前加上一個前置空白，這正是 RFC 6350 匯入程式所預期看到的格式。
- 下載 .vcf 檔案，並在發布前於您的目標通訊錄或聯絡人應用程式中進行實際匯入測試。各家匯入程式對標準核心屬性集的處理略有不同，因此一次真正的匯入，是唯一能抓出選填欄位缺漏、國碼格式錯誤或罕見標點符號問題的相容性檢查。
當下載按鈕觸發時，檔案會在您的瀏覽器內部以臨時 Blob 的方式組裝完成。關閉或重新載入網頁會同時捨棄已輸入的資料與下載 URL，這能避免聯絡細節滯留在您無意建立的快取中。
瀏覽器為您處理的 vCard 4.0 規則
手動建立 vCard 很少像輸入欄位標籤那麼單純。RFC 6350 規範了每個文字值應如何跳脫、實體行可允許的長度，以及 Unicode 字元的編碼方式，而大多數匯入程式會默默地誤讀一個略過這些步驟的檔案。瀏覽器產生器會處理在手動建檔時容易忽略的規則：
- 跳脫處理。文字值中的逗號、分號、反斜線與換行，會依 RFC 6350 的要求加上反斜線跳脫。像 Doe, Jane 這樣的姓名會停留在單一 FN 屬性內部，而不會被剖析為兩個結構化欄位。
- 行折疊。vCard 內容行是以 UTF-8 位元組計算，而非 JavaScript 字元。產生器會在不超過 75 個位元組處折疊過長的行，並依規範要求在每個接續行前加上單一空白。
- Unicode 安全性。折疊發生在完整的碼點上，因此表情符號或多位元組字元絕不會在其 UTF-8 編碼的中間被切開。這能讓接收端的非 ASCII 備註與姓名保持完整。
- CRLF 行尾。輸出使用 CRLF 行尾，並以一個最終的 CRLF 作為結束，這正是大多數通訊錄匯入程式對符合標準的檔案所預期的格式。
產生器也強制執行一些實用的輸入檢查，以保護檔案的結構。網站項目必須是公開的 HTTP 或 HTTPS URL；內嵌的使用者名稱與密碼會被拒絕，其他聯絡欄位中不支援的控制字元也會被拒絕。在屬性內輸入的換行會被編碼進該值中，而不會被允許插入額外的 vCard 屬性。這些規則能在保持檔案結構乾淨的同時，保留一般的國際文字、標點符號、電話格式與備註。
API 工作流程 vs 瀏覽器工作流程
並排比較時，呼叫 API 與執行本機產生器之間的務實差異如下所示：
| 面向 | 以 API 為基礎的產生器 | 本機瀏覽器產生器 |
|---|---|---|
| 驗證方式 | 需要 API 金鑰 | 無 |
| 是否需要帳號 | 通常需要註冊 | 無 |
| 聯絡資料流向 | 上傳至遠端伺服器 | 停留在您的瀏覽器分頁中 |
| 速率限制或額度 | 常見於免費分級 | 無 |
| 成本模式 | 按次計費或每月分級 | 免費，無計量 |
| 離線使用 | 每次呼叫都需要網路 | 頁面載入後即可使用 |
| 輸出行為 | 依 API 回傳內容而定 | 確定性的 RFC 6350 序列化 |
| 廠商擴充 | 依提供者而異 | 僅保守的核心屬性集 |
什麼時候 vCard 檔案才是正確的格式
vCard 檔案並非在人與人之間傳遞聯絡細節的唯一方式。可掃描的 QR code 能承載相同的資訊，在會議現場或印刷名片上進行面對面交接時速度更快。這兩種格式解決的是不同的工作，兩者之間的選擇多半取決於聯絡細節將如何抵達接收端的裝置。當目的地預期接收一個可下載的記錄時，vCard 檔案就能發揮作用：電子郵件簽名、附件名片、HR 通訊錄匯入，或匯入至 Outlook、Apple Contacts 或 Google Contacts。當目的地是一支手機的相機，且接收者想要掃描而非下載時，QR code 就能派上用場。Lizely 的 vCard 產生器是為前者而打造。當聯絡人名片需要以結構化記錄的形式存在於通訊錄中時，.vcf 檔案就是每個主流匯入程式都能理解的格式。
在分享 .vcf 之前進行驗證
預覽是您的第一道安全檢查。請像閱讀任何其他文件一樣閱讀它：確認完整姓名的拼字、檢查電話號碼上的國碼是否為您原本要輸入的那個、掃視電子郵件地址的網域是否正確，並確認網站路徑中沒有夾帶多餘的字元。跳脫會以反斜線形式出現在逗號、分號與換行之前；這是預期中的現象，接收端的匯入程式會在顯示欄位之前將它們解碼回原始字元。姓名或備註中的多位元組文字應在預覽中以您實際輸入的字元呈現，即使該行已使用接續空白進行折疊。
下載之後，唯一重要的測試就是一次真正的匯入。請在您預定使用的通訊錄應用程式中開啟 .vcf 檔案，並確認每個欄位都落在正確的位置。若您需要匯入步驟的檢查清單，如何製作可在任何地方乾淨匯入的 vCard 檔案一文會逐步說明 Outlook、Apple Contacts 與 Google Contacts 常見的問題。
產生器刻意不嵌入照片、社群檔案或廠商專屬擴充。這種保守的屬性集正是讓檔案能跨匯入程式可攜的原因，也是這個工具從不聲稱電子郵件地址或電話號碼屬於真實人物的原因。它會序列化您所提供的任何內容。若您正在為他人製作名片，請在分享檔案前取得對方同意，並將 .vcf 視為純文字而非已驗證的身分憑證。
若您正在權衡各種選項，用於快速瀏覽器預覽的 LED 跑馬燈 API 替代方案對此有詳細說明。