雪球股票數據獲取

㈠ 雪球、英為財情上面的美股行情是怎麼獲得的

怎麼獲得美股行情最權威的途徑是 wind 資料庫，不過都是收費的，一般是賣給企業，價格不菲
個人的話，只能找找有沒有免費提供的了。沒有的話就只能自己寫爬蟲了。

雪球、英為財情上面的美股行情經過美股研究社調查基本上都屬於從資料庫合作或者買賣獲取，收益模式是兩種之一：一是賣產品，一是賣廣告。服務很多時候也是一種產品。

對於網站來說，電子商務類的網站，比如淘寶店，京東商鋪，亞馬遜商鋪，這些都是典型的通過賣產品盈利的。

需要注意的是，這只局限於店家的店鋪。對於淘寶、京東、亞馬遜而言，他們很多的時候是運營平台，通過向加盟的商戶收取服務費，或廣告費。
媒體類的網站，廣告會是更主流的商業模式。比如打開英為財情首頁，我們可以看到這是一個財經類的門戶網站，提供各種行情和數據。我們在頁面頂部，左右側都可以看到有橫幅廣告，同時頁面中間，也可以看到由一些廣告聯盟提供的廣告信息，會在頁面中有所標注。（國內的網路聯盟就是一個大型的廣告聯盟）。在頁面底部，我們可以看到一些交易商的LOGO和鏈接，這些可以判斷是合作夥伴或者廣告客戶。對於華爾街見聞，也可以做類似的分析。
對於不同類型的網站，他們還會有各種各樣的盈利模式，如果網站所屬的公司是上市公司，那可以通過查看公開的財報來查看其收入來源。

㈡ 如何通過excel獲取股票列表

1這里以獲取中國石油(601857)的行情為例，打開提供股市行情的網站，在頁面的「個股查詢」區域輸入該股票代碼，選擇「實時行情」，單擊「行情」按鈕之後就可以查詢中國石油的行情數據，接下來復制地址欄中網址。

2運行Excel，新建一個空白工作簿，選擇「數據」選項卡中「獲取外部數據」選項組中「導入外部數據一自網站」命令。

3彈出「新建Web查詢』對話框，在地址欄中輸入剛剛復制的地址，單擊「轉到」按鈕，此時在下面的文本框中打開網站，單擊「導入」按鈕。

4彈出「導入數據」對話框，選擇要插入的工作表，單擊「確定」按鈕即可。此時在工作表中導入了網站的數據。

㈢ 雪球是什麼軟體

雪球是北京雪球信息科技有限公司開發的交易類軟體，它支持多家證券公司開戶和交易，比如：平安證券、方正證券、國聯證券、國金證券等。投資者開戶後可以直接在雪球軟體上交易股票、基金、可轉債、國債逆回購、理財等，若之前有賬戶的可以直接登錄交易。

溫馨提示：
1、以上解釋僅供參考，不作任何建議。
2、入市有風險，投資需謹慎。
應答時間：2021-04-16，最新業務變化請以平安銀行官網公布為准。
[平安銀行我知道]想要知道更多？快來看「平安銀行我知道」吧~
https://b.pingan.com.cn/paim/iknow/index.html

㈣ 怎麼將股票中的數據導出到excel

1、首先在電腦桌面上打開股票軟體。

㈤ 同花順如何查詢個股的歷史收盤價

同花順如何查詢個股的歷史收盤價炒股就是從事股票的買賣活動。炒股的核心內容就是通過證券市場的買入與賣出之間的股價差額，獲取利潤。面，不再受相思之苦。你說但願我們的愛情

㈥ 如何使用python 抓取雪球網頁

