文字コード総合スレ Part12

**デフォルトの名無しさん** · 2018/12/17(月) 16:48:24.47

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/
　（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
　（隔離スレ）UnicodeとUTF-8の違いは？　その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.net/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.net/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.net/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 http://mevius.5ch.net/test/read.cgi/tech/1516629503/

**デフォルトの名無しさん** · 2021/02/24(水) 16:32:05.41

日本人が作る日本人のためのパソコンで
日本で使われている漢字が表示できないのは
マイナスでしかない。だからパソコン屋は
当初のSJISで定義されていた基本的な文字集合を超えた
文字を漢字ROMボードとして提供するしか道はなかった

そしてWindowsの時代となりフォントがOSに搭載されるようになってから
各メーカーが拡張していた漢字を相互運用できなくなるのは困るため
Microsoftは各拡張SJISを統合して改めてCP932として標準化した

もともとSJISを作ったのはMicrosoftなわけで
WindowsのSJISは、初期のSJISの正統後継といえる

**デフォルトの名無しさん** · 2021/02/24(水) 17:13:57.11

PC-98シリーズの漢字ROM、テキストVRAMはJISコードベースだ。SJISではない。

**デフォルトの名無しさん** · 2021/02/24(水) 18:38:57.51

PC-98のMS-DOSでShift_JISのファイルを何も問題なく開けたけど
漢字ROMがJISだとするとファイルを開く時にどこかでShift_JISからJISに変換していたという事？

**デフォルトの名無しさん** · 2021/02/24(水) 18:44:43.54

変換というかシフトしてる分を戻してるだけだな

**デフォルトの名無しさん** · 2021/02/25(木) 16:21:35.59

可変長で無限に文字を追加できる文字コードなると
全ての文字を実体参照で記録する形式にするしかないのでは？

**デフォルトの名無しさん** · 2021/02/25(木) 17:21:18.30

プレーンなgrepができなければ文字コード失格。
甲斐武田氏の家臣だけを抽出する正規表現クラス\p{KaiTakeda}みたいなのも使えなければダメ。

◆QZaw55cn4c · 2021/02/25(木) 19:01:31.51

>>574
VRAM が JIS ベースだ、という話というだけであって、ファイルが S-JIS だろうが UTF-16 であろうがどーでもいい話かと

**デフォルトの名無しさん** · 2021/02/25(木) 19:53:40.28

JISとSJISとEUC-JPの文字コードは
比較的単純な計算で変換することが出来るから
パフォーマンスの影響も少なくメモリも食わない

Unicodeの場合は変換にテーブルが必要になるから
MS-DOSの時代ではちょっと困るだろうな

**デフォルトの名無しさん** · 2021/02/26(金) 23:06:18.58

MS-DOS時代のテキストエディターで複数の文字コードに対応したものってあったんだろうか

**デフォルトの名無しさん** · 2021/02/27(土) 00:23:55.40

nemacsか

**デフォルトの名無しさん** · 2021/02/27(土) 03:48:22.68

単純計算だと非Unicode文字コード種ごとに128KBの変換テーブルが必要になる。
当時の揮発メモリに全部乗せたまま使うのは当然無理。LFUなりLRUなり使ってしのぐしかない。

◆QZaw55cn4c · 2021/02/27(土) 07:46:18.27

>>580
demacs/mule

**デフォルトの名無しさん** · 2021/03/03(水) 00:32:39.49

日本のsc2って今休業中なのかな
Unicode 14のalphaでKana Extended-Aに文字突っ込まれてるけどコメントしなくていいのか
このままbetaに進むと変更が難しくなりそうだけど

**デフォルトの名無しさん** · 2021/03/04(木) 21:20:40.72

ASCIIの制御文字にエスケープ文字(0x1b)や
その他の字の区切りを表す制御文字があるのに
メールでもHTMLでも制御文字は使わずに0x20-0x7eの印字可能文字の一部を
エスケープ文字として使うようになったのはなぜなのか

**デフォルトの名無しさん** · 2021/03/04(木) 22:12:23.62

ここで言うHTMLのエスケープ文字ってどれのこと？

**デフォルトの名無しさん** · 2021/03/04(木) 22:40:28.52

>>586
タグを示す<>や実体参照で使う&;

**デフォルトの名無しさん** · 2021/03/04(木) 23:10:32.38

その手の手書きする奴は図形文字じゃないと逆に不便じゃね？

**デフォルトの名無しさん** · 2021/03/04(木) 23:54:15.04

