ffmpeg裁剪合并视频

在网上找了个视频,其中有部分内容是需要的,能不能从整个文件中抽取一部分呢?或抽取一部分内容的音频列?在查阅了资料后发现 FFmpeg 很容易实现这些功能。

这行命令解释为:从文件 Morning_News.asf 第 46:28 分秒开始,截取 03: 25 的时间,其中视频和音频解码不变,输出文件名为 output.asf 。

那如果视频文件太大,该如何保存为的 mp3 文件呢?

这两条命令顺序一定要注意。不然运行会有问题。切记切记!
参考:
1、http://wuyuans.com/2012/04/ffmpeg-split/

2、http://ffmpeg.org/ffmpeg.html

这里裁剪是指时间轴裁剪,不是空间裁剪。

比如说,你想把视频的从一分20秒开始,30秒的视频裁剪出来,保存成一个视频。这是这个文章要讨论的问题。

一 裁剪视频

ffmpeg提供简单的命令参数:

ffmpeg -ss START -t DURATION -i INPUT -vcodec copy -acodec copy OUTPUT

对上面的命令稍做个解释。

-ss 开始时间,如: 00:00:20,表示从20秒开始;

-t 时长,如: 00:00:10,表示截取10秒长的视频;

-i 输入,后面是空格,紧跟着就是输入视频文件;

-vcodec copy 和 -acodec copy表示所要使用的视频和音频的编码格式,这里指定为copy表示原样拷贝;

INPUT,输入视频文件;

OUTPUT,输出视频文件;

比如:

ffmpeg -ss 00:00:20 -t 00:00:10 -i D:/MyVideo.mpg -vcodec copy -acopy copy D:/Split.mpg

这个命令就是从20秒开始裁剪到20+10=30秒结束,总共10秒的视频。这个命令执行很快,因为只是原始数据的拷贝,中间没有什么编码和解码的过程。

执行这个命令后你能得到Split.mpg这个输出文件。你可以用视频播放软件播放这个视频看看。可能有些视频裁剪后的效果,如期望一致,20秒开始,30秒结束,总共10秒的视频,但是有些视频裁剪后你会发现可能开始和结束都不是很准确,有可能是从18秒开始,33秒结束。这是为什么呢?

因为这些视频里20秒和30秒处地方刚好不是关键帧,而ffmpeg会在你输入的这两个时间点附近圆整到最接近的关键帧处,然后做接下来的事情。如果你不懂什么是关键帧,没关系,这也不影响你使用这个命令。

如果你的要求能够接受几秒的误差,那么这个命令完全就可以满足你的需要,接下来的内容你也没有必要往下看了。

但是在我项目里要求很严格,一定要到确定的时间。所以要用另外一种方式。

上面的造成那样的原因是所选的时间不是关键帧,那如果我们将输入的视频先转换成所有的帧都为关键帧的视频,其实就是将所有的帧的编码方式转为帧内编码(不理解帧内编码也没关系,你就当没看见它,接着往下看),这个问题就有解了。ffmpeg也可以帮我们完成这个事情。

ffmpeg -i INPUT -sameq -intra OUTPUT

-i 输入,后面是空格,紧跟着就是输入视频文件;

INPUT 输入文件;

-sameq 表示保持同样的视频质量;

-intra, 帧内编码;

OUTPUT 输出文件名。

 

如:

ffmpeg -i D:/MyVideo.mpg -sameq -intra D:/temp.mpg

这个命令的结果文件就是D:/temp.mpg.这个文件的视频和D:/MyVideo.mpg是一样的,但是你会发现这个文件会比D:/MyVideo.mpg大很多倍,原因就是转换前一般采用的帧间编码,转换后变成了帧内编码。这里我们说是一般,原因是有些视频文件本身就采用了帧内编码。

接下来我们就开始裁剪。

ffmpeg -ss START -vsync 0 -t DURATION -i INPUT -vcodec VIDEOCODEC-acodec AUDIOCODEC OUTPUT

-ss 开始时间,如: 00:00:20,表示从20秒开始;

-t 时长,如: 00:00:10,表示截取10秒长的视频;

-i 输入,后面是空格,紧跟着就是输入视频文件;

-vcodec 视频的编码格表示所要使用的视频式;

-acodec 音频的编码格表示所要使用的视频式;

INPUT,输入视频文件;

OUTPUT,输出视频文件;

如:

