文字コード総合スレ 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/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あれば十分＝破綻ｗ

**デフォルトの名無しさん** · 2021/04/19(月) 13:35:40.29

それは不要なもの入れる入れないではなくて、拡張性のある実装と拡張性の乏しい実装の違い。
unicode の文字の中には余計なものもあることは認めるが、それは関係ない。

**デフォルトの名無しさん** · 2021/04/19(月) 13:37:50.42

>>850
つまりUTF-32が正解ってことでしょ？

**デフォルトの名無しさん** · 2021/04/19(月) 15:24:44.16

その辺は既に結論が出てる。
UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。必要なら32bitまで拡張可能。外部コードに最適
UTF-32: 固定長。必要なら32bit分の文字まで拡張可能。内部コードに最適。
UTF-16: メリットがない。拡張性ない。オワコン。将来は特定のOSやプログラム言語やアプリで過去の遺物として残る

**デフォルトの名無しさん** · 2021/04/19(月) 16:02:17.06

UTF-32が固定長なのはすべての文字が32bit長に収まる時期限定の話でしかない
いずれUTF-64を固定長として定義してUTF-32を可変長にせざるを得ない
そしていつの日かUTF-64も可変長になる日が来る
以後ループ

**デフォルトの名無しさん** · 2021/04/19(月) 17:13:36.69

>>852
あのさ、UTF-32のBOMを無視するなよ

**デフォルトの名無しさん** · 2021/04/19(月) 17:22:51.43

> UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。
って言ってるのに、これが
欧米ではない文章だとUTF-16に劣るという
意味になるってわかってないのかな？

**デフォルトの名無しさん** · 2021/04/19(月) 17:25:16.03

UTF-16だと2バイトですむのに、UTF-8だと3バイト必要だからな
データ量が33%増加する

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

日本語の漢字かな中心の文章や、中国語の文章などでは UTF-16 の方が短かくなるけど
欧米のやつらは日本語での長さなんて気にもかけないので。もはや UTF-16 はオワコンで意見が固まってる。
欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
日本のすみっこで、いくら叫んでも世界の流れは変えられないのだ。
少し腹立つけど仕方ない。

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

WindowsやJavaの内部エンコードに使われている限り生き続けるだけだろ。日本がどうとか関係ない。

>欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。

そのマルチバイトエンコーディングからUTF-16に乗り換えたWindowsやJavaの中の人は欧米なんだが。
もしかしたらUTF-8を推したいのかもしれないけど論理が支離滅裂。

**デフォルトの名無しさん** · 2021/04/19(月) 21:18:27.77

U+xxxxxxxxで表現されるバイト列をRAWデータで扱うための概念としてUTF-16,UTF-32は必要とされ続ける

**デフォルトの名無しさん** · 2021/04/19(月) 21:27:04.16

合成文字があるのにいつまで固定長なんて幻想にしがみついてんだよ

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

これからはUTF-16の時代だって思うやつがいるんなら英語の掲示板に行ってぜひ布教してくれ。
もう世の中の流れは変わってることがわかる。昔に戻せるならやってみてくれ。
無理だと思うが、個人的には嬉しいので。

**デフォルトの名無しさん** · 2021/04/20(火) 04:46:32.12

git diff コマンドがUTF-16テキストファイルをバイナリ扱いして困る

**デフォルトの名無しさん** · 2021/04/20(火) 08:00:32.57

これからはUTF-16の時代だなんて思う奴はまずいないだろうが、
これからもUTF-16の時代が続くと思う奴はいるだろう。

**デフォルトの名無しさん** · 2021/04/20(火) 10:21:46.36

欧米の奴らも絵文字は使いたがる、これはある意味いいことかも。

**デフォルトの名無しさん** · 2021/04/20(火) 10:27:53.52

>>861
これからもなにもずっと前からUnicodeの時代で
UTF-16もUTF-8もその表現の一つでしかないんだが
WindowsのAPIは柔軟だから両方に対応してるね

**デフォルトの名無しさん** · 2021/04/20(火) 21:54:20.56

U+xxxxxxxxで表現されるバイト列をRAWデータで扱うためとしても
UTF-16は桁が足りないんだからUTF-16を使っている箇所はUTF-32に移行すべき

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

ASCII文字も1文字=7bitを前提にした文字の並びになっているから
1文字=8bitを前提に文字の並びを変えて
ISO646による言語別の文字の変更（バックスラッシュが円マークになる）も
廃止すればシンプルになっていいね。
ISO8859でもASCII文字の部分は何も変えなかったのは
ASCIIとISO646が普及してしまって変えられなかったから？

**デフォルトの名無しさん** · 2021/04/21(水) 18:25:00.32

文字コードとフォントは別のものだから…

**デフォルトの名無しさん** · 2021/04/21(水) 18:26:38.07

過去のファイルは編集されずにずっと残るんだから古いファイルを
開くために仕様や規格を廃止することは不可能だよ
これからの話しか見えてないのは視野が狭すぎる

**デフォルトの名無しさん** · 2021/04/21(水) 20:28:41.18

