掲示板に戻る
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に居座っているためここも使えません。

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