ノート:UTF-8

UTF-8の先頭バイトについて

C0-C1は確かに使われませんが、E0,F0が使われないという事実はありません。RFC 3629を見てください。またC0-C1を使うことが不正になったRFC 3629では5バイト以上の表現も不正になったので、5バイト以上の表現が含まれている現行の説明に対してRFC 3629の規則を当てはめるのもおかしな話です。そもそも4バイト表現があるものとないもの、重複符号化が認められているものといないものを区別せず渾然一体に書いている現在の説明がかなりアレなのですが、とりあえず明らかな誤りは差し戻させていただきました。--emk 2008年4月28日 (月) 09:21 (UTC)[返信]

UTF-8#エンコード体系の表は書き直した方がいいですね。0xc0はUTF-8には使われませんし、U+200000以上のコードはサポートされていないはず。en:UTF-8のような構成にした方がいいのかな。。。--bcxfu75k 2010年2月5日 (金) 08:18 (UTC)[返信]

たしかに、0xC0の使用は最短シーケンスのみを認めるという規約に反しますね。書き直すべきです。構成を英語版と同様にし、変種 (Javaの0xC0 0x80やPerlの64ビットまでの拡張など) についても軽く触れればいいとおもいます。 --Hatukanezumi 2010年2月6日 (土) 03:17 (UTC)[返信]

返信

賛成明示的にen:UTF-8#Overlong encodingsに触れた方がベターですね。--Wint7（会話） 2021年12月29日 (水) 07:46 (UTC)[返信]

2010年2月20日 (土) 16:08 (UTC) の編集について

2010年2月20日 (土) 16:08 (UTC) により編集された部分を戻しました。根拠なくBOM付きのUTF-8を推奨するかのような編集であるからです。例えば、「RFC3023の『XML Media Types』において、XMLをUTF-8で符号化する場合は先頭にBOMをつけることを推奨しており」とありますが、RFC 3023を探してみても該当する記述はありません。

UTF-8におけるBOMは、相互運用性の問題を引き起こすことがあり、通常のUTF-8のほうがBOM付きのものより信頼性が高いです。また、BOMと呼ばれてはいますが、バイト順を表すものではなく、慣例的にそう呼ばれているに過ぎません。（en:UTF-8#Byte order markより）--謎の魔人X 2010年4月30日 (金) 04:48 (UTC)[返信]

修正しました。JISの標準情報(TR) TR X 0015:2002でもそのように訳されてましたね。--122.220.1.166 2010年5月1日 (土) 14:59 (UTC)[返信]

RFC 3032のどの箇所に、UTF-8において「XMLの解析プログラムにおいては、<?xmlの後のencodingが指定されていない場合は、先頭にBOMを参照して符号化を判別することを求めている」の出典となる記述があるのか具体的に抜き出して頂けないでしょうか。説明をお願いします。

先程の繰り返しになりますが、BOMがないとUTF-8と認識できないプログラムが「存在する」を「多い」に変える、UTF-8Nの呼称が一般的でないことを脚注に持って行くなど、他にも根拠なくBOM付きのUTF-8を推奨する編集であると考えます。通常のUTF-8の方が信頼性が高く推奨されるべきです。また、ノートページで戻した理由を書いているのに、コメント欄で理由なきrv、とされるのは心外であります。--謎の魔人X 2010年5月3日 (月) 16:06 (UTC)[返信]

Hatukanezumiさんが記述を訂正しました。私もHatukanezumiさんがコメント欄で書かれているのと同意見で、UTF-16のBOMのことではないかと思っています。また、UTF-8Nの呼称が一般的でないことを脚注から復帰させておきました。--謎の魔人X 2010年5月5日 (水) 06:17 (UTC)[返信]

RFC 3023よりは、参照されております、XMLの規格Extensible Markup Language (XML) 1.0のF Autodetection of Character Encodings (Non-Normative)に明記されておりますね。

