為論文把公開 Instagram 留言匯出到 Excel

每一列已保存資料包含甚麼

這些欄位規則已於 2026-10-13，就 Instagram Comments Scraper Actor 的公開組建 0.1.21 作過檢查。欄位是一列上一個有名稱的值。這個組建在每一列保存一則公開的頂層留言。

每一列都有 `postUrl`、`postId`、`postShortCode`、`commentId`、`text`、`createdAt`、`likesCount`、`repliesCount`、`ownerId`、`ownerUsername`、`ownerVerified` 和 `collectedAt`。

`postUrl` 是你輸入的帖文連結。`postId` 是該帖文的來源身分。`postShortCode` 是該連結裏面的短代碼。短代碼是 `/p/`、`/reel/` 或 `/tv/` 後面的部分。`commentId` 是一則留言的來源身分。`text` 是留言的文字。`createdAt` 是來源提供的留言時間。`likesCount` 是來源所顯示的讚好次數。`repliesCount` 是來源所顯示的回覆次數。它不是回覆文字。`ownerId` 是發表該留言的帳戶的來源身分。`ownerUsername` 是該帳戶的公開名稱。`ownerVerified` 表示來源是否在該帳戶上顯示驗證標記。`collectedAt` 是 Actor 保存該列的時間。

Null 表示該值未能取得。空白文字沒有任何字元。空白文字與 null 不同。Zero 表示該數字是零。False 表示驗證標記為否。null、zero 和 false 要保持為不同的值。不要把 null 改成 zero 或 false。

這個組建不會在每一列放上狀態欄位。它不保存 `parentId`。它不保存回覆文字。它不保存帖文說明文字。它不保存追蹤者人數。它不保存 bot score。Bot score 會猜測一個帳戶是否由自動程式操作。它不保存情感標籤。情感會是諸如讚賞或投訴之類的標籤。它不標明誰算是一個群組的完整成員。Owner ID 可以是 null。

沒有可供編碼的回覆列。`repliesCount` 為 null，並不是一則文字空白的回覆。它也不是一種情感。

1. 收集之前先寫下取樣框

取樣框是你選定的帖文清單，以及你保留留言的規則。執行 Actor 之前，先寫下取樣框。

寫下這些項目：

• 已知的公開帖文連結。
• 把這些帖文放進清單的規則。
• 日期區間，或一則註明你不會按日期篩選的筆記。
• 你會從 `collectedAt` 抄下的收集時間。
• 語言規則。
• 你所計數的對象：留言、帳戶或帖文。

日期區間是你選擇保留的第一日和最後一日。你所計數的對象就是你的單位。一則留言、一個帳戶和一則帖文是不同的單位。收集時間要寫成 `collectedAt`，不要寫成你開始編碼的那一日。

先寫下帖文清單，再閱讀留言。這樣你就不會因為留言符合你的想法而加入一則帖文。執行之前先寫下日期區間，或者寫明你不會使用日期區間。在同一則筆記寫下單位。後來的計數很容易混淆。下面的編造檔案說明原因。Actor 不會加入語言欄位。寫下一條你做得到的語言規則。例如，保留每一段已保存文字，並在新欄標明語言。如果你剔除一列，寫下原因。

使用一條你已經知道的公開連結。連結必須包含 `/p/`、`/reel/` 或 `/tv/`。個人檔案連結是帳戶頁面。Story 是一項短暫存在的限時動態。標籤連結是標籤頁面。Search 和 Explore 是瀏覽頁面。這些路徑不受支援。只使用公開帖文。不要收集私人帳戶或隱藏留言。

樣本可以描述你所保存的公開留言文字。它不能代表所有 Instagram 用戶。如果要對所有用戶作出說法，就需要另一份會選取人物的計劃。本文不撰寫該計劃。

如果你使用日期篩選，結束日期包含在內。包含在內是指第一日或最後一日的留言可以留下。當日期篩選開啟時，沒有 `createdAt` 的留言會被跳過。除非你移除結果上限，否則日期篩選對每則帖文查看的公開留言不多於 250 則。由最舊開始使用同一個查看上限。即使移除結果上限，仍然不會收集完整的公開動態。如果你使用日期或由最舊開始，把這個上限寫進筆記。

