당신의 아랍어 제목은 깨진 것이 아닙니다. 스토어가 다른 방향으로 읽고 있을 뿐입니다

아랍어나 페르시아어, 우르두어 제목이 스토어에 도착했는데 괄호가 반대쪽에 붙어 있거나 "feat." 크레딧이 맨 끝으로 밀려 있거나 카탈로그 번호가 엉뚱한 자리에 떠 있다면, 무엇도 손상된 것이 아닙니다. 당신이 입력한 바이트가 거의 언제나 그대로 도착한 바이트입니다. 달라진 것은 그 텍스트가 그려지는 상자의 기준 방향이고, 그것은 당신의 제목이 아니라 스토어의 페이지가 결정합니다. 이 글은 어떤 제목이 전송 전에 깨질지 예측할 수 있을 만큼 정확하게 그 원리를 설명합니다.

먼저 하나 밝혀 둡니다. 정직한 입장이기 때문입니다. 아랍 문자 메타데이터의 오류율을 측정해 공개한 자료는 업계 어디에도 우리가 아는 한 존재하지 않습니다. 이 문제는 누구나 겪지만 전혀 계량되어 있지 않습니다. 아래에 수치가 나오지 않는 이유는, 제시할 수치가 없기 때문입니다.

논리 순서와 표시 순서는 서로 다른 것입니다

Unicode는 텍스트를 논리 순서로 저장합니다. 즉 당신이 말하고, 입력하고, 소리 내어 읽는 순서입니다. 표시 순서는 렌더링 시점에 그것으로부터 계산되며, Unicode Standard Annex #9 (UAX #9)에 정의된 유니코드 양방향 알고리즘이 그 일을 합니다. 이 부속서는 그 구분을 직설적으로 말합니다. "The Unicode Standard prescribes a memory representation order known as logical order", 그리고 "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."

이 한 문장이 아랍 문자권 아티스트들에게 자기 메타데이터에 귀신이 붙었다고 느끼게 만드는 현상을 설명합니다. 저장된 문자열이 완벽히 올바른데도 표시가 잘못될 수 있고, 화면상으로는 올바른데 저장된 바이트가 잘못돼 있을 수도 있습니다. 그리고 화면에서 두 실패는 똑같아 보입니다. 눈으로 봐서는 검증할 수 없습니다. 유통사의 상담 직원도 마찬가지입니다.

RTL 문자열 안의 라틴 문자가 움직이는 이유

UAX #9는 모든 문자에 양방향 유형을 부여합니다. 아랍어, 페르시아어, 우르두어 글자는 AL(오른쪽에서 왼쪽으로 쓰는 아랍 문자)입니다. 라틴 글자는 L입니다. ASCII 숫자는 EN(유럽 숫자), 아랍-인도 숫자는 AN(아랍 숫자)입니다. 공백과 대부분의 구두점 — 소괄호, 대괄호, 하이픈, 마침표를 포함해 — 은 중립이며, 자체 방향이 없어 주변에서 방향을 물려받습니다.

두 규칙 묶음이 문제를 일으킵니다.

문단 방향, 규칙 P2–P3. 알고리즘은 첫 번째 강한 방향성 문자를 찾아 그것으로 기준 방향을 정합니다. 라틴 단어로 시작하는 제목은 그 뒤가 전부 페르시아어여도 왼쪽에서 오른쪽 기준 방향을 갖게 됩니다.

중립 문자 해소, 규칙 N1–N2. 규칙 N1: "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction." 규칙 N2: 합의가 없는 중립 문자는 문단 방향을 따릅니다. 그다음 규칙 L2가 표시를 위해 재배열합니다. "reverse any contiguous sequence of characters that are at that level or higher."

이것들을 합치면 실패는 무작위가 아니라 결정론적입니다. 라틴 문자 토큰 — 리믹서 이름, feat., Vol. 2, 카탈로그 번호, 연도 — 은 주변 아랍어와 다른 임베딩 레벨에 놓입니다. 그 경계의 중립 문자들(공백, 여는 괄호)은 한쪽에 아랍어, 다른 쪽에 라틴 문자를 두고 있으므로 N1은 합의를 찾지 못하고 N2가 문단 방향을 넘겨줍니다. 당신의 오른쪽에서 왼쪽 편집기에서 한 방향으로 해소되던 괄호가 왼쪽에서 오른쪽 스토어 페이지에서는 반대로 해소되고, 괄호가 떨어져 나가 뒤집힙니다.

