vCard 產生器的大量工作流程會從一份聯絡人清單產生多個符合標準的 .vcf 檔案，通常每人一筆記錄，並可選擇性地輸出一個合併檔案。這個詞涵蓋了兩種截然不同的工作：將一份數百列的試算表送進伺服器端的批次處理器，以及在私人的瀏覽器工具中一次產生少量聯絡人檔案。兩種做法都朝著同一個目標——把聯絡人資訊轉成任何通訊錄應用程式都能匯入的可攜式 .vcf 記錄——但它們在隱私、格式版本以及你所提交的資料會發生什麼事情上有著明顯的差異。本文聚焦於第二種做法，使用 Lizely 的 vCard 產生器，它在每次工作階段中產生單筆 vCard 4.0 記錄，並讓你為每位聯絡人重複這個流程，直到整批完成。對於非常龐大的聯絡人清單，則存在另一類工具，會在文末說明，讓你能夠有意識地做出選擇。
「大量」對 vCard 產生來說代表什麼
「大量」這個詞在不同的聯絡人管理工具有不同的意義。在 CSV 批次的世界中，它通常代表一個伺服器端的上傳工具，接受一份數百列的試算表，並回傳一個包含完成 .vcf 檔案的 ZIP 壓縮檔，有時還會附上一個合併的聯絡人檔案。在注重隱私的瀏覽器內工具中，「大量」的定義更為節制：它描述的是你手動也會做的同樣流程，只是透過一個為你處理格式的表單反覆執行。簡單來說，Lizely 的 vCard 產生器每次工作階段產生一筆記錄，因此大量工作流程的意思就是產生一位聯絡人、下載檔案、產生下一位，然後重複。
這個區別很重要，因為兩條路徑回答的是不同的問題。CSV 上傳工具以本機處理換取處理大量清單的速度。本機的單筆記錄產生器以吞吐量換取可驗證的輸出——不需要帳號、不需要上傳，而且你可以在檔案離開裝置之前先行檢視。如果你的批次很小（一個十二人的業務團隊、一份四十人的活動參加者名單、一場研討會的講者），單筆記錄的工作流程速度已經足夠，還能讓你在聯絡人卡片進入通訊錄之前先逐一檢查。如果你的批次動輒數百筆，或包含絕不該送到第三方伺服器的敏感個人資訊，那麼本機工作流程是唯一合理的選擇。
為什麼符合標準的本機產生器對大量工作很重要
當你產生多於一個 .vcf 檔案時，每筆記錄都必須以相同方式被解析。任何一個非標準的字元——一個遺漏的跳脫字元、一個應該是 CRLF 卻出現 LF 的換行、一行長度超出匯入工具所能接受的範圍——都可能讓檔案變成靜默的不完整匯入。Lizely 產生器依據 RFC 6350 來建立每筆記錄，這是 IETF 發佈、並由 IANA vCard Elements Registry 追蹤的現行 vCard 4.0 規格。遵循該規格意味著同一個檔案應該不需要重新格式化，就能匯入 Apple Contacts、Google Contacts、Microsoft Outlook、Thunderbird，以及大多數行動裝置的通訊錄。
本機處理的設計也消除了一類在大量工作中會變得棘手的風險：沒有任何伺服器會保存你產生的每一筆聯絡人複本。每次預覽、跳脫、折行和下載都發生在當前的瀏覽器分頁中。下載本身是一個暫時性的 Blob 連結，一旦你關閉或重新載入頁面就會失效。對於處理私人資料的團隊——人力資源聯絡人、內部通訊名單、客戶升級案件——這個界線是偏好使用本機工具的主要原因，即使 CSV 批次上傳工具理論上能更快完成工作。
建立一筆可在任何地方匯入的單一 vCard
這是核心迴圈。每位聯絡人都經過同樣的三個步驟，結果是一個 .vcf 檔案，你可以在把批次其餘部分送給同事之前，先在一台裝置上測試匯入。
- 開啟 vCard 產生器，在格式化名稱欄位中輸入必要的完整姓名。接著視需要加入其他可選的細節：組織、職稱、電子郵件地址、電話號碼、公開網站網址，以及簡短備註。空白欄位會從輸出中省略，而不會以空白屬性的形式發出。
- 選擇 Create vCard 並仔細閱讀預覽。檢查姓名中的拼字錯誤、電話號碼中的正確國碼、是否為正確的電子郵件網域，以及網站路徑是否完全正確。預覽就是實際的檔案內容，因此這是在錯誤被凍結到 .vcf 之前最後一個便宜且容易修正的地方。
- 下載 .vcf 檔案並匯入到你預定用於整批作業的通訊錄應用程式。真實的匯入是最終的相容性檢查：如果 Outlook 能把姓名、電子郵件和網站視為獨立欄位，那麼批次中的其餘部分也會以同樣方式運作。如果你需要更深入的測試匯入步驟說明，請參閱 如何建立一張在任何地方都能乾淨匯入的 vCard 檔案。
小型批次可重複的工作流程
對於五到三十位聯絡人的批次，一份簡單的試算表加上重複的單筆記錄產生，其實比想像中更快。從一份每個可選欄位各佔一行的試算表開始：完整姓名、組織、職稱、電子郵件、電話、網站、備註。將標題列排序並凍結，然後逐列往下處理。每一列，把值複製到表單中、產生檔案、把下載的 .vcf 重新命名以對應該聯絡人（例如 jane-doe.vcf），再繼續處理下一列。預先重新命名可以避免瀏覽器覆蓋先前的下載檔案。
如果你的目的端接受包含多筆記錄的單一合併 .vcf，你也可以把多次工作階段的預覽文字串接成一個檔案。每筆記錄都已以 BEGIN:VCARD 開頭、以 END:VCARD 結尾，因此安全的做法是：把第一次預覽的完整文字複製到一個新檔案中，將第二次預覽直接貼在第一次的下方（保留 CRLF 行尾不變），然後重複。匯入工具會把這個檔案視為一串記錄的清單，並獨立解析每個 BEGIN/END 區塊。務必先在目的端應用程式上測試合併後的檔案，再進行散佈；如果某一筆記錄格式錯誤，匯入工具可能會略過整個檔案或在錯誤處停止。
小型批次還有另一項優勢：審查。眼前只有一筆記錄時，你能抓出電話號碼中顛倒的數字、組織名稱的拼字錯誤，或備註中可能會被匯入工具誤判為欄位分隔符號的多餘分號。正是這個審查步驟，讓五筆記錄的批次能在第一次就順利匯入。
RFC 6350 實際上規定了什麼
有兩個細節決定 vCard 4.0 檔案能否乾淨匯入：文字跳脫和折行。Lizely 產生器會自動套用這兩項，但了解背後的運作有助於你在預覽中察覺異常。
在任何 vCard TEXT 值中，下列字元必須進行跳脫：
| 字元 | vCard 4.0 中的跳脫 | 為何重要 |
|---|---|---|
| 逗號 | \， | 分隔結構化屬性中的清單項目 |
| 分號 | \; | 分隔單一值中的各個組成部分 |
| 反斜線 | \\ | 引入跳脫序列本身 |
| 換行 | \n | 在不結束屬性的前提下，在 NOTE 中編碼段落 |
像「Doe, Jane」這類姓名、含有分號的組織，以及包含多個段落的備註，全都仰賴這些跳脫字元。如果缺少它們，匯入工具可能會把姓名中的逗號當成新清單項目的開頭，或把換行當成屬性的結尾。
第二個細節是折行。RFC 6350 限制每個內容行最多 75 個 UTF-8 八位元組（不是 JavaScript 字元，也不是字碼點）。當屬性值更長時，行會被切斷，每個接續行的開頭都是一個空格。產生器以 UTF-8 八位元組為單位來計算，因此絕不會把表情符號或多位元組字元從其編碼中間切開。下載的檔案也使用 CRLF 行尾，並以一個結尾的 CRLF 作為檔案結尾——這正是大多數通訊錄匯入工具所預期的形式。
工具所輸出的屬性集刻意保持保守。以下是目前版本會產生的內容，以及刻意省略的內容：
| 屬性 | 是否輸出 | 備註 |
|---|---|---|
| BEGIN:VCARD / END:VCARD | 是 | 包裹每一筆記錄 |
| VERSION:4.0 | 是 | 宣告格式版本 |
| FN（格式化名稱） | 是，必要 | 缺少此項，記錄就無法成為可用的聯絡人 |
| ORG、TITLE、EMAIL、TEL、URL、NOTE | 有提供時輸出 | 空白欄位會被省略，而非以空白形式輸出 |
| PHOTO、社群檔案、同步來源 | 否 | 僅輸出一組保守的、以文字為基礎的屬性 |
什麼時候你需要不同的工具
實際的限制在於吞吐量。單筆記錄的本機產生器適用於大約一到三十位聯絡人的批次，特別是在資料敏感、或你希望在每筆記錄離開裝置前先行檢查的情況下。超過這個規模，工作流程仍然可行，但時間成本會變得明顯，你可能會偏好使用一個能回傳完成檔案 ZIP 壓縮檔的 CSV 批次處理器。
如果你的目標是可以掃描的條碼而非可匯入的檔案，工作流程又完全不同。基於 QR Code 的聯絡人分享會為每位聯絡人產生一張手機相機可掃描的圖片，通常是來自 CSV 上傳的 ZIP 壓縮檔。Lizely 的工具鏈把這兩種工作分開：vCard 產生器產生可下載的記錄，而 QR Code 產生器則處理一個可掃描的表示形式，用於簡短的公開值。該選擇哪一個，取決於接收方是需要把聯絡人資訊讀進自己的手機，還是收到一個可以加入通訊錄的檔案。
對於非常龐大的清單——企業通訊錄、擁有數百列資料的研討會參加者資料庫——適合使用試算表的批次工具會更有效率。其取捨在於，這類工具通常會把你的聯絡人資料上傳到遠端的轉檔服務，再回傳完成檔案，而這正是本機 vCard 產生器設計上要避開的界線。了解你願意做出哪種取捨，才是「vCard 產生器 大量」這個搜尋背後真正問題的答案。
如果你正在權衡各種選項，LED 跑馬燈大量前置作業：無需 App 也能製作單行橫幅 對此有詳細說明。