2. 用上限 3 檢查一則帖文

試行是一次非常小的首次執行。你用它檢查檔案的資料結構和格式。由一則已知的公開帖文和上限 3 開始。上限是你要求從一則帖文保存的留言的最高數目。上限是最高值，不是獲承諾的數目。

已保存的匯出為 CSV 的 Task已於 2026-10-13 作過檢查。它已保存的輸入是：

{
  "postUrls": ["https://www.instagram.com/reel/DZu6dkVyImf/"],
  "maxCommentsPerPost": 250,
  "commentSortMode": "default",
  "collectAllAvailable": false
}

該 Reel 是起始輸入。起始輸入不是你的研究。一次執行不會替你做編碼。用你自己的公開帖文連結取代該 Reel。

試行使用以下輸入結構：

{
  "postUrls": ["https://www.instagram.com/p/YOURPUBLICPOST/"],
  "maxCommentsPerPost": 3,
  "commentSortMode": "default",
  "collectAllAvailable": false
}

`YOURPUBLICPOST` 是佔位符。佔位符是你必須取代的代用文字。不要把那些字母當作真實帖文來執行。

把 `commentSortMode` 設為 `default`，會為該次請求保持來源次序。預設次序並不承諾是最新的留言。它並不承諾是最舊的留言。它不是從所有用戶作隨機抽取。如果你其後選擇最新或最舊，該選擇只會為這次執行所收集的留言排序。它本身不會越過第 1 步所述的查看上限。

把 `collectAllAvailable` 設為 false，會保留你的數字上限。如果你把它設為 true，數字上限會被移除。執行仍然可能在公開動態結束、時間用完或來源失敗時停止。該次停止仍然不是每一則公開留言。它也不是每一位 Instagram 用戶。試行時保持 `collectAllAvailable` 為 false。

一則帖文讓第一次檢查保持細小。如果兩則帖文同時失敗，原因就較難看出。上限 3 讓你可以用眼睛閱讀每一列已保存的資料。Task 值 250 只是一個已保存的最高值。它不是承諾會有 250 則留言。較早的一則公開問題可能把 100 則留言說成工具上限。那個舊數字不是目前 Actor 的上限。你寫下的上限就是你所設定的最高值。更高的上限仍然不是每一則留言。

執行之後，把 `postShortCode` 與你的 URL 比較。然後閱讀 OUTPUT。OUTPUT 是與這些列一同保存的執行報告。閱讀頂部的 `requestedTargets`、`savedRows` 和 `cappedTargets`。對每個目標，閱讀 `resultState`、`sampleHealth` 和 `stopReason`。

一次已檢查的執行，為所要求的短代碼保存了 3 列。那些列有留言 ID、文字、作者 ID 和日期。OUTPUT 顯示 capped，停止原因是 `max_comments_reached`，`savedRows` 是 3。`repliesCount` 是 null。該次執行顯示該來源所傳回的欄位結構。它不顯示該帖文上的所有留言。它不證明哪一則留言最舊。它不列出回覆文字或其他帖文。該次執行有作者 ID。較後的帖文仍然可以傳回 null 的 owner ID。

是上限使該次執行停止。已達上限的結果不表示該帖文只有 3 則留言。只有在這次傳回資料結構檢查通過之後，才選擇研究用的上限。在你明白其他停止情況之前，保持 `collectAllAvailable` 為 false。

如果試行沒有傳回任何列，不要寫該帖文沒有留言。來源的可見性可能失敗。作出決定之前，先閱讀 `resultState`、`sampleHealth` 和 `stopReason`。空白列與已編碼的情感不同。

3. 保留原本的 JSON

JSON 是一種文字格式，可以保留巢狀值，也可以保留 null 這個詞。JSONL 是指每一行一個 JSON 物件。資料集是一次執行所保存的列的集合。你可以按 Apify 資料集指南 所述匯出它。

先保存原本的 JSON 或 JSONL，以及 OUTPUT 報告。然後才製作 CSV 或 Excel 檔作為工作副本。CSV 是用逗號分隔各欄的文字表格。同時保存你所使用的輸入。保存帖文連結、上限、排序、`collectAllAvailable` 和任何日期。

