我的天

不知不觉好像我已经快一个星期都没有碰python了，原因是在家的时候我懒惰，在单位的时候，一心在整理各种各样的数据，也正是因为我正在整理数据，所以其实在我的骨子里是念念不忘想使用python这个大招的。在数据处理方面。我觉得，我正在用Excel人肉操作的那些，如果以一个正确的方式丢给python，那绝对是几秒钟就能完事。明明我知道可以这么干，但现在我还没到达那个境界。

昨天我整了一个巨长的公式。在最开始的阶段，我在普通的Windows记事本里折腾，但是当公式嵌套得越来越多以后，显然普通的记事本把我直接看晕了。我把那个东西放回Excel，但实际上Excel这个怪物根本不给我显示到底那些一对又一对的括号谁跟谁匹配。我也试过把那条长长的公式放到VS Code里，我随便打了个py文件往里面放Excel公式。虽然某些地方高亮了，但是括号匹配还是很不行。如果那不是一个Excel公式，而是一个python文件，我早就给它写很多注释、搞很多回车了。不就是个嵌套了三层的if嘛。但实际上，如果这是在python，完全可以不嵌套，用三组平行的if就解决问题了。最终，我把那条很长的公式贴到了Notepad++里。经过一番折腾，我觉得Notepad++才是最适合编辑Excel长公式的工具。虽然Notepad++不能自动生成成对的括号，但是在判断括号对应性方面，我感觉已经足够了。他们会把成对的括号用加粗的红色显示。当你选择这一边的括号的时候，那边的括号就红色加粗了，这样我就能搞清楚自己编辑到了哪一层括号。习惯了用python之后，什么括号，什么使用范围之类的东西全部用冒号、用缩进就解决了，回到Excel里要用一句话表达，本来用三句短话就能表达清楚的东西的确挺烦人。为什么Excel编辑公式就不能用回车，不能用缩进解决问题呢？如果有几个回车的话，显然那条公式到底在表达什么就很明白了。在Excel的某个单元格里回车，那就是要执行公示的节奏。如果是数组公式，你还得用组合键结束。有时我实在不明白他们为什么非得一定要用组合键呢？为什么不能在公式外面加一个什么函数包裹，让软件明白就在执行数组公式呢？

习惯了python的简洁与人性化后，回到Excel让我各种不习惯。在python里，单引号和双引号都可以用来表达那是字符串，但Excel要表达字符串，要表达某些固定格式，必须用双引号。另外一个人让我不习惯，因为我已经彻底忘记的就是在Excel里面不等于用的是<>，而在其他编程语言里面，不等于的表达方式是!=。所以当我在Excel里使用!=的时候，Excel懵逼了。于是我不得不去搜索，进而发现是我自己搞迷糊了。还记得小学的时候，家长们总担心孩子如果一边学汉语拼音一边学英语会不会张冠李戴，用汉语拼音来读英语或者用英语来读汉语拼音。这是两种彻底不一样的东西，虽然他们的最终结果就只是个发音而已。我是小学一年级开始学汉语拼音的，三年级的时候开始学英语口语。在我开始在学校正规接触英语之前，我的汉语拼音已经很熟练了，而在我接触编程语言之前，我接触过Excel，但只是接触过而已。对二者的深入了解几乎可以说是平行发展的，所以混淆二者的某些基础用法我觉得可以理解。

最终，我把那个我想做到的效果用一条很长的公式表达了出来。那条公式针对的不是具体的某些单元格里面的东西，所指代的位置全部都是相对的。所以根本不存在拖拉以后会出现状况。有了这条公式我就彻底做到了对某个仓开始入库、结束入库以及期间库存精准定筛选定位。

那条长公式在成功整出来之前，我先在纸上列出了几个条件。代码这种东西是非常讲究思路的啊啊啊。

