重庆分公司
重庆分公司，新征程启航
为企业提供网站建设、域名注册、服务器等服务
高级表单验证－针对多次提交表单(转)
每个开发人员面对的困难是预测用户能够或是将要做什么--这对于网络开发人员来说就更为困 难，因为他的预测必须考虑到Web
的多样性和缺乏真正的session控制机制。如果你已经创建过一个使用表单的ASP应用程序，也许你已经遇到过一些奇怪的问题，如数据传输两次，接收数据不完整，或者用户报告表单显示不正确。尽管你也插入了确认数据所需的所有客户机端和服务器端的脚本，表单仍然会发生许多异常情况。这些异常情况与意外用户行为或浏览器书签的误使用有关。本文将集中解决一些容易引起表单问题的典型情况：用户意外地重复发送数据，在多步骤表单中直接使用中间表单。
数据复制
通过表单重复发送数据是一个常见的情况，但是它会带来问题。在理想的情况下，用户在一个 Web 站点遇到一个表单，用正确的数据类型填充它，将它提交给处理数据的服务器，然后作为回应发送给用户一个确认页，这时用户就可以再去做别的。如果用户重新访问前面那一页，使用back 按钮，然后无意中再将数据发送一次，那将会出现什么情形呢？如果你没有预料到这一场景并且有所准备，数据就将被重新传送给服务器并且再处理一次。试想这些数据是一份订单或旅馆预约，那将会带来很不愉快的结果。
终止重复数据传输
为了避免那些错误地重复发送给服务器的数据，可以在服务器侧进行一些校验，来确定用户能 意识到他们正在发送数据。这里使用的例子包含一个有单一文本框的简单表单，表单接收一些文本，然后将其发送到一个显示它们的ASP页。 为确保用户不将同样的信息发送两次，需要指示数据已经被服务器接收到。存储这些信息的最好的地方是一个session变量。定义一个session变量Session("submitted") ，当用户第一次到达这个表单时将它初始化为False,在用户进行最初的数据传输时将它设置为true 。如果用户在当前的session期间重新访问这个表单，将出现相关重复提交信息。
所以用户只能是在有意的情况下向服务器重复发送数据。现在来看看执行这一校验的代码。建立表单并且校验已发送数据的ASP页（在下载处为form.asp）有以下结构：
〈 HTML 〉
〈 HEAD 〉
〈 /HEAD 〉
〈 BODY 〉
〈 ％ If Session("submitted") Then ％ 〉
〈 !-- Code showing the warning message -- 〉
... 〈 ％ Else ％ 〉
〈 !-- Code showing the form -- 〉
... 〈 ％ End If ％ 〉
〈 /BODY 〉
〈 /HTML 〉
表单和警告信息都是从同一个ASP页创建的。表单包括标准的HTML代码，引用ManageForm.asp页作为它的ACTION 属性：
〈 FORM METHOD="post" ACTION="ManageForm.asp" 〉
Send me some data:
〈 INPUT TYPE="text" NAME="data" 〉
〈 P 〉
〈 INPUT TYPE="submit" VALUE="Submit" 〉
〈 INPUT TYPE="reset" VALUE="Cancel" 〉
〈 /FORM 〉
ManageForm.asp 页接收用户发送的文本，显示它并将session 变量submitted设置为True:
〈 HTML 〉
〈 HEAD 〉
〈 /HEAD 〉
〈 BODY 〉
You have sent the following information:
〈 P 〉
〈 ％= Request("data") ％ 〉
〈 ％ Session("submitted") = True ％ 〉
〈 /BODY 〉
〈 /HTML 〉
所以当用户又回到这个表单时，测试session 变量submitted，当它的值为True时，发送给用 户的是警告信息而不是输入表单。这个警告信息是用HTML和客户机侧的Javascript代码组合编写的：
〈 script 〉
function SendAnswer(answer) { document.AnswerForm.answer.value = answer document.AnswerForm.submit() }
〈 /script 〉
You have already submitted some information to this Web site.
〈 BR 〉 Do you want submit again?
〈 P 〉
〈 FORM NAME="AnswerForm" METHOD="post" ACTION="CheckAnswer.asp" 〉
〈 INPUT TYPE="button" VALUE="Yes" onClick="SendAnswer(＇Y＇)" 〉
〈 INPUT TYPE="button" VALUE="No" onClick="SendAnswer(＇N＇)" 〉
〈 INPUT TYPE="hidden" NAME="answer" VALUE="" 〉
〈 /FORM 〉
表单包含两个按钮（(Yes 和 No) 以及一个隐含控制域(answer) ，在其中保存用户所选择的值： Y 或 N。这个值由Javascript 函数SendAnswer() 设置，这个函数还将它发送给CheckAnswer.asp 页以执行正确的重定向。如果用户选择了No按钮，CheckAnswer.asp 检验隐含控制的值，并将其重定向到一个普通 welcome 页，反之就将session 变量submitted设置为False 并再次将其重定向到表单页。
〈 ％ If Request("answer") = "Y" Then Session("submitted") = False Response.Redirect "form.asp" Else Response.Redirect "welcome.htm" End If ％ 〉
控制浏览器缓冲器
如果你已经实施了以上方法，你会发现，只有当你在浏览器的地址文本框内键入URL来回到这个 表单时，此方法才奏效。它依靠的是浏览器的缓冲器机制。如果你使用back按钮来返回页，浏览器就检测它的缓冲器来找到该页的副本。它将使用缓存的页而不是向服务器发出请求。所以服务器就 不能在session 变量submitted上进行校验。为了避免这种情况，就要抑制浏览器的页缓冲器。这通过在表单页中处理Response对象来实现。取消页缓冲器有多种方法。所有这些方法都要依靠HTTP头文件中到浏览器的地址指示。但是所有浏览器对服务器发送的指示反应不同，所以说最好能多发送一些指示来为更多的浏览器抑制缓冲器，按以下代码所示：
〈 ％ Response.AddHeader "cache-control", "private" Response.AddHeader "pragma", "no-cache" Response.ExpiresAbsolute = #January 1, 1990 00:00:01# Response.Expires=0 ％ 〉
以上代码的头两行使用Response 对象的AddHeader 方法来将头信息附加到HTTP头文件中。 Expires 和 ExpiresAbsolute 属性用浏览器缓冲器中页的持续时间信息来标记当前页。在表单页中，这些行必须要插入在所有代码之前，因为她们所引用的信息放置在HTTP头文件中，在所有输出之前发送给浏览器。
多步骤表单
如果一个表单需要许多数据，那么最好将你要求的数据划分成多个小表单，这样使用户可以一步一步地填充表单，而不用等待表单加载许多HTML控制。另外还有一些情况，表单中的某些控制不完全必要，并且可以用已经提交的数据逐行填充。使用多步骤表单允许显示倚赖于用户以前答案的定制表单。如果用户在浏览器中将一个中间表单设置为书签的话就会产生问题。在随后的一个session中，用户就试图直接到达这个表单并提交数据，这些数据已经在上下文范围之外，因为本来应该在前面 表单收集的session 数据丢失了。
避免使用中间步骤表单
为了避免这些问题，可以存储当前数据收集的状态。这个状态可以用一个session 变量来代表 来记录是否执行了一个特定的步骤---用户是否填充了给出的表单。在一个多步骤表单中，每个表单都可以通过一个Boolean型的session变量来实现。如果有关表单没有被处理，变量就为False ，反之就是True。下载部分的第二个例子显示一个两步骤表单：第一个表单要求用户名，第二个表单显示一个组合框，它的列表项要依赖第一个表单所提供的用户名。第一个表单与一个session变量requested1相关联，你可以想象出来，第二个表单与变量requested2相关联。当用户要求第一个表单(form1.asp) 时，session变量 requested1 被设置为 True :
〈 FORM METHOD="post" ACTION="form2.asp" 〉
Your name: 〈 INPUT TYPE="text" NAME="name" 〉
〈 P 〉
〈 INPUT TYPE="submit" VALUE="Submit" 〉
〈 INPUT TYPE="reset" VALUE="Cancel" 〉
〈 /FORM 〉
〈 ％ Session("requested1") = True ％ 〉
这个值将由下一个表单( form2.asp ) 来校验，以确定是否满足了要求。事实上当用户要求第二个表单时校验requested1 变量。如果为True，就向浏览器发送第二个表单并将requested2变量设置为True。如果为False 就意味着用户想要直接使用第二个表单，于是浏览器就重定向到第一个表单。以下代码是第二个表单的ASP页：
〈 ％ If Session("requested1") Then ％ 〉
〈 HTML 〉
〈 HEAD 〉
〈 /HEAD 〉
〈 BODY 〉
〈 !-- Code for the second form -- 〉
... 〈 ％ Session("requested2") = True Else Response.Redirect "form1.asp" End If ％ 〉
〈 /BODY 〉
〈 /HTML 〉
要注意对requested1 的校验必须要在〈 HTML 〉记录之前进行，这样就允许可能的重定向。实际上，重定向是对浏览器的指示，它出现在HTTP头文件中，在所有的HTML代码之前。
结论
本文所示范的两种技巧允许ASP开发人员对某些奇怪的情况有所控制，这些奇怪情况会造成用户 通过一个Web 表单向服务器重复发送数据。每个技巧解决一个特定问题，所以最好将两者混合使用，在ASP应用程序每个表单中管理两个session 变量。[@more@]
网站名称：高级表单验证－针对多次提交表单(转)
转载源于：http://cqcxhl.cn/article/gpejoe.html
数据复制
通过表单重复发送数据是一个常见的情况，但是它会带来问题。在理想的情况下，用户在一个 Web 站点遇到一个表单，用正确的数据类型填充它，将它提交给处理数据的服务器，然后作为回应发送给用户一个确认页，这时用户就可以再去做别的。如果用户重新访问前面那一页，使用back 按钮，然后无意中再将数据发送一次，那将会出现什么情形呢？如果你没有预料到这一场景并且有所准备，数据就将被重新传送给服务器并且再处理一次。试想这些数据是一份订单或旅馆预约，那将会带来很不愉快的结果。
终止重复数据传输
为了避免那些错误地重复发送给服务器的数据，可以在服务器侧进行一些校验，来确定用户能 意识到他们正在发送数据。这里使用的例子包含一个有单一文本框的简单表单，表单接收一些文本，然后将其发送到一个显示它们的ASP页。 为确保用户不将同样的信息发送两次，需要指示数据已经被服务器接收到。存储这些信息的最好的地方是一个session变量。定义一个session变量Session("submitted") ，当用户第一次到达这个表单时将它初始化为False,在用户进行最初的数据传输时将它设置为true 。如果用户在当前的session期间重新访问这个表单，将出现相关重复提交信息。
所以用户只能是在有意的情况下向服务器重复发送数据。现在来看看执行这一校验的代码。建立表单并且校验已发送数据的ASP页（在下载处为form.asp）有以下结构：
〈 HTML 〉
〈 HEAD 〉
〈 /HEAD 〉
〈 BODY 〉
〈 ％ If Session("submitted") Then ％ 〉
〈 !-- Code showing the warning message -- 〉
... 〈 ％ Else ％ 〉
〈 !-- Code showing the form -- 〉
... 〈 ％ End If ％ 〉
〈 /BODY 〉
〈 /HTML 〉
表单和警告信息都是从同一个ASP页创建的。表单包括标准的HTML代码，引用ManageForm.asp页作为它的ACTION 属性：
〈 FORM METHOD="post" ACTION="ManageForm.asp" 〉
Send me some data:
〈 INPUT TYPE="text" NAME="data" 〉
〈 P 〉
〈 INPUT TYPE="submit" VALUE="Submit" 〉
〈 INPUT TYPE="reset" VALUE="Cancel" 〉
〈 /FORM 〉
ManageForm.asp 页接收用户发送的文本，显示它并将session 变量submitted设置为True:
〈 HTML 〉
〈 HEAD 〉
〈 /HEAD 〉
〈 BODY 〉
You have sent the following information:
〈 P 〉
〈 ％= Request("data") ％ 〉
〈 ％ Session("submitted") = True ％ 〉
〈 /BODY 〉
〈 /HTML 〉
所以当用户又回到这个表单时，测试session 变量submitted，当它的值为True时，发送给用 户的是警告信息而不是输入表单。这个警告信息是用HTML和客户机侧的Javascript代码组合编写的：
〈 script 〉
function SendAnswer(answer) { document.AnswerForm.answer.value = answer document.AnswerForm.submit() }
〈 /script 〉
You have already submitted some information to this Web site.
〈 BR 〉 Do you want submit again?
〈 P 〉
〈 FORM NAME="AnswerForm" METHOD="post" ACTION="CheckAnswer.asp" 〉
〈 INPUT TYPE="button" VALUE="Yes" onClick="SendAnswer(＇Y＇)" 〉
〈 INPUT TYPE="button" VALUE="No" onClick="SendAnswer(＇N＇)" 〉
〈 INPUT TYPE="hidden" NAME="answer" VALUE="" 〉
〈 /FORM 〉
表单包含两个按钮（(Yes 和 No) 以及一个隐含控制域(answer) ，在其中保存用户所选择的值： Y 或 N。这个值由Javascript 函数SendAnswer() 设置，这个函数还将它发送给CheckAnswer.asp 页以执行正确的重定向。如果用户选择了No按钮，CheckAnswer.asp 检验隐含控制的值，并将其重定向到一个普通 welcome 页，反之就将session 变量submitted设置为False 并再次将其重定向到表单页。
〈 ％ If Request("answer") = "Y" Then Session("submitted") = False Response.Redirect "form.asp" Else Response.Redirect "welcome.htm" End If ％ 〉
控制浏览器缓冲器
如果你已经实施了以上方法，你会发现，只有当你在浏览器的地址文本框内键入URL来回到这个 表单时，此方法才奏效。它依靠的是浏览器的缓冲器机制。如果你使用back按钮来返回页，浏览器就检测它的缓冲器来找到该页的副本。它将使用缓存的页而不是向服务器发出请求。所以服务器就 不能在session 变量submitted上进行校验。为了避免这种情况，就要抑制浏览器的页缓冲器。这通过在表单页中处理Response对象来实现。取消页缓冲器有多种方法。所有这些方法都要依靠HTTP头文件中到浏览器的地址指示。但是所有浏览器对服务器发送的指示反应不同，所以说最好能多发送一些指示来为更多的浏览器抑制缓冲器，按以下代码所示：
〈 ％ Response.AddHeader "cache-control", "private" Response.AddHeader "pragma", "no-cache" Response.ExpiresAbsolute = #January 1, 1990 00:00:01# Response.Expires=0 ％ 〉
以上代码的头两行使用Response 对象的AddHeader 方法来将头信息附加到HTTP头文件中。 Expires 和 ExpiresAbsolute 属性用浏览器缓冲器中页的持续时间信息来标记当前页。在表单页中，这些行必须要插入在所有代码之前，因为她们所引用的信息放置在HTTP头文件中，在所有输出之前发送给浏览器。
多步骤表单
如果一个表单需要许多数据，那么最好将你要求的数据划分成多个小表单，这样使用户可以一步一步地填充表单，而不用等待表单加载许多HTML控制。另外还有一些情况，表单中的某些控制不完全必要，并且可以用已经提交的数据逐行填充。使用多步骤表单允许显示倚赖于用户以前答案的定制表单。如果用户在浏览器中将一个中间表单设置为书签的话就会产生问题。在随后的一个session中，用户就试图直接到达这个表单并提交数据，这些数据已经在上下文范围之外，因为本来应该在前面 表单收集的session 数据丢失了。
避免使用中间步骤表单
为了避免这些问题，可以存储当前数据收集的状态。这个状态可以用一个session 变量来代表 来记录是否执行了一个特定的步骤---用户是否填充了给出的表单。在一个多步骤表单中，每个表单都可以通过一个Boolean型的session变量来实现。如果有关表单没有被处理，变量就为False ，反之就是True。下载部分的第二个例子显示一个两步骤表单：第一个表单要求用户名，第二个表单显示一个组合框，它的列表项要依赖第一个表单所提供的用户名。第一个表单与一个session变量requested1相关联，你可以想象出来，第二个表单与变量requested2相关联。当用户要求第一个表单(form1.asp) 时，session变量 requested1 被设置为 True :
〈 FORM METHOD="post" ACTION="form2.asp" 〉
Your name: 〈 INPUT TYPE="text" NAME="name" 〉
〈 P 〉
〈 INPUT TYPE="submit" VALUE="Submit" 〉
〈 INPUT TYPE="reset" VALUE="Cancel" 〉
〈 /FORM 〉
〈 ％ Session("requested1") = True ％ 〉
这个值将由下一个表单( form2.asp ) 来校验，以确定是否满足了要求。事实上当用户要求第二个表单时校验requested1 变量。如果为True，就向浏览器发送第二个表单并将requested2变量设置为True。如果为False 就意味着用户想要直接使用第二个表单，于是浏览器就重定向到第一个表单。以下代码是第二个表单的ASP页：
〈 ％ If Session("requested1") Then ％ 〉
〈 HTML 〉
〈 HEAD 〉
〈 /HEAD 〉
〈 BODY 〉
〈 !-- Code for the second form -- 〉
... 〈 ％ Session("requested2") = True Else Response.Redirect "form1.asp" End If ％ 〉
〈 /BODY 〉
〈 /HTML 〉
要注意对requested1 的校验必须要在〈 HTML 〉记录之前进行，这样就允许可能的重定向。实际上，重定向是对浏览器的指示，它出现在HTTP头文件中，在所有的HTML代码之前。
结论
本文所示范的两种技巧允许ASP开发人员对某些奇怪的情况有所控制，这些奇怪情况会造成用户 通过一个Web 表单向服务器重复发送数据。每个技巧解决一个特定问题，所以最好将两者混合使用，在ASP应用程序每个表单中管理两个session 变量。[@more@]
网站名称：高级表单验证－针对多次提交表单(转)
转载源于：http://cqcxhl.cn/article/gpejoe.html