%% 癑ֈ?Apache2.0.44或更高的版本)
%a q端IP地址
%A 本机IP地址
%B 除HTTP头以外传送的字节?br /> %b 以CLF格式昄的除HTTP头以外传送的字节敎ͼ也就是当没有字节传送时昄’-‘而不??br /> %{Foobar}C 在请求中传送给服务端的cookieFoobar的内宏V?br /> %D 服务器处理本h所用时_以微为单位?br /> %{FOOBAR}e 环境变量FOOBAR的?br /> %f 文g?br /> %h q端L
%H h使用的协?br /> %{Foobar}i 发送到服务器的h头Foobar:的内宏V?br /> %l q端d?由identd而来Q如果支持的?Q除非IdentityCheck设ؓ”On“Q否则将得到一?#8221;-”?br /> %m h的方?br /> %{Foobar}n 来自另一个模块的注解Foobar的内宏V?br /> %{Foobar}o 应答头Foobar:的内宏V?br /> %p 服务器服务于该请求的标准端口?br /> %P 为本h提供服务的子q程的PID?br /> %{format}P 服务于该h的PID或TID(U程ID)Qformat的取D围ؓQpid和tid(2.0.46及以后版?以及hextid(需要APR1.2.0及以上版?
%q 查询字符?若存在则׃?#8221;?“引导Q否则返回空?
%r h的第一?br /> %s 状态。对于内部重定向的请求，q个状态指的是原始h的状态，?>s则指的是最后请求的状态?br /> %t 旉Q用普通日志时间格?标准p格式)
%{format}t 旉Q用strftime(3)指定的格式表C的旉?默认情况下按本地化格?
%T 处理完请求所花时_以秒为单位?br /> %u q程用户?Ҏ验证信息而来Q如果返回status(%s)?01Q可能是假的)
%U h的URL路径Q不包含查询字符丌Ӏ?br /> %v 对该h提供服务的标准ServerName?br /> %V ҎUseCanonicalName指o讑֮的服务器名称?br /> %X h完成时的q接状态：
X= q接在应{完成前中断?br /> += 应答传送完后l保持连接?br /> -= 应答传送完后关闭连接?br /> (?.3以后的版本中Q这个指令是%cQ但q样和q去的SSL语法Q?{var}c冲突?
%I 接收的字节数Q包括请求头的数据，q且不能为零。要使用q个指o你必d用mod_logio模块?br /> %O 发送的字节敎ͼ包括h头的数据Qƈ且不能ؓ零。要使用q个指o你必d用mod_logio模块?br />
一些常见的格式Ԍ
通用日志格式(CLF)
“%h %l %u %t \”%r\” %>s %b”
带虚拟主机的通用日志格式
“%v %h %l %u %t \”%r\” %>s %b”
NCSA扩展/l合日志格式
“%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\”"
Referer日志格式
“%{Referer}i -> %U”
Agent(Browser)日志格式
“%{User-agent}i”
]]>
http://freeware.sgi.com/source/rzsz/rzsz-3.48.tar.gz
<coolcode linenum=”off”>
tar -xzvf rzsz-3.48.tar.gz
cd src
</coolcode>
修改MakefileW四行OFLAG= -O ?OFLAG= -O -DREGISTERED
否则Q编译后Q在上传下蝲完成都会提示Q?/p>
<coolcode linenum=”off”>
**** UNREGISTERED COPY *****
Please read the License Agreement in rz.doc
</coolcode>
<coolcode linenum=”off”>
xok# make posix
cc -O2 -fno-strict-aliasing -pipe -O -DREGISTERED -DPOSIX -DMD=2 rz.c -o rz
size rz
text data bss dec hex filename
29093 640 6328 36061 8cdd rz
rm -f rb rx rc
ln rz rb
ln rz rx
ln rz rc
cc -O2 -fno-strict-aliasing -pipe -O -DREGISTERED -DPOSIX sz.c -o sz
size sz
text data bss dec hex filename
34632 704 38828 74164 121b4 sz
rm -f sb sx zcommand zcommandi
ln sz sb
ln sz sx
ln sz zcommand
ln sz zcommandi
cp rz sz /usr/sbin/
</coolcode>
安装OK?/p>
1.安装后，可以把sz ?rz 复制?/usr/local/bin ?/p>
2.使用时如果遇到类似错误，
-bash-3.00$ sz sz.doc
/dev/pts/5: Permission denied
可以使用理员修?nbsp;/dev/pts/5 权限卛_?/p>
3.~译Ӟ可能?cc 找不刎ͼ修改Makefile 里的 cc 为gcc 卛_
4.~译Ӟ如果?size 找不刎ͼ?nbsp;/usr/ccs/bin/ 加入 $PATH 既可
]]>
在网上搜了好一会儿发现time.nist.govq个旉服务器以l失效了
root@OpenWrt:~# rdate -s time.nist.gov
rdate: timeout connecting to time server
?a >http://youhuiba.net/2010/10/12/280.htmlq里发现一个可用的
root@OpenWrt:~# rdate -s rdate.cpanel.net
rdate: current time matches remote time
现在把它d到crontab?br />
root@OpenWrt:~# crontab -e
00 19 * * *
具体的时间格式可以根?a >http://hi.baidu.com/mahaibao/blog/item/0286375582f2f7cbb645aed6
可以了~~~以后每天的晚?点就可以自动的更新时间了
]]>
* %b - 发送的字节敎ͼ不包括HTTP_如果?Q?Q?
* %B - 发送的字节敎ͼ不包括HTTP?
* %h - q端L?如果resolveHost=falseQ远端的IP地址Q?
* %H - h协议
* %l - 从identdq回的远端逻辑用户名（Lq回 '-'Q?
* %m - h的方法（GETQPOSTQ等Q?
* %p - 收到h的本地端口号
* %q - 查询字符?如果存在Q以 '?'开?
* %r - h的第一行，包含了请求的Ҏ和URI
* %s - 响应的状态码
* %S - 用户的session ID
* %t - 日志和时_使用通常的Log格式
* %u - 认证以后的远端用P如果存在的话Q否则ؓ'-'Q?
* %U - h的URI路径
* %v - 本地服务器的名称
* %D - 处理h的时_以毫Uؓ单位
* %T - 处理h的时_以秒为单?
- %a - Remote IP address
- %A - Local IP address
- %b - Bytes sent, excluding HTTP headers, or '-' if zero
- %B - Bytes sent, excluding HTTP headers
- %h - Remote host name (or IP address if
resolveHostsis false) - %H - Request protocol
- %l - Remote logical username from identd (always returns '-')
- %m - Request method (GET, POST, etc.)
- %p - Local port on which this request was received
- %q - Query string (prepended with a '?' if it exists)
- %r - First line of the request (method and request URI)
- %s - HTTP status code of the response
- %S - User session ID
- %t - Date and time, in Common Log Format
- %u - Remote user that was authenticated (if any), else '-'
- %U - Requested URL path
- %v - Local server name
- %D - Time taken to process the request, in millis
- %T - Time taken to process the request, in seconds
- %I - current request thread name (can compare later with stacktraces)
%{xxx}ifor incoming request headers%{xxx}ofor outgoing response headers%{xxx}cfor a specific request cookie%{xxx}rxxx is an attribute in the ServletRequest%{xxx}sxxx is an attribute in the HttpSession
]]>
[原创文章Q{载请保留或注明出处：http://www.regexlab.com/zh/encoding.htm]
U别Q中U?/p>
摘要Q本文介l了字符与编码的发展q程Q相x늚正确理解。D例说明了一些实际应用中Q编码的实现Ҏ。然后，本文讲述了通常对字W与~码的几U误解，׃q些误解而导致ؕ码生的原因Q以及消除ؕ码的办法。本文的内容늛?#8220;中文问题”Q?#8220;q问题”?/p>
掌握~码问题的关键是正确地理解相x念，~码所涉及的技术其实是很简单的。因此，阅读本文旉要慢d惻I多思考?/p>
引言
“字符与编?#8221;是一个被l常讨论的话题。即使这P时常出现的ؕ码仍然困扰着大家。虽然我们有很多的办法可以用来消除ؕ码，但我们ƈ不一定理解这些办法的内在原理。而有的ؕ码生的原因Q实际上׃底层代码本n有问题所D的。因此，不仅是初学者会对字W编码感到模p，有的底层开发h员同样对字符~码~Z准确的理解?/p>
 |
|||
|
1. ~码问题的由来，相关概念的理?/h4>
1.1 字符与编码的发展
从计机对多国语a的支持角度看Q大致可以分Z个阶D：
| pȝ内码 | 说明 | pȝ | |
| 阶段一 | ASCII | 计算机刚开始只支持pQ其它语a不能够在计算Z存储和显C?/td> | 英文 DOS |
| 阶段?/td> | ANSI~码 Q本地化Q?/td> | Z计算机支持更多语aQ通常使用 0x80~0xFF 范围?2 个字节来表示 1 个字W。比如：汉字 '? 在中文操作系l中Q?[0xD6,0xD0] q两个字节存储?br />
不同的国家和地区制定了不同的标准Q由此生了 GB2312, BIG5, JIS {各自的~码标准。这些?2 个字节来代表一个字W的各种汉字延~码方式Q称?strong> ANSI ~码。在体中文系l下QANSI ~码代表 GB2312 ~码Q在日文操作pȝ下，ANSI ~码代表 JIS ~码?br /> 不同 ANSI ~码之间互不兼容Q当信息在国际间交流Ӟ无法属于两U语a的文字，存储在同一D?strong> ANSI ~码的文本中?/td> | 中文 DOSQ中?Windows 95/98Q日?Windows 95/98 |
| 阶段?/td> | UNICODE Q国际化Q?/td> | Z使国际间信息交流更加方便Q国际组l制定了 UNICODE 字符?/strong>Qؓ各种语言中的每一个字W设定了l一q且唯一的数字编P以满语言、跨q_q行文本转换、处理的要求?/td>
| Windows NT/2000/XPQLinuxQJava |
|
字符串在内存中的存放ҎQ?/p>
?ASCII 阶段Q?strong>单字节字W串使用一个字节存放一个字W（SBCSQ。比如，"Bob123" 在内存中为：
| 42 | 6F | 62 | 31 | 32 | 33 | 00 |
 |
|
|
|
|
|
|
| B | o | b | 1 | 2 | 3 | \0 |
在?ANSI ~码支持多种语言阶段Q每个字W用一个字节或多个字节来表C（MBCSQ，因此Q这U方式存攄字符也被UC多字节字W?/strong>。比如，"中文123" 在中?Windows 95 内存中ؓ7个字节，每个汉字?个字节，每个英文和数字字W占1个字节：
| D6 | D0 | CE | C4 | 31 | 32 | 33 | 00 |
|
|
|
|
|
|
||
| ?/td> | ?/td> | 1 | 2 | 3 | \0 | ||
?UNICODE 被采用之后，计算机存攑֭W串Ӟ改ؓ存放每个字符?UNICODE 字符集中的序受目前计机一般?2 个字节（16 位）来存放一个序PDBCSQ，因此Q这U方式存攄字符也被UC宽字节字W?/strong>。比如，字符?"中文123" ?Windows 2000 下，内存中实际存攄?5 个序P
| 2D | 4E | 87 | 65 | 31 | 00 | 32 | 00 | 33 | 00 | 00 | 00 | ← ?x86 CPU 中，低字节在?/font> |
|
|
|
|
|
|
|
||||||
| ?/td> | ?/td> | 1 | 2 | 3 | \0 | |||||||
一共占 10 个字节?/p>
|
|||
|
1.2 字符Q字节，字符?/h5>
理解~码的关键，是要把字W的概念和字节的概念理解准确。这两个概念ҎhQ我们在此做一下区分：
| 概念描述 | 举例 | |
| 字符 | Z使用的记P抽象意义上的一个符受?/td> | '1', '?, 'a', '$', 'K?, …… |
| 字节 | 计算Z存储数据的单元，一?位的二进制数Q是一个很具体的存储空间?/td> | 0x01, 0x45, 0xFA, …… |
| ANSI 字符?/td> | 在内存中Q如?#8220;字符”是以 ANSI ~码形式存在的，一个字W可能用一个字节或多个字节来表C，那么我们U这U字W串?ANSI 字符?/strong>或?strong>多字节字W串?/td> | "中文123" Q占7字节Q?/span> |
| UNICODE 字符?/td> | 在内存中Q如?#8220;字符”是以?UNICODE 中的序号存在的，那么我们U这U字W串?UNICODE 字符?/strong>或?strong>宽字节字W串?/td> | L"中文123" Q占10字节Q?/span> |
׃不同 ANSI ~码所规定的标准是不相同的Q因此，对于一个给定的多字节字W串Q我们必ȝ道它采用的是哪一U编码规则，才能够知道它包含了哪?#8220;字符”。而对?UNICODE 字符?/strong>来说Q不在什么环境下Q它所代表?#8220;字符”内容L不变的?/p>
各个国家和地区所制定的不?ANSI ~码标准中，都只规定了各自语a所需?#8220;字符”。比如：汉字标准QGB2312Q中没有规定韩国语字W怎样存储。这?ANSI ~码标准所规定的内容包含两层含义： 各个国家和地区在制定~码标准的时候，“字符的集?#8221;?#8220;~码”一般都是同时制定的。因此，q_我们所说的“字符?#8221;Q比如：GB2312, GBK, JIS {，除了?#8220;字符的集?#8221;q层含义外，同时也包含了“~码”的含义?/p>
“UNICODE 字符?/strong>”包含了各U语a中用到的所?#8220;字符”。用来给 UNICODE 字符集编码的标准有很多种Q比如：UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig {?/p>
单介l一下常用的~码规则Qؓ后边的章节做一个准备。在q里Q我们根据编码规则的特点Q把所有的~码分成三类Q?/p>
我们实际上没有必要去q每一U编码具体把某一个字W编码成了哪几个字节Q我们只需要知?#8220;~码”的概念就是把“字符”转化?#8220;字节”可以了。对?#8220;UNICODE ~码”Q由于它们是可以通过计算得到的，因此Q在Ҏ的场合，我们可以M解某一U?#8220;UNICODE ~码”是怎样的规则?/p>
?C++ ?Java 中，用来代表“字符”?#8220;字节”的数据类型，以及q行~码的方法： 以上需要注意几点： 声明一D字W串帔RQ?/p>
UNICODE 字符串的 I/O 操作Q字W与字节的{换操作： ?Visual C++ 中，UNICODE 字符串常量有更简单的表示Ҏ。如果源E序的编码与当前默认 ANSI ~码不符Q则需要?#pragma setlocaleQ告诉编译器源程序用的~码Q?/p>
以上需要注?#pragma setlocale ?setlocale(LC_ALL, "") 的作用是不同的，#pragma setlocale 在编译时起作用，setlocale() 在运行时起作用?/p>
字符串类 String 中的内容?UNICODE 字符Ԍ 字符?I/O 操作Q字W与字节转换操作。在 Java ?java.io.* 中，?#8220;Stream”l尾的类一般是用来操作“字节?#8221;的类Q以“Reader”Q?#8220;Writer”l尾的类一般是用来操作“字符?#8221;的类?/p>
如果 java 的源E序~码与当前默?ANSI ~码不符Q则在编译的时候，需要指明一下源E序的编码。比如： 以上需要注意区分源E序的编码与 I/O 操作的编码，前者是在编译时起作用，后者是在运行时起作用?/p>
W一U误解，往往是导致ؕ码生的原因。第二种误解Q往往D本来ҎU正的ؕ码问题变得更复杂?/p>
在这里，我们可以看到Q其中所讲的“误解一”Q即采用?#8220;一个字?#8221;是“一个字W?#8221;的{化方法，实际上也q同于采用 iso-8859-1 q行转化。因此，我们常常使用 bytes = string.getBytes("iso-8859-1") 来进行逆向操作Q得到原始的“字节?#8221;。然后再使用正确?ANSI ~码Q比?string = new String(bytes, "GB2312")Q来得到正确?#8220;UNICODE 字符?#8221;?/p>
?UNICODE E序中的字符Ԍ都是以某U?ANSI ~码形式存在的。如果程序运行时的语a环境与开发时的语a环境不同Q将会导?ANSI 字符串的昄p|?/p>
比如Q在日文环境下开发的?UNICODE 的日文程序界面，拿到中文环境下运行时Q界面上显CZؕ码。如果这个日文程序界面改为采?UNICODE 来记录字W串Q那么当在中文环境下q行Ӟ界面上将可以昄正常的日文?/p>
׃客观原因Q有时候我们必d中文操作pȝ下运行非 UNICODE 的日文YӞq时我们可以采用一些工P比如Q南极星QAppLocale {，暂时的模拟不同的语言环境?/p>
当页面中的表单提交字W串Ӟ首先把字W串按照当前面的编码，转化成字节串。然后再每个字节{化成 "%XX" 的格式提交到 Web 服务器。比如，一个编码ؓ GB2312 的页面，提交 "? q个字符串时Q提交给服务器的内容?"%D6%D0"?/p>
在服务器端，Web 服务器把收到?"%D6%D0" 转化?[0xD6, 0xD0] 两个字节Q然后再Ҏ GB2312 ~码规则得到 "? 字?/p>
?Tomcat 服务器中Qrequest.getParameter() 得到qӞ常常是因为前面提到的“误解一”造成的。默认情况下Q当提交 "%D6%D0" l?Tomcat 服务器时Qrequest.getParameter() 返?[0x00D6, 0x00D0] 两个 UNICODE 字符Q而不是返回一?"? 字符。因此，我们需要?bytes = string.getBytes("iso-8859-1") 得到原始的字节串Q再?string = new String(bytes, "GB2312") 重新得到正确的字W串 "??/p>
通过数据库客LQ比?ODBC ?JDBCQ从数据库服务器中读取字W串Ӟ客户端需要从服务器获知所使用?ANSI ~码。当数据库服务器发送字节流l客LӞ客户端负责将字节按照正的~码转化?UNICODE 字符丌Ӏ?/p>
如果从数据库d字符串时得到qQ而数据库中存攄数据又是正确的，那么往往q是因ؓ前面提到?#8220;误解一”造成的。解决的办法q是通过 string = new String( string.getBytes("iso-8859-1"), "GB2312") 的方法，重新得到原始的字节串Q再重新使用正确的编码{化成字符丌Ӏ?/p>
当一D?Text 或?HTML 通过电子邮g传送时Q发送的内容首先通过一U指定的字符~码转化?#8220;字节?#8221;Q然后再?#8220;字节?#8221;通过一U指定的传输~码QContent-Transfer-EncodingQ进行{化得到另一?#8220;字节?#8221;。比如，打开一电子邮件源代码Q可以看到类似的内容Q?/p>
最常用?Content-Transfer-Encoding ?Base64 ?Quoted-Printable 两种。在对二q制文g或者中文文本进行{化时QBase64 得到?#8220;字节?#8221;?Quoted-Printable 更短。在对英文文本进行{化时QQuoted-Printable 得到?#8220;字节?#8221;?Base64 更短?/p>
邮g的标题，用了一U更短的格式来标?#8220;字符~码”?#8220;传输~码”。比如，标题内容?"?Q则在邮件源代码中表CZؓQ?/p>
其中Q?/p>
如果“传输~码”改ؓ Quoted-PrintableQ同P如果标题内容?"?Q?/p>
如果阅读邮g时出Cؕ码，一般是因ؓ“字符~码”?#8220;传输~码”指定有误Q或者是没有指定。比如，有的发邮件组件在发送邮件时Q标?"?Q?/p>
q样的表C，实际上是明确指明了标题ؓ [0x00D6, 0x00D0]Q即 "ÖÐ"Q而不?"??/p>
非也。iso-8859-1 只是单字节字W集中最单的一U，也就?#8220;字节~号”?#8220;UNICODE 字符~号”一致的那种~码规则。当我们要把一?#8220;字节?#8221;转化?#8220;字符?#8221;Q而又不知道它是哪一U?ANSI ~码Ӟ先暂时地?#8220;每一个字?#8221;作ؓ“一个字W?#8221;q行转化Q不会造成信息丢失。然后再使用 bytes = string.getBytes("iso-8859-1") 的方法可恢复到原始的字节丌Ӏ?/p>
Java 中，字符串类 java.lang.String 处理的是 UNICODE 字符Ԍ不是 ANSI 字符丌Ӏ我们只需要把字符串作?#8220;抽象的符L?#8221;来看待。因此不存在字符串的内码的问题?/p>
1.3 字符集与~码
1.4 常用的编码简?/h5>
分类
~码标准
说明
单字节字W编?/td>
ISO-8859-1
最单的~码规则Q每一个字节直接作Z?UNICODE 字符。比如，[0xD6, 0xD0] q两个字节，通过 iso-8859-1 转化为字W串Ӟ直接得?[0x00D6, 0x00D0] 两个 UNICODE 字符Q即 "ÖÐ"?br />
反之Q将 UNICODE 字符串通过 iso-8859-1 转化为字节串Ӟ只能正常转化 0~255 范围的字W?/td>
ANSI ~码
GB2312,
BIG5,
Shift_JIS,
ISO-8859-2 ……?UNICODE 字符串通过 ANSI ~码转化?#8220;字节?#8221;ӞҎ各自~码的规定，一?UNICODE 字符可能转化成一个字节或多个字节?br />
反之Q将字节串{化成字符串时Q也可能多个字节转化成一个字W。比如，[0xD6, 0xD0] q两个字节，通过 GB2312 转化为字W串Ӟ得?[0x4E2D] 一个字W，?'? 字?br />
“ANSI ~码”的特点：
1. q些“ANSI ~码标准”都只能处理各自语a范围之内?UNICODE 字符?br />
2. “UNICODE 字符”?#8220;转换出来的字?#8221;之间的关pLZؓ规定的?/td>
UNICODE ~码
UTF-8,
UTF-16, UnicodeBig ……?#8220;ANSI ~码”cM的，把字W串通过 UNICODE ~码转化?#8220;字节?#8221;Ӟ一?UNICODE 字符可能转化成一个字节或多个字节?br />
?#8220;ANSI ~码”不同的是Q?br />
1. q些“UNICODE ~码”能够处理所有的 UNICODE 字符?br />
2. “UNICODE 字符”?#8220;转换出来的字?#8221;之间是可以通过计算得到的?/td>
2. 字符与编码在E序中的实现
2.1 E序中的字符与字?/h5>
cd或操?/strong>
C++
Java
字符
wchar_t
char
字节
char
byte
ANSI 字符?/td>
char[]
byte[]
UNICODE 字符?/td>
wchar_t[]
String
字节?#8594;字符?/td>
mbstowcs(), MultiByteToWideChar()
string = new String(bytes, "encoding")
字符?#8594;字节?/td>
wcstombs(), WideCharToMultiByte()
bytes = string.getBytes("encoding")
2.2 C++ 中相兛_现方?/h5>
// ANSI 字符Ԍ内容长度 7 字节
char sz[20] = "中文123";
// UNICODE 字符Ԍ内容长度 5 ?wchar_tQ?0 字节Q?/span>
wchar_t wsz[20] = L"\x4E2D\x6587\x0031\x0032\x0033";
// q行时设定当?ANSI ~码QVC 格式
setlocale(LC_ALL, ".936");
// GCC 中格?/span>
setlocale(LC_ALL, "zh_CN.GBK");
// Visual C++ 中用小?%sQ按?setlocale 指定~码输出到文?br />
// GCC 中用大?%S
fwprintf(fp, L"%s\n", wsz);
// ?UNICODE 字符串按?setlocale 指定的编码{换成字节
wcstombs(sz, wsz, 20);
// 把字节串按照 setlocale 指定的编码{换成 UNICODE 字符?br />
mbstowcs(wsz, sz, 20);
// 如果源程序的~码与当前默?ANSI ~码不一_
// 则需要此行，~译时用来指明当前源E序使用的编?/span>
#pragma setlocale(".936")
// UNICODE 字符串常量，内容长度 10 字节
wchar_t wsz[20] = L"中文123";
2.3 Java 中相兛_现方?/h5>
// Java 代码Q直接写中文
String string = "中文123";
// 得到长度?5Q因为是 5 个字W?/span>
System.out.println(string.length());
// 字符串与字节串间怺转化
// 按照 GB2312 得到字节Q得到多字节字符Ԍ
byte [] bytes = string.getBytes("GB2312");
// 从字节按?GB2312 得到 UNICODE 字符?/span>
string = new String(bytes, "GB2312");
// 要将 String 按照某种~码写入文本文gQ有两种ҎQ?br />
// W一U办法：?Stream cd入已l按照指定编码{化好的字节串
OutputStream os = new FileOutputStream("1.txt");
os.write(bytes);
os.close();
// W二U办法：构造指定编码的 Writer 来写入字W串
Writer ow = new OutputStreamWriter(new FileOutputStream("2.txt"), "GB2312");
ow.write(string);
ow.close();
/* 最后得到的 1.txt ?2.txt 都是 7 个字?*/
E:\>javac -encoding BIG5 Hello.java
3. 几种误解Q以及ؕ码生的原因和解军_?/h4>
3.1 Ҏ产生的误?/h5>
对编码的误解
误解一
在将“字节?#8221;转化?#8220;UNICODE 字符?#8221;Ӟ比如在读取文本文件时Q或者通过|络传输文本ӞҎ?#8220;字节?#8221;单地作ؓ单字节字W串Q采用每“一个字?#8221;是“一个字W?#8221;的方法进行{化?br />
而实际上Q在非英文的环境中，应该?#8220;字节?#8221;作ؓ ANSI 字符Ԍ采用适当的编码来得到 UNICODE 字符Ԍ有可?#8220;多个字节”才能得到“一个字W?#8221;?br />
通常Q一直在英文环境下做开发的E序员们Q容易有q种误解?/td>
误解?/td>
?DOSQWindows 98 {非 UNICODE 环境下，字符串都是以 ANSI ~码的字节Ş式存在的。这U以字节形式存在的字W串Q必ȝ道是哪种~码才能被正地使用。这使我们Ş成了一个惯性思维Q?#8220;字符串的~码”?br />
?UNICODE 被支持后QJava 中的 String 是以字符?#8220;序号”来存储的Q不是以“某种~码的字?#8221;来存储的Q因此已l不存在“字符串的~码”q个概念了。只有在“字符?#8221;?#8220;字节?#8221;转化Ӟ或者，一?#8220;字节?#8221;当成一?ANSI 字符串时Q才有编码的概念?br />
不少的h都有q个误解?/td>
3.2 ?UNICODE E序在不同语a环境间移植时的ؕ?/h5>
3.3 |页提交字符?/h5>
3.4 从数据库d字符?/h5>
3.5 电子邮g中的字符?/h5>
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
sbG+qcrQuqO17cf4yee74bGjz9W7+b3wudzA7dbQ0MQNCg0KvPKzxqO6uqO17cnnsaPW0NDEDQoNCg==
// 正确的标题格?/span>
Subject: =?GB2312?B?1tA=?=
// 正确的标题格?/span>
Subject: =?GB2312?Q?=D6=D0?=
// 错误的标题格?/span>
Subject: =?ISO-8859-1?Q?=D6=D0?=
4. 几种错误理解的纠?/h4>
误解Q?#8220;ISO-8859-1 是国际编码？”
误解Q?#8220;Java 中，怎样知道某个字符串的内码Q?#8221;
]]>
