Skip to main content

​
圖片與影片發布規範

當你將貼文發布到社群網路時，遵循每個平台的規範相當重要。 遵循這些準則可以確保你的貼文被社群網路接受，並觸及目標受眾。 更多細節請參閱 post 端點。

​
可接受的檔案類型

檔案有可接受的副檔名，例如 jpg、jpeg、png、 webp、gif、mp4、mov 或 avi，其 content-type 如 image/jpeg 或 video/mp4。 此外，LinkedIn 接受以下副檔名的檔案類型：ppt、 pptx、doc、docx 和 pdf。 如果媒體 URL 含有特殊字元（例如 ñ），請先將這些特殊字元編碼再送出。 各平台的詳細規範請見下方。
自動圖片格式轉換。 WebP、HEIC、HEIF 和 AVIF 來源圖片在發布到不原生支援的平台之前，會自動轉換為 JPEG。WebP 會為 Instagram、LinkedIn、TikTok、Google My Business、Threads 和 Snapchat 進行轉換；HEIC、HEIF 和 AVIF 則會在所有支援的平台上進行轉換。轉換會在發送時透明地執行，因此你可以透過 mediaUrls 提交任何這些格式，Ayrshare 會代為處理目標平台上的格式問題。下方每個平台的「支援的格式」清單描述了每個網路在傳輸層最終接受什麼格式；你不需要事先轉換。失敗模式（狀態碼 450、451、452）請參閱 圖片格式轉換錯誤。當圖片被轉換時，內嵌 metadata 的處理方式請參閱 圖片 Metadata 與 Content Credentials。

​
最大圖片數量

每個平台在單則貼文中可接受的最大圖片數：
  • Bluesky：4 張圖片。
  • Facebook Pages：10 張圖片，包含 輪播貼文。
  • Instagram：10 張圖片。
  • Google Business Profile：1 張圖片。
  • LinkedIn：9 張圖片。
  • Pinterest：1 張圖片。
  • Reddit：1 張圖片。
  • Telegram：1 張圖片。
  • Threads：20 張圖片。
  • TikTok：35 張圖片。
  • X/Twitter：4 張圖片。

​
最大影片數量

Bluesky、Facebook、Instagram、LinkedIn、Pinterest、Telegram、Threads、TikTok、X/Twitter 和 YouTube 每則貼文只允許 一 部影片。Reddit 目前尚不支援影片。
請確保你的影片 URL 以可接受的影片副檔名結尾，例如依平台而定的 .mp4 或 .mov。例如：
  • 可接受：https://mysite.com/video.mp4
  • 不可接受：https://mysite.com/video.mp4?code=30s93
如果你的影片是簽章 URL（signed URL）或無法以可接受的影片副檔名結尾，發布貼文時可以使用 isVideo 參數。
我們建議大於 50 MB 的影片檔案，使用 scheduleDate 參數建立排程貼文以進行非同步處理。 也請務必檢查媒體 URL 的上傳速度，以避免在社群網路發生逾時。 如果媒體檔案無法在大約 5 分鐘內下載完成，很可能會發生逾時。

​
標準社群影片規範

每個社群網路都有不同的影片規範。如果你希望影片能發布到 X/Twitter、Instagram、Facebook 和 TikTok 等社群網路，請使用下列標準： 尺寸： 1080 x 1920 px 長度： 60 秒 大小： 50 MB 格式： MP4 直向影片範例： https://img.ayrshare.com/random/portrait5.mp4 你也可以針對 YouTube 這類接受更長更大檔案的平台，建立特定尺寸的影片。各平台的詳細資訊請見下方。 參閱如何為測試 建立隨機影片。

​
Content Type

發布時， 請確認 content-type 設定正確，例如 image/png、image/jpg 或 image/jpeg。

​
安全 URL

發布你自己的媒體 URL 時，連結必須使用 SSL 並以 https:// 開頭。

​
社群網路媒體規範

Bluesky 媒體規範

Facebook 媒體規範

Google Business Profile 媒體規範

Instagram 媒體規範

LinkedIn 媒體規範

Pinterest 媒體規範

Reddit 媒體規範

Snapchat 媒體規範

Telegram 媒體規範

Threads 媒體規範

TikTok 媒體規範

X/Twitter 媒體規範

YouTube 媒體規範

​
Image Metadata and Content Credentials

圖片經常會攜帶內嵌的 metadata：ICC 色彩描述檔、XMP 封包、EXIF 相機資料，或 C2PA Content Credentials manifest。 當圖片是由 AI 工具產生或編輯時，AI 揭露資訊通常會以 Iptc4xmpExt:DigitalSourceType 屬性存在於 XMP 封包中，並且常常也會存在於 C2PA manifest 內。 當目標網路不接受來源格式時，Ayrshare 會將圖片重新編碼為 JPEG，如上方 可接受的檔案類型 所述。 重新編碼會改寫檔案，因此本節精確說明 Ayrshare 會保留什麼、會丟棄什麼，以及各網路如何處理結果。 影片永遠不會被重新編碼，其 metadata 保持不動。

