X
文字コード総合スレ Part12
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2018/12/17(月) 16:48:24.47ID:Pfqpaohb
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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 http://mevius.5ch.net/test/read.cgi/tech/1516629503/
0154デフォルトの名無しさん
垢版 |
2020/09/24(木) 23:00:01.78ID:2TpuCg1t
UTF-1 があるから歴史が古いなんて言ってる人いないけど、どこ見てるの。
UTF-1 のすぐ後に UTF-8 が提案されてて間は1年もないよ。寝惚けてるの？
0155デフォルトの名無しさん
垢版 |
2020/09/24(木) 23:04:21.45ID:4CFVaDi9
論点はそこじゃなくてUTF-8はUnix系でUTF-16に対応できなかったから
しかたなく作ったものだって話だろ
外部が作って後からUnicodeに追加された仕様
0156デフォルトの名無しさん
垢版 |
2020/09/24(木) 23:19:57.03ID:KWqR4FD9
あきらめろ。
UTF-8 は Unicode ではなく UCS 用に作られた。
UTF-8 は欠陥のある UTF−1 の代わりにするために作られた。
UTF-8 が考案された時には UTF-16 は影も形も無かった。
0158デフォルトの名無しさん
垢版 |
2020/09/24(木) 23:31:22.25ID:tp/LFCei
>>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の実装と互換性がありません。
0159デフォルトの名無しさん
垢版 |
2020/09/25(金) 01:42:25.42ID:gzmvGmy3
>>158
そこに書かれている original UTF というのは UTF-1 のことで UTF-16 のことじゃないぞ。
ちゃんと理解できてるか？
0160デフォルトの名無しさん
垢版 |
2020/09/25(金) 02:18:28.45ID:N+dUj7Ty
だからUnicodeに対応するためにUCS-2ではなくてUTF-1を使ってたんだろ
UnixがUCS-2に対応するのは現実的に不可能だったから
0161デフォルトの名無しさん
垢版 |
2020/09/25(金) 02:46:48.42ID:4J6tgyym
>>156
> UTF-8 が考案された時には UTF-16 は影も形も無かった。

UTF16の直接の先祖のUnicode1.0の符号化方式が厳然と存在してるのに影も形もないはないな
0162デフォルトの名無しさん
垢版 |
2020/09/25(金) 02:48:35.22ID:gzmvGmy3
>>160
だから、それ、お前の妄想だろ。不可能とかどこにも書かれてない。

