BufferedInputStream bis = new BufferedInputStream(conn.getInputStream()); long curPos = startPos; int bytesRead = -1; byte[] buffer = new byte[BUFFER_SIZE]; while ((bytesRead = bis.read(buffer)) != -1) { fos.write(buffer, 0, bytesRead); }
BufferedInputStream bis = new BufferedInputStream(conn.getInputStream()); long curPos = startPos; int bytesRead = -1; byte[] buffer = new byte[BUFFER_SIZE]; while ((bytesRead = bis.read(buffer)) != -1) { fos.write(buffer, 0, bytesRead); }
-Djavax.net.ssl.trustStore
-Dhttps.protocols=SSLv3
-Djsse.enableSNIExtension=false //This is for JDK 7 SNI support, but need to be disabled.
-Djavax.net.debug=ssl
-Dweblogic.security.SSL.protocolVersion=SSL3
-Dweblogic.security.SSL.ignoreHostnameVerification=true
Reference
http://stackoverflow.com/questions/5507878/ssl-connection-reset
http://stackoverflow.com/questions/10188568/sslexception-during-handshake-while-resuming-cached-session
http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0
一句话概括,JDK升级到1.7后对于SSL的支持各种坑。
在项目中碰到个问题,想要建立一个反向的键值对关系,什么叫反向的键值对关系类?先看如下的需求。
旧项目中有很多很多表,每个表的机构类似,但是字段的类型不同,有可能是varchar2,有可能是Number,也有可能是Char或者Int,但是我们需要在一个Config表中来描述这些表,有个data_type的字段,在系统中只定义了Number,String,Date等广泛意义的类型定义,从字典表中可查询到字段类型,但是哪几种字段类型算是String,哪几种算是Number呢?这就构成一种多对1的关系。问题也就产生了,传统意义上的Map都是一个键对应多个值,比如:
Map<String, List<String>> map
在我们这个Map中,按照我们的需求,就是根据List中的value获得Key,当然,我们假设List中的值全部都是唯一的,更精确的描述应该是一个Set<String>,当然这只是为了方便,使用的List。
搜索了一圈google,本以为有现成的反向map实现,但似乎没有。看来只能自己实现下了。代码如下。
package com.catpaw.utils.collection;
import java.util.List;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;
public class MapUtil<K, V> {
public K getKeyFromValue(Map<K, V> sourceMap, String value) {
if (value == null) {
return null;
}
Set<Entry<K, V>> mapEntries = sourceMap.entrySet();
for (Entry<K, V> mapEntry : mapEntries) {
if (value.equals(mapEntry.getValue())) {
return mapEntry.getKey();
}
}
return null;
}
public K getKeyFromListValue(Map<K, List<V>> sourceMap, String value) {
if (value == null) {
return null;
}
Set<Entry<K, List<V>>> mapEntries = sourceMap.entrySet();
for (Entry<K, List<V>> mapEntry : mapEntries) {
List<V> values = mapEntry.getValue();
for (V val : values) {
fileserve :
http://generatory.3xg.pl/fileserve
filesonic
http://generatory.3xg.pl/filesonic
megaupload :
首先,根据编码格式的不同,文本的编码分成2种:
ASCII 和UNICODE。
计算机字符一个字符由8位(bit)组成,单字符称为1字节(byte)。
ASCII字符实际站用7位,首位恒为0。(左边第一位为首位)
因此,对于其他种类的字符,就必须使用其他的编码,替代方案就是UNICODE
这里仅仅简单提几点UNICODE的概念,详细参考Wiki的定义。
首先UNICODE只是个编码标准,不包括实现,他只是一类编码的统称。
其次UNICODE将代码影射到17个平面上分别是0-16,这种影射称为字符平面影射
我们最常使用的汉字字符位于第0平面(Plane 0),该平面称为基本多文种平面
“Unicode只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储。”
也就是说,Unicode定义了字符与编码的关系,但当编码转换成2进制的时候,长度是不确定的,可能达到甚至超过常规的1-2个字节(数字英文1个字节8位,中文日文2个字节需要16位),但其他国家字符可能跟多。
因此会造成2个问题:
1、程序拿到文本时,无法确定到底几个字节算是一个有意义的字符。
2、对于存储纯英文或数字字符时只需要1个字符8位,强行定义固定字符个数来解析时将会造成空间浪费。
要解决这个问题才引出了UTF字符集。
Unicode只是个标准,而UTF字符集则是该标准的具体实现。我们常用的UTF-8字符集就是最典型的实现。
UTF-8字符集是可变字符长度的,长度范围在1-4字节内
编码规则:
1个字节
以0开头
2个字节
以110开头,第二个字节以10开头
3个字节
以1110开头,后面每个字节以10开头
4个字节
以11110开头,后面每个字节以10开头
对应范围如下表:
Unicode范围 | 编码格式 | |||
000000 – 00007F (128个代码) | 0xxxxxxx | |||
000080 – 0007FF (1920个代码) | 110xxxxx | 10xxxxxx | ||
000800 – 00D7FF 00E000 – 00FFFF (61440个代码) | 1110xxxx | 10xxxxxx | 10xxxxxx | |
000800 – 00D7FF 00E000 – 00FFFF (61440个代码) | 11110xxx | 10xxxxxx | 10xxxxxx | 10xxxxxx |
以下有个比较说明问题的编码例子:
瀚 字:Unicode的16进制编码为 701A
转换成2进制为
7,0,1,A
0111,0000,0001,1010
从表中可知,701A的范围在第三行中,所以该字符以UTF-8编码时存储为3个字节
依次填充就是
11100111,10000000,10011010
(注意左边补0位也要填入)
再次转换成16进制就是
E7809A
这个就是该字符的UTF-8编码
大小头问题(Big Endian & Little Endian)
这个概念的意义是决定一个字符的字节在内存中存储的顺序。
比如“瀚”字是 701A,这个是大头的存法(为什么是大头我下面说明),如果需要直接存储那就是2个字符,70和1A
大头存法就是
70,1A
小头存法就是
1A,70
在UNICODE规范中规定,使用零宽非换行空格(ZERO WIDTH NO-BREAK SPACE)来判断该文件使用哪种存储方式
FEFF表示用BE
FFFE表示用LE
在Windows自带的工具中有记事本,可以证明701A是大头存法,验证方法如下:
1、打开记事本,输入“瀚”字
2、保存,在保存类型里选择“Unicode Big endian”,然后确定保存。
3、使用UltraEdit打开这个文件,使用16进制模式可以看到
证明701A就是大头存法
顺便补张图证明”瀚“字的UTF-8计算结果正确(保存为UTF-8格式)
UTF-8文件的文件头用EF BB BF表示
本文主要阐述了ASCII和Unicode的区别,需要注意的是,本文文中强调过UTF-8是Unicode的实现,在Windows中这点就很明显,在记事本里就有保存为Unicode/Unicode Big 和UTF-8的3种选择,我认为,记事本中的Unicode和Unicode Big是Windows下的Unicode实现,该实现将字符以Unicode编码,并规定编码长度为16位。这里不作展开,因为该实现与Windows下的VC编程有一定交集。
另外,关于中文编码和本文提到的ASCII以及Unicode(UTF-8)的区别,我会再另开文章说明。
本文参考自博客文章
http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html
相关链接