文字コード総合スレ part14

文字コード総合スレ p ..

2:デフォルトの名無しさん
23/03/03 18:50:36.86 GXuOSZhF.net
乙

3:デフォルトの名無しさん
23/03/04 05:49:15.61 USGrlhof.net
Q. UTF-8 に BOM をつけるべきですか？
A. Unocode Standard では「付けたければ付けても良いが、付ける必要はないし、付けるのはお勧めしない」と規定されています。

4:デフォルトの名無しさん
23/03/04 11:03:14.60 RFNVa0Qi.net
>>1
>Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
filesystem の文字コードと system locale についても詳しく
あとファイル名に BOM 必要かどうかも

5:デフォルトの名無しさん
23/03/04 11:35:06.58 vwOVzejx.net
>>3
訳し方でニュアンスが変わるから根拠となる規格の原文も載せた方が良いぞ

6:デフォルトの名無しさん
23/03/04 20:52:22.05 Uzl83FOV.net
UTF-8, UTF-16, UTF-32 & BOM
URLﾘﾝｸ(unicode.org)
「付けたければ付けても良いが、付ける必要はないし、付けるのはお勧めしない」なんてどこにも書いてないんだが

7:デフォルトの名無しさん
23/03/04 23:54:57.70 q+Tu7Jlx.net
>>4
Windowsの場合はUnicodeというのはUTF-16LEを示す模様
UTF-16LEはリトルエンディアン固定でBOMは付かないフォーマット
UnicodeといってもUTF-8ではない

8:デフォルトの名無しさん
23/03/05 00:42:43.70 lXlBYG2e.net
>>3
何で規定されてんの？

9:デフォルトの名無しさん
23/03/05 01:11:17.97 JF7lH/t4.net
>>6
Unicode Standard を嫁。

10:デフォルトの名無しさん
23/03/05 01:17:14.07 JF7lH/t4.net
>>8
規格に理由は書かれてない。
規格書では趣旨として UTF-8 では Unicode をASCII互換にするための方式みたいな説明してるので、BOM をつけると ASCII互換性が崩れるのが駄目なのかもしれない。違うかもしれない。

11:デフォルトの名無しさん
23/03/05 10:21:41.04 uw77rwIl.net
すまそ。ここの40ページにUTF-8でBOMが許可されるって書いてあった
URLﾘﾝｸ(www.unicode.org)

Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme: UTF-8
Endian Order: N/A
BOM Allowed?: yes

12:デフォルトの名無しさん
23/03/05 10:24:42.19 Dqp2Pk7H.net
The Unicode® Standard Version 15.0 – Core Specification
URLﾘﾝｸ(www.unicode.org)

When converting between different encoding schemes, extreme care must be taken in handling any initial byte order marks.
For example, if one converted a UTF-16 byte serialization with an initial byte order mark to a UTF-8 byte serialization, thereby converting the byte order mark to <EF BB BF> in the UTF-8 form, the <EF BB BF> would now be ambiguous as to its status as a byte order mark (from its source) or as an initial zero width no break space.
If the UTF-8 byte serialization were then converted to UTF-16BE and the initial <EF BB BF> were converted to <FE FF>, the interpretation of the U+FEFF character would have been modified by the conversion.
This would be nonconformant behavior according to conformance clause C7, because the change between byte serializations would have resulted in modification of the interpretation of the text.
This is one reason why the use of the initial byte sequence <EF BB BF> as a signature on UTF-8 byte sequences is not recommended by the Unicode Standard.

13:デフォルトの名無しさん
23/03/05 10:24:58.61 dEWQ/p/B.net
>>10
ASCIIは文字コードで言えば0～127までの文字
UTF-8が使う128～255はASCII互換ではない

128～255を許容するのであれば
BOMもこの範囲に含まれるのでASCII互換

14:デフォルトの名無しさん
23/03/05 11:15:20.72 V5cM5Nk9.net
一般に言うASCII互換ってそういう意味じゃねえだろ。

15:デフォルトの名無しさん
23/03/05 12:40:57.35 /Qd0pRlS.net
BOMがもし先頭以外に現れたら読み飛ばす？

16:デフォルトの名無しさん
23/03/05 16:31:35.44 C3C6IsZE.net
>>13
ここで言われるASCII互換は、ASCII上位互換だな。
今までと同じ入力(ASCII)には同じ出力になることが期待されている。今まで勝手にBOMを付けなかったので、勝手にBOMつけるのはNGくらいの意味。

17:デフォルトの名無しさん
23/03/05 17:06:23.64 C3C6IsZE.net
>>12
「UTF-8 の先頭にある U+FEFF は BOM なのか ZWNBS なのか曖昧なのが、UTF-8 に signature として <FE BB BF> をつけることを推奨しない理由の一つ。」
と書いてあるのか。一つということは他にもあるのか。

18:デフォルトの名無しさん
23/03/05 17:10:12.27 C3C6IsZE.net
>>15
「BOM が不要の場合は先頭の U+FEFF は後方互換性のために ZWNBS として扱う」と規定には書かれいる。