그러니 نام آهنگ (Nima Remix)는 깨진 것이 아닙니다. 하나의 문자열이 두 맥락에서 해소되고 있는 것입니다. 기준 방향은 내용이 아니라 맥락이고, 스토어의 맥락은 당신의 맥락이 아닙니다.

절대 하지 말아야 할 한 가지

미리보기가 제대로 보일 때까지 문자를 거꾸로 입력해서 표시를 "고치지" 마십시오.

그렇게 하면 논리 순서상 잘못되었고, 딱 하나의 렌더링 맥락에서만 맞고, 나머지 모든 곳에서는 깨지는 문자열이 만들어집니다. 검색, 정렬, 아티스트 매칭, 그리고 당신이 고쳤던 도구와 기준 방향이 다른 모든 스토어에서 말입니다. 회복 가능한 표시 문제를 회복 불가능한 데이터 문제로 바꿔 놓은 셈이 됩니다.

UAX #9는 이를 명시적으로 제어하는 문자들을 실제로 정의해 두었습니다. 격리 문자 LRI, RLI, FSI, PDI와 표식 문자 LRM, RLM, ALM입니다. 기술적으로는 이것이 올바른 해법입니다. 다만 이들은 보이지 않는 서식 문자이고, 많은 전송 파이프라인이 보이지 않는 서식 문자를 아무 말 없이 제거합니다. 메타데이터 필드에서는 신뢰할 수 없는 것으로 취급하십시오.

구조적 해법: 라틴 문자 토큰을 가운데에서 빼내기

모든 렌더러에서, 보이지 않는 문자 없이 통하는 완화책은 구조적인 것입니다. 선호 순서대로 적습니다.

• 데이터 모델이 제공하는 곳에서는 방향이 섞인 문자열 대신 별도 필드를 쓰십시오. 참여 아티스트는 제목이 아니라 아티스트 역할 단계에 들어갑니다. Music Biz의 Music Metadata Style Guide는 참여 아티스트를 아티스트 역할 단계에서 크레딧하고 그 데이터를 트랙이나 앨범 발매 제목에 넣지 말라고 권고하며, Spotify의 공개 안내는 "You shouldn't include any artists' names in your track or release titles"입니다. 버전 정보는 버전 필드에 들어가야 합니다. 그 필드의 존재 이유가 제목이 같은 두 음원을 구분하는 것입니다. 자기 필드로 옮긴 라틴 문자 토큰 하나하나가 사라지는 양방향 경계 하나입니다.
• 피할 수 없는 라틴 문자 토큰은 첫 자리에 두지 마십시오. 첫 자리가 P2–P3에 따라 문단 방향을 정합니다. 라틴 단어로 시작하는 페르시아어 제목은 페르시아어가 담긴 왼쪽에서 오른쪽 문단이며, 그것은 당신이 의도한 바가 아닙니다.
• 방향 경계에 장식용 구두점을 두지 마십시오. 대시, 슬래시, 파이프, 겹친 괄호는 알고리즘이 가진 정보가 가장 적은 바로 그 자리에 놓인 중립 문자입니다.

계약상 제목에 크레딧 표기가 반드시 들어가야 한다면, 관례가 정해져 있으니 그대로 따르는 것이 좋습니다. Music Biz는 "feat."와 "with"에 대해 이렇게 적습니다. "when included in the title are generally lowercase and in English." Apple의 스타일 가이드는 이렇습니다. "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets." 여기서 "not localized"라는 지시가 실제로 일을 합니다. 제목 필드에서 "feat."를 아랍어나 페르시아어, 우르두어로 번역하지 마십시오. 그것은 단어가 아니라 기계가 읽는 토큰입니다.

숫자, 그리고 당신이 쓴 숫자가 생각한 그 숫자가 아닐 수 있는 이유

세 가지 숫자 집합이 관련됩니다.

이것들은 서체상의 변형이 아닙니다. 서로 다른 코드 포인트이며, Unicode Character Database에 따르면 양방향 분류조차 공유하지 않습니다. UAX #9의 규칙 W2는 가장 가까운 앞선 강한 문자가 아랍 문자일 때 유럽 숫자를 아랍 숫자로 다시 분류하므로, 페르시아어 텍스트 안에서 둘은 표시 시점에는 비슷하게 동작할 수 있습니다. 하지만 정렬이나 검색, 문자열 비교에서는 결코 그렇지 않습니다. 서로 다른 문자이기 때문입니다. 확장 아랍-인도 숫자 ۲로 쓴 "Vol. 2"와 ASCII 2로 쓴 "Vol. 2"는 거의 똑같아 보이는 서로 다른 두 문자열입니다.

