Excel Match() 函数的通配特性

今天遇到一个奇怪的情况,在使用形如:

=Match(A2,A:A,0)

的 Excel 公式查找时,居然返回了 #N/A 的结果。逻辑上来说,在自己所在的数组里查找自己,不应该得到错误结果,事实上这个公式的值只可能是 1 或者 2 才对。

经过检查,发现问题出在字符 ~ (波浪号)上,即键盘上 ESC 键的下方,数字 1 的左边那个键的 Shift 上档符号。

Excel 官方帮助文档 中,找到了相关的解释。

如果 match_type 为 0 且 lookup_value 为文本字符串,您可在 lookup_value 参数中使用通配符 – 问号 (?) 和星号 (*) 。问号匹配任意单个字符;星号匹配任意一串字符。如果要查找实际的问号或星号,请在字符前键入波形符 (~)。

这里提到了,当使用 Match() 函数进行精确的文本查找时可以使用通配符 ? 和 *,当用户确实需要查找问号/星号时,则可以用 ~? 和 ~* 来表示。这里没有提到的是,如果用户需要查找 ~,其实也需要通过两个波浪号 ~~ 来表示。转义符自身也需要转义表达,也算是一般规则了。

所以,如果一个单元格中包含了波浪号 ~,则当这个单元格作为被查找的数据的一部分时,是正常的。但当它同时作为 lookup_value 时,则会在转义后变得无实际意义。于是导致了 Match() 函数查找自身所在数组时产生的错误结果。

遇到这个问题时,我正在处理由家用下载机长年积累下的大量动画片资源。用 Bash 获得所有的动画目录名、文件名,并试图尽量删减一些重复资源。文件名系统中并不存在『 ? * : < > | / \ ” 』等符号,但偏偏允许波浪号 ~ 的存在。又因为在 Excel 的默认字体中,波浪号并不显示为扭曲的波浪形状,而是略长的横线,如图,于如是尴尬便发生了。

解决办法:

给 lookup_value 添加一个 SUBSTITUTE() 函数进行修正,即:

即可得到期望结果。

一句话总结:

当 match_type 为 0 且 lookup_value 为文本字符串时,使用 =Match() 函数时需要注意 lookup_value 是否包含 ~ 、?、* 并根据需要预先做处理。

Ikaruga 评测

★ Ikaruga「斑鸠」 on Steam ★

来,跟我念:

黑机吃黑弹躲白弹打白鸡留黑鸡给白队友遇白光切白机。
白机吃白弹躲黑弹打黑鸡留白鸡给黑队友遇黑光切黑机。

黑白黑白黑白黑黑白白黑黑黑黑白黑白黑白黑白黑白黑黑黑白黑,
变变变变变变变定变定变定定定变变变变变变变变变变定定变变。

黑白黑黑白白白黑白白黑白黑白白黑黑白黑白黑黑黑白白黑黑黑黑黑白白白黑黑黑白黑黑白白黑黑白黑白黑黑黑黑白白白白白白,
变躲吸吸变吸吸躲吸吸躲吸变躲躲吸吸躲吸躲吸吸吸放大招吸吸吸吸变吸吸变吸吸变躲躲吸吸变吸躲吸躲吸吸吸躲变吸吸放大招。

……差不多这个感觉。

Ikaruga 斑鸠

如果说彩京、虫姬、东方是用层层叠叠的华丽弹幕压迫你的灵魂让你手脚冰凉让你奋起反抗让你一世积累尽殁此役,那么斑鸠则是用至简与朴素唤醒你心底的温暖,唤起你对理想与光明世界的向往。

这个世界没有遮天蔽日的弹幕,每一个子弹都可以直接吸收无需躲避,
这个世界没有血条畸长的敌人,即使是关底 Boss 也挡不住几轮蓄能爆发,
这个世界的敌人甚至还会在死去时抛出剩余的能量帮你充能,
这个世界不断地告诉你什么叫理想、试练、信念、现实与轮回。
这个世界总是将光明放在你的眼前,触手可及。

一个完美的世界。

