androidutf轉unicode

Ⅰ 怎麼解決讀取txt文件讀取時中文亂碼問題

從SDCard保存的txt文件讀取中文到android系統中會出現亂碼問題，如何解決這個亂碼問題，網上有不少解答方法，譬如說利用String temp1 =EncodingUtils.getString(strLine.getBytes(),"GB2312"); 但並非對所有的情況都適用，解決亂碼問題首先要明白為什麼會亂碼。究其原因，是因為txt文件在win系統上保存時默認為ANSI格式，而android目前只支持UTF-8編碼，因此將txt文件的中文讀入android系統中會產生亂碼。也有人說直接將txt另存為UTF-8編碼格式來解決亂碼問題，但這種方法指標不治本，不能要求用戶手動去更改格式，客戶第一嘛。因此還是需要想辦法在程序中進行處理。
以下做了一些編碼格式的測試：
測試文本： 122.11196,29.90573,北侖固廢廠 測試代碼段：
reader=new BufferedReader(new FileReader(filename));
strLine=reader.readLine() ;
String temp1 = EncodingUtils.getString(strLine.getBytes(),"GB2312");
String temp2 = EncodingUtils.getString(strLine.getBytes("utf-8"),"utf-8");
String temp3 = EncodingUtils.getString(strLine.getBytes(),"utf-8");
將文件存成 Unicode 格式
這種方式能得到非亂碼的中文顯示，但對於 utf-8 格式下取得的經緯度數字利用double lon = Double.parseDouble(lat); 報錯 NumberFormatException，原因可能是 parseDouble(lat)方法不能處理存成utf-8格式的帶標點小數。 將文件 存成 ANSI 格式
將代碼改為：

reader = new BufferedReader(new InputStreamReader(new FileInputStream(filename),"GB2312"));

strLine=reader.readLine() ;
String temp1 = EncodingUtils.getString(strLine.getBytes(),"GB2312");
String temp2 = EncodingUtils.getString(strLine.getBytes("utf-8"),"utf-8");
String temp3 = EncodingUtils.getString(strLine.getBytes(),"utf-8");
即解決了中文亂碼問題，又解決了Double.parseDouble(lat)報錯問題。

Ⅱ 易語言好用還是python語言好用

