1. 問題摘要

在 iOS (iPhone 13, iOS 17.x) 環境下，透過 X(前 Twitter) 應用程式 保存的圖片，若直接從 iPhone 照片應用程式上傳至 GPT，會發現該圖片的 MIME-type 未被正確識別，導致 Action API 請求時被處理為 null，從而產生 400 錯誤。儘管圖片格式為 JPEG，OpenAI 的文件服務卻無法正確推斷 MIME。

2. 發生條件

  • 使用設備: iPhone 13 (iOS 17.x)
  • 上傳方式: 從照片應用程式直接上傳至 GPT
  • 圖片生成路徑: 通過 X 應用程式下載按鈕保存
  • 檔案格式: JPEG (根據 EXIF 資訊和壓縮方式)
  • 副檔名標示: .jpeg 或 .JPEG (照片應用程式) → .jpg (在 Ubuntu 中通過 Nextcloud 連接時確認)
  • 照片應用程式運作: 將 X 應用程式保存的圖片自動分類到相簿

3. 實驗結果摘要

實驗條件 來源 副檔名 MIME 推斷值 結果
從照片應用程式上傳 X 圖片 X 應用程式下載 .jpeg null ❌ 失敗
複製到檔案應用程式/Nextcloud 後上傳 X 圖片副本 .jpg image/jpeg ✅ 成功
將相同圖片上傳至 Ubuntu Nextcloud 同步的資料夾 .jpg image/jpeg ✅ 成功

4. 分析與推測原因

4.1 X 應用程式的元資料干擾可能性

  • 如 com.apple.metadata:kMDItemWhereFroms 等 iOS 專用元標籤可能會干擾 MIME-type 的推斷

4.2 副檔名與內部格式的不一致

  • 在 iOS 中標示為 .jpeg，但在 Ubuntu 等環境中則處理為 .jpg，導致平台間的推斷方式存在差異

4.3 GPT 指定的 MIME-type 被忽視

  • 儘管 GPT 指定為 image/jpeg，OpenAI 的文件服務卻忽視此項，將其自行處理為 null

5. 建議與應對方向

5.1 用戶端應對

  • 請勿從照片應用程式直接上傳由 X 應用程式保存的圖片
  • 建議通過檔案應用程式或 PC/Mac 將圖片檔案轉移後上傳

5.2 向 OpenAI 及 Action SDK 改進請求

  1. 改善對 .jpeg 副檔名的 MIME-type 推斷
  2. 避免忽視 GPT 指定的 MIME-type，改進 SDK
  3. 考慮不依賴元資料而基於 Content-Sniffing 的 Fallback 處理

6. 參考資料提供可能項目

可在請求時提供以下資料： - iOS 照片應用程式與 Ubuntu 環境下的元資料比較螢幕截圖 - 在 Ubuntu 中提取的媒體屬性信息 - GPT 指定的 mime_type 被忽視的實際請求日誌