文字コード総合スレ part14

1 ：デフォルトの名無しさん：2023/03/03(金) 15:46:58.08 ID:yKqwMGHT.net

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/
文字コード総合スレ part13
https://mevius.5ch.net/test/read.cgi/tech/1593777227/

345 ：デフォルトの名無しさん：2023/06/25(日) 21:54:46.00 ID:ySKqPmeW.net

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

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

346 ：デフォルトの名無しさん：2023/06/25(日) 21:56:04.00 ID:ySKqPmeW.net

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

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

347 ：デフォルトの名無しさん：2023/06/25(日) 22:09:28.31 ID:0nHjw2pZ.net

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

348 ：デフォルトの名無しさん：2023/06/25(日) 22:10:52.26 ID:ySKqPmeW.net

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

349 ：デフォルトの名無しさん：2023/06/25(日) 22:18:03.54 ID:ySKqPmeW.net

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

350 ：デフォルトの名無しさん：2023/06/25(日) 22:22:23.09 ID:0nHjw2pZ.net

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

351 ：デフォルトの名無しさん：2023/06/25(日) 22:24:10.92 ID:ySKqPmeW.net

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

352 ：デフォルトの名無しさん：2023/06/25(日) 22:25:47.25 ID:ySKqPmeW.net

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

353 ：デフォルトの名無しさん：2023/06/25(日) 22:25:52.06 ID:0nHjw2pZ.net

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

354 ：デフォルトの名無しさん：2023/06/25(日) 22:30:06.30 ID:ySKqPmeW.net

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

355 ：デフォルトの名無しさん：2023/06/25(日) 22:31:57.20 ID:ySKqPmeW.net

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

356 ：デフォルトの名無しさん：2023/06/25(日) 22:34:23.36 ID:ySKqPmeW.net

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

357 ：デフォルトの名無しさん：2023/06/25(日) 22:34:25.42 ID:0nHjw2pZ.net

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

358 ：デフォルトの名無しさん：2023/06/25(日) 22:37:12.38 ID:0nHjw2pZ.net

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

359 ：デフォルトの名無しさん：2023/06/25(日) 22:40:53.01 ID:ySKqPmeW.net

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

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

360 ：デフォルトの名無しさん：2023/06/25(日) 22:41:32.64 ID:9S6fsVfv.net

>>336
wc

361 ：デフォルトの名無しさん：2023/06/25(日) 22:42:37.03 ID:ySKqPmeW.net

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

362 ：デフォルトの名無しさん：2023/06/25(日) 23:21:26.81 ID:0nHjw2pZ.net

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

363 ：デフォルトの名無しさん：2023/06/26(月) 10:16:30.84 ID:lZKUXxOT.net

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

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

364 ：デフォルトの名無しさん：2023/06/26(月) 10:35:51.62 ID:wgwkla1B.net

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

365 ：デフォルトの名無しさん：2023/06/26(月) 10:39:44.57 ID:lZKUXxOT.net

なんか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とは別概念なはず

366 ：デフォルトの名無しさん：2023/06/26(月) 11:12:59.67 ID:15L3klhZ.net

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

367 ：デフォルトの名無しさん：2023/06/26(月) 11:45:10.68 ID:OOvp3Qkm.net

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

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

368 ：デフォルトの名無しさん：2023/06/26(月) 11:51:20.62 ID:uBe3VRyC.net

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

369 ：デフォルトの名無しさん：2023/06/26(月) 12:04:29.17 ID:OOvp3Qkm.net

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

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

370 ：デフォルトの名無しさん：2023/06/26(月) 12:07:04.06 ID:OOvp3Qkm.net

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

371 ：デフォルトの名無しさん：2023/06/26(月) 12:44:13.00 ID:15L3klhZ.net

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

372 ：デフォルトの名無しさん：2023/06/26(月) 12:54:23.97 ID:15L3klhZ.net

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

373 ：デフォルトの名無しさん：2023/06/26(月) 13:12:12.62 ID:15L3klhZ.net

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

374 ：デフォルトの名無しさん：2023/06/26(月) 16:20:01.13 ID:LAEwcUbv.net

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

375 ：デフォルトの名無しさん：2023/06/26(月) 17:50:33.08 ID:e5otmU9r.net

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

376 ：デフォルトの名無しさん：2023/06/26(月) 18:30:16.65 ID:15L3klhZ.net

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

