我的天

花了一个早上的时间写了两个Power Query的方法，主要是用于转换1~4层的标签和第4层对应的具体内容。其实如果有大表，我就是把那个大表分成两片，第1片用方法一处理，第2片用方法二处理，方法一跟方法二重叠的部分就是第4层的标签。

方法一，实际上我是把同一个步骤重复了三遍，分别是取第1第2层，第2第3层和第3第4层。这三个步骤分别对应的就是分类1~3。分类3所包含的内容实际上就是第4层的标签。在研究怎么整这个东西的时候，我只是做了第1第2层，后面那两个重复，我直接复制后修改里面的某些数字，就可以把东西重新定位，然后生成后面两个重复步骤的结果。三个步骤的结果出来了以后合并在一起，就可以直接加工出我想要的json格式。至于方法二，我感觉比方法一还要简单一些，因为实际上就只是做一个步骤而已，但是方法二有一个做超链接的过程，属于有超链接就做，没超链接就不处理。最后json的内容就是把方法一跟方法二的结果全部融在一起，最后一行手动删除一个逗号。

做出这两个PQ方案以后，可以让完全小白的人直接生成json，把相应条目复制到目标json文件，网页接着刷新就可以了。刷新这里可能会遇到浏览器缓存的问题，但这是后话了。PQ方案需要对电脑有要求，准确来说对office的版本有要求， Office 2016以下的可能会有点问题，即便是Office2016专业版也有可能出现某些状况，但我不确定状况一定会发生，因为我很少用那个版本office。虽然可能我一开始接触的Office365是基于Office2016的，但经过这么些年的迭代更新，我不知道现二者在Power Query上有什么差异性，在核心功能上会不会有一些变动。但是这个操作只需要那个处理网页数据的人做一次就可以了，其他人完全不需要涉及，所以即便对office有要求，那么在可以行得通的电脑上操作也就没有问题。主要是Excel数据转json格式的时候需要PQ支持。

Power Query的处理上，我主要在不新增列的情况下直接修改某一列的数据花费时间比较多，比如说在原有的数据上加上一对双引号。如果我要加的不是双引号而是其它乱七八糟的东西，可能我根本不会碰钉子，但因为双引号在PQ里是一个比较特殊的存在，准确来说在所有编程语言里，双引号都是很特别的存在。所以当你要自定义一列，在原来列数据的基础上加上双引号，那么实际上，你在写脚本的时候就得打4个双引号。有些时候你得用4个双引号，有些时候你得用3个双引号，我不知道为什么PQ就是不能让我用反斜杠，如果允许反斜杠的话，我就不会被双引号搞得非常晕了。把那些东西转化为json格式的时候，我必须添加大量的双引号。那个步骤虽然我已经很小心翼翼，但是也不免经常会有各种手贱的操作。另外一个让我手贱的原因是PQ的编辑器不知道为什么会自动给我添加双引号，有可能会给我添加双引号，有可能会给我添加半边括号，反正就是我不想它给我增加的，它老是很自觉不定时增加，于是到最后我不知道为什么出错了，结果发现原来是它给我增加了我不想要的东西。

最终，我花了一个上午实现了我的计划，感觉挺爽的。

网页里面的select和option，这两个东西估计是在一开始出现网页的时候就已经有。周三的时候我发现option的hover效果是无论如何设置不了的，你可以设置option的颜色或者背景，但是hover上去没有效果。你也可以通过css设置select的hover或者focus。该怎么设置这个option呢？最后发现是无解的，所以我又研究了一下其他人的替代方案，有些很酷的网站，他们用js写了个脚本，在option的上面又覆盖了一层由li和span组成的东西，所以你看到的特效实际上是有那些产生的，而不是option本身。那个效果非常的炫酷，但是你要引入大量的js，也要引入大量的css。漂亮是要有代价的，这是显然的，本来我已经想好，要模仿其中一个，结果却突然想到它的下拉可能就只有几个选项，但我的下拉有可能有十几二十个选项。我选定的那种款式，默认没有滚动条，所以这该怎么办呢？所以我只能放弃。

