/u/monupload虽然没有提供很多API,但是它有比较灵活,它上传的过 程中会把上传的文件先写入磁盘,所以上传的大小只是带宽有关系,我尝试最大的上传文件的大小是700M,当然是本地测试:>

还有是就是在Linux/Unix系统上传文件的中文问题,我在下面的代码有了一些解决.

下面是前两种方式的上传代码:

int pid = 等等语言都实现了该标准， 成为了应用最为广泛的 XML 处理方式。当然，为了能提供更多更加强大的功能，Java 对于 DOM 直接扩展工具类有很多，比如很多 Java 程序员耳熟能详的 JDOM，DOM4J 等等， 它们基本上属于对 DOM 接口功能的扩充，保留了很多 DOM API 的特性，许多原本的 DOM 程序员甚至都没有任何障碍就熟练掌握了另外两者的使用，直观、易于操作的方式使它深受广大 Java 程序员的喜爱。

　　绿色环保的 SAX

　　SAX 的应运而生有它特殊的需要，为什么说它绿色环保呢，这是因为 SAX 使用了最少的系统资源和最快速的解析方式对 XML 处理提供了支持。 但随之而来繁琐的查找方式也给广大程序员带来许多困扰，常常令人头痛不已，同时它对 XPath 查询功能的支持，令人们对它又爱又恨。

　　Digester 是 apache 基金组织下的一个开源项目，笔者对它的了解源于对 Struts 框架的研究，是否有很多程序员想要一解各大开源框架的设计甚至想要自己写一个功能强大的框架时会碰到这样一个难题： 这些形形色色的用 XML 语言标记的框架配置文件，框架底层是用什么技术来解析呢？ DOM 解析耗费时间，SAX 解析又过于繁琐，况且每次解析系统开销也会过大， 于是，大家想到需要用与 XML 结构相对应的 JavaBean 来装载这些信息，由此 Digester 应运而生。它的出现为 XML 转换为 JavaBean 对象的需求带来了方便的操作接口，使得更多的类似需求得到了比较完美的解决方法， 不再需要程序员自己实现此类繁琐的解析程序了。与此同时 SUN 也推出了 XML 和 JavaBean 转换工具类 JAXB，有兴趣的读者可以自行了解。

　　优缺点：实现 W3C 标准，有多种编程语言支持这种解析方式，并且这种方法本身操作上简单快捷，十分易于初学者掌握。其处理方式是将 XML 整个作为类似树结构的方式读入内存中以便操作及解析，因此支持应用程序对 XML 数据的内容和结构进行修改，但是同时由于其需要在处理开始时将整个 XML 文件读入到内存中去进行分析，因此其在解析大数据量的 XML 文件时会遇到类似于内存泄露以及程序崩溃的风险，请对这点多加注意。

　　适用范围：小型 XML 文件解析、需要全解析或者大部分解析 XML、需要修改 XML 树内容以生成自己的对象模型

　　SAX 从根本上解决了 DOM 在解析 XML 文档时产生的占用大量资源的问题。其实现是通过类似于流解析的技术，通读整个 XML 文档树，通过事件处理器来响应程序员对于 XML 数据解析的需求。由于其不需要将整个 XML 文档读入内存当中，它对系统资源的节省是十分显而易见的，它在一些需要处理大型 XML 文档以及性能要求较高的场合有起了十分重要的作用。支持 XPath 查询的 SAX 使得开发人员更加灵活，处理起 XML 来更加的得心应手。但是同时，其仍然有一些不足之处也困扰广大的开发人员：首先是它十分复杂的 API 接口令人望而生畏，其次由于其是属于类似流解析的文件扫描方式，因此不支持应用程序对于 XML 树内容结构等的修改，可能会有不便之处。

　　适用范围：大型 XML 文件解析、只需要部分解析或者只想取得部分 XML 树内容、有 XPath 查询需求、有自己生成特定 XML 树对象模型的需求

　　优缺点 : 由于其是在上述两者的基础上衍生出来的工具类，为的是满足将 XML 转换为 JavaBean 的特殊需求，故而没有什么特别明显的优缺点。作为大名鼎鼎的开源框架 Struts 的 XML 解析工具 Digester，为我们带来了将 XML 转换为 JavaBean 的可靠方法。

在javaIO中，文件的查询和删除，文件的复制程序如下：

在建立线程时，有两种方式，1是继承java.lang.Thread类，重写run方法，此方法用于你想让线程干的事，在调用此方法时，不能直接调用run方法，要调用start方法，如果想访问此线程，使用Thread.currentThread()方法。2，是实现Runnable接口，在调用时，因为接口没有start方法，所以要先创建出实现类的的对象， 再创建出Thread的对象，把实现类的对象传入Thread的对象的构造方法中，再用Thread的对象调用start（）方法。

