手機(jī)出現(xiàn)SSL怎么解決？

隨著網(wǎng)絡(luò)安全的普及，大多數(shù)人都知道網(wǎng)站要確保安全需要安裝SSL證書(shū)，但卻不知道手機(jī)里的應(yīng)用也是需要SSL證書(shū)保護(hù)的。手機(jī)應(yīng)用要確保安全的話，也需要安裝https證書(shū)，這樣才能使用戶的訪問(wèn)更安全，手機(jī)應(yīng)用中的數(shù)據(jù)更安全。不過(guò)，手機(jī)證書(shū)有時(shí)也會(huì)出現(xiàn)證書(shū)錯(cuò)誤，比如Android手機(jī)SSL證書(shū)連接錯(cuò)誤，下面就來(lái)看看怎樣修復(fù)這些錯(cuò)誤。

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)灤州,10多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢建站服務(wù):18980820575

怎樣修復(fù)Android手機(jī)上的SSL連接錯(cuò)誤？

當(dāng)你在Android手機(jī)上接收到SSL證書(shū)錯(cuò)誤信息提示時(shí)，如下圖所示，你需要檢查修復(fù)此SSL連接錯(cuò)誤。

這里有五種方式可以幫助你解決這個(gè)問(wèn)題。如果一種不行，請(qǐng)嘗試下一個(gè)。

1.） 更正Android設(shè)備上的日期和時(shí)間

手機(jī)SSL證書(shū)連接時(shí)，最容易出現(xiàn)的就是日期和時(shí)間的錯(cuò)誤，解決這一問(wèn)題的方法非常簡(jiǎn)單，只要選擇“設(shè)置”并選擇“日期時(shí)間”，進(jìn)入這一界面后，激活“自動(dòng)更新日期時(shí)間”選項(xiàng)，在這里就可以對(duì)時(shí)間和日期進(jìn)行修改了。

2.） 清除Chrome上的瀏覽數(shù)據(jù)

如果修改日期時(shí)間這種方法無(wú)效，你可能需要清除你的瀏覽數(shù)據(jù)。這是另一種簡(jiǎn)單的方式。首先打開(kāi)Chrome，點(diǎn)擊"菜單"選項(xiàng)，然后轉(zhuǎn)到"隱私"并選擇"設(shè)置"，然后選擇“清除瀏覽數(shù)據(jù)”，檢查屏幕上所有的勾選框，然后點(diǎn)擊“清除”。

3.） 更改WiFi連接

如果以上兩種方法都不起作用，請(qǐng)?jiān)囍哪愕脑O(shè)備上的WiFi連接。如果你登錄的是公共的WiFi，則可能存在不安全的情況。所以請(qǐng)連接一個(gè)私有的WiFi，然后查看Android錯(cuò)誤是否得到了修復(fù)。

4.） 暫時(shí)禁用殺毒軟件

如果你已經(jīng)在你的Android手機(jī)上安裝了殺毒軟件或安全應(yīng)用程序，請(qǐng)暫時(shí)禁用此類(lèi)程序軟件，然后再開(kāi)始瀏覽網(wǎng)頁(yè)。有時(shí)，這些殺毒app可能會(huì)干擾你的瀏覽器，使它們不能進(jìn)行SSL連接。

5.） 重置你的Android設(shè)備

如果以上所述方法都不能解決SSL證書(shū)錯(cuò)誤連接的問(wèn)題，你還可以選擇重置你的Android設(shè)備。不過(guò)這個(gè)方法有一定風(fēng)險(xiǎn)性，為了防止你丟失存儲(chǔ)的東西，建議在重置設(shè)備之前備份您的手機(jī)數(shù)據(jù)，然后選擇重置工廠數(shù)據(jù)就可以解決連接問(wèn)題。

一文弄懂關(guān)于證書(shū)，簽名，ssl，android包簽名機(jī)制。

所有的概念都基于一個(gè)非常重要的基礎(chǔ)：

rsa 非對(duì)稱(chēng)加密算法 ：

先感受下幾個(gè)概念

PKI。

