=====================================
jsp自定义标签概述
JSP自定义标签（有些书籍中称为JSP标签扩展）可以看成是一种通过用户编写的标签处理器（实现特定接口的Java类）生成基于XML的脚本的方法。从概念上讲，标签就是很简单而且可重用的代码结构。

一般处理相似任务的若干个自定义标签会被打包为一个JAR文件，作为一个标签库来使用。

使用自定义标签的好处：

1、逻辑与显示的分离。
在没有使用自定义标签之前，我们一般使用scriptlet来进行逻辑处理。使用scriptlet可以快速编码，但随之而来的一个弊端就是逻辑与显示混杂在一起，从长远来看，这并不是一种好的解决方案。而自定义标签则能够将逻辑与显示分离，为项目带来了长期的收益。

2、代码可重用
自定义标签很容易从一个JSP项目迁移到其他项目。一旦建立了一个标签库，则只需要将所有的东西打包为一个JAR文件，你就可以在任何的JSP项目中重新使用。
　
3.可以对JSP进行无限扩展
标签库可以具备JSP规范(JSP 1.2)中的任何特性和功能，你可以无限制地扩展和增加JSP的功能，而无需要等待下一版本JSP的出现。例如，你对JSP的include调用不太满意。你可以建立自己的include标签，该标签执行的是你自己的规范。 More …

=====================================
前言
jsp的9个内置对象中，request对象和response对象是最常用的，需要掌握的东东也相对多一些，于是分别单独作了一些笔记，其他的7个内置对象则在此简单记录一下，有了大致了解就OK了。

request对象学习笔记：
http://www.darkmi.com/blog/archives/1024

response对象学习笔记：
http://www.darkmi.com/blog/archives/1025

=====================================
out对象
out对象的类型是javax.servlet.jsp.JspWriter，该类从java.io.Writer类派生，以字符流的形式输出数据。out对象实际上是PrintWriter对象的带缓冲的版本（在out对象内部使用PrintWriter对象来输出数据），可以通过page指令的buffer属性来调整缓冲区的大小，默认的缓冲区是8kb。

JspWriter抽象类的API帮助文档地址：
http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/jsp/JspWriter.html

out对象的主要方法如下：
（1）print()、及println()
输出数据，包括对各数据类型进行支持的重构方法。是out对象最常用的方法。

同print()相比，println()函数会多输出一个换行符，不过换行的效果是针对生成的html源代码，而在页面显示上是看不到换行效果的。想要在页面上换行可以这样做：

out.println(“
“);

More …

=====================================
JSP编译指令概述
编译指令的英文原话是“directive”，原意是“指示、命令”的意思。在一些java技术书籍中将其称翻译为“伪指令”，也有将其翻译为“编译指令”的，我个人更习惯叫编译指令。只要知道都是指的“directive”就OK了。

JSP的编译指令是通知JSP引擎的消息，它不直接生成输出。编译指令都有默认值，因此开发人员无须为每个指令设置值。

常见的编译指令有3个：

page：该指令是针对当前页面的指令。

include：用于指定包含另一个页面。

taglib：用于定义和访问自定义标签。

使用编译指令的语法格式如下：

<%@ 编译指令名 属性名="属性值"…%>

===================================== More …

response对象
response对象包含了响应客户端请求的有关信息，但在JSP中很少直接用到它。它是HttpServletResponse的实例。

(1)String getCharacterEncoding()
返回响应用的是何种字符编码，该输出同page编译指令的pageEncoding是相关的。

<%@ page language="java" pageEncoding="GBK"%>





<% System.out.println(response.getCharacterEncoding()); %>

输出为：

GBK

如果将pageEncoding修改UTF-8，那么输入则为UTF-8。

(2)ServletOutputStream getOutputStream()
返回响应的一个二进制输出流

(3)PrintWriter getWriter()
返回可以向客户端输出字符的一个对象

(4)void setContentLength(int len)
设置响应头长度

(5)void setContentType(String type)
设置响应的MIME类型

(6) sendRedirect(java.lang.String location)
重新定向客户端的请求

request对象
request对象封装了客户端的请求信息，服务端通过request对象可以了解到客户端的需求，然后做出响应。request对象是HttpServletRequest(接口)的实例。HttpServletRequest接口继承自ServletRequest接口，只是增加了一些HTTP相关的方法。所谓的request（在JSP中使用的）其实只是规范中的一个名称而已，它是一个对象，但并不是由SUN提供，而是由各个不同的Servlet提供商编写的，SUN只是规定这个类要实现HttpServletRequest接口，并且规定了各个方法的用途，但具体的实现则由各个提供商自己决定。

