@clearc #47
你的说法我能够理解，包括 46 楼的朋友关于 setapp 的说法。

我对此类行为的忍受度相对较高，主要是因为我觉得：
我们不能把 “好人” 的要求放的太高，并希望他们通过损害自己的利益来达成 “好人” 称号。


可能我从一开始就不认为荔枝会是一个 “完美的” 正版化推广者，所以心理落差比较小吧。

当然，不论是否有做错事，既然引发了争议，说明必然有不如意的地方。
建议荔枝在 PR 方面再慎重考虑一下，自己希望呈现出的形象是怎样的，是否对这个形象做好了准备。

@clearc #41
回复提示能看到，你可以看一下你回帖需要消耗多少铜币，短回帖如果超过 5 铜币，那可能是降权了。

那个帖子我之前有看过，我认可关于 “封禁是荔枝主动要求的”的说法，但我不认为这件事里荔枝有太多责任。

厂商给了荔枝代理权，荔枝把序列号卖给了 A 使用，A 把序列号卖给了 B 使用。
这个问题其实应当拆成两个合同来理解：
B 与 A 的销售合同，A 与 荔枝&厂商 的销售合同。

B 遇到了序列号问题，不论是什么原因，都应当由 A 来解决。
如果 A 认为这件事是荔枝的责任，那么 A 可以自己向荔枝发起追偿。

B 和荔枝之间没有任何合同关系，荔枝对 B 的序列号不负有任何责任。


至于推脱给厂商的行为，却有不妥，但在整件事里我认为不算决定性的错误，因为荔枝原本就对 B 不负有任何责任。

关键错误是：A 违规转售了授权，导致自己的所有客户授权出问题，且（似乎）没有做好售后措施。

从 17 年开始就从数码荔枝购买软件，算了下也买了超过 500 块钱的软件，应该算老用户吧。

这件事我认为数码荔枝确实 *存在过错*，但是微软官方的暧昧态度才是 *罪魁祸首* 。


我自己最近几年长期订阅 Office 365，能够感受到正版卖家 / 买家的痛苦。
Office 365 是微软主推的产品，官方商城定价个人版 398，家庭版 498。
https://www.microsoftstore.com.cn/office/office-365-personal/p/qq2-00009

但是大家会按这个价格购买嘛？

15 年左右，市面上就出现了大量的 50 块左右的 Office365 家庭版密钥，后来价格逐渐上涨到 199 左右。
链接： https://www.v2ex.com/t/205126
（当时数码荔枝也出售过，还引发了质疑，链接： https://www.v2ex.com/t/206496 ）

16 年中，出现了大量 90 块左右的 Office365 个人版密钥，等效大约家庭版 120 元。
当时我还发了帖子，链接： https://www.v2ex.com/t/285562

18 年年底，又出现了一批 80 一年（后涨价到 160 ）的 Office365 家庭版密钥。
链接： https://www.v2ex.com/t/515677

这些密钥，究竟是来自什么渠道我完全不清楚，但是毕竟是数字密钥，它能正常兑换，且兑换过程中没有任何其他特殊声明，我认为这些密钥都属于微软认可的 “正版” 范畴。

补充说明：我自己虽然购买家庭版，但是从未对外出售，早期购买家庭版是因为当时个人版限制设备数，后期纯粹是因为购买成本低。

即使抛开这些 “野渠道” 不谈，现在 “正规”第三方渠道是什么价格呢？
我们以数码荔枝为例，当前的价格是：个人版 269 家庭版 299
https://item.taobao.com/item.htm?id=565828227961


从 15 年到 19 年，我不知道微软是有意还是无意，给我的感觉是他们完全没有关心过 Office365 的价格体系，对于那些不明渠道的低价密钥也从未有过态度（我认为这代表默许）。

回到家庭版的问题也是一样，与你分享家庭版的人，究竟需要是“家人”？还是“朋友”也行？亦或者只是“帐号”？
微软在这件事上从未有过明确表态，一直都是一种暧昧不清的态度（我认为这也代表了默许）。

价格体系的不稳定，和授权条款的不明确，对数码荔枝这样的 “正版商家”，是很不公平的。
他们虽然有着官方代理授权，但是其它人借助各种 “骚操作” 拥有更低的价格。

我能够理解他们面对的压力，但是 “官方拼车”这件事，实在是 “不合适”。
这实际上导致自己被拉到了 “不规范”授权的战场，我认为这对 “数码荔枝” 的品牌非常不利。
我不会因为这件事去指责荔枝，但是我非常建议他们不要继续做这件事。
https://www.lizhi.io/blog/94813543