BOMがないとUTF-8と認識できないプログラムが多いというのは、事実だと思うのですが。

エディタや文字コード変換プログラムなどUTF-8を含む文字コードに対応していたとしても、文字コードを指定せずにファイルにアクセスした場合BOMがない場合は自動でのUTF-8であるとの判別に失敗するプログラムはかなりの数存在しますよ。

通常のUTF-8の方が信頼性が高いとされる根拠を示してください。BOMがあればその時点でUTF-8だということが確定できます。もし、UTF-8でBOMがなく、誤った文字コードだと判別して解析した場合はセキュリティ上の信頼性が低くなると思うのですが。--122.220.1.166 2010年5月8日 (土) 14:19 (UTC)[返信]

あどうも。わたしの編集の要約欄の「ZWSP」は「ZWNBSP」のまちがいです。でコメント。

XML 1.0のAppendix Fはおっしゃるとおりnon-normativeですから、「こうしないといけない」といったものではありません。

RFC 3023では、要約欄に書いたとおり、BOMに言及するときはUTF-16のBOMのことを言っています。具体例を挙げると、3.1 Text/xml registrationの「Magic number」では

Although no byte sequences can be counted on to always be present, XML MIME entities in ASCII-compatible charsets (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml").

と書いてあります。要約すると「〔XML文書は〕UTF-8などを使っていると “<?xml” で始まることが多い。UTF-16ではその前にBOMがつくことも多い」ということです。

信頼性について。RFC 3629の6章「Byte Order Mark (BOM)」では、この「非公式な」(unofficial) シーケンスの解釈に曖昧さが存在しうることを指摘しています。テキストデータ中に、テキストの一部であるかないかの解釈が分かれる情報が含まれるわけですから、情報交換が適切に行われない可能性があります。そこで、同章ではつぎの場合を区別して規定しています。

プロトコルがUTF-8を常に必須とする (...the protocol mandates to be always UTF-8) 場合
プロトコルがキャラクタ符号化方式の識別機構を提供する (...the protocol provides character encoding identification mechanisms) 場合
プロトコルがキャラクタ符号化方式の識別機構を提供しないか、禁止に強制力を持たせられないか、プロトコルの実装が機構を正常に利用できるとは限らない (...the protocol does not provide character encoding identification mechanisms, when a ban would be unenforceable, or when it is expected that implementations of the protocol will not be in a position to always use the mechanisms properly) 場合

で、前ふたつの場合はBOMシーケンスを禁止すべき (SHOULD)、最後の場合は禁止すべきではない (SHOULD NOT) としています。これが、UTF-8#バイト順マーク節の最後の段落に書いてあることですね。 --Hatukanezumi 2010年5月9日 (日) 00:51 (UTC)[返信]

（インデントを戻します）Hatukanezumiさん、信頼性について文献をありがとうございます。あまり長くなるのが嫌なので、重複するコメントはしません。

Extensible Markup Language (XML) 1.0の該当箇所を読みました。必要箇所だけ簡単に要約しておきます。

外部の情報でエンコーディングを判断出来ない場合は、XMLのエンコーディング宣言を読み取る前に、エンコーディングをある程度判断する必要がある。（そもそもエンコーディングが分かってないとエンコーディング宣言も読めないので）この時、XMLでは先頭数バイトを見ることで判断できる。判断表がBOMありの時となしの時で分けて図示されてます。判断によってエンコーディングがひとつに確定した場合でも、エンコーディング宣言が存在するなら、つき合わせて正当性を確認すること。

件の出典にはならないと思います。

BOMがないとUTF-8と判別できないプログラムが多いかどうかについて、個人的には、存在するとは思いますが、そこまで多くないような気がします。とはいえ、主観ですし、多いということを書きたいならばやはり出典が必要でしょうね。ちゃんと言えば存在することについても出典が要るのですが、存在する出典を出してくるのはそんなに難しいことではないのでとりあえず残しておいていいでしょう。--謎の魔人X 2010年5月9日 (日) 03:25 (UTC)[返信]

参戦します。

「BOMがないとUTF-8と判別できないプログラムが多いかどうか」 について。

「多い」という表現を「過半数である」という意味で使うのは明確に誤りです。そもそも集計対象とする母集団がどのくらい大きいのか分からないのですから。
一方で、テキストファイルの読み書きでは、BOMをつけると誤動作するアプリ、逆にBOMがない場合にはShift_JIS として解釈しようとするアプリのどちらもあります。これは既に記事中に記載されていますね。

↑最初の文面から少々差し替えました。

「通常のUTF-8の方が信頼性が高く推奨されるべきです。」

これを主張するためには「信頼性が高い」という単語自体の定義から始めて、次に、その定義による「信頼度」の定量的測定手順を設定しないといけませんよ。そして、BOMあり・なしのどちらを選べば信頼度100%が達成できるかというと、答えは「どちらでも永久に不可能」です。従って、この主張は本文に入れるべきではないと考えます。

--Delmonta_Iijima（会話） 2019年1月17日 (木) 06:14 (UTC)[返信]

2010年6月5日 (土) 14:30 (UTC) の編集について

UTF-8においてBOMをつけて送信することを義務付けているプロトコルがあるとの記述ですが、提示されている出典には

UTF-8 によってデータを転送する場合、バイト順マーク(Byte Order Mark)は用いない。

とあります（118ページ）。また、RFC 3629まわりの記述もかえって分かりにくくなっているように感じました。そのため当該の記述を差し戻しました。

記事の編集とは関係ないことになりますが、122.220.1.166さんにはUTF-8におけるBOMは無い方が良いものということを理解して頂きたいです。

例えば、UTF-8で書かれたテキストが0xEFBBBFで始まっていたら、UTF-8のBOMなのかZWNBSPなのか判定できません。多くのテキストエディタではこれをBOMとみなすでしょうが、既に指摘されているとおり、UTF-8であることが明示されているプロトコルではZWNBSPと扱うことになり、例えばHTMLですと先頭に空白が入ったりする問題が起きることがあります。こういった相互運用性の問題について英語版Wikipediaでも述べられていますね（残念ながら出典はついていないようですが）。

確かにBOMがついていないとUTF-8と認識できないプログラムもあるのですが、BOMが無いものも正しいUTF-8と認められていますから、これをUTF-8と認識できないプログラムはUTF-8に完全に対応してない、ということになるでしょう。それはプログラムをBOMなしでも認識できるよう修正すべきなのです。--謎の魔人X 2010年6月5日 (土) 16:58 (UTC)[返信]

RFC 3629の箇所は規定のまま文にしたのですが……。どうわかりづらいのかがわかりません。

謎の魔人Xさんの話は少し矛盾しているような気がします。

そのまま逆も言えて、UTF-8で書かれたテキストが0xEFBBBFで始まっていたら、UTF-8のBOMであることを解釈できないプログラムもUTF-8に完全に対応してない、ということになるでしょう。それはプログラムをBOMありでも認識できるよう修正すべきなのです。

どちらも書くかどちらも書かないかのいずれかにすべきであって、一方だけ書くのは恣意的です。両ケースがあることは事実なのであって、この場合は両方を書くことのほうがよいのではないかと思います。

U+FEFFをZWNBSPとして使用することは最新のバージョンでは（とはいってもだいぶ前からですが）Deprecatedなのですが。

昨今では、BOMをつける方向に進んでおり、HTML5ではUTF-8を使用する目的でBOMをつけて判別することができることが明示されていますよ。--122.220.1.166 2010年6月5日 (土) 18:56 (UTC)[返信]

すみませんが、RFC3629 6章を通読してください。ややこみいっていてわかりにくいかもしれません。簡単にまとめますと……。

UTF-8に準拠するといっても、どんな状況でどんな処理を期待するかによって、\xEF\xBB\xFFの解釈はちがってきます。

このシーケンスを必須とするのなら、送信側はこれを付加するべきで、受信側はこれを無視しなければなりません。
このシーケンスを必須としないのなら、送信側はこれを付加するべきではなく、受信側はこれをデータの一部とみなさなければなりません。

あなたが主張する「送信側はこのシーケンスを付加してもしなくてもよく、受信側ではこのシーケンスを適宜データの一部とみなさないで無視する」というような、定義があいまいな動作は、このRFCでは許されていないのです。

また、「昨今では、BOMをつける方向に進んでおり」ということを主張したいようですが、これまでに示された論拠・出典はいずれも、UTF-8でのこのシーケンスのことを言っていなかったり、付けることと付けないことを併記していたりと、主張を裏づけるものではありませんでした。

まあそもそも「UTF-8のBOM」なんて表現からして形容矛盾なわけですが、そういうものを一部の有力ベンダが多用した時期がありまして、それでいろいろな規格でもUTF-8にかかわる規定を述べなければならなくなっている、ということはありますよね。「言及の回数が多い」ということと「このシーケンスは必須のものとして規定されている」ということとは、ちがいます。

それと、記事の編集について討論をするのはよいことですが、続けて議論をするのならアカウントを取得して、ログインしてやってください。Wikipedia:説明責任なんかもお読みください。 --Hatukanezumi 2010年6月5日 (土) 23:16 (UTC)[返信]

ビットパターン表の見やすさ改善

UTF-8#エンコード体系のビットパターン表がとてもみづらかったので、下記対策をしました。

ブラウザの横幅が狭いと、各セルの文字列が折り返されてみづらいので、nowrap追加。
デフォルトフォントだと「yyyy」に対応する下のセルのフォントがずれるので、等幅フォントにしました。
「U+0800 … U+FFFF」「U+00200000 … U+03FFFFFF」「U+04000000 … U+7FFFFFFF」の列は、「yyyy」に対応する下のセルのビット位置がずれていたので「text-align:right」追加。

以上。--bcxfu75k 2011年4月6日 (水) 11:18 (UTC)[返信]

記事を英語版の翻訳で置き換えることについて

現在の記事の内容は英語版のものと比べて不備と不足が多くあり、また英語版は少なくとも大きな間違いは見受けらず内容も詳しいため、英語版のものを翻訳したものにしたいと考えます。3日か一週間ほど待って反対がなければ時間のある時に行おうと思うのですがいかがでしょうか。--Sumilzumie（会話） 2018年8月10日 (金) 06:16 (UTC)[返信]

参戦します。大枠はそれでも構わないと思いますが、2点ほど要望させてください。

Wikipedia日本語版の翻訳記事全般に当てはまることですが、日本語として極端に読みにくい文体、あるいは {{誤訳}} をつけたくなるような直訳そのままの記事がまま見られます。なので、いちばん最初に行うべき「見出しの差替と、それに伴う既存文面の順序入れ替え」とか、あるいは「純粋な追加になる部分」とかは見切り発車で本番ページに投入してあとから修正するのがいいと思いますが、既存の文章を差し替える部分は逆に慎重を期していただきたいです。
漢字圏の事情に関する記載、特に既存の各種文字セット（具体的には ①Shift_JIS；②G0とG1のみのEUC各種；③Big5；④EUCを拡張したGBK/GB18030/拡張KS等；あたりでしょうか）とのメリット・デメリット比較について具体例を交えた記載は、日本語版OSのユーザに向けて記事を書く以上、絶対に必要と考えます。こちらは本決まりになれば私も協力できるかもしれません。

--Delmonta_Iijima（会話） 2019年1月17日 (木) 05:27 (UTC)[返信]

こちら、どうなりましたでしょうか? 興味あるのですが、状況がわからないとなんとも。鍋太郎（会話） 2020年2月10日 (月) 05:40 (UTC)[返信]