留言列沒有供整個資料集使用的狀態欄位。Excel 不會把 OUTPUT 放進留言儲存格內。如果你只保留工作檔，就可能失去產生它的規則。

要保留 JSON，因為 CSV 可能隱藏 null 與空白之間的分別。下面這兩個虛構值不是研究計數：

{"text": null, "likesCount": null, "ownerVerified": null}

{"text": "", "likesCount": 0, "ownerVerified": false}

對於 null 和空白文字，CSV 儲存格都可以看起來是空的。只有原本的 JSON 能告訴你當時是哪一個。零個讚好是真實數值。False 是一個真實的驗證值。Null 不是 zero，null 也不是 false。

4. 匯入 CSV，並把 ID 以文字儲存

從資料集把工作副本下載為 CSV 或 Excel。對於 CSV，開啟 Excel，使用「資料」，然後「從文字/CSV」。載入檔案之前，先檢視每一欄的類型。Microsoft 在匯入或匯出文字或 CSV 檔案說明該匯入路徑。

把 `postId`、`commentId` 和 `ownerId` 設為文字。真實的來源 ID 常常看起來像很長的數字。數字欄可能從長 ID 中丟掉位數。把 `text` 保持為文字。只有在 `createdAt` 和 `collectedAt` 仍然與 JSON 相符時，才把它們保持為日期和時間。UTC 是共用的世界時鐘。它不使用你的本地時區。如果 Excel 改動了時鐘，就改為把時間保持為文字。不要信任 Excel 所猜測的類型。

匯入之後，把一個 `commentId` 和一個 `createdAt` 與未改動的 JSON 比較。也比較列數。下一節為這項檢查提供一個編造的文字測試。

5. 編碼之前先計列

把工作檔與原本的 JSON 核對。計列數。計不是空白、而且互不相同的留言 ID。互不相同是指同一個 ID 只計一次。找出複製列。找出沒有留言 ID 的列。用 JSON 分辨 null 和空白。

虛構匯入測試

下一個檔案是虛構的。虛構是指我們為了教學而編造它。它不是 Actor 的結果。它不屬於下面的八列計數。它不是真實 Excel 執行的結果。

測試 ID 是 `1234567890123456789`。該 ID 有 19 位數字。以文字儲存它。預期的 ID 正好是這 19 位數字。本文不會編造一個來自 Excel 的錯誤數字。它告訴你仍然必須看到的數字。

測試文字包含一個逗號、一個換行、引號，以及 café 這個詞。字母 é 不在基本英文 A 至 Z 的字母集合內。檔案必須保留 é。

以下 JSON 是虛構來源：

{
  "commentId": "1234567890123456789",
  "text": "Nice, work\nShe said \"hello\" at the café"
}

在 JSON 中，`\n` 表示一個換行。這段 CSV 是同一列虛構資料。引號內的文字包含一個真實換行。欄內每一個內部引號都會連寫兩次。這是正常的 CSV 寫法。

commentId,text
"1234567890123456789","Nice, work
She said ""hello"" at the café"

正確匯入之後，ID 仍然是：

1234567890123456789

文字仍然是：

Nice, work
She said "hello" at the café

那些是預期保留的值。它們不是來自你電腦的報告。如果 ID 欄是數字，或者 café 失去了 é，就停止並修正匯入。不要在已損壞的檔案上開始編碼。

虛構的八列研究檔

接下來的八列也是虛構的。它們不是 Actor 的結果。它們不是已檢查的三列執行。它們是來自一則編造帖文的一份教學檔。不要把這些計數抄進真實論文。

每一列都共用這些帖文值：

• `postUrl`：`https://www.instagram.com/p/EXAMPLE0001/`
• `postId`：`1000000000000000001`
• `postShortCode`：`EXAMPLE0001`
• `collectedAt`：`2026-10-13T12:00:00Z`

`postId` 有 19 位數字。在真實匯入中，它必須是文字。八列留言仍然屬於一則帖文。不要計成八則帖文。

在表格中，null 表示未能取得。空白表示文字沒有任何字元。簡短的擁有者標籤 A、B、C 和 D 用來代替來源 ID。真實的 owner ID 可以很長。也以文字儲存它們。

