为什么被折叠？
0 个回复被折叠
31 回答
刚好我毕业设计做的就是这个东西，事实上呢，楼上说的很好了，我做一点补充。
以前的刷卡一般都是要和服务器联网的，怕的就是不安全。但是随着技术的发展，把你所谓题目里的钱放在卡上的越来越多了。电子现金，意思就是电子形式的现金，你丢了是没法管的，而且由于电子现金账户有上限，银行也不怕你修改这里面的金额，有哪个本事破解了公钥密码，还干这个干啥。现在成都坐地铁就可以刷蓉城卡了，也挺方便的，希望以后越来越方便吧～
行业相关
城市一卡通平台，公交卡充值，校园卡充值都做过。
文字逻辑不太好，能表达到哪种程度要看你们的理解能力了~_~
先明确一下，题主所说的公交IC卡的钱是存在卡里的，但是一般来说公交后台也会有一个余额作为辅助参考。你们日常乘坐公交、地铁刷卡时都是脱机消费，不需要和公交后台进行交互，脱机消费所产生的交易信息会存在刷卡时的POS机中，这些会定期从POS机采集出来送到公交后台进行清算，清算之后会对公交后台存储的余额进行更新。
公交后台存储余额的意义：例如你的卡里现在有200元，如果卡坏了要换卡或者退卡， 那么读不了卡怎么知道要给你退多少呢， 这时候就需要公交后台存储的这个余额了，但是这个余额是不准确的，有可能后台现在余额是200元，但是你最近几天产生的消费还在POS机里，你的实际余额实际是少于200元的，不过要知道公交公司是不可能会吃亏的，当你的卡坏了去做换卡或者退卡的时候，公交公司会先帮你做个申请，然后通知你几天以后再来，这几天时间就是用来等最近的消费记录送到后台清算，清算完之后发现你的余额已经少于200了，几天过后你来的时候公交公司就会按最新的余额给你换卡移资或者退钱。
--------------
先占个位，以后慢慢补充吧。
有什么问题可以在评论里说，我会尽量解答。
正好让我自己写我也不知道怎么写合适。
第一的答案跟实际情况还是有些出入的，当然大部分是没问题的。
公共交通卡/银行IC卡（仅电子现金）余额在服务器端和卡片端都会记录，但都以服务器端为准。
公共交通卡这类的消费都是脱机消费，即使在可以终端联网的情况下也不会联机，如果是圈存的话是需要联机的。
银行IC卡，如果你开通了闪付的话，卡片端和服务器端还会额外增加一个电子现金余额（类似于公交卡），通过闪付消费一般都是脱机的，如果风险检查没有通过的话会联机交易。
消费会产生交易日志等等，如果每笔交易都要实时上传，服务器是吃不消的，这里服务器要做的事情很多，比如验证余额，交易日志，交易凭证等等，而不仅仅是同步数据。其解决办法就是日终的时候批量上传日志等文件/数据。
校园卡等不了解。
不用联网，不用输密码，查询余额和消费记录就是这么简单 
这种涉及到钱，而且还是大规模用户的卡，我觉得是有个服务器的，毕竟现在的学校卡和校园水卡都做了服务器。 这种卡有几种吧，有接触式非接触式 有IC 和ID卡之分，线圈的和芯片的，数据的真实变动其实都是'会同步到服务器终端的，要不公交卡丢了就不能补办了，另外别人非法盗刷也容易了，卡只是和公交终端通信过程过，让公交终端识别卡以及验证卡是否是合法的卡，再把数据同步到服务器吧
都没说到本质问题上。
国内公交卡，包括北京公交一卡通，采用的是金融IC卡PBOC2.0电子钱包标准。电子钱包是一种用于脱机离线交易环境的IC卡标准，所用的POS机具和闸机机具是离线的，刷卡时不需要连接到服务器后台。因此，公交卡的余额是保存在卡片上的，只有卡片上有准确的余额信息。POS机具每天会有日结批上送，就是每天会把当日所有交易信息上传到服务器，由后台进行对账结算。
关于卡片制式，包括北京在内的主要大城市公交卡，已经不再采用MIFARE卡了，原因是太不安全已经被破解。现在多数已经采用CPU芯片卡，部分甚至已经是JAVA CARD了。
关于电子现金，电子现金可以看作是电子钱包的升级版，电子现金的交易是可以实时连接到后台的，取决于交易策略。目前国内公交除了一小部分城市直接采用银行电子现金卡外，其余都还是电子钱包卡。
钱当然是在银行账户里啦。
读卡器不联网的话，卡里只是一个余额数字，刷卡时读卡器会扣除费用后把新的余额数字回写到卡上。同时读卡器会记录下卡号和余额、费用，回到车站后把数据导入服务器，服务器再更新数据。显然这种方式存在安全隐患，读卡器并不向服务器验证卡里的余额，如果你能破译读卡器的加密算法，就能往卡里任意充值啦。
现在读卡器可以联网了，其实就是加上个无线通信模块，可以与服务器实时通讯。这种情况下，卡里只需存身份信息，余额实时在服务器上更新，安全性更高。
谢邀。我在20年前做过一个IC卡的项目，那个项目中IC卡是可以读写，因此钱是在IC卡中。但是服务器上有数据库，每天做一次同步，就是和食堂的收款机同步。也就是钱，同时在服务器上有备份。发现有异动，会被查到。
不知道现在有没有改进。
太暴露年龄了。
利益相关：前段时间了解过一些射频安全的知识，也想本校网络中心的老师了解过我们学校校园卡的计费机制。
先说结论：计费方式是服务端和校园卡内部存储双轨计费，以服务端信息为准，想必公交卡计费方式应该也差不多。
我们学校的校园卡使用的是普通的IC卡，也就是MIFARE MF1S503x IC卡，
MIFARE datasheet
- 每张卡分为16个Sector，每个Sector分为4个Block，每个Block 16 Byte
- 其中Sector 0 Block 0 也就是每张卡储存信息的最开端是只读区，前四个字节储存的是每张卡的唯一标识符，即UID信息，全球唯一（约定要求），第五个字节存储的是UID的CRC验证值，后面十一个字节存储的是生产厂商信息。这就是卡的标识信息。
- 每个Sector 的Block 3存储是每个Sector的访问密钥，读卡器需要通过正确的密钥来读写相关扇区（Block）的内容，密钥的长度为6 Byte，且每个扇区有两个密钥A和B，密钥的组合方式有(2^48)种可能。而余额等信息就是存储在某个扇区中。
- 每个读卡器都缓存了有效校园卡的UID和个人学号的对应列表，读卡时首先匹配获得与UID匹配的学生学号，防止有人拿着挂失卡消费。每次同步时更新UID列表
- 如果读卡器离线：读卡器通过内置密钥读取校园卡相关扇区获取余额，进行扣费等操作，且在本地缓存消费记录，待上线后上传某饭卡消费记录。
- 如果读卡器在线：根据校园卡UID从缓存列表获取个人学号，以此查询服务器获取服务端饭卡余额，扣费后进行同步。
