文字コード総合スレ part15

**デフォルトの名無しさん** · 2024/08/17(土) 11:18:00.01

文字コードについて語り合うスレです

**デフォルトの名無しさん** · 2025/08/20(水) 15:48:16.32

絶対負けを認めないマン

**デフォルトの名無しさん** · 2025/08/20(水) 16:40:06.57

勝った負けたではなく、俺の認識はこう、ということ
お前がそう思わないのはお前の自由
(というか、何でも勝った負けたになるのは議論出来ない馬鹿の特徴
そもそも「議論」に勝った負けたはない
勝った負けたがあるのは「討論」＝決を採る段階で、5chで(というよりネットで)決採る意味はないから、
そもそもネットでのほぼ全部の議論に勝った負けたはない
その辺ひろゆきも大幅に勘違いしてるし、信奉者も同程度
つかね、論破に拘ってる＝論破して喜べる＝普段なかなか論破出来てない＝馬鹿
ということなので、自分で自己紹介しなくても、とは思うのだが)

PDFの仕様が完璧でなかったにせよ、
SJIS時代にMS明朝等使ってた人＝一般の人ほぼ全員は遭遇しなかった問題だろ

・MSが上手く回避策を実行してくれてた事を感謝するタイプか、(正確にはMSがではなく、普通に作ったら回避出来るとも思うが)
・俺が何をやるにしても自由だからとにかく仕様が悪いと言い張るタイプかの違いだよ

俺は前者、unicode連中やお前らは後者、ということ
ただ実際、unicodeはもう一度綺麗に作り直さないと駄目な程度に酷い仕様になってきてるよ
しかしこれはunicodeの唯一の利点＝文字化けしないを消す事になるから、死んでもやらないのだろうけど
となると、どこまで行けるか？というチキンレースにはなってるよ

**デフォルトの名無しさん** · 2025/08/20(水) 16:44:32.21

さんざんマウント取る言い方してきて、勝った負けたの勝負じゃないだとw
クソダサ

**デフォルトの名無しさん** · 2025/08/20(水) 17:25:07.68

>>423
SJISなんてものを褒め称えるとはマイクロソフト信者かね
昔からメールなどネット上ではいわゆるJISコード(ISO-2022-JP)が使われてきてこちらが国際的にも通用する主流でUNIXなどではEUC-JPが標準
もちろん今では国際的にUNICODEで統一され符号化はネット上もファイル保存もUTF8だがマイクロソフトさんは

**デフォルトの名無しさん** · 2025/08/20(水) 18:20:43.93

unicode 出る前からフォントは複数の文字コード対応マップで多言語化されれたことを知らないんだろうな

**デフォルトの名無しさん** · 2025/08/20(水) 19:22:16.58

SJISが世界の全てだった人なんだろうね

**デフォルトの名無しさん** · 2025/08/20(水) 21:05:49.55

>>427
JISがメールで使われてたのは7bit透過だからだぞ
SJIS信者だと思うのは自由だが、PDFのコピペに関しては、今風に言うと現場猫だよ
PDF仕様猫：グリフが重複して使われるフォントなんて普通ないからヨシッ
PDF出力アプリ猫：同上、ヨシッ
google猫：PDF出力アプリが対応してればグリフが重複してもヨシッ
unicode猫：同じ字(でもないが)に複数の文字コードを割り当てても、アプリかフォントが対応してればヨシッ

MS：普通、部首素片と通常文字は別グリフだろ、これで何も問題なくなるし
フォントがどうであれ、アプリ側で対応出来るのは事実なので、アプリが一番悪い
次に悪いのはフォントで、手抜きでなければ部首素片と通常文字は別グリフになるように思う
ただしそもそものunicodeの思想が間違ってて、そもそも統合漢字としてるCJKの通常文字、
日本人と台湾人と中国人の美的感覚は異なるだろうから、同一グリフで何とかなると考えてる所に無理がある
ただ、欧米も同様にアルファベットの美的感覚が微妙には異なるはずなので、連中が問題ないからCJKも問題ないと思ったのかな、とは思う
(ここらへんは文化の結合度によるが、欧米ほど人が交流してれば美的感覚もそれなりに共有されてるのかもしれん)

というか、具体的に言うと「骨」(0x9aa8)や「曜」(0x66dc)、これらは美的感覚ではなくモロに別形だが
CJK統合漢字という根本的なとこから間違ってるよねと
というかこれらが別コードとして登録されなかった理由は何なんだ？今更異体字ダーとかやってるのに

**デフォルトの名無しさん** · 2025/08/20(水) 21:08:26.58

ん？2行連続空行は削除されるようになったのか？
まあちと読みにくくなってるが、よろしく

**デフォルトの名無しさん** · 2025/08/21(木) 02:20:32.36

一つ一つの技術を正しく理解していないから、文字通り「個人の感想ですよね」という
まあ5ちゃんだし、酒飲み話みたいのもアリだとは思うけど
正しい知識が元になっていればそれは役に立つ話にもなる
一方読む方は間違いを間違いと見抜く力が.... って決してひろゆき信者ではないw

**デフォルトの名無しさん** · 2025/08/21(木) 02:56:06.57

私も世界にSJISさえアレば良かった人間です(過去形)。欲しい文字は外字にドット打ってました。
ROMに第2水準程度しか乗っていない8ビットや16ビット世代のマシンでUTF8を構築するのって、現実的に可能なのかしら。
興味本位の疑問だけど。

**デフォルトの名無しさん** · 2025/08/21(木) 04:47:17.94