카탈로그마다 숫자 집합을 하나로 정하고, 한 문자열 안에서 집합을 절대 섞지 마십시오.

실제로 무엇을 입력했는지 확인하는 법

표시는 믿을 수 없으니 바이트를 확인하십시오. 전송 전마다 해 볼 만한 세 가지입니다.

1. 문자열을 글리프가 아니라 코드 포인트로 읽으십시오. U+ 값을 보여 주는 도구라면 그것이 페르시아어 ی(U+06CC)인지 아랍어 ي(U+064A)인지, 페르시아어 ک(U+06A9)인지 아랍어 ك(U+0643)인지 즉시 알려 줍니다. 대부분의 폰트가 뭉개 버리고 어떤 교정자도 볼 수 없는 구분입니다. 어떤 유니코드 정규화 형식으로도 제거되지 않는 떠도는 타트윌(U+0640)이나, 입력 필드가 조용히 삼켜 버린 폭 없는 비결합 문자(U+200C)에도 같은 이야기가 적용됩니다.
2. 제목을 왼쪽에서 오른쪽 맥락과 오른쪽에서 왼쪽 맥락에 각각 붙여 넣고 비교하십시오. 두 곳에서 구두점이 다른 자리에 떨어진다면, 방향이 섞인 문자열이고 자기 필드로 가야 할 라틴 문자 토큰이 있는 것입니다.
3. 이전 발매물과 눈대중이 아니라 한 글자씩 대조하십시오. 아랍 문자 카탈로그가 쪼개지는 원인은 거의 언제나 눈에 보이지 않는 차이입니다. 한 발매물은 페르시아어 자판으로, 다음 발매물은 아랍어 자판으로 입력한 식입니다.

Mazufa의 도구는 전부 브라우저 안에서 실행되고 오디오도 텍스트도 업로드되지 않으며, 제목이 오른쪽에서 왼쪽으로 쓰이면 dir="rtl"을 자동으로 설정하므로 입력하는 동안 보이는 것이 그 문자열이 쓰인 맥락과 일치합니다. mazufa.com에는 당신 기기에서 실행되며 보이지 않는 사례들을 짚어 주는 무료 메타데이터 체커도 있습니다. 숫자 집합 혼용, 타트윌, 떠돌거나 빠진 ZWNJ, 아랍어와 페르시아어의 예·카프 구분, 그리고 NFC가 아닌 문자열을 잡아냅니다.

전송 전에 할 일

다음 발매물의 제목과 아티스트명을 놓고 네 가지를 하십시오. 옮길 수 있는 라틴 문자 토큰은 모두 자기 필드로 옮기십시오. 참여 아티스트는 아티스트 역할로, 버전은 버전 필드로 말입니다. 라틴 단어로 시작하는 것이 없는지 확인하십시오. 숫자 집합을 통일하고 타트윌을 제거하십시오. 그다음 문자열을 코드 포인트로 한 번 읽고, 바로 그 문자열을 앞으로 모든 발매물에서 다시 입력하지 않고 재사용할 표준 표기로 저장해 두십시오.

그래도 제목 가운데에 라틴 문자 토큰을 넣어야 한다면, 그대로 전송하고 곳에 따라 다르게 렌더링되리라는 점을 받아들이십시오. 그것은 손상이 아니라 표시상의 결과입니다. 문자열은 올바릅니다. 미리보기 하나를 제대로 보이게 하려고 거꾸로 다시 입력하는 것만이 그것을 진짜로 잘못되게 만드는 유일한 방법입니다.

출처

• Unicode Standard Annex #9, Unicode Bidirectional Algorithm (Revision 51, Unicode 17.0.0, 2025-08-13) — https://www.unicode.org/reports/tr9/
• Unicode Standard Annex #15, Unicode Normalization Forms (Version 57, Unicode 17.0.0, 2025-07-30) — https://www.unicode.org/reports/tr15/
• Unicode Character Database — 문자 속성: 양방향 분류, 분해 매핑 — https://www.unicode.org/ucd/
• Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
• Apple Music Style Guide — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
• Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/

이 문서들의 버전과 개정 날짜는 위에 적은 대로 자료 모음에 기록되어 있으며, 별도의 열람 날짜는 기록되어 있지 않습니다.