文字コード総合スレ 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/04/07(水) 09:21:37.00

>>748
ずっと前（Windows 2000の頃）から
Linuxと相互運用するものはUTF-8
Windowsでしか使わないソースコードはUTF-16だよ
Windowsでしか使わないものは少ないからほとんどUTF-8だけど

**デフォルトの名無しさん** · 2021/04/07(水) 09:24:13.21

あと秀丸とかとうの昔に使うのをやめた
遅くともSublime Text（2008年ごろ？）からUTF-8に統一
atomを経て今はvscode

それまでは何使ってたっけ？vimとかemacsとか一時期使ってたけど
そういや昔はLinuxではEUC-JPを使ってたね

**デフォルトの名無しさん** · 2021/04/07(水) 10:21:35.02

Win10 1803でANSI APIでUTF-8を使うようにする設定がベータで入ったけど、
結局MSは影響が大きすぎると判断したんだろう
代わりに1903で、システム全体じゃなくてアプリ単位でUTF-8を使えるようにする機能が入った
ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな

**デフォルトの名無しさん** · 2021/04/07(水) 11:34:30.51

> ANSI APIのデフォルトがシステム全体でUTF-8になるのは5年とか10年先の話じゃないかな
> 結局MSは影響が大きすぎると判断したんだろう

MSじゃなくても影響が大きいってわかるわ。デフォルトをUTF-8にするのは
古いアプリとの互換性を切り捨てるってことを意味する
デフォルトにしていいのは、既存のUnicodeに対応してないアプリが消え去って
互換性を気にしなくていい時代になってから。それぐらい時間がかかるのは当たり前だろう

アプリ単位でUTF-8が使えるならそれで十分でしょ
UTF-8用に作られたアプリは、システムロケールをUTF-8にするように
マニフェストかなにかで設定できるだろうし
Windows NTのデフォルトの文字コードがUTF-16に統一されてるわけだから
わざわざ古いアプリの方のデフォルトを変更する理由がない

**デフォルトの名無しさん** · 2021/04/07(水) 12:27:49.00

システムロケール（本来は古いアプリ用の設定）を
UTF-8に変更することの意味をわかってない人がいるようだから
くどいようだけどまとめておく

1. システムロケールでUTF-8を設定できるようになったのはWin10 1803から
2. 日本語をSJISで使うアプリが、システムロケールがSJISになってるのを前提としていたように
システムロケールがUTF-8になってることを前提としてアプリを作らなければいけない
3. つまりWin10 1803登場より前にシステムロケールUTF-8に対応してるアプリは存在しない

Windowsの本来の文字コードであるUTF-16に対応してるアプリ＝Unicodeや絵文字に対応してるアプリは
そもそもシステムロケールの設定には何も依存しない。

今現在システムロケールUTF-8に対応したアプリは殆どないのに
互換性を壊してまで今すぐデフォルトを変更してメリットあると思う？
そういう話。

これからはUTF-8前提で作られたアプリ（Linuxアプリ等）はWindowsに移植しやすくなりますよ。
これからはUTF-8前提で作ってもWindowsとLinuxに両対応出来ますよ。という話

**デフォルトの名無しさん** · 2021/04/07(水) 13:30:36.82

ASCII専用の欧米ソフトは案外その設定で動いたりするんだよ
ASCII圏のユーザーにとってはチェックを入れるだけでUTF-8が使えるようになる（かもしれない）便利設定
別に新しく開発するアプリのための設定というわけではない
マルチバイト圏のユーザーにとっては互換性壊すだけの余計な設定だが

ちなみにANSI APIでUTF-8を使う際には、パス名がMAX_PATHバイトまでしか扱えないという
重大な欠点があるのは注意な
Wide APIならMAX_PATHコードユニットだから、それに比べると扱える文字数は最悪1/3になる

**デフォルトの名無しさん** · 2021/04/07(水) 14:39:04.07