交換用符号としての扱いは楽だけど
ROMのコードがJISだから変換マップをオンメモリにするのは厳しそう
索引付きでないと性能でないと思うから
これもROMで持てるならあり
もちろん幅や方向、合字なんかは扱えない

**デフォルトの名無しさん** · 2025/08/21(木) 05:18:08.01

>>433
そこはSJISとUTF8といった符号化方式の比較でなくてJIS漢字コードとユニコードの比較で十分
漢字ROMのデータ収録順序はJIS漢字コードの機械的変換できる範囲内だろうから
ユニコードからJIS漢字コードへのマッピング

**デフォルトの名無しさん** · 2025/08/21(木) 05:33:29.34

いわゆる半角カタカナ等(JIS X 0201)と全角漢字等(JIS X 0208)のほとんどは規則的変換できるようにユニコード内に収容されている
例外は一部の記号や文字のみ
したがって漢字ROM読み出しもほとんどは規則的変換できて例外のみ対応で実用的かな

**デフォルトの名無しさん** · 2025/08/21(木) 06:14:19.45

漢字は厳しいだろ
偶然だが半角の途中まではEF BDを前置するとUTF8
　A1　｡　EF BD A1

　AF　ｯ　EF BD AF
　B0　ｰ　EF BD B0
　B1　ｱ　EF BD B1
　B2　ｲ　EF BD B2
　B3　ｳ　EF BD B3
　B4　ｴ　EF BD B4
　B5　ｵ　EF BD B5

　BF　ｿ　EF BD BF

**デフォルトの名無しさん** · 2025/08/21(木) 08:42:01.26

>>436
JIS/SJIS/EUC: https://manuals.ricoh.com/mfp/p_manual/MPC6004JPN/ja/intro/int/r_cjr041.htm
unicode: https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/cjku_klist.html
さすがゆとりZ、無敵すぎ

**デフォルトの名無しさん** · 2025/08/21(木) 09:07:08.19

>>436
昔のAIにSJISをunicodeに変換するコード書かせたら何故かテーブルもってなくて機械的にシフトと論理演算で変換できますってコード出されたって話を思い出した
お前、そのAIだったりしないか？

**デフォルトの名無しさん** · 2025/08/21(木) 16:15:00.95

>>438
>JIS/SJIS/EUC: https://manuals.ricoh.com/mfp/p_manual/MPC6004JPN/ja/intro/int/r_cjr041.htm

区点コードで文字入力とはシブい。しかし字形が2004じゃないのは果たして
マニュアルだけの話でプリントで使うフォントとかは別なのかな。にしても

**デフォルトの名無しさん** · 2025/08/21(木) 21:08:42.64

>>440
何が言いたいのか分からんが、こちらの意図を明確にしておくと、
ただ単に「JIS 漢字表」でググって並び順が見やすいのを選んだだけ
コードなら以下が見やすいかと
http://www.infonet.co.jp/ueyama/ip/binary/x0208txt.html

JIS等は漢字もあいうえお順(ricohのサイトはまんまアイウエオで見やすい)
てかunicodeって何順？

**デフォルトの名無しさん** · 2025/08/22(金) 21:59:54.85

https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/cjku_radical.html
＞UnicodeのCJK統合漢字は、概ね部首順(部首内は画数順)に並んでいます

**デフォルトの名無しさん** · 2025/08/23(土) 02:24:50.51

しかしこれらの部首って、例のUnicodeの漢字部首のコードポイントに頼らなくても
出せるのね。元々各国の文字コードに部首のコードがあってそれがUnicodeに
引き継がれているようで

JISでも第二水準にちょいちょい部首が入っている。冫（にすい）とか
だがしかし「さんずい」や「しんにょう」などは第二水準にはない
これって何故でしたっけ。まさかさんずい＝水に「包摂」とか? ???

**デフォルトの名無しさん** · 2025/08/23(土) 06:47:36.46

>>443
氵も辶もJISにあるだろ (JIIS補助漢字または第4水準だが、包摂ではない)
もちろん Unicode も部首素片以外に漢字側にも登録がある
冫だけ第2水準なのは教科書とかで使用例があったから（うろ覚え）

**デフォルトの名無しさん** · 2025/08/23(土) 07:30:15.06

大元の理由が知りたいというい意味ならこの辺は漢字の歴史に由来していて
「冫」は甲骨の時代から独立した漢字で「氷」は字源的には「冫+水」の「冰」の略字
「氵」は「水」が部首になった時の省略形で昔の漢字では2つは全く同じ字形

unicode でも「冫」は漢字としてのみ登録されていて、部首素片(CJK Radical)には無かったはず

**デフォルトの名無しさん** · 2025/08/23(土) 08:40:59.48

>>444
「第二水準内で」（第四水準がなかった時代に）という意味です
第四がある現在では包摂の適用が変わりましたので

