아장아장 프로그래밍2

https://en.wikipedia.org/wiki/UTF-7

It was originally intended to provide a means of encoding Unicode text for use in Internet E-mail messages that was more efficient than the combination of UTF-8 with quoted-printable.

일단은 이렇게 이해해놓으면 좋겠다. email 도메인 특성 상 고안되어 사용된 것으로 보인다. 

컴퓨터 분야에서 쓰이는 Base 64 (베이스 육십사)란 8비트 이진 데이터(예를 들어 실행 파일이나, ZIP 파일 등)를 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식을 가리키는 개념이다.

문장이 끝나면 '=' 로 데이터가 끝났다는 것을 표시한다. 다시 데이터를 원복할 때 틀리지 않도록 방지하기 위함이다. 문장 하나를 Base64 에 의거해서 데이터를 변경하는 방법은 아래와 같다. 

1. 캐릭터 하나를 아스키 문자에 대응한다. 

2. 해당하는 아스키 문자를 8비트 패턴으로 변경한다. 

3. 8비트를 앞에서부터 6비트 씩 잘라서 다시 십진수로 변경한다. 

4. 그 값으로 나온 십진수를 Base64의 색인표에 대응시켜 나온 값으로 대응한다. 

5. 이 작업을 반복한다. 

* 출처: 위키 백과 참조 (https://ko.wikipedia.org/wiki/베이스64) 

----

url safe한 base64 란. 어렵지 않아요~

표1 base 64 original 

62, 63을 보면 각각 +, / 에 대응되는 것을 알 수 있다. 그러나 이는 데이터를 컨트롤할 때 오류를 일으킬 수 있는 문제가 될 수도 있고 = 가 url에서 사용하는 문자라는 문제 등이 제기 되었다. 따라서 아래와 같이 변경해버렸다. 아래의 url safe 한 base64 의 62, 63번은 - , _로 대체되었다. 

참조: https://tools.ietf.org/html/rfc4648

.  Base 64 Encoding with URL and Filename Safe Alphabet

   The Base 64 encoding with an URL and filename safe alphabet has been
   used in [12].

   An alternative alphabet has been suggested that would use "~" as the
   63rd character.  Since the "~" character has special meaning in some
   file system environments, the encoding described in this section is
   recommended instead.  The remaining unreserved URI character is ".",
   but some file system environments do not permit multiple "." in a
   filename, thus making the "." character unattractive as well.

   The pad character "=" is typically percent-encoded when used in an
   URI [9], but if the data length is known implicitly, this can be
   avoided by skipping the padding; see section 3.2.

   This encoding may be referred to as "base64url".  This encoding
   should not be regarded as the same as the "base64" encoding and
   should not be referred to as only "base64".  Unless clarified
   otherwise, "base64" refers to the base 64 in the previous section.

   This encoding is technically identical to the previous one, except 

JVM은 대략 네 섹션으로 메모리를 나눌 수 있다. 

스택

힙

메소드

텍스트

힙과 스택은 서로 마주보고 쌓임. 

그리고 힙을 다시 확대해서 볼 수 있다. 

그 안에 young(eden) old permanent가 존재하고, 나머지는 GC를 진행하는 방법에 의거해서 힙을 사용한다. GC관련된 좋은 내용(http://d2.naver.com/helloworld/1329)