9 格照片分割工具會將一張圖片分割成一個 3 乘 3、共九張獨立 PNG 拼磚的組合，而 Image Grid Splitter 正是執行這項工作:挑選一張本機的 JPG、PNG 或 WebP，在行列欄位中輸入 3，選擇 Split image，接著依閱讀順序下載九張編號齊全、保持原始解析度的 PNG。整個流程——檔案解碼、像素擷取、PNG 編碼以及下載建立——都在當前的瀏覽器分頁中執行，因此來源圖片永遠不會被上傳到伺服器。每個來源像素恰好被涵蓋一次，這代表一張 1080 乘 1080 的照片會產生九張 360 乘 360 的拼磚，而不是九張稍微被裁切或拉伸的正方形;而一張 1200 乘 900 的照片則會產生九張 400 乘 300 的拼磚，而不是在右側或底部邊緣掉一條的組合。邊界是由比例化的整數座標計算出來的，因此相鄰的拼磚會精準對齊，既沒有重疊也沒有缺漏像素;而且若某個網格會產生零像素的拼磚，工具會直接拒絕，而不是默默截斷影像。
9 格照片分割工具實際上在做什麼
當你向一張圖片要求「9 格」時，你其實是在要求一個 3 乘 3 的拼磚組合，而且這些拼磚必須是:保持原始解析度的 PNG 而非縮圖、可個別下載、邊緣緊密相接沒有重疊也沒有縫隙，以及可預測的排列順序——由上而下、再由左而右。其中最重要的特性是邊緣緊密相接的完整覆蓋。如果工具從每個格子的中央裁切一個固定大小的正方形，照片最外側的邊緣就會遺失。如果它先把每個格子縮成正方形，拼磚就不再是照片的原始解析度。如果它把寬度進位到「漂亮」的數字，你可能會在右側掉一條，或得到一排誤導人的正方形。
Image Grid Splitter 避開了上述三個陷阱:它以照片的原始像素尺寸為基準、以整數邊界進行切割，並且把每個像素指派給恰好一張拼磚。那種可預測的順序在實務上很重要。如果某則貼文依賴拼磚依正確順序被閱讀——例如當九張拼磚要在個人檔案式的動態中重組成完整照片時——它就必須依序下載，而檔名也必須讓順序一目了然。分割工具會將每個輸出檔命名為類似 photo-row-2-column-3.png 的形式，這讓拼磚保持可排序，並且消除了當最後一行或最後一列比其他人大一個像素時所產生的歧義。
為什麼 Image Grid Splitter 適合這項任務
Image Grid Splitter 是圍繞著 9 格照片分割工具的精確需求所打造，同時也涵蓋人們常在搜尋時一併尋找的幾種相關網格:
- 輸入一張本機圖片，輸出一組編號拼磚。輸入可以是 JPG、PNG 或 WebP，上限為 25 MiB，每邊最多 20,000 像素，總計最多 4,000 萬像素;輸出則是一份 PNG 拼磚清單，包含精確的寬度、高度以及下載連結。
- 由你控制的矩形網格。行與列可各自設定為 1 到 10，因此同一個工具能產出 3 乘 3 的 9 張拼磚、4 乘 4 的 16 張拼磚、5 乘 5 的 25 張拼磚，以此類推到 10 乘 10、共 100 張拼磚。
- 精準、像素真實的切割。邊界是由比例化的整數座標計算出來的，因此把 10 像素寬度切成四欄會得到寬度為 2、3、2、3 的結果——每個像素恰好被涵蓋一次，沒有拉伸、模糊，也沒有內插。
- 純本機處理。檔案解碼、切割與 PNG 編碼都在瀏覽器中執行。來源不會被上傳到 Lizely 或任何其他地方;這個工具從未看到它離開分頁。
- 可預測、可排序的命名。每個檔案以原始檔名加上行列來命名，因此把 photo.jpg 切成 3 乘 3 之後，會得到從 photo-row-1-column-1.png 到 photo-row-3-column-3.png 的檔案。
因為切割在本機執行，即使是私人或工作上敏感的圖片，也能放心使用，不必擔心會在伺服器端留下副本。因為每個輸出都是 PNG，銳利的邊緣以及來源中任何透明區域都能完整保留，拼磚也不必再承受第二輪有損 JPEG 壓縮。
一步步把照片切成 9 格
切割本身只有三個動作:
- 在顯示的檔案與像素限制範圍內，挑選一張本機的 JPG、PNG 或 WebP。
- 輸入 1 到 10 的行數與 1 到 10 的列數——要做經典的 9 格，在兩個欄位中都輸入 3——然後選擇 Split image。
- 檢查每張編號拼磚的尺寸，並下載你需要的 PNG 檔案。
當你選擇 Split image 時，工具會使用瀏覽器的 canvas drawImage 機制，將每張拼磚繪製到一張獨立、原始大小的離屏畫布上，接著把該畫布編碼為 PNG，並依由上而下、由左而右的閱讀順序列出所有拼磚。每個拼磚項目會顯示它的精確寬度、高度和大約的編碼後大小，以及下載連結。MDN canvas drawImage 參考文件說明了瀏覽器只會複製你所指定的來源矩形，這正是保證拼磚不被拉伸或濾鏡處理的關鍵。
即使照片的寬度或高度無法被 3 整除，仍然會產生一組有效的 9 張拼磚。一張寬度 1000 像素的影像切成 3 欄，會得到三張寬度約 333 像素的拼磚，最後一欄吸收那多出的一個像素;三個寬度加總回到 1000，沒有任何像素被遺漏。同樣的規則也獨立套用於高度，因此一張 1000 乘 1001 的影像切成 3 乘 3 時，產生的網格中最後一欄會比其他兩欄寬一個像素，而最後兩列會比第一列各寬一個像素，任何位置都沒有像素遺失。如果某個網格會把拼磚縮到零像素——例如對一張高度只有 2 像素的影像要求 3 列——工具會拒絕這個網格並顯示明確的錯誤，而不是產出損壞的結果。
除了經典 3x3 之外:這個工具還能處理的其他網格
同一個工具涵蓋了相當廣泛的網格尺寸，因為行與列欄位都接受 1 到 10 的數值，而最大拼磚數量為 100。下表整理了常見的版面配置，以及各自適合的來源照片類型。每張拼磚的確切像素尺寸會依來源照片而有所不同;對任何特定影像，工具都會顯示實際的拼磚大小。
| 網格 | 列數 | 行數 | 拼磚數 | 典型用途 |
|---|---|---|---|---|
| 2 乘 2 | 2 | 2 | 4 | 正方形照片切成四個象限 |
| 3 乘 2 | 3 | 2 | 6 | 直立照片切成三組水平配對 |
| 3 乘 3 | 3 | 3 | 9 | 經典的 9 格 / 九張拼磚版面 |
| 4 乘 4 | 4 | 4 | 16 | 正方形照片切成更密集的拼磚組合 |
| 5 乘 5 | 5 | 5 | 25 | 精細的馬賽克式切割 |
| 10 乘 10 | 10 | 10 | 100 | 支援的上限;大型馬賽克 |
如果目標是標準的九張拼磚貼文，將列數設為 3、行數設為 3。若要更密集的馬賽克或不同的長寬比，只要調整這兩個數字;每次切割時，拼磚數量與每張拼磚的尺寸都會依來源重新計算。
不整除的像素數如何分配
當兩個維度都能被 3 整除時，9 格切割非常直觀。但實際的照片往往無法整除——手機直拍可能是 3024 乘 4032，螢幕截圖可能是 1280 乘 720——因此分割工具必須決定如何處理剩下的像素。Image Grid Splitter 會刻意地分配這些像素:每張拼磚的寬度與高度由比例化的整數座標計算出來，最寬的拼磚最多只比最窄的多一個像素，每個來源像素恰好落在某一張拼磚中，邊緣細條不會被默默丟棄。
舉一個具體的例子。一張 1200 乘 900 的影像切成 3 列 4 行，共 12 張拼磚。每欄的寬度為 300、300、300、300，因為 1200 能被 4 整除。每列的高度為 300、300、300，因為 900 能被 3 整除。全部 12 張拼磚都是精準的 300 乘 300,12 × 300 × 300 = 1,080,000 像素，正好等於 1200 × 900 = 1,080,000 像素。拼磚組合之所以一致，是因為來源能夠整除。
當來源尺寸無法整除時，分割工具仍然會產生一組有效的拼磚。規則會分別獨立套用於寬度與高度:來源中的每個像素恰好落在某一張拼磚中，最寬的拼磚最多只比最窄的多一個像素，最後一列或最後一欄吸收任何餘數，邊緣的條帶不會被默默丟棄。因此一張 1000 乘 1001 的影像切成 3 乘 3 時，會產生一組有效的九張拼磚網格，其中最後一欄比其他兩欄寬一個像素，而最後兩列比第一列各寬一個像素，任何位置都沒有像素遺失。
命名規則已將這種情況納入考量。當最後一列或最後一欄比其他的大一個像素時，檔名——photo-row-3-column-3.png——會清楚標示哪一張拼磚是額外寬的那一張，而每張拼磚的尺寸顯示會精確告訴你多了多少。你不需要打開拼磚才能判斷哪一張比較寬;在下載之前，工具就會回報。
9 格拼磚組合的實際應用場景
最常見的用途是在個人檔案式動態上的 3 乘 3 貼文，九張小拼磚合在一起會被讀成一張大圖。相同的概念也適用於任何能從「把一張來源照片拆成有序的方形或矩形」中受益的版面:切成條狀以拼接成並排拼貼的桌布、切成一組社群媒體可用拼磚的長條 banner、分別裁切以作為縮圖的產品照，或是把一幅藝術作品拆成方便列印或分享的局部。
閱讀順序式的命名在這些工作流程中會產生實質的差異。如果拼磚預期要依序上傳，像 photo-row-2-column-1.png 這類檔名一開始就能正確排序，而每張拼磚的尺寸顯示讓你能在開始上傳前先驗證順序。如果拼磚要在一種各自獨立的版面中使用——例如一個 4 乘 4 的網格，每張拼磚成為輪播中的一張投影片——有名稱的檔案仍然有助於追蹤每一張拼磚在來源照片中的來源位置。
Image Grid Splitter 並不會把拼磚打包成 ZIP、不會為印刷加上出血、不會辨識來源中的人臉或面板，也不會產生重疊或加邊框的拼磚。對於那些工作流程——印刷出血、面板感知擷取、ZIP 交付——具備手動切割位置的完整編輯器會更合適。至於從一張矩形照片直接產出標準的九張拼磚組合，這正是這個工具專注的工作。
Limits to Know Before You Click Split
A few constraints are worth flagging before you load a photo:
- File type and size. Inputs are browser-decodable JPG, PNG, or WebP up to 25 MiB. Decoded images must stay within 20,000 pixels per side and 40 megapixels total. Beyond those limits, the tool refuses the input with a visible error rather than producing partial output.
- Loss of source metadata. Because every output is PNG, a JPEG or WebP source is decoded and re-encoded as PNG; the visible pixel region is preserved exactly, but EXIF, XMP, ICC, and the original compression bytes are not carried over to the tiles.
- Uniform rectangular grid only. The tool produces one rectangular row-by-column grid. It does not detect faces, snap to panels, produce overlapping or non-rectangular slices, or add gutters or borders between tiles.
- No ZIP packaging. Tiles are downloaded one by one. If a single archive is needed, download them and zip them locally.
- One image at a time. Each split processes a single source; switching sources or changing either grid value invalidates the previous result list, and temporary browser URLs are revoked when they are replaced.
If any of those limits are blockers — for example, the source EXIF must be preserved on every tile, overlapping slices are required, or more than 100 tiles are needed in one go — this is not the right tool. For a clean, ordered, locally-processed nine-tile set from one rectangular photo, the Image Grid Splitter is the focused option.
If you're weighing options, Image to ASCII on Android: Convert Photos in Your Browser covers this in detail.
If you're weighing options, Plain Color Background Image: Create It at Any Pixel Size covers this in detail.