文字コード総合スレ part15

**デフォルトの名無しさん** · 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 ではない独自変種を他者に送りつけてくるのが間違い

**デフォルトの名無しさん** · 2025/12/21(日) 10:33:38.74

>>524
unicode警察くんは結局の所、
windowsで作成した書類をunicode準拠です、として送りつけられることが嫌で嫌でたまらないのか？
ならお前は無駄にハゲるし早死するだろう。
こんなしょうもない所でいちいち腹を立てても意味ない。ただそれでもお前の自由ではあるがな。

0x5cの問題なんて人間が見れば分かる程度のものでしか無い。
お前が今後共unicode意識高いのはお前の自由だが、
日本語の書類の大半が今後共Windows上で作成されることも、
お前以外の大半がWindowsの仕様で何の苦労もしないことも変わらない。

そんなことより正規化のほうが大問題であって、
放置しておけばバラけて問題になるが、どれかに決めておけば問題が無くなる、まさにこういう事の為に規格/仕様は存在するのだから、
決めきれてないのは存在価値を自ら放棄してるのと同じ。
馬鹿じゃねーの(AA略
と本当に思うよ。
(とは言え、世界中の言語をカバーしようとしても、現実的に全言語を詳しく知っている人は居ないので、
まあそうなるだろうな、程度にグダグダになってるだけではあるが。
これは風呂敷の広げすぎ＝目標仕様が壮大すぎて現実離れしてただけであって、unicodeの次に期待するしか無い)

**デフォルトの名無しさん** · 2025/12/21(日) 11:44:27.73

Windows でしかものが見れない時代遅れの Windows 中心主義者の言いそうなことだな
Windows の問題は Windows の中に閉じ込めとけ、輸出してよそに迷惑かけるな

Windows からスマフォに送ったら文字化けしましたって毎回問い合わせされるスマフォアプリ開発者やサーバー技術者の身になって考えろ、そしてアプリ側では一切対策が存在しないんだぞ（あきらめろ、文句あったらマイクロソフトかwindowsソフトの開発者に言えって回答してしかられるだけ）

今の時代はスマフォもサーバーも Windows 以外で Windows は少数派なんだよ自重しろ
パス区切りとかプログラムすら分かってない素人がコンピュータ使う時代なんだよ

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

unicode警察くんがMacOS使いだったら、あっちはあっちで変態文字コードなのに...と思った。
私は仕事では Windows,AIX,Linux 上で SJIS が残っているから今の状態でいい人だけど。
OS だけでなくて DB も文字コード関係する所はあるから、中々統一出来ないよ。
相手システムに合わせて EBCDIC でデータも送っているし。

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

>>527
文字コードの統一なんて関係ないし Mac 内部の話も一切関係ない
外部とのやりとりのときに unicode で送るんならちゃんとした unicode で送ってこいというだけ
そかっら先はこっちの責任で対処できる
曖昧なの送られてもこっちでは対処できない

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

>>526
> スマフォアプリ開発者やサーバー技術者の身になって考えろ、そしてアプリ側では一切対策が存在しないんだぞ
100%嘘だな。
だからWeb系はゴミだと言われるんだよ。

少なくともスマホは後発なのだから、先発のWindowsに合わせる、という選択肢はあった。
自分達は規格準拠だから正しい、お前が変えろ、というのはgoogleはじめゴミ共のやり口だ。
とりあえずUA見れば当面の対策も出来るはずだが、それもやる気がないのは、
自分たちこそ正しいと信じてる、意識高い系馬鹿共の言い分だよ。

まあ昔からMSアレルギーのあるやつは居たし、お前もそうなのだろう。
ただ実際の所、かつてのMSよりも今のgoogleの方が何倍も酷いのだが、
その辺酷く言われないのは、立ち回り方が上手いのか、上手く情報操作してるだけなのか、謎だがな。

数年のうちにWindowsが滅びることはない。パヨクみたいに足を引っ張ることが目的でないなら、
単純に、Windowsのunicode(モドキ)→お前が信じる正しいunicode、の変換器を作ればいいだけだろ。
これは本当に簡単に実装できるはずだ。

知能がないやつは全部MSが悪いというが、
少なくとも現行で一番シェアが高いのは、現在一番マシな選択肢だと認識されているということ。
この事実を認めないと、パヨクのままだぞ。

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

>>528
意識高く、
「あなたのunicodeは、Windowsで作成したものですか？
それともunicode完全準拠の金のシステムで作成したものですか？」
といちいち問えばいいんではないですかね。
嫌われるだろうけど、お前の目的は達成できるだろうよ。

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

Kの話で知ったが
物理と言ってもVやAやPやEやBやHやGやTやIやCやQやDやFやJやLやMやRやUやWが独立した話は聴いた事が無い
μをuと描く香具師が居るのは迷惑だった鴨試練
C言語のCとかD言語のDは別コードになってる方が検索には便利だったはず

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

windows が unicode を採用したのは当然ながら unicode が出来た後だよ
そういう当たり前の事実すら見えなくなってるのが windows 老害

**デフォルトの名無しさん** · 2025/12/21(日) 15:22:21.34

>>532
俺が正しい、お前が間違い、なWeb系パヨクの言い分だな。
実際google筆頭にこんな感じではあるが。
最早日本語が通じ無い感があるが、再度繰り返すと、

スマホの方が後発であり、その時既にWindowsが支配的シェアを持っていたのだから、
・Windowsの仕様を丸パクする、または、
・Windowsコード→オレオレunicode変換器を準備する
が非パヨクな普通の人が採る選択肢だ。(＝非パヨクなら、解決の具体策を準備する)

後から「標準化しました〜こっちのほうが正しいです〜」と難癖付けられても、
互換性を重視すればそう簡単に変更するわけにも行かない。
そしてポリコレ棒ならぬ規格棒で殴り続けるという手口か。

まあお前は「Windowsのunicodeは、unicodeではありませんよ」と言い続ければいい。
疎まれるだろうけども、お前は満足できるだろうよ。
そしてこれは、物事を解決する気がなく、ただ文句を言うだけの、典型的なパヨク仕草だと思うぜ。

**デフォルトの名無しさん** · 2025/12/21(日) 15:57:03.22

>>531
> Unicode Block “Letterlike Symbols”
> https://www.compart.com/en/unicode/block/U+2100
見た目何がしたかったのか分からんが、
ℎ(プランク定数0x210e)とか、h(アルファベット)で文句言ってる奴に遭遇したこと無いので、
書き直せって事になれば混乱するだけだろう。

> μをuと描く香具師が居るのは迷惑だった鴨試練
むしろ俺は慣れすぎて、最近増えた、頑なにμを使う奴がウザいが。
(というか、以前はum,usと書く以外の選択肢がなかった)

> C言語のCとかD言語のDは別コードになってる方が検索には便利だったはず
これはABCのCなのだし、検索という概念自体がなかった頃なのだから致し方なし。
D言語はそもそも検索でヒットする必要もなし。
Go言語という命名をした連中はただの馬鹿。でもこれ以降、ググラビリティが気にされるようにはなった。

unicodeはすべてを「文字」に集約しようとした。多分ここが間違いだった。
今作り直すなら、ほぼ間違いなく、タグにするはず。つまり、

unicode: K (0x212aという、K(0x4b)とは別の字を用意)
今なら…: <class="KelvinSign">K</> (アルファベットのKに情報を付加)

考えてみれば、Texがこれに近いか。
まあasciiの時代にアレコレ何とか表示しようとしたらこれしか無かったからではあるが。
IVS/IVDも、実はタグ方式のほうがスマートに解決できるのかも？

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

unicode警察くんが存在する事が面白いけど、困り事はサッパリ分からん。
スマホアプリで見た目の円マークとバックスラッシュを使い分けたいシチュエーションも分からん。
エスケープ文字や正規表現でバックスラッシュは使うけど、そこで円マーク出てきても（今は出て来ないと思うが）困る訳でもないし

**デフォルトの名無しさん** · 2025/12/22(月) 07:09:14.21

>>535
実際、文字コードというよりはフォントの問題だからな。
0x5cが半角円記号で表示されるフォントを使えば、見た目以外の問題はなくなる。
そして気づいたんだが、LinuxMintでも半角円記号で表示されてた。つまり、

・Windows→半角円記号
・Linux(Mint)→半角円記号
・泥9,泥14→半角バックスラッシュ

で、googleが意識高い系馬鹿ムーブをやらかしてるだけだ。
とはいえ、フォント変えれば済むなら、試しにやってみようかと思いきや、
変える設定無いんだな。root化必須かこれ？
この辺がどうにもスマホに借りてきたデバイス感が拭えず、好きになれないところだ。
PCと同様に、完全にオープンアーキテクチャにして、好きなOSその他を入れさせてくれ、と思うよ。
(今のメーカー製PCと同様の扱いでいい)

**デフォルトの名無しさん** · 2025/12/22(月) 07:30:48.38

>>536
そのMintが異常なだけだろ
LinuxはUbuntuなどいくつか使ってるが0x5cは当然バックスラッシュ

**デフォルトの名無しさん** · 2025/12/22(月) 08:42:11.05

>>537
「正常」なだけだな。
safariも大昔からパッチ入れてるらしいぞ。
https://teppeis.はてなblog.com/entry/2014/09/safari-backslash-yen-sign

**デフォルトの名無しさん** · 2025/12/22(月) 08:42:33.96

>>536
mint でどのフォント使ってんだよ？
お前が windows からパクってきたフォントか windows 互換フォントわざわざ使ってるんじゃないの？

**デフォルトの名無しさん** · 2025/12/22(月) 09:00:03.13

>>539
さあ？特段自分では何もやってない。apt installやググってああしろこうしろをそのまま。
ただ以下見る限り、0x5cを『日本語環境では』標準で円記号に当てるようだがな。
https://forums.linuxmint-jp.net/viewtopic.php?t=1409

Archならまだしも、Ubuntuですらその程度だからLinuxも広まらないのだな。
規格ガーではなく、出来る限り馬鹿でも問題ないように最初からしとけではある。

**デフォルトの名無しさん** · 2025/12/22(月) 09:16:05.20

>>539
MintのFirefox上では https://agree.5ch.net/v/style.css によって
font-family: ArialMT, "Hiragino Kaku Gothic ProN", "繝偵Λ繧ｮ繝手ｧ偵ざ ProN W3" !important;
が当たってる。(上記のとおり、DevTools上で文字化けしてる)

Mintではターミナルでも半角円記号出るが、これが0x5cか0xa5かは分からん。
フォントは Monospace Regular 10 になってる。

泥chromeのフォントはどうやったら分かるんだこれ？
DevTools開けんし。

**デフォルトの名無しさん** · 2025/12/22(月) 10:01:52.69

>>540
それはキーボードの話な

・linux は UTF8 なので円記号とバックスラッシュをちゃんと使い分けてる
・linux はバックスラッシュを多用するけど円記号はなくてもさして困らない
・JISキーボードには円記号はあるけどバックスラッシュのキーはない、円記号のキー押すと正しく 0xA5 が入力される
バックスラッシュ 0x5C 入力したいけどどうすばいい？って問題がある

標準な解決策は

・JISキーボードなんか捨ててバックスラッシュがある US配列のキーボード買ってこい
・けちりたいなら設定だけUSキーボードにしてキートップなんか見ずにUS配列で使え
・どうしてもJIS配列が好みなら使わないキー（windows 互換にしたければ円記号キーとかでも良い）にバックスラッシュ割り当てろ、打てなくなったのはコピペなりかな漢字変換で入力しろ

みたいな話だ。円記号とバックスラッシュが同じに見える windows ユーザーは常にとまどってくだらない質問繰り返してる

**デフォルトの名無しさん** · 2025/12/22(月) 11:02:41.57

>>542
キーボードに詳しくないやつのために敢えて補足しておくと、現実には

・通常PC用として売られている日本語キーボードは純正のJIS規格配列じゃなくて改造されたOADG106キーボードで円記号とバックスラッシュは別のキーになってはいる
・でもWindowsで指が覚えてる人とかは円記号のキーを押した時にもバックスラッシュになって欲しい

linux 側でもこの辺は分かっているので対応してくれてるけどディストロとかバージョンによってデフォルトをどうするかとかの思想（日本人以外が決めてることも多い）に違いがあるかもしれない（違いが悩ましければUS配列買ってくるか自分でなんとかしろみたいな話）

キーボードとかOS内の話なので他人に影響しないので自分の好きにカスタマイズすればいいよ

**デフォルトの名無しさん** · 2025/12/22(月) 11:20:10.08

>>542-543
ちな、俺環境はUSキーボードだ。(MintもWindowsも)
そしてMintとWindowsで目に見えて違いはない。

MintでUSキーボードのバックスラッシュを押すと、ターミナルでは半角円記号になる。
(なおMonospaceフォントでは、0x5cは半角バックスラッシュ、0xa5は半角円記号らしい)
Mint側であまりバックスラッシュを使用しないのでなんともだが、
例えばDevToolsのコンソール上では問題なく動作する。(表示は半角円記号)
どこで差し替えてるのかはよく分からん。が、まあ、気にせず使える程度にはなってる。
(これはアプリ側で0xa5を0x5c扱いしてるのかも？ならこれでもいいんだが)

**デフォルトの名無しさん** · 2025/12/22(月) 12:18:57.64

>>544
その monospace フォントというのは別のフォントへのリンクで代表名みたいなものなので実態を確認しないと
どうせ mint のことだから monospace が TAKAO PGothic に設定されてるとかなんじゃね？

**デフォルトの名無しさん** · 2025/12/22(月) 12:39:35.32

PCならAlt+数値入力でコードで文字入力できるよね
マカーだからいまでも有効かはしらない

**デフォルトの名無しさん** · 2025/12/22(月) 18:43:45.60

>>545
デフォルトフォント: Ubuntu Regular
デフォルトMonospaceフォント: Monospace Regular
となってることしか分からんな。

とりあえず、
awk -v BINMODE=rw 'BEGIN{for(i=0;i<256;i++)printf("%c",i)}' | od -A x -t x1z
で確認すると、0x5cは半角円記号のフォントになってる。
ただgawkもutf8出力になってて、しかもBINMODEも何故か効かないので
0x80以降がc2,c3が付いてる2バイトコードになってて糞ウザい。
よってこの方法では0xa5のフォントは分からんが、
echo -e "\xa5" とすると、○に?、つまり多分豆腐の親戚が出る。
export LC_ALL=C してからだと0x80以降もバイナリが出てくれるが、od 出力は . だな。
0x80以降にはフォントが当たってない？らしい。

> どうせ mint のことだから
こんな事言ってるから意識高い系馬鹿のままなんだぞ。
こんなのは馬鹿に合わせる＝何も知らない人が何もしなくても苦労しないようにするべきであって、
0x5cが半角円記号なのを見たら火病で死ぬ人たちが勝手にフォントを変更すればいいだけ。
Mint日本語化グループの判断の方が正しい。