URL スラッグ生成

タイトルを URL スラッグに変換。ヘブライ語、アラビア語、キリル文字、ギリシャ文字を翻字し、Unicode 形式と一覧の衝突検出も。

スラッグ
creme-brulee-grusse-aus-munchen
Unicode パス — 翻字なし、失われるものなし
crème-brûlée-grüße-aus-münchen
パーセントエンコード — サーバーが見る形
cr%C3%A8me-br%C3%BBl%C3%A9e-gr%C3%BC%C3%9Fe-aus-m%C3%BCnchen

ブラウザは上の読みやすい形を表示し、こちらを送信します。どちらも同じパスです。

このツールの役割

任意の文字体系でタイトルを貼り付けると、URL が運べるスラッグとして返ってきます: 小文字、句読点なし、あなたが選ぶ区切り文字で結ばれた単語です。ラテンのアクセントは取り除かれ、ヘブライ語・アラビア語・キリル文字・ギリシャ文字はラテン文字に翻字されます。

スラッグの横には、同じタイトルが自分の文字体系のまま置かれます。その形も合法なパスで、翻字で最も多くを失う文字体系にとってはしばしばよりよい答えです — だから、ツールが選ぶのではなく、一つのタイトルから両方が生まれます。

スラッグは何のためか

スラッグは URL の人が読める部分です: 最後のスラッシュの後、ページを番号付けるのではなく名付ける一片です。単語として読めるパスは、メッセージに貼り付けられ、スライドに印刷され、電話で読み上げられても生き延び、数値の id はそのどれもしないから存在します。

だから形がこれほど制約されます。スラッグは安定しているべきで — 変えると既にそのページを指すすべてのリンクを壊します — 手で書かれたとき曖昧でないべきで、それが空白、読み手が再現するかしないか分からない大文字、そしてシェルや Markdown パーサーに何かを意味する句読点を除外します。

アクセントはどう取れるか

ほとんどのラテンの発音区別符号は、表ではなくプラットフォームによって取り除かれます。Unicode は é を、素の e に結合アキュートアクセントを続けたものに分解できると定義するので、その分解された形に正規化してからすべての結合文字を捨てると、素の文字が残ります。同じ操作が ñ・ç・ő ほか数百を扱い、ブラウザが既に出荷する Unicode データを使うので、時代遅れになりえません。

すべてを扱うわけではなく、その隙間は知っておく価値があります。印が字形の上の印ではなく字形を貫く線である文字 — ø・ł・đ・ħ・ŧ — は、分解をまったく持たない単一の分けられない文字なので、印を取り除いてもそのまま残ります。合字も同じです: ß・æ・œ はそれぞれ、文字に装飾を足したものではなく、音の並びを表します。それらすべては明示的な綴りが要り、それなしにはただスラッグから消えるでしょう。

言語設定が答えを変える理由

ü の唯一の正しいローマ字化はありません。ドイツ語はダイエレシスが存在する前から 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 の二重字は平らになるのを生き延びます。

キリル文字の表の一つの詳細は誤りやすく、述べる価値があります。ё と й はアクセント付きの文字に見え、Unicode はそう分解しますが、印はそれらを同じ文字の上の装飾ではなく別の文字にするものです。表を参照する前に印を剥がすこと — ここのほかのすべての文字体系にとって正しい順序 — は、Ёлка を黙って elka に、Андрей を andrei にします。

ヘブライ語とアラビア語、そして失うもの

両方の文字体系は子音を書き、ほとんどの母音を、ふつうのテキストが運ばない点に任せます。それは、このツールがよりよい表で解決できる符号化の問題ではありません: 情報がテキストにないのです。מאמר は四つの文字、メム・アレフ・メム・レシュで、maamar という読みは、その語を既に知る読み手から来ます。一文字ずつでは mamr にしかなれません。

できることはされます。文字が母音記号を兼ねるところではその位置が使われます。それが、点なしのテキストが残す唯一の信号だからです:

  • ו と י は語頭では子音、語中では母音字で、それが שלום を shlvm ではなく shlom にするものです。
  • 二重の וו や יי は両方の場所で子音です — その二重化こそ、ヘブライ語が二つの読みを区別する方法です。
  • ב・כ・פ は語頭では閉鎖音、語中では摩擦音です。その違いを印すダゲシュは母音点なので、位置だけが残ります。
  • ゲレシュが続く文字は、アルファベットに文字のない音です: ג׳ は j、צ׳ は ch、ז׳ は zh。無視すれば ג׳אז が別の語になるでしょう。
  • アラビア語の強勢子音は素の対応物に潰れます。ASCII に、それらを区別する下の点を置く場所がないからです。صابر と سابر は同じスラッグを生みます。