當然是python好用了，不論是易還是python都不可以編寫手機軟體python對中文支持不好，這個不好辦，不過網上很多相關解決方法的。=====================================================本文原創，如需轉載，請註明出處。在本文中，以'哈'來解釋作示例解釋所有的問題，「哈」的各種編碼如下： 1. UNICODE (UTF8-16)，C854； 2． UTF-8，E59388； 3． GBK，B9FE。一、python中的str和unicode
一直以來，python中的中文編碼就是一個極為頭大的問題，經常拋出編碼轉換的異常，python中的str和unicode到底是一個什麼東西呢？在python中提到unicode，一般指的是unicode對象，例如'哈哈'的unicode對象為u'\u54c8\u54c8'而str，是一個位元組數組，這個位元組數組表示的是對unicode對象編碼(可以是utf-8、gbk、cp936、GB2312)後的存儲的格式。這里它僅僅是一個位元組流，沒有其它的含義，如果你想使這個位元組流顯示的內容有意義，就必須用正確的編碼格式，解碼顯示。例如： 對於unicode對象哈哈進行編碼，編碼成一個utf-8編碼的str－s_utf8,s_utf8就是是一個位元組數組，存放的就是'\xe5\x93\x88\xe5\x93\x88'，但是這僅僅是一個位元組數組，如果你想將它通過print語句輸出成哈哈，那你就失望了，為什麼呢？因為print語句它的實現是將要輸出的內容傳送了操作系統，操作系統會根據系統的編碼對輸入的位元組流進行編碼，這就解釋了為什麼utf-8格式的字元串「哈哈」，輸出的是「鍝堝搱」，因為'\xe5\x93\x88\xe5\x93\x88'用GB2312去解釋，其顯示的出來就是「鍝堝搱」。這里再強調一下，str記錄的是位元組數組，只是某種編碼的存儲格式，至於輸出到文件或是列印出來是什麼格式，完全取決於其解碼的編碼將它解碼成什麼樣子。這里再對print進行一點補充說明：當將一個unicode對象傳給print時，在內部會將該unicode對象進行一次轉換，轉換成本地的默認編碼（這僅是個人猜測）二、str和unicode對象的轉換
str和unicode對象的轉換，通過encode和decode實現，具體使用如下： 將GBK'哈哈'轉換成unicode，然後再轉換成UTF8三、Setdefaultencoding
如上圖的演示代碼所示：當把s(gbk字元串)直接編碼成utf-8的時候，將拋出異常，但是通過調用如下代碼：import sysreload(sys)sys.setdefaultencoding('gbk')後就可以轉換成功，為什麼呢？在python中str和unicode在編碼和解碼過程中，如果將一個str直接編碼成另一種編碼，會先把str解碼成unicode，採用的編碼為默認編碼，一般默認編碼是anscii，所以在上面示例代碼中第一次轉換的時候會出錯，當設定當前默認編碼為'gbk'後，就不會出錯了。至於reload(sys)是因為Python2.5 初始化後會刪除 sys.setdefaultencoding 這個方法，我們需要重新載入。四、操作不同文件的編碼格式的文件
建立一個文件test.txt，文件格式用ANSI，內容為:abc中文用python來讀取# coding=gbkprint open("Test.txt").read()結果：abc中文把文件格式改成UTF-8：結果：abc涓�枃顯然，這里需要解碼：# coding=gbkimport codecsprint open("Test.txt").read().decode("utf-8")結果：abc中文上面的test.txt我是用Editplus來編輯的，但當我用Windows自帶的記事本編輯並存成UTF-8格式時，運行時報錯：Traceback (most recent call last):File "ChineseTest.py", line 3, in print open("Test.txt").read().decode("utf-8")UnicodeEncodeError: 'gbk' codec can't encode character u'\ufeff' in position 0: illegal multibyte sequence原來，某些軟體，如notepad，在保存一個以UTF-8編碼的文件時，會在文件開始的地方插入三個不可見的字元（0xEF 0xBB 0xBF，即BOM）。因此我們在讀取時需要自己去掉這些字元，python中的codecs mole定義了這個常量：# coding=gbkimport codecsdata = open("Test.txt").read()if data[:3] == codecs.BOM_UTF8:data = data[3:]print data.decode("utf-8")結果：abc中文五、文件的編碼格式和編碼聲明的作用源文件的編碼格式對字元串的聲明有什麼作用呢？這個問題困擾一直困擾了我好久，現在終於有點眉目了，文件的編碼格式決定了在該源文件中聲明的字元串的編碼格式，例如：str = '哈哈'print repr(str)a.如果文件格式為utf-8，則str的值為：'\xe5\x93\x88\xe5\x93\x88'（哈哈的utf-8編碼）b.如果文件格式為gbk，則str的值為：'\xb9\xfe\xb9\xfe'（哈哈的gbk編碼）在第一節已經說過，python中的字元串，只是一個位元組數組，所以當把a情況的str輸出到gbk編碼的控制台時，就將顯示為亂碼：鍝堝搱；而當把b情況下的str輸出utf-8編碼的控制台時，也將顯示亂碼的問題，是什麼也沒有，也許'\xb9\xfe\xb9\xfe'用utf-8解碼顯示，就是空白吧。>_<說完文件格式，現在來談談編碼聲明的作用吧，每個文件在最上面的地方，都會用# coding=gbk 類似的語句聲明一下編碼，但是這個聲明到底有什麼用呢？到止前為止，我覺得它的作用也就是三個：
1.聲明源文件中將出現非ascii編碼，通常也就是中文；
2.在高級的IDE中，IDE會將你的文件格式保存成你指定編碼格式。
3.決定源碼中類似於u'哈'這類聲明的將『哈』解碼成unicode所用的編碼格式，也是一個比較容易讓人迷惑的地方，看示例：
#coding:gbk
ss = u'哈哈'print repr(ss)print 'ss:%s' % ss將這個些代碼保存成一個utf-8文本，運行，你認為會輸出什麼呢？大家第一感覺肯定輸出的肯定是：u'\u54c8\u54c8'ss:哈哈但是實際上輸出是：u'\u935d\u581d\u6431'ss:鍝堝搱為什麼會這樣，這時候，就是編碼聲明在作怪了，在運行ss = u'哈哈'的時候，整個過程可以分為以下幾步：1) 獲取'哈哈'的編碼：由文件編碼格式確定，為'\xe5\x93\x88\xe5\x93\x88'（哈哈的utf-8編碼形式）2) 轉成unicode編碼的時候，在這個轉換的過程中，對於'\xe5\x93\x88\xe5\x93\x88'的解碼，不是用utf-8解碼，而是用聲明編碼處指定的編碼GBK，將'\xe5\x93\x88\xe5\x93\x88'按GBK解碼，得到就是''鍝堝搱''，這三個字的unicode編碼就是u'\u935d\u581d\u6431'，至止可以解釋為什麼print repr(ss)輸出的是u'\u935d\u581d\u6431'了。好了，這里有點繞，我們來分析下一個示例：#-*- coding:utf-8 -*-ss = u'哈哈'print repr(ss)print 'ss:%s' % ss將這個示例這次保存成GBK編碼形式，運行結果，竟然是：UnicodeDecodeError: 'utf8' codec can't decode byte 0xb9 in position 0: unexpected code byte這里為什麼會有utf8解碼錯誤呢？想想上個示例也明白了，轉換第一步，因為文件編碼是GBK，得到的是'哈哈'編碼是GBK的編碼'\xb9\xfe\xb9\xfe'，當進行第二步，轉換成unicode的時候，會用UTF8對'\xb9\xfe\xb9\xfe'進行解碼，而大家查utf-8的編碼表會發現，utf8編碼表（關於UTF-8解釋可參見字元編碼筆記：ASCII、UTF-8、UNICODE）中根本不存在，所以會報上述錯誤。 本文來自CSDN博客，轉載請標明出處： http://blog.csdn.net/kiki113/archive/2009/04/10/4062063.aspx

