文字與日常工具·二維碼與條碼工具包

一個二維碼可以容納多少資料？版本 1 到 40 和容量說明

2026年9月28日 · 背景

二維碼編碼可用性

解釋 40 QR 版本、網格大小、編碼模式和糾錯如何結合起來設定容量，以及為什麼理論最大值很少是實際的。

程式碼變成了不可讀的灰色方塊——當你編碼一個段落而不是一個連結時會發生什麼

長音符甚至可以在編碼器拒絕它之前將緊湊的符號變成密集的微小模組。這種視覺變化很重要，因為固定的列印寬度為每個新增的行和列留下了更少的像素或印表機點。

密度在模組計數器和物理證明中都可見。產生器可以接受長註釋，但固定大小的預覽現在包含許多較小的單元格，稍後列印可能會使它們模糊。容量回答是否可以建立矩陣，而不是選擇的印表機和電話是否可以解析它。在減少邊距或單元尺寸之前先減少有效負載，因為這些變化會攻擊掃描器的視覺證據。

此實作支援 QR 版本一到四十：第一個版本每側 21 模組，然後每側另外四個模組，直到 177。自動選擇選擇適合 UTF-8 位元組有效負載和校正等級的最小版本。

版本尺寸提供了一個簡單的可觀察階梯：版本一的 21 模組，然後每一步每側四個附加模組，直到 177。這些測試驗證了跨校正等級的 `4n + 17` 尺寸規則。 ToolAcre 要求自動選擇的依賴項，而不是公開版本欄位，因此使用者應該讀取產生的模組計數，而不是強制進行表查找。

通用容量表將數字、字母數字、位元組和漢字模式分開，但 ToolAcre 故意對每個有效負載使用位元組模式。複製其他模式最大值會錯誤地描述此工具，因此此處的容量以編碼的 UTF-8 位元組來衡量。

UTF-8 位元組長度解釋了為什麼相同的字元數可能表現不同。四十個 ASCII `x` 字符使用的字節數少於四十個日語字符，並測試確認多字節有效負載需要至少同樣大的矩陣。因此面板顯示位元組而不是字元。通用數字或字母數字最大值不會預測 ToolAcre，因為它透過位元組模式發送每個有效負載。

已驗證的上限是 L 處的 2,953 位元組、M 處的 2,331 位元組、Q 處的 1,663 和 H 處的 1,273 位元組。這些是實現常數，而不是對實際列印品質的承諾，更強的校正為有效負載位元組留下了更少的空間。

確切配置的上限也定義錯誤路徑：L 處的 2,953 位元組、M 處的 2,331、Q 處的 1,663 和 H 處的 1,273。這些是在介面中顯示的有效實現圖。它們不應轉換為字元數，因為重音符號和表情符號的 UTF-8 長度各不相同。當某個值超出容量時，縮短它比默默刪除內容更安全。

當印刷太小或在太遠的地方觀看時，技術上適合的矩陣仍然可能是糟糕的物理設計。相機解析度、靜區、對比度和基材降低了實際的上限，這就是為什麼短 URL 通常比整個記錄更可取的原因。

實際範圍取決於整個符號。更強的校正可以使相同文字的矩陣更大，如 L 和 H 之間的 200 字元測試所示。在固定的列印寬度下，這會縮小每個模組。因此，提高校正不會自動變得更安全：冗餘可能會容忍一些損壞，而增加的密度會使乾淨捕獲變得更加困難。選擇一個級別，然後測試產生的物理程式碼。

產生一個短 URL、受支援的 vCard 和長純文字註釋，然後比較傳回的模組計數並掃描校樣。原始碼沒有公開任意文字的有保證的版本估計器，因此請觀察實際輸出而不是猜測。

對於範例集，在相同的修正層級產生一個短 HTTPS URL、受支援的 vCard 和 500 字元註解。記錄位元組數和模組尺寸，而不是預測確切的版本。 vCard 在可見的聯絡人資料周圍新增了欄位標籤和分隔符，因此其編碼長度不僅僅是表單中出現的長度總和。

未實現結構化追加和 Micro QR。 ToolAcre 也不會在符號之間分割過大的有效負載；它報告內容太長並建議縮短內容或選擇較低的更正等級。

ToolAcre 不會將資料分割為多個代碼，也不提供 Micro QR。過大的有效負載會回傳錯誤而不是部分影像。如果記錄太大，請將其託管在穩定的 URL 後面，或選擇其多符號格式和讀取器支援滿足要求的專業工具。將文字手動剪下成不相關的 QR 影像會為掃描器和使用者帶來組裝問題。

當目標可以託管更大的記錄時，對指標進行編碼，將長期存在的 URL 置於您的控制之下，並讓產生器選擇矩陣。容量是位元組預算，而可靠使用是物理系統測試。

操作要點是一個層次結構：保留正確的內容，刪除不必要的字節，選擇適當的校正級別，觀察產生的矩陣，然後調整大小並測試它。理論上的最大值是編碼器的最終邊界，而不是設計目標。短指標通常為強大的模組留出更多空間，並允許目標內容變更而無需替換列印。