文本浏览器

将Tomcat、MySQL从Linux迁移到Windows的心路历程(干货):令人恐惧的字符编码

发布者 : 管理员-Adler | 发布时间 : 2019-05-07 22:58:57
文章号 : 47 | 阅读量 : 0+1 | AAW值(?) : 3.00 (仅供参考)

 

前言

近日打算对服务端进行进一步的解耦,便购入了云数据库服务,将数据库独立,使得Tomcat主机独立运行,提高安全性和便利性。
心血来潮,想将服务器重装为Windows,便有了下面的一系列文章:

迁移MySQL

平时我都是使用Navicat对MySQL进行管理。在备份的第一时间我便想到了使用Navicat进行数据的迁移。

Dump SQL File



右键指定的数据库,选择Dump SQL File -> Structure + Data就可以将选定数据库全部的结构、参数、表、键值保存到一个文件中,我将其输出到桌面以便恢复。

Execute SQL File

登录到新的数据库中,并建立一个名称相同的数据库。右键该数据库,选中Execute SQL File



为什么要迁移

比对Windows和Linux的区别,对我而言:

Linux(Ubuntu 16.04)

优点

  1. 占用内存小
  2. Terminal用起来太爽
  3. 开源
  4. 安装工具方便(apt)
  5. ......

不足

  1. 不知道,别问我

Windows (Windows Server 2016)

优点

  1. 桌面环境比较成熟
  2. 文件权限划分清晰严谨
  3. 图形界面进行编辑(学不会Vim)、服务安装配置比较快捷

不足

  1. 内存占用太高,开机就2G
  2. ......

迁移前我做的规划

  1. 将Tomcat服务端打包,备份到本地
  2. 安装Java并配置环境变量
  3. 用IIS配置FTP服务
  4. 将Tomcat服务端上传,并运行测试
  5. 配置防火墙,禁止一大堆自带的服务监听端口

我遇到的问题

1. 控制台中文乱码

遇到这个问题的时候,我还是不慌的,在我的意料之内。
在查找资料后,我找到了解决办法:
conf/logging.properties文件中,添加下面一行(先检查是否已经存在,如果已经存在直接修改即可):
java.util.logging.ConsoleHandler.encoding = GBK

这是因为Windows的控制台编码为GBK,而Linux的终端编码一般为UTF-8而导致的。

2. ​​​HTML中文乱码

这可真是令人手忙脚乱了... JSP和Servlet都是正常的,但HTML的中文却是乱码。排除法:
√ HTML头部设置了<meta charset="utf-8"/>
√ HTML源文件编码经检测为UTF-8
√ web.xml拦截器编码设置为UTF-8
? 问题可能出在Tomcat的配置

—— 再次经过几经查找,我找到了两种解决方法:

方法一:server.xml

编辑conf/server.xml文件,在Connector后边追加参数URIEncoding="UTF-8"

由于我开启了SSL,所以在port443的后方加入。如果你没有使用HTTPS而只是使用了HTTP,那么找到port80的后方加入即可。

方法二:catalina.sh

编辑bin/catalina.sh文件:

找到JAVA_OPTS并追加参数:
-Dfile.encoding=utf-8

通过这条参数,我们可以从根源(JVM)处告诉Tomcat,要以UTF-8的编码来读取文件。

最后,通过方法二(推荐都使用)解决了HTML中文乱码的问题。

3. APR模式不可用

经常使用Tomcat的小伙伴可能知道APR模式。

Tomcat的三种模式

模式 描述 性能
BIO Blocking I/O 阻塞式I/O操作,表示Tomcat使用的是传统的Java I/O操作。
NIO Non-Blocking I/O 基于缓冲区,并能提供非阻塞I/O操作的Java API。
APR Tomcat将以JNI的形式调用Apache HTTP服务器的核心动态链接库来处理文件读取或网络传输操作,从而大大地提高Tomcat对静态文件的处理性能。
在Linux,我一直使用APR模式来运行Tomcat服务端,但这次有些不对劲儿。

JAVA_OPTS可能与APR模式冲突

由于APR模式需要安装额外的扩展,我便安装并进行了测试,但并没有效果。
在这之后,我尝试了:
  1. 使用安装版Tomcat并勾选APR扩展
  2. 重新生成配置文件
  3. 重新生成并导入域名SSL证书
  4. 查找可能导致冲突的配置
最终的一个现象:
一旦我开启APR模式,HTTPS就无法访问。
在一个下午的苦苦挣扎后,我找到了问题所在:

一旦为JAVA_OPTS添加参数-Dfile.encoding=utf-8,APR模式就无法正常工作。

为什么不直接将所有文件转码为GBK?

其实我本可以直接将所有的页面文件转码为GBK(Windows的默认编码)从而直接防止上述所有情况的发生,但过程复杂,且一旦需要迁移回Linux非常繁琐
所以最后,我放弃了APR,使用无需额外扩展及配置的NIO模式:
编辑conf/server.xml

修改protocol的参数为
org.apache.coyote.http11.Http11NioProtocol

后语

总的来说,除了在文件编码方面略有困难之外,在提前做好充足功课之后还是能够迁移成功的。
生命在于折腾。
(如果事事都能像自己预想的那样运行,谁还愿意瞎折腾呢?)

如转载请在文章尾部添加

原作者来自AdlerED个人技术博客:blog.stackoverflow.wiki






评论加载中...

+ 参与讨论