19:デフォルトの名無しさん
23/03/05 17:13:23.86 C3C6IsZE.net
>>18
途中で送ってしまった。
当然途中にある U+FEFF は全て Zero Width Non-Breakable Space (ここで改行禁止くらいの意味）として扱われる。

20:デフォルトの名無しさん
23/03/05 21:42:23.56 dEWQ/p/B.net
>>16
ASCIIと同じ出力になるって言うなら
0～127までの文字しか使えないじゃんｗ
まさか最初さえ同じなら、後ろは違ってもいいとかいう
意味不明な話してるの？

21:デフォルトの名無しさん
23/03/05 21:44:41.60 JF7lH/t4.net
>>20
素人発見。

22:デフォルトの名無しさん
23/03/05 21:46:48.07 VZfS5Nba.net
規格がどうであれ、可能な限りBOMをつけるのが最善策。

23:デフォルトの名無しさん
23/03/05 21:53:29.71 JF7lH/t4.net
>>22
とうとう規格無視しろって言い始めた。
オレオレ基準は他所でやれ。技術者どうしの合意は規格を使う。お前に発言する資格はない。

24:デフォルトの名無しさん
23/03/05 21:56:43.19 dEWQ/p/B.net
元がASCII → UTF-8 （BOM なし）に変換？ → それはただのASCII
UTF-8に対応するのであれば
128～255を許容した上で
UTF-8の仕様に対応しなければいけない
UTF-8に対応するならBOMにも対応しなければいけない
それだけのこと

25:デフォルトの名無しさん
23/03/05 21:59:56.36 dEWQ/p/B.net
UTF-8という規格に対応するのなら
BOMにも対応しろって話だな

26:デフォルトの名無しさん
23/03/05 22:09:24.16 VZfS5Nba.net
>>23
これは規格外をどうするかという話なので、規格の話をしても意味がないぞ
君はエンジニアにむいてない。技術者じゃなくて法律家にでもなれ。

27:デフォルトの名無しさん
23/03/05 22:11:31.00 VZfS5Nba.net
交通事故が起きた時に、人命救助したり、クルマを安全な場所に移動させようとするのが技術者。
交通事故の責任問題ばかり考えるのが法律家。ID:JF7lH/t4は技術者にむいてない。断言する。

28:デフォルトの名無しさん
23/03/05 22:16:09.81 JF7lH/t4.net
>>27
悔しかったら Unicode Standard 書き換えてこいや。もしくは賛同者つのって新しい規格でも作ったら？

29:デフォルトの名無しさん
23/03/05 22:16:39.06 VZfS5Nba.net
規格が不完全でも現実として運用していかなければならないのに、規格を盾に対応を拒否するような技術者はクビだよ

30:デフォルトの名無しさん
23/03/05 22:20:27.96 JF7lH/t4.net
>>29
規格が不完全なら規格を正しく修正するのが技術者の仕事。
お前の主張が正しいなら規格はとっくに直されてる。変更されないのは今の規格が正しいということ。

31:デフォルトの名無しさん
23/03/05 22:26:54.92 VZfS5Nba.net
>>30
そのとおり。誰も問題と思ってないのだからBOM付きはどんどん増える

32:デフォルトの名無しさん
23/03/05 22:32:47.50 dEWQ/p/B.net
>>27
つまり文字化けという事故が起きたときに
文字コードを安全に変換できるようにUTF-8のBOMは使われているということか

33:デフォルトの名無しさん
23/03/05 22:42:24.63 Xloi8tSE.net
うわあ時代遅れのBOM強要おじさんがまだ粘着してる
このクソくだらない流れいつまで続けるんだ、あほらし

34:デフォルトの名無しさん
23/03/05 22:44:16.68 V5cM5Nk9.net
BOMありもなしも規格では許容していて、あとはその仕様の違いを意識せずに混ぜるなというだけの話。
その一方ですべての文字コードをUTF-8 BOMなしに統一すべきだという原理主義者が存在いる構図。

35:デフォルトの名無しさん
23/03/05 23:33:36.53 JupVD2B6.net
規格に「推奨しない」って書かれているのをどうしても見なかったことにしたい人がいるみたいだな。

36:デフォルトの名無しさん
23/03/05 23:42:49.54 9BvZMLGQ.net
>>35
そんなに強く否定してるとこあったっけ
原文どれだ

37:デフォルトの名無しさん
23/03/05 23:51:56.87 9BvZMLGQ.net
>>12にあったw

38:デフォルトの名無しさん
23/03/05 23:57:59.32 V5cM5Nk9.net
not recommended ってのは、必要性を十分検討したうえで使えってことだな。

39:デフォルトの名無しさん
23/03/06 00:10:15.45 M8d550bg.net
>>37
本体は2.6章にあるよ。12はその理由を説明してる感じみたい。

40:デフォルトの名無しさん
23/03/06 03:36:44.43 wHg1YKYv.net
「お前が○○するぶんには好きにしろ」でいい気がするのだが
なんか相手の使い方にそれ以上踏み込んで口を出したくてたまらない人がいるのがエンドレスの原因な気がするのだが

41:デフォルトの名無しさん
23/03/06 05:16:32.79 5TJ6iMgZ.net
>>40
自分が口出してるという自覚はないのか？
「UTF-8でBOMは許容されている。推奨されていないだけ。」
これが事実だろ
これ以上のことは言わんでいい

42:デフォルトの名無しさん
23/03/06 08:52:12.04 nYGMo+Fh.net
推奨されてないものを付けろだの、対応しろだの、規格無視しろだの言うから荒れてる。
つけたきゃ勝手につけろ。他人に勧めるなで終わり。

43:デフォルトの名無しさん
23/03/06 09:27:16.62 7tSuC6ry.net
URLﾘﾝｸ(www.unicode.org)
In UTF-8, the BOM corresponds to the byte sequence <EF BB BF>.
Although there are never any questions of byte order with UTF-8 text, this sequence can serve as signature for UTF-8 encoded text where the character set is unmarked.
(中略)
For compatibility with versions of the Unicode Standard prior to Version 3.2, the code point U+FEFF has the word-joining semantics of zero width no-break space when it is not used as a BOM. In new text, these semantics should be encoded by U+2060 word joiner.
See “Line and Word Breaking” in Section 23.2, Layout Controls, for more information.

44:デフォルトの名無しさん
23/03/06 10:05:23.97 OTf/Royi.net
BOMというのはバイトオーダーマークの略で
リトルエンディアンかビッグエンディアンか区別するためのもの
UTF-8では必要ない
これはWindowsのメモ帳のバグでM$がUTF-8にBOMをつけたのが始まり
仕方ないからUnicodeで許可されてるだけで本来はつけてはいけない

45:デフォルトの名無しさん
23/03/06 11:39:19.84 VJJWQXML.net
>>44
ついてた時にどうするかが重要なのであって、そこが自由裁量であり経営判断。
Windowsの資産をすべて捨てる決断をするのはカネを払う経営者やユーザーであって技術者ではない。

46:デフォルトの名無しさん
23/03/06 11:42:21.59 VJJWQXML.net
山茶花(サザンカ)は本来サンザカと読まなければならないのだから、今後はサザンカは受け付けない(ｷﾘｯ

47:デフォルトの名無しさん
23/03/06 11:50:48.53 OTf/Royi.net
>>45
お前のようなやつがいるからWindowsはいつまでもShiftJISを使い続けることになる
BOMはUnicodeでは認められていない。禁止すべきものだ。

48:デフォルトの名無しさん
23/03/06 11:51:31.28 M8d550bg.net
>>45
入力がBOMつきUTF-8に指定されている場合はBOMとして処理しろ。
入力がBOMなしUTF-8に指定されている場合はZWNBSとして処理しろ。

49:デフォルトの名無しさん
23/03/06 12:05:50.90 lfXpWlV+.net
>>47
推奨されてなくても一応認められてるでしょ
何でそこを捻じ曲げるの

50:デフォルトの名無しさん
23/03/06 12:36:46.99 VJJWQXML.net
ま、積極的にBOMを使うのが運用として自然だから、BOMをつけるアプリがドンドン増える。
デファクトスタンダード。

51:デフォルトの名無しさん
23/03/06 14:23:24.15 diWxUEyJ.net
>>19
>Zero Width Non-Breakable Space (ここで改行禁止くらいの意味）
何も処理せず読み飛ばせって意味では

52:デフォルトの名無しさん
23/03/06 14:36:44.93 diWxUEyJ.net
>>51 の補足だが
入力に(BOMありかBOMなしかはともかく)
[ZWNBS]AB[ZWNBS]CD
というデータがあれば
出力は
ABCD
になるという意味ね

53:デフォルトの名無しさん
23/03/06 14:53:51.51 M8d550bg.net
>>52
先頭は無意味だがそのまま保存する。
途中のはBとCの間で自動改行禁止という指示になる。
# 家(ZWNBS)康ってしとけば難癖つけらなくて安全だな。

54:デフォルトの名無しさん
23/03/06 18:29:55.53 wCDmqeE8.net
話の途中ですまんのだが
ASCIIって7bitのはずなのに下みたいにどう見ても先頭に0がついて8桁あるのはなんでなんや
URLﾘﾝｸ(medium-company.com)
もしかして先頭に0をつけて8bitにしたのがメモ帳とかでは標準の表現方法なんか？

55:デフォルトの名無しさん
23/03/06 19:54:14.87 M8d550bg.net
>>54
単に 8bit = 1byte の世界で説明してるからだろう。（最近はそれしかないので、昔は 7bit = 1byte とかもあった）

56:デフォルトの名無しさん
23/03/06 21:19:45.89 wCDmqeE8.net
そうなん？
じゃあ実際のバイナリ列は7桁なんやね

57:デフォルトの名無しさん
23/03/06 23:59:43.85 6ovzh4WN.net
ハイともイイエともどうとでもとれる書き方なんですんのやろ

58:デフォルトの名無しさん
23/03/07 00:04:49.03 ITg7AjV1.net
>>56
7bitマシンならそうだな

59:デフォルトの名無しさん
23/03/07 00:31:08.63 hOnyMfzk.net
電子メールは7ビットで世界を駆け巡っているの？

60:デフォルトの名無しさん
23/03/07 00:53:18.81 cliNPotC.net
大昔は一番上のビットをパリティとして利用していたこともあつたし

61:デフォルトの名無しさん
23/03/07 00:56:51.64 6eBCzRN0.net
JSONではUTF8必須かつBOMを付けてはいけないと明確に定められてるんだな
全てがこのように決まれば文字コードで悩むこと無くなるな
ソース
URLﾘﾝｸ(www.rfc-editor.org)
JSON text exchanged between systems that are not part of a closed ecosystem
MUST be encoded using UTF-8 [RFC3629].
Implementations MUST NOT add a byte order mark (U+FEFF)
to the beginning of a networked-transmitted JSON text.

62:デフォルトの名無しさん
23/03/07 01:03:35.76 l5xLBgZr.net
8b/10bの10bitが云々の話になるぞ

63:デフォルトの名無しさん
23/03/07 03:00:53.09 fx05/qep.net
>>54
M$がShiftJIS対応のために8bitに変更したんだろ

64:デフォルトの名無しさん
23/03/07 09:10:52.97 ITg7AjV1.net
なんだろな。このど素人が混ざってる感じ
ASCII はもともと 1byte に 1文字を入れる設計。
6bit マシンには非対応
7bit マシンにはそのまま入れる
8bit マシンでパリティ不要なら最上位bitにゼロを入れる
という設計。最近の機器は全部8bitマシンなので最上位にゼロが入る。
（ISO 2022 拡張とかで変更できるけど）

65:デフォルトの名無しさん
23/03/07 09:56:10.33 iWhTsxXS.net
ShiftJIS対応だけのために8bitに変更とか日本はどんだけ凄いんだよ…

66:デフォルトの名無しさん
23/03/07 10:08:55.63 fx05/qep.net
本質がわかってないやつがいるが
論点はBOM禁止という話
M$のバグのために仕様を歪めるな！

67:デフォルトの名無しさん
23/03/07 12:02:26.19 CdvGJ9oA.net
将来SJIS(cp932)やそれ以外のcp(cp65001を除く)は全部無くなるんだろうし
その頃にはUTF-8にBOM付けるやつは居なくなると想定していて
その準備段階として現状UTF-8にBOM付けるべきでないってスタンス
今がんばってBOM付けろって言ってるアホは死ぬまでSJIS浸かってろ

68:デフォルトの名無しさん
23/03/07 12:58:43.14 5oG+IrWl.net
>>67
そのとおり。死ぬまでSJIS浸かってる人は今後もずっと存在し続けるからBOMつけるのが最適解だよ。

69:デフォルトの名無しさん
23/03/07 13:14:07.69 ng3wG2tM.net
MSがWindows12でSJIS(CP932)を異様に扱い難くくするとかの
ペナルティが無いと10年後でも平気で残ってそうだ
互換性重視のWindowsが完全にUTF-8で統一なんて20年はかかると予想

70:デフォルトの名無しさん
23/03/07 13:18:03.53 FxAt1biD.net
>>68
お前にとってはそうなんだろうな。後5年くらいしか生きない老害にとってはそれが最適解。間違いないな。

71:デフォルトの名無しさん
23/03/07 13:18:03.91 5oG+IrWl.net
暴れている人は、最近覚えたCP932という単語ばかり使ってlatin-1の話が出てこないあたり、初心者っぽい。
もうこのスレに書き込まないでくれ。静かに読むだけにしてくれ。

72:デフォルトの名無しさん
23/03/07 13:25:15.27 fx05/qep.net
お前が書き込むな

73:デフォルトの名無しさん
23/03/07 14:05:19.65 jU//zIC9.net
誰か1人が暴れていると書く人は自分が見えていない
このスレでは2人がお互い暴れている

74:デフォルトの名無しさん
23/03/07 23:08:58.35 aKlG86O4.net
暴れてるのはやっぱりUTF-8原理主義者の人だよなあ

75:デフォルトの名無しさん
23/03/07 23:22:22.92 msqWHE5U.net
原理ｗって反対の立場ですと表明してるようなもんだが
愉快犯かなにかか

76:デフォルトの名無しさん
23/03/07 23:29:59.54 aKlG86O4.net
もちろん反対の立場(自由主義)だよ。BOM付けても付けなくてもいいしUTF-8以外のコードも容認する。

77:デフォルトの名無しさん
23/03/08 00:34:32.71 Ax/TB2dR.net
>>61の例のように文字コードは全てUTB8で統一そしてBOMは使用不可が現在進んでいる方向だろう
文字コード問題があるおかげで喰ってる既得権益層にとっては脅威

78:デフォルトの名無しさん
23/03/08 02:50:08.33 KzMkGg+5.net
外部コードが UTF-8 BOM 無しで統一されれば文字コードで悩むやつは少なくなるだろうな
Linux はほぼそうなっていて、Mac も頑張っている。Windows はまだこれからだけどMicrosoft はその方向性を技術者向けに発信してる
10年後くらいの新人に「SJIS? 昔そういうのもあったんですね。まだ使ってるんですか?」とか言われそう

79:デフォルトの名無しさん
23/03/08 03:53:49.16 zRm+4Flk.net
過去のソフト・データの資産こそがWindowsの存在意義なんだから、いまさら捨てられる分けがない
それがなかったらWindowsである必要がないからな
古すぎて非効率極まりないWin32 APIが結局今も残っているのと同じこと
マイクロソフトがいくら頑張ってもこれはどうしようもないことなんだよね
もはや誰もメンテしてないDOS時代に作られたツールがひっそりと使われていたりするし
10年後はまだ確実にSJISが残っていると思うよ
20年後はわからないが

80:デフォルトの名無しさん
23/03/08 04:42:28.62 PePxsOuN.net
過去のデータや文字コードは、そういうのを取り扱うレガシーなアプリケーション
（ブラウザなり古いテキストエディタなり）が対応してれば事足りるよね
今後作成するシステムは基本的にすべてBOMなしUTF8で統一、
連携対象となる外部I/Fがあればインターフェース仕様に応じたエンコーディングを採用すればよい
CSVなんかはExcelで開くことを考えるとどうしてもBOMありにせざるを得ないだろうけど
普通のプレーンテキストならメモ帳ですらBOMなしUTF8がデフォルトになってもう何年も経ってる以上
あえて今更BOMありを要件にする必要はないだろう

81:デフォルトの名無しさん
23/03/08 04:53:38.07 PePxsOuN.net
EUC-JPのテキストファイルにお目にかかる機会もほとんどなくなった
linuxのデフォルト文字コードがUTF8に変わったのっていつ頃だったっけ
iso2022jpもほぼほぼ見なくなったかな
メールクライアントやメールサーバでUTF8がデフォルトになってから15年位ってところか
sjisが消滅するまでEUCやiso2022jpと同じくらい時間がかかるとすれば
やっぱり2030～2040年位になるのかな

82:デフォルトの名無しさん
23/03/08 07:30:34.89 0e7t4My9.net
>文字コード問題があるおかげで喰ってる既得権益層にとっては脅威
そんなんで食っていけるってどんな仕事だよと思うが、本人は本気で思っていそうだな。

83:デフォルトの名無しさん
23/03/08 07:57:02.61 dedBgKWt.net
>>81
SMTPはまだ 7bit code が残ってるよね。
UTF-8 もBase64 でエンコードだし

84:デフォルトの名無しさん
23/03/08 08:52:21.73 KzMkGg+5.net
>>83
プロトコルの話なら SMTPUTF8 があるよ。

85:デフォルトの名無しさん
23/03/08 10:32:01.17 FKUb7GnF.net
インターネットの世界だとUTF-8のBOMは「つけるな、解釈するな、さわるな」だから。
20年前にRFC改定されてからはそんな感じ。

86:デフォルトの名無しさん
23/03/08 19:22:53.32 Gpe8bqC5.net
>>81
ひと昔前の海外OSSのソースコードやドキュメントはCP1252(latin)が当たり前だったな
いつのまにかUTF8で統一されたように感じるのはなぜだろう

87:デフォルトの名無しさん
23/03/08 19:41:48.35 LcRKYHDN.net
>>86
淘汰された

88:デフォルトの名無しさん
23/03/08 20:01:21.53 fd4vfZJd.net
なんでだと思うんだ？😠

89:デフォルトの名無しさん
23/03/08 20:46:09.77 Czf7FTOV.net
nginxの台頭
当時はこぞってドキュメントを原文で輪読してたとか

90:デフォルトの名無しさん
23/03/09 18:57:54.79 WLy5E3Kl.net
なんで？って一瞬思ったけどロシア製だからか
koi8?cp1251どっちだとしても非キリル文字圏のwindowsだと辛いね

91:デフォルトの名無しさん
23/03/11 08:34:25.16 4eNVcbJV.net
VS Code と PowerShell でのファイルのエンコードの概要
URLﾘﾝｸ(learn.microsoft.com)
システムやアプリケーションごとに使用しているエンコードが異なる可能性があります。
・現在、.NET Standard、Web、Linux の世界では、UTF-8 が主流のエンコードです。
・多くの .NET Framework アプリケーションは UTF-16 を使用しています。歴史的な理由から、これは "Unicode" と呼ばれることもあり、現在では UTF-8 と UTF-16 の両方を含む広範な標準を指しています。
・Windows では、Unicode より前のネイティブアプリケーションの多くが既定で Windows-1252 を使用し続けています。
BOM はオプションであり、Linux の世界ではそれほど採用されていません。UTF-8 の信頼性の高い規則があらゆるところで使用されているためです。ほとんどの Linux アプリケーションでは、テキスト入力が UTF-8 でエンコードされていると想定されています。多くの Linux アプリケーションは BOM を認識して正しく処理しますが、認識しないものもあります。そのため、そのようなアプリケーションで処理されたテキストにアーティファクトが生じます。
したがって:
・主に Windows アプリケーションと Windows PowerShell を使用している場合は、BOM ありの UTF-8 または UTF-16 のようなエンコードをお勧めします。
・複数のプラットフォームにまたがって作業する場合は、BOM ありの UTF-8 をお勧めします。
・主に Linux 関連のコンテキストで作業する場合は、BOM なしの UTF-8 をお勧めします。
・Windows-1252 とラテン-1 は基本的にレガシエンコードであり、できれば避けてください。ただし、一部の古い Windows アプリケーションではそれらに依存している可能性があります。

92:デフォルトの名無しさん
23/03/11 09:00:57.05 qx2T+jGN.net
LinuxはBOMをうまく扱えないんやな

93:デフォルトの名無しさん
23/03/11 10:23:36.62 5Ex6umnL.net
UNIX はパイプで複数のデータストリームが一つになったりするので，
データストリームの「先頭」とは何かがはっきりしないよね
tar のデータストリームとかどうするんだろうね

94:デフォルトの名無しさん
23/03/11 10:42:53.36 2IDu8ors.net
そういいながら、結局 PowerShell の新しいバージョンからデフォルトを BOM無しUTF-8 に変更してきたのがマイクロソフト流儀だけどな。
時代の流れは早いお。

95:デフォルトの名無しさん
23/03/11 15:13:41.78 Q9SpWajK.net
>>93
そもそもtarはバイナリだ。テキストファイルじゃねーよｗ

96:デフォルトの名無しさん
23/03/11 19:53:47.04 5Ex6umnL.net
ファイル名とか入ってるけど，そのファイル名の先頭にBOMつけるの？

97:デフォルトの名無しさん
23/03/11 19:54:34.90 WfuE5Qpv.net
Windows技術者「お前ぇぇ、WindowsアプリではBOMつきUTF-8 使えって言ってたじゃん。なんでVScodeやPowerShellの新しいの BOMなしなの？」
MS「BOMつきは昔の話」
俺「......

98:デフォルトの名無しさん
23/03/11 20:33:35.60 iJEvXpew.net
>>97
何かおかしいかな？

99:デフォルトの名無しさん
23/03/11 20:42:13.29 66SSApNW.net
tar扉を開く

100:デフォルトの名無しさん
23/03/11 23:21:38.53 Q9SpWajK.net
>>97
Linuxにも対応してるからだろ
ちょっとアホすぎやろ

101:デフォルトの名無しさん
23/03/11 23:22:42.03 Q9SpWajK.net
>>96
BOMはテキストファイルの頭につけるものなの
tarはテキストファイルか？違うだろ。アホすぎ。

102:デフォルトの名無しさん
23/03/12 00:00:06.48 Or/mO0pv.net
へえ
tarはただ元のファイルにヘッダをつけてひたすら結合するだけという認識だったんだけど
こういうファイルもバイナリファイルって呼ぶべきものなのかな
BOMつきテキストファイルならBOMつきのまま無圧縮で格納されちゃうものかと思ってたんだが
tar化するときにはファイルの先頭じゃなくなるから除去されちゃうの？
で展開するときにはまた自動でBOMがついちゃうの

103:デフォルトの名無しさん
23/03/12 00:02:44.53 Or/mO0pv.net
途中送信しちゃったけど、
もしBOMの付け外しまでフルオートでよしなにやってくれるとしたらtarコマンドって随分と賢いんだね
そんなｸｿめんどくさい考慮せずに済ませるほうがよっぽど楽だろうに

104:デフォルトの名無しさん
23/03/12 00:46:06.01 Cuf4mGT0.net
おちつけ
最近の tar は gzip やその他の圧縮なんか対応してたりする賢い tar で便利に使われてるので人によって認識にいろいろ違いが出るのは仕方ない。
もともと tar は tape archiver で、磁気テープにファイルを読み書きするためのツールでバイナリとかテキストとか気にしない。
というか unix 系のツールにはバイナリとテキストを区別しないやつが多い。
「それバイナリやろ」とか、「それテキストやろ」とか言われれも、「何の違いが？」ってなる。

105:デフォルトの名無しさん
23/03/12 01:06:11.40 8ghP4JCw.net
圧縮されていようがいまいがこんな発想が出てくるのはただものではない

106:デフォルトの名無しさん
23/03/12 05:16:54.72 C6Uwumzj.net
>>94 >>97
MicrosoftもBOM無しUTF8へと移行をどんどん進めてるね
Microsoft以外の一般環境だとBOM無しUTF8で統一されてしまったからね

107:デフォルトの名無しさん
23/03/12 05:55:05.23 LPnCxw27.net
というか、MicrosoftとLinux以外のOSがなくなってしまったんだぜ
あとmacOSが残ってるか

108:デフォルトの名無しさん
23/03/12 09:21:56.46 zZ3L0xxp.net
そういえば、テキストだけ特別な扱いはしたくないからBOMは入れてくれるなという主張はわからんでもないが
とあるそこそこ有名なOSSは逆にストリームの先頭の EF BB BF を強制的に削るという強硬策をとってたな。

109:デフォルトの名無しさん
23/03/12 09:39:57.05 LPnCxw27.net
今はテキストファイルの話をしてる
ストリームの仕様は関係ない話だ

110:デフォルトの名無しさん
23/03/12 10:13:38.29 Cuf4mGT0.net
あほだな。テキストのストリームとか言われたら死にそうだな。

111:デフォルトの名無しさん
23/03/12 15:01:05.66 JTWw5hHO.net
UNIXはバイトストリームしかない中古品
C言語もWindows向けと違ってテキストモードとか実装して当然ものすら無いし

112:デフォルトの名無しさん
23/03/12 16:18:15.25 C6Uwumzj.net
>>111
レイヤの区別をできない素人かよ

113:デフォルトの名無しさん
23/03/12 17:11:02.31 SD5cjZL3.net
Windows の改行コードが 0D0A なのはMSDOS の名残
C言語の \n は1バイトなのだが，これを2バイトでも処理できるように
苦し紛れに作ったモードがテキストモード

114:デフォルトの名無しさん
23/03/12 21:43:16.22 JTWw5hHO.net
Why is the line terminator CR+LF?
URLﾘﾝｸ(devblogs.microsoft.com)
This protocol dates back to the days of teletypewriters. CR stands for “carriage return” – the CR control character returned the print head (“carriage”) to column 0 without advancing the paper. LF stands for “linefeed” – the LF control character advanced the paper one line without moving the print head. So if you wanted to return the print head to column zero (ready to print the next line) and advance the paper (so it prints on fresh paper), you need both CR and LF.
If you go to the various internet protocol documents, such as RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), or RFC 2616 (HTTP), you’ll see that they all specify CR+LF as the line termination sequence. So the the real question is not “Why do CP/M, MS-DOS, and Win32 use CR+LF as the line terminator?” but rather “Why did other people choose to differ from these standards documents and use some other line terminator?”
Unix adopted plain LF as the line termination sequence. If you look at the stty options, you’ll see that the onlcr option specifies whether a LF should be changed into CR+LF. If you get this setting wrong, you get stairstep text, where
each
　　line
　　　　begins
where the previous line left off. So even unix, when left in raw mode, requires CR+LF to terminate lines. The implicit CR before LF is a unix invention, probably as an economy, since it saves one byte per line.

115:デフォルトの名無しさん
23/03/12 22:44:50.34 myYPYrxB.net
こんなスレにおるのはほぼオッサンなんだけど
キミに学びがあったのならよかった

116:デフォルトの名無しさん
23/03/12 22:58:02.67 Cuf4mGT0.net
最後の方の Unix の記述は間違いだな。ちゃんと調査せずに適当な風説を元に回答したようだ。

117:デフォルトの名無しさん
23/03/12 23:20:28.70 Cuf4mGT0.net
1) 大昔の teleprinter/teletypewriter では CR+LF で改行にしていた。違うのもあった。
2) それを引き継いでビデオ端末の多くが CR+LF を改行にしていた。違うのもあった。
3) デバイスに直接出力していた古いOSや、OS無しの低機能のシステムではデバイスの多数派に合わせて CR+LF を改行コードにした。
4) Multics ではデバイス・ドライバーで出力先デバイスに合わせて改行処理を変更する機能があるので、デバイスに依存しない抽象化された文字コードを採用することにした。
5) このときに、当時の ISO 646 のドラフトにおいて LF だけで改行とできる規定があったので、それを採用した。
6) unix はこの Multics の仕様を引き継いだ。
#）一方で CP/M はデバイス・ドライバーによる抽象化などの高度な機能は無かったので、CR+LF を改行コードにするしかなかった。MS-DOS および MS-Windows はこの仕様を引き継いだ。

