文字コード総合スレ part14

**デフォルトの名無しさん** · 2023/03/03(金) 15:46:58.08

Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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 https://mevius.5ch.net/test/read.cgi/tech/1516629503/
文字コード総合スレ Part12 https://mevius.5ch.net/test/read.cgi/tech/1544931495/
文字コード総合スレ part13
https://mevius.5ch.net/test/read.cgi/tech/1593777227/

**デフォルトの名無しさん** · 2023/06/27(火) 00:39:10.68

文字コードポイントとそのエンコーディングの区別ができてやつがいるな
例えばUTF8の0xE3 0x81 0x82を文字コードポイントとは言わない
あくまでも文字コードポイントはU+3042であり0xE3 0x81 0x82はUTFでエンコーディングした時のバイト列にすぎない

**デフォルトの名無しさん** · 2023/06/27(火) 01:24:36.76

>>382
+ の後ろを coded character set 「符号化文字集合」とした方がより良いな

**デフォルトの名無しさん** · 2023/06/27(火) 07:10:50.09

>>384
codedじゃ誤解しそうな人が出るので
numberedを付けるかどうか迷った

**デフォルトの名無しさん** · 2023/06/27(火) 09:02:31.09

>>385
規格によって用語の意味が違うので難しいところだねインターネットのRFCとかだと正式用語は
code character set + character encoding scheme
それぞれCCSとCESと略されることもある
一般的な日本訳は「符号化文字集合」と「文字符号化方式」かな

**デフォルトの名無しさん** · 2023/06/27(火) 09:03:47.40

>>386
dが抜けた。coded character set ね

**デフォルトの名無しさん** · 2023/06/30(金) 18:08:26.89

>>383
お前は文字コードとエンコードの区別はついているか？

**デフォルトの名無しさん** · 2023/07/01(土) 03:56:24.34

数学の写像だと考えればいいのでは

**デフォルトの名無しさん** · 2023/07/11(火) 16:13:44.17

てすと🌀🌀

**デフォルトの名無しさん** · 2023/07/27(木) 22:11:05.51

𝕏

**デフォルトの名無しさん** · 2023/07/28(金) 00:23:42.06

ﾌﾌﾌ

**デフォルトの名無しさん** · 2023/07/28(金) 00:51:45.87

文字コードって誰が作ってんの？

**デフォルトの名無しさん** · 2023/07/28(金) 02:16:49.64

>>393
誰が作っても良い。他人に使ってもらえるかは知らんが

**デフォルトの名無しさん** · 2023/07/28(金) 02:28:54.58

俺用の文字コードを作れば、漏洩して悪意ある他人が見ても文字化けで意味不明ってことか。

**デフォルトの名無しさん** · 2023/07/28(金) 19:41:58.97

まず13文字ずらします

**デフォルトの名無しさん** · 2023/07/29(土) 08:13:24.61

おおジュリアス・シーザー

**デフォルトの名無しさん** · 2023/07/29(土) 14:26:21.89

カエサル派にとっては意味不明ってことか。

**デフォルトの名無しさん** · 2023/08/04(金) 14:46:46.47

コードずらしただけだと出現頻度でばれるって話

**デフォルトの名無しさん** · 2023/08/04(金) 18:06:48.16

－・　・・－　・－・・　・－・・　・－－・　－－－

**デフォルトの名無しさん** · 2023/08/18(金) 15:49:14.73

macOS上の話ですが、'が’という名前のフォルダを作ってその名前をシェルで見ると

% ls | iconv -f utf-8 -t utf-16le | od -x -A n
304b 3099 000a

% echo * | iconv -f utf-8 -t utf-16le | od -x -A n
304c 000a

あれ、もしかしてシェル (zsh) がUnicodeの合成をしている?

**デフォルトの名無しさん** · 2023/08/18(金) 23:53:14.80

bashでやると元のままでコマンドを外部コマンドにしても変わらないから
globがそういう動作なんやね

**デフォルトの名無しさん** · 2023/08/19(土) 00:16:00.94

正確に言うと MacOS の zsh のグロブだな。

