名状しがたいSSBBSのようなものお試し版

No:686 タイトル:GEAR戦士撫子新Part680 お名前:プロフェッサー圧縮投稿日:2025/12/10 08:12:25 単表示返信

とはいえ。

国産PCとて漢字用テキストビューしか持っていない訳ではありません。

ちゃんと普通のグラフィック描画用ビューも持っていました。

ただし漢字用テキストとは比べ物にならないくらい遅かったようです。

まあ原理を考えればアタリマエですわね。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

肝心のAT機との比較でも大体遅れを取ることが多かったようです。

両者ともに流石に危機感を抱いたのか様々な新技術を投入して高速化を図っていきましたが・・・・・・

パーツを入れ替えるという思想がなかった国産機は早期に限界を迎え。

そして脱落していったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

そんなこんなで。

遂に自社独自企画を諦めた国内メーカーはAT機の軍門に下ります。

まあ企業ではよくあることですが・・・・・・

諸行無常ですわね。祇園精舎の鐘の声が聞こえてくるようですわ。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

さてまあ。

大分脱線しましたが、PC本体が規格統一されたようにプリンタも規格統一されて行きました。

独自の漢字コードは廃され、共通規格に準拠するようになったのです。

もっともプリンタ側で漢字コードを漢字フォントに変換するような方式は激減し、PCからグラフィックデータとして送られてくるものをそのまま印字するようになったのは先に述べた通りとなります。

返信

No:687 タイトル:GEAR戦士撫子新Part681 お名前:プロフェッサー圧縮投稿日:2025/12/17 08:11:36 単表示返信

但し。

文章丸ごとをグラフィックデータとして送るのではなく、あくまでプリンタ側に文字フォントを持たなくなっただけで、印刷自体は文字単位で行われます。

つまり印刷する時は文章に含まれる文字フォントのみと文字コードが送られる訳です。

ビットマップとして送るより遥かに効率が良く、プリンタ側で文字フォントを形成して印刷する方式はプリンタ側にフォントを持っていた時代と互換性が高かったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

しかし。

この言ってみれば新旧合わせたハイブリッド方式は、プリンタ側にフォントを持っていた時代の欠点をも継承してしまいました。

即ち文字コード問題による文字化けです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

「いやいや使うフォントを一緒に送ってるのになんで文字化けすんの」と思いましたわね? そこの諸兄。

この問題の肝は、文章はあくまで文字コードで表されるところにあります。

つまるところが違う文字コードで解釈したら文字化けするという、至極当然の帰結なのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

実を言いますと。

プレーンテキストには文字コードを指定する方法がありません。

ですのでそのテキストを開いたアプリが何の文字コードかを判定し、時には使う者が明示的に設定してやる必要があります。

ここが間違っていると間違った文字コードで印刷してしまい、結果として見事にﾊﾞｹﾗｯﾀするという訳です。

返信
No:688 タイトル:GEAR戦士撫子新Part682 お名前:プロフェッサー圧縮投稿日:2025/12/24 07:01:59 単表示返信

ここまでを聞いて「ん?」と思った数少ないであろう勘の良い貴方。

その第六感めいたものは大事にすべきですわよ?

脳内で言語を介することなく半ば無意識に思考できるのは才能です。

磨けば将来必ず役に立つとこのわたくしが保証しましょう。

しかし漠然としたままでは駄目です。

そこから深堀りすること、それが大事なのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

閑話休題。

今回はわたくしが貴方のその漠然とした違和感を言語化して差し上げましょう。

それは「漢字コードはJISコードで事実上統一されてるんだから、文字コード違いなんか起こらんのじゃないか」ですわね?

・・・・・・まあ、わたくしの解説を聞いただけではそう思っても不思議じゃありませんわ。

勘のいい貴方なら、もうこの言い方で察しがついたんじゃありませんこと?

そう。

漢字が使える文字コードはJISコードだけではないのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

一応言っておきますが、ShiftJISはJISコードに含む扱いです。

何故かと言いますと、ShiftJIS←→JISコードはある一定の変換式だけで相互に変換でき、またこのどちらかしかないとわかっていればどっちがどっちかはすぐ判定できるからです。

しかしこれから解説するJIS以外の文字コードは一部にしか変換式が通用せず、変換のための表が必要になるからです。

そのため文字コード列だけではどの文字コードか特定するのが難しく、別途の指定が必須となってくるのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

そんなJIS以外の漢字コードですが。

現在ではほぼ2つに絞られています。

EUC-JPとUnicodeです。

返信
No:689 タイトル:GEAR戦士撫子新Part683 お名前:プロフェッサー圧縮投稿日:2025/12/31 11:34:25 単表示返信

EUC-JPはENIACに端を発する巨大コンピュータと個人用途のPCの中間に当たるワークステーション用OS・UNIXの漢字コードで、所謂サーバー系に普及しました。

対応する文字はJISコードとほぼ同等ですが、1文字のバイト数が1～3バイトと変動するのがポイントとなります。

