developer-tools

Unicode、UTF-8と文字エンコーディング：すべての開発者が知るべきこと

robinhood-projects3 分で読める

Base64エンコード・デコード

テキストやバイナリデータをBase64にエンコードし、Base64文字列をプレーンテキストにデコードします。ブラウザ内で即座に処理。

ツールを使う →

JSONビューア・フォーマッター・エディター

リアルタイムのインタラクティブツリーでJSONを表示・編集・フォーマット。インライン値編集、キー名変更、ノードの追加/削除、JSONCコメントのサポート、ワンクリックエクスポート — すべてブラウザ内で動作。

ツールを使う →

URLエンコード・デコード

クエリ文字列で安全に使用するためにURLをパーセントエンコードするか、エンコードされたURLをプレーンテキストに戻します。

ツールを使う →

Unicode、UTF-8と文字エンコーディング：すべての開発者が知るべきこと

Webフォームから名前をコピーしたら、データベースにéとして保存された。ExcelでCSVを開くとアクセント付き文字がすべて間違っている。ユーザーがテキストフィールドに絵文字を貼り付けたら、MySQLのINSERT全体が謎めいたエラーで失敗した。ExcelがCSVを正しく読めるようにBOMをファイルに追加したら、シェルスクリプトが最初の行で壊れた。

これらはすべて文字エンコーディングのバグです。症状がランダムに見えるため、開発者が直面しうる最も混乱させる問題のひとつです——同じ文字列があるコンテキストでは正しく表示され、別のコンテキストでは化けてしまう。原因はほぼ常に同じです：2つのソフトウェアがバイトを文字に対応させる方法で一致していない。

このガイドはその対応を根本から説明します：文字エンコーディングとは何か、UnicodeとUTF-8はどのように機能するか、そして現実のよくあるバグをどのように診断して修正するか。

Unicode以前の時代：ASCIIと拡張ASCIIの混乱

コンピューターに保存されるすべての文字は究極的には数値です。文字エンコーディングは数値を文字に対応させ、逆も然りとするルックアップテーブルです。

最初に広く採用されたエンコーディングはASCII（American Standard Code for Information Interchange）で、1963年に発表されました。ASCIIは7ビットを使用し、128のスロット（0–127）があります。英語の大文字・小文字、10桁の数字、一般的な句読点、そして改行やタブのような33の非印刷制御文字をカバーします。

128文字は英語には十分ですが、フランス語、ドイツ語、スペイン語、アラビア語、中国語、日本語、あるいは世界の何千もの他の書記言語には到底足りません。

拡張ASCIIの問題

バイトの8番目のビットが利用可能で、128のスロット（128–255）が追加されました。異なる組織やオペレーティングシステムがそれらのスロットを異なる方法で埋めようと競い合いました：

  • Windows-1252（CP1252とも呼ばれる）：Microsoft WindowsがわたがEuropeで使用。é、ñ、€などの文字を上半分に配置。
  • ISO-8859-1（Latin-1）：西ヨーロッパ言語の国際標準。Windows-1252と大幅に重複しますが完全には一致しません——範囲128–159はLatin-1では制御文字ですが、Windows-1252では印刷可能な文字です。
  • ISO-8859-5：キリル文字をカバー。
  • ISO-8859-6：アラビア文字をカバー。
  • Shift JIS、EUC-JP、Big5：東アジア言語の完全に異なるマルチバイト方式。

結果として、あるシステムで作成されたファイルは、両方が同じエンコーディングに合意しない限り、別のシステムでは文字化けして表示されました——そしてファイルがどのエンコーディングを使用しているかを知らせる信頼できる方法がありませんでした。ソフトウェアは推測し、そして常に間違って推測しました。

これがUnicodeが解決するために作られた問題です。

Unicode：すべての言語のための統一文字セット

Unicodeはエンコーディングではありません。文字セットです——使用されているすべての書記体系のすべての文字に一意の数値を割り当て、さらに何千ものシンボル、絵文字、歴史的な文字体系を含む巨大なルックアップテーブルです。

そのテーブルの各エントリをコードポイントと呼び、U+の後に16進数で表記します。いくつかの例：

文字コードポイント説明
AU+0041ラテン大文字A
éU+00E9アキュート・アクセント付きラテン小文字e
中U+4E2DCJK統合漢字（zhōng）
😀U+1F600笑顔の絵文字
𝄞U+1D11E音楽記号ト音記号

Unicode標準は現在14万以上の文字を定義しており、定期的に更新されています。

Unicodeの面（プレーン）

