달력

52024  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

springframework.org 보다가 배낌

 

 

  <bean id="propertyConfigure"

      class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
      <list>
        <value>WEB-INF/jdbc.properties</value>
      </list>
    </property> 
  </bean>

 

  <bean id="dataSource"
     class = "org.apache.commons.dbcp.BasicDataSource">   
   <property name="driverClassName" ><value>${jdbc.driver}</value></property>
   <property name="url"><value>${jdbc.url}</value></property>
   <property name="username"><value>${jdbc.user}</value></property>
   <property name="password"><value>${jdbc.password}</value></property>
  </bean>
 

ㅋ.. 편리하군... 설정으로 끝나다뉘~~

Posted by tornado
|

Spring 시작..


http://www.springframework.org/download.html

에 가서 다운로드 받는다.

압축 풀고.. dist 디렉토리에 가보면 jar 파일, dtd, tld 등등이 보인다.

이 파일들을 사용할 수 있게 클래스 패스에 걸던, Eclipse 에서

해당 프로젝트에 등록하던지 한다.

=====================================
package test;

public interface Hello{

 public void sayHello();

}

=====================================
package test;

public class HelloImpl implements Hello{

 public String name;

 public HelloImpl(){
  System.out.println("Default Constructure called..");
 }

 public void sayHello(){ 
  System.out.println("Hello~~~ " + name);
 }

 public void setName(String name){
  this.name = name;
 }
}


=====================================


위의 파일을 Spring 설정 파일에 등록해야 사용할 수가 있다.

hello.xml 파일로 아래 내용 저장..

=====================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
  <bean id="hello"
 class="test.HelloImpl">
    <property name="name">
      <value>tornado</value>
    </property>
  </bean>
</beans>
=====================================


이제 이 파일을 테스트 해볼 클래스를 만든다.

=====================================
package test;

import org.springframework.context.*;
import org.springframework.context.support.*;

public class HelloTest{

 public static void main(String[] args) throws Exception{

  ApplicationContext ac =
   new FileSystemXmlApplicationContext("d:/source/spring/test/hello.xml");
  
  Hello hello = (Hello) ac.getBean("hello");

  hello.sayHello();

 }

}
=====================================

시작해보면.... HelloImpl 클래스의 생성자가 호출되는것을 볼 수 있고.

sayHello() 를 통해 메세지가 출력되는 것을 볼수 있당..

property 엘리먼트를 이용해서 특정 메소드에 변수를 전달 할 수도 있다.

 

내친김에 DataSource 를 등록해볼까나???

jndi 도 가능하고, DBCP 도 가능하다.

Application 이니.. DBCP 의 BasicDataSource 를 등록해 보자..

hello.xml 파일에 bean 을 등록...

(물론 DBCP 를 위한 commons-pool, commons-dbcp, commons-collection,
mysql driver 등은 준비해야쥐)

  <bean id="dataSource"
   class = "org.apache.commons.dbcp.BasicDataSource">
   
   <property name="driverClassName" >
     <value>org.gjt.mm.mysql.Driver</value>
   </property>
   <property name="url">
     <value>jdbc:mysql://localhost:3306/test</value>
   </property>
   <property name="username">
     <value>root</value>
   </property>
   <property name="password">
     <value>1111</value>
   </property>
  </bean>

위에 부분을 등록한다.


HelloTest 클래스의 main 메서드에 아래만 등록해 보면 된다.

절라 간단..


DataSource ds = (DataSource)ac.getBean("dataSource");

if(ds == null) System.out.println("null");
else System.out.println("Ok");

Connection conn = ds.getConnection();

PreparedStatement pstmt = conn.prepareStatement("select now()");

ResultSet rs = pstmt.executeQuery();

if(rs.next()){
   
    System.out.println(rs.getString(1));
}

conn.close();

 

시작은 했는데...... 개념이 헷갈리넹 ㅜㅜ

설정은 또 왜이리 많은겨  -.-;;

 

음주가무 해야 하는데 쩝~

 

Posted by tornado
|

http://forum.springframework.org/index.php

 

Spring Framework Forum IndexSpring Framework
Spring Framework Support Forums
 

 

스프링 사용하다가 막히면 바로 찾게 되는 곳.

싱싱하고 현장에서 검증된 유용한 정보가 올라온다...

Posted by tornado
|

벨로시티에서 제공하는 툴들은 여러 종류가 있다.

GenericTools
VelocityView
VelocityStruts

이 있는데... 간단하게 GenericTools 에 있는 DateTool 을 사용해봤다.

http://jakarta.apache.org/velocity/tools/generic/

요기 GenericTools 를 볼 수 있당.

사용법은 무지 간단..

먼저 Tool 을 사용하기 위해..  toolbox.xml 을 WEB-INF/ 디렉토리에 생성하고,
VelocityViewServlet 에 해당 툴을 등록시켜주면 된다.

=============================================
<?xml version="1.0" encoding="UTF-8"?>

<toolbox>

  <tool>
    <key>date</key>
 <scope>application</scope>
 <class>org.apache.velocity.tools.generic.DateTool</class>
  </tool>

</toolbox>
=============================================

web.xml 에서 VelocityViewServlet 에 init-param 으로 toolbox.xml 을 지정해 주어야 한다.

=============================================

<init-param>
  <param-name>org.apache.velocity.toolbox</param-name>
  <param-value>/WEB-INF/toolbox.xml</param-value>
</init-param>

=============================================

이렇게 적어주고... 해당 컨텍스트 리로딩..

마지막으로 test.vm 파일에 아래와 같이 적어준당..

=============================================

<BR><HR><BR>
$date.getDate()

<BR>
$date.format('yyyy-MM-dd aaa H:m:s', $date)

<BR>
$date.short || $date.medium || $date.long

<BR>
$date.get('yyyy-M-d H:m:s a')

=============================================

http://localhost:8080/velocity/test.do 

오옷... 날짜 나와따~~

이런식으로 제공되는 Tool들을 지정해서 쓰면 된당..


 

Posted by tornado
|

디렉토리만 뽑아와야 하는 상황..

java.io 패키지에 보면 FileFilter 와 FilenameFilter 인터페이스가 있다.

 

두개의 차이점은 정의된 메소드인데..

FileFilter 에는 accept(File pathname) 이 있고.

FilenameFilter 에는 accept(File dir, String name) 이 있다.

 

만약 *.exe 파일만 고르고 싶다고 하면 FilenameFilter 를 쓰면 되고...

디렉토리만 골라서 보고 싶을때는 FileFilter 인터페이스를 구현해 주면 된다.

 

   File[] fileNames = f.listFiles(new FileFilter(){
    public boolean accept(File pathname){     
     return pathname.isDirectory();
    }
   });

 

이런식이 되겠지..

 

만약 확장자로 걸러내고 싶다면...

File[] fileNames = f.listFiles(new FilenameFilter(){
  public boolean accept(File dir, String name){

    return name.endsWith(".exe");

  }

});

 

IO 를 특정부분만 쓰다보니.. 이런데서 잠깐씩 헤매고 있네 ㅡㅡ

'JAVA > JSE' 카테고리의 다른 글

[펌] JVM GC와 메모리 튜닝  (0) 2005.05.18
[펌] 손쉬운 정적 분석 툴로 버그 잡기  (0) 2005.05.11
[nio] Channels 클래스  (0) 2005.01.17
[펌] Sorting Algorithm  (0) 2005.01.15
[link] 자바 검색 봇~  (0) 2005.01.11
Posted by tornado
|

벨로시티에 스트러츠도 함 붙여볼까??

필요한 jar 파일을 lib 에 복사하자..

struts.jar 는 필수이고

struts 구동에 필요한 commons-digester, commons-beanutils, validator 등등을 복사한다.


WEB-INF 디렉토리에 struts-config.xml 파일을 생성한다.

=====================================================================

<?xml version="1.0" encoding="EUC-KR"?>
<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>
 
 <data-sources />
 
 <form-beans />   
 
 <global-exceptions />   
   
 <global-forwards />     
   
 <action-mappings>
  
 </action-mappings> 
           
 <controller />   

</struts-config>


=====================================================================

암것도 없다 ㅡㅡ;;


web.xml 에 ActionServlet 을 등록한다.


<servlet>
  <servlet-name>action</servlet-name>
  <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> 
  <init-param>
 <param-name>config</param-name>
 <param-value>/WEB-INF/struts-config.xml</param-value>
  </init-param>

  <init-param>
    <param-name>locale</param-name>
 <param-value>true</param-value>
  </init-param>

  <load-on-startup>2</load-on-startup>
</servlet>

 

<servlet-mapping>
  <servlet-name>action</servlet-name>
  <url-pattern>*.do</url-pattern>
</servlet-mapping>


머 위치는 적당히 알아서 넣는다.

톰캣 다시 시작... (로그에 보면... struts.jar, commons-xxx 등등이 로딩된게 보일게다..)


간단한 Action 을 만든다...

===============================================================
package test;

import javax.servlet.*;
import javax.servlet.http.*;

import java.io.*;

import org.apache.struts.action.*;

public class TestAction extends Action{
 
 public ActionForward execute(
  ActionMapping mapping ,
  ActionForm form ,
  HttpServletRequest req ,
  HttpServletResponse res)
  throws IOException , ServletException
 {
  
  String target = "success";


  return mapping.findForward(target);
 }

}

 

===============================================================

간단하게 하는거라...
ant 안쓰고 그냥 지저분하게 컴파일함..
예전에 ant 모를때는 ejb 컴파일을 .bat 파일로 만들어서
컴파일 했다는 ㅡㅡ;

D:\tomcat_ex\webapps\velocity\WEB-INF\classes\test>javac -classpath %CLASSPATH%;d:\tomcat_ex\common\lib\servlet.jar;..\..\lib\struts.jar *.java


컴파일 되었으면... struts-config.xml 에 action 등록..

==============================================================


<action-mappings>

  <action
 path = "/test"
 type = "test.TestAction"
 scope = "request">

 <forward name="success" path="/test.vm" />

  </action>
 
</action-mappings> 


==============================================================

http://localhost:8080/manager/html/reload?path=/velocity 

해당 컨텍스트 리로드 하고..

http://localhost:8080/velocity/test.do 를 요청...


오옷... test.vm 으로 포워딩 대따...

 


request 에 객체 를 담아볼까낭~~~


TestAction 클래스를 수정한당...

================================================================

package test;

import javax.servlet.*;
import javax.servlet.http.*;

import java.io.*;
import java.util.*;

import org.apache.struts.action.*;

public class TestAction extends Action{
 
 public ActionForward execute(
  ActionMapping mapping ,
  ActionForm form ,
  HttpServletRequest req ,
  HttpServletResponse res)
  throws IOException , ServletException
 {
  
  String target = "success";
  
  List _list = new ArrayList();

  for(int i = 0; i < 10; i++){
   _list.add(new String("Number : " + ( i + 1) ) );
  }

  req.setAttribute("TEST_LIST", _list);

  return mapping.findForward(target);
 }

}

================================================================

컴파일 하고... Manager 에서 리로딩 하던지.. 톰캣 재시작 하던지..


test.vm 에 아래 코드 추가..

#foreach( $t in $TEST_LIST)

<B>$t</B></br>


#end


http://localhost:8080/velocity/test.do <-- 요청한다..


오옷... 찐하게 뭐가 나와따~~~~

 

Tool 좀 더 보구 가지고 놀아야쥐...

 

'JAVA > Framework' 카테고리의 다른 글

첨으로 Spring 해바따..  (0) 2005.02.14
[펌] Spring Framework Forum  (0) 2005.02.14
벨로시티 GenericTool 중에.. DateTool  (0) 2005.02.12
[울트라 초 간단] Velocity 시작 ㅡㅡ  (0) 2005.02.12
헷갈리 ㅡㅡ;;  (0) 2005.02.12
Posted by tornado
|

먼저 톰캣을 설치(4.1.31 zip 버젼..)

설치하고 conf 디렉토리에서 tomcat-users.xml 파일에 admin, manager 정보 입력.

  <user username="manager" password="123456" roles="manager"/>
  <user username="admin" password="123456" roles="admin"/>

velocity-1.4 다운로드하고 압축 풀고...
velocitytool 도 다운로드 하고 압축 풀고...

톰캣에 velocity 컨텍스트 를 만든다.

webapps/velocity
webapps/velocity/WEB-INF
webapps/velocity/WEB-INF/classes
webapps/velocity/WEB-INF/lib

이렇게 만들고 lib 디렉토리에
velocity-1.4.jar
velocity-tools-view-1.1.jar   <-- velocityTool 에 있음

일단 이렇게 두개의 파일을 복사... (나머지는 차근차근 알아가자..)

 

WEB-INF 디렉토리에 web.xml 파일을 만들고.. VelocityViewServlet 을 등록한다.

전체 xml 파일은 아래와 같음.
=================================================================
<?xml version="1.0" ?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

 <!-- Define Velocity template compiler -->
 <servlet>
   <servlet-name>velocity</servlet-name>
   <servlet-class>
  org.apache.velocity.tools.view.servlet.VelocityViewServlet
   </servlet-class>
<!--
   <init-param>
  <param-name>org.apache.velocity.toolbox</param-name>
  <param-value>/WEB-INF/toolbox.xml</param-value>
  </init-param>

   <init-param>
  <param-name>org.apache.velocity.properties</param-name>
  <param-value>/WEB-INF/velocity.properties</param-value>
  </init-param>
-->
  <load-on-startup>10</load-on-startup>

 </servlet>


 <servlet-mapping>
   <servlet-name>velocity</servlet-name>
   <url-pattern>*.vm</url-pattern>
 </servlet-mapping>

</web-app>

=================================================================


toolbox 와 velocity.property 는 아직 설정하지 않았당..
없으면 지가 알아서 Default 프라퍼티를 설정하는듯 하다..

하여간에 서블릿 매핑에서 vm 확장자로 들어오는 요청은
VelocityViewServlet 으로 요청이 가게 되고.. 그곳에서 번역되어서
결과물이 출력된다.


일단 톰캣을 시작하고... logs 디렉토리에서 localhost_log 중 최신 파일을
보면 아래처럼 벨로시티가 잘 시작되었고 어짜고 저짜고.. 나옴..


2005-02-12 11:16:45  Velocity   [info] VelocityViewServlet: No custom properties found. Using default Velocity configuration.
2005-02-12 11:16:45  Velocity   [info] **************************************************************
2005-02-12 11:16:45  Velocity   [info] Starting Jakarta Velocity v1.4


이렇게 나오면.. 간단한 벨로시티 테스트 파일을 만든다...

 

=================================================================
## test.vm
#set ($name = "tornado" )

Hello $name !!

=================================================================

 

브라우저에서 http://localhost:8080/velocity/test.vm 으로 요청...

오옷.... $name 변수에 대입된 값이 출력돼써~~!!!

log 파일을 보니 아래와 같이 로그가 남았다..


2005-02-12 11:18:35  Velocity   [info] ResourceManager : found /test.vm with loader org.apache.velocity.tools.view.servlet.WebappLoader


다같이 벨로시티에 빠져 볼까요~~ 빠져 봅시다~~

근데 게임기능 되나요??

 


 

Posted by tornado
|

헷갈리 ㅡㅡ;;

JAVA/Framework 2005. 2. 12. 10:10

이제 하나씩 시작해봐야쥐..

Posted by tornado
|

http://wiki.blojsom.com/wiki/display/blojsom

 

오... 벨로시티로 스킨을 .....

 

 

