(Translated by https://www.hiragana.jp/)
UTF-8 - Wikipedia
Wikipedia

UTF-8

符号ふごう単位たんいを既定きていしたUnicode文字もじ符号ふごう化か形式けいしき及および文字もじ符号ふごう化かスキーム

UTF-8（ユーティーエフはち、ユーティーエフエイト）はISO/IEC 10646 (UCS) とUnicodeで使つかえる8ビット符号ふごう単位たんい（1–4バイトの可変長かへんちょう）の文字もじ符号ふごう化か形式けいしきおよび文字もじ符号ふごう化かスキーム。

正式せいしき名称めいしょうは、ISO/IEC 10646では “UCS Transformation Format 8”、Unicodeでは “Unicode Transformation Format-8” という。両者りょうしゃはISO/IEC 10646とUnicodeのコード重複じゅうふく範囲はんいで互換ごかん性せいがある。RFCにも仕様しようがある[1]。

2バイト目め以降いこうに「/」などのASCII文字もじが現あらわれないように工夫くふうされていることから、UTF-FSS (File System Safe) ともいわれる。旧きゅう名称めいしょうはUTF-2。

UTF-8は、データ交換こうかん方式ほうしき・ファイル形式けいしきとして一般いっぱん的てきに使つかわれる傾向けいこうにある。

当初とうしょは、ベル研究所けんきゅうじょにおいてPlan 9で用もちいるエンコードとして、ロブ・パイクによる設計せっけい指針ししんのもと、ケン・トンプソンによって考案こうあんされた[2][3]。

エンコード体系たいけい 編集へんしゅう

ASCII文字もじと互換ごかん性せいを持もたせるために、ASCIIと同おなじ部分ぶぶんは1バイト、その他たの部分ぶぶんを2–6バイトで符号ふごう化かする。4バイトのシーケンスでは21ビット (0x1FFFFF) まで表現ひょうげんすることができるが、Unicodeの範囲はんい外がいとなる17面めん以降いこうを表あらわすもの（U+10FFFFより大おおきなもの）は受うけ付つけない。

また、5–6バイトの表現ひょうげんは、ISO/IEC 10646による定義ていぎ[4]とIETFによるかつての定義ていぎ[5]で、Unicodeの範囲はんい外がいを符号ふごう化かするためにのみ使用しようするが、Unicodeによる定義ていぎ[6]とIETFによる最新さいしんの定義ていぎ[7]では、5–6バイトの表現ひょうげんは不正ふせいなシーケンスである。

後述こうじゅつのセキュリティの項こうに詳細しょうさいはあるが、符号ふごう化かは最少さいしょうのバイト数すうで表現ひょうげんしなければならない。そのため、バイト数すうごとにUnicodeの符号ふごう位置いちの最小さいしょう値ち（下限かげん）も設もうけている。

例たとえば、1バイトで表現ひょうげんするASCII文字もじは2バイト以上いじょうでも表現ひょうげんできるが、バイト数すうごとの下限かげんによってこれを回避かいひしている。

ビットパターンは以下いかのようになっている。

バイト数すう 有効ゆうこうビット Unicode 2進数しんすう表記ひょうき 16進数しんすう表記ひょうき
1 07 bit 0xxx-xxxx 00..7F
下限かげん U+0000 0000-0000 00
上限じょうげん U+007F 0111-1111 7F
2 11 bit 110y-yyyx 10xx-xxxx C2..DF 80..BF
下限かげん U+0080 1100-0010 1000-0000 C2 80
上限じょうげん U+07FF 1101-1111 1011-1111 DF BF
3 16 bit 1110-yyyy 10yx-xxxx 10xx-xxxx E0..EF 80..BF 80..BF
下限かげん U+0800 1110-0000 1010-0000 1000-0000 E0  80* 80
上限じょうげん U+FFFF 1110-1111 1011-1111 1011-1111 EF  BF* BF
4 21 bit 1111-0yyy 10yy-xxxx 10xx-xxxx 10xx-xxxx F0..F4 80..BF 80..BF 80..BF
下限かげん U+10000 1111-0000 1001-0000 1000-0000 1000-0000 F0  80* 80 80
上限じょうげん U+10FFFF 1111-0100 1000-1111 1011-1111 1011-1111 F4  BF* BF BF

* 第だい1バイトがE0のときに第だい2バイトが80-9Fの範囲はんいを、または同どうF0のときに80-8Fの範囲はんいを取とるものは冗長じょうちょうな符号ふごう化かとなるため許ゆるされない。第だい1バイトがEDのときに第だい2バイトがA0以上いじょうとなるものはサロゲートペアのための符号ふごう位置いちにあたり、また同どうF4のときに90以上いじょうとなるものはUnicodeの範囲はんい外がいとなるため、UTF-8ではやはり許ゆるされない。

Unicodeの符号ふごう位置いちを2進しん表記ひょうきしたものを、上うえのビットパターンのx, yに右みぎ詰づめに格納かくのうする（最少さいしょうのバイト数すうで表現ひょうげんするため、yの部分ぶぶんには最低さいてい1回かいは1が出現しゅつげんする）。符号ふごう化かされたバイト列れつは、バイト順じゅんに関かかわらず左ひだりから順じゅんに出力しゅつりょくする。

1バイト目めの先頭せんとうの連続れんぞくするビット "1"（その後ごにビット "0" が1つ付つく）の個数こすうで、その文字もじのバイト数すうがわかるようになっている。また、2バイト目め以降いこうはビットパターン "10" で始はじまり、1バイト目めと2バイト目め以降いこうでは値ねの範囲はんいが重かさならないので、文字もじ境界きょうかいを確実かくじつに判定はんていできる。すなわち、任意にんいのバイトの先頭せんとうビットが "0" の場合ばあいは1バイト文字もじ、"10" の場合ばあいは2バイト以上いじょうの文字もじの2番目ばんめ以降いこうのバイト、"110" の場合ばあいは2バイト文字もじの先頭せんとうバイト、"1110" の場合ばあいは3バイト文字もじの先頭せんとうバイト、"11110" の場合ばあいは4バイト文字もじの先頭せんとうバイトであると判定はんていできる。

7バイト以上いじょうの文字もじは規定きていされないため、0xFE, 0xFFは使用しようされない。このため、バイト順じゅんマーク (BOM) に0xFEと0xFFを使用しようするUTF-16やUTF-32が、UTF-8と混同こんどうされることはない。

特徴とくちょう 編集へんしゅう

利点りてん 編集へんしゅう

  • ASCII文字もじコードのテキストを処理しょりするソフトウェアの多おおくがそのまま使つかえる[8]。
  • バイトストリーム中ちゅうの任意にんいの位置いちから、その文字もじ、前まえの文字もじ、あるいは次つぎの文字もじの先頭せんとうバイトを容易よういに判定はんていすることができる。
  • 文字もじ列れつの検索けんさくを単たんなるバイト列れつの検索けんさくとして行いっても、文字もじ境界きょうかいと異ことなる個所かしょでマッチしてしまうことがない。たとえばShift_JISで「¥」(0x5C) を検索けんさくすると「表ひょう」(0x95 0x5C) の2バイト目めにマッチしたり、EUC-JPで「海うみ」(0xB3 0xA4) を検索けんさくすると「ここ」(0xA4 0xB3 0xA4 0xB3) にマッチしたりするのと同様どうようのことが起おきない。このため、マルチバイト文字もじを意識いしきせず、ISO 8859-1などの8ビット文字もじ向むけに作つくられた膨大ぼうだいなプログラム資産しさんを、比較的ひかくてき少すくない修正しゅうせいで再さい利用りようできる。
    • ただし、他たのUnicodeの符号ふごう化かと同様どうように、単たんにバイト列れつの比較ひかくでは文字もじ列れつが同一どういつか判断はんだんできない場合ばあいがある。詳細しょうさいは、Unicodeの等価とうか性せいおよび正規せいき化かを参照さんしょうのこと。
  • UTF-16やUTF-32と異ことなり、バイト単位たんいの入出力にゅうしゅつりょくを行おこなうため、バイト順じゅんの影響えいきょうがない。
  • 21ビットまで表現ひょうげんできるため、サロゲートペアを使用しようする必要ひつようがない。
  • ASCII文字もじが主体しゅたいの文書ぶんしょであれば、ほとんどデータサイズを増ふやさずにUnicodeのメリットを享受きょうじゅできる。UTF-16やUTF-32では、データサイズはほぼ2倍ばい、4倍ばいとなる。
  • 複数ふくすうのUTF-8文字もじ列れつを、単たんなる符号ふごうなし8ビット整数せいすうの配列はいれつとみなして辞書じしょ順じゅんソートした結果けっかは、Unicodeの符号ふごう位置いちの辞書じしょ順じゅんのソート結果けっか（すなわちUTF-32に変換へんかんした後のちにソートした結果けっか）と等ひとしくなる。これに対たいして、サロゲートペアを含ふくむUTF-16文字もじ列れつを符号ふごうなし16ビット整数せいすうの配列はいれつとみなしてソートした結果けっかは、Unicodeの符号ふごう位置いちの辞書じしょ順じゅんのソート結果けっかと異ことなりうる。

欠点けってん 編集へんしゅう

  • UTF-8による符号ふごう化かでは、漢字かんじや仮名かめいなどの表現ひょうげんに3バイトを要ようする。このように、東ひがしアジアの従来じゅうらい文字もじコードではマルチバイト符号ふごうを用もちいて1文字もじ2バイトで表現ひょうげんされていたデータが、1.5倍ばいかそれ以上いじょうのサイズとなる。同様どうように、ISO/IEC 8859-1では1バイトで表現ひょうげんできた非ひASCIIのラテン文字もじ（ウムラウト付つきの文字もじなど）も2バイトとなるし、その他たのISO/IEC 8859シリーズに属ぞくする文字もじ符号ふごうではデータ量りょうがさらに増大ぞうだいしうる。
    • なお、1バイトが9ビットである処理しょり系けいでは、この問題もんだいをあまり発生はっせいさせずに符号ふごう化かできるはずである。このアイディアに基もとづいたジョークRFCがRFC 4042 "UTF-9" として2005年ねんのエイプリルフール（4月がつ1日にち）に公開こうかいされた。
  • 最短さいたんではない符号ふごうやサロゲートペアなど、UTF-8の規格きかく外がいだがチェックを行おこなわないプログラムでは一見いっけん正常せいじょうに扱あつかわれるバイト列れつが存在そんざいする。これらのバイト列れつを入力にゅうりょくとして受うけ入いれてしまうと、プログラムが予期よきしない範囲はんいのデータを生成せいせいするため、セキュリティ上じょうの脅威きょういとなりうる[9]。

サロゲートペアの扱あつかい 編集へんしゅう

UTF-16ではサロゲートペアで表あらわされるような、基本きほん多言たげん語ご面めん外そとの符号ふごう位置いちをUTF-8で表あらわす時ときは、変換へんかん元もとがUTF-16でサロゲートペアの時ときには U+D800–U+DBFF, U+DC00–U+DFFF を表あらわすUTF-8にそのまま変換へんかんしたりはせず、U+10000–U+10FFFF の符号ふごう位置いちにデコードしてから変換へんかんする。そのままUTF-8で符号ふごう化かしたような列れつは不正ふせいなUTF-8とされる。

サロゲートペアのままUTF-8と同等どうとうの符号ふごう化かを行おこなう符号ふごう化かは、CESU-8 (Compatibility Encoding Scheme for UTF-16: 8-Bit) として別途べっと定義ていぎされている。実用じつように供きょうされている例れいとしては、Oracle Databaseのバージョン8以前いぜんにおいて、UTF-8として3オクテットまでのオクテット列れつしか扱あつかえなかったために定義ていぎされたものである。本来ほんらいのUTF-8における4オクテット列れつの代かわりに、サロゲート符号ふごう位置いちを表あらわす3オクテット列れつのペア（上位じょういが ED A0 80–ED AF BF、下位かいが ED B0 80–ED BF BF）で表現ひょうげんされる。

現在げんざいのOracle Databaseでも、CESU-8を「UTF8」として、「普通ふつうのUTF-8」を「AL32UTF8」として扱あつかっているため注意ちゅういを要ようする。MySQLでも「utf8」を指定していした場合ばあいは4オクテット列れつが扱あつかえず、CESU-8相当そうとうの符号ふごう化かを必要ひつようとする（4オクテット列れつ対応たいおうのUTF-8は「utf8mb4」として別途べっと定義ていぎされているが、MySQL 5.5.3以降いこうでないと使用しようできない[10]）。

また、Javaの一部いちぶの内部ないぶ実装じっそうで用もちいられているModified UTF-8も、サロゲートペアをそのまま残のこす仕様しようとなっている。ただし、NULL文字もじをC0 80とエンコードする（これもUTF-8規格きかく外がい）点てんで、CESU-8とも異ことなる実装じっそうとなっている。

セキュリティ 編集へんしゅう

UTF-8のエンコード体系たいけいには冗長じょうちょう性せいがあり、同おなじ文字もじを符号ふごう化かするのに複数ふくすうの表現ひょうげんが考かんがえられる（例れい: スラッシュ記号きごうである「/」を 0x2F という1バイトで表現ひょうげんするのではなく、0xC0 0xAF という2バイトもしくはそれより大おおきなバイト数すうで表現ひょうげんする）。かつてはそのような表現ひょうげんも許容きょようされていたが、ディレクトリトラバーサルなどの対策たいさくとして行おこなわれる文字もじ列れつ検査けんさを冗長じょうちょうな表現ひょうげんによりすり抜ぬける手法しゅほうが知しられるようになったため、現在げんざいの仕様しようでは最少さいしょうのバイト数すうによる表現ひょうげん以外いがいは不正ふせいなUTF-8シーケンスとみなさなければならない[11]。

ISO/IEC 10646の定義ていぎが5バイト以上いじょうの表現ひょうげんを許容きょようしていることにより、正ただしくない実装じっそうを行おこなったバグのあるシステムにおいてエンコード時じにバッファオーバーフローが発生はっせいする可能かのう性せいも指摘してきされている。

文字種もじしゅ 編集へんしゅう

B Unicode スクリプト JIS X 0201 JIS X 0208 JIS X 0212 JIS X 0213
1 U+0000–U+007F ASCII Roman（円えん記号きごう・オーバーライン以外いがい）      
2 U+0080–U+07FF
円えん記号きごう 非ひ漢字かんじの一部いちぶ 非ひ漢字かんじの一部いちぶ 非ひ漢字かんじの一部いちぶ
3 U+0800–U+FFFF
オーバーライン、Kana 残のこりの全すべて 残のこりの全すべて 大半たいはん
4 U+10000–U+10FFFF 古代こだい文字もじ、3に含ふくまれない漢字かんじ       第だい3・第だい4水準すいじゅん漢字かんじの一部いちぶ

バイト順じゅんマークの使用しよう 編集へんしゅう

UTF-8で符号ふごうされたテキストデータはバイト順じゅんマーク (BOM) の付加ふかは不要ふようである（エンディアンに関かかわらず同おなじ内容ないようになるので）。

しかし、テキストデータがUTF-8で符号ふごう化かされていることの標識ひょうしきとして、データの先頭せんとうにEF BB BF（16進しん。UCSでのバイト順じゅんマーク U+FEFFのUTF-8での表現ひょうげん）のシーケンスをBOMとして付加ふかすることが許ゆるされる（推奨すいしょうはされない）。

  • この３バイトは、ZERO WIDTH NON-BREAKING SPACE を表あらわすが、データ先頭せんとうではバイト順じゅんマークの機能きのうを持もたせている。
  • なお、日本にっぽんの特殊とくしゅ事情じじょうとして、このシーケンスがある方ほうをUTF-8、ない方ほうを特とくにUTF-8Nと呼よび分わけることもあるが[12]、日本にっぽん以外いがいではほとんど知しられておらず、また公的こうてき規格きかくなどによる裏付うらづけもない[13]。

プログラム・アプリケションソフトの対応たいおう状じょう況きょうの問題もんだい 編集へんしゅう

BOM付つきには対応たいおうしないプログラムは標準ひょうじゅん的てきではある。それらは、BOMを余分よぶんなデータとみなすので、問題もんだいも生しょうずる。

例たとえば、Unix系けいOSにおける実行じっこう可能かのうスクリプトは、ファイル先頭せんとうが「#!」から始はじまるとき、それに続つづく文字もじ列れつをインタプリタのコマンドとして認識にんしきするが、多おおくのシステムでは、このシーケンスが存在そんざいするとこの機能きのうが働はたらかず実行じっこうできない。PHPでは、<?PHPの前まえに出力しゅつりょくされるため、header()関数かんすうの実行じっこうに失敗しっぱいする原因げんいんとなる。HLSLやGLSLのシェーダープログラムコンパイラ（fxcやglslangValidator）はBOMを処理しょりできず、コンパイルエラーとなる。

一方いっぽう、一部いちぶのテキスト処理しょりアプリケーション（テキストエディタなど）ではBOMを前提ぜんていとした動作どうさをする[14]。同様どうようにこのシーケンスがない場合ばあい、UTF-8と認識にんしきできないプログラムも存在そんざいする。たとえば、Microsoft Excelでは、CSVファイルを開ひらくとき、このシーケンスが付加ふかされていないUTF-8の場合ばあいは正常せいじょうに読よみ込こむことができず文字もじ化ばけを生しょうずる[15]。Microsoft Visual C++は既定きていでBOMなしUTF-8を認識にんしきせず、システムロケール設定せっていに応おうじたマルチバイトエンコーディングとみなすが、Visual C++ 2015以降いこうではコンパイルオプションを指定していすることでBOMなしUTF-8を認識にんしきすることができるようになった[16]。 Windows 10のメモ帳ちょうアプリは、2019年ねんの19H1アップデートからBOM無なしUTF-8がデフォルトになった[17]。

また、BOMがなくともエンコード自動じどう推定すいていによってUTF-8とShift_JISなどを区別くべつすることのできるプログラムもあるが、ASCII部ぶ以外いがいの文字もじが少すくない場合ばあいに誤認ごにんすることが多おおい。

プロトコルが常つねにUTF-8であることを強制きょうせいしているものである場合ばあいはこのシーケンスを禁止きんしするべきで、この場合ばあいファイル先頭せんとうにこのシーケンスが現あらわれると “ZERO WIDTH NO-BREAK SPACE” と見みなされる。逆ぎゃくにプロトコルがそれを保証ほしょうしない場合ばあいこのシーケンスは禁止きんしされずファイル先頭せんとうのそれはバイト順じゅんマークと見みなされる[18]。

脚注きゃくちゅう 編集へんしゅう

[脚注きゃくちゅうの使つかい方かた]
  1. ^ RFC 3629 UTF-8, a transformation format of ISO 10646
  2. ^ RFC 3629 Page-3
  3. ^ Rob Pike's UTF-8 history
  4. ^ ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS)
  5. ^ RFC 2279 UTF-8, a transformation format of ISO 10646
  6. ^ The Unicode Standard, Version 5.2
  7. ^ RFC 3629 UTF-8, a transformation format of ISO 10646
  8. ^ ただし、バイト順じゅんマーク (BOM) が付加ふかされている場合ばあいや、テキストを7ビットで処理しょりするソフトウェア、内部ないぶ的てきに最さい上位じょういビットを使用しようしているソフトウェアなど、使つかえないものも存在そんざいする
  9. ^ RFC 3629, pp.9f.
  10. ^ “10.1.10.6 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)”. dev.mysql.com. MySQL 5.5 Reference Manual. Oracle. 2015年ねん12月1日にち02:10:55時じ点てんのオリジナルよりアーカイブ。2015年ねん12月11日にち閲覧えつらん。
  11. ^ Windowsにおける有名ゆうめいなワームであるNimdaウイルスは、IISにおけるUTF-8の脆弱ぜいじゃく性せいをもちいたものである。(はせがわようすけ 2009)
  12. ^ Mark Davis. “Forms of Unicode” (英語えいご). IBM. 2005年ねん5月がつ6日にち時点じてんのオリジナルよりアーカイブ。2013年ねん9月がつ18日にち閲覧えつらん。
  13. ^ このため、UTF-8という呼よび名なを使つかっていれば情報じょうほう交換こうかんの相手あいてが文書ぶんしょ先頭せんとうにこのシーケンスがあると見みなすと期待きたいすべきではないし、また、UTF-8Nという呼よび名なは情報じょうほう交換こうかんの際さいに用もちいるべきではない。
  14. ^ TeraPad、EmEditor、MIFESのようにBOMを付加ふかするかどうかを選択せんたくできるものもある。
  15. ^ マイクロソフト・サポート https://support.microsoft.com/en-us/office/opening-csv-utf-8-files-correctly-in-excel-8a935af5-3416-4edd-ba7e-3dfd2bc4a032
  16. ^ /source-charset (Set Source Character Set) | Microsoft Docs
  17. ^ “「メモ帳ちょう」に多数たすうの改善かいぜん、BOMなしUTF-8がデフォルト保存ほぞん形式けいしきに ～「Windows 10 19H1」”. Impress. 2023年ねん1月がつ26日にち閲覧えつらん。
  18. ^ RFC 3629 6. Byte order mark (BOM)

参考さんこう資料しりょう 編集へんしゅう

関連かんれん項目こうもく 編集へんしゅう

「https://ja.wikipedia.org/w/index.php?title=UTF-8&oldid=100419626」から取得しゅとく