request对象的主要方法：

(1)setAttribute(String name, Object value) 和 getAttribute(String name)
前者用来在request中保存一个属性值，后者则返回name指定的属性值，如果指定的属性值不存在，则返回一个null值。这一对方法用来在不同的请求之间传递数据，而且从上一个请求到下一个请求必须是转发请求(forward)，而不能是重定向请求(redirect)。API文档中已经有明确的说明，这两个方法是同RequestDispatcher联合使用的。
More …

=====================================
javaBean简介
模块化的设计思想首先在硬件及电子技术领域中得到广泛应用。通过模块化的设计，电子产品得以在流水线上通过各种标准化零部件进行组装生产。这种思想逐渐延伸及软件领域，就是基于组件的编程技术。在java世界中，javaBean即是其中一种组件技术。

bean的定义很广泛。bean简单的说是满足两项需求的Java类：
（1）它包含一个无参的构造器；
（2）它利用Serializable接口使之可持续。
More …

=====================================
forward指令
forward动作元素将HTTP请求转发至另一JSP页面或servlet进行处理。

forward动作语法格式如下：

在跳转的同时也可以向跳转页面传递参数：




…



More …

=====================================
JSP动作元素概述

jsp文件可以包含JSP元素、固定模板数据或者两者的任意结合。

JSP元素指示JSP容器生成什么代码及操作方式。这些元素有特定的开始和结束标记，使JSP编译器可以对其识别。

模板数据是JSP容器不可识别的所有其他代码。模板数据（通常为HTML）不做修改的加以传递，这样最后生成的HTML就会像在.jsp文件编码中一样准确的包含模板数据。

JSP元素有以下3种：
（1）伪指令；
（2）脚本元素、包含表达式、scriptlet和声明；
（3）动作。

动作元素与伪指令元素不同，伪指令元素是通知Servlet引擎的处理消息，而动作元素只是运行时的脚本动作。伪指令在将JSP编译成Servlet时起作用；而动作元素通常可替换成JSP脚本，是JSP脚本的标准写法。

在所有JSP1.1的兼容环境中，可以利用的标准行为有7种，include行为用来包含一个静态的或者动态的文件。
More …

手头有一套png格式的表情，想在discuz论坛中使用，无奈discuz论坛的表情符号只支持gif格式，于是需要将这套表情文件批量转为gif格式。

首先想到的是使用工具软件进行格式的批量转换：

批量图片格式转换器
下载地址：http://www.xdowns.com/soft/31/55/2008/Soft_43541.html

非常小巧的一款绿色软件，仅仅22K。不过进行格式转换之后，图像质量会有所下降。于是放弃格式转换，偷一下懒，直接把表情符号的后缀改为gif。

打开CMD窗口，进入表情所在目录，使用如下命令：

rename *.png *.gif

批量更改后缀完毕，将表情文件上传至服务器，这次discuz终于识别出这些表情符号了，搞定。

以下是一款批量更改文件名的绿色小软件，感兴趣的可以试试：
http://www.xdowns.com/soft/4/144/2009/Soft_56458.html

来自：J道论坛
作者：zhaoping_yu

我对hgwnet老兄的观点颇有同感。我们公司接触使用Struts可以说是比较早了（大概是从Struts刚推出不久就开始了）。当时Struts也比较轻型，其对MVC的实现确实给我们WEB项目的开发带来很大的方便。但Struts后继版本的发展，我们对其的使用反而越来越不方便了、代价越来越高。首先是Struts本身越来越庞大，原因是它想包含的功能越来越全（如果只是扩展表现层必须的功能也就罢了，可它为什么把数据库等有关的功能也考虑进去啊（我当时用的版本是这样的，其最新的版本是不是还考虑，我没有考察）），导致我们的WEB应用越来越慢，员工的学习曲线越来越陡。它提供了那么多TAG，我们大部分用不到，而且我们需要的它又没提供（或至少不是太对口）。于是我们公司就根据Struts实现MVC的原理实现了自己的MVC框架，它只考虑实现了MVC最基本的东西，相关的代码才十几K，用它替换原先的Struts后，经过相关测试，给我的感觉就象一个人脱掉笨重的外套一样。后来我们公司就一直用这个框架，也没发现对其还有太多的扩展需求。由于这个框架对我们公司来说已经够用了，在Struts后面出现的其他MVC模式框架，我们公司也没有对它们进行跟踪使用。 More …