1、查询系统是否安装了Log4j、log4j-core

find / -name "log4j*.jar" 2>/dev/null
find / -name "log4j-core*.jar" 2>/dev/null

2、如果回显未带版本号

unzip -p /path/log4j.jar META-INF/MANIFEST.MF | grep version

转载请注明：运维博客 » 查看Centos\Euler上Log4j、log4j-core的版本

折腾了好久，最终使用win7系统解决，特此记录一下，以防后期用到。

系统版本：windows_7_enterprise_with_sp1_x64_dvd_u_677685

下载地址：ed2k://|file|cn_windows_7_enterprise_with_sp1_x64_dvd_u_677685.iso|3265574912|E9DB2607EA3B3540F3FE2E388F8C53C4|/

jre版本：jre-7u80-windows-i586.exe

下载地址：https://download.oracle.com/otn/java/jdk/7u80-b15/jre-7u80-windows-i586.exe

转载请注明：运维博客 » 解决web登录华为T8000但是无法进入KVM，jre/jdk/java报错问题。

计算机中储存的信息都是用二进制数表示的，而我们在屏幕上看到的数字、英文、标点符号、汉字等字符是二进制数转换之后的结果。按照某种规则，将字符存储到计算机中，称为编码。反之，将存储在计算机中的二进制数按照某种规则解析显示出来，称为解码。比如说，按照A规则存储，同样按照A规则解析，那么就能显示正确的文本符号。反之，按照A规则存储，再按照B规则解析，就会导致乱码现象。
字符编码Character Encoding:就是一套自然语言的字符与二进制数之间的对应规则。

2.字符集

字符集Charset：也叫编码表。是一个系统支持的所有字符的集合，包括各国家文字、标点符号、图形符号、数字等。
计算机要准确的存储和识别各种字符集符号，需要进行字符编码，一套字符集必然至少有一套字符编码。常见字符集有ASCII字符集、GBK字符集、Unicode字符集等。常见字符集和字符编码对应关系：

由上图得知，当指定了编码，它所对应的字符集自然就指定了，所以编码才是我们最终要关心的。

3.ASCII字符集

ASCII（American Standard Code for Information Interchange，美国信息交换标准代码）是基于拉丁字母的一套电脑编码系统，用于显示现代英语，主要包括控制字符（回车键、退格、换行键等）和可显示字符（英文大小写字符、阿拉伯数字和西文符号）。
基本的ASCII字符集，使用7位（bits）表示一个字符，共128字符。扩展的ASCII字符集，使用8位（bits）表示一个字符，共256字符，方便支持欧洲常用字符。

4.ISO-8859-1字符集

拉丁码表，别名Latin-1，用于显示欧洲使用的语言，包括荷兰、丹麦、德语、意大利语、西班牙语等。
ISO-5559-1使用单字节编码，兼容ASCII编码。

5.GBxxx字符集

GB就是国标的意思，是为了显示中文而设计的一套字符集。
GB2312：简体中文码表。一个小于127的字符的意义与原来相同。但两个大于127的字符连在一起时，就表示一个汉字，这样大约可以组合了包含7000多个简体汉字，此外数学符号、罗马希腊的字母、日文的假名们都编进去了，连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。
GBK：最常用的中文码表。是在GB2312标准基础上的扩展规范，使用了双字节编码方案，共收录了21003个汉字，完全兼容GB2312标准，同时支持繁体汉字以及日韩汉字等。
GB18030：最新的中文码表。收录汉字70244个，采用多字节编码，每个字可以由1个、2个或4个字节组成。支持中国国内少数民族的文字，同时支持繁体汉字以及日韩汉字等。

6.Unicode字符集

Unicode编码系统为表达任意语言的任意字符而设计，是业界的一种标准，也称为统一码、标准万国码。它最多使用4个字节的数字来表达每个字母、符号，或者文字。有三种编码方案，UTF-8、UTF-16和UTF-32。最为常用的UTF-8编码。
UTF-8编码：可以用来表示Unicode标准中任何字符，它是电子邮件、网页及其他存储或传送文字的应用中，优先采用的编码。互联网工程工作小组（IETF）要求所有互联网协议都必须支持UTF-8编码。所以，我们开发Web应用，也要使用UTF-8编码。它使用一至四个字节为每个字符编码，编码规则：

• 128个US-ASCII字符，只需一个字节编码。
• 拉丁文等字符，需要二个字节编码。
• 大部分常用字（含中文），使用三个字节编码。
• 其他极少使用的Unicode辅助字符，使用四字节编码。

转载请注明：运维博客 » 常用的字符集和字符编码

对于线程不安全的集合，应该通过Collections工具类对应的synchronizedXxx方法将其包装成线程安全的集合类。

2.关于集合选用原则

转载请注明：运维博客 » Java中的常见集合特性与数据结构关系、集合选用原则

