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 揭露資訊通常會存放於 XMP 封包中的 Iptc4xmpExt:DigitalSourceType 屬性，也經常同時存在於 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——都會完全依你提供的內容儲存。 上述保留行為僅適用於圖片被發布到需要不同格式的網路時。