Kento
URIと文字
2025年06月30日
Tips
見出しはありません
要約を生成中...
URI（Uniform Resource Identifier）は、Webの基盤技術のひとつであり、リソースを一意に識別するために使われます。
しかし、そのURIの中にどんな文字が使えるか、文字の表現に制限はあるのかといった点まで、正確に理解している人は意外と多くないかもしれません。
今回の記事では、URIにおける**「文字の扱い」**に注目していきましょう！
関連記事もご覧ください。
URIでは、次の文字がURIのパスに使えると定められています。
英字（A-Z, a-z）
数字（0-9）
記号 (; , / ? : @ & = + $ #)など
これらの文字は、ASCII（American Standard Code for Information Interchange）に基づく文字で、7ビットで表現される英数字や記号です。
つまり、URIには日本語の文字を直接入れられません。
日本語などのASCII以外の文字をURIに入れるときは、%エンコーディングという方式を用います。
URIに使えない文字をどう表すのか
私たちがふだん目にするWebサイトのURL（URI）は、実は「使える文字」にルールがあります。
たとえば、アルファベットや数字、「-」「_」「.」など一部の記号以外の文字（日本語や空白など）はそのままではURIに使えません。
🔐 そこで登場するのが「%エンコーディング」
「%エンコーディング」とは、使えない文字を「%」と数字で置き換える方法です。
これにより、コンピュータが正しくURIを読み取れるようになります。
具体例で見てみましょう
たとえば、「ひらがなの“あ”」をWikipediaで検索すると、ブラウザのアドレス欄にはこう表示されます：
表示上のURI（人間向け）
http://ja.wikipedia.org/wiki/あ実際に使われているURI（コンピュータ向け）
http://ja.wikipedia.org/wiki/%E3%81%82
※現在主流の「HTTPS」プロトコル
「あ」という1文字が、実は %E3%81%82 という9文字で表現されているんですね。
なぜこうなるの？
「あ」は UTF-8 という文字コードで
0xE3 0x81 0x82 という 3つのバイトに変換されます。
それぞれのバイトが %E3, %81, %82 のように「%xx」形式で表現されます。
つまり、「1文字＝1バイト」ではなく、「1文字＝複数バイト」になることがあるんです。
✋注意点
% 自体をURIに使いたいときは、「%25」と書く必要があります（%の%エンコーディング）。
%E3%81%82 のように 大文字と小文字は区別されません（%e3 でもOK）。でも、公式には大文字を使うことが推奨されています。
先ほどのWikipediaのURIでは、文字列をUTF-8でエンコードしていることを前提にしていました。しかし、実際のWebサービス以外の文字エンコーディングを使ったURIも利用されています。
例えば同じ「あ」でも、文字エンコーディングによってバイト列は表１のように変化します。
表１
サーバが提供するURIをそのまま扱う場合、そのURIはサーバが%エンコードしているので問題ないのですが、クライアント側でフォームを使ってURIを生成する場合は問題が発生が生じます。
ユーザが入力した文字をどの文字エンコーディングを使って%エンコードするかをブラウザなどのクライアントが判断できないからです。
この問題は、一般的には元となるフォームを提供しているWebページの文字エンコーディングを使うことで解決します。
UTF-8で記述したフォームならUTF-8で、Shift _JISで記述したフォームならShift _JIでURIを作ります。
ただ、この方式はプロキシで文字エンコーディングを変換する場合や、元となるWebページの文字エンコーディングの範囲外の文字が与えられ場合などに不具合を起こします。
現代的なWebサイトの多くは文字エンコーディングとしてUTF-8で%エンコードする場合がほとんどです。
これからWebサイトを構築する場合は、よほどの理由がない限りUTF-8を使うのが無難です。
国際対応に強い（多言語対応）
ASCII、ひらがな、漢字、絵文字など、世界中の文字を1つのエンコーディングで表現可能。
HTML・CSS・JavaScriptとの親和性
W3CもHTML5以降は UTF-8 を標準としており、<meta charset="UTF-8"> がデフォルト。
ブラウザ・検索エンジンがUTF-8前提で最適化されている
Googleなどの検索エンジンもUTF-8を前提としてクロールやインデックス化を行う。
他の文字コードは非推奨・廃止の流れ
Shift_JISやEUC-JPなどは、レガシーな用途以外ではほとんど使用されなくなっています。
仕様上、URIの長さには明確な上限はありません。
しかし、実際のブラウザやサーバーの実装には制限が存在します。
特に Internet Explorer（IE） は、バージョンに関係なく 約2,038バイト までという制限があり、実務ではこの制限に合わせて設計されることが多くあります。
また、URIが長くなりすぎると、可読性が低下し、扱いづらくなるため、たとえモダンブラウザで扱えるとしても、なるべく短く整理することが推奨されます。
WebサービスやWeb APIを実装する際に意識すべきポイントは、相対URIの扱いと非ASCII文字のエンコード処理です。
相対URIは、クライアント側で解決処理が必要となるため、Webサービスでは絶対URIを使用するのが望ましいです。これにより、クライアント実装の複雑さを避けることができます。
また、URIに日本語などの非ASCII文字を含める場合は、%エンコード（パーセントエンコーディング）を行う必要があります。このときの文字コードにはUTF-8を用いるのが一般的であり、他の文字コード（例：Shift_JISやEUC-JP）を使うと文字化けや解釈の不一致が起きやすくなるため注意が必要です。
URIの仕様を正しく理解することは、堅牢なWebサービスを構築する上で重要な基礎となります。
次回は、この知識を踏まえた「URI設計」のポイントについて見ていきましょう！！
「符号化」「暗号化」「記号化」などの意味がある。
映像や音声などのデータを一定の規則に従い圧縮や暗号化を行い、別の形式に変換することを「エンコード」という。
日本語を扱うために、主にWindowsで使われていた文字コードです。
1970年代にMicrosoftが開発し、日本のパソコンでも長く標準として使われてきました。
現在では、レガシーなWebページや古いソフトで時々見かけるぐらいです。
UNIX系のシステムで使われていた日本語対応の文字コードです。
「EUC」は「Extended Unix Code」の略で、複数の言語を扱うために作られました。
とくにEUC-JPは、LinuxやUNIXサーバーで日本語表示をする場面で使われていました。
要約
コメント
まだコメントはありません。
