前言

今天組長在做站內巡檢的時候，發現header內有一條meta標簽的content顯示為亂碼。

<meta name="description" content="�����?����������?������������������?������?�����������?���?����?���?�?���?��??������������?�??�����?�������?�?��?�������?���������������?�" />

我們版本是由svn控制的，組長使用blame看見是我提交的文件，就丟給我。?

雖然已經是2個月前的提交，但是我還是稍微有點印象。
那是一次從測試站到正式站的代碼合并，使用了BeyondCompare(下文簡稱為BC)的文件夾對比功能，逐個文件進行對比合并。

發現

首先確認了測試站和正式站文件的內容是一樣的，而測試站中頭部文件的編碼方式是UTF-8，而正式站中頭部文件的編碼方式是GB2312。這讓我感到非常奇怪，因為不論是用BC文件拷貝還是IDE的文件創建，都不會出現非UTF-8編碼的文件。

追溯查詢了上一次提交所有文件的編碼方式后發現，非UTF-8編碼的文件還有很多。

測試

于是我打算造個環境測試一下，建了兩個空文件夾test1、test2，test1中放入一個隨意漢字內容的UTF-8編碼test.html。

先使用BC的目錄復制到右邊功能，從test1復制到test2，經查test2/test.html的編碼方式還是UTF-8。

清空test2/test.html的內容，并將編碼方式改為ansi。

再使用BC的打開文件復制到右邊功能，從test1/test.html復制到test2/test.html，漢字復制過去了。

如紅框顯示，只是文字內容復制過去，編碼方式卻沒有。

推測

于是我推測出2個月前的經過是這樣的：
在進行文件夾內容合并的時候，我發現正式站文件夾內已經有了一個空的頭部文件html。
于是我在使用BC進行內容合并的時候不是直接拷貝文件，而是點進文件內復制了內容，卻沒有看到BC右上角提示的不同的文件編碼方式。導致一個GB2312的漢字頭部文件進了UTF-8編碼的網站。

總結

去追究誰造的GB2312空頭部文件已經沒有意義了，組長真正的責難點在于我在復制文字的過程中沒有檢查編碼方式不同，還把這個文件投產了。
通過這個生產事故，再次敲響警鐘，始終要記得檢查文件編碼方式。

標注：本文發布于2017-05-25，最近寫文章都用md，文章也直接發到了我個人的github page內，有時間會一次性貼進博客園里。

轉載于:https://www.cnblogs.com/waltersgarden/p/7357674.html

總結

以上是生活随笔為你收集整理的记一次小型生产事故 | BeyondComper跨编码方式复制文件内容的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。