PKI是公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure) 包括PKI策略、軟硬件系統(tǒng)、證書(shū)機(jī)構(gòu)CA、注冊(cè)機(jī)構(gòu)RA、證書(shū)發(fā)布系統(tǒng)和PKI應(yīng)用等。

我們關(guān)注就倆東西： PKCS 證書(shū)機(jī)構(gòu)CA 。前者是定義加密算法，簽名，證書(shū)相關(guān)的各種事情采用的協(xié)議。后者可以為我們頒發(fā)權(quán)威的證書(shū)。

PKCS ：

PKCS（The Public-Key Cryptography Standards ）是由美國(guó)RSA數(shù)據(jù)安全公司及其合作伙伴制定的一組公鑰密碼學(xué)標(biāo)準(zhǔn)，其中包括證書(shū)申請(qǐng)、證書(shū)更新、證書(shū)作廢表發(fā)布、擴(kuò)展證書(shū)內(nèi)容以及數(shù)字簽名、數(shù)字信封的格式等方面的一系列相關(guān)協(xié)議。RSA算法可以做加密、解密、簽名、驗(yàn)證，還有RSA的密鑰對(duì)存儲(chǔ)。這些都需要標(biāo)準(zhǔn)來(lái)規(guī)范，如何輸入，如何輸出，如何存儲(chǔ)等。

PKCS。全稱(chēng)是公鑰密碼學(xué)標(biāo)準(zhǔn)， 目前共發(fā)布過(guò) 15 個(gè)標(biāo)準(zhǔn)，這些標(biāo)準(zhǔn)都是協(xié)議。總結(jié)一下 就是對(duì)加密算法，簽名，證書(shū)協(xié)議的描述。下面列舉一些常用的協(xié)議，這些協(xié)議在本文都會(huì)對(duì)應(yīng)上。

這些協(xié)議具體的實(shí)現(xiàn)就體現(xiàn)在openssl等工具中， 以及jdk工具keytool jdk java第三方庫(kù)bouncycastle。

比如用openssl 如何生成公/私鑰(PKCS#1)、簽名(PKCS#1 )、簽名請(qǐng)求文件（KCS#10）、 帶口令的私鑰（PKCS#8）。 含私鑰的證書(shū)（PKCS#12）、證書(shū)庫(kù)（PKCS#12）

其中涉及到算法的基礎(chǔ)協(xié)議PKCS#1等，由于涉及到密碼學(xué)原理所以我們并不需要深究它，只要知道怎么做就可以了。

現(xiàn)實(shí)中我們要解決這樣一種情況:

客戶端和服務(wù)器之間的數(shù)據(jù)要進(jìn)行加密。需要兩個(gè)達(dá)成同一個(gè)對(duì)稱(chēng)秘鑰加密才行，那么這個(gè)秘鑰如何生成，并在兩邊都能拿到，并保證傳輸過(guò)程中不被泄露。 這就用到非對(duì)稱(chēng)加密了。 后續(xù)的傳輸，就能用這個(gè) 對(duì)稱(chēng)秘鑰來(lái)加密和解密了。

還有這樣一個(gè)問(wèn)題：

就是客戶端如何判斷服務(wù)端是否是合法的服務(wù)端。這就需要服務(wù)端有個(gè)id來(lái)證明它，而這個(gè)id 就是證書(shū)，而且必須是權(quán)威機(jī)構(gòu)頒發(fā)的才能算是合法的。

因?yàn)榭蛻舳思礊g覽器，認(rèn)定證書(shū)合法的規(guī)則必須通過(guò)第三方來(lái)確認(rèn) 即ca頒發(fā)的證書(shū)。否則就我可能進(jìn)了一個(gè)假網(wǎng)站。

而這兩個(gè)問(wèn)題 都是ssl協(xié)議要解決的內(nèi)容。

