11/06/06 19:25:09.50
>>174
> ファイル名はUnicodeで保存されてるのに
ダウト
176:デフォルトの名無しさん
11/06/06 21:04:50.04
保存されてるだろ。実体がUTF16でもそれを隠蔽して
シフトJISに見せてるWindowsをマクとと一緒にすんな
と思ったけど、ラウンドトリップが完全でないからNEC選定IBM拡張文字を書くと
IBM拡張に化けるのかな
177:デフォルトの名無しさん
11/06/06 21:12:42.72
>>176
> 保存されてるだろ。実体がUTF16でも
ダウト
URLﾘﾝｸ(jp.rubyist.net)
178:デフォルトの名無しさん
11/06/06 21:19:47.11
文字集合を切り替えて使う方式が最も合理的だろ。
179:デフォルトの名無しさん
11/06/06 21:26:00.93
>>177
> >>176
> > 保存されてるだろ。実体がUTF16でも
> ダウト
> URLﾘﾝｸ(jp.rubyist.net)
正確には今もなお UCS-2 らしい。つまり、サロゲートペアの片方のみの場合がある
180:デフォルトの名無しさん
11/06/06 21:58:53.32
>>177
著者成瀬って成瀬ゆいか？ あんなアホ男のことを真に受けるとは。
>UCS-2 らしい。つまり、サロゲートペアの片方のみの場合がある
らしいってソース無しかよ。
しかも「つまり、サロゲートペアの片方」って意味わかんね。さすが池沼成瀬
181:デフォルトの名無しさん
11/06/06 22:03:20.02
結局レッテル貼りかw
182:デフォルトの名無しさん
11/06/06 22:12:52.07
どうせならもっと圧縮率の高いエンコードにしようぜ。
183:デフォルトの名無しさん
11/06/06 23:03:57.57
>>181
レッテルっていうけど、自分で試してみればわかるでしょ。
FILE *f = _tfopen(_T("d:\\tmp\\\xD844\xDE3D.txt"), _T("wb")); // ??: U+2123D
明らかにWindowsはUCS-2じゃないよ
184:デフォルトの名無しさん
11/06/06 23:24:04.52
>>174
>zipアーカイブのファイル名をShift_JISで記録してるため
日本語版WindowsはシフトジスだがShift_JISではないな。Windows-31J
185:デフォルトの名無しさん
11/06/06 23:50:27.43
>>175と>>177のダウトは何なの？
UTF-16かUCS-2かは置いておいて
WindowsがUnicodeなのは疑いようの無い事実だと思うんだけど
186:デフォルトの名無しさん
11/06/06 23:56:38.49
Unicodeと聞いてUnicode規格でなくUTF-16LEを想像したに決まってんだろ。
そっとしておいてやれ
187:デフォルトの名無しさん
11/06/07 00:26:01.87
_T の意味を理解してない奴まだいたんだ。
188:デフォルトの名無しさん
11/06/07 00:44:02.43
どうしてunicode=UTF-16LEなのは何で？
189:デフォルトの名無しさん
11/06/07 01:19:45.40
Windowsの場合、MBCSに対してのunicodeだよ。
MBCSが文字コードを指定してるわけじゃないのと同じで、
Unicodeも実際のコードを特に名指ししてるわけじゃない。
そこはまた別問題な。
MBCS ←→ unicode
ANSI ←→ wide character
この関係な
190:デフォルトの名無しさん
11/06/07 01:23:52.96
UnicodeとUTF-16の違いは？
191:デフォルトの名無しさん
11/06/07 01:35:45.36
可逆な圧縮形式と考えたらいい。
実データ……Unicode
圧縮形式……UTF-8 UTF-16等
生waveを圧縮するのにMP3とかWMAとか色々あるだろ。
まあ、これは不可逆だけど。
192:デフォルトの名無しさん
11/06/07 02:17:46.91
>>174
FAT32のファイルを扱う時に必要。
193:デフォルトの名無しさん
11/06/19 05:08:50.30
>>189
>Windowsの場合、MBCSに対してのunicodeだよ
どうしてそんな嘘付くかなあ。
メモ帳の保存オプション見れば「Unicode」「Unicode big endian」「UTF-8」
が選択できるでしょ。明らかにMS用語のUnicodeはUTF-16のLE(BOM付き)
194:デフォルトの名無しさん
11/06/19 22:59:22.95
最初の頃ははBOM付きUCS-2だったんじゃない?
195:デフォルトの名無しさん
11/06/19 23:52:11.55
話が噛み合ってないぞ。
>>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 01:01:12.89
昔はUCS-2がエンコーディングでもあった時代があった。> Unicodeコンソーシアム
197:デフォルトの名無しさん
11/06/21 02:43:05.15
Unicode 3.0かな。
ISO 10646ってひょっとしてUCS-2が前提で
U+10000以上をUTF-16で扱えなかったりするの？
198:デフォルトの名無しさん
11/06/21 11:47:38.99
UCS-2が前提なのは、DIS 10646 1.0の頃のUnicodeコンソーシアム。
だからUnicodersがDIS 10646 1.0を廃案にした。
その頃Unicodeコンソーシアムは16bitで全て賄うつもりだったから。
結局ダメでサロゲートペア→UCS-4という流れ。
UTF-16はずっと後。
199:デフォルトの名無しさん
11/06/22 01:31:59.98
Unicodeが昔16ビット前提だったのは確かだけど、
UCS-2/UCS-4はISOの概念でUnicodeとは直接関係なくね？
200:デフォルトの名無しさん
11/06/23 11:36:55.26
ISO/IEC 10646-1:1993 UCS-2
と
The Unicode Starndard, Version 1.1
は同じ。そのための1.1。
UTF-8, UTF-16は2から。
201:デフォルトの名無しさん
11/06/25 20:56:52.95
すいません、
「あんたねぇ、UnicodeとUTF-8の違いが分かってるの？」
を英語に翻訳していただけますか？
バカなアメ公がクソなコードをアップロードしてしまうんで困ってます。
202:デフォルトの名無しさん
11/06/25 23:06:12.21
You seems you don't understand difference between Unicode and UTF-8 at all, fucking guy!
適当に翻訳サイトで訳した
203:デフォルトの名無しさん
11/06/25 23:19:37.00
youなのにseems？
204:デフォルトの名無しさん
11/06/25 23:55:11.65
つか丁寧な出だしなのに最後がfuckingで面白い
遠回りな表現しないで確実にUTF-8の文字コードでアップしろでいいじゃん
二つの違いを教えたいわけじゃない
205:デフォルトの名無しさん
11/06/26 00:35:52.32
書きだし you seems はいらんな
Why don't you understand the difference between Unicode and UTF-8 ?
206:デフォルトの名無しさん
11/06/26 00:50:25.50
>>196 嘘つくな
「UCS」は符号化文字集合。「UCS-2」はエンコーディング。
ちゃんとISO/IEC 10646読め。
>>201
TOEIC 330点の俺が訳すと
Please seive file as UTF-8 encoding, not as Unicorde.
207:デフォルトの名無しさん
11/06/26 02:01:46.16
UnicodeとUTF-8の違いがわかっていない発言の例だな >>201
208:デフォルトの名無しさん
11/06/27 13:35:43.31
確かにそのようにも取れるが
易に断罪してしまうのは間違いだと思う。
209:デフォルトの名無しさん
11/06/27 19:45:43.18
「文字コードとシフトジスの違いがわかってんのか？ 糞な文字コードでうｐするな」
って言っているようなもの。あきらかな理解不足
210:デフォルトの名無しさん
11/06/27 20:54:21.02
Unicode規格って、文字集合とエンコーディングひっくるめた規格だっけ？
なんかそこらへん曖昧になる。>>19はあってるのか？
211:デフォルトの名無しさん
11/06/27 23:23:17.83
>>210
>Unicode規格って、文字集合とエンコーディングひっくるめた規格だっけ？
その通り。
エンコーディングに関する仕様: URLﾘﾝｸ(www.unicode.org)
文字集合の定義:URLﾘﾝｸ(www.unicode.org)
>>>19はあってるのか？
違う。Unicodeは規格であって、文字集合の名前じゃない
212:デフォルトの名無しさん
11/06/27 23:53:43.78
文字集合を指すときは、なんて言えばいいんだ? Unicode表?
UCS-2とかUCS-4はどっちだっけ
213:デフォルトの名無しさん
11/06/28 00:09:11.90
UCSが何の略かを思い出せ
214:デフォルトの名無しさん
11/06/28 00:09:51.48
UCS-4はISOのエンコーディングの名前。
UCSはISOの文字集合の名前。
Unicodeの文字集合に名前はない。
215:デフォルトの名無しさん
11/06/28 00:12:21.43
>>213
Universalだろ。Unicodeとは関係なし
216:デフォルトの名無しさん
11/06/28 00:21:52.80
CSはどこいっちゃったんだよ
217:デフォルトの名無しさん
11/06/28 00:34:05.00
UCSはUniversal Coded Character Setの略。
Cが一個どこに行っちゃったのか不明。
Unicodeの文字集合は「Unicodeの文字集合」でいいんじゃない？
218:デフォルトの名無しさん
11/06/28 10:29:58.08
201です。
まず訂正。
×バカなアメ公
○バカなイタ公
クソコードを投稿（正確にはsvnリポジトリーにコミット）してたのは、イタリア人でした。
でもコードを管理してるコミュニティの親分はアメリカ人で、そいつのチェックでＯＫが出た上で投稿されたんです。
コードというのは、javaで書かれたプログラムコードのことで、テキストのエンコードのことではありません。
話が長くなるのでアレですが・・・
javaでは内部的に文字列をユニコードで処理しています。１文字は16ビットです。
Windowsも皆さんご存知の通り、内部的に文字列をユニコードで処理しています。１文字16ビットです。
Win32APIの末尾に w が付くやつがそうですね。
つまり、javaで何も考えずにフツーにプログラミングすれば、アメ公が作ってもイタ公が作っても
自動的に日本語対応になるんです。
あとは画面に表示されるメッセージを言語別に作成して、利用者の言語にあわせて切り替える仕組み
にしてやれば、マルチリンガルなアプリケーションの一丁あがり！ってワケです。
javaにはもともと、そういう仕組みが用意されてるので簡単です。
ところが、件のバカなイタ公は、文字列を一旦 UTF-8 にエンコードしてから表示しようとするんです。
もちろん文字化けします。バカなイタ公はなぜ文字化けするのか理解できないので
今度はそのUTF-8エンコードされた文字を、javaからWin32APIのWriteConsoleWに渡そうとします。
もちろん文字化けします。バカなイタ公はなぜ文字化けするのか理解できないので
今度はコンソールのコードページを無理やりUTF-8に変更するAPIを使いドツボにハマっています。
何もしなくていい、ただ System.out.println()関数でフツーに表示すればいい、ってのが理解できんのです。
アプリケーションをユニコード対応して国際化したい一心で一生懸命がんばってくれてるキモチはアリガタイwのですがw
ユニコードとUTF-8の違いが理解できてないため、まったくトンチンカンなプログラムコードを書いて投稿します。
このイタ公を何とかして退治したいです。イタ公の愚行をやめさせるナイスな文章を教えてください。
コミュニティは英語以外禁止なので英語で構いません。
219:デフォルトの名無しさん
11/06/28 10:46:16.97
おまへは先ず日本語を勉強汁
220:デフォルトの名無しさん
11/06/28 10:46:39.02
>>211
> エンコーディングに関する仕様: URLﾘﾝｸ(www.unicode.org)
ここで文字集合も定義しているが?
221:デフォルトの名無しさん
11/06/28 20:25:40.31
>>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 11:02:32.90
>>218
中学生の妹のことで困っています。
ここ最近、妹は風呂上りに毎回僕の部屋にやってきます。
脱衣所でしっかり体を拭いていないせいか、濡れたタンクトップに乳首が透けて浮き出ています。
視線を逸らしながら注意すると「やっぱ妹のでも気になるんだ？」
と俺をからかいはじめる始末です。
こんな調子で二三時間も居つかれては堪ったもんじゃありません。
この高見盛そっくりの妹を退治するにはどうしたらいいのでしょうか。
223:デフォルトの名無しさん
11/06/29 11:03:28.46
UnicodeとUTF-8の違いわかってない土方大杉
224:デフォルトの名無しさん
11/06/29 14:56:27.20
>>218 四行目で読むのやめた
>>222 三行目まで読んだ
225:デフォルトの名無しさん
11/06/29 16:20:10.45
>>221
TOUICってのは何万点満点なんだい？
226:デフォルトの名無しさん
11/06/29 22:41:25.18
>>222
漏れにくれ
227:デフォルトの名無しさん
11/06/30 08:19:39.53
>>223
このスレは３スレ目なのに、酷いものだ
228:221
11/06/30 08:27:39.19
>>225
ん？よくしらないけど1000点じゃね。
そのくらい自分で調べな
229:デフォルトの名無しさん
11/06/30 12:00:51.80
>>228
そもそもTOUICってなんの試験？
馬鹿レベルを計るもの？恥レベル？
230: 忍法帖【Lv=14,xxxPT】
11/06/30 13:58:51.40
>>229
Test Of Unwise International Computation.
231:デフォルトの名無しさん
11/07/01 13:39:03.71
なんか長文あったから読んでみたけどいらない情報多すぎだし、このスレに来る人なら知ってることをダラダラ書いてるし途中でやめた
232:デフォルトの名無しさん
11/07/03 03:52:20.12
Windowsでサロゲートペアのファイル名がZIP圧縮出来ないんだけど、なんとかならんの？
今時シフトJISしか扱えないなんて糞過ぎる。
スマホ上で作ったUTF-8ファイル名のZIP持ってくると文字化けしまくる。
ファイル名にBOM付けてもいいからマジ何とかしてほしい
233:デフォルトの名無しさん
11/07/03 05:03:45.92
コントロールパネル
→個人設定
→システムロケールの変更
→再起動
234:デフォルトの名無しさん
11/07/03 05:33:52.76
ZIPそのものが古代の遺物。7-Zipにすればよろしい。
235:デフォルトの名無しさん
11/07/03 14:42:31.19
>>232
お前が使ってる糞解凍ツールを見直すべきかと
236:デフォルトの名無しさん
11/07/09 13:45:03.50
Unicodeの文字に言語情報ってある？ 日本語かどうか判断したいんだけど。
JIS2004は日本語と判断したい
237:デフォルトの名無しさん
11/07/10 04:31:44.19
>>236
そんなものは無いし、JIS2004をそのまま含んでいる訳ではないので不可能。
JIS2004に追加された文字でUNICODEに無かった分をUNICODE3.1や3.2でUNICODEに追加した分というのなら調べればわかる。
238:デフォルトの名無しさん
11/07/10 17:04:21.42
極端な話アルファベットで日本語の文章を書くことも出来るわけで、
言語とスクリプトは別というのはわりと基礎知識。
239:デフォルトの名無しさん
11/07/10 19:43:44.83
そんな極論聞いてるわけじゃないんだよねえ
240:デフォルトの名無しさん
11/07/10 20:40:34.17
極論じゃないでしょ。
>>236の言う「日本語かどうか」がどういう意味かによって、
やり方が全然変わってくるんだから。
JISで登録されてる文字集合に含まれてるかどうかでいいってのなら、
テーブル見れば済む。
けどそんなこと質問するかね。
241:デフォルトの名無しさん
11/07/10 21:22:02.68
>>240
Unicodeの文字集合はUnifiedだから、一つの文字が複数の言語に
対応するのは>>236もわかってるでしょ。>>236は
「A」: 英語,日本語
「百」: 日本語,中国語
「あ」: 日本語
みたいなテーブルが欲しかったんでしょ。そんなものは無い。
>>240
>テーブル見れば済む
どこかに正式なものが公開されてる？
無保証でいいなら URLﾘﾝｸ(x0213.org) とかあるけど
242:デフォルトの名無しさん
11/07/11 13:36:38.84
>>218
超一般論として、説明してもわからない
我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ
エラーが出るテストを作ってそれをつき突けろ
最終的にはそれしかない
「よくわからんがこのテストが通ってるんだからあちらでも問題はないんだろう」というものを作ってさしあげろ
243:デフォルトの名無しさん
11/07/11 19:57:07.03
一塊の文章としてなら、IMultiLanguageで文字コードを推定することはできるはずだぜ？
244:デフォルトの名無しさん
11/07/12 08:47:17.73
>>242
>我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ
ぶっちゃけこの業界はコミュ障が多いから
そこまで他人の立場に立って理解出来る香具師は少ない
245:デフォルトの名無しさん
11/07/12 16:41:00.55
つーか、駄目なコードの例と正しいコードの例を提示すればいいだけなんじゃねーの？
246:デフォルトの名無しさん
11/07/14 00:29:31.56
流れを断ち切って申し訳ないが、
UTF-8がバイトオーダーの影響を受けてLE,BEに分かれないのはどうして？
いや、UTF-16だけが特殊なのか？
CPUがメモリ上の複数バイトを読み書きする際の配置の都合からLE,BEがあるのなら、
UTF-8だってASCII文字以外は複数バイトでしょ？
247: 忍法帖【Lv=24,xxxPT】
11/07/14 00:58:37.24
UTF-8は1バイトずつ読み書きする。
248:デフォルトの名無しさん
11/07/14 01:17:06.25
>>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 07:28:59.02
MIME64と一緒か
250:デフォルトの名無しさん
11/07/14 08:26:50.94
>>246
UTF-8はエンコーディングフォームが1オクテット単位だから、
UTF-8エンコーディングスキームはバイトオーダーに依存しない。
UTF-16とUTF-32エンコーディングフォームが2/4オクテット単位だから、
エンコーディングスキームが複数必要となった。
251:デフォルトの名無しさん
11/07/14 19:26:49.50
LEとかBEとか分けないで、どちらかに統一すればいいのに。
252:デフォルトの名無しさん
11/07/14 20:23:18.94
できなかったからこうなってるんだろ
253:デフォルトの名無しさん
11/07/14 21:58:52.88
UTF-16/32は内部表現として採用されることが多い。
だからバイトオーダーの問題が出てくる。
UTF-8はそんまんま垂れ流すのでなければ、
内部表現としてのUTF-16/32と併用されることが多く、
その場合decodeがいずれにせよ必要となるので、
バイトオーダーと逆順になっていても大した手間じゃない。
254:デフォルトの名無しさん
11/07/14 22:48:24.40
LEとBEは、規格上で相互運用とかをあんまり考えなかった結果…ではある
どっちかに我慢してもらって無理してでもどっちかに決めてしまえばよかった
本当はね
LEでもBEでもどちらでももちろん構わないというのは、うんざりするほど正当で当たり前だが、うんざりだ
255:246
11/07/15 07:20:47.59
レス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: 忍法帖【Lv=25,xxxPT】
11/07/15 07:47:31.64
画像に擬える辺り、根本から判ってない悪寒。
257:デフォルトの名無しさん
11/07/15 07:59:23.90
低レベルの挙動を考えたら、LEとBEは両方必要だろと普通に思うがな
258:デフォルトの名無しさん
11/07/15 08:02:47.23
ネットワークバイトオーダーっつうもんがあるように、
交換形式はどっちかにしちまえよ、って思ったことはある。
259:デフォルトの名無しさん
11/07/15 08:59:25.19
>>258
それは実質UTF-8だな
UTF16/32のままネットワークを流れることはあまりない
260:デフォルトの名無しさん
11/07/15 14:23:43.37
>>258
大量のテキストを処理したい時に、
内部表現と同じテキスト形式が存在しないのは不便。
実行環境の内部形式に依存しても、軽快に扱いたい局面はある。
たとえばテキストデータベースの二次記憶保存など。
ネットワークバイトオーダーについては、
TCP/IPのヘッダー部はデータ量が少ないし、
最近はハードウェア評価だからオーバーヘッドにはならない。
それにデータ交換についてはプロトコル毎に決めればいい。
261:デフォルトの名無しさん
11/07/15 21:33:02.35
>>255
>しかし内部形式って意識されるべきですか？
意識する必要は無いし、UTF-16フォームにLEとBEの区別は無い。
ただし外部形式であるUTF-16スキームにはLEとBE区別が当然ある。
262:デフォルトの名無しさん
11/07/15 23:55:08.88
>>255
せめてPNGにしとけ。それなら話が通じる
263:デフォルトの名無しさん
11/07/16 11:30:38.92
ヒント：
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 11:37:43.86
ドヤ顔でそんな事言われても
265:デフォルトの名無しさん
11/07/16 12:16:52.83
しかしエンコーディングをUnicodeって言うのはやめてほしい
昔はそうだったのかもしれないけど、気持ち悪くて
266:デフォルトの名無しさん
11/07/16 12:37:51.74
UCS-2ですよ。Unicodeって言われた時代はありません。
267:デフォルトの名無しさん
11/07/16 20:26:19.26
>>263
> 文字一覧
文字セットの方が好き
268:デフォルトの名無しさん
11/07/17 16:28:44.12
マクのSJIS-Unicode変換ルールを知りたいのですが、
どこかに公開されていないでしょうか。
特にNEC特殊文字やIBM拡張文字(「①」(U+2460)など)がどうなるか知りたいです。
269:デフォルトの名無しさん
11/07/17 16:53:25.93
どうもならんよ
270:デフォルトの名無しさん
11/07/17 17:13:37.77
数多いShift_JISベンダー拡張の「MacJapanese」からのなら
URLﾘﾝｸ(unicode.org)
にあるけど、今もこの変換通りなのか不明。
Microsoft拡張のCP932との関係も少しだけコメントが書いてある。
271:デフォルトの名無しさん
11/07/17 17:14:29.89
どうにもならない、というのは、
U+2460をシフトジスに変換すると24 60の2バイトになるということかな？
272:デフォルトの名無しさん
11/07/17 17:15:05.68
これを挙げ忘れた。
URLﾘﾝｸ(unicode.org)
273:デフォルトの名無しさん
11/07/17 19:22:02.19
>>270
>今もこの変換通りなのか不明
今も昔もこのルールか実装されたためしなんて無い。
|0x5C 0x00A5 # YEN SIGN
274:デフォルトの名無しさん
11/07/17 20:23:16.02
>>273
Character ViewerからShift-JIS(X0208)指定して005Cダブルクリックで入力すると
アプリ側にはU+00A5が渡るけど
CoreFoundationで変換してもU+00A5になる。
275:デフォルトの名無しさん
11/07/17 21:07:44.60
>>268
MacはもうShift_JISは使ってないよ。
UnicodeとShift_JISの変換は当然できるけど、動作はAPIに対するパラメータ次第。
例えばU+2460に対しては古いMacJapaneseを指示すれば0x8540が返るし、X0208を
指示すると変換できずエラー、X0213を指示すると0x8740が返る。
端的に言うとパラメータで指示した規格に沿った値に変換される。
276:デフォルトの名無しさん
11/07/17 22:33:23.51
シフトJISを規定の文字コードとするアプリケーションは、Mac OS Xには無いそうです。
JDK 6とかな。
277:デフォルトの名無しさん
11/07/17 23:13:50.55
Shift_JISX0213のエンコーディングを実装してるなんて、マッコステンて無駄にすげーな。
シフトジスの84 BF(丸付き21)をUTF-16に変換すると27D0になったり、
シフトジスのFCA3をUTF-16に変換するとD867 DFCEになっちゃうわけ
278:デフォルトの名無しさん
11/07/18 21:57:13.75
Windowsも正確には MS932(CP932やWIN31Jとも言うが)なんだけどな
279:デフォルトの名無しさん
11/07/18 23:46:46.27
そんな偉そうにIANAに登録されていない名前を列挙されても
280:デフォルトの名無しさん
11/07/19 01:26:36.91
ドヤ顔でズレたこと言ってるのはお前じゃねーの
>>278はshift_jsと違うってことが言いたいんだろ
281:デフォルトの名無しさん
11/07/19 02:20:03.27
まぁ、ちゃんとした名前で言っておけばつっこまれなかったかもしれんぞ。
Windows-31J な。
URLﾘﾝｸ(www.iana.org)
282:デフォルトの名無しさん
11/07/19 03:23:11.11
WIN31J「とは言わない」からな
その時点でいろいろ知れる
283:デフォルトの名無しさん
11/07/19 06:06:29.06
>>280
node.jsの親戚かと。
284:デフォルトの名無しさん
11/07/19 10:14:52.68
>>278
MS932とはあまり言わないだろう、Microsoftの「Code Page 932」って規格だから略称としては「CP932」が適切
285:デフォルトの名無しさん
11/07/19 10:39:36.67
>>284
MS932はJava語で、おおむね、Windows-31Jを指すはず（IBM版CP932とは違う）
Javaが独自分類表現を使用しているなんて夢にも思わない人がJavaの外に持ち出して恥をかくことがある
286:デフォルトの名無しさん
11/07/19 11:26:26.69
よくこんな細かいことで争えるなあ・ω・
287:デフォルトの名無しさん
11/07/19 11:39:43.38
別に細かくはない
ギョウザを頼んだらシュウマイが出てきた、くらいには違う
288:デフォルトの名無しさん
11/07/19 11:44:54.65
Wikipediaが正しいかわからないけど、色々な経緯が載ってる
URLﾘﾝｸ(ja.wikipedia.org)
289:デフォルトの名無しさん
11/07/19 14:43:58.56
CP932はLLのコード指定なんかでも良く使われる名前だし、突っ込むほどでもないと思うがな
290:デフォルトの名無しさん
11/07/19 15:44:26.12
>>289
CP932は問題になってはいない
っていうかお前>>278だろ
291:デフォルトの名無しさん
11/07/19 23:27:12.20
Windows-31J はJavaのJSPだっけ？でしか
聞いたことがない。
292:デフォルトの名無しさん
11/07/21 23:17:57.44
日本語版Windowsのメモ帳の文字コードがWindows-31Jなのは
間違いないし、Shift_JISでないのも確かだが、
「シフトジスではない」と言われるとそれは違うだろう。
どう考えてもWindows-31Jはシフトジス。
293:デフォルトの名無しさん
11/07/21 23:33:26.32
>>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 23:55:46.23
文中では「Shift JIS」で、
wikipedia項目に飛ぶと「Shift_JIS」になってるな。無茶だなw
Windows-31Jは、初期の「Shift JIS」からは文字が足されて拡張されているけど、
その飛び先が「Shift_JIS」ではな。
「Shift_JIS」の項目内で「Shift JIS」と「Shift_JIS」の使い分けが甘い。
295:デフォルトの名無しさん
11/07/22 02:15:49.92
>>294
Wikipedia のリンク名には制約があって、「_」と「 」が区別できない。
296:デフォルトの名無しさん
11/07/22 02:17:52.27
リンク名というか記事名だな
他にも記事名に使えない記号ってあるのよね
297:デフォルトの名無しさん
11/07/23 09:13:21.14
Wikipedia のタイトルの制約には昔から悩まされてる。
1. アンダースコアが空白になる
2. ふたつ以上の空白がひとつにまとめられる
3. 先頭と最後の空白が除去される
4. [ ] { } < > | # が使えない
5. : が特殊な意味を持つことがあり、たとえば「:」からはじまるタイトルが作れない
6. 先頭の1文字が大文字になる
7. 長さ制限(UTF-8 で 255バイト以内)がある
リンクするときにはさらに複雑な制約がかかる。
298:デフォルトの名無しさん
11/07/23 10:12:07.29
文字コードの話じゃないけど、入力文字に複雑な制限があるのは
エスケープ前と後の区別がつけられないできの悪いエンジニアが
作ったんだろうな。そういう人たちがSQLインジェクションとか起こす。
299:デフォルトの名無しさん
11/07/23 10:46:25.58
記事名がURLになる、というのは便利なんだがそういう弊害もあるよな。
逆にハッシュ値のような長いURLは不便だし、シリアルナンバーも微妙。
MediaWikiって内部的に持ってる記事名も空白が _ になってたりして、
そのへんの設計も微妙だな。
300:デフォルトの名無しさん
11/07/23 12:35:06.53
スレ違い
301:デフォルトの名無しさん
11/07/23 13:06:04.48
Not スレ違い
URLﾘﾝｸ(ja.wikipedia.org)神
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(ja.wikipedia.org)
302:デフォルトの名無しさん
11/07/23 17:00:46.82
記事名の問題だけじゃなくShift JISの記事は内容がおかしいな。
303:デフォルトの名無しさん
11/07/23 19:16:54.74
そういう時は君が修正すれば良い。
誰でも修正できるのだから、それをせずに
間違っていると言ったところで信用されない。
言う前に直してから、直したよと報告すればいい。
304:デフォルトの名無しさん
11/07/23 19:50:47.55
>そういう時は君が修正すれば良い。
これはそうなんだが
>誰でも修正できるのだから、それをせずに
>間違っていると言ったところで信用されない。
こういうことを言う奴って頭おかしいんじゃないかと思う。
ただ間違ってるものを見たときに間違ってると言ってはいけないだろうか。
305:デフォルトの名無しさん
11/07/23 21:02:27.38
好きにすればいいんじゃねーの？
俺は>>304みたいのを見ると頭おかしい人なんだなと思うけど
言いたいこと言うのはいいことだと思うようん
306:デフォルトの名無しさん
11/07/23 21:12:44.57
>>304
お前は間違っている。
間違っているものを見たので
つい言ってしまったｗ
307:デフォルトの名無しさん
11/07/23 21:28:03.23
A: ○△に～って書いてあったよ
B: それ間違ってるね
A: 間違ってるって言う前に○△を修正しなよ
B: ハァ？ 何で俺が○△とかいうのを直さなきゃいけないの
>>304はともかく、>>303が変なのは確定的に明らか
308:デフォルトの名無しさん
11/07/23 21:32:53.91
A: ○△に～って書いてあったよ
B: それ間違ってるね
A: 間違ってるって言う前に○△を修正しなよ
B: ハァ？ 何で俺が○△とかいうのを直さなきゃいけないの
A: ○△は誰でも修正できるものだから。
309:デフォルトの名無しさん
11/07/23 21:41:10.14
「誰でも修正できる」がなんで「見つけた人は修正する義務がある」にすり替わるよ。
頭だいじょうぶ？
310:デフォルトの名無しさん
11/07/23 21:44:07.47
誰が義務があるって言ったんだ？
311:デフォルトの名無しさん
11/07/23 22:19:21.22
おまえら楽しそうだな。
312:デフォルトの名無しさん
11/07/23 22:44:52.69
仲良くしてね
313:デフォルトの名無しさん
11/07/23 23:11:11.98
とりあえずシフトジスって書かれたときは99%はWindows-31Jのことだから、
Windows-31Jって書いておけば問題ない。
314:デフォルトの名無しさん
11/07/24 10:08:13.04
Windows-31JはJava用語で一般的ではないから
他では通じない。CP932と言ったほうがいい。
315:デフォルトの名無しさん
11/07/24 10:26:45.92
>>314
2点
レス欲しいなら狂人の真似を
316:デフォルトの名無しさん
11/07/24 11:58:46.32
いや事実を言っただけなんだが。
317:デフォルトの名無しさん
11/07/24 12:50:28.09
「Windows-31J」はIANAに登録された一般的な名前で、Java固有ではない。
HTTPのContent-Typeにも(条件付きではあるが)正式に使用できる名前。
なお.NET FrameworkのEncoding.GetEncodingは、文字コード名をパラメーターに
取るのではなくWindowsコードページ名を受け取るので、Windows-31Jは指定できない。
318:デフォルトの名無しさん
11/07/24 17:21:27.70
>>317
GetEncodingは.NETのウニコード文字をローカルに
変換するルールでしょ
IANAが決めているのは文字コードであって、
ユニコードとの変換ルールでないんだから当然
319:デフォルトの名無しさん
11/07/24 20:34:52.28
>>315
861 ：デフォルトの名無しさん：2011/01/04(火) 20:39:59
SJISはウンコ、CP932はウンチ
320:デフォルトの名無しさん
11/07/25 11:13:51.23
IANAのcharset名、Windows関連は
"Windows-コードページ番号"で統一できたらよかったのにな。
321:デフォルトの名無しさん
11/07/25 15:50:16.53
Wikipediaなんて間違いだらけなのは、まともな技術屋ならしょっちゅう見て理解してるだろ…
内輪ルールがめんどくさすぎて修正しねーことも多いわ
一応、楽に修正できそうな範囲ならするけどな
322:デフォルトの名無しさん
11/07/25 18:40:44.97
間違いっていうか意図的な捏造もかなりあるぞ
特に反日歴史関連は酷い
323:デフォルトの名無しさん
11/07/25 18:53:37.20
ウヨ脳乙
324:デフォルトの名無しさん
11/07/25 22:23:54.09
えっ
325:デフォルトの名無しさん
11/07/26 18:33:59.96
要するに>>278の言いたい「正確」ってのが何だったのかが分からんということだな
326:278
11/07/27 01:27:57.83
拡張漢字（NEC選定IBM拡張・IBM選定IBM拡張・NEC特殊文字）を含む場合は
MS932かCP932あるいはWindows-31J
が正しい
Shift_JISに拡張文字は無い
なので、
「MS932かCP932あるいはWindows-31J」＞「Shift_JIS」
なのだろう
それが正確
327:デフォルトの名無しさん
11/07/27 08:04:57.93
正式名称と通称は区別してよ。
シフトジス
├Windows-31J(X 0201,X 0208,NE特殊,NEC選定IBM拡張,IBM拡張)→通称MS932,CP932
└Shift_JIS(X 0201,X 0208)
328:デフォルトの名無しさん
11/07/27 10:09:52.09
文字エンコーディング・文字コードは技術ではなく（おそらくは残念なことに）ただの政治なので、
ちょろっと読んだ人がしたり顔できるほど相関関係は単純ではない
329:デフォルトの名無しさん
11/07/27 11:56:11.29
CP932はMicrosoft的には正式名称でしょ。
330:デフォルトの名無しさん
11/07/27 20:47:15.11
>>329
コードページの932番というのは正式な番号だけど、
「CP932」という名前はちょっと違うんじゃね
331:デフォルトの名無しさん
11/07/27 23:11:17.71
microsoft.comの公式文書でcp932と表現してる所がある。
332:デフォルトの名無しさん
11/07/28 04:13:07.78
cp65001
333:デフォルトの名無しさん
11/07/28 13:21:19.41
IANAだけ正式だと思ってるのは勘違いだわな
334:デフォルトの名無しさん
11/07/28 22:52:57.57
ソースが出てこないから突っ込まれるんだよ。
MSの文書で文字コード名cp932が定義されているソース出してみろや。
コードページの932番じゃなくて「cp932」な
335:デフォルトの名無しさん
11/07/28 23:41:20.22
後付けくさい理由で絡んでるようにしか見えないが
336:デフォルトの名無しさん
11/07/28 23:41:29.23
ぐぐれ
URLﾘﾝｸ(social.msdn.microsoft.com)
337:デフォルトの名無しさん
11/07/28 23:48:40.52
socialはちょっと…
msdn本家ページにもあるよ。
338:デフォルトの名無しさん
11/07/29 16:00:03.50
今度は「使っているというだけでは正式な定義ではない」とか絡んでくるんじゃねーの
ぶっちゃけ心底どうでもいいんだが
339:デフォルトの名無しさん
11/07/29 23:51:06.97
仕様がどうでもいいとかいうやつは、
プログラマーやめたほうがいいんじゃねーの
340:デフォルトの名無しさん
11/07/29 23:59:57.74
プログラマにとっての仕様なんて、
「コメントを求む」程度の文章でいいんだよ。
341:デフォルトの名無しさん
11/07/30 02:47:52.95
自ら勉強する気が無いならやめてしまえ
342:デフォルトの名無しさん
11/07/30 10:43:39.89
自ら勉強する気はあるが、
会社のためにしかならないことを
勉強する気にはならない。
343:デフォルトの名無しさん
11/07/30 14:40:35.21
向上心が無いのは仕方ないが、仕様が守れない奴は会社やめれ
例えば Content-Type=text/htm; charset=Shift_JIS
で、丸付き数字とか送られてきた日にはブチ切れですよ。
僕のパソコンの僕のブラウザでは表示できましたとか言い出すと殺意を覚える
344:デフォルトの名無しさん
11/07/31 00:31:57.60
text/htmってのひどいな
345:デフォルトの名無しさん
11/07/31 01:37:05.98
typoにマジレス。カコワルイ
346:デフォルトの名無しさん
11/07/31 03:22:17.45
>>343
世の中仕様が全てではないんだよ。
347:デフォルトの名無しさん
11/07/31 03:33:15.68
仕様書に必要なこと全てが書いてあるとは限らんが、
>>343のは仕様で禁止されたことをやってんでしょ。
それはまずい。
348:デフォルトの名無しさん
11/07/31 11:22:19.48
charset=Windows_31J
なら良かったのか
349:デフォルトの名無しさん
11/07/31 13:39:25.25
JavaやってるとContent-Typeと文字コードがリンクしてるから死活問題だな。
鯖と端末双方が「①」を使うと合意した上でWindows-31J使うのが正しいと思う。
350:デフォルトの名無しさん
11/07/31 22:12:23.38
> JavaやってるとContent-Typeと文字コードがリンクしてるから
設計が現実を処理できない仕様になってる。
ダメな設計だ。
351:デフォルトの名無しさん
11/08/01 06:21:06.64
Ruby1.9.3がSJISをWindows-31Jと認識するようになった
352:デフォルトの名無しさん
11/08/01 07:09:08.98
何か問題が？
353:デフォルトの名無しさん
11/08/04 20:55:45.64
世の中で使われているシフトジスの実態を考えれば
SJISをWindows-31Jにすることは妥当だと思うが。
SJISをShift_JISにしたところで安岡センセイ以外喜ばない。
354:デフォルトの名無しさん
11/08/04 21:26:58.69
>>353
> SJISをWindows-31Jにする
> SJISをShift_JISに
どういう意味で言っているのか?
「SJIS」とは何なのだ?
355:デフォルトの名無しさん
11/08/04 22:49:17.03
文字コード名に"SJIS"を指定されたときの動作をどうするかってことじゃねーの
356:デフォルトの名無しさん
11/08/04 22:53:19.60
そんなの好きにしたらいいじゃん。
357:デフォルトの名無しさん
11/08/06 00:15:01.41
もともとこのスレはUnicodeをUTF-16系のエンコーディングと勘違いした
人が立てたんだと思うが、MSだけでなくJavaもUnicode=UTF-16なんだっけ？
358:デフォルトの名無しさん
11/08/06 00:38:20.18
>>354
>>351
359:デフォルトの名無しさん
11/08/07 04:48:33.66
>>357
おＪＡＶＡ様の"Unicode"は
デコード時：ビッグエンディアンUTF-16、BOM許可
エンコード時：ビッグエンディアンUTF-16、BOMあり
Windowsの"Unicode"は
デコード時：リトルエンディアンUTF-16、BOM許可
エンコード時：リトルエンディアンUTF-16、BOMあり
360:デフォルトの名無しさん
11/08/07 14:43:57.06
>>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 14:47:36.25
BOMって文字コードの一部なのか？
たとえば、「あいうえおかきくけこ」という文字列を
split関数で2つに分けたとき、「(BOM)あいうえお」「(BOM)かきくけこ」になるのか？
違うだろう？
BOMはマックバイナリみたいなもので
文字の一部ではなくファイル形式の一種だと思うんだが。
362:デフォルトの名無しさん
11/08/07 14:55:48.67
BOMはデータストリームの一部で、
データストリームの先頭にあるとシグネチャと看做されます。
363:デフォルトの名無しさん
11/08/07 15:02:40.62
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 15:29:54.27
はっきりとin the unicode data streamと書いてる。
URLﾘﾝｸ(unicode.org)
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 16:33:38.94
仕様でないものを仕様と勘違いする奴とか、常に正しい仕様が存在してくれていると思ってる奴とか、
プログラマやめた方がいいんじゃねーの
366:デフォルトの名無しさん
11/08/07 23:35:37.51
文盲がいるな。
>はっきりとin the unicode data streamと書いてる
一つ前のレスも読めないのか
367:デフォルトの名無しさん
11/08/07 23:49:21.22
unicode data streamってのが
何かよくわからないけど、
わざわざ書いてるってことは、
特別扱い、つまり通常の文字とは別扱いなんだな。
368:デフォルトの名無しさん
11/08/07 23:52:20.46
プログラム言語で扱う文字型はencoding schemeでなくencoding formの単位なので
BOMになり得ない。
encoding scheme: バイトデータ表現。BOMが付くことがある
encoding form:「文字」単位の表現。BOMの概念無し。splitで扱うのはこっち
char型(UTF-16/32文字)のFEFFはZWNBSとみなさなければならない。
それをバイトデータにエンコードして初めてBOMが付く。
369:デフォルトの名無しさん
11/08/07 23:55:16.42
BOMが途中にあったらどうなるの？
切り替わるの？
370:デフォルトの名無しさん
11/08/08 00:01:50.41
文盲がいるな。
バイト配列をwchar_t(C)とかchar(Java)にデコードした時点でBOMは消えなきゃいけないの。
ちなみに途中にあらわれるものはBOMでなくU+FEFF文字として扱わなければならない
371:デフォルトの名無しさん
11/08/08 01:07:46.83
途中で現れるのは後方互換性のために許されてるだけで、
本当は途中に現れちゃ駄目。
372:デフォルトの名無しさん
11/08/08 01:17:08.95
deprecateでも許されてるってことは、書き込むプログラムはともかく
読み込むプログラムは処理しなきゃいけないってこった
373:デフォルトの名無しさん
11/08/13 06:53:27.25
Windows7HP 64bit、MS-IME2010ですが、IMEで変換中の文字コードは何でしょうか？
質問は以下2点で、例えば、EUC-JPのテキストをエディタで編集中とします。
１．MS-IMEで変換中（この時の文字コードは？）
２．変換した文字を確定（変換中の文字コード → EUC-JPの変換は誰がどのタイミングで行っているのでしょうか？）
374:デフォルトの名無しさん
11/08/13 10:46:33.19
>>373
1.ふつうはUTF-16
2.ふつうはテキストエディタの保存時
375:デフォルトの名無しさん
11/08/13 10:57:29.48
>>373
普通はEUC-JPで表現できない文字も入力できて、保存時にエラーが出るよね。
ってことは編集中はEUC-JPじゃないってこった
376:デフォルトの名無しさん
11/08/13 12:10:50.38
>>374-375
なるほど。
㌧
377:デフォルトの名無しさん
11/08/14 01:13:50.65
他スレから来ました。
UNIXのshebangってBOMに対応できないの？
378:デフォルトの名無しさん
11/08/14 01:17:53.45
カーネルがバイナリファイルの先頭で #! の存在をチェックしている
ところで、まずBOMの有無をチェックするように改造すれば可能かも。
379:デフォルトの名無しさん
11/08/14 01:26:25.04
ファイルの先頭にFE FF 00 00を見つけたとき、
・UTF-16BEのU+FEFF, U+0000
・UTF-16のBOM, U+0000
・UTF-32のBOM
のいずれであるかの見分けはつくのでしょうか
380:デフォルトの名無しさん
11/08/14 01:53:40.23
>>379
そのバイトオーダーでは迷う要素がどこにもないのだが…
381:デフォルトの名無しさん
11/08/14 04:44:20.21
先頭がBOMかU+feffかは、
エンコードスキームがutf-16なのかutf-16beなのか
の情報が必要。
つまりエンコードスキーム情報無しに読むことは不可
382:デフォルトの名無しさん
11/08/14 04:45:13.50
>>381
そのバイトオーダーでは迷う要素がどこにもないのだが…
383:デフォルトの名無しさん
11/08/14 04:57:36.54
>>381
ならff fe 00 00ならどうするのよ？
384:デフォルトの名無しさん
11/08/15 00:39:15.78
>>382
FE FF 00 00ってのは例が悪くて>>383の間違いなんだろうけど、
「FE FF」にしたってBOMなのかU+FEFFなのか区別付かないよね？
385:デフォルトの名無しさん
11/08/15 00:50:44.72
Unicodeでは先頭のU+FEFFは常にBOMと解釈すべし、というルールだから、BOMであることに疑問はない。
ただしUTF-16LEによるBOM + U+0000という解釈とUTF-32LEによるBOMという解釈のどちらをとるべきかは
一意に決定する方法がない、という意味で>>383の指摘は正しいものだと思う。
386:デフォルトの名無しさん
11/08/15 01:05:17.86
つ URLﾘﾝｸ(stackoverflow.com)
バイトオーダマークであってエンコーディングを示すものじゃないから諦めろってさ
387:デフォルトの名無しさん
11/08/15 02:30:12.19
>>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 00:42:00.98
先頭の<FE FF>がBOMなのかfeff文字なのか判断できないなんて、
BOM考えた奴、ばかなの？
389:デフォルトの名無しさん
11/08/18 07:30:27.15
Unicode自体が馬鹿の塊なのは欧米人以外なら即分かると思うが
390:デフォルトの名無しさん
11/08/18 22:29:40.94
>>389
どの辺が馬鹿の塊なのか解説よろしく
391:デフォルトの名無しさん
11/08/19 15:06:30.40
香具師らの認識している「表意文字」とはアイコンのことだからなぁ
392:デフォルトの名無しさん
11/08/19 20:08:38.83
だから今は漢字のことを表語文字と呼んだりするね
393:デフォルトの名無しさん
11/08/28 23:49:09.53
>>390
当初16 bitで収まると考えていたことなんか、素人の俺にもすぐに指摘できる。
394:デフォルトの名無しさん
11/08/29 01:00:05.33
>>393
かつてそう考えたミスは事実だが、今はコードポイントが
U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で
対応出来てるだろ。
「Unicode自体が馬鹿の塊」の理由は説明出来ないのかな？
395:デフォルトの名無しさん
11/08/29 01:32:35.26
>>389でも>>393でもないが
正規化すると互換漢字が統一漢字になるところは時々キレそうになる
自分は異体字セレクタでやればいいんだけど、他人に渡す時に対応エディタがないから揉める
あと他人から受け取ったファイルに互換漢字が大量に含まれてたりするともうね・・・
396:デフォルトの名無しさん
11/08/29 01:43:05.53
>>394
無理はあるだろ
16bitとか考えなきゃ、最初っからCJKなんて無謀なこともしないで済んだし、そうすればコード変換の
コストも大幅に軽減されたし、i18n対応のソフトがフォントでつまずくようなことも起きなかったし
他にもさまざまな問題が事前にことごとく指摘されてたのに強行して、結局無理でした、だからな
397:デフォルトの名無しさん
11/08/29 02:27:50.75
>>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 03:31:52.42
＞もう一文字がすべて同じ32bitの世界は絶望的だよ。
いや、それは結合文字ある時点で絶望的だろ、と突っ込んでみる
UTF-16がクソなのは同意だがUTF-8は需要多かったからどの道生まれただろうし
399:デフォルトの名無しさん
11/08/29 08:01:59.08
>>395
自分の処理目的に適した基準でnormalizeすれば良いよ。decompositionだけ無くすとかね。
外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
OSXだと互換漢字は除外してnormalizeするAPIとかも用意されてる。
400:デフォルトの名無しさん
11/08/29 08:11:50.68
ぜんぜんCJK非分離の解決になっていない件
401:デフォルトの名無しさん
11/08/29 11:17:14.00
漢字は本当に、普通に見た目が違う字が出るもんなぁ
402:デフォルトの名無しさん
11/08/29 11:41:22.44
>>399
要件にわざわざ『Unicode正規化(C方式)』と入ってなければ
或いは、送ったファイルが何故か相手側で正規化される、そんな可能性が無視できるなら
Apple独自規格だろうがなんだろうが喜んで使おう
ただ、その場合はそもそも正規化する必要がないんだけど
403:デフォルトの名無しさん
11/08/29 11:55:21.11
>>399
＞外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
必要だからやる→>>395
自分勝手にnormalizeしたところで何の解決にもならん罠
404:デフォルトの名無しさん
11/08/30 22:01:52.91
正規化についても、みんなで仲良く正規化しないと、
いろいろ面倒なんだよなあ。
例えば、外部からきたUSBメモリ上のパス名まで正規化されているかどうかとか。
内部的には正規化してから処理するとしても、
再度書きこむ時に正規化すべきか、それとも元のままにしておくか、
元のままにしておく場合、保存しておかなければならないし。
>>397
> UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。
ちょっとこの列挙の仕方はどうかと。
言わんとしていることは分からないでもないが、
最初から32bitじゃまとまらなかっただろう。
405:デフォルトの名無しさん
11/08/31 10:41:56.92
受け入れられるためには理想の仕様は諦めて妥協しないといけない、
かといって妥協しまくりのダメ仕様でも誰も使わない。
その結果を一見して「迷走」と決めつけることは誰にもできるw
406:デフォルトの名無しさん
11/08/31 11:50:16.72
16bitは必要な妥協だったとは思わんがな
407:デフォルトの名無しさん
11/09/01 14:44:18.72
根拠は？
どうなっていたのと思うの？
408:デフォルトの名無しさん
11/09/01 19:30:44.11
必要な妥協だった、迷走ではない、と開き直るほうが簡単だよね
でも互換漢字の中に統合漢字を適当に混ぜるとか、何も考えてないのは丸わかり
規格作ってるやつらは実装しなくていいんだから楽だよなあ
409:デフォルトの名無しさん
11/09/02 12:27:42.35
必要な妥協なんてものはそもそも無い。
ないものを攻撃している奴は馬鹿。
仕方ない妥協があるだけ。
410:デフォルトの名無しさん
11/09/02 12:47:09.80
仕方も工夫も色々あったけど
馬鹿が都合悪い部分放置でそのままreleaseしたんだろ
なんで「仕方なかった」なんて嘘が通ると思うのか
まだ「必要だった」って言い訳のほうがマシだよ
411:デフォルトの名無しさん
11/09/02 13:14:29.07
>>409
>>408だけど、妥協そのものを攻撃してるんじゃなくて
>>399みたいな開き直りについて言ってるだけだから
必要とか仕方ないとかそのへんの細かいニュアンスは俺の言ってる本筋とは関係ないから
412:デフォルトの名無しさん
11/09/02 13:15:49.10
安価ミスすまん
>>399じゃなくて>>405ね
413:デフォルトの名無しさん
11/09/02 15:51:45.81
経緯をよく知らないけど、中国/日本の当局者に6万語で収まるのかをきちんと聞いたのか？
単に憶測で6万語で収まると判断したのか？
414:デフォルトの名無しさん
11/09/02 18:11:44.98
Unicodeは最初からHan Unificationありき。
Xerox(とApple)でHan Unificationが研究されたから、
Unicodeが誕生のきっかけが出来た。
日本ではEmacsやArenaの多言語化を、
ISO 2022ベースでやっていた頃。
415:デフォルトの名無しさん
11/09/04 05:22:06.88
>>414
最初から、というか、最初だけ。
誕生のきっかけであって、もう今ではとてもじゃないが、機能してるとは言えん
同じ字体が互換漢字・互換漢字両方で表せるのがまずおかしいのに
さらにKS X 1001とかいう規格から、同じ字体で読みだけが違う互換漢字も追加されて
統一漢字＋異体字セレクタで統一漢字でも字体を変更できるようになって
と思ったら異体字セレクタに汎用電子がAdobeと同じ字体を重複登録しはじめて
トドメに、異なった統一漢字同士でも異体字セレクタによっては同じ字体になるんだから……
416:デフォルトの名無しさん
11/09/04 17:42:35.37
>>415
> 機能してるとは言えん
はあ?
417:デフォルトの名無しさん
11/09/04 19:33:51.55
うん、そうだね
418:デフォルトの名無しさん
11/09/05 04:04:33.03
その通りだ
419:デフォルトの名無しさん
11/09/05 22:01:45.96
>>294
アンダースコアの有る無しで意味が違う、っていうことの方が狂気の沙汰だと思う
420:デフォルトの名無しさん
11/09/05 22:32:53.25
狂気はお前だ。
421:デフォルトの名無しさん
11/09/06 01:33:22.31
アンスコあるのと無いのでは全然違うだろ。
422:デフォルトの名無しさん
11/09/06 02:42:07.11
アンダースコートは無い方が良い
423:デフォルトの名無しさん
11/09/10 15:51:03.10
>>413
まずいよこれ無理だよ、ってのは少なくとも日本の機関や企業から結構発信してたはず
424:デフォルトの名無しさん
11/09/10 18:02:22.29
収まらないのはUnicodeが開発される前からわかっていた。
収めるためのHan Unificationが適切かどうかが議論になった。
>>414
> Unicodeは最初からHan Unificationありき。
> Xerox(とApple)でHan Unificationが研究されたから、
> Unicodeが誕生のきっかけが出来た。
425:デフォルトの名無しさん
11/09/10 18:18:33.20
で、不適切だったと
426:デフォルトの名無しさん
11/09/10 23:32:57.71
まだ天安門の頃か
427:デフォルトの名無しさん
11/11/08 00:10:00.22
>>423
それでも説得して変えさせることは出来なかった。
かといって代替を用意して
それを普及させるだけの力もなかった。
ガラパゴス規格を作っては国内オンリーで威張る
だけの親方日の丸体質では最初から無理でした。
せめて今後は上手く捻じ込む交渉術を学んでいただきたいものです。
無理か。無能なJIS関係者や学者に金撒くんじゃなくて
最初から、ロビイストに金を突っ込むのが正しいな。
428:デフォルトの名無しさん
11/11/08 00:46:24.54
今更お金撒いてももう無理なんじゃない？
文字コードには詳しくないんだけど
プログラマのための文字コード入門読む限りでは
今後もシフトJISを使うのが一番安全という気がひしひしとしてくる。
実際、Windowsも内部はUnicodeだけどインタフェースはNLSを通してシフトJISを使うわけだし。
429:デフォルトの名無しさん
11/11/08 00:51:01.90
.Netでもそんな扱いだっけ？
430:デフォルトの名無しさん
11/11/08 01:05:01.98
シフトJISってWindows以外じゃ使わないんだけどなあ…
431:デフォルトの名無しさん
11/11/08 01:09:02.77
シフトJISって恥ずかしいよね
432:デフォルトの名無しさん
11/11/08 01:21:12.38
Windows使いだが、業務用のバッチファイル以外でシフトJISなんか使わねーぞ。
ソースコードもHTMLもデータベースもテキストファイルも全部ウニコードにしてる。
ただメールだけはISO-2022-JPでないと文字化けする糞アプリが存在するので
なかなかUTF-8に移行できない。
433:デフォルトの名無しさん
11/11/08 01:24:56.95
Visual C++がコードページにうにコードをセットできないのがすべての敗因。
コマンドプロンプトも未だにうにコード使えないし、ファイルシステム事態はうにコードを使えても
ファイル名をやり取りするAPIの中にうにコード版が存在しないものが…
WindowsだけシフトJISで。
434:デフォルトの名無しさん
11/11/08 01:32:12.35
>コマンドプロンプトも未だにうにコード使えないし
cp 65001
435:デフォルトの名無しさん
11/11/08 01:39:37.21
>>433
URLﾘﾝｸ(yukarin.wiki.fc2.com)
436:デフォルトの名無しさん
11/11/08 02:07:10.34
よし、コマンドプロンプトのうにコード問題は解決したぞ
あとはVC++がlocaleにうにコードをセットできるようになってくれれば解決だ。
437:デフォルトの名無しさん
11/11/08 02:07:27.82
ほー。
chcp 65001すると今まで動いてた以下のコードが正しく動かないんだがどうすればいい？
_tsetlocale(LC_CTYPE, _T(""));
_tprintf(_T("マンコ\n"));
438:デフォルトの名無しさん
11/11/08 02:56:46.07
windows のシステムロケールを変更して再起動
439:デフォルトの名無しさん
11/11/08 08:53:05.57
mendoxer!
440:デフォルトの名無しさん
11/11/17 03:47:25.53
囗囘囙囚四囜囝回囟因囡团団囤囥囦囧囨囩囪囫囬园囮囯困囱囲図围囵囶囷囸囹固囻囼国图
囿圀圁圂圃圄圅圆圇圈圉圊國圌圍圎圏圐圑園圓圔圕圖圗團圙圚圛圜圝圞
441:デフォルトの名無しさん
11/11/19 21:17:47.39
シフトJISはWindowsだけってことはないと思うぞ。
むしろ自分の周りだとWindows以外のシステムはいろいろあるけど
情報交換はシフトJISでまず問題がない。ユニコードにお目にかかる
ことのほうが滅多にない。
442:デフォルトの名無しさん
11/11/20 04:14:11.87
>>441
> 情報交換はシフトJISでまず問題がない。
老害しねや
443:デフォルトの名無しさん
11/11/20 11:36:54.27
最近は中国人の顧客とかも増えてるからUnicode対応じゃねーと死ぬわ俺んとこは
444:デフォルトの名無しさん
11/11/20 12:29:01.95
異体字セレクタと互換漢字どっち使うにしてもUnicodeは地獄
445:デフォルトの名無しさん
11/11/20 20:58:49.78
互換漢字・意自体セレクタはUnicodeよりシフトジスの方が優れていると？
446:デフォルトの名無しさん
11/11/20 21:12:01.10
中国の客とか、その時点で死だろ
447:デフォルトの名無しさん
11/11/20 21:17:11.83
異体字があっても意味を区別できるヤツなんて
1000人に1も居ないんだから、異体字なんて駆逐してしまえ。
国も時代に合わせろよ。
448:デフォルトの名無しさん
11/11/20 22:39:49.13
全国の渡邊さんと渡邉さんがアップをはじめたようです
449:デフォルトの名無しさん
11/11/21 02:15:21.62
源規格分離のUnicodeに移行すれば、メリットは多数あってもデメリットは無いだろ。
互換漢字とか話をすり替えてユニコード批判するしかないとは。
いつまで20世紀に生きてるんだよ
450:デフォルトの名無しさん
11/11/21 13:52:38.60
>>444だけど、>>441書いたのは俺じゃないからな
当然だけどShift_JISが使えない規格ってのが大前提だが
>>449みたいなやつも程度としては>>441と同レベルだわ
デメリットないとか本気で言ってんならな
そりゃ、ソフトウェアを源規格分離のUnicodeで作るだけなら楽だけど
使うやつはUnicodeのことなんてなにも分かっちゃいないんだぞ
使われてるうちにデータがどういう惨状になるか分かってんのか……
451:デフォルトの名無しさん
11/11/21 15:03:02.41
>>449 は全ての問題が解決した22世紀から来た人なんだろう、多分
452:デフォルトの名無しさん
11/11/23 20:24:22.16
>>449
合成漢字とか、マイナーな漢字で問題が有るっちゃあるらしい。
だから、PDFに複数のエンコーディングを同時に使いたいという需要が
あったりする。
453:デフォルトの名無しさん
11/11/24 08:26:11.02
原規格分離でも、別規格の文字が同じコードポイントという致命的欠点を「前世紀に批判」と誤魔化してみても、
その致命的欠点が前世紀からそのままであるという事実は変わらないけどなw
454:デフォルトの名無しさん
11/11/24 20:20:13.17
>453
それは別に致命的な欠点ではないだろう
統一漢字をせっかくまとめたのに、互換漢字を作ったのが失敗なんだよ
最初から異体字はセレクタでよかった
455:デフォルトの名無しさん
11/11/24 20:50:09.36
使い物にならないままでよかった、とw
456:デフォルトの名無しさん
11/11/24 20:56:22.92
ﾊｧ?
457:デフォルトの名無しさん
11/11/26 11:51:28.97
痛い字セレクたん
458:デフォルトの名無しさん
12/01/09 10:04:59.13
>>457
459:デフォルトの名無しさん
12/01/09 10:20:35.33
れ
460:デフォルトの名無しさん
12/01/15 21:54:45.42
書き込みが少ないようだが、スレタイの疑問には
コンセンサスが得られたってことでいいんだよな
Unicode: UTF-16リトルエンディアンBOMあり
UTF-8: よく使うアレ
461:デフォルトの名無しさん
12/01/16 09:15:50.56
そんなコンセンサスはない。
MSがそう表記したがってるのは事実。
'Unicode'と'UTF-16LE'を同一視するような言い方をすれば
頭の弱いかわいそうな人と見なされる。
少なくともそいつと技術の話はできない。
462:デフォルトの名無しさん
12/01/16 14:23:26.17
JavaもUTF-16の意で使うよね。MSだけじゃなくて
463:デフォルトの名無しさん
12/01/16 15:19:44.52
>>462
使わねーよ。よほど古い、1990年代にかかれたような文書ならともかく。
単に文字列の内部表現がUTF-16というだけ。
464:デフォルトの名無しさん
12/01/16 15:45:26.60
つまり使ってるという訳ですね
465:デフォルトの名無しさん
12/01/16 17:06:14.95
使ってないじゃんｗ
466:デフォルトの名無しさん
12/01/16 18:40:17.48
実質UTF-16しかなかった時代には、Unicode＝UTF-16として扱っているドキュメントは多かった
MSは、単に旧時代の言い方をいつまでも引きずっているだけ。別にそう表記したがっているわけじゃない
467:デフォルトの名無しさん
12/01/16 18:43:23.43
かつては符号化文字集合と文字符号化方式は一対一で不可分だったからね
でも時代は変わったんだからマイクロソフトは自分の所でしか通じない用語は改善するべきだと思う
468:デフォルトの名無しさん
12/01/16 22:54:53.28
>>463 おＪＡＶＡ様はUnicodeがUTF-16BEの様ですね。
System.out.printf(new String(new byte[]{(byte)0x30, (byte)0x70, (byte)0x30, (byte)0x4B}, "Unicode"));
469:デフォルトの名無しさん
12/01/17 08:39:03.98
お前も頭悪いな。そんなところの互換性無くして誰か喜ぶと思ったのか？
470:デフォルトの名無しさん
12/01/17 13:55:57.57
つまり使ってる
MSと同じ
471:デフォルトの名無しさん
12/01/17 14:10:23.18
>>467
そりゃ、無理な相談だ
472:デフォルトの名無しさん
12/01/28 03:34:36.69
>>467
日本語でおk
473:デフォルトの名無しさん
12/01/28 23:14:28.00
結局Unicodeの定義にコンセンサスがないので、違いを語ることができないということでOK?
Unicodeは規格の名前だが、文字集合の意味で使われたり、UTF-16の意味で使われたり、意味も分からずユニコードと言ってみたりカオス？
474:デフォルトの名無しさん
12/01/29 07:23:52.01
混同してるバカがいる、ってだけの話
475:デフォルトの名無しさん
12/02/07 21:50:52.80
英語は大小あわせて46文字しかないし、数字10文字、記号もろもろ入れても7bitで128種類も有れば足りるよね。1byteは8bitだから頭は常に0にしとくよ。
-> ascii (7bit)
んじゃ「頭に1つけたときは半角カタカナ」ってことにしといたらasciiに日本語混ぜれるんじゃね？
いろは47文字に濁点、半濁点、カギカッコとか句読点も入れとくわ。
日本でバックスラッシュとか使わんからこいつは円記号と一緒なｗｗｗ俺天才ｗｗ
-> JIS X 0201
アルファベットだけじゃヨーロッパは物足りないんで、
日本が半角カナ入れたところにウムラウト付きの文字とか入れときます。
-> latin-1
漢字絶対必要なんで、asciiとかほっといてとりあえず2バイトで表現できる文字集合選定しときます。
限りある空間資源なんで「掴」と「摑」とかは一緒ってことで堪忍してください。(包摂)
あ、英語書く時は全部全角でおながいします。
-> 97JIS符号化方式によるJIS X 0208文字集合の利用
いやいや、英語重要なんで。マジ。無視とかありえないんで。
はい、頭が1のバイト隣同士でasciiサンに迷惑かけないよう二人組作ってー。
JIS X 0201のカナ文字は無視しておｋ。これでJIS X 0208の文字も表現できる。
……あれ、半角と全角でアルファベットダブっちまってるけど……まいいか。
-> EUC-JP
おい、メールは7bit符号しか使ったあかんらしいぞ。えー。
切替用の透明文字（エスケープ文字）作ってその文字以降はそれぞれのコードってことにしよ。
-> ISO-2022-JP
asciiもJIS X 0201の半角カナも無視とか親泣くぞ。過去の遺産大事にしろ。
まぁ漢字使いたいけどエスケープ文字とかダルすぎるし、
JIS X 0201の空いたトコもらって2byteで使わせてもらうわ。
え？そこは制御文字用って？知るかボケ。
-> Shift_JIS
476:デフォルトの名無しさん
12/02/07 21:51:23.32
結局同じ文章に外国語入り混じらせて使いたい？
分かった分かった。お前ら黙れ。4バイトで世界中の文字全部平等に並べ直そう。な。
-> ISO/IEC 10646
ちょっとまって同じ事やろうとしてるんだけど。2byteで。
-> Unicode
足並みそろえよか。4byteやけど上2byte全部0の実質Unicodeでやってこや。
おうアジアの土人ども、母国語の文字数すら数えられんのに大きい顔すんなよ？
迷惑なんだから、似たような文字はガンガン同じにまとめとけ。(CJK統合漢字)
-> 10646とUnicodeサブセット
メンゴメンゴ。65536個じゃ足らんかったわｗ
Unicodeの2byte2つ組み合わせる方針にします。
2つのbyteのうち前後どっちを先にするかは文章の始めに印を付けて表すことにしましょう。(BOM)
素直に全部前から読む時はビッグエンディアン、天邪鬼さんはリトルエンディアンってことで。
でもでも、やっぱよく使う文字とよく使わない文字が同じビット数占拠するのもバカらしいんでー、
よく使う文字(BMPの文字)は2byte単体、それ以外は2つくっつけて表す事にします。(サロゲートペア)
-> UTF-16
結局くっつけるんかいｗｗｗそれやったらasciiとの互換も考えれｗｗｗ
1文字あたりのバイト数は可変長だけどasciiの文字しか使わなかったらasciiと一緒になる。
-> UTF-8
サロゲートペアは甘え。容量も懐も大きいとこ見せろ。
Unicodeをそのまま直書きで4byte固定符号化方式。どや。
Unicodeの文字並び(U+00303Dとか)がそのまんま0000303Dで分かりやすい。
-> UTF-32
477:デフォルトの名無しさん
12/02/07 23:14:02.83
符号化文字集合の一文字1コードっていう大原則を破った時点でもうぐちゃぐちゃだったんだよ。
もうどんな符号化文字集合を持ってきても絶対に誰も幸せになれない。
478:デフォルトの名無しさん
12/02/07 23:57:30.91
>>476
Unicodeの意味をを勘違いしている典型例ですね
円コーディングフォームと円コーディングスキームの区別もつかなくて、
リトルエンディアンが天の邪鬼とか言い出すバカ
479:デフォルトの名無しさん
12/02/08 00:00:19.79
わけ判らん駄文を読むヤツが居たという事の方に笑ってしまったわ
480:デフォルトの名無しさん
12/02/08 00:07:39.59
円コーディングｗ
481:デフォルトの名無しさん
12/02/08 07:36:46.60
誰も46文字にはつっこまんのか。
482:デフォルトの名無しさん
12/02/08 16:12:14.16
>>475-476がまるっきり変遷の歴史と違う上に、技術屋とは思えないレベルの勘違いがありすぎ
483:デフォルトの名無しさん
12/02/08 17:20:13.44
英語は大小あわせて46文字しかないね。
-> ascii (7bit)
アイちゃん言語訓練には足りないね。
-> UTF-32
484:デフォルトの名無しさん
12/02/08 18:50:51.84
いろは48文字につっこむのが先
485:デフォルトの名無しさん
12/02/08 23:04:17.54
なんでバイトオーダーとキャストの話が出てこない？
486:デフォルトの名無しさん
12/02/09 01:11:51.86
kwsk
487:デフォルトの名無しさん
12/02/09 23:29:02.94
>>475-476 はセンスあるね
エンディアンの説明がおかしい他はいい線いってる。
時系列を変えてるのはわかりやすさのためだろ
488:デフォルトの名無しさん
12/02/10 00:57:08.24
TCP/IPの立場から考えればリトルエンディアンは十分天邪鬼だろ。
Intel CPUはリトルエンディアンだが
整数値を小さな型にキャストしようとする時
先頭アドレスを変えずに読み込みを途中で打ち切るだけで済む。
ビッグエンディアンだとスライドさせないといけない。
その分リソースを食う。
でも数値をどこかで切り捨てたい時とか上から順にダンプかけたいときは
メリット・デメリットが逆になる。
円記号問題の根底はJIS X 0201というよりISO 646各国版の普及にあって、
もっと世界的なもんじゃないのか？ トライグラフとか。
誰か詳しい人解説頼む。
489:デフォルトの名無しさん
12/02/10 08:33:56.11
トライグラフはEBCDICでもC言語を書けるようにしたものだから、あまり関係ない。
490:デフォルトの名無しさん
12/02/10 21:48:22.40
えっ？
491:デフォルトの名無しさん
12/02/11 01:09:06.04
ビッグエンディアンがマトモだと信じているバカはプログロマー止めた方がいい
492:デフォルトの名無しさん
12/02/11 08:38:33.85
なんで？
ワード長の拡張で、対応がずれる、以外のディスアドバンテージがあるならどうぞ。
493:デフォルトの名無しさん
12/02/11 09:53:05.21
どう考えても下位ビットが下位アドレスに格納されるリトル園ディンのが自然じゃね?
ビッグエンディアンは奇数アドレスアクセスとかできないでしょ。
GIF画像の圧縮みたいな可変ビット長データの連続してパッキングは、ビッグエンディアンじゃやってられない。
デメリットは「ビットの上位の方向とバイトの上位の方向が逆」に尽きる。
494:デフォルトの名無しさん
12/02/11 10:07:27.29
こうして小人さんたちの戦いは続くのであった。
495:デフォルトの名無しさん
12/02/11 10:10:47.68
まともなビッグエンディアンのアーキテクチャなら、ビットにアドレスが付く命令でも、
MSBがアドレス0だよ？
ビットアドレスが2の冪と対応してない、とは言えるけど、直感的でない、以外に問題ある？
496:デフォルトの名無しさん
12/02/11 10:21:38.52
1バイト内のビットアドレスじゃなくてメモリ(バイト)アドレスのことだろ。
4バイト整数12345678hの上位バイト12が上位メモリアドレス3に書かれるのがリトル。
4バイト整数12345678hの上位バイト12が下位メモリアドレス0に書かれるのがビッグ。
FFhに1足して上位桁に繰り上がったら、より下位のアドレスが変わるなんて変と思わないの?
497:デフォルトの名無しさん
12/02/11 10:31:03.80
アドレスが大きい方が下位と思えばどうということはない。
498:デフォルトの名無しさん
12/02/11 10:41:26.87
二つ前のレスも読めないなんて、
こういうバカがビッグエンディアンを設計したんだろうな
499:デフォルトの名無しさん
12/02/11 10:49:46.08
UTF-8は上位ビットが下位アドレス側に格納されるから、設計者は馬鹿だし、
リトルエンディアン信者は当然使わないよなw
500:デフォルトの名無しさん
12/02/11 11:02:53.62
どうやら自分以外は全て馬鹿病の患者が、リトルエンディアン凄い、偉い、と吠えてるだけのようですねw
準TADのTRONコードでも使ってろw
501:デフォルトの名無しさん
12/02/11 11:44:58.61
>>388
考えたのはＭ＄だからな。
502:デフォルトの名無しさん
12/02/11 11:48:27.56
MS叩きとか、いまどき流行らんわ
503:デフォルトの名無しさん
12/02/11 11:51:29.54
>>499
cpuがメモリに直接ワードアクセスする時のメモリイメージの話と、
バイトオリエントにシリアライズしたutf-8の話を一緒にするのはいくないぜ
504:デフォルトの名無しさん
12/02/11 12:13:02.50
>>501
いやほんとbomのおかげで助かるわ。
utf-8とその他のコードをほぼ確実に判別できる
505:デフォルトの名無しさん
12/02/11 20:26:42.27
>>504
utf-8なのにBOMって
506:デフォルトの名無しさん
12/02/11 21:38:11.32
>>505
何か問題が？
UTF-8のシグネチャーとして大活躍じゃないか
507:デフォルトの名無しさん
12/02/12 02:20:34.14
名前が良くないな。
援交ディングスキームシグネチャー
これでおk
508:デフォルトの名無しさん
12/02/12 02:52:52.82
異体字セレクたん
みたいだな
509:デフォルトの名無しさん
12/02/12 08:16:34.20
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 11:27:09.36
よくありません
511:デフォルトの名無しさん
12/02/12 12:25:31.41
why?
512:デフォルトの名無しさん
12/02/12 15:56:41.47
U+FEFFはBOM限定になったような
513:デフォルトの名無しさん
12/02/12 23:11:21.56
既存の文書の存在は認めないのですね
514:デフォルトの名無しさん
12/02/12 23:28:04.18
はい
はい
515:デフォルトの名無しさん
12/02/13 00:47:58.80
>>512
ソースｷﾎﾞﾝﾇ
516:デフォルトの名無しさん
12/02/13 12:43:00.82
URLﾘﾝｸ(www.unicode.org)
のU+FEFFで、non-breakingは代わりにU+2060を使ってね、と。
URLﾘﾝｸ(www.unicode.org)
のU+2060で、BOMの曖昧さを無くす為に、と。
その方向で行こうね、位の意味合い？
517:デフォルトの名無しさん
12/02/13 23:32:42.50
先頭の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 07:21:36.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 07:47:25.15
「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 13:05:58.68
なるほど。やっと理解しました。ありがとう。
521:デフォルトの名無しさん
12/02/14 17:43:30.45
URLﾘﾝｸ(www.unicode.org)
> kHanyuPinyin 10760.010:g�i
文字化けワロス
522:デフォルトの名無しさん
12/02/19 00:37:27.03
今来た俺に違いを3行で教えてくれ
523:デフォルトの名無しさん
12/02/19 01:31:55.27
Unicode・・・文字集合
UTF-8・・・文字表現
です
524:デフォルトの名無しさん
12/02/19 01:37:04.34
>>523
ほう、ではUnicode 6.0のどこに「Unicodeが文字集合の一つ」と
書かれているのかね？
525:デフォルトの名無しさん
12/02/19 01:40:16.48
3行オーバーしたので答えられません。
自分でぐぐってください。
526:デフォルトの名無しさん
12/02/19 01:42:59.62
仕様のどこと訊かれてググれと答える奴は
プログラマーに剥いていない
527:デフォルトの名無しさん
12/02/19 01:47:33.04
ハゲは結構多いよ
528:デフォルトの名無しさん
12/02/19 01:49:36.68
プログラマーの童貞率、アスペ率は異常
529:デフォルトの名無しさん
12/02/19 01:57:06.64
細かいことにこだわらない奴はプログラマー向いてない。
向いてない人「ちょっとくらいいいでしょ？多めに見てよ」
コンピュータ「はあ？」
530:デフォルトの名無しさん
12/02/19 02:11:33.76
そもそも「文字表現」ってなんだよ。ちゃんとした用語使えよ。
531:デフォルトの名無しさん
12/02/19 02:23:21.28
文字表現は文字表現だよ
(T-T)悲しい
(^-^)うれしい
こんなのが最近たくさん追加されてるだろ
532:522
12/02/19 02:54:14.52
おいおい、2スレ目にもなってケツ論出てないのかよ
533:デフォルトの名無しさん
12/02/19 15:37:07.51
>>523
痴呆があらわれたか
534:デフォルトの名無しさん
12/02/19 22:52:12.18
Unicode=UTF-8
一般人に違いなどわからんからこれでよし
535:デフォルトの名無しさん
12/02/19 23:03:51.63
いいわけないだろカスが＾＾
536:デフォルトの名無しさん
12/02/20 11:24:52.62
元々の規格
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 18:09:07.05
ぜんぜんダメ
538:デフォルトの名無しさん
12/02/20 18:10:40.38
このスレで何度か書かれてるけど、
そろそろencoding formとencoding schemeの違いを
理解した方がいいよ
539:デフォルトの名無しさん
12/02/20 20:38:04.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 20:40:31.47
最初の二つを間違えた。正しくは ↓
UTF-8 (BOMなし)
UTF-8 (BOMあり) ←MSの「UTF-8」
541:デフォルトの名無しさん
12/02/20 23:14:05.93
そもそもBOMってMSの拡張じゃないの？
Unicodeにそんな仕様はいってるの？
542:デフォルトの名無しさん
12/02/21 00:42:33.77
入ってますがな。
なければどんなに幸せだったことか…
BOMのない世界にforkしたい。
543:デフォルトの名無しさん
12/02/21 04:01:27.70
無くて困ったことはあるが、
あって困ったことはありませぬ。
544:デフォルトの名無しさん
12/02/21 04:24:21.16
BOMあるとshebangが正常に動作しない
545:デフォルトの名無しさん
12/02/21 05:19:27.61
そのファイルだけBOMとれば？
文字コード不明なファイルを読み取ろうとするシバンはウンコ(・∀・)ノ●。
日本語のパスはどうすんだよ。
546:デフォルトの名無しさん
12/02/21 06:46:27.45
BOM が MS拡張とかどんだけ……
まだ ISO-10646 が正式な規格になる以前からありますがな。
547:デフォルトの名無しさん
12/02/21 17:29:35.79
>>537
えーなんでダメなんだよ？これjavaのエンコードライブラリそのまんまなんだぜ？
548:デフォルトの名無しさん
12/02/21 20:08:10.74
>>547
JavaはBOM周りの処理のバグを認識しつつ
バグを永久に直さないことに決定済みだろ
『マイクロソフトが追加した規格』が『おJavaの認識する名前』で
BOMがMS独自という誤った記述が無ければおけ
549:デフォルトの名無しさん
12/02/21 22:38:40.98
>>544
shebangに関して言えば、
shebangを読み取るプログラムが
Unicodeに対応していないというべきだろうね。
たぶん、UTF32で書かれたshebangも読み取れないはず。
550:デフォルトの名無しさん
12/02/21 22:45:12.38
>>543
無くて困ったことは皆無ですが、
あって困ったことはいやほどあります。
551:デフォルトの名無しさん
12/02/21 22:52:15.54
>>550
無くて困ったというのは文字コードが明確でなかったと想像できるけど、
あって困ったというのは、具体的にどんなこと？
552:デフォルトの名無しさん
12/02/21 23:04:12.52
>>551
上にあるけどshbangが通らないとか(頻発するので慣れた)、
ビルドが通らないとか(頻発するので慣れた)、
SQLの実行に失敗するとか(多数のDDLの実行途中だったのでリカバーに泣いた)。
553:デフォルトの名無しさん
12/02/21 23:09:04.25
ああ、あと複数のファイルをcatで繋いだら境目にゴミが混じったってのもあった。
554:デフォルトの名無しさん
12/02/21 23:12:44.31
あるテキストの改行が
Cr
CrLf
Lf
の
三つが混ざっちゃうことあるの?
555:デフォルトの名無しさん
12/02/21 23:14:57.14
>>551
単なるバイトストリームとして扱えなくなるケース。
556:デフォルトの名無しさん
12/02/21 23:19:30.60
BOMが認識できないバギーなコンパイラはともかく、catは違うような。
テキストファイルをバイナリで結合することが間違ってると思う。
結合するファイルの文字コードが違ってたら破綻するし、
ISO-2022はそもそもバイナリ結合できなくね？
557:デフォルトの名無しさん
12/02/22 09:08:20.78
>>556
>>553, >>555 は、BOM なし UTF-8 ならば cat で連結できる、って話じゃないの？
別なコードの話を持ちだしても意味ないと思う。
558:デフォルトの名無しさん
12/02/22 09:10:14.09
>>556
＞バギーなコンパイラ
言いがかり。
そういうことがないようにUTF-8を使うのに
BOMがあるだけでパー。
＞結合するファイルの文字コードが違ってたら破綻
同じUTF-8だけどな。
BOMがあるだけでパー。
559:デフォルトの名無しさん
12/02/22 09:28:36.68
utf-8対応をうたうならbomを認識できなくてはならないのに
僕のＫＵＳＯコンパイラはダメなんです。と言われてもなあ。
取り敢えずＫＵＳＯコンパイラユーザーにデメリットが有るのはわかったw
560:デフォルトの名無しさん
12/02/22 09:34:37.56
catでbomが困るなんて、
「テキストに日本語を書くと様々な問題を起こすので日本語の使用はデメリット」
とか
「csvにヘッダー行を書くとcatできない問題があるので書かないようにしている」
ってのと同レベル
561:デフォルトの名無しさん
12/02/22 13:10:05.23
>>559
BOMさえなければ、とくにUTF-8に
対応することがそもそも不要。
バギーでもクソでもない。
UTF-8原理主義者は面倒くさいな。
562:デフォルトの名無しさん
12/02/22 14:07:48.03
バイトオーダーという概念がないUTF-8でBOMとはこれいかに？
563:デフォルトの名無しさん
12/02/22 14:21:41.35
仕様に従っているかどうかの話と
仕様自体の妥当性は別の話。
utf-8安置は頭が悪いな
564:デフォルトの名無しさん
12/02/22 14:25:08.95
うにコード安置はいるがutf-8安置はいるのだろうか？
565:デフォルトの名無しさん
12/02/22 15:03:18.48
ファイル名に日本語を使ってはいけないとか、メールのタイトルに日本語を
使ってはいけないというのは、UNIXの伝統的な掟です。
LinuxはUNIXに憧れているので、UNIXの掟を忠実に守ります。
掟を守るのは大事なことです。
UTF-8を許せば日本語を使う馬鹿が出てきますよ。
566:デフォルトの名無しさん
12/02/22 15:03:29.36
UTF-8は、ASCII上位互換コーディングシステムとして設計された。
バイトストリームとして扱えば、プログラムがそのまま使えるように。
Ken Thompson先生が。Unicodeの外の世界で。
だからUnicode.orgがUTF-8にもBOMを付けるのは味噌をつけてしまったようなもの。
ただ既にBOMがあるのだから、当然の帰結ではあるのだが。
もともとのUnicodeの考え(wide character主義)とUTF-8は乖離しているから、
こういう残念な状態になってしまった。
567:デフォルトの名無しさん
12/02/22 15:06:40.21
>>565
パス名といえば、例えば、
"￥Users￥漢字名さん￥ドキュメント"
"漢字名さん"
"ドキュメント"
それぞれにBOMが付くとパス名処理がすごく面倒になる。
Unicode互換の処理系を名乗るにはやらないといけないけど、
そういうOS、ミドルウェアは未だ存在しない。
568:デフォルトの名無しさん
12/02/22 15:18:27.13
大体BOM付きとか滅茶苦茶不合理じゃん。
"a" だけで何バイトだよ？
旧来のBOM無しUnicodeを新しいUnicodeとして制定しなおしましょう。
569:デフォルトの名無しさん
12/02/22 15:18:31.69
>>567
だからこそ許してはいけないのです。
ファイル名やメールの件名に日本語を使ってはいけません。
570:デフォルトの名無しさん
12/02/22 15:19:17.81
さあ、早くEF BB BFを削る作業に戻るんだ。
571:デフォルトの名無しさん
12/02/22 15:20:33.65
>>568
それは思い上がりですね。
ASCIIだけで充分です。
572:デフォルトの名無しさん
12/02/22 15:20:40.10
NotePad BOM付きしか認識しない。
UNIX系 BOM無しを前提にしている。
やっぱM$の陰謀以外考えられないわけだが。
573:デフォルトの名無しさん
12/02/22 15:21:39.18
>>571
ならば、おまえだけは日本語で書き込むなよ。
574:デフォルトの名無しさん
12/02/22 15:28:41.23
kokoha tanoshii intaaneto desune
575:デフォルトの名無しさん
12/02/22 15:29:14.05
>>573
俺はUNIXもLinuxも使っていないのでメールの件名に日本語を使うし、
ファイル名にも日本語を使います。
HTMLメールが送られてきたからと言って怒ったりしません。
576:デフォルトの名無しさん
12/02/22 15:35:24.27
571 名前：デフォルトの名無しさん ：2012/02/22(水) 15:20:33.65
>>568
それは思い上がりですね。
ASCIIだけで充分です。
>>575
だからおまえは日本語でこの掲示板に書き込む権利は一切無いの。
577:デフォルトの名無しさん
12/02/22 15:41:57.47
>>576
いえいえ、俺はUNIXもLinuxも使わないので歴史的に日本語OKなのです。
ご心配には及びません。
578:デフォルトの名無しさん
12/02/22 15:42:52.80
nanda tadano baka dattaka
579:デフォルトの名無しさん
12/02/22 16:46:17.18
>>567
Unicode規格のencoding formとencoding schemeの説明を読み直してこい
フォルダー名にbomが付くとかあり得ないから
580:デフォルトの名無しさん
12/02/22 16:51:22.56
asciiとかどれだけ可搬性のないのものを持ち出すんだよ。
@とか[とかは機種依存文字なのを知らんのか最近の若いモンは。
581:デフォルトの名無しさん
12/02/22 16:57:58.84
>>580
8bit目を立てるのはマナー違反です。
582:デフォルトの名無しさん
12/02/22 17:18:50.84
>>579
何言ってるかさっぱりわからん。
パス名はメモリ上のデータに限られてると限定しているわけ？
583:デフォルトの名無しさん
12/02/22 18:05:31.10
>>572
NotePad は BOM なくても UTF-8 を認識するよ。
でも保存するときに強制的に BOM がつくのが問題。
Unix でなくても、たとえば文書のヘッダやフッタを別のテキストファイルから
include してくるというのは、よくある処理だと思うけど、そういう場合に、
いちいち BOM の処理が必要というのは不合理。
字数とかワードラップとかの処理が必要な場合は仕方ないけれど、そうでない
場合はバイナリとテキストで同じプログラムが使えるようになっているのが望
ましい。
584:デフォルトの名無しさん
12/02/22 18:11:47.88
>>582
Unicode規格ではEncoding FormにBOMの概念は無いんですよ。(ここらへんはRFC 3629と定義が違う)
Windowsのフォルダー名はEncoding SchemeでなくEncoding Form単位で読み書きするので、
フォルダー名にBOMが入ることはないです
585:デフォルトの名無しさん
12/02/22 18:22:59.79
>>583
>たとえば文書のヘッダやフッタを別のテキストファイルから
>include してくるというのは、よくある処理だと思うけど、そういう場合に、
MS Word文書をバイナリで結合したら読み取れませんでした。てのと同レベル。
バイナリデータを挿入するんでなく、「テキスト」を挿入するよう見直した方がいい。
ISO/IEC 2022だって二つのファイルをバイナリで結合したら壊れるだろ
586:デフォルトの名無しさん
12/02/22 18:31:25.66
>>580
ASCIIの7ビット文字は、現代で現実的に
充分ポータブルだろ。
どのあたりを心配してる？
587:デフォルトの名無しさん
12/02/22 18:34:04.47
>>586
∩＿∩
／ ＼ ／＼
| （^）=（^） | 人人人人人人人人人人
| ●_● | ＜ BOM否定派に対する皮肉だろ＞
/ // ///ヽ ＜言わせんな恥ずかしい＞
| 〃 ------ ヾ | ＹＹＹＹＹＹＹＹＹＹＹＹＹＹ
＼＿＿二＿＿ノ
588:デフォルトの名無しさん
12/02/22 20:32:33.68
>>584
フォルダ名が外からもたらされたら、
>フォルダー名にBOMが入ることはないです
なんて課程は全くできないけど?
589:デフォルトの名無しさん
12/02/22 22:16:57.21
>>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 22:20:02.08
> 外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、
> BOMを取り除いた形で
こういう処理をユーザがしないといけないって話なんだけど？
591:デフォルトの名無しさん
12/02/22 22:49:40.36
話がずれてないか？
もとはパス名処理が大変と言う567に対し、
文字列になってる時点でBOMは無いので単純だというのが579。
バイナリを文字列に変換するのにBOM処理は当然必要なんだけど、
それは567の「パス名処理が大変」「実装が存在しない」とは違う話。
592:デフォルトの名無しさん
12/02/22 23:09:53.07
BOMっていうのはファイルにしか存在しないものだよ。
BOM付きの文字列を半分に分けたらどうする？
前半の文字列にはBOMがついて、
後半の文字列にはBOMがついてない？
それともわざわざ付けると思う？
BOMが存在するのは外部リソースのみ
それをUNICODE文書として読み取った時、
BOMは消さないといけない。
だから、APIに渡す文字列がBOM無しなのはアタリマエのこと。
593:デフォルトの名無しさん
12/02/22 23:11:12.92
プログラマが頑張らないといけない実装しかないから、
パス名処理が大変なんでしょ？
> 文字列になってる時点でBOMは無い
「文字列になって」
この定義自体が難しいから、
プログラマが何も気にしないでも問題が起きない実装はないわけだ。
そもそも利用者のレベルでも問題が起きうる。
594:デフォルトの名無しさん
12/02/22 23:12:42.87
>>592
> BOMっていうのはファイルにしか存在しないものだよ。
外部リソースならどんなものにも付く可能性がある。
595:デフォルトの名無しさん
12/02/22 23:22:35.82
>>593
> 「文字列になって」
> この定義自体が難しいから、
簡単。バイナリではなく文字列として解釈できる準備ができた時。
それは文字列型に代入した時や、
UTF8フラグなんかをつけた時。
596:デフォルトの名無しさん
12/02/22 23:23:34.45
そもそも「ファイル」っていう概念をちゃんと>>592が分かって書いてるのかどうかも怪しい