Unicode and Character Sets
https://docs.microsoft.com/ja-jp/windows/win32/intl/unicode-and-character-sets
Unicode in the Windows API
https://docs.microsoft.com/ja-jp/windows/win32/intl/unicode-in-the-windows-api

**デフォルトの名無しさん** · 2021/04/07(水) 16:22:47.71

>>753
間違い。昔から複数の文字コードで動くプログラムはある。
コードページ切り換えによって SJIS でも KOI8 でも BIG5 でも動くように作られているプログラムは、
修正無しで UTF-8 にも対応するようになる。
そもそもコードページの切り換えにちゃんと対応したプログラムはそうなってるのが普通。
SJIS専用処理とかしてるアホが作ったプログラムは、修正が必要だが、それは複数文字コード対応できてないんだから仕方ない

**デフォルトの名無しさん** · 2021/04/07(水) 17:58:42.18

アプリ単位でUTF-8が使えるようになってたの知らなかった
横からだけどありがとう
https://superuser.com/questions/1033088/is-it-possible-to-set-locale-of-a-windows-application-to-utf-8/1451686#1451686
のUpdateのところに対応方法がまとまってた

**デフォルトの名無しさん** · 2021/04/07(水) 20:05:39.59

>>757
一般論としてはそうだけど、WindowsのANSI系APIやVSのCRTが本当に全部UTF-8に対応してるんだっけ？

**デフォルトの名無しさん** · 2021/04/07(水) 21:05:32.99

コマンドプロンプトとサロゲートペア縛り
https://zenn.dev/zetamatta/books/b820d588f4856bcf836c/viewer/95bfb9

**デフォルトの名無しさん** · 2021/04/07(水) 22:56:12.09

>>759
Windows には山ほどライブラリ(DLL)があって、その中には対応できてなかったり、できてるはずなのにバグバグなやつとか多数ある。
今後のアップデートで直るかもしれないやつも多数あるけど、仕様上どうやって直すんだ？！みたいなやつもある。
一般論でしかないのは、その通り。過渡期なんだよ。
一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。

**デフォルトの名無しさん** · 2021/04/07(水) 23:51:48.85

> 一方で Microsoft は CP_ACP はもう使うな CP_UTF8 使えとか言い出してる。
そりゃそうだろ。CP_ACPは古いアプリが使ってるかもしれないが
それじゃUnicodeには対応できない。文字数とかサロゲートペアが
正しく判断できない。ANSI系でUnicode使うなら書き換えが必要

**デフォルトの名無しさん** · 2021/04/08(木) 01:14:14.46

>>762
ACP でも UTF8 や UTF16 が使えること知らない人は引っ込んでて。

**デフォルトの名無しさん** · 2021/04/08(木) 07:51:09.35

CP_ACPとかってMultiByteToWideChar以外どこで使うんだっけ

**デフォルトの名無しさん** · 2021/04/08(木) 08:24:03.75

相手するなよ

**デフォルトの名無しさん** · 2021/04/08(木) 14:33:47.10

過渡期30年
まだまだ続く過渡期

**デフォルトの名無しさん** · 2021/04/08(木) 16:48:36.55

コンピュータのコードなんてずっと更新中みたいなもんだけど。
MS が UTF-8 のサポートをまともに開始したのは 2017年から。
古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。
30年が何を指すのかしらんけど、あと5年や10年くらいは待ってやれ

**デフォルトの名無しさん** · 2021/04/08(木) 16:51:08.06

バッチスクリプトをUTF8で走らせられるようになったの？

**デフォルトの名無しさん** · 2021/04/08(木) 17:54:09.52

中で呼び出すプログラムが code pege 切り換え対応、もしくは utf8 対応ならバッチできるよ
例えば UTF-8 で以下のようなバッチを書けば、日本語Windowsでも動くよ
chcp 65001
echo かな漢字 > file.txt
type file.txt
pause

**デフォルトの名無しさん** · 2021/04/08(木) 18:08:44.31