R1 和 R2 有相同的來源值。R2 是一列複製的匯出資料。複製列會重複同一個留言 ID 和相同的來源值。R3 使用相同的文字 Great post，但它的留言 ID 是 C2。C2 是另一則留言。它的時間和讚好次數也不同。這些差異幫助你看出這一點。即使其他欄位相符，單靠留言 ID 也已經足夠。

在 R4，`likesCount` 為 0 表示零個讚好。`repliesCount` 為 0 表示來源顯示零則回覆。你仍然沒有回覆文字。`ownerVerified` 為 false 表示來源把該帳戶顯示為未經驗證。在 R7，null 不表示 zero 或 false。C6 的文字為空白。這個例子沒有用 null 文字來表示 C6。CSV 工作副本可能使該空白文字、null 擁有者、null 讚好次數、null 回覆次數和 null 驗證標記全部看起來是空白。編碼 C6 之前，先使用原本的 JSON。

按以下次序計這個檔案：

原始列是每一列，包括複製列。原始列 = 8。

R2 是額外的複製。額外複製列 = 1。

R8 沒有留言 ID。沒有留言 ID 的列 = 1。

已知且互不相同的留言 = 8 - 1 - 1。那就是 6。這六個 ID 是 C1、C2、C3、C4、C5 和 C6。

C6 的文字為空白。文字為空白的已知留言 = 1。

文字基數 = 6 - 1。那就是 5。文字基數是有文字、而且你可以編碼的已知留言。那些留言是 C1、C2、C3、C4 和 C5。

你也可以從包含詞語的列開始。R1、R2、R3、R4、R5、R6 和 R8 有詞語。那是 7 列。移除複製列 R2 和未定列 R8。7 - 1 - 1 = 5。兩種做法都會得出同一個文字基數。

R1、R2 和 R3 都寫着 Great post。因為 R1 和 R2 共用一個 ID，所以 C1 只計一次。保留 C2，因為它的 ID 不同。如果你剔除重複的詞語，就會失去一則真實留言。如果你保留每一行相符的列，就會把 C1 計兩次。

這六則已知留言的擁有者值是 A、A、B、C、D 和 null。五則已知留言有擁有者：C1 至 C5。帳戶 A 寫了 C1 和 C2。已知且互不相同的帳戶 = 5 - 1。那就是 4。這四個帳戶是 A、B、C 和 D。五個擁有者值是五則留言，不是五個帳戶，也不是五個人。

擁有者不是 null 的原始列是 R1、R2、R3、R4、R5 和 R6。該計數是 6。6 是錯誤的留言總數，因為 R2 是複製列。移除複製列之後，剩下五個擁有者值。5 仍然是錯誤的帳戶總數，因為 A 出現了兩次。

這個檔案沒有人物欄位。一個人可以使用兩個帳戶。兩個人可以共用一個帳戶。報告 4 個已知帳戶。不要報告 4 個人。不要報告 5 個人。C6 是一則擁有者為 null 的已知留言。不要為 C6 寫下擁有者 0。在這個檔案中，六則已知留言和四個已知帳戶都是真的。它們不是同一個計數。

R8 有文字 Cool、一個時間，但沒有留言 ID。沒有其他列寫着 Cool。這仍然不使 R8 成為已知留言。時間不能取代留言 ID。不要因為兩者的擁有者都是 null，就把 R8 與 C6 合併。共用的 null 不是相符。沒有證明 R8 是一則新留言。也沒有證明它是複製列。在你檢視原本的 JSON 之前，保持它為未定。不要按空白的留言 ID 合併。

只有當量度需要有文字的已知留言時，才用 5 作為基數。把 C6 保留在有無計數中。有無是指該值當時是否存在。對於所有已知留言的量度，基數是 6。把基數寫在量度旁邊。不要把 8、6 和 5 當作同一個基數來使用。這個例子不計算讚賞佔比，也不計算任何其他結果。

有 `createdAt` 的已知留言 = 6 之中的 6。在這個例子中，沒有日期的已知留言 = 0。R8 有一個時間，但該時間不會給它一個留言 ID。真實執行可以不同。如果你使用了日期篩選，`createdAt` 為 null 的留言早就已被跳過。

6. 在原始文字旁邊加入編碼