エスケープ文字に制御文字を使うと手で入力するのが面倒になるし
かといって図形文字を使うと文章中の文字と混同しないように注意しないといけなくなるから難しいか。
SJISの0x5c問題もこれが原因だよね。

**デフォルトの名無しさん** · 2021/03/05(金) 02:36:48.86

一言で言えば既存のテキストエディターで書けることを重視したから。
専用のハイパーテキスト用ツールは昔からあったけど不便だった。

**デフォルトの名無しさん** · 2021/03/05(金) 17:53:33.38

ISO系(特にUnicode)が理解できなさすぎて辛い・・・・・・
・古い規格は数万払って買えw
・原文英語だけど頑張って読めw
・1993年の初版からいーっぱい改定して規格書いーっぱいあるでw
・JIS 「こうやで(決してISO版原文の解説ではない)」
・UnicodeとISO/IEC 10646で同じ用語使ってますw
・規格書で定義されてない用語を平気で使いますw
・規格書にUCS-2, UCS-4の定義, 解説がない
・文献によってコードポイントの表記が微妙に違う
UCS-4はU+00000000のからなのか, U+0000からなのか？w
・UCS-2/4は符号化文字集合だぞwあっ、やっぱり文字符号化方式だぞw
・CJK 「俺らも理解してくれよなw」
・日本人　「Unicodeが理解できん？こうやで！^^(ソースなし！w)」

おれはUnicodeの理解を諦めたぞ・・・・・・

**デフォルトの名無しさん** · 2021/03/06(土) 02:52:41.34

まず unicode と ISO10646 は建前上は別の規格で用語も適用範囲も一致していないと理解することから。

**デフォルトの名無しさん** · 2021/03/06(土) 08:51:58.30

>>591
Unicodeは諦めるとして
次はPOSIXとC++のどちらに挑戦する？

**デフォルトの名無しさん** · 2021/03/06(土) 11:40:26.99

Unicode公式「ISOのUCS-4はUTF-32と同義語なんやでw」

おれ「UCSは符号化文字集合でUTF-32は符号化方式では？ムキーーーーーーッ？？！」

つらい
全てを投げ出して北海道グルメ旅行したい

**デフォルトの名無しさん** · 2021/03/06(土) 12:58:55.62

>>594
違うねん。
ISO10646 でも UCS-4 と UTF-32 は同じ意味で符号化方式やねん。
UCS: 符号化文字集合
UCS-4: 符号化方式
UTF-32: 符号化方式

ISO/IEC 10646:2017 の定義だと
9.4 UTF-32 (UCS-4)
UTF-32 (or UCS-4) is the UCS encoding form that assigns each UCS
scalar value to a single unsigned 32-bit code unit. The terms UTF-32
and UCS-4 can be used interchangeably to designate this encoding form.

**デフォルトの名無しさん** · 2021/03/06(土) 15:26:58.97

10646:2017だと明確に同義語として使われてたのか。
その版は持ってなくて中身確認できなかったから助かったわ

**デフォルトの名無しさん** · 2021/03/06(土) 15:41:25.54

マジで疲れた
UCS-4はUCSの部分集合だと思ってたけど実は違ったのかw
こんなことに悩んでたのかよクソすぎるw

**デフォルトの名無しさん** · 2021/03/06(土) 18:39:02.04

もしかして 10646:2020 を参照してん？なら UCS-4 という用語自体が過去の遺物扱いや。
10.4 UTF-32
UTF-32 is the UCS encoding form that assigns each UCS scalar value to a single unsigned 32-bit code unit.
NOTE — Former editions of this document included “UCS-4” as an alternate term synonymous with “UTF-32”. Use of the term “UCS-4” to refer to this encoding form is deprecated.

**デフォルトの名無しさん** · 2021/03/07(日) 12:36:06.36

あ、そこは見た
ただ10646:2020でいう「synonymous」が
どの程度の「同義」なのかが分からなかったけど
10646:2017を引用してくれたおかげで100％イコールなのが分かったわｻﾝｶﾞﾂな

**デフォルトの名無しさん** · 2021/03/07(日) 12:38:04.56

やっとこれでクソつまらん文字コードからC++の参考書に戻れる
やったぜ

**デフォルトの名無しさん** · 2021/03/07(日) 23:47:47.88

UTF (Unicode Transformation Format)という言葉も昔の遺産だよね
今作り直すならUnicode Encoding SchemeでUES-8とかになるのかな

**デフォルトの名無しさん** · 2021/03/08(月) 00:17:56.33

