linuxism

gcc 옵션 정리 - 자바 -D 옵션 의미

Development/C 2012. 3. 23. 21:25

유닉스, 리눅스 프로그래밍 필수 유틸리티 책 참조

gcc 전역 옵션
-E : 전처리 과정 화면에 출력
-S : 어셈블리 파일 생성
-c : 오브젝트 파일 생성
-v : 컴파일 과정 화면에 출력

전처리기 옵션
-include [헤더 파일 패스] : 해당 헤더 파일을 모든 소스내 추가
-D[매크로] : 외부에서 #define 지정
-D[매크로]=[매크로 값] : 외부에서 해당 매크로를 정의하고 값을 지정
-U[매크로] : 외부에서 #undef 지정
-M or -MM : make 기술 파일을 위한 소스 파일의 종속 항목 출력

경고 옵션
-Wall -W : 모든 경고메시지 출력
-w : 모든 경고 메시지 제거
-Werror : 모든 경고를 오류로 취급하여 컴파일 중단

최적화 옵션
-O0 : 아무런 최적화를 수행치 않음
-O1 or -O : 최적화 레벨 1 수행
-O2~3 : 최적하 레벨 2, 3 수행
-Os : 사이즈 최적화 수행

내가 자주 쓰는 것 기준으로 기록함. 까먹지 좀 말자.

출처 - http://116117.tistory.com/7

'Development > C' 카테고리의 다른 글

c - 함수의 원형 선언 (0)	2012.11.06
c - 전처리문의 종류 (0)	2012.10.28
헤더파일과 라이브러리 (0)	2012.02.24
C에서 정의된 FILE 구조체 (0)	2012.02.22
C 표준 라이브러리 (0)	2012.02.11

Posted by linuxism

jsp - *.jsp를 WEB-INF 아래에 숨겨라

Development/JSP & Servlet 2012. 3. 23. 21:14

Struts 등의 MVC 패턴 프레임웍을 사용할 경우에는 컨트롤러가 호출하는 자바 클래스에서 로직 처리를 끝내고서 JSP파일로 포워딩을 한다.

여기서 JSP파일은 실제로 웹 브라우저의 주소창에 나타나지 않는다.

포워딩을 할 경우 포워딩 시키기 전에 웹브라우저가 호출한 주소가 남아 있고, 포워딩된 주소는 단지 서버측에서 실행되어 결과만을 웹브라우저로 전달한다.

JSP/Servlet 컨테이는(앞으로는 웹 컨테이너)는 WEB-INF 디렉토리 이하를 보안상의 문제로 웹 브라우저를 통한 접근을 금지하고 있다. 하지만 포워딩을 통한 접근은 웹 브라우저를 통하지 않기 때문에 가능하다.

MVC 패턴에서 뷰로 사용되는 JSP 페이지들은 컨트롤러를 통하지 않고서 직접 액세스 될 필요가 전혀 없고 어떤 경우에는 그렇게 되면 안되는 때도 있다.

그래서 뷰로 사용되는 JSP 페이지를 WEB-INF 아래에 두는 것을 권장하는 것 같다.
그럴 경우, 결코 웹 브라우저를 통한 직접 액세스가 불가능하므로, 컨트롤러를 통해서 액세스 됨을 보장할 수 있기 때문이다.

또 다른 문제로, 로그를 웹 컨텍스트 디렉토리에 그대로 남기는 경우가 있는데, 절대로 그래서는 안 될 것 으로 보인다.
많은 사람들이 로그에 접속한 사람의 ID와 비밀번호, 그리고 주민등록번호등을 남기기도 하는데, 이것을 웝 컨텍스트 디렉토리에 둘 경우 우연찮게 유출될 가능성이 매우 높다. 로그 파일들도 WEB-INF 디렉토리 아래에 두거나, 아니면 웹 컨텍스트와 전혀 상관없는 디렉토리에 둬야 할 것으로 보인다.
제일 좋은 것은 웹 컨텍스트와 전혀 다른 디스크 파티션에 두는 것일 것 같다.
그렇게 하면 서로 다른 디스크를 사용하므로 시스템 성능 향상도 가져올 것이다.