所以ssl協(xié)議做了兩件事情，一是驗(yàn)證身份，二是協(xié)商對(duì)稱(chēng)秘鑰，并安全的傳輸。 而實(shí)現(xiàn)這個(gè)過(guò)程的關(guān)鍵數(shù)據(jù)模型就是證書(shū)， 通過(guò)證書(shū)中的ca對(duì)證書(shū)的簽名，實(shí)現(xiàn)了身份驗(yàn)證，通過(guò)證書(shū)中的公鑰，實(shí)現(xiàn)對(duì)對(duì)稱(chēng)秘鑰加密，從而實(shí)現(xiàn)數(shù)據(jù)保密。 其實(shí)還順手做了一件事情就是通過(guò)解密簽名比對(duì)hash，保證了數(shù)據(jù)完整性。

明白ssl協(xié)議 首先明白幾個(gè)重要的概念：

證書(shū)： 顧名思義就是提供了一種在Internet上驗(yàn)證通信實(shí)體身份的方式，數(shù)字證書(shū)不是數(shù)字身份證，由權(quán)威公正的第三方機(jī)構(gòu)，即CA（例如中國(guó)各地方的CA公司）中心簽發(fā)的證書(shū)， 就是可以認(rèn)定是合法身份的。客戶端不需要證書(shū)。 證書(shū)是用來(lái)驗(yàn)證服務(wù)端的。

一般的證書(shū)都是x509格式證書(shū)，這是一種標(biāo)準(zhǔn)的證書(shū)，可以和其他證書(shū)類(lèi)型互相轉(zhuǎn)換。完整來(lái)說(shuō)證書(shū)包含，證書(shū)的內(nèi)容，包括 版本號(hào)， 證書(shū)序列號(hào)， hash算法， 發(fā)行者名稱(chēng)，有效期， 公鑰算法，公鑰，簽名（證書(shū)原文以及原文hash一起簽名）而這個(gè)內(nèi)容以及格式 都是標(biāo)準(zhǔn)化的，即x509格式 是一種標(biāo)準(zhǔn)的格式。

簽名: 就用私鑰對(duì)一段數(shù)據(jù)進(jìn)行加密，得到的密文。 這一段數(shù)據(jù)在證書(shū)的應(yīng)用上就是 對(duì)證書(shū)原文+原文hash進(jìn)行簽名。

誰(shuí)簽的名，就是用誰(shuí)的私鑰進(jìn)行加密。就像身份證一樣， 合法的身份證我們都依據(jù)是政府簽的，才不是假證， 那就是瀏覽器會(huì)有政府的公鑰，通過(guò)校驗(yàn)（解密）簽名，如果能夠解密，就可以確定這個(gè)就是政府的簽名。就對(duì)了。

hash算法 ：對(duì)原始數(shù)據(jù)進(jìn)行某種形式的信息提取，被提取出的信息就被稱(chēng)作原始數(shù)據(jù)的消息摘要。比如，MD5和SHA-1及其大量的變體。 hash算法具有不可逆性，無(wú)法從摘要中恢復(fù)出任何的原始消息。長(zhǎng)度總是固定的。MD5算法摘要的消息有128個(gè)比特位，SHA-1算法摘要的消息最終有160比特位的輸出。

ca機(jī)構(gòu)： 權(quán)威證書(shū)頒發(fā)機(jī)構(gòu)，瀏覽器存有ca的公鑰，瀏覽器以此公鑰來(lái)驗(yàn)證服務(wù)端證書(shū)的合法性。

證書(shū)的獲取： 生成證書(shū)申請(qǐng)文件.csr（涉及到PKCS#10定義的規(guī)范）后向ca機(jī)構(gòu)申請(qǐng)。 或者自己直接通過(guò)生成私鑰就可以一步到位生成自簽名證書(shū)。 自簽名證書(shū)就是用自己的私鑰來(lái)簽名證書(shū)。

那么為了體現(xiàn)到 證書(shū)身份認(rèn)證、數(shù)據(jù)完整、保密性三大特性 ，證書(shū)的簡(jiǎn)化模型可以認(rèn)為包含以下兩個(gè)要素：服務(wù)器公鑰，ca的簽名（被ca私鑰加密過(guò)的證書(shū)原文+原文hash），

身份認(rèn)證：

