1.lodash源码分析——deepclone
2.犀牛(RhinOS)CMS3.X任意文件下载漏洞(CVE-2018-18760)
3.为MediaWiki安装可视化编辑器VisualEditor
4.JavaParser是解析解析哪个国家的？
5.研究快速修改Unity构建包内的资源文件

lodash源码分析——deepclone

       lodash源码分析——deepclone，基于4..版本

       本文从源码阅读初心者的源码源码角度，一句一句深入分析lodash的公式deepclone方法，从入口函数开始，解析解析逐步解析每一个关键步骤。源码源码

       入口函数调用cloneDeep.js，公式cloudinit 源码通过掩码位判断是解析解析否进行深拷贝与复制symbol类型。

       在baseClone.js中，源码源码通过内部函数调用baseClone进行主要逻辑处理。公式先判断对象是解析解析否为普通对象，然后使用getTag方法获取对象的源码源码类型标识。

       getTag方法通过baseGetTag进行判断，公式获取symbol类型时返回symbol.toStringTag属性。解析解析现代浏览器支持返回特定类型标签，源码源码如内置对象类型或新出现的公式类型如Map、Promise等。对于自定义类创建的对象，若无特定标签则返回[object Object]。

       继续解析baseClone逻辑，重点在于针对不同类型的对象进行区分处理，包括数组、普通对象、函数等。函数和空对象返回{ }，不进行深拷贝。

       在处理复杂类型如数组和对象时，baseClone采用initCloneArray和copyArray函数优化拷贝过程。对于循环引用问题，通过构造栈结构解决，无溯源码燕窝保证了代码的兼容性和易用性。

       对于symbol类型，通过Object.getOwnPropertySymbols方法获取symbol的副本，确保深拷贝操作的完整性。

       总结，lodash的deepclone方法通过Object.prototype.toString.call得到对象的类型标识，根据标识进行针对性处理，同时解决循环引用问题，兼容现代浏览器的symbol类型。然而，对于function类型仍然采用引用拷贝，未进行深拷贝处理原型链上的属性。

       本文由某初学者撰写，旨在分享lodash deepclone源码分析过程，提供一个从入门到深入理解的路径参考。完成日期：年7月日。

犀牛(RhinOS)CMS3.X任意文件下载漏洞(CVE--)

       发现于RhinOS CMS 3.X版本的安全漏洞CVE--揭示了一个严重的任意文件下载漏洞。RhinOS CMS，作为一款功能强大的Web开发框架，提供了丰富的网站管理特性，如数据库访问、XML解析、购物车功能等。然而，download.php文件中的漏洞使得攻击者能够利用它下载任何文件，对系统安全构成威胁。

       要构建RhinOS CMS环境，首先从sourceforge.net下载源码，dz 应用中心 源码按照安装指示进行，尽管安装过程中可能出现乱码，但西班牙语系统用户可正常显示。安装完成后，修改stat命令进行检查。

       你应该得到类似于以下的结果：

       语法安装和配置已经完成。 注意：如果你使用云服务器的话，别忘了将安全组中的端口放行，否则还是会报错。

       好了，打开浏览器，输入`你的域名:`，页面如下：

       3、安装并配置可视化编辑器

       安装插件就简单多了，打开配置文件LocalSettings.php，输入：

       试着编辑一下维基页面吧。

       问题1、“编辑”标签和“编辑源代码”标签共存

       安装完之后，每个页面就会重复出现“编辑”和“编辑源代码”的标签，而当你点击任何一个都会默认进入到可视化编辑器中。

       MediaWiki官网的参数设置中有一个编辑模式的选项。

       解决方法：在LocalSettings.php中加入如下代码

       如果不希望在参数设置中显示“编辑模式”的选项，可以在上述代码中继续加一行

       2、除了条目外，是否能将可视化编辑器用在模板和其他命名空间

       除了主条目外，可视化编辑器也可以用于其他命名空间，比如你自己新建的命名空间，如下面的通用 管理系统源码MYTEST。

       3、错误：apierror-visualeditor-docserver-http-error

       在LocalSettings.php中$wgVirtualRestConfig['modules']['parsoid']那一段url如果你使用https则可能出现这样的错误，你可以将https改为http试一下。

       如果Parsoid和MediaWiki安装在同一个服务器下，那么最根本的方法就是将网址改成localhost ：

       参考文章：《 How to Install VisualEditor for MediaWiki on CentOS 7》、《 如何在CentOS 7上安装MediaWiki的VisualEditor》、《 VisualEditor安装笔记》

