HTML

この記事では、フォーム送信時の文字コードを指定するaccept-charset属性について、現代のWebで基本となるUTF-8や、文字化けを防ぐための考え方を初心者向けに説明します。

この記事でわかること

accept-charsetがフォーム送信時に決めること
meta charsetやHTTPヘッダーとの役割の違い
送信側・サーバー・データベースをUTF-8に揃える理由

The HTML accept-charset attribute tells the browser which character encoding to use when submitting a form (today, this effectively means sending form data in UTF-8).

accept-charset属性

accept-charset は、<form> の送信時に「入力した文字を、どの文字コード（エンコーディング）でサーバーへ渡すか」を指定する属性です。フォームの送信は最終的にバイト列になりますが、その変換ルールを決めるのが accept-charset です。

ざっくり言うと、フォームの送信ボタンを押した瞬間に「文字をどの箱（文字コード）に入れて運ぶか」を決めるイメージです。箱がズレると、受け取った側で文字化けしやすくなります。

Table Of Contents

accept-charsetの主な役割（まずはここだけ）

フォーム送信時の文字コードを指定する: 入力した文字（日本語・絵文字・アクセント付き文字など）を、送信時にどの文字コードでエンコードして送るかを指定します。
現代の実務では「UTF-8に揃える」が基本: 多くの環境で文字コードはUTF-8が前提です。迷ったら accept-charset="UTF-8" を使い、サーバー側もUTF-8で受け取る前提に揃えるのが安全です。
ページのmeta charsetとは役割が違う: <meta charset="UTF-8"> は「そのHTMLをブラウザがどう読むか」。accept-charset は「フォーム送信時にどう送るか」。似ているけれど別の役割です。

ポイント：「ページを読む文字コード」と「フォームを送る文字コード」は別。混ざると原因調査が難しくなります。

まず初心者向け：文字化けが起きる仕組み（超やさしく）

フォームで入力した文字は、送信時にバイト列へ変換されます。文字コードは、その変換ルールです。

送る側：文字 →（文字コードのルール）→ バイト列
受け取る側：バイト列 →（同じルールで戻す）→ 文字

この「ルール」がズレると、受け取る側が間違ったルールで戻してしまい、文字化けします。accept-charset は、送る側のルールを明示するためのひとつの手段です。

現代仕様では「実質UTF-8だけ」だと思ってOK

昔は複数の文字コードを並べて「この中から選んで送ってね」という使い方もありました。しかし現代の仕様では、実質的にUTF-8を前提として扱うのが安全です。

じゃあ、書く意味はある？: あります。特に「フォーム送信の前提を明示しておく」ことで、保守時の混乱を減らせます。また、レガシー環境での事故を減らす“お守り”として有効な場面もあります。
「Shift_JISで送る」みたいな用途に使える？: 現代のブラウザと仕様の組み合わせでは期待どおりに動かない可能性が高いです。UTF-8へ寄せる方向で設計するのが現実的です。

混同しやすい3点セット：どれが何を決めている？

似た言葉が多いので、ここを一度で整理します。

<meta charset="UTF-8">（HTMLの読み取り）: そのHTMLファイルを、ブラウザがどの文字コードとして読み取るかを指定します。ページがUTF-8ならこれが基本です。
Content-Type: ...; charset=UTF-8（HTTPレスポンス）: サーバーが「このレスポンス本文はUTF-8だよ」とブラウザへ伝えるための情報です。meta charset と矛盾すると混乱の元です。
<form accept-charset="UTF-8">（フォーム送信）: フォーム送信時に、入力データをどの文字コードとしてエンコードして送るかを指定します。ページの読み取りとは別の話です。

名前が似ている Accept-Charset（HTTPリクエストヘッダー）もありますが、フォームの accept-charset とは別物として扱うのが安全です（現代の主要ブラウザは送らない前提で設計されがちです）。

実務のおすすめ：迷ったらこの「統一セット」

文字化けは「どこか1箇所だけUTF-8」だと、別の場所でズレて事故りやすいです。実務では、次の統一セットが一番強いです。

ページ（HTML）: <meta charset="UTF-8"> を入れてUTF-8にする。
フォーム送信: 必要なら accept-charset="UTF-8" を付け、送信もUTF-8前提にする。
サーバーの受け取り: POST/GETをUTF-8として扱う設定に揃える（フレームワークや言語の設定を確認する）。
DB: UTF-8（特に絵文字まで扱うなら utf8mb4）に揃える。

ポイント：「送る側がUTF-8」でも「受け取る側がUTF-8として読む」とは限りません。原因切り分けは“送信”と“受信”を分けて考えると早いです。

サンプル（最小）

まずはこれだけでOK、という最小形です。

HTML

<form action="/submit" method="post" accept-charset="UTF-8">
    <label>
        お名前
        <input type="text" name="name" autocomplete="name">
    </label>

    <button type="submit">送信</button>
