文字コード総合スレ Part12

**デフォルトの名無しさん** · 2018/12/17(月) 16:48:24.47

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/
　（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
　（隔離スレ）UnicodeとUTF-8の違いは？　その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.net/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.net/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.net/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 http://mevius.5ch.net/test/read.cgi/tech/1516629503/

**デフォルトの名無しさん** · 2021/03/09(火) 11:13:42.05

>>610
EUCとUTF-8と同じようにC言語とC言語で作られてる
Unixのソースコードと互換性があるように作られたことを知ってますか？
そしてEUCがどうしましたか？

**デフォルトの名無しさん** · 2021/03/09(火) 17:39:10.59

キャラクタセットは選ぶもの

**デフォルトの名無しさん** · 2021/03/09(火) 17:40:37.43

アスキー文字は1バイトで同じ文字コードにしたいのはあたりまえ

**デフォルトの名無しさん** · 2021/03/09(火) 17:41:09.24

UTF-16にこだわったのは欧米人

**デフォルトの名無しさん** · 2021/03/09(火) 17:53:03.04

>>612
UTF-16を選べるというのなら選んでみるが良い
互換性がないキャラクタセットはサポートされていない

**デフォルトの名無しさん** · 2021/03/09(火) 19:47:21.10

UTF-16はユニコードの文学的表現と、あわしろ氏が言ってた。

**デフォルトの名無しさん** · 2021/03/09(火) 19:49:34.87

じゃあ間違いってことだな

**デフォルトの名無しさん** · 2021/03/09(火) 22:12:38.95

UTF-16 にこだわったわけじゃないだろ。
昔こだわってたのは16ビット固定長。
当時の非力なパソコンだと都合が良かった。

ワークステーションとか性能に余裕がある機械使ってる人たちから絶対に文字数足りなくなる阿呆仕様とか言われてたが、仕方なかった。

後に性能に余裕が出てきた時に既に16ビットでOSとかAPI設計・使用していたので、16ビット可変長を導入した。それが今のUTF-16。

**デフォルトの名無しさん** · 2021/03/10(水) 23:22:37.08

ISO/IEC 8859-1前提で作られていたはずなのに
いつの間にかUTF-8に乗り換えようとしてる？とうに乗り換えた？
WWW(のHTTP)の世界

**デフォルトの名無しさん** · 2021/03/15(月) 00:38:41.86

0x7Fだけでなく0xFFがDELとして定義されていないのは
0x80-0xFFに文字が定義された時には既に紙テープは使われなくなっていたという事なのかな

**デフォルトの名無しさん** · 2021/03/15(月) 08:07:57.71

その紙テープとDELの話、機能的に必要だからそうしたというわけじゃないと思うがな。
DELは「削除する」文字なのに紙テープは「削除された」文字になるよね。

**デフォルトの名無しさん** · 2021/03/15(月) 09:04:25.39

その 0x80-0xFF というのが 0xFF に文字を割当ててる ISO8859の時代ことなら、もう紙テープななんか使ってなかった。
それより古いの、例えば JISX0201 のカナとかの時代でもほぼ紙テープなんか使ってなかったけど 0xFF は未定義で文字は割当なかった。

**デフォルトの名無しさん** · 2021/03/16(火) 14:48:47.22

「削除する」というよりか「これは間違いだから無視してね」という印、みたいな感じ

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

モールス信号は単音と長音の組み合わせだからビット表示みたいなもんかな

**デフォルトの名無しさん** · 2021/03/16(火) 21:56:06.00

へー、DELをバックスペースの意味で使うようになったのが後付けなのか。
https://ja.wikipedia.org/wiki/削除文字

**デフォルトの名無しさん** · 2021/03/18(木) 22:37:10.93

制御文字はASCIIコードの最初を占めているのにCUIでのコマンドに使わないのはもったいないと思う。
昔は制御文字をコマンドとして使っていたんだから
例えばSMTPは制御文字のSOH STX ETX EOTをコマンドにしてもよかったのでは

**デフォルトの名無しさん** · 2021/03/19(金) 00:35:37.02

あのう…、素人がひとつお尋ねしたいのですけど、よろしいですか？

大昔からWindowsパソコンを使っていて
今までにエディタで書いたテキスト資産をたくさん持つ人が
これからもWindowsパソコンを使い続けると仮定するなら
新しく書くテキストデータの文字コードは何を使えば良いのでしょう？

従来どおりShift-JIS？　それともUTF-8？
なお、テキストは書くだけではなく他人から貰ったデータを読むこともあります

**デフォルトの名無しさん** · 2021/03/19(金) 00:37:01.06

ゴメンなさい、最後の一文は
コピペしてテキストをマージすることもある、の意です

**デフォルトの名無しさん** · 2021/03/19(金) 01:21:48.92

Windowsは表面的にはシフトJISですが、内部はUTF-16です。

メモ帳がBOM付きUTF-8に対応したりとしているので、UTF-8でも特に問題ありません。

テキストエディタやOffice製品でSJISが使えなくなることは、想定しなくてもいいと思います。

**デフォルトの名無しさん** · 2021/03/19(金) 01:23:29.57

日本語の世界でSJISがなくなることは想定しなくてよいという意味です。

**デフォルトの名無しさん** · 2021/03/19(金) 06:55:45.01

>>627
UTF-8一択
絵文字も使えない文字コードなんて使えるか

**デフォルトの名無しさん** · 2021/03/19(金) 07:01:30.18

>>629->>630
有り難うございます、てことは…
別に今後もずっとSJISだけを使い続けて良い…という言い方もできますかね？

実はメールでテキストをやり取りする際、相手がHTMLメール使っていたりすると
なぜか「～」が文字化けしたり、しなかったり…、コピペの時に苦労しておるのです

**デフォルトの名無しさん** · 2021/03/19(金) 07:03:11.89

>>631
いや、絵文字は一生使うつもりがありませんｗ

**デフォルトの名無しさん** · 2021/03/19(金) 07:53:48.58

自分自身が絵文字を使うかどうかは重要じゃなくて、他人の書いた絵文字を含む文書を劣化させずに保存できることが重要

◆QZaw55cn4c · 2021/03/19(金) 08:22:24.74

>>631
絵文字は不要、誰が絵文字なんかを文字コードの中に押し込んだんだ？

**デフォルトの名無しさん** · 2021/03/19(金) 08:45:35.33

>>635
Appleだよ

https://ja.wikipedia.org/wiki/MacJapanese

**デフォルトの名無しさん** · 2021/03/19(金) 09:58:34.93

>>636
具体的にどれが?
一般的にはガラケーの各キャリアでは?

**デフォルトの名無しさん** · 2021/03/19(金) 13:03:56.18

最初にコード化したのは誰かって意味ならワープロメーカーとかじゃね？
unicodeに入れたのはgoogle。
その元になった絵文字セットのうちの1つを最初に作ったのはドコモ

**デフォルトの名無しさん** · 2021/03/19(金) 14:00:06.98

MSが何を考えているか外からではわからないけど
S-JISは切り捨てる可能性があるんじゃないかな

**デフォルトの名無しさん** · 2021/03/19(金) 14:15:07.57

>>639
「切り捨てる」の定義次第でしょ。
ゴールポストを動かすように定義を変えることもできる。

**デフォルトの名無しさん** · 2021/03/19(金) 15:26:48.13

>>633
macだとcuiでも絵文字使ってるプログラムが増えてて、見やすいしわりと便利よ

**デフォルトの名無しさん** · 2021/03/19(金) 16:19:10.35

Powerlineとかのプログラミング用の絵文字
あれUnicodeに入れてくれないかな？

◆QZaw55cn4c · 2021/03/19(金) 16:31:55.75

歩香桂銀金王角飛と杏圭全馬龍の逆さ文字は追加してほしいなぁ……

**デフォルトの名無しさん** · 2021/03/19(金) 17:45:59.37