ちゃうねん。もともと UTF の U は unicode じゃなくて UCS や。Universal の U。

**デフォルトの名無しさん** · 2021/03/08(月) 11:33:52.88

文字コードという呼び方をなくして
文字シーケンスと言ったほうが良いと思う
1文字は最大8バイトで表現する

**デフォルトの名無しさん** · 2021/03/08(月) 12:58:27.48

EUCのU

**デフォルトの名無しさん** · 2021/03/08(月) 13:47:48.99

>>602
おおっと、これは失礼しました

**デフォルトの名無しさん** · 2021/03/08(月) 15:45:58.81

UTF-の後に続く数字は当初はバージョン番号のような意味だったのが
途中からビット数を表す意味に変わったようにも見える

**デフォルトの名無しさん** · 2021/03/08(月) 23:38:40.10

>>606
Unicodeの種別をUTF-なんとかと言い出したのは、1文字を16ビットで表現することに限界を感じたため。UTF-8は一番やりたくなかったけど、世界中の文字を切り替えて表現する方法は支持されなかったから、最小単位が8バイトのUTF-8が標準になった。

**デフォルトの名無しさん** · 2021/03/08(月) 23:41:28.57

SJISのように2バイトで表現するキャラクタセットとの相性を重視している場合はUTF-16が使われる。

**デフォルトの名無しさん** · 2021/03/09(火) 09:45:27.84

>>607
UTF-8が標準になったのはUnix系の互換性の問題
多バイト固定すると、文字列が1バイト前提であるC言語とC言語で作られてる
Unixのソースコードの多くを修正する必要があった。
そのため互換性があるUTF-8が作られた。

**デフォルトの名無しさん** · 2021/03/09(火) 11:10:37.15

>>609
EUCを知ってますか？

**デフォルトの名無しさん** · 2021/03/09(火) 11:13:42.05

>>610
EUCとUTF-8と同じようにC言語とC言語で作られてる
Unixのソースコードと互換性があるように作られたことを知ってますか？
そしてEUCがどうしましたか？

**デフォルトの名無しさん** · 2021/03/09(火) 17:39:10.59

キャラクタセットは選ぶもの

**デフォルトの名無しさん** · 2021/03/09(火) 17:40:37.43

アスキー文字は1バイトで同じ文字コードにしたいのはあたりまえ

**デフォルトの名無しさん** · 2021/03/09(火) 17:41:09.24

UTF-16にこだわったのは欧米人

**デフォルトの名無しさん** · 2021/03/09(火) 17:53:03.04

>>612
UTF-16を選べるというのなら選んでみるが良い
互換性がないキャラクタセットはサポートされていない

**デフォルトの名無しさん** · 2021/03/09(火) 19:47:21.10

UTF-16はユニコードの文学的表現と、あわしろ氏が言ってた。

**デフォルトの名無しさん** · 2021/03/09(火) 19:49:34.87

じゃあ間違いってことだな

**デフォルトの名無しさん** · 2021/03/09(火) 22:12:38.95

UTF-16 にこだわったわけじゃないだろ。
昔こだわってたのは16ビット固定長。
当時の非力なパソコンだと都合が良かった。

ワークステーションとか性能に余裕がある機械使ってる人たちから絶対に文字数足りなくなる阿呆仕様とか言われてたが、仕方なかった。

後に性能に余裕が出てきた時に既に16ビットでOSとかAPI設計・使用していたので、16ビット可変長を導入した。それが今のUTF-16。

**デフォルトの名無しさん** · 2021/03/10(水) 23:22:37.08

ISO/IEC 8859-1前提で作られていたはずなのに
いつの間にかUTF-8に乗り換えようとしてる？とうに乗り換えた？
WWW(のHTTP)の世界

**デフォルトの名無しさん** · 2021/03/15(月) 00:38:41.86

0x7Fだけでなく0xFFがDELとして定義されていないのは
0x80-0xFFに文字が定義された時には既に紙テープは使われなくなっていたという事なのかな

**デフォルトの名無しさん** · 2021/03/15(月) 08:07:57.71

その紙テープとDELの話、機能的に必要だからそうしたというわけじゃないと思うがな。
DELは「削除する」文字なのに紙テープは「削除された」文字になるよね。

**デフォルトの名無しさん** · 2021/03/15(月) 09:04:25.39

その 0x80-0xFF というのが 0xFF に文字を割当ててる ISO8859の時代ことなら、もう紙テープななんか使ってなかった。
それより古いの、例えば JISX0201 のカナとかの時代でもほぼ紙テープなんか使ってなかったけど 0xFF は未定義で文字は割当なかった。

