文字コード総合スレ Part12

**デフォルトの名無しさん** · 2018/12/17(月) 16:48:24.47

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/

**デフォルトの名無しさん** · 2021/02/16(火) 08:25:02.10

>>512
Unicodeで決まってるんじゃなくて？

**デフォルトの名無しさん** · 2021/02/16(火) 09:08:45.11

>>516
図柄を決めてるのはフォント屋。
Unicode的にはコードポイントが離れてても同じような図柄にすることを想定してるけど、フォントがそうなってないだけ。

**デフォルトの名無しさん** · 2021/02/16(火) 16:32:28.02

文字のバイト数が可変長のコードを作れば、弱い暗号に使えないのかな
１，２，３，４バイト不規則に混在、たまに７バイトや１０バイトも混ざる

**デフォルトの名無しさん** · 2021/02/16(火) 17:46:12.13

もしかしてutf-8？

**デフォルトの名無しさん** · 2021/02/16(火) 20:48:18.23

>>496
UTF-8の4バイトに合わせてU+1FFFFFまでにしてくれればよかったのにとはちょっと思った。

**デフォルトの名無しさん** · 2021/02/16(火) 21:51:25.16

可変長の究極は1文字ごとに
文字の切れ目を表すためのエスケープ文字とunicodeの登録名（HIRAGANA LETTER Aなど）
をテキストファイルに記録する事かもね。
コードポイントの概念を無くして16進数の番号で管理しないから
後から追加された文字でもコードポイントが飛んでいる事はなくなるし。
ただし文字によっては1文字に50バイト以上使うこともある。

**デフォルトの名無しさん** · 2021/02/16(火) 23:05:15.94

>496
Unicodeの当初の16bit（最大65536文字）あれば
十分だろうという考えがそもそもの原因なんだから
UnicodeをややこしくさせてるのはUnicode自身だよ

最初の段階で16bitで足りないと認めていれば
今頃はUTF-32が主流になっていただろう
もっともUnixは互換性のためにUTF-32をネイティブで扱うのが
難しいのでUTF-8は生まれていたかもしれないがね

**デフォルトの名無しさん** · 2021/02/17(水) 01:57:41.63

枻（木へんに世）って、シフトJIS（のバリエーション）的にはどうなんだっけ。
というかこれ自体もテストだったり。

**デフォルトの名無しさん** · 2021/02/17(水) 02:17:54.79

ちなみに自分はMacなんだが、0xFAE2を書き込んだ模様。
皆さんには見えてますでしょうか。
HTMLでcharset=Shift_JISのときってどうするのか揉めた記憶が。

**デフォルトの名無しさん** · 2021/02/17(水) 02:44:16.94

５ちゃんねるの仕様は文字コードと何の関係もない

**デフォルトの名無しさん** · 2021/02/17(水) 03:22:07.19

っ https://encoding.spec.whatwg.org/shift_jis.html
今のブラウザはこの辺に従ってるで終了じゃねの?

**デフォルトの名無しさん** · 2021/02/17(水) 08:12:07.90

>>525
5chをブラウザで見るとHTMLがcharset=Shift_JISなんだけど、それは関係ないってこと?

そもそもテキストデータのやり取りで文字コードの指定がない仕様というのは... もしかして
適当にデータを送受信して適当な文字コードを指定して見れたらラッキー、的な仕様?

そもそも5chの仕様ってどこかにあるんでしょうか。

**デフォルトの名無しさん** · 2021/02/17(水) 09:42:15.24

やれやれ頭が固いなｗ
SJISでUnicodeが表示できないと思いこんでる

**デフォルトの名無しさん** · 2021/02/17(水) 18:28:41.76

もりおうがいしかる
森鷗外𠮟る
森鴎外叱る

**デフォルトの名無しさん** · 2021/02/17(水) 19:54:41.88

森鳩ﾀﾄﾛﾋる

**デフォルトの名無しさん** · 2021/02/17(水) 20:00:49.86

>>521
そこまで行くと文字コードというか最早マーク付け言語みたいだな
てかHTML (SGML/XML)の文字実体参照まんまでは

