トップページ⇒tech
987コメント271KB

UnicodeとUTF-8の違いは？　その2

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2010/05/27(木) 14:17:17
前スレでなんとなくわかったのですが、インディアンがどうとかいうあたりで
話について行けなくなりました。
0002デフォルトの名無しさん2010/05/27(木) 14:20:27
次スレいるのかよｗ
0003デフォルトの名無しさん2010/05/27(木) 14:47:56
すみません。まだよくわかりません。
自分の理解では　↓

＜Unicode＞
　文字の一覧のことらしい。文字には識別用の符号が割り振られている。

＜UTF-8＞
　Unicodeの各文字をバイトデータで表現したもの。Unicodeの符号値から
UTF-8のバイトデータへは変換式があるらしい。
　インディアンが関係してくるらしいがそのあたりがよくわからない。
　BOMというものが付いていて、それがUnicodeのしるしの役割をしているらしい。

疑問点
・UTF-8とインディアンの関係は？
・UnicodeとUTF-8が別モノなのにBOMがUnicodeのしるしというのがよくわからない
0004デフォルトの名無しさん2010/05/27(木) 15:01:44
UTF-8はエンディアン関係無いよ。これは1バイトずつの並びだから
どのCPUでも扱いは同じ。
Unicodeの表を元に実際のバイトの並びを決めた方式の一つがUTF-8

BOMはUnicode（≒UTF-16と思っていいか？）には必須だが
UTF-8の場合、このファイルはUTF-8でエンコードされてると
わかるためのしるし。
何も無かったらそのユーザーの環境で普通に使われてるエンコーディングと
判断されるケースが多い。
0005デフォルトの名無しさん2010/05/27(木) 15:09:04
ビットで表すと、、、
16ビットのUNICODEの表で
00000000 0xxxyyyy (7bit)の文字は
UTF-8だと0xxxyyyy
ビッグエンディアンの環境でUTF-16だと00000000 0xxxyyyy
リトルエンディアンの環境でUTF-16だと0xxxyyyy 00000000
xxxxxxxx yyyyyyyy(16bit)の文字は
UTF-8だと1110xxxx 10xxxxyy 10yyyyyy
ビッグエンディアンの環境でUTF-16だとxxxxxxxx yyyyyyyy
リトルエンディアンの環境でUTF-16だとyyyyyyyy xxxxxxxx

こんな感じ。何が入ってるか事前にわからないとエンコードできないでしょ？
0006デフォルトの名無しさん2010/05/27(木) 15:16:22
>>4
あれーでもUTF-16はBOM省略可能では？(Unicode規格2.6章)

>>5
>16ビットのUNICODEの表で
Unicode表はバイトデータと関係ないから「16ビットの表」っていう表現はおかすぃ
0007デフォルトの名無しさん2010/05/27(木) 15:31:18
ところでUCSって何?
Unicodeとは別モノ?
0008デフォルトの名無しさん2010/05/27(木) 15:55:44
>>3
{UTF-8, UTF-16}　∈ Unicode

こういう包含関係があるのがUnicodeとUTF-8との違いだよ
0009デフォルトの名無しさん2010/05/27(木) 16:16:19
それは
{UTF-8仕様, UTF-16仕様}　∈ Unicode規格
の話な。
ここで議論しているのはUnicode規格でなくUnicode文字集合の話だ。
0010デフォルトの名無しさん2010/05/27(木) 16:23:30
えっ
0011デフォルトの名無しさん2010/05/27(木) 17:28:25
なんでこんなしょもないスレの次スレなんか立てるんだよ...
0012デフォルトの名無しさん2010/05/27(木) 17:30:29
せめてスレタイを汎用化してほしかった。
Unicode総合スレとか。
0013デフォルトの名無しさん2010/05/27(木) 18:23:10
とりあえず前スレ

UnicodeとUTF-8の違いは？
http://pc12.2ch.net/test/read.cgi/tech/1177930957/
0014デフォルトの名無しさん2010/05/27(木) 18:28:31
Unicode ⊃ { USC-2, UCS-4, UTF-8, UTF-16 }
USC-2 : 1文字2バイトの文字集合
USC-4 : 1文字4バイトの文字集合
UTF-8 : 文字コードを文字集合にマッピングする変換規則の一つ（ひとつの文字を表す文字コードの長さは1バイトから6バイト）
UTF-16 : 文字コードを文字集合にマッピングする変換規則の一つ（ひとつの文字を表す文字コードの長さは2バイト（但し一部の文字は二つの文字コードを使って一つの文字を表す））
0015デフォルトの名無しさん2010/05/27(木) 19:25:25
ところでお前らUnicodeって言ったらUnicodeコンソーシアムの規格かISO/IEC10646か
どっちを指すわけ？
Unicodeコンソーシアムの規格にはUCSなんて概念は無いわけで。
0016デフォルトの名無しさん2010/05/27(木) 19:30:55
それを知るためにここにきますた
0017デフォルトの名無しさん2010/05/27(木) 19:33:26
UTFは文字コードをUCSの文字集合に割り当てる為の実装手段って事か。
UTF-8は文字集合にUCS-4を使っているみたいだけど
UCS-4は1文字4バイトとあるのにUTF-8は1文字1～6バイトと可変とある。
UTFによって1文字に使うバイトが変わるならUCS-4の1文字4バイトってのは一体何の基準なんだ
と思ったらUCS-4自身もUCS-4の文字集合を使うための実装手段として使えるんだな。
その際に1文字が4バイトになると、なるほど。
0018デフォルトの名無しさん2010/05/27(木) 19:35:14
UTF-8って1～6じゃなくて1～4バイトの可変じゃねーの？
0019デフォルトの名無しさん2010/05/27(木) 19:45:34
>>18
セキュリティーにうるさい環境では4バイトまでしか認めないけど、20年
前から絶対防御を実現しているLinux等は、いまだに6バイトまで許容して
います。
まあ、JavaやWindowsは脆弱すぎるってことです。
0020デフォルトの名無しさん2010/05/27(木) 19:49:19
>>18
フラットな4バイト空間をどうやって1から4バイトの可変長の空間に詰め込むんだよ。
0021デフォルトの名無しさん2010/05/27(木) 19:52:12
>>19
意味わかんね。何で仕様の話にセキュリティーが出てくるんだよ。

>>19
規格嫁。Unicode 5.2.0の2.5章にUTF-8は最大4バイトと書いてある。
0022デフォルトの名無しさん2010/05/27(木) 19:54:49
>>21
意味がわからなかったら危険。
0023デフォルトの名無しさん2010/05/27(木) 19:54:58
>>21 ISO 10646 対応ってことでそ
0024212010/05/27(木) 19:55:48
>>19
どうやって詰め込むかは3.9章に書いてある。
0025デフォルトの名無しさん2010/05/27(木) 20:03:32
煽りあい気味の意見交換は前スレで散々やったからこのスレでは控えめに行こうぜ

5バイト以上のUTF-8についてwikipediaに分かりやすくまとまってたので引用
http://ja.wikipedia.org/wiki/UTF-8#.E3.82.BB.E3.82.AD.E3.83.A5.E3.83.AA.E3.83.86.E3.82.A3
｜ セキュリティ
｜
｜UTF-8のエンコード体系には冗長性があり、同じ文字を符号化するのに複数の表現が考えられる。
｜かつてはそのような表現も許容されていたが、ディレクトリトラバーサルなどの対策として行われる
｜文字列検査を冗長な表現によりすり抜ける手法が知られるようになったため、現在の仕様では最も
｜短いバイト数による表現以外は不正なUTF-8シーケンスとみなさなければならない。[9]
｜
｜ISO/IEC 10646の定義が5バイト以上の表現を許容していることにより、正しくない実装をおこったバグ
｜のあるシステムにおいてエンコード時にバッファオーバーフローが発生する可能性も指摘されている。
0026242010/05/27(木) 20:07:20
アンカミスったし(>>19→>>20)、ageちまった。スマン。

でもUnicodeっていったらUnicodeコンソーシアムの規格じゃねーの？
ISO 10646って言ったらUnicodeじゃなくてUCSっつーイメージがある。偏見？
0027デフォルトの名無しさん2010/05/27(木) 20:24:45
>>19
JavaやWindowsには既知の『正しくない実装をおこったバグ』が存在
しているということですね。
具体的にWindowsのKB番号など教えていただけないでしょうか。
0028デフォルトの名無しさん2010/05/27(木) 20:33:16
>>27
いや、ノーガード戦法こそ唯一絶対のセキュリティーって話。
セキュリティーが甘いからノーガード戦法が出来ないんだろ？
0029デフォルトの名無しさん2010/05/27(木) 20:35:38
よくわかりませんが、Linuxはノーガードということなのですね。凄いです。
0030デフォルトの名無しさん2010/05/27(木) 20:38:21
Windows：細かいところが甘いから6バイトまで使えるところを４バイトに縛って強制的に安全化を図っている
Linux：細かいところまで大丈夫なので４バイト縛りなどのセキュリティーを入れる必要がない

って事が言いたいんでしょ。
0031デフォルトの名無しさん2010/05/27(木) 20:45:39
>>30
いや、さすがにそこまでは言っていない。
というか、細かいバグの多さならLinuxが最高峰だし。
0032デフォルトの名無しさん2010/05/27(木) 20:55:39
>>15
ISO/IEC 10646はUnicodeではありません。
よってUTF-8が6バイトとか、UCSがどうとか言っている奴はスレ違いということで。
0033デフォルトの名無しさん2010/05/27(木) 20:56:24
ただ、ノーガード戦法がセキュアって言うのは常識だろ。
たとえば、Linuxで広範に使われているlibxml2。
これは、エンティティー参照によく知られるバグを持っているけど、
そのまま使うと危険だから、賢い人なら自力で回避して使う。
Gnomeはlibxml2をそのまま使っているから、実際危険な使い方が出来る。
だから、賢い人ならGnomeを使わず、TWM+XFMで環境を構築する。
こうやって賢く安全な使い方が普通に出来てしまうのがLinuxの良い
ところだ。
Windowsではどうだ？
エクスプローラに脆弱性があるからと言って、代替製品に置き換えて
使う人がどれだけいる？
つまり、与えられたセキュリティーなど無意味。
何も与えない、ノーガードこそが一番安全なのだ。
0034デフォルトの名無しさん2010/05/27(木) 20:59:00
>>33はクレイジー
0035デフォルトの名無しさん2010/05/27(木) 21:08:46
>>34
クレイジーってなんだよ？
Linuxが6バイト許容なのもエンティティー参照の問題もセキュリティーの
啓蒙のためにそうなっているんだよ。
痛い目にあえば、ユーザーは気をつけるようになるだろ？
「誰も信用するな」がセキュリティーの基本原則だ。
こういった啓蒙活動のおかげでLinuxユーザーは賢くなり、Linuxは最高の
セキュリティーを手に入れることが出来た。
これがフルオープンの力だ。
0036デフォルトの名無しさん2010/05/27(木) 21:14:00
ふむふむ、Linuxは広範囲に使われている基幹dllに脆弱性があっても修正されないのか
0037デフォルトの名無しさん2010/05/27(木) 21:15:32
これ以上俺の腹筋を痛めないで欲しいなぁ
0038デフォルトの名無しさん2010/05/27(木) 22:20:07
>>14
UTF-8に関しては日本語が3バイト、英数字が1バイト
UTF-16は日本語が2バイト、英数字が2バイトで

日本語の量が多いファイルではUTF-16が容量節約に適して
日本語より英数字が多いファイルではUTF-8が容量節約に適しているって
解説しているサイトがあったなあ
0039デフォルトの名無しさん2010/05/27(木) 22:27:12
そもそもASCIIコードと互換性のないUTF-16なんてなんで作ったの？
0040デフォルトの名無しさん2010/05/27(木) 23:34:42
移行できると思っていた
0041デフォルトの名無しさん2010/05/28(金) 00:01:05
アメリカ野郎にとってはASCIIで対応してる文字にわざわざ２バイト以上使うなんてクレイジーでしかないからね
0042デフォルトの名無しさん2010/05/28(金) 01:12:07
ASCIIは永遠に使われ続けるだろ
0043デフォルトの名無しさん2010/05/28(金) 01:12:12
たかが１バイト増えるだけだが
1が2になると倍だしな
0044デフォルトの名無しさん2010/05/28(金) 19:17:26
wikipediaのUTF-8の項目に
＞UTF-8はISO/IEC 10646(UCS)とUnicodeで使える8ビット符号単位の文字符号化形式及び文字符号化スキーム。
とあるのですが一般的に使われているUTF-8はISO/IEC 10646を使ったものですか？それともUnicodeを使ったものですか？
ttp://ja.wikipedia.org/wiki/UTF-8
0045デフォルトの名無しさん2010/05/28(金) 22:17:36
>>44
実際に使われているUTF-8のデータから、両者の違いを見分けることはできないと思うよ。

文字集合がUCS-2だUCS-4だって言ったところで、Unicodeで定義されない文字がある訳じゃ無い。

ついでにUCS-4はUnicodeと同じ21bitの範囲までしか文字を入れない決まりになったしね。
0046デフォルトの名無しさん2010/05/29(土) 22:54:03
ⅠⅡⅢとか①②③ってなんの問題が?
0047デフォルトの名無しさん2010/05/30(日) 11:09:31
機種によってコードが違ったり無かったりしたからな
0048デフォルトの名無しさん2010/05/30(日) 21:18:26
>>41
でも日本人の場合、EUCとかSJISで対応してる文字にわざわざ３バイト以上使う
クレイジーな奴が多いんだよな・・・
0049デフォルトの名無しさん2010/05/31(月) 03:08:55
UTF-8って日本語3バイトになるのか
知らんかった
0050デフォルトの名無しさん2010/05/31(月) 21:57:26
そりゃあ日本独自のそれこそガラパゴスよりは全世界共通のグローバルの方が見た目かっこいいからだろうな。
0051デフォルトの名無しさん2010/06/01(火) 01:28:22
SJISは海外アプリが食ってくれない事が多々あるし、EUCは日本人でも使ってる奴が少ない。
最大でもせいぜい1.5倍にしか増えないなら、使う価値は十分あると思うが。
0052デフォルトの名無しさん2010/06/01(火) 05:17:40
>>46
Unicode的には全く問題ない。
0053デフォルトの名無しさん2010/06/01(火) 10:09:44
外国の混じりにしたらとたんにSJISのソースじゃやっていけなくなった・・
まあ直接埋め込む方が悪いがｗ
0054デフォルトの名無しさん2010/06/01(火) 18:50:01
>>44
そらUnicodeだろ。IANAもRFC3629もUnicode。

>>46
シフトJISで後から追加された文字。いわゆる機種依存文字なのでWinのシフトJISを
Macに持って行くと文字化けする。Unicode系のコードでやりとりすれば>>52の言うとおり問題無い
0055デフォルトの名無しさん2010/06/01(火) 20:31:22
UNIXやLINAXはEUCなのになんでEUCが世界を支配してないの?
0056デフォルトの名無しさん2010/06/01(火) 20:42:29
えっ普通LinuxはUTF-8じゃないの？
それはともかく多言語を同時に扱えない文字コードはちょっと・・・
0057デフォルトの名無しさん2010/06/01(火) 22:01:20
PARLだかパールだか
サーバーサードスクリプトがはやったときどのプロバイダもFTPでEUCのHtmlをアップさせてたじゃん
0058デフォルトの名無しさん2010/06/01(火) 22:14:20
>>55
基本的に殆どのソフトウエアのコア部分は海外で作られる。
Windows、Mac OS X、Linux、FreeBSD、NetBSD、OpenBSD、
Plan9、gcc、glibc、perl、php、Python、vi、emacs等

海外のプログラマの人達が使ってる文字はASCIIが基本で、
その範囲を超える文字はマルチバイト文字として特殊な扱いに属する。

マルチバイト文字には歴史的に数多くの種類があるけれど、(日本ならshift-jis、euc、jis等)
その一つ一つに対応したプログラムを個別に書くのは非常に手間が掛かってかったるいし、
自分が使っていない言語の事は良く分からないので、取っつきにくいという問題もある。

その点Unicodeは各国語の文字が単一の文字集合に入っているし、
その取り扱い方法も規定されているので、Unicodeを扱えるように
プログラムを書けば、各国語の文字を扱えるようになるという便利さがある。
0059デフォルトの名無しさん2010/06/01(火) 22:17:00
>>57
今perlはutf-8がデフォルト文字コードだよ。
0060デフォルトの名無しさん2010/06/02(水) 02:22:38
perlはスクリプトをutf-8で書いて、入力時に希望の文字コードからutf-8に変換して、
出力時にutf-8から好きな希望の文字コードに変換する、という方法が確立されたかららくちん
0061デフォルトの名無しさん2010/06/02(水) 06:08:30
>>55
Unicode系じゃないとコンパイル時と実行時に文字コードの情報が必要になって
面倒なんだよ。Unicodeならその国の文字は読めなくても文字化けしない。
0062デフォルトの名無しさん2010/06/02(水) 20:47:12
WindowsServerとSQLServerが無料になったら使う
0063デフォルトの名無しさん2010/06/02(水) 20:50:27
お前は一生シフトJIS使ってればいーよ
0064デフォルトの名無しさん2010/06/03(木) 03:36:54
すんげー亀レスだったりレスつけすぎだったりだけど規制解除がうれしくてはしゃいでるだけだから許してちょ
あと、UCSってあんまり知らないんで誰か教えてちょ。あれは文字コード表なの？エンコーディングなの？
>>3
> ・UTF-8とインディアンの関係は？
まず、インディアンじゃなくてエンディアン。そしてUTF-8ではエンディアンは関係ない。
>・UnicodeとUTF-8が別モノなのにBOMがUnicodeのしるしというのがよくわからない
Unicodeのしるしというよりも、UTF-8のしるし。昔、HTMLで文字コードをうまく認識させるために上の方に
<!-- あ -->
って書くって小ワザが使われていた時期があったんだが、それと同じようなもの。

>>4
>BOMはUnicode（≒UTF-16と思っていいか？）には必須
なくてもいい。あったら簡単に判別できるよってだけ。
Unicode≒UTF-16は、実質そうなのだけど、あえてそう思わないようにしたいところ。

"≒"って書いてあるのでサロゲートペアは考えないことにする。
UTF-8とかのテキストエンコーディングを知る上で重要になる、文字コード表+コード変換規則という組み合わせを大事にしたい。
UTF-16はあえて「数字をそのまんま返す」という変換をしていると考える。あるいは、コード変換規則はバイト列から表番号への型変換だと考えてもいい。

>>55
わずかに、日本じゃeuc-jpが使われてて、韓国じゃeuc-krが使われてるだけ。
両者に互換性はないし、他の非ASCII文字が必要な国ではまた別の文字コードが使われてるし、世界支配には全然至らない。

例えば、俺が何かソフト書くとき、日本語には対応させる気になっても、手間かけてまで中国語・韓国語には対応させたいとは思わない。
多分、アメリカ人から見たら、わざわざ手間かけて日本語、中国語、韓国語に対応したいとは思ってないんだろう。

Unicodeは、その手間を最小限に抑えられる。
もともと特殊な文字コードが必要なら、Unicodeを使えば勝手に世界中の言語に対応してくれることになる。
そういうのが不用なアメリカ人だって、Unicodeにさえしてくれれば世界中の言語に対応したのを作れるといったら、それくらいの手間はかけてくれるかもしれない。
0065デフォルトの名無しさん2010/06/03(木) 06:47:00
知ってるぜ。昔HTMLで文字コードを認識させるために
<!-- 美乳 -->
って書いたんだよな。他人が見たらびっくりだ

> UCSってあんまり知らないんで
たふん
　UCS→規格ISO/IEC 10646のこと
　UCS-2/UCS-4→テキストエンコーディング
UCSの文字集合は、何だろうね。規格で定められているのかな。
0066デフォルトの名無しさん2010/06/03(木) 09:31:39
UTF-8のプレーンテキスツで利用させてもらうわ「美乳」
0067652010/06/03(木) 13:20:36
>>66
すまん説明が悪かった。
EUC-JPのHTMLページを文字化けさせない時に「美乳」を使う。
UTF-8ならBOMがあればいいでしょ。
0068デフォルトの名無しさん2010/06/03(木) 17:56:40
>>65
UCSは文字集合で、エンコーディングじゃ無いよ。
0069デフォルトの名無しさん2010/06/03(木) 21:32:43
ホームページのファミコン.icoだかfamicon.icoってなに?
0070デフォルトの名無しさん2010/06/03(木) 22:04:03
faviconだろ
0071デフォルトの名無しさん2010/06/03(木) 22:07:46
ｆａｖｏｒｉｔｅ　ｉｃｏｎの略だろ。
お気に入りに追加するときに自動的にダウンロードされる。
0072デフォルトの名無しさん2010/06/03(木) 22:27:36
ていうか、unicodeどころか文字ですらない。
0073デフォルトの名無しさん2010/06/04(金) 19:08:15
そういやSolarisってUCS-4なのな。
マイクロソフトも もう少しUnicode対応が遅ければUTF-32採用されていただろうに。
0074デフォルトの名無しさん2010/06/05(土) 03:51:23
UCS-4 or UTF-32の何がそんなに嬉しいのかね。
コードポイントは32bitの固定長だけど、
どのみち結合文字があるから1文字は可変長なのにね。
0075デフォルトの名無しさん2010/06/06(日) 04:41:01
一文字何バイトにしようと
半角カナの濁点や合成用濁点をその前の仮名文字と組み合わせる必要が
なくなるわけじゃないのにね。
0076デフォルトの名無しさん2010/06/06(日) 06:42:54
読めない読む必要のない言語はトーフで十分なんだから
末端ユーザの文書なんて不可逆にEUC等のローカルコードに変換して保持すりゃ十分だよne
0077デフォルトの名無しさん2010/06/06(日) 06:43:58
Unicode←→EUC-JPの変換がどれだけ地雷原なのかも知らんのか…
0078デフォルトの名無しさん2010/06/06(日) 09:53:54
>>76
その文書を入力として読み込むことがないのなら。
入力しなけりゃ、二度と出力もできないが。
0079デフォルトの名無しさん2010/06/06(日) 10:18:53
>>77
unicodeに戻す必要があるのならね
0080デフォルトの名無しさん2010/06/06(日) 10:43:25
>>74
code pointとgraphemeの区別が付いていないんだろうね。
文字として扱う場合はいずれにしても可変長処理になるから、UTF-16の
サロゲートペアとかも些末な問題なんだけど、延々的外れな主張が繰り返される。
0081デフォルトの名無しさん2010/06/06(日) 11:37:03
>>77
マッピングテーブル2回通すだけだろ
0082デフォルトの名無しさん2010/06/06(日) 11:44:02
>>81
そのテーブルが問題なんだよ
0083デフォルトの名無しさん2010/06/06(日) 11:59:58
FirefoxからEUC-JPの掲示板に投稿すると一部の文字がIEで読めなくなるとか
Safariから円記号を投稿すると文字化けするとか
いずれもUTF-8なら問題ない
0084812010/06/06(日) 22:10:50
>>82
何か問題ある？
UTF-32→(普通のマッピング)→SJIS→(IBM拡張をマッピング)→SJIS→(計算式)→JIS→(計算式)→EUC
でしょ。
一つ目のテーブルはUnicodeコンソーシアムのtxtファイルからソース生成した。
二つ目のテーブルはシコシコと自作した。
0085デフォルトの名無しさん2010/06/06(日) 22:26:20
EUC-JPはいらない子過ぎる･･･
0086812010/06/06(日) 22:27:45
ああ思い出した。マッピングテーブル作る時に「X 0208」「NEC特殊」「NEC選定IBM拡張」「IBM拡張」
とマッピング先が複数候補有るので小細工が必要だったかも。
どの文字領域で重複してるか一文字ずつ調べてく単純作業が必要だった。
計算式と一般公開データだけでできると思ったら確実にはまるね。
0087デフォルトの名無しさん2010/06/06(日) 23:06:38
フロントエンドプロセッサを日本語に訳すと?
0088デフォルトの名無しさん2010/06/07(月) 00:07:36
前の方を処理してくれる女
0089デフォルトの名無しさん2010/06/07(月) 07:46:06
>>86
Shift-JISとCP932でマッピングが違う記号がいくつかあるし
0090デフォルトの名無しさん2010/06/07(月) 13:32:29
イミフメ。CP932がシフトJISじゃないとでも？
0091デフォルトの名無しさん2010/06/07(月) 13:41:05
￡がU+00A3になったりU+FFE1になったりして困った経験がないんだろうな
0092デフォルトの名無しさん2010/06/07(月) 13:44:23
色色問題あるけど、代表はasciiのバックスラッシュをJISの円記号と解釈する(cp932)かJISのバックスラッシュと解釈する(sjis)かだな。
0093デフォルトの名無しさん2010/06/07(月) 16:08:34
おまいらの言う「sjis」って何よ？
JIS X 0213に\(5Ch)をUnicodeのどの文字にマッピングするかなんて書いてあったっけ？
0094デフォルトの名無しさん2010/06/07(月) 16:33:29
お前ら本当にUnicode好きだな。
そろそろ次スレ立てるか？
スレタイは「Unicode総合スレU+0003」
0095デフォルトの名無しさん2010/06/07(月) 19:07:09
お前３行目言いたいだけだろ
0096デフォルトの名無しさん2010/06/07(月) 21:31:22
お
そ
ス
0097デフォルトの名無しさん2010/06/20(日) 00:17:09
誰もCP932と「sjis」の違いを説明できないんですね。残念です。

で「sjis」って何よ？
定義は？
0098デフォルトの名無しさん2010/06/20(日) 01:03:23
sjisはJIS X 0208:1997のシフト符号化表現
cp932はANSIコードページの932
規格が違う、としか言いようがない。
日本のチョコレートがベルギーではチョコレートとみなされなかったりするのと同じようなもんだ。
0099デフォルトの名無しさん2010/06/20(日) 02:22:52
ttp://ja.wikipedia.org/wiki/Microsoft%E3%82%B3%E3%83%BC%E3%83%89%E3%83%9A%E3%83%BC%E3%82%B8932
【SJIS】
Shift_JISの短縮形

【Shift_JIS】
「シフトJIS」のIANA登録名。

【シフトJIS】
JIS X 0208符号化文字集合を一定の規則に従ってシフトした文字符号化方式。

【CP932】
MS-DOSと Windowsにおける日本語コードページを表す用語。
「Windows-31J」が制定されるまでは、OEMベンダによって文字集合が違う。

【Windows-31J】
Windows 3.1(J)のリリースに合わせて、マイクロソフトがIBMとNECのコードを
統合して作った符号化文字集合。

まとめ：
・SJIS
　… 狭義ではJIS X 0208:1997のシフト符号化表現のこと。
　　　広義ではシフトJIS系文字コード全般を指す。(CP932も含む)

・CP932
… DOSやWinにおいて、日本語コードページを指す用語。
　　Win3.1以降ならその実体はWindows-31Jだが、古いverやDOSでは
　　バージョンにより実体が異なる。

