西西软件园多重安全检测下载网站、值得信赖的软件下载站!
软件
软件
文章
搜索
鐢熸椿鏈嶅姟
鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�
鐧惧害鍦板浘瀵艰埅2022V15.12.10 瀹夊崜鎵嬫満鐗�鐧惧害鍦板浘瀵艰埅2022V15.12.10 瀹夊崜鎵嬫満鐗�
鎵嬫満娣樺疂瀹㈡埛绔痸10.8.40瀹樻柟鏈€鏂扮増鎵嬫満娣樺疂瀹㈡埛绔痸10.8.40瀹樻柟鏈€鏂扮増
鐣呴€旂綉鎵嬫満瀹㈡埛绔痸5.6.9 瀹樻柟鏈€鏂扮増鐣呴€旂綉鎵嬫満瀹㈡埛绔痸5.6.9 瀹樻柟鏈€鏂扮増
鍗冭亰鐭ヨ瘑鏈嶅姟appv4.5.1瀹樻柟鐗�鍗冭亰鐭ヨ瘑鏈嶅姟appv4.5.1瀹樻柟鐗�
褰遍煶鎾斁
p2psearcher瀹夊崜鐗�7.3  鎵嬫満鐗�p2psearcher瀹夊崜鐗�7.3 鎵嬫満鐗�
閰风嫍闊充箰2022瀹樻柟鐗圴11.0.8 瀹樻柟瀹夊崜鐗�閰风嫍闊充箰2022瀹樻柟鐗圴11.0.8 瀹樻柟瀹夊崜鐗�
鐖卞鑹烘墜鏈虹増v13.1.0鐖卞鑹烘墜鏈虹増v13.1.0
鐧惧害褰遍煶7.13.0 瀹樻柟鏈€鏂扮増鐧惧害褰遍煶7.13.0 瀹樻柟鏈€鏂扮増
褰遍煶鍏堥攱v6.9.0 瀹夊崜鎵嬫満鐗�褰遍煶鍏堥攱v6.9.0 瀹夊崜鎵嬫満鐗�
闃呰宸ュ叿
鑵捐鍔ㄦ极V9.11.5 瀹夊崜鐗�鑵捐鍔ㄦ极V9.11.5 瀹夊崜鐗�
涔︽棗灏忚鍏嶈垂鐗堟湰v11.5.5.153 瀹樻柟鏈€鏂扮増涔︽棗灏忚鍏嶈垂鐗堟湰v11.5.5.153 瀹樻柟鏈€鏂扮増
QQ闃呰鍣╝ppV7.7.1.910 瀹樻柟鏈€鏂扮増QQ闃呰鍣╝ppV7.7.1.910 瀹樻柟鏈€鏂扮増
鎳掍汉鐣呭惉鍚功appv7.1.5 瀹樻柟瀹夊崜鐗�鎳掍汉鐣呭惉鍚功appv7.1.5 瀹樻柟瀹夊崜鐗�
璧风偣璇讳功app鏂扮増鏈�20227.9.186 瀹夊崜鐗�璧风偣璇讳功app鏂扮増鏈�20227.9.186 瀹夊崜鐗�
閲戣瀺鐞嗚储
骞冲畨璇佸埜瀹塭鐞嗚储V9.1.0.1 瀹樻柟瀹夊崜鐗�骞冲畨璇佸埜瀹塭鐞嗚储V9.1.0.1 瀹樻柟瀹夊崜鐗�
娴烽€氳瘉鍒告墜鏈虹増(e娴烽€氳储)8.71 瀹樻柟瀹夊崜鐗�娴烽€氳瘉鍒告墜鏈虹増(e娴烽€氳储)8.71 瀹樻柟瀹夊崜鐗�
涓滄捣璇佸埜涓滄捣鐞嗚储4.0.5 瀹夊崜鐗�涓滄捣璇佸埜涓滄捣鐞嗚储4.0.5 瀹夊崜鐗�
涓摱璇佸埜绉诲姩鐞嗚储杞欢6.02.010 瀹樻柟瀹夊崜鐗�涓摱璇佸埜绉诲姩鐞嗚储杞欢6.02.010 瀹樻柟瀹夊崜鐗�
鍗庨緳璇佸埜灏忛噾鎵嬫満鐞嗚储杞欢3.2.4 瀹夊崜鐗�鍗庨緳璇佸埜灏忛噾鎵嬫満鐞嗚储杞欢3.2.4 瀹夊崜鐗�
鎵嬫満閾惰
绂忓缓鍐滄潙淇$敤绀炬墜鏈洪摱琛屽鎴风2.3.4 瀹夊崜鐗�绂忓缓鍐滄潙淇$敤绀炬墜鏈洪摱琛屽鎴风2.3.4 瀹夊崜鐗�
鏄撳埗浣滆棰戝壀杈慳pp4.1.16瀹夊崜鐗�鏄撳埗浣滆棰戝壀杈慳pp4.1.16瀹夊崜鐗�
鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�
涓浗宸ュ晢閾惰鎵嬫満閾惰appV7.0.1.2.5 瀹夊崜鐗�涓浗宸ュ晢閾惰鎵嬫満閾惰appV7.0.1.2.5 瀹夊崜鐗�
涓浗閾惰鎵嬫満閾惰瀹㈡埛绔�7.2.5 瀹樻柟瀹夊崜鐗�涓浗閾惰鎵嬫満閾惰瀹㈡埛绔�7.2.5 瀹樻柟瀹夊崜鐗�
浼戦棽鐩婃櫤
鑵捐鐚庨奔杈句汉鎵嬫満鐗圴2.3.0.0 瀹樻柟瀹夊崜鐗�鑵捐鐚庨奔杈句汉鎵嬫満鐗圴2.3.0.0 瀹樻柟瀹夊崜鐗�
鍔茶垶鍥㈠畼鏂规鐗堟墜娓竩1.2.1瀹樻柟鐗�鍔茶垶鍥㈠畼鏂规鐗堟墜娓竩1.2.1瀹樻柟鐗�
楗ラタ椴ㄩ奔杩涘寲鏃犻檺閽荤煶鐗坴7.8.0.0瀹夊崜鐗�楗ラタ椴ㄩ奔杩涘寲鏃犻檺閽荤煶鐗坴7.8.0.0瀹夊崜鐗�
妞嶇墿澶ф垬鍍靛案鍏ㄦ槑鏄�1.0.91 瀹夊崜鐗�妞嶇墿澶ф垬鍍靛案鍏ㄦ槑鏄�1.0.91 瀹夊崜鐗�
鍔ㄤ綔灏勫嚮
鍦颁笅鍩庣獊鍑昏€卋t鐗�1.6.3 瀹樻柟鐗�鍦颁笅鍩庣獊鍑昏€卋t鐗�1.6.3 瀹樻柟鐗�
瑁呯敳鑱旂洘1.325.157 瀹夊崜鐗�瑁呯敳鑱旂洘1.325.157 瀹夊崜鐗�
鍦f枟澹槦鐭㈤泦缁搗4.2.1 瀹夊崜鐗�鍦f枟澹槦鐭㈤泦缁搗4.2.1 瀹夊崜鐗�
閬ぉ3D鎵嬫父1.0.9瀹夊崜鐗�閬ぉ3D鎵嬫父1.0.9瀹夊崜鐗�
濉旈槻娓告垙
瀹夊崜妞嶇墿澶ф垬鍍靛案2榛戞殫鏃朵唬淇敼鐗圴1.9.5 鏈€鏂扮増瀹夊崜妞嶇墿澶ф垬鍍靛案2榛戞殫鏃朵唬淇敼鐗圴1.9.5 鏈€鏂扮増
涔辨枟瑗挎父2v1.0.150瀹夊崜鐗�涔辨枟瑗挎父2v1.0.150瀹夊崜鐗�
淇濆崼钀濆崪3鏃犻檺閽荤煶鏈€鏂扮増v2.0.0.1 瀹夊崜鐗�淇濆崼钀濆崪3鏃犻檺閽荤煶鏈€鏂扮増v2.0.0.1 瀹夊崜鐗�
鍙h鑻遍泟鍗曟満鐗�1.2.0 瀹夊崜鐗�鍙h鑻遍泟鍗曟満鐗�1.2.0 瀹夊崜鐗�
灏忓皬鍐涘洟瀹夊崜鐗�2.7.4 鏃犻檺閲戝竵淇敼鐗�灏忓皬鍐涘洟瀹夊崜鐗�2.7.4 鏃犻檺閲戝竵淇敼鐗�
璧涜溅绔炴妧
鐧诲北璧涜溅2鎵嬫父1.47.1  瀹夊崜鐗�鐧诲北璧涜溅2鎵嬫父1.47.1 瀹夊崜鐗�
涓€璧锋潵椋炶溅瀹夊崜鐗坴2.9.14 鏈€鏂扮増涓€璧锋潵椋炶溅瀹夊崜鐗坴2.9.14 鏈€鏂扮増
璺戣窇鍗′竵杞︽墜鏈虹増瀹樻柟鏈€鏂扮増v1.16.2 瀹夊崜鐗�璺戣窇鍗′竵杞︽墜鏈虹増瀹樻柟鏈€鏂扮増v1.16.2 瀹夊崜鐗�
鐙傞噹椋欒溅8鏋侀€熷噷浜戜慨鏀圭増(鍏嶆暟鎹寘)v4.6.0j 閲戝竵鏃犻檺鐗�鐙傞噹椋欒溅8鏋侀€熷噷浜戜慨鏀圭増(鍏嶆暟鎹寘)v4.6.0j 閲戝竵鏃犻檺鐗�
鐧句箰鍗冪偖鎹曢奔2021鏈€鏂扮増5.78 瀹夊崜鐗�鐧句箰鍗冪偖鎹曢奔2021鏈€鏂扮増5.78 瀹夊崜鐗�
瑙掕壊鎵紨
姊﹀够鍓戣垶鑰呭彉鎬佺増1.0.1.2瀹夊崜鐗�姊﹀够鍓戣垶鑰呭彉鎬佺増1.0.1.2瀹夊崜鐗�
浠欏浼犺ro澶嶅叴瀹夊崜鐗�1.20.3鏈€鏂扮増浠欏浼犺ro澶嶅叴瀹夊崜鐗�1.20.3鏈€鏂扮増
姊﹀够璇涗粰鎵嬫父鐗�1.3.6 瀹樻柟瀹夊崜鐗�姊﹀够璇涗粰鎵嬫父鐗�1.3.6 瀹樻柟瀹夊崜鐗�
鐜嬭€呰崳鑰€V3.72.1.1 瀹夊崜鏈€鏂板畼鏂圭増鐜嬭€呰崳鑰€V3.72.1.1 瀹夊崜鏈€鏂板畼鏂圭増
璋佸灏忚溅寮烘墜鏈虹増v1.0.49 瀹夊崜鐗�璋佸灏忚溅寮烘墜鏈虹増v1.0.49 瀹夊崜鐗�
绯荤粺杞欢
mac纾佺洏鍒嗗尯宸ュ叿(Paragon Camptune X)V10.8.12瀹樻柟鏈€鏂扮増mac纾佺洏鍒嗗尯宸ュ叿(Paragon Camptune X)V10.8.12瀹樻柟鏈€鏂扮増
鑻规灉鎿嶄綔绯荤粺MACOSX 10.9.4 Mavericks瀹屽叏鍏嶈垂鐗�鑻规灉鎿嶄綔绯荤粺MACOSX 10.9.4 Mavericks瀹屽叏鍏嶈垂鐗�
Rar瑙e帇鍒╁櫒mac鐗坴1.4 瀹樻柟鍏嶈垂鐗�Rar瑙e帇鍒╁櫒mac鐗坴1.4 瀹樻柟鍏嶈垂鐗�
Mac瀹夊崜妯℃嫙鍣�(ARC Welder)v1.0 瀹樻柟鏈€鏂扮増Mac瀹夊崜妯℃嫙鍣�(ARC Welder)v1.0 瀹樻柟鏈€鏂扮増
Charles for MacV3.9.3瀹樻柟鐗�Charles for MacV3.9.3瀹樻柟鐗�
缃戠粶宸ュ叿
鎼滅嫍娴忚鍣╩ac鐗坴5.2 瀹樻柟姝e紡鐗�鎼滅嫍娴忚鍣╩ac鐗坴5.2 瀹樻柟姝e紡鐗�
閿愭嵎瀹㈡埛绔痬ac鐗圴1.33瀹樻柟鏈€鏂扮増閿愭嵎瀹㈡埛绔痬ac鐗圴1.33瀹樻柟鏈€鏂扮増
蹇墮mac鐗坴1.3.2 瀹樻柟姝e紡鐗�蹇墮mac鐗坴1.3.2 瀹樻柟姝e紡鐗�
鏋佺偣浜旂瑪Mac鐗�7.13姝e紡鐗�鏋佺偣浜旂瑪Mac鐗�7.13姝e紡鐗�
濯掍綋宸ュ叿
Apple Logic Pro xV10.3.2Apple Logic Pro xV10.3.2
Adobe Premiere Pro CC 2017 mac鐗坴11.0.0 涓枃鐗�Adobe Premiere Pro CC 2017 mac鐗坴11.0.0 涓枃鐗�
鍗冨崈闈欏惉Mac鐗圴9.1.1 瀹樻柟鏈€鏂扮増鍗冨崈闈欏惉Mac鐗圴9.1.1 瀹樻柟鏈€鏂扮増
Mac缃戠粶鐩存挱杞欢(MacTV)v0.121 瀹樻柟鏈€鏂扮増Mac缃戠粶鐩存挱杞欢(MacTV)v0.121 瀹樻柟鏈€鏂扮増
Adobe Fireworks CS6 Mac鐗圕S6瀹樻柟绠€浣撲腑鏂囩増Adobe Fireworks CS6 Mac鐗圕S6瀹樻柟绠€浣撲腑鏂囩増
鍥惧舰鍥惧儚
AutoCAD2015 mac涓枃鐗堟湰v1.0 瀹樻柟姝e紡鐗�AutoCAD2015 mac涓枃鐗堟湰v1.0 瀹樻柟姝e紡鐗�
Adobe Photoshop cs6 mac鐗坴13.0.3 瀹樻柟涓枃鐗�Adobe Photoshop cs6 mac鐗坴13.0.3 瀹樻柟涓枃鐗�
Mac鐭㈤噺缁樺浘杞欢(Sketch mac)v3.3.2 涓枃鐗�Mac鐭㈤噺缁樺浘杞欢(Sketch mac)v3.3.2 涓枃鐗�
Adobe After Effects cs6 mac鐗坴1.0涓枃鐗�Adobe After Effects cs6 mac鐗坴1.0涓枃鐗�
Adobe InDesign cs6 mac1.0 瀹樻柟涓枃鐗�Adobe InDesign cs6 mac1.0 瀹樻柟涓枃鐗�
搴旂敤杞欢
Mac鐗堝揩鎾�1.1.26 瀹樻柟姝e紡鐗圼dmg]Mac鐗堝揩鎾�1.1.26 瀹樻柟姝e紡鐗圼dmg]
Mac璇诲啓NTFS(Paragon NTFS for Mac)12.1.62 瀹樻柟姝e紡鐗�Mac璇诲啓NTFS(Paragon NTFS for Mac)12.1.62 瀹樻柟姝e紡鐗�
杩呴浄10 for macv3.4.1.4368 瀹樻柟鏈€鏂扮増杩呴浄10 for macv3.4.1.4368 瀹樻柟鏈€鏂扮増
Mac涓嬫渶寮哄ぇ鐨勭郴缁熸竻鐞嗗伐鍏�(CleanMyMac for mac)v3.1.1 姝e紡鐗�Mac涓嬫渶寮哄ぇ鐨勭郴缁熸竻鐞嗗伐鍏�(CleanMyMac for mac)v3.1.1 姝e紡鐗�
鑻规灉BootCamp5.1.5640 瀹樻柟鏈€鏂扮増鑻规灉BootCamp5.1.5640 瀹樻柟鏈€鏂扮増

