# hexo blog 使用 bug 问题记录

# hexo d 出现 "warning: LF"

先说结论，出现如下的警告，其实是可以直接忽视的，不会影响编译后的结果

网上能 Google 到一大堆解决方案都是千篇一律的，将 core.autocrlf 设置为 false .
这样可以直接解决警告提示，但是很显然，全局化的处理必然会带来更多的隐性问题
所以，还是很有必要去弄清楚为什么，然后再找出合理的方案解决这个问题

# 分析

这和个问题的本质源头和 git add 出现 "LF" 警告是一致的
在 Windows 中使用 CRLF ( \r\n ) 做作为行尾符，而在 Linux 系统中则使用 LF ( \n )
CRLF 即 Carriage-Return Line-Feed 的缩写
Git 不修改文件内容，但默认会将入库的文件的行尾符设置为 LF, 会将检出的文件的行尾符设置为 CRLF, 在执行时出现上面的警告
工作目录中的文件的行尾是 LF, 但是这里在即将入 Git 库之前会将 LF 转换为 CRLF, 所以给出 LF will be replaced by CRLF in <file-name> 的警告
其实其目的是在告诉我们，源文件不会被修改，但是在 git 仓库中的文件 LF 会被设置为 CRLF.
因此在 "LF will be replaced by CRLF in <file-name> 警告后面往往会有一句 "The file will have its original line endings in your working directory."
所以 core.autocrlf 的配置是用于检测跨平台的，如果将其设置为 false 则可能出现一些很难发现的 bug
例如，我在做 ftp 开发时，ftp server 是运行在 linux 上的，而从机 MCU 开发是在 windows 上实现的，在新建文件夹命令中多出了一个空格，使用 windows 的 ftp 客户端去查看时跟本无法辨别，而在 linux 上会显示出一个 \ 的空格，这个 bug 查了半天

而现将 core.autocrlf 的检测关闭，最直接会导致:

pull linux 文件到自己的 windows 环境下用记事本看的话会出现黑点
Windows 里的文件在 Mac 下打开的话，在每行的结尾可能会多出一个 ^M 符号 (未验证，穷鬼没有 Mac, 据说 Mac 投奔了 Unix)

# 解决方案

由上面可知，暴力的全局更改为不检测并不可取，那么有没有什么合理的方法呢？
很遗憾，当必须跨平台处理协作的时候就不能关闭
一般来说 git 的 Windows 客户端会默认设置 core.autocrlf=true (可通过 git config core.autocrlf 命令查询是否默认 true. 如不是 true, 通过 config --global core.autocrlf true 命令设置该属性为 true)
而 core.autocrlf=true 有以下 3 个功能来避免我们出现我们前面分析时所述的问题:

在把 modified 修改过的文件 git add 到暂存区 stage” 时，Git 自动把 LF 转换成 CRLF, 并给出那条警告 "LF will be replaced by CRLF"
在把 modified 修改过的文件由暂存区 (stage) 提交 (commit) 到版本库 / 仓库 (repository) 时，Git 自动把 CRLF 转换成 LF
在用 check/git checkout 切换到指定分支或 git clone 克隆远程版本库” 来加载代码时，Git 自动把 LF 转换成 CRLF
我们博客属于第一种

不过对于我们只写博客不进行跨平台处理的情况的话，还是有一个建议可以在使用编辑器的时候，将编辑器的换行标识符进行默认设置
这里介绍 vscode 的解决方法

vsocode 的的右下角设置为 CRLF
每次都手动设置就非常的不合理，所以可以去工作区的设置中设置默认的文件换行方法，这样就可以避免出现需要警告了
当让也可以在 .vscode 文件夹中的 setting.json 文件中添加 "files.eol":"\r\n"

# 知识大爆炸

# CR-LF 和 LF 区别

LF: Line Feed 换行
CRLF: Carriage Return Line Feed 回车换行

早期的机械打字机上个名为 **「字车」(Typewriter carriage) 的部件，类似于现在的光标，打一个字符，字车前进一格.
而打完一行后，则需要让字车回到起始位置，这就是 Carriage Return** 键最早的作用，因而被直接翻译为 **「回车」**
虽然回车键的功能已经不止 "倒回字车" 了 (例如，泄愤的大回车键，狗头), 但这个译名保留了下来

# '\r' 与 '\n' 的起源

这最早起源于电传打字机，这是一种远距离信息传送器械，通常由键盘、收发报器和印字机构等组发报时，按下某一字符键，就能将该字符的电码信号自动发送到信道；收报时，能自动接收来自信道的电码信号，并打印出相应的字符.
大概是这个样子，经常出现在二战时期为背景的电影中的打字机是他的祖先辈份

这种打字机有一个打印头和滚轮，滚轮用于调整纸的纵向移动。每当打印头打印完当前行后需要将打印头移到最左边，滚轮需要把纸向下移动一行。由于这两个操作需要的时间远大于电信号传输的时间，可能会导致在操作过程中电信号的丢失。而解决这个问题的方案是物理补偿，要求每行都加上 \r\n 这两个字符，用于补偿物理设备操作的时间
\r 代表打印头左移对应 CR, 而 \n 滚轮滚动操作对应 LF.

# 那么为什么要分成两个字符？

其实理由很简单，因为测试出来的结果是一个字符输入后，CRLF 的操作并没有完成，进而导致移动到一半的时候打印出错位的文字。所以干错设计为两个字符来避免这个问题.
虽然这个理由很无厘头，但这就是最节省成本的解决方式

# 为什么不是 `\n\r` 呢？

因为 \r 所消耗的时间会更长，保证在两个字符输入完成前实现 CR-LF 的操作，要不然也会出现一个字符设计版本的问题

# Node.js 14 Accessing non-existent property 问题

-------------------20230617---------------------------

今天早更新主题一不小心把 _config.yml 文件覆盖了，/(ㄒ o ㄒ)/~~

之前环境配置也存在一些问题，所以干脆重新搭建一遍环境

结果在编译的时候出现了这个警告，本着不放过任何一个警告的精神，我去 google 了一下

结果，但部分都说是无关紧要的警告，是因为 Node Js 的版本过高，可以忽略或者强制降低警告优先级

目前暂时没有找到更好的解决方案，而且还有一大堆 bug 没修，所以暂时搁置一下

-------------------20230717---------------------------

# shoka 的 quiz

这里需要注意一下 []{.gap} 和 {.quiz} 不能直接相连，相连会导致无法识别 {.quiz} 语法，进而导致无法实现 quiz 的功能

# 关于图床

目前一直用的图床管理 | PicX (xpoet.cn)

但最近总是出现上传后无法复制链接，并且在图库中无法查询到图片

在 github 上查看发现的确上传成功了，如果直接使用链接替换图片名称则会出现有时可以正常显示，有时显示获取异常

去 GitHub 上查看仓库时无意中发现存在两个 branch, 但是有一个 branch 不知道是什么时候创建的，内容和现在的一模一样.

本着多余即是浪费的原则，删掉了图床工作正常，

所以推测图床虽然可以识别不同分支，但是存在多 branch 无法识别的问题

by 2023 年 12 月 17 日

# 本文参考来源

[1] https://blog.csdn.net/mrbone11/article/details/104052137
[2] https://www.finclip.com/news/f/11678.html
[3] https://en.wikipedia.org/wiki/Newline

大道五十，天衍四十九，人遁其一！

blog