① utf8不支持java怎麼辦
伺服器端
修改資料庫配置文件/etc/my.cnf
character-set-server=utf8mb4
collation_server=utf8mb4_unicode_ci
重啟MySQL（按照官方文答培檔，這兩個選項都是可以動態設置的，但是實際的經驗是Server必須重啟一下）
已有的表修改編碼為utf8mb4
ALTER TABLE
tbl_name
CONVERT TO CHARACTER SET
charset_name；
使用下面這個語句只是修改了表的default編碼
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4;
客戶端
jdbc的連接字元串不支持utf8mb4，這個 這種方式 來解決的，如果伺服器端設置了character_set_server=utf8mb4，則客戶端會自動將傳過去的utf-8視作清和唯utf8mb4。
Connector/J did not support utf8mb4 for servers 5.5.2 and newer.
Connector/J now auto-detects servers configured with character_set_server=utf8mb4 or treats the Java encoding utf-8 passed using characterEncoding=... as utf8mb4 in the SET NAMES= calls it makes when establishing the connection. (Bug #54175)
其他的client端，比如php、python需要看下client是否支持，如果不能在連接字元串中指定的話，可以在獲取連接之後，執行」set names utf8mb4″來解決這個問題；
因為utf8mb4是utf8的超集，理論上即使client修改字元集為utf8mb4，也會不棚滑會對已有的utf8編碼讀取產生任何問題。
② 如何解決在doc下運行java中文亂碼的情況
以下為轉載~Java中文問題一直困擾著很多初學者，如果了解了Java系統的中文問題原理，我們就可以對中文問題能夠採取根本的解決之道。最古老的解決方案是使用String的位元組碼轉換，這種方案問題是不方便，我們需要破壞對象封裝性，進行位元組碼轉換。還有一種方式是對J2EE容器進行編碼設置，如果J2EE應用系統脫離該容器，則會發生亂碼，而且指定容器配置不符合J2EE應用和容器分離的原則。在Java內部運算中，涉及到的所有字元串都會被轉化為UTF-8編碼來進行運算。那麼，在被Java轉化之前，字元串是什麼樣的字元集？ Java總是根據操作系統的默認編碼字元集來決定字元串的初始編碼，而且Java系統的輸鋒譽櫻入和輸出的都是採取虛罩操作系統的默認編碼。因 此，如果能統一Java系統的輸入、輸出和操作系統3者的編碼字元集合，將能夠使Java系統正確處理和顯示漢字。這是處理Java系統漢字的一個原則， 但是在實際項目中，能夠正確抓住和控制住Java系統的輸入和輸出部分是比較難的。J2EE中，由於涉及到外部瀏覽器和資料庫等，所以中文問題亂碼顯得非 常突出。J2EE應用程序是運行在J2EE容器中。在這個系統中，輸入途徑有很多種：一種是通過頁面表單打包成請求 （request）發往伺服器的；第二種是通過資料庫讀入；還有第3種輸入比較復雜，JSP在第一次運行時總是被編譯成Servlet，JSP中常常包含 中文字元，那麼編譯使用javac時，Java將根據默認的操作系統編碼作為初始編碼。除非特別指定，如在Jbuilder/eclipse中可以指定默 認的字元集。輸出途徑也有幾種：第一種是JSP頁面的輸出。由於JSP頁面已經被編譯成Servlet，那麼在輸出時，也將根據操作系統的默認編碼來選擇輸出編碼，除非指定輸出編碼方式；還有輸出途徑是資料庫，將字元串輸出到資料庫。由此看來，一個J2EE系統的輸入輸出是非常復雜，而且是動態變化的，而Java是跨平台運行的，在實銀叢際編譯和運行中，都可能涉及到不同的操作系統，如果任由Java自由根據操作系統來決定輸入輸出的編碼字元集，這將不可控制地出現亂碼。正是由於Java的跨平台特性，使得字元集問題必須由具體系統來統一解決，所以在一個Java應用系統中，解決中文亂碼的根本辦法是明確指定整個應用系統統一字元集。指定統一字元集時，到底是指定ISO8859_1 、GBK還是UTF-8呢？（1）如統一指定為ISO8859_1，因為目前大多數軟體都是西方人編制的，他們默認的字元集就是ISO8859_1，包括操作系統Linux和資料庫MySQL等。這樣，如果指定Jive統一編碼為ISO8859_1，那麼就有下面3個環節必須把握：開發和編譯代碼時指定字元集為ISO8859_1。運行操作系統的默認編碼必須是ISO8859_1，如Linux。在JSP頭部聲明：。（2）如果統一指定為GBK中文字元集，上述3個環節同樣需要做到，不同的是只能運行在默認編碼為GBK的操作系統，如中文Windows。統一編碼為ISO8859_1和GBK雖然帶來編制代碼的方便，但是各自只能在相應的操作系統上運行。但是也破壞了Java跨平台運行的優越性，只在一定范圍內行得通。例如，為了使得GBK編碼在linux上運行，設置Linux編碼為GBK。那麼有沒有一種除了應用系統以外不需要進行任何附加設置的中文編碼根本解決方案呢？將Java/J2EE系統的統一編碼定義為UTF-8。UTF-8編碼是一種兼容所有語言的編碼方式，惟一比較麻煩的就是要找到應用系統的所有出入口，然後使用UTF-8去「結扎」它。一個J2EE應用系統需要做下列幾步工作：開發和編譯代碼時指定字元集為UTF-8。JBuilder和Eclipse都可以在項目屬性中設置。使用過濾器，如果所有請求都經過一個Servlet控制分配器，那麼使用Servlet的filter執行語句，將所有來自瀏覽器的請求（request）轉換為UTF-8，因為瀏覽器發過來的請求包根據瀏覽器所在的操作系統編碼，可能是各種形式編碼。關鍵一句：request.setCharacterEncoding("UTF-8")。網上有此filter的源碼，Jdon框架源碼中com.jdon.util.SetCharacterEncodingFilter需要配置web.xml 激活該Filter。在JSP頭部聲明：。在Jsp的html代碼中，聲明UTF-8:設定資料庫連接方式是UTF-8。例如連接MYSQL時配置URL如下：jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8一般資料庫都可以通過管理設置設定UTF-8其他和外界交互時能夠設定編碼時就設定UTF-8，例如讀取文件，操作XML等。一、Java中文問題的由來Java的內核和class文件是基於unicode的，這使Java程序具有良好的跨平台性，但也帶來了一些中文亂碼問題的麻煩。原因主要有兩方面，Java和JSP文件本身編譯時產生的亂碼問題和Java程序於其他媒介交互產生的亂碼問題。首
先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基於位元組流的，如果Java和JSP編譯成class文件過程
中，使用的編碼方式與源文件的編碼不一致，就會出現亂碼。基於這種亂碼，建議在Java文件中盡量不要寫中文（注釋部分不參與編譯，寫中文沒關系），如果
必須寫的話，盡量手動帶參數－ecoding GBK或－ecoding gb2312編譯；對於JSP，在文件頭加上<%
@ page contentType="text/html;charset=GBK"%>或<%@ page contentType=
"text/html;charset=gb2312"%>基本上就能解決這類亂碼問題。本文要重點討論的是第二類亂碼，即Java程序與其他存儲媒介交互時產生的亂碼。很多存儲媒介，如資料庫，文件，流等的存儲方式都是基於位元組流的，Java程序與這些媒介交互時就會發生字元(char)與位元組(byte)之間的轉換，具體情況如下：從頁面form提交數據到java程序 byte－>char
從java程序到頁面顯示 char?>byte從資料庫到java程序 byte?>char
從java程序到資料庫 char?>byte從文件到java程序 byte－>char
從java程序到文件 char－>byte從流到java程序 byte－>char
從java程序到流 char－>byte如果在以上轉換過程中使用的編碼方式與位元組原有的編碼不一致，很可能就會出現亂碼。二、解決方法前面已經提到了Java程序與其他媒介交互時字元和位元組的轉換過程，如果這些轉換過程中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與位元組原有的編碼方式保持一致，下面分別論述（Java或JSP自身產生的亂碼請參看第一部分）。1、JSP與頁面參數之間的亂碼
JSP
獲取頁面參數時一般採用系統默認的編碼方式，如果頁面參數的編碼類型和系統默認的編碼類型不一致，很可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁
面獲取參數之前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding("GBK")或
request.setCharacterEncoding("gb2312")。
如果在JSP將變數輸出到頁面時出現了亂碼，可以通過設置
response.setContentType("text/html;charset=GBK")或response.setContentType
("text/html;charset=gb2312")解決。
如果不想在每個文件里都寫這樣兩句話，更簡潔的辦法是使用Servlet規范中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼如下：
web.xml:<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>net.vschool.web.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CharacterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>CharacterEncodingFilter.java:public class CharacterEncodingFilter implements Filter
{protected String encoding = null;public void init(FilterConfig filterConfig) throws ServletException
{
this.encoding = filterConfig.getInitParameter("encoding");
}public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
request.setCharacterEncoding(encoding);
response.setContentType("text/html;charset="+encoding);
chain.doFilter(request, response);
}}
2、Java與資料庫之間的亂碼
大
部分資料庫都支持以unicode編碼方式，所以解決Java與資料庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與資料庫交互。很多數據
庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其他大部分資料庫驅動，可以在驅動的url參數中指定，如如mm的
mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&
characterEncoding=GBK。3、Java與文件/流之間的亂碼
Java讀寫文件最常用的類是
FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream
和FileOutputStream是基於位元組流的，常用於讀寫二進制文件。讀寫字元文件建議使用基於字元的FileReader和
FileWriter，省去了位元組與字元之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，如果文件內容與系統編碼方式不一致，可能會出現亂碼。
在這種情況下，建議使用FileReader和FileWriter的父類：
InputStreamReader/OutputStreamWriter，它們也是基於字元的，但在構造函數中可以指定編碼類型：
InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter
(OutputStream out, Charset cs)。4、其他
上面提到的方法應該能解決大部分亂碼問題，如果在
其他地方還出現亂碼，可能需要手動修改代碼。解決Java亂碼問題的關鍵在於在位元組與字元的轉換過程中，你必須知道原來位元組或轉換後的位元組的編碼方式，轉
換時採用的編碼必須與這個編碼方式保持一致。我們以前使用Resin伺服器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒
有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了我們很久，後來我們分析
smartUpload組件的源文件，因為文件上傳採用的是位元組流的方式，裡麵包含的參數名稱和值也是位元組流的方式傳遞的。smartUpload組件讀
取位元組流後再將參數名稱和值從位元組流中解析出來，問題就出現在smartUpload將位元組流轉換成字元串時採用了系統默認的編碼，而將Resin設置成
服務後，系統默認的編碼可能發生了改變，因此出現了亂碼。後來，我們更改了smartUpload的源文件，增加了一個屬性charset和
setCharset(String)方法，將upload()方法中提取參數語句：
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1 );
改成了
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1, charset );
終於解決了這個亂碼問題。
③ java判斷文件編碼格式 怎麼判斷編碼格式
UTF-8編碼的文本文檔，有的帶有BOM (Byte Order Mark, 位元組序標志)，即0xEF, 0xBB, 0xBF，有的沒有。Windows下的txt文本編輯器在保存UTF-8格式的文本文檔時會自動添加BOM到文件頭。在判斷這類文檔時，可以根據文檔的前3個位元組來進行判斷。然敏頌而BOM不是必需的，而且也不是推薦的。對不希望UTF-8文檔帶有BOM的程序會帶來兼容性問題，例如Java編譯器在編譯帶有BOM的UTF-8源文件時就會出錯。而且BOM去掉了UTF-8一個期望的特性，即是在文本全部是ASCII字元時UTF-8是和ASCII一致的，即UTF-8向下兼容ASCII。
在具體判斷時，如果文檔不帶有BOM，就無法根據BOM做出判斷，而且IsTextUnicode API也無法對UTF-8編碼的Unicode字元串做出判斷。那在編程判斷時就要根據UTF-8字元編碼的此冊規律進行判斷了。
UTF-8是一種多森拿宏位元組編碼的字元集，表示一個Unicode字元時，它可以是1個至多個位元組，在表示上有規律：
1位元組：0xxxxxxx
2位元組：110xxxxx 10xxxxxx
3位元組：1110xxxx 10xxxxxx 10xxxxxx
4位元組：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
這樣就可以根據上面的特徵對字元串進行遍歷來判斷一個字元串是不是UTF-8編碼了。
舉例代碼：
java.io.File f=new java.io.File("待判定的文本文件名");
try{
java.io.InputStream ios=new java.io.FileInputStream(f);
byte[] b=new byte[3];
ios.read(b);
ios.close();
if(b[0]==-17&&b[1]==-69&&b[2]==-65)
System.out.println(f.getName()+"編碼為UTF-8");
else System.out.println(f.getName()+"可能是GBK");
}catch(Exception e){
e.printStackTrace();
}
④ protobuffer java中文亂碼怎麼解決
protobuf支持非UTF8字元串
protobuf規范string類型是必須是UTF8字元,但在C/C++中可以直接調用set方法設置任意編碼方式的字元串,也可以直接取得對應字元串,但在控制台中會列印出編碼不是UTF8字元的錯誤信息.
查看protobuf源代碼發現是在wire_format.h中有一函數VerifyUTF8String()里進行編碼判斷的,而且有一宏定義GOOGLE_PROTOBUF_UTF8_VALIDATION_ENABLED可以取消此錯誤信息.估計google當初開發時用的是std::string類型,並沒有編碼方面的強制要求,只是在跨平台時沒有統一編碼容易引起問題,才統一使用UTF8方式傳送字元串.
但像Java,Python預設就是支持UNICODE,在protobuf庫中就已經做了轉換或檢測,可以修改粗握兄相關代碼不做此轉換或檢測.
如python中修改lib中的protobufxxx.egg中的decoder.py的StringDecoder()方法,將value.append(local_unicode(buffer[pos:new_pos], 'utf-8'))
改為value.append(buffer[pos:new_pos])
,將field_dict[key] = local_unicode(buffer[pos:new_pos], 'utf-8')
改為field_dict[key] = buffer[pos:new_pos]
即可,Python即不會報異常錯誤,也能皮團正確取得任意編碼的字元串,但需要注意取出後需要進行編碼(decode("gbk"))才能正確顯示.
另外type_checkers.py中CheckValue()中對str的判斷也需要去掉,encoder.py中帶'utf-8'的全改了,才岩襲能正常編碼.
至於如此改會不會有其它潛在的問題,還有待測試.
⑤ 請問java如何改變字元串的編碼方式
byte[] b=string.getBytes("GB2312");//使用GB2312編碼方式對字元串string進行編碼
//這時要想將位元組數組b的內容正確解碼只能使用GB2312的編碼方式進行解碼，即
String str=new String(b,"GB2312");//這里若使用UTF-8編碼方式來進行解碼就會亂碼
//將eclipse默認的編碼方式改為UTF-8，只是用該編碼方式對.java源文件進行編碼保存
//這個對new String(string.getBytes("GB2312"),"UTF-8")沒啥影運敏響的
//因為從java源文件獲取字元串string時，已經通過UTF-8編碼方式進行解碼了
//而string.getBytes("GB2312")是使用指定的編碼方吵晌式對字元串string進行從新編碼
//旁碰枝這兩者之間沒啥關系的
⑥ jsp\java如何編寫過濾器過濾特殊字元
正則表達式來校驗：過濾器就網路一大堆，怎麼寫正則表達式，也可以網路，不知你說的特殊字元是什麼字元，所以只能給方法
⑦ 判斷JAVA字元串（內容為網址）中是否含有非英文、數字等字元
可以挨個讀出來並判斷《255的是英文，》255的是漢字或其它亂碼。
這樣每次只要遇到一個》255的就可以放棄，再度另一行文字。
例如 ： a=openfile（」原始文件。txt「）
b=openfile（」過濾後的文件。txt「）羨棚
wihle（！eof（纖脊a）毀派滲）
{
s=readline（a）
flage=false
for(int i=0 l i<s.length;i+=)
{
if(s[i]>255){
flage=true
}
}
wrtieline（s,b)
}
close(a)
close(b)
⑧ java判斷字元串是否超出utf8編碼
51CTO博客已為您找到關於java判斷字元串是否嫌如為塌虧utf8編碼的相關內容,包含IT學習相關文檔代碼介紹、相關教程視頻課程,以及java判斷芹衫啟字元串是否為utf8...
⑨ java怎樣過濾字元串中的\xf1\xa1
windows平台的換行符為/r/n;
linux平台的換行符為/n;
java程序中如何將不同平台用戶輸入的換行符轉換成特定系統的神殲換行好瞎姿符.
2.解答友絕
java 代碼
1. String userInputString = userInput;
2. userInputString = userInputString.replaceAll ( "\r", "" );
3. userInputString = userInputString.replaceAll ( "\n", "\\\\"+System.getPropert("line.separator"));
⑩ 在Java截取字元串的時候，如何過濾掉html標簽
去除html標簽
function
strip_tags($string,
$replace_with_space
=
true)
{
if
($replace_with_space)
{
return
preg_replace('!<[^>]*?>!',
'
',
$string);
}
else
{
return
strip_tags($string);
}
}
截取字元函數（匹配各種編碼）
function
truncate($string,
$length
=
80,
$etc
=
'...',
$break_words
=
false,
$middle
=
false){
if
($length
==
0)
return
'';
if
(is_callable('mb_strlen'))
{
if
(mb_detect_encoding($string,
'utf-8,
iso-8859-1')
===
'utf-8')
{
//
$string
has
utf-8
encoding
if
(mb_strlen($string)
>
$length)
{
$length
-=
min($length,
mb_strlen($etc));
if
(!$break_words
&&
!$middle)
{
$string
=
preg_replace('/\s+?(\s+)?$/u',
'',
mb_substr($string,
0,
$length
+
1));
}
if
(!$middle)
{
return
mb_substr($string,
0,
$length)
.
$etc;
}
else
{
return
mb_substr($string,
0,
$length
/
2)
.
$etc
.
mb_substr($string,
-
$length
/
2);
}
}
else
{
return
$string;
}
}
}
//
$string
has
no
utf-8
encoding
if
(strlen($string)
>
$length)
{
$length
-=
min($length,
strlen($etc));
if
(!$break_words
&&
!$middle)
{
$string
=
preg_replace('/\s+?(\s+)?$/',
'',
substr($string,
0,
$length
+
1));
}
if
(!$middle)
{
return
substr($string,
0,
$length)
.
$etc;
}
else
{
return
substr($string,
0,
$length
/
2)
.
$etc
.
substr($string,
-
$length
/
2);
}
}
else
{
return
$string;
}
}
綜合就是
$arc=strip_tags($arc);