ffmpeg -ss 00:00:30 -vsync 0 -t 00:00:30 -i D:/temp.mpg -vcodec libx264-acodec libfaac D:/result.mpg

这里音频和视频分别采用了aac和h264.

这样就得到了我们最终想要的结果。

二 合并视频

上面我们可以将一个视频中感兴趣的部分裁剪出来,比如我们裁剪出3段视频,而裁剪出来的视频,我们不想它是一个一个的,而是一整个。总的需求就是给定一个视频,用户可以挑选出自己喜欢的一些时间段,然后开始裁剪,最后得到那些挑选的时间段组成的视频。

要完成这个任务,有了前面我们裁剪视频的基础就好办多了,利用前面的方法将各个感兴趣的视频裁剪出了,这样得到多个小视频,然后再用下面的方法就可以实现:

1. 首先将各个视频全部转换为mpeg格式:

ffmpeg  -i INPUT -f mpeg  OUTPUT

例如:

ffmpeg  -i D:/temp1.avi -f mpeg  D:/result1.mpg

ffmpeg  -i D:/temp2.mp4 -f mpeg  D:/result2.mpg

2. 通过copy或者cat命令合并视频

copy -b INPUT+INPUT OUTPUT

例如:

copy /b “D:/result1.mpg”+”D:/result1.mpg” “D:/result.mpge”

3. 将合并的视频进行编码生成最终的结果视频

ffmpeg -i INPUT -f FORMAT OUTPUT

例如:

ffmpeg -i “D:/result.mpge” -f mp4 “D:/result.mp4”

完。

 

转自(有删减):http://m.oschina.net/blog/138774

HTTP长连接

What is HTTP Persistent Connections?
HTTP persistent connections, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using the same TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new one for every single request/response pair. Using persistent connections is very important for improving HTTP performance.

什么是HTTP长连接?
HTTP长连接,与一般每次发起http请求或响应都要建立一个tcp连接不同,http长连接利用同一个tcp连接处理多个http请求和响应,也叫HTTP keep-alive,或者http连接重用。使用http长连接可以提高http请求/响应的性能。

There are several advantages of using persistent connections, including:

Network friendly. Less network traffic due to fewer setting up and tearing down of TCP connections.
Reduced latency on subsequent request. Due to avoidance of initial TCP handshake
Long lasting connections allowing TCP sufficient time to determine the congestion state of the network, thus to react appropriately.

使用http长连接有很多好处,包括:

更少的建立和关闭tcp连接,可以减少网络流量。
因为已建立的tcp握手,减少后续请求的延时。
长时间的连接让tcp有充足的时间判断网络的拥塞情况,方便做出下步操作。

The advantages are even more obvious with HTTPS or HTTP over SSL/TLS. There, persistent connections may reduce the number of costly SSL/TLS handshake to establish security associations, in addition to the initial TCP connection set up.
In HTTP/1.1, persistent connections are the default behavior of any connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server. However, the protocol provides means for a client and a server to signal the closing of a TCP connection.

这些优点在使用https连接时更显著。可以减少多次建立高消耗的SSL/TLS握手。
在HTTP/1.1中,默认使用的是长连接方式。客户端默认服务端会保持长连接,即便返回错误响应;除非明确指示不使用长连接。同时,协议中也指定了客户端可以发送关闭信号到服务端来关闭TCP连接。

What makes a connection reusable?
Since TCP by its nature is a stream based protocol, in order to reuse an existing connection, the HTTP protocol has to have a way to indicate the end of the previous response and the beginning of the next one. Thus, it is required that all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection). Self demarcation is achieved by either setting the Content-Length header, or in the case of chunked transfer encoded entity body, each chunk starts with a size, and the response body ends with a special last chunk.

怎样是连接可以重用?
因为TCP是基于流的协议,所以HTTP协议需要有一种方式来指示前一个响应的结束和后一个响应的开始来重用已建立的连接。所以,它要求连接中传输的信息必须有自定义的消息长度。自定义消息长度可以通过设置 Content-Length 消息头,若传输编码的实体内容块,则每个数据块的标明数据块的大小,而且响应体也是以一个特殊的数据块结束。

What happens if there are proxy servers in between?
Since persistent connections applies to only one transport link, it is important that proxy servers correctly signal persistent/or-non-persistent connections separately with its clients and the origin servers (or to other proxy servers). From a HTTP client or server’s perspective, as far as persistence connection is concerned, the presence or absence of proxy servers is transparent.

