文字コード総合スレ 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/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として解釈するというだけだ

**デフォルトの名無しさん** · 2021/03/23(火) 08:39:38.88

Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?
http://www.unicode.org/faq/utf_bom.html#bom5

Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream.
UTF-8 always has the same byte order. An initial BOM is only used as a signature - an indication that an otherwise unmarked text file is in UTF-8.
Note that some recipients of UTF-8 encoded data do not expect a BOM.
Where UTF-8 is used transparently in 8-bit environments,
the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning,
such as the use of "#!" of at the beginning of Unix shell scripts.

**デフォルトの名無しさん** · 2021/03/28(日) 20:48:56.89

そもそも全く意味も機能も異なるZERO WIDTH NO-BREAK SPACEとBYTE ORDER MARKを
U+FEFFという単一のコードポイントに統合した馬鹿は何処の誰なん？

**デフォルトの名無しさん** · 2021/03/29(月) 10:11:40.65

>>673
英語よめないの？

ZERO WIDTH NO-BREAK SPACE（幅がない改行をしないスペース）
BOMは幅があるか？ないだろ
改行するか？しないだろ

BOMが途中に出てくることがあるか？
その場合どうすればいいんだ？
無視する＝幅がなくて改行しないスペースだろ

**デフォルトの名無しさん** · 2021/03/29(月) 16:21:58.12

落ち着け
ZWNBS は無視しちゃ駄目だよ。そこで自動改行禁止というマークなので、ちゃんと処理しないと駄目。

**デフォルトの名無しさん** · 2021/03/29(月) 17:07:30.02

>>675
自動改行禁止の意味わかってるか？
無視する＝そこに文字がないのと同じように扱うから
自動改行も禁止なんだよ

BOMとZERO WIDTH NO-BREAK SPACEを同じにしたと言うより
BOMはZERO WIDTH NO-BREAK SPACEと同じ動きをする文字だということ

**デフォルトの名無しさん** · 2021/03/29(月) 21:25:17.42

あまり文字コード関係ないけど笑ったので貼っとく

https://twitter.com/ryancdotorg/status/1375484757916672000
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2021/03/30(火) 02:24:24.90

>>676
嘘をつくな。
BOM は内部コードに変換する時に取り除くべき文字。制御コードとしての機能はない。
ZWNBS は内部コードでも残り制御コードとして前後の文字を一体として接続し、その間での改行を禁止する意味を持つ。

**デフォルトの名無しさん** · 2021/03/30(火) 02:31:28.79

>>678
だからそのBOMが文書の内部に出てきたら
どう処理するんだよって話なんだが

データに絶対入らないように誰かが制限してるか？
バイナリエディタを使っても入れることが出来ないか？
入っていたら落ちたほうがいいか？

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

>>679
寝ぼけっての？
文章の途中に来たら BOM じゃないよ。

**デフォルトの名無しさん** · 2021/03/30(火) 05:29:26.08

>>680
だからバイナリエディタでBOMと同じコードを文章中に入れたものを
読み込んだら、どういう挙動をするべきかって話をしてるんだが

制御コードとして前後の文字を一体として接続し、その間での改行を禁止する意味を持たせたほうがいいだろうね

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

持たせたほうがいいも何も、規格上はそういう意味だよ。
バイナリ・エディタで入れようが、テキスト・エディタで入れようが ZWNBS として扱う。

もともと規格では
U+FEFF は制御コードとして ZERO WIDTH NO-BREAK SPACE としての機能を持つ。(その場所での分割を禁止する)
そしてこれが、UTF-16, UTF-32 ストリームの先頭に来た場合には Byte Order Mark (エンディアンの指定)という特別な機能を持つ
さらに先頭の BOMは Unicode Signature (その文章が Unicode で書かれている印)として使用できる。
この先頭の U+FEFF は制御コードとしての機能はないので処理の際には取り除け。
先頭に U+FEFF が二つ続いた場合は一つ目は BOM で、二つ目は ZWNBS として解釈せよ。
UTF-16LE や UTF-16BE などのようにエンディア決め打ちの文字コードや、他の方法でエンディアンが指定されている場合は、先頭にあっても ZWNBS で BOM ではない。
ファイルを結合する時とか、そのままつなぐと、後ろにファイルの先頭の U+FEFF が ZWNBS として解釈されるので取り除くのを忘れんな
その後の改訂で
やっぱ使ってみると、同じコードポイントに複数の機能があるのはややこしいので U+2060 WORD JOINWER ってのを作った。
この WORD JOINER は ZWNBS と全く同じ機能だけど、BOM としては使うことができない。制御コードには今後はこっちを使うのを強く推奨。
でも歴史的な経緯と過去の資産があるから、文章の途中に出てくる U+FEFF は、これまでどおりの意味で解釈せよ。

**デフォルトの名無しさん** · 2021/03/31(水) 01:51:23.09

asciiの0-32までってc記法あるの以外ほぼ死語かと思ってたんだけど
バイナリエディタでMS系のフォーマット(特にOffice)で汎用されてるのな
セパレータ系とかなるべく原義に沿おうとしてて好感
いつもprintable文字抽出だけしてたからなかなか気付かんかった

**デフォルトの名無しさん** · 2021/03/31(水) 01:57:57.39

論理的に考えてcrlfが正義とか言い張り続けてたり、なんかこだわりあるんかねMS

**デフォルトの名無しさん** · 2021/03/31(水) 09:30:13.62

> 論理的に考えてcrlfが正義とか言い張り続けてたり

なんのこと？
意味的にCR LFが正しいことに間違いはないし、CR LF対応は
意味のないプライドとかじゃなくて互換性のためにでしょ

それにLinuxとの互換性のためにLFだけのファイルもメモ帳で受け付けるようになったじゃん
開発ツールに限れば昔からLFだけでも認めてた。

**デフォルトの名無しさん** · 2021/03/31(水) 09:35:15.80

>>685
crlfで正しいと思ってるよ、まあ蛇足だった