首先计算机底层是使用二进制存储的，一个二进制叫做位或比特(bit)，8位(bit)叫一个字节(byte)，一个字符占多少字节取决于编码方式，例如查到”李”对应的Unicode十六进制编码是：\u674e。通过计算器换算成二进制：

0110  0111  0100  1110

至此，可以得出的结论是汉字使用Unicode字符集存储应该占两个字节(16位)。

接下来，使用java将其转换成字节数组形式：

byte[] bytes = "李".getBytes("utf-8");
for (byte b : bytes) {
    System.out.println(b);
}
输出：
-26
-99
-114

通过计算器将-26、-99、-114这个三个数字转成二进制：

1110  0110  1001  1101  1000  1110

猛一看，发现这串二进制数字和上面的Unicode对应的二进制数字没有任何相似之处啊，明明网上说法是“UTF-8是Unicode的一种实现方式”，但是这明显没有半毛钱关系啊，我靠，难道网上这些人在胡说，还是我的打开方式不对？？

心想，你两不是没关系吗?那我就把你们硬两放在一起，让你们发生点关系。。。

11100110    10011101    10001110
    0110      011101      001110

这么一分割，貌似还真有点关系了，上网找到如下资料：

Unicode符号范围           |  UTF-8编码方式
(十六进制)                      | （二进制）
—————————————————————–————————————–
0000 0000-0000 007F   | 0xxxxxxx                 #UTF-8规定此范围字符占1字节，首位定死为0。
0000 0080-0000 07FF   | 110xxxxx 10xxxxxx  #UTF-8规定占2字节，高位字节前3位为110，低位前2位为10。
0000 0800-0000 FFFF   | 1110xxxx 10xxxxxx 10xxxxxx  #占3字节，高位字节前3位为1110，后面低位前2位一律为10。
0001 0000-0010 FFFF   | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx #占4字节，高位字节前3位为11110，后面前2位一律为10。

这下再想想“utf-8是一种变长字节编码方式”这句话，说的是这个意思啊。

转载请注明：运维博客 » 为什么一个汉字查出来的Unicode是2个字节(16位)，但UTF-8转出来却是3个字节(24位)？

原因：idea中默认的Language level 使用的是5版本，jdk5是不支持在重写的接口方法上加@Override注解的。

方法一(修改项目配置)

点击idea左上角File–>Project Stucture–>Moudules，将所有模块的Sources的Language level修改到5以上，但是这有个问题，项目自动更新后仍然会恢复到默认值。所以最好使用方法二。

方法二(修改pom文件)

如果项目使用了maven，可以在在pom中增加：

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
</properties>

转载请注明：运维博客 » IDEA报错@Override is not allowed when implementing interface method 解决方法

不少应用服务器（如 Tomcat 和 WebShpere）的类路径中已经包含 Commons Logging，所以在这种配置环境下的 MyBatis 会把它作为日志工具，记住这点非常重要。这将意味着，在诸如 WebSphere 的环境中，它提供了 Commons Logging 的私有实现，你的 Log4J 配置将被忽略。MyBatis 将你的 Log4J 配置忽略掉是相当令人郁闷的（事实上，正是因为在这种配置环境下，MyBatis 才会选择使用 Commons Logging 而不是 Log4J）。如果你的应用部署在一个类路径已经包含 Commons Logging 的环境中，而你又想使用其它日志工具，你可以通过在 MyBatis 配置文件 mybatis-config.xml 里面添加一项 setting 来选择别的日志工具:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration
        PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
    <settings>
        <setting name="logImpl" value="LOG4J"/>
    </settings>
</configuration>

然后在spring核心配置文件中的配置：

<!--MyBatis的SqlSessionFactory-->
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <!--读取mybatis的配置文件-->
    <property name="configLocation" value="classpath:mybaits-config.xml"/>
</bean>

转载请注明：运维博客 » SSM框架整合后，mybatis使用log4j但是控制台不打印SQL执行语句解决办法

最近使用Struts2写了个文件上传，测试时候明明超过大小限制，也在struts.xml中配置了页面，但是就是死活无法跳转至指定input页面问题。浏览器提示连接已重置，折腾了一上午，翻阅了两本参考书，查看了培训机构的视频，一步一步照着仔仔细细的做，还是不行，甚至把人家的源码拷贝过来在我的机子上跑，还是不行，把IDEA，tomcat，jdk卸载了重新装……能折腾的都折腾了，还是不行，甚至开始怀疑人生了，哎，上网搜了下，遇到这问题的人还不少，终于找到了根本原因，恍然大悟，特此记录，以此为戒。

2.根本原因

就是tomcat也有默认上传限制，叫maxSwallowSize，默认大小也是2M，如果找超过2M，tomcat会判定是个失败的上传，就会将浏览器请求重置，更不会把这个request再传送到struts2，所以就会出现上述现象。

3.解决办法