**デフォルトの名無しさん** · 2023/08/19(土) 01:35:51.14

>>403
もしかしてmacOS上以外のzshだと挙動が違ったりします?

**デフォルトの名無しさん** · 2023/08/19(土) 02:04:07.40

>>404
違う

**デフォルトの名無しさん** · 2023/08/19(土) 10:09:35.79

>>405
確かに、zshのソースを見てみたらMac上だとファイル名を加工する処理が入ってました:
https://github.com/zsh-users/zsh/blob/master/Src/utils.c#L5169

**デフォルトの名無しさん** · 2023/08/19(土) 10:21:56.98

が、果たしてそれはいい事なんだろうか。小さな親切大きなお世話という気もしないでもない

皆さんご存知macOS上のFSはファイル名がUnicodeの分解形になっているのだが、
上記により、シェル内でワイルドカードを使うとファイル名が合成形で得られる
その後、そのファイル名を加工して別のファイルを作ると、合成形でファイルが作られること
になる（macOSのUNIXレイヤーではパス名を分解形にすることは強制ではない）

結果、分解形のファイル名と合成形のファイル名がコンタミするではないか、と

**デフォルトの名無しさん** · 2023/08/19(土) 10:44:11.66

>>407
macOS には HFS+ と APFS というのがあってだな。

**デフォルトの名無しさん** · 2023/09/18(月) 15:14:20.26

awkが新しくなる！？本家AwkがUnicode (UTF-8)とCSV対応に！
https://qiita.com/ko1nksm/items/1a3e711bbd925657f5fd

やっぱりUTF-8に対応するにはアプリ側を修正しなきゃいけないって事ね

**デフォルトの名無しさん** · 2023/09/18(月) 17:45:11.83

>>409
そもそも、そういう用途は nawk じゃなくて gawk とか使ってるので今更 nawk が対応したと主張したところで意味無し
nawk は文字とバイトの区別すらついて無かった古典だし。POSIX？それ美味しいの？状態だったのがようやく今頃になって対応始めた感じ。まだ問題だらけなので文字コード区別必要な場面での使用は非推奨。

**デフォルトの名無しさん** · 2023/09/21(木) 17:13:01.39

事故の予感しかしない

**デフォルトの名無しさん** · 2023/10/05(木) 21:37:01.18

全ての開発者が知っておくべきUnicodeについての最低限の知識
https://gigazine.net/news/20231005-unicode/

**デフォルトの名無しさん** · 2023/10/06(金) 02:09:53.00

互換漢字のことを思い出してもいいですか

macOSのFinderで神というフォルダーを作ると神に変換される
Chrome上で神を検索すると神と神の両方にマッチする
Firefox上で神を検索すると神にはマッチしない
Firefox上で分解形の神︀で検索すると合成形の神にはマッチしない
Mozcで神︀を入力すると分解形がデフォ

みんなちがって、みんないい?

**デフォルトの名無しさん** · 2023/10/06(金) 09:13:41.28

おはよう
今起きたけど、UTF-8にBOMつけるか否か？結論は出た？

**デフォルトの名無しさん** · 2023/10/06(金) 09:59:40.01

UTF-8にBOは存在しない
↓
BOMなんて概念が不要

議論も何も無い

**デフォルトの名無しさん** · 2023/10/06(金) 11:34:57.64

>>413
>macOSのFinderで神というフォルダーを作ると神に変換される

このあたり、Appleには素のNFDとは少し違う独自の正規化を使うこだわりが
あったのだと思っていたけど、今は違うのかな?

**デフォルトの名無しさん** · 2023/10/06(金) 14:17:35.44

>>415
元来の用途で使う可能性が無いからこそ新しいより有用な目的を割り当てて使えるのですね

**デフォルトの名無しさん** · 2023/10/06(金) 17:44:51.54

>>415
お前が世間知らずなだけ
エディタでbomありutf8は普通にサポートされてる
当然これは需要があるから

**デフォルトの名無しさん** · 2023/10/06(金) 18:03:58.96

Firefoxの検索は半角カナの同一視もしてくれないからなあ

