win下python脚本以unix风格换行保存将会报错为编码问题 SyntaxError: encoding problem:gbk，

win下python脚本以unix风格换行保存将会报错为编码问题 SyntaxError: encoding problem:gbk，

utf-8与gbk编码都报错

从别人的github拉下来一个python脚本。
直接运行，python报错如下：

File ".\drag_files_do_event.py", line 1
SyntaxError: encoding problem: utf8

打开发现该文件第一行已经使用了注释说明文件编码是utf-8,怀疑是否实际是gbk编码。所以将注释中的编码替换成gbk。并且不放心，还将编码转换成gbk保存。
之后再次运行，依旧报错。

File "drag_files_do_event.py", line 1
SyntaxError: encoding problem: gbk

怀疑是不是我的编辑器有问题，又去尝试用notepad++及VScode分别用utf-8,gbk编码保存。折腾的怀疑人生怀疑世界，百度无果。谷歌我打不开。

问题关键是换行风格的问题

吃完午饭，想着看一下每个字符是啥，于是突然想起了notepad++的查看所有字符功能，发现换行只有LF，是unix风格的换行，而我自己写的能跑起来的脚本，无论是utf-8编码的还是gbk编码的都是CR LF的win风格换行。
于是我将换行风格转为win风格。问题成功解决，脚本能够跑起来。

更进一步的解决类似的问题

上面已经清楚了问题的产生是不同平台下默认的不同风格的EOL产生的问题。
于是我开始思考如何更加优雅的解决这个问题。通过搜索，我找到了git的core.autocrlf这个设置。

# 通过这个设置
git config --global core.autocrlf true
git config --blobal core.safecrlf true

但是，不幸的是我发现了下面这篇文章，并且发现许多人并不推荐开启autocrlf（虽然我看到的文章都类同于这篇）。
https://www.cnblogs.com/zjoch/p/5400251.html#4504140
但我注意到这篇文章算是比较久远，所以我在想这个bug是否已经修复。但不幸的是，由于许多人的文章要不是转发或者引用这篇文章，要不就是打着原创的雷同的剽窃的文章。
我花费了一方力气阅读了不少社区的文章，以及自己亲手测试之后。我还是做出了上面的选择。
https://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat
Adi Shavit 的回答测试了各种平台各种选项值的表现。但是，注意测试时间(12年)可能会比较久远一些。
而 pratt 的回答更近一些（16年）。则指出和平台无关，并与win下设置autocrlf为true，linux设为false进行测试。但是其没有测试混合的情况。
___
基于上面的情况，我自己测试了一下win下提交和拉取的情况。

测试时间 2020年2月24日
测试版本 git version 2.21.0
测试平台 win10
测试选项
core.autocrlf=true

我自己测试了windows平台下的commit和pull，发现autocrlf开启的时候，win下纯CRLF的文件或CRLF和LF混合的文件提交到库中都能正常的变成纯LF风格的文件（符合预期）。对于拉取，则都能正常的将LF都转换为CRLF风格（符合预期）。
但是对于纯CR风格的文件或者混有CR风格换行的文件，则git不会对其进行转换。
___
此时，两个小时被花费掉了，感觉过于浪费。又突发奇想在知乎搜索了一下相关的问题。
算是看到了一篇算比较理性的文章，那是git如何避免”warning: LF will be replaced by CRLF“提示？ - Andy Deng的回答 - 知乎
突然感觉如果我早点想到去知乎搜一搜的话，就不必浪费两个多小时了。

一些心得