周四当我搜索的时候，我又发现了一个英文网站里面用了纯css实现了option的hover，之所以可以做到这样，是因为他在select那里使用了onfocus之类的事件。为什么onfocus之后就可以设置option呢？之前option做不到的东西，加入了那些事件以后就变得可以做到了。接下来你就可以在option里面设置你想要的东西。本来我觉得自己有救了，之所以说本来，是因为后来我又发现了一些很无语的现实。

做的这个静态网站，我觉得受众大多数是用手机打开的。虽然可能他们准备资料的时候是在电脑旁，但是要查询资料的时候，估计他们不会先打开个电脑。所以这就意味着这个网站的开发我得兼容手机和PC。select和option的展示方式，不同浏览器不一样，手机和电脑不一样，不同的手机品牌也不一样。非常有可能在PC上的效果已经设置得如我所愿，但实际上到了手机上还是自动套用了手机经典的款式，所以等于做了个寂寞，与其这么大费周章，还不如直接放弃治疗。同一个手机，不同浏览器出来效果不一样；再换一个平板，虽然内核都是Chrome， 但实际上又会有差别。我不知道那些人是如何做到兼容这有一切的，起码对我来说这实在太难了。所以我只能尽量做到在不同的设备上效果都过得去。所以在选择字体大小上应该用什么样的比例，我又研究了一番。如果完全就只是一个PC的网页，设置好我想要的也就可以了，大概差不多也就那些字体大小，但是手机上看到的东西我感觉比PC上看到的小很多，于是我不得不把字体放大，但是放得太大，PC上就像一个搞笑的存在。以前body的font-size我都是用绝对像素。这一次我不得不采用相对单位。PC上点击用的是鼠标，图标再小，你都可以准确按到，但手机上你用的是手指，所以那个按钮必定不能太小。这些矛盾的东西，当你不是真的碰上的时候，是不会想象得出来的。

最后，我感觉大概差不多就那样了，剩下的事情就只是等待最终的数据源。

花了大概两天的时间，终于做出了我想要的那种级联分类下拉的效果，但实际上我的判断是根据上一层筛选的，所以如果上上一层不一样以我现在的判断结构，没办法分辨出来的。如果要把这些都分辨得清楚，那么json的结构里就得把每一条记录所在层都写清楚。如果那是1层，那么234可以留空，但如果那是4层，那么1234都得有。我的json文件现在结构非常简单，总体来说是一个数组，每个对象只有三个部分，一个是name，一个是class，一个是content。name是这个对象的名字，class是它所在的层，content分为两部分，如果不是最后一层，那么content就是下一层的name的数组，如果那是最后一层，那么就是它所包含的所有信息。

第1层比较简单，就是把属于第1层的数据添加到第1个选框里。第2层是我纠结得最久的，因为搞不定这个后面的也搞不定。一开始我的计划是首先判断第1层是有数的，然后获取第1层对应的content。然后开始数组的历遍，把名字跟content里的一致且层数是2的name选出来，然后把它们逐个添加到第2层的选框里。第2层开始，这个操作是第1层的选项发生了变动后清空第2层，然后初始化选项框。第3层和第2层做的事情是一样的，无非就是2变成3，然后就是清空的时候，如果到达了第3层，第2层清空的时候，就得把第2层跟第3层都清空了。我的设定是到第4层，第4场就是结果，所以当第4层被确定下来以后，第4层的content就需要展示具体内容。同理，如果我1234层都选好了，然后我又变动了第1层，那么就得把234层以及最后的结果全部清空。这些操作都是很规律的，我感觉可以通过循环或者递归之类把这说清楚，就不需要一次又一次重复这种事情。准确来说，我感觉用递归更合理一些，但是因为我的递归学得实在很糟糕。学python时候，递归那一章从来都是让我瑟瑟发抖的，尤其是要我画雪花图案的时候，简直毛骨悚然。有了那些清空和初始化的操作以后，我就彻底避免了百度AI自动生成的那些bug。现在我的这个方案的确挺傻的，但我觉得可以通过递归的改写让它没那么傻，这个方案之所以可行，其中一个很重要的地方在于起码以我手头上的资源以及我的技术，我可以生成出对应的文件。虽然可能会有点麻烦，但起码可以实现。首次生成会让你有点望洋兴叹，但持续更新的难度不大。

