文字コード総合スレ part8 [sc] | レス824-874

■ このスレッドは過去ログ倉庫に格納されています

1 2012/11/30(金) 13:16:02.46

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

ここまで見た

824 2014/04/19(土) 09:54:13.30: どちらかというと「安岡」という単語に猿のレベルで脊髄反射して
トロン信者認定のレスを貼る安岡信者の方がすごいと思う

ここまで見た

825 2014/04/19(土) 13:11:12.57: >>824
過去ログに残る執拗な叩きの痕跡という前提がまるで存在しないかのように、
件の彼に対する反応を「『安岡』という単語に猿のレベルで脊髄反射」ってことにするのはどうかと。
あなたが同列に「どちらがすごいか」を比べてるのが奇妙に思えるほど、件の彼の行動は異質。積み重ねがあるからね。

そしてもちろん、件の彼について話している人は
「この人はなぜ、疎まれることがわかっている場でなお1人で叩き書き込みを続けるモチベーションを持っているのだろう？」
という点を不思議に思って集まっているんであって、書き込みの動機は明確。ここから「安岡信者」と解釈はしづらい。

また、仮にもしそのなかに「安岡信者」が紛れ込んでいたとして、
その信者はこのスレで執拗に「敵」を叩き続けたりはしていない。
件の彼と違って人畜無害なのだから、ほうっておけば良い。

ここまで見た

826 2014/04/19(土) 13:15:43.09: おれなんでこのスレ常駐してんだっけ……

ここまで見た

827 2014/04/19(土) 13:43:05.46: >信者はこのスレで執拗に「敵」を叩き続けたりはしていない。

これには同意。
安岡信者は被害妄想が激しく
単発のレスで偏執に被害を主張するのが特徴だからね。

ここまで見た

828 2014/04/19(土) 17:03:56.09: >>822
NBSPが紛れこんでてイラっと来るやつかな

ここまで見た

829 2014/04/20(日) 08:23:30.09: 信者とか言い出す時点でどの発言も議論として無価値

ここまで見た

830 2014/04/21(月) 10:53:47.48: > 被害妄想が激しく
> 単発のレスで偏執に被害を主張するのが特徴だからね。

安岡さんに対して執拗に粘着している君の特徴じゃないかw

ここまで見た

831 2014/04/21(月) 19:22:16.02: 安岡センセイもビットコインに走っちゃったから…
…おっと誰か来たようだ

ここまで見た

832 2014/04/22(火) 02:46:51.52: 誰も来てない

ここまで見た

833 2014/04/22(火) 16:39:21.34: よそでやれよ気違いども

ここまで見た

834 2014/04/23(水) 01:02:12.57: サロゲートペアがらみで文字化けとか文字落ちは未だに良くありますか？
合成文字（アイヌ語表記用）などがうまく処理できないんですけど、完全にサポートをしないと割り切った人はいますか？

ここまで見た

835 2014/04/23(水) 01:11:50.85: サロゲートペアかどうかの判定なんていちいち入れないし
固定長に可変長混ぜたら何の意味もない

ここまで見た

836 2014/04/23(水) 01:58:46.32: 何か誤解してる様だが、元々Unicodeの文字表現は可変長

ここまで見た

837 2014/04/23(水) 18:34:35.68: はじめは16bit固定じゃないの？

ここまで見た

838 2014/04/23(水) 20:59:37.84: 「元々」って「当初は」って意味で書いてないのか
すまん

ここまで見た

839 2014/04/23(水) 21:11:18.40: 「か」と「゛」で「が」みたいに
二文字で一文字を表す合字があるんだから、
言語機能かライブラリを使うしか
現実的な対応方法ないだろ。

逆に言えば、それらを使っていれば
無視できる問題。

ここまで見た

840 2014/04/23(水) 21:34:36.00: UTF-8あたりとごっちゃになってる？

ここまで見た

841 2014/04/23(水) 21:52:29.17: 最初から UTF-16 も UTF-32 も可変長だけど
未だに固定長と思ってるやつなんかいるんだ？
そりゃすげーや

ここまで見た

842 2014/04/23(水) 21:58:56.82: そりゃ日本の官公庁相手に仕事してる分には
たいていそれで許されるからな

ここまで見た

843 2014/04/23(水) 22:22:44.74: >>841
「code pointを複数組み合わせた可変長で文字(grapheme)を表現する」っていう
Unicodeの基本をどうしても理解できない(認めたくない)人がいるんですよ。

ここまで見た

844 2014/04/23(水) 23:13:15.72: >>842

お役所が扱う人名なんて、それが許されない筆頭じゃなかろうか。

ここまで見た

845 2014/04/24(木) 11:06:30.10: Unicode1.0の頃はUCS-2。UTF-16は2.0から。
UCS-2はBMPの固定長エンコーディング。
まだ固定長原理主義者が多い頃だったから。

