文字コード総合スレ 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/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で書かれたコードは正しく解釈すると規格に反する状態であった

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

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

厳密にいうと C言語のソースは基本文字集合と呼ばれる 1バイト文字を含まなければならない。それには \ のみで￥は存在していない。
JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と￥を置き換えることになっている。
1バイト文字の解釈は必ず基本文字集合と同じでなければならない。
多バイト文字やシフト状態を持つ文字でナル以外の文字に 0x00 のバイトが来るのは禁止。
シフト状態を持つ場合には初期シフト状態に基本文字集合を持たなければならない。
上記を満たせば多バイト文字の解釈は実装依存。

**デフォルトの名無しさん** · 2020/10/02(金) 22:13:24.20

>>327
実際にgccのShift_JISとCP932ハマった人の例見つけた
ttps://blogger.tempus.org/2008/03/gcc-shiftjis.html

**デフォルトの名無しさん** · 2020/10/03(土) 00:32:32.33

文字コードを意識せずにプログラミングが出来るようになる革命はまだですか？

**デフォルトの名無しさん** · 2020/10/03(土) 00:59:47.45

革命とは過去の遺物を捨て去ることだよ。

**デフォルトの名無しさん** · 2020/10/03(土) 09:47:26.20

>>328
> JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と￥を置き換えることになっている。
ANSI CやISO 9899にそんな規定はない
JISX3010で参考として追記された箇所であってローカル規格

そもそも￥を＼の代わりに使っていいなら何のためにトライグラフを国際規格に入れたの?
￥を＼と解釈するJISX3010は国際規格ISO 646に反しCP932と同じ超解釈の類

gccの振る舞いが国際規格に準拠する正しい動作

**デフォルトの名無しさん** · 2020/10/03(土) 10:32:33.14

ideone.com とかは
スマホから試すときとPCから試すときで
\と＼の扱いが違って動きが可笑しくなることがある
unicode になって区別が明確になったことによる弊害のひとつ

**デフォルトの名無しさん** · 2020/10/03(土) 14:19:07.86

>>322
だから JIS の C言語の規格で、なおかつ入力に JIS X 0201 を使う時、限定と書いてるじゃん。
コンパイラがロカール規格に対応していたら使って良いんだよ。
gcc がローカル規格に対応する義務はないが、ちなみに gcc には LANG=C-SJIS という設定があってな。

**デフォルトの名無しさん** · 2020/10/03(土) 14:23:10.98

アンカミス。 322 → 332

**デフォルトの名無しさん** · 2020/10/03(土) 14:44:31.16

もちつけ

**デフォルトの名無しさん** · 2020/10/05(月) 00:37:11.64

>>323
どうなんだろうね。
確かにユニコード的には例えばNFDにしたときのベースの文字が正解かと。
一方 U+025X はIPAのブロックで、要は発音記号... ということは、文脈的に発音記号
として使われているならこっちだったりするのかも?

**デフォルトの名無しさん** · 2020/10/08(木) 10:57:17.71

Rubyをやってるんだけど、分からないところあるから教えてほしいです…
クラスメソッド、インスタンスメソッド、インスタンス変数あたりの意味がさっぱりで…

**デフォルトの名無しさん** · 2020/10/08(木) 11:08:48.28

説明読んでも意味が判らない間は無理に使う必要は無い
君にはまだ早いってこと

**デフォルトの名無しさん** · 2020/10/08(木) 11:25:58.08

>>338
Ruby 初心者スレッド Part 66
https://mevius.5ch.net/test/read.cgi/tech/1578068134/

**デフォルトの名無しさん** · 2020/10/08(木) 11:34:16.59

個人的に普段は ruby は使わないんだけど、文字コードの実装は perl や python や java に比べると ruby は筋が良いんだよな。(個人の感想です)

**デフォルトの名無しさん** · 2020/10/08(木) 21:30:15.81

>>341
python使いの私に文字コード関連でのrubyの利点についてぜひご教示ください。
rubyはさわったこと無いです。

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

