2012年3月プログラム165: UnicodeとUTF-8の違いは? その2 (711)
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
Coqスレ (138)
初心者向け新言語 Small Basic スレ (240)
メガデモを語る fr-08 (603)
【O3D】HTML5用 3D API WebGL 【Canvas:3D】 (367)
くだすれC++Builder(超初心者用)その4 (974)
【自動】株式トレーディングシステム Part6【売買】 (141)
UnicodeとUTF-8の違いは? その2
1 :10/11/30 富士通だとデフォルトでは生成されない frt -c -Am -M./ (なんとか.f90) でいけるのではなかろうか。いずれにせよ、 frt -help | less とかやって、"module"で検索を掛けるのが吉。
2 :10/11/30 アイちゃんによる誤爆スレ立てでした
3 :10/11/30 このスレッドは天才pンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
4 :10/12/09 つ゚
5 :10/12/09 | ,.-――――‐ 、 ..| | / ,.-――┴- 、 .| | 以下 / | /: : l、: : : ;l: : : : :\. .| | イカペディア創設者 / :! ./: : :、: :!_\;/ _V\ : |` | | イカ娘からの 〈 ___V: : : :|∧| __`|∨ | | メッセージをお読みください ` ̄丁 |: |:l :| __ 〃⌒V| | | ヽ|: NV:!〃⌒__ //}| | | /: :{_|: :|//f´ ヽ} 八 | | _/: :/:/ : ト .丶___,ノイ\_:\. | | __,/: :_;/: /,.イ⌒ヽ!ヽ: ト、\ !: |__ |  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
6 :10/12/15 ,. ――- 、_ / \` 、 / ___ \ \ 人類よ、よく聞け! // . ´: : : : : : : :` 、 ヽ \ 今からこのスレを / / ./: : : : : : : : : : : : : : : \i: 〉 人類侵略の拠点に / / / : : : : : : : : : : : 八: : : : : : :ヽ./ させていただくでゲソ . / :i/: : : :\: __: : : : :-/―}ハ‐ : : : : : i __ 〈 /: : : : : /\: : : : / ,x≠ミx、: :∧| / } \i: : : : :/ |:| \:/ んィハ }}V:|):{ ./ / |: : : : : : ト| 弋ぅり {: :、: \__/ /__ ,. ┐ ∨\: : :| ,x≠ , ハ: : \:__:/ /: : : : : :`ン'’ ノ \|ヘ〃 r  ̄} /: : \:_____/ /´ ̄ ̄/ / \ / : : ∧ \ __ノ/L.,ィ'⌒ヽ:_/ /: ̄`ン' / ヽ: : : :! /: : :〃: :,>ー;‐┬ ´ /{{ /:/ ハ:>'´ /、 j: : : | ___,/: ://: : :{ 〃 八 / ∨/ /ヽ: : ', /: : :/ / : : : : : : ://: : :,ハ {{ |\ __/ V:f '⌒ヽ }: :| \: :\ / : :/´ ̄ ̄/ : : / j : ヽ}}:! / |: | { / /},: : / _/: : / {: : :{ / />くつ/: : : :リ '. / / :! : 、 V´ ̄ ,.イ/ : / | : : : :| 、: : 、 |:{ r_〉}ヽ: : :{ ∨ \: \ \― ´ /' : 〈 ! : : : : | \: :\ 、:\__): }\:、 ` ┬ヽ._}=一'´ 〉: : 〉 ! : : : : |
7 :10/12/16 524 名前:デフォルトの名無しさん [sage]: 2010/09/26(日) 02:22:11 BOMの扱いが決定不可能な問題について質問と言う形で出す ↓ 変な子が、ファイルサイズと文字長は違うよと言ってくる ↓ 知ってると返す ↓ 変な子が、人が扱う文字長とプログラムで扱う文字長は違うと言ってくる ↓ 知ってると返す ↓ 変な子が、いやおれの中では文字長と言えばこう定義されてるし別物なんだよと言ってくる ↓ だから、そんな話はしていないからもうレスしなくていいよと返す ↓ 変な子が、人が扱う文字長とプログラムで扱う文字長は違うんだよ!昔からの当たり前の話だろうと言ってくる ↓ 開いた口がふさがらない ↓ 変な子が、コンピュータ処理で言う1文字と人が認識する1文字とは違うんじゃないのと、また繰り返してる ↓ もうやだこの馬鹿 ←いまここ
8 :10/12/16 1 名前:デフォルトの名無しさん [sage]: 2007/04/30(月) 20:02:37 ビッグインディアンとかなんとかかんとか
9 :10/12/17 皆様へのお願い このスレッドは高次機能障害をもたらす 病理の臨床実験のために立てたものです。 被験者と研究員のやり取りに使うため、 書き込み等は自重されるようお願いいたします。 もし、書き込み等をすることで不愉快な思いをされましても、 当研究所は責を負いかねます。 (社)京都微生物研究所
10 :10/12/17 ,.-―― 、 / ,.- ┴- 、 /.| /:´ : : : : : : : :ヽ . / :! i{: : : :/\;/ V }: :ゝ 〈.__V l:l:V-‐ ´ ‐ ,'l:/ <人間ども、昔ETという映画があったことを知らなイカ? . ヽ|: l: l、 ヮ_.ノ:l <ETという宇宙人によって地球が侵略される話でゲソ . _/:/`,}:`ス/ ̄ ̄ ̄ ̄/ <そして、次の瞬間、貴様はキーボードのEとTを見て驚愕するでゲソー /: : :(__::::つ/ FMV / カタカタ .. ̄ ̄ ̄ ̄ ̄\/____/ ̄ ̄
11 :10/12/17 うーん、EとTを見ても驚愕すべきものがなにも見つからない。 目の前にキーボードが2台並んでいるのだが……
12 :10/12/17 EとTの間にはRがある Rと言えば思い出すのは そう Ruby
13 :10/12/18 1 名前:デフォルトの名無しさん [age]: 2010/05/27(木) 14:17:17 前スレでなんとなくわかったのですが、インディアンがどうとかいうあたりで 話について行けなくなりました。 2 名前:デフォルトの名無しさん [sage]: 2010/05/27(木) 14:20:27 次スレいるのかよw
14 :10/12/18 117 名前:デフォルトの名無しさん [sage]: 2010/06/22(火) 08:42:27 おかしい人は相手をせず放置するのがいちばんですよ。 でもここはおかしい人隔離スレかw
15 :10/12/18 173 名前:デフォルトの名無しさん [sage]: 2010/07/05(月) 21:18:23 >>164 文字コードと改行コードの話はキチガイ信者が集まるものだよ。 ネットニュースのうさげの時代からずっと。 そんな人達の隔離スレがここゆっくりしていってね
16 :10/12/19 <!-- 美 -->
17 :10/12/19 ここはシフトジスです。美はいりません。
18 :10/12/19 <!-- 入口 -->
19 :10/12/20 971 名前:デフォルトの名無しさん [sage]: 2010/05/24(月) 20:09:15 結局UnicodeとUTF-8の違いは何なのでしょうか。 符号化文字集合Unicodeにも各文字に符号が振られているのに さらにUTF-8が符号化方式とかわけわかりません。 972 名前:デフォルトの名無しさん [sage]: 2010/05/24(月) 20:15:38 Unicodeは文字に番号を振っているだけ。ビットもバイトも関係ない。 そのUnicode番号を、バイト(正確にはオクテット)データの連続として 表現する方法の一つがUTF-8。 973 名前:デフォルトの名無しさん [sage]: 2010/05/24(月) 22:06:07 Unicode: 単なる「文字の表」で、あいうえお表のようなもの。 便利にするために、文字ごとに番号がついてあるけど、 その番号はコンピュータ上のデータとは何ら関係がない。単なる整理番号。 UTF-8, UTF-16など: Unicodeの表にある文字をコンピュータ上で表現したいとき、 どういう手順で表せばいいかを定めた「決まりごと」。 Unicode表の文字をコンピュータ上のデータに変換する規則、 コンピュータ上のデータをUnicode表の文字に変換する規則が定められている。 Unicode系の規格では「文字の表」と「決まりごと」が一組そろってはじめて、文字とデータの対応付けができる。 ASCIIコードでは、表と決まりごとの区別はあんまり明確じゃない。 Shift_JIS, iso-2022-jp, euc-jpは全部「決まりごと」で、やっぱり「文字の表」がないと意味をなさない。 そいつらはUnicode表じゃなくて、JISコードって表のための決まりごと。
20 :10/12/20 977 名前:デフォルトの名無しさん [sage]: 2010/05/25(火) 09:34:36 >>975 VB6の動作は知らないが、インディアン付きってなんだw BOM付きか、リトルエンディアンかどっちかの勘違いだと思うけど。 エンディアン: ガリバー旅行記に出てくる、卵を尖った方から割る種族、丸い方から割る種族に由来。 データの格納順序。例えば、16ビットデータ0xFEFFを表すとき、 FE FFのように、桁の大きい方から表すのがビッグエンディアン FF FEのように、8ビットずつ区切って桁の小さい方から表すのがリトルエンディアン CPUによって、どっちがやりやすいかはある程度決まってくる。 例えばx86系(パーソナルコンピュータのCPUは全部これ、と思っても特に差し支えない)は リトルエンディアンなCPUなので、何も考えずにUTF-16テキストを作るとリトルエンディアンになる。 BOM(Byte Order Mark): ユニコード表のU+FEFFの文字のこと。 UTF-16で、この文字を頭に入れておくと、あら不思議。エンディアン(バイトの並び順=Byte Order)が分かっちゃう。 より具体的には、UTF-16でU+FEFFは0xFEFFなので、 これがFE FFのように入っていたらビッグエンディアン、FF FEのように入っていたらリトルエンディアン。 UTF-8には、エンディアンの違いはないので、Byte Orderを示す必要がない。 けれども、これが頭に入ってたらUTF-8だって判別しやすいよね、ということでsignature(しるし)として 入れることが認められている。
21 :10/12/25 >>1 本スレ>>1 です。紛らわしいスレを立てないでください。 とはいえ、本スレが埋まったらまたここに来ますです。
22 :11/01/01 unicodeはfffeのボムつきutf-16リトルエンディアン メモ帳がそうだ
23 :11/01/18 JIS漢字コードとシフトJISコードの違いは何でしょうか。 区点コードとシフトJISコードの違いは何でしょうか。
24 :11/01/18 http://msdn.microsoft.com/ja-jp/library/cwe8bzh0(v=VS.100).aspx >Unicode は 16 ビットの文字セットで、すべての言語に対する十分な表現能力を持っています。 >すべての ASCII 文字は、拡張文字として Unicode の中に含まれます。 WindowsにおけるUnicode(の文字符号化方式)とはUTF-16(またはUCS-2)の意味。 >このドキュメントでは、MBCS は、Unicode でサポートされていないすべてのマルチバイト文字を指します。 >Visual C++ では、MBCS は常に DBCS を意味します。 2 バイトを超える文字セットはサポートされていません。 WindowsにおいてはUnicodeがUTF-16(またはUSC-2)の意味なので UTF-7やUTF-8はサポートされない。 http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx >1200 utf-16 Unicode UTF-16, little endian byte order (BMP of ISO 10646); available only to managed applications コードページ1200(UTF-16)はネイティブなVC++では使えない。 VC++でネイティヴアプリケーションを記述する限り、 Unicodeの全文字を利用する方法はない。 これでOK?^^;
25 :11/01/18 >>23 JIS漢字コードってなんですか。JIS X 0208 のことですか。 シフトJISコードってなんですか。シフト符号化表現のことですか。 区点コードってなんですか。区点番号のことですか。 勝手な用語を使われたら誰も何も答えられません。
26 :11/01/18 目指してる 未来が違うwwww byシャープ http://twitter.com/ozawa_yuuki/status/6549767047872513
27 :11/01/18 最近ようやくわかってきたんだ。つまり、Unicodeを扱えないのはコンソールなんだよ。
28 :11/01/18 ええ〜〜っ!JIS漢字コードを知らないひとがいるのぉ? ええ〜〜っ!シフトJISコードを知らないひとがいるのぉ? ええ〜〜っ!区点コードを知らないひとがいるのぉ? ばっかみた〜い
29 :11/01/18 「コンソール」って何ですか?
30 :11/01/19 command.com のことかな
31 :11/01/19 chcp 65001
32 :11/01/19 cp65001はUTF-8なので今度はVC++が対応しないね。
33 :11/01/19 Windowsのシステムロケールを英語にしてからcp650001にするとける
34 :11/01/19 >>28 自分がバカを晒していることに気付かないバカ
35 :11/01/26 前スレが見当たらないんだが、物凄い勢いでDAT落ち?
36 :11/01/26 987で落ちたみたいだね UnicodeとUTF-8の違いは? その2 http://hibari.2ch.net/test/read.cgi/tech/1274937437/
37 :11/01/26 980超えて24時間書き込みがないと自動的に落ちる、だっけ。
38 :11/01/28 隔離スレ浮上
39 :11/02/01 コンソールってのは辞書を引くと「慰める」。 つまりーのことだったんだよ
40 :11/02/01 確かに肌荒れしたところに塗ると痛みが引くよね
41 :11/02/01
42 :11/02/02 珍宝に塗るのがオヌヌメ
43 :11/02/02 >>39 琉球語で「いらっしゃい」の意味じゃなかったの?
44 :11/02/03 >>24 >VC++でネイティヴアプリケーションを記述する限り、 >Unicodeの全文字を利用する方法はない。 どれだけ無知なんだよ。Unicode(UTF-16)版API使うに決まってんだろ。 >>25 >シフトJISコードってなんですか。シフト符号化表現のことですか。 相変わらずJIS信者はキモいな。シフトJISはシフトJISだよ。
45 :11/02/03 それはWindows SDKであって、Visual C++ではないんじゃないか? みたいなつっこみでどうでしょう。
46 :11/02/04 >>45 で、それが問題になるケースは?
47 :11/02/04 ないね。2003以降はSDKにVCコンパイラくっついてるし。逆もまた真だし。
48 :11/02/04 VC++ で BOM なしで UTF-8 通るようになったら もう完全に引っ越すんだけどな
49 :11/02/04 引っ越さない理由がわからない。BOMありで何か問題が?
50 :11/02/04 > >シフトJISコードってなんですか。シフト符号化表現のことですか。 > 相変わらずJIS信者はキモいな。シフトJISはシフトJISだよ。 CP932 とか Windows-32J で混乱してばいいと思うよ。
51 :11/02/04 Unix - 「UTF-8にBOMはいらないんだよ糞が」派 Windows - 「BOMねえとエンコーディングの判別が面倒すぎるだろ糞が」派
52 :11/02/04 俺 - じゃあ、なんも悩まなくいいように全部何から何までBOMなしUTF-8にしようぜ! バイト列だからとかホザいてるFSもな!
53 :11/02/04 >>51 「shebang の次の行に書いておけばいいだろ」派
54 :11/02/04 Cのソースとかにまでshebang書いてたらアホだと思われるぞ 実際アホなんだろうけど
55 :11/02/04 もともとUTF-8の規格にはBOMないし BOMがあるとUTF-8の利点である1バイト部分がLaten-1互換ってのも失われちゃうし ぱいなんじゃなかったっけ?
56 :11/02/04 綴り間違ってるし互換性なんてないし 古いエンコードでバシッと表示できる可能性がミジンコくらい有るのはASCIIだけだよ
57 :11/02/04 >>56 バックスラッシュとチルダは?
58 :11/02/05 ASCIIだから問題ないでしょ。 JIS X 0201左面じゃないんだから。
59 :11/02/06 >>51 ファイル名に BOM 付ける訳にいかないしなぁ
60 :11/02/06 >>59 実はお前、馬鹿ですね
61 :11/02/06 >>54 shebang という事は TCC 使いなのかもね。 http://bellard.org/tcc/
62 :11/02/06 >>61 申し訳ございませんが tcc と shebang の関係について私には分かり兼ねますので ご高説賜りたく望む所存でございます
63 :11/02/06 >>61 TCCでコンパイルすると出来上がったexeにアンチウィルスソフトが反応してワロス ここのひとも同じみたいだ >ttp://www.mail-archive.com/tinycc-devel@nongnu.org/msg02244.html
64 :11/02/06 >>62 リンク先嫁
65 :11/02/06 >>64 ># C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line. ありがとうございました
66 :11/02/06 >>61 TCC でも動作確認出来ました。 ttp://www1.axfc.net/uploader/Sc/so/202217.zip&key=tcc ほんとうにありがとうございました。
67 :11/02/06 >>59-60 ファイル名に BOM 付けたければ付ければ?
68 :11/02/06 RFCは規格とイコールではないし、規格だって法とイコールでもない Unicode関連が元々どうしようもないクソ規格なんだから、適当にならざるを得ないんだよ 四角四面に適用可能なほど出来のいい規格じゃねーし
69 :11/02/06 BOMって結局>>51 の言うように、「美」の代わりなの? BOMのバイト列が先頭に出現する符号化方式って他に無いの?
70 :11/02/06 >>69 > BOMのバイト列が先頭に出現する符号化方式って他に無いの? Latin-1をはじめとするシングルバイト全部
71 :11/02/06 じゃあUTF-16って言う前提が無いとダメなの? 具体的に役立つ場面が想像付かない。 あまり聞くのも迷惑だろうし、判りやすいサイトがあれば誘導してほしいです
72 :11/02/06 たしかにBOM付いてると UTF-8でもVC++通るな
73 :11/02/06 >>71 君の疑問は君の無知から来ているわけではなく、 BOMの矛盾がそのままあなたの頭の中のモヤモヤになってるだけ。
74 :11/02/06 >>70 確かに[FE FF 41 41]のファイルはLatin-1ともUTF-16とも。 (VC#で確認したけどデフォルトではEncoding無視してBOM優先なんですね。ちょっと驚いた) 前スレも見てきたけどBOMについては賛否あるみたいなんで、 あんまり関わらないようにします。
75 :11/02/09 >>71 偶然先頭にBOMが来ることは少ない、という前提の元では、 ファイルが、自身のエンコード方式を明確にする目的での利用にはそれなりに役に立つ。 けどBOMなしUTF-16というものもあるので、 アプリが、ファイルのエンコードを知るという目的では微妙。
76 :11/02/09 >>73 >BOMの矛盾 何も矛盾してないだろ。矛盾とは何? エンコーディングを確実に判断するにはメタデータが必要に決まっているし、 BOMはUnicodeを他のエンコーディングと区別できることを保障している わけではない。
77 :11/02/10 >>71 も>>73 も同レベルの無知だと思うよ
78 :11/02/10 じゃあ俺も!
79 :11/02/10 だな >>75 も無知の部類
80 :11/02/10 うざいなあ 低能なネタ振りは無視すれいちいちツッコミ入れるな
81 :11/02/10 それも無視すれば良いんじゃないの
82 :11/02/10 >>75 の認識で何が間違ってる? 無知じゃない人おしえて
83 :11/02/10 ------ はいはい ここまで読んだ ------
84 :11/02/10 >>75 はあれだろ。 「挨拶は人間同士のコミュニケーションを円滑にするが、 挨拶しない人もいるので、挨拶の必要性を感じない」ってレベル。
85 :11/02/10 コードポイントとスカラー値の違いは何でしょうか?
86 :11/02/10 コードポイントというのは抽象的な概念で、Unicode 以外の文字集合の (たとえば JIX X 0208 の「何区何点」)も「コードポイント」。 スカラー値というのは Unicode の概念で、コードポイントを示す具体的な 整数値。
87 :11/02/10 >>86 そういうことなんだ。 d
88 :11/02/10 バカと無知の違いは何でしょうか?
89 :11/02/10 無知は知識を獲得すれば問題なくなる バカは死ななきゃ治らない
90 :11/02/10 const int バカ = 0; int 無知; // uninitialized
91 :11/02/10 人格的な理由によるバカならば、稀にconst_castが効くこともある
92 :11/02/10 ただし膨大なコストを伴う
93 :11/02/10 UTF-8 なファイルに BOM を付けるのは、渋谷の交差点ですれ違う人全員に挨拶するレベルかな
94 :11/02/10 的外れなたとえ話は要らん
95 :11/02/10 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf8"> これでじゅうぶんやん。何が不満なの?ワケがわかりません。
96 :11/02/10 <?xml encoding="UTF-8"> これでもいいし。まぁ煮たようなのは他にも -*- coding: UTF-8 -*- とか vim:fileencoding=UTF-8 とか use utf8; とかあるらしいけど、実際に使った事がないから知らん。 なんでソレじゃダメなのさ?
97 :11/02/10 おそらく誰も明確には答えられんだろうな。
98 :11/02/10 <?xml encoding="UTF-8"> -*- coding: UTF-8 -*- vim:fileencoding=UTF-8 これらは coding="UTF-8" coding: UTF-8 coding=UTF-8 の部分のマッチだけ見てるよ
99 :11/02/11 コーディングマッチ子先生
100 :11/02/11 その手の手法は、元来レイヤーが違うところに情報を持たせている気持ち悪さはあるな 例えば、文字コード変換との相性は明らかに良くないし、対処法も美しくない BOMと比べてどうかはまた別の話だが
101 :11/02/11 実際のエンコーディングと異なるエンコーディング名を指定できるし UTF-16で破綻するしBOMより酷いと思う
102 :11/02/11 世の中の流れとしては 旧 HTML → media type で指定。デフォルトなし ↓ XML → デフォルトは Unicode だが指定可能 新 JSON, YAML → Unicode 以外不可 となっている。Unicode 以外不可なら BOM で判別がつく(なければ UTF-8)。
103 :11/02/11 >>84 そう解釈したのならバカ。挨拶ってのがセンスのない例えなので、違和感は出るが 挨拶しない人もいるから、挨拶してもらえるつもりでいてはいけない の方が近い。
104 :11/02/11 >>102 昔のHTMLは、そもそも多言語対応 してなかった。 JSONは、パーサー次第だろ。 「世の中」としては、UTF-8に収束 しつつも、統合されるのはまだまだ 遠い将来、くらい?
105 :11/02/11 YAMLもUTF-8で通るライブラリと通らないのがある >>104 >しつつも、統合されるのはまだまだ >遠い将来、くらい? もう目の前まで来てる
106 :11/02/11 最初っからUCS-4なら統合も素直に喜べたんだけどねぇ
107 :11/02/11 >>104 多言語対応と複数文字コード対応は全く違う話。
108 :11/02/11 >実際のエンコーディングと異なるエンコーディング名を指定できるし そげなことを言い始めたら話が先に進まんぜ。 シフトJISの文書ファイルにUTF-8のBOMを埋め込むことだってできる。 偽装しようと思えば何だってできるやろ。 他人の考えを否定するばかりでなく、自分で何か建設的な意見は言えんの?
109 :11/02/11 動画とおんなじようにテキストファイル用のコンテナフォーマットを作って BOMだの言語タグだのコーディング指定だのはそっちに入れるのがいい テキストとBOMとごっちゃに規格管理しようとするから混乱する
110 :11/02/11 まあ安易だわな。 必須にならなくてよかったよ。 そのうち死滅するだろう。
111 :11/02/11 SJISにBOMを付けるなんてのは意図的に破壊しないと出てこないと思うが。少なくとも 文字コード変換と同列の問題じゃない。 実際問題、文字コード変換をしようとしたら、どれが一番楽かはともかく、データ内に 文字コード情報を埋め込むやり方は一番面倒だ。設計的には美しくない。かといって、 既存の枠組みから大幅に異なるコンテナを作ったところで誰も使わないだろう。 UTF-8で全部片付くほど綺麗な世界でもない。BMPだけなのか、UCS-4まで行ける のか、同じUTF-8でも別扱いにしないとまずい世界が既にあるのだし。 BOM付きUTF-8への対応も進んでいるし、推奨もしないが排除する必要も無かろう。 大体、CJKなんて糞仕様を作った糞コンソーシアムに盲従する必要も全く感じない。
112 :11/02/11 いいかげんすぎるのも困るが、原理原則でガチガチなのも困るわな
113 :11/02/11 これだけ対応ソフトが出回ると、死滅はしないんじゃないか? まぁ、使わなくても個人的には全く困らないっつーか、BOM無しに統一された世界なら むしろその方が楽だから、非対応に戻すのが流行ったりしたら死滅するだろうけど。 あと、美しく新しいテキストファイルのコンテナ、とか考えていいのは中学生までだな。
114 :11/02/11 コンテナとか難しいこと考えんでも、"\033$@" と "\033(J" で囲めばええやん
115 :11/02/12 >>108 他人の考えを否定するばかりって…w conding=UTF-8埋め込みじゃあ例えばSJISにコード変換しただけで破綻するじゃない コード変換は普通に行われるから、それを指摘しただけなのにw
116 :11/02/12 >>115 > conding=UTF-8埋め込みじゃあ例えばSJISにコード変換しただけで破綻するじゃない それは現状のコード変換がconding=UTF-8を認識せずにコード変換するからであって conding=UTF-8をコード指定として認識するコード変換ツールは、変換後のコード名を 埋め込み直すんじゃないでしょうか?
117 :11/02/12 コード変換ツールは必ず coding=*** を正しく認識して埋め込み直しなさい。 ユーザーは一行目に coding *** などと間違われやすいテキストを書いてはいけない。 ユーザーはテキストエディタで開けば書き直せる状態だけど coding=*** を書き換えてはいけない。 制約が多いなあ。
118 :11/02/12 それは文字コード変換なのだろうか? そもそも文字コード間の文字って完全に対応が決まってるわけじゃないし どうやっても何らかの問題を含んでしまいそうだ コンセンサンスのある文字コード変換手法が定まってればいいんだろうけど どうせ「Windowsと同じ挙動にすること」ってなったりしそうで実装者がかわいそう
119 :11/02/12 >>108 馬鹿にかまうな
120 :11/02/12 詭弁のガイドライン
121 :11/02/12 おまいらアフォ杉w コード変換する必要の無いように、coding=*** を埋め込むんじゃないか。 コード変換する必要があるのは、コードが不明だから。 判明してれば変換する必要は無いだろ。
122 :11/02/12 >>121 アフォなプログラマ・アプリは山ほどあるぞ
123 :11/02/12 >>107 何が違うのかわかんね。 ちなみに「多言語対応」は、英語系以外の 言語の対応のつもりで書いた。
124 :11/02/12 >>105 >もう目の前まで来てる ガラパゴスなめんな!
125 :11/02/12 コード変換ツールは、METAタグ、XMLタグ、coding=*、using文、その他もろもろを正確に 認識しなければならない。 また、例えばプログラムのコード、ログファイル、ドキュメントなどにMETAタグがサンプル として埋まっている場合は、それは言語コード指定ではないので変換してはならない。 アホかと。 「コード変換ツールが対応すればいい」とか言ってる奴は、一生プログラムを書くべきじゃ ないレベルだろ。
126 :11/02/12 >>121 が何を言いたいのか分からん 適当な言語で非ASCIIで破綻しない正規表現マッOをしようとしたとして、シフトJISと 判明しているテキストが送られてきた場合、coding=Shift_JISって埋まってたら、どんな プログラム言語でも変換せずに処理できるとでも?
127 :11/02/12 日本語でおねがいします
128 :11/02/12 この場合適当とは文字通り適当ということを指します
129 :11/02/26 http://hibari.2ch.net/test/read.cgi/tech/1295493964/210-
130 :11/02/26 >>129 UTF-32は固定長でないと書いてありますが、これはどういう意味でしょうか? 合成文字があるから1文字が必ずしも32bitでないということを言っているのでしょうか? http://hibari.2ch.net/test/read.cgi/tech/1295493964/228 >228 :デフォルトの名無しさん:2011/02/26(土) 02:22:47.15 >いまどき、欧米人以外でUTF-32が固定長とか思ってる奴がいるんだな。 >CJKの当事者としてもうちょっと勉強しようぜ。
131 :11/02/26 >>130 普通に考えたらそうだと思うけど、その人が本当に何を考えてそう発言したのかは 向こうで聞かないと分からないと思われ コードポイントの話に反論が無かった所を見ると、まあ間違いないとは思うけどね
132 :11/02/26 合成文字だろ。
133 :11/02/26 >>131-132 やはりそういうことですよね。 d
134 :11/02/26 CJKとかアホなことして切り詰めた意味は全く無かったよな
135 :11/02/26 そうだね
136 :11/02/26 http://benlynn.blogspot.com/2011/02/utf-8-good-utf-16-bad.html CJK を使ってなくても分かる話だよな
137 :11/04/16 突然だけど、俺、今日ソープで捨ててくる。 11時に電話で予約入れた。どきどき お前らも今時シフトジスなんて使わずMancode使えよ
138 :11/04/16
139 :11/04/16 >>137 体験レポートもよろしく。 自分の場合、の中がゆるく感じて、あまり気持ちいいとは思わなかった。
140 :11/04/16 シフトジスは最大2バイトだからしまりが良い
141 :11/04/16 川崎ソプに行ってきた。 騎乗位は何故かチソコ痛いだけで苦痛だったけど 正常位はむちゃくちゃ気持ち良かった。 緊張して何話したか覚えてないけど、優しくしてもらえたよ。 お前らもMancodeなんて使ってないで。UTF-8使った方がいいよマジ
142 :11/04/30 最近OUTLOOKの設定を「Unicode(UTF-8)」にしたんだけど、 相手が読めなかったり 問題ある? あとUTF-8が括弧書きされてるのはUTF-8はUnicodeの一種ってい 理解でいいのかな
143 :11/04/30 >UTF-8はUnicodeの一種 軽く目まいがしたぜ・・・
144 :11/04/30 問題ないだろ。Unicode規格で定められたエンコーディングの一つがUTF-8。 「Unicode」が符号化文字集合の名前だなんてUnicode規格のどこにも書いてないし、 「Unicode」をUTF-16の意で使うのはマイクロソフトだけ
145 :11/04/30 Unicodeの一種、っていう呼び方は語弊があるな。 「魚の一種」というなら対象は魚であるべきだし 「Unicodeの一種」というなら対象はUnicode(つまり規格)であるべきなんだ 日本語の問題だな UTF-8は規格は規格でもUnicodeの符号化方式の規格であって、言うなれば 上の例でたとえるなら「フグの白子って魚の一種ですよね?」と聞いているようなもの フグは魚の一種だが、フグの白子は魚の一種ではない 「Unicodeの一種」と呼べるのは、例えばUnicode 1.0.1とかUnicode 6.0.0とかだな この二つは全然違うけどどちらもUnicode
146 :11/04/30 まああれだ。「原材料:魚(フグの白子)」みたいなもんだ。
147 :11/04/30 区点コードってJISコードの一種ですよね?
148 :11/04/30 JISの文字集合のインデックスです。
149 :11/05/01 とある文字集合の・・・
150 :11/05/01 >>147 JISコードの定義は?
151 :11/05/01 JIS X 0208文字集合
152 :11/05/01 いまどきのガキはJIS26も知らんのか。
153 :11/05/01 知らん
154 :11/05/14 Unicodeの理解が間違ってたようですみません。 メール本文は文字化けしないようなのですが、返信メールの宛先が 「"=?utf-8?B?=" aaa@bbb」みたいになってしまいます。 相手のメールソフトがMIMEエンコードを認識できないことがあるようです。
155 :11/05/15 携帯に歩数計アプリ入れてるんだけどさ、今日は10646歩だったぜ。キリがいい
156 :11/05/29 前スレの、ISO-2022-JPがIEで文字化けする問題だけど、MSのブログはアホが多いな。 「文字コードの指定の無いページで文字化けが起こるようになりました」とか言う奴は 死んだ方がいい
157 :11/06/02 前スレとか半年越しで言われても何の話かわからん
158 :11/06/02 984 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 14:21:57 いや、最近IEを更新すると、 META書いてあってもISO-2022-JPが化けるようになった。 985 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 17:03:21 >>984 ISO-2022-JP は IE でも見れるって 話じゃなかったのか? 見れなくなったのか。 986 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 21:39:59 >>985 http://blogs.msdn.com/b/ie_jp/archive/2010/12/17/ms10-090.aspx 987 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 22:57:09 HTTPヘッダだと認識してhttp-equivで認識しないってなんだよ。 いずれにせよHTMLでのISO-2022-JPに未来はないと。
159 :11/06/05 Unicodeはインディアン依存で、UTF-8はインディアン無関係っていう理解でOK?
160 :11/06/05 合ってるような、合ってないような
161 :11/06/05 規格としてのUnicode:バイトオーダー依存のUTF-16や非依存のUTF-8を含む規格 MS用語としてのUnicode:リトルエンディアン固定のUTF-16 UTF-8: バイトオーダー非依存でおk
162 :11/06/05 嘘つかない
163 :11/06/05 正規化NFCとNFDって、こっちが標準形式とか決まってるものですか? それともWinとMacでカオス?
164 :11/06/05 "Unicode" をUTF-16の意味で使うのは、Windowsだけじゃなくて Javaもなんだな。 http://download.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html
165 :11/06/05 >>163 カオスです。 詳しいことはMacOSXの方しか知らないけど、 NFDじゃないのが紛れ込んだりすると、 フレームワークも標準アプリもとても馬鹿げた動作をする。 要するにNFDを徹底できてない。
166 :11/06/05 >>163 どちらも標準形式、両者を扱えないといけない。 >>165 OSXは両刀、テキスト入力とかはNFCだよ。 NFCをファイル名に渡すと自動的にNFDにnormalizeする。 変換、比較のAPIも揃ってる。
167 :11/06/05 MacはUTF-8(NFD)に似た独自の文字コード。 正規化できてないってことはUTF-8と呼ぶことすら問題がある
168 :11/06/05 >>167 それはVFSレイヤに限定した話。 専用のnormalize APIもある。 テキスト等でどんな正規化を使っても構わない、って言うか普通はNFC
169 :11/06/05 POSIXとかCarbon使うと簡単に破綻するけどな。
170 :11/06/05 >>168 >VFSレイヤに限定した話 独自コードの使用場所がファイルシステム限定っていうのは知らんかった。でも NFCでファイルシステムに書き込み要求→独自コードに変換される →lsの結果を読み込むと独自コードのまま→元のNFCと比較するとアウチ Mac内だけで既にカオスだね
171 :11/06/05 >>170 正規化無視するにしても、ファイルシステムによって使えない文字(/:とか)や 同一視される文字(大文字小文字とか)は異なるから、ファイル作ったりしたら 実際どういうファイル名になったかは確認する必要あるよ。指定した文字列が そのまま使われる保証は無い。
172 :11/06/06 VFSレイヤでやってないからそういう問題が頻発するんだろ。 VFS関係ではNFDのコードはhfs+ドライバにしかないから。 Cocoaでもうまく出来てない。 hfs+以外は全部プログラマー任せだから。
173 :11/06/06 /:と文字コードとを同じにしないで欲しいな。 \が/になっても文句言わないけど、シフトJISで 書き込んだファイル名がEUC-JPになったら困るじゃないか。
174 :11/06/06 >>172 >VFS関係ではNFDのコードはhfs+ドライバにしかないから。 >Cocoaでもうまく出来てない。 それは君が知らないだけ。自動変換で不十分ならUnicodeConverterを使えばHFS+ルール でのNFD/NFC変換もできる。 >hfs+以外は全部プログラマー任せだから。 HFS+以外だと具体的に何が必要になるの? >>173 >シフトJISで書き込んだファイル名がEUC-JPになったら困るじゃないか。 古目のWindowsのアプリはそうでしょ。ファイル名はUnicodeで保存されてるのに未だに Shift_JISで扱ってる。zipアーカイブのファイル名をShift_JISで記録してるため、本当の ファイル名と違うし、UTF-8使ってるOSX等unix系の物と互換性が無いのは有名な話。
175 :11/06/06 >>174 > ファイル名はUnicodeで保存されてるのに ダウト
176 :11/06/06 保存されてるだろ。実体がUTF16でもそれを隠蔽して シフトJISに見せてるWindowsをマクとと一緒にすんな と思ったけど、ラウンドトリップが完全でないからNEC選定IBM拡張文字を書くと IBM拡張に化けるのかな
177 :11/06/06 >>176 > 保存されてるだろ。実体がUTF16でも ダウト http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07
178 :11/06/06 文字集合を切り替えて使う方式が最も合理的だろ。
179 :11/06/06 >>177 > >>176 > > 保存されてるだろ。実体がUTF16でも > ダウト > http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07 正確には今もなお UCS-2 らしい。つまり、サロゲートペアの片方のみの場合がある
180 :11/06/06 >>177 著者成瀬って成瀬ゆいか? あんなアホ男のことを真に受けるとは。 >UCS-2 らしい。つまり、サロゲートペアの片方のみの場合がある らしいってソース無しかよ。 しかも「つまり、サロゲートペアの片方」って意味わかんね。さすが池沼成瀬
181 :11/06/06 結局レッテル貼りかw
182 :11/06/06 どうせならもっと圧縮率の高いエンコードにしようぜ。
183 :11/06/06 >>181 レッテルっていうけど、自分で試してみればわかるでしょ。 FILE *f = _tfopen(_T("d:\\tmp\\\xD844\xDE3D.txt"), _T("wb")); // ??: U+2123D 明らかにWindowsはUCS-2じゃないよ
184 :11/06/06 >>174 >zipアーカイブのファイル名をShift_JISで記録してるため 日本語版WindowsはシフトジスだがShift_JISではないな。Windows-31J
185 :11/06/06 >>175 と>>177 のダウトは何なの? UTF-16かUCS-2かは置いておいて WindowsがUnicodeなのは疑いようの無い事実だと思うんだけど
186 :11/06/06 Unicodeと聞いてUnicode規格でなくUTF-16LEを想像したに決まってんだろ。 そっとしておいてやれ
187 :11/06/07 _T の意味を理解してない奴まだいたんだ。
188 :11/06/07 どうしてunicode=UTF-16LEなのは何で?
189 :11/06/07 Windowsの場合、MBCSに対してのunicodeだよ。 MBCSが文字コードを指定してるわけじゃないのと同じで、 Unicodeも実際のコードを特に名指ししてるわけじゃない。 そこはまた別問題な。 MBCS ←→ unicode ANSI ←→ wide character この関係な
190 :11/06/07 UnicodeとUTF-16の違いは?
191 :11/06/07 可逆な圧縮形式と考えたらいい。 実データ……Unicode 圧縮形式……UTF-8 UTF-16等 生waveを圧縮するのにMP3とかWMAとか色々あるだろ。 まあ、これは不可逆だけど。
192 :11/06/07 >>174 FAT32のファイルを扱う時に必要。
193 :11/06/19 >>189 >Windowsの場合、MBCSに対してのunicodeだよ どうしてそんな嘘付くかなあ。 メモ帳の保存オプション見れば「Unicode」「Unicode big endian」「UTF-8」 が選択できるでしょ。明らかにMS用語のUnicodeはUTF-16のLE(BOM付き)
194 :11/06/19 最初の頃ははBOM付きUCS-2だったんじゃない?
195 :11/06/19 話が噛み合ってないぞ。 >>188 曰く 「MSのUnicode=UTF-16LEはなぜ?」 >>189 曰く 「MSのUnicodeは規格のUnicodeであってLEとか関係ない」 >>193 曰く 「嘘付くな。MSのUnicodeはUTF-16のLE限定」 >>194 曰く 「MSのUnicodeは当初UCS-2の範囲しか扱えなかった」 当初U+10000以上が扱えなかったのは事実だけど、>>193 が言ってるのは リトルエンディアン限定ということ。 ちなみにUCS-2は符号化文字集合だからエンコーディングであるUTF-16と 同列に扱うべきじゃない。BOM付きUCS-2とかいうものは存在しない。
196 :11/06/20 昔はUCS-2がエンコーディングでもあった時代があった。> Unicodeコンソーシアム
197 :11/06/21 Unicode 3.0かな。 ISO 10646ってひょっとしてUCS-2が前提で U+10000以上をUTF-16で扱えなかったりするの?
198 :11/06/21 UCS-2が前提なのは、DIS 10646 1.0の頃のUnicodeコンソーシアム。 だからUnicodersがDIS 10646 1.0を廃案にした。 その頃Unicodeコンソーシアムは16bitで全て賄うつもりだったから。 結局ダメでサロゲートペア→UCS-4という流れ。 UTF-16はずっと後。
199 :11/06/22 Unicodeが昔16ビット前提だったのは確かだけど、 UCS-2/UCS-4はISOの概念でUnicodeとは直接関係なくね?
200 :11/06/23 ISO/IEC 10646-1:1993 UCS-2 と The Unicode Starndard, Version 1.1 は同じ。そのための1.1。 UTF-8, UTF-16は2から。
201 :11/06/25 すいません、 「あんたねぇ、UnicodeとUTF-8の違いが分かってるの?」 を英語に翻訳していただけますか? バカなアメ公がクソなコードをアップロードしてしまうんで困ってます。
202 :11/06/25 You seems you don't understand difference between Unicode and UTF-8 at all, fucking guy! 適当に翻訳サイトで訳した
203 :11/06/25 youなのにseems?
204 :11/06/25 つか丁寧な出だしなのに最後がfuckingで面白い 遠回りな表現しないで確実にUTF-8の文字コードでアップしろでいいじゃん 二つの違いを教えたいわけじゃない
205 :11/06/26 書きだし you seems はいらんな Why don't you understand the difference between Unicode and UTF-8 ?
206 :11/06/26 >>196 嘘つくな 「UCS」は符号化文字集合。「UCS-2」はエンコーディング。 ちゃんとISO/IEC 10646読め。 >>201 TOEIC 330点の俺が訳すと Please seive file as UTF-8 encoding, not as Unicorde.
207 :11/06/26 UnicodeとUTF-8の違いがわかっていない発言の例だな >>201
208 :11/06/27 確かにそのようにも取れるが 易に断罪してしまうのは間違いだと思う。
209 :11/06/27 「文字コードとシフトジスの違いがわかってんのか? 糞な文字コードでうpするな」 って言っているようなもの。あきらかな理解不足
210 :11/06/27 Unicode規格って、文字集合とエンコーディングひっくるめた規格だっけ? なんかそこらへん曖昧になる。>>19 はあってるのか?
211 :11/06/27 >>210 >Unicode規格って、文字集合とエンコーディングひっくるめた規格だっけ? その通り。 エンコーディングに関する仕様: http://www.unicode.org/versions/Unicode6.0.0/ 文字集合の定義:http://www.unicode.org/charts/ >>>19 はあってるのか? 違う。Unicodeは規格であって、文字集合の名前じゃない
212 :11/06/27 文字集合を指すときは、なんて言えばいいんだ? Unicode表? UCS-2とかUCS-4はどっちだっけ
213 :11/06/28 UCSが何の略かを思い出せ
214 :11/06/28 UCS-4はISOのエンコーディングの名前。 UCSはISOの文字集合の名前。 Unicodeの文字集合に名前はない。
215 :11/06/28 >>213 Universalだろ。Unicodeとは関係なし
216 :11/06/28 CSはどこいっちゃったんだよ
217 :11/06/28 UCSはUniversal Coded Character Setの略。 Cが一個どこに行っちゃったのか不明。 Unicodeの文字集合は「Unicodeの文字集合」でいいんじゃない?
218 :11/06/28 201です。 まず訂正。 ×バカなアメ公 ○バカなイタ公 クソコードを投稿(正確にはsvnリポジトリーにコミット)してたのは、イタリア人でした。 でもコードを管理してるコミュニティの親分はアメリカ人で、そいつのチェックでOKが出た上で投稿されたんです。 コードというのは、javaで書かれたプログラムコードのことで、テキストのエンコードのことではありません。 話が長くなるのでアレですが・・・ javaでは内部的に文字列をユニコードで処理しています。1文字は16ビットです。 Windowsも皆さんご存知の通り、内部的に文字列をユニコードで処理しています。1文字16ビットです。 Win32APIの末尾に w が付くやつがそうですね。 つまり、javaで何も考えずにフツーにプログラミングすれば、アメ公が作ってもイタ公が作っても 自動的に日本語対応になるんです。 あとは画面に表示されるメッセージを言語別に作成して、利用者の言語にあわせて切り替える仕組み にしてやれば、マルチリンガルなアプリケーションの一丁あがり!ってワケです。 javaにはもともと、そういう仕組みが用意されてるので簡単です。 ところが、件のバカなイタ公は、文字列を一旦 UTF-8 にエンコードしてから表示しようとするんです。 もちろん文字化けします。バカなイタ公はなぜ文字化けするのか理解できないので 今度はそのUTF-8エンコードされた文字を、javaからWin32APIのWriteConsoleWに渡そうとします。 もちろん文字化けします。バカなイタ公はなぜ文字化けするのか理解できないので 今度はコンソールのコードページを無理やりUTF-8に変更するAPIを使いドツボにハマっています。 何もしなくていい、ただ System.out.println()関数でフツーに表示すればいい、ってのが理解できんのです。 アプリケーションをユニコード対応して国際化したい一心で一生懸命がんばってくれてるキモチはアリガタイwのですがw ユニコードとUTF-8の違いが理解できてないため、まったくトンJンなプログラムコードを書いて投稿します。 このイタ公を何とかして退治したいです。イタ公の愚行をやめさせるナイスな文章を教えてください。 コミュニティは英語以外禁止なので英語で構いません。
219 :11/06/28 おまへは先ず日本語を勉強汁
220 :11/06/28 >>211 > エンコーディングに関する仕様: http://www.unicode.org/versions/Unicode6.0.0/ ここで文字集合も定義しているが?
221 :11/06/28 >>218 TOUIC 420点の俺が説明すると Don't use JNI. Don't use new String() or String#getBytes(). Never change code page for console window (use default always). Simply, you should pass String objects to System.out.println. ex 1. println("native text") ex 2. println(str) Encoding conversion as below is performed: source text(Native encoding) ->(compilation)-> UTF-16/class file -> String object(UTF-16) -> System.out.println -> Windows -> (Windows converts UTF-16 to native encoding)
222 :11/06/29 >>218 中学生の妹のことで困っています。 ここ最近、妹は風呂上りに毎回僕の部屋にやってきます。 脱衣所でしっかり体を拭いていないせいか、濡れたタンクトップに首が透けて浮き出ています。 視線を逸らしながら注意すると「やっぱ妹のでも気になるんだ?」 と俺をからかいはじめる始末です。 こんな調子で二三時間も居つかれては堪ったもんじゃありません。 この高見盛そっくりの妹を退治するにはどうしたらいいのでしょうか。
223 :11/06/29 UnicodeとUTF-8の違いわかってない土方大杉
224 :11/06/29 >>218 四行目で読むのやめた >>222 三行目まで読んだ
225 :11/06/29 >>221 TOUICってのは何万点満点なんだい?
226 :11/06/29 >>222 漏れにくれ
227 :11/06/30 >>223 このスレは3スレ目なのに、酷いものだ
228 :11/06/30 >>225 ん?よくしらないけど1000点じゃね。 そのくらい自分で調べな
229 :11/06/30 >>228 そもそもTOUICってなんの試験? 馬鹿レベルを計るもの?恥レベル?
230 :11/06/30 >>229 Test Of Unwise International Computation.
231 :11/07/01 なんか長文あったから読んでみたけどいらない情報多すぎだし、このスレに来る人なら知ってることをダラダラ書いてるし途中でやめた
232 :11/07/03 Windowsでサロゲートペアのファイル名がZIP圧縮出来ないんだけど、なんとかならんの? 今時シフトJISしか扱えないなんて糞過ぎる。 スマホ上で作ったUTF-8ファイル名のZIP持ってくると文字化けしまくる。 ファイル名にBOM付けてもいいからマジ何とかしてほしい
233 :11/07/03 コントロールパネル →個人設定 →システムロケールの変更 →再起動
234 :11/07/03 ZIPそのものが古代の遺物。7-Zipにすればよろしい。
235 :11/07/03 >>232 お前が使ってる糞解凍ツールを見直すべきかと
236 :11/07/09 Unicodeの文字に言語情報ってある? 日本語かどうか判断したいんだけど。 JIS2004は日本語と判断したい
237 :11/07/10 >>236 そんなものは無いし、JIS2004をそのまま含んでいる訳ではないので不可能。 JIS2004に追加された文字でUNICODEに無かった分をUNICODE3.1や3.2でUNICODEに追加した分というのなら調べればわかる。
238 :11/07/10 極端な話アルファベットで日本語の文章を書くことも出来るわけで、 言語とスクリプトは別というのはわりと基礎知識。
239 :11/07/10 そんな極論聞いてるわけじゃないんだよねえ
240 :11/07/10 極論じゃないでしょ。 >>236 の言う「日本語かどうか」がどういう意味かによって、 やり方が全然変わってくるんだから。 JISで登録されてる文字集合に含まれてるかどうかでいいってのなら、 テーブル見れば済む。 けどそんなこと質問するかね。
241 :11/07/10 >>240 Unicodeの文字集合はUnifiedだから、一つの文字が複数の言語に 対応するのは>>236 もわかってるでしょ。>>236 は 「A」: 英語,日本語 「百」: 日本語,中国語 「あ」: 日本語 みたいなテーブルが欲しかったんでしょ。そんなものは無い。 >>240 >テーブル見れば済む どこかに正式なものが公開されてる? 無保証でいいなら http://x0213.org/codetable/sjis-0213-2004-std.txt とかあるけど
242 :11/07/11 >>218 超一般論として、説明してもわからない 我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ エラーが出るテストを作ってそれをつき突けろ 最終的にはそれしかない 「よくわからんがこのテストが通ってるんだからあちらでも問題はないんだろう」というものを作ってさしあげろ
243 :11/07/11 一塊の文章としてなら、IMultiLanguageで文字コードを推定することはできるはずだぜ?
244 :11/07/12 >>242 >我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ ぶっちゃけこの業界はコミュ障が多いから そこまで他人の立場に立って理解出来る香具師は少ない
245 :11/07/12 つーか、駄目なコードの例と正しいコードの例を提示すればいいだけなんじゃねーの?
246 :11/07/14 流れを断ち切って申し訳ないが、 UTF-8がバイトオーダーの影響を受けてLE,BEに分かれないのはどうして? いや、UTF-16だけが特殊なのか? CPUがメモリ上の複数バイトを読み書きする際の配置の都合からLE,BEがあるのなら、 UTF-8だってASCII文字以外は複数バイトでしょ?
247 :11/07/14 UTF-8は1バイトずつ読み書きする。
248 :11/07/14 >>246 1文字(16bit整数値1つ)を、どういうバイト列に変換するかの問題。 UTF-16LEは、UCSの1文字を2byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → 42 30 UTF-16BEは、UCSの1文字を2byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → 30 42 UTF-8は、UCSの1文字を1-4byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → e3 81 82 2byteの整数をサイズ2のバイト列に変換する方法は、簡単で合理的な2種類ある(BE,LE)ので、 どちらを使えばいいか迷ってしまい、みんなで混乱する。 一方、2byteの整数をサイズ1〜3のバイト列に変換する方法は、それほど自明ではないので、 誰かが「UTF-8」としての変換ルールを決めた。そしてみんながそれに従った。現状、それがうまくいっている。 仮に、「UTF-8なんとか」というUTF-8に似て非なるルールが乱立するなら、UTF-16のLE/BEの混乱と 近いことが起こるかもしれないけど、たまたま現実はそうなっていない。
249 :11/07/14 MIME64と一緒か
250 :11/07/14 >>246 UTF-8はエンコーディングフォームが1オクテット単位だから、 UTF-8エンコーディングスキームはバイトオーダーに依存しない。 UTF-16とUTF-32エンコーディングフォームが2/4オクテット単位だから、 エンコーディングスキームが複数必要となった。
251 :11/07/14 LEとかBEとか分けないで、どちらかに統一すればいいのに。
252 :11/07/14 できなかったからこうなってるんだろ
253 :11/07/14 UTF-16/32は内部表現として採用されることが多い。 だからバイトオーダーの問題が出てくる。 UTF-8はそんまんま垂れ流すのでなければ、 内部表現としてのUTF-16/32と併用されることが多く、 その場合decodeがいずれにせよ必要となるので、 バイトオーダーと逆順になっていても大した手間じゃない。
254 :11/07/14 LEとBEは、規格上で相互運用とかをあんまり考えなかった結果…ではある どっちかに我慢してもらって無理してでもどっちかに決めてしまえばよかった 本当はね LEでもBEでもどちらでももちろん構わないというのは、うんざりするほど正当で当たり前だが、うんざりだ
255 :11/07/15 レスthxです。 おかげさまでずっと疑問だったのが解消しました。 CPUの都合を考慮して2種類規格化してくれただけなんですね。 >>253 これは少し考えていました。 画像ファイルに例えるならばUTF-8=JPEG,UTF-16=BMPで、 JPEGはメモリ上にBMP形式で展開&編集され、最終的にJPEGで再保存される。 JPEG(UTF-8)がデータ交換用としての相互運用性を重視される一方、 BMP(UTF-16)はメモリ上での編集のし易さが重視される。 UTF-16においては、それはLE,BEの許容にあたる。 という認識です。 しかし内部形式って意識されるべきですか? 恥ずかしながらVB以降の言語しか分かりませんが、 通常charの型変換には符号化方式の指定が必要なので気にしたことがありません。 (short)charをファイルにシリアル化するような事があったとしても、 これはテキストと見せかけてバイナリファイルですと言い張るかも。 C言語なんかだと意識するんですか? UNICODEをAPIで扱うならば内部的にはポインタ/byte[]で持つんですよね? だとしたら意識しないといけないのかな? あ、JAVAでもif('A'<=VALUE || VALUE <= 'Z')と書けるのはUTF-16BEだからですか! 無意識に書いてましたorz
256 :11/07/15 画像に擬える辺り、根本から判ってない悪寒。
257 :11/07/15 低レベルの挙動を考えたら、LEとBEは両方必要だろと普通に思うがな
258 :11/07/15 ネットワークバイトオーダーっつうもんがあるように、 交換形式はどっちかにしちまえよ、って思ったことはある。
259 :11/07/15 >>258 それは実質UTF-8だな UTF16/32のままネットワークを流れることはあまりない
260 :11/07/15 >>258 大量のテキストを処理したい時に、 内部表現と同じテキスト形式が存在しないのは不便。 実行環境の内部形式に依存しても、軽快に扱いたい局面はある。 たとえばテキストデータベースの二次記憶保存など。 ネットワークバイトオーダーについては、 TCP/IPのヘッダー部はデータ量が少ないし、 最近はハードウェア評価だからオーバーヘッドにはならない。 それにデータ交換についてはプロトコル毎に決めればいい。
261 :11/07/15 >>255 >しかし内部形式って意識されるべきですか? 意識する必要は無いし、UTF-16フォームにLEとBEの区別は無い。 ただし外部形式であるUTF-16スキームにはLEとBE区別が当然ある。
262 :11/07/15 >>255 せめてPNGにしとけ。それなら話が通じる
263 :11/07/16 ヒント: Unicode = UTF-16 UTF-8 = UTF-8 もともと、Unicodeに準拠した文字コードはUTF-16しかなかったから 文字コードはUnicodeという記述をするとUTF-16をさす その後、UTF-8というものが増えた為、 それと差別をするために、UTF-16という言葉が発生しました なので今となっては Unicodeは文字一覧を指し、 UTF-16/UTF-8は文字コードの種類を指す という意味が正しいのだが、昔の事情があったため、 文字コードUTF-16をUnicodeという言い方をする場合がある
264 :11/07/16 ドヤ顔でそんな事言われても
265 :11/07/16 しかしエンコーディングをUnicodeって言うのはやめてほしい 昔はそうだったのかもしれないけど、気持ち悪くて
266 :11/07/16 UCS-2ですよ。Unicodeって言われた時代はありません。
267 :11/07/16 >>263 > 文字一覧 文字セットの方が好き
268 :11/07/17 マクのSJIS-Unicode変換ルールを知りたいのですが、 どこかに公開されていないでしょうか。 特にNEC特殊文字やIBM拡張文字(「@」(U+2460)など)がどうなるか知りたいです。
269 :11/07/17 どうもならんよ
270 :11/07/17 数多いShift_JISベンダー拡張の「MacJapanese」からのなら http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT にあるけど、今もこの変換通りなのか不明。 Microsoft拡張のCP932との関係も少しだけコメントが書いてある。
271 :11/07/17 どうにもならない、というのは、 U+2460をシフトジスに変換すると24 60の2バイトになるということかな?
272 :11/07/17 これを挙げ忘れた。 http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/Readme.txt
273 :11/07/17 >>270 >今もこの変換通りなのか不明 今も昔もこのルールか実装されたためしなんて無い。 |0x5C 0x00A5 # YEN SIGN
274 :11/07/17 >>273 Character ViewerからShift-JIS(X0208)指定して005Cダブルクリックで入力すると アプリ側にはU+00A5が渡るけど CoreFoundationで変換してもU+00A5になる。
275 :11/07/17 >>268 MacはもうShift_JISは使ってないよ。 UnicodeとShift_JISの変換は当然できるけど、動作はAPIに対するパラメータ次第。 例えばU+2460に対しては古いMacJapaneseを指示すれば0x8540が返るし、X0208を 指示すると変換できずエラー、X0213を指示すると0x8740が返る。 端的に言うとパラメータで指示した規格に沿った値に変換される。
276 :11/07/17 シフトJISを規定の文字コードとするアプリケーションは、Mac OS Xには無いそうです。 JDK 6とかな。
277 :11/07/17 Shift_JISX0213のエンコーディングを実装してるなんて、マッコステンて無駄にすげーな。 シフトジスの84 BF(丸付き21)をUTF-16に変換すると27D0になったり、 シフトジスのFCA3をUTF-16に変換するとD867 DFCEになっちゃうわけ
278 :11/07/18 Windowsも正確には MS932(CP932やWIN31Jとも言うが)なんだけどな
279 :11/07/18 そんな偉そうにIANAに登録されていない名前を列挙されても
280 :11/07/19 ドヤ顔でズレたこと言ってるのはお前じゃねーの >>278 はshift_jsと違うってことが言いたいんだろ
281 :11/07/19 まぁ、ちゃんとした名前で言っておけばつっこまれなかったかもしれんぞ。 Windows-31J な。 http://www.iana.org/assignments/character-sets
282 :11/07/19 WIN31J「とは言わない」からな その時点でいろいろ知れる
283 :11/07/19 >>280 node.jsの親戚かと。
284 :11/07/19 >>278 MS932とはあまり言わないだろう、Microsoftの「Code Page 932」って規格だから略称としては「CP932」が適切
285 :11/07/19 >>284 MS932はJava語で、おおむね、Windows-31Jを指すはず(IBM版CP932とは違う) Javaが独自分類表現を使用しているなんて夢にも思わない人がJavaの外に持ち出して恥をかくことがある
286 :11/07/19 よくこんな細かいことで争えるなあ・ω・
287 :11/07/19 別に細かくはない ギョウザを頼んだらシュウマイが出てきた、くらいには違う
288 :11/07/19 Wikipediaが正しいかわからないけど、色々な経緯が載ってる http://ja.wikipedia.org/wiki/Microsoft%e3%82%b3%e3%83%bc%e3%83%89%e3%83%9a%e3%83%bc%e3%82%b8932
289 :11/07/19 CP932はLLのコード指定なんかでも良く使われる名前だし、突っ込むほどでもないと思うがな
290 :11/07/19 >>289 CP932は問題になってはいない っていうかお前>>278 だろ
291 :11/07/19 Windows-31J はJavaのJSPだっけ?でしか 聞いたことがない。
292 :11/07/21 日本語版Windowsのメモ帳の文字コードがWindows-31Jなのは 間違いないし、Shift_JISでないのも確かだが、 「シフトジスではない」と言われるとそれは違うだろう。 どう考えてもWindows-31Jはシフトジス。
293 :11/07/21 >>288 |マイクロソフト及び、MS-DOS の OEM ベンダが Shift JIS を独自に拡張した文字コードである。 でたらめな説明だな。 もともとアスキーマイクロソフトが考えた文字コードが「シフトJIS」と呼ばれ、 正確な定義はどこにも無かった。 1997年にJISが「Shift_JIS」を定め、それは世の中にあるシフトJISの 共通部分であるX 0201,X 0208のみを対象としたものだった。 だからShift_JISもWindows-31JもシフトJISの一種でしか無い。 拡張なんて嘘がどこからでてきたんだ。
294 :11/07/21 文中では「Shift JIS」で、 wikipedia項目に飛ぶと「Shift_JIS」になってるな。無茶だなw Windows-31Jは、初期の「Shift JIS」からは文字が足されて拡張されているけど、 その飛び先が「Shift_JIS」ではな。 「Shift_JIS」の項目内で「Shift JIS」と「Shift_JIS」の使い分けが甘い。
295 :11/07/22 >>294 Wikipedia のリンク名には制約があって、「_」と「 」が区別できない。
296 :11/07/22 リンク名というか記事名だな 他にも記事名に使えない記号ってあるのよね
297 :11/07/23 Wikipedia のタイトルの制約には昔から悩まされてる。 1. アンダースコアが空白になる 2. ふたつ以上の空白がひとつにまとめられる 3. 先頭と最後の空白が除去される 4. [ ] { } < > | # が使えない 5. : が特殊な意味を持つことがあり、たとえば「:」からはじまるタイトルが作れない 6. 先頭の1文字が大文字になる 7. 長さ制限(UTF-8 で 255バイト以内)がある リンクするときにはさらに複雑な制約がかかる。
298 :11/07/23 文字コードの話じゃないけど、入力文字に複雑な制限があるのは エスケープ前と後の区別がつけられないできの悪いエンジニアが 作ったんだろうな。そういう人たちがSQLインジェクションとか起こす。
299 :11/07/23 記事名がURLになる、というのは便利なんだがそういう弊害もあるよな。 逆にハッシュ値のような長いURLは不便だし、シリアルナンバーも微妙。 MediaWikiって内部的に持ってる記事名も空白が _ になってたりして、 そのへんの設計も微妙だな。
300 :11/07/23 スレ違い
301 :11/07/23 Not スレ違い http://ja.wikipedia.org/wiki/ ~ http://ja.wikipedia.org/wiki/%EF%A8%99 http://ja.wikipedia.org/wiki/%E7%A5%9E
302 :11/07/23 記事名の問題だけじゃなくShift JISの記事は内容がおかしいな。
303 :11/07/23 そういう時は君が修正すれば良い。 誰でも修正できるのだから、それをせずに 間違っていると言ったところで信用されない。 言う前に直してから、直したよと報告すればいい。
304 :11/07/23 >そういう時は君が修正すれば良い。 これはそうなんだが >誰でも修正できるのだから、それをせずに >間違っていると言ったところで信用されない。 こういうことを言う奴って頭おかしいんじゃないかと思う。 ただ間違ってるものを見たときに間違ってると言ってはいけないだろうか。
305 :11/07/23 好きにすればいいんじゃねーの? 俺は>>304 みたいのを見ると頭おかしい人なんだなと思うけど 言いたいこと言うのはいいことだと思うようん
306 :11/07/23 >>304 お前は間違っている。 間違っているものを見たので つい言ってしまったw
307 :11/07/23 A: ○△に〜って書いてあったよ B: それ間違ってるね A: 間違ってるって言う前に○△を修正しなよ B: ハァ? 何で俺が○△とかいうのを直さなきゃいけないの >>304 はともかく、>>303 が変なのは確定的に明らか
308 :11/07/23 A: ○△に〜って書いてあったよ B: それ間違ってるね A: 間違ってるって言う前に○△を修正しなよ B: ハァ? 何で俺が○△とかいうのを直さなきゃいけないの A: ○△は誰でも修正できるものだから。
309 :11/07/23 「誰でも修正できる」がなんで「見つけた人は修正する義務がある」にすり替わるよ。 頭だいじょうぶ?
310 :11/07/23 誰が義務があるって言ったんだ?
311 :11/07/23 おまえら楽しそうだな。
312 :11/07/23 仲良くしてね
313 :11/07/23 とりあえずシフトジスって書かれたときは99%はWindows-31Jのことだから、 Windows-31Jって書いておけば問題ない。
314 :11/07/24 Windows-31JはJava用語で一般的ではないから 他では通じない。CP932と言ったほうがいい。
315 :11/07/24 >>314 2点 レス欲しいなら狂人の真似を
316 :11/07/24 いや事実を言っただけなんだが。
317 :11/07/24 「Windows-31J」はIANAに登録された一般的な名前で、Java固有ではない。 HTTPのContent-Typeにも(条件付きではあるが)正式に使用できる名前。 なお.NET FrameworkのEncoding.GetEncodingは、文字コード名をパラメーターに 取るのではなくWindowsコードページ名を受け取るので、Windows-31Jは指定できない。
318 :11/07/24 >>317 GetEncodingは.NETのウニコード文字をローカルに 変換するルールでしょ IANAが決めているのは文字コードであって、 ユニコードとの変換ルールでないんだから当然
319 :11/07/24 >>315 861 :デフォルトの名無しさん:2011/01/04(火) 20:39:59 SJISは、CP932は
320 :11/07/25 IANAのcharset名、Windows関連は "Windows-コードページ番号"で統一できたらよかったのにな。
321 :11/07/25 Wikipediaなんて間違いだらけなのは、まともな技術屋ならしょっちゅう見て理解してるだろ… 内輪ルールがめんどくさすぎて修正しねーことも多いわ 一応、楽に修正できそうな範囲ならするけどな
322 :11/07/25 間違いっていうか意図的な捏造もかなりあるぞ 特に反日歴史関連は酷い
323 :11/07/25 ウヨ脳乙
324 :11/07/25 えっ
325 :11/07/26 要するに>>278 の言いたい「正確」ってのが何だったのかが分からんということだな
326 :11/07/27 拡張漢字(NEC選定IBM拡張・IBM選定IBM拡張・NEC特殊文字)を含む場合は MS932かCP932あるいはWindows-31J が正しい Shift_JISに拡張文字は無い なので、 「MS932かCP932あるいはWindows-31J」>「Shift_JIS」 なのだろう それが正確
327 :11/07/27 正式名称と通称は区別してよ。 シフトジス ├Windows-31J(X 0201,X 0208,NE特殊,NEC選定IBM拡張,IBM拡張)→通称MS932,CP932 └Shift_JIS(X 0201,X 0208)
328 :11/07/27 文字エンコーディング・文字コードは技術ではなく(おそらくは残念なことに)ただの政治なので、 ちょろっと読んだ人がしたり顔できるほど相関関係は単純ではない
329 :11/07/27 CP932はMicrosoft的には正式名称でしょ。
330 :11/07/27 >>329 コードページの932番というのは正式な番号だけど、 「CP932」という名前はちょっと違うんじゃね
331 :11/07/27 microsoft.comの公式文書でcp932と表現してる所がある。
332 :11/07/28 cp65001
333 :11/07/28 IANAだけ正式だと思ってるのは勘違いだわな
334 :11/07/28 ソースが出てこないから突っ込まれるんだよ。 MSの文書で文字コード名cp932が定義されているソース出してみろや。 コードページの932番じゃなくて「cp932」な
335 :11/07/28 後付けくさい理由で絡んでるようにしか見えないが
336 :11/07/28 ぐぐれ http://social.msdn.microsoft.com/search/ja-JP?query=cp932
337 :11/07/28 socialはちょっと… msdn本家ページにもあるよ。
338 :11/07/29 今度は「使っているというだけでは正式な定義ではない」とか絡んでくるんじゃねーの ぶっちゃけ心底どうでもいいんだが
339 :11/07/29 仕様がどうでもいいとかいうやつは、 プログラマーやめたほうがいいんじゃねーの
340 :11/07/29 プログラマにとっての仕様なんて、 「コメントを求む」程度の文章でいいんだよ。
341 :11/07/30 自ら勉強する気が無いならやめてしまえ
342 :11/07/30 自ら勉強する気はあるが、 会社のためにしかならないことを 勉強する気にはならない。
343 :11/07/30 向上心が無いのは仕方ないが、仕様が守れない奴は会社やめれ 例えば Content-Type=text/htm; charset=Shift_JIS で、丸付き数字とか送られてきた日にはブチ切れですよ。 僕のパソコンの僕のブラウザでは表示できましたとか言い出すと意を覚える
344 :11/07/31 text/htmってのひどいな
345 :11/07/31 typoにマジレス。カコワルイ
346 :11/07/31 >>343 世の中仕様が全てではないんだよ。
347 :11/07/31 仕様書に必要なこと全てが書いてあるとは限らんが、 >>343 のは仕様で禁止されたことをやってんでしょ。 それはまずい。
348 :11/07/31 charset=Windows_31J なら良かったのか
349 :11/07/31 JavaやってるとContent-Typeと文字コードがリンクしてるから死活問題だな。 鯖と端末双方が「@」を使うと合意した上でWindows-31J使うのが正しいと思う。
350 :11/07/31 > JavaやってるとContent-Typeと文字コードがリンクしてるから 設計が現実を処理できない仕様になってる。 ダメな設計だ。
351 :11/08/01 Ruby1.9.3がSJISをWindows-31Jと認識するようになった
352 :11/08/01 何か問題が?
353 :11/08/04 世の中で使われているシフトジスの実態を考えれば SJISをWindows-31Jにすることは妥当だと思うが。 SJISをShift_JISにしたところで安岡センセイ以外喜ばない。
354 :11/08/04 >>353 > SJISをWindows-31Jにする > SJISをShift_JISに どういう意味で言っているのか? 「SJIS」とは何なのだ?
355 :11/08/04 文字コード名に"SJIS"を指定されたときの動作をどうするかってことじゃねーの
356 :11/08/04 そんなの好きにしたらいいじゃん。
357 :11/08/06 もともとこのスレはUnicodeをUTF-16系のエンコーディングと勘違いした 人が立てたんだと思うが、MSだけでなくJavaもUnicode=UTF-16なんだっけ?
358 :11/08/06 >>354 >>351
359 :11/08/07 >>357 おJA様の"Unicode"は デコード時:ビッグエンディアンUTF-16、BOM許可 エンコード時:ビッグエンディアンUTF-16、BOMあり Windowsの"Unicode"は デコード時:リトルエンディアンUTF-16、BOM許可 エンコード時:リトルエンディアンUTF-16、BOMあり
360 :11/08/07 >>359 >UTF-16、BOM許可 冗長な表現だな。UTF-16エンコーディングスキームは常にBOM許可なんだよ。 "UTF-16LE"→BOM禁止 "UTF-16BE"→BOM禁止 "UTF-16"→BOM許可 Javaの"Unicode"は先頭のBOMを読み飛ばすから"UTF-16"。 ちなみにJavaの"UTF-8"はBOMをNBSPと認識する統一性の無い仕様。 Javaも.NETも、文字コードに表現の曖昧さのあるものは 区別できるようならないものかな "UTF-8" →実行環境の規定のUTF-8表現 "UTF-8:wBOM" →先頭にBOM必須 "UTF-8:w/BOM "→先頭のFEFFはNBSP "UTF-8:autoBOM" → 先頭にFEFFがあればBOM みたいな
361 :11/08/07 BOMって文字コードの一部なのか? たとえば、「あいうえおかきくけこ」という文字列を split関数で2つに分けたとき、「(BOM)あいうえお」「(BOM)かきくけこ」になるのか? 違うだろう? BOMはマックバイナリみたいなもので 文字の一部ではなくファイル形式の一種だと思うんだが。
362 :11/08/07 BOMはデータストリームの一部で、 データストリームの先頭にあるとシグネチャと看做されます。
363 :11/08/07 ISO-2022のエスケープシーケンスを文字コードに含むぐらいには文字コードかな。 Unicode 6.0の16.8には「U+FEFF at the very beginning of a file or stream」とあるね。 ただの文字列がstreamに含まれるかと言えば普通の感覚ではNoだけど、 絶対ダメと断言するには表現が曖昧な気がする。 streamの定義をきかれたら「一連のcharacter」としか言いようが無いから。
364 :11/08/07 はっきりとin the unicode data streamと書いてる。 http://unicode.org/faq/utf_bom.html#bom1 Byte Order Mark (BOM) FAQ Q: What is a BOM? A: A byte order mark (BOM) consists of the character code U+FEFF at the beginning of a data stream, where it can be used as a signature defining the byte order and encoding form, primarily of unmarked plaintext files. Under some higher level protocols, use of a BOM may be mandatory (or prohibited) in the Unicode data stream defined in that protocol. [AF]
365 :11/08/07 仕様でないものを仕様と勘違いする奴とか、常に正しい仕様が存在してくれていると思ってる奴とか、 プログラマやめた方がいいんじゃねーの
366 :11/08/07 文盲がいるな。 >はっきりとin the unicode data streamと書いてる 一つ前のレスも読めないのか
367 :11/08/07 unicode data streamってのが 何かよくわからないけど、 わざわざ書いてるってことは、 特別扱い、つまり通常の文字とは別扱いなんだな。
368 :11/08/07 プログラム言語で扱う文字型はencoding schemeでなくencoding formの単位なので BOMになり得ない。 encoding scheme: バイトデータ表現。BOMが付くことがある encoding form:「文字」単位の表現。BOMの概念無し。splitで扱うのはこっち char型(UTF-16/32文字)のFEFFはZWNBSとみなさなければならない。 それをバイトデータにエンコードして初めてBOMが付く。
369 :11/08/07 BOMが途中にあったらどうなるの? 切り替わるの?
370 :11/08/08 文盲がいるな。 バイト配列をwchar_t(C)とかchar(Java)にデコードした時点でBOMは消えなきゃいけないの。 ちなみに途中にあらわれるものはBOMでなくU+FEFF文字として扱わなければならない
371 :11/08/08 途中で現れるのは後方互換性のために許されてるだけで、 本当は途中に現れちゃ駄目。
372 :11/08/08 deprecateでも許されてるってことは、書き込むプログラムはともかく 読み込むプログラムは処理しなきゃいけないってこった
373 :11/08/13 Windows7HP 64bit、MS-IME2010ですが、IMEで変換中の文字コードは何でしょうか? 質問は以下2点で、例えば、EUC-JPのテキストをエディタで編集中とします。 1.MS-IMEで変換中(この時の文字コードは?) 2.変換した文字を確定(変換中の文字コード → EUC-JPの変換は誰がどのタイミングで行っているのでしょうか?)
374 :11/08/13 >>373 1.ふつうはUTF-16 2.ふつうはテキストエディタの保存時
375 :11/08/13 >>373 普通はEUC-JPで表現できない文字も入力できて、保存時にエラーが出るよね。 ってことは編集中はEUC-JPじゃないってこった
376 :11/08/13 >>374-375 なるほど。 d
377 :11/08/14 他スレから来ました。 UNIXのshebangってBOMに対応できないの?
378 :11/08/14 カーネルがバイナリファイルの先頭で #! の存在をチェックしている ところで、まずBOMの有無をチェックするように改造すれば可能かも。
379 :11/08/14 ファイルの先頭にFE FF 00 00を見つけたとき、 ・UTF-16BEのU+FEFF, U+0000 ・UTF-16のBOM, U+0000 ・UTF-32のBOM のいずれであるかの見分けはつくのでしょうか
380 :11/08/14 >>379 そのバイトオーダーでは迷う要素がどこにもないのだが…
381 :11/08/14 先頭がBOMかU+feffかは、 エンコードスキームがutf-16なのかutf-16beなのか の情報が必要。 つまりエンコードスキーム情報無しに読むことは不可
382 :11/08/14 >>381 そのバイトオーダーでは迷う要素がどこにもないのだが…
383 :11/08/14 >>381 ならff fe 00 00ならどうするのよ?
384 :11/08/15 >>382 FE FF 00 00ってのは例が悪くて>>383 の間違いなんだろうけど、 「FE FF」にしたってBOMなのかU+FEFFなのか区別付かないよね?
385 :11/08/15 Unicodeでは先頭のU+FEFFは常にBOMと解釈すべし、というルールだから、BOMであることに疑問はない。 ただしUTF-16LEによるBOM + U+0000という解釈とUTF-32LEによるBOMという解釈のどちらをとるべきかは 一意に決定する方法がない、という意味で>>383 の指摘は正しいものだと思う。
386 :11/08/15 つ ttp://stackoverflow.com/questions/1929962/unicode-bom-for-utf-16le-vs-utf32-le バイトオーダマークであってエンコーディングを示すものじゃないから諦めろってさ
387 :11/08/15 >>385 >先頭のU+FEFFは常にBOMと解釈すべし んなこたーない。 Unicode 6.0.0「3.10 Unicode Encoding Schemes」D96 『In UTF-16BE, an initial byte sequence <FE FF> is interpreted as U+FEFF zero width no-break space』 D98 『In the UTF-16 encoding scheme, an initial byte sequence corresponding to U+FEFF is interpreted as a byte order mark』 UTF-16BEなら先頭のFE FFはU+FEFF。UTF-16なら先頭のFE FFはBOM。データから区別は出来ない。
388 :11/08/18 先頭の<FE FF>がBOMなのかfeff文字なのか判断できないなんて、 BOM考えた奴、ばかなの?
389 :11/08/18 Unicode自体が馬鹿の塊なのは欧米人以外なら即分かると思うが
390 :11/08/18 >>389 どの辺が馬鹿の塊なのか解説よろしく
391 :11/08/19 香具師らの認識している「表意文字」とはアイコンのことだからなぁ
392 :11/08/19 だから今は漢字のことを表語文字と呼んだりするね
393 :11/08/28 >>390 当初16 bitで収まると考えていたことなんか、素人の俺にもすぐに指摘できる。
394 :11/08/29 >>393 かつてそう考えたミスは事実だが、今はコードポイントが U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で 対応出来てるだろ。 「Unicode自体が馬鹿の塊」の理由は説明出来ないのかな?
395 :11/08/29 >>389 でも>>393 でもないが 正規化すると互換漢字が統一漢字になるところは時々キレそうになる 自分は異体字セレクタでやればいいんだけど、他人に渡す時に対応エディタがないから揉める あと他人から受け取ったファイルに互換漢字が大量に含まれてたりするともうね・・・
396 :11/08/29 >>394 無理はあるだろ 16bitとか考えなきゃ、最初っからCJKなんて無謀なこともしないで済んだし、そうすればコード変換の コストも大幅に軽減されたし、i18n対応のソフトがフォントでつまずくようなことも起きなかったし 他にもさまざまな問題が事前にことごとく指摘されてたのに強行して、結局無理でした、だからな
397 :11/08/29 >>394 > かつてそう考えたミスは事実だが、今はコードポイントが > U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で > 対応出来てるだろ。 その代償として、Unicodeは複雑化してしまった。 UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。 最初から世の中の文字はすべて32bitで扱うとなっていれば、プログラムも簡単だっただろうに。 OS、言語、すべてが同じUTF-32を使う。さっさと移行しておけばよかったのに。 第一の失敗UTF-16、これがあったせいでWindows、Mac、JavaはUTF-16を 標準のものとしてサポートしてしまった。今更UTF-32にはやすやすと移行できないだろう。 おかげでサロゲートペア対応とか変なモノが後で導入された。 第二の失敗UTF-8、これのせいでUnix系はASCII文字と互換性を保てるようになってしまった。 そのせいで、UTF-8はなかなか消せなくなっただろう。 もう一文字がすべて同じ32bitの世界は絶望的だよ。
398 :11/08/29 >もう一文字がすべて同じ32bitの世界は絶望的だよ。 いや、それは結合文字ある時点で絶望的だろ、と突っ込んでみる UTF-16がクソなのは同意だがUTF-8は需要多かったからどの道生まれただろうし
399 :11/08/29 >>395 自分の処理目的に適した基準でnormalizeすれば良いよ。decompositionだけ無くすとかね。 外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。 OSXだと互換漢字は除外してnormalizeするAPIとかも用意されてる。
400 :11/08/29 ぜんぜんCJK非分離の解決になっていない件
401 :11/08/29 漢字は本当に、普通に見た目が違う字が出るもんなぁ
402 :11/08/29 >>399 要件にわざわざ『Unicode正規化(C方式)』と入ってなければ 或いは、送ったファイルが何故か相手側で正規化される、そんな可能性が無視できるなら Apple独自規格だろうがなんだろうが喜んで使おう ただ、その場合はそもそも正規化する必要がないんだけど
403 :11/08/29 >>399 >外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。 必要だからやる→>>395 自分勝手にnormalizeしたところで何の解決にもならん罠
404 :11/08/30 正規化についても、みんなで仲良く正規化しないと、 いろいろ面倒なんだよなあ。 例えば、外部からきたUSBメモリ上のパス名まで正規化されているかどうかとか。 内部的には正規化してから処理するとしても、 再度書きこむ時に正規化すべきか、それとも元のままにしておくか、 元のままにしておく場合、保存しておかなければならないし。 >>397 > UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。 ちょっとこの列挙の仕方はどうかと。 言わんとしていることは分からないでもないが、 最初から32bitじゃまとまらなかっただろう。
405 :11/08/31 受け入れられるためには理想の仕様は諦めて妥協しないといけない、 かといって妥協しまくりのダメ仕様でも誰も使わない。 その結果を一見して「迷走」と決めつけることは誰にもできるw
406 :11/08/31 16bitは必要な妥協だったとは思わんがな
407 :11/09/01 根拠は? どうなっていたのと思うの?
408 :11/09/01 必要な妥協だった、迷走ではない、と開き直るほうが簡単だよね でも互換漢字の中に統合漢字を適当に混ぜるとか、何も考えてないのは丸わかり 規格作ってるやつらは実装しなくていいんだから楽だよなあ
409 :11/09/02 必要な妥協なんてものはそもそも無い。 ないものを攻撃している奴は馬鹿。 仕方ない妥協があるだけ。
410 :11/09/02 仕方も工夫も色々あったけど 馬鹿が都合悪い部分放置でそのままreleaseしたんだろ なんで「仕方なかった」なんて嘘が通ると思うのか まだ「必要だった」って言い訳のほうがマシだよ
411 :11/09/02 >>409 >>408 だけど、妥協そのものを攻撃してるんじゃなくて >>399 みたいな開き直りについて言ってるだけだから 必要とか仕方ないとかそのへんの細かいニュアンスは俺の言ってる本筋とは関係ないから
412 :11/09/02 安価ミスすまん >>399 じゃなくて>>405 ね
413 :11/09/02 経緯をよく知らないけど、中国/日本の当局者に6万語で収まるのかをきちんと聞いたのか? 単に憶測で6万語で収まると判断したのか?
414 :11/09/02 Unicodeは最初からHan Unificationありき。 Xerox(とApple)でHan Unificationが研究されたから、 Unicodeが誕生のきっかけが出来た。 日本ではEmacsやArenaの多言語化を、 ISO 2022ベースでやっていた頃。
415 :11/09/04 >>414 最初から、というか、最初だけ。 誕生のきっかけであって、もう今ではとてもじゃないが、機能してるとは言えん 同じ字体が互換漢字・互換漢字両方で表せるのがまずおかしいのに さらにKS X 1001とかいう規格から、同じ字体で読みだけが違う互換漢字も追加されて 統一漢字+異体字セレクタで統一漢字でも字体を変更できるようになって と思ったら異体字セレクタに汎用電子がAdobeと同じ字体を重複登録しはじめて トドメに、異なった統一漢字同士でも異体字セレクタによっては同じ字体になるんだから……
416 :11/09/04 >>415 > 機能してるとは言えん はあ?
417 :11/09/04 うん、そうだね
418 :11/09/05 その通りだ
419 :11/09/05 >>294 アンダースコアの有る無しで意味が違う、っていうことの方が狂気の沙汰だと思う
420 :11/09/05 狂気はお前だ。
421 :11/09/06 アンスコあるのと無いのでは全然違うだろ。
422 :11/09/06 アンダースコートは無い方が良い
423 :11/09/10 >>413 まずいよこれ無理だよ、ってのは少なくとも日本の機関や企業から結構発信してたはず
424 :11/09/10 収まらないのはUnicodeが開発される前からわかっていた。 収めるためのHan Unificationが適切かどうかが議論になった。 >>414 > Unicodeは最初からHan Unificationありき。 > Xerox(とApple)でHan Unificationが研究されたから、 > Unicodeが誕生のきっかけが出来た。
425 :11/09/10 で、不適切だったと
426 :11/09/10 まだ天安門の頃か
427 :11/11/08 >>423 それでも説得して変えさせることは出来なかった。 かといって代替を用意して それを普及させるだけの力もなかった。 ガラパゴス規格を作っては国内オンリーで威張る だけの親方日の丸体質では最初から無理でした。 せめて今後は上手く捻じ込む交渉術を学んでいただきたいものです。 無理か。無能なJIS関係者や学者に金撒くんじゃなくて 最初から、ロビイストに金を突っ込むのが正しいな。
428 :11/11/08 今更お金撒いてももう無理なんじゃない? 文字コードには詳しくないんだけど プログラマのための文字コード入門読む限りでは 今後もシフトJISを使うのが一番安全という気がひしひしとしてくる。 実際、Windowsも内部はUnicodeだけどインタフェースはNLSを通してシフトJISを使うわけだし。
429 :11/11/08 .Netでもそんな扱いだっけ?
430 :11/11/08 シフトJISってWindows以外じゃ使わないんだけどなあ…
431 :11/11/08 シフトJISって恥ずかしいよね
432 :11/11/08 Windows使いだが、業務用のバッチファイル以外でシフトJISなんか使わねーぞ。 ソースコードもHTMLもデータベースもテキストファイルも全部ウニコードにしてる。 ただメールだけはISO-2022-JPでないと文字化けする糞アプリが存在するので なかなかUTF-8に移行できない。
433 :11/11/08 Visual C++がコードページにうにコードをセットできないのがすべての敗因。 コマンドプロンプトも未だにうにコード使えないし、ファイルシステム事態はうにコードを使えても ファイル名をやり取りするAPIの中にうにコード版が存在しないものが… WindowsだけシフトJISで。
434 :11/11/08 >コマンドプロンプトも未だにうにコード使えないし cp 65001
435 :11/11/08 >>433 ttp://yukarin.wiki.fc2.com/wiki/Tips
436 :11/11/08 よし、コマンドプロンプトのうにコード問題は解決したぞ あとはVC++がlocaleにうにコードをセットできるようになってくれれば解決だ。
437 :11/11/08 ほー。 chcp 65001すると今まで動いてた以下のコードが正しく動かないんだがどうすればいい? _tsetlocale(LC_CTYPE, _T("")); _tprintf(_T("\n"));
438 :11/11/08 windows のシステムロケールを変更して再起動
439 :11/11/08 mendoxer!
440 :11/11/17 囗囘囙囚四囜囝回囟因囡团団囤囥囦囧囨囩囪囫囬园囮囯困囱囲図围囵囶囷囸囹固囻囼国图 囿圀圁圂圃圄圅圆圇圈圉圊國圌圍圎圏圐圑園圓圔圕圖圗團圙圚圛圜圝圞
441 :11/11/19 シフトJISはWindowsだけってことはないと思うぞ。 むしろ自分の周りだとWindows以外のシステムはいろいろあるけど 情報交換はシフトJISでまず問題がない。ユニコードにお目にかかる ことのほうが滅多にない。
442 :11/11/20 >>441 > 情報交換はシフトJISでまず問題がない。 老害しねや
443 :11/11/20 最近は中国人の顧客とかも増えてるからUnicode対応じゃねーと死ぬわ俺んとこは
444 :11/11/20 異体字セレクタと互換漢字どっち使うにしてもUnicodeは地獄
445 :11/11/20 互換漢字・意自体セレクタはUnicodeよりシフトジスの方が優れていると?
446 :11/11/20 中国の客とか、その時点で死だろ
447 :11/11/20 異体字があっても意味を区別できるヤツなんて 1000人に1も居ないんだから、異体字なんて駆逐してしまえ。 国も時代に合わせろよ。
448 :11/11/20 全国の渡邊さんと渡邉さんがアップをはじめたようです
449 :11/11/21 源規格分離のUnicodeに移行すれば、メリットは多数あってもデメリットは無いだろ。 互換漢字とか話をすり替えてユニコード批判するしかないとは。 いつまで20世紀に生きてるんだよ
450 :11/11/21 >>444 だけど、>>441 書いたのは俺じゃないからな 当然だけどShift_JISが使えない規格ってのが大前提だが >>449 みたいなやつも程度としては>>441 と同レベルだわ デメリットないとか本気で言ってんならな そりゃ、ソフトウェアを源規格分離のUnicodeで作るだけなら楽だけど 使うやつはUnicodeのことなんてなにも分かっちゃいないんだぞ 使われてるうちにデータがどういう惨状になるか分かってんのか……
451 :11/11/21 >>449 は全ての問題が解決した22世紀から来た人なんだろう、多分
452 :11/11/23 >>449 合成漢字とか、マイナーな漢字で問題が有るっちゃあるらしい。 だから、PDFに複数のエンコーディングを同時に使いたいという需要が あったりする。
453 :11/11/24 原規格分離でも、別規格の文字が同じコードポイントという致命的欠点を「前世紀に批判」と誤魔化してみても、 その致命的欠点が前世紀からそのままであるという事実は変わらないけどなw
454 :11/11/24 >453 それは別に致命的な欠点ではないだろう 統一漢字をせっかくまとめたのに、互換漢字を作ったのが失敗なんだよ 最初から異体字はセレクタでよかった
455 :11/11/24 使い物にならないままでよかった、とw
456 :11/11/24 ハァ?
457 :11/11/26 痛い字セレクたん
458 :12/01/09 >>457
459 :12/01/09 れ
460 :12/01/15 書き込みが少ないようだが、スレタイの疑問には コンセンサスが得られたってことでいいんだよな Unicode: UTF-16リトルエンディアンBOMあり UTF-8: よく使うアレ
461 :12/01/16 そんなコンセンサスはない。 MSがそう表記したがってるのは事実。 'Unicode'と'UTF-16LE'を同一視するような言い方をすれば 頭の弱いかわいそうな人と見なされる。 少なくともそいつと技術の話はできない。
462 :12/01/16 JavaもUTF-16の意で使うよね。MSだけじゃなくて
463 :12/01/16 >>462 使わねーよ。よほど古い、1990年代にかかれたような文書ならともかく。 単に文字列の内部表現がUTF-16というだけ。
464 :12/01/16 つまり使ってるという訳ですね
465 :12/01/16 使ってないじゃんw
466 :12/01/16 実質UTF-16しかなかった時代には、Unicode=UTF-16として扱っているドキュメントは多かった MSは、単に旧時代の言い方をいつまでも引きずっているだけ。別にそう表記したがっているわけじゃない
467 :12/01/16 かつては符号化文字集合と文字符号化方式は一対一で不可分だったからね でも時代は変わったんだからマイクロソフトは自分の所でしか通じない用語は改善するべきだと思う
468 :12/01/16 >>463 おJA様はUnicodeがUTF-16BEの様ですね。 System.out.printf(new String(new byte[]{(byte)0x30, (byte)0x70, (byte)0x30, (byte)0x4B}, "Unicode"));
469 :12/01/17 お前も頭悪いな。そんなところの互換性無くして誰か喜ぶと思ったのか?
470 :12/01/17 つまり使ってる MSと同じ
471 :12/01/17 >>467 そりゃ、無理な相談だ
472 :12/01/28 >>467 日本語でおk
473 :12/01/28 結局Unicodeの定義にコンセンサスがないので、違いを語ることができないということでOK? Unicodeは規格の名前だが、文字集合の意味で使われたり、UTF-16の意味で使われたり、意味も分からずユニコードと言ってみたりカオス?
474 :12/01/29 混同してるバカがいる、ってだけの話
475 :12/02/07 英語は大小あわせて46文字しかないし、数字10文字、記号もろもろ入れても7bitで128種類も有れば足りるよね。1byteは8bitだから頭は常に0にしとくよ。 -> ascii (7bit) んじゃ「頭に1つけたときは半角カタカナ」ってことにしといたらasciiに日本語混ぜれるんじゃね? いろは47文字に濁点、半濁点、カギカッコとか句読点も入れとくわ。 日本でバックスラッシュとか使わんからこいつは円記号と一緒なwww俺天才ww -> JIS X 0201 アルファベットだけじゃヨーロッパは物足りないんで、 日本が半角カナ入れたところにウムラウト付きの文字とか入れときます。 -> latin-1 漢字絶対必要なんで、asciiとかほっといてとりあえず2バイトで表現できる文字集合選定しときます。 限りある空間資源なんで「掴」と「摑」とかは一緒ってことで堪忍してください。(包摂) あ、英語書く時は全部全角でおながいします。 -> 97JIS符号化方式によるJIS X 0208文字集合の利用 いやいや、英語重要なんで。マジ。無視とかありえないんで。 はい、頭が1のバイト隣同士でasciiサンに迷惑かけないよう二人組作ってー。 JIS X 0201のカナ文字は無視しておk。これでJIS X 0208の文字も表現できる。 ……あれ、半角と全角でアルファベットダブっちまってるけど……まいいか。 -> EUC-JP おい、メールは7bit符号しか使ったあかんらしいぞ。えー。 切替用の透明文字(エスケープ文字)作ってその文字以降はそれぞれのコードってことにしよ。 -> ISO-2022-JP asciiもJIS X 0201の半角カナも無視とか親泣くぞ。過去の遺産大事にしろ。 まぁ漢字使いたいけどエスケープ文字とかダルすぎるし、 JIS X 0201の空いたトコもらって2byteで使わせてもらうわ。 え?そこは制御文字用って?知るかボケ。 -> Shift_JIS
476 :12/02/07 結局同じ文章に外国語入り混じらせて使いたい? 分かった分かった。お前ら黙れ。4バイトで世界中の文字全部平等に並べ直そう。な。 -> ISO/IEC 10646 ちょっとまって同じ事やろうとしてるんだけど。2byteで。 -> Unicode 足並みそろえよか。4byteやけど上2byte全部0の実質Unicodeでやってこや。 おうアジアの土人ども、母国語の文字数すら数えられんのに大きい顔すんなよ? 迷惑なんだから、似たような文字はガンガン同じにまとめとけ。(CJK統合漢字) -> 10646とUnicodeサブセット メンゴメンゴ。65536個じゃ足らんかったわw Unicodeの2byte2つ組み合わせる方針にします。 2つのbyteのうち前後どっちを先にするかは文章の始めに印を付けて表すことにしましょう。(BOM) 素直に全部前から読む時はビッグエンディアン、天邪鬼さんはリトルエンディアンってことで。 でもでも、やっぱよく使う文字とよく使わない文字が同じビット数占拠するのもバカらしいんでー、 よく使う文字(BMPの文字)は2byte単体、それ以外は2つくっつけて表す事にします。(サロゲートペア) -> UTF-16 結局くっつけるんかいwwwそれやったらasciiとの互換も考えれwww 1文字あたりのバイト数は可変長だけどasciiの文字しか使わなかったらasciiと一緒になる。 -> UTF-8 サロゲートペアは甘え。容量も懐も大きいとこ見せろ。 Unicodeをそのまま直書きで4byte固定符号化方式。どや。 Unicodeの文字並び(U+00303Dとか)がそのまんま0000303Dで分かりやすい。 -> UTF-32
477 :12/02/07 符号化文字集合の一文字1コードっていう大原則を破った時点でもうぐちゃぐちゃだったんだよ。 もうどんな符号化文字集合を持ってきても絶対に誰も幸せになれない。
478 :12/02/07 >>476 Unicodeの意味をを勘違いしている典型例ですね 円コーディングフォームと円コーディングスキームの区別もつかなくて、 リトルエンディアンが天の邪鬼とか言い出すバカ
479 :12/02/08 わけ判らん駄文を読むヤツが居たという事の方に笑ってしまったわ
480 :12/02/08 円コーディングw
481 :12/02/08 誰も46文字にはつっこまんのか。
482 :12/02/08 >>475-476 がまるっきり変遷の歴史と違う上に、技術屋とは思えないレベルの勘違いがありすぎ
483 :12/02/08 英語は大小あわせて46文字しかないね。 -> ascii (7bit) アイちゃん言語訓練には足りないね。 -> UTF-32
484 :12/02/08 いろは48文字につっこむのが先
485 :12/02/08 なんでバイトオーダーとキャストの話が出てこない?
486 :12/02/09 kwsk
487 :12/02/09 >>475-476 はセンスあるね エンディアンの説明がおかしい他はいい線いってる。 時系列を変えてるのはわかりやすさのためだろ
488 :12/02/10 TCP/IPの立場から考えればリトルエンディアンは十分天邪鬼だろ。 Intel CPUはリトルエンディアンだが 整数値を小さな型にキャストしようとする時 先頭アドレスを変えずに読み込みを途中で打ち切るだけで済む。 ビッグエンディアンだとスライドさせないといけない。 その分リソースを食う。 でも数値をどこかで切り捨てたい時とか上から順にダンプかけたいときは メリット・デメリットが逆になる。 円記号問題の根底はJIS X 0201というよりISO 646各国版の普及にあって、 もっと世界的なもんじゃないのか? トライグラフとか。 誰か詳しい人解説頼む。
489 :12/02/10 トライグラフはEBCDICでもC言語を書けるようにしたものだから、あまり関係ない。
490 :12/02/10 えっ?
491 :12/02/11 ビッグエンディアンがマトモだと信じているバカはプログロマー止めた方がいい
492 :12/02/11 なんで? ワード長の拡張で、対応がずれる、以外のディスアドバンテージがあるならどうぞ。
493 :12/02/11 どう考えても下位ビットが下位アドレスに格納されるリトル園ディンのが自然じゃね? ビッグエンディアンは奇数アドレスアクセスとかできないでしょ。 GIF画像の圧縮みたいな可変ビット長データの連続してパッキングは、ビッグエンディアンじゃやってられない。 デメリットは「ビットの上位の方向とバイトの上位の方向が逆」に尽きる。
494 :12/02/11 こうして小人さんたちの戦いは続くのであった。
495 :12/02/11 まともなビッグエンディアンのアーキテクチャなら、ビットにアドレスが付く命令でも、 MSBがアドレス0だよ? ビットアドレスが2の冪と対応してない、とは言えるけど、直感的でない、以外に問題ある?
496 :12/02/11 1バイト内のビットアドレスじゃなくてメモリ(バイト)アドレスのことだろ。 4バイト整数12345678hの上位バイト12が上位メモリアドレス3に書かれるのがリトル。 4バイト整数12345678hの上位バイト12が下位メモリアドレス0に書かれるのがビッグ。 FFhに1足して上位桁に繰り上がったら、より下位のアドレスが変わるなんて変と思わないの?
497 :12/02/11 アドレスが大きい方が下位と思えばどうということはない。
498 :12/02/11 二つ前のレスも読めないなんて、 こういうバカがビッグエンディアンを設計したんだろうな
499 :12/02/11 UTF-8は上位ビットが下位アドレス側に格納されるから、設計者は馬鹿だし、 リトルエンディアン信者は当然使わないよなw
500 :12/02/11 どうやら自分以外は全て馬鹿病の患者が、リトルエンディアン凄い、偉い、と吠えてるだけのようですねw 準TADのTRONコードでも使ってろw
501 :12/02/11 >>388 考えたのはM$だからな。
502 :12/02/11 MS叩きとか、いまどき流行らんわ
503 :12/02/11 >>499 cpuがメモリに直接ワードアクセスする時のメモリイメージの話と、 バイトオリエントにシリアライズしたutf-8の話を一緒にするのはいくないぜ
504 :12/02/11 >>501 いやほんとbomのおかげで助かるわ。 utf-8とその他のコードをほぼ確実に判別できる
505 :12/02/11 >>504 utf-8なのにBOMって
506 :12/02/11 >>505 何か問題が? UTF-8のシグネチャーとして大活躍じゃないか
507 :12/02/12 名前が良くないな。 援交ディングスキームシグネチャー これでおk
508 :12/02/12 異体字セレクたん みたいだな
509 :12/02/12 UTF-8のBOMって、オプションなのでしょうか? 例えばUTF-16の場合、先頭の<FE FF>はU+FEFFでなくBOMと見なす必要がありますが、 UTF-8ではUnicode 6の3.10D95をみると『can』とあるので、UTF-8の先頭の<EF BB BF>を U+FEFFと見なすことは禁止されていないように見えます。 先頭<EF BB BF>の解釈は自由という理解で良いでしょうか?
510 :12/02/12 よくありません
511 :12/02/12 why?
512 :12/02/12 U+FEFFはBOM限定になったような
513 :12/02/12 既存の文書の存在は認めないのですね
514 :12/02/12 はい はい
515 :12/02/13 >>512 ソースキボンヌ
516 :12/02/13 http://www.unicode.org/charts/PDF/UFE70.pdf のU+FEFFで、non-breakingは代わりにU+2060を使ってね、と。 http://www.unicode.org/charts/PDF/U2000.pdf のU+2060で、BOMの曖昧さを無くす為に、と。 その方向で行こうね、位の意味合い?
517 :12/02/13 先頭のU+FEFFは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSPになるのか。 で、UTF-8ではUTF-16やUTF-32から変換されたときBOMが付くことがあって、 UTF-8としては不要だけどUTF-8かどうかの識別として使えるし違反ではないよ。 途中のU+FEFFは、ZWNBSPとして扱うけどなるべくU+2060を使ってね。 こんな感じの認識でいい?
518 :12/02/14 >先頭のU+FEFFは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSPになるのか。 いいと思うけど、細かい所がちょっと違う。 先頭のFE FFやFF FEの2バイトは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSP文字相当になる。 バイナリデータ(Encoding Scheme)をEncoding Formに読み取った時点でBOMは無くなる。 U+FEFFというのはUTF-16orUTF-32のEncoding FormだからBOMになり得ない。 >UTF-16やUTF-32から変換されたときBOMが付くことがあって これも同じく、Encoding FormをEncoding Schemeに変換したときにBOMが付くことがある
519 :12/02/14 「U+」はコードポイントの表記。Formじゃない。 コードポイント: u+feff (ZWNBS文字(非推奨)) UTF-16エンコードフォーム: <FEFF>(16ビット単位、u+は付かない) UTF-16エンコードスキーム: <FE FF FE FF>または<FF FE FF FE> (8バイト単位)。先頭のFE FFはBOM UTF-16BEエンコードスキーム: <FE FF>(8バイト単位)、先頭の<FE FF>はZWNBS文字だがZWNBSが非推奨
520 :12/02/14 なるほど。やっと理解しました。ありがとう。
521 :12/02/14 http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=4E62 > kHanyuPinyin 10760.010:g�i 文字化けワロス
522 :12/02/19 今来た俺に違いを3行で教えてくれ
523 :12/02/19 Unicode・・・文字集合 UTF-8・・・文字表現 です
524 :12/02/19 >>523 ほう、ではUnicode 6.0のどこに「Unicodeが文字集合の一つ」と 書かれているのかね?
525 :12/02/19 3行オーバーしたので答えられません。 自分でぐぐってください。
526 :12/02/19 仕様のどこと訊かれてググれと答える奴は プログラマーに剥いていない
527 :12/02/19 ハゲは結構多いよ
528 :12/02/19 プログラマーの率、アスペ率は異常
529 :12/02/19 細かいことにこだわらない奴はプログラマー向いてない。 向いてない人「ちょっとくらいいいでしょ?多めに見てよ」 コンピュータ「はあ?」
530 :12/02/19 そもそも「文字表現」ってなんだよ。ちゃんとした用語使えよ。
531 :12/02/19 文字表現は文字表現だよ (T-T)悲しい (^-^)うれしい こんなのが最近たくさん追加されてるだろ
532 :12/02/19 おいおい、2スレ目にもなってケツ論出てないのかよ
533 :12/02/19 >>523 痴呆があらわれたか
534 :12/02/19 Unicode=UTF-8 一般人に違いなどわからんからこれでよし
535 :12/02/19 いいわけないだろカスが^^
536 :12/02/20 元々の規格 UTF-8 UTF-16BE UTF-16LE UTF-32BE UTF-32LE マイクロソフトが追加した規格 (いずれもBOM付き) UTF-8 (上記と重複する) UTF-16 (省略BE-BOM) UTF-16LE-BOM UTF-32 (省略BE-BOM) UTF-32BE-BOM UTF-32LE-BOM ってことでよろしいですか?
537 :12/02/20 ぜんぜんダメ
538 :12/02/20 このスレで何度か書かれてるけど、 そろそろencoding formとencoding schemeの違いを 理解した方がいいよ
539 :12/02/20 Unicode規格で定義されるEncoding Scheme UTF-8 (BOMなし) ←MSの「UTF-8」 UTF-8 (BOM付き) UTF-16 (BOMなしBE、先頭にU+FEFFは書けない) UTF-16 (BOMありBE、先頭の<FE FF>はU+FEFFでなくBOM) ←MSの「Unicode big endian」 UTF-16 (BOMありLE、先頭の<FF FE>はU+FEFFでなくBOM) ←MSの「Unicode」 UTF-16BE (BOMなしBE、先頭の<FE FF>はBOMでなくU+FEFF) UTF-16LE (BOMなしLE、先頭の<FF FE>はBOMでなくU+FEFF) UTF-32 (BOMなしBE、先頭にU+FEFFは書けない) UTF-32 (BOMありBE、先頭の<00 00 FE FF>はU+FEFFでなくBOM) UTF-32 (BOMありLE、先頭の<FF FE 00 00>はU+FEFFでなくBOM) UTF-32BE (BOMなしBE、先頭の<00 00 FE FF>はBOMでなくU+FEFF) UTF-32LE (BOMなしLE、先頭の<FF FE 00 00>はBOMでなくU+FEFF)
540 :12/02/20 最初の二つを間違えた。正しくは ↓ UTF-8 (BOMなし) UTF-8 (BOMあり) ←MSの「UTF-8」
541 :12/02/20 そもそもBOMってMSの拡張じゃないの? Unicodeにそんな仕様はいってるの?
542 :12/02/21 入ってますがな。 なければどんなに幸せだったことか… BOMのない世界にforkしたい。
543 :12/02/21 無くて困ったことはあるが、 あって困ったことはありませぬ。
544 :12/02/21 BOMあるとshebangが正常に動作しない
545 :12/02/21 そのファイルだけBOMとれば? 文字コード不明なファイルを読み取ろうとするシバンは(・∀・)ノ●。 日本語のパスはどうすんだよ。
546 :12/02/21 BOM が MS拡張とかどんだけ…… まだ ISO-10646 が正式な規格になる以前からありますがな。
547 :12/02/21 >>537 えーなんでダメなんだよ?これjavaのエンコードライブラリそのまんまなんだぜ?
548 :12/02/21 >>547 JavaはBOM周りの処理のバグを認識しつつ バグを永久に直さないことに決定済みだろ 『マイクロソフトが追加した規格』が『おJavaの認識する名前』で BOMがMS独自という誤った記述が無ければおけ
549 :12/02/21 >>544 shebangに関して言えば、 shebangを読み取るプログラムが Unicodeに対応していないというべきだろうね。 たぶん、UTF32で書かれたshebangも読み取れないはず。
550 :12/02/21 >>543 無くて困ったことは皆無ですが、 あって困ったことはいやほどあります。
551 :12/02/21 >>550 無くて困ったというのは文字コードが明確でなかったと想像できるけど、 あって困ったというのは、具体的にどんなこと?
552 :12/02/21 >>551 上にあるけどshbangが通らないとか(頻発するので慣れた)、 ビルドが通らないとか(頻発するので慣れた)、 SQLの実行に失敗するとか(多数のDDLの実行途中だったのでリカバーに泣いた)。
553 :12/02/21 ああ、あと複数のファイルをcatで繋いだら境目にゴミが混じったってのもあった。
554 :12/02/21 あるテキストの改行が Cr CrLf Lf の 三つが混ざっちゃうことあるの?
555 :12/02/21 >>551 単なるバイトストリームとして扱えなくなるケース。
556 :12/02/21 BOMが認識できないバギーなコンパイラはともかく、catは違うような。 テキストファイルをバイナリで結合することが間違ってると思う。 結合するファイルの文字コードが違ってたら破綻するし、 ISO-2022はそもそもバイナリ結合できなくね?
557 :12/02/22 >>556 >>553 , >>555 は、BOM なし UTF-8 ならば cat で連結できる、って話じゃないの? 別なコードの話を持ちだしても意味ないと思う。
558 :12/02/22 >>556 >バギーなコンパイラ 言いがかり。 そういうことがないようにUTF-8を使うのに BOMがあるだけでパー。 >結合するファイルの文字コードが違ってたら破綻 同じUTF-8だけどな。 BOMがあるだけでパー。
559 :12/02/22 utf-8対応をうたうならbomを認識できなくてはならないのに 僕のKUSOコンパイラはダメなんです。と言われてもなあ。 取り敢えずKUSOコンパイラユーザーにデメリットが有るのはわかったw
560 :12/02/22 catでbomが困るなんて、 「テキストに日本語を書くと様々な問題を起こすので日本語の使用はデメリット」 とか 「csvにヘッダー行を書くとcatできない問題があるので書かないようにしている」 ってのと同レベル
561 :12/02/22 >>559 BOMさえなければ、とくにUTF-8に 対応することがそもそも不要。 バギーでもクソでもない。 UTF-8原理主義者は面倒くさいな。
562 :12/02/22 バイトオーダーという概念がないUTF-8でBOMとはこれいかに?
563 :12/02/22 仕様に従っているかどうかの話と 仕様自体の妥当性は別の話。 utf-8安置は頭が悪いな
564 :12/02/22 うにコード安置はいるがutf-8安置はいるのだろうか?
565 :12/02/22 ファイル名に日本語を使ってはいけないとか、メールのタイトルに日本語を 使ってはいけないというのは、UNIXの伝統的な掟です。 LinuxはUNIXに憧れているので、UNIXの掟を忠実に守ります。 掟を守るのは大事なことです。 UTF-8を許せば日本語を使う馬鹿が出てきますよ。
566 :12/02/22 UTF-8は、ASCII上位互換コーディングシステムとして設計された。 バイトストリームとして扱えば、プログラムがそのまま使えるように。 Ken Thompson先生が。Unicodeの外の世界で。 だからUnicode.orgがUTF-8にもBOMを付けるのは味噌をつけてしまったようなもの。 ただ既にBOMがあるのだから、当然の帰結ではあるのだが。 もともとのUnicodeの考え(wide character主義)とUTF-8は乖離しているから、 こういう残念な状態になってしまった。
567 :12/02/22 >>565 パス名といえば、例えば、 "¥Users¥漢字名さん¥ドキュメント" "漢字名さん" "ドキュメント" それぞれにBOMが付くとパス名処理がすごく面倒になる。 Unicode互換の処理系を名乗るにはやらないといけないけど、 そういうOS、ミドルウェアは未だ存在しない。
568 :12/02/22 大体BOM付きとか滅茶苦茶不合理じゃん。 "a" だけで何バイトだよ? 旧来のBOM無しUnicodeを新しいUnicodeとして制定しなおしましょう。
569 :12/02/22 >>567 だからこそ許してはいけないのです。 ファイル名やメールの件名に日本語を使ってはいけません。
570 :12/02/22 さあ、早くEF BB BFを削る作業に戻るんだ。
571 :12/02/22 >>568 それは思い上がりですね。 ASCIIだけで充分です。
572 :12/02/22 NotePad BOM付きしか認識しない。 UNIX系 BOM無しを前提にしている。 やっぱM$の陰謀以外考えられないわけだが。
573 :12/02/22 >>571 ならば、おまえだけは日本語で書き込むなよ。
574 :12/02/22 kokoha tanoshii intaaneto desune
575 :12/02/22 >>573 俺はUNIXもLinuxも使っていないのでメールの件名に日本語を使うし、 ファイル名にも日本語を使います。 HTMLメールが送られてきたからと言って怒ったりしません。
576 :12/02/22 571 名前:デフォルトの名無しさん :2012/02/22(水) 15:20:33.65 >>568 それは思い上がりですね。 ASCIIだけで充分です。 >>575 だからおまえは日本語でこの掲示板に書き込む権利は一切無いの。
577 :12/02/22 >>576 いえいえ、俺はUNIXもLinuxも使わないので歴史的に日本語OKなのです。 ご心配には及びません。
578 :12/02/22 nanda tadano baka dattaka
579 :12/02/22 >>567 Unicode規格のencoding formとencoding schemeの説明を読み直してこい フォルダー名にbomが付くとかあり得ないから
580 :12/02/22 asciiとかどれだけ可搬性のないのものを持ち出すんだよ。 @とか[とかは機種依存文字なのを知らんのか最近の若いモンは。
581 :12/02/22 >>580 8bit目を立てるのはマナー違反です。
582 :12/02/22 >>579 何言ってるかさっぱりわからん。 パス名はメモリ上のデータに限られてると限定しているわけ?
583 :12/02/22 >>572 NotePad は BOM なくても UTF-8 を認識するよ。 でも保存するときに強制的に BOM がつくのが問題。 Unix でなくても、たとえば文書のヘッダやフッタを別のテキストファイルから include してくるというのは、よくある処理だと思うけど、そういう場合に、 いちいち BOM の処理が必要というのは不合理。 字数とかワードラップとかの処理が必要な場合は仕方ないけれど、そうでない 場合はバイナリとテキストで同じプログラムが使えるようになっているのが望 ましい。
584 :12/02/22 >>582 Unicode規格ではEncoding FormにBOMの概念は無いんですよ。(ここらへんはRFC 3629と定義が違う) Windowsのフォルダー名はEncoding SchemeでなくEncoding Form単位で読み書きするので、 フォルダー名にBOMが入ることはないです
585 :12/02/22 >>583 >たとえば文書のヘッダやフッタを別のテキストファイルから >include してくるというのは、よくある処理だと思うけど、そういう場合に、 MS Word文書をバイナリで結合したら読み取れませんでした。てのと同レベル。 バイナリデータを挿入するんでなく、「テキスト」を挿入するよう見直した方がいい。 ISO/IEC 2022だって二つのファイルをバイナリで結合したら壊れるだろ
586 :12/02/22 >>580 ASCIIの7ビット文字は、現代で現実的に 充分ポータブルだろ。 どのあたりを心配してる?
587 :12/02/22 >>586 ∩_∩ / \ /\ | (^)=(^) | 人人人人人人人人人人 | ●_● | < BOM否定派に対する皮肉だろ> / // ///ヽ <言わせんな恥ずかしい> | 〃 ------ ヾ | YYYYYYYYYYYYYY \__二__ノ
588 :12/02/22 >>584 フォルダ名が外からもたらされたら、 >フォルダー名にBOMが入ることはないです なんて課程は全くできないけど?
589 :12/02/22 >>588 BOMとU+FEFFは違う物です。Encoding SchemeとEncoding Formの違いを理解してください。 Windows APIでフォルダーを作成する際の名前は「UTF-16(Encoding Form)」でしか指定できないのです。 「UTF-16(Encoding Scheme)」を受け取るAPIは有りません。 外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、 BOMを取り除いた形でWindowsに渡す必要があります。
590 :12/02/22 > 外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、 > BOMを取り除いた形で こういう処理をユーザがしないといけないって話なんだけど?
591 :12/02/22 話がずれてないか? もとはパス名処理が大変と言う567に対し、 文字列になってる時点でBOMは無いので単純だというのが579。 バイナリを文字列に変換するのにBOM処理は当然必要なんだけど、 それは567の「パス名処理が大変」「実装が存在しない」とは違う話。
592 :12/02/22 BOMっていうのはファイルにしか存在しないものだよ。 BOM付きの文字列を半分に分けたらどうする? 前半の文字列にはBOMがついて、 後半の文字列にはBOMがついてない? それともわざわざ付けると思う? BOMが存在するのは外部リソースのみ それをUNICODE文書として読み取った時、 BOMは消さないといけない。 だから、APIに渡す文字列がBOM無しなのはアタリマエのこと。
593 :12/02/22 プログラマが頑張らないといけない実装しかないから、 パス名処理が大変なんでしょ? > 文字列になってる時点でBOMは無い 「文字列になって」 この定義自体が難しいから、 プログラマが何も気にしないでも問題が起きない実装はないわけだ。 そもそも利用者のレベルでも問題が起きうる。
594 :12/02/22 >>592 > BOMっていうのはファイルにしか存在しないものだよ。 外部リソースならどんなものにも付く可能性がある。
595 :12/02/22 >>593 > 「文字列になって」 > この定義自体が難しいから、 簡単。バイナリではなく文字列として解釈できる準備ができた時。 それは文字列型に代入した時や、 UTF8フラグなんかをつけた時。
596 :12/02/22 そもそも「ファイル」っていう概念をちゃんと>>592 が分かって書いてるのかどうかも怪しい
597 :12/02/22 UNIXでいう「ファイル」だけど?
598 :12/02/23 そもそもBOM付きデータは「バイナリ」であって「テキスト」ではない、と考えてる。 「テキスト」は純粋に「文字列」を表現する要素のみで構成されたものであるべき。
599 :12/02/23 バイト列だから順序が必要なんじゃろ? 整数列だから順序が必要ないんじゃろ? それがエンコードスキームとエンコードフォームを分けた由来じゃろ? Unicodeのエンコードフォームでは文字列は数値列だから、ひとつの文字はひとつの数値として扱われる。 しかしこれが物理的にコンピュータ上で扱われるとき、 コンピュータはその数値列を一つのバイト値として扱えない。 つまり、一つの文字は複数のバイト列になる。 だからバイト列に順序が必要になる。 一方、UTF-8はいずれの場合もバイト列として扱う。 文字列はバイト列であるので順番が必要ない。 という話じゃなかったっけあはん大陸。
600 :12/02/23 ん >一方、UTF-8はいずれの場合もバイト列として扱う。 >文字列はバイト列であるので順番が必要ない。 これは「文字列もまたバイト列であるので順番が必要ない」と書くべきか^^;
601 :12/02/23 >>565 UTF-8 許されてるなら日本語使っても良いと思う むしろファイル名に半角 space 入れる香具師の方が もう阿呆かと
602 :12/02/23 >>594 ファイルじゃない外部リソースなんかあるのか
603 :12/02/23 >>601 何がいけないんだ?
604 :12/02/23 >>602 メモリ、ストリームなどなど^^
605 :12/02/23 >>604 それって、つまり、ずーっと辿るとファイルに行き着くだろ ファイル以外でBOMなんて付かないだろ
606 :12/02/23 >>605 いやいや。 例えばリアルタイムにコード変換してる時は元ファイルにはBOMついてないし^^; メモリに展開される時にBOMがつく(つかないと判別できない^^) そもそもプログラム内部は論理表現なのでBOMなどというものはありえない。 これがメモリに展開される瞬間、つまり物理表現に変わる瞬間にバイト順序が必要になる。 ストリームも同じ。
607 :12/02/23 >>603 だろ?
608 :12/02/23 恥ずかしいスレだな
609 :12/02/23 J( 'ー`)し ごめんね。おかあさんはじめてUnicode使ったから、ごめんね
610 :12/02/23 >>606 '\0'を文字列の途中に突っ込むのと同じ話だけど。 やろうと思えば出来る。でも普通はメモリ中のデータにBOMは入れない。 くだらない話だから伸ばすな。
611 :12/02/23 >>605 > それって、つまり、ずーっと辿るとファイルに行き着くだろ アホなの?
612 :12/02/23 >>593 明確だよ。 byte[]型は文字列でない。stringは文字列。 CでもWindowsならchar[]からTCHAR[]になった時点で文字列。 CでもASCII NUL終端で扱っている時点でBOMが有るのは間違い。 UTF-16とか扱えなくなるだろ
613 :12/02/23 >>601 むしろ半角スペースで動かなくなる方が害モノだね。 やるべきことをやってないだけ。 "c:\a bcacls.exe" "c:de f" /R "SYSTEM" SET "PATH=c:a b" 常にこう書けば何が渡されても破綻しない
614 :12/02/23 crlf->lf cr->lf lf->crlf --------------- ->の意味わ?
615 :12/02/23 >612 > CでもWindowsならchar[]からTCHAR[]になった時点で文字列。 アホなの?
616 :12/02/23 そもそもUTF-16やUTF-32は 文字に\0が含まれるのでchar[]では扱えない。
617 :12/02/23 >>612 > CでもWindowsならchar[]からTCHAR[]になった時点で文字列。 char[] == TCHAR[]
618 :12/02/23 犬が混じると低レベル化するな。
619 :12/02/23 また犬が来たw
620 :12/02/23 テーブル(Unicode)とデータ表現(UTF-8)の違いじゃねーの?
621 :12/02/23 >612 > CでもWindowsならchar[]からTCHAR[]になった時点で文字列。 Windowsでは#define UNICODEとしないと文字列を扱えないそうです。
622 :12/02/23 >>616 いや扱える。 <stdio.h><string.h>などが文字列はnull terminate前提、 Cコンパイラも文字列リテラルが同様ってだけ。 ex. struct UTF16String { int length; char data[]; };
623 :12/02/23 MessageBoxA と MessageBoxW の違いも判ってなさそう出汁
624 :12/02/23 Shift_JISは常にビッグエンディアンだけど UTF-16はBEとLEがあるクソ仕様、SJISとCP932の問題よりさらに酷い おまけにサロゲートペアのせいで何が16なのかと言うレベル バイトストリームとしてはBEに限定して APIなどではuint16_t*なりwchar_t*で扱えばいいのに 何故バイトストリームでBE版とLE版を用意したのかと
625 :12/02/23 ネットワークバイトオーダーもJavaのデータアウトプットもBEに規定されてたよな。 たしかOracleもBEだったか。16LEは確かに誰得。
626 :12/02/23 同じchar[]でもバイト列と文字列ではセマンティクスは別物になる ファイル or メモリ、char[] or TCHAR[] 重要なのはデータソースでも型でも無く、データの意味そのもの 同じintでも電圧の変数に電流の値を代入して良いわけがなく 同じstringでも通常の文字列とhtml文字列を混同すればxssに一直線だ 内部表現は[文字符号化方式]でなく[符号化文字集合]と考えるのが適切 バイナリとして読み込んだUTF-16文書のバッファ(文字符号化方式)のポインタを wchar_t*(符号化文字集合)に単純キャストするような荒業でも動作する環境はあるが wchar_tが4バイトの処理系ではそうはいかない
627 :12/02/23 何でキチガイが湧いてるの?
628 :12/02/23 なんでレッテル厨が湧いてるの? 具体的な反論するのが怖いの?
629 :12/02/23 >>624 >Shift_JISは常にビッグエンディアンだけど 「A」は82h 60hという2バイトであって、3260h(33376)ではありません。 >>621 長さとペアでバイナリデータを保持するcharと、ヌル終端前提のTCHARを区別しろってことでしょ。 TCHARがcharかwchar_tかは関係無い。 >>626 の言う「重要なのはデータソースでも型でも無く、データの意味そのもの」を少しは理解しな
630 :12/02/23 文字集合JIS X 0208の A : コードポイント3区33点(3-33) → JIS X 0208の符号化方式Shift JISでは 0x82 0x60 と表現 → JIS X 0208の別の符号化方式EUC-JPでは 0xA3 0xC1 と表現 つまりUTF-32BEが最強
631 :12/02/24 >>628 Cの時代にcharで文字列とバイナリの両方を扱って きた人間には理解を超えているので、 相手に罵声を浴びせることしかできないんだぜ。 エンコードスキーム(バイトデータ)とエンコードフォームの 違いがこのスレで何度説明されたことか。 未だに全く理解できていないし
632 :12/02/24 Unicodeはwchar_tのために作られたわけじゃねーだろ
633 :12/02/24 >>631 まだ言ってるのかw
634 :12/02/24 >>626 この解釈間違ってると思うんだが 誰も突っ込まないのな
635 :12/02/24 >>631 Windowsのwchar_tは2バイトでutf-16で固定長じゃないんだから、 charでutf-8を扱った方がまし。
636 :12/02/24 >>635 utf-8はいいけど BOMのあり得るエンコードスキームUTF-8と BOMの無いエンコードフォームUTF-8は 異なる概念なので区別しろよw でないと、UTF-16BEはヌルが含まれるのでcで扱えないとか とんちんかんなことを言い出しかねん
637 :12/02/24 BOMありUTF-8使ってるのって日本だけなん?
638 :12/02/24 >>634 頼んだぞ
639 :12/02/24 >>637 Windowsのメモ帳が付けるというのに、 どうしてそんな考えに至ったのか知りたい
640 :12/02/24 >>636 メモリ上にはUnicode encoding formしかないと勘違いしている人?
641 :12/02/24 それだとファイルを読み込むことが不可能になってしまいます 読み取ったバイナリデータをテキストとして処理する前に エンコードフォームに直すと言うことでは?
642 :12/02/24 ヌル終端の文字列って超使われてるけどさ struct{char* begin, char* end}の値渡しか、その構造体へのポインタを渡すようにした方が良かったよね 今更ってレベルじゃないけど
643 :12/02/24 struct{char* begin, int len)の方がいい。
644 :12/02/24 struct{char*end;chars[];};の方がいい
645 :12/02/24 >>642 最初はstructなんてなかったんだよ。 そこまで斜めだと後出しですらないだろ。
646 :12/02/24 >>643 Pascalがそれ。 実装によってはnull characterも持てた。 けど勝利したのはCのシンプルさ。 同じデータ構造(char [])でバイナリも持てる。
647 :12/02/24 そのせいでCはUTF16や32に 特殊な型を持ち出さないと対応できなくなった。
648 :12/02/24 それどころかstrlenやstrcpyでも UTF16やUTF32専用の関数が必要になった。
649 :12/02/25 >>643 intじゃポインタで表現可能な範囲を持てる保証が無いよ 実際殆どの64bit環境(LP64やLLP64)でintでは4Gの壁が出来上がる せめてptrdiff_tにしないとね >>645 マジか、struct無かったのか・・・ でも斜めではなくね?STLでもbegin(),end()が基本だしさ
650 :12/02/25 >>649 昔の話だとして… Cの前身はT *とintの区別なかったんだよ。 型指定がなくて、型は名前のついてないWORD型しかない。 今で言うところのILP16で。(Integer, Long, Pointerが16bit) だからその影響でCでもしばらく型指定なしの変数宣言するとintだった。
651 :12/02/25 >>649 ならsize_tでいいだろ。 strlenの戻り値の型だ。
652 :12/02/25 >>650 cの前身っていったら1971年? そんな時代に16ビットが普及してたはずもないのだが
653 :12/02/25 パソコンの16ビットはそりゃそうだろうけど、 ミニコンの16ビットは70年代に16ビットは普通では?
654 :12/02/25 BCPLはPDP-7だっけかな。 と思って調べたらまさかの18ビット
655 :12/02/25 DECという会社があったこと #平成生まれが知らないことを挙げていこうぜ
656 :12/02/25 ここは加齢臭漂うスレとなりました。
657 :12/02/25 ファブリーズしても全然ダメなぐらい
658 :12/02/26 CrCrLfはWindowsだと1回の改行でMacだと2回の改行?
659 :12/02/26 CR/CRLF/LF が混在してるテキストなんて基本的に想定外という扱いでいいだろJK
660 :12/02/26 >>658 ソフトラインブレークは発狂の元
661 :12/02/26 CRとLFの連続を改行として扱えばいい 空行が無くなるが
662 :12/02/27 >>658 CrCrLfはWindowsだと不正な改行。 なのでそれを受け入れたい場合は、どう処理するかをソフトウェアの仕様で 決めなければならない。
663 :12/02/27 Crの次がLfならひとまとめ、Lfの次がCrならひとまとめって感じの実装が多い気がする 混ざってても大体うまくいくし CrCrLfLfLfCrLfLfCr → Cr,CrLf,Lf,LfCr,Lf,LfCr → 改行6個 CrLfCrLfCrLf → CrLf,CrLf,CrLf (Windows) LfLfLf → Lf,Lf,Lf (Linux) CrCrCr → Cr,Cr,Cr (Mac9以前)
664 :12/02/27 WIN/UNIX/MACごちゃまぜのソフトでWINのクライアントから編集するたびに改行が倍になってくやつがあったな
665 :12/02/27 CRのみは歴史的文書しかないから、特殊なアプリ以外は無視して問題なし。
666 :12/02/27 >>659 一方Microsoft Excelさんは平然と混ぜてくるのであった CSV形式で保存すると行の区切りにCRLFを使用するけど セル内に改行がある場合は""で囲った上でLFのみで出してくる斜め上仕様 そうした理由は分からんでもないけど・・・
667 :12/02/27 自分が作る場合はこんなふうに処理している。 1. CR または LF が連続していたら、それぞれの数を数える 2. LF が一個でもあったら CR は無視してその個数を改行数とする 3. LF がひとつもなかったら CR の個数を改行数とする 4. 出力の改行を決める必要があるときは、入力の最初の改行によって決める (入力がないときはOS依存……最近は LF 決め打ちが多いけど) わざと混在させる必要がある場合以外、これで問題ない。 もっとも、CR のみの文書っていまだかつて見たことないが。
668 :12/02/27 RFC4180ってAccessのCSVと同じだろ
669 :12/02/27 RFC4180読んでみた 2005年公開でこの内容ってことは単にMS Officeに合わせただけか MSの頭悪いCSVの仕様がRFCになってるとは 素直にメタ文字エスケープすればいいのに
670 :12/02/27 メタ文字こそ。 パーサーのことだけで読みやすさを考えてないだろ。
671 :12/02/28 俺はエスケープの方が途中で改行が混じっていない分読みやすい まぁその辺は人によるから不毛だな あとパーサーだけじゃないぞ ちょっとした文字の置換とかも、しやすさが全然違う
672 :12/02/29 \を入力するとなんで/になっちゃうの?
673 :12/02/29 なるのは君だけ
674 :12/03/02 \
675 :12/03/02 ∖ ∖ ╲ ╲ \ \
676 :12/03/02 >>675 みえる化
677 :12/03/02 クイックス懐かしいな・・・
678 :12/03/03 1ヶ月のケってなんなの?
679 :12/03/03 箇ないし个の変形。「け」ではない。
680 :12/03/03 へーへーへー。10へー。
681 :12/03/03 1ヵ月のカってなんなの?
682 :12/03/03 30人日の力だろ?
683 :12/03/03 ヵゕかカカ力刀
684 :12/03/03 >>681 それも >>679
685 :12/03/04 【 これはキーボードのローマ字入力でどのキーを押せば
686 :12/03/04 消せますか?
687 :12/03/12 もう面倒くさいから 1文字1MBで表現しろよ!
688 :12/03/12 らめぇ、回線が壊れちゃうよぉ
689 :12/03/12 原稿用紙一枚分のテキストが400MB
690 :12/03/12 動画でテキストを表現ですか。
691 :12/03/12 トントンツーツーは2進法なの?
692 :12/03/12 文字間セパレータがあるから記号としては3つじゃないか?
693 :12/03/12 ∧,,∧ ( `・ω・) ウーム…? / ∽ | しー-J
694 :12/03/12 >>692 ストップビット2 0:1ビット 1:1.5ビット
695 :12/03/12 >>694 書き直す ストップビット:4 0:2ビット 1:3ビット
696 :12/03/12 三進数
697 :12/03/13 学習塾
698 :12/03/13 痛い児セレクたん
699 :12/03/13 やっぱり二進数だわ トン、ツー
700 :12/03/14 >>699 その様子だと、お前は次の問題が解けねぇな。 英文が成立する最低限度のキャラクタのうち、出現頻度が一番高いのは、何?
701 :12/03/14 kumi
702 :12/03/14 すポース
703 :12/03/14 Siri
704 :12/03/14 chinbo
705 :12/03/16 >>700 話そらすバカ
706 :12/03/27 >>705 全くそれていないんだが、それが理解できないと言うことは、 1200 8N1 とか言っても理解できんのんだよなwww
707 :12/03/27 レイヤ1と2の区別がつかないハード屋さんですね。 わかります。 しかも1200っていつの時代
708 :12/03/27 ATZ ATZ ATDT110
709 :12/03/27 年寄りの加齢臭話はいいから文字コードの話しに戻ろうぜ
710 :12/03/28 >>707 お前・・・・分かるんだwww
711 :12/03/28 50歳以下は帰ってくれないか?
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
人工知能は感情を獲得する事ができると思いますか? (480)
初心者向け新言語 Small Basic スレ (240)
Pythonについて(アンチ専用) (781)
P2P型の完全匿名掲示板はまだ出来ないの?その2 (502)
【3DS】プチコンを語るスレ【DSi】 (512)
最近の若者はUNIX/LINUXを使えなさ過ぎる (375)
--log9.info------------------
マツコ・デラックス (432)
辻希美 アメーバブログ 6 (656)
和田アキ子が紅白落選してほしい奴→ (934)
▼▼▼離婚泥沼化■高嶋政伸の嫁 美元▼▼▼ (335)
★★★★★在日芸能人15★★★★★ (726)
【芹那】 不自然に押されてる芸能人 【満島ひかり】 (387)
【棒演技】アンチ向井理【LG】 (823)
醜体型+音痴+顔面異物入AKB板野友美 (223)
【自己満足】アンチ上地雄輔22【芳一カー完成】 (853)
辻チャンo(^-^)o (295)
【武将パン】大泉洋99【パンク探偵】 (208)
この人はなぜメディアに出てるの? (571)
●○●そーとー可愛い♪眞鍋かをりたん 79●○● (820)
【美輝】制服向上委員会について語ろう60【脱北 (660)
聖母大沢あかねの悩み相談室 (352)
【私には】小林さや【でないもん♪】 (138)
--log55.com------------------
モバイルGoogleマップ part4
【docomo】ローつく総合スレ5【チヂンダ他】
お前等が目覚ましに使ってる着メロ何よ?
【そろそろ】movaにパケ放題を付けろよ!
教えて!vodafoneの無料着うたサイト
【3タソ】絵文字使っても叩かれないスレ【降臨】 Part.2
【au】そしてanmを語るpart4【ATX】
【docomo】iコンシェル 2匹目【ドコモ】