UnicodeとUTF-8の違いは？

ビッグインディアンとかなんとかかんとか

戦力の決定的差ではない

また、頭の悪そうなスレが・・・

>>1
それは魚とマグロの違いを訊ねるようなもんだ。

魚と鮪というよりは、魚と刺身の違いのような気がする。

俺もわからん。
誰か詳しく説明してよ。

>>5
UNICODE→魚
UTF-8→刺身

Unicodeは文字の集合で、UTF-8はそれに(語弊があるが)番号を振る方法の1つ。

UNICODE
- 文字集合：１種類
- 符号化方式：UTF-8, UTF-16BE, etc

小学生でもわかるように！

Unicode => クラスメート
UTF-8 => 身長順に並べー、名前の順に並べー、誕生日の順に並べー

自分はUCSとの違いがわからん

2chの絵文字の#1234とかがUTF-8なのか？

Unicode:
コードポイント: JISの句点コード
UTF-7, UTF-8, UTF-16, UTF-32: Shift_JIS, ISO-2022-JP, EUC-jp

Unicode ⊃ UTF-8

unicode => 国民
UTF-8 => 住基コード

Unicode = { 'a', 'b', ... }
UTF8 = { utf8encode('a'), utf8encode('b'), ... }

UNICODE: JIS
UTF-8: SJIS or UJIS

かな？

JISてーと、ISO-2022-JPエンコーディングのことを指すのかJIS X 0201とか08
とかを指すのかはっきりしないが、後者ならそんな感じ。

あるいは
UNICODE: DivX or XviD or WMV9
UTF-8: AVI or MKV or OGM or ASF

>>1
そもそもUTF-16やUTF-32と違って
バイトストリームのUTF-8にはエンディアン問題はない
UTF-8のBOMはエンディアン対策ではない

>>11
UnicodeとUCSは同義といってもいいのでは

UNICODEって文字セットのことなのか、
文字セット＋符号化方式たち　のことなのかどっち？

文字それぞれにも番号は振られているが、これは日本語の文字でいうと
区点コードみたいなもんだな。

UTF-8とかってのは一種の圧縮方式みたいなものだよね
前cjk漢字統合で叩かれてたのはUNICODE自体の問題？
それとも非可逆圧縮への批判？

なんという他力本願なｽﾚ・・・

ていうか、こんだけグチャグチャ言われたらわかるもんも
わからんようになるだろ、普通ｗ

>22
UnicodeがCJK漢字を統合するという
非可逆圧縮を選択したことへの批判だったと記憶している。

.NET2.0には文字コードを自動判別する機能があるかどうかどうなんだ

文字コードスレで聞けよ・・・

>>22
>UTF-8とかってのは一種の圧縮方式みたいなものだよね

全然違うから。

>>11
UnicodeはUCS-4のサブセットであり、UCS-2のスーパーセット

UNICODEには基盤になる文字集合が一つあって、
その文字コードを固定長で(そのまま)使うのがUCS、
可変長で(圧縮して)使うのがUTFだと思ってた俺。

しかし>>28によって否定されてしまった。
調べてもなぜ間違ってるのか分からん。

>>30
可変長と圧縮を混同するな。

>>31
そりゃ確かに俺らからすれば圧縮とは言えないね。
でもわざわざ可変長にする理由は第一に互換性、第二にサイズぐらいしかない気がする
とりあえず大筋では合ってたようなのでよかった。ｻﾝｸｽ

UTF-16LEを指してUnicodeと連呼しているSDKドキュメントが存在するんだが、
あいつらの傲慢さは何とかならんのか？

UTFのUとは何か

さいたまてれびがうつらないのですが・・・

なぁ、ちょっとおしえてくんねーか？
なんでutf8の「ももんが」って文字列を
PerlのJCodeでutf8に変換しようとすると文字化けしちゃうんだ？

ももんが！！

>>36
utf8からutf8だと、変換してないじゃないか。

Unicode： Unicode Consociumの制定した文字集合。(U+0 - U+1FFFFF)
UTF-8/16/32： Unicode Transformation Format。Unicodeの符号化方式。
　UTF-8： 外字が無いため4Byte長まで。
　UTF-16： UCS-2＋サロゲートペア＋バイナリ符号化。

ISO/IEC 10646： 国際文字集合規格（群、面、区、点）。制定前にUnicodeが出て来たためそのコンパチに。Unicodeの文字はこのうち0群16面まで。
UCS-4： ISO規格の31bit符号集合。規格化文字集合＋外字。
UCS-2： ISO規格の16bit符号集合。基本多言語面のみ。（例：U+1234）
UTF-8/16/32： UCS Transformation Format。UCSのバイナリ符号化方式。（例：0x12 0x34）
　UTF-8： Unicodeの方と違い6Byte長まであり。

メモ帳でテキストを保存するときに
UnicodeやUTF-8を指定できるが、
Unicodeで保存する
としたときは
UTF-8で保存したのかUTF-16で保存したのか
わたしたちにはわからなくないか？

コンソールのfileコマンドでわかるだろ！(：D)|￣|_

>>40
Microsoft Windows では "Unicode" といえば UTF-16 のリトルエンディアンという暗黙の了解になっている。

>>33
csUnicodeっていうISO-10646-UCS-2のIANA別名があって、
こいつはUTF-16コンパチだから、あながち間違いとはいえない。

Visual Studio.NETのSystem.IOでテキストをつくったらとくにコード指定なしのときはUTFいくつなんだ？

windowsの標準

UTF-8
MSDNに書いてある。

ISO-2022でいいじゃんね

VB.NETでも結局はBASP21を使わないと文字コード半別できんのか？

mlangつかやいいじゃん

文字コードのことがイマイチよくわからん・・・・
頭こんがらがり

文字コードもOSI参照モデルみたいな階層構造の概念が必要だと思うんだよな
↓みたいな感じで

表示字形（グリフ、フォント）
文字入力（物理デバイス、IME）
符号化方式
文字集合
自然言語

とりあえず、M$はUTF-16をUnicodeと呼ぶのを自重すべきだな。
まるでUTF-16だけがUnicodeとしたいようだ。
SJIS(MS漢字コード)を日本語テキストの標準にしたいかのように。

自然言語ってのは普段使ってる言葉な
そこで使われてる文字を集めたのが文字集合ってヤツ

英語だとラテン文字a-z,A-Zと数字、記号なんかが文字集合になるわけ
日本語だと異体字なんかの問題があって集合を作るのが難しいんだけど
（土吉／士吉とか、はしご高／くち高みたいな）
とりあえず作って使われてるのがJIS X 0208文字集合ってヤツ
いわゆるJIS第1水準、第2水準漢字ね

他の国でも独自に文字集合を作ってて
それらをまとめてひとつの大きな文字集合に
しちゃおうってのがUnicodeの考え方なの

ここでいうUnicodeはUCS(Universal Character Set)と
同じと思ってもらっていい

その文字集合を実際にコンピュータ上のゼロイチで
対応させる方法のことを符号化方式っていうの

JIS X 0208文字集合を符号化する主な方法として
EUC-JP、ShiftJIS、ISO-2022-JP(JIS)
っていう３つがあって文字化けとかの問題が出てくるんだけどね

ASCIIなんかだと文字集合と符号化方式が明確に区別されてなくて
規格として「この文字はこのゼロイチの組合せ」ってのが決められてたりして
そこらへんが文字集合と符号化方式を混乱する一因ではあるんだけど

UTF-8ってのはUCSを符号化する方法のひとつっていうだけ
それ以上でもそれ以下でもない

じゃあ、何が混乱の元かっていうと
Unicodeって言葉がUCS（文字集合）だけを指す場合と
符号化方式まで含めて使われる場合があるのだな
区別が付いてる人はいいんだけど、区別が付いてない人が
書いたり読んだりしてるとエスパー助けて状態にｗ

UCSという規格の存在を知らず、
UCSという言葉を単にUCS-2やUCS-4などといった符号化形式の
総称としか思っていない奴いるだろ。

なるへそ。
そういうことか。

Unicodeが単に世界中の文字を集めたもので、その1文字1文字にゼロとイチ
の組み合わせ対応させたものが、UTF-8と。

なんかちょっとわかったよ。

ASP.NETのWebconfigファイルはUTF-8なんだからできればなにもかもUTF-8で統一してもらいたいんだが。
アラビア語とかを考えてUTF-16とかにする必要があるんだろうか

Unicodeが16ビット固定長だった頃に書かれたソフトウェアを使うためということが
UTF-16の最大の存在理由だと思う。

個人的には大半の仮名漢字が2オクテットで収まるUTF-16はそんなに嫌いでない。
ASCIIの文字が2バイトになることと、プログラムで扱うときに
サロゲートペアを考慮しなければならないこと、は悩ましいけど。

どうせ互換性なくなるならASCIIの制御文字から設計し直せばいいのにな

このスレは文字コードスレの内容がサッパリわからない
アフォの俺には非常に助かる

なるほど。すごく良く分かった。
エロい人に感謝。

それじゃぁ、このスレは目的を果たしたということで埋め？

日本で使うコードポイントはどの辺でしょうか？
http://www.ssec.wisc.edu/~tomw/java/unicode.html

ブラウザの実装も大変みたいだね
http://openmya.hacker.jp/hasegawa/public/20061209/momiji.html

>>39
UTFって、２種類あるんだ。Windowsのはどっちなんだろ？
というかそもそも、UCS-?とUTF-?の違いが良く分からんが。

Basic LatinがASCIIの範囲。
CJKなんたらと付くところが漢字関連。
あとHiragana、Katakanaは当然だな。
Halfwidth and Fullwidth Formsが半角カタカナや全角アルファベット。

漏れがあるかも知れないがだいたいこんなとこだろう。

将来的にはHigh/Low Surrogatesに入る文字もあるのかな。(もう入ってる?)

