URL 슬러그 생성기

이 도구가 하는 일

어느 문자 체계의 제목을 붙여넣어도 URL이 나를 수 있는 슬러그로 돌아옵니다: 소문자, 구두점 없음, 당신이 고른 구분자로 이은 단어입니다. 라틴 악센트는 떨어지고, 히브리 문자, 아랍 문자, 키릴 문자, 그리스 문자는 라틴 글자로 로마자화됩니다.

슬러그 옆에는 같은 제목이 자기 문자 체계 그대로 놓입니다. 그 형태도 합법적인 경로이고, 로마자화에서 가장 많이 잃는 문자 체계에는 흔히 더 나은 답입니다 — 그래서 도구가 골라 주는 대신 하나의 제목에서 둘 다 나옵니다.

슬러그는 무엇을 위한 것인가

슬러그는 URL의 사람이 읽을 수 있는 부분입니다: 마지막 슬래시 뒤의, 페이지를 번호 매기는 것이 아니라 이름 붙이는 조각입니다. 단어로 읽히는 경로는 메시지에 붙여넣어지거나, 슬라이드에 인쇄되거나, 전화로 소리 내어 읽혀도 살아남고, 숫자 id는 그중 아무것도 하지 못하기에 존재합니다.

그것이 모양이 그토록 제약된 이유이기도 합니다. 슬러그는 안정적이어야 하고 — 바꾸면 이미 그 페이지를 가리키는 모든 링크가 깨집니다 — 손으로 쓸 때 모호하지 않아야 하는데, 그것이 공백, 읽는 이가 재현할지 안 할지 모를 대문자, 셸이나 Markdown 파서에 무언가를 뜻하는 구두점을 배제합니다.

악센트는 어떻게 떨어지는가

대부분의 라틴 발음 구별 부호는 표가 아니라 플랫폼이 떼어 냅니다. 유니코드는 é를 맨 e에 결합 예음 악센트를 이은 것으로 분해할 수 있다고 정하므로, 그 분해된 형태로 정규화한 뒤 모든 결합 문자를 버리면 맨 글자가 남습니다. 같은 연산이 ñ, ç, ő와 수백 개를 더 다루고, 브라우저가 이미 싣는 유니코드 데이터를 쓰므로 낡을 수 없습니다.

모든 것을 다루지는 않고, 그 틈은 알아 둘 만합니다. 자국이 글자 위의 표가 아니라 글리프를 가로지르는 획인 글자 — ø, ł, đ, ħ, ŧ — 는 분해가 아예 없는 단일의 나눌 수 없는 문자라, 표를 떼어도 그대로 남습니다. 합자도 그렇습니다: ß, æ, œ는 저마다 소리의 나열을 나타내지 글자에 장식을 더한 것이 아닙니다. 그것들 모두 명시적 철자가 필요하고, 그것이 없으면 그저 슬러그에서 사라집니다.

언어 설정이 답을 바꾸는 이유

ü의 유일한 옳은 로마자화는 없습니다. 독일어는 다이에레시스가 있기 전부터 ue로 써 왔고 — 두 점은 작은 위첨자 e로 시작했습니다 — 그래서 Müller는 제대로는 mueller이고, 독일어 읽는 이는 muller를 틀리다 여깁니다. 프랑스어, 스페인어, 포르투갈어는 발음 구별 부호를 그 밖에는 그 자체인 글자 위의 악센트로 다루므로, crème brûlée는 제대로는 creme-brulee이고, cruemme로 쓰는 것은 헛소리일 것입니다.

북유럽 언어는 같은 방식으로 서로 어긋납니다. 덴마크어와 노르웨이어는 그 글자가 대신한 옛 철자를 따라 모음을 두 겹으로 하고, 스웨덴어는 그러지 않습니다:

• 독일어 — ä는 ae, ö는 oe, ü는 ue, ß는 ss가 됩니다. München은 muenchen입니다.
• 덴마크어와 노르웨이어 — æ는 ae, ø는 oe, å는 aa가 됩니다. Ålborg는 aalborg입니다.
• 스웨덴어 — ä는 a, ö는 o, å는 a가 됩니다. Ålborg는 alborg입니다.
• 일반 — 모든 표가 떨어지고 기본 글자가 남습니다. Ålborg는 alborg, München은 munchen입니다.