核心部分基本解决以后，我要开始进行UI美化，进而发现，原来CSS进化了那么多年，select下面的option依然没有可以轻易被控制的方案。这么一个死胡同，居然被我撞上了。

要做一个报销指引的时候，我首先想到的是做一个Word，然后再做一个目录，那么不管你前面有多少个分类，对这个Word和那些目录都是不受影响的，所以实际上就是把需要的东西全部都分在一页一页里面，然后就可以了，目录这种事，是由Word才能完成的，然后可以选择到底得显示到什么分类。目录这个东西，你可以把它当做是一个页码的指引，你也可以把它当做是一个超链接。无论哪一条，你都可以直接找到你要找的那个东西，如果你操作足够熟练，甚至不需要查、不需要肉眼找，只需要调出查询框，然后直接到达。报销项目页面包括了要完成这个报销需要准备的所有资料，有些表格是需要填写的，有些资料是需要预先准备的，比如各种合同、发票之类的东西。需要填写的表格我感觉应该有空表和范表，都带有超链接。这些表格不需要在Word里体现，只需要把空表和范表都放在Word同级或者下级的文件夹，通过超链接就可以直接到达。我感觉Office的超链接应该可以做到引用相对地址，万一真的做不到相对地址，用还可以把那些需要填写的空表和范表做一个排序，给一个序号，在Word里面把这些表格的序号给填上去，同样一目了然，非常快速就能找到你要的表格。这样的操作，谁都可以做。增加修改很方便，因为索引是系统自动完成的。这个也可以保存为PDF，以防有些人手贱，修改了某些东西。保存为PDF之后，超链接依然是可用的，至于那个PDF会不会自动根据Word生成一个一样的PDF目录，我不太清楚，万一真的不行，也可以跟根据Word的目录手动生成一个PDF的目录，可能一开始的时候不太习惯，习惯了以后PDF的目录也会很快完成。总的来说，我觉得Word的这套方案非常实在，无论大家喜欢用电子版，还是喜欢把Word的全套东西打印出来、用纸质查阅都很方便。

我不负责这个项目。一开始被委派了给予这个项目技术支持的人用的是Excel。因为她太熟悉Excel的超链接以及数据有效性操作，所以做了一套级联下拉的东西出来。这其实也没有什么问题，但关键是报销项目的具体附件她以二维展开的方式加在各级分类那里。一直以来我都觉得人肉实现二维操作是非常繁琐的，尤其是当你的附件超过你的显示器的程度，你会找得很麻烦。无论是分类作为列，还是附件作为列。最终的结果都要你在茫茫的东西里找你要找的东西，首先通过一个级联下拉搜索得出某个报销项目，然后同时会出现完成这个报销项目需要准备的附件。接下来她把这些附件全部都设定了超链接，这些超链接对应的表格全部都在这个Excel里面。我已经不记得我到底说了多少个全部。这个东西的维护，一般人不是说上手就能上手，这里里面可能有几十个空标或者范表。报销的人还得懂得在一系列的表格里把自己要的那个复制出来，这个操作可能超越了绝大多数人的能力范围。他们会复制一个文件夹，也会复制一个文件，但要在Excel里把其中一个工作表复制出来，而且还不能改变里面的格式，这个操作能难倒来报销80%的人。我没试过，设定了有数据有效性的Excel转化为网页或者PDF之后会有什么效果，转化为PDF，估计就没有然后了，转换为网页还能进行数据有效性级联下拉操作吗？我觉得这条路不太靠谱，但是直接跟她那么说，又好像打击了她的积极性。

最后我只能悄咪咪地自己努力学习jQuery+Json，努力憋一个网页的大招出来。

