文字コード総合スレ part14 YouTube動画>1本 ->画像>14枚

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 http://2chb.net/r/tech/1516629503/
文字コード総合スレ Part12 http://2chb.net/r/tech/1544931495/
文字コード総合スレ part13
http://2chb.net/r/tech/1593777227/

乙

Q. UTF-8 に BOM をつけるべきですか？
A. Unocode Standard では「付けたければ付けても良いが、付ける必要はないし、付けるのはお勧めしない」と規定されています。

>>1
>Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。

filesystem の文字コードと system locale についても詳しく
あとファイル名に BOM 必要かどうかも

>>3
訳し方でニュアンスが変わるから根拠となる規格の原文も載せた方が良いぞ

UTF-8, UTF-16, UTF-32 & BOM
https://unicode.org/faq/utf_bom.html

「付けたければ付けても良いが、付ける必要はないし、付けるのはお勧めしない」なんてどこにも書いてないんだが

>>4
Windowsの場合はUnicodeというのはUTF-16LEを示す模様
UTF-16LEはリトルエンディアン固定でBOMは付かないフォーマット

UnicodeといってもUTF-8ではない

>>3
何で規定されてんの？

>>6
Unicode Standard を嫁。

>>8
規格に理由は書かれてない。
規格書では趣旨として UTF-8 では Unicode をASCII互換にするための方式みたいな説明してるので、BOM をつけると ASCII互換性が崩れるのが駄目なのかもしれない。違うかもしれない。

すまそ。ここの40ページにUTF-8でBOMが許可されるって書いてあった
https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf

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

The Unicode® Standard Version 15.0 – Core Specification
https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf

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.

>>10
ASCIIは文字コードで言えば0～127までの文字
UTF-8が使う128～255はASCII互換ではない

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

一般に言うASCII互換ってそういう意味じゃねえだろ。

BOMがもし先頭以外に現れたら読み飛ばす？

>>13
ここで言われるASCII互換は、ASCII上位互換だな。
今までと同じ入力(ASCII)には同じ出力になることが期待されている。今まで勝手にBOMを付けなかったので、勝手にBOMつけるのはNGくらいの意味。

>>12
「UTF-8 の先頭にある U+FEFF は BOM なのか ZWNBS なのか曖昧なのが、UTF-8 に signature として <FE BB BF> をつけることを推奨しない理由の一つ。」
と書いてあるのか。一つということは他にもあるのか。

>>15
「BOM が不要の場合は先頭の U+FEFF は後方互換性のために ZWNBS として扱う」と規定には書かれいる。

>>18
途中で送ってしまった。
当然途中にある U+FEFF は全て Zero Width Non-Breakable Space (ここで改行禁止くらいの意味）として扱われる。

>>16
ASCIIと同じ出力になるって言うなら
0～127までの文字しか使えないじゃんｗ

まさか最初さえ同じなら、後ろは違ってもいいとかいう
意味不明な話してるの？

>>20
素人発見。

規格がどうであれ、可能な限りBOMをつけるのが最善策。

>>22
とうとう規格無視しろって言い始めた。
オレオレ基準は他所でやれ。技術者どうしの合意は規格を使う。お前に発言する資格はない。

元がASCII → UTF-8 （BOM なし）に変換？ → それはただのASCII

UTF-8に対応するのであれば
128～255を許容した上で
UTF-8の仕様に対応しなければいけない

UTF-8に対応するならBOMにも対応しなければいけない
それだけのこと

UTF-8という規格に対応するのなら
BOMにも対応しろって話だな

>>23
これは規格外をどうするかという話なので、規格の話をしても意味がないぞ
君はエンジニアにむいてない。技術者じゃなくて法律家にでもなれ。

交通事故が起きた時に、人命救助したり、クルマを安全な場所に移動させようとするのが技術者。
交通事故の責任問題ばかり考えるのが法律家。ID:JF7lH/t4は技術者にむいてない。断言する。

>>27
悔しかったら Unicode Standard 書き換えてこいや。もしくは賛同者つのって新しい規格でも作ったら？

規格が不完全でも現実として運用していかなければならないのに、規格を盾に対応を拒否するような技術者はクビだよ

>>29
規格が不完全なら規格を正しく修正するのが技術者の仕事。
お前の主張が正しいなら規格はとっくに直されてる。変更されないのは今の規格が正しいということ。

>>30
そのとおり。誰も問題と思ってないのだからBOM付きはどんどん増える

>>27
つまり文字化けという事故が起きたときに
文字コードを安全に変換できるようにUTF-8のBOMは使われているということか

うわあ時代遅れのBOM強要おじさんがまだ粘着してる
このクソくだらない流れいつまで続けるんだ、あほらし

BOMありもなしも規格では許容していて、あとはその仕様の違いを意識せずに混ぜるなというだけの話。
その一方ですべての文字コードをUTF-8 BOMなしに統一すべきだという原理主義者が存在いる構図。

規格に「推奨しない」って書かれているのをどうしても見なかったことにしたい人がいるみたいだな。

>>35
そんなに強く否定してるとこあったっけ
原文どれだ

>>12にあったw

not recommended ってのは、必要性を十分検討したうえで使えってことだな。

>>37
本体は2.6章にあるよ。12はその理由を説明してる感じみたい。

「お前が○○するぶんには好きにしろ」でいい気がするのだが
なんか相手の使い方にそれ以上踏み込んで口を出したくてたまらない人がいるのがエンドレスの原因な気がするのだが

>>40
自分が口出してるという自覚はないのか？
「UTF-8でBOMは許容されている。推奨されていないだけ。」
これが事実だろ

これ以上のことは言わんでいい

推奨されてないものを付けろだの、対応しろだの、規格無視しろだの言うから荒れてる。
つけたきゃ勝手につけろ。他人に勧めるなで終わり。

https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf#page=967

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.

BOMというのはバイトオーダーマークの略で
リトルエンディアンかビッグエンディアンか区別するためのもの
UTF-8では必要ない
これはWindowsのメモ帳のバグでM$がUTF-8にBOMをつけたのが始まり
仕方ないからUnicodeで許可されてるだけで本来はつけてはいけない

>>44
ついてた時にどうするかが重要なのであって、そこが自由裁量であり経営判断。
Windowsの資産をすべて捨てる決断をするのはカネを払う経営者やユーザーであって技術者ではない。

山茶花(サザンカ)は本来サンザカと読まなければならないのだから、今後はサザンカは受け付けない(ｷﾘｯ

>>45
お前のようなやつがいるからWindowsはいつまでもShiftJISを使い続けることになる
BOMはUnicodeでは認められていない。禁止すべきものだ。

>>45
入力がBOMつきUTF-8に指定されている場合はBOMとして処理しろ。
入力がBOMなしUTF-8に指定されている場合はZWNBSとして処理しろ。

>>47
推奨されてなくても一応認められてるでしょ
何でそこを捻じ曲げるの

ま、積極的にBOMを使うのが運用として自然だから、BOMをつけるアプリがドンドン増える。
デファクトスタンダード。

>>19
>Zero Width Non-Breakable Space (ここで改行禁止くらいの意味）

何も処理せず読み飛ばせって意味では

>>51 の補足だが
入力に(BOMありかBOMなしかはともかく)
[ZWNBS]AB[ZWNBS]CD
というデータがあれば
出力は
ABCD
になるという意味ね

>>52
先頭は無意味だがそのまま保存する。
途中のはBとCの間で自動改行禁止という指示になる。
# 家(ZWNBS)康 ってしとけば難癖つけらなくて安全だな。

話の途中ですまんのだが
ASCIIって7bitのはずなのに下みたいにどう見ても先頭に0がついて8桁あるのはなんでなんや
https://medium-company.com/ascii%E3%82%B3%E3%83%BC%E3%83%89/
もしかして先頭に0をつけて8bitにしたのがメモ帳とかでは標準の表現方法なんか？

>>54
単に 8bit = 1byte の世界で説明してるからだろう。（最近はそれしかないので、昔は 7bit = 1byte とかもあった）

そうなん？
じゃあ実際のバイナリ列は7桁なんやね

ハイともイイエともどうとでもとれる書き方なんですんのやろ

>>56
7bitマシンならそうだな

電子メールは7ビットで世界を駆け巡っているの？

大昔は一番上のビットをパリティとして利用していたこともあつたし

JSONではUTF8必須かつBOMを付けてはいけないと明確に定められてるんだな
全てがこのように決まれば文字コードで悩むこと無くなるな

ソース
https://www.rfc-editor.org/rfc/rfc8259.html#section-8.1
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.

8b/10bの10bitが云々の話になるぞ

>>54
M$がShiftJIS対応のために8bitに変更したんだろ

なんだろな。このど素人が混ざってる感じ
ASCII はもともと 1byte に 1文字を入れる設計。
6bit マシンには非対応
7bit マシンにはそのまま入れる
8bit マシンでパリティ不要なら最上位bitにゼロを入れる
という設計。最近の機器は全部8bitマシンなので最上位にゼロが入る。
（ISO 2022 拡張とかで変更できるけど）

ShiftJIS対応だけのために8bitに変更とか日本はどんだけ凄いんだよ…

本質がわかってないやつがいるが
論点はBOM禁止という話
M$のバグのために仕様を歪めるな！

将来SJIS(cp932)やそれ以外のcp(cp65001を除く)は全部無くなるんだろうし
その頃にはUTF-8にBOM付けるやつは居なくなると想定していて
その準備段階として現状UTF-8にBOM付けるべきでないってスタンス
今がんばってBOM付けろって言ってるアホは死ぬまでSJIS浸かってろ

>>67
そのとおり。死ぬまでSJIS浸かってる人は今後もずっと存在し続けるからBOMつけるのが最適解だよ。

MSがWindows12でSJIS(CP932)を異様に扱い難くくするとかの
ペナルティが無いと10年後でも平気で残ってそうだ
互換性重視のWindowsが完全にUTF-8で統一なんて20年はかかると予想

>>68
お前にとってはそうなんだろうな。後5年くらいしか生きない老害にとってはそれが最適解。間違いないな。

暴れている人は、最近覚えたCP932という単語ばかり使ってlatin-1の話が出てこないあたり、初心者っぽい。
もうこのスレに書き込まないでくれ。静かに読むだけにしてくれ。

お前が書き込むな

誰か1人が暴れていると書く人は自分が見えていない
このスレでは2人がお互い暴れている

暴れてるのはやっぱりUTF-8原理主義者の人だよなあ

原理ｗって反対の立場ですと表明してるようなもんだが
愉快犯かなにかか

もちろん反対の立場(自由主義)だよ。BOM付けても付けなくてもいいしUTF-8以外のコードも容認する。

>>61の例のように文字コードは全てUTB8で統一そしてBOMは使用不可が現在進んでいる方向だろう
文字コード問題があるおかげで喰ってる既得権益層にとっては脅威

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

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

過去のデータや文字コードは、そういうのを取り扱うレガシーなアプリケーション
（ブラウザなり古いテキストエディタなり）が対応してれば事足りるよね

今後作成するシステムは基本的にすべてBOMなしUTF8で統一、
連携対象となる外部I/Fがあればインターフェース仕様に応じたエンコーディングを採用すればよい
CSVなんかはExcelで開くことを考えるとどうしてもBOMありにせざるを得ないだろうけど
普通のプレーンテキストならメモ帳ですらBOMなしUTF8がデフォルトになってもう何年も経ってる以上
あえて今更BOMありを要件にする必要はないだろう

EUC-JPのテキストファイルにお目にかかる機会もほとんどなくなった
linuxのデフォルト文字コードがUTF8に変わったのっていつ頃だったっけ

iso2022jpもほぼほぼ見なくなったかな
メールクライアントやメールサーバでUTF8がデフォルトになってから15年位ってところか

sjisが消滅するまでEUCやiso2022jpと同じくらい時間がかかるとすれば
やっぱり2030～2040年位になるのかな

>文字コード問題があるおかげで喰ってる既得権益層にとっては脅威

そんなんで食っていけるってどんな仕事だよと思うが、本人は本気で思っていそうだな。

>>81
SMTPはまだ 7bit code が残ってるよね。
UTF-8 もBase64 でエンコードだし

>>83
プロトコルの話なら SMTPUTF8 があるよ。

インターネットの世界だとUTF-8のBOMは「つけるな、解釈するな、さわるな」だから。
20年前にRFC改定されてからはそんな感じ。

>>81
ひと昔前の海外OSSのソースコードやドキュメントはCP1252(latin)が当たり前だったな
いつのまにかUTF8で統一されたように感じるのはなぜだろう

>>86
淘汰された

なんでだと思うんだ？😠

nginxの台頭
当時はこぞってドキュメントを原文で輪読してたとか

なんで？って一瞬思ったけどロシア製だからか
koi8?cp1251どっちだとしても非キリル文字圏のwindowsだと辛いね

VS Code と PowerShell でのファイルのエンコードの概要
https://learn.microsoft.com/ja-jp/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding#choosing-the-right-encoding

システムやアプリケーションごとに使用しているエンコードが異なる可能性があります。

・現在、.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 アプリケーションではそれらに依存している可能性があります。

LinuxはBOMをうまく扱えないんやな

UNIX はパイプで複数のデータストリームが一つになったりするので，
データストリームの「先頭」とは何かがはっきりしないよね
tar のデータストリームとかどうするんだろうね

そういいながら、結局 PowerShell の新しいバージョンからデフォルトを BOM無しUTF-8 に変更してきたのがマイクロソフト流儀だけどな。
時代の流れは早いお。

>>93
そもそもtarはバイナリだ。テキストファイルじゃねーよｗ

ファイル名とか入ってるけど，そのファイル名の先頭にBOMつけるの？

Windows技術者「お前ぇぇ、WindowsアプリではBOMつきUTF-8 使えって言ってたじゃん。なんでVScodeやPowerShellの新しいの BOMなしなの？」
MS「BOMつきは昔の話」
俺「......

>>97
何かおかしいかな？

tar扉を開く

>>97
Linuxにも対応してるからだろ
ちょっとアホすぎやろ

>>96
BOMはテキストファイルの頭につけるものなの
tarはテキストファイルか？違うだろ。アホすぎ。

へえ
tarはただ元のファイルにヘッダをつけてひたすら結合するだけという認識だったんだけど
こういうファイルもバイナリファイルって呼ぶべきものなのかな

BOMつきテキストファイルならBOMつきのまま無圧縮で格納されちゃうものかと思ってたんだが
tar化するときにはファイルの先頭じゃなくなるから除去されちゃうの？
で展開するときにはまた自動でBOMがついちゃうの

途中送信しちゃったけど、
もしBOMの付け外しまでフルオートでよしなにやってくれるとしたらtarコマンドって随分と賢いんだね
そんなｸｿめんどくさい考慮せずに済ませるほうがよっぽど楽だろうに

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

圧縮されていようがいまいがこんな発想が出てくるのはただものではない

>>94 >>97
MicrosoftもBOM無しUTF8へと移行をどんどん進めてるね
Microsoft以外の一般環境だとBOM無しUTF8で統一されてしまったからね

というか、MicrosoftとLinux以外のOSがなくなってしまったんだぜ
あとmacOSが残ってるか

そういえば、テキストだけ特別な扱いはしたくないからBOMは入れてくれるなという主張はわからんでもないが
とあるそこそこ有名なOSSは逆にストリームの先頭の EF BB BF を強制的に削るという強硬策をとってたな。

今はテキストファイルの話をしてる
ストリームの仕様は関係ない話だ

あほだな。テキストのストリームとか言われたら死にそうだな。

UNIXはバイトストリームしかない中古品
C言語もWindows向けと違ってテキストモードとか実装して当然ものすら無いし

>>111
レイヤの区別をできない素人かよ

Windows の改行コードが 0D0A なのはMSDOS の名残
C言語の \n は1バイトなのだが，これを2バイトでも処理できるように
苦し紛れに作ったモードがテキストモード

こんなスレにおるのはほぼオッサンなんだけど
キミに学びがあったのならよかった

最後の方の Unix の記述は間違いだな。ちゃんと調査せずに適当な風説を元に回答したようだ。

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 はこの仕様を引き継いだ。

>>113
タイプライターの名残やろ

CP/Mのパクリをしなければ改行にCR+LFを採用する必要はなかった
まあこのパクリのおかげでCP/M86に勝ったんだけどね

レトロmac: "CR" ぼくも忘れないで

>>120
お前は深く考えてない玩具 Apple II の文字コード継承しただけじゃないか？ 正直に白状したまえ。

Macはワンボタンが素晴らしいと思ってるし、画面下にアプリ切り替えバーなんていらないし、UNIXなんてクソだからCRを使った

CRはCarriage Returnで行頭に復帰
改行はしない

それ端末の動作だし
だからなんやねん

読むときは CR(単独) が来ようが CR+LF(連続) が来ようが LF(単独) が来ようが LF として処理する
描くときは LF のみ描き込む
これが正しい在り方

問題はCRとLFとCRLFが混ざっているときだ

LF, CR, LF, LF, LF, CR ときたら何行改行するか問題。
CR+LF 派にこれを突きつけると、 言行がバグる人が多い。CR+LF派は脳に欠陥があるに違いない。

>>127
LRの次がCRだったら無視する（読み飛ばす）
CRの次がLFだったら無視する（読み飛ばす）
で問題なし

CRLFで1回、CRで1回、LFで1回だろ？

LF派：誰に聞いても同じ回答を返す
CR+LF派：人によって回答が違う。謎のオレオレ理論を説明しだす
CR派：問を無視してアップルへの恨み言を言い始める

BOMは諦めて今度は改行かね

>>131
ﾜﾛﾀ

CRは先頭位置に戻す
LFは行替え
だから>>127は4行改行して先頭位置になる

>>133
本来はそんなんだけど
タイプライターで打つときにそれだと二動作必要になるので
一動作でcr+lfにするようにした
これが混乱の始まりかも

>>133
つまり先頭位置にある時には CR は不要で LF だけで改行すべきで、
毎回 CR+LF を出力している某OSは無駄と言いたいの？
それでは CR+LF 派とは言えないよな？

HTTPプロトコルは改行がCR+LFなのはどうして？

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

ほー、ってことはWindowsも
そういった互換性を大切にしてたんだな

むしろ>>127なんて通常はあり得ないって事さ

>>138
まあ、そうだな。
Windows が大事にしたのは MS-DOS との互換性で、
MS-DOS が大事にしたのは CP/M との互換性で、
CP/M は大昔の汎用機と同じくらい古臭い<BS><BS><BS>シンプルな設計だったというだけだな。

UNIXは元々研究用だからね
互換性なんか考えちゃいない
だからUNIXはBSD系とSystemV系に分離した
多くのコマンドの互換性がなくなった

>>141
歴史をまったく知らない素人妄想だな。
Multics で導入されたテキストデータの抽象化とか知ってるか？

http2以降はヘッダに改行なくなったんだね、、、

>>141
多くのコマンドの互換性ってたかだかオプションが違うくらい
シェルスクリプトでどのバージョンでも対応できた

>>142
知ってる。お前のターン。
俺を論破してみせろやｗ

>>144
歴史を知らんのねｗ

知ってる→実は何もわかってない
知らんのかね→自分が何も知らない
どうして、こういう知ったかぶりする小学生みたいんな奴が混ざってるんだろう？

コマンドラインにプログレスバーを出したり
固定レイアウトでリアルタイム更新する画面とか
きちんとCRとLFは区別されてるって感じる

BOMは文字コード？
ZWNBSは文字コード？
CRは文字コード？
LFは文字コード？

>>147
俺のこと言ってる？

「知らんだろ」っていうやつは、
自分が知らないことを相手に要求して
揚げ足取ろうとしているだけだから
「知ってる」っていうと相手に大ダメージを与えられる

知ってた？

知っとって知らんて言うのは犯罪やぞ

>>150
無知なやつは恥も知らんなwww
自分が知らないから相手も知らないはずwww

UNIX終了wwやはり正義はWindowsだったwwww

Unix is dead. Long live Unix!
https://www.theregister.com/2023/01/17/unix_is_dead/

Unix というか Linux に徐々に移行でしょ
メインフレームやスーパーコンピュータはLinux になっちゃたし

>>153
タイトルすらまともに読めてなくてｗ
その記事
IBM が Redhat 買ってこれからは Linux を始めとする unix-like の時代。AIX とかの(旧来の) Unix は終わり。
Windows についてはマイクロソフトも WSL を頑張ってるとしか書かれてない。

そもそも文字コードに何の関係が？

>>141,153
お前 UTF-8 に BOM つけろ君だろ
教養が感じられないあたりがそっくり
主張が通らなかった、腹いせにスレを荒らすな！

>>156
アホ化。逆だわ
UTF-8にBOMつけるな
あれはMSが歪めた仕様
元々はバグだ
シランなら黙っとれ

このスレは以下で全員が一致している
・文字コードはUTF8で統一
・UTF8はBOMを付けない

＞ LinuxやMacでは、ファイル名やメタデータから文字コードを判断することが多いので、BOMは不要です。

これマジ？

BOMって、 UTF16とかじゃないと意味が無いやん？

一応は出典付きになってんだからそれ辿って判断しろ

mac のファイルシステムはリソースフォークを持っているので
そこにTextEncoding を格納しておけば良い

>>159
出典を挙げてくれるところが親切だな。そのqiitaどこ？

Windows のファイルシステムは拡張子を持っているので
そこが .txt なら BOM 無し UTF-8 を前提にして良い

おいおい
Windowsで.txtなんてそれこそ山程CP932のファイルがあるだろう(日本の場合)
それらは全て無視かい

>>165
そいつらは将来に備えて .sjt とかにでも改名しとけw

UTF-8を使う俺が困らなければ他人はどうでもいい。

>>167
UTF-8を使う俺＝将来のお前
どうせ嫌でも皆がUTF-8を使うことになる
遅いか早いかの違いでしかない

遅いか早いか、まさにそこがポイントだわな。
100年後には確実に死んでいるだろうからといって明日すぐに死んでもいいなんて考える人はまずいない。

あきらめろ！もう勝負はついてしまったんだ
今は粛々と対応を進めるフェーズだ
早く対応するほど傷は浅くてすむぞ

>>166
むしろ新しいほうが.utf8のほうが合理的かと

>>171
あきらめろ。どうせSJISのファイルは無くなるんだ。
何ならSJISのテキスト .txt ファイル今後一切作らなくても生きていける。 UTF-8はそうはいかない。

春休みっぽいね。

今日は日曜日なんだぜ。仕事引退したご老人は気づかんかもだが。

C言語でShiftJISからUTF-8に変換するコードをライブラリは使用しないで書いて下さい。

以下はC言語でShiftJISからUTF-8に変換する簡単なコードです。このコードでは、ShiftJISの1バイト目が0x81以上0x9F以下または0xE0以上0xEF以下の場合には2バイト文字、それ以外の場合には1バイト文字として扱います。

#include <stdio.h>

void sjis_to_utf8(char *sjis, char *utf8) {
unsigned char c1, c2;
while (*sjis != '\0') {
c1 = *(unsigned char *)sjis++;
if (c1 <= 0x7F) {
*utf8++ = c1;
} else {
c2 = *(unsigned char *)sjis++;
if ((0x81 <= c1 && c1 <= 0x9F) || (0xE0 <= c1 && c1 <= 0xEF)) {
*utf8++ = ((c1 << 8) | c2) + 0x3C00;
} else {
*utf8++ = c1;
sjis--;
}
}
}
*utf8 = '\0';
}

int main() {
char sjis[] = "こんにちは、世界！";
char utf8[100];
sjis_to_utf8(sjis, utf8);
printf("%s\n", utf8);
return 0;
}

ShiftJISって表現だと文字集合定まらないのに回答もらえんだ
どんだけクソ記事多いんだよ

>>162
macのリソースフォークとか、知識が化石だな
今は大概のファイルシステムが拡張ファイル属性をサポートするので、そこにメタデータを
記録することが可能

apfs はxattr もresource fork も両方使える
named resource fork は無くなってるが

>>175
バッファオーバーフローのチェックがなく不合格

それ以前の問題だろ。>>175はChatGPTに作らせたんじゃね？

AIによるプログラミングはまだ無理だね

AIって、コンピュータのくせに自分でトレース実行してバグ無いか確認しないのなw

検算してもその検算が正しいかどうかすら自身が持てないのがchatGPT

WindowsだがExcelもWordも入れてない
自分のHDD/SSDにはSJISで保存されたファイルなんてもうほぼ存在しない

今MacユーザーになるともれなくUnicode絡みの問題が付いてくるよ
https://applech2.com/archives/20230402-nfd-and-nfc-issues-in-macos-13-3-ventura.html

>>185
Mac が定期的にかかる病気。
すぐ治るけど、時間をおいてまた再発する。

Macは日本の野党と同じで世間からの評価が甘いよなあ。
Macが基幹業務で使われてない何よりの証拠でもあるが。

地震ないのに自信たっぷりに回答するのがChatGPT

ｸｴｰｯ!

知らないことは知らない
調査した限りでは存在しない
そういう答えのほうがいいのに
なんで捏造するんだろうね

そういうのはだいたい、知らないと答えたらひどく怒られた経験があって委縮して育ってしまったんだと思う

自信たっぷりに嘘を答えるから
文系はすぐにだまされるωωω

キャラ名に「ソ」があると画面がフリーズ　Switchの新作ゲームにバグ　制作会社が謝罪
https://www.itmedia.co.jp/news/articles/2304/14/news119.html

>>193
ShiftJISならバックスラッシュ誤判定だろうけど、ShiftJISなわけないよな

浅慮すぎるのは置いといて
ゲームだし手軽にバイト長固定で処理したかったは十分考えられる

芸能人は化ける

ネットの論調は「ソ」と言ったらSJISバグみたいになってるけど今時ありえるだろうか？
もし事実だとしたら旧作からライブラリか何かを移植して流用したのかな？

「ソ」とか「ポ」を含む文字列で壊れる問題、昔はS-JIS絡みで時々見かけたね

ここで念のため
<!--美乳-->

ノーパソ

XAMPP は、MSYS2 なのか？
Windows のsjis(CP932), MySQL, PHP を使っているのかも

Ruby on Rails では、日本語のバグを避けるため、
Linux, UTF-8, PostgreSQL しか使わない

>>193
アイディアファクトリー(コンパイルハート)のゲーム開発の求人には、

C/C++, C#, Windows, Unity と書いてある

Unityの文字化けを解消する！
https://qiita.com/kumi0708/items/2f8dd2fc2ccb673ff12b

UnityからC#のスクリプトファイルを作成するとUTF-8(BOM無し)になりますが、
VisualStudioはUTF-8(BOM付き)じゃないとコードページを解釈できずにShift-JISになってしまうようです。

WindowsがUTF-16だと知らないのは不思議だな

SwitchとWindowsでBOMなしテキスト使ってると、結構困ったことになるんだよね
char：Switch=utf8 Win32=sjis
wchar_t：Switch=utf32 Win32=utf16
char16_t／char32_t：対応しているライブラリが少ない

ターゲット固定なのにそんなのある？
ネットとか客先とか何くるかわからん状況じゃないんだし

Windows はUTF-16 か。
確か、Ubuntu はUTF-32 とか？

たとえLinux 内部で、4バイト文字を使っていたとしても、
Ruby などのウェブ系言語では、UTF-8 前提でモジュールを作るでしょ？

CP932 の「表・ソ」などのダメ文字は、数十年前の話

一方ビックカメラは令和でもSJISを使った

>>208
5ch…

〄🆗

森鷗外��る
森鷗外𠮟る

森鴎外(´･ω･`)ｼｮﾎﾞ-ﾝ

＆＃ｘHHHHH； で5桁以上指定出来ないのは HTML のバグ？

“𠮟る” と “叱る”
https://hydrocul.github.io/wiki/blog/2014/1201-shikaru.html

>>213
え？

痛い痔

字にはヒラギノール

Macで古いmp3を取り込んだらID3タグが文字化けしまくり
昔はコード変換のユーティリティとか持ってたけど、どうすべきかな

坂本龍一は言いました「芸術は長く、人生は短し」
音楽ファイルは長く、文字コードは短し

教授死んで済々したわ

ふと思ったが、令和の令って、手書きでどう書いてます?

「令」の下側の部分、活字だと「つ」に縦棒みたいになってるけど、手書きだとマみたいに書く人は
少なくないと思う。でもこれって中国語の活字体に近い
実はこんなレベルで「統合」漢字ですか?

>>220
今どき手書きしない。
ここ20年くらい住所氏名電話番号くらいしか手書きした覚えないなあ。あとは問診票の体温とかか

>>220
あえて言うと、もともと歴史的には明朝体(印刷用)字体と楷書体(手書き)字体の差なので、手書きの時にマになるのが普通のこと。
「はしご高」とかも本来は楷書体(手書き用)で、明朝体(印刷用)は「くち高」。
この辺の歴史を忘れちゃって別字だ同字だ異字体だと言って混乱してるのが現代人。もともとは単に書体の違い。

昔は詳しくない層はうろおぼえで何となく近い文字を同じ文字と認識してたんだろうけど
今は正確に同じ形を出力できるようになったぶん「なんか違うぞ」と目に留まりやすくなってしまったんだな

悪いのは学校教育。
昔の人は明朝体と楷書体は完全に別物という認識で区別がついてた。本とか新聞とかで見るのが明朝体。手書きは楷書体、戸籍は手書きなので楷書体だった。
ところが明朝体と楷書体の両方の特徴をもった中間の「教科書体」という書体を作って小学校で文字を教えるようになった。このせいで多くの人にとって書体間の差が良く分からなくなってる。

書道とか専門的なことをやれば気付くのだが、普通の人は明朝体と楷書体の違いが理解できない。
というか両方間違いで中間の教科書体が一般的文字と信じてる。そういう現状に合わせるためにフォントの明朝体や楷書体も学校教育文字については教科書体に近づけるようデザインされるようになってる。

日本の明朝体フォントの「令」は珍しく昔ながらの明朝体の字形が残っていて、教科書体(楷書）寄りに改変されてないので、手書きと違う字形になってる。

※1　どうしてもunicodeのCJK総合漢字から新字体と繁体字と簡体字を切り離してリストアップしたかったんです
散々調べて下のそれっぽいコード例を発見するものの、さっぱりで残念
https://qiita.com/Saqoosha/items/927e9d6e77922ad9f08a

膨大にある造語めいた気持ち悪い繁体字と簡体字をPC環境から排除するため、フィルターへそれらのunicodeを登録したいのです
繁体字または簡体字のunicodeリスト、メモ帳などへ抽出したテキストリスト、上記目的を達するのに最適なソフトなど
何かしら情報はないものでしょうか

※2
unicodeを紹介してくださるサイトを、そのまま丸コピして手元へ資料化すれば？と考えるものの著作面で不安
HTTrackというオープンソースのソフトを発見しましたが、古い上にソフトへ通信権限を与える類いのようで、下手なネトゲよりリスク高い
何より資料として閲覧可能になるのは嬉しいものの、繁体字と簡体字を排除する本来の目的に沿わない

↑全てをすっとばして、CJK総合漢字から気持ち悪い繁体字と簡体字のunicodeを抽出する方法、既存のファイルやリストなど、がありましたら解決する話です
アドバイスくださいm(vv)m

意味不
統合されてるんだし

unicodeにおけるcjk統合漢字は、一つの意味に対する漢字を〇△□×と横並びさせて、それを終えてから次の意味の漢字へ移行する配列となっています
だからこそ〇しか要らないのに4E00から9FF0の中で膨大な△□×という文字のゴミが無作為に溢れてしまうのです
しかも支那は性懲りもなく使いもしないゴミ文字を未だに造り続けているので、unicodeは5桁にまで膨れ上がっています（そろそろ整理しろよ！新語を作んなボケが！！使わねー字なら抹消しろ！と）
「漢字」と一括りにするのではなく、そこから真に必要で有用な新字体のみを抽出したい、あるいはフィルター用に新字体以外のゴミunicodeリストを欲しい、と思うのは必然ではないでしょうか
そのくらい、今の支那はあらゆる分野で癌と化していますよ^^;

ですよねえ・・・
qiita.com/Saqoosha/items/927e9d6e77922ad9f08aさんの例がまさに自分の環境でも活用可能な案だったのですが、古い上によく分からなくて^^;
日本語に用いられる漢字＝新字体は、象形文字状態の造語・当て字ばかりで非文明的な繁体字・簡体字と比較すると、めちゃくちゃ秀逸かつ言語内に上手く纏められているんですよ
集約とも言えます
1949年の内閣すげー！！！

それも平仮名や片仮名という3種の文字列を組み合わせて歌を詠んだり、そうした世界屈指の難解な文字文化を経たからこそ、私達の先祖は新字体という完成度の高いものを作れたんでしょう
今現在、支那チョンに使われる言葉の多くは「日本語由来」ですしね・・・
文字においても漢字なのに新字体が一番最初に確立されている不思議
その史実を虚偽で覆い隠さんと、いつもの共産圏の捏造焼き畑で無駄な簡体字が、延々造られ続け、unicodeを圧迫しているのが昨今の実情です
やることなすことGと一緒で美も詫び寂びも無い、ただ増えるだけの癌に等しい存在と価値観が、まさにチャイナの本質ですね^^;

文字コードのことも漢字のことも何も分かってなくて草。
お前は日本語専用フォント使っとけ。

まあ、統合なんてせず、他はどうでもいいから新字体だけは別枠でunicodeに登録してほしかったですね
そうすれば、ここからここまで理論で新字体とそうでないゴミ象形オナニー文字とを正負ともに区別出来たんですわ・・・
他の地域はそれぞれの民族単位で登録されていたり、誤差の範囲内でもきっちり枠が設けられているのに
東アジアの区分だけ何故かごちゃ混ぜで笑えますよ（拡張ABCDとかやってる暇あんなら新字体だけでも別枠にしろ！）
unicodeを制定する世界の上層部が、如何にアジア圏をどうでもよく考え、雑に一括りとしているか分かる話ですなｗ

文字コード | 衆議院議員 河野太郎公式サイト
https://www.taro.org/2023/05/%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89.php

>>232
2023年になってから取り組んでも無駄だろな
無理やり押し付けて既存のシステムが崩壊し日本はますます貧しくなる

国賊親子だからそうやって日本の国体を壊し、貧困化の延長を謀るのがこいつらの本懐だからな^^;
自分達だけは生かされると思っているのだろうけど、支那の歴史は例外なく相手国で利敵に走った屑を真っ先に親類縁者ひっくるめて惨殺して口封じとした
俺らパンピーやその子孫が絶望の中にいるとき、こいつら当人は他界し、その子孫は既にもがき苦しんだ後っしょ
ま、俺らの将来も支那の臓器牧場候補だろうけど、その前に必ずこの国賊達が総じて臓器強奪や人肉食の材料になる点だけ、留飲を下げる要素だろうね

CJK統合漢字
https://ja.wikipedia.org/wiki/CJK%E7%B5%B1%E5%90%88%E6%BC%A2%E5%AD%97

1984年、ISOの文字コード規格委員会 (ISO/TC 97 - SC2) は文字セットの切り替えを行わずに世界中の文字を単一の文字集合として扱える文字コード規格 (ISO 10646) を作成することを決定し、専門のワークグループ (WG2) を設置した。当初、この文字コード規格は16ビットを想定し、その中に日本や中国など各国の漢字コード表をそのまま入れることを想定していた。しかし中国はこの方式では自国で現在策定中の漢字コードが全て入らなくなるとしてこの方針に反対し[要出典]、1989年、各国の漢字コードを統合した漢字集合HCCのアイデアを提案した。

1990年、完成したISO 10646の初版ドラフト (DIS 10646) では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対しており、今後の漢字コードの方針を決めるため、ワークグループはCJK-JRGと呼ばれるグループを別途設置し、そこで引き続き検討することにした。

>>222
なるほどー。

そうすると統合漢字も自然なものに思えてきますね。国や言語毎に字体が違うだけなんだと。

漢字の場合、国・言語ごとの字形の違いは
アルファベット書きの単語における国・言語ごとの綴りの違いに近いと思う。

同源の単語であれば他言語の綴りで書かれても一応意味は分かるが、
決してそれが自然だとは思われない。

漢字は統合によって「元の綴りがどうだったか」の情報が残らなくなってしまったので
言語判定をさぼってフォールバックフォント表示を通常運用にしたような環境では
他言語の綴りに化けた文書に頻繁に遭遇することになり違和感が募る。

同じ漢字でも、簡体字って全然読めないよ…
違和感なんてレベルじゃないよ、あれ…

おばあちゃんが書く門の略字体なんかは今の子読めなかったりするね

不思議な漢字と日本語──異体字の謎
https://tenki.jp/suppl/hiroyuki_koga/2015/05/18/3961.html

実は、意味も発音も同じなのに異なった字形の漢字は、紀元前約1600年前に中国で誕生した、漢字の原型である「甲骨文字」からあります。
このことはなにを示しているかというと、異体字は主に手書きの文字だからこそ生まれるということです。手書きであれば、点画が短いとか長いとか、おさえるとか払うとか表現が人によって変わってしまうことは当然ですね。それまで使われていた文字があるときにちょっと異なったふうに書かれて、それが誤字となって消えてしまうのではなく、多くの人がそう書くようになってある程度定着してしまう…しかも前の書き方も生きている…。これが異体字の源泉です。楷書、行書などの漢字のスタイルである「書体」も関係しています。

異体字は人名や地名に多いですね。
地名については、言ってみれば「なまり」のようなものだといってもいいかもしれません。人名であれば、漢字の字形の差が自分の個性のようなものと感じられて「渡邊」と書かれないと、自分ではないような気がする、といったことも起こってきます。

文字は社会のなかで共有されているものですから、自分勝手に書いていいというものではありません。ただ異体字だからといって、「間違っている文字」というわけでもないのです。正字・旧字・本字・俗字…といった区別は、漢字の使われ方を標準化するためにある社会・時代で便宜的に決められた「正しさ」の基準ですから、時代によって変わることもあります。日本でも当用漢字、常用漢字、人名漢字などとしょっちゅう漢字の枠組みが変化していることはご存知でしょう。
現在ではコンピューターや携帯電話などで表示できる漢字の数が飛躍的に増えたことで、この枠組がまた変化しています。時代の変化とともに、そして技術との関係で漢字はどんどん変化するものなのです。

>>238
新字体もいわば簡略字体なわけで、まあ違和感があるかどうかは慣れなのかも

>>239
簡体字だと门ですよね。というわけで昔の世代の方がより簡体字を読める?

中国語での発音が同じという観点で共産党が簡体字を作ったので
日本の老人とは関係ない

簡体字には二種類の起源があって、難しい漢字のかわりに手書きの略字を形を整えて正式採用したものと、めったに使わない漢字を廃止して意味や音の似た別字で置き換えたもの。（民間の手書きでは難しい字を宛て字で置き換えるのがよくある話）
実は日本語でも政府は同じようなことをやってる。「編輯」の「輯」を廃止して別字の「集」にするよう指示したり、「叡智」を別字の「英知」に置き換えたり。
中国(大陸)は日本より徹底的実行しただけ。

英知バウ子

>>243
障碍→障害は酷すぎた

>>245
これは「前からどちらも使われていたのが片方に統一された」だったはずで
一般に言われているほどではない

>>246
昔から両方あるけど、違う意味で使い分けられていた。
障碍：じゃまな物があって進められないこと
障害：危害を加えられて進められないこと

当用漢字で碍を害に置き換えたせいで、この2つが衝突した。「妨碍」を「妨害」に統合した関係も似たような感じ。前者は邪魔な物を置いて、後者は傷を負わせて。

碍を害と統合するとか unicode 以上の暴挙。
国語審議会には漢字廃止論者がいたので仕方ないね。

近頃は漢字を使うことをあきらめているケースも多いよね
こ線橋とか

こうしちゃおう
跨線橋
↓
股線橋

>>247
まさにそれが俗説
https://www8.cao.go.jp/shougai/suishin/seisaku_iinkai/k_54/txt/s3-2.txt

>>251
俗説でも何でもないだろうが。
引用されてるやつも、昔から混用があったことを指摘してるだけで、害と碍が統合可能な根拠などどこにも示していない。
難しい漢字や頻度の低い字を同じ音の別の漢字で代用するのは大昔からあった習慣。それこそ甲骨文字の頃からある。
しかしあくまで代用は代用。

戦争で片足を失った。→ 身体を傷つけられているので「障害」でOK
生まれつき目が見えない。→ 誰かに危害を加えられた訳ではないので「障害」はNG
使った例があるかどうかじゃなくて、正しく使われてるかの問題。

＞当用漢字で碍を害に置き換えたせいで、

嘘はここだな。
その流れは戦前からあったと。

>>254
昔から混用があったのと、政府が正式に使用を禁止したのでは全然意味が違う。

＞当用漢字で碍を害に置き換えたせいで、この2つが衝突した。

せいで衝突したんじゃないな。

>>256
衝突してるじゃん。学識がある人には使い分けができてたのに、使い分けが禁止になってる。

それよりも前から衝突はしてるだろう。
あと当用漢字をそれ以外の「禁止」とするのもまた嘘だろう。
学識がある人はあれと「禁止」は区別がつくから心配には及ばないだろう。

話を戻すと大陸の簡体字も同じやり口。
「機」の略字が「机」なわけではなくて、難しい漢字の「機」を廃止するんで、同じ音の「机」を使ってね。民間の手書きとかなら机って書いて人もいただろみたいなの。

話を戻してて笑った。

>>258
当用漢字は禁止だよ。公文書、学校教育、新聞などでの使用ができなくなった。
当用漢字が廃止されて、常用漢字の制定で推奨に変わった。

使用が一切認められない「禁止」ではない。
そして「話を戻すと」、せいで衝突したんじゃないな。

当用漢字表
https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kakuki/syusen/tosin02/index.html

使用上の注意事項
イ　 　この表の漢字で書きあらわせないことばは，別のことばにかえるか，または，かな書きにする。
ロ　 　代名詞・副詞・接続詞・感動詞・助動詞・助詞は，なるべくかな書きにする。
ハ　 　外国(中華民国を除く)の地名・人名は，かな書きにする。
　ただし，「米国」「英米」等の用例は，従来の慣習に従ってもさしつかえない。
ニ　 　外来語は，かな書きにする。
ホ　 　動植物の名称は，かな書きにする。
ヘ　 　あて字は，かな書きにする。
ト　 　ふりがなは，原則として使わない。
チ　 　専門用語については，この表を基準として，整理することが望ましい。

原則となる調達基準が制定されてそれ以外が入りにくくなったみたいな話だよね
こういうの一言で言えば何なんだろう？「ルール」？

簡略化は一貫性がない場合もあるのな。傳->伝、團->団とか

異体字はその定義があいまいだから、IT技術者の仕様都合でどうにかできる話ではないでしょ

UTF-8をよく見かけるけど
7とか6とかも昔はあったんですか？

8ビットスルーでない経路が絶滅危惧種だし
HTTPで無駄にUTF-7なんて使っても知らんいわれるのがオチ
つかうにしてもプログラム書かないといけないならBase64のが筋がよさそう

UTF-5のことも忘れないでいてあげるべき

UTF-5 ‐ 通信用語の基礎知識
https://www.wdic.org/w/WDIC/UTF-5

UTF-1は美しそうだ

やっぱり色々あるんですね㌧
これからも増える可能性もありそうですねー

・・・ギャグで言ってるつもりなのか本気でそう思ってるのか判断がつかないんで一応補足しとくと
「UTF-#」の#はバージョン番号じゃなくて
Unicodeの文字を何ビットで表現するかを意味してる

基本的には16Bitで表現するUTF-16が一番楽
サロゲートペア文字もそうでない文字も同じデータ長として管理するなら32Bit表現のUTF-32がよい
だが現状はAsciiと互換性のある8Bit表現のUTF-8が事実上の標準となった
UTF-7はデータビット数を8⇒7に減らすことで少しでも通信速度を稼ごうとしてた昔の通信経路向けの規格

>>272
バージョンじゃないんですか、詳しくありがとうございます！

>>272
あんまり知ったかぶりすんな
>「UTF-#」の#はバージョン番号じゃなくて
虚偽、UTF-1 とか UTF-2 はバージョン

> 基本的には16Bitで表現するUTF-16が一番楽
虚偽、（もしくは個人の感想）

> UTF-7はデータビット数を8⇒7に減らすことで少しでも通信速度を稼ごうと
虚偽

>>238
毛沢東文字やね
あれはスパイを発見し易くするために導入された

>>272
>サロゲートペア文字もそうでない文字も同じデータ長として管理するなら32Bit表現のUTF-32がよい

doubt

64bit版g++は、規定のstd::wstringがUTF-32だよ

規定じゃなくて既定だった

>同じデータ長

doubt

ネタとして楽しむためには正しい知識がいる、という

文字コード奥深過ぎだなアニメ化して欲しい

IVSなめんな

ペロッ...これは、0xE0100で修飾された異体字!!

文字コードソムリエですね

\ソムリエ

漢字構成記述文字 IDSは何処かで有効活用されているのですか？

今の字体の見た目の直感と違うのですが
黒 →⿱里灬 ダメ？

https://kanji-database.sourceforge.net/ids/ids-analysis.html
>解字ＩＤＳデータは、UCS漢字を、字の成り立ちからIDS化する作業を行っています。

U+09ED1 黑 ⿱𡆧炎 會意 3840010
U+09ED2 黒 →黑
https://github.com/cjkvi/cjkvi-ids/blob/86b4d16159f0079437870408f0ca186e529015db/ids-analysis.txt#L18185

見た目じゃなくて成り立ちだから歴史的経緯からIDS化してるんじゃね

簡体字制定時にも過度の正規化に反対する良心的な人もいたみたいだけど…結果は文化継承お構い無しむしろ断絶こそ業績みたいな御用学者に押し切られた？わけで
一旦決まったからはあの面子の国、則天文字やルイセンコ学説宜しく滅ぶまで使い続けるんだろな
という訳で今すぐ滅びろ

二簡字ぐらいいくとかっこよくも見えてくる

utf-8が標準だと思ってたけど昨日Excel見たらutf-8じゃなくてビックリした

メモリ上の内部コードはしらんけど
xlsxはXMLだからUTF-8じゃない？

文語で「じゃない」を使うおじさん

お姉さんの可能性あるで
俺もお姉さんだし( ･`ω･´)

>>291
他の人のExcelも今度確認してみるわ

XML は BOMつき UTF-16 も許されてるんじゃなかったっけ？
BOM無しなら UTF-8 だったか

excelは昔からさまざまな文字コードに対応してる
高い互換性を維持し続けてる
それがMSの強さ
こういうところはUnixとかLinuxとかOSSでは
太刀打ちできない

>>296
emacs だってexcel 以上に多種多様な文字コードに対応してるし、linux (glibc)の対応ロケールと文字コードの数は windows より多いぞ。
無知が擁護するとMSの格が下がるのでやめとけ。

>>291
そうだね。実際には階層的になったXMLをzipにしてあるけど

んでXMLの中をよく見るとxlsxを作成したローカルのパスが書かれていたり。キモっ
おっと文字コード関係なかったw

Microsoft が互換性重視とか最近のブラックユーモアは笑えないなぁ
ASCII との互換性を切捨てて UTF-16 にしようとして失敗したり
5年以上前のCPUは Windows 11 ではサポートしません、買い替えてくださいとか言い出したり
その頃 linux では33年前の CPU の 80486 の互換性はそろそろ切って良いのではという議論をしてた。

2012年頃?
Windows10 が最後の Windows バージョンです(キリっ

MSはJIS X 0213:2012のIVSに
Wordが早く対応したりしてそれほど悪い印象はない
しかしパス名が未だにCP932系なのは何とかならんのか

>>301
ロケール設定とアプリの問題じゃないの？

近年のMSは、昔からの独自仕様での高い互換性よりも、オープンソース＆標準準拠を進めているのは良い

>>302
日本ロケールだとNTFSのパス名がShift JIS

ファイル名で使用される文字セット
https://learn.microsoft.com/ja-jp/windows/win32/intl/character-sets-used-in-file-names

＞ NTFS では、Unicode にファイル名が格納されます。

>>304
そういうのはコンソールやアプリ側のエンコーディング設定であってな...

UTF16はMBCSと共存しており切り捨てた訳ではない
windows11で64bit版だけになるまで16bitアプリも動かせてたわけで
そもそもソースレベルでしか互換性を保てないのがLinux
Linuxは当初はEUCだったと思うけど当時の日本語対応ソフトが今のUTF8で動くかい？

>>307
あほ？ EUC-JPアプリって何？
２0年前にコンパイルされたアプリが一切の改変無く、EUC-JP でも、UTF-8 でも SJIS でも動くんだが？
ロケールの切り替えとか知ってる？

>>308
Linuxで20年前にコンパイルしたバイナリが今のLinuxで動く？
冗談はやめてほしい
百歩譲ってロケール切り替えで動くとして今のUTF8前提のアプリと共存出来ないでしょ
Windowsだったら20年前のMBCSのソフトもそのまま動くよ
当然Unicodeのソフトも動く
Ubuntuが32bitCPUのサポートカーをきったのは5年くらい前だっけ
Windows11より速いですね
あとマイクロソフトがMBCS切り捨ててUTF16一本にしようとしたってのは初耳ですが根拠を出してほしい

>>309
技術がないやつは、これだから。
お前の技術が足りないのをOSのせいにしてるだけだな
全部できるぞ。俺が実際使ってるし
Ubuntu で32ビットアプリも動いてるよ

コンパイルしたなら文字コード関係なくそりゃ動くわな。
スクリプト言語なら知らんが。

スクリプト言語のが文字という概念があるから
ロケールみて外部入出力ちゃんと取り持ってくれそう
昔のプログラムはバイトストリームで処理してるから問題ないだけで
ロケールなんてgettextで文言変わるくらいにしか利用してない

>>309
冗談は辞めてほしい
君が何も知らないのはよく分かった

タイトルに付いていたらあ、クソだなと思うもの
異世界
チート
転生
のんびり
最強
スローライフ
無双
ギルド
追放
スキル
おっさん
勇者
魔王
賢者
魔術師
錬金術
聖女
奴隷
悪役令嬢
婚約破棄

遅くとも<title>までにはエンコードを確定できるワードが欲しいね

どす恋！

>>312
> 昔のプログラムはバイトストリームで処理してるから問題ないだけで
> ロケールなんてgettextで文言変わるくらいにしか利用してない

あっさり言ってくれちゃってますが
Ken Thompson大先生の大発明UTF-8以前は
みんな処理系から実行系まで
USC-2対応に書き換えるつもりだったんですよ?

凄く簡単なアイデアだけど着眼点がシャープ

それから商業UNIXのm17nは徹底的なもので
grepなんかも各言語、各文字コード対応だった

👁－－－－－－－－→

昔のプログラムはバイトストリームで処理してるから問題ない？
そんなわけないだろ
正規表現の.とかUTF-8の一文字に対応させんといかんから
ほとんどのプログラムに修正が必要だぞ
今も修正できてないコマンドはいくらでもある

相手が変なこといってるなと感じたら
じぶんが拾えてない情報がないか確認するよねふつう

ふわっとしてんな

>>320
お前、もしかして相手が変なことを言っていると感じているのか？

>>317
みんな突っ込まないでくれているけど
USC-2 → UCS-2

>>323
タイポとか誤変換とかに突っ込んでたらきりがないのでわかってるぽいのはスルーで
無理に訂正する必要もないよ

なーんだ、てっきり南カリフォルニア大学ことかと思っちゃった

のw

このスレに来る人はICUを集中治療室とか国際基督教大学とは思わないから安心しろ

UTF-8がASCII互換っていうのはASCII部分のみが互換っていう意味で
ASCIIだけを使ってるなら動くってことだよ
ASCII以外の漢字部分までASCII互換になるわけがない
そもそもASCIIに漢字なんて無いんだから
漢字は別途対応、もちろん漢字だけじゃなくて絵文字とかも含むからね

これで気兼ねなくATMの話ができます！

>>319
正規表現とか使ってなければ問題無いだろう
ほとんどのプログラムに修正が必要は大げさ

昔のプログラムがバイトストリームで処理してると思っているあたりが素人くさい。
MS-DOSの話してるんだろうか？

>>330
ASCII以外の文字を扱う全てのプログラムに修正が必要

>>331
昔も今もバイトストリームだろ
じゃなきゃバックスラッシュと円記号が同一視されるはずがない

>>333
小学生でもそんなこと言わんぞ
「文字コード」って聞いたことあるか？

多バイト文字の処理が念頭にあるんだろうけども
改行含めてASCIIの範囲でマッチできれば成立するプラグラムの方が大半な気がする
catやcpなんて文字コードなにそれだし

うん。だからテキスト処理関係のフィルタコマンドだよ
grepとかsedとかawkとかtrとかcutとかsortとか
そこいらは全部修正が必要

>>336
お前どこのツール使ってるの？
オレの sort とかのツールはちゃんとロカール対応してるけど？

>>329
それは回線にモデルとかISBNとか使ってた頃の遺物だろww

ぼくは雑誌コード

>>337
だからロケールに対応する修正が入ってるから今は動くようになってるんだろ
UTF-8がASCII互換だからって、何も修正しないで動くわけじゃないって話をしてる

>>340
Unix 系はunicodeとか発明される以前の昔からロカールあったろ？ お前のは無かったの？
UTF-8 きても対応文字コードが増えた以上の変化はないぞ

>>336
ほとんどのプログラムって言っていたのが随分と対象が減ったな

>>341
昔にロケールなんて概念ねーよｗ
あったとしてもASCIIしか考慮してないプログラムは
ロケールに対応してない

どうせ今の話しか知らんくせに
やってみたら動いているみたいだから
昔から対応していたみたいの思ってるんだろうけど
これとか読んだら？

GNU Coreutils - Multibyte/unicode support
https://crashcourse.housegordon.org/coreutils-multibyte-support.html

多くの人の努力によってようやくUTF-8に対応しつつあるというのに
ASCIIのままのプログラムでUTF-8でも動くとか

あーほみたいじゃなくて、あーほ

>>343
unicode や UTF-8 よりロカール機構の方が古いって本当に知らないの？
調べもしないの？ 恥ずかしくない？

>>346
古いって知ってるがそれがなにか？
古かったら、対応しなくても動くんですか（笑）

だいたいASCIIにしか対応してないプログラムって言ってんだから
ロケールにも対応してないに決まってるだろ
頭悪そうじゃなくて、頭悪い。

>>345
gnu や linux は商用unixの後追いで互換ツール作ってたんだよ。商用unixは皆対応できてた。
こっちとら linux の黎明期に glibc や gnu tool の locale 実装手伝ってたりしたんだが、お前何やったの？

>>349
話をすり替えんな
お前がやった仕事は大したことじゃないんだろ？ｗ
だってASCIIに対応していれば、そのまんま動くんだからな！

俺が何をやったかだって？
お前よりすごいことをしていたよ
守秘義務があるから言えないけどなｗｗｗ

>>348
336の話してるんだが、どこで言ったの？ 脳内？ ASCII しか対応してないって何時の時代の話？ お前何か参加したの？

> ASCII しか対応してないって何時の時代の話？
まさか全アメリカ人がUTF-8に目覚めたとでも思ってるのか？ｗ

今もUnicode・UTF-8に非対応で、
本当は一文字なのに三文字とか間違える実装を知らんのだろうな

漢字1文字が最大8バイト、Unicodeの「IVS」とは？
https://xtech.nikkei.com/it/article/COLUMN/20100126/343783/

UTF-8 が来た時には既に locale があった
locale に対応していたれば同じバイナリで UTF-8 も扱えたので、UTF-8 に対応するめの改修とかする必要なかった

個々のツールを改修する必要はなくて、OS側のライブラリを改修することで対応するという基本的な考え方が理解できてないんだろうな。

どうやらASCIIしか考慮してないプログラムは
そのOS側のライブラリを使ってないということに
思い至らないようだｗ

それともなにか？printfをロケール対応に
仕様変更するきかね？ｗｗｗ

>>335
wc

UTF-8 が来た時には既に locale があった
だがlocale に対応していないプログラムがたくさんあった

>>360
で336のうちどれの話？

>>358
ISO/IEC 9899:1990/Amendment1:1995(C95)の7.9.6.1と7.9.6.3より
printfの仕様はロケール対応では?

%sの代わりに%lsでワイドキャラクタを扱える

>>358
商業UNIXはlibcレベルから各文字コード対応だったんだよ

なんかCの仕様をわかっていない人がいるような

Cのプログラムをロケールを利用した国際化対応するには冒頭でsetlocale()を
呼ぶだけでなくて、文字をcharではなくwchar_tで扱い、fgetsの代わりにfgetwsを
使うなどワイドキャラクタ対応のw系関数で文字を処理するに変更するか、printfや
scanf系関数で%sの代わりに%lsで扱う

Cのユニコード関連の仕様はISO/IEC 9899:2011(C11)で導入され、6.4の\u,\U, u'',U''と
7.27のuchar.hで定義されたchar16_t, char32_tがユニコード関連
これらはロケールやwchar_tとは別概念なはず

>>364
順番とか歴史を理解してる？
国際化するのに locale という仕組みが提案さてて wchar_t が導入され、OS標準ツールは言語や文字コードを切り替えられるようになった
その後に多言語化のために unicode と UTF-8 が出てきて locale 対応しているプログラムは変更なく多言語化できるようになった
比較的最近になって、もう新しいプログラムは unicode だけ対応していれば 十分で locale 対応いらないんじゃね？ という大雑把アメリカンな考えが出てきて char32_t みたいな仕組みが作られた
国ごとに仕組み違うし、言語ごとに文字の定義とか違うんだから unicode あっても locale 無くせないんだよ。というアメリカ以外からの当然の反発もあって
今は、真面目に国際化対応が必要なやつは locale, そんなん気にしなくて良いやつは生UTF-32, Windowsと互換性が最重要なら生UTF-16みたいな棲み分けになってる

utf-8になってもロケールは必要だよね
言語や地域ごとに処理を変えないといけないから
例えば同じ文字を使っていても辞書順が違うことがある
発音記号の取り扱いとか

それからwchar_t+Unicodeのみで処理する枠組みはうまくいかなかった
ASCII文字だけ扱いたい時
Unicode以前旧世界との互換性
を考えると
結局世界はMBCSと付き合わざるを得ない事に納得し
wchar_t+Unicodeは速いindexingが必要な内部表現だけで使うことになった

localeに対応しているlessコマンドはsjisファイルも読めるん？

>>367
昔の商業UNIXにlessはなくてmoreだけど
ja_JP.sjis
に設定すれば

Solarisでは2byte目\問題もなかった
もちろん内部的にはMBCS stringとして扱ってる
euc-jpだってMBCSなのだから
ちなみにSolarisの場合はこの辺の処理は
ハードコーディングではなくテーブルドリブンだった

ただこの辺の努力は全て水泡に帰して
GNU Linux全盛期に入ったわけだ
つまり文字コード対応はutf-8をベースにして
各言語対応は車輪の再発明をしなければならなかったし
まだ当時に追いついてもいない

>>369
再発明とかはやってないぞ
普通に gnu tool も昔から locale 対応してるし、今もそう
ただ、まだマイナーなバグや使い難い仕様が一杯残ってるねってだけ。国際化でなくて、特に多言語化のまわりが熟れてない
ユーザーにも一部の開発者にも国際化と多言語化の違いとか、機構と文字コードの違いが良くわかってないやつがいて
本来は「多言語化に問題がある」というべきところを「UTF-8の処理に問題がある」という言い方をしがち

ここでも知らんやつもいるかもしれないので、一応書いておくと
国際化(i18n): 文字コードとか言語とかを切り替えて使えるようにする機構
多言語化(m17n): 一つのテキストの中に複数の言語の文章を含めることができるようにする機構

unicode という規格には
(A) 純粋に文字コードを定義している部分。どの文字にどのコードを割り当て、それをどのように符号化するか。UTF-8 は符号化の名前
(B) unicode を使ってどのように多言語化(m17n)を実現するかの部分。標準的な多言語化を提案する。IVSの対応とかはこっち
の2つが含まれてる。
今いろいろやってるのは (B) 側の話。UTF-8対応やってるんじゃなくて「多言語化」対応やってる

多言語化は国際化に含まれますか?

>>372
それもちょっと違うね
「(A) 純粋に文字コードを定義している部分」にUTF8は全く関係ない
そこでは各文字にコード割り当て定義されていてコードは一意に定まる
一方でUTF8やUTF16などはそのコードのエンコーディングの話であり文字コード割り当てとは独立した全く別の話になるね

>>374
エンコードはコードじゃないという主張の人なの？ 珍しいな

>>375
そこは全く異なるのがユニコードの基本
例えば「あ」はコードポイントU+3042と一意に定められている
これはエンコーディング方式に関係なく一意に定まる
エンコーディング方式が増えたり廃止されたりしても影響を受けない

一方でこのコードポイントを扱う時に環境や状況に応じて様々なエンコーディング方式を取ることができる
例えばコードポイントは16bitに収まりきらないので32bitに入れるのがUTF32
「あ」はコードポイントU+3042なのでUTF32だと0x00003042となる
UTF8は8bit前半をascii互換とし8bit後半の不定長列を非asciiに割り当てる
「あ」はコードポイントU+3042なのでUTF8だと0xE3 0x81 0x82となる

このようにコードポイント割り当てとエンコーディングは全く独立した別の分野

>>376
それはISO-2022のフレームワークとさほど大差ない
特にShift JISも含めて考えた場合は

バイト表現と文字コード体系は別の概念

>>376
世間では一般的に
コードポイント(符号位置)＋エンコード＝文字コード
という認識なんだけどね。言葉の定義の問題なので、ここで議論しても始まらないか

その感覚はないな
\uXXXXや数値文字参照で指定する値という認識じゃね？
コードポイントそのもの

>>380
世間一般はSJISもEUC-JPもUTF-8も文字コードという認識なんだよ。厳密な言い方とはいえないが、そういもの
コードポイントだけを文字コードと呼ぶやつはかなり特殊、自覚しとけ

character encoding system = encoding method + character set

文字コードポイントとそのエンコーディングの区別ができてやつがいるな
例えばUTF8の0xE3 0x81 0x82を文字コードポイントとは言わない
あくまでも文字コードポイントはU+3042であり0xE3 0x81 0x82はUTFでエンコーディングした時のバイト列にすぎない

>>382
+ の後ろを coded character set 「符号化文字集合」とした方がより良いな

>>384
codedじゃ誤解しそうな人が出るので
numberedを付けるかどうか迷った

>>385
規格によって用語の意味が違うので難しいところだねインターネットのRFCとかだと正式用語は
code character set + character encoding scheme
それぞれCCSとCESと略されることもある
一般的な日本訳は「符号化文字集合」と「文字符号化方式」かな

>>386
dが抜けた。coded character set ね

>>383
お前は文字コードとエンコードの区別はついているか？

数学の写像だと考えればいいのでは

てすと🌀🌀

𝕏

ﾌﾌﾌ

文字コードって誰が作ってんの？

>>393
誰が作っても良い。他人に使ってもらえるかは知らんが

俺用の文字コードを作れば、漏洩して悪意ある他人が見ても文字化けで意味不明ってことか。

まず13文字ずらします

おおジュリアス・シーザー

カエサル派にとっては意味不明ってことか。

コードずらしただけだと出現頻度でばれるって話

－・　・・－　・－・・　・－・・　・－－・　－－－

macOS上の話ですが、'が’という名前のフォルダを作ってその名前をシェルで見ると

% ls | iconv -f utf-8 -t utf-16le | od -x -A n
304b 3099 000a

% echo * | iconv -f utf-8 -t utf-16le | od -x -A n
304c 000a

あれ、もしかしてシェル (zsh) がUnicodeの合成をしている?

bashでやると元のままでコマンドを外部コマンドにしても変わらないから
globがそういう動作なんやね

正確に言うと MacOS の zsh のグロブだな。

>>403
もしかしてmacOS上以外のzshだと挙動が違ったりします?

>>404
違う

>>405
確かに、zshのソースを見てみたらMac上だとファイル名を加工する処理が入ってました:
https://github.com/zsh-users/zsh/blob/master/Src/utils.c#L5169

が、果たしてそれはいい事なんだろうか。小さな親切大きなお世話という気もしないでもない

皆さんご存知macOS上のFSはファイル名がUnicodeの分解形になっているのだが、
上記により、シェル内でワイルドカードを使うとファイル名が合成形で得られる
その後、そのファイル名を加工して別のファイルを作ると、合成形でファイルが作られること
になる（macOSのUNIXレイヤーではパス名を分解形にすることは強制ではない）

結果、分解形のファイル名と合成形のファイル名がコンタミするではないか、と

>>407
macOS には HFS+ と APFS というのがあってだな。

awkが新しくなる！？ 本家AwkがUnicode (UTF-8)とCSV対応に！
https://qiita.com/ko1nksm/items/1a3e711bbd925657f5fd

やっぱりUTF-8に対応するにはアプリ側を修正しなきゃいけないって事ね

>>409
そもそも、そういう用途は nawk じゃなくて gawk とか使ってるので今更 nawk が対応したと主張したところで意味無し
nawk は文字とバイトの区別すらついて無かった古典だし。POSIX？それ美味しいの？状態だったのがようやく今頃になって対応始めた感じ。まだ問題だらけなので文字コード区別必要な場面での使用は非推奨。

事故の予感しかしない

全ての開発者が知っておくべきUnicodeについての最低限の知識
https://gigazine.net/news/20231005-unicode/

互換漢字のことを思い出してもいいですか

macOSのFinderで神というフォルダーを作ると神に変換される
Chrome上で神を検索すると神と神の両方にマッチする
Firefox上で神を検索すると神にはマッチしない
Firefox上で分解形の神︀で検索すると合成形の神にはマッチしない
Mozcで神︀を入力すると分解形がデフォ

みんなちがって、みんないい?

おはよう
今起きたけど、UTF-8にBOMつけるか否か？結論は出た？

UTF-8にBOは存在しない
↓
BOMなんて概念が不要

議論も何も無い

>>413
>macOSのFinderで神というフォルダーを作ると神に変換される

このあたり、Appleには素のNFDとは少し違う独自の正規化を使うこだわりが
あったのだと思っていたけど、今は違うのかな?

>>415
元来の用途で使う可能性が無いからこそ新しいより有用な目的を割り当てて使えるのですね

>>415
お前が世間知らずなだけ
エディタでbomありutf8は普通にサポートされてる
当然これは需要があるから

Firefoxの検索は半角カナの同一視もしてくれないからなあ

How can I get WideCharToMultiByte to convert strings encoded in UTF-16BE?
https://devblogs.microsoft.com/oldnewthing/20231005-00/?p=108854

UTB-16BEからShift_JISに変換したいとかいろんな要望があるものだな

>>415
正確には「UTF-8にバイトオーダーの違いはない」だな。

JSONなどBOMを付与して送信してはいけないと明確に規定されていたり
BOMを取り扱わない規定やソフトウェアもあるため
UTF8ではBOMを付与しないほうが好ましい

JSOINファイルに付けるなとは言ってないみたいよ

#!shebangの邪魔になるだろ

>>424
BOMを認識するようシステムコールを改修すればいいだけ
それをしないのはOS開発者の怠慢

>>413
macOS/iOSのSafariではひらがなとカタカナを同一視するという挙動があるようで
みんなちがって、みんないいw

>>425
execve の引数解釈が locale に従うのであれば BOM を付けるべきではない状況に該当すると思う。

BOMなしがいいってのはAsciiしか対応してないレガシーソフトウェアに通したいから？
UTF8を意識できてるならBOMのありなしの両対応は簡単だし

>>428
ファイルの接続とか分割にゴミ処理とかしないですむ。自分がいまから出力するのが先頭かどうか不明とかでも問題は起きない
ファイルの先頭とかには別の識別子置きたいアプリもある。先頭BOMが優先して使えるとか思い上がり。
そして何より、世の中すべて UTF-8 で情報交換すべきで、他の文字コードは内部コード以外は認めない。滅べば良いと本気で信じてるので BOM に使いみちなんかない。
だいたい最近の欧米の主張はこんな感じ。

UTF8こそが不要で滅べば良い。I

これからの時代は UTF-32

なぁに。1バイトを32bitにしてしまえばエンディアンがどうのなどとつまらない事を考える必要もなくなる。BOMも不要。

いいかげんチマチマと8bitづつ扱うようなケチな精神がいけない。
8bit CPU の事などもう忘れろ。

>>431
文字結合あるからUTF32でも解決しない
結局可変ならUTF8が合理的という考え方もある

>>434
つまり UTF1024 が必要ということだな

えっ

ふーん

結局UTF-8にBOMつけるか否か？まだ結論は出てないんだな？
じゃあ、今からまた寝るから結論出たら教えて…おやすみ

結論は出ない、永遠に寝てろ

結論も何も最初から規格上は「つけないことを推奨」。規格を無視するやつらは勝手につけてるだけ。
これ以上何に結論を出せと？

禁止はしてないな。いくつか使用すべきではない状況はあるがそれ以外必要に応じて使ってよい。
まあいずれEUCと同じように淘汰はされていくと思うが。

拡大解釈を結論としちゃうとそりゃ永遠に終わらんよな

もう恥ずかしいからやめろよ

文字コードの自動判定でBOMが欲しいんでしょ
だったら日本人的には当面ありの方がいいんじゃないの

まじで文字コード判定でBOM必要とするなんてExcel以外にしらんし
他にならって決め打ちか失敗前提で推測する実装にしとけばこんなことにはならなんだ

>>443
今はネット通信もローカルもUTF8を使うのが普通だからBOMは要らない
HTTPやHTMLならそこで文字コード指定できるし

UTF8を使うのが普通だったりエンコーディングを指定できる所ばかりじゃないんだからBOMがあるのは仕方ない

>>444
まさにExcelのためにBOM付けてる

>>445
早くWindowsのシステムロケールが標準でUTF-8になれば良いな

visual studioもbom必要
設定でutf8指定したら不要だけど
外部のソースまでutf8前提になるので踏み切れない

いわゆるWindows PowerShell（5.x系）も、日本語を含むスクリプトの場合は BOM付きUTF-8 で保存する必要がある

文字コード、改行コード（何らかのデミリタ）に関わる問題は果てしなく続く
そして、文字数カウント問題も...

>>447
Mac, iPhone も Linux, android も BOM なし UTF8 オンリーで、十分いけてることを考ええると、
UTF8にBOM必要とかいってるやつも、日本語 Windows の system locale が UTF8 なったら手のひら返すだろうね

必要だから使っているだけで、必要なくなったら使わなくなるだけ。
手のひら返すって発想が出るのはこれをなにか派閥争いや宗教的対立ととらえているんだろうな。

みんなうるさいなぁ…全然寝れないじゃん！
結論は出ない…という結論が出てるんだから
もうみんな静かにしといて欲しいわ

ホントの結論が出たら起こしてねｗ

UTF-8にBOMは不要だがBOMを要求する出来の悪いアプリが存在するというだけの話
アプリを修正すればいいだけなのに出来の悪い子のためにBOM付きファイルを広めようとするから迷惑がられる

こう、「出来の悪い」とか要らん煽りをちょいちょい挟んでくるのがな

環境のCPのエンコーディングとUTF-8を両対応したくてBOMを導入した設計は偏狭
専用の閉じたデータなら勝手にどうぞだけどCSVファイルだよ
出来が悪いにもほどがある

一応Unicode規格に定められた仕様なわけだがそれを正しく実装しても出来が悪い呼ばわりするわけだな

CSVファイルの一般的書式 (RFC4180 日本語訳)
http://www.kasai.fm/wiki/rfc4180jp

CSVファイルにBOM付けるな、なんてどこに書いてあるんだよ

>>457
ABNF表記

そのRFCはメジャーではないし従う必要もないけどね

VC++はコンパイルオプションでBOM無し通るようになったから許す

あ、そうか。UTF-8なのにBOM入りにする理由はコードの自動判別のためか。

>>460
Windows は文字コードの指定がないとシステムロカールに設定されている文字コード（日本語WiIndows11だとCP932=SJIS)という約束になっていて、これを変更せずに UTF−8 を使いたいがための苦肉の策だった(過去形）。
最近はマイクロソフトはこの約束を破棄して標準を UTF−8 にするよう要請してるし、将来システムロケールのデフォルトを UTF−8 に変更することは確実なので、単なる経過措置。

メモ帳のデフォルトの文字コードは、BOM付きUTF-8

>>462
もう今は BOM なしがデフォ
BOM 付にする場合は格納する時に明示的に選ぶ

「メモ帳」に多数の改善、BOMなしUTF-8がデフォルト保存形式に 〜「Windows 10 19H1」
https://forest.watch.impress.co.jp/docs/news/1157696.html

「UTF8はBOMを付けない」
これでWindows以外は統一されている
WindowsでもBOMなしが標準になりつつある
大勢は決した

ExcelがBOM無しCSV/TSVを文字化けせずに読み込んでくれたら解決しそうw
自慢？のcopilot使ってもいいからさっさと解決しろやーw

>>466
今でもシステムロカールを UTF8 に切り替ええると BOM なしで読める。システムのデフォルトを SJIS に設定しているから BOM なしを SJIS とみなしてるだけ。

>>467
今のExcelの挙動の方がOSの設定を反映してて行儀良いとも言える
WindowsがUTF-8で統一されるには、まずはWindowsのシステムロケールの規定値がUTF-8にならないことにはな

>>468
その通りなんだが、マイクロソフト自身がそこを翻して、今後は外部文字コードはシステム設定にかかわらず UTF8 にするようにプログラマー向けのガイドで推奨している。
時代は変わったというやつだな。

General Unicode requirement in INF files
https://learn.microsoft.com/en-us/windows-hardware/drivers/display/general-unicode-requirement

INF files should be saved and encoded as Unicode (UTF-16 LE); they must not be ANSI or UTF-8.

話してるのは交換用のデータ
そういうレガシーな閉じたデータは困んないし関係ないよ

Microsoft は 、UTF-8 BOM 無しを推奨する理由として「Web アプリや Unix 系の OS が UTF8 BOM 無しなので、文字コード関連のバグを最低限にするためには UTF8 は BOM なしである必要がある」と主張している。
この主張を元に PowerShell とかの基幹アプリもデフォルトを BOM 無しに移行した。
今はもう UTF-8 BOM つきを推奨するメジャー組織は存在しない。

ハナっから「推奨」していた組織など存在しない

Windows/MS がさっさと間違いを認めれば良いだけ

>>473
マイクロソフトは昔はプログラマ向けにBOMつけることを推奨してたんだよ。ツールとかも勝手にBOMを追加していた。
そもそもユニコード規格で UTF8 のBOMが文字コード判別用として規定されたのもマイクロソフトの主張によるもの。
他の企業とかは反対だったけどMSが強く主張するので、妥協として非推奨という形で規格に取り入れられた。

RFC3629の日本語訳
UTF-8, ISO 10646 を変換したフォーマット
https://www.akanko.net/marimo/data/rfc/rfc3629-jp.txt

プロトコルはが常にUTF-8であるなら、そのような場合シグネチャ機能は完全に無駄であるので、そのプロトコルが命令するそれらの原文のプロトコル要素のためのシグネチャとしてU+FEFFの使用を禁止【すべき】(SHOULD)である。

プロトコルは、それらの原文のプロトコル要素、プロトコルの実装が常に適切にメカニズムを使う立場にあることが予測されるとき、そのプロトコルが文字符号識別メカニズムを供給するためのシグネチャとしてのU+FEFFの使用を同じく【禁じるべき】(SHOULD)である。これは、プロトコル要素がそれらの作成時からそれらの適切に分類される伝送の時間まで実装の制御下にきつく維持されるケースであろう。

禁止が不可能、あるいはプロトコルの実装がメカニズムを常に適切に使う立場にないことが予測される時には、プロトコルは、文字符号化識別メカニズムを提供しないそれら原文のプロトコル要素のためのシグネチャとしてU+FEFFの使用を禁じる【べきではない】(SHOULD NOT)。後者2ケースでは、特にプロトコルの実装が、そのような要素を、ファイルシステム、ペイロード(FTPなど)のための符号化識別メカニズムを持たないプロトコル、または文字符号化の適切な識別を保証しない他のプロトコルから得る時のMIME要素(HTTPなど)など、より大きいプロトコル要素で起こりそうだ。

>>472
UTF8のBOM付きは古いローカル環境のファイルを除いて世の中から消滅だね

いずれ消滅はするだろうね。今すぐにではないだろうけど。

以下のウェブページ、ちゃんと表示されます? 自分の環境ではところどころ文字化けが

新JIS漢字で包摂の扱いが変わる文字
https://www.aozora.gr.jp/newJIS-Kanji/gokan_henkou_list.html

Shift_JIS-2004にするとemacsでは見れるっぽいな

>>479
ページのデコード（文字コード）の問題っぽいので、現代のブラウザでそれらの文字を正しく表示するのは不可能な気がする
少なくともChromiumにはページの文字コードを指定して読み込む機能はない（かなり前に失われた）

>>481
なるほど
試しにソースをUTF-8に変換してみたら問題ないっぽいので、そこに書かれているような
UCSのコードポイントがないだとか拡張されたフォントが必要だとかそういうのも
昔話くさいですね。関係者の皆様(?)ご苦労様でした

ちなみに当の青空文庫、チラ見すると今でも基本はJIS X 0208/ShiftJISのようで
なかなかストイックですな。結局「包摂の扱いが変わ」らなかったのかな

>>481
https://chrome.google.com/webstore/detail/set-character-encoding/bpojelgakakmcfmjfilgdlmhefphglae

永青文庫といつも間違う

中々に興味深い内容だった

我々の著書はなぜ誤植まみれに？出版業界と標準規格は相容れない世界。【文字ヶｮデ2】#95 - YouTube

>使わざる終えない

こういう誤字ってる香具師をよく観かけた

>>486
流し見したけど、若いなあ。若い視聴者向けにあえて歴史的な部分を嘘で誤魔化したのかもしれないけど。
印刷業界の正字文化も、おおもとはフォントの都合。コンピュターのフォントじゃなくてフォント(物理)。
金属活字は高価なのでマイナーな漢字は種類揃えることができなきて正字しか存在しなかった。それで作家がどんな漢字を手書きで書いてこようが、植字職人が問答無用で正字に直していた。
作家に文句いわれても、これが正しい漢字だとうちは正しい漢字で出版すると言い訳してきたのが伝授されていくうちに文化として定着した。

常用漢字も公務員ωの都合だしな

>>484
元の文書はShift_JISx0213なんですよね。チラ見した感じではリストになさそうなので
単にメニューを追加しただけでは無理そう
さらに今は名前がShift_JIS-2004に変わっているという
ただ、Shift_JIS-2004にしてもIANAには登録されてないようですが

このウェブ文書が書かれたときにはどうやって見ていたのだろう
ブラウザにエンコーディングメニューがあった時代にもShift_JISx0213はなかったような

>>488
昭和期の小説なんて送り仮名すら適当だからなあ
昔はいい加減だったものが編集その他の介入が厳格になってかっちりしたのもありそう

>>491
送り仮名や当て字は昔は作家の作風の一部だったので出版社が勝手にいじるのは厳禁だった。あくまで正字に直すだけ、あとは校正校閲で指摘して作家本人に直すか確認。
最近は出版社どうのこうのの前にかな漢字変換先生が“正しい”送り仮名をつけるし、わざわざ選ばない限り当て字にもならないので差がほぼ消滅した

ついにWindows 11のメモ帳に文字数カウント機能が追加される - GIGAZINE
https://gigazine.net/news/20231208-windows-11-notepad-character-count/

メモ帳とワードパッドどこで差が付いたのか

ワードパッドはプアマンズワードみたいなもんだったから、あらゆる意味で中途半端だった
エディタとして基本的なものだけでよかったメモ帳とはわけが違うな

>>493
合成絵文字とか国旗とかは何文字扱いなんだろう？

>>470
NVIDIA Windows 10 (64 bit) Display INF file
普通にUTF-8で草生えた

そういえば、Windowsのレジストリスクリプト、
v.4はANSI
v.5はUTF-16LE
だったな

時代のあだはなって奴か

「世界の全部の文字は16ビットに収まる。16ビット固定長なら全世界の人が幸せになる。」

マイクロソフトの発想は面白かったんだが前提が間違っていたのでどうにもならないな。
韓国がワガママ言ってハングルだけでBMPの1/5の1万2千字持って行くとか、中国や台湾が漢字を5万字追加してBMPに入らなくなるとか想定できないのが悪い。
絵文字は同情の余地がある。Google がandroid携帯で携帯市場に参入するとかは当時は予想し難いだろう。

想定が甘かったのでなく、もともとISOで32bitで文字を表す規格化が進んでいたけど16bitに収めたい企業のゴリ押しで16bitになったんだよ

>>501
その前の話だよ。ISOとかとの調整以前の動き

じゃあマイクロソフトを持ち出すのはおかしい

ISOの多言語化とは別に、マイクロソフトがIBMと多言語文字コードの研究開発してたの知らずに文句言ってるだけか。

おれは歴史を知ってるふう装っても
その上に歴史に基づかない妄想を書いたことは取り消せないよな

https://ja.wikipedia.org/?curid=1999

1984年、ISOの文字コード規格委員会 (ISO/TC 97/SC2) は文字セットの切り替えを行わずに世界中の文字を単一の文字集合として扱える文字コード規格 (ISO 10646) を作成することを決定し、専門の作業グループ (ISO/TC 97/SC 2/WG 2) を設置し、作業を始めていた。1980年代後半にはこの作業グループにおいてさまざまな提案が検討されている。1990年になって出来あがったISO/TC 97/SC 2/WG 2作成のISO 10646の初版ドラフト(DIS 10646#DIS 10646第1版)では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対しており、今後の漢字コードの方針を決めるため、WG 2は CJK-JRG (Joint Research Group) と呼ばれるグループを別途設置し、そこで引き続き検討することにした。

このような公的機関の動きとは別に、1987年頃からXeroxのJoe BeckerとLee Collinsは、後にUnicodeと呼ばれるようになる、世界中の文字を統一して扱える文字コードを開発していた。1989年9月には「Unicode Draft 1」が発表された。ここではその基本方針として、2オクテット(16ビット)固定長で全ての文字を扱えることを目指しており、そのために日本・中国・韓国の漢字を統一することで2万弱の漢字コードを入れ、さらに将来の拡張用に、3万程度の漢字の空き領域が別に用意されていた。

それだけあれば十分だな！

>>506
>しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対
デフォルトで中華フォントを表示させるのに成功した

適当なサンプル

https://qiita.com/kominato_slj/items/bbe0ae1445d8394d95bf

デフォでCJKフォントになるのまじで敗北
いちいち手をいれるの面倒なのはわかるけど
チラシやオフィス文書で頻繁にみかけるし気分悪い

ChatGPTに頼ってもFlutterでは中華フォント対策コードにはならない
て言うか明らかにフォントがおかしいのが気にならないのかよ


https://qiita.com/asasigure/items/ea751ec73689e5fc7a41
https://github.com/asasigure1209/my-memo-app/blob/82a89d1fceec4a793294eaffc396e2d1432daa38/lib/main.dart#L19

奴ら平仮名も持ってるから日本語のフォントに来ないってことかな
最初の優先順位はどうやって決まるんだっけ。文字数?

Flutter民「おもちゃアプリで細かい事を言われても困ります」(真顔)

台湾行ったら看板とかでたまにひらがな使ってた。日本でちょっと英語を使うようなノリなのか?
ということは台湾のフォントにひらがなが入っていることもあるか
日本語のフォントだって英語が入ってるものなあ