**デフォルトの名無しさん** · 2021/03/16(火) 14:48:47.22

「削除する」というよりか「これは間違いだから無視してね」という印、みたいな感じ

**デフォルトの名無しさん** · 2021/03/16(火) 16:03:04.87

モールス信号は単音と長音の組み合わせだからビット表示みたいなもんかな

**デフォルトの名無しさん** · 2021/03/16(火) 21:56:06.00

へー、DELをバックスペースの意味で使うようになったのが後付けなのか。
https://ja.wikipedia.org/wiki/削除文字

**デフォルトの名無しさん** · 2021/03/18(木) 22:37:10.93

制御文字はASCIIコードの最初を占めているのにCUIでのコマンドに使わないのはもったいないと思う。
昔は制御文字をコマンドとして使っていたんだから
例えばSMTPは制御文字のSOH STX ETX EOTをコマンドにしてもよかったのでは

**デフォルトの名無しさん** · 2021/03/19(金) 00:35:37.02

あのう…、素人がひとつお尋ねしたいのですけど、よろしいですか？

大昔からWindowsパソコンを使っていて
今までにエディタで書いたテキスト資産をたくさん持つ人が
これからもWindowsパソコンを使い続けると仮定するなら
新しく書くテキストデータの文字コードは何を使えば良いのでしょう？

従来どおりShift-JIS？　それともUTF-8？
なお、テキストは書くだけではなく他人から貰ったデータを読むこともあります

**デフォルトの名無しさん** · 2021/03/19(金) 00:37:01.06

ゴメンなさい、最後の一文は
コピペしてテキストをマージすることもある、の意です

**デフォルトの名無しさん** · 2021/03/19(金) 01:21:48.92

Windowsは表面的にはシフトJISですが、内部はUTF-16です。

メモ帳がBOM付きUTF-8に対応したりとしているので、UTF-8でも特に問題ありません。

テキストエディタやOffice製品でSJISが使えなくなることは、想定しなくてもいいと思います。

**デフォルトの名無しさん** · 2021/03/19(金) 01:23:29.57

日本語の世界でSJISがなくなることは想定しなくてよいという意味です。

**デフォルトの名無しさん** · 2021/03/19(金) 06:55:45.01

>>627
UTF-8一択
絵文字も使えない文字コードなんて使えるか

**デフォルトの名無しさん** · 2021/03/19(金) 07:01:30.18

>>629->>630
有り難うございます、てことは…
別に今後もずっとSJISだけを使い続けて良い…という言い方もできますかね？

実はメールでテキストをやり取りする際、相手がHTMLメール使っていたりすると
なぜか「～」が文字化けしたり、しなかったり…、コピペの時に苦労しておるのです

**デフォルトの名無しさん** · 2021/03/19(金) 07:03:11.89

>>631
いや、絵文字は一生使うつもりがありませんｗ

**デフォルトの名無しさん** · 2021/03/19(金) 07:53:48.58

自分自身が絵文字を使うかどうかは重要じゃなくて、他人の書いた絵文字を含む文書を劣化させずに保存できることが重要

◆QZaw55cn4c · 2021/03/19(金) 08:22:24.74

>>631
絵文字は不要、誰が絵文字なんかを文字コードの中に押し込んだんだ？

**デフォルトの名無しさん** · 2021/03/19(金) 08:45:35.33

>>635
Appleだよ

https://ja.wikipedia.org/wiki/MacJapanese

**デフォルトの名無しさん** · 2021/03/19(金) 09:58:34.93

>>636
具体的にどれが?
一般的にはガラケーの各キャリアでは?

**デフォルトの名無しさん** · 2021/03/19(金) 13:03:56.18

最初にコード化したのは誰かって意味ならワープロメーカーとかじゃね？
unicodeに入れたのはgoogle。
その元になった絵文字セットのうちの1つを最初に作ったのはドコモ

**デフォルトの名無しさん** · 2021/03/19(金) 14:00:06.98

MSが何を考えているか外からではわからないけど
S-JISは切り捨てる可能性があるんじゃないかな

**デフォルトの名無しさん** · 2021/03/19(金) 14:15:07.57

>>639
「切り捨てる」の定義次第でしょ。
ゴールポストを動かすように定義を変えることもできる。

**デフォルトの名無しさん** · 2021/03/19(金) 15:26:48.13

>>633
macだとcuiでも絵文字使ってるプログラムが増えてて、見やすいしわりと便利よ

