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

前スレでなんとなくわかったのですが、インディアンがどうとかいうあたりで
話について行けなくなりました。

次スレいるのかよｗ

すみません。まだよくわかりません。
自分の理解では　↓

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

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

疑問点
・UTF-8とインディアンの関係は？
・UnicodeとUTF-8が別モノなのにBOMがUnicodeのしるしというのがよくわからない

UTF-8はエンディアン関係無いよ。これは1バイトずつの並びだから
どのCPUでも扱いは同じ。
Unicodeの表を元に実際のバイトの並びを決めた方式の一つがUTF-8

BOMはUnicode（≒UTF-16と思っていいか？）には必須だが
UTF-8の場合、このファイルはUTF-8でエンコードされてると
わかるためのしるし。
何も無かったらそのユーザーの環境で普通に使われてるエンコーディングと
判断されるケースが多い。

ビットで表すと、、、
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

こんな感じ。何が入ってるか事前にわからないとエンコードできないでしょ？

>>4
あれーでもUTF-16はBOM省略可能では？(Unicode規格2.6章)

>>5
>16ビットのUNICODEの表で
Unicode表はバイトデータと関係ないから「16ビットの表」っていう表現はおかすぃ

ところでUCSって何?
Unicodeとは別モノ?

>>3
{UTF-8, UTF-16}　∈ Unicode

こういう包含関係があるのがUnicodeとUTF-8との違いだよ

それは
{UTF-8仕様, UTF-16仕様}　∈ Unicode規格
の話な。
ここで議論しているのはUnicode規格でなくUnicode文字集合の話だ。

えっ

なんでこんなしょもないスレの次スレなんか立てるんだよ...

せめてスレタイを汎用化してほしかった。
Unicode総合スレとか。

とりあえず前スレ

UnicodeとUTF-8の違いは？
http://pc12.2ch.net/test/read.cgi/tech/1177930957/

Unicode ⊃ { USC-2, UCS-4, UTF-8, UTF-16 }
USC-2 : 1文字2バイトの文字集合
USC-4 : 1文字4バイトの文字集合
UTF-8 : 文字コードを文字集合にマッピングする変換規則の一つ（ひとつの文字を表す文字コードの長さは1バイトから6バイト）
UTF-16 : 文字コードを文字集合にマッピングする変換規則の一つ（ひとつの文字を表す文字コードの長さは2バイト（但し一部の文字は二つの文字コードを使って一つの文字を表す））

ところでお前らUnicodeって言ったらUnicodeコンソーシアムの規格かISO/IEC10646か
どっちを指すわけ？
Unicodeコンソーシアムの規格にはUCSなんて概念は無いわけで。

それを知るためにここにきますた

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バイトになると、なるほど。

UTF-8って1〜6じゃなくて1〜4バイトの可変じゃねーの？

>>18
セキュリティーにうるさい環境では4バイトまでしか認めないけど、20年
前から絶対防御を実現しているLinux等は、いまだに6バイトまで許容して
います。
まあ、JavaやWindowsは脆弱すぎるってことです。

>>18
フラットな4バイト空間をどうやって1から4バイトの可変長の空間に詰め込むんだよ。

>>19
意味わかんね。何で仕様の話にセキュリティーが出てくるんだよ。

>>19
規格嫁。Unicode 5.2.0の2.5章にUTF-8は最大4バイトと書いてある。

>>21
意味がわからなかったら危険。

>>21 ISO 10646 対応ってことでそ

>>19
どうやって詰め込むかは3.9章に書いてある。

煽りあい気味の意見交換は前スレで散々やったからこのスレでは控えめに行こうぜ

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バイト以上の表現を許容していることにより、正しくない実装をおこったバグ
｜のあるシステムにおいてエンコード時にバッファオーバーフローが発生する可能性も指摘されている。

アンカミスったし(>>19→>>20)、ageちまった。スマン。

でもUnicodeっていったらUnicodeコンソーシアムの規格じゃねーの？
ISO 10646って言ったらUnicodeじゃなくてUCSっつーイメージがある。偏見？

>>19
JavaやWindowsには既知の『正しくない実装をおこったバグ』が存在
しているということですね。
具体的にWindowsのKB番号など教えていただけないでしょうか。

>>27
いや、ノーガード戦法こそ唯一絶対のセキュリティーって話。
セキュリティーが甘いからノーガード戦法が出来ないんだろ？

よくわかりませんが、Linuxはノーガードということなのですね。凄いです。

Windows：細かいところが甘いから6バイトまで使えるところを４バイトに縛って強制的に安全化を図っている
Linux：細かいところまで大丈夫なので４バイト縛りなどのセキュリティーを入れる必要がない

って事が言いたいんでしょ。

>>30
いや、さすがにそこまでは言っていない。
というか、細かいバグの多さならLinuxが最高峰だし。

>>15
ISO/IEC 10646はUnicodeではありません。
よってUTF-8が6バイトとか、UCSがどうとか言っている奴はスレ違いということで。

ただ、ノーガード戦法がセキュアって言うのは常識だろ。
たとえば、Linuxで広範に使われているlibxml2。
これは、エンティティー参照によく知られるバグを持っているけど、
そのまま使うと危険だから、賢い人なら自力で回避して使う。
Gnomeはlibxml2をそのまま使っているから、実際危険な使い方が出来る。
だから、賢い人ならGnomeを使わず、TWM+XFMで環境を構築する。
こうやって賢く安全な使い方が普通に出来てしまうのがLinuxの良い
ところだ。
Windowsではどうだ？
エクスプローラに脆弱性があるからと言って、代替製品に置き換えて
使う人がどれだけいる？
つまり、与えられたセキュリティーなど無意味。
何も与えない、ノーガードこそが一番安全なのだ。

>>33はクレイジー

>>34
クレイジーってなんだよ？
Linuxが6バイト許容なのもエンティティー参照の問題もセキュリティーの
啓蒙のためにそうなっているんだよ。
痛い目にあえば、ユーザーは気をつけるようになるだろ？
「誰も信用するな」がセキュリティーの基本原則だ。
こういった啓蒙活動のおかげでLinuxユーザーは賢くなり、Linuxは最高の
セキュリティーを手に入れることが出来た。
これがフルオープンの力だ。

ふむふむ、Linuxは広範囲に使われている基幹dllに脆弱性があっても修正されないのか

これ以上俺の腹筋を痛めないで欲しいなぁ

>>14
UTF-8に関しては日本語が3バイト、英数字が1バイト
UTF-16は日本語が2バイト、英数字が2バイトで

日本語の量が多いファイルではUTF-16が容量節約に適して
日本語より英数字が多いファイルではUTF-8が容量節約に適しているって
解説しているサイトがあったなあ

そもそもASCIIコードと互換性のないUTF-16なんてなんで作ったの？

移行できると思っていた

アメリカ野郎にとってはASCIIで対応してる文字にわざわざ２バイト以上使うなんてクレイジーでしかないからね

ASCIIは永遠に使われ続けるだろ

たかが１バイト増えるだけだが
1が2になると倍だしな

wikipediaのUTF-8の項目に
＞UTF-8はISO/IEC 10646(UCS)とUnicodeで使える8ビット符号単位の文字符号化形式及び文字符号化スキーム。
とあるのですが一般的に使われているUTF-8はISO/IEC 10646を使ったものですか？それともUnicodeを使ったものですか？
ttp://ja.wikipedia.org/wiki/UTF-8

>>44
実際に使われているUTF-8のデータから、両者の違いを見分けることはできないと思うよ。

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

ついでにUCS-4はUnicodeと同じ21bitの範囲までしか文字を入れない決まりになったしね。

�T�U�Vとか�@�A�Bってなんの問題が?

機種によってコードが違ったり無かったりしたからな

>>41
でも日本人の場合、EUCとかSJISで対応してる文字にわざわざ３バイト以上使う
クレイジーな奴が多いんだよな・・・

UTF-8って日本語3バイトになるのか
知らんかった

そりゃあ日本独自のそれこそガラパゴスよりは全世界共通のグローバルの方が見た目かっこいいからだろうな。

SJISは海外アプリが食ってくれない事が多々あるし、EUCは日本人でも使ってる奴が少ない。
最大でもせいぜい1.5倍にしか増えないなら、使う価値は十分あると思うが。

>>46
Unicode的には全く問題ない。

外国の混じりにしたらとたんにSJISのソースじゃやっていけなくなった・・
まあ直接埋め込む方が悪いがｗ

>>44
そらUnicodeだろ。IANAもRFC3629もUnicode。

>>46
シフトJISで後から追加された文字。いわゆる機種依存文字なのでWinのシフトJISを
Macに持って行くと文字化けする。Unicode系のコードでやりとりすれば>>52の言うとおり問題無い

UNIXやLINAXはEUCなのになんでEUCが世界を支配してないの?

えっ普通LinuxはUTF-8じゃないの？
それはともかく多言語を同時に扱えない文字コードはちょっと・・・

PARLだかパールだか
サーバーサードスクリプトがはやったときどのプロバイダもFTPでEUCのHtmlをアップさせてたじゃん

>>55
基本的に殆どのソフトウエアのコア部分は海外で作られる。
Windows、Mac OS X、Linux、FreeBSD、NetBSD、OpenBSD、
Plan9、gcc、glibc、perl、php、Python、vi、emacs等

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

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

その点Unicodeは各国語の文字が単一の文字集合に入っているし、
その取り扱い方法も規定されているので、Unicodeを扱えるように
プログラムを書けば、各国語の文字を扱えるようになるという便利さがある。

>>57
今perlはutf-8がデフォルト文字コードだよ。

perlはスクリプトをutf-8で書いて、入力時に希望の文字コードからutf-8に変換して、
出力時にutf-8から好きな希望の文字コードに変換する、という方法が確立されたかららくちん

>>55
Unicode系じゃないとコンパイル時と実行時に文字コードの情報が必要になって
面倒なんだよ。Unicodeならその国の文字は読めなくても文字化けしない。

WindowsServerとSQLServerが無料になったら使う

お前は一生シフトJIS使ってればいーよ

すんげー亀レスだったりレスつけすぎだったりだけど規制解除がうれしくてはしゃいでるだけだから許してちょ
あと、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にさえしてくれれば世界中の言語に対応したのを作れるといったら、それくらいの手間はかけてくれるかもしれない。

知ってるぜ。昔HTMLで文字コードを認識させるために
<!-- 美乳 -->
って書いたんだよな。他人が見たらびっくりだ

> UCSってあんまり知らないんで
たふん
　UCS→規格ISO/IEC 10646のこと
　UCS-2/UCS-4→テキストエンコーディング
UCSの文字集合は、何だろうね。規格で定められているのかな。

UTF-8のプレーンテキスツで利用させてもらうわ「美乳」

>>66
すまん説明が悪かった。
EUC-JPのHTMLページを文字化けさせない時に「美乳」を使う。
UTF-8ならBOMがあればいいでしょ。

>>65
UCSは文字集合で、エンコーディングじゃ無いよ。

ホームページのファミコン.icoだかfamicon.icoってなに?

faviconだろ

ｆａｖｏｒｉｔｅ　ｉｃｏｎの略だろ。
お気に入りに追加するときに自動的にダウンロードされる。

ていうか、unicodeどころか文字ですらない。

そういやSolarisってUCS-4なのな。
マイクロソフトも もう少しUnicode対応が遅ければUTF-32採用されていただろうに。

UCS-4 or UTF-32の何がそんなに嬉しいのかね。
コードポイントは32bitの固定長だけど、
どのみち結合文字があるから1文字は可変長なのにね。

一文字何バイトにしようと
半角カナの濁点や合成用濁点をその前の仮名文字と組み合わせる必要が
なくなるわけじゃないのにね。

読めない読む必要のない言語はトーフで十分なんだから
末端ユーザの文書なんて不可逆にEUC等のローカルコードに変換して保持すりゃ十分だよne

Unicode←→EUC-JPの変換がどれだけ地雷原なのかも知らんのか…

>>76
その文書を入力として読み込むことがないのなら。
入力しなけりゃ、二度と出力もできないが。

>>77
unicodeに戻す必要があるのならね

>>74
code pointとgraphemeの区別が付いていないんだろうね。
文字として扱う場合はいずれにしても可変長処理になるから、UTF-16の
サロゲートペアとかも些末な問題なんだけど、延々的外れな主張が繰り返される。

>>77
マッピングテーブル2回通すだけだろ

>>81
そのテーブルが問題なんだよ

FirefoxからEUC-JPの掲示板に投稿すると一部の文字がIEで読めなくなるとか
Safariから円記号を投稿すると文字化けするとか
いずれもUTF-8なら問題ない

>>82
何か問題ある？
UTF-32→(普通のマッピング)→SJIS→(IBM拡張をマッピング)→SJIS→(計算式)→JIS→(計算式)→EUC
でしょ。
一つ目のテーブルはUnicodeコンソーシアムのtxtファイルからソース生成した。
二つ目のテーブルはシコシコと自作した。

EUC-JPはいらない子過ぎる･･･

ああ思い出した。マッピングテーブル作る時に「X 0208」「NEC特殊」「NEC選定IBM拡張」「IBM拡張」
とマッピング先が複数候補有るので小細工が必要だったかも。
どの文字領域で重複してるか一文字ずつ調べてく単純作業が必要だった。
計算式と一般公開データだけでできると思ったら確実にはまるね。

フロントエンドプロセッサを日本語に訳すと?

前の方を処理してくれる女

>>86
Shift-JISとCP932でマッピングが違う記号がいくつかあるし

イミフメ。CP932がシフトJISじゃないとでも？

£がU+00A3になったりU+FFE1になったりして困った経験がないんだろうな

色色問題あるけど、代表はasciiのバックスラッシュをJISの円記号と解釈する(cp932)かJISのバックスラッシュと解釈する(sjis)かだな。

おまいらの言う「sjis」って何よ？
JIS X 0213に\(5Ch)をUnicodeのどの文字にマッピングするかなんて書いてあったっけ？

お前ら本当にUnicode好きだな。
そろそろ次スレ立てるか？
スレタイは「Unicode総合スレU+0003」

お前３行目言いたいだけだろ

お
そ
ス

誰もCP932と「sjis」の違いを説明できないんですね。残念です。

で「sjis」って何よ？
定義は？

sjisはJIS X 0208:1997のシフト符号化表現
cp932はANSIコードページの932
規格が違う、としか言いようがない。
日本のチョコレートがベルギーではチョコレートとみなされなかったりするのと同じようなもんだ。

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では
　　バージョンにより実体が異なる。

これでどうでしょ。
間違ってたら適当に修正よろ。

>>98,99
そのJIS X 0208にUnicodeとのマッピングが書いてあるのかよ。話をすり替えるな。

俺はJIS X 0213とhttp://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
ぐらいしか知らない。
>>89の言う「Shift-JISのマッピング」って一体何なのよ？

そういや、なんで異字体セレクタって後置なの？
前置にしとけば、何か漢字1文字読んだ後に異字体セレクタなんて付いてない可能性高いのに
念のためもう1文字読む、という手間が省ける気がするのだが。

>>100
いや、誰がどう言おうと、sjisの定義はそれなんだから仕方ない。
>>89が言いたかったのは波ダッシュ問題のことだとは思うけど、
それはsjisの定義そのものとも、sjisとは何かとも関係がない。

>>102
いや、関係ないは言い過ぎだな。
sjisがJIS X 0208:1997に完全に基づいてるとしたら、それをUnicodeに変換するときは
JIS punctuationに従うって考えるのが自然だろうし。

>>101
付随する物が基本となる物に続くのが論理的、とかフォントレンダリングが単純化される、
みたいな言い訳が2.11章に書いてあった気がする。

