微信技術(shù)實操（11）：公眾賬號接收非文字消息

　　用戶都是用使用文字在進行交互的，但是有時候使用圖片、語音、視頻以及地理位置等可以實現(xiàn)一些非常棒的功能，比如“語音提醒”公眾號里的發(fā)送語音就可以實現(xiàn)定時的事件提醒功能;比如ZTalk曾經(jīng)搞過微信拍照曬電腦桌面的活動(響應(yīng)的人太少，桑心……);比如一些預(yù)定本地化服務(wù)的公眾號里發(fā)送當(dāng)前地理位置就可以查詢周邊商家。

　　要實現(xiàn)這些功能首先得學(xué)會接收這些消息類型，比文字消息類型肯定要復(fù)雜很多了，目前我們能夠接收的消息類型只有圖片、地理位置以及退訂消息，其他的如鏈接消息、語音消息是需要官方授權(quán)的。接收到用戶消息以后回復(fù)的消息類型可以參考第11章，目前也就那三種。

　　一、圖片消息接收

　　相信拍照是目前智能手機用戶用得最多的功能沒有之一，在微信里也是一樣，看看每天朋友圈里分享的那些照片就知道了，那么如何接收和保存用戶照片捏，首先我們得了解用戶發(fā)送的圖片消息結(jié)構(gòu)，如下圖：

　　

 

 

　　大家可以看到圖片消息除了固定的消息發(fā)送用戶ID、接收公眾號ID、生成時間等固定字段外，多了一個圖片鏈接PicUrl，這個就是用戶向公眾賬號發(fā)送圖片后，保存到微信的服務(wù)器上返回給公眾號的鏈接，該圖片鏈接格式如下：

　　

 

 

　　也就是說我們?nèi)绻褕D片保存到本地服務(wù)器，就要先將圖片從微信服務(wù)器上抓取下來，當(dāng)然你也可以直接保存這個鏈接以后直接訪問，這個看具體應(yīng)用了。今天要講的是圖片保存到本地服務(wù)器上，請看下面代碼：

　　

 

 

　　由于圖片消息是另一種消息類型，因此代碼添加位置可以位于文字消息上面或者下面，只要別在文字消息的判斷語句內(nèi)就行。然后我來解釋下每個語句的作用：

　　第20行，判斷消息類型是否為圖片消息，條件為$form_MsgType==image;

　　第24行，獲取圖片消息數(shù)據(jù)中的圖片鏈接并賦值給$from_PicUrl;

　　第26行，生成要保存到本地服務(wù)器的圖片名稱，為了避免重復(fù)新圖片命名使用了發(fā)送用戶的OPENID+當(dāng)前時間戳，文件的后綴名我是直接設(shè)定為jpg文件。(由于從圖片鏈接上無法獲取到圖片后綴名，又懶得通過頭文件獲取圖片格式，就直接固定死了JPG格式，貌似沒有什么問題，哈哈哈);

　　第28行，SAE上的內(nèi)置接口類很多，SaeFetchurl是一個用來抓取遠程網(wǎng)頁的類，使用這個類就可以很方便的實現(xiàn)抓取其他網(wǎng)站的內(nèi)容，否則使用PHP的curl或者file_get_contents這些估計還得解釋半天，這句代碼是新建一個抓取類的對象。

　　第30行，執(zhí)行抓取圖片鏈接，其中抓取的函數(shù)是fetch()，圖片鏈接是之前賦值的$from_PicUrl，抓取后的結(jié)果賦值給$res;

　　第32行，判斷抓取結(jié)果，errno()返回的是抓取結(jié)束后的錯誤代碼，如果為0則成功，其他的就是不成功。

　　第35行，圖片抓取成功后，新建一個Storage的對象，我們要保存圖片了。

　　第37行，這句代碼其實已經(jīng)在以前出現(xiàn)多次，這次將抓取的內(nèi)容($res)寫入指定的文件($filename),并保存到Storage里，請注意把“weixincourse”替換成自己創(chuàng)建的Storage空間名。

　　第39行到41行，保存成功后給用戶提示圖片上傳成功。

　　第45行到48行，文件沒有抓取到提示用戶圖片上傳失敗。

　　當(dāng)然我們?nèi)绻麌乐斠稽c，還要判斷圖片文件是否保存成功，可以把第37行后面改寫一下，如下圖：

　　

 

 

　　大家可以嘗試把Storage的空間名字故意寫錯，看看會有什么樣的提示。如果提示上傳成功，我們到SAE的Storage列表里就應(yīng)該可以看到剛上傳的文件了。

　　

 

 

　　二、地理位置消息接收

　　手機上基于地理位置的APP很多，是個應(yīng)用現(xiàn)在都得跟LBS扯上點關(guān)系，SoLoMo里重要的一環(huán)就是地理位置，微信里也有很多應(yīng)用是跟地理位置相關(guān)的，比如查個本地天氣、附近酒店餐館啥的。今天舉的例子是查本地天氣。先了解下地理位置消息的結(jié)構(gòu)，如下圖：

　　

 

 

