본 문서는 ID3v24 Structure 문서(http://id3.org/id3v2.4.0-structure)를 번역한 글입니다.

잘못된 번역 또는 오탈자에 대한 지적은 달갑게 받도록 하겠습니다 :)




비공식 표준 문서 M. Nilsson

파일명: id3v2.4.9-structure.txt 2000. 11. 1.


ID3 태그 버전 2.4.0 - 기본 구조


이 문서의 상태

    

   이 문서는 비공식적인 표준이며, ID3v2.3.0 표준을 대체한다 [ID3v2]. 공식 표준문서와 내용이

같더라도, 다른 리비전 번호를 사용할 것이다. 내용을 명확하게 하기 위해 변경될 수는 있지만

기능적으로 추가되거나 대체되지는 않을 것이다.


이 문서의 배포에는 제한이 없다.



초록


   이 문서는 비공식 표준인 ID3v2 [ID3v2]의 수정된 버전으로써 ID3v2.4.0의 기본 구조를

설명한다. ID3v2는 오디오 파일 내에서 오디오의 메타 정보를 저장하는 유연한 방법을 제공한다.

포함되는 정보는 이퀄라이제이션 커브와 같은 기술적인 정보뿐만 아니라 제목, 연주자, 저작권

등의 정보이다.


   ID3v2.4.0은 구현을 가능한 용이하게 수정할 수 있도록 하기 위해 되도록 ID3v2.3.0과

유사하게 구성한다.



1. 목차


이 문서의 상태

초록

1. 목차

2. 이 문서의 규칙

2. 표준 개요

3. ID3v2 개요

3.1. ID3v2 헤더(Header)

3.2. ID3v2 확장된 헤더(Extended header)

3.3. 패딩(Padding)

3.4. ID3v2 푸터(Footer)

4. ID3v2 프레임개요

4.1. 프레임 헤더 플래그

4.1.1. 프레임 상태 플래그

4.1.2. 프레임 포맷 플래그

5. 태그 위치

6. 비동기화(Unsynchronisation)

6.1. 비동기화 스키마

6.2. Synchsafe 정수

7. 저작권

8. 참조

9. 작성자 주소



2. 이 문서의 규칙