実際やろうと思えばできる。素人じゃあるまいし。Ken って誰だか知ってるか？
ただ、互換性がないから嫌っていたという話。
Windows とかはしょちゅう非互換な変更を加えるけど、Unix とかは文化として相互の協調動作を重視するんだ。
それで、可能な限り非互換な変更を避けようとする、仕方がない場合にはやるけど。
実際問題 Plan-9 には UCS-2 と UTF-1 の両方が既に開発済みで、リリース間近だった。
ちょうど、その時に X/Open comitee の人から電話がかかって来て、UTF の改良について相談されたので、速攻でより互換性の高い新しい符号((UTF-8)を設計して提案したという話。
0164デフォルトの名無しさん
垢版 |
2020/09/25(金) 03:18:37.40ID:4J6tgyym
お前の間違いってどれよ、挙げてみｗｗｗお前が思ってるお前の発言は多分俺の発言じゃないから
一人を相手にしてると思ってるなら大間違い
0165デフォルトの名無しさん
垢版 |
2020/09/25(金) 03:20:48.06ID:N+dUj7Ty
>>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の実装と互換性がありません。
0169デフォルトの名無しさん
垢版 |
2020/09/25(金) 08:14:51.08ID:ElnYG5aU
互換性がないから嫌いとしか読めん
現実に各社 Unix でも Linux でも UTF-16 実装してるんだよなあ。
不可能とは？
0171デフォルトの名無しさん
垢版 |
2020/09/25(金) 09:16:58.00ID:gzmvGmy3
なんで？
プログラムと API を書き換えれば、普通にできるよ。
実際 Windows はそれをやったわけだし。
0172デフォルトの名無しさん
垢版 |
2020/09/25(金) 09:28:26.81ID:ElnYG5aU
>>171
Mivrosoft は愚直に全てのプログラムを書き換えた。
UNIX陣営は UTF-8 を発明して、その手間を大幅に省いた、天才。って話だわな。
0173デフォルトの名無しさん
垢版 |
2020/09/25(金) 09:31:02.93ID:N+dUj7Ty
>>171
永遠の時間があればできるだろうなって話
Windows NTは最初のバージョンからUnicode対応だった
0174デフォルトの名無しさん
垢版 |
2020/09/25(金) 09:36:14.75ID:gzmvGmy3
逆だろ、Unicode 対応のために DOS-FAT から NTFS に非互換な変更したってだけだろ。
DOS-FAT はあまりにもダメダメなので、他の理由でも置き換えるのが必須だったので決断は簡単だった。
一方 UNIX 系の FS は FAT に比べれば良くできてたので、置き換える意欲に乏しかった。
0175デフォルトの名無しさん
垢版 |
2020/09/25(金) 10:34:03.53ID:N+dUj7Ty
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)
0176デフォルトの名無しさん
垢版 |
2020/09/25(金) 11:53:51.78ID:ET4Ww2dt
DOS-FATなんて使われてない用語を使ってるのは、印象操作でも目論んでるようにしか見えないが
FATの正統後継であるexFATは今も使われてるしSDカードの標準のファイルシステムとして公式採用されてる
だめだめの部分がなにか知らんがとっくに改良されておりよくできたファイルの一つとなってる
0177デフォルトの名無しさん
垢版 |
2020/09/25(金) 11:57:18.65ID:ElnYG5aU
お前はネットで検索した情報を知ったかする前に、まずは時系列順に並べ替えてみろ。
0178デフォルトの名無しさん
垢版 |
2020/09/25(金) 12:43:52.40ID:fcTjdC6n
>>177
それはお前がやるべきことだ
　　
なぜ俺が不利になる（？）ようなことを
俺がわざわざ調べないといけないんだｗ

反論があるならお前がしろ
自分が反論できないからって相手に反論の
材料を探させるという間抜けをするな
やるわけねーだろアホｗ
0179デフォルトの名無しさん
垢版 |
2020/09/25(金) 14:19:51.56ID:ElnYG5aU
ちゃんと調べれば自分が間違っていることに気づくぞ、というアドバイスなんだが。
不都合な真実は知りたくないというのなら、永遠に間違って理解してろ。
残念ながらお前は技術者には向いてないんだろうと思う。
0180デフォルトの名無しさん
垢版 |
2020/09/25(金) 14:27:52.78ID:Aqlkxpe2
ANSI文字列を扱うAPIをいまだに保守し続けているWindows
デフォルトエンコーディングをEUCから突然UTF-8に切り替えたunix

互換性を軽視しているのはどちらでしょう
0182デフォルトの名無しさん
垢版 |
2020/09/25(金) 16:02:35.34ID:ElnYG5aU
調べなくても、その辺の時系列はよく知ってるんだよ。当時、リアルタイムでおっかけてたので。
時系列誤解して、知ってるやつなら絶対に間違えないレベルの主張してるのがいたので指摘しとこうかと思っただけ。
お前は知りたくなければ知らなくて良いよ。
十分に事実は書いたので、後から奇特にもこのスレ覗きに来て、お前の妄言に惑わされる奴もいないだろうし。
p.s. 上から目線なのはジジイなので許せ。
0183◆QZaw55cn4c
垢版 |
2020/09/25(金) 21:10:47.40ID:DCkHs+Bt
>>180
その unix とやらの具体的で正式な OS の名称を教えてください…
0185デフォルトの名無しさん
垢版 |
2020/09/25(金) 21:22:39.15ID:K0BToZeX
https://docs.microsoft.com/ja-jp/archive/blogs/nakama/win10waas-part5a

カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ないと思います。
Windows 7 で動作していた .NET 3.5 のアプリのほとんどは、Windows 10 上の .NET 3.5 でもまず十中八九動作するはずで、
先行検証しているあるお客様からは、「まるで非互換問題が出てこないんだけれども、名前だけ変えてお金稼ごうとしてない？」とか言われたことがあるぐらいです；。
0186デフォルトの名無しさん
垢版 |
2020/09/25(金) 21:53:11.91ID:jsxvfqFg
>>185
マイクロソフトは互換性が高いと主張しています。それは事実だと思いますが
それでも断定はできないし保証はできないので検証は必要です。

ただしお客様の方で検証していただければお金は不要です。
問題があった場合は有償でサポートしますが対応に時間がかかることがあるので
余裕を持ったスケジュールで行ってください。

って言えば良いんかな？
0187デフォルトの名無しさん
垢版 |
2020/09/26(土) 04:29:55.57ID:V6Zu3iZf
>>183
そんなUNIXは存在しない。
Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。
MacOS を Unix だと主張するなら、違うかもしれない。解釈次第。
0188デフォルトの名無しさん
垢版 |
2020/09/26(土) 05:50:51.04ID:dJRFq1YT
> 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. Ｌｉｎｕｘの文字処理ライブラリ関数は、Unicode を扱うことを基本としているため、本ライブラリ
> 関数を使ってインプリメントされた Linux システムコマンドでは、ファイルデータの中の文字
> 処理や、ファイル名の処理で、Unicode は正しく扱えても、Shift JIS は扱えないことがある。

> 2. Shift JIS データの処理は、「特別」な扱いとなり、メールクライアント Thunderbird など、個々
> のミドルウェアに多大な開発負担を負わせている。

> 3. 特に、正統 Shift JIS ロケール sjis では、 0x5C=U+00A5 というマッピングのために、オープ
> ン系プログラム（Ｃ言語、Java など）の動作が保証されない。cp932 などでは問題ない。
0189デフォルトの名無しさん
垢版 |
2020/09/26(土) 05:52:24.09ID:dJRFq1YT
ちなみにWindows NTは最初のバージョンから複数文字コード対応が終わっている
UTF-16（初期はUCS-2）がOSの標準文字コードだからね
0190デフォルトの名無しさん
垢版 |
2020/09/26(土) 08:35:16.23ID:4p5kvQE6
その定義だと WindowsNT は ShiftJIS に対応してないんだなこれが。
あくまで対応しているのは CP932 なんだ。
Linux は正しく ShiftJIS を規格書どおりに実装している。
問題は CP932 と ShiftJIS を後出しで別物にしちゃったマイクロソフトにある。
だから Linux でMS互換の文字コードを使いたい場合、ShiftJIS ではなく CP932 と設定する必要がある。
0192デフォルトの名無しさん
垢版 |
2020/09/26(土) 10:55:23.76ID:HIxn44p8
そういえば CP932 は ASCII 互換だったな。
（互換だったということにマイクロソフトがした）
0193デフォルトの名無しさん
垢版 |
2020/09/26(土) 11:00:49.52ID:ToQOodFb
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
0196デフォルトの名無しさん
垢版 |
2020/09/26(土) 14:37:10.24ID:ER2LZL5Z
plamoっって久々に観たわ
0197デフォルトの名無しさん
垢版 |
2020/09/26(土) 15:20:39.47ID:dJRFq1YT
>>192
マイクロソフトはCP932がASCII互換なんて言ってないよ
それもあってかWindowsではANSIという呼び方をしている
0198デフォルトの名無しさん
垢版 |
2020/09/26(土) 15:23:26.93ID:dJRFq1YT
>>194
話をそらしてるのはお前でしょ。Linux および Unix が CP932 または ShiftJIS に対応してないって話なのに
Windowsがー、ShiftJISじゃなくてー、CP932なんだーってWindowsの話にすり替えてる