若中间存在代理服务器将会如何?
因为长连接仅占用一条传输链路,所以代理服务器能否正确得与客户端和服务器端(或者其他代理服务器)发送长连接或非长连接的信号尤为重要。但是HTTP的客户端或服务器端来看,代理服务器对他们来说是透明的,即便长连接是需要关注的。

What does the current JDK do for Keep-Alive?
The JDK supports both HTTP/1.1 and HTTP/1.0 persistent connections.

When the application finishes reading the response body or when the application calls close() on the InputStream returned by URLConnection.getInputStream(), the JDK’s HTTP protocol handler will try to clean up the connection and if successful, put the connection into a connection cache for reuse by future HTTP requests.

The support for HTTP keep-Alive is done transparently. However, it can be controlled by system properties http.keepAlive, and http.maxConnections, as well as by HTTP/1.1 specified request and response headers.

当前的JDK如何处理Keep-Alive?
JDK同时支持HTTP/1.1 和 HTTP/1.0。
当应用程序读取完响应体内容后或者调用 close() 关闭了URLConnection.getInputStream()返回的流,JDK中的HTTP协议句柄将关闭连接,并将连接放到连接缓存中,以便后面的HTTP请求使用。
对HTTP keep-Alive 的支持是透明的。但是,你也可以通过系统属性http.keepAlive和http.maxConnections以及HTTP/1.1协议中的特定的请求响应头来控制。

The system properties that control the behavior of Keep-Alive are:
http.keepAlive=<boolean>
default: true

Indicates if keep alive (persistent) connections should be supported.
http.maxConnections=<int>
default: 5

Indicates the maximum number of connections per destination to be kept alive at any given time

HTTP header that influences connection persistence is:
Connection: close

If the “Connection” header is specified with the value “close” in either the request or the response header fields, it indicates that the connection should not be considered ‘persistent’ after the current request/response is complete.

控制Keep-Alive表现的系统属性有:

http.keepAlive=<布尔值>
默认: true
指定长连接是否支持

http.maxConnections=<整数>
默认: 5
指定对同一个服务器保持的长连接的最大个数。

影响长连接的HTTP header是:
Connection: close
如果请求或响应中的Connection header被指定为close,表示在当前请求或响应完成后将关闭TCP连接。

The current implementation doesn’t buffer the response body. Which means that the application has to finish reading the response body or call close() to abandon the rest of the response body, in order for that connection to be reused. Furthermore, current implementation will not try block-reading when cleaning up the connection, meaning if the whole response body is not available, the connection will not be reused.

JDK中的当前实现不支持缓存响应体,所以应用程序必须读取完响应体内容或者调用close()关闭流并丢弃未读内容来重用连接。此外,当前实现在清理连接时并未使用阻塞读,这就意味这如果响应体不可用,连接将不能被重用。

What’s new in Tiger?
When the application encounters a HTTP 400 or 500 response, it may ignore the IOException and then may issue another HTTP request. In this case, the underlying TCP connection won’t be Kept-Alive because the response body is still there to be consumed, so the socket connection is not cleared, therefore not available for reuse. What the application needs to do is call HttpURLConnection.getErrorStream() after catching the IOException , read the response body, then close the stream. However, some existing applications are not doing this. As a result, they do not benefit from persistent connections. To address this problem, we have introduced a workaround.

The workaround involves buffering the response body if the response is >=400, up to a certain amount and within a time limit, thus freeing up the underlying socket connection for reuse. The rationale behind this is that when the server responds with a >=400 error (client error or server error. One example is “404: File Not Found” error), the server usually sends a small response body to explain whom to contact and what to do to recover.

JDK1.5中的新特性
当应用接收到400或500的HTTP响应时,它将忽略IOException 而另发一个HTTP 请求。这种情况下,底层的TCP连接将不会再保持,因为响应内容还在等待被读取,socket 连接未清理,不能被重用。应用可以在捕获IOException 以后调用HttpURLConnection.getErrorStream() ,读取响应内容然后关闭流。但是现存的应用没有这么做,不能体现出长连接的优势。为了解决这个问题,介绍下workaround。

当响应体的状态码大于或等于400的时候,workaround 将在一定时间内缓存一定数量的响应内容,释放底层的socket连接来重用。基本原理是当响应状态码大于或等于400时,服务器端会发送一个简短的响应体来指明连接谁以及如何恢复连接。

Several new Sun implementation specific properties are introduced to help clean up the connections after error response from the server.

The major one is:

sun.net.http.errorstream.enableBuffering=<boolean>
default: false