Unicodeのコードポイントはu+0000からU+10FFFFまで、100万を少し超えるスロットを提供します。その空間は65,536のコードポイントを持つ17の面に分けられます。

  • 第0面 — 基本多言語面（BMP）： U+0000からU+FFFF。今日一般的に使用されるほぼすべての文字を含む：ラテン文字、ギリシャ文字、キリル文字、アラビア文字、ヘブライ文字、CJKなど。
  • 第1面 — 補助多言語面（SMP）： U+10000からU+1FFFF。絵文字、歴史的な文字体系、音楽記号。
  • 第2–16面： 追加のCJK統合漢字、珍しい歴史的文字体系、未割り当て空間。

MySQLのテーブルを壊す絵文字は第1面に存在します。このことはすぐに重要になります。

UTF-8：Unicodeが実際にどのように保存されるか

Unicodeは各文字がどの数値を取得するかを定義します。それらの数値をディスクやメモリ上のバイトとして保存する方法は指定しません。それがUnicodeエンコーディングの役割です。

UTF-8はウェブと現代的なソフトウェアで最も広く使用されているUnicodeエンコーディングです。可変幅であり、文字によって使用するバイト数が異なります：

コードポイント範囲使用バイト数ここに住んでいるもの
U+0000 – U+007F1バイトASCII（全128文字）
U+0080 – U+07FF2バイト拡張ラテン文字、ギリシャ文字、キリル文字、アラビア文字、ヘブライ文字
U+0800 – U+FFFF3バイトほとんどのCJK文字、BMPの残り
U+10000 – U+10FFFF4バイト絵文字、珍しい文字体系

UTF-8バイトシーケンスの仕組み

UTF-8は自己同期型です。任意の文字の最初のバイトは後続のバイト数を教えてくれます：

  • 0xxxxxxx — 1バイト文字（ASCII）。有効なASCIIファイルはすべて有効なUTF-8です。
  • 110xxxxx 10xxxxxx — 2バイト文字。
  • 1110xxxx 10xxxxxx 10xxxxxx — 3バイト文字。
  • 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx — 4バイト文字。

継続バイトは常に10で始まるため、任意のバイトが新しい文字の始まりなのか、ある文字の途中なのかを即座に判断できます。これにより部分的なストリームを読んだ後の再同期が可能になります。

具体的な例 — é（U+00E9）のエンコード：

U+00E9の2進数は11101001で、2バイト範囲に入ります。テンプレート110xxxxx 10xxxxxxは11000011 10101001——バイト0xC3 0xA9——を生成します。これがUTF-8がéのために格納する内容です。

なぜUTF-8が主流なのか

UTF-8には勝利をもたらした3つの特性があります：

  1. ASCII互換性。 純粋にASCIIのファイルはすべて有効なUTF-8です。既存システムの移行で、非ASCII内容のないファイルを変更する必要がありませんでした。
  2. ラテン文字のスペース効率。 英語テキストはASCIIと同様に1文字1バイトを使用します。ASCII以外の文字だけがより多くのバイトを使います。
  3. バイト順序の曖昧さがない。 バイト構造はヘッダーなしで明確です。（バイト順序マークを必要とするUTF-16と比較してください。）

UTF-16とUTF-32：いつ遭遇するか

UTF-8はUnicodeエンコーディングの唯一の選択肢ではなく、一部の環境では他のものを使用します。

UTF-16はBMP文字を2バイト（1つの16ビットコード単位）でエンコードし、補助面の文字を4バイト（2つの16ビットコード単位、サロゲートペアと呼ばれる）でエンコードします。WindowsのSQL、Javaの文字列、JavaScriptの文字列（エンジンレベル）、.NETの文字列はすべて内部でUTF-16を使用しています。

UTF-32は常に正確に1文字4バイトを使用します。スペースを浪費しますが、文字インデックスによるランダムアクセスを非常に高速にします。一部のデータベース内部でも使用されています。

バイト順序マーク（BOM）

UTF-16にはエンディアン問題があります。2バイトシーケンスはビッグエンディアン（Aでは0x00 0x41）またはリトルエンディアン（0x41 0x00）で格納できます。受信側はどちらの順序が使われたかを知る必要があります。

解決策はバイト順序マークです：コードポイントU+FEFFがファイルの先頭に置かれます。UTF-16ビッグエンディアンではFE FFとして現れ、UTF-16リトルエンディアンではFF FEとして現れます。どちらかを見た読み取り側はバイト順序を知ります。

