文字コード総合スレ Part12
■ このスレッドは過去ログ倉庫に格納されています
簡単な用語定義 (※元々は ISO における用語、後に Unicode にも取り入れられた) ユニコード・コンソーシアムが定めている文字コードを「Unicode」という 国際規格委員会が ISO-10646 で定めている文字コードを「UCS」という 国際規格 UCS を 32 bit 固定長で符号化したものを「UCS-4」と呼ぶ 国際規格 UCS の BMP だけを 16 bit 固定長で符号化した簡易実装を「UCS-2」と呼ぶ(後に廃止) 第一次国際規格(1993年)の付録に定められた UCS の 8-bit 可変長符号化を「UTF」(UCS 変形フォーマットの意味)と呼ぶ(後に廃止) 国際規格の追補(1996年)で追加された UCS の 8-bit 可変長符号化を「UTF-8」と呼ぶ 国際規格の追補(1996年)で追加された UCS のサロゲートペアを用いた 16-bit 可変長フォーマットを「UTF-16」と呼ぶ 備考 UCS-2 は Unicode 1.1 とほぼ互換になるように定められた UTF-16 は Unicode 2.0 (サロゲートペア有)と互換になるように定められた 後に定められた「UTF-32 」と UCS-4 は実質的に同じもの UTF は UTF-8 と区別するために UTF-1 と呼ばれるようになった UTF-8 は規格化される前は FSS-UTF とか UTF-2 などと呼ばれていた 以上の用語定義で UTF-8 導入の経緯は Unicode はもともと内部 16 bit、外部 16 bit の使用法を前提にしていたが、国際規格では内部 32 bit、外部 8 bit可変長で実装することも想定していた。 このための外部用 8 bit 可変長文字コードとして最初に提案されたのが、UTF (UTF-1) 方式。 だだこの UTF-1 方式は Unix のファイル名等に使えないという欠点があっったので、すぐに改良版の FSS-UTF (UTF-8) 方式が提案され、そっちで実装が進んだ。 第一次規格(1993年)では時間的に変更が間に合わなくて UTF-1 方式の方が規格書の付録に記載されたが、後から追補(1996年)によって UTF-1 方式と UTF-8 方式を入れ換えた。 UTF-8の祖先にUTF-1があるから歴史が古いんだと言えるなら、同じ論理で UTF-16の祖先にUCS-2を直接使用する原ユニコードがあるとも言えるんじゃね? UTF-1 があるから歴史が古いなんて言ってる人いないけど、どこ見てるの。 UTF-1 のすぐ後に UTF-8 が提案されてて間は1年もないよ。寝惚けてるの? 論点はそこじゃなくてUTF-8はUnix系でUTF-16に対応できなかったから しかたなく作ったものだって話だろ 外部が作って後からUnicodeに追加された仕様 あきらめろ。 UTF-8 は Unicode ではなく UCS 用に作られた。 UTF-8 は欠陥のある UTF−1 の代わりにするために作られた。 UTF-8 が考案された時には UTF-16 は影も形も無かった。 >>155 だから、それが間違いって指摘してるんだが >>157 UTF-8が開発された経緯 https://www.cl.cam.ac.uk/ ~mgk25/ucs/utf-8-history.txt > UTF-8 was designed, in front of my eyes, on a > placemat in a New Jersey diner one night in September or so 1992. UTF-8は1992年9月に私の目の前で設計された > We had used the original UTF from ISO 10646 > to make Plan 9 support 16-bit characters, but we hated it. Plan 9で16ビット文字をサポートするためにISO 10646の オリジナルのUTFを使用していた が私たちはそれを嫌っていました。 > However, UCS and its UTF variant do not protect > null bytes and/or the ASCII slash ("/") making these character encodings > incompatible with existing Unix implementations. しかしUCSとその亜種であるUTFはヌル文字とスラッシュを保護せず 存在するUnixの実装と互換性がありません。 >>158 そこに書かれている original UTF というのは UTF-1 のことで UTF-16 のことじゃないぞ。 ちゃんと理解できてるか? だからUnicodeに対応するためにUCS-2ではなくてUTF-1を使ってたんだろ UnixがUCS-2に対応するのは現実的に不可能だったから >>156 > UTF-8 が考案された時には UTF-16 は影も形も無かった。 UTF16の直接の先祖のUnicode1.0の符号化方式が厳然と存在してるのに影も形もないはないな >>160 だから、それ、お前の妄想だろ。不可能とかどこにも書かれてない。 実際やろうと思えばできる。素人じゃあるまいし。Ken って誰だか知ってるか? ただ、互換性がないから嫌っていたという話。 Windows とかはしょちゅう非互換な変更を加えるけど、Unix とかは文化として相互の協調動作を重視するんだ。 それで、可能な限り非互換な変更を避けようとする、仕方がない場合にはやるけど。 実際問題 Plan-9 には UCS-2 と UTF-1 の両方が既に開発済みで、リリース間近だった。 ちょうど、その時に X/Open comitee の人から電話がかかって来て、UTF の改良について相談されたので、速攻でより互換性の高い新しい符号((UTF-8)を設計して提案したという話。 >>161 そんな見苦しい言い分けしても、お前の間違いはごまかせないんだぜ。 お前の間違いってどれよ、挙げてみwwwお前が思ってるお前の発言は多分俺の発言じゃないから 一人を相手にしてると思ってるなら大間違い >>162 書いてある > However, UCS and its UTF variant do not protect > null bytes and/or the ASCII slash ("/") making these character encodings > incompatible with existing Unix implementations. しかしUCSとその亜種であるUTFはヌル文字とスラッシュを保護せず 存在するUnixの実装と互換性がありません。 >>165 互換性がないとしか書いてないようだが? だからOSの方を書き換えるのが現実的に不可能だったんだろ >>162 > Windows とかはしょちゅう非互換な変更を加える これって何のギャグよ 互換性がないから嫌いとしか読めん 現実に各社 Unix でも Linux でも UTF-16 実装してるんだよなあ。 不可能とは? 不可能なのは各コマンドをUTF-16対応にすること なんで? プログラムと API を書き換えれば、普通にできるよ。 実際 Windows はそれをやったわけだし。 >>171 Mivrosoft は愚直に全てのプログラムを書き換えた。 UNIX陣営は UTF-8 を発明して、その手間を大幅に省いた、天才。って話だわな。 >>171 永遠の時間があればできるだろうなって話 Windows NTは最初のバージョンからUnicode対応だった 逆だろ、Unicode 対応のために DOS-FAT から NTFS に非互換な変更したってだけだろ。 DOS-FAT はあまりにもダメダメなので、他の理由でも置き換えるのが必須だったので決断は簡単だった。 一方 UNIX 系の FS は FAT に比べれば良くできてたので、置き換える意欲に乏しかった。 DOSは最初からSJISなんていう、これまたUnix系では(完全に)対応することができない 文字コードに対応してるわけでその理屈はおかしい 更に言うなら1995年に発売されたNT3.5(NT系としては2つ目のバージョン)に 搭載されているFATは長いファイル名をサポートし文字コードはUTF-16を使う https://en.wikipedia.org/wiki/File_Allocation_Table#Long_file_names > One of the user experience goals for the designers of Windows 95 was > the ability to use long filenames (LFNs?up to 255 UTF-16 code units long) DOS-FATなんて使われてない用語を使ってるのは、印象操作でも目論んでるようにしか見えないが FATの正統後継であるexFATは今も使われてるしSDカードの標準のファイルシステムとして公式採用されてる だめだめの部分がなにか知らんがとっくに改良されておりよくできたファイルの一つとなってる お前はネットで検索した情報を知ったかする前に、まずは時系列順に並べ替えてみろ。 >>177 それはお前がやるべきことだ なぜ俺が不利になる(?)ようなことを 俺がわざわざ調べないといけないんだw 反論があるならお前がしろ 自分が反論できないからって相手に反論の 材料を探させるという間抜けをするな やるわけねーだろアホw ちゃんと調べれば自分が間違っていることに気づくぞ、というアドバイスなんだが。 不都合な真実は知りたくないというのなら、永遠に間違って理解してろ。 残念ながらお前は技術者には向いてないんだろうと思う。 ANSI文字列を扱うAPIをいまだに保守し続けているWindows デフォルトエンコーディングをEUCから突然UTF-8に切り替えたunix 互換性を軽視しているのはどちらでしょう >>179 調べてた結果正しかったです。調べたくない人が事実を知りたくないだと思います(笑) 調べなくても、その辺の時系列はよく知ってるんだよ。当時、リアルタイムでおっかけてたので。 時系列誤解して、知ってるやつなら絶対に間違えないレベルの主張してるのがいたので指摘しとこうかと思っただけ。 お前は知りたくなければ知らなくて良いよ。 十分に事実は書いたので、後から奇特にもこのスレ覗きに来て、お前の妄言に惑わされる奴もいないだろうし。 p.s. 上から目線なのはジジイなので許せ。 >>180 その unix とやらの具体的で正式な OS の名称を教えてください… しょっちゅう非互換な変更を加えるWindowsって具体的にはどれの事よ https://docs.microsoft.com/ja-jp/archive/blogs/nakama/win10waas-part5a カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ないと思います。 Windows 7 で動作していた .NET 3.5 のアプリのほとんどは、Windows 10 上の .NET 3.5 でもまず十中八九動作するはずで、 先行検証しているあるお客様からは、「まるで非互換問題が出てこないんだけれども、名前だけ変えてお金稼ごうとしてない?」とか言われたことがあるぐらいです;。 >>185 マイクロソフトは互換性が高いと主張しています。それは事実だと思いますが それでも断定はできないし保証はできないので検証は必要です。 ただしお客様の方で検証していただければお金は不要です。 問題があった場合は有償でサポートしますが対応に時間がかかることがあるので 余裕を持ったスケジュールで行ってください。 って言えば良いんかな? >>183 そんなUNIXは存在しない。 Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。 MacOS を Unix だと主張するなら、違うかもしれない。解釈次第。 > Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。 それはASCIIと互換性がある文字コードだけ LinuxはSJISに対応しようと頑張ったやつがあるが ASCIIと互換性がないので不完全なまま終了した http://ossforum.jp/jossfiles/Linux_SJIS_Support.pdf > なぜ Linux で Shift JIS ロケールがサポートされない > 現在、日本で利用されている多くの Linux ディストリビューションでも、Unicode 系の UTF-8 がデ > フォルトとされ、Shift JIS ロケールが用意されているケースでも、利用は推奨されていない。 > 1. Linuxの文字処理ライブラリ関数は、Unicode を扱うことを基本としているため、本ライブラリ > 関数を使ってインプリメントされた Linux システムコマンドでは、ファイルデータの中の文字 > 処理や、ファイル名の処理で、Unicode は正しく扱えても、Shift JIS は扱えないことがある。 > 2. Shift JIS データの処理は、「特別」な扱いとなり、メールクライアント Thunderbird など、個々 > のミドルウェアに多大な開発負担を負わせている。 > 3. 特に、正統 Shift JIS ロケール sjis では、 0x5C=U+00A5 というマッピングのために、オープ > ン系プログラム(C言語、Java など)の動作が保証されない。cp932 などでは問題ない。 ちなみにWindows NTは最初のバージョンから複数文字コード対応が終わっている UTF-16(初期はUCS-2)がOSの標準文字コードだからね その定義だと WindowsNT は ShiftJIS に対応してないんだなこれが。 あくまで対応しているのは CP932 なんだ。 Linux は正しく ShiftJIS を規格書どおりに実装している。 問題は CP932 と ShiftJIS を後出しで別物にしちゃったマイクロソフトにある。 だから Linux でMS互換の文字コードを使いたい場合、ShiftJIS ではなく CP932 と設定する必要がある。 >>190 だからLinuxはCP932に完全対応できずに終わったって言ってるじゃん 話すり替えるなよ そういえば CP932 は ASCII 互換だったな。 (互換だったということにマイクロソフトがした) https://shellscript.sunone.me/character_code.html >古くから UNIX の日本語環境では EUC-JP が標準の文字コードとして使用されてきた https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi/0069 >EUC-JPはUNIX系OSに採用されてワークステーションに,ISO-2022-JP(の前身であるJUNETコード)は電子メールやネットニュースなどインターネットを中心に広まっていきました。 https://codeaid.jp/blog/exchange-utf8/ >UnixはEUC、WindowsはShift_JIS、MacはMacJapaneseやUTF-8など異なったエンコードタイプでテキストを扱います。 http://www.monyo.com/technical/samba/docs/Japanese-HOWTO-3.0.ja.txt >オープンソースの Linux、FreeBSD や、Solaris、IRIX、Tru64 UNIX といった商用 UNIX では、日本語のロケールとして通常 EUC-JP を利用しています あとどれだけの情報を出せば納得するのかな?ww >>191 話そらしてるようにしか読めないのなら、それがお前の知識の限界ってやつだ。 >>193 ちなみに Sony の NEWS とか知ってる? >>192 マイクロソフトはCP932がASCII互換なんて言ってないよ それもあってかWindowsではANSIという呼び方をしている >>194 話をそらしてるのはお前でしょ。Linux および Unix が CP932 または ShiftJIS に対応してないって話なのに Windowsがー、ShiftJISじゃなくてー、CP932なんだーってWindowsの話にすり替えてる Linux および Unix の話に戻しましょう。 Linux および Unix が CP932 または ShiftJIS に完全対応してない >>193 にも書いてあるように日本語はASCII互換のEUC-JPを使っていた AIXはCP932系のCP943がデフォルトだったしSolarisも一応PCKというのを提供していた。 使うコマンド全てちゃんとlocaleに従う国際化していればできる話。 どんどんボロが出るな。 お前のういう ANSI と ASCII の違いって何。 Linux において Shift_JIS と CP932 の違いはわかる? Sony の NEWS って知ってる? >>199 IBM の Shift JIS とか教えてやんなよw にわか君の脳がバグってこれまで以上に面白いことになりそう。 かつて、シフトJISは皆同じものであった。 その名は様々であったが、人々はシフトJISを使って互いに話し合うことができた。 ほんとは空き領域にメーカー独自に文字を追加してたり、外字領域として使っていたりしたが、同じものと主張していた。 傲慢になった人々はさらに多くの文字を要求した。 お怒りになられた神は Unicode をもたらされた。 各社が勝手気儘に Unicode とシフトJISの変換表を定義したので、ひとつのシフトJISは沢山のシフトJISに分割された。 人々は互いに言葉が通じなくなった。 故・永井一郎氏でナレーションをつけたらガンダムみあってよいね。 >>203 パソコン通信の時代 「文字化け」はノイズでテキストデータが一部壊れることを意味していた 文字化けをなくすしくみとして「MNP」があったけどそれも今では違う意味で使われている 以前、GB18030の話したときの感じだと、素人集団だし、あまり他人のことをとやかく言っても仕方ないのでは。 ANSI の本来の意味は「アメリカ国会標準協会」、日本の JIS にあたる。 一般的な読みは「アンシー」。 もちろん文字コードだけを規定しているのでなくて、色々な規格を決めてる。 でも日本で俗に文字コードのことを JIS って呼ぶ感じで、ANSI って呼んじゃう。 ちなみに ASCII のアメリカ規格での正式な名称は ANSI X3.4 だった。(国際規格だとISO 646 IRV) Windows の人たちは ASCII だけでなくて ASCII 系の拡張コードを全て ANSI って呼ぶ(ことが多い)。 (もちろん正式名称ではないので、正式なドキュメントでは使用しない)。 あまり詳しくないけどShiftJISの規格書とかあるんだな JIS X 0208 に「シフト符号化」として規格がある。Linux の SHIFT-JIS は基本これに従っている。 でも各社が空領域に勝手に追加した文字は、使ってはいけないことになってるのでマイクロソフトの CP932 とかとは完全な互換ではない。 もともとShiftJISはマイクロソフトといくつかの会社で共同開発したものだよ だからマイクロソフトがオリジナルと言っていい。 そこにNECやIBMなどが空き領域に勝手に文字を追加した。 CP932はマイクロソフトが作った文字コード(文字集合)であるが マイクロソフトが勝手に文字を追加したのではなく、 NECやIBMの独自拡張を互換性を維持するように統合したもの ShiftJISの亜種で困るのは、MacJapanese アップルも同じく勝手に空き領域の文字を追加した上に同じ文字コードに 違う文字を割り当ててる。そのせいでMacとのデータのやり取りで 丸囲み数字とかで文字化けが発生する原因となった。少しは互換性を考えろって ここに詳しく書いてあるよ https://wiki.suikawiki.org/n/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%BD%E3%83%95%E3%83%88%E6%A8%99%E6%BA%96%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%82%BB%E3%83%83%E3%83%88 そこにも書いてあるけど、最初に作られたシフトJIS には追加文字は無かった。 その後に各社が勝手に文字を追加していった。マイクロソフトもその後から互換性を無視した追加した一社。 JIS がシフト符号化方式を規格化する時の特定の会社に肩入れするわけにはいかないので、本来の空領域は使用禁止という方針を維持した。 Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。 > マイクロソフトもその後から互換性を無視した追加した一社。 何を追加したというの? > Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。 多くのソフトはCP932とかいう名前で対応してるけど? >> 217 もともとマイクロソフトの CP932 には追加文字は無かったんだけベンダー各社が勝手に文字を追加することを許していた。 Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。 つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。 インターネットの正式規格(IANA)には後者に Windows-3.1J として登録されている。 両者を区別した場合に俗に後者を MS932 と呼ぶ人たちもいる。 >>218 そう。Linux では Shift_JIS と CP932 は別の文字コードという扱いになってる。 なんか主張がブレまくってる気がするけど、結局どういうことを主張したいの? SHIFT JIS には種類がいっぱいある。同じ名前でも同じものだとは思うな。互換性はない。 >>220 > Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。 だから、NECとIBMとの互換性を保つように、それら両方の文字集合を含んだCP932を作ったことでしょう? そう言ってるじゃん そしてさらにそこから拡張して混乱を招かないように禁止したんだね それは当然の行為だね > つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。 昔ながらのもの?なにそれ。Windows-3.1J ?MS932?同じものだけど いちいち書いてる所探してやるの面倒くさいなと思ったけどすぐ見つかったw 最初にこっちを見つけてくればよかったね Shift_JIS、CP932、MS932、Windows-31J http://una.soragoto.net/topics/13.html nkfだと、sjisとcp932で扱いが異なる。 最初sjisでうまくいかないで、cp932だとうまくいった。 俺にとってのcp932事始め。 結局、Linuxがどうたら言っていた話はなんの関係があったんだろうか https://weblabo.oscasierra.net/shift_jis-windows31j/ ここにはちゃんと最初の時点ではShiftJISとCP932は同じものって書いてあるな CP932はもともとMS内部での呼び名だしな そしてあとからNECとIBMが独自に拡張した それじゃいろいろと困るから、あらためてMSがそれらを取り込んでCP932として再定義した。 IANAではWindows-31JでありJavaではMS932という名前になった。 MacJapaneseはどういう経緯で作ったんだろうな NECやIBMのことなんかも考えず、アップルがShiftJISを勝手に拡張したのか? 2022も一枚岩じゃねーのにMSシフトだけ悪者かよw 技術の話だからな、誰が邪悪で誰が正義とかはないぞ。 種類が多数あるから気をつけろ。あえて言えば非互換な変更は可能な限り避けろ。 あと別に NEC と IBM だけが独自拡張してたわではないぞ。 Apple や Fujitsu を始めとして他も各社独自拡張してた。 マイクロソフトはビジネス上の都合で普及してた NEC と IBM のもののみから取捨選択した。 そこそこ普及してたけどライバルだった Apple のもは無視した(互換にする理由が無かった)。 code page 932 って元々MSじゃなくて IBM の規格だけどな。 IBM が作った OS/2 とうのがあってな。それ用の文字コード名だった。 MS は IBM が OS/2 を作るのに技術協力しててな、その後に Windows 作る時にその用語をそのまま使った。 MS が拡張する前の CP932 を IBM 932 と呼ぶ人がいるのはこれが理由。 うちがIBM社から依頼されて制作したのが始まり。 当時は広く調査する手段が無く、偏りがある事は認める。 >>231 そういえば IBM は律義なので、文字を追加して互換性のないやつは CP943 とか別の番号を割当てて名前を変えてたんだよな。 MS はその辺を参考に文字を追加したやつも CP932 と呼び続けたのは何でだろう。 >>233 CP932はどちらもMSが作ったコードページでMSとしては互換性があるからじゃないの? Unicodeにバージョンがあっても文字集合が違うように オリジナルの CP932(=ShiftJIS )があって、そこに文字集合を 拡張したいわば CP932 2.0 という扱いだから名前を変える必要がない IBMのは別会社だから、別の名前にするのはそこまで不思議じゃないかな むしろNECがなんでCP932を使ってるかのほうが気になるけど NECもMS-DOSを使っていたからかな 最初のMS製のCP932は1982年に作られて、NECとIBMが独自拡張したのは1983年なんだね アップルは1991年にそれまた独自で拡張してる そして再構成されたCP932ができたのは1993年のようだ code page 番号での管理は IBM が汎用機時代からずっとやってきた名前で、 マイクロソフトは後から、その番号をそのまま採用したって聞いたけど、違うの? >>235 もともとMSとIBMは1990年代まで協力してOS開発をしてた 例えばIBM PC用のPC-DOSはMS-DOSをリネームしたもの だから共通のコードページを使用するのは当たり前 1990年代以降にOS開発の協力をやめてからはそれぞれ独立して コードページを管理してる 古くはIBMが使っていた用語のようだがCP932がなんかができた時期は共同開発なんだろう MS等数社でShiftJISの仕様を作ってそれをOSに実装するときにCP932という管理番号が与えられた https://en.wikipedia.org/wiki/Code_page 共通のコードページを使うようになったのはいつから? そこが曖昧なんだよな。 マイクロソフトは元々 CP932 とは呼んでなかったという意見があるみたいなんだが。 >>234 NEC は厳密に言えば CP932 に文字を追加したわけではないからなあ。 NEC や Fujitsu がやったのは漢字ROMの空き領域に字形を追加した。 これをやると OS とか文字コードに関係無く使える漢字が増える。CP/M でも BASIC でも。 ANSI先生、シフトジスがめんどくさいです... >>227 HTMLでcharset=Shift_JISであっても実際はWindows-31Jだったりする。 巷の大概のブラウザはWindows-31Jにしかない文字があっても開ける。はしご高とか。 そうやってある意味グダグダになっていく(った)わけやね。でもしょうがないのかな。 厳密な挙動をしても「えーこのブラウザ文字化けするー」とか言われちゃうのがオチだし。 ま、HTMLはもうだいぶUTF-8になってきてるし、いっかw >>237 元々というのがいつの話か知らんが、chcp "MS-DOS 3.3" で検索したら 海外のMS-DOS3.3(1987年)にはCHCPコマンドがあったようだね http://radioc.web.fc2.com/column/pc98bas/internal-version-of-msdos-33.html https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/appendix-a/ ここからCP932が存在したということにはならないけど 今と同じコードページはMS-DOS当時使われていた そこに別のものを使うとは思えないな 当時は日本ではほぼNECの独占状態で、日本専用なわけだから コードページの切り替えはないしCHCPは存在しないから 日本では知られてなかっただけじゃないの? >>238 NEC の汎用機に文字が追加された。もちろんSJIS関係ない。 NEC の汎用機の端末として使えるようにするために PC9801 の漢字ROM は NEC追加文字が含まれて状態で発売された。 ちばみに IBM拡張漢字ROMは別売オプション。 PC9801 に MS-DOS を移植したら、あーら不思議、最初から使える文字が増えてた。 という順序だな。 >>238 MS-DOS、漢字ROMの時代はOSが知っているのは文字コードだけで そこで表示されるフォントはハードウェア搭載されてるものだったからね ShiftJIS系は全て同じものとして扱うことしかできなかった 勝手に違う文字コードに化けさせるわけには行かないし 細かい文字コードを区別できるようになったのはフォントをOSで 処理するようになったWindowsから だからそのときに改めて統一する必要がでてきた >>240 最初(1982年)からCP932だったという主張は撤回するのん? NEC独自の文字としては2バイト系半角文字がお気に入りだったな 数字やアルファベットが縦長で、全角半角混ぜても違和感ないんだよ 2バイトだけど文字幅は1バイトと同じでな 表示位置の調整の計算は、2バイトは1バイトの倍として 計算するだけでは駄目だったんだよ 1文字ずつ見ていって文字コードの範囲をみて計算する必要がある ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様 >>243 してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる 当時は日本で広まっていないだけ >>245 推測とかじゃなくて、その根拠が知りたいんだが。どこ情報? あ、別に否定してるわけじゃないよ。 世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。 >>246 そんなに答えを求めてるなら「今となってはわからない」が正解じゃねw 少なくともCP932が使われていなかったという根拠はないからね もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題 私の一番すきな 98 は 98FA なので、98FA が正義でありたい □□□□□□□□□□□□□□□□□□□□□□□□□ □□■□■■□□□□■■□□■■■□□□■■■□□ □■■□□□□■□■□□□□□□□■□□□□□■□ □□■□■□□■□□□□□□□□□□□□□□□□□ □■□□■□□■□□□□□□□□□□□□□□□□□ □□□■■■□■□□■■□■□□□□□■□□□□□ □□□■■□□□■□□□□□■■■■□□■■■■□ □□□□□□□□□□□□□□□□□□□□□□□□□ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる