文字コード総合スレ part13

**デフォルトの名無しさん** · 2020/07/03(金) 20:53:47.08

Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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 https://mevius.5ch.net/test/read.cgi/tech/1516629503/
文字コード総合スレ Part12 https://mevius.5ch.net/test/read.cgi/tech/1544931495/

**デフォルトの名無しさん** · 2023/02/24(金) 01:46:20.35

>>768 >>769
Mac上のExcelは、どうするのが正解?
以前「CSVで日本語が化けるぞ」と言われて、よくわからなかったからググったら「UTF-16なら
大丈夫」とあったので、そうしたら文句を言われなくなったのでよかったらしいw
Excel以外でCSVを使うとき、例えばpandasとかUTF-16でも大丈夫なんだっけ?

**デフォルトの名無しさん** · 2023/02/24(金) 03:29:22.76

今後はファイルや外部通信はUTF-8がデフォルトになる
逆にいうとBOMついてないのは全てUTF-8とみなされる
よってUTF-8にBOMは不要
この単純なロジックが理解できないやつはかわいそう

**デフォルトの名無しさん** · 2023/02/24(金) 06:23:20.57

>>783
> 今後はファイルや外部通信はUTF-8がデフォルトになる

ならないよ。
誤った認識を前提に議論するのは意味がない。
スレのレベルが低下して無駄な書き込みが増えるだけなので、この話題はもうやめてくれ。

**デフォルトの名無しさん** · 2023/02/24(金) 08:06:25.11

文字コードを自動判別するためにBOMを使うってのがダメだな
BOMと思ったコードが違うエンコーディングの可能性があるんだから
Windows だけで閉じておいてほしいから、通信回線には流さないで

**デフォルトの名無しさん** · 2023/02/24(金) 08:34:34.48

>>777
> Windowsは内部的にはUTF16で統一されてるよ
ワイドキャラクタがUTF-16で統一されているという意味なら
Linuxも20年以上前のglibc-2.0からUTF-32で統一されているよ

ワイドキャラクタ以外アプリ等が独自に他の符号化方式を
採用している場合があるのも同じ

**デフォルトの名無しさん** · 2023/02/24(金) 08:58:55.21

>>785
そもそも誰も自動判別の正確性を担保できないからBOMがあるんだろ
Windowsを除外したビジネスで成り立つならそれでいいが、現実はそうじゃない。
他人が対応するのを待つのは無能な人のすることだよ。

**デフォルトの名無しさん** · 2023/02/24(金) 09:04:15.26

過去にプログラミングやったことない人が急にスマホ開発に配属されて、自分が対応するのではなく他人が対応するのを待ってるあたりに頭悪いのが伝わってくる。
プログラミングの才能ないし、むいてないからプログラミングから離れたほうがいいと思う。

**デフォルトの名無しさん** · 2023/02/24(金) 12:43:37.42

逆だね。BOMなんかじゃ判別できない
だって，FEってソーンのコードだもの

**デフォルトの名無しさん** · 2023/02/24(金) 12:49:37.23

Windows プログラマってほんとどうしてこんなに喧嘩を売るの？
世の中の文字コードがCP932 とUTF-16しかないと思っているよね

**デフォルトの名無しさん** · 2023/02/24(金) 13:06:47.37

もう少し正確にいうと，テキストファイルから
文字のエンコーディングを推測することはほとんど不可能
文字のエンコーディングはアウトオブバンドで送る必要がある
ISO2022 はエスケープシーケンスというアウトオブバンド転送を定義していた
ちゃんと定義するなら，UTF-8も Byte order mark ではなく
エンコーディングを指定するアウトオブバンドシーケンスを定義すべきという話
なんか議論が噛み合ってなかったので

**デフォルトの名無しさん** · 2023/02/24(金) 13:10:51.59

それで，Windows は先頭にBOM を入れるというのをアウトオブバンドで決めてる訳
だから，Windows で勝手にしてね。Windows 以外には送らないでって話

**デフォルトの名無しさん** · 2023/02/24(金) 13:23:55.49

「べき」論はよそでやってくれ。

