네트워크 전송상에서 안전한 통신을 위해
base64 encoding 나 web 의 경우 url encoding 을 사용하는 걸로 알고 있습니다.
이유가 ascii 같은 8bit 문자로 만드는 걸로 알고 있는데요.
ascii 문자가 아니면 전송시 누락될 수가 있는 건가요??
encoding 을 하는 실질적 이유를 모르겟습니다.
답변 달아주시면 감사하겠습니다.
web 에서는 ?& 요런 특수문자나 http:// 같은 url 의 값을 POST 등으로 넘길때. 값을 얻거나 구분하기가 곤란해서 사용했습니다.
전송 자체에서의 누락'은 아니고. 값'을 구분하는데서 잘못 구분될 수 있습니다.
---------------------------------------------------------------------------- 젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다. 정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
유니코드를 쓰는 경우 8비트 초과가 변형되는 경우가 있습니다.
언어별 문자인코딩에 따라 변형되기도 하고요.
참고:
UTF-8에 바이너리 자료를 인코딩할 때 제일 효율적인 방법은 뭐가 있을까요?http://kldp.org/node/129227
재벌 2세가 재벌이 될 확률과 금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록 자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전http://blog.aaidee.com
귀태닷컴http://www.gwitae.com
네트워크 전송상에서 안전한 통신을 위해 base64 encoding 나 web 의 경우 url encoding 을 사용하는 걸로 알고 있습니다.
사실이 아닙니다. 안전한 통신을 위하여 base64나 URL econding을 하는것이 아닙니다.
HTTP specification이 그렇게 정의하고 있는것 뿐입니다.
HTTP는 RFC2396(Uniform Resource Identifiers (URI): Generic Syntax)에 정의 되어있는 URI의 규칙을 따릅니다.
RFC2396에서는 URI path에서 허용가능한 문자의 셋을 다음과 같이 정의하고 있습니다.
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | "," reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," unreserved = alphanum | mark mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
escaped = "%" hex hex hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
네트워크 전송의 안전이나, 전송시 누락이랑은 관련이 없습니다. 그냥 규칙이죠. IETF에서 Non-ASCII를 이용한 URI syntax를 재정의하고, HTTP에서 그것을 받아들인다면 Non-ASCII 도 쓸수가 있겠죠.(그럴것 같지는 않습니다만.)
Base64도 비슷합니다. RFC 2616 뒤져보세요. MIME type과 관련한 RFC도 읽어보세요.
프로토콜에 정의된것들은 그냥 규칙이고 약속일뿐입니다.
URI 말고 내용에 관한 규칙은 없나요?
당연히 있죠.
Content-type field에 따라 관련한 여러 필드들이 있습니다. binary 형식도 있고, 7bit, 8bit형식도 있습니다.
RFC 2616 읽어보세요.
...
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
저도 그렇게 했는데.
web 에서는
?& 요런 특수문자나
http:// 같은 url 의 값을 POST 등으로 넘길때. 값을 얻거나 구분하기가 곤란해서 사용했습니다.
전송 자체에서의 누락'은 아니고. 값'을 구분하는데서 잘못 구분될 수 있습니다.
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
유니코드를 쓰는 경우 8비트 초과가 변형되는 경우가
유니코드를 쓰는 경우 8비트 초과가 변형되는 경우가 있습니다.
언어별 문자인코딩에 따라 변형되기도 하고요.
참고:
UTF-8에 바이너리 자료를 인코딩할 때 제일 효율적인 방법은 뭐가 있을까요?
http://kldp.org/node/129227
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
Quote:네트워크 전송상에서 안전한 통신을
사실이 아닙니다.
안전한 통신을 위하여 base64나 URL econding을 하는것이 아닙니다.
HTTP specification이 그렇게 정의하고 있는것 뿐입니다.
HTTP는 RFC2396(Uniform Resource Identifiers (URI): Generic Syntax)에 정의 되어있는
URI의 규칙을 따릅니다.
RFC2396에서는 URI path에서 허용가능한 문자의 셋을 다음과 같이 정의하고 있습니다.
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" |
"(" | ")"
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
네트워크 전송의 안전이나, 전송시 누락이랑은 관련이 없습니다.
그냥 규칙이죠. IETF에서 Non-ASCII를 이용한 URI syntax를 재정의하고, HTTP에서 그것을 받아들인다면
Non-ASCII 도 쓸수가 있겠죠.(그럴것 같지는 않습니다만.)
Base64도 비슷합니다.
RFC 2616 뒤져보세요.
MIME type과 관련한 RFC도 읽어보세요.
프로토콜에 정의된것들은 그냥 규칙이고 약속일뿐입니다.
URI 말고 내용에 관한 규칙은 없나요?
URI 말고 내용에 관한 규칙은 없나요?
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
당연히 있죠. Content-type field에
당연히 있죠.
Content-type field에 따라
관련한 여러 필드들이 있습니다. binary 형식도 있고, 7bit, 8bit형식도 있습니다.
RFC 2616 읽어보세요.
감사합니다.^^
...
댓글 달기