SIM，PIN，PUK，IMEI，ICCID，Ki，IMSI，SMSP概念

1、什麼是SIM卡
移動電話機與SIM卡共同構成移動通信終端設備。無論是GSM系統還是CDMA系統，數字移動電話機用戶在“入網”時會得到一張SIM卡。SIM卡 是（Subscriber Identity Model 客戶識別模塊）的縮寫 ，也稱為智能卡、用戶身份識別卡, GSM數字移動電話機必須裝上此卡方能使用。
SIM卡就是一個在內部包含有大規模集成電路的卡片，卡片內部存儲了數字移動電話客戶的信息、加密密鑰等內容，它可供GSM網絡對客戶身份進行鑒別，並對客戶通話時的語音信息進行加密。SIM卡的使用，完全防止了並機和通話被竊聽行為，並且 SIM卡的制作是嚴格按照GSM國際標准和規范來完成的，它使客戶的正常通信得到了可靠的保障。現在的數字電話都是必須要安裝SIM卡之后才可以使用，如果不安裝的話，那麼后果相信也就也不用我多說了。在沒有安裝SIM卡的情況下，我們僅僅隻能撥打像119、112這種緊急電話的號碼。
SIM卡在GSM系統中的應用，使得卡和手機分離，一張SIM卡唯一標識一個客戶。一張SIM卡可以插入任何一部GSM手機中使用，而使用手機所產生的通信費用則自動記錄在該SIM卡所唯一標識的客戶的帳戶上。

SIM卡內部的數據
了解完SIM卡的大概之后，我們再來看看SIM卡具體都能存儲哪些類型的數據。以目前的情況來看，SIM卡能夠存儲的數據類型主要被分為以下四種：

1. 由SIM卡生產廠商存入的系統原始數據存儲手機的固定信息，手機在出售之前都會被SIM卡中心記錄到SIM卡當中，主要包括鑒權和加密信息、國際移動用戶識別碼（IMSI）、IMSI認証算法、加密密匙生成算法、密匙生成前，用戶密匙的生成算法（這三種算法均為128位）


2. 用戶自己存入的數據，如短消息、固定撥號、縮位撥號、性能參數、話費記數等；能夠存儲有關的電話號碼，也就是具備電話簿功能。


3. 有關於網絡方面的數據，用戶在用卡過程中自動存入和更新的網絡接續和用戶信息類數據，包括最近一次位置登記時手機所在位置識別號、設置的周期性位置更新間隔時間、臨時移動用戶號等。不過這種數據的存放是暫時性的，也就是說它並不是永久的存放於SIM卡之中。


4. 相關的業務代碼，這一點相信也是大家很熟悉的，那就是非常重要的個人識別碼(也就使我們平常所說的PIN碼)，還有就是解開鎖定用的解鎖碼(PUK)等等。

以上四種類型的數據都是存儲在SIM卡當中的，而我們通常也是可以利用這些數據來進行手機的設置，每張SIM卡個人密碼(PIN)都是可以由用戶設置，利用加密的功能可以實現防止手機被其它人所盜用甚至被竊聽，由此看來SIM卡不僅僅可以為我們提供打電話的功能，而且還為我們保護自己的隱私而提供了安全的保障。
SIM卡內部的數據都存放在各自的目錄項內，第一類數據放在根目錄，當電源開啟后首先進入根目錄，再根據指令進入相關的子目錄，每種目錄及其內部的數據域均有各自的識別碼保護，隻有經過核對判別以后才能對數據域中的數據進行查詢、讀出和更新。上面第一類數據通常屬於永久性數據，由SIM卡生產廠商注入以后無法更改，第二類數據隻有網絡運行部門的專門機構才允許查閱和更新，第三、四類數據中的大部分允許用戶利用手機對其進行讀寫操作。

