北京华网天下

苹果 Pay 2 月 18 日正式登陆中国，你准备好了吗？

2024-05-29

来源：网络整理

Pay将于2月18日正式登陆中国，苹果终于要用Pay来取代中国消费者的钱包了。

1. 设备要求

Pay 支持线上线下支付，线下支付可使用 iPad、iPad Mini 3、iPad Mini 4、iPad Pro，线上支付可使用 iPad 6s、iPad 6s Plus、iPad Air 2、iPad mini 3、iPad mini 4、iPad Pro。

2. 系统要求

根据此前消息，用户很可能需要将系统升级到iOS9.2或者iOS9.2以上的最新官方版本才能使用 Pay。

3.绑定银行卡

Pay正式上线后，用户只需在账户中添加一张卡即可开始使用Pay，如果用户想添加另一张卡，只需用相机拍照即可。

待Pay正式进入中国后，IT之家将会分享具体的银行卡绑定方式，敬请期待。

绑定银行卡后，即可使用Pay支付。

4. 开始付款

Pay网上支付可以通过指纹验证，不需要输入信用卡信息和地址等，至于是否需要密码，可能取决于发卡银行和商户。

Pay离线支付利用的是设备内置的NFC技术，当你在有银联云闪付POS机的商户消费时，只需将手机背面靠近支付设备即可完成支付，此前没有相关硬件的机型，都无法通过手表完成支付。

结账的时候，如果您看到以下两个图标之一，则可以使用Pay进行付款。

说是将系统时间改为1970/1/1，重启后系统将永远无法开机。

为了真正理解这个错误，你可能需要以下知识。

UNIX 时间戳

在确认这件事情的真实性之前，你需要知道的一件事就是Unix时间戳。

iOS 系统时间以 Unix 时间戳（Unix ）（数据类型）表示，在系统中，系统采用二进制数字来存储时间。

Unix时间戳规定UTC时区1970年1月1日0时0分0秒的值为0，以秒为单位，即每过一秒二进制数加1。

如果您想了解有关 Unix 时间戳的更多信息，请转到 Unix 时间。

如果我无法将其向前调整，那么我就会将时间向后调整。

有好奇的朋友拿出手机，心想：既然回不去，那尝试把时间往后调，又能怎样呢？

细心的朋友发现一个问题，iOS系统可以设置的最大时间为2038年1月1日，不能设置更晚，苹果肯定考虑到了这个问题，为什么这么说呢？

我们以 32 位系统为例，在 32 位系统中，它是一个有符号整数（int）类型，长度为 32 位。第一位二进制位为符号位，用于存储正负数。正数为 1970-1-1 以后的时间，负数则相反；其余 31 位用于计数。当时间到达 2038-01-19 3 时 14 分 08 秒时，所有数值位都前进 1 位，导致符号位被设置为 1，其余 31 位为 0。此时就会发生“时间倒退”，系统时间变成 1901-12-13 20 时 45 分 52 秒，系统出现错误。

所以为了避免这个问题导致的错误，将最大时间限制设定在2038年1月1日23点59分59秒，这样就算超出这个范围，18天之内也不会有太大的问题，到时候32位设备基本就被淘汰了。

那么64位系统会受此影响吗？通过计算我们可以发现，292,277,026,596年12月4日 15:30:08 是64位系统能够表示的最大时间。

64 位处理器的“时间回归”问题

有了刚才的知识储备，我们回到正题，开始讨论搭载64位处理器的设备的时间bug。

我们提到过，UTC 时区是以 1970 年 1 月 1 日 0 时 0 分 0 秒为界，值为 0。时间正常流逝为正，负数为负。不过需要注意的是，时间是受时区影响的。

假设我原本是在北京时区，并且把时间设置为1970年1月1日0点0分0秒，那么我把这个时间换算成UTC时间，公式：北京时间=GMT+8=UTC+8，那么UTC时间就是1969年12月31日16点0分0秒。这样就会出现负的时间值，也就是触发了时间回归的Bug，系统启动就卡在了那个阶段，时间不对，启动无法继续。

触发漏洞的条件和表现形式

当满足以下条件时，会触发“时间回归”错误：

系统版本：iOS8.0~iOS9.3 beta 3

硬件设备：搭载64位处理器的设备（即处理器从A7到A9X的设备）

进入“设置”-“通用”-“时间和日期”，关闭“自动设置”，将时间改为1970年1月1日，任意分或秒。

修改时间后需要重启设备。

Bug触发表现：iOS设备启动时，卡在 Logo上，无法继续启动。

解决方案

▼适用于所有配备 64 位处理器的 iOS 设备

拆开设备并取出电池，静置 10 分钟，然后重新安装。

如果电池充满电，请等待几个小时，当Unix时间戳的值大于或等于0时，系统时间生效，计算机即可正常启动。

▼越狱设备防范