With the above system property set to true (default is false), when the response code is >=400, the HTTP handler will try to buffer the response body. Thus freeing up the underlying socket connection for reuse. Thus, even if the application doesn’t call getErrorStream(), read the response body, and then call close(), the underlying socket connection may still be kept-alive and reused.

The following two system properties provide further control to the error stream buffering behavior:

sun.net.http.errorstream.timeout=<int> in millisecond
default: 300 millisecond

sun.net.http.errorstream.bufferSize=<int> in bytes
default: 4096 bytes

下面介绍一些SUN实现中的特定属性来帮助接收到错误响应体后清理连接:
主要的一个是:
sun.net.http.errorstream.enableBuffering=<布尔值>
默认: false

当上面属性设置为true后,在接收到响应码大于或等于400是,HTTP 句柄将尝试缓存响应内容。释放底层的socket连接来重用。所以,即便应用不调用getErrorStream()来读取响应内容,或者调用close()关闭流,底层的socket连接也将保持连接状态。

下面的两个系统属性是为了更进一步控制错误流的缓存行为:
sun.net.http.errorstream.timeout=<int> in 毫秒
默认: 300 毫秒

sun.net.http.errorstream.bufferSize=<int> in bytes
默认: 4096 bytes

What can you do to help with Keep-Alive?
Do not abandon a connection by ignoring the response body. Doing so may results in idle TCP connections. That needs to be garbage collected when they are no longer referenced.

If getInputStream() successfully returns, read the entire response body.

When calling getInputStream() from HttpURLConnection, if an IOException occurs, catch the exception and call getErrorStream() to get the response body (if there is any).

Reading the response body cleans up the connection even if you are not interested in the response content itself. But if the response body is long and you are not interested in the rest of it after seeing the beginning, you can close the InputStream. But you need to be aware that more data could be on its way. Thus the connection may not be cleared for reuse.

Here’s a code example that complies to the above recommendation:

你如何做可以保持连接为连接状态呢?
不要忽略响应体而丢弃连接。这样会是TCP连接闲置,当不再被引用后将会被垃圾回收器回收。
如果getInputStream()返回成功,读取全部响应内容。如果抛出IOException ,捕获异常并调用getErrorStream() 读取响应内容(如果存在响应内容)。

即便你对响应内容不感兴趣,也要读取它,以便清理连接。但是,如果响应内容很长,你读取到开始部分后就不感兴趣了,可以调用close()来关闭流。值得注意的是,其他部分的数据已在读取中,所以连接将不能被清理进而被重用。

下面是一个基于上面建议的代码样例:

If you know ahead of time that you won’t be interested in the response body, you should issue a HEAD request instead of a GET request. For example when you are only interested in the meta info of the web resource or when testing for its validity, accessibility and recent modification. Here’s a code snippet:

如果你预先就对响应内容不感兴趣,你可以使用HEAD 请求来代替GET 请求。例如,获取web资源的meta信息或者测试它的有效性,可访问性以及最近的修改。下面是代码片段:

 

 

转自:http://www.blogjava.net/xjacker/articles/334709.html

window.open 模拟模态窗口效果

在Web软件开发过程中,经常会需要弹出一个窗口,并且在子窗口和父窗口之间通信,并且子窗口要能锁住父窗口。比较常见的是window.showModalDialog(),这种方法有很多局限性,比如窗口之间的通信不方便,只在ie下有效等。如果采用window.open()的方式,子窗口又不能锁住父窗口。网上有许多通过层来屏蔽父窗口的例子,但是也都没能完全锁定父窗口。经过考虑,楼主我决定采用一种变通的办法:锁定父窗口-> 阻止父窗口获得焦点->当父窗口获得焦点时,将焦点转移到子窗口。

代码如下:

父窗口网页parent.html:

子窗口网页 child.html:

>> 楼主用firefox试下,不管用,锁定不住父窗口的

 

转自:http://yyyccc4000.iteye.com/blog/807912

Freemarker method cannot accept object as parameters

I am trying to pass Freemarker HashLiteral to my custom method as follows:

where item without quotes is an object given in ModelAndView. The {“item”: item} is correctly transformed to freemarker.core.HashLiteral$SequenceHash, but I cannot recover it in my method as I get following exception:

This happens even with href method having empty body:

————————-