これでどうでしょ。
間違ってたら適当に修正よろ。
0100972010/06/20(日) 02:37:16
>>98,99
そのJIS X 0208にUnicodeとのマッピングが書いてあるのかよ。話をすり替えるな。

俺はJIS X 0213とhttp://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
ぐらいしか知らない。
>>89の言う「Shift-JISのマッピング」って一体何なのよ？
0101デフォルトの名無しさん2010/06/20(日) 03:03:44
そういや、なんで異字体セレクタって後置なの？
前置にしとけば、何か漢字1文字読んだ後に異字体セレクタなんて付いてない可能性高いのに
念のためもう1文字読む、という手間が省ける気がするのだが。
0102デフォルトの名無しさん2010/06/20(日) 03:10:06
>>100
いや、誰がどう言おうと、sjisの定義はそれなんだから仕方ない。
>>89が言いたかったのは波ダッシュ問題のことだとは思うけど、
それはsjisの定義そのものとも、sjisとは何かとも関係がない。
0103デフォルトの名無しさん2010/06/20(日) 03:12:52
>>102
いや、関係ないは言い過ぎだな。
sjisがJIS X 0208:1997に完全に基づいてるとしたら、それをUnicodeに変換するときは
JIS punctuationに従うって考えるのが自然だろうし。
01041002010/06/20(日) 03:52:34
>>101
付随する物が基本となる物に続くのが論理的、とかフォントレンダリングが単純化される、
みたいな言い訳が2.11章に書いてあった気がする。

>>103
「JIS Punctuationに従う」って何？
「sjis」とUnicodeとのマッピングがどこに書いてあるのか、具体的に教えてくれ。
0105デフォルトの名無しさん2010/06/20(日) 07:35:23
>>104
>「sjis」とUnicodeとのマッピングがどこに書いてあるのか、具体的に教えてくれ。

規格化されていないのでどこにも書いてない。
0106デフォルトの名無しさん2010/06/20(日) 08:28:19
CP932
ttp://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT

JIS X 0208とShift-JIS
ttp://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/
0107デフォルトの名無しさん2010/06/20(日) 12:41:09
>>104
> 付随する物が基本となる物に続くのが論理的、とかフォントレンダリングが単純化される、
なるほど。
けど論理性はともかく、レンダリングが単純化されるって、どういう風にされるんだ？

> 「sjis」とUnicodeとのマッピング
よくわかんないけど、sjisがjisをシフトさせたもので、unicodeにjisとunicodeの対応があるんだったら、
sjisをjisに変換してjisをunicodeに変換したものがマッピングに当たるんじゃないの？
>>105の言う通り、規格化はされてないようだから、それで納得できない人もいるかもしれないけど。

> 「JIS Punctuationに従う」って何？
だって、JIS PunctuationのWAVE DASHに対応する文字がjisの中にないとおかしいじゃん。
だったら、sjisの中にWAVE DASHに対応する文字がないとおかしいじゃん。
unicodeの規格には「ないとおかしい」って書いてないだろうから、なくてもいいのかもしれないけど。
0108デフォルトの名無しさん2010/06/20(日) 19:08:06
>>106
obsoleteかよ。しかも半角円記号がA5にマッピングされてるじゃねーか。
そんな実装存在すんの？

>>107
>>89,91,92の言うsjisのマッピングって、存在するかどうか怪しい>>106のことなのか？　空想乙
0109デフォルトの名無しさん2010/06/20(日) 19:29:48
>>108
>>91-92は存在するか検証可能だろ。波ダッシュ問題見逃してるのはなんでか知らないけど。

{sjis, cp932}からunicodeじゃなくてutf8から{sjis, cp932}だけど。
iconv (GNU libc) 2.9
Copyright (C) 2008 Free Software Foundation, Inc.
使って波ダッシュを変換。マイナーな処理系だと言うなら、勝手に言うがよろし。

$ echo ～ | iconv -f utf8 -t cp932 | od
0000000 060201 000012
0000003
$ echo ～ | iconv -f utf8 -t sjis | od
iconv: 位置 0 で不正な入力シーケンスがありました
0000000
0110デフォルトの名無しさん2010/06/20(日) 20:16:15
>>109
波ダッシュ変換して何がうれしいのか。

今度は「sjisのUnicodeマッピングとはiconvコマンドの実装のこと」ですか。
よくもまあ言うことがコロコロ変わるもんだ。

ついでにそのiconvは半角￥をA5に変換するのかな？

最初から「cp932以外はマッピングが規格化されてないのでcp932とそれ以外のシフトJIS系実装でマッピングが異なる」って言えばいいんだよ。
0111デフォルトの名無しさん2010/06/20(日) 20:21:04
なんで「俺様のまとめ」を、他人に最初から要求するんだろうこういう馬鹿って
0112デフォルトの名無しさん2010/06/20(日) 20:38:46
まとめを要求したいのではなく89と91の表現が不適切だと言いたいのではないだろうか。
110(=90?)はCP932もシフトJISだと言いたいんだろう。

確かにsjisのUnicodeマッピングは定義が曖昧すぎる。
0113デフォルトの名無しさん2010/06/20(日) 21:57:57
>>110
え？うれしくないの？超うれしいじゃん。

> よくもまあ言うことがコロコロ変わるもんだ。
もともと俺、sjisのunicodeマッピングが何かについては言及してなかったんだけど、誰と勘違いした？

> ついでにそのiconvは半角￥をA5に変換するのかな？
ならなかったけど、人の言ったことにまで責任は取らない。
手順もソフトも覚えてないが過去になったことはあるけど。

> cp932以外はマッピングが規格化されてないのでcp932とそれ以外のシフトJIS系実装でマッピングが異なる
明らかな間違い。規格化されていないことは、マッピングが異なる理由ではない。
011499 ◆SmULsZQKBg 2010/06/22(火) 00:43:33
相手を誰かと買い違いして、喧嘩腰になってる方が見受けられるのでトリ付けた方が良いかも。

散々問題になってる>89は、>81を
　「X 0208」「NEC特殊」「NEC選定IBM拡張」「IBM拡張」 → CP932 (=Windows-31J)
と解釈した上で、Shift-JIS（=JIS X 0208）という別のキャラセットもあると述べてるだけかと。
（両者は別のキャラセットとして、IANAに別個に登録されてます。）
具体的に何が問題になるかも、>92で示されてます罠。
011599 ◆SmULsZQKBg 2010/06/22(火) 00:44:44
訂正。>81じゃなくて>86ですね。同一人物ですが。
011699 ◆SmULsZQKBg 2010/06/22(火) 00:54:25
今更ながら>77の言う「地雷」の意味が何となく分かった。
ttp://ja.wikipedia.org/wiki/EUC-JP

>84の変換方法だと、Windowsなら良いかもしれないけど
他で問題がありそうな予感が。（検証してないけど）
0117デフォルトの名無しさん2010/06/22(火) 08:42:27
おかしい人は相手をせず放置するのがいちばんですよ。

でもここはおかしい人隔離スレかw
0118デフォルトの名無しさん2010/06/23(水) 08:36:14
>>114
待て待て。Shift-JISはIANAに登録されていないし、IANAはUnicodeとのマッピングは定めていないぞ。
話と関係なくね？
0119デフォルトの名無しさん2010/06/23(水) 09:02:52
規格化されてないなら、デファクトスタンダードな処理系を基準にするしかないじゃん。
そしたら結局のところ、sjisとcp932はマッピングが違う、という最初から出てた話に。
0120デフォルトの名無しさん2010/06/23(水) 18:25:46
そうしたら>>90がまた「cp932もsjisだ」って言い出すだろ。
それともsjisのデファクトスタンダードって何かあるの？
0121デフォルトの名無しさん2010/06/23(水) 18:39:42
PC9801のROMに入ってるか否かだ
0122デフォルトの名無しさん2010/06/23(水) 23:15:53
PC9801のROMにIBM拡張漢字は入ってないぞ
初代には第二水準漢字すら入ってなかった
0123デフォルトの名無しさん2010/06/23(水) 23:40:12
>118
ttp://ja.wikipedia.org/wiki/Shift_JIS
「Shift_JISの標準化」の項
IANAも「Shift_JIS」という名前で登録している。

でもよく読むとX0208じゃなくてX0213の方なのかな?
0124デフォルトの名無しさん2010/06/24(木) 00:03:25
>>123
sjisそのものは標準規格があるけど、sjisをunicodeに変換する方法については規格がない、という話。

>>120
デファクトスタンダード選ぶなら、GNU iconv以上にメジャーな処理系ってなに？
0125デフォルトの名無しさん2010/06/27(日) 01:21:33
>124
sjis-Unicodeのマッピングが公式に定義されて無いのは別に否定してませんが…
ただ「sjis」という文字とコードのマッピング（要はキャラセット）はIANAに登録されてるでそ。
それを無いとか言うもんだから>123を提示したまでですが。

あとメジャーかどうか知らないけど、IBMがICUっての公開してますよ。>処理系
0126デフォルトの名無しさん2010/06/27(日) 02:13:15
>>125
ちゃんと読もうよ。
わかんないことには口を出さないこと。
勘違いしてたのなら素直に謝ること。
それだけだよ。
0127デフォルトの名無しさん2010/06/27(日) 09:44:14
JIS X 0208:1997の附属書1は規格じゃないの? 「規定」って書いてるんだけど。
標準じゃなくてガラパゴスだとか?
0128デフォルトの名無しさん2010/06/27(日) 14:45:37
>>125
sjisとShift-JISとShift_JISを一緒にしないでくれ。IANAに登録されているのはShift_JIS。

>>124
また話がループするようなことを。規格化されているのはShift_JISX0213。
断じてsjisではない。
0129デフォルトの名無しさん2010/06/27(日) 15:10:13
>>123
X0201とX0208だよ。
http://www.iana.org/assignments/character-sets

>>124
デファクトスタンダードはやっぱりJavaでそ。
0130デフォルトの名無しさん2010/06/27(日) 20:00:00
>>128
それに関しては、もはや揚げ足取りではないのかい？
cp932とShift_JISX0213は別物だが、sjis, Shift_JIS, Shift-JIS, shiftjis, ... を
Shift_JISX0213の通称として扱っていいんじゃないの。

それともShift_JISX0213と別物で、よく似た名前の別規格or独自仕様って何かある？
01311282010/06/27(日) 22:38:28
>>130
揚げ足を取るつもりはないけど。
少なくともShift_JISはIANAに登録されていて別格。狭義のシフトJISを指す。
それに対しsjis,Shift-JISは定義の無い通称で、広義のシフトJISでは？
両者は明確に区別されるべきだと思う。
少なくとも>>99のSJISがShift_JISの略っていうのは嘘。
0132デフォルトの名無しさん2010/06/27(日) 23:03:12
>128
そこまでの厳密さを求める割に、IANAに登録されてる/されてないという流れに対して、
「Shift_JISX0213」を持ち出すのはおかしいと思わないのかい。
それJISでは正式採用されてても、IANAじゃまだドラフトのはず。
0133デフォルトの名無しさん2010/06/28(月) 03:14:55
>>131
Shift_JISって名前出しつつIANA Shift_JISと別のエンコーディングの話する場合はないといえるのかい？
俺と君との2人だけの議論だったら、単語の使い方を明確にしておくのは有効だろうが、
何人いるのかも分からないし、そのうち何人が全部のレス読んでるか分からない、単発ばかりかもしれない場所でそれをやってもろくなことにならないと思うよ。

できる限り、文脈で判断して、違いを分かってる人は必要に応じて明確に違いを明示した言葉遣いをするのが一番マシだと思うんだ。
0134デフォルトの名無しさん2010/06/28(月) 11:17:31
unicodeと関係ない話は他でやってくれ。
わかったのはCP932以外のシフトジス系はunicodeとの対応が規格化されていないってことだ。
0135デフォルトの名無しさん2010/06/28(月) 11:21:55
X0208←→Unicodeが存在して、X0208←→シフト符号化表現が存在するのに、
シフト符号化表現←→Unicodeが存在しないとはこれいかに？
0136デフォルトの名無しさん2010/06/28(月) 12:31:41
なんでこう、脊髄反射するんだろうな。
0137デフォルトの名無しさん2010/06/28(月) 13:53:54
やけどしないように、かな
0138デフォルトの名無しさん2010/06/28(月) 21:00:17
脊髄反射した結果、炎上してるのになぁ。
反省とかしないのかね。
0139デフォルトの名無しさん2010/06/28(月) 21:44:51
>>135
X 0208←→Unicodeは何処に書かれてるの？おせーてくださいまし。
あとX 0201の存在もお忘れ無く・・・
0140デフォルトの名無しさん2010/06/28(月) 21:44:58
>134は「規格」を「IANAのobsoleteではない規格」に限定しないと、真にならんかと。
0141デフォルトの名無しさん2010/06/28(月) 23:17:23
>>140
IANAじゃなくてUnicodeコンソーシアムのまちがいだよね？
あとobsoleteじゃないってのはデフォかと。
0142デフォルトの名無しさん2010/06/29(火) 02:29:00
なんだ、そしたらもう、cp932は規格通りにUnicodeと変換可能だけど、
Shift_JISもiso-2022-jpもUnicodeと変換する規格なんてないからUnicode化は諦めたらいいんじゃないの。
0143デフォルトの名無しさん2010/06/29(火) 03:00:59
まあそうだな。だから>>110みたいな意見が出て来るし、実際に実装が乱立している。
>>113はどのあたりが間違いだと言ってるのか気になるけど。
0144デフォルトの名無しさん2010/06/29(火) 03:03:36
>>143
「規格化されていないことは、マッピングが異なる理由ではない」 って書いてあるじゃん。
0145デフォルトの名無しさん2010/06/29(火) 03:05:04
>>143
ついでに、ここで「だから」という文脈で>>110を出してくるのはおかしい。
0146デフォルトの名無しさん2010/06/29(火) 03:13:54
お前ら規格にこだわりすぎ。規格がなければ変換できないかのように言うのはミスリーディング。
>>142とそれに賛同してる奴は、本気で書いてるとすればキチガイに近いレベルのバカだ。

例えば上でiconvが出てたが、あれは規格がなくてもできてる。
いくつかの記号では実装によって食い違いが出るかもしれないが、それが一体何だって言うんだ？
cp932
0147デフォルトの名無しさん2010/06/29(火) 03:14:59
すまん。途中でかいてしまった。

cp932じゃなくShift_JISで書かれた文章なんて、そんなに数ないだろうに。
0148デフォルトの名無しさん2010/06/29(火) 03:57:16
>>144
じゃあOracleのSJISとJavaのSJISでマッピングが異なるのは何故なの？　きちんと規格化されてないからじゃないの。　

>>146
いや規格化されていないと困るだろ。マッピングが異なるなんて致命的。
0149デフォルトの名無しさん2010/06/29(火) 09:59:33
だからその致命的なことがすでに世の中に蔓延していますよ、というのが現実なのだがw
0150デフォルトの名無しさん2010/06/29(火) 21:18:07
>148
>じゃあOracleのSJISとJavaのSJISでマッピングが異なるのは何故なの？　きちんと規格化されてないからじゃないの。　
各々の環境で「SJIS」が指してる規格が違うだけかと。
OracleはX0208（cp932にも変更可）で、Javaはcp932らしい。
ttp://otndnld.oracle.co.jp/skillup/oracle9i/1_1/index.html
ttp://www.ingrid.org/java/i18n/encoding/shift_jis.html
まぁ最初からきちんと規格化されてりゃ、こんな事にはならなかったんだろうけど。
0151デフォルトの名無しさん2010/06/29(火) 21:28:46
>OracleはX0208（cp932にも変更可）
すんませんこれエンコーディングとしてcp932も選べるってだけですね。
SJISの実体をcp932に定義できる、とも読めてしまう気がしたので念のため訂正。
0152デフォルトの名無しさん2010/06/30(水) 00:11:26
>>148
例えば、OracleのSJISが規格化されたとしたら、cp932とOracle SJISのマッピングは同じになると思うかい？
>>110が書いたのはそういうこと。

>>148
君は、PC(サーバとかじゃなくてPCだぞ)を使う上で1byteの大きさが決まっていなくて困ったことはあるかい？
例えば、この文章をUnicodeに変換するとして、何が致命的になりうる？
0153デフォルトの名無しさん2010/06/30(水) 02:41:09
>>150
違うぞ。
OracleのSJISはCP932から「～」の一文字だけ異なる独自マッピング。
JavaのSJISはCP932とはほど遠い、iconvのsjisに近いマッピング。
規格化なんて何処にもされていない。

>>148
もし規格化されてたら同じになったんじゃない？
たった１文字だけ違うなんてなかっただろう。
0154デフォルトの名無しさん2010/06/30(水) 09:49:58
>>153
今のをそのまま規格化したとしたら？
0155デフォルトの名無しさん2010/07/02(金) 12:03:20
UTF16の1文字で表した年号って今後の年号のために
4つくらい予備をとってあるんだね。
とはいえ、これ残してると後々困ることが起きそうだねー。
結構使われてたりするんだろうか。
0156デフォルトの名無しさん2010/07/02(金) 12:06:34
予備はもう全部使いきったんじゃなかったっけ。

0157デフォルトの名無しさん2010/07/02(金) 13:56:04
UTF16の、って意味わかんないんだが。
エンコーディングを指定する意味は？
0158デフォルトの名無しさん2010/07/02(金) 18:25:49
♡
こーゆー文字を書くためのコードはどこに載ってるの?
0159デフォルトの名無しさん2010/07/02(金) 18:59:06
ttp://www.unicode.org/
0160むぎゅう2010/07/02(金) 19:11:12
>>157
細けーこたー(略

>>158
http://www.unicode.org/Public/5.2.0/charts/CodeCharts-noHan.pdf
10進16進の変換は自分でやれ。
0161デフォルトの名無しさん2010/07/02(金) 21:04:21
pdf・・・
0162デフォルトの名無しさん2010/07/02(金) 21:27:00
utf・・・
0163デフォルトの名無しさん2010/07/05(月) 04:13:53
なんで2chはシフトジスなのに改行はラインフィードのみなの?
0164デフォルトの名無しさん2010/07/05(月) 08:01:55
こっちはUnicodeスレかと思ったらそうでもないのね。
0165デフォルトの名無しさん2010/07/05(月) 10:06:08
>>163
sjis使ってることと改行コードは関係ないよ。2chのサーバがUnixだからだろうけど。
0166デフォルトの名無しさん2010/07/05(月) 14:59:38
改行コード1バイトにするだけで10%近く圧縮されるからな
0167デフォルトの名無しさん2010/07/05(月) 16:15:17
それで、SJISとUTF-8の圧縮率の話に戻って・・・
0168デフォルトの名無しさん2010/07/05(月) 16:52:56
1バイトが0~255の範囲を満遍なく使ってるかどうかで言うと
SJISよりもUTF-8の方が使用効率が良いので
単純に3/2という訳にもいかんのよ
0169デフォルトの名無しさん2010/07/05(月) 19:50:25
だってシフトジスはウィンドウスが創作したわけだからCrLfだろJk
0170デフォルトの名無しさん2010/07/05(月) 19:53:30
あらあら小学生の来るところじゃありませんよｗ
0171やんやん ◆yanyan72E. 2010/07/05(月) 20:04:09
CP/Mが起源じゃないの？
0172デフォルトの名無しさん2010/07/05(月) 20:28:25
プリンタとかではCRとLFが別々に必要だからな
0173デフォルトの名無しさん2010/07/05(月) 21:18:23
>>164
文字コードと改行コードの話はキチガイ信者が集まるものだよ。
ネットニュースのうさげの時代からずっと。
そんな人達の隔離スレがここゆっくりしていってね
0174デフォルトの名無しさん2010/07/05(月) 21:34:57
>>173
これまた懐かしい話を。
じゃぁ半角カナもここ？
0175デフォルトの名無しさん2010/07/06(火) 00:20:04
>>168
満遍なく使うことだけじゃ、効率のよさの証明にはならない。

例えば次のようにしたら、ASCIIコードから、効率は悪いが範囲を満遍なく使う文字コードへの変換ができる。
00 -> 00 01 02 03 ... FF
01 -> 01 00 02 03 ... FF
...
FF -> FF 00 01 02 ... FE
0176デフォルトの名無しさん2010/07/08(木) 13:06:30
>>174
半角ってなんですか?
0177やんやん ◆yanyan72E. 2010/07/08(木) 13:48:06
文字化けしてますよ。
0178デフォルトの名無しさん2010/07/08(木) 23:58:14
>>176
45°
0179名無しさん＠そうだ選挙に行こう2010/07/10(土) 22:47:35
>>176
JIS X 0201片仮名用図形文字集合のことだ氏ねバーカ日下部もどきが。
0180名無しさん＠そうだ選挙に行こう2010/07/10(土) 22:53:16
そういうことにしたいのですね:)
0181名無しさん＠そうだ選挙に行こう2010/07/11(日) 09:19:04
はつみみです
0182名無しさん＠そうだ選挙に行こう2010/07/11(日) 12:28:18
4倍角ってなんすか
0183名無しさん＠そうだ選挙に行こう2010/07/11(日) 15:02:27
昔むかしガラパゴス島にワープロ専用機という珍種がおっての。
0184名無しさん＠そうだ選挙に行こう2010/07/11(日) 16:17:41
倍角　　　ネ申

4倍角　　　イ立　　々
　　　　　　　｜口　　門
0185名無しさん＠そうだ選挙に行こう2010/07/11(日) 18:44:42
>183

ttp://ja.wikipedia.org/wiki/%E3%83%AF%E3%83%BC%E3%83%89%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B5
世界初のワードプロセッサは、1964年のIBM MT/STで、
その後もワング・ラボラトリーズ社などからいくつか
英文ワープロ専用機が登場した。
0186デフォルトの名無しさん2010/07/12(月) 18:32:32
http://pc12.2ch.net/test/read.cgi/tech/1278923059/ 文字コード総合スレ part6
建てるの忘れてた。スマソ
0187デフォルトの名無しさん2010/07/14(水) 22:55:43
ここは隔離スレだったのか。
void的にUnicodeの『Halfwidth』はどうなんだろ。あとPC9821に「2バイト半角カナ」とかあったよなぁ
0188デフォルトの名無しさん2010/07/15(木) 10:36:50
ヘミ猫はmixiに生息しているのですか？
0189デフォルトの名無しさん2010/07/15(木) 23:35:42
voidなら最近はtwitterだね。
0190デフォルトの名無しさん2010/07/16(金) 01:15:54
>>189
はつみみです
0191デフォルトの名無しさん2010/07/17(土) 08:35:42
くそかべととりまきチネ
0192デフォルトの名無しさん2010/07/17(土) 09:33:01
ascii-netの時代からそうだけど、取り巻き認定ほど無意味なものはないのに未だに気付けない連中が沸くんだな。
0193デフォルトの名無しさん2010/07/17(土) 09:50:49
怒ってた猫が急に話しかけて来たけど、ヘミ猫語だからわからない
http://www.nicovideo.jp/watch/sm11126185
0194デフォルトの名無しさん2010/07/17(土) 10:44:28
mixiで暴れてたと思ったら
今はtwitterでも暴れてんのかw
常に時代の最先端を行く奴だな
0195デフォルトの名無しさん2010/07/17(土) 13:28:12
voidはUnicodeという時代の流れについてゆけず、単なるアラシと化しました
0196デフォルトの名無しさん2010/07/17(土) 16:31:58
>>187
http://groups.google.com/group/fj.kanji/browse_thread/thread/ffb260159ecd663e
0197デフォルトの名無しさん2010/07/20(火) 08:42:28
>>192
Unicode時代になっても、あいかわらず馬鹿のやることはワンパターンだよな
0198デフォルトの名無しさん2010/07/20(火) 09:35:19
個人スレが立っている。秀丸に対するありがたいお言葉が。
0199デフォルトの名無しさん2010/07/22(木) 20:30:43
キャラクターってなに?
0200デフォルトの名無しさん2010/07/22(木) 23:09:35
>>199
つhttp://www.unicode.org/versions/Unicode5.2.0/ch02.pdf
2.2 Characters, Not Glyphs
0201デフォルトの名無しさん2010/07/22(木) 23:49:42
>>199
「ATOKを入れてませんか? 」とかアンサイクロに書いてある。
0202デフォルトの名無しさん2010/07/29(木) 14:10:57
また強制退会処分の模様
0203デフォルトの名無しさん2010/07/29(木) 14:19:52
横浜退会決勝は雨で延期
0204デフォルトの名無しさん2010/08/02(月) 06:17:39
>>200
そこには、

Letters in different scripts, even when they correspond either semantically or
graphically, are represented in Unicode by distinct characters. This is true even in those
instances where they correspond in semantics, pronunciation, or appearance
.
とあるから、Han Unificationの正当化のためにはscriptの違いをlanguageの違いだと
主張しなきゃいけなくなって、傷が広がってるだけ
0205デフォルトの名無しさん2010/08/02(月) 19:14:55
scriptとlanguageは関係ない。
0206デフォルトの名無しさん2010/08/04(水) 05:33:35
Letters in different scripts, even when they correspond either semantically or 
graphically, are represented in Unicode by distinct characters.

と、はっきりscriptsと書いてある文書を得意げに紹介しといて、都合が悪くなると「関係
ない」ってか
0207デフォルトの名無しさん2010/08/04(水) 13:24:56
scriptsの違いってのはLatinとかCyrillicとかそういうレベルの話
Latin scriptは英語でもフランス語でもドイツ語でも使われるんだから
言語とはイコールじゃない
0208デフォルトの名無しさん2010/08/05(木) 08:29:42
どうでもいいけど日本語に訳してくれよ
0209デフォルトの名無しさん2010/08/05(木) 14:09:01
文字セットと言語の話？
0210デフォルトの名無しさん2010/08/07(土) 00:35:00
>>207
>Latin scriptは英語でもフランス語でもドイツ語でも使われるんだから 

Latin scriptは日本語でも使われるね

もしかして、言語が決まればscriptが決まるとか誤解はしてないよね

>言語とはイコールじゃない 

だから、漢文scriptを日本語で読み下すこともできるけど、同じ日本語を漢字仮名混じり
scriptで表現したものと漢文scriptとは、別のscriptってことになる

もちろん、scriptが違う漢文と漢字仮名混じり文の漢字は、対応はしても別の文字
0211デフォルトの名無しさん2010/08/07(土) 02:28:36
きちがいあらわる
0212傍観者2010/08/07(土) 13:39:14
>210
>>Latin scriptは英語でもフランス語でもドイツ語でも使われるんだから
>
>Latin scriptは日本語でも使われるね
>
>もしかして、言語が決まればscriptが決まるとか誤解はしてないよね