태그에 표시된 따옴표(")안의 텍스트는 정확한 텍스트 문자열이다.

숫자 앞의 $ 기호는 16진수를 의미하며, %기호는 이진수를 의미한다. $xx는 바뀔 수 있는 두 자리의

16진수를 나타내는 데 사용된다. %x는 바뀔 수 있는 한 자리의 이진수를 나타내는 데 사용된다.

바이트의 최상위 비트(MSB, Most significant bit)는 7번 비트이며, 최하위 비트(LSB, Least

significant bit)는 0번 비트로 부른다.


태그는 이 문서의 전체 태그를 지칭하며, 프레임은 태그의 정보를 갖는 블럭이다. 태그는 헤더, 프레임

및 옵션 패딩으로 구성되어 있다. 필드는 하나의 값, 문자열과 같은 정보의 한 부분이다. 숫자 문자열은

문자 "0123456789"로 구성된 문자열이다. "반드시 ~이어야 한다", "반드시 ~이 아니어야 한다.",

"필수", "가능", "가능하지 않을 수 있다.", "권장", "~일 수 있다.", "선택 사항"과 같은 표현은

RFC 2119 [KEYWORDS]에 기술된 바와 같이 해석될 수 있다.


(주: 영어 표현에서는 RFC 2119의 키워드를 사용할 수 있으나 번역하는 경우 위의 키워드를 정의하여 번역에 사용하기에는 문맥 또는 어감에 따라 표현이 달라질 수 있음)



3. ID3v2 개요


ID3v2는 해당 오디오 파일 내에 오디오에 관한 메타 데이터를 저장할 수 있게하는 범용의 오디오 태그

포맷이다. 이 문서에서 설명하는 ID3 태그는 주로 MPEG-1/2/ 레이어 I, MPEG-1/2/ 레이어 II,

MPEG-1/2 레이어 III 그리고 MPEG-2.5로 인코딩된 파일을 대상으로 하지만, 다른 타입으로 인코딩된

오디오나 오디오 메타 데이터를 위한 독립형 포맷으로 작업할 수 있다.


ID3v2는 발생할 수 있는 새로운 메타 정보의 요구를 충족하기 위해 유연하고 확장 가능하도록 설계되었다.   ID3v2는 프레임으로 칭하는 다양한 정보 블럭을 위한 컨테이너를 구성하며, 오디오 파일을 읽는

소프트웨어에서 ID3v2에 대해 고려하지 않을 수 있도록 한다. 모든 프레임의 시작 부분은 소프트웨어에

알려지지 않은 프레임 및 플래그 필드를 스킵할 수 있도록 하는 미리 정의된 식별자와 크기를 기술한다.  

플래그는 인코딩의 상세 정보와, 소프트웨어에서 알 수 없는 태그를 프레임에 유지될 수 있도록 하고,

파일이 변경되었는지를 설명한다.


ID3v2의 비트 순서(비트오더, bit order)는 MSB(최상위 비트)가 첫 번째이다. 멀티 바이트로 구성된

숫자의 바이트 순서(바이트오더) 에서의 최상위바이트는 첫 번째이다(예, $12345678은 $12 34 56 78로

인코딩된다). 또한 빅 엔디안(big endian)으로 알려진 네트워크 바이트 순서를 사용한다.


전체 태그 구조


     +-----------------------------+

     |       헤더 (10 바이트)      |

     +-----------------------------+

     |       확장된 헤더       |

     | (가변 길이, 선택 사항) |

     +-----------------------------+

     |   프레임 (가변 길이)  |

     +-----------------------------+

     |           패딩           |

     | (가변 길이, 선택 사항) |

     +-----------------------------+

     | 푸터 (10 바이트, 선택사항) |

     +-----------------------------+


일반적으로 패딩과 푸터는 상호 배타적이다. 상세한 내용은 3.3.절, 3.4.절, 5.절에서 확인할 수 있다.



3.1. ID3v2 헤더


ID3v2 태그의 첫 번째 부분은 10 바이트의 태그 헤더이다. 다음과 같이 배치된다.


ID3v2/파일 식별자 "ID3"

ID3v2 버전 $04 00

ID3v2 플래그 %abcd0000

ID3v2 크기 4 * %0xxxxxx


태그의 첫 3 개 바이트는 항상 "ID3"이며, 곧이어 따라오는 두 개의 버전을 의미하는 바이트는 ID3v2 태그의

버전을 나타낸다. ID3v2 버전의 첫 번째 바이트는 메이저 버전이고, 두 번째 바이트는 리비전 번호이다.

위 경우는 ID3v2.4.0을 의미한다. 모든 리비전은 하위 호환성을 가지지만, 메이저 버전은 하위 호환성을

갖지 않는다. 만약 ID3v2.4.0 이하를 지원하는 소프트웨어가 5 이상을 만나면 태그 전체를 무시하면 된다.

버전 또는 리비전은 절대 $FF가 될 수 없다.

버전 뒤의 ID3v2 플래그 필드는 현재 네 개의 플래그 비트만 사용된다. a - 비동기(Unsynchronisation) 'ID3v2 플래그'의 7번 비트는 모든 프레임에 비동기를 사용할 지의 여부를 나타낸다. (상세한 내용은 6.1.

절 참조) 플래그 비트가 셋인 경우(1인 경우) 사용함을 나타낸다. b - 확장된 헤더(Extended header) 두 번째 비트(6번 비트)는 태그 헤더가 확장되었는지 여부를 나타낸다. 확장된 헤더는 3.2.절에서 설명한다. 플래그 비트가 셋인 경우 확장된 헤더를 사용하는 것을 나타낸다. c - 실험용 지시자(Experimental indicator) 세 번째 비트(5번 비트)는 '실험용 지시자'로 사용된다. 실험용 태그를 사용하는 경우 이 플래그 값이

셋(set, 1) 되어야 한다. d - 푸터 여부(Footer present) 4번 비트는 태그의 끝을 의미하는 푸터를 나타낸다 (3.4. 절). 값이 셋 된 경우 푸터가 있음을 의미한다.

위의 4개 외의 모든 플래그는 반드시 %abcd0000 과 같이 0이어야 한다. 정의되지 않은 비트 중의 하나가 셋인

경우 플래그의 기능을 알지 못하는 파서는 태그를 읽지 못할 수 있다. ID3v2 태그 크기는 28비트의 유효한 크기를 가진 32비트의 Synchsafe 정수(6.2. 절)로 저장된다. (256MB

까지 표현됨) ID3v2 태그의 크기는 확장된 헤더, 패딩 그리고 비동기(Unsynchronisation) 뒤의 프레임의 바이트 길이의

합이다. 푸터를 사용한다면 ('전체 크기' - 20)바이트와 같고, 사용하지 않는다면 ('전체 크기' - 10) 바이트

와 같다. ID3v2 태그는 아래의 패턴으로 찾을 수 있다. $49 44 33 yy yy xx zz zz zz zz yy 부분이 $FF 보다 작을 때, xx는 '플래그' 바이트이고, zz는 $80보다 작다. 3.2. 확장된 헤더 확장된 헤더는 태그 구조의 자세한 이해를 제공할 수 있는 정보를 포함하고 있지만, 확장된 헤더는 선택적인

부분이므로 태그 정보를 정확하게 파싱하는 것은 중요하지 않다. 확장된 헤더 크기 4 * %0xxxxxxx 플래그 바이트 수 $01 확장된 플래그 $xx '확장된 헤더 크기'는 32비트의 Synchsafe 정수로 표현된 전체 확장된 헤더의 크기이다. 따라서 확장된 헤더의 크기는 절대 6 바이트보다 작은 크기를 갖지 않는다. '플래그 바이트 수'에 의해 크기가 정해진 확장된 플래그 필드는 다음과 같이 정의된다. %0bcd0000 Each flag that is set in the extended header has data attached, which comes in the order in which the flags are encountered (i.e. the data for flag 'b' comes before the data for flag 'c'). Unset flags cannot have any attached data. All unknown flags MUST be unset and their corresponding data removed when a tag is modified. Every set flag's data starts with a length byte, which contains a value between 0 and 128 ($00 - $7f), followed by data that has the field length indicated by the length byte. If a flag has no attached data, the value $00 is used as length byte. b - Tag is an update If this flag is set, the present tag is an update of a tag found earlier in the present file or stream. If frames defined as unique are found in the present tag, they are to override any corresponding ones found in the earlier tag. This flag has no corresponding data. Flag data length $00 c - CRC data present If this flag is set, a CRC-32 [ISO-3309] data is included in the extended header. The CRC is calculated on all the data between the header and footer as indicated by the header's tag length field, minus the extended header. Note that this includes the padding (if there is any), but excludes the footer. The CRC-32 is stored as an 35 bit synchsafe integer, leaving the upper four bits always zeroed. Flag data length $05 Total frame CRC 5 * %0xxxxxxx d - Tag restrictions For some applications it might be desired to restrict a tag in more ways than imposed by the ID3v2 specification. Note that the presence of these restrictions does not affect how the tag is decoded, merely how it was restricted before encoding. If this flag is set the tag is restricted as follows: Flag data length $01 Restrictions %ppqrrstt p - Tag size restrictions 00 No more than 128 frames and 1 MB total tag size. 01 No more than 64 frames and 128 KB total tag size. 10 No more than 32 frames and 40 KB total tag size. 11 No more than 32 frames and 4 KB total tag size. q - Text encoding restrictions 0 No restrictions 1 Strings are only encoded with ISO-8859-1 [ISO-8859-1] or UTF-8 [UTF-8]. r - Text fields size restrictions 00 No restrictions 01 No string is longer than 1024 characters. 10 No string is longer than 128 characters. 11 No string is longer than 30 characters. Note that nothing is said about how many bytes is used to represent those characters, since it is encoding dependent. If a text frame consists of more than one string, the sum of the strungs is restricted as stated. s - Image encoding restrictions 0 No restrictions 1 Images are encoded only with PNG [PNG] or JPEG [JFIF]. t - Image size restrictions 00 No restrictions 01 All images are 256x256 pixels or smaller. 10 All images are 64x64 pixels or smaller. 11 All images are exactly 64x64 pixels, unless required otherwise. 3.3. Padding It is OPTIONAL to include padding after the final frame (at the end of the ID3 tag), making the size of all the frames together smaller than the size given in the tag header. A possible purpose of this padding is to allow for adding a few additional frames or enlarge existing frames within the tag without having to rewrite the entire file. The value of the padding bytes must be $00. A tag MUST NOT have any padding between the frames or between the tag header and the frames. Furthermore it MUST NOT have any padding when a tag footer is added to the tag. 3.4. ID3v2 footer To speed up the process of locating an ID3v2 tag when searching from the end of a file, a footer can be added to the tag. It is REQUIRED to add a footer to an appended tag, i.e. a tag located after all audio data. The footer is a copy of the header, but with a different identifier. ID3v2 identifier "3DI" ID3v2 version $04 00 ID3v2 flags %abcd0000 ID3v2 size 4 * %0xxxxxxx 4. ID3v2 frame overview All ID3v2 frames consists of one frame header followed by one or more fields containing the actual information. The header is always 10 bytes and laid out as follows: Frame ID $xx xx xx xx (four characters) Size 4 * %0xxxxxxx Flags $xx xx The frame ID is made out of the characters capital A-Z and 0-9. Identifiers beginning with "X", "Y" and "Z" are for experimental frames and free for everyone to use, without the need to set the experimental bit in the tag header. Bear in mind that someone else might have used the same identifier as you. All other identifiers are either used or reserved for future use. The frame ID is followed by a size descriptor containing the size of the data in the final frame, after encryption, compression and unsynchronisation. The size is excluding the frame header ('total frame size' - 10 bytes) and stored as a 32 bit synchsafe integer. In the frame header the size descriptor is followed by two flag bytes. These flags are described in section 4.1. There is no fixed order of the frames' appearance in the tag, although it is desired that the frames are arranged in order of significance concerning the recognition of the file. An example of such order: UFID, TIT2, MCDI, TRCK ... A tag MUST contain at least one frame. A frame must be at least 1 byte big, excluding the header. If nothing else is said, strings, including numeric strings and URLs [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the range $20 - $FF. Such strings are represented in frame descriptions as <text string>, or <full text string> if newlines are allowed. If nothing else is said newline character is forbidden. In ISO-8859-1 a newline is represented, when allowed, with $0A only. Frames that allow different types of text encoding contains a text encoding description byte. Possible encodings: $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All strings in the same frame SHALL have the same byteorder. Terminated with $00 00. $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. Terminated with $00 00. $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. Strings dependent on encoding are represented in frame descriptions as <text string according to encoding>, or <full text string according to encoding> if newlines are allowed. Any empty strings of type $01 which are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00). The timestamp fields are based on a subset of ISO 8601. When being as precise as possible the format of a time string is yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of 24), ":", minutes, ":", seconds), but the precision may be reduced by removing as many time indicators as wanted. Hence valid timestamps are yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use the slash character as described in 8601, and for multiple non- contiguous dates, use multiple strings, if allowed by the frame definition. The three byte language field, present in several frames, is used to describe the language of the frame's content, according to ISO-639-2 [ISO-639-2]. The language should be represented in lower case. If the language is not known the string "XXX" should be used. All URLs [URL] MAY be relative, e.g. "picture.png", "../doc.txt". If a frame is longer than it should be, e.g. having more fields than specified in this document, that indicates that additions to the frame have been made in a later version of the ID3v2 standard. This is reflected by the revision number in the header of the tag. 4.1. Frame header flags In the frame header the size descriptor is followed by two flag bytes. All unused flags MUST be cleared. The first byte is for 'status messages' and the second byte is a format description. If an unknown flag is set in the first byte the frame MUST NOT be changed without that bit cleared. If an unknown flag is set in the second byte the frame is likely to not be readable. Some flags in the second byte indicates that extra information is added to the header. These fields of extra information is ordered as the flags that indicates them. The flags field is defined as follows (l and o left out because ther resemblence to one and zero): %0abc0000 %0h00kmnp Some frame format flags indicate that additional information fields are added to the frame. This information is added after the frame header and before the frame data in the same order as the flags that indicates them. I.e. the four bytes of decompressed size will precede the encryption method byte. These additions affects the 'frame size' field, but are not subject to encryption or compression. The default status flags setting for a frame is, unless stated otherwise, 'preserved if tag is altered' and 'preserved if file is altered', i.e. %00000000. 4.1.1. Frame status flags a - Tag alter preservation This flag tells the tag parser what to do with this frame if it is unknown and the tag is altered in any way. This applies to all kinds of alterations, including adding more padding and reordering the frames. 0 Frame should be preserved. 1 Frame should be discarded. b - File alter preservation This flag tells the tag parser what to do with this frame if it is unknown and the file, excluding the tag, is altered. This does not apply when the audio is completely replaced with other audio data. 0 Frame should be preserved. 1 Frame should be discarded. c - Read only This flag, if set, tells the software that the contents of this frame are intended to be read only. Changing the contents might break something, e.g. a signature. If the contents are changed, without knowledge of why the frame was flagged read only and without taking the proper means to compensate, e.g. recalculating the signature, the bit MUST be cleared. 4.1.2. Frame format flags h - Grouping identity This flag indicates whether or not this frame belongs in a group with other frames. If set, a group identifier byte is added to the frame. Every frame with the same group identifier belongs to the same group. 0 Frame does not contain group information 1 Frame contains group information k - Compression This flag indicates whether or not the frame is compressed. A 'Data Length Indicator' byte MUST be included in the frame. 0 Frame is not compressed. 1 Frame is compressed using zlib [zlib] deflate method. If set, this requires the 'Data Length Indicator' bit to be set as well. m - Encryption This flag indicates whether or not the frame is encrypted. If set, one byte indicating with which method it was encrypted will be added to the frame. See description of the ENCR frame for more information about encryption method registration. Encryption should be done after compression. Whether or not setting this flag requires the presence of a 'Data Length Indicator' depends on the specific algorithm used. 0 Frame is not encrypted. 1 Frame is encrypted. n - Unsynchronisation This flag indicates whether or not unsynchronisation was applied to this frame. See section 6 for details on unsynchronisation. If this flag is set all data from the end of this header to the end of this frame has been unsynchronised. Although desirable, the presence of a 'Data Length Indicator' is not made mandatory by unsynchronisation. 0 Frame has not been unsynchronised. 1 Frame has been unsyrchronised. p - Data length indicator This flag indicates that a data length indicator has been added to the frame. The data length indicator is the value one would write as the 'Frame length' if all of the frame format flags were zeroed, represented as a 32 bit synchsafe integer. 0 There is no Data Length Indicator. 1 A data length Indicator has been added to the frame. 5. Tag location The default location of an ID3v2 tag is prepended to the audio so that players can benefit from the information when the data is streamed. It is however possible to append the tag, or make a prepend/append combination. When deciding upon where an unembedded tag should be located, the following order of preference SHOULD be considered. 1. Prepend the tag. 2. Prepend a tag with all vital information and add a second tag at the end of the file, before tags from other tagging systems. The first tag is required to have a SEEK frame. 3. Add a tag at the end of the file, before tags from other tagging systems. In case 2 and 3 the tag can simply be appended if no other known tags are present. The suggested method to find ID3v2 tags are: 1. Look for a prepended tag using the pattern found in section 3.1. 2. If a SEEK frame was found, use its values to guide further searching. 3. Look for a tag footer, scanning from the back of the file. For every new tag that is found, the old tag should be discarded unless the update flag in the extended header (section 3.2) is set. 6. Unsynchronisation The only purpose of unsynchronisation is to make the ID3v2 tag as compatible as possible with existing software and hardware. There is no use in 'unsynchronising' tags if the file is only to be processed only by ID3v2 aware software and hardware. Unsynchronisation is only useful with tags in MPEG 1/2 layer I, II and III, MPEG 2.5 and AAC files. 6.1. The unsynchronisation scheme Whenever a false synchronisation is found within the tag, one zeroed byte is inserted after the first false synchronisation byte. The format of synchronisations that should be altered by ID3 encoders is as follows: %11111111 111xxxxx and should be replaced with: %11111111 00000000 111xxxxx This has the side effect that all $FF 00 combinations have to be altered, so they will not be affected by the decoding process. Therefore all the $FF 00 combinations have to be replaced with the $FF 00 00 combination during the unsynchronisation. To indicate usage of the unsynchronisation, the unsynchronisation flag in the frame header should be set. This bit MUST be set if the frame was altered by the unsynchronisation and SHOULD NOT be set if unaltered. If all frames in the tag are unsynchronised the unsynchronisation flag in the tag header SHOULD be set. It MUST NOT be set if the tag has a frame which is not unsynchronised. Assume the first byte of the audio to be $FF. The special case when the last byte of the last frame is $FF and no padding nor footer is used will then introduce a false synchronisation. This can be solved by adding a footer, adding padding or unsynchronising the frame and add $00 to the end of the frame data, thus adding more byte to the frame size than a normal unsynchronisation would. Although not preferred, it is allowed to apply the last method on all frames ending with $FF. It is preferred that the tag is either completely unsynchronised or not unsynchronised at all. A completely unsynchronised tag has no false synchonisations in it, as defined above, and does not end with $FF. A completely non-unsynchronised tag contains no unsynchronised frames, and thus the unsynchronisation flag in the header is cleared. Do bear in mind, that if compression or encryption is used, the unsynchronisation scheme MUST be applied afterwards. When decoding an unsynchronised frame, the unsynchronisation scheme MUST be reversed first, encryption and decompression afterwards. 6.2. Synchsafe integers In some parts of the tag it is inconvenient to use the unsychronisation scheme because the size of unsynchronised data is not known in advance, which is particularly problematic with size descriptors. The solution in ID3v2 is to use synchsafe integers, in which there can never be any false synchs. Synchsafe integers are integers that keep its highest bit (bit 7) zeroed, making seven bits out of eight available. Thus a 32 bit synchsafe integer can store 28 bits of information. Example: 255 (%11111111) encoded as a 16 bit synchsafe integer is 383 (%00000001 01111111). 7. Copyright Copyright (C) Martin Nilsson 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that a reference to this document is included on all such copies and derivative works. However, this document itself may not be modified in any way and reissued as the original document. The limited permissions granted above are perpetual and will not be revoked. This document and the information contained herein is provided on an 'AS IS' basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. References [ID3v2] Martin Nilsson, 'ID3v2 informal standard'. <url:http://www.id3.org/id3v2.3.0.txt> [ISO-639-2] ISO/FDIS 639-2. 'Codes for the representation of names of languages, Part 2: Alpha-3 code.' Technical committee / subcommittee: TC 37 / SC 2 [ISO-3309] ISO 3309 'Information Processing Systems--Data Communication High-Level Data Link Control Procedure--Frame Structure', IS 3309, October 1984, 3rd Edition. [ISO-8859-1] ISO/IEC DIS 8859-1. '8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1.' Technical committee / subcommittee: JTC 1 / SC 2 [JFIF] 'JPEG File Interchange Format, version 1.02' <url:http://www.w3.org/Graphics/JPEG/jfif.txt> [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate Requirement Levels', RFC 2119, March 1997. <url:ftp://ftp.isi.edu/in-notes/rfc2119.txt> [MPEG] ISO/IEC 11172-3:1993. 'Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s, Part 3: Audio.' Technical committee / subcommittee: JTC 1 / SC 29 and ISO/IEC 13818-3:1995 'Generic coding of moving pictures and associated audio information, Part 3: Audio.' Technical committee / subcommittee: JTC 1 / SC 29 and ISO/IEC DIS 13818-3 'Generic coding of moving pictures and associated audio information, Part 3: Audio (Revision of ISO/IEC 13818-3:1995)' [PNG] 'Portable Network Graphics, version 1.0' <url:http://www.w3.org/TR/REC-png-multi.html> [UNICODE] The Unicode Consortium, 'The Unicode Standard Version 3.0', ISBN 0-201-61633-5. <url:http://www.unicode.org/unicode/standard/versions/Unicode3.0.htm> [URL] T. Berners-Lee, L. Masinter & M. McCahill, 'Uniform Resource Locators (URL)', RFC 1738, December 1994. <url:ftp://ftp.isi.edu/in-notes/rfc1738.txt> [UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646', RFC 2279, January 1998. <url:ftp://ftp.isi.edu/in-notes/rfc2279.txt> [UTF-16] F. Yergeau, 'UTF-16, an encoding of ISO 10646', RFC 2781, February 2000. <url:ftp://ftp.isi.edu/in-notes/rfc2781.txt> [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, 'ZLIB Compressed Data Format Specification version 3.3', RFC 1950, May 1996. <url:ftp://ftp.isi.edu/in-notes/rfc1950.txt> 9. Author's Address Written by Martin Nilsson Rydsv�gen 246 C. 30 SE-584 34 Link�ping Sweden Email: nilsson at id3.org




'싹이 움트다 > MP3Tagger' 카테고리의 다른 글

ID3v24 Structure 번역 - 작성 중  (0) 2015.06.05
MP3Tagger 프로젝트  (0) 2015.06.05

MP3Tagger Project

ID3v24 태그 분석 및 태깅을 위한 자바로 작성된 라이브러리


GitHub https://github.com/nnoco/mp3tagger

'싹이 움트다 > MP3Tagger' 카테고리의 다른 글

ID3v24 Structure 번역 - 작성 중  (0) 2015.06.05
MP3Tagger 프로젝트  (0) 2015.06.05

자바 애너테이션 기반의 HTTP 클라이언트 라이브러리.


안드로이드 관련 프로젝트를 진행하면서 안드로이드 애플리케이션이나 SDK에서 안드로이드 SDK를 제외하고 가장 많이 공통적으로 쓰였던 부분은 HTTP Client가 아니었나 싶다.

HTTP 통신은 비교적 손이 많이 가는 편이고, 핵심 코드에 비해 주변코드가 많이 작성된다. DB를 프로그래밍 할 때와 비슷하게 주변코드는 공통적으로 처리되는 부분이 많고, 핵심 코드에 집중해서 HTTP 클라이언트를 작성하고 싶다는 생각을 항상 하고 있어서, 이를 애너테이션 기반으로 만들어보면 어떨까 하는 생각에 구상하게 되었다.


프로젝트 네이밍은 자바의 애너테이션 기호인 @을 우리말로 읽을 때 '골뱅이'라고 많이 읽는 것에서 '골뱅'으로 하고, 영어로 쓰면 'gol bang'이므로, 의미는 없지만 '#!' 을 해쉬뱅(Hash bang)으로 읽으니 'Gol!' 으로 축약하였다. (하이고 의미없다, 그치만 개인적으로는 마음에 든다 하하;)


Gol!의 목표는 HTTP 통신을 간편하게 핵심코드만으로 처리할 수 있도록 하는 것이다. 즉 핵심 로직에만 집중할 수 있도록 하여 생산성을 향상시키는데 있다. 고려해야하는 것들은 HTTP 프로토콜, 비동기 요청의 처리 및 비동기 요청 시의 콜백 처리 등이다.

Gol!의 기본적인 개념은 메서드와 HTTP 요청을 1:1로 매핑하는 것이고, 메서드 호출이 곧 HTTP 요청이며, 메서드 파라미터는 쿼리스트링이나 HTTP 메시지 본문이 되며, 리턴 타입이 응답 메시지이다. (비동기의 경우에는 리턴에 대한 처리를 콜백에서 하도록 해야한다.) 이 외에 요청에 관한 데이터(헤더, 요청 URL, 메서드 등)은 애너테이션을 통해 메타 데이터로 제공한다. 애너테이션의 경우 리터럴 상수만 인자로 받을 수 있으므로, 동적으로 요청에 대한 정보를 변경할 수 없다. 따라서 메서드 파라미터 애너테이션을 통해 요청에 대한 정보를 동적으로 제공할 수 있도록 설계하여야 한다.

개별 요청에 대한 정보는 메서드 및 메서드 애너테이션으로 제공하고, 서버에 대한 공통적인 설정은 인터페이스에서 할 수 있도록한다.


기본적으로는 위와 같은 모습으로 메서드가 작성이 되고, 자바의 동적 프록시를 통해 HTTP 요청을 공통으로 처리할 것이므로, 위 요청 메서드는 인터페이스 내에 작성하도록 한다. 따라서 Gol! 사용시에는 요청에 대한 데이터만 인터페이스로 제공하고, 요청에 대한 세부적인 로우레벨의 코드 구현은 최대한 배제할 수 있도록 한다.


예상되는 가장 큰 이슈는 메모리와 속도 이슈가 아닐까싶다. 애너테이션은 리플렉션을 통해 실제 값을 얻을 수 있으므로 여기에서 한번 속도 및 메모리 이슈가 발생하고, 사용자의 구현을 단순하게 하게 위해서 동적 프록시를 적용하게 되므로 또 한번 속도 및 메모리 이슈가 발생한다. 또한 사용자 구현은 단순화되지만, 라이브러리 자체의 복잡도가 높아져서 설계를 잘해야할 듯 하다.. ㅜㅜ


조금씩이라도 부지런하게 작성하고, 개선해봐야겠다. :)