JavaParser是哪个国家的？

       !!!@@@

背景介绍

       JavaParser是一个Java语言的语法分析器，可以将Java代码自动转换为抽象语法树。它广泛用于各种Java修复和转换工具中。该开源项目最初由Federico Tomassetti创建和维护，已成为许多Java开发人员工作流程的核心组件。然而，最近发生了一件抄袭事件，使得该项目备受争议。

抄袭事件详细介绍

       年，Federico Tomassetti发现日本一家公司名为Nanzan Technologies发布了一个名为“Japanese JavaParser”的项目，而这个项目与他创建的JavaParser极为相似。在调查后，Federico发现该公司在未经授权的情况下直接将JavaParser的代码复制到了自己的项目中，甚至还在官方网站上明确提到了JavaParser。此行为明显侵犯了JavaParser的知识产权。

事件反应

       事件公开后，社区引起了极大的关注，许多Java开发者谴责Nanzan Technologies的侵权行为。在网络上，JavaParser社区发表了一份声明，声称他们的项目被侵犯了，并采取了适当的同花顺bbb指标源码措施。随后，Nanzan Technologies删除了他们的项目，但此举并未消除 JavaParser社区的不满。

影响

       JavaParser是Java开发社区的核心组件之一，已经被数千名开发人员广泛使用。该事件让人们对这种侵权行为的代价产生了重新认识。这起事件也教育了开源社区确保采用适当的许可证来保护其知识产权。JavaParser团队也对自己的代码库进行了重大更新，以避免将来再次发生类似事件。总之，这起事件提醒我们在开源社区中必须谨慎行事。

结论

       在互联网时代，软件知识产权的保护变得尤为重要。开源软件虽然为开发人员和用户带来了极大的便利，但也面临着更大的风险。JavaParser的抄袭事件向我们证明，即使你的项目只是在官方网站上发布，知识产权仍然可能受到侵犯。因此，大家应该专注于保护自己的知识产权，尽可能采用适当的许可证并遵守相关法律法规，以确保软件的合法性和信任度。