这个世界里里唯一不完美的是你。是屏幕前双手颤抖面目狰狞的你,是竭力紧抓手柄胡乱变色仓皇逃窜的你。但这个世界依然爱着你,从内到外都爱着你。

没有 给你任何 随机出现的敌人,只有约定之时,只有约定之地。
她给了你远超需要的强大技能, 蓄能爆发,让你在瞬间打倒最强大的敌人。
她给了你 异色双倍伤害,给了你 三同色击破链式加分,给了你破敌 残弹 额外蓄能。
她还给了你 竖屏模式,将显示器旋为竖置,世界便扩大八分。
她甚至给了你 单手柄双机模式,让最孤独的你也能与自己一起游戏。
她唯独只是 没有 给你 网络联机 模式,她是完美的,她不需要的,便是不需要的。

你只需要做好一件事,在该变白时变白,该变黑时变黑,你就能回应她的爱,双双走向高潮。

你怎么就做不到呢。

甚至最后的最后,她为了如此不成器的你,把 无限命模式 也给了你。

完美的她,深深地爱着毫不完美的你,爱着什么都做不到的你,爱着靠无限命死乞白赖撒泼打混的你,爱到了最后。

这份爱,只需 36 人民币,打折 18。

守望先锋 1.14 版本后更改了底层数据格式

参考老文章: Overwatch Toolchain 解包方式考察,OW 音频小站一直以来使用原始文件 hash 的办法,便每次更新以后,都能区分旧数据和新增数据,使得每次更新的条目数量都在合理范围。但从版本 1.14 开始,暴雪更新了内部数据格式,这个是由蓝帖明确提到的,目的是减少之后的每次客户端更新时的下载。

但这对本小站来说不亚于一次冲击。这意味着,直到 1.13 版为止的条目,和从 1.17 版开始的所有条目,无法从数据角度建立『新』与『旧』的联系。

也就是说,明明从用户角度来说是同一句台词,音频波形也一致,但由于 OW 内部格式的变化,导致 hash 计算的结果变化,使得从数据角度来说,它们变成了两个不同的条目。

比如: D.VaD.Va 一分,坏蛋零分。(1.17 版本) 的 hash 计算结果是 5908654fbc3965232689836abb249c57,而
D.VaD.Va 一分,坏蛋零分。(1.16 或更早版本) 的 hash 计算结果是 1d99c1739f5b0844f57f3a1a5fbb4580。

我做了很多尝试,试图恢复一些信息,把这些本质相同的音频重新联系起来,有些成功了,有些失败了。最后我把匹配成功部分更新到原有条目上,匹配失败的部分按『新增音频』对待,添加到数据库里。

  1. 尝试使用音频分析软件批量比较,如果成功,理论上这是最好的办法。
    • 这是本质的解决办法,如果两个音频文件的波形完全一致,则两个音频当然是一样的。
    • 尝试了 Audacity 和 Similarity,前者缺乏批量功能,后者无法对这种只有一两秒的音频进行比较,均告失败。
  2. 尝试使用新版本拆解工具拆解旧客户端,失败,但得到了启发。
  3. 因为拆解所用的 Toolchain 工具链(简称 TC)本身有自己的文件名系统,而我亦保留了过去所有版本的原始拆解数据,理论上能通过新旧版本文件的相同路径名等信息恢复联系。
  4. 测试以上两条 D.VA 音频的 TC 路径分别为:
    • 旧(1.13):cn\heroes\D.Va\Sound Dump Full\_Base\000300000057\000000020231.wem
    • 新(1.18):cn\HeroVoice\D.Va\00000000059F.078\000000020231.wem
  5. 测试成功。
  6. 进入实操,发现由于旧版本拆解工具的不完全,数据存在错误,依然有许多坑要填:
    • 一,多个不同的 TC 文件名对应同一个 hash,即多个 1.18 新文件条目对应同一个 1.13 旧条目 hash,错误在旧版拆解工具自带的文件名系统有 bug。
      • 解决办法是视为多个条目,并将旧条目的听写内容更新到各个新条目上。
      • 对于网站用户来说,同一个关键词可能会搜索出几条内容,但其中应该至少有一条是对得上的
    • 二,同一个 TC 文件名对应多个一个 hash,即同一个 1.18 新文件条目对应多条旧的 1.13 旧条目,显然错误还是旧版折解工具的不完善
      • 解决办法只能是人工筛选按多条里面正确的那条。
      • 大约一共有 1200 条这种类型的错误,一条一条听完。网站用户肯定会得到正确的结果,因为这部分我都筛完了。