瀏覽器存有ca公鑰，用ca公鑰解密網(wǎng)站發(fā)給你的證書(shū)中的簽名。如果能解密，說(shuō)明該證書(shū)由ca頒發(fā)，證書(shū)合法。 否則瀏覽器就會(huì)報(bào)警告，問(wèn)你是否信任這個(gè)證書(shū)，也就是這個(gè)網(wǎng)站。這時(shí)候的證書(shū)可以是任何人簽發(fā)的，可以自己簽發(fā)的。 但是中間人攻擊。 完全偽造新的證書(shū)， 這就沒(méi)有辦法了。 所以還是信任證書(shū)的時(shí)候要謹(jǐn)慎。

數(shù)據(jù)完整：

如果你信任該證書(shū)的話，這時(shí)候就會(huì)用證書(shū)中的公鑰去解密簽名，如果是ca簽發(fā)的證書(shū)，那么之前就已經(jīng)通過(guò)ca的公鑰去解密簽名了。 然后得到證書(shū)hash，然后在瀏覽器重新對(duì)證書(shū)做hash，兩者比對(duì)一致的話，說(shuō)明證書(shū)數(shù)據(jù)沒(méi)有被篡改。

保密性：

使用證書(shū)的公鑰對(duì)對(duì)稱(chēng)秘鑰加密保證傳輸安全，對(duì)稱(chēng)秘鑰生成后，后續(xù)的傳輸會(huì)通過(guò)對(duì)稱(chēng)秘鑰來(lái)在服務(wù)端和客戶端的加解密。

那么ssl協(xié)議的具體過(guò)程就是：

4.網(wǎng)站接收瀏覽器發(fā)來(lái)的數(shù)據(jù)之后 使用自己的私鑰校驗(yàn)簽名，并對(duì)原文進(jìn)行hash 與解密出的hash 做比對(duì)檢查完整性。然后發(fā)送編碼改變通知，服務(wù)器握手結(jié)束通知（所有內(nèi)容做hash ）。 發(fā)送給客戶端校驗(yàn)。

5 客戶端校驗(yàn)，校驗(yàn)成功后，之后就用 對(duì)稱(chēng)秘鑰進(jìn)行通信了。

總共的過(guò)程是 c-s-c- s-c 四次握手。

四次握手簡(jiǎn)單來(lái)說(shuō)分別是：

1.請(qǐng)求獲取證書(shū)

2.服務(wù)端返回證書(shū)，客戶端驗(yàn)證了證書(shū)的合法性和完整性，同時(shí)生成了對(duì)稱(chēng)秘鑰。

3.客戶端把加密的 對(duì)稱(chēng)秘鑰發(fā)給服務(wù)器。服務(wù)器檢查真實(shí)性和完整性。

4.服務(wù)端返回握手結(jié)束通知，客戶端再檢查一次真實(shí)性和完整性。

前兩次握手是明文， 后兩次握手是密文。 所以都要檢查身份真實(shí)性和數(shù)據(jù)完整性。

ca的作用：

ca起到一個(gè)權(quán)威中間人的角色，如果脫離了ca， 那么證書(shū)還是證書(shū)，還能加密，保證數(shù)據(jù)完整性。 但是無(wú)法應(yīng)用在客戶端去認(rèn)定服務(wù)器身份合法這個(gè)場(chǎng)景下。

下面就詳細(xì)說(shuō)下 脫離了ca簽發(fā)的證書(shū)的應(yīng)用：

自簽名證書(shū)：

證書(shū)如果沒(méi)有權(quán)威機(jī)構(gòu)的簽名，就是沒(méi)有權(quán)威機(jī)構(gòu)給你簽發(fā)身份證。 那么這時(shí)候身份認(rèn)證的場(chǎng)景變了。

這時(shí)候的認(rèn)證場(chǎng)景就變成了，不再是某個(gè)官方權(quán)威說(shuō)了算，而是假設(shè)第一次碰到這個(gè)證書(shū)，會(huì)認(rèn)為，這個(gè)證書(shū)與之捆綁的實(shí)體之間是合法的并做記錄。如果當(dāng)這個(gè)實(shí)體下次捆綁了另一個(gè)證書(shū)，那么就是非法的。

