小名开开

在春天的光影里喘息

Update: Ubuntu 16.04 系的解决了这个问题。此文终结。


无标题

这个 Bug 出现在几乎所有版本的 VMWare Workstation、VMWare Fusion 而且按原理来说似乎也会出现在 VirtualBox 上(未验证)。用户选择右键点击喇叭图标手动连接,则可以使用一段时间,Rhythmbox 之类的也可以正常播放声音,但只要打开声音设置或其它类似操作就又会断开。

遇到这种情况,可以先尝试在宿主机接上麦克风/耳麦,随便弄个录音设置,或者把普通耳机插头插进录音孔也行。对的,尽管实际上录不了音,但只要让录音孔插着东西就行。无标题

然后重启虚拟机,如果一切正常该提示不再出现,就继续往下看真·解决办法,如果依然不行,很抱歉你的问题不是这篇文章所能解决的。

这个问题的真正原因是:Ubuntu 默认会检测音频硬件设备,包括音频输入和输出两种设置,但 VMWare 不能正常反馈宿主机声卡的状态。感觉更多的是 Ubuntu 的锅,它没有检测设备存在就直接调用录音设备。

解决办法:

1
sudo apt-get install pavucontrol

安装 pavucontrol 软件包,然后在 Term 中输入 pavucontrol 启动旧版的音量控制:

Ubuntu 64-2016-02-27-20-44-14

在音量控制界面,选择『配置』选项卡,选择『模拟立体声输出』,不要选任何带“输入”的项。然后注销用户再重新进入桌面。

Ubuntu 64-2016-02-27-20-45-50

以上,VMware Ubuntu 就可以正常出声了。

无标题

关于数组公式解释见这里:<Excel 数组公式的概念解释>

补充一个实际应用里出现的公式

1
{=INDEX($A$4:$A$27,MATCH(1,IF(ISERROR(FIND(C4,$A$4:$A$27)),0,1),0))}

作用是在 A 组数据的各项文字中寻找到第一条包含 B 组词汇的数据,如图:

matchindex

原理是这样的,将 find()函数数组化,令其在 A4:A27 中逐个寻找 C4 中的『愿望』两字。当找到匹配时,Find() 函数会返回一个具体数值,即『愿望』两字在被查找的字串中在第几个字符出现;当找不到匹配时,则 Find() 函数会返回 #Value!。在数组化后,返回的数组大致为 { #Value!, #Value!, #Value!, #Value!, 2, #Value!, …, #Value! }。

再通过 if() 和 iserror() 判断这个数组中每个数的有效性,转为 {0, 0, 0, 0, 1, 0, …, 0}。

再通过 Match() 函数将数值 1 的位置找出来,即数组第 5 项。最后再通过 Index() 函数把原歌词中的第五句摘出来,并返回到屏幕上。

通过这个组合数组函数,可以查找某个词在多个单元格中的某一个出现过。

将函数改造成:

1
{=INDEX($A4:$A$27,MATCH(1,IF(ISERROR(FIND(C$4,$A4:$A$27)),0,1),0))}

则通过复制粘贴数组公式,可以知道 C4 这个词分别在哪几句中出现过,而不限于仅仅找出第一句。

Excel 公式,本质就是输入原始数据,处理后再输出结果数据,放在公式的单元格里。

有些公式,输入是一个数据,输出也是一个数据,例如取整 int()、10 底对数 log()。若 A1=5.5,=Int(A1) 显示为 5。

有些公式,输入是一组数据,输出一个数据,例如 Sum。这一组数据整个是一个参数。若 A1:A5={1,2,3,4,5},输入公式 =Sum(A1:A5),显示为 15。A1:A5 数组是 Sum() 的一个参数。

有些公式,输入是一个数据和一组数据,输出一个数据,例如 Match(A2,A1:A5)。两个参数,A2 是待查数据,A1:A5 是被搜索的数组。

而数组公式,则是输入一组数据,输出一组数据

以 Match() 为例,Match 公式的形式为 =Match(lookup_value, lookup_array, [match_type]),其中 第三参数 match_type (查询模式)在本文讨论中忽略。则本文讨论的简化为 =Match(_lookup_value 待查询数值, lookup_array 被搜索数组)

可以看到,一个 Match 公式一次只能在 lookup_array 里查找一个数值。而把 Match 公式改写为数组公式,并用 Ctrl+Shift+Enter 确认以后,实际公式则变成了 {=Match( lookup_value_array, _lookup_array, [match_type] )}。