118:デフォルトの名無しさん
23/03/13 03:18:43.79 7nq5QUJ1.net
>>113
タイプライターの名残やろ

119:デフォルトの名無しさん
23/03/13 09:07:24.07 g2KgZszC.net
CP/Mのパクリをしなければ改行にCR+LFを採用する必要はなかった
まあこのパクリのおかげでCP/M86に勝ったんだけどね

120:デフォルトの名無しさん
23/03/13 11:13:13.34 bF2IN6wD.net
レトロmac: "CR" ぼくも忘れないで

121:デフォルトの名無しさん
23/03/13 13:38:04.06 L8qxRZDz.net
>>120
お前は深く考えてない玩具 Apple II の文字コード継承しただけじゃないか？正直に白状したまえ。

122:デフォルトの名無しさん
23/03/13 14:36:51.97 7nq5QUJ1.net
Macはワンボタンが素晴らしいと思ってるし、画面下にアプリ切り替えバーなんていらないし、UNIXなんてクソだからCRを使った

123:デフォルトの名無しさん
23/03/13 21:35:59.50 Lx/25M/K.net
CRはCarriage Returnで行頭に復帰
改行はしない

124:デフォルトの名無しさん
23/03/13 22:29:34.49 bqBi0AM/.net
それ端末の動作だし
だからなんやねん