**デフォルトの名無しさん** · 2023/10/06(金) 21:14:36.66

How can I get WideCharToMultiByte to convert strings encoded in UTF-16BE?
https://devblogs.microsoft.com/oldnewthing/20231005-00/?p=108854

UTB-16BEからShift_JISに変換したいとかいろんな要望があるものだな

**デフォルトの名無しさん** · 2023/10/06(金) 21:24:18.57

>>415
正確には「UTF-8にバイトオーダーの違いはない」だな。

**デフォルトの名無しさん** · 2023/10/06(金) 22:08:49.33

JSONなどBOMを付与して送信してはいけないと明確に規定されていたり
BOMを取り扱わない規定やソフトウェアもあるため
UTF8ではBOMを付与しないほうが好ましい

**デフォルトの名無しさん** · 2023/10/06(金) 22:54:13.21

JSOINファイルに付けるなとは言ってないみたいよ

**デフォルトの名無しさん** · 2023/10/06(金) 23:20:11.94

#!shebangの邪魔になるだろ

**デフォルトの名無しさん** · 2023/10/07(土) 09:59:00.66

>>424
BOMを認識するようシステムコールを改修すればいいだけ
それをしないのはOS開発者の怠慢

**デフォルトの名無しさん** · 2023/10/07(土) 10:25:02.17

>>413
macOS/iOSのSafariではひらがなとカタカナを同一視するという挙動があるようで
みんなちがって、みんないいw

**デフォルトの名無しさん** · 2023/10/07(土) 10:55:59.28

>>425
execve の引数解釈が locale に従うのであれば BOM を付けるべきではない状況に該当すると思う。

**デフォルトの名無しさん** · 2023/10/07(土) 19:44:18.39

BOMなしがいいってのはAsciiしか対応してないレガシーソフトウェアに通したいから？
UTF8を意識できてるならBOMのありなしの両対応は簡単だし

**デフォルトの名無しさん** · 2023/10/07(土) 20:50:45.55

>>428
ファイルの接続とか分割にゴミ処理とかしないですむ。自分がいまから出力するのが先頭かどうか不明とかでも問題は起きない
ファイルの先頭とかには別の識別子置きたいアプリもある。先頭BOMが優先して使えるとか思い上がり。
そして何より、世の中すべて UTF-8 で情報交換すべきで、他の文字コードは内部コード以外は認めない。滅べば良いと本気で信じてるので BOM に使いみちなんかない。
だいたい最近の欧米の主張はこんな感じ。

**デフォルトの名無しさん** · 2023/10/07(土) 21:50:44.31

UTF8こそが不要で滅べば良い。I

**デフォルトの名無しさん** · 2023/10/08(日) 05:39:53.69

これからの時代は UTF-32

**デフォルトの名無しさん** · 2023/10/08(日) 05:43:54.93

なぁに。1バイトを32bitにしてしまえばエンディアンがどうのなどとつまらない事を考える必要もなくなる。BOMも不要。

**デフォルトの名無しさん** · 2023/10/08(日) 05:46:34.19

いいかげんチマチマと8bitづつ扱うようなケチな精神がいけない。
8bit CPU の事などもう忘れろ。

**デフォルトの名無しさん** · 2023/10/08(日) 12:38:49.49

>>431
文字結合あるからUTF32でも解決しない
結局可変ならUTF8が合理的という考え方もある

**デフォルトの名無しさん** · 2023/10/08(日) 13:46:55.09

>>434
つまり UTF1024 が必要ということだな

**デフォルトの名無しさん** · 2023/10/09(月) 13:08:59.15

えっ

**414** · 2023/10/09(月) 14:11:34.76

ふーん

結局UTF-8にBOMつけるか否か？まだ結論は出てないんだな？
じゃあ、今からまた寝るから結論出たら教えて…おやすみ

**デフォルトの名無しさん** · 2023/10/10(火) 07:39:18.70

結論は出ない、永遠に寝てろ

**デフォルトの名無しさん** · 2023/10/10(火) 08:43:04.58

結論も何も最初から規格上は「つけないことを推奨」。規格を無視するやつらは勝手につけてるだけ。
これ以上何に結論を出せと？

