X
文字コード総合スレ Part12
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2018/12/17(月) 16:48:24.47ID:Pfqpaohb
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/
0244デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:46:31.48ID:IvlPnhNT
NEC独自の文字としては2バイト系半角文字がお気に入りだったな

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

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

ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様
0245デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:47:44.81ID:IvlPnhNT
>>243
してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる
当時は日本で広まっていないだけ
0247デフォルトの名無しさん
垢版 |
2020/09/28(月) 11:07:15.33ID:cf3OGOhX
あ、別に否定してるわけじゃないよ。
世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。
0248デフォルトの名無しさん
垢版 |
2020/09/28(月) 11:21:20.86ID:IvlPnhNT
>>246
そんなに答えを求めてるなら「今となってはわからない」が正解じゃねｗ
少なくともCP932が使われていなかったという根拠はないからね
0249◆QZaw55cn4c
垢版 |
2020/09/28(月) 19:55:51.42ID:iFBbxDDj
もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと
で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題

私の一番すきな 98 は 98FA なので、98FA が正義でありたい
0250デフォルトの名無しさん
垢版 |
2020/09/28(月) 20:15:42.82ID:LpDzonCU
□□□□□□□□□□□□□□□□□□□□□□□□□
□□■□■■□□□□■■□□■■■□□□■■■□□
□■■□□□□■□■□□□□□□□■□□□□□■□
□□■□■□□■□□□□□□□□□□□□□□□□□
□■□□■□□■□□□□□□□□□□□□□□□□□
□□□■■■□■□□■■□■□□□□□■□□□□□
□□□■■□□□■□□□□□■■■■□□■■■■□
□□□□□□□□□□□□□□□□□□□□□□□□□
0251デフォルトの名無しさん
垢版 |
2020/09/28(月) 21:40:36.46ID:o1iMmVBZ
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を採用しているコンピュータであるにもかかわらず、登録されている文字集合がバラバラだった。
0253デフォルトの名無しさん
垢版 |
2020/09/28(月) 22:15:52.03ID:F7s1Ev+m
当時としてはMS-DOSはコンピュータで動くOSの１つでしかないのに
マイクロソフトがコンピュータに搭載する文字集合を決めるなって話だろ
0254◆QZaw55cn4c
垢版 |
2020/09/28(月) 22:32:50.70ID:iFBbxDDj
>>253
そういう意見など、奴らは無視して漢字を 16ビットに無理やり押し込めにかかり、
あわてた中日韓が妥協させられてできあがったのが CJK 漢字統合
月日は流れ、結局 16 ビットの中に世界の文字を押し込めることなど出来ないと奴らが悟った後には、醜い CJK 漢字統合だけが残されたのであった…
0256デフォルトの名無しさん
垢版 |
2020/09/28(月) 23:19:53.80ID:LFNRA5Wr
人はみな自分の話したいことのみを話す。

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

実はこれま語られた以外にも Shift JIS には、いわゆる旧JIS(JIS78) と新JIS(JIS83)の違いというヴァリアントがあるんだよな。
NECの漢字ROM は旧JIS準拠で、富士通の漢字ROMは新JIS準拠で、互換性が無かったりとか。
マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、
今の CP932 は新JIS準拠の字形になってるので、どこかの時点(多分 DOS/Vあたり)で、ちゃっかり入れ換えてるんだよな。
0257デフォルトの名無しさん
垢版 |
2020/09/29(火) 01:44:43.55ID:xt+EJgQq
なんとなーく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専用のコンピュータというわけではない

ハードウェアの仕様の話なのになぜマイクロソフトに命令されなければならないのだ？という話になる
0258デフォルトの名無しさん
垢版 |
2020/09/29(火) 01:52:41.35ID:xt+EJgQq
>>256
> マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、

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

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