125:デフォルトの名無しさん
23/03/14 16:02:14.81 ZglUMoKm.net
読むときは CR(単独) が来ようが CR+LF(連続) が来ようが LF(単独) が来ようが LF として処理する
描くときは LF のみ描き込む
これが正しい在り方

126:デフォルトの名無しさん
23/03/14 17:57:34.43 3k2Galku.net
問題はCRとLFとCRLFが混ざっているときだ

127:デフォルトの名無しさん
23/03/14 19:20:49.37 pZL91EEN.net
LF, CR, LF, LF, LF, CR ときたら何行改行するか問題。
CR+LF 派にこれを突きつけると、言行がバグる人が多い。CR+LF派は脳に欠陥があるに違いない。

128:デフォルトの名無しさん
23/03/14 19:52:03.66 euneF1w3.net
>>127
LRの次がCRだったら無視する（読み飛ばす）
CRの次がLFだったら無視する（読み飛ばす）
で問題なし

129:デフォルトの名無しさん
23/03/14 19:53:53.28 f/+ml7jb.net
CRLFで1回、CRで1回、LFで1回だろ？

130:デフォルトの名無しさん
23/03/14 20:20:53.43 pZL91EEN.net
LF派：誰に聞いても同じ回答を返す
CR+LF派：人によって回答が違う。謎のオレオレ理論を説明しだす
CR派：問を無視してアップルへの恨み言を言い始める

