하마
6k
2015-04-13 17:28:18 작성 2018-03-21 09:16:31 수정됨
48
48004

Base64 왜 사용하는 걸까요?


  

1. Base64 사용 안했을때 충돌지점의 구체적 예시화

2. 더 좋은 방법들

 살다보면 무임승차 바랄때가 있잖습니까. 누가 떡하니 총돌지점 및 인사이트를 자세히 가져다 줄지..하는 ..스스로 찾아야 하는 문제를 너무 쉽게 떠먹여 달라고 한거 같습니다..반성합니다.


@ 시간없는 분들을 위한 간략 정리입니다.

ㅡ양쪽종단을 직접연결해서 자기 관리하에 코딩하면 바이너리+문자열을 혼합해서 하던 멀하던 base64 는 쓸 필요없다.  낭비이다.

ㅡ이미지나 한글등으로 이루어진 메모리가 다양한 네트워크를 타고 다니면 의도치 않게 1바이트단위로 쪼개져서 처리가 되기도 한다. 그때 기본 아스키문자가 아닌 컨트롤 기호등으로 오인받어 오류가 스며들수있다. 따라서 모든 시스템이 기본적으로 알고있는 128자의 문자로 변경한다.

ㅡ현재 base64 가 사용되는 여러것들에서 더나은 해결법은 없었을까 하는 의심은 들지만 파볼생각은 없다. 지쳤다.

ㅡ 주변에 자연스럽게 사용하는 기술도 딴지 걸어 보자. 즉 오해/확인/의심의 과정을 밟아보자.



나름 괜찮은 의논들이 될 수 있었겠지만, 내 역량이 부족해서 망했다. 소중한 의견 사이 사이 몇몇 수준 낮은 댓글에 수준 낮게 반응 한 내 부끄러움의 잔재이지만 그래도 먼가 얻는 분들도 있으리라 해서 남겨 뒀는데 이제 댓글을 2년만에 지운다. 감정소모의 부분이 삭제되면 이 글을 첨 읽는 분들이 내용에 집중하기 더 좋을 것 같다.  그리고 내가 애초에 좀 만 더 정리를 잘 해서 썼었더라면...하는 후회가 남는다. 다시는 무임승차 하지 말아야지.  가벼히 생각한 내 탓이 크다. 