けどそれじゃBMP以外や合成文字どうすんねん、
規格の中で矛盾してるだろ、固定長原理主義無理だろってことで、
その辺入れたUTF-16になった。
たしかUTF系はベル研のケン・トンプソンが考えた8が最初。

うろ覚え書き込みだから、修正よろ。

ここまで見た

846 2014/04/25(金) 00:12:43.23: 修正不可能なくらい間違いまくってるよ。
そもそもUCSは文字集合を定めるものであり、UTFは個々の文字を
どう表現するかを定めるものであってまったく別の概念だし。

ここまで見た

847 2014/04/25(金) 08:45:09.27: CPUのエンディアンが複数あるため、UTF-16にはBEとLEがあります。
どのサイトも説明見ると大体こんなような事書いてあるけど意味が分からない
エンディアンがどうこうってエンコーディングの内部で解決されるべき問題でしょ？
CPUに合わせてLEを使うと速いですよって事？

ここまで見た

848 2014/04/25(金) 08:57:28.13: 絵文字統一か

ここまで見た

849 2014/04/25(金) 13:03:42.00: >>847
確かにその説明はおかしいと思う。
画像フォーマットでもtiffにはエンディアンの指定があるが、普通はどちらにも対応する。

ここまで見た

850 2014/04/25(金) 13:20:19.28: >>847
ちゃんとエンコーディングでBE,LEが考慮されてるでしょ？
それともBEとLEの存在自体が問題だといってんの？
何がおかしいかわからない

ここまで見た

851 2014/04/25(金) 13:55:02.90: 何を悩んでいるのかしら無いけど、
初期のUTF16の話として16bit固定っていうのはわかるよね？

C言語風に書くならば、WCHAR型（16bit）となって、
WCHAR *text = "あいうえお";
こういう定義になる。

この時のメモリ配列はC言語の仕様によりCPUのエンディアンによって変わる。
このメモリ内容がUTF-16BEやUTF-16LEなんだよ。

ファイルに保存するときはどちらかに統一してもいいが、
処理を速くするためにCPUに合わせた形式でメモリには格納しないといけない。
だからUTF16-BEかUTF16-LEというものが生まれることになる。

メモリ内で使うために、UTF16-BE と UTF16-LE の存在を無くすことは出来ない。
そのメモリ内容をそのまま保存することもある。テキストファイルではなくて
構造体データの一部としてテキストが含まれている場合とか、一項目ずつ保存するのではなくて
メモリの構造体データを丸ごと保存したりするからね。

だから、UTF16-BEかUTF16-LEという存在はCPUのエンディアンの存在によって生まれ、
それを保存するファイルに格納されたデータの呼び名にもなる。

ここまで見た

852 2014/04/25(金) 14:14:58.98: テキストファイルで保存するときでもLEとBEを選べるエディタがあるんだが
それはおかしいのか？

ここまで見た

853 2014/04/25(金) 14:19:55.61: 世の中に二つの形式があるのなら、
二つの形式を選べるのが普通でしょう？

エンディアンが違うCPUとの間でもファイルの交換や、
ネットワーク通信できるんだから。

ここまで見た

854 2014/04/25(金) 14:57:01.01: > C言語風に書くならば、WCHAR型（16bit）となって、
> WCHAR *text = "あいうえお";
> こういう定義になる。
WCHAR *text = L"あいうえお";
じゃね？

ここまで見た

855 2014/04/25(金) 15:01:18.03: 別にC言語風だからどうでもいいよ

ここまで見た

856 2014/04/25(金) 15:34:10.60: たまには。PDPエンディアンのことも思い出してあげて

ここまで見た

857 2014/04/25(金) 15:49:44.73: エンディアン嘘つかない

ここまで見た

858 2014/04/25(金) 17:51:44.43: >>845
UCSとUTFの区別は最初はなかった。
最初はUCSのみ。
>>845も書いてるけど。

ここまで見た

859 2014/04/25(金) 17:56:44.39: >>847
UTF-16文字列はuint16_tの並び。
uint16_tだからCPUによってバイト順が違う。
だからエンコーディングのバイトオーダーが決まってると、
逆順のシステムはネットワークにデータを流す時にバイト順を毎回変えないといけない。
それを防ぐためにバイトオーダー順違いのエンコーディングが定義されてる。
こうしておくと必要なときだけバイト順を変えればいい。
DCE/RPCみたいに接続時にバイトオーダをネゴしてもいいし、
どちらを送られても必ず扱えるようにしてもいい。

ここまで見た

860 2014/04/25(金) 18:34:47.40: レスありがとう
2つの(代表的な)エンディアンがあってだからBEとLEがありますだと理由付けとして弱い、何か他にあるんじゃないの？？って疑問でした。
だから
>処理を速くするためにCPUに合わせた形式でメモリには格納しないといけない。
という事情があると知り納得しました。