이것들은 하나의 답에 대한 경쟁하는 근사가 아닙니다. 네 다른 물음에 대한 네 다른 옳은 답입니다. 하나만 기본값이 될 수 있으므로 설정이 보이고, 도구는 어느 관례가 지금 보는 것을 냈는지 말합니다. 한 글자는 어디서나 같습니다: ß는 악센트가 아니라 합자라, 떨어뜨리면 소리를 지우게 되고, 여기 어느 설정에서든 ss입니다.

표가 필요한 문자 체계

브라우저에는 키릴, 그리스, 히브리, 아랍 문자를 로마자화하는 것이 없으므로, 각각이 공개된 표준에 대해 손으로 쓴 표입니다. 그중 둘은 잘 나옵니다. 모음을 쓰기 때문입니다:

• 키릴 문자는 BGN/PCGN을 따릅니다. 영어 지도와 여권의 로마자화입니다: ж는 zh, ч는 ch, щ는 shch, х는 kh입니다. Москва는 moskva, Чехов는 chekhov가 됩니다.
• 그리스 문자는 ELOT 743을 따르고, 그것이 정하는 이중자를 포함합니다: ου는 oy가 아니라 ou, ευ는 ev입니다. Αθήνα는 athina, Ευρώπη는 evropi가 됩니다.

ISO 9은 다른 잘 알려진 키릴 표준이고 여기서 일부러 쓰지 않습니다. 되돌릴 수 있고 그것이 요점이지만, 발음 구별 부호로 그것을 이룹니다: ж는 ž입니다. 슬러그에 캐론의 자리가 없어 곧 z로 평평해지고 — Жуков와 Зуков가 같은 슬러그가 될 것입니다. BGN 이중자는 평평해짐을 살아남습니다.

키릴 표의 세부 하나는 틀리기 쉽고 말할 만합니다. ё와 й는 악센트 붙은 글자처럼 보이고 유니코드도 그렇게 분해하지만, 그 표가 그것들을 같은 글자 위의 장식이 아니라 다른 글자로 만드는 것입니다. 표를 참고하기 전에 표를 떼는 것 — 여기 다른 모든 문자 체계에 옳은 순서 — 은 Ёлка를 조용히 elka로, Андрей를 andrei로 바꿉니다.

히브리어와 아랍어, 그리고 그것들이 잃는 것

두 문자 체계 모두 자음을 쓰고 대부분의 모음을 보통 텍스트가 나르지 않는 점에 맡깁니다. 그것은 이 도구가 더 나은 표로 풀 수 있는 인코딩 문제가 아닙니다: 정보가 텍스트에 없습니다. מאמר는 네 글자, 멤-알레프-멤-레시이고, maamar이라는 읽기는 그 단어를 이미 아는 읽는 이에게서 옵니다. 글자마다는 mamr밖에 될 수 없습니다.

할 수 있는 것은 됩니다. 글자가 모음 기호를 겸하는 곳에서는 그 위치가 쓰입니다. 그것이 점 없는 텍스트가 남기는 유일한 신호이기 때문입니다:

• ו와 י는 단어 처음에서는 자음, 안에서는 모음 글자이고, 그것이 שלום을 shlvm이 아니라 shlom으로 바꾸는 것입니다.
• 두 겹의 וו나 יי는 두 곳 모두에서 자음입니다 — 그 두 겹이야말로 히브리어가 두 읽기를 가르는 방법입니다.
• ב, כ, פ는 단어 처음에서는 폐쇄음, 안에서는 마찰음입니다. 그 차이를 표하는 다게시는 모음 점이라 위치가 남는 전부입니다.
• 게레시가 따르는 글자는 알파벳에 글자가 없는 소리입니다: ג׳는 j, צ׳는 ch, ז׳는 zh입니다. 무시하면 ג׳אז가 다른 단어가 될 것입니다.
• 아랍어 강세 자음은 맨 대응물로 뭉개집니다. ASCII에 그것들을 가르는 아래 점을 둘 곳이 없기 때문입니다. صابر와 سابر가 같은 슬러그를 냅니다.