首页编程开发java → Java编程中的编码问题、Java 中的中文编码问题

Java编程中的编码问题、Java 中的中文编码问题

前往专题相关文章发表评论 来源:西西整理时间:2013/9/8 10:23:59字体大小:A-A+

作者:西西点击:79次评论:0次标签: Java

1. 只有 字符到字节 或者 字节到字符 的转换才存在编码转码;

相关链接 版本说明 下载地址
Java SE Development Kit 7 官方正式版 查看
Java SE Runtime Environment(JRE7 64位版) 71多语官方安装版 查看
JD-GUI(Java反编译工具 绿色免费版 查看
JDK 6(Java SE Development Kit) 64位版 查看
Java SE Development Kit (JDK7) 7u67官方正式版 查看
Java Runtime Environment(JRE7) 官方最新版 查看

2. Java String 采用 UTF-16 编码方式存储所有字符。unicode体系采用唯一的码点表示唯一的字符信息, 码点的存储方式有UFT-16、UTF-8 等等。:  A String represents a string in the UTF-16 format in which supplementary characters are represented bysurrogate pairs (see the section Unicode Character Representations in the Character class for more information). Index values refer to char code units, so a supplementary character uses two positions in a String.  The String class provides methods for dealing with Unicode code points (i.e., characters), in addition to those for dealing with Unicode code units (i.e., char values).

3. String只有一种格式,可认为String是独立于编码系统的,通过  getBytes(String charsetName) 可实现编码转换。

4. String对象是内存数据,string之间不存在编码变换问题。 

5. 编码转换场景主要在 I/O , I/O 包括磁盘 I/O 和网络 I/O:文件输入输出、屏幕、数据库、浏览器、服务器。

6. 在内存中倒腾String数据是编码无关的,比如压缩编码。

7. 编码误区: new String(str.getBytes("ISO-8859-1"), "GB18030") 这种用法是无意义的,甚至是错误的。这种用法是用GB18030编码将ISO-8859-1编码格式的字节数据强制转换成unicode码点,不乱码是运气!

9. 数据库JDBC能够处理 数据库数据 <=> String 的正确互换。

9. OutputStreamWriter 和 InputStreamWriter 应该指定编码格式,避免程序依赖操作系统默认编码。

10. 用户从浏览器端发起一个 HTTP 请求,需要存在编码的地方是 URL、Cookie、Parameter。服务器端接受到 HTTP 请求后要解析 HTTP 协议,其中 URI、Cookie 和 POST 表单参数需要解码,服务器端可能还需要读取数据库中的数据,本地或网络中其它地方的文本文件,这些数据都可能存在编码问题,当 Servlet 处理完所有请求的数据后,需要将这些数据再编码通过 Socket 发送到用户请求的浏览器里,再经过浏览器解码成为文本。

11. tomcat: URL 的 URI 部分进行解码的字符集是在 connector 的 <Connector URIEncoding=”UTF-8”/>

12. QueryString(GET 查询参数) 的解码字符集要么是 Header 中 ContentType 中定义的 Charset 要么就是默认的 ISO-8859-1,要使用 ContentType 中定义的编码就要设置 connector 的 <Connector URIEncoding=”UTF-8” useBodyEncodingForURI=”true”/> 中的 useBodyEncodingForURI 设置为 true。

13. 不要在 Header 中传递非 ASCII 字符,如果一定要传递的话,我们可以先将这些字符用 org.apache.catalina.util.URLEncoder 编码然后再添加到 Header 中,这样在浏览器到服务器的传递过程中就不会丢失信息了,如果我们要访问这些项时再按照相应的字符集解码就好了。

14. POST 表单的编解码: 通过 HTTP 的 BODY 传递到服务端的。当我们在页面上点击 submit 按钮时浏览器首先将根据 ContentType 的 Charset 编码格式对表单填的参数进行编码然后提交到服务器端,在服务器端同样也是用 ContentType 中字符集进行解码。所以通过 POST 表单提交的参数一般不会出现问题,而且这个字符集编码是我们自己设置的,可以通过 request.setCharacterEncoding(charset) 来设置。

15. HTTP BODY 的编解码: 当用户请求的资源已经成功获取后,这些内容将通过 Response 返回给客户端浏览器,这个过程先要经过编码再到浏览器进行解码。这个过程的编解码字符集可以通过 response.setCharacterEncoding 来设置,它将会覆盖 request.getCharacterEncoding 的值,并且通过 Header 的 Content-Type 返回客户端,浏览器接受到返回的 socket 流时将通过 Content-Type 的 charset 来解码,如果返回的 HTTP Header 中 Content-Type 没有设置 charset,那么浏览器将根据 Html 的 <meta HTTP-equiv="Content-Type" content="text/html; charset=GBK" /> 中的 charset 来解码。如果也没有定义的话,那么浏览器将使用默认的编码来解码。<%@ page contentType="text/html; charset= GBK" %>。该设置和response.setCharacterEncoding("GBK")等效。

示例代码

/**
 * @author zhenjing
 * 
 * @date 2013-9-7
 */
public class cnCodeTest {

    public static void toHex(char[] b) {
        for (int i = 0; i < b.length; i++) {
            System.out.printf("%x " , (int)b[i]);
        }
        System.out.println();
    }

    public static void toHex(byte[] b) {
        for (int i = 0; i < b.length; i++) {
            System.out.printf("%x " , b[i]);
        }
        System.out.println();
    }
    
    public static void encode() {
        String name = "I am 中文编码";
        toHex(name.toCharArray());
        try {
            byte[] iso8859 = name.getBytes("ISO-8859-1");
            toHex(iso8859);
            byte[] gb2312 = name.getBytes("GB2312");
            toHex(gb2312);
            byte[] gbk = name.getBytes("GBK");
            toHex(gbk);
            byte[] utf16 = name.getBytes("UTF-16");
            toHex(utf16);
            byte[] utf8 = name.getBytes("UTF-8");
            toHex(utf8);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        String cn = "中文编码";  // 这里存在编码转换: 将文件存储字节转成unicode存入String对象内存. 采用文件编码

        char[] charArray = cn.toCharArray();
        byte[] data = cn.getBytes();

        System.out.println("print char array : " + cn);
        toHex(cn.toCharArray());

        cn = "���ı���"; // 这里存在编码转换: 将文件存储字节转成unicode存入String对象内存. 采用文件编码。 
                        // 显示乱码是由于文件采用的编码无法解码文件存储字节数据。故存到String的unicode也是乱码的
        charArray = cn.toCharArray();
        System.out.println("print char array: " + cn);
        toHex(cn.toCharArray());
        
        encode();
    }
}

几种常见的编码格式

为什么要编码

不知道大家有没有想过一个问题,那就是为什么要编码?我们能不能不编码?要回答这个问题必须要回到计算机是如何表示我们人类能够理解的符号的,这些符号也就是我们人类使用的语言。由于人类的语言有太多,因而表示这些语言的符号太多,无法用计算机中一个基本的存储单元—— byte 来表示,因而必须要经过拆分或一些翻译工作,才能让计算机能理解。我们可以把计算机能够理解的语言假定为英语,其它语言要能够在计算机中使用必须经过一次翻译,把它翻译成英语。这个翻译的过程就是编码。所以可以想象只要不是说英语的国家要能够使用计算机就必须要经过编码。这看起来有些霸道,但是这就是现状,这也和我们国家现在在大力推广汉语一样,希望其它国家都会说汉语,以后其它的语言都翻译成汉语,我们可以把计算机中存储信息的最小单位改成汉字,这样我们就不存在编码问题了。

所以总的来说,编码的原因可以总结为:

计算机中存储信息的最小单元是一个字节即 8 个 bit,所以能表示的字符范围是 0~255 个

人类要表示的符号太多,无法用一个字节来完全表示

要解决这个矛盾必须需要一个新的数据结构 char,从 char 到 byte 必须编码

如何“翻译”

明白了各种语言需要交流,经过翻译是必要的,那又如何来翻译呢?计算中提拱了多种翻译方式,常见的有 ASCII、ISO-8859-1、GB2312、GBK、UTF-8、UTF-16 等。它们都可以被看作为字典,它们规定了转化的规则,按照这个规则就可以让计算机正确的表示我们的字符。目前的编码格式很多,例如 GB2312、GBK、UTF-8、UTF-16 这几种格式都可以表示一个汉字,那我们到底选择哪种编码格式来存储汉字呢?这就要考虑到其它因素了,是存储空间重要还是编码的效率重要。根据这些因素来正确选择编码格式,下面简要介绍一下这几种编码格式。

ASCII 码

学过计算机的人都知道 ASCII 码,总共有 128 个,用一个字节的低 7 位表示,0~31 是控制字符如换行回车删除等;32~126 是打印字符,可以通过键盘输入并且能够显示出来。

ISO-8859-1

128 个字符显然是不够用的,于是 ISO 组织在 ASCII 码基础上又制定了一些列标准用来扩展 ASCII 编码,它们是 ISO-8859-1~ISO-8859-15,其中 ISO-8859-1 涵盖了大多数西欧语言字符,所有应用的最广泛。ISO-8859-1 仍然是单字节编码,它总共能表示 256 个字符。

GB2312

它的全称是《信息交换用汉字编码字符集 基本集》,它是双字节编码,总的编码范围是 A1-F7,其中从 A1-A9 是符号区,总共包含 682 个符号,从 B0-F7 是汉字区,包含 6763 个汉字。

GBK

全称叫《汉字内码扩展规范》,是国家技术监督局为 windows95 所制定的新的汉字内码规范,它的出现是为了扩展 GB2312,加入更多的汉字,它的编码范围是 8140~FEFE(去掉 XX7F)总共有 23940 个码位,它能表示 21003 个汉字,它的编码是和 GB2312 兼容的,也就是说用 GB2312 编码的汉字可以用 GBK 来解码,并且不会有乱码。

GB18030

全称是《信息交换用汉字编码字符集》,是我国的强制标准,它可能是单字节、双字节或者四字节编码,它的编码与 GB2312 编码兼容,这个虽然是国家标准,但是实际应用系统中使用的并不广泛。

UTF-16

说到 UTF 必须要提到 Unicode(Universal Code 统一码),ISO 试图想创建一个全新的超语言字典,世界上所有的语言都可以通过这本字典来相互翻译。可想而知这个字典是多么的复杂,关于 Unicode 的详细规范可以参考相应文档。Unicode 是 Java 和 XML 的基础,下面详细介绍 Unicode 在计算机中的存储形式。

UTF-16 具体定义了 Unicode 字符在计算机中存取方法。UTF-16 用两个字节来表示 Unicode 转化格式,这个是定长的表示方法,不论什么字符都可以用两个字节表示,两个字节是 16 个 bit,所以叫 UTF-16。UTF-16 表示字符非常方便,每两个字节表示一个字符,这个在字符串操作时就大大简化了操作,这也是 Java 以 UTF-16 作为内存的字符存储格式的一个很重要的原因。

UTF-8

UTF-16 统一采用两个字节表示一个字符,虽然在表示上非常简单方便,但是也有其缺点,有很大一部分字符用一个字节就可以表示的现在要两个字节表示,存储空间放大了一倍,在现在的网络带宽还非常有限的今天,这样会增大网络传输的流量,而且也没必要。而 UTF-8 采用了一种变长技术,每个编码区域有不同的字码长度。不同类型的字符可以是由 1~6 个字节组成。

UTF-8 有以下编码规则:

如果一个字节,最高位(第 8 位)为 0,表示这是一个 ASCII 字符(00 - 7F)。可见,所有 ASCII 编码已经是 UTF-8 了。

如果一个字节,以 11 开头,连续的 1 的个数暗示这个字符的字节数,例如:110xxxxx 代表它是双字节 UTF-8 字符的首字节。

如果一个字节,以 10 开始,表示它不是首字节,需要向前查找才能得到当前字符的首字节

相关评论

阅读本文后您有什么感想? 已有人给出评价!

  • 8 喜欢喜欢
  • 3 顶
  • 1 难过难过
  • 5 囧
  • 3 围观围观
  • 2 无聊无聊

热门评论

最新评论

发表评论 查看所有评论(0)

昵称:
表情: 高兴 可 汗 我不要 害羞 好 下下下 送花 屎 亲亲
字数: 0/500 (您的评论需要经过审核才能显示)