>>767
> 古い文字コードを捨てて,今後は UTF-8 のみを推奨ってアナウンスしたのが 2019年から。

古い文字コードを捨ててません。
新たにUTF-8対応を増やしただけです。

Linuxは古い文字コードを捨てましたか？捨ててないでしょう。
そんなアホなことをするOSなんてありませんよ。

**デフォルトの名無しさん** · 2021/04/08(木) 18:11:58.41

>>768
それはずっと前から出来る。
少なくともWindows 2000では確認した。
ただ画面の表示がおかしくなっていただけ
処理結果はまともだった

**デフォルトの名無しさん** · 2021/04/08(木) 18:17:12.48

マルチバイト文字を含むコマンド引数がただの文字列じゃなくて、ファイルパスだったりすると積むはず。

**デフォルトの名無しさん** · 2021/04/08(木) 18:27:11.87

ファイルパスも文字列だろ

ところでなんでcp932に設定していても
絵文字が含まれたディレクトリにcdできると思う？
絵文字はcp932には含まれてない。だから使えるはずがない
だけどコマンドプロンプトでcp932にしても普通にcdできる

答えは、cp932は古いアプリ用であって
コマンドプロンプト自体はUTF-16で動いてるからなんだよ
WindowsはNTの時代にすでに完全にUnicode対応を終えてる
OSはUnicode（UTF-16）で動いている

cp932とかいうのは互換性機能でOSとしては重要ではなく
互換性機能をなくすのは、それが不要になってからで十分なわけ

**デフォルトの名無しさん** · 2021/04/08(木) 19:21:17.04

>>770
「捨てる」っていうのが正確で無かったか？サポートをしないって意味ではなくて
「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」
という方針を打ち出したんだよ。もう前のことなのでニュース記事のリンクとか出せないけど、かなり話題になった。
開発者ドキュメント等を読めば買いてると思う。

**デフォルトの名無しさん** · 2021/04/08(木) 19:30:38.81

>>771
わかってて言ってるんじゃないかと思うけど、重要なのは echo の行ではなくchcp 65001 の話。
これで TYPE の行のように正しく画面表示されるし、他のバッチから呼び出されるプログラムも UTF-8 の切替わる。
pause の行のように言語が日本語から英語に切替わってしまうので、メッセージとか日本語じゃないと困る人には駄目な方式なんだが

**デフォルトの名無しさん** · 2021/04/08(木) 19:46:39.13

>>773
お前は、バッチファイルすらまとも使ったことないだろ？
内部コードと外部(入出力)コードの区別すらまともについてないくせに、いちいちコメントすんな。
Windowsの内部コードがUTF16のことなんて全員わかってるんだよ。
みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。
バッチファイルの文字コードも外部コード。
マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。

**デフォルトの名無しさん** · 2021/04/08(木) 20:50:56.63

>>774
> 「今後は書かれるプログラムは古い文字コードをサポートする必要はない。UTF-8 だけ排他的に使用することを推奨する」

前からUnicode（UTF-16）推奨だったじゃん。
今後は書かれるプログラムは古い文字コードをサポートする必要はないのは
UTF-16でも同じことで、古い文字コードをサポートする必要なんてなかった

単にANSI系でもUTF-8が使えるようになりましたってだけだよ

**デフォルトの名無しさん** · 2021/04/08(木) 20:54:30.34

>>776
> マイクロソフトは外部コードを UTF-8 に統一する方向で動いてるって話をしてる。
そんな動きないよ

今だって標準はUTF-16だし、UTF-8もサポートしたと言うだけの話

**デフォルトの名無しさん** · 2021/04/08(木) 20:58:09.07

> みんなが議論しているのは外部コードのはなし。コードページとかUTF-8とかも全部、外部コードに何を使うか。

違うよ。コードページは古いアプリが使うコードのことだよ

**デフォルトの名無しさん** · 2021/04/08(木) 21:26:50.32

古いだの新しいだのそういう曖昧な言葉を使うのは良くない