在公式里,本来应该是单一数值的地方,被替换成了一个数组,待查询数值 变成了 待查询数组。则 Excel 会自动响应 Ctrl+Shift+Enter 命令,把该公式拆分成多次分别执行,每次取待查询数组里的一项,单独给出一个结果,然后循环到该数组里的每个元素都被查询一遍。

例如,选择 C1:C5 单元格并在公式栏中输入 =Match( B1:B5, A1:A10, 0 ) ,按 Ctrl+Shift+Enter 回车。Excel 会自动内部展开五次 =Match() 查询,每次查询在第一个参数位分别填入 B1 – B5。即在 A1:A10 中分别查找 B1 – B5 的值,查 5 遍,并把 5 个结果分别放在对应的 C1:C5 单元格里。

array_match

所以:

1. 因为往往有多个输出结果,使用数组公式需要先选择好输出位置,再在公式栏写公式,写完用 Ctrl+Shift+Enter 确认。注意,这多个单元格包含的是『一个公式』。

2. 数组公式需要你在写公式时,把『一个数据』的参数改写为『一组数据』。(例子中 Match() 函数本来的 lookup_value 即『需要查找的值』改成了『需要查找的数组』。)Excel 会自动循环这个改写数组里的每一个数据,然后把公式计算结果填到对应的单元格里。

3. 数组公式修改起来较为费劲,经常会出现『不能更改数组的某一部分』,正确的方法是先按 Ctrl+/ 全选该数组公式的整体占用位置,然后再在公式栏进行修改。

4. 某些公式,例如 Sum()、Len() 使用数组公式和直接使用该公式往往没有区别。所以如果你见到某个教程在以 Sum 举例讲数组函数时就不用往下看了。百度搜出来有不少是这样的。

5. 一般来说,常用的数组计算 Excel 都已经提供了特定的函数,比如 Logest()、Frequency 等。如果返回的值有两个以上的,也通常都拆成了多个公式,比如线性回归的 Slope()、Linest()、Steyx() 等。当需要多个计算结果时,也无需使用数组公式,使用 Excel 的公式复制粘贴就可以完成绝大部分工作。上文的例子即是如此,选择 C1:C5 然后输入 Match() 数组公式,和先在 C1 输入普通的 Match 公式 =Match( B1, $A$1:$A:$10,0 ),然后把公式复制到 C2:C5 上,效果是一样的,后续处理起来还方便一些。

那么数组公式有什么用呢?

大部分情况其实没什么用,确实没什么用,所以很多人用了好久也没用过数组公式。哲学点地说,等到你需要用数组公式时,数组公式就有用了。

数组公式的最大特点是『输出的是一个数组』,所以它需要用多个单元格才能放下,同时,它可以作为数组参数供其它函数使用。所以数组函数最大的使用场景是通过复杂嵌套函数,实现更大程度的 Excel 自动化。

例如,去除重复单元格,可以使用 Alt+A+M 的『删除重复项』实现,但这样意味着每次数据更新,都需要重新进行人工操作,当处理步骤较多时,往往意味着后续步骤也需要重新操作。而使用数组公式,则可以一劳永逸地解决这个问题。

1
{=INDEX(A:A,SMALL(IF(MATCH(A$2:A$20,A$2:A$20,)=ROW($1:$19),ROW($2:$20),4^10),ROW(A1)))&""}

因为『删除重复项』本质上就是一个『输入一个数组,输出一个数组』的操作。在这个例子里,Match() 函数的第一个参数和两个 Row() 参数进行了相同的对应循环,并把每个计算结果填入相应的单元格里。

而另一个例子

1
{=Mid(A1,Row(1:100),1)}

则相当于把 A1 单元格中的每个字符都单拆出来。辅以其它公式嵌套,可以比较方便地计算诸如『若干个单元格一共包含多少个特定字符』之类的问题。

一句话总结:当你在使用 Excel 时,需要处理『处理若干个数据,过程中包含若干数据,结果也是若干个数据』时,在宏程序之外,还可以考虑使用数组公式。

一个需求:如何批量建立 Github 帐号下的库。

Github 库通常的建立方式是通过网页,其次是通过 Github 客户端 Publish。

但这两种方式都无法批量建立库,每新建一个库都需要用户重复操作一遍。

查了一下,还真有这样的办法。Github 提供了 Restful API 来帮助企业管理代码库。不光是批量建立,还包括添加删除用户组等等,非常完善。就建库这一需求,Github 提供了这样的一个 API:

https://developer.github.com/v3/repos/

第5节就讲的是如何 Create 一个库,提供了非常详尽的设置参数:

Name Type Description
name string Required. The name of the repository
description string A short description of the repository
homepage string A URL with more information about the repository
private boolean Either true to create a private repository, or false to create a public one. Creating private repositories requires a paid GitHub account. Default: false
has_issues boolean Either true to enable issues for this repository, false to disable them. Default: true
has_wiki boolean Either true to enable the wiki for this repository, false to disable it. Default: true
has_downloads boolean Either true to enable downloads for this repository, falseto disable them. Default: true
team_id integer The id of the team that will be granted access to this repository. This is only valid when creating a repository in an organization.
auto_init boolean Pass true to create an initial commit with empty README. Default: false
gitignore_template string Desired language or platform .gitignore template to apply. Use the name of the template without the extension. For example, “Haskell”.
license_template string Desired LICENSE template to apply. Use the name of the template without the extension. For example, “mit” or “mozilla”.

当然其中大部分参数可以忽略,理论上只有库名是必须的。

所以使用以下命令就可以在不登录网站或者客户端的前提下建立一个库,通过 Sublime Text 等多行文本编辑软件(甚至通过 Excel)编辑一个多行批处理文件,然后运行即可:

1
2
3
4
5
curl -u "Github用户名:Github密码" https://api.github.com/user/repos -d '{"name":"库一名字"}'
curl -u "Github用户名:Github密码" https://api.github.com/user/repos -d '{"name":"库二名字"}'
curl -u "Github用户名:Github密码" https://api.github.com/user/repos -d '{"name":"库三名字"}'
curl -u "Github用户名:Github密码" https://api.github.com/user/repos -d '{"name":"库四名字"}'
curl -u "Github用户名:Github密码" https://api.github.com/user/repos -d '{"name":"库五名字"}'

库名重复时,Github 会自动报错,并不影响批处理继续执行。

#Update:

改进了。现在的样式如下:

0

第一步,先做一张报销单:

从自动化的角度来说,尽量采用公式帮助计算、限定单元格可输入的内容、以及设置单元格格式。在这张单据里,编号单元格为 K1

公式:

对于报销单而言,使用 =SUM() 和 =VLOOKUP() 通常就足够了,至多再加个 =SUMIF()、=COUNTIF() 就足以做出挺复杂的报销单了。

单元格格式:

选定单元格后 『右键 → 设置单元格格式』。标准的可以选择第三类货币格式,复杂的可以自行定义格式,使用#代表一个数位,使用 0 代表『当这个数位是最高位但为 0 时依然显示』。

step1-2

限定填充序列:

选定单元格后菜单栏选择『 数据 → 数据验证 → 数据验证』。允许序列,来源直接写入需要的内容,用英文逗号分隔。

step1-3

第二步,添加 Excel 的开发工具菜单:

依次点击菜单上的 『文件 → 选项 →(跳出 Excel 选项窗口)→ 自定义功能区 →☑ 开发工具』打钩。

step2

第三步,设置打印宏:

点击菜单上的 『开发工具 →Visual Basic』,打开 VBA 面板,左侧双击 『ThisWorkbook』,把以下代码粘贴到出现的窗口内,然后关闭窗口

注意 K1 为这篇文章中的编号位置,其它表单需要相应调整。

1
2
3
4
5
6
7
8
9
Sub PrintWithNumber()                                       '定义宏名
Dim startnum, loopnum, N As Long '定义变量:起始编码,打印份数和循环值
loopnum = Application.InputBox(Prompt:="需要打印多少份?") '定义打印份数
startnum = Sheet1.Range("K1") '读入表格上的份数的起始值
For N = startnum To startnum + loopnum - 1 '开始循环
ActiveSheet.PrintOut '打印当前表格
Range("K1") = N + 1 '份数加一
Next N '下一个循环直到结束
End Sub '结束

step3

第四步,添加宏按钮:

点击『开发工具 → 插入 → 按钮(窗体按钮)』。

step4

然后用鼠标在 Excel 空白处拖出一个方块,当松开鼠标时,会自动跳出『指定宏』窗口,选择窗口内的『ThisWorkbook.PrintWithNumber』,然后确定。

step4-2

右键点击该按钮,选择『编辑文字』,修改为『打印报销单』。

step4-3

第五步,设置打印区域:

这一步是为了防止把按钮本身也打印出来。

全选需要打印的区域,选择菜单 『页面布局 → 打印区域 → 设置打印区域』。

step5

第六步,另存为 xlsm:

由于使用了 vba,必须把文件存为 xlsm 格式。(启用宏的 Excel 格式)

完工。


今天接到一个小任务,寥寥一记。

在 Excel 中,常见的一种需求是打印带份数号码的各种表单,例如报销单、外出单等。通常财务都会提供模板给员工自行填写,再由财务按入帐顺序统一写上序号。但当某人一次性要写几十份,或者说类似的需求,需要一次性打印 N 份时,有没有办法让打印的表格上自动带上序号?

解决办法需要依赖 Excel 中的宏程序,在 Excel 中按 Alt+F11 可以直接打开宏编辑器。或需要先通过『视图』→『宏』→『录制宏』,再经由编辑宏的办法来打开。

核心宏程序如下,一目了然:

1
2
3
4
5
6
7
Sub test()
Dim N As Integer
For N = 1 To 10
Range("E1") = N
ActiveSheet.PrintOut
Next N
End Sub

E1 为需要填序号的单元格。程序先定义一个变量用来作为页码,然后不断用它替换指定单元格中的值,每替换一次就打印一张。这一方法硬要说有什么缺点的话,大概也就是打印任务数比较多,可能在几千份时会占用不少内存。

更完整的模板还需要在界面上做个按钮和两个输入框,以便让完全没有宏能力的财务也能定义起始和结束页码并打印。但今天这需求仅仅是帮助打印而不是做个新模版,所以这任务也就完成了不再搞复杂了。

样例下载 模板-日常费用报销表

Chrome 在更新到 44.0.2403.125 m 后,存在一个由拼写检查导致的性能低下 bug,该 bug 只在 win 版 Chrome 下呈现,同时影响 32 位和 64 位版本。

chrome-44-about就是这货