修改tomcat的配置文件server.xml(在tomcat目录下的conf里)，找到并修改如下内容：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxSwallowSize="-1" />

maxSwallowSize设置值规则：如果没有指定则为默认值，小于0表示无限制，大于0表示限制为多少字节。

转载请注明：运维博客 » Struts2文件上传超过默认大小限制2M，但无法跳转至指定input页面问题的解决办法

public class GetPath extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        //第1种：获取服务器二进制命令路径
        String path1 = new File("").getCanonicalPath();
        System.out.println("path1:" + path1);

        //第2种：获取服务器二进制命令路径
        String path2 = System.getProperty("user.dir");
        System.out.println("path2:" + path2);

        //第3种：获取项目的根目录
        String path3 = getServletContext().getRealPath("");
        System.out.println("path3:" + path3);

        //第4种：获取项目的根目录,但Servlet2.1以后已过期
        String path4 = request.getRealPath("");
        System.out.println("path4:" + path4);

        //第5种：获取类加载的根路径
        String path5 = Thread.currentThread().getContextClassLoader().getResource("").getPath();
        System.out.println("path5:" + path5);

        //第6种：获取类加载的根路径
        String path6 = this.getClass().getClassLoader().getResource("").getPath();
        System.out.println("path6:" + path6);

        //第7种：获取类加载的根路径
        String path7 = this.getClass().getResource("/").getPath();
        System.out.println("path7:" + path7);

        //第8种：获取当前类的路径
        String path8 = this.getClass().getResource("").getPath();
        System.out.println("path8:" + path8);
    }
}

运行结果：

path1:D:\java\apache-tomcat-8.5.37\bin
path2:D:\java\apache-tomcat-8.5.37\bin
path3:D:\ROOT\
path4:D:\ROOT\
path5:/D:/ROOT/WEB-INF/classes/
path6:/D:/ROOT/WEB-INF/classes/
path7:/D:/ROOT/WEB-INF/classes/
path8:/D:/ROOT/WEB-INF/classes/com/gqzzw/

转载请注明：运维博客 » Java获取各种绝对路径的8种方法

早期的数据库开发领域没有通用的应用程序编程接口，开发人员在使用不同数据库产品时，必须学习和使用厂商专用API。针对业界对通用编程接口的需求，微软推出了ODBC(Open Database Connectivity)方案，并获得厂商和开发人员的认可。ODBC建立了一组规范，并提供了对数据库访问的标准API，后来被X/OPEN和ISO/IEC采纳，作为SQL标准的一部分。

2.JDBC

SUN参考了ODBC，为JAVA设计了专用的数据库连接规范JDBC(JAVA Database Connectivity)。JDBC期望的目标是让Java开发人员在编写数据库应用程序时，可以有统一的接口，无须依赖特定数据库API，达到“ 一次开发，适用所有数据库”。

3.JDBC驱动程序

然后数据库厂商去写代码来实现JDBC中的接口，再把这些实现类打成jar包，称之为“JDBC驱动”。驱动程序按工作方式分为下面四种类型。

4.JDBC-ODBC Bridge Driver

SUN发布JDBC规范时，市场上可用的JDBC驱动程序并不多，但是已经逐渐成熟的ODBC方案使得通过ODBC驱动程序几乎可以连接所有类型的数据源。所以SUN发布了JDBC-ODBC的桥接驱动，利用现成的ODBC架构，将JDBC调用转换为ODBC调用，避免了JDBC无驱动可用的尴尬。不过，由于桥接的限制，并非所有功能都能直接转换并正常调用，而且多层调用转换对速度也有不小的影响，除非没有其他解决方案，否则不应采用桥接架构。

5.Native API Driver

这类驱动程序会直接调用数据库提供的原生链接库或客户端，因为没有中间过程，访问速度通常表现良好。但是驱动程序与数据库和平台绑定，无法达到JDBC跨平台的基本目的。在JDBC规范中也是不被推荐的选择。

6.JDBC-Net Driver

这类驱动程序会将JDBC调用转换为独立于数据库的协议，然后再通过特定的中间组件或服务器转换为数据库通信协议，主要目的是为了获得更好的架构灵活性。例如更换数据库时可通过更换中间组件实现。由非数据库厂商开发的Type 3驱动通常还提供额外的功能，例如高级安全特性等，但通过中间服务器转换也会对速度有一定影响。JDBC领域这种类型驱动并不常见，而微软的ADO.NET是这种架构的典型。

7.Native Protocol Driver

这是最常见的驱动程序类型，我们开发中使用的驱动jar包基本都属于此类，通常由数据库厂商直接提供，例如mysql-connector-java，驱动程序把JDBC调用转换为数据库特定的网络通信协议。因为使用网络通信，驱动程序可以纯Java实现，支持跨平台部署，性能也较好。

转载请注明：运维博客 » JDBC的四类驱动程序(JDBC-ODBC桥、本地API、JDBC网络、本地协议)