>>103
「JIS Punctuationに従う」って何？
「sjis」とUnicodeとのマッピングがどこに書いてあるのか、具体的に教えてくれ。

>>104
>「sjis」とUnicodeとのマッピングがどこに書いてあるのか、具体的に教えてくれ。

規格化されていないのでどこにも書いてない。

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/

>>104
> 付随する物が基本となる物に続くのが論理的、とかフォントレンダリングが単純化される、
なるほど。
けど論理性はともかく、レンダリングが単純化されるって、どういう風にされるんだ？

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

> 「JIS Punctuationに従う」って何？
だって、JIS PunctuationのWAVE DASHに対応する文字がjisの中にないとおかしいじゃん。
だったら、sjisの中にWAVE DASHに対応する文字がないとおかしいじゃん。
unicodeの規格には「ないとおかしい」って書いてないだろうから、なくてもいいのかもしれないけど。

>>106
obsoleteかよ。しかも半角円記号がA5にマッピングされてるじゃねーか。
そんな実装存在すんの？

>>107
>>89,91,92の言うsjisのマッピングって、存在するかどうか怪しい>>106のことなのか？　空想乙

>>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

>>109
波ダッシュ変換して何がうれしいのか。

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

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

最初から「cp932以外はマッピングが規格化されてないのでcp932とそれ以外のシフトJIS系実装でマッピングが異なる」って言えばいいんだよ。

なんで「俺様のまとめ」を、他人に最初から要求するんだろうこういう馬鹿って

まとめを要求したいのではなく89と91の表現が不適切だと言いたいのではないだろうか。
110(=90?)はCP932もシフトJISだと言いたいんだろう。

確かにsjisのUnicodeマッピングは定義が曖昧すぎる。

>>110
え？うれしくないの？超うれしいじゃん。

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

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

> cp932以外はマッピングが規格化されてないのでcp932とそれ以外のシフトJIS系実装でマッピングが異なる
明らかな間違い。規格化されていないことは、マッピングが異なる理由ではない。

相手を誰かと買い違いして、喧嘩腰になってる方が見受けられるのでトリ付けた方が良いかも。

散々問題になってる>89は、>81を
　「X 0208」「NEC特殊」「NEC選定IBM拡張」「IBM拡張」 → CP932 (=Windows-31J)
と解釈した上で、Shift-JIS（=JIS X 0208）という別のキャラセットもあると述べてるだけかと。
（両者は別のキャラセットとして、IANAに別個に登録されてます。）
具体的に何が問題になるかも、>92で示されてます罠。

訂正。>81じゃなくて>86ですね。同一人物ですが。

今更ながら>77の言う「地雷」の意味が何となく分かった。
ttp://ja.wikipedia.org/wiki/EUC-JP

>84の変換方法だと、Windowsなら良いかもしれないけど
他で問題がありそうな予感が。（検証してないけど）

おかしい人は相手をせず放置するのがいちばんですよ。

でもここはおかしい人隔離スレかw

>>114
待て待て。Shift-JISはIANAに登録されていないし、IANAはUnicodeとのマッピングは定めていないぞ。
話と関係なくね？

規格化されてないなら、デファクトスタンダードな処理系を基準にするしかないじゃん。
そしたら結局のところ、sjisとcp932はマッピングが違う、という最初から出てた話に。

そうしたら>>90がまた「cp932もsjisだ」って言い出すだろ。
それともsjisのデファクトスタンダードって何かあるの？

PC9801のROMに入ってるか否かだ

PC9801のROMにIBM拡張漢字は入ってないぞ
初代には第二水準漢字すら入ってなかった

>118
ttp://ja.wikipedia.org/wiki/Shift_JIS
「Shift_JISの標準化」の項
IANAも「Shift_JIS」という名前で登録している。

でもよく読むとX0208じゃなくてX0213の方なのかな?

>>123
sjisそのものは標準規格があるけど、sjisをunicodeに変換する方法については規格がない、という話。

>>120
デファクトスタンダード選ぶなら、GNU iconv以上にメジャーな処理系ってなに？

>124
sjis-Unicodeのマッピングが公式に定義されて無いのは別に否定してませんが…
ただ「sjis」という文字とコードのマッピング（要はキャラセット）はIANAに登録されてるでそ。
それを無いとか言うもんだから>123を提示したまでですが。

あとメジャーかどうか知らないけど、IBMがICUっての公開してますよ。>処理系

>>125
ちゃんと読もうよ。
わかんないことには口を出さないこと。
勘違いしてたのなら素直に謝ること。
それだけだよ。

JIS X 0208:1997の附属書1は規格じゃないの? 「規定」って書いてるんだけど。
標準じゃなくてガラパゴスだとか?

>>125
sjisとShift-JISとShift_JISを一緒にしないでくれ。IANAに登録されているのはShift_JIS。

>>124
また話がループするようなことを。規格化されているのはShift_JISX0213。
断じてsjisではない。

>>123
X0201とX0208だよ。
http://www.iana.org/assignments/character-sets

>>124
デファクトスタンダードはやっぱりJavaでそ。

>>128
それに関しては、もはや揚げ足取りではないのかい？
cp932とShift_JISX0213は別物だが、sjis, Shift_JIS, Shift-JIS, shiftjis, ... を
Shift_JISX0213の通称として扱っていいんじゃないの。

それともShift_JISX0213と別物で、よく似た名前の別規格or独自仕様って何かある？

>>130
揚げ足を取るつもりはないけど。
少なくともShift_JISはIANAに登録されていて別格。狭義のシフトJISを指す。
それに対しsjis,Shift-JISは定義の無い通称で、広義のシフトJISでは？
両者は明確に区別されるべきだと思う。
少なくとも>>99のSJISがShift_JISの略っていうのは嘘。

>128
そこまでの厳密さを求める割に、IANAに登録されてる/されてないという流れに対して、
「Shift_JISX0213」を持ち出すのはおかしいと思わないのかい。
それJISでは正式採用されてても、IANAじゃまだドラフトのはず。

>>131
Shift_JISって名前出しつつIANA Shift_JISと別のエンコーディングの話する場合はないといえるのかい？
俺と君との2人だけの議論だったら、単語の使い方を明確にしておくのは有効だろうが、
何人いるのかも分からないし、そのうち何人が全部のレス読んでるか分からない、単発ばかりかもしれない場所でそれをやってもろくなことにならないと思うよ。

できる限り、文脈で判断して、違いを分かってる人は必要に応じて明確に違いを明示した言葉遣いをするのが一番マシだと思うんだ。

unicodeと関係ない話は他でやってくれ。
わかったのはCP932以外のシフトジス系はunicodeとの対応が規格化されていないってことだ。

X0208←→Unicodeが存在して、X0208←→シフト符号化表現が存在するのに、
シフト符号化表現←→Unicodeが存在しないとはこれいかに？

なんでこう、脊髄反射するんだろうな。

やけどしないように、かな

脊髄反射した結果、炎上してるのになぁ。
反省とかしないのかね。

>>135
X 0208←→Unicodeは何処に書かれてるの？おせーてくださいまし。
あとX 0201の存在もお忘れ無く・・・

>134は「規格」を「IANAのobsoleteではない規格」に限定しないと、真にならんかと。

>>140
IANAじゃなくてUnicodeコンソーシアムのまちがいだよね？
あとobsoleteじゃないってのはデフォかと。

なんだ、そしたらもう、cp932は規格通りにUnicodeと変換可能だけど、
Shift_JISもiso-2022-jpもUnicodeと変換する規格なんてないからUnicode化は諦めたらいいんじゃないの。

まあそうだな。だから>>110みたいな意見が出て来るし、実際に実装が乱立している。
>>113はどのあたりが間違いだと言ってるのか気になるけど。

>>143
「規格化されていないことは、マッピングが異なる理由ではない」 って書いてあるじゃん。

>>143
ついでに、ここで「だから」という文脈で>>110を出してくるのはおかしい。

お前ら規格にこだわりすぎ。規格がなければ変換できないかのように言うのはミスリーディング。
>>142とそれに賛同してる奴は、本気で書いてるとすればキチガイに近いレベルのバカだ。

例えば上でiconvが出てたが、あれは規格がなくてもできてる。
いくつかの記号では実装によって食い違いが出るかもしれないが、それが一体何だって言うんだ？
cp932

すまん。途中でかいてしまった。

cp932じゃなくShift_JISで書かれた文章なんて、そんなに数ないだろうに。

>>144
じゃあOracleのSJISとJavaのSJISでマッピングが異なるのは何故なの？　きちんと規格化されてないからじゃないの。　

>>146
いや規格化されていないと困るだろ。マッピングが異なるなんて致命的。

だからその致命的なことがすでに世の中に蔓延していますよ、というのが現実なのだがw

>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
まぁ最初からきちんと規格化されてりゃ、こんな事にはならなかったんだろうけど。

>OracleはX0208（cp932にも変更可）
すんませんこれエンコーディングとしてcp932も選べるってだけですね。
SJISの実体をcp932に定義できる、とも読めてしまう気がしたので念のため訂正。

>>148
例えば、OracleのSJISが規格化されたとしたら、cp932とOracle SJISのマッピングは同じになると思うかい？
>>110が書いたのはそういうこと。

>>148
君は、PC(サーバとかじゃなくてPCだぞ)を使う上で1byteの大きさが決まっていなくて困ったことはあるかい？
例えば、この文章をUnicodeに変換するとして、何が致命的になりうる？

>>150
違うぞ。
OracleのSJISはCP932から「〜」の一文字だけ異なる独自マッピング。
JavaのSJISはCP932とはほど遠い、iconvのsjisに近いマッピング。
規格化なんて何処にもされていない。

>>148
もし規格化されてたら同じになったんじゃない？
たった１文字だけ違うなんてなかっただろう。

>>153
今のをそのまま規格化したとしたら？

UTF16の1文字で表した年号って今後の年号のために
4つくらい予備をとってあるんだね。
とはいえ、これ残してると後々困ることが起きそうだねー。
結構使われてたりするんだろうか。

予備はもう全部使いきったんじゃなかったっけ。

UTF16の、って意味わかんないんだが。
エンコーディングを指定する意味は？

♡
こーゆー文字を書くためのコードはどこに載ってるの?

ttp://www.unicode.org/

>>157
細けーこたー(略

>>158
http://www.unicode.org/Public/5.2.0/charts/CodeCharts-noHan.pdf
10進16進の変換は自分でやれ。

pdf・・・

utf・・・

なんで2chはシフトジスなのに改行はラインフィードのみなの?

こっちはUnicodeスレかと思ったらそうでもないのね。

>>163
sjis使ってることと改行コードは関係ないよ。2chのサーバがUnixだからだろうけど。

改行コード1バイトにするだけで10%近く圧縮されるからな

それで、SJISとUTF-8の圧縮率の話に戻って・・・

1バイトが0~255の範囲を満遍なく使ってるかどうかで言うと
SJISよりもUTF-8の方が使用効率が良いので
単純に3/2という訳にもいかんのよ

だってシフトジスはウィンドウスが創作したわけだからCrLfだろJk

あらあら小学生の来るところじゃありませんよｗ

CP/Mが起源じゃないの？

プリンタとかではCRとLFが別々に必要だからな

>>164
文字コードと改行コードの話はキチガイ信者が集まるものだよ。
ネットニュースのうさげの時代からずっと。
そんな人達の隔離スレがここゆっくりしていってね

>>173
これまた懐かしい話を。
じゃぁ半角カナもここ？

>>168
満遍なく使うことだけじゃ、効率のよさの証明にはならない。

例えば次のようにしたら、ASCIIコードから、効率は悪いが範囲を満遍なく使う文字コードへの変換ができる。
00 -> 00 01 02 03 ... FF
01 -> 01 00 02 03 ... FF
...
FF -> FF 00 01 02 ... FE

>>174
半角ってなんですか?

文字化けしてますよ。

>>176
45°

>>176
JIS X 0201片仮名用図形文字集合のことだ氏ねバーカ日下部もどきが。

そういうことにしたいのですね:)

はつみみです

4倍角ってなんすか

昔むかしガラパゴス島にワープロ専用機という珍種がおっての。

倍角　　　ネ申

4倍角　　　イ立　　々
　　　　　　　｜口　　門

>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で、
その後もワング・ラボラトリーズ社などからいくつか
英文ワープロ専用機が登場した。

http://pc12.2ch.net/test/read.cgi/tech/1278923059/ 文字コード総合スレ part6
建てるの忘れてた。スマソ

ここは隔離スレだったのか。
void的にUnicodeの『Halfwidth』はどうなんだろ。あとPC9821に「2バイト半角カナ」とかあったよなぁ

ヘミ猫はmixiに生息しているのですか？

voidなら最近はtwitterだね。

>>189
はつみみです

くそかべととりまきチネ

ascii-netの時代からそうだけど、取り巻き認定ほど無意味なものはないのに未だに気付けない連中が沸くんだな。

怒ってた猫が急に話しかけて来たけど、ヘミ猫語だからわからない
http://www.nicovideo.jp/watch/sm11126185

mixiで暴れてたと思ったら
今はtwitterでも暴れてんのかw
常に時代の最先端を行く奴だな

voidはUnicodeという時代の流れについてゆけず、単なるアラシと化しました

>>187
http://groups.google.com/group/fj.kanji/browse_thread/thread/ffb260159ecd663e

>>192
Unicode時代になっても、あいかわらず馬鹿のやることはワンパターンだよな

個人スレが立っている。秀丸に対するありがたいお言葉が。

キャラクターってなに?

>>199
つhttp://www.unicode.org/versions/Unicode5.2.0/ch02.pdf
2.2 Characters, Not Glyphs

>>199
「ATOKを入れてませんか? 」とかアンサイクロに書いてある。

また強制退会処分の模様

横浜退会決勝は雨で延期

>>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の違いだと
主張しなきゃいけなくなって、傷が広がってるだけ

scriptとlanguageは関係ない。

Letters in different scripts, even when they correspond either semantically or 
graphically, are represented in Unicode by distinct characters.

と、はっきりscriptsと書いてある文書を得意げに紹介しといて、都合が悪くなると「関係
ない」ってか

scriptsの違いってのはLatinとかCyrillicとかそういうレベルの話
Latin scriptは英語でもフランス語でもドイツ語でも使われるんだから
言語とはイコールじゃない

どうでもいいけど日本語に訳してくれよ

文字セットと言語の話？

>>207
>Latin scriptは英語でもフランス語でもドイツ語でも使われるんだから 

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

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

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

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

もちろん、scriptが違う漢文と漢字仮名混じり文の漢字は、対応はしても別の文字

きちがいあらわる

>210
>>Latin scriptは英語でもフランス語でもドイツ語でも使われるんだから
>
>Latin scriptは日本語でも使われるね
>
>もしかして、言語が決まればscriptが決まるとか誤解はしてないよね

なんかいちゃもんつけるために、意図的に拡大解釈してないかこの人。
結論自体は>207を言い直してるだけだし。

http://twitter.com/void_No3/status/20745513220
> WebサイトShift_JIS使用は法律で禁止すべきだ!

完全血出痔禍がかのうなんだから文字コード完全UTF-8化くらい簡単だろう

Shift_JISは2011年7月24日で使えなくなります、とか？

void先生！誰に言っているんですか！
http://twitter.com/void_No3/status/20773507133
> 『全角入力』なる変なのを要求するのやめてもらえませんか?

そういうお前は誰に言ってるんだよw
ストーカー体質の奴って本当、自分を客観視できない馬鹿ばっかりだよな。
完全に狂ってる。

