记一次小型生产事故 | BeyondComper跨编码方式复制文件内容
前言
今天組長在做站內(nèi)巡檢的時(shí)候,發(fā)現(xiàn)header內(nèi)有一條meta標(biāo)簽的content顯示為亂碼。
<meta name="description" content="�����?����������?������������������?������?�����������?���?����?���?�?���?��??���������й����?�??�����?��й������?�?��?�������?���������������?�" />我們版本是由svn控制的,組長使用blame看見是我提交的文件,就丟給我。?
雖然已經(jīng)是2個(gè)月前的提交,但是我還是稍微有點(diǎn)印象。
那是一次從測試站到正式站的代碼合并,使用了BeyondCompare(下文簡稱為BC)的文件夾對比功能,逐個(gè)文件進(jìn)行對比合并。
發(fā)現(xiàn)
首先確認(rèn)了測試站和正式站文件的內(nèi)容是一樣的,而測試站中頭部文件的編碼方式是UTF-8,而正式站中頭部文件的編碼方式是GB2312。這讓我感到非常奇怪,因?yàn)椴徽撌怯肂C文件拷貝還是IDE的文件創(chuàng)建,都不會(huì)出現(xiàn)非UTF-8編碼的文件。
追溯查詢了上一次提交所有文件的編碼方式后發(fā)現(xiàn),非UTF-8編碼的文件還有很多。
測試
于是我打算造個(gè)環(huán)境測試一下,建了兩個(gè)空文件夾test1、test2,test1中放入一個(gè)隨意漢字內(nèi)容的UTF-8編碼test.html。
如紅框顯示,只是文字內(nèi)容復(fù)制過去,編碼方式卻沒有。
推測
于是我推測出2個(gè)月前的經(jīng)過是這樣的:
在進(jìn)行文件夾內(nèi)容合并的時(shí)候,我發(fā)現(xiàn)正式站文件夾內(nèi)已經(jīng)有了一個(gè)空的頭部文件html。
于是我在使用BC進(jìn)行內(nèi)容合并的時(shí)候不是直接拷貝文件,而是點(diǎn)進(jìn)文件內(nèi)復(fù)制了內(nèi)容,卻沒有看到BC右上角提示的不同的文件編碼方式。導(dǎo)致一個(gè)GB2312的漢字頭部文件進(jìn)了UTF-8編碼的網(wǎng)站。
總結(jié)
去追究誰造的GB2312空頭部文件已經(jīng)沒有意義了,組長真正的責(zé)難點(diǎn)在于我在復(fù)制文字的過程中沒有檢查編碼方式不同,還把這個(gè)文件投產(chǎn)了。
通過這個(gè)生產(chǎn)事故,再次敲響警鐘,始終要記得檢查文件編碼方式。
標(biāo)注:本文發(fā)布于2017-05-25,最近寫文章都用md,文章也直接發(fā)到了我個(gè)人的github page內(nèi),有時(shí)間會(huì)一次性貼進(jìn)博客園里。
轉(zhuǎn)載于:https://www.cnblogs.com/waltersgarden/p/7357674.html
總結(jié)
以上是生活随笔為你收集整理的记一次小型生产事故 | BeyondComper跨编码方式复制文件内容的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 嵌入式产品开发设计需要考虑的问题总结
- 下一篇: angularjs-数据同步时机ng-m