文字コード総合スレ 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/

**デフォルトの名無しさん** · 2020/09/28(月) 00:29:11.65

2022も一枚岩じゃねーのにMSシフトだけ悪者かよw

**デフォルトの名無しさん** · 2020/09/28(月) 00:45:44.06

そういやEUC-JPも亜種が多かったね

**デフォルトの名無しさん** · 2020/09/28(月) 02:22:56.82

技術の話だからな、誰が邪悪で誰が正義とかはないぞ。
種類が多数あるから気をつけろ。あえて言えば非互換な変更は可能な限り避けろ。

あと別に NEC と IBM だけが独自拡張してたわではないぞ。
Apple や Fujitsu を始めとして他も各社独自拡張してた。
マイクロソフトはビジネス上の都合で普及してた NEC と IBM のもののみから取捨選択した。
そこそこ普及してたけどライバルだった Apple のもは無視した(互換にする理由が無かった)。

**デフォルトの名無しさん** · 2020/09/28(月) 03:00:06.80

code page 932 って元々MSじゃなくて IBM の規格だけどな。
IBM が作った OS/2 とうのがあってな。それ用の文字コード名だった。
MS は IBM が OS/2 を作るのに技術協力しててな、その後に Windows 作る時にその用語をそのまま使った。
MS が拡張する前の CP932 を IBM 932 と呼ぶ人がいるのはこれが理由。

**デフォルトの名無しさん** · 2020/09/28(月) 03:09:14.91

うちがIBM社から依頼されて制作したのが始まり。
当時は広く調査する手段が無く、偏りがある事は認める。

**デフォルトの名無しさん** · 2020/09/28(月) 03:09:23.25

>>231
そういえば IBM は律義なので、文字を追加して互換性のないやつは CP943 とか別の番号を割当てて名前を変えてたんだよな。
MS はその辺を参考に文字を追加したやつも CP932 と呼び続けたのは何でだろう。

**デフォルトの名無しさん** · 2020/09/28(月) 03:39:47.21

>>233
CP932はどちらもMSが作ったコードページでMSとしては互換性があるからじゃないの？
Unicodeにバージョンがあっても文字集合が違うように
オリジナルの CP932（=ShiftJIS ）があって、そこに文字集合を
拡張したいわば CP932 2.0 という扱いだから名前を変える必要がない

IBMのは別会社だから、別の名前にするのはそこまで不思議じゃないかな
むしろNECがなんでCP932を使ってるかのほうが気になるけど
NECもMS-DOSを使っていたからかな

最初のMS製のCP932は1982年に作られて、NECとIBMが独自拡張したのは1983年なんだね
アップルは1991年にそれまた独自で拡張してる
そして再構成されたCP932ができたのは1993年のようだ

**デフォルトの名無しさん** · 2020/09/28(月) 04:20:00.06

code page 番号での管理は IBM が汎用機時代からずっとやってきた名前で、
マイクロソフトは後から、その番号をそのまま採用したって聞いたけど、違うの？

**デフォルトの名無しさん** · 2020/09/28(月) 05:06:08.90

>>235
もともとMSとIBMは1990年代まで協力してOS開発をしてた
例えばIBM PC用のPC-DOSはMS-DOSをリネームしたもの

だから共通のコードページを使用するのは当たり前
1990年代以降にOS開発の協力をやめてからはそれぞれ独立して
コードページを管理してる

古くはIBMが使っていた用語のようだがCP932がなんかができた時期は共同開発なんだろう
MS等数社でShiftJISの仕様を作ってそれをOSに実装するときにCP932という管理番号が与えられた

https://en.wikipedia.org/wiki/Code_page

**デフォルトの名無しさん** · 2020/09/28(月) 09:14:02.90

共通のコードページを使うようになったのはいつから？
そこが曖昧なんだよな。
マイクロソフトは元々 CP932 とは呼んでなかったという意見があるみたいなんだが。

**デフォルトの名無しさん** · 2020/09/28(月) 09:33:14.92

>>234
NEC は厳密に言えば CP932 に文字を追加したわけではないからなあ。
NEC や Fujitsu がやったのは漢字ROMの空き領域に字形を追加した。
これをやると OS とか文字コードに関係無く使える漢字が増える。CP/M でも BASIC でも。

**デフォルトの名無しさん** · 2020/09/28(月) 09:42:09.44

ANSI先生、シフトジスがめんどくさいです...

>>227
HTMLでcharset=Shift_JISであっても実際はWindows-31Jだったりする。
巷の大概のブラウザはWindows-31Jにしかない文字があっても開ける。はしご高とか。

そうやってある意味グダグダになっていく（った）わけやね。でもしょうがないのかな。
厳密な挙動をしても「えーこのブラウザ文字化けするー」とか言われちゃうのがオチだし。