前段时间就被网友告知我们快要搬家了。搬家其实也没什么，但关键是网友已经忘记了账号密码。发邮件给服务器供应商，根本就没有回应。理论上找账密这种事情是很常见的，但为什么居然会没有回复呢？服务器外国，虽然我们的网站上也没有什么秘密，但如果突然有一天他们宕机了，我们又访问不到，丢失的就会是我们一直以来的心血，准确来说可能是我的心血，因为估计极少有人会像我这么痴迷于每天都写blog。虽然非常惋惜，但实际上我自己的内容倒还有纯文字的备份，只是不太容易查找我想要的内容，也会丢失掉所有的媒体文件以及网友的回复。

在我的印象之中，wordpress的经典搬家是需要在服务器那里把网站的内容拷贝出来，然后再去数据库那里把数据也打包出来，接下来就是到新的服务器那里，把网站内容复制上去，把数据库内容重新导到新的数据库里面。最后的步骤就是在域名那里重新做一个DNS的指向，但是这一个倒不是非常关键，因为用IP地址也能访问得到。对我这个基本上不会有什么浏览量的个人blog来说，外人一两天访问不到无所谓。

我想都没想过，我的合伙人居然把账密忘记了，这实在让人觉得非常的无语，所以如果按照wordpress常规的搬家程序，这个家是无论如何搬不动了，但现在有wordpress插件能实现全站搬家。1月的时候我就试验了一下，把网站的内容打包出来，大小是500多MB。他们的搬家方法你基本上不需要用什么大脑，把东西从原来的地方打包出来，然后新建一个wordpress，再把东西再导进去就可以了，但这个步骤到底行不行，会不会有什么幺蛾子？在没有测试过之前，我是不敢直接在网络上操作的，毕竟文件的大小摆在那里，没必要浪费时间。所以我需要做的就是用XAMPP在本地建立一个wordpress的运行环境，然后在本地建一个新的wordpress，然后尝试一下，把数据导进去。

在本地用XAMPP建wordpress对我来说已经不是第一次，但这一次，在win10之下，我发现了一个非常神奇的问题，理论上本地操作速度应该很快，但实际上打开一个页面居然要转上好几分钟，于是我不得不寻求帮助，结果发现首先第一个拦路虎是Windows Defender，那个东西是一个很大的罪魁祸首，所以首先我得在那里把XAMPP的文件夹设置为例外，第二个拦路虎是Apache的端口默认是80，但是80端口容易跟其他东西形成冲突，所以我把那个端口改成了8080。端口改掉了以后，在浏览器那里，打开本地的网站会出现警告，但是忽略了那些乱七八糟的东西以后就很顺利了，网站是秒开的。在我印象之中，以前我使用XAMPP的时候根本没有设置过MySQL的密码，但这一次我进行了设置，因为实际上在新建一个wordpress的时候需要我填入MySQL的密码，但XAMPP的MySQL默认没有密码。所以以前我之所以没有遇到这个问题，是不是以前的教程默认密码那一栏直接留空？

试验证明，那个搬家插件能非常快速顺利地把整个网站挪到其他地方。基本可以这么说，全部东西都挪过去了，起码我测试的部分都挪过去了。一开始的时候网页会出现404，我觉得可能是某些数据没有完全索引到位，当我在后台检查一番以后，再回到那些之前开不了的页面，发现又全部都可以了。可能在数据库方面，需要一定的时间去建立某些映射关系。除了出现404以外，还有一些warning的地方。搜索之后发现原来那是PHP的一些提示，当某个变量没有声明就开始使用的时候，就会出现那些warning，所以我看到的结果是我要的数据都生成出来了，但是那些数据前面会有一段warning，然后我就在自定义模板的functions.php那里把那些有warning提示的自定义变量全部都先做一个null初始化，这样非常傻瓜的操作以后，那些有warning的地方全部都警报解除了。

试验证明，用这种搬家方式是完全可行的。因为我是在本地测试，所以我把上传文件的大小改为了600MB，但如果我在新的服务器上做这种上传操作，服务器会不会允许我上传那么大的文件呢？万一真不允许我这么干，我还有第二个方案，就是先把导出的文件在本地转化为一个完整的wordpress，再把本地的网站和数据库分两片提取压缩，然后再上传到新的服务器。这是一种曲线救国的方法，应该没有问题。

自己的blog有救了，感觉终于可以松一口气。