Unlike many of the internet protocols which are text based, DNS is a binary protocol. DNS servers are some of the busiest computers on the internet, and the overhead of string-parsing would make such a protocol prohibitive. To keep things fast and lean, UDP is the transport of choice being lightweight, connectionless and fast in comparison to TCP. To communicate with a DNS server, you simply throw a single UDP packet at it and it throws one back. Oh, and these packets cannot exceed 512 bytes in length. (Incidentally, many firewalls block UDP packets larger than 512 bytes in length.)

The diagram below shows the binary request I sent to my DNS server to look up the MX records for the domain microsoft.com and the corresponding response I received. To do this, I sent a 31 byte UDP packet to port 53 of my DNS server as shown below. It replied with a 97 byte response again on UDP port 53.

Both request and response share the same format, which starts with a 12 byte header block. This starts with a two byte message identifier. This can be any 16 bit value and is echoed in the first two bytes of the response, and is useful as it allows us to match up requests and responses as UDP makes no guarantees about the order in which things arrive. After that follows a two byte status field which in our request has just one single bit set, the recursion desired bit. Next comes a two byte value denoting how many questions there are in the request, in this case just 1. There then follows three more two byte values denoting the number of answers, name server records and additional records. As this is a request, all these are zero.

The rest of the request is our single question. A question consists of a variable length domain name, a two byte QTYPE and a two byte QCLASS in that order. Domain names are treated as a series of labels, labels being the words between dots. In our example microsoft.com consists of two labels, microsoft and com. Each label is preceded by a single byte specifying its length. The QTYPE denotes the type of record to retrieve, in this example, MX. QCLASS is Internet.

The response we get back tells us that there are three inbound mail servers for the domain microsoft.com, maila.microsoft.com, mailb.microsoft.com and mailc.microsoft.com. All three have the same preference of 10. When sending mail to a domain, the mail server with the lowest preference should be tried first, then the next lowest etc. In this case, there is no preference difference and any of the three may be used. Let's look a bit more closely at the response.

You may have noticed that the first 31 bytes of the response are very similar to the request, the only difference being in the status field (bytes 2 & 3) and the answer count (bytes 6 & 7). The answer count tells us that three answers follow in the response. I refer those who are interested in the make up of the status field to the above RFC section 4.1.1, as I will not cover that here. You'll also notice that the question is echoed in the response, something which seems rather inefficient to me, but that's the standard. The first answer starts at byte 31 (0x1F).

The first part of any answer embeds the question in it so if you ask more than one question you know to which question the answer refers. A shortened form is used - rather than repeating the domain microsoft.com explicitly here which is wasteful when we've only got 512 bytes to play with. We reference the existing domain definition at byte 12 (0x0C). This requires just two bytes instead of 15 in our example. When examining the label length byte which precedes a label, if the two most significant bits are set, this denotes a reference to a previously defined domain name and the label does not follow here. The next byte tells you the position in the message of the existing domain name. Again the QTYPE and QCLASS follow, and then we start to see the part which is the answer.

The next four bytes represent the TTL (time to live) of the record. When a DNS server can't answer a question explicitly, it knows (or can find out) another server which can and asks that. It will then cache this answer for a certain period to improve efficiency. Every record in the cache has a TTL after which it will be destroyed and re-fetched from elsewhere if needed.

The next two bytes tell the size of the record, the next two the MX preference, and then follows the variable length domain name. Here we only specify the mailc part of the domain, and then again reference the rest of the domain name at byte 12 (to produce mailc.microsoft.com). Two almost identical records follow for maila.microsoft.com and mailb.microsoft.com.

+---------------------+
| Header              |
+---------------------+
| Question            | the question for the name server
+---------------------+
| Answer              | RRs answering the question
+---------------------+
| Authority           | RRs pointing toward an authority
+---------------------+
| Additional          | RRs holding additional information
+---------------------+

Obviously queries won't have the answer, authority, and additional fields. Packets are of course UDP and DNS servers feel comfortable to operate on port 53. So the first thing is to send a query containing the hostname.

The next task is to receive the reply which is expected to contain the information we are expecting. DNS queries are used for a variety of purposes. Apart from getting the ipv4 address of a host we also use DNS for getting the mail exchange/server of a specified domain and etc. All types of queries and response packets are built nearly on the same structure depicted above.

When a DNS server replies it sends the question as it is along with a bunch of RR's or resource records. All RR's stand in a queue, and certain fields of the header reveal how many of the RR's fall into the answer, authority, and additional categories.

This is the structure of a DNS header :

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID                                            |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode    |AA|TC|RD|RA| Z      |  RCODE    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   QDCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   ANCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   NSCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   ARCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

ID :the identifier
QDCOUNT : how many questions are there in the packet.
ANCOUNT : how many answers in the RR queue.
NSCOUNT : Authority RR count
ARCOUNT : Additional Count
for explanation of the other fields lookup the RFC
A DNS packet typically looks like this Header-Query-RR-RR-RR-RR-RR-RR........

A Query structure looks like this

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                    QNAME                      /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QTYPE                      |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QCLASS                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Note : QNAME is a variable length field to fit the hostname
QCLASS should be 1 since we are on internet
QTYPE determines what you want to know ; ipv4 address,mx etc.

Resource Record(RR) field looks like this

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                                               /
/                     NAME                      /
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     TYPE                      |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     CLASS                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     TTL                       |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                  RDLENGTH                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/                     RDATA                     /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Note again : NAME and RDATA are variable length field
Type field tells how RDATA relates to NAME. e.g. if TYPE is 1 then RDATA contains the ipv4 address of the NAME.
That's all about the structures we need.

1. .test{   
2.   background:#000;   
3.   color:white;   
4.   width:200px;   
5.   position:absolute;   
6.   left:10px;   
7.   top:10px;   
8.    filter: Alpha(opacity=10);   
9.    -moz-opacity:.1;   
10.    opacity:0.1;   
11. }  

這里關鍵的是

這三句,第一句是ie 支持.第二三句是firefox支持的,但是版本不一樣就有兩種了,所以用時候把三句都加上就行了

刪除Ｂ－－－3
修改Ｂ－－－4
添加Ｂ－－－5

……

　　理論上可以有Ｎ個操作，這取決于你用于儲存用戶權限值的數據類型了。

　　這樣，如果用戶有權限：添加Ａ－－－2；刪除Ｂ－－－3；修改Ｂ－－－4。那用戶的權限值 purview =2^2+2^3+2^4＝28，也就是2的權的和了。化成二進制可以表示為11100。這樣，如果要驗證用戶是否有刪除Ｂ的權限，就可以通過位與運算來實現。在Ｊａｖａ里，位與運算運算符號為＆，即是：

int value = purview &((int)Math.pow(2,3));

　　你會發現，當用戶有操作權限時，運算出來的結果都會等于這個操作需要的權限值！

　　原理：

　　位與運算，顧名思義就是對位進行與運算：

　　以上面的式子為例：purview & 2^3 也就是　28&8

　　將它們化成二進制有

　11100
＆ 01000
-------------------
　 01000 == 8(十進制)　＝＝　2^3

　　同理，如果要驗證是否有刪除Ａ－－－0的權限

　　可以用：purview &((int)Math.pow(2,0));

　　即：

　11100
＆ 00001
------------------------
　 00000 == 0(十進制)　　！＝　2^0

　　這種算法的一個優點是速度快。可以同時處理Ｎ個權限。如果想驗證是否同時有刪除Ａ－－－0和刪除Ｂ－－－3的權限，可以用purview&(2^0+2^3)==(2^0+2^3)?true:false;設置多角色用戶。根據權限值判斷用戶的角色。

　　下面提供一個java的單操作權限判斷的代碼：

//userPurview是用戶具有的總權限
//optPurview是一個操作要求的權限為一個整數（沒有經過權的！）
public static boolean checkPower(int userPurview, int optPurview)
{
  int purviewValue = (int)Math.pow(2, optPurview);
  return (userPurview & purviewValue) == purviewValue;
}

　　當然，多權限的驗證只要擴展一下就可以了。

　　幾點注意事項：首先，一個系統可能有很多的操作，因此，請建立數據字典，以便查閱，修改時使用。其次，如果用數據庫儲存用戶權限，請注意數值的有效范圍。操作權限值請用唯一的整數！ 

FancyUpload，用flash和mootools實現的一款多文件無刷新上傳工具。
最大的特點是可以一次選擇多個文件，無刷新上傳。
早些時候曾想過一次選擇多個文件的問題，瀏覽器默認的file標簽一次只能選擇一個文件，要瀏覽并讀取本地文件就必須調用本地的組件或命令，所以單純用javascript+html無解。
今天查看訂閱的feeds時，無意中在Ajaxian看到這個演示圖片上選擇了多個文件：

非常好奇，過去看了一下demo，果然可以一次選擇多個文件！

Browsfile的button沒什么特別，就是一個button，肯定是通過js觸發了某個動作。前面說過js和html是不能實現這個功能的，那么肯定是flash實現了這個功能。

文件里面有個Swiff.Uploader.swf，就是這個swf實現了文件瀏覽的功能，as在這：http://digitarald.de/workspace/packages/Uploader/Swiff.Uploader.as

google了一下flash filebrowser和flash fileupload果然找到很多內容

這片中文的詳細說明了那個flash的原理：
http://www.cnblogs.com/walkingboy/archive/2007/02/09/Flash_FileUpload_FileReference.html
出處可能是這個：
http://www.codeproject.com/aspnet/FlashUpload.asp

原理是用了flash的FileReferenceList API實現的多文件選取。
http://markshu.ca/imm/flash/tutorial/fileReference.html

另外還有幾個實例：
http://www.betriebsraum.de/blog/2006/01/13/download-flash-8-file-browser/

http://www.extremefx.com.ar/blog/flash-textarea

1. import javax.servlet.http.HttpServletRequest;   
2. import org.aopalliance.intercept.MethodInterceptor;   
3. import org.aopalliance.intercept.MethodInvocation;   
4. import org.apache.struts.action.ActionMapping;   
5.   
6. /**  
7.  * 這是一個攔截器,用來驗證用戶是否通過驗證  
8.  *  
9.  */  
10. public class AuthorityInterceptor implements MethodInterceptor {   
11.   
12.     public Object invoke(MethodInvocation invocation) throws Throwable   
13.     {   
14.         HttpServletRequest request = null;   
15.         ActionMapping mapping = null;   
16.         Object[] args = invocation.getArguments();   
17.         for (int i = 0 ; i < args.length ; i++ )   
18.         {   
19.             if (args[i] instanceof HttpServletRequest) request = (HttpServletRequest)args[i];   
20.             if (args[i] instanceof ActionMapping) mapping = (ActionMapping)args[i];   
21.         }   
22.         if ( request.getSession().getAttribute("adminname") != null)   
23.         {   
24.             return invocation.proceed();   
25.         }   
26.         else  
27.         {   
28.             return mapping.findForward("login");   
29.         }   
30.     }   
31. }  

import javax.servlet.http.HttpServletRequest;
import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.apache.struts.action.ActionMapping;
/**
* 這是一個攔截器,用來驗證用戶是否通過驗證
*
*/
public class AuthorityInterceptor implements MethodInterceptor {
public Object invoke(MethodInvocation invocation) throws Throwable
{
HttpServletRequest request = null;
ActionMapping mapping = null;
Object[] args = invocation.getArguments();
for (int i = 0 ; i < args.length ; i++ )
{
if (args[i] instanceof HttpServletRequest) request = (HttpServletRequest)args[i];
if (args[i] instanceof ActionMapping) mapping = (ActionMapping)args[i];
}
if ( request.getSession().getAttribute("adminname") != null)
{
return invocation.proceed();
}
else
{
return mapping.findForward("login");
}
}
}

 思路：在頁面上的一個輸入框中，當用戶輸入內容的時侯，網頁應該做出響應，將用戶所輸內容提交給一個后臺頁面或程序處理；然后將此內容與網站中的信息（固定信息或數據庫中的信息）相比較，若找到相關內容，則使的輸入框彈出下拉提示信息，用戶可選擇下拉提示信息，輸入框中內容也不再是用戶所輸內容，而是所選的下拉信息。

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf- 8">

 <title>Insert title here</title>

 <script type="text/javascript" src="javascripts/prototype.js"></s cript>  

 <script type="text/javascript" src="javascripts/autoassist.js"></ script>

 <link rel="stylesheet" type="text/css" href="styles/autoassist.cs s" />  

 <script language="javascript">

 Event.observe(window, "load", function() {

     var aa = new AutoAssist("userName", function() {

        return "autoassist.action?q=" + this.txtBox.value;//q為用
戶所輸內容找出下拉信息后返回；當用戶點擊后改變input中的值

    });

});//將用戶所輸內容傳遞到action中的函數

</script>

</head>

<body>

<input type="text" name="userName" id="userName"/>

</body>

      </html>

我們不可能列舉所有可能的頑固，我們會針對幾種最常見的問題進行處理。當然了，正如前面說到的，如果我們自己使用java.net.HttpURLConnection來搞定這些問題是很恐怖的事情，因此在開始之前我們先要介紹一下一個開放源碼的項目，這個項目就是Apache開源組織中的httpclient，它隸屬于Jakarta的commons項目，目前的版本是2.0RC2。commons下本來已經有一個net的子項目，但是又把httpclient單獨提出來，可見http服務器的訪問絕非易事。

Commons-httpclient項目就是專門設計來簡化HTTP客戶端與服務器進行各種通訊編程。通過它可以讓原來很頭疼的事情現在輕松的解決，例如你不再管是HTTP或者HTTPS的通訊方式，告訴它你想使用HTTPS方式，剩下的事情交給httpclient替你完成。本文會針對我們在編寫HTTP客戶端程序時經常碰到的幾個問題進行分別介紹如何使用httpclient來解決它們，為了讓讀者更快的熟悉這個項目我們最開始先給出一個簡單的例子來讀取一個網頁的內容，然后循序漸進解決掉前進中的所形侍狻?/font>

1． 讀取網頁(HTTP/HTTPS)內容

首先創建RomeResult類：

程序很簡單。實現了Result接口，尋找一個與feedName參數匹配的SyndFeed實例，然后轉換為指定的feedType類型，然后通過rome的SyndFeedOutput輸出到Response去。
然后我們給我們的WebWork配置romeResult。
在xwork.xml中配置：

真是不好意思，Getter/Setter占了大部分地方我省略去了。邏輯很簡單，就是把我們的POJO影射到Feed的模型上面，過程很簡單。我留下了幾個參數可以在外面設置：
maxEntryNumber顯示的feed的條數，鏈接生成時使用的SiteUrl，當然也可以通過request獲取。
下面我們配置我們的Action，注意平時我們可能使用DAO生成newsList，而不是我這個寫死的getNewsList()方法，此時可能需要配合Spring進行IOC的設置，我們這里省略掉。
下面是我們這個Action的xwork配置：