具体表现
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
<style type="text/css">
p {margin: 20px;font-weight: bold;text-align: center;width: 33%}
.input {display: block;width: 33%;margin: 20px;border: 2px solid #999;}
.editor {display: block;width: 33%;border-radius: 4px;margin:20px;overflow: scroll;padding: 8px;min-height: 100px;max-height: 400px;}
.area {border: 2px solid #fa0;}
.div {border: 2px solid #0af;}
</style>
</head>
<body>
<input type="text" class="input">
<p>Textarea</p>
<textarea class="editor area"></textarea>
<p>Contenteditable DIV</p>
<div class="editor div" contenteditable='true' role='textbox'></div>
</body>
</html>

将上面这段代码另存为 html 网页,在 Chrome 44 (win) 版本下打开。

用文本编辑器制造 10000 行会被触发单词拼写识别的文本,比如使用 Excel 连续生成 10000 行『AKB0048』。复制粘贴到橙色 Textarea 框中,然后用鼠标点击灰色 Input 框……

你会发现,非常的卡,光标在三个输入框中切换,每次切换都需要花费很长时间,对于性能不佳的电脑,和彻底进入死循环没区别了。

刷新页面重置数据后,再将这 10000 行粘贴到 Contenteditable DIV 的蓝色框里,第一次粘贴也略有卡顿,毕竟数据量比较大。但等卡顿过后,鼠标再在三个框中反复切换,就非常顺畅毫无迟滞感了。

10000linta

这就是这个 bug 的真身了:

在 Textarea 有大量会触发拼写检查的内容时,Chrome 44 的 Spellcheck 功能会极大消耗计算机资源,使得整台电脑近乎死机。

解决办法

由于这是浏览器 bug,前端程序员对此几乎无能为力,只能绕过这个 bug。

通常来说,HTML5 已经提出了 Textarea 的一些标准属性,比如 spellcheck=”false” 可以强制浏览器不检查内容,webkit 内核支持这一属性。正常来说,这似乎是很容易解决的一个兼容性问题。

但偏偏 Chrome 却强制忽略了这一设置,就像它强制忽略 font-size < 10 时那样。禁用拼写检查只在用户手动输入时有效,而对于 Ctrl+V 进来的内容,拼写检查依然正常运行,搞死你机。

即使你把相关属性全部列全:

1
<textarea class="editor area" spellcheck="false" autocapitalize="off" autocomplete="off" autocorrect="off"></textarea>

也是然并卵,在别的浏览器一切正常,而 Chrome 下依然故我。并没有解决问题。

解决方法一:

你可以通过 JS 检查当前浏览器是否是 Chrome,在需要粘贴大量内容的 textarea 上提示用户去关闭 SpellCheck 功能,具体位置为:

Chrome 菜单 → 设置 → (最下方)显示高级设置 → 语言和输入设置 → 启用拼写检查。

但这并不是一个好方法,尤其是需要用户主动去对 Chrome 进行设置。

解决方法二:

使用 JS,将一次的粘贴行为,模拟为连续字符添加的行为。比如当用户 Paste 后得到 Text 值,立刻删除该 Textarea 元素再重建一个。然后根据 text.length 使用 JQuery 插件 Jquery.Caret 不断循环插入字符。

这一方法缺点更多,首先是作为 walkaround 的方案,引入了太多并非用户参与的互动。其次,这一 bug 本来就是在大文本量 paste 下才会出现,如果再使用额外的一重循环,并不会使得体验有太多改善。最后,假如 Chrome 的再次升级把 JS 插入字符也纳入拼写检查的话,就会导致页面更 n 倍重的卡顿,到时候大概是再高性能的电脑都扛不住了。

解决方法三:

使用带 contenteditable=’true’ 属性的 DIV 元素代替 Textarea,并使用 innerText 或者 $.text() 来获取用户填写的文本内容。

10000lintv

这也是这篇博客所写的内容,这样的方法是最合法且绕过 Chrome 44 拼写检查 Bug 的方法。完全相当于是『有两种实现方法选择了另一种』。contenteditable = ‘true’ 属性的 DIV 往往也是很多 JS 版所见即所得编辑器的常用办法。比如 WordPress。这一方法不需要用户操作,也只需要少量 JS 代码。最后,即使这个 BUG 的影响范围继续蔓延,也不过是和现有的情况一样,不会更坏。

关于 MAC 版 Chrome:

Mac 下无此 bug,是因为暂时还没有拼写检查功能。

==== edit ====

现在 Mac 下也有了。

==== edit ====

现在修正了。

先上代码:
1
2
3
4
5
6
7
8
9
10
> new Date("2015-07-08")
< Wed Jul 08 2015 08:00:00 GMT+0800 (中国标准时间)
> new Date("2015/07/08")
< Wed Jul 08 2015 00:00:00 GMT+0800 (中国标准时间)
> new Date("2015 Jul 08")
< Wed Jul 08 2015 00:00:00 GMT+0800 (中国标准时间)
> new Date("2015 Jul 08 GMT+400")
< Wed Jul 08 2015 04:00:00 GMT+0800 (中国标准时间)
> new Date("2015-07-08 GMT+400")
< Wed Jul 08 2015 04:00:00 GMT+0800 (中国标准时间)
再说结论:

在 Javascript 中,当为某个变量只赋值日期时,会默认使用该日期的 0 点 0 分 0 秒作为完整的值。而根据表现格式的不同,在具体赋值时会使用不同的时区时间赋值。

当使用『-』作为年月日的分隔,即 YYYY-MM-DD 的格式时,赋值会根据 GMT/UTC 时间的当日 0 点赋值,再根据浏览器提供的系统时间,折算为当地时间。也就是说,如果你在北京,并且电脑时区正常。那么当你为某变量赋值『今天』时,实际上赋的值是 0 时区的 0 点 0 分 0 秒,换算成北京时间为早上 8 点。如果在东京,则是早上 9 点。

也就是说,无论是在哪个时区,相同的一套代码在不同的电脑上,会得到相同的值。

而当使用『/』作为年月日的分隔,即 YYYY/MM/DD 的格式时,赋值则根据电脑时间,取到本地时间该日的 0 点 0 分 0 秒。由于各时区都差一个小时整,实际上会导致 JS 代码在不同时区电脑上执行相同代码时,得到的时间值在绝对值上并不相等。即在北京时区时,会取到北京时区的 0 点 0 分 0 秒,同一时刻在东京则已经是当日 1 点 0 分 0 秒了。

换句话说,不同客户端执行相同代码会取得不同的值。

但即使如此,两者也有表现相同的时候。只要在赋值时就明确指定时区,则两者的值可以是相同的。例如:

1
2
3
4
> var a = new Date('2015-07-01 GMT+800')
> var b = new Date('2015/07/01 GMT+800')
> a.getTime() == b.getTime()
< true

同时,无论是哪种情况,当通过 JS 转换成时间戳时,其值都是相同的。原因在于时间戳本身的定义,就是指当前时间距 0 时区的 1970 年 1 月 1 号 0 点 0 分 0 秒的秒数。所以在执行环境中,函数会根据电脑的时区设置来加减相应的小时数,先转换为 0 时区,然后再进行时间距离的计算。

参考:

http://www.w3schools.com/js/js_date_formats.asp

起了个小学生式标题。

这东西又是浏览器历史的一桩恩怨……当最初的 HTML 标记式的语言结构逐步成形后,人们开始对网页内的互动有了要求。当然,这事本来并不难,所有的用户互动归根结底就是『触发事件 – 判断当前状态 – 执行相应命令』的逻辑,而 HTML 本身就已经通过开标签和闭标签组对的形式,很好地形成了后来被称之为『DOM 元素』的数据结构,理论上只要把触发事件分别加到一个个的元素上,或者按需加到某些特定的元素上,就可以执行命令了。

然后问题就来了。

由于 HTML 的表现是盒式结构,都是一些大框框包含小框框的情况。比如如下代码:

1
2
3
4
5
6
7
<div id="blue">
<div id="green">
<div id="red">
sometext
</div>
</div>
</div>

形成的 DOM 盒式包含结构大约就是这样:

无命名

当用户点击红块时,实际上浏览器是无法判断这次点击的意图的,也就是说,到底应该是点在红块上,红块对这次点击作出反应,还是点在绿块上,亦或是蓝块上。即使是三者都算作被点到了,三者都有反应,那怎么也得有个先后顺序吧。

有两种顺序都可以,一种是先子后父,先里后外,红绿蓝顺序;第二种是先父后子,先外后里,蓝绿红顺序。

两者都可以,两者都有理,然后老 IE 用的是前者,老 Netscape 用的是后者……结的梁子够多了,也不差这一个了。

于是新的协议为了兼容,提出了 DOM 事件流的三个阶段的设计,即……首先,都别争了,顺序就按『蓝绿红绿蓝』这么来吧……然后,这一顺序又分成三个阶段,第一阶段我称之为『下沉』,顺序为蓝绿;第二阶段『触底』,系统发现红色已经是最底层 DOM 元素了,第三阶段『上浮』,顺序变成了红绿蓝。

这三个阶段是有标准的命名的,分别是『捕获阶段』、『目标阶段』、『冒泡阶段』。并且严格来说,捕获阶段不包括最底层元素,而冒泡阶段包括目标阶段。盗图一张:

001108_Ry8q_214423

尽管规范上来说,要求捕获阶段只注册事件,而在冒泡阶段执行相应阶段。但事实上各浏览器在实现时,都允许在捕获阶段也执行相应的事件。结果就是,对于一个目标,有两次执行事件的机会。这在为 DOM 元素添加事件的 JS 函数里就写得很明白:

1
addEventListener(type, listener, useCapture)

其中第三参数就是决定这个事件是否在捕获阶段就开始执行的。

当我们使用 jQuery 等第三方库时,这一特性被 jQuery 很好地隐藏封装起来了,并良好地处理了各浏览器不一致的特性,使得我们可以通过 .click() 函数方便地添加点击事件,并不用考虑三个阶段的问题。

开宗明义:

一、死亡对你也许是一种震慑,但对别人不一定是。

二、贩卖人口在目前的量刑下已是重罪。

三、法律适罪量刑,并不是保护罪犯,而是在保护受害者不遭受更严重的伤害。

四,贩卖儿童的特殊之处,在于『孩子还活着』这点上,人贩和儿童父母的利益一致。这很别扭,但正是最能承载『找回孩子』这一希望的。如果一律死刑,那么孩子几乎是不可能找回了。


突然之间被鼓吹『拐卖儿童一律死刑』的给刷屏了。

在我的朋友圈里,要求拐卖儿童一律死刑的,一半是有孩子的,另一半是没孩子的。怎么说呢,有孩子的,多少可以理解爱子之情。没孩子还这样的,呵呵。善良得久了,脑子里只剩水和面了。

『今亡亦死,举大义亦死,等死,死国可乎?』

『民不畏死,奈何以死惧之?』

归根结底,在于你们安生日子过久了,就以为死刑是种多么大的震慑,但事实上未必。死对你也许是一种震慑,但未必对所有人都是。为什么叫『亡命之徒』,正是因为那些人并不把死亡当成是件无限巨大的震慑,而只不过是利益天平上可以衡量的一种损失而已。而法律,也并不像你想像的那样,是人人遵守违者天罚的无上神圣规则。其实在我看来,法律恰恰是与这些突破底限的罪犯之间的讨价还价而已。

『如果你做出怎样的行为,就可能会面对怎样的惩罚,』,这是法律的前半句,而更关键的是后关句,『如果你不做出怎样的行为,就不会有怎样的惩罚。

这才是法律的制定和执行中,更为根本和重要的一环,如果说前半句是在震慑犯罪者,那么后半句则是在拯救受害者。

如果抢劫就是死刑,那么确实不会再有单纯的抢劫了,只是必然会有大量的受害人死亡。因为受害人活着,只会对抢劫犯不利。如果强奸一律判处死刑了,那么所有的强奸都会变成奸杀。如果贪污受贿一律死刑,那么所有的官吏一但开口,就会迅速巨贪并转移财产。如果驾车撞人一律死刑,那么一定会造成大量的撞人拖曳血肉模糊。如果盗版一律死刑,……哦,这时大概又会是同一帮人跳出来说,凭啥死刑。

适罪量刑,是为了让罪犯每施加更多的伤害,就需要承担更重的刑罚,这样,当罪犯无论达到或者不达到目的时,都会出于利益考虑,不向受害者施加更重的伤害。

且问,如果你的孩子正在人贩手上,警察正在追捕,并且很有希望抓住了。你是希望犯人逃跑无望束手就擒呢,还是挺而走险杀了孩子自己再轻身跑路呢?正常来说,你都希望无论犯人怎样都行,自己的孩子能平安归来吧。然而你支持的却是『一律死刑』,你觉得犯人会乖乖交人?还是会友善地扔下孩子自己跑路?

你未免太过自以为是了吧。

再说一遍,适度量刑,是在保护受害者不遭受更严重的伤害。

再说两遍,适度量刑,是在保护受害者不遭受更严重的伤害。

再说三遍,适度量刑,是在保护受害者不遭受更严重的伤害。

那么,你为什么在拐卖,甚至是购买儿童上,就支持『一律死刑』了呢?除了伪善和杀人欲,我没看见别的。

我真心觉得,之前无论转发多么脑残的东西,雾霾也好,炸鸡也罢,顶多是为那些认真工作的人平添一些麻烦,或者伤害一下他们的感情,虽然难受,但不至于伤筋动骨。

但这次,你们这帮脑残,真的是想杀人啊。

一,在转发这个观点时,你是否查阅过现行法律体系下的量刑尺度?是否已经存在死刑的可能性。事实上据我所知,拐卖妇女儿童情节严重的是确实可以处以死刑的。注意,是情节严重。

二,你鼓吹过一律死刑,是否考虑过可能会造成的其它后果,比如犯人为了逃避罪责,直接把小孩弄死再逃跑的情况?

三,你如何确定以死刑震慑,就会让拐卖的犯罪率下降。如何确保不因为刑罚上升,导致贩卖小孩的价格升高,有更多的人挺而走险?同时因为一律死刑的存在,而造成受害人更严重的伤害。

这些事情,无法预测,也没法实验。

从更广阔的情况来看,『一律死刑』是有类似的现实映证的。在我国,运输、贩卖海洛因等强成瘾性毒品,超过 50 克,一律死刑。然后,你再自己去查查辑毒人员为此付出的巨大代价,他们的家人为此付出的代价。但区别在于,毒品的受害人是间接受害人,并不在犯罪过程中出现,不会有毒贩『残忍杀害抛弃自己手上的毒品』,无论打击贩毒多严重,都不会造成毒品受害者更大的伤害。但贩卖儿童却真的可能存在更严重的恶行,因为儿童是在人贩手中的。

事实上贩卖儿童最特殊的恰恰是,孩子活着才有利润,死了就什么都没了。在『孩子活着』这点上,人贩和孩子父母是利益一致的。这很别扭,但恰恰是这点,是最大的希望,也是我最反感『一律死刑』并叱之如此的原因。死刑只会割断最后的希望,把孩子的性命完全吊在人贩本已无几的同情心上,并让遇拐父母位陷于万劫不复之地。

我们应该做的,是改善儿童找回的渠道,建立更好的防拐防丢体系,改进儿童领养的现状,甚至邪恶地说,还可以『创造供给』,从那些虐待亲生子女的父母身边剥夺他们的抚养权,然后交给那些想抚养孩子的父母。

这才是正道。

而当法律失去了『更重的犯罪,会有更严重的惩罚』的惩罚能力,如何阻止犯罪者的罪行升级?指望死刑解决一切问题么?指望死刑阻止犯罪么?横竖是死,发什么善心?

死刑只会让人贩开出更高的价格,只会引来更多的亡命之徒拐带儿童,只会造成被拐卖的儿童非卖即死的惨况。

还是那句话,本来他们就是把自己的性命当作成本,价格更高只能让他们更疯狂。


观点:

一,只有死刑才能遏制贩卖儿童。

这条不解释了,社会运行自有规律,每个人都会选择最自己最有利的办法,键盘侠们也是,吹牛显正义,道德占高地,也不过是对自己的形象最有利罢了,哪管他人死活。

第二,你不是被贩卖儿童的家长,根本无法体会那种痛苦。

请问转发者们,你们是贩卖儿童的家长吗?我不想在这点上讨论。更可怕的是,还有真的孩子父亲评论说,『因为我不知道我孩子是生是死,如果被拐,相比于我无尽的搜索与痛苦,我宁可他死了』。

第三,失去孩子对家长来说比杀了他们还痛苦,所以一定要判死刑。

我不想在痛苦的程度上作辩解,这并无意义。

重点在于,以这种理由判断贩卖者应该施加何种刑法无疑是将孩子当作父母的一种私人财产,这种私人财产的剥夺对父母产生的伤害程度的大小决定了刑法的轻重。

这是荒诞的逻辑,因为父母对孩子是有监护权,但不是谁完全属于谁、谁是谁的私人财产的关系。人贩贩卖孩子,应以对孩子造成的伤害为主要量刑依据,这是我的看法。不然,孩子父母的痛苦,无疑也会造成父母的亲朋的痛苦,那么这份痛苦也要向罪犯赎回吗?

如果讨论的是精神伤害的罪名,通常也只关注直接伤害的那部分,而『通过对亲密关系或者试图建立的亲密关系进行打击从而伤害到某一方的感情』这种情况是难以处理的,孩子青春期跟父母闹别扭,是不是也让父母心如刀割,是不是也应该把孩子抓起来毙了?追求女神,女神爱理不理,是不是也应该把女神抓起来毙了。我明天就去找二马,他们不理我就让国家把他们毙了。

当然这是一个过于敏感话题,从政治正确性上说,如果父母不在这件事情上『比死还痛苦』的话,就不足以说明他们对于孩子的爱。然而就我个人看来,这种爱与仇恨无异了。这种态度甚至反映出某种现状,太将情感和希望寄托在孩子身上了,这种爱并不包含无私、尊重和理解,往往只是一种对家庭中所有人的负担。

最后,还是祝愿天下太平,祝愿务实理性的人,做事能不受傻逼的干扰,祝愿自以为好心,实际办坏事的人,始终办不成事,即使这恐怕很难。

前文: <很是喜欢这个微信表情包:小哥斯拉么>

么么出了第二个表情包,另外在 2015 贺年表情中也露了一次脸。现在她有了陪伴,体形也越发可爱,大概这是一个美好的结局吧。依然,我还是找不到作者,不知道哪里有卖衍生品。

么么 2:monmon2

肉肉哒 陪着你 抱抱 不理你
肉肉哒 陪着你 抱抱 不理你
不要啦 新年快乐 我要减肥 都怪你
不要啦 新年快乐 我要减肥 都怪你
好无聊 摸摸头 我错了
好无聊 摸摸头 嗨 我错了
亲亲 点赞 圣诞快乐 没问题
亲亲 点赞 圣诞快乐 没问题

然后是新年萌物表情包,只有一部分是么么:5f656f4dacb0cee887adc091619380c8

恭喜发财 身体健康 福到 发发发 万事兴
恭喜发财 身体健康 福到 发发发 万事兴
羊年大吉 暖洋洋 新春快乐 元宵快乐
羊年大吉 暖洋洋 新春快乐 元宵快乐

剩下是同一表情包里无么么的表情:

吃吃吃 心想事成 年年有余 红红火火 过年啦
吃吃吃 心想事成 年年有余 红红火火 过年啦
喜气洋洋 十全十美 发红包 吉星高照 恭贺新禧
喜气洋洋 十全十美 发红包 吉星高照 恭贺新禧
同乐 万事如意 抢红包 财源滚滚 一帆风顺
同乐 万事如意 抢红包 财源滚滚 一帆风顺
0%