でもこれは入力チェックの手抜きだよなあｗ

客観視を気にするあまり主体性のかけらもないバカがたくさんいるけどなw

おまいらすれ違い
http://hibari.2ch.net/test/read.cgi/tech/1179389033/

どの住所入力でもぜったい全角入力を要求されるのはなんかの陰謀か。

圧倒的多数のアホに合わせてるんだろ＞全角入力

全角で入力しても半角で入力してもおkのほうがアホに優しいんじゃないか？

今日初めてこのスレ見たけど、インディアンには笑った。
もう初心者は置き去りになってますね。

そもそも1で終わってたのに、インディアンのためだけに2を立てたやつがいるんだよ

UNIX厨必死だなｗ

なんでそんなに必死なの？

1文字が7ビットじゃないと動かないクソプログラムを大量にバラ撒き続ける
ＵＮＩＸ信者が必死にShift_JISを攻撃してるんだよな

7bitじゃなければ駄目ならUTF-8でも駄目じゃないか

ああそのとり。もちろんダメだよ。それが何か？

7F は 7bit でおさまってるのに通らないんだぜ

7Fって何？

~

>>229
UTF-7で。

>>233
それって0x7Eじゃない？

あ
そうだね

1文字が７ビットな文化圏では「~」という文字は使用されてないよ
この文字は日本語ＯＳで使える文字
だから7ビットに収まってないんだよ

>>237
そういえばそうだった。「半角」の話か。

えっ

チルダ・バックスラッシュの話でしょ。

7階、家具売り場でございます

Unixで${HOME}に展開される~は日本ローカルだったのか！


そんなわけないだろうw

>>242
http://hibari.2ch.net/test/read.cgi/tech/1278923059/43-47

>>242
ヒント：
ASCII,JIS,overline,フォント,101キーボード

おそらく>>242は
「〜」の半角と「￣」の半角の区別がついてない

2chはSJISだそうだから半角チルダに見えても文句言えないんじゃなかったけ？

7fの話から7eの話に脱線してるのか。

javaのsjisとms932は、チルダとか数文字unicodeとのマッピングが違うけど、
その理由はなんでしょうか？
sjisはjis規格でms932はmicrosoftが決めたからとも聞いたのですが、
本当でしょうか？

スレ違いです

>>248
つ>>89-

うーん。見てみましたが、どうもマッピングが違う理由がよくわからない。
マッピングの規格がないからと言うこと？

うぜえ

>251
ISO646を継承してるか否か。

>>248
由仁子がバカだったから。
いいかげんマッピングをさらしやがって。

>>212
>なんかいちゃもんつけるために、意図的に拡大解釈してないかこの人。 

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

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

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

207の結論は207の前提の真逆だのに、何が言いたい？

>>248
嘘です。
Javaの「SJIS」というコンバータ（UnicodeとシフトJISとの変換ルール）はどこにも規格化されていません。Java独自です。
ms932はUnicodeコンソーシアムのCP932ルールを実装しているので規格化されていると言えるでしょう。

>>251
深い理由はないです。無知とミスが積み重なった不幸から生じた歴史的経緯という負の遺産です。

具体的にはこのあたり参照
ttp://slashdot.jp/~yasuoka/journal/357074

>>257
ミスがあったのはともかく、無知が積み重なったなんで何で言える？
自分の案と違う案をマイクロソフトが出したからマイクロソフトの案を理由もなく
「間違ってる」と批判しているだけの駄文。さすが安岡先生。
マイクロソフトからすれば前の案が間違っていると思ったから別の案を出しただけでは。

おまえが間違ってる

>>258
・FULLWIDTH なんたらは互換用途以外は使うべきでない
・Unicodeのグリフの例示は絶対ではない
ってのを知らない状態でつくったんだろうなってことで＞無知

> 互換用途以外は使うべきでない
> 例示は絶対ではない

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

いずれにせよUnicode規格に残ったのはFF5Eなんだし、自分の思う案が通ら
なかったら規格を無視しようなんて、わがままな子供みたい

FF5E は最初から今に至るまで "TILDE" であって明らかに別の文字なので……
見た目できめるな意味できめろ、という Unicode の基本ルール知ってたらこれ例示がおかしくね？って問いあわせるだろって話。
「見た目同じだからこれでいいよね」は無知のなせる業だろう

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

互換用途の話はその部分じゃなくて ¢とか £ とかね。
POUND SIGN → FULLWIDTH POUND SIGN とわりあてられてしまっている。

>>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。

話の流れをぶった切ってすみません。
スレタイの「Unicode」なんですが、「Unicode」が文字集合の一つだっていうのは
Unicode規格のどこに書いてあるんでしょうか？

エンディアンについてはたいへんお世話になりました。インディアンはお恥ずかしい。
で、大体わかったつもりになったのですが、前スレ43の
> csUnicodeっていうISO-10646-UCS-2のIANA別名があって
を読んだらおやっと思ったのです。これって文字集合でなくエンコードでは？と。

>>265
ここは隔離スレだそうだから本スレ行って聞いたら？

1に対してそれを言うのかｗ

文字コードは難しいな。
ネットで情報を集めても、微妙に間違っている(情報ソースによりまちまち）なものがあったりして、信用できない。
文字コードに携わる前は、unicodeは厳密なものだと思っていたが、方言と呼ばれているものがあったり、
実装によって変換方法が違っていたり、細かいところではぼろぼろなことがわかってきた。
unicodeのバイブル（?)の文字のイメージも違っているなどと言うことがあるんだとすると、
ますます何を信用していいのかわからなくなってくる。

自分を信じろ

インディアンしか信じられないでしょう。
インディアン嘘つかない。

7Fはどうなった？

>>271
7Fは>>236で7Ehの間違いだとして、
昔IBMのAIX使ってて文字コードがシフトJISだった。ホームは半角の￣で表示された。
これはフォントの問題だろうし、Unicodeに変換される時は大抵7Ehに変換される。
フォントの問題なので7ビット系はOKだろう。

ちなみに7fはDELな。

muleとかみたいに7Fとか1Bとか混ざってると落ちるソフトもあったなって話

1Bって何？

ESC

ISO-2022で言語とか全角／半角を切り替えるために挿入されるエスケープシーケンスの先頭バイト。
1Bで落ちるってことは、muleはJISコードが扱えない糞ソフトなの？サイテー
まあ文書をISO-2022で保存しようなとどは思わないから別にいいけど。

>>277
muleがそんなわけねえだろうが。
「多言語用emacs」だぞ。

MS-DOSが登場してシフトJISが一般的になる前は
漢字のテキストファイルといえば
KI-KOコードのついたJISコードしか見たこと無かったけどな

>>279
世間が狭かったんだね。

そりゃ8bitじゃなくて7bitだからな

その当時はPCじゃなくてオンライン端末だったしな

JIS制定以前は各社独自の日本語バイナリファイルだから当然の事

そういやJavaってまだBOM付きUTF-8が処理できないんだっけ？
java.exeの方は互換性が問題になるからともかく、コンパイラjavac.exeがNGなのは
一体何の嫌がらせなのか。

世の中のほとんどのプログラミング言語はガイジン（欧米人）が作ってるからですよ。
日本だけを特別扱いするワケにはいかないんです。
彼らにとって、日本は取るに足りない、地球の裏側の、世界地図の端っこの小さな小さな国
でしかないんです。
だからBOMなんてどうでもいいんです。
嫌がらせとか、そんなんじゃないですよ。な〜〜んにも気にしてないだけですよ。
問題意識が全くないんですよ。

ソースコードBOM付きで保管する香具師って馬鹿なの？死ぬの？

BOMと日本語になんの関係が。
まぁ、メモ帳は死ね、と思うが。

>>285
お前何も分かってねーな
日本なんて中国の一部と思われてる
まず国として認識されてない

素直に英語つかえばいいやん

>>286
エンコーディングが明確になっていいじゃない。何か不都合でも？
BOMのせいで親が死んだとか。

同僚が過労死した

>>286
BOMじゃなくて単なるZERO WIDTH SPACEですよ
行番号の前に空白が入ると動かないBASICでも使っているの?

ZERO WIDTH SPACEがあると動かないperl笑java笑

ファイル先頭にZERO WIDTH SPACEがあると困るというのは
言語仕様やシェルの仕様の問題だからそれぞれのスレでやった方がいい

そりゃshbangはダメだろうなぁ

BOMがあると誤作動するソフト。
BOMが無いと誤作動するソフト。
もちろん、BOMがあっても無くても正しく動くソフトもあるが。
こんなのを混在して使用しなければならないのが現状。
それぞれのソフトの作者に改良してもらうしかないのだが。
ソースコードが公開されていて自分で改造・コンパイル可能なものは
自分で手直ししてるが、すべてがそうではないからな。
それぞれのソフトを自分で独自に１から作り上げていては
本来の業務に差しさわりがある。

>>290
>>292
>>294
単なるZERO WIDTH SPACEだ？
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？
エンコーディングが明確になるだ？
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス

ソースに上位ビットが立った文字列を入れるのが間違い

>>297
いや
<!-- 美乳 -->
の有効性をなめたらいかん

京には美乳が多いのですか？

>>297
お前にとって要らないものかも知れないけど、俺は入れたいし、好き嫌いの問題だな。
美乳と違ってUTF-8のBOMは規格化されているから一緒にするなよ。
それとは別の話で、Unicode規格に従ったエンコーディングを受け入れられないJavaみたいなソフトは糞。

BOMはクソ。

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

……たかだかプリフィックス1つでこんだけ面倒くさくなるんだから、BOMなんて滅んでしまえー。

>>302
それはBOMに限った話じゃなくて、標準入出力でテキストファイルを処理することが問題というか、
制限を覚悟しなければならないことじゃないの？
例えばISO-2022で書かれた2つのファイルを結合するとして、最初のファイルがASCII以外で終わっていて
次のファイルがASCII前提で始まってたらデータ壊れるでしょ。

美乳と聞いてやってきました。
美乳と言えば貧乳、貧乳はもはやステータスですよね！

>>303

たしかにテキストファイルの分割結合に関しては、BOMよりはISO-2022の方が
やっかいだわな。

なんで美乳と２文字も要るんだ？乳だけじゃだめなのか？

>>305
バイトストリームとして扱える事が売りのひとつのUTF8にわざわざ始端だけつけて
「付けても付けなくても良い」とか言う糞どうでも良い仕様のために常に余計なチェックを実装させられる
好き嫌いの問題じゃすまねーよ
得意げにストリームとして扱えない事が明白なエンコード持ち出して馬鹿じゃねーのお前

世の中のBOMに対する実装だって、ほぼ全てが「BOMを適切に除外するための処理」でしかない
除外されるためだけに存在するBOMって何なのマジで

>>302
こんなに頭悪いやつは、ひさしぶりにみた。

すまん馬鹿じゃねーのお前は305に言う言葉じゃないなｗ

標準入出力でテキストファイルを処理することが問題って、どこの星の人間だよ

現状としては（本来の目的は別として）
BOMはShift_JISやEUCなど他のエンコードなどを見分ける目的で利用されている。
Shift_JISやEUCがあってこそ、BOMの存在価値があるってことだ。
システム全体がUTF8化されていて、通信やフロッピーやＣＤやUSBメモリーなど
外部から入ってくるテキストもすべてUTF8なら、BOMはいらない。
むかしならそれでいいだろう。
だが今は21世紀だぜ？インターネットの時代だぜ？世界の国からこんにちわだぜ？
「UTF8以外お断り。」ってワケにはいかない。
いろんな文字を扱わざる終えない。
だからUTF8識別文字としてのBOMは価値がある。

UTF-8にBOMって要るんだっけ？

BOMだけ見て終わりなんて、あらゆる状況で危険すぎて不可能
よってBOMは邪魔なだけ

インデアン蚊帳の外です。

結局エンコーディングなんざメタ情報が無ければ大体でしか分からん.
偽りの安心感を得るためBOM付けるくらいならメタ情報を含むフレームを作れ.
UTF-8の特性を根本から揺るがすBOMの推奨者は本当に馬鹿としか言えない.

UTF-8にインディアンは関係無くない？

ウニコデにもインディアン関係ないな

>>307
ストリームとして扱えないのではなく、UTF-8はISO-2022同様、分割・結合が簡単にできません。
ってだけですよ。BOMに限らずステートフルなテキストをリダイレクトで結合するなってこと。

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

本来>>315の言うとおりメタ情報で管理するべきなのだろうけど、現代のOSもファイル交換
プロトコルもテキストファイルにメタ情報付ける仕組みが無いですし。

>>318
> テキストファイル単体でエンコーディングがUTF-8であることが(事実上100%)わかるんですよ。
latin-1との誤判断は防げないと思うが

BOMって

Byte
Order
Mark

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

エンコーディングを見分けるとか何とか、それって事実上そういう使い方もできる、
ってだけの話で、それが本来の目的であるかのような議論っておかしいのでは？

>>311
本当に識別文字として使っていいの？
現状使われているどの文字コードでも、BOMと同じ並びのバイト列が最初に現れる可能性はないと言える？

>>320-321
そういう文句はUTF-8の規格作った人に言わないと。

>>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との誤判断については「極めてまれ」ってことにしたいみたいだね。

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

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

けど識別に使うって言っても、BOMあり/なし混在してる以上はどっちにせよ
BOMなしでも識別できないといけないんだし、BOMをつけるメリットは生かせない。
ていうか、混在してる状況でつけるメリットが全然見えてこない。

>>324
「これはUTF-8だ間違えてくれるな」ってな思いで付けちゃいけないか?
BOM有りUTF-8で保存した文書はブラウザでもテキストエディタでも文字化け
することなく開いてくれるから付けることにしてる。

signatureが付いてる時点でそれは「plain」textじゃないんだよ。
数バイトでも本体とは別のメタデータなんだから、BOM付きtextというのはある種の構造化データだ。
だから、plain text前提のツールではとっても困る。
plain textのフリをして混じり込んでくるから余計に困る。

>>306
乳だけじゃ唐突だから単語っぽくしてみたんじゃないか?
<!-- 入口 -->というのもあったな

BOMってのはボム、つまり爆弾。掲示板が炎上するネタっていう意味だったんだよ。

>>306
何で「美」「乳」のうち「乳」を取るんだよおまいは。「美」でいいだろ。

>>318
>ストリームとして扱えないのではなく、UTF-8はISO-2022同様、分割・結合が簡単にできません。 
>ってだけですよ。BOMに限らずステートフルなテキストをリダイレクトで結合するなってこと。 
ISO-2022-JPなら、結合は自由

>本来>>315の言うとおりメタ情報で管理するべきなのだろうけど、現代のOSもファイル交換 
本来はエスケープシーケンスで管理してたんだけど、ユニコードが全部ぶち壊した

>>329
>>303,318はダメな例としてISO-2022を挙げている。ISO-2022-JPに話をすりかえるな。
またISO-2022-JPだとしても、「フィルタで特定の一行を抜き出して他の
ファイルの最後に追加」とかはできない。X 0201とASCIIが混ざるから。

> 本来はエスケープシーケンスで管理してたんだけど
世界中の文字コードをISO-2022に統一したいのか?　頭おかしい。
俺ならレガシーコードを捨てて世界中の文字コードをUTF-8Nに統一したいね。

20年前のUnicodeは頭おかしかったけど、
結局その頭おかしいUnicodeに統一されたもんなwwwwwww

UTF-8に統一された後にもBOMつけたがってんのか
真性のドアホだな

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の中で、半角カタカナを禁止すると明記すべきでしょう。

Unicodeに半角カナが入るって何年前の話だよ

>>333
junet信者はこんなこと言ってたの？元はいつの発言なのか。きんもー