ま、HTMLはもうだいぶUTF-8になってきてるし、いっかw

**デフォルトの名無しさん** · 2020/09/28(月) 10:30:21.69

>>237
元々というのがいつの話か知らんが、chcp "MS-DOS 3.3" で検索したら
海外のMS-DOS3.3（1987年）にはCHCPコマンドがあったようだね

http://radioc.web.fc2.com/column/pc98bas/internal-version-of-msdos-33.html
https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/appendix-a/

ここからCP932が存在したということにはならないけど
今と同じコードページはMS-DOS当時使われていた
そこに別のものを使うとは思えないな

当時は日本ではほぼNECの独占状態で、日本専用なわけだから
コードページの切り替えはないしCHCPは存在しないから
日本では知られてなかっただけじゃないの？

**デフォルトの名無しさん** · 2020/09/28(月) 10:39:54.81

>>238
NEC の汎用機に文字が追加された。もちろんSJIS関係ない。
NEC の汎用機の端末として使えるようにするために PC9801 の漢字ROM は NEC追加文字が含まれて状態で発売された。
ちばみに IBM拡張漢字ROMは別売オプション。
PC9801 に MS-DOS を移植したら、あーら不思議、最初から使える文字が増えてた。
という順序だな。

**デフォルトの名無しさん** · 2020/09/28(月) 10:41:07.34

>>238
MS-DOS、漢字ROMの時代はOSが知っているのは文字コードだけで
そこで表示されるフォントはハードウェア搭載されてるものだったからね

ShiftJIS系は全て同じものとして扱うことしかできなかった
勝手に違う文字コードに化けさせるわけには行かないし

細かい文字コードを区別できるようになったのはフォントをOSで
処理するようになったWindowsから
だからそのときに改めて統一する必要がでてきた

**デフォルトの名無しさん** · 2020/09/28(月) 10:45:58.86

>>240
最初(1982年)からCP932だったという主張は撤回するのん？

**デフォルトの名無しさん** · 2020/09/28(月) 10:46:31.48

NEC独自の文字としては2バイト系半角文字がお気に入りだったな

数字やアルファベットが縦長で、全角半角混ぜても違和感ないんだよ
2バイトだけど文字幅は1バイトと同じでな

表示位置の調整の計算は、2バイトは1バイトの倍として
計算するだけでは駄目だったんだよ
1文字ずつ見ていって文字コードの範囲をみて計算する必要がある

ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様

**デフォルトの名無しさん** · 2020/09/28(月) 10:47:44.81

>>243
してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる
当時は日本で広まっていないだけ

**デフォルトの名無しさん** · 2020/09/28(月) 11:04:04.80

>>245
推測とかじゃなくて、その根拠が知りたいんだが。どこ情報？

**デフォルトの名無しさん** · 2020/09/28(月) 11:07:15.33

あ、別に否定してるわけじゃないよ。
世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。

**デフォルトの名無しさん** · 2020/09/28(月) 11:21:20.86

>>246
そんなに答えを求めてるなら「今となってはわからない」が正解じゃねｗ
少なくともCP932が使われていなかったという根拠はないからね

◆QZaw55cn4c · 2020/09/28(月) 19:55:51.42

もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと
で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題

私の一番すきな 98 は 98FA なので、98FA が正義でありたい

**デフォルトの名無しさん** · 2020/09/28(月) 20:15:42.82

□□□□□□□□□□□□□□□□□□□□□□□□□
□□■□■■□□□□■■□□■■■□□□■■■□□
□■■□□□□■□■□□□□□□□■□□□□□■□
□□■□■□□■□□□□□□□□□□□□□□□□□
□■□□■□□■□□□□□□□□□□□□□□□□□
□□□■■■□■□□■■□■□□□□□■□□□□□
□□□■■□□□■□□□□□■■■■□□■■■■□
□□□□□□□□□□□□□□□□□□□□□□□□□

**デフォルトの名無しさん** · 2020/09/28(月) 21:40:36.46

https://ja.wikipedia.org/wiki/Microsoftコードページ932

1982年(JIS X 0208-1983策定の前年)、JIS C 6226(JIS X 0208)を複雑にシフトさせた文字符号化方式としてShift_JISが誕生した。
この符号化方式(を利用した拡張符号化文字集合)は、マイクロソフトによりMS-DOSにおける標準日本語コードとして採用され、
「コードページ 932 (CP932)」という管理番号を与えられた。

