Bibz 免費B站彈幕查詢工具，實測一次能拿到多少條彈幕

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

一個免費工具能不能用，有時候不由工具自己決定。當它要拿的資料握在別人手裡，而對方正在積極防守，可用性就變成每天重新擲一次的骰子。Bibz（bibz.me）是這個邏輯的最新樣本：它是一個標榜免費、免登記的 B 站彈幕查詢與匯出網站，貼上影片網址就能把彈幕抓下來，同站還有影片下載、音訊與封面提取、直播流、封禁查詢、熱詞與熱搜榜等周邊工具。我在 2026 年 10 月 30 日實際測它：彈幕查詢這條主線十次呼叫只成功了一次，成功那次拿到的是整整一千條、集中在當天的彈幕，而那支影片的彈幕總數約八千條；同一時間，熱搜、封禁名單、熱詞三個周邊介面實測都在一秒內回應。想用它做正事之前，先看懂這個落差從哪裡來。

先把身分講清楚：Bibz 是第三方工具，與 B 站沒有從屬關係，關於頁自述是面向 B 站用戶的第三方免費工具集，部署在 Cloudflare 全球節點上，全部功能不需要 B 站帳號。它的訴求對象是 UP 主、觀眾與做資料分析的人：想復盤一支影片哪個時間點被洗版、想留存在直播裡刷過的互動、想研究彈幕關鍵字的人，都屬於它的目標用戶。站方在首頁把承諾寫得很滿，宣稱能查到一支影片的全部歷史彈幕，不受時間和數量限制。下面的實測會逐一檢驗這句話。

Pin

一個靠修修補補活過來的站

Bibz 的更新日誌還掛在站上，讀起來像一部「彈幕抓不到」的除錯史。2025 年 5 月 v1.0.0 上線，主打彈幕查詢；隨後兩個月快速疊功能，封禁查詢、熱搜、熱詞、直播流、彈幕發送者查詢陸續加入；2025 年 7 月 20 日 v1.9.6 修了 b23.tv 短連結解析失敗，九天後的 v1.9.7 修「彈幕獲取不到的問題」，站方還在旁邊加了括號註記「徹底解決這個問題了」。最後一筆紀錄停在 2025 年 8 月 26 日的 v1.9.8，加入影片批量下載與歷史記錄功能。此後十四個月，站還在營運、功能頁都活著，但更新日誌沒有再動過。

這段歷史對使用者的意義很實際：彈幕抓不到不是偶發事件，而是這個站反覆出現的老症狀。站方自己把修復寫進版號，等於承認資料鏈路先天不穩。至於「徹底解決」四個字，後面會用實測數字對照。

Pin

順帶一提，站內曾經有獨立的「彈幕發送者查詢」頁面（2025 年 6 月底 v1.9.1 上線），現在的網站選單裡已經找不到對應路由。發送者資訊本身沒有消失，成功查詢的每一條彈幕資料裡都還帶著發送者的匿名雜湊值，這點後面談匯出格式時會展開。

十次查詢，成功一次

實測方式很直接：拿五支不同的 B 站影片，反覆呼叫 Bibz 的彈幕查詢介面，隔了幾分鐘再挑三支重測，總共十次。結果是一次成功、九次失敗。五支影片裡有四支來自 B 站當天熱門榜，遊戲前瞻、當季國創動畫、自然科普、央視節目各一，彈幕量從一千五百多到十二萬條；另一支是站方範例程式碼裡出現的經典老片。成功與失敗和影片熱門程度、彈幕密度對不上，找不到肉眼可見的規律。

失敗的長相非常簡陋：伺服器回一個 500 錯誤，內容只有 HTTPError 一個詞，沒有原因、沒有建議、沒有重試指引。頁面上相對應的只是「查詢失敗，請稍後重試」這類提示。用瀏覽器正常操作與直接呼叫介面的結果一致，問題不在使用者這一端。更麻煩的是不穩定本身：唯一成功的那支影片，幾分鐘後再查一次，也變成了 500。

成功的那次發生在一支央視節目影片上，回應速度不到三秒，體驗本身相當好：一千條彈幕帶時間軸、顏色、類型完整送達，頁面上可以直接按關鍵字過濾，影片標題與 UP 主名稱一併帶回。問題出在數量。回應裡的總數欄寫 1000，實際陣列長度也是 1000，一條不多一條不少；而這支影片當時的彈幕統計約八千條。再看得細一點，這一千條的發送時間全部落在測試當天，等於拿到的是最近的快照，不是從影片發布以來的累積。對照站方「全部歷史彈幕、不受時間和數量限制」的宣稱，實拿結果是單次一千條的近期樣本。拿去做熱點分析夠用，拿去做全量統計就是差了近一個數量級（約八倍）。