UCS-2⊂UCS-4⊂世界の文字
UTF-8∈( UCS-2→バイト列(1〜4?バイト) )
UTF-16∈( (UCS-2→バイト列(2バイト) ∩ (UCS-4-UCS-2→バイト列(4バイト)) )

こうかな…？

UCSは集合でUTFは関数
集合の元に関数を適用するとゼロイチが出てくる

>>65
国を意識しないで使えるのがUnicodeのメリットで
全ての国で全てのコードポイントが使える

そもそも日本語だけを使いたいのであれば
Unicodeを使う意味がない
理想論だけど

で、実践的に、ネットからダウンロードしたのをUTF-8で保存するとして
ネットのドキュメントのいろいろな文字コードを知るにはどうするんだ？

(1)ソース表示→charset=???の部分で判断
(2)いろんなエンコードで開いてみて読めたのが正解

>>71
>Unicodeを使う意味がない

２バイトコードの問題から開放されるだけでもすごく意味があるぞ。

>>67
Unicodeコンソーシアムが作った文字集合がUnicode。
ISO 10646で定義された文字集合がUCS。
両者は、互換になるように働きかけあっているので、今のところ同じ文字集合と見なして問題ない。

一時期はUnicodeを符号化するのがUTF-?、UCSを符号化するのがUCS-?だったと俺は思うが、
今はISO 10646にUTF-8/16も収録されているらしい。
UTF-8/16の正式名称はUnicodeとUTFで違うが、実際の符号化の方法は同じで、
基の文字集合も上に書いたとおり同じだからどちらのUTF-8/16も実用上基本的に違いはない。

UCS-4は、32ビット固定長の内31ビット使用し、UCSの全ての文字を符号化できる。
UCS-2は、16ビット固定長（16ビット使用）で、UCSのうち、BMP（基本多言語面）だけしか符号化できない。
UTF-32は、32ビット固定長の内21ビット使用し、Unicodeの全ての文字を符号化できる。
UTF-16は、16ビット/32ビット（サロゲートペア）の可変長で、Unicodeの全ての文字を符号化できる。
UnicodeのUTF-8は、8ビット単位、1-4オクテットの可変長で、Unicodeの全ての文字を符号化できる。
UCSのUTF-8は、8ビット単位、1-6オクテットの可変長で、UCSの全ての文字を符号化できる。

Unicodeは、UTF-16で全ての文字を符号化できることを念頭においているが、
UCSは、UCS-4で全ての文字を符号化できることを念頭においている。

>>74
Unicodeでも多バイト問題は付いて回るし
EUC-JPとかISO-2022-JPでいいんじゃね？

>>69
これくらいすっきりさせろ
UCS-4 = UCSのUTF-8
UTF-32 = UTF-16 = UnicodeのUTF-8
UCS-2 ⊆ UTF-32 ⊆ UCS-4
（そもそもUnicode ⊆ UCS）

ISO-2022-JPはステートフルなので扱うのが大変。
UTF-8はEUC-JPより多くの文字が扱える。
Shift_JISはYENとかで困るから除外。
XMLのデフォルトエンコーディングはUTF-8。

JISX0213（ニアリイコールVistaの文字セット）でサロゲートペアって
ハマりそうだよな。

string s="○";
assert( s.length==1 );

これが成り立たない場合があるっていうのも詐欺みたいな。

1区当たり94点しか使わないASCII絶対主義が狂ってると思う
コードポイントの5/7が使われないのはもったいなすぎ

>>76
なるほど・・・だいぶ間違ってたなぁ。こうなるのかな？
BMP(16bit)⊂Unicode(21bit)⊂UCS(31bit)⊂世界の文字
UCS-4∈( UCS→(32bit) )
UCS-2∈( BMP→(16bit) )
(UCS)UTF-8∈( UCS→(8〜48bit) )
(Unicode)UTF-8∈( Unicode→(8〜32bit) )
UTF-16∈( BMP→(16bit) ∩ Unicode-BMP→(32bit) )
UTF-32∈( Unicode→(32bit) )

>>78
俺はずっと文字集合とエンコーディングがごっちゃになってたから
あんまり省略すると不安だったもんで

>>80
「が」とかなら判るけど、○も文字的に２文字になるケースってあるの？
サロゲートペアだから2だとかでは、バイト長だから4という思想から
変わってないような。文字としてなら1以外ありえないと思うので、
そのassertが不成立ならstringクラスのバグ（か、lengthのバグ仕様）なんでは？

任意の文字って意味じゃね＞"○"

あ゛、なるほど。でも任意の文字っていっても実装依存で
なるわけじゃなくて、そうなってもおかしくない文字（合字とか）で
なるだけじゃないの？言語的な文字数ではなくて内部的に確保した
記憶スロットの数を返すようなlengthはいくらなんでもバグだろう。

>>83
いや、サロゲートペアだから２になるんだわ。
とりあえず.NETはそうなる。

http://msdn2.microsoft.com/ja-jp/library/system.string.length(VS.80).aspx
> Length プロパティは、このインスタンス内の Char オブジェクトの数を返します。Unicode 文字の数ではありません。

Javaもそうなるみたいだけど。

Java
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/String.html#length()
> この文字列の長さを返します。長さは文字列内の 16 ビット Unicode 文字の数に等しくなります。

JavaScriptも多分？

>>86
げーっ、そうなんだ。
「16ビットUnicode文字」の数なんて何の意味もないのにな。
「言語的な文字」の数かどうかだけが問題で、それ以外は
バイト数を返すのと同じこと（＝同じ問題を抱える）なのに。

しかし、実際サロゲートペアの
文字なんかほとんど使われないわけで。

それなのにそれを考慮して処理速度を大幅に落とす方が俺は困る。

Javaは仕様としてサロゲートペアを
そもそもサポートしないと決められてるはず。

>>89
最近のJavaはちょっとサポートしている。
String.codePointCount() とか、Character.codePoint*() とか。

>>87
プログラム組む人は、バイト数が欲しい
（書面の）文を書く人は、文字数が欲しい


strcatとかの標準関数が全滅するUTF-16なんて誰が考えたんだろな？
しかも、MSは標準にするし…

意味的にはもちろん文字数を返すのが理想なんだけど・・・
そもそもJavaなんて、ｓtringクラス作った時はサロゲートペアなんて無い時代じゃないの

>>68
有り難う御座います、結構飛びますね
>>71
ゲームで使うライブラリが使うコードポイントを指定して
テクスチャに書くので決める必要があるからです
海外のフォントが使えなきゃ線画ができませんし

>>91
バイト数を気にしてた頃はJIS X 0201カナも普通に使われてたから
SJISなんつー中途半端なモンが重宝されてたんだよな

>>87
.NETの場合、文字数はSystem.Globalization.StringInfo.LengthInTextElementで得られる。
ほかにもStringInfoには、サロゲートペアを考慮して文字単位で操作するメソッドがいくつかある。

>>91
C89の時点で既にwchar_tはあった。
wcscpyなどの関数が入ったのはC95だった気がするが。

そのwchar_tは、今のWindowsだとUTF-16だが、
そもそもwchar_tことC/C++のワイド文字は固定長で処理することを志向していたはずで、
本来のwchar_tの意義からすればUTF-16は良くない罠。

もしもUnicodeが初めから32ビットになっていれば、と思う。

やべえええ
話についていけない
というか、文字コードの変換は出来るけど　実際の詳しい部分知らない俺はヘタレ・・・

16bitで足りないのはすぐに判ったろうけど、似た文字はまとめちゃえば入るだろと思ったんだろな
でも、それじゃ納得しない人が出てくるのは当然。

24bitあれば足りたろうから24bitで定義しておけば最善だったかもな

それにしても \ の扱いが醜い

7bitで足りてた人間が考え始めたコトだからｗ

JIS X 0201のGRはISO646ではあるけどASCIIではないからね
バイナリ的に区別付かないからフォント変えれば同じだけど

ASCIIにスラッシュとバックスラッシュが採用されたのは
当時のプログラム言語で使われてた論理記号の∧と∨を表すためらしい

歴史的な経緯はこのページが参考になる
ttp://www.horagai.com/www/moji/code4.htm

んじゃ、文字数とかバイト数とかのお話の説明なぞ

UTF-16っていうので16bitで全部の文字を表そうと思ってたのね
でも実際に作り始めたら16bitじゃ全然足りなかったから
その分は16bitをふたつ使って32bitで表しますよっていうコトにしたの
それがサロゲートペアって呼ばれてるモノね（ふたつ組だからペア）

そんなわけで、UTF-16は基本的に16bitで一文字なんだけど
例外的にサロゲートペアだけ32bitで一文字っていう
ヘンテコリンな規格になっちゃったわけ

サロゲートペアの処理がちゃんとされてないプログラムだと
16bitなら一文字、32bitなら二文字っていう風に
機械的に文字数を判断しちゃって困るねっていうこと

言ってみればサロゲートペア非対応のプログラムでサロゲートペアを含む文字列を扱おうということは、
マルチバイト文字列非対応のプログラムでマルチバイト文字列を扱おうとするのと同じこと。
まあShift_JISのような駄目文字問題が生まれないのはましだけど。

足りない領域に文字を突っ込むという点では
JIS X 0201のカタカナ集合に通じるモノがあるかも
（いわゆる半角カナのコトね）

自然な感覚だと濁点・半濁点が付いてるのも一文字だし
付いてなくても同様に一文字だと思うんだけど、
文字入れる場所がないから濁点・半濁点付き文字は
例外的に8bitふたつで表現してねっていう

「こんにちは」と「こんばんは」
一般的な感覚としては両方とも五文字だけど
8bitカタカナの世界では
「ｺﾝﾆﾁﾊ」は五文字で「ｺﾝﾊﾞﾝﾊ」は六文字になる

UTF-16で
1文字16bitだとして1文字32bitのものもあるってことは判った
流石に混在はしないの？

>>103
D800-DB7FとDB80-DBFFが上位サロゲート、DC00-DFFFが下位サロゲートの領域になっていて、
任意のUTF-16 1バイト（= 2オクテット）を取り出しても、
それがサロゲートでないか、上位サロゲートか、下位サロゲートかは区別が付く。

駄目文字の問題が起こらないという点において、ASCIIとの対比で言えばShift_JISよりもEUC-JPっぽいという感じ。
EUCは、あるコードがマルチバイトのどこになるかの区別が付かなかった気がするが。

>>104
解説ｻﾝｸｽ
なるほど　なんかUTF-16が判ってきた
でもぶっちゃけ存在は知ってるけど使ったことがない俺がいる

文字コードなんて本来はユーザが意識するようなものじゃないからなぁ
ユーザが意識して扱わないと問題が起きる設計なんてのは
IT業界じゃなきゃ欠陥商品としてリコール対象だろｗ

つまりUTF-16だとサロゲートペアで表す対象になる文字の中で、
俺が有名そうだと思うのは、吉野家の「土吉」（上部が土になっている）U+20BB7 𠮷。
メイリオなんかだとグリフを持っているので表示できる。

DOMStringの長さはUTF-16での符号単位数ってことになってるんだよな。
これ決めた奴、死ぬべきだと思うわ。

>>108
W3CでDOMを規格化するときには、もうJavaScriptもJavaも16bit単位ベー
スの文字列処理になってしまっていたので、仕方なくそれらに合わせた
んだと記憶してます。

7bit文字の場合
0xxx xxxx
8-11bit
110x xxxx 10xx xxxx
11-16bit
1110 xxxx 10xx xxxx 10xx xxxx

unicodeの部分がxxxx

1バイトだけ見た場合、

0xxx xxxxならそのバイトだけで1文字
1xxx xxxxなら
-- 10xx xxxxなら多バイト文字の2バイト目以降(先頭は遡って11xxなバイト)
-- 11xx xxxxなら多バイト文字の先頭バイト
---- 110x xxxxなら2バイト文字の先頭バイト
---- 111x xxxxなら3バイト文字の先頭バイト

と判別できるわけだな。

>>110-111はUTF-8の場合な

>>112
なにが言いたいのかわからんが、
UTF-8はstr系の標準関数が、ほぼそのまま使えるから大好きだぞ。
ASCIIの前半文字との比較だって、何の躊躇もいらない。
str系に限らず、UTF-8のシステムならfopen等までそのままってのはでかい。
w系使えばいいってのは何かの冗談にしか聞こえない。
ま、UTF-16は、何も考えず0x00を織り込んだのが、糞仕様ってことだ。

>>100
根本的に認識が間違ってる。
Unicodeの文字表現は元々複数のcode pointを組合わせた可変長
UTF-16でサロゲートが無くても2 byte毎に分割してはだめだし、1文字の長さは2
byte以上の可変長としか言えない。
文字単位に処理したかったらcode pointではなく、grapheme clusterが処理単位
code pointは文字の構成要素であって文字ではない。

そこでISO/IEC 10646の実装水準1ですよ(もうすぐ廃止されるけど)

>>113
世の主流言語がPascalとかBasicだったら今頃はUTF-16マンセーの時代だったのかもな。

なんでPascalやBasicだったらUTF 16マンセーなの？

というか、現代は既にUTF16マンセーだろ？

どうだろうね。 Unicodeだとその言語がどの言葉か判らんから翻訳ソフトなんて困ってしまうんじゃないの？
16bitに無理にしたかった弊害がどこまでも付いて回る
今なら24bitなり32bitなりのコードで何の問題もなかった。
ほんの５年待てばよかったのにね。

何言ってるんだろね。こいつは。

>どうだろうね。 Unicodeだとその言語がどの言葉か判らんから翻訳ソフトなんて困ってしまうんじゃないの？
文字コードから言語を選択する翻訳ソフトってアホだろ。
自動判定するとしても、使われている文字の種別で判定するだろ。

>16bitに無理にしたかった弊害がどこまでも付いて回る
一文目と文章が繋がってなく唐突で、
何が言いたいのか、根拠は何か、さっぱりわからん。

>今なら24bitなり32bitなりのコードで何の問題もなかった。
24bitは別の問題があるし。

>ほんの５年待てばよかったのにね。
「何を」「どの時点から」5年待てばよかったのかさっぱりわからんな。

>使われている文字の種別で判定するだろ

ってどうやるの？

>>119
>>99 の話じゃない？

バベル倒壊
・・・
　もう一つ、問題なのは、言語指定の仕組を文字コードレベルから排除してしまったことです。
ISO 2022や DIS 10646 1.0では、コードを見るだけで、それがどこの国の文字かを識別することができます。
それはアルファベットの「a」が、英語領域、フランス語領域、ドイツ語領域等々に重複して登録してあるから
なのですが、そんなことをしていたら16bit単一平面に全世界の文字を詰めこむことはできません。
言語指定などは必要なく、それよりも16bit単一平面におさめる方がメリットがある、というのが当時の
Unicodeの考え方だったのです。

Unicodeって多言語を扱う一部の人のためのものではないの？
自国語だけで足りてる人にも使わせようとしてるのはなぜ？

>>120
asciiしか使われて無いなら英語とか。
文字コード判別より簡単だろ。

>>122
アプリの多言語化は一部の人だけの問題じゃないだろ。

>>123
ウニコードの話してるんだろ？　なんでasciiの話が出るんだ？
EUC-JP なら日本語と判るのに
ウニコードだと基本ラテンが続いてるだけじゃどこの言葉か判らんだろ？

＞　アプリの多言語化は一部の人だけの問題じゃないだろ。

そう。一部の人だけの問題じゃないのに、一部、
特にＭ＄とシリコンバレーが利益率を上げる為に必要と突っ走ったのが

何語かを考えないで全て等しく文字として扱うための仕組みがUnicodeだろ
どこの国の文字かはコードポイントで判断すればいいだけ

そのコードポイントでどう判断するんだ？

JIS X 0208でもＡとΑとАはコードポイントで何文字か区別つくっしょ

>>124
>ウニコードの話してるんだろ？　なんでasciiの話が出るんだ？
Unicodeの話だろ？
ascii範囲だけが多く使われていたらだよ。わかれよ。
Πが使われていたらロシアとかだよ。わかれよ。

ascii　ってのは　基本ラテン文字の事だろ？
http://code.cside.com/3rdpage/jp/utf-8/Bacic_Latin.html

だったら、どうしてコレだけで英語だとわかるんだ？

完全に分かる分けないだろ。
後は単語で判別だわな。

>>117
Pascal string と C string。

>>132
Pascal stringって、文字列の先頭に文字の長さが格納されてるってもんじゃないの？

なんでPascal stringだとUTF-16マンセーになるか、全然説明になってないよ。

標準関数自体が今となっては問題の種な訳だが。

strsafe.h で追加された文字列操作関数について
http://ir9.jp/prog/ayu/strsafe.htm

kono bunshou ha nihon-go desu.

>>124
EUC-JPの半角英数だから日本語と決めつける方がどうかしてる
コメントに日本語が使われてるC言語のソースの単語は全部日本語か?
そもそもISO-8859-1の時点ですでに欧州の文字統一しまくりなわけだが?

>>134
バッファオーバーフローは、古い関数だからおこるの？ 違うだろ。

なんであの会社は作り直しを奨励するようなことをやりたがるの？
仕事を増やすためじゃないの？

このスレと文字コード総合スレの違いは?

>>137
古い関数だと間違いやすく、新しい関数だと間違えづらいだろ？あってるだろ。

>なんであの会社は作り直しを奨励するようなことをやりたがるの？
古いC関数は使わないってのはもう常識なのに…
お前何十年と情報から隔絶されてたんだ…

>仕事を増やすためじゃないの？
逆逆。古い関数使うお前のようなバカの尻拭い仕事を減らすため。

>>139
>古い関数だと間違いやすく、新しい関数だと間違えづらいだろ？あってるだろ。
何の話をしてるのかね？ 関数名を間違えるのかね？
「間違いが起こりやすく」だろ？ 日本語でおｋ。

>古いC関数は使わないってのはもう常識なのに…
常識なんつーのは、所詮、てめーの知識でしかねーんだよ。
軽々しく常識なんて単語使うな。
お前は、動いているプログラムを変更するが大好きなのか？
それこそ、お前のようなバカの尻拭い仕事をさせられるぜ。

>>133
nullターミネートじゃないからUTF-16で間に0x00が入っててもそのまんま
扱えるってことじゃないの？

>>140
バカかお前。動いているプログラムを変更しろなんてダレが言った？


これから間違えにくい関数を用意したら、
>なんであの会社は作り直しを奨励するようなことをやりたがるの？
>仕事を増やすためじゃないの？
こんなバカなこと言うアホは死んでね^^


>何の話をしてるのかね？ 関数名を間違えるのかね？
はぁ？お前の脳内では「関数名を間違える」としか補完できないの?
「使い方を間違える」とかあるだろ。ホントバカだねお前ｗ


「「使い方を間違える」はおかしい」とか言い出したらバカ確定なw
バッファをオーバーするような「使い方は」「おかしい」から。

すいません、もうちょっと高度な話題でケンカしてもらえますか

ハンドアセンブル最強

理由を言わないといけないわけだが・・・？最強だけ言われても納得するのはどんだけ・・・・

諦めろ。　叫んだ方の勝ちだ　

>>142
>バカかお前。動いているプログラムを変更しろなんてダレが言った？
…作り直しを推奨する…。作り直し。新規の物に作り直しとは言わない。

>これから間違えにくい関数を用意したら、
用意しても全く構わないが、
#define等で旧式と同じようにも使えるようにするもんだろ。
それをしないから文句言ってんだ。

>「使い方を間違える」とかあるだろ。
予想も出来なかったわ。ま「使い方を間違える」なんて考える馬鹿が、あのs付きを有り難がるわけだ。
しかも、デフォルト設定。
M$も、オーバーフローも考慮できない馬鹿は、放置すりゃいいのに。

放置して叩かれるのはWindowsですから。

>>147
http://msdn2.microsoft.com/ja-jp/library/ms175759(VS.80).aspx
Visual C++ 2005の場合では、常に使える訳ではないが、
従来の関数がそのままセキュリティ強化版の関数呼出になるようにできる
_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMESというマクロがある。

もっとも、C++限定なので、>>134のページと同じく、
そもそもC++ならクラスでカプセル化しろよということになるのだが。

>>124
>EUC-JP なら日本語と判るのに
確かにEUC-JPなら日本語だけど、その前に
あるバイナリ列がEUC-JPであるとどうやって判断するんだ？
ISO-8859やEUCであることはわかっても
どこの国のかは単純には判断できないだろ

>>129は世界には言語が５つくらいしかないとでも思ってんのか？
例えば、英語とインドネシア語はどうやって判別するんだ？ｗ　統計的手法とか言うなよ。お前の発言と矛盾するからな。
ウィキペディアにあるような、英文の中に日本語の単語が引用されてるテキストの扱いはどうなるの？

っ地球上の3人に1人はちうごく人

インドも恐ろしい。下手すると、世界の現行文字の３分の１くらいはインド１国で占めかねない。

お前ら言語タグ使えよ。

> ウィキペディアにあるような、英文の中に日本語の単語が引用されてるテキストの扱いはどうなるの？
それはEUC-JPでも全く同じように問題なわけで
文字コードで言語判別しようとするのがそもそもの間違い

「日本語をアルファベットで表記する」なんていうこともあるし、
言語とスクリプト(日本語では「用字」だっけ?)も分けて考えないといかん。

yorosikuと夜露死苦と紐育と上海はそれぞれ何人の何語の何文字なのかというやつだな。

This site is Japanese only.
と英語で書いてある日本語サイトとはこれいかに

Ｓｏｒｒｙ　Ｊａｐａｎｅｓｅ　ｏｎｌｙとか

哀れな日本人のみ利用可能

しかも全角

たまには縦倍角・横倍角・４倍角も思い出してあげて

フォントの拡大縮小が自由にできなかった時代の遺物ですね
テラナツカシス

半角全角もあぼーんしてくれ

半角カナは組み込みでまだ使ってます
Unicode？なにそれ？

炊飯器で使われるようになったらUnicode勝利宣言してもいいかな

そこに全角文字、マルチバイト文字はあるのか？

笑園漫畫大王

This Home Page is Link Free !

This Home Page is Link GPL!

This Home Page is Open Source.

「私のために争わないで」文字コードのUTF8さん、自殺 : bogusnews
http://bogusne.ws/article/41580267.html

ｸｿﾜﾛﾀ

ネタにマジレスするのもアレだがUTF8とCP932の年齢がおかしくないか?

アスキーとアンジーの違いは？

>>173
JIS と JIS X 0201 の違いを聞いてるようなもんかな

？

UTF-8
と
UTF8
の
どっちが正しい？

前者

どっちも正しい

>>174
JISじゃなくてJSAだろ。

>>176
MIME charset名としては前者

ISO/IEC 10646の表記も、Unicode Bookの表記も前者。

>>177-181
沢山回答頂きありがとうございます
MySQLを使っていてデフォルトを
Latin1からUTF8に変えたんですが
こいつはUTF-8じゃなくてUTF8と
書かないといけないみたいで
なんで2種類あるのかなぁと

ハイフンはトークンの区切りになるからでしょ。

シフトジスは shift-jis
だけど
ジスは iso-2022-jp

こういったので迷うのは俺だけ？

>>184
ｋｗｓｋ

http://e-words.jp/w/Shift20JISE382B3E383BCE38389.html
http://e-words.jp/w/ISO-2022-JP.html

.NETのエンコードの話なんだけど、ジスコードの規格っていろいろあって、
iso-2022-jp 日本語 (JIS)
csISO2022JP 日本語 (JIS 1 バイト カタカナ可)
iso-2022-jp 日本語 (JIS 1 バイト カタカナ可 - SO/SI)
迷うよな

いわゆるシフトJISだってShift_JIS, Shift_JIS-2004, CP932 (Windows-31J)と種類豊富
大体CP932以外使わないけどな

WEBとかエンコードの柵が強いからいやだなぁ・・・
もう慣れたけど、うっかりで文字が化けたりする敏感なの何とかしてほしいな

Unicode以外使ったら罰金。

>>189
じゃぁ、まずシフトJISで書き込みを行った >>189 が率先して
UNICODEコンソーシアムに罰金を払ってください。

俺専用コード

ロリコードとかだめっすか？

>>191
ぷにコード(実在する)でも使ってなさい

その括弧がきは馬鹿っぽく見える

そういう演出は必要さ。　首相の「ザンキにたえない」発言と同じ。

「ザンキにたえない」ってどういう意味なん？

http://www.asahi.com/politics/update/0528/TKY200705280458.html
＞首相周辺は「こういう結果に至ったことへの自らの責任を、この言葉に込めた」と解説する。

スクリューパイルドライバーの吸い込みを防げないことだろう

文字コードが乱用されているのはプログラマーとしてはやりづらい。
いっそのことすべてUnicodeにしてくれれば手間が省けるのにorz

Unicode自体が何種類もある事態

すべてUnicodeにしようってのは
そばの出前も会社の通勤も全てトラックを使おう
ってのと同じくらいナンセンス

そのUnicodeだって、結合文字列・合成済み文字とか、文字列の向きとか
UTF-16のサロゲートペアとか、考え込むネタは尽きないわけで

字体の扱いもおかしい
利用は辞退させて頂く

審議中（AA略

16bitじゃ絶対無理って最初からわかってたのに、
16bitに無理やり収めようなんて考えて自爆した欧米人は馬鹿すぎ

8bitで十分だったから16bitにするだけでもビビってたのさ

かれこれ20年になるのか

アメリカに限れば、7bitででも足りてたんだよね？

5bitでも足りるわな
ttp://www.trans-usa.com/mike/BaudCode.htm

PCのインターフェースもパラレルからシリアルになってきたし、
文字コードも可変長なシリアルに変更しようぜ

それとこれとは訳が違う。
しかも例えが逆だろう。

>>209
つUTF-8

>>201
Unicode「と」他のあらゆるコードを全部相手にするよりはマシ

>>192
残念ながらPunycodeはピュニコードと音訳するのが近い。

うにこーど
ゆにこーど

どっちが正しいですか？

うにっくすとおなじくうにこーどがただしいですよ。

ttp://www.uny.co.jp/
ここも「ウニー」だしな

日本ウニシス

ウではじまるとウインドーズみたいで嫌だな

シャーペンの替え芯売ってるあのメーカってウニと読むのか

いいえ、三菱鉛筆です。

ウマ・サーマン？
ユマ・サーマン？

ウマ・サーマン！

Unimog
http://ja.wikipedia.org/wiki/%E3%82%A6%E3%83%8B%E3%83%A2%E3%82%B0

ウナイテッド・ステイツ・オブ・アメリカ

知り合いのヌーヨーカー(w)は「ヤイェヨ」は変わらないけど「ユ」は「ウ」になるって言ってた。

Nuyork ？

ewの発音は、元来「ユー」なんだけど、「ウー」に化けているのでnewが「ヌー」になる。

４へぇ〜

最初 knew を /nu:/ と発音されたときはさっぱり理解できんかったなあ。

TRONコードに統一しようぜ

TRONコードは(少なくとも現在の実装は)日本のことしか考えてません

>>230
http://pc11.2ch.net/test/read.cgi/os/1028526865/7-13

TRONコードに収録されてる文字のグリフはTRON文字収録センターで公開されてるけど
同定のための情報は提供されてないな。それは超漢字という製品に付けて売ってるから
公開できないだろうし

エスペラントでOK

Mi estas tre ĝoja konatiĝi kun vi.

>>235
これエスペラントなの？
最初スペイン語かと思った。

Mi estasでI amなのは覚えてる。
この辺の語彙はラテン語系から採用してるんだよな。

あ、やっぱりそうなんだ。

だから印欧語族の連中には割と覚えやすいんだよ
日本語とか圧倒的に不利
ある意味Unicodeと一緒だな

利用者が単語登録してもいいところとかね。

ところでかんじんのUnicodeとUTF-8の違いがまだ
のべられてないよね

それは1桁で終わったんじゃないのか

インディアン嘘ツカナイ

馬鹿を見ることになるぞ

約四ヶ月ぶりのレスがそんなでは、目が点になっちゃうだろ。　もうすこしなんかかけ。

けっきょくいまだにスレタイトルの疑問をだれもがなｔっとくできるほどうまく解説した人があらわれない

>>246
>8で充分だろ。Unicodeの符号化方式の一つがUTF-8。

Unicode: 人々
UTF-8: 名前一覧

>>247
いや、Unicodeは単なる文字集合（レパートリ）ではなく、
あくまでも符号化文字集合だろ。

Coded Character Set: Unicode
Character Encoding Form: UTF-8, UTF-16, UTF-32
Character Encoding Scheme:
UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE

どうして
UNICODE って UNI - CODE なはずなのに
何種類もあるのはなぜ？

>>251
どうして>251の日本語がおかしいのはなぜ?

雲丹には糞という意味もあるんだぜ

バージョン違いを除けば、文字集合は常に唯一。
符号化の方法が色々あるだけ。

ハングル……いやなんでもない

UCS-2 ?

UNICODE

UNCODEI

hjfjgfjgj




ktykytk




hjkghkkg




j,jhjhklkgh




urtutrtu



jjkfjfg

unicodeとutf-8の違いは
50音と平仮名の違いと一緒だろ

utf-16が片仮名？

片仮名でもローマ字でもなんでもいいよ
一つ一つマッピングする意味は無いと思うが

いや一緒とは思えないから

50音は平仮名でも片仮名でもないだろ。
読み方を定義したのが50音で、それに割り当てるのが平仮名であったり
片仮名なんだから。

世界中の文字を表わせる Unicodeってのを定義しました。

じゃあそれを2オクテットで表現しよう→UCS-2

でも他の文字コードと互換性ないしいちいち全部に2オクテット使うのは不便だから
よく使う文字を1オクテットに対応させて使わないのは2,3,4オクテットに分けて符号化しよう。
これでASCIIコードと互換性できたしよく使う文字は少ないオクテットで表現できる。→UTF-8

でもUnicodeって2オクテットじゃ表現しきれなくなってます。
じゃあ4オクテット(実際は31ビット）使おう。→UCS-4

4オクテットじゃ長すぎるからよく使う文字を以下略で分けて16ビット符号化しよう。
UCS-2の範囲はそのまま表わそう、不足しているUCS-4の部分はあんまり使わないし符号2つを組み合わせて32ビットで表わそう。
内部がややこしくなったけどUnicode全部表現できるからいいよね。→UTF-16

っていう感じの認識しかないな俺は。

どっちかというとこんな感じ。

32ビット化してUCS-4/UTF-32作った。
けど、今までのUCS-2なシステムどうしよう？
じゃあマルチバイトっぽいことしよう→UTF-16

16ビットで世界の文字を網羅出来るなんてマジで思っていたのかね

１０年も昔の環境じゃできるだけリソース消費を抑えたいってのはわかるし
３オクテットじゃ扱いにくいし４じゃ多すぎるしで話がまとまらなかったんだろうな。

単純に中国で既にコード化されてる分で漢字の量はOKとか考えてたんじゃないか

そもそもそのやり方じゃ足りねえと文句付けたのは中国

増やす気まんまんだったわけだな

UCS-2とUTF-16の違いがわからない

サロゲートペアでの拡張があるのがUTF-16、それがなくて16ビットだけなのがUCS-2

WindowsXPのメモ帳で保存しようとすると
アンジーがデフォルトになってるんだけどシフトジスってのがみあたらないんだが。でも日本語ドキュメントがうまく保存される。
つまり、
アンジー = シフトジス
だと思う。

メモ帳の選択肢のANSIというのは、
現在使用中の言語のANSIコードページの文字コードということ。
日本語の場合、それはコードページ932、つまりMicrosoftのShift_JIS。

言語の設定を変えれば、当然ANSIで保存するときの文字コードも変化する。

>>274 そういう意味だったのか !

>>272
では、Windowsの内部コードというか、hogehogeW系のUNICODE APIは、
UCS-2かUTF-16なのでしょうか？

Windows 2000以降はUTF-16
それ以前はUCS-2(つまりサロゲートに対応していなかった)

サロゲートがいまいちわからん
2バイトで足りないから、上位、下位にわけたってことは、
UCS-2が2バイトとで、サロゲートのあるUTF-16は上下合わせて4バイトってこと？

そうだよ

>>278
単に未使用領域の2文字分を組み合わせて使ってUCS-2に無い分の文字を表わそうというだけの話だから
・UCS-2 → そもそもその文字が無い
・UTF-16→ その部分だけ4バイト。UCS-2にもある文字は2バイト
という事になる

>>280
なるほど足りないところだけ4バイトか
つまり、可変長なのね。
2バイト固定かと思ってたよ＞UTF-16
へえ

へえへえへえ

>>281
そう。だからUTF-16の２バイトの部分がUCS-2と同じっていうメリットがあるんよ。
４バイト部分はあんまり使わない部分だからサロゲートペアっつう２つ合わせる方式で表わしてる。

UCS-2=文字コード、UTF-16＝文字エンコーディング
じゃなかったっけ？

UTF-16はバイト並びにリトルとビッグがあるし、BOMが引っ付いたりするし。

UCSは文字集合。
UTFはエンコーディング。

文字コードというあいまいな語はこういう議論では避けるべき。

>UTF-16はバイト並びにリトルとビッグがあるし、BOMが引っ付いたりするし。

Unicodeではエンコーディングをencoding formとencoding schemeの二段階に
分けていてそのへんややこしいことになってる。

　国試では、｢UNICODEとは、全ての文字体系が収まる"2byte"の文字コード｣というのが正解答だったりする件。
いつからバイト長が固定されたんだよタコ。

3.0未満のUnicodeかよorz

2byteだったら1.xじゃない？

それぞれの構造が単純じゃないから説明するのが面倒だな。

>>284
ユニコードに関係した規格として、次の2つがある。
ユニコードコンソーシアムの「Unicode」。
ISO/IECの「ISO/IEC 10646 Universal Multiple-Octet Coded Character Set」。

前者の規格に含まれる符号化（エンコーディング）がUTF-8、UTF-16、UTF-32など。
後者の規格に含まれる符号化がUCS-2とUCS-4、UTF-8など。

UTF-8が両方に収録されているけど、同一と思って差し支えない。

>>284

UCSは文字集合。

そしてその文字集合から2バイトで表せる部分を切り取ってきて
そのまんま使うのがUCS-2

それを拡張して使用できる文字範囲を広げたのがUTF-16

UTF-8は別のアプローチの符号化方法

>>289
それ以前に1バイト=8ビットとは限らない

どういう場合に１バイト８ビットじゃなくなるの？

マシンがPDP-11だったりした場合

JIS X 0208/0213の規格名ではわざわざ「7ビット及び8ビットの…」と言ってるだろ。
1バイトが8ビットとは限らないからだ。
それに対してUCSは>>291にあるとおり"Universal Multiple-Octet..."で
8ビットであることを明確化している

1バイト≠8ビットな処理系でUTFを扱うようなケースはほぼないんじゃない？

UTF-7もdeprecatedになったしな

UTF-9の時代だろ

ｴｲﾌﾟﾘﾙﾌｰﾙにはまだ早いぜ

>>295
PDP-11 は 16bit マシンだぞ．DEC-10/20（36bit マシン）のことか？

すまん

>>301 それです

Latin-1の設定になってしまってるMySQLにUTF-8ぶっこんでもちゃんと動くんだけど
無理にset character set utf8してアクセスするとかえって文字化けしてしまう
そのままつかってたほうがいい？

MySQLのバージョンは?
4バイト以上のBMP外を表すシーケンスに対応したのは6.0以降だから
それより古いバージョンではLatin-1ということにして
変換は自分で行うとかの小細工が必要

きっと、PDP-8の12bitなんですよ（を

Unisys機(旧UNIVAC系の古い汎用機)では、
1文字=6/8/9/12ビットと、4通りあったりする。
（1ワード=36ビットのマシンの生き残り）

ユニコードのインディアンて？

>>307
インド人です。アメリカ原住民のことは、ネイティブアメリカンと呼んでください。

原住民的にはむしろインディアンの方がいいらしいけど

エンディアンの語源を考えるとインディアンと表記しても間違いじゃないなぁ。

9bitはPDP-10だろ。過去にかなり真面目に議論されたし、ちゃんとRFCも出てるぞ。
http://www.rfc-editor.org/rfc/rfc4042.txt
>306の言うとおり、昔は１バイト6bitだってあった。ISO646だって、7bit の他に6bit版の文字コードも
規定されてたし。近年の改正で6bit文字コード規定は残念ながら消滅してしまったけどね。

みかんはリトルエンディアンの方が白い筋がよく取れるそうだ。

でも皮が硬いときはビッグエンディアンかなー。

シフトジスとMSPゴシックは違うものだろうか？

>>287
Unicodeは規格/標準の名前なのになあ。
検索とか比較とか符号化とか、文字に関する処理について書いてある。
http://www.unicode.org/glossary/#unicode
http://www.unicode.org/faq/basic_q.html#a

>>291
付録CにUCS-2, UCS-4について、
ISO 10646との関係が書いてありますね。

>>313
全然別物。
Shift_JIS = エンコーディング
MSPゴシック = フォント名

文字コードをMS明朝で保存するのはどうやる？

>>317
仕事の都合上、いやいやPC使ってんなら会社で聞け。
そうじゃないなら、もっと基礎から学び直せ。

>>317
おまえはどこのPython使いだ？

あなたはお風呂に入るとき
みかんから食べますか？
それとも山に登りますか？

VB.NET2005だとまだエンコードクラスにMSPゴシックがないけど
できるだけ早く対応して欲しい。

つまらないから帰れ
ネタじゃないならなおさらさっさと帰れ

IDEのフォントをＭＳ Ｐゴシックにすれば解決？

なんで半角文字の範囲まとまってないんだよファッキン！！

すみません、取り乱しました。

unicodeに含まれる文字には番号はついてるんでしょ。
どうしてそれは使えないの？

>>326
どこからの話の流れか分からないが、
それ（コードポイント）をそのまま使う符号化には
UTF-32, UCS-4, UCS-2がある。

ありがとさんです。

UTF-32, UCS-4, UCS-2はどう違うの？

UTF-32/UCS-4
1文字32ビット。
現在では2つとも同じ中身。
どの規格に含まれているかというだけの違い。>>291に書いてある。

UCS-2
1文字16ビット。U+10000以上のコードポイントを持つ文字は表現できない。

UTF-32 は U+110000 以上は無いんじゃ？

もうめんどくさいから今までの全部廃止してUTF-256とかに統一して欲しい

まったくだな

バイトオーダーも固定して64byteぐらいにしておけばいい。

そうだね余裕がある事はすばらしい事だね。

アルファベット件の馬鹿共のせいで混迷しているのだ

そういやIPAとUnicodeの対応表みたいなのってないの？

http://webos-goodies.jp/archives/51072404.html

Microsoft Visual UTF-2008 Professional Edition

>>331
UCS-4もU+110000以上は使わないことになった。
>>330に「現在では」と書かれているのはそのへんの含みがあると思われる

Unicode識別子についての日本語資料ってない？

UTF-8にBOMついてるとまともに動かないソフトが多すぎて嫌すぎる
もっと細分化して、細かく細部まで決めてくれないとどーしよーもないな、実際

アンジーってサイモンとガーファンクルだったような

UTF-8ってBOMつけるんだっけ？

RFC 3629 の 6. を見よ

なる、つけるべきではないのか。

いや、ついていても受け入れるべき
MySQLみたいにそもそもUTF-8を理解してない馬鹿げたソフト多すぎ

>>346 一般には違う。
付けるべきじゃないのは、UTF-8であることが上位層で規定されている場合。

BOMはエンコードを判別するためのものじゃないべさ。
Byte Order Markなんだから。

つまりメモ帳のあの動作は正しいわけか

>>349

まぁ元々はそうだったんだけど UTF-8に於いてはUTF-8であることを
あらわすシグネチャという位置付けにされた。

まぁ1バイト文字で済む国はシグネチャなくても全然問題ないんだろうけど
マルチバイト文字使ってる国ではシグネチャない場合は、エンコード誤認の
可能性があるからな。　UTF-8決めうちのソフトならいいんだけど

勝手に追加するのはどうかと思うが、テキストファイルの頭にBOMついてるからって
誤動作する方が確実におかしい、無視すべき

#!/usr/bin/env hogehoge

とかをBOM付きで保存すると死ぬって本当？

ASCIIにしか対応していないものから見たらBOMはゴミ以外の何者でもないから

UTF-8対応してるといいながら駄目なソフトが多いって話だろ？

ASCIIだったらそもそもBOMは無いだろ
そしてASCII範囲外に対応してるならBOMあっても問題ないし

俺はドラゴンボールが揃ったらBOMを廃止する。
それからDIS 10646.1、いやごめんなんでもない

ＢＯＭよりスーパー写真塾の方がエロイよな。

むかしのエロ本のオンナはそのままのかおだが
いまのエロ本は整形オンナばっかり

UTF-8にBOMなんか辞めようと
そもそも、BOM=Byte Order Mark で、UTF-16、UCS-2、UTF-32、UCS-4なんかで使うものだし
そいつ(BOM)をそのままUTF-8変換した値がBOMもどきだし

Visual Studio 2005なんかはUTF-8でソース管理出来るみたいだな
今のPRJはLinuxでUTF-16使ってるから文字列は全てリソース扱い、っつかASCIIだろうとそうすべきではあるけど
ソースコードにUTF-16をhexでどかどか書いても見づらいだけだ
だけど、データ管理はUTF-16のがいい。サロゲートペアなんて使うことはまず無いし、１文字=2バイトと見なして差し支えなければ楽でいい
UTF-8は最近ISO 10646だっけ、RFCだっけ、あれUnicode.orgだっけ？規格変更で1〜4バイトの可変長になって、それとともにUTF-32の領域も狭くなったみたいだが

XMLなんかはエンコーディング付いてるから問題ないし、ソースもSJISやEUCさえなんとかなれば別に問題らしいものはない気がする＞UTF-8
UTF-8自体ASCIIコンパチだしね

UTF-32は最初からU+10FFFFまでだよ

お前ら説明下手すぎだろ。
もっと俺にわかるように産業で説明しなさい。

>ソースもSJISやEUCさえなんとかなれば

これがなんとかならないから　UTF-8にBOMが存在しているんだろうけどね。

>>360
>エンコーディング付いてるから問題ないし
そういう場合はBOMを付けるなとちゃんと書いてある
ttp://tools.ietf.org/html/rfc3629#section-6

BOMを付けるのはあくまでもそれがUTF-8と確定できない場合だけだから問題ないだろ
それともエンコード不明のテキストファイルを力技でエンコード推測するのが正しいとでも？
あるいはテキストファイル＝UTF-8として統一するつもり？
Latin-1とかはそうそう無くならないと思うぞ

エンコード不明のテキストファイルを力技でエンコード推測するのが正しい

BOMダセエと思うが、
BOMも処理できないUnicode処理系は氏ねよ。

Chinaってチャイナじゃなくてシナ＝支那だったのね
勉強になった

はい？

いいえちがいます。

チャイナシンドロームってどういういみ？

何の？　一般的には原子炉のメルトダウン事故の用語だが。

Japanてジパングじゃなくてニッポン＝日本だったのね
勉強になった

漆器のことだろ？

sorry japanese only.

かわいそうな日本人専用

漆塗りのペニスキャップとか作ると
やっぱりかぶれたりするんだろうか

漆塗りの器で唇かぶれた話とか聞いたことないけど。

漆がかぶれるのは生(？)の漆だけじゃないかと

シャープの芯のUniもこれが語源なん？

http://ja.wikipedia.org/wiki/%E4%B8%89%E8%8F%B1%E9%89%9B%E7%AD%86

| 国内では「三菱鉛筆」と、旧財閥の三菱グループ各社と混同されないように
| 「uni」（ユニ）のブランドも使っている。「uni」は、英語で「単一の」を
| 表す接頭語「uni」から比類無き品質ということを表したもの。

単一はmonoだったよーな
⇔pori

モノ
ジ
トリ
テトラ

monoもuniも一つという意味

×pori
○poly

釣りなのかこれは

ユニークのユニ

ギリシャ語系のmono, di, tri, tetraと、ラテン語系のuni, bi, ter(tres, tri), quadriの違いだな。
多角形も両方の表現があって、trigon, tetragon, pentagonとするかtriangle, quadrangle, quintangleとするか。
# 尤も、アメリカ辺りだと入り混じっていて、septagon, septangle, heptagon, heptangleのどれも見かけるけど。
## ついでに言えば、polygonに対するラテン語はmultiangleになる筈だけど……

rectangleは？

>>386
ラテン語由来。ラテン語にも、rectangulasという言葉があるらしい。英語に直訳すると、right angleになるそうな。
つーか、m-w.comでちょっと調べれば済むことなんですが。

都市ガスはtoshi gus だからペリーが運んできたオランダ語っぽい

トナカイってアイヌ語だったんだな

ラッコもな

MacのZIP解凍したら濁点や半濁点で文字化けするんだけど
これの変換てどうしたらええの？

NFCしてください。

NFDとNFCの違いか。
オレもそれやらかして、Perlのモジュール使って直したなあ

ありがとう
一部元に戻らないトコもあるけど中身が理解できる分には戻せたよ

結局UTF-8みたいなASCII互換の可変長コードが主流になるんだったら、
80h〜FFhをコードページ指定にして、
その後の１〜2オクテットをまとまった文字種セットにしとけば、
すっきりしたコードになったのになあ。

状態持ちはイヤン

それなんてISO 2022?

>>395
Arena-i18n内部コードやん
あれは固定長だけど。

>>367
>Chinaってチャイナじゃなくてシナ＝支那だったのね
あー！そういう意味だったのか。
支那支那っていうから判らんかった。
支那の語源がChinaなのね。

どちらの語源もサンスクリットの同じ単語だそうだが

いくつか説があるようだが
ttp://www004.upp.so-net.ne.jp/teikoku-denmo/html/history/honbun/cina2.html
は「秦」を語源としてるな
まぁJapanもニッポンがジパングを経てジャパンになったんだから
シナとチャイナ位の違いは普通か

日本の現代中国語読みがリーペンで、マルコポーロが東方見聞録で書いたのがジパング。
この違いがかなりデカい気がするが、どう理解すればよいのやら。
古代中国語で日本をジパングと読む？

ri4ben3は現代普通話でのピンイン
「日」は漢音で"ji" 「本」は呉音で"hong"

今の日本語で日を「ジツ」と読むのは古い中国語からきてるわけだし。
中国は現代音、中古音、古音と何度も大きな変貌を経ている。特にマルコポーロの時代である
元は中国語の発音が大きく変化した時代の一つ。

誰もそんな話は聞きたくないし。
ＵＴＦ８とユニコードの違いが聞きたいし。

いやいや
>>401の話は重要だよ。

たとえば天安門。
これは自動的に排除するようにプログラムを組むことが義務付けられていて、守らなければ毒ガスの人体実験されて体を切り刻まれる。

>>401の話は、少なくとも一つのキーワードについてそれをしなくてよいと確認できる根拠だから。

聖火リレーで旗を広げようとした人がそれを広げる間もなく大勢の警官に取り押さえられ逮捕されたけど、日本って中国並みに怖いな。

http://tvde.web.infoseek.co.jp/cgi-bin/jlab-dat/s/216761.jpg
http://tv.dee.cc/jlab-maru/s/maru1209168412846.jpg

Japanese police suppressed a member of Tibetan human rights group
日本警察によるチベット人弾圧の様子

>>408
警官の数が異常すぎ。

「たかだか芸能人が怪我するかも」程度なのに洞爺湖サミットの何倍の警官を投入してるんだと。

それは勘違いだよ。
この場合、芸能人の命の火が消えること以上に、聖火が消えることのほうにピリピリしてるんだよｗ

聖火という「設定」がどんなに馬鹿馬鹿しくても、その馬鹿設定を国際的に共有しちゃってる以上、
活動家を抑えられずに聖火消しちゃったら日本の恥だからね。

そもそもくだらんイベントに税金使うなよ。

Unicode関係ないだろうおまえら……。

>>410
でも火を消そうとはしてないんだ。

むしろさらに火を大きくしようとして発炎筒やら布切れやら持ち込んでるわけで。

それは始まってからじゃないとﾜ絡んだろ

.NETはたとえ完全でないのでもいいから文字コード自動判別クラスを用意すべき

>>414
普通に殺されかけて通報したときは「ナイフが心臓に刺さったらもう一度通報してください。」って言われるのに。

設計や管理がテケトーだから自動判別なんてのが必要なシステムになるんだ

恥を知れ！

>>415
禿同

>>415
間違えると「バグだ！金返せ」と言うバカの相手にいいかげんうんざりしたんだろう。

>>410
＞聖火という「設定」がどんなに馬鹿馬鹿しくても、その馬鹿設定を国際的に共有しちゃってる以上、

これは暗にUnicodeのことを言ってるんだよな？
だよな？

批判くらい小学生でもできる。気に入らないなら代案を示すべき。
ここでグダグダ文句ばっかしタレてるヤツは小学生なのか？

これは暗にみんしゅとうのことを言ってるんだよな？
だよな？

>>421
まぁそうなんだが、正しすぎて2ch全否定になってるな。

>>353
カーネルが1バイト目の#を見てスクリプトと機械語を
識別しているから、その前にBOMがついていたら機械語
として実行しようとして暴走するだろう

機械語って、おまえELFとか知らんのか

COMファイルしか知らないんだよきっと

あれ？最近COMファイルって見かけないな。
使わなくなったの？

拡張子のＣＯＭならＤＯＳ専用だから。

もうやだこの低レベルスレ

>>428
ところがどっこい。Windowsは拡張子COMのPEを平気で実行する。
例えばNT系のformat.com

スレ違い止め止め

>>429
おこぼれを貰いに来てるだけのお前みたいな奴は、
自分じゃその下がったレベルを引き上げられないからつらいよね。

でも、おこぼれ貰いに来てるだけの奴が嘆いても、「勝手に嫌がってれば？」としかｗ

俺も428と同じ認識でネタを書いたつもりだったが。動くのな。
まあ確かにMSだったら拡張子.comでも動くようにしてそうだ。

タイのヤフーにアクセスするとブラウザにタイ語がきちんと表示されるけど、それをコピペして
エディタに貼り付けると文字化けするのは何故でしょうか？

エディタはUnicode版サクラエディタを使いました。

Yahoo! ?????????
http://th.yahoo.com/

FrontPage - サクラエディタUNICODE化プロジェクト
http://mofmof.nsf.tc/soft/sakura_unicode/

こんなところで聞くより、開発元で聞いたほうが早いと思うぞ。

unicode->ウニ
utf-8->アワビ

>>432
おまえもな

>>435
なるほどサクラエディタの問題なのか。
EmEditorだとタイ語というのがあったので、それでするときちんと表示されました。

たぶんクリップボードからANSI文字列として取得してるんじゃないかな。

>>434
普通に表示できたけど、フォントリンクがうまくいってないだけとかじゃないの

>>439
EmEditorにコピペすると、ちゃんとタイ語で表示されたので、多分そうではないと思います。
そこで疑問がまた出てきました。

Unicodeってほぼ全文字を扱っているんですよね？
EmEditorのUTF-8を選んでも、上記のタイ語は文字化け。
タイ語を選んでやっときちんと表示される。

タイ語用のUTF-8とかがあるんですかね？

>>440
フォントリンクとはどういうことでしょうか？？

扱ってる文字集合にタイ文字が含まれてないせいで表示されないのか、
ただ単にフォントが足りなくて表示されないだけなのか、
問題を切り分けろっていってるんだよ。

UTF16は終端文字がNULLバイト2つだから嫌い

>>441
そういう意味じゃなくて。
サクラエディタ自体がミスってて、コピーされた文字列をAPIで取得する時に、
Unicode指定じゃなく、ANSIを指定しちゃってるかもってこと。
まあさすがにそんなことは無いだろうけど。

>>445
それはないな。俺が確かめたから。

>>443
UTF-8というのはタイ語は含まれていないのでしょうか？
ブラウザとEmEditorではタイ語をきちんと表示しているので、タイ語のフォントはあると考えてはダメなの
でしょうか？

タイ文字をブラウザからEmEditorにコピペして、それを保存したのをバイナリエディタで見ると、UTF-8じゃ
ないみたいだ。

EmEditorのタイ語という文字コードはUTF-8とは別物ということか？

>>440さんの言っていることは、、自分の環境ではUTF-8のタイ語を表すコード領域とタイ語のフォントが
うまく結びついていないということかな？

でもブラウザではちゃんと表示されているんだよな。
よくわからん。

>>447
少なくともIEとFirefoxは言語別に使用するフォントの設定を持っていて、
タイ語の文字を見つけたら、タイ語用のフォントでタイ語の文字を描く。
ところがサクラエディタはそうなっていないのではないのか、ということ。
（無理に日本語フォント使って豆腐になるとか）

>UTF-8じゃないみたいだ。
保存時にデフォルトでShift_JISが選ばれるなんてことはない？

あと、試しにsakuraW_r1398.zipをダウンロードして
コピペしてみたが、うまくいっているように見えるけど。

>>448
＞保存時にデフォルトでShift_JISが選ばれるなんてことはない？
設定を色々見ましたが、そんなのはなさそうな感じです。
EmEditorには、UTF-8の他にタイ語(Windows)という文字コードが選択できるんですよね。

1文字だけコピペして、それをタイ語(Windows)で保存。
それをバイナリエディタで見ると3バイトでした。だから多分Shift_JISではないと思います。

>>448さんではうまくいってるということは、やはり自分の環境の何かが悪いってことなんしょうね。

>>449
あたまだいじょうぶか

そもそもサクラエディタはShift_JISで扱える文字しか対応していないはず

>>451
Unicode版の話だといってるだろ…
よくよめよ

Unicode対応版を謳っていても実際に満足にUnicodeに対応している
テキストエディタはVisual Studioのエディタと秀丸くらいしかないよね。

>>449

タイ語(Windows)って選択肢はUNICODEとかじゃなくて、CPなんとかというコードページ
（WindowsのShift JISだと CP932）をタイ語のコードページに切り替えてるだけじゃないの？

だからコードページ切り替えに対応していないエディタでは文字化けする。

一旦EmEditorで　UTF-8で保存して、そのあと他のエディタで読み込ませてみたら？

サクラエディタスレでやれば？

>>453
秀丸は合字処理がおかしい

>>454
UTF-8で保存して、サクラエディタと秀丸で開いてみましたが、ダメでした。
とりあえず自分の環境では、Unicodeとそれに対応するフォントがうまく対応付けされていないと
結論ずけておきます。

うちの秀丸は、http://th.yahoo.com/ をコピペしてもぜんぜん文字化けしないよ。
もちろんタイのにょろにょろした文字が画面いっぱいな。

コピペがOS依存だって事忘れてるわけじゃないよな

>>453
おまえが知らないだけ。

Alphaとかいうエディタは異字体セレクタまで対応してたな。

Unicodeは16ビットで全ての文字が収まると早合点したことが失敗の始まりですか？

いいえ、全ての文字を符号化できると思ったのがそもそもの誤りでした

TRONや今昔文字鏡のことですね、わかります

もっと言えば、文字とは符号化できるものである、という前提から間違っている。

いや、TRONは存在自体が間違っている。

>>465
文字って符号じゃないの? 符号化できない文字表現という存在自体が想像付かない。
あ、一応、1:1マッピングできない(適切でない)ケースがあることくらいは想像が付く。

そんなネタにマジレスしなくても

龜甲占いの結果を写生しました/写真に撮りました。
この画像は符合ですか?
一応「龜」ですが。

「龜」と字を書きました。画像として保存しました。符合ですか?
この画像ファイルには"1.jpg"という名前をつけました。符合ですか?
「龜」の代りに<img src="1.jpg">とすることにしました。符合ですか?

連番をつけて符号化しようと思ったあたりが、問題なんじゃね

合成文字とか似ている漢字は一緒にしようとか
めんどくさい事考えるから・・

> 似ている漢字は一緒にしよう
これはまったくやらずに済まそうとするのは無理じゃない？
デジタル化以前には表記揺れするのがあたりまえだったんだし。

どこまでやるかを間違った、という批判ならその通りだと思うけども。

いや，揺れたものをそのまま保存・表示できない時点でダメ
揺れたものを対象にした論文などが表現できなくなるから

人間が文字の生き死にを自由にしようなんて、おこがましいとは思わんかね・・・・・・

本間先生？

結局、「国番号＋ＪＩＳコード」 で１６ビットとか３２ビットとか、みたいな形にすればよかったんじゃない？
（外国はＪＩＳコードとは言わんが、ま、その国ごとで規格化されてるコード、って理解してくれい）

変に世界中の文字をシャッフルしちゃったのが間違いだな。

それがサロゲートペアだろ。

なんでやねん

>>473
そいつは画像でやれよ……

一般的な用途ではある程度ユニファイされてる方がいい。
微妙な違いなんて日常的な文章には不要だし、検索とかにも不便だし。

>>477
(；ﾟдﾟ) ・・・
　
(つд⊂)ｺﾞｼｺﾞｼ
　　_, ._
（；ﾟ Дﾟ） …！？

>一般的な用途ではある程度ユニファイされてる方がいい
これはその通りだと思うけど、符号化のレベルではやらない方が良かったかと・・

もう1つ上のレイヤを用意して表記ゆれを吸収するのはそこの層がやる
とかにすればやり方を失敗してもそこの層を差し替えるとかして何とかなったのに

同意．一番下でマージしちゃったらどうしようもない
画像でやれって言う人は，実際に自分でやってないから
どれだけ大変かつ不便で読み難くなるか分からないんだろうな

実際に文字コード設計したことない人が国コード付けろとか128ビットにしろとか
妄想語るのももはやお約束ですよねー

UnicodeでAdobe Japan1-6互換の字形切替をする枠組みが既に正式規格化されているにも関わらず、
「みたいな形にすればよかったんじゃない？」
「もう1つ上のレイヤを用意して」
「一番下でマージしちゃったらどうしようもない」
とか言ってるヤツってナンなの？ゆとり？
ttp://www.unicode.org/reports/tr37/
ttp://www.unicode.org/ivd/
ttp://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1435_ivs-demo-irg30.pdf
ttp://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1435_ivs-white-paper.pdf

上記PDFに書かれている対応製品以外にも、フリーソフトやフリーフォントで既に対応しているものもある。
ttp://alpha.sourceforge.jp/
(↑：日記の2008年1月〜に詳細記述)
ttp://yozvox.web.infoseek.co.jp/
(↑：掲示板の2008年1月〜に詳細記述)

てか、文字コードの話をするなら↓の方がいいだろ、常識で考えて。
文字コード総合スレ part3
ttp://pc11.2ch.net/test/read.cgi/tech/1180250376/

>>483
いかにも 「ワタシが文字コードを設計しました！」 って言いたげだな

何事にも失敗はある。

Unicodeは失敗

ROMっているだけだったが、ここが文字コードスレだと錯覚していた。

ゆとり教育は失敗

失敗したら反省が必要。そして次回はどうすべきか案を出し合う。

>>453
しゅーまる（何故か変換(ry）は、アラビア語ちゃんと扱えるんだ。すごい。
xyzzyはアラビア語無理なんだよなあ・・・

有名どころだと秀丸とEmEditorくらいだな。

しゅーまるぐみはやわじゃねえ！
しゅーまるぐみにはいるんだ！

EmEditorのフリー版のUnicode対応はイマイチだけど
有料版はいいんかな

Alphaはどうよ

>>494
たぶんエディタ部分のコードは同じだと思うよ。

>>495
アラビア語の結合は対応してるみたいだけど、キャレットとか選択領域の端とかと重なると切れちゃう。
ただ、いまのところシンタックスハイライティングがびみょんで、この板的な実用には向かんかなあ。

>>492
EmEditorや秀丸って右から左に表示するオプションあったっけ？
前に試したときはどっちもダメだった気がしたんだけど、それから対応したのかな。

直接指定するわけじゃなくて、エンコードで判断

>>498
それはEm? 秀丸?

でも、そうなるとUnicode系の文字コードじゃRTL文書書けないのかな。

>>497
> この板的な実用には向かんかなあ。

プログラム技術＠2ch掲示板
ttp://pc11.2ch.net/tech/

この板はプログラムを作る人のための板です。

プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。

>>500は有名な基地外だから無視していいです

>>500
Alphaは、アラビア語が(比較的)まともに扱えるけど
「シンタックスハイライトが微妙」だから
「プログラムを作る人」が使うエディタとしては「実用には向かん」
って行ってる様にみえるんだけどなんでそのコピペなのか理解できません！

試してみたけど、秀もEmも右から左にする方法を見つけらんなかった…

夏休みだから話題が逸れる前に予防線張ろうとしたと解釈してあげよう。

　　　　 ///////
　　　　///////＿＿＿＿＿＿＿＿＿＿＿_
　　　 /////// ￣￣￣￣￣￣￣￣￣|￣￣
　　　///////　　　　　　　　　　　　　 (~)　ﾁﾘﾝﾁﾘﾝ
　　 ///////　　　　　　　　　　　　　　ﾉ,,
　　///////　　　　 ∧＿∧　　　　　　　　 ／￣￣￣￣￣￣
　 ///////　　　　 （　´∀｀）（ 厨 ） )）　＜　　夏だなあ〜
　/////// 　　　　 （つ　へへ つ　　　　　 ＼＿＿＿＿＿＿
///////　　　//△ ヽλ　 ）　）　旦
//////　　l￣￣￣￣￣￣￣￣￣￣￣l
/////　　　￣| .|￣￣￣￣￣￣￣| .|￣
////　　　　　^＾^　　　　　　　　　 ^＾^

>>500
コイツ、バッチファイルのスレで誰にも相手にしてもらえないから
こんなスレを荒らしてやがる。

↓メタ夏厨議論どうぞ

Unicode は、夏厨
UTF-8 は、メタ夏厨議論

UNICODE: 数社の企業が決めたもの、使用できる文字とその番号を定義。
UCS: 国際標準、内容はUNICODEとほほ同じ
UTF: UNICODEやUCSをコンピュータ上に表現するための仕組み

この認識あってる？

UNICODEとUCSってのはJavaScriptとECMAScriptの関係に似てるんかねぇ。

コンソーシアムとその規格が Unicode
国際標準規格が ISO/IEC 10646

そしてそのそれぞれで UCS とか UTF とか定義してる

ISO/IEC 10646の名称（の頭文字とったもの）がUCSだろ。
509の理解で合っているぞ。

大は小を兼ねるんだから、
Shift-JistとEUCもこれからはUTF-8で扱えばすべて解決。
ユニックス派のカタブツはEUCにこだわるからいけない

文字集合は大は小を兼ねてるけど符号化方式が違ってるだろ

最近のUNIXなら、日本語環境でもだいたいUTF-8だと思うが。

>>512
むしろS-JISの方が圧倒的に量が多くて、移行できないだろ。

>>509
> この認識あってる？

間違ってます。

>>516
ｋｗｓｋ

>>517
間違ってますなんて書くだけの奴に詳しく説明できるほどの根拠なんかあるわけ無いだろ。
ちゃんと根拠があって指摘してるなら>>510 のようにはじめから書くしな。

>>518
「間違ってますなんて書くだけの奴に詳しく説明できるほどの根拠なんかあるわけ無い」
「ちゃんと根拠があって指摘してるなら>>510 のようにはじめから書く」
そう考える根拠は？

あ、そうか、根拠をはじめから書いていない奴には、詳しく説明できるほどの根拠が無いんだっけ。
ごめんごめん、訊くだけ無駄だった。

>>519
まあ、その、なんだ、悪かったよ…。図星つかれてレスもまともに読めなくなるほど泣く
とは思わなかったんだよ。もう言わないから勘弁してくれ、な？

泣かしたな悪者め

子ども泣かすの良くない

＞＜

　　　､_人_人_人_人_人_人_人_人_人_人_人_,
　　､_）　 　 　 　　　　　　　　　　　　　　　　 （_
　　 _）　 夏　　　厨　　　警　　　報　　！！ （_
　 　_）　　　　　　　　　　　　　　　　　　　　　（
　　　'⌒Ｙ⌒Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒Ｙ⌒`
　　　　　　　　　　　　　　　　　　　／／
　　　　　　　　　　　ﾍ,(ﾟ∀ﾟ)ｙ'＾　　　　　ｱｰﾋｬ ﾋｬ ﾋｬ ﾋｬ ﾋｬ
　　　　　　　 　 ､　 _L_;二;_.j_　 ,　＼＼
　　　　　　　　　 ￣ ﾄ､~Ｙ~,/|￣
　　　　　　 　 　 　 ,|ｙΛ=ｽｲ|､　　　ｱｰﾋｬﾋｬﾋｬ 　 ＿
　　 　 　 　 　 　　' | | !;∀Y i| `　　　　　　　　　 /##;〉
　　　　　　　　　　　|ｲYﾄ〉ｲY.| 　　　　　　　　　 / ￣
　　　ｱﾋｬﾋｬ　　　　 ﾚYy'`vﾚ|　　　　　ヽ(ﾟ∀ﾟ )ﾉ
　　　　　　　　　　　 Vｙ　　Ｖ'　　　　　 　（夏 ）ヘ
　　　ヽ( ﾟ∀ﾟ)ﾉ　　　　　　　　　　　　　　　<
　　　　 （ 夏）ﾍ
　　　　　<

>>520
夏のどさくさに紛れて、そういうキャラ付けで逃げるのはよくないよ。気持ち悪いし。

鸚鵡返し、人格攻撃はスレが機能しなくなるからやめようよ・・・

>>516が>>509に対して説明すれば済むだけの話。

>>509
http://pc11.2ch.net.nat.homeunix.org:65082/post.pl?b=tech&t=1177930957

本来は
Unicode ⊂ UTF-8
であることは明白だが、

事Windows OSではUTF-16の事を単にUnicodeと表記するので、
Windows上では
Unicode ≠ UTF-8
とも言える

釣りですか

ググれカス

ネタにマジレス( ´;ﾟ;ё;ﾟ;)きんも〜☆彡

　　　【ＪＩＳコード】
デコード↑／↓エンコード
　　　　 シフトＪＩＳ
　　　　　 ＥＵＣ

　　　【ユニコード】
デコード↑／↓エンコード
　　　　 ＵＴＦ８
ＵＴＦ１６ＬＥ／ＵＴＦ１６ＧＥ
　　　　 ＵＴＦ３２

　　　　　【音声】
デコード↑／↓エンコード
　　　　 　WAV
　　　　 　MP3
　　　　 　WMA

　　　　【ビデオ】
デコード↑／↓エンコード
　　　　 　AVI
　　　　 　MPG
　　　　 　FLV

全角で書く奴って、やっぱりアレだな…

ときに、UTF16GEってなんだろ。

デコードした先がコードとは何ともかんとも

>>535
ゲルググエンディアン

あまりの非の打ち所の無い完璧な説明なため
全角や誤字しかツッコミどころが無いな。

確かにゲルググエンディアンは完璧だ

コンテナはどうなんだ

>>533
おい大漁だなｗ
やったじゃねーかｗ

>>533-539
釣られまくり乙

全角と誤字以外のツッコミは無いのかい？

へんなのが住みついたね

夏だね。

そろそろ秋だよ

暦の上でどうだろうと、今は夏真っ盛りだ

では、全角と誤字以外には非の打ち所の無い
カンペキな「Unicode と UTF-8 の違い」の解答という事で
無事にこのスレを閉じたいと思います。
みなさん、長い間ごくろうさまでした。

お疲れさまでした。

先生の次回作にご期待ください。

　 　 世　界　迷　作　劇　場


　 　 　 　 　 　 　 　 おわり

思ったこと。
・広義の「ユニコード」はUTF-8等の規格を含めることがあるので不正確
・>>536指摘済みだけど、音声のenc/decと、文字のenc/decを一緒にするのは
　違和感あり。JISコードは既に「符号(コード)化」されてるから。
　俺的には
　　音楽→(量子化)→PCM→(各種圧縮)→MP3　の３段階が
　　文字→符号化文字集合→テキストエンコーディング　に対応する感じ
・AVIって格納形式の概要だけ決まってて、圧縮アルゴリズムは別じゃなかった？

狭義のユニコードっていうのはM$が決めつけたUnicodeのことか？
例えば、ttp://msdn.microsoft.com/ja-jp/library/ms191200.aspx
>Unicode 仕様は 2 バイトを使用して 1 つの文字をエンコードすることでこの問題を解決しました。2 バイトには 65,536 個のパターンがあるため


つーか、広義も狭義もねーよ。バーヤ。

まだやる気か？

>>552
MSが決めつけたというよりも、まだUTF-8もサロゲートペアもなかった昔を引きずっているだけ。

サロゲートペア厨必死だな。無視されてんのによｗ

サロゲートペアは、32bit wchar_tの入り口ですよ。

マイクロソフトで統一すれば市場に一致して解決

けど駄目仕様に駄目実装が蔓延ると思うよ
競合いてもあれだもん

結論
>>1みたいなのが現れるのはMSが糞だから

何でも他人のせい、日本のせいにする人たちみたいですね。

批判だけならパートのおばちゃんでも出来る。
問題は、どう改善すべきか、改善するに当たって
予算・人員・スケジュールをどう工面するのか、だ。
それを何一つ提示していない。
おまいら、パートのおばちゃん以下のクズ。

その理屈だとパートのおばちゃんと同等であって以下とは読み取れないが

少なくともパートのおばちゃんは働いてるからな
　　　　　　　　　　　　　　　　　　　^^^^^^^^^

>>552
マイクロソフトの言うUnicodeはエンコーディングの一つでしょ。>>533からの
流れからして
協議:符号化文字集合としてのUnicode
広義:符号化文字集合およびそのエンコーディング仕様。Unicode規格
以外の解釈はありえんと思うが。このスレ>>14ぐらいまで読み直せ。

だからわざと、マイクロソフトのUnicodeと区別するためにカタカナで【ユニコード】と書いたがな。

お前ら、紛らわしいと思わないのか？
MSは正義だからOKとか、思考停止杉。

え、誰か「MSは正義」とか言ってる？
その脳内設定が、お前の思考停止なんじゃないの？
思春期のオトコノコの「自分以外はみんなバカ症候群」みたい。

>>567
>>557

>思春期のオトコノコの「自分以外はみんなバカ症候群」みたい。

> お前ら

たった一人書いてただけで、「お前ら」か。
知ってる？「デフォルトの名無しさん」は全部同一人物なんだぞ。

以下でOK?

・(文字集合としての)Unicode
扱う文字の一覧を定めて、識別用に符号をつけたもの。
「あ」=U+3042、「A」=U+0041・・・

・UTF-8
Unicodeの文字列を電子データとして扱う際の表現を定める「エンコーディング」の一つ。
あA(U+3042 U+0041)→E3 81 82 41

エンコーディングの他の例としてシフトJIS・UTF-16 BE・マイクロソフトのUnicode 等がある。
よってUnicodeとは
　1. 符号化文字集合の一つ
　2. 文字コードの規格
　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい
の3つの意味があり、一方UTF-8は、エンコーディングの一つとしての意味しかない。

>>570
> よってUnicodeとは
> 　1. 符号化文字集合の一つ

こんな使い方はない。

> 　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい

アホドキュメント、アホアプリは無視するのがいい。

×符号化文字集合
○文字集合
だよね？
MSは無視できないほど規模があるのが憎たらしくて困ったチャンなわけで。

「マイクロソフトの」と書いているが、
まともなドキュメントもあるわけで…
メモ帳の文字コード選択ウィンドウとかそういう部分的なことで、
> 　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい
を言葉の定義の一つに同列に並べてるのは馬鹿っぽいね。

>>573
メモ帳もUnicode/Unicode big endianだけど。

とりあえず「UTF-8にBOM」という意味がわからん表現はやめて欲しいもんだ

> 　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい
典拠は？

>>552だけ？
これってSQL Server 2005のドキュメントだよね？

>>576
Office XP リソース キット
Unicode サポートと多国語ドキュメント
ttp://msdn.microsoft.com/ja-jp/library/cc389880.aspx
>Unicode では、どの文字に対しても 2 バイトからなる固有のエンコードが割り振られます。

やっぱりアプリ屋はフレームワーク屋よりレベル低くなるね。
周辺技術の知識については。

抱き合わせ販売禁止

というのが文字コード氾濫を招いた。

最初からOSとセットで組まれていれば文字コードはマイクロソフトのやつがスタンダードになって
ユーザーはいくつものコードに悩まされることがなかった

Shift JISで悩まされてた人って多いんじゃないの？

>>572
「符号化文字集合」でいいのでは？
文字の集合を定義して、各文字に対して符号化表現(例:A=U+41)を規定してるから。

「符号化文字集合」の定義はJIS/ISOとW3C/IETFですら違うからどちらのつもりなのか
くらいはっきりさせろ

>>580
それで悩むのはＵＮＩＸ屋だけ。

>>579
えーっとどこから突っ込めば？（笑）

つーか貧弱な16bitマシンで日本語とかやろうとしてShiftJISなんてもんをつくったとこからおかしくなってるよなぁ、いろいろと。

>>583
携帯メール入れるとどのプラットフォームも悩ましいのでは?

>>584
しかも、SJIS作ったの誰だ？って話だよな。

当時の状況を考えれば仕方ないかんじだろ
一文字16bitなんて贅沢の極み

贅沢の極み。と言ってた人が、
年金記録問題を予見できなかったんだろうな〜。
氏名をカナで管理ってありえねーよ。

むしろカナしかないだろ

仮に漢字を使っていたとしてもやっぱり年金問題は起こっていたと思う。
略字正字の入力がずさんだとか、読み方分かんなくてうやむやにデータ入力するとか。

氏名に漢字をつかえば
全国のグリーンピアは莫大な赤字を抱えずに済んだのだろうか？

グリーンピアって暴力団が接待するための専用設備だろ

年金台帳の問題って朝鮮脳が主犯ぽいな

>>588

昔はカタカナと英数しか印刷できないプリンタがほとんどで、
漢字やひらがなな印字できるプリンタは「漢字」プリンタとか
「日本語」プリンタとか名前が付いて特別扱いされてたのさ

>>594
それを最初から分かってて、あえてコンピュータで管理しようとしたんだろ？
もうアフォとしか言いようが無い。

いやいや、当時でも立派に稼動してたシステムはあるさ。

>>595
そういう問題じゃないだろ。
アホかよw

>>595
現代からだったらなんとでも言えるよ。
例えば、将来DNAを登録出来る、確実に本人に紐付けられるシステムが出来たとして、
「昔は」名前を登録するだけしか出来なかったんだと。
で、
> それを最初から分かってて、あえてコンピュータで管理しようとしたんだろ？
> もうアフォとしか言いようが無い。
と言うようなもんじゃないか？

官公庁では今でも”「漢字」プリンタとか「日本語」プリンタとか”を使ってるね。
こないだ海上自衛隊の護衛艦を見学する機会があったが
艦内に古めかしい漢字プリンタが鎮座ましましておられた。

何を調達するにしても防衛スペックの準拠を求められるからね
それがかなり無茶苦茶な要求だったりするから一度通った物は三十年前の図面でもそのまま流用する。

いやぁ、防衛省関連はそんなもんじゃないよ。「スペックの準拠」じゃなくて他のものが要求されているんだ。判るだろ?w

幹部用最新PC一式（個人宅へ配送。伝票は廃棄のこと）なのか
ケツの穴なのか。

>>602
んにゃ、世間をにぎわした件とか、○○システムと抱き合わせとか。

VB6.0が受け取るコマンドラインはどんな文字コードでもいいんだろうか。
VB.NETアプリからVB6.0アプリをコマンドライン付きで呼び出すとコマンドラインはUTF-8でわだすが
しかしVB6.0はShift-Jisじゃないと扱えないし
どうなっとるんじゃ

>>604
VB6の内部コードはUTF-16LE
しかしエディタではsjisという素敵仕様

いや、それは知ってて、
とりあえず、コマンドラインでユニコード文字のトランプ図柄をVB6.0アプリに送ってみるとどうなるよ

VB6はそこ等辺の境界で勝手に文字コード変換しまくる
どんな仕様かはもう使ってないから忘れた

＞VB.NETアプリからVB6.0アプリをコマンドライン付きで呼び出すとコマンドラインはUTF-8でわだすが
というか、これが訳わからん。
VB.NETのエンコーダ選択が間違っとるんでないの。

コマンドラインをUTF-8で渡すって言うのが俄に信じがたいな

VB6だろうと何だろうとエントリポイントはWinMainかwWinMainな訳で、
UTF-8なんてあり得ん。OSの仕組みをよく考えろ。
アプリがWinMainの時はOSがシフトJISで渡し、アプリがwWinMainの時は
OSがUTF-16で渡してくる。

>>610
WinMainとかを呼ぶのはランタイムだろうに……
コマンドライン取得もランタイムが GetCommandLine() で取得
してるので、OS がやっているわけではないよ。

>>611
専ブラ、アップデイトしろよ。

>>612
実はアップデートテストをかねて書きこんだんだけど
うまくいってなかったみたい :-)

>>100あたりでようやく判った。

http://www.atmarkit.co.jp/fxml/askxmlexpert/024utf/24utf.html

これも判りやすかった。

>>100は微妙に誤解を産む表現だぞ。
UTF-16は、16bit単位が一つか二つで一文字。
32bitじゃない。BEとLEがあるからこの違いは本質的。

えぇぇぇぇ？１６ビット２つで３２ビットじゃ無いの？
もしそうなら、１２８ビット暗号とか、３２ビットＣＰＵじゃ絶対に扱えないじゃん。

32bitの文字一文字と
16bitの文字二文字ではビットの並びが違う

という事を言いたかったんではないかと

>>617
釣りにマジレス

「ビットの並び」 なんて言ってる時点でアフォ丸出し。
同じ値をあらわす３２ビットの数値であっても、
ディスクファイル上とメモリー上とＣＰＵ内部のＡＬＵとでは
ぜんぶ同じとは限らん。

意味がわからんならレスしなくていいよ

会話の粒度を間違う奴ってどうしようもないよな。
一番細かい視点に立つ自分が一番確かで賢い話をしていると勘違いするし。

>>620
>>621
だから釣りだって

Ｎｕｍｂｅｒを略すとなんでNoになるん?

>>623
Numberを略しているんじゃなくて、MiddleEnglishのnombreの略かラテン語のnumeroの略なんでしょ。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1481014

AをBにコピーできない。
AがBにコピーできない。
どちらも同じ意味?正しい日本語?

>626
後者はあまり正しい日本語ではないね。

> AがBにコピーできない。

AがBにコピーされない。　
だと違和感少ないけど意味違っちゃうか。

ところでこれはスレとなんか関係あるのか？

hosiyu

　

utf-8nってなんなの？

BOMなし

勝手にBOMをつけるエディターってなんなの？
イヤガラセなの？

javaコンパイラ javac はソースコードに BOM が付いてるとエラーを出す。
eclipseのjavaソーコードエディタは BOM が無いと文字化けする。

うんこ

UTF-8っていつ発生したんだっけか？

そんなことよりUFT-8にBOMをつけた基地外を知りたい

オレも知りたいわ、それ

BOMがバカ正直に付いてるのは、Windowsのテキストファイルだけだと思うお。
Mac OS X とか付けないっぽいｗ

バカ正直ならBOM付いてるUTF-8は不正として開かないだろ
折角のバイトストリームに先頭の概念持ち込むとか基地外にも程がある
そんなゴミ以下の物付けるならせめて文字長位は格納できる様にしとけって話だな

>>635
UNIXを作ったKen Tompson大先生が1992/09/02に考えた。
http://www.cl.cam.ac.uk/~mgk25/unicode.html#history

�d

UNIX作った人たち天才。

先頭にZERO WIDTH SPACEがあるUTF-8テキストが不正だとは知らなかった
これからはエラーを吐くようにしないと

＞1992/09/02

WinNT3.1って1994年発売だし、UTF-8にしとけば良かったのにね。
なんでUTF-16（だよね？）にしたんだろ。

後からならどうとでも言える典型だなｗ

とは言っても、
言語の変数レベルに侵食する
超巨大な問題＆選択なんだけど。

BeOSとかLinux新ﾃﾞｨｽﾄﾘとかはUTF-8な希ガス。

可変バイトだと文字列処理が遅くなりそうでや
UTF-32がいい

>>646
まさにその理屈で、Windows NTやJavaは16ビットになったんだろ。
まだ当時の欧米人は16ビットで足りると思っていたみたいだからね。

ところで、結合文字列があるから、まじめにテキスト処理しようとすると
UTF-32にしたところでちっとも固定長として扱えない罠。

そこで
UTF-4
でつよ

もとい
UTF-64
でつよ

>>649
3文字以上からなる結合文字列は？

結局いろいろ加味するとUTF8が最強なのかね

結合で全ての文字を表せるとか言い張ったUnicodeは馬鹿の仕様
そんな糞仕様を包括できるUTF-8は神の仕様
基地外のつけたBOMすら許容できる懐の深さは計り知れない

母国語ＥＵＣにサロゲートペア付けた符号化が最強
そう云う意味でラテン文字圏ではUTF-8が最良なのは事実だね

とりあえず、標準では何を使えばいいのか決めてくれ。

バカ言うな。
BOM無しでいったいどうやって ISO8859 と UTF8 を区別できるんや！
ラテン文字市ね！

>>653
その最強様は文字境界問題とか仕様レベルで解決してるの？
可変長だがストリームとして扱えないとかゴミじゃない？

Fの女SE（笑）がUnicodeのこと丸で知らなくて引いたな。

そんなの不実でつ

大丈夫、某芝の言語処理のSEがUTF-8を知らないくらいだから。

つーか、もうユニコードやめて欲しい。

丸投げかと思っていたがUnicode知らなくて困るくらいの仕事はしていたのか

>>660
同意だが、もう�_

サロゲートを埋め尽くした後で、真UTF-32を作ればいいじゃん。

＞真UTF-32

誰も欲しがってない希ガス。

古いメインフレームとかで文字列サイズ計算に有難がられただけで、
ウェブアプリ時代になって、文字列はどれだけでも入れれるのが当たり前で、
１文字長が完全固定ってことが特に要求されない。

不満を並べるだけなら、１５歳少年にだってできる。
建設的な意見、代替案は出せないのか？
ユニコードに代わるものを発案して、規格化して、世界中に普及させろや。
それができないなら、おまいら１５歳少年と同じ。

今その権力を蓄えてる。

>>665
自分は権威にすがるだけの高2病定番レスだなw

何かのブラウザかエディタであたかも無関係なものとしてエンコードリストに載ってるのがあれだね

で？
建設的な意見は？

64bitOSが主流になるとUTF-64とか使われるようになるのかね

リトルインディアンとビッグインディアンは
何が小さくて大きいんだ?

>>670
そんなもん、そもそも定義されていないから。

>>671
お前の家の冷蔵庫に玉子はあるか？
あったら、小一時間ぐらい眺めてみるんだ。

ウチは横からだ

リトルインディアンとビッグインディアン

１６階建てのビルを
右に倒すか
左に倒すか
の違い

×インディアン
○エンディアン

>>675
ミドルエンディアンは?

×アップル
○アポー

×ミドルエンディアンは?
○ミディアムポインターは?

>>677
釣りはいいから。まさかとは思うが、エンディアンとインディアンが同じ単語だと思っていないよね?

>>678
--
ウェブ全体から検索 日本語のページを検索

ウェブ検索ツールを閉じる検索ツールを表示
"ミディアムポインター"との一致はありません。
--
何それ?

＞ミディアムポインター

ファーポインターとニアーポインターの混ざる
リンクライブラリのミディアムモデルってのがあった。

ミドルエンディアンは聞いたことあるし、
タイニー、スモール、コンパクト、ミディアム、ラージ、ヒュージのメモリモデルも
思い出したくない思い出だが、
ミディアムポインターってのは初耳だな。

よく分かってないんだけど

wchar_t str[] = L"日本語";

これってUTF-16なの？

Windowsでは9割9分9厘UTF-16。

ただ、一般にそうとは決まっていない。LinuxとかではUTF-32。
CやC++の標準規格ではそもそもUnicodeであることすら要求していない。

今はどうだか知らないけれど Solaris とかだと wchar_t は
32 bit 表現の EUC だったような。

>>684
そっちはlocale依存なんじゃね?

一文字に16bitしか使わないときのUTF-16の値はUnicodeコードポイントにイコール?

んなもん人に聞くな

確かに。
アイちゃんに問いかけるべきだ

>>682 >>683 >>684 >>685
つまり、標準C/C++でも、Lは規定されてて、
Lの後の文字列はLocaleで決めて下さいね、
って意味？

コンパイラによって違う

なるほど。

でもC/C++の文法的に、Lは存在するわけですね。

> C/C++の文法的に、Lは存在するわけですね。

もちろん。

すべては.NETに文字コードを自動判別するクラスがないのが悪い?

.NETｲﾗﾈ

結局C/C++文法的には、LはLocaleなの？UNICODE指定なの？
人に説明するときのために知っておきたい。

long

ワイドキャラクターなのに Long の L とは。
数値型の int／ling の ling とまぎらわしいよね。
実際、１文字が int 幅なのか long 幅なのかはコンパイラ次第。

�d

Localeと間違えて恥かくとこﾀﾞﾀｗｗｗ

＞ワイドキャラクターなのに Long の L とは。

long型じゃなくて、長いって意味なのね、ｻﾝｸﾂ。
危うく「2バイトだからlong」って新人でも間違えないような事言って疑われるところだったｗｗｗｗｗ

700

このスレッドは７００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

702

utf-8ってアジア圏涙目じゃねーかｗ

なんで東洋のわけわかめな文字を使ってる連中のために俺たちがコストを払う必要が
あるんだよ。一応使えるようにしてあるんだから文句言うな。ヨーロッパの連中？
お前ら同じ文字使えねぇなら少し苦労しろよ。

VHFとかUHFってなに?

まあなポーランドとかスウェーデンのキーボードでC/C++のソースを
打ち込むと涙目なんだってな

俺らが見ると暗号にしか見えないらしい

>>706
ただのトライグラフじゃなくって?

>>705
VeryHighFrequency
UltraHighFrequency

用語おかしいよね。
ELF : Extremely low frequency : 極限に低い周波数
SLF : Super low frequency : 超超低い周波数
ULF : Ultra low frequency : ちょー低い周波数
VLF : Very low frequency : とっても低い周波数
LF : Low Frequency : 低い周波数
MF : Medium Frequency : 中ぐらいの周波数
HF : High Frequency : 高い周波数
VHF : Very High Frequency : とっても高い周波数
UHF : Ultra High Frequency : ちょー高い周波数
SHF : Super High Frequency : 超超高い周波数
EHF ] Extremely High Frequency : 極限に高い周波数

VHFの上にUHFを命名した後、それより上のネーミングに困ってアルファベットの逆順と言うルールを作ったとか。
日本語名がまた揮っていて、HFが短波、以下VHF:超短波、UHF:極超短波、SHF:極極超短波だったり。

PC98のconfigなんとかとオートエグゼドエグゼスなんちゃらは
なんの文字コードでかいたらえんだ?

Shift_JIS

cp932

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その３
『いつもサボってばかりのキャップがウゼえ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★
> 71 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:58:57.28 ID:PVAf+dux0
> >>69
> 大変って言うか
> 毎日、報告されたのを見て、判断して、処理して、完了報告して、以下ループ。
> ちょっとでもミスすると、普段は作業もしてないキャップさんたちがさんざん文句言ってきて
> その言いわけを考えないと、キャップはく奪されたりアカウント凍結されたりするから
>
> 登録されてから一年以上経って、やっといいたいこと言えるようになってきたよ。



----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その１
『アパッチ砲はワシが作った』

http://jbbs.livedoor.jp/bbs/read.cgi/internet/134/1229674638/5062
自分の管理するしたらばで借りた掲示板にて

> 5062 ：自動保守 ◆AOIMAD.NZM [] ：2009/08/16(日) 00:46:29 ID:nQYgq9jg0
> そもそも、アパッチ砲っていうのは、私が指揮官になった時代に私の先輩たちが導入して
> 先輩たちが命名したもの、っていうかまぁ、そういう砲は今まで存在してないから
> 名前つけなくちゃいけないしｗ
>
> ってことで、使っているうちに広まった名前なので、それが正式名称になるんじゃないかと。
>
> http://www.paradisearmy.com/doujin/pasok_apache.htm（俺の先輩が命名）
> http://www.paradisearmy.com/doujin/pasok_hping.htm（俺が命名？）

※注　「アパッチ砲」の正式名称は「Apache Jmeter」で、もちろん自動焼人の先輩が作ったものではありません


----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

ｵｲ俺のコピペ脳、まで読んだ。

こんばんは
と
こんばんわ
どっちが正しくて、その理由がわからん

けふはてふてふがとんでゐるのをみたでせう

今晩は好い夜で御座いますね。

今晩は好い夜で御座いますね。
と
今晩わ好い夜で御座いますね。
どっちが正しくて、その理由がわからん

わ なんて助詞は無い。
後スレ違い。

あるよ。終助詞だけど。

そんな話はしてないわ

時々だけど、「電車は遅れるわ、財布は落とすわ……」の「わ」も「は」にする人を見かける。
あれは間違いなのか、それともそっちもアリなのか、面倒だから調べたことは無いけど。

終助詞だな。精選版日国でも「わ」の項にも載ってる（「は」とも書く、とある）から、
どっちでもいいらしい。
学校じゃ教えない言い回しだから、「学校ではこっちを教えてる」という正解もないな多分。

Char("わ") = Char("は")
ってこと?

ノンノン

> 学校じゃ教えない言い回しだから、「学校ではこっちを教えてる」という正解もないな多分。

文化庁「国語表記の基準」にあるぞ。

UCS-4＝UTF-32 ですか？

ノンノノノン
ノンノノノン
ノンノノノン
ノンノノノン

ELFっとどのくらいのことを言うんだ?

3Hz〜30Hz

jk
っていう文字列がﾜｹﾜｶﾒ

香台->J
ttp://cpatch.org/witchfive/1/J.HTM

保守

このスレ、まとめられてたな。ところで UTF-1 とか UTF-7 って今はどうなったんだっけ？

アンジーとアスキーとシフトジスの違いは?

ああ米内ってあの射殺されたやつかｗ

>>735
UTF-8に抹殺された。

>>640
おかしいな。
コード体系は１９７０年代に僕が考えたものだけど。

１２ビット符号化はオレが先。

もあのスレを見るまでUnicodeとUTF-8を混同してた一人なのでほとんどあのスレからの知識ですが...orz
--------------------
あのスレってどのスレ?

UTF８（BOMなし）が最強。25年はこれで大丈夫。
全世界で一斉に統一汁

もっと行けると思うけどな。
元の文字コード体系が追加で拡張してもついていけるし

100年は行ける。

世界で最も優秀な文字
国際神学大学院大学が主催して、ハングル学会などが後援する第1回世界文字オリンピック[6]でハングルが1位となり、
世界最高の文字と認められた[7]。しかし、韓国で開催される･ハングル学会が後援する･変化の少ない文字を
数年間隔で比較するなど、明らかに合理性に欠けた出来レースだと思われる点が多々存在する。
第2回世界文字オリンピックは、2011年に韓国の釜山で開催予定。

>>742-744
あと100億文字追加しても余裕だよな

万に一つ、もし文字コードが統一されたら、統一の弊害を洗い出す事が
一大研究分野になるだろうな。そしてバベルは崩壊する。

いや、ハングルを廃止して、漢字を康煕字典に統一、
全てを16bitで収めて欲しい

真面目な話、合成済み文字を全部廃止すれば、
表音文字は1プレーンで収まりそう。

まぁ確かに漢字を康煕字典で統一すれば16bitに収まるが...

社会の側の負担が半端ないw

VS併用すれば桶

インバーターってなに?

インバータ（Inverter）とは、直流電力から交流電力を電気的に生成する
電源回路、またはその回路を持つ電力変換装置のことである。
逆変換回路、逆変換装置などとも呼ばれる。インバータと逆の機能を持つ
回路（装置）はコンバータ、または整流器（順変換器）とも言う。

提供: フリー百科事典『ウィキペディア（Wikipedia）』

ﾌｰﾝ

郡と群の違いは?

>>755

スレをまとめとUTF-8ってゆーのは
0をあ
1をい
01をう
11をえ
011をお
111をか
っていう2進と1文字の1対1対応の事なんでしょ?

たしかにそのとおりだが、
それはUnicodeにも言えることだ。
「UnicodeとUTF-8の違い」
の説明にはなってないぞ。

1と01の違いがわからなかった

結局具体的な解説はまだミシュツなんじゃ

お前が理解できないだけだろ。

Unicodeはコード体系
UTF-8は実装
猿でも分かるだろこんなの

実装ってなんだよ実装って。
近頃はエンコーディングも学校じゃ教えないのか。

中学校ならさすがに教えてない

>>763
物凄い馬鹿を晒してるから反省した方がいい

JISとSJISの関係

後者が「シフト符号化表現」とか、(0208:1997)
「Shift_JIS-2004」とかならまだわかる。(0213:2004)

Unicodeは文字集合で世界中から文字や記号を集めた物。
21bitで表現されて、収録可能な文字数は約209万字。(U+0000〜U+10FFFF)

U+0000〜U+10FFFFの範囲の文字を、ビットの並びとしてどう表現するかを決めたのが
符号化形式でいくつかの種類がある。
代表的な物は UTF-7 / UTF-8 / UTF-16 / UTF-32 など。

UTF-8はUnicodeを符号化する為の形式の一つ。
他のUTF-16やUTF-32と異なり、データの並びの順番（エンディアン）が一意に定まる。
ASCIIコードとの互換が高く、従来の文字列処理のやり方で扱いやすい符号化方法。
可変長なので、文章中の文字数をはじき出すには、文字数を数える必要がある。(=データサイズから文字数を求められない)
日本語を表現させるとシフトJISよりサイズが増えてしまうのが泣き所。

>>768
正しいけど>>758や>>760みたいなサルには理解不能だなｗ

今では「Unicode」は文字集合も、それに対するコーディングシステムも、
文字を扱うときの規則も全て含んだ文字コード体系全体を指すことの方が多いのでは?

>>770
そりゃ、「Unicodeとは何か？」って聞かれりゃね。
>>1の質問はそうじゃ無いし。

インディアンがまだ続いてたのか・・・

うそつかない

符号化方式の存在意義が不明

使われる場面が違うと、符号化形式に求められる物も違ってくるって事だな。
あとは歴史的な経緯もある。

最も古いUTF-16は、2オクテット(16bit)を基本として、主要な言語の文字は
その範囲に収まるようにしてある。本当は2オクテット固定長にしたかったのだが、
文字数が足りなくなってしまったので、16bitで表現可能な範囲を超える分については
サロゲートと言ってさらに2オクテット必要とする。
これは「文字コードは16bitあれば十分!」なんて思われていた時代の傷跡。
ちなみにUnicodeが21bitなのはサロゲートで表現可能な上限が21bitだから。
WindowsやJavaの内部文字コードとして採用されたので、普及率が高い。

UTF-7は、7bitでしか通信が行えない古いSMTPサーバー間の
通信路で使われる事を想定されていた。
UTF-16のASCIIコード互換領域以外をbase64で7bitエンコードする物だが、
そんな面倒な事をするならUTF-8あたりをbase64で丸々くるんで使えよって話になった。
ステートフルなので、文章の頭から順に読み込んで行かないとならない。

UTF-8は、1オクテット(8bit)を基本とする物で、最初から1〜4オクテットの可変長。
ASCIIコードを処理しているプログラムと相性が良くて、それが好まれる。
ASCIIコードの範囲ならほぼ1オクテットに収まるが、日本語は殆ど3オクテットになる。
これもHTML/XML標準やMac OS XやLinuxで使われてるので普及率が高い。
可変長なので内部文字コードとして使うには面倒くさい部分もあるが、
バイトの並び順が固定されているので、その分はやりやすい。
何らかのアクシデントでビットが欠落しても文字の境界が分かりやすい利点もある。

UTF-32は、4オクテット(32bit)を基本とする物で、4オクテットの固定長。
32bitとは言っても、そのうち文字の表現に使われるのは21bit。
1文字が絶対に4オクテットなので、文章の保存にはサイズの問題からまず使われない。
文字数は文章サイズを4で割れば求まるかというと、実はそうでも無い。
合成文字や異字体セレクタなどがあると、その目論見は脆くも崩れ去る。
データの境界が常に4オクテット単位であってほしい、メモリ上や、データベース上の内部コード向け。

バカみたいに文字種の増えるハングルを字母だけの収録にすれば16bitで十分収まる
もちろん公平に日本語の濁点やラテン文字の補助符号等もAA方式で組合せ文字にする

スレの表題にあるように単に「UnicodeとUTF-8の違いは？」と聞かれたら、UTF-16とUTF-8の符号化方式の違いを問われてるように感じるんだが。

単に「Unicode」と言えば、UTF-16の事だと受け取る感覚が古いのだろうか？

>>777
その感覚自体がよくわからんのだが、MSどっぷりだとまた違うのだろうか。
>>1のとっかかりってメモ帳の文字コード指定なんだろうし。
# 俺的感覚では「UnicodeつーたらふつーUTF-8だろjk」だったりするが。

>776
漢字は異なる字体を全てひとつのコードで表す事にすれば16bitで収まるのかも知れないが、既に地理的、歴史的事情でいろんな字体が共存してしまってるからな。

「この状況ではこの字体を使う」と言う統一的なルールをつくるのも難しいだろうと思える。

俺の感覚ではUnicodeは何百ページもある巨大な仕様なのに、
ただ単にUnicodeと言えば単一の符号化形式を指してるような
感覚で物を言う奴は分かってないのが多いので信用しない。
こういう奴は、文字集合と符号化形式の区別もついてないのが多い。

UTF-16のリトルエンディアンとUTF-16LEが別物っていうのを最近知ったわ

>778 >780
私がUnicodeと言う言葉を最初に知ったときにはUTF-16しか無かったからね。

そのためつい、単に「Unicode」と言われるとUnicode文字セット UTF-16と同一視してしまう。

>>781
UTF-16も、
　UTF-16LE(リトルエンディアン) ※BOMを付けてはいけない。
　UTF-16BE(ビッグエンディアン)　※BOMを付けてはいけない。
　UTF-16のリトルエンディアン BOM付き
　UTF-16のビッグエンディアン BOM付き
　UTF-16のBOM無し(bit列はUTF-16BEと同じ)
と5種(bit列としては4種)あるからねぇ。

Windowsのメモ帳は、Unicodeの規格には無いBOM付きのUTF-8とかで保存しやがるし。
UTF-8はバイトオーダー固定だからBOMなんか無いってのに、
そんな事をするもんだからUTF-8とかUTF-8Nとか別れちゃうし。
文字コードの世界はややこしい。

※BOMはByte Order Markでエンディアンを明示するためのコードね。

あ、Unicodeの最大収録文字数間違えたわ。申し訳ない。
2^21=約209万字じゃなくて、

サロゲートペアは1024^2の領域で表せられるので、全部で1048576字
これに基本言語面の65536字から、サロゲート用の2048領域を除いた物を加えると、
1048576+(65536-2048)=1112064文字だった。というわけで約111万字だった。

>>776
>もちろん公平に日本語の濁点やラテン文字の補助符号等もAA方式で組合せ文字にする
NFDで既にそうなってるから

すべての文字を画像として扱えばどんな文字でも表現できるのになもうハードも画像ベースで扱えるぐらい進化したし

>786
すべての文字が画像として表現されていて、表示がクソ重いWebページなんて俺は嫌だぞ。

すべてとは言わず極端に頻度の低い異体字なんかを外部参照にして都度ストロークやビットマップで表現するってのはありかも
編集を重ねた文書がクソ重いデータに成るっぽいのはイヤだけど

>>786
馬鹿すぎｗ

>>783

UTF-8のBOMはUnicodeの規格に入ったんじゃなかったっけ？
バイトオーダーを示すBOMとしてではなくて、UTF-8を表すシグネチャーという扱いで

>　UTF-16BE(ビッグエンディアン)　※BOMを付けてはいけない。
>　UTF-16のBOM無し(bit列はUTF-16BEと同じ)
この２つが別なの？？マジワケわかんねぇ……

>>790
この資料によると、UTF-8の際でもsignatureとしてのみBOMを使えるって書いてあるね。
http://unicode.org/faq/utf_bom.html#bom5
Where a BOM is used with UTF-8,
it is only used as an ecoding signature to distinguish UTF-8 from other encodings
? it has nothing to do with byte order.

という事はUTF-8に対応しているって表明しているプログラムの場合、
厳密に解釈するならBOMがあると正常に動作しないような実装は、中途半端って事か。
(BOMを付けるかどうかは選択自由だけど。)

>>791
Unicodeの規格上、符号化方式はUTF-16とUTF-16BEで別の扱いだが、
符号化された結果は同じになるって事。

「オブジェクト」ってなに?

物っぽいナニカ。

物のたとえ

コンパイルしてリンクする前のバイナリ

オブジェクトとインスタンスの違いは？

オブジェクトは広い意味でクラスも含んでる場合があるな
そういう曖昧さを避けるためにまともな本では
クラスとオブジェクトという対比ではなく
クラスとエンティティと表現している
っつーかスレ違いじゃぼけ

すれ違いに続けるのもなんだけど。
>>798
いやいやオブジェクトとエンティティは別物でしょう。
クラスと(クラス)インスタンスって言うと思うけど。

U+FFFCをオブジェクトと略しても通じないと思う

オブジェクトとエンティティが別物じゃないとは誰も言ってないぞ
っつーかスレ違いじゃぼけ

いや別物だといってるんだけど。

スレも別物になってる

>>802
どこ？

ラーメンと野球の違いは？

打球はのびるとうれしいが
ラーメンはのびるとうれしくない

お前どこにでもいるな

808

オブジェクト指向で「エンティティ」と言う言葉はあまり聞いた事が無いなと思ってたら、その関係はなかなか微妙みたいだな。

http://itpro.nikkeibp.co.jp/free/NIP/NIPCOLUMN/20021225/2/

スレ違いを続けてスマソ。

と、エンティティという言葉を覚えたての素人がほざいております

>>804
一昔前に良く話題になったよね。
http://www.google.co.jp/search?q=OOA+DOA+%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88+%E3%82%A8%E3%83%B3%E3%83%86%E3%82%A3%E3%83%86%E3%82%A3&btnG=%E6%A4%9C%E7%B4%A2

>>811
お前馬鹿じゃね？

お前どこにでもいるな

age

たいく
が変換できないんだけどシステムのなにがこわれたのかしら
運動のことなんだけど

>>815
体育の読みは「たいいく」だから。漢字の勉強をやり直す事をお勧めする。

>>815 素で言ってたら相当間抜けだな。素でなくても間抜けだけど。

体躯　であってるんじゃないのかな

っつーかなんでこのすれ

それ運動のことじゃないし

ふいんき

いい加減
文字コードはなんかひとつに統一してくれ
プログラム書く時とかうっとおしいんだよ

あるじゃん。UTF-8が。

せっかく Unicode が使えるようになっても、
今まで使ってきた経験のある EUC-JPを選んでしまう運用管理者が許せない。
お前ら、いつまでも文字コードを乱立させておくつもりかと。

UTF-8以外は廃止して良いと思う

Unicodeの符号化方法が乱立してて余計にややこしい

UTF-8以外は廃止して良いと思う

>>824
内部表現としては使われてるからダメ。

けど、テキストファイルに使うのはUTF-8だけで十分。

>>827
素人

>>828
天才ハッカー

>>829
あらわる！

>>827が無知すぎる
内部表現って何の事を言いたいんだよ

Windows内部ではUTF-16だとかいう話じゃないの。

普通に考えてそうだよなあ。
「内部表現」が何のことか分からないのに>>827が無知って何で言えるんだ？
無知をさらしてるのは>>831だな。>>

>>833
それじゃ話がおかしくなるからあえて聞いてんだよバカ

Windowsに限らずUTF-16を内部で使ってる系はあるみたいだよ。
それよりも何がどう話がおかしくなるのか、示してくれる人はいないのかい？

JavaとかJavaScriptもUTF-16だね。
>>834の説明に期待

834じゃないけど

>>827
内部処理に使われてるから廃止しちゃダメってのは変じゃね？
内部処理だけに使われてるなら別に廃止してもいいと思う
勿論、現実にはそうじゃないから、廃止には反対だけど

プログラマーは内部処理意識してプログラム書かないといけないから困るんじゃね？

個人的にはUCS-4とUTF-8だけでいい。文字aが4バイト取っても構わん。

>>837
> 834じゃないけど
> >>827
> 内部処理に使われてるから廃止しちゃダメってのは変じゃね？
使われているものを廃止するってのが変じゃなくてなんなんだ？データ交換用のエンコーディングと
しては使用しないだけ、ってぇならわかるけど、廃止されたら何を基準にエンコーディングを扱えば
いいんだ？俺様エンコーディング？OSとアプリケーションでエンコーディングの基準が食い違うようじゃ
ダメだろ。

>使われているものを廃止するってのが変じゃなくてなんなんだ？

使われていないものをどうやって廃止するんだ？

でもさ、交換用はすべてUTF-8として、内部表現が「1文字=1キャラクタ」ならOSごとに
文字コード違っても問題なくね？

>840
たとえばUTF-7なんかは使われていないから廃止、とかはありでしょう？

　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>834
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　 　 「 　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　 〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

>>842
バッカじゃねぇの？UTF-7は俺のアプリの内部表現で使われてるからダメに決まってんだろ
この考え方は>>827もお前らも支持している考え方だから、異論は認めん

このスレは「内部表現」の解釈について語るスレとなりました。

>>842
バッカじゃねぇの？
使われてないものはわざわざ廃止しなくても使われてないんだから問題ないんだよ
使ってるものでも廃止して整理した方がいいものは廃止するべきって話をしてるんだが

使われてるからダメとか言ってたら何一つ統合されねーってのに
何得意げに内部表現内部表現言ってんだかな
「内部表現に使われてるからダメ」とか、全く場違いで全然意味が無いって気付けないの？

sumimasenga itteru imiga yokuwakarimasen

起
821 名前：デフォルトの名無しさん[sage] 投稿日：2010/05/03(月) 02:05:08
いい加減
文字コードはなんかひとつに統一してくれ
プログラム書く時とかうっとおしいんだよ

承
824 名前：デフォルトの名無しさん[sage] 投稿日：2010/05/03(月) 12:26:50
UTF-8以外は廃止して良いと思う

転
827 名前：デフォルトの名無しさん[sage] 投稿日：2010/05/03(月) 14:06:01
>>824
内部表現としては使われてるからダメ。

結
バッカじゃねぇの？

やっぱUTF-32とUTF-8以外は廃止だな。

UTF32は合成文字がある時点で固定長足りえないからゴミクズだろ
なら最初から可変長のUTF8の方が統一感がある

それでもサロゲートペアのあるUTF-16よりはまだマシ

いや、マシとか言えるのは日本だからだろ
合成文字が当たり前の国もあるし、エンコード統一の観点からはゴミ

あーもうバカばっか
何が出て来いゴガギーンだよ死ね

で
>内部表現としては使われてるからダメ。
どういうこと？何故ダメなの？使われてたらダメなの？内部表現だとダメなの？>>844て事なの？馬鹿なの？
結局ごく普通の意味で内部表現と言いたかったの？例えば日本向けWindowsのFAT32の内部表現はSJISだし、内部表現にUTF-8が使われてるOS等の環境もあるんだけど？
それらを一緒くたに引き合いに出して何の話がしたかったの？たかが内部表現をどこまで特別視してるの？

そもそも「色々使われててウザイから統一してくれ」と言う話題に「使われてるからダメ」と答えることの間抜けさを認識出来るだけの脳みそは持ち合わせてないの？

ゐゑ

>>854
みなまで言わないと分からないのか。そんなに極論が好きなのか。面倒くさい奴を相手してしまった。
そんなに頻繁に代行スレ使うのやだから、規制解除されるまではもう聞かれても答えないよ。

UTF-16はUnicodeと互換性があって内部表現としてそれなりに使いやすい(実装例も多い。数例あるとかそういう話をしているのではない)。
それを規格として保守しておいて、常にUnicode文字集合と対応付けられるのは大きな利点。

内部表現だからといってオレオレエンコーディングの使用は苦労に比べて利点がないし、
まともな設計のソフトウェアなら内部表現にも規格化された表現を使うが、そのときUTF-8よりもUTF-16の方が使いやすいことが多々ある(だからこそ、実装例が多い)
それが、UTF-16を規格に残しておく意義。

>>824には「色々使われてて」のくだりはないし、少し前あたりにもUTF-16を廃止する意義のあるレスは見られない。
君が勝手に話題だと妄想してただけ。

代行レスってお願いする物じゃなくて、使うものだったのかｗ

>>854
>>826が「UTF-8以外は廃止して良い」とかいうから、
>>827は、UTF-8以外の文字コードでもシステム内部で使われてる
文字コード（UTF-16など）があるから
UTF-8を除く全廃は駄目だと言ってるんだろ。
Unicodeがどうこういう前に日本語が理解できないんだな。

ああ、こう書いたらUTF-8も含めて全廃しろって意味に取られるかな？　馬鹿には。

>>858
おいおい･･･果てしないバカだな

>>821が「色々使われててウザイから統一してくれ」
で
>>824が「統一するならUTF-8」という主張だわな

お前の妄想ではこの話題は>>824から始まっていたわけな
もう何も言えんわ

>>856
お前の言いたい事って結局「UTF-8以外も広く使われてるから廃止は難しい」って事でしょ？
んなもん誰でもわかってんだよアホｗ

Unicodeの糞さは最早どうしようもない
では諸問題を含め、統一された場合を仮定し、どの符号化方式が一番優れていると言えるかを語ろうか
俺はサロゲートペアをデコードしたUTF-8を推す
当然BOM無し

>861
UTF-16のサロゲートをそのままエンコードしたらUTF-8とはいわんと思うが？
個人的には統一するならUTF-32で。

そうだよなあ……。
文字ごとにバイト数が違うなんて面倒くさすぎてやってられるかと。

URL符号化を弄ってるともう何でもいいんじゃね？とアキラメの気持ちが

>>862
サロゲートをそのままエンコードしない素のUTF-8だっての

>>863
Unicodeである限り文字毎にバイト数は違う
バグ突っ込む無能乙

>865
だからそれ以外のものはUTF-8っていわんだろ、って話。まさか
> UTF-16のサロゲートをそのままエンコードした
ものまでUTF-8と呼ぶのか？

UTF-32って1文字の区切りはどうやって判断するんでしょうか?
シフトJISとかEUCなら簡単に1文字が判断できますけど。

>>866
うるせえよ馬鹿
UTF-8の派生がいくつかあんだろ
務めて明確に言っただけだよ

1MBのUTF32バイトストリームの481211バイト目から得る事が出来ました。
文字境界はどうやって求めますか？ここは何文字目か分かりますか？

>867
単純に4バイト境界。ただし区別されるのは文字ではなく要素。

>>862
100GBのログファイルが400GBになるとかカンベンｗ

一定量のコードポイントがいくつの文字図形になるかは、
フォント依存だから、「何文字」なんてのは決めつけられない。

例えばU+30ab, U+309aという並びは、最近のフォントなら
「半濁点付きのカ」という一つの文字図形に置き換えられるだろうけど、
古いフォントだと「カ」＋豆腐という二つの文字図形になる、というように。

それじゃ現実的なニーズから言うと話にならないんだよね

理論上の文字境界は、UnicodeData.txtで属性を見れば分かる
それが表示上何文字になるかはフォント次第

→SJISでいいよもう

SJISいらねー。
文字列先頭からスキャンしないと文字境界わからないし、
2バイト目が処理系のメタキャラクタと衝突して酷い目に遭うし、
ベンダ拡張の文字使われると環境によって出る文字が違うし、
ろくでもねー。
まー、UTF-8に欠陥がないかというとそんなことは全然ないわけだが、
少なくとも上記の問題が解消される分、我慢できないこともない。

EUCも半角カタカナ混ぜるとおかしくなったりするからな
JISが最強言われた時代もあったが
UTF-8ですっきりしたな
日本人が文字コードでいがみあってる間に
毛唐にいいところもって行かれたよねw

UTF-8には欠陥は無いが、Unicodeがもうどうしようもない

>>876
Unicodeなんか 文字の境界もよくわからんですよ

クワティーはなんでクワティー?

>>876
キミ、素人だね

合成文字って、1文字目を見ただけじゃ合成文字かどうか判断つかなかったり、次の文字が
来ないと合成文字の終わりがわかんないのって、何でこんな仕様になってんのかな

発想を変えて自然言語のほうを1つに統一するのはどう？

あっという間に方言ができまくって結局バラバラになるんじゃない？
バベルの塔みたいの作ってるやつらもいるしな

エスペラント語のこと？

>>882
Unicode用語の使い方が間違ってるぞ。

誤：合成文字
正：結合文字

マイナー言語は年々滅んでいってるらしいし、いつか統一言語になるんじゃね

英語と日本語と中国語が統一されるにはあと50年はかかるだろ

何か言語が滅びても記録に残す必要とか研究する必要はでてくるから結局Unicodeはどんどん脹らむ（w

UTF-32が可変長でもいいから、サロゲートペアのUTF-16は今すぐ死んで欲すぃ

>>877
Ken Thompsonすごすぎ。
単純なアイデアの組合わせにすぎないんだが…

>>887
手話の研究により、そのような考えは完全に否定されている。

UTF-8 は 7bit クリーンじゃないし、EUCとSJISの半角カナの相性が悪いのは、
どちらに責任があるわけでもない。

別にUTF-8がたいして優れてるわけじゃない。ワードアライン取れないし。

じゃあUTF-7で

>>891
話が分かる人が居て良かったｗ

TRONコードってどうなの？

>>893
今時7bitって、、じゃあISO-2022でも使ってな。

> EUCとSJISの半角カナの相性が悪いのは
相性悪いってのは判別がつかないってこと?
文字コードに関するのメタ情報無しで読もうとすること自体問題だと思うけど。

>ワードアライン取れないし。
何で取る必要があるのかな?　まあUTF-32でも使ってな

どう考えても
UTF-8 >> その他の文字コード > Unicode　だろ

UTF-8 >> EUC > JIS > その他の文字コード > Unicode > TRONコード > SJIS

並存してる時点でEUCもかなりの糞
UTF-8 >> その他の文字コード
これは揺るがない
今時7bitとか言ってる奴は流石に馬鹿

7-bitっていったらエロ画像もエロ動画も見れないじゃないか！

エロサイトさんの思うとおりにはさせないぜ。

日本語しか扱わないシフトJISと多国語を扱えるJISを同列に扱うのは如何な物か

UTF-7があるじゃない

そろそろメールもUTF-8にしたいな。仕事で中国とやりとりするとき便利。

UTF-8でいいんじゃない。base64かQuoted-printableすればSMTPへ流しても安全。

いい加減、8ビット転送も許可するSMTPの拡張って出て来ないかな。

SMTPはテキストベースなんだから、
非対応なサーバを通るときだけBase64/Quoted-printableへ変換すれば良さそうな気がするけど。

>>906
まさにそれを行う、ESMTPってのがあるよ。
http://www.wdic.org/w/WDIC/ESMTP

>>906
RFC1426 - SMTP Service Extension for 8bit-MIMEtransport
『February 1993』

ちなみに1652でobsoleteされている。

拡張版でサポートされても元のhttp://www.ietf.org/rfc/rfc2821.txtで
8ビット保証されてないから意味ない。あと俺の会社ではUTF-8が文字化けする
糞メールソフトが標準になっている

糞メールソフトを使い続ける企業は消えても問題無い。

デフォをUTF-8にしないとどんなメーラでもバケバケ

UTF-8は使えない糞コードってことでOK？

インタネットエクスプロラでEUCのホームペジをソース表示するとメモ超がぐちゃグチャになるのはなんとかならんの

板違い

>>913
メモ帳以外を使う

メモ帳が文字コード自動認識しないのはEU対策かな？

世界中の文字コードの自動判別は結構大変

windows SDKのCLでコメントにutf-8、unix式改行コードを使ってたらバグった。
初期設定
の次の行の変数定義が飛んだ。
utf-8でもMS-DOS式の改行にすると通る。
utf-8も文字列の最後が\になる問題あったっけ？

>>918
最後の文字のUTF-8での最後のバイトがSJISの1バイト目とみなされて、
次の改行コードがSJISの2バイト目として消費されたんじゃね?

>>919
ああ、その可能性があるか。
linuxとwindowsでコードを共通化するのは色々面倒くさいなぁ。

>>920
//形式のコメントじゃなくて/**/形式使う。*/の前には半角スペースを少なくとも1個入れる。
これで大抵いけるんじゃないかなぁ。

それか、日本語は行末に句読点をいれることにしてもやっぱダメな場合ってある？

Visual C++10で普通に動いたけど？
ソースきぼん

まさかBOM無しにしてる？　そりゃダメだよ

>utf-8も文字列の最後が\になる問題あったっけ？
無い。(Unicode規格3.9より)

>>922
正確には
//OpenCLの初期設定
だったかな。
日本語のコメント面倒くさいから消したのでもうわからん。

UTF-8だと行の前の空白とかでもなにか変わったっけ？

あと、windows SDK v6.1のCLでダメだったんだが、VC++10だとUTF-8対応しているのかも

Visual C++がUTF-8対応したのは確か2005(VC8)から。2008(VC9)もOKだった。
SDK v6.1ってのはいつの時代のだ？

>>926
いつのだろ？
2008 server 64bit版用のSDKを取ってきたらこれが入ったはずだが。
versionは15.00.21022.08 for x64

この次のPlatform SDKは今のwindows 7用だと思うので、最新の一つ前。
多分、2008 Expressを64bit化しようとして当時の最新版を入れたから2008の世代だと思うけど。

>>923
meadowで作ったUTF-8だけど何か入るのかな。

BOM有りUTF-8(LF)で別に文字化けしないな。Visual C++ 2008(cl /EHsc)


#include <cstdio>//OpenCLの初期設定

#include <vector>//OpenCLの初期設定


int main()//OpenCLの初期設定

{//OpenCLの初期設定

　　std::printf("aaかきく\n"//OpenCLの初期設定

　　　　);

　　std::printf("aaさしす\n");//OpenCLの初期設定

　　fgetc(stdin);//OpenCLの初期設定

}

>>929
改行がLF(unix風）の時だよ。
CRLFだとバグらない。（多分CRが犠牲になってくれていると思う）

わかってるさ。これで試して　↓
http://www.dotup.org/uploda/www.dotup.org903315.cpp.html
リンクを右クリックで保存。

>>931
utf.cpp: warning C4819: The file contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss
utf.cpp(3): error C2143: syntax error: missing ';' before 'printf'
あとは連鎖的にエラー

残念ながら君が使ってるcl.exeは古いようださようなら

ああ、すまん
/EHscをつけたら、
warning　C4819　...
までは一緒だがコンパイルは通った。
実行すると（画面じゃグチャグジャなのでリダイレクトしてemacsで見る）出力は

aaかきく\naaさしす\n

\nは改行じゃなくて\nという文字で。

「15.00.21022.08 for x64」ってVC9だろ。メッセージ英語だし何か間違ってるんじゃね？
あとLinuxならG++だろうから、そんなBOMも扱えない糞は窓から捨てるか、おとなしく
EUCに文字コード変換でもしてな

"の初期設定\n"はutf-8で
e3 81 ae e5 88 9d e6 9c 9f e8 a8 ad e5 ae 9a 0a
なわけだけど、これをsjisで解釈すると
縺ョ蛻晄悄險ュ螳
になって、改行文字食われるね。

何でBOM付いてるテキストをシフトJISで解釈しようとするのかわからんな。
保存の時にBOM削ってんじゃねーの？ utf.cppうぷしてみ

>utf.cpp(3): error C2143: syntax error: missing ';' before 'printf'
3行目ってことは間違いなく改行コードが食われてるな

>>937
>>931にあるよ。
そもそもエンコードの自動判別をする気が一切なければ、
BOM付いててもsjisで解釈しようとするんじゃないの？

そもそもボムッてなに?

BOMはバイトオーダーマークのことで
本来はUTF-16のバイト並びがビッグエンディアンかリトルエンディアンかを
区別するために付ける最初の1文字。
バイトオーダーなので本来はUTF-8には必要無いが、UTF-8であることを
区別するために、UTF-16のBOMをそのままUTF-8にしたものが使用される

ちなみにUTF-8にBOMつけた場合の、BOMの呼び名はsignatureとなる

むずかしす

一応整理しておく。

BOMってのはByte Order Markの事でUTF-16やUTF-32ではバイトオーダを表す。
UTF-8では、UTF-8をASCIIと区別する為のUnicode signatureとして扱われる。

BOMのコードポイントはU+FEFF

これを各符号化形式に変換すると、
UTF-8のUnicode signatureはEF BB BF
UTF-16のビッグエンディアンはFE FF
UTF-16のリトルエンディアンはFF FE
UTF-32のビッグエンディアンは00 00 FE FF
UTF-32のリトルエンディアンはFF FE 00 00
となる。

lol

>>941
>ちなみにUTF-8にBOMつけた場合の、BOMの呼び名はsignatureとなる
Unicode規格のどこにそんなこと書いてあった？

>>945
日本限定の糞ローカルルールだからないよ

>>945
http://unicode.org/faq/utf_bom.html#bom5

>>946
日本限定じゃないよW3Cだって使ってる。
http://www.w3.org/International/questions/qa-utf8-bom.en.php

>>947
書いてねーじゃん。2章読んでも16章読んでもそんな記述は見当たらないんだが

>>949
Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)?
　　If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?

A: Yes, UTF-8 can contain a BOM.
　　However, it makes no difference as to the endianness of the byte stream.
　　UTF-8 always has the same byte order. An initial BOM is only used as a signature
　　 ? an indication that an otherwise unmarked text file is in UTF-8.
　　Note that some recipients of UTF-8 encoded data do not expect a BOM.
　　Where UTF-8 is used transparently in 8-bit environments,
　　the use of a BOM will interfere with any protocol or file format that expects specific
　　ASCII characters at the beginning, such as the use of "#!" of at the beginning of Unix shell scripts. [AF] & [MD]

>>950
だからどこに「BOMの呼び名はsignatureとなる」って書いてあるんだよ？

>>950
あぁ、呼び名じゃないな、役割だったね。

細かい揚げ足取りだな。
どっちみちUTF-8でBOMは
仕様書的にもありなんじゃん。

無いって言いたかったんじゃないの？
ただ呼び方に文句つけてただけ？

これ見ると下手な食事療法とかダイエットよりも効果あったよ。
http://www.petatv.com/tvpopup/video.asp?video=agri_long&Player=wm&speed=_med

ちゃんとRFC3629にも出てくるよ。

Network Working Group F. Yergeau
Request for Comments: 3629 Alis Technologies
STD: 63 November 2003
Obsoletes: 2279
Category: Standards Track

UTF-8, a transformation format of ISO 10646

6. Byte order mark (BOM)

The UCS character U+FEFF "ZERO WIDTH NO-BREAK SPACE" is also known
informally as "BYTE ORDER MARK" (abbreviated "BOM"). This character
can be used as a genuine "ZERO WIDTH NO-BREAK SPACE" within text, but
the BOM name hints at a second possible usage of the character: to
prepend a U+FEFF character to a stream of UCS characters as a
"signature". A receiver of such a serialized stream may then use the
initial character as a hint that the stream consists of UCS
characters and also to recognize which UCS encoding is involved and,
with encodings having a multi-octet encoding unit, as a way to
recognize the serialization order of the octets. UTF-8 having a
single-octet encoding unit, this last function is useless and the BOM
will always appear as the octet sequence EF BB BF.

prependなんて単語はじめて知った。

揚げ足取りとか言われたようだが、
「UTF-8にBOMつけた場合の、BOMの呼び名はsignatureとなる 」
ってことは、UTF-8について語る時は「BOM」という用語を使っちゃいけないってことだろ。
んなわけあるかって言いたかったんだよ。
プログラマーなら仕様は絶対。用語はきちんとしてくれないと困る。

正確な用語が重要なのは分かるけど
UTF-8のsignatureって言うよりUTF-8のBOMって言った方が通りがよさそう

UTF-8にBOMつけた場合の、BOMの扱いはsignatureとなる

技術英語さえまともに読めないのか。

>959
BOMはシグネチャとして扱われる、のほうがいいかも。

pythonにてプログラム勉強してるんですが
utf-8BOM無しで統一しているつもりなんですが　u'一'　（漢数字の一）がエラー解説の時にu'荳?'と出ます（実行には正常に出力されます）
これはunicodeとutf8を理解していないことによる何らかの弊害なのでしょうか
よろしくおねがいします

pythonスレでやれ

>>963
スレチと言われコチラに誘導されたもので

>>964
こっちでやる方が遥かにスレチ
失せろ

まずはバイトオーダーとシグナツレについて解説ｼﾙ

ここでのシグネチャは単にしるしという意味かな
バイトオーダーはCPUによって変わる、
ワード以上のデータがメモリ上でどういう配置になるかということ
だいたいビッグエンディアンかリトルエンディアンかの2通り
てこれはググればすむかと

UTF-8ではエンディアンの影響を受けずOctetの順序は不変なのでByte Order Markとして機能しない

>>962
>エラー解説の時に
をもっと具体的に。

あと、setdefaultencoding とか弄ってないよな？
アレを弄ることで本来出るべきエラーを隠したら、エラーにならず文字化けして問題が何処にあるのか
発見が難しくなる。

>>969
Traceback (most recent call last):
File "C:\Python26\test\test04.py", line 8, in <module>
print b.index(u'荳?')
ValueError: list.index(x): x not in list

setdefaultencoding はいじってません
環境はwindowsXP python2.6です
以後向こうで聞きます。お騒がせしました

結局UnicodeとUTF-8の違いは何なのでしょうか。
符号化文字集合Unicodeにも各文字に符号が振られているのに
さらにUTF-8が符号化方式とかわけわかりません。

Unicodeは文字に番号を振っているだけ。ビットもバイトも関係ない。
そのUnicode番号を、バイト(正確にはオクテット)データの連続として
表現する方法の一つがUTF-8。

Unicode: 単なる「文字の表」で、あいうえお表のようなもの。
　　　　　　便利にするために、文字ごとに番号がついてあるけど、
　　　　　　その番号はコンピュータ上のデータとは何ら関係がない。単なる整理番号。

UTF-8, UTF-16など: Unicodeの表にある文字をコンピュータ上で表現したいとき、
　　　　　　どういう手順で表せばいいかを定めた「決まりごと」。
　　　　　　Unicode表の文字をコンピュータ上のデータに変換する規則、
　　　　　　コンピュータ上のデータをUnicode表の文字に変換する規則が定められている。

Unicode系の規格では「文字の表」と「決まりごと」が一組そろってはじめて、文字とデータの対応付けができる。
ASCIIコードでは、表と決まりごとの区別はあんまり明確じゃない。

Shift_JIS, iso-2022-jp, euc-jpは全部「決まりごと」で、やっぱり「文字の表」がないと意味をなさない。
そいつらはUnicode表じゃなくて、JISコードって表のための決まりごと。

でも「JISコードで保存」とか言うじゃん。何ソレ？

VB6ではEUCもShiftJisも自動で一旦UTF16インディアン付きに変換してるってこと?

>>974
その場合のJISコードとはiso-2022-jpのこと。

>>975
VB6の動作は知らないが、インディアン付きってなんだw
BOM付きか、リトルエンディアンかどっちかの勘違いだと思うけど。

エンディアン: ガリバー旅行記に出てくる、卵を尖った方から割る種族、丸い方から割る種族に由来。
　　　　データの格納順序。例えば、16ビットデータ0xFEFFを表すとき、
　　　　FE FFのように、桁の大きい方から表すのがビッグエンディアン
　　　　FF FEのように、8ビットずつ区切って桁の小さい方から表すのがリトルエンディアン

　　　　CPUによって、どっちがやりやすいかはある程度決まってくる。
　　　　例えばx86系(パーソナルコンピュータのCPUは全部これ、と思っても特に差し支えない)は
　　　　リトルエンディアンなCPUなので、何も考えずにUTF-16テキストを作るとリトルエンディアンになる。

BOM(Byte Order Mark): ユニコード表のU+FEFFの文字のこと。
　　　　UTF-16で、この文字を頭に入れておくと、あら不思議。エンディアン(バイトの並び順=Byte Order)が分かっちゃう。
　　　　より具体的には、UTF-16でU+FEFFは0xFEFFなので、
　　　　これがFE FFのように入っていたらビッグエンディアン、FF FEのように入っていたらリトルエンディアン。

　　　　UTF-8には、エンディアンの違いはないので、Byte Orderを示す必要がない。
　　　　けれども、これが頭に入ってたらUTF-8だって判別しやすいよね、ということでsignature(しるし)として
　　　　入れることが認められている。

＞これがFE FFのように入っていたらビッグエンディアン、FF FEのように入っていたらリトルエンディアン

つーか、何も考えずにワードで読んで0xFEFFなら変換不要0xFFFEなら必要、でいいじゃない

>>978
実装のときはそれでいいとも思ったが、めんどくさかったので書かなかった。
x86の説明入れてるの見て分かる通り、なんでム板にいるの？ってくらいの人を対象に書いた。

揚げ足取り

最後にスレタイの質問が解決したということで埋め

ずいぶんかかったなｗ

>>978
非対称で気持ち悪い。処理速度も測定限界不能な位にしか変わらんだろ。
あとデータが奇数アライメントで配置されてたらどうするつもりだ？

>>977
>>CPUによって、どっちがやりやすいかはある程度決まってくる。
えっ、ビットとバイトを逆にする変なのがビッグエンディアンで、統一性のあるのが
リトルエンディアンじゃないの？　やりやすさの問題じゃないと思うけど。

ストリームでもテキストファイルでもメモリアクセスでもIOアクセスでもリトルエンディアンが有利
ビックリエンディアンはありえない

ハードウェアの進化したいまではなんでもビッグでやっちゃえばいいんじゃないの
大きい集合は小さい集合を含む

両対応で変換命令も含むのが最近じゃ多くない?

>>977
> FE FFのように、桁の大きい方から表すのがビッグエンディアン
> FF FEのように、8ビットずつ区切って桁の小さい方から表すのがリトルエンディアン
それは文字を左から右に書く場合だろ。右から左に書けばリトルエンディアンが
如何に優れているかよくわかる。

そもそも、ビット列のときは下から0, 1, 2, ...と番号をふるのに、バイト列になると上位桁からアドレスの若い順に並べようというビッグエンディアンの発想はキモい。

> ガリバー旅行記に出てくる、卵を尖った方から割る種族、丸い方から割る種族に由来。

と書いたが、その2つの種族はお互いをキモい、変だと言い合って長年戦争してる。
ガリバー旅行記は風刺小説で、そういう些細なことが大きな争いに発展することを風刺してる。

それを引用した上で、改めてその対立を実写化するとは大したやつらだぜ…

>>983
>処理速度も測定限界不能な位にしか変わらんだろ。
には同意するが、>>978の方法で読めなかったらエンディアンを判定してから読む方法でも読めないよ。

>えっ、ビットとバイトを逆にする変なのがビッグエンディアンで、統一性のあるのが
>リトルエンディアンじゃないの？　やりやすさの問題じゃないと思うけど。

ビットとバイトを逆にする、の意味が分からんが、どっちにせよ、それは一般的に認められた意見とは言い難い気がする。
与えられたCPUを使う以上は、やりやすさは大いに関係がある。どっちでも変わらないのであれば、好きな方を使えばいいが。

32bitで1を書き込んで同じアドレスを8bitで読んでも
16bitで読んでも1が読めるのがリトルエンディアン。
32bitで1を書いて16進ダンプすると
8bitでダンプしても16bitでダンプしても
00000001になるのがビッグエンディアン。
アセンブラレベルだとビッグエンディアン
高級言語レベルだとリトルエンディアンの方がわかりやすい。

＞＞９８４
ぎゃくじゃないか

マップドIOとポートIOの違いから派生してるわけで
今時マップドIOだけで動いてるMPUなんて無いんだからリトルエンディアンに統一してしまえばいいのに

5

統一っていったところで、x86はリトルエンディアンでTCP/IPはビッグエンディアン。今更どうにも。
そして、リトルエンディアン・ビッグエンディアンって呼び方はこういう、くだらない論争を揶揄したもの。
先人たちが散々不毛な論争を続けた結果、こいつらをそう呼ぶことになったわけだ。

ビッグエンディアンは非ワードアクセス時に
バイトレーン切り替え必須でハード的に不利。

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

>えっ、ビットとバイトを逆にする変なのがビッグエンディアンで、統一性のあるのが

上位ビットが上位アドレスに書かれるのがリトルエンディアン。
上位ビットが下位アドレスに書かれるのがビッグエンディアン。

今年の流行語大賞決定
「隠してないで土地を出せ」

【口蹄疫】赤松「隠してないで土地を出せ」(本音が出ちゃった)
http://www.nicovideo.jp/watch/sm10843509

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。