ドキュメントを見ると結構マイナー(?)なエンコーディングもあるっぽいね。
ケータイ各社の絵文字入りSJISとかもあるんだ。
https://en.wikibooks.org/wiki/Ruby_Programming/Encoding

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

>>342
Python は内部格納文字コードに unicode を固定で使用していて、unicode に変換できない文字は使えないし、
unicode に変換した場合に unify などで消える情報は保持できないけど、
ruby は特定の文字コードを仮定した内部コードを持たないため、programing や library の実装でどうにでもなる。
初心者には Python の実装がわかりやすいけど、文字コードそのものをいじりたいレベルになると嵌ることがある。
概要は ruby m17n とかで、検索してい関連しそうな記事を読んで見ると良いかと。

**デフォルトの名無しさん** · 2020/10/09(金) 11:44:47.75

うそはいかんよ
python は binary も自由に扱える

**デフォルトの名無しさん** · 2020/10/09(金) 12:08:49.92

>>345
バイナリは文字じゃないので文字列の長さすらわからない
低機能なデータ形式でしかない

**デフォルトの名無しさん** · 2020/10/09(金) 12:37:20.08

ruby は文字じゃないものの文字列長をどうやって計算してるのですか？

**デフォルトの名無しさん** · 2020/10/09(金) 12:38:41.36

>>347
文字じゃないものの文字列長なんて計算できるわけ無いでしょ（笑）
だからいろんな文字コードを文字として認識できるようになってる
それに対しPythonはバイナリだから文字列の長さが計算できない（大爆笑）

**デフォルトの名無しさん** · 2020/10/09(金) 12:44:19.84

うそはいかんよ
馬鹿丸出しだから煽りは止めた方が良い

**342** · 2020/10/09(金) 12:45:15.41

>>344
ありがとうございます。
個々の文字列オブジェクトにエンコーディング情報を持たせてるので
文字コードを変換せずにm17nを実現できてる感じですね。

**デフォルトの名無しさん** · 2020/10/09(金) 20:40:06.43

漢字のようで漢字でないUnicodeの「康熙部首」と「CJK部首補助」
https://techracho.bpsinc.jp/hachi8833/2020_10_07/95257

**デフォルトの名無しさん** · 2020/10/10(土) 09:48:22.75

Unicode 3.0って1999年だろうに

**デフォルトの名無しさん** · 2020/10/10(土) 22:38:12.17

nuby からの流れで... nkf　って今でもメンテされてるようで。
ネットニュースから shar で入手したのはいつの日か。

**デフォルトの名無しさん** · 2020/10/10(土) 23:59:49.31

Unicodeの文字の情報を見たいと思ったら
どれを参照すればいいの？

**デフォルトの名無しさん** · 2020/10/11(日) 01:36:12.47

情報って？

**デフォルトの名無しさん** · 2020/10/11(日) 01:53:31.67

Aという文字の小文字はaであるとか

**デフォルトの名無しさん** · 2020/10/11(日) 02:42:43.61

Unicodeのcode chartにはいちいち文字の説明が書いてあるがそれ以上の説明が欲しいのか否か？

https://unicode.org/charts/

**デフォルトの名無しさん** · 2020/10/11(日) 06:59:02.20

>>357
それらの情報を全て文字ごとに知りたいんだよ

**デフォルトの名無しさん** · 2020/10/11(日) 07:21:36.62

>>358
"Find chart by hex code:" ってとこにコードポイントを入れてみようw

**デフォルトの名無しさん** · 2020/10/11(日) 07:33:27.40

>>359
情報が全く足りません

**デフォルトの名無しさん** · 2020/10/11(日) 07:34:05.33

Aは大文字であり、対応する小文字はaである
という情報はどこに書かれているのでしょうか？

**デフォルトの名無しさん** · 2020/10/11(日) 08:36:01.64

https://unicode.org/charts/PDF/U0000.pdf
これの
LATIN CAPITAL LETTER A
LATIN SMALL LETTER A
区別じゃ足りないかい？