なんかいちゃもんつけるために、意図的に拡大解釈してないかこの人。
結論自体は>207を言い直してるだけだし。
0213デフォルトの名無しさん2010/08/10(火) 14:00:53
http://twitter.com/void_No3/status/20745513220
> WebサイトShift_JIS使用は法律で禁止すべきだ!
0214デフォルトの名無しさん2010/08/10(火) 14:45:47
完全血出痔禍がかのうなんだから文字コード完全UTF-8化くらい簡単だろう
0215デフォルトの名無しさん2010/08/10(火) 15:36:08
Shift_JISは2011年7月24日で使えなくなります、とか？
0216デフォルトの名無しさん2010/08/10(火) 15:48:08
void先生！誰に言っているんですか！
http://twitter.com/void_No3/status/20773507133
> 『全角入力』なる変なのを要求するのやめてもらえませんか?
0217デフォルトの名無しさん2010/08/10(火) 15:53:11
そういうお前は誰に言ってるんだよw
ストーカー体質の奴って本当、自分を客観視できない馬鹿ばっかりだよな。
完全に狂ってる。
0218デフォルトの名無しさん2010/08/10(火) 15:53:23
でもこれは入力チェックの手抜きだよなあｗ
0219デフォルトの名無しさん2010/08/10(火) 17:05:29
客観視を気にするあまり主体性のかけらもないバカがたくさんいるけどなw
0220デフォルトの名無しさん2010/08/10(火) 22:00:25
おまいらすれ違い
http://hibari.2ch.net/test/read.cgi/tech/1179389033/
0221デフォルトの名無しさん2010/08/10(火) 22:09:11
どの住所入力でもぜったい全角入力を要求されるのはなんかの陰謀か。
0222デフォルトの名無しさん2010/08/10(火) 22:15:13
圧倒的多数のアホに合わせてるんだろ＞全角入力
0223デフォルトの名無しさん2010/08/10(火) 22:19:52
全角で入力しても半角で入力してもおkのほうがアホに優しいんじゃないか？
0224デフォルトの名無しさん2010/08/10(火) 23:10:06
今日初めてこのスレ見たけど、インディアンには笑った。
もう初心者は置き去りになってますね。
0225デフォルトの名無しさん2010/08/11(水) 10:12:16
そもそも1で終わってたのに、インディアンのためだけに2を立てたやつがいるんだよ
0226デフォルトの名無しさん2010/08/11(水) 14:36:52
UNIX厨必死だなｗ
0227デフォルトの名無しさん2010/08/11(水) 14:42:53
なんでそんなに必死なの？
0228デフォルトの名無しさん2010/08/11(水) 14:59:04
1文字が7ビットじゃないと動かないクソプログラムを大量にバラ撒き続ける
ＵＮＩＸ信者が必死にShift_JISを攻撃してるんだよな
0229デフォルトの名無しさん2010/08/11(水) 15:02:13
7bitじゃなければ駄目ならUTF-8でも駄目じゃないか
0230デフォルトの名無しさん2010/08/11(水) 15:13:41
ああそのとり。もちろんダメだよ。それが何か？
0231デフォルトの名無しさん2010/08/11(水) 15:22:50
7F は 7bit でおさまってるのに通らないんだぜ
0232デフォルトの名無しさん2010/08/11(水) 16:57:05
7Fって何？
0233デフォルトの名無しさん2010/08/11(水) 18:24:19
~
0234デフォルトの名無しさん2010/08/11(水) 18:28:55
>>229
UTF-7で。
0235デフォルトの名無しさん2010/08/11(水) 18:36:51
>>233
それって0x7Eじゃない？
0236デフォルトの名無しさん2010/08/11(水) 19:04:58
あ
そうだね
0237デフォルトの名無しさん2010/08/12(木) 10:05:09
1文字が７ビットな文化圏では「~」という文字は使用されてないよ
この文字は日本語ＯＳで使える文字
だから7ビットに収まってないんだよ
0238デフォルトの名無しさん2010/08/12(木) 10:16:12
>>237
そういえばそうだった。「半角」の話か。
0239デフォルトの名無しさん2010/08/12(木) 10:17:15
えっ
0240デフォルトの名無しさん2010/08/12(木) 10:24:35
チルダ・バックスラッシュの話でしょ。
0241デフォルトの名無しさん2010/08/12(木) 10:27:08
7階、家具売り場でございます
0242デフォルトの名無しさん2010/08/12(木) 11:37:36
Unixで${HOME}に展開される~は日本ローカルだったのか！


そんなわけないだろうw
0243デフォルトの名無しさん2010/08/12(木) 11:54:05
>>242
http://hibari.2ch.net/test/read.cgi/tech/1278923059/43-47
0244デフォルトの名無しさん2010/08/12(木) 15:42:59
>>242
ヒント：
ASCII,JIS,overline,フォント,101キーボード
0245デフォルトの名無しさん2010/08/12(木) 19:48:20
おそらく>>242は
「～」の半角と「￣」の半角の区別がついてない
0246デフォルトの名無しさん2010/08/12(木) 20:16:15
2chはSJISだそうだから半角チルダに見えても文句言えないんじゃなかったけ？
0247デフォルトの名無しさん2010/08/12(木) 21:30:44
7fの話から7eの話に脱線してるのか。
0248デフォルトの名無しさん2010/08/12(木) 22:13:25
javaのsjisとms932は、チルダとか数文字unicodeとのマッピングが違うけど、
その理由はなんでしょうか？
sjisはjis規格でms932はmicrosoftが決めたからとも聞いたのですが、
本当でしょうか？
0249デフォルトの名無しさん2010/08/12(木) 22:14:36
スレ違いです
0250デフォルトの名無しさん2010/08/12(木) 22:31:26
>>248
つ>>89-
0251デフォルトの名無しさん2010/08/12(木) 22:47:08
うーん。見てみましたが、どうもマッピングが違う理由がよくわからない。
マッピングの規格がないからと言うこと？
0252デフォルトの名無しさん2010/08/12(木) 22:52:35
うぜえ
0253デフォルトの名無しさん2010/08/12(木) 23:14:28
>251
ISO646を継承してるか否か。
0254デフォルトの名無しさん2010/08/12(木) 23:19:40
>>248
由仁子がバカだったから。
いいかげんマッピングをさらしやがって。
0255デフォルトの名無しさん2010/08/13(金) 21:31:50
>>212
>なんかいちゃもんつけるために、意図的に拡大解釈してないかこの人。 

意図的に議論を「英語でもフランス語でもドイツ語でも」と、都合のいいほうにだけ拡大
して誤魔化してるのがお前だろ

日本と中国の漢字を考えるだけで破綻してるのに

>結論自体は>207を言い直してるだけだし。 

207の結論は207の前提の真逆だのに、何が言いたい？
0256デフォルトの名無しさん2010/08/13(金) 23:02:13
>>248
嘘です。
Javaの「SJIS」というコンバータ（UnicodeとシフトJISとの変換ルール）はどこにも規格化されていません。Java独自です。
ms932はUnicodeコンソーシアムのCP932ルールを実装しているので規格化されていると言えるでしょう。
0257デフォルトの名無しさん2010/08/17(火) 05:50:04
>>251
深い理由はないです。無知とミスが積み重なった不幸から生じた歴史的経緯という負の遺産です。

具体的にはこのあたり参照
ttp://slashdot.jp/~yasuoka/journal/357074
0258デフォルトの名無しさん2010/08/17(火) 12:16:35
>>257
ミスがあったのはともかく、無知が積み重なったなんで何で言える？
自分の案と違う案をマイクロソフトが出したからマイクロソフトの案を理由もなく
「間違ってる」と批判しているだけの駄文。さすが安岡先生。
マイクロソフトからすれば前の案が間違っていると思ったから別の案を出しただけでは。
0259デフォルトの名無しさん2010/08/17(火) 13:43:03
おまえが間違ってる
0260デフォルトの名無しさん2010/08/17(火) 13:46:31
>>258
・FULLWIDTH なんたらは互換用途以外は使うべきでない
・Unicodeのグリフの例示は絶対ではない
ってのを知らない状態でつくったんだろうなってことで＞無知
0261デフォルトの名無しさん2010/08/17(火) 21:39:15
> 互換用途以外は使うべきでない
> 例示は絶対ではない

いや、それ知ってても、301Cが逆の波ダッシュでFF5EにJISと同じ例示の
波ダッシュがあったら普通(私だけか?)FF5E選ぶでしょう。
「互換用途以外は使うべきでない」のも絶対ではなく、こういうケース
にこそ使うべきだと思いますが。

いずれにせよUnicode規格に残ったのはFF5Eなんだし、自分の思う案が通ら
なかったら規格を無視しようなんて、わがままな子供みたい
0262デフォルトの名無しさん2010/08/17(火) 22:18:54
FF5E は最初から今に至るまで "TILDE" であって明らかに別の文字なので……
見た目できめるな意味できめろ、という Unicode の基本ルール知ってたらこれ例示がおかしくね？って問いあわせるだろって話。
「見た目同じだからこれでいいよね」は無知のなせる業だろう

まあ、そもそも、FULLWIDTH TILDE などという、互換対象になる文字がそもそも最初から
存在してない文字を登録したの誰だよって話かもしれん。それがなければ少し不幸が減っていただろう

互換用途の話はその部分じゃなくて ￠とか ￡ とかね。
POUND SIGN → FULLWIDTH POUND SIGN とわりあてられてしまっている。
0263デフォルトの名無しさん2010/08/17(火) 23:10:23
>>257の下の方読んだけど、平成3年の時点で既に8160←→U+FF5Eだったのね(Unicode 1.0)。
平成6年にX 0221やら『Shift-JIS to Unicode, Version 0.9』を出されても、平成5年に
Windows 3.1出したMicrosoftがU+301Cに変更するのは難しいね。
1.0にして道を間違えていたUnicode。
026412010/08/17(火) 23:30:43
話の流れをぶった切ってすみません。
スレタイの「Unicode」なんですが、「Unicode」が文字集合の一つだっていうのは
Unicode規格のどこに書いてあるんでしょうか？
026512010/08/17(火) 23:59:18
エンディアンについてはたいへんお世話になりました。インディアンはお恥ずかしい。
で、大体わかったつもりになったのですが、前スレ43の
> csUnicodeっていうISO-10646-UCS-2のIANA別名があって
を読んだらおやっと思ったのです。これって文字集合でなくエンコードでは？と。
0266デフォルトの名無しさん2010/08/18(水) 08:00:26
>>265
ここは隔離スレだそうだから本スレ行って聞いたら？
0267デフォルトの名無しさん2010/08/18(水) 10:17:04
1に対してそれを言うのかｗ
0268デフォルトの名無しさん2010/08/18(水) 21:39:00
文字コードは難しいな。
ネットで情報を集めても、微妙に間違っている(情報ソースによりまちまち）なものがあったりして、信用できない。
文字コードに携わる前は、unicodeは厳密なものだと思っていたが、方言と呼ばれているものがあったり、
実装によって変換方法が違っていたり、細かいところではぼろぼろなことがわかってきた。
unicodeのバイブル（?)の文字のイメージも違っているなどと言うことがあるんだとすると、
ますます何を信用していいのかわからなくなってくる。
0269デフォルトの名無しさん2010/08/18(水) 21:43:29
自分を信じろ
0270デフォルトの名無しさん2010/08/18(水) 22:29:36
インディアンしか信じられないでしょう。
インディアン嘘つかない。
0271デフォルトの名無しさん2010/08/22(日) 08:57:53
7Fはどうなった？
0272デフォルトの名無しさん2010/08/22(日) 11:45:13
>>271
7Fは>>236で7Ehの間違いだとして、
昔IBMのAIX使ってて文字コードがシフトJISだった。ホームは半角の￣で表示された。
これはフォントの問題だろうし、Unicodeに変換される時は大抵7Ehに変換される。
フォントの問題なので7ビット系はOKだろう。
0273デフォルトの名無しさん2010/08/22(日) 12:16:46
ちなみに7fはDELな。
0274デフォルトの名無しさん2010/08/22(日) 17:24:50
muleとかみたいに7Fとか1Bとか混ざってると落ちるソフトもあったなって話
0275デフォルトの名無しさん2010/08/26(木) 20:37:19
1Bって何？
0276デフォルトの名無しさん2010/08/26(木) 23:40:57
ESC
0277デフォルトの名無しさん2010/09/08(水) 18:38:27
ISO-2022で言語とか全角／半角を切り替えるために挿入されるエスケープシーケンスの先頭バイト。
1Bで落ちるってことは、muleはJISコードが扱えない糞ソフトなの？サイテー
まあ文書をISO-2022で保存しようなとどは思わないから別にいいけど。
0278デフォルトの名無しさん2010/09/08(水) 19:43:24
>>277
muleがそんなわけねえだろうが。
「多言語用emacs」だぞ。
0279デフォルトの名無しさん2010/09/08(水) 19:47:04
MS-DOSが登場してシフトJISが一般的になる前は
漢字のテキストファイルといえば
KI-KOコードのついたJISコードしか見たこと無かったけどな
0280デフォルトの名無しさん2010/09/09(木) 02:03:48
>>279
世間が狭かったんだね。
0281デフォルトの名無しさん2010/09/09(木) 02:43:22
そりゃ8bitじゃなくて7bitだからな
0282デフォルトの名無しさん2010/09/09(木) 10:34:48
その当時はPCじゃなくてオンライン端末だったしな
0283デフォルトの名無しさん2010/09/09(木) 11:12:00
JIS制定以前は各社独自の日本語バイナリファイルだから当然の事
0284デフォルトの名無しさん2010/09/09(木) 22:02:09
そういやJavaってまだBOM付きUTF-8が処理できないんだっけ？
java.exeの方は互換性が問題になるからともかく、コンパイラjavac.exeがNGなのは
一体何の嫌がらせなのか。
0285デフォルトの名無しさん2010/09/09(木) 23:19:54
世の中のほとんどのプログラミング言語はガイジン（欧米人）が作ってるからですよ。
日本だけを特別扱いするワケにはいかないんです。
彼らにとって、日本は取るに足りない、地球の裏側の、世界地図の端っこの小さな小さな国
でしかないんです。
だからBOMなんてどうでもいいんです。
嫌がらせとか、そんなんじゃないですよ。な～～んにも気にしてないだけですよ。
問題意識が全くないんですよ。
0286デフォルトの名無しさん2010/09/10(金) 02:26:05
ソースコードBOM付きで保管する香具師って馬鹿なの？死ぬの？
0287デフォルトの名無しさん2010/09/10(金) 02:30:25
BOMと日本語になんの関係が。
まぁ、メモ帳は死ね、と思うが。
0288デフォルトの名無しさん2010/09/10(金) 02:49:43
>>285
お前何も分かってねーな
日本なんて中国の一部と思われてる
まず国として認識されてない
0289デフォルトの名無しさん2010/09/10(金) 07:47:35
素直に英語つかえばいいやん
0290デフォルトの名無しさん2010/09/10(金) 08:32:55
>>286
エンコーディングが明確になっていいじゃない。何か不都合でも？
BOMのせいで親が死んだとか。
0291デフォルトの名無しさん2010/09/10(金) 10:14:48
同僚が過労死した
0292デフォルトの名無しさん2010/09/10(金) 10:34:21
>>286
BOMじゃなくて単なるZERO WIDTH SPACEですよ
行番号の前に空白が入ると動かないBASICでも使っているの?
0293デフォルトの名無しさん2010/09/10(金) 10:58:29
ZERO WIDTH SPACEがあると動かないperl笑java笑
0294デフォルトの名無しさん2010/09/10(金) 11:32:56
ファイル先頭にZERO WIDTH SPACEがあると困るというのは
言語仕様やシェルの仕様の問題だからそれぞれのスレでやった方がいい
0295デフォルトの名無しさん2010/09/10(金) 11:40:11
そりゃshbangはダメだろうなぁ
0296デフォルトの名無しさん2010/09/10(金) 12:08:38
BOMがあると誤作動するソフト。
BOMが無いと誤作動するソフト。
もちろん、BOMがあっても無くても正しく動くソフトもあるが。
こんなのを混在して使用しなければならないのが現状。
それぞれのソフトの作者に改良してもらうしかないのだが。
ソースコードが公開されていて自分で改造・コンパイル可能なものは
自分で手直ししてるが、すべてがそうではないからな。
それぞれのソフトを自分で独自に１から作り上げていては
本来の業務に差しさわりがある。
0297デフォルトの名無しさん2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ？
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？
エンコーディングが明確になるだ？
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス
0298デフォルトの名無しさん2010/09/10(金) 12:34:29
ソースに上位ビットが立った文字列を入れるのが間違い
0299デフォルトの名無しさん2010/09/10(金) 12:42:28
>>297
いや
<!-- 美乳 -->
の有効性をなめたらいかん
0300デフォルトの名無しさん2010/09/10(金) 20:57:07
京には美乳が多いのですか？
03012902010/09/10(金) 22:48:44
>>297
お前にとって要らないものかも知れないけど、俺は入れたいし、好き嫌いの問題だな。
美乳と違ってUTF-8のBOMは規格化されているから一緒にするなよ。
それとは別の話で、Unicode規格に従ったエンコーディングを受け入れられないJavaみたいなソフトは糞。
0302デフォルトの名無しさん2010/09/11(土) 00:07:17
BOMはクソ。

ファイルを分割・結合するときに、いちいちテキストかバイナリかを識別
せにゃならんの? 標準入出力とかパイプとか、何処から読まれて何処に
書き込まれるか、そもそもテキストかバイナリかもわからんのに、BOMを
付けたり外したりするのに責任を持つのは誰? 署名したいんだけど、対象は
バイナリ列? それともBOM抜きテキストデータ?

……たかだかプリフィックス1つでこんだけ面倒くさくなるんだから、BOMなんて滅んでしまえー。
0303デフォルトの名無しさん2010/09/11(土) 00:59:22
>>302
それはBOMに限った話じゃなくて、標準入出力でテキストファイルを処理することが問題というか、
制限を覚悟しなければならないことじゃないの？
例えばISO-2022で書かれた2つのファイルを結合するとして、最初のファイルがASCII以外で終わっていて
次のファイルがASCII前提で始まってたらデータ壊れるでしょ。
0304デフォルトの名無しさん2010/09/11(土) 02:00:03
美乳と聞いてやってきました。
美乳と言えば貧乳、貧乳はもはやステータスですよね！
0305デフォルトの名無しさん2010/09/11(土) 07:17:21
>>303

たしかにテキストファイルの分割結合に関しては、BOMよりはISO-2022の方が
やっかいだわな。
0306デフォルトの名無しさん2010/09/11(土) 08:42:10
なんで美乳と２文字も要るんだ？乳だけじゃだめなのか？
0307デフォルトの名無しさん2010/09/11(土) 11:06:14
>>305
バイトストリームとして扱える事が売りのひとつのUTF8にわざわざ始端だけつけて
「付けても付けなくても良い」とか言う糞どうでも良い仕様のために常に余計なチェックを実装させられる
好き嫌いの問題じゃすまねーよ
得意げにストリームとして扱えない事が明白なエンコード持ち出して馬鹿じゃねーのお前

世の中のBOMに対する実装だって、ほぼ全てが「BOMを適切に除外するための処理」でしかない
除外されるためだけに存在するBOMって何なのマジで
0308デフォルトの名無しさん2010/09/11(土) 11:06:52
>>302
こんなに頭悪いやつは、ひさしぶりにみた。
0309デフォルトの名無しさん2010/09/11(土) 11:06:52
すまん馬鹿じゃねーのお前は305に言う言葉じゃないなｗ
0310デフォルトの名無しさん2010/09/11(土) 11:08:46
標準入出力でテキストファイルを処理することが問題って、どこの星の人間だよ
0311デフォルトの名無しさん2010/09/11(土) 11:17:19
現状としては（本来の目的は別として）
BOMはShift_JISやEUCなど他のエンコードなどを見分ける目的で利用されている。
Shift_JISやEUCがあってこそ、BOMの存在価値があるってことだ。
システム全体がUTF8化されていて、通信やフロッピーやＣＤやUSBメモリーなど
外部から入ってくるテキストもすべてUTF8なら、BOMはいらない。
むかしならそれでいいだろう。
だが今は21世紀だぜ？インターネットの時代だぜ？世界の国からこんにちわだぜ？
「UTF8以外お断り。」ってワケにはいかない。
いろんな文字を扱わざる終えない。
だからUTF8識別文字としてのBOMは価値がある。
0312デフォルトの名無しさん2010/09/11(土) 11:26:44
UTF-8にBOMって要るんだっけ？
0313デフォルトの名無しさん2010/09/11(土) 11:34:28
BOMだけ見て終わりなんて、あらゆる状況で危険すぎて不可能
よってBOMは邪魔なだけ
0314デフォルトの名無しさん2010/09/11(土) 11:35:28
インデアン蚊帳の外です。
0315デフォルトの名無しさん2010/09/11(土) 11:40:09
結局エンコーディングなんざメタ情報が無ければ大体でしか分からん.
偽りの安心感を得るためBOM付けるくらいならメタ情報を含むフレームを作れ.
UTF-8の特性を根本から揺るがすBOMの推奨者は本当に馬鹿としか言えない.
0316デフォルトの名無しさん2010/09/11(土) 11:40:31
UTF-8にインディアンは関係無くない？
0317デフォルトの名無しさん2010/09/11(土) 11:41:51
ウニコデにもインディアン関係ないな
0318デフォルトの名無しさん2010/09/11(土) 13:30:23
>>307
ストリームとして扱えないのではなく、UTF-8はISO-2022同様、分割・結合が簡単にできません。
ってだけですよ。BOMに限らずステートフルなテキストをリダイレクトで結合するなってこと。

>除外されるためだけに存在するBOMって何なのマジで
テキストファイル単体でエンコーディングがUTF-8であることが(事実上100%)わかるんですよ。
実用上もの凄いメリットです。

本来>>315の言うとおりメタ情報で管理するべきなのだろうけど、現代のOSもファイル交換
プロトコルもテキストファイルにメタ情報付ける仕組みが無いですし。
0319デフォルトの名無しさん2010/09/11(土) 13:38:00
>>318
> テキストファイル単体でエンコーディングがUTF-8であることが(事実上100%)わかるんですよ。
latin-1との誤判断は防げないと思うが
0320デフォルトの名無しさん2010/09/11(土) 13:47:36
BOMって

Byte
Order
Mark

のはずだよね。
つまり最初からUTF-8のデータとして処理されることだけを想定してる。（当たり前だけど）

エンコーディングを見分けるとか何とか、それって事実上そういう使い方もできる、
ってだけの話で、それが本来の目的であるかのような議論っておかしいのでは？
0321デフォルトの名無しさん2010/09/11(土) 13:59:17
>>311
本当に識別文字として使っていいの？
現状使われているどの文字コードでも、BOMと同じ並びのバイト列が最初に現れる可能性はないと言える？
0322デフォルトの名無しさん2010/09/11(土) 14:03:23
>>320-321
そういう文句はUTF-8の規格作った人に言わないと。
0323デフォルトの名無しさん2010/09/11(土) 14:03:40
>>320
UTF-8のBOMはUTF-8のシグネチャーでしょ。16.8章には↓と書いてある。
| this sequence can serve as signature
| for UTF-8 encoded text where the character set is unmarked. As with a BOM in UTF-16,
| this sequence of bytes will be extremely rare at the beginning of text files in other character
| encodings. For example, in systems that employ Microsoft Windows ANSI Code Page 1252

>>319,321
Latin-1との誤判断については「極めてまれ」ってことにしたいみたいだね。
0324デフォルトの名無しさん2010/09/11(土) 14:05:55
>>320
> つまり最初からUTF-8のデータとして処理されることだけを想定してる。（当たり前だけど）

UTF-16。なんでそこまで分かっててそこ間違える。
本来の使い方はエンディアンの識別だったけど、規格でUTF-8にも入れていいことになってる。

けど識別に使うって言っても、BOMあり/なし混在してる以上はどっちにせよ
BOMなしでも識別できないといけないんだし、BOMをつけるメリットは生かせない。
ていうか、混在してる状況でつけるメリットが全然見えてこない。
0325デフォルトの名無しさん2010/09/11(土) 14:15:21
>>324
「これはUTF-8だ間違えてくれるな」ってな思いで付けちゃいけないか?
BOM有りUTF-8で保存した文書はブラウザでもテキストエディタでも文字化け
することなく開いてくれるから付けることにしてる。
0326デフォルトの名無しさん2010/09/11(土) 15:10:47
signatureが付いてる時点でそれは「plain」textじゃないんだよ。
数バイトでも本体とは別のメタデータなんだから、BOM付きtextというのはある種の構造化データだ。
だから、plain text前提のツールではとっても困る。
plain textのフリをして混じり込んでくるから余計に困る。
0327デフォルトの名無しさん2010/09/11(土) 15:15:50
>>306
乳だけじゃ唐突だから単語っぽくしてみたんじゃないか?
<!-- 入口 -->というのもあったな
0328デフォルトの名無しさん2010/09/11(土) 16:24:58
BOMってのはボム、つまり爆弾。掲示板が炎上するネタっていう意味だったんだよ。

>>306
何で「美」「乳」のうち「乳」を取るんだよおまいは。「美」でいいだろ。
0329デフォルトの名無しさん2010/09/11(土) 18:31:40
>>318
>ストリームとして扱えないのではなく、UTF-8はISO-2022同様、分割・結合が簡単にできません。 
>ってだけですよ。BOMに限らずステートフルなテキストをリダイレクトで結合するなってこと。 
ISO-2022-JPなら、結合は自由

>本来>>315の言うとおりメタ情報で管理するべきなのだろうけど、現代のOSもファイル交換 
本来はエスケープシーケンスで管理してたんだけど、ユニコードが全部ぶち壊した
0330デフォルトの名無しさん2010/09/11(土) 19:16:56
>>329
>>303,318はダメな例としてISO-2022を挙げている。ISO-2022-JPに話をすりかえるな。
またISO-2022-JPだとしても、「フィルタで特定の一行を抜き出して他の
ファイルの最後に追加」とかはできない。X 0201とASCIIが混ざるから。

> 本来はエスケープシーケンスで管理してたんだけど
世界中の文字コードをISO-2022に統一したいのか?　頭おかしい。
俺ならレガシーコードを捨てて世界中の文字コードをUTF-8Nに統一したいね。
0331デフォルトの名無しさん2010/09/11(土) 19:23:24
20年前のUnicodeは頭おかしかったけど、
結局その頭おかしいUnicodeに統一されたもんなwwwwwww
0332デフォルトの名無しさん2010/09/11(土) 19:53:58
UTF-8に統一された後にもBOMつけたがってんのか
真性のドアホだな
0333デフォルトの名無しさん2010/09/11(土) 20:09:03
231 名無しさん＠お腹いっぱい。 [] 2010/09/10(金) 22:20:36 ID: Be:
    Unicode Draft 2という文字コードの草案が出てますが、
    このままだとマズイです。

    いわゆる半角カタカナが収録されます。
    JUNETでは既に周知徹底されていて、いわゆる半角カタカナは
    根絶できたわけですが、今更のように復活するんです。

    更にマズイことがあります。
    このUnicodeという文字コードは文字幅とバイト数が一致しません。
    1バイトが半角、2バイトが全角という扱いができないんです。
    ターミナルソフトで実装できるわけがないでしょう。

    更に更に、EUCから変換する方法がありません。
    じゃあ、どうするのかというと、巨大なマッピングテーブルを
    用意するんです。
    Unicode対応nkfを作ったとしても、メモリが足りなくて実行できません。

    つまり、SJISよりも更に邪悪なんです。

    そういう無謀な規格なので、誰も実装できずに自然消滅するでしょう。
    そんな将来性のない実装の仕事がまわってくる前に、
    しっかり反論してボツにしましょう。まだDraft 2なので、間に合います。

    JUNETも自然消滅の運命なので、JISコードの扱いに関しては、
    RFCの形で後世に残すべきです。
    そしてそのRFCの中で、半角カタカナを禁止すると明記すべきでしょう。