這種情況常用于android中安裝和校驗(yàn)app的時(shí)候，會(huì)先假設(shè)第一次安裝的是合法的應(yīng)用，認(rèn)定這個(gè)app證書(shū)中的公鑰是合法的公鑰。然后通過(guò)自簽名的證書(shū)，校驗(yàn)簽名，就能實(shí)現(xiàn)后續(xù)安裝是否合法以及完整性。

android中的如何對(duì)app進(jìn)行身份認(rèn)定和不被篡改：

android系統(tǒng)在安裝app時(shí)候會(huì)進(jìn)行校驗(yàn)applicationId，applicationId 不同會(huì)認(rèn)定為不同應(yīng)用。相同應(yīng)用，第二次安裝會(huì)校驗(yàn)證書(shū)是否和之前app的證書(shū)相同，如果相同則兩個(gè)包很可能來(lái)自同一個(gè)身份。 如果證書(shū)不同，也就是該包被另一個(gè)身份用自己的私鑰重新簽名過(guò)，就會(huì)拒絕安裝。 然后通過(guò)公鑰來(lái)解密簽名，如果能解密，說(shuō)明身份是ok的。否則拒絕安裝。比對(duì)解密簽名后的hash 與apk包內(nèi)的cert.sf文件(該文件是apk內(nèi)所有文件生成的hash文件)是否一致，如果相同則認(rèn)定為沒(méi)有被篡改。

android在提交應(yīng)用商店的問(wèn)題：

應(yīng)用商店也會(huì)校驗(yàn) 后續(xù)的上傳和第一次上傳時(shí)的證書(shū)，以及類(lèi)似上述的后續(xù)的一系列校驗(yàn)。防止合法的開(kāi)發(fā)者平臺(tái)被盜后，上傳非法應(yīng)用。

android在接入第三方sdk的問(wèn)題：