SIM卡的類型
SIM卡的存儲容量有3kB、8kB、16kB、32kB、64kB等。STK卡(SIM application Tool Kit)是SIM卡的一種，它能為手機提供增值服務，如移動夢網業務等。SIM卡能夠儲存多少電話號碼和短信取決於卡內數據存儲器EEPROM的容量（有2KB、3KB、8KB容量），假設一張EEPROM容量為8KB的SIM卡，可儲存以下容量的數據：100組電話號碼及其對應姓名、15組短信息、25組最近撥出的號碼、4位SIM卡密碼（PIN）。目前中國移動/中國聯通實際對普通用戶提供的多數是普通8K的SIM卡。

SIM卡的接口
SIM卡是通過卡面上銅制接口來連接卡內邏輯電路與移動終端的，SIM卡芯片有8個觸點，通常與移動設備連接需要6個觸點。
SIM卡是一個裝有微處理器（CPU）的芯片卡，它的內部有5個模塊，並且每個模塊都對應一個功能：微處理器CPU（8位）、程序存儲器ROM（3～8kbit）、工作存儲器RAM（6～16kbit）數據存儲器EEPROM（16～256kbit）和串行通信單元。這5個模塊被膠封在SIM卡銅制接口后與普通IC卡封裝方式相同。這5個模塊必須集成在一塊集成電路中，否則其安全性會受到威脅，因為芯片間的連線可能成為非法存取和盜用SIM卡的重要線索。
SIM卡的供電分為5V（1998年前發行）、5V與3V兼容、3V、1.8V等，當然這些卡必須與相應的手機配合使用，即手機產生的SIM卡供電電壓與該SIM卡所需的電壓相匹配。SIM卡插入手機后，電源端口提供電源給SIM卡內各模塊。

SIM外觀
在實際使用中有兩種功能相同而形式不同的SIM卡：卡片式（俗稱大卡）SIM卡，這種形式的SIM卡符合有關IC卡的ISO7816標准，類似IC卡；嵌入式（俗稱小卡）SIM卡，其大小隻有25mm×15mm，是半永久性地裝入到移動台設備中的卡。
“大卡”上真正起作用的是它上面的那張“小卡”，而“小卡”上起作用的部分則是卡面上的銅制接口及其內部膠封的卡內邏輯電路。目前國內流行樣式是“小卡”，小卡也可以換成“大卡”（需加裝一卡托）。“大卡”和“小卡”分別適用於不同類型的GSM移動電話，早期機型如摩托羅拉GC87C、308C等手機用的是“大卡”，而目前新出的機型基本上都使用“小卡”
在SIM卡的背面有以五個一排，被排成四排的一組數字，在這組數字最前面的六位數字所代表的是中國的代號，就像從國外打電話到國內都需要先撥打86一樣。第七位數字則代表的是接入號碼，如果是5的話，那麼這張SIM卡的電話號碼前三位就是135的，而如果是6的話，則代表其前三位數字為136，其它的也都以此類推。第八位數字代表的是該SIM卡的功能位，一般情況下顯示的數字為0。第九和第十位數字代表了該SIM卡所處的省份。至於第十一和第十二位數字則代表的是該SIM卡的年號，而第十三位數字則是SIM卡供應商的代碼。從第十四位開始至第十九位數字則代表了該SIM卡的用戶識別碼。最后一個數字是校驗位。

2、PIN、PUK碼介紹
我們在使用手機時，會接觸到5種密碼 ：SIM卡的PIN、PIN2、PUK、PUK2和手機密碼。前四種初始密碼都是SIM卡供應商移動、聯通提供的，手機密碼是手機生產商提供的。它們之間的關系如下：

PIN碼(即PIN1碼)就是SIM卡的個人識別密碼 ，一般在修改前原始密碼是1234，如果不是就不要再試了，打1860/1001咨詢。打開開機PIN碼，剛每次開機后就要輸入PIN碼！如果輸入三次錯誤，需要用 PUK 碼 解鎖， PUK 碼 由移動、聯通提供，如果輸入十次錯誤會導致SIM卡燒毀，所以有問題不要自己隨便猜測密碼 ，馬上找移動、聯通。

