JDBC 是java编程中一系列允许简单连接到很多数据库（特别是关系型数据库）编程APIs . In Java 2 Platform, Standard Edition (J2SE) 5.0,
JDBC API 由两个包定义:

java.sql ：提供java访问处理贮存在数据源（特别是关系型数据库）中的数据，有最基础常用的对象如Connection, ResultSet, Statement, and PreparedStatement。这个包j2se 和j2ee平台都可使用。

javax.sql：提供java访问处理服务器端数据源。这个包给j2ee提供服务，如DataSource 和RowSet。

ODBC bridge是以ODBC标准 C API 方式实现JDBC 的库。

简而言之，JDBC是一个和database-independent 的访问数据库的API。

DriverManager是唯一可以创建数据库连接的类。DriverManager根据各个厂商（如Oracle, MySQL, and Sybase）提供的驱动创建数据库。

What Is ODBC ？

  Open Database Connectivity (ODBC) 是一种来自微软的编程接口，他为Windows应用程序访问网络上数据库提供了通用语言。 ODBC is a C-based interface
to SQL-based database systems. It provides a consistent interface for communicating with a database and for accessing database metadata (information about the database system vendor and how the tables, views, and data are stored).ODBC作为标准出现。厂商为各自的DBMS提供了各种的驱动或bridges。从java客户端访问ODBC-based数据库，可以使用JDBC-ODBC bridge，因此可以使用JDBC-ODBC bridge访问支持ODBC的数据库，比如Microsoft Access。微软为他的操作系统提供ODBC driver manager。ODBC driver manager协调访问ODBC驱动和对应的数据源。

问题：如果用c++写数据库客户端，你不得不在另一平台重新写客户端；PC版的不能在Macintosh上运行。两个原因：1.c++不是跨平台的，很多东西没有特别指定（如int型用多少位表示）2 更重要的是，想网络访问，GUI框架库等在各个平台不同。ODBC的另一个问题是，接口复杂学习时间长。JDBC去除了这些问题，为访问关系数据库引入平台无关的解决方案。因为性能问题和缺少事务支持, JDBC-ODBC bridge 驱动只适合实验用或没有其他可选方法。

What Is a JDBC-ODBC Bridge?

   简而言之，JDBC-ODBC bridge通过大多数ODBC驱动来提供JDBC访问。它是一个把JDBC操作转换为ODBC操作的JDBC驱动。（ODBC操作是由 C-based libraries实现的——ODBC功能仍然在二进制代码库中；如果数据库或硬件平台更换，需要替换ODBC库）。brige作为sun.jdbc.odbc包实现，包含一个native library用来访问ODBC。sun.jdbc.odbc包在/jre/lib/rt.jar中，包含一个sun.jdbc.odbc.JdbcOdbcDriver类，用来JDBC驱动。注意，JDBC-ODBC bridge是一种“万能”的方式，因此可能比一些特别设计的JDBC驱动慢。

SQL is a Data Manipulation Language (DML—影响数据库对象内容的命令集) and a Data Definition Language (DDL—影响数据库对象结构的命令集).SQL also 提供控制事务命令 (such as commit and rollback)

连接jdbc的过程参考JDBC加载分析 。总之JDBC驱动的作用是提供各种数据库的具体实现(实现了java.sql.Driver接口)，隐藏具体数据库的细节（每个数据库厂商可能会为同一个数据库提供不止一个驱动，这些效率，价格/性能会有不同）。

在fianlly中立刻关闭/释放 JDBC资源(such as the ResultSet, Statement, PreparedStatement, and Connection objects)，而不是等他们自己关闭，会改进应用程序的性能。写一个工具类释放这些资源是一个好办法。

JDBC API主要用来传SQL statement给数据库，但也能读写表格式数据源的数据，这种来自javax.sql.RowSet组接口的读写能力可以被定制去使用更新spreadsheet,flat file 类似表格式数据源的数据。

JDBC有四种类型的驱动连接数据库。