**デフォルトの名無しさん** · 2021/02/17(水) 22:24:44.47

sjis には、Windows CP932 特有の環境依存文字がある

それで、バグルか、フォントが無いとか

**デフォルトの名無しさん** · 2021/02/18(木) 00:08:48.51

>>523-524
世に出てるブラウザの殆どはcharset=Shift_JISな文書をWindows-31Jとして解釈するだろうから
IBM拡張文字として表示されるんでない？
というか、何を疑問に感じてのレスなのかが分からないんだけど。

**デフォルトの名無しさん** · 2021/02/18(木) 10:20:55.82

不知佛

**デフォルトの名無しさん** · 2021/02/18(木) 16:35:44.79

>>533
>charset=Shift_JISな文書をWindows-31Jとして解釈するだろうから

まさにそこ。本来はこの両者は違うから、正しく解釈すれば文字化けする。
しかし事情を知らないユーザーから見たら、文字化けするソフトウェアの方が劣ると
思われそうで悔しいw

そもそもShit_JISとWindows-31Jをごちゃ混ぜにして大量に垂れ流したWindowsのプラット
フォームないしユーザーに責任があると言えるが、それに迎合しないといけないのがw

**デフォルトの名無しさん** · 2021/02/18(木) 17:36:53.61

>>535
なんでもかんでもWindowsのせいにするな

もともとSJISはMicrosoftがメインで策定したもので
その仕様はMicrosoftが一番知ってる

Microsoftが想定外だったのは、拡張性を持たせるための領域を
NECやIBMが拡張しまくってSJISとして広めてしまったことにある
ごちゃまぜにしたのはNECやIBMにすぎない

Microsoftはそれじゃデータの相互運用に困るから
Windowsでそれらを統合しただけ
MicrosoftのおかげでSJISはほぼ統一されたんだよ

例外は互換性がない形でSJISを確証したMacJapaneseだけ
Appleは独自拡張のうえ既存のSJISを無視して同じ領域に
別の文字を割り当てやがったアホ

**デフォルトの名無しさん** · 2021/02/18(木) 18:09:37.01

Tower of Babel

**デフォルトの名無しさん** · 2021/02/18(木) 18:54:47.31

C言語の/r/nなどのエスケープシーケンスは制御文字に対するアルファベットの割り当てを
キャレット記法と同じにした方がよかったんじゃないかと思う

**デフォルトの名無しさん** · 2021/02/18(木) 20:15:29.49

キャレットって^Cの^（CTRLという意味）のこと？

**デフォルトの名無しさん** · 2021/02/18(木) 22:08:13.73

Ruby は、数十種類もの日本語の方言を変換できる。
方言同士の変換パスを作っている

最大6パスで変換できる方言もあるらしい

でも、今でも、NEC・ドコモ方言などを使うかどうか疑問

**デフォルトの名無しさん** · 2021/02/18(木) 22:29:52.06

>>539
例えばCRLFなら^M^JだからC言語でも\r\nではなく\m\jの方がよかったんじゃないかと

**デフォルトの名無しさん** · 2021/02/18(木) 23:13:37.69

あらゆる文字コードでCR=0x0D,LF=0x0Aだと本当に保証されているのか？
を考えてみれば答えが出るんじゃないかと

**デフォルトの名無しさん** · 2021/02/19(金) 10:43:19.20

>>536
うむー確かに各ベンダーのせいはあるか。
しかし、このSJISの混乱があったにも関わらず、ガラケーでは各ベンダーが勝手な絵文字の
コードを割り当ててえらいことになりかけてたよね。
で今度はGoogleが中心になって事態を収拾した。
歴史は繰り返すってか。あるいは日本企業の変わらない体質?

**デフォルトの名無しさん** · 2021/02/19(金) 11:24:24.47

最近はもうこんな感じのコードを必ず最初に入れるようにしてるなぁ。
$Text = preg_replace("/(\r\n|\r|\n)/" , "\n" , $Text );