http://b2evolution.net/  <--- PHP 로 만든 블로그...

 

asp 로 만든건 없나??

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] lucene index browser 오옷~ 00  (2) 2005.03.31
[링크]proxool.. 편리한 풀...  (0) 2005.03.22
간단한 trackback ping 보내는 JSP ..  (0) 2005.02.04
[펌] Trackback CGI 설계  (0) 2005.02.03
[펌] 검색엔진 만들기  (0) 2005.01.21
Posted by tornado
|

심심해서(?) 잠깐 만들어봄 ㅡㅡ

PHP 는 금새 했는데 JSP 는 HttpURLConnection 에서 잠깐 헤맴 ㅜㅜ

 

<%@ page contentType="text/xml; charset=euc-kr" %>
<%@ page import="java.util.*, java.net.*, java.io.*, org.jdom.*, org.jdom.input.*" %>
<%


 String receipt = "http://blog.empas.com/yheesung/tb/6327649";


 String url = "http://yheesung.egloos.com/";


 String title = URLEncoder.encode("트랙백연습", "euc-kr");


 String blog_name = URLEncoder.encode("tornado Blog", "euc-kr");


 String excerpt = URLEncoder.encode("이 글의 내용은 어짜구.. 저짜구......", "euc-kr");


 URL receiptURL = new URL(receipt);

 

 HttpURLConnection conn = (HttpURLConnection)receiptURL.openConnection();

 

 conn.setDoOutput(true);

 

 //==================================================================
 // 특별히 Header 정보를 셋팅할 필요는 없다.
 // 보내는 부분에서는 아무 문제가 없었다.
 // Test : 이글루, 네이버, 엠파스
 //==================================================================

 conn.setRequestMethod("GET");
 
 //conn.setRequestMethod("POST");

 PrintWriter pw = new PrintWriter(conn.getOutputStream());

 pw.write("url="+url);

 pw.write("&title=" + title);

 pw.write("&blog_name=" + blog_name);

 pw.write("&excerpt=" + excerpt);

 pw.flush();

 pw.close();

 BufferedReader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));

 //==================================================================
 //
 // 헐... 왜 xml문서 앞에 공백을 넣어서리..... ㅡㅡ;;
 //
 //================================================================== 
 
 String txt = "";

 while( (txt = reader.readLine()) != null){

  if(txt.indexOf("<?xml") > -1){

   break;

  }

 }

 String message = null;

 String status = null;

 boolean errorFlag = true;


 SAXBuilder builder = new SAXBuilder();

 builder.setValidation(false);

 builder.setIgnoringElementContentWhitespace(true);
  
 Document document = builder.build(reader);

 Element rootElement = document.getRootElement();

 List list = rootElement.getChildren();

 for(int i = 0; i < list.size(); i++){

  Element _el = (Element)list.get(i);


  if("error".equalsIgnoreCase(_el.getName())){

   status = _el.getValue();

  }

  if("message".equalsIgnoreCase(_el.getName())){

   message = _el.getValue();

  }

 }


 
 if("1".equals(status)){

  out.println("트랙백 핑을 보내는 중 에러가 발생하였습니다!!");

  out.print("<BR>Error code : " + status);

  out.print("<BR>Error message : " + message);

 }else{

  out.println("트랙백 핑이 에러가 없이 전송되었습니다");

 }

 reader.close();

 conn.disconnect();

%>

'JAVA > JSP_Servlet' 카테고리의 다른 글

[링크]proxool.. 편리한 풀...  (0) 2005.03.22
[링크]자바로 만든 블로그  (2) 2005.02.11
[펌] Trackback CGI 설계  (0) 2005.02.03
[펌] 검색엔진 만들기  (0) 2005.01.21
[javamail] 제목 깨질때...  (0) 2005.01.18
Posted by tornado
|

이 문서는 Trackback CGI를 제작하기 원하는 이들을 위해 제공하는 도움서일 뿐입니다.
제로보드용 블로그 스킨 Paz에 트랙백 기능을 추가해달라는 요구들이 많더군요. 제가 직접 할까하고 손 댔다가, 역시 코딩은 만만치 않군요. ^^; 저보다 더 잘 코딩해주실 분들이 많이 계시고, 또 현재 준비중이신 것 같아서 제가 직접 하는 것보다는 그분들을 위한 CGI설계에 도움되는 쪽이 나을 것 같아 이 문서를 작성합니다.

트랙백의 flow
트랙백은 간단한 HTTP + XML의 형태로 구현가능합니다.
편의상 트랙백을 보내는 쪽을 sender, 받는 쪽을 receiver라고 칭하겠습니다.

sender.cgi에서 receiver.cgi로 HTTP를 통해 보내는 정보는 다음과 같습니다.

POST Method


title : 해당 엔트리의 타이틀
url : 해당 엔트리의 고유주소
excerpt : 해당 엔트리의 내용 요약(혹은 설명)
blog_name : 블로그의 이름

그렇다면 receiver는 POST로 넘어온 이 값을 DB나 TXT등으로 저장 후, 잘 받았다는 값을 sender쪽에 회신해주면 됩니다.

이상이 트랙백의 전부입니다. 너무 간단하다구요? ^^; 맞습니다.

조금 더 상세히 살펴보도록 하지요.

사용자가 트랙백을 보내고자 할 때 sender와 receiver가 해야할 일은 다음과 같습니다.

1)트랙백 메시지 준비하기.
receiver쪽에 전달할 트랙백 메시지를 준비합니다. 필요한 어트리뷰트는,
*title:현재 문서의 제목
*url:현재 문서의 고유주소
*excerpt:현재 문서 내용의 요약 혹은 설명 (255자 이하로 축약하는 것이 좋음. 본문 내용에서 적당히 끊으면 되겠죠?)
*receipt:받는 쪽의 트랙백수신 CGI 주소 (사용자가 텍스트 박스등에 입력하도록 해야겠지요?)

2)트랙백 전달
receipt로 title, url, excerpt의 값을 POST 메쏘드를 이용해 전달합니다. 그리고 회신이 돌아올 때까지 기다립니다.

3)트랙백 수신
receiver쪽에서는 receipt로 넘어온 값을 확인한 후, sender에게 회신을 보내줍니다.
다음은 php로 작성한 간단한 receiver.php입니다.

<?
$fh = fopen("./tb.log", 'w');
$results = print_r($_POST, true);
$id = $_GET['id'];
fwrite($fh, $id);
fwrite($fh, $results);
fclose($fh);
header("Content-Type: text/xml");
print "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n";
print "<response>\n";
print "<error>0</error>\n";
print "</response>\n";
?>


이것만으로도 충분히 트랙백을 수신할 수 있습니다. 물론 실제로 활용하기 위해서는 받은 트랙백값을 DB에 저장해야겠지요. 위의 코드에서 id는 수신하는쪽의 문서의 id를 말합니다. 각 개별문서마다 일일이 트랙백 수신 CGI를 만들어 줄 수 없기 때문에 공용 수신 CGI를 이용해야 할테고, 그러자면 송신측에서는 자기가 어느 문서를 향해 보내는지 알리기 위한 id가 필요하겠죠. 이 id는 트랙백 규격에는 포함되지 않으므로 GET method로 그냥 보내면 됩니다. receiver.php?id=123 이런 식으로 말이죠.

header()이하 부분은 정상적인 트랙백 메시지일 경우 잘받았다는 회신으로 Sender쪽에 Response해줍니다. php에서는 그냥 print로 출력해버리면 되지요. ^^; 만약 정상적인 트랙백 메시지가 아니라서 수신을 거부할 경우 error 항목을 0대신 1로 바꿔주면 됩니다.

4)트랙백 회신 확인
이번엔 sender쪽에서 Response 받은 문자열을 분석해서 error가 0인지, 1인지 확인하면 되겠죠. 그에 따라 적당한 메시지를 출력해주면 끝.

5)문서 출력시
일단 DB를 뒤져서 이 문서로 들어온 트랙백 데이터가 있는지 확인합니다. 데이터가 있으면 문서 중에 적당한 자리에 그 정보를 붙여 넣으면 됩니다.


6)트랙백 자동발견용 RDF 아이템 문서내 삽입.
트랙백을 걸 수 있게 준비가 되면, 트랙백을 걸어도 좋다는 메시지를 문서속에 삽입해야합니다.

<!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">

<rdf:Description
rdf:about="[Entry Permalink]"
dc:title="[Entry Title]"
dc:identifier="[Entry Permalink]" />
trackback:ping="[http://yourserver.com/cgi-bin/receiver.cgi/][TrackBack ID]"
</rdf:RDF>
-->

위의 코드를 각 문서내에 적절히 삽입하시면 됩니다. []안의 내용은 삽입되는 문서에 맞게 수정되어야겠지요?
만약 트랙백을 보내기 전에 먼저 해당 문서를 읽어들여, 저 코드를 발견한다면 사용자가 receiver.cgi?id=xxx식으로 일일이 적어줄 필요가 없겠죠? MT등에서는 실제로, 엔트리 작성시 본문에서 언급된 모든 링크를 찾아 다니면서 저 아이템이 있으면 자동으로 트랙백을 걸어줍니다. 사용자가 트랙백할 주소를 일일이 지정하지 않아도 되니 편리하겠지요. 요런 기능도 여유가 되시면 구현하면 좋겠죠.

그외의 트랙백 관련 확장으로는, 카테고리 별 자동 트랙백(특정 카테고리로 입력되는 엔트리는 무조건 특정 주소로 자동으로 트랙백 보내기)과, 한번에 복수개의 트랙백 보내기등이 구현되면 될 것 같네요.

혹시 개발시에 문제가 되거나 궁금하신 점이 있으면 말씀하세요.

<출처 :
http://eouia.net >

'JAVA > JSP_Servlet' 카테고리의 다른 글

[링크]자바로 만든 블로그  (2) 2005.02.11
간단한 trackback ping 보내는 JSP ..  (0) 2005.02.04
[펌] 검색엔진 만들기  (0) 2005.01.21
[javamail] 제목 깨질때...  (0) 2005.01.18
[펌] 메일 헤더 구성 요소  (0) 2005.01.17
Posted by tornado
|
검색엔진 만들기 작성자 : hjnam93, 등록일 : 2004-08-22 23:28:30

 

지금 쓰는 내용은 "Modern Information Retrieval" (Ricardo Baeza-Yates, Berthier Ribeiro-Neto공저)과 Information Retrieval Data Structures & Algorithms(William B. Frakes, Ricardo Baeza-Yates공저)의 내용과 내가 생각하는 정보검색에 대한 사항들을 정리한 것입니다. 자유롭게 참조하세요.

 ..

내용 전체보기

'JAVA > JSP_Servlet' 카테고리의 다른 글

간단한 trackback ping 보내는 JSP ..  (0) 2005.02.04
[펌] Trackback CGI 설계  (0) 2005.02.03
[javamail] 제목 깨질때...  (0) 2005.01.18
[펌] 메일 헤더 구성 요소  (0) 2005.01.17
[펌] [MAIL] MIME 관련  (0) 2005.01.17
Posted by tornado
|

한글 제목 자체가 깨져서 들어올 경우가 있다.

 

헤더의 Subject 부분이 =?인코딩?B?안전한 문자 ?=  처럼 들어오면 인코딩이 가능하다.

 

그런데 Subject 부분에 그냥 한글을 쓸 경우 제목이 깨지게 되는데..

 

byte[] bytes = string.getBytes("iso-8859-1");

 

String subject = new String(bytes, "euc-kr");

 

과 같이 ISO-8859-1 로 풀어 헤쳐서 다시 스트링으로 조립해 줘야 한다는 ㅡㅡ;;

 

포털 메일에서 첨부 파일 있을때는 안전한 문자로 변형시켜 캐릭터 셋 포함시키고 전달하고..

 

첨부 파일이 없을때는 그냥 보내고 ㅡㅡ

 

어떤 포털은 또 반대로 보내서리... 경우의 수가 여러개 생기넹 ...

 

base64 로 온거 풀어 헤칠때두 어디는 제대로 파싱되는 반면..

 

어디는 깨지고 ㅡㅡ

 

야후에서 보낸거 다음에서 보면 제대로 안보이고 ㅡㅡ

 

 

개발자 맘대로 메일 보내는 부분을 만들면 어쩌냐고여...

 

RFC 규약은 괜히 있냐고여~~ 짱나네 -.-;;

 

 

 

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] Trackback CGI 설계  (0) 2005.02.03
[펌] 검색엔진 만들기  (0) 2005.01.21
[펌] 메일 헤더 구성 요소  (0) 2005.01.17
[펌] [MAIL] MIME 관련  (0) 2005.01.17
[펌] 코드시스템및 한글문자체계  (0) 2005.01.17
Posted by tornado
|

헤더는 매우 다양한 구성요소가 있습니다. 메시지를 전달하기 위해 반드시 필요한 것도 있고 꼭 필요하지 않은 것도 있습니다. 또 어떤 헤더는 여러분이 입력하지 않아도 자동으로 입력되는 것도 있습니다. 자동으로 입력되는 헤더는 다시 메일/뉴스 프로그램이 직접 기록하는 것과 서버에서 직접 기록하는 것이 있습니다.

자신이 직접 입력할 수 있는 헤더

자신이 직접 입력할 수 있는 헤더는 주로 메일 프로그램에서 새 메시지를 작성할 때 입력할 수 있는 항목과 프로그램의 설정 항목에서 작성한 내용입니다. 프로그램의 설정 항목에 기록한 내용은 이메일을 보낼때마다 자동으로 헤더에 첨부됩니다. 자신의 소속, 이메일 주소, 진짜 이름등등은 이메일을 보낼때마다 매번 기록할 필요가 없을 것입니다. 그래서 그런 것들은 프로그램 설정 항목에 기록하도록 해서 자동으로 입력할 수 있도록 하는 것입니다. 그러나 받는 사람, 제목, 참조, 숨은 참조등은 이메일을 보낼때마다 매번 바뀌는 항목이라서 매번 새롭게 입력해야 합니다.

 

1. 받은 사람
헤더 - To:

메시지를 보내려면 당연히 받는 사람의 주소를 적어야겠지요. To: 헤더에 아무것도 입력하지 않으면 메시지를 보낼 수 없습니다. 메일 서버는 이곳에 있는 주소로 여러분의 메시지를 보냅니다. 프로그램에서 "수신인" 또는 "받는 사람" 입력창에 입력한 내용이 To: 헤더에 기록됩니다.

2. 참조
헤더 - Cc:

Cc는 "Carbon Copy"의 약자로써 원본 메시지를 참조하는 것을 말합니다. 참조는 어떤 메시지를 여러 사람에게 보낼 때 원본 메시지와는 별도로 다른 사람이 그 메시지를 참조삼아 읽으라고 보내는 경우에 사용합니다. A라는 사람에게 보내는 메시지를 B와 C가 참조할 필요가 있다고 생각한다면 A를 받는 사람으로 지정하고 B와 C는 참조로 지정하여 메시지를 보내면 됩니다. 참조형식으로 보낸 메시지의 헤더에는 Cc: 부분에 받는 사람의 주소가 모두 표시됩니다.

3. 숨은 참조
헤더 - Bcc:

Bcc는 "Blind Carbon Copy"의 약자인데, 숨은 참조라고 합니다. 숨은 참조는 여러 사람에게 메시지를 보낼 때 누구에게 그 메시지를 보냈는지 알 수 없도록 참조인의 주소를 숨길 때 사용합니다. 참조를 나타내는 Cc: 헤더와는 달리 숨은 참조란에 기록한 주소는 헤더에 표시되지 않습니다. 100명에게 메시지를 보낼 때 참조를 이용하는 것은 좋지 못합니다. 100명은 자신에게 필요하지 않은 99명의 이메일 주소가 헤더에 포함된 이메일을 받아야할 것이니까요.

4. 제목
헤더 - Subject:

보낼 메시지의 제목을 나타내는 헤더입니다. 설령 여러분이 제목을 적지 않고 이메일을 보냈더라도 헤더는 표시됩니다. 제목을 "안녕"이라고 적었다면 "Subject: 안녕"이라고 될 것이고 제목을 적지 않았다면 단지 "Subject:"라고만 헤더에 표시될 것입니다.

프로그램의 설정 메뉴에서 기록하는 헤더

사용하는 이메일 프로그램의 설정 메뉴에서 기록한 정보는 보내는 이메일 메시지의 헤더에 자동으로 기록됩니다. 이런 정보는 늘 입력할 필요가 없는 고정된 정보입니다. 이메일을 보내며 매번 자신의 이메일 주소와 이름, 소속, 답신받을 주소를 입력할 필요는 없을 것입니다. 그런 것들은 자동으로 입력하도록 설정해 두는 것이 훨씬 편할 것입니다.

 

1. 전자 우편 주소
헤더 - From:

자신의 주소가 없다면 보낸 메시지가 잘못되었을 때 어디로 반송되어 올지 알 수 없을 것입니다. 자신의 이메일 주소를 적지 않으면 메시지를 작성할 수 없습니다. 정 주소를 밝히기 싫다면 가짜 주소라도 적어야 합니다. somebody@nonono.com 처럼 정체불명의 주소라도 적지 않으면 메시지를 작성할 수 없습니다. 아웃룩 익스프레스에서 From: 헤더를 설정하는 곳은 [계정] 메뉴에서 사용자 정보 입력창입니다. [전자 우편 주소]라는 곳에 입력한 정보가 From: 헤더에 기록됩니다.

2. 이름
헤더 - From:


자신의 이름을 적는 곳입니다. 이곳을 비워두면 메시지를 작성할 수 없습니다. 자기 이름을 입력해도 좋고, 이름을 밝히기 싫다면 가짜 이름 - 'SkyHawk'와 같은 별명이나 가짜 이름을 적어도 무방합니다. 여기에 적은 이름은 From: 헤더에 기록되어 다음과 같이 나타납니다.

From: "Lee JunYoung"
leejuy@hyowon.pusan.ac.kr

3. 회신 주소
헤더 - Reply-To:


상대방이 여러분의 이메일에 대해 회신하기 위해 이메일 프로그램의 회신 기능을 사용할 때 이곳에 적어둔 주소로 답신이 보내집니다. 회신 주소 입력창에 굳이 주소를 적지 않아도 괜찮습니다. Reply-To 헤더가 없을 경우 '전자 우편 주소'로 답신이 보내지게 됩니다.

Reply-To: "Lee JunYoung" <leejuy@hyowon.pusan.ac.kr>

자동으로 붙는 헤더

여러분이 받은 이메일의 헤더를 잘 살펴 보십시오. 그곳에는 여러분이 설정할 수 없는 헤더들이 있을 것입니다. 이런 헤더들은 대부분 센드메일에서 이메일을 주고 받으며 붙인 헤더나 여러분이 사용중인 메일 프로그램에서 붙인 헤더입니다. 이런 헤더는 여러분이 어떻게 조정할 수 없는 것들입니다.

 

1. 메일이 전달된 경로
헤더 - Received:

여러분의 편지함에 도착한 메일이 어디를 거쳐서 왔는지 표시하는 헤더입니다. [from A by B for C]라는 문장으로 이루어져 있습니다. "B라는 메일 서버를 통해 A라는 메일 서버로 전송된 이메일이다. 그리고 그것은 C에게 전달되었다."라는 내용을 담고 있습니다. 이 부분의 헤더를 잘 살펴보면 메일이 어디를 거쳐서 여러분에게 전달되었는지 잘 알 수 있습니다. 여기에 그 사람이 사용하는 컴퓨터의 이름이 표시되기도 하고, 메일 서버로 어떤 프로그램을 사용하는지, 센드메일의 버전등이 표시 됩니다. 아래는 제가 받은 메일에 포함된 Received: 헤더입니다. 이것을 잘 분석해 보십시오.

Received: from hyowon.cc.pusan.ac.kr (hyowon.cc.pusan.ac.kr [164.125.9.3])
by bora.dacom.co.kr (8.8.6/8.8.6) with SMTP id BAA11063
for <social91@bora.dacom.co.kr>; Fri, 30 Jan 1998 01:47:06 +0900 (KST)

첫 라인에서 메일이 hyowon.cc.pusan.ac.kr이라는 서버에서 보내진 것임을 알 수 있습니다. 이곳의 IP 주소는 164.125.9.3이구요. 두 번째 라인에서 메일이 bora.dacom.co.kr이라는 서버로 전달되었음을 알 수 있습니다. 그리고 이 서버는 SMTP 서버로군요. 그리고, 세 번째 라인에서 1998년 1월 30일, 금요일 오전 1시 47분에 social91@bora.dacom.co.kr이라는 사용자에게 전달되었음을 알 수 있습니다. 날짜는 여러분의 메일 서버로 메일이 도착한 시간을 의미합니다. 뒤에 얘기할 Date: 헤더는 상대방이 메일을 보낸 시간을 의미하는데 이것을 보고 메일 서버간의 전달 시간을 체크해 볼 수 있습니다. "+0900 (KST)"는 한국 표준 시각을 말합니다. 그리니치 표준시보다 9시간 빠르다는 뜻이죠?

가끔 Received: 헤더가 여러개 포함된 메시지를 발견할 수 있습니다. 곧장 자신에게 전달된 메시지가 아니라 다른 몇 개의 서버를 거쳐 전달된 경우 Received: 헤더에는 거쳐온 메일 서버들이 모두 표시됩니다. 맨 아래의 Received: 헤더가 제일 처음 메일이 발송된 곳이고 그곳에서 차례대로 위쪽으로 지나온 것입니다. 제가 구독중인 온라인 잡지인 People에서 보내온 메일의 Received: 헤더를 보십시오.

(1) Received: from hyowon.cc.pusan.ac.kr (hyowon.cc.pusan.ac.kr [164.125.9.3])
by bora.dacom.co.kr (8.8.6/8.8.6) with SMTP id CAA13191
for <social91@bora.dacom.co.kr>; Fri, 30 Jan 1998 02:10:40 +0900 (KST)

(2) Received: from listserv.pathfinder.com ([204.71.242.6]) by hyowon.cc.pusan.ac.kr (8.6.11/8.6.8)
with ESMTP id CAA14694 for <leejuy@HYOWON.PUSAN.AC.KR>;
Fri, 30 Jan 1998 02:10:39 +0900

(3) Received: (from daemon@localhost) by pathfinder.com (*private*/SMI-SVR4) id
LAA21552 for peopledaily-text@listserv.pathfinder.com; Thu, 29 Jan
1998 11:44:40 -0500 (EST)

3개의 Received: 헤더가 있습니다. 여러분은 이것을 보고 어떤 정보를 얻을 수 있습니까?

(3) 의 Received: 헤더를 보세요. pathfinder.com이라는 컴퓨터에서 listserv.pathfinder.com이라는 컴퓨터에게 메일을 보내도록 지시했음을 알 수 있습니다. pathfinder.com이라는 컴퓨터는 People지의 메인 컴퓨터입니다. 여기서 온라인 신문을 구독하는 사람들을 위해 신문을 작성합니다. 그리고 실제로 메일을 보내는 컴퓨터인 listserv.pathfinder.com이라는 컴퓨터로 메시지를 보내면 이 컴퓨터가 메일 발송작업을 하는 것입니다. 메일은 미국 동부 표준시(EST) 1998년 1월 29일 오전 11시 44분에 전세계 온라인 People 구독자에게 발송되었습니다.

(2) 의 Received: 헤더에서 이 메시지가 한국 시각 1월 30일 오전 2시 10분 39초에 hyowon.pusan.ac.kr이라는 컴퓨터로 도착했음을 알 수 있습니다. 이 컴퓨터는 제가 학교에서 사용하는 계정이 있는 컴퓨터입니다. 이 주소로 도착한 메일은 즉시 bora.dacom.co.kr이라는 컴퓨터로 돌려 보내도록 설정해 두었죠.

(3)의 Received: 헤더에서 한국 시각 1월 30일 오전 2시 10분 40초에 bora.dacom.co.kr로 메시지가 도착했음을 알 수 있습니다.

메일을 보내고 받은 시각은 센드 메일에서 그리니치 표준시로 계산합니다. +0900 (KST)는 한국 표준 시각이 그리니치 표준시보다 9시간 빠르다는 말입니다. 결국 메일이 미국 동부의 People 메인 컴퓨터에서 social91@bora.dacom.co.kr까지 전달되는데 약 26분이 걸린 것을 알 수 있습니다.

Received: 헤더를 통해 여러분은 이렇게 메일이 전달되는 경로를 알 수 있을 뿐만 아니라 메일의 전달과정에 문제가 생겼을 때 도움을 받기도 합니다. 만약 메일이 전달되는 과정에서 매우 시간이 많이 걸렸거나 또는 데이터의 손실이 발생했다면 Received: 헤더를 참조하여 중간에 어떤 메일 서버를 경유했는지 확인할 수 있습니다. 그리고 그 메일 서버가 문제가 있는지 조사해 보거나 서버 담당자에게 문의할 수 있습니다. 만약 여러분이 메일을 주고 받는 메일 서버의 센드메일 버전이 너무 낮아 메일이 깨지는 문제가 발생한다면 다른 곳으로 서비스를 옮기는 것을 고려할수도 있습니다.

2. 메시지 아이디
헤더 - Message-ID

이 헤더는 메일 서버에서 메시지를 외부로 보내며 붙이는 일련번호입니다. 메시지 아이디는 다음과 같이 표시됩니다.

Message-ID: <199801291644.LAA21552@pathfinder.com>

여러분은 이것을 통해 단지 그 메시지가 어떤 컴퓨터에서 보내졌는지 알 수 있습니다. 그러나, '@' 앞에 적혀있는 이상한 문자열은 여러분을 위한 것이 아니라 컴퓨터가 그 메시지에 임의로 붙인 번호표입니다.

3. 보낸 날짜
헤더 - Date

메일을 보낸 날짜를 표시하며 다음과 같은 형식으로 표시됩니다.

Date: Thu, 29 Jan 1998 02:37:50 -0800 (PST)

시간을 표기하는 방식은 24시간 표기방식으로 마지막에 그리니치 표준시를 표시합니다. 이것을 보고 그 컴퓨터가 위치한 지역을 대략 예상해 볼 수 있습니다. 예문에 제시된 PST(Pacific Standard Timezone)는 태평양 표준시로써 미국과 캐나다에서 사용하는 표준 시간대를 의미합니다. Date: 헤더는 서버에서 직접 붙이는 경우가 있고, 사용자의 컴퓨터 시간을 따르는 경우가 있습니다. 계정에 접속하여 PINE을 통해 메일을 보내면 Date 헤더에 서버의 시계에 맞춰서 Date: 헤더가 붙습니다. 그러나, 아웃룩 익스프레스를 이용하여 메일을 보낼 경우 사용자의 컴퓨터에 있는 시계에 맞춰서 Date 헤더가 붙게 됩니다.

Received: 헤더에 나와있는 시각이 실제로 서버에 메일이 도착한 시간이라면 Date: 헤더는 메일 프로그램에서 메일이 보내진 시각을 의미합니다.

4. MIME 헤더

MIME이란 멀티미디어 메일을 위한 인터넷 표준 규약입니다. 여러분이 MIME 표준을 지원하는 메일 프로그램을 사용하며 'MIME을 사용하여 메일 보내기' 옵션을 설정하면 다음과 같은 헤더를 볼 수 있습니다.

가) MIME-Version: 1.0
MIME의 버전을 나타냅니다.

나) Content-Type:

Content-Type: 헤더는 메일 본문이 어떤 형식인지 알려 줍니다.
text/plain - 일반 문자열을 사용한 본문
multipart/ - 일반 문자열과 다른 여러 가지 인코딩 방식이 섞여 있을 경우 multipart/mixed는 일반 텍스트에 파일을 첨부했을 경우에 사용합니다. multipart/alternative는 똑같은 내용이 일반 텍스트와 html로 반복되어 있어서 둘 중 하나를 선택해서 읽을 수 있을 경우에 사용합니다. multipart/related 는 HTML 형식의 메시지를 보내며 배경그림을 첨부했을 때 사용됩니다.

다) charset="euc-kr"
charset= 부분은 본문이 어떤 언어로 작성되었는지를 나타냅니다. Content-Type 헤더에 함께 나타납니다. 한글 메일의 경우 euc-kr이란 문자셋이 표시되어야 합니다.

라) Content-Transfer-Encoding:
본문이 인코딩된 방식을 표시합니다. 한글 메시지에 8비트라고 표시되어 있으면 인코딩없이 본문을 그대로 보낸 것입니다. BASE64라든가 Quoted Printable라고 적혀 있으면 그런 방식으로 인코딩을 했다는 의미입니다.

제 멋대로 붙인 헤더

헤더는 철저히 규칙에 맞게 붙여야 합니다. 만약 헤더를 마음대로 붙인다면 컴퓨터간에 메시지 전송이 이루어질 수 없기 때문입니다. 어떤 컴퓨터는 O.K를 '좋다'는 뜻으로 이해하는데 다른 컴퓨터는 O.K를 '엉망이다'라는 뜻으로 이해하면 어떻게 되겠습니까?

그런데, 이런 엄격한 규칙을 가진 헤더지만 제 멋대로 붙일 수 있는 헤더도 있습니다. 'X-'라는 문자열로 시작하는 헤더가 그런 경우입니다. 이런 헤더는 메일 서버에서 신경을 쓰지 않고 그냥 넘겨 버립니다. 신경을 쓰지 않기 때문에 이런 헤더에 무슨 내용을 쓰더라도 메일의 전송에 영향을 끼치지 않습니다. 아웃룩 익스프레스를 사용하여 보낸 메일에는 이런 'X-'가 붙은 헤더를 몇 개 볼 수 있습니다.

X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

이 헤더들은 아웃룩 익스프레스라는 프로그램이 임의로 붙인 헤더입니다. 이런 헤더들은 인터넷의 표준이 아닐뿐더러 표준으로 인정받을 필요도 없습니다. 그렇기 때문에 'X-'라는 헤더를 사용한 것이죠.

'X-' 헤더는 매우 다양한 목적으로 사용될 수 있는데, 예문에서 볼 수 있듯이 메일 프로그램을 헤더에 표시하는데 사용되기도 합니다. X-Mailer: 헤더를 통해 메일이 어떤 프로그램을 사용하여 보내졌는지 표시하고 있습니다. X-MimeOLE: 는 메일에 포함된 바이너리 파일을 윈도우의 OLE와 연결시키는 것에 대한 헤더입니다.

또는 그 메일 프로그램이 제공하는 특별한 기능을 표시하기 위해 사용되기도 합니다. 예문에 있는 X-Priority: 헤더와 X-MSMail-Priority: 헤더는 아웃룩 익스프레스를 사용하는 메일에만 붙습니다. 이것은 메일의 보내며 중요도를 설정할 때 나타납니다.

