JAVA字符串编码问题!
将URL地址转化成字符串时,有些特别的字符识别不了。如.和#等。请实际解决过这方面的大侠指点迷津...
将URL地址转化成字符串时,有些特别的字符识别不了。如.和#等。请实际解决过这方面的大侠指点迷津
展开
3个回答
展开全部
这种编码问题真是很tricky的问题。说它tricky是因为这至少涉及到以下4种编码选取的排列组合(有时甚至更多),更有时乃至会发生错进错出,负负得正,中间过程错了但反而到不是乱码的情况。
(1)源代码的编码
(2)编译时告诉java编译器的源代码编码
(3)运行时jvm参数file.encoding
(4)输出终端对输出字节流的解码所采用的码组
在这简单情况下(1)和(2)一致,(3)和(4)一致就不会因为编解码映射错误(当然字符向终端字体映射的错误是另一回事,如字体缺失之类)。而(1)(2)和(3)(4)不必一致,这样就使得不必强求开发编译环境和运行应用环境的编码必须一致。
源代码的录入与编译若在在一个平台上时,大多数情况没有问题(反而用聪明的Idea IDE设置错误时会乱套,越是简陋的开发环境越不太会错)。但是如果你在中文GBK编码平台上的源代码在别人的unicode编码平台上编译,就有问题了。所以和别人,特别是和不同母语的人合作编程时,建议要么约定一律用unicode作为源文件编码;要么只用ASCII字符,反正其他编码一般都和ASCII兼容的,对于非ASCII字符,用Java的/uxxxx表示机制,比如"中国"就表示为"\u4e2d\u56fd"。4e2d和56fd分别是中国二字的unicode十六进制编码。
但我认为楼主在这里其实主要关心的是运行时的编码一致问题,即(3)和(4)。所以言归正传,让我们来检查它们是否一致。
由于正如上述,iso8859-1编码集其实是被其他所有公认的编码集所兼容的,也就是说它是所有公认编码集的公共子集。所以以iso8859-1为基础可以外延到任何一个公认编码集。事实上大多数情况也是这样做的。比如java System property里设定了encoding为iso8859-1,事实上不仅仅是一个Latin字母的映射,在非Latin区域按JVM宿主操作系统的编码扩展。即选iso8859-1其实是选择了宿主操作系统的默认编码。
假设楼主的操作系统编码是GBK,那么file.encoding=iso8859-1相当于选择了file.encoding=GBK。那么System.out.println(...)这个核心类方法会将china字符转换为file.encoding指定的编码(GBK)字节由out流输出给最终out所绑定的终端。比如console一般采用系统默认编码也是GBK的话,那就和file.encoding一致,能正常解码,不会乱码。
至于System.out.write()直接写字节流。由于该字节流是由china.getBytes()得到的,在不指定编码的时候使用file.encoding指定的默认值的(即GBK),因此Str->Byte的编码方法GBK和console采用的解码方法GBK又是一致的,所以也不是乱码。
但是这时候用toHexString打印出的两个字节串是不一样的。先直接把china逐字强行转换为int的情况,不涉及输出编码,总是unicode的。(JVM规范规定class里字串必须unicode编码)只要上述(1) (2)匹配,java编译器会自动从各种编码的源文件正确转成class文件里统一unicode编码的字串。相反,作为一个题外话提一下,当(1)(2)不匹配时会在特定的一种配合(1)(2)的(3)(4)也不匹配的情况下会负负得正输出正常,但这是绝对错误的做法,因为任何要求(1)(2)和(3)(4)有匹配关系的要求都是在应用中可能无法满足的。java编译器对这种情况也会报告warning,但不fail。
综上,一旦file.encoding设成宿主操作系统默认而系统consle也采用操作系统默认编解码的话,(3)(4)总是一致的,无论系统选择的是GBK还是utf-8等等。
那么如果file.encoding不选系统默认呢?比如utf-8。那就很可能出现乱码了。但是,慢着,试验的结果还是没有乱码。那是因为file.encoding是静态的JVM系统参数,在程序里像楼主那样设定是不起作用的(我不知道有没有办法发一个什么通知让这种程序改变生效的)。必须作为JVM参数直接传给java程序让它构造虚拟机的时候就得到这个参数,否则JVM会去拿宿主系统的默认值,就相当于又回到设file.encoding=iso8859-1了。
java -Dfile.encoding=utf-8 A
这下终于乱码了,而且两个都乱了。打印出的字节串一个还是unicode,另一个从GBK变到utf-8了。
如果你发现试验的现象和我上面说的正好相反,请注意检查console的编码设置,我们上面假设它也采用了宿主系统默认编码,但有些console很高级的嘞,可以设置成不通编码的(其实几乎所有的都可以)。那么分析的方法和上面一样,结果可能正好相反。
(1)源代码的编码
(2)编译时告诉java编译器的源代码编码
(3)运行时jvm参数file.encoding
(4)输出终端对输出字节流的解码所采用的码组
在这简单情况下(1)和(2)一致,(3)和(4)一致就不会因为编解码映射错误(当然字符向终端字体映射的错误是另一回事,如字体缺失之类)。而(1)(2)和(3)(4)不必一致,这样就使得不必强求开发编译环境和运行应用环境的编码必须一致。
源代码的录入与编译若在在一个平台上时,大多数情况没有问题(反而用聪明的Idea IDE设置错误时会乱套,越是简陋的开发环境越不太会错)。但是如果你在中文GBK编码平台上的源代码在别人的unicode编码平台上编译,就有问题了。所以和别人,特别是和不同母语的人合作编程时,建议要么约定一律用unicode作为源文件编码;要么只用ASCII字符,反正其他编码一般都和ASCII兼容的,对于非ASCII字符,用Java的/uxxxx表示机制,比如"中国"就表示为"\u4e2d\u56fd"。4e2d和56fd分别是中国二字的unicode十六进制编码。
但我认为楼主在这里其实主要关心的是运行时的编码一致问题,即(3)和(4)。所以言归正传,让我们来检查它们是否一致。
由于正如上述,iso8859-1编码集其实是被其他所有公认的编码集所兼容的,也就是说它是所有公认编码集的公共子集。所以以iso8859-1为基础可以外延到任何一个公认编码集。事实上大多数情况也是这样做的。比如java System property里设定了encoding为iso8859-1,事实上不仅仅是一个Latin字母的映射,在非Latin区域按JVM宿主操作系统的编码扩展。即选iso8859-1其实是选择了宿主操作系统的默认编码。
假设楼主的操作系统编码是GBK,那么file.encoding=iso8859-1相当于选择了file.encoding=GBK。那么System.out.println(...)这个核心类方法会将china字符转换为file.encoding指定的编码(GBK)字节由out流输出给最终out所绑定的终端。比如console一般采用系统默认编码也是GBK的话,那就和file.encoding一致,能正常解码,不会乱码。
至于System.out.write()直接写字节流。由于该字节流是由china.getBytes()得到的,在不指定编码的时候使用file.encoding指定的默认值的(即GBK),因此Str->Byte的编码方法GBK和console采用的解码方法GBK又是一致的,所以也不是乱码。
但是这时候用toHexString打印出的两个字节串是不一样的。先直接把china逐字强行转换为int的情况,不涉及输出编码,总是unicode的。(JVM规范规定class里字串必须unicode编码)只要上述(1) (2)匹配,java编译器会自动从各种编码的源文件正确转成class文件里统一unicode编码的字串。相反,作为一个题外话提一下,当(1)(2)不匹配时会在特定的一种配合(1)(2)的(3)(4)也不匹配的情况下会负负得正输出正常,但这是绝对错误的做法,因为任何要求(1)(2)和(3)(4)有匹配关系的要求都是在应用中可能无法满足的。java编译器对这种情况也会报告warning,但不fail。
综上,一旦file.encoding设成宿主操作系统默认而系统consle也采用操作系统默认编解码的话,(3)(4)总是一致的,无论系统选择的是GBK还是utf-8等等。
那么如果file.encoding不选系统默认呢?比如utf-8。那就很可能出现乱码了。但是,慢着,试验的结果还是没有乱码。那是因为file.encoding是静态的JVM系统参数,在程序里像楼主那样设定是不起作用的(我不知道有没有办法发一个什么通知让这种程序改变生效的)。必须作为JVM参数直接传给java程序让它构造虚拟机的时候就得到这个参数,否则JVM会去拿宿主系统的默认值,就相当于又回到设file.encoding=iso8859-1了。
java -Dfile.encoding=utf-8 A
这下终于乱码了,而且两个都乱了。打印出的字节串一个还是unicode,另一个从GBK变到utf-8了。
如果你发现试验的现象和我上面说的正好相反,请注意检查console的编码设置,我们上面假设它也采用了宿主系统默认编码,但有些console很高级的嘞,可以设置成不通编码的(其实几乎所有的都可以)。那么分析的方法和上面一样,结果可能正好相反。
展开全部
对URL进行编码
javascript :
解决办法是对要发送的内容进行url编码,可以使用如下javascript函数:
escape(),encodeURI(),以及encodeURIComponent()。这几种编码所起的作用各不相同。
1 escape() 方法:
采用ISO Latin字符集对指定的字符串进行编码。所有的空格符、标点符号、特殊字符以及其他非ASCII字符都将被转化成%xx格式的字符编码(xx等于该字符在字符集表里面的编码的16进制数字)。比如,空格符对应的编码是%20。
不会被此方法编码的字符: @ * / +
2 encodeURI() 方法:
把URI字符串采用UTF-8编码格式转化成escape格式的字符串。
不会被此方法编码的字符:! @ # $& * ( ) = : / ; ? + '
3 encodeURIComponent() 方法:
把URI字符串采用UTF-8编码格式转化成escape格式的字符串。与encodeURI()相比,这个方法将对更多的字符进行编码,比如 / 等字符。所以如果字符串里面包含了URI的几个部分的话,不能用这个方法来进行编码,否则 / 字符被编码之后URL将显示错误。
不会被此方法编码的字符:! * ( ) '
因此,对于中文字符串来说,如果不希望把字符串编码格式转化成UTF-8格式的(比如原页面和目标页面的charset是一致的时候),只需要使用 escape。如果你的页面是GB2312或者其他的编码,而接受参数的页面是UTF-8编码的,就要采用encodeURI或者 encodeURIComponent。
另外,encodeURI/encodeURIComponent是在javascript1.5之后引进的,escape则在javascript1.0版本就有。
java
通过java.net.URLDecoder来解码
String condition = java.net.URLDecoder.decode(aconditon, "utf-8");
javascript :
解决办法是对要发送的内容进行url编码,可以使用如下javascript函数:
escape(),encodeURI(),以及encodeURIComponent()。这几种编码所起的作用各不相同。
1 escape() 方法:
采用ISO Latin字符集对指定的字符串进行编码。所有的空格符、标点符号、特殊字符以及其他非ASCII字符都将被转化成%xx格式的字符编码(xx等于该字符在字符集表里面的编码的16进制数字)。比如,空格符对应的编码是%20。
不会被此方法编码的字符: @ * / +
2 encodeURI() 方法:
把URI字符串采用UTF-8编码格式转化成escape格式的字符串。
不会被此方法编码的字符:! @ # $& * ( ) = : / ; ? + '
3 encodeURIComponent() 方法:
把URI字符串采用UTF-8编码格式转化成escape格式的字符串。与encodeURI()相比,这个方法将对更多的字符进行编码,比如 / 等字符。所以如果字符串里面包含了URI的几个部分的话,不能用这个方法来进行编码,否则 / 字符被编码之后URL将显示错误。
不会被此方法编码的字符:! * ( ) '
因此,对于中文字符串来说,如果不希望把字符串编码格式转化成UTF-8格式的(比如原页面和目标页面的charset是一致的时候),只需要使用 escape。如果你的页面是GB2312或者其他的编码,而接受参数的页面是UTF-8编码的,就要采用encodeURI或者 encodeURIComponent。
另外,encodeURI/encodeURIComponent是在javascript1.5之后引进的,escape则在javascript1.0版本就有。
java
通过java.net.URLDecoder来解码
String condition = java.net.URLDecoder.decode(aconditon, "utf-8");
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
转化时 用g各种编码方式试一下!!例如 utf-8 utf-16 ISO-
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询