しかし、マイクロソフトは、MS-DOSにおける唯一の日本語用コードページである「CP932」を、OEMメーカーの自由に任せていた。
そのため、NECのPC-9800シリーズ、IBMのPS/55 シリーズ、富士通のFMRシリーズなどは全て、MS-DOSを搭載し
文字符号化方式もShift_JISを採用しているコンピュータであるにもかかわらず、登録されている文字集合がバラバラだった。

**デフォルトの名無しさん** · 2020/09/28(月) 21:49:17.49

jawpをソースにするなよ

**デフォルトの名無しさん** · 2020/09/28(月) 22:15:52.03

当時としてはMS-DOSはコンピュータで動くOSの１つでしかないのに
マイクロソフトがコンピュータに搭載する文字集合を決めるなって話だろ

◆QZaw55cn4c · 2020/09/28(月) 22:32:50.70

>>253
そういう意見など、奴らは無視して漢字を 16ビットに無理やり押し込めにかかり、
あわてた中日韓が妥協させられてできあがったのが CJK 漢字統合
月日は流れ、結局 16 ビットの中に世界の文字を押し込めることなど出来ないと奴らが悟った後には、醜い CJK 漢字統合だけが残されたのであった…

**デフォルトの名無しさん** · 2020/09/28(月) 22:43:50.48

>>254
そんな話してないよ

**デフォルトの名無しさん** · 2020/09/28(月) 23:19:53.80

人はみな自分の話したいことのみを話す。

>>249
NECの漢字ROMに合わせると、旧JISになるのだが、それでよろしいか？

実はこれま語られた以外にも Shift JIS には、いわゆる旧JIS(JIS78) と新JIS(JIS83)の違いというヴァリアントがあるんだよな。
NECの漢字ROM は旧JIS準拠で、富士通の漢字ROMは新JIS準拠で、互換性が無かったりとか。
マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、
今の CP932 は新JIS準拠の字形になってるので、どこかの時点(多分 DOS/Vあたり)で、ちゃっかり入れ換えてるんだよな。

**デフォルトの名無しさん** · 2020/09/29(火) 01:44:43.55

なんとなーくNECの漢字ROMはShiftJISじゃないのか！？とかいい出す人がいいそうｗ

PC9801シリーズは漢字ROMが搭載されていて、
テキストVRAMに文字コードを書き込むだけで画面に漢字が表示される

そのときに使われる文字コードはシフトJISではなくJISコード

http://software.aufheben.info/oohpc/textvram.html
> JISコードで書き込む
> 通常MS-DOS上でプログラミングをしているのであれば、文字コードは
> シフトJISコードを使っていることでしょう。ところが、テキストV-RAMには
> JISコードで書き込まなければならないので、別途変換ルーチンが必要です。

MS-DOSはシフトJISを使っているが、文字を表示する場合はこのような簡単なアルゴリズムで変換できる
MS-DOSで使われてる文字コードはCP932といううが、実際にはシフトJIS→JISコードの変換アルゴリズムがあるだけ
だからCP932の空き領域だってJISコードにマッピングされるし、文字を表示は漢字ROMの仕事

もしPC9801シリーズにCP932を遵守しろというのであれば、
漢字ROM（JISコード）にCP932以外を乗せるな！というしかない
だがPC9801は別にMS-DOS専用のコンピュータというわけではない

ハードウェアの仕様の話なのになぜマイクロソフトに命令されなければならないのだ？という話になる

**デフォルトの名無しさん** · 2020/09/29(火) 01:52:41.35

>>256
> マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、

マイクロソフトがやったのは実質シフトJISからJISコードへの変換でしかないので
例えば古いバージョンのMS-DOSのバージョンで古い一太郎（笑）を使っていて
それを収録文字数が増えた新しいハードウェアに買い換えるとMS-DOSも一太郎も同じ古いままで
新しい文字に対応できてしまうんだよね。対応する文字は漢字ROMで決まることだから

つまりMS-DOSはCP932を想定していたとしても
実際に対応する文字はMS-DOSで決めることができない

マイクロソフトが使ってる文字コードをShiftJISと呼ぼうがCP932と呼ぼうが
NECや富士通なんかが勝手に文字を追加してしまうわけ

**デフォルトの名無しさん** · 2020/09/29(火) 03:15:45.97

そもそも IBM も NEC も富士通も、パソコンの主な使用目的の一つは、自社の大型コンピューターの端末として使うことだったからな。
だから自社の汎用機に合わせて文字を追加したんであって、MS-DOS とか眼中にはない。
追加した漢字が MS-DOS からもたまたま使えただけ。
パソコン専用の Apple の文字追加はまた別の理由だが。

**デフォルトの名無しさん** · 2020/09/29(火) 06:39:24.27

東風フォントの人元気かな

**デフォルトの名無しさん** · 2020/09/29(火) 08:26:34.17

