PHP 后臺接口返回小程序端的數(shù)據(jù)，在數(shù)據(jù)前面出現(xiàn)了亂碼情況，怎么解決

這種情況發(fā)生在以UTF-8編碼格式傳輸數(shù)據(jù)的時(shí)候，這開頭的三個(gè)字節(jié)叫做BOM（Byte Order Mark，字節(jié)順序標(biāo)記），小程序接收到php端返回的數(shù)據(jù)后，把開頭的三個(gè)字節(jié)去掉即可。

我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、濮陽縣ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的濮陽縣網(wǎng)站制作公司

更徹底的解決辦法是把php文件保存為?不帶BOM的UTF-8?文件，這樣返回的數(shù)據(jù)就不帶BOM了

php獲得api返回的json數(shù)據(jù)后，如何解析？

首先你需要使用對方約定方式獲取，然后考慮是否使用緩存，最后獲取到數(shù)據(jù)后使用json_decode函數(shù)解析成數(shù)組格式，接下來就是自己的邏輯代碼了。

php接口返回json，無法解析

file_get_contents 得到的字符，使用 json_decode 解析成json。

$xxx_json = json_decode($xxx_response);

PHP---APP接口02

JSONXML

XML: 是一種標(biāo)記語言，設(shè)計(jì)的宗旨是傳輸數(shù)據(jù)

JSON： 輕量級的數(shù)據(jù)交換格式

APP接口主要是用JSON輸出格式

APP接口輸出格式三要素：

1. code:：錯(cuò)誤碼

2. msg：錯(cuò)誤碼對應(yīng)的描述

3. data：接口返回的數(shù)據(jù)

誰有權(quán)限調(diào)用APP接口，客戶端需要帶著憑證來調(diào)用APP接口

JWT的原理：

服務(wù)端認(rèn)證之后，生成一個(gè)JSON對象，返回給用戶。后續(xù)客戶端所有請求都會(huì)帶上這個(gè)JSON對象。服務(wù)端依靠這個(gè)JSON對象來認(rèn)定用戶身份。

組成: Header, Payload, Signature

1. Header

說一下我是什么

header通常包含了兩部分：類型和加密算法

{

"alg": "HS256",

"typ": "JWT"

}

header需要經(jīng)過Base64Url編碼后作為IWT的第一部分。

2. Payload

payload包含了claim, 三種類型reserved, public, private

reserved這些claim是JWT預(yù)先定義的，不強(qiáng)制使用，常用的有：

1). iss: 簽發(fā)者

2). exp: 過期的時(shí)間戳

3). sub: 面向的用戶

4). aud: 接收方

5). iat: 簽發(fā)時(shí)間

{

"sub":? "1234567890",

"name":? "John Doe",

"admin": true

}

payload需要經(jīng)過Base64Url編碼后作為JWT的第二部分。

3. Signature

創(chuàng)建簽名使用編碼后的header和payload以及一個(gè)密匙，使用header中指定的簽名算法進(jìn)行簽名

HMACSHA256(

base64UrlEncode(header) + "." +

base64UrlEncode(payload),

secret

)

簽名是在服務(wù)端進(jìn)行的，客戶端并不知道，所以是安全的。

PHP 接口返回值帶

php 部署到 centos 里，出現(xiàn)返回值中間有個(gè)空字段。

在正常運(yùn)行環(huán)境中沒有發(fā)現(xiàn)，但當(dāng)我們與對方進(jìn)行接口壓力測試的時(shí)候，對方的環(huán)境用xml對json進(jìn)行了一次轉(zhuǎn)換，造成壓測出現(xiàn)不解析的狀況，對方反復(fù)測試，發(fā)現(xiàn)出現(xiàn)多余空格。

處理辦法：

1、centos命令處理

2、編碼處理，用Notepad++ 對php文件進(jìn)行一下格式轉(zhuǎn)換

不要到BOM,重新上傳