**デフォルトの名無しさん** · 2021/02/19(金) 21:20:37.86

絵文字はユーザーの利便性に直結する、最も重要な要素

絵文字でシェアが変わるから、他社よりも先に、魅力的な絵文字を作らないといけない。
Line は、絵文字・スタンプでシェアを不動のものにした

**デフォルトの名無しさん** · 2021/02/19(金) 23:58:34.63

\nだとLFを指している場合と
CR単独、CRLF、LF単独に関係なく改行を指している場合の両方があって
ソフトによって違うから困る
前者と後者を区別できるようにしてほしいね

**デフォルトの名無しさん** · 2021/02/20(土) 14:22:35.85

米アップル、注射器の絵文字を微調整　「血のしずく」を削除
https://www.cnn.co.jp/tech/35166607.html

**デフォルトの名無しさん** · 2021/02/20(土) 16:11:25.88

あきらめないで

**デフォルトの名無しさん** · 2021/02/20(土) 20:02:11.54

>>545
じゃあLineはどうしてるの、という疑問が。

探してみるととりあえず... https://developers.line.biz/media/messaging-api/emoji-list.pdf
これに関してはUnicodeの私用領域を使ってるみたいね。

確か絵文字が表示されないときに (laugh) みたいにちゃんと置き換わるやつがあった気が
するが... あれはHTML的なもの（か、そのもの）なのかな。

**デフォルトの名無しさん** · 2021/02/20(土) 23:07:01.67

調べてみると点字にも文字コードと同じ問題があるんだな
6bitだから仮名と数字とアルファベットを全て1文字で表せないから
数字とアルファベットはエスケープ文字を付けて対応しているし
漢点字だと8bitで可変長になっている

**デフォルトの名無しさん** · 2021/02/21(日) 02:25:03.18

>>550
そういえばUnicode上の点字はなぜか8個の点で例示してあり、実際256パターンある。
点字のUnucode化? 8bitで十分かは知らんけどw
でも8個以上は指で触って読むのが難しいかもしれない。

**デフォルトの名無しさん** · 2021/02/21(日) 05:02:36.24

>>546
\n は、LF だけど、

Python みたいに、global new line を設定すると、
CR単独・CRLF・LF単独と、OS によって改行コードを切り替える、言語がある

**デフォルトの名無しさん** · 2021/02/21(日) 05:15:52.00

>>552
テキストモードって知らんのか？
どのOSでも持ってる機能だぞ

**デフォルトの名無しさん** · 2021/02/21(日) 05:33:13.41

テキストモードという概念はOSというよりプログラミング言語じゃないかな。

◆QZaw55cn4c · 2021/02/21(日) 09:02:39.59

>>553
テキストモード（正式にはクックドモードcooked mode／ローモード raw mode）は Micro Soft 社限定のような気が

**デフォルトの名無しさん** · 2021/02/21(日) 14:27:37.46

Terminal mode
https://en.wikipedia.org/wiki/Terminal_mode

A terminal mode is one of a set of possible states of a terminal or pseudo terminal character device in Unix-like systems and determines how characters written to the terminal are interpreted.
In cooked mode data is preprocessed before being given to a program, while raw mode passes the data as-is to the program without interpreting any of the special characters.

◆QZaw55cn4c · 2021/02/21(日) 16:39:18.84

>>556
thx

**デフォルトの名無しさん** · 2021/02/21(日) 20:28:19.64

たぶん、ascii・テキスト伝送は、Microsoft の規格だろ

基本、データはバイナリしかない。
バイナリを送っているだけ

それを、バイナリかテキストなのか、2種類に分けた

データベースと同じ。
バイナリしかないのに、各列を、バイナリ・テキスト・数値などに分類してる

**デフォルトの名無しさん** · 2021/02/22(月) 03:41:51.59