중요도 설정에 따라 헤더의 내용이 달라집니다.

중요도X-MSMail-PriorityX-Priority
높 음High1
보 통Normal3
낮 음Low5

중요도가 높게 설정된 메시지를 받으면 메시지 표시 창에 느낌표(!)가 표시되어 그 메시지가 중요한 것임을 표시합니다. 이것은 단지 아웃룩 익스프레스에서 제공하는 특별한 기능일 뿐 메일 암호화라든가 보안문제를 해결하는 기능은 아닙니다.

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] 검색엔진 만들기  (0) 2005.01.21
[javamail] 제목 깨질때...  (0) 2005.01.18
[펌] [MAIL] MIME 관련  (0) 2005.01.17
[펌] 코드시스템및 한글문자체계  (0) 2005.01.17
[펌] http RFC  (0) 2005.01.17
Posted by tornado
|
. MIME

MIME(Multipurpose Internet Message Extension)은 말 그대로 Internet Message를 통해서 여러 가지 내용을 보낼 수 있도록 확장한 규격입니다.

한글같은 2바이트 Non-ASCII 문자가 여러 메일 서버를 무사히 통과하기 위해서는 7비트 ASCII 문자로 일단 변환되어야 합니다. 물론, 요즘의 대부분의 메일 시스템은 보통 8비트의 Non-ASCII 문자들도 손상시키지 않고 통과시키만 (8bit clean이라 하죠...), 그렇지 않은 경우도 아직 꽤 많습니다. 때문에, 그냥 8비트인 상태로 보내면, 메시지가 올바로 간다고 보장할 수 없게 됩니다. 게다가 단순한 텍스트 뿐만이 아니라, 요즘에는 바이너리 파일도 메일에 첨부하는 경우가 많죠?

그런 것들을 위해서 MIME에서는 Message Body에 있는 내용의 형태, Encoding 방식, 각 부분의 연관 관계 등을 지정할 수 있는 규약을 정하고 있습니다.



2. MIME Header

MIME 형태를 지정하기 위해서 RFC822에서 정의된 Header Field 외에 몇 가지 Header Field가 새로 정의되었습니다. 이 Header들은 message의 Top Level Header 혹은 Message Body Part의 Header에 들어갑니다.

MIME-Version Header Field
Content-Type Header Field
Content-Transfer-Encoding Header Field
Content-Disposition Header Field
Content-ID Header Field
Content-Description Header Field

MIME-Version Header Field는 Message의 주 Header에 있게 됩니다.
Content-Type, Content-Transfer-Encoding Header Field는 Top Level Header에 있을 수도 있고, Body Part의 Header에 있을 수도 있습니다.
Content-Disposition Header Field는 Top Level Header에 쓰일 수도 있지만, 대부분의 경우에는 Body Part의 Header에 있게 됩니다.


1. MIME-Version 헤더 필드

MIME 규약에 따르는 Message는 이 Header를 반드시 가지고 있어야만 합니다. 필수라고 RFC에서는 강조하고 있지만, 이 Header FIeld를 가지고 처리할 수 있는 건 아무 것도 없습니다. 그래서 실제로는 이 Header Field가 빠진 메시지도 상당히 많습니다.

MIME-Version: 1.0

지금 현재 MIME 버전은 현재까지는 무조건 1.0 입니다. 이 헤더를 가지고 있으면, 이후의 모든 내용은 MIME의 규격을 준수한다는 것을 의미하게 됩니다. 물론 실제로 보장되지는 않습니다.
EBNF Form으로 구성하면 아래와 같이 됩니다.

version := "MIME-Version" ":" 1Digit "." 1Digit

아래의 세 가지 예 모두 동일하며, 문제 없는 형식입니다.

MIME-Version: 1.0 (prodeced by MetaSend Vx.x)
MIME-Version: (prodeced by MetaSend Vx.x) 1.0
MIME-Version: 1.(prodeced by MetaSend Vx.x)0



2. Content-Type 헤더 필드

메시지 본문 혹은 본문의 각 부분의 내용의 종류를 지정하는 헤더 필드입니다. 보통 MIME Type이라고 부르는 것들은 바로 이걸 말하죠. 이 헤더 필드의 문법은 아래와 같습니다.

content := "Content-Type" ":" type "/" subtype *(";" parameter)

"Content-Type:" 이라는 헤더 이름 다음에, "타입/서브타입"과 같은 형태로 지정합니다.
그리고 여기에 parameter를 붙이고 싶으면 세미콜론으로 구분하면서 계속 적어나가면 됩니다.

타입은 크게 두 가지로 나뉩니다.
첫번째는 Discrete-Type인데, 이 것은 그 자체로 어떤 의미를 가지고 있는 Content-Type이 됩니다. 예를 들어, Text라든지, Image 같은 것들이 여기에 해당됩니다.
각각의 Type은 여러 가지 Subtype을 가질 수 있습니다. 예를 들어서, Text의 경우에는, 일반 ASCII 텍스트를 나타내는, text/plain, text/html 등의 Subtype을 가집니다.
Discrete-Type에 해당되는 것들은 아래와 같습니다.

"text" / "image" / "audio" / "video" / "application" / extension-token

두번째는 Composite-Type입니다. 이것은 Discrete-Type 혹은 Composite-Type의 개체 여러 개가 복합되어 만들어진 타입입니다. 이런... 재귀적인 설명이 되어 버렸군요. Composite-Type은 일단은 두 가지 입니다. 그 외에 확장된 타입을 둘 수 있다고 되어 있습니다. 이 중에서 MIME 규약이 점점 커지면서 다양한 서브 타입이 생겨나고 있는 것은 multipart 타입입니다.

"message" / "multipart"

Content-Type 헤더 필드가 없는 메시지도 많습니다. 이런 경우에는 어떻게 처리해야 할까요?
이 헤더가 없는 메시지는 MIME 규약이 생기기 전에 만들어진 메시지로 취급하면 됩니다. 즉, 단순한 ASCII 텍스트로만 이루어진 메시지로 처리하는 거죠...
아래가 Content-Type 헤더 필드가 없는 경우의 기본 Content-Type이 됩니다.

Content-Type: text/plain; charset=us-ascii

각 Content-Type에 대한 좀 더 자세한 내용은 다음에 설명하도록 하겠습니다.



3. Content-Transfer-Encoding 헤더 필드

이 헤더 필드는 메시지의 본문이나 본문의 각 부분이 어떤 방식으로 Encoding되었는지를 나타냅니다. 이 헤더 필드의 문법은 아래와 같습니다.

encoding := "Content-Transfer-Encoding" ":" mechanism

mechanism에는 다섯 가지가 있습니다.

"7bit" / "8bit" / "binary" / "quoted-printable" / "base64"

7bit, 8bit, binary를 먼저 보자면... 이 경우는 Encoding을 하지 않았다는 얘깁니다.

   7bit는 원래 ASCII 문자만 있다는 것을 의미하고,
   8bit는 8비트 문자들도 그래도 들어 있다는 것을 의미하고,
   binary는 8bit와 같은데, 한 줄의 길이의 제한이 없다는 것을 의미합니다. (안 쓰인다고 보면 됩니다).

물론, 한글을 7비트로 Encoding한 경우는 물론 Decoding이 필요합니다.
이 방식은 사라지고 있고, 요즘에는 한글은 base64로 Encoding하는 경우가 절대 다수이니까요.

그 다음에 특정한 알고리즘을 필요로 하는 두 개의 Encoding 방식이 있습니다.
Quoted-Printable하고 base64 Encoding이죠.

   Base64 Encoding은 간단히 말해서 3바이트의 데이타를 4바이트에 저장하는 겁니다. 24비트를 6비트씩 4개로 나누어서 따로 저장하고 각 바이트의 위쪽 두 비트를 0으로 하니까 무조건 ASCII 문자라는게 보장이 되는 거죠.
따라서 8비트 중에서 6비트만 사용하므로, 인코딩 결과로 나온 메시지는 모두 64가지의 Octet만을 가질 수 있게 됩니다. 그래서 Base64라고 부릅니다.
이 64개의 Octet는 ASCII와 같은 코드셋에도 독립적으로 설계되었습니다.
이 Encoding 방식의 장점이라고 하면, 원래의 데이타가 Encoding 후에 크기가 얼마가 될지 거의 정확하게 예측할 수 있다는 거죠. 약 33%정도가 늘어나죠. 또 다른 인코딩 방식에 비해 공간을 덜 차지하기 때문에, 효율적이라고 할 수 있습니다. 반면, Encoding을 하고 나면 원래 내용이 뭔지 도저히 알아볼 수 없다는 단점이 있죠.

   Quoted-Printable 방식은 ASCII 문자가 아닌 놈들만 "=XX" (X : 0...9, A...F)와 같은 모양으로 Encoding 하는 방식을 말합니다. 따라서 7Bit ASCII로 표현할 수 없는 문자는 한 바이트가 3바이트로 늘어나게 됩니다. 따라서, 이 방식은 크기가 최대 3배로 늘어날 수 있으니까 효율성 면에서는 거의 최악이라고 할 수 있습니다.

이 Encoding 방식은 영어 문화권에서 보면 나쁜 Encoding이 아닐 수 있습니다. 영어 문화권에서 만들어지는 텍스트는, 대부분의 문자가 7비트 ASCII 문자로 되어 있고, 그렇지 않은 문자가 훨씬 적습니다. 따라서, 이 방식으로 Encoding을 하면, 대부분의 글자가 Encoding이 되지 않고 일부분만이 Encoding이 됩니다.
그러니까, 일단 오히려 효율적일 수도 있고, 다양한 Decoding을 수행하지 못하는 MUA에서 메일을 보더라도, 대략적으로 내용을 파악할 수 있다는 거죠. 반면 한글 같이 거의가 Non-ASCII 문자인 Message나 바이너리 파일 같은 경우는 이 방식으로 Encoding 해봤자 좋은 점이 없습니다. 괜히 메모리나 디스크, 네트워크만 더 잡아먹을 뿐이지요.

정리하자면 Quoted-Printable Encoding은 Decoding이 안 되더라도 내용을 대략적으로 알아볼 수 있지만, 효율이 안 좋고, base64 Encoding은 효율이 좋지만, Decoding하기 전까지는 내용을 전혀 못 알아볼 수 없다는 겁니다.

그래서, 대부분의 ASCII 문자가 많은 텍스트나 HTML의 경우에는 Quoted-Printable로 Encoding 하는 경우가 많고, 한글이나 바이너리 파일은 거의 무조건 base64로 Encoding합니다.
이것은 그냥 그런 경우가 많이 있다는 것이고, 실제로 각 Body Part의 Encoding의 MUA 맘대로 (혹은 사용자의 선택으로) 하게 되겠죠.


4. Content-Disposition 헤더 필드

이 헤더 필드는 각각의 본문의 부분이 화면에 바로 보여야 하는지, 아니면 첨부된 파일로 보여서, 사용자가 따로 처리해야 하는지를 명시하기 위해서 사용됩니다. 문법은 아래와 같습니다.

disposition := "Content-Disposition" ":" disposition-type *(";" disposition-param)

disposition-type이 붙고 parameter가 붙을 수 있습니다.
disposition-type에는 두 가지가 있을 수 있습니다.

"inline" / "attachment"

inline은 사용자가 메시지를 보려고 할 때, 무조건 화면에 나타나야 한다는 걸 말하고, attachment는 메시지의 주 본문과는 별도로 처리될 수 있다는 걸 표시합니다. 물론 요즘 Windows용 MUA같은 경우에는 첨부된 그림 파일 같은 건 바로 화면에 보여주죠? attachment는 반드시 따로 처리해야 하는게 아니라, 반드시 화면에 바로 나타낼 필요는 없다는 걸 알려주는 겁니다.

parameter는 아래와 같은 형식으로 만들 수 있습니다. attachment같은 경우에는 "filename" parameter를 지정하는 것이 일반적입니다.

disposition-param := "filename" "=" value
    / "creation-date" "=" quoted-date-time
    / "modification-date" "=" quoted-date-time
    / "read-date" "=" quoted-date-time
    / "size" "=" 1*Digit

이 헤더가 필요한 이유는 Content-Type만을 보고 이 메시지 덩어리가 inline인지, attachment 인지 판단하기 힘든 경우가 많기 때문입니다.
예를 들어서, 어떤 사람이 텍스트로 메일을 열심히 쓴 다음에 참고할 만한 텍스트 파일을 첨부해서 메일로 보냈다고 합시다. 그러면 이 사람이 작성한 주 본문의 Content-Type은 text/plain이겠죠? 이 사람이 첨부한 파일의 Content-Type도 text/plain이겠죠?
그러면 메일을 받았을 때, 어느 부분이 진짜 주 본문인지 판단하기 힘들죠. 보통은 주 본문을 앞에 두니까, 별 상관없다고 할 수 있지만, 받은 메시지만 보고 판단할 방법은 없다는 겁니다.
어쨌든 보통의 MUA에서는 주 본문에 해당되는 부분에는 이 헤더를 굳이 설정하지 않고, attach에 해당되는 부분에는 이 헤더를 표기해 주는 경우가 많습니다.
MTA와는 전혀 관계없고, 순전히 MUA를 위해서 사용되는 Header Field라고 할 수 있습니다.



5. Content-ID, Content-Description 헤더 필드

이 두 헤더 필드의 문법은 아래와 같습니다.

id = "Content-ID" ":" "<" localpart @ domain ">"
description := "Content-Description" ":" *text

이 중 Content-ID와 같은 경우에는 평소에는 별로 중요하게 쓰이지 않지만, HTML Message 중 Embedded Image가 있는 경우에는 반드시 사용되는 중요한 Field입니다.
1. Content-Type의 종류들...

MIME의 Content-Type으로 공식적으로 등록된 것들은 얼마나 될까요? 엄청나게 많겠죠? Windows 탐색기의 파일 타입만 보더라도, 매우 많은 타입을 볼 수 있지만, 많은 응용 프로그램들이 생겨나고 있으니, 갈수록 더 늘어나겠죠.

"Text" 타입

인터넷 텍스트 메시지의 기본적인 타입입니다. 여기에 포함되는 서브 타입들을 보면...

text/plain, text/html 등등...

"Text" 타입은 charset이라고 부르는 문자 집합을 지정하는 parameter를 가질 수 있습니다.
기본 값은 앞에서도 말씀드렸듯이 US-ASCII죠.
Content-Type이 지정되지 않은 메시지 본문은 text/plain으로 처리합니다. 모든 메시지 본문의 기본 Content-Type은...

text/plain; charset=US-ASCII

요렇게 되는 거죠. charset에는 그밖에도 iso-8859-X (X : 1~10) 이라는 것이 있습니다. 한글을 비롯한 여러 국가에서 쓰이는 EUC (Extended Unix Characterset) 라는 것도 있죠. 한글 메세지의 실제로 많이 사용되는 표준 문자 집합은 EUC-KR라고 생각되네요.

"Image" 타입

이 타입은 GIF, JPEG 등의 이미지를 지원하기 위해서 처음 만들어졌습니다. 물론 Image에 해당되는 서브 타입도 아주 많지만, 거의 모든 곳에서 지원되는 타입이라면,
image/jpeg, image/gif

이 두 가지라고 할 수있겠네요.

"Audio" 타입

