Message Validation/Transformation アサーション

ほとんどの HTTP レスポンスと同様、HTTP PUT および POST リクエストには、通常、返されるコンテンツの種類を宣言する Content-Type ヘッダが含まれます。 XML や HTML のようなテキスト ドキュメントの場合は、Content-Type ヘッダに、コンテンツ内の文字がどのように転送用バイトにエンコードされたかを宣言する追加の「エンコーディング」パラメータを含めることができます。 たとえば、XML ドキュメントの最も一般的な Content-Type は次のとおりです。
gateway83
Message Validation/Transformation アサーションは、サービス メッセージに適用された XML 変換および検証スキーマを設定します。
(1) インストールした
Layer7 API Gateway
製品によっては、このカテゴリのアサーションがすべて使用できるとは限りません。 「カプセル化されたアサーション」を参照してください。
文字エンコーディングについて
ほとんどの HTTP レスポンスと同様、HTTP PUT および POST リクエストには、通常、返されるコンテンツの種類を宣言する Content-Type ヘッダが含まれます。 XML や HTML のようなテキスト ドキュメントの場合は、Content-Type ヘッダに、コンテンツ内の文字がどのように転送用バイトにエンコードされたかを宣言する追加の「エンコーディング」パラメータを含めることができます。 たとえば、XML ドキュメントの最も一般的な Content-Type は次のとおりです。
Content-Type: text/xml; charset="utf-8"
Web サーバは、ファイル拡張子に基づいて静的ファイルの Content-Type を推測します。より確かな情報に基づいた推測を行うために、ファイルの最初の数バイトを読み取る場合もあります。 コンテンツの実際のタイプを推定できないため、または不正確に推測したために、コンテンツに一致しない Content-Type ヘッダを持つ HTTP リクエストまたはレスポンスをシステムが送信することもあります。
Evaluate Regular Expression アサーションは、バイトではなく、文字で動作します。したがって、コンテンツに対して正規表現を評価する前に、そのコンテンツをデコードする必要があります。 このアサーションは、コンテンツをデコードするために、最初に使用されたエンコーディング スキームを認識する必要があります。
Content-Type ヘッダが見つからないか、"charset" パラメータがない場合、Gateway は(RFC2616 HyperText Transfer Protocol に従って)コンテンツが ISO8859-1 でエンコードされていると想定します。 7 ビットの文字(つまり、U+0000 と U+007F の間のコード ポイント)が含まれるコンテンツの場合、UTF-8 と ISO8859-1 の両方で同一のバイトがエンコードされるため、このクラスのエラーでは問題が発生しません。 ただし、UTF-16 など、その他のエンコーディングではまだ問題が残っています。
UTF-8 は、世界の言語の大部分で使用されている Unicode 文字を含め、どのような Unicode 文字でもエンコードできます。一方、ISO8859-1 は、これらの文字のサブセットに制限されます(主に、西ヨーロッパ言語に関連するもの)。 ほかにも、さまざまなロケールで使用するために設計された多くの非 Unicode 文字セットがあります。しかし、ISO8859-1 は北アメリカで最も一般的であり、Microsoft Windows のデフォルトになっています。
7 ビットを使用してエンコードできない文字の例を以下に示します(ISO8859-1 では、127 を超える値を持つバイトを使用してこれらの文字をエンコードしますが、UTF-8 では複数のバイトを使用してエンコードします)。
  • スマート クォート(二重引用符とも呼ばれます)
  • エン ダッシュおよびエム ダッシュ(ダッシュやハイフンではありません)
  • 著作権(©)および商標(®、™)記号
  • アクセント記号付きの文字
  • $ 以外の通貨記号
サマリ
想定される(または宣言されている)エンコーディングが ISO8859-1 である場合は、任意のバイトを有効な ISO8859-1 文字にデコードできるため、Evaluate Regular Expression アサーションは文字変換エラーによって失敗しません。 ただし、コンテンツが ISO8859-1 であると想定される(または宣言されている)が、実際には UTF-8 でエンコードされ、非 7 ビット文字が含まれる場合、ドキュメントは警告なしに破損している可能性があります。
この場合、コンテンツを正しくデコードするには、[Override character encoding]フィールドに「UTF-8」を入力します。
一方、コンテンツは UTF-8 でエンコードされていると想定される(または宣言されている)が、実際には 8 ビットの ISO8859-1 文字が含まれる場合、UTF-8 には、偶然に一致する ISO8859-1 シーケンスがほとんどない非 7 ビット文字用に規定された構文があるため、Gateway はデコーディング プロセス中に例外をスローする可能性があり、Evaluate Regular Expression アサーションは失敗します。
この場合、コンテンツを正しくデコードするには、[Override character encoding]フィールドに「ISO8859-1」を入力します。