Appendable介面和(7064:1983.MOD 11-2)演算法

標籤：style   code   java   http   資料   string   

1 Appendable介面

如果某個類的執行個體打算接收取自 Formatter 的格式化輸出，那麼該類必須實現 Appendable 介面。

java.lang的StringBuffer、StringBuilder實現了該介面。

格式化主要用在文本輸出方面，比如，數字、日期、金額等。

 

2 7064:1983.MOD 11-2演算法

以下可以說明為什麼身份證校正碼裡非得有X。

該演算法的主要應用有身份證校正碼。校正碼通常是一組數位最後一位，由前面的數字通過某種運算得出，用以檢驗該組數位正確性。身份證校正碼的作用即是對身份證的前17位元字進行運算得到第18位，以初步檢驗該組數字正確性。

該演算法函數的構造方式為mod((2^(i-1) * ai), 11)，這個i是身份證17位元據從左至右的編號，從1~17。sigma(xi)表示x1+x2+……+x17。

這裡和這個演算法的具體結果可能不一樣，i的編排方式，計算結果後模取反(如5%11=5，取反後(12-5)%11 = 7)等，忽略這些差別。

這樣做的放，校正碼對17位的其中一位出錯是可以校正出來的，對兩位非同樣位置的錯誤也是可以校正出來的，對三位以上的某些，是可以校正出來的。由於一位出錯的機率要遠遠高於二位再遠遠遠高於三位，所以該演算法的校正能力應該是非常強的(除非故意設計)。

所以該演算法最後一位增加了X，使校正的能力增加到11和身份證的位元17沒有關係，而是和每一位的進位有關係。即如果每一位元字範圍是0~6，校正碼就是0~7了。

當然，這裡還有一點問題，如果跟進位有關，0~9也只需要10種標識來區別，校正碼錶示的可能值至少為10，而不是11。這是由於校正碼的可能性為10時，和模數可能會有問題，a1為奇數，結果就為奇數。這是和其基底2相關的，也就是說校正碼的可能值個數與基底應該是正交的。這應該就是演算法名中11-2的含義。

據此，我們可以構造一個10-3演算法，這樣，身份證上就不必要有X了。但與11-2相比，10-3有一個劣勢：目前記憶體資料按2進位存放，11-2演算法對有兩位(相鄰位？)出錯的情況，檢出率更高一些(目測)。