**デフォルトの名無しさん** · 2023/02/24(金) 13:24:26.82

もうさ、結論出ないからこうしたら？

今後新たに作成するテキストファイルはBOM無しUTF-8で書く
今後のソフトはBOM有りBOM無し両方のUTF-8を読めるように作る

**デフォルトの名無しさん** · 2023/02/24(金) 13:53:37.06

急にスレのレベルが下がった感じ。同じ人がID変えて書き込んでるんだろうか。
このスレに独り善がりな理想論を書き込む人は、プログラマ適性がないから転職しなさい。

**デフォルトの名無しさん** · 2023/02/24(金) 13:59:12.56

>>792
Windowsではとか言ってる時点で国際化とか文字コードのこと全く知らない無知だろ。単に「日本語Windows」で使われてたCP932がUTF-8のBOMとかぶってなかっただけ。
英語Windowsで使われてたCP1252とかは EF BB BF にもそれぞれ文字が割当れらてるのでBOMとかあっても区別できばない。他の多くの文字コードもそうだし、CP932/SJIS なんかより断然現有の資産も多い。
おま国事情でたまたまうまくいってるだけなんて、一般化や標準化されるわけないだろ

**デフォルトの名無しさん** · 2023/02/24(金) 14:02:43.91

>>796
792の返信にしたけど、792を批判したいわけではなくて、WindowsではBOMが便利という一般論を否定したかっただけ。
それは単なる日本しか知らない蛙仕草。

**デフォルトの名無しさん** · 2023/02/24(金) 14:02:58.25

「ぼくのかんがえたさいきょうの文字コード処理パッチ適用」を自腹で開発して、自腹ですべての顧客のデバイスに入れればいいだけ。
すべてはカネ次第。カネを出す人が仕様を決めればいい。それだけ。

**デフォルトの名無しさん** · 2023/02/24(金) 14:42:29.80

海外ではこうとか、本来こうあるべきとか、どうでも良いんだよ
日本語のテキストファイルを読み込むプログラムの仕様としてSJIS/UTF8自動判別にした場合、
確実に文字化けしないのはBOM付きUTF-8だけという事実は考慮すべき

**デフォルトの名無しさん** · 2023/02/24(金) 15:02:03.28

>>796
CP1252でEF BB BFって文字はあっても意味を成さない謎の文字列だし、極稀なパターン
完璧ではなくとも、実用上ほぼ問題ない精度で判別出来るでしょ
とうのWindowsがそういう風に利用してるのだし

**デフォルトの名無しさん** · 2023/02/24(金) 15:30:37.37

ïÿ¿を有意な先頭文字列とする利点と欠点を考えて決断すればいいだけのこと

**デフォルトの名無しさん** · 2023/02/24(金) 16:49:11.30

WindowsやエクセルとBOMは関係ないとおもうんだが
とくにマイクロソフトが開発したり、始めたわけではなく
採用前からBOMありのユニコードがあってたまたまBOMありフォーマットを使っただけでは?
ちがうのか?

**デフォルトの名無しさん** · 2023/02/24(金) 18:05:09.63

>>799
そもそも自動判別は悪という流れになってることすら知らないんだな。
セキュリティホールやバグの温床になるので文字コードの自動判別はなくすのが世界の流れ。特に確実性のない自動判別は害悪でしかない。

**デフォルトの名無しさん** · 2023/02/24(金) 18:22:32.64

BOMを信じた時点でもはや自動判別ではないだろ。

**デフォルトの名無しさん** · 2023/02/24(金) 19:12:21.37

>>786
> Linuxも20年以上前のglibc-2.0からUTF-32で統一されているよ
それでマウントとったつもりだろうが
Windows NTがUnicodeに対応したのは30年前だ

**デフォルトの名無しさん** · 2023/02/24(金) 19:13:09.21

>>804
世界には多数の文字コードがあるわけで
完全な自動判別は不可能だって知らないの？

**デフォルトの名無しさん** · 2023/02/24(金) 19:20:45.75

>>783
> 逆にいうとBOMついてないのは全てUTF-8とみなされる
> よってUTF-8にBOMは不要
あのー、Unicode以外の全ての文字コードにはBOMがついてないんですけど？

