방사성 폐기장

 현재, 집에서 쓸데없는 책(억울하다. 집에서 내 물건들은 내가 아버지 다음으로 가장 적게있다!)과 물건들을 다 치우라고 뭐라 들었다.

 CD에 있는 데이터를 백업하여 DVD로 옮기고, 책을 DVD로 옮긴다고 해도, 문제는 DVD로 바꾼 데이터는 책자로 만든 데이터보다 안정성이 떨어진다.

 그렇다고 책을 가지고 있자고하니, 공간을 차지하는 걸 줄이라고 하니...(분가한 누나의 책을 없애봐라. 모자란 공간이 남아도는데, 빌어먹을...)

 무튼, 최대한 데이터를 유지하면서 공간을 줄이는 방법으로 DVD(전자화)를 시키는걸로 할려고한다.

 지금 생각하는 방법으론, DVD로 말곤 없다고 생각했지만, 다른 방법을 생각해봤다.

 QR코드와 BASE64는 어떨까 생각한다.

 BASE64는 문자로 표현이 가능한걸로 변환하기 때문이다. 문자는 곰팡이가 펴도 읽을 수만 있으면 됀다.

 문자를 읽을 수 있다면, 그대로 타자를 친 후에 변환 프로그램으로 변환을 하게되면, 데이터를 그대로 얻을 수 있다.(BASE64의 원래 목적은 데이터를 그대로 문자로 표현하는 방법이다.)

 QR코드는 바코드형태를 2차원으로 표현한 것이다.

 바코드는 검은바와 흰색의 차이로 데이터를 만든다. 하지만, 최대 표현할 수 있는 능력이 제한되며, 데이터가 손실되기 쉽다는 특징이 있다고한다.

 하지만, QR코드는 2차원으로 1차원 바코드보다 데이터 표현량이 커진다.

 이걸 이용해서 DVD에 대한 데이터를 넣을 수 있다면, 안전한 데이터표현법이 되지 않을까 생각이 든다.

 하지만, 해보지 않아서 정말 가능한지 모른다. 그리고 DVD가 4.7Gb가량이 된다고 하면, QR코드는 고작 8bit는 2953Byte 가량 밖에 안되기 때문이다.

 집에 도배, 도장, 장판등 작업한다고, 개고생하고 컴퓨터 말아 먹었다.

 더 짜증나는 것은 내 책을 다 없애야된다는 점이다.

 CD도 다 없애라는 말 듣고 와서 지금 CD도 빽업 할 예정이다.

 조사해보니, 2004년부터 2014년에 항상 말하는 300Gb 저장되는 광디스크를 개발되는 중인데, 왜 상용화 못하는지 모르겠다.

 무튼, 그래서 관련 포스팅을 못할 것 같다.

 잘 작동되다가 OS가 갑자기 블루 스크린이 뜨면서 Device Power Error라는 오류가 뜬다면, 컴퓨터를 빨리 끈 후에 하드 디스크와 기타 장비에 녹이 슨데가 없는지 확인한다.

 녹이 슨데를 확인 하였다면, 제 빠르게 지우개로 녹이 슨데를 닦아 준다.

 만약, 하지 않는다면, 하드 디스크가 타버리거나 하여 컴퓨터에 불이난다.

 오늘 재수가 없어서 파워랑 하드 디스크가 다 타버렸다...

 개인적으로 궁금한 점이 생겨서 구글 포토스에 이것 저것 시켜봤다.

 포스팅에서 75Mb까지 사진을 지원해준다고 한다.

 그래서 궁금해서 BMP(Not Compress)로 64Mb 파일을 강제로 만든 후(그림판으로 흰색 단일 처리로 순수 Pixel로 처리) 올려 봤다.

 처리가 빠르길래, 한번 보니, BMP가 JPEG로 변환하는 상황일 발생하였다.

 순수한 파일이 아니라는 뜻이기도 하면서, 75Mb를 제대로 지원해주지 않는 말이 되기도 한다.

 75Mb을 제대로 지원 받을려면, PNG로 변환 하는 방법 말곤 없다.

 그런데, 웃긴 이야기는 전체 픽셀을 1600만화소라는데

 1600만화소를 제대로 지원해줄려면,

 2048x7168 이상은 가야된다.

 그런데, 2048x7168을 순수 BMP으로 맞춰서 만들어내면, 10Mb에서 20Mb가량 밖에 안된다.

 과연, 75Mb는 어디에서 나오는 수치이란 말인가?

 모든 실험은 BMP 24bit에서 이루어진 실험입니다.

 구글 포토스가 고화질을 지원해준다. 하지만, JPEG 사진을 원본을 가지고 있는게 아니다.

 원본을 변경하여, 본 화질과 값이 다를 수 있다.

 JFIF로 처리하는 것을 보면, 구글은 중간에 화질 변경을 이루어진다.

 클라우드에 올리는 것에 비해서 사진의 화질이 떨어질 수 있다는 뜻을 가진다.

 증거 자료.

 JPEG로 실험한 결과이다.

 원본.

 구글 포토스에서 받은 경우.

 데이터를 손실시켜도 상관 없는 사람들에겐 문제가 없을진 몰라도. 원본을 원하는 사람에겐 PNG로 저장하는 것을 추천한다.

 MP4 또한 변질된다.

 제일 안전한 방법은 PNG로 변환 시켜서 처리하는 것이다.

 어제 테스트해서 보니, 압축 방식을 어떻게 하느냐에 따라서 압축률이 증가한다는걸 알아 냈다.

 답은 TAR로 한번 폴더와 파일을 한 파일로 몰아 넣은 후에 압축하면, 상대적으로 엄청 많은 압축률을 보여준다.

 ZIP이나 ZIPX는 압축률이 높은 알고리즘을 사용한다.

 특히, ZIPX는 최근에 발전된 방식의 압축 방식이다.

 여기서 ZIP과 ZIPX의 공통점은 LZ77을 이용한다는 점이다.(ZIP은 DEFLATE, ZIPX는 LZMA)

 여기서 압축률이 가장 높은것은 LZMA이다.

 그런데, LZMA의 압축률이 높은 것은 LZ77의 사전의 크기가 크기 때문에 그런 것이다.

 LZ77의 사전 크기는 압축률을 뜻하고.

 사전를 빠르게 탐색하는 것은 압축 속도를 높이는 장치이다.

 즉, 검색 알고리즘이 발전하면, 압축속도가 높아진다.

 사전 크기(저장하는 데이터)가 커지면, 압축률이 높고, 이 사전에 검색을 빠르게 하는 알고리즘을 적용하면, 빠르고 압축률이 높은 알고리즘이 생긴다.

 일단, ZIP은 LZ77의 최대 사전 크기가 32kb이다.

 하지만, ZIPX는 LZ77의 최대 사전 크기가 4Gb이다.

 그래서 LZMA(LZ77의 사전 크기가 4Gb)가 압축률이 가장 높다.

 그럼, 왜 TAR을 했던것과 그냥 하는 것과 압축률이 엄청 차이나는가?

 TAR을 이용하여, ZIPX을 적용하면, 사전을 전부다 적용 시킬 수 있기 때문이다.

 ZIPX는 각 파일마다 LZMA 압축을 하기 때문에 제대로된 압축이 되지 않는다.

 7Z는 TAR처럼 한번 압축을 거치기 때문인지 ZIPX보다 압축률이 높을때가 높다.

 TAR+ZIPX을 한것과 비슷하거나 조금더 압축이 된다.

 그래서 7Z을 사용하거나 TAR+ZIPX을 쓰는게 더 이득이다.

 요즘 Google에서 Open Source로 공개한, Brotli라는게 있다.

 이게 압축율이 좋다고 한다.

 좁플라이보다 개량되서 20% 향상되었다고 한다.^[각주:1]

 그래서 구글링을 해서 exe파일로 구해봤다.^[각주:2]

 현재, 테스트 해본 결과

 mp4파일(원본) : 297624674kbyte = 100%

 zip[반디집] : 266413245 = 89.51%

 zipx[반디집] : 41239013 = 13.85%

 brotli : 40981074 = 13.76%

 paq8o10t [8] : 40088746 = 13.47%

 이렇게 압축파일의 효율적으로 처리되는걸 알 수 있다.

 압축 속도는 zipx(LZMA) 보다 느리나, 압축율과 압축 해제속도는 상대적으로 비슷하거나 높음을 알 수 있다.

 하지만, 역시 PAQ알고리즘보단, 낮다.

 단, 속도를 비교해보니, PAQ가 시간이 엄청오래 걸리고 메모리를 많이 먹는 것 비해.

 이정도(약 1Mb차이)면, 괜찮은 것 같다.

 --2015.10.07--

 확인해보니 아직 brotli는 문제점이 있는 것 같다.

 반디집의 zipx을 이용하는 것과 brotli을 이용하는걸 비교해보니, zipx가 오히려 더 이득적인게 있다.

 그냥, 반디집의 zipx을 이용하는게 더 이득이다.(속도로나 압축률로 보나...)