現在關注一個組合，就會有持倉變動的提示了。不過我覺得這事情挺有意思的。比如可以把很多持倉的數據都抓下來，做一些綜合的分析，看看現在網站上被持有最多的股票是哪一支，某一天被調入最多的又是哪一支之類。
於是我決定來抓抓看，順便藉此說說我通常用程序做自動抓取的過程。
Step.1 分析頁面
要抓一個網頁，首先自然是要「研究」這個網頁。通常我會用兩種方式：
一個是 Chrome 的 Developer Tools。通過它裡面的 Network 功能可以看到頁面發出的所有網路請求，而大多數數據請求都會在 XHR 標簽下。點擊某一個請求，可以看到其具體信息，以及伺服器的返回結果。很多網站在對於某些數據會有專門的請求介面，返回一組 json 或者 XML 格式的數據，供前台處理後顯示。

另一個就是直接查看網頁源代碼。通常瀏覽器的右鍵菜單里都有這個功能。從頁面的 HTML 源碼里直接尋找你要的數據，分析它格式，為抓取做准備。
對於雪球上的一個組合頁面 粗略地看了一下它發出的請求，並沒有如預想那樣直接找到某個數據介面。看源代碼，發現有這樣一段：
SNB.cubeInfo = {"id":10289,"name":"誓把老刀挑下位","symbol":"ZH010389" ...此處略過三千字... "created_date":"2014.11.25"}
SNB.cubePieData = [{"name":"汽車","weight":100,"color":"#537299"}];

cubeInfo 是一個 json 格式的數據，看上去就是我們需要的內容。一般我會找個格式化 json 的網站把數據復制進去方便查看。

這應該就是組合的持倉數據。那麼接下來，一切似乎都簡單了。只要直接發送網頁請求，然後把其中 cubeInfo 這段文字取出，按 json 讀出數據，就完成了抓取。甚至不用動用什麼 BeautifulSoup、正則表達式。
Step.2 獲取頁面
分析完畢，開抓。
直接 urllib.urlopen 向目標網頁發送請求，讀出網頁。結果，失敗了……
看了下返回結果：
403 Forbidden
You don't have permission to access the URL on this server. Sorry for the inconvenience.

被拒了，所以這種赤裸裸地請求是不行的。沒關系，那就稍微包裝一下：
send_headers = {
'User-Agent':'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36',
'Accept':'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'Connection':'keep-alive',
'Host':'xueqiu.com',
'Cookie':r'xxxxxx',
}
req = urllib2.Request(url, headers=send_headers)
resp = urllib2.urlopen(req)
html = resp.read()

header 數據都可以從 Developer Tools 里拿到。這次順利抓到頁面內容。
一般網站或多或少都會對請求來源做一些阻攔，通過加 header 可以搞定大部分情況。
Step.3 提取數據
因為這個數據比較明顯，直接用通過一些字元串查找和截取操作就可以取出來。
pos_start = html.find('SNB.cubeInfo = ') + len('SNB.cubeInfo = ')
pos_end = html.find('SNB.cubePieData')
data = html[pos_start:pos_end]
dic = json.loads(data)

dic 就是一個包含數據的字典對象。之後想干什麼就隨便你了。
對於復雜一點的情況，可以通過 BeautifulSoup 來定位 html 標簽。再不好辦的，就用正則表達式，基本都可以解決掉。
Step.4 處理數據
因為我想對數據進行持久化存儲，並且做展示和分析，所以我用了 django 里的 ORM 來處理抓下來的數據。
# add Portfolio
portfolio, c = models.Portfolio.objects.get_or_create(code=dic['symbol'])
portfolio.name = dic['name']
portfolio.earnings = dic['total_gain']
portfolio.save()
# add Stock
stocks = dic['view_rebalancing']['holdings']
for s in stocks:
stock, c = models.Stock.objects.get_or_create(code=s['stock_symbol'])
stock.name = s['stock_name']
stock.count += 1
stock.weight += s['weight']
stock.save()

