對(duì)于一些常量我們經(jīng)常放到property屬性文件中.
今天在對(duì)其的存取過(guò)程中遇到了些問(wèn)題:
1:取的時(shí)候掉了內(nèi)容
2:取出后出現(xiàn)亂碼
首先,我們的property文件大約如下:
#友情鏈接
news.link.inner.href?= http:
//
www.baidu.com,
http://www.baidu.com
,
http://www.baidu.com
new
.link.inner.title? = 百度1,百度2,百度3
1:取的時(shí)候掉了內(nèi)容的解決:
當(dāng)然我這個(gè)文件有些特殊,主要是針對(duì)跳轉(zhuǎn)下拉菜單的數(shù)據(jù)設(shè)計(jì)(用戶在日后擴(kuò)展數(shù)據(jù)的時(shí)候只需在后面直接添加,但必須以","號(hào)分開(kāi)).
在開(kāi)始我以如下方法來(lái)取:
private
?
void
?initiallink()
????
{
????????String?innerlinkstr?
=
?
null
;
????????String?innertitlestr?
=
?
null
;
????????String?outerlinkstr?
=
?
null
;
????????String?outertitlestr?
=
?
null
;
????????
????????StringTokenizer?innerlink?
=
?
null
;
????????StringTokenizer?innertitle?
=
?
null
;
????????StringTokenizer?outerlink?
=
?
null
;
????????StringTokenizer?outertitle?
=
?
null
;
????????
????????InputStream?in?
=
?
this
.getClass().getResourceAsStream(
"
/conf/netedu.properties
"
);
????????
try
?
{
????????????
try
?
{
????????????????Properties?props?
=
?
new
?Properties();
????????????????props.load(in);
????????????????innerlinkstr?
=
?props.getProperty(
"
news.link.inner.href
"
);
????????????????innertitlestr?
=
?props.getProperty(
"
new.link.inner.title
"
);
????????????????outerlinkstr?
=
?props.getProperty(
"
news.link.outer.href
"
);
????????????????outertitlestr?
=
?props.getProperty(
"
new.link.outer.title
"
);
????????????????
????????????????innerlink?
=
?
new
?StringTokenizer(innerlinkstr,
"
,
"
);
????????????????innertitle?
=
?
new
?StringTokenizer(innertitlestr,
"
,
"
);
????????????????outerlink?
=
?
new
?StringTokenizer(outerlinkstr,
"
,
"
);
????????????????outertitle?
=
?
new
?StringTokenizer(outertitlestr,
"
,
"
);
????????????????
????????????????innermap
=
?
this
.getlinks(innertitle,innerlink);
????????????????outermap?
=
?
this
.getlinks(outertitle,outerlink);
????????????????
????????????}
????????????
finally
?
{
????????????????in.close();
????????????}
????????}
????????
catch
?(Exception?ex)?
{
????????????log.debug(
"
Error?to?read?property?in?/conf/netedu.properties?file
"
);
????????}
????}
getLinks的方法如下:
/**?*/
/**
?????*?
@param
?titleargs?存放鏈接名稱的StringTokenizer
?????*?
@param
?linkargs?存放鏈接地址的StringTokenizer
?????*?return?hashmap(title,link)
?????*?兩個(gè)參數(shù)應(yīng)該有相同的長(zhǎng)度
?????
*/
????
private
?HashMap?getlinks(StringTokenizer?titles,?StringTokenizer?links)
????
{
????????HashMap?results?
=
?
new
?HashMap();
????????
????????
for
(
int
?i
=
0
;i
<
titles.countTokens();i
++
)
????????????results.put((String)titles.nextElement(),(String)links.nextElement());
????????
return
?results;
????}
但到JSP顯示的時(shí)候得到的results的長(zhǎng)度為2,也就是只取出了文件中的百度1,百度2(亂碼解決后才知道是這二個(gè)啦).在Eclipse中調(diào)試的時(shí)候發(fā)在getLinks方法中的for循環(huán)確實(shí)少執(zhí)行了次!為什么?(搞不懂!郁悶了半天),不得不將此方法的代碼加長(zhǎng)些(真受不了)
/**?*/
/**
?????*?
@param
?titleargs?存放鏈接名稱的StringTokenizer
?????*?
@param
?linkargs?存放鏈接地址的StringTokenizer
?????*?return?hashmap(title,link)
?????*?兩個(gè)參數(shù)應(yīng)該有相同的長(zhǎng)度
?????
*/
????
private
?HashMap?getlinks(StringTokenizer?titles,?StringTokenizer?links)
????
{
????????HashMap?results?
=
?
new
?HashMap();
????????
int
?len?
=
?titles.countTokens();
????????String[]?temp1?
=
?
new
?String[len];
????????String[]?temp2?
=
?
new
?String[len];
????????????
????????
for
(
int
?i
=
0
;i
<
len;i
++
)
????????
{
????????????temp1[i]?
=
?(String)titles.nextElement();
????????????temp2[i]?
=
?(String)links.nextElement();
????????}
????????
????????
for
(
int
?i
=
0
;i
<
len;i
++
)
????????
{
????????????results.put(temp1[i],temp2[i]);
????????}
????????
????????
return
?results;
????}
這簡(jiǎn)直一樣的處理啊?為什么結(jié)果會(huì)不同呢?
2:亂碼處理
亂碼其實(shí)簡(jiǎn)單,只是開(kāi)始的時(shí)候沒(méi)注意罷了.我們的機(jī)器編碼應(yīng)該是GBK方式的,而在JVM程序中讀取Property文件的時(shí)候使用的是Unicode編碼方式,(我的這些處理過(guò)程也沒(méi)對(duì)編碼文件請(qǐng)求進(jìn)行過(guò)濾),所以我們可以對(duì)其進(jìn)行對(duì)應(yīng)的編碼.
我是利用了JDK自帶的native2ascii.exe工具.
通過(guò)--encoding 來(lái)指定其編碼方式
native2ascii -encoding GBK sourcefilename? destfilename?
這樣你在
InputStream?in?=?this.getClass().getResourceAsStream("/conf/netedu.properties");
語(yǔ)句中用到的/conf/netedu.properties文件就是destfilename?來(lái)代替就OK了
只是這樣你看到的可能是如下的一些代碼:
#\u5385\u5185\u94fe\u63a5
-----
\u7528,\u9694\u5f00
news.link.inner.href?http:
//
www.baidu.com,
http://www.baidu.com
,
http://www.baidu.com
new
.link.inner.title?\u767e\u5ea61,\u767e\u5ea62,\u767e\u5ea63
當(dāng)然你不可能對(duì)著一大堆的16進(jìn)制看吧,所以可以通過(guò) -reverse 來(lái)解碼.
native2ascii -reverse? sourcefilename? destfilename?
本人覺(jué)得對(duì)于大量文本的處理,比如說(shuō)整個(gè)項(xiàng)目的國(guó)際化,這樣可以通過(guò)對(duì)整個(gè)文件編碼來(lái)處理,但若只是為了一個(gè)下拉框,就顯得有些大材小用了(再說(shuō)對(duì)用戶來(lái)說(shuō),他們也得多一步去執(zhí)行項(xiàng)目里的腳本代碼).所以我們可以在疊代標(biāo)題(這些就是"百度")StringTokenizer的時(shí)候?qū)ζ渲匦戮幋a.這時(shí)可用將getLinks()方法中的
?
for
(
int
?i
=
0
;i
<
len;i
++
)
????????
{
????????????temp1[i]?
=
?(String)titles.nextElement();
????????????temp2[i]?
=
?(String)links.nextElement();
????????}
改成
for
(
int
?i
=
0
;i
<
len;i
++
)
????????
{
????????????String?s?
=
?(String)titles.nextElement();
????????????
try
?
{
????????????????temp1[i]?
=
?
new
?String(s.getBytes(
"
ISO-8859-1
"
),
"
GBK
"
);
????????????}
?
catch
?(UnsupportedEncodingException?e)?
{
????????????????e.printStackTrace();
????????????}
????????????temp2[i]?
=
?(String)links.nextElement();
????????}
注意:"ISO-8859-1"與"GBK"對(duì)應(yīng)的分別是源編碼與目標(biāo)編碼方式.
關(guān)于native2ascii的詳細(xì)用法,可以參考相關(guān)文檔,as this:
native2ascii?-?Native-to-ASCII?Converter
Converts?a?file?with?native-encoded?characters?(characters?which?are?non-Latin?1?and?non-Unicode)?to?one?with?Unicode-encoded?characters.?
SYNOPSIS
native2ascii?[options]?[inputfile?[outputfile]]
DESCRIPTION
The?Java?compiler?and?other?Java?tools?can?only?process?files?which?contain?Latin-1?and/or?Unicode-encoded?(\udddd?notation)?characters.?native2ascii?converts?files?which?contain?other?character?encodings?into?files?containing?Latin-1?and/or?Unicode-encoded?charaters.?
If?outputfile?is?omitted,?standard?output?is?used?for?output.?If,?in?addition,?inputfile?is?omitted,?standard?input?is?used?for?input.?
OPTIONS
-reverse?
Perform?the?reverse?operation:?convert?a?file?with?Latin-1?and/or?Unicode?encoded?characters?to?one?with?native-encoded?characters.?
-encoding?encoding_name?
Specify?the?encoding?name?which?is?used?by?the?conversion?procedure.?The?default?encoding?is?taken?from?System?property?file.encoding.?The?encoding_name?string?must?be?a?string?taken?from?the?first?column?of?the?table?below.?
-------------------------------------------------------------
Converter????????Description
Class
-------------------------------------------------------------
8859_1???????????ISO?8859-1
8859_2???????????ISO?8859-2
8859_3???????????ISO?8859-3
8859_4???????????ISO?8859-4
8859_5???????????ISO?8859-5
8859_6???????????ISO?8859-6
8859_7???????????ISO?8859-7
8859_8???????????ISO?8859-8
8859_9???????????ISO?8859-9
Big5?????????????Big5,?Traditional?Chinese
CNS11643?????????CNS?11643,?Traditional?Chinese
Cp037????????????USA,?Canada(Bilingual,?French),?Netherlands,
???????????????????????????????Portugal,?Brazil,?Australia
Cp1006???????????IBM?AIX?Pakistan?(Urdu)
Cp1025???????????IBM?Multilingual?Cyrillic:?Bulgaria,?Bosnia,
???????????????????????????????Herzegovinia,?Macedonia(FYR)
Cp1026???????????IBM?Latin-5,?Turkey
Cp1046???????????IBM?Open?Edition?US?EBCDIC
Cp1097???????????IBM?Iran(Farsi)/Persian
Cp1098???????????IBM?Iran(Farsi)/Persian?(PC)
Cp1112???????????IBM?Latvia,?Lithuania
Cp1122???????????IBM?Estonia
Cp1123???????????IBM?Ukraine
Cp1124???????????IBM?AIX?Ukraine
Cp1125???????????IBM?Ukraine?(PC)
Cp1250???????????Windows?Eastern?European
Cp1251???????????Windows?Cyrillic
Cp1252???????????Windows?Latin-1
Cp1253???????????Windows?Greek
Cp1254???????????Windows?Turkish
Cp1255???????????Windows?Hebrew
Cp1256???????????Windows?Arabic
Cp1257???????????Windows?Baltic
Cp1258???????????Windows?Vietnamese
Cp1381???????????IBM?OS/2,?DOS?People's?Republic?of?China?(PRC)
Cp1383???????????IBM?AIX?People's?Republic?of?China?(PRC)
Cp273????????????IBM?Austria,?Germany
Cp277????????????IBM?Denmark,?Norway
Cp278????????????IBM?Finland,?Sweden
Cp280????????????IBM?Italy
Cp284????????????IBM?Catalan/Spain,?Spanish?Latin?America
Cp285????????????IBM?United?Kingdom,?Ireland
Cp297????????????IBM?France
Cp33722??????????IBM-eucJP?-?Japanese?(superset?of?5050)
Cp420????????????IBM?Arabic
Cp424????????????IBM?Hebrew
Cp437????????????MS-DOS?United?States,?Australia,?New?Zealand,
???????????????????????????????South?Africa
Cp500????????????EBCDIC?500V1
Cp737????????????PC?Greek
Cp775????????????PC?Baltic
Cp838????????????IBM?Thailand?extended?SBCS
Cp850????????????MS-DOS?Latin-1
Cp852????????????MS-DOS?Latin-2
Cp855????????????IBM?Cyrillic
Cp857????????????IBM?Turkish
Cp860????????????MS-DOS?Portuguese
Cp861????????????MS-DOS?Icelandic
Cp862????????????PC?Hebrew
Cp863????????????MS-DOS?Canadian?French
Cp864????????????PC?Arabic
Cp865????????????MS-DOS?Nordic
Cp866????????????MS-DOS?Russian
Cp868????????????MS-DOS?Pakistan
Cp869????????????IBM?Modern?Greek
Cp870????????????IBM?Multilingual?Latin-2
Cp871????????????IBM?Iceland
Cp874????????????IBM?Thai
Cp875????????????IBM?Greek
Cp918????????????IBM?Pakistan(Urdu)
Cp921????????????IBM?Latvia,?Lithuania?(AIX,?DOS)
Cp922????????????IBM?Estonia?(AIX,?DOS)
Cp930????????????Japanese?Katakana-Kanji?mixed?with?4370?UDC,
???????????????????????????????superset?of?5026
Cp933????????????Korean?Mixed?with?1880?UDC,?superset?of?5029
Cp935????????????Simplified?Chinese?Host?mixed?with?1880?UDC,
???????????????????????????????superset?of?5031
Cp937????????????Traditional?Chinese?Host?miexed?with?6204?UDC,
?????????????????????????&n0