**デフォルトの名無しさん** · 2021/04/08(木) 21:44:00.84

入出力時のデフォルトコードページの話だから古いか新しいかなんて関係ないんだけどな。

いい加減みんなこのバカ相手するのやめようぜ。

**デフォルトの名無しさん** · 2021/04/08(木) 22:03:05.49

マイクロソフト謹製のPowerShellは完全にコードページ依存だよ。
MSYSなどUTF8で出力する伝統的な実行バイナリとうまく共存できない。パイプが積む。それが現実。

**デフォルトの名無しさん** · 2021/04/08(木) 23:16:12.03

さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいないだろ。
これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。
これが UTF-16 だったり BOM つきだったりしないのは、単なる気まぐれじゃない。

**デフォルトの名無しさん** · 2021/04/09(金) 01:54:21.80

BOM付きじゃなくてBOM無しUTF-8がデフォルトになったのは驚いた
そっちに舵を切ったのはそうだろう
だがExcelでBOM無しUTF-8なCSVが扱えないとか、リソースコンパイラで
BOM付きUTF-8すら自動判別してくれないとか個々のアプリはまだまだ対応不足

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

デフォはありのほうがいいと思うんだがな

**デフォルトの名無しさん** · 2021/04/09(金) 03:06:58.40

>>780
厳密に言うならANSI系のAPIを使ってるアプリのこと
このAPIは元々Win9x用で（UTF-8に対応が発表されるまで）
Unicodeに対応してない古いアプリ用だった

つまりUnicodeに対応しているアプリは
UTF-16を使っていたということ

もちろん内部文字コードとしてUTF-8を使ってるアプリもあるだろうが
それは今も昔も変わらずUTF-8が使える
そういうアプリはOSへ処理を渡すときにUTF-16に変換して渡してる
その変換は正しく作っているなら自動的に行われるのでさほど面倒ではない

なのでアプリ開発側からすれば、そんなにメリットはない
これからはANSI系APIも使えますよーと今更言われた所で
元からUTF-8を使ってるアプリは、UTF-16への（自動）変換が
省略できる程度の意味しかない
今どきWindowsのAPIにバリバリ依存して作ることなんてないしね

**デフォルトの名無しさん** · 2021/04/09(金) 03:08:04.84

>>783
> さすがに、このスレにいて Windowsの「メモ帳」アプリのデフォルト文字コードが「 UTF-8 (BOM無し)」に変更されたことを知らない人はいな
> これはMSが UTF-8 BOM無しを今後の標準とすることに舵を切った結果だよ。

なあ。お前。メモ帳以外の事例は存在するか？
一テキストエディタにすぎないメモ帳のデフォルトが
変わった程度で騒ぎ過ぎだよ

**デフォルトの名無しさん** · 2021/04/09(金) 04:36:09.91

はぁ？
クロスプラットフォームで開発されている実行バイナリはC/C++案件が多いから、WindowsのAPIにバリバリ依存だよ
.NETなんてLinuxやmacOSで動かないだろ

**デフォルトの名無しさん** · 2021/04/09(金) 09:51:30.06

>>786
> 今どきWindowsのAPIにバリバリ依存して作ることなんてないしね
Windows の API 使わずにプログラムとかww
それこそ fopen() とかの標準Cライブラリこそコードページ依存だろ。もしかしてそれすら知らない？
Mac 使いですか？それとも Java屋さん？
Windows の API まともに知らないやつがプログラム版で Windows について語ってんの？

**デフォルトの名無しさん** · 2021/04/09(金) 10:10:06.15

> Windows の API 使わずにプログラムとかww

え？知らんの？そういうのは言語やライブラリが解決してくれるんだよ。
.NET フレームワークとか、nodeとかrubyとか
Windows APIを使わないことなんて当たり前

**デフォルトの名無しさん** · 2021/04/09(金) 10:12:26.81

> .NETなんてLinuxやmacOSで動かないだろ
動くじゃん

