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配置：