過去の文字コードってASCIIでしょ。だったらUTF-8でそのまま読めるじゃん。というのがアメリカンの発想。
ローカルなSJISなどというものは念頭にない。ASCIIに比べれば大した量ではないので変換でも何でもしろくらいに思ってる。
オープンソース系のアプリとか気の早いやつは、もうUTF-8以外のサポート切り捨てようとか本気で言い出してる。
まだ時期尚早と説得してるが、どうなることやら。

**デフォルトの名無しさん** · 2021/04/21(水) 20:58:34.18

もうAltコード覚えてしまってるから勘弁して
まあ今もアプリ側でマップしてるだろうけど、文字セットの実装が失われると参照が難しくなり方言化が進む
なにより二重ループで一覧表生成出来なくなるだろうしやだー

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

コードポイント=エンコードにできるはずの128-255を捨てるutf-8一人勝ちは避けたい
欧州文字セットでも記号類とか重宝する
8-bitクリーンかを気にする機会減ってきたし、新規参入の機会では
ダイアクリティカルマークは別バイトにすれば記号いっぱい詰め込めるだろ

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

>>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの

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

>>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの

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

Windows用実行バイナリの場合、システムの文字コードに依存したC言語ライブラリを使ってコンパイルされた実行バイナリが大部分だから、移行は簡単じゃないよ。
新しいライブラリにリンクするよう作り直したバイナリを再配布する必要がある。動作検証がたいへん

**デフォルトの名無しさん** · 2021/04/21(水) 22:23:29.33

>>875
例えばどんなのがありますか？

**デフォルトの名無しさん** · 2021/04/21(水) 22:29:47.38

お堅くwin32API叩いて書かれたバイナリの互換性は驚異的だよな
MSが気まぐれに出しては忘れるフレームワーク叩いてたら知らんが

バイナリ配布文化を育ててしまった原因でもあるが、ここまで大事にしてきたのにエンコード対応なんかで折れてもらっては残念
win10(64bit)でoffice97が元気に動くのは誇っていい

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

>>876
ロケール指定する処理が省かれたC言語アプリ全般

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

>>878
だからそれはどれかって聞いてる

**デフォルトの名無しさん** · 2021/04/21(水) 23:11:26.55

大部分と言う割に、事例を一個も思いつかないなら矛盾してる

**デフォルトの名無しさん** · 2021/04/21(水) 23:20:34.30

Cで書かれたレガシープログラムほぼ全部なので挙げるまでもないんだけど、有名どころだとPerlだね
システムコード以外の文字を含むファイル名をperlに引数で渡せない

**デフォルトの名無しさん** · 2021/04/21(水) 23:26:30.87

Cで書かれたmain()関数にはシステムコードページで引数が渡されるのだけど、その時点で文字化けしてるので復元不能。

**デフォルトの名無しさん** · 2021/04/22(木) 09:25:25.74

>>880
お前、もう少し黙っとけ。無知過ぎる。
アホを晒し続けてるの実は同一人物だろ。

**デフォルトの名無しさん** · 2021/04/22(木) 11:05:09.03

このスレ読んでるとハゲそう

**デフォルトの名無しさん** · 2021/04/22(木) 11:48:03.64

>>867
勿論普及してたからはあるだろうけど、そもそも変えるとかまた作り直すとかいう発想が無かったんじゃないかな。

ASCII制定→ISO 646制定→各国で変えられるのは10文字とか足りる訳無いだろ！→
ASCIIを拡張して8ビットフルに使おう→ISO 8859制定

とかそんな流れでしょ、増やして積んでけばいいと。当時のことは資料でしか知らないけどたぶん。

**デフォルトの名無しさん** · 2021/04/22(木) 20:15:21.29

メールで添付ファイルを送ろうとしたらbase64でエンコードされたせいで容量オーバーした
ネットワークのトラフィックを減らすためにもメールでバイナリデータをエンコード無しで送れるのが標準化すればいいのに

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

いち早く国際化はずのjavaもシステムのコードページでしか引数を受け取れない制約がある

**デフォルトの名無しさん** · 2021/04/23(金) 00:48:19.99

ほんまに？
Unicode対応していながら_wmain()とかGetCommandLineW()使ってないとは信じがたいが

**デフォルトの名無しさん** · 2021/04/23(金) 01:33:18.30

googleで検索したら以下ページすぐ見つかったけど、探すことさえしないタイプの人？

https://blogs.osdn.jp/2020/05/20/java-unicode.html

**デフォルトの名無しさん** · 2021/04/23(金) 03:25:56.54

Windows 専用ソフトでなくて、複数のOSに対応したソフトは当然そうなる。
特に Unix 系からの移植ならロケールをコードページに対応させるのは当たり前。
Windows独自の特殊APIで実装とか頭の悪いローカル変更は極力しない。

**デフォルトの名無しさん** · 2021/04/23(金) 03:27:43.26

というか単にC言語がASCII互換の文字コードしか
対応できないんだよな
そこは言語側の問題だと思う

**デフォルトの名無しさん** · 2021/04/23(金) 03:29:09.72

例えばJavaとかはUnicode前提で設計されてるから
当然Javaで作った複数のOS対応のソフトは
WindowsでもUnicodeが使える

これは殆どの言語に当てはまると思う
C#、JavaScript、Ruby、Python、などなど

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

そういやC言語はマルチバイト対応の機能は標準化されてないんだっけ？
流石にC++は標準化されてるよな？