- changefreq:頁面內(nèi)容更新頻率。
- lastmod:頁面最后修改時間
- loc:頁面永久鏈接地址
- priority:相對于其他頁面的優(yōu)先權(quán)
- url:相對于前4個標簽的父標簽
- urlset:相對于前5個標簽的父標簽
- <urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
這一行定義了此xml文件的命名空間，相當于網(wǎng)頁文件中的<html>標簽一樣的作用。 <url> 這是具體某一個鏈接的定義入口，你所希望展示在SiteMap文件中的每一個鏈接都要用<url>和</url>包含在里面，這是必須的。<loc>http://duduwolf.winzheng.com</loc> 用<loc>描述出具體的鏈接地址，這里需要注意的是鏈接地址中的一些特殊字符必須轉(zhuǎn)換為XML(HTML)定義的轉(zhuǎn)義字符，如下表：字符 轉(zhuǎn)義后的字符 HTML字符 字符編碼 and(和) & & & 單引號 ' ' ' 雙引號 " " " 大于號 > > > 小于號 < < < <lastmod>2005-06-03T04:20:32-08:00</lastmod> <lastmod>是用來指定該鏈接的最后更新時間，這個很重要。Google的機器人會在索引此鏈接前先和上次索引記錄的最后更新時間進行比較，如果時間一樣就會跳過不再索引。所以如果你的鏈接內(nèi)容基于上次Google索引時的內(nèi)容有所改變，應(yīng)該更新該時間，讓Google下次索引時會重新對該鏈接內(nèi)容進行分析和提取關(guān)鍵字。這里必須用ISO 8601中指定的時間格式進行描述，格式化的時間格式如下：- 年：YYYY(2005)
- 年和月：YYYY-MM(2005-06)
- 年月日：YYYY-MM-DD(2005-06-04)
- 年月日小時分鐘：YYYY-MM-DDThh:mmTZD(2005-06-04T10:37+08:00)
- 年月日小時分鐘秒：YYYY-MM-DDThh:mmTZD(2005-06-04T10:37:30+08:00)
<changefreq>always</changefreq> 用這個標簽告訴Google此鏈接可能會出現(xiàn)的更新頻率，比如首頁肯定就要用always(經(jīng)常)，而對于很久前的鏈接或者不再更新內(nèi)容的鏈接就可以用yearly(每年)。這里可以用來描述的單詞共這幾個："always", "hourly", "daily", "weekly", "monthly", "yearly"，具體含義我就不用解釋了吧，光看單詞的意思就明白了。<priority>1.0</priority> <priority>是用來指定此鏈接相對于其他鏈接的優(yōu)先權(quán)比值，此值定于0.0 - 1.0之間- 還有</url>和</urlset>，這兩個就是來關(guān)閉xml標簽的，這和HTML中的</body>和</html>是一個道理
- 另外需要注意的是，這個xml文件必須是utf-8的編碼格式，不管你是手動生成還是通過代碼生成，建議最好檢查一下xml文件是否是utf-8編碼，最簡單的方法就是用記事本打開xml然后另存為時選擇編碼(或轉(zhuǎn)換器)為UTF-8。
web.xml <xwork> import com.opensymphony.xwork.ActionSupport; /**
<?xml version="1.0" encoding="GB18030"?>
<web-app version="2.4"
xmlns=" xmlns:xsi=" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
<filter>
<filter-name>webwork</filter-name>
<filter-class>com.opensymphony.webwork.dispatcher.FilterDispatcher</filter-class>
</filter>
<filter-mapping>
<filter-name>webwork</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
xwork.xml
<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN"
"
<include file="webwork-default.xml"></include>
<package name="default" extends="webwork-default">
<action name="helloWorld" class="cn.javaworker.yeming.action.HelloWorld">
<result name="success">index.jsp</result>
<result name="input">hello.jsp</result>
</action>
</package>
</xwork>
hello.jsp
<%@ taglib prefix="ww" uri="/webwork"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Enter you name</title>
</head>
<body>
<ww:form action="helloWorld">
<ww:textfield label="please enter user name" name="name"></ww:textfield>
<input type="submit"/>
</ww:form>
<form action="helloWorld.action">
please enter you name:<input type="text" name="name" value="<ww:property value="name"/>"/>
<input type="submit">
</form>
</body>
</html>
index.jsp
<%@ taglib prefix="ww" uri="/webwork"%>
<html>
<head>
<title>hello page</title>
</head>
<body>
The message generated by my first action is :<ww:property value="message"/>
</body>
</html>
HelloWorld.java
package cn.javaworker.yeming.action;
* @author $author
*/
@SuppressWarnings("serial")
public class HelloWorld extends ActionSupport{
private String message;
private String name;
/**
* @see com.opensymphony.xwork.Action#execute()
*/
public String execute() throws Exception
{
if(name==null||name.equals("")||name.equals("world")){
addFieldError("name","blank names or names of 'world' are not allowed!");
return INPUT;
}
message ="hello "+name+"!\n";
message+="this is the time is: "+System.currentTimeMillis();
return SUCCESS;
}
/**
* @return the name
*/
public String getName() {
return name;
}
/**
* @param name the name to set
*/
public void setName(String name) {
this.name = name;
}
/**
* @return the message
*/
public String getMessage() {
return message;
}
}
屬于：java.util包。
１、構(gòu)造函數(shù)。
1. StringTokenizer(String str) ：構(gòu)造一個用來解析str的StringTokenizer對象。java默認的分隔符是“空格”、“制表符(‘\t’)”、“換行符(‘\n’)”、“回車符(‘\r’)”。
2. StringTokenizer(String str, String delim) ：構(gòu)造一個用來解析str的StringTokenizer對象，并提供一個指定的分隔符。
3. StringTokenizer(String str, String delim, boolean returnDelims) ：構(gòu)造一個用來解析str的StringTokenizer對象，并提供一個指定的分隔符，同時，指定是否返回分隔符。
２、方法。
說明：
1. 所有方法均為public；
2. 書寫格式：［修飾符］ <返回類型> <方法名（［參數(shù)列表］）>
如：
static int parseInt(String s) 表示：此方法（parseInt）為類方法（static），返回類型為（int），方法所需參數(shù)為String類型。
- 1. int countTokens() ：返回nextToken方法被調(diào)用的次數(shù)。如果采用構(gòu)造函數(shù)1和2，返回的就是分隔符數(shù)量(例2)。
2. boolean hasMoreTokens() ：返回是否還有分隔符。
3. boolean hasMoreElements() ：結(jié)果同2。
4. String nextToken() ：返回從當前位置到下一個分隔符的字符串。
5. Object nextElement() ：結(jié)果同4。
6. String nextToken(String delim) ：與4類似，以指定的分隔符返回結(jié)果。
例子：
String s = new String("The Java platform is the ideal platform for network computing");
StringTokenizer st = new StringTokenizer(s);
System.out.println( "Token Total: " + st.countTokens() );
while( st.hasMoreElements() ){
System.out.println( st.nextToken() );
}
結(jié)果為：
Token Total: 10
The
Java
platform
is
the
ideal
platform
for
network
computing
例2:
String s = new String("The=Java=platform=is=the=ideal=platform=for=network=computing");
StringTokenizer st = new StringTokenizer(s,"=",true);
System.out.println( "Token Total: " + st.countTokens() );
while( st.hasMoreElements() ){
System.out.println( st.nextToken() );
}
結(jié)果為：
Token Total: 19
The
=
Java
=
platform
=
is
=
the
=
ideal
=
platform
=
for
=
network
=
computing
描述：在實際應(yīng)用中，經(jīng)常回遇到對字符串進行動態(tài)修改。這時候，String類的功能受到限制，而StringBuffer類可以完成字符串的動態(tài)添加、插入和替換等操作。
１、構(gòu)造函數(shù)。
-
StringBuffer() ：構(gòu)造一個沒有任何字符的StringBuffer類。
StringBuffer(int length) ： ：構(gòu)造一個沒有任何字符的StringBuffer類，并且，其長度為length。
StringBuffer(String str) ：以str為初始值構(gòu)造一個StringBuffer類。
２、方法。
說明：
1. 所有方法均為public；
2. 書寫格式：［修飾符］ <返回類型> <方法名（［參數(shù)列表］）>
如：
static int parseInt(String s) 表示：此方法（parseInt）為類方法（static），返回類型為（int），方法所需參數(shù)為String類型。
-
1. StringBuffer append(boolean b)
2. StringBuffer append(char c)
3. StringBuffer append(char[] str)
4. StringBuffer append(char[] str, int offset, int len)
5. StringBuffer append(double d)
6. StringBuffer append(float f)
7. StringBuffer append(int i)
8. StringBuffer append(long l)
9. StringBuffer append(Object obj)
10. StringBuffer append(String str)
11. StringBuffer append(StringBuffer sb)
以上的方法都是向字符串緩沖區(qū)“追加”元素，但是，這個“元素”參數(shù)可以是布爾量、字符、字符數(shù)組、雙精度數(shù)、浮點數(shù)、整型數(shù)、長整型數(shù)對象類型的字符串、字符串和StringBuffer類等。如果添加的字符超出了字符串緩沖區(qū)的長度，Java將自動進行擴充。
String question = new String("1+1=");
int answer = 3;
boolean result = (1+1==3);
StringBuffer sb = new StringBuffer();
sb.append(question);
sb.append(answer);
sb.append('\t');
sb.append(result);
System.out.println(sb);
結(jié)果為：
1+1=3 false
- 12. int capacity() ：返回當前StringBuffer對象（字符串緩沖區(qū)）的總空間，而非字符號串的長度。
13. char charAt(int index) ：在當前StringBuffer對象中取索引號為index的字符。第一個字符的索引為“0”
14. StringBuffer delete(int start, int end) ：刪除當前StringBuffer對象中以索引號start開始，到end結(jié)束的子串。
15. StringBuffer deleteCharAt(int index) ：刪除當前StringBuffer對象中索引號為index的字符。
16. void ensureCapacity(int minimumCapacity) ：重新設(shè)置字符號串緩沖區(qū)的總空間。如果minimumCapacity大于當前的總空間，則新的空間被設(shè)置：一種結(jié)果是minimumCapacity；另一種結(jié)果是{“老空間”乘2加2}。
StringBuffer sb1 = new StringBuffer(5);
StringBuffer sb2 = new StringBuffer(5);
sb1.ensureCapacity(6);
sb2.ensureCapacity(100);
System.out.println( "sb1.Capacity: " + sb1.capacity() );
System.out.println( "sb2.Capacity: " + sb2.capacity() );
結(jié)果為：
sb1.Capacity: 12
sb2.Capacity: 100
- 17. void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) ：從當前StringBuffer對象的索引號srcBegin開始，到srcEnd結(jié)束的子串，賦值到字符數(shù)組dst中，并且從dst的索引號dstBegin開始。
StringBuffer sb = new StringBuffer("I love her!");
char[] i = {'I',' ','l','o','v','e',' ','y','o','u'};
sb.getChars(7,10,i,7);
System.out.println( "sb: " + sb );
結(jié)果為：sb: I love her!
- 18. int indexOf(String str) ：返回當前StringBuffer對象中，第一個滿足str子串的位置。
19. int indexOf(String str, int fromIndex) ：從當前StringBuffer對象的fromIndex開始查找，返回第一個滿足str子串的位置。
20. StringBuffer insert(int offset, boolean b)
21. StringBuffer insert(int offset, char c)
22. StringBuffer insert(int offset, char[] str)
23. StringBuffer insert(int index, char[] str, int offset, int len)
24. StringBuffer insert(int offset, double d)
25. StringBuffer insert(int offset, float f)
26. StringBuffer insert(int offset, int i)
27. StringBuffer insert(int offset, long l)
28. StringBuffer insert(int offset, Object obj)
29. StringBuffer insert(int offset, String str)
以上的方法都是在當前StringBuffer對象中插入一個元素，在索引號offset處插入相應(yīng)的值。
30. int lastIndexOf(String str) ：返回當前StringBuffer對象中，最后一個滿足str子串的位置。
31. int lastIndexOf(String str, int fromIndex) ：從當前StringBuffer對象的fromIndex開始查找，返回最后一個滿足str子串的位置。
32. int length() ：返回當前StringBuffer對象（字符緩沖區(qū)）中，字符串的長度。注意：此方法與capacity() 不同。
33. StringBuffer replace(int start, int end, String str) ：替換當前StringBuffer對象的字符串。從start開始，到end結(jié)束的位置替換成str。
34. StringBuffer reverse() ：將字符串翻轉(zhuǎn)。
StringBuffer sb = new StringBuffer("0123456789");
System.out.println( "sb.reverse(): " + sb.reverse() );
結(jié)果為：sb.reverse(): 9876543210
- 35. void setCharAt(int index, char ch) ：設(shè)置索引號index的字符為ch。
36. void setLength(int newLength) ：重新設(shè)置字符串緩沖區(qū)中字符串的長度，如果newLength小于當前的字符串長度，將截去多余的字符。
StringBuffer sb = new StringBuffer("0123456789");
sb.setLength(5);
System.out.println( "sb: " + sb );
結(jié)果為：sb: 01234
- 37. String substring(int start) ：取當前StringBuffer對象中，從start開始到結(jié)尾的子串。
38. String substring(int start, int end) ：取當前StringBuffer對象中，從start開始到end的子串。
39. String toString() ：將當前StringBuffer對象轉(zhuǎn)換成String對象。
# Attach appender A1 to root. Set root level to Level.DEBUG.
log4j.rootLogger=INFO, A1,A4
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.Threshold=ERROR
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%p [%t] %c{2} (%M:%L) - %m%n
log4j.appender.A4=org.apache.log4j.DailyRollingFileAppender
log4j.appender.A4.file=D:\\Java\\logs\\yeming.log
log4j.appender.A4.Encoding=GBK
log4j.appender.A4.DatePattern='.'yyyy-MM-dd
log4j.appender.A4.layout=org.apache.log4j.PatternLayout
log4j.appender.A4.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss} [%c]-[%p] %m%n
使用代碼：
package com.javawoker.yeming.jiemie.database;
import java.sql.Connection;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.sql.DataSource;
import org.apache.log4j.Logger;
/**
?*@author 葉明 ---guming123416@gmail.com
?*@version $Id: v 1.01 2006/06/38 16:09:14 teodord Exp $
?*/
public class Pubconn {
?
?/*
? * 創(chuàng)建私有變量conn為數(shù)據(jù)庫連接對象中Connection
? * 創(chuàng)建私有變量dsye為數(shù)據(jù)庫連接池的DataSource
? */
?
?private Connection conn;
?private DataSource dsye;
?private static Logger log=Logger.getLogger(Pubconn.class);
?/*
? * 創(chuàng)建構(gòu)造函數(shù)Pubconn，在建立class中加載數(shù)據(jù)源的InitialContext
? */
?public Pubconn()
?{
??try{
???Context initCtx=new InitialContext();
???if(initCtx==null)
???{
????throw new Exception("不能加載文件Context");
???}
???dsye=(javax.sql.DataSource)initCtx.lookup("jdbc/yeming");
??}catch(Exception ex)
??{
???ex.printStackTrace();
???log.error("在加栽數(shù)據(jù)庫連接池時間發(fā)生錯誤"+ex.getMessage());
??}
?}
?/*
? * 從連接池中取出一條連接變量
? *
? */
?public Connection getConn()
?{
??try{
???conn=dsye.getConnection();
??}catch(SQLException ex)
??{
???ex.printStackTrace();
???log.error("獲得連接對象CONN時間發(fā)生錯誤"+ex.getMessage());
??}
??return conn;
?}
?/*
? * 關(guān)閉數(shù)據(jù)庫連接，釋放資源
? */
?public void closeConn(Connection conn)
?{
??try{
???if(conn!=null)
???{
????conn.close();
????conn=null;
???}
??}catch(SQLException ex)
??{
???ex.printStackTrace();
???log.error("關(guān)閉CONN時間發(fā)生錯誤"+ex.getMessage());
??}
?}
}
<script language="javascript">
var checkSubmitFlg = false;
function checkSubmit() {
if (checkSubmitFlg == true) {
return false;
}
checkSubmitFlg = true;
return true;
}
document.ondblclick = function docondblclick() {
window.event.returnValue = false;
}
document.onclick = function doconclick() {
if (checkSubmitFlg) {
window.event.returnValue = false;
}
}
</script>
<html:form action="myAction.do" method="post" onsubmit="return checkSubmit();">
2 還是javascript，將提交按鈕或者image置為disable
<html:form action="myAction.do" method="post"
onsubmit="getElById('submitInput').disabled = true; return true;">
<html:image styleId="submitInput" src="images/ok_b.gif" border="0" />
</html:form>
3 利用struts的同步令牌機制
利用同步令牌（Token）機制來解決Web應(yīng)用中重復(fù)提交的問題，Struts也給出了一個參考實現(xiàn)。
基本原理：
服務(wù)器端在處理到達的請求之前，會將請求中包含的令牌值與保存在當前用戶會話中的令牌值進行比較，看是否匹配。在處理完該請求后，且在答復(fù)發(fā)送給客戶端之前，將會產(chǎn)生一個新的令牌，該令牌除傳給客戶端以外，也會將用戶會話中保存的舊的令牌進行替換。這樣如果用戶回退到剛才的提交頁面并再次提交的話，客戶端傳過來的令牌就和服務(wù)器端的令牌不一致，從而有效地防止了重復(fù)提交的發(fā)生。
if (isTokenValid(request, true)) {
// your code here
return mapping.findForward("success");
} else {
saveToken(request);
return mapping.findForward("submitagain");
}
Struts根據(jù)用戶會話ID和當前系統(tǒng)時間來生成一個唯一（對于每個會話）令牌的，具體實現(xiàn)可以參考TokenProcessor類中的generateToken()方法。
1. //驗證事務(wù)控制令牌,<html:form >會自動根據(jù)session中標識生成一個隱含input代表令牌，防止兩次提交
2. 在action中：
//<input type="hidden" name="org.apache.struts.taglib.html.TOKEN"
// value="6aa35341f25184fd996c4c918255c3ae">
if (!isTokenValid(request))
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("error.transaction.token"));
resetToken(request); //刪除session中的令牌
3. action有這樣的一個方法生成令牌
protected String generateToken(HttpServletRequest request) {
HttpSession session = request.getSession();
try {
byte id[] = session.getId().getBytes();
byte now[] =
new Long(System.currentTimeMillis()).toString().getBytes();
MessageDigest md = MessageDigest.getInstance("MD5");
md.update(id);
md.update(now);
return (toHex(md.digest()));
} catch (IllegalStateException e) {
return (null);
} catch (NoSuchAlgorithmException e) {
return (null);
}
}
- A new expression language (EL) syntax that allows deferred evaluation of expressions, enables using expressions to both get and set data and to invoke methods, and facilitates customizing the resolution of a variable or property referenced by an expression
- Support for resource injection through annotations to simplify configuring access to resources and environment data
- Complete alignment of JavaServer Faces technology tags and JavaServer Pages (JSP) software code
In this series of articles, web-tier proponents at Sun introduce the new concepts that every web-application developer should be familiar with to get the most out of the Java EE 5 web-tier technologies. This first article in the series gives an overview of the new features introduced in version 2.1 of JSP technology.
 |
