public static void main(string args) throws filenotfoundexception, ioexception而且對於配置獲取，沒有特殊要求的封裝，直接對屬性名稱進行獲取也是十分方便。
注意前置contains判斷，並打出屬性key，這樣更能及時發現和定位錯誤。
但是這種辦法在某些場景下，就會讓人抓狂。比如？亂碼了。
直接的簡單載入是沒辦法指定編碼格式的，而差異由此而來。
properties預設使用的是os指定的檔案編碼，一般情況下，不會出現問題，即使有些許的問題，在eclipse或idea中修改檔案編碼或properties編碼問題就會得到解決。
但是當windows的程式打包然後部署到linux上？檔案亂碼就會讓人氣炸，但是卻無可奈何。
恰好的編碼對上了，這些問題便不存在，只是經過各種體位的修改linux檔案型別，我才發現這東西對於細節的處理的確迷惑了很多人。
總結一下，亂碼原因有二
properties預設使用os預設字元編碼，機器不同，字符集有差異
檔案型別不對，也會讀出亂碼
解決辦法也是兩方面
統一os字元編碼
針對檔案指定字符集
對於第一種，意義的確不大。
因為你不可能把所有的機器做統一，尤其是系統做大了的時候；而且運維人員的個人習慣差異，這是強求不來的。
而且，程式講究的是普適，是魯棒性，因此專門針對第二點動手
第二種嘛，和os不再相關，到哪都一樣(如果是跨平台語言的話)
注意兩點
程式指定編碼
修改檔案編碼
public static void main(string args) throws filenotfoundexception, ioexception位元組流
二進位製碼流，對於所有檔案通用，未編碼直接是unicode
字元流
專門針對語言文字封裝的檔案流，支援對各編碼字符集的操作，對文字的處理比字元流更快速。
好吧，不用多說，properties配置是文字檔案，字元流是支援的，然後指定一下編碼字符集就ok了。
然後載入的時候，和os與os的預設字符集就沒多大關係了。
接下來唯一的問題就是文字檔案的字符集問題了，接下來介紹一下linux下的文字字符集修改和檢視操作。
file
file filename
檢視檔案字符集
當windows直接上傳的時候還有特殊提示哦
crlf，所以window上傳到linux的文字最好dos2unix一下
:set fenc="utf-8"
熟悉vi的就不多說了，設定檔案編碼，統一一下就好了，檔案編碼就是讀取檔案時指定的編碼。
iconv
這個嘛，主要協助工作，也可以換換口味。
iconv -l
檢視linux支援的字符集
iconv -f from_encoding -t to_encoding filename
外部修改，指定檔案從from_encoding轉碼到to_encoding
iconv filename -f from_encoding -t to_encoding -o new_filename
轉碼內容輸出到指定檔案，當然了，也可以手動指定輸出
iconv -f from_encoding -t to_encoding filename > new_filename
over，反正問題不大。
java 讀取配置檔案
前幾天因為配置檔案的事，線上的job掛掉了，使用的是spring載入配置檔案方式。spring配置如下 test.properties api test.properties decryptpropertyplaceholderconfigurer類如下所示。public class decrypt...
java讀取配置檔案
現今的程式都要求能夠讀寫配置檔案，使得程式的配置資訊能夠很方便地修改。讀取配置檔案通常使用property檔案，下面列舉了從hadoop的hdfs和本地的檔案系統讀取配置的例子。話不多說，上 讀取hdfs配置檔案 public static properties getpropertiesfromh...
java讀取配置檔案property
properties pro new properties try catch filenotfoundexception e catch ioexception e propertynames 返回屬性列表中所有鍵的列舉 enumeration enu2 pro.propertynames whi...