**デフォルトの名無しさん** · 2021/04/09(金) 10:21:23.24

EcxelがBOMなしのCSV読めんからな
メモ帳がBOM無しでも関係ないな

**デフォルトの名無しさん** · 2021/04/09(金) 11:02:02.21

それ以前に .Net デフォルトだとコードページ依存じゃないかwww
ruby は Windows のプログラムじゃないし。
node って何? もしかして Node.js のこと？まさか JavaScript 基準で Windows の文字コード語ってたの？
さすがに、それはないよね...。
node というのは聞いたことない、もしくはどれを指すのが不明なので教えて。

**デフォルトの名無しさん** · 2021/04/09(金) 12:38:07.07

>>745
話題持ち込んじゃった人だけど分かりやすい
ありがとう

**デフォルトの名無しさん** · 2021/04/09(金) 15:21:47.85

nodeはオワコン
るuびyはもっとオワコン

**デフォルトの名無しさん** · 2021/04/09(金) 17:38:21.19

>>793
ああ、今どきのWindowsプログラムを知らんのね
例えばvscodeはJavaScriptで出来てるんだよ
.NETがコードページ依存って何を言ってるんだろうか

**デフォルトの名無しさん** · 2021/04/09(金) 18:36:32.22

> .NETがコードページ依存って何を言ってるんだろうか
入出力用の文字コードの概念がないやつには一生理解できないだろう(確度の高い予測)
他の人のためにリンク張っとく
https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.default

ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。

**デフォルトの名無しさん** · 2021/04/09(金) 18:47:45.05

>>797
そんなの出されても意味がないなぁ。
言語の内部コードと、外部コードの違いわかってる？

例えばPythonの文字コードはUTF-8なわけ
それをStreamRecodeを使って自動的に外部文字コードに変換する時
https://docs.python.org/ja/3/library/codecs.html#streamrecoder-objects

Pythonの文字コードはSJISだ！コードページに依存してるんだ！なんて言わないでしょ
.NETも内部の文字コードはUnicodeなわけ
外部への文字コードへの自動変換を備えてるけど
それはほとんどの言語で標準的に持ってる機能なわけ

**デフォルトの名無しさん** · 2021/04/09(金) 18:48:43.58

そういえば、関係ないけど vscode も UTF-8 BOM無しが規定文字コードだね。
メモ帳だけじゃなくてテキストエディタは UTF-8 ってことか。

**デフォルトの名無しさん** · 2021/04/09(金) 18:51:28.05

>>797
> ちなみに Linux とかでも動くオープンソース版の .NET Core はコードページないので、UTF-8 (BOM無し)になる。

デフォルトで入ってないだけ

PowerShell on Linux(Mac)でShift-JISを扱う
https://blog.shibata.tech/entry/2016/08/22/231538

**デフォルトの名無しさん** · 2021/04/09(金) 19:25:48.50

>>798
> 言語の内部コードと、外部コードの違いわかってる？
お前がわかってないのは知ってる。ソースコードの文字コードを内部コードと勘違いしてるとか
Python の内部コードが UTF-8 だと思ってるあたり素人丸出し。
Python の内部文字コードはかなり昔から UTF-32 (UCS4) だよ。それ以前は UCS2。

**デフォルトの名無しさん** · 2021/04/09(金) 19:33:45.09

>>800
> デフォルトで入ってないだけ
デフォルトのエンコーディングの話してたの忘れたの？
入出力用の文字コードが切り換えできるのは当り前で、そのデフォルトが何かっていう話をしてるんだけど

**デフォルトの名無しさん** · 2021/04/09(金) 21:16:02.60

>>801
ID:3uc6Yjpoは何を言ってるのか分からんのでほっとくとして、
Python 3.3からはメモリ使用量節約のため、latin1, UCS2, UCS4の自動切り替えな
https://www.python.org/dev/peps/pep-0393/

**デフォルトの名無しさん** · 2021/04/09(金) 22:16:54.05