Under the auspices of JSR 245 at the Java Community Process (JCP), the main focus of JSP 2.1 technology has been to provide a better alignment with the next release of JavaServer Faces technology, version 1.2.
The misalignment between the two technologies originated with the fact that version 1.0 of JavaServer Faces technology depended on JSP 1.2 technology. The reason is that the JSP 1.2 software was already widely available at the time, and the intention was to make the JavaServer Faces 1.0 interface more accessible to a broader audience. A consequence of this requirement was that JavaServer Faces technology could not take advantage of the EL introduced in the subsequent version of JSP technology, version 2.0. In addition, JSP 2.0 technology could not be modified to accommodate the needs of JavaServer Faces technology. And JSP 1.2 technology does not support an EL. Therefore, JavaServer Faces technology introduced an EL that was suited to its needs as a user interface (UI) component framework. As a result, page authors using JavaServer Faces technology tags with JSP technology code encountered some incompatibilities between the two technologies.
The expert groups have worked together on the upcoming releases of JSP 2.1 and JavaServer Faces 1.2 technologies in Java EE 5 to fix these integration issues and make sure that the two technologies work together seamlessly. One result is that all of the web-tier technologies now share a unified EL, allowing you to mix code from all of these technologies freely and without worry. This article provides an overview of the work that was done to improve the alignment of these technologies. It also explains the other minor improvements that made it into JSP 2.1 technology.
|
The simple EL included in JSP 2.0 technology offers many advantages to the page author. Using simple expressions, page authors can easily access external data objects from their pages. The JSP technology container evaluates and resolves these expressions as it encounters them. It then immediately returns a response because the JSP request-processing model has only one phase, the render phase. However, because the request-processing model does not support a postback, all JSP expressions are read-only.
Unlike JSP technology, JavaServer Faces technology supports a multiphase life cycle. When a user enters values into the JavaServer Faces UI components and submits the page, those values are converted, validated, and propagated to server-side data objects, after which component events are processed. In order to perform all these tasks in an orderly fashion, the JavaServer Faces life cycle is split into separate phases. Therefore, JavaServer Faces technology evaluates expressions at different phases of the life cycle rather than immediately, as JSP technology would do. Additionally, the expressions can be used to set as well as get data, so that the values a user enters into the UI components are propagated to server-side objects during a postback. Finally, some JavaServer Faces technology expressions can invoke methods on server-side objects during various stages of the life cycle in order to validate data and handle component events.
Each EL suited the needs of its respective technology very well. When using both JSP technology tags or template text and JavaServer Faces technology tags, however, page authors would expose incompatibilities between the ELs. One example involves using JavaServer Faces components inside the c:forEach tag, as in the following example:
<c:forEach var="location" items="${handler.locations}"> |
The problem with this code stems from the fact that the iteration variable location is visible only within the boundaries of its iteration tag. This means that on a postback, the JavaServer Faces request life cycle has no way to access the value associated with the variable location.
To solve problems such as these, the expert groups for JavaServer Faces and JSP technologies decided to unify the two ELs. They created a more powerful EL, the unified EL, that supports the following features:
- Deferred expressions, which can be evaluated at different stages of the page life cycle
- Expressions that can set data of external objects as well as get that data
- Method expressions, which can invoke methods that perform event handling, validation, and other functions for the JavaServer Faces technology UI components
- A flexible mechanism to enable customization of variable and property resolution for EL expression evaluation
With the addition of these features into a unified EL, the incompatibility problems such as that illustrated by the preceding c:forEach code example can be solved. Now, the iteration variable can be a deferred expression that refers to the proper object within the collection being iterated over -- for example, locations[0]. This way, the deferred expression can be evaluated later on during the JavaServer Faces request life cycle, as shown in the following code:
<c:forEach var="location" items="#{locations}"> |
For more details on changes made to the c:forEach tag and other JSTL tags, please see the upcoming article of this series, which will describe new features in JSTL. If you are a page author, make sure to read another upcoming article in the series, which describes the differences between the two EL syntaxes now supported in JSP technology. The article "Unified Expression Language (EL)" provides a much more detailed description. It also explains how to create a custom resolver, which is one of the new features of the unified EL.
It is also important to note that the EL is useful beyond all of the web technology specifications. This is why the EL is agnostic of the technology hosting it and is currently defined through its own independent document within the JSP specification. This makes it clear that the EL is not dependent on the JSP specification and might therefore have its own JSR in the future.
|
Prior to the Java EE 5 platform, accessing data sources, web services, environment entries, and Enterprise JavaBeans (EJB) bean references required the use of the Java Naming and Directory Interface (JNDI) API along with the declaration of entries into a deployment descriptor. Thanks to injection annotations, it is now possible to inject container-managed objects without having to write the traditional boilerplate code and deal with the deployment descriptor.
For example, a tag handler could access a database through the following code:
@Resource(name="jdbc/myDB") |
The field myDB of type javax.sql.DataSource is annotated with @Resource and is injected by the container prior to the tag handler being made available to the application. The data source JNDI mapping is inferred from the field name catalogDS and type javax.sql.DataSource. Moreover, the myDB resource no longer needs to be defined in the deployment descriptor. An upcoming article in this series will provide more detail on how to perform injection with web-tier applications.
TrimWhiteSpace |
A frequent complaint in user forums concerns the large number of blank lines, or white spaces, that often clutter the output of a JSP technology page. For example, consider this page:
<%@page contentType="text/html"%> |
Prior to JSP 2.1 technology, this page would produce the following output in the response (where ? represents the end of a blank line):
? |
Although these extra blank lines do not change the way a browser displays the output page, they do add extra payload to the response and make the HTML source code less legible. To solve this issue, JSP 2.1 technology now offers the configuration parameter trimDirectiveWhitespaces, which can be specified as a page directive or as a property-group configuration parameter that applies to a group of pages.
With trimDirectiveWhitespaces enabled, template text containing only blank lines, or white space, is removed from the response output. In the code example above, the lines containing only blank lines would be removed, yielding the following output:
<html> |
|
Maintaining compatibility with earlier versions is critical for any Java EE platform release. For JSP 2.1 technology, the only backward compatibility issue involves the EL's new support of the #{ syntax that refers to deferred expressions. The #{ character sequence can create backward compatibility problems in two situations: when the sequence is included in template text or in attribute values.
In JSP 2.1 technology, a deferred expression does not make sense in the context of template text because evaluation of an expression is always done immediately by the JSP container. Because no entity other than the JSP container processes template text, a deferred expression would always be left unevaluated if it were included in template text. Therefore, any page authors who have included the #{ character sequence in template text probably meant to use the ${} syntax instead. Acknowledging this fact, the JSP specification authors have mandated that the inclusion of #{ in template text triggers a translation error in JSP 2.1 technology.
With respect to tag attribute values, it is important to note that tag libraries based on JSP versions prior to 2.1 (such as the 1.1 version of the JavaServer Faces component tag library) made extensive use of the #{ syntax to specify deferred expressions. Because these tag libraries must be responsible for the parsing of these deferred expressions, they must execute in an environment in which the #{ character sequence is processed as a string literal.
To determine whether or not to treat the #{ character sequence as a string literal, the web container relies on the JSP version indicated by the tag library descriptor (TLD) associated with the tag library. The JSP version specified in the TLD tells the web container which version of the JSP specification the tag library is written for. JSP versions previous to 2.1 processed #{ as a string literal, as did applications based on those earlier versions. With version 2.1 or later, the character sequence #{ represents a deferred expression, assuming the attribute has been declared to support deferred expressions in the TLD. If the attribute does not support deferred expressions, then the presence of the #{ character sequence results in a translation error.
Web-application developers who have developed applications for a version prior to JSP 2.1 technology and want to deploy and run them on a JSP 2.1 container must take the following actions to ensure that the container handles any instances of the #{ character sequence correctly:
- Escape each instance of the
#{characters using a backslash:\#{.
- Globally allow usage of the
#{character sequence as a string literal by setting the JSP property groups elementdeferred-syntax-allowed-as-literaltotrueor by setting thepage/tag-filedirective attributedeferredSyntaxAllowedAsStringLiteraltotrue.
Aside from the incompatibilities relating to the #{ character sequence, all JSP 2.0 technology applications will run as is on JSP 2.1 containers. However, if a web application uses third-party tag libraries that are based on JavaServer Faces 1.1 technology or earlier, some new features provided by JSP 2.1 and JavaServer Faces 1.2 technologies will not be available with these libraries. For example, although EL functions may now be used in the JavaServer Faces 1.2 core and HTML tag libraries, they cannot be used with third-party tag libraries that are based on JavaServer Faces 1.1 technology and earlier, because these libraries run on a version of the JavaServer Faces EL that did not support EL functions.
Taglib Order of Precedence |
Now that JavaServer Faces technology and JSTL are part of the Java EE 5 platform, they take precedence over any other version of these libraries that could be bundled with a web application. Some people may ask: "But what if I want to replace the container's implementation of these technologies with another implementation?" This is no longer possible. This would be like replacing the implementation of the java.util package in the Java Platform, Standard Edition (Java SE, formerly referred to as J2SE), a fruitless task. The same applies from now on with platform tag libraries.
Essentially, applications should not replace the APIs that the Java EE 5 platform requires. If the platform architects really wanted to make this possible, they would have designed the APIs with service-provider interfaces to allow applications to easily swap in their own implementations. However, this was not their intention, and applications will always have to rely on the platform tag libraries bundled with a container.
|
Let's look at a few other minor additions and clarifications to the JSP 2.1 specification. For a detailed list of all changes between JSP 2.0 and JSP 2.1, please consult Appendix E of the specification. Most notable are the following:
- The JSP spec now supports Byte Order Marks (BOM) as authoritative page-encoding declarations for JSP technology pages and tag files in standard syntax.
- Because JSP 2.1 technology requires J2SE 5.0, some APIs that can take advantage of generics have been modified.
- And many more, as Appendix E points out.
在此之前，我想從網(wǎng)上找些資料。不過，關(guān)于IIS與Resin整合的文章很少，而有關(guān)IIS6.0整合的文章就更少了。到Resin的官方網(wǎng)站上，雖然是有關(guān)IIS與Resin整合的文章。不過是英文，而且版本很低，是Resin_2.1的。最后只有一點一點的摸索。后來又看到了Resin_3.0.8里面自帶的文檔中有一部分是關(guān)于IIS6.0與Resin_3.0.8整合的內(nèi)容。按照上面說的，終于將IIS6.0與Resin_3.0.8整合好了。Resin的官方文擋寫的不是很清楚。特別有些地方很中文版的IIS6.0有些出入。
1、安裝好J2SDK和Resin.（我J2SDK是安裝在D:\J2SDK下的，Resin是解壓縮在D:\Resin_3.0.8文件夾下的）。
2、環(huán)境變量。在我的電腦上單擊鼠標右鍵→屬性→高級→環(huán)境變量。
1）新建兩個系統(tǒng)變量（單擊下面的新建）：
①變量名：JAVA_HOME
變量值：D:\J2SDK（J2SDK安裝的目錄）
②變量名：classpath
變量值：.;%JAVA_HOME%\lib\tools.jar（注：前面是一個小數(shù)點加個分
號，直接復(fù)制就可以）
③變量名：RESIN_HOME
變量值：D:\Resin_3.0.8（Resin安裝的目錄）
2）編輯系統(tǒng)變量Path
在變量值后面追加;%JAVA_HOME%\bin\
3、復(fù)制文件。在windows2003下面是不能使用Rensin_3.0.8\bin\setup.exe。運行setup回報錯。這就需要我們自己來復(fù)制文件。我的IIS是安裝在C:\Inetpub下的。
1）C:\Inetpub下面新建一個文件夾，重命名為scripts
2）把Rensin_3.0.8\libexec下的isapi_srun.dll復(fù)制到
C:\Inetpub\scripts下
3）在C:\Inetpub\scripts新建一個resin.ini文件。
文件內(nèi)容下面兩行數(shù)據(jù)：
ResinConfigServer localhost 6802
IISPriority high
（官方的文檔上說只有需要建立多個站點的時候才必須使用
resin.ini。如果只有一個站點就沒必要新建resin.ini。推薦使用）
4、設(shè)置IIS。
1）在默認網(wǎng)站上單擊右鍵→屬性→ISAPI篩選器→添加
篩選器名稱：Resin_3.0.8（可隨便填）
可執(zhí)行文件：C:\Inetpub\scripts\isapi_srun.dll
2）在默認網(wǎng)站上單擊右鍵→新建→虛擬目錄
別名：scripts
本地路徑：C:\Inetpub\scripts
3）單擊WEB服務(wù)擴展→添加一個新的WEB服務(wù)擴展
擴展名：Resin（可隨便添）
要求文件：C:\Inetpub\scripts\isapi_srun.dll
選中設(shè)置擴展狀態(tài)為允許
5、設(shè)置Resin_3.0.8\conf\resin.conf。
在文件中找到（大概是在最后）
<host id=''>
<document-directory>doc</document-directory>
改成
<host id=''>
<document-directory>c:/inetpub/wwwroot</document-directory>
（c:/inetpub/wwwroot，為你的默認網(wǎng)站的目錄）
好，到這里，我們就完全設(shè)置完了。
然后先運行net stop w3svc關(guān)閉IIS服務(wù)。
再運行net start w3svc重新啟動IIS。
打開Resin_3.0.8\bin\httpd.exe。
現(xiàn)在IIS6.0與Resin_3.0.8已經(jīng)成功整合了。我們可以將httpd.exe作為服務(wù)啟動。那么，計算機啟動的時候就會啟動httpd.exe。
安裝服務(wù)
d:\resin_3.0.8\bin\httpd.exe -install
取消服務(wù)
d:\resin_3.0.8\bin\httpd.exe -remove
IIS6.0與Resin_3.0.8的整合困擾了我好幾天。現(xiàn)在寫出來跟大家交流一下。有什么錯誤請大家指出來。
本系列的性能提示將為改善JDBC應(yīng)用程序的性能介紹一些基本的指導(dǎo)原則，這其中的原則已經(jīng)被許多現(xiàn)有的JDBC應(yīng)用程序編譯運行并驗證過。 這些指導(dǎo)原則包括:
正確的使用數(shù)據(jù)庫MetaData方法
只獲取需要的數(shù)據(jù)
選用最佳性能的功能
管理連接和更新
以下這些一般性原則可以幫助你解決一些公共的JDBC系統(tǒng)的性能問題.
使用數(shù)據(jù)庫Metadata方法
因為通過ResultSet對象生成的Metadata方法與其它的JDBCB方法相比是較慢的, 經(jīng)常的使用它們將會削弱系統(tǒng)的的性能. 本節(jié)的指導(dǎo)原則將幫助你選擇和使用meatdata時優(yōu)化系統(tǒng)性能.
少用Metadata方法
與其它的JDBC方法相比, 由ResultSet對象生成的metadata對象的相對來說是很慢的. 應(yīng)用程序應(yīng)該緩存從ResultSet返回的metadata信息，避免多次不必要的執(zhí)行這個操作.
幾乎沒有哪一個JDBC應(yīng)用程序不用到metadata，雖然如此，你仍可以通過少用它們來改善系統(tǒng)性能. 要返回JDBC規(guī)范規(guī)定的結(jié)果集的所有列信息, 一個簡單的metadata的方法調(diào)用可能會使JDBC驅(qū)動程序去執(zhí)行很復(fù)雜的查詢甚至多次查詢?nèi)ト〉眠@些數(shù)據(jù). 這些細節(jié)上的SQL語言的操作是非常消耗性能的.
應(yīng)用程序應(yīng)該緩存這些metadata信息. 例如, 程序調(diào)用一次getTypeInfo方法后就將這些程序所依賴的結(jié)果信息緩存. 而任何程序都不大可能用到這些結(jié)果信息中的所有內(nèi)容，所以這些緩存信息應(yīng)該是不難維護的.
避免null參數(shù)
在metadata的方法中使用null參數(shù)或search patterns是很耗時的. 另外, 額外的查詢會導(dǎo)致潛在的網(wǎng)絡(luò)交通的增加. 應(yīng)盡可能的提供一些non-null的參數(shù)給metadata方法.
因為metadata的方法很慢, 應(yīng)用程序要盡可能有效的調(diào)用它們. 許多應(yīng)用程序只傳遞少量的non-null參數(shù)給這些方法.
例如:
ResultSet WSrs = WSc.getTables (null, null, "WSTable", null);
應(yīng)該這樣:
ResultSet WSrs = WSc.getTables ("cat1", "johng", "WSTable", "TABLE");
在第一個getTables()的調(diào)用中, 程序可能想知道表'WSTable'是否存在. 當然, JDBC驅(qū)動程序會逐個調(diào)用它們并且會解譯不同的請求. JDBC驅(qū)動程序會解譯請求為: 返回所有的表, 視圖, 系統(tǒng)表, synonyms, 臨時表, 或存在于任何數(shù)據(jù)庫類別任何Schema中的任何別名為'WSTable'的對象.
第二個getTables()的調(diào)用會得到更正確的程序想知道的內(nèi)容. JDBC驅(qū)動程序會解譯這個請求為: 返回當前數(shù)據(jù)庫類別中所有存在于'johng'這個schema中的所有表.
很顯然, JDBC驅(qū)動程序處理第二個請求比處理第一個請求更有效率一些.
有時, 你所請求信息中的對象有些信息是已知的. 當調(diào)用metadata方法時, 程序能傳送到驅(qū)動程序的的任何有用信息都可以導(dǎo)致性能和可靠性的改善.
使用'啞元'(dummy)查詢確定表的特性
要避免使用getColumns()去確定一個表的特性. 而應(yīng)該使用一個‘啞元’查詢來使用getMetadata()方法.
請考慮這樣一個程序, 程序中要允許用戶選取一些列. 我們是否應(yīng)該使用getColumns()去返回列信息給用戶還是以一個'啞元'查詢來調(diào)用getMetadata()方法呢?
案例 1: GetColumns 方法
| ResultSet WSrc = WSc.getColumns (... "UnknownTable" ...); // getColumns()會發(fā)出一個查詢給數(shù)據(jù)庫系統(tǒng) . . . WSrc.next(); string Cname = getString(4); . . . // 用戶必須從反復(fù)從服務(wù)器獲取N行數(shù)據(jù) // N = UnknownTable的列數(shù) |
案例 2: GetMetadata 方法
| // 準備'啞元'查詢 PreparedStatement WSps = WSc.prepareStatement ("SELECT * from UnknownTable WHERE 1 = 0"); // 查詢從來沒有被執(zhí)行，只是被預(yù)儲 ResultSetMetaData WSsmd=WSps.getMetaData(); int numcols = WSrsmd.getColumnCount(); ... int ctype = WSrsmd.getColumnType(n) ... // 獲得了列的完整信息 |
在這兩個案例中, 一個查詢被傳送到服務(wù)器. 但在案例1中, 查詢必須被預(yù)儲和執(zhí)行, 結(jié)果的描述信息必須確定(以傳給getColumns()方法), 并且客戶端必須接收一個包含列信息的結(jié)果集. 在案例2中, 只要準備一個簡單的查詢并且只用確定結(jié)果描述信息. 很顯然, 案例2執(zhí)行方式更好一些.
這個討論有點復(fù)雜, 讓我們考慮一個沒有本地化支持prepared statement的DBMS服務(wù)器. 案例1的性能沒有改變, 但案例2中, 因為'啞元'查詢必須被執(zhí)行而不是被預(yù)儲使得它的性能增強了一些. 因為查詢中的WHERE子句總是為FALSE, 查詢在不用存取表的數(shù)據(jù)情況的下會生成沒有數(shù)據(jù)的結(jié)果集. 在這種情況下，第二種方式當然比第一種方式好一些.
總而言之，總是使用ResultSet的metadata方法去獲取列信息，像列名,列的數(shù)據(jù)類型,列的數(shù)據(jù)精度和長度等. 當要求的信息無法從ResultSet的metadata中獲取時才去用getColumns()方法(像列的缺省值這些信息等)。
<!--
var doc = new ActiveXObject("Msxml2.DOMDocument"); //ie5.5+,CreateObject("Microsoft.XMLDOM")
//加載文檔
//doc.load("b.xml");
//創(chuàng)建文件頭
var p = doc.createProcessingInstruction
("xml","version=’’1.0’’
encoding=’’gb2312’’");
//添加文件頭
doc.appendChild(p);
//用于直接加載時獲得根接點
//var root = doc.documentElement;
//兩種方式創(chuàng)建根接點
// var root =
doc.createElement("students");
var root = doc.createNode(1,"students","");
//創(chuàng)建子接點
var n = doc.createNode(1,"ttyp","");
//指定子接點文本
//n.text = " this is a test";
//創(chuàng)建孫接點
var o = doc.createElement("sex");
o.text = "男";
//指定其文本
//創(chuàng)建屬性
var r = doc.createAttribute("id");
r.value="test";
//添加屬性
n.setAttributeNode(r);
//創(chuàng)建第二個屬性
var r1 = doc.createAttribute("class");
r1.value="tt";
//添加屬性
n.setAttributeNode(r1);
//刪除第二個屬性
n.removeAttribute("class");
//添加孫接點
n.appendChild(o);
//添加文本接點
n.appendChild(doc.createTextNode
("this is a text node."));
//添加注釋
n.appendChild(doc.createComment
("this is a comment\n"));
//添加子接點
root.appendChild(n);
//復(fù)制接點
var m = n.cloneNode(true);
root.appendChild(m);
//刪除接點
root.removeChild(root.childNodes(0));
//創(chuàng)建數(shù)據(jù)段
var c = doc.createCDATASection
("this is a cdata");
c.text = "hi,cdata";
//添加數(shù)據(jù)段
root.appendChild(c);
//添加根接點
doc.appendChild(root);
//查找接點
var a = doc.getElementsByTagName("ttyp");
//var a = doc.selectNodes("http://ttyp");
//顯示改接點的屬性
for(var i= 0;i<a.length;i++)
{
alert(a[i].xml);
for(var j=0;j<a[i].attributes.length;j++)
{
alert(a[i].attributes[j].name);
}
}
//XML保存（需要在服務(wù)端，客戶端用FSO）
//doc.save();
//查看根接點XML
if(n)
{
alert(n.ownerDocument.xml);
}
//-->
</script>
前言
正則表達式是煩瑣的，但是強大的，學(xué)會之后的應(yīng)用會讓你除了提高效率外，會給你帶來絕對的成就感。只要認真去閱讀這些資料，加上應(yīng)用的時候進行一定的參考，掌握正則表達式不是問題。
索引
1. 引子
目前，正則表達式已經(jīng)在很多軟件中得到廣泛的應(yīng)用，包括*nix（Linux, Unix等），HP等操作系統(tǒng)，PHP，C#，Java等開發(fā)環(huán)境，以及很多的應(yīng)用軟件中，都可以看到正則表達式的影子。
正則表達式的使用，可以通過簡單的辦法來實現(xiàn)強大的功能。為了簡單有效而又不失強大，造成了正則表達式代碼的難度較大，學(xué)習起來也不是很容易，所以需要付出一些努力才行，入門之后參照一定的參考，使用起來還是比較簡單有效的。
例子： ^.+@.+\\..+$
這樣的代碼曾經(jīng)多次把我自己給嚇退過。可能很多人也是被這樣的代碼給嚇跑的吧。繼續(xù)閱讀本文將讓你也可以自由應(yīng)用這樣的代碼。
注意：這里的第7部分跟前面的內(nèi)容看起來似乎有些重復(fù)，目的是把前面表格里的部分重新描述了一次，目的是讓這些內(nèi)容更容易理解。
2. 正則表達式的歷史
正則表達式的“祖先”可以一直上溯至對人類神經(jīng)系統(tǒng)如何工作的早期研究。Warren McCulloch 和 Walter Pitts 這兩位神經(jīng)生理學(xué)家研究出一種數(shù)學(xué)方式來描述這些神經(jīng)網(wǎng)絡(luò)。
1956 年, 一位叫 Stephen Kleene 的數(shù)學(xué)家在 McCulloch 和 Pitts 早期工作的基礎(chǔ)上，發(fā)表了一篇標題為“神經(jīng)網(wǎng)事件的表示法”的論文，引入了正則表達式的概念。正則表達式就是用來描述他稱為“正則集的代數(shù)”的表達式，因 此采用“正則表達式”這個術(shù)語。
隨后，發(fā)現(xiàn)可以將這一工作應(yīng)用于使用 Ken Thompson 的計算搜索算法的一些早期研究，Ken Thompson 是 Unix 的主要發(fā)明人。正則表達式的第一個實用應(yīng)用程序就是 Unix 中的 qed 編輯器。
如他們所說，剩下的就是眾所周知的歷史了。從那時起直至現(xiàn)在正則表達式都是基于文本的編輯器和搜索工具中的一個重要部分。
3. 正則表達式定義
正則表達式(regular expression)描述了一種字符串匹配的模式，可以用來檢查一個串是否含有某種子串、將匹配的子串做替換或者從某個串中取出符合某個條件的子串等。
列目錄時， dir *.txt或ls *.txt中的*.txt就不是一個正則表達式,因為這里*與正則式的*的含義是不同的。
正則表達式是由普通字符（例如字符 a 到 z）以及特殊字符（稱為元字符）組成的文字模式。正則表達式作為一個模板，將某個字符模式與所搜索的字符串進行匹配。
3.1 普通字符
由所有那些未顯式指定為元字符的打印和非打印字符組成。這包括所有的大寫和小寫字母字符，所有數(shù)字，所有標點符號以及一些符號。
3.2 非打印字符
| 字符 | 含義 |
|---|---|
| \cx | 匹配由x指明的控制字符。例如， \cM 匹配一個 Control-M 或回車符。x 的值必須為 A-Z 或 a-z 之一。否則，將 c 視為一個原義的 'c' 字符。 |
| \f | 匹配一個換頁符。等價于 \x0c 和 \cL。 |
| \n | 匹配一個換行符。等價于 \x0a 和 \cJ。 |
| \r | 匹配一個回車符。等價于 \x0d 和 \cM。 |
| \s | 匹配任何空白字符，包括空格、制表符、換頁符等等。等價于 [ \f\n\r\t\v]。 |
| \S | 匹配任何非空白字符。等價于 [^ \f\n\r\t\v]。 |
| \t | 匹配一個制表符。等價于 \x09 和 \cI。 |
| \v | 匹配一個垂直制表符。等價于 \x0b 和 \cK。 |
3.3 特殊字符
所謂特殊字符，就是一些有特殊含義的字符，如上面說的"*.txt"中的*，簡單的說就是表示任何字符串的意思。如果要查找文件名中有＊的文件，則需要對＊進行轉(zhuǎn)義，即在其前加一個\。ls \*.txt。正則表達式有以下特殊字符。
| 特別字符 | 說明 |
|---|---|
| $ | 匹配輸入字符串的結(jié)尾位置。如果設(shè)置了 RegExp 對象的 Multiline 屬性，則 $ 也匹配 '\n' 或 '\r'。要匹配 $ 字符本身，請使用 \$。 |
| ( ) | 標記一個子表達式的開始和結(jié)束位置。子表達式可以獲取供以后使用。要匹配這些字符，請使用 \( 和 \)。 |
| * | 匹配前面的子表達式零次或多次。要匹配 * 字符，請使用 \*。 |
| + | 匹配前面的子表達式一次或多次。要匹配 + 字符，請使用 \+。 |
| . | 匹配除換行符 \n之外的任何單字符。要匹配 .，請使用 \。 |
| [ | 標記一個中括號表達式的開始。要匹配 [，請使用 \[。 |
| ? | 匹配前面的子表達式零次或一次，或指明一個非貪婪限定符。要匹配 ? 字符，請使用 \?。 |
| \ | 將下一個字符標記為或特殊字符、或原義字符、或向后引用、或八進制轉(zhuǎn)義符。例如， 'n' 匹配字符 'n'。'\n' 匹配換行符。序列 '\\' 匹配 "\"，而 '\(' 則匹配 "("。 |
| ^ | 匹配輸入字符串的開始位置，除非在方括號表達式中使用，此時它表示不接受該字符集合。要匹配 ^ 字符本身，請使用 \^。 |
| { | 標記限定符表達式的開始。要匹配 {，請使用 \{。 |
| | | 指明兩項之間的一個選擇。要匹配 |，請使用 \|。 |
構(gòu)造正則表達式的方法和創(chuàng)建數(shù)學(xué)表達式的方法一樣。也就是用多種元字符與操作符將小的表達式結(jié)合在一起來創(chuàng)建更大的表達式。正則表達式的組件可以是單個的字符、字符集合、字符范圍、字符間的選擇或者所有這些組件的任意組合。
3.4 限定符
限定符用來指定正則表達式的一個給定組件必須要出現(xiàn)多少次才能滿足匹配。有*或+或?或{n}或{n,}或{n,m}共6種。
*、+和?限定符都是貪婪的，因為它們會盡可能多的匹配文字，只有在它們的后面加上一個?就可以實現(xiàn)非貪婪或最小匹配。
正則表達式的限定符有：
| 字符 | 描述 |
|---|---|
| * | 匹配前面的子表達式零次或多次。例如，zo* 能匹配 "z" 以及 "zoo"。* 等價于{0,}。 |
| + | 匹配前面的子表達式一次或多次。例如，'zo+' 能匹配 "zo" 以及 "zoo"，但不能匹配 "z"。+ 等價于 {1,}。 |
| ? | 匹配前面的子表達式零次或一次。例如，"do(es)?" 可以匹配 "do" 或 "does" 中的"do" 。? 等價于 {0,1}。 |
| {n} | n 是一個非負整數(shù)。匹配確定的 n 次。例如，'o{2}' 不能匹配 "Bob" 中的 'o'，但是能匹配 "food" 中的兩個 o。 |
| {n,} | n 是一個非負整數(shù)。至少匹配n 次。例如，'o{2,}' 不能匹配 "Bob" 中的 'o'，但能匹配 "foooood" 中的所有 o。'o{1,}' 等價于 'o+'。'o{0,}' 則等價于 'o*'。 |
| {n,m} | m 和 n 均為非負整數(shù)，其中n <= m。最少匹配 n 次且最多匹配 m 次。例如，"o{1,3}" 將匹配 "fooooood" 中的前三個 o。'o{0,1}' 等價于 'o?'。請注意在逗號和兩個數(shù)之間不能有空格。 |
3.5 定位符
用來描述字符串或單詞的邊界，^和$分別指字符串的開始與結(jié)束，\b描述單詞的前或后邊界，\B表示非單詞邊界。不能對定位符使用限定符。
3.6 選擇
用圓括號將所有選擇項括起來，相鄰的選擇項之間用|分隔。但用圓括號會有一個副作用，是相關(guān)的匹配會被緩存，此時可用?:放在第一個選項前來消除這種副作用。
其中?:是非捕獲元之一，還有兩個非捕獲元是?=和?!，這兩個還有更多的含義，前者為正向預(yù)查，在任何開始匹配圓括號內(nèi)的正則表達式模式的位置來匹配搜索字符串，后者為負向預(yù)查，在任何開始不匹配該正則表達式模式的位置來匹配搜索字符串。
3.7 后向引用
對一個正則表達式模式或部分模式兩邊添加圓括號將導(dǎo)致相關(guān)匹配存儲到一個臨時緩沖區(qū)中，所捕獲的每個子匹配都按照在正則表達式模式中從左至右所遇到的內(nèi) 容存儲。存儲子匹配的緩沖區(qū)編號從 1 開始，連續(xù)編號直至最大 99 個子表達式。每個緩沖區(qū)都可以使用 '\n' 訪問，其中 n 為一個標識特定緩沖區(qū)的一位或兩位十進制數(shù)。
可以使用非捕獲元字符 '?:', '?=', or '?!' 來忽略對相關(guān)匹配的保存。
4. 各種操作符的運算優(yōu)先級
相同優(yōu)先級的從左到右進行運算，不同優(yōu)先級的運算先高后低。各種操作符的優(yōu)先級從高到低如下：
| 操作符 | 描述 |
|---|---|
| \ | 轉(zhuǎn)義符 |
| (), (?:), (?=), [] | 圓括號和方括號 |
| *, +, ?, {n}, {n,}, {n,m} | 限定符 |
| ^, $, \anymetacharacter | 位置和順序 |
| | | “或”操作 |
| 字符 | 描述 |
|---|---|
| \ | 將下一個字符標記為一個特殊字符、或一個原義字符、或一個 向后引用、或一個八進制轉(zhuǎn)義符。例如，'n' 匹配字符 "n"。'\n' 匹配一個換行符。序列 '\\' 匹配 "\" 而 "\(" 則匹配 "("。 |
| ^ | 匹配輸入字符串的開始位置。如果設(shè)置了 RegExp 對象的 Multiline 屬性，^ 也匹配 '\n' 或 '\r' 之后的位置。 |
| $ | 匹配輸入字符串的結(jié)束位置。如果設(shè)置了RegExp 對象的 Multiline 屬性，$ 也匹配 '\n' 或 '\r' 之前的位置。 |
| * | 匹配前面的子表達式零次或多次。例如，zo* 能匹配 "z" 以及 "zoo"。* 等價于{0,}。 |
| + | 匹配前面的子表達式一次或多次。例如，'zo+' 能匹配 "zo" 以及 "zoo"，但不能匹配 "z"。+ 等價于 {1,}。 |
| ? | 匹配前面的子表達式零次或一次。例如，"do(es)?" 可以匹配 "do" 或 "does" 中的"do" 。? 等價于 {0,1}。 |
| {n} | n 是一個非負整數(shù)。匹配確定的 n 次。例如，'o{2}' 不能匹配 "Bob" 中的 'o'，但是能匹配 "food" 中的兩個 o。 |
| {n,} | n 是一個非負整數(shù)。至少匹配n 次。例如，'o{2,}' 不能匹配 "Bob" 中的 'o'，但能匹配 "foooood" 中的所有 o。'o{1,}' 等價于 'o+'。'o{0,}' 則等價于 'o*'。 |
| {n,m} | m 和 n 均為非負整數(shù)，其中n <= m。最少匹配 n 次且最多匹配 m 次。例如，"o{1,3}" 將匹配 "fooooood" 中的前三個 o。'o{0,1}' 等價于 'o?'。請注意在逗號和兩個數(shù)之間不能有空格。 |
| ? | 當該字符緊跟在任何一個其他限制符 (*, +, ?, {n}, {n,}, {n,m}) 后面時，匹配模式是非貪婪的。非貪婪模式盡可能少的匹配所搜索的字符串，而默認的貪婪模式則盡可能多的匹配所搜索的字符串。例如，對于字符串 "oooo"，'o+?' 將匹配單個 "o"，而 'o+' 將匹配所有 'o'。 |
| . | 匹配除 "\n" 之外的任何單個字符。要匹配包括 '\n' 在內(nèi)的任何字符，請使用象 '[.\n]' 的模式。 |
| (pattern) | 匹配 pattern 并獲取這一匹配。所獲取的匹配可以從產(chǎn)生的 Matches 集合得到，在VBScript 中使用 SubMatches 集合，在JScript 中則使用 $0…$9 屬性。要匹配圓括號字符，請使用 '\(' 或 '\)'。 |
| (?:pattern) | 匹配 pattern 但不獲取匹配結(jié)果，也就是說這是一個非獲取匹配，不進行存儲供以后使用。這在使用 "或" 字符 (|) 來組合一個模式的各個部分是很有用。例如， 'industr(?:y|ies) 就是一個比 'industry|industries' 更簡略的表達式。 |
| (?=pattern) | 正向預(yù)查，在任何匹配 pattern 的字符串開始處匹配查找字符串。這是一個非獲取匹配，也就是說，該匹配不需要獲取供以后使用。例如，'Windows (?=95|98|NT|2000)' 能匹配 "Windows 2000" 中的 "Windows" ，但不能匹配 "Windows 3.1" 中的 "Windows"。預(yù)查不消耗字符，也就是說，在一個匹配發(fā)生后，在最后一次匹配之后立即開始下一次匹配的搜索，而不是從包含預(yù)查的字符之后開始。 |
| (?!pattern) | 負向預(yù)查，在任何不匹配 pattern 的字符串開始處匹配查找字符串。這是一個非獲取匹配，也就是說，該匹配不需要獲取供以后使用。例如'Windows (?!95|98|NT|2000)' 能匹配 "Windows 3.1" 中的 "Windows"，但不能匹配 "Windows 2000" 中的 "Windows"。預(yù)查不消耗字符，也就是說，在一個匹配發(fā)生后，在最后一次匹配之后立即開始下一次匹配的搜索，而不是從包含預(yù)查的字符之后開始 |
| x|y | 匹配 x 或 y。例如，'z|food' 能匹配 "z" 或 "food"。'(z|f)ood' 則匹配 "zood" 或 "food"。 |
| [xyz] | 字符集合。匹配所包含的任意一個字符。例如， '[abc]' 可以匹配 "plain" 中的 'a'。 |
| [^xyz] | 負值字符集合。匹配未包含的任意字符。例如， '[^abc]' 可以匹配 "plain" 中的'p'。 |
| [a-z] | 字符范圍。匹配指定范圍內(nèi)的任意字符。例如，'[a-z]' 可以匹配 'a' 到 'z' 范圍內(nèi)的任意小寫字母字符。 |
| [^a-z] | 負值字符范圍。匹配任何不在指定范圍內(nèi)的任意字符。例如，'[^a-z]' 可以匹配任何不在 'a' 到 'z' 范圍內(nèi)的任意字符。 |
| \b | 匹配一個單詞邊界，也就是指單詞和空格間的位置。例如， 'er\b' 可以匹配"never" 中的 'er'，但不能匹配 "verb" 中的 'er'。 |
| \B | 匹配非單詞邊界。'er\B' 能匹配 "verb" 中的 'er'，但不能匹配 "never" 中的 'er'。 |
| \cx | 匹配由 x 指明的控制字符。例如， \cM 匹配一個 Control-M 或回車符。x 的值必須為 A-Z 或 a-z 之一。否則，將 c 視為一個原義的 'c' 字符。 |
| \d | 匹配一個數(shù)字字符。等價于 [0-9]。 |
| \D | 匹配一個非數(shù)字字符。等價于 [^0-9]。 |
| \f | 匹配一個換頁符。等價于 \x0c 和 \cL。 |
| \n | 匹配一個換行符。等價于 \x0a 和 \cJ。 |
| \r | 匹配一個回車符。等價于 \x0d 和 \cM。 |
| \s | 匹配任何空白字符，包括空格、制表符、換頁符等等。等價于 [ \f\n\r\t\v]。 |
| \S | 匹配任何非空白字符。等價于 [^ \f\n\r\t\v]。 |
| \t | 匹配一個制表符。等價于 \x09 和 \cI。 |
| \v | 匹配一個垂直制表符。等價于 \x0b 和 \cK。 |
| \w | 匹配包括下劃線的任何單詞字符。等價于'[A-Za-z0-9_]'。 |
| \W | 匹配任何非單詞字符。等價于 '[^A-Za-z0-9_]'。 |
| \xn | 匹配 n，其中 n 為十六進制轉(zhuǎn)義值。十六進制轉(zhuǎn)義值必須為確定的兩個數(shù)字長。例如，'\x41' 匹配 "A"。'\x041' 則等價于 '\x04' & "1"。正則表達式中可以使用 ASCII 編碼。. |
| \num | 匹配 num，其中 num 是一個正整數(shù)。對所獲取的匹配的引用。例如，'(.)\1' 匹配兩個連續(xù)的相同字符。 |
| \n | 標識一個八進制轉(zhuǎn)義值或一個向后引用。如果 \n 之前至少 n 個獲取的子表達式，則 n 為向后引用。否則，如果 n 為八進制數(shù)字 (0-7)，則 n 為一個八進制轉(zhuǎn)義值。 |
| \nm | 標識一個八進制轉(zhuǎn)義值或一個向后引用。如果 \nm 之前至少有 nm 個獲得子表達式，則 nm 為向后引用。如果 \nm 之前至少有 n 個獲取，則 n 為一個后跟文字 m 的向后引用。如果前面的條件都不滿足，若 n 和 m 均為八進制數(shù)字 (0-7)，則 \nm 將匹配八進制轉(zhuǎn)義值 nm。 |
| \nml | 如果 n 為八進制數(shù)字 (0-3)，且 m 和 l 均為八進制數(shù)字 (0-7)，則匹配八進制轉(zhuǎn)義值 nml。 |
| \un | 匹配 n，其中 n 是一個用四個十六進制數(shù)字表示的 Unicode 字符。例如， \u00A9 匹配版權(quán)符號 (?)。 |
| 正則表達式 | 說明 |
|---|---|
| /\b([a-z]+) \1\b/gi | 一個單詞連續(xù)出現(xiàn)的位置 |
| /(\w+):\/\/([^/:]+)(:\d*)?([^# ]*)/ | 將一個URL解析為協(xié)議、域、端口及相對路徑 |
| /^(?:Chapter|Section) [1-9][0-9]{0,1}$/ | 定位章節(jié)的位置 |
| /[-a-z]/ | A至z共26個字母再加一個-號。 |
| /ter\b/ | 可匹配chapter，而不能terminal |
| /\Bapt/ | 可匹配chapter，而不能aptitude |
| /Windows(?=95 |98 |NT )/ | 可匹配Windows95或Windows98或WindowsNT,當找到一個匹配后，從Windows后面開始進行下一次的檢索匹配。 |
7.1 基本模式匹配
一切從最基本的開始。模式，是正規(guī)表達式最基本的元素，它們是一組描述字符串特征的字符。模式可以很簡單，由普通的字符串組成，也可以非常復(fù)雜，往往用特殊的字符表示一個范圍內(nèi)的字符、重復(fù)出現(xiàn)，或表示上下文。例如：
^once
這個模式包含一個特殊的字符^，表示該模式只匹配那些以once開頭的字符串。例如該模式與字符串"once upon a time"匹配，與"There once was a man from NewYork"不匹配。正如如^符號表示開頭一樣，$符號用來匹配那些以給定模式結(jié)尾的字符串。
bucket$
這個模式與"Who kept all of this cash in a bucket"匹配，與"buckets"不匹配。字符^和$同時使用時，表示精確匹配（字符串與模式一樣）。例如：
^bucket$
只匹配字符串"bucket"。如果一個模式不包括^和$，那么它與任何包含該模式的字符串匹配。例如：模式
once
與字符串
There once was a man from NewYork
Who kept all of his cash in a bucket.
是匹配的。
在該模式中的字母(o-n-c-e)是字面的字符，也就是說，他們表示該字母本身，數(shù)字也是一樣的。其他一些稍微復(fù)雜的字符，如標點符號和白字符（空 格、制表符等），要用到轉(zhuǎn)義序列。所有的轉(zhuǎn)義序列都用反斜杠(\)打頭。制表符的轉(zhuǎn)義序列是：\t。所以如果我們要檢測一個字符串是否以制表符開頭，可以 用這個模式：
^\t
類似的，用\n表示“新行”，\r表示回車。其他的特殊符號，可以用在前面加上反斜杠，如反斜杠本身用\\表示，句號.用\.表示，以此類推。
7.2 字符簇
在INTERNET的程序中，正規(guī)表達式通常用來驗證用戶的輸入。當用戶提交一個FORM以后，要判斷輸入的電話號碼、地址、EMAIL地址、信用卡號碼等是否有效，用普通的基于字面的字符是不夠的。
所以要用一種更自由的描述我們要的模式的辦法，它就是字符簇。要建立一個表示所有元音字符的字符簇，就把所有的元音字符放在一個方括號里：
[AaEeIiOoUu]
這個模式與任何元音字符匹配，但只能表示一個字符。用連字號可以表示一個字符的范圍，如：
[a-z] //匹配所有的小寫字母
[A-Z] //匹配所有的大寫字母
[a-zA-Z] //匹配所有的字母
[0-9] //匹配所有的數(shù)字
[0-9\.\-] //匹配所有的數(shù)字，句號和減號
[ \f\r\t\n] //匹配所有的白字符
同樣的，這些也只表示一個字符，這是一個非常重要的。如果要匹配一個由一個小寫字母和一位數(shù)字組成的字符串，比如"z2"、"t6"或"g7"，但不是"ab2"、"r2d3" 或"b52"的話，用這個模式：
^[a-z][0-9]$
盡管[a-z]代表26個字母的范圍，但在這里它只能與第一個字符是小寫字母的字符串匹配。
前面曾經(jīng)提到^表示字符串的開頭，但它還有另外一個含義。當在一組方括號里使用^是，它表示“非”或“排除”的意思，常常用來剔除某個字符。還用前面的例子，我們要求第一個字符不能是數(shù)字：
^[^0-9][0-9]$
這個模式與"&5"、"g7"及"-2"是匹配的，但與"12"、"66"是不匹配的。下面是幾個排除特定字符的例子：
[^a-z] //除了小寫字母以外的所有字符
[^\\\/\^] //除了(\)(/)(^)之外的所有字符
[^\"\'] //除了雙引號(")和單引號(')之外的所有字符
特殊字符"." (點，句號)在正規(guī)表達式中用來表示除了“新行”之外的所有字符。所以模式"^.5$"與任何兩個字符的、以數(shù)字5結(jié)尾和以其他非“新行”字符開頭的字符串匹配。模式"."可以匹配任何字符串，除了空串和只包括一個“新行”的字符串。
PHP的正規(guī)表達式有一些內(nèi)置的通用字符簇，列表如下：
字符簇含義
[[:alpha:]] 任何字母
[[:digit:]] 任何數(shù)字
[[:alnum:]] 任何字母和數(shù)字
[[:space:]] 任何白字符
[[:upper:]] 任何大寫字母
[[:lower:]] 任何小寫字母
[[:punct:]] 任何標點符號
[[:xdigit:]] 任何16進制的數(shù)字，相當于[0-9a-fA-F]
7.3 確定重復(fù)出現(xiàn)
到現(xiàn)在為止，你已經(jīng)知道如何去匹配一個字母或數(shù)字，但更多的情況下，可能要匹配一個單詞或一組數(shù)字。一個單詞有若干個字母組成，一組數(shù)字有若干個單數(shù)組成。跟在字符或字符簇后面的花括號({})用來確定前面的內(nèi)容的重復(fù)出現(xiàn)的次數(shù)。
字符簇 含義
^[a-zA-Z_]$ 所有的字母和下劃線
^[[:alpha:]]{3}$ 所有的3個字母的單詞
^a$ 字母a
^a{4}$ aaaa
^a{2,4}$ aa,aaa或aaaa
^a{1,3}$ a,aa或aaa
^a{2,}$ 包含多于兩個a的字符串
^a{2,} 如：aardvark和aaab，但apple不行
a{2,} 如：baad和aaa，但Nantucket不行
\t{2} 兩個制表符
.{2} 所有的兩個字符
這些例子描述了花括號的三種不同的用法。一個數(shù)字，{x}的意思是“前面的字符或字符簇只出現(xiàn)x次”；一個數(shù)字加逗號，{x,}的意思是“前面的內(nèi)容出 現(xiàn)x或更多的次數(shù)”；兩個用逗號分隔的數(shù)字，{x,y}表示“前面的內(nèi)容至少出現(xiàn)x次，但不超過y次”。我們可以把模式擴展到更多的單詞或數(shù)字：
^[a-zA-Z0-9_]{1,}$ //所有包含一個以上的字母、數(shù)字或下劃線的字符串
^[0-9]{1,}$ //所有的正數(shù)
^\-{0,1}[0-9]{1,}$ //所有的整數(shù)
^\-{0,1}[0-9]{0,}\.{0,1}[0-9]{0,}$ //所有的小數(shù)
最后一個例子不太好理解，是嗎？這么看吧：與所有以一個可選的負號(\-{0,1})開頭(^)、跟著0個或更多的數(shù)字([0-9]{0,})、和一個 可選的小數(shù)點(\.{0,1})再跟上0個或多個數(shù)字([0-9]{0,})，并且沒有其他任何東西($)。下面你將知道能夠使用的更為簡單的方法。
特殊字符"?"與{0,1}是相等的，它們都代表著：“0個或1個前面的內(nèi)容”或“前面的內(nèi)容是可選的”。所以剛才的例子可以簡化為：
^\-?[0-9]{0,}\.?[0-9]{0,}$
特殊字符"*"與{0,}是相等的，它們都代表著“0個或多個前面的內(nèi)容”。最后，字符"+"與 {1,}是相等的，表示“1個或多個前面的內(nèi)容”，所以上面的4個例子可以寫成：
^[a-zA-Z0-9_]+$ //所有包含一個以上的字母、數(shù)字或下劃線的字符串
^[0-9]+$ //所有的正數(shù)
^\-?[0-9]+$ //所有的整數(shù)
^\-?[0-9]*\.?[0-9]*$ //所有的小數(shù)
當然這并不能從技術(shù)上降低正規(guī)表達式的復(fù)雜性，但可以使它們更容易閱讀。
|
一 準備 當然，在生產(chǎn)環(huán)境中這樣做是不行的，需要的在 DNS 上做相應(yīng)的域名解析。 將 tomcat 目錄下的 webapps 目錄在同一目錄復(fù)制一份，目錄名分為 webapps2 ，然后將 最后，寫一個簡單 html 文件用于測試，文件名為 test.html ，文件內(nèi)容如下： <HTML> <BODY> 至此，前期的準備工作做完了，全是一些體力活。 配置 www.sentom1.net 虛擬主機 打開 tomcat/conf/server.xml 文件，將 Host <Logger className="org.apache.catalina.logger.FileLogger" </Host> 將下面內(nèi)容追加到 Host 元素后面，注意 Host 元素中 name 屬性和 appBase 屬性的值的變化。 <Logger className="org.apache.catalina.logger.FileLogger" </Host> |