第三章 系統設計與架構
3.3 系統功能探索
3.3.2 搜集資料分析與統計
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
41
圖 3. 9 搜集推文工作設定。
訊息的使用能夠讓系統間各個元件有一個共通語言，元件間只需要解析訊息 即可，可避免繁複的 API 參數，對程式員造成的負擔。
3.3.2 搜集資料分析與統計
分析與統計功能除了可針對所搜集回來的推文，進行轉推文、被收藏的次數或推 文內容進行統計外，同時也結合時下最流行的雲端服務來分析一些推特 API 並未 完整或僅部份提供的資訊，如短網址還原統計、發文者統計、資料地理資訊分析 等。
推特對於推文內容有字數限制，目前為 140 個字元，然而發文者在撰寫推文 時除了純文字外，常常也會引用一些網址，若把這些引用的網址也計算進推文的 字數限制內，很快就會遇到 140 個字元的瓶頸，有鑒於此，推特採用短網址的技 術，將十分冗長的網址透過一個對應機制，縮短為一個固定長度的網址，這裡稱 它為短網址，因此，發文人能輸入更多的字數，同時亦不影響推文的內容。
推文對於網址資訊一律以推特自身的短網址服務(t.co53)加以表示，即便是發
53 http 開頭的網址會被縮短成 22 個字元(http://t.co/vyl5DcLSbf)，剩餘可輸入的字元為 118。https 開頭的網址會被縮短成 23 個字元(https://t.co/9CMJU8uuYU)，剩餘可輸入的字元為 117。無論推 文的內容是否含有短網址，Twitter 都會自動幫他轉成以 t.co 開頭的短網址。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
42
文人是輸入其它短網址服務提供者所產生的短網址，推特仍然會將它轉換成自家 服務的短網址，因此，若是要分析推文中有關於網址的部份，我們必需要對短網 址進行進一步的處理。圖 3. 10 推特的短網址。
圖 3. 10 推特的短網址。
圖 3. 11 短網址的原理。
由圖 3. 11 短網址的原理。可知，短網址其實只是其服務提供者的一個 KEY，
服務提供者用該 KEY 來查詢資料庫取得原始的網址，然而，在實務的應用上，我 們還需要考慮到遞迴的問題，即一個網址已經過某一短網址服務提供者轉譯成一 個短網址，但發文人又將該短網址置於其推文中引用；如前文所述，推特會對所 有推文的網址進行短網址的轉譯，因此我們從 API 取得的網址，會是經過兩次以
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
43
上短網址服務處理後的網址。在此我們使用 ExpandURL54這個免費的雲端服務來 做短網址的解析。同時，由於分析一個工作中所有推文的短網址，需耗費不少的 時間，故非同步的方式有其必要，在這裡是採用 Quartz 來負責執行非同步的分 析工作。最後，終端使用者可以分別依短網址統計、原網址統計及網域(Domain) 統計來檢視結果。
圖 3. 12 短網址還原之網域統計。
資料地理資訊分析牽涉到一個關鍵性的問題，推特 API 是否有提供經緯度資 訊?這個問題答案是肯定的，依推特 API 對推文回應格式的說明55，coordinates(表 示推文是發自所示的經緯度)及 place(表示推文與這個位置資訊有關係)這兩個欄 位均有涉及到經緯度資訊。但實務上有含地理位置資訊的推文付之闕如，所搜集 到的推文含有地理位置資訊低於 1%的比率，更是比比皆是(推特並未強迫使用者 公開地理位置資訊)，這樣稀少的樣本數，在統計學上其實是亳無意義的。因此，
若要分析地理位置資訊，我們必需要找到另一種方式來獲得更多的樣本數。
54 http://expandurl.appspot.com/
55 https://dev.twitter.com/docs/platform-objects/tweets
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
44
推特用戶可以在個人檔案(profile)中輸入地點(location)資訊(實際上這個欄位 是可以讓用戶自由輸入的，用戶可以輸入任意的字元，因此較不會涉及到敏感或 與個人隱私有關的位置資訊)，比起公開位置資訊，大多數用戶比較願意在這個 欄位輸入一些具分析價值的資訊。如用戶可能會在此輸入【台北 101】來概括地 描述他在台北，而非公開發文位置精確的經緯度座標資訊。然而，若要將用戶的 地點欄位，轉譯為有意義的地理位置資訊，我們就需要借助 Gazetteer56這樣的地 區地名查詢服務；在這裡我們選用 MapQuest57這個雲端服務，不但免費而且沒 有加諸任何 API 存取的限制(即不會因為 API 大量的存取，導致請求被拒的窘境)。
實證上，我們將所搜集的推文，以約不到 1%含地理位置資訊的推文，再加上透 過推文發文者個人檔案中的地點資訊加以解析後，我們大約可以從其中獲得 10%
到 30%左右的地理位置資訊，這樣的樣本數，已經具有相當的參考價值。另外在 歸納發文國別的簡寫與國家全名上，我們採用世界銀行58所提供的 API 來取得國 名簡寫與國家全名的對應關係。
終端使用者在完成統計後可以依地理資訊分析，使用 jVectorMap 向量地圖，
將推文的發文地點展現在世界地圖上；也可以依推文國別分析，從圓餅圖中來檢 視所搜集回來的推文國別的比例。圖 3. 13 地理資訊分析。及圖 3. 14 推文國別分 析。
56 Gazetteer 是一種應用於地圖或圖集中，用於查詢地區地名的一種地理位置字典。
57 http://www.mapquestapi.com/
58 http://data.worldbank.org/developers
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
45
圖 3. 13 地理資訊分析。
圖 3. 13 地理資訊分析。呈現出在 2014/4/20 在東歐克里米亞事件發生時，以 Russia 為搜尋關鍵字，所查找出來的推文地理資訊分析，我們可以明顯的發現，
推文的發送地點多為歐洲大陸各國，其次為美國，相當符合一般的預期。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
46
圖 3. 14 推文國別分析。
圖 3. 14 推文國別分析。可以發現在克里米亞事件發生時以 Russia 關鍵字進 行搜尋，俄羅斯、美國及法國分別為發文者國別的前三名。
在發文者統計方面，我們可以透過推特 API 中回應的 user 欄位，找出該篇推 文的發文者，再透過 SQL 語句的 GROUP BY，即可將所搜集的推文，依發文者來 加以統計。然而很多的推文其實是轉推自某一推文而來的，這種推文的特性是在 其推文內容的最前方會有 RT @twitterusername 的標籤，其中，RT 代表 Retweet，
@twitterusername，表示轉推自那個推特用戶，如 RT @NCCU 表示推文轉推自 NCCU 這個發文者。很多時侯，推文是來自於不斷的轉推，此時，若我們想要獲 得真正的原始發文者統計，就不能只單純的依賴 user 這個欄位，所幸推特 API 還有提供了 retweeted_status 這個欄位，透過它，我們可以得到原始的推文，再 從原始推文的 user 欄位得到發文者，最後透過 SQL 語句的 UNION，將非轉推推 文的發文者及屬轉推推文的發文者給連結起來，即可得到一個原始推文發文者的 子集合。圖 3. 15 發文者統計(不考慮到轉推文)。，圖 3. 16 發文者推文含有轉推 文。，圖 3. 17 發文者統計(原始發文者)。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
47
圖 3. 15 發文者統計(不考慮到轉推文)。
圖 3. 16 發文者推文含有轉推文。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
48
圖 3. 17 發文者統計(原始發文者)。