0334デフォルトの名無しさん2010/09/11(土) 20:36:59
Unicodeに半角カナが入るって何年前の話だよ
0335デフォルトの名無しさん2010/09/11(土) 20:47:04
>>333
junet信者はこんなこと言ってたの？元はいつの発言なのか。きんもー

>>330がちょっとわからないんだけど、iso-2022-jpは行の終わりが半角英数、
ファイルの終わりがasciiで、iso-2022はそれが決まってないってこと？
0336デフォルトの名無しさん2010/09/11(土) 20:49:05
>>334
ここだけ20年時代が遅れているスレ
http://hibari.2ch.net/test/read.cgi/unix/1243343056/231
0337デフォルトの名無しさん2010/09/11(土) 20:54:39
半角カナはUnicode 1.0(1991年)だからドラフト2はその前だよね。
でもiso-2022-jpで半角カナが禁止になったのが1993年。あれ？
メールでMSの半角カナが出回る前に一時半角カナは根絶したのかな。
0338デフォルトの名無しさん2010/09/11(土) 21:06:12
JUNETでは半角カナは使えなかった。
http://www.softlab.cs.tsukuba.ac.jp/~yas/fj/junet-tebiki/J.6.3

つまり、それを踏まえたうえで、RFC 1468 を「予言」してるわけで、歴史考証的に変ではないよ。
0339デフォルトの名無しさん2010/09/11(土) 21:25:52
>>333みたいなJUNETユーザーは「国内だけの問題ではない」とか言いながら、
世界中が繋がってISO-2022-JP以外のコードが流れてくるという考えは無かったんだろうか。

> 1バイトが半角、2バイトが全角という扱いができないんです。
> ターミナルソフトで実装できるわけがないでしょう。
ﾜﾛﾀ｡どんだけレベル低いんだよｗｗ
0340デフォルトの名無しさん2010/09/11(土) 21:35:08
>メールでMSの半角カナが出回る前に一時半角カナは根絶したのかな。

yes
0341デフォルトの名無しさん2010/09/11(土) 21:37:21
>>339
> >>333みたいなJUNETユーザーは「国内だけの問題ではない」とか言いながら、

>>333 のどこに「国内だけの問題ではない」なんて書いてあるんだ？
0342デフォルトの名無しさん2010/09/11(土) 21:39:35
「半角ってなんですか?」はいつから？
0343デフォルトの名無しさん2010/09/11(土) 21:42:52
>>339

>> 1バイトが半角、2バイトが全角という扱いができないんです。
>> ターミナルソフトで実装できるわけがないでしょう。
>ﾜﾛﾀ｡どんだけレベル低いんだよｗｗ

ﾜﾛﾀ｡皮肉が理解出来ない低脳ｗｗ
0344デフォルトの名無しさん2010/09/11(土) 22:02:11
>>341
俺は>>339じゃないが、>>338のリンク先に書いてあるぞ。
0345デフォルトの名無しさん2010/09/11(土) 22:06:12
>>339
> ISO-2022-JP以外のコード
外部コードはISO-2022(JPが付かないやつ)に統一されると思ってたんだろ。
> ターミナルソフト
「実装できない」じゃなくて「実装したくない」だな、20年前だと。
当時はEUC-JPマンセーだったので、半角カナ&機種依存文字死ね状態だったわ。
あ、あとアンチMIMEな。
0346デフォルトの名無しさん2010/09/11(土) 22:26:08
ぶっちゃけ今現在、一番足を引っ張ってるのはEUC-JPだよね
0347デフォルトの名無しさん2010/09/11(土) 22:29:07
MSWindowsの日本語ロケールもさっさとUTF-8にしないと後で大変なことになる
0348デフォルトの名無しさん2010/09/11(土) 22:37:01
>>346
Shift_JIS/Windows-31Jだろどう考えても。
EUC-JPは事実上滅亡寸前。既に俺の可視範囲内にEUC-JPなシステムは存在しない。
0349デフォルトの名無しさん2010/09/11(土) 22:56:20
足を引っ張ってるのはISO-2022だろjk。
状態があるのは処理しにくいし、無駄にデータサイズがでかくなる。
今時7ビットとか言ってる奴は死んでくれと思う。早くUTF-8に統一されて欲しい。
0350デフォルトの名無しさん2010/09/11(土) 23:19:53
UTF-8でダメなメーラ・メール環境・経路って何があるんだろう？
0351デフォルトの名無しさん2010/09/11(土) 23:21:22
メールはUTF-8でいいよ。
0352デフォルトの名無しさん2010/09/11(土) 23:29:31
>>350
UTF-8がダメなメーラーは携帯電話ぐらいかな。
0353デフォルトの名無しさん2010/09/11(土) 23:36:01
>>345
> 外部コードはISO-2022(JPが付かないやつ)に統一されると思ってたんだろ。
なんだ。じゃあJUNETはISO-2022-JPではないけれどISO-2022として半角カナ使い放題じゃないか。
0354デフォルトの名無しさん2010/09/11(土) 23:38:44
http://www.nikkei.com/news/headline/related-article/g=96958A9C93819499E3E3E2E3988DE3E3E2EBE0E2E3E2E2E2E2E2E2E2;bm=96958A9C93819595E3E3E2E2978DE3E3E2EBE0E2E3E29F9FEAE2E2E2
0355デフォルトの名無しさん2010/09/12(日) 17:37:56
うんこして紙でケツの穴を拭いてもさぁ
どうせ明日、また、うんこしたらケツの穴が汚れるんだから
ケツの穴を拭くのは無駄。
うんこしてケツの穴を拭く必要性が見えてこない。
0356デフォルトの名無しさん2010/09/12(日) 17:45:22
文字化けするホームページがあってソースを見てみたら
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
って記述があるのに、実際はShift_JISだった、ってこと・・・良くあるだろ？
だからこんなタグはアテにならない。付けるの無駄。無用の長物。廃止して構わないよ。

UTF-8のBOMも同じこと。
BOMがあるからUTF-8とは限らない。
0357デフォルトの名無しさん2010/09/12(日) 18:12:03
>>355
かゆくなるぞ
0358デフォルトの名無しさん2010/09/12(日) 18:22:58
>>356
人里離れた山奥でコンピューターの無い生活した方がいいぞ。
そこではうんこも拭かなくていい。文字化けとも無縁だ。
0359デフォルトの名無しさん2010/09/12(日) 19:03:04
<!-- 美龜 -->
0360デフォルトの名無しさん2010/09/14(火) 17:48:31
<!-- マンコ -->
秀丸ならEUCの方が優先でもシフトJISで開いてくれる。
0361デフォルトの名無しさん2010/09/14(火) 18:16:44
上手く処理できないXMLがあってソースを見てみたら
<?xml version="1.0" encoding="utf-8" ?>
って記述があるのに、実際はシフトJISだった、てこと・・・よくあるだろ。
だからこんなXML宣言は当てにならない。XMLは無用の長物。廃止して構わないよ。