在这件事里，微软才是那个最大的恶人。
https://wx3.sinaimg.cn/large/760b39b3gy1g7irwzuu22j20d907nai4.jpg

补充：
才想起来我数据库里其实只存了一部分数据，具体的 县 / 区 一级的数据有 142 MB 那么大。
and 接口实现很简单，单 php 文件不到 100 行就好了。
https://wx3.sinaimg.cn/large/760b39b3gy1g7gcuu2b6mj20oq0emmzk.jpg

其实可以自己把地理区域的边界爬下来，然后写一个简单的服务。

我拉了区一级的数据，其实并不大：
https://wx2.sinaimg.cn/large/760b39b3gy1g7gcpe54t4j21nq05cn0a.jpg

然后就可以自己写个简单的接口来查询，类似这样：
https://geo.by24.cn/district.php?point=113.031952,27.396448

注意：上面这个接口是我写着玩儿的，不要拿来用

@awhane #7 https://ws3.sinaimg.cn/bmiddle/62e721e4gw1et02ek7u61j200k00k3y9.jpg 我以为你从 18 年过年找到现在……

https://ws3.sinaimg.cn/bmiddle/62e721e4gw1et02ek7u61j200k00k3y9.jpg 看了下楼主的发帖记录，现在寒冬这么严重了嘛？

域名和真名完全一样 （没有任何多余后缀 com net cn 之类的）

OK，背景普及完毕，楼主的问题是怎么出现的呢？
很简单，session 是 B 服务器生成的，session-id 也是 B 服务器下发的，而 session-id 存储在 a.php 所在的 A 服务器，你使用不带 session-id 信息的本地客户端去 B 服务器查，当然就查不到相应的 session-data 啦。

而关于 “另一个人” 此时访问 a.php 的问题，其实涉及 a.php 的实现。
默认情况下，a.php 里应该是没有做 session-id 的保存和复用的，也就是说 a.php 下次请求 B 的时候，连 session-id 都不会带，那么自然就取不到相应的 session-data 啦。

杠精情况下，a.php 可以自己实现一套类似 cookies 的 session-id 持久化机制，来保证自己下一次请求 B 的时候会带上 session-id，那么自然就能取到相应的 session-data 啦。

引用一下自己在之前帖子里的回复：
https://www.v2ex.com/t/520410

这就体现出了很多人混淆 session / session-data / session-id / cookies 的情况了。


不少人因为 cookies 里存储了一个叫做 session 的变量，就粗暴的认为这是 session 的本体了。

我倾向于把东西划分为 session 和 session-data 来解释：
session 是个虚拟概念，代表了一个虚拟的会话过程
session-data 是个实体概念，代表这个会话中的独享数据（例如登录状态、用户信息等）

在大部分实现中（ flask 除外），cookies 里存储的只是 session-id，只是一个索引 id 而已，就一串字符 id 而已。
真正的 session-data，其实是存储在服务端程序中的，服务端程序，根据 session-id，取出了 session-data 参与运算渲染。
于是在外界看来，就好像这个 session 是通过 cookies 里的 session-id 来维持的一样。

https://ws2.sinaimg.cn/large/760b39b3gy1fyhtr5gmuqj209105u74e.jpg


这就造成了许多人 “ session 是存储在 cookies 中” 的误解。
同时也造成了，在讨论 session 的时候，很多人混淆 session 会话 / session-data / session-id 的情况。


当然，刚才被我排除掉的 flask，人家是真的把 session-data 存储在 cookies 中的（即 “客户端 session ”），所以在使用 flask 的时候，要处理好 secret_key 的安全性，否则容易出现 伪造 session 的问题，另外就是 flask 只对 session 做了签名，没做校验，所以本地 session 是可以被解码查看的。当然那就是另一个话题了，不多说。

还有许多平台带来的互联网文化，也是很有意思的。

早期的 斑竹、大虾、小白、PLMM ...
后来的 楼主、沙发、板凳、兰州烧饼...
平台特有的 一楼喂熊、233、RT、紫薯布丁...
V2 文化的 迫于 XX、六字真言...

有一些似乎都无法考证到底怎么发源的了，比如 沙发板凳 / 楼主 的出现应该是因为盖楼，但是盖楼这个词是什么时候出现的似乎不可考。

在知乎这种新形态平台刚出来的时候，还有许多人习惯性的称呼“楼主”“反对一楼回答”，如果翻看一些早期内容还能看到痕迹，当然现在基本上都是喊“题主”和“答主”了。