マイクロソフトが使ってる文字コードをShiftJISと呼ぼうがCP932と呼ぼうが
NECや富士通なんかが勝手に文字を追加してしまうわけ
0259デフォルトの名無しさん
垢版 |
2020/09/29(火) 03:15:45.97ID:3c9yndle
そもそも IBM も NEC も富士通も、パソコンの主な使用目的の一つは、自社の大型コンピューターの端末として使うことだったからな。
だから自社の汎用機に合わせて文字を追加したんであって、MS-DOS とか眼中にはない。
追加した漢字が MS-DOS からもたまたま使えただけ。
パソコン専用の Apple の文字追加はまた別の理由だが。
0260デフォルトの名無しさん
垢版 |
2020/09/29(火) 06:39:24.27ID:jqf8qavY
東風フォントの人元気かな
0262デフォルトの名無しさん
垢版 |
2020/09/29(火) 11:27:29.43ID:3c9yndle
今となっては別に昔の名前なんてどうでもだが。
アスキー・マイクロソフトが出した最初に Shift JIS に対応した MS-DOS 2.01 では MIcrosoft Kanji Code が正式名称だった。
MS-DOS のソースコードの中でSJISの処理をする部分は KANJI という表記だった。
0265デフォルトの名無しさん
垢版 |
2020/09/29(火) 17:25:53.58ID:3c9yndle
白黒の限界を感じる。後、矢印の向きが派生ではなく包含関係だったりして、
通常とは逆なので知らない人が見ても理解するのは難しいかも。努力は認める。
>>264
文句あったらお前が書き直せ(お約束)
0267デフォルトの名無しさん
垢版 |
2020/09/29(火) 17:39:10.32ID:aO5ZnI7G
EUC-JPとShiftJIS系とUnicode系でも分けるべきだし
包含関係でまとめられるのはまとめるべきだろう
0268デフォルトの名無しさん
垢版 |
2020/09/29(火) 17:51:57.33ID:3c9yndle
ぱっと見てみたけど、包含関係は、かなり正確だな。
今までここに上げられた、いい加減な図と比べるとかなりマシ。
NEC の CP932 と、IBM の CP932 を混ぜて Windows CP932 ができたなどという中途半端な説明が
間違いということが、わかるように書かかれている。
0269デフォルトの名無しさん
垢版 |
2020/09/29(火) 17:55:22.30ID:aO5ZnI7G
>>268
図の真ん中、Shift-JIS Windows 932は
Shift-JIS with NEC r13 and 89-92 and IBM DBCS からできたって書いてありますが？
0270デフォルトの名無しさん
垢版 |
2020/09/29(火) 18:03:23.01ID:aO5ZnI7G
そして、その「Shift-JIS with NEC r13 and 89-92 and IBM DBCS」は
「Shift-JIS with NEC r13 and 89-92」＋「Shift-JIS with IBM DBCS」のことだって書いてありますよね？
0272デフォルトの名無しさん
垢版 |
2020/09/29(火) 18:20:25.83ID:aO5ZnI7G
左からの矢印？
そりゃいわゆるShiftJISと呼ばれたものに「NECの追加文字」と「IBMの追加文字」を加えたって言ってるんだから
左のもの（基本的な文字セット）もあるに決まってんだろｗ
0273デフォルトの名無しさん
垢版 |
2020/09/29(火) 18:34:13.19ID:3c9yndle
都合の悪いものは見えない目をしてる奴がいるようなので、
その図で表示されている文字集合の関係を表にしてみた。
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漢字)
0275デフォルトの名無しさん
垢版 |
2020/09/29(火) 18:39:08.12ID:aO5ZnI7G
>>215のリンク先に書いてある

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

NEC や IBM の拡張に由来する「いくつかの」追加文字を収録していますという話を繰り返しただけか
リンク先読んでねーなこいつｗ
0276デフォルトの名無しさん
垢版 |
2020/09/29(火) 18:41:53.46ID:3c9yndle
再挑戦。
Ａ　Ｊ　Ｋ　Ｘ　漢　Ｉ漢　Ｎ特　Ｎ漢
×　○　○　×　○　×　　×　　×　　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漢字)
0277デフォルトの名無しさん
垢版 |
2020/09/29(火) 19:33:37.91ID:3JpWukK6
ASCII 互換じゃないから Linux では SJIS は使えないｷﾘ
とかほざいてたのいたけど、実際には ASCII 互換じゃないと困るのは Windows の方だったという落ち。
樂しい♪
0278デフォルトの名無しさん
垢版 |
2020/09/29(火) 19:49:07.20ID:3c9yndle
>>277
仕方ないよな。UNIX 系のパス区切りは / なので ISO-646 系ならどれでも共通だけど
Windows はパス区切り \ なので国ごとに違っていて、Unicode に変換した時に困る。
0279デフォルトの名無しさん
垢版 |
2020/09/29(火) 20:13:35.05ID:gQNOuyE2
>>278
ん？
Windowsのパス区切りは、あくまでバックスラッシュで、
それぞれの言語環境で別の文字に見えてるだけでしょ？
割り当てられた文字コード番号自体は同じじゃないのか？
0280◆QZaw55cn4c
垢版 |
2020/09/29(火) 20:34:00.58ID:5fiAtNx/
>>279
win32api から見る限り、パス区切りは \ であっても / であっても使えます
0285デフォルトの名無しさん
垢版 |
2020/09/30(水) 00:15:57.00ID:mE7lggX7
それどころか多分どの制御コードやDEL、極めつけは
改行コードまでLinuxやUNIXはファイルめに使えるんだ
すごいだろー