>>252
だったらWikipedia以外のまともなソースとやらを出してくれよ
どうせ出せないんだろ？

**デフォルトの名無しさん** · 2020/09/29(火) 11:27:29.43

今となっては別に昔の名前なんてどうでもだが。
アスキー・マイクロソフトが出した最初に Shift JIS に対応した MS-DOS 2.01 では MIcrosoft Kanji Code が正式名称だった。
MS-DOS のソースコードの中でSJISの処理をする部分は KANJI という表記だった。

**デフォルトの名無しさん** · 2020/09/29(火) 13:51:59.38

https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/JIS_and_Shift-JIS_variants.svg/2880px-JIS_and_Shift-JIS_variants.svg.png

**デフォルトの名無しさん** · 2020/09/29(火) 14:17:45.42

>>263
図をまとめる下手すぎ
わざとわかりづらくしてるようにしか見えない

**デフォルトの名無しさん** · 2020/09/29(火) 17:25:53.58

白黒の限界を感じる。後、矢印の向きが派生ではなく包含関係だったりして、
通常とは逆なので知らない人が見ても理解するのは難しいかも。努力は認める。
>>264
文句あったらお前が書き直せ(お約束)

**デフォルトの名無しさん** · 2020/09/29(火) 17:37:33.69

>>264
時系列とかメーカーで横に並べるべきだろうね

**デフォルトの名無しさん** · 2020/09/29(火) 17:39:10.32

EUC-JPとShiftJIS系とUnicode系でも分けるべきだし
包含関係でまとめられるのはまとめるべきだろう

**デフォルトの名無しさん** · 2020/09/29(火) 17:51:57.33

ぱっと見てみたけど、包含関係は、かなり正確だな。
今までここに上げられた、いい加減な図と比べるとかなりマシ。
NEC の CP932 と、IBM の CP932 を混ぜて Windows CP932 ができたなどという中途半端な説明が
間違いということが、わかるように書かかれている。

**デフォルトの名無しさん** · 2020/09/29(火) 17:55:22.30

>>268
図の真ん中、Shift-JIS Windows 932は
Shift-JIS with NEC r13 and 89-92 and IBM DBCS からできたって書いてありますが？

**デフォルトの名無しさん** · 2020/09/29(火) 18:03:23.01

そして、その「Shift-JIS with NEC r13 and 89-92 and IBM DBCS」は
「Shift-JIS with NEC r13 and 89-92」＋「Shift-JIS with IBM DBCS」のことだって書いてありますよね？

**デフォルトの名無しさん** · 2020/09/29(火) 18:17:32.15

左からも矢印が延びてるの見えない？

**デフォルトの名無しさん** · 2020/09/29(火) 18:20:25.83

左からの矢印？
そりゃいわゆるShiftJISと呼ばれたものに「NECの追加文字」と「IBMの追加文字」を加えたって言ってるんだから
左のもの（基本的な文字セット）もあるに決まってんだろｗ

**デフォルトの名無しさん** · 2020/09/29(火) 18:34:13.19

都合の悪いものは見えない目をしてる奴がいるようなので、
その図で表示されている文字集合の関係を表にしてみた。
Windows CP932 だけ他と比べて明らかに違うところあるだろ。
逆に IBM の CP932 にあって Windows 932 にないのとかも

A J K IBMex 漢 IBM漢 NEC特 NEC漢
Invaliant × ○ ○ × ○ × × ×
with NEC r13,80-92 × ○ ○ × ○ × ○ ○
with IBM DBCS × ○ ○ ○ ○ ○ × ×
IBM CP 932 × ○ ○ ○ ○ ○ × ×
with IBM DBCS & NEC × ○ ○ × ○ ○ ○ ○
Windows CP 932 ○ × ○ × ○ ○ ○ ○
IBM CP 943 × ○ ○ ○ ○ ○ ○ ○

A: ASCII
J: JIS X 0201 Romaji (JIS半角英数字)
K: JIS X 0201 Kana (JIS半角カナ)
漢: JIS X 0208 (JIS漢字)
IBMex: IBM katakana extesion (IBM半角拡張)
IBM漢: IBM DBCS extension (IBM漢字拡張)
NEC特: NEC row 13 (NEC特殊文字)
NEC漢: NEC row 89-92 (NEC漢字 + IBM選定NEC漢字)

**デフォルトの名無しさん** · 2020/09/29(火) 18:35:11.83

表ズレた。すまん。

**デフォルトの名無しさん** · 2020/09/29(火) 18:39:08.12

>>215のリンク先に書いてある

> マイクロソフト標準キャラクタセット (Windows-31J、MS932) は、
> マイクロソフト社が使用している日本語用文字コードで、シフトJISの一種です。
> [37]標準的なシフトJISに加え、NEC や IBM の拡張に由来するいくつかの追加文字を収録しています。