**デフォルトの名無しさん** · 2023/02/24(金) 19:22:18.48

>>781
> 具体的なコマンド名とディストリビューションを挙げてみろや

echo あいうえお | mawk '{ print length($0) }'
15

**デフォルトの名無しさん** · 2023/02/24(金) 19:23:31.95

まだunicode以外の文字コードを使う気かよ
化石なん？

**デフォルトの名無しさん** · 2023/02/24(金) 19:23:32.40

>>781
echo あいうえお | dash -c 'read line; echo ${#line}'
15

**デフォルトの名無しさん** · 2023/02/24(金) 19:24:26.90

>>809
今すぐこれまでの資産をUnicodeに変換してみせろよｗ

**デフォルトの名無しさん** · 2023/02/24(金) 19:28:28.37

UTF-8はPlan 9かららしい

Linuxに勝てなかったPlan 9　2009/02/09
「Plan 9」はUNIXが生まれたベル研究所で、次世代UNIXとして開発されていた分散OSだ。
UNIXやC言語を生み出したケン・トンプソン、デニス・リッチー、ロブ・パイクらのチームが、当時UNIXが抱えていた限界を打ち破るために、ネットワークやGUIを最初からUNIXの設計思想に基づいて取り入れた先進的なOSだった。

UNIXの大きな特徴として、デバイスをファイルにマッピングして抽象化するというものがある。ところが、こうした初期設計時の抽象化から漏れるAPIが増えた。
そうして漏れつつあった各種リソースを、再びUNIX的なファイルシステムのツリーにマップし、抽象度と統一性の高いインターフェイスを用意したのがPlan 9だった。

ファイルとして扱えるのは一般に想像するようなハードウェアデバイスだけではなく、あらゆるリソースが対象となった。
TCP/IPなどのネットワーク関連の操作も「/net」というディレクトリを使って行うなど徹底していた。

Plan 9はなぜ失敗したのか？
マーケティングに熱心でなかったからとか、さまざまな理由付けが可能だが、Plan 9が普及しなかった理由は結局のところ、旧来のUNIXを置き換えるほどには先進的ではなかったからだ、というのがレイモンド氏の答えだ。
Plan 9に比べれば、確かにUNIXはきしみ音が聞こえてガタピシいうし、明らかにさび付いたところもあるのだが、そのポジションを維持するために必要な仕事はちゃんとこなせていた、という。

LinuxやBSD系UNIXには、Plan 9由来の機能がいくつか取り込まれている。
稼働中のプロセスをモニタしたり操作するための「/proc」と呼ばれるファイルシステムは、Plan 9のものだし、
Linuxでスレッドを生成するシステムコール「clone」は、レイモンド氏によればPlan 9の「rfork」をモデルにしているという。
すべてをファイルのように扱うという意味でいえば、LinuxのFUSEもPlan 9の影響下にある。
現在、FUSEを使ったファイルシステムには、ftpfsはもちろん、flickrfsやBloggerFS、TracFSなどさまざまな実装がある。
今やOSばかりかインターネット全体にも利用範囲を広げた感があるUTF-8も、Plan 9のために考案されたエンコーディングだという。
https://atmarkit.itmedia.co.jp/news/analysis/200902/09/future.html

**デフォルトの名無しさん** · 2023/02/24(金) 19:28:34.50

>>781
echo あいうえお | cut -b 4-
いうえお

**デフォルトの名無しさん** · 2023/02/24(金) 19:30:00.43

間違えた

echo あいうえお | cut -c 4-
いうえお

**デフォルトの名無しさん** · 2023/02/24(金) 19:36:38.85

業界人ですら認識ちがいのある文字コード。素人に説明するの超絶に面倒。

**デフォルトの名無しさん** · 2023/02/24(金) 19:46:01.57

エンコーディングの話をしているのに Unicode とは？

**デフォルトの名無しさん** · 2023/02/24(金) 21:08:47.90

誰も>>794はスルーするんだな？ｗ

**デフォルトの名無しさん** · 2023/02/24(金) 21:53:46.51