출처 - http://blog.naver.com/reomereome?Redirect=Log&logNo=40014897720

'Development > JSP & Servlet' 카테고리의 다른 글

JSP에서 JSTL과 EL(Expression Language) 사용하기 (0)	2012.03.28
contentType charset과 pageEncoding의 차이점 (0)	2012.03.28
request.setCharacterEncoding (0)	2012.03.23
JSP (0)	2012.02.05
서블릿 Invoker (0)	2011.12.29

Posted by linuxism

request.setCharacterEncoding

Development/JSP & Servlet 2012. 3. 23. 13:32

<% request.setCharacterEncoding("euc-kr");%>

요청 파라미터의 캐릭터 인코딩을 한글로 하기 위한 것.

만일, 이 문장이 없을시 form을 통하여 넘어온 한글은 모두 깨져서 출력된다.

쉽게 말해서

<%@ page contentType="text/html;charset=euc-kr"%> 은

서버 -> 웹 브라우저 형태의 한글의 출력을 원활하게 해 주는 역할이며

<% request.setCharacterEncoding("euc-kr")%> 은

웹 브라우저 -> 서버 형태의 한글의 출력을 원활하게 해 주는 역할이다.

[출처] request.setCharacterEncoding("euc-kr")|작성자 skyblue

출처 - http://blog.naver.com/adelraidae?Redirect=Log&logNo=10014875384

[Tomcat/한글] 4.1.29 및 5.0.x 버전에서의 request.setCharacterEncoding 문제

[출처] 4.1.29 및 5.0.x 버전에서의 request.setCharacterEncoding 문제.. |작성자 슬레이어

파라미터의 한글처리를 위해 request.setCharacterEncoding 을 사용하거나 Characterset Encoding Filter를 사용할텐데요.. Servlet 2.3 스펙에 의하면 이것이 Request Body 에만 적용이 됩니다. 톰캣 4.1.29 및 5.0.x 버전에서는 이를 적용하여 request.setCharacterEncoding에 의해 설정된 인코딩이 POST방식의 파라미터에만 적용됩니다. GET방식의 파라미터에는 적용이 되지 않네요.

GET방식의 파라미터가 들어있는 QueryString은 URIEncoding 에 설정된 캐릭터셋을 이용하여 처리합니다. 따라서, 한글이 깨지지 않게 하기 위해서는 URIEncoding 을 별도로 설정해 주어야합니다. 이는 %CATALINA_HOME%/conf/server.xml 내에 있는 HTTP 호출을 처리하는 Connector 에서 설정할 수 있습니다. 톰캣의 기본 HTTP Connector를 예로 들면 다음과 같이됩니다.

<Connector port="8080"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

debug="0" connectionTimeout="20000"

disableUploadTimeout="true" URIEncoding="KSC5601"/>

마지막 속성인 URIEncoding="KSC5601" 이 URIEncoding의 캐릭터셋을 명시적으로 지정하는 속성이 되겠습니다.

혹시 톰캣 업글후 한글 파라미터때문에 고생하셨던 분이 계시다면 도움이 되길 바랍니다.

[출처] 4.1.29 및 5.0.x 버전에서의 request.setCharacterEncoding 문제.. |작성자 슬레이어

출처 - http://blog.naver.com/sj99yang?Redirect=Log&logNo=140001271631

'Development > JSP & Servlet' 카테고리의 다른 글

contentType charset과 pageEncoding의 차이점 (0)	2012.03.28
jsp - *.jsp를 WEB-INF 아래에 숨겨라 (0)	2012.03.23
JSP (0)	2012.02.05
서블릿 Invoker (0)	2011.12.29
JSP와 HTTP 주석 (0)	2010.12.12