NEC や IBM の拡張に由来する「いくつかの」追加文字を収録していますという話を繰り返しただけか
リンク先読んでねーなこいつｗ

**デフォルトの名無しさん** · 2020/09/29(火) 18:41:53.46

再挑戦。
Ａ　Ｊ　Ｋ　Ｘ　漢　Ｉ漢　Ｎ特　Ｎ漢
×　○　○　×　○　×　　×　　×　　Invaliant
×　○　○　×　○　×　　○　　○　　with NEC r13,80-92
×　○　○　×　○　○　　×　　×　　with IBM DBCS
×　○　○　○　○　○　　×　　×　　IBM CP 932　
×　○　○　×　○　○　　○　　○　　with IBM DBCS & NEC
○　×　○　×　○　○　　○　　○　　Windows 932
×　○　○　○　○　○　　○　　○　　IBM 943

Ａ: ASCII
Ｊ: JIS X 0201 Romaji (JIS半角英数字)
Ｋ: JIS X 0201 Kana (JIS半角カナ)
Ｘ: IBM katakana extesion (IBM半角拡張)
漢: JIS X 0208 (JIS漢字)
Ｉ漢: IBM DBCS extension (IBM漢字拡張)
Ｎ特: NEC row 13 (NEC特殊文字)
Ｎ漢: NEC row 89-92 (NEC漢字 + IBM選定NEC漢字)

**デフォルトの名無しさん** · 2020/09/29(火) 19:33:37.91

ASCII 互換じゃないから Linux では SJIS は使えないｷﾘ
とかほざいてたのいたけど、実際には ASCII 互換じゃないと困るのは Windows の方だったという落ち。
樂しい♪

**デフォルトの名無しさん** · 2020/09/29(火) 19:49:07.20

>>277
仕方ないよな。UNIX 系のパス区切りは / なので ISO-646 系ならどれでも共通だけど
Windows はパス区切り \ なので国ごとに違っていて、Unicode に変換した時に困る。

**デフォルトの名無しさん** · 2020/09/29(火) 20:13:35.05

>>278
ん？
Windowsのパス区切りは、あくまでバックスラッシュで、
それぞれの言語環境で別の文字に見えてるだけでしょ？
割り当てられた文字コード番号自体は同じじゃないのか？

◆QZaw55cn4c · 2020/09/29(火) 20:34:00.58

>>279
win32api から見る限り、パス区切りは \ であっても / であっても使えます

**デフォルトの名無しさん** · 2020/09/29(火) 20:51:03.40

>>277
アプリケーション側の問題だからね
OSだけ対応していても

**デフォルトの名無しさん** · 2020/09/29(火) 20:55:47.86

mohtaの昔から文字コードの話はなんでこう揉めるんだろ

**デフォルトの名無しさん** · 2020/09/29(火) 22:01:45.11

https://docs.microsoft.com/ja-jp/previous-versions/visualstudio/visual-studio-2008/77859s1t(v=vs.90)

UNIX ではパスデリミタとしてスラッシュ (/) しか使用できませんが、Win32 オペレーティングシステムは円記号 (\) とスラッシュ (/) の両方を使用できます。

**デフォルトの名無しさん** · 2020/09/29(火) 23:21:22.59

バックスラッシュをファイル名に使えるからデリミタに使う意味がない

**デフォルトの名無しさん** · 2020/09/30(水) 00:15:57.00

それどころか多分どの制御コードやDEL、極めつけは
改行コードまでLinuxやUNIXはファイルめに使えるんだ
すごいだろー

findでどうやって改行コードが入ったファイル名を扱うのか知らんがｗ

**デフォルトの名無しさん** · 2020/09/30(水) 00:17:36.68

バックスラッシュをファイル名に使うと面白いことができて
echoでそのファイル名を表示すると、色を付けたりできるんだｗ

**デフォルトの名無しさん** · 2020/09/30(水) 00:18:07.91

間違ったｗ色をつけるのはエスケープコードだったｗ

**デフォルトの名無しさん** · 2020/09/30(水) 00:24:04.53

🐏スケープゴートに空目したわ

**デフォルトの名無しさん** · 2020/09/30(水) 00:24:37.97

>>285
たいていのシェル環境だとデフォルトは Ctrl-V の後に改行を入れる。カスタマイズ化。

**デフォルトの名無しさん** · 2020/09/30(水) 00:25:31.56

訂正。🐐ゴートは羊じゃなくて山羊

**デフォルトの名無しさん** · 2020/09/30(水) 00:27:29.17

入力でなくて出力の話なら -0 オプションで、改行区切りから Null 文字区切りに変更できる。