Unicodeの絵文字は全世界で使われているからね。

**デフォルトの名無しさん** · 2021/03/19(金) 17:46:52.40

日本の絵文字がベースだから、日本人っぽいものが多い。

**デフォルトの名無しさん** · 2021/03/19(金) 18:07:03.09

>>643
文字を所定角度に回転させる異体字セレクタがいくつもあれば一番いいんだけど
30度ごとならアナログ時計の表現にも使えそう

**デフォルトの名無しさん** · 2021/03/19(金) 22:38:34.45

あのう…、皆さん色々ありがとうございます

それで…、結局のところ私は…、これから先テキストを新しく書いた時に
そのテキストデータの文字コードを何にして保存すれば良いのでしょうか？

**デフォルトの名無しさん** · 2021/03/19(金) 23:10:26.99

何回も何回も裏切られてきたからな
一寸先は闇
UTFが優勢ではあるけど
何があるかわからん

◆QZaw55cn4c · 2021/03/19(金) 23:12:46.09

>>647
BOM 付きUTF-8 でいいんじゃないでしょうか…

**デフォルトの名無しさん** · 2021/03/20(土) 00:19:36.84

異体字セレクタは無視可能だから>>643みたいな対比が重要な用途には向かん

**デフォルトの名無しさん** · 2021/03/20(土) 03:11:58.85

>>649
UTF8 に BOM はいらんだろ。(原理主義)

**デフォルトの名無しさん** · 2021/03/20(土) 03:46:25.95

>>647
文字コードはなんでもいいので、...を空文字列に置換してから保存してください

**デフォルトの名無しさん** · 2021/03/20(土) 04:03:35.66

>>651
627のwindowsでの質問なのでbom付きのが良い

**デフォルトの名無しさん** · 2021/03/20(土) 06:00:23.16

BOM付きはエラーの原因になったりするんだよね
647レベルだと恐らく原因にたどり着けない

**デフォルトの名無しさん** · 2021/03/20(土) 12:04:30.81

個人用なら UTF8一択でいいよ

ただし、以下が注意かな
1. 納品先、提出先の指定、プロジェクトでの指定があるなら合わせる
2. UTF8に対応していない古いツール類（エディタ含む）を使って処理しているなら合わせる

**デフォルトの名無しさん** · 2021/03/20(土) 13:21:00.17

>>654
エラーの原因になるというか、そのソフトがUTF8シグネチャに対応してないってだけだな。
結局のところ使うソフトや環境次第。
WindowsメインならUTF8シグネチャ付きの方がトラブルは少ないだろう。

**デフォルトの名無しさん** · 2021/03/20(土) 14:11:52.17

BOM なしUTF-8(UTF-8N)が良い

Windows と言っても、WSL でLinux を使うかも知れないから、
BOMを付けると、動かないかも

**デフォルトの名無しさん** · 2021/03/20(土) 14:43:30.24

winにはofficeとか、utf-8でもbomがないと化けるメジャーソフトもあるんだよなあ

**ID:pLBLA8wx** · 2021/03/20(土) 17:23:15.32

皆さん本当に色々とありがとうございました！

出てくる単語を片っ端からググって再確認しつつ、もっとも普遍的原理的な
考え方を自分の頭の中で屁理屈として組み立てあげました！

結論：これから私は、書いたテキストを原則UTF-8で保存する
　　　　 (→必要に応じてBOMをつけて保存し使うこともある)

本当に勉強になりました。２日で１０年分(か２０年分)勉強した感じですw。

**デフォルトの名無しさん** · 2021/03/20(土) 18:05:23.87

もつかれ

**デフォルトの名無しさん** · 2021/03/21(日) 02:58:59.19

UTF8はBOMがないのが正式。規格書嫁。
BOMが付くのは他の文字コードから変換の時に頭悪いソフトが削り損ねたか、
メモ帳のように文字コード対応が不完全なソフトが、独自の文字コード判別機能のために規格無視で突っ込んだ
くらい。