Unix の raw-mode とういのはバイナリとかASCII とかじゃくて入力されたキーボードの文字を生のまま受け取るモード。
たとえばリターンキーを押すと 0x0D がバックスペースを押すと 0x08 がバイト単位でそのまま渡される。実際のコードは端末次第。
cooked-mode というのは端末の設定に従って行単位でバッファしながら入力を加工するモード。
端末設定で「改行文字入力」が 0x0D に設定されていて、キーボードから 0x0D が入力されたら
改行の入力とみなしてunixの内部的な改行 0x0A に変換して、それまでのバッファを渡す。
端末設定で「前の一文字削除」が 0x08 に設定されていて、キーボードから 0x08 がきたらバッファー内の最後の一文字を削除する。
Ctrl-C で割り込み中断とかも cooked の機能。

**デフォルトの名無しさん** · 2021/02/22(月) 17:39:30.14

>>533
>世に出てるブラウザの殆どはcharset=Shift_JISな文書をWindows-31Jとして解釈するだろうから

ちなiOSのSafariはそうじゃないっぽい。macOSの方はそうなんだが。

とりあえずiPhone買って、付いてきたSafariでウェブを見る、みたいなユーザーは多いんじゃない
かと思うんだが.. というわけで「殆ど」という言い方はできないかもしれない。

**デフォルトの名無しさん** · 2021/02/22(月) 20:36:22.30

>>551
バイナリコードに親しんでいる人が点字を覚えるなら従来の6点の点字より8点の点字で
そのままバイナリコードを表した方が分かりやすいって人はいるだろうね
昔は穿孔テープの穴を見て何が書いてあるか分かる人は多かったようだし

**デフォルトの名無しさん** · 2021/02/23(火) 03:23:29.15

後から穴の数が増えたのも出てくるけど、もともとの紙テープは5穴なので10分も練習すれば誰でも読めた。ただし会社ごとに個別に覚える必要があった。

このスレ的に言えば、各社バラバラだった5穴、6穴の規格を統一するために作られた7穴の共通規格が ASCII の始まり。

**デフォルトの名無しさん** · 2021/02/23(火) 08:57:17.31

もうさ32ドット×32ドットぐらいの点字を作りなよ
そうすりゃかなりの文字を表現できるやろ？

**デフォルトの名無しさん** · 2021/02/23(火) 12:06:09.45

32x32でいけると思ったのですが、森羅万象を表現するに全然足りないことが判明したので、サロゲート点字を導入します

**デフォルトの名無しさん** · 2021/02/23(火) 16:52:17.61

有史から遠い未来まで全人類の顔を絵文字として登録できる、という前提で文字コード規格を作らないとダメでしょ。

**デフォルトの名無しさん** · 2021/02/23(火) 18:23:04.03

漢字には一画のぞくとか、わざと間違えるとかいう字もあるからなあ

**デフォルトの名無しさん** · 2021/02/24(水) 15:37:09.38

「信長の野望」の家康画像みたいに元服前の顔、青年期の顔、老年期の顔をそれぞれ登録するようにしたらますます文字コードが増える。

**デフォルトの名無しさん** · 2021/02/24(水) 15:43:59.66

同じ顔は同一の文字コードにすればOK

**デフォルトの名無しさん** · 2021/02/24(水) 16:00:01.95

>>545
そうなんだ。
ということはSJISのバリエーションに関しても、似たような経緯があったのかな?
「ウチのOSではこんな文字も使えますよ」的な?

**デフォルトの名無しさん** · 2021/02/24(水) 16:13:32.49

IPv6では宇宙誕生から消滅に至るまでの全宇宙のデバイスにIPアドレスを割り当てることはできない。勝手に最大量を決めてはダメってことだ。

**デフォルトの名無しさん** · 2021/02/24(水) 16:25:49.69

>>569
OSじゃなくてハードウェアの問題

まずSJISの文字コード自体はMicrosoftとほか団体が協力して作ったが
SJISという文字コードと基本的な文字集合を定義したが、
当時のOSであるMS-DOSには文字集合という概念そのものがなかった

そもそもMS-DOSにはフォントというものが搭載されておらず
MS-DOSは単にSJISの文字コードに対応した出力機能を備えていたに過ぎない
そしてその文字コードに対応した文字（つまりフォント）はハードウェアの漢字ROMに搭載されていた