findでどうやって改行コードが入ったファイル名を扱うのか知らんがｗ
0286デフォルトの名無しさん
垢版 |
2020/09/30(水) 00:17:36.68ID:mE7lggX7
バックスラッシュをファイル名に使うと面白いことができて
echoでそのファイル名を表示すると、色を付けたりできるんだｗ
0291デフォルトの名無しさん
垢版 |
2020/09/30(水) 00:27:29.17ID:JM4zIKtb
入力でなくて出力の話なら -0 オプションで、改行区切りから Null 文字区切りに変更できる。
0292デフォルトの名無しさん
垢版 |
2020/09/30(水) 01:46:35.60ID:bt+pY3Wp
ぬるぽ
0294デフォルトの名無しさん
垢版 |
2020/09/30(水) 02:08:30.20ID:mE7lggX7
ファイル名にコロンが使えるから
PATHのコロン区切りで問題が出るというねｗ
制御文字と一部の記号は使えないようにするべきだっただろうな
0295デフォルトの名無しさん
垢版 |
2020/09/30(水) 02:13:17.35ID:JM4zIKtb
アホか？ 使いたくない文字は使わなきゃ良いだけなんやで。
わざと変な文字入れて、変な文字入れられる方が悪いとか、小波。
0296デフォルトの名無しさん
垢版 |
2020/09/30(水) 02:17:17.38ID:mE7lggX7
>>295
論点ずれてるぞｗ
いろんな文字が使えちゃうから、それが原因でバグになるということだ

ファイル名に改行を入れられるってことを知らないで作っていたら
「bin<改行>lib<改行>etc」みたいなフォルダを消そうとして被害にあったり
「a*?」みたいなファイル名でaで始まるファイルが全部消えたりｗｗｗとか
実際に起きてるからな
0298デフォルトの名無しさん
垢版 |
2020/09/30(水) 02:26:53.11ID:JM4zIKtb
制限したいやつが制限すればええんやで。Linux にはその仕組みがある。
普通の人はそんなことせんでも変は文字入れないから、困ってないだけ。
0299デフォルトの名無しさん
垢版 |
2020/09/30(水) 02:49:29.19ID:mE7lggX7
入れたくていれるんじゃなくて
端末に文字をペーストしたら変な文字を実行しちゃったりして
その結果変な名前のファイルができたりするんだよ

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

普通の人は変な文字入れないというのなら
なおのこと入れられないようにしてよかったということになる
0300デフォルトの名無しさん
垢版 |
2020/09/30(水) 03:03:44.88ID:JM4zIKtb
だから、そんな間抜けなユーザー抱えてんなら管理者が制限設定入れとけや。
普通、変なファイルできても ls すれば、すぐ気付くし、シェルの補完とかも対応してる。
やってみもせずに妄想垂れ流す暇あったら触ってこい。
それでも駄目だと思うんなら、システム制限掛けとけ。
0301デフォルトの名無しさん
垢版 |
2020/09/30(水) 03:11:45.53ID:mE7lggX7
シェルの補完にバグがないとどうしているんだ？ｗ
メタ文字とかは勝手にエスケープが入ったりする。だがそれが正しいとどうしていえる？
どうエスケープすればいいかを知らなければ、今からエンター押しても大丈夫か？なんてわからんはずだが
だから俺はGUIから消すようにしてるよ。GUIならシェルのワイルドカード展開なんて使えないからね
0302デフォルトの名無しさん
垢版 |
2020/09/30(水) 03:15:35.92ID:JM4zIKtb
お前に Linux は早過ぎた。
バグが心配ならソースでも眺めとけ。ここプログラム板やし。
0303デフォルトの名無しさん
垢版 |
2020/09/30(水) 03:23:32.50ID:mE7lggX7
初心者「バグがあるかもしれない」
プログラマ「バグなんてあるわけない」

こういう考えかｗ
0304デフォルトの名無しさん
垢版 |
2020/09/30(水) 03:39:20.46ID:JM4zIKtb
初心者： いきなりバグとか心配しない。気になったたらドキュメントとか、ネット調べたり、試行錯誤して学習する。
プログラマ：いきなりバグとか心配しない。気になったらソースコード確認して、万一バグを見つけたら自分で直す。
お前：根拠無くバグが心配になり、5ch でOS の仕様にケチをつける。
0306デフォルトの名無しさん
垢版 |
2020/09/30(水) 03:51:15.98ID:mE7lggX7
なんてレスしてるうちにバグ報告したとある有名プロジェクトから
修正したってコメントが有ったわｗ
0310デフォルトの名無しさん
垢版 |
2020/10/02(金) 03:35:07.39ID:rHkefn4v
>>99
それなら普遍的に使えるスタイルとの結合文字にすりゃいい話
だけどそうしないのはそもそもスタイルと文字は分ける設計だから
スタイルはCSSなり他の技術がある
0311デフォルトの名無しさん
垢版 |
2020/10/02(金) 03:36:07.77ID:rHkefn4v
肌の色とか差別がなかったところに肌の色って概念を導入した結果結局偏りが生まれてるクソ仕様
0313デフォルトの名無しさん
垢版 |
2020/10/02(金) 11:31:57.29ID:vWjl5fwE
こんにちは、初めまして。

今、個人的に 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,'&#xFF5E;') は
JIS x0213:2004 コード規格の 波線(U+301C,'&#x301C;') に正規化することにしています。
(その他、似たような文字はなるべく一種類に正規化出来ればと考えています)
0314デフォルトの名無しさん
垢版 |
2020/10/02(金) 11:37:56.63ID:vEIDHK0R
グレープってなんだって思ったらグラーブのことか
0316デフォルトの名無しさん
垢版 |
2020/10/02(金) 12:00:25.80ID:vWjl5fwE
どうぞ。

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/)
0317デフォルトの名無しさん
垢版 |
2020/10/02(金) 14:38:35.67ID:vWjl5fwE
なんとなく備忘録

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 で６バイトのコードを表示するのも辞めてほしい・・・、
0318デフォルトの名無しさん
垢版 |
2020/10/02(金) 15:25:55.64ID:rmc8/xO8
日本の PC の内臓フォントは JIS X 0201 だったので、SJIS の 0x5C は円記号ということで運用されていたのだけど
Windows 3.1 で Unicode 対応を入れる時に ASCII 互換じゃないとうまくいかないことに気付いて、
CP932 の 0x5C を「見かけは円記号に見えるけど、実際には逆射線ということにした。円記号に見えるのはフォントせいで心の目で見ると逆射線」ということにした。
そのせいで Windows の一部日本語フォントを使った場合のみ 0x5C と 0xA5 の両方が円記号で表示される。
解決法: (1)別のフォントに変える。(2)Windows を捨てる。
0319デフォルトの名無しさん
垢版 |
2020/10/02(金) 15:54:09.42ID:rmc8/xO8
Unicode 的にはどっちでも良いのだけど JIS X 0213 的には 1-11-48,49 は 1F72,1F73 との対応を示しているので、そっちにしておくのが無難かな。
一文字にしておけば、結合文字に未対応の環境でも変にならずにすむし。
0320デフォルトの名無しさん
垢版 |
2020/10/02(金) 16:07:25.61ID:gdIx8v5/
>>318
消火器と消化器は間違えんなよ。小火器も使う時あるからな。
0322デフォルトの名無しさん
垢版 |
2020/10/02(金) 18:49:02.52ID:zXx3uGG2
>>318
Windowsだけでなく、国産Android端末もそういうフォント入れてる。
Android標準のnotoなら正しくバックスラッシュ出るんだけど、SONY端末には入ってないんだな。
0323デフォルトの名無しさん
垢版 |
2020/10/02(金) 18:54:47.21ID:vWjl5fwE
>>319
サンクス。
U+1F70 , U+1F71 , U+1F72 , U+1F73 は一文字の方を正規化先にして作ってみることにします。
0324デフォルトの名無しさん
垢版 |
2020/10/02(金) 20:47:22.49ID:ErcYaiEt
>>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の意味はチルダでグリフも〜だからそっちはそのままでいい

