Naming convention ng product image: huwag magpadala ng luma

Ang quote na ipinadala mo noong isang linggo ay ginawa mula sa litratong kuha noong 2024. Nagpresyo ang buyer gamit ang lumang base, ipinadala mo ang bago, at ang naging away ay hindi tungkol sa teknikal o presyo — tungkol ito sa kung aling file ang totoo. Wala sa pangalan ng litratong iyon ang makapagsasabi sa inyong dalawa.

Ang naming convention ng product image ay isang fixed at machine-sortable na pattern na inilalapat sa bawat litrato ng bawat SKU, para makilala ang isang file — produkto, view, bersyon, petsa — nang hindi ito binubuksan, at para malaman ng dalawang tao sa dalawang bansa kung alin ang kasalukuyan. Hindi ito usapin ng kaayusan. Ito ang pinakamurang ebidensya na mayroon ka na ang litratong inaprubahan mo ay ang litratong naipadala.

Narito ang pattern na tumatagal ng limang taon sa katalogo, ang mga token na talagang may dalang impormasyon, ang tatlong lugar kung saan nasisira ang pangalan, at ang tamang pagkakasunod-sunod sa pagpapalit ng pangalan ng lumang library nang hindi masisira ang mga aktibong listing.

Ano ang dapat gawin ng naming convention ng product image

Tatlo ang trabaho ng pangalan ng file, at karamihan sa supplier ay isa lang ang dinisenyo.

Ang ikatlong trabaho ang magastos. Sa sandaling hindi mo maipresenta ang inaprubahang file, halos walang isasagot sa "hindi ito ang pinagkasunduang finish" ng buyer, kahit perpekto ang finish. Sa folder kung saan ang pinakabagong file ay tinatawag na (1), walang makakabuo muli kung ano ang ipinadala noong Marso.

Limang token, sa ganitong pagkakasunod-sunod

Mas mahalaga ang ayos kaysa bokabularyo. Kapag fixed ang sequence, ang simpleng alphabetical sort ay gumagawa ng gamitin na listahan: magkakasama ang isang SKU, fixed ang ayos ng view, huli ang pinakabagong bersyon.

Ang buong pangalan ay SM-CB-1200_front_v03_2026-10-29.jpg — 38 character, walang puwang, walang simbolong kailangang i-escape, at tama ang sort sa Finder, Explorer, at Drive.

Nauuna ang SKU dahil naka-index sa SKU ang filing ng buyer: iyon ang numero sa purchase order. Ang pangalang nagsisimula sa pangalan ng produkto (walnut-cabinet-1200mm-2.jpg) ay nagkakalat ng isang SKU sa buong alphabet kapag may dalawang finish na ang parehong cabinet. Hiwalay ang petsa dahil sinasabi ng bersyon kung ano ang nagbago at ng petsa kung kailan ito nakita ng buyer; kapag dumating ang reklamo makalipas ang anim na buwan, ang petsa ang magpapasya.

Tandaan ang isang linyang ito: ang pangalan ng file ay hindi label, ito ang tanging rekord kung aling litrato ang inaprubahan mo.

Ang token ng view: closed list, hindi pang-uri

Kapag pinayagang magsulat ng sarili ang view, namamatay ang convention. Isara ang listahan sa mga value na talagang ipinapublish mo.

Siyam na value ang sumasaklaw sa halos lahat ng B2B na tanong. Kapag may ikasampu, isulat muna sa listahan bago gamitin: ang convention na nasa isip lang ng isang tao ay hindi convention.

Madalas magkamali sa dim at scale. Ang dim ay ang sinukat na guhit; ang scale ay ang litrato na may reference. Ang buyer na nagtatanong kung kasya sa pinto ay kailangan ang scale; ang nagfifill-up ng quote ay kailangan ang dim. Kapag nasa isang pangalan ang dalawa, ang mali ang naipapasa.

Hindi magkapareho ang bersyon at petsa

