一般用語
中級

UTF-8 (1992)(ユーティーエフエイト)

Ken Thompson と Rob Pike が 1992 年に Plan 9 OS のために設計し、1993 年に X/Open で発表された Unicode の 8bit 可変長エンコーディング。ASCII 完全互換・自己同期性・エンディアン非依存の特性で現代インターネット・OS・プログラミング言語の事実上世界標準となった。

0 回閲覧
0 いいね
2026/5/11 更新
関連タグ
UTF-8
Unicode
Ken Thompson
Rob Pike
Plan 9
RFC 3629

概要

UTF-8 (UCS Transformation Format - 8bit) は、Ken Thompson と Rob Pike が 1992 年 9 月に Plan 9 OS のために設計し、1993 年 1 月に X/Open で発表された Unicode の 8bit 可変長エンコーディングで、現代インターネット・OS・プログラミング言語の事実上世界標準となった重要な文字符号化方式です。1-4 バイト可変長で全 Unicode (16 億字) を表現可能、ASCII 範囲 (0-127) は 1 バイトで完全互換、日本語等の CJK (中国・日本・韓国) 統合漢字は 3 バイトで効率的に圧縮。自己同期性 (バイト列の途中から正しい文字境界を判定可能)・エンディアン非依存 (バイト順問題なし)・ASCII 完全互換の優れた特性により、Shift_JIS・EUC-JP・UTF-16 などの先発エンコーディングをすべて置き換え、HTML5 (2014)・JSON (2006)・Linux ディストリビューション (2005 年頃から)・macOS (2001 年以降)・Python 3 (デフォルト)・Web 標準として 2010 年代以降に完全確立しました。

主な特徴・仕組み

  • 設計者: Ken Thompson (B 言語・UNIX 共同開発者)・Rob Pike (Plan 9・Go 言語共同開発者)
  • 設計年: 1992 年 9 月 (Plan 9 OS 向け)、1993 年 1 月 X/Open 発表
  • 標準化: RFC 3629 (2003)・ISO/IEC 10646
  • バイト数: 1-4 バイト可変
  • ASCII 互換: 0-127 範囲は 1 バイト・ASCII と完全同一
  • 2 バイト範囲 (U+0080-U+07FF): 80h-DFh で開始、ラテン拡張・ギリシャ・キリル等
  • 3 バイト範囲 (U+0800-U+FFFF): E0h-EFh で開始、CJK 統合漢字・日本語等
  • 4 バイト範囲 (U+10000-U+10FFFF): F0h-F7h で開始、絵文字・新規 Unicode 拡張
  • 自己同期性: バイト列の任意位置から文字境界判定可能
  • エンディアン非依存: UTF-16 と異なり BE/LE 区別なし
  • BOM: U+FEFF (EFh BBh BFh) で UTF-8 識別可能 (推奨されない)

スペック比較表

エンコーディングASCII 互換バイト数エンディアン普及度
ASCII完全1B不要基盤
UTF-8完全1-4B不要現代標準
UTF-16不可2-4BBE/LE 区別Windows 内部
UTF-32不可4BBE/LE 区別内部処理
Shift_JIS部分1-2B不要日本レガシー

具体例・対応技術

  • Plan 9 OS (1992): UTF-8 初実装、ベル研究所
  • Linux ディストリビューション (2005-): ja_JP.UTF-8 ロケール標準
  • macOS (2001-): HFS+/APFS で UTF-8 ファイル名標準
  • HTML5 (2014): UTF-8 推奨、<meta charset="utf-8">
  • JSON (2006): RFC 4627、UTF-8 必須
  • Python 3 (2008-): 文字列内部 Unicode、ソースコード UTF-8 デフォルト
  • Go 言語 (2009-): ソースコード UTF-8 必須

自作PCでの選び方・注意点

UTF-8 は 2026 年現在の事実上世界標準で、新規開発はすべて UTF-8 が原則です。Windows 11 でも「Region settings > Administrative > UTF-8 for worldwide language support」で有効化可能、Visual Studio Code・JetBrains IDE のデフォルトも UTF-8。Web 開発 (HTML5・JSON・REST API)・データベース (PostgreSQL の UTF8・MySQL の utf8mb4)・Git リポジトリすべて UTF-8 が標準。Python/JavaScript/Go/Rust など現代プログラミング言語は UTF-8 をネイティブサポート。注意点として、Windows レガシーシステム (cmd.exe・PowerShell の CP932 デフォルト・Excel の VBA・古い Visual Studio) では文字化けが発生、chcp 65001 で UTF-8 切替、BOM 付き UTF-8 ファイル保存・PowerShell 7+ への移行が必要です。データインポートで Shift_JIS/EUC-JP/CP932 ファイルを扱う場合 iconv -f cp932 -t utf-8 file.txt で変換、これは現代エンジニアの必須スキルとなっています。

関連用語との違い

  • UTF-16: 2-4 バイト、Windows 内部、エンディアン区別あり
  • UTF-32: 4 バイト固定、内部処理向け、ファイル保存非効率
  • Shift_JIS/EUC-JP/CP932: レガシー、UTF-8 で完全置換中

よくある質問(FAQ)

Q1: UTF-8 の最大の長所は? A: ASCII 完全互換・自己同期性・エンディアン非依存・全 Unicode 対応の組合せ。これにより既存 ASCII システムを段階的に UTF-8 化可能、グローバル普及した。

Q2: BOM は付けるべき? A: 一般的に「付けない」が推奨。UTF-8 にエンディアン区別はなく BOM 不要、付けると一部の古いシステム (Linux スクリプト・PHP・MySQL) で問題発生。Windows メモ帳が BOM 付加する点で混乱の元凶。

Q3: UTF-16 との使い分けは? A: UTF-8 はファイル・ネットワーク (Web・JSON・メール)、UTF-16 は OS 内部処理 (Windows API・Java/JavaScript の内部文字列)。アプリでは UTF-8 出力が原則。

まとめ

  • UTF-8 = 1992 年 Thompson/Pike 設計、Unicode 可変長エンコーディング
  • ASCII 完全互換・1-4 バイト・自己同期・エンディアン非依存
  • HTML5/JSON/Linux/macOS の世界標準、2010 年代に完全確立
  • Windows レガシー (CP932) を置き換え中、文字化け解決の鍵
この記事について
カテゴリー一般用語
難易度中級
作成日2026/5/11