0
9
  • 답변 48

  • alwk68
    583
    2015-04-13 17:30:38
    보안이라고 보긴 어렵고 그냥 바로 읽기 힘들게 섞는다 정도로 생각하셔야될것같습니다.
    0
  • fender
    13k
    2015-04-13 17:35:08
    Base64는 보안을 위해 사용하는 것이 아니라, 무슨 이유에서건 바이너리 데이터를 텍스트로 다루고 싶을 때 보편적으로 사용할 수 있는 방식이라고 보시면 됩니다.
    5
  • fender
    13k
    2015-04-13 19:02:31
    바이너리를 텍스트로 변환할 수 밖에 없는 예를 원하시는 건가요, 아니면 그런 작업을 하기 위해서 Base64보다 더 효율적인 알고리즘이 없는지를 물으시는 건가요?
    0
  • fender
    13k
    2015-04-13 19:14:39

    구체적인 예를 들자면 JSF에서 직렬화한 컴포넌트 상태를 input type="hidden"에 저장하는 경우가 생각나네요.

    RDBMS의 종류에 따라 이진 컬럼에 Base64로 insert를 지원하는 경우도 예가 될 것 같습니다. HTML파일이나 SQL 구문 안에 이진 데이터를 직접 쓸 수는 없으니까 Base64로 텍스트로 변환하는 방식을 사용하는 경우입니다.

    2
  • fender
    13k
    2015-04-13 19:20:27

    하나 더 추가하자면 HTML의 Data URI도 좋은 예가 될 듯 합니다. 이를 이용해서 HTML이나 CSS에 인라인으로 임의의 그림을 내장할 수 있는데, 역시 이들 파일 형식이 기본적으로 텍스트 기반이니 불가피한 선택이 될 것입니다.

    2
  • fender
    13k
    2015-04-13 19:41:09

    왜 HTML에 이진 데이터를 때려 박으면 편집이 안되는지가 궁금하신 것 같지도 않고, 그렇다고 더 효율적인 대안이 궁금한 건 아니라고 하셨고...

    솔직히 무엇을 원하시는 지 잘 모르겠네요.

    0
  • 앙앙이
    2015-04-13 19:53:37

    영문화권은 7비트로 충분하지요

    그렇게 생각하던시절

    만들어진 네트워크 장비를 뚫고 8비트를

    보내고 받기 위한 방법론의 필요성으로

    base64가 만들어 진거로 알고 있습니다

    제가 잘못알고 있을수 있으니

    잘못되었다면  지적해 주시면 감사하겠습니다

    0
  • fender
    13k
    2015-04-13 19:56:38

    이건 코드 레벨의 문제가 아니라 요구조건의 문제가 아닐까요?

    HTML 파일을 텍스트 편집기로 고칠 수 있어야 한다거나 URL엔 이진값을 쓸 수 없다던가 하는 문제는 순전히 코드의 문제는 아닌 것 같습니다.

    예컨대 앞선 예에서 HTML의 INPUT이나 Data URI에서 이진값을 허용하면 HTML 파일은 특수한 편집기로만 수정가능하고 브라우저 주소창도 파라메터로 이진값을 입력할 수 있게 특수하게 새로 만들어야할 것입니다.

    1
  • fender
    13k
    2015-04-13 20:07:17

    예로드신 RPC나 스트리밍의 예처럼 보내는 쪽이나 받는 쪽이나 이진 데이터를 처리하는 데 아무 문제가 없다면 Base64로 인코딩할 이유가 전혀 없을 것 같습니다.

    텍스트 편집을 전제로하거나 HTTP 스펙을 준수해야 한다거나 하는 경우를 전제해야 합리적인 선택이 될 문제인 듯 합니다.

    1
  • pacific1
    2k
    2015-04-13 22:56:53
    예전에 이미지를 멀티파트대신 base64로 인코딩해서 저장할때 디코딩해서 파일로 만들어 저장했던 기억이 있습니다.
    0
  • 지붕뚫고높이차
    559
    2015-04-13 23:15:06

     

    메모장에서 자판으로 한글로 쓴 뒤 저장 버튼을 클릭하면
    메모장에서 사용하는 캐릭터 셋으로 인코딩 되어
    바이너리 데이터 (정확하게 이야기하면 8bit 크기인 블록의 배열) 로 스토리지에 저장됩니다.

    저장된 파일을 불러오면
    스토리지에 읽은 바이너리  데이터를
    메모장에서 사용하는 캐릭터 셋으로 디코딩 되어
    사람이 볼수 있게 메모장에서 출력이 되구요.

    캐릭터셋은 아스키코드와 아스키코드에 표현안되는 한글같은 문자에 대해 바이너리로 표현하는 규칙입니다.
    EUC-KR 로 인코딩된 한글문자열을 UTF-8 로 디코딩할경우 깨지는 이유는
    인코딩 과 디코딩시 사용했던 바이너리 변환규칙이 달랐기 때문이죠.

     
    보통 바이너리를 사람이 볼수 있게 표현하는 방법은
    1byte인 8bit를 2개의  영문자/숫자로 표현하는 HEX 와
    2byte를 묶어 키보드 입력이 가능한 문자를 활용 1개의 문자로 표현 HEX보다 공간을 절약한 BASE64 를 많이 사용합니다.
    (대신 8bit 배수인 바이너리 배열을 24비트로 나누다 보니 나머지를 = 로 표현하는 복잡함이 생깁니다.)

    * 위 부분은 오늘 아침에 수정했습니다.

     
    캐릭터 셋과 BASE64,HEX 의 공통점은
    바이너리 데이터를
    사람이 볼 수 있고
    캐릭터셋 간 호환성이 있는
    아스키 코드기반 문자로 표현한다는데 있습니다.

     
    암호화된 데이터를 BASE64로 표현한다고 했을때
    문자열 -> 지정된 캐릭터셋 기반 바이너리로 인코딩 -> 암호화 연산
    -> 암호화된바이너리를 BASE64로 인코딩 하는 복잡한 과정을 거칩니다.

    이때 암호화된 바이너리를 BASE64로 인코딩을 안하고 메모장에 출력하면 어떻게 될까요?

    메모장에서 사용한 캐릭터 셋으로 디코딩에 실패를 하고
    메모장에 이상한 문자열이 찍히거나 최악의 경우 메모장이 종료되는 오류가 발생할 수도 있습니다.

    DBMS 에 데이터입력/수정/삭제는 사람이 인식 할 수 있는 문자로 SQL 을 만들어
    지정된 캐릭터셋으로 바이너리로 인코딩해 SQL을 수행합니다.
    (LOB 는 처리방법이 다르니 논외로 합니다.)
    이때 바이너리 데이터를 SQL 로 만들어 전송하면 DBMS 의 캐릭터셋 때문에
    입력한 바이너리 데이터는 깨지게 되는겁니다.


    HTTP 프로토콜은 아스키코드 를 사용해 해더 영역에서 전송 데이터를 표현합니다.
    하지만 HTTPS 처럼 데이터 부분은 바이너리 로 전송해도 무방하지만
    수신받은 바이너리 데이터를 깨지지 않고 디코딩 할 수 있어야 한다는 조건이 붙습니다.
    따라서 캐릭터셋간 호환성이 있는 아스키 코드기반으로 바이너리 파일을 디코딩 해서
    안전하게 전송을 하는 겁니다.
    중계서버등 이슈가 있다면 더욱 바이너리 데이터를 BASE64, HEX 로 아스키 코드로 변환해 전송해야 합니다.
     
    여기까지 BASE64 인코딩/디코딩을 사용해야 하는 이유에 대해 설명드렸구요.
    규칙을 정리하면 다음과 같습니다.

    1. 바이너리 데이터에 대해 서로 디코딩/인코딩 규칙이 동일하거나 데이터 자체가 이미지같은 바이너리일 경우 사용하지 않아도 됩니다. 단  바이너리 데이터의 시작과 끝은 명확해야 합니다.

    2. DBMS, 엑셀 등 사람이 관리해야 하는 데이터는 바이너리 데이터를 아스키로 표현해야 합니다.

    3. 상호간 사용하는 캐릭터셋이 다를경우 중간 단계인 BASE64/HEX 로 바이너리 데이터를 전달합니다.

    4
  • 지붕뚫고높이차
    559
    2015-04-14 11:49:54

    하마//

    base64 규칙에 대해 다시 적었습니다.

    저의 어리석음을 알게 해준것 참으로 감사드립니다.


    그리고 BASE64 를 써야 하는 이유는


    아스키 코드 외 문자에 대해 

    바이너리로 표현하는 규칙인 

    캐릭터 셋이 프로그램 마다 다를 수 있고


    규칙이 안맞을 경우 바이너리 데이터를 문자로 디코딩 할때 

    깨지는 문제점이 있어

    그걸 방지하는 차원에서 

    바이너리 데이터를 아스키 코드로 표현한다고

    메모장, 암호화, DBMS, HTTP프로토콜 e다양한 경우를 들어 설명했는데


    하마님이 why 를 충족시키기에는 부족했나 보네요.


    스펙이라는 용어도 스펙과 유사한 내용도 쓰지 않았는데

    단어를 유추하는 대단한 문장 해석 실력도 있구요.


    암호화의 경우 질문 하셨는데 답변하기 귀찮습니다.


    하마님


    why 를 충족시키기 어려우면


    여기서 스무고개 하지 마시고


    당장 옆 동료, 상사와 BASE64 의 why 에 대해 사이좋게 토론하거나 

    도서관에 가서

    why 를 알아내는것을 권합니다.


    괜히 마이너스 점수 사용자에 댓글을 올렸네요.

    시간 아깝게..

    2
  • 흐어엉
    1k
    2015-04-14 16:25:03

    오키분들은 다들 천사시네~

    6
  • py15
    25
    2015-04-14 16:52:54

    첫째.  왜 표현가능한 문자셋으로만 통신을 하나? 코딩상문제인가 , 스펙상 약속인가 

    => 바이너리데이터를 ASCII문자열로 표시하기 위한 스펙입니다.


    둘째. 아래와 같이 image 를 그냥 binary 로 넣으면 깨진다는것은   XML 을 파싱할때 image binary 부분을 

    파싱할때 시작 과 length 를 모른다는것이 될까요 아니면

    XML 은 파싱할때 이미지는 base64 로 파싱한다는 약속이 있는걸까요.

    => XML은 텍스트 문서이고, 문서에 바이너리 데이터를 넣기 위해서는 바이너리 데이터를 문서화(캐릭터화)를 해야 하기 때문입니다. 그래서 위에서 언급한것처럼 바이너리 데이터를 문자로 표현하기 위해 base64인코딩을 하는 것입니다.


    그리고 일단 위키에서 base64에 대해서 찾아보셨다면 위의 질문중 일부는 해결되었을겁니다..
    http://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464


    3
  • py15
    25
    2015-04-14 19:53:14

    저에게 질문을 하시기 전에 위키는 읽어보셨는지 모르겠습니다.

    왜 64글자로만 써야 하는지 위키 두번째줄에 써있습니다.

    더 효율이 좋게 하실거면 따로 라이브러리를 만들어서 쓰시면 됩니다. (대신에 먼길로 돌아가겠죠)

    그리고 XML에 바이너리 데이터를 넣지 않으실거라면 base64를 안쓰셔도 됩니다.


    결론

    1.  base64 로 밖에 할수없다.  (O) 

    2.  33%의 낭비는 어쩔수없다. 다른 방식으로 하려면 더 큰 공간 낭비를 해야한다 (O)

    3.  base 64 가 가장효율적이다. (O)




    3
  • madzzang
    82
    2015-04-14 23:41:19

    제가 이야기하는게 정답은 결코 아닐겁니다.

    유추할수 있는건 바이너리 데이터를 전송시 특수문자 파싱문제를 가장 깔끔하게 제거 할수 있는 수단중 하나가 아닐까 예상합니다.


    예를들어 바이너리 데이터를 sms로 보내서 받는 앱을 만든다고 했을때 가장 깔끔한건 127비트 아스키 코드가 아닐꺼거든요.

    순수 문자기반으로 변형해야 가장 문제없이 전달될듯...

    너무 쉽게생각하고 답변 다는거일지도 모르겠네요.

    2
  • madzzang
    82
    2015-04-14 23:45:19
    그리고 위에서 이미지를 base64로 바꾸는건 쉽게 생각해서 binary data가 공교롭게 <>값으로 SQL injection같은 파싱문제를 유발시킬수도 있으니 sms로 보내는거와 마찬가지로 가장 안전한 데이터 로 a-z, 0-1등의 문자를 보장한다는 의미로 보면 되지 않을까요?
    1
  • 하두
    9k
    2015-04-15 00:37:11

    플랫폼에 관계없이 독립성을 가진,  자료의 깨짐을 방지하기 위해서랍니다.  

    왜 그런지는 원리는 모름 ㅋ

    왜 그럴까요.

    1
  • 앙앙이
    2015-04-15 07:00:17

    Hex비효율은 얼마일까요?

    여기 오시는분들께 이런 질문은 실례이지요

    Hex비효율 계산 못하시나

    자꾸 Base64 33퍼 비효율인데 왜 쓰냐고 하시네요

    자바하다 자빠지신것같은 동질의식이 들어 기쁘네요. 나만 자빠진것이 아니라서 위로가 되네요


    4
  • urbug2
    1k
    2015-04-15 07:58:03


    저도 실력이 미천한 개발자입니다.


    그런데 비교적 명확한 내용인거 같아 대답을 달아 봅니다.

    Base64는 단순히 바이너리를 어느 문자셋에나 있는 기본문자로 인코딩을 하는 단순 인코딩 기술이며. 기 이상(스펙인가요?) 그 이하도 아닙니다. 단지 개발자 편의에 의해 사용 될 뿐이구요.

    인코딩은 언제나 힘든 문제입니다.간단하게 http로 html을 만드는데 벌써 상당 수의 인코딩을 거칩니다.그리고 개발자라면 누구나 이기종 간에 한글이 깨져서 고생을 하는 경우를 겪으셨을 겁니다.말이 길어져짧게 쓰지만 인코딩은 정말 정말 정말 어려운 문제입니다 ㅜㅜ

    그런데 base64로 꾸워버리면. 데이터가 인코딩을 통해 안전한 케릭터들로만 채워지고. 전송받고 디코딩만 하면 온전하게 문자셋을 받을 수 있죠.

    가장 귀찮은 문제를 간단하게 털어 버릴 수 있기 때문에 많이 쓰일뿐 거창한 내용을 품고 있지는 않습니다.

    이 밖에도 간단한 파일을 문자열로보내고 싶거나. 사용자가 읽을 수 없는 문자로 노출하고 싶거나. 등등 있지만 글쓴님이 아시는 범위를 크게 벗어나지 않는다고 생각 되네요.









    3
  • py15
    25
    2015-04-15 11:24:48

    계속 위키얘기를 해서 좀 그렇습니다만, 위키에 이미 언급된 내용을 계속 이곳에 질문하시는게 의아합니다.


    1. XML   같이 반드시 바이너리 데이터를 문자화 해야하는 모든 곳에서 base64 를 쓴다. (o/x)

    => XML은 기본적으로 텍스트 포멧입니다. 텍스트 포멧에 바이너리 데이터 (예를 들어 줄바꿈문자나 탭문자)를 넣을 수 없습니다. 넣으면 실제로 줄바꿈이나 탭으로 들어가버리니까요.(다른 제어문자라면 더더욱 표시가 안되죠) 그렇다면 이런 데이터를 어떻게 텍스트 형식으로 바꿀 수 있는가..에 대한 해답으로 나온게 base64인코딩입니다.

    참고로 왜 xml은 텍스트형식인가요.. 와 같은 질문에는 뭐라 답해드려야 할지 모르겠습니다.

    (그리고 base64를 쓰게된 곳이 E-mail이었습니다만, Email은 기본적으로 7bit ascii로만 통신이 되었습니다 / 정확히는 SMTP가 7bit를 사용합니다.)


    2. 다른 방식을 쓴다면 base64 를 안쓰는 이유는?

    => 내부 룰이겠죠. base64가 보안상 안좋다던가, 주관적으로 쓰기싫다 같은게 있을 수 있으니까요. 성능이 안좋아서 안쓰겠다는 곳도 있을 수 있겠죠. 어쨌든 바이너리를 텍스트로 표현할 수 있고, 송수신 양쪽이 대응을 할 수 있다면 뭘 써도 상관없는거니까요. 예전에는 UUEncode라는 것도 있었습니다만, 다양한 포멧이 있어서 지금은 일반적으로 base64로 통일해서 사용중에 있습니다.(정확히는 MIME형식에서 base64만 쓴다고 정의해 버렸습니다.)


    3.더 효율이 좋게 하려먼 만들어 쓰라고 하였는데  더 효율좋게 만드는 방법이 있는데

       XML,   메일 등이  base64  를 쓰는이유?

    => 범용적으로 쓰고 있는데 바꿔야 할 이유가 있나요? 성능상에 큰 문제가 생기는 곳이 아닌 이상 먼 길을 돌아가야 할 이유가 있나요? 그리고 메일은 이미 RFC로 그렇게 인코딩해서 쓰라고 정의되어 있습니다만..


    4. XML, 메일 에 바이너리가 들어갈경우 파싱에 어떤 문제가 생기는지에 대한 상세 예제 

    => 2바이트 메일보내기 셋팅이 안된 메일서버에서 한글메일 보내보시면 바로 보실 수 있습니다... 만, 당연한거 아닌가요? 영문 스택오버플로 같이 영어로만 질문해야 하는 곳에 한국어로 질문하는 거랑 같은데요..(한국인이 대답할 수도 있겠지만, 영어권 사람들이 대답할리 없겠죠)


    5. 위의 1~4의 질문이 모순이 있거나 잘못되었다면 그 이유?

    => 왜 이런 질문을 이어가시는지 모르겠습니다. 이미 base64에 대해 설명을 해드렸는데, 마치 그 내용을 전부 이해시켜 달라고 하는것으로 밖에 안보입니다.

    4
  • yongbam
    167
    2015-04-15 14:37:48

    Rule 3: The space (decimal 32), tab (decimal 9), carriage return(decimal 13), and line feed (decimal 10) characters may be directly represented by their ASCII equivalents. Howevero, note that MIME content transfer encodings have rules concerning the use of such characters. Usage that does not conform to the restrictions of RFC 822, for example, would have to be encoded using MIME content transfer encodings other than 7bit or 8bit, such as quoted-printable, binary, or base64.

    [RFC 1642 중 일부]

    치던 것을 다 날려서 급 기운이.....

    RFC 에서 quoted-printable 과 base6 를 동일하게 한 것처럼 캐리지 리턴의 다른 표현으로 인한 데이터 깨짐에 대한 해결책으로 쓰였다고 보입니다

    아무래도 네트워크 전송에 있어 여러 게이트웨이나 라우터를 통과하는데 서로 다른 OS 를 사용하는 이 들 장비에서 데이터 손실이 발생할 수 있습니다

    다른 더 좋은 것이라고 하면 당연 base64 에 crc 를 추가해서 안정성을 더 올린 것 등이 있지만 보통 데이터가 약간 깨졌을 때 재전송이 빠를 경우도 있고 RFC 의 사항이기도 하니 범용적으로 사용되는 것으로 보이네요

    0
  • yongbam
    167
    2015-04-15 14:50:04

    근데 텍스트는 이해가 가는데 왜 이미지 전송에도 많이 쓰는 건가는 좀 생각해봐야 될 것 같아요

    저는 이미지를 전송 시 base64 인코딩을 쓰지 않고 그냥 압축 후 뒤에 crc 를 붙이고 바이너리로 전송시키거든요.. 생각해 볼 재미있는 문제인 것 같네요

    가장 예상되는 이유는 많은 오픈 소스들이 편리함 및 최상의 안전성을 위해 이 방식을 쓰기 때문??

    0
  • 초보조사
    117
    2015-04-15 16:02:56
    CGI 를 생각하면 쉬울거 같은데요. 웹이 처음에 시지아이 방식으로 표준입출력으로 데이터를 입역받습니다. 그러면 바이너리데이터는 표준입출력으로 받을수가 없습니다. 키보드로 0x00 과 같은 헥사코드값 입력이 불가능하죠. 그래서 이런 바이너리데이터를 받기위해서 베이스64란 표준입출력이가능한 문자로 다 바꾸는 걸로 알고있습니다. 
    1
  • kenu
    43k
    2015-04-16 17:09:58
    이 글도 지워질 것 같습니다만
    0
  • kon
    1k
    2015-04-16 21:57:41
    싸가지라니... 제정신인가요?
    3
  • kenu
    43k
    2015-04-16 23:29:50

    욕 먹는 거야 많이 먹어봐서 괜찮습니다.

    구글에서 "base64 why" 로 검색해서 찾은 링크입니다.

    http://stackoverflow.com/questions/3538021/why-do-we-use-base64

    도움이 되시길...

    이상 "4가지less"였습니다.

    2
  • 앙앙이
    2015-04-17 12:50:43

    자신이 원하는 풍토를 만들고 싶다면 

    본인글도 그것에 충실해야지

    자신도  못 지키면서

    감나라 배나라 하지 않으셨으면하네요

    꽤 아주 타인글을 통해 본인이 느끼는 불쾌감을

    자신의글를 통해 다른 분들도 느꼈을수 있는데

    자기 기분  나쁜것만 말하면

    다른 분들이  수긍할까요

    1
  • kon
    1k
    2015-04-17 14:01:59

    싸가지 다음엔 똥인가요...

    남이 뭔말을 하던지, 자신이 남에게 어떤말을 했는지, 자기말을 듣는 사람이 어떻게 생각하는지..

    관심은 있으세요? 다 필요없고 그냥 맹목적으로 자기 말하고 싶은거만 계속 되풀이..

    그런식으로는 정상적인 소통이 불가능합니다. 당연히 남들도 불쾌하게 느끼지요.

    처음에 메인에 이글이 떠서 들어오게 됬지만, 

    하마님이 어떤분인지 잘 알았으니 앞으로는 들어오지 않도록 하겠습니다.

    혹시라도 같이 일하지 않게 되기를 바랍니다.

    4
  • 흐어엉
    1k
    2015-04-17 16:36:27

    와.... 알림떠서 봤는데 여기 아직도 이렇게 댓글 달아주시는 분들이 계셨네....ㅎㅎㅎ

    진심 답변 달아주시는 분들도 성격 대단히 좋으시고~~ 글쓴이분은 가관이시네요~~ㅎㅎ

    진심 성격들 좋으시네...ㅎㅎ 

    1
  • 무명소졸
    5k
    2015-04-17 16:51:42
    누가봐도 이상한 감정적인 부분을 제외하고 많이 배우고 갑니다.
    1
  • 서비스지향개발자
    7k
    2015-04-17 18:42:38

    // 우리가 진짜 이유는 아무도 모르고 , 그냥 써오는 기술들 중에 하나인듯 -.-a

    이건  내가라고 바꾸셔야 할 것 같네요. 

    보편적으로 우리는 멍청하다 제시하고 이거 왜 쓰는지 물어보는척 하면서 너희는 멍청하다

    이렇게 보이네요 글 의도가.ㅋ

    여기 댓글다는 제가 멍청한거죠--.

    쓸사람은 필요해서 쓰는겁니다.  암호화로직 중에도 들어가죠.

    출력한 문자 인코딩이 안깨진다 깨져도 상관 없다 하시면 안쓰셔도 됩니다.

    만에 하나라도 깨져선 안된다면 써야겠죠. 프로그램은 그렇게 짜는겁니다.

    그럼 수고요. 

    1
  • 동키
    74
    2015-04-18 12:28:56

    작성자분의 의도가 어찌되었던 간에 많은 배움 얻고 갑니다.

    역시 지식이 출중하신 분이 많으시군요

    자신이 부끄러워지면서 한편으로는 더 열심히 해야 겠다 생각이 드네요


    0
  • 서비스지향개발자
    7k
    2015-04-18 13:54:35

    -----하마------

    글 의도와는 상관 없이 다른 사람을 존중하지 않는 성향이 좀 보여서 그렇게 느꼈습니다.

    감수성 예민이라는 말로 또 ㅋㅋㅋ 그렇게 비하하시는데..

    공격적인 성향을 공격적이다 하는것이 감수성 예민해서 그렇다 생각하는게 좀 그렇네요...

    이런 논쟁을 하고싶었던게 아니라면 tip 게시판을 이용 바랍니다. 

     

    1
  • 읏샤
    99
    2015-04-18 22:28:34

    하마님 댓글을 다 읽어보았는데, 일단은 질문을 하시는 입장으로 글쓰는 예의가 좀 부족하신거 같네요

    이런식으로 질문하시는거면 질문을 하지마시는게 어떤지요?

    본인이 답을 얻던말던 제알바는 아니지만 시간내서 답변달아주신 분들에게 말투가 영거슬리네요


    "이글을 보시는분들은 쓸때없는 내용은 알아서 패스하시고 작은 도움되었으면 합니다."  이말 자체가 굉장히 공격적이시네요


    같은 말투로 말씀드려보면 싸가지 없다입니다.

    이건 논쟁이라고 볼수도 없고요 그냥 하마님이 예의가 없는거에요

    정신차리세요, 질문하러 온건지 싸우러 온건지 모르겠네요

    4
  • 흐어엉
    1k
    2015-04-20 10:03:49

    갑자기 꼴통소리 듣네요...

    어이없어서 이분한테 연락하는데 전화 안받으시네요...

    이분 연락처 알고싶으신분은 쪽지보내세요!~ 알려줄테니깐...

    온라인이라 모르는사람 수준평가하시면 됩니까? 

    1
  • hjinha2000
    69
    2015-04-20 13:55:13

    롤 해본 사람은 이정도 어그로는 대수롭지 않다.

    추천 ㄱㄱ

    1
  • 레버리지
    2k
    2015-04-29 16:22:18
    천사분들 진짜 많으시네요 ;;;;
    1
  • HJOW
    68
    2015-06-22 17:15:02

    논제가 정리가 안되면, 실제로 해보면 되는거지요.

    BASE64를 쓴 상태로 작동되는지 확인해 보고, BASE64를 빼서 확인해 보면 됩니다.


    그런데, 적어도 저는 BASE64를 안 썼을 때 문제가 생기는 상황을 여러 차례 겪었습니다.

    물론 BASE64 외에 다른 인코딩 방식이 있다면 또 모르겠지만,


    일단 이야기를 진행하기 위해, 바이트 데이터를 문자열 형태로 인코딩하는 방식이 BASE64 밖에 없다고 가정했을 때



    제가 겪었던 문제는 GET 방식으로 매개변수를 웹 서버에 넘길 때 생겼습니다.

    GET 방식의 경우 매개변수들은 말 그대로 "텍스트", 문자열입니다. 바이너리를 인코딩 안하고 보내서 서버 쪽에서 그걸 받아 출력해 보시면 이해가 되실 겁니다.

    심지어 일반 텍스트조차 제대로 못받는 경우도 있어서 기존 텍스트도 URL 인코딩을 해서 보내는 경우 여러 번 봤으리라 생각됩니다.


    물론 바이너리를 GET 방식으로 보내는 일이 생각보다 그리 많지는 않습니다만,

    SSL을 안쓰고 자체 암호화해 서버로 전송하는 방식의 프로젝트를 진행하고 있는 경우는 어쩔 수가 없습니다. 암호화 결과는 바이너리로 나오니까 이걸 보내려면 어쩔 수 없이 특정 문자들만으로 규격화된 형태로 만들어주는 BASE64나, 다른 인코딩 방식을 써야만 합니다.


    물론 방식을 POST로 바꾸거나 서버 환경을 바꿔서 인코딩 안해도 되게 만들면 되지 않느냐 할 수도 있지만, 자기 독단적으로 못바꾸는 경우도 분명히 있고, 무엇보다, 크로스 URL 문제 때문에 어쩔 수 없이 안보이는 iframe 을 만들어 써야 하는 경우도 있습니다. 이 때는 무조건 써야되죠.

    1
  • 이지훈
    2015-10-15 02:11:53

    두개의 이기종 시스템간에 텍스트 기반에 바이너리 데이터를 전달하고자 하는 경우 사용하는 방식 입니다. 뭐 웹에서도 사용하고 , 메일포멧 내부에서도 사용하고 하는 가장 범용적이 포멧이죠.

    아스키문자와 숫자 그리고 특수문자 2개로 이루어진 문자열만을 가지고 바이너리 데이터를 보내는 포멧이 되겠습니다.

    이기종 시스템은 다양한 이유로 바이너리 데이터를 전송하여 사용하는 경우 문제의 소지가 많습니다.

    이때 순수 텍스트포멧(아스키 문자)만을 가지고 바이너리를 보낼 필요성이 있지요. 보내온 데이터를 에디터로 열어서 그대로 복사해서 다른데 전송해도 데이터는 깨지지 않는 다는 뜻이거든요. 

    그래서 대문자(26개)+소문자(26개)+숫자(10개)+특수문자(=,/ 2개) 총 64개의 아스키 문자만을 가지고 표현합니다.

    1
  • devsss
    757
    2015-10-20 11:36:27

    많이 배우고갑니다 !

    개인적의견으론 글쓴이님께서 조금 몰아세우듯 질문하신거외에 뜬금없이 논지와 상관없이 댓글하나달며 욕하시는분들 이해가안되네요 ㅎㅎ

    기술의 why 를 늘 궁금해하는 초보개발자로선 아주좋은 공부가되었습니다 감사합니다 !

    -1
  • 레비 키아누
    12
    2016-05-27 13:59:52
    1년전 자료인데,, 저도 정말 도움 많이 받고 갑니다~!

    게시글 및 답변 모두 너무 감사합니다!


    1
  • kkey21a
    3k
    2016-08-05 14:20:40

    하~

    나도 참 평범하지는 않은건가?

    전 개인적으로 상당히 잘봤습니다.

    재밌기도 하구요.


    그나저나 하마님 정체는 궁금하긴 하네요.

    0
  • taeWoo
    552
    2017-03-09 01:42:08

    재밋네요ㅋㅋ

    질문자님께서는 http 통신을 주로 접하셔서 항상 base64를 쓰셔서 이 질문이 나오지 않았나 생각합니다.

    저는 반대로 tcp 통신부터 경험해서 처음 http로 서로 다른 플랫폼 간 통신할때 한글인코딩 때문에 엄청고생했었는데요, 당시 답은 base64였죠.

    base64가 뭔지는 위에서 충분히 설명하신거같고 왜쓰는지는, 서로다른 플랫폼에서의 문자 포맷을 유지하기위해서 인것 같아요.

    예를 들어서 api서버와 http로 통신하는 안드로이드 앱의 경우, 걍 주고받으면 한글 깨집니다. 근데  BA%12%56%

    이런씩으로 인코딩해서 어떤 환경으로 전송해도 디코딩할수 있게 하기위해 쓰는거죠^^

    0
  • taeWoo
    552
    2017-03-09 12:14:13

    저와 동일한 케이스였군요.

    저도 http 자체가 비효율적이라 생각해서 폭주했었습니다.

    그래서 앱계층에서 http처럼 동작하는 프로토콜을 만들었었죠ㅋㅋㅋㅜㅜ

    0
  • 여행매니아
    140
    2017-03-23 13:47:05

    바이너리 스트림을 주고 받을 수 있는 프로토콜에서는 필요없는 인코딩이 맞습니다. 하지만 세상에는 너무나 많은 프로토콜들이 있고 그 중에는 애초에 텍스트만 주고 받겠다고 만들었다가 나중에 바이너리 데이터를 주고 받을 상황에 직면한 프로토콜이 있습니다.

    우리가 하나 뿐인 줄 알고 있는 Base64 인코딩은 사실 여러가지 버전이 있습니다. 62개의 아스키문자는 공통으로 사용되고 나머지 두 개의 문자와 패딩문자가 약간씩 다르게 정의되어 있어요.

    그 중 최초로 개발되고 사용된 것은 90년대 초반 사용된 Original Base64입니다. Privacy-enhanced mail (RFC1421) 프로토콜에 적용되었다고 하네요. 요즘 흔히 MIME Base64라고 부릅니다.

    RFC1421링크 https://www.ietf.org/rfc/rfc1421.txt

    현재도 우리가 사용하는 이메일에 텍스트이외의 데이터는 Base64로 인코딩되어서 첨부됩니다. 그리고 브라우저에서 HTTP 프로토콜을 이용하여 서버로 파일을 전송할 때도 multipart/formdata 라는 이름으로 사용됩니다. 여러개의 파트로 이루어진 리퀘스트의 각각의 파트는 Base64로 인코딩되어 있습니다.

    MIME :: Multipurpose Internet Mail Extensions
    우리가 웹에서 흔히 이야기 하는 mime-type 도 그 뿌리는 같습니다.
    1
  • 리박사사사
    2
    2017-07-11 18:24:51

    다들 천사시네요.


    저도 HTTP GET 사용할때 한번 필요성을 느낀적이 있었습니다. 


    기타 이기종간에도 분명이 케이스가 있을 것 같네요.


    하마님은 답정너도 아니고 이해가 안되면, 좀더 검토해보고 질의를 하는게 맞지 않을까 싶습니다.


    자기 아는범주내에서 이해가 안되니 폭주하는겁니다.


    저도 좀 공격적으로 쓰긴했네요.  


    논리적으로 반박하신다고 한거같은데, 다른분들 글 몇개 보다보면 저는 참 이해가 잘되는 글이었습니다.


    하마님이 여러가지면에서 성장할 수 있는 계기가 되었으면 좋겠습니다.

    0
  • kamy
    42
    2018-03-20 14:12:58
    base64 궁금해서 찾아보다가 여기까지 왔는데 댓글들 매우 유익하네요... 위에서 어떤 논란이 있었는진 모르겠지만 어쨌든 정보 잘 얻고 갑니다
    0
  • 로그인을 하시면 답변을 등록할 수 있습니다.