**デフォルトの名無しさん** · 2021/03/21(日) 08:53:26.10

BOMはオプション的な扱いだけど正式なRFCの仕様だが？
プロトコルとして文字コードを決め打ちする場合とか他の方法で文字コードを受け渡す
仕組みがある場合はBOMを使用すべきではないというくらい。
そもそも「文字コード対応が不完全なソフト」って、UTF-8決め打ちのソフトのことじゃね？

**デフォルトの名無しさん** · 2021/03/21(日) 10:07:00.18

>>661
UTF-8のBOMがなかったら以前の文字コード（日本だったらSJIS）とUTF-8の区別がつかないんだよ。
UTF-16やUTF-32なら1バイト単位で見た時にNULL文字が多数登場するという特徴があるが
UTF-8はバイト列をフルに使って詰め込んでるから区別することが不可能
UTF-8のBOMはUTF-8とそれ以外の文字コードを区別するための機能

昔は文字コードが自動判定できてたって？それはSJISとEUC-JPみたいに
バイト列をフルに使ってない文字コードかつ、日本語しか考慮してないから
できてたことなんだよ。UTF-8とそれ以外の文字コード判別は無理

◆QZaw55cn4c · 2021/03/21(日) 10:20:33.48

>>661
＞UTF8はBOMがないのが正式。規格書嫁。

であれば規格書（）にわざわざ UTF-8 のための BOM 0xEF 0xBB 0xBF が定義されているのは、なぜでしょうか？

**デフォルトの名無しさん** · 2021/03/21(日) 10:46:26.36

規格はちゃんと読めとしか。
例えば Unicode 13.0 での扱いは
1) U+FEFF は基本は Zero Width Non-Breaking Space
2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark
3) Unicode Signature としても使用できるが、プロトコルが型無しの場合に使用し、それ以外では使用を推奨しない
という扱いだ。1) と 2) と 3) は別の使い方だと理解するところから始めろ
UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)

UTF-16 から UTF-8 に変換する時は 1) の意味なら残す、2) の意味なら削る、3) の意味ならプロトコル次第。
不明ならば基本の 1) を仮定して残すのが正しい実装だ。

**デフォルトの名無しさん** · 2021/03/21(日) 11:32:14.01

>1) U+FEFF は基本は Zero Width Non-Breaking Space

「本来は～だった。」が正しいだろうな。
その意味で解釈するのはストリームの先頭以外に現れた場合に限るとされているし
今ではその意味でも使用すべきではないということになった。

>2) バイト列化した UTF-16 と UTF-32 の先頭に来た場合は Byte Order Mark

RFCで言う"BOM"にはバイトオーダーマークとシグネチャの両方の機能があって、
バイトオーダーマークとしての意味はUTF-16やUTF-32だけだけれども
シグネチャとしての意味はUTF-8でも有効だと書いてあるだろう。

**デフォルトの名無しさん** · 2021/03/21(日) 12:02:55.18

最新規格でも ZWNBS が正式。BOM は例外的な使用法。
「だった」って過去形で主張するんなら規格のどこに過去形書いてあるか、どの規格で廃止されたか示してみろ。
カタカナでバイトオーダーマークって書いても誤魔化せないぞ。

**ID:pLBLA8wx** · 2021/03/21(日) 13:46:50.50

けんかをやめて　二人をとめて
私のためにBOMで争わないで　もうこれ以上

**デフォルトの名無しさん** · 2021/03/21(日) 14:28:20.22

ああそうだな。文字の定義自体は変わっていないからその意味では過去形はおかしかったかな。
ただRFC3629では、今は同じ意味のU+2060があるからそっちを使うことを「強く推奨する」と。

**デフォルトの名無しさん** · 2021/03/21(日) 15:38:22.99

https://www.unicode.org/charts/PDF/UFE70.pdf
>may be used to detect byte order by contrast with the noncharacter code point FFFE
>use as an indication of non-breaking is deprecated; see 2060 instead
non-breakingとして使うのはdeprecatedだと言ってるし過去形でいいんじゃね
BOMとしての使い道だけが残った