先画一个正方形，然后画一个正多边形，接着画一个圆形，最后画一个圆弧。从思路上说，再简单不过了，但实际上实施起来的时候，我还是花费了一点心思，但这些东西跟之后的用圆弧画出三个花朵比起来，我算是轻而易举就完成了的任务。后来的花朵之所以耗费了好几个小时才终于搞定，倒不是因为问题本身有多难，而是因为其实我没想通那些数学上的问题。我要画一朵花，花是由花瓣组成的。我画的那朵花是规则结构。那么画完一个花瓣到下一个花瓣的时候，角度我应该如何确定呢？这个问题很简单，但实际上我却在这里兜了无数个圈。我在那里瞎猜，所以很浪费时间。有无数次，我想直接去看答案了，但是我还是控制住了自己。当我终于画出一朵花，并在里面测试无论花瓣是胖是瘦，是多是少，我都能画出来以后，接下来我考虑的是如何一次性在一个面板上画出三朵花。画出一朵跟一次性画出三朵，其实已经非常接近了，但要怎么实现，还是费了一点心，因为某些函数的应用书上根本没说。我去网上稍微搜了一下，发现直接搬过来，而且是在没有看到例子的时候就搬过来行不通。最终我用了COPY大法，一次性画出了三朵花，虽然花的大小跟要求的有点差别。当我看过答案以后，我觉得这种差别是完全可以理解的。胖瘦跟大小是由他们设定的参数决定的，那些参数我们不可能知道。我只能模拟出个大概比例，要我完全模拟出一模一样是不可能的。

小海龟这个东西是一个画图的玩意，但是那又不像艺术家手里的画笔那样随心所欲。那是编程出来的，编程出来的东西还是有大神可以画出个小猪佩奇，但这些做法正如某些大神能用Excel的单元格画出他们想画的任意东西一样。

玩过成年人常规的编程以后再去搞这个小海龟，我觉得最难的地方在于数据的运用。你该怎么处理那些数据？难就难在那些公式设计上面。我不知道为什么Think Python 2这一章要这么整人，但也正是因为他们把我整得很惨，所以我在函数调用上面的确有了一些思路，而那种感觉是从前老师又或者我自学的课程里从来没接触过的。这些才是最核心的东西！为了让我懂得这个，他们祭出了从来都让我很崩溃的小海龟。

现在回想起来，为什么小学的时候小海龟会那么容易让我崩溃，估计情况跟现在差不多。在解决问题的时候我没有把那个箭头当作是一条数学题，一定程度上我把它当作是一个游戏了，所以当我不可以一口说出答案的时候，我首先开始做的是瞎掰，折腾好长时间以后我才终于静下心来，用脑子去考虑，这到底是怎么回事。所以可能某些东西的实现并不难，但是因为我耗在瞎掰上面的时间太多了，简直把我搞得慌张了，所以我会对那个东西瑟瑟发抖。把大问题解剖下来变成小问题，再逐个击破，我应该能很快的发现我的问题所在。

战胜人生中曾经不敢去面对的，非常有意思。

时间用在查找代码上去得特别快。感觉问题还没解决，时间就已经溜了。大体上看，就只有几个大问题需要解决，但实际上那些东西是完全没有头绪应该怎么去做的。昨天我花了一个下午的时间去处理comments.php。那个模板用来设定在哪里显示评论，哪里显示评论框，这其中还不包括评论框里的具体格式。看上去这是非常简单的事情，实际上，还是要考虑好几个问题，但显然，10年前，做那个模板的时候，我没有在comments.php这个问题上纠结，我顶多是往里面放了一些我设定好的CSS，所以那个部分的逻辑到底是怎样的，我没去修改，沿用的是某个模板。实际上我用的那个模板是不是标准的，我也说不准，因为我实在不记得当年我用作改造的模板是哪一个。因为通常WordPress的官方模板都非常简单，甚至可以说简单过头，于是你不知道该如何在那个的基础之上改造。大概之前，我的那个comments.php测试的时候，我只是考虑了一般情况。但除了正常情况，WordPress里还是会有一些极端情况，比如说某篇日志被设计为密码可见。无论是日志还是评论，在输入密码之前都应该是一片空白。那个模板就很神奇，日志部分已经是提示输入密码才可见，评论部分直接不显示就行了，但实际上，那里居然在会提示一次输入密码才可见，显然这就是画蛇添足了。让我纠结的时间最长的是嵌套格式的代码。因为正文部分我分为左边和右边，左边是文章的主体以及评论框，右边是边栏。这两个板块，一个是float向左，一个向右，一旦代码嵌套不合理，右边的边栏就会进入左边，又或者直接消失，也有可能是因为缺少结束嵌入代码，所以网页底部的东西飞上去了。要解决这些结构格式上的问题，就首先要搞清楚，那些php代码的开始结束位置。比如说某篇文章设定了不允许评论，但是对于已经有的评论，你还是要把它们显示出来，然后在最后一条的那里显示不许再评论。之前我根本没有测试过不许评论这个功能，显然当我在撰写日志的时候设定了不允许评论以后，之前的模板相应网页会出状况。而之所以这样，是因为默认的模板里面我只在if下面添加了足够多的格式结束标签，在else里面没写。不许评论就是else的部分，判定函数应该是评论是否开放，但实际上，不允许评论这句话从结构看来，应该是放在评论列表的最后。这样的风格才会统一，因为有些时候，不许评论之前可能文章已经有评论了，如果硬生生地把那放在允许评论就有评论框，不允许评论评论框消失并写着不允许评论，那样就太生硬了。