結果は読めて認識でき、誰も正しいと呼ばない綴りです。ツールは、損失のある答えを完成したものとして示すのではなく、すべてのヘブライ語やアラビア語の結果でそう言い — 何も失わない下の形を指します。

翻字の要らない Unicode パス

URL パスは ASCII に限られません。RFC 3987 は IRI — 任意の Unicode 文字を含みうる識別子 — を定義し、それを回線に載せる規則は UTF-8 バイトをパーセントエスケープとして符号化することです。すべてのブラウザが 20 年これをしてきて、だから Wikipedia がヘブライ語やロシア語の記事タイトルを自分の名前で提供し、アドレスバーがそれらを読めるように示すのです。

だからここの二つ目の出力は、句読点と間隔を整え、それ以外は何も触れないタイトルで、三つ目はそれが実際に回線でどう見えるかです。それらは同じパスです: 読めるほうがブラウザが表示し人がコピーするもので、符号化されたほうがサーバーが記録するものです。

どちらを使うかは形式ではなく本物の決定です。Unicode 形式は何も失わず、その言語を話す誰にも正しく読め、検索エンジンが示すものです。翻字された形式は、符号化を壊す場所に貼り付けられても生き延び、ASCII パスを仮定するシステムに収まり、電話で読み上げられます。特にヘブライ語とアラビア語では、翻字が母音を回復できないからこそ、Unicode 形式がたいていよりよい答えです。

衝突と、なぜそれがあなたのために解決されないのか

スラッグ化は句読点を剥がすので、句読点だけが異なるタイトルはまったく異ならなくなります。「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 文字を表示し、古いシステムは時にパスの一区切りに上限を設けますが、特定の数で何も壊れません。欄を空のままにすると、スラッグはタイトルが必要とするだけ長くなります。

よくある質問

URL スラッグで安全な文字は何ですか?
小文字の ASCII 文字・数字・単一の区切り文字は、例外なくどこでも動きます。ハイフンが慣習的な区切りで、アンダースコアも同じに動きますが、下線の付くリンクの下では見にくいです。空白・大文字・句読点はすべて技術的には符号化でき、すべて実務で問題を起こすので、スラッグはそれらを剥がします。
ハイフンかアンダースコアか?
ハイフンです。流行を超える二つの理由で。すべての主要なプラットフォームが使うもので、だから読み手やほかのツールが期待するもので、ほとんどのリンクが持つ下線の下で消え、アンダースコアはそうしません。既存のシステムには既存の慣習があり、一つのサイトの中での一貫性がどちらの答えよりも重要なので、選択はここで提供されます。
私のヘブライ語やアラビア語のタイトルが母音を失うのはなぜですか?
それらが決して書かれなかったからです。両方の文字体系はほとんどの母音を、ふつうのテキストが省く点で印すので、一文字ずつの読みが、どの語が意味されたかを推測する母音化エンジンなしにどんなツールも生めるすべてです。これは実際にそこにあるものを翻字し、結果でそう言い、タイトルを入力どおりに保つ Unicode パス形式を提供します。
URL はヘブライ語・アラビア語・中国語を直接含めますか?
はい。パスは任意の Unicode 文字を保持でき、回線では UTF-8 としてパーセントエンコードされ、ブラウザに読めるように表示されます。それが Wikipedia が覆うすべての言語で記事タイトルを提供する方法です。このツールは読める形と符号化された形の両方を示します。二つ目がサーバーのログと分析に現れるものだからです。
Müller が時々 mueller で時々 muller なのはなぜですか?
両方が、異なる言語で正しいからです。ドイツ語はウムラウトを綴り出し — 二つの点は小さな上付きの e として始まりました — フランス語とスペイン語は発音区別符号を、それ以外はそれ自身である文字の上の印として扱います。言語設定が慣習を選び、ツールはどれを適用したかを教えます。
私の二つのタイトルが同じスラッグを生むのはなぜですか?
スラッグ化が句読点と大小を取り除き、それがしばしば二つのタイトルを分ける唯一のものだからです。一覧モードはすべての衝突を、それが衝突する行とともに印します。WordPress 形式の -2 接尾辞をオンにできますが、根底の問い — 二つの投稿が本当にほぼ同じ名前を持つべきか — を先に答える価値があります。
私が入力したものはサーバーに送られますか?
いいえ。すべての変換がブラウザ内で動きます。何もアップロードも記録もされず、ネットワーク接続なしで動きます。