Sinasagot ng bersyon ang "kapareho ba ito ng dating produkto"; ng petsa ang "mula kailan naging opisyal na file ito". Naghihiwalay sila sa sandaling muling kunan ng litrato nang walang pagbabago sa produkto — mas malinis na background, mas magandang ilaw sa finish — at iyon mismo ang kaso na nagdudulot ng reklamo, dahil bahagyang iba ang itsura at iniisip ng buyer na gumalaw ang specification.

Tatlong tuntunin, nakasulat sa lugar na nakikita ng team:

• Tumataas lang ang bersyon kapag nagbago ang produkto, finish, o sukat. Ang reshoot na ilaw lang ang binago ay pinapanatili ang bersyon at kumukuha ng bagong petsa; kung kailangang itago ang dalawa, dagdagan ng -res: SM-CB-1200_front_v03_2026-10-29-res.jpg.
• Pinapanatili ng inaprubahang file ang pangalan nito habang-buhay. Kapag may bagong file, lumilipat ang luma sa archive/ nang buo ang pangalan — hindi pinapalitan ng old, hindi ino-overwrite.
• Walang ipinapadala mula sa archive/. Kapag hinihingi ng buyer ang litrato ng nakaraang season, lumalabas ito na may sariling petsa sa pangalan, kaya nagpapakilala pa rin ang file.

Ang huling tuntunin ang dahilan ng token ng bersyon: ang file na na-overwrite sa parehong pangalan ay hindi maipapatunay. Hindi mo maipapakita ang ipinadala, at hindi rin ito maipapakita ng buyer. Lumilitaw ang parehong disiplina sa checklist ng pagbabago ng product specification, kung saan kailangang makarating ang bersyon sa lahat ng dokumento nang sabay.

Isang halimbawa: isang inquiry, anim na file

Humingi ang buyer ng 1,200 mm walnut cabinet, bersyong 900 mm, at ang flat-packed na karton. Anim na file ang sagot, pinili sa pangalan pa lang:

Dalawang bagay ang lumalabas sa table na hindi maibibigay ng folder na may 40 litratong walang ayos. Dalawang linggo ang pagitan ng shoot ng dalawang modelo, at nakikita ito sa mga petsa — kapaki-pakinabang kapag tinanong kung may bagong hinge ang 900 mm. At sinasabi ng bawat file ang sariling trabaho, kaya kumukuha ang engineer, forwarder, at showroom manager ng kailangan nila nang walang ikalawang email.

Pareho ito sa prinsipyo ng spec sheet para sa isang SKU: isang SKU, isang pahina, isang trabaho. Ang naming convention ng product image ay ang prinsipyong iyon na inilapat sa mga file na bumubuo sa pahina, at iyon ang dahilan kung bakit naipapasa ang case study ng annotation sa furniture listing sa buong katalogo, hindi isang beses lang na demo. Ito rin ang kailangan para magamit muli ang mga litrato ng produkto sa iba't ibang platform nang hindi hinuhulaan kung aling channel ang may-ari ng bawat asset.

Tatlong lugar kung saan nasisira ang pangalan

Wala sa mga ito ang opinyon sa estilo. Bawat isa ay tahimik na hinahati ang library sa dalawa.

1. Haba ng path: 260 character sa Windows

Nililimitahan ng Windows ang buong path sa 260 character, at 255 para sa isang pangalan. Ang file na bukas sa test folder ay hindi na mabubuksan tatlong folder ang lalim sa download directory ng kliyente. Mahabang deskriptibong pangalan kasama ng malalim na folder ang paraan para maging "file not found" ang isang magandang file.

Panatilihin ang pangalan sa ilalim ng 60 character at ang path sa ilalim ng 150, at hindi mangyayari ang problema. Ito rin ang praktikal na dahilan para huwag isama ang titulo ng produkto: mahaba ito, doble sa SKU, at unang natatabasan.