결과는 읽을 수 있고 알아볼 수 있으며, 누구도 옳다 부를 철자가 아닙니다. 도구는 손실 있는 답을 완성된 것으로 내놓는 대신 모든 히브리어나 아랍어 결과에 그렇게 말하고 — 아무것도 잃지 않는 아래 형태를 가리킵니다.

로마자화가 필요 없는 유니코드 경로

URL 경로는 ASCII에 한정되지 않습니다. RFC 3987은 IRI — 임의의 유니코드 문자를 담을 수 있는 식별자 — 를 정하고, 그것을 회선에 싣는 규칙은 UTF-8 바이트를 퍼센트 이스케이프로 인코딩하는 것입니다. 모든 브라우저가 20년간 이것을 해 왔고, 그래서 Wikipedia가 히브리어와 러시아어 문서 제목을 자기 이름으로 서비스하고 주소창이 그것들을 읽을 수 있게 표시합니다.

그래서 여기 두 번째 출력은 구두점과 간격을 정리하고 그 밖은 아무것도 건드리지 않은 제목이고, 세 번째는 그것이 회선에서 실제로 어떻게 보이는지입니다. 둘은 같은 경로입니다: 읽을 수 있는 것이 브라우저가 표시하고 사람이 복사하는 것, 인코딩된 것이 서버가 기록하는 것입니다.

무엇을 쓸지는 형식이 아니라 진짜 결정입니다. 유니코드 형태는 아무것도 잃지 않고, 그 언어를 하는 누구에게나 옳게 읽히며, 검색 엔진이 보일 것입니다. 로마자화된 형태는 인코딩을 망가뜨리는 곳에 붙여넣어도 살아남고, ASCII 경로를 가정하는 시스템에 들어맞으며, 전화로 소리 내어 읽을 수 있습니다. 특히 히브리어와 아랍어에는 로마자화가 모음을 되살릴 수 없기에 바로 그래서 유니코드 형태가 대개 더 나은 답입니다.

충돌, 그리고 왜 당신을 위해 풀지 않는가

슬러그화는 구두점을 벗기므로, 구두점만 다른 제목은 아예 다르지 않게 됩니다. "Our guide to CSS"와 "Our guide to CSS!"는 두 게시물이고 하나의 슬러그입니다. 목록 모드에서는 그런 충돌마다 그것이 충돌하는 줄이 표시됩니다. 이것이 콘텐츠 관리 시스템이 숨기는 실패이기 때문입니다: 조용히 접미사를 붙이고 공개해, 당신이 기대한 URL이 다른 게시물의 것이 됩니다.

접미사는 스위치로 제공되어 WordPress와 Django 스타일 — our-guide-to-css, our-guide-to-css-2 — 을 냅니다. 목록이 그대로 어딘가에 붙여넣어질 뜻인 경우를 위해서입니다. 충돌이 대개 이름 짓기가 아니라 콘텐츠 문제이기에 기본으로 꺼져 있고, 스위치가 켜져도 충돌은 표시된 채라 켜도 아무것도 숨기지 않습니다.

길이, 그리고 옳은 곳에서 자르기

길이 제한은 구분자 경계에서 자르지 결코 단어 안에서 자르지 않습니다. 단어 중간에 자르는 것은 더 짧은 슬러그라기보다 다른 것을 내고 — introduction-to-crypt은 더 정돈된 introduction-to-cryptography가 아닙니다 — 단어의 절반은 다른 무언가를 뜻하는 단어입니다. 단일 단어가 제한보다 길면 자를 경계가 없어, 잘리는 대신 통째로 돌아옵니다.

보편적으로 옳은 제한은 없습니다. 검색 엔진은 URL의 대략 처음 60에서 70자를 표시하고, 오래된 시스템은 때때로 경로 조각에 상한을 두지만, 특정한 수에서 아무것도 깨지지 않습니다. 칸을 비워 두면 슬러그가 제목이 필요한 만큼 길게 남습니다.