Portfolio 記錄下組合及其收益，Stock則記錄每支股票的被收錄數和總收錄份額。
對於抓取到的，一般也可以存在文件中，或者直接通過 SQL 存入資料庫，視不同情況和個人喜好而定。
Step.5 批量抓取
前面的一套做下來，就完整地抓取了一組數據。要達到目的，還要設計一下批量抓取的程序。
一個要解決的問題就是如何獲得組合列表。這個可以再通過另一個抓取程序來實現。然後根據這些列表來循環抓取就可以了。
若要細究，還要考慮列表如何保存和使用，如何處理抓取失敗和重復抓取，如何控制抓取頻率防止被封，可否並行抓取等等。
Step.6 數據分析
數據有了，你要怎麼用它，這是個很大的問題。可以簡單的統計現象，也可以想辦法深入分析背後隱藏的邏輯。不多說，我也還只是在摸索之中。

㈦ 達內 股票數據雪球 雪球怎麼跟股票

這家的數據還算不錯，可以

㈧ 如何通過雪球查詢股票之前的變動狀況

一. 雪球公司介紹

雪球 聰明的投資者都在這里。

web 1.0：新聞資訊，股價信息，K線圖
web 2.0：SNS 訂閱，分享，聊天
web 3.0：移動 APP，交易閉環
雪球現在員工數還不到100，其中技術人員佔一半。去年9月C輪融資4kw刀。我們現在的技術棧由下列組件組成：Java，Scala，Akka，Finagle，Nodejs，Docker ，Hadoop。我們當前是租用IDC機房自建私有雲，正在往「公私混合雲」方向發展。

在雪球上，用戶可以獲取滬深港美2w+股票的新聞信息，股價變化情況，也可以獲取債券，期貨，基金，比特幣，信託，理財，私募等等理財產品的各類信息，也可以關注雪球用戶建立的百萬組合，訂閱它們的實時調倉信息，還可以關注雪球大V。雪球當前有百萬日活躍用戶，每天有4億的API調用。App Store 財務免費榜第 18 名。歷史上曾排到財務第二，總免費榜第 19。

二. 雪球當前總體架構

作為一個典型的移動互聯網創業公司，雪球的總體架構也是非常典型的設計：

最上層是三個端：web端，android端和iOS端。流量比例大約為 2：4：4 。web3.0 的交易功能，在 web 端並不提供。
接入層以及下面的幾個層，都在我們的自建機房內部。雪球當前只部署了一個機房，還屬於單機房時代。正在進行「私有雲+公有雲混合部署」方案推進過程中。
我們當前使用 nodejs 作為 web 端模板引擎。nodejs 模塊與android 和 ios 的 app 模塊一起屬於大前端團隊負責。
再往下是位於 nginx 後面的 api 模塊。跟 linkedin 的 leo 和微博的 v4 一樣，雪球也有一個遺留的大一統系統，名字就叫 snowball 。最初，所有的邏輯都在 snowball 中實現的。後來慢慢的拆出去了很多 rpc 服務，再後來慢慢的拆出去了一些 http api 做成了獨立業務，但即便如此，snowball 仍然是雪球系統中最大的一個部署單元。
在需要性能的地方，我們使用 netty 搭建了一些獨立的介面，比如 quoto server，是用來提供開盤期間每秒一次的股價查詢服務，單機 qps 5w+，這個一會再細說；而 IM 服務，起初設計里是用來提供聊天服務，而現在，它最大的用途是提供一個可靠的 push 通道，提供 5w/s 的消息下發容量，這個也一會再細說。
雪球的服務化拆分及治理採用 twitter 開源的 finagle rpc 框架，並在上面進行了一些二次開發和定製。定製的功能主要集中在 access log 增強，和 fail fast，fail over 策略及降級開關等。 finagle 的實現比較復雜，debug 和二次開發的門檻較高，團隊內部對此也進行了一些討論。
雪球的業務比較復雜，在服務層中，大致可以分為幾類：第一類是web1.0，2.0 及基礎服務，我們稱為社區，包括用戶，帖子，新聞，股價，搜索等等，類比對象就是新浪財經門戶+微博；第二類是組合及推薦，主要提供股票投資策略的展示和建議，類比對象是美國的motif；第三類是通道，類似股市中的「支付寶」，接入多家券商，提供瞬間開戶，一鍵下單等等各種方便操作的功能。
雪球的業務實現中，包含很多非同步計算邏輯，比如搜索建索引，比如股票漲跌停發通知，比如組合收益計算等等，為此，我們設計了一個獨立的 Thread/Task 模塊，方便管理所有的後台計算任務。但隨著這些 task 越來越多，邏輯差異越來越大，一個統一的模塊並不是總是最佳的方案，所以，我們又把它拆成了兩大類：流式的，和批量式的。
雪球的推薦體系包括組合推薦「買什麼」和個性化推薦。我們最近正在重新梳理我們的大數據體系，這個感興趣的話可以單聊。
最下面是基礎設施層。雪球基礎設施層包括：redis，mysql，mq，zk，hdfs，以及容器 docker。
線上服務之外，我們的開發及後台設施也很典型：gitlab開發，jenkins打包，zabbix 監控系統向 openfalcon 遷移，redimine向confluence遷移，jira，以及內部開發的 skiing 後台管理系統。
** 三. 雪球架構優化歷程**