>>330がちょっとわからないんだけど、iso-2022-jpは行の終わりが半角英数、
ファイルの終わりがasciiで、iso-2022はそれが決まってないってこと？

>>334
ここだけ20年時代が遅れているスレ
http://hibari.2ch.net/test/read.cgi/unix/1243343056/231

半角カナはUnicode 1.0(1991年)だからドラフト2はその前だよね。
でもiso-2022-jpで半角カナが禁止になったのが1993年。あれ？
メールでMSの半角カナが出回る前に一時半角カナは根絶したのかな。

JUNETでは半角カナは使えなかった。
http://www.softlab.cs.tsukuba.ac.jp/~yas/fj/junet-tebiki/J.6.3

つまり、それを踏まえたうえで、RFC 1468 を「予言」してるわけで、歴史考証的に変ではないよ。

>>333みたいなJUNETユーザーは「国内だけの問題ではない」とか言いながら、
世界中が繋がってISO-2022-JP以外のコードが流れてくるという考えは無かったんだろうか。

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

>メールでMSの半角カナが出回る前に一時半角カナは根絶したのかな。

yes

>>339
> >>333みたいなJUNETユーザーは「国内だけの問題ではない」とか言いながら、

>>333 のどこに「国内だけの問題ではない」なんて書いてあるんだ？

「半角ってなんですか?」はいつから？

>>339

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

ﾜﾛﾀ｡皮肉が理解出来ない低脳ｗｗ

>>341
俺は>>339じゃないが、>>338のリンク先に書いてあるぞ。

>>339
> ISO-2022-JP以外のコード
外部コードはISO-2022(JPが付かないやつ)に統一されると思ってたんだろ。
> ターミナルソフト
「実装できない」じゃなくて「実装したくない」だな、20年前だと。
当時はEUC-JPマンセーだったので、半角カナ&機種依存文字死ね状態だったわ。
あ、あとアンチMIMEな。

ぶっちゃけ今現在、一番足を引っ張ってるのはEUC-JPだよね

MSWindowsの日本語ロケールもさっさとUTF-8にしないと後で大変なことになる

>>346
Shift_JIS/Windows-31Jだろどう考えても。
EUC-JPは事実上滅亡寸前。既に俺の可視範囲内にEUC-JPなシステムは存在しない。

足を引っ張ってるのはISO-2022だろjk。
状態があるのは処理しにくいし、無駄にデータサイズがでかくなる。
今時7ビットとか言ってる奴は死んでくれと思う。早くUTF-8に統一されて欲しい。

UTF-8でダメなメーラ・メール環境・経路って何があるんだろう？

メールはUTF-8でいいよ。

>>350
UTF-8がダメなメーラーは携帯電話ぐらいかな。

>>345
> 外部コードはISO-2022(JPが付かないやつ)に統一されると思ってたんだろ。
なんだ。じゃあJUNETはISO-2022-JPではないけれどISO-2022として半角カナ使い放題じゃないか。

http://www.nikkei.com/news/headline/related-article/g=96958A9C93819499E3E3E2E3988DE3E3E2EBE0E2E3E2E2E2E2E2E2E2;bm=96958A9C93819595E3E3E2E2978DE3E3E2EBE0E2E3E29F9FEAE2E2E2

うんこして紙でケツの穴を拭いてもさぁ
どうせ明日、また、うんこしたらケツの穴が汚れるんだから
ケツの穴を拭くのは無駄。
うんこしてケツの穴を拭く必要性が見えてこない。

文字化けするホームページがあってソースを見てみたら
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
って記述があるのに、実際はShift_JISだった、ってこと・・・良くあるだろ？
だからこんなタグはアテにならない。付けるの無駄。無用の長物。廃止して構わないよ。

UTF-8のBOMも同じこと。
BOMがあるからUTF-8とは限らない。

>>355
かゆくなるぞ

>>356
人里離れた山奥でコンピューターの無い生活した方がいいぞ。
そこではうんこも拭かなくていい。文字化けとも無縁だ。

<!-- 美龜 -->

<!-- マンコ -->
秀丸ならEUCの方が優先でもシフトJISで開いてくれる。

上手く処理できないXMLがあってソースを見てみたら
<?xml version="1.0" encoding="utf-8" ?>
って記述があるのに、実際はシフトJISだった、てこと・・・よくあるだろ。
だからこんなXML宣言は当てにならない。XMLは無用の長物。廃止して構わないよ。

ISO-2022-JPでも同じこと。エスケープシーケンスがあっても糞ソフトが途中からEUC-jpを
混入させていたり、エスケープシーケンスなんて当てにならない。つまりASCII以外はアテに
ならないってことさ。

>>361
バックスラッシュとチルダが変な表示になっちゃうだろ？
つまり(ry

C++で、いろいろな国の言語を使った文字列を定義するとき、charとwchar_t　どっち使うのがいいの？
コンパイラによってサイズも符号化方式も異なるwchar_tを使わず、
charで処理している人もいるとさっき知った。

sizeofで、wchar_tのサイズが
1ならUTF-8
2ならUTF-16(UCS2?)
4ならUTF-32(UCS4?)
と仮定して処理しているらしい実装を見たけどこれってどうなのよ。
wchar_tだからってUnicodeとは限らないんでしょう？

せめてSTDC_ISO_10646をチェックしろというか

男は黙ってBOM

L""で文字列を定義すればソースコードがShift-JISだったとしてもコンパイルが通るというメリットがあるのかな。
""で定義しても、ソースコードをUTF-8で保存し、charの中身UTF-8と仮定して処理すれば
いけるはずのに・・・あれ？

>>364
wchar_tの中身がUnicodeなら定義されている奴だね
でも定義されていなかったらどうすんの。
>>365
ソースコード中の文字列定義にBOMいれるの？

ソースコードに文字列埋め込む人って・・・

ASCII文字しかソースコード中には使っちゃいけないと？
それを言っちゃあ おしめいよ

コメントは非ASCIIを使っても良いかもしれない

// コメントのけつが 0x5C だと次の行をコメントに連結するC++コンパイラは今でも実在する。

おまいらm17n対応ってどうしてんの？

環境・動作対象による。

>>368
#ifndef STDC_ISO_10646
#error Hello, Galapagos Islands!
#endif
とか?

>>366だった

charでUTF-8が扱える環境ならcharでいいだろう。でなきゃwchar_t。

C++の話にSTDC_ISO_10646は関係ねーだろ。

ここでも始めるのか、wchar_t、UTF-8・・・

ここは隔離スレなんだからもっと煽らないとw

俺は変数も日本語だぜ。Visual Studio 2008。困ったことはない。UTF-8なので中国語もOKだ
#include <cstdio>


int main()

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

}

>>377
不毛だからやるとしたらこの続きから
http://hibari.2ch.net/test/read.cgi/tech/1093251312/208-282

>>378
ええなぁ。
javaは実行時の端末と同じエンコードでソースコードを書かないと不具合出まくり。
ソースコード書く時点で実行時の端末のエンコードが判ってなきゃダメなんだぜ！
やんなっちゃうよ。

>>380
えっ、Javaってそんな仕様だったか？
サーバサイドJavaはコンパイル環境とエンコード合わせた記憶がない。
少なくともコンパイル時点でUTF-16になっているからソースコードの文字コード情報
は消え失せてると思うけど。

>>380
それはどうみても、君かプロジェクトの担当者か、
あるいは両方が
馬鹿

>>381
インディアンはどっち？

>>383
今ためしたらUTF-8だった。ｽﾏﾝｶｯﾀ

>>380
javac -help
<中略>
-encoding <encoding> ソースファイルが使用する文字エンコーディングを指定する
<以下略>

>>384
ぅぉ、本当だ、classファイル中の文字列定数はUTF-8(サロゲートペアの扱いはjava固有だった希ガス)表現なんだ。知らんかった。

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を突っ込んでやらないといけないのか。

Javaは実用性皆無のウンコ

しかし、クライアントから金は巻き上げやすい…

Java案件で数多の阿鼻叫喚を繰り広げ
IT大不況へと突入
今となっては受注開発は金の無駄が経営者達の合言葉

ずいぶん荒らされたし
発注側にもトラウマが残った

一山いくらで量産されたJava猿のお陰でプログラマの市場価値も駄々下がりｗ

ほんと、Java発の技術ってろくなもんないんだよね…
XMLとかSOAPとか

>>393
全然Java発じゃないし、役にも立ってる

>>394
そりゃ、多少の役には立たなきゃw
完全な詐欺道具になっちまう。
なくても困らないし、ないほうがいいくらいの技術だといってるだけさw

>>387
classファイルの中だけの固有形式で、不正な形式のまま
外部とやり取りすることはない

>>363
> sizeofで、wchar_tのサイズが
> 1ならUTF-8

これがわからん。defineしているのか？

wchar_tが1でUTF-8なんてISO 14882の3.9.1-5的におかしい。
まあマイクロソフトのwchar_tがUTF-16なのもおかしいけど。

>387
えー、zipとかjarファイルのファイル名もこんな変なUTF-8が出力
されてなかったっけ。

>>399
ホントだ。jarでclassファイルをまとめる時、ファイル名はUTF-8で記録するけど、
サロゲートペアは間違った偽UTF-8じゃないとダメみたいだな。
これも互換性のための仕様ってやつかね。仕様のバグがあっても互換性のために絶対直さない糞Java

どうせＪＡＲを勝手にＺＩＰとして開いて文句を垂れてるんだろ。お前が悪い
Ｊａｖａの崇高な設計思想など貴様ら愚民共に理解できるはずがない。消えろ屑

Firefox拡張用のjarとかはどうなってるんだろう

>>401
必死だなｗ

>>403
何が？

CSI方式万歳！UCS normalization方式 は屑

wchar_tがUTF-8の環境なんてあるの？

↑
こいつあたまおかしい

>>407
つ>>397-398

正しく動作させるためにはwchar_t[]の度に先頭から走査するのかねぇ？