PIN2碼是設定手機計費時使用的，如果輸入三次錯誤需要用 PUK 2碼解鎖。目前移動、聯通都不提供此項功能支持，即使PIN2 密碼鎖死也不會影響手機正常使用。

PIN碼連續輸入10次都是錯誤的話就會鎖卡要求用 PUK 碼 來解開，而 PUK 碼的輸入機會隻有3次，3次都輸錯的話，SIM卡將會給永久鎖死，即報廢了。

PUK碼，不管你使用的是全球通還是神州行，網絡服務商那裡都有資料保存，一旦需要輸入時，可以致電相應的服務熱線來查詢，先核對用戶資料就行了。這些密碼設定及更改都在菜單－其他設定－安全設定中。

忘記PIN碼可以用 PUK碼來解密， PUK密碼一般不向用戶提供，但某些SIM卡除外，比如神州行的用戶就隨卡提供PUK 。如果你的SIM卡的 PUK 沒有隨卡提供，你可以到當地的網絡運營商營業廳要求解鎖，一般是免費的。

3、什麼是Ki、IMEI、IMSI、SMSP
國際移動設備識別碼（IMEI：International Mobile Equipment Identification Number）是區別移動設備的標志，儲存在移動設備中，可用於監控被竊或無效的移動設備。IMEI組成如下圖所示，移動終端設備通過鍵入“*#06#”即可查得。其總長為15位，每位數字僅使用0～9的數字。其中TAC代表型號裝配碼，由歐洲型號標准中心分配；FAC代表裝配廠家號碼；SNR為產品序號，用於區別同一個TAC和FAC中的每台移動設備；SP是備用編碼。
國際移動用戶識別碼（IMSI：International Mobile Subscriber Identification Number）是區別移動用戶的標志，儲存在SIM卡中，可用於區別移動用戶的有效信息。IMSI組成如下圖所示，其總長度不超過15位，同樣使用0～9的數字。 其中MCC是移動用戶所屬國家代號，佔3位數字，中國的MCC規定為460；MNC是移動網號碼，最多由兩位數字組成，用於識別移動用戶所歸屬的移動通信網；MSIN是移動用戶識別碼，用以識別某一移動通信網中的移動用戶。
Ki (Key identifier)是SIM卡與運營商之間加密數據傳遞的密鑰。GSM的加密方式是一種稱為comp-128的數字加密運算，當系統進行驗証時會同時使用Ki及IMSI，經過一連串系統安全認証訊息后產生隨機變量，並以A3算法進行加密運算與手機內存資料進行比對，當身份確認無誤后始可入網。目前GSM使用的Ki長度是16 bytes，相當於128bits，若非經過特殊譯碼程序，使用者無法讀取Ki，安全性極高，使用者無須擔心有被盜打電話的顧慮。
由此看來，隻要知道SIM卡的Ki、IMSI值，我們就可以通過軟件仿真出SIM卡的功能，甚至可以利用多組Ki、IMSI值，用一張微處理器卡片來同時仿真本來需要多張SIM所完成的功能，這就是“一卡多號”技術。

