問題タブ [tlv]

TLV 値を割り当てる必要がある ISO 8583 メッセージの 55 番目のフィールド (予約済み ISO) に値を割り当てる例はありますか?

やあ、私はJpos初心者で、を使用しているフィールドに問題があります。IFA_TTLLLBINARY

しかし、私は常にこのエラーが発生します:

このエラーが表示される理由を教えてください。

Paypass Maestro Mastercard を読み取ろうとしています。そこで、次の SELECT PPSE コマンドを送信します。

次の応答が返されます。

選択が成功すると:SW1SW2=9000

TLV Decoder で応答をデコードしようとすると、次のようになります。

不明なタグ 9F2A を含むこの結果をどのように解釈すればよいかわかりません。Maestro カードの AID はどうでしょうか。検索したところ、次のことがわかりました。

誰かがこの問題を解決するのを手伝ってくれますか?

非接触型デビット/クレジット カードからカード番号と有効期限を取得することに成功しました。ただし、READ RECORD コマンドの応答でカード所有者名が返されません。何か不足していますか？

M/Chip Select 4 バージョン 1.1a で MasterCard EMV カードのプロファイルを作成していますが、9F7E (アプリケーション ライフ サイクル データ)タグ値のデータ要素を理解するための助けが必要です。残念ながら、MasterCard のマニュアルでは、このタグの目的や対応するデータ要素について十分に説明されていません。

マニュアルから、最初のバイトがバージョン番号用であることを理解しています-簡単です。ただし、残りの 47 バイトは、「型式承認 ID」、「アプリケーション発行者 ID」、「アプリケーション コード ID」など、私がよく知らないデータ要素を表しています。

これらのデータ値は取引処理中に生成されたものですか、それともカードに常駐する静的な値ですか?

さまざまな EMV TLV から値を問い合わせるコードがあります。ただし、PED シリアル番号の場合、 http ://www.emvlab.org/emvtags/ のタグ「9F1E」の仕様には次のように記載されています。

名前 説明 ソース フォーマット テンプレート タグの長さ P/C インターフェイス デバイス (IFD) のシリアル番号 製造元によって IFD に割り当てられた一意かつ永続的なシリアル番号 端末 8 9F1E 8 プリミティブ

しかし、上記の制限は 8 ですが、VeriFone PED には 9 つの長い SN があります。

そのため、タグ「9F1E」に依存するサンプル コードでは、完全な長さを取得できません。

上記の GetTLV() は、タグ arg を受け取り、その値を char 配列に入力するように記述されています。

完全な 9 を取得する良い方法を見つけた開発者はいますか?

データを転送するために Web ソケットを利用するサービスがあります。

ツリー構造をエンコードし、そのツリー構造を websocket 経由で転送する方法が必要です。TLV およびサブ TLV エンコーディングについて読んだことがありますが、これは素晴らしいアイデアのようです。つまり、Radius や LLDP などのプロトコルですでに使用されており、これが機能していることを証明していますが、私の問題は、これらのプロトコルが通常、信頼できるデバイス、つまりスイッチ/ルーター間 (LLDP を除く)。私の問題は、ランダムなサイズ/長さを持ち、静的に定義された構造を持たないサブ TLV を含む TLV を転送することです。サブ TLV が定義されている、つまり

Extended IS Reachability TLV #22 の場合、この tlv には次のような構造があることがわかります。

構造上、7 バイトのネイバー ID、3 バイトの Metric 、1 バイトの SubTLVs Length が事前定義されており、変数部分が来るだけですが、少なくとも高度に定義されていて変更できないビットがいくつかあることを意味します。

今、いくつかの本を読んで（主にH Gredler The Complete IS-IS Routing Protocol 2005 - page 296）、これらのTLVを検証する4つの手法を見つけました。

1) 最大長チェック

2) サブ TLV オーバーラン チェック

3) 離散長チェック

4) TLVコンテンツのパターンチェック

ユーザーからの情報はまったく信用できませんが、他に 2 つの問題があります。つまり、値が a) ランダムな長さ/サイズである TLV を検証する方法です。つまり、値が持つことができる範囲があります。つまり、1 バイト以上です。 700 kb 以下であり、b) その値は暗号化されているため、つまり読み取り可能な形式ではないため、その値に対してパターン チェックを実行できず、パターンを実行できません。

したがって、私の質問は次のとおりです。同じ目標を達成するにはどうすればよいですか。つまり、ツリー構造を他の構造内に送信することです。つまり、キーと値のペアまたは同様のものを送信することです (http はこれを使用していますが、それには理由があるはずです)。

ツリー構造でデータを転送するには、TLV の方法が本当に最適な方法でしょうか。それをバイナリ形式で送信すると、1発で2匹のウサギを攻撃できます。つまり、写真などのファイルを送信するときに、面白いbase64エンコーディングなどを使用する必要はありませんが、本当に欲しいのは、動作するプロトコルですL5-7 (つまり、websocket 経由) を使用すると、シリアル化と逆シリアル化の部分について考える必要なく、受信部分がツリーを識別して再構築できるツリー構造の形式でデータを送信できます。では、TLV の 2 番目に優れた代替手段は何でしょうか?一方の側で Java を使用し、もう一方の側で javasctipt を使用していることを考慮してください。