㈠ 前端get請求url拼接多項參數方法
var toString = "";
for (var key in data) {
if(!data[key]){
delete data.key
}else{
var obj = data[key];
if (Array.isArray(obj)) {
var arrayString = obj.join(",");
toString += key + "=" + arrayString + "&";
} else {
廳禪燃 扮虛 toString += key + "=" + data[key] + "&";
}
襲碰 }
}
toString.substring(0, toString.length - 1).replace(/$/, "");
㈡ 前端是vue,後台用的python。前台get請求url中有中文,後台看到鏈接地址變成了亂碼
傳遞之前先把漢字跟標點符號之類轉成urlcode
js代碼
encodeURIComponent("哈哈哈哈哈");
輸出"%E5%93%88%E5%93%88%E5%93%88%E5%93%88%E5%93%88"
py代碼使用urllib將urlcode編碼解碼
from urllib import parse
get = "%E5%93%88%E5%93%88%E5%93%88%E5%93%88%E5%93%88"
print(parse.unquote(get))
輸出"哈哈哈哈哈"
㈢ SpringMVC前後端分離交互傳參詳細教程-
溫故而知新,本文為一時興起寫出,如有錯誤還請指正
本文後台基於SpringBoot2.5.6編寫,前端基於Vue2 + axios和微信小程序JS版分別編寫進行聯調測試,用於理解前後端分離式開發的交互流程,如果沒用過axios可以點我看之前的帖子
如果你沒有學過SpringBoot也不要緊,把他看做成SpringMVC即可,寫法完全一致(其實我不說你也發現不了)
本文主要講前後端交互流程,力求幫助新人快速入門前後端分離式開發,不會講關於數胡環境搭建部分的內容
在文章開頭快速的過一遍SpringMVC接收參數的幾種方式,一定要記住這幾種方式,看不懂或不理解都沒關系,後續會結合前端代碼過一遍,這里就不過多解釋了,直接上代碼
細心的人應該留意到了,最後使用變數接收參數的時候只接收了 username 這一個值,並沒有接收 password ,作為擴展在這里解釋一下, 不看也可以,看了不理解也沒關系,知道這個事兒就夠了,以後接觸多了就理解了
如果請求參數放在了請求體中,只有參數列表第一個變數能接收到值,這里需要站在Servlet的角度來看:
可以看到請求體內容是存到了 InputStream 輸入流對象中,想要知道請求體中的內容是什麼必須讀流中的數據,讀取到數據後會將值給第一個變數,而流中的數據讀取一次之後就沒了,當第二個變數讀流時發現流已經被關閉了,自然就接收不到
SpringMVC回顧到此為止,只需要記住那三種方式即可,在前後端交互之前先在Controller中寫個測試介面
這個介面對應的是GET類型的請求,這里直接在瀏覽器地址欄訪問測試一下:
這里推薦一個Chrome瀏覽器的插件 JSONView ,它可以對瀏覽器顯示的JSON數據進行格式化顯示,推薦的同時也提個醒,安裝需謹慎,如果JSON數據量太大的話頁面會很卡
之前已經寫好一個GET請求的測試介面了,這里就在前端寫代碼訪問一下試試看
代碼已經寫完了,接下來打開頁面試一下能不能調通:州凳
可以看到請求代碼報錯了,查看報錯信息找到重點關鍵詞 CORS ,表示該請求屬於 跨域請求
什麼是跨域請求?跨域請求主要體現在跨域兩個字上,當發起請求的客戶端和接收請求的服務端他們的【協議、域名、埠號】有任意一項不一致的情況都屬於跨域請求,拿剛剛訪問的地址舉例,VUE頁面運行在9000埠上,後台介面運行在8080埠上,埠號沒有對上所以該請求為跨域請求
如果在調試的時候仔細一點就會發現,雖然前端提示請求報錯了,但是後端還是接收到請求了,那為什麼會報錯呢?是因為後端返回數據後,瀏覽器接收到響應結果發現該請求跨域,然後給我們提示錯誤信息,也就是說問題在瀏覽器這里
怎樣才能讓瀏覽器允許該請求呢?我們需要在後端動點手腳,在返回結果的時候設置允許前端訪問即可
首先配置一個過濾器,配置過濾器有很多種實現的方法,我這里是實現Filter介面
過濾器創建完成了,回來看前端提示的報錯信息為 Access-Control-Allow-Origin ,意思是允許訪問的地址中並不包含當前VUE的地址,那麼我們就在響應結果時將VUE的地址追加上
添加完成後重啟項目後台就會發現請求已經成功並且拿到了返回值
再次冊畢旅進行測試,將後台的GetMapping修改為PostMapping,修改前端請求代碼後重新發起請求進行測試
可以看到POST請求還是提示跨域請求,對應的錯誤信息則是 Access-Control-Allow-Headers ,也就是說請求頭中包含了不被允許的信息,這里圖省事兒用 * 通配符把所有請求頭都放行
這樣處理之後,請求就可以正常訪問啦
路徑佔位參數,就是將參數作為請求路徑的一部分,例如你現在正在看的這篇博客使用的就是路徑佔位傳參
這種傳參方法很簡單,就不細講了,可以效仿他這種方法寫個測試案例
這里需要注意區分【路徑佔位傳參】和【路徑傳參】兩個概念,不要記混
什麼是路徑傳參?發起一個請求 http://localhost:8080/index?a=1&b=2 ,在路徑 ? 後面的都屬於路徑傳參,路徑傳參就是將參數以明文方式拼接在請求地址後面
路徑傳參使用【正常接收參數】中的實例代碼即可接收到值
除了自己手動拼接請求參數之外,axios在config中提供了params屬性,也可以實現該功能
表單類型參數,就是通過form表單提交的參數,通常用在例如HTML、JSP頁面的form標簽上,但如果是前後端分離的話就不能使用form表單提交了,這里可以手動創建表單對象進行傳值
需要注意,GET請求一般只用於路徑傳參,其他類型傳參需要使用POST或其他類型的請求
表單類型參數也是【正常接收參數】中的實例代碼接收值
小程序刪除了FormData對象,不能發起表單類型參數的請求,如果非要寫的話可以試著使用 wx.uploadFile 實現,這里就不嘗試了
請求體傳參,是在發起請求時將參數放在請求體中
表單類型參數需要使用上面【請求體接收參數】中的實例代碼接收值
axios如果發起的為POST類型請求,默認會將參數放在請求體中,這里直接寫即可
小程序代碼也是一樣的,當發起的時POST類型的請求時,默認會把參數放在請求體中
在實際開發中大概率不用寫前端代碼,只負責編寫後台介面,但怎樣才能知道前端請求是什麼類型參數?
關於這點可以通過瀏覽器開發者工具的【網路】面板可以看出來,網路面板打開時會錄制網頁發起的所有請求
路徑佔位傳參就不解釋了,沒啥好說的,這里介紹一下路徑傳參、表單傳參和請求體傳參
編寫好路徑傳參的請求代碼後切換到網路面板,點擊發起請求:
編寫好請求體傳參的請求代碼後切換到網路面板,點擊發起請求:
編寫好表單類型傳參的請求代碼後切換到網路面板,點擊發起請求:
掌握了前後端交互的流程就可以正常開發網站了,這里推薦後端返回一套規定好的模板數據,否則某些情況可能會比較難處理,例如這個查詢用戶列表的介面:
該介面乍一看沒毛病,拿到用戶列表數據後返回給前端用於渲染,合情合理,可是如果後端業務邏輯有BUG可能會導致前端接收到的結果為空,這種情況下前端就需要判斷,如果接收到的值為空,就提示請求出錯,問題貌似已經解決,但是如果表中本來就沒有任何數據的話有應該怎麼處理
上述的就是最常見的一種比較頭疼的情況,所以針對這種情況最好指定一套標準的返回模板進行處理
根據剛剛的舉例來看,返回結果中應該有一個標識來判斷該請求是否執行成功,如果執行失敗的話還應該返回失敗原因,響應給前端的數據會被轉換為JSON數據,使用Map集合來返回最合適不過了
在後台介面編寫完成後,一般情況下我們都需要進行測試,GET請求還好,瀏覽器直接就訪問呢了,如果是POST請求還要去寫前端代碼就很煩,這里介紹一款介面調試工具ApiPost
你可能沒聽過ApiPost,但是你大概率聽說過Postman,他們的用法幾乎一致,且ApiPost是國人開發的免費的介面調試工具,界面中文很友好
這里也可以看出來,form表單傳參其實也算在了請求體裡面,只不過使用的是 multipart/form-data 類型的參數而已,而之前提到的請求體傳參對應的就是 application/json
㈣ vue-resource 怎麼解決跨域問題
上一篇我們介紹了如何使用vue resource處理請求,結合服務端的REST API,就能夠很容易地構建一個增刪查改應用。
這個應用始終遺留了一個問題,Web App在訪問REST API時,沒有經過任何認證,這使得服務端的REST API是不安全的,只要有人知道api地址,就可以調用API對服務端的資源進行修改和刪除。
今天我們就來探討一下如何結合Web API來限制資源的訪問。
本文的主要內容如下:
介紹傳統的Web應用和基於REST服務的Web應用
介紹OAuth認證流程和密碼模式
創建一個基於ASP. Identity的Web API應用程序
基於$.ajax實現OAuth的注冊、登錄、注銷和API調用
基於vue-resource實現OAuth的注冊、登錄、注銷和API調用
本文的最終示例是結合上一篇的CURD,本文的登錄、注冊、注銷和API調用功能實現的。
35
本文9個示例的源碼已放到GitHub,如果您覺得本篇內容不錯,請點個贊,或在GitHub上加個星星!
Page Demo GitHub Source
基於$.ajax的示例如下:
注冊示例 登錄和注銷示例 登錄獲取token並調用API示例 注冊、登錄、注銷、調用API綜合示例
基於vue-resource的示例如下:
注冊示例 登錄和注銷示例 登錄獲取token並調用API示例 注冊、登錄、注銷、調用API綜合示例
OAuth介紹
傳統的Web應用
在傳統的Web應用程序中,前後端是放在一個站點下的,我們可以通過會話(Session)來保存用戶的信息。
例如:一個簡單的ASP. MVC應用程序,用戶登錄成功後,我們將用戶的ID記錄在Session中,假設為Session["UserID"]。
前端發送ajax請求時,如果這個請求要求已登錄的用戶才能訪問,我們只需在後台Controller中驗證Session["UserID"]是否為空,就可以判斷用戶是否已經登錄了。
這也是傳統的Web應用能夠逃避面向無連接的方法。
基於REST服務的Web應用
當今很多應用,客戶端和服務端是分離的,服務端是基於REST風格構建的一套Service,客戶端是第三方的Web應用,客戶端通過跨域的ajax請求獲取REST服務的資源。
然而REST Service通常是被設計為無狀態的(Stateless),這意味著我們不能依賴於Session來保存用戶信息,也不能使用Session["UserID"]這種方式確定用戶身份。
解決這個問題的方法是什麼呢?常規的方法是使用OAuth 2.0。
對於用戶相關的OpenAPI,為了保護用戶數據的安全和隱私,第三方Web應用訪問用戶數據前都需要顯式的向用戶徵求授權。
相比於OAuth 1.0,OAuth 2.0的認證流程更加簡單。
專用名詞介紹
在了解OAuth 2.0之前,我們先了解幾個名詞:
Resource:資源,和REST中的資源概念一致,有些資源是訪問受保護的
Resource Server:存放資源的伺服器
Resource Owner:資源所有者,本文中又稱為用戶(user)
User Agent:用戶代理,即瀏覽器
Client: 訪問資源的客戶端,也就是應用程序
Authorization Server:認證伺服器,用於給Client提供訪問令牌的伺服器
Access Token:訪問資源的令牌,由Authorization Server器授予,Client訪問Resource時,需提供Access Token
Bearer Token:Bearer Token是Access Token的一種,另一種是Mac Token。
Bearer Token的使用格式為:Bearer XXXXXXXX
Token的類型請參考:s://tools.ietf/html/draft-ietf-oauth-v2-15#section-7.1
有時候認證伺服器和資源伺服器可以是一台伺服器,本文中的Web API示例正是這種運用場景。
OAuth認證流程
在知道這幾個詞以後,我們用這幾個名詞來編個故事。
簡化版本
這個故事的簡化版本是:用戶(Resource Owner)訪問資源(Resource)。
image
具體版本
簡化版的故事只有一個結果,下面是這個故事的具體版本:
用戶通過瀏覽器打開客戶端後,客戶端要求用戶給予授權。
客戶端可以直接將授權請求發給用戶(如圖所示),或者發送給一個中間媒介,比如認證伺服器。
用戶同意給予客戶端授權,客戶端收到用戶的授權。
授權模式(Grant Type)取決於客戶端使用的模式,以及認證伺服器所支持的模式。
客戶端提供身份信息,然後向認證伺服器發送請求,申請訪問令牌
認證伺服器驗證客戶端提供的身份信息,如果驗證通過,則向客戶端發放令牌
客戶端使用訪問令牌,向資源伺服器請求受保護的資源
資源伺服器驗證訪問令牌,如果有效,則向客戶端開放資源
image
以上幾個步驟,(B)是較為關鍵的一個,即用戶怎麼樣才能給客戶端授權。有了這個授權以後,客戶端就可以獲取令牌,進而通過臨牌獲取資源。這也是OAuth 2.0的運行流程,詳情請參考:s://tools.ietf/html/draft-ietf-oauth-v2-15#section-1.2
客戶端的授權模式
客戶端必須得到用戶的授權(authorization grant),才能獲得令牌(access token)。
OAuth 2.0定義了四種授權方式:
授權碼模式(authorization code)
簡化模式(implicit)
密碼模式(resource owner password credentials)
客戶端模式(client credentials)
本文的示例是基於密碼模式的,我就只簡單介紹這種模式,其他3我就不介紹了,大家有興趣可以看阮大的文章:
://http://www.yingtaow.com/sitemap.html?blog/2014/05/oauth_2_0.html
密碼模式
密碼模式(Resource Owner Password Credentials Grant)中,用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息,向服務端申請授權。
在這種模式中,用戶必須把自己的密碼給客戶端,但是客戶端不得儲存密碼。這通常用在用戶對客戶端高度信任的情況下,比如客戶端是操作系統的一部分,或者由一個著名公司出品。
image
密碼嘛事的執行步驟如下:
(A)用戶向客戶端提供用戶名和密碼。
(B)客戶端將用戶名和密碼發給認證伺服器,向後者請求令牌。
(C)認證伺服器確認無誤後,向客戶端提供訪問令牌。
(B)步驟中,客戶端發出的請求,包含以下參數:
grant_type:表示授權類型,此處的值固定為"password",必選項。
username:表示用戶名,必選項。
password:表示用戶的密碼,必選項。
scope:表示許可權范圍,可選項。
注意:在後面的客戶端示例中,除了提供username和password,grant_type也是必須指定為"password",否則無法獲取服務端的授權。
服務端環境准備
如果您是前端開發人員,並且未接觸過ASP. Web API,可以跳過此段落。
image
Authentication選擇Indivial User Accounts
image
創建這個Web API工程時,VS會自動引入Owin和Asp.Identity相關的庫。
image
修改ValuesController,除了IEnumerable<string> Get()操作外,其他操作都刪除,並為該操作應用[Authorize]特性,這表示客戶端必須通過身份驗證後才能調用該操作。
public class ValuesController : ApiController
{
// GET: api/Values
[Authorize]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
}
添加Model, Controller
image
image
image
初始化資料庫
image
執行以下3個命令
image
image
執行以下SQL語句:
顯示代碼
CustomersController類有5個Action,除了2個GET請求外,其他3個請求分別是POST, PUT和DELETE。
為這3個請求添加[Authorize]特性,這3個請求必須通過身份驗證才能訪問。
隱藏代碼
public class CustomersController : ApiController
{
private ApplicationDbContext db = new ApplicationDbContext();
// GET: api/Customers
public IQueryable<Customer> GetCustomers()
{
return db.Customers;
}
// GET: api/Customers/5
[ResponseType(typeof(Customer))]
public async Task<IActionResult> GetCustomer(int id)
{
Customer customer = await db.Customers.FindAsync(id);
if (customer == null)
{
return NotFound();
}
return Ok(customer);
}
// PUT: api/Customers/5
[Authorize]
[ResponseType(typeof(void))]
public async Task<IActionResult> PutCustomer(int id, Customer customer)
{
// ...
}
// POST: api/Customers
[Authorize]
[ResponseType(typeof(Customer))]
public async Task<IActionResult> PostCustomer(Customer customer)
{
// ...
}
// DELETE: api/Customers/5
[ResponseType(typeof(Customer))]
[Authorize]
public async Task<IActionResult> DeleteCustomer(int id)
{
// ...
}
}
讓Web API以CamelCase輸出JSON
在Global.asax文件中添加以下幾行代碼:
var formatters = GlobalConfiguration.Configuration.Formatters;
var jsonFormatter = formatters.JsonFormatter;
var settings = jsonFormatter.SerializerSettings;
settings.Formatting = Formatting.Indented;
settings.ContractResolver = new ();
啟用CORS
在Nuget Package Manager Console輸入以下命令:
Install-Package Microsoft.Asp.WebApi.Cors
在WebApiConfig中啟用CORS:
public static class WebApiConfig
{
public static void Register(Configuration config)
{
var cors = new EnableCorsAttribute("*", "*", "*");
config.EnableCors(cors);
// ...
}
}
類說明
在執行上述步驟時,VS已經幫我們生成好了一些類
image
IdentityModels.cs:包含ApplicationDbContext類和ApplicationUser類,無需再創建DbContext類
public class ApplicationUser : IdentityUser
{
// ...
}
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
// ...
}
Startup.Auth.cs:用於配置OAuth的一些屬性。
public partial class Startup
{
public static OAuthOptions { get; private set; }
public static string PublicClientId { get; private set; }
// For more information on configuring authentication, please visit ://go.microsoft./fwlink/?LinkId=301864
public void ConfigureAuth(IAppBuilder app)
{
// ..
// Configure the application for OAuth based flow
PublicClientId = "self";
OAuthOptions = new
{
TokenEndpointPath = new PathString("/Token"),
Provider = new ApplicationOAuthProvider(PublicClientId),
AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(14),
// In proction mode set AllowInsecure = false
AllowInsecure = true
};
// Enable the application to use bearer tokens to authenticate users
app.UseOAuthBearerTokens(OAuthOptions);
// ..
}
}
這些OAuth配置項,我們只用關注其中的兩項:
TokenEndpointPath:表示客戶端發送驗證請求的地址,例如:Web API的站點為www.example.,驗證請求的地址則為www.example./token。
UseOAuthBearerTokens:使用Bearer類型的token_type(令牌類型)。
ApplicationOAuthProvider.cs:默認的OAuthProvider實現,GrantResourceOwnerCredentials方法用於驗證用戶身份信息,並返回access_token(訪問令牌)。
public override async Task GrantResourceOwnerCredentials( context)
{
// ...
}
通俗地講,客戶端輸入用戶名、密碼,點擊登錄後,會發起請求到www.example./token。
token這個請求在服務端執行的驗證方法是什麼呢?正是GrantResourceOwnerCredentials方法。
客戶端發起驗證請求時,必然是跨域的,token這個請求不屬於任何ApiController的Action,而在WebApiConfig.cs中啟用全局的CORS,只對ApiController有效,對token請求是不起作用的。
所以還需要在GrantResourceOwnerCredentials方法中添加一行代碼:
public override async Task GrantResourceOwnerCredentials( context)
{
context.Response.Headers.Add("Access-Control-Allow-Origin", new []{"*"});
// ...
}
IdentityConfig.cs:配置用戶名和密碼的復雜度,主要用於用戶注冊時。例如:不允許用戶名為純字母和數字的組合,密碼長度至少為6位…。
隱藏代碼
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));
// Configure validation logic for usernames
manager.UserValidator = new UserValidator<ApplicationUser>(manager)
{
= false,
RequireUniqueEmail = true
};
// Configure validation logic for passwords
manager.PasswordValidator = new PasswordValidator
{
RequiredLength = 6,
RequireNonLetterOrDigit = true,
RequireDigit = true,
RequireLowercase = true,
RequireUppercase = true,
};
// ...
return manager;
}
使用Postman測試GET和POST請求
測試GET請求
image
GET請求測試成功,可以獲取到JSON數據。
測試POST請求
image
POST請求測試不通過,提示:驗證不通過,請求被拒絕。
基於$.ajax實現注冊、登錄、注銷和API調用
服務端的環境已經准備好了,現在我們就逐個實現用戶注冊、登錄,以及API調用功能吧。
注冊
頁面的HTML代碼如下:
<div id="app">
<div class="container">
<span id="message">{{ msg }}</span>
</div>
<div class="container">
<div class="form-group">
<label>電子郵箱</label>
<input type="text" v-model="registerModel.email" />
</div>
<div class="form-group">
<label>密碼</label>
<input type="text" v-model="registerModel.password" />
</div>
<div class="form-group">
<label>確認密碼</label>
<input type="text" v-model="registerModel.confirmPassword" />
</div>
<div class="form-group">
<label></label>
<button @click="register">注冊</button>
</div>
</div>
</div>
創建Vue實例,然後基於$.ajax發送用戶注冊請求:
var demo = new Vue({
el: '#app',
data: {
registerUrl: '://localhost:10648/api/Account/Register',
registerModel: {
email: '',
password: '',
confirmPassword: ''
},
msg: ''
},
methods: {
register: function() {
var vm = this
vm.msg = ''
$.ajax({
url: vm.registerUrl,
type: 'POST',
dataType: 'json',
data: vm.registerModel,
success: function() {
vm.msg = '注冊成功!'
},
error: vm.requestError
})
},
requestError: function(xhr, errorType, error) {
㈤ 前端面試get和post區別是什麼ajax跨域如何解決
GET和POST的核心區別就是:
GET通過URL傳輸數據,位於HTTP請求頭中
POST通過HTTP請求體傳遞數據
Ajax跨域幾種方法:
CORS跨域
postMessage跨域
document.domain同主域,不同子域之間跨域
iframe的hash跨域
window.name跨域
JSONP跨域
後端代理跨域
其中1、2、3、6是最常用的,一定要說
㈥ 前端腳本發起get請求,後端將數據放到 js 回調里,前端接受響應後執行回調拿到數據,就是jsonp的原理嗎
jsonp的原理
<script src="http://xxxx/xxx?callback=fnName ">
script中的src具有天然的跨域特性,以src發送的請求的返回值默認會以js語法解析,只要將需要執行的函數名以url里get請求 ?callback=fnName 接在路徑後
然後後端將數據放在回調中返回,前端響應執行回調
最主要要講到 script 中 src 帶有的天然跨域性
㈦ 前端必備HTTP技能之請求頭響應頭格式以及請求方法簡述
http協議中,客戶端和服務端通過發送純文本(ASCII)消息的方式進行通信,客戶端發送請求(requests)到服務端,服務端發送響應(responses)到客戶端。
請求消息格式
例子:
響應消息格式
例子:
為了標識特定資源需要特定的行為訪問,HTTP協議定義了多種請求方法。這種特定資源是什麼樣的,是已有的數據,還有動態生成的?主要依賴於服務端實現。通常來說這種資源對應一個文件或者屬於服務端的一個可執行輸出。
HTTP/1.0規范定義三種請求方法:GET, POST, HEAD。HTTP/1.1規范又增加了五種:OPTIONS, PUT, DELETE, TRACE,CONNECT。
在規范中定義的這些請求方法是語義化的,並且是可依賴的。任何客戶端都可以使用任何請求方法,服務端也可以配置成支持任何這些請求方法的組合。
實際上這些請求方法可以隨意定義,沒有數量限制,不過你自己定義出來的請求方法會被認為是不安全並且是非冪等的。
總結 :這些請求方法本質上沒有區別,最終都是TCP請求,唯一的區別就是每個請求方法,使用的時候,規范規定的使用格式不同,原則上必須按照規范規定的格式使用,其實也可以違反規范使用,比如你可以使用GET方法請求數據,也可以使用GET方法提交數據,當然你可以用POST方法提交數據,也可以用POST方法獲取數據。
做好前端開發必須對HTTP的相關知識有所了解,所以我創建了一個專題 前端必備HTTP技能 專門收集前端相關的HTTP知識,歡迎關注,投稿。
㈧ 如何接受前端使用ajax發送get請求而傳遞過
你說的接收參數嗎 如果沒有使用框架那就直接用request.getparameter("key")
如果使用struts2或springmvc框架,可以這接在action中定義對應的key值,框架內部就解析了。