131:デフォルトの名無しさん
23/03/14 20:23:34.83 IFFVvzVH.net
BOMは諦めて今度は改行かね

132:デフォルトの名無しさん
23/03/14 20:27:00.01 f6OfJkKw.net
>>131
ﾜﾛﾀ

133:デフォルトの名無しさん
23/03/14 23:03:37.37 YE6RlyDJ.net
CRは先頭位置に戻す
LFは行替え
だから >>127は4行改行して先頭位置になる

134:デフォルトの名無しさん
23/03/14 23:25:04.85 9qcdp0KK.net
>>133
本来はそんなんだけど
タイプライターで打つときにそれだと二動作必要になるので
一動作でcr+lfにするようにした
これが混乱の始まりかも

135:デフォルトの名無しさん
23/03/15 01:01:29.12 GIgi9suE.net
>>133
つまり先頭位置にある時には CR は不要で LF だけで改行すべきで、
毎回 CR+LF を出力している某OSは無駄と言いたいの？
それでは CR+LF 派とは言えないよな？

136:デフォルトの名無しさん
23/03/15 02:30:17.71 ClK12XWK.net
HTTPプロトコルは改行がCR+LFなのはどうして？

137:デフォルトの名無しさん
23/03/15 04:53:01.78 GIgi9suE.net
>>136
まじめに答えると、
SMTPなどの既存のプロトコルを参考にしたから。
で、SMTPがCRLFなのは、インターネット以前の汎用機とか使ったメールシステムとの相互接続性に気を使ったから。
実際のHTMLは場所によってLFだけやCRだけの改行も許されていてかなり複雑なんだが。