**デフォルトの名無しさん** · 2020/09/30(水) 01:46:35.60

ぬるぽ

**デフォルトの名無しさん** · 2020/09/30(水) 02:06:47.48

>>291
それはPOSIX準拠じゃないんだよなｗ
UNIXは改行が使えるから、UNIXで苦労するｗ

**デフォルトの名無しさん** · 2020/09/30(水) 02:08:30.20

ファイル名にコロンが使えるから
PATHのコロン区切りで問題が出るというねｗ
制御文字と一部の記号は使えないようにするべきだっただろうな

**デフォルトの名無しさん** · 2020/09/30(水) 02:13:17.35

アホか？使いたくない文字は使わなきゃ良いだけなんやで。
わざと変な文字入れて、変な文字入れられる方が悪いとか、小波。

**デフォルトの名無しさん** · 2020/09/30(水) 02:17:17.38

>>295
論点ずれてるぞｗ
いろんな文字が使えちゃうから、それが原因でバグになるということだ

ファイル名に改行を入れられるってことを知らないで作っていたら
「bin<改行>lib<改行>etc」みたいなフォルダを消そうとして被害にあったり
「a*?」みたいなファイル名でaで始まるファイルが全部消えたりｗｗｗとか
実際に起きてるからな

**デフォルトの名無しさん** · 2020/09/30(水) 02:26:40.95

>>292
ｶﾞｯ

**デフォルトの名無しさん** · 2020/09/30(水) 02:26:53.11

制限したいやつが制限すればええんやで。Linux にはその仕組みがある。
普通の人はそんなことせんでも変は文字入れないから、困ってないだけ。

**デフォルトの名無しさん** · 2020/09/30(水) 02:49:29.19

入れたくていれるんじゃなくて
端末に文字をペーストしたら変な文字を実行しちゃったりして
その結果変な名前のファイルができたりするんだよ

*とか?とか<とか>とか!とかシェルのメタ文字は
ファイルに使えないようにするべきだった
互換性があるから手遅れなんだろうけど

普通の人は変な文字入れないというのなら
なおのこと入れられないようにしてよかったということになる

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

だから、そんな間抜けなユーザー抱えてんなら管理者が制限設定入れとけや。
普通、変なファイルできても ls すれば、すぐ気付くし、シェルの補完とかも対応してる。
やってみもせずに妄想垂れ流す暇あったら触ってこい。
それでも駄目だと思うんなら、システム制限掛けとけ。

**デフォルトの名無しさん** · 2020/09/30(水) 03:11:45.53

シェルの補完にバグがないとどうしているんだ？ｗ
メタ文字とかは勝手にエスケープが入ったりする。だがそれが正しいとどうしていえる？
どうエスケープすればいいかを知らなければ、今からエンター押しても大丈夫か？なんてわからんはずだが
だから俺はGUIから消すようにしてるよ。GUIならシェルのワイルドカード展開なんて使えないからね

**デフォルトの名無しさん** · 2020/09/30(水) 03:15:35.92

お前に Linux は早過ぎた。
バグが心配ならソースでも眺めとけ。ここプログラム板やし。

**デフォルトの名無しさん** · 2020/09/30(水) 03:23:32.50

初心者「バグがあるかもしれない」
プログラマ「バグなんてあるわけない」

こういう考えかｗ

**デフォルトの名無しさん** · 2020/09/30(水) 03:39:20.46

初心者：いきなりバグとか心配しない。気になったたらドキュメントとか、ネット調べたり、試行錯誤して学習する。
プログラマ：いきなりバグとか心配しない。気になったらソースコード確認して、万一バグを見つけたら自分で直す。
お前：根拠無くバグが心配になり、5ch でOS の仕様にケチをつける。

**デフォルトの名無しさん** · 2020/09/30(水) 03:41:07.93

>>304
お前が気になったことの例を１つでも上げてみてよｗ

**デフォルトの名無しさん** · 2020/09/30(水) 03:51:15.98

なんてレスしてるうちにバグ報告したとある有名プロジェクトから
修正したってコメントが有ったわｗ

**デフォルトの名無しさん** · 2020/09/30(水) 10:44:11.67

MS「CON\CONなんてパスを指定する奴なんているはずないな」

**デフォルトの名無しさん** · 2020/09/30(水) 11:03:16.10

>>307
バグじゃなくて仕様だよ。予約されてるから。

**デフォルトの名無しさん** · 2020/09/30(水) 11:04:41.69

制約事項として明記された不具合は仕様と呼んでいい。

**デフォルトの名無しさん** · 2020/10/02(金) 03:35:07.39