Ⅲ Android裡面JNI使用的MUTF-8編碼，為什麼要使用MUTF-8而不使用UTF-8

這是因為java內部使用UTF-16編碼，
一般情況下，一個char就能代表u+0000~u+ffff的unicode. utf-8,mutf-8編碼是一樣的。
而對於u+10000 u+10ffff的字元的編碼是採用一對代理字元的方式來編碼的，即兩個char代表一個字元。其中一個char為0xD800 ~ 0xDBFF 含高位10bits,另一個為0xDC00 ~ 0xDFFF含低位10bits.（在這之前這個編碼要先被減去0x10000,這樣它的值的范圍就落到0x0~0xfffff,正好最多20bits） 也就是說只要檢查一個字元的值的范圍，就知道這字元是否應該和下一個字元組成對。
回過頭來，utf-8 對u+0000 ~ u+ffff編碼結果是1~3位元組，對u+1000 ~ u+10ffff編碼會4位元組及以上。
如果採用utf-8,會使jvm處理這種位元組時，進行兩次編碼。第一次是utf-8 -> unicode (32 位)，第二次 unicode (32 位) -> utf-16 (16 位)。
而採用mutf-8時，它只認位元組，不認位元組對。它直接操作java 語義上的char。u+10000 ~ u+10ffff是被當成兩個char來處理的。每都分別被編碼成utf-8 的三個位元組。這相當於直接utf-8 -> utf-16，省了一步操作。可以說是必然的結果。

Ⅳ 如何解決Android WebView出現的亂碼問題

1、webView.loadUrl()；
直接顯示網頁內容(單獨顯示網路圖片)，一般不會出現亂碼。
2、webView.loadData(data, "text/html", "UTF-8");
loadData主要被設計用來裝載URI格式的數據，它不能通過網路來載入內容。網上流傳的webview載入中文出現亂碼，多數是使用此方法。使用過程中主要有兩個問題：
（1）loadData不能載入圖片內容，如果想載入圖片內容或者獲得更強大的Web支持建議使用更強大的loadDataWithBaseURL.
(2) 許多實用loadData方法的朋友都遇到顯示亂碼的問題，那是因為編碼器設置錯誤導致的。我們知道String類型的數據主要是unicode編碼，而WebView一般為了節省資源使用的是UTF-8編碼，所以我們在loadData的時候要告訴方法怎樣轉碼。即要告訴它要將unicode編碼的內容轉成UTF-8編碼的內容。有些朋友雖然在loadData的時候設置了編碼方式，但是還是顯示亂碼，這是因為還需要為WebView的text編碼指定編碼方式。舉例如下：
WebView wv = (WebView)findViewById(R.id.webview) ;
wv.getSettings().setDefaultTextEncodingName(「UTF -8」) ;
wv.loadData(content, 「text/html」, 「UTF-8」) ;
注意為gb2312或gbk
（3）.網頁說明編碼格式
以上兩種方法是網上給的比較好的方法，但是我都試了下都沒有解決我的亂碼問題。 原來我是用LoadData方法來解析html的，但是據說這是官方的一個BUG，不能用來解析中文。所以繞其道而行之，採用loadDataWithBaseURL的方法，其中codeingType設置為utf-8就OK了。3、loadDataWithBaseURL如果單純顯示文字的話可以寫webView.loadDataWithBaseURL(null, string, "text/html", "utf-8", null);
如果要顯示圖片可以寫webView.loadDataWithBaseURL(baseUrl, string, "text/html", "utf-8", null);
其中baseUrl為你存儲照片的路徑，比如：

Ⅳ android studio 怎麼打開文件有些亂碼，有些不亂嗎

亂碼是因為編碼不匹配的問題，你的文件中應該含有中文，並且你的文件編碼方式不統一，或者使用了不同的編碼方式打開相同編碼的文件。推薦使用utf8，這是所有Android、Ios、Linux默認的編碼方式，Windows是GBK編碼，utf8屬於Unicode編碼方式中的一種，Unicode是全世界都通用的，ANSI指的是本土化編碼對於中國來說就是ANSI就是GBK。Android Studio編輯文件時右下角有個本文件的編碼方式，一旦出現亂碼你就不要修改文件內容了，如果修改文件內容再保存，就很難恢復亂碼了，要在沒有編輯文件前選擇一種合適的編碼方式，看什麼編碼方式文件才不會出現亂碼就選擇什麼編碼方式，如果想要修改編碼方式可以直接賦值粘貼到不同編碼的文件內。Sublime Text和Notepad++都很好的支持各種編碼方式並且能夠輕易轉化，其中Sublime Text會自動匹配對應的編碼方式。

Ⅵ android怎麼根據文件編碼讀取文件

使用記事本"另存為"，可以看到有編碼類型選項：

編碼類型有: ANSI, Unicode, UTF-8幾種，它們的區別在於前面的BOM碼(Bytes Of Mark)：
Unicode的txt前兩個位元組是ff fe；
Unicode big endian的txt前兩個位元組是fe ff；
UTF-8的txt前三個位元組是ef bb bf，也可以沒有，即沒有BOM.
ANSI的txt是直接開始內容的。

Ⅶ Android中Java 默認UTF-8，中文亂碼

OutputStreamWriter(OutputStream out)
Creates an OutputStreamWriter that uses the default character
encoding.

OutputStreamWriter(OutputStream out, Charset cs)
Creates an OutputStreamWriter that uses the given
charset.