138:デフォルトの名無しさん
23/03/15 11:00:18.93 ClK12XWK.net
ほー、ってことはWindowsも
そういった互換性を大切にしてたんだな

139:デフォルトの名無しさん
23/03/15 11:12:26.56 2SW2Y069.net
むしろ >>127なんて通常はあり得ないって事さ

140:デフォルトの名無しさん
23/03/15 12:41:20.81 GIgi9suE.net
>>138
まあ、そうだな。
Windows が大事にしたのは MS-DOS との互換性で、
MS-DOS が大事にしたのは CP/M との互換性で、
CP/M は大昔の汎用機と同じくらい古臭い<BS><BS><BS>シンプルな設計だったというだけだな。

141:デフォルトの名無しさん
23/03/15 22:20:01.44 ClK12XWK.net
UNIXは元々研究用だからね
互換性なんか考えちゃいない
だからUNIXはBSD系とSystemV系に分離した
多くのコマンドの互換性がなくなった

142:デフォルトの名無しさん
23/03/16 00:21:30.90 OI9tXZBe.net
>>141
歴史をまったく知らない素人妄想だな。
Multics で導入されたテキストデータの抽象化とか知ってるか？

143:デフォルトの名無しさん
23/03/16 03:57:32.72 mQ2r18kg.net
http2以降はヘッダに改行なくなったんだね、、、