**デフォルトの名無しさん** · 2023/10/10(火) 09:13:29.30

禁止はしてないな。いくつか使用すべきではない状況はあるがそれ以外必要に応じて使ってよい。
まあいずれEUCと同じように淘汰はされていくと思うが。

**デフォルトの名無しさん** · 2023/10/11(水) 14:25:41.16

拡大解釈を結論としちゃうとそりゃ永遠に終わらんよな

**デフォルトの名無しさん** · 2023/10/11(水) 16:29:14.72

もう恥ずかしいからやめろよ

**デフォルトの名無しさん** · 2023/10/11(水) 16:32:12.66

文字コードの自動判定でBOMが欲しいんでしょ
だったら日本人的には当面ありの方がいいんじゃないの

**デフォルトの名無しさん** · 2023/10/11(水) 17:54:36.20

まじで文字コード判定でBOM必要とするなんてExcel以外にしらんし
他にならって決め打ちか失敗前提で推測する実装にしとけばこんなことにはならなんだ

**デフォルトの名無しさん** · 2023/10/11(水) 23:59:31.72

>>443
今はネット通信もローカルもUTF8を使うのが普通だからBOMは要らない
HTTPやHTMLならそこで文字コード指定できるし

**デフォルトの名無しさん** · 2023/10/12(木) 21:40:02.12

UTF8を使うのが普通だったりエンコーディングを指定できる所ばかりじゃないんだからBOMがあるのは仕方ない

**デフォルトの名無しさん** · 2023/10/12(木) 22:03:04.02

>>444
まさにExcelのためにBOM付けてる

>>445
早くWindowsのシステムロケールが標準でUTF-8になれば良いな

**デフォルトの名無しさん** · 2023/10/12(木) 22:26:37.40

visual studioもbom必要
設定でutf8指定したら不要だけど
外部のソースまでutf8前提になるので踏み切れない

**デフォルトの名無しさん** · 2023/10/12(木) 23:49:07.23

いわゆるWindows PowerShell（5.x系）も、日本語を含むスクリプトの場合は BOM付きUTF-8 で保存する必要がある

文字コード、改行コード（何らかのデミリタ）に関わる問題は果てしなく続く
そして、文字数カウント問題も...

**デフォルトの名無しさん** · 2023/10/13(金) 08:42:04.37

>>447
Mac, iPhone も Linux, android も BOM なし UTF8 オンリーで、十分いけてることを考ええると、
UTF8にBOM必要とかいってるやつも、日本語 Windows の system locale が UTF8 なったら手のひら返すだろうね

**デフォルトの名無しさん** · 2023/10/13(金) 09:08:31.59

必要だから使っているだけで、必要なくなったら使わなくなるだけ。
手のひら返すって発想が出るのはこれをなにか派閥争いや宗教的対立ととらえているんだろうな。

**414** · 2023/10/13(金) 09:49:50.49

みんなうるさいなぁ…全然寝れないじゃん！
結論は出ない…という結論が出てるんだから
もうみんな静かにしといて欲しいわ

ホントの結論が出たら起こしてねｗ

**デフォルトの名無しさん** · 2023/10/13(金) 09:59:16.16

UTF-8にBOMは不要だがBOMを要求する出来の悪いアプリが存在するというだけの話
アプリを修正すればいいだけなのに出来の悪い子のためにBOM付きファイルを広めようとするから迷惑がられる

**デフォルトの名無しさん** · 2023/10/13(金) 20:19:14.08

こう、「出来の悪い」とか要らん煽りをちょいちょい挟んでくるのがな

**デフォルトの名無しさん** · 2023/10/13(金) 21:36:36.55

環境のCPのエンコーディングとUTF-8を両対応したくてBOMを導入した設計は偏狭
専用の閉じたデータなら勝手にどうぞだけどCSVファイルだよ
出来が悪いにもほどがある

**デフォルトの名無しさん** · 2023/10/13(金) 22:08:36.81

一応Unicode規格に定められた仕様なわけだがそれを正しく実装しても出来が悪い呼ばわりするわけだな