首先描述一下標題中的「股市動盪」定語修飾詞吧：

上證指數從年初的3000點半年時間漲到了5000多，6月12號達到最高點5200點，然後就急轉直下，最大單日跌幅 8.48%，一路跌回4000點以下。最近一周都在3900多徘徊。

3月最後一周，A股開戶 166萬戶，超過歷史最高紀錄 2007年5月第二周165萬戶。

4月份，證監會宣布A股支持單用戶開設多賬戶。

6月底，證金公司代表國家隊入場救市。

7月份，證監會宣布嚴打場外配資。

中國好聲音廣告第一晚，帶來超過平時峰值200倍的注冊量

挑戰：小 VS 大：

小：小公司的體量，團隊小，機器規模小
大：堪比大公司的業務線數量，業務復雜度，瞬間峰值沖擊

雪球的業務線 = 1個新浪財經 + 1 個微博 + 1 個 motif + 1 個大智慧/同花順。由於基數小，API調用瞬間峰值大約為平時峰值的 30+ 倍。

挑戰：快速增長，移動互聯網 + 金融，風口，A股大盤劇烈波動。

首先，在app端，在我們核心業務從 web2.0 sns 向 3.0 移動交易閉環進化的過程中，我們開發了一個自己的 hybrid 框架：本地原生框架，加離線 h5 頁面，以此來支撐我們的快速業務迭代。當前，雪球前端可以做到 2 周一個版本，且同時並行推進 3 個版本：一個在 app store 等待審核上線，一個在內測或公測，一個在開發。我們的前端架構師孟祥宇在今年的 wot 上有一個關於這方面的詳細分享，有興趣的可以稍後再深入了解。

雪球App實踐—構建靈活、可靠的Hybrid框架 http://wot.51cto.com/2015mobile/ http://down.51cto.com/data/2080769

另外，為了保障服務的可用性，我們做了一系列的「端到端服務質量監控」。感興趣的可以搜索我今年4月份在環信SM meetup上做的分享《移動時代端到端的穩定性保障》。其中在 app 端，我們採用了一種代價最小的數據傳輸方案：對用戶的網路流量，電池等額外消耗幾乎為0

每個請求里帶上前一個請求的結果

succ or fail ： 1 char
失敗原因：0 - 1 char
請求介面編號： 1 char
請求耗時：2 - 3 char
其它：網路制式，etc
炒股的人大多都會盯盤：即在開盤期間，開著一個web頁面或者app，實時的看股價的上下跳動。說到「實時」，美股港股當前都是流式的數據推送，但國內的A股，基本上都是每隔一段時間給出一份系統中所有股票現價的一個快照。這個時間間隔，理論上是3秒，實際上一般都在5秒左右。 交了錢簽了合同，雪球作為合作方就可以從交易所下屬的數據公司那裡拿到數據了，然後提供給自己的用戶使用。