이 타입은 MUA가 동작하는 환경에서 이를 얼마나 지원하느냐가 문제겠죠? 그리고 Audio에 대해서는 특별한 표준이... 없습니다. MP3, Real Media 등과 같은 Audio 소스가 요즘에는 많지만, MIME에서는 공식적으로 사용하는 기본 규격은 8비트 PCM, 8KHz 규격입니다. -_-;

audio/basic

"Video" 타입

Vidoe 서브 타입도 Audio와 마찬가지로 MUA의 환경이 문제가 됩니다. 이 타입의 기본 서브타입은 MPEG으로 되어 있습니다.

video/mpeg

"Application" 타입

Application 타입은 다른 응용 프로그램이 이걸 처리해야 한다는 걸 의미합니다. 그래서 이 타입의 기본 동작은 사용자의 디스크에 저장하는게 되는 거죠. 여러 MUA에서 바로 이런 타입의 Content를 열 수 있는 기능을 지원하지만, 사실은 임시 공간에 파일을 저장하고 응용 프로그램을 부르는 방식이죠.

넘쳐나는 응용프로그램의 MIME Content-Type을 모두 인식하기란 사실상 힘들다고 볼 수 있습니다. 따라서 알 수 없는 파일의 기본 Content-Type은,

application/octet-stream

로 정의되고, 이 Content-Type에 대한 기본 동작은, "로컬 디스크에 저장"이 됩니다.

RFC에 언급되기로는 application/Postscript과 같은 서브타입이 있고, 보안 관련 이슈가 상당히 많지만, 별로 흥미가 없네요. ^^;

1. 기본 구조

"Multipart" 타입의 기본 구조를 보기 전에, Multipart 타입의 기본 서브 타입에 대해서 이야기를 해야겠네요.

Multipart Content-Type의 기본 Subtype은 "multipart/mixed"라는 서브 타입입니다. 각각의 부분은 연관관계가 없으며, 각 부분의 순서만 미미하게(?) 의미가 있는 거죠. 꼭 하나의 (특히 첫번째) 본문 부분이 inline 메시지고, 나머지는 attachment라는 보장은 없습니다. 또, 각각의 본문 부분도 multipart로 구성될 수 있습니다. 따라서 이론적으로 무한대의 중첩이 가능합니다. 실제로는 최대 세 단계 정도로 mulitpart가 구성되는 것이 일반적입니다. 어째서 세 단계까지인지는 이후에 설명하겠습니다.

맨 앞에서 메시지는 헤더와 본문으로 구성되고 둘의 구분은 NULL 라인으로 한다고 말씀드렸죠?
메시지 본문은 단순히 라인의 집합의 형태로 평면적인 구성을 하고 있기 때문에, 여러 부분으로 나누기 위해서는 각 부분의 경계를 표시할 수 있는 표식이 필요하고, 이것이 Multipart Content-Type의 기본 Parameter가 됩니다. 이 Parameter를 그걸 boundary라 부릅니다.

기본 구조를 보면 아래와 같습니다.

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

boundary로 쓰일 수 있는 문자는 ASCII 문자 중에서 일부에 속합니다. 아래의 예는 올바른 boundary 구성이라고 볼 수 없습니다. 콜론이 들어가 있기 때문입니다. 콜론은 헤더 필드 이름과 필드 본문을 구분하기 위해서 사용되는 문자니까요.

Content-Type: multipart/mixed; boundary=gc0p4Jq0M:2Yt08j34c0p

그렇다고 완전히 틀린 건 아니고, 아래처럼 따옴표로 묶으면 적법한 boundary가 됩니다. 좀 애매한 기준이긴 합니다만, 실제로는 boundary를 Uniqueue하게 만들기 위해서 이런 식으로 쓰이는 경우도 많습니다.

Content-Type: multipart/mixed; "boundary=gc0p4Jq0M:2Yt08j34c0p"

boundary는 메시지 안에 이런 형태가 나타나지 않도록 신중하게 만들어져야 합니다. 특히, 다음에 설명할 "message" Content-Type과 같이 메시지를 가지고 있는 본문 부분의 경우에 문제가 발생할 소지가 많기 때문이죠.

multipart로 구성된 메시지의 예를 하나 보죠.

From: Nathaniel Borenstein
To: Ned Freed
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"

This is the preamble. It is to be ignored, though it
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.

--simple boundary

This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii

This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.

--simple boundary--

This is the epilogue. It is also to be ignored.

보면, 인자로 주어진 boundary에 두 가지 변형을 해서 boundary로 사용하고 있습니다. 첫번째는 앞에 "--"를 붙인 것입니다. 이것을 메시지 부분간의 실제 경계로 사용합니다. 그 담엔 앞 뒤에 "--"를 붙인 것이 있지요? 이건 multipart의 끝을 의미합니다.

일단 Content-Type이 multipart로 선언되면 첫번째 경계가 나타나기 전까지의 메시지는 "반드시" 무시해야 합니다. 그리고 경계가 나타나면 다음 경계가 나타나기 전까지의 부분을 하나의 본문 파트로 처리하면 됩니다. 그러다가 multipart의 끝을 나타내는 표식이 나타나면 실제 mulitpart 메시지가 끝난 걸로 처리합니다. 이후에 나타나는 모든 문자는 역시 "반드시" 무시해야 합니다.
뭐 생각보다 간단하다고 생각할 수도 있겠지만, 이 기본적인 구조를 지키지 않는 메일 시스템이 참 많습니다. boundary를 단순히 "mail-boundary"와 같이 표시하는 것들은 좀 문제를 많이 일으키죠. 또한 에필로그에 해당되는 경계를 제대로 넣어주지 않는 경우도 많이 있습니다.



2. "multipart" 타입의 각 서브 타입

이게 각각의 서브 타입들을 살펴보도록 하죠. 앞에서 본 기본 구조를 머리 속에 두고 각각의 서브 타입의 차이점들을 살펴보도록 하죠.

"Mixed" 서브 타입

앞서 말씀드린 것과 같이 mulitpart 타입의 기본 서브타입입니다. 내용은 앞과 마찬가지고, 중요한 것은, 알 수 없는 multipart의 어떤 서브 타입이 나타나더라도 처리를 못해서는 안 된다는 겁니다. 알 수 없는 multipart 서브 타입는 이 multipart/mixed 서브 타입으로 처리하도록 되어 있습니다.

"Alternative" 서브 타입

이 타입은 형식상으로는 multipart/mixed 타입과 완전히 동일합니다. 다른 점은, 이 타입은 같은 내용에 대한 서로 다른 버전을 담고 있다는 것이죠. 이 메시지를 처리하는 쪽 즉, MUA에서는 자신의 환경에 맞는 가장 좋은 버전 하나만을 선택하면 됩니다.
보통은 가장 훌륭한 버전을 맨 뒤에 놓습니다. 어떤 생각해 보면, 가장 좋은 버전이 맨 앞에 있어야 하는 것 같기도 하지만, 이런 타입을 제대로 처리하지 못하는 MUA 환경을 생각할 때, 가장 단순하고 일반적인 타입이 맨 앞에 있어야 그나마 처리가 쉬워집니다.

예를 하나 보죠.

From: Nathaniel Borenstein
To: Ned Freed
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42

--boundary42
Content-Type: text/plain; charset=us-ascii

... plain text version of message goes here ...

--boundary42
Content-Type: text/enriched

... RFC 1896 text/enriched version of same message goes here ...

--boundary42
Content-Type: application/x-whatever

... fanciest version of same message goes here ...

--boundary42--

각각의 내용은 모두 같지만, 서로 다른 포맷을 가지는 내용을 이렇게 구분할 수 있겠죠. 이 타입을 사용하는 중요한 예는 바로 HTML 문서를 메일로 보내는 경우가 됩니다. MUA마다 HTML를 처리할 수 있는지 없는지가 달라지기 때문에, 앞부분에는 그냥 일반적인 텍스트 즉, text/plain을 넣고 그 뒤에 text/html을 넣는 겁니다.

"Digest" 서브 타입

이 서브 타입의 기본 문법은 "multipart/mixed"와 동일합니다. 다른 점은 multipart/mixed 타입에서, 각 부분의 기본 Content-Type이 text/plain인 것과는 달리 이 타입의 기본 Content-Type은 "message/rfc822"라는 겁니다.

message/rfc822라는 타입은 헤더를 포함한 메시지 자체를 나타냅니다.
즉, 메일 메시지를 캡슐화하고 있는 거라고 보면 됩니다. 보통 되돌아온 메일에 attach로 달려 있는 원래 메시지가 이 타입을 가지고 있습니다.

실제로 아직 Multipart-Digest 타입으로 된 메시지는 보지 못했습니다. 이 형태를 Multipart-Mixed 타입으로 처리해도 큰 문제는 없습니다.

예를 한 번 보죠.

From: Moderator-Address
To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42
MIME-Version: 1.0
Content-Type: multipart/digest; boundary="---- main boundary ----"

------ main boundary ----

...Introductory text or table of contents...

------ main boundary ----
Content-Type: multipart/digest;
boundary="---- next message ----"

------ next message ----

From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion

...body goes here ...

------ next message ----

From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion

... another body goes here ...

------ next message ------

------ main boundary ------


"Parallel" 서브 타입

"multipart/mixed"와 다른 점이라고 하자면, 이 타입에서는 각각의 본문 파트가, 하드웨어에 의하든 소프트웨어에 의하든 간에 병렬적으로 디스플레이가 가능해야 한다는 거죠. 예를 들어 프리젠테이션과 같이 텍스트와 이미지와 오디오가 동시에 나타나야 하는 경우를 들 수 있겠네요. 하지만, 상당히 플랫폼의 제약을 많이 받기 때문에, 실제로 사용되는 일은 거의 없다고 보면 되겠습니다.

"Report" 서브 타입

이 타입은 현재로는 메시지의 상태를 알리기 위한 것으로 사용되고 있습니다. 즉 되돌아오는 메일 등을 이 형태로 처리하게 됩니다. 좀 더 자세한 내용은 Notification Message에서 다루도록 하겠습니다.

이 타입은 어떤 본문 파트의 일부분으로는 사용될 수 없으며, "반드시" Top Level의 Content- Type으로만 쓰이도록 되어 있습니다. 그리고 이 메시지의 전체는 반드시 7비트 ASCII 문자로만 이루어져 있어야 합니다. (실제로는 8bit로 된 경우도 존재합니다.)

이 타입의 서브 파트는 크게 두 개 혹은 세 개이고, 이 순서로 나타나야 합니다. 세번째 Part는 없을 수도 있습니다.

첫번째 부분은 사람이 알아볼 수 있는 상태 설명 부분입니다. 보통 Content-Type이 지정되어 있지 않기 때문에, Content-Type을 text/plain으로 설정해서 보게 됩니다.

두번째 부분은 기계가 파싱해서 사용할 수 있는 상태 설명입니다. Content-Type은 "message/delivery-status"와 같은 형태로 나타납니다. 이 부분도 반드시 나타나야 합니다.

세번째 부분은 선택 사항으로 원래 메시지 전체 혹은 일부분을 가지고 있습니다. 보통은 헤더에 문제가 있어서 메시지가 되돌아 오는 경우가 많기 때문에, RFC에서는 메시지 헤더만을 가지는 "text/rfc822" (실제로는 message/rfc822-headers가 더 많습니다) 타입을 권장하고 있습니다. 하지만, 요즘 같이 네트워크 용량이 풍부한 세상에서는 앞서 말씀드린 "message/rfc822" 타입으로 메시지 전체가 포함되는 것이 일반적입니다.


"Related" 서브 타입

이 타입이 multipart 타입 중에서 가장 어려운 타입이라고 볼 수 있겠네요. 이 타입은 각 본문 파트가 연관을 가지고 있다는 것을 말합니다. 그런데, 각 부분을 연결하는 방식이 응용 프로그램마다 천차만별일 수밖에 없기 때문에, 이 타입은 뭐라고 설명하기가 어렵네요.

하지만, 역시 이 타입이 중요한 이유는 HTML 문서를 메시지로 전달하기 위한 것입니다. HTML 문서에는 단순히 텍스트 뿐만이 아니라, 이미지 등의 많은 객체가 포함되어야 하는데, 거기에 바로 각 Content들을 Content-ID로 연결해서 사용하는 겁니다. 자세한 내용은 HTML 메시지에서 알아보도록 하죠.
1. "Message" 타입의 각 서브 타입

"RFC822" Subtype

앞서서 말씀드렸듯이 가장 간단하게 메일 메시지를 포함하고 있는 타입을 뜻합니다.
되돌아온 메시지에 가장 많이 포함된다고 말씀드렸죠?
"Partial" 서브 타입

메일 시스템 용량이 아무리 빠방하다 하더라도, 어떤 큰 메시지라도 끄떡없이 보낼 수 있는 건 아닙니다. 한 번에 통과할 수 있는 메시지의 크기가 여러 가지 이유로 제한이 생기기 마련이죠. 그래서, 뭔가 큰 메시지를 보내기 위해서는 여러 개의 메시지로 잘라서 보내고 받는 쪽에서 합쳐서 봐어 합니다. 그것을 위한 타입입니다.

그래서, 각각의 메시지에 몇 번째 조각이며, 전체는 몇 조각으로 되어 있는지를 표시합니다. 물론 같은 메시지의 조각임을 나타내기 위해서 id라는 parameter를 사용합니다. 아래의 예를 보죠.

3조각 메시지의 두번째 조각
Content-Type: Message/Partial; number=2; total=3;
    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
혹은,
Content-Type: Message/Partial;
    id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
    number=2

3조각 메시지의 세번째 조각 - 반드시 전체 조각수를 가지고 있어서, 자신이 마지막 조각임을 알려야 합니다.
Content-Type: Message/Partial; number=3; total=3;
    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

그렇다고 메시지를 조각낼 때, 아무렇게나 조각낼 수 있는 건 아니고, 몇 가지 원칙이 있습니다.

   일단 메시지는 "반드시" 라인이 끝나는 지점에서만 잘려야 합니다.
   각 메시지 마다 Content-*, Subject, Message-ID, Encrypted, MIME-Version를 제외한 모든 헤더 필드가 덧붙여져야 합니다.
   메시지가 합쳐질 때는, 헤더 중 Content-*, Subject, Message-ID, Encrypted, MIME-Version만이 살아남고, 나머지는 무시됩니다.
   두번째 조각 이후의 헤더 필드는 깡그리 무시됩니다.

어쨌든 쉽지 않은 모양이네요...


"External-Body" 서브 타입

이 타입은 실제 내용이 메시지 내부에 있는게 아니라 외부에 있다고 알리는 건데요. 그 외부 소스의 형태가 메일, FTP, HTTP, 로칼 디스크 등 워낙 다양하기 때문에, 사용하기도 어렵고, 설명하긴 더 힘드네요. ^^;
1. 헤더 필드의 확장

일단, 문법을 좀 보죠.

encoded-word := "=?" charset "?" encoding "?" encoded-text "?="

좀 복잡하죠? 간단히 쓰자면
=? (문자집합) ? (Encoding 방식) ? (인코딩된 문자열) ?=

'JAVA > JSP_Servlet' 카테고리의 다른 글

[javamail] 제목 깨질때...  (0) 2005.01.18
[펌] 메일 헤더 구성 요소  (0) 2005.01.17
[펌] 코드시스템및 한글문자체계  (0) 2005.01.17
[펌] http RFC  (0) 2005.01.17
[펌]Single Sign On...  (0) 2005.01.17
Posted by tornado
|

Report on Code system and Hangeul Character set

 

 

