16、在類型定義和信息對象集中使用擴展標記有什么區(qū)別？擴展標記是否不可見？

擴展標記就類型定義而言是不可見的，但就簡單表約束和組件關系約束而言并非不可見。

類型本身是可擴展的，與限制它是可擴展的對象集之間是有區(qū)別的。在類型是可擴展的情況下，它天生可以采用可擴展約束允許的任何值。例如，

INTEGER(1..8, ...)

可以隨時假設任何有效值。將此與使用簡單表約束進行約束的 INTEGER類型進行對比，在這種類型中，此類類型只能假定在該類型被編碼/解碼時恰好包含在信息對象集中的那些值。隨著程序的運行，這可能會隨著時間的推移而變化，因為可擴展信息對象集中的對象集可能會在運行時發(fā)生變化。

在BER、DER和 CER的情況下，這種區(qū)別不太重要，其中類型的可擴展性在其編碼方式中不發(fā)揮作用，但在PER 中起主要作用。在 PER 中，使用擴展標記“...”定義的類型的值使用1 位前綴進行編碼，當設置為0 時，意味著后面的值在擴展根中，因此以優(yōu)化的形式編碼。（例如，上面示例中的值 1-8 將被編碼為3 位）。但是，當設置為 1 時，意味著后面的值以更通用的形式編碼。（例如，上例中不在 1-8 范圍內(nèi)的值占用16 位或更多位）。

17、你能解釋一下類型可擴展性在PER 中是如何工作的嗎？

考慮以下兩個ASN.1 語法定義：

A::= SEQUENCE { --defined in v1

f1BOOLEAN,

f2BOOLEAN,

...,

}

A::= SEQUENCE { --defined in v2

f1BOOLEAN,

f2BOOLEAN,

...,

e1BOOLEAN OPTIONAL,

e2BOOLEAN

}

類型可擴展性背后的目的是允許不理解新字段的V1 應用程序接收具有它無法識別的字段的V2 消息，并將它們視為由V1 應用程序發(fā)送，同樣，對于V2 應用程序來說接收缺少字段的 V1 消息。如果 V2 應用程序收到缺少強制擴展添加的消息，它可以安全地假定該消息是由V1 應用程序發(fā)起的。

只有在擴展附加位圖中有一個位表示存在/不存在哪些擴展附加值時，才必須對擴展標記之后的強制字段進行編碼。因此，在強制擴展附加 y 之后定義了擴展附加x，并且 x的值存在于編碼中，那么y 的值必須存在。此外，如果強制擴展附加 y 是SEQUENCE 中的最后一個組件，并且在擴展附加位圖中存在一個位，則該位必須設置為1，因為該位的存在表明消息的發(fā)起者知道這個擴展添加，因此它的存在是強制性的。只有當消息是從未定義強制擴展添加的早期版本的消息定義中繼時，才可以省略它（在這種情況下，擴展添加位圖中將沒有位）。ITU-T 建議X.680(2008) 25.15 注2 中指出了這一點：

作為擴展添加但不包含在“ExtensionAdditionGroup”中的“ComponentType”如果未標記為OPTIONAL 或DEFAULT，則應始終對其進行編碼，除非抽象值是從使用較早版本抽象語法的發(fā)送者中繼的其中未定義“ComponentType”。

換句話說，PER將標記為 OPTIONAL的擴展添加與非 OPTIONAL的擴展添加完全相同。

審核編輯：劉清