剛才介紹總體架構圖的時候有提到 quote server ，說到這是需要性能的地方。

業務場景是這樣的，雪球上個人主頁，開盤期間，每秒輪詢一次當前用戶關注的股票價格變動情況。在內部，所有的組合收益計算，每隔一段時間需要獲取一下當前所有股票的實時價格。起初同時在線用戶不多，這個介面就是一個部署在 snowball 中的普通介面，股價信息被實時寫入 redis ，讀取的時候就從 redis 中讀。後來，A股大漲，snowball 抗不住了。於是我們就做了一個典型的優化：獨立 server + 本地內存存儲。開盤期間每次數據更新後，數據接收組件主動去更新 quote server 內存中的數據。 後續進一步優化方案是將這個介面以及相關的處理邏輯都遷移到公有雲上去。

對於那些不盯盤的人，最實用的功能就是股價提醒了。在雪球上，你除了可以關注用戶，還可以關注股票。如果你關注的某隻股票漲了或跌了，我們都可以非常及時的通知你。雪球上熱門股票擁有超過 50w 粉絲（招商銀行，蘇寧雲商）粉絲可以設置：當這支股票漲幅或跌幅超過 x%（默認7%）時提醒我。曾經連續3天，每天超過1000股跌停，證監會開了一個會，於是接下來2天超過1000股漲停

原來做法：

股票漲（跌）x%，掃一遍粉絲列表，過濾出所有符合條件的粉絲，推送消息
新做法：

預先建立索引，開盤期間載入內存
1%：uid1，uid2
2%：uid3，uid4，uid5
3%：uid6
問題：有時候嫌太及時了：頻繁跌停，打開跌停，再跌停，再打開。。。的時候
內部線上記錄：

4台機器。
單條消息延時 99% 小於 30秒。
下一步優化目標：99% 小於 10 秒
IM 系統最初的設計目標是為雪球上的用戶提供一個聊天的功能:

送達率第一
雪球IM：Netty + 自定義網路協議
Akka ： 每個在線client一個actor
推模式：client 在線情況下使用推模式
多端同步：單賬號多端可登錄，並保持各種狀態同步
移動互聯網時代，除了微信qq以外的所有IM，都轉型成了推送通道，核心指標變成了瞬間峰值性能。原有架構很多地方都不太合適了。

優化：

分配更多資源：推送賬號actor池
精簡業務邏輯：重復消息只存id，實時提醒內容不推歷史設備，不更新非活躍設備的session列表等等
本地緩存：拉黑等無法精簡的業務邏輯遷移到本地緩存
優化代碼：非同步加密存儲，去除不合理的 akka 使用
akka這個解釋一下：akka 有一個自己的 log adapter，內部使用一個 actor 來處理所有的 log event stream 。當瞬間峰值到來的時候，這個 event stream 一下子就堵了上百萬條 log ，導致 gc 顛簸非常嚴重。最後的解決辦法是，繞過 akka 的 log adapter，直接使用 logback 的 appender

線上記錄：5w/s （主動限速）的推送持續 3 分鍾，p99 性能指標無明顯變化

7月10號我們在中國好聲音上做了3期廣告。在廣告播出之前，我們針對廣告可能帶來的對系統的沖擊進行了壓力測試，主要是新用戶注冊模塊，當時預估廣告播出期間2小時新注冊100萬

壓測發現 DB 成為瓶頸：

昵稱檢測 cache miss > 40%
昵稱禁用詞 where like 模糊查詢
手機號是否注冊 cache miss > 80%
注冊新用戶：5 insert
優化：

redis store：昵稱，手機號
本地存儲：昵稱禁用詞
業務流程優化：DB insert 操作同步改非同步
下一步優化計劃：

將 sns 系統中所有的上行操作都改成類似的非同步模式
介面調用時中只更新緩存，而且主動設置5分鍾過期，然後寫一個消息到 mq 隊列，隊列處理程序拿到消息再做其它耗時操作。
為了支持失敗重試，需要將主要的資源操作步驟都做成冪等。
前置模塊HA：

合作方合規要求：業務單元部署到合作方內網，用戶的敏感數據不允許離開進程內存
業務本身要求：業務單元本身為有狀態服務，業務單元高可用
解決方案：

使用 Hazelcast In-Memory Data Grid 的 replication map 在多個 jvm 實例之間做數據同步。

java 啟動參數加上 -XX:+DisableAttachMechanism -XX:-UsePerfData，禁止 jstack，jmap 等等 jdk 工具連接

關於前置模塊，其實還有很多很奇葩的故事，鑒於時間關系，這里就不展開講了。以後有機會可以當笑話給大家講。

組合凈值計算性能優化：

一支股票可能在超過20萬個組合里（南車北車中車，暴風科技）
離線計算，存儲計算後的結果
股價3秒變一次，涉及到這支股票的所有組合理論上也需要每 3 秒重新計算一次
大家可能會問，為什麼不用戶請求時，實時計算呢？這是因為「組合凈值」中還包括分紅送配，分股，送股，拆股，合股，現金，紅利等等，業務太過復雜，開發初期經常需要調整計算邏輯，所以就設計成後台離線計算模式了。當前正在改造，將分紅送配邏輯做成離線計算，股價組成的凈值實時計算。介面請求是，將實時計算部分和離線計算部分合並成最終結果。

實際上，我們的計算邏輯是比較低效的：循環遍歷所有的組合，對每個組合，獲取所有的價值數據，然後計算。完成一遍循環後，立即開始下一輪循環。

優化：

分級：活躍用戶的活躍組合，其它組合。
批量：拉取當前所有股票的現價到 JVM 內存里，這一輪的所有組合計算都用這一份股價快照。
關於這個話題的更詳細內容，感興趣的可以參考雪球組合業務總監張岩楓在今年的 arch summit 深圳大會上的分享：構建高可用的雪球投資組合系統技術實踐 http://sz2015.archsummit.com/speakers/201825

最後，我們還做了一些通用的架構和性能優化，包括jdk升級到8，開發了一個基於 zookeeper 的 config center 和開關降級系統

四. 聊聊關於架構優化的一些總結和感想

在各種場合經常聽說的架構優化，一般都是優化某一個具體的業務模塊，將性能優化到極致。而在雪球，我們做的架構優化更多的是從問題出發，解決實際問題，解決到可以接受的程度即可。可能大家看起來會覺得很凌亂，而且每個事情單獨拎出來好像都不是什麼大事。

我們在對一個大服務做架構優化時，一般是往深入的本質進行挖掘；當我們面對一堆架構各異的小服務時，「架構優化」的含義其實是有一些不一樣的。大部分時候，我們並不需要（也沒有辦法）深入到小服務的最底層進行優化，而是去掉或者優化原來明顯不合理的地方就可以了。

在快速迭代的創業公司，我們可能不會針對某一個服務做很完善的架構設計和代碼實現，當出現各種問題時，也不會去追求極致的優化，而是以解決瓶頸問題為先。

即使我們經歷過一回將 snowball 拆分服務化的過程，但當我們重新上一個新的業務時，我們依然選擇將它做成一個大一統的服務。只是這一次，我們會提前定義好每個模塊的 service 介面，為以後可能的服務化鋪好路。

在創業公司里，重寫是不能接受的；大的重構，從時間和人力投入上看，一般也是無法承擔的。而「裱糊匠」式做法，哪裡有性能問題就加機器，加緩存，加資料庫，有可用性問題就加重試，加log，出故障就加流程，加測試，這也不是雪球團隊工作方式。我們一般都採用最小改動的方式，即，准確定義問題，定位問題根源，找到問題本質，制定最佳方案，以最小的改動代價，將問題解決到可接受的范圍內。