**デフォルトの名無しさん** · 2023/10/13(金) 23:15:47.89

CSVファイルの一般的書式 (RFC4180 日本語訳)
http://www.kasai.fm/wiki/rfc4180jp

CSVファイルにBOM付けるな、なんてどこに書いてあるんだよ

**デフォルトの名無しさん** · 2023/10/14(土) 00:20:16.97

>>457
ABNF表記

そのRFCはメジャーではないし従う必要もないけどね

**デフォルトの名無しさん** · 2023/10/14(土) 12:58:12.11

VC++はコンパイルオプションでBOM無し通るようになったから許す

**デフォルトの名無しさん** · 2023/10/14(土) 23:17:30.52

あ、そうか。UTF-8なのにBOM入りにする理由はコードの自動判別のためか。

**デフォルトの名無しさん** · 2023/10/15(日) 01:20:23.94

>>460
Windows は文字コードの指定がないとシステムロカールに設定されている文字コード（日本語WiIndows11だとCP932=SJIS)という約束になっていて、これを変更せずに UTF－8 を使いたいがための苦肉の策だった(過去形）。
最近はマイクロソフトはこの約束を破棄して標準を UTF－8 にするよう要請してるし、将来システムロケールのデフォルトを UTF－8 に変更することは確実なので、単なる経過措置。

**デフォルトの名無しさん** · 2023/10/15(日) 01:39:21.51

メモ帳のデフォルトの文字コードは、BOM付きUTF-8

**デフォルトの名無しさん** · 2023/10/15(日) 02:16:16.57

>>462
もう今は BOM なしがデフォ
BOM 付にする場合は格納する時に明示的に選ぶ

**デフォルトの名無しさん** · 2023/10/15(日) 10:20:43.11

「メモ帳」に多数の改善、BOMなしUTF-8がデフォルト保存形式に～「Windows 10 19H1」
https://forest.watch.impress.co.jp/docs/news/1157696.html

**デフォルトの名無しさん** · 2023/10/15(日) 11:24:00.22

「UTF8はBOMを付けない」
これでWindows以外は統一されている
WindowsでもBOMなしが標準になりつつある
大勢は決した

**デフォルトの名無しさん** · 2023/10/15(日) 12:36:43.97

ExcelがBOM無しCSV/TSVを文字化けせずに読み込んでくれたら解決しそうw
自慢？のcopilot使ってもいいからさっさと解決しろやーw

**デフォルトの名無しさん** · 2023/10/15(日) 13:03:46.10

>>466
今でもシステムロカールを UTF8 に切り替ええると BOM なしで読める。システムのデフォルトを SJIS に設定しているから BOM なしを SJIS とみなしてるだけ。

**デフォルトの名無しさん** · 2023/10/15(日) 14:10:15.45

>>467
今のExcelの挙動の方がOSの設定を反映してて行儀良いとも言える
WindowsがUTF-8で統一されるには、まずはWindowsのシステムロケールの規定値がUTF-8にならないことにはな

**デフォルトの名無しさん** · 2023/10/15(日) 15:48:50.38

>>468
その通りなんだが、マイクロソフト自身がそこを翻して、今後は外部文字コードはシステム設定にかかわらず UTF8 にするようにプログラマー向けのガイドで推奨している。
時代は変わったというやつだな。

**デフォルトの名無しさん** · 2023/10/15(日) 21:43:34.82

General Unicode requirement in INF files
https://learn.microsoft.com/en-us/windows-hardware/drivers/display/general-unicode-requirement

INF files should be saved and encoded as Unicode (UTF-16 LE); they must not be ANSI or UTF-8.

**デフォルトの名無しさん** · 2023/10/15(日) 23:29:04.23

話してるのは交換用のデータ
そういうレガシーな閉じたデータは困んないし関係ないよ

**デフォルトの名無しさん** · 2023/10/16(月) 00:06:18.56

Microsoft は、UTF-8 BOM 無しを推奨する理由として「Web アプリや Unix 系の OS が UTF8 BOM 無しなので、文字コード関連のバグを最低限にするためには UTF8 は BOM なしである必要がある」と主張している。
この主張を元に PowerShell とかの基幹アプリもデフォルトを BOM 無しに移行した。
今はもう UTF-8 BOM つきを推奨するメジャー組織は存在しない。

**デフォルトの名無しさん** · 2023/10/16(月) 00:53:41.28

ハナっから「推奨」していた組織など存在しない

**デフォルトの名無しさん** · 2023/10/16(月) 09:54:20.88

Windows/MS がさっさと間違いを認めれば良いだけ

**デフォルトの名無しさん** · 2023/10/16(月) 11:23:36.19

>>473
マイクロソフトは昔はプログラマ向けにBOMつけることを推奨してたんだよ。ツールとかも勝手にBOMを追加していた。
そもそもユニコード規格で UTF8 のBOMが文字コード判別用として規定されたのもマイクロソフトの主張によるもの。
他の企業とかは反対だったけどMSが強く主張するので、妥協として非推奨という形で規格に取り入れられた。

**デフォルトの名無しさん** · 2023/10/16(月) 15:03:12.56

RFC3629の日本語訳
UTF-8, ISO 10646 を変換したフォーマット
https://www.akanko.net/marimo/data/rfc/rfc3629-jp.txt

プロトコルはが常にUTF-8であるなら、そのような場合シグネチャ機能は完全に無駄であるので、そのプロトコルが命令するそれらの原文のプロトコル要素のためのシグネチャとしてU+FEFFの使用を禁止【すべき】(SHOULD)である。

プロトコルは、それらの原文のプロトコル要素、プロトコルの実装が常に適切にメカニズムを使う立場にあることが予測されるとき、そのプロトコルが文字符号識別メカニズムを供給するためのシグネチャとしてのU+FEFFの使用を同じく【禁じるべき】(SHOULD)である。これは、プロトコル要素がそれらの作成時からそれらの適切に分類される伝送の時間まで実装の制御下にきつく維持されるケースであろう。

禁止が不可能、あるいはプロトコルの実装がメカニズムを常に適切に使う立場にないことが予測される時には、プロトコルは、文字符号化識別メカニズムを提供しないそれら原文のプロトコル要素のためのシグネチャとしてU+FEFFの使用を禁じる【べきではない】(SHOULD NOT)。後者2ケースでは、特にプロトコルの実装が、そのような要素を、ファイルシステム、ペイロード(FTPなど)のための符号化識別メカニズムを持たないプロトコル、または文字符号化の適切な識別を保証しない他のプロトコルから得る時のMIME要素(HTTPなど)など、より大きいプロトコル要素で起こりそうだ。

**デフォルトの名無しさん** · 2023/10/16(月) 22:51:46.46

>>472
UTF8のBOM付きは古いローカル環境のファイルを除いて世の中から消滅だね

**デフォルトの名無しさん** · 2023/10/17(火) 21:20:13.70

いずれ消滅はするだろうね。今すぐにではないだろうけど。

**デフォルトの名無しさん** · 2023/10/20(金) 01:51:40.88

以下のウェブページ、ちゃんと表示されます? 自分の環境ではところどころ文字化けが

新JIS漢字で包摂の扱いが変わる文字
https://www.aozora.gr.jp/newJIS-Kanji/gokan_henkou_list.html

**デフォルトの名無しさん** · 2023/10/20(金) 02:19:51.80

Shift_JIS-2004にするとemacsでは見れるっぽいな

**デフォルトの名無しさん** · 2023/10/20(金) 02:31:11.04

>>479
ページのデコード（文字コード）の問題っぽいので、現代のブラウザでそれらの文字を正しく表示するのは不可能な気がする
少なくともChromiumにはページの文字コードを指定して読み込む機能はない（かなり前に失われた）

**デフォルトの名無しさん** · 2023/10/20(金) 05:05:07.19

>>481
なるほど
試しにソースをUTF-8に変換してみたら問題ないっぽいので、そこに書かれているような
UCSのコードポイントがないだとか拡張されたフォントが必要だとかそういうのも
昔話くさいですね。関係者の皆様(?)ご苦労様でした