各种磁卡是怎样记录信息和内容

磁卡的ISO标准:
   磁卡,特别是应用于银行系统的磁卡的一些ISO 标准分别为:ISO7810,ISO7811-1 至ISO7811-6,ISO7812,ISO7813 以及ISO15457 等等。其中:
  ISO7810 标准:制定了磁卡的物理特性等;
 ISO7812 标准:制定了磁卡的记录技术标准;
 ISO781-4 标准:制定了磁卡上只读的Track1 和Track2 的记录技术标准;
 ISO781-5 标准:制定了磁卡上可读/写的Track3 的记录技术标准;
  ISO15457 标准:制订了磁卡物理标准/测试方式Track 标准F/2F 技术标准;
磁卡的物理结构及数据结构:

    一般而言,应用于银行系统的磁卡上的磁带有3 个磁道,分别为Track1,Track2 及Track3。每个Track都记录着不同的信息,这些信息有着不同的应用。此外,也有一些应用系统的磁卡只使用了两个磁道(Track),甚至只有一个Track。在我们所设计的应用系统中,根据具体情况,可以使用全部的三个Track或是二个或一个Track。
如上图所示是符合ANSI 及ISO/IEC 标准的磁卡的物理尺寸定义。这些尺寸的定义涉及磁卡读写机具的标准化。因为如果您对磁卡上Track1(或Track2 或Track3)进行数据编码时,其数据在磁带上的物理位置偏高或偏低了哪怕几个毫米,则这些已编码的数据信息偏移到了另外的Track 上了。其中:  Track1,2,3 的每个磁道宽度相同,大约在2.80mm(0.11 英寸)左右,用于存放用户的数据信息;相邻两个Track 约有0.05mm (0.02 英寸)的间隙(Gap),用于区分相邻的两个磁道;整个磁带宽度在10.29毫米(0.405)左右(如果是应用3 个Track 的磁卡),或是在6.35 毫米(0.25 英寸)左右(如果是应用2 个Track 的磁卡)。实际上我们所接触看到的银行磁卡上的磁带宽度会加宽1~2mm 左右,磁带总宽度在12~13mm 之间。
 在磁带上,记录3 个有效磁道数据的起始数据位置和终结数据位置不是在磁带的边缘,而是在磁带边缘向内缩减约7.44mm(0.293 英寸时)为起始数据位置(引导0 区);在磁带边缘向内缩减约6.93mm(0.273英寸)为终止数据位置(尾随0 区);这些标准是为了有效保护磁卡上的数据不易被丢失。因为磁卡边缘上的磁记录数据很容易因物理磨损而被破坏。
磁道Track 上的标准定义:
磁道Track 的应用分配一般是根据特殊的使用要求而定制的,比如银行系统、证券系统、门禁控制系统、身份识别系统、驾驶员驾驶执照管理系统等等,都会对磁卡上的磁卡上的3 个Track 提出不同的应用格式要求提出不同的应用格式要求。在此,我们将主要研讨的是符合国际流通的银行/财政应用系统的银行磁卡上的3 个Track 的标准定义,这些定义也已经广泛适用于Visa 信用卡、MasterCard 信用卡等我们常用的一些银行卡。
    磁道Track1:它的数据标准制定最初是由“国际航空运输协会”IATA(International Air Transportation Association)完成的。Track1 上的数据和字母记录了航空运输中的自动化信息,例如货物标签信息、交易信息、机票定票/定座情况,等等。这些信息由专门的磁卡读写机具进行数据读写处理,并且在航空公司中有一套应用系统为此服务。应用系统包含了一个数据库,所有这些磁卡的数据信息都可以在此找到记录。
    磁道Track2:它的数据标准制定最初是由“美国银行家协会”ABA(American Bankers Association)完成的。该磁道上的信息已经被当今很多的银行系统所采用。它包含了一些最基本的相关信息,例如卡的惟一识别号码、卡的有效期等。
    磁道Track3:它的数据标准制定最初是由财政行业(THRIFT)完成的。其主要应用于一般的储蓄、货款和信用单位等那些需要经常对磁卡数据进行更改、重写的场合。典型的应用包括现金售货机、预付费卡(系统)、借贷卡(系统)等等。这一类的应用很多都是处于“脱机"(off line)的模式,即银行(验证)系统很难实时对磁卡上的数据进行跟踪,表现为用户卡上磁道上Track3 的数据与银行(验证)系统所记录的当前数据不同。
    磁道(Track1,Track2,Track3)上允许使用的数字和字符:
    磁卡上的3 个Track 一般都是使用“位”(bit)方式来编码的。根据数据所在的Track 不同,5 个bit或7 个bit 组成一个字节。Track1(IATA):记录密度为210BPI;可以记录0~9 数字及A~Z 字母等;总共可以记录多达79 个数字或字符(包含起始结束符和校验符);每个字符(一个字节)由7 个bit 组成。
    Track1 上的信息不仅可以用数字0~9 来表示,还能用字母A~Z 来表示信息,因此Track1 上信息一般记录了磁卡的使用类型、范围等一些“标记”性、“说明”性的信息。例如银行用卡中,Track1 记录了用户的姓名,卡的有效使用期限以及其他的一些“标记”信息。
    Track2(ABA):记录密度为75BPI;可以记录0~9 数字,不能记录A~Z 字符;总共可以记录多达40个数字(包含起始结束符和校验符);每个数据(一个字节)由5 个bit 组成。
    Track3(THRIFT):记录密度为210BPI;可以记录0~9 数字,不能记录A~Z 字母;总共可以记录多达107 个数字或字符(包含起始结束符和校验符);每个字符(一个字节)由5 个bit 组成。
    由于Track2 和3 上的信息只能用数字0~9 等来表示,不能用字母A~Z 来表示信息,因此在银行用卡中,Track2,3 一般用以记录用户的帐户信息、款项信息等等,当然还有一些银行所要求的特殊信息等。
    在实际的应用开发中,如果我们希望在Track2 或3 中表示数字以外的信息,例如“ABC”等,一般应采用按照国际标准的ASCII 表来映射。例如,要记录字母“A”在Track2 或3 上时,则可以用“A”的ASCII值“0x41”来表示。“0x41”可以在Track2 或是Track3 中用两个数据来表示:“4”和“1”,即“0101”和“0001”。