>>445
JISの中の人がどう考えていたのか気になりました
「冫」は康熙部首の方にありますね(U+2F0E）

どうやら康熙部首がメインでCJK部首が補助のようですが、件の「長」は何故か両方に

と思いきや、CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
そんなんわかるかあw

**デフォルトの名無しさん** · 2025/08/23(土) 08:52:37.93

>>444
「第二水準内で」（第四水準がなかった時代に）という意味です
第三以降では包摂の適用が変わったので、同列には語れません

>>445
JISの中の人がどう考えていたのか気になりました
「冫」は康熙部首の方にありますね(U+2F0E）

どうやら康熙部首がメインでCJK部首にはそのバリエーションが
なのに「長」は何故か両方に同じものが入っている??

と思いきや、CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
そんなんわかるかあw

**デフォルトの名無しさん** · 2025/08/23(土) 08:56:22.55

失礼、投稿が失敗したと思いダブリました（&少し書き直した）

**デフォルトの名無しさん** · 2025/08/23(土) 09:10:23.66

>>446
> CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
ならばgoogle猫が手抜きで糞フォントを作ったのがPDFコピペ文字化けの元凶だな
日本人の美的感覚では、(この辺は習字を見れば分かりやすい)
「長」の縦棒は、上よりも下のほうが少し左側(下のほうが広く見える)が美しいとされるので、
真面目にフォントを作れば同じグリフになることはない

**デフォルトの名無しさん** · 2025/08/23(土) 12:38:53.36

>>447
そういう意味なら「康熙部首」はもともと部品じゃなくて普通に使われる漢字なのでJIS的には漢字として登録されるのは問題ない
（康煕部首を漢字以外に登録しているunicode が変というかローマ数字の ⅰ がアルファベットの i と別にあるみたいな変さ)

「氵」とかは伝統的な漢字じゃないので（辞典類の索引くらいしか）単独の用例が存在していなかったのが理由じゃないかな
国語の教科書とかでも康煕準拠で「冫の部」とういう表記は使われるけど「氵の部」という部首は存在してなくて「水の部」と書かれてる

第3、第4水準の包摂基準は原則として第1、第2の基準を援用してるので第2水準で包摂されていたら第4水準に追加できないので、逆説的に第4水準に追加されたことは包摂されていなかった解釈になる（補助漢字はかなりあやしい

**デフォルトの名無しさん** · 2025/08/23(土) 12:45:02.17

>>449
文字をどのようにデザインするかはフォントごとの勝手、文字コードでは規定していない
いやならそのフォントを使わなければ良い
ゴシック体で画数と意識してられるかアホらしい

**デフォルトの名無しさん** · 2025/08/23(土) 14:58:11.95

あ、すみません

> CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話

ちょっとこの部分はガセかもしないので皆さん一旦忘れてもらえますか?
「長」が康熙部首とCJK部首（補助）に登場するのは事実ですが

**デフォルトの名無しさん** · 2025/08/23(土) 15:25:52.11

>>452
unicode には4つの「長」の部首素片が登録されてるメインに1つ、補助に3つ
多分メインのやつが字形を無視した意味上の部首素片で、補助のやつが unicode の包摂基準に従って分離された字形

**デフォルトの名無しさん** · 2025/08/23(土) 15:38:45.17

>>450
> 「氵」とかは伝統的な漢字じゃないので（辞典類の索引くらいしか）単独の用例が存在していなかったのが理由じゃないかな

なるほど、そんな感じですかね

**デフォルトの名無しさん** · 2025/08/23(土) 15:54:04.18

>>453
基底クラスに派生クラスが3つ、みたいな感じですかね

部首周りは思ったより複雑ですなw

**デフォルトの名無しさん** · 2025/08/25(月) 08:21:51.64

今回の話はほぼ部首由来だけど、そうでないのも少しありそう

U+6AF8（櫸）は「ケヤキ」らしいがこれ以外にU+237F1（𣟱）という字もあり、
この両者に同じグリフを使う場合がある
ちなみに例の坂道グループのはU+6B05（欅）、つくりの下側が「手」

ここらへんの文字がちゃんと扱えるのかのテストでもある

**デフォルトの名無しさん** · 2025/08/25(月) 08:51:42.49

ちなみに台湾の日本アイドルファン系のサイトには、U+6AF8を使っている
サイトが散見される.。まあ無理もないことではある
しかしそれだと日本の情報を十分に集められなかったのではなかろうか

まさかそれを嫌って櫻坂に改名したとしたら、なかなかの文字コード通か?
しかし今度は中国本土の人がU+6A31（樱）を使ってしまう可能性もある

**デフォルトの名無しさん** · 2025/08/25(月) 08:56:46.72

そもそも unicode の統合基準がグダグダなので unicode では同じ字形の文字が複数あるのが当然になってる（IVS/IVDも入れると同じ字形の漢字が3つも4つもあったり
あと1つのフォントには最大で65536グリフしか登録できないので多くの文字を登録したい場合やフォントサイズを圧縮したい場合は同じ字形は一つのグリフで表すというのも普通のテクニックになってる

**デフォルトの名無しさん** · 2025/08/25(月) 15:28:01.56

>>456
Unicodeは各国にある規格を取り込む、というのはまあまあやっていて
U+6AF8は台湾で使われる字、U+237F1は日本などで用例のある字、
で本来グリフにも差があるらしい

**デフォルトの名無しさん** · 2025/08/25(月) 18:00:18.28

>>459
U+6B05 は旁の下部が手なのでおいておいて

もともとU+6AF8 は横棒二本と横棒三本が統合(unify)されてる（日本語フォントだと三本、中国語フォントだと二本で表示されるのが一般的、
二本と三本を指定したい時は IVS をつけるのがルール、具体的には U+E0100 をつければ日本で一般的な adobe-japan の横棒三本の字体を明示的に示せる

IVS なんか知るか独立のコードポイントよこせという大陸様のゴリ押しで、横棒三本が別に U+237F1 に登録された
このせいで日本語フォントで表示すると両方が横棒三本の同じ字形という状態になってる（中国語フォントなら二本と三本で別の字形になる

**デフォルトの名無しさん** · 2025/08/26(火) 15:23:22.74

>>460
例えば
>IVS なんか知るか
U+237F1が入ったのはIVSより前じゃね?

**デフォルトの名無しさん** · 2025/08/26(火) 17:54:44.18

>>461
ちょうど同じ時期に並行して議論されてたんだよ
正式な規格書にコード位置が載ったのは Ext-B の方が少しだけ早かったかも

**デフォルトの名無しさん** · 2025/09/10(水) 21:44:22.92

Unicode 17.0 Release Announcement
https://blog.unicode.org/2025/09/unicode-170-release-announcement.html
「Unicode 17.0」がリリース～8つの新しい絵文字、日中韓(CJK)文字の拡充も継続
サウジアラビア通貨「リヤル」の記号も
https://forest.watch.impress.co.jp/docs/news/2046141.html

**デフォルトの名無しさん** · 2025/09/10(水) 22:23:52.97

>>463
漢字10万字突破とか笑える事態は置いとくとして
誰だ？ウサ耳の絵文字とか登録したやつは

**デフォルトの名無しさん** · 2025/09/10(水) 23:25:55.02

https://asset.watch.impress.co.jp/img/wf/docs/2046/141/image3_l.png

**デフォルトの名無しさん** · 2025/09/11(木) 14:48:21.23

>>464
合成でバニーガールとバニーボーイを使い分けられてジェンダーフリー、
ってそこまでしてw

絆創膏のデフォルトの色をどうするか、みたいな話もあったり
めんどくさい世の中だ
そういえばインド人から送られてきたthumbs-upの絵文字は茶色かった

**デフォルトの名無しさん** · 2025/09/11(木) 15:09:06.69

>>466
ああ、なるほど
「うさ耳」固有の絵文字が追加されたわけではなくて
今まであった「バニーガール」の絵文字を合成で使うと「うさ耳」の追加として処理するルールが追加されたのか

**デフォルトの名無しさん** · 2025/09/15(月) 20:12:18.82

>>464
しかしリアルな中国の辞書でも10万字を超えるのはないはずだけど
10万字突破ってどういう文字集合になってるんすかねえ
あと文字情報と汎用電子が追加したIVDはこの場合カウントされるのかな?

**デフォルトの名無しさん** · 2025/09/16(火) 03:15:46.45

>>468
手元に「汉字海」の2018年版があるけど、10万2千字超えてるよ
音未詳、義未詳、同〇〇、みたいな漢字が多数掲載

**デフォルトの名無しさん** · 2025/09/17(水) 13:27:21.24

>>469
なるほど。しかしそのうちどれだけにUnicodeのコードポイントがあるのか
興味深いですね

ちなみにこの場合の「海」は中心が点々で表示されるべきなんだろうけど
異体字セレクタにある点々の海を使うのは正解じゃないんでしたっけ

**デフォルトの名無しさん** · 2025/11/07(金) 08:24:41.35

macOS 26 Tahoeアップグレード後に、正規化形式(NFD/NFC)の不具合により日本語環境でNASに接続されたTime Machineバックアップが行えない問題はmacOS 26.1でも修正されていないので注意を。
https://applech2.com/archives/20251106-time-machine-bug-still-unresolved-on-macos-26-1-tahoe.html

Synologyサポートチームによる調査の結果、この問題はTime MachineバックアップをNASストレージ上に作成すると、日本語環境ではデフォルトで「Hogeのバックアップ」という名前がUnicde NFC形式で自動的に付けられ保存されるものの、macOS 26.0 Tahoeではボリューム名をNFD形式で探すようになっていることが原因だとして、
SynologyはAppleがこの問題を修正するまでの一時的な対応策として、バックアップ先のフォルダ名およびボリューム名をアルファベットのみで構成するという対処法を公開していましたが、Appleが2025年11月03日にリリースした「macOS 26.1 Tahoe」でもこの問題は修正されていませんでした。

**デフォルトの名無しさん** · 2025/11/10(月) 05:32:30.23

>>471
macOSの正規化の問題はもはや定期

**デフォルトの名無しさん** · 2025/11/18(火) 16:46:15.76

なんかMac上のAdobeのアプリが動かなくなってるらしいけどけどパス関連
じゃないだろうね
以前、システムのドライブを大文字小文字を区別するファイルシステムにすると
動かなくなったりしたことはある

**デフォルトの名無しさん** · 2025/11/19(水) 19:08:44.33

>>473
原因はまだ公表されていないが症状的にそういうOS寄りの話じゃなさそう
adobe がオンライン経由でライセンスの強制取り消しか何かの仕組みをいれようとしてバグったとかそんな感じのやつ

**デフォルトの名無しさん** · 2025/11/27(木) 22:04:02.60

AIにテキストが読み取られるのを防ぐために目に見えないUnicode文字を挿入する「Gibberifier」
https://gigazine.net/news/20251126-gibberifier-stun-llm-random-unicode/

文字コードの標準規格であるUnicodeには世界中で使われるさまざまな文字が登録されていますが、中には「目に見えないUnicode文字」も多数含まれています。また、そのうちの一部は目に見えない「ゼロ幅文字」となっています。

Gibberifierは入力したテキストの文字間に、ゼロ幅文字を挿入するツールです。目には見えないもののコンピューター上では存在しているゼロ幅文字を挿入することで、テキストの見た目はそのままに文字数が大幅に増加し、難読化されることでAIによる読み取りを防ぐとのこと。また、実際の文字数が見かけより大幅に増えるため、AIユーザーのトークンを無駄遣いさせることも可能です

**デフォルトの名無しさん** · 2025/11/27(木) 22:14:49.16

HTMLや画像でも文章認識できるのは前処理してるからで
こんなもん瞬で対策されておわりでしょ

**デフォルトの名無しさん** · 2025/12/10(水) 11:51:06.42

皆さんUTF-8 code pageでのテストしましょう

Fix corrupted file loading on Windows system using the full UTF-8 code page. (Fix #17234)
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/17234

**デフォルトの名無しさん** · 2025/12/10(水) 12:14:52.51

Windows で BOM 付き UTF-8 使った時にバグるのか。
ちゃんと実装できないんなら滅んでしまえ

**デフォルトの名無しさん** · 2025/12/10(水) 21:28:59.81

NPP v8.8.6 32bitでは再現出来なかった

**デフォルトの名無しさん** · 2025/12/11(木) 00:51:43.45

>>479
多分英語版の Windows のバグ
日本語版の Windows ならデフォルトロケールを英語 codepage 1252 に変更しないと再現しないと思う
SJISにはSJISで別の文字で類似バグがあったりするかもしれないけど

**デフォルトの名無しさん** · 2025/12/11(木) 04:34:26.04

そういえば少し前ベンダーから送られてくるログがやたら文字化けしていて
うんざりしたが、ちゃんと見てないが関係あるのかなあ
データ的にWindows上でSJISとUTF-8を混ぜこぜにしてる感じだったが
しかしいつまでこの手の問題が続くんだろ

**デフォルトの名無しさん** · 2025/12/11(木) 06:20:41.73

ちゃんと見て原因を特定しないお前のような奴がいる限り無理だろ

**デフォルトの名無しさん** · 2025/12/13(土) 06:14:20.73

>>482
自分がメンテしているソフトウェアで文字化けが発生しているのではなく
ベンダーがログのデータの扱い中になんかやらかしている
ログのデータをそのまんま送るだけでいいのに余計なことすんなと
そんなものに付き合ってるほど暇じゃない

**デフォルトの名無しさん** · 2025/12/13(土) 14:45:54.42

最近のネット関係の実装とか脆弱性の問題をおいかけてると
セキュリティリスクになるので
・通信にはUTF8以外は使うな
・BOMは拒否しろ（付けるな認識するな）
という方向に収束していきそうだな

**デフォルトの名無しさん** · 2025/12/13(土) 15:00:06.21

バイナリやASCIIに回帰するならわかる
Unicodeは太っちょだし実装がまだ枯れていない

**デフォルトの名無しさん** · 2025/12/13(土) 17:36:17.84

英数字だけならSJIS,UTF-8,ASCIIは同じなのでいいよね
改行コードの問題はあるけど。

**デフォルトの名無しさん** · 2025/12/13(土) 23:27:14.26

>>485
つい最近も致命的なやつが見つかって大騒ぎ

unicode の使い方を今更統一するのは無理
文字コード変換とかあると重大的なセキュリティホールになる
UTF-8限定で他の文字コードを一切許さなければバイナリ扱いでリスクは低い
ASCIIはUTF-8の完全なサブセットなのでUTF-8扱いしても問題ない

ということらしい。

**デフォルトの名無しさん** · 2025/12/13(土) 23:30:44.14

>>486
SJIS さんはバックスラッシュと円記号問題があるので駄目です。仲間には入れてもらえません。

**デフォルトの名無しさん** · 2025/12/15(月) 16:21:56.43

>>488
Macでも使ってんのかw

**デフォルトの名無しさん** · 2025/12/17(水) 20:05:34.96

>>489
>>488 の言うのは、Shift-JIS の 1 バイト文字部分の規格は JIS X0201 であって、ASCII と完全に同一ではない、ということでしょ
それに対して Unicode や EUC-JP の 1 バイト部分は ASCII そのもの
まぁ MS の CP932 なんかはかなりアバウトなんだけど

**デフォルトの名無しさん** · 2025/12/17(水) 20:54:58.87

>>490
かなりアバウトwww

MS CP932 0x5C
フォントで表示すると円記号なんだけど、心の目で見るとバックスラッシュな文字
どう見ても円記号だし昔から円記号として使われていて、なんならマイクロソフトの技術マニュアルにもそう書いてあったのに、ユニコード導入する時のどさくさでバックスラッシュだったと過去改変し半角円記号なんか存在しなかったことになった文字
今でも日本語Windowsのフォントだと円記号表示されたりするけど規格上はバックスラッシュなんで見た目に騙されてはいけない
無茶言うな!!

**デフォルトの名無しさん** · 2025/12/17(水) 22:12:32.32

ANKは大昔ISOに沿って名前と書体が変わった
二重に名前が付いてるだけで交換用符号としては困らない
極東がバックスラッシュ置き換えたのは事故なのでしょうがない
DOSのパス区切りとSJISはメタ文字利用されだした後だからただのアホ

**デフォルトの名無しさん** · 2025/12/18(木) 01:39:33.82

まぁ ANK しか使えなかった時代には、円マークはそれなりに利用価値があったはずで
一方で DOS や Win のプログラミングでは、当時からそれをバックスラッシュと空目しながらコードを書いてたわけで
資産継承を考えると MS のやり方を一概には責められない、とは思うけどね

**デフォルトの名無しさん** · 2025/12/18(木) 10:15:45.78

>>493
資産継承とかいっても未だに解決してないのが問題
Windows ユーザが 0x5C 送ってきても円記号を送りたかったのか文字通りバックスラッシュなのか受け取った側では判別できない
問題を先送りしただけで被害（駄目な資産）が再生産されてる

**デフォルトの名無しさん** · 2025/12/18(木) 15:49:32.31

レシートの円マークは頑張って表示しているんだろうな、と思いました。
直DBに繋がっているシステムは、バックスラッシュで使う要件も多いはずなのに。

**デフォルトの名無しさん** · 2025/12/18(木) 19:40:56.03

いろいろな作り方があるけどビューだけは分離して考えて

**デフォルトの名無しさん** · 2025/12/18(木) 21:46:10.30

>>494
そのとおりなので特にコメントはないｗ

いや今回は擁護するようなこと書いたけど、MS の肩を持つつもりは毛頭ないので
むしろ敵だと思ってこれまで戦ってきたけど、力及ばすというところ

**デフォルトの名無しさん** · 2025/12/19(金) 21:46:54.73

>>492
真説 Windowsでディレクトリ区切りのスラッシュ / がバックスラッシュ ⧵ で円マーク \ な理由
https://qiita.com/ko1nksm/items/4ae0a784a612f23aa412

**デフォルトの名無しさん** · 2025/12/19(金) 22:58:08.40

>>498
どうでもいいけどケン・トンプソンが Unix を作ったのは自作ゲームで遊ぶため、という話はウソだったのかな

**デフォルトの名無しさん** · 2025/12/20(土) 01:42:46.43

>>498
よく調べてるけど本質を理解してないので論旨がゴミになってるな
「バックスラッシュを使いたければフォントを変えればすむ」
とか言ってるやつの長文読む価値はない

**デフォルトの名無しさん** · 2025/12/20(土) 01:54:11.10

どこがへん？
日本語環境以外にするのは本末転倒だしスマートな解決やん
反論にしては中身スッカスカだし愉快犯なんだろうけど

**デフォルトの名無しさん** · 2025/12/20(土) 08:12:39.40

俺は>>498はよく書けてると思ったけど。
大半は知らない事だが、俺が知ってる範囲の事は合ってるし。
実際、バックスラッシュのフォントが\であれ、見た目以外に問題になったことないし。
(ただ俺は基本的に枯れてることしかやらない、つまりファイル名の日本語化は《特にCLI環境では》避ける人間だがな。
ちな、Mintでも　ダウンロードやデスクトップという日本語フォルダが自動的に出来てウザい《打つのが手間すぎて使いづらい》)

ゆうて0x5cが被ったところで、前から正しくSJIS判定してれば普通に使えるだろ。
utf8のようにASCII/null終端前提のCコードにブっこんでもそれなりに動く、という程イージーではないだけで。

**デフォルトの名無しさん** · 2025/12/20(土) 10:25:41.79

漏れのconsole(win11のcmd)は
日本語キーボードで「\」キーを押すと
「＼(半角のバックスラッシュね)」が出るけど何にも困らん
chcpは932でも65001でも同じ結果

**デフォルトの名無しさん** · 2025/12/20(土) 11:14:30.11

肝心なのは文字コードは情報交換用符号ということ。送った方と受け取った方で意味が一致していないといけない。そのために共通規格がある
自分の中で閉じ籠もっていれば俺俺コードとかでも問題ないけど他者と情報交換したいなら規格を合わせないといけない
Microsoft はそこがちゃんとわかってなかった

一番問題で指摘すべきなのは Microsoft CP932 （独自規格）から Unicode （共通規格）への変換テーブルを定めた時に円記号をバックスラッシュにマップしたとこ
独自規格では何やろうと勝手で MS はそれまでも独自実装で規格を勝手に改変して独自のものを作ることが多かった。当時の Windows にはTCP/IPとかも実装してなく他者と情報交換するのが限定的だったので俺俺でも良かった。シェアも圧倒的だったので俺俺実装を押し付けてくることが多かった

今はちゃんと規格を守る優良企業に変化した (そのために IE とか捨てるはめになった) けど過去が足を引っ張っているのはこの点。他の長々は蛇足。技術調査としては面白いが文字コード (情報交換) の視点が欠けてる

要はネットワーク時代を予想できない時代遅れの自閉症思想で問題を場当たり的に対応しようとしたつけが残っている状態。多分今では後悔してるだろう

**デフォルトの名無しさん** · 2025/12/20(土) 11:58:14.83

現実解としてはMSのやり方が正解

**502** · 2025/12/20(土) 12:41:05.42

うむ、自分の投稿が化けてる(投稿時と違う)のに気づいた。
こういうところは不便、というか仕様バグレベルだな。
見た目、送信時に差し替えられてるようだが、以下テスト。
(502は化けないようにわざわざ全角円記号にしたのだが、半角バックスラッシュになっている)

半角バックスラッシュ: \
全角バックスラッシュ: ＼
全角円記号: ￥

**デフォルトの名無しさん** · 2025/12/20(土) 12:42:50.59

んん？俺の勘違いか？だったらすまん

**デフォルトの名無しさん** · 2025/12/20(土) 12:56:08.36

MSはファイルに使える文字も見せ方も頑張ってはる

**デフォルトの名無しさん** · 2025/12/20(土) 13:03:13.01

>>504
> 変換テーブルを定めた時に円記号をバックスラッシュにマップしたとこ
これは正しい。0x5cはバックスラッシュで、フォントが円記号なだけだから。
プログラミング的には、モデル(意味)はバックスラッシュで、ビュー(見た目)が円記号なだけだから。

つまり同音異義語のようなもので、同じコードを複数の意味で使っていたのだからどうやっても問題になる。
どちらかに揃えるなら、当然バックスラッシュだ。
使用状況からどちらとして使っているかは(人間には)容易に推測できるから、自動判定頑張れはあるかもだが、
今ならまだしも、80〜90年代では無理だ。

現実的に、バックスラッシュを円記号に「見た目だけ」差し替えてもあまり問題なかったから今がある。
和文でバックスラッシュを使うことはないし、困るのは精々プログラマだけというのも事実だ。
(この点からすると、0x5cをどちらにするかは手動で切り替えるべきだったのかも？
まあs/\\/￥/すりゃいいだけではあるが)

**デフォルトの名無しさん** · 2025/12/20(土) 15:03:29.90

>>509
文字コードに「同音多義語」ｗｗｗとかあってはいけない。 MSのCP932は独自規格なので知らんが Unicode に同音多義語などない
Unicode の 0x5C を円記号で表示するのは明確な規格違反。その規格違反を許し続けている以上問題は解決しない

**デフォルトの名無しさん** · 2025/12/20(土) 15:43:38.07

特定フォントのグリフの問題であって、ここで話すことではない

**デフォルトの名無しさん** · 2025/12/20(土) 17:17:31.62

>>511
いや、だからそれは規格上は間違いなんすよ

Shift_JIS の 1 バイト部分は JIS X0201 なので、そこでは 0x5C は円マークであってバックスラッシュではない
Unicode の 1 バイト部分は ASCII なので、0x5C はバックスラッシュであって円マークではない

それをグリフの問題として片づけるのは実利上の「解釈」に過ぎなくて、規格として明文化されたことは一度もない

でも規格通りに変換してマッピングを変えると、大抵のプログラムはちゃんと動かなくなるので、プログラマには (私も含めて) 受け入れ難い
なので、なぁなぁで済ませるｗ

ということですよ

**デフォルトの名無しさん** · 2025/12/20(土) 18:11:46.05

>>510
> Unicode に同音多義語などない
そうなのだろうが、実際に使う人間は同音異義語に慣れているので無理だ。
具体的には、単字AA、例えば w (単芝) は明確な同形異義文字として使われてる。
Unicode警察的には、新たに登録された芝の絵文字を使うべきなのだろうが、誰もそんなことはしない。
(ググっても🌱🌿🍀🍃しか出てこないが、ここ数年のうちに登録されたものがあったはず。
しかし出てこないところを見ると、俺がLINEスタンプと勘違いしているか？)

**デフォルトの名無しさん** · 2025/12/20(土) 18:23:22.98

>>513
w はラテン文字のｗであって他の文字ではない
文字コードは文字の解釈ではなく「文字」を規定している
「文字」であって「語」ではないし「義」を定義していないので多義語とか異義語とかありえない
unicode ではバックスラッシュの文字は 0x5C 、円記号の文字は 0xA5 で表現されなければならない。逆は認められない

**デフォルトの名無しさん** · 2025/12/20(土) 18:27:18.42

>>512
解決するには、0x5cをどちらの意味で使ってるか明確に意識し、別のコードとして使い分ける、しか無いだろ。
なら、今は移行期間で、Windows13からは0x5cはバックスラッシュであり円記号ではないので、それまでに書き直せ、程度の解釈でも問題ないのでは。

だから問題なのは現実の運用で、

A: 0x5c→￥で困るのはプログラマだけなのだから、こうした上で、プログラマはフォントで誤魔化すなり、s/\/\\/しろで済ます。
B: 0x5c→バックスラッシュとして、￥の意味で0x5c使ってる場合は積極的な書き換えを促す。最低限、新規で使うのは禁止。

のどちらかであるべきなのに、

現実(Bモドキ): 0x5c→バックスラッシュの癖に、新規で0x5cを￥の意味で使うことすら禁止してない。

から筆者も問題視してるんだろ。ただ実際はAの方が良かったように思えるし、筆者も、504も、多分お前もそう思ってるんだろ。
プログラミング理論的にはBだからBモドキになってしまってるが。

**デフォルトの名無しさん** · 2025/12/20(土) 18:59:02.34

>>515
unicode の 0x5C は元からバックスラッシュで円記号だったことなど一度もないよ
それなのに unicode の 0x5C を円記号で表示するフォントを準備して積極的に誤魔化してるのが今の日本語Windowsの状態
導入当初から変なのであって途中の移行で変になったわけではないよ

**デフォルトの名無しさん** · 2025/12/20(土) 19:45:20.19

>>516
それはお前が間違っている。(或いは勘違いしている)

Windowsはunicodeを使用する(準拠する)のが目的ではなく、
従来Windowsと互換を維持しつつ、最大限時代に合わせる＝なるべくunicode準拠にする、のが命題だからだ。
だから、互換性が崩れるところはSJIS/CP932を優先するし、unicodeの仕様は無視されて同然。
これは非常に現実的で妥当で真っ当な判断だ。

一言で言えば、WindowsはUnicode警察用のOSではない。
そんなにunicode完全準拠が欲しければ、Windowsを止めて、完全準拠の別OSを使えばいいだけ。
(あるのかどうか知らんが)

**デフォルトの名無しさん** · 2025/12/20(土) 20:06:56.48

>>514
> 文字コードは文字の解釈ではなく「文字」を規定している
そうだとして、これだとunicode内に矛盾を生じる。
つまりは正規化の問題だが、

が (0x304c) と
が (0x304b,0x3099)

は(人間にとっては)同じ文字だが異なる文字コード(＝unicodeでは別文字扱い)になってるだろ。
だから正規化の問題はあちこちで発生しまくってるわけだけども。
これは仕様がKISS/驚き最小の原則に反してるからバグの温床になってるのもあるが。

そもそも人間が使っている文字は表音文字(アルファベットや平仮名)か表意文字(漢字)であって、
音も意味も無関係なただの文字(unicode、或いはQRコードのようなビットパターン)ではない。
だから完全分離して綺麗にマッピングしようとしてもかなり無理があって、実際ろくでもないことになってる。
(勿論これでも頑張った方なのは認めるけども)

**デフォルトの名無しさん** · 2025/12/21(日) 00:53:34.65

>>517
>>518
お前は規格が分かっていない
規格というのは任意に一部だけ無視することはできない
選択肢がある場合には規格自身に選択をして良いと記述されてなければならない
unicode 規格には U+005C を円記号に使って良いという記述はない
互換文字とか変種とか規格に書かれてば規格が許可する範囲で使って良い

**デフォルトの名無しさん** · 2025/12/21(日) 01:55:13.85

ほら
愉快犯だった

**デフォルトの名無しさん** · 2025/12/21(日) 07:20:46.63

>>519
でマイクロソフトは円記号問題どうすべきだったわけ？
経済合理性無視した幼稚な意見は控えてくれ

**デフォルトの名無しさん** · 2025/12/21(日) 07:55:00.80

>>519
「規格」の認識はその通りだとして、
繰り返すが、その部分は互換性の為に規格を無視する判断だろ。これに何の不満が？
規格警察ならお前が100%unicode準拠の何かを作ればいい。だけど出来ないと思うぞ。

お前は、規格＝絶対大正義だと勘違いしてる。
規格ってのは、基本的には揃えて無駄な手間を無くす為の方策であり、絶対遵守のギアスではない。
勿論人が定めるものだから、特に政治的指向がある場合、それ自体に間違いが含まれる事も多い。
unicodeなんて、人の絵文字で肌色48種類みたいな、ポリコレまみれになってるだろ。

まあこれはさておき、unicodeは技術的にも間違い(というか矛盾)を作り込んでる。
unicode、というより計算機用の文字コードは、読みや意味よりも見た目(グリフ)との結びつきが強い、
というお前の説(>>514)は一理あるし、実際そうあるべきかもしれない。
ただ、unicodeはK(0x4b)とK(0x212a)を分離してるだろ。
これらは見た目が完全に同じで、意味で分離してる。
(この辺に矛盾が発生し、実装で大幅に手間となるので、100%準拠の実装をする奴が居なくなる)

物理学の単位は人の頭文字から取られているので、自動的にアルファベットになる。
unicode以前のK(ケルビン)は、別文字が用意されていなかった事もあって、全て(アルファベットの)Kが使われていたはず。
当然、全てのグリフは同一だった。
(実際は斉の類と同じで、本来は微妙に違うのだが我慢して使ってただけかもしれんが、知らん)

ただし、計算機用の文字コードをグリフではなく意味で分離し、使い分けをさせる事自体は(計算機的には)正しい。
置換や検索等の計算機上の操作には(本来は)有利だし、その後、同じグリフを与えて同一の見た目にする事も簡単だからだ。
分離してない物を適切に分離させる方が段違いで難しいので、あらかじめ人力で分離しておけ、というのは(今は)正しい。

**デフォルトの名無しさん** · 2025/12/21(日) 07:55:23.64

ただ、K(ケルビン)を検索する為には、今後とも、殆どの人がK(アルファベット)を使うに決まっている。
だから今後とも、K(ケルビン)とK(アルファベット)を(少なくとも検索時は)同一視する必要があり、
この辺で技術的負債がかなり発生する。
(仮に、あらゆる文書でK(ケルビン)とK(アルファベット)が完全に間違いなく分離された時代の後でも、
K(ケルビン)は利便性の為にK(アルファベット)で検索され続けるはず)
これ以外にも、unicodeはこの手の話が多い。
勿論、現存する文字情報を全てデジタル化する為に、あらゆる文字を少なくとも表示できることが必要であり、
これに向かって邁進した結果、色々矛盾を抱え込む状況になってるのは仕方ないにしても、
規格として、これを最優先、という方針がなく、あやふやな印象なので、無駄に矛盾が発生しまくってるように見える。
だから、unicode＝正しい、とは、俺には全く思えない。

この点、MSの「互換性重視以外にはないだろ馬鹿タレ」は分かりやすくていい。
使用者にとって、挙動を100%予測/納得できることが最重要だからだ。

unicodeの正規化問題なんて、初めて知ったときには、かなり驚いた。
本来規格/仕様上にあんな問題が存在する事自体が間違いで、
NF(K)C/Dのどれでもいいが、本来は、入力時に正規化してしまって、
unicode文字列として存在するのは正規化後の文字列だけ、という規格/仕様にしてないといけない。
これをしなかった/出来なかった正当な理由なんてない気がするがね。
この辺がunicodeは規格側の体制/方針が間違ってる、というかあやふやなままだ。
だからろくでもない規格になりつつある。
(寄り合い所帯の限界ではあるのだろうけども)

**デフォルトの名無しさん** · 2025/12/21(日) 09:23:22.82

>>523
unicode が正しいかどうかという問題と unicode 規格に適格というのは別問題

unicode が間違ってるなら unicode を採用しないか unicode 規格を改定すれば良い
それをせずに unicode だと言い張りながら unicode ではない独自変種を他者に送りつけてくるのが間違い