@euzen #27
那和 urllib3 这个有关的可能性就非常大了……

可以直接抓包把原始的请求内容拿出来看一下，或者在服务端打印一下所有字段的信息。

懒得追查的话也可以先把 urllib3 升级到 1.25 版本以上看看问题会不会自动消失。


你这个问题真的是搞了个超大的 X-Y Problem 出来……

认真的看了一下，楼主你这个问题没有描述清楚哈：

> 服务器就是接受 iso-8859-1 编码
这个是根据什么判定的？怎么测试出来的？

> 必须提交'\xe6\xba\x90\xe4\xbb\xa3\xe7\xa0\x81' 才可以
是说这样提交就可以正常使用？这个是 utf-8，不是 iso-8859-1 啊，和上一条的结论似乎不一样？

> 使用 request.post
指的是 requests.post 嘛？（少了 s ）
如果是的话，我现在怎么觉得和我一开始认为的是同一个问题了呢……
如果是这样的话，那还是看一下 urllib3 的版本号


BTW：
赞同 @xuboying 关于最开始那几种展示无区别的看法。

BBTW：
我感觉楼主还没有把整个问题的完整情况搞清楚。
建议使用抓包软件抓一下 requests 发出的原始请求，确认编码情况。

刚睡醒，仔细看了下应该不是同一个问题，我再看看楼主到底想干啥…

咦，昨天群里有个人在问这个，我直接复制下我的回答：


「 暴走的熊猫: python2 用 requests 库上传文件时，如果文件名是中文，上传失败，度娘一圈给的原因是中文文件名被进行 RFC 2231 编码了，导致找不到文件，给的解决方法被都是改源码，大佬们有其他方法么？ 」
- - - - - - - - - - - - - - -
翻了一下，这个似乎是 urllib3 的锅
https://github.com/psf/requests/issues/4652
https://github.com/urllib3/urllib3/issues/303

而 urllib3 似乎已经在 1.25 版本里修好了这个问题
https://github.com/urllib3/urllib3/pull/1492
https://github.com/urllib3/urllib3/blob/master/CHANGES.rst#125-2019-04-22

你要不要看下你的 pip 或者 venv 里的 urllib3 的版本号

只是为了编译的话，为什么要用 IDE ？

极其之频繁的话试下触发角？

所以楼主还是没有给出你所想阐述的 『企业邮箱』 的定义。

这里至少可能出现 3 种不同的理解：

1、『企业邮箱』指的是『真实的企业官方设立』的邮箱。

没有很好的办法，即使某域名由某企业备案，也不能代表该企业以该域名为官方的企业邮箱。
也不建议直接使用官网域名来判断，因为部分企业的业务域名和企业邮箱域名是互相分离的。

2、『企业邮箱』指的是 『使用了企业邮箱服务』的邮箱，例如腾讯企业邮，谷歌 G Suite 邮箱等。

可以收集各企业邮平台的 MX 记录域名，凡域名 CNAME 到相应域名的，均视为这种情况。
但是疏漏的情况肯定会存在，很难完全覆盖到。

3、『企业邮箱』指的是『使用自己持有的域名搭建』的邮箱，包括自己搭建的，和托管给第三方的。

可以反向思路，但凡未使用公共服务的，均视为这种情况，需要收集公共邮箱服务的域名。
和上一条一样，也一定会出现许多疏漏的情况，无法完全覆盖。

@strahe #18
那就考虑 bcache / LVM cache / dm-cache 吧

不过说实话，PB 级别的话，应该要考虑直接 CEPH 了吧，CEPH 是支持分层缓存的：
http://docs.ceph.org.cn/rados/operations/cache-tiering/

个人蛮推荐 Windows Server 分层存储的：

是存储池带的功能，企业级，如果使用 Win 系，可以考虑下
https://docs.microsoft.com/zh-cn/windows-server/storage/storage-spaces/understand-the-cache

@Remember #1
L2ARC 是读缓存，不是写缓存啊。

@secondwtq #4
ZIL/SLOG 更大的作用似乎是降低写入延迟和保证数据的安全性。
我看到的一个说法是，每 5 秒钟数据就会被刷新写入到最终位置，确实如此的话，似乎对 『连续写入』的帮助不大。

> OpenZFS aggregates your writes into “transaction groups” which are flushed to their final location periodically (every 5 seconds in FreeNAS & TrueNAS).
> 来源： https://www.ixsystems.com/blog/o-slog-not-slog-best-configure-zfs-intent-log/

似乎翻到了一颗有意思的 IC，也许就是这种玩儿法了


继续补充：2 楼的我好像混淆了 DP ALT MODE 和 HDMI，我再补补课

BTW：你可能需要看下这个帖子 https://v2ex.com/t/610853

另外，其实上面的帖子还隐含了一个信息：
苹果只保证了独显机型和新 Adapter 支持 DP1.4，实际中应该还需要考虑线材和显示器方面

没买那个，在用小米的 type-c 转 DP，充电功率 89W，日常够用了

https://wx3.sinaimg.cn/large/760b39b3gy1gb2hiz4bxkj20cs06ewfk.jpg

期待更多的同行能够认识到这一点，这样和我竞争的人就少了 [手动狗头]

啊呀这样说还是有歧义，尝试解释一下：

QQ 邮箱体系内，可以当做域名邮箱使用的，有两个业务：
域名邮箱 和 企业邮箱

截图里的，是那个叫做 “域名邮箱” 的域名邮箱服务，估计以后慢慢就关掉了。
与此同时，那个被叫做 “企业邮箱” 的域名邮箱服务，还是可以正常使用的。

以及，那个被叫做 “企业邮箱” 的域名邮箱服务，并不是只有企业才可以用。

再以及，如果你只是自己用的话，不需要担心帐号数量限制，配置好全域邮件转发就行了。


以上这一大串，充分说明了，好好给产品起个名字有多重要。

楼上诸位，区分清楚 “域名邮箱” 和 “企业邮箱” 啊，这是两个不同的业务…… 企业邮箱那边是正常用的

咦，原来这个飞猪就是 NOMO 的 flypig 啊

我觉得你对 “重放” 是不是有一定的误解？

“防重放” 一般防的是第三方监听了一个 “有效请求” 之后，通过再次发送这个请求来达到一些其它的目的。

举例：
张三 使用某银行 APP，向 李四 转账了 100 元，银行 APP 调用某接口，正常的完成了这个请求。

但是这个请求被 王麻子 通过中间人攻击监听到了；
> 此处为防监听，也就是 https 常见的工作内容）
> 王麻子由于未持有银行域名的 https 证书，未能完成监听

于是王麻子把请求原样发送了 3 遍，期望张三给李四再转 300 元；
> 此处为防重放，一个活儿不能干多次
> 由于银行记录了请求 ID，直接忽略了这 3 次请求

王麻子又试着把请求中的收款人改成自己，期望能收到张三的转账；
> 此处为防篡改，保证执行的内容和发送者发送的一致
> 银行校验请求签名不一致，直接拒绝了这个请求，同时把请求留档给了安全部门



而抢票软件干的事情相当于什么？
张三 使用某银行 APP，向 李四 转账了 100 元，转账 ID 01。
张三 使用某银行 APP，又向 李四 转账了 100 元，转账 ID 02。
张三 使用某银行 APP，又向 李四 转账了 100 元，转账 ID 03。

这三个请求是互相独立的，不叫 “重放” ，只是恰好业务一致而已。