その意味ではShiftJISより処理が面倒ではありますが・・・・・・

先頭バイトで後続があるかはすぐわかるようになってはいます。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

「大して処理変わらないならJISコードそのままでよかったんじゃないか」と思ったそこの貴方。

原理的に言えば確かにそうなのですが・・・・・・

しかしそうも言ってられないUNIX特有の事情というものがあったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

UNIXはエスケープコードという特殊文字で諸々の制御を行っていました。

界隈で有名なのは16進数表記の0x5cで、これはJISコードでは「\」を意味します。

例えば\nと書くとこれは改行コードになるのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

これの何がまずいかと言いますと・・・・・・

JIS漢字コードの一部に下位バイトが0x5cのものがあり、ちゃんと漢字モード処理をしてないとエスケープコードと勘違いして文字化けします。

先程も触れましたが、エスケープコードは改行等の制御が割り当てられていますので・・・・・・

最悪画面全体がぐちゃぐちゃになるのです。

返信
No:690 タイトル:GEAR戦士撫子新Part684 お名前:プロフェッサー圧縮投稿日:2026/01/07 08:11:37 単表示返信

表示が滅茶苦茶になるくらいはまだマシな方でして・・・・・・

一番危険なのは、コマンドラインに漢字混じりを書くことです。

特に特別な動作をする"|"(0x7c)や"{"(0x7b)がShiftJISの漢字コード2バイト目に現れることがあり、非対応だととんでもないことになりました。

EUC-JPは漢字コード全般が英数字コードに被らないようになっており、万一アプリが非対応でも致命的なことにはならないようになっていたのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

ファイル名に漢字が使えるようになったのはもっと後のことです。

一応ShiftJISでもパス区切り"/"(0x2f)は漢字の中に現れない仕様であるため、コマンドラインほどの致命的な問題はなかったとされます。

ただ、UNIXとMS-DOS(windows)では使っている漢字コードが違うため、ファイル名自体はモノの見事に文字化けします。

こればかりはしょうがないので、変換ツールを使っていたようです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

ちなみに。

テキストの中身についても同じツールで変換できるようです。

わたくしは使ったことありませんが。

もっともネットワーク越しにファイル共有されたファイルはﾊﾞｹﾗｯﾀせずに見られるのですが・・・・・・

これはどうも別の技術らしいです。

特に突っ込んで聞いた訳ではありませんけどね。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

ともあれ。

主にコマンドラインでの深刻な文字コードの衝突により、ShiftJISはUNIXでは採用されませんでした。

開発前から制定されてればまた話は違ったかもしれませんが・・・・・・

言っても詮無いことですわね。

返信
No:691 タイトル:GEAR戦士撫子新Part685 お名前:プロフェッサー圧縮投稿日:2026/01/14 07:01:57 単表示返信

という訳で。

暫くの間、文字コードはMS-DOS系(ShiftJIS)とUNIX系(EUC-JP)の二大巨頭体制が続きました。

お互い半角英数字以外の互換性は絶無でしたので、変換ツールや自動判別の技術が発展したのです。

幸か不幸かで言えば間違いなく不幸でしたが・・・・・・

まあ実情を考えれば致し方なし、ではあります。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

しかし。

ShiftJISもEUC-JPも、共通の欠点を抱えていました。

それは「後から文字を追加できない」です。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

制定当時の漢字は第一水準と第二水準の6,355文字しかないのに2バイト(65536文字分)あって余裕がないとかおかしいだろ、と思った其処の貴方。

まあパッと見おかしいですわよね。

その疑問はごもっともではあるのですが・・・・・・

実のところ、ここでも従来との互換性問題が足を引っ張っていたのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

まず第一に。

第一バイトの半分(0x00-0x7F)はASCIIとの互換性のために使えません。

これはSI/SOをなくした代わりに1バイトだけで第二バイトがある(漢字)かない(半角英数字)かを判別しなければならないためで、この時点で使える領域は半減します。

更にJIS系特有の問題として半角カナが0xA0-0xDFに居座っているためここも使えません。

このように上位バイトの使える部分ががっつり減ったため、漢字コードとして使える領域がとても狭くなったのです。

返信
No:692 タイトル:GEAR戦士撫子新Part686 お名前:プロフェッサー圧縮投稿日:2026/01/21 08:12:14 単表示返信

細かい計算を省いてざっくり言うと、JIS X 0208オンリーでのShiftJIS未定義(=空き)領域は1800文字前後です。

JIS X 0208はほぼ第一水準と第二水準漢字のみですので、人名やら地名やらを表現するには全く足りないことになります。

なので実際には、IBM拡張漢字等を含めた準標準ShiftJISであるWindows-31J(CP932)が大体使われています。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

当たり前の話ですが、拡張漢字を加えればその分空きは減ります。

Windows-31Jのユーザー拡張予約は1800バイトほどありますが、それ以外の空きはほぼ0です。