UTF8はリードバイトが可変長過ぎてAPI任せだわ( ´ω`)
BOMもありとなしがあってなんであそこまでｶｵｽなんだ

>>410
UTF-8にBOMなんてないよ。
あったらそりゃUTF-8もどきだよ。

>>411
それがあるんですよ。

Unicodeなんだからそこは「なんでBOMなしでいいんだよ」って突っ込もうぜ( ^ω^)
半角英数記号を1バイトにしたいがためのコードと言えばそれまでよ

UTF-8って良く出来てる

一番最後に作られただけあるよな。

UTF-8は屑。SJIS/EUC-JPで２バイトだったのが３バイトになって喜んでいるのは欧米人の手先。

さすがにDBCSに戻る気にはなれないな

日本人同士がJISとかSJISとかEUCとかで揉めてるときに
欧米人にUTF-8でサクっと問題解決されてしまった
日本人涙目

>>416
たかが1文字で1バイト増えたぐらいでごちゃごちゃ言うなよ。

すべての文字表すのに16bitじゃ足りないって言っていたのに、
32bitにすることで2バイト増えるからとケチっていた欧米人と
お前は何にも変わらん。

>>412
だからUTF-8もどきだと言ってるだろ？
わかんねーのか？

>>420
全然わからないな。
http://www.unicode.org/versions/Unicode5.2.0/ch16.pdf
この16.8章をどう読んだらBOM有りUTF-8がもどきになるんだ？

どう考えてもISO 2022フル実装が一番カオス。
designate/invokeで表現方法が複数あったり、シングルシフトに2種類の表現があったり
アナウンスまで出てきた日には大変だ。
ESC - "$" - Ft と ESC - "$" - "(" - Ftで使える文字集合が違うとか狂ってる。

>>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と分かってたら使っちゃダメ）

で、BOM以外は同一のUTF-8テキストファイルで
先頭から10文字目って言うのは等しい文字が帰ってくるのかい？
BOMを数えるのが仕様？数えないのが仕様？

あと、BOMの意図無く、ただの文字としてファイルの先頭にZERO WIDTH SPACEを入れるのは仕様上認められるの？

もうそろそろ誰か文字コードを識別する仕組みを外部の何かにやらせるまでを
文字コードの仕様にした規格を出してもいいと思うんだ

>>423
言い換えれば、
「UTF-8にバイトオーダーなんてないしBOMなんてない。
例外として、エンコードが分からないような特殊なケースでシグニチャ付けて良いよ。」
と言っている訳。

シグニチャをBOMって呼ぶのは本来誤用だけど、UTF-16の連想からBOMと言っている。

>>424
> ただの文字としてファイルの先頭にZERO WIDTH SPACEを入れるのは仕様上認められるの？

認められる。
BOM有りUTF-8の場合は先頭のU+FEFFはBOM。
BOM無しUTF-8の場合は先頭のU+FEFFはZWNBSP。
ファイルのデータのみからは判断できず、解釈するためにはエンコーディングスキームに関する
メタ情報が必要。そこら辺がカオス

詰まる所メタ情報必須って事だよね？
ただの1文字と区別のつかないBOM(シグニチャ)付けたがる意味がわかんないわ

そうは言っても文字コードの異なるファイルが混在する問題を放置するわけにもいかず、
「ファイルのみ必ずBOMを付け、メモリ上や通信のデータ部はBOM無し」
という暗黙のルールをマイクロソフトが広めたがっていると思われる。

大勢がUTF-8へ傾いてる状態で、UTF-8に統一された後に無駄に困るような仕様を残すのは馬鹿じゃないの

せめて ZWSP(U+FEFF)は文字として使用せずUnicodeのシグネチャーとしてのみ使用される、
とかすればよかったのに。
通常文字の一つをシグネチャーとしても使用したことがクレイジー。区別つかないだろまったく

>>430
だよな

もうBOMなんて使わんで
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
を入れときゃいいやん。それですべて解決するはずだろ？

80バイトも無駄にするくらいなら
macbinaryの方がましだな

UTF-8はASCII互換が売りなんだから、BOM付けるのは本末転倒ですよね

そりゃそうだ。その使用を正式からはずせ。

UTF-8Nの利点が本気で分からない
先頭バイト見ればエンコーディングが分かるなど、初学者を惑わすだけの危険な幻想でしかないし
BOMに一体どんな利点があるって言うの？

>>416
てめーmule encoding disてんじゃねーよ。

>>437
逆? そ言えば、必ずBOMがある(慣習的な)エンコーディング名ってないな。
UTF-8N(BOM無しUTF-8)は日本固有の慣習らしいが。

逆だなｗ
BOM付UTF-8には特に呼び方が無いという、まさに混乱を極める仕様

あっても無くても良いし、あった所で何かを保証するわけでもないし
「それ」を全うに扱うためには信頼できるメタ情報が必須であり
メタ情報があるならそもそも「それ」は不要である
そんなBOMさんがこの先生き残るには

この先生キノコる

(U+FEFF)(U+FEFF)(U+FEFF)aaa
って内容のファイルのLengthっていくつになるのが正しいの？
3？5？6？

>>424

先頭からの文字数に関しては、UTF-16等と一緒だろ。
UTF-16でBOMを一文字としてカウントするのなんて見たことないんだが。

>>443

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

改行コードなんかに関しても似たようなケースがおこるよね

当然文字列のLengthの話
ファイルサイズのLengthは悩む余地無いでしょ？
12バイト以外になり得るの？

>>444
通りが良いからBOMって言ってるだけで、UTF-8に「UTF-16等と一緒のBOM」は無いよ
いい加減文脈から区別付けて話しましょう

「UTF-16等と一緒のBOM」をUTF-8でエンコードしたものじゃないか

>>447

なんでそこに食いつく。

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

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

で、テキストファイルに於いて付けられているシグネチャを文字列の文字数と
カウントするのか、そうでないのかって話ならUTF-8もUTF-16も同じじゃ
ないの？と言ってる。

>>438
mule encodingは屑。なんだか分からないから。

>>446

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

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

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

シフトコードとか、こういった類のものはプログラミングするうえで厄介な
ものであることは確かだけどね。

utf-8シグネチャはテキストファイルの先頭に限ってのみ付加可能ってことにすれば
いいのかもしれんね。一つのテキストファイルに複数の文字エンコードが混在する
ようなものを扱う場合はシグネチャなんて当てにせず自前で処理するだろうからさ。

BOMって何の略？
Byte Order Mark ?

>>451
えーと、バイト数なんてどうでも良いんだけど･･･
何でしつこくそこに持っていくの？
UTF-8でやっとバイト数と文字数に一切の関連性は無いという共通認識が得られつつあるのに、何をいまさらという感じ

(U+FEFF)(U+FEFF)(U+FEFF)aaa
上記UTF-8ファイルの文字長はいくつと解釈するのが正しいのですか？
この質問に、少なくともバイト数と改行は全く関係ないでしょう？

UTF → Unicode Transformation Format

略語の原語を調べればだいたい理解できるだろ

>>453
そう
エンディアンの識別用

>>453
Beautiful Oppai Mark

やっぱ
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
これが最強だね。これさえあれば世界中のどんな文書もエンコードが判別できる。
なんでこんな簡単なことに誰も気づかないんだろ。
もしかして、おまいらアフォ？

ほらほら、つりですよー。
早くパクッってやらないと
何度もコピペしますよー。

美乳がこの先生きのこるには

>>454

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

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

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

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

馬鹿はおまえだ。
各プログラミング言語における「文字」の定義次第。

オクテット長でなければいけないなんて合意はどこにもない。

「1文字＝１バイト」っていう変な概念は捨てろや

>>461
ごっちゃにしてるのはお前だけ

>>441
結局のところそのメタ情報の決定版がないからさらに状況を面倒くさくしてるのでは。

>>461はもうレスしなくていいよ
何度も言うけど実際に操作する文字列のサイズなんて問題にしてないんだよ

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

とにかく>>461は頭の中が時代遅れ過ぎてお話になってないよ

>>458
そのやり方はXHTML1.1では非推奨でHTTPヘッダ使えってことになってるし
HTML5でも書き方が変わって<meta charset="utf-8">になった
だからそのやり方は最強ではなく単に古い仕様

EmacsとPythonとRuby1.9では「-*- coding: utf-8 -*-」。

Perlではuse utf8

Rubyでは-Ku

文字数と言えばtwitterってどうなんだっけ？

>>454
5文字でいい。

metaタグとか言ってるバカは何なの？
HTML以外のテキストファイルとかどうするつもりなの。
ZIPファイルで圧縮している日本語ファイル名をどう記録するつもりなの

素人騙しだよなぁlang属性で全て解決！とかさ

オールマイティなBOMさんかっこよすなぁ

>>472
metaタグでええやん。何か問題でも？

>>467
あんたねぇ・・・
オエライさんが決めたからって、犬みたいにシッポ振ってホイホイ付いて行くなよ。
今まで大量に蓄積された文書はどうすんの？
どうせ過去との互換性も保つために、古いタグも新しいタグも両方とも対応するアプリケーションを作らにゃいかんやろ。
アフォくさ。
意味のない新規格なんざ無視しろ。

>>476
HTML5だと新しい書き方が推奨ってだけで古い書き方も問題無く通るよ
それに新規格に意味が無いなら営利企業がたくさん策定作業に参画したりしないよ

古い書き方ガン無視で誰もついてこなかった
XHTML2の反省に立って作られた規格だからな

そうすると今度は誰も新しい書き方なんかしない。
そういう奴らだからな、「ウェブデザイナー」とか。

うｔｆ−８にぼｍなんて必要ない

<br>に / という無駄なものを
書かせたXHTMLは市ね。

>>481
てめえか、締りの悪いケツをさらしてんのは？

EOFの無いファイルはクソ

＞それに新規格に意味が無いなら営利企業がたくさん策定作業に参画したりしないよ

新規格をつくれば企業は儲かる。たとえそれが意味の無い新規格でも。
ただ儲かりたいだけ。それが営利企業なんだよ。
われわれユーザの利便性など、どうでもいい。

>>481
brを使ってる時点でお前が死ね

>>484
＞新規格をつくれば企業は儲かる。
いや、規格の協同策定は、得のためと
いうよりは、損をしないがためだろ。

チキンレースみたいなもんだ。ｗ

>>479
互換性無視で新仕様作ったって結局誰も新しい書き方なんかしなかったんだから
「そうすると」はおかしいだろ

utf-8シグネチャ = U+FEFF = ZWNBSP(Zero Width No-Break Space：幅の無い改行しない空白)
って事は、ZWNBSPという文字を、ヒントや推測に使って良いってだけの話じゃないか。

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

むしろ utf-8シグネチャ = ZWNBSP としてある所に、センスを感じるな漏れは。

>>488
馬鹿乙

>>488
どうみても苦し紛れ

<!-- 美乳 -->としてある所に、センスを感じるな漏れは。

>>466

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

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

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

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

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

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

そもそもなんでオクテット長なんて出てくるんだよ。

そんな事より美乳の話しようぜ

BOMをどう扱うかは、個々のプログラマが個々のアプリケーションに対して個々に決める仕様だろ。
TABコードをどう扱うか、とか、CRやLFをどう扱うか、とか。そんなんと同じだろ。

>>492
馬鹿で粘着乙

ゼロ角ってなんですか?

>>492みたいなコミュ障害者に限ってレスしたがりだよなｗ

>>494
全然違うよカス
BOMは仕様で定義されてんの

>>495 >>497 コミュ障粘着乙。消えな

そんなひとはいません

>>499
オウムが消えるべき

　　　 _ 　∩
　　(　ﾟ∀ﾟ)彡　美乳!美乳!
　　(　 ⊂彡
　 　|　　　|
　 　し ⌒Ｊ

最近は言語によってはその辺の変換クラスが最初からあるから便利だよね
最初文字コード変換関数作ったときとかBOMとはなんぞ？ってなったわ

ﾄﾞ━━━━m9(ﾟ∀ﾟ)━━━━ﾝ!!

そうだ！
文頭の微乳はBOM扱いにして、ゼロ長ってことにすればどう？

天才現る

美乳、爆乳は何倍角ですか？

こんなお遊びの流れの中で指摘されてる問題の本質も>>492は理解できてないんだろうなｗ

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

ユーザーが自由に扱えるはずの、ただの一文字でしかないU+FEFFが
先頭にあるってだけでシグニチャ扱いするのは不確実で危険だ(仕様上決定されてない)と言う話なんだけどな
君一人だけだよ？話が理解できてないの

↑

>>498
じゃぁ、BOMをどう扱うか、仕様を示してみろよ。どうせできんくせに。

>>505
乳に長さがあるのか？龜ならあると思うが

>505
文頭に限らずゼロ長にすれば、「文頭のみ」なんて気持ち悪い処理は要らんじゃん。

BOM付きファイルはテキストファイルじゃなくてバイナリファイル。
メタデータの付いた「テキスト」ファイルなんてねーよ。

テキストファイル・バイナリファイルの定義自体曖昧なわけで

>>513
制御コードはテキストファイルか？
http://ash.jp/code/ctrltbl.htm

スクリプトの先頭行の#!とか副ストリームにZoneId付加するのとかはｾﾌｾﾌ?

印字できないものは全部ｱｳｱｳ

タブ・半角空白・全角空白が含んだのもバイナリファイルか

>508
最新の規格だと、U+FEFFはBOM以外の用途に使うな、となってるらしいけど。

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

※某短距離走者の名前を出したら爺決定。

ビートたけしのスポーツ大将

>>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

>>508

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

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

で、顧客などから要求される仕様としての文字数の扱いは、後者の場合が多いわけで、
その実装の手間はBOMに限らずタイプフェイスを持たない文字全般につきまとう問題だよね。

>>515,517,518
BOM付きファイルは、BOMパート + テキストパートという構造を持つコンテナフォーマットの一種。
テキストファイルは、テキストパートのみを含み、それ以外を含まないファイル。
制御コードやホワイトスペース文字はテキストパートの一部を構成するものに対して、BOMはテキストパートの外側にあるものなので、そもそも扱いが違う。

BOMの扱いが決定不可能な問題について質問と言う形で出す
↓
変な子が、ファイルサイズと文字長は違うよと言ってくる
↓
知ってると返す
↓
変な子が、人が扱う文字長とプログラムで扱う文字長は違うと言ってくる
↓
知ってると返す
↓
変な子が、いやおれの中では文字長と言えばこう定義されてるし別物なんだよと言ってくる
↓
だから、そんな話はしていないからもうレスしなくていいよと返す
↓
変な子が、人が扱う文字長とプログラムで扱う文字長は違うんだよ！昔からの当たり前の話だろうと言ってくる
↓
開いた口がふさがらない
↓
変な子が、コンピュータ処理で言う１文字と人が認識する１文字とは違うんじゃないのと、また繰り返してる
↓
もうやだこの馬鹿　←いまここ

岡田監督にどうなんですか？って聞き続けるコントを思い出した。

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

ここまでのまとめ

保守派の主張

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

革新派の主張

おエライさんが決めたことだぁ？だから何だよテメェ。
何をどう使おうと俺の勝手だ。
１文字＝１バイト圏の毛唐の決めたクソ仕様なんざ、守る必要ねぇ！
UTF-8にBOMあったってええやん。これをUTF-8テキストどうか識別するのに使ったってええやん。

UTF-8にBOMを挿入可能なのは規格上許容された事だろ。
unixのshell scriptとかで#の前にBOMがある場合は使えませんよってだけ。
UTF-16のみに使うべきなどというのは、根拠の無い主張に過ぎない。

Use of a BOM is neither required nor recommended for UTF-8

>>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（同期信号）

テキストファイルなんてものは存在しません

ttp://unicode.org/faq/utf_bom.html

^G は普通にテキストファイル中で使うよな。
たとえばバチファイルでこんなふうに。
IF ERRORLEVEL 1 ECHO ^Gエラーが発生しました。
(実際に制御コードを埋め込む↑)

テキストファイルの判断は、
・最上位ビットが立っていない
・改行コードが入っている
・'\0'がない
ってのがあると思うが、UTF-16はどれもだめ。これじゃ単なるバイナリ

最上位ビットを入れたら、Shift_JISもEUC-JPもUTF-8もアウトですよ。
そこはさすがに冗談ですよね？

>>535
Linuxのfileコマンド叩いてみな

>>534
Perlの-Tもそんな感じだね。あれはASCII TEXTって言ってるけど

>>536
Linuxなんて知らねーよ。持ってる奴の方が少ないだろ。
そのfileコマンドとやらの結果が何であっても>>534がおかしいことに変わりはない。

Linuxなんてファイル名すらバイナリデータとして扱うぶっ飛びキチガイ仕様じゃねえかｗ
「テキスト」に関しては一切参考に出来ない糞の塊

>>536
リナックスってそんな馬鹿なんだｗ

Linuxはファイルシステムに文字コードが規定されてないから
どの言語でも扱えるようにバイナリデータで扱うしかできなくなってるらしいｗ
ファイルシステムはUnicodeにしとけよ。マジで馬鹿ｗ

もっと煽って

$ 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

$ echo 美乳 | nkf -e > euc
$ file euc
euc: ISO-8859 text

OSは透過性が高くつくってあるのがいいに決まってるじゃねーか。
馬鹿なの？　死ぬの？

ファイルシステムはここでやっているからやるならこの続きから
http://hibari.2ch.net/test/read.cgi/tech/1093251312/208-282

めも

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

| NTFS ファイルシステム上のファイルを Windows のファイル圧縮ツール(zip, lha など）で
| 圧縮ファイルにまとめると、Windows カーネルは、ファイル名を Unicode -> SJIS 変換して
| ファイル圧縮ツールに渡し、ファイル圧縮ツールは、SJIS のファイル名で圧縮ファイル内に保存します

何だよこの糞仕様。UTF-8にしないと後生まで後悔するぞ。

もう手遅れ。
WindowsはファイルシステムはUnicodeなのに使っちゃいかん文字があるという
不思議仕様になってる。Unicodeファイル名含むアーカイブ渡すと罵倒されるよw

それ太古のUnicode非対応アプリの話だろ。

アプリのエントリポイントが昔ながらのmainであればMBCSに変換、
wmain であれば Unicode のまんま渡される。
また、wmain なファイル圧縮ツールも存在する。（Explzhとか）
なので>547,548は正確ではない。

そもそも exe に渡すファイル名が、常に SJIS に変換されるのであったら、
explorer で開けないフォルダを作れてしまうと思うけど。

太古のＵｎｉｃｏｄｅ非対応アプリ(当時圧倒的主流派)への互換性を優先し
今まで通りのやり方(太古の主流派)で作られた場合、今まで通りの文字コードが渡されるようにしただけだな

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

>>549
お前の脳みそウンコに入れ替わってるみたいよ？病院いってら

Windowsの某フリーエディタはmain()がUnicodeで無いみたいで、explorerで開けないファイルがあるが

>>553
失せろ

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

文字数を固定長としているのが悪い。
MAX_PATHもプラットフォームでばらばら。

とはいえバッファサイズは決めなきゃならないしな

>>549
> もう手遅れ。
> WindowsはファイルシステムはUnicodeなのに使っちゃいかん文字があるという
> 不思議仕様になってる。Unicodeファイル名含むアーカイブ渡すと罵倒されるよw

使っちゃいかん文字ってコロンとかじゃなくて？

>>556
ファイル名に限らず文字列は動的に確保するものだろ。
制限の厳しいWindowsでさえファイル名が最大3万文字なのに固定でバッファとる奴はアフォ。

>>558
それ本気でいってんの？

>>559
言語は？

>>558は話題領域を把握できてないタコスケ

char path[MAX_PATH]
wchart_t wpath[MAX_PATH]
バッファ食いすぎ

>>562は話題領域を把握できてないタコスケ

そりゃあBOMだけで３バイトも食うから低レベルな領域でUTF-8は使えないなぁ

>>562
getcharで1文字ずつ取っていって、足りなくなったらreallocするの？

>>565
Windowsのワイド文字からマルチバイトに変換するなんたらって関数は、
必要バイト数を返してくれるオプションがあるから、それでもらってそれで確保する。

Cには文字列型がないので処理がめんどくさい。エラー処理でのfreeをずっと気にしなければならなくなる。

Unicodeはダサイよな

ダサいけど現状一番マシな選択肢だからしょうがない

| char path[MAX_PATH]
Windowsでこんなプログラム書く奴は死んで欲しい。
全角文字ばかりの240文字のファイル名渡されたらどうするつもりだ。

>>570
Windowsでっていうけど、
じゃあLinuxだとどうすんのさ。

LinuxだとPATH_MAX。パスの長さは4096文字あれば十分だろ。

100文字あれば十分だと思う

> char path[MAX_PATH]
海外のシングルバイト前提のアプリでは平気である。
日本のでもShift_JIS前提でchar path[MAX_PATH*2]てのもある。
これじゃ、UTF-8なんて無理。
まだ TCHAR path[MAX_PATH] の方がまし。

MAX_PATH*2なんて、Win32 APIが扱えない時点で無駄。
wじゃないWinMainアプリはマルチバイト文字ファイル名を扱えない欠陥アプリ。
長い全角ファイル名があると フォルダのファイル一覧取得APIがエラーになるんだぜ。

Windowsの場合、サロゲートペアの文字はどうなるの？
ノートパッドだと、1文字で2文字にカウントされるよね？

>>574
いや、UTF-8かどうかなんて関係なく
パスは無限の長さを持つんだよ。
シンボリックリンクを使えばね。

だからMAX_PATHだろうが、PATH_MAXだろうが
どちらにしろ関係ない。
パスの長さを固定にしている時点でどちらも同じ。

>>566
で、そのワイド文字は、メモリ上にないのか？

>>578
wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] )

>>577
で？
可変に拘るのはいいが、無限の長さをどうやって扱うの？

PATH_MAX、4096バイトって
たかがパス一つ保持するだけで
スタック4KBも消費するのか・・・

>>580
どうやって扱うかじゃなくて
バッファオーバーフローして
セキュリティホールになるのが問題なんだよ。

バッファオーバーフローにさえならなければ
char path[MAX_PATH]での
何の問題もないよ。

単にこのソフトはMAX_PATH文字のパスしか
扱えない仕様ってだけ。

>>582
そりゃバッファが固定長なのが問題じゃなく、バッファの長さを管理してないのが問題なんじゃねぇか

>>583
文字じゃなくてバイト
Shift_JISなら最後のバイトが欠ける可能性がある

○　バッファオーバーラン
×　バッファオーバーフロー

"バッファオーバーラン"　　　約 16,500 件 （0.17 秒）
"バッファオーバーフロー"　約 107,000 件 （0.03 秒）

＾＾；

で？
バッファオーバーフローは実際に発生したデータ量が予定していたバッファのサイズを上回ること。
バッファオーバーランはバッファオーバーフローした際にデータサイズをチェックしなくて予定外の
メモリを変更されること。意味が違う。

>>585
それは、バッファのサイズを
いくつにしようが発生する問題だろ。

>>588
少しはぐぐった？
どちらも同じって書いてあるよ。

>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

○バッファオーバーフロー = バッファオーバーラン

>>591
ソースがwikipediaかよｗ

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

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

結論　バッファオーバーランが正しい。

つまり、WikipediaにあるUnicodeの説明も全て間違いと言うことですね、判ります。

>>592
じゃあお前のソースはなに？

予定サイズを上回ったら自動的に何かが書き込まれて変更されるからな。
結果としては一緒。

>>592 逆裏対偶の区別もつかないバカ登場wwwwwww

char path[MAX_PATH+1]と+1を付けていなければどっちも起きるわな

得意げに○×やってみたら自分が間違ってた時って、どんな気持ちなんだろう

なんか本筋でないところでもめているようだけど、CERTやCWEでは"buffer overflow"が使われている。
あと stackoverflow.com とか名付けられているように、overflowのほうが普通に使われているようだね。

>>597
+1 ってセコすぎる。たった1バイトしか余裕がないのかよ。
せめて1文字分は余裕持たせたほうが・・・おっと、「1文字とは1バイトである」って概念
に毒されたひとには何を言ってもムダか。

醜いレス乞食

>>588
「バッファから溢れる」現象を指してオーバーフローと言うわけで
「バッファを越えて書き込んだ」現象を指すオーバーランとどこも違わん。
オーバーフローしてりゃオーバーランしてるし、オーバーランしてりゃオーバーフローしてんだよ。

顔真っ赤にして恥の上塗り乙。

>>575
FindFirstFileA/FindFirstFileW両方あるが？

>>597
> char path[MAX_PATH+1]と+1を付けていなければどっちも起きるわな

なにが？

今時のOSはパスの最大長は無限長なのを
まだ理解できてないの？
シンボリックリンクを使えばね。

文字列を固定長で取っていれば、どんなサイズにしようが
バッファオーバーフローが起きる可能性はあるし、

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

Shift_JISなら最後のバイトが欠けるというのは、
1バイト文字を混在して使える（つまりバッファサイズを
何文字にしてもおきる話）ということに気づいていないので論外。

だってさ
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

あと、NTFSはUnicodeで255文字、
NTFSはUTF-16と決まっているので、
charのMAX_PATHを×2にするのは正しい。
（Shift_JISだから×2なんじゃなくて、UTF-16だから×2なんだよ）

>>606
それは、ファイルシステム上の物理的なパスの長さね。
シンボリックリンクを使えば無限になるから。

UTF-16で帰ってくるってことはW系APIだろ。
何故WCHAR使わずにcharで受けるんだ？

(1)ストレージに記録しておける個々のファイル名・フォルダ名の長さ
(2)ストレージに記録しておけるパスの長さ
(3)APIに渡せるパスの長さ
(4)状況として発生し得るパスの長さ（例：>608）
をきちんと区別して語ろうず。

ちなみにWindowsの場合、
(1)255 (NTFSの場合。)
(2)パスは記録していない
(3)32767 (2k以降?)
(4)無限

>>607
サロゲートペアの文字は一文字と数えるの？

>>609
http://hibari.2ch.net/test/read.cgi/tech/1093251312/281

シンボリックリンク使わなくとも昔から
./././././hoge
みたいにやたら長いパスを渡せるな。

>>605
> Shift_JISなら最後のバイトが欠けるというのは、
> 1バイト文字を混在して使える（つまりバッファサイズを
> 何文字にしてもおきる話）ということに気づいていないので論外。

サロゲートペアでも欠けるんじゃね？

合成文字はどうするんだろ
正規化する必要あるの？

charだろうがwchar_tだろうがバイト・文字が欠けるのは一緒。
だったら汎用性の高いcharでUTF-8の方が良い。

しつこくシンボリックリンクと繰り返してる奴はどこの脳内Windowsの話をしてるの?
すくなくとも実在のWindowsではシンボリックリンクは32回以上ネストできないし
「展開後」の長さがWCHARで数えて32767文字を超えられないから
無限にはならない

>>617
親ディレクトリへのシンボリックとか
ネットワークファイルシステムとかあるでしょｗ

>>617
覚えたばっかのニワカ知識を振りかざしたくてしょうがないんだろ
猿のオナニーなんざ止めようとするだけ無駄

どうでもいいけど、誰もWindowsなんて言ってないのに
なんで限定するんだろう

>>620
変な名前のが出来て嬉しくて仕方が無いから

>>597
MAX_PATH+1 ほど情弱なもんはない

>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

削除用バッチ訂正。

×for /l %%n in (0,1,10) do (
○for /l %%n in (0,1,500) do (

ウイルス貼るなクズ！

>>625
お前様はマルウェアは押し並べてウイルス扱いするお間抜けですか。

マルウェアかどうかすら怪しい

>625
それを言うなら「ヴァイラス」だろ

ヴァイタミン

ヴィニュー

ヴァニラタン

ヴェガス

ビールスだろ

beers

ヴィールス

そろそろまとめろ

>>602
バッファオーバーフロー
　　バッファサイズ以上に書き込む
バッファオーバーラン
　　バッファサイズ以上に書き込む／読み込む

>>637
お前の定義はいらんから、
どこからか出典もってこい。

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

じゃあ、サイナラ

バッファオーバーフローの例
main()
{
  int unko[10];
  printf("%d", unko[20]);
}

つ、釣られないぞ・・・

バッファオーバーランの例

void main()
{
char oppai[1];
strcpy (oppai,"美乳");
}

>>638 惨敗だな
常識に「出典もってこい」とは恥ずかしい。
中学２年生かおまいは！

バッファオーバーフローの例
void f(char buf[])
{
　char manko[200];
　if ( strlen(buf) >= sizeof manko / sizeof *manko ) throw "buffer overflow";
　strcpy(manko, buf);
　：
}

┌─────────────┐
│　　　　CrossDays　　　　　　　　　│
│　11GBの空きが必要です　　　.│
│　　　　　　[ＯＫ]　　　　　　　　　　.│
└─────────────┘ （　ﾟдﾟ）

>>642
どっちも同じ意味だなんて、常識だよね。

「Unicode 6.0」が策定、絵文字が国際標準に
http://k-tai.impress.co.jp/docs/news/20101013_399811.html

UNK絵も国際化されたわけだ。

>>646-647
ここはインディアンがテーマなのですれ違い

ビッグインディアンって白人？黒人？






エンディアンの間違いじゃないのかｗ

無粋すぐる

ここはキチガイ論者の隔離スレとして再利用されたから、ここでいいんだよ。
しかし使えない絵文字ばかり集まったな。これじゃ携帯メールのUnicode化なんて無理だ。

おでんに海苔せんべえとか、
随分と日本ローカルなもんまで採用したんだな。
こんな事認めてたら、収集付かなくなりそ。

ヘタクソというか素人臭が漂う絵ばかりだなあ

サンプルのデザインをあげつらってもしょーがないべ。

>>646
Googleによる企業支配の幕開けだな

×収集
○収拾

1F4A9

💩

\u1F4A9

U+1F4A9

\x{1F4A9}

絵文字に関しては、字体もコード表に合わせなくても怒る人いないの？
漢字はそうなってるし、波ダッシュ・全角チルダ問題も字の形がちょっと違うことが原因で起こったトラブルだったのに。

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

絵文字も異字体セレクタで別の字体を選べるの？

絵文字は色もついてるしアニメするし、どうしようもない。
各社でちがうし。

1F4A9には臭いもついてます

http://www.google.co.jp/images?q=PILE%20OF%20POO

うんこage

チャットで
ௌௌௌௌௌௌௌௌ☠ௌௌ☠ௌௌௌௌௌௌௌௌ☠ௌௌௌௌௌௌௌௌௌ☠ ௌௌௌௌ
ってうたれたら文字真っ白になってバグるんだけどどうすればいいかな？
エンコードしても無理みたいｗｗｗ

>>667
死ねばいいと思う

>>668
なんでやってｗｗｗ
マジで対策法教えてくれ

>>667
何かと思って調べてみればタミル文字じゃん
試しにエディタに貼り付けてみたら、秀丸、gPad、K2Editor、Notepad++では無理だった
サクラエディタとMeryはOK

これ、そのチャットアプリで対応してなければ無理じゃね

ちなみにうちの秀丸(7.10)はOKだったお(UTF-8で)

ちなみに対策としては、相手のインド人に
英語か日本語を使うようお願いするといい

別のチャットシステムを試すというのも考えるべきだよ。

サポートに修正依頼する。ちなみにWord 2010に貼り付けたら固まったぞ。

「文字コードはUnicodeで」とか言う奴が多くて困る。
お前はホントにISO-10646-UCS-2のつもりなのかと、サロゲートペア使わないんだなと
言ってやりたい。

UCS-4のつもりかもしれないじゃまいか

UTF-16だってUnicodeじゃん。
むしろUTF-8でもUTF-16でもUTF-32でも好きなのを選んでいいのだなと小一時間(ry

じゃあUTF-7で

さすがに非標準は選択肢に入れたらダメだろうｗ

punycodeってどうなんだっけ？

Unicodeは規格であって文字コード(エンコーディング)じゃないからねぇ。
ISO-10646-UCS-2って言ってるからIANAのUnicodeのことじゃないの。
> Name: ISO-10646-UCS-2
> Source: the 2-octet Basic Multilingual Plane, aka Unicode
「aka Unicode」なんて書いた奴だれだ。

それはNameでもAliasでもないから
エンコーディング名として「Unicode」が認められてるわけじゃない

Windowsのことじゃないの

赤UNICODE？
青UNICODEや
黄UNICODEもあるのか？

also known as

UnicodeつったらUnicodeに決まってるじゃないか！

UNICODEがいくつもあるなんて変だよ

Multicodeに改名だ。

JISコードつったらJISコードに決まってるじゃないか！

Javaって未だにソースコードをUTF-8で書けないんだっけ。ウンコだな。

>>690
ファイルの先頭にウンコがついてるだけじゃないの？

>>691
ウンコじゃなくてBOM。JavaはBOMありUTF-8が扱えないうんこ。
ついでにこのスレで既に議論があった通り、不正なUTF-8でJARファイルを作成するうんこ

VC++も悲惨なんだけどなんとかならんのかな

VC++はウンコつきじゃないとコンパイルできないんだっけ。

Microsoft Visual C++はまっとうだろ？
　BOMあり→BOMに従う
　BOMなし→システム既定のANSIコードページとして解釈
コンパイルオプションに文字コード指定があっても良かったとは思うが、
BOMなしでコンパイラに自動判別を期待するのはクレイジー

VCだと　fopen("filename", "r, ccs=UTF-8");　でBOMなしもBOMありも読める。
おJava様のInputStreamReaderはBOMありが正常に読めないウンコ。

>>695
C/C++コンパイラはそれで構わないんだけど、
リソースコンパイラがBOM付きのUTF-8を認識しないんだ
UTF-16にすると今度は外部ツールが扱えなかったりと

じゃあVC++もリソースでBOMありUTF-8が使えないウンコ。

ソースコードやビルドリソースの文字コードに制限があるのはまだ我慢できるよ。
問題は>>696の通りデータファイルでBOMありなしの両方が扱えないこと。これは致命的

Microsoftの開発環境さえ無ければBOM無しUTF-8で皆が幸せに暮せるのにな
byte orderが無いUTF-8でbyte order markって何だよ？

さて、どこからループするのでしょうか？

>>700
それはマジ勘弁。シフトJISの資産が切り捨てられるならいいけど実際には無理。
素人が文字コードのよくわからんファイルを作っちゃってそれを判別しろとか言われると困る。
区別がつかなかったのでUTF-8と仮定して追記したら「実はシフトJISしか
扱えないアプリのファイルでした」とか言われるかも知れん。

今度からBOMはF0 9F 92 A9(U+1F4A9)でお願いします。
例: 「JavaってUTF-8扱えないの?」
　　「先頭にウンコついてるからじゃない? ウンコ取った方がいいよ!」

Linuxかぶれが公開してるオープンソースソフトに入ってた拡張子のないREADMEが、
改行コードLFでShiftJISだった時は死ねと思った
どういうエディタで書いてんだ

Mac

>>704
俺が今やってるプロジェクトのソースもそうだ。
開発サーバがシフトJIS+LF。本番サーバはUTF-8がデフォなのに
export LANG=ja_JP.SJISして使っているらしい。

FFFTPとかって改行コードを勝手に変換するモードなかったか？

いまどきFTP使ってるなんて

sftpは現役だと思うぞ。改行コードの変換機能があるかは知らないが

WinSCPでSFTP使ってるけど、転送は全部バイナリに設定してるなあ。
テキストエディタで開くだけなら文字コードも改行コードもあんまり意識しない。
Java使う時だけBOMのありなしに気をつかう程度。

ftpとsftpは全くの別物でしょ

イントラネット内とかデータセンターにシステムを構築する場合、既存システムとの
インターフェース仕様は当たり前のようにFTPが出てくる。目立とか目立とか目立とか。
そんでもってスレ違いだけどファイル書き込みが完了する前にファイル処理が走って
「想定外です。タイミングに依存した複雑な問題です」とか毎回言ってくる。仕様見直せよ。

>>712
日本語見直せよ。

LinuxでSJIS使うメリットってないだろ。
UTF-8の扱えないFFFTPはうんこ。UTF-8に統一してWinSCPが勝者。

業務だったらUTF-8になんかメリットないだろ。
だから信者の思いとは異なってLinuxはWindowsを駆逐できないんだよ。

SJISで表示できないコードがあるんですけど

LinuxがWindowsを駆逐できないのはユーザビリティが低すぎるからでしょ
サーバ開発でLinuxは十分成功してる。
UTF-8については、数年もしたら「旧システムは文字コードがシフトジス
なのでデータ移行の対象外」とかいう言い訳すら流行りかねない

充分？
壊れてもいいWebサーバくらいだろ。
バックエンドはAIXやらHP-UXばっかじゃねーか。

早くWindowsの日本語localeのmbcsがUTF-8にならないかな

>>719
本スレのどこかにmbcsが２バイトまでと決まっているから無理だと書いてあった

へー

Visual C++はCのsetlocaleも3バイト文字対応してないって書いてあるし、
一生UTF-8には対応しないんじゃ値

.NETでカバーするつもりなのかもな。

VC++でUTF-8の文字列リテラルを書けるようになって欲しいな。
u8"ほげほげ" って書くとANSIじゃなくてUTF-8になるとかさ。
今は実行時にワイド文字列から変換するか、すごく読みにくいけどエスケープして書いてる。

うーん、最近はasciiじゃない文字を含むリテラルを書くことがないなぁ。
VCならリソースだし、そうでなくてもそれに近い形にしてしまう。

UTF-8文字列を直接扱うのってメリットあるの?
どうせワイド文字に変換しなきゃ扱いづらいんだから、ワイド文字に統一で
いいと思うんだけど。

互換性の問題。

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

UTF16やUTF32だと、0x00という1バイトが含まれた
2~4バイトで構成された文字があるから既存のコードが動かない。

保存やデータ交換はUTF-8でいいけど文字列処理はUTF-16でって言いたいんだろ。
char const*しか受け付けないライブラリが多すぎるからUTF-16に統一は無理。

>>726
そのワイド文字がWindows APIでは２バイト。
１文字固定長でないのに。

日本でシステム構築してる限りは合成文字もサロゲートペアも
たぶん出てこないから大丈夫

濁点・半濁点の文字はそもそも合成文字だし、
今度の常用漢字の改定で「叱」の本字が
サロゲートペアになっちゃう領域に入ったし、
何で出てこないといっているのかわけわかめ。

>濁点・半濁点の文字はそもそも合成文字だし、
そんなもんどこで使われてるんだよ。

Macはファイル名を正規分解で扱うから濁点は分解される

Macってなに?　それうまいの?

>>734
グルメなvoidさんが愛用しているからうまいんじゃないの？

グルメってのは味はわかってないけどうんちくだけ一流ってやつだよ。

>>727
またその話か。前スレだか他スレだかで出たとき、結局どういう話なったんだっけ？

8bit長と16bit長を同じに考えてるのが不思議

>>737
fopenに飛び火したのならここに残っている
http://hibari.2ch.net/test/read.cgi/tech/1093251312/

>>739
あー、結局、UTF-16でもUTF-8でもどうせ微妙だよって結論だったか。

>>740
そうか？
単純にchar*に突っ込めるUTF-8があったからこそ
Unix/LinuxがUTF-8化できたようなものだって
結論だったと思うが。

UTF-8は史上最高の符号化方式
Unicodeは史上最低のコード体系

>>742
激しく同意、という言葉はこういうときに使うのか。

>>743
激しく同意、という言葉はこういうときに使うのか。

最低ってこたないだろ。全世界の文字を収録するという世界初の試みなのに
使い物にならなくもないレベルでよくまとまってる。
シフトJISみたいに無駄に文字の重複があったりする糞コードよりはマシ。

でも多分、Unicodeをなかったことにして全く新しいものを築こうって流れは自分が生きてる間には来ないよね

たとえtronコードがいかに素晴らしくてもUnicodeが使われる

テキストファイルに保存するときのコードと
ＣＰＵ内部で演算処理するときのコードが
同じでなければならない、って考えがUNIX・LINUXでは根強い。
そもそも、テキストファイルとバイナリーファイルに違いが無い、って考えがある。
一方、Windowsやらjavaやらでは、内部と外部のコードが別でいいじゃん。
内部コードをユニコードに統一して、テキストファイルはシフトJISでもビッグ５でも
ＵＴＦ８でも何でもいいじゃん。入出力時にＩ／Ｏレベルで相互変換すればいいじゃん、って考え。
現代のインターネット時代ではありとあらゆるテキストファイルを混在処理しなければならないから。
UNIX・LINUXはコンソールアプリ時代の古い考えが捨てられないんだよ。
何しろ世界中何十万人？何百万人のユーザを捨てることになってしまうから。
Windowsはゲイツの鶴の一声でどうにでもなる。嫌でもゲイツに付いて行かざる終えないから
不満があろうが無かろうが長文疲れた文章のシメが思いつかん工業高校卒なので頭悪い許せうんこちんちん

>>748
Gtk、Qtは内部はユニコードですよ

それがどうかしましたか

> UNIX・LINUXはコンソールアプリ時代の古い考えが捨てられないんだよ。
という考えが古いのではないかと

「内部」が何を指してるのか知らないけどC標準関数にしろperlのビルトイン関数にしろ
英数以外使う気のない関数がやたら多い。
GUI系のライブラリは流石にその辺考慮してなんちゃってutf8に対応してみたり（SDLとかSDLとかSDLとか）
なんかBOMなんていうずれた対応してみたり（VSとか）
Windowsとか*nixとか関係なくて、OSとか言語作ってる連中はみんな英語圏なんだから英数以外まともに扱う気ねーよ。

>>752
> Windowsとか*nixとか関係なくて、OSとか言語作ってる連中はみんな英語圏なんだから英数以外まともに扱う気ねーよ。
そのためにutf-8は作られたのではないか？

以前にソースコードにエンコード情報を持たせないのが*nixの常道
（全てASCIIで構成）という話を聞いたことがあるんだけど、
それはその人の意見という話だったのかな

プログラミングWindows（上巻）の冒頭で
65536文字あれば世界中の文字を収められるぜヒャッハーみたいな寝言が書かれてたり
CJK統合漢字みたいに「形が似てるから一緒でいいだろ＾＾」なんつー暴挙に出たり

欧米人の認識力の甘さには勃起を禁じえないぜ

>「形が似てるから一緒でいいだろ＾＾」なんつー暴挙
素人質問で悪いんだが、どんな被害があるの?
原規格分離でシフトJISの違う文字は全て区別できるようになってるから
何が問題なのかわかりませぬ

一緒
ー諸
ー諸
-1
‐1

>>756
Han-Unificationのことでわ?

>>754
それは、メッセージなんざリテラルで書くな全部メッセージカタログに追い出せ、という主張だったのではあるまいか。

>>757
オマエ言いたいことわからない。死んだほういい

−諸

>>760
見た目に区別のつかない文字がいっぱいあるから もっと統合した方がいい、
という意見だろう。

フォントだけを統合するの？コードも統合するの？

どうしたらこの文脈でフォントの統一なんて解釈が出てくるのか不思議

フォントというか字形（グリフ？）
コードまで統合されると形態素解析とか検索に影響が出るし。

似ている文字は統合するなんてことは
しないほうが良かったね。

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

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

日本文字か、中国文字かわからなくて、ごっちゃになるなんて問題は
アプリ側で対応すればいい。検索の場合も、日本語の文字検索の他に
似ている形検索という機能をアプリ側に用意すればいいだけの話。

これは陰謀だ

Latin-1のA1hとLatin-15のA1hも違う文字にするの? アプリ死ぬよ?

16ビットですべての文字を収録するなんて目標がハナから無理だとわかってれば（いや、わかってたわけだが）
統合しなかったかもね

IPアドレス枯渇問題ににてるな

>>748
いろんな入力が入ってくる可能性があるからこそ、出力はUnicode系文字コードが必要なんだろーが。

国際化にあたっては、文字コード以外にも色々と(↓)考慮が必要なのに、こんな調子では…

・記述方向（右→左や双方向、縦書き）
・カーニングとかの組版ルール
・禁則処理ルール
・ソートルール　（A…Za…zとAaBb…Zzの違いとか）
・活用等による語形変化のルール
・主語・述語・目的語・etcの順序
・冠詞とか
・小数点/桁区切り記号の違い（例：ドイツ式→12.345.678,9）
・桁区切りの違い（例：インド式→12,34,56,789）
・負値の表記（ 1-だったり (1)だったり）
・通貨の表記（-\100だったり\100-だったり、小数点とかの記号が違ったり））
・日時の表記（年月日の順序バラバラ）
・13月まである暦
・測量単位系（メートル法/ヤードポンド法）
・用紙の規格（A?系/letter・legal系）
・スラング
・シンボル（国によっては十字架や六芒星はアウトとか）
・etc

>>770
IPアドレス枯渇問題は、仕方ない。
v4ができた当時から、インターネットがこんなに発展することを見越した実装ってのは現実的じゃなかった。

一方、世界中の文字が65536文字で収まりきらないことは、調べりゃすぐに分かったはず。

馬鹿は黙ってろ

黙って書き込んだり、黙ってつぶやいたりする時代ですわ。

>>773
IPv6が通常接続料金とは別料金を払わないと利用できないISPだらけなのが問題なのね。
IPv4を有料利用していればIPv6は基本的に無料にすればこんなにIPv6の立ち上がり
が遅い状況は生まれなかった。
別料金払ってまでほとんど利用しないIPv6を使うか？
ぜんぶISPが引き起こした問題で、解決するにはISPに責任を取ってもらうべき。
IPv4を通すトンネル接続じゃ意味ないんだけど。

>IPv6の立ち上がりが遅い状況は生まれなかった。
そうか?　IPv6のメリットを村井純が説明できなかっただけだろ?
ISO-2022-JP2と同じく誰も相手にしてない。

誰も相手にしていない。

自分を騙す必死の呪文ですw

どこかの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 バイト形式を使用

bmpに入らずんば文字にあらず

>>779
いや使えるから。Cとかよりもよほど簡単に。スレにあったのは単にnioのバグだ。
あと偽UTF8はclassファイル内部のリテラル表現(とjarのフォーマットもか)の話で、通常のデータ入出力には関係ない。

>>781
そのページ見るとJNIでJVMに渡す文字列は全て偽UTF-8なのでは?

JVMの実装内部に関わる部分はたいてい偽UTF-8のような
その方が処理しやすいから・・・かどうか知らんけど
OutputStreamWriterとかCharsetEncoderとかString#getBytesとか
明示的にエンコーディング名に "UTF-8" って指定して使うやつは、普通のUTF-8で処理するのでは？

>>724
>VC++でUTF-8の文字列リテラルを書けるようになって欲しいな。
無理。Windowsは実行ファイルに埋め込まれたANSIリテラルをUTF-16に変換する時、
システムデフォルトのコードページ(932)を使用する。
環境変数LANGで切り替える方式にしないと、シフトJISが埋め込まれた
既存のプログラムとUTF-8アプリの混在が不可能。

>>784
え？
馬鹿？

おまえがバカ

日本国内しか対象にしていないアプリで日本語を埋め込もうが勝手

>>784
お前、自分が言っていること良く考えてみ。

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

実行ファイルに埋め込まれた時点で、
なんらかの文字コードになっているわけで、
それをどうやって実行時に切り替えるんだよｗ

>>788
何を言ってるのかさっぱり分からない。

実行ファイルに埋め込まれているのか？
Windowsアプリも、AとWがあるが。

特定の文字コードで文字列が実行ファイルに埋め込まれて、
Windowsからしたら与えられた文字列がsjisなのかutf8なのか区別がつかない
から無理と言ってるんだろ

char8_t型があれば問題ないが、
C++0xドラフトには未だないね

L""でない""のリテラルのことか？

utf8を扱う文字列クラスでも作れば

APIを使って表示したり文字列操作をしたりするのでなければ問題はない。
VC++でエディタから文字を直接入力してそれをUTF-8のリテラルとしてリソースに埋め込みたいんだろ。
ネットワーク関連の処理かな。

UTF-8を扱うアプリなんぞいくらでも考えられる
エディタとか

>784,788-791
コンパネの「地域と言語の設定」で設定したロケール情報を読み取るAPIが存在しますが。

例えば setlocale( LC_ALL, "" ) でC標準関数やMFCの挙動がロケールに即したものに変わる。
例えばドイツ語(ドイツ)だったら、マルチバイトテキストをcp1252として扱うようになるし、
printf( "%f", 1.23); の出力が「1,23」になる。

だから、
char s[] = "日本語";
って文字列は？

>>797
そんなもの呼ばなくてもA系API読んだ時点でシステムロケールが考慮されるでしょ。
それを考慮したって「プログラム中に埋め込まれたリテラル文字列」が変わるわけじゃない。

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

結局、.objファイルごとにロケールのメタ情報を持つか、Unicodeみたいな統合文字コードを
持ってくるしかない。

コーディングの手間を減らしたいってだけの話が
いつの間にかWindowsシステム内部における文字エンコードの扱いの話になってるのはなぜなんだぜ

VC++って限定しているのか。
他のコンパイラを考えるとカオス。

Windows内部でもVisual C++限定の問題ではないような・・・
GCCでもいろんな文字コードでリテラル文字列埋め込まれたら問題あるのでは?

>799
文字列を扱う前に適切なタイミングでsetlocaleとかすりゃ、一応は混在可能。
プログラマにその辺意識させないようにするには、メタ情報とか必要だけどさ。

ちなみにリソース化しとけば言語情報は付加される。
1つのexe/dll内に複数の言語のリソースを混在させたり、
外部dllの形で言語を追加することも可能。

ロケールは基本的に使わない方がいいと思う
ロケールってあまり当てにならない

>802
大丈夫だ、問題ない。
GCCもPGが setlocale(LC_CTYPE,...) とかで各々指定すりゃ良い。

>>805
C++だけど、他人の作ったclass ore_exception::what()がどんな文字コードの
メッセージ返すか調べて、what()の度にsetlocaleするんですね。やってられんですよ。
what()の返す文字コードはコンパイル時に決まってるかもしれないんだよ？
自分(呼び出し側)のメッセージと連結したいときはどうすんのよ。

もういいよ。「リテラル文字列どうすんの」って言ってるやつと、
それを理解しない「setlocaleでおk」の会話がループするだけ。

setlocaleって言ってるやつは、文字列を受け渡しするたびに
setlocale→mbstowcs→処理→setlocale→wcstombs　するわけ?
最初からwchar_tでやったほうがいいに決まってる。

可能ってだけで、それが現実的かどうかは別の話。
あくまで「不可能じゃない」だけ。

ちなみに「大丈夫だ、問題ない」は知らない人のために
ギャグのつもりだと断っておく。

>807
全体で統一すれば、一々setlocaleする必要ないじゃん。
そーいう意味では本気で問題無い。

とりあえず漏れは>784とかが「不可能」と言ったのに対して「可能」と返してるんであって、
実際無理かどうかはケースバイケースだと思うよ。

VC++って、コメントに日本語書かなきゃ、ソースをBOM無utf-8にすると、
リテラルがutf-8になるよね。たぶん

| char const msg[] = "あ";
このコンパイルが通らないのだが。

みなさんお久しぶりです。>>265以来の>>1です。
このスレも隔離スレとして再利用されたようなので幸いです。
そろそろ次スレ立てなきゃいけませんよね。
「Unicode隔離スレ その3」でどうでしょうか

おいやめろバカ死ね

>>812
ここが先
http://hibari.2ch.net/test/read.cgi/tech/1291075205/

UnicodeはUTF16だとあれほど（

UnicodeがUTF-16なのはMS用語で、一般にUnicodeと言えば
文字コードに関する規格の名前。別におかしくないと思うが。

JavaもUTF16だけど？

>>811
一文字目にゴミが付いているからでわ？

多分UTF-8だと(VCでは)コンパイルが通らないと言ってるんだと思われ。

リテラルといえども￥があるからコンパイラが文字コード解釈しているのでは？

UTF-8だとmsbitが立ったのが3バイトになるから、
閉じるための"を食ってると思われ

思われ

>>724が例に書いたu8"Hoge"ってUTF-8文字列リテラルは、
今度のC++の規格改正で導入される見込み。
g++でも4.5から使えるようになっており、VCも近い将来のバージョンで対応すると思うぞ。

>>784とそれに連なる馬鹿共は一体なんだったんだ･･･

u8""とやらの型がchar[]なのか別なのかがわからんが、
現在の規格のchar[]にutf8を入れると問題があることに変わりないだろ。
お前がバカ。

VCってコメントとかもSJISなんでしょ。
u8""が対応したとして、中の文字コードは何で書くの？

英語で書けばいいんじゃね

>>826
ワイド文字列と同じで、VCならそーすは何で書いたっていい。
・今まで
　ソースUTF-8の 文字列→SJISに変換される
　ソースSJISの 文字列→SJISのまま
　ソースUTF-8の ワイド文字列→UTF-16に変換される
　ソースSJISの ワイド文字列→UTF-16に変換される
・u8""の対応
　ソースUTF-8の u8文字列→UTF-8のまま
　ソースSJISの u8文字列→UTF-8に変換される

>>826
無知すぎ失せろ

>>826>>828
GCCだって--input-charsetと--exec-charsetがあるよ。

VCはソースファイルのエンコーディングを指定できないからウンコ

character setとencodingの区別がついていない人たちなんですね

VCはソースファイルのエンコーディングを指定できないからウンコ

Windowsのシステムロケールを英語にして
ソースをUTF-8で書けばよい

節子、それLatin-1や

VCはソースファイルのエンコーディングを指定できないからウンコ

VCでもファイルメニューから保存の詳細設定でエンコード指定できるけど
それじゃだめですのん？

ファイルにBOMが付いていればUTF-16かUTF-8、付いてなければANSI(日本版なら
cp932)として強制的に処理しちゃうのよ。

mbcsでは？

1バイトのcode pageもあるから

英語ならCP1252

cp65001

http://practical-scheme.net/chaton/gauche/a/2009/11/16

Shift-JISで書かれたソースは日本語環境じゃないとコンパイルできないってありえねえ。

いまどきはソースにSJIS埋め込まない

VCって日本語のコメントを自動生成しなかった？

VCはソースファイルのエンコーディングを指定できないからウンコ

よそのスレで富士通のJavaのコーディング規約みたら、SJIS推奨だった。
SJISかもしくはEUCみたいな感じ。

不治痛は納品先が官公庁だからかね

S務省・B衛省相手に仕事させてもらってるけど、殆どUTF-8でOKだぞ。
それにプログラミング言語や文字コードで指定があることなんて
そんない無い。富士通が時代遅れの糞なんでしょ。

誰かVC++の#pragma setlocale試してみないか？
http://msdn.microsoft.com/ja-jp/library/3e22ty2t.aspx
文字列リテラル・ワイド文字列リテラルの変換に使われると書いてある。

MS用語でUnicodeはおそらくUTF-16 リトルエンディアンでfffeのボムつき

SJISはウンコ

理由は？

>>854
Windows-31Jの文字しか扱えないし、日本以外のシステムに通すことが
できないから。
SJISは文字コードとしてはがんばったけど、もう引退すべき。

hagedou

うむ。

だったらBIG5だってウンコじゃないか

UTF-8はユニコード文字しか扱えないからウンコじゃないか

UTF8はSJISと違って\マーク変換しても文字化けしない

SJISはウンコ、CP932はウンチ

ウンコとウンチの違いが分かりません＞＜

どっちも触りたくないものにはちがいない

>>860
でもWindowsだと~化けるよね

規格決定する前に先走ってしまい、へたに大きなシェア抱えてるから、
引っ込みがつかなくなっていつまで立っても規格とマッチしない
ってのは、M$の場合よくある話

ということで、みなさん。
規格決定まで突っ走らないように。

とくにHTML5関係。

>>866
規格が決定するまで待ってたら後10年かかるだろ

一方、SamsungはDDR4のDRAMモジュールを開発完了したと発表

>>864
はつみみだな。詳しく教えてくれ。

半角は7e、全角は波ダッシュ

WindowsだとUTF-8で7eを保存して開くと文字化けするの?

Windowsは関係ない。
それはアプリの仕様

￣

ちょいと質問です。

ビッグエンディアン環境で作成したUTF16の文章をリトルエンディアン環境で
読みとる場合ですが、こういう場合は自前でエンディアン対応を行うのでしょうか？

お使いの言語の入出力ライブラリがそういった変換機能を提供してくれないなら、自前で対応せざるを得ません

BOMあるなしにかかわらず判断できているライブラリはあるのでしょうかね・・・。

ひとまずUTF8であれば倍と並びの順はエンディアンに関係なく同じならびになるので、
BOM関係なく処理を行えると考えてよいのでしょうか。

奇数バイト目に0が多ければビッグエンディアン、偶数バイト目に0が多ければリトルエンディアンなどと判断することができなくもありません
確実ではないけれど実用上はそれで問題ないと思いますが

>>101
ソートだと後置のほうが楽。
まあどっちでも問題は起きる。

>>877
ありがとうございます、チェックルーチンをでっち上げてテストしてみます。

>>874が何を言いたいのかさっぱりわからん。
「保存データの仕様を明確にする」「LE/BEどちらでも読めるようにする」
この二つは基本だろ?
データから推測とか方向性を間違えているとしか思えん。

「LE/BEどちらでも正しく読めるようにする」ためにはデータからどちらか判断する必要があるんじゃ…？

必ずBOM付けるとかどっちかに運用で統一するとかメタ情報を
別に持たせるとか考えるのが先だろ。
完全な自動判別は不可能なのにデータから判断したいなんて
やはり方向性がおかしい。

わざわざ面倒な自動判別を実装しようとするってことは
出力側をいじれない状況だと判断すべきだろうに

882は経験不足

何故UTF-16の文章を作らなきゃいけないんだ？

>>885
そこにMSの環境があるからさ。

BOMのないUTF-16は文章と言えるのだろうか？

>>886
baka?

>>888
aho?

>>887
baka?

>>888
Windows 95が出たころはUTF-8なんかよりUTF-16の方がメジャーだっただろ。
古いソフトで設定ファイルやデータファイルがUTF-16になってるのをが時々見かける

UnicodeとUTF-16の違いは何でしょうか？

逆に聞くが、Unicodeは何を指す言葉だと思う？

885は経験不足

や、優しくしてください・・・

ウニコードとUTF-8の違いについての俺的理解

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


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

この理解でおｋ？

アメリカ人がインディアンは政治的に正しくないから作ったのがUTF-8

>895
全然違う
文字セットとエンコーディングスキームを勉強しな

問） Unicode UCS UTF を使って例文を作りなさい

このスレッドは天才チンパンジー「アイちゃん」が
Unicode訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学UCS研究所

もっとがんばりましょう

unicode内部の混乱の大きな原因は二つ
Microsoftの独自な解釈による unicode という言葉の混乱
Appleの独善的な解釈による uicode の実装の混乱

Googleに収集つけてもらうか
あそこは嫌でも世界中の文字と言語扱わなきゃいかんわけだし

収拾

>>895
UTF-8は史上最高の符号化方式
Unicodeは史上最低のコード体系

マークアップ言語からしてASCIIで決め打ちだからUTF-8が幅効かせるのは仕方がないぜよ
JIS漢字の罫線でマークアップすればスゲーシンプルに人間様にも見やすくなりそうなんだけど米製の先行規格が死ぬ事はないだろうし

いくらTronコードが(実際はどうあれ)優れていても、世界標準とはならないのだよ。

UTF-8考えた人って天才だよね

誰だろうと思って調べてみたら、
UNIXにバックドア仕込んで14年間バレなかったケン・トンプソンじゃねえか

文字に番号つけたのがうにこーど
その番号をどうやって表現するか、メモリやファイル上にどう並べるかを決めたのがUTF

…であってる？

うん

UnicodeとTronコード、なぜ差が付いたか 慢心、環境の違い

日本の規格はアメリカに潰されるんだよ
スーパー301だのなんだの突きつけて国内でしか使えない
それなのにガラパゴスだなんだと言われるのは理不尽だよな

この際、ビットマップをそのままコードにすればいい。
16x16 = 256bit = 32バイト

>>911
超漢字ってちゃんと考えて作ってんのかって感じがする。
よく知らんけど。

>>913
どうやって

龍龍
龍龍

を16*16で表すんだ？

そんなネタ漢字は表さなくてよいが、16ドットで充分なのかという話には興味がある

16ドットは、第2水準にもなるとかなり苦しい。24ドットはほしいね。

ことしは庭でアサガオ育てたんですよ。アサガオ。
みんなも小学生のこと育てたことあるでしょ。
ツルをきれいにネットにはわせるために、
いったん人手でほどいて、巻きなおしたりするんです。
そのとき思ったんです。アサガオのツルはどっち巻きだっけ？って。
ネットで調べたら、「右巻き」って書いてあるとこもあれば「左巻き」って書いてあるとこもあるんです。
ワケわかんなくて、もっとよく調べたら、なんと

すんません、途中で書き込んでしまいました。アサガオのツルの話の続きです。
なんと、「右巻き」と「左巻き」は同じ巻き方なんです！

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

ちなみにアサガオは、江戸時代は上から見るのが一般的で、したがって「左巻き」とされていました。
現代では下から見るのが一般的で、したがって「右巻き」とするらしいです。

http://www.restspace.jp/gazo/img-box/img20110116005202.gif

ANSIってのも普通に意味不明な表現な気がする

> みんなも小学生のこと育てたことあるでしょ。

ついにこのスレからも逮捕者が…

右巻きって・・・どっちだよ。

たぶん、時計回り(clockwise)

普通のネジの向き

チンコが微妙にねじれている場合、自分から見た右巻きか
相手から見た右巻きか、どちらで説明するのがよいでしょうか?

右巻きのウンコと左巻きのウンコ

utf-8のページの入力フォームの内容をメールで送る処理して困るがいい

いまどきメールもUTF-8でしょ？

ケータイ

入力内容をsjisにして出力せよと頼まれて、
ハイフンのような文字をハイフンに修正するような処理を延々追加するがいい

文字化けしてますよ

>>748
UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。
(BSD系のlibcみたいに独自内部コードのものもあるけれど)
後は状況に応じて使い分けてる。特に外部コードに対する柔軟性が大きい。

Windowsみたいにファイルシステムごとに文字コードが決まってるなんて
決め打ちは殆ど無いよ。

>>934
> Windowsみたいにファイルシステムごとに文字コードが決まってるなんて
> 決め打ちは殆ど無いよ。
MacOSXはUnixに入りますか？

>>934
>UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。
「内部」ってどこのこと？

> UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。
キミの言っているUNIXってどれとどれの事?
ほとんどと言ってるので複数あるんだよね。

>>934
そりゃ何十年前の知識だ？

何十年前でも正しくないだろう・・・

UNIXは今はほとんど内部がUTF-16、外部がUTF-8ですよ。

翻訳後

(僕が唯一知ってる)UNIX(らしきOS)は今は "ほとんど内部がUTF-16" 、外部がUTF-8ですよ。

内部と外部の定義から始めないとフレームの元になるな。

「内部」の意味のわからないヤツって何？
コンピュータのことまともに勉強したことないの？
初心者むけにやさしく教えてあげるよ。
（少しだけウソを書いてるけど、わかりやすくするため、わざとだよ）

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

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

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

ところで、漢字１文字は８ビットレジスターには入りきれない。
Windowsは１６ビットレジスターを使うことに決めてある。このしくみと相性がいいのがUTF-16。
一方Linuxは８ビットにこだわり続けてるから漢字を扱うには８ビットレジスターで２回または３回に分けて処理をおこなう。
このしくみに相性がいいのがUTF-8だな。

Linuxは「１文字は７ビット」にこだわり続けています。
Windowsは過去のしがらみを捨てて「１文字は１６ビット」としました。
これを「ニューテクノロジー」といいます。Windows NT の「NT」です。

このスレどうなっちゃうんですか？

>>942
インディアンもやさしく教えてください

>>943
> Windowsは過去のしがらみを捨てて「１文字は１６ビット」としました。
> これを「ニューテクノロジー」といいます。Windows NT の「NT」です。
さらに１文字３２ビットに進化しました。
これを「みかか」といいます。

>>944

>>950 を踏んだひとが次スレを立てて引き継がれます

>>947
残念、次スレはもう用意されています
http://hibari.2ch.net/test/read.cgi/tech/1291075205/

全然関係ないけど、VC++でBMP面の文字を1文字も落とすことなく
完全にやりとりするにはlocaleをどう設定したらいいの？

みなさんお久しぶりです。>>1です。
不本意ながら次すれは↓で行きたいと思います
http://hibari.2ch.net/test/read.cgi/tech/1291075205/l50

>>942さん
>「内部」って言うのはレジスターのことだと思うといい。
レジスタとかCPUというのはプログラムを実行するための装置で
あって、「内部」がどのプログラム(or 保存データ)を指して
いるのかの説明が無いと意味がないと思うのです。

マトモなこと言うとは>>1のくせに生意気

>UNIXは今はほとんど内部がUTF-16
確認だけど、これ嘘だよね？

内部だけにナイーブな問題だな・・・

>>953
FATをマウントするには内部でUTF-16使わんとだめだろ

だからその内部ってなんだよｗ

三重県四日市市小古曽三丁目

少なくともファイルシステムのファイル名はマルチバイト文字列のまま

Unicodeもマルチバイト文字列なんだがｗ

Unicodeだけではないということだねえ。

合成文字が存在する限り、UTF-32を使ってもマルチバイトになるなぁ。

>>958
バカ丸出し

>>961
バカ丸出し

>>959 でちょっと純粋に疑問に思ったんだけど
「Unicode」と呼ばれる部分だけで「文字列」は表現できるの？

文字コード表だけでエンコード方法なしでは、コンピュータ上に1文字足りとも表現できないだろうね。

↑
またLinuxバカが沸いたか。一生７ビット地獄で苦しんでろ。

相変わらずドザはバカだなぁ

>>966
バカ丸出し

>>957
それは「うつべ」

内部線＝ISO-2022-JP
南大阪線＝CP932
名古屋線＝UTF-8

Linuxで8bit cleanじゃない実装ってどの部分だろう？
Linux(というか大半の*nix系)はOSとしてはバイナリとして扱うから
application側でlocaleに従って適宜運用してくれというスタンスだと思うが

内部はおなか、外部はウンコ
内部に問題があるとウンチになる

腸は身体から見ると外部なんだよ

>>973
人間の体でクラインの壷ってできるかな？

「白線の内側にお下がりください」を線路に降りて死ねってことかとか言ったことあるな

白線の上に爪先立ちしてる奴もいた。

白線＝ISO-2022-JP
黄色い線＝CP932
ホームドア＝UTF-8

駅員が持ってくるタラップ=ASCII

酔っ払ったおぢさん＝EUC-JP

ISO-2022-JPって、Internet Explorerで見れないやつか?

ISO-2022-JP は IE でも見れる
EUC とか UTF-8 とか charset= が書いてないとだめ

いつの時代のIEだよ。

4ぐらいじゃね？

いや、最近IEを更新すると、
META書いてあってもISO-2022-JPが化けるようになった。

>>984
ISO-2022-JP は IE でも見れるって
話じゃなかったのか？
見れなくなったのか。

>>985
http://blogs.msdn.com/b/ie_jp/archive/2010/12/17/ms10-090.aspx

HTTPヘッダだと認識してhttp-equivで認識しないってなんだよ。
いずれにせよHTMLでのISO-2022-JPに未来はないと。