'싹이 움트다 > GolBang(@!)' 카테고리의 다른 글

GolBang(gol!) - Annotation-based HTTP Client for Java  (0) 2015.02.23
공개될 API 정의



ISSUES

사용자 인증을 어떤 방식으로 할 것인지?



SDK 구현에서의 마스터 스토리 리스트 작성하기

'싹이 움트다' 카테고리의 다른 글

[Salina] 안드로이드 SDK를 만들기 위한 준비  (0) 2013.02.21
Forget Me Not project

'싹이 움트다 > Forget-me-not' 카테고리의 다른 글

Forget-Me-Not  (0) 2011.08.17

Fields 7 6 5 4 3 2 1 0
Header MB ME CF SR IL Type Name Format
1 1 0 1 0 0x01
Type length 0 0 0 1 0 0 0 1
Payload length ?
Type 16 0 1 1 1 0 0 1 1
...
Type 0 0 1 0 0 0 1 0 0
Payload n
...
Payload 0

먼저 헤더 필드의 flag를 지정하면
- 태그에는 1개의 메시지, 1개의 레코드를 사용하므로 MB, ME flag 는 1이다.
- Chunk 되지 않았으므로 0의 값
- 짧은 타입의(Short Record) 레코드 이므로 SR = 1
- ID는 사용하지 않으므로 IL = 0
- TNF(Type Name Format) : NFC Forum well-known type = 0x01