把來源文字保留在 `raw_text`。不要在那裏修正拼寫。不要在那裏移除換行。如果你需要清理後的文字，把它們放在新欄，例如 `coding_text`。把每一個選擇放在新欄：`coding_unit`、`code`、`coder`、`decision_note` 和 `coding_version`。

`coding_unit` 指出你所編碼的東西。在這個練習中，單位是留言。`code` 是你的人手標籤。`coder` 指出作出選擇的人。`decision_note` 說明原因。`coding_version` 指出規則集。如果規則改變，寫下新版本。不要默默覆寫舊筆記。

只有在那些欄仍然填有內容時，另一個人可以重複該選擇。Actor 不會填寫那些欄。

同一份虛構檔案在這裏繼續。這些標籤是名為 casey 的虛構編碼者所做的練習標記。它們不是 Actor 欄位。它們不是情感分數。它們不是關於真實人物的發現。

C1 和 C2 仍然是兩個單位，因為它們的留言 ID 不同。帳戶 A 寫了兩者。如果單位是帳戶，就會把它們歸成一組。如果單位是留言，就不會。

C6 不在這個練習表格內，因為它的文字是空白。把 C6 保留在有無計數中。R8 不在其中，因為它沒有留言 ID。不要給 R8 一個編碼，藉此強迫它進入文字基數。

如果來源帖文其後消失，把帶有日期的檔案保留為來自 `collectedAt` 的觀察。不要修改舊文字去配合一個已消失的頁面。保留規則是另一項書面選擇，用來決定你把檔案保留多久，以及誰可以查看。本文不設定該規則。

7. 寫下樣本清冊

清冊是一份書面計數，記錄你要求了甚麼、保存了甚麼，以及略去了甚麼。用原本的 JSON 和 OUTPUT 來建立它。下面的虛構清冊只使用編造的列。這個例子沒有 OUTPUT 報告。在真實執行必須抄下 OUTPUT 的地方，這個例子寫上未知。

在真實執行中，從 OUTPUT 抄下 `requestedTargets`、`savedRows` 和 `cappedTargets`。為每則帖文抄下 `resultState`、`sampleHealth` 和 `stopReason`。然後自行計數互不相同的留言 ID。不要用猜測取代報告中的值。不要把這個例子的數字貼進該報告。

在該列旁邊寫下每一個排除原因。預設次序和公開可見性可以改變哪些聲音出現。在清冊筆記中說明這一點。已達上限的目標是碰到了你設定的上限。它本身不會逐一點名每一則被留在外面的留言。

來源顯示總數是帖文頁面上顯示的留言數目。把它與已保存列分開。你會在方法說明中使用這兩個數字。

8. 寫一份與檔案相符的方法說明

寫下你實際保存的內容。說明這些列是公開顯示的頂層留言。寫明帖文連結、次序、上限、日期區間和收集時間。把來源顯示總數與已保存列分開。

如果這兩個數字不同，單憑這個差異並不能知道原因。這個差距不證明收集有錯誤。這個差距也不證明收集是完整的或沒有過失的。上限、動態停止、時間停止、來源失敗、隱藏留言，或者從來都不是列的回覆，全部都可以改變這些計數。你的 OUTPUT 筆記才是記錄你實際看到的停止的地方。

如果已保存列是零，不要寫該帖文沒有留言。先閱讀目標狀態。

這些文字是範本。用你自己的執行取代每一個方括號。不要把虛構計數抄進去。

We saved publicly shown top-level comments.
The posts were the public URLs we listed before the run.
The order was default.
The cap per post was [your cap].
The collection time was [collectedAt].
The date window was [your dates], or we did not use a date filter.
We saved [saved rows] rows.
The source displayed total was [source total], or we did not record one.
A difference between those numbers is not proof of a bug.
That difference is also not proof that the file is complete.
We did not export reply text.
Null means a value was unavailable.
We kept zero and false as real values.
We counted comments, accounts, and posts separately.
This file describes the saved public comments only.
It does not describe all Instagram users.

如果你沒有記錄來源顯示總數，就把它留空。不要編造它。另一個人應該能夠把每則已編碼留言追溯到一個留言 ID、一條帖文連結，以及 `collectedAt`。