#============================================================Logger CommonLog
log4j.logger.CommonLog=DEBUG, Console, LogRollingFile
# Console output...
log4j.appender.Console=org.apache.log4j.ConsoleAppender
log4j.appender.Console.layout=org.apache.log4j.PatternLayout
log4j.appender.Console.layout.ConversionPattern=[%-5p] %d{yyyy-MM-dd HH:mm:ss,SSS} method:%l%n%m%n
# RollingFileAppender output...
log4j.appender.LogRollingFile=org.apache.log4j.RollingFileAppender
log4j.appender.LogRollingFile.File=${user.dir}/yccb/log/yccb.log
log4j.appender.LogRollingFile.Append=true
log4j.appender.LogRollingFile.MaxFileSize=46MB
log4j.appender.LogRollingFile.MaxBackupIndex=50
log4j.appender.LogRollingFile.layout=org.apache.log4j.PatternLayout
log4j.appender.LogRollingFile.layout.ConversionPattern=[%-5p] %d{yyyy-MM-dd HH\:mm\:ss,SSS} method\:%l%n%m%n
#============================================================Logger SkmLog
log4j.logger.SkmLog=DEBUG, DailyRollingFile
# DailyRollingFile output...
log4j.appender.DailyRollingFile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.DailyRollingFile.DatePattern=yyyy-MM-dd'.log'
log4j.appender.DailyRollingFile.File=${user.dir}/yccb/log/skm/skm.log
log4j.appender.DailyRollingFile.layout=org.apache.log4j.PatternLayout
log4j.appender.DailyRollingFile.layout.ConversionPattern=[%-5p] %d{yyyy-MM-dd HH\:mm\:ss,SSS} method\:%l%n%m%n
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
sdf.setLenient(false);
boolean b = true;
try {
sdf.parse("2002-15-11");
} catch (ParseException e) {
e.printStackTrace();
b = false;
}
System.out.println(b);
http://blog.csdn.net/wuxianglong/article/details/6285978
1，公鑰和私鑰成對出現
2，公開的密鑰叫公鑰，只有自己知道的叫私鑰
3，用公鑰加密的數據只有對應的私鑰可以 解密
4，用私鑰加密的數據只有對應的公鑰可以解密
5，如果可以用公鑰解密，則必然是對應的私鑰加的密
6，如果可以用私鑰解密，則 必然是對應的公鑰加的密
明白了？
假設一下，我找了兩個數字，一個是1，一個是2。我喜歡2這個數字，就保留起來，不告訴你們，然 后我告訴大家，1是我的公鑰。
我有一個文件，不能讓別人看，我就用1加密了。別人找到了這個文件，但是他不知道2就是解密的私鑰啊，所以 他解不開，只有我可以用數字2，就是我的私鑰，來解密。這樣我就可以保護數據了。
我的好朋友x用我的公鑰1加密了字符a，加密后成了b， 放在網上。別人偷到了這個文件，但是別人解不開，因為別人不知道2就是我的私鑰，只有我才能解密，解密后就得到a。這樣，我們就可以傳送加密的數據了。
現在我們知道用公鑰加密，然后用私鑰來解密，就可以解決安全傳輸的問題了。如果我用私鑰加密一段數據（當然只有我可以用私鑰加密，因為只有我知道 2是我的私鑰），結果所有的人都看到我的內容了，因為他們都知道我的公鑰是1，那么這種加密有什么用處呢？
但是我的好朋友x說有人冒充我 給他發信。怎么辦呢？我把我要發的信，內容是c，用我的私鑰2，加密，加密后的內容是d，發給x，再告訴他解密看是不是c。他用我的公鑰1解密，發現果然 是c。這個時候，他會想到，能夠用我的公鑰解密的數據，必然是用我的私鑰加的密。只有我知道我得私鑰，因此他就可以確認確實是我發的東西。這樣我們就能確 認發送方身份了。這個過程叫做數字簽名。當然具體的過程要稍微復雜一些。用私鑰來加密數據，用途就是數字簽名。
好，我們復習一下：
1， 公鑰私鑰成對出現
2，私鑰只有我知道
3，大家可以用我的公鑰給我發加密的信了
4，大家用我的公鑰解密信的內容，看看能不能解開， 能解開，說明是經過我的私鑰加密了，就可以確認確實是我發的了。
總結一下結論：
1，用公鑰加密數據，用私鑰來解密數據
2， 用私鑰加密數據（數字簽名），用公鑰來驗證數字簽名。
在實際的使用中，公鑰不會單獨出現，總是以數字證書的方式出現，這樣是為了公鑰的安 全性和有效性。
二，SSL
我和我得好朋友x，要進行安全的通信。這種通信可以是QQ聊天，很頻繁的。用我的公鑰加密數據就不行 了，因為：
1，我的好朋友x沒有公私鑰對，我怎么給他發加密的消息啊？ （注：實際情況中，可以雙方都有公私鑰對）
2，用公私鑰加密運算 很費時間，很慢，影響QQ效果。
好了，好朋友x，找了一個數字3，用我的公鑰1，加密后發給我，說，我們以后就用這個數字來加密信息吧。 我解開后，得到了數字3。這樣，只有我們兩個人知道這個秘密的數字3，別的人都不知道，因為他們既不知x挑了一個什么數字，加密后的內容他們也無法解開， 我們把這個秘密的數字叫做會話密鑰。
然后，我們選擇一種對稱密鑰算法，比如DES，（對稱算法是說，加密過程和解密過程是對稱的，用一個 密鑰加密，可以用同一個密鑰解密。使用公私鑰的算法是非對稱加密算法），來加密我們之間的通信內容。別人因為不知道3是我們的會話密鑰，因而無法解密。
好，復習一下：
1，SSL實現安全的通信
2，通信雙方使用一方或者雙方的公鑰來傳遞和約定會話密鑰 （這個過程叫做握手）
3， 雙方使用會話密鑰，來加密雙方的通信內容
上面說的是原理。大家可能覺得比較復雜了，實際使用中，比這還要復雜。不過慶幸的是，好心的先行 者們在操作系統或者相關的軟件中實現了這層（Layer），并且起了一個難聽的名字叫做SSL，（Secure Socket Layer）。
超文本傳輸安全協議（縮寫：HTTPS，英語：Hypertext Transfer Protocol Secure）是超文本傳輸協議和SSL/TLS的組合，用以提供加密通訊及對網絡服務器身份的鑒定。HTTPS連接經常被用于萬維網上的交易支付和企業信息系統中敏感信息的傳輸。HTTPS不應與在RFC 2660中定義的安全超文本傳輸協議（S-HTTP）相混。
主要思想
HTTPS的主要思想是在不安全的網絡上創建一安全信道，并可在使用適當的加密包和服務器證書可被驗證且可被信任時，對竊聽和中間人攻擊提供合理的保護。
HTTPS的信任繼承基于預先安裝在瀏覽器中的證書頒發機構（如VeriSign、Microsoft等）（意即“我信任證書頒發機構告訴我應該信任的”）。因此，一個到某網站的HTTPS連接可被信任，當且僅當：
- 用戶相信他們的瀏覽器正確實現了HTTPS且安裝了正確的證書頒發機構；
- 用戶相信證書頒發機構僅信任合法的網站；
- 被訪問的網站提供了一個有效的證書，意即，它是由一個被信任的證書頒發機構簽發的（大部分瀏覽器會對無效的證書發出警告）；
- 該證書正確地驗證了被訪問的網站（如，訪問
https://example時收到了給“Example Inc.”而不是其它組織的證書）； - 或者互聯網上相關的節點是值得信任的，或者用戶相信本協議的加密層（TLS或SSL）不能被竊聽者破壞。
技術細節
- pasting
與HTTP的差異[編輯]
與HTTP的URL由“http://”起始且默認使用端口80不同，HTTPS的URL由“https://”起始且默認使用端口443。
HTTP是不安全的，且攻擊者通過監聽和中間人攻擊等手段，可以獲取網站帳戶和敏感信息等。HTTPS被設計為可防止前述攻擊，并（在沒有使用舊版本的SSL時）被認為是安全的。
網絡層[編輯]
HTTP工作在應用層（OSI模型的最高層），但安全協議工作在一個較低的子層：在HTTP報文傳輸前對其加密，并在到達時對其解密。嚴格地講，HTTPS并不是一個單獨的協議，而是對工作在一加密連接（TLS或SSL）上的常規HTTP協議的稱呼。
HTTPS報文中的任何東西都被加密，包括所有報頭和荷載。除了可能的CCA（參見限制小節）之外，一個攻擊者所能知道的只有在兩者之間有一連接這一事實。
服務器設置[編輯]
要使一網絡服務器準備好接受HTTPS連接，管理員必須創建一數字證書，并交由證書頒發機構簽名以使瀏覽器接受。證書頒發機構會驗證數字證書持有人和其聲明的為同一人。瀏覽器通常都預裝了證書頒發機構的證書，所以他們可以驗證該簽名。
獲得證書[編輯]
由證書頒發機構簽發的證書有免費的[3][4]，也有每年收費13美元[5]到1500美元[6]不等的。
一個組織也可能有自己的證書頒發機構，尤其是當設置瀏覽器來訪問他們自己的網站時（如，運行在公司或學校局域網內的網站）。他們可以容易地將自己的證書加入瀏覽器中。
此外，還存在一個人到人的證書頒發機構，CAcert。
作為訪問控制[編輯]
HTTPS也可被用作客戶端認證手段來將一些信息限制給合法的用戶。要做到這樣，管理員通常會給每個用戶創建證書（通常包含了用戶的名字和電子郵件地址）。這個證書會被放置在瀏覽器中，并在每次連接到服務器時由服務器檢查。
當私鑰失密時[編輯]
TLS有兩種策略：簡單策略和交互策略。交互策略更為安全，但需要用戶在他們的瀏覽器中安裝個人的證書來進行認證。
不管使用了哪種策略，協議所能提供的保護總強烈地依賴于瀏覽器的實現和服務器軟件所支持的加密算法。
HTTPS并不能防止站點被網絡蜘蛛抓取。在某些情形中，被加密資源的URL可僅通過截獲請求和響應的大小推得，[11]這就可使攻擊者同時知道明文（公開的靜態內容）和密文（被加密過的明文），從而使選擇密文攻擊成為可能。
因為SSL在HTTP之下工作，對上層協議一無所知，所以SSL服務器只能為一個IP地址/端口組合提供一個證書。[12]這就意味著在大部分情況下，使用HTTPS的同時支持基于名字的虛擬主機是不很現實的。一種叫域名指示（SNI）的方案通過在加密連接創建前向服務器發送主機名解決了這一問題。Firefox 2、Opera8和運行在Windows Vista的Internet Explorer 7都加入了對SNI的支持。[13][14][15]
因為HTTPS連接所用的公鑰以明文傳輸，因此中國大陸的防火長城可以對特定網站按照匹配的黑名單證書，通過偽裝成對方向連接兩端的計算機發送RST包干擾兩臺計算機間正常的TCP通訊，以打斷與特定IP地址之間的443端口握手，或者直接使握手的數據包丟棄，導致握手失敗，從而導致TLS連接失敗。[16]這也是一種互聯網信息審查和屏蔽的技術手段。
如果Mac OS X中的家長控制被啟用，那么HTTPS站點必須顯式地在“總是允許”列表中列出。[17]