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的回答 - 知乎
突然感覺如果我早點想到去知乎搜一搜的話，就不必浪費兩個多小時了，
一些心得
- 注意資訊的時效性，保持懷疑
- 不要人云亦云，需要結合自身實際情況
- 優先考慮從比較優質的社區搜尋答案
- 可以多從官方檔案或者根據自身情況動手實驗確定自己的解決方案，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/189232.html
標籤：Python
下一篇：python選課系統作業