>>99
それなら普遍的に使えるスタイルとの結合文字にすりゃいい話
だけどそうしないのはそもそもスタイルと文字は分ける設計だから
スタイルはCSSなり他の技術がある

**デフォルトの名無しさん** · 2020/10/02(金) 03:36:07.77

肌の色とか差別がなかったところに肌の色って概念を導入した結果結局偏りが生まれてるクソ仕様

**デフォルトの名無しさん** · 2020/10/02(金) 03:47:03.40

>>311
それはもう解決済みの問題です

**デフォルトの名無しさん** · 2020/10/02(金) 11:31:57.29

こんにちは、初めまして。

今、個人的に amazon kindle端末用の電子書籍データを作るにあたって
仕様として JIS X 0213:2004 を保証すると書いてあるのでこの文字コードのユニコードのセットをまとめて
いわゆる JIS X 0213:2004 文字チェッカーのようなものを作っています。
Webページベースでユニコードのテキストを入力して、
使用してる文字が Kindle端末オーケーかどうかをチェックするプログラムです。
JavaScript(u16)用と PHP(u8)用で二種類のチェックプログラムを作ってます。

それで資料を集めて検証しているところなのですが、ちょっと判断に迷うコードがあったので、
他に聞ける場所も無いということで、ちょっとここで質問してみることにしました。

以下のコードなのですが、方や u16 で２文字(U+025B U+0300)、方や１文字(U+1F72) になってます。

https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
(A) ɛ̀ 1-11-48 0x866f U+025B U+0300 グレーブアクセント付きEPSILON小文字
(A) ɛ́ 1-11-49 0x8670 U+025B U+0301 アキュートアクセント付きEPSILON小文字

https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/u1f00.html#u1f72
(B) U+1F72 ὲ グレーブアクセント付きEPSILON小文字
(B) U+1F73 έ アキュートアクセント付きEPSILON小文字

この文字だけに限っての判断としますが、
どちらか一方が出た場合にどちらかに変換して正規化するとした場合、
正規化後は (A) と (B) のどちらが良いと思いますか？

気が向いたらレスを付けてくれたら嬉しいです、参考にしますので。

ちなみに、Windows10等でキーボード入力される全角チルダ(U+FF5E,'～') は
JIS x0213:2004 コード規格の波線(U+301C,'〜') に正規化することにしています。
(その他、似たような文字はなるべく一種類に正規化出来ればと考えています)

**デフォルトの名無しさん** · 2020/10/02(金) 11:37:56.63

グレープってなんだって思ったらグラーブのことか

**デフォルトの名無しさん** · 2020/10/02(金) 11:59:54.40

Ruby に、そのエンコードは無いの？

**デフォルトの名無しさん** · 2020/10/02(金) 12:00:25.80

どうぞ。

https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/u1f00.html#u1f72
1F72 ὲ GREEK SMALL LETTER EPSILON WITH VARIA ≡03B5(ε) 0300(◌̀) グレーブアクセント付きEPSILON小文字 2B50
1F73 έ GREEK SMALL LETTER EPSILON WITH OXIA ≡03AD(έ) アキュートアクセント付きEPSILON小文字

https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
` 1-1-14 0x814d U+0060 アクサングラーブ/グレーブアクセントグレイヴ・アクセント

https://ja.wikipedia.org/wiki/グレイヴ・アクセント
JIS X 0213の名称は、「アクサングラーブ, グレーブアクセント」
The grave accent ( ` ) (/ɡreɪv/ or /ɡrɑːv/)

**デフォルトの名無しさん** · 2020/10/02(金) 14:38:35.67

なんとなく備忘録

https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
\ 1-1-32 (JIS)2140 (SJIS)0x815f U+005c 逆斜線バックスラッシュ
\ 1-1-79 (JIS)216f (SJIS)0x818f U+00a5 円記号円記号

日本語環境だとどちらも円マークだけど、JISx0208 , JISx0213 だと U+00a5 に正規化すべきなのか・・・、
一応 JIS x0213:2004 規格だと、U+005c はバックスラッシュで表示されるらしいし？
自分とこで作る電子書籍は問答無用で全角円マークにするから検討すべき問題でもないのだけれど、
とりあえず日本語でしか使わないので U+005c → U+00a5 正規化コードを突っ込んどけばいいか。

というか、いい加減にカオスな状況が終わってると思ってチマチマ始めたというのに、
なんか微妙なところで微妙に決まってないというか、
mb_convert_encoding() で Unicode から JIS コードにしたいのに、
エラーも出さずにシラっと Unicode で返すのは辞めてほしかった・・・、

