아장아장 프로그래밍2

디렉토리 위치를 스택처럼 푸쉬해놓고 사용할 수 있다. popd로 뽑는다. 

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)

split을 하면 split의 기준이 되는 글자를 제외하고 나머지 부분이 앞 뒤로 배열 형태로 리턴된다. 

형식

my @arr = split /test/ , $str;

로그를 관리할 때는 일단 데몬을 믿기보다는 시스템을 믿어라. 그런 차원에서 믿을 수 있는 logrotate. 

로그를 관리 할 때 방법

1. 날짜를 시간계산한다. (epoch)

2. find -mtime 해서 파일의 생성일자를 확인 후 삭제한다. 

3. logrotate를 사용한다.

- 나는 로그로테이트가 잘려져 있는 로그에 대해서는 사용하기 어렵다고 생각했는데 그것도 아니라고 함. 

즉 로그를 관리할 때는 로그 로테이트를 사용할 것을 추천받음. 바이 펄. 

 관련 링크 

http://www.thegeekstuff.com/2010/07/logrotate-examples/

http://blueskai.tistory.com/101

http://pchero21.com/?p=1367

http://www.jamescoyle.net/cheat-sheets/676-logrotate-cheat-sheet

http://linux.die.net/man/8/logrotate

1. epoch로 초를 계산해서 30일을 초로 변환해서 뺀 다음에 그 값을 비교 

2. str2+time 을 이용해서 스트링을 epoch로 바꿔서 계산. 스트링을 변환하는 작업을 대신해주는 셈.

3. localtime을 이용해서 epoch로 초단위 계산. 

> 결국 초단위 계산을 통해서 스트링을 날짜 계산하게 된다. 

logrotate를 사용하면 처리하는 당일의 날짜로 파일을 압축할 수 있다. 

listup

https://github.com/spring-projects/spring-boot/blob/master/spring-boot-actuator%2Fsrc%2Fmain%2Fjava%2Forg%2Fspringframework%2Fboot%2Factuate%2Fhealth%2FAbstractHealthAggregator.java

여기에서 디버깅 걸림.

의심 중인 부분은 application.properties의 네이밍.