我很無聊，並通過PCSC閱讀器將所有INS代碼嘗試到我的SIM卡。SIM/Javacard - 無法發送INS 69或96
我有一個奇怪的行爲 - 當我使用CLA 80和INS 69或96我在我的程序中得到一個異常。
我知道INS 6X和9X是無效的，但只有這兩個值（69和96）我每次都會遇到異常。
有人可以解釋我爲什麼嗎？
感謝傭工:)
順便說一句 - 我試了一下使用smartcard.scard（蟒蛇），SCARD（C++）和smartcardio（JAVA）。
CLI值6X和9X無效的原因是T=0協議工作的方式。從ISO 7816-3
摘錄：
接口設備通過發送一個五字節的頭，告訴卡做什麼發起的每一個命令。
... ...跳過
該頭由表示CLA，INS，P1，P2和P3五個字節。 CLA，INS，P1和P2的值應符合ISO/IEC 7816-4中的規定。
CLA表示一類命令。值'FF'無效 （保留給PPSS，見6.3.1和9.2）。
注意：ISO/IEC 7816-4強制執行 'FF'作爲CLA的無效值。
INS表示指令碼。 值'6X'和'9X'是無效的。
注意：ISO/IEC 7816-4強制'6X' 和'9X'作爲INS的無效值。
P1 P2表示指令 參數，例如完成指令代碼的參考。
P3 編碼在命令期間要被傳送的數據字節D1到Dn的數目 。
在傳出的數據傳輸命令時，P3 = '00' 介紹從卡256字節的數據傳送。
在傳入的 數據傳輸命令中，P3 = '00'不引入數據傳輸。
發送所述標頭，如五個字符的字符串後，接口設備必須等待傳送過程字節的字符 。有三種類型的過程字節，見表11
如果 值是「60」，它是一個空字節。它請求對數據 轉移不採取任何行動。接口設備應等待一個字符傳送一個 過程字節。
如果該值是'6X'或'9X'，除了'60'，它的 是一個SW1字節。它要求不對數據傳輸採取行動。接口 設備應等待傳送SW2字節的字符。 SW2值沒有 限制。
注：ISO/IEC 7816-4強制執行'60'爲 SW1的無效值，以及與'9X'和 '6X'不同的任何值。
如果該值是INS的值，除了值'6X' 和'9X'，它是一個ACK字節。如果任何字節 保留的所有剩餘數據字節，表示爲Di至Dn，則應隨後轉移。然後接口設備將等待一個字符傳送一個程序 字節。
如果該值是異或 INS，值「FF」距值「6X」和「9X」的，它是一個ACK字節。只有存在的下一個數據字節，表示爲Di，纔會被傳送。然後接口設備將等待一個字符傳送一個程序 字節。
其他任何值都是無效的。
在每個過程字節，該卡可以通過NULL或ACK與命令進行，或通過 SW1 SW2完成命令，或者顯示由不響應（WT將被超過）其不滿。
狀態字節SW1 SW2指示在命令結束時的卡狀態。它們的值應爲ISO/IEC 7816-4中規定的 。
換言之 - 的9X和6X的INS值被禁止作爲它們的ACK字節（直接或互補/異或變體）不能從SW1在過程字節進行區分。
我承認這並不能解釋爲什麼你只爲69/96特別INS值，而不是爲其他6X/9X的人越來越例外。這是未定義的行爲。
希望這篇文章對你有用...祝你好運！
這可能是因爲'T = 0'協議，其中這些字節的使用，見ISO 7816-3 ... – vlp
@vlp就像我提到我知道，6倍和9倍無效。但只爲那些2我得到一個執行。 – Bluestar
（假設你得到一些有意義的狀態字爲其他INS價值觀 - 你沒寫）：如果我記得很清楚，那是因爲當卡相呼應的INS/INS〜的T = 0協議時的瞬間或用6XXX/9XXX狀態字進行響應。由於這兩個不能區分6X/9X INS是禁止的。同樣的情況應該是'60'的INS，其中這個值用於時間延長。 （我會寫一個答案，但我比較忙學習ISO 7816-3現在......我很抱歉） – vlp