流れからしてピントのずれたレスに反応するほどのことでもないかなって

**デフォルトの名無しさん** · 2023/02/24(金) 22:24:35.19

>>814
そもそも -c オプションは現在 -b （バイト指定）と同じ動きというのが仕様なので文字コードもくそもない。
マニュアル嫁。

**デフォルトの名無しさん** · 2023/02/24(金) 22:30:50.23

>>815
いや、このスレは素人が跋扈してるだけに過ぎないと思うが。
文字コードやネット・プロトコルの専門家で、「今後は外部は UTF-8 がデフォルト」って以外の意見は聞いたことがない。

**デフォルトの名無しさん** · 2023/02/24(金) 23:16:35.23

>>817
スルーしてないだろ
ちゃんと読めよ
わざとか？

**デフォルトの名無しさん** · 2023/02/24(金) 23:18:05.18

>>819
どこにも同じ動きとは書いていない

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html

-b list
Cut based on a list of bytes. Each selected byte shall be output unless the -n option is also specified.
It shall not be an error to select bytes not present in the input line.

-c list
Cut based on a list of characters. Each selected character shall be output.
It shall not be an error to select characters not present in the input line.

**デフォルトの名無しさん** · 2023/02/24(金) 23:31:32.12

>>822
linux なら linux のマニュアル嫁。

**デフォルトの名無しさん** · 2023/02/25(土) 00:00:07.97

>>823
お前か誰かしらんが、どのディストリでUnicodeに
対応してないって聞かれたから
Linuxは全て対応してないと答えたんだが？

Linuxは対応してないといった俺の指摘に対して
Linuxは対応してないのが仕様だと答えるアホ

macOSのcutはちゃんとUnicodeに対応してる
対応してないディストリを聞かれたから答えただけだ

**デフォルトの名無しさん** · 2023/02/25(土) 00:01:38.57

それにmawkやdashが対応してないという話からも逃げてるな
Unicodeに完全対応してねーんだよ

**デフォルトの名無しさん** · 2023/02/25(土) 01:08:13.97

>>825
話の流れを見る限り、お前が内部コードと外部コードの区別がついてないんじゃないか？

**デフォルトの名無しさん** · 2023/02/25(土) 01:34:53.03

macOSはUNIXといってるからawkもちゃんとロケール対応してるべき? SUSのバージョンにもよる?
gawkは対応してるみたいね

**デフォルトの名無しさん** · 2023/02/25(土) 06:59:37.00

>>826
付いているし、そんな質問されても意味がない

**デフォルトの名無しさん** · 2023/02/25(土) 08:46:26.36

>>821
現実的で一番良い結論だと思うｗ

**デフォルトの名無しさん** · 2023/02/25(土) 08:48:27.98

現実的っていうのはEUC-JPで書かれた
ウェブサイトが見れなくなるってこと？

**デフォルトの名無しさん** · 2023/02/25(土) 10:28:54.79

文字のエンコーディングは通信相手同士で取り決めろということ
相手がEUC-JPで送ってくるならこっちもEUC-JPで受け取れば良いこと

**デフォルトの名無しさん** · 2023/02/25(土) 10:44:41.98

今後はファイルや外部通信はUTF-8がデフォルトになる
デフォルトの意味が理解できないド素人がいるみたいなので書いておくと
「アプリは特に文字コードの指定が無かった場合はUTF-8で出力するべき、指定が無かった場合はUTF-8として読み込むべきである」ということ

つまりBOMが無くてもUTF-8とみなすべきなので、UTF-8にBOMは不要

**デフォルトの名無しさん** · 2023/02/25(土) 12:47:05.63

>>832
お前が気まぐれに「不要」と宣言したら、他人は良きように計らってくれるとでも思っているのか？
BOM付き文字列が送り込まれた時にどのように処理するかを決めないことには、なにも進まないぞ

**デフォルトの名無しさん** · 2023/02/25(土) 14:33:50.87

通信はともかく、問題は過去に作成された膨大な数のUTF-8以外のファイルだ
とりあえず開いてみて、文字化けしたらエンコードを指定して開き直してみろ?
そんな対応じゃクレームが大量に来るし、PC苦手な人じゃ教わっても対応出来ないだろ