一千條裡有 761 個不同的發送者雜湊，流動的行為 892 條、頂部固定 105 條、底部固定 3 條，這個分佈對做互動節奏分析的人有直接用處。但要提醒：彈幕是公開但個人化的行為資料，每一條都掛著發送者的匿名識別與彈幕編號，做研究沒問題，反過來用來針對特定的人檢索言行，就踩到隱私與騷擾的邊界，這條線站方沒有提醒，使用者得自己畫。想做「用一串數字翻出某帳號言論史」那類查詢，站內已經沒有對應頁面，同類需求可以看我們之前介紹過的 AICU，它的定位本來就偏向帳號言論檢索。

匯出檔案長什麼樣，決定你能做什麼

查詢成功後，頁面上的出口有兩個：匯出 XML，或者整批複製成純文字。XML 是 B 站彈幕的標準格式，每一條寫成八個欄位：出現秒數、類型、字級、顏色、發送時間戳記、池號、發送者雜湊、彈幕編號，外層再包一層播放器認得的結構。這個選擇很聰明，等於匯出檔可以直接餵給支援彈幕的本地播放器或剪輯工具，二次創作者幾乎零成本。八個欄位各有用途：出現秒數與類型讓播放器知道什麼時候、用什麼方式浮現這條留言（捲動、置頂或置底）；發送時間戳記對研究者最有價值，它能對出彈幕的發布日期，做長期互動分析全靠它；發送者雜湊與彈幕編號則是每條彈幕的身分證，同一個雜湊重複出現，就代表同一個人在這支影片裡發了多條。複製功能則把每一條變成「[分:秒] 內容」的純文字，整批一次複製，貼進文件或聊天記錄都好處理。有個小細節：匯出檔名是「影片標題_彈幕.xml」，中間那個彈字是簡體，看得出背後的字串直接從簡體環境抄來，台灣使用者存檔時自己改一下就好。

輸入端倒是不挑：完整網址、BV 號、AV 號都吃，b23.tv 手機分享短鏈也在支援之列（站方更新日誌 v1.9.6 修的就是短鏈解析失敗），手機上看到影片直接複製分享連結丟進去就能查。v1.9.8 加入的批量解析與歷史記錄也實用：歷史記錄存在你自己的瀏覽器裡，換設備不會跟著走，但也不會上傳到誰的伺服器。

這裡有個宣稱與實作的落差要指出：首頁行銷文案兩處宣稱能把彈幕匯出成 CSV、Excel、JSON、TXT 等多種格式，但查詢頁面上實際存在的出口只有上述兩個，從查詢頁的介面實作裡也找不到其他格式的蹤影。CSV 之類的表格格式並非難事，把 XML 轉一下就有，但對期待「匯出 Excel 直接做樞紐分析」的人，現況是拿到 XML 後自己動手。要餵播放器的人反而撿到便宜，標準格式比 CSV 更稀缺。

前端是殼，真正幹活的是站方伺服器

為什麼同一個站，彈幕查詢搖搖欲墜，熱搜與封禁名單卻每次都通？把前後端的分工拆開看就明白了。

彈幕主查詢走的是站方代理：瀏覽器把影片網址交給 bibz.me 自己的後端，由站方伺服器去 B 站抓資料，抓完整理好再回傳給你。周邊的資料頁走另一條輕量通道，我實測熱搜榜、封禁名單、熱詞三個介面，全部在 1 秒內回應，內容也是活的：熱搜榜上看得到當下關鍵字與熱度分數，動畫電影與電競戰況都在榜上；熱詞頁像一本持續更新的流行語字典，每個詞附讀音，「為菈妮」「小雞恰恰舞」這類梗詞查得到出處圖；封禁名單頁更有看頭，B 站官方公示的封禁案由全文呈現，例如假借「關注即可贈送B站硬幣」名義引誘用戶下載站外 App 再騙個資的詐騙案，一頁頁翻下來就是平台治理的實錄。這三個頁面穩定的原因也單純：它們要的資料輕、單次拉取量小、逐頁分頁。差別就在負載與防禦強度：彈幕查詢要逐支影片去翻 B 站的內部資料鏈路，是第三方工具裡最容易被平台風控盯上的那種請求；熱搜與封禁名單是輕量公開資料，風險壓力小得多。順帶一個細節：這些周邊資料回傳的都是簡體字（畢竟源頭是 B 站的簡體內容），做簡報或引用前要自己做一次簡轉繁。

前端程式碼裡還藏著一段更直白的證據。Bibz 的瀏覽器程式在呼叫 B 站介面時，會把自己偽裝成 B 站網頁客戶端：瀏覽器識別字串冒用特定版本的 Chrome、來源頁與請求來源都填 B 站網址，還會自己生成一枚 B 站用來識別訪客的 buvid3 指紋，遇到 412 風控攔截就換一枚新指紋重試。412 正是 B 站風控的招牌回應，我在測試當天直接查 B 站的影片資訊介面，連續幾次之後也被 412 擋下，親身驗證了這道牆的存在。站方聯絡頁有個細節與此呼應：回報問題時請附上所在地區，用意與排查網路節點有關，等於承認同一個功能在不同地區、不同線路上的表現會不一樣。

