BOM

스크립트 작업을 하다보면 UTF-8 이 참 속을 썩인다. 

이번엔 BOM 이라는 녀석이 내 속을 썩였는데 

BOM은 인코딩된 문서 첫 머리에 사용되어 정확한 인코딩 방식을 알려주는 역할을 한다.

-  http://blog.wystan.net/2007/08/18/bom-byte-order-mark-problem

파일을 만들때 "이건 인코딩이 xxx 이거덩~ xxx 로 읽어줘~ " 라고 표시하는게 BOM 이다. 

사실 BOM 을 안넣어줘도 UTF-8는 인코딩 형식이 일정해서 대부분 알아채리고 맞게 해석해 주는데 

구~지~ 윈도우 메모장은 utf-8로 저장하면 저 BOM을 넣어줘 버린다. 

메모장에서 아무생각없이 작업한걸 ftp로 리눅스로 올렸다.

근데 스크립트에서 파일을 읽으면서 저 BOM 이 말썽을 일으켰다.

예를 들어 a.txt 파일을 열어보면 

> vi a.txt

<feff>aaaa

bbbb

aaaa

이렇게 들어 있게 되는데  cat 하여 내용을 보면 

> cat a.txt

aaaa

bbbb

aaaa

요래 나온다. 

이걸 sort 하면 

aaaa

aaaa

bbbb

이렇게 하게 되는데 정장 uniq 를 멕이면

1 aaaa

1 aaaa

1 bbbb

이렇게 나온다. 우리는 이렇게 예상했지만... 쉘 스크립트는 bom 캐릭터도 캐릭터로 보는것이었다~

2 aaaa

1 bbbb

급 검색질~~~

Find the list of files containing BOM characters

1	find /var/www/website/ -type f -print  -exec hd -n 3 {} \;  |grep -1 "ef bb bf" | grep "some_part_of_the_path" > bom_lines.txt

Remove BOM character

1	while read l; do sed -i '1 s/^\xef\xbb\xbf//'   $l ; done < bom_lines.txt

배운걸 적용!

cat a.txt | sort | uniq -c  이 문장을 cat a.txt | sed -e '1 s/^\xef\xbb\xbf//' | sort | uniq -c 이렇게 바꾸어 주었더니

2 aaaa

1 bbbb

요래 잘 나왔다~ 

* 역발상으로... 다음 메일에서 linux에서 파일생성한걸 미리보기하려니 

UTF-8로 파일을 만들었음에도 불구하고 다 깨져서 나왔다. 

그래서 일부러 BOM 을 넣어줬더니 안깨져서 나온다. --;; 

header에 utf-8이라고 명시 해줬는데도 해석 못하는거 봐선 다음메일 버그인듯..