>>802
だから.NETのデフォルトはUnicodeだろ
.NETアプリが世界中の文字に対応してるってわかってますかー？

**デフォルトの名無しさん** · 2021/04/10(土) 01:56:42.91

>>803
正確にはそうだね。
ややこしい話しても絶対ついてこれないだろうと思ったの最終的に UTF=32 に落ちるのでいいかと思って簡略化しちゃった。
そこまで、ちゃんとわかってる人がいて良かった。訂正サンクス。
レベル低いの混ると、ついついレベル低い回答になってしまう。

**デフォルトの名無しさん** · 2021/04/10(土) 07:57:12.51

.NETアプリが絵文字を表示できるのはなんで？

**デフォルトの名無しさん** · 2021/04/10(土) 07:59:08.31

WPFアプリって言ったほうが正確かな？

**デフォルトの名無しさん** · 2021/04/10(土) 09:09:41.00

互換性のせいでコマンドプロンプトの仕組みが複雑だから勘違いしてるんだろうけど
コマンドプロンプト自体はUTF-16で動いてる
そうでなければUnicode文字を使ったファイル名とかが表示できるわけがない

それに対してコンソールアプリケーションはUnicode（UTF-8、UTF-16、UTF-32いずれにも対応）で
出力するモードとANSIで出力するモードを選べる
Unicodeで選んだらOSによってUTF-16に変換されてコマンドプロンプトに出力される
ANSIモードで出力した場合、OSが自動的にUnicodeに変換してコマンドプロンプトに出力する
このANSIモードからUnicodeに変換するときに利用する情報がコードページ

コンソールアプリケーションは、どれでも好きな文字コードで出力してくださいってだけだよ
コードページの情報を利用するもしないも自由
コードページの情報を無視してSJISで出力することだって出来る
まあそんな事するとコマンドプロンプト上では文字化けするがファイルに出力すればなんの問題もない

Unicodeに対応してるアプリはUnicodeモードで出力するだろうね
作り込んでるアプリなら、コードページに従うだろうねってだけの話

**デフォルトの名無しさん** · 2021/04/14(水) 13:39:34.45

練習
⥁⥀
⟳⟲
↻↺
⤾⤿
⤸⤹

**デフォルトの名無しさん** · 2021/04/14(水) 15:39:07.59

🌍🌎🌏

サロゲ

**デフォルトの名無しさん** · 2021/04/14(水) 15:40:00.22

win10
コマンドプロンプトで
chcp 65001
でも
>>810
は化けたわ

**デフォルトの名無しさん** · 2021/04/14(水) 19:39:34.04

>>810
Windows 10 のIEで表示できた
色はつかんかったけど
もちろんEdgeなら色付きで表示できた

**デフォルトの名無しさん** · 2021/04/14(水) 19:47:01.17

>>811
フォントの問題だからね
echo その文字 > test.txt とかやってファイルに書き出したら
cmd /UのUnicodeモードでUTF-16LEで問題なく保存されたよ
もちろんcmd /Aだとchcp 65001でUTF-8にしたら保存される。

**デフォルトの名無しさん** · 2021/04/14(水) 19:49:01.33

× フォントの問題だからね
○ 表示周りの問題だからね

データ自体は問題なく扱えるといいたかった

**デフォルトの名無しさん** · 2021/04/17(土) 14:25:57.05

Clarify guidance for use of a BOM as a UTF-8 encoding signature
https://www.unicode.org/L2/L2021/21038-bom-guidance.pdf

・Do not use U+FEFF as a ZWNBSP character; use U+2060 WORD JOINER instead.
・Include a BOM if one is known to be required by a targeted protocol.
・Otherwise, include a BOM when authoring a UTF-8 text file that contains non-ASCII characters,
　is not targeting a specific protocol, and may be opened by applications that will not assume UTF-8 by default
　(this is useful on systems like Microsoft Windows where some applications assume text files to be encoded with the Active Code Page).
・Otherwise, do not include a BOM.

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