377 ：デフォルトの名無しさん：2023/06/26(月) 19:03:46.54 ID:CwqPR/Mz.net

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

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

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

378 ：デフォルトの名無しさん：2023/06/26(月) 19:14:59.15 ID:b1vEmQDc.net

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

379 ：デフォルトの名無しさん：2023/06/26(月) 19:27:42.67 ID:Wnoei0OS.net

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

380 ：デフォルトの名無しさん：2023/06/26(月) 22:19:22.18 ID:15L3klhZ.net

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

381 ：デフォルトの名無しさん：2023/06/26(月) 23:14:57.66 ID:zFI2p9hF.net

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

382 ：デフォルトの名無しさん：2023/06/27(火) 00:02:41.00 ID:fkxIsCCD.net

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

383 ：デフォルトの名無しさん：2023/06/27(火) 00:31:42.23 ID:TcukIZUS.net

character encoding system = encoding method + character set

384 ：デフォルトの名無しさん：2023/06/27(火) 00:39:10.68 ID:0oaaTR6k.net

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

385 ：デフォルトの名無しさん：2023/06/27(火) 01:24:36.76 ID:fkxIsCCD.net

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

386 ：デフォルトの名無しさん：2023/06/27(火) 07:10:50.09 ID:TcukIZUS.net

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

387 ：デフォルトの名無しさん：2023/06/27(火) 09:02:31.09 ID:fkxIsCCD.net

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

388 ：デフォルトの名無しさん：2023/06/27(火) 09:03:47.40 ID:fkxIsCCD.net

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

389 ：デフォルトの名無しさん：2023/06/30(金) 18:08:26.89 ID:9szWkPbV.net

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

390 ：デフォルトの名無しさん：2023/07/01(土) 03:56:24.34 ID:LJyXb+JQ.net

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

391 ：デフォルトの名無しさん：2023/07/11(火) 16:13:44.17 ID:heSsZz8c.net

てすと🌀🌀

392 ：デフォルトの名無しさん：2023/07/27(木) 22:11:05.51 ID:u2yUFzzA.net

𝕏

393 ：デフォルトの名無しさん：2023/07/28(金) 00:23:42.06 ID:8p3s4hKM.net

ﾌﾌﾌ

394 ：デフォルトの名無しさん：2023/07/28(金) 00:51:45.87 ID:9nGZuQCT.net

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

395 ：デフォルトの名無しさん：2023/07/28(金) 02:16:49.64 ID:6UVKXpPK.net

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

396 ：デフォルトの名無しさん：2023/07/28(金) 02:28:54.58 ID:9nGZuQCT.net

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

397 ：デフォルトの名無しさん：2023/07/28(金) 19:41:58.97 ID:25x9IMWE.net

まず13文字ずらします

398 ：デフォルトの名無しさん：2023/07/29(土) 08:13:24.61 ID:ej8Wm4VI.net

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

399 ：デフォルトの名無しさん：2023/07/29(土) 14:26:21.89 ID:fTZOzdc3.net

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

400 ：デフォルトの名無しさん：2023/08/04(金) 14:46:46.47 ID:XLfSEGlw.net

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

401 ：デフォルトの名無しさん：2023/08/04(金) 18:06:48.16 ID:v1ivVYRs.net

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

402 ：デフォルトの名無しさん：2023/08/18(金) 15:49:14.73 ID:s/AKDW6W.net

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の合成をしている?

403 ：デフォルトの名無しさん：2023/08/18(金) 23:53:14.80 ID:mQKTVMWd.net

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

404 ：デフォルトの名無しさん：2023/08/19(土) 00:16:00.94 ID:Af/nXbF+.net

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

405 ：デフォルトの名無しさん：2023/08/19(土) 01:35:51.14 ID:5L917aO4.net

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

406 ：デフォルトの名無しさん：2023/08/19(土) 02:04:07.40 ID:Af/nXbF+.net

>>405
違う

407 ：デフォルトの名無しさん：2023/08/19(土) 10:09:35.79 ID:5L917aO4.net

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

408 ：デフォルトの名無しさん：2023/08/19(土) 10:21:56.98 ID:5L917aO4.net

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

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

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

409 ：デフォルトの名無しさん：2023/08/19(土) 10:44:11.66 ID:Af/nXbF+.net

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

410 ：デフォルトの名無しさん：2023/09/18(月) 15:14:20.26 ID:lNC8R66h.net

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

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