**デフォルトの名無しさん** · 2023/02/25(土) 15:16:11.43

ロバストネス原則(ポステルの法則)
https://makitani.net/shimauma/robustness-principle

ロバストネス原則(robustness principle)とは、「あなたがすることは厳密に、あなたが他人から受けることには寛容に (be conservative in what you do, be liberal in what you accept from others.)」というシステムやソフトウェアの開発における考え方、開発指針のこと。「送信は厳密に、受信は寛容に」とも言い換えられる。「堅牢性原則」。

他のシステムとの間で通信を行う際、処理をして送信する側は厳格なデータの仕様に準拠するべきだが、利用するユーザー側には入力データの多様性を許容して使い勝手を損なわないようにするべきである、というものである。

アメリカのコンピューター科学者でインターネットの創始者の1人であるジョン・ポステル(Jonathan Bruce Postel)が初期のTCPを規定したRFC 793において示した一節であり、それが一般化され知られるようになったものである。ジョン・ポステルにちなんで「ポステルの法則 (Postel’s law)」とも呼ばれる。

**デフォルトの名無しさん** · 2023/02/25(土) 15:34:51.75

禿丸最強でFA

**デフォルトの名無しさん** · 2023/02/25(土) 16:51:45.73

>>831
だからUTF-8を前提にできないってことだろ

**デフォルトの名無しさん** · 2023/02/25(土) 16:52:21.29

>>832
> 今後はファイルや外部通信はUTF-8がデフォルトになる

だーかーら、既存のHTMLとかでEUC-JPとかが使われてるから
UTF-8以外を切り捨てられないっての

**デフォルトの名無しさん** · 2023/02/25(土) 18:25:42.81

アップデートされずEUC-JPのまま捨て置かれたドキュメントの価値などもはや「歴史的な」価値しかない
Webブラウザで閲覧できれば十分、新しく作るシステムでいまさら対応する必要性など皆無

2000年前後の知識しか持ち合わせていない老害がいくらギャーギャー騒ごうとも
時代遅れなエンコーディングに対応するような愚を犯してはならない
毅然としてUTF-8以外を切り捨てるべし

**デフォルトの名無しさん** · 2023/02/25(土) 19:05:12.59

>>839みたいに「切り捨てる」とか強い表現を使う人は、既得権からあぶれた失うものがない負け組が好んで使う言葉。
ネットでは威勢が良く見えても現実世界では切り捨てる側ではなく切り捨てられる側。ルサンチマンを抱えている。

**デフォルトの名無しさん** · 2023/02/25(土) 19:12:22.66

「～べき」とか語っていいのはカネを出す側であって、「～べき」はカネで雇われる側にすぎない技術者が使っていい表現ではない。

**デフォルトの名無しさん** · 2023/02/25(土) 19:43:50.59

>>835
そういう歴史的なコンテクストでいうならRFC 793じゃなくて761を引用すべきでしょ

**デフォルトの名無しさん** · 2023/02/25(土) 21:32:29.38

よりによってShift_JISの5chでイキってて笑っちゃうんすよね

**デフォルトの名無しさん** · 2023/02/25(土) 21:46:01.53

🤔

**デフォルトの名無しさん** · 2023/02/25(土) 22:09:35.17

ユニコード規格 Unicode Standard にも UTF-8 の BOM は付けても良い(may)けど、非推奨(not recommended)って明記されてるのに、どうしても付けさせたいや奴がいるのはわかった

**デフォルトの名無しさん** · 2023/02/25(土) 22:43:56.85

>>839
だから歴史的な価値が高いものをお前は捨てるのかって言ってるんだよ

**デフォルトの名無しさん** · 2023/02/25(土) 22:44:39.12

>>845
非推奨だけど付けて良いわけで何の問題もないだろ

**デフォルトの名無しさん** · 2023/02/25(土) 22:52:11.76

>>847
だから、お前が一人でつける分には勝手にしろ
つけるべきか聞かれたら、「非推奨なのでつけるな」が正解。