2. Reserved character, puwang, at capitalization

Ipinagbabawal ng Windows ang < > : " / \ | ? * at nirereserba ang mga pangalang tulad ng CON, PRN, AUX, NUL. Sa URL, nasisira ang iba pa: nagiging %20 ang puwang, pinuputol ng # ang link sa fragment, at ginagawang query string ng ? ang natitira. Bukas ang file sa laptop mo at 404 sa chat app.

Ang capitalization ang mas tahimik na bitag: hindi naghihiwalay ang Windows at macOS sa malaki at maliit na titik bilang default, kaya ang SM-CB-1200_front.jpg at sm-cb-1200_front.jpg ay isang file sa Mac at dalawang object sa Linux server. I-upload ang dalawa at hindi mo masasabi kung alin ang ipinapakita ng listing.

Maliit na titik, numero, hyphen, at tuldok lang. Dumadaan ang hyphen sa lahat ng client, gateway, at URL parser; hindi dumadaan ang underscore at puwang.

3. Accent at Unicode normalization

May mga character na magkamukhang pareho pero magkaibang bytes. Ang "é" ay puwedeng isang precomposed character o e kasama ang combining accent; hindi naghihiwalay ang macOS sa normalization kapag naghahambing ng pangalan, samantalang ang Linux server at cloud storage ay karaniwang naghihiwalay. Kopyahin ang folder mula sa Mac papuntang server at ang pangalang may accent ay puwedeng maging dalawang file — o mas malala, mag-overwrite ang isa sa isa.

Kung may accent o Chinese character ang katalogo, panatilihing ASCII ang pangalan ng file at ilagay ang lokal na pangalan sa product data, para gumana ang parehong file sa lahat ng makina sa kadena.

May ikaapat na pagkasira na hindi tungkol sa pangalan: ipinapasa ng CDN ang file sa URL nito, at patuloy na ibinibigay ng cache ang lumang larawan pagkatapos mong palitan ang file sa parehong path. Ang token ng bersyon ay libre ang solusyon — bagong bersyon, bagong URL, walang stale na kailangang i-invalidate, at ang URL pa mismo ang nagsisilbing audit trail.

Pagpapalit ng pangalan sa library na mayroon ka na

Ang paglalapat ng naming convention ng product image sa lumang library ang laging ipinagpapaliban. Huwag magsimula sa 4,000 file; magsimula sa mga buhay pa.

1. I-export ang listahan ng SKU mula sa quotation system, hindi sa photo folder — kulang ang folder sa aktibong SKU at puno ng patay.
2. Markahan ang SKU na lumabas sa listing, katalogo, o quote sa nakaraang 12 buwan — karaniwang 10 hanggang 20 porsiyento ng library.
3. Palitan ang pangalan ng mga iyon lang, simula sa pinakabagong inaprubahang file, at ilipat ang lumang bersyon sa archive/ nang hindi binabago ang pangalan.
4. I-update ang mga reference sa parehong araw: bagong pangalan, bagong URL, kaya ang tumuturo pa sa lumang path ay mababali nang nakikita, hindi tahimik.
5. Iwanan ang mahabang buntot hanggang kailanganin. Ang tuntuning ipinatutupad sa 200 aktibong SKU ay mas mabuti kaysa perpektong convention na walang sumusunod.

Kilala ang failure mode ng big-bang rename: may nagpalit ng pangalan ng folder noong Biyernes, blangko ang listing sa weekend, at itinapon ang convention bilang "ang bagay na sumira sa site". Ayusin ang trabaho ayon sa na-publish na, at isang oras lang ang migration, hindi isang linggo.

Checklist bago ipadala

