J2EE初步，第一次接觸的那些亂碼問題

J2EE初步，第一次接觸的那些亂碼問題

    本學期初次接觸《J2EE技術》這門課程，雖然本身的方向並非Java Web方向，可是沒辦法，仍是要花費不少的時間去探索。固然，首先遇到的就是各類噁心的亂碼問題，字母系語言的程序員應該不會遭遇這些迷惑吧！      最開始的是jsp文件是UTF-8編碼的，然而確使用jsp默認編碼iso8859-1，在瀏覽器中打開亂碼！因而，按照之前的經驗在jsp文件中加入」<meta charset=utf-8 />」結果一點用也沒有。原來，頁面編碼的決定權在「pageEncoding="UTF-8"」手上，那個」<meta charset=utf-8 />」寫與沒寫都是同樣的。   

    解決初步問題以後，再次遭遇的亂碼問題是經過jsp表單向Servlet提交數據；起初全是使用英文測試沒在乎，結果使用中文以後，竟然又再次出現噁心的亂碼。而後，在Servlet修改至下面的兩段代碼：

response.setContentType("text/html;charset=UTF-8");request.setCharacterEncoding("UTF-8");

自覺得問題解決以後，趕忙測試一下，結果竟然沒有一點兒的變化。谷歌、必應、百度之，原來要改服務器配置文件。以個人修改成例：進入服務器安裝目錄：apache-tomcat-7.0.37/conf管理員權限編輯server.xml文件，修改內容以下：

<Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8" />

即便是修改過了，但是仍是沒有見到本身想見的中文，看到的又是亂碼字符。後來，貌似又能夠了；而後又不在乎間又出現亂碼。這讓我糾結了好長的一段時間。後來，才意識到本身沒有重啓服務器，改過的配置文件沒有立刻生效；還有就是我竟然將response.setContentType("text/html;charset=UTF-8");request.setCharacterEncoding("UTF-8");這兩行代碼寫到request.get...()以後，沒有發揮request.setCharacterEncoding("UTF-8");的做用。

至此，在j2ee方面的亂碼問題算是解決啦！下面遭遇的是mysql數據庫連接亂碼悲劇。

學習《數據庫系統概論》時老師選用的數據庫是Oralce。這個你們夥，貌似那段時間數據庫基礎知識倒黴有學紮實，卻是如何安裝Oracle和PL/SQL軟件花費了一個學期。到Oracle好不容易安裝好了，數據庫課程也結束了。myql以前也接觸過，可是沒有此次這麼細緻。

說明下，我作的小網站頁面使用的默認編碼是UTF-8。首先，我在Mysql數據庫下創建數據庫和表，在Mysql終端插入數據，而後select * from竟然出現亂碼，沒在乎；而後用JDBC訪問讀取數據庫內容。丫的，竟然仍是亂碼。而後再調用Java相關方面的類進行轉碼。嗯，顯示中文了！但是，這樣就不自在了，明明能夠直接在數據庫中讀取內容，而後進行增、刪、改、查的操做便可，爲啥非要進行轉碼操做呢？這不是浪費資源麼？要是有數百萬的數據，光轉碼操做都要浪費多少資源呀！查找了許多的資料，而後更改Mysql數據庫配置，改配置文件，設置各類默認編碼爲UTF-8，後來，一切正常。

後來，一切貌似能夠說是正常啦！但是，我又忽視了一點，我全部的測試都是在本機進行的。當我把我作的上傳到遠程服務器時，又出現和上述同樣的數據庫亂碼。可是，當我欲修改數據庫配置文件時，才發現本身的權限不夠。難道，爲了本身的網站去讓管理員更改數據庫配置？那會不會影響別人的數據庫使用呢？最後，本身才意識到數據庫編碼在數據庫建立的時候就要開始注意了。

根據查詢的網上資料，要使用UTF-8編碼，數據庫應該相似於如下的建立方式：

create database tianhuifang default character set utf8 collate utf8_general_ci;

create table iuser(id int primary key auto_increment,name varchar(50) not null,password varchar(50) not null, email varchar(50) unique not null) default charset utf8;

這時，我才意識到本身具有通常程序員不該該具有的壞習慣：遇到困惑，只想着去改變別人的東西，或是埋怨別人的缺陷；卻不肯從本身的源碼開始，嘗試去適應。

這樣建立的數據庫，根本不用去考慮mysql默認的編碼問題。固然，到此也不是最後就再也不出現亂碼了。在使用JDBC連接mysql時，別忘了?characterEncoding=UTF-8這段內容，也就是以下的形式：

DriverManager.getConnection("jdbc:mysql://localhost:3306/ijavame?characterEncoding=UTF-8","root","***");

終於，到最後遇到的困難幾乎都和亂碼無關了！最後，告誡本身：程序員，不要埋怨；有時候，埋怨就是你技術不行，實力不夠。