Brotli.exe

 현재, 테스트 해본 소스에서 단일 처리가 빠르다.

 파일에서 추출하고, 다중 처리하기 위해서 데이터를 분할하는 과정이 있어서인지 오히려, 다중 처리가 단일 처리보다 느린 점을 보였다.

 다른 사람들은 어떻게 하는가 설명을 보니, 큐 구조를 이용해서 자료를 저장하고, 그 데이터를 각 스레드에 연결해서 큐을 추출해서 처리하는 방식을 취한다고한다.

 나는 그냥 각 변수에 연결하는 방식이기 때문에, 그 변수가 종료 될때까지 멈춰있는 문제점이 있었다.

 그래서 다중 처리자가 늘수록 빠르게 작동은 되지만, 단일 처리보다 못 미치게 되는 것 같다.

 자료 구조가 중요하다는 걸 깨달은 날이다.

 base64는 파일의 구성을 256가지가 아닌 64가지로 표현하는 방법이다.

 그래서 파일의 내용은 그대로 남아있다는 특징을 가진다.

 Decoder만 존재한다면, 해당 파일을 어떻게든 얻을 수 있다는 뜻이다.(깨져있을 수 있다는 점은 제외)

 예을 들어서 이미지 파일을 표현하고자 한다고 하자.

 보통 html로 이미지를 불러온다면, 다음같은 소스를 사용한다.

 <img src="이미지 파일 경로" />

 여기서 src을 '이미지 파일 경로'로 처리하는게 아니라.

 base64로 얻어진 파일 경로를 사용한다.(Data URI)

 그렇게하면, 서버에 파일데이터를 데이터베이스 문서파일로 넣을 수 있게 된다.

 예제:

 이미지파일을 base64로 변경시킨 값.

 base 64:

 이렇게 되어있을걸 그대로 html에 사용하면, 안된다.

 앞에 어떤 데이터인지 제대로 명시해주어야된다.

 현재 Tistory 로고는 gif구조이다.

 그래서 data:image/gif;을 앞에 붙여줘야된다.

 그리고, base64로 구성된것이다. 라고 알려 줘야된다.

 처음 부분은 이렇게 된다.

 data:image/gif;base64,R0lGODlhYAATAPcAAAAAA...

 적용하면, 다음과 같다.

 이걸 응용하여, 데이터를 주고 받거나 다운 받을 수도 있다.

 예제

 이렇게하여 데이터를 인터넷에서 다운로드, 저장, 공유를 할 수 있게 된다.

 단, 안전성에서 완벽하다. 라고 할 수는 없을 것이다.(전송 중 1bit가 오류났을 경우, 정정할 수 없으며, 오류를 탐지할 수도 없다.)

 이것만 제외하면, 파일을 글로 저장하여 쓸 수 있게 된다.

 인쇄물을 읽어서 컴퓨터에게 전송 할 수 있는 기술이 있다면, base64로 만든 인쇄물을 이용해서 보관 할 수도 있을 것이다.(그럴 필요성은 없겠지만...)

 base64란, 컴퓨터가 표현하고 있는 문자 방식(1byte로 표현할 수 있는 최댓값)은 256가지이다.

 하지만, 이런 경우를 생각해보자.

 문서(문자열로만 구성된 파일)을 보내는데, 대상이 문서로 표현할 수 없는 데이터로 이루어 져있다면, 어떻게 보낼 것인가?

 여기서 모든 플랫폼에 서로 대응하는 형태를 가져야될 것이다.

 이것을 64가지(숫자, 알파벳 대/소문자, 기타 기호 몇개)로 표현하는 방식이다.

 이 방식의 문제점은 용량의 증가가 존재한다는 문제가 있다.(약 33%가량이 증가한다고 한다.)

 이 방식은 메일 및 기타 방식에 사용되며, 암호와는 전혀 관계가 없다.

 그냥 인코딩하는 것이다. 암호는 알고리즘과 키가 밝혀졌을때, 최대한 그 암호 문서를 늦게 풀어내는 것이 목적이다.(공개키) 하지만, Base64는 남에게 숨길려고 드는 목적을 가지고 있지 않다.

 심지어, Base64는 키라는 존재도, 특정한 존재에게만 열리도록 목적을 가지고 있지 않다.

 1. Base64는 암호용 알고리즘이 아니다.

 그렇다고 Base64가 암축용으로 만들어진 것도 아니다. 오히려 용량이 늘었으면 늘었지(256가지로 표현된 데이터를 64가지로 표현하기 때문에 늘어날 수 밖에 없다.) 줄어들 경우는 없다.

 2. Base64는 압축용 알고리즘이 아니다.

 그렇다면, 왜 Base64가 존재하는가?

 그것은 쉽게 이렇게 들수 있다.

 파일은 올릴 수 없고, 게시판에 이미지 파일을 올려야 될 경우에.

 Base64을 이용하면, 쉽게 사용이 가능하다.

 다음과 같은 효과를 얻을 수 있으며, 음악, 사진, 동영상, 파일등 모두다 가능하다.

 그 외에도 메일(MIME)에도 사용이 가능하다.