UTF-8には技術的にもBOM（EF BB BF）がありますが、UTF-8にはバイト順序の曖昧さがないため意味がありません。これが問題を引き起こす場所です：

  • ExcelとCSVファイル。 ExcelはUTF-8 BOMをCSVをUTF-8として解釈するシグナルとして使用します。それがないと、Excelはシステムのロケールエンコーディング（多くの場合Windows-1252）をデフォルトにし、アクセント付き文字が壊れます。多くの開発者はExcelを正しく動作させるためだけにBOMを追加します。
  • シェルスクリプト。 #!/bin/bashで始まるシェルスクリプトは、その最初のバイトにその文字列が必要です。UTF-8 BOMがシェバンに先行する場合、カーネルはEF BB BF 23 21を見てシェバンを認識できず、スクリプトが失敗するか誤ったインタープリターで実行されます。

経験則：Excel向けCSVファイルにはBOMを追加し、シェルスクリプトやJSONファイルには絶対に追加しない。

現実によくある文字化けバグ

文字化け：UTF-8をLatin-1として読む

文字化け（Mojibake）はエンコーディングの不一致によって引き起こされる文字の乱れを表す日本語の用語です。現代のウェブで最も一般的な変種：UTF-8文字列がLatin-1（ISO-8859-1またはWindows-1252）であるかのように読まれる。

éという文字はU+00E9です。UTF-8では2バイト0xC3 0xA9として格納されます。プログラムがこれらの2バイトをLatin-1として読む場合、2つの別々の文字として見ます：0xC3はÃで、0xA9は©です。文字列caféがcaféになります。

この特定の破損パターン——éがéに、èがèに、àがà に——はUTF-8がLatin-1として解釈されている兆候です。最もよく見られる場所：

  • 挿入時に接続文字セットがUTF-8に設定されていなかったデータベース。
  • 古いメールサーバーを通じて送信されたメール。
  • ロケール設定が一致しないシステム間でコピーされたファイル。

修正方法は不一致が発生する場所を特定し、そのレイヤーでエンコーディング宣言を修正することです——破損した文字列を事後にパッチするのではなく。

代替文字（U+FFFD）

デコーダーが期待されるエンコーディングでは無効なバイトシーケンスに遭遇すると、何かをしなければなりません。Unicode標準は代替文字U+FFFD（<0xFFFD>と表示）を代わりに入れることを推奨します。出力に?ボックスや<0xFFFD>文字が見える場合、デコーダーは解釈できないバイトに遭遇しています。

一般的な原因：

  • マルチバイトUTF-8シーケンスの切り捨て。3バイトのCJK文字の内部に落ちるバイト境界で文字列を切った場合、部分的なシーケンスは無効です。
  • Latin-1でエンコードされたファイルを厳格なUTF-8デコーダーに渡す。
  • エンコーディングが混在するソースからデータを受け取る。

MySQLのutf8対utf8mb4：絵文字の問題

これはWeb開発で最もよく知られたエンコーディングのバグのひとつです。MySQLにはutf8とutf8mb4という名前の2つの文字セットがあります。

MySQLのutf8は本物のUTF-8ではありません。U+FFFFまでのコードポイントのみをサポートします——厳密には基本多言語面だけです——1文字につき最大3バイトを使用します。絵文字は第1面（U+10000以上）に存在し、4バイトを必要とします。utf8として定義された列に4バイトのUTF-8文字を挿入しようとすると、MySQLは静かに値を切り詰めるかエラーをスローします。

utf8mb4は4バイトを完全にサポートする本物のUTF-8です。絵文字やその他の補助面の文字を処理するために具体的に導入されました。

正しいアプローチ：新しいテーブルとデータベースには常にutf8mb4を使用してください。接続文字セットと照合順序も明示的に設定してください：

ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

アプリケーションの設定で接続パラメーターを設定してください：

charset=utf8mb4

MySQLでutf8を使用するのは古い落とし穴です。非推奨として扱ってください。

Pythonにおける文字列長と文字数

Python 2はデフォルトで文字列をバイトシーケンスとして格納していました。UTF-8文字列のlen("café")は——éは2バイトを占めるため——4ではなく5を返しました。正しいマルチバイト処理には、明示的なu""ユニコードリテラルと慎重なエンコード/デコードが必要でした。

Python 3はこれを修正しました：strはUnicodeコードポイントのシーケンスなので、len("café")は4を返します。バイトデータは明示的な.encode()と.decode()呼び出しを持つbytes型に移動しました。

しかし微妙な点がひとつ残っています。Python 3のlen()はコードポイントを数え、書記素クラスターを数えません。éという文字は単一のコードポイント（U+00E9）として表現することも、e（U+0065）とアキュートアクセント（U+0301）の組み合わせとして表現することもできます。両方同じにレンダリングされますが、異なるlen()値を生成します。ユーザーに文字数を公開する多言語アプリケーションは、生のlen()ではなくUnicode分割ライブラリを使用すべきです。