ISO-2022-JPでも同じこと。エスケープシーケンスがあっても糞ソフトが途中からEUC-jpを
混入させていたり、エスケープシーケンスなんて当てにならない。つまりASCII以外はアテに
ならないってことさ。
0362デフォルトの名無しさん2010/09/14(火) 18:25:51
>>361
バックスラッシュとチルダが変な表示になっちゃうだろ？
つまり(ry
0363デフォルトの名無しさん2010/09/14(火) 22:28:20
C++で、いろいろな国の言語を使った文字列を定義するとき、charとwchar_t　どっち使うのがいいの？
コンパイラによってサイズも符号化方式も異なるwchar_tを使わず、
charで処理している人もいるとさっき知った。

sizeofで、wchar_tのサイズが
1ならUTF-8
2ならUTF-16(UCS2?)
4ならUTF-32(UCS4?)
と仮定して処理しているらしい実装を見たけどこれってどうなのよ。
wchar_tだからってUnicodeとは限らないんでしょう？
0364デフォルトの名無しさん2010/09/14(火) 22:57:35
せめてSTDC_ISO_10646をチェックしろというか
0365デフォルトの名無しさん2010/09/14(火) 23:00:10
男は黙ってBOM
0366デフォルトの名無しさん2010/09/14(火) 23:12:33
L""で文字列を定義すればソースコードがShift-JISだったとしてもコンパイルが通るというメリットがあるのかな。
""で定義しても、ソースコードをUTF-8で保存し、charの中身UTF-8と仮定して処理すれば
いけるはずのに・・・あれ？

>>364
wchar_tの中身がUnicodeなら定義されている奴だね
でも定義されていなかったらどうすんの。
>>365
ソースコード中の文字列定義にBOMいれるの？
0367デフォルトの名無しさん2010/09/14(火) 23:22:25
ソースコードに文字列埋め込む人って・・・
0368デフォルトの名無しさん2010/09/14(火) 23:32:08
ASCII文字しかソースコード中には使っちゃいけないと？
それを言っちゃあ おしめいよ
0369デフォルトの名無しさん2010/09/14(火) 23:34:35
コメントは非ASCIIを使っても良いかもしれない
0370デフォルトの名無しさん2010/09/14(火) 23:37:14
// コメントのけつが 0x5C だと次の行をコメントに連結するC++コンパイラは今でも実在する。
0371デフォルトの名無しさん2010/09/14(火) 23:47:34
おまいらm17n対応ってどうしてんの？
0372デフォルトの名無しさん2010/09/15(水) 00:18:38
環境・動作対象による。
0373デフォルトの名無しさん2010/09/15(水) 01:04:16
>>368
#ifndef STDC_ISO_10646
#error Hello, Galapagos Islands!
#endif
とか?
0374デフォルトの名無しさん2010/09/15(水) 01:04:27
>>366だった
0375デフォルトの名無しさん2010/09/15(水) 16:26:56
charでUTF-8が扱える環境ならcharでいいだろう。でなきゃwchar_t。

C++の話にSTDC_ISO_10646は関係ねーだろ。
0376デフォルトの名無しさん2010/09/15(水) 16:35:24
ここでも始めるのか、wchar_t、UTF-8・・・
0377デフォルトの名無しさん2010/09/15(水) 17:03:28
ここは隔離スレなんだからもっと煽らないとw
0378デフォルトの名無しさん2010/09/15(水) 17:07:45
俺は変数も日本語だぜ。Visual Studio 2008。困ったことはない。UTF-8なので中国語もOKだ
#include <cstdio>


int main()

{
　　int マンコ = 3;
　　std::printf("%d\n", マンコ);

}
0379デフォルトの名無しさん2010/09/15(水) 17:15:12
>>377
不毛だからやるとしたらこの続きから
http://hibari.2ch.net/test/read.cgi/tech/1093251312/208-282
0380デフォルトの名無しさん2010/09/15(水) 19:19:54
>>378
ええなぁ。
javaは実行時の端末と同じエンコードでソースコードを書かないと不具合出まくり。
ソースコード書く時点で実行時の端末のエンコードが判ってなきゃダメなんだぜ！
やんなっちゃうよ。
03813782010/09/15(水) 19:29:31
>>380
えっ、Javaってそんな仕様だったか？
サーバサイドJavaはコンパイル環境とエンコード合わせた記憶がない。
少なくともコンパイル時点でUTF-16になっているからソースコードの文字コード情報
は消え失せてると思うけど。
0382デフォルトの名無しさん2010/09/15(水) 19:33:54
>>380
それはどうみても、君かプロジェクトの担当者か、
あるいは両方が
馬鹿
0383デフォルトの名無しさん2010/09/15(水) 19:56:27
>>381
インディアンはどっち？
03843812010/09/15(水) 20:01:47
>>383
今ためしたらUTF-8だった。ｽﾏﾝｶｯﾀ
0385デフォルトの名無しさん2010/09/15(水) 22:39:48
>>380
javac -help
<中略>
-encoding <encoding> ソースファイルが使用する文字エンコーディングを指定する
<以下略>
0386デフォルトの名無しさん2010/09/15(水) 22:45:03
>>384
ぅぉ、本当だ、classファイル中の文字列定数はUTF-8(サロゲートペアの扱いはjava固有だった希ガス)表現なんだ。知らんかった。
0387デフォルトの名無しさん2010/09/16(木) 01:20:46
Java 1.6でU+D800, U+DF02のサロゲートペア文字列をコンパイルすると、classファイルは
F0 90 8C 82(U+10302)じゃなくてED A0 80(U+D800) + ED BC 82(U+DF02) になるね。
UTF-32通さずにそのままUTF-8にしてるな。
Javaで2面以上扱う時はこの不正なUTF-8を突っ込んでやらないといけないのか。
0388デフォルトの名無しさん2010/09/16(木) 01:56:22
Javaは実用性皆無のウンコ
0389デフォルトの名無しさん2010/09/16(木) 02:05:20
しかし、クライアントから金は巻き上げやすい…
0390デフォルトの名無しさん2010/09/16(木) 02:37:39
Java案件で数多の阿鼻叫喚を繰り広げ
IT大不況へと突入
今となっては受注開発は金の無駄が経営者達の合言葉
0391デフォルトの名無しさん2010/09/16(木) 02:43:23
ずいぶん荒らされたし
発注側にもトラウマが残った
0392デフォルトの名無しさん2010/09/16(木) 03:00:24
一山いくらで量産されたJava猿のお陰でプログラマの市場価値も駄々下がりｗ
0393デフォルトの名無しさん2010/09/16(木) 03:05:47
ほんと、Java発の技術ってろくなもんないんだよね…
XMLとかSOAPとか
0394デフォルトの名無しさん2010/09/16(木) 03:32:32
>>393
全然Java発じゃないし、役にも立ってる
0395デフォルトの名無しさん2010/09/16(木) 03:38:09
>>394
そりゃ、多少の役には立たなきゃw
完全な詐欺道具になっちまう。
なくても困らないし、ないほうがいいくらいの技術だといってるだけさw
0396デフォルトの名無しさん2010/09/16(木) 06:40:04
>>387
classファイルの中だけの固有形式で、不正な形式のまま
外部とやり取りすることはない
0397デフォルトの名無しさん2010/09/16(木) 21:00:03
>>363
> sizeofで、wchar_tのサイズが
> 1ならUTF-8

これがわからん。defineしているのか？
0398デフォルトの名無しさん2010/09/16(木) 23:31:44
wchar_tが1でUTF-8なんてISO 14882の3.9.1-5的におかしい。
まあマイクロソフトのwchar_tがUTF-16なのもおかしいけど。
0399デフォルトの名無しさん2010/09/17(金) 00:39:51
>387
えー、zipとかjarファイルのファイル名もこんな変なUTF-8が出力
されてなかったっけ。
0400デフォルトの名無しさん2010/09/17(金) 01:16:21
>>399
ホントだ。jarでclassファイルをまとめる時、ファイル名はUTF-8で記録するけど、
サロゲートペアは間違った偽UTF-8じゃないとダメみたいだな。
これも互換性のための仕様ってやつかね。仕様のバグがあっても互換性のために絶対直さない糞Java
0401デフォルトの名無しさん2010/09/17(金) 01:44:18
どうせＪＡＲを勝手にＺＩＰとして開いて文句を垂れてるんだろ。お前が悪い
Ｊａｖａの崇高な設計思想など貴様ら愚民共に理解できるはずがない。消えろ屑
0402デフォルトの名無しさん2010/09/17(金) 02:30:19
Firefox拡張用のjarとかはどうなってるんだろう
0403デフォルトの名無しさん2010/09/18(土) 08:52:00
>>401
必死だなｗ
0404デフォルトの名無しさん2010/09/18(土) 12:16:46
>>403
何が？
0405デフォルトの名無しさん2010/09/18(土) 13:03:02
CSI方式万歳！UCS normalization方式 は屑
0406デフォルトの名無しさん2010/09/18(土) 23:45:11
wchar_tがUTF-8の環境なんてあるの？
0407デフォルトの名無しさん2010/09/19(日) 03:02:53
↑
こいつあたまおかしい
0408デフォルトの名無しさん2010/09/19(日) 08:52:02
>>407
つ>>397-398
0409デフォルトの名無しさん2010/09/19(日) 09:00:47
正しく動作させるためにはwchar_t[]の度に先頭から走査するのかねぇ？
0410デフォルトの名無しさん2010/09/19(日) 09:07:38
UTF8はリードバイトが可変長過ぎてAPI任せだわ( ´ω`)
BOMもありとなしがあってなんであそこまでｶｵｽなんだ
0411デフォルトの名無しさん2010/09/19(日) 18:10:49
>>410
UTF-8にBOMなんてないよ。
あったらそりゃUTF-8もどきだよ。
0412デフォルトの名無しさん2010/09/19(日) 18:52:29
>>411
それがあるんですよ。
0413デフォルトの名無しさん2010/09/19(日) 18:56:48
Unicodeなんだからそこは「なんでBOMなしでいいんだよ」って突っ込もうぜ( ^ω^)
半角英数記号を1バイトにしたいがためのコードと言えばそれまでよ
0414デフォルトの名無しさん2010/09/19(日) 18:59:10
UTF-8って良く出来てる
0415デフォルトの名無しさん2010/09/19(日) 19:07:18
一番最後に作られただけあるよな。
0416デフォルトの名無しさん2010/09/19(日) 19:16:57
UTF-8は屑。SJIS/EUC-JPで２バイトだったのが３バイトになって喜んでいるのは欧米人の手先。
0417デフォルトの名無しさん2010/09/19(日) 19:23:31
さすがにDBCSに戻る気にはなれないな
0418デフォルトの名無しさん2010/09/19(日) 19:56:24
日本人同士がJISとかSJISとかEUCとかで揉めてるときに
欧米人にUTF-8でサクっと問題解決されてしまった
日本人涙目
0419デフォルトの名無しさん2010/09/19(日) 20:02:00
>>416
たかが1文字で1バイト増えたぐらいでごちゃごちゃ言うなよ。

すべての文字表すのに16bitじゃ足りないって言っていたのに、
32bitにすることで2バイト増えるからとケチっていた欧米人と
お前は何にも変わらん。
0420デフォルトの名無しさん2010/09/19(日) 20:05:35
>>412
だからUTF-8もどきだと言ってるだろ？
わかんねーのか？
0421デフォルトの名無しさん2010/09/19(日) 21:54:36
>>420
全然わからないな。
http://www.unicode.org/versions/Unicode5.2.0/ch16.pdf
この16.8章をどう読んだらBOM有りUTF-8がもどきになるんだ？
0422デフォルトの名無しさん2010/09/19(日) 23:22:46
どう考えてもISO 2022フル実装が一番カオス。
designate/invokeで表現方法が複数あったり、シングルシフトに2種類の表現があったり
アナウンスまで出てきた日には大変だ。
ESC - "$" - Ft と ESC - "$" - "(" - Ftで使える文字集合が違うとか狂ってる。
0423デフォルトの名無しさん2010/09/19(日) 23:47:02
>>421
そこに書いてある通りのことを言ってるんだが？

Although there are never any questions of byte order with UTF-8 text,

UTF-8のテキストにバイトオーダーがない（＝ＢＯＭが必要ない）事は疑問の余地がないが。

this sequence can serve as signature　for UTF-8 encoded text where the character set is unmarked.

このシークエンスは、そのキャラクタセットがマークされていないところで、 UTF-8でエンコードされたテキストの
シグニチャとして保持することができる。（＝UTF-8と分かってたら使っちゃダメ）
0424デフォルトの名無しさん2010/09/19(日) 23:59:53
で、BOM以外は同一のUTF-8テキストファイルで
先頭から10文字目って言うのは等しい文字が帰ってくるのかい？
BOMを数えるのが仕様？数えないのが仕様？

あと、BOMの意図無く、ただの文字としてファイルの先頭にZERO WIDTH SPACEを入れるのは仕様上認められるの？
0425デフォルトの名無しさん2010/09/20(月) 00:06:57
もうそろそろ誰か文字コードを識別する仕組みを外部の何かにやらせるまでを
文字コードの仕様にした規格を出してもいいと思うんだ
0426デフォルトの名無しさん2010/09/20(月) 00:11:11
>>423
言い換えれば、
「UTF-8にバイトオーダーなんてないしBOMなんてない。
例外として、エンコードが分からないような特殊なケースでシグニチャ付けて良いよ。」
と言っている訳。

シグニチャをBOMって呼ぶのは本来誤用だけど、UTF-16の連想からBOMと言っている。
0427デフォルトの名無しさん2010/09/20(月) 00:16:47
>>424
> ただの文字としてファイルの先頭にZERO WIDTH SPACEを入れるのは仕様上認められるの？

認められる。
BOM有りUTF-8の場合は先頭のU+FEFFはBOM。
BOM無しUTF-8の場合は先頭のU+FEFFはZWNBSP。
ファイルのデータのみからは判断できず、解釈するためにはエンコーディングスキームに関する
メタ情報が必要。そこら辺がカオス
0428デフォルトの名無しさん2010/09/20(月) 01:10:12
詰まる所メタ情報必須って事だよね？
ただの1文字と区別のつかないBOM(シグニチャ)付けたがる意味がわかんないわ
0429デフォルトの名無しさん2010/09/20(月) 01:35:19
そうは言っても文字コードの異なるファイルが混在する問題を放置するわけにもいかず、
「ファイルのみ必ずBOMを付け、メモリ上や通信のデータ部はBOM無し」
という暗黙のルールをマイクロソフトが広めたがっていると思われる。
0430デフォルトの名無しさん2010/09/20(月) 01:44:19
大勢がUTF-8へ傾いてる状態で、UTF-8に統一された後に無駄に困るような仕様を残すのは馬鹿じゃないの
0431デフォルトの名無しさん2010/09/20(月) 02:05:06
せめて ZWSP(U+FEFF)は文字として使用せずUnicodeのシグネチャーとしてのみ使用される、
とかすればよかったのに。
通常文字の一つをシグネチャーとしても使用したことがクレイジー。区別つかないだろまったく
0432デフォルトの名無しさん2010/09/20(月) 02:11:31
>>430
だよな
0433デフォルトの名無しさん2010/09/20(月) 07:42:12
もうBOMなんて使わんで
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
を入れときゃいいやん。それですべて解決するはずだろ？
0434デフォルトの名無しさん2010/09/20(月) 07:45:45
80バイトも無駄にするくらいなら
macbinaryの方がましだな
0435デフォルトの名無しさん2010/09/20(月) 08:28:15
UTF-8はASCII互換が売りなんだから、BOM付けるのは本末転倒ですよね
0436デフォルトの名無しさん2010/09/20(月) 08:34:47
そりゃそうだ。その使用を正式からはずせ。
0437デフォルトの名無しさん2010/09/20(月) 08:44:38
UTF-8Nの利点が本気で分からない
先頭バイト見ればエンコーディングが分かるなど、初学者を惑わすだけの危険な幻想でしかないし
BOMに一体どんな利点があるって言うの？
0438デフォルトの名無しさん2010/09/20(月) 08:46:31
>>416
てめーmule encoding disてんじゃねーよ。
0439デフォルトの名無しさん2010/09/20(月) 08:51:03
>>437
逆? そ言えば、必ずBOMがある(慣習的な)エンコーディング名ってないな。
UTF-8N(BOM無しUTF-8)は日本固有の慣習らしいが。
0440デフォルトの名無しさん2010/09/20(月) 09:07:36
逆だなｗ
BOM付UTF-8には特に呼び方が無いという、まさに混乱を極める仕様
0441デフォルトの名無しさん2010/09/20(月) 09:13:36
あっても無くても良いし、あった所で何かを保証するわけでもないし
「それ」を全うに扱うためには信頼できるメタ情報が必須であり
メタ情報があるならそもそも「それ」は不要である
そんなBOMさんがこの先生き残るには
0442デフォルトの名無しさん2010/09/20(月) 09:15:28
この先生キノコる
0443デフォルトの名無しさん2010/09/20(月) 09:16:17
(U+FEFF)(U+FEFF)(U+FEFF)aaa
って内容のファイルのLengthっていくつになるのが正しいの？
3？5？6？
0444デフォルトの名無しさん2010/09/20(月) 09:23:54
>>424

先頭からの文字数に関しては、UTF-16等と一緒だろ。
UTF-16でBOMを一文字としてカウントするのなんて見たことないんだが。
0445デフォルトの名無しさん2010/09/20(月) 09:28:41
>>443

ファイルサイズとしてのlengthと文書の文字数としてのlengthは違うと思うよ

改行コードなんかに関しても似たようなケースがおこるよね
0446デフォルトの名無しさん2010/09/20(月) 09:37:44
当然文字列のLengthの話
ファイルサイズのLengthは悩む余地無いでしょ？
12バイト以外になり得るの？
0447デフォルトの名無しさん2010/09/20(月) 09:42:28
>>444
通りが良いからBOMって言ってるだけで、UTF-8に「UTF-16等と一緒のBOM」は無いよ
いい加減文脈から区別付けて話しましょう
0448デフォルトの名無しさん2010/09/20(月) 10:08:29
「UTF-16等と一緒のBOM」をUTF-8でエンコードしたものじゃないか
0449デフォルトの名無しさん2010/09/20(月) 10:18:48
>>447

なんでそこに食いつく。

UTF-16だって、BOMはバイトオーダーを示すシグネチャなんだから、
UTF-8のシグネチャと同じようなもんだよ。

重要度が違うとか、UTF-8のシグネチャをBOMと言っちゃうから誤解や混乱が
発生するという問題はあるけどね。

で、テキストファイルに於いて付けられているシグネチャを文字列の文字数と
カウントするのか、そうでないのかって話ならUTF-8もUTF-16も同じじゃ
ないの？と言ってる。
0450デフォルトの名無しさん2010/09/20(月) 10:27:01
>>438
mule encodingは屑。なんだか分からないから。
0451デフォルトの名無しさん2010/09/20(月) 10:34:56
>>446

文字列のlengthの問題はUTF-8に限った事じゃないけどな。

その文字列が何バイトか？
その文字列が何文字か？
でも違ってくる。

たとえばISO-2022-JPなんかだとESC $ Bなどのエスケープコードは
プログラミング上の文字列のlengthでは数える必要があるけど、先頭から
10文字表示しなさいって場合の10文字には含んではいけない。

シフトコードとか、こういった類のものはプログラミングするうえで厄介な
ものであることは確かだけどね。
0452デフォルトの名無しさん2010/09/20(月) 10:41:03
utf-8シグネチャはテキストファイルの先頭に限ってのみ付加可能ってことにすれば
いいのかもしれんね。一つのテキストファイルに複数の文字エンコードが混在する
ようなものを扱う場合はシグネチャなんて当てにせず自前で処理するだろうからさ。
0453デフォルトの名無しさん2010/09/20(月) 11:31:07
BOMって何の略？
Byte Order Mark ?
0454デフォルトの名無しさん2010/09/20(月) 11:36:14
>>451
えーと、バイト数なんてどうでも良いんだけど･･･
何でしつこくそこに持っていくの？
UTF-8でやっとバイト数と文字数に一切の関連性は無いという共通認識が得られつつあるのに、何をいまさらという感じ

(U+FEFF)(U+FEFF)(U+FEFF)aaa
上記UTF-8ファイルの文字長はいくつと解釈するのが正しいのですか？
この質問に、少なくともバイト数と改行は全く関係ないでしょう？
0455デフォルトの名無しさん2010/09/20(月) 12:09:10
UTF → Unicode Transformation Format

略語の原語を調べればだいたい理解できるだろ
0456デフォルトの名無しさん2010/09/20(月) 12:24:32
>>453
そう
エンディアンの識別用
0457デフォルトの名無しさん2010/09/20(月) 13:06:48
>>453
Beautiful Oppai Mark
0458デフォルトの名無しさん2010/09/20(月) 13:32:04
やっぱ
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
これが最強だね。これさえあれば世界中のどんな文書もエンコードが判別できる。
なんでこんな簡単なことに誰も気づかないんだろ。
もしかして、おまいらアフォ？
0459デフォルトの名無しさん2010/09/20(月) 13:42:23
ほらほら、つりですよー。
早くパクッってやらないと
何度もコピペしますよー。
0460デフォルトの名無しさん2010/09/20(月) 13:47:19
美乳がこの先生きのこるには
0461デフォルトの名無しさん2010/09/20(月) 13:59:53
>>454

文字長は3文字だろ。
行間や文字間を一文字と数える習慣は日本語にはないからね。

何度も言うけど、「先頭から何文字切り出す」という場合の文字数と
実際に操作する文字列のサイズとは別物なんだよ。

目に見える表現形式としてのテキストの文字数（一般人が考える文字数）と、
プログラミングで使われる文字列長（バイト表記であろうが文字数表記であろうが）
とをごっちゃにして、

「先頭から何文字切り出す」という観点からUTF-8のシグネチャを
数えるのか？なんて議論は的外れだと俺は言ってるんだよ。

0462デフォルトの名無しさん2010/09/20(月) 14:09:34
馬鹿はおまえだ。
各プログラミング言語における「文字」の定義次第。

オクテット長でなければいけないなんて合意はどこにもない。
0463デフォルトの名無しさん2010/09/20(月) 14:49:34
「1文字＝１バイト」っていう変な概念は捨てろや
0464デフォルトの名無しさん2010/09/20(月) 15:34:16
>>461
ごっちゃにしてるのはお前だけ
0465デフォルトの名無しさん2010/09/20(月) 15:53:33
>>441
結局のところそのメタ情報の決定版がないからさらに状況を面倒くさくしてるのでは。
0466デフォルトの名無しさん2010/09/20(月) 16:01:02
>>461はもうレスしなくていいよ
何度も言うけど実際に操作する文字列のサイズなんて問題にしてないんだよ

aaaの一体どこから日本語と思ったのか不思議
大体ロケールが違ったら文字長もその都度変わるって言うの？
特別扱いしないただの1文字であるはずのU+FEFFを
文字長としてカウントしない言うのはどこに定義されてるの？
「制限：全角10文字　半角20文字　0角無限文字」とか言っちゃうの？

とにかく>>461は頭の中が時代遅れ過ぎてお話になってないよ
0467デフォルトの名無しさん2010/09/20(月) 18:08:43
>>458
そのやり方はXHTML1.1では非推奨でHTTPヘッダ使えってことになってるし
HTML5でも書き方が変わって<meta charset="utf-8">になった
だからそのやり方は最強ではなく単に古い仕様
0468デフォルトの名無しさん2010/09/20(月) 18:23:49
EmacsとPythonとRuby1.9では「-*- coding: utf-8 -*-」。
0469デフォルトの名無しさん2010/09/20(月) 18:29:34
Perlではuse utf8
0470デフォルトの名無しさん2010/09/20(月) 18:36:28
Rubyでは-Ku
0471デフォルトの名無しさん2010/09/20(月) 20:27:26
文字数と言えばtwitterってどうなんだっけ？
0472デフォルトの名無しさん2010/09/20(月) 20:33:52
>>454
5文字でいい。

metaタグとか言ってるバカは何なの？
HTML以外のテキストファイルとかどうするつもりなの。
ZIPファイルで圧縮している日本語ファイル名をどう記録するつもりなの
0473デフォルトの名無しさん2010/09/20(月) 20:39:37
素人騙しだよなぁlang属性で全て解決！とかさ
0474デフォルトの名無しさん2010/09/20(月) 21:32:36
オールマイティなBOMさんかっこよすなぁ
0475デフォルトの名無しさん2010/09/20(月) 23:46:57
>>472
metaタグでええやん。何か問題でも？
0476デフォルトの名無しさん2010/09/20(月) 23:50:37
>>467
あんたねぇ・・・
オエライさんが決めたからって、犬みたいにシッポ振ってホイホイ付いて行くなよ。
今まで大量に蓄積された文書はどうすんの？
どうせ過去との互換性も保つために、古いタグも新しいタグも両方とも対応するアプリケーションを作らにゃいかんやろ。
アフォくさ。
意味のない新規格なんざ無視しろ。
0477デフォルトの名無しさん2010/09/20(月) 23:57:20
>>476
HTML5だと新しい書き方が推奨ってだけで古い書き方も問題無く通るよ
それに新規格に意味が無いなら営利企業がたくさん策定作業に参画したりしないよ
0478デフォルトの名無しさん2010/09/21(火) 00:19:04
古い書き方ガン無視で誰もついてこなかった
XHTML2の反省に立って作られた規格だからな
0479デフォルトの名無しさん2010/09/21(火) 10:55:08
そうすると今度は誰も新しい書き方なんかしない。
そういう奴らだからな、「ウェブデザイナー」とか。
0480デフォルトの名無しさん2010/09/21(火) 14:41:09
うｔｆ－８にぼｍなんて必要ない
0481デフォルトの名無しさん2010/09/21(火) 20:37:55
<br>に / という無駄なものを
書かせたXHTMLは市ね。
0482デフォルトの名無しさん2010/09/21(火) 21:08:20
>>481
てめえか、締りの悪いケツをさらしてんのは？
0483デフォルトの名無しさん2010/09/21(火) 21:17:37
EOFの無いファイルはクソ
0484デフォルトの名無しさん2010/09/21(火) 21:55:46
＞それに新規格に意味が無いなら営利企業がたくさん策定作業に参画したりしないよ

新規格をつくれば企業は儲かる。たとえそれが意味の無い新規格でも。
ただ儲かりたいだけ。それが営利企業なんだよ。
われわれユーザの利便性など、どうでもいい。
0485デフォルトの名無しさん2010/09/22(水) 00:10:15
>>481
brを使ってる時点でお前が死ね
0486デフォルトの名無しさん2010/09/22(水) 00:11:05
>>484
＞新規格をつくれば企業は儲かる。
いや、規格の協同策定は、得のためと
いうよりは、損をしないがためだろ。

チキンレースみたいなもんだ。ｗ
0487デフォルトの名無しさん2010/09/22(水) 00:47:26
>>479
互換性無視で新仕様作ったって結局誰も新しい書き方なんかしなかったんだから
「そうすると」はおかしいだろ
0488デフォルトの名無しさん2010/09/22(水) 03:01:05
utf-8シグネチャ = U+FEFF = ZWNBSP(Zero Width No-Break Space：幅の無い改行しない空白)
って事は、ZWNBSPという文字を、ヒントや推測に使って良いってだけの話じゃないか。

U+FEFF がシグネチャを意図してるのか、ZWNBSPであるかを悩む必要は無いだろう。
改行コード等と同じように、勝手に付けたり消したりせず、初期状態を維持すりゃ良いのだし、
あるなら使い、無いなら無いで何とかするか、端から無視するかすれば良いだけ。

むしろ utf-8シグネチャ = ZWNBSP としてある所に、センスを感じるな漏れは。
0489デフォルトの名無しさん2010/09/22(水) 03:05:41
>>488
馬鹿乙
0490デフォルトの名無しさん2010/09/23(木) 07:27:32
>>488
どうみても苦し紛れ
0491デフォルトの名無しさん2010/09/23(木) 08:25:18
<!-- 美乳 -->としてある所に、センスを感じるな漏れは。
0492デフォルトの名無しさん2010/09/23(木) 22:57:25
>>466

何度言ってもわからんやつだなぁ

あなたは文字数、文字数って言ってるけど　その文字数っていう観念には
文学的な文字数、言い換えれば人が文章として見て認識する文字数と、
ソフトウェアなどで扱う際のコードとしての文字数（俺はそれを文字列の長さ
と言ってる）があるんだよ。

このスレ前の方で出てた、先頭から何文字切り出す云々は、テキストの処理を
想定したものだから、いわゆる文章としての文字の処理の問題でシグネチャ
などはカウントしないのが普通だろ。

こんなのは　ACB^H^HBC なんてやってた頃からあたりまえのことじゃん。

そしてプログラミングで扱う場合の文字列としての文字数なら当然U-FEFFは
一文字として扱わないといけない。

だから最初に出てた、U-FEFEが付いたファイルは何文字とカウントするんだよ？
なんて話題はナンセンスだって言ってるわけ。

そもそもなんでオクテット長なんて出てくるんだよ。
0493デフォルトの名無しさん2010/09/23(木) 23:10:13
そんな事より美乳の話しようぜ
0494デフォルトの名無しさん2010/09/23(木) 23:31:12
BOMをどう扱うかは、個々のプログラマが個々のアプリケーションに対して個々に決める仕様だろ。
TABコードをどう扱うか、とか、CRやLFをどう扱うか、とか。そんなんと同じだろ。
0495デフォルトの名無しさん2010/09/23(木) 23:59:57
>>492
馬鹿で粘着乙
0496デフォルトの名無しさん2010/09/24(金) 00:05:40
ゼロ角ってなんですか?
0497デフォルトの名無しさん2010/09/24(金) 00:10:21
>>492みたいなコミュ障害者に限ってレスしたがりだよなｗ
0498デフォルトの名無しさん2010/09/24(金) 06:14:01
>>494
全然違うよカス
BOMは仕様で定義されてんの
0499デフォルトの名無しさん2010/09/24(金) 09:30:39
>>495 >>497 コミュ障粘着乙。消えな
0500デフォルトの名無しさん2010/09/24(金) 09:36:44
そんなひとはいません
0501デフォルトの名無しさん2010/09/24(金) 10:06:46
>>499
オウムが消えるべき
0502デフォルトの名無しさん2010/09/24(金) 10:13:29
　　　 _ 　∩
　　(　ﾟ∀ﾟ)彡　美乳!美乳!
　　(　 ⊂彡
　 　|　　　|
　 　し ⌒Ｊ
0503デフォルトの名無しさん2010/09/24(金) 10:27:34
最近は言語によってはその辺の変換クラスが最初からあるから便利だよね
最初文字コード変換関数作ったときとかBOMとはなんぞ？ってなったわ
0504デフォルトの名無しさん2010/09/24(金) 10:42:59
ﾄﾞ━━━━m9(ﾟ∀ﾟ)━━━━ﾝ!!
0505デフォルトの名無しさん2010/09/24(金) 13:10:27
そうだ！
文頭の微乳はBOM扱いにして、ゼロ長ってことにすればどう？
0506デフォルトの名無しさん2010/09/24(金) 13:22:50
天才現る
0507デフォルトの名無しさん2010/09/24(金) 13:25:01
美乳、爆乳は何倍角ですか？
0508デフォルトの名無しさん2010/09/24(金) 18:00:05
こんなお遊びの流れの中で指摘されてる問題の本質も>>492は理解できてないんだろうなｗ

シグニチャはカウントしない？そうですか
で、君はどこからシグニチャと判断したのですか？

ユーザーが自由に扱えるはずの、ただの一文字でしかないU+FEFFが
先頭にあるってだけでシグニチャ扱いするのは不確実で危険だ(仕様上決定されてない)と言う話なんだけどな
君一人だけだよ？話が理解できてないの
0509デフォルトの名無しさん2010/09/24(金) 18:13:36
↑
0510デフォルトの名無しさん2010/09/24(金) 19:24:14
>>498
じゃぁ、BOMをどう扱うか、仕様を示してみろよ。どうせできんくせに。
0511デフォルトの名無しさん2010/09/24(金) 19:37:50
>>505
乳に長さがあるのか？龜ならあると思うが
0512デフォルトの名無しさん2010/09/24(金) 22:27:42
>505
文頭に限らずゼロ長にすれば、「文頭のみ」なんて気持ち悪い処理は要らんじゃん。
0513デフォルトの名無しさん2010/09/24(金) 23:47:09
BOM付きファイルはテキストファイルじゃなくてバイナリファイル。
メタデータの付いた「テキスト」ファイルなんてねーよ。
0514デフォルトの名無しさん2010/09/25(土) 00:05:08
テキストファイル・バイナリファイルの定義自体曖昧なわけで
0515デフォルトの名無しさん2010/09/25(土) 01:22:50
>>513
制御コードはテキストファイルか？
http://ash.jp/code/ctrltbl.htm
0516デフォルトの名無しさん2010/09/25(土) 05:12:07
スクリプトの先頭行の#!とか副ストリームにZoneId付加するのとかはｾﾌｾﾌ?
0517デフォルトの名無しさん2010/09/25(土) 05:55:08
印字できないものは全部ｱｳｱｳ
0518デフォルトの名無しさん2010/09/25(土) 07:57:08
タブ・半角空白・全角空白が含んだのもバイナリファイルか
0519デフォルトの名無しさん2010/09/25(土) 10:25:43
>508
最新の規格だと、U+FEFFはBOM以外の用途に使うな、となってるらしいけど。

※幅・改行無しの空白が欲しいなら以下を使う。
　U+200C : ZERO WIDTH NON-JOINER
　U+200D : ZERO WIDTH JOINER

※某短距離走者の名前を出したら爺決定。
0520デフォルトの名無しさん2010/09/25(土) 10:35:48
ビートたけしのスポーツ大将
0521デフォルトの名無しさん2010/09/25(土) 18:17:51
>>519
> 以下を使う。
何でそこを間違える。
http://www.unicode.org/Public/5.2.0/charts/CodeCharts-noHan.pdf
によると
| use as an indication of non-breaking is deprecated; see 2060 instead
0522デフォルトの名無しさん2010/09/25(土) 23:49:11
>>508

コンピュータ処理で言う１文字と、人が画面に表示あるいは紙に印刷された
文字として認識する１文字とは違うんじゃないの。

コンピュータ処理での１文字は、それは文字コードとして定義されている物は
すべて１文字としてカウントされるけど、人が目にする媒体になって人が文字数を
カウントする場合は必ずしもそうでない。

で、顧客などから要求される仕様としての文字数の扱いは、後者の場合が多いわけで、
その実装の手間はBOMに限らずタイプフェイスを持たない文字全般につきまとう問題だよね。
0523デフォルトの名無しさん2010/09/26(日) 01:22:14
>>515,517,518
BOM付きファイルは、BOMパート + テキストパートという構造を持つコンテナフォーマットの一種。
テキストファイルは、テキストパートのみを含み、それ以外を含まないファイル。
制御コードやホワイトスペース文字はテキストパートの一部を構成するものに対して、BOMはテキストパートの外側にあるものなので、そもそも扱いが違う。
0524デフォルトの名無しさん2010/09/26(日) 02:22:11
BOMの扱いが決定不可能な問題について質問と言う形で出す
↓
変な子が、ファイルサイズと文字長は違うよと言ってくる
↓
知ってると返す
↓
変な子が、人が扱う文字長とプログラムで扱う文字長は違うと言ってくる
↓
知ってると返す
↓
変な子が、いやおれの中では文字長と言えばこう定義されてるし別物なんだよと言ってくる
↓
だから、そんな話はしていないからもうレスしなくていいよと返す
↓
変な子が、人が扱う文字長とプログラムで扱う文字長は違うんだよ！昔からの当たり前の話だろうと言ってくる
↓
開いた口がふさがらない
↓
変な子が、コンピュータ処理で言う１文字と人が認識する１文字とは違うんじゃないのと、また繰り返してる
↓
もうやだこの馬鹿　←いまここ
0525デフォルトの名無しさん2010/09/26(日) 03:10:43
岡田監督にどうなんですか？って聞き続けるコントを思い出した。
0526デフォルトの名無しさん2010/09/26(日) 07:48:57
コンピュータ処理で言う美乳と、人が画面に表示あるいは紙に印刷された
美しい乳として認識する美乳とは違うんじゃないの。
0527デフォルトの名無しさん2010/09/26(日) 09:05:33
ここまでのまとめ

保守派の主張

BOMはUTF-16のバイト順を識別する以外の目的で使うべきではない。
おエライさんが決めたことだから、守らなければならない。
しかし、細かいことがあいまいなので愚痴ってる。
不満はあってもシッポ振ってわんわん吼えながら御主人様についていく。

革新派の主張

おエライさんが決めたことだぁ？だから何だよテメェ。
何をどう使おうと俺の勝手だ。
１文字＝１バイト圏の毛唐の決めたクソ仕様なんざ、守る必要ねぇ！
UTF-8にBOMあったってええやん。これをUTF-8テキストどうか識別するのに使ったってええやん。
0528デフォルトの名無しさん2010/09/26(日) 10:53:41
UTF-8にBOMを挿入可能なのは規格上許容された事だろ。
unixのshell scriptとかで#の前にBOMがある場合は使えませんよってだけ。
UTF-16のみに使うべきなどというのは、根拠の無い主張に過ぎない。
0529デフォルトの名無しさん2010/09/26(日) 11:12:49
Use of a BOM is neither required nor recommended for UTF-8
0530デフォルトの名無しさん2010/09/26(日) 11:13:20
>>523
> 制御コードやホワイトスペース文字はテキストパートの一部を構成するものに対して
え？

01 SOH ^A Start Of Heading（ヘッダ開始）
04 EOT ^D End Of Transmission（転送終了）
05 ENQ ^E ENQuiry（問合せ）
06 ACK ^F ACKnowledge（肯定応答）
07 BEL ^G BELl（ベル）
10 DLE ^P Data Link Escape（伝送制御拡張）
11 DC1 ^Q Device Control 1（装置制御1）
12 DC2 ^R Device Control 2（装置制御2）
13 DC3 ^S Device Control 3（装置制御3）
14 DC4 ^T Device Control 4（装置制御4）
15 NAK ^U Negative AcKnowledge（否定応答）
16 SYN ^V SYNchronous idle（同期信号）
0531デフォルトの名無しさん2010/09/26(日) 11:42:22
テキストファイルなんてものは存在しません
0532デフォルトの名無しさん2010/09/26(日) 11:51:17
ttp://unicode.org/faq/utf_bom.html
0533デフォルトの名無しさん2010/09/26(日) 17:43:15
^G は普通にテキストファイル中で使うよな。
たとえばバチファイルでこんなふうに。
IF ERRORLEVEL 1 ECHO ^Gエラーが発生しました。
(実際に制御コードを埋め込む↑)
0534デフォルトの名無しさん2010/09/26(日) 19:14:02
テキストファイルの判断は、
・最上位ビットが立っていない
・改行コードが入っている
・'\0'がない
ってのがあると思うが、UTF-16はどれもだめ。これじゃ単なるバイナリ
0535デフォルトの名無しさん2010/09/26(日) 19:28:29
最上位ビットを入れたら、Shift_JISもEUC-JPもUTF-8もアウトですよ。
そこはさすがに冗談ですよね？
0536デフォルトの名無しさん2010/09/26(日) 19:37:18
>>535
Linuxのfileコマンド叩いてみな
0537デフォルトの名無しさん2010/09/26(日) 19:39:12
>>534
Perlの-Tもそんな感じだね。あれはASCII TEXTって言ってるけど
0538デフォルトの名無しさん2010/09/27(月) 00:42:59
>>536
Linuxなんて知らねーよ。持ってる奴の方が少ないだろ。
そのfileコマンドとやらの結果が何であっても>>534がおかしいことに変わりはない。
0539デフォルトの名無しさん2010/09/27(月) 01:01:22
Linuxなんてファイル名すらバイナリデータとして扱うぶっ飛びキチガイ仕様じゃねえかｗ
「テキスト」に関しては一切参考に出来ない糞の塊
0540デフォルトの名無しさん2010/09/27(月) 02:31:22
>>536
リナックスってそんな馬鹿なんだｗ
0541デフォルトの名無しさん2010/09/27(月) 05:52:40
Linuxはファイルシステムに文字コードが規定されてないから
どの言語でも扱えるようにバイナリデータで扱うしかできなくなってるらしいｗ
ファイルシステムはUnicodeにしとけよ。マジで馬鹿ｗ
0542デフォルトの名無しさん2010/09/27(月) 07:22:20
もっと煽って
0543デフォルトの名無しさん2010/09/27(月) 08:19:11
$ echo 美乳 | nkf -j > jis
$ echo 美乳 | nkf -s > sjis
$ echo 美乳 | nkf -w16 > utf16
$ echo 美乳 | nkf -w16B > utf16bom
$ echo 美乳 | nkf -w > utf8
$ echo 美乳 | nkf -w8 > utf8bom
$ file *
jis: ASCII text, with escape sequences
sjis: Non-ISO extended-ASCII text
utf16: data
utf16bom: Big-endian UTF-16 Unicode text
utf8: UTF-8 Unicode text
utf8bom: UTF-8 Unicode (with BOM) text
0544デフォルトの名無しさん2010/09/27(月) 08:30:17
$ echo 美乳 | nkf -e > euc
$ file euc
euc: ISO-8859 text
0545デフォルトの名無しさん2010/09/27(月) 08:54:57
OSは透過性が高くつくってあるのがいいに決まってるじゃねーか。
馬鹿なの？　死ぬの？
0546デフォルトの名無しさん2010/09/27(月) 09:09:10
ファイルシステムはここでやっているからやるならこの続きから
http://hibari.2ch.net/test/read.cgi/tech/1093251312/208-282
0547デフォルトの名無しさん2010/09/29(水) 09:15:52
めも

Windows のファイル名の文字コードについて
ttp://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-007ACA9B
Linuxにおける各種文字コード系の扱いについて
ttp://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-002BF237
0548デフォルトの名無しさん2010/09/29(水) 19:09:30
| NTFS ファイルシステム上のファイルを Windows のファイル圧縮ツール(zip, lha など）で
| 圧縮ファイルにまとめると、Windows カーネルは、ファイル名を Unicode -> SJIS 変換して
| ファイル圧縮ツールに渡し、ファイル圧縮ツールは、SJIS のファイル名で圧縮ファイル内に保存します

何だよこの糞仕様。UTF-8にしないと後生まで後悔するぞ。
0549デフォルトの名無しさん2010/09/29(水) 19:58:59
もう手遅れ。
WindowsはファイルシステムはUnicodeなのに使っちゃいかん文字があるという
不思議仕様になってる。Unicodeファイル名含むアーカイブ渡すと罵倒されるよw
0550デフォルトの名無しさん2010/09/29(水) 21:16:46
それ太古のUnicode非対応アプリの話だろ。
0551デフォルトの名無しさん2010/09/30(木) 00:33:24
アプリのエントリポイントが昔ながらのmainであればMBCSに変換、
wmain であれば Unicode のまんま渡される。
また、wmain なファイル圧縮ツールも存在する。（Explzhとか）
なので>547,548は正確ではない。

そもそも exe に渡すファイル名が、常に SJIS に変換されるのであったら、
explorer で開けないフォルダを作れてしまうと思うけど。
0552デフォルトの名無しさん2010/09/30(木) 01:37:42
太古のＵｎｉｃｏｄｅ非対応アプリ(当時圧倒的主流派)への互換性を優先し
今まで通りのやり方(太古の主流派)で作られた場合、今まで通りの文字コードが渡されるようにしただけだな

>>548
必要バイト数があまりにも予測できなくなるので、多言語かつ低レベルな領域ではUTF-8は微妙
もう10年経ったら分からんが

>>549
お前の脳みそウンコに入れ替わってるみたいよ？病院いってら
0553デフォルトの名無しさん2010/09/30(木) 08:43:08
Windowsの某フリーエディタはmain()がUnicodeで無いみたいで、explorerで開けないファイルがあるが
0554デフォルトの名無しさん2010/09/30(木) 09:27:04
>>553
失せろ
0555デフォルトの名無しさん2010/09/30(木) 10:02:49
>>552
> 必要バイト数があまりにも予測できなくなるので、多言語かつ低レベルな領域ではUTF-8は微妙
> もう10年経ったら分からんが

文字数を固定長としているのが悪い。
MAX_PATHもプラットフォームでばらばら。
0556デフォルトの名無しさん2010/09/30(木) 12:02:40
とはいえバッファサイズは決めなきゃならないしな
0557デフォルトの名無しさん2010/09/30(木) 16:34:52
>>549
> もう手遅れ。
> WindowsはファイルシステムはUnicodeなのに使っちゃいかん文字があるという
> 不思議仕様になってる。Unicodeファイル名含むアーカイブ渡すと罵倒されるよw

使っちゃいかん文字ってコロンとかじゃなくて？
0558デフォルトの名無しさん2010/09/30(木) 20:01:28
>>556
ファイル名に限らず文字列は動的に確保するものだろ。
制限の厳しいWindowsでさえファイル名が最大3万文字なのに固定でバッファとる奴はアフォ。
0559デフォルトの名無しさん2010/10/01(金) 21:11:17
>>558
それ本気でいってんの？
0560デフォルトの名無しさん2010/10/01(金) 21:32:44
>>559
言語は？
0561デフォルトの名無しさん2010/10/01(金) 23:59:52
>>558は話題領域を把握できてないタコスケ
0562デフォルトの名無しさん2010/10/02(土) 08:19:34
char path[MAX_PATH]
wchart_t wpath[MAX_PATH]
バッファ食いすぎ
0563デフォルトの名無しさん2010/10/02(土) 09:18:14
>>562は話題領域を把握できてないタコスケ
0564デフォルトの名無しさん2010/10/02(土) 09:26:57
そりゃあBOMだけで３バイトも食うから低レベルな領域でUTF-8は使えないなぁ
0565デフォルトの名無しさん2010/10/02(土) 10:05:04
>>562
getcharで1文字ずつ取っていって、足りなくなったらreallocするの？
0566デフォルトの名無しさん2010/10/02(土) 10:09:38
>>565
Windowsのワイド文字からマルチバイトに変換するなんたらって関数は、
必要バイト数を返してくれるオプションがあるから、それでもらってそれで確保する。
0567デフォルトの名無しさん2010/10/02(土) 10:15:57
Cには文字列型がないので処理がめんどくさい。エラー処理でのfreeをずっと気にしなければならなくなる。
0568デフォルトの名無しさん2010/10/02(土) 10:43:11
Unicodeはダサイよな
0569デフォルトの名無しさん2010/10/02(土) 10:45:14
ダサいけど現状一番マシな選択肢だからしょうがない
0570デフォルトの名無しさん2010/10/02(土) 18:26:25
| char path[MAX_PATH]
Windowsでこんなプログラム書く奴は死んで欲しい。
全角文字ばかりの240文字のファイル名渡されたらどうするつもりだ。
0571デフォルトの名無しさん2010/10/02(土) 18:32:18
>>570
Windowsでっていうけど、
じゃあLinuxだとどうすんのさ。
0572デフォルトの名無しさん2010/10/02(土) 18:39:13
LinuxだとPATH_MAX。パスの長さは4096文字あれば十分だろ。
0573デフォルトの名無しさん2010/10/02(土) 18:45:00
100文字あれば十分だと思う
0574デフォルトの名無しさん2010/10/02(土) 18:49:24
> char path[MAX_PATH]
海外のシングルバイト前提のアプリでは平気である。
日本のでもShift_JIS前提でchar path[MAX_PATH*2]てのもある。
これじゃ、UTF-8なんて無理。
まだ TCHAR path[MAX_PATH] の方がまし。
0575デフォルトの名無しさん2010/10/02(土) 19:24:38
MAX_PATH*2なんて、Win32 APIが扱えない時点で無駄。
wじゃないWinMainアプリはマルチバイト文字ファイル名を扱えない欠陥アプリ。
長い全角ファイル名があると フォルダのファイル一覧取得APIがエラーになるんだぜ。
0576デフォルトの名無しさん2010/10/02(土) 19:28:06
Windowsの場合、サロゲートペアの文字はどうなるの？
ノートパッドだと、1文字で2文字にカウントされるよね？
0577デフォルトの名無しさん2010/10/02(土) 20:11:48
>>574
いや、UTF-8かどうかなんて関係なく
パスは無限の長さを持つんだよ。
シンボリックリンクを使えばね。

だからMAX_PATHだろうが、PATH_MAXだろうが
どちらにしろ関係ない。
パスの長さを固定にしている時点でどちらも同じ。
0578デフォルトの名無しさん2010/10/02(土) 20:57:48
>>566
で、そのワイド文字は、メモリ上にないのか？
0579デフォルトの名無しさん2010/10/02(土) 21:02:00
>>578
wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] )
0580デフォルトの名無しさん2010/10/02(土) 21:46:24
>>577
で？
可変に拘るのはいいが、無限の長さをどうやって扱うの？
0581デフォルトの名無しさん2010/10/02(土) 21:48:03
PATH_MAX、4096バイトって
たかがパス一つ保持するだけで
スタック4KBも消費するのか・・・
0582デフォルトの名無しさん2010/10/02(土) 21:49:46
>>580
どうやって扱うかじゃなくて
バッファオーバーフローして
セキュリティホールになるのが問題なんだよ。
0583デフォルトの名無しさん2010/10/02(土) 21:52:03
バッファオーバーフローにさえならなければ
char path[MAX_PATH]での
何の問題もないよ。

単にこのソフトはMAX_PATH文字のパスしか
扱えない仕様ってだけ。
0584デフォルトの名無しさん2010/10/02(土) 21:57:52
>>582
そりゃバッファが固定長なのが問題じゃなく、バッファの長さを管理してないのが問題なんじゃねぇか
0585デフォルトの名無しさん2010/10/02(土) 21:59:00
>>583
文字じゃなくてバイト
Shift_JISなら最後のバイトが欠ける可能性がある
0586デフォルトの名無しさん2010/10/02(土) 22:29:49
○　バッファオーバーラン
×　バッファオーバーフロー
0587デフォルトの名無しさん2010/10/02(土) 22:39:22
"バッファオーバーラン"　　　約 16,500 件 （0.17 秒）
"バッファオーバーフロー"　約 107,000 件 （0.03 秒）

＾＾；
0588デフォルトの名無しさん2010/10/02(土) 22:49:43
で？
バッファオーバーフローは実際に発生したデータ量が予定していたバッファのサイズを上回ること。
バッファオーバーランはバッファオーバーフローした際にデータサイズをチェックしなくて予定外の
メモリを変更されること。意味が違う。
0589デフォルトの名無しさん2010/10/02(土) 23:12:51
>>585
それは、バッファのサイズを
いくつにしようが発生する問題だろ。
0590デフォルトの名無しさん2010/10/02(土) 23:14:29
>>588
少しはぐぐった？
どちらも同じって書いてあるよ。
0591デフォルトの名無しさん2010/10/03(日) 02:51:21
>586-588
http://en.wikipedia.org/wiki/Buffer_overflow
http://en.wikipedia.org/wiki/Buffer_overrun
http://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%95%E3%82%A1%E3%82%AA%E3%83%BC%E3%83%90%E3%83%BC%E3%83%A9%E3%83%B3

○バッファオーバーフロー = バッファオーバーラン
0592デフォルトの名無しさん2010/10/03(日) 03:10:23
>>591
ソースがwikipediaかよｗ

wikipediaを信じるなんて馬鹿のすること。
wikipediaに書いてあることはみんな間違い。
つまり、その逆が正解。

wikipediaに書いてある時点で
世界で最も信用できないものと思え。

結論　バッファオーバーランが正しい。
0593デフォルトの名無しさん2010/10/03(日) 06:31:52
つまり、WikipediaにあるUnicodeの説明も全て間違いと言うことですね、判ります。
0594デフォルトの名無しさん2010/10/03(日) 06:46:36
>>592
じゃあお前のソースはなに？
0595デフォルトの名無しさん2010/10/03(日) 06:51:48
予定サイズを上回ったら自動的に何かが書き込まれて変更されるからな。
結果としては一緒。
0596デフォルトの名無しさん2010/10/03(日) 07:02:10
>>592 逆裏対偶の区別もつかないバカ登場wwwwwww
0597デフォルトの名無しさん2010/10/03(日) 07:27:47
char path[MAX_PATH+1]と+1を付けていなければどっちも起きるわな
0598デフォルトの名無しさん2010/10/03(日) 08:27:06
得意げに○×やってみたら自分が間違ってた時って、どんな気持ちなんだろう
0599デフォルトの名無しさん2010/10/03(日) 09:16:04
なんか本筋でないところでもめているようだけど、CERTやCWEでは"buffer overflow"が使われている。
あと stackoverflow.com とか名付けられているように、overflowのほうが普通に使われているようだね。
0600デフォルトの名無しさん2010/10/03(日) 09:45:28
>>597
+1 ってセコすぎる。たった1バイトしか余裕がないのかよ。
せめて1文字分は余裕持たせたほうが・・・おっと、「1文字とは1バイトである」って概念
に毒されたひとには何を言ってもムダか。
0601デフォルトの名無しさん2010/10/03(日) 09:50:12
醜いレス乞食
0602デフォルトの名無しさん2010/10/03(日) 10:06:48
>>588
「バッファから溢れる」現象を指してオーバーフローと言うわけで
「バッファを越えて書き込んだ」現象を指すオーバーランとどこも違わん。
オーバーフローしてりゃオーバーランしてるし、オーバーランしてりゃオーバーフローしてんだよ。

顔真っ赤にして恥の上塗り乙。
0603デフォルトの名無しさん2010/10/03(日) 11:39:31
>>575
FindFirstFileA/FindFirstFileW両方あるが？
0604デフォルトの名無しさん2010/10/03(日) 13:16:15
>>597
> char path[MAX_PATH+1]と+1を付けていなければどっちも起きるわな

なにが？

今時のOSはパスの最大長は無限長なのを
まだ理解できてないの？
シンボリックリンクを使えばね。
0605デフォルトの名無しさん2010/10/03(日) 13:22:00
文字列を固定長で取っていれば、どんなサイズにしようが
バッファオーバーフローが起きる可能性はあるし、

バッファオーバーフローがおきないように作っているのなら、
そのソフトで使えるパスの長さが100文字とかいう制限はできたとしても
それはそのソフトの仕様というだけの話。

Shift_JISなら最後のバイトが欠けるというのは、
1バイト文字を混在して使える（つまりバッファサイズを
何文字にしてもおきる話）ということに気づいていないので論外。
0606デフォルトの名無しさん2010/10/03(日) 13:26:36
だってさ
http://www.k5.dion.ne.jp/~r-f/sicklylife/memo/ubuntu910/hdd.html

ext3・ext4・XFS 255バイト Linux系OSのファイルシステム
UFS 255バイト UNIX系OSのファイルシステム
NTFS 255文字 Windowsのファイルシステム
HFS+ 255文字 MacOS Xのファイルシステム
255バイトというと日本語だけでおよそ80文字強。

参考：NTFS,ext3,ReiserFSのファイル名の長さの話
参考：ext3 - Wikipedia
参考：ext4 - Wikipedia
参考：XFS - Wikipedia
参考：HFS Plus - Wikipedia

また、最大パス長は以下のようになっている。

ext3・ext4・XFS 4096バイト Ubuntu 9.10での場合
UFS 不明 POSIXの規定では「NULL終端で1024バイト」
NTFS Unicodeで32767文字 対応していないアプリもあるらしい
HFS+ 無制限 ただしDarwinの制限で1024文字を限界としている部分がある
参考：ファイルシステム - Wikipedia

0607デフォルトの名無しさん2010/10/03(日) 13:30:46
あと、NTFSはUnicodeで255文字、
NTFSはUTF-16と決まっているので、
charのMAX_PATHを×2にするのは正しい。
（Shift_JISだから×2なんじゃなくて、UTF-16だから×2なんだよ）
0608デフォルトの名無しさん2010/10/03(日) 13:31:51
>>606
それは、ファイルシステム上の物理的なパスの長さね。
シンボリックリンクを使えば無限になるから。
0609デフォルトの名無しさん2010/10/03(日) 14:28:24
UTF-16で帰ってくるってことはW系APIだろ。
何故WCHAR使わずにcharで受けるんだ？
0610デフォルトの名無しさん2010/10/03(日) 14:30:51
(1)ストレージに記録しておける個々のファイル名・フォルダ名の長さ
(2)ストレージに記録しておけるパスの長さ
(3)APIに渡せるパスの長さ
(4)状況として発生し得るパスの長さ（例：>608）
をきちんと区別して語ろうず。

ちなみにWindowsの場合、
(1)255 (NTFSの場合。)
(2)パスは記録していない
(3)32767 (2k以降?)
(4)無限
0611デフォルトの名無しさん2010/10/03(日) 15:19:02
>>607
サロゲートペアの文字は一文字と数えるの？
0612デフォルトの名無しさん2010/10/03(日) 15:58:16
>>609
http://hibari.2ch.net/test/read.cgi/tech/1093251312/281
0613デフォルトの名無しさん2010/10/03(日) 16:26:33
シンボリックリンク使わなくとも昔から
./././././hoge
みたいにやたら長いパスを渡せるな。
0614デフォルトの名無しさん2010/10/03(日) 18:53:38
>>605
> Shift_JISなら最後のバイトが欠けるというのは、
> 1バイト文字を混在して使える（つまりバッファサイズを
> 何文字にしてもおきる話）ということに気づいていないので論外。

サロゲートペアでも欠けるんじゃね？
0615デフォルトの名無しさん2010/10/03(日) 19:32:57
合成文字はどうするんだろ
正規化する必要あるの？
0616デフォルトの名無しさん2010/10/03(日) 19:41:27
charだろうがwchar_tだろうがバイト・文字が欠けるのは一緒。
だったら汎用性の高いcharでUTF-8の方が良い。
0617デフォルトの名無しさん2010/10/04(月) 07:32:43
しつこくシンボリックリンクと繰り返してる奴はどこの脳内Windowsの話をしてるの?
すくなくとも実在のWindowsではシンボリックリンクは32回以上ネストできないし
「展開後」の長さがWCHARで数えて32767文字を超えられないから
無限にはならない
0618デフォルトの名無しさん2010/10/04(月) 07:48:29
>>617
親ディレクトリへのシンボリックとか
ネットワークファイルシステムとかあるでしょｗ
0619デフォルトの名無しさん2010/10/04(月) 08:02:31
>>617
覚えたばっかのニワカ知識を振りかざしたくてしょうがないんだろ
猿のオナニーなんざ止めようとするだけ無駄
0620デフォルトの名無しさん2010/10/04(月) 09:10:34
どうでもいいけど、誰もWindowsなんて言ってないのに
なんで限定するんだろう
0621デフォルトの名無しさん2010/10/04(月) 09:15:59
>>620
変な名前のが出来て嬉しくて仕方が無いから
0622デフォルトの名無しさん2010/10/04(月) 13:48:23
>>597
MAX_PATH+1 ほど情弱なもんはない
0623デフォルトの名無しさん2010/10/04(月) 19:19:28
>617-619
シンボリックとか使わなくても、コマンドプロンプトで「フォルダ作ってはmove」を
繰り返せば余裕で限界超えられるよ。

※エクスプローラでは削除できないフォルダが出来上がるので注意。
※エロ画像とか隠すのに使えるかも。

■実証用バッチ
cd /d %~dp0
set prefix=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789_
for /l %%n in (500,-1,0) do (
ren tmp %prefix%%%n
md tmp
move %prefix%%%n tmp
)
pause

■削除用バッチ
cd /d %~dp0
set prefix=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789_
for /l %%n in (0,1,10) do (
move tmp\%prefix%%%n .
rd tmp
ren %prefix%%%n tmp
)
pause
0624デフォルトの名無しさん2010/10/04(月) 19:20:52
削除用バッチ訂正。

×for /l %%n in (0,1,10) do (
○for /l %%n in (0,1,500) do (
0625デフォルトの名無しさん2010/10/05(火) 01:01:56
ウイルス貼るなクズ！
0626デフォルトの名無しさん2010/10/05(火) 01:32:06
>>625
お前様はマルウェアは押し並べてウイルス扱いするお間抜けですか。
0627デフォルトの名無しさん2010/10/05(火) 08:00:23
マルウェアかどうかすら怪しい
0628デフォルトの名無しさん2010/10/05(火) 10:07:28
>625
それを言うなら「ヴァイラス」だろ
0629デフォルトの名無しさん2010/10/05(火) 10:54:06
ヴァイタミン
0630デフォルトの名無しさん2010/10/05(火) 21:43:32
ヴィニュー
0631デフォルトの名無しさん2010/10/05(火) 23:00:19
ヴァニラタン
0632デフォルトの名無しさん2010/10/06(水) 15:14:29
ヴェガス
0633デフォルトの名無しさん2010/10/06(水) 22:51:13
ビールスだろ
0634デフォルトの名無しさん2010/10/07(木) 06:48:38
beers
0635デフォルトの名無しさん2010/10/11(月) 07:43:50
ヴィールス
0636デフォルトの名無しさん2010/10/11(月) 10:06:28
そろそろまとめろ
0637デフォルトの名無しさん2010/10/11(月) 11:02:31
>>602
バッファオーバーフロー
　　バッファサイズ以上に書き込む
バッファオーバーラン
　　バッファサイズ以上に書き込む／読み込む
0638デフォルトの名無しさん2010/10/11(月) 11:21:49
>>637
お前の定義はいらんから、
どこからか出典もってこい。

ぐぐったら、どちらも同じって書いてあって
レスするきにならなくなるだろうけどなｗ

じゃあ、サイナラ
0639デフォルトの名無しさん2010/10/11(月) 15:16:58
バッファオーバーフローの例
main()
{
  int unko[10];
  printf("%d", unko[20]);
}
0640デフォルトの名無しさん2010/10/11(月) 18:11:44
つ、釣られないぞ・・・
0641デフォルトの名無しさん2010/10/11(月) 18:39:00
バッファオーバーランの例

void main()
{
char oppai[1];
strcpy (oppai,"美乳");
}
0642デフォルトの名無しさん2010/10/12(火) 08:08:59
>>638 惨敗だな
常識に「出典もってこい」とは恥ずかしい。
中学２年生かおまいは！
0643デフォルトの名無しさん2010/10/12(火) 10:43:19
バッファオーバーフローの例
void f(char buf[])
{
　char manko[200];
　if ( strlen(buf) >= sizeof manko / sizeof *manko ) throw "buffer overflow";
　strcpy(manko, buf);
　：
}
0644デフォルトの名無しさん2010/10/12(火) 10:51:23
┌─────────────┐
│　　　　CrossDays　　　　　　　　　│
│　11GBの空きが必要です　　　.│
│　　　　　　[ＯＫ]　　　　　　　　　　.│
└─────────────┘ （　ﾟдﾟ）
0645デフォルトの名無しさん2010/10/12(火) 20:56:10
>>642
どっちも同じ意味だなんて、常識だよね。
0646デフォルトの名無しさん2010/10/14(木) 17:38:01
「Unicode 6.0」が策定、絵文字が国際標準に
http://k-tai.impress.co.jp/docs/news/20101013_399811.html
0647デフォルトの名無しさん2010/10/14(木) 17:38:29
UNK絵も国際化されたわけだ。
0648デフォルトの名無しさん2010/10/14(木) 18:18:58
>>646-647
ここはインディアンがテーマなのですれ違い
0649デフォルトの名無しさん2010/10/14(木) 22:13:50
ビッグインディアンって白人？黒人？






エンディアンの間違いじゃないのかｗ
0650デフォルトの名無しさん2010/10/14(木) 22:14:55
無粋すぐる

0651デフォルトの名無しさん2010/10/14(木) 22:33:31
ここはキチガイ論者の隔離スレとして再利用されたから、ここでいいんだよ。
しかし使えない絵文字ばかり集まったな。これじゃ携帯メールのUnicode化なんて無理だ。
0652デフォルトの名無しさん2010/10/15(金) 03:03:17
おでんに海苔せんべえとか、
随分と日本ローカルなもんまで採用したんだな。
こんな事認めてたら、収集付かなくなりそ。
0653デフォルトの名無しさん2010/10/15(金) 06:58:52
ヘタクソというか素人臭が漂う絵ばかりだなあ
0654デフォルトの名無しさん2010/10/15(金) 10:49:59
サンプルのデザインをあげつらってもしょーがないべ。
0655デフォルトの名無しさん2010/10/15(金) 11:03:52
>>646
Googleによる企業支配の幕開けだな
0656デフォルトの名無しさん2010/10/15(金) 11:39:39
×収集
○収拾
0657デフォルトの名無しさん2010/10/15(金) 13:59:20
1F4A9
0658デフォルトの名無しさん2010/10/15(金) 14:01:54
💩
0659デフォルトの名無しさん2010/10/15(金) 14:04:06
\u1F4A9
0660デフォルトの名無しさん2010/10/15(金) 14:05:49
U+1F4A9
0661デフォルトの名無しさん2010/10/15(金) 14:11:01
\x{1F4A9}
0662デフォルトの名無しさん2010/10/15(金) 21:59:37
絵文字に関しては、字体もコード表に合わせなくても怒る人いないの？
漢字はそうなってるし、波ダッシュ・全角チルダ問題も字の形がちょっと違うことが原因で起こったトラブルだったのに。

絵文字は、マイナス記号・ダッシュ・ハイフンみたいに、使い道によって別の文字コード割り当てなくてもいいの？

絵文字も異字体セレクタで別の字体を選べるの？
0663デフォルトの名無しさん2010/10/15(金) 22:08:09
絵文字は色もついてるしアニメするし、どうしようもない。
各社でちがうし。
0664デフォルトの名無しさん2010/10/18(月) 11:57:35
1F4A9には臭いもついてます
0665デフォルトの名無しさん2010/10/20(水) 12:24:45
http://www.google.co.jp/images?q=PILE%20OF%20POO
0666デフォルトの名無しさん2010/11/08(月) 22:33:49
うんこage
0667デフォルトの名無しさん2010/11/11(木) 01:15:56
チャットで
ௌௌௌௌௌௌௌௌ☠ௌௌ☠ௌௌௌௌௌௌௌௌ☠ௌௌௌௌௌௌௌௌௌ☠ ௌௌௌௌ
ってうたれたら文字真っ白になってバグるんだけどどうすればいいかな？
エンコードしても無理みたいｗｗｗ
0668デフォルトの名無しさん2010/11/11(木) 07:54:04
>>667
死ねばいいと思う
0669デフォルトの名無しさん2010/11/11(木) 13:49:40
>>668
なんでやってｗｗｗ
マジで対策法教えてくれ
0670デフォルトの名無しさん2010/11/11(木) 15:42:13
>>667
何かと思って調べてみればタミル文字じゃん
試しにエディタに貼り付けてみたら、秀丸、gPad、K2Editor、Notepad++では無理だった
サクラエディタとMeryはOK

これ、そのチャットアプリで対応してなければ無理じゃね
0671デフォルトの名無しさん2010/11/12(金) 10:49:52
ちなみにうちの秀丸(7.10)はOKだったお(UTF-8で)
0672デフォルトの名無しさん2010/11/12(金) 13:28:00
ちなみに対策としては、相手のインド人に
英語か日本語を使うようお願いするといい
0673デフォルトの名無しさん2010/11/23(火) 19:42:30
別のチャットシステムを試すというのも考えるべきだよ。
0674デフォルトの名無しさん2010/11/25(木) 19:09:51
サポートに修正依頼する。ちなみにWord 2010に貼り付けたら固まったぞ。
0675デフォルトの名無しさん2010/12/02(木) 18:51:34
「文字コードはUnicodeで」とか言う奴が多くて困る。
お前はホントにISO-10646-UCS-2のつもりなのかと、サロゲートペア使わないんだなと
言ってやりたい。
0676デフォルトの名無しさん2010/12/02(木) 23:45:25
UCS-4のつもりかもしれないじゃまいか
0677デフォルトの名無しさん2010/12/03(金) 06:55:00
UTF-16だってUnicodeじゃん。
むしろUTF-8でもUTF-16でもUTF-32でも好きなのを選んでいいのだなと小一時間(ry
0678デフォルトの名無しさん2010/12/03(金) 10:32:45
じゃあUTF-7で
0679デフォルトの名無しさん2010/12/03(金) 17:17:07
さすがに非標準は選択肢に入れたらダメだろうｗ
0680デフォルトの名無しさん2010/12/03(金) 23:01:12
punycodeってどうなんだっけ？
0681デフォルトの名無しさん2010/12/03(金) 23:06:18
Unicodeは規格であって文字コード(エンコーディング)じゃないからねぇ。
ISO-10646-UCS-2って言ってるからIANAのUnicodeのことじゃないの。
> Name: ISO-10646-UCS-2
> Source: the 2-octet Basic Multilingual Plane, aka Unicode
「aka Unicode」なんて書いた奴だれだ。
0682デフォルトの名無しさん2010/12/03(金) 23:38:46
それはNameでもAliasでもないから
エンコーディング名として「Unicode」が認められてるわけじゃない
0683デフォルトの名無しさん2010/12/03(金) 23:41:52
Windowsのことじゃないの
0684デフォルトの名無しさん2010/12/04(土) 01:53:40
赤UNICODE？
青UNICODEや
黄UNICODEもあるのか？
0685デフォルトの名無しさん2010/12/04(土) 12:17:49
also known as
0686デフォルトの名無しさん2010/12/06(月) 00:41:29
UnicodeつったらUnicodeに決まってるじゃないか！
0687デフォルトの名無しさん2010/12/06(月) 00:42:19
UNICODEがいくつもあるなんて変だよ
0688デフォルトの名無しさん2010/12/06(月) 01:47:20
Multicodeに改名だ。
0689デフォルトの名無しさん2010/12/06(月) 03:36:24
JISコードつったらJISコードに決まってるじゃないか！
0690デフォルトの名無しさん2010/12/14(火) 20:01:05
Javaって未だにソースコードをUTF-8で書けないんだっけ。ウンコだな。
0691デフォルトの名無しさん2010/12/14(火) 20:07:54
>>690
ファイルの先頭にウンコがついてるだけじゃないの？
0692デフォルトの名無しさん2010/12/14(火) 20:16:29
>>691
ウンコじゃなくてBOM。JavaはBOMありUTF-8が扱えないうんこ。
ついでにこのスレで既に議論があった通り、不正なUTF-8でJARファイルを作成するうんこ
0693デフォルトの名無しさん2010/12/14(火) 20:21:31
VC++も悲惨なんだけどなんとかならんのかな
0694デフォルトの名無しさん2010/12/14(火) 20:36:55
VC++はウンコつきじゃないとコンパイルできないんだっけ。
0695デフォルトの名無しさん2010/12/14(火) 20:40:39
Microsoft Visual C++はまっとうだろ？
　BOMあり→BOMに従う
　BOMなし→システム既定のANSIコードページとして解釈
コンパイルオプションに文字コード指定があっても良かったとは思うが、
BOMなしでコンパイラに自動判別を期待するのはクレイジー
0696デフォルトの名無しさん2010/12/14(火) 21:02:33
VCだと　fopen("filename", "r, ccs=UTF-8");　でBOMなしもBOMありも読める。
おJava様のInputStreamReaderはBOMありが正常に読めないウンコ。
0697デフォルトの名無しさん2010/12/14(火) 21:09:28
>>695
C/C++コンパイラはそれで構わないんだけど、
リソースコンパイラがBOM付きのUTF-8を認識しないんだ
UTF-16にすると今度は外部ツールが扱えなかったりと
0698デフォルトの名無しさん2010/12/14(火) 21:14:56
じゃあVC++もリソースでBOMありUTF-8が使えないウンコ。
0699デフォルトの名無しさん2010/12/14(火) 21:23:20
ソースコードやビルドリソースの文字コードに制限があるのはまだ我慢できるよ。
問題は>>696の通りデータファイルでBOMありなしの両方が扱えないこと。これは致命的
0700デフォルトの名無しさん2010/12/14(火) 23:34:50
Microsoftの開発環境さえ無ければBOM無しUTF-8で皆が幸せに暮せるのにな
byte orderが無いUTF-8でbyte order markって何だよ？
0701デフォルトの名無しさん2010/12/14(火) 23:41:34
さて、どこからループするのでしょうか？
0702デフォルトの名無しさん2010/12/15(水) 00:25:30
>>700
それはマジ勘弁。シフトJISの資産が切り捨てられるならいいけど実際には無理。
素人が文字コードのよくわからんファイルを作っちゃってそれを判別しろとか言われると困る。
区別がつかなかったのでUTF-8と仮定して追記したら「実はシフトJISしか
扱えないアプリのファイルでした」とか言われるかも知れん。
0703デフォルトの名無しさん2010/12/15(水) 00:40:24
今度からBOMはF0 9F 92 A9(U+1F4A9)でお願いします。
例: 「JavaってUTF-8扱えないの?」
　　「先頭にウンコついてるからじゃない? ウンコ取った方がいいよ!」
0704デフォルトの名無しさん2010/12/15(水) 05:58:41
Linuxかぶれが公開してるオープンソースソフトに入ってた拡張子のないREADMEが、
改行コードLFでShiftJISだった時は死ねと思った
どういうエディタで書いてんだ
0705デフォルトの名無しさん2010/12/15(水) 07:17:16
Mac
0706デフォルトの名無しさん2010/12/15(水) 07:23:56
>>704
俺が今やってるプロジェクトのソースもそうだ。
開発サーバがシフトJIS+LF。本番サーバはUTF-8がデフォなのに
export LANG=ja_JP.SJISして使っているらしい。
0707デフォルトの名無しさん2010/12/15(水) 09:37:29
FFFTPとかって改行コードを勝手に変換するモードなかったか？
0708デフォルトの名無しさん2010/12/15(水) 09:55:35
いまどきFTP使ってるなんて
0709デフォルトの名無しさん2010/12/15(水) 10:02:47
sftpは現役だと思うぞ。改行コードの変換機能があるかは知らないが
0710デフォルトの名無しさん2010/12/15(水) 22:14:17
WinSCPでSFTP使ってるけど、転送は全部バイナリに設定してるなあ。
テキストエディタで開くだけなら文字コードも改行コードもあんまり意識しない。
Java使う時だけBOMのありなしに気をつかう程度。
0711デフォルトの名無しさん2010/12/15(水) 23:05:33
ftpとsftpは全くの別物でしょ
0712デフォルトの名無しさん2010/12/15(水) 23:20:12
イントラネット内とかデータセンターにシステムを構築する場合、既存システムとの
インターフェース仕様は当たり前のようにFTPが出てくる。目立とか目立とか目立とか。
そんでもってスレ違いだけどファイル書き込みが完了する前にファイル処理が走って
「想定外です。タイミングに依存した複雑な問題です」とか毎回言ってくる。仕様見直せよ。
0713デフォルトの名無しさん2010/12/16(木) 08:34:03
>>712
日本語見直せよ。
0714デフォルトの名無しさん2010/12/16(木) 20:09:43
LinuxでSJIS使うメリットってないだろ。
UTF-8の扱えないFFFTPはうんこ。UTF-8に統一してWinSCPが勝者。
0715デフォルトの名無しさん2010/12/16(木) 21:19:38
業務だったらUTF-8になんかメリットないだろ。
だから信者の思いとは異なってLinuxはWindowsを駆逐できないんだよ。
0716デフォルトの名無しさん2010/12/16(木) 21:32:42
SJISで表示できないコードがあるんですけど
0717デフォルトの名無しさん2010/12/16(木) 21:36:39
LinuxがWindowsを駆逐できないのはユーザビリティが低すぎるからでしょ
サーバ開発でLinuxは十分成功してる。
UTF-8については、数年もしたら「旧システムは文字コードがシフトジス
なのでデータ移行の対象外」とかいう言い訳すら流行りかねない
0718デフォルトの名無しさん2010/12/16(木) 23:53:31
充分？
壊れてもいいWebサーバくらいだろ。
バックエンドはAIXやらHP-UXばっかじゃねーか。
0719デフォルトの名無しさん2010/12/17(金) 03:42:17
早くWindowsの日本語localeのmbcsがUTF-8にならないかな
0720デフォルトの名無しさん2010/12/17(金) 07:51:49
>>719
本スレのどこかにmbcsが２バイトまでと決まっているから無理だと書いてあった
0721デフォルトの名無しさん2010/12/17(金) 07:55:02
へー
0722デフォルトの名無しさん2010/12/17(金) 08:26:56
Visual C++はCのsetlocaleも3バイト文字対応してないって書いてあるし、
一生UTF-8には対応しないんじゃ値
0723デフォルトの名無しさん2010/12/17(金) 21:23:37
.NETでカバーするつもりなのかもな。
0724デフォルトの名無しさん2010/12/18(土) 04:34:20
VC++でUTF-8の文字列リテラルを書けるようになって欲しいな。
u8"ほげほげ" って書くとANSIじゃなくてUTF-8になるとかさ。
今は実行時にワイド文字列から変換するか、すごく読みにくいけどエスケープして書いてる。
0725デフォルトの名無しさん2010/12/18(土) 04:49:46
うーん、最近はasciiじゃない文字を含むリテラルを書くことがないなぁ。
VCならリソースだし、そうでなくてもそれに近い形にしてしまう。
0726デフォルトの名無しさん2010/12/19(日) 01:14:12
UTF-8文字列を直接扱うのってメリットあるの?
どうせワイド文字に変換しなきゃ扱いづらいんだから、ワイド文字に統一で
いいと思うんだけど。
0727デフォルトの名無しさん2010/12/19(日) 01:30:50
互換性の問題。

Ｃ言語などでは0x00という一バイトが文字列の終了を表す。
UTF8だと0x00は文字には使われてないから
ASCIIコードしか考慮してないコードでもそれなりに動く。

UTF16やUTF32だと、0x00という1バイトが含まれた
2~4バイトで構成された文字があるから既存のコードが動かない。
0728デフォルトの名無しさん2010/12/19(日) 02:00:19
保存やデータ交換はUTF-8でいいけど文字列処理はUTF-16でって言いたいんだろ。
char const*しか受け付けないライブラリが多すぎるからUTF-16に統一は無理。
0729デフォルトの名無しさん2010/12/19(日) 07:44:50
>>726
そのワイド文字がWindows APIでは２バイト。
１文字固定長でないのに。
0730デフォルトの名無しさん2010/12/19(日) 13:46:17
日本でシステム構築してる限りは合成文字もサロゲートペアも
たぶん出てこないから大丈夫
0731デフォルトの名無しさん2010/12/19(日) 13:54:14
濁点・半濁点の文字はそもそも合成文字だし、
今度の常用漢字の改定で「叱」の本字が
サロゲートペアになっちゃう領域に入ったし、
何で出てこないといっているのかわけわかめ。
0732デフォルトの名無しさん2010/12/19(日) 14:05:07
>濁点・半濁点の文字はそもそも合成文字だし、
そんなもんどこで使われてるんだよ。
0733デフォルトの名無しさん2010/12/19(日) 14:06:20
Macはファイル名を正規分解で扱うから濁点は分解される
0734デフォルトの名無しさん2010/12/19(日) 14:28:58
Macってなに?　それうまいの?
0735デフォルトの名無しさん2010/12/19(日) 14:31:35
>>734
グルメなvoidさんが愛用しているからうまいんじゃないの？
0736デフォルトの名無しさん2010/12/19(日) 18:26:34
グルメってのは味はわかってないけどうんちくだけ一流ってやつだよ。
0737デフォルトの名無しさん2010/12/19(日) 21:01:23
>>727
またその話か。前スレだか他スレだかで出たとき、結局どういう話なったんだっけ？
0738デフォルトの名無しさん2010/12/19(日) 21:08:27
8bit長と16bit長を同じに考えてるのが不思議
0739デフォルトの名無しさん2010/12/19(日) 21:13:32
>>737
fopenに飛び火したのならここに残っている
http://hibari.2ch.net/test/read.cgi/tech/1093251312/
0740デフォルトの名無しさん2010/12/20(月) 02:03:29
>>739
あー、結局、UTF-16でもUTF-8でもどうせ微妙だよって結論だったか。
0741デフォルトの名無しさん2010/12/20(月) 02:07:31
>>740
そうか？
単純にchar*に突っ込めるUTF-8があったからこそ
Unix/LinuxがUTF-8化できたようなものだって
結論だったと思うが。
0742デフォルトの名無しさん2010/12/20(月) 07:22:08
UTF-8は史上最高の符号化方式
Unicodeは史上最低のコード体系
0743デフォルトの名無しさん2010/12/20(月) 14:56:16
>>742
激しく同意、という言葉はこういうときに使うのか。
0744デフォルトの名無しさん2010/12/20(月) 18:33:27
>>743
激しく同意、という言葉はこういうときに使うのか。
0745デフォルトの名無しさん2010/12/20(月) 19:31:58
最低ってこたないだろ。全世界の文字を収録するという世界初の試みなのに
使い物にならなくもないレベルでよくまとまってる。
シフトJISみたいに無駄に文字の重複があったりする糞コードよりはマシ。
0746デフォルトの名無しさん2010/12/21(火) 00:51:11
でも多分、Unicodeをなかったことにして全く新しいものを築こうって流れは自分が生きてる間には来ないよね
0747デフォルトの名無しさん2010/12/21(火) 01:26:47
たとえtronコードがいかに素晴らしくてもUnicodeが使われる
0748デフォルトの名無しさん2010/12/22(水) 09:06:39
テキストファイルに保存するときのコードと
ＣＰＵ内部で演算処理するときのコードが
同じでなければならない、って考えがUNIX・LINUXでは根強い。
そもそも、テキストファイルとバイナリーファイルに違いが無い、って考えがある。
一方、Windowsやらjavaやらでは、内部と外部のコードが別でいいじゃん。
内部コードをユニコードに統一して、テキストファイルはシフトJISでもビッグ５でも
ＵＴＦ８でも何でもいいじゃん。入出力時にＩ／Ｏレベルで相互変換すればいいじゃん、って考え。
現代のインターネット時代ではありとあらゆるテキストファイルを混在処理しなければならないから。
UNIX・LINUXはコンソールアプリ時代の古い考えが捨てられないんだよ。
何しろ世界中何十万人？何百万人のユーザを捨てることになってしまうから。
Windowsはゲイツの鶴の一声でどうにでもなる。嫌でもゲイツに付いて行かざる終えないから
不満があろうが無かろうが長文疲れた文章のシメが思いつかん工業高校卒なので頭悪い許せうんこちんちん
0749デフォルトの名無しさん2010/12/22(水) 12:33:54
>>748
Gtk、Qtは内部はユニコードですよ
0750デフォルトの名無しさん2010/12/22(水) 13:04:12
それがどうかしましたか
0751デフォルトの名無しさん2010/12/22(水) 13:23:05
> UNIX・LINUXはコンソールアプリ時代の古い考えが捨てられないんだよ。
という考えが古いのではないかと
0752デフォルトの名無しさん2010/12/22(水) 13:44:54
「内部」が何を指してるのか知らないけどC標準関数にしろperlのビルトイン関数にしろ
英数以外使う気のない関数がやたら多い。
GUI系のライブラリは流石にその辺考慮してなんちゃってutf8に対応してみたり（SDLとかSDLとかSDLとか）
なんかBOMなんていうずれた対応してみたり（VSとか）
Windowsとか*nixとか関係なくて、OSとか言語作ってる連中はみんな英語圏なんだから英数以外まともに扱う気ねーよ。
0753デフォルトの名無しさん2010/12/22(水) 16:44:47
>>752
> Windowsとか*nixとか関係なくて、OSとか言語作ってる連中はみんな英語圏なんだから英数以外まともに扱う気ねーよ。
そのためにutf-8は作られたのではないか？
0754デフォルトの名無しさん2010/12/22(水) 20:33:00
以前にソースコードにエンコード情報を持たせないのが*nixの常道
（全てASCIIで構成）という話を聞いたことがあるんだけど、
それはその人の意見という話だったのかな
0755デフォルトの名無しさん2010/12/22(水) 21:54:42
プログラミングWindows（上巻）の冒頭で
65536文字あれば世界中の文字を収められるぜヒャッハーみたいな寝言が書かれてたり
CJK統合漢字みたいに「形が似てるから一緒でいいだろ＾＾」なんつー暴挙に出たり

欧米人の認識力の甘さには勃起を禁じえないぜ
0756デフォルトの名無しさん2010/12/22(水) 22:18:49
>「形が似てるから一緒でいいだろ＾＾」なんつー暴挙
素人質問で悪いんだが、どんな被害があるの?
原規格分離でシフトJISの違う文字は全て区別できるようになってるから
何が問題なのかわかりませぬ
0757デフォルトの名無しさん2010/12/22(水) 22:32:21
一緒
ー諸
ー諸
-1
‐1
0758デフォルトの名無しさん2010/12/22(水) 22:40:18
>>756
Han-Unificationのことでわ?
0759デフォルトの名無しさん2010/12/22(水) 22:48:03
>>754
それは、メッセージなんざリテラルで書くな全部メッセージカタログに追い出せ、という主張だったのではあるまいか。
0760デフォルトの名無しさん2010/12/22(水) 22:49:38
>>757
オマエ言いたいことわからない。死んだほういい
0761デフォルトの名無しさん2010/12/22(水) 22:49:43
－諸
0762デフォルトの名無しさん2010/12/22(水) 22:54:17
>>760
見た目に区別のつかない文字がいっぱいあるから もっと統合した方がいい、
という意見だろう。
0763デフォルトの名無しさん2010/12/22(水) 22:55:59
フォントだけを統合するの？コードも統合するの？
0764デフォルトの名無しさん2010/12/22(水) 23:23:31
どうしたらこの文脈でフォントの統一なんて解釈が出てくるのか不思議
0765デフォルトの名無しさん2010/12/22(水) 23:26:53
フォントというか字形（グリフ？）
コードまで統合されると形態素解析とか検索に影響が出るし。
0766デフォルトの名無しさん2010/12/22(水) 23:36:54
似ている文字は統合するなんてことは
しないほうが良かったね。

コードポイントのここからここまでは日本語文字
ここからここまでは中国語文字なんて
分かれている方が良かった。

そうすれば、テキストの中に中国語が含まれているかどうか
なんてチェックも出来た。

日本文字か、中国文字かわからなくて、ごっちゃになるなんて問題は
アプリ側で対応すればいい。検索の場合も、日本語の文字検索の他に
似ている形検索という機能をアプリ側に用意すればいいだけの話。
0767デフォルトの名無しさん2010/12/23(木) 00:58:18
これは陰謀だ
0768デフォルトの名無しさん2010/12/23(木) 16:31:03
Latin-1のA1hとLatin-15のA1hも違う文字にするの? アプリ死ぬよ?
0769デフォルトの名無しさん2010/12/23(木) 16:56:18
16ビットですべての文字を収録するなんて目標がハナから無理だとわかってれば（いや、わかってたわけだが）
統合しなかったかもね
0770デフォルトの名無しさん2010/12/23(木) 21:15:00
IPアドレス枯渇問題ににてるな
0771デフォルトの名無しさん2010/12/23(木) 22:01:17
>>748
いろんな入力が入ってくる可能性があるからこそ、出力はUnicode系文字コードが必要なんだろーが。
0772デフォルトの名無しさん2010/12/23(木) 22:02:13
国際化にあたっては、文字コード以外にも色々と(↓)考慮が必要なのに、こんな調子では…

・記述方向（右→左や双方向、縦書き）
・カーニングとかの組版ルール
・禁則処理ルール
・ソートルール　（A…Za…zとAaBb…Zzの違いとか）
・活用等による語形変化のルール
・主語・述語・目的語・etcの順序
・冠詞とか
・小数点/桁区切り記号の違い（例：ドイツ式→12.345.678,9）
・桁区切りの違い（例：インド式→12,34,56,789）
・負値の表記（ 1-だったり (1)だったり）
・通貨の表記（-\100だったり\100-だったり、小数点とかの記号が違ったり））
・日時の表記（年月日の順序バラバラ）
・13月まである暦
・測量単位系（メートル法/ヤードポンド法）
・用紙の規格（A?系/letter・legal系）
・スラング
・シンボル（国によっては十字架や六芒星はアウトとか）
・etc
0773デフォルトの名無しさん2010/12/23(木) 22:08:16
>>770
IPアドレス枯渇問題は、仕方ない。
v4ができた当時から、インターネットがこんなに発展することを見越した実装ってのは現実的じゃなかった。

一方、世界中の文字が65536文字で収まりきらないことは、調べりゃすぐに分かったはず。
0774デフォルトの名無しさん2010/12/23(木) 22:24:13
馬鹿は黙ってろ
0775デフォルトの名無しさん2010/12/24(金) 01:41:06
黙って書き込んだり、黙ってつぶやいたりする時代ですわ。
0776デフォルトの名無しさん2010/12/24(金) 07:34:58
>>773
IPv6が通常接続料金とは別料金を払わないと利用できないISPだらけなのが問題なのね。
IPv4を有料利用していればIPv6は基本的に無料にすればこんなにIPv6の立ち上がり
が遅い状況は生まれなかった。
別料金払ってまでほとんど利用しないIPv6を使うか？
ぜんぶISPが引き起こした問題で、解決するにはISPに責任を取ってもらうべき。
IPv4を通すトンネル接続じゃ意味ないんだけど。
0777デフォルトの名無しさん2010/12/24(金) 19:16:28
>IPv6の立ち上がりが遅い状況は生まれなかった。
そうか?　IPv6のメリットを村井純が説明できなかっただけだろ?
ISO-2022-JP2と同じく誰も相手にしてない。
0778デフォルトの名無しさん2010/12/24(金) 19:27:37
誰も相手にしていない。

自分を騙す必死の呪文ですw
0779デフォルトの名無しさん2010/12/24(金) 19:57:26
どこかのJavaスレに書かれてたけど、JavaっていまだにIPv6扱えないんだってな。
JAVAと言えばやっぱりJAVAのUTF-8は偽UTF-8らしい。

http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/jni/spec/types.html
> Java VM は、標準 UTF-8 の 4 バイト形式を認識せず、2 x 3 バイト形式を使用
0780デフォルトの名無しさん2010/12/24(金) 21:35:48
bmpに入らずんば文字にあらず
0781デフォルトの名無しさん2010/12/24(金) 23:19:52
>>779
いや使えるから。Cとかよりもよほど簡単に。スレにあったのは単にnioのバグだ。
あと偽UTF8はclassファイル内部のリテラル表現(とjarのフォーマットもか)の話で、通常のデータ入出力には関係ない。
0782デフォルトの名無しさん2010/12/24(金) 23:33:00
>>781
そのページ見るとJNIでJVMに渡す文字列は全て偽UTF-8なのでは?
0783デフォルトの名無しさん2010/12/25(土) 00:56:14
JVMの実装内部に関わる部分はたいてい偽UTF-8のような
その方が処理しやすいから・・・かどうか知らんけど
OutputStreamWriterとかCharsetEncoderとかString#getBytesとか
明示的にエンコーディング名に "UTF-8" って指定して使うやつは、普通のUTF-8で処理するのでは？
0784デフォルトの名無しさん2010/12/25(土) 04:13:49
>>724
>VC++でUTF-8の文字列リテラルを書けるようになって欲しいな。
無理。Windowsは実行ファイルに埋め込まれたANSIリテラルをUTF-16に変換する時、
システムデフォルトのコードページ(932)を使用する。
環境変数LANGで切り替える方式にしないと、シフトJISが埋め込まれた
既存のプログラムとUTF-8アプリの混在が不可能。
0785デフォルトの名無しさん2010/12/25(土) 05:25:27
>>784
え？
馬鹿？
0786デフォルトの名無しさん2010/12/25(土) 09:11:01
おまえがバカ
0787デフォルトの名無しさん2010/12/25(土) 09:40:04
日本国内しか対象にしていないアプリで日本語を埋め込もうが勝手
0788デフォルトの名無しさん2010/12/25(土) 10:05:25
>>784
お前、自分が言っていること良く考えてみ。

実行ファイルに埋め込まれたANSIリテラルを
実行時に切り替えるようにしろ。といってるんだぞ。

実行ファイルに埋め込まれた時点で、
なんらかの文字コードになっているわけで、
それをどうやって実行時に切り替えるんだよｗ
0789デフォルトの名無しさん2010/12/25(土) 10:57:06
>>788
何を言ってるのかさっぱり分からない。
0790デフォルトの名無しさん2010/12/25(土) 11:22:20
実行ファイルに埋め込まれているのか？
Windowsアプリも、AとWがあるが。
0791デフォルトの名無しさん2010/12/25(土) 11:42:12
特定の文字コードで文字列が実行ファイルに埋め込まれて、
Windowsからしたら与えられた文字列がsjisなのかutf8なのか区別がつかない
から無理と言ってるんだろ
0792デフォルトの名無しさん2010/12/25(土) 11:45:32
char8_t型があれば問題ないが、
C++0xドラフトには未だないね
0793デフォルトの名無しさん2010/12/25(土) 11:45:54
L""でない""のリテラルのことか？
0794デフォルトの名無しさん2010/12/25(土) 11:49:52
utf8を扱う文字列クラスでも作れば
0795デフォルトの名無しさん2010/12/25(土) 11:53:15
APIを使って表示したり文字列操作をしたりするのでなければ問題はない。
VC++でエディタから文字を直接入力してそれをUTF-8のリテラルとしてリソースに埋め込みたいんだろ。
ネットワーク関連の処理かな。
0796デフォルトの名無しさん2010/12/25(土) 11:58:10
UTF-8を扱うアプリなんぞいくらでも考えられる
エディタとか
0797デフォルトの名無しさん2010/12/25(土) 15:42:31
>784,788-791
コンパネの「地域と言語の設定」で設定したロケール情報を読み取るAPIが存在しますが。

例えば setlocale( LC_ALL, "" ) でC標準関数やMFCの挙動がロケールに即したものに変わる。
例えばドイツ語(ドイツ)だったら、マルチバイトテキストをcp1252として扱うようになるし、
printf( "%f", 1.23); の出力が「1,23」になる。
0798デフォルトの名無しさん2010/12/25(土) 15:48:19
だから、
char s[] = "日本語";
って文字列は？
0799デフォルトの名無しさん2010/12/25(土) 17:01:40
>>797
そんなもの呼ばなくてもA系API読んだ時点でシステムロケールが考慮されるでしょ。
それを考慮したって「プログラム中に埋め込まれたリテラル文字列」が変わるわけじゃない。

問題なのは、シフトJISを想定したファイルAのobjファイルと、UTF-8を想定したファイルB
のobjをリンクしただけで破綻すること。(Aが返した文字列をBでprintするとか)
これはアプリとkernel32.dll(A系API)のリンクについても言える。

結局、.objファイルごとにロケールのメタ情報を持つか、Unicodeみたいな統合文字コードを
持ってくるしかない。
0800デフォルトの名無しさん2010/12/25(土) 17:14:59
コーディングの手間を減らしたいってだけの話が
いつの間にかWindowsシステム内部における文字エンコードの扱いの話になってるのはなぜなんだぜ
0801デフォルトの名無しさん2010/12/25(土) 17:18:39
VC++って限定しているのか。
他のコンパイラを考えるとカオス。
0802デフォルトの名無しさん2010/12/25(土) 17:27:15
Windows内部でもVisual C++限定の問題ではないような・・・
GCCでもいろんな文字コードでリテラル文字列埋め込まれたら問題あるのでは?
0803デフォルトの名無しさん2010/12/25(土) 17:28:50
>799
文字列を扱う前に適切なタイミングでsetlocaleとかすりゃ、一応は混在可能。
プログラマにその辺意識させないようにするには、メタ情報とか必要だけどさ。

ちなみにリソース化しとけば言語情報は付加される。
1つのexe/dll内に複数の言語のリソースを混在させたり、
外部dllの形で言語を追加することも可能。
0804デフォルトの名無しさん2010/12/25(土) 17:30:09
ロケールは基本的に使わない方がいいと思う
ロケールってあまり当てにならない
08058032010/12/25(土) 17:33:55
>802
大丈夫だ、問題ない。
GCCもPGが setlocale(LC_CTYPE,...) とかで各々指定すりゃ良い。
0806デフォルトの名無しさん2010/12/25(土) 18:43:45
>>805
C++だけど、他人の作ったclass ore_exception::what()がどんな文字コードの
メッセージ返すか調べて、what()の度にsetlocaleするんですね。やってられんですよ。
what()の返す文字コードはコンパイル時に決まってるかもしれないんだよ？
自分(呼び出し側)のメッセージと連結したいときはどうすんのよ。
0807デフォルトの名無しさん2010/12/25(土) 18:56:56
もういいよ。「リテラル文字列どうすんの」って言ってるやつと、
それを理解しない「setlocaleでおk」の会話がループするだけ。

setlocaleって言ってるやつは、文字列を受け渡しするたびに
setlocale→mbstowcs→処理→setlocale→wcstombs　するわけ?
最初からwchar_tでやったほうがいいに決まってる。
08088052010/12/25(土) 19:03:53
可能ってだけで、それが現実的かどうかは別の話。
あくまで「不可能じゃない」だけ。

ちなみに「大丈夫だ、問題ない」は知らない人のために
ギャグのつもりだと断っておく。
08098052010/12/25(土) 19:07:47
>807
全体で統一すれば、一々setlocaleする必要ないじゃん。
そーいう意味では本気で問題無い。

とりあえず漏れは>784とかが「不可能」と言ったのに対して「可能」と返してるんであって、
実際無理かどうかはケースバイケースだと思うよ。
0810デフォルトの名無しさん2010/12/25(土) 19:54:22
VC++って、コメントに日本語書かなきゃ、ソースをBOM無utf-8にすると、
リテラルがutf-8になるよね。たぶん
0811デフォルトの名無しさん2010/12/25(土) 22:01:14
| char const msg[] = "あ";
このコンパイルが通らないのだが。
081212010/12/25(土) 22:40:13
みなさんお久しぶりです。>>265以来の>>1です。
このスレも隔離スレとして再利用されたようなので幸いです。
そろそろ次スレ立てなきゃいけませんよね。
「Unicode隔離スレ その3」でどうでしょうか
0813デフォルトの名無しさん2010/12/25(土) 22:43:23
おいやめろバカ死ね
0814デフォルトの名無しさん2010/12/25(土) 22:44:22
>>812
ここが先
http://hibari.2ch.net/test/read.cgi/tech/1291075205/
0815デフォルトの名無しさん2010/12/26(日) 01:06:55
UnicodeはUTF16だとあれほど（
0816デフォルトの名無しさん2010/12/26(日) 01:16:14
UnicodeがUTF-16なのはMS用語で、一般にUnicodeと言えば
文字コードに関する規格の名前。別におかしくないと思うが。
0817デフォルトの名無しさん2010/12/26(日) 02:46:35
JavaもUTF16だけど？
0818デフォルトの名無しさん2010/12/26(日) 06:43:26
>>811
一文字目にゴミが付いているからでわ？
0819デフォルトの名無しさん2010/12/26(日) 14:18:11
多分UTF-8だと(VCでは)コンパイルが通らないと言ってるんだと思われ。
0820デフォルトの名無しさん2010/12/26(日) 14:25:01
リテラルといえども￥があるからコンパイラが文字コード解釈しているのでは？
0821デフォルトの名無しさん2010/12/26(日) 21:57:00
UTF-8だとmsbitが立ったのが3バイトになるから、
閉じるための"を食ってると思われ
0822デフォルトの名無しさん2010/12/27(月) 17:23:44
思われ
0823デフォルトの名無しさん2010/12/29(水) 04:43:45
>>724が例に書いたu8"Hoge"ってUTF-8文字列リテラルは、
今度のC++の規格改正で導入される見込み。
g++でも4.5から使えるようになっており、VCも近い将来のバージョンで対応すると思うぞ。
0824デフォルトの名無しさん2010/12/29(水) 08:52:17
>>784とそれに連なる馬鹿共は一体なんだったんだ･･･
0825デフォルトの名無しさん2010/12/29(水) 10:58:55
u8""とやらの型がchar[]なのか別なのかがわからんが、
現在の規格のchar[]にutf8を入れると問題があることに変わりないだろ。
お前がバカ。
0826デフォルトの名無しさん2010/12/29(水) 11:42:11
VCってコメントとかもSJISなんでしょ。
u8""が対応したとして、中の文字コードは何で書くの？
0827デフォルトの名無しさん2010/12/29(水) 12:20:12
英語で書けばいいんじゃね
0828デフォルトの名無しさん2010/12/29(水) 16:36:30
>>826
ワイド文字列と同じで、VCならそーすは何で書いたっていい。
・今まで
　ソースUTF-8の 文字列→SJISに変換される
　ソースSJISの 文字列→SJISのまま
　ソースUTF-8の ワイド文字列→UTF-16に変換される
　ソースSJISの ワイド文字列→UTF-16に変換される
・u8""の対応
　ソースUTF-8の u8文字列→UTF-8のまま
　ソースSJISの u8文字列→UTF-8に変換される
0829デフォルトの名無しさん2010/12/29(水) 20:29:21
>>826
無知すぎ失せろ
0830デフォルトの名無しさん2010/12/30(木) 05:05:37
>>826>>828
GCCだって--input-charsetと--exec-charsetがあるよ。
0831デフォルトの名無しさん2010/12/30(木) 08:05:22
VCはソースファイルのエンコーディングを指定できないからウンコ
0832デフォルトの名無しさん2010/12/30(木) 08:13:23
character setとencodingの区別がついていない人たちなんですね
0833デフォルトの名無しさん2010/12/30(木) 08:15:41
VCはソースファイルのエンコーディングを指定できないからウンコ
0834デフォルトの名無しさん2010/12/30(木) 08:17:41
Windowsのシステムロケールを英語にして
ソースをUTF-8で書けばよい
0835デフォルトの名無しさん2010/12/30(木) 08:19:11
節子、それLatin-1や
0836デフォルトの名無しさん2010/12/30(木) 15:35:23
VCはソースファイルのエンコーディングを指定できないからウンコ
0837デフォルトの名無しさん2010/12/30(木) 15:45:56
VCでもファイルメニューから保存の詳細設定でエンコード指定できるけど
それじゃだめですのん？
0838デフォルトの名無しさん2010/12/30(木) 16:13:53
ファイルにBOMが付いていればUTF-16かUTF-8、付いてなければANSI(日本版なら
cp932)として強制的に処理しちゃうのよ。
0839デフォルトの名無しさん2010/12/30(木) 17:22:35
mbcsでは？
0840デフォルトの名無しさん2010/12/30(木) 18:17:34
1バイトのcode pageもあるから
0841デフォルトの名無しさん2010/12/30(木) 18:21:06
英語ならCP1252
0842デフォルトの名無しさん2010/12/30(木) 18:28:01
cp65001
0843デフォルトの名無しさん2010/12/30(木) 18:30:47
http://practical-scheme.net/chaton/gauche/a/2009/11/16
0844デフォルトの名無しさん2010/12/31(金) 09:38:02
Shift-JISで書かれたソースは日本語環境じゃないとコンパイルできないってありえねえ。
0845デフォルトの名無しさん2010/12/31(金) 09:40:01
いまどきはソースにSJIS埋め込まない
0846デフォルトの名無しさん2010/12/31(金) 09:44:11
VCって日本語のコメントを自動生成しなかった？
0847デフォルトの名無しさん2010/12/31(金) 13:55:27
VCはソースファイルのエンコーディングを指定できないからウンコ
0848デフォルトの名無しさん2010/12/31(金) 14:03:42
よそのスレで富士通のJavaのコーディング規約みたら、SJIS推奨だった。
SJISかもしくはEUCみたいな感じ。
0849デフォルトの名無しさん2010/12/31(金) 16:50:07
不治痛は納品先が官公庁だからかね
0850デフォルトの名無しさん2011/01/01(土) 00:21:00
S務省・B衛省相手に仕事させてもらってるけど、殆どUTF-8でOKだぞ。
それにプログラミング言語や文字コードで指定があることなんて
そんない無い。富士通が時代遅れの糞なんでしょ。
0851デフォルトの名無しさん2011/01/01(土) 01:19:47
誰かVC++の#pragma setlocale試してみないか？
http://msdn.microsoft.com/ja-jp/library/3e22ty2t.aspx
文字列リテラル・ワイド文字列リテラルの変換に使われると書いてある。
0852デフォルトの名無しさん2011/01/01(土) 13:42:13
MS用語でUnicodeはおそらくUTF-16 リトルエンディアンでfffeのボムつき
0853デフォルトの名無しさん2011/01/01(土) 14:45:25
SJISはウンコ
0854デフォルトの名無しさん2011/01/01(土) 23:08:01
理由は？
0855デフォルトの名無しさん2011/01/02(日) 00:43:34
>>854
Windows-31Jの文字しか扱えないし、日本以外のシステムに通すことが
できないから。
SJISは文字コードとしてはがんばったけど、もう引退すべき。
0856デフォルトの名無しさん2011/01/02(日) 00:52:57
hagedou
0857デフォルトの名無しさん2011/01/02(日) 00:56:04
うむ。
0858デフォルトの名無しさん2011/01/04(火) 17:41:42
だったらBIG5だってウンコじゃないか
0859デフォルトの名無しさん2011/01/04(火) 17:42:32
UTF-8はユニコード文字しか扱えないからウンコじゃないか
0860デフォルトの名無しさん2011/01/04(火) 20:27:04
UTF8はSJISと違って\マーク変換しても文字化けしない
0861デフォルトの名無しさん2011/01/04(火) 20:39:59
SJISはウンコ、CP932はウンチ
0862デフォルトの名無しさん2011/01/04(火) 20:43:34
ウンコとウンチの違いが分かりません＞＜
0863デフォルトの名無しさん2011/01/04(火) 20:47:36
どっちも触りたくないものにはちがいない
0864デフォルトの名無しさん2011/01/04(火) 21:57:05
>>860
でもWindowsだと~化けるよね
0865デフォルトの名無しさん2011/01/04(火) 22:18:40
規格決定する前に先走ってしまい、へたに大きなシェア抱えてるから、
引っ込みがつかなくなっていつまで立っても規格とマッチしない
ってのは、M$の場合よくある話
0866デフォルトの名無しさん2011/01/04(火) 23:43:37
ということで、みなさん。
規格決定まで突っ走らないように。

とくにHTML5関係。
0867デフォルトの名無しさん2011/01/06(木) 03:36:46
>>866
規格が決定するまで待ってたら後10年かかるだろ
0868デフォルトの名無しさん2011/01/06(木) 10:36:17
一方、SamsungはDDR4のDRAMモジュールを開発完了したと発表
0869デフォルトの名無しさん2011/01/06(木) 19:29:52
>>864
はつみみだな。詳しく教えてくれ。
0870デフォルトの名無しさん2011/01/06(木) 19:54:40
半角は7e、全角は波ダッシュ
0871デフォルトの名無しさん2011/01/10(月) 21:47:08
WindowsだとUTF-8で7eを保存して開くと文字化けするの?
0872デフォルトの名無しさん2011/01/10(月) 22:14:10
Windowsは関係ない。
それはアプリの仕様
0873デフォルトの名無しさん2011/01/10(月) 22:18:15
￣
0874デフォルトの名無しさん2011/01/11(火) 15:16:31
ちょいと質問です。

ビッグエンディアン環境で作成したUTF16の文章をリトルエンディアン環境で
読みとる場合ですが、こういう場合は自前でエンディアン対応を行うのでしょうか？
0875デフォルトの名無しさん2011/01/11(火) 15:24:42
お使いの言語の入出力ライブラリがそういった変換機能を提供してくれないなら、自前で対応せざるを得ません
0876デフォルトの名無しさん2011/01/11(火) 16:07:04
BOMあるなしにかかわらず判断できているライブラリはあるのでしょうかね・・・。

ひとまずUTF8であれば倍と並びの順はエンディアンに関係なく同じならびになるので、
BOM関係なく処理を行えると考えてよいのでしょうか。
0877デフォルトの名無しさん2011/01/11(火) 17:27:15
奇数バイト目に0が多ければビッグエンディアン、偶数バイト目に0が多ければリトルエンディアンなどと判断することができなくもありません
確実ではないけれど実用上はそれで問題ないと思いますが
0878デフォルトの名無しさん2011/01/11(火) 18:35:49
>>101
ソートだと後置のほうが楽。
まあどっちでも問題は起きる。
0879デフォルトの名無しさん2011/01/11(火) 19:56:19
>>877
ありがとうございます、チェックルーチンをでっち上げてテストしてみます。
0880デフォルトの名無しさん2011/01/11(火) 23:17:28
>>874が何を言いたいのかさっぱりわからん。
「保存データの仕様を明確にする」「LE/BEどちらでも読めるようにする」
この二つは基本だろ?
データから推測とか方向性を間違えているとしか思えん。
0881デフォルトの名無しさん2011/01/12(水) 01:39:16
「LE/BEどちらでも正しく読めるようにする」ためにはデータからどちらか判断する必要があるんじゃ…？
0882デフォルトの名無しさん2011/01/12(水) 06:50:40
必ずBOM付けるとかどっちかに運用で統一するとかメタ情報を
別に持たせるとか考えるのが先だろ。
完全な自動判別は不可能なのにデータから判断したいなんて
やはり方向性がおかしい。
0883デフォルトの名無しさん2011/01/12(水) 09:54:39
わざわざ面倒な自動判別を実装しようとするってことは
出力側をいじれない状況だと判断すべきだろうに
0884デフォルトの名無しさん2011/01/12(水) 22:36:17
882は経験不足
0885デフォルトの名無しさん2011/01/12(水) 22:59:13
何故UTF-16の文章を作らなきゃいけないんだ？
0886デフォルトの名無しさん2011/01/13(木) 18:36:53
>>885
そこにMSの環境があるからさ。
0887デフォルトの名無しさん2011/01/13(木) 18:58:31
BOMのないUTF-16は文章と言えるのだろうか？
0888デフォルトの名無しさん2011/01/13(木) 19:01:40
>>886
baka?
0889デフォルトの名無しさん2011/01/13(木) 19:19:07
>>888
aho?
0890デフォルトの名無しさん2011/01/13(木) 21:26:20
>>887
baka?

>>888
Windows 95が出たころはUTF-8なんかよりUTF-16の方がメジャーだっただろ。
古いソフトで設定ファイルやデータファイルがUTF-16になってるのをが時々見かける
0891デフォルトの名無しさん2011/01/13(木) 22:41:48
UnicodeとUTF-16の違いは何でしょうか？
0892デフォルトの名無しさん2011/01/13(木) 23:01:18
逆に聞くが、Unicodeは何を指す言葉だと思う？
0893デフォルトの名無しさん2011/01/13(木) 23:02:52
885は経験不足
0894デフォルトの名無しさん2011/01/14(金) 00:35:27
や、優しくしてください・・・
0895デフォルトの名無しさん2011/01/14(金) 20:20:40
ウニコードとUTF-8の違いについての俺的理解

・どっかの団体がウニコードを制定
・文字ひとつに、ひとつの整数値を割り当てる（この全体のセットがウニコード）


・アメリカ人がアスキーとチゲー、使いにくいと不満を漏らす
・アスキーコードをそのまま使えるように、ウニコードの整数値をいじくったのがUTF-8

この理解でおｋ？
0896デフォルトの名無しさん2011/01/14(金) 20:48:39
アメリカ人がインディアンは政治的に正しくないから作ったのがUTF-8
0897デフォルトの名無しさん2011/01/14(金) 21:17:30
>895
全然違う
文字セットとエンコーディングスキームを勉強しな
0898デフォルトの名無しさん2011/01/14(金) 21:30:54
問） Unicode UCS UTF を使って例文を作りなさい
0899デフォルトの名無しさん2011/01/14(金) 21:35:23
このスレッドは天才チンパンジー「アイちゃん」が
Unicode訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
UTF以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学UCS研究所
0900デフォルトの名無しさん2011/01/14(金) 21:46:25
もっとがんばりましょう
0901デフォルトの名無しさん2011/01/14(金) 22:41:32
unicode内部の混乱の大きな原因は二つ
Microsoftの独自な解釈による unicode という言葉の混乱
Appleの独善的な解釈による uicode の実装の混乱
0902デフォルトの名無しさん2011/01/14(金) 22:48:23
Googleに収集つけてもらうか
あそこは嫌でも世界中の文字と言語扱わなきゃいかんわけだし
0903デフォルトの名無しさん2011/01/14(金) 22:49:29
収拾
0904デフォルトの名無しさん2011/01/14(金) 23:03:07
>>895
UTF-8は史上最高の符号化方式
Unicodeは史上最低のコード体系
0905デフォルトの名無しさん2011/01/14(金) 23:16:23
マークアップ言語からしてASCIIで決め打ちだからUTF-8が幅効かせるのは仕方がないぜよ
JIS漢字の罫線でマークアップすればスゲーシンプルに人間様にも見やすくなりそうなんだけど米製の先行規格が死ぬ事はないだろうし
0906デフォルトの名無しさん2011/01/15(土) 00:04:26
いくらTronコードが(実際はどうあれ)優れていても、世界標準とはならないのだよ。
0907デフォルトの名無しさん2011/01/15(土) 01:34:14
UTF-8考えた人って天才だよね
0908デフォルトの名無しさん2011/01/15(土) 01:50:04
誰だろうと思って調べてみたら、
UNIXにバックドア仕込んで14年間バレなかったケン・トンプソンじゃねえか
0909デフォルトの名無しさん2011/01/15(土) 03:42:54
文字に番号つけたのがうにこーど
その番号をどうやって表現するか、メモリやファイル上にどう並べるかを決めたのがUTF

…であってる？
0910デフォルトの名無しさん2011/01/15(土) 09:30:52
うん
0911デフォルトの名無しさん2011/01/15(土) 10:11:12
UnicodeとTronコード、なぜ差が付いたか 慢心、環境の違い
0912デフォルトの名無しさん2011/01/15(土) 10:28:18
日本の規格はアメリカに潰されるんだよ
スーパー301だのなんだの突きつけて国内でしか使えない
それなのにガラパゴスだなんだと言われるのは理不尽だよな
0913デフォルトの名無しさん2011/01/15(土) 10:36:44
この際、ビットマップをそのままコードにすればいい。
16x16 = 256bit = 32バイト
0914デフォルトの名無しさん2011/01/15(土) 10:54:07
>>911
超漢字ってちゃんと考えて作ってんのかって感じがする。
よく知らんけど。
0915デフォルトの名無しさん2011/01/15(土) 11:05:05
>>913
どうやって

龍龍
龍龍

を16*16で表すんだ？
0916デフォルトの名無しさん2011/01/15(土) 11:07:37
そんなネタ漢字は表さなくてよいが、16ドットで充分なのかという話には興味がある
0917デフォルトの名無しさん2011/01/15(土) 11:46:37
16ドットは、第2水準にもなるとかなり苦しい。24ドットはほしいね。
0918デフォルトの名無しさん2011/01/16(日) 00:31:54
ことしは庭でアサガオ育てたんですよ。アサガオ。
みんなも小学生のこと育てたことあるでしょ。
ツルをきれいにネットにはわせるために、
いったん人手でほどいて、巻きなおしたりするんです。
そのとき思ったんです。アサガオのツルはどっち巻きだっけ？って。
ネットで調べたら、「右巻き」って書いてあるとこもあれば「左巻き」って書いてあるとこもあるんです。
ワケわかんなくて、もっとよく調べたら、なんと
0919デフォルトの名無しさん2011/01/16(日) 00:38:03
すんません、途中で書き込んでしまいました。アサガオのツルの話の続きです。
なんと、「右巻き」と「左巻き」は同じ巻き方なんです！

下から見て「右巻き」、上から見て「左巻き」だったんですよ。
どっちの方向から見るかという前提条件を決めずに、「右だ」「左だ」と論争してたんですね。
なんか、このスレの「ユニコード」論争と似てるような気がします。

ちなみにアサガオは、江戸時代は上から見るのが一般的で、したがって「左巻き」とされていました。
現代では下から見るのが一般的で、したがって「右巻き」とするらしいです。
0920デフォルトの名無しさん2011/01/16(日) 00:52:44
http://www.restspace.jp/gazo/img-box/img20110116005202.gif
0921デフォルトの名無しさん2011/01/16(日) 01:39:43
ANSIってのも普通に意味不明な表現な気がする
0922デフォルトの名無しさん2011/01/16(日) 13:20:40
> みんなも小学生のこと育てたことあるでしょ。
0923デフォルトの名無しさん2011/01/16(日) 13:23:43
ついにこのスレからも逮捕者が…
0924デフォルトの名無しさん2011/01/16(日) 13:32:54
右巻きって・・・どっちだよ。
0925デフォルトの名無しさん2011/01/16(日) 14:27:00
たぶん、時計回り(clockwise)
0926やんやん ◆yanyan72E. 2011/01/16(日) 14:27:24
普通のネジの向き
0927デフォルトの名無しさん2011/01/17(月) 00:36:45
チンコが微妙にねじれている場合、自分から見た右巻きか
相手から見た右巻きか、どちらで説明するのがよいでしょうか?
0928デフォルトの名無しさん2011/01/17(月) 09:43:45
右巻きのウンコと左巻きのウンコ
0929デフォルトの名無しさん2011/01/17(月) 12:35:36
utf-8のページの入力フォームの内容をメールで送る処理して困るがいい
0930デフォルトの名無しさん2011/01/17(月) 12:42:26
いまどきメールもUTF-8でしょ？
0931デフォルトの名無しさん2011/01/17(月) 12:44:23
ケータイ
0932デフォルトの名無しさん2011/01/17(月) 12:52:56
入力内容をsjisにして出力せよと頼まれて、
ハイフンのような文字をハイフンに修正するような処理を延々追加するがいい
0933デフォルトの名無しさん2011/01/17(月) 14:21:51
文字化けしてますよ
0934デフォルトの名無しさん2011/01/17(月) 14:44:54
>>748
UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。
(BSD系のlibcみたいに独自内部コードのものもあるけれど)
後は状況に応じて使い分けてる。特に外部コードに対する柔軟性が大きい。

Windowsみたいにファイルシステムごとに文字コードが決まってるなんて
決め打ちは殆ど無いよ。
0935デフォルトの名無しさん2011/01/17(月) 14:50:25
>>934
> Windowsみたいにファイルシステムごとに文字コードが決まってるなんて
> 決め打ちは殆ど無いよ。
MacOSXはUnixに入りますか？
0936デフォルトの名無しさん2011/01/17(月) 15:18:35
>>934
>UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。
「内部」ってどこのこと？
0937デフォルトの名無しさん2011/01/17(月) 16:48:54
> UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。
キミの言っているUNIXってどれとどれの事?
ほとんどと言ってるので複数あるんだよね。
0938デフォルトの名無しさん2011/01/17(月) 16:54:44
>>934
そりゃ何十年前の知識だ？
0939デフォルトの名無しさん2011/01/17(月) 17:29:07
何十年前でも正しくないだろう・・・
0940デフォルトの名無しさん2011/01/17(月) 17:42:00
UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。

翻訳後

(僕が唯一知ってる)UNIX(らしきOS)は今は "ほとんど内部がUTF-16" 、外部がUTF-8ですよ。
0941デフォルトの名無しさん2011/01/17(月) 17:51:54
内部と外部の定義から始めないとフレームの元になるな。
0942デフォルトの名無しさん2011/01/17(月) 17:58:07
「内部」の意味のわからないヤツって何？
コンピュータのことまともに勉強したことないの？
初心者むけにやさしく教えてあげるよ。
（少しだけウソを書いてるけど、わかりやすくするため、わざとだよ）

まず、ＣＰＵにはレジスターというものがあって、すべての計算処理はレジスターでおこなう。
文字も扱うときもレジスターでおこなうんだよ。
「内部」って言うのはレジスターのことだと思うといい。

このレジスターというのは、８ビット、１６ビット、３２ビット、６４ビットと変幻自在
どう扱うかはプログラマーが自由に決められる。
たとえばインテルＣＰＵのばあい、同じ１本のレジスターが
AHレジスタと呼べば８ビット、AXレジスターと呼べば１６ビットに化けてくれる。

「１文字」をレジスターに収める場合、８ビットレジスターを使うか１６ビットレジスターを使うかも
自由に決められるんだけど、Windowsは１６ビット、UNIXは８ビットを使うのが習慣となっている。

ところで、漢字１文字は８ビットレジスターには入りきれない。
Windowsは１６ビットレジスターを使うことに決めてある。このしくみと相性がいいのがUTF-16。
一方Linuxは８ビットにこだわり続けてるから漢字を扱うには８ビットレジスターで２回または３回に分けて処理をおこなう。
このしくみに相性がいいのがUTF-8だな。
0943デフォルトの名無しさん2011/01/17(月) 18:03:02
Linuxは「１文字は７ビット」にこだわり続けています。
Windowsは過去のしがらみを捨てて「１文字は１６ビット」としました。
これを「ニューテクノロジー」といいます。Windows NT の「NT」です。
0944デフォルトの名無しさん2011/01/17(月) 18:06:50
このスレどうなっちゃうんですか？
0945デフォルトの名無しさん2011/01/17(月) 18:15:30
>>942
インディアンもやさしく教えてください
0946デフォルトの名無しさん2011/01/17(月) 18:21:25
>>943
> Windowsは過去のしがらみを捨てて「１文字は１６ビット」としました。
> これを「ニューテクノロジー」といいます。Windows NT の「NT」です。
さらに１文字３２ビットに進化しました。
これを「みかか」といいます。
0947デフォルトの名無しさん2011/01/17(月) 18:37:26
>>944

>>950 を踏んだひとが次スレを立てて引き継がれます
0948デフォルトの名無しさん2011/01/17(月) 18:39:52
>>947
残念、次スレはもう用意されています
http://hibari.2ch.net/test/read.cgi/tech/1291075205/
0949デフォルトの名無しさん2011/01/17(月) 19:37:17
全然関係ないけど、VC++でBMP面の文字を1文字も落とすことなく
完全にやりとりするにはlocaleをどう設定したらいいの？
095012011/01/17(月) 21:03:04
みなさんお久しぶりです。>>1です。
不本意ながら次すれは↓で行きたいと思います
http://hibari.2ch.net/test/read.cgi/tech/1291075205/l50
095112011/01/17(月) 21:12:38
>>942さん
>「内部」って言うのはレジスターのことだと思うといい。
レジスタとかCPUというのはプログラムを実行するための装置で
あって、「内部」がどのプログラム(or 保存データ)を指して
いるのかの説明が無いと意味がないと思うのです。
0952デフォルトの名無しさん2011/01/17(月) 21:26:16
マトモなこと言うとは>>1のくせに生意気
0953デフォルトの名無しさん2011/01/19(水) 19:38:42
>UNIXは今はほとんど内部がUTF-16
確認だけど、これ嘘だよね？
0954デフォルトの名無しさん2011/01/19(水) 20:07:54
内部だけにナイーブな問題だな・・・
0955デフォルトの名無しさん2011/01/19(水) 20:14:15
>>953
FATをマウントするには内部でUTF-16使わんとだめだろ
0956デフォルトの名無しさん2011/01/19(水) 20:17:00
だからその内部ってなんだよｗ
0957デフォルトの名無しさん2011/01/19(水) 20:23:17
三重県四日市市小古曽三丁目
0958デフォルトの名無しさん2011/01/19(水) 21:14:34
少なくともファイルシステムのファイル名はマルチバイト文字列のまま
0959デフォルトの名無しさん2011/01/19(水) 22:10:55
Unicodeもマルチバイト文字列なんだがｗ
0960デフォルトの名無しさん2011/01/19(水) 22:32:25
Unicodeだけではないということだねえ。
0961デフォルトの名無しさん2011/01/19(水) 23:07:40
合成文字が存在する限り、UTF-32を使ってもマルチバイトになるなぁ。
0962デフォルトの名無しさん2011/01/19(水) 23:22:57
>>958
バカ丸出し
0963デフォルトの名無しさん2011/01/19(水) 23:40:00
>>961
バカ丸出し
0964デフォルトの名無しさん2011/01/20(木) 00:47:00
>>959 でちょっと純粋に疑問に思ったんだけど
「Unicode」と呼ばれる部分だけで「文字列」は表現できるの？
0965デフォルトの名無しさん2011/01/20(木) 01:07:20
文字コード表だけでエンコード方法なしでは、コンピュータ上に1文字足りとも表現できないだろうね。
0966デフォルトの名無しさん2011/01/20(木) 10:35:42
↑
またLinuxバカが沸いたか。一生７ビット地獄で苦しんでろ。
0967デフォルトの名無しさん2011/01/20(木) 11:08:31
相変わらずドザはバカだなぁ
0968デフォルトの名無しさん2011/01/20(木) 12:41:46
>>966
バカ丸出し
0969デフォルトの名無しさん2011/01/20(木) 16:43:11
>>957
それは「うつべ」
0970デフォルトの名無しさん2011/01/20(木) 21:41:55
内部線＝ISO-2022-JP
南大阪線＝CP932
名古屋線＝UTF-8
0971デフォルトの名無しさん2011/01/21(金) 00:25:38
Linuxで8bit cleanじゃない実装ってどの部分だろう？
Linux(というか大半の*nix系)はOSとしてはバイナリとして扱うから
application側でlocaleに従って適宜運用してくれというスタンスだと思うが
0972デフォルトの名無しさん2011/01/21(金) 07:30:05
内部はおなか、外部はウンコ
内部に問題があるとウンチになる
0973デフォルトの名無しさん2011/01/21(金) 11:16:07
腸は身体から見ると外部なんだよ
0974デフォルトの名無しさん2011/01/21(金) 11:30:45
>>973
人間の体でクラインの壷ってできるかな？
0975デフォルトの名無しさん2011/01/21(金) 20:43:43
「白線の内側にお下がりください」を線路に降りて死ねってことかとか言ったことあるな
0976やんやん ◆yanyan72E. 2011/01/21(金) 21:44:36
白線の上に爪先立ちしてる奴もいた。
0977デフォルトの名無しさん2011/01/22(土) 12:50:42
白線＝ISO-2022-JP
黄色い線＝CP932
ホームドア＝UTF-8
0978デフォルトの名無しさん2011/01/22(土) 13:37:16
駅員が持ってくるタラップ=ASCII
0979デフォルトの名無しさん2011/01/22(土) 19:51:57
酔っ払ったおぢさん＝EUC-JP
0980デフォルトの名無しさん2011/01/23(日) 03:42:21
ISO-2022-JPって、Internet Explorerで見れないやつか?
0981デフォルトの名無しさん2011/01/23(日) 03:55:18
ISO-2022-JP は IE でも見れる
EUC とか UTF-8 とか charset= が書いてないとだめ
0982デフォルトの名無しさん2011/01/23(日) 04:09:31
いつの時代のIEだよ。
0983デフォルトの名無しさん2011/01/23(日) 09:25:00
4ぐらいじゃね？
0984デフォルトの名無しさん2011/01/23(日) 14:21:57
いや、最近IEを更新すると、
META書いてあってもISO-2022-JPが化けるようになった。
0985デフォルトの名無しさん2011/01/23(日) 17:03:21
>>984
ISO-2022-JP は IE でも見れるって
話じゃなかったのか？
見れなくなったのか。
0986デフォルトの名無しさん2011/01/23(日) 21:39:59
>>985
http://blogs.msdn.com/b/ie_jp/archive/2010/12/17/ms10-090.aspx
0987デフォルトの名無しさん2011/01/23(日) 22:57:09
HTTPヘッダだと認識してhttp-equivで認識しないってなんだよ。
いずれにせよHTMLでのISO-2022-JPに未来はないと。
レス数が950を超えています。1000を超えると書き込みができなくなります。