>>813
/u スイッチで出力されるUTF-16LEはBOMなしなんだな
開けないエディタもあった

**デフォルトの名無しさん** · 2021/04/17(土) 16:07:47.50

>>815
要約：明示的に必要とされる場合以外は UTF-8 に BOM 入れるな。

**デフォルトの名無しさん** · 2021/04/17(土) 16:17:49.74

そうでない場合は、非ASCII文字を含み、特定のプロトコルを対象としておらず、デフォルトでUTF-8を想定していない
アプリケーションで開かれる可能性のあるUTF-8テキストファイルを作成するときに、BOMを含めるようにしてください
（これは、Microsoft Windowsのように、一部のアプリケーションがテキストファイルをActive Code Pageでエンコード
することを想定している場合に有効です）。

**デフォルトの名無しさん** · 2021/04/17(土) 19:34:14.90

>>816
BOMがなにか知っていれば、そんな感想はでてこないはずなんだがな

BOMっていうのは文字コードが「不明なモノ」を認識するためのものだよ
最初から「UTF-16である」と決まってるなら当然BOMはない

出力はUTF-16と決まってるのだから当然BOMは不要
それを文字コードが決まってないファイルに
出力したお前がつけるべきもの

ファイル形式によってはUTF-16と決まってる場合もあるだから
勝手につけるようなことはしない

◆QZaw55cn4c · 2021/04/17(土) 19:54:12.40

>>819
というか、UTF-16 における BOM って Byte Order Mark という本来の意味の方が大きいと思いますが
もっとも私はアプリ内では全部例外なく UTF-32, win32api に渡すときは UTF-16 に変換, コンテンツの外部表現は UTF-8 にしていますけれども

**デフォルトの名無しさん** · 2021/04/17(土) 19:56:30.03

だから？

◆QZaw55cn4c · 2021/04/17(土) 20:33:08.95

>>821
BOMっていうのは文字コードが「不明なモノ」を認識するためのもの、というよりは、エンディアンを知らせるためのものでは？BOM の意義はそちらの方が優勢では？

**デフォルトの名無しさん** · 2021/04/17(土) 22:23:07.48

規格では
UTF-16LE はBOM付けない
UTF-16BE はBOM付けない
UTF-16 はBOM必要
これらは別物なので混同するのは良くない。

**デフォルトの名無しさん** · 2021/04/17(土) 22:25:44.67

>>819
事実を明示しただけなのに、何ドヤってんだよ

**デフォルトの名無しさん** · 2021/04/17(土) 22:30:24.80

819はUTF-16にBOMが必要という常識すら知らない素人。

**デフォルトの名無しさん** · 2021/04/17(土) 22:57:11.23

UTF-16にBOMが必要なら、なぜついてないのか説明してくれ

**デフォルトの名無しさん** · 2021/04/17(土) 23:00:00.38

>>823
規格書ぐらい読みましょう
https://www.unicode.org/versions/Unicode12.0.0/UnicodeStandard-12.0.pdf

The UTF-16 encoding scheme may or may not begin with a BOM. However,
when there is no BOM, and in the absence of a higher-level protocol, the byte
order of the UTF-16 encoding scheme is big-endian

UTF-16 のエンコーディング方式は、 BOM で始まることも、そうでないこともあります。
しかし、BOM がない場合、また、上位プロトコルがない場合、
UTF-16 符号化方式のバイト順序はビッグエンディアンです。

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

ちょくちょく >>823 みたいな読解力ない人が沸くよね
なんでだろ

**デフォルトの名無しさん** · 2021/04/18(日) 04:36:32.83

要するに「UTF-16」のパターンは5種類あるってことだね
UTF-16BE 00 4D
UTF-16LE 4D 00
UTF-16 BOM(BigEndian)　FE FF 00 4D
UTF-16 BOM(LittleEndian) FF FE 4D 00
UTF-16 BOMなし(=BigEndian) 00 4D

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

ビッグエンディアンとリトルエンディアンの2つだけだよ
あとはBOMがあるかどうかだけ