144:デフォルトの名無しさん
23/03/16 07:48:28.62 svmadcyh.net
>>141
多くのコマンドの互換性ってたかだかオプションが違うくらい
シェルスクリプトでどのバージョンでも対応できた

145:デフォルトの名無しさん
23/03/16 10:25:24.39 6H39TrIH.net
>>142
知ってる。お前のターン。
俺を論破してみせろやｗ

146:デフォルトの名無しさん
23/03/16 10:25:51.36 6H39TrIH.net
>>144
歴史を知らんのねｗ

147:デフォルトの名無しさん
23/03/16 10:41:46.04 rUjwTzLK.net
知ってる→実は何もわかってない
知らんのかね→自分が何も知らない
どうして、こういう知ったかぶりする小学生みたいんな奴が混ざってるんだろう？

148:デフォルトの名無しさん
23/03/16 10:46:31.88 0AiTyYBY.net
コマンドラインにプログレスバーを出したり
固定レイアウトでリアルタイム更新する画面とか
きちんとCRとLFは区別されてるって感じる

149:デフォルトの名無しさん
23/03/16 11:13:17.10 N2/NSeFa.net
BOMは文字コード？
ZWNBSは文字コード？
CRは文字コード？
LFは文字コード？

150:デフォルトの名無しさん
23/03/16 11:31:30.24 6H39TrIH.net
>>147
俺のこと言ってる？
「知らんだろ」っていうやつは、
自分が知らないことを相手に要求して
揚げ足取ろうとしているだけだから
「知ってる」っていうと相手に大ダメージを与えられる
知ってた？

