퀴즈 문제 미디어 태깅 규격서 (Specification)
1. 기본 원칙 및 목적
이 규격은 퀴즈 문제 지문 내부에 이미지나 동영상을 삽입하기 위한 규칙을 정의합니다.
글로벌 호환성 유지: 태그 이름은 *영문(image, video)*을 사용해야 합니다.
파싱 안정성 극대화: 미디어 태그 인식 조건을 극도로 엄격하게 제한하여, 일반 텍스트와의 충돌 가능성을 완전히 제거합니다.
간결함: 태그 내부에 파일 경로 외의 어떠한 복잡한 *속성(Attribute)*도 사용하지 않습니다.
2. 미디어 태그 형식
미디어 태그는 항상 [< 로 시작하고 >] 로 끝나며, 내부에 순수한 XML 스타일 태그를 포함합니다.
이미지 삽입 형식: [<image>path/file.jpg</image>]
동영상 삽입 형식: [<video>path/file.mp4</video>]
3. 미디어 태그 인식 필수 조건 (엄격한 경계)
단 하나의 조건을 충족할 때만 미디어 태그로 인식하고 처리됩니다.
미디어 태그는 해당 지문(Question Text) 문자열의 맨 앞, 첫 글자에만 위치해야 합니다.
즉, [ 문자가 지문 문자열의 첫 번째 글자이어야 하며, 두 번째 글자는 반드시 < 이어야 합니다.
태그 앞에 공백, 탭, 줄바꿈 등 어떠한 문자도 존재해서는 안 됩니다.
4. 콘텐츠 제작자 가이드라인
문제 출제자는 다음 지침을 반드시 준수해야 합니다.
미디어 위치 고정: 이미지나 동영상을 넣으려면, 해당 지문 문장을 반드시 미디어 태그로 시작해야 합니다. 지문 중간이나 끝에 태그를 삽입할 수 없습니다.
태그 작성: 경로를 포함하여 정해진 형식대로 정확하게 입력해야 합니다.
충돌 방지: 문제 지문 내부에 [, <, >, ] 문자를 포함하는 텍스트는 시스템 충돌을 유발할 수 있습니다. 이러한 기호 사용은 절대 피해야 하며, 불가피한 경우라면 다른 대체 기호를 사용해야 합니다.
5. 개발자 (파싱 로직) 가이드
개발 로직은 미디어 태그 인식 조건을 최대한 활용하여 효율적으로 구현되어야 합니다.
시작 위치 검사: 입력된 지문 문자열이 *[*로 시작하고, 두 번째 글자가 < 인지 확인하는 조건을 통해 미디어 태그 존재 여부를 판단합니다.
미디어 추출 및 제거: 패턴이 발견되면, 정규식 등을 사용하여 [<type>path</type>] 구조 전체를 추출하여 별도의 미디어 정보로 저장합니다. 원본 지문 텍스트에서는 이 태그 부분을 즉시 제거해야 합니다.
텍스트 및 미디어 출력: 태그가 제거된 나머지 텍스트를 최종 지문으로 확정하고, 추출된 미디어 정보를 텍스트와 분리된 별도의 UI 컴포넌트(예: 지문 영역 상단/하단)에 렌더링합니다.
이 엄격한 규칙을 통해 콘텐츠 제작의 자유도는 다소 제한되지만, 데이터 처리의 안정성과 글로벌 확장성은 최고 수준으로 유지됩니다.
미디어 태그 인식 사례 20가지
아래 사례에서 ✅ 미디어 태그는 앱에서 미디어를 로드하고 나머지 텍스트만 표시하는 경우이며, ❌ 일반 텍스트는 태그 자체가 화면에 그대로 표시되는 경우입니다.
A. ✅ 미디어 태그로 인식되는 경우 (특수 환경)
이 경우, 태그 전체가 제거되고 미디어가 출력됩니다.
[<image>q1_map.jpg</image>]이 지도에 대한 설명으로 옳은 것은?
[<video>intro.mp4</video>]영상을 보고 물음에 답하시오.
[<image>assets/photo.jpg</image>]이 사진은 언제 촬영된 것인가요?
[<video>lecture.mp4</video>] (태그만 단독으로 있는 경우도 인식)
[<image>url/external.png</image>]다음 중 이 이미지에 대한 설명은?
[<video>clip.mp4</video>] (주목! 해당 영상은 5초간 재생됩니다.)
[<image>1.png</image>]정답은 2번입니다.
[<video>v1.mp4</video>]
[<image>path/sub/file.gif</image>]위 그림에 해당하는 내용은 무엇인가요?
[<video>long_name_video_001.mp4</video>]이제 문제를 풀어보세요.
B. ❌ 일반 텍스트로 인식되는 경우 (태그가 아님)
이 경우, 태그 자체가 제거되지 않고 화면에 그대로 출력됩니다.
이 문제의 [<image>q1_map.jpg</image>] 핵심은 무엇인가?
이유: [ 앞에 공백이 있어 지문의 맨 처음이 아닙니다.
[참고]<image>q1_map.jpg</image> 이 사진을 보세요.
이유: 첫 글자는 [ 이지만, 두 번째 글자가 < 가 아닌 참입니다.
(<image>q1_map.jpg</image>) 이 문제에 대한 설명입니다.
이유: 첫 글자가 [ 가 아닌 공백입니다.
[1]번 보기에 대한 설명입니다.
이유: [ 뒤에 < 가 아닌 숫자가 왔습니다.
[<image>경로</image> ] (태그 닫는 부분에 공백 삽입)
이유: 파싱 패턴이 >] 으로 끝나지 않았습니다. (문자열 불일치)
<image>q1_map.jpg</image>
이유: 첫 글자가 [ 가 아닙니다.
지문 내 [< How are you? >] 라는 문구가 있습니다.
이유: [ 앞에 공백이 있습니다.
[문제] 다음은 [힌트]입니다.
이유: 두 번째 글자가 < 가 아닌 문자입니다.
[ image>path.jpg</image>] (태그 시작 부분에 공백 삽입)
이유: [ 뒤에 바로 < 가 오지 않고 공백이 왔습니다.
이 질문은 [<image>path.jpg>] 에 대해 묻습니다.
이유: [ 앞에 공백이 있어 지문의 맨 처음이 아닙니다.
이 사례들을 통해 [와 <가 공백 없이 지문의 맨 앞에 붙어야만 특수 환경으로 인식된다는 규칙이 얼마나 엄격하고 명확하게 작동하는지 이해하시는 데 도움이 되셨기를 바랍니다.
엄격한 미디어 태깅 규칙의 구조적 강점
1. DB 테이블 세분화 문제 해결 (유연성)
이 방식은 데이터 모델을 단순하게 유지할 수 있는 가장 큰 강점을 제공합니다.
테이블 구조 단순화: 미디어를 위한 별도의 Media_Table이나 Question_Image_Table을 만들 필요가 없습니다. 퀴즈 데이터베이스 테이블(Quiz_Question 테이블)은 오로지 question_id, text_content, answer 등 핵심 필드만 가지면 됩니다.
데이터 모델 변경 최소화: 미디어 정보(경로, 유형)가 문제 지문 텍스트 안에 포함되어 있기 때문에, 새로운 미디어가 추가되더라도 DB 테이블 스키마를 변경할 필요가 전혀 없습니다. 개발 로직(파싱 정규식)만 업데이트하면 됩니다.
2. 새로운 구분 미디어 추가의 용이성 (확장성)
새로운 유형의 미디어(예: 3D 모델, AR 마커, 오디오 파일)가 생겨도 대응이 매우 빠릅니다.
쉬운 확장: 새로운 유형의 미디어에 대해 **<audio>**나 **<ar>**와 같은 새로운 태그만 정의하면 됩니다.
예: [<audio>file.mp3</audio>]
하위 호환성 유지: 기존의 <image>와 <video> 태그는 전혀 건드리지 않습니다. 개발자는 파싱 로직에 새로운 태그 패턴만 추가하면 되며, 기존의 문제 데이터는 완벽하게 하위 호환성을 유지합니다.
3. 일반인의 구조적 접근성 및 제작 용이성
이 방식은 코딩 지식이 없는 콘텐츠 제작자에게 가장 친화적입니다.
직관적인 이해: 제작자는 <image>, <video>라는 직관적인 영문 단어만 기억하고, 정해진 앞뒤 패턴([<와 >]) 안에 넣어주기만 하면 됩니다. 복잡한 XML 문법 구조나 속성을 이해할 필요가 없습니다.
텍스트 파일 작업: 문제 데이터를 엑셀이나 단순 텍스트 편집기에서 작업하고, 미디어 태그만 삽입해도 데이터 파일이 깔끔하게 유지됩니다. 이는 CSV 또는 텍스트 기반 데이터 관리를 선호하는 콘텐츠 제작 환경에 매우 효율적입니다.
4. 파싱 로직의 명확성 (개발 효율)
경계 조건 명확: 지문의 맨 앞에 [<와 <가 와야 한다는 엄격한 규칙 덕분에, 개발자는 문제 텍스트를 파싱할 때 무작정 모든 꺾쇠괄호(<>)를 검사할 필요가 없습니다. 오직 문자열의 시작만 검사하면 되므로, 파싱 로직이 매우 빠르고 안정적입니다.
결론적으로, 이 규칙은 **"데이터는 순수한 텍스트에 가깝게 유지하고, 모든 복잡한 처리는 앱의 개발 로직이 담당한다"**는 현대적인 데이터 관리 철학을 완벽하게 구현한 것입니다.
Quiz Question Media Tagging Specification
This specification defines the strict rules for embedding images or videos directly within the text of a quiz question (Question Text).
1. Core Principles and Objectives
Global Compatibility: Tag names must use English (image, video) to ensure seamless internationalization (i18n) and localization (l10n).
Parsing Stability: Media tag recognition conditions are defined with extreme rigor to eliminate conflicts and parsing errors with general text.
Simplicity: Tags must not include any complex attributes (Attribute-Free), only the file path.
2. Media Tag Format
Media tags must always start with [< and end with >], enclosing the standard XML-style tags within.
Image Insertion Format: [<image>path/file.jpg</image>]
Video Insertion Format: [<video>path/file.mp4</video>]
3. Mandatory Media Tag Recognition Condition (Strict Boundary)
A string is recognized as a Media Tag (Special Environment) only if it meets this single, strict condition:
Fixed Starting Position: The tag must be located at the very beginning (first character) of the Question Text string.
The first character must be [, and the second character must be <.
No characters—including spaces, tabs, or newlines—are allowed before the tag.
4. Content Creator Guidelines
Content creators must strictly adhere to the following guidelines:
Media Placement: To insert media, the entire question text must begin with the media tag. Tags cannot be inserted in the middle or at the end of the text.
Tagging: Tags must be entered exactly as defined, including the correct file path (e.g., [<image>assets/q1_photo.jpg</image>]).
Conflict Avoidance: Using the characters [, <, >, or ] in the general body of the question text is strongly discouraged as it can interfere with the tag parsing logic. If unavoidable, use alternative symbols or methods.
5. Media Tag Recognition Examples (20 Cases)
The following examples demonstrate how the strict recognition rule applies. ✅ Media Tag means the media is loaded and the tag is removed. ❌ General Text means the tag structure is ignored and the text is displayed as is.
A. ✅ Recognized as a Media Tag (Special Environment)
The tag is at the very start of the string.
[<image>q1_map.jpg</image>]What is the correct explanation for this map?
[<video>intro.mp4</video>]Watch the video and answer the question.
[<image>assets/photo.jpg</image>]When was this photo taken?
[<video>lecture.mp4</video>] (Tag alone is recognized)
[<image>url/external.png</image>]Which statement describes this image?
[<video>clip.mp4</video>] (Note: The video plays for 5 seconds.)
[<image>1.png</image>]The answer is number 2.
[<video>v1.mp4</video>]
[<image>path/sub/file.gif</image>]What content corresponds to the figure above?
[<video>long_name_video_001.mp4</video>]Now, solve the problem.
B. ❌ Recognized as General Text (Not a Media Tag)
The tag structure fails the strict starting condition.
The core of this problem is [<image>q1_map.jpg</image>].
Reason: The tag is not at the very beginning of the string.
[Note]<image>q1_map.jpg</image> Look at this picture.
Reason: The second character is 'N', not <.
(<image>q1_map.jpg</image>) This is an explanation for the problem.
Reason: The first character is a space, not [.
[1] This statement refers to the problem.
Reason: The second character is a number, not <.
[<image>q1_map.jpg</image> ] (Space before the closing ])
Reason: Fails the exact pattern match for the closing sequence.
<image>q1_map.jpg</image>
Reason: The first character is <, not [.
The sentence [< How are you? >] is inside the text.
Reason: There is a space before the [.
[Q] What is the next step?
Reason: The second character is 'Q', not <.
[ <image>path.jpg</image>] (Space after the opening [)
Reason: The second character is a space, not <.
This question asks about [<image>path.jpg>].
Reason: There is a space before the [.
Structural Strengths of the Strict Media Tagging Rule
Yes, that's right. As a developer with 25 years of experience, I can confirm that this strictly defined tagging system—using the [<image>path</image>] format with a "must start at the beginning of the string" rule—maximizes all the advantages you mentioned.
Here are the core strengths this rule brings to your project:
1. Solves the DB Table Segmentation Problem (Flexibility)
This approach offers the most significant benefit by allowing you to keep your data model simple.
Simplified Table Structure: You avoid the need for separate tables like Media_Table or Question_Image_Table. Your main database table (Quiz_Question) only needs core fields such as question_id, text_content, and answer.
Minimal Data Model Changes: Because the media information (path, type) is embedded within the question text, you will never need to change the DB table schema if new media types are added. Only the parsing logic needs to be updated.
2. Ease of Adding New Media Types (Scalability)
Responding to new media types (e.g., 3D models, AR markers, audio files) becomes very fast.
Simple Expansion: You only need to define a new, intuitive tag, such as <audio> or <ar>.
Example: [<audio>file.mp3</audio>]
Maintained Backward Compatibility: The logic only needs to add a new pattern to the parsing routine. Existing data using <image> and <video> tags remain perfectly backward compatible without any modifications.
3. Structural Accessibility for Non-Developers
This method is highly user-friendly for content creators who are not coders.
Intuitive Understanding: Creators only need to remember the straightforward English tags (image, video) and wrap them in the simple [< and >] pattern. They don't need to learn complex XML grammar or specific attributes.
Easy Content Creation: Since the media information lives directly in the text, content teams can easily manage data in simple text editors or spreadsheets, which is highly efficient for text-based data management.
4. Parsing Logic Clarity (Development Efficiency)
Clear Boundary Condition: The strict rule requiring the tag to be at the very start of the string means your parsing logic does not need to scan the entire text for every bracket. Checking only the start of the string makes the parsing extremely fast, reliable, and significantly reduces the chance of misinterpretation.
In short, this rule perfectly implements the philosophy that "data should remain close to pure text, and all complex processing should be handled by the application's development logic."
FROM BUNTGAMES.COM