產品圖片命名規範：別再送出那張舊圖

上週那份報價，是用 2024 年的一張圖算出來的。客戶照舊款底座報了價，你出的是新款底座，接著吵的不是工藝也不是價格，而是「到底哪張圖才算數」。那張圖的檔名，沒告訴你們任何一個人答案。

產品圖片命名規範，是一套固定、可被機器排序的命名格式，統一套在每个 SKU 的每一張圖上：不必打開檔案，就能看出是哪個產品、哪個視角、第幾版、哪天定稿；兩個國家的人看同一批檔案，也能一眼分出哪張是現行的。它不是潔癖式的整齊，而是你手上唯一低成本的證據——證明你核可的圖，就是送出去的那張。

以下說明這套格式、真正承載資訊的欄位、檔名會在哪三個地方出問題，以及在不弄壞線上 listing 的前提下整理舊圖庫的順序。

產品圖片命名規範要解決的三件事

檔名有三個用途，多數供應商只按第一個設計。

第三件事最花錢。拿不出核可文件的那一刻，客戶說「這不是我們談好的表面處理」，你幾乎沒有辯解空間——即使處理得完全正確。資料夾裡「最新的那張」叫 (1)，這種資料夾裡沒有人能還原三月到底寄過什麼。

五個欄位，順序固定

順序比用詞更重要：欄位順序一旦固定，單純的字母排序就能得到可用清單——同一個 SKU 聚在一起，視角順序固定，最新版本排在最後。

完整檔名是 SM-CB-1200_front_v03_2026-10-29.jpg——38 個字元，沒有空白，沒有需要轉義的符號，在 Finder、檔案總管與雲端硬碟裡都排得對。

SKU 放第一位，是因為客戶的歸檔系統就按 SKU 建立：那是採購單上的號碼。用產品名開頭（例如 walnut-cabinet-1200mm-2.jpg），一旦同一個櫃子做兩種表面處理，這個 SKU 的圖就被打散到字母表各處。日期單獨成欄位，是因為版本說明「改了什麼」，日期說明「客戶何時看得到」；半年後客戶來追究，能定案的是日期。

**記住這一句：**檔名不是標籤，它是你核可過哪張圖的唯一紀錄。

視角欄位：封閉清單，不是形容詞

視角一旦允許自由填寫，規範就會失效。把清單收斂到你真的會寄出的那幾個值。

九個值大致涵蓋 B2B 詢價。真要加第十個，先寫進清單再使用——只存在某個人腦子裡的約定，不算約定。

dim 與 scale 最常被混用。dim 是量出來的標註圖，scale 是含參照物的場景圖。客戶在算能不能過門，要的是 scale；客戶在填報價單，要的是 dim。兩張擠在同一個名字下，轉出去的多半是錯的那張。

版本號與日期不是同一件事

版本回答「是不是同一款產品」，日期回答「從哪天起這份檔案生效」。只要重拍一次而產品沒變——背景更乾淨、表面處理打光更好——兩者就會分開，而這正是最容易產生爭議的情況：產品看起來略有不同，客戶就以為規格動了。

三條規則，寫在團隊看得到的地方：

• 只有產品、表面處理或尺寸變更，版本才進位。 只改打光的重拍，版本不動、日期更新；兩張都要留，就在末尾加 -res：SM-CB-1200_front_v03_2026-10-29-res.jpg。
• 核可檔案的名字永不改變。 出新圖時，舊圖移進 archive/，名字原樣保留——不改名成 old，更不覆蓋。
• archive 裡的檔案不對外寄送。 客戶要上一季的圖，就帶著它自己的日期改名後寄出，檔案仍然能自我說明。

最後這條正是版本欄位的意義：同名檔案被覆蓋後無法自證，你證明不了寄過什麼，客戶也證明不了收到什麼。同一套紀律也出現在產品規格變更清單裡——版本必須同時走到每一份文件上。

一個實例：一次詢價，六個檔案

客戶問 1200 mm 胡桃木櫃、900 mm 版本，以及平板包裝的外箱。回覆就是六個檔案，靠名字就能挑出來：

兩件事直接從表裡浮出來，40 張亂放的圖給不了：兩個型號的拍攝日期差了兩週，日期讓這件事可見——客戶問 900 mm 有沒有換新鉸鏈時正好用得上；每個檔案都寫明自己的用途，工程師、貨代、展示間主管各取所需，不必再寄一封信。

這和單一 SKU 規格頁是同一個原則：一個 SKU、一頁、一件事。產品圖片命名規範就是把它套在頁面背後的檔案上，也正是家具 listing 標註案例能複製到整本型錄、而不只是一次性展示的原因。它同時是跨平台重複使用產品圖片的前提——不必猜這張素材屬於哪個通路。

檔名會出問題的三個地方

這三條都不是美感意見，每一條都會悄悄把圖庫切成兩半。

1. 路徑長度：Windows 的 260 個字元

Windows 完整路徑上限是 260 個字元，單一檔名 255 個。在測試資料夾裡好好的檔案，到了客戶下載目錄再套三層就變成「打不開」。冗長的描述性檔名加上深層資料夾，就是這樣把好檔案變成「找不到檔案」。

把檔名控制在 60 個字元內、路徑控制在 150 個字元內，問題就不會發生。這也是不要把產品標題塞進檔名的原因：它很長、和 SKU 重複，而且是最先被截掉的部分。

2. 保留字元、空白與大小寫

Windows 禁用 < > : " / \ | ? *，也保留 CON、PRN、AUX、NUL 這類裝置名稱。放進 URL 之後，其餘符號會被改寫：空白變成 %20，# 把連結截斷在錨點，? 把後面全變成查詢字串。檔案在你電腦上能開，寄到通訊軟體裡就是 404。