　　地理位置消息多了四項，分別是經(jīng)緯度的X和Y坐標、地圖縮放比例以及地址信息，而實際上由于網(wǎng)絡(luò)原因我們經(jīng)常是收不到地址信息的，只有坐標信息，因此地理位置的開發(fā)基本圍繞著坐標來。先來看本地天氣查詢代碼吧，如下圖：

　　

 

 

　　代碼添加位置同圖片消息，另起一個消息類型判斷語句，可以放在圖片消息前面或者后面。前面說了我們主要使用的是經(jīng)緯度，經(jīng)緯度是可以通過一些地圖api接口來獲取實際地址、周邊商家等信息的，天氣代碼這里我用的是百度地圖API接口，主要是因為它有URL接口，代碼解釋開始：

　　第21行，消息類型判斷語句，消息類型為location;

　　第24行到27行，將用戶推送地理消息的經(jīng)緯度、地圖比例、地址信息分別賦值。經(jīng)緯度分別為Location_X和Location_Y，相當(dāng)于用經(jīng)線和緯線的交叉點來標注地理位置。Scale是用戶發(fā)送地理位置時地圖的縮放比例。Label是地址信息(經(jīng)常是獲取不到的，獲取了也沒啥用，因為都是連在一起的，無法提取地市縣信息)。

　　第29行，定義百度地圖API接口的反向地址解析URL，反向地址解析是指通過經(jīng)緯度獲取當(dāng)前位置的地址信息。

　　第31行，由于各家地圖不一樣因此傳輸過來的經(jīng)緯度也會有所偏差，這里我選的是wgs84即手機GPS的坐標。

　　第33行，又要抓頁面了，先建個抓取類的對象。

　　第35行，百度地圖API接口的反向地址解析規(guī)則是URL+坐標類型+坐標值，其中$map_api_url.$map_coord_type兩個變量拼接就是URL+坐標類型，然后再加上經(jīng)緯度參數(shù)，用location=經(jīng)度,緯度來賦值。

　　這里說下URL的規(guī)則，URL就是大家?？吹降木W(wǎng)頁鏈接，一般由HTTP://后面加網(wǎng)址加參數(shù)組成，主要說下參數(shù)，參數(shù)一般是“參數(shù)名=賦值”組成，普通的URL參數(shù)格式是跟在網(wǎng)址后面第一個參數(shù)前用“?”號分隔，第二個參數(shù)開始用“&”分隔，參數(shù)在程序里是可以獲取到的，我們上面獲取坐標解析的實際地址形式為：

　　

 

 

　　接收的實際地址為http://api.map.baidu.com/geocoder，獲取到的參數(shù)是coord_type和location，值為相應(yīng)后面跟著的。

　　第37行，判斷是否抓取成功，如果抓取成功$geocoder的數(shù)據(jù)實際是如下格式：

　　

 

 

　　這里一大堆信息里只需要提取城市，即CITY這個標簽內(nèi)的數(shù)據(jù)。

　　第40行，這是一個正則表達式，比較復(fù)雜，作用就是根據(jù)規(guī)則將$geocoder里的北京市數(shù)據(jù)提取出來賦予$city這個變量，如果成功這個數(shù)據(jù)是會是一個多維數(shù)組，其中city標簽內(nèi)的數(shù)據(jù)即北京市是存儲在$city[1][0]里的，$city[0][0]的值是“北京市”;

　　第41行，將$city[1][0]的值即“北京市”提取出來，同時使用str_replace函數(shù)將“市”替換掉再重新賦值給$city，str_replace按照字面意思就是字符串替換，用法是：str_replace(要替換的內(nèi)容,替換成的內(nèi)容,字符串);其中替換的內(nèi)容和替換成的內(nèi)容可以使用數(shù)組，也可以使用單個字符串，我這里是用了數(shù)組，即將市縣區(qū)都替換成了空，替換的用處是因為后面查天氣預(yù)報的接口只支持城市名稱，不能有市縣區(qū)啥的……經(jīng)過這一步$city的值就是“北京”;

　　第43行，定義天氣API接口的URL;

　　第45行，做了三件事，第一個使用iconv()函數(shù)將$city的字符編碼從UTF-8轉(zhuǎn)換成GBK，第二件是使用urlencode將漢字轉(zhuǎn)換成英文編碼方便URL傳值，第三件是將URL中的“&city=”的參數(shù)名拼接了。

　　關(guān)于字符，有時候我們上網(wǎng)的時候會發(fā)現(xiàn)網(wǎng)頁有亂碼，大部分是因為字符編碼不對造成的，可以調(diào)節(jié)瀏覽器的編碼來切換，在程序里也是一樣，由于新浪接口接收的字符串是GBK的，而我們程序里使用UTF-8，所以需要轉(zhuǎn)碼后才能通訊，否則新浪接口收到的就是亂碼。