研究快速修改Unity构建包内的资源文件

       本文将探讨如何实现快速修改Unity构建包内资源文件的方法，目标是使整个操作耗时控制在分钟级别，且无需依赖Unity引擎。以一个Resource目录下的空节点Prefab为例，首先，找到其构建后对应的资源文件。预制体构建后，文件以prefab的guid命名，存放在名为Data的二进制文件中。要对这个Data文件进行修改，需了解其格式，但Unity官方文档并未提供详细的二进制文件格式定义，也没有提供将Prefab资源转化为Data二进制文件的API。因此，我们借助开源工具AssetStudio查看Unity Data二进制文件格式，并从源码中找到解析二进制文件的逻辑。

       我们得知，Prefab的二进制Data资源是SerializedFile格式，其解析逻辑位于SerializedFile.cs代码文件中。SerializedFile包含文件头和数据部分，文件头格式在Unity版本中如下所示。

       文件头格式包含了多个字段，部分字段含义可以通过测试推断。例如，当给Prefab挂载自定义脚本时，发现localSerializedFileIndex和localIdentifierInFile字段表示引用文件1中的第个对象，即全局游戏管理器文件中的第个MonoScript对象。通过对全局游戏管理器文件的分析，我们发现第个对象正是创建的脚本。

       了解SerializedFile的结构后，接下来需要解决如何根据Editor中编辑的Prefab替换构建好的包内对应Prefab的二进制内容。Prefab文件在Editor中以文本格式存储，格式为Unity修改后的YAML格式。我们发现，YAML格式与SerializedFile相似，都将树形结构的对象平铺化，并使用文件内的唯一索引进行引用。

       然而，YAML中的信息与SerializedFile格式并非完全对应，比如自定义脚本的信息，YAML中使用脚本的guid，而SerializedFile中使用的是全局游戏管理器文件中的脚本对象索引。为了解决guid到全局游戏管理器文件中脚本对象的映射关系，我们采取了以下思路：通过类型信息作为关联键，建立guid与文件内对象索引的映射关系。首先，编写脚本从Editor中获取所有类型信息，建立guid到类型信息的映射。然后，解析全局游戏管理器文件获取类型信息到文件内索引的映射。这样一来，就可以将YAML中的脚本引用guid序列化为localFileID。

       在替换构建好的包内Prefab的二进制内容时，头信息描述了每个对象数据的起始位置和大小。我们接下来关注对象是如何序列为二进制数据的。不同的对象类型具有不同的序列化格式，我们以GameObject类型为例进行介绍。

       每个Prefab节点包含一个GameObject对象，Inspector面板显示的名字、Tag等信息来源于GameObject对象。GameObject的序列化格式相对简单。在从YAML到SerializedFile的对应关系中，我们看到一些Editor环境下使用的数据在构建中不需要序列化。在SerializedFile中，挂载的组件对象使用Component指针数组表示，包含PathID和FileID信息。PathID表示对象的索引，FileID为0表示是内部文件对象。

       Transform对象也包含在每个节点中，其中包含Vector3和Quaternion数据类型，这些数据在YAML中以多维浮点数保存，在SerializedFile中同样以这种方式保存。

       在介绍更多的Unity内置组件类型之前，我们先关注最常用的自定义组件类型，即MonoBehaviour类的子类。MonoBehaviour对象在YAML中结构清晰，首先引用自定义脚本类文件，然后是所有可序列化字段的数据。在SerializedFile格式中，首先是指向自定义组件类的引用数据，接着是所有可序列化字段数据。组件类引用数据结构包括PathID和FileID。

       在测试序列化简单字段时，我们发现序列化的字段都是4字节对齐的。要实现YAML中MonoBehaviour字段的序列化写入，我们采取了一种方法，即通过反射从Unity工程中找到对应的类型，然后使用Mono Cecil库静态分析Assembly-CSharp.dll以提取类型信息。有了类型信息后，我们就需要考虑如何序列化。

       序列化过程有两种方向，其中一种需要了解Unity支持的字段序列化规则，筛选出类型的可序列化字段。然而，考虑到实现目标是脱离Unity工程的独立工具，我们选择另一种方案，即从构建好的包体中寻找类型信息。通过Il2CppDumper从globalmetadata中静态提取类型信息，我们查看Assembly-CSharp.dll以确认包含类型的字段信息。

       在处理其他Native Component时，除了GameObject和Transform之外，Unity还提供了丰富的原生组件。一些常见组件的YAML和SerializedFile映射关系如下所示。对于其他几十种原生组件的映射关系，需要通过耐心测试来摸索清楚。

       此外，Prefab可能引用贴图、字体、材质以及其他Prefab等外部依赖资源。构建包的测试表明，如果一个Prefab通过脚本引用了其他Prefab，如TestPrefab和TestPrefab，那么在构建的序列化文件中，头信息的externals会包含TestPrefab和TestPrefab的guid。序列化的脚本引用字段分别指向这两个资源。

       对于引用的内置资源，如字体文件，构建包内的资源文件为unity default resources。序列化的脚本资源值为特定格式，如{ fileID:2, pathID:}，对应的YAML引用信息为。

       对于内置资源，其type为0，且fileID为序列化后的文件内对象索引。因此，需要解决guid到内置资源路径的映射问题。由于内置资源数量有限且固定，我们选择先人工维护映射关系。

       在处理图集资源时，遇到困难，因为它没有将图集Prefab作为externals引用，而是引用了sharedassets0.assets文件。项目中存在大量sharedassetsXXX.assets文件，不知道如何从图集Prefab的guid关联到sharedassets0.assets文件。我们推测，Unity在构建过程中会擦除一些项目资源文件的guid信息，转而使用externals依赖形式。

       至此，研究暂时陷入困境。我们希望后续能有其他方法解决这个问题。本文使用Zhihu On VSCode创作并发布。