这次更新正常应当在 1.14 新版数据格式更新,1.17 新版拆解软件开发成熟以后更新,但这数据处理是真 TM 麻烦啊,烦死了。

近期用到的一些命令合集

Grep 字典式匹配输出

SED 若干则

CMD 快速删除文件

Excel:从右往左查找某个字符。

原理,使用 Substitute() 将所查找的字符替换为空,则长度差代表该字符出现的次数。将该次数作为 substitute 函数的第四参数,用一个特殊字符再度进行 Substitute() 替换,然后 Find() 该特殊字符。

微信取消 iOS 打赏功能一二三

事件原委:

4月19日下午,微信官方通过其公众号发布了一片公告,其核心内容为“iOS版微信公众平台赞赏功能将从4月19日下午17:00开始被关闭,安卓等其他版本微信赞赏功能不受影响。”微信表示仍然可以通过二维码转账的方式对公众号表示支持,但次日凌晨微信又发布官方通知,宣布紧急对昨天(19日)下午上线的 iOS 版微信公众平台文章个人转账功能进行关闭,意味着二维码转账也不能用了。

根据微信团队的说法,做出这次改动的原因主要在于苹果公司一方。声明中写道:“2016年6月13日,苹果更新了3.1.1条款,更严格要求App 不得包含指引客户使用非 IAP 机制进行购买的按钮、外部链接或其他行动号召用语。”腾讯方面与苹果公司长期沟通未果,最终只能够在 iOS 系统上取消了打赏功能。

苹果方面已经针对此事做出回应,表示微信可以选择提供App内购买让用户赞赏他们喜爱的公众号运营者,微信只需正确使用App内购买体系进行开发即可。并强调“如同我们提供这一选择给所有的开发者一样”。