OutputStreamWriter(OutputStream out, CharsetEncoder enc)
Creates an OutputStreamWriter that uses the given charset
encoder.

OutputStreamWriter(OutputStream out, String charsetName)
Creates an OutputStreamWriter that uses the named
charset.
參考一下吧

Ⅷ 在android中怎樣把utf-16的字元轉換為GBK字元用printf輸出

在java裡面應該是先轉換成newString(s,"utf-16").getBytes("gbk");這樣操作的。

不知道位元組的順序C和Java是一樣的不。原來的 JDK 中也是用char 來代表字元的，我們知道當我們想處理所有字元時1個位元組 (char) 根本不夠，所以 JDK 5 還是用回 int 來表示 code point在邏輯上一個 int 表示一個字元，而原來的 char 只能表示位元組。那麼你的 7 位元組的 unsigned int 是相當於 Java 中的什麼呢？每個 unsigned int 怎麼對應到 java 的 char[] 數組上來的?

在 Java 中內核是使用 Unicode 處理的，不存在什麼 GBK 輸出，我們已經看到字元時它就在 JVM 處理時有一個 unicode code point 了，你的 GBK 輸出是指要轉換成 GBK 位元組導出另一個系統？保存到磁碟也可以算做交換數據，不過如果只是緩存只被自己使用的話，隨便用什麼字元集保存下次再用同樣字元集讀取就可以了，哪怕保存到磁碟上是錯誤的也沒關系，只要還原過程是無損失的就可以了。那麼如果你的 printf 列印把控制台（還在內存中，不去磁碟，也不去網路另一端）就不需要考慮 byte[] 了，直接當成 Reader / Writer 這類來處理就可以了。

始終了解一點，當你不打算」交換數據「時，字元集是根本沒有任何用處的。

位元組或字元本身並沒有UTF-16和GBK的差別，主要是當我們想把它轉換成位元組時而有不同。每個字元按理說在操作系統或編程語言中會有一個unicodecodepoint與它對應（這樣的系統內核使用unicode就不存在處理不了的語言了）。因此，轉換的過程就是先讓對應到unicodecodepoint再轉換到另一個字元集編碼對應的byte[]就行了。

什麼是 unicode，看下這個圖片，那麼什麼是 UTF-8，從圖片中看到了 code point 是十六進制 0x20073 = 131187，那麼當多個字元挨在一起我們想通過網路傳送出去，如何讓對方程序知道字元的邊界在哪裡，哪幾個位元組湊在一起是一個字元，這就是字元集編碼方案了。UTF-8 只是其中一種編碼方案。

Ⅸ 如何將編碼為UTF-16LE的文本在文本編碼為UTF-8的安卓手機正常顯示出來

如果只是轉換ascill字元,轉換到utf8是一樣的.如果轉換到utf16即unicode,這個是寬位元組編碼,asicll和中文即gb編碼,算多位元組編碼,即需要直接調用vs的api函數MultiByteToWideChar,多位元組轉寬位元組函數來實現

Ⅹ Android 使用Log列印日誌的時候中文是亂碼,怎麼解決啊

是由於DOS窗口顯示的編碼同logcat日誌中不同導致的亂碼問題。DOS窗口默認的編碼是GBK，而LogCat列印的是UTF-8的編碼，所以要設置DOS字元編碼：
1， 在當前命令行下輸入 chcp 65001，按回車鍵。這時，當前代碼頁使用的就是UTF-8編碼了。
2， 修改窗口屬性，改變字體。在命令行標題欄上點擊右鍵，選擇「屬性」->「字體」」，將字體修改為True Type字體」Lucida Console」，然後點擊確定將屬性應用到當前窗口。
3，再使用logcat列印日誌，就可以正常顯示中文字元了。
4， 補充部分字元編碼對應代碼：
65001——UTF-8
936——簡體中文
950——繁體中文
437——美國/加拿大英語
932——日文
949——韓文
866——俄文