It’s probably that href is a TemplateMethodModel instead of a TemplateMethodModelEx. The args argument in TemplateMethodModel.exec(args) is a List of String-s, hence FreeMarker tries to convert the value to a string, but it can only do that with string, date or number values. So just change it to TemplateMethodModelEx and then args will be a List of TemplateModel-s and hence accepts all kind of values.

 

转自:http://stackoverflow.com/questions/9483554/freemarker-method-cannot-accept-object-as-parameters#

HTTP协议header头域

HTTP(HyperTextTransferProtocol)是超文本传输协议的缩写,它用于传送WWW方式的数据,关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求,请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行,一个或者多个头域,一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头,请求头,响应头和实体头四个部分。每个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。

通用头域
通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
Cache-Control头域
  Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached,响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下:
Public指示响应可被任何缓存区缓存。
Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。
no-cache指示请求或响应消息不能缓存
no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值,那么客户机可以接收超出超时期指定值之内的响应消息。
Date头域
Date头域表示消息发送的时间,时间的描述格式由rfc822定义。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。
Pragma头域
Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache。在HTTP/1.1协议中,它的含义和Cache-Control:no-cache相同。

请求消息
请求消息的第一行为下面的格式:
MethodSPRequest-URISPHTTP-VersionCRLFMethod表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持,其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息,只是可以在响应时,不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息,可以用于提交表单,向新闻组、BBS、邮件群组和数据库发送消息。
SP表示空格。Request-URI遵循URI格式,在此字段为星号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务器本身。HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。CRLF表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。
典型的请求消息:
GEThttp://class/download.microtool.de:80/somedata.exe
Host:download.microtool.de
Accept:*/*
Pragma:no-cache
Cache-Control:no-cache
Referer:http://class/download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
上例第一行表示HTTP客户端(可能是浏览器、下载程序)通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息,绿色的部分表示通用头部分。
Host头域
Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。
Referer头域
Referer头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址,Referer不能被发送。如果指定的是部分uri地址,则此地址应该是一个相对地址。
Range头域
  Range头域可以请求实体的一个或者多个子范围。例如,
表示头500个字节:bytes=0-499
表示第二个500字节:bytes=500-999
表示最后500个字节:bytes=-500
表示500字节以后的范围:bytes=500-
第一个和最后一个字节:bytes=0-0,-1
同时指定几个范围:bytes=500-600,601-999
但是服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206(PartialContent)返回而不是以200(OK)。
User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。

响应消息
  响应消息的第一行为下面的格式:
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。Status-Code是一个三个数字的结果代码。Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别,Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别,后两个数字没有分类的作用。第一个数字可能取5个不同的值:
1xx:信息响应类,表示接收到请求并且继续处理
2xx:处理成功响应类,表示动作被成功接收、理解和接受
3xx:重定向响应类,为了完成指定的动作,必须接受进一步处理
4xx:客户端错误,客户请求包含语法错误或者是不能正确执行
5xx:服务端错误,服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持,如果存在不支持的响应头域,一般将会作为实体头域处理。
典型的响应消息:
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:”a030f020ac7c01:1e9f”
Content-length:39725426
Content-range:bytes554554-40279979/40279980
上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息,绿色的部分表示通用头部分,红色的部分表示实体头域的信息。
Location响应头
  Location响应头用于重定向接收者到一个新URI地址。
Server响应头
Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释,产品标识一般按照重要性排序。

实体
请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头,但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流,它的编码方式由Content-Encoding或Content-Type定义,它的长度由Content-Length或Content-Range定义。
Content-Type实体头
用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法发送的请求介质类型Content-Range实体头
Content-Range实体头
用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。一般格式:
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如,传送头500个字节次字段的形式:Content-Range:bytes0-499/1234如果一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围,Content-Length表示实际传送的字节数。
Last-modified实体头
指定服务器上保存内容的最后修订时间。

 

转自:http://www.iwms.net/n2030c40.aspx

Java中如何“sublist”一个List

在实际开发过程,我经常用到java.util.List这个类里的一个subList方法,但是使用过程中(web开发),却发现这样一个问题:分割list没有达到我的预期,示例代码如下:

打印出来是一条数据,但是如果将这个反映到页面,确发现还是6条数据,于是进行dubug操作,发现原来list中的数据其实都还在

没处理前:

处理后:

查询了JDK帮助文档,发现这么一句话

The returned list is backed by this list, so non-structural changes in the returned list are reflected in this list, and vice-versa.

也就是说,其实sublist后的list结构并没有像我所想的是分割完之后的list,还是原来的。

解决方法:

在分割后重新new ArrayList<Person>,这样返回的list就是分割数据后的list。

 

转自:http://www.cnblogs.com/wentiertong/archive/2011/03/07/1973459.html

JexcelApi和POI导入Excel日期识别成数字的解决方案

用过Jxl或者POI导入Excel信息的朋友应该都遇到过这样的问题。日期格式的单元格有些会识别成数字单元格。(为什么说有些呢?因为在Excel文件中输入2008-3-18的日期可以正确导入,但是输入3-18的就会识别成数字。)关于这个问题我找了很久,都没有找到解答。现在解决了,所以记录以下,一是怕以后忘了,二是希望遇到这个问题的朋友可以少走弯路。

首先来分析一下这个问题的成因。既然两个开源包都有同样的问题,说明可能是Excel内部就是这样存储的。所以需要通过一些其他的方式来从NUMERIC Cell中把这些日期找出来。

有两种方式可以辨别NUMERIC Cell储存的是否是日期:

方法一:如果用的是POI,可以直接用HSSFDateUtil.isCellDateFormatted(cell)这个方法。

方法二:如果用的是Jxl,可以将cell.getCellFormat 强制转换成 XFRecord。然后判断XFRecord.formatIndex 如果等于 58就是DateCell

得到的这个double不能直接拿来用。转换可以用HSSFDateUtil.getJavaDate(double date)这个方法。

 

转自:http://blog.csdn.net/qianling3439/article/details/3998861

修改sequence的nextval的值

在oracle数据库中建立sequence,通过sequence.nextval来生成表的主键值,防治主键冲突。但有的时候需要往表中导入一些额外的数据(比如老系统数据),这时候sequ.nextval产生的值可能会与表中的主键值产生冲突。

解决方法可以参考如下方法:

假设现有表 T_test 对应主键的sequence为seq_test_id

方法一:删除序列seq_test_id,然后重新新建序列seq_test_id,将新序列seq_test_id的start with值改为一个合适的num

方法二:执行如下sql

alter sequence seq_test_id increment by num;(num为一个合适的不会造成主键冲突的数字)

select seq_test_id.nextval from dual;

alter sequence seq_test_id increment by 1;
转自:http://blog.csdn.net/myprogramer/article/details/6256800

java List.subList方法中的超级大陷阱

在使用集合中,可能常常需要取集合中的某一部分子集来进行一下操作,于是subList这个方法就映入我们的眼帘,毫不犹豫地使用。

例如以下代码:

代码初步写好后,可能我们想达到的效果是:往集合lists的子集合tempList中添加一个元素6,而原有的集合保持不变。

即到达这样的效果:lists = [1, 2, 3, 4],tempList = [3, 4, 6]。但是我们看到实际的结果确是lists里边也添加了元素6。

这是怎么一会事呢,通过查找java原代码我们可以看到:tempList的subList实现代码在AbstractList类里边,然而无论如何,最终的结果都是返回一个AbstractList的子类:SubList(该类是一个使用默认修饰符修饰的类,其源代码位于AbstractList.java类文件里边),

SubList类的构造方法:

里边,将我们原有的list对象给缓存到SubList类对象的一个属性中去了。

而SubList类的add/remove等修改元素的方法中,都使用l进行了操作:

因此,当我们使用子集合tempList进行元素的修改操作时,会影响原有的list集合。所以在使用subList方法时,一定要想清楚,是否需要对子集合进行修改元素而不影响原有的list集合。

如果需要对子集合的元素进行修改操作而不需要影响原集合时,我们可以使用以下方法进行处理:

 

转自:http://blog.csdn.net/lianggeblog/article/details/7267449

模态窗口中使用window.open可能造成session丢失

在IE6中,如果在A.jsp中使用window.showModalDialog()打开B.jsp,并在B.jsp中使用window.open()打开C.jsp,这时session数据可能会丢失。

解决的方法有两种:

1.在A.jsp执行showModalDialog(),方法时,将A的window对象通过参数传到B.jsp。

window.showModalDialog(URL, Awindow, …..);

之后,在B.jsp中使用Awindow打开C.jsp。

var win = window.dialogArguments;

win.open(…..);

2.B、C两个页面都使用showModalDialog来打开。

在不同的情况下可以选择适合的方法,模态窗口的这个问题在IE8+的版本中好像已经解决了(IE7没测试),但IE6还有不少人在用,因此遇到这种情况时需要注意测试环境。

 

转自:http://www.haogongju.net/art/120820