异常：SQLException:有getNextException()可以链接一系列异常，还有很多方法可以展示额外的错误/异常信息。SQLWarning:SQLException的子类，表示非致命可忽略BatchUpdateException:批量更新时出现的错误，除了SQLException提供的信息，还有错误发生前已成功执行多少条数据DataTruncation:意外truancate 数据抛出。

命名服务目的：把命名和对象联系起来，提供用命名访问对象的方法。

目录服务：允许属性和对象联系，比如用户对象的email地址属性，（命名服务不提供），因此能利用目录服务访问对象属性或以属性为基础查找对象。

在tomcat下，我们通常这样来解决中文乱码问题：

过滤器代码：

1. package filter;  
2.   
3. import java.io.*;  
4. import javax.servlet.*;  
5. import javax.servlet.http.*;  
6. import wrapper.GetHttpServletRequestWrapper;  
7.   
8. public class ContentTypeFilter implements Filter {  
9.   
10.     private String charset = "UTF-8";  
11.     private FilterConfig config;  
12.       
13.     public void destroy() {  
14.         System.out.println(config.getFilterName()+"被销毁");  
15.         charset = null;  
16.         config = null;  
17.     }  
18.   
19.     public void doFilter(ServletRequest request, ServletResponse response,  
20.             FilterChain chain) throws IOException, ServletException {  
21.         //设置请求响应字符编码  
22.         request.setCharacterEncoding(charset);  
23.         response.setCharacterEncoding(charset);  
24.           
25.         HttpServletRequest req = (HttpServletRequest)request;  
26.           
27.           
28.         System.out.println("----请求被"+config.getFilterName()+"过滤");  
29.         //执行下一个过滤器（如果有的话,否则执行目标servlet）  
30.         chain.doFilter(req, response);  
31.           
32.         System.out.println("----响应被"+config.getFilterName()+"过滤");  
33.   
34.     }  
35.   
36.     public void init(FilterConfig config) throws ServletException {  
37.             this.config = config;  
38.             String charset = config.getServletContext().getInitParameter("charset");    
39.             if( charset != null && charset.trim().length() != 0)  
40.             {  
41.                 this.charset = charset;  
42.             }  
43.     }  
44.   
45. }  

web.xml中过滤器配置
<!--将采用的字符编码配置成应用初始化参数而不是过滤器私有的初始化参数是因为在JSP和其他地方也可能需要使用-->
 <context-param>
   <param-name>charset</param-name>
   <param-value>UTF-8</param-value>
 </context-param>

 <filter>
  <filter-name>ContentTypeFilter</filter-name>
  <filter-class>filter.ContentTypeFilter</filter-class>
 </filter>

 <filter-mapping>
  <filter-name>ContentTypeFilter</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>

equest.setCharacterEncoding(charset); 必须写在第一次使用request.getParameter()之前，这样才能保证参数是按照已经设置的字符编码来获取。
response.setCharacterEncoding(charset);必须写在PrintWriter out = request.getWriter()之前，这样才能保证out按照已经设置的字符编码来进行字符输出。

通过过滤器，我们可以保证在Servlet或JSP执行之前就设置好了请求和响应的字符编码。

但是这样并不能完全解决中文乱码问题：

对于post请求，无论是“获取参数环节”还是“输出环节"都是没问题的；

对于get请求，"输出环节"没有问题，但是"获取参数环节"依然出现中文乱码，所以在输出时直接将乱码输出了。

原因是post请求和get请求存放参数位置是不同的：

post方式参数存放在请求数据包的消息体中。 get方式参数存放在请求数据包的请求行的URI字段中，以？开始以param=value&parame2=value2的形式附加在URI字段之后。而request.setCharacterEncoding(charset); 只对消息体中的数据起作用，对于URI字段中的参数不起作用，我们通常通过下面的代码来完成编码转换：

 String paramValue = request.getParameter("paramName");