• Nagsisimula ang pangalan sa SKU, kapareho ng nakalimbag sa karton at quote
• Galing sa closed list ang value ng view, hindi sa memorya
• Tumataas ang bersyon dahil lang sa pagbabago ng produkto, finish, o sukat
• Ang petsa ay petsa ng pag-apruba, hindi ng shoot
• Hyphen lang, maliit na titik, walang puwang, walang accent, walang # o ?
• Wala pang 60 character ang pangalan at bukas pa rin tatlong folder ang lalim
• Nasa archive/ ang lumang bersyon nang buo ang orihinal na pangalan
• Tumuturo sa kasalukuyang file ang bawat aktibong listing, catalog page, at naipadalang quote
• Hindi napagpalit ang dim at scale

FAQ

Ano ang magandang naming convention para sa product image?

SKU_view_version_date.extension, lahat maliit na titik, fixed ang ayos ng token. Dinadala nito ang apat na katotohanang kailangan ng katrabaho o buyer — aling produkto, aling view, anong revision, kailan inaprubahan — at tama ang sort sa kahit anong file manager nang walang database.

SKU o pangalan ng produkto ang dapat mauna sa pangalan ng file?

SKU, palagi. Nasa purchase order, karton, at invoice ito, kaya iyon ang numerong naka-index sa filing ng buyer. Nagbabago ang pangalan ng produkto ayon sa market, finish, at wika, at ang library na naka-sort sa pangalan ng produkto ay hinahati ang isang SKU sa dalawang dulo ng alphabet kapag may ikalawang finish.

Anong character ang dapat iwasan sa pangalan ng file ng product image?

Iwasan ang puwang, #, ?, %, &, <, >, :, ", /, \, |, *, at accent o non-Latin na character. Ipinagbabawal ng Windows ang ilan, nagiging %20 ang puwang sa URL, at tahimik na pinuputol ng # ang link. Ang hyphen ang pinakaligtas na separator.

Paano pangalanan ang mga litrato ng iba't ibang view ng parehong produkto?

Bigyan ang bawat view ng isang fixed na token mula sa closed list — front, main, dim, detail, scale, pack, assembled, packed, break — at huwag kailanman gumawa ng bagong salita para sa isang beses na request. Ang listahang iyon ang dahilan kung bakit parang contact sheet ang alphabetical sort: magkakasama ang lahat ng view ng isang SKU, laging pareho ang ayos.

Saan nakalagay ang version number kapag nagbago ang litrato?

Kaagad pagkatapos ng token ng view at bago ang petsa; tumataas lang kapag nagbago ang produkto, finish, o sukat, hindi kapag gumanda ang ilaw. Ang reshoot na exposure lang ang binago ay pinapanatili ang bersyon at kumukuha ng bagong petsa. Kapag kailangang magbago ang file at hindi puwedeng gumalaw ang bersyon, magdagdag ng suffix tulad ng -res para manatiling makilala ang dalawang file habang-buhay.

Kapag tumalon ang bersyon dahil nagbago ang sukat, hindi kayang ayusin ng pagpapalit ng pangalan: may dalang numero na ang lumang guhit na hindi na tugma sa produkto. Dito kumikita ang workflow — sukatin isang beses, i-lock ang value sa totoong gilid ng produkto sa litrato, at i-export muli sa sukat na hinihingi ng bawat channel, para ang bagong bersyon ay mula sa parehong source sa halip na guhitan muli gamit ang mata. Nakakapagpaganda ng itsura ang generated na scene; sa dim na file, sinukat na value lang ang puwedeng ilagay.

Mga sanggunian

• Microsoft Learn — Naming Files, Paths, and Namespaces (reserved characters, reserved device names, 260-character path limit)
• RFC 3339 — Date and Time on the Internet: Timestamps (ang YYYY-MM-DD na format na nagmula sa ISO 8601)
• GS1 — GTIN, mga identification key ng trade item
• Unicode Standard Annex #15 — Unicode normalization forms (precomposed at combining characters)
• RFC 3986 — URI: reserved characters at percent-encoding
• AWS — Pag-invalidate ng mga file sa CloudFront (naka-key sa request path ang mga cached object)