Linux および Unix の話に戻しましょう。

Linux および Unix が CP932 または ShiftJIS に完全対応してない
>>193にも書いてあるように日本語はASCII互換のEUC-JPを使っていた
0199デフォルトの名無しさん
垢版 |
2020/09/26(土) 15:35:39.57ID:nz56jET8
AIXはCP932系のCP943がデフォルトだったしSolarisも一応PCKというのを提供していた。
使うコマンド全てちゃんとlocaleに従う国際化していればできる話。
0200デフォルトの名無しさん
垢版 |
2020/09/26(土) 15:56:41.68ID:HIxn44p8
どんどんボロが出るな。
お前のういう ANSI と ASCII の違いって何。
Linux において Shift_JIS と CP932 の違いはわかる？
Sony の NEWS って知ってる？
0201デフォルトの名無しさん
垢版 |
2020/09/26(土) 15:59:25.33ID:HIxn44p8
>>199
IBM の Shift JIS とか教えてやんなよw
にわか君の脳がバグってこれまで以上に面白いことになりそう。
0202デフォルトの名無しさん
垢版 |
2020/09/26(土) 16:25:27.51ID:Xs9MiFl7
NEWSとX68kは欲しかったな
0203デフォルトの名無しさん
垢版 |
2020/09/26(土) 16:26:57.63ID:QQeUS8EE
かつて、シフトJISは皆同じものであった。
その名は様々であったが、人々はシフトJISを使って互いに話し合うことができた。
ほんとは空き領域にメーカー独自に文字を追加してたり、外字領域として使っていたりしたが、同じものと主張していた。

傲慢になった人々はさらに多くの文字を要求した。
お怒りになられた神は Unicode をもたらされた。
各社が勝手気儘に Unicode とシフトJISの変換表を定義したので、ひとつのシフトJISは沢山のシフトJISに分割された。
人々は互いに言葉が通じなくなった。
0204デフォルトの名無しさん
垢版 |
2020/09/26(土) 16:47:43.71ID:htO/NqgS
故・永井一郎氏でナレーションをつけたらガンダムみあってよいね。
0205デフォルトの名無しさん
垢版 |
2020/09/26(土) 17:05:55.71ID:iJutkljl
>>203
パソコン通信の時代
「文字化け」はノイズでテキストデータが一部壊れることを意味していた
文字化けをなくすしくみとして「MNP」があったけどそれも今では違う意味で使われている
0206デフォルトの名無しさん
垢版 |
2020/09/26(土) 17:45:01.52ID:P5ZUvIL5
以前、GB18030の話したときの感じだと、素人集団だし、あまり他人のことをとやかく言っても仕方ないのでは。
0211デフォルトの名無しさん
垢版 |
2020/09/27(日) 01:58:25.37ID:UrweFCig
ANSI の本来の意味は「アメリカ国会標準協会」、日本の JIS にあたる。
一般的な読みは「アンシー」。
もちろん文字コードだけを規定しているのでなくて、色々な規格を決めてる。
でも日本で俗に文字コードのことを JIS って呼ぶ感じで、ANSI って呼んじゃう。
ちなみに ASCII のアメリカ規格での正式な名称は ANSI X3.4 だった。(国際規格だとISO 646 IRV)
Windows の人たちは ASCII だけでなくて ASCII 系の拡張コードを全て ANSI って呼ぶ(ことが多い)。
(もちろん正式名称ではないので、正式なドキュメントでは使用しない)。
0214デフォルトの名無しさん
垢版 |
2020/09/27(日) 17:40:16.09ID:UrweFCig
JIS X 0208 に「シフト符号化」として規格がある。Linux の SHIFT-JIS は基本これに従っている。
でも各社が空領域に勝手に追加した文字は、使ってはいけないことになってるのでマイクロソフトの CP932 とかとは完全な互換ではない。
0215デフォルトの名無しさん
垢版 |
2020/09/27(日) 18:22:15.82ID:I+ot45zN
もともと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
0216デフォルトの名無しさん
垢版 |
2020/09/27(日) 19:50:11.19ID:UrweFCig
そこにも書いてあるけど、最初に作られたシフトJIS には追加文字は無かった。
その後に各社が勝手に文字を追加していった。マイクロソフトもその後から互換性を無視した追加した一社。
JIS がシフト符号化方式を規格化する時の特定の会社に肩入れするわけにはいかないので、本来の空領域は使用禁止という方針を維持した。
Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。
0217デフォルトの名無しさん
垢版 |
2020/09/27(日) 20:01:06.53ID:duNnLcqR
> マイクロソフトもその後から互換性を無視した追加した一社。
何を追加したというの？
0218デフォルトの名無しさん
垢版 |
2020/09/27(日) 20:02:45.37ID:duNnLcqR
> Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。