**デフォルトの名無しさん** · 2021/03/19(金) 16:19:10.35

Powerlineとかのプログラミング用の絵文字
あれUnicodeに入れてくれないかな？

◆QZaw55cn4c · 2021/03/19(金) 16:31:55.75

歩香桂銀金王角飛と杏圭全馬龍の逆さ文字は追加してほしいなぁ……

**デフォルトの名無しさん** · 2021/03/19(金) 17:45:59.37

Unicodeの絵文字は全世界で使われているからね。

**デフォルトの名無しさん** · 2021/03/19(金) 17:46:52.40

日本の絵文字がベースだから、日本人っぽいものが多い。

**デフォルトの名無しさん** · 2021/03/19(金) 18:07:03.09

>>643
文字を所定角度に回転させる異体字セレクタがいくつもあれば一番いいんだけど
30度ごとならアナログ時計の表現にも使えそう

**デフォルトの名無しさん** · 2021/03/19(金) 22:38:34.45

あのう…、皆さん色々ありがとうございます

それで…、結局のところ私は…、これから先テキストを新しく書いた時に
そのテキストデータの文字コードを何にして保存すれば良いのでしょうか？

**デフォルトの名無しさん** · 2021/03/19(金) 23:10:26.99

何回も何回も裏切られてきたからな
一寸先は闇
UTFが優勢ではあるけど
何があるかわからん

◆QZaw55cn4c · 2021/03/19(金) 23:12:46.09

>>647
BOM 付きUTF-8 でいいんじゃないでしょうか…

**デフォルトの名無しさん** · 2021/03/20(土) 00:19:36.84

異体字セレクタは無視可能だから>>643みたいな対比が重要な用途には向かん

**デフォルトの名無しさん** · 2021/03/20(土) 03:11:58.85

>>649
UTF8 に BOM はいらんだろ。(原理主義)

**デフォルトの名無しさん** · 2021/03/20(土) 03:46:25.95

>>647
文字コードはなんでもいいので、...を空文字列に置換してから保存してください

**デフォルトの名無しさん** · 2021/03/20(土) 04:03:35.66

>>651
627のwindowsでの質問なのでbom付きのが良い

**デフォルトの名無しさん** · 2021/03/20(土) 06:00:23.16

BOM付きはエラーの原因になったりするんだよね
647レベルだと恐らく原因にたどり着けない

**デフォルトの名無しさん** · 2021/03/20(土) 12:04:30.81

個人用なら UTF8一択でいいよ

ただし、以下が注意かな
1. 納品先、提出先の指定、プロジェクトでの指定があるなら合わせる
2. UTF8に対応していない古いツール類（エディタ含む）を使って処理しているなら合わせる

**デフォルトの名無しさん** · 2021/03/20(土) 13:21:00.17

>>654
エラーの原因になるというか、そのソフトがUTF8シグネチャに対応してないってだけだな。
結局のところ使うソフトや環境次第。
WindowsメインならUTF8シグネチャ付きの方がトラブルは少ないだろう。

**デフォルトの名無しさん** · 2021/03/20(土) 14:11:52.17

BOM なしUTF-8(UTF-8N)が良い

Windows と言っても、WSL でLinux を使うかも知れないから、
BOMを付けると、動かないかも

**デフォルトの名無しさん** · 2021/03/20(土) 14:43:30.24

winにはofficeとか、utf-8でもbomがないと化けるメジャーソフトもあるんだよなあ

**ID:pLBLA8wx** · 2021/03/20(土) 17:23:15.32

皆さん本当に色々とありがとうございました！

出てくる単語を片っ端からググって再確認しつつ、もっとも普遍的原理的な
考え方を自分の頭の中で屁理屈として組み立てあげました！

結論：これから私は、書いたテキストを原則UTF-8で保存する
　　　　 (→必要に応じてBOMをつけて保存し使うこともある)

本当に勉強になりました。２日で１０年分(か２０年分)勉強した感じですw。

**デフォルトの名無しさん** · 2021/03/20(土) 18:05:23.87

もつかれ

**デフォルトの名無しさん** · 2021/03/21(日) 02:58:59.19

UTF8はBOMがないのが正式。規格書嫁。
BOMが付くのは他の文字コードから変換の時に頭悪いソフトが削り損ねたか、
メモ帳のように文字コード対応が不完全なソフトが、独自の文字コード判別機能のために規格無視で突っ込んだ
くらい。

**デフォルトの名無しさん** · 2021/03/21(日) 08:53:26.10