接入第三方sdk 會(huì)提交applicationId 和 sha1 值。 這個(gè)sha1值就是對(duì) 證書(shū)原文的簽名后的sha1，也就是證書(shū)指紋。這個(gè)證書(shū)是證書(shū)庫(kù)里最初的那個(gè)證書(shū)（x509格式），而不是對(duì)apk簽名后生成的證書(shū)(PKCS#7)。一般的證書(shū)簽名的主體是證書(shū)原文本身，而對(duì)apk簽名還額外會(huì)對(duì)apk所有文件生成的hash值文件（cert.sf）進(jìn)行一次簽名。

第三方平臺(tái)會(huì)記錄 applicationId 與sha1 的對(duì)應(yīng)關(guān)系。 當(dāng)有假冒app試圖接入時(shí)候，由于會(huì)對(duì)app內(nèi)的PKCS#7證書(shū)轉(zhuǎn)換為原始的x509格式證書(shū)，重新生成sha1值，與用戶提交sha1 比對(duì)， 如果相同則說(shuō)明證書(shū)很可能是ok的。 因?yàn)閟ha1就是證書(shū)的指紋。 之后就會(huì)通過(guò)證書(shū)中的公鑰來(lái)校驗(yàn)簽名，從而最終確認(rèn)身份合法性以及信息完整性。

第三方平臺(tái)之所以需要用戶去提交證書(shū)指紋sha1值，多了這一步，就意味著你的證書(shū)是可以更換的，一旦更換了證書(shū)，就必須提交新的指紋給我，然后我來(lái)做匹配。而應(yīng)用商店沒(méi)有這個(gè)功能， 一旦你的證書(shū)的私鑰丟了， 那就必須重新建一個(gè)新的app。

總結(jié)來(lái)看證書(shū)的身份認(rèn)定機(jī)制：

在ssl協(xié)議下，這種場(chǎng)景是 瀏覽器用于認(rèn)定合法的服務(wù)器身份。 在自簽名證書(shū)下，需要用戶選擇是否信任該證書(shū)。

在android app采用自簽名證書(shū)的場(chǎng)景下， 證書(shū)起到了 假設(shè)第一次的證書(shū)合法，公鑰合法，后續(xù)如果證書(shū)不一致或不能夠完成簽名校驗(yàn)，就是非法。

證書(shū)庫(kù)：

證書(shū)庫(kù)應(yīng)該滿足PKCS#12協(xié)議。 但是jdk提供了制作證書(shū)的工具keytool 可以生成keystore類(lèi)型的證書(shū)庫(kù)，后綴為jks。 keystore pk12可以通過(guò)keytool命令互相轉(zhuǎn)換。

證書(shū)庫(kù)是個(gè)證書(shū)的容器， 可以用來(lái)創(chuàng)建數(shù)字證書(shū)。 在keystore證書(shū)庫(kù)中，所有的數(shù)字證書(shū)是以一條一條(采用別名alias區(qū)別)的形式存入證書(shū)庫(kù)的。證書(shū)庫(kù)中的證書(shū)格式為pk12，即包含私鑰。 如果導(dǎo)出證書(shū)的話， 可以導(dǎo)出為x509不包含私鑰的格式 或者pk12包含私鑰的證書(shū)。 也可以也可以用-import參數(shù)加一個(gè)證書(shū)或證書(shū)鏈到信任證書(shū)。

android中一般都采用讀取證書(shū)庫(kù)的方式，通過(guò)證書(shū)庫(kù)來(lái)創(chuàng)建一個(gè)證書(shū)，通過(guò)alias來(lái)區(qū)分。 所以在簽名的時(shí)候，一個(gè)alias是一個(gè)證書(shū)，不同的alias是不同的證書(shū)，不要搞錯(cuò)了。

幾個(gè)關(guān)系：

證書(shū)和非對(duì)稱(chēng)加密算法的關(guān)系：

證書(shū)代表一個(gè)身份的主體，包含了非對(duì)稱(chēng)秘鑰體系中的公鑰，以及用私鑰對(duì)證書(shū)簽名。這種組織結(jié)構(gòu)，把非對(duì)稱(chēng)加密算法從加密的功能，拓寬到了用于身份認(rèn)證，信息完整性上。這體現(xiàn)在了證書(shū)的作用。 本質(zhì)還是利用了非對(duì)稱(chēng)加密算法的特性。

ssl協(xié)議和證書(shū)的關(guān)系。

因?yàn)樽C書(shū)解決了客戶端對(duì)服務(wù)器的身份認(rèn)證（自簽名證書(shū)除外），同時(shí)也解決了加密，和信息完整性，所以ssl協(xié)議基于證書(shū)來(lái)實(shí)現(xiàn)。

android ssl證書(shū) 放到哪里

ssl證書(shū)是放在服務(wù)器的，有身份驗(yàn)證和數(shù)據(jù)傳輸加密的作用，建議安裝。數(shù)安時(shí)代可以提供受信任的ssl證書(shū)，免費(fèi)付費(fèi)的都有~

android下的SSL證書(shū)信任問(wèn)題怎么解決

1、創(chuàng)建MySSLSocketFactory?對(duì)象 ：Throw Excetion

CertificateFactory cf = CertificateFactory.getInstance("X.509");

InputStream inStream = context.getAssets().open("信用證書(shū)");

Certificate ca;

try {

ca = cf.generateCertificate(inStream);

} finally {

inStream.close();

}

KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());

keyStore.load(null, null);

keyStore.setCertificateEntry("ca", ca);

MySSLSocketFactory sslFactory = new MySSLSocketFactory(keyStore)

2、將?MySSLSocketFactory傳入 http通信 ， 這里以 HttpAsyncTask 作為http通信框架：

AsyncHttpClient client = new?AsyncHttpClient();

client.setSSLSocketFactory(sslFactory);

client.get(urlString, params, new AsyncHttpResponseHandler() {

// TODO: 2017/1/5 ?

}

新聞名稱(chēng)：androidssl,androidsslhandshake 手機(jī)時(shí)間
本文網(wǎng)址：http://www.chinadenli.net/article36/dsdsssg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動(dòng)態(tài)網(wǎng)站、網(wǎng)站設(shè)計(jì)、小程序開(kāi)發(fā)、商城網(wǎng)站、服務(wù)器托管、電子商務(wù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)