paramValue = new String(paramValue.trim().getBytes("ISO-8859-1"), charset);

但是每次进行这样的转换实在是很麻烦，有没有统一的解决方案呢？

解决方案1: 在tomcat_home"conf"server.xml 中的Connector元素中设置URIEncoding属性为合适的字符编码

这样做的缺点是，同一个tomcat下的其他应用也将受到影响。而其每次部署时都需要类修改配置也很麻烦。

解决方案2:自定义请求包装器包装请求，将字符编码转换的工作添加到getParameter()方法中

package wrapper;

import java.io.UnsupportedEncodingException;
import java.net.URLDecoder;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;

public class GetHttpServletRequestWrapper extends HttpServletRequestWrapper {

    private String charset = "UTF-8";

    public GetHttpServletRequestWrapper(HttpServletRequest request) {
        super(request);
    }

    /** *//**
     * 获得被装饰对象的引用和采用的字符编码
     * 
     * @param request
     * @param charset
     */
    public GetHttpServletRequestWrapper(HttpServletRequest request,
            String charset) {
        super(request);
        this.charset = charset;
    }

    /** *//**
     * 实际上就是调用被包装的请求对象的getParameter方法获得参数，然后再进行编码转换
     */
    public String getParameter(String name) {
        String value = super.getParameter(name);
        value = value == null ? null : convert(value);
        return value;
    }

    public String convert(String target) {
        System.out.println("编码转换之前：" + target);
        try {
            return new String(target.trim().getBytes("ISO-8859-1"), charset);
        } catch (UnsupportedEncodingException e) {
            return target;
        }
    }
}

修改过滤器的doFilter方法 代码如下：

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        // 设置请求响应字符编码
        request.setCharacterEncoding(charset);
        response.setCharacterEncoding(charset);
        // 新增加的代码
        HttpServletRequest req = (HttpServletRequest) request;

        if (req.getMethod().equalsIgnoreCase("get")) {
            req = new GetHttpServletRequestWrapper(req, charset);
        }

        System.out.println("----请求被" + config.getFilterName() + "过滤");
        // 传递给目标servlet或jsp的实际上时包装器对象的引用，而不是原始的HttpServletRequest对象
        chain.doFilter(req, response);

        System.out.println("----响应被" + config.getFilterName() + "过滤");
    }

Web 上最常用的两种 Http 请求就是 Get 请求和 Post 请求了。我们在做 java web 开发时，也总会在 servlet 中通过 doGet 和 doPost 方法来处理请求；更经常地，我们会在 doGet 方法的实现中调用 doPost 方法。尽管做了近两年的 web 开发，我对诸如 Get 请求和 Post 请求的基本概念仍不是十分了解。近日阅读《 javascript 高级程序设计》重新整理了一下 Get 请求和 Post 请求的概念，算是读书笔记吧。

Get 是从服务器上获取数据，这是最常见的请求类型。每次在浏览器中输入 URL 打开页面时，就是向服务器发送一个 Get 请求。 Get 请求的参数是用问号追加到 URL 结尾，后面跟着用＆连接起来的名称／值对。比如网址 http://bt.neupioneer.com/viewthread.php?tid=87813 ，其中 tid 为参数名， 87813 为参数的值。在编程中，使用 Get 最多的地方就是超链接列表，其中的参数多是从数据库读出的字段拼接而成。在 Ajax 中，我们也经常使用 Get ，通过提取出页面的标签值，拼成串后构造一个 URL 。 Get 在使用上是有限制的， URL 的最大长度为 2KB ，因此，如果表单中包含textarea这样的大文本段，就不要用Get了。对于表单来说， Get 是把参数数据队列加到提交表单的 ACTION 属性所指的 URL 中，值和表单内各个字段一一对应，通过 URL 可以看到中传递的参数。因此，相比于 Post ，它是不安全的。