つまり後からデフォルトで追加漢字を入れる余地が全くないことになります。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

翻ってEUC-JPはと言いますと、ぶっちゃけほぼShiftJISと一緒です。

1対1マッピングが可能な時点でお察しと言うべきでしょう。

ちなみにEUC-JPの規格には一応3バイトで1文字のフォーマットが規定されていましたが・・・・・・

互換性の問題でほぼ実装されませんでした。

なのでないのと一緒です。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

と、言う訳で。

ShiftJISもEUC-JPも、後から漢字を追加する余地はほぼありませんでした。

しかしながらJIS X 0208は漢字全てを網羅してるなどとは口が裂けても言えません。

制定当時ですら第三水準・第四水準漢字の検討が始まっていたのです。

近い将来問題になるのは目に見えていたのです。

返信
No:693 タイトル:GEAR戦士撫子新Part687 お名前:プロフェッサー圧縮投稿日:2026/01/28 07:01:52 単表示返信

しかしながら。

問題が認識されつつも、5年位ShiftJISは最前線の漢字コードでした。

これにはいくつか理由があったようですが・・・・・・

身も蓋もない事を言うと、「PCはまだまだ個人のおもちゃ」だったからです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

ShiftJIS登場以前から、ワープロ等の漢字印刷マシンは存在していましたが・・・・・・

第三水準以上の「外字」が必要な住所氏名は、公的文書であれば自分で署名するか判子を押すのが主流でした。

つまり外字が必要な文字を印刷する必要に迫られてなかったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

無論、魑魅魍魎等の第三水準以上が求められる小説等には対応できませんが・・・・・・

そういう大規模印刷物は当時活版印刷であり、文字コードなどほぼ関係ありませんでした。

原稿もそれこそ400字詰原稿用紙に手書きでしたから。

どうしても第三水準以上が必要、という場面は言うほどなかったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

ついでに言いますと。

国産PCは海外で大して売れなかったので、JIS X 0208に入っていない非漢字特殊文字に対応するニーズがほぼありませんでした。

その意味でも、多少の個人レベルの不満を我慢さえすれば、ShiftJISでもそれなりに使えていた環境であったのです。

返信
No:694 タイトル:GEAR戦士撫子新Part688 お名前:プロフェッサー圧縮投稿日:2026/02/04 07:02:29 単表示返信

風向きが変わったのはインターネットの誕生です。

インターネットによりサーバーサイドに日本語対応の必要が生まれ、EUC-JPの普及を後押ししました。

元々のインターネットは個人のものではないため、漢字コードの使用頻度が劇的に上がりました。

──つまり、第一第二水準で十分等とは言ってられなくなったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

という訳で。

JIS X 0208からおよそ10年ぶりに、新しい文字コード制定の機運が高まりました。

そしてShiftJIS制定メンバー+αが集まって、文字コード制定団体を立ち上げます。

The Unicode Consortium.

サーバーもPCも関係なく、『一つの統一文字コード』が遍く広まった世界を目指す挑戦が始まったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

とは言うものの。

既に普及しているJISやEUCを無視するのは現実的ではありません。

特にASCIIコード域は一種の聖域になっており、ここを無視してはあらゆるコンピュータで動かなくなります。

ですので例によって、0x7Fまでは据え置きとなりました。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

但しそれ以外には大鉈が入りました。

上位領域に居座っていた半角カナやら制御コードをばっさり蹴り出して、特殊漢字として漢字領域にぶち込んだのです。

ここはShiftJISとEUC-JPで非互換の部分だったので、新しい文字コードが互換性なくとも今更であったのです。

返信
No:695 タイトル:GEAR戦士撫子新Part689 お名前:プロフェッサー圧縮投稿日:2026/02/11 16:10:34 単表示返信

その御蔭でUnicodeは予約領域約2000字以外の6万3千文字近くを割り当てることが出来ました。

第四水準までの漢字数は1万字ちょいなので、計算上は全ての漢字を網羅できることになります。

しかし。

実際にはそうはなりませんでした。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

何故か? と言いますと・・・・・・

単純にタイミングの問題でした。

最初のUnicodeはJIS X 0208に対応することを目標にしており、第三水準以降は後の改定に回されました。

と言いますのも、Unicode制定の1991年では第三水準以降の規格が出来ていなかったからです。

これら拡張漢字はこの時点ではメーカー独自拡張であり、工業規格ではなかったのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

とは言うものの。

最初から2バイトを想定していたUnicodeはまだまだ余裕があり、規格が制定され次第割当ればいいと誰もが楽観的に考えていました。

しかし。

Unicodeの普及が進むに連れ、思わぬ伏兵が名乗りを上げてきたのです。

　　　　　　　　　　◇　　　　　　　　　　◇　　　　　　　　　　◇

それはアラビアやベトナム、果てはハングルや日本に輸入されていない中国漢字等でした。

Unicodeはその名の通り「世界統一符号」をお題目に掲げていましたので、断れるはずもなかったのです。

返信