我这个博客就是用Typecho搭建的。刚才把var改为了core,把usr改为了exts,。

这俩目录其实在第三篇分析文章里讲过,分别是Typecho的核心类,以及插件和主题的目录,那么既然是核心类,那就是core里;既然是插件和主题,那就是对这个核心类的改进和增强,便于开发者进行二次开发,所以就是扩展exts

其实这个exts里,还有隐藏的设置,包括语言包(langs),备份(backups)和上传目录(uploads)。这些都是在改这个目录名的时候发现的隐藏设置,如果不看代码,是不知道的。这个对开发者是真的不太友好。

我会考虑增加一个vendors目录,把一些优秀的第三方库涵盖进来。

鑫鑫小店这个项目里,我走得更远,更激进,把core目录下的三个目录也改为lowercase了。然后,我发现了一个神奇的事,就是所有的class仍然可以正确加载。

Typecho的类加载机制是这样的,Typecho_Common::init这个函数,把所有的类名都做了处理,下划线(_)都被\替代了,就把className转换为php文件的路径了。我使用print_r函数把所有加载的className和转化之后的路径都打印出来过,都是首字母大写的,比如Typecho_Common,路径就是Typecho/Common.php。但仍然可以在typecho这个lowercase的目录里找得到这个Common.php文件。

但是,同样的事,如果在本博客的项目代码里做,就会报错。

所以到此为止,事情就变得非常因吹斯听了。

这里的问题很明显,其实就是,为什么一个项目可以,另一个不可以? 本质上都是Typecho!!

这里面就涉及到了一个不常见的问题,就是case的问题。其实case不仅分为case sensitivecase insensitive,还有一个分类,就是case preservation或者case preserving

这到底是啥意思呢?

macOS为例,这个操作系统用的是Apple File System (APFS) ,这就是case preserving,就是说,文件名和目录名,会保存大小写的信息的,比如mkdir Test,新建出来的目录就是Test,但其实这个本质上test是一样的,就是说你再继续mkdir test会报错。同样的,你可以touch test新建一个文件test,然后你再继续做touch Test会报错,不允许你新建一个有同样拼写、仅仅大小写不同的文件。这就是一个case insensitive并且case preserving的系统。文件名和目录名都同样是case insensitive并且case preserving

Windows系统也是同样的,

https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

Case sensitivity

Unlike Linux, Windows file systems are by default case preserving, but not case sensitive. In actuality, Windows and NTFS do support case sensitivity, but this behavior is not enabled by default.

但Ubuntu用的是ext4 filesystem,你可以touch test之后,再touch Test的,没问题,不会报错。

这个时候,其实我就比较困惑了。这可能是个答案,但还是没法回答这个问题啊。对不?为啥两个项目,一个可行,一个不可行?

暂时没有答案。

补充

这个我刚才对最新版的Typecho做了一个实验。简而言之,最新版Typecho在解析文件的路径之后,虽然首字母仍然是大写的,但已经不区分目录名和文件名的大小写了。我新添加了2个类,一个文件名大写,一个文件名小写,路径名都小写,统统可以被加载出来。

可能是我这个博客的项目在2018年3月份搭建的,那个时候的老版本可能还区分大小写。

至于到底哪里改了之后就不区分大小写了,看了半天git log也没看出来,commit message非常非常模糊。

标签: Typecho, 源码分析

添加新评论