Post 的使用场合多是在表单提交的地方，因为和 Get 相比， Post 可以发送更多的数据，《 javascript 高级程序设计》中说最多可以发送 2GB ，这多少让我不太相信，网上一些文章说 IIS4 中最大量为 80KB ， IIS5 中为 100KB ，不知道 Tomcat 中的情况如何。 Post 是通过 HTTP Post 机制，将表单内各个字段与其内容放置在 HTML Header 内一起传送到 ACTION 属性所指的 URL 地址。 和 Get 相比， Post 的内容是不会在 URL 中显现出来的，这多少是安全一些的。 我在做登录这样的表单时，只是将请求方式设为 Post ，使得用户名和密码信息不在浏览器中显现，但不清楚的是，是否有更好的方法加密密码等信息（实在不知道如果请求不传到服务器的话，怎么对未知的请求加密，清楚的朋友不妨给个解决方案）。在 Ajax 中，如果要和服务器交互，记得加上 request.setRequestHeader(“Content-Type”,”application/x-www-urlencoded”); 这一脚本，尽管很多 Ajax 教材中都提到了这一点。另外要说的是，被传递的参数是要经过编码的。在 javascript 中，编码函数是 encodeURIComponent(xx) 。  
    以上转自 http://blog.csdn.net/yoland/archive/2009/03/19/4005740.aspx
一个get的发送请求例子：
GET /select/selectBeerTaste.jsp?color=dark&taste=malty HTTP/1.1
Host: www.wickedlysmart.com
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/
20030624 Netscape/7.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

CAS 介绍

CAS 具有以下特点：

• 开源的企业级单点登录解决方案。
• CAS Server 为需要独立部署的 Web 应用。
• CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

CAS 原理和协议

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。

在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。

在 Tomcat 上部署一个完整的 CAS Server 主要按照以下几个步骤：

配置 Tomcat 使用 Https 协议

如果希望 Tomcat 支持 Https，主要的工作是配置 SSL 协议，其配置过程和配置方法可以参考 Tomcat 的相关文档。不过在生成证书的过程中，会有需要用到主机名的地方，CAS 建议不要使用 IP 地址，而要使用机器名或域名。（项目过程中没使用）

部署 CAS Server

CAS Server 是一个 Web 应用包，将前面下载的 cas-server-3.1.1-release.zip 解开，把其中的 cas-server-webapp-3.1.1.war 拷贝到 tomcat的 webapps 目录，并更名为 cas.war。由于前面已配置好 tomcat 的 https 协议，可以重新启动 tomcat，然后访问：https://localhost:8443/cas（没配置ssh应该是http://localhost:8080/cas） ，如果能出现正常的 CAS 登录页面，则说明 CAS Server 已经部署成功。

虽然 CAS Server 已经部署成功，但这只是一个缺省的实现，在实际使用的时候，还需要根据实际概况做扩展和定制，最主要的是扩展认证 (Authentication) 接口和 CAS Server 的界面。

参考http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html
项目也采用jdbc验证,文章介绍了三个基于 JDBC 的 AuthenticationHandler，我使用的cas-server 3.3 多了一个AbstractJdbcUsernamePasswordAuthenticationHandler 直接使用。

部署客户端应用

单点登录的目的是为了让多个相关联的应用使用相同的登录过程，使用的是cas-client-core- 3.1.9.jar 放入要使用单点登录项目的lib下。cas客户端使用的是过滤器，在web.xml配置。可以使用spring配置bean。官方网站http://www.ja-sig.org/wiki/display/CASC/Configuring+the+JA- SIG+CAS+Client+for+Java+using+Spring 有配置。
用类扩展 Cas20ProxyReceivingTicketValidationFilter复写onSuccessfulValidation方法，写入验证成功后做的事情，比如把用户信息放入session。写了一个a.jsp用于跳转，过滤器针对他，访问这个页面的时候，会到cas服务器端，如果成功的话，返回到a.jsp，这个页面用sendRedirect调用了一个action方法处理登录成功后直接进入项目首页。

yuxh 2009-11-12 20:57 发表评论

]]>