</form>

インデント（字下げ）は半角スペース4つに揃えています。

サンプル（ページも送信もUTF-8に揃える）

実務では「ページ側もUTF-8」をセットで入れておくのが事故りにくいです。

HTML

<!doctype html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>フォーム送信をUTF-8に揃える</title>
</head>
<body>
    <form action="/submit" method="post" accept-charset="UTF-8">
        <label>
            メッセージ
            <textarea name="message" rows="4"></textarea>
        </label>

        <button type="submit">送信</button>
    </form>
</body>
</html>

送信形式（enctype）との関係（中級者向け）

フォームは「文字コード」だけでなく「どんな形式で送るか」も関係します。ここで迷うと、文字化けの調査が遠回りになります。

application/x-www-form-urlencoded（デフォルト）: 普通のフォーム送信の基本形です。多くの場面でこれでOKです。
multipart/form-data（ファイル送信など）: ファイルアップロードが絡むときはこれが基本です。文字の扱いも含めて環境差が出やすいので、UTF-8統一がさらに大事になります。
text/plain（ほぼ使わない）: デバッグ用途っぽい位置づけです。実務では避けることが多いです。

実務の結論：UTF-8 +（通常は）urlencoded /（ファイルなら）multipart が安定です。

ありがちな落とし穴（初心者がハマりやすい順）

accept-charset を付けたのに文字化けする: 送信側はUTF-8でも、サーバー側が別の前提でデコードしている可能性が高いです。「送信」と「受信」を分けて見直すと解決が早いです。
ページが古い文字コード運用のまま: ページ自体がShift_JISなどで運用されていると、入力・表示・送信が混ざって混乱しやすいです。可能ならページごとUTF-8へ寄せるのが安全です。
HTTPヘッダーやDB側がズレている: レスポンスのcharset、アプリの内部文字列、DBの照合順序など、どこかでズレると文字化けします。UTF-8統一のチェックリストを作ると強いです。
「似た名前の設定」をいじっていた: meta charset、Content-Type、accept-charset を混ぜると、どれが原因か分からなくなります。まず役割を分けて考えます。

セキュリティ視点の実務メモ（上級者向け）

文字コードは表示だけの話に見えて、実はセキュリティにも関わります。代表例は「デコードの不一致」です。

フィルタとアプリで解釈がズレる: WAFやミドルウェアが別の前提でデコードし、アプリがさらに別の前提で扱うと、フィルタの穴や誤判定につながります。
正規化の揺れで比較が壊れる: 見た目が同じでも別コードポイントになる文字（合成文字など）があり、同一判定やバリデーションが崩れることがあります。
ログや監視基盤の取り込みで壊れる: 想定外のバイト列がログに入ると、解析基盤や可視化が崩れることがあります。UTF-8統一と、入力値の検証・エスケープが重要です。

結論：入力はUTF-8として受け、サーバー側で一度検証し、表示・保存前に適切にエスケープするのが基本です。

よくある質問（FAQ）

accept-charset は必ず書いた方がいいですか？: UTF-8で統一できているサイトなら必須ではないことが多いです。ただ、フォーム送信の前提を明示したい、保守で迷いを減らしたい、レガシー環境で事故を減らしたい、という目的があるなら付ける価値があります。
複数の文字コード（例：UTF-8 Shift_JIS）は指定できますか？: 昔はそういう運用がありましたが、現代の実務ではUTF-8前提として扱うのが安全です。複数指定に期待しない方が事故りにくいです。
accept-charset を書いたのに文字化けします: 原因はサーバー側の受け取り（デコード）設定であることが多いです。「送った側」と「受け取る側」の文字コード前提が一致しているかを確認してください。
meta charset を入れれば accept-charset は不要ですか？: 役割が違います。meta charset はページの読み取り、accept-charset はフォーム送信です。ただし、現代はどちらもUTF-8に揃えるのが基本なので、結果として「両方UTF-8」になります。
JavaScriptで値を確認できますか？: form.acceptCharset で確認できます。ただし動的に変える必要がある場面は少ないので、基本はHTMLでUTF-8に揃える運用が安定します。

よくあるエラー・誤用早見表

日本語が「????」や「ã�“ã‚“ã�«ã�¡ã�¯」になる: 送信側と受信側のデコード前提が不一致。サーバーの受け取り設定を確認。
絵文字だけ保存できない／DBでエラーになる: DBの文字セットが絵文字対応（例：utf8mb4）になっていない可能性。
GET送信でURLが文字化けする: クエリ文字列のデコード設定や、ミドルウェア・ログ基盤側の扱いがズレている可能性。
accept-charset を変えても改善しない: 現代はUTF-8前提。原因がサーバー・DB・別の設定にある可能性が高い。