SMSP--短消息中心
對於中國移動，短消息中心號碼以+8613800開頭，緊接3位該號碼所在的地區碼（電話區號），比方571（杭州），最后一般是500。因此杭州移動的手機短消息中心為+8613800571500。對於區號小於三位的地區，地區碼則在第三位補0，例如北京100，上海210。
中國聯通的短消息中心對應表如下：
北京 +8613010112500或008613010112500
上海 +8613010314500或008613010314500
深圳 +8613010888500或008613010888500
山東 +8613010171500或008613010171500
江蘇 +8613010341500或008613010341500
浙江 +8613010360500或008613010360500
福建 +8613010380500或008613010380500
四川 +8613010811500或008613010811500
重慶 +8613010831500或008613010831500
海南 +8613010501500或008613010501500
黑龍江 +8613010980500或008613010980500
吉林 +8613010911500或008613010911500
天津 +8613010130500或008613010130500
河北 +8613010180500或008613010180500
內蒙 +8613010950500或008613010950500
山西 +8613010701500或008613010701500
安徽 +8613010305500或008613010305500
新疆 +8613010969500或008613010969500
青海 +8613010776500或008613010776500
甘肅 +8613010879500或008613010879500
寧夏 +8613010796500或008613010796500
貴州 +8613010788500或008613010788500
雲南 +8613010868500或008613010868500
湖南 +8613010731500或008613010731500
湖北 +8613010710500或008613010710500
廣東 +8613010200500或008613010200500
廣西 +8613010591500或008613010591500
河南 +8613010761500或008613010761500
江西 +8613010720500或008613010720500
遼寧 +8613010240500或008613010240500
下面是Fans們收集的台灣的短消息中心
中華電信
+886932400851
09288XXXXX : +886932400882
09379XXXXX : +886932400841
台灣大哥大
+886935874258
09203XXXXX : +886935874443
0958XXXXXX : +886935074443
泛亞電信
+886931744010
和信
+886938348404(0927開頭門號)
+886938749104(0938\"4\"以後)
遠傳電信
+886931000099
東信
+886931413131

Some information about Window Mobile 7

Just found some news about window mobile 7. Look good.

http://microsoft.blognewschannel.com/archives/2008/01/06/exclusive-windows-mobile-7-to-focus-on-touch-and-motion-gestures/          

 

Osspedia.com - Your Open Source Software Encyclopedia

Osspedia.com is a very useful site for finding open source software. In fact, it is a wiki based web site. You can also add more open source project information into the web site.

 

http://www.osspedia.com

 

Java秘史：隱藏在SWT/Swing背後的故事

本文來自straight_talking_java@yahoogroups.com討論組: http://tech.groups.yahoo.com/group/straight_talking_java/messages/24236?xm=1&m=e&l=1

　　要想弄清楚為什麼Java GUI API被弄得如此混亂，要從幾年前隻存在AWT的時候說起。SUN當時已經建立了一套基本的可移植控件類，這些類映射到不同作業系統上的原生窗口元件（native widget），顯然下一步應該繼續增強這套模型，除了初始的CUA 92元件（文字、按鈕等等），再繼續加上表格、樹、記事本、滑塊等等……當時的AWT還滿是漏洞，遠不能稱為可靠，還需要SUN的coder們去修補。SUN的developer們如Graham和Otto總是習慣於公開把他們的bug歸咎為作業系統的差異，比如"Windows和OS/2的焦點次序不同"或者"在……之間Ctrl-X的行為不一樣"，以及其他蒼白的託辭，好讓批評的火力從SUN太早釋出代碼這個問題的真相上移開。然後Amy Fowler來到了SUN。不是我大男子主義，Amy是個聰明的美女，大多數獃頭呆腦隻懂技術的開發人員都要被她捏在手裏。 Amy來自一家Smalltalk公司，叫做Objectshare，在那裏她負責搞UI類庫。

 

　　跟Java相比Smalltalk的歷史有些悲慘，曾幾何時有3家龐大的Smalltalk公司－－IBM、Parc-Place和Digitalk。在90年代初期3家公司的市場份額大致相等，生活是美好的。Parc-Place採用倣窗口部件（emulated widgets）的設計（即Swing的設計），IBM和Digitalk則採用原生窗口部件（native widgets）。後來IBM壓倒了另外兩家，因此他們打算合併成一家，假設叫做Parc-Place Digitalk。隨後當他們試圖將他們的產品融合到一個叫做Jigsaw的計劃中時爆發了一場大戰，計劃由於政治原因失敗了（開發人員實際上已經能讓它運轉起來），就因為原生和倣造兩派的死戰。

 

　　Amy贏得了精神上的勝利，不過在IBM我們贏得了他們所有的生意，因為這兩家公司在一整年裏除了吵架什麼都沒做。當塵埃落定之後PPD（Parc-Place Digitalk當時已改名為Objectshare，跟Windscale改名為Sellafield的原因相同－－讓人們淡忘之前發生的災難）的股票價格從60美元掉到了低於1美元1股。他們因為偽報收入被NASDAQ摘牌，從此消失。此時SUN正走上與PPD類似的技術方向，於是PDD的技術人員都把他們的簡歷投到了SUN。Amy被僱傭了，她承諾透過輕量級方案解決所有窗口元件的問題，因此說服SUN管理層讓她當了GUI開發部門的頭頭。她是拿著"這裡原來的人都搞砸了，我是來解決的"的鑰匙進來的。隨後Amy僱傭了所有她過去在Parc-Place的舊朋友，讓他們來開發Swing。

 

　　顯然Swing應該做的是僅僅成為一個繪制框架，給那些希望創建地圖軟體或者繪圖軟體的人們使用，無論如何，應該圍繞AWT類庫來建造它，按鈕之類的東西仍然交給AWT來管。SUN的人比如Philip和Mark已經讓AWT能夠處理表格、樹和記事本（notebook，？），所以Swing的方向應該說很明顯了。但那些毀了PDD的人不幹，他們非要把一切都弄成輕量級的。由於SUN管理層的無知，再加上Amy無情的政治手段，造成了我們今天所見的混亂局面。Amy還使SUN相信Swing是作為Mozilla項目的一部分與Netscape聯合開發的，事實上這只是她的宣傳伎倆。

 

　　在IBM，我們從第一天起就憎惡Swing。龐大、滿是錯誤，而且難看至極。原先我們的工具如VisualAge for Java都是用Smalltalk（用的是原生窗口元件）寫的，所以當我們將這些工具向Java代碼庫遷移時，我們需要一套窗口元件。IBM這邊的開發人員都是原來搞Smalltalk的那一批人，我們對管理層要求用Swing來構建WebSphere Studio工具都非常不情願。Swing是個可怕的充滿缺陷的怪獸。

 

　　在WebSphere Studio最初的預視中，當與Microsoft Visual Studio作對比演示的時候，我們所有的用戶都討厭它，就因為它的外觀，而不管它的功能有多強。大多數消費者都不會買一輛讓人覺得難看的車，哪怕這車有一台出色的引擎。因此我們開始了一個項目，是把我們的Smalltalk原生窗口元件移植到Java上去。這個項目是加拿大的Object Technology International小組做的。這個項目穫得了成功，被運用在在我們發佈的VisualAge Micro Edition產品中，VisualAge Micro Edition後來成為J2ME開發方面一個非常成功的IDE。但是OTI的人發現，Swing在讀取Windows事件方面有極嚴重的缺陷，我們甚至無法進行SWT（S開始是Simple的縮寫，不過後來變成了Standard的縮寫）和Swing間的互操作。他們在讀事件佇列的時候用了一種可能留下記憶體漏洞的方式，所以我們不得不採用我們自己的查詢Windows事件佇列的循環，以糾正這個錯誤。

 

　　我們試了一次又一次讓SUN修復這個錯誤，但Amy就是聽不進去，所以我們才決定SWT和AWT/Swing不能共存。我們甚至在SWT中定義了自己的Point和Rectangle類－－整個工具包對AWT或Swing都沒有任何依賴。我們把這個工具包放到了Eclipse中，這是一個工具平台，它的總體設計目標就是要戰勝Micrsoft和Visual Studio。Eclipse是開源的，所以任何人都可以在上面構建自己的東西，我們已經有像TogetherSoft和Rational這樣的公司移植到了上面。我們的競爭者是Microsoft，所以我們所有努力和注意力都是從正面針對Microsoft。

 

　　不管怎麼說SUN對此非常不滿。他們的Netbeans跟Eclipse做的是相同的事，因此他們向IBM高層抱怨。他們認為SWT是要將你綁到Windows上，這純粹是胡說，因為SWT能透過GTK在Mac/Linux上運行，以及一大堆嵌入式平台。他們拒絕讓Eclipse穫得Java認證，因為裏面有原生代碼，所以Eclipse產品必須很小心地使用單詞"Java"這個SUN的商標。Eclipse甚至不能把自己稱為一個Java IDE，SUN已經威脅過要采取法律行動來制止IBM在任何時候把Eclipse稱作一個Java IDE。結果之一就是IBM在Eclipse上創建的GUI設計工具，允許你構建Swing/AWT GUI，卻不讓你往裏面拖放SWT窗口控件。

 

　　將SWT從Eclipse中分離出來是完全可能的，只需要把DLL摳出來放到路徑中，並使用窗口元件工具包來給你的銀行或者保險或者其他什麼應用程式開發GUI。再次說明，我們無法更進一步，因為SUN把我們的雙手綁上了。雖然作為Eclipse開放源碼協議的一部分，CPL允許我們提供這樣的解決方案，但SUN已經很清楚地表明他們不希望我們這樣做。 對於用戶社區來說，無論IBM和SUN的最終動機是什麼，我發現有一點總是很有趣：喜愛Swing的人總會說"一旦你花上幾年時間去掌握它，你就能正確地使用它"，這基本上是他們在試圖證明和維護他們辛苦得來的用途有限的專門技術；而SWT的擁護者們說的是"哇，這真快，這跟原生的一樣，還可以用XP皮膚……它還又輕又小"。有一句話是我喜歡的，我們的一個用戶說，Swing就像Java決定不透過作業系統來實現原生的IO，而是透過磁頭馬達API自己來讀磁碟的扇區。Swing基本上就是這樣的，它拿著個底層的"paint(Graphics)"方法，自己來繪制所有的窗口元件。

 

另一Amy Fowler的interview:

http://java.sys-con.com/read/44701_p.htm

 

 

Opensource WPF application

http://channel9.msdn.com/showpost.aspx?postid=309873

 

 

Why need WPF

A good presentation about why Microsoft design WPF

http://channel9.msdn.com/showpost.aspx?postid=185468           

 

Anders Hejlsberg的人生信念:

Anders Hejlsberg的人生信念:

如果你对该问题不具有发言权，也没办法推进其解决进程，那么最好保持沉默和中立，而不应该摆出一个非此即彼的架势。

 

我十分認同.

 

 

Rounding Dilemma in Two-Dimension Situation

Please consider following example:

Before Rounding:
	Jan	Feb	Cum
Item 1	12.534145	8.126270	20.660415
Item 2	14.004458	7.119500	21.123958
Total	26.538603	15.245770	41.784373
Rounded Version
	Jan	Feb	Cum
Item 1	12.53	8.13	20.66
Plan 2	14.00	7.12	21.12
Total	26.54	15.25	41.78

 

There is no problem in calculation in "Before Rounding" version.

 

However, user may report that some problem on Rounded version. Because 26.54+15.25 <> 41.78

But, if we patch the data become 41.79, then it become another problem since 20.66+21.12<> 41.79

It is a perception dilemma because we did not recognized that all version are rounded values rather than actual values.  

 

May be you may suggest to do rounding before all calculations, however, please aware that cumulative error will become very large, as we have more than 5,000 of item in calculation . 

Let me compare the "error"

Method	Error due to Rounding	Error due to Human Perception
Rounding only on display (Current method)	0.00 (as no rounding in calculation)	0.005
Rounding before calculation	=0.005* 5,000 = 25.00	0.00

 

Conclusion:

The "Rounding Issues" is because of a wrong perception from human rather than system error.