线程有生命周期的，新建 ，就绪，运行，死亡。新建以后只有调用start方法才处于就绪队列，处于就绪队列的线程在获得处理机资源后处于运行，在运行过程中，如果调用sleep方法，或IO阻塞例如Scanner输入，或等待同步锁，或等待通知时就处于阻塞，这是释放处理机资源，在sleep时间到，或IO方法返回，或获得同步锁，或受到通知后，处于就绪队列，线程在run执行完成，或Error，或exeception时，就死亡。可以调用stop方法让线程死亡，但是禁止使用，可以使用isAlive方法判断线程是否死亡，该方法在线程处于就绪，运行，阻塞时返回true，处于新建和死亡时返回false，线程一旦死亡，不能再次调用start方法让线程重新执行。

当一个程序在执行中被另外一个线程插队，并且后来的线程需要先执行完后原来的线程才能执行，就要让插队线程先调用start方法，再调用join方法，进行插队。

守护线程就是在主线程死亡后，守护线程也随之死亡，在使用时让守护线程的对象先调用setDaemon(true)方法，再调用start方法。

当多个线程同时对同一个对象的实例属性进行操作时，会引起线程的同步问题，为了消除线程的同步，可用synchronized来修饰有可能引起线程同步的方法，也可用用synchronized(this)

{方法代码} ，设置同步代码块，在JDK1.5以上的版本可使用同步锁来操作，具体做法是：

三．释放连接时对象的顺序不能变，释放的顺序和创建对象的顺序相反

四．如果操作的事本地的数据库，在连接数据库时，有三种方法

五．如果不知道数据库列的数据类型，可以通过这三步在控制台上查看

一．在java中的异常中，Throwable类有两个子类，Error和Exception，在Exception类中有两个子类，RuntimeException(运行时异常)和非运行时异常，运行时异常是指只有在运行时才会报错的异常，不会编译错，但是非运行时异常是会编译错的，在运行前就报错了。

二．在cry {语句1}catch（Exception e）{语句2}finally{语句3}语句中，语句1放的是可能会发生异常的语句，语句2放的是发生异常后执行的语句，语句3放的是一定会执行的语句，不管有异常没有，

三。PrintStackTrace()方法用于输出有关的异常信息，包括异常的原因，以及该异常发生在类的第几行代码中，getMessage()方法用于返回异常相关的详细信息，但是无法跟踪到具体的行。

四．在自定义异常中，如果是继承自Exception类时，有两种方法处理

1.在有可能发生异常的方法中，在这个方法名后利用throws跑出自定义异常，

在对象调用此方法的时，需要对象自己利用try  catch语句处理此方法

2在有可能发生异常的方法中，自己利用try  catch语句处理异常，在对象调用此方法时，不在需要对象自己利用try  catch语句处理此方法，直接调用方法就可以

五．在自定义异常中，如果继承自RuntimeException类时，在对象调用此方法的时，需要对象自己利用try  catch语句处理此方法。

一．在内连接中的等值连接中，适用于两个表，且两个表中都有共同的一项，根据这一项来连接两表中其他的项，但是如果不在where中约束两表中共同的一项相等，会产生笛卡尔积。

三．只要是几个表的连接查询，都要在其中直接连接的两个表中找到相同的项，作为纽带，查询其他的列。

四．表之间的关系包括1对1,1对多，多对多，其中1对1 时比如建立人的表和身份证表，他们是1对1的，在建立身份证表时，表的id号不是自动增长的，并且id即使身份证表的主键，也是人表的外键，也就是说id不但不能重复，还要一定时人表中存在的，1对1的。

在1对多时，比如人表和银行卡表，一个人可以有多个银行卡，但是一个银行卡只能属于一个人，所以把人的id放在银行卡表中，作为人表的外键，也就是说，在1对多时，在多的表中存放1的主键。

在多对多时，比如学生表和课程表，一个学生可以选多个课，一个课可以有多个学生上课，这就是多对多的情况，需要建立第三张关系表，在关系表中包括学生表和课程表的俩主键，这俩主键也是关系表的主键

在mysql中，group by 分组后，可用sun（）来计算每组的莫一列的内容和，比如价格总额，数量总额，count（）是用来计算列的个数和，不是内容和，

在子查询中又是可以把子查询分解为几个单表查询，最后再整合在一起

customers;中是先在customers表中拿到第一个cust_id 带到小括号里进行比对，如果有相同的就计算总和，没有相同的为0，以此类推，最后算出结果,。