151:デフォルトの名無しさん
23/03/16 14:30:41.33 gF6V1TZr.net
知っとって知らんて言うのは犯罪やぞ

152:デフォルトの名無しさん
23/03/16 14:32:32.77 NwWFe4eh.net
>>150
無知なやつは恥も知らんなwww
自分が知らないから相手も知らないはずwww

153:デフォルトの名無しさん
23/03/16 14:59:26.59 b0tE1S4+.net
UNIX終了wwやはり正義はWindowsだったwwww
Unix is dead. Long live Unix!
URLﾘﾝｸ(www.theregister.com)

154:デフォルトの名無しさん
23/03/16 16:43:13.46 hqbItujU.net
Unix というか Linux に徐々に移行でしょ
メインフレームやスーパーコンピュータはLinux になっちゃたし

155:デフォルトの名無しさん
23/03/16 16:58:32.87 OI9tXZBe.net
>>153
タイトルすらまともに読めてなくてｗ
その記事
IBM が Redhat 買ってこれからは Linux を始めとする unix-like の時代。AIX とかの(旧来の) Unix は終わり。
Windows についてはマイクロソフトも WSL を頑張ってるとしか書かれてない。
そもそも文字コードに何の関係が？

156:デフォルトの名無しさん
23/03/16 17:04:46.17 CqIyXRLu.net
>>141,153
お前 UTF-8 に BOM つけろ君だろ
教養が感じられないあたりがそっくり
主張が通らなかった、腹いせにスレを荒らすな！

157:デフォルトの名無しさん
23/03/16 17:42:30.76 6H39TrIH.net
>>156
アホ化。逆だわ
UTF-8にBOMつけるな
あれはMSが歪めた仕様
元々はバグだ
シランなら黙っとれ

158:デフォルトの名無しさん
23/03/17 20:09:59.24 kImSYq8C.net
このスレは以下で全員が一致している
・文字コードはUTF8で統一
・UTF8はBOMを付けない

159:デフォルトの名無しさん
23/03/17 21:06:51.85 2DL2Xy3z.net
URLﾘﾝｸ(i.imgur.com)
＞ LinuxやMacでは、ファイル名やメタデータから文字コードを判断することが多いので、BOMは不要です。
これマジ？

160:デフォルトの名無しさん
23/03/17 21:09:37.93 HCeWuFC8.net
BOMって、 UTF16とかじゃないと意味が無いやん？

161:デフォルトの名無しさん
23/03/17 21:21:18.90 Y3Hkfwer.net
一応は出典付きになってんだからそれ辿って判断しろ

162:デフォルトの名無しさん
23/03/17 22:17:32.94 axfbRcbR.net
mac のファイルシステムはリソースフォークを持っているので
そこにTextEncoding を格納しておけば良い

163:デフォルトの名無しさん
23/03/18 09:15:45.80 hvwkbmHD.net
>>159
出典を挙げてくれるところが親切だな。そのqiitaどこ？

164:デフォルトの名無しさん
23/03/19 12:16:38.49 fPDrKYk/.net
Windows のファイルシステムは拡張子を持っているので
そこが .txt なら BOM 無し UTF-8 を前提にして良い

165:デフォルトの名無しさん
23/03/19 12:24:54.52 h5llDeKs.net
おいおい
Windowsで.txtなんてそれこそ山程CP932のファイルがあるだろう(日本の場合)
それらは全て無視かい

166:デフォルトの名無しさん
23/03/19 13:04:41.50 SRrPG6Bv.net
>>165
そいつらは将来に備えて .sjt とかにでも改名しとけw

167:デフォルトの名無しさん
23/03/19 13:31:52.51 pEJ/zH5I.net
UTF-8を使う俺が困らなければ他人はどうでもいい。

168:デフォルトの名無しさん
23/03/19 14:22:28.77 SRrPG6Bv.net
>>167
UTF-8を使う俺＝将来のお前
どうせ嫌でも皆がUTF-8を使うことになる
遅いか早いかの違いでしかない

169:デフォルトの名無しさん
23/03/19 14:46:22.57 pEJ/zH5I.net
遅いか早いか、まさにそこがポイントだわな。
100年後には確実に死んでいるだろうからといって明日すぐに死んでもいいなんて考える人はまずいない。

170:デフォルトの名無しさん
23/03/19 15:05:53.25 SRrPG6Bv.net
あきらめろ！もう勝負はついてしまったんだ
今は粛々と対応を進めるフェーズだ
早く対応するほど傷は浅くてすむぞ

次ページ