**デフォルトの名無しさん** · 2023/02/25(土) 23:48:54.66

つけたいじゃなくて、対応できないと困ると言ってるだけでしょう

**デフォルトの名無しさん** · 2023/02/26(日) 01:34:30.84

つまり入力をどするかは置いといて、出力にがBOMはつけるなでFA?

**デフォルトの名無しさん** · 2023/02/26(日) 05:45:33.47

>>843
逆にShift_JISでも文字参照さえ使えれば問題ないという

それに言語タグみたいのもあると便利だし、もうプレーンテキストを廃止して
マークアップ系で情報のやり取りをすればいいとか

**デフォルトの名無しさん** · 2023/02/26(日) 06:00:29.38

ドレスコードを守らない客を門前払いするかを判断するのは雇われコックではない。経営者や管理人だ。

**デフォルトの名無しさん** · 2023/02/26(日) 06:40:37.52

UTF-8にBOMは付けるなでFA
付いてるやつ受け取ったらドンマイ

**デフォルトの名無しさん** · 2023/02/26(日) 15:37:46.70

付けるなと規定されているところなら付けないし
付けろと規定されているところならつける
指定が無ければ俺は付ける

**デフォルトの名無しさん** · 2023/02/26(日) 16:12:00.59

コロナ禍でマスクするのは世間体のためばかりとは限らない。
マスクしてないと入店拒否されかねないからね。
マスクしている人を入店拒否するのは反ワクチンかな。

**デフォルトの名無しさん** · 2023/02/26(日) 16:23:35.39

>>853みたいにクライアントとサーバーの切り分けできてない人、頭悪そうに見えてしまうから良く考えてから書き込んだほうがいい
BOMのせいで挙動がおかしくなることはないので、みなBOMをつけるようになる。それが現実。

**デフォルトの名無しさん** · 2023/02/26(日) 19:04:25.66

>>856
ねえよ。規格で非推奨ってなってるの出力して誤動作したら出力した方の責任。業務プログラムなら非推奨を理由に改修要求や損害賠償請求できる。規格の非推奨にはそれだけの効力がある。
趣味でやる分に好きにすれば良いけど、実務にはかかわるな。

**デフォルトの名無しさん** · 2023/02/26(日) 19:13:28.86

まさか禁止と非推奨の違いを知らないのか？

**デフォルトの名無しさん** · 2023/02/26(日) 20:41:34.15

>>856
>>BOMのせいで挙動がおかしくなることはないので
少なくとも linux のシェルスクリプト、perl, python スクリプト等は BOM つけるとエラーになって起動できない。

**デフォルトの名無しさん** · 2023/02/26(日) 22:10:02.37

Windows環境はどんどんBOMつきが当たり前になっていくから、サービス提供者はBOM対応が事実上必須になる
非推奨だからとかつけるなとか、およそ現実を見てないね

**デフォルトの名無しさん** · 2023/02/26(日) 22:12:16.04

>>860
そのマイクロソフトがBOM無しをデフォに変更したんだがな。
妄想と現実の区別がついてないんじゃないか？

**デフォルトの名無しさん** · 2023/02/26(日) 22:18:29.81

>>861
許容するようになっただけで、規定ではない。規定はあくまでシステムコードページ。
技術板だから嘘つくのは慎め

**デフォルトの名無しさん** · 2023/02/26(日) 23:13:02.63

>>862
じゃあメモ帳のデフォルトがBOM無しに変更された理由は何？
妄想くんには説明できんだろw

**デフォルトの名無しさん** · 2023/02/26(日) 23:31:02.55

>>863
Windows Subsystem for Linuxのためじゃないかな？
上にもあるとおりunix系のアプリの中にはutf8のBOM未対応のまま（というか今更いじれない？）の状態になっているからな
良くも悪しくも歴史的にメモ帳は機能がしょぼすぎてその他の一般業務向けでの影響力はほとんどない状態だから、
Excelとかに比べれば変更しやすいという後ろ向きな理由もあるだろう

**デフォルトの名無しさん** · 2023/02/26(日) 23:35:43.20