这个事儿其实可以严肃讨论的，很多东西都可以溯源，以下基于我对中文互联网的了解，可能会有部分错误。

在 Web 1.0 时代，或者说 PGC 时代：
此时比较常见的是门户网站的 新闻 /文章 /页面 。
少量的个人网站被称为个人主页（ personal homepage ）。

关键词：文章 / 页面

在向 UGC 的 Web 2.0 时代进发的过程中，BBS 出现了：
BBS 是什么的缩写呢？ bulletin board system，也就是 电子布告栏。

一个布告栏上的内容是怎么划分的呢？想象一下，布告栏被划分为多个区域（分区 /板块），上面贴满了一篇篇的内容（帖子）。

但是 BBS 不同的是什么？ BBS 可以回复啊，既然是回复帖子，就叫“回帖”吧。

这里插一句百度贴吧，其实也是论坛，也许是为了保护“贴吧”这个招牌，也许是因为 “帖子 /贴子”本来就大量混用，贴吧选择了“贴子 /回贴”这个称呼。

关键词：分区 / 板块 / 帖子 / 回帖 / 贴子 / 回贴



随着向 Web 2.0 时代的迈进，博客出现了：
博客为什么叫博客？ Web log -> blog -> 博客，其实就是 网络日志 /日记 。

那么博客上的文章，就是博客文章了嘛，再按照不同的缩略方式，就可以讲：我发了一篇 文章 / 博客 / 博文 （此时“博客”指的是单篇文章而不是整个站点）。

与博客类似的，就是空间（ QQ 空间，百度空间...）了，这个命名我不清楚是否和 MySpace 有关。
空间更像是一种集合体，复合了多种服务，可以理解为早期博客是空间的一个子集，后期博客在向空间的方向发展。

关键词：博客 / 文章 / 博客 / 博文

//简书为什么叫“文章”？因为简书是个博客平台啊。


紧接着，推特出现了，或者说类似推特的一大堆服务出现了：
我没有找到 twitter 官方自称 micro blog 的证据，但是确实早在 2007 年，就有媒体称此类服务为 social network microblogging services 了。
https://web.archive.org/web/20081207045512/http://www.thws.cn/articles/twitter-clones.html

那么 micro blog （微小的博客）进入国内之后，自然入乡随俗的被称为“微博客”了，相应的也就有了“发微博”的说法。

当然，平台的意志也是很重要的，Twitter 叫 “ Tweet / 推文，饭否叫“消息”，做啥叫“更新”，Follow5 叫“分享”，腾讯微博叫“广播”，嘀咕则就叫“嘀咕”，这些就是平台的策略了。

那么为什么微博要用“条”呢？我觉得有两个原因：
1、诉其本源，twitter 限制 140 个字符是因为短信，而短信我们已经习惯称之为“条”。
2、微博希望主打的就是“轻快”的特色，用“条”更能体现出来。

关键词：微博 / 推文 / 微博 / 条


从微博时代可以看出，平台越来越趋向于放弃通用名称，通过给出自己独有的称呼来表达个性。
为什么 V2 叫“主题”（包括 V2 之前已经有论坛称帖子为主题），也许就是出于这种考虑吧。

@bxsw #12
东莞是比较有名的 “分段递减模式” ，之前珠海也有，深圳有部分线路也是这样的。
售票员模式和上下车刷卡模式的 “分段计价”，相对来说对短途乘客会更友好一些。

另：东莞已经在准备取消 “分段递减模式” 计费了
http://dgdp.dg.gov.cn/007330029/0801/201907/190b89026c2b4be5995b24d2e1728e44.shtml
> 东莞市发展和改革局发布《东莞市完善城市公共汽车票价听证方案》（以下简称《方案》）。调整后的方案在基本维持现行公交票价水平的同时，单独制定了公交快线新标准，将高速路段过桥过路费纳入公交快线票价；同时拟取消跨镇公交分段递减统票计价方式。

@imnpc #10
@0Nick #11
珠海公交去年 11 月 18 日 起也把所有公交调整为 1 元了
https://mp.weixin.qq.com/s/VjccfN1TCd6n58j0EKUsbQ

目前（ 8 月 30 日）
358 线和 M488 线都有一辆公交车
在试行「上下车刷卡」模式

计划 9 月 16 日开始
358 线无人售票分段收费上下车刷卡模式
会在全线路全面启动

换句话说就是
到时候深圳所有 358 车的乘客
上下车都需要刷卡

https://mp.weixin.qq.com/s/B3eagI9hVXb0R_rkTMKt0A