​
轉換時保留的 Metadata

  • 色彩呈現。 廣色域圖片在轉換後看起來與轉換前相同。實現方式取決於來源格式，若你會檢查轉換後的檔案，這個差異值得了解。HEIC 或 HEIF 圖片會保留其原始 ICC 色彩描述檔，並帶入 JPEG。WebP 或 AVIF 圖片則會改為轉換為標準 sRGB，因此即使在會丟棄內嵌描述檔的網路上，顏色仍然正確 — 轉換後的 JPEG 不會攜帶 ICC 描述檔，因為已不再需要。
  • AI 揭露，僅限 AI 揭露。 Ayrshare 會寫入一個新的小型 XMP 封包，其中包含 Iptc4xmpExt:DigitalSourceType — 這是 IPTC 屬性，用來記錄圖片是由相機拍攝、經過編輯，或由演算法產生 — 因此由你的生成工具寫入的揭露會傳遞到網路。此封包是 從頭建立而非複製：來自你圖片原始 XMP 的其他任何內容都不會隨之傳遞。作者與版權欄位、關鍵字、編輯歷史，以及 photoshop:City、Iptc4xmpExt:LocationCreated 等地點欄位都會被留下，因此不會意外發布關於你或照片拍攝地點的任何資訊。請參閱下方的 未保留的 Metadata。
  • 合成的 AI 揭露。 如果 C2PA manifest 主張 AI 來源，但 XMP 封包並未記錄，Ayrshare 會將等效的 Iptc4xmpExt:DigitalSourceType 值寫入輸出 XMP，因此揭露不會隨 manifest 一起遺失。Ayrshare 絕不會自行推論 AI 來源：只有在圖片已攜帶該值時才會傳遞，且僅在 C2PA manifest 有此主張時才會合成。若 AI 生成圖片抵達時兩處皆無揭露，發布時就不會帶有揭露。

​
未保留的 Metadata

  • 除 AI 揭露以外的一切。 轉換後的圖片完全不攜帶任何 EXIF 區塊 — 沒有 GPS 座標，沒有相機廠牌、型號或拍攝時間 — 也不包含原始 XMP 封包中揭露本身以外的任何內容。這包括 dc:creator 和 dc:rights、關鍵字、編輯歷史，以及所有地點欄位、exif:GPS* 及作者輸入文字如 photoshop:City 和 Iptc4xmpExt:LocationCreated。輸出封包是從頭建立而非篩選而來，因此其中唯一能出現的就是揭露資訊。如果你需要作者或版權 metadata 送達某個網路，請以該網路原生接受的格式發布，讓轉換不會發生。
  • 超長的揭露值。 Ayrshare 寫入的封包必須符合 JPEG 中固定的空間大小，若揭露值長到會將封包推過 60,000 位元組，則會被略過而非截斷。實際 IPTC 值只有數十位元組，因此實務上不會發生；此處說明是因為貼文仍會成功且不會回傳警告。請注意，這是對 揭露 本身的限制，而非你圖片的原始封包 — 一個龐大的原始 XMP 不再會讓你失去揭露，因為被寫入的並非原始封包。
  • C2PA 密碼學簽章無法在重新編碼後保留。 C2PA manifest 是針對其所附加檔案的精確位元組進行簽章。將圖片轉換為 JPEG 會產生不同的位元組，因此簽章不再有效，也不會保留下來。揭露 在轉換過程中保留；簽章 則不會。轉換後的圖片在 Content Credentials 驗證器中將無法驗證為已簽章的內容。
請勿依賴轉換後的圖片來證明作者身分或防篡改。若必須有可驗證的 C2PA 簽章，請以目標網路原生接受的格式發布圖片，讓轉換不會發生。

​
何時會發生轉換

  • JPEG 與 PNG 原樣通過。 不進行重新編碼，也不變更 metadata — 你提供的位元組就是網路接收的位元組。
  • WebP 會為 Instagram、Threads、LinkedIn、TikTok、Google Business Profile 和 Snapchat 轉換為 JPEG。
  • HEIC、HEIF 與 AVIF 會針對每個網路轉換為 JPEG。
  • 影片 永遠不會被轉換。
如果你需要確保不會發生重新編碼，請提供 JPEG 或 PNG。

​
各網路如何處理 Metadata

保留 metadata 只走完了一半的路。每個網路會獨立決定在接收時是否保留，以及是否呈現 AI 標籤。 以下結果來自 2026 年 8 月發布的真實貼文，且未設定任何平台 AI 旗標，因此內嵌 metadata 是唯一可能的訊號： Meta 在 Facebook、Instagram 與 Threads 上一致地保留揭露，但依界面呈現標籤：Facebook 和 Instagram 會顯示，Threads 目前則不會。 兩個欄位是彼此獨立的，而 Instagram 就是值得特別說明的原因：它保留 AI 揭露，同時捨棄色彩描述檔。這也是 WebP 與 AVIF 圖片會轉換為標準 sRGB、而非附加描述檔的原因 — 描述檔只有在保留它的網路上才有幫助，而正確的 sRGB 色彩則在任何地方都正確。
溯源 metadata 無法在 LinkedIn 的圖片處理中留存。 LinkedIn 在接收圖片時會移除內嵌 metadata，因此 Iptc4xmpExt:DigitalSourceType 揭露不會出現在已發布的圖片上，也不會套用 AI 標籤。請勿將內嵌 metadata 當作 LinkedIn 的 AI 揭露機制。
未列於上表的網路未經測量。網路行為可能會在不預警的情況下改變，請將此表視為觀察到的行為，而非保證。
Instagram autoResize 會丟棄揭露。 當貼文使用 instagramOptions.autoResize 時，圖片會由一個獨立步驟調整為 1080×1080，該步驟會寫入新檔案且不會攜帶任何 metadata — 因此無論來源攜帶什麼，AI 揭露、ICC 描述檔和任何 C2PA manifest 在 Instagram 接收到的圖片中都會缺失。如果揭露需要抵達 Instagram，請提供已符合 Instagram 長寬比要求的圖片，並關閉 autoResize。

​
直接上傳媒體

POST /media/upload 會原樣儲存你的位元組。 不會進行重新編碼，所有 metadata — 包括 EXIF 和任何 C2PA manifest — 都會依原樣儲存。 上述保留行為僅在圖片發布至需要不同格式的網路時才會適用。