**デフォルトの名無しさん** · 2021/04/18(日) 08:08:13.68

base64エンコーディングを加えればバリエーションはさらに増えるよ
よかったね

**デフォルトの名無しさん** · 2021/04/18(日) 08:12:27.46

玉子とかお新香つけたらバリエーションさらに増える

**デフォルトの名無しさん** · 2021/04/18(日) 16:24:37.92

>>829
五番目と最初は全く同じバイト構成になるので4種類が正解。
BOMなしの UTF-16 は実質 UTF-16BE の別名に過ぎない。

**デフォルトの名無しさん** · 2021/04/18(日) 16:31:23.17

BOMはパターンじゃなくて追加のシグネチャだよ
もしこれがHTMLだとしてUTF-8というメタタグがない場合
それはUTF-8とは別のパターンになるかと言ったらそうはならない

パターンとしては同じUTF-8であり
シグネチャがあるかどうかの違いでしかない

**デフォルトの名無しさん** · 2021/04/18(日) 19:12:05.70

BOMでこうまで話が続くのな

**デフォルトの名無しさん** · 2021/04/18(日) 19:24:29.98

なつかしのfree論争みたいだな

**デフォルトの名無しさん** · 2021/04/18(日) 21:03:03.56

Malloc and Free
https://groups.google.com/g/fj.comp.lang.c/c/G4HRnHTdImg

**デフォルトの名無しさん** · 2021/04/18(日) 22:24:15.55

>>837
うわなつかしい、俺のアドレスもあったw

**デフォルトの名無しさん** · 2021/04/18(日) 22:45:16.09

議論の理由も似てるかも
free()が必要かどうかは環境による。基本は必要最低限で使え。
BOMが必要かどうかは環境による。基本は必要最低限で使え。
というのが正しい答えだが、特定の環境のみ前提に主張するやつや、
念のためにいれておこうと考える不届き者のせいで話が混乱する。

**デフォルトの名無しさん** · 2021/04/19(月) 00:36:54.81

ぜんぜん違うな。BOMはUnicodeの仕様

**デフォルトの名無しさん** · 2021/04/19(月) 00:38:28.03

>>837
俺はこれ知らんかったけど、太田・久野・河野…とそうそうたるメンバーですなあ懐かしい

**デフォルトの名無しさん** · 2021/04/19(月) 00:41:47.58

昔はみんなバカだった

◆QZaw55cn4c · 2021/04/19(月) 00:43:04.40

>>839
それに「そもそも BOM という名前が」云々の原理主義者もお忘れなく、あー私のことか‥‥

**デフォルトの名無しさん** · 2021/04/19(月) 01:58:51.92

つまりBOMの話題はプログラマ界隈にとって爆弾のようなものだ、とこういうことか

**デフォルトの名無しさん** · 2021/04/19(月) 03:49:32.03

>>844
ミニマム・シンプルというのがプログラムの基本というのが理解できないやつがいる。
「不必要なものは入れるな」というのは最低限の知識.

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

パーセントエンコーディングした文字列を正確にURL引数に渡すには
文字エンコーディングをサーバーに教えるためのパラメーターが別途必要になる。
だが、しかしサーバー側アプリにはBOMの情報をまるっと捨て去って平然と不具合を起こす権利がある。
文字エンコーディングをサーバーに教えるためのパラメーターと同じ役割を果たすのがBOM。
テキストエディタやコンパイラやブラウザはBOMをガン無視する権利がある。

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

すっげー、面白い解釈してるな。どの規格読んだの？
URI は全体で一つの文字列なので、BOM つけるのなら最初の https: とかの前につけないと意味ないんだが？
そんな規格違反の URI に対応する必要があるという主張? それとも文字列の途中に BOM を入れて解釈しろという主張？

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

>>845
ギチギチしたら拡張性がなくなるだろ

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

不要なもの入れるな＝16bitあれば十分＝破綻ｗ