多くのソフトはCP932とかいう名前で対応してるけど？
0220デフォルトの名無しさん
垢版 |
2020/09/27(日) 20:42:09.15ID:UrweFCig
>> 217
もともとマイクロソフトの CP932 には追加文字は無かったんだけベンダー各社が勝手に文字を追加することを許していた。
Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。
つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
インターネットの正式規格(IANA)には後者に Windows-3.1J として登録されている。
両者を区別した場合に俗に後者を MS932 と呼ぶ人たちもいる。
0222デフォルトの名無しさん
垢版 |
2020/09/27(日) 21:07:18.47ID:xq8pY9v9
なんか主張がブレまくってる気がするけど、結局どういうことを主張したいの？
0223デフォルトの名無しさん
垢版 |
2020/09/27(日) 21:09:23.04ID:UrweFCig
SHIFT JIS には種類がいっぱいある。同じ名前でも同じものだとは思うな。互換性はない。
0224デフォルトの名無しさん
垢版 |
2020/09/27(日) 22:15:06.93ID:duNnLcqR
>>220
> Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。

だから、NECとIBMとの互換性を保つように、それら両方の文字集合を含んだCP932を作ったことでしょう？
そう言ってるじゃん

そしてさらにそこから拡張して混乱を招かないように禁止したんだね
それは当然の行為だね

> つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
昔ながらのもの？なにそれ。Windows-3.1J ？MS932？同じものだけど

いちいち書いてる所探してやるの面倒くさいなと思ったけどすぐ見つかったｗ
最初にこっちを見つけてくればよかったね

Shift_JIS、CP932、MS932、Windows-31J
http://una.soragoto.net/topics/13.html
0225デフォルトの名無しさん
垢版 |
2020/09/27(日) 23:12:33.54ID:G6Rp/5vA
nkfだと、sjisとcp932で扱いが異なる。
最初sjisでうまくいかないで、cp932だとうまくいった。
俺にとってのcp932事始め。
0227デフォルトの名無しさん
垢版 |
2020/09/27(日) 23:21:06.50ID:duNnLcqR
https://weblabo.oscasierra.net/shift_jis-windows31j/

ここにはちゃんと最初の時点ではShiftJISとCP932は同じものって書いてあるな
CP932はもともとMS内部での呼び名だしな

そしてあとからNECとIBMが独自に拡張した
それじゃいろいろと困るから、あらためてMSがそれらを取り込んでCP932として再定義した。
IANAではWindows-31JでありJavaではMS932という名前になった。

MacJapaneseはどういう経緯で作ったんだろうな
NECやIBMのことなんかも考えず、アップルがShiftJISを勝手に拡張したのか？
0228デフォルトの名無しさん
垢版 |
2020/09/28(月) 00:29:11.65ID:yUM2IYPL
2022も一枚岩じゃねーのにMSシフトだけ悪者かよw
0230デフォルトの名無しさん
垢版 |
2020/09/28(月) 02:22:56.82ID:LFNRA5Wr
技術の話だからな、誰が邪悪で誰が正義とかはないぞ。
種類が多数あるから気をつけろ。あえて言えば非互換な変更は可能な限り避けろ。

あと別に NEC と IBM だけが独自拡張してたわではないぞ。
Apple や Fujitsu を始めとして他も各社独自拡張してた。
マイクロソフトはビジネス上の都合で普及してた NEC と IBM のもののみから取捨選択した。
そこそこ普及してたけどライバルだった Apple のもは無視した(互換にする理由が無かった)。
0231デフォルトの名無しさん
垢版 |
2020/09/28(月) 03:00:06.80ID:aMwTz6q2
code page 932 って元々MSじゃなくて IBM の規格だけどな。
IBM が作った OS/2 とうのがあってな。それ用の文字コード名だった。
MS は IBM が OS/2 を作るのに技術協力しててな、その後に Windows 作る時にその用語をそのまま使った。
MS が拡張する前の CP932 を IBM 932 と呼ぶ人がいるのはこれが理由。
0232デフォルトの名無しさん
垢版 |
2020/09/28(月) 03:09:14.91ID:Btw2QdlH
うちがIBM社から依頼されて制作したのが始まり。
当時は広く調査する手段が無く、偏りがある事は認める。
0233デフォルトの名無しさん
垢版 |
2020/09/28(月) 03:09:23.25ID:LFNRA5Wr
>>231
そういえば IBM は律義なので、文字を追加して互換性のないやつは CP943 とか別の番号を割当てて名前を変えてたんだよな。
MS はその辺を参考に文字を追加したやつも CP932 と呼び続けたのは何でだろう。
0234デフォルトの名無しさん
垢版 |
2020/09/28(月) 03:39:47.21ID:IvlPnhNT
>>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年のようだ
0235デフォルトの名無しさん
垢版 |
2020/09/28(月) 04:20:00.06ID:LFNRA5Wr
code page 番号での管理は IBM が汎用機時代からずっとやってきた名前で、
マイクロソフトは後から、その番号をそのまま採用したって聞いたけど、違うの？
0236デフォルトの名無しさん
垢版 |
2020/09/28(月) 05:06:08.90ID:IvlPnhNT
>>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
0237デフォルトの名無しさん
垢版 |
2020/09/28(月) 09:14:02.90ID:8EXAUbY4
共通のコードページを使うようになったのはいつから？
そこが曖昧なんだよな。
マイクロソフトは元々 CP932 とは呼んでなかったという意見があるみたいなんだが。
0238デフォルトの名無しさん
垢版 |
2020/09/28(月) 09:33:14.92ID:UEVgwzRH
>>234
NEC は厳密に言えば CP932 に文字を追加したわけではないからなあ。
NEC や Fujitsu がやったのは漢字ROMの空き領域に字形を追加した。
これをやると OS とか文字コードに関係無く使える漢字が増える。CP/M でも BASIC でも。
0239デフォルトの名無しさん
垢版 |
2020/09/28(月) 09:42:09.44ID:ZQPU+aZv
ANSI先生、シフトジスがめんどくさいです...

>>227
HTMLでcharset=Shift_JISであっても実際はWindows-31Jだったりする。
巷の大概のブラウザはWindows-31Jにしかない文字があっても開ける。はしご高とか。

そうやってある意味グダグダになっていく（った）わけやね。でもしょうがないのかな。
厳密な挙動をしても「えーこのブラウザ文字化けするー」とか言われちゃうのがオチだし。

ま、HTMLはもうだいぶUTF-8になってきてるし、いっかw
0240デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:30:21.69ID:IvlPnhNT
>>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は存在しないから
日本では知られてなかっただけじゃないの？
0241デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:39:54.81ID:Uhat3CEo
>>238
NEC の汎用機に文字が追加された。もちろんSJIS関係ない。
NEC の汎用機の端末として使えるようにするために PC9801 の漢字ROM は NEC追加文字が含まれて状態で発売された。
ちばみに IBM拡張漢字ROMは別売オプション。
PC9801 に MS-DOS を移植したら、あーら不思議、最初から使える文字が増えてた。
という順序だな。
0242デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:41:07.34ID:IvlPnhNT
>>238
MS-DOS、漢字ROMの時代はOSが知っているのは文字コードだけで
そこで表示されるフォントはハードウェア搭載されてるものだったからね

