將csv數據導入mysql時發現一個有趣的問題
行段的結束符是以\r\n而非一貫的字符串思維中的換行為\n
於是乎就換行、回車整理了一些思路
網上的說法是這樣的:
回車: Carriage Return
新行：New Line
Linux中\n表示回車+換行；
Windows中\r\n表示回車+換行。（文件以\r\n結尾）
Mac中\r表示回車+換行。
這也成為了不同系統下文件不能直接打開的原因之一
個人就windows下的情況進行了一些測試
當我們按下回車鍵時，實際上相當於輸入了"\r\n"（nodepad++的擴展查找可以印證）
在開發環境中輸入"\n"或"\r"時，
控制台輸出都表現為換行，當我們從負責輸出的控制台將結果復制出來時,發現對應的字符串中原本的"\n"或"\r"被轉化為了"\r\n"
而當我們在開發環境中獲取相對應的字符串時，或是直接在本地文本下或是在數據庫中進行輸出，依舊對應"\n"或"\r"
在Git Bash（Windows下的Linux模仿環境）中創建文本輸入回車，最終Windows得到的文件為"\n"，復制粘貼出來轉換為"\r\n"
下面是結論
1.Windows下剪切切板可以兼容任何類型的二進制編碼所對應的字符，對於字符更是完全的復制粘貼，在對"\r"或"\n"的克隆時剪切板均視為"\r\n"，當然同樣的字符在不同編碼格式下對應的二進制編碼不同
2.系統文件在跨平台的過程中，二進制編碼不變，類型(假設不轉格式)不變，將產生相同的字符，由於系統對回車字符的解釋不同，導致文件可能無法正確執行。
3.對同一個系統的同一個二進制編碼，以不同編碼類型，這是亂碼原因。
4.在編碼轉換過程中，以java web為例，我們獲取的（請求參數）是二進制編碼，同時獲知它的編碼格式（gb2312），
再以己方的編碼格式（UTF-8）進行轉換，達到字符相同（相當於復制粘貼過程），那么server中的文本從頭到尾都以UTF-8編輯，最后在以UTF-8統一編譯執行。