App Store 审核指南 ( https://developer.apple.com/app-store/review/guidelines/cn/#in-app-purchase )

3.1.1 App 内购买:

  • 如果您想要在 app 内解锁特性或功能(解锁方式有:订阅、游戏内货币、游戏关卡、优质内容的访问权限或解锁完整版等),则必须使用 App 内购买。App 不得包含指引客户使用非 IAP 机制进行购买的按钮、外部链接或其他行动号召用语。
  • 通过 IAP 购买的所有点数和游戏货币必须在 app 内使用且不得过期,并且您应确保为所有可恢复的“App 内购买”设计一套恢复机制。
  • 请务必指定正确的可购买类型,否则您的 app 将被拒绝。
  • App 不得直接或间接地将 IAP 内容、功能或消耗品赠予他人。
  • 通过 Mac App Store 分发的 app 可托管基于非 App Store 机制的插件或扩展功能。

后续事件:腾讯某高管在其公号上发布文章《腾讯高管:为了更自由的用微信,我打算重新买部安卓手机》评论此事,表示自己打算重新买部安卓手机,“虽然可能性不大,但我希望未来苹果公司的股价和在华销量能够告诉它,这种逼迫 App 应用与安卓平台产生功能性差异化的平台政策,是得不偿失的。”

列表式评论:

一、关于公众号:

  • 开设公众号需要提交身份证明付费审核,文章内容在微信管理下,『不适』内容随时可能被删除。
  • 公众号的文章数据完全储存在微信服务器上,微信制定了一系列规则限定公众号的行为。
  • 外链(跳转其它网站)必须有企业资质,个人开号只能链接到微信内其它文章,完全出不了微信。
  • 基于此,苹果认为公众号文章就是微信的功能之一,微信认为是独立个人行为。
  • 微信认为『打赏』是用户间转帐,而苹果觉得这是购买应用内功能。
  • 双方争议在于『公众号文章』是否属于应用本身部分功能。
  • 双方争议还在于打赏功能是否有『解锁』行为。
  • 公众号文章算不算,你自己判断。
  • 你自己判断也不算,苹果说了算。

二、关于 App Store:

  • App Store 内,免费获得,也被定义为一种购买行为,只是价格为零。
  • App Store 内,不改变任何 App 功能甚至连界面都不变的 IAP (应用内购买,简称内购)是存在的。
  • 比如 Doodle God 就有 Thanks to developers 的内购,即打赏。
  • 可以认为,事前付费事后付费,付不付费,都不是定义内购的必要条件。
  • 可以认为苹果觉得没有跳出 APP 范围的非实物付费都属于内购,而微信严格规范下的公众号文章属于此类。
  • 各直播平台 iOS 版的打赏功能确实是用内购充值平台代币的,当然你也可以通过网站或安卓版 APP 充。
  • iOS 充值获得的代币大约就是网页/安卓版的 70%,差额就是 App Store 分成。
  • 苹果的审核标准并不一致,确实有大量开发者抱怨。
  • 2016 年 6 月的标准,到现在才开始怼,苹果在打自己脸。

三、关于事件

  • 微信并没有否认苹果『一视同仁』的声明,而是抛了个暧昧的高官『个人』文章作为回应。
  • 微信沟通大半年并非为达成一致意见,而是想要特权。
  • 商业合作的事,不能叫要特权,应该叫利益分配。
  • 如果按苹果要求开发,至少公众号运营者能拿到 iOS 用户打赏的 70%。
  • 现在微信不干了,公众号运营者的这部分收益降为零。
  • 从这个角度来说,吃相难看的是微信,为跟苹果要特权牺牲作者群利益。
  • 高管 个人 对对方公司股价和销量的言辞,直如街市泼妇。
  • 个人 两字我用了加粗,表强调,显然他不能代表公司立场。
  • 显然 两字也应该用加粗的,我忘了。
  • 即使如此,事件影响到的只有公众号运营者的一部分收益。
  • 所以这事本来就是公说公有理,婆说婆有理。
  • 吃你的瓜。

四、升华主题

  • 微信不会下架 iOS,也不会再有 3Q 大战二选一,都是成年人。
  • iOS 版和安卓版的功能已经有很多区别,以后会更多,这次事件未来回头看,只会是过程中的寻常一节。
  • 当然炒一炒还是可以成为热点的。
  • App Store 优点之一就是严格审核,统一规范带来的体系信赖。
  • 苹果限制多,不全是对用户有利的限制。
  • 安卓更自由,也未必是对用户有利的自由。
  • 苹果只占手机市场份额 20%,App Store 同样只占软件市场 20%,谈不上垄断。
  • 利润份额和利润率不是垄断的指标,但是商业谈判时的优势。
  • 在商言商,本不须谈及道义。然而腾讯某高管似乎忘了自己是怎么对付淘宝、网易云音乐、快的、虾米等的。
  • 同是争取利益,苹果偏执的『一视同仁』,在托辞选择上比微信还是好一些。

五、实用建议

  • 手机号目前依然是别人找你的最好方法。
  • 电话比文字直接,快速,准确,有时也更温暖。
  • 文字比电话含蓄、有存档、有时会误解,会错过时机。
  • 你的相对价值决定了是你担心找不到别人,还是别人担心找不到你。
  • 最有经济能力换手机的人,也最不用担心上不了微信别人找不到他,当然也最不需换手机。
  • 屁股决定脑袋的某高管除外,当然,其实他也不用担心。
  • 强行假设一个对立困境并为之争吵,即使在脑残粉中也是最愚蠢的行为之一。
  • 有人换手机难,有人换 APP 难,苹果害怕失去用户,微信也害怕失去用户。
  • 你是用户,你怕啥。用到不想用,换哪一个都行。

Windows 10 下清理 WinSxS 很有用的一条命令

更新:查询相关资料时发现已经有人实现了更完整的工具: DISM++

地址:http://www.chuyu.me/zh-Hans/index.html

==========================================================

来源:Microsoft MSDN

Windows 在每次更新补丁以后会把补丁新旧文件都放到 WinSxS 目录里,于是 WinSxS 越来越大。如果你使用 Windows 磁盘工具中的磁盘清理功能,确实能清理掉一些文件,但清理以后,你依然可以在控制面板里卸载各个 Windows Update 补丁,就意味着旧文件其实还在目录里。

而这条命令通过 /ResetBase 参数,会把所有的旧补丁全部清理干净,将当前系统状态设置为『Base』。你也再无法退回到之前的状态,当前状态变成了新的 Base。也就是说,这命令相当于是 WinSxS 目录专用的『删除还原备份』命令。该命令不会影响以后的补丁,如果有新补丁需要重新运行该命令清理。

注意,清理时间会很长,笔记本注意电池电量。

扩展阅读: WinSxS 目录功能 (MSDN)

感谢读者,新年送 Steam 老游戏

感谢我的 Steam 好友和关注我博客的同学们,送点老游戏。如果:

  1. 你有 Steam 帐号。
  2. 你有 steamgifts.com 帐号或者可以开通。(开通时会自动审核你 Steam 上的游戏,游戏越多越容易通过,只有一个 dota 或者 csgo 的肯定是开通不了的)

请在本帖子下留言,留下你的 steam 地址。最先留言的十位同学将收到正版三角洲经典游戏合集各一份。因为留言是先会被我审核的,所以不用担心别人会看到你的留言。

 

本次送的是:

http://store.steampowered.com/sub/46995/

如果你无法开通 steamgifts.com 帐号,但有steam 帐号,只会随机获得一份 10 元以下的小游戏,也限 10 份。

如果你连 steam 帐号都没有,要不你能迅速开通,要不就等下次机会吧。

Ubuntu 安装 scrapy 及 pip upgrade 时的各种依赖问题

安装 Scrapy 时遇到了依赖问题,使用 pip 时又发现自带的基础 py 包同样依赖不全,后一并 Google 解决,记一笔备忘。

首先安装 PIP,即 python 的包管理器。

由于 ubuntu 官方库提供的 pip 不是最新的,因此需要先 upgrade 自己:

此时如果你直接试图安装 scrapy 是会出错的:

原因是 scrapy 需要抓取网页因而要处理 https,而处理 https 又依赖加解密算法(即 cryptography 包),而 cryptography 又依赖傅立叶变换的算法以及相应的编译环境。Ubuntu 16.04 默认没有安装 libffi-dev 和 libssl-dev,gcc 也不一定安装,而 scrapy 包又没有将相关软件包记到依赖列表里,因此需要先手动安装:

然后再安装 scrapy 即可顺利完成。

 


顺便,由于更新强迫症,一并把 pip 自带的包均更新了一遍。pip 没有 apt 那么好用的 dist-upgrade 命令,需要先手动列出旧包然后逐项更新:

这些 Py 包可以直接升级:

这些 Py 包需要先安装 libssl-dev、libffi-dev、python-dev 以及 build-essential 以后才能升级(其实都是因为要依赖 cryptography):

这些 Py 包需要先安装 python-dev 以及 libjpeg8-dev 以后才能升级:

解决。

 

话说 numpy 的编译时间真是长啊……

Overwatch Toolchain 解包方式考察


理想的英雄语音音频源文件,大概是这样的:

sample

有一个比较标准的文件名(Filename),以英雄名字起头,文件名自己就包含了一些有用的分类信息。
有一个配套的文本文件(Dictionary),里面写好了每个音频对应的台词(Text),我们直接可以查找替换复制粘贴。
有一套分类详尽的标签(Tags)列表,里面详细地给每个音频分好了类,我们可以方便地根据这些标签进行筛选、处理、归档。
这些理论上 Blizzard 应该已经做好了放在客户端里,我们只要解压了就能拿来用。

但事实上并不是这样的,CASC 是 BLZ 私有的加密格式,目前并没有很好的手段可以完美解压,实际解出来的结果大概是这样的:

hashname

这种 32 个数字英文组成的字符串称之为 filehash,可以简单理解为一种特殊的文件名。这种名字没有实际意义,仅仅表示『这个文件和那个文件是不同的』。

所以,比『什么都没有』稍微好点,我们有了『不知道是什么的一堆文件』,稍后我们又通过文件格式识别软件,找出了其中的音频部分,并转换成了可以播放的 mp3。于是我们得到了『不知道是什么的一堆音频』:

untitled-2

情况没有本质变化,但我们有了一大包知道是 mp3 的文件以后,我们就可以 手-动-听-写-打-标-签 了。

于是情况变成了这样:

untitled

这就是 http://ow.thnuclub.com 这个小站现在正在做的事情。全世界想的办法都一样——先解出来能播放的,再人工一个一个挑。幸运的是,吃瓜群众撸袖自己上,一不小心撸出了全世界最好的守望音频网站。


 

昨天 nga 有网友(青龙圣者@ngacn.cc)推荐了 toolchain 系列解压软件。这个软件在小站建站之初是没有的。现在看来,它有优点也有缺点,但前景似乎不错。

toolchain 使用的还是 zezula 的 CASCLib 开源库,但库版本更新了不少。因此比 cascview 能多解出一些信息,具体地来说是有了目录和文件类型,有目录就意味着可以自动完成一部分标签。但缺点是引入了另一套也没啥意义的文件名系统。于是情况变成了这样:

小站的旧数据有 Text 内容,而 toolchain 有相对比较准确的标签分类。但因为两边的文件名对不上,所以不知道哪个对应哪个。

再仔细验证以后,发现 toolchain 解压的文件是可以计算得到 filehash 的,于是又变成了:

tagmatching

这是目前所能获得的最大的成果了。

进一步分析发现,toolchain 解压出的音频总数较少,也就是:

compare

原因可能是 toolchain 的作者的关注重点并不在音频上,因而把原始数据中暂时未分析的部分直接抛弃了。而 CascView 则以解压优先,并未抛弃数据。

 

总结:

  1. toolchain 通过目录结构间接提供了较为准确的英雄分类 tag,可以补充修正现有小站全靠人工听写的标签数据。
  2. toolchain 目前仍然没有解出音频对应的文本,而目前音频文本(Text 数据)依然是最宝贵的劳动成果,也是 ow.thnuclub.com 小站存在的最大价值。暂时还没办法由 toolchain 自动化解决,期待未来某天可以彻底解决。那时小站大概就可以关闭了。
  3. toolchain 引入了另一套文件名,但可以通过计算得到 hash 值与旧数据对应起来。
  4. toolchain 的数据分类更细致,但总量较少,新的文件名系统无甚作用,且构成规则不明。因此也没有必要跟随 toolchain 的命名方式。
  5. toolchain 可解压出 *.mdl、*.dds 等文件,对视频制作者、签名档、头像等很有作用,但对于既有的音频内容,所助仅限于标签分类数据。
  6. 对于一些特殊的标签数据,例如莱因哈特的台词『Many of my comerads fell in battle here, may they rest in peace.(我的许多同伴在此牺牲,愿他们安息)』只会在艾兴瓦尔德这张地图出现,因此较完美的 tag 应当是『莱因哈特,英雄,艾兴瓦尔德,地图,入场』,这个是 toolchain 也无法提供的,只能依靠人工标注。

因此,在现阶段 toolchain 还不成熟的情况下,暂时还没有必要修改小站现有的数据结构和使用方式,只需要把 toolchain 提供的目录结构,转化成较为准确的 tag 数据补充到小站上即可。相比于 toolchain 构成规则不明的文件名系统,可以通过计算得到的 filehash 系统通用性也更好一些。


接下来的工作:

  1. 计算 toolchain 获得的所有音频文件的 hash 值,如果有软件可以直接带子目录列表输出 csv 就好了。
  2. 通过目录路径给 toolchain 所有音频文件打上英雄分类/地图分类 tag。
  3. 合并到现有小站数据上,需要解决英雄标签冲突,并尽可能保留有效信息。
  4. 但合并 tag 也可能导致形如『【天使】I feel unstoppable.』这类音频中的安娜标签丢失。具体处理办法还需要考虑。

更新完成。

盗号开挂被封责任是谁的?

最近一段时间守望外挂封号频率变快,吃瓜群众们顺带就发现了另一乐趣:『看演员』。即是围观被封号的人员是如何花样百出地去论坛控诉他们是『被误封』的。我也去了。可不是嘛,挺开心的。

绝大部分的申冤理由最后都集中到了『被盗号开挂』上,毕竟这大概确实属于最能彻底撇清责任的理由。帐号被盗并非拥有者意愿,而被盗期间主人对帐号失去了控制权,造成的影响也应当与主人无关,既然两个环节都并非号主意愿,那么号主自然不应当承受处罚。我觉得这个申诉理由确实有点意思,就记一笔理一下这里的逻辑好了。

 

『帐号被盗开挂被封』,仔细想想这八个字背后的逻辑其实挺复杂的。为了说明问题逻辑,不妨先来看一下另一个例子:

你买了一辆汽车,一切手续完备资格有效,各种费用包括保险费交通费全部交清——这完完全全是你的东西,别人找不到一丝茬。然后你某天下车没有关好门,一个无业混混一拉车把,门就开了。他坐进去打算开一把过瘾,然后就撞死了个老太太,要赔 30 万。

你忘了关车门,混混偷了你的车撞死了人。好嘛,这事怎么了结?

一般来说,首先是分配责任。混混偷车还撞死人当然是主责,但你确实也忘了关门,次要责任肯定得担一些。至于比例多少基本就是法官定度了,就假设是二八开吧。于是理论上你承担 6 万,混混承担 24 万。在结案以后,汽车会还给你。至于洗车费做法事香火钱,那得你自己出。

这个例子可以有诸般变化,比如你能证明你没有疏忽,已经尽到了保管责任,有监控录像证明你确实停在车库并且锁了门,混混是自己撬门开的。那你很幸运的不用承担责任,理论上还可以找混混要求赔偿修车钱。又比如混混还未成年,你停车的地方又是学校附近,可以预见到这里未成年人多。那你忘关车门甚至可能成为主责。再比如混混出车祸一块死了。那你就安心赔上 30 万给老太太家属,说不定还得另赔 30 万给混混家属。

但就算是一堆废铁了,车还是会还给你。如果你还要,记得付拖车费。

 

所以照这么说,帐号=车,应该还你罗?

这里的最大区别,其实恰恰就在于帐号不等于车。

你对某辆车拥有『所有权』,意味着对这车拥有一切处置、支配的权力,改了拆了砸了埋了卖了,都行。除非法律明确禁止,比如做成汽车炸弹。但退一万步说,法律也只是禁止你危害公共安全,并不禁止你对汽车进行改装,哪怕是改造成炸弹。

实物商品的复制需要和原型等量多的材料,还需要同等的加工和运输,凝聚了诸多人类劳动,因而我们可以将每一辆车看作独立物品,并单独分配所有权。但软件不同,软件存在一个实物没有的特点,『零成本复制』。无论是代码也好,小说也好,本质上都只是一段特定的排列顺序。软件作者,小说也好,所做的工作本质是排出这段序列而已。排列是困难的,排出来了,接触到的人想要照着再排一次,却毫不费力。

为了对抗这种情况,人们发明了版权。一旦某个序列排好,作者就可以宣称对这样一段序列有所有权。全世界任何一个地方,只要出现相同的序列,作者就拥有所有权,这就是版权的本质。实物的『复制』有成本,所以所有权可以分配到物。序列的复制无成本,则所有权索性不可分割,全部属于创造者。

而客人购买的,是『接触、阅读或者使用这段序列』的权利。说人话,就是买了软件的使用权,或者书本的阅读权。对于书籍而言,作者把『一段排列好的文字』通过卖实体 / 电子书的渠道,展现在你面前。展现的期限通常都是永久的,但也存在『租书』这种有时限的情况。软件同理,你购买的是限时或者永久使用这段代码的权利。

因为所有权永远是作者的,所以『复制』作为对原型的一种处置,自然也只有作者拥有这一权利。这样就从法理上,确定了未经作者许可的『复制』(也就是盗版)是侵犯作者权力的。同时,尽管在绝大多数情况下使用时长是永久的,但购买使用权本身更像是一种『租赁』。你花钱在某网吧办了『牛逼会员』,终身免费上网,也终归只是一种特殊的包时上网,并非就拥有网吧了。

 

回到守望这事上。你花 198/328 购买的,首先并不是软件的『所有权』。如果你对守望有了『所有权』,则暴雪网易反过来需要向你交纳使用费了,这显然不成立。没有所有权,就排除了『任意处置』的权利。顾客购买的并非所有权,则如何使用,需要根据买卖双方的约定执行。

你把钱交给暴雪,暴雪允许你复制它的客户端,连上它架的服务器,获得愉悦。所以你购买的是『使用名为守望的这段代码获得娱乐』的权利。时长名义上是『永久』,实际上是暴雪公司的寿命。服务器本质上也只是另一段代码,客户端和服务端代码一起,才能整个正常运行起来。

讲到这里,就涉及到核心问题了:盗号开挂该不该封?

暴雪拥有守望的『所有权』,并分割出了很多份不同的『使用权』,一个客人通常会购买一份使用权,但真想要购买多份也可以(小号)。每一份使用权都在顾客和暴雪达成约定后获得,约定内容包括:

  • 支付一定的金钱(就是花钱买)。
  • 为客人准备一份使用权,并准备相应的服务资源。(例如每卖出一千份多开一组服务器)。
  • 约定这份使用权的帐号密码,包括密保等,通常由客人自行完成(注册帐号)。
  • 若干条使用权的限制(也就是用户协议),通常包括不可共享、反编译等,当然也包括不可开挂。

在这一逻辑下,帐号密码只是链接暴雪和玩家的一个环节。它本身并不是出售的使用权的一部分,而仅仅是用来和玩家约定,谁可以使用这份『使用权』而已。也就是说:

  • 对于玩家,主观感觉可能是:花了 198 / 328,买了一个游戏的使用权,只有我能用,别人用不算。
  • 对于暴雪,客观的逻辑则是:某一份特定的『使用权』已经售出。自己准备好了相应的服务资源,并和客人约定了使用这份资源的口令。当然,口令可以由双方约定得很复杂(安全令/异地IP限制),并且暴雪也建议约定得足够复杂(绑安全令送 WOW 宠物)。但用户依然可以约定得很简单。

对于暴雪而言,确认身份的唯一方法就是口令,只有拥有口令才能获得『使用权』,只要拥有口令就能拥有『使用权』。而惩罚也是针对『使用权』在行使过程中的不当行为作出的,根据情节轻重,会暂停提供使用权,几天到永久不等。也就是说,对于暴雪而言,只是针对每一份『使用权』的不当行为,削减该份『使用权』的时长罢了。

由于事先约定了口令,自然拥有该口令的连接,必须可以访问该份『使用权』。盗号者当然犯了冒用他人身份的罪,然而之所以说“冒用”,正是因为只有当事人才知道是假的,而对于善意的第三方而言,这个身份是正确有效的。

一个有效『使用权』做出了不当行为,于是削减该份『使用权』的时间。

一个有效『使用权』开了外挂,于是削减该份『使用权』所有剩余时间(即封禁)。

由冒用身份而对事主造成的损失,由冒用身份的人负责。假若在核对口令检查身份时服务方有疏忽,则服务方也有责任。也就是说,如果你不但可以证明是有人盗用你的帐号开的挂,并且还能证明暴雪在验证帐号密码上有疏忽(比如明明开了将军令没却没验证 / 错误的用户名密码也可以登录),那么确实有理由解封。但假若在验证帐号密码上没有疏忽,则你的损失应当向冒用身份的人去追索,而与服务方无关。

 

以上只是逻辑上而言的,但在现实中其实还有更强大的约束存在——购买时的事前约定,也就是用户协议。当用户协议与法律不冲突时,该协议无论从人伦视角来看多么过份,依然是受法律保护的有效协议。因为这是最顶层的“事前约定”。至于怎么看用户协议,就不用多说了。