时间: 2024-11-09 11:48:04

各种磁卡是怎样记录信息和内容的相关文章

使用文档对象在页面上创建学生信息表。 信息表包括学号、姓名、性别、电子邮件、联系电话、个人主页和联系地址, 信息表内容通过表单输入,提交前先使用正则表达式进行验证,联系地址不能超过20个字符, 每输入一名学生的信息,提交后,表格增加一行,表格不能被选择、复制。

<!DOCTYPE html><html>    <head>        <meta charset="UTF-8">        <title></title>    </head>    <!--        描述:使用文档对象在页面上创建学生信息表.        信息表包括学号.姓名.性别.电子邮件.联系电话.个人主页和联系地址,        信息表内容通过表单输入,提交前先使用

EWS API 2.0读取日历信息-读取内容注意事项

[from] http://www.cnblogs.com/love007/archive/2013/06/26/3156852.html 采用模拟账号的方式读取日历信息,注意下日历的内容读取(Body)读取.代码如下:(采用 EWS API 2.0版本) 1.读取内容前必须设置如下属性:否则会提示:You must load or assign this property before you can read its value  Body 如下: //*******************

如何进行SCCM中客户端记录信息维护

SCCM 部署完毕之后,不久我们就会发现客户端代理状态,因为重装系统,非正常的退域,长时间不开机,导致客户端状态有不可用的,有过期的,重复的记录很多.当然我们可以手动的快速删除重复的记录,那么怎么能做按照企业的要求进行自动删除,且能搞清楚SCCM是怎么去判断执行这个过程呢,根据我在实际环境中的实施,分享给大家. 删除不活动的客户端发现数据: 设置每周五删除90天不活动的客户端,这个设置只是针对已经安装了客户端代理的计算机,那么关于不活动是如何判定,我们下面有说明. 如何判断已经安装客户端的计算机

查看wtmp(登陆信息的内容)

/var/log/wtmp文件的作用 /var/log/wtmp也是一个二进制文件,记录每个用户的登录次数和持续时间等信息. 查看方法: 可以用last命令输出当中内容: debian:/var/log# last  root pts/1 :0.0 Thu Jul 7 23:19 still logged in  root pts/3 :0.0 Thu Jul 7 22:31 still logged in  root pts/3 :0.0 Thu Jul 7 20:17 - 22:24 (02

file_put_contents记录的日志内容丢失

使用函数 file_put_contents()来记录日志,当多人同时操作,记录的日志会莫名其妙的丢失,即并发追加写时,日志会丢失. 经分析,是不正确使用函数 file_put_contents() 造成 int file_put_contents ( string $filename , mixed $data [, int $flags = 0 [, resource $context ]] ) filename :写入的文件名和路径data :写入的数据flags :可选参数,FILE_U

Nginx记录post body内容

nginx在记录http的body内容时,会将中文转义为16进制 在nginx 1.11.8 以上版本中log_format 增加了escape=json 参数,可以不转义变量内容: log_format access escape=json '$request_time $remote_addr "$request" "$request_body" $status "$http_referer" "$http_user_agent&q

日志信息相关内容 一

# 日志的处理 # 1.记录的信息不全面,比如没有记录时间信息.没有执行人信息.日志等级信息.日志详细信息 # 2.文件记录的信息混乱不清,不方便使用脚本统计 # 3.当日志文件大的时候,没有自动进行日志轮转功能 # 引出 日志器 # 日志信息 # 日志收集器(Logger),用来装日志信息 # 日志收集器的日志等级(NOTSET(0).DEBUG(10).INFO(20).WARNING(30).ERROR(40).CRITICAL(50)) # NOTSET(0):无限制,只要是日志信息都可

java提取(获取)博客信息(内容)

package com.wbg.my.service; import java.io.*; import java.net.HttpURLConnection; import java.net.URL; import java.util.*; import java.util.regex.Matcher; import java.util.regex.Pattern; /** * @author Jack Chen * */ public class BlogUtil { /** * URL_P

crm2013开启审核和查看审核记录信息

crm2013开启组织审核 crm2013开启实体审核 crm2013开启字段审核 crm2013查询审核历史记录