NFC 포럼에서 사용하는 규격의 타입이 아니므로 외부타입으로 만들어줘야 한다.
NDEF 상세에 따라 타입 이름을 작성하면  dns-part:name-part 형식에 맞춰서

Type Name : smartmenu.com:RID

US-ASCII 캐릭터 셋으로하여 byte 배열을 얻으면 문자열 길이대로 17개의 바이트 배열이 나오고 결과는 아래의 값이다.

TYPE LENGTH : 0x11, 17(10)
TYPE : 0x73  0x6d  0x61  0x72  0x74  0x6d  0x65  0x6e  0x75  0x2e  0x63  0x6f  0x6d  0x3a  0x52  0x49  0x44

PAYLOAD 의 문자 인코딩은 UTF-8을 사용하고 PAYLOAD에 들어갈 내용은
식당을 식별할 수 있는 사업자 번호와 테이블을 식별할 수 있는 테이블 번호가 연속으로 들어간다.
이에따라 PAYLOAD의 LENGTH가 결정되고, PAYLOAD에 byte 값을 가지게 된다.




- 최종 작성일 : 11.08.17

[참고 사항(제약)]
1. The External Type MUST be formed by taking the domian name of the issuing organization, adding a colon, and then adding a type name, An External Type MUST include a colon and a non-zero length type name [NFC Record Type Definition 2.3]

