통상 form의 element에 접근하는 방식은
js를 사용하는 사람들 마다 다소 약간의 차이가 있습니다.
선호하는 코딩 스타일이 다르다는 소리죠
그렇지만 한가지 공통점은 어디서든 돌아가게 만들자~ 는게 목적 아닐까요?
javascript 에서 form 뿐만 아니라 document단의 element에 접근하는 방법은
계층적 접근에 대해서 약간 이해를 해야할 부분이 있습니다.
그럼 아래에 기본적인 형식을 이용해서 설명을 곁들여 보겠습니다.
-------------------------------------- 예제 코드1 --------------------------------------
<html>
<head>
<title>문서제목</title>
</head>
<body>
<form name="wfm">
<input type="text" name="lg" /><br />
<input type="password" name="lp" /><br />
<input type="checkbox" name="auto" /><br />
<input type="submit" value="전송" />
</form>
</body>
</html>
------------------------------------------------------------------------------------------------
위와 같은 form이 있다고 가정 하겠습니다.
스크립트를 통해서 문서내의 특정 tag에 접근하는 규칙은 . 을 기준으로
계층적 구조로 접근하는 형식을 쓰는 것입니다.
쉬운예로
document.forms["wfm"].elements["lg"];
문서 . 폼 . 객체
이해가 되시나요?
물론 폼을 거치지 않고 바로 접근하는 방법도 있습니다.
document.getElementById("id");
document.getElementsByName("name");
문서 . 아이디 | 네임 객체지정;
이런 형식이 대표적인 예라고 보시면 됩니다.
get은 가져오다 라는 의미로 해석을 하시면 이해가 빠를것이라 생각됩니다.
엘리먼트의 아이디나 네임을 지정해서 해당객체를 지정하는 것입니다.
그럼 이런 형식의 접근을 이용한 실질적인 방법을 만들어 보겠습니다.
-------------------------------------- 예제 코드2 --------------------------------------
<html>
<head>
<title>문서제목</title>
</head>
<script language="javascript">
function fm(){
var obj = document.getElementById("sp");//span tag의 id를 이용한 접근
var frm = document.forms["wfm"];//폼까지의 접근자를 지정
for ( i=0; i < frm.length; i++){
// form elements는 form의 배열형식으로도 접근 가능합니다.
tc = "=\n\n"
tc += "element type : " + frm[i].type + "\n\n"; //tc 변수에 문자열지정
tc += "element name : " + frm[i].name + "\n\n";
tc += "element value : " + frm[i].value + "\n\n";
obj.innerText += tc;//지정된 id의 연결정보를 담고있는 obj변수에
//innerText 를 이용하여 span tag영역안에 문자를 넣어라는 표현입니다.
}
return false;
}
</script>
<body>
<form name="wfm" onsubmit="return fm();">
<input type="text" name="lg" /><br />
<input type="password" name="lp" /><br />
<input type="checkbox" name="auto" value="1" /><br />
<input type="submit" value="전송" />
</form>
<span id="sp"></span>
</body>
</html>
------------------------------------------------------------------------------------------------
실행된 결과물을 보시면
element type : text
element name : lg
element value :
element type : password
element name : lp
element value :
element type : checkbox
element name : auto
element value : 1
element type : submit
element name :
element value : 전송
이런 값이 출력됩니다.
단편적인 예를 들어 설명을 하였지만 javascript를 이용하여
window, document 등에 접근하는 형식 대동소이합니다.
forms[""], elements[""] 이런 내용은 하나의 형식입니다.
elements["string"] 이런 표현식은 form의 객체에 접근하는 경우에만
사용가능 합니다.
예제코드2에 사용된 onsubmit 이벤트핸들러에 대해서 말씀드리면
많은 초보자들이 <input type="button" value="전송" onclick="함수명()" />
이런식으로 사용하여 폼유효성 체크를 하고 js에서 form.submit();를 이용하여
form을 전송하는 것을 많이 보았습니다.
하지만 스쿨 팁텍에도 언젠가 올라온 내용이 있는데요
이런경우 form의 input field에서 enter를 입력하면 form이 submit 되는 현상을
보게 됩니다.
위 input field 예는 버튼을 클릭을 해야만 함수를 호출하게 되어 있습니다.
반면 onsubmit 이벤트 핸들러는 form이 submit 되는것을 인식합니다.
onsubmit = "return 함수명();"
이런식으로 사용하여 함수내에서 form의 입력된 정보에 유효성 검사를 하여
맞지 않을 경우 false를 return 하는 형식을 취해주면 form이 전송되는 것도
막을 수 있습니다. = "return <- 이문장은 함수로 부터 되돌아 오는
값이 false가 아니면 submit을 시키겠다는 뜻입니다.
유니코드(Unicode)는 전세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 산업 표준이다. 유니코드 협회(Unicode Consortium)가 제정하며, 현재 최신판은 2006년 7월에 공개된 유니코드 5.0이다. 이 표준에는 ISO 10646 문자 집합, 문자 인코딩, 문자 정보 데이터베이스, 문자들을 다루기 위한 알고리즘 등이 포함된다.
유니코드의 목적은 현존하는 문자 인코딩 방법들을 모두 유니코드로 교체하려는 것이다. 기존의 인코딩들은 그 규모나 범위 면에서 한정되어 있고, 다국어 환경에서는 서로 호환되지 않는 문제점이 있었다. 유니코드가 다양한 문자 집합들을 통합하는 데 성공하면서 유니코드는 컴퓨터 소프트웨어의 국제화와 지역화에 널리 사용되게 되었으며, 비교적 최근의 기술인 XML, 자바, 그리고 최신 운영체제 등에서도 지원하고 있다.
역사
- 1991년: 유니코드 1.0
- 1993년: 유니코드 1.1
- 1996년: 유니코드 2.0 ― 11172자의 모든 현대 한글이 포함되었다.
- 1998년: 유니코드 2.1
- 2000년: 유니코드 3.0
- 2001년: 유니코드 3.1 ― 보조 평면들이 처음으로 소개되었다.
- 2002년: 유니코드 3.2
- 2003년: 유니코드 4.0
- 2005년: 유니코드 4.1
- 2006년: 유니코드 5.0 (문자 데이터베이스는 7월 18일에 발표되었으나 책은 11월 9일 출시)
- 2008년: 유니코드 5.1 (2008년 초나 중반에 나올 것으로 추측)
유니코드 목록
링크
아스키(ASCII) 또는 미국 정보 교환 표준 부호(American Standard Code for Information Interchange)는 영문 알파벳을 사용하는 대표적인 문자 인코딩이다. 아스키는 컴퓨터와 통신 장비를 비롯한 문자를 사용하는 많은 장치에서 사용되며, 대부분의 문자 인코딩이 아스키에 기반한다.
아스키는 1967년에 표준으로 제정되어 1986년에 마지막으로 개정되었다. 아스키는 7비트 인코딩으로, 33개의 출력 불가능한 제어 문자들과 공백을 비롯한 95개의 출력 가능한 문자들로 이루어진다. 제어 문자들은 역사적인 이유로 남아 있으며 대부분은 더 이상 사용되지 않는다. 출력 가능한 문자들은 52개의 영문 알파벳 대소문자와, 10개의 숫자, 32개의 특수 문자, 그리고 하나의 공백 문자로 이루어진다.
아스키가 널리 사용되면서 다양한 아스키 기반의 확장 인코딩들이 등장했으며, 이들을 묶어서 아스키라고 부르기도 한다. 대표적으로 7비트 인코딩을 유지한 ISO/IEC 646과, 원래 아스키 코드 앞에 비트 0을 넣어 8비트 인코딩을 만든 IBM 코드 페이지와 ISO 8859가 있다. 이 인코딩들은 언어군에 따라 같은 숫자에 서로 다른 문자가 배당된 경우가 많다.
MIME (Multipurpose Internet Mail Extensions)는 전자우편을 위한 인터넷 표준 포맷이다. 전자우편은 7비트 ASCII 문자를 사용하여 전송되기 때문에, 8비트 이상의 코드를 사용하는 문자나 바이너리 파일들은 MIME 포맷으로 변환되어 SMTP로 전송된다. 실질적으로 SMTP로 전송되는 대부분의 전자우편은 MIME 형식이다. MIME 표준에 정의된 content types은 HTTP와 같은 통신 프로토콜에서 사용되며, 점차 그 중요성이 커지고 있다.
소개
기본적으로 인터넷 전자우편 전송 프로토콜인 SMTP는 7비트 ASCII 문자만을 지원한다. 이것은 7비트 ASCII 문자로 표현할 수 없는 영어 이외의 언어로 쓰인 전자우편은 제대로 전송될 수 없다는 것을 의미한다. MIME은 ASCII가 아닌 문자 인코딩을 이용해 영어가 아닌 다른 언어로 된 전자우편을 보낼 수 있는 방식을 정의한다. 또한 그림, 음악, 영화, 컴퓨터 프로그램과 같은 8비트 바이너리 파일을 전자우편으로 보낼 수 있도록 한다. MIME은 또한 전자우편과 비슷한 형식의 메시지를 사용하는 HTTP와 같은 통신 프로토콜의 기본 구성 요소이다. 메시지를 MIME 형식으로 변환하는 것은 전자우편 프로그램이나 서버 상에서 자동으로 이루어진다.
전자우편의 기본적인 형식은 RFC 2821에서 정의하고 있다. 이 문서는 RFC 822를 대체한다. 이 문서는 텍스트 전자우편의 헤더와 본문의 형식을 명시하고 있으며, 그 중에는 우리에게 익숙한 "To:", "Subject:", "From:", "Date:" 등의 헤더가 포함되어 있다. MIME은 메시지의 종류를 나타내는 content-type, 메시지 인코딩 방식을 나타내는 content-transfer-encoding과 같은 추가적인 전자우편 헤더를 정의하고 있다. MIME은 또한 ASCII가 아닌 문자를 전자우편 헤더로 사용할 수 있도록 규정하고 있다.
MIME은 확장 가능하다. MIME 표준은 새로은 content-type과 또 다른 MIME 속성 값을 등록할 수 있는 방법을 정의하고 있다.
MIME의 명시적인 목표 중 하나는 기존 전자우편 시스템과의 호환성이다. MIME을 지원하는 클라이언트에서 비 MIME가 제대로 표시될 수 있고, 반대로 MIME을 지원하지 않는 클라이언트에서 간단한 MIME 메시지가 표시될 수 있다.
MIME 헤더
MIME-Version
이 헤더는 해당 메시지가 MIME 형식임을 나타낸다. 현재 사용되는 값은 "1.0"이므로 아래와 같이 사용할 수 있다.
MIME-Version: 1.0
Content-Type
이 헤더는 메시지의 타입과 서브타입을 나타낸다. 예를 들면
Content-Type: text/plain
타입과 서브타입을 합쳐 MIME 타입이라 부른다. Internet media type 이라고도 부른다. 다양한 파일 포맷이 MIME 타입으로 등록되어 있다. text 타입은 charset 인자를 가질 수 있으며 이 인자는 문자 인코딩을 지정한다.
content-type 헤더와 MIME 타입은 전자우편을 위해 정의된 것이지만, 이제는 HTTP, SIP와 같은 인터넷 프로토콜에서 함께 사용하고 있다. MIME 타입 등록은 IANA에서 관리하고 있다.
multipart 메시지 타입을 통해 MIME은 트리 구조의 메시지 형식을 정의할 수 있다. 이 방식은 다음을 지원한다.
- text/plain을 통한 단순 텍스트 메시지 ("Content-type:"의 기본값")
- 첨부가 포함된 텍스트 (text/plain 파트와 텍스트가 아닌 파트로 구성된 multipart/mixed). 파일을 첨부한 MIME 메시지는 "Content-disposition:" 헤더를 통해 파일의 본래 이름을 지정한다. 파일의 종류는 MIME의 content-type 헤더와 파일 확장자를 통해 알 수 있다.
- 원본 메시지가 첨부된 답장 메시지 (text/plain 파트와 원본 메시지를 나타내는 message/rfc822 파트로 구성된 multipart/mixed)
- 평문 텍스트와 HTML과 같이 다른 포맷을 함께 보낸 메시지 (multipart/alternative)
- 그 외 다양한 메시지 구조들
Content-Transfer-Encoding
MIME (RFC 2045)는 바이너리 데이터를 ASCII 텍스트 형식으로 변환하기 위한 몇가지 방법을 정의하고 있다. content-transfer-encoding MIME 헤더를 통해 변환 방식을 지정한다. RFC 문서와 전송 인코딩에 대한 IANA 목록은 다음을 정의하고 있다.
- 일반 SMTP에 사용 가능
- 7bit - [1..127]의 ASCII 코드로 이루어진 데이터로 줄 단위로 표현하며 각 줄을 CR, LF로 끝난다. 한 줄의 최대 길이는 CR (ASCII 코드 13), LF (ASCII 코드 10)를 제외하고 998자이다.
- quoted-printable - 약간의 바이너리 데이터가 포함된 US-ASCII로 이루어진 텍스트 데이터를 표현할 때 효과적이다. US-ASCII는 특별한 변환을 거치지 않고 그대로 표시되기에 효율적이며 인코딩한 데이터를 사람이 이해할 수 있다.
- base64 - 임의의 바이너리 데이터를 7비트 데이터로 변환한다. 고정된 오버헤드가 발생하고 비 텍스트 데이터의 변환 시 사용한다.
- 8BITMIME 지원하는 SMTP 서버에 사용 가능
- 8bit - 8비트로 표현된 데이터로 한 줄 당 998자로 표현하며 CR, LF로 끝난다.
- binary - 일련의 octets. SMTP에서는 사용 할 수 없다.
Encoded-Word
RFC 2822의 정의에 따르면, 메시지 헤더와 그 값은 항상 ASCII 문자를 사용해야 한다. ASCII가 아닌 헤더 값은 MIME의 encoded-word 문법(RFC 2047)에 따라 인코딩해야 한다. 이 문법은 원본 문자 인코딩("문자셋")과 원본 데이터를 ASCII 문자로 변환하는 데 사용한 인코딩 방식을 포함한다.
encoded-word의 형식: "=?문자셋?인코딩 방식?인코드된 데이터?=".
- 문자셋은 보통 utf-8을 사용한다. 하지만 IANA에 등록된 어떤 문자셋도 사용 가능하다.
- 인코딩 방식은 quoted-printable 인코딩 방식과 비슷한 Q-encoding 방식을 나타내는 "
Q"나 base64 인코딩을 나타내는 "B" 중 하나를 사용할 수 있다. - 인코드된 데이터는 인코딩 방식에 의해 변환된 데이터이다.
Q-encoding과 quoted-printable의 차이
RFC 2047에 따르면, encoded-word는 공백 문자(white space)를 포함해서는 안된다. 따라서 ASCII 코드로 20h(iso-8859-1에서의 스페이스)인 문자는 인코딩을 거쳐야 한다. ASCII 20h(20h가 공백이 아닐지라도)인 문자는 보통 "_" 문자(ASCII 5Fh)로 변환한다. 공백을 "=20"으로 인코딩한 것보다 이 방식이 인코드된 데이터의 가독성을 높여준다.
예를 들어,
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=
위 문장은 "Subject: ¡Hola, señor!"를 인코딩한 데이터이다.
encoded-word 형식은 헤더 이름에는 사용할 수 없다. 헤더 이름은 항상 US-ASCII로 표현해야 한다.
Multipart 메시지
MIME multipart 메시지는 "Content-type:" 헤더에 boundary 파라미터를 포함한다. 이 boundary는 다음과 같이 각 메시지 파트를 구분하는 역할을 하며, 메시지의 시작과 끝부분에도 나타난다.
Content-type: multipart/mixed; boundary="frontier" MIME-version: 1.0 This is a multi-part message in MIME format. --frontier Content-type: text/plain This is the body of the message. --frontier Content-type: text/html; encoding=UTF-8 Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--
각 파트는 Content-로 시작하는 자신만의 헤더와 본문을 갖는다. 그리고 multipart 메시지는 중첩 가능하다. 각 파트는 자신만의 문자셋과 인코딩 방식(Content-Transfer-Encoding)을 파트 헤더에서 정의하고 있다. Multipart 메시지에는 아래와 같은 종류가 있다.
Notes:
- 첫 번째 boundary 전에 나오는 내용은 MIME을 지원하지 않는 클라이언트를 위해 제공된다. MIME 호환 클라이언트는 이 내용을 무시한다.
- Boundary를 선택하는 것은 전자 우편을 전송하는 클라이언트의 몫이다. 보통 무작위의 문자를 선택함으로써 메시지의 본문과 충돌을 피한다.
Mixed
Multipart/mixed는 다른 "Content-type" 헤더를 갖는 파일을 전송하는데 사용한다. 그림이나 쉽게 읽을 수 있는 파일을 전송할 때, 대부분의 전자 우편 클라이언트는 이를 직접 화면에 표시할 것이다. 그렇지 않을 경우 해당 데이터는 첨부 파일의 형태로 표시된다. "Content-disposition" 헤더는 첨부 파일의 이름을 표시하는 데 사용한다.
Digest
RFC 2049에 명시되어 있듯이 multipart/mixed와 multipart/digest는 최소한 지원해야 할 MIME 타입이다. mixed 파트의 기본 content-type은 text/plain이며, digest의 경우 message/rfc822이다. Multipart/digest는 하나 이상의 메시지를 포워딩 하기 위한 간편한 방법이다.
Alternative
Multipart/alternative 메시지는 동일한 내용을 다른 형식으로 표현할 때 사용된다. 각각의 파트는 서로 다른 "Content-type" 헤더를 갖으며, MIME을 지원하지 않는 클라이언트에서 처리를 쉽게 하고자 표현하기 쉬운 형식에서 복잡한 형식 순으로 메시지에 나타난다. 따라서 메일 클라이언트는 각 파트를 순서대로 검색하여 자신이 표현할 수 있는 마지막 파트를 선택하게 된다. 일부 클라이언트는 이런 순서를 무시한 채 자신이 선호하는 형식을 표시하기도 한다. 일반적으로 오래된 클라이언트를 위해 text/plain 타입의 파트가 먼저 나오고 최신 클라이언트를 위해 text/html 타입의 파트가 나온다.
예전 anti-spam 필터는 text/html 파트보다 파싱이 쉽다는 이유로 메시지의 text/plain 파트 만을 검사했다. 스패머들은 이러한 점을 악용해 메시지의 text/plain 파트에는 평범한 내용을 넣고 대신 text/html에는 광고를 포함하였다. 이런 방식을 막기 위해 anti-spam 소프트웨어는 multipart/alternative 메시지 중 각 파트가 매우 상이한 내용을 갖을 경우 이를 스팸 메시지로 처리하는 식으로 해당 메시지를 걸러낸다.
Related
Multipart/related 메시지는 하나의 주 내용을 포함하며 보통 제일 먼저 나오는 파트가 그것이다. 뒤따르는 파트들은 "Content-ID" 헤더를 포함해야 한다. 보통 content-id로는 URL이 사용되며 주 파트는 이를 통해 뒤따르는 파트들을 메시지 안에서 참조한다. 보통 쓰이는 방식은 주 파트로 HTML 문서를 사용하고, HTML 문서 내의 img 태그가 참조하는 이미지들을 뒤따르는 파트로 표현하는 방식이다.
Report
Multipart/report 메시지는 메일 서버를 위한 형식화된 데이터를 포함한다. 이 메시지 타입은 text/plain과 message/delivery-status로 나뉜다.
Signed
Multipart/signed 메시지는 본문과 서명 파트를 갖는다. MIME 헤드를 포함하는 본문 파트는 서명을 생성하기 위해 사용된다. Application/pgp-signature, application/x-pkcs7-signature 등의 서명이 사용된다.
Encrypted
Multipart/encrypted 메시지 타입은 암호화된 application/octet-stream과 이를 풀기 위한 정보를 갖는 제어 파트로 구분된다.
See also
- SOAP with Attachments
- DIME — Microsoft proposed a technology called DIME which would have streamlined MIME, primarily for use in web services.
- S/MIME
- Mailcap
- Unicode and e-mail
References
- RFC 1847
- Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
- RFC 2045
- MIME Part One: Format of Internet Message Bodies.
- RFC 2046
- MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
- RFC 2047
- MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
- RFC 4288
- MIME Part Four: Media Type Specifications and Registration Procedures.
- RFC 4289
- MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
- RFC 2049
- MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
- RFC 2231
- MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
- RFC 2387
- The MIME Multipart/Related Content-type
External links
본문 컴퓨터 프로그램을 작동시키기 위한 모든 기능과 기구의 총칭. 주기억 장치, 중앙 처리 장치, 입출력 장치, 데이터, 파일, 프로그램 등이 포함된다. 태스크가 실행되는 단계에서 제어 프로그램으로 각종 자원을 할당한다.
출처 : 네이버 IT용어 사전