我花了几乎一个下午的时间去处comments.php，最后终于搞清了里面的逻辑关系。为了让那些if跟else，以及endif能更好地维护，我在上面做了很多注解，基本上每个的那里我都会写清楚了对应的是哪个，同时我也进行了缩进。那么以后找的时候就不会那么头痛。如果写代码的人用的是大括号，显然就不需要纠结endif对应谁。我也不知道为什么那个人不用大括号，在没有标注也没有缩进的情况下搞清那些东西真的好费神。

纠结不是毫无用处的，这会让我变得更强大。

昨天晚上收到Lei的这些回复，彻底死心了……

Lei
告诉你一个处理方法，将最外围的a标签干掉，换成div什么的，让DOM结构正常化。然后在外层的div上绑click事件，阻止浏览器本身的事件，然后用JS将页面跳转到想要的页面。
19小时前

Lei
看到DEMO终于知道怎么回事了。因为你的a标签里面还嵌套着a标签，这用法本身就是错的（看来画廊模板真的很烂），所以浏览器解析出来的DOM结构就是错的。用JS去A标签，也是在错误的DOM树上修改，就不可能正常了。
19小时前

原来我的瞎想一开始就是错的，难怪……所以虽然我已经很努力了，但还是没有实现我的目标，因为我的方向根本就是错的。昨晚看了两个把“span”利用JavaScript当“a”用的例子（例子1，例子2），结果发现纯文字链接没问题，加上非文字部分就歇菜了。估计是某些判断句所设定的非空与不是常规字符串有空格回车什么的东西产生矛盾。对JS可算是一窍不通，看来这回，我真的很有理由认真地学学JS了。

HTML、CSS、JavaScript、jQuery浏览器端的神兵利器，外加服务器端的PHP和SQL，哇咔咔。如果当初我读的是网络工程神马的，估计会很神奇，不过如果我的专业真是那个我就不会花那么时间激情澎湃地像现在这样去学习了。

今天没搞懂是怎么回事，库里有一帮人在拍片子，整个下午就耗在当群众演员上，外加早上一回来就说开神马会，结果，一天就这么被浪费掉了，多可惜啊～～～

明天是Raw，是Alberto Del Rio vs. CM Punk的WWEC rematch，对结果，我不存在丝毫的幻想，我只希望他们能给出一场精彩的比赛，足矣。可以没有头衔，但不可以没有血性，哪怕当个跑龙套的jobber！

不知道推迟了1个多月的演讲明晚会不会举行，真讨厌！

很傻很天真的以为用正则可以轻易提取出div里的层层嵌套div，结果囧得厉害。div的开头通常都带有class或id，唯一，且容易辨认，但div的结尾，清一色的“/div”，真会搞死人。网络上流传的提取div版本貌似都不太可行。在一坨里提取一堆只是第一步，第二部还得把提取到的内容xml数组化。

其实呢，我也有想过一开始就对所有内容xml数组化，不过，信不信由你，从最开始那层<>到我要提取的那些内容少说也有15层，而且如果那些网页设计者好心加一层或减一层，我又得慢慢摸到底哪里出问题了。所以，用xml数组化是个思路，但“解剖”源数据的工作量不少且维护困难。毕竟，这不是5层，这是15层+啊！怨念那些穿那么多层衣服的网页。

正则难提取嵌套div，xml太郁闷，咋办呢？

我还有一个很天真的办法，手动选取要提取部分的代码然后贴到程序里提取。这么一来就解决了难提取困难的问题，当然啦，都手动干了，还有什么难不难的，这个办法很低级，但一定可行。

怎么办呢，怎么办呢？！

应该是我想得还不够深入，再花点时间动动脑筋好好琢磨琢磨吧。

今天很坏地想到用正则提取，table输出，然后直接Excel粘贴保存，早上还在兴奋这个伟大思路，下午就发现正则把我卡死，生活真是个悲喜剧。

别囧，我有的是时间，一定可以的！