BOMはオプション的な扱いだけど正式なRFCの仕様だが？
プロトコルとして文字コードを決め打ちする場合とか他の方法で文字コードを受け渡す
仕組みがある場合はBOMを使用すべきではないというくらい。
そもそも「文字コード対応が不完全なソフト」って、UTF-8決め打ちのソフトのことじゃね？

**デフォルトの名無しさん** · 2021/03/21(日) 10:07:00.18

>>661
UTF-8のBOMがなかったら以前の文字コード（日本だったらSJIS）とUTF-8の区別がつかないんだよ。
UTF-16やUTF-32なら1バイト単位で見た時にNULL文字が多数登場するという特徴があるが
UTF-8はバイト列をフルに使って詰め込んでるから区別することが不可能
UTF-8のBOMはUTF-8とそれ以外の文字コードを区別するための機能

昔は文字コードが自動判定できてたって？それはSJISとEUC-JPみたいに
バイト列をフルに使ってない文字コードかつ、日本語しか考慮してないから
できてたことなんだよ。UTF-8とそれ以外の文字コード判別は無理

◆QZaw55cn4c · 2021/03/21(日) 10:20:33.48

>>661
＞UTF8はBOMがないのが正式。規格書嫁。

であれば規格書（）にわざわざ UTF-8 のための BOM 0xEF 0xBB 0xBF が定義されているのは、なぜでしょうか？

**デフォルトの名無しさん** · 2021/03/21(日) 10:46:26.36

規格はちゃんと読めとしか。
例えば Unicode 13.0 での扱いは
1) U+FEFF は基本は Zero Width Non-Breaking Space
2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark
3) Unicode Signature としても使用できるが、プロトコルが型無しの場合に使用し、それ以外では使用を推奨しない
という扱いだ。1) と 2) と 3) は別の使い方だと理解するところから始めろ
UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)

UTF-16 から UTF-8 に変換する時は 1) の意味なら残す、2) の意味なら削る、3) の意味ならプロトコル次第。
不明ならば基本の 1) を仮定して残すのが正しい実装だ。

**デフォルトの名無しさん** · 2021/03/21(日) 11:32:14.01

>1) U+FEFF は基本は Zero Width Non-Breaking Space

「本来は～だった。」が正しいだろうな。
その意味で解釈するのはストリームの先頭以外に現れた場合に限るとされているし
今ではその意味でも使用すべきではないということになった。

>2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark

RFCで言う"BOM"にはバイトオーダーマークとシグネチャの両方の機能があって、
バイトオーダーマークとしての意味はUTF-16やUTF-32だけだけれども
シグネチャとしての意味はUTF-8でも有効だと書いてあるだろう。

**デフォルトの名無しさん** · 2021/03/21(日) 12:02:55.18

最新規格でも ZWNBS が正式。BOM は例外的な使用法。
「だった」って過去形で主張するんなら規格のどこに過去形書いてあるか、どの規格で廃止されたか示してみろ。
カタカナでバイトオーダーマークって書いても誤魔化せないぞ。

**ID:pLBLA8wx** · 2021/03/21(日) 13:46:50.50

けんかをやめて　二人をとめて
私のためにBOMで争わないで　もうこれ以上

**デフォルトの名無しさん** · 2021/03/21(日) 14:28:20.22

ああそうだな。文字の定義自体は変わっていないからその意味では過去形はおかしかったかな。
ただRFC3629では、今は同じ意味のU+2060があるからそっちを使うことを「強く推奨する」と。

**デフォルトの名無しさん** · 2021/03/21(日) 15:38:22.99

https://www.unicode.org/charts/PDF/UFE70.pdf
>may be used to detect byte order by contrast with the noncharacter code point FFFE
>use as an indication of non-breaking is deprecated; see 2060 instead
non-breakingとして使うのはdeprecatedだと言ってるし過去形でいいんじゃね
BOMとしての使い道だけが残った

**デフォルトの名無しさん** · 2021/03/21(日) 23:32:21.54

> UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)

Byte Order Markの意味わかってんのか？
UTF-8は1バイト単位で扱う文字列なんだから、2として使い方に
意味がないのは当たり前だろ。使えないというより意味がない
使っては駄目という意味じゃない。使ってもいいが本来の意味がないというだけだ。

16bitまたは32bitのときの順番を判断するためにあるのに
Byte（バイト） Order（順番） Mark（記号）

つまりU+FEFFは「文章のどこでも使っていい文字」で
先頭に来た場合に限りBOMとして解釈するというだけだ