照片上傳後為什麼會變成橫的？

你用手機拍商品，把機身轉直，按下快門。螢幕上看起來是正的。到了電商平台的上傳表單裡，它卻躺著出現——同一個檔案，差了四分之一圈。

這不是你的手機壞了。那張照片在檔案裡很可能真的是橫躺的，而且從你按下快門那一刻起就是。你的手機不管怎樣都會把它擺正給你看。上傳表單沒有。

你的檔案處於兩種狀態的其中一種，而分辨它們只需要檢查一件事。

相機是照著感光元件看到的樣子存檔

感光元件是一塊鎖死在手機上的固定矩形；你轉，它不會跟著轉。你拍一張直式照片，它記錄下來的仍然是一個橫幅的畫面，你的主體就躺在裡面。

很多相機不想重寫幾百萬個像素，改成在中繼資料裡寫下一個小小的數字，意思是「顯示前先把它轉四分之一圈」。另一些則在存檔時就把像素轉好，並把檔案標記成已經是正的——這就是為什麼同一個場景，兩支手機的表現會不一樣。在 JPEG 裡，那個數字就是 Exif 標籤 274，也就是 Orientation，它除了旋轉，也能描述鏡像的畫面。

有些程式尊重旗標，有些直接無視

現代瀏覽器確實會讀它。CSS 的 image-orientation 屬性初始值是 from-image；MDN 講得很直白：「圖片中包含的 EXIF 資訊會被用來把圖片適當地旋轉。」這在各家瀏覽器上從 2020 年 4 月起就都成立了。

不是瀏覽器的東西，還是可能無視這個標籤。網頁標準已經一致往尊重它的方向靠攏，但很多伺服器端的解碼器、縮圖產生器和影像函式庫是在這之前寫的，根本不會去看那個標籤——也沒有任何規定強迫它們看。

所以問題從來不是「我的照片是不是橫的」，而是「顯示它的那個東西有沒有讀旗標」。你的相簿有讀。電商平台的縮圖產生器可能沒有。

在相簿裡旋轉，可能只改寫了旗標

按下旋轉鍵，結果取決於那個 App。可能發生的是兩件非常不同的事。

• App 只改方向值，像素資料原封不動。瞬間完成、無損，但對任何無視旗標的程式來說完全看不見：你的照片在檔案裡還是橫躺的。
• App 重新編碼：把像素解碼、轉正，再寫出一個旗標已歸零的新檔案。旋轉被烙進畫面，到哪裡都成立。PNG 或無損 WebP 這樣做不用付出代價；JPEG 通常要付出一次重新編碼的世代損失，值得付一次，不值得反覆付。

一個 App 走哪條路，從按鈕上看不出來，而且同一個 App 的不同版本之間也可能改變。什麼都別假設；檢查輸出。

更糟的是那種把像素轉了、卻原封不動複製舊中繼資料的工具：旗標還寫著「請旋轉」，像素卻早就轉好了，於是尊重旗標的程式會把照片轉兩次。

怎麼判斷你的檔案是哪一種狀態

這件事沒辦法靠盯得更用力來解決，只能去檢查預覽以外的東西。

• 拿外觀和數字對照。如果一張看起來是直式的照片，在檔案的屬性裡卻回報寬大於高，那麼像素就是橫的，正在做事的是旗標。有些看圖軟體連這組數字也會一併修正，所以對不上比對得上更能說明問題。
• 直接讀旗標本身。瀏覽器、桌面看圖軟體和檔案總管縮圖現在幾乎都尊重這個標籤，所以它們彼此一致證明不了什麼。請對副本操作，絕對不要動原檔，用 Exif 檢視工具打開它，直接讀 Orientation。只要不是 1（通常顯示為「Normal」），就代表正在做事的是旗標，而像素並不是正的。

在其他任何處理碰到檔案之前，先把方向定下來

remover.bg 接受 25 MB 以內的 PNG、JPEG 和 WebP，回給你一個背景已經移除的新檔案。它是去背工具，不是修圖軟體：旋轉屬於你手機的照片編輯器或設計軟體，而且要在上傳之前完成。

這個順序之所以重要，是因為你正在產生一個新檔案。PNG 和 WebP 容器都有地方可以放 Exif——Google 的 WebP 規格允許中繼資料放「在 'EXIF' 或 'XMP ' 區塊裡」——但你用來旋轉的那個編輯器輸出時到底寫不寫，是那個編輯器的決定，不是你的。把旋轉烙進像素，就沒有旗標可以弄丟了。這個格式的細節請看我們的支援 WebP：直接上傳與輸出，免轉檔。

可行的順序：

1. 在編輯器裡旋轉並輸出一份副本，而不是在相簿裡按旋轉。
2. 檢查那份輸出副本的 Orientation 值。
3. 把它上傳去背。
4. 把去背圖放到純色或你自己的照片上，如果它需要落在平面上，就加一道投影。

透過 HTTP API 大量處理的團隊——也就是走去背 API — 自動移除圖片背景那一套的人——應該先在流程裡把方向正規化：一張橫躺的來源圖會變成一張橫躺的去背圖，重複一千次。方向不在我們Amazon 商品圖規範：白底規則完整解析談的背景規則裡，但一則躺著的刊登，不管其他地方做得多對，看起來都很隨便。

值得養成的習慣

相信檔案，不要相信預覽。用輸出的方式旋轉，並在副本上讀一次 Orientation；接下來，這張照片在瀏覽器裡、在縮圖產生器裡、在印刷廠的佇列裡，都會是正的。