　　PS：GBK或者GB2312是中文簡體編碼，屬于ANSI編碼，但是同個ANSI編碼值在不同國家的編碼對應(yīng)是不同的文字，會非常混亂，所以有了Unicode以及UTF-8，這是國際通用的文字編碼格式，所有文字都被分配了不同的編碼，也就不怕亂碼了。

　　第46行，查詢天氣日期，0表示當(dāng)天，1表示明天，以此類推……

　　第49行，抓取天氣內(nèi)容并賦值給$weather，這里不需要再建立抓取類的對象了，因為之前已經(jīng)建立了可以直接用。

　　第51行，判斷是否抓到天氣，這里我多加了一個

　　

 

 

　　strstr函數(shù)是用來檢查$weather里是否存在“Weather”這個字符串，&&表示并且，這里的判斷就是不僅要抓取成功并且在抓取到的內(nèi)容里存在“Weather”。這樣寫的目的是因為新浪天氣接口不管有沒有查詢到天氣都會返回數(shù)據(jù)，而判斷數(shù)據(jù)里是否有天氣信息，只有判斷返回內(nèi)容里有木有“Weather”這個字符串。成功抓取到的會是如下內(nèi)容：

　　

 

 

　　這又是一個XML，然后用的是一些拼音首字母做了標簽，把這個回復(fù)給用戶估計會瘋的，我們要進行一些整理，方法嘛就是用正則表達式來提取我們需要的內(nèi)容，我這里提取的標簽是city(城市)、status2-status1(天氣變化)、temperature2-temperature1(溫度變化)、direction2-power2(風(fēng)向風(fēng)力)、chy_shuoming(穿著建議)、savedate_weather(信息發(fā)布時間)

　　第54行到62行就是提取這些數(shù)據(jù)的正則表達式，可以發(fā)現(xiàn)其實改動的只是標簽名和賦值的參數(shù)，如果大家還想加寫數(shù)據(jù)的可以參照著提取;

　　第64行到71行判斷天氣變化是否相同，比如上面顯示的天氣1和天氣2其實都是陰，如果不做判斷就會返回給用戶“陰轉(zhuǎn)陰”，非常2，所以這里判斷如果兩個天氣是一致的則將任意一個天氣賦值給$w_status變量，否則就按照天氣2轉(zhuǎn)天氣1賦值給$w_status變量，最后輸出時用$w_status這個變量。

　　第73行到81行新建一個數(shù)組，將前面獲取到的天氣數(shù)據(jù)添加為數(shù)組元素，格式就是$weather_res=array();然后在括號里用逗號分割每個天氣數(shù)據(jù)，最后一個后面不要加逗號，這樣做的好處是避免代碼行過長，而且很清晰。

　　第82行，將數(shù)組用implode()函數(shù)轉(zhuǎn)化成數(shù)組，用””這個換行符來分割。

　　其實73到82行完成的就是將所有數(shù)據(jù)拼接成一個字符串，使用“.”一個個拼也可以，不過效率低下而且代碼也不夠清晰。

　　全部拼接完成就可以輸出了，在手機上效果如下：

　　

 

 

　　后面的就不詳細說了，都有標注，都是些判斷提示語句，大家可以自己學(xué)著看，不懂的可以直接在后臺問。另外強調(diào)一點，一般天氣預(yù)報是拿中國天氣網(wǎng)接口做的會比這個更好，能夠顯示縣區(qū)級的天氣，但是需要搞個城市代碼表，留到以后說吧，新浪的接口可以直接用城市名查就先演示下。

　　三、退訂消息接收

　　不知道還有多少人記得我曾寫過一篇《那些離開的朋友們》，是因為微信把退訂消息接口開了，每天看到不少人退訂心里有點小難過寫的，到今天我看了下差不多有2000個退訂用戶了，估計是我現(xiàn)在寫的東西不合他們胃口。

　　退訂消息接口的代碼很簡單，跟用戶訂閱一樣是一個事件類型的消息，只是事件類型的標示是”unsubscribe“，退訂用戶最好是配合數(shù)據(jù)庫來記錄，我這里給大家的是一個保存成文件的例子，如下圖：

　　

 

 

　　代碼添加的位置請看仔細了，在事件消息判斷里的獲取事件類型之后。代碼很短，解釋如下：

　　第300行，判斷事件類型標示是否為”unsubscribe“，大家可以看下訂閱消息是”subscribe“;

　　第303行，新建一個Storage的對象;

　　第305行，寫入文件，文件名為退訂用戶的OPENID，文件后綴是.txt，內(nèi)容我用了退訂時間。

　　當(dāng)用戶退訂后在Storage的存儲空間里就會有一個文件生成。