版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
http://www.chedong.com/tech/hello_unicode.html
关键词：linux java mutlibyte encoding locale i18n i10n chinese ISO-8859-1 GB2312 BIG5 GBK UNICODE
内容摘要：
不知道你有没有这样的感受：为什么PHP很少有乱码问题而用Java做WEB应用却这么麻烦呢？为什么在Google上能用简体中文查到繁体中文，甚至日文的结果？而且用Google的时候发现它居然能自动根据我使用浏览器的语言选择自动调出中文界面？
很多国际化应用的让我理解了这么一个道理：Unicode是为更方便的做国际化应用设计的，而Java核心的字符是基于UNICODE的，这一机制为应用提供了对中文“字”的控制（而不是字节）。但如果不仔细理解其中的规范，这种自由反而会成为累赘，从而导致更多的乱码问题：
关于字符集的准备知识：
ISO-8859-1 GB2312 BIG5 GBK GB18030 UNICODE 为什么会有这么多字符集编码方式？
注意：以下说明不是严格定义，一些比喻仅作为方便理解使用。
假设一个字符就是棋盘上的一个棋子，有其固定的坐标，如果需要区别所有的字符，就需要有足够的棋格容纳不同的“字符”。
英文和欧洲其他语言的单字节字符集 (SingleByte Charsets)：
首先对于ISO-8859系列的字符集都想象成一个：2^8 = 16 * 16 = 256个格子的棋盘，这样所有的西文字符（英文）用这样一个16×16的坐标系就基本可以覆盖全了。而英文实际上只用其中小于128(\x80)的部分就够了。利用大于128部分的空间的不同定义规则形成了真对其他欧洲语言的扩展字符集：ISO-8859-2 ISO-8859-4等……
| ISO-8859-1 |
ISO-8859-7 |
其他语言 |
||||||||||||
|
|
|
GB2312 BIG5 SJIS等多字节字符集（MultiByte Charsets）：
对于亚洲语言来说：汉字这么多，用这么一个256格的小棋盘肯定放不下，所以要区别成千上万的汉字解决办法就是用2个字节（坐标）来定位一个“字”在棋盘上的位置，将以上规则做一个扩展：
- 如果第1个字符是小于128(\x80)的仍和英文字符集编码方式保持兼容；
- 如果第1个字符是大于128(\x80)的，就当成是汉字的第1个字节，这个自己和后面紧跟的1个字节组成一个汉字；
其结果相当于在位于128以上的小棋格里每个小棋格又划分出了一个16×16的小棋盘。这样一个棋盘中的格子数（可能容纳的字符数）就变成了128 + 128 * 256。按照类似的方式有了简体中文的GB2312标准，繁体中文的BIG5字符集和日文的SJIS字符集等，GB2312字符集包含大约有六仟多个常用简体汉字。
| 简体中文 |
日文SJIS |
繁体中文 |
||||||||||||||||||||||||||||||
|
|
|
由此可以看出，所有这些从ASCII扩展式的编码方式中：英文部分都是兼容的，但扩展部分的编码方式是不兼容的，虽然很多字在3种体系中写法一致（比如“中文”这2个字）但在相应字符集中的坐标不一致，所以GB2312编写的页面用BIG5看就变得面目全非了。而且有时候经常在浏览其他非英语国家的页面时（比如包含有德语的人名时）经常出现奇怪的汉字，其实就是扩展位的编码冲突造成的。
我把GBK和GB18030理解成一个小 UNICODE：GBK字符集是GB2312的扩展(K)，GBK里大约有贰万玖仟多个字符，除了保持和GB2312兼容外，繁体中文字，甚至连日文的假名字符也能显示。而GB18030-2000则是一个更复杂的字符集，采用变长字节的编码方式，能够支持更多的字符。关于汉字的编码方式比较详细的定义规范可以参考：
http://www.unihan.com.cn/cjk/ana17.htm
ASCII （英文） ==> 西欧文字 ==> 东欧字符集（俄文，希腊语等） ==> 东亚字符集（GB2312 BIG5 SJIS等）==> 扩展字符集GBK GB18030这个发展过程基本上也反映了字符集标准的发展过程，但这么随着时间的推移，尤其是互联网让跨语言的信息的交互变得越来越多的时候，太多多针对本地语言的编码标准的出现导致一个应用程序的国际化变得成本非常高。尤其是你要编写一个同时包含法文和简体中文的文档，这时候一般都会想到要是用一个通用的字符集能够显示所有语言的所有文字就好了，而且这样做应用也能够比较方便的国际化，为了达到这个目标，即使应用牺牲一些空间和程序效率也是非常值得的。UNICODE就是这样一个通用的解决方案。
UNICODE双字节字符集
所以你可以把UNICODE想象成这样：让所有的字符（包括英文）都用2个字节（2个8位）表示，这样就有了一个2^(8*2) = 256 * 256 = 65536个格子的大棋盘。在这个棋盘中，这样中（简繁）日韩（还包括越南）文字作为CJK字符集都放在一定的区位内，为了减少重复，各种语言中写法一样的字共享一个“棋格”。详细的区位见附录A
Unicode：(DoubleByte Charsets)
| 西 | C中 | 其 | |
| 欧 | J日 | 它 | |
| 英 | K韩 | 语 | |
| 文 | 言 |
什么还要有UTF-8？毕竟互联网70％以上的信息仍然是英文。如果连英文都用2个字节存取(UCS-2)，空间浪费不就太多了？所谓UTF-8就是这样一个为了提高英文存取效率的字符集转换格式：Unicode Transformation Form 8-bit form。用UTF-8，UNICODE的2字节字符用变长个（1－3个字节）表示：
- 对英文，仍然和ASCII一样用1个字节表示，这个字节的值小于128(\x80)；
- 对其他语言的用一个值位于128-256之间的字节开始，再加后面紧跟的2个字节表示，一个字符一共是3个字节；
因此，在应用中程序处理过程中所有字符都是16位（双字节），但在存取转换成字节流时使用UTF-8格式转换，对于英文字符来说和原来用ASCII方式存取时相比大小仍然是一样的，而对中文来说和原来的GB2312编码方式相比，大小为：(3字节/2字节)=1.5倍
小节：
假设英文字符集是一个16×16的棋盘，么其他语言的字符集就是把高位区重新分割的(> 128)的中等棋盘，多种字符集之间互不兼容而UNICODE本身就相当于一个256×256的大棋盘，通过一定规则将英文和其他所有语言的字符都包含在内。
试验1：操作系统语言环境设置对Java应用缺省编码方式的影响
为了了解Java应用的编码处理的机制，首先要了解操作系统对JVM缺省编码方式的影响，因此我做了一个Env.java，用于打印显示不同系统下JVM的属性和系统支持的LOCALE。程序很简单：
/*
* Copyright (c) 2002 Email: chedongATbigfoot.com/chedongATchedong.com
* $Id: hello_unicode.html,v 1.6 2003/11/09 07:57:11 chedong Exp $
*/
import java.util.*;
import java.text.*;
/**
* 目的：
* 显示环境变量和JVM的缺省属性
* 输入：无
* 输出：
* 1 支持的LOCALE
* 2 JVM的缺省属性
*/
public class Env {
/**
* main entrance
*/
public static void main(String[] args) {
System.out.println("Hello, it's: " + new Date());
//print available locales
Locale list[] = DateFormat.getAvailableLocales();
System.out.println("======System available locales:======== ");
for (int i = 0; i < list.length; i++) {
System.out.println(list[i].toString() + "\t" + list[i].getDisplayName());
}
//print JVM default properties
System.out.println("======System property======== ");
System.getProperties().list(System.out);
}
}
最需要注意的是JVM的file.encoding属性，这个属性确定了JVM的缺省的编码/解码方式：从而影响应用中所有字节流==>字符流的解码方式 ，字符流==>字节流的编码方式。
LINUX下的LOCALE可以通过 LANG=zh_CN; LC_ALL=zh_CN.GBK; export LANG LC_ALL 设置。locale 命令可以显示系统当前的环境设置
Windows的LOCALE可以通过 控制面板==>区域设置 设置实现
| GNU/Linux 2.4.x (J2SE1.3.1) LANG=en_US LC_ALL=en_US |
GNU/Linux 2.4.x (J2SE1.3.1) LANG=zh_CN LC_ALL=zh_CN.GBK |
Windows 2000(J2SE1.3.0) 区域设置:中国 中文 |
Windows 2000(J2SE1.3.0) 区域设置:英国 英文 |
Hello, it's: Tue Jul 30 11:05:44 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_BO Spanish (Bolivia) es_AR Spanish (Argentina) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) et Estonian es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko Korean ko_KR Korean (South Korea) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh Chinese zh_CN Chinese (China) zh_HK Chinese (Hong Kong) zh_TW Chinese (Taiwan) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386 java.vm.version=1.3.1_04-b02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/chedong/src/char_test java.runtime.version=1.3.1_04-b02 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Linux java.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=2.4.7-10 user.home=/home/chedong user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.motif.PSPrinterJob file.encoding=ISO-8859-1 java.specification.version=1.3 user.name=chedong java.class.path=/home/chedong/classes java.vm.specification.version=1.0 java.home=/usr/java/jdk1.3.1_04/jre user.language=en java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.version=1.3.1_04 java.ext.dirs=/usr/java/jdk1.3.1_04/jre/lib/ext sun.boot.class.path=/usr/java/jdk1.3.1_04/jre/lib/rt.jar:... java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=US sun.cpu.isalist= |
Hello, it's: Tue Jul 30 11:07:34 CST 2002 ======System available locales:======== en 英文 en_US 英文 (美国) ar 阿拉伯文 ar_AE 阿拉伯文 (阿拉伯联合酋长国) ar_BH 阿拉伯文 (巴林) ar_DZ 阿拉伯文 (阿尔及利亚) ar_EG 阿拉伯文 (埃及) ar_IQ 阿拉伯文 (伊拉克) ar_JO 阿拉伯文 (约旦) ar_KW 阿拉伯文 (科威特) ar_LB 阿拉伯文 (黎巴嫩) ar_LY 阿拉伯文 (利比亚) ar_MA 阿拉伯文 (摩洛哥) ar_OM 阿拉伯文 (阿曼) ar_QA 阿拉伯文 (卡塔尔) ar_SA 阿拉伯文 (沙特阿拉伯) ar_SD 阿拉伯文 (苏丹) ar_SY 阿拉伯文 (叙利亚) ar_TN 阿拉伯文 (突尼斯) ar_YE 阿拉伯文 (也门) be 白俄罗斯文 be_BY 白俄罗斯文 (白俄罗斯) bg 保加利亚文 bg_BG 保加利亚文 (保加利亚) ca 加泰罗尼亚文 ca_ES 加泰罗尼亚文 (西班牙) ca_ES_EURO 加泰罗尼亚文 (西班牙,Euro) cs 捷克文 cs_CZ 捷克文 (捷克共和国) da 丹麦文 da_DK 丹麦文 (丹麦) de 德文 de_AT 德文 (奥地利) de_AT_EURO 德文 (奥地利,Euro) de_CH 德文 (瑞士) de_DE 德文 (德国) de_DE_EURO 德文 (德国,Euro) de_LU 德文 (卢森堡) de_LU_EURO 德文 (卢森堡,Euro) el 希腊文 el_GR 希腊文 (希腊) en_AU 英文 (澳大利亚) en_CA 英文 (加拿大) en_GB 英文 (英国) en_IE 英文 (爱尔兰) en_IE_EURO 英文 (爱尔兰,Euro) en_NZ 英文 (新西兰) en_ZA 英文 (南非) es 西班牙文 es_BO 西班牙文 (玻利维亚) es_AR 西班牙文 (阿根廷) es_CL 西班牙文 (智利) es_CO 西班牙文 (哥伦比亚) es_CR 西班牙文 (哥斯达黎加) es_DO 西班牙文 (多米尼加共和国) es_EC 西班牙文 (厄瓜多尔) es_ES 西班牙文 (西班牙) es_ES_EURO 西班牙文 (西班牙,Euro) es_GT 西班牙文 (危地马拉) es_HN 西班牙文 (洪都拉斯) es_MX 西班牙文 (墨西哥) es_NI 西班牙文 (尼加拉瓜) et 爱沙尼亚文 es_PA 西班牙文 (巴拿马) es_PE 西班牙文 (秘鲁) es_PR 西班牙文 (波多黎哥) es_PY 西班牙文 (巴拉圭) es_SV 西班牙文 (萨尔瓦多) es_UY 西班牙文 (乌拉圭) es_VE 西班牙文 (委内瑞拉) et_EE 爱沙尼亚文 (爱沙尼亚) fi 芬兰文 fi_FI 芬兰文 (芬兰) fi_FI_EURO 芬兰文 (芬兰,Euro) fr 法文 fr_BE 法文 (比利时) fr_BE_EURO 法文 (比利时,Euro) fr_CA 法文 (加拿大) fr_CH 法文 (瑞士) fr_FR 法文 (法国) fr_FR_EURO 法文 (法国,Euro) fr_LU 法文 (卢森堡) fr_LU_EURO 法文 (卢森堡,Euro) hr 克罗地亚文 hr_HR 克罗地亚文 (克罗地亚) hu 匈牙利文 hu_HU 匈牙利文 (匈牙利) is 冰岛文 is_IS 冰岛文 (冰岛) it 意大利文 it_CH 意大利文 (瑞士) it_IT 意大利文 (意大利) it_IT_EURO 意大利文 (意大利,Euro) iw 希伯来文 iw_IL 希伯来文 (以色列) ja 日文 ja_JP 日文 (日本) ko 朝鲜文 ko_KR 朝鲜文 (南朝鲜) lt 立陶宛文 lt_LT 立陶宛文 (立陶宛) lv 拉托维亚文(列托) lv_LV 拉托维亚文(列托) (拉脱维亚) mk 马其顿文 mk_MK 马其顿文 (马其顿王国) nl 荷兰文 nl_BE 荷兰文 (比利时) nl_BE_EURO 荷兰文 (比利时,Euro) nl_NL 荷兰文 (荷兰) nl_NL_EURO 荷兰文 (荷兰,Euro) no 挪威文 no_NO 挪威文 (挪威) no_NO_NY 挪威文 (挪威,Nynorsk) pl 波兰文 pl_PL 波兰文 (波兰) pt 葡萄牙文 pt_BR 葡萄牙文 (巴西) pt_PT 葡萄牙文 (葡萄牙) pt_PT_EURO 葡萄牙文 (葡萄牙,Euro) ro 罗马尼亚文 ro_RO 罗马尼亚文 (罗马尼亚) ru 俄文 ru_RU 俄文 (俄罗斯) sh 塞波尼斯-克罗地亚文 sh_YU 塞波尼斯-克罗地亚文 (南斯拉夫) sk 斯洛伐克文 sk_SK 斯洛伐克文 (斯洛伐克) sl 斯洛文尼亚文 sl_SI 斯洛文尼亚文 (斯洛文尼亚) sq 阿尔巴尼亚文 sq_AL 阿尔巴尼亚文 (阿尔巴尼亚) sr 塞尔维亚文 sr_YU 塞尔维亚文 (南斯拉夫) sv 瑞典文 sv_SE 瑞典文 (瑞典) th 泰文 th_TH 泰文 (泰国) tr 土耳其文 tr_TR 土耳其文 (土耳其) uk 乌克兰文 uk_UA 乌克兰文 (乌克兰) zh 中文 zh_CN 中文 (中国) zh_HK 中文 (香港) zh_TW 中文 (台湾) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386 java.vm.version=1.3.1_04-b02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/chedong/src/char_test java.runtime.version=1.3.1_04-b02 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Linux java.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=2.4.7-10 user.home=/home/chedong user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.motif.PSPrinterJob file.encoding=GBK java.specification.version=1.3 user.name=chedong java.class.path=/home/chedong/classes java.vm.specification.version=1.0 java.home=/usr/java/jdk1.3.1_04/jre user.language=zh java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.version=1.3.1_04 java.ext.dirs=/usr/java/jdk1.3.1_04/jre/lib/ext sun.boot.class.path=/usr/java/jdk1.3.1_04/jre/lib/rt.jar:... java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=CN sun.cpu.isalist= |
Hello, it's: Tue Jul 30 11:49:36 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_AR Spanish (Argentina) es_BO Spanish (Bolivia) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et Estonian et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko 韩文 ko_KR 韩文 (大韩民国) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh 中文 zh_CN 中文 (中华人民共和国) zh_HK 中文 (香港) zh_TW 中文 (台湾) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vm.version=1.3.0_02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=D:\java\src\char_test java.runtime.version=1.3.0_02 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment os.arch=x86 java.io.tmpdir=D:\TEMP\ line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Windows 98 java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=4.90 user.home=C:\WINDOWS user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.windows.WPrinterJob file.encoding=GBK java.specification.version=1.3 user.name=Sicci java.class.path=d:\java\classes java.vm.specification.version=1.0 java.home=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_02 user.language=zh java.specification.vendor=Sun Microsystems Inc. awt.toolkit=sun.awt.windows.WToolkit java.vm.info=mixed mode java.version=1.3.0_02 java.ext.dirs=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... sun.boot.class.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vendor=Sun Microsystems Inc. file.separator=\ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=CN sun.cpu.isalist=pentium i486 i386 |
Hello, it's: Tue Jul 30 11:53:27 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_AR Spanish (Argentina) es_BO Spanish (Bolivia) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et Estonian et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko Korean ko_KR Korean (South Korea) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh Chinese zh_CN Chinese (China) zh_HK Chinese (Hong Kong) zh_TW Chinese (Taiwan) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vm.version=1.3.0_02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=D:\java\src\char_test java.runtime.version=1.3.0_02 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment os.arch=x86 java.io.tmpdir=D:\TEMP\ line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Windows 98 java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=4.90 user.home=C:\WINDOWS user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.windows.WPrinterJob file.encoding=Cp1252 java.specification.version=1.3 user.name=Sicci java.class.path=d:\java\classes java.vm.specification.version=1.0 java.home=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_02 user.language=en java.specification.vendor=Sun Microsystems Inc. awt.toolkit=sun.awt.windows.WToolkit java.vm.info=mixed mode java.version=1.3.0_02 java.ext.dirs=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... sun.boot.class.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vendor=Sun Microsystems Inc. file.separator=\ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=GB sun.cpu.isalist=pentium i486 i386 |
结论1：
JVM的缺省编码方式由系统的“本地语言环境”设置确定，和操作系统的类型无关 。所以当设置成相同的LOCALE时，Linux和Windows下的缺省编码方式是没有区别的（可以认为cp1252=ISO-8859-1都是一样的西文编码方式，只包含255以下的拉丁字符），因此后面的测试2我只列出了GNU/Linux下LOCALE分别设置成zh_CN和en_US的测试结果输出。以下测试如果在Windows下分别按照不同的区域和字符集设置后试验的输出是一样的。
试验2：Java的输入输出过程中的字节流到字符流的转换过程
通过这个HelloUnicode.java程序，演示说明"Hello world 世界你好"这个字符串（16个字符）在不同缺省系统编码方式下的处理效果。在编码/解码的每个步骤之后，都打印出了相应字符串每个字符(Charactor)的byte值，short值和所在的UNICODE区间。
| LANG=en_US LC_ALL=en_US | LANG=zh_CN LC_ALL=zh_CN.GBK |
========testing1: write hello world to files======== [test 1-1]: with system default encoding=ISO-8859-1 string=Hello world 世界你好 length=20 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENT char[13]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENT char[14]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENT char[15]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENT char[16]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENT char[17]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENT char[18]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENT char[19]='? byte=-61 \uFFFFFFC3 short=195 \uC3 LATIN_1_SUPPLEMENT 第1步：在英文编码环境下，虽然屏幕上正确的显示了中文， 但实际上它打印的是“半个”汉字，将结果写入第1个文件 hello.orig.html [test 1-2]: getBytes with platform default encoding and decoding as gb2312: string=Hello world ???? length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='?' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='?' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='?' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='?' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS 按系统缺省编码重新变成字节流，然后按照GB2312方式解码，这里虽然打印出的是问号 （因为当前的英文环境下系统对于255以上的字符是不知道用什么字符表示的，因此全部用?显示） 但从相应的UNICODE MAPPING和SHORT值我们可以知道字符是正确的中文 但下一步的写入第2个文件html.gb2312.html， 没有指定编码方式（按系统缺省的ISO-8859-1编码方式）， 因此从后面的测试2－2读取的结果是真的'？'了 [test 1-3]: convert string to UTF8 string=Hello world 涓栫晫浣犲ソ length=24 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='? byte=-28 \uFFFFFFE4 short=228 \uE4 LATIN_1_SUPPLEMENT char[13]='? byte=-72 \uFFFFFFB8 short=184 \uB8 LATIN_1_SUPPLEMENT char[14]='? byte=-106 \uFFFFFF96 short=150 \u96 LATIN_1_SUPPLEMENT char[15]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENT char[16]='? byte=-107 \uFFFFFF95 short=149 \u95 LATIN_1_SUPPLEMENT char[17]='? byte=-116 \uFFFFFF8C short=140 \u8C LATIN_1_SUPPLEMENT char[18]='? byte=-28 \uFFFFFFE4 short=228 \uE4 LATIN_1_SUPPLEMENT char[19]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENT char[20]='? byte=-96 \uFFFFFFA0 short=160 \uA0 LATIN_1_SUPPLEMENT char[21]='? byte=-27 \uFFFFFFE5 short=229 \uE5 LATIN_1_SUPPLEMENT char[22]='? byte=-91 \uFFFFFFA5 short=165 \uA5 LATIN_1_SUPPLEMENT char[23]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENT 第3个试验，将字符流按照UTF8方式编码后，写入第3个测试文件hello.utf8.html， 我们可以看到UTF8对英文没有影响，但对于其他文字使用了3字节编码方式， 因此比GB2312编码方式的存储要大50%， ========Testing2: reading and decoding from files======== [test 2-1]: read hello.orig.html: decoding with system default encoding string=Hello world 世界你好 length=20 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENT char[13]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENT char[14]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENT char[15]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENT char[16]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENT char[17]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENT char[18]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENT char[19]='? byte=-61 \uFFFFFFC3 short=195 \uC3 LATIN_1_SUPPLEMENT 按系统从中间存储hello.orig.html文件中读取相应文件， 虽然是按字节方式（半个“字”）读取的，但由于能完整的还原，因此输出显示没有错误。 其实PHP等应用很少出现字符集问题其实就是这个原因，全程都是按字节流方式处理， 很好的还原了输入，但这样处理的同时也失去了对字符的控制 [test 2-2]: read hello.gb2312.html: decoding as GB2312 string=Hello world ???? length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='?' byte=63 \u3F short=63 \u3F BASIC_LATIN char[13]='?' byte=63 \u3F short=63 \u3F BASIC_LATIN char[14]='?' byte=63 \u3F short=63 \u3F BASIC_LATIN char[15]='?' byte=63 \u3F short=63 \u3F BASIC_LATIN 最惨的就是输出的时候这些'?'真的是问号char(63)了， 数据如果是这样就真的没救了 [test 2-3]: read hello.utf8.html: decoding as UTF8 string=Hello world ???? length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='?' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='?' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='?' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='?' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS great! 字符虽然显示为'?'，但实际上字符的解码是正确的， 从相应的UNICODE MAPPING就可以看的出来。 |
========Testing1: write hello world to files======== [test 1-1]: with system default encoding=GBK string=Hello world 世界你好 length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS 注意：在新的语言环境中做以上测试需要将源程序重新编译， 最早的字节流到字符流的解码过程从JavaC编译源文件就开始了， 这个测试和刚才最大的不同在于源文件中的“世界你好”这4个字是否按中文编码方式 编译导程序里的，而不是按字节方式编译成8个字符（实际上对应的是8个字节）在程序里。 [test 1-2]: getBytes with platform default encoding and decoding as gb2312: string=Hello world 世界你好 length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS 在中文环境下，解码和上面缺省的编码是一致的，因此输出一致 [test 1-3]: convert string to UTF8 string=Hello world 涓栫晫浣犲ソ length=18 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='涓' byte=-109 \uFFFFFF93 short=28051 \u6D93 CJK_UNIFIED_IDEOGRAPHS char[13]='栫' byte=43 \u2B short=26667 \u682B CJK_UNIFIED_IDEOGRAPHS char[14]='晫' byte=107 \u6B short=26219 \u666B CJK_UNIFIED_IDEOGRAPHS char[15]='浣' byte=99 \u63 short=28003 \u6D63 CJK_UNIFIED_IDEOGRAPHS char[16]='犲' byte=-78 \uFFFFFFB2 short=29362 \u72B2 CJK_UNIFIED_IDEOGRAPHS char[17]='ソ' byte=-67 \uFFFFFFBD short=12477 \u30BD KATAKANA 其实我们用于测试的终端窗口就是一个GBK字符集的应用， 这个输出其实都是把UNICODE按GBK字符集解码的效果。 ========Testing2: reading and decoding from files======== [test 2-1]: read hello.orig.html: decoding with system default encoding string=Hello world 世界你好 length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS [test 2-2]: read hello.gb2312.html: decoding as GB2312 string=Hello world 世界你好 length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS [test 2-3]: read hello.utf8.html: decoding as UTF8 string=Hello world 世界你好 length=16 char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN char[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS 结论：如果后台数据采用UNICODE方式的存储 然后根据需要指定字符集编码、解码方式，则应用几乎可以不受前端应用所处 环境字符集设置的影响 |
试验2的一些结论：
- 所有的应用都是按照字节流=>字符流=>字节流方式进行的处理的：
byte_stream ==[input decoding]==> unicode_char_stream ==[output encoding]==> byte_stream； - 在Java字节流到字符流（或者反之）都是含有隐含的解码处理的（缺省是按照系统缺省编码方式）；
- 最早的字节流解码过程从javac的代码编译就开始了；
- Java中的字符character存储单位是双字节的UNICODE；
试验3：WEB应用中的输入输出中的编码问题：Java是为做国际化应用设计的，Servlet应根据浏览器语言设置自动切换字符集配置
首先一个概念：即使是基于Java的WEB应用，在服务器和客户端之间传递的仍然是字节流，比如我从一个中文客户端的浏览器表单中提交“世界你好”这4个中文字到服务器时：首先浏览器按照GBK方式编码成字节流CA C0 BD E7 C4 E3 BA C3，然后8个字节按照URLEncoding的规范转成：%CA%C0%BD%E7%C4%E3%BA%C3，服务器端的Servlet接收到请求后应该按什么解码处理，输出时又应该按什么方式编码行字节流呢？在目前的Servlet的规范中，如果不指定的话通过WEB提交时的输入ServletRequest和输出时的 ServletResponse缺省都是ISO-8859-1方式编/码解码的（注意，这里的编码/解码方式是和操作系统环境中的语言环境是无关的）。因此，即使服务器操作系统的语言环境是中文，上面输入的请求仍然按英文解码成8个UNICODE字符，输出时仍按照英文再编码成8个字节，虽然这样在浏览器端如果设置是中文能够正确显示，但实际上读写的是“字节”，正确的方式是应该根据客户端浏览器设置ServletRequest和 ServletResponse用相应语言的编码方式进行输入解码/输入编码，HelloUnicodeServlet.java就是这样一个监测客户端浏览器语言设置的例子：
当根据浏览器的头信息中的"Accept-Language"为zh-cn（中文）时，设置请求的解码方式和输出的字符集编码方式使用GBK：
//auto detect broswer's languages
String clientLanguage = req.getHeader("Accept-Language");
//for Simplied Chinese
if ( clientLanguage.equals("zh-cn") ) {
req.setCharacterEncoding("GBK");
res.setContentType("text/html; charset=GBK");
}
输出为：
'世界你好' length=4 ServletRequest's Charset Encoding = GBK ServletResponse's Charset Encoding = GBK char[0]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS char[1]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS char[2]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS char[3]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS
再做一个试验：把程序开头部分的浏览器自动检测功能注释掉，再次的输出结果就是和目前很多应用一样其实是按ISO-8859-1方式解码/编码的“字节应用”了：
'世界你好' length=8 ServletRequest's Charset Encoding = null ServletResponse's Charset Encoding = ISO-8859-1 char[0]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENT char[1]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENT char[2]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENT char[3]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENT char[4]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENT char[5]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENT char[6]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENT char[7]='? byte=-61 \uFFFFFFC3 short=195 \uC3 LATIN_1_SUPPLEMENT虽然这样的输出结果如果在浏览器中设置用中文字符集也能正确显示，但实际上处理的已经是“字节”而不是处理中文“字符”了。ServletRequest 和 ServletResponse 缺省使用ISO-8859-1字符集解码/编码的具体定义请参考：
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html#setCharacterEncoding(java.lang.String)
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html#setContentType()
以前能够配置让一个WEB应用能够在GBK方式编码的中文Windows2000服务器上和按ISO-8859-1方式编码的GNU/Linux上都能够正确的显示中文一直让我迷惑了很久。我仔细想了一下，后来终于想明白了，在一个国际化的应用中：ServletRequest和 ServletResponse的编码/解码方式的确不应该根据服务器设置成固定的字符集，而应该是面向客户端语言环境进行输入/输出编码方式的自适应。一个按照国际化规范设计的WEB应用中：
- 在Servlet 的源代码中尽量不要有中文：因为在MVC模式中，Servlet主要是控制器（C）的角色，因此，应该通过ResourceBundle机制由 Servlet控制转向到相应的显示器（JSP或者XSLT）中，所以应该将与本地界面语言相关的界面显示的部分从Servlet和后台的模块中完全剥离出来，放到相应的ResourceBundle文件中或者XSLT文件中。这样源程序里完全是英文，编译时完全不需要考虑字符集的问题。
如果Servlet实在需要包含中文，则需要设置应用服务器的Javac编译选项，加上-encoding选项成系统缺省的字符集，如果把用中文编写的字符按照英文方式解码编译，然后再按照英文方式输出，虽然结果表面正确，实际上都成了面向“字节”编程。
- 在Servlet层，应该像GOOGLE搜索引擎那样，设计成能够根据客户端浏览器的语言环境自适应输出，为了判断浏览器的语言Servlet中应该有类似以下的代码：
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { //从HTTP请求的头信息中获取客户端的语言设置 String clientLanguage = req.getHeader("Accept-Language"); //简体中文浏览器 if ( clientLanguage.equals("zh-cn") ) { req.setCharacterEncoding("GBK"); res.setContentType("text/html; charset=GBK"); } //繁体中文浏览器 else if ( clientLanguage.equals("zh-tw") ) { req.setCharacterEncoding("BIG5"); res.setContentType("text/html; charset=BIG5"); } //日文浏览器 else if ( clientLanguage.equals("jp") ) { req.setCharacterEncoding("SJIS"); res.setContentType("text/html; charset=SJIS"); } //缺省认为是英文浏览器 else { req.setCharacterEncoding("ISO-8859-1"); res.setContentType("text/html; charset=ISO-8859-1"); } ... //设置好request的解码方式和response的编码方式后，进行后续的操作。 //比如再转向到HelloWorld.gbk.jsp HelloWorld.big5.jsp HelloWorld.jis.jsp等 }
而SERVLET缺省将字符集设置为ISO-8859-1也许是标准制定者认为英文的浏览器占大多数吧（而且按照ISO-8859-1方式输出界面往往也是正确的）。
结论：
过以上几个Java试验程序得出的一些结论：
- Java 环境是基于操作系统上的一个虚拟机应用，因此，如果操作系统遵循国际化规范：JVM的缺省编码方式可以通过修改操作系统的LOCALE设置实现。对于一个 Java应用来说，只要将LINUX的缺省编码方式设置成GBK，其文字编码处理应该和中文Windows平台上的表现是一致的。
redhat 6.X使用linux内核的是基于glibc2.1.X，不支持中文LOCALE，因此无法通过改变LOCALE设置改变JVM的缺省编码方式，linux内核2.4开始基于glibc.2.2.x，对中文LOCALE有了比较好的支持。 - 不同的JVM对字符集的支持程度不同：
比如：IBM的JVM1.3.0开始支持GB18030，SUN的JVM从1.4开始支持GB18030 - 正确的编码方式不一定表示能正确的显示，正确的显示还要需要相应的前端显示系统（字库）的支持
但对于Linux上的服务应用来说，往往只要能确认字符正确的按照指定的方式编码就够了 - 如果应用的是基于UNICODE的编码方式处理并使用UTF8字符集做集中存储，这样最便于根据客户端语言环境做本地化输出；
根据以上结论，设计一个适应多语言环境的应用，可以考虑一下2个应用处理模式：
- （客户端应用或本地化应用）根据LOCALE，让Java应用根据系统LOCALE的缺省
分享到：
发表评论
相关推荐
毕业设计选题 -未来生鲜运输车设计.pptx
内容概要：本文详细探讨了基于樽海鞘算法（SSA）优化的极限学习机（ELM）在回归预测任务中的应用，并与传统的BP神经网络、广义回归神经网络（GRNN）以及未优化的ELM进行了性能对比。首先介绍了ELM的基本原理，即通过随机生成输入层与隐藏层之间的连接权重及阈值，仅需计算输出权重即可快速完成训练。接着阐述了SSA的工作机制，利用樽海鞘群体觅食行为优化ELM的输入权重和隐藏层阈值，从而提高模型性能。随后分别给出了BP、GRNN、ELM和SSA-ELM的具体实现代码，并通过波士顿房价数据集和其他工业数据集验证了各模型的表现。结果显示，SSA-ELM在预测精度方面显著优于其他三种方法，尽管其训练时间较长，但在实际应用中仍具有明显优势。 适合人群：对机器学习尤其是回归预测感兴趣的科研人员和技术开发者，特别是那些希望深入了解ELM及其优化方法的人。 使用场景及目标：适用于需要高效、高精度回归预测的应用场景，如金融建模、工业数据分析等。主要目标是提供一种更为有效的回归预测解决方案，尤其是在处理大规模数据集时能够保持较高的预测精度。 其他说明：文中提供了详细的代码示例和性能对比图表，帮助读者更好地理解和复现实验结果。同时提醒使用者注意SSA参数的选择对模型性能的影响，建议进行参数敏感性分析以获得最佳效果。
2025年中国生成式AI大会PPT（4-1）
内容概要：本文详细介绍了基于Simulink平台构建无刷直流电机（BLDC）双闭环调速系统的全过程。首先阐述了双闭环控制系统的基本架构，即外层速度环和内层电流环的工作原理及其相互关系。接着深入探讨了PWM生成模块的设计，特别是占空比计算方法的选择以及三角波频率的设定。文中还提供了详细的电机参数设置指导，如转动惯量、电感、电阻等，并强调了参数选择对系统性能的影响。此外，针对PI控制器的参数整定给出了具体的公式和经验值，同时分享了一些实用的调试技巧，如避免转速超调、处理启动抖动等问题的方法。最后，通过仿真实验展示了系统的稳定性和鲁棒性，验证了所提出方法的有效性。 适用人群：从事电机控制研究的技术人员、自动化工程领域的研究生及科研工作者。 使用场景及目标：适用于需要深入了解和掌握无刷直流电机双闭环调速系统设计与优化的人群。主要目标是帮助读者学会利用Simulink进行BLDC电机控制系统的建模、仿真和参数优化，从而提高系统的稳定性和响应速度。 其他说明：文章不仅提供了理论知识，还包括了许多实践经验和技术细节，有助于读者更好地理解和应用相关技术。
内容概要：本文详细介绍了西门子S7-1200 PLC与施耐德ATV310/312变频器通过Modbus RTU进行通讯的具体实现步骤和调试技巧。主要内容涵盖硬件接线、通讯参数配置、控制启停、设定频率、读取运行参数的方法以及常见的调试问题及其解决方案。文中提供了具体的代码示例，帮助读者理解和实施通讯程序。此外，还强调了注意事项，如地址偏移量、数据格式转换和超时匹配等。 适合人群：从事工业自动化领域的工程师和技术人员，尤其是那些需要将西门子PLC与施耐德变频器进行集成的工作人员。 使用场景及目标：适用于需要通过Modbus RTU协议实现PLC与变频器通讯的工程项目。目标是确保通讯稳定可靠，掌握解决常见问题的方法，提高调试效率。 其他说明：文中提到的实际案例和调试经验有助于读者避免常见错误，快速定位并解决问题。建议读者在实践中结合提供的代码示例和调试工具进行操作。
内容概要：本文详细介绍了如何使用Verilog在FPGA上实现IIC（Inter-Integrated Circuit）主从机驱动。主要内容包括从机和主机的设计，特别是状态机的实现、寄存器读取、时钟分频策略、SDA线的三态控制等关键技术。文中还提供了详细的代码片段，展示了从机地址匹配逻辑、主机时钟生成逻辑、顶层模块的连接方法以及仿真实验的具体步骤。此外，文章讨论了一些常见的调试问题，如总线竞争、时序不匹配等，并给出了相应的解决方案。 适合人群：具备一定FPGA开发基础的技术人员，尤其是对IIC协议感兴趣的嵌入式系统开发者。 使用场景及目标：适用于需要在FPGA平台上实现高效、可靠的IIC通信的应用场景。主要目标是帮助读者掌握IIC协议的工作原理，能够独立完成IIC主从机系统的开发和调试。 其他说明：文章不仅提供了理论讲解，还包括了大量的实战经验和代码实例，有助于读者更好地理解和应用所学知识。同时，文章还提供了一个思考题，引导读者进一步探索多主设备仲裁机制的设计思路。
内容概要：本文介绍了一款基于C#开发的拖拽式Halcon可视化抓边、抓圆控件，旨在简化机器视觉项目中的测量任务。该控件通过拖拽操作即可快速生成测量区域，自动完成边缘坐标提取，并提供实时反馈。文中详细描述了控件的工作原理和技术细节，如坐标系转换、卡尺生成、边缘检测算法封装以及动态参数调试等功能。此外，还讨论了一些常见问题及其解决方案，如坐标系差异、内存管理等。 适合人群：从事机器视觉开发的技术人员，尤其是熟悉C#和Halcon的开发者。 使用场景及目标：适用于需要频繁进行边缘和圆形特征测量的工业自动化项目，能够显著提高测量效率并减少编码工作量。主要目标是将复杂的测量任务转化为简单的拖拽操作，使非专业人员也能轻松完成测量配置。 其他说明：该控件已开源发布在GitHub上，提供了完整的源代码和详细的使用指南。未来计划扩展更多高级功能，如自动路径规划和亚像素级齿轮齿距检测等。
内容概要：本文详细介绍了西门子200Smart PLC与维纶触摸屏在某疫苗车间控制系统的具体应用，涵盖配液、发酵、纯化及CIP清洗四个主要工艺环节。文中不仅展示了具体的编程代码和技术细节，还分享了许多实战经验和调试技巧。例如，在配液罐中，通过模拟量处理确保温度和液位的精确控制；发酵罐部分，着重讨论了PID参数整定和USS通讯控制变频器的方法；纯化过程中，强调了双PID串级控制的应用；CIP清洗环节，则涉及复杂的定时器逻辑和阀门联锁机制。此外，文章还提到了一些常见的陷阱及其解决方案，如通讯干扰、状态机切换等问题。 适合人群：具有一定PLC编程基础的技术人员，尤其是从事工业自动化领域的工程师。 使用场景及目标：适用于需要深入了解PLC与触摸屏集成控制系统的工程师，帮助他们在实际项目中更好地理解和应用相关技术和方法，提高系统的稳定性和可靠性。 其他说明：文章提供了大量实战经验和代码片段，有助于读者快速掌握关键技术点，并避免常见错误。同时，文中提到的一些优化措施和调试技巧对提升系统性能非常有帮助。
计算机网络课程的结课设计是使用思科模拟器搭建一个中小型校园网，当时花了几天时间查阅相关博客总算是做出来了，现在免费上传CSDN，希望小伙伴们能给博客一套三连支持
《芋道开发指南文档-2023-10-27更新》是针对软件开发者和IT专业人士的一份详尽的资源集合，旨在提供最新的开发实践、范例代码和最佳策略。这份2023年10月27日更新的文档集，包含了丰富的模板和素材，帮助开发者在日常工作中提高效率，保证项目的顺利进行。 让我们深入探讨这份文档的可能内容。"芋道"可能是一个开源项目或一个专业的技术社区，其开发指南涵盖了多个方面，例如： 1. **编程语言指南**：可能包括Java、Python、JavaScript、C++等主流语言的编码规范、最佳实践以及常见问题的解决方案。 2. **框架与库的应用**：可能会讲解React、Vue、Angular等前端框架，以及Django、Spring Boot等后端框架的使用技巧和常见应用场景。 3. **数据库管理**：涵盖了SQL语言的基本操作，数据库设计原则，以及如何高效使用MySQL、PostgreSQL、MongoDB等数据库系统。 4. **版本控制**：详细介绍了Git的工作流程，分支管理策略，以及与其他开发工具（如Visual Studio Code、IntelliJ IDEA）的集成。 5. **持续集成与持续部署(CI/CD)**：包括Jenkins、Travis CI、GitHub Actions等工具的配置和使用，以实现自动化测试和部署。 6. **云服务与容器化**：可能涉及AWS、Azure、Google Cloud Platform等云计算平台的使用，以及Docker和Kubernetes的容器化部署实践。 7. **API设计与测试**：讲解RESTful API的设计原则，Swagger的使用，以及Postman等工具进行API测试的方法。 8. **安全性与隐私保护**：涵盖OAuth、JWT认证机制，HTTPS安全通信，以及防止SQL注入、
内容概要：本文介绍了一种先进的综合能源系统优化调度模型，该模型将风电、光伏、光热发电等新能源与燃气轮机、燃气锅炉等传统能源设备相结合，利用信息间隙决策（IGDT）处理不确定性。模型中引入了P2G（电转气）装置和碳捕集技术，实现了碳经济闭环。通过多能转换和储能系统的协同调度，提高了系统的灵活性和鲁棒性。文中详细介绍了模型的关键组件和技术实现，包括IGDT的鲁棒性参数设置、P2G与碳捕集的协同控制、储能系统的三维协同调度等。此外，模型展示了在极端天气和负荷波动下的优异表现，显著降低了碳排放成本并提高了能源利用效率。 适合人群：从事能源系统优化、电力调度、碳交易等相关领域的研究人员和工程师。 使用场景及目标：适用于需要处理多种能源形式和不确定性的综合能源系统调度场景。主要目标是提高系统的灵活性、鲁棒性和经济效益，减少碳排放。 其他说明：模型具有良好的扩展性，可以通过修改配置文件轻松集成新的能源设备。代码中包含了详细的注释和公式推导，便于理解和进一步改进。
毕业设计的论文撰写、终期答辩相关的资源
该是一个在 Kaggle 上发布的数据集，专注于 2024 年出现的漏洞（CVE）信息。以下是关于该数据集的详细介绍：该数据集收集了 2024 年记录在案的各类漏洞信息，涵盖了漏洞的利用方式（Exploits）、通用漏洞评分系统（CVSS）评分以及受影响的操作系统（OS）。通过整合这些信息，研究人员和安全专家可以全面了解每个漏洞的潜在威胁、影响范围以及可能的攻击途径。数据主要来源于权威的漏洞信息平台，如美国国家漏洞数据库（NVD）等。这些数据经过整理和筛选后被纳入数据集，确保了信息的准确性和可靠性。数据集特点：全面性：涵盖了多种操作系统（如 Windows、Linux、Android 等）的漏洞信息，反映了不同平台的安全状况。实用性：CVSS 评分提供了漏洞严重程度的量化指标，帮助用户快速评估漏洞的优先级。同时，漏洞利用信息（Exploits）为安全研究人员提供了攻击者可能的攻击手段，有助于提前制定防御策略。时效性：专注于 2024 年的漏洞数据，反映了当前网络安全领域面临的新挑战和新趋势。该数据集可用于多种研究和实践场景： 安全研究：研究人员可以利用该数据集分析漏洞的分布规律、攻击趋势以及不同操作系统之间的安全差异，为网络安全防护提供理论支持。 机器学习与数据分析：数据集中的结构化信息适合用于机器学习模型的训练，例如预测漏洞的 CVSS 评分、识别潜在的高危漏洞等。 企业安全评估：企业安全团队可以参考该数据集中的漏洞信息，结合自身系统的实际情况，进行安全评估和漏洞修复计划的制定。
内容概要：本文档作为建模大赛的入门指南，详细介绍了建模大赛的概念、类型、竞赛流程、核心步骤与技巧，并提供实战案例解析。文档首先概述了建模大赛，指出其以数学、计算机技术为核心，主要分为数学建模、3D建模和AI大模型竞赛三类。接着深入解析了数学建模竞赛，涵盖组队策略（如三人分别负责建模、编程、论文写作）、时间安排（72小时内完成全流程）以及问题分析、模型建立、编程实现和论文撰写的要点。文中还提供了物流路径优化的实战案例，展示了如何将实际问题转化为图论问题并采用Dijkstra或蚁群算法求解。最后，文档推荐了不同类型建模的学习资源与工具，并给出了新手避坑建议，如避免过度复杂化模型、重视可视化呈现等。; 适合人群：对建模大赛感兴趣的初学者，特别是高校学生及希望参与数学建模竞赛的新手。; 使用场景及目标：①了解建模大赛的基本概念和分类；②掌握数学建模竞赛的具体流程与分工；③学习如何将实际问题转化为数学模型并求解；④获取实战经验和常见错误规避方法。; 其他说明：文档不仅提供了理论知识，还结合具体实例和代码片段帮助读者更好地理解和实践建模过程。建议新手从中小型赛事开始积累经验，逐步提升技能水平。
该资源为protobuf-6.30.1-cp310-abi3-win32.whl，欢迎下载使用哦！
内容概要：本文档详细介绍了基于Linux系统的大数据环境搭建流程，涵盖从虚拟机创建到集群建立的全过程。首先，通过一系列步骤创建并配置虚拟机，包括设置IP地址、安装MySQL数据库等操作。接着，重点讲解了Ambari的安装与配置，涉及关闭防火墙、设置免密登录、安装时间同步服务（ntp）、HTTP服务以及配置YUM源等关键环节。最后，完成了Ambari数据库的创建、JDK的安装、Ambari server和agent的部署，并指导用户创建集群。整个过程中还提供了针对可能出现的问题及其解决方案，确保各组件顺利安装与配置。 适合人群：具有Linux基础操作技能的数据工程师或运维人员，尤其是那些需要构建和管理大数据平台的专业人士。 使用场景及目标：适用于希望快速搭建稳定可靠的大数据平台的企业或个人开发者。通过本指南可以掌握如何利用Ambari工具自动化部署Hadoop生态系统中的各个组件，从而提高工作效率，降低维护成本。 其他说明：文档中包含了大量具体的命令行指令和配置细节，建议读者按照顺序逐步操作，并注意记录下重要的参数值以便后续参考。此外，在遇到问题时可参照提供的解决方案进行排查，必要时查阅官方文档获取更多信息。
内容概要：本文详细介绍了如何在MATLAB R2018A中使用最小均方(LMS)自适应滤波算法对一维时间序列信号进行降噪处理，特别是针对心电图(ECG)信号的应用。首先，通过生成模拟的ECG信号并加入随机噪声，创建了一个带有噪声的时间序列。然后，实现了LMS算法的核心部分，包括滤波器阶数、步长参数的选择以及权重更新规则的设计。文中还提供了详细的代码示例，展示了如何构建和训练自适应滤波器，并通过图形化方式比较了原始信号、加噪信号与经过LMS处理后的降噪信号之间的差异。此外，作者分享了一些实用的经验和技术要点，如参数选择的影响、误差曲线的解读等。 适用人群：适用于具有一定MATLAB编程基础并对信号处理感兴趣的科研人员、工程师或学生。 使用场景及目标：本教程旨在帮助读者掌握LMS算法的基本原理及其在实际项目中的应用方法，特别是在生物医学工程、机械故障诊断等领域中处理含噪信号的任务。同时，也为进一步探索其他类型的自适应滤波技术和扩展到不同的信号处理任务奠定了基础。 其他说明：尽管LMS算法在处理平稳噪声方面表现出色，但在面对突发性的强干扰时仍存在一定局限性。因此，在某些特殊场合下，可能需要与其他滤波技术相结合以获得更好的效果。
内容概要：本文详细介绍了基于TMS320F2812 DSP芯片的光伏并网逆变器设计方案，涵盖了主电路架构、控制算法、锁相环实现、环流抑制等多个关键技术点。首先，文中阐述了双级式结构的主电路设计，前级Boost升压将光伏板输出电压提升至约600V，后级采用三电平NPC拓扑的IGBT桥进行逆变。接着，深入探讨了核心控制算法，如电流PI调节器、锁相环(SOFGI)、环流抑制等，并提供了详细的MATLAB仿真模型和DSP代码实现。此外，还特别强调了PWM死区时间配置、ADC采样时序等问题的实际解决方案。最终，通过实验验证，该方案实现了THD小于3%，MPPT效率达98.7%，并有效降低了并联环流。 适合人群：从事光伏并网逆变器开发的电力电子工程师和技术研究人员。 使用场景及目标：适用于光伏并网逆变器的研发阶段，帮助工程师理解和实现高效稳定的逆变器控制系统，提高系统的性能指标，减少开发过程中常见的错误。 其他说明：文中提供的MATLAB仿真模型和DSP代码可以作为实际项目开发的重要参考资料，有助于缩短开发周期，提高成功率。
内容概要：本文详细解析了三菱FX3U PLC在六轴自动包装机中的应用，涵盖硬件配置、程序框架、伺服定位控制、手自动切换逻辑、功能块应用以及报警处理等方面。硬件方面，采用FX3U-48MT主模块自带三轴脉冲输出，配合三个FX3UG-1PG模块扩展定位功能，使用六个MR-JE-20A伺服驱动器和16点输入扩展模块进行传感器采集。程序框架主要由初始化、模式切换、六轴控制和异常处理组成。伺服定位使用DRVA指令实现双速定位模式，手自动切换逻辑通过功能块封装，确保模式切换顺畅。报警处理模块则利用矩阵扫描方式压缩报警信号，提高IO利用率。此外，程序还包括状态监控设计和原点回归等功能。 适合人群：具备一定PLC编程基础，从事自动化控制领域的工程师和技术人员。 使用场景及目标：适用于六轴自动包装机的设计与调试，帮助工程师理解和掌握三菱FX3U PLC在包装机械中的具体应用，提升系统的可靠性和效率。 其他说明：文中提供了详细的代码示例和注意事项，有助于新手避免常见错误并优化程序性能。
PPTJAVA编程190