多言語文字列を含むJSONデータを調べると、これに気づくかもしれません——単一の文字のように見えるものが内部では2つのコードポイントである可能性があります。

エンコーディング比較表

エンコーディング最大文字数ASCII文字のバイト数絵文字のバイト数一般的な文脈
ASCII1281N/Aレガシーシステム、プロトコルヘッダー
Latin-1 (ISO-8859-1)2561N/A西ヨーロッパのレガシーテキスト
Windows-12522561N/AレガシーWindowsドキュメント
UTF-81,114,11214Web、Linux、macOS、最新のAPI
UTF-161,114,11224Windows、Java、.NET、JavaScriptエンジン内部
UTF-321,114,11244一部のDB内部、テキスト処理
MySQL utf8~65,5361壊れているレガシーMySQLカラム——避けること
MySQL utf8mb41,114,11214MySQL——これを使用

エンコーディング問題の検出と修正方法

検出

Pythonで：

import chardet
 
with open("mystery_file.txt", "rb") as f:
    raw = f.read()
 
result = chardet.detect(raw)
print(result)  # {'encoding': 'Windows-1252', 'confidence': 0.73, 'language': ''}

chardetライブラリはバイトパターンからエンコーディングを推測するために統計分析を使用します。信頼スコアは誠実です——エンコーディング検出はヒューリスティックであり、決定論的ではありません。

ブラウザで： DevToolsを開き、ネットワークタブに移動し、HTMLページのレスポンスを見つけ、Content-Typeヘッダーを確認します。text/html; charset=utf-8と表示されるはずです。存在しないか間違っている場合、ブラウザは推測し、多くの場合は間違えます。

データベースで： データベース、テーブル、カラムレベルで文字セットを確認します：

SHOW VARIABLES LIKE 'character_set%';
SHOW CREATE TABLE posts;

文字化けしたデータベースの修正

データがUTF-8で挿入されたがLatin-1として格納された場合（よくある移行の間違い）、回復できることがあります：

-- 破損したデータをバイナリとして読み取り、その後UTF-8として解釈
UPDATE posts
SET body = CONVERT(CAST(CONVERT(body USING latin1) AS BINARY) USING utf8mb4)
WHERE body REGEXP '[Ã]';

これは元のバイトが損なわれておらず、単に誤ったラベルが付いていた場合にのみ機能します。データが本当に破損していた場合——バイトが削除または置換された場合——バックアップなしの回復は不可能です。

予防

  • 常にエンコーディングを明示的に宣言してください。デフォルトに絶対に頼らないでください。
  • すべてのHTMLドキュメントに<meta charset="UTF-8">を設定してください。
  • APIレスポンスにContent-Type: application/json; charset=utf-8を設定してください。
  • データベース接続を開くときに接続文字セットを指定してください。
  • エディターでUTF-8を使用し、テキストファイルに対してそれを強制するようにバージョン管理システムを設定してください。

文字セットを超えたエンコーディングタスク——バイナリデータをテキストセーフな表現に変換するなど——には、FileCrankのテキストのエンコード/デコードツールがセットアップなしでBase64変換を処理します。必要であれば、既存のエンコーディング記事はBase64、URLエンコーディング、HTMLエンティティをカバーしています。設定ファイルを扱っており、多言語文字列が正しく見えることを確認する必要がある場合は、ブラウザで直接JSONデータを調べることができます。

まとめ

文字エンコーディングのバグが謎めいて感じられるのは、障害モード——文字の乱れや欠落——が実際の原因から遠く離れたところに現れるためです。しかし根本的なメカニズムは単純です：2つのプログラムが異なるルックアップテーブルを使用してバイトを文字に変換しています。

この3つのルールを常に意識してください：

  1. 常にUTF-8を至る所で使用する ——特定のシステムが他のものを強制する場合を除いて。明示的に設定し、デフォルトに頼らない。
  2. MySQLではutf8mb4を使用する ——utf8ではなく。ユーザーが絵文字を送信した瞬間に違いが重要になる。
  3. 文字化けを見たら境界を見つける。 バイトがそのエンコーディングを知らないシステムを通過する場所を探す。そのポイントで宣言を修正し、下流の症状を修正しない。

メカニズムを理解する——コードポイント、バイトシーケンス、エンコーディング宣言——ことで、推測の代わりに新しいエンコーディングバグを体系的に分析できます。次に出力でéを見たとき、何が起きたのか、どこを見ればいいのかが即座にわかります。

すべてのFileCrankツールはブラウザの中で完全に動作します。ファイルはサーバーにアップロードされません。多言語コンテンツを含むテキストを扱っている場合は、JSONビューアまたはBase64エンコード/デコードツールを試してください——どちらも設定なしでUnicodeを正しく処理します。