**デフォルトの名無しさん** · 2021/03/21(日) 23:32:21.54

> UTF-8 でも 1) は普通に使える、2)としては使用できない、3)はプロトコル次第(HTTPだと非推奨、FTPだと可)

Byte Order Markの意味わかってんのか？
UTF-8は1バイト単位で扱う文字列なんだから、2として使い方に
意味がないのは当たり前だろ。使えないというより意味がない
使っては駄目という意味じゃない。使ってもいいが本来の意味がないというだけだ。

16bitまたは32bitのときの順番を判断するためにあるのに
Byte（バイト） Order（順番） Mark（記号）

つまりU+FEFFは「文章のどこでも使っていい文字」で
先頭に来た場合に限りBOMとして解釈するというだけだ

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

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

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

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

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

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

>>673
英語よめないの？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Officeのalt/shift+retとかで特殊な改行したりするけど、ちゃんと対応するASCII制御文字入ってたんだなと感心してしまったもんで

**デフォルトの名無しさん** · 2021/03/31(水) 10:06:28.66

表の階層化にFS, GS, RS、複数行セルにVTとか使ってるねー、面白い
echoでコピペしてみたけどこれは受け付けてくれないっぽい…残念

**デフォルトの名無しさん** · 2021/04/02(金) 14:48:41.83

メモ帳で折り返しにCR CR LF入れるとかもこの流れなのかな？

**デフォルトの名無しさん** · 2021/04/04(日) 09:56:09.95

やはりBOMは必要だな

「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話
https://qiita.com/heeroo_ymsw/items/c6e15d5f9246b4e842eb

**デフォルトの名無しさん** · 2021/04/04(日) 11:25:45.54

>>689
きになる
Format>WordWrap?だよね

折返した状態で保存みたいなオプションがあるのかな

当たり前だけど保存しても改行してない（してたらバグだw
表示上だけ入れてるのかとコピペしても拾えない
内部で描画のコントロールに使ってるということ？かな？

**デフォルトの名無しさん** · 2021/04/04(日) 11:47:39.11

>>690
要するに
UTF-8、但しASCII/sjisとの共通部分はダメ、かつ英数字のみを使いたいということね

０１２０―ＡＢＣーＸＹＺ（ユニコfull-width latin

これで要件を満たせる！

**デフォルトの名無しさん** · 2021/04/04(日) 11:59:15.19

顧客が本当に求めていたモノ…

**デフォルトの名無しさん** · 2021/04/04(日) 20:11:30.38

BOM付きだな
頭でっかちの原理主義者はいつでも間違っている

**デフォルトの名無しさん** · 2021/04/05(月) 01:33:23.71

あほ過ぎる
UTF8 や本来のSJISやEUCはASCIIの完全上位互換なのがメリットなのに BOM 入れて互換性無くすとか素人の極み。
ASCIIと互換性無くていいんなら UTF16でも使ってろ。

**デフォルトの名無しさん** · 2021/04/05(月) 01:40:26.92

その考え方がそもそもの間違いだわ

**デフォルトの名無しさん** · 2021/04/05(月) 01:48:11.31

全角で納品したら楽しそうだからそれで

**デフォルトの名無しさん** · 2021/04/05(月) 07:02:33.51

ファイル名にいちいちBOMが入ってて、ASCII で書かれたファイル名と、UTF8で書かれたファイル名が、別ファイルとして扱われる世界。
考えただけでも吐き気がする。

**デフォルトの名無しさん** · 2021/04/05(月) 08:21:19.81

ファイル名にBOM入れる奴はさすがにいないだろ…
いないよね？

**デフォルトの名無しさん** · 2021/04/05(月) 09:04:19.64

BOMは"ファイル"に入れるのは別に悪くないと思ってる
明示できるものは明示すべきだろう、何でもutf-8の時代になりつつあるから、むしろ他のutfやsjis/eucに入れるのが時代にそぐう
もはやBOMじゃなくて単なるマジックナンバーだが