https://blogs.windows.com/windows-insider/2018/12/10/announcing-windows-10-insider-preview-build-18298/
マイクロソフトはそんなこと言ってないけどなあ

**デフォルトの名無しさん** · 2023/02/26(日) 23:40:56.18

ていうかあれか、パイプを使ったテキストのやりとり等とBOMの相性が悪そうだから、コンソール系のアプリでBOM対応は面倒だわな

**デフォルトの名無しさん** · 2023/02/26(日) 23:42:12.69

>>865
いや、webの標準はunix系のコンソールアプリでしょ？

**デフォルトの名無しさん** · 2023/02/27(月) 00:05:34.15

リンク貼った人がいるので正解は
Microsoft の主張は「WEBの標準はASCIIと互換性のある BOM 無しの UTF-8 だから、それに合わせるため変更した。これは重要な改善である。後方互換性のためにBOMつきも可能にしといた」

BOMなしは改善、BOMつき後方互換性って明言してる。

**デフォルトの名無しさん** · 2023/02/27(月) 00:50:48.43

ASCIIのような化石との互換性は要らない。UTF16以上を推奨し、UTF8はASCII文字出現率が
99.5%以上のファイルに限り許容するのが良い。

**デフォルトの名無しさん** · 2023/02/27(月) 01:16:54.16

Windows10では、デバッグ機能で別のエディタを起動してるから
メモ帳を使ったことないというか、どんなだったかも思い出せない

**デフォルトの名無しさん** · 2023/02/27(月) 01:28:41.06

MSはデフォルトを変更しただけで
BOMにも対応している
つまり完璧にUnicodeに対応している

**デフォルトの名無しさん** · 2023/02/27(月) 02:25:37.58

大正義じゃないか

**デフォルトの名無しさん** · 2023/02/27(月) 02:59:07.83

もうUTF－16にはWindowsの内部コード以外の役割はないんだ
文字コード戦争はとっくにUTF-8の勝利で終結したんだネットの普及が決め手だった
残念ながら負け犬がどんだけ吠えても現実は変わらないんだ
ほら、どんどん吠えて、（愉悦

**デフォルトの名無しさん** · 2023/02/27(月) 03:10:49.85

恥ずかしい無知野郎だなぁｗ
JavaもJavaScriptも内部コードはUTF-16だってーのに

**デフォルトの名無しさん** · 2023/02/27(月) 05:48:11.01

>>873
UTF-16でどうやって絵文字処理してるのか不思議なんだよなあ
サロゲート処理必要なのに 🪟🍎🐧

**デフォルトの名無しさん** · 2023/02/27(月) 06:23:41.06

無知二匹目ｗ

**デフォルトの名無しさん** · 2023/02/27(月) 06:45:46.85

>>868
>これは重要な改善である。

甘いなあ
文字コードの自動判定を入れた、ということは、今後はUTF-8と認識できない可能性が生じる事を意味する
皮肉な話だが、文字コード自動判定のせいで事実上、BOM必須になる

**デフォルトの名無しさん** · 2023/02/27(月) 06:46:52.69

JavaのStringとか、もう開き直っちゃってる感じで「文字とはUTF-16のバイトのことでーす」
って感じじゃん。ただの16ビットの配列と何が違うんだっけあれ
まともな文字列処理をするには別途ライブラリが確実にいる。面倒じゃのう

**デフォルトの名無しさん** · 2023/02/27(月) 06:48:51.24

BOMは文字コード自動判定をスキップする顔パスのようなもの。BOMを無くしたいという意向とは裏腹に、今後BOMは益々増える。
それが現実。

**デフォルトの名無しさん** · 2023/02/27(月) 06:51:35.24

関所を沢山作ったせいで、ますます関所破りのバッドノウハウが普及する

**デフォルトの名無しさん** · 2023/02/27(月) 08:02:36.27

>>874
通りすがりだが、お前は論外
ググってトップに「Java/Javascriptは内部コードでUTF-16が使われています」と書かれていたのを読んだのだろうが、BOMつけるか論争をしている人達割り込むツッコミ方じゃねぇw
他人を煽る前に自身の読解力と理解力を見直して出直してこいw