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的回答 - 知乎
突然感覺如果我早點想到去知乎搜一搜的話，就不必浪費兩個多小時了。
一些心得
- 注意信息的時效性，保持懷疑
- 不要人雲亦雲，需要結合自身實際情況
- 優先考慮從比較優質的社區搜尋答案
- 可以多從官方文檔或者根據自身情況動手實驗確定自己的解決方案。