命令列 QR 產生器會在您自己的機器上執行腳本，並能在單一工作中產生數百甚至數千個 PNG；線上批量 QR 產生器則在瀏覽器分頁中執行，並將批次限制為固定數量的檔案。這兩種做法回答了同一個根本需求 — 從多個輸入產生多個 QR code — 但在控制權與便利性上做出相反方向的取捨。腳本要求您安裝執行環境、管理相依套件、撰寫或借用迴圈，並決定檔案輸出的位置。線上批次工具則要求您貼上一份清單、選擇尺寸，然後點擊產生，但代價是批次大小有硬性上限，且選項是固定的。批次 QR Code 產生器是第二種路徑的一個例子：它完全在用戶端執行，將編碼工作委派給與本專案單張圖片工具相同的 qrcode 1.5.4 函式庫，並透過各自的個別下載連結提供每個 PNG。所有資料都不會離開瀏覽器分頁，且該頁面刻意避免加入封存相依套件來打包整個批次。因此，命令列腳本與線上批次產生器之間的抉擇，並非抽象地比較哪個工具「比較好」，而是哪種取捨最符合眼前這個批次在規模、治理與驗證上的需求。
命令列批次 QR 產生器：您實際執行的內容
命令列批次 QR 產生器在本質上，是一個您從終端機呼叫的小程式。它從檔案或參數讀取一份輸入清單，對每筆輸入呼叫一次 QR 編碼函式庫，並將結果 — 通常是 PNG 或 SVG 檔案 — 寫入您指定的資料夾。多數已發佈的腳本是以 Python 或 Node 撰寫，因為這兩個生態系都擁有成熟的 QR 函式庫，且都可在沒有 UI 的情況下編寫腳本。在命令列這一側的工作流程大致如下：若尚未安裝，請先安裝 Python 3 或 Node.js 等執行環境；透過套件管理器安裝一個 QR 函式庫（pip install qrcode 或 npm install qrcode）；將您的輸入儲存為純文字檔，每行一個網址或字串；然後執行一支腳本，逐行編碼並將 01-name.png、02-name.png 等檔案寫入輸出目錄。
對工程師而言，其吸引力顯而易見：零點擊操作、完全掌控檔名、易於與 CSV 流程整合，且除了機器的算力之外沒有批次上限。其代價也同樣明顯：您必須負責執行環境、相依套件、腳本的正確性，以及輸出資料夾。迴圈中的一個拼字錯誤可能會在不知情的情況下覆寫檔案；缺少一個套件則可能讓整個批次中途停擺。對於以數百或數千計的批次規模，這種「所有權」通常是值得的。但對於一、二十個左右的批次，工程上的負擔往往難以回本。
瀏覽器式批次 QR 產生器：分頁中發生了什麼
線上批次 QR 產生器將同樣的工作搬到瀏覽器中執行。您貼上清單、選擇像素尺寸與容錯等級、點擊產生，該頁面便會以 JavaScript 對每一行執行 QR 函式庫。PNG 會以預覽形式出現在頁面上，每個都有各自的下載連結，且您的輸入與輸出都停留在當前分頁中。這裡的取捨與命令列路徑恰好相反：您放棄了明確的批次上限與可程式化的流程，但換來零安裝操作、零相依套件負擔，以及在目標裝置上下載前明確的掃描步驟。批次 QR Code 產生器遵循的就是這個模式 — 它使用與本專案單張圖片工具相同的 qrcode 1.5.4 套件，因此批次輸出會與您逐行編碼所得到的結果相同；但它將批次上限設為 20 筆不重複的值，且每行最多 2,000 個字元，以在一般筆電與手機上將 CPU、記憶體與意外的大量下載控制在合理範圍內。編碼工作會委派給 node-qrcode 瀏覽器 API，邊界設為 2，並使用您所選擇的 L、M、Q 或 H 容錯等級。
命令列 vs 線上：並列比較取捨
下表從真正影響決策的面向來比較這兩條路徑。由於具體數字與行為取決於您所選擇的函式庫、腳本或服務，因此以質化方式描述。
| 面向 | 命令列腳本 | 瀏覽器式批次工具 |
|---|---|---|
| 設定工作量 | 安裝執行環境、函式庫，並撰寫或借用腳本 | 開啟頁面並貼上清單 |
| 相依套件 | 由您自行管理與更新的數個套件 | 終端使用者看不到任何相依套件 |
| 批次上限 | 僅受記憶體與時間限制 | 硬性上限（批次 QR Code 產生器為 20 筆不重複的值） |
| 資料流向 | 由您掌控的本機輸出資料夾 | 停留在當前瀏覽器分頁中 |
| 每個檔案的命名 | 由腳本自行決定 | 由內容衍生的確定性索引檔名 |
| 容錯等級控制 | 由函式庫所公開的選項決定 | 固定的 L、M、Q、H 等級 |
| 封存或 ZIP 輸出 | 在執行環境支援時易於加入 | 通常省略，以避免新增相依套件 |
| 驗證流程 | 必須自行撰寫 | 下載前內建逐一掃描預覽的步驟 |
| 最佳適用情境 | 工程流程與數百個檔案 | 小型編輯、行銷或營運批次 |
在瀏覽器中產生最多 20 個 QR Code
若您判斷瀏覽器路徑符合您的批次需求，批次 QR Code 產生器會引導您完成五個具體步驟。
- 將每行一個文字或網址貼入輸入框，且不超過 20 筆不重複的行。解析器會去除前後空白、移除空白行與完全重複的內容，同時保留首次出現的順序，因此您可以直接貼上粗略的清單，無須事先清理。
- 選擇 PNG 尺寸 — 128、256 或 512 像素 — 以及容錯等級 — L、M、Q 或 H。根據 DENSO WAVE 容錯規格，這些等級分別可還原約 7%、15%、25% 與 30% 的代碼字，且較高的等級會降低資料容量，而非自動提升掃描成功率。若想更深入了解何時 128px 是優於更大尺寸的選擇，請參閱128px PNG 與較小尺寸適用的時機指南。
- 選擇「產生 QR code」。頁面會在工作識別碼下並行編碼每一行，因此若您變更輸入或選項，較舊的產生結果便無法覆寫較新的設定。
- 使用目標裝置與應用程式掃描每個預覽。這是驗證步驟；產生的影像並不代表每台掃描器都能讀取到預期內容，且部分讀取器對網址、聯絡人文字或其他承載資料的解讀方式不同。
- 個別下載已驗證的 PNG，並保留其靜默區。瀏覽器政策可能會要求每個檔案各點擊一次，或提示下載權限；該頁面刻意不會觸發 20 個自動下載，以保持所選輸出的明確性。
若某筆承載資料超出 QR 容量，批次會顯示錯誤，而非將不完整的結果呈現為完成狀態。縮短該行內容或降低容錯等級，通常就能讓它重新納入有效的符號中。
命令列腳本仍有其適用之處
對於非常大的批次、編寫腳本的流程，或嵌入於其他建置步驟中的 QR code，命令列做法仍是較佳的選擇。以下幾種情況會讓決策傾向腳本：您在單一工作中需要超過 20 個符號，或需要將 QR 產生串接到更大的資料流程中；您希望在工作結束時產出一個一次性的 ZIP 封存檔，這對腳本而言輕而易舉，因為它掌控自身的相依套件；您需要對檔名、影像尺寸或輸出路徑進行細部控制，而瀏覽器工具並未提供這些選項；或者您要編碼成瀏覽器工具不支援的格式，例如 SVG、PDF 或 EPS，而您的下游工具預期會收到這些格式之一。上述每種情況，其代價雖真實但可預期：安裝執行環境、加入 QR 函式庫、撰寫或借用迴圈，並自行負責驗證步驟。瀏覽器工具在這些情境下無能為力，而這正是同時保留兩條路徑的意義所在。
您必須事先考量的限制、檔名與掃描驗證
無論選擇哪條路徑，有三項限制反覆出現，值得在開始前先牢記在心。第一，每批上限。批次 QR Code 產生器強制限制為 20 筆不重複的值，且每行最多 2,000 個 JavaScript 字元。這些限制是為了在手機與一般筆電上將 CPU、記憶體與版面配置工作量控制在合理範圍內，並避免意外的大量下載。腳本則沒有這樣的上限，但若不想讓失控的迴圈寫出數千個檔案，您必須自行加上防護機制。第二，確定性檔名。產生的檔名以兩位數的批次位置起頭，加上由內容衍生的簡短 ASCII 檔名。網址 https://example.com 會變成 01-example-com.png。若一行中不含任何 ASCII 字母或數字，則備用檔名為 qr-code。檔名僅作為便利標籤，永遠不會改變編碼內容，因此在檔案管理員中重新命名是安全的，也不會改變掃描器讀取的內容。第三，掃描驗證。產生的影像並不代表每台掃描器都能讀取到預期內容。長篇 UTF-8 文字、表情符號、印刷尺寸、對比、相機焦距、螢幕反光、物理損壞與讀取器行為都會影響成功率，且底層函式庫已註明尚未實作完整的 ECI 支援。在發佈、印刷、標示庫存、發送活動資料或取代現有 QR code 之前，請務必使用目標裝置與應用程式掃描每個最終 PNG。請勿將未經驗證的 QR code 用於付款、身分驗證密鑰、安全指示或不可逆的動作。
為您的批次規模選擇正確的路徑
一個實用的經驗法則：若您的批次為 20 筆或更少的值，瀏覽器式批次 QR Code 產生器能以最少的安裝提供最快且可驗證的結果。若您的批次更大，或 QR 產生是更大腳本流程中的一個步驟，那麼以維護良好的函式庫建構的命令列迴圈，能在不帶意外的情況下提供您所需的控制力。無論哪種方式，驗證步驟都是您的責任：在最終符號送到客戶、標籤印表機或印刷品之前，請先在目標裝置上掃描每一個。這項比較並非忠於哪一個工具，而是將路徑與眼前批次的規模與治理需求相互匹配。
若想進一步了解，請參閱在 iPhone 上批次產生網址：從 Safari 執行。