ちなみにこんなもので悩もうとか思ったのは、
kindle用電子書籍を作るにあたって第3水準や第4水準のつもりで使った漢字を
既存のWebサービスやツール類で適性かどうかをチェック出来るものが無かったからなんですね。
まぁ、既存のツールがあったとしても他人が作ったそのツールの仕様を理解するのも面倒だって理由もありますが。

ちょっと気づいたんだけど、U+00a5 の方も普通に Windows のファイル名として使えるのね・・・、
見た目で違いを判別できないとか、まじに勘弁してほしい。

あと、他のサイトだけど、しらっと SJIS で６バイトのコードを表示するのも辞めてほしい・・・、

**デフォルトの名無しさん** · 2020/10/02(金) 15:25:55.64

日本の PC の内臓フォントは JIS X 0201 だったので、SJIS の 0x5C は円記号ということで運用されていたのだけど
Windows 3.1 で Unicode 対応を入れる時に ASCII 互換じゃないとうまくいかないことに気付いて、
CP932 の 0x5C を「見かけは円記号に見えるけど、実際には逆射線ということにした。円記号に見えるのはフォントせいで心の目で見ると逆射線」ということにした。
そのせいで Windows の一部日本語フォントを使った場合のみ 0x5C と 0xA5 の両方が円記号で表示される。
解決法: (1)別のフォントに変える。(2)Windows を捨てる。

**デフォルトの名無しさん** · 2020/10/02(金) 15:54:09.42

Unicode 的にはどっちでも良いのだけど JIS X 0213 的には 1-11-48,49 は 1F72,1F73 との対応を示しているので、そっちにしておくのが無難かな。
一文字にしておけば、結合文字に未対応の環境でも変にならずにすむし。

**デフォルトの名無しさん** · 2020/10/02(金) 16:07:25.61

>>318
消火器と消化器は間違えんなよ。小火器も使う時あるからな。

**デフォルトの名無しさん** · 2020/10/02(金) 17:58:09.59

おう逆射線と逆斜線の変換ミスな。気付いてなかったわ。すまん。

**デフォルトの名無しさん** · 2020/10/02(金) 18:49:02.52

>>318
Windowsだけでなく、国産Android端末もそういうフォント入れてる。
Android標準のnotoなら正しくバックスラッシュ出るんだけど、SONY端末には入ってないんだな。

**デフォルトの名無しさん** · 2020/10/02(金) 18:54:47.21

>>319
サンクス。
U+1F70 , U+1F71 , U+1F72 , U+1F73 は一文字の方を正規化先にして作ってみることにします。

**デフォルトの名無しさん** · 2020/10/02(金) 20:47:22.49

>>318
Shift_JISがJIS X 0201 Romanだから困るからCP932で超解釈したのはC言語の問題じゃなかったっけ?

Shift_JISで厳密に次のコードを解釈すると
#include <stdio.h>

int main(int argc, char argv[])
{
int a = 0x0077ffaa;
printf("%08x %08x\n", a, ~a);
return 0;
}
バックスラッシュ＼ｎとチルダ～ではなく円記号￥ｎとオーバーライン￣だから、改行とビット反転にはならない

正しくはトライグラフを使って
#include <stdio.h>

int main(int argc, char argv[])
{
int a = 0x0077ffaa;
printf("%08x %08x??/n", a, ??-a);
return 0;
}
としないといけない

だけど誰もトライグラフなんて使っていないから、CP932は0x5cはグリフが￥なバックスラッシュという超解釈でごまかした
CP932では0x7eの意味はチルダでグリフも～だからそっちはそのままでいい

チルダ関係もカオスだよね
『～』と『～』別な文字だけど区別できる見た目で表示されているほうがむしろおかしいんだっけ?

**デフォルトの名無しさん** · 2020/10/02(金) 21:00:45.39

PDF に謎の漢字が含まれるとき
https://gist.github.com/xl1/940d653451fd96a06618a6df08d5df84

**デフォルトの名無しさん** · 2020/10/02(金) 21:17:20.27

ピントはずれ。
シフトJISできる前からJIS C 6220のソースをコンパイラに食わせてた。
コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。

シフトJISとコンパイラで問題がでるのは文字列リテラル中のダメ字。

**デフォルトの名無しさん** · 2020/10/02(金) 21:57:12.83

>>326
> コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。
正しく国際化されているコンパイラでは問題を起こす

実際2000年前後の国際化対応gccでShift_JISで書かれたコードで問題が起きたことがある
(ダメ字を問題なく処理できるのに￥ｎが改行と解釈されない)

日本語環境ではみんな雑に捉えて￥と＼を区別していなかったのは事実だけど、トライグラフが
ANSI Cで導入された以降Shift_JISで書かれたコードは正しく解釈すると規格に反する状態であった

実際にトライグラフをまともに使っていたのはデンマークだっけ?