我們現在正在所有的地方強推3個數據指標：qps，p99，error rate。每個技術人員對自己負責的服務，一定要有最基本的數據指標意識。數字，是發現問題，定位根源，找到本質的最重要的依賴條件。沒有之一。

我們的原則：保持技術棧的一致性和簡單性，有節制的嘗試新技術，保持所有線上服務依賴的技術可控，簡單來說，能 hold 住。

能用cache的地方絕不用db，能非同步的地方，絕不同步。俗稱的：吃一塹，長一智。

特事特辦：業務在發展，需求在變化，實現方式也需要跟著變化。簡單的來說：遺留系統的優化，最佳方案就是砍需求，呵呵。

㈨ 如何使用 Python 抓取雪球網頁

#start coding
首先要知道自己在爬什麼~樓主說找到HTML的代碼雲雲，思路其實是錯誤的。因為我們想要的內容不在原始的html裡面。但是肯定在瀏覽器和伺服器之間的通信里，我們只要找到這部分數據就好。
#我用的是Firefox的FireBug
選擇網路（Chrome中應該是Network），點擊調倉歷史記錄
可以看到瀏覽器和伺服器之間進行了一次通信。我們截獲了一個網址。打開看看。可以看到瀏覽器和伺服器之間進行了一次通信。我們截獲了一個網址。打開看看。

看上去像是一堆亂碼，但是細心的話就會發現……
也就是說我們要的數據都在這里了，所以只要先獲取這個頁面的內容然後在提取數據就好了~

#python3項目，python2中請使用urllib和urllib2
import urllib.request
url = '?cube_symbol=ZH010389&count=20&page=1'
req = urllib.request.Request(url,headers=headers)
html = urllib.request.urlopen(req).read().decode('utf-8')
print(html)

運行一下~
報錯了~報錯沒關系，兵來將擋水來土掩~
403禁止訪問…應該是headers的問題…什麼是headers呢…403禁止訪問…應該是headers的問題…什麼是headers呢…
你現在用python去訪問網頁，網頁得到的請求就是你是python程序，但是網頁並不想讓程序看到自己，因為他是給人看的，資源都被程序佔了算什麼，所以我們要讓python偽裝成瀏覽器。
依然是用Firebug查看headers信息。
然後我們完善代碼在訪問過程中添加headers~然後我們完善代碼在訪問過程中添加headers~

import urllib.request
headers = {'X-Requested-With': 'XMLHttpRequest',
'Referer': '',
'User-Agent': 'Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0',
'Host': 'xueqiu.com',
#'Connection':'keep-alive',
#'Accept':'*/*',
'cookie':'s=iabht2os.1dgjn9z; xq_a_token=; xq_r_token=; __utma=1.2130135756.1433017807.1433017807.1433017807.1;'
'__utmc=1; __utmz=1.1433017807.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); Hm_lvt_=1433017809; Hm_lpvt_=1433017809'}

url = '?cube_symbol=ZH010389&count=20&page=1'
req = urllib.request.Request(url,headers=headers)
html = urllib.request.urlopen(req).read().decode('utf-8')
print(html)

這次得到想要的結果了~

我們回過頭再去看headers會發現，其實有些我並沒有寫進去，你也可以自己嘗試把headers中的某一行注釋掉運行。但是每個站是不一樣的，你把所有的都填上去是一定能運行成功的，但是可能其中某一些不是必需的。
比如我們這里只要有User-Agent（缺少報錯403）和cookie（缺少報錯400）。
好~我們現在拿到了想要的數據，但是看上去太復雜了，一點都不友好。現在我們來解析一下這個網頁。其實這個網頁是json格式的數據包。
然後我們來觀察這個數據的解析。然後我們來觀察這個數據的解析。
#你可以直接點擊Firebug中的JSON來看，也可以復制到Notepad++中使用json viewer插件查看。
大概是這個樣子的……大概是這個樣子的……
有了json的構成結構我們就可以來解析它了…
我直接拿Python Shell調試，一會兒完善代碼