チルダ関係もカオスだよね
『〜』と『〜』別な文字だけど区別できる見た目で表示されているほうがむしろおかしいんだっけ?
0326デフォルトの名無しさん
垢版 |
2020/10/02(金) 21:17:20.27ID:zXx3uGG2
ピントはずれ。
シフトJISできる前からJIS C 6220のソースをコンパイラに食わせてた。
コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。

シフトJISとコンパイラで問題がでるのは文字列リテラル中のダメ字。
0327デフォルトの名無しさん
垢版 |
2020/10/02(金) 21:57:12.83ID:ErcYaiEt
>>326
> コンパイラは0x5cにASCIIのバックスラッシュ以外の意味知らないし、そう扱って問題は出ない。
正しく国際化されているコンパイラでは問題を起こす

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

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

実際にトライグラフをまともに使っていたのはデンマークだっけ?
0328デフォルトの名無しさん
垢版 |
2020/10/02(金) 22:12:09.12ID:rmc8/xO8
厳密にいうと C言語のソースは基本文字集合と呼ばれる 1バイト文字を含まなければならない。それには \ のみで ￥ は存在していない。
JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と ￥ を置き換えることになっている。
1バイト文字の解釈は必ず基本文字集合と同じでなければならない。
多バイト文字やシフト状態を持つ文字でナル以外の文字に 0x00 のバイトが来るのは禁止。
シフト状態を持つ場合には初期シフト状態に基本文字集合を持たなければならない。
上記を満たせば多バイト文字の解釈は実装依存。
0330デフォルトの名無しさん
垢版 |
2020/10/03(土) 00:32:32.33ID:5QIBKgVv
文字コードを意識せずにプログラミングが出来るようになる革命はまだですか？
0332デフォルトの名無しさん
垢版 |
2020/10/03(土) 09:47:26.20ID:8tX55Lof
>>328
> JIS の C言語の規格ではソースに JIS X 0201 を使用する場合は \ と ￥ を置き換えることになっている。
ANSI CやISO 9899にそんな規定はない
JISX3010で参考として追記された箇所であってローカル規格

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

gccの振る舞いが国際規格に準拠する正しい動作
0333デフォルトの名無しさん
垢版 |
2020/10/03(土) 10:32:33.14ID:1CYfZXkg
ideone.com とかは
スマホから試すときとPCから試すときで
\と＼の扱いが違って動きが可笑しくなることがある
unicode になって区別が明確になったことによる弊害のひとつ
0334デフォルトの名無しさん
垢版 |
2020/10/03(土) 14:19:07.86ID:asw2Nmie
>>322
だから JIS の C言語の規格で、なおかつ入力に JIS X 0201 を使う時、限定と書いてるじゃん。
コンパイラがロカール規格に対応していたら使って良いんだよ。
gcc がローカル規格に対応する義務はないが、ちなみに gcc には LANG=C-SJIS という設定があってな。
0336デフォルトの名無しさん
垢版 |
2020/10/03(土) 14:44:31.16ID:y5FkQ2yd
もちつけ
0337デフォルトの名無しさん
垢版 |
2020/10/05(月) 00:37:11.64ID:aYBNZcXd
>>323
どうなんだろうね。
確かにユニコード的には例えばNFDにしたときのベースの文字が正解かと。
一方 U+025X はIPAのブロックで、要は発音記号... ということは、文脈的に発音記号
として使われているならこっちだったりするのかも?
0338デフォルトの名無しさん
垢版 |
2020/10/08(木) 10:57:17.71ID:tD965ZiH
Rubyをやってるんだけど、分からないところあるから教えてほしいです…
クラスメソッド、インスタンスメソッド、インスタンス変数あたりの意味がさっぱりで…
0339デフォルトの名無しさん
垢版 |
2020/10/08(木) 11:08:48.28ID:Riy1MZEi
説明読んでも意味が判らない間は無理に使う必要は無い
君にはまだ早いってこと
0341デフォルトの名無しさん
垢版 |
2020/10/08(木) 11:34:16.59ID:SMtYwKCf
個人的に普段は ruby は使わないんだけど、文字コードの実装は perl や python や java に比べると ruby は筋が良いんだよな。(個人の感想です)
0342デフォルトの名無しさん
垢版 |
2020/10/08(木) 21:30:15.81ID:24ftK7/Z
>>341
python使いの私に文字コード関連でのrubyの利点についてぜひご教示ください。
rubyはさわったこと無いです。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況