Table of Contents

1.  Introduction

2.  Code 체계

3.  한글 Character Set

4.  Problem Definitions

5.  Conclusion

 

1.      Introduction

Home Page, E-mail, Java 등을 사용하다 보면 Unicode (ISO/IEC 10646) 부호계를 알지 못하면 그런데서 한글을 사용하기가 불편해 진다. ISO/IEC 10646 국제 표준 부호계와 한글 부호계에 대하여 살펴 보고자 한다. 또한 E-mail에서 많이 쓰이는 Quoted Printable (QP) Base64 살펴 , UTF-16, UTF-8, UTF-7 각종 UTF 대하여 살펴본다. ISO/IEC 10646 KS X 1005-1 (과거 KS C 5700)으로 받아 들였는데, 이에 대한 소개도 더붙인다. 현재 Internet E-mail 등에서는 한글 완성형 KS X 1001 ASCII (KS X 1003) 같이 , MIME charset 이름으로 EUC-KR 쓰고 있는데, EUC-KR 이라는 MIME charset KS C 5601 대하여도 살펴보며, 이러한 code체계가 한글에 미치는 영향과 문제점들을 정리하였다.

 

2.      Code 체계

정보 처리 분야의 규격이 늘어나게 데는 국제 표준 기구의 영향이 크다. 1987년에 ISO(International Organization for Standardization) TC97 IEC(International Electrotechnical Commission ) TC83 공동으로 ISO/IEC JTC1 (Joint Technical Committee 1) 만들면서 정보 처리 분야의 국내 규격이 많이 늘어나게 되었다.

1992 6-7월에 열린 ISO/IEC JTC1/SC2/WG2 22 회의에서 ISO/IEC 10646-1 국제 표준 (IS)으로 확정함에 따라서, 거기에 들어 있던 한글 부호계도 확정되게 되었다. ISO/IEC 10646 글자를 4 Byte 나타내는 4 Byte 부호계 (UCS-4) 시작하였으며, 전세계의 주요한 글자계를 거의 모두 나타 있다. [경석]

 

2.1      용어 정의

2.1.1     code (부호계)

code codeword 집합이라고 있다. ISO/IEC 10646 code에서 첫가끝 조합형 첫소리 글자 ㄱ의 codeword 0x0000 1100 된다.

2.1.2     Codeword(부호값)

code codeword 집합이다. 표준에 따라서는 codeword라는 용어 대신 ISO/IEC 10646 에서는 code position이라는 용어를 사용하고, Unicode에서는 code point라는 용어를 쓰며, 다른 곳에서는 code element라는 용어를 사용하기도 하나 모두 같은 용어이다.

2.1.3     Plane

4 Byte code UCS-4에서 윗자리 16bit 값은 같고, 나머지 아래자리 16bit 다른 codeword 집합을 plane이라고 한다. Plane 하나에는 codeword 64K(65,536) 만큼 있게 되며, plane Group 번호와 Plane번호를 각각 hexadecimal 나타낸다. 예를 들면 BMP (Basic Multilingual Plane) 경우 G=00, P=00 된다.

 

BMP는 다시 4개의 영역으로 나누어 지는데 각 영역의 특징은 다음과 같다.

             A-zone: alphabetic and syllabic scripts together with various symbols

             I-zone: Chinese/Japanese/Korean (CJK) unified ideographs (unified East Asian ideographs)

             O-zone: reserved for future standardization

             R-zone: restricted use zone (private use characters, presentation forms, compatibility characters, etc.)

그림 1. BMP(Basic Multilingual Plane)

 

2.1.4     Group

4 Byte code UCS-4에서 윗자리 8bit 값은 같고, 나머지 아래자리 24bit 다른 codeword 집합을 group이라고 한다. group 하나에는 codeword 16M(1600) 만큼 있게 되며, group 번호는 hexadecimal 두개로 나타낸다. 우리가 알고 있는 대부분의 codeword 거의 모두 G=00이다.

 

2.2      ISO/IEC 10646-1

2.2.1     UCS-4 : 4Byte code

ISO/IEC 10646 표준의 이름은 Universal Multiple-Octet Coded Character Set (UCS)이다. UCS 처음에 4Byte code 시작하였는데, 이를 UCS-4라고 한다. , 글자는 4byte 쓰며, 따라서 hexadecimal 8개로 나타낸다.

한글 첫가끝 조합형 첫소리 글자 codeword 0x0000 1100이고, 가운뎃소리

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] 메일 헤더 구성 요소  (0) 2005.01.17
[펌] [MAIL] MIME 관련  (0) 2005.01.17
[펌] http RFC  (0) 2005.01.17
[펌]Single Sign On...  (0) 2005.01.17
JSP 다운로드시 헤더 ㅡㅡ  (0) 2005.01.13
Posted by tornado
|

[펌] http RFC

JAVA/JSP_Servlet 2005. 1. 17. 21:30

RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1
rfc2068 :하이퍼텍스트 전송규약 1.1표준(안)
출처 : 한국전자통신연구소요약하이퍼텍스트 전송 규약(HTTP)은 분산 정보 시스템, 종합 정보시스템 및 하이퍼미디어 정보시스템에서사용하는 응용 계층 규약으로서 요구 방법의 확장을 통해서 네임 서버와 분산 객체 관리 시스템과 같은수많은 작업에 사용될 수 있는 보편적인 객체 지향형 규약이다. HTTP는 어떤 문서의 데이터 표현 형식을규정하고 협상하여 전송 중인 데이터와 무관하게 시스템을 구축할 수 있게 한다.HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에 의하여 사용되고 있다.이 규격은 "HTTP/1.1"로 언급되는 규약을 정의하고 있다.
목차 1. 도입 1.1 목적 1.2 필요 사항 1.3 용어 1.4 전반적인 운영 2. 기호 관례 및 일반적인 문법 2.1 추가된 BNF 2.2 기본적인 규칙 3. 규약 파라미터 3.1 HTTP 버전 3.2 보편적 자원 식별자(Uniform Resource Identifiers) 3.2.1 일반적 형식 3.2.2 http URL 3.2.3 URI 비교 3.3 날짜/시간 형식 3.3.1 완전한 날짜 3.3.2 Delta Seconds 3.4 문자 집합 3.5 내용 코딩 (Content Coding) 3.6 전송 코딩 (Transfer Coding) 3.7 미디어 타입 3.7.1 정형화(Canonicalization) 및 텍스트 기본값 3.7.2 Multipart Type 3.8 제품 토큰 3.9 품질 등급 값 3.10 언어 태그 3.11 엔터티 태그 3.12 영역 단위 4. HTTP 메시지 4.1 메시지 유형 4.2 메시지 헤더 4.3 메시지 본문 4.4 메시지 길이 4.5 일반적인 헤더 필드 5. 요구 5.1 Request-Line 5.1.1 Method 5.1.2 Request-URI 5.2 요구에 의해 식별되는 자원 5.3 요구 헤더 필드 6. 응답 6.1 상태-라인 6.1.1 상태 코드 및 이유 문구 6.2 응답 헤더 필드 7 엔터티(Entity) 7.1 엔터티 헤더 필드 7.2 엔터티 본문 7.2.1 유형 7.2.2 길이 8. 접속 8.1 지속적인 접속 8.1.1 목적 8.1.2 전반적인 운영 8.1.3 프락시 서버(Proxy Servers) 8.1.4 실제적인 고려 사항 8.2 메시지 전송 필요 조건 9. Method 정의 9.1 안전 및 멱등원(冪等元) method 9.1.1 안전 method 9.1.2 멱등원 method 9.2 OPTIONS 9.3 GET 9.4 HEAD 9.5 POST 9.6 PUT 9.7 DELETE 9.8 TRACE 10. 상태 코드 정의 10.1 Informational 1xx (정보를 알려 주는 1xx) 10.1.1 100 Continue (계속) 10.1.2 101 Switching Protocols (규약 전환) 10.2 Successful 2xx (성공을 알려 주는 2xx) 10.2.1 200 OK 10.2.2 201 Created (생성 되었음) 10.2.3 202 Accepted (접수 되었음) 10.2.4 203 Non-Authoritative Information (비 인증 정보) 10.2.5 204 No Content (내용이 없음) 10.2.6 205 Reset Content (내용을 지움) 10.2.7 206 Partial Content (부분적 내용) 10.3 Redirection 3xx (방향을 재설정하는 3xx) 10.3.1 300 Multiple Choices (복수 선택) 10.3.2 301 Moved Permanently (영구 이동) 10.3.3 302 Moved Temporarily (임시 이동) 10.3.4 303 See Other (다른 것을 참조) 10.3.5 304 Not Modified (변경되지 않았음) 10.3.6 305 Use Proxy (프락시를 사용할 것) 10.4 Client Error 4xx (클라이언트 에러 4xx) 10.4.1 400 Bad Request (잘못된 요구) 10.4.2 401 Unauthorized (인증되지 않았음) 10.4.3 402 Payment Required (요금 지불 요청) 10.4.4 403 Forbidden (금지되었음) 10.4.5 404 Not Found (찾을 수 없음) 10.4.6 405 Method Not Allowed (Method를 사용할 수 없음) 10.4.7 406 Not Acceptable (접수할 수 없음) 10.4.8 407 Proxy Authentication Required (프락시 인증이 필요함) 10.4.9 408 Request Timeout (요구 시간 초과) 10.4.10 409 Conflict (충돌) 10.4.11 410 Gone (내용물이 사라졌음) 10.4.12 411 Length Required (길이가 필요함) 10.4.13 412 Precondition Failed (사전 조건 충족 실패) 10.4.14 413 Request Entity Too Large (요구 엔터티가 너무 큼) 10.4.15 414 Request-URI Too Long (Request-URI이 너무 김) 10.4.16 415 Unsupported Media Type (지원되지 않는 media type) 10.5 Server Error 5xx (서버 에러 5xx) 10.5.1 500 Internal Server Error (서버 내부 에러) 10.5.2 501 Not Implemented (구현되지 않았음) 10.5.3 502 Bad Gateway (불량 게이트웨이) 10.5.4 503 Service Unavailable (서비스를 사용할 수 없음) 10.5.5 504 Gateway Timeout (게이트웨이 시간 초과) 10.5.6 505 HTTP Version Not Supported (지원되지 않는 HTTP 버전) 11. 접속 인증 11.1 기본 인증 scheme 11.2 요약 인증 scheme 12. 내용 협상(Content Negotiation) 12.1 서버가 주도하는 협상 12.2 에이전트가 주도하는 협상 12.3 투명한 협상(Transparent Negotiation ) 13. HTTP에서의 캐시 13.1.1 캐시의 정확성 13.1.2 경고 13.1.3 캐시-제어 메커니즘 13.1.4 명백한 사용자 에이전트 경고 13.1.5 규칙 및 경고의 예외 사항 13.1.6 클라이언트가 제어하는 행태 13.2 유효일 모델 13.2.1 서버가 명시한 만기일 13.2.2 스스로 만기일을 찾음(Heuristic Expiration) 13.2.3 경과 시간 계산(Age Calculations) 13.2.4 만기일 계산 13.2.5 만기일 값을 명확하게 하기 13.2.6 복수의 응답을 명확하게 하기 13.3 검증 모델 13.3.1 최종 갱신 날짜 13.3.2 엔터티 태그 캐시 검증자(Validators) 13.3.3 약한/강한 검증자 13.3.4 엔터티 태그와 최종 갱신 날짜를 사용할 때를 결정하는 규칙 13.3.5 검증을 하지 않는 조건 법 13.4 응답을 캐시할 수 있는 정도(Cachability) 13.5 캐시에서 응답을 구축하기 13.5.1 End-to-end 및 Hop-by-hop 헤더 13.5.2 변경할 수 없는 헤더 13.5.3 헤더의 결합 13.5.4 바이트 영역(Byte Ranges)의 결합 13.6 협상을 통한 응답을 캐시하기 13.7 공유/비공유 캐시 13.8 에러 또는 불완전한 응답 캐시 행태 13.9 GET 및 HEAD의 부작용 13.10 갱신 또는 삭제 후의 무효화 13.11 의무적으로 서버를 통하여 기입 13.12 캐시 대체 13.13 History List 14. 헤더 필드 정의 14.1 Accept 14.2 Accept-Charset 14.3 Accept-Encoding 14.4 Accept-Language 14.5 Accept-Ranges 14.6 Age 14.7 Allow 14.8 Authorization 14.9 Cache-Control 14.9.1 무엇을 캐시할 수 있는가 14.9.2 캐시에 의해 무엇을 저장할 수 있는가 14.9.3 기본적인 만기일 메커니즘의 변경 14.9.4 캐시의 재검증 및 Reload 제어 14.9.5 비 변경 지시어 14.9.6 캐시 제어 확장 14.10 Connection 14.11 Content-Base 14.12 Content-Encoding 14.13 Content-Language 14.14 Content-Length 14.15 Content-Location 14.16 Content-MD5 14.17 Content-Range 14.18 Content-Type 14.19 Date 14.20 ETag 14.21 Expires 14.22 From 14.23 Host 14.24 If-Modified-Since 14.25 If-Match 14.26 If-None-Match 14.27 If-Range 14.28 If-Unmodified-Since 14.29 Last-Modified 14.30 Location 14.31 Max-Forwards 14.32 Pragma 14.33 Proxy-Authenticate 14.34 Proxy-Authorization 14.35 Public 14.36 Range 14.36.1 Byte Ranges 14.36.2 Range Retrieval Requests 14.37 Referer 14.38 Retry-After 14.39 Server 14.40 Transfer-Encoding 14.41 Upgrade 14.42 User-Agent 14.43 Vary 14.44 Via 14.45 Warning 14.46 WWW-Authenticate 15. 보안에 대한 고려 사항 15.1 클라이언트의 인증 15.2 인증 scheme을 선택할 수 있도록 함 15.3 서버 로그 정보의 남용 15.4 민감한 정보의 전송 15.5 파일 및 경로 이름에 기초한 공격 15.6 개인적인 정보 15.7 Accept 헤더와 연결된 사생활 보호의 이슈 15.8 DNS Spoofing(속이기) 15.9 Location 헤더와 Spoofing(속이기) 16. 감사의 말 17. 참고 문헌 18. 저자의 주소 19. 부록 19.1 Internet Media Type message/http 19.2 Internet Media Type multipart/byteranges 19.3 Tolerant Applications 19.4 HTTP 엔터티와 MIME 엔터티의 차이점 19.4.1 규범적인 폼으로 변환 19.4.2 날짜 형식의 변환 19.4.3 Content-Encoding 소개 19.4.4 No Content-Transfer-Encoding 19.4.5 Multipart Body-Part의 HTTP 헤더 필드 19.4.6 Transmit-Encoding 소개 19.4.7 MIME-Version 19.5 HTTP/1.0 이후 변경 사항 19.5.1 복수의 홈을 가진 웹 서버를 단순하게 하기 위한 변경 사항 및 IP 주소 보존 19.6 추가 기능 19.6.1 추가적인 요구 method 19.6.2 추가 헤더 필드 정의 19.7 이전 버전과의 호환성 19.7.1 HTTP/1.0 지속적인 연결과의 호환성
1. 서론1.1 목적하이퍼텍스트 전송 규약(HTTP)은 분산 정보시스템, 종합 정보시스템 및 하이퍼미디어 정보시스템에서사용하는 응용계층의 규약이다. HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에의하여 사용되고 있다. "HTTP/0.9"로 언급되는 HTTP의 첫 버전은 인터넷 상에서 저장되어 있는 원래데이터(raw data)를 전송하기 위한 단순한 규약이었다. RFC 1945 [6]이 규정한 HTTP/1.0은 메시지를전송되는 문서 데이터에 대한 메타 정보 및 요구/응답 용어의 변경자를 포함하는 MIME과 유사한메시지의 형식으로 사용할 수 있도록 함으로써 규약을 향상시켰다. 그러나 HTTP/1.0은 계층적 프락시(hierarchical proxies), 캐시, 지속적인 연결의 필요성 및 가상 호스트(virtual host) 등의 영향을충분히 고려하지 않았다. 또한 "HTTP/1.0"을 지원한다고 하면서도 규약의 불완전 구현 및 오해에 의한잘못된 구현 등에 의해 응용 프로그램 사이에 종종 문제가 발생하였기에 상호 협상할 수 있는 응용프로그램이 상대방의 진정한 성능을 파악할 수 있도록 규약 버전을 갱신할 필요가 생겼다. 이 규격은 "HTTP/1.1"로 불리우는 하이퍼텍스트 전송 규약을 정의한다. 이 규약은 기능을 신뢰할 수있도록 구현하기 위해 HTTP/1.0보다 더 엄격한 필요 조건을 포함하고 있다.실제적인 정보 시스템은 단순한 조회보다 검색, 프런트-엔드(front-end) 갱신 및 주석 달기 등 많은기능을 필요로 한다. HTTP는 요구의 목적을 표시하는 일련의 개방된 method를 (open-ended setof methods) 허용한다. 이 규약은 보편적 자원 식별자(URI) [3][20], 자원 위치 (URL) [4] 또는 자원이름(URN)이 제공하는 참고 방법에 따라 method를 적용할 자원을 지칭하는 데 사용한다.메시지는 다용도 인터넷 메일 확장(MIME)에서 정의된 것처럼 인터넷 메일에서 사용되는 것과 유사한형식으로 전송된다. HTTP는 사용자 에이전트, 프락시/게이트웨이와 SMTP [16], NNTP [13], FTP [18], Gopher [2], 및 WAIS [10] 등을 지원하는 다른 인터넷 시스템 사이의 통신을 위한 범용 규약으로서 사용된다. 이러한 방식으로 HTTP는 기본적인 하이퍼미디어가 다양한 애플리케이션의 자원에 접근할 수 있도록한다. 1.2 필요 조건이 규격은 각각의 특별한 필요 조건의 중요도를 정의할 때 RFC 1123 [8]와 동일한 용어를 사용한다.이러한 용어는 다음과 같다. MUST이 단어 또는 "요구된"이라는 형용사는 해당 항목이 규격의 절대적인 필요 조건임을 의미한다. SHOULD이 단어 또는 "추천된"이라는 형용사는 특정 상황에서 해당 항목을 무시할 합당한 이유가 있을 수있다는 것을 의미한다. 그러나 충분히 함축적 의미를 이해해야 하고 다른 방법을 선택하기 전에 사례를충분히 검토해야 한다. MAY이 단어 또는 "선택적"이라는 형용사는 해당 항목이 진정으로 선택적이라는 것을 의미한다.한 판매회사는 특정 항목을 특정 시장이 요구하기 때문에 또는 예를 들어 제품의 기능을 향상시켜 주기때문에 다른 판매 회사와 달리 동일한 항목을 포함할 수 있다.구현 방법이 하나 또는 그 이상의 MUST 규약 필요 조건을 충족시켜 주지 못하면 규약에 따르지 않는것이다. 구현 방식이 모든 MUST 및 SHOULD 필요 조건을 충족한다면 "무조건적으로 충족한다"고 할 수있고, 모든 MUST 필요 조건을 충족하지만 모든 SHOULD 필요 조건을 충족하지 못한다면 "조건적으로충족한다"고 할 수 있다. 1.3 용어이 규격은 HTTP 통신의 참여자 및 객체가 수행하는 역할을 지칭하는 몇몇 용어를 사용하고 있다. connection(연결)통신을 목적으로 두 프로그램 간에 설정된 전송 계층의 가상적 회로 message(메시지)HTTP 통신의 기본 전송 단위. 4 장에 규정된 의미론을 따르는 구조적인 데이터 표현 형태이며, 일련의8 비트(octets)로 구성되어 있고 연결을 통하여 전송된다. request(요구) 5 장에 규정된 HTTP 요구 메시지. response(응답) 5 장에 규정된 HTTP 응답 메시지. resource(자원)3.2절에 규정되어 있는 URI에 의하여 식별되는 네트워크 데이터 객체 또는 서비스. 자원은 다양한 표현형태(예를 들어 언어, 데이터 형식, 크기 및 해상도)를 지닐 수 있으며 다양한 방법으로 변형될 수 있다. entity(엔터티)요구나 응답 메시지의 페이로드(payload)로서 전송되는 정보. 엔터티는 7 장에서 설명된 대로 Entity-Header필드 형태의 메타 정보 및 Entity-Body 형태의 내용으로 구성되어 있다. representation(표현)12 장에서 기술한 내용 협상의 통제를 따르는 응답에 포함된 엔터티. 특정한 응답 상태와 연관된 다수의표현 방법이 있을 수 있다. content negotiation(내용 협상)12 장에서 기술한 대로 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한 응답에서는엔터티의 표현은 협상할 수 있다.(에러 응답 포함) variant(변형자)자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있다. 이러한 각각의 표현 방식을"변형자"라고 부른다. "변형자"라는 용어를 사용한다고 해서 자원이 반드시 내용 협상의 대상인 것은아니다. client(클라이언트)요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램. user agent(사용자 에이전트)요구 메시지를 시작하는 클라이언트. 이것은 종종 브라우저, 편집기, 스파이더(웹을 탐색하는 로봇) 또는다른 사용자 툴(tool)일 수 있다. server(서버)요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송한다.어떤 프로그램이든 동시에 클라이언트와 서버가 될 수 있다. 이 규격에서 이 용어를 사용하는 것은프로그램의 일반적인 능력을 참조하기보다는 특정한 연결을 위해 프로그램이 수행하는 역할만을 참조하는것이다.마찬가지로 어떠한 서버도 원서버, 프락시, 게이트웨이, 터널 등 각 요구의 성격에 따라 동작을 전환하는역할을 할 수 있다. origin server(원서버)해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버. proxy(프락시)다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두 수행하는 중간프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전달된다. 프락시는 이 규격의클라이언트와 서버의 필요 조건을 모두 구현해야만 한다. gateway(게이트웨이)다른 서버를 위해 중간 역할을 하는 서버. 프락시와는 달리 게이트웨이는 요구 메시지를, 요청받은자원을 서비스하는 최종적인 원서버처럼 수신한다. 요구한 클라이언트는 자신이 게이트웨이와 통신하고있다는 것을 알지 못할 수 있다. tunnel(터널)두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구에 의하여시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않는다. 터널은 중계하고 있는 양 쪽의 연결이종결되면 사라진다. cache(캐시)프로그램이 응답 메시지를 저장하는 로컬 저장소. 메시지 보관, 조회 및 삭제를 제어하는 하부 시스템이기도하다. 캐시는 응답 시간, 향후 네트워크 대역폭 소모 및 동일한 요구를 감소시킬 목적으로 캐시할수 있는 응답을 저장한다. 어떤 클라이언트나 서버도 캐시를 포함할 수 있다. 단지 터널 역할을 하는서버는 캐시를 사용할 수 없다. cachable(캐시할 수 있는)응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으면 응답을 캐시할 수 있다고 한다.HTTP 응답의 캐시 가능 여부를 결정하는 원칙은 13 장에 정의되어 있다. 자원을 캐시할 수 있다 하더라도 캐시가 특정 요구에 대하여 캐시 된 사본을 사용할 수 있는지 여부에대한 추가적인 제한 사항이 있을 수 있다. first-hand(직접)응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프락시를 거쳐옴으로써 발생하는 불필요한지연이 없을 경우 응답이 직접 온다고 할 수 있다. 또한 검증이 원서버에서 직접 이루어진다면 응답이직접 온다고 할 수 있다. explicit expiration time(명백한 유효 시간)원서버가 추가적인 검증 없이는 캐시에 의해 엔터티를 더 이상 되돌려 주지 않기로 한 시간. 즉, 원서버가캐시된 데이터의 유효성을 보장할 수 있는 시간. heuristic expiration time(자동으로 설정되는 유효 시간)분명한 유효 시간이 설정되어 있지 않을 때 캐시가 할당하는 유효 시간 age(경과 시간)응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간. freshness lifetime(신선한 기간)응답의 생성 시점과 유효시간 만기 시점 사이의 시간 길이 fresh(신선한)응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 응답이 신선하다고 할 수 있다. stale(낡은)응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 낡았다고 할 수 있다. semantically transparent(의미상으로 분명한)성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버에 영향을미치지 않을 때 특정한 요구에 대하여 캐시가 "의미상으로 분명하게" 작동한다고 할 수 있다. 캐시가의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와 완전히 동일할 응답을 수신하게된다.( hop-by-hop 헤더는 제외). validator(검증자)캐시 엔트리가 엔터티의 복사본과 동일한지 알아내는 데 사용하는 규약 요소(예를 들면 엔터티태그나 Last-Modified 시간)1.4 Overall OperationHTTP 규약은 요구/응답 규약이다. 클라이언트는 요구 method, URI, 규약 버전의 형태로 서버에 요구메시지를 전송한다. 요구 변경자, 클라이언트 정보, 서버와의 접속에 사용되는 본문 내용을 포함하는MIME 유형의 메시지가 뒤따른다. 서버는 메시지의 규약 버전 및 성공 또는 실패 코드를 포함하는 상태정보로서 응답한다. 서버 정보, 엔터티 메타 정보, Entity-Body 내용을 포함하는 MIME 유형의 메시지도뒤따른다.대부분의 통신은 사용자 에이전트가 구동하며 특정 원서버에 적용할 요구로 구성되어 있다. 가장 단순한 경우 이것은 사용자 에이전트(UA)와 원서버(O) 사이의 단일 접속(v)에 의해 성취할 수있을 것이다. request chain ---------------------->UA ---------------- v ------------------- O <--------------------- response chain좀 더 복잡한 상황은 Request/Response chain에 하나 또는 그 이상의 중간 매개자가 있는 경우이다.프락시, 게이트웨이 및 터널의 세 가지 일반적인 중간 매개 형태가 있다. 프락시는 전송 에이전트로절대 표현 형태의 URI 요구를 수신하여 메시지의 전체 혹은 부분을 재작성한 후 URI가 표시하는 서버로재구성된 요구 메시지를 전달한다. 게이트웨이는 수신 에이전트로 다른 서버 위의 계층 역할을 수행하며필요하다면 원서버의 규약에 맞도록 요구를 해석하기도 한다. 터널은 메시지를 변경하지 않고 두 연결지점을 연결하는 중계역할을 수행한다. 터널은 통신(communication)이 중간 매개자가 메시지의 내용을이해할 수 없을 때라도 방화벽과 같은 중간 매개자를 통과할 필요가 있을 때 사용한다. request chain ------------------------------------->UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------ response chain위의 도표는 사용자 에이전트와 원서버 사이의 세 중간 매개자(A, B 및 C)를 보여 준다. 전체 고리를통과하는 요구 또는 응답 메시지는 네 개의 별도 연결을 통과하게 된다. 몇몇 HTTP 통신 선택 사항은최고 근접 거리의 비터널 이웃과의 통신, 연쇄적 연결 고리의 마지막 부분에만 또는 연결 고리에 따르는모든 연결에 적용되기 때문에 이러한 구분은 중요하다. 그림이 선형이지만 각 참여자는 복수의 동시통신에 참여할 수 있다. 예를 들어 B는 A의 요구를 처리함과 동시에 A를 제외한 복수의 클라이언트요구를 수신하고/수신하거나 C 이외의 서버에게 요구를 전송할 수 있다.터널 역할을 수행하는 것이 아닌 통신에 참여하는 어떤 것이라도 요구를 처리할 때 내부 캐시를 사용할수 있다. 캐시의 효과는 연결 고리를 따라 참가자 중 하나가 해당되는 요구에 적용할 수 있는 캐시된응답을 갖고 있다면 Request/Response chain이 짧아진다. 다음은 UA 또는 A가 캐시하지 않은요구에 대한 O (C를 경유) 초기 응답의 사본을 B가 가지고 있을 때의 결과 고리를 설명하고 있다. request chain --------->UA -----v----- A -----v----- B - - - - - - C - - - - - - O <-------- response chain보통 모든 응답을 캐시할 수 있는 것은 아니며 어떤 요구는 캐시 방식에 특별 요구를 하는 변경자를포함할 수 있다. 13 장에 캐시 방식과 캐시할 수 있는 응답에 대한 필요 조건이 기록되어 있다.사실상 World Wide Web에는 현재 실험되고 있거나 배포되고 있는 캐시와 프락시의 다양한 아키텍쳐와환경설정 방법이 있다. 이러한 것 중에는 대륙간 대역폭을 절약하기 위한 프락시 캐시의 국가적 계층,캐시 엔트리를 배포하거나 복수로 배포하는 시스템, CD-ROM 등을 통하여 캐시 된 데이터의 하부세트를 배포하는 조직 등이 있다. HTTP 시스템은 광대역 연결을 통한 기업 인트라넷, 저동력 무선연결의 PDA를 통한 연결 및 간헐적인 연결에 사용된다. HTTP/1.1의 목적은 고도의 신뢰성과 신뢰성을확보할 수 없다면 신뢰할 수 있는 실패의 표시 기능을 지닌 웹 응용프로그램을 개발하는 개발자의요구를 충족하는 규약 구조물을 새로 소개하면서도 이미 배포된 다양한 환경을 지원하는 것이다.HTTP 통신은 대개 TCP/IP 연결을 통하여 이루어진다. 기본 포트는 TCP 80 이지만 다른 포트를 사용할수도 있다. 그러나 이것은 HTTP가 인터넷 상의 다른 규약이나 다른 네트워크 위에서 구현될 수 없게하는 것은 아니다. HTTP는 단순히 신뢰할 수 있는 전송 수단을 가정할 뿐이며 이러한 보장을 해 줄 수있는 어떠한 규약을 사용해도 된다. HTTP/1.1의 요구 응답 구조를 적용하고자 하는 규약의 전송 데이터단위로 배치(mapping)하는 것은 이 규격의 범위 밖의 것이다.HTTP/1.0에서 대부분의 구현 방식은 각각의 요구/응답 교환에 새로운 접속을 사용하는 것이다.또한 HTTP/1.1에서는 하나의 접속을 하나 또는 그 이상의 요구/응답 교환에 사용할 수 있으나 연결이여러 가지 이유로 단절될 수 있다.( 8.1 절 참조)
2. 기호 관례 및 일반적인 문법2.1 추가된 BNF이 문서에서 명시된 모든 메커니즘은 설명형 문구로서 RFC 822 [9]에서 사용한 것과 유사한 추가된Backus-Naur Form (BNF)으로 설명되어 있다. 구현자는 이 규격을 이해하기 위하여 이러한 기호에익숙할 필요가 있다. 추가된 BNF는 다음의 구성 요소를 포함한다.name = definition규칙의 이름이 이름 그 자체(둘러싸는 "<" 및 ">"이 없는)이며 정의 부분과는 등호 문자("=")로 구별된다.계속되는 공백 문자는 규칙에 대한 규정이 한 줄 이상에 걸쳐 있음을 표시하는 들여쓰기의 경우에만의미가 있다. SP, LWS, HT, CRLF, DIGIT, ALPHA 등과 같은 몇몇 기본 규칙은 대문자로만 사용한다.정의문 내에서 소괄호는 규칙 이름의 사용 구별을 용이하게 해줄 경우에는 언제든지 사용한다."literal"인용 부호로 문자 텍스트 주위를 감싼다. 별도의 언급이 없으면 문자는 대소문자를 구별한다.rule1 | rule2막대 ("|")로 구분된 요소는 선택 사항이다. 예를 들어 "yes |no" 는 yes 나 no어느 것이든 가능하다.(rule1 rule2)괄호로 둘러싼 요소는 단일 요소로 취급한다. 따라서 "(elem (foo | bar) elem)"는 "elem foo elem"및 "elem bar elem"의 토큰 순서를 허용한다.*rule이것은 반복을 의미하는 것으로서 뒤이어서 나올 #rule과 혼동을 일으키는 표현 방식이므로 유의해야한다. 반복을 통해 이루어지는 결과는 하나의 단어나 수와 같이 한 개 요소의 표현 형태로 되는 것이며,#rule에서는 똑같은 반복이지만 여러 개 단어나 수의 열 형태와 같이 여러 개 요소의 나열 형태로 표현되는 것이다. *element와 같은 표기 방법으로 쓰인다. 이것은 적어도 n개와 최대 m개의 요소로구성되는 한 가지 결과를 의미한다. 즉, 1*2DIGIT 라는 표현은 숫자가 적어도 한 개 최대 두 개로 구성되어 한 개의 수를 나타낸다는 뜻이다. 4는 한 가지 예이며, 45도 한 가지 예가 된다. 그러나 345의 경우에는 숫자 세 개로 구성된 한 개 요소이므로 최대 갯수에 위배되어 적합하지 않다.n과 m은 생략될 수 있으며, 이 경우에 n의 기본값은 0이고 m의 기본값은 무한대이다. 그러므로 "*(element)"는 0개를 포함해서 어떤 개수라도 가능하고, "1*element"의 경우는 한 요소의표현에 있어 적어도 한 개는 있어야 하며 최대 갯수에는 제한이 없다.[rule]대괄호는 선택 요소를 둘러 싼다. "[foo bar]" 는 "*1(foo bar)"와 동일하다.N rule특정 횟수의 반복을 나타낸다. "(element)" 은 "*(element)"와 동일하다. 즉 요소(element)가 정확하게 번 표시된다. 따라서 2 DIGIT 는 2 자리 숫자, 3 ALPHA 는 세 개의알파벳 문자로 구성된 문자열이다.#rule앞서 설명한 것처럼 반복을 나타내긴 하지만 요소들의 나열로서 표현되는 것이다. 즉, 1#DIGIT 라고하면 여러 개의 수로 구성된 수열로서 표현되는데, 최소 한 개의 수는 있어야 하고 최대 갯수는 제한이없는 수열이 된다. 각 요소들 사이의 구분은 ","와 LWS를 이용하는데, 여러 개의 나열 형태를 쉽게표현할 수 있게 해준다. 예를 들어, (*LWS element *(*LWS "," *LWS element)) 이것을 간단하게1#element 이와 같이 표현할 수 있다. 또 다른 예를 들자면, 1#2(2DIGIT)이것은 숫자 두 개로 구성된수가 적어도 한 개가 있어야 하며 최대 두 개까지 가능하다는 것이다. 즉, 23 이렇게 표현될 수도 있고, 23, 56 이렇게 두 개로 표현될 수도 있다. 이것이 *rule과의 차이점이고, #rule 에서도 "#element" 의구성이 그대로 성립한다. 이에 대한 설명은 *rule 의 경우와 같다. ","를 이용하여 나열함에 있어, nullelement가 허용된다. 예를 들어, 1#3(2DIGIT)과 같은 표현식에 대해23, , 56, 34 이렇게 null element표시가 가능하지만, 실제 갯수는 세 개로서 간주된다. 따라서 최소 한 개 최대 세 개의 제한에 위배되지않는다.; comment규칙 문장에서 오른쪽으로 약간 떨어져 있는 세미콜론은 해당 라인의 끝에까지 계속되는 주석의 시작을의미한다. 이것은 규격과 병행하여 적절한 설명을 포함시키기 위한 방법이다.implied *LWS두 개의 인접한 단어 (token or quoted-string) 또는 인접한 토큰(tokens)과 식별자 (tspecials) 사이에LWS (linear whitespace)가 포함될 수 있다. 여기서 두 개의 토큰 사이에는 반드시 적어도 하나의식별자가 존재하여 각기 하나의 토큰으로 간주되지 않게끔 구별되어야 한다.2.2 기본 규칙다음의 규칙은 기본적인 분석 구조를 설명하기 위해 이 규격 전반에 걸쳐 사용되고 있다. US-ASCII로코드화 된 문자 집합은 ANSI X3.4-1986 [21]에 의하여 규정되었다. OCTET = <모든 8-bit 연속 데이터> CHAR = <모든 US-ASCII 문자 (octets 0 - 127)> UPALPHA = <모든US-ASCII 대문자 "A".."Z"> LOALPHA = <모든 US-ASCII 소문자 "a".."z"> ALPHA = UPALPHA | LOALPHA DIGIT = <모든 US-ASCII 숫자 "0".."9"> CTL = <모든 US-ASCII 제어 문자 (octets 0 - 31) 및 DEL (127)> CR = <US-ASCII CR, 캐리지 리턴(13)> LF = <US-ASCII LF, 라인피드 (10)> SP = <US-ASCII SP, 스페이스 (32)> HT = <US-ASCII HT, 수평 탭 (9)> <"> = <US-ASCII 이중 인용 부호(34)>HTTP/1.1은 연속적인 CR LF를 Entity-Body를 (부록 19.3 참조) 제외한 모든 규약 요소의 라인 마감부호로 정의한다. Entity-Body 내에서의 라인 마감 부호는 3.7 절에서 설명된 것처럼 연관된 mediatype에 의하여 정의한다. CRLF = CR LFHTTP/1.1 헤더는 계속되는 라인이 스페이스나 수평 탭으로 시작한다면 복수의 라인에 걸쳐 계속작성할 수 있다. 폴딩(folding)을 포함한 모든 선형 공백 스페이스는 SP와 동일한 의미를 가진다. LWS = [CRLF] 1*( SP | HT )TEXT 규칙은 메시지 분석기가 해석하지 않도록

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] [MAIL] MIME 관련  (0) 2005.01.17
[펌] 코드시스템및 한글문자체계  (0) 2005.01.17
[펌]Single Sign On...  (0) 2005.01.17
JSP 다운로드시 헤더 ㅡㅡ  (0) 2005.01.13
헐.. 죽이넹  (0) 2004.12.21
Posted by tornado
|

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] 코드시스템및 한글문자체계  (0) 2005.01.17
[펌] http RFC  (0) 2005.01.17
JSP 다운로드시 헤더 ㅡㅡ  (0) 2005.01.13
헐.. 죽이넹  (0) 2004.12.21
얼... 좋은걸~  (0) 2004.12.17
Posted by tornado
|