沒什麼問題~一切看起來很完美的樣子~這一步其實沒什麼難度，只要你能看懂上一步里我們分析的json數據的組成結構，然後一層一層地向下解析數據就可以了。
完善代碼。

import urllib.request
import json
headers = {#'X-Requested-With': 'XMLHttpRequest',
#'Referer': '',
'User-Agent': 'Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0',
#'Host': 'xueqiu.com',
#'Connection':'keep-alive',
#'Accept':'*/*',
'cookie':'s=iabht2os.1dgjn9z; xq_a_token=; xq_r_token=; __utma=1.2130135756.1433017807.1433017807.1433017807.1;'
'__utmc=1; __utmz=1.1433017807.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); Hm_lvt_=1433017809; Hm_lpvt_=1433017809'}
url = '?cube_symbol=ZH010389&count=20&page=1'
req = urllib.request.Request(url,headers=headers)
html = urllib.request.urlopen(req).read().decode('utf-8')
#print(html)
data = json.loads(html)
print('股票名稱',end=':')
print(data['list'][0]['rebalancing_histories'][0]['stock_name'],end=' 持倉變化')
print(data['list'][0]['rebalancing_histories'][0]['prev_weight'],end='-->')
print(data['list'][0]['rebalancing_histories'][0]['target_weight'])
print('股票名稱',end=':')
print(data['list'][0]['rebalancing_histories'][1]['stock_name'],end=' 持倉變化')
print(data['list'][0]['rebalancing_histories'][1]['prev_weight'],end='-->')
print(data['list'][0]['rebalancing_histories'][1]['target_weight'])

運行程序~

好嘞！搞定收工！
當然也還不能收工……只是我不幹了而已……
To-dos:

可以看到程序是面向過程的…重復代碼很多，可以通過定義類或方法實現調用
大概……大概得寫點注釋……不過這么簡單直接無腦面向過程的代碼真的需要注釋嗎
如果是想在他持倉變化時收到提醒，需要爬蟲定時爬取頁面數據與之前數據進行比較
如果你更細心的話會發現最初的json網址的構成是這樣的…cube_symbol='#此處可添加任意組合的號碼例如ZH010389'&count=『#此處數字是一次獲取的交易變化數量,也就是說你一次性拿到了20次的交易,你點開之前交易記錄的時候並不會重新請求數據而是讀取了本地現有的數據此處數據可以任意修改哦~很神奇的試一試吧~20』&page=『和前面聯系起來,前面是一次性獲取20條記錄,這邊便是頁碼,通過對page數的控制利用循環可以輸出所有交易過程,當然,40一頁和20兩頁的效果顯然是一樣的,看你怎麼玩兒了~1』
如果你有耐心看完上面那一大段話的話想必你可以有更多的想法。讓別人來指導我們的思路是好的，可是投資的機會稍瞬即逝，跟在別人後面是沒有前途的，我們要學習。大數據的時代為什麼不試試爬更多人的更多投資記錄呢？比如在雪球首頁爬取首頁推薦的組合，然後自動爬取這些組合所做的所有操作~這樣你是不是就有了很厚的一本交易目錄，結合過去的股市數據（這些能不能想辦法自動獲取呢？），你可以自己嘗試分析別人作出投資決定的原因（是不是可以把數據自動寫入一個excel？提示：xlwt3）…最終指導自己的投資。大數據學習，想想都炫酷。可惜我不炒股…

大概就醬紫~希望有幫助~
寫這么多是因為我自己在學爬蟲…一周了…看到實踐的機會就來試一下…所以是邊調BUG邊寫答案~
大概就寫這么多吧…後面的To-dos哪天我突然感興趣了會試著寫一下或者過來補充的…
看到這個答案的…前輩還希望多多指教；看到這個答案的新手…歡迎交流：P

㈩ 怎樣從互聯網上採集股票數據

你可以從網上下載免費的股票軟體，如「大智慧」，「同花順」等。很方便，什麼數據都有。