大小寫是更安靜的坑：Windows 與 macOS 預設不區分大小寫，SM-CB-1200_front.jpg 與 sm-cb-1200_front.jpg 在 Mac 上是同一個檔案，在 Linux 伺服器上卻是兩個物件。兩張都上傳，你說不清 listing 顯示的是哪張。

只用小寫字母、數字、連字號與點。連字號能穿過任何用戶端、閘道與 URL 解析器，底線和空白不行。

3. 重音符號與 Unicode 正規化

兩個字元看起來一樣，位元組卻可能不同。「é」可以是預組合的單一字元，也可以是 e 加組合重音；macOS 比較檔名時不區分正規化形式，Linux 伺服器與物件儲存通常會區分。把資料夾從 Mac 複製到伺服器，一個帶重音的名字可能變成兩個檔案，或更糟——一個覆蓋另一個。

如果型錄裡有重音字元或中文，檔名保持 ASCII，在地語言名稱放進產品資料裡。這樣同一份檔案在鏈條上每台機器都能用。

還有第四個坑，跟名字本身無關：CDN 是依 URL 取檔案的，把同名檔案替換掉之後，快取還會繼續送舊圖。檔名帶版本，這個問題免費解決——新版本就是新 URL，沒有陳舊內容要清除，URL 本身還兼作稽核線索。

已經存在的圖庫怎麼整理

把產品圖片命名規範套到既有圖庫上，是所有人都會往後拖的那一步。別從四千個檔案開始，從「還在線上」的檔案開始。

1. 從報價系統匯出 SKU 清單，不要從圖片資料夾匯出——資料夾缺在售 SKU，還躺著一堆已停產的。
2. 標出近 12 個月進過 listing、型錄或報價的 SKU，通常是庫裡的 10% 到 20%。
3. 只改這些，從最新的核可檔案改起，舊版本按原名移進 archive/。
4. 當天同步更新引用：改過名就是新 URL，還指向舊路徑的地方會直接報錯，而不是悄悄錯著。
5. 長尾部分等要用到时再說。200 個在售 SKU 上真正執行的規則，勝過一條誰都沒落實的完美規範。

一次性全量改名的失敗模式很典型：週五改了一個資料夾，週末 listing 空白，這套規範就被定性為「搞壞網站的那件事」。按「已經發布的內容」排優先順序，遷移花一小時，不是一週。

寄出前檢查清單

• 檔名以 SKU 開頭，SKU 與紙箱、報價單印的完全一致
• 視角值取自封閉清單，不是憑記憶敲的
• 版本號只因為產品、表面處理或尺寸變更才進位
• 日期是定稿日，不是拍攝日
• 只有連字號，全小寫，無空白、無重音、無 # 與 ?
• 檔名 60 個字元以內，套三層資料夾後仍能打開
• 舊版本在 archive/ 裡，原名完整保留
• 線上 listing、型錄頁、已送出的報價都指向現行檔案
• dim 與 scale 兩張沒有對調

常見問題

產品圖片該怎麼命名比較好？

用 SKU_視角_版本_日期.副檔名，全小寫，欄位順序固定。它承載同事與客戶都需要的四個事實——哪個產品、哪個視角、第幾版、何時核可——而且在任何檔案瀏覽器裡都能正確排序，不依賴資料庫。

檔名裡 SKU 放前面還是產品名放前面？

一定是 SKU。它出現在採購單、紙箱與發票上，是客戶歸檔系統的鑰匙。產品名會隨市場、表面處理與語言變化，按產品名排序，一旦多出一個表面處理，同一個 SKU 就會被拆到字母表兩端。

產品圖片檔名要避開哪些字元？

避開空白、#、?、%、&、<、>、:、"、/、\、|、*，以及重音與非拉丁字元。Windows 直接禁用其中幾個，空白在 URL 裡變成 %20，# 會悄悄截斷連結。連字號是最安全的分隔符號。

同一產品的不同視角該怎麼命名？

每個視角固定一個封閉清單裡的詞——front、main、dim、detail、scale、pack、assembled、packed、break——永遠不要為一次臨時需求造新詞。正是這份清單讓字母排序表現得像聯絡表：同一個 SKU 的所有視角聚在一起，順序永遠一致。

圖片換了，版本號該放在哪？

緊接視角欄位、放在日期之前；只有產品、表面處理或尺寸變更才進位，打光變好不進位。只改了曝光的重拍，版本不動、換新日期。檔案本身必須變、版本又不能動時，在末尾加 -res 這類後綴，讓兩份檔案永遠可區分。

如果版本是因為尺寸變更才跳的，光改名救不了：舊圖上的數字已經和產品對不上。這時流程才顯出價值——量一次，把數值鎖到照片上產品真實的邊緣，依各通路要求的尺寸重新匯出，新版本來自同一個資料源，而不是靠眼睛重畫。生成的場景圖可以讓畫面好看；dim 檔案上只能放量出來的數。

來源與依據

• Microsoft Learn — Naming Files, Paths, and Namespaces（保留字元、保留裝置名稱、260 字元路徑上限）
• RFC 3339 — Date and Time on the Internet: Timestamps（源自 ISO 8601 的 YYYY-MM-DD 日期格式）
• GS1 — GTIN 商品識別代碼
• Unicode Standard Annex #15 — Unicode 正規化形式（預組合字元與組合字元）
• RFC 3986 — URI：保留字元與百分號編碼
• AWS — 在 CloudFront 中讓檔案失效（快取物件以請求路徑為鍵）