把這些線索放在一起，合理的推測是：彈幕查詢的失敗，主因出在站方伺服器與 B 站之間的攻防，程式本身的缺陷是次要解釋。站方未公開失敗原因，這段屬於推論，但它與更新日誌裡反覆出現的修復紀錄、與聯絡頁要求回報地區的做法一致。這也是所有第三方平台工具的共同宿命：平台沒有義務為你保留非官方通道，B 站對 API 邊界的防守是認真的，社群整理的非官方 API 文件庫 bilibili-API-collect 曾經收到律師函後刪庫，就是最直接的訊號。依賴這類工具的人，心裡要有一條停損線。

免費的但書：廣告牆與匿名營運者

「永久免費使用，無限制下載」寫在首頁最顯眼的位置，實際使用時有兩個但書。

一個但書在影片下載頁。實測打開批量下載功能時，頁面先跳出一個名為「解鎖更多內容」的對話框，寫著「請做出選擇以便繼續訪問此網站上的內容」，選項是觀看一則短廣告，回報是 72 小時的網站級訪問權限。換句話說，下載類的重功能採用看廣告解鎖的模式，彈幕查詢本身在測試中沒有遇到這道牆。這種模式對免費用戶不算苛刻，但「無限制」的說法要打折扣，而且對話框攔住了整個操作流程，不看廣告就動不了。同頁還掛著電視會員訂閱的入口與下載次數看板，商業化痕跡比彈幕頁明顯得多。

另一個但書是營運主體。條款頁與隱私頁都存在，寫得也算清楚明白：服務按現狀提供、可用性受上游平台影響、下載內容的版權責任在使用者自己。但整個站找不到營運公司的名字，聯絡頁明說不公布客服信箱，只留站內表單，寫明一至三個工作日內處理，但無法保證逐條回覆。隱私頁說明了匿名統計與瀏覽器本地記錄兩件事，歷史記錄功能存在你自己的瀏覽器裡。對照它的用途，這種匿名結構的風險不算大，畢竟你不上傳檔案、不留個資；但若哪天要爭議、要商用授權證明、要開發票，沒有任何主體可以追溯。

集中限制與其他沒測到的部分

把限制集中攤開，方便對照自己的需求。成功率的部分，觀察基準是單日單時段，十次呼叫成功一次不代表它永遠如此，換一天、換地區可能完全是另一組數字；可以確定的是失敗毫無預警、錯誤訊息不提供任何線索、且同一支影片的結果會翻盤。資料量的部分，成功時單次實拿一千條近期彈幕，與全量宣稱有落差，做長期趨勢統計前要先想清楚母體定義。匯出格式只有 XML 與純文字複製兩種，表格格式要自己轉。看廣告解鎖的牆在影片下載類功能上。營運者匿名，條款按現狀提供。另外，直播流獲取、字幕提取、音訊提取、封面提取這幾個功能頁這次沒有逐一實測，僅確認頁面存在且正常載入，它們與彈幕主查詢共用同樣的第三方資料鏈路，穩定性建議用同樣的標準看待。

誰該用、誰該繞開

適合的情境其實不少：臨時想看一支影片被洗版的段落分佈、做影片精華回顧時想找高能時間點、想保存某次直播互動的氣氛、做彈幕關鍵字的小型分析，這些需求有一千條近期樣本就夠用，而且免費、免登記、免安裝，試錯成本只有時間。匯出的 XML 能直接進播放器，對二創族群是加分。使用的節奏建議是：先拿目標影片試查一次，通了再排後續工作，不通就換時段再試，別把它放進需要保證產出的正式流程。

不適合的也一樣清楚：要完整歷史彈幕做學術等級統計的人，一千條上限與近期樣本兩個限制會直接否決；商業流程裡需要穩定供應資料的場景，第三方非官方通道的先天風險不該由公司流程承擔；需要表格格式與自動化串接的人，現有出口要多一道自製轉換。這些需求可以看替代路線：B 站影片本體的下載與處理，有開源的 BiliVideoDown 與自己跑腳本的思路；收藏夾備份有 Mybili；要真正穩定的資料通道，回到 B 站官方開放平台申請，或者以 bilibili-API-collect 整理的介面自建腳本，把成敗握在自己手裡。

一句話收尾：Bibz 把「查彈幕」這件事的門檻壓到貼網址就好，代價是把穩定性與資料完整度交給一場看不見的攻防。輕量嘗試很值得，正式依賴前，先想清楚那一天查不到的時候怎麼辦。