ファイル名…ってのは正直思いつかなかった
でもBOM付きの細かいテキストを文字列として継ぎ接ぎした時にトリムするのが面倒だった経験があるわ
やはりマジックナンバー、テキストファイル=マジックナンバー+テキストとして扱うべき
テキストファイル以外に付けるのは勘弁

**デフォルトの名無しさん** · 2021/04/05(月) 11:09:52.26

そりゃ仕様できっちりとBOMを入れませんと
なってるものにBOMを入れる必要ないだろ

テキストファイルの場合はいろんな文字コードが
歴史的な経緯で許可されてるフォーマットだから
BOMをファイル形式を判断するヘッダとし
て利用するというだけであって

**デフォルトの名無しさん** · 2021/04/05(月) 11:12:15.44

>>695
BOMはテキストファイルにおいて文字コードを判別するための仕組み
BOMによってSJISやEUCではないと判別できるのに
互換性がなんの関係があるのか？
SJISやEUCと互換性がないからこそ、文字コードを判別するのに利用できる

**デフォルトの名無しさん** · 2021/04/05(月) 11:51:41.26

なんで UTF -8 と SJIS の互換性気にせにゃならんねん。
これやから、ロートル多いスレは。
今からの時代 BOM なんかくてもデフォルトは UTF-8 だよ。
Linux とか Mac は既にそうなってるし、日本語WIndowsだって次か、次の次のメジャーバージョンくらいで SJIS 捨てて UTF-8 いくやろ。
過去に生きてるやつはBOM 必要かもしれないが、今が過渡期なのでそんな気がしてるだけや。
どうせ欧米がナロー系の文字コードは UTF-8 に一本化で動いてるんで、今さらどうにかなるもんでもない。

**デフォルトの名無しさん** · 2021/04/05(月) 13:58:26.49

>>703
すぐバレる嘘を付くな

> Linux とか Mac は既にそうなってるし、
Linuxはローケルの変更から日本語だとEUC-JPに対応しているしSJISも使える
https://www.early2home.com/blog/os/linux/post-1314.html

WindowsはNTは最初からUTF-16だ

**デフォルトの名無しさん** · 2021/04/05(月) 14:08:55.17

ぶっちゃけUTF-8をマトモに実装するのは難しいので勘弁してほしい
正規化とかわけわかんぬ…
プログラミング言語やライブラリの内部ではコードポイントそのままで固定長で扱いやすいUTF-32採用が多いね
後に成熟してきたら変換のオーバヘッド削る為にUTF-8に切り替える風潮だけど（pythonはじめ諸々

将来ネットワークのスループットが良くなればUTF32も受け入れられたりしないかな、それまで生き残ってればの話だが

**デフォルトの名無しさん** · 2021/04/05(月) 14:19:53.71

>>704
デフォルトって言葉の意味知ってる？

**デフォルトの名無しさん** · 2021/04/05(月) 15:36:03.55

>>706
WindowsのデフォルトはUTF-16です。
英語のアメリカでも日本語のSJISがデフォルトだとでも思ってた？
そんなんだから理解が浅いって言われるわけ

**デフォルトの名無しさん** · 2021/04/05(月) 15:37:39.57

>>705
UTF-32はもはや固定長じゃないよ

漢字1文字が最大8バイトUnicodeの「IVS」が
32bit、4バイトに収まるわけがない

**デフォルトの名無しさん** · 2021/04/05(月) 16:24:25.38

デフォルト、破産だよ
デフォルト国家、あの国やったろ

**デフォルトの名無しさん** · 2021/04/05(月) 17:09:09.07

>>707
日本語Windows のデフォルトの話してるのに、何で英語のアメリカとか関係してくるんや？
文字が読めない人なのだろうか？
お前の Windows 日本語インストールして直後のカスタマイズ無しの状態でコマンドプロプトで chcp って打ったら何と応えるの？