当時はPCの速度が遅く、ハードウェアにフォントを搭載しなければ
日本語はまともな速度が出なかった

そして漢字ROMを作っていたのはNECなどのパソコン屋。拡張領域に文字を入れることで
NEC「うちのパソコンは、こういう漢字にも対応していますよ。」ということが出来た

例えば PC-9801の初代は漢字ROMボードを搭載せず、
・JIS第一水準漢字ROMボード
・JIS第ニ水準漢字ROMチップ
・どちらにも含まれていない拡張漢字ROMチップ
がそれぞれ別売りされていた

**デフォルトの名無しさん** · 2021/02/24(水) 16:32:05.41

日本人が作る日本人のためのパソコンで
日本で使われている漢字が表示できないのは
マイナスでしかない。だからパソコン屋は
当初のSJISで定義されていた基本的な文字集合を超えた
文字を漢字ROMボードとして提供するしか道はなかった

そしてWindowsの時代となりフォントがOSに搭載されるようになってから
各メーカーが拡張していた漢字を相互運用できなくなるのは困るため
Microsoftは各拡張SJISを統合して改めてCP932として標準化した

もともとSJISを作ったのはMicrosoftなわけで
WindowsのSJISは、初期のSJISの正統後継といえる

**デフォルトの名無しさん** · 2021/02/24(水) 17:13:57.11

PC-98シリーズの漢字ROM、テキストVRAMはJISコードベースだ。SJISではない。

**デフォルトの名無しさん** · 2021/02/24(水) 18:38:57.51

PC-98のMS-DOSでShift_JISのファイルを何も問題なく開けたけど
漢字ROMがJISだとするとファイルを開く時にどこかでShift_JISからJISに変換していたという事？

**デフォルトの名無しさん** · 2021/02/24(水) 18:44:43.54

変換というかシフトしてる分を戻してるだけだな

**デフォルトの名無しさん** · 2021/02/25(木) 16:21:35.59

可変長で無限に文字を追加できる文字コードなると
全ての文字を実体参照で記録する形式にするしかないのでは？

**デフォルトの名無しさん** · 2021/02/25(木) 17:21:18.30

プレーンなgrepができなければ文字コード失格。
甲斐武田氏の家臣だけを抽出する正規表現クラス\p{KaiTakeda}みたいなのも使えなければダメ。

◆QZaw55cn4c · 2021/02/25(木) 19:01:31.51

>>574
VRAM が JIS ベースだ、という話というだけであって、ファイルが S-JIS だろうが UTF-16 であろうがどーでもいい話かと

**デフォルトの名無しさん** · 2021/02/25(木) 19:53:40.28

JISとSJISとEUC-JPの文字コードは
比較的単純な計算で変換することが出来るから
パフォーマンスの影響も少なくメモリも食わない

Unicodeの場合は変換にテーブルが必要になるから
MS-DOSの時代ではちょっと困るだろうな

**デフォルトの名無しさん** · 2021/02/26(金) 23:06:18.58

MS-DOS時代のテキストエディターで複数の文字コードに対応したものってあったんだろうか

**デフォルトの名無しさん** · 2021/02/27(土) 00:23:55.40

nemacsか

**デフォルトの名無しさん** · 2021/02/27(土) 03:48:22.68

単純計算だと非Unicode文字コード種ごとに128KBの変換テーブルが必要になる。
当時の揮発メモリに全部乗せたまま使うのは当然無理。LFUなりLRUなり使ってしのぐしかない。

◆QZaw55cn4c · 2021/02/27(土) 07:46:18.27

>>580
demacs/mule

**デフォルトの名無しさん** · 2021/03/03(水) 00:32:39.49

日本のsc2って今休業中なのかな
Unicode 14のalphaでKana Extended-Aに文字突っ込まれてるけどコメントしなくていいのか
このままbetaに進むと変更が難しくなりそうだけど

**デフォルトの名無しさん** · 2021/03/04(木) 21:20:40.72

ASCIIの制御文字にエスケープ文字(0x1b)や
その他の字の区切りを表す制御文字があるのに
メールでもHTMLでも制御文字は使わずに0x20-0x7eの印字可能文字の一部を
エスケープ文字として使うようになったのはなぜなのか

**デフォルトの名無しさん** · 2021/03/04(木) 22:12:23.62

ここで言うHTMLのエスケープ文字ってどれのこと？

**デフォルトの名無しさん** · 2021/03/04(木) 22:40:28.52

>>586
タグを示す<>や実体参照で使う&;

**デフォルトの名無しさん** · 2021/03/04(木) 23:10:32.38

その手の手書きする奴は図形文字じゃないと逆に不便じゃね？

**デフォルトの名無しさん** · 2021/03/04(木) 23:54:15.04

エスケープ文字に制御文字を使うと手で入力するのが面倒になるし
かといって図形文字を使うと文章中の文字と混同しないように注意しないといけなくなるから難しいか。
SJISの0x5c問題もこれが原因だよね。

**デフォルトの名無しさん** · 2021/03/05(金) 02:36:48.86

一言で言えば既存のテキストエディターで書けることを重視したから。
専用のハイパーテキスト用ツールは昔からあったけど不便だった。

**デフォルトの名無しさん** · 2021/03/05(金) 17:53:33.38

ISO系(特にUnicode)が理解できなさすぎて辛い・・・・・・
・古い規格は数万払って買えw
・原文英語だけど頑張って読めw
・1993年の初版からいーっぱい改定して規格書いーっぱいあるでw
・JIS 「こうやで(決してISO版原文の解説ではない)」
・UnicodeとISO/IEC 10646で同じ用語使ってますw
・規格書で定義されてない用語を平気で使いますw
・規格書にUCS-2, UCS-4の定義, 解説がない
・文献によってコードポイントの表記が微妙に違う
UCS-4はU+00000000のからなのか, U+0000からなのか？w
・UCS-2/4は符号化文字集合だぞwあっ、やっぱり文字符号化方式だぞw
・CJK 「俺らも理解してくれよなw」
・日本人　「Unicodeが理解できん？こうやで！^^(ソースなし！w)」

おれはUnicodeの理解を諦めたぞ・・・・・・

**デフォルトの名無しさん** · 2021/03/06(土) 02:52:41.34

まず unicode と ISO10646 は建前上は別の規格で用語も適用範囲も一致していないと理解することから。

**デフォルトの名無しさん** · 2021/03/06(土) 08:51:58.30

>>591
Unicodeは諦めるとして
次はPOSIXとC++のどちらに挑戦する？

**デフォルトの名無しさん** · 2021/03/06(土) 11:40:26.99

Unicode公式「ISOのUCS-4はUTF-32と同義語なんやでw」

おれ「UCSは符号化文字集合でUTF-32は符号化方式では？ムキーーーーーーッ？？！」

つらい
全てを投げ出して北海道グルメ旅行したい

**デフォルトの名無しさん** · 2021/03/06(土) 12:58:55.62

>>594
違うねん。
ISO10646 でも UCS-4 と UTF-32 は同じ意味で符号化方式やねん。
UCS: 符号化文字集合
UCS-4: 符号化方式
UTF-32: 符号化方式

ISO/IEC 10646:2017 の定義だと
9.4 UTF-32 (UCS-4)
UTF-32 (or UCS-4) is the UCS encoding form that assigns each UCS
scalar value to a single unsigned 32-bit code unit. The terms UTF-32
and UCS-4 can be used interchangeably to designate this encoding form.

**デフォルトの名無しさん** · 2021/03/06(土) 15:26:58.97

10646:2017だと明確に同義語として使われてたのか。
その版は持ってなくて中身確認できなかったから助かったわ

**デフォルトの名無しさん** · 2021/03/06(土) 15:41:25.54

マジで疲れた
UCS-4はUCSの部分集合だと思ってたけど実は違ったのかw
こんなことに悩んでたのかよクソすぎるw

**デフォルトの名無しさん** · 2021/03/06(土) 18:39:02.04

もしかして 10646:2020 を参照してん？なら UCS-4 という用語自体が過去の遺物扱いや。
10.4 UTF-32
UTF-32 is the UCS encoding form that assigns each UCS scalar value to a single unsigned 32-bit code unit.
NOTE — Former editions of this document included “UCS-4” as an alternate term synonymous with “UTF-32”. Use of the term “UCS-4” to refer to this encoding form is deprecated.

**デフォルトの名無しさん** · 2021/03/07(日) 12:36:06.36

あ、そこは見た
ただ10646:2020でいう「synonymous」が
どの程度の「同義」なのかが分からなかったけど
10646:2017を引用してくれたおかげで100％イコールなのが分かったわｻﾝｶﾞﾂな

**デフォルトの名無しさん** · 2021/03/07(日) 12:38:04.56

やっとこれでクソつまらん文字コードからC++の参考書に戻れる
やったぜ

**デフォルトの名無しさん** · 2021/03/07(日) 23:47:47.88

UTF (Unicode Transformation Format)という言葉も昔の遺産だよね
今作り直すならUnicode Encoding SchemeでUES-8とかになるのかな

**デフォルトの名無しさん** · 2021/03/08(月) 00:17:56.33

ちゃうねん。もともと UTF の U は unicode じゃなくて UCS や。Universal の U。

**デフォルトの名無しさん** · 2021/03/08(月) 11:33:52.88

文字コードという呼び方をなくして
文字シーケンスと言ったほうが良いと思う
1文字は最大8バイトで表現する

**デフォルトの名無しさん** · 2021/03/08(月) 12:58:27.48

EUCのU

**デフォルトの名無しさん** · 2021/03/08(月) 13:47:48.99

>>602
おおっと、これは失礼しました

**デフォルトの名無しさん** · 2021/03/08(月) 15:45:58.81

UTF-の後に続く数字は当初はバージョン番号のような意味だったのが
途中からビット数を表す意味に変わったようにも見える

**デフォルトの名無しさん** · 2021/03/08(月) 23:38:40.10

>>606
Unicodeの種別をUTF-なんとかと言い出したのは、1文字を16ビットで表現することに限界を感じたため。UTF-8は一番やりたくなかったけど、世界中の文字を切り替えて表現する方法は支持されなかったから、最小単位が8バイトのUTF-8が標準になった。

**デフォルトの名無しさん** · 2021/03/08(月) 23:41:28.57

SJISのように2バイトで表現するキャラクタセットとの相性を重視している場合はUTF-16が使われる。

**デフォルトの名無しさん** · 2021/03/09(火) 09:45:27.84

>>607
UTF-8が標準になったのはUnix系の互換性の問題
多バイト固定すると、文字列が1バイト前提であるC言語とC言語で作られてる
Unixのソースコードの多くを修正する必要があった。
そのため互換性があるUTF-8が作られた。

**デフォルトの名無しさん** · 2021/03/09(火) 11:10:37.15

>>609
EUCを知ってますか？

**デフォルトの名無しさん** · 2021/03/09(火) 11:13:42.05

>>610
EUCとUTF-8と同じようにC言語とC言語で作られてる
Unixのソースコードと互換性があるように作られたことを知ってますか？
そしてEUCがどうしましたか？

**デフォルトの名無しさん** · 2021/03/09(火) 17:39:10.59

キャラクタセットは選ぶもの

**デフォルトの名無しさん** · 2021/03/09(火) 17:40:37.43

アスキー文字は1バイトで同じ文字コードにしたいのはあたりまえ

**デフォルトの名無しさん** · 2021/03/09(火) 17:41:09.24

UTF-16にこだわったのは欧米人

**デフォルトの名無しさん** · 2021/03/09(火) 17:53:03.04

>>612
UTF-16を選べるというのなら選んでみるが良い
互換性がないキャラクタセットはサポートされていない

**デフォルトの名無しさん** · 2021/03/09(火) 19:47:21.10

UTF-16はユニコードの文学的表現と、あわしろ氏が言ってた。