[nio] Channels 클래스

JAVA/JSE 2005. 1. 17. 11:20

간단한 회사 웹 메일 만들던 중 메일 발송 부분에서 자료 첨부를 Struts 의 FormBean 을 이용해서

파일을 보내는데 nio 를 이용해 보려고 했다.

 

폼 파일에서는 FormFile.getInputStream() 이라는 것만 제공해 주는데..

무식하게 스리 getInputStream() 으로 반납되는 InputStream 을 FileInputStream 으로 바꾸려

뻘짓거리를 ㅡㅡ;;

 

그래서 API 를 뒤져보니.. java.nio.channels 클래스를 보니 newChannel() 메소드 발견~

 

아래와 같이 처리 함.

 

File file = new File("경로","파일명");

InputStream is = formFile.getInputStream();

ReadableByteChannel byteChannel = Channels.newChannel( is )

FileChannel outputChannel = new FileOutputStream(file).getChannel();

outputChannel.transferFrom(byteChannel, 0, is.available());

 

일단 되는것 확인...

 

Channels 클래스에 InputStream, OutputStream, Reader, Writer 로 변환해 주는게 다 모여있넹.

 

대충 알았으니 이제 놀자 ㅋㅋ

 

 

 

 

'JAVA > JSE' 카테고리의 다른 글

[펌] 손쉬운 정적 분석 툴로 버그 잡기  (0) 2005.05.11
FileFilter... 까먹기 싫어~~~  (0) 2005.02.12
[펌] Sorting Algorithm  (0) 2005.01.15
[link] 자바 검색 봇~  (0) 2005.01.11
[펌] [Collection Framework ] List, Set and Map  (0) 2004.12.29
Posted by tornado
|

[펌] Sorting Algorithm

JAVA/JSE 2005. 1. 15. 17:16

Sorting algorithm

From Wikipedia, the free encyclopedia.

In computer science and mathematics, a sorting algorithm is an algorithm that puts elements of a list in a certain order. The most used orders are numerical order and lexicographical order. Efficient sorting is important to optimizing the use of other algorithms (such as search and merge algorithms) that require sorted lists to work correctly; it is also often useful for canonicalizing data and for producing human-readable output.

Contents [hide]


 

Classification

Sorting algorithms used in computer science are often classified by:

  • computational complexity (worst, average and best behaviour) in terms of the size of the list (n). Typically, good behaviour is O(n log n) and bad behaviour is O(n2). Sort algorithms which only use an abstract key comparison operation always need at least O(n log n) comparisons on average; sort algorithms which exploit the structure of the key space cannot sort faster than O(n log k) where k is the size of the keyspace.
  • memory usage (and use of other computer resources)
  • stability: stable sorting algorithms maintain the relative order of records with equal keys. That is, a sorting algorithm is stable if whenever there are two records R and S with the same key and with R appearing before S in the original list, R will appear before S in the sorted list.

When equal elements are indistinguishable, such as with integers, stability is not an issue. However, say we were sorting these pairs of numbers by their first coordinate:

(4, 1) (3, 1) (3, 7) (5, 6) 

In this case, two different results are possible, one which maintains the relative order records with equal keys, and one which doesn't:

(3, 1) (3, 7) (4, 1) (5, 6) (order maintained) (3, 7) (3, 1) (4, 1) (5, 6) (order changed) 

Unstable sorting algorithms may change the relative order of records with equal keys, stable sorting algorithms never so. Unstable sorting algorithms can be specially implemented to be stable. One way of doing this is to artificially extend the key comparison, so that comparisons between two objects with otherwise equal keys are decided using the order of the entries in the original data order as a tie-breaker. Remembering this order, however, often involves an additional space penalty.

Table of sorting algorithms

In this table, n is the number of records to be sorted, k is the number of distinct keys, and u is the number of unique records.

Stable

Unstable

Questionable sort algorithms not intended for production use:

Summaries of the popular sorting algorithms

Bubble sort

Bubble sort is the most straightforward and simplistic method of sorting data that could actually be considered for real world use. The algorithm starts at the beginning of the data set. It compares the first two elements, and if the first is greater than the second, it swaps them, then repeats until no swaps have occurred on the last pass. The algorithm does this for each pair of adjacent elements until there are no more pairs to compare. This algorithm, however, is vastly inefficient, and is rarely used except in education (i.e., beginning programming classes). A slightly better variant is generally called shuttle sort, and works by inverting the ordering criteria, and the pass direction on alternating passes.

Insertion sort

Insertion sort is similar to bubble sort, but is more efficient as it reduces element comparisons somewhat with each pass. An element is compared to all the prior elements until a lesser element is found. In other words, if an element contains a value less than all the previous elements, it compares the element to all the previous elements before going on to the next comparison. Although this algorithm is more efficient than the Bubble sort, it is still inefficient compared to many other sort algorithms since it, and bubble sort, move elements only one position at a time. However, insertion sort is a good choice for small lists (about 30 elements or fewer), and for nearly-sorted lists. These observations can be combined to create a variant of insertion sort which works efficiently for larger lists. This variant is called shell sort (see below).

Shell sort

Shell sort was invented by Donald Shell in 1959. It improves upon bubble sort and insertion sort by moving out of order elements more than one position at a time. One implementation can be described as arranging the data sequence in a two-dimensional array (in reality, the array is an appropriately indexed one dimensional array) and then sorting the columns of the array using the Insertion sort method. Although this method is inefficient for large data sets, it is one of the fastest algorithms for sorting small numbers of elements (sets with less than 10 or so elements). Another advantage of this algorithm is that it requires relatively small amounts of memory.

See work-in-place article for the list of sorting algorithms that can be written as work-in-place.

Merge sort

Merge sort takes advantage of the ease of merging already sorted lists into a new sorted list. It starts by comparing every two elements (i.e. 1 with 2, then 3 with 4...) and swapping them if the first should come after the second. It then merges each of the resulting lists of two into lists of four, then merges those lists of four, and so on; until at last two lists are merged into the final sorted list.

Heapsort

Heapsort is a member of the family of selection sorts. This family of algorithms works by determining the largest (or smallest) element of the list, placing that at the end (or beginning) of the list, then continuing with the rest of the list. Straight selection sort runs in O(n2) time, but Heapsort accomplishes its task efficiently by using a data structure called a heap, which is a binary tree where each parent is larger than either of its children. Once the data list has been made into a heap, the root node is guaranteed to be the largest element. It is removed and placed at the end of the list, then the remaining list is "heapified" again.

Radix sort

Some radix sort algorithms are counterintuitive, but they can be surprisingly efficient. If we take the list to be sorted as a list of binary strings, we can sort them on the least significant bit, preserving their relative order. This "bitwise" sort must be stable, otherwise the algorithm will not work. Then we sort them on the next bit, and so on from right to left, and the list will end up sorted. This is most efficient on a binary computer (which nearly all computers are). If we had a ternary computer, we would regard the list as a list of base 3 strings and proceed in the same way. Most often, the bucket sort algorithm is used to accomplish the bitwise sorting.

Radix sort can also be accomplished from left to right, but this makes the algorithm recursive. On a binary (radix 2) computer, we would have to sort on the leftmost bit, and then sort the sublist with 0 as the leftmost bit, and then sort the sublist with 1 as the leftmost bit, and so on.

Graphical representations

Microsoft's "Quick" programming languages (such as QuickBASIC and QuickPascal) have a file named "sortdemo" (with extension BAS and PAS for QB and QP, respectively) in the examples folder that provides a graphical representation of several of the various sort procedures described here, as well as performance ratings of each.

Also, a program by Robb Cutler called The Sorter (http://faculty.harker.org/robbc/Pages/Software/TheSorter/TheSorter.htm) for classic Mac OS performs a similar function. It illustrates Quick Sort, Merge Sort, Heap Sort, Shell Sort, Insertion Sort, Bubble Sort, Shaker Sort, Bin Sort, and Selection Sort.

See also

External links and references

'JAVA > JSE' 카테고리의 다른 글

FileFilter... 까먹기 싫어~~~  (0) 2005.02.12
[nio] Channels 클래스  (0) 2005.01.17
[link] 자바 검색 봇~  (0) 2005.01.11
[펌] [Collection Framework ] List, Set and Map  (0) 2004.12.29
소스포지.. 디컴파일해두 소스 안보여주는  (0) 2004.11.23
Posted by tornado
|