ShiftJIS系は全て同じものとして扱うことしかできなかった
勝手に違う文字コードに化けさせるわけには行かないし

細かい文字コードを区別できるようになったのはフォントをOSで
処理するようになったWindowsから
だからそのときに改めて統一する必要がでてきた
0244デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:46:31.48ID:IvlPnhNT
NEC独自の文字としては2バイト系半角文字がお気に入りだったな

数字やアルファベットが縦長で、全角半角混ぜても違和感ないんだよ
2バイトだけど文字幅は1バイトと同じでな

表示位置の調整の計算は、2バイトは1バイトの倍として
計算するだけでは駄目だったんだよ
1文字ずつ見ていって文字コードの範囲をみて計算する必要がある

ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様
0245デフォルトの名無しさん
垢版 |
2020/09/28(月) 10:47:44.81ID:IvlPnhNT
>>243
してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる
当時は日本で広まっていないだけ
0247デフォルトの名無しさん
垢版 |
2020/09/28(月) 11:07:15.33ID:cf3OGOhX
あ、別に否定してるわけじゃないよ。
世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。
0248デフォルトの名無しさん
垢版 |
2020/09/28(月) 11:21:20.86ID:IvlPnhNT
>>246
そんなに答えを求めてるなら「今となってはわからない」が正解じゃねｗ
少なくともCP932が使われていなかったという根拠はないからね
0249◆QZaw55cn4c
垢版 |
2020/09/28(月) 19:55:51.42ID:iFBbxDDj
もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと
で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題

私の一番すきな 98 は 98FA なので、98FA が正義でありたい
0250デフォルトの名無しさん
垢版 |
2020/09/28(月) 20:15:42.82ID:LpDzonCU
□□□□□□□□□□□□□□□□□□□□□□□□□
□□■□■■□□□□■■□□■■■□□□■■■□□
□■■□□□□■□■□□□□□□□■□□□□□■□
□□■□■□□■□□□□□□□□□□□□□□□□□
□■□□■□□■□□□□□□□□□□□□□□□□□
□□□■■■□■□□■■□■□□□□□■□□□□□
□□□■■□□□■□□□□□■■■■□□■■■■□
□□□□□□□□□□□□□□□□□□□□□□□□□
0251デフォルトの名無しさん
垢版 |
2020/09/28(月) 21:40:36.46ID:o1iMmVBZ
https://ja.wikipedia.org/wiki/Microsoftコードページ932

1982年(JIS X 0208-1983策定の前年)、JIS C 6226(JIS X 0208)を複雑にシフトさせた文字符号化方式としてShift_JISが誕生した。
この符号化方式(を利用した拡張符号化文字集合)は、マイクロソフトによりMS-DOSにおける標準日本語コードとして採用され、
「コードページ 932 (CP932)」という管理番号を与えられた。

しかし、マイクロソフトは、MS-DOSにおける唯一の日本語用コードページである「CP932」を、OEMメーカーの自由に任せていた。
そのため、NECのPC-9800シリーズ、IBMのPS/55 シリーズ、富士通のFMRシリーズなどは全て、MS-DOSを搭載し
文字符号化方式もShift_JISを採用しているコンピュータであるにもかかわらず、登録されている文字集合がバラバラだった。
0253デフォルトの名無しさん
垢版 |
2020/09/28(月) 22:15:52.03ID:F7s1Ev+m
当時としてはMS-DOSはコンピュータで動くOSの１つでしかないのに
マイクロソフトがコンピュータに搭載する文字集合を決めるなって話だろ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況