411 ：デフォルトの名無しさん：2023/09/18(月) 17:45:11.83 ID:xE50yd7v.net

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

412 ：デフォルトの名無しさん：2023/09/21(木) 17:13:01.39 ID:2fMT8T96.net

事故の予感しかしない

413 ：デフォルトの名無しさん：2023/10/05(木) 21:37:01.18 ID:629OTK1e.net

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

414 ：デフォルトの名無しさん：2023/10/06(金) 02:09:53.00 ID:rMpfnI78.net

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

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

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

415 ：デフォルトの名無しさん：2023/10/06(金) 09:13:41.28 ID:r0aKLQgw.net

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

416 ：デフォルトの名無しさん：2023/10/06(金) 09:59:40.01 ID:Zl0hPCVy.net

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

議論も何も無い

417 ：デフォルトの名無しさん：2023/10/06(金) 11:34:57.64 ID:rMpfnI78.net

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

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

418 ：デフォルトの名無しさん：2023/10/06(金) 14:17:35.44 ID:RyNaN3Hq.net

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

419 ：デフォルトの名無しさん：2023/10/06(金) 17:44:51.54 ID:vOZibH++.net

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

420 ：デフォルトの名無しさん：2023/10/06(金) 18:03:58.96 ID:vujaBc4z.net

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

421 ：デフォルトの名無しさん：2023/10/06(金) 21:14:36.66 ID:VyRY/4o/.net

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に変換したいとかいろんな要望があるものだな

422 ：デフォルトの名無しさん：2023/10/06(金) 21:24:18.57 ID:cSD4ys+j.net

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

423 ：デフォルトの名無しさん：2023/10/06(金) 22:08:49.33 ID:g8qFATdI.net

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

424 ：デフォルトの名無しさん：2023/10/06(金) 22:54:13.21 ID:cSD4ys+j.net

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

425 ：デフォルトの名無しさん：2023/10/06(金) 23:20:11.94 ID:tE7CLicd.net

#!shebangの邪魔になるだろ

426 ：デフォルトの名無しさん：2023/10/07(土) 09:59:00.66 ID:I3+2vFW6.net

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

427 ：デフォルトの名無しさん：2023/10/07(土) 10:25:02.17 ID:8Whhaa6B.net

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

428 ：デフォルトの名無しさん：2023/10/07(土) 10:55:59.28 ID:dXS7C+xF.net

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

429 ：デフォルトの名無しさん：2023/10/07(土) 19:44:18.39 ID:hE+46nhQ.net

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

430 ：デフォルトの名無しさん：2023/10/07(土) 20:50:45.55 ID:iX5KyQz4.net

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

431 ：デフォルトの名無しさん：2023/10/07(土) 21:50:44.31 ID:gQ4GHwFf.net

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

432 ：デフォルトの名無しさん：2023/10/08(日) 05:39:53.69 ID:c7bH/Jal.net

これからの時代は UTF-32

433 ：デフォルトの名無しさん：2023/10/08(日) 05:43:54.93 ID:c7bH/Jal.net

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

434 ：デフォルトの名無しさん：2023/10/08(日) 05:46:34.19 ID:c7bH/Jal.net

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

435 ：デフォルトの名無しさん：2023/10/08(日) 12:38:49.49 ID:BgGDjECm.net

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

436 ：デフォルトの名無しさん：2023/10/08(日) 13:46:55.09 ID:VA0G2N7t.net

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

437 ：デフォルトの名無しさん：2023/10/09(月) 13:08:59.15 ID:anIJ/4nw.net

えっ

438 ：414：2023/10/09(月) 14:11:34.76 ID:o3mTrHdx.net

ふーん

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

439 ：デフォルトの名無しさん：2023/10/10(火) 07:39:18.70 ID:dUGfQnTA.net

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

440 ：デフォルトの名無しさん：2023/10/10(火) 08:43:04.58 ID:5iCI9hbC.net

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

441 ：デフォルトの名無しさん：2023/10/10(火) 09:13:29.30 ID:aKJ84hs/.net

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

442 ：デフォルトの名無しさん：2023/10/11(水) 14:25:41.16 ID:+taOca1a.net

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

443 ：デフォルトの名無しさん：2023/10/11(水) 16:29:14.72 ID:dsbLch4n.net

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

444 ：デフォルトの名無しさん：2023/10/11(水) 16:32:12.66 ID:iAp1htgn.net

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