2. Type Name ABNF format - 아래의 규칙을 따라서  Type Name 작성
external-type = dns-part “:” name-part
dns-part = 1*DNS-char
name-part = 1*WKT-char
WKT-char = upper / lower / number / other
DNS-char = upper / lower / number / “.” / “-”
upper = “A” / “B” / “C” / “D” / “E” / “F” / “G” / “H” / “I” / “J” / “K” / “L” / “M” / “N” / “O” / “P” / “Q” / “R” / “S” / “T” / “U” / “V” / “W” / “X” / “Y” / “Z”
lower = “a” / “b” / “c” / “d” / “e” / “f” / “g” / “h” / “i” / “j” / “k” / “l” / “m” / “n” / “o” / “p” / “q” / “r” / “s” / “t” / “u” / “v” / “w” / “x” / “y” / “z”
number = “0” / “1” / “2” / “3” / “4” / “5” / “6” / “7” / “8” / “9”
other = “(“ / “)” / “+” / “,” / “-” / “:” / “=“ / “@” / “;” / “$”
[RFC 2234]

'싹이 움트다 > Dianthus' 카테고리의 다른 글

Restaurant Identifier Record Format  (0) 2011.08.17
Dianthus  (0) 2011.08.17
Smart Menu project

'싹이 움트다 > Dianthus' 카테고리의 다른 글

Restaurant Identifier Record Format  (0) 2011.08.17
Dianthus  (0) 2011.08.17

+ Recent posts