UnicodeとUTF-8の違いは? その2
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん
2010/11/30(火) 09:00:05frt -c -Am -M./ (なんとか.f90)
でいけるのではなかろうか。いずれにせよ、
frt -help | less
とかやって、"module"で検索を掛けるのが吉。
0002デフォルトの名無しさん
2010/11/30(火) 10:52:070003デフォルトの名無しさん
2010/11/30(火) 13:18:27言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0004デフォルトの名無しさん
2010/12/09(木) 09:43:390005デフォルトの名無しさん
2010/12/09(木) 16:52:06| / ,.-――┴- 、 .|
| 以下 / | /: : l、: : : ;l: : : : :\. .|
| イカペディア創設者 / :! ./: : :、: :!_\;/ _V\ : |` |
| イカ娘からの 〈 ___V: : : :|∧| __`|∨ |
| メッセージをお読みください ` ̄丁 |: |:l :| __ 〃⌒V| |
| ヽ|: NV:!〃⌒__ //}| |
| /: :{_|: :|//f´ ヽ} 八 |
| _/: :/:/ : ト .丶___,ノイ\_:\. |
| __,/: :_;/: /,.イ⌒ヽ!ヽ: ト、\ !: |__ |
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
0006デフォルトの名無しさん
2010/12/15(水) 07:54:00/ \` 、
/ ___ \ \ 人類よ、よく聞け!
// . ´: : : : : : : :` 、 ヽ \ 今からこのスレを
/ / ./: : : : : : : : : : : : : : : \i: 〉 人類侵略の拠点に
/ / / : : : : : : : : : : : 八: : : : : : :ヽ./ させていただくでゲソ
. / :i/: : : :\: __: : : : :-/―}ハ‐ : : : : : i __
〈 /: : : : : /\: : : : / ,x≠ミx、: :∧| / }
\i: : : : :/ |:| \:/ んィハ }}V:|):{ ./ /
|: : : : : : ト| 弋ぅり {: :、: \__/ /__ ,. ┐
∨\: : :| ,x≠ , ハ: : \:__:/ /: : : : : :`ン'’ ノ
\|ヘ〃 r  ̄} /: : \:_____/ /´ ̄ ̄/ / \
/ : : ∧ \ __ノ/L.,ィ'⌒ヽ:_/ /: ̄`ン' / ヽ: : : :!
/: : :〃: :,>ー;‐┬ ´ /{{ /:/ ハ:>'´ /、 j: : : |
___,/: ://: : :{ 〃 八 / ∨/ /ヽ: : ', /: : :/
/ : : : : : : ://: : :,ハ {{ |\ __/ V:f '⌒ヽ }: :| \: :\
/ : :/´ ̄ ̄/ : : / j : ヽ}}:! / |: | { / /},: : / _/: : /
{: : :{ / />くつ/: : : :リ '. / / :! : 、 V´ ̄ ,.イ/ : / | : : : :|
、: : 、 |:{ r_〉}ヽ: : :{ ∨ \: \ \― ´ /' : 〈 ! : : : : |
\: :\ 、:\__): }\:、 ` ┬ヽ._}=一'´ 〉: : 〉 ! : : : : |
0007デフォルトの名無しさん
2010/12/16(木) 08:43:29BOMの扱いが決定不可能な問題について質問と言う形で出す
↓
変な子が、ファイルサイズと文字長は違うよと言ってくる
↓
知ってると返す
↓
変な子が、人が扱う文字長とプログラムで扱う文字長は違うと言ってくる
↓
知ってると返す
↓
変な子が、いやおれの中では文字長と言えばこう定義されてるし別物なんだよと言ってくる
↓
だから、そんな話はしていないからもうレスしなくていいよと返す
↓
変な子が、人が扱う文字長とプログラムで扱う文字長は違うんだよ!昔からの当たり前の話だろうと言ってくる
↓
開いた口がふさがらない
↓
変な子が、コンピュータ処理で言う1文字と人が認識する1文字とは違うんじゃないのと、また繰り返してる
↓
もうやだこの馬鹿 ←いまここ
0008デフォルトの名無しさん
2010/12/16(木) 17:04:23ビッグインディアンとかなんとかかんとか
0009デフォルトの名無しさん
2010/12/17(金) 19:47:50このスレッドは高次機能障害をもたらす
病理の臨床実験のために立てたものです。
被験者と研究員のやり取りに使うため、
書き込み等は自重されるようお願いいたします。
もし、書き込み等をすることで不愉快な思いをされましても、
当研究所は責を負いかねます。
(社)京都微生物研究所
0010デフォルトの名無しさん
2010/12/17(金) 22:09:58/ ,.- ┴- 、
/.| /:´ : : : : : : : :ヽ
. / :! i{: : : :/\;/ V }: :ゝ
〈.__V l:l:V-‐ ´ ‐ ,'l:/ <人間ども、昔ETという映画があったことを知らなイカ?
. ヽ|: l: l、 ヮ_.ノ:l <ETという宇宙人によって地球が侵略される話でゲソ
. _/:/`,}:`ス/ ̄ ̄ ̄ ̄/ <そして、次の瞬間、貴様はキーボードのEとTを見て驚愕するでゲソー
/: : :(__::::つ/ FMV / カタカタ
.. ̄ ̄ ̄ ̄ ̄\/____/ ̄ ̄
0011デフォルトの名無しさん
2010/12/17(金) 22:39:28目の前にキーボードが2台並んでいるのだが……
0012デフォルトの名無しさん
2010/12/17(金) 22:45:23Rと言えば思い出すのは
そう
Ruby
0013デフォルトの名無しさん
2010/12/18(土) 08:07:40前スレでなんとなくわかったのですが、インディアンがどうとかいうあたりで
話について行けなくなりました。
2 名前:デフォルトの名無しさん [sage]: 2010/05/27(木) 14:20:27
次スレいるのかよw
0014デフォルトの名無しさん
2010/12/18(土) 08:08:41おかしい人は相手をせず放置するのがいちばんですよ。
でもここはおかしい人隔離スレかw
0015デフォルトの名無しさん
2010/12/18(土) 08:09:23>>164
文字コードと改行コードの話はキチガイ信者が集まるものだよ。
ネットニュースのうさげの時代からずっと。
そんな人達の隔離スレがここゆっくりしていってね
0016デフォルトの名無しさん
2010/12/19(日) 12:42:030017デフォルトの名無しさん
2010/12/19(日) 13:44:380018デフォルトの名無しさん
2010/12/19(日) 21:31:420019デフォルトの名無しさん
2010/12/20(月) 08:57:56結局UnicodeとUTF-8の違いは何なのでしょうか。
符号化文字集合Unicodeにも各文字に符号が振られているのに
さらにUTF-8が符号化方式とかわけわかりません。
972 名前:デフォルトの名無しさん [sage]: 2010/05/24(月) 20:15:38
Unicodeは文字に番号を振っているだけ。ビットもバイトも関係ない。
そのUnicode番号を、バイト(正確にはオクテット)データの連続として
表現する方法の一つがUTF-8。
973 名前:デフォルトの名無しさん [sage]: 2010/05/24(月) 22:06:07
Unicode: 単なる「文字の表」で、あいうえお表のようなもの。
便利にするために、文字ごとに番号がついてあるけど、
その番号はコンピュータ上のデータとは何ら関係がない。単なる整理番号。
UTF-8, UTF-16など: Unicodeの表にある文字をコンピュータ上で表現したいとき、
どういう手順で表せばいいかを定めた「決まりごと」。
Unicode表の文字をコンピュータ上のデータに変換する規則、
コンピュータ上のデータをUnicode表の文字に変換する規則が定められている。
Unicode系の規格では「文字の表」と「決まりごと」が一組そろってはじめて、文字とデータの対応付けができる。
ASCIIコードでは、表と決まりごとの区別はあんまり明確じゃない。
Shift_JIS, iso-2022-jp, euc-jpは全部「決まりごと」で、やっぱり「文字の表」がないと意味をなさない。
そいつらはUnicode表じゃなくて、JISコードって表のための決まりごと。
0020デフォルトの名無しさん
2010/12/20(月) 08:59:50>>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(しるし)として
入れることが認められている。
0021デフォルトの名無しさん
2010/12/25(土) 22:49:24本スレ>>1です。紛らわしいスレを立てないでください。
とはいえ、本スレが埋まったらまたここに来ますです。
0022デフォルトの名無しさん
2011/01/01(土) 13:32:38メモ帳がそうだ
0023デフォルトの名無しさん
2011/01/18(火) 17:52:43区点コードとシフトJISコードの違いは何でしょうか。
0024デフォルトの名無しさん
2011/01/18(火) 17:54:39>Unicode は 16 ビットの文字セットで、すべての言語に対する十分な表現能力を持っています。
>すべての ASCII 文字は、拡張文字として Unicode の中に含まれます。
WindowsにおけるUnicode(の文字符号化方式)とはUTF-16(またはUCS-2)の意味。
>このドキュメントでは、MBCS は、Unicode でサポートされていないすべてのマルチバイト文字を指します。
>Visual C++ では、MBCS は常に DBCS を意味します。 2 バイトを超える文字セットはサポートされていません。
WindowsにおいてはUnicodeがUTF-16(またはUSC-2)の意味なので
UTF-7やUTF-8はサポートされない。
http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx
>1200 utf-16 Unicode UTF-16, little endian byte order (BMP of ISO 10646); available only to managed applications
コードページ1200(UTF-16)はネイティブなVC++では使えない。
VC++でネイティヴアプリケーションを記述する限り、
Unicodeの全文字を利用する方法はない。
これでOK?^^;
0025デフォルトの名無しさん
2011/01/18(火) 21:38:24JIS漢字コードってなんですか。JIS X 0208 のことですか。
シフトJISコードってなんですか。シフト符号化表現のことですか。
区点コードってなんですか。区点番号のことですか。
勝手な用語を使われたら誰も何も答えられません。
0026デフォルトの名無しさん
2011/01/18(火) 22:21:26http://twitter.com/ozawa_yuuki/status/6549767047872513
0027デフォルトの名無しさん
2011/01/18(火) 23:27:120028デフォルトの名無しさん
2011/01/18(火) 23:52:45ええ〜〜っ!シフトJISコードを知らないひとがいるのぉ?
ええ〜〜っ!区点コードを知らないひとがいるのぉ?
ばっかみた〜い
0029デフォルトの名無しさん
2011/01/18(火) 23:53:270030デフォルトの名無しさん
2011/01/19(水) 00:16:220031デフォルトの名無しさん
2011/01/19(水) 00:34:400032デフォルトの名無しさん
2011/01/19(水) 00:50:050033デフォルトの名無しさん
2011/01/19(水) 01:39:240034デフォルトの名無しさん
2011/01/19(水) 10:31:450035デフォルトの名無しさん
2011/01/26(水) 00:29:480036デフォルトの名無しさん
2011/01/26(水) 00:34:53UnicodeとUTF-8の違いは? その2
http://hibari.2ch.net/test/read.cgi/tech/1274937437/
0037デフォルトの名無しさん
2011/01/26(水) 16:26:320038デフォルトの名無しさん
2011/01/28(金) 19:01:230039デフォルトの名無しさん
2011/02/01(火) 06:41:44つまりオナニーのことだったんだよ
0040デフォルトの名無しさん
2011/02/01(火) 07:17:120041デフォルトの名無しさん
2011/02/01(火) 15:03:500042デフォルトの名無しさん
2011/02/02(水) 00:13:350043デフォルトの名無しさん
2011/02/02(水) 08:12:08琉球語で「いらっしゃい」の意味じゃなかったの?
0044デフォルトの名無しさん
2011/02/03(木) 21:48:55>VC++でネイティヴアプリケーションを記述する限り、
>Unicodeの全文字を利用する方法はない。
どれだけ無知なんだよ。Unicode(UTF-16)版API使うに決まってんだろ。
>>25
>シフトJISコードってなんですか。シフト符号化表現のことですか。
相変わらずJIS信者はキモいな。シフトJISはシフトJISだよ。
0045デフォルトの名無しさん
2011/02/03(木) 22:37:43みたいなつっこみでどうでしょう。
0046デフォルトの名無しさん
2011/02/04(金) 00:22:50で、それが問題になるケースは?
0047デフォルトの名無しさん
2011/02/04(金) 00:25:110048デフォルトの名無しさん
2011/02/04(金) 01:21:00もう完全に引っ越すんだけどな
0049デフォルトの名無しさん
2011/02/04(金) 06:57:050050デフォルトの名無しさん
2011/02/04(金) 07:12:45> 相変わらずJIS信者はキモいな。シフトJISはシフトJISだよ。
CP932 とか Windows-32J で混乱して死ねばいいと思うよ。
0051デフォルトの名無しさん
2011/02/04(金) 07:21:36Windows - 「BOMねえとエンコーディングの判別が面倒すぎるだろ糞が」派
0052デフォルトの名無しさん
2011/02/04(金) 10:50:26バイト列だからとかホザいてるFSもな!
0053デフォルトの名無しさん
2011/02/04(金) 11:42:13「shebang の次の行に書いておけばいいだろ」派
0054デフォルトの名無しさん
2011/02/04(金) 11:47:16実際アホなんだろうけど
0055デフォルトの名無しさん
2011/02/04(金) 19:11:35BOMがあるとUTF-8の利点である1バイト部分がLaten-1互換ってのも失われちゃうし
おっぱいぱいなんじゃなかったっけ?
0056デフォルトの名無しさん
2011/02/04(金) 20:39:51古いエンコードでバシッと表示できる可能性がミジンコくらい有るのはASCIIだけだよ
0057デフォルトの名無しさん
2011/02/04(金) 21:56:15バックスラッシュとチルダは?
0058デフォルトの名無しさん
2011/02/05(土) 11:35:57JIS X 0201左面じゃないんだから。
0059デフォルトの名無しさん
2011/02/06(日) 01:07:58ファイル名に BOM 付ける訳にいかないしなぁ
0060デフォルトの名無しさん
2011/02/06(日) 02:07:45実はお前、馬鹿ですね
0061デフォルトの名無しさん
2011/02/06(日) 02:11:36shebang という事は TCC 使いなのかもね。
http://bellard.org/tcc/
0062デフォルトの名無しさん
2011/02/06(日) 04:33:14申し訳ございませんが
tcc と shebang の関係について私には分かり兼ねますので
ご高説賜りたく望む所存でございます
0063デフォルトの名無しさん
2011/02/06(日) 05:13:24TCCでコンパイルすると出来上がったexeにアンチウィルスソフトが反応してワロス
ここのひとも同じみたいだ
>ttp://www.mail-archive.com/[email protected]/msg02244.html
0064デフォルトの名無しさん
2011/02/06(日) 06:51:10リンク先嫁
0065デフォルトの名無しさん
2011/02/06(日) 07:35:26># C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
ありがとうございました
0066デフォルトの名無しさん
2011/02/06(日) 13:00:21TCC でも動作確認出来ました。
ttp://www1.axfc.net/uploader/Sc/so/202217.zip&key=tcc
ほんとうにありがとうございました。
0067デフォルトの名無しさん
2011/02/06(日) 13:15:56ファイル名に BOM 付けたければ付ければ?
0068デフォルトの名無しさん
2011/02/06(日) 15:13:49Unicode関連が元々どうしようもないクソ規格なんだから、適当にならざるを得ないんだよ
四角四面に適用可能なほど出来のいい規格じゃねーし
0069デフォルトの名無しさん
2011/02/06(日) 17:16:43BOMのバイト列が先頭に出現する符号化方式って他に無いの?
0070デフォルトの名無しさん
2011/02/06(日) 17:18:23> BOMのバイト列が先頭に出現する符号化方式って他に無いの?
Latin-1をはじめとするシングルバイト全部
0071デフォルトの名無しさん
2011/02/06(日) 17:31:36具体的に役立つ場面が想像付かない。
あまり聞くのも迷惑だろうし、判りやすいサイトがあれば誘導してほしいです
0072デフォルトの名無しさん
2011/02/06(日) 21:07:11UTF-8でもVC++通るな
0073デフォルトの名無しさん
2011/02/06(日) 22:39:52君の疑問は君の無知から来ているわけではなく、
BOMの矛盾がそのままあなたの頭の中のモヤモヤになってるだけ。
0074デフォルトの名無しさん
2011/02/06(日) 23:03:58確かに[FE FF 41 41]のファイルはLatin-1ともUTF-16とも。
(VC#で確認したけどデフォルトではEncoding無視してBOM優先なんですね。ちょっと驚いた)
前スレも見てきたけどBOMについては賛否あるみたいなんで、
あんまり関わらないようにします。
0075デフォルトの名無しさん
2011/02/09(水) 01:01:41偶然先頭にBOMが来ることは少ない、という前提の元では、
ファイルが、自身のエンコード方式を明確にする目的での利用にはそれなりに役に立つ。
けどBOMなしUTF-16というものもあるので、
アプリが、ファイルのエンコードを知るという目的では微妙。
0076デフォルトの名無しさん
2011/02/09(水) 23:56:09>BOMの矛盾
何も矛盾してないだろ。矛盾とは何?
エンコーディングを確実に判断するにはメタデータが必要に決まっているし、
BOMはUnicodeを他のエンコーディングと区別できることを保障している
わけではない。
0077デフォルトの名無しさん
2011/02/10(木) 00:29:490078デフォルトの名無しさん
2011/02/10(木) 00:31:470079デフォルトの名無しさん
2011/02/10(木) 00:47:30>>75も無知の部類
0080デフォルトの名無しさん
2011/02/10(木) 00:53:16低能なネタ振りは無視すれいちいちツッコミ入れるな
0081デフォルトの名無しさん
2011/02/10(木) 00:55:100082デフォルトの名無しさん
2011/02/10(木) 01:55:30無知じゃない人おしえて
0083デフォルトの名無しさん
2011/02/10(木) 06:15:010084デフォルトの名無しさん
2011/02/10(木) 06:41:56「挨拶は人間同士のコミュニケーションを円滑にするが、
挨拶しない人もいるので、挨拶の必要性を感じない」ってレベル。
0085デフォルトの名無しさん
2011/02/10(木) 08:36:090086デフォルトの名無しさん
2011/02/10(木) 09:26:48(たとえば JIX X 0208 の「何区何点」)も「コードポイント」。
スカラー値というのは Unicode の概念で、コードポイントを示す具体的な
整数値。
0087デフォルトの名無しさん
2011/02/10(木) 09:48:53そういうことなんだ。
�d
0088デフォルトの名無しさん
2011/02/10(木) 10:16:570089デフォルトの名無しさん
2011/02/10(木) 10:18:13バカは死ななきゃ治らない
0090デフォルトの名無しさん
2011/02/10(木) 10:37:47int 無知; // uninitialized
0091デフォルトの名無しさん
2011/02/10(木) 12:28:240092デフォルトの名無しさん
2011/02/10(木) 15:27:410093デフォルトの名無しさん
2011/02/10(木) 20:00:100094デフォルトの名無しさん
2011/02/10(木) 21:34:490095デフォルトの名無しさん
2011/02/10(木) 23:01:51これでじゅうぶんやん。何が不満なの?ワケがわかりません。
0096デフォルトの名無しさん
2011/02/10(木) 23:06:18これでもいいし。まぁ煮たようなのは他にも
-*- coding: UTF-8 -*-
とか
vim:fileencoding=UTF-8
とか
use utf8;
とかあるらしいけど、実際に使った事がないから知らん。
なんでソレじゃダメなのさ?
0097デフォルトの名無しさん
2011/02/10(木) 23:07:040098デフォルトの名無しさん
2011/02/10(木) 23:16:46-*- coding: UTF-8 -*-
vim:fileencoding=UTF-8
これらは
coding="UTF-8"
coding: UTF-8
coding=UTF-8
の部分のマッチだけ見てるよ
0099デフォルトの名無しさん
2011/02/11(金) 00:42:470100デフォルトの名無しさん
2011/02/11(金) 01:31:28例えば、文字コード変換との相性は明らかに良くないし、対処法も美しくない
BOMと比べてどうかはまた別の話だが
0101デフォルトの名無しさん
2011/02/11(金) 03:51:56UTF-16で破綻するしBOMより酷いと思う
0102デフォルトの名無しさん
2011/02/11(金) 08:38:34旧 HTML → media type で指定。デフォルトなし
↓ XML → デフォルトは Unicode だが指定可能
新 JSON, YAML → Unicode 以外不可
となっている。Unicode 以外不可なら BOM で判別がつく(なければ UTF-8)。
0103デフォルトの名無しさん
2011/02/11(金) 14:01:51そう解釈したのならバカ。挨拶ってのがセンスのない例えなので、違和感は出るが
挨拶しない人もいるから、挨拶してもらえるつもりでいてはいけない
の方が近い。
0104デフォルトの名無しさん
2011/02/11(金) 14:19:06昔のHTMLは、そもそも多言語対応
してなかった。
JSONは、パーサー次第だろ。
「世の中」としては、UTF-8に収束
しつつも、統合されるのはまだまだ
遠い将来、くらい?
0105デフォルトの名無しさん
2011/02/11(金) 14:26:29>>104
>しつつも、統合されるのはまだまだ
>遠い将来、くらい?
もう目の前まで来てる
0106デフォルトの名無しさん
2011/02/11(金) 14:34:350107デフォルトの名無しさん
2011/02/11(金) 16:40:26多言語対応と複数文字コード対応は全く違う話。
0108デフォルトの名無しさん
2011/02/11(金) 21:05:52そげなことを言い始めたら話が先に進まんぜ。
シフトJISの文書ファイルにUTF-8のBOMを埋め込むことだってできる。
偽装しようと思えば何だってできるやろ。
他人の考えを否定するばかりでなく、自分で何か建設的な意見は言えんの?
0109デフォルトの名無しさん
2011/02/11(金) 21:12:19BOMだの言語タグだのコーディング指定だのはそっちに入れるのがいい
テキストとBOMとごっちゃに規格管理しようとするから混乱する
0110デフォルトの名無しさん
2011/02/11(金) 21:23:42必須にならなくてよかったよ。
そのうち死滅するだろう。
0111デフォルトの名無しさん
2011/02/11(金) 21:28:41文字コード変換と同列の問題じゃない。
実際問題、文字コード変換をしようとしたら、どれが一番楽かはともかく、データ内に
文字コード情報を埋め込むやり方は一番面倒だ。設計的には美しくない。かといって、
既存の枠組みから大幅に異なるコンテナを作ったところで誰も使わないだろう。
UTF-8で全部片付くほど綺麗な世界でもない。BMPだけなのか、UCS-4まで行ける
のか、同じUTF-8でも別扱いにしないとまずい世界が既にあるのだし。
BOM付きUTF-8への対応も進んでいるし、推奨もしないが排除する必要も無かろう。
大体、CJKなんて糞仕様を作った糞コンソーシアムに盲従する必要も全く感じない。
0112デフォルトの名無しさん
2011/02/11(金) 21:30:190113デフォルトの名無しさん
2011/02/11(金) 21:48:01まぁ、使わなくても個人的には全く困らないっつーか、BOM無しに統一された世界なら
むしろその方が楽だから、非対応に戻すのが流行ったりしたら死滅するだろうけど。
あと、美しく新しいテキストファイルのコンテナ、とか考えていいのは中学生までだな。
0114デフォルトの名無しさん
2011/02/11(金) 22:13:450115デフォルトの名無しさん
2011/02/12(土) 00:50:26他人の考えを否定するばかりって…w
conding=UTF-8埋め込みじゃあ例えばSJISにコード変換しただけで破綻するじゃない
コード変換は普通に行われるから、それを指摘しただけなのにw
0116デフォルトの名無しさん
2011/02/12(土) 00:56:01> conding=UTF-8埋め込みじゃあ例えばSJISにコード変換しただけで破綻するじゃない
それは現状のコード変換がconding=UTF-8を認識せずにコード変換するからであって
conding=UTF-8をコード指定として認識するコード変換ツールは、変換後のコード名を
埋め込み直すんじゃないでしょうか?
0117デフォルトの名無しさん
2011/02/12(土) 02:18:01ユーザーは一行目に coding *** などと間違われやすいテキストを書いてはいけない。
ユーザーはテキストエディタで開けば書き直せる状態だけど coding=*** を書き換えてはいけない。
制約が多いなあ。
0118デフォルトの名無しさん
2011/02/12(土) 02:23:36そもそも文字コード間の文字って完全に対応が決まってるわけじゃないし
どうやっても何らかの問題を含んでしまいそうだ
コンセンサンスのある文字コード変換手法が定まってればいいんだろうけど
どうせ「Windowsと同じ挙動にすること」ってなったりしそうで実装者がかわいそう
0119デフォルトの名無しさん
2011/02/12(土) 03:21:01馬鹿にかまうな
0120デフォルトの名無しさん
2011/02/12(土) 04:55:240121デフォルトの名無しさん
2011/02/12(土) 12:43:08コード変換する必要の無いように、coding=*** を埋め込むんじゃないか。
コード変換する必要があるのは、コードが不明だから。
判明してれば変換する必要は無いだろ。
0122デフォルトの名無しさん
2011/02/12(土) 13:00:10アフォなプログラマ・アプリは山ほどあるぞ
0124デフォルトの名無しさん
2011/02/12(土) 14:36:40>もう目の前まで来てる
ガラパゴスなめんな!
0125デフォルトの名無しさん
2011/02/12(土) 20:16:29認識しなければならない。
また、例えばプログラムのコード、ログファイル、ドキュメントなどにMETAタグがサンプル
として埋まっている場合は、それは言語コード指定ではないので変換してはならない。
アホかと。
「コード変換ツールが対応すればいい」とか言ってる奴は、一生プログラムを書くべきじゃ
ないレベルだろ。
0126デフォルトの名無しさん
2011/02/12(土) 20:22:12適当な言語で非ASCIIで破綻しない正規表現マッチングをしようとしたとして、シフトJISと
判明しているテキストが送られてきた場合、coding=Shift_JISって埋まってたら、どんな
プログラム言語でも変換せずに処理できるとでも?
0127デフォルトの名無しさん
2011/02/12(土) 20:39:570128デフォルトの名無しさん
2011/02/12(土) 23:02:110129デフォルトの名無しさん
2011/02/26(土) 09:39:55.260130デフォルトの名無しさん
2011/02/26(土) 12:23:31.69UTF-32は固定長でないと書いてありますが、これはどういう意味でしょうか?
合成文字があるから1文字が必ずしも32bitでないということを言っているのでしょうか?
http://hibari.2ch.net/test/read.cgi/tech/1295493964/228
>228 :デフォルトの名無しさん:2011/02/26(土) 02:22:47.15
>いまどき、欧米人以外でUTF-32が固定長とか思ってる奴がいるんだな。
>CJKの当事者としてもうちょっと勉強しようぜ。
0131デフォルトの名無しさん
2011/02/26(土) 14:19:42.86普通に考えたらそうだと思うけど、その人が本当に何を考えてそう発言したのかは
向こうで聞かないと分からないと思われ
コードポイントの話に反論が無かった所を見ると、まあ間違いないとは思うけどね
0132デフォルトの名無しさん
2011/02/26(土) 14:20:00.770133デフォルトの名無しさん
2011/02/26(土) 15:25:56.28やはりそういうことですよね。
�d
0134デフォルトの名無しさん
2011/02/26(土) 16:50:59.120135デフォルトの名無しさん
2011/02/26(土) 17:33:27.170136デフォルトの名無しさん
2011/02/26(土) 18:00:45.17CJK を使ってなくても分かる話だよな
0137デフォルトの名無しさん
2011/04/16(土) 07:00:33.6011時に電話で予約入れた。どきどき
お前らも今時シフトジスなんて使わずMancode使えよ
0138デフォルトの名無しさん
2011/04/16(土) 07:39:18.440139デフォルトの名無しさん
2011/04/16(土) 09:30:15.01体験レポートもよろしく。
自分の場合、マンコの中がゆるく感じて、あまり気持ちいいとは思わなかった。
0140デフォルトの名無しさん
2011/04/16(土) 10:15:37.300141137
2011/04/16(土) 13:54:15.82騎乗位は何故かチソコ痛いだけで苦痛だったけど
正常位はむちゃくちゃ気持ち良かった。
緊張して何話したか覚えてないけど、優しくしてもらえたよ。
お前らもMancodeなんて使ってないで。UTF-8使った方がいいよマジ
0142デフォルトの名無しさん
2011/04/30(土) 09:25:16.40相手が読めなかったり 問題ある?
あとUTF-8が括弧書きされてるのはUTF-8はUnicodeの一種ってい
理解でいいのかな
0143デフォルトの名無しさん
2011/04/30(土) 13:17:17.60軽く目まいがしたぜ・・・
0144デフォルトの名無しさん
2011/04/30(土) 14:59:14.76「Unicode」が符号化文字集合の名前だなんてUnicode規格のどこにも書いてないし、
「Unicode」をUTF-16の意で使うのはマイクロソフトだけ
0145デフォルトの名無しさん
2011/04/30(土) 15:29:57.76「魚の一種」というなら対象は魚であるべきだし
「Unicodeの一種」というなら対象はUnicode(つまり規格)であるべきなんだ
日本語の問題だな
UTF-8は規格は規格でもUnicodeの符号化方式の規格であって、言うなれば
上の例でたとえるなら「フグの白子って魚の一種ですよね?」と聞いているようなもの
フグは魚の一種だが、フグの白子は魚の一種ではない
「Unicodeの一種」と呼べるのは、例えばUnicode 1.0.1とかUnicode 6.0.0とかだな
この二つは全然違うけどどちらもUnicode
0146デフォルトの名無しさん
2011/04/30(土) 15:43:17.080147デフォルトの名無しさん
2011/04/30(土) 22:14:03.440148デフォルトの名無しさん
2011/04/30(土) 22:45:48.730149デフォルトの名無しさん
2011/05/01(日) 02:25:41.720150デフォルトの名無しさん
2011/05/01(日) 06:12:28.610151デフォルトの名無しさん
2011/05/01(日) 10:30:43.790152デフォルトの名無しさん
2011/05/01(日) 12:36:34.070153デフォルトの名無しさん
2011/05/01(日) 20:50:07.030154142
2011/05/14(土) 18:23:02.15メール本文は文字化けしないようなのですが、返信メールの宛先が
「"=?utf-8?B?=" aaa@bbb」みたいになってしまいます。
相手のメールソフトがMIMEエンコードを認識できないことがあるようです。
0155デフォルトの名無しさん
2011/05/15(日) 00:27:53.500156デフォルトの名無しさん
2011/05/29(日) 07:37:03.28「文字コードの指定の無いページで文字化けが起こるようになりました」とか言う奴は
死んだ方がいい
0157デフォルトの名無しさん
2011/06/02(木) 00:01:47.430158デフォルトの名無しさん
2011/06/02(木) 02:53:51.08いや、最近IEを更新すると、
META書いてあってもISO-2022-JPが化けるようになった。
985 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 17:03:21
>>984
ISO-2022-JP は IE でも見れるって
話じゃなかったのか?
見れなくなったのか。
986 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 21:39:59
>>985
http://blogs.msdn.com/b/ie_jp/archive/2010/12/17/ms10-090.aspx
987 名前:デフォルトの名無しさん [sage]: 2011/01/23(日) 22:57:09
HTTPヘッダだと認識してhttp-equivで認識しないってなんだよ。
いずれにせよHTMLでのISO-2022-JPに未来はないと。
0159デフォルトの名無しさん
2011/06/05(日) 00:19:36.360160デフォルトの名無しさん
2011/06/05(日) 00:22:01.400161デフォルトの名無しさん
2011/06/05(日) 00:30:48.61MS用語としてのUnicode:リトルエンディアン固定のUTF-16
UTF-8: バイトオーダー非依存でおk
0162デフォルトの名無しさん
2011/06/05(日) 01:23:32.870163デフォルトの名無しさん
2011/06/05(日) 03:17:36.76それともWinとMacでカオス?
0164デフォルトの名無しさん
2011/06/05(日) 04:26:54.21Javaもなんだな。
http://download.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html
0165デフォルトの名無しさん
2011/06/05(日) 20:08:59.54カオスです。
詳しいことはMacOSXの方しか知らないけど、
NFDじゃないのが紛れ込んだりすると、
フレームワークも標準アプリもとても馬鹿げた動作をする。
要するにNFDを徹底できてない。
0166デフォルトの名無しさん
2011/06/05(日) 21:12:30.76どちらも標準形式、両者を扱えないといけない。
>>165
OSXは両刀、テキスト入力とかはNFCだよ。
NFCをファイル名に渡すと自動的にNFDにnormalizeする。
変換、比較のAPIも揃ってる。
0167デフォルトの名無しさん
2011/06/05(日) 21:20:40.21正規化できてないってことはUTF-8と呼ぶことすら問題がある
0168デフォルトの名無しさん
2011/06/05(日) 21:32:28.48それはVFSレイヤに限定した話。
専用のnormalize APIもある。
テキスト等でどんな正規化を使っても構わない、って言うか普通はNFC
0169デフォルトの名無しさん
2011/06/05(日) 21:57:45.920170デフォルトの名無しさん
2011/06/05(日) 22:10:46.58>VFSレイヤに限定した話
独自コードの使用場所がファイルシステム限定っていうのは知らんかった。でも
NFCでファイルシステムに書き込み要求→独自コードに変換される
→lsの結果を読み込むと独自コードのまま→元のNFCと比較するとアウチ
Mac内だけで既にカオスだね
0171デフォルトの名無しさん
2011/06/05(日) 22:41:39.84正規化無視するにしても、ファイルシステムによって使えない文字(/:とか)や
同一視される文字(大文字小文字とか)は異なるから、ファイル作ったりしたら
実際どういうファイル名になったかは確認する必要あるよ。指定した文字列が
そのまま使われる保証は無い。
0172デフォルトの名無しさん
2011/06/06(月) 08:09:48.24VFS関係ではNFDのコードはhfs+ドライバにしかないから。
Cocoaでもうまく出来てない。
hfs+以外は全部プログラマー任せだから。
0173デフォルトの名無しさん
2011/06/06(月) 08:52:33.29\が/になっても文句言わないけど、シフトJISで
書き込んだファイル名がEUC-JPになったら困るじゃないか。
0174デフォルトの名無しさん
2011/06/06(月) 18:46:43.25>VFS関係ではNFDのコードはhfs+ドライバにしかないから。
>Cocoaでもうまく出来てない。
それは君が知らないだけ。自動変換で不十分ならUnicodeConverterを使えばHFS+ルール
でのNFD/NFC変換もできる。
>hfs+以外は全部プログラマー任せだから。
HFS+以外だと具体的に何が必要になるの?
>>173
>シフトJISで書き込んだファイル名がEUC-JPになったら困るじゃないか。
古目のWindowsのアプリはそうでしょ。ファイル名はUnicodeで保存されてるのに未だに
Shift_JISで扱ってる。zipアーカイブのファイル名をShift_JISで記録してるため、本当の
ファイル名と違うし、UTF-8使ってるOSX等unix系の物と互換性が無いのは有名な話。
0175デフォルトの名無しさん
2011/06/06(月) 19:25:09.50> ファイル名はUnicodeで保存されてるのに
ダウト
0176デフォルトの名無しさん
2011/06/06(月) 21:04:50.04シフトJISに見せてるWindowsをマクとと一緒にすんな
と思ったけど、ラウンドトリップが完全でないからNEC選定IBM拡張文字を書くと
IBM拡張に化けるのかな
0177デフォルトの名無しさん
2011/06/06(月) 21:12:42.72> 保存されてるだろ。実体がUTF16でも
ダウト
http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07
0178デフォルトの名無しさん
2011/06/06(月) 21:19:47.110179デフォルトの名無しさん
2011/06/06(月) 21:26:00.93> >>176
> > 保存されてるだろ。実体がUTF16でも
> ダウト
> http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07
正確には今もなお UCS-2 らしい。つまり、サロゲートペアの片方のみの場合がある
0180デフォルトの名無しさん
2011/06/06(月) 21:58:53.32著者成瀬って成瀬ゆいか? あんなアホ男のことを真に受けるとは。
>UCS-2 らしい。つまり、サロゲートペアの片方のみの場合がある
らしいってソース無しかよ。
しかも「つまり、サロゲートペアの片方」って意味わかんね。さすが池沼成瀬
0181デフォルトの名無しさん
2011/06/06(月) 22:03:20.020182デフォルトの名無しさん
2011/06/06(月) 22:12:52.070183デフォルトの名無しさん
2011/06/06(月) 23:03:57.57レッテルっていうけど、自分で試してみればわかるでしょ。
FILE *f = _tfopen(_T("d:\\tmp\\\xD844\xDE3D.txt"), _T("wb")); // ??: U+2123D
明らかにWindowsはUCS-2じゃないよ
0184デフォルトの名無しさん
2011/06/06(月) 23:24:04.52>zipアーカイブのファイル名をShift_JISで記録してるため
日本語版WindowsはシフトジスだがShift_JISではないな。Windows-31J
0185デフォルトの名無しさん
2011/06/06(月) 23:50:27.43UTF-16かUCS-2かは置いておいて
WindowsがUnicodeなのは疑いようの無い事実だと思うんだけど
0186デフォルトの名無しさん
2011/06/06(月) 23:56:38.49そっとしておいてやれ
0187デフォルトの名無しさん
2011/06/07(火) 00:26:01.870188デフォルトの名無しさん
2011/06/07(火) 00:44:02.430189デフォルトの名無しさん
2011/06/07(火) 01:19:45.40MBCSが文字コードを指定してるわけじゃないのと同じで、
Unicodeも実際のコードを特に名指ししてるわけじゃない。
そこはまた別問題な。
MBCS ←→ unicode
ANSI ←→ wide character
この関係な
0190デフォルトの名無しさん
2011/06/07(火) 01:23:52.960191デフォルトの名無しさん
2011/06/07(火) 01:35:45.36実データ……Unicode
圧縮形式……UTF-8 UTF-16等
生waveを圧縮するのにMP3とかWMAとか色々あるだろ。
まあ、これは不可逆だけど。
0192デフォルトの名無しさん
2011/06/07(火) 02:17:46.91FAT32のファイルを扱う時に必要。
0193デフォルトの名無しさん
2011/06/19(日) 05:08:50.30>Windowsの場合、MBCSに対してのunicodeだよ
どうしてそんな嘘付くかなあ。
メモ帳の保存オプション見れば「Unicode」「Unicode big endian」「UTF-8」
が選択できるでしょ。明らかにMS用語のUnicodeはUTF-16のLE(BOM付き)
0194デフォルトの名無しさん
2011/06/19(日) 22:59:22.950195デフォルトの名無しさん
2011/06/19(日) 23:52:11.55>>188曰く 「MSのUnicode=UTF-16LEはなぜ?」
>>189曰く 「MSのUnicodeは規格のUnicodeであってLEとか関係ない」
>>193曰く 「嘘付くな。MSのUnicodeはUTF-16のLE限定」
>>194曰く 「MSのUnicodeは当初UCS-2の範囲しか扱えなかった」
当初U+10000以上が扱えなかったのは事実だけど、>>193が言ってるのは
リトルエンディアン限定ということ。
ちなみにUCS-2は符号化文字集合だからエンコーディングであるUTF-16と
同列に扱うべきじゃない。BOM付きUCS-2とかいうものは存在しない。
0196デフォルトの名無しさん
2011/06/20(月) 01:01:12.890197デフォルトの名無しさん
2011/06/21(火) 02:43:05.15ISO 10646ってひょっとしてUCS-2が前提で
U+10000以上をUTF-16で扱えなかったりするの?
0198デフォルトの名無しさん
2011/06/21(火) 11:47:38.99だからUnicodersがDIS 10646 1.0を廃案にした。
その頃Unicodeコンソーシアムは16bitで全て賄うつもりだったから。
結局ダメでサロゲートペア→UCS-4という流れ。
UTF-16はずっと後。
0199デフォルトの名無しさん
2011/06/22(水) 01:31:59.98UCS-2/UCS-4はISOの概念でUnicodeとは直接関係なくね?
0200デフォルトの名無しさん
2011/06/23(木) 11:36:55.26と
The Unicode Starndard, Version 1.1
は同じ。そのための1.1。
UTF-8, UTF-16は2から。
0201デフォルトの名無しさん
2011/06/25(土) 20:56:52.95「あんたねぇ、UnicodeとUTF-8の違いが分かってるの?」
を英語に翻訳していただけますか?
バカなアメ公がクソなコードをアップロードしてしまうんで困ってます。
0202デフォルトの名無しさん
2011/06/25(土) 23:06:12.21適当に翻訳サイトで訳した
0203デフォルトの名無しさん
2011/06/25(土) 23:19:37.000204デフォルトの名無しさん
2011/06/25(土) 23:55:11.65遠回りな表現しないで確実にUTF-8の文字コードでアップしろでいいじゃん
二つの違いを教えたいわけじゃない
0205デフォルトの名無しさん
2011/06/26(日) 00:35:52.32Why don't you understand the difference between Unicode and UTF-8 ?
0206デフォルトの名無しさん
2011/06/26(日) 00:50:25.50「UCS」は符号化文字集合。「UCS-2」はエンコーディング。
ちゃんとISO/IEC 10646読め。
>>201
TOEIC 330点の俺が訳すと
Please seive file as UTF-8 encoding, not as Unicorde.
0207デフォルトの名無しさん
2011/06/26(日) 02:01:46.160208デフォルトの名無しさん
2011/06/27(月) 13:35:43.31易に断罪してしまうのは間違いだと思う。
0209デフォルトの名無しさん
2011/06/27(月) 19:45:43.18って言っているようなもの。あきらかな理解不足
0210デフォルトの名無しさん
2011/06/27(月) 20:54:21.02なんかそこらへん曖昧になる。>>19はあってるのか?
0211デフォルトの名無しさん
2011/06/27(月) 23:23:17.83>Unicode規格って、文字集合とエンコーディングひっくるめた規格だっけ?
その通り。
エンコーディングに関する仕様: http://www.unicode.org/versions/Unicode6.0.0/
文字集合の定義:http://www.unicode.org/charts/
>>>19はあってるのか?
違う。Unicodeは規格であって、文字集合の名前じゃない
0212デフォルトの名無しさん
2011/06/27(月) 23:53:43.78UCS-2とかUCS-4はどっちだっけ
0213デフォルトの名無しさん
2011/06/28(火) 00:09:11.900214デフォルトの名無しさん
2011/06/28(火) 00:09:51.48UCSはISOの文字集合の名前。
Unicodeの文字集合に名前はない。
0215デフォルトの名無しさん
2011/06/28(火) 00:12:21.43Universalだろ。Unicodeとは関係なし
0216デフォルトの名無しさん
2011/06/28(火) 00:21:52.800217デフォルトの名無しさん
2011/06/28(火) 00:34:05.00Cが一個どこに行っちゃったのか不明。
Unicodeの文字集合は「Unicodeの文字集合」でいいんじゃない?
0218デフォルトの名無しさん
2011/06/28(火) 10:29:58.08まず訂正。
×バカなアメ公
○バカなイタ公
クソコードを投稿(正確にはsvnリポジトリーにコミット)してたのは、イタリア人でした。
でもコードを管理してるコミュニティの親分はアメリカ人で、そいつのチェックでOKが出た上で投稿されたんです。
コードというのは、javaで書かれたプログラムコードのことで、テキストのエンコードのことではありません。
話が長くなるのでアレですが・・・
javaでは内部的に文字列をユニコードで処理しています。1文字は16ビットです。
Windowsも皆さんご存知の通り、内部的に文字列をユニコードで処理しています。1文字16ビットです。
Win32APIの末尾に w が付くやつがそうですね。
つまり、javaで何も考えずにフツーにプログラミングすれば、アメ公が作ってもイタ公が作っても
自動的に日本語対応になるんです。
あとは画面に表示されるメッセージを言語別に作成して、利用者の言語にあわせて切り替える仕組み
にしてやれば、マルチリンガルなアプリケーションの一丁あがり!ってワケです。
javaにはもともと、そういう仕組みが用意されてるので簡単です。
ところが、件のバカなイタ公は、文字列を一旦 UTF-8 にエンコードしてから表示しようとするんです。
もちろん文字化けします。バカなイタ公はなぜ文字化けするのか理解できないので
今度はそのUTF-8エンコードされた文字を、javaからWin32APIのWriteConsoleWに渡そうとします。
もちろん文字化けします。バカなイタ公はなぜ文字化けするのか理解できないので
今度はコンソールのコードページを無理やりUTF-8に変更するAPIを使いドツボにハマっています。
何もしなくていい、ただ System.out.println()関数でフツーに表示すればいい、ってのが理解できんのです。
アプリケーションをユニコード対応して国際化したい一心で一生懸命がんばってくれてるキモチはアリガタイwのですがw
ユニコードとUTF-8の違いが理解できてないため、まったくトンチンカンなプログラムコードを書いて投稿します。
このイタ公を何とかして退治したいです。イタ公の愚行をやめさせるナイスな文章を教えてください。
コミュニティは英語以外禁止なので英語で構いません。
0219デフォルトの名無しさん
2011/06/28(火) 10:46:16.970220デフォルトの名無しさん
2011/06/28(火) 10:46:39.02> エンコーディングに関する仕様: http://www.unicode.org/versions/Unicode6.0.0/
ここで文字集合も定義しているが?
0221デフォルトの名無しさん
2011/06/28(火) 20:25:40.31TOUIC 420点の俺が説明すると
Don't use JNI.
Don't use new String() or String#getBytes().
Never change code page for console window (use default always).
Simply, you should pass String objects to System.out.println.
ex 1. println("native text")
ex 2. println(str)
Encoding conversion as below is performed:
source text(Native encoding) ->(compilation)-> UTF-16/class file
-> String object(UTF-16) -> System.out.println -> Windows
-> (Windows converts UTF-16 to native encoding)
0222デフォルトの名無しさん
2011/06/29(水) 11:02:32.90中学生の妹のことで困っています。
ここ最近、妹は風呂上りに毎回僕の部屋にやってきます。
脱衣所でしっかり体を拭いていないせいか、濡れたタンクトップに乳首が透けて浮き出ています。
視線を逸らしながら注意すると「やっぱ妹のでも気になるんだ?」
と俺をからかいはじめる始末です。
こんな調子で二三時間も居つかれては堪ったもんじゃありません。
この高見盛そっくりの妹を退治するにはどうしたらいいのでしょうか。
0223デフォルトの名無しさん
2011/06/29(水) 11:03:28.460224デフォルトの名無しさん
2011/06/29(水) 14:56:27.20>>222 三行目まで読んだ
0225デフォルトの名無しさん
2011/06/29(水) 16:20:10.45TOUICってのは何万点満点なんだい?
0226デフォルトの名無しさん
2011/06/29(水) 22:41:25.18漏れにくれ
0227デフォルトの名無しさん
2011/06/30(木) 08:19:39.53このスレは3スレ目なのに、酷いものだ
0229デフォルトの名無しさん
2011/06/30(木) 12:00:51.80そもそもTOUICってなんの試験?
馬鹿レベルを計るもの?恥レベル?
Test Of Unwise International Computation.
0231デフォルトの名無しさん
2011/07/01(金) 13:39:03.710232デフォルトの名無しさん
2011/07/03(日) 03:52:20.12今時シフトJISしか扱えないなんて糞過ぎる。
スマホ上で作ったUTF-8ファイル名のZIP持ってくると文字化けしまくる。
ファイル名にBOM付けてもいいからマジ何とかしてほしい
0233デフォルトの名無しさん
2011/07/03(日) 05:03:45.92→個人設定
→システムロケールの変更
→再起動
0234デフォルトの名無しさん
2011/07/03(日) 05:33:52.760235デフォルトの名無しさん
2011/07/03(日) 14:42:31.19お前が使ってる糞解凍ツールを見直すべきかと
0236デフォルトの名無しさん
2011/07/09(土) 13:45:03.50JIS2004は日本語と判断したい
0237デフォルトの名無しさん
2011/07/10(日) 04:31:44.19そんなものは無いし、JIS2004をそのまま含んでいる訳ではないので不可能。
JIS2004に追加された文字でUNICODEに無かった分をUNICODE3.1や3.2でUNICODEに追加した分というのなら調べればわかる。
0238デフォルトの名無しさん
2011/07/10(日) 17:04:21.42言語とスクリプトは別というのはわりと基礎知識。
0239デフォルトの名無しさん
2011/07/10(日) 19:43:44.830240デフォルトの名無しさん
2011/07/10(日) 20:40:34.17>>236の言う「日本語かどうか」がどういう意味かによって、
やり方が全然変わってくるんだから。
JISで登録されてる文字集合に含まれてるかどうかでいいってのなら、
テーブル見れば済む。
けどそんなこと質問するかね。
0241デフォルトの名無しさん
2011/07/10(日) 21:22:02.68Unicodeの文字集合はUnifiedだから、一つの文字が複数の言語に
対応するのは>>236もわかってるでしょ。>>236は
「A」: 英語,日本語
「百」: 日本語,中国語
「あ」: 日本語
みたいなテーブルが欲しかったんでしょ。そんなものは無い。
>>240
>テーブル見れば済む
どこかに正式なものが公開されてる?
無保証でいいなら http://x0213.org/codetable/sjis-0213-2004-std.txt とかあるけど
0242デフォルトの名無しさん
2011/07/11(月) 13:36:38.84超一般論として、説明してもわからない
我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ
エラーが出るテストを作ってそれをつき突けろ
最終的にはそれしかない
「よくわからんがこのテストが通ってるんだからあちらでも問題はないんだろう」というものを作ってさしあげろ
0243デフォルトの名無しさん
2011/07/11(月) 19:57:07.030244デフォルトの名無しさん
2011/07/12(火) 08:47:17.73>我々がどっか外国のLatinなんとかの違いでの動作の違いを英語で追求されてもぶっちゃけよくわからんのと一緒だ
ぶっちゃけこの業界はコミュ障が多いから
そこまで他人の立場に立って理解出来る香具師は少ない
0245デフォルトの名無しさん
2011/07/12(火) 16:41:00.550246デフォルトの名無しさん
2011/07/14(木) 00:29:31.56UTF-8がバイトオーダーの影響を受けてLE,BEに分かれないのはどうして?
いや、UTF-16だけが特殊なのか?
CPUがメモリ上の複数バイトを読み書きする際の配置の都合からLE,BEがあるのなら、
UTF-8だってASCII文字以外は複数バイトでしょ?
0248デフォルトの名無しさん
2011/07/14(木) 01:17:06.251文字(16bit整数値1つ)を、どういうバイト列に変換するかの問題。
UTF-16LEは、UCSの1文字を2byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → 42 30
UTF-16BEは、UCSの1文字を2byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → 30 42
UTF-8は、UCSの1文字を1-4byteのバイト列に変換する。その順番も規定されている。あ(\u3042) → e3 81 82
2byteの整数をサイズ2のバイト列に変換する方法は、簡単で合理的な2種類ある(BE,LE)ので、
どちらを使えばいいか迷ってしまい、みんなで混乱する。
一方、2byteの整数をサイズ1〜3のバイト列に変換する方法は、それほど自明ではないので、
誰かが「UTF-8」としての変換ルールを決めた。そしてみんながそれに従った。現状、それがうまくいっている。
仮に、「UTF-8なんとか」というUTF-8に似て非なるルールが乱立するなら、UTF-16のLE/BEの混乱と
近いことが起こるかもしれないけど、たまたま現実はそうなっていない。
0249デフォルトの名無しさん
2011/07/14(木) 07:28:59.020250デフォルトの名無しさん
2011/07/14(木) 08:26:50.94UTF-8はエンコーディングフォームが1オクテット単位だから、
UTF-8エンコーディングスキームはバイトオーダーに依存しない。
UTF-16とUTF-32エンコーディングフォームが2/4オクテット単位だから、
エンコーディングスキームが複数必要となった。
0251デフォルトの名無しさん
2011/07/14(木) 19:26:49.500252デフォルトの名無しさん
2011/07/14(木) 20:23:18.940253デフォルトの名無しさん
2011/07/14(木) 21:58:52.88だからバイトオーダーの問題が出てくる。
UTF-8はそんまんま垂れ流すのでなければ、
内部表現としてのUTF-16/32と併用されることが多く、
その場合decodeがいずれにせよ必要となるので、
バイトオーダーと逆順になっていても大した手間じゃない。
0254デフォルトの名無しさん
2011/07/14(木) 22:48:24.40どっちかに我慢してもらって無理してでもどっちかに決めてしまえばよかった
本当はね
LEでもBEでもどちらでももちろん構わないというのは、うんざりするほど正当で当たり前だが、うんざりだ
0255246
2011/07/15(金) 07:20:47.59おかげさまでずっと疑問だったのが解消しました。
CPUの都合を考慮して2種類規格化してくれただけなんですね。
>>253
これは少し考えていました。
画像ファイルに例えるならばUTF-8=JPEG,UTF-16=BMPで、
JPEGはメモリ上にBMP形式で展開&編集され、最終的にJPEGで再保存される。
JPEG(UTF-8)がデータ交換用としての相互運用性を重視される一方、
BMP(UTF-16)はメモリ上での編集のし易さが重視される。
UTF-16においては、それはLE,BEの許容にあたる。
という認識です。
しかし内部形式って意識されるべきですか?
恥ずかしながらVB以降の言語しか分かりませんが、
通常charの型変換には符号化方式の指定が必要なので気にしたことがありません。
(short)charをファイルにシリアル化するような事があったとしても、
これはテキストと見せかけてバイナリファイルですと言い張るかも。
C言語なんかだと意識するんですか?
UNICODEをAPIで扱うならば内部的にはポインタ/byte[]で持つんですよね?
だとしたら意識しないといけないのかな?
あ、JAVAでもif('A'<=VALUE || VALUE <= 'Z')と書けるのはUTF-16BEだからですか!
無意識に書いてましたorz
0257デフォルトの名無しさん
2011/07/15(金) 07:59:23.900258デフォルトの名無しさん
2011/07/15(金) 08:02:47.23交換形式はどっちかにしちまえよ、って思ったことはある。
0259デフォルトの名無しさん
2011/07/15(金) 08:59:25.19それは実質UTF-8だな
UTF16/32のままネットワークを流れることはあまりない
0260デフォルトの名無しさん
2011/07/15(金) 14:23:43.37大量のテキストを処理したい時に、
内部表現と同じテキスト形式が存在しないのは不便。
実行環境の内部形式に依存しても、軽快に扱いたい局面はある。
たとえばテキストデータベースの二次記憶保存など。
ネットワークバイトオーダーについては、
TCP/IPのヘッダー部はデータ量が少ないし、
最近はハードウェア評価だからオーバーヘッドにはならない。
それにデータ交換についてはプロトコル毎に決めればいい。
0261デフォルトの名無しさん
2011/07/15(金) 21:33:02.35>しかし内部形式って意識されるべきですか?
意識する必要は無いし、UTF-16フォームにLEとBEの区別は無い。
ただし外部形式であるUTF-16スキームにはLEとBE区別が当然ある。
0262デフォルトの名無しさん
2011/07/15(金) 23:55:08.88せめてPNGにしとけ。それなら話が通じる
0263デフォルトの名無しさん
2011/07/16(土) 11:30:38.92Unicode = UTF-16
UTF-8 = UTF-8
もともと、Unicodeに準拠した文字コードはUTF-16しかなかったから
文字コードはUnicodeという記述をするとUTF-16をさす
その後、UTF-8というものが増えた為、
それと差別をするために、UTF-16という言葉が発生しました
なので今となっては
Unicodeは文字一覧を指し、
UTF-16/UTF-8は文字コードの種類を指す
という意味が正しいのだが、昔の事情があったため、
文字コードUTF-16をUnicodeという言い方をする場合がある
0264デフォルトの名無しさん
2011/07/16(土) 11:37:43.860265デフォルトの名無しさん
2011/07/16(土) 12:16:52.83昔はそうだったのかもしれないけど、気持ち悪くて
0266デフォルトの名無しさん
2011/07/16(土) 12:37:51.740267デフォルトの名無しさん
2011/07/16(土) 20:26:19.26> 文字一覧
文字セットの方が好き
0268デフォルトの名無しさん
2011/07/17(日) 16:28:44.12どこかに公開されていないでしょうか。
特にNEC特殊文字やIBM拡張文字(「�@」(U+2460)など)がどうなるか知りたいです。
0269デフォルトの名無しさん
2011/07/17(日) 16:53:25.930270デフォルトの名無しさん
2011/07/17(日) 17:13:37.77http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
にあるけど、今もこの変換通りなのか不明。
Microsoft拡張のCP932との関係も少しだけコメントが書いてある。
0271デフォルトの名無しさん
2011/07/17(日) 17:14:29.89U+2460をシフトジスに変換すると24 60の2バイトになるということかな?
0272デフォルトの名無しさん
2011/07/17(日) 17:15:05.68http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/Readme.txt
0273デフォルトの名無しさん
2011/07/17(日) 19:22:02.19>今もこの変換通りなのか不明
今も昔もこのルールか実装されたためしなんて無い。
|0x5C 0x00A5 # YEN SIGN
0274デフォルトの名無しさん
2011/07/17(日) 20:23:16.02Character ViewerからShift-JIS(X0208)指定して005Cダブルクリックで入力すると
アプリ側にはU+00A5が渡るけど
CoreFoundationで変換してもU+00A5になる。
0275デフォルトの名無しさん
2011/07/17(日) 21:07:44.60MacはもうShift_JISは使ってないよ。
UnicodeとShift_JISの変換は当然できるけど、動作はAPIに対するパラメータ次第。
例えばU+2460に対しては古いMacJapaneseを指示すれば0x8540が返るし、X0208を
指示すると変換できずエラー、X0213を指示すると0x8740が返る。
端的に言うとパラメータで指示した規格に沿った値に変換される。
0276デフォルトの名無しさん
2011/07/17(日) 22:33:23.51JDK 6とかな。
0277デフォルトの名無しさん
2011/07/17(日) 23:13:50.55シフトジスの84 BF(丸付き21)をUTF-16に変換すると27D0になったり、
シフトジスのFCA3をUTF-16に変換するとD867 DFCEになっちゃうわけ
0278デフォルトの名無しさん
2011/07/18(月) 21:57:13.750279デフォルトの名無しさん
2011/07/18(月) 23:46:46.270280デフォルトの名無しさん
2011/07/19(火) 01:26:36.91>>278はshift_jsと違うってことが言いたいんだろ
0281デフォルトの名無しさん
2011/07/19(火) 02:20:03.27Windows-31J な。
http://www.iana.org/assignments/character-sets
0282デフォルトの名無しさん
2011/07/19(火) 03:23:11.11その時点でいろいろ知れる
0283デフォルトの名無しさん
2011/07/19(火) 06:06:29.06node.jsの親戚かと。
0284デフォルトの名無しさん
2011/07/19(火) 10:14:52.68MS932とはあまり言わないだろう、Microsoftの「Code Page 932」って規格だから略称としては「CP932」が適切
0285デフォルトの名無しさん
2011/07/19(火) 10:39:36.67MS932はJava語で、おおむね、Windows-31Jを指すはず(IBM版CP932とは違う)
Javaが独自分類表現を使用しているなんて夢にも思わない人がJavaの外に持ち出して恥をかくことがある
0286デフォルトの名無しさん
2011/07/19(火) 11:26:26.690287デフォルトの名無しさん
2011/07/19(火) 11:39:43.38ギョウザを頼んだらシュウマイが出てきた、くらいには違う
0288デフォルトの名無しさん
2011/07/19(火) 11:44:54.65http://ja.wikipedia.org/wiki/Microsoft%e3%82%b3%e3%83%bc%e3%83%89%e3%83%9a%e3%83%bc%e3%82%b8932
0289デフォルトの名無しさん
2011/07/19(火) 14:43:58.560290デフォルトの名無しさん
2011/07/19(火) 15:44:26.12CP932は問題になってはいない
っていうかお前>>278だろ
0291デフォルトの名無しさん
2011/07/19(火) 23:27:12.20聞いたことがない。
0292デフォルトの名無しさん
2011/07/21(木) 23:17:57.44間違いないし、Shift_JISでないのも確かだが、
「シフトジスではない」と言われるとそれは違うだろう。
どう考えてもWindows-31Jはシフトジス。
0293デフォルトの名無しさん
2011/07/21(木) 23:33:26.32|マイクロソフト及び、MS-DOS の OEM ベンダが Shift JIS を独自に拡張した文字コードである。
でたらめな説明だな。
もともとアスキーマイクロソフトが考えた文字コードが「シフトJIS」と呼ばれ、
正確な定義はどこにも無かった。
1997年にJISが「Shift_JIS」を定め、それは世の中にあるシフトJISの
共通部分であるX 0201,X 0208のみを対象としたものだった。
だからShift_JISもWindows-31JもシフトJISの一種でしか無い。
拡張なんて嘘がどこからでてきたんだ。
0294デフォルトの名無しさん
2011/07/21(木) 23:55:46.23wikipedia項目に飛ぶと「Shift_JIS」になってるな。無茶だなw
Windows-31Jは、初期の「Shift JIS」からは文字が足されて拡張されているけど、
その飛び先が「Shift_JIS」ではな。
「Shift_JIS」の項目内で「Shift JIS」と「Shift_JIS」の使い分けが甘い。
0295デフォルトの名無しさん
2011/07/22(金) 02:15:49.92Wikipedia のリンク名には制約があって、「_」と「 」が区別できない。
0296デフォルトの名無しさん
2011/07/22(金) 02:17:52.27他にも記事名に使えない記号ってあるのよね
0297デフォルトの名無しさん
2011/07/23(土) 09:13:21.141. アンダースコアが空白になる
2. ふたつ以上の空白がひとつにまとめられる
3. 先頭と最後の空白が除去される
4. [ ] { } < > | # が使えない
5. : が特殊な意味を持つことがあり、たとえば「:」からはじまるタイトルが作れない
6. 先頭の1文字が大文字になる
7. 長さ制限(UTF-8 で 255バイト以内)がある
リンクするときにはさらに複雑な制約がかかる。
0298デフォルトの名無しさん
2011/07/23(土) 10:12:07.29エスケープ前と後の区別がつけられないできの悪いエンジニアが
作ったんだろうな。そういう人たちがSQLインジェクションとか起こす。
0299デフォルトの名無しさん
2011/07/23(土) 10:46:25.58逆にハッシュ値のような長いURLは不便だし、シリアルナンバーも微妙。
MediaWikiって内部的に持ってる記事名も空白が _ になってたりして、
そのへんの設計も微妙だな。
0300デフォルトの名無しさん
2011/07/23(土) 12:35:06.530301デフォルトの名無しさん
2011/07/23(土) 13:06:04.48http://ja.wikipedia.org/wiki/�~
http://ja.wikipedia.org/wiki/%EF%A8%99
http://ja.wikipedia.org/wiki/%E7%A5%9E
0302デフォルトの名無しさん
2011/07/23(土) 17:00:46.820303デフォルトの名無しさん
2011/07/23(土) 19:16:54.74誰でも修正できるのだから、それをせずに
間違っていると言ったところで信用されない。
言う前に直してから、直したよと報告すればいい。
0304デフォルトの名無しさん
2011/07/23(土) 19:50:47.55これはそうなんだが
>誰でも修正できるのだから、それをせずに
>間違っていると言ったところで信用されない。
こういうことを言う奴って頭おかしいんじゃないかと思う。
ただ間違ってるものを見たときに間違ってると言ってはいけないだろうか。
0305デフォルトの名無しさん
2011/07/23(土) 21:02:27.38俺は>>304みたいのを見ると頭おかしい人なんだなと思うけど
言いたいこと言うのはいいことだと思うようん
0306デフォルトの名無しさん
2011/07/23(土) 21:12:44.57お前は間違っている。
間違っているものを見たので
つい言ってしまったw
0307デフォルトの名無しさん
2011/07/23(土) 21:28:03.23B: それ間違ってるね
A: 間違ってるって言う前に○△を修正しなよ
B: ハァ? 何で俺が○△とかいうのを直さなきゃいけないの
>>304はともかく、>>303が変なのは確定的に明らか
0308デフォルトの名無しさん
2011/07/23(土) 21:32:53.91B: それ間違ってるね
A: 間違ってるって言う前に○△を修正しなよ
B: ハァ? 何で俺が○△とかいうのを直さなきゃいけないの
A: ○△は誰でも修正できるものだから。
0309デフォルトの名無しさん
2011/07/23(土) 21:41:10.14頭だいじょうぶ?
0310デフォルトの名無しさん
2011/07/23(土) 21:44:07.470311デフォルトの名無しさん
2011/07/23(土) 22:19:21.220312デフォルトの名無しさん
2011/07/23(土) 22:44:52.690313デフォルトの名無しさん
2011/07/23(土) 23:11:11.98Windows-31Jって書いておけば問題ない。
0314デフォルトの名無しさん
2011/07/24(日) 10:08:13.04他では通じない。CP932と言ったほうがいい。
0315デフォルトの名無しさん
2011/07/24(日) 10:26:45.922点
レス欲しいなら狂人の真似を
0316デフォルトの名無しさん
2011/07/24(日) 11:58:46.320317デフォルトの名無しさん
2011/07/24(日) 12:50:28.09HTTPのContent-Typeにも(条件付きではあるが)正式に使用できる名前。
なお.NET FrameworkのEncoding.GetEncodingは、文字コード名をパラメーターに
取るのではなくWindowsコードページ名を受け取るので、Windows-31Jは指定できない。
0318デフォルトの名無しさん
2011/07/24(日) 17:21:27.70GetEncodingは.NETのウニコード文字をローカルに
変換するルールでしょ
IANAが決めているのは文字コードであって、
ユニコードとの変換ルールでないんだから当然
0319デフォルトの名無しさん
2011/07/24(日) 20:34:52.28861 :デフォルトの名無しさん:2011/01/04(火) 20:39:59
SJISはウンコ、CP932はウンチ
0320デフォルトの名無しさん
2011/07/25(月) 11:13:51.23"Windows-コードページ番号"で統一できたらよかったのにな。
0321デフォルトの名無しさん
2011/07/25(月) 15:50:16.53内輪ルールがめんどくさすぎて修正しねーことも多いわ
一応、楽に修正できそうな範囲ならするけどな
0322デフォルトの名無しさん
2011/07/25(月) 18:40:44.97特に反日歴史関連は酷い
0323デフォルトの名無しさん
2011/07/25(月) 18:53:37.200324デフォルトの名無しさん
2011/07/25(月) 22:23:54.090325デフォルトの名無しさん
2011/07/26(火) 18:33:59.960326278
2011/07/27(水) 01:27:57.83MS932かCP932あるいはWindows-31J
が正しい
Shift_JISに拡張文字は無い
なので、
「MS932かCP932あるいはWindows-31J」>「Shift_JIS」
なのだろう
それが正確
0327デフォルトの名無しさん
2011/07/27(水) 08:04:57.93シフトジス
├Windows-31J(X 0201,X 0208,NE特殊,NEC選定IBM拡張,IBM拡張)→通称MS932,CP932
└Shift_JIS(X 0201,X 0208)
0328デフォルトの名無しさん
2011/07/27(水) 10:09:52.09ちょろっと読んだ人がしたり顔できるほど相関関係は単純ではない
0329デフォルトの名無しさん
2011/07/27(水) 11:56:11.290330デフォルトの名無しさん
2011/07/27(水) 20:47:15.11コードページの932番というのは正式な番号だけど、
「CP932」という名前はちょっと違うんじゃね
0331デフォルトの名無しさん
2011/07/27(水) 23:11:17.710332デフォルトの名無しさん
2011/07/28(木) 04:13:07.780333デフォルトの名無しさん
2011/07/28(木) 13:21:19.410334デフォルトの名無しさん
2011/07/28(木) 22:52:57.57MSの文書で文字コード名cp932が定義されているソース出してみろや。
コードページの932番じゃなくて「cp932」な
0335デフォルトの名無しさん
2011/07/28(木) 23:41:20.220336デフォルトの名無しさん
2011/07/28(木) 23:41:29.23http://social.msdn.microsoft.com/search/ja-JP?query=cp932
0337デフォルトの名無しさん
2011/07/28(木) 23:48:40.52msdn本家ページにもあるよ。
0338デフォルトの名無しさん
2011/07/29(金) 16:00:03.50ぶっちゃけ心底どうでもいいんだが
0339デフォルトの名無しさん
2011/07/29(金) 23:51:06.97プログラマーやめたほうがいいんじゃねーの
0340デフォルトの名無しさん
2011/07/29(金) 23:59:57.74「コメントを求む」程度の文章でいいんだよ。
0341デフォルトの名無しさん
2011/07/30(土) 02:47:52.950342デフォルトの名無しさん
2011/07/30(土) 10:43:39.89会社のためにしかならないことを
勉強する気にはならない。
0343デフォルトの名無しさん
2011/07/30(土) 14:40:35.21例えば Content-Type=text/htm; charset=Shift_JIS
で、丸付き数字とか送られてきた日にはブチ切れですよ。
僕のパソコンの僕のブラウザでは表示できましたとか言い出すと殺意を覚える
0344デフォルトの名無しさん
2011/07/31(日) 00:31:57.600345デフォルトの名無しさん
2011/07/31(日) 01:37:05.980346デフォルトの名無しさん
2011/07/31(日) 03:22:17.45世の中仕様が全てではないんだよ。
0347デフォルトの名無しさん
2011/07/31(日) 03:33:15.68>>343のは仕様で禁止されたことをやってんでしょ。
それはまずい。
0348デフォルトの名無しさん
2011/07/31(日) 11:22:19.48なら良かったのか
0349デフォルトの名無しさん
2011/07/31(日) 13:39:25.25鯖と端末双方が「�@」を使うと合意した上でWindows-31J使うのが正しいと思う。
0350デフォルトの名無しさん
2011/07/31(日) 22:12:23.38設計が現実を処理できない仕様になってる。
ダメな設計だ。
0351デフォルトの名無しさん
2011/08/01(月) 06:21:06.640352デフォルトの名無しさん
2011/08/01(月) 07:09:08.980353デフォルトの名無しさん
2011/08/04(木) 20:55:45.64SJISをWindows-31Jにすることは妥当だと思うが。
SJISをShift_JISにしたところで安岡センセイ以外喜ばない。
0354デフォルトの名無しさん
2011/08/04(木) 21:26:58.69> SJISをWindows-31Jにする
> SJISをShift_JISに
どういう意味で言っているのか?
「SJIS」とは何なのだ?
0355デフォルトの名無しさん
2011/08/04(木) 22:49:17.030356デフォルトの名無しさん
2011/08/04(木) 22:53:19.600357デフォルトの名無しさん
2011/08/06(土) 00:15:01.41人が立てたんだと思うが、MSだけでなくJavaもUnicode=UTF-16なんだっけ?
0359デフォルトの名無しさん
2011/08/07(日) 04:48:33.66おJAVA様の"Unicode"は
デコード時:ビッグエンディアンUTF-16、BOM許可
エンコード時:ビッグエンディアンUTF-16、BOMあり
Windowsの"Unicode"は
デコード時:リトルエンディアンUTF-16、BOM許可
エンコード時:リトルエンディアンUTF-16、BOMあり
0360デフォルトの名無しさん
2011/08/07(日) 14:43:57.06>UTF-16、BOM許可
冗長な表現だな。UTF-16エンコーディングスキームは常にBOM許可なんだよ。
"UTF-16LE"→BOM禁止
"UTF-16BE"→BOM禁止
"UTF-16"→BOM許可
Javaの"Unicode"は先頭のBOMを読み飛ばすから"UTF-16"。
ちなみにJavaの"UTF-8"はBOMをNBSPと認識する統一性の無い仕様。
Javaも.NETも、文字コードに表現の曖昧さのあるものは
区別できるようならないものかな
"UTF-8" →実行環境の規定のUTF-8表現
"UTF-8:wBOM" →先頭にBOM必須
"UTF-8:w/BOM "→先頭のFEFFはNBSP
"UTF-8:autoBOM" → 先頭にFEFFがあればBOM みたいな
0361デフォルトの名無しさん
2011/08/07(日) 14:47:36.25たとえば、「あいうえおかきくけこ」という文字列を
split関数で2つに分けたとき、「(BOM)あいうえお」「(BOM)かきくけこ」になるのか?
違うだろう?
BOMはマックバイナリみたいなもので
文字の一部ではなくファイル形式の一種だと思うんだが。
0362デフォルトの名無しさん
2011/08/07(日) 14:55:48.67データストリームの先頭にあるとシグネチャと看做されます。
0363デフォルトの名無しさん
2011/08/07(日) 15:02:40.62Unicode 6.0の16.8には「U+FEFF at the very beginning of a file or stream」とあるね。
ただの文字列がstreamに含まれるかと言えば普通の感覚ではNoだけど、
絶対ダメと断言するには表現が曖昧な気がする。
streamの定義をきかれたら「一連のcharacter」としか言いようが無いから。
0364デフォルトの名無しさん
2011/08/07(日) 15:29:54.27http://unicode.org/faq/utf_bom.html#bom1
Byte Order Mark (BOM) FAQ
Q: What is a BOM?
A: A byte order mark (BOM) consists of the character code U+FEFF at
the beginning of a data stream, where it can be used as a signature
defining the byte order and encoding form, primarily of unmarked
plaintext files. Under some higher level protocols, use of a BOM may
be mandatory (or prohibited) in the Unicode data stream defined in
that protocol. [AF]
0365デフォルトの名無しさん
2011/08/07(日) 16:33:38.94プログラマやめた方がいいんじゃねーの
0366デフォルトの名無しさん
2011/08/07(日) 23:35:37.51>はっきりとin the unicode data streamと書いてる
一つ前のレスも読めないのか
0367デフォルトの名無しさん
2011/08/07(日) 23:49:21.22何かよくわからないけど、
わざわざ書いてるってことは、
特別扱い、つまり通常の文字とは別扱いなんだな。
0368デフォルトの名無しさん
2011/08/07(日) 23:52:20.46BOMになり得ない。
encoding scheme: バイトデータ表現。BOMが付くことがある
encoding form:「文字」単位の表現。BOMの概念無し。splitで扱うのはこっち
char型(UTF-16/32文字)のFEFFはZWNBSとみなさなければならない。
それをバイトデータにエンコードして初めてBOMが付く。
0369デフォルトの名無しさん
2011/08/07(日) 23:55:16.42切り替わるの?
0370デフォルトの名無しさん
2011/08/08(月) 00:01:50.41バイト配列をwchar_t(C)とかchar(Java)にデコードした時点でBOMは消えなきゃいけないの。
ちなみに途中にあらわれるものはBOMでなくU+FEFF文字として扱わなければならない
0371デフォルトの名無しさん
2011/08/08(月) 01:07:46.83本当は途中に現れちゃ駄目。
0372デフォルトの名無しさん
2011/08/08(月) 01:17:08.95読み込むプログラムは処理しなきゃいけないってこった
0373デフォルトの名無しさん
2011/08/13(土) 06:53:27.25質問は以下2点で、例えば、EUC-JPのテキストをエディタで編集中とします。
1.MS-IMEで変換中(この時の文字コードは?)
2.変換した文字を確定(変換中の文字コード → EUC-JPの変換は誰がどのタイミングで行っているのでしょうか?)
0374デフォルトの名無しさん
2011/08/13(土) 10:46:33.191.ふつうはUTF-16
2.ふつうはテキストエディタの保存時
0375デフォルトの名無しさん
2011/08/13(土) 10:57:29.48普通はEUC-JPで表現できない文字も入力できて、保存時にエラーが出るよね。
ってことは編集中はEUC-JPじゃないってこった
0376デフォルトの名無しさん
2011/08/13(土) 12:10:50.38なるほど。
�d
0377デフォルトの名無しさん
2011/08/14(日) 01:13:50.65UNIXのshebangってBOMに対応できないの?
0378デフォルトの名無しさん
2011/08/14(日) 01:17:53.45ところで、まずBOMの有無をチェックするように改造すれば可能かも。
0379デフォルトの名無しさん
2011/08/14(日) 01:26:25.04・UTF-16BEのU+FEFF, U+0000
・UTF-16のBOM, U+0000
・UTF-32のBOM
のいずれであるかの見分けはつくのでしょうか
0380デフォルトの名無しさん
2011/08/14(日) 01:53:40.23そのバイトオーダーでは迷う要素がどこにもないのだが…
0381デフォルトの名無しさん
2011/08/14(日) 04:44:20.21エンコードスキームがutf-16なのかutf-16beなのか
の情報が必要。
つまりエンコードスキーム情報無しに読むことは不可
0382デフォルトの名無しさん
2011/08/14(日) 04:45:13.50そのバイトオーダーでは迷う要素がどこにもないのだが…
0383デフォルトの名無しさん
2011/08/14(日) 04:57:36.54ならff fe 00 00ならどうするのよ?
0384デフォルトの名無しさん
2011/08/15(月) 00:39:15.78FE FF 00 00ってのは例が悪くて>>383の間違いなんだろうけど、
「FE FF」にしたってBOMなのかU+FEFFなのか区別付かないよね?
0385デフォルトの名無しさん
2011/08/15(月) 00:50:44.72ただしUTF-16LEによるBOM + U+0000という解釈とUTF-32LEによるBOMという解釈のどちらをとるべきかは
一意に決定する方法がない、という意味で>>383の指摘は正しいものだと思う。
0386デフォルトの名無しさん
2011/08/15(月) 01:05:17.86バイトオーダマークであってエンコーディングを示すものじゃないから諦めろってさ
0387デフォルトの名無しさん
2011/08/15(月) 02:30:12.19>先頭のU+FEFFは常にBOMと解釈すべし
んなこたーない。
Unicode 6.0.0「3.10 Unicode Encoding Schemes」D96
『In UTF-16BE, an initial byte sequence <FE FF> is interpreted as U+FEFF zero width no-break space』
D98
『In the UTF-16 encoding scheme, an initial byte sequence corresponding to U+FEFF is interpreted as a byte order mark』
UTF-16BEなら先頭のFE FFはU+FEFF。UTF-16なら先頭のFE FFはBOM。データから区別は出来ない。
0388デフォルトの名無しさん
2011/08/18(木) 00:42:00.98BOM考えた奴、ばかなの?
0389デフォルトの名無しさん
2011/08/18(木) 07:30:27.150390デフォルトの名無しさん
2011/08/18(木) 22:29:40.94どの辺が馬鹿の塊なのか解説よろしく
0391デフォルトの名無しさん
2011/08/19(金) 15:06:30.400392デフォルトの名無しさん
2011/08/19(金) 20:08:38.830393デフォルトの名無しさん
2011/08/28(日) 23:49:09.53当初16 bitで収まると考えていたことなんか、素人の俺にもすぐに指摘できる。
0394デフォルトの名無しさん
2011/08/29(月) 01:00:05.33かつてそう考えたミスは事実だが、今はコードポイントが
U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で
対応出来てるだろ。
「Unicode自体が馬鹿の塊」の理由は説明出来ないのかな?
0395デフォルトの名無しさん
2011/08/29(月) 01:32:35.26正規化すると互換漢字が統一漢字になるところは時々キレそうになる
自分は異体字セレクタでやればいいんだけど、他人に渡す時に対応エディタがないから揉める
あと他人から受け取ったファイルに互換漢字が大量に含まれてたりするともうね・・・
0396デフォルトの名無しさん
2011/08/29(月) 01:43:05.53無理はあるだろ
16bitとか考えなきゃ、最初っからCJKなんて無謀なこともしないで済んだし、そうすればコード変換の
コストも大幅に軽減されたし、i18n対応のソフトがフォントでつまずくようなことも起きなかったし
他にもさまざまな問題が事前にことごとく指摘されてたのに強行して、結局無理でした、だからな
0397デフォルトの名無しさん
2011/08/29(月) 02:27:50.75> かつてそう考えたミスは事実だが、今はコードポイントが
> U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で
> 対応出来てるだろ。
その代償として、Unicodeは複雑化してしまった。
UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。
最初から世の中の文字はすべて32bitで扱うとなっていれば、プログラムも簡単だっただろうに。
OS、言語、すべてが同じUTF-32を使う。さっさと移行しておけばよかったのに。
第一の失敗UTF-16、これがあったせいでWindows、Mac、JavaはUTF-16を
標準のものとしてサポートしてしまった。今更UTF-32にはやすやすと移行できないだろう。
おかげでサロゲートペア対応とか変なモノが後で導入された。
第二の失敗UTF-8、これのせいでUnix系はASCII文字と互換性を保てるようになってしまった。
そのせいで、UTF-8はなかなか消せなくなっただろう。
もう一文字がすべて同じ32bitの世界は絶望的だよ。
0398デフォルトの名無しさん
2011/08/29(月) 03:31:52.42いや、それは結合文字ある時点で絶望的だろ、と突っ込んでみる
UTF-16がクソなのは同意だがUTF-8は需要多かったからどの道生まれただろうし
0399デフォルトの名無しさん
2011/08/29(月) 08:01:59.08自分の処理目的に適した基準でnormalizeすれば良いよ。decompositionだけ無くすとかね。
外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
OSXだと互換漢字は除外してnormalizeするAPIとかも用意されてる。
0400デフォルトの名無しさん
2011/08/29(月) 08:11:50.680401デフォルトの名無しさん
2011/08/29(月) 11:17:14.000402デフォルトの名無しさん
2011/08/29(月) 11:41:22.44要件にわざわざ『Unicode正規化(C方式)』と入ってなければ
或いは、送ったファイルが何故か相手側で正規化される、そんな可能性が無視できるなら
Apple独自規格だろうがなんだろうが喜んで使おう
ただ、その場合はそもそも正規化する必要がないんだけど
0403デフォルトの名無しさん
2011/08/29(月) 11:55:21.11>外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。
必要だからやる→>>395
自分勝手にnormalizeしたところで何の解決にもならん罠
0404デフォルトの名無しさん
2011/08/30(火) 22:01:52.91いろいろ面倒なんだよなあ。
例えば、外部からきたUSBメモリ上のパス名まで正規化されているかどうかとか。
内部的には正規化してから処理するとしても、
再度書きこむ時に正規化すべきか、それとも元のままにしておくか、
元のままにしておく場合、保存しておかなければならないし。
>>397
> UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。
ちょっとこの列挙の仕方はどうかと。
言わんとしていることは分からないでもないが、
最初から32bitじゃまとまらなかっただろう。
0405デフォルトの名無しさん
2011/08/31(水) 10:41:56.92かといって妥協しまくりのダメ仕様でも誰も使わない。
その結果を一見して「迷走」と決めつけることは誰にもできるw
0406デフォルトの名無しさん
2011/08/31(水) 11:50:16.720407デフォルトの名無しさん
2011/09/01(木) 14:44:18.72どうなっていたのと思うの?
0408デフォルトの名無しさん
2011/09/01(木) 19:30:44.11でも互換漢字の中に統合漢字を適当に混ぜるとか、何も考えてないのは丸わかり
規格作ってるやつらは実装しなくていいんだから楽だよなあ
0409デフォルトの名無しさん
2011/09/02(金) 12:27:42.35ないものを攻撃している奴は馬鹿。
仕方ない妥協があるだけ。
0410デフォルトの名無しさん
2011/09/02(金) 12:47:09.80馬鹿が都合悪い部分放置でそのままreleaseしたんだろ
なんで「仕方なかった」なんて嘘が通ると思うのか
まだ「必要だった」って言い訳のほうがマシだよ
0411デフォルトの名無しさん
2011/09/02(金) 13:14:29.07>>408だけど、妥協そのものを攻撃してるんじゃなくて
>>399みたいな開き直りについて言ってるだけだから
必要とか仕方ないとかそのへんの細かいニュアンスは俺の言ってる本筋とは関係ないから
0412デフォルトの名無しさん
2011/09/02(金) 13:15:49.10>>399じゃなくて>>405ね
0413デフォルトの名無しさん
2011/09/02(金) 15:51:45.81単に憶測で6万語で収まると判断したのか?
0414デフォルトの名無しさん
2011/09/02(金) 18:11:44.98Xerox(とApple)でHan Unificationが研究されたから、
Unicodeが誕生のきっかけが出来た。
日本ではEmacsやArenaの多言語化を、
ISO 2022ベースでやっていた頃。
0415デフォルトの名無しさん
2011/09/04(日) 05:22:06.88最初から、というか、最初だけ。
誕生のきっかけであって、もう今ではとてもじゃないが、機能してるとは言えん
同じ字体が互換漢字・互換漢字両方で表せるのがまずおかしいのに
さらにKS X 1001とかいう規格から、同じ字体で読みだけが違う互換漢字も追加されて
統一漢字+異体字セレクタで統一漢字でも字体を変更できるようになって
と思ったら異体字セレクタに汎用電子がAdobeと同じ字体を重複登録しはじめて
トドメに、異なった統一漢字同士でも異体字セレクタによっては同じ字体になるんだから……
0416デフォルトの名無しさん
2011/09/04(日) 17:42:35.37> 機能してるとは言えん
はあ?
0417デフォルトの名無しさん
2011/09/04(日) 19:33:51.550418デフォルトの名無しさん
2011/09/05(月) 04:04:33.030419デフォルトの名無しさん
2011/09/05(月) 22:01:45.96アンダースコアの有る無しで意味が違う、っていうことの方が狂気の沙汰だと思う
0420デフォルトの名無しさん
2011/09/05(月) 22:32:53.250421デフォルトの名無しさん
2011/09/06(火) 01:33:22.310422デフォルトの名無しさん
2011/09/06(火) 02:42:07.110423デフォルトの名無しさん
2011/09/10(土) 15:51:03.10まずいよこれ無理だよ、ってのは少なくとも日本の機関や企業から結構発信してたはず
0424デフォルトの名無しさん
2011/09/10(土) 18:02:22.29収めるためのHan Unificationが適切かどうかが議論になった。
>>414
> Unicodeは最初からHan Unificationありき。
> Xerox(とApple)でHan Unificationが研究されたから、
> Unicodeが誕生のきっかけが出来た。
0425デフォルトの名無しさん
2011/09/10(土) 18:18:33.200426デフォルトの名無しさん
2011/09/10(土) 23:32:57.710427デフォルトの名無しさん
2011/11/08(火) 00:10:00.22それでも説得して変えさせることは出来なかった。
かといって代替を用意して
それを普及させるだけの力もなかった。
ガラパゴス規格を作っては国内オンリーで威張る
だけの親方日の丸体質では最初から無理でした。
せめて今後は上手く捻じ込む交渉術を学んでいただきたいものです。
無理か。無能なJIS関係者や学者に金撒くんじゃなくて
最初から、ロビイストに金を突っ込むのが正しいな。
0428デフォルトの名無しさん
2011/11/08(火) 00:46:24.54文字コードには詳しくないんだけど
プログラマのための文字コード入門読む限りでは
今後もシフトJISを使うのが一番安全という気がひしひしとしてくる。
実際、Windowsも内部はUnicodeだけどインタフェースはNLSを通してシフトJISを使うわけだし。
0429デフォルトの名無しさん
2011/11/08(火) 00:51:01.900430デフォルトの名無しさん
2011/11/08(火) 01:05:01.980431デフォルトの名無しさん
2011/11/08(火) 01:09:02.770432デフォルトの名無しさん
2011/11/08(火) 01:21:12.38ソースコードもHTMLもデータベースもテキストファイルも全部ウニコードにしてる。
ただメールだけはISO-2022-JPでないと文字化けする糞アプリが存在するので
なかなかUTF-8に移行できない。
0433デフォルトの名無しさん
2011/11/08(火) 01:24:56.95コマンドプロンプトも未だにうにコード使えないし、ファイルシステム事態はうにコードを使えても
ファイル名をやり取りするAPIの中にうにコード版が存在しないものが…
WindowsだけシフトJISで。
0434デフォルトの名無しさん
2011/11/08(火) 01:32:12.35cp 65001
0435デフォルトの名無しさん
2011/11/08(火) 01:39:37.21ttp://yukarin.wiki.fc2.com/wiki/Tips
0436デフォルトの名無しさん
2011/11/08(火) 02:07:10.34あとはVC++がlocaleにうにコードをセットできるようになってくれれば解決だ。
0437デフォルトの名無しさん
2011/11/08(火) 02:07:27.82chcp 65001すると今まで動いてた以下のコードが正しく動かないんだがどうすればいい?
_tsetlocale(LC_CTYPE, _T(""));
_tprintf(_T("マンコ\n"));
0438デフォルトの名無しさん
2011/11/08(火) 02:56:46.070439デフォルトの名無しさん
2011/11/08(火) 08:53:05.570440デフォルトの名無しさん
2011/11/17(木) 03:47:25.53囿圀圁圂圃圄圅圆圇圈圉圊國圌圍圎圏圐圑園圓圔圕圖圗團圙圚圛圜圝圞
0441デフォルトの名無しさん
2011/11/19(土) 21:17:47.39むしろ自分の周りだとWindows以外のシステムはいろいろあるけど
情報交換はシフトJISでまず問題がない。ユニコードにお目にかかる
ことのほうが滅多にない。
0442デフォルトの名無しさん
2011/11/20(日) 04:14:11.87> 情報交換はシフトJISでまず問題がない。
老害しねや
0443デフォルトの名無しさん
2011/11/20(日) 11:36:54.270444デフォルトの名無しさん
2011/11/20(日) 12:29:01.950445デフォルトの名無しさん
2011/11/20(日) 20:58:49.780446デフォルトの名無しさん
2011/11/20(日) 21:12:01.100447デフォルトの名無しさん
2011/11/20(日) 21:17:11.831000人に1も居ないんだから、異体字なんて駆逐してしまえ。
国も時代に合わせろよ。
0448デフォルトの名無しさん
2011/11/20(日) 22:39:49.130449デフォルトの名無しさん
2011/11/21(月) 02:15:21.62互換漢字とか話をすり替えてユニコード批判するしかないとは。
いつまで20世紀に生きてるんだよ
0450デフォルトの名無しさん
2011/11/21(月) 13:52:38.60当然だけどShift_JISが使えない規格ってのが大前提だが
>>449みたいなやつも程度としては>>441と同レベルだわ
デメリットないとか本気で言ってんならな
そりゃ、ソフトウェアを源規格分離のUnicodeで作るだけなら楽だけど
使うやつはUnicodeのことなんてなにも分かっちゃいないんだぞ
使われてるうちにデータがどういう惨状になるか分かってんのか……
0451デフォルトの名無しさん
2011/11/21(月) 15:03:02.410452デフォルトの名無しさん
2011/11/23(水) 20:24:22.16合成漢字とか、マイナーな漢字で問題が有るっちゃあるらしい。
だから、PDFに複数のエンコーディングを同時に使いたいという需要が
あったりする。
0453デフォルトの名無しさん
2011/11/24(木) 08:26:11.02その致命的欠点が前世紀からそのままであるという事実は変わらないけどなw
0454デフォルトの名無しさん
2011/11/24(木) 20:20:13.17それは別に致命的な欠点ではないだろう
統一漢字をせっかくまとめたのに、互換漢字を作ったのが失敗なんだよ
最初から異体字はセレクタでよかった
0455デフォルトの名無しさん
2011/11/24(木) 20:50:09.360456デフォルトの名無しさん
2011/11/24(木) 20:56:22.920457デフォルトの名無しさん
2011/11/26(土) 11:51:28.970458デフォルトの名無しさん
2012/01/09(月) 10:04:59.130459デフォルトの名無しさん
2012/01/09(月) 10:20:35.330460デフォルトの名無しさん
2012/01/15(日) 21:54:45.42コンセンサスが得られたってことでいいんだよな
Unicode: UTF-16リトルエンディアンBOMあり
UTF-8: よく使うアレ
0461デフォルトの名無しさん
2012/01/16(月) 09:15:50.56MSがそう表記したがってるのは事実。
'Unicode'と'UTF-16LE'を同一視するような言い方をすれば
頭の弱いかわいそうな人と見なされる。
少なくともそいつと技術の話はできない。
0462デフォルトの名無しさん
2012/01/16(月) 14:23:26.170463デフォルトの名無しさん
2012/01/16(月) 15:19:44.52使わねーよ。よほど古い、1990年代にかかれたような文書ならともかく。
単に文字列の内部表現がUTF-16というだけ。
0464デフォルトの名無しさん
2012/01/16(月) 15:45:26.600465デフォルトの名無しさん
2012/01/16(月) 17:06:14.950466デフォルトの名無しさん
2012/01/16(月) 18:40:17.48MSは、単に旧時代の言い方をいつまでも引きずっているだけ。別にそう表記したがっているわけじゃない
0467デフォルトの名無しさん
2012/01/16(月) 18:43:23.43でも時代は変わったんだからマイクロソフトは自分の所でしか通じない用語は改善するべきだと思う
0468デフォルトの名無しさん
2012/01/16(月) 22:54:53.28System.out.printf(new String(new byte[]{(byte)0x30, (byte)0x70, (byte)0x30, (byte)0x4B}, "Unicode"));
0469デフォルトの名無しさん
2012/01/17(火) 08:39:03.980470デフォルトの名無しさん
2012/01/17(火) 13:55:57.57MSと同じ
0471デフォルトの名無しさん
2012/01/17(火) 14:10:23.18そりゃ、無理な相談だ
0472デフォルトの名無しさん
2012/01/28(土) 03:34:36.69日本語でおk
0473デフォルトの名無しさん
2012/01/28(土) 23:14:28.00Unicodeは規格の名前だが、文字集合の意味で使われたり、UTF-16の意味で使われたり、意味も分からずユニコードと言ってみたりカオス?
0474デフォルトの名無しさん
2012/01/29(日) 07:23:52.010475デフォルトの名無しさん
2012/02/07(火) 21:50:52.80-> ascii (7bit)
んじゃ「頭に1つけたときは半角カタカナ」ってことにしといたらasciiに日本語混ぜれるんじゃね?
いろは47文字に濁点、半濁点、カギカッコとか句読点も入れとくわ。
日本でバックスラッシュとか使わんからこいつは円記号と一緒なwww俺天才ww
-> JIS X 0201
アルファベットだけじゃヨーロッパは物足りないんで、
日本が半角カナ入れたところにウムラウト付きの文字とか入れときます。
-> latin-1
漢字絶対必要なんで、asciiとかほっといてとりあえず2バイトで表現できる文字集合選定しときます。
限りある空間資源なんで「掴」と「摑」とかは一緒ってことで堪忍してください。(包摂)
あ、英語書く時は全部全角でおながいします。
-> 97JIS符号化方式によるJIS X 0208文字集合の利用
いやいや、英語重要なんで。マジ。無視とかありえないんで。
はい、頭が1のバイト隣同士でasciiサンに迷惑かけないよう二人組作ってー。
JIS X 0201のカナ文字は無視しておk。これでJIS X 0208の文字も表現できる。
……あれ、半角と全角でアルファベットダブっちまってるけど……まいいか。
-> EUC-JP
おい、メールは7bit符号しか使ったあかんらしいぞ。えー。
切替用の透明文字(エスケープ文字)作ってその文字以降はそれぞれのコードってことにしよ。
-> ISO-2022-JP
asciiもJIS X 0201の半角カナも無視とか親泣くぞ。過去の遺産大事にしろ。
まぁ漢字使いたいけどエスケープ文字とかダルすぎるし、
JIS X 0201の空いたトコもらって2byteで使わせてもらうわ。
え?そこは制御文字用って?知るかボケ。
-> Shift_JIS
0476デフォルトの名無しさん
2012/02/07(火) 21:51:23.32分かった分かった。お前ら黙れ。4バイトで世界中の文字全部平等に並べ直そう。な。
-> ISO/IEC 10646
ちょっとまって同じ事やろうとしてるんだけど。2byteで。
-> Unicode
足並みそろえよか。4byteやけど上2byte全部0の実質Unicodeでやってこや。
おうアジアの土人ども、母国語の文字数すら数えられんのに大きい顔すんなよ?
迷惑なんだから、似たような文字はガンガン同じにまとめとけ。(CJK統合漢字)
-> 10646とUnicodeサブセット
メンゴメンゴ。65536個じゃ足らんかったわw
Unicodeの2byte2つ組み合わせる方針にします。
2つのbyteのうち前後どっちを先にするかは文章の始めに印を付けて表すことにしましょう。(BOM)
素直に全部前から読む時はビッグエンディアン、天邪鬼さんはリトルエンディアンってことで。
でもでも、やっぱよく使う文字とよく使わない文字が同じビット数占拠するのもバカらしいんでー、
よく使う文字(BMPの文字)は2byte単体、それ以外は2つくっつけて表す事にします。(サロゲートペア)
-> UTF-16
結局くっつけるんかいwwwそれやったらasciiとの互換も考えれwww
1文字あたりのバイト数は可変長だけどasciiの文字しか使わなかったらasciiと一緒になる。
-> UTF-8
サロゲートペアは甘え。容量も懐も大きいとこ見せろ。
Unicodeをそのまま直書きで4byte固定符号化方式。どや。
Unicodeの文字並び(U+00303Dとか)がそのまんま0000303Dで分かりやすい。
-> UTF-32
0477デフォルトの名無しさん
2012/02/07(火) 23:14:02.83もうどんな符号化文字集合を持ってきても絶対に誰も幸せになれない。
0478デフォルトの名無しさん
2012/02/07(火) 23:57:30.91Unicodeの意味をを勘違いしている典型例ですね
円コーディングフォームと円コーディングスキームの区別もつかなくて、
リトルエンディアンが天の邪鬼とか言い出すバカ
0479デフォルトの名無しさん
2012/02/08(水) 00:00:19.790480デフォルトの名無しさん
2012/02/08(水) 00:07:39.590481デフォルトの名無しさん
2012/02/08(水) 07:36:46.600482デフォルトの名無しさん
2012/02/08(水) 16:12:14.160483デフォルトの名無しさん
2012/02/08(水) 17:20:13.44-> ascii (7bit)
アイちゃん言語訓練には足りないね。
-> UTF-32
0484デフォルトの名無しさん
2012/02/08(水) 18:50:51.840485デフォルトの名無しさん
2012/02/08(水) 23:04:17.540486デフォルトの名無しさん
2012/02/09(木) 01:11:51.860487デフォルトの名無しさん
2012/02/09(木) 23:29:02.94エンディアンの説明がおかしい他はいい線いってる。
時系列を変えてるのはわかりやすさのためだろ
0488デフォルトの名無しさん
2012/02/10(金) 00:57:08.24Intel CPUはリトルエンディアンだが
整数値を小さな型にキャストしようとする時
先頭アドレスを変えずに読み込みを途中で打ち切るだけで済む。
ビッグエンディアンだとスライドさせないといけない。
その分リソースを食う。
でも数値をどこかで切り捨てたい時とか上から順にダンプかけたいときは
メリット・デメリットが逆になる。
円記号問題の根底はJIS X 0201というよりISO 646各国版の普及にあって、
もっと世界的なもんじゃないのか? トライグラフとか。
誰か詳しい人解説頼む。
0489デフォルトの名無しさん
2012/02/10(金) 08:33:56.110490デフォルトの名無しさん
2012/02/10(金) 21:48:22.400491デフォルトの名無しさん
2012/02/11(土) 01:09:06.040492デフォルトの名無しさん
2012/02/11(土) 08:38:33.85ワード長の拡張で、対応がずれる、以外のディスアドバンテージがあるならどうぞ。
0493デフォルトの名無しさん
2012/02/11(土) 09:53:05.21ビッグエンディアンは奇数アドレスアクセスとかできないでしょ。
GIF画像の圧縮みたいな可変ビット長データの連続してパッキングは、ビッグエンディアンじゃやってられない。
デメリットは「ビットの上位の方向とバイトの上位の方向が逆」に尽きる。
0494デフォルトの名無しさん
2012/02/11(土) 10:07:27.290495デフォルトの名無しさん
2012/02/11(土) 10:10:47.68MSBがアドレス0だよ?
ビットアドレスが2の冪と対応してない、とは言えるけど、直感的でない、以外に問題ある?
0496デフォルトの名無しさん
2012/02/11(土) 10:21:38.524バイト整数12345678hの上位バイト12が上位メモリアドレス3に書かれるのがリトル。
4バイト整数12345678hの上位バイト12が下位メモリアドレス0に書かれるのがビッグ。
FFhに1足して上位桁に繰り上がったら、より下位のアドレスが変わるなんて変と思わないの?
0497デフォルトの名無しさん
2012/02/11(土) 10:31:03.800498デフォルトの名無しさん
2012/02/11(土) 10:41:26.87こういうバカがビッグエンディアンを設計したんだろうな
0499デフォルトの名無しさん
2012/02/11(土) 10:49:46.08リトルエンディアン信者は当然使わないよなw
0500デフォルトの名無しさん
2012/02/11(土) 11:02:53.62準TADのTRONコードでも使ってろw
0501デフォルトの名無しさん
2012/02/11(土) 11:44:58.61考えたのはM$だからな。
0502デフォルトの名無しさん
2012/02/11(土) 11:48:27.560503デフォルトの名無しさん
2012/02/11(土) 11:51:29.54cpuがメモリに直接ワードアクセスする時のメモリイメージの話と、
バイトオリエントにシリアライズしたutf-8の話を一緒にするのはいくないぜ
0504デフォルトの名無しさん
2012/02/11(土) 12:13:02.50いやほんとbomのおかげで助かるわ。
utf-8とその他のコードをほぼ確実に判別できる
0505デフォルトの名無しさん
2012/02/11(土) 20:26:42.27utf-8なのにBOMって
0506デフォルトの名無しさん
2012/02/11(土) 21:38:11.32何か問題が?
UTF-8のシグネチャーとして大活躍じゃないか
0507デフォルトの名無しさん
2012/02/12(日) 02:20:34.14援交ディングスキームシグネチャー
これでおk
0508デフォルトの名無しさん
2012/02/12(日) 02:52:52.82みたいだな
0509デフォルトの名無しさん
2012/02/12(日) 08:16:34.20例えばUTF-16の場合、先頭の<FE FF>はU+FEFFでなくBOMと見なす必要がありますが、
UTF-8ではUnicode 6の3.10D95をみると『can』とあるので、UTF-8の先頭の<EF BB BF>を
U+FEFFと見なすことは禁止されていないように見えます。
先頭<EF BB BF>の解釈は自由という理解で良いでしょうか?
0510デフォルトの名無しさん
2012/02/12(日) 11:27:09.360511デフォルトの名無しさん
2012/02/12(日) 12:25:31.410512デフォルトの名無しさん
2012/02/12(日) 15:56:41.470513デフォルトの名無しさん
2012/02/12(日) 23:11:21.560514デフォルトの名無しさん
2012/02/12(日) 23:28:04.18はい
0515デフォルトの名無しさん
2012/02/13(月) 00:47:58.80ソースキボンヌ
0516デフォルトの名無しさん
2012/02/13(月) 12:43:00.82のU+FEFFで、non-breakingは代わりにU+2060を使ってね、と。
http://www.unicode.org/charts/PDF/U2000.pdf
のU+2060で、BOMの曖昧さを無くす為に、と。
その方向で行こうね、位の意味合い?
0517デフォルトの名無しさん
2012/02/13(月) 23:32:42.50で、UTF-8ではUTF-16やUTF-32から変換されたときBOMが付くことがあって、
UTF-8としては不要だけどUTF-8かどうかの識別として使えるし違反ではないよ。
途中のU+FEFFは、ZWNBSPとして扱うけどなるべくU+2060を使ってね。
こんな感じの認識でいい?
0518デフォルトの名無しさん
2012/02/14(火) 07:21:36.14いいと思うけど、細かい所がちょっと違う。
先頭のFE FFやFF FEの2バイトは、UTF-16ではBOMで、UTF-16LEやUTF-16BEではZWNBSP文字相当になる。
バイナリデータ(Encoding Scheme)をEncoding Formに読み取った時点でBOMは無くなる。
U+FEFFというのはUTF-16orUTF-32のEncoding FormだからBOMになり得ない。
>UTF-16やUTF-32から変換されたときBOMが付くことがあって
これも同じく、Encoding FormをEncoding Schemeに変換したときにBOMが付くことがある
0519デフォルトの名無しさん
2012/02/14(火) 07:47:25.15コードポイント: u+feff (ZWNBS文字(非推奨))
UTF-16エンコードフォーム: <FEFF>(16ビット単位、u+は付かない)
UTF-16エンコードスキーム: <FE FF FE FF>または<FF FE FF FE> (8バイト単位)。先頭のFE FFはBOM
UTF-16BEエンコードスキーム: <FE FF>(8バイト単位)、先頭の<FE FF>はZWNBS文字だがZWNBSが非推奨
0520デフォルトの名無しさん
2012/02/14(火) 13:05:58.680521デフォルトの名無しさん
2012/02/14(火) 17:43:30.45> kHanyuPinyin 10760.010:g�i
文字化けワロス
0522デフォルトの名無しさん
2012/02/19(日) 00:37:27.030523デフォルトの名無しさん
2012/02/19(日) 01:31:55.27UTF-8・・・文字表現
です
0524デフォルトの名無しさん
2012/02/19(日) 01:37:04.34ほう、ではUnicode 6.0のどこに「Unicodeが文字集合の一つ」と
書かれているのかね?
0525デフォルトの名無しさん
2012/02/19(日) 01:40:16.48自分でぐぐってください。
0526デフォルトの名無しさん
2012/02/19(日) 01:42:59.62プログラマーに剥いていない
0527デフォルトの名無しさん
2012/02/19(日) 01:47:33.040528デフォルトの名無しさん
2012/02/19(日) 01:49:36.680529デフォルトの名無しさん
2012/02/19(日) 01:57:06.64向いてない人「ちょっとくらいいいでしょ?多めに見てよ」
コンピュータ「はあ?」
0530デフォルトの名無しさん
2012/02/19(日) 02:11:33.760531デフォルトの名無しさん
2012/02/19(日) 02:23:21.28(T-T)悲しい
(^-^)うれしい
こんなのが最近たくさん追加されてるだろ
0532522
2012/02/19(日) 02:54:14.520533デフォルトの名無しさん
2012/02/19(日) 15:37:07.51痴呆があらわれたか
0534デフォルトの名無しさん
2012/02/19(日) 22:52:12.18一般人に違いなどわからんからこれでよし
0535デフォルトの名無しさん
2012/02/19(日) 23:03:51.630536デフォルトの名無しさん
2012/02/20(月) 11:24:52.62UTF-8
UTF-16BE
UTF-16LE
UTF-32BE
UTF-32LE
マイクロソフトが追加した規格 (いずれもBOM付き)
UTF-8 (上記と重複する)
UTF-16 (省略BE-BOM)
UTF-16LE-BOM
UTF-32 (省略BE-BOM)
UTF-32BE-BOM
UTF-32LE-BOM
ってことでよろしいですか?
0537デフォルトの名無しさん
2012/02/20(月) 18:09:07.050538デフォルトの名無しさん
2012/02/20(月) 18:10:40.38そろそろencoding formとencoding schemeの違いを
理解した方がいいよ
0539デフォルトの名無しさん
2012/02/20(月) 20:38:04.20UTF-8 (BOMなし) ←MSの「UTF-8」
UTF-8 (BOM付き)
UTF-16 (BOMなしBE、先頭にU+FEFFは書けない)
UTF-16 (BOMありBE、先頭の<FE FF>はU+FEFFでなくBOM) ←MSの「Unicode big endian」
UTF-16 (BOMありLE、先頭の<FF FE>はU+FEFFでなくBOM) ←MSの「Unicode」
UTF-16BE (BOMなしBE、先頭の<FE FF>はBOMでなくU+FEFF)
UTF-16LE (BOMなしLE、先頭の<FF FE>はBOMでなくU+FEFF)
UTF-32 (BOMなしBE、先頭にU+FEFFは書けない)
UTF-32 (BOMありBE、先頭の<00 00 FE FF>はU+FEFFでなくBOM)
UTF-32 (BOMありLE、先頭の<FF FE 00 00>はU+FEFFでなくBOM)
UTF-32BE (BOMなしBE、先頭の<00 00 FE FF>はBOMでなくU+FEFF)
UTF-32LE (BOMなしLE、先頭の<FF FE 00 00>はBOMでなくU+FEFF)
0540デフォルトの名無しさん
2012/02/20(月) 20:40:31.47UTF-8 (BOMなし)
UTF-8 (BOMあり) ←MSの「UTF-8」
0541デフォルトの名無しさん
2012/02/20(月) 23:14:05.93Unicodeにそんな仕様はいってるの?
0542デフォルトの名無しさん
2012/02/21(火) 00:42:33.77なければどんなに幸せだったことか…
BOMのない世界にforkしたい。
0543デフォルトの名無しさん
2012/02/21(火) 04:01:27.70あって困ったことはありませぬ。
0544デフォルトの名無しさん
2012/02/21(火) 04:24:21.160545デフォルトの名無しさん
2012/02/21(火) 05:19:27.61文字コード不明なファイルを読み取ろうとするシバンはウンコ(・∀・)ノ●。
日本語のパスはどうすんだよ。
0546デフォルトの名無しさん
2012/02/21(火) 06:46:27.45まだ ISO-10646 が正式な規格になる以前からありますがな。
0547デフォルトの名無しさん
2012/02/21(火) 17:29:35.79えーなんでダメなんだよ?これjavaのエンコードライブラリそのまんまなんだぜ?
0548デフォルトの名無しさん
2012/02/21(火) 20:08:10.74JavaはBOM周りの処理のバグを認識しつつ
バグを永久に直さないことに決定済みだろ
『マイクロソフトが追加した規格』が『おJavaの認識する名前』で
BOMがMS独自という誤った記述が無ければおけ
0549デフォルトの名無しさん
2012/02/21(火) 22:38:40.98shebangに関して言えば、
shebangを読み取るプログラムが
Unicodeに対応していないというべきだろうね。
たぶん、UTF32で書かれたshebangも読み取れないはず。
0550デフォルトの名無しさん
2012/02/21(火) 22:45:12.38無くて困ったことは皆無ですが、
あって困ったことはいやほどあります。
0551デフォルトの名無しさん
2012/02/21(火) 22:52:15.54無くて困ったというのは文字コードが明確でなかったと想像できるけど、
あって困ったというのは、具体的にどんなこと?
0552デフォルトの名無しさん
2012/02/21(火) 23:04:12.52上にあるけどshbangが通らないとか(頻発するので慣れた)、
ビルドが通らないとか(頻発するので慣れた)、
SQLの実行に失敗するとか(多数のDDLの実行途中だったのでリカバーに泣いた)。
0553デフォルトの名無しさん
2012/02/21(火) 23:09:04.250554デフォルトの名無しさん
2012/02/21(火) 23:12:44.31Cr
CrLf
Lf
の
三つが混ざっちゃうことあるの?
0555デフォルトの名無しさん
2012/02/21(火) 23:14:57.14単なるバイトストリームとして扱えなくなるケース。
0556デフォルトの名無しさん
2012/02/21(火) 23:19:30.60テキストファイルをバイナリで結合することが間違ってると思う。
結合するファイルの文字コードが違ってたら破綻するし、
ISO-2022はそもそもバイナリ結合できなくね?
0557デフォルトの名無しさん
2012/02/22(水) 09:08:20.78>>553, >>555 は、BOM なし UTF-8 ならば cat で連結できる、って話じゃないの?
別なコードの話を持ちだしても意味ないと思う。
0558デフォルトの名無しさん
2012/02/22(水) 09:10:14.09>バギーなコンパイラ
言いがかり。
そういうことがないようにUTF-8を使うのに
BOMがあるだけでパー。
>結合するファイルの文字コードが違ってたら破綻
同じUTF-8だけどな。
BOMがあるだけでパー。
0559デフォルトの名無しさん
2012/02/22(水) 09:28:36.68僕のKUSOコンパイラはダメなんです。と言われてもなあ。
取り敢えずKUSOコンパイラユーザーにデメリットが有るのはわかったw
0560デフォルトの名無しさん
2012/02/22(水) 09:34:37.56「テキストに日本語を書くと様々な問題を起こすので日本語の使用はデメリット」
とか
「csvにヘッダー行を書くとcatできない問題があるので書かないようにしている」
ってのと同レベル
0561デフォルトの名無しさん
2012/02/22(水) 13:10:05.23BOMさえなければ、とくにUTF-8に
対応することがそもそも不要。
バギーでもクソでもない。
UTF-8原理主義者は面倒くさいな。
0562デフォルトの名無しさん
2012/02/22(水) 14:07:48.030563デフォルトの名無しさん
2012/02/22(水) 14:21:41.35仕様自体の妥当性は別の話。
utf-8安置は頭が悪いな
0564デフォルトの名無しさん
2012/02/22(水) 14:25:08.950565デフォルトの名無しさん
2012/02/22(水) 15:03:18.48使ってはいけないというのは、UNIXの伝統的な掟です。
LinuxはUNIXに憧れているので、UNIXの掟を忠実に守ります。
掟を守るのは大事なことです。
UTF-8を許せば日本語を使う馬鹿が出てきますよ。
0566デフォルトの名無しさん
2012/02/22(水) 15:03:29.36バイトストリームとして扱えば、プログラムがそのまま使えるように。
Ken Thompson先生が。Unicodeの外の世界で。
だからUnicode.orgがUTF-8にもBOMを付けるのは味噌をつけてしまったようなもの。
ただ既にBOMがあるのだから、当然の帰結ではあるのだが。
もともとのUnicodeの考え(wide character主義)とUTF-8は乖離しているから、
こういう残念な状態になってしまった。
0567デフォルトの名無しさん
2012/02/22(水) 15:06:40.21パス名といえば、例えば、
"¥Users¥漢字名さん¥ドキュメント"
"漢字名さん"
"ドキュメント"
それぞれにBOMが付くとパス名処理がすごく面倒になる。
Unicode互換の処理系を名乗るにはやらないといけないけど、
そういうOS、ミドルウェアは未だ存在しない。
0568デフォルトの名無しさん
2012/02/22(水) 15:18:27.13"a" だけで何バイトだよ?
旧来のBOM無しUnicodeを新しいUnicodeとして制定しなおしましょう。
0569デフォルトの名無しさん
2012/02/22(水) 15:18:31.69だからこそ許してはいけないのです。
ファイル名やメールの件名に日本語を使ってはいけません。
0570デフォルトの名無しさん
2012/02/22(水) 15:19:17.810571デフォルトの名無しさん
2012/02/22(水) 15:20:33.65それは思い上がりですね。
ASCIIだけで充分です。
0572デフォルトの名無しさん
2012/02/22(水) 15:20:40.10UNIX系 BOM無しを前提にしている。
やっぱM$の陰謀以外考えられないわけだが。
0573デフォルトの名無しさん
2012/02/22(水) 15:21:39.18ならば、おまえだけは日本語で書き込むなよ。
0574デフォルトの名無しさん
2012/02/22(水) 15:28:41.230575デフォルトの名無しさん
2012/02/22(水) 15:29:14.05俺はUNIXもLinuxも使っていないのでメールの件名に日本語を使うし、
ファイル名にも日本語を使います。
HTMLメールが送られてきたからと言って怒ったりしません。
0576デフォルトの名無しさん
2012/02/22(水) 15:35:24.27>>568
それは思い上がりですね。
ASCIIだけで充分です。
>>575
だからおまえは日本語でこの掲示板に書き込む権利は一切無いの。
0577デフォルトの名無しさん
2012/02/22(水) 15:41:57.47いえいえ、俺はUNIXもLinuxも使わないので歴史的に日本語OKなのです。
ご心配には及びません。
0578デフォルトの名無しさん
2012/02/22(水) 15:42:52.800579デフォルトの名無しさん
2012/02/22(水) 16:46:17.18Unicode規格のencoding formとencoding schemeの説明を読み直してこい
フォルダー名にbomが付くとかあり得ないから
0580デフォルトの名無しさん
2012/02/22(水) 16:51:22.56@とか[とかは機種依存文字なのを知らんのか最近の若いモンは。
0581デフォルトの名無しさん
2012/02/22(水) 16:57:58.848bit目を立てるのはマナー違反です。
0582デフォルトの名無しさん
2012/02/22(水) 17:18:50.84何言ってるかさっぱりわからん。
パス名はメモリ上のデータに限られてると限定しているわけ?
0583デフォルトの名無しさん
2012/02/22(水) 18:05:31.10NotePad は BOM なくても UTF-8 を認識するよ。
でも保存するときに強制的に BOM がつくのが問題。
Unix でなくても、たとえば文書のヘッダやフッタを別のテキストファイルから
include してくるというのは、よくある処理だと思うけど、そういう場合に、
いちいち BOM の処理が必要というのは不合理。
字数とかワードラップとかの処理が必要な場合は仕方ないけれど、そうでない
場合はバイナリとテキストで同じプログラムが使えるようになっているのが望
ましい。
0584デフォルトの名無しさん
2012/02/22(水) 18:11:47.88Unicode規格ではEncoding FormにBOMの概念は無いんですよ。(ここらへんはRFC 3629と定義が違う)
Windowsのフォルダー名はEncoding SchemeでなくEncoding Form単位で読み書きするので、
フォルダー名にBOMが入ることはないです
0585デフォルトの名無しさん
2012/02/22(水) 18:22:59.79>たとえば文書のヘッダやフッタを別のテキストファイルから
>include してくるというのは、よくある処理だと思うけど、そういう場合に、
MS Word文書をバイナリで結合したら読み取れませんでした。てのと同レベル。
バイナリデータを挿入するんでなく、「テキスト」を挿入するよう見直した方がいい。
ISO/IEC 2022だって二つのファイルをバイナリで結合したら壊れるだろ
0586デフォルトの名無しさん
2012/02/22(水) 18:31:25.66ASCIIの7ビット文字は、現代で現実的に
充分ポータブルだろ。
どのあたりを心配してる?
0587デフォルトの名無しさん
2012/02/22(水) 18:34:04.47∩_∩
/ \ /\
| (^)=(^) | 人人人人人人人人人人
| ●_● | < BOM否定派に対する皮肉だろ>
/ // ///ヽ <言わせんな恥ずかしい>
| 〃 ------ ヾ | YYYYYYYYYYYYYY
\__二__ノ
0588デフォルトの名無しさん
2012/02/22(水) 20:32:33.68フォルダ名が外からもたらされたら、
>フォルダー名にBOMが入ることはないです
なんて課程は全くできないけど?
0589デフォルトの名無しさん
2012/02/22(水) 22:16:57.21BOMとU+FEFFは違う物です。Encoding SchemeとEncoding Formの違いを理解してください。
Windows APIでフォルダーを作成する際の名前は「UTF-16(Encoding Form)」でしか指定できないのです。
「UTF-16(Encoding Scheme)」を受け取るAPIは有りません。
外からもたらされた時点で<FE FF>がBOMかU+FEFFかを判断し、
BOMを取り除いた形でWindowsに渡す必要があります。
0590デフォルトの名無しさん
2012/02/22(水) 22:20:02.08> BOMを取り除いた形で
こういう処理をユーザがしないといけないって話なんだけど?
0591デフォルトの名無しさん
2012/02/22(水) 22:49:40.36もとはパス名処理が大変と言う567に対し、
文字列になってる時点でBOMは無いので単純だというのが579。
バイナリを文字列に変換するのにBOM処理は当然必要なんだけど、
それは567の「パス名処理が大変」「実装が存在しない」とは違う話。
0592デフォルトの名無しさん
2012/02/22(水) 23:09:53.07BOM付きの文字列を半分に分けたらどうする?
前半の文字列にはBOMがついて、
後半の文字列にはBOMがついてない?
それともわざわざ付けると思う?
BOMが存在するのは外部リソースのみ
それをUNICODE文書として読み取った時、
BOMは消さないといけない。
だから、APIに渡す文字列がBOM無しなのはアタリマエのこと。
0593デフォルトの名無しさん
2012/02/22(水) 23:11:12.92パス名処理が大変なんでしょ?
> 文字列になってる時点でBOMは無い
「文字列になって」
この定義自体が難しいから、
プログラマが何も気にしないでも問題が起きない実装はないわけだ。
そもそも利用者のレベルでも問題が起きうる。
0594デフォルトの名無しさん
2012/02/22(水) 23:12:42.87> BOMっていうのはファイルにしか存在しないものだよ。
外部リソースならどんなものにも付く可能性がある。
0595デフォルトの名無しさん
2012/02/22(水) 23:22:35.82> 「文字列になって」
> この定義自体が難しいから、
簡単。バイナリではなく文字列として解釈できる準備ができた時。
それは文字列型に代入した時や、
UTF8フラグなんかをつけた時。
0596デフォルトの名無しさん
2012/02/22(水) 23:23:34.450597デフォルトの名無しさん
2012/02/22(水) 23:27:15.210598デフォルトの名無しさん
2012/02/23(木) 00:11:05.68「テキスト」は純粋に「文字列」を表現する要素のみで構成されたものであるべき。
0599デフォルトの名無しさん
2012/02/23(木) 00:44:37.73整数列だから順序が必要ないんじゃろ?
それがエンコードスキームとエンコードフォームを分けた由来じゃろ?
Unicodeのエンコードフォームでは文字列は数値列だから、ひとつの文字はひとつの数値として扱われる。
しかしこれが物理的にコンピュータ上で扱われるとき、
コンピュータはその数値列を一つのバイト値として扱えない。
つまり、一つの文字は複数のバイト列になる。
だからバイト列に順序が必要になる。
一方、UTF-8はいずれの場合もバイト列として扱う。
文字列はバイト列であるので順番が必要ない。
という話じゃなかったっけあはん大陸。
0600デフォルトの名無しさん
2012/02/23(木) 00:46:24.77>一方、UTF-8はいずれの場合もバイト列として扱う。
>文字列はバイト列であるので順番が必要ない。
これは「文字列もまたバイト列であるので順番が必要ない」と書くべきか^^;
0601デフォルトの名無しさん
2012/02/23(木) 00:52:52.91UTF-8 許されてるなら日本語使っても良いと思う
むしろファイル名に半角 space 入れる香具師の方が
もう阿呆かと
0602デフォルトの名無しさん
2012/02/23(木) 00:53:52.69ファイルじゃない外部リソースなんかあるのか
0603デフォルトの名無しさん
2012/02/23(木) 00:54:42.23何がいけないんだ?
0604デフォルトの名無しさん
2012/02/23(木) 00:56:47.75メモリ、ストリームなどなど^^
0605デフォルトの名無しさん
2012/02/23(木) 01:00:55.19それって、つまり、ずーっと辿るとファイルに行き着くだろ
ファイル以外でBOMなんて付かないだろ
0606デフォルトの名無しさん
2012/02/23(木) 01:05:04.93いやいや。
例えばリアルタイムにコード変換してる時は元ファイルにはBOMついてないし^^;
メモリに展開される時にBOMがつく(つかないと判別できない^^)
そもそもプログラム内部は論理表現なのでBOMなどというものはありえない。
これがメモリに展開される瞬間、つまり物理表現に変わる瞬間にバイト順序が必要になる。
ストリームも同じ。
0607デフォルトの名無しさん
2012/02/23(木) 01:16:51.20だろ?
0608デフォルトの名無しさん
2012/02/23(木) 01:18:14.420609デフォルトの名無しさん
2012/02/23(木) 01:35:10.930610デフォルトの名無しさん
2012/02/23(木) 01:40:10.04'\0'を文字列の途中に突っ込むのと同じ話だけど。
やろうと思えば出来る。でも普通はメモリ中のデータにBOMは入れない。
くだらない話だから伸ばすな。
0611デフォルトの名無しさん
2012/02/23(木) 02:46:18.12> それって、つまり、ずーっと辿るとファイルに行き着くだろ
アホなの?
0612デフォルトの名無しさん
2012/02/23(木) 05:51:03.86明確だよ。
byte[]型は文字列でない。stringは文字列。
CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
CでもASCII NUL終端で扱っている時点でBOMが有るのは間違い。
UTF-16とか扱えなくなるだろ
0613デフォルトの名無しさん
2012/02/23(木) 06:10:47.12むしろ半角スペースで動かなくなる方が殺害モノだね。
やるべきことをやってないだけ。
"c:\a b�cacls.exe" "c:�d�e f" /R "SYSTEM"
SET "PATH=c:�a b"
常にこう書けば何が渡されても破綻しない
0614デフォルトの名無しさん
2012/02/23(木) 07:36:47.91cr->lf
lf->crlf
---------------
->の意味わ?
0615デフォルトの名無しさん
2012/02/23(木) 07:41:56.77> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
アホなの?
0616デフォルトの名無しさん
2012/02/23(木) 08:15:36.17文字に\0が含まれるのでchar[]では扱えない。
0617デフォルトの名無しさん
2012/02/23(木) 08:24:03.69> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
char[] == TCHAR[]
0618デフォルトの名無しさん
2012/02/23(木) 09:58:23.450619デフォルトの名無しさん
2012/02/23(木) 10:36:35.750620デフォルトの名無しさん
2012/02/23(木) 13:52:22.900621デフォルトの名無しさん
2012/02/23(木) 13:58:47.78> CでもWindowsならchar[]からTCHAR[]になった時点で文字列。
Windowsでは#define UNICODEとしないと文字列を扱えないそうです。
0622デフォルトの名無しさん
2012/02/23(木) 14:02:47.03いや扱える。
<stdio.h><string.h>などが文字列はnull terminate前提、
Cコンパイラも文字列リテラルが同様ってだけ。
ex.
struct UTF16String {
int length;
char data[];
};
0623デフォルトの名無しさん
2012/02/23(木) 16:55:20.640624デフォルトの名無しさん
2012/02/23(木) 20:02:43.63UTF-16はBEとLEがあるクソ仕様、SJISとCP932の問題よりさらに酷い
おまけにサロゲートペアのせいで何が16なのかと言うレベル
バイトストリームとしてはBEに限定して
APIなどではuint16_t*なりwchar_t*で扱えばいいのに
何故バイトストリームでBE版とLE版を用意したのかと
0625デフォルトの名無しさん
2012/02/23(木) 20:31:26.64たしかOracleもBEだったか。16LEは確かに誰得。
0626デフォルトの名無しさん
2012/02/23(木) 21:06:35.37ファイル or メモリ、char[] or TCHAR[]
重要なのはデータソースでも型でも無く、データの意味そのもの
同じintでも電圧の変数に電流の値を代入して良いわけがなく
同じstringでも通常の文字列とhtml文字列を混同すればxssに一直線だ
内部表現は[文字符号化方式]でなく[符号化文字集合]と考えるのが適切
バイナリとして読み込んだUTF-16文書のバッファ(文字符号化方式)のポインタを
wchar_t*(符号化文字集合)に単純キャストするような荒業でも動作する環境はあるが
wchar_tが4バイトの処理系ではそうはいかない
0627デフォルトの名無しさん
2012/02/23(木) 21:42:14.430628デフォルトの名無しさん
2012/02/23(木) 21:46:52.94具体的な反論するのが怖いの?
0629デフォルトの名無しさん
2012/02/23(木) 21:59:21.69>Shift_JISは常にビッグエンディアンだけど
「A」は82h 60hという2バイトであって、3260h(33376)ではありません。
>>621
長さとペアでバイナリデータを保持するcharと、ヌル終端前提のTCHARを区別しろってことでしょ。
TCHARがcharかwchar_tかは関係無い。
>>626の言う「重要なのはデータソースでも型でも無く、データの意味そのもの」を少しは理解しな
0630デフォルトの名無しさん
2012/02/23(木) 23:09:37.18→ JIS X 0208の符号化方式Shift JISでは 0x82 0x60 と表現
→ JIS X 0208の別の符号化方式EUC-JPでは 0xA3 0xC1 と表現
つまりUTF-32BEが最強
0631デフォルトの名無しさん
2012/02/24(金) 00:24:42.69Cの時代にcharで文字列とバイナリの両方を扱って
きた人間には理解を超えているので、
相手に罵声を浴びせることしかできないんだぜ。
エンコードスキーム(バイトデータ)とエンコードフォームの
違いがこのスレで何度説明されたことか。
未だに全く理解できていないし
0632デフォルトの名無しさん
2012/02/24(金) 00:31:43.040633デフォルトの名無しさん
2012/02/24(金) 00:41:41.68まだ言ってるのかw
0634デフォルトの名無しさん
2012/02/24(金) 00:50:25.32この解釈間違ってると思うんだが
誰も突っ込まないのな
0635デフォルトの名無しさん
2012/02/24(金) 00:50:38.49Windowsのwchar_tは2バイトでutf-16で固定長じゃないんだから、
charでutf-8を扱った方がまし。
0636デフォルトの名無しさん
2012/02/24(金) 01:03:21.88utf-8はいいけど
BOMのあり得るエンコードスキームUTF-8と
BOMの無いエンコードフォームUTF-8は
異なる概念なので区別しろよw
でないと、UTF-16BEはヌルが含まれるのでcで扱えないとか
とんちんかんなことを言い出しかねん
0637デフォルトの名無しさん
2012/02/24(金) 01:20:18.390638デフォルトの名無しさん
2012/02/24(金) 01:21:59.80頼んだぞ
0639デフォルトの名無しさん
2012/02/24(金) 01:24:48.19Windowsのメモ帳が付けるというのに、
どうしてそんな考えに至ったのか知りたい
0640デフォルトの名無しさん
2012/02/24(金) 02:40:35.01メモリ上にはUnicode encoding formしかないと勘違いしている人?
0641デフォルトの名無しさん
2012/02/24(金) 06:13:03.23読み取ったバイナリデータをテキストとして処理する前に
エンコードフォームに直すと言うことでは?
0642デフォルトの名無しさん
2012/02/24(金) 21:05:08.82struct{char* begin, char* end}の値渡しか、その構造体へのポインタを渡すようにした方が良かったよね
今更ってレベルじゃないけど
0643デフォルトの名無しさん
2012/02/24(金) 21:23:26.590644デフォルトの名無しさん
2012/02/24(金) 21:27:00.180645デフォルトの名無しさん
2012/02/24(金) 21:32:30.58最初はstructなんてなかったんだよ。
そこまで斜めだと後出しですらないだろ。
0646デフォルトの名無しさん
2012/02/24(金) 21:34:20.57Pascalがそれ。
実装によってはnull characterも持てた。
けど勝利したのはCのシンプルさ。
同じデータ構造(char [])でバイナリも持てる。
0647デフォルトの名無しさん
2012/02/24(金) 21:35:14.65特殊な型を持ち出さないと対応できなくなった。
0648デフォルトの名無しさん
2012/02/24(金) 21:36:10.43UTF16やUTF32専用の関数が必要になった。
0649デフォルトの名無しさん
2012/02/25(土) 00:27:19.29intじゃポインタで表現可能な範囲を持てる保証が無いよ
実際殆どの64bit環境(LP64やLLP64)でintでは4Gの壁が出来上がる
せめてptrdiff_tにしないとね
>>645
マジか、struct無かったのか・・・
でも斜めではなくね?STLでもbegin(),end()が基本だしさ
0650デフォルトの名無しさん
2012/02/25(土) 00:36:53.09昔の話だとして…
Cの前身はT *とintの区別なかったんだよ。
型指定がなくて、型は名前のついてないWORD型しかない。
今で言うところのILP16で。(Integer, Long, Pointerが16bit)
だからその影響でCでもしばらく型指定なしの変数宣言するとintだった。
0651デフォルトの名無しさん
2012/02/25(土) 00:53:57.92ならsize_tでいいだろ。
strlenの戻り値の型だ。
0652デフォルトの名無しさん
2012/02/25(土) 08:59:27.50cの前身っていったら1971年?
そんな時代に16ビットが普及してたはずもないのだが
0653デフォルトの名無しさん
2012/02/25(土) 11:01:25.83ミニコンの16ビットは70年代に16ビットは普通では?
0654デフォルトの名無しさん
2012/02/25(土) 11:05:36.97と思って調べたらまさかの18ビット
0655デフォルトの名無しさん
2012/02/25(土) 11:06:15.460656デフォルトの名無しさん
2012/02/25(土) 13:22:49.450657デフォルトの名無しさん
2012/02/25(土) 23:22:28.040658デフォルトの名無しさん
2012/02/26(日) 15:47:27.680659デフォルトの名無しさん
2012/02/26(日) 16:11:51.660660デフォルトの名無しさん
2012/02/26(日) 19:02:49.96ソフトラインブレークは発狂の元
0661デフォルトの名無しさん
2012/02/26(日) 19:09:25.17空行が無くなるが
0662デフォルトの名無しさん
2012/02/27(月) 06:35:19.89CrCrLfはWindowsだと不正な改行。
なのでそれを受け入れたい場合は、どう処理するかをソフトウェアの仕様で
決めなければならない。
0663デフォルトの名無しさん
2012/02/27(月) 12:08:54.55混ざってても大体うまくいくし
CrCrLfLfLfCrLfLfCr → Cr,CrLf,Lf,LfCr,Lf,LfCr → 改行6個
CrLfCrLfCrLf → CrLf,CrLf,CrLf (Windows)
LfLfLf → Lf,Lf,Lf (Linux)
CrCrCr → Cr,Cr,Cr (Mac9以前)
0664デフォルトの名無しさん
2012/02/27(月) 13:18:33.440665デフォルトの名無しさん
2012/02/27(月) 15:26:35.500666デフォルトの名無しさん
2012/02/27(月) 16:24:28.49一方Microsoft Excelさんは平然と混ぜてくるのであった
CSV形式で保存すると行の区切りにCRLFを使用するけど
セル内に改行がある場合は""で囲った上でLFのみで出してくる斜め上仕様
そうした理由は分からんでもないけど・・・
0667デフォルトの名無しさん
2012/02/27(月) 18:18:57.201. CR または LF が連続していたら、それぞれの数を数える
2. LF が一個でもあったら CR は無視してその個数を改行数とする
3. LF がひとつもなかったら CR の個数を改行数とする
4. 出力の改行を決める必要があるときは、入力の最初の改行によって決める
(入力がないときはOS依存……最近は LF 決め打ちが多いけど)
わざと混在させる必要がある場合以外、これで問題ない。
もっとも、CR のみの文書っていまだかつて見たことないが。
0668デフォルトの名無しさん
2012/02/27(月) 18:20:19.660669デフォルトの名無しさん
2012/02/27(月) 19:07:55.382005年公開でこの内容ってことは単にMS Officeに合わせただけか
MSの頭悪いCSVの仕様がRFCになってるとは
素直にメタ文字エスケープすればいいのに
0670デフォルトの名無しさん
2012/02/27(月) 22:26:43.04パーサーのことだけで読みやすさを考えてないだろ。
0671デフォルトの名無しさん
2012/02/28(火) 11:05:23.12まぁその辺は人によるから不毛だな
あとパーサーだけじゃないぞ
ちょっとした文字の置換とかも、しやすさが全然違う
0672デフォルトの名無しさん
2012/02/29(水) 07:10:49.120673デフォルトの名無しさん
2012/02/29(水) 16:32:24.200674デフォルトの名無しさん
2012/03/02(金) 19:25:17.780675デフォルトの名無しさん
2012/03/02(金) 19:43:07.92∖
╲
╲
\
\
0676デフォルトの名無しさん
2012/03/02(金) 19:43:31.69みえる化
0677デフォルトの名無しさん
2012/03/02(金) 19:48:04.830678デフォルトの名無しさん
2012/03/03(土) 05:57:10.920679デフォルトの名無しさん
2012/03/03(土) 07:43:55.610680デフォルトの名無しさん
2012/03/03(土) 16:13:06.060681デフォルトの名無しさん
2012/03/03(土) 16:41:16.180682デフォルトの名無しさん
2012/03/03(土) 16:46:52.040683デフォルトの名無しさん
2012/03/03(土) 17:05:29.990684デフォルトの名無しさん
2012/03/03(土) 17:11:27.730685デフォルトの名無しさん
2012/03/04(日) 23:00:24.18これはキーボードのローマ字入力でどのキーを押せば
0686デフォルトの名無しさん
2012/03/04(日) 23:51:46.850687デフォルトの名無しさん
2012/03/12(月) 07:21:55.871文字1MBで表現しろよ!
0688デフォルトの名無しさん
2012/03/12(月) 08:07:52.930689デフォルトの名無しさん
2012/03/12(月) 15:01:53.430690デフォルトの名無しさん
2012/03/12(月) 15:22:57.770691デフォルトの名無しさん
2012/03/12(月) 20:10:02.360692デフォルトの名無しさん
2012/03/12(月) 20:31:58.100693デフォルトの名無しさん
2012/03/12(月) 21:20:31.96∧,,∧
( `・ω・) ウーム…?
/ ∽ |
しー-J
0694デフォルトの名無しさん
2012/03/12(月) 22:00:02.92ストップビット2
0:1ビット
1:1.5ビット
0695デフォルトの名無しさん
2012/03/12(月) 22:01:50.36書き直す
ストップビット:4
0:2ビット
1:3ビット
0696デフォルトの名無しさん
2012/03/12(月) 22:17:33.780697デフォルトの名無しさん
2012/03/13(火) 10:00:05.440698デフォルトの名無しさん
2012/03/13(火) 10:02:10.360699デフォルトの名無しさん
2012/03/13(火) 23:25:06.32トン、ツー
0700デフォルトの名無しさん
2012/03/14(水) 12:43:51.04その様子だと、お前は次の問題が解けねぇな。
英文が成立する最低限度のキャラクタのうち、出現頻度が一番高いのは、何?
0701デフォルトの名無しさん
2012/03/14(水) 12:57:27.420702デフォルトの名無しさん
2012/03/14(水) 16:28:08.330703デフォルトの名無しさん
2012/03/14(水) 17:02:49.100704デフォルトの名無しさん
2012/03/14(水) 23:11:46.610705デフォルトの名無しさん
2012/03/16(金) 00:03:13.48話そらすバカ
0706デフォルトの名無しさん
2012/03/27(火) 00:05:22.70全くそれていないんだが、それが理解できないと言うことは、
1200 8N1 とか言っても理解できんのんだよなwww
0707デフォルトの名無しさん
2012/03/27(火) 07:50:36.57わかります。
しかも1200っていつの時代
0708デフォルトの名無しさん
2012/03/27(火) 13:12:53.93ATZ
ATDT110
0709デフォルトの名無しさん
2012/03/27(火) 15:45:33.290710デフォルトの名無しさん
2012/03/28(水) 09:08:44.45お前・・・・分かるんだwww
0711デフォルトの名無しさん
2012/03/28(水) 09:41:33.960712営利利用に関するLR審議中@詳細は自治スレへ
2012/04/08(日) 02:17:17.240713営利利用に関するLR審議中@詳細は自治スレへ
2012/04/08(日) 02:20:11.840714デフォルトの名無しさん
2012/04/12(木) 12:01:16.850715デフォルトの名無しさん
2012/04/15(日) 04:48:40.36ドイツ語、ポルトガル語など、英語以外の言語では、発音がことなるおそれがある。
「ヘボン式ローマ字は英語の発音に準拠したので、日本語の表記法としては破綻が多い(中略)
日本式は音韻学理論の結実として、日本国内外の少なくない言語学者の賛同を得た。
しかし、英語の発音への準拠を排除した日本式ローマ字は英語話者や日本人英語教育者から激しい抵抗を受け」
ローマ字 - Wikipedia
0716デフォルトの名無しさん
2012/04/15(日) 05:43:55.650717デフォルトの名無しさん
2012/04/15(日) 12:15:22.240718デフォルトの名無しさん
2012/04/16(月) 13:41:08.050719デフォルトの名無しさん
2012/04/21(土) 23:43:35.820720デフォルトの名無しさん
2012/04/22(日) 05:43:04.900721デフォルトの名無しさん
2012/04/22(日) 10:56:29.77ユニホーム
とか
ビルヂング
0722デフォルトの名無しさん
2012/04/22(日) 11:34:27.880723デフォルトの名無しさん
2012/04/22(日) 11:48:55.630724デフォルトの名無しさん
2012/04/22(日) 12:00:05.69ス マ ホ
をなんとかしろ。
0725デフォルトの名無しさん
2012/04/22(日) 12:09:28.760726デフォルトの名無しさん
2012/04/22(日) 13:51:12.050727デフォルトの名無しさん
2012/04/22(日) 20:35:53.60何なのとは?
お前が何を問題視しているのかを説明してもらおうか
0728デフォルトの名無しさん
2012/04/22(日) 20:45:02.960729デフォルトの名無しさん
2012/04/23(月) 18:35:00.200730デフォルトの名無しさん
2012/04/23(月) 19:54:19.700731デフォルトの名無しさん
2012/04/23(月) 20:49:49.640732デフォルトの名無しさん
2012/04/24(火) 02:44:24.00プログラミングを意識したら、半角がいいとおもう(区切りだから)
実際には、全角がつかわれてもしょうがない
0733デフォルトの名無しさん
2012/04/24(火) 02:52:38.612桁以上を半角にする。
たとえば、新聞、雑誌など、縦書きを意識したら、何桁でも全角数字がいいとか。
0734デフォルトの名無しさん
2012/04/24(火) 10:37:30.00使っている文字フォントの縦横比が1:40000だったりしたらどうするのだw
全角半角という呼び方もそうだが、
文字幅は文字フォントの問題であり、文字コードの責任ではない。
って、件の本に書いてあったじゃろ?^^
0735デフォルトの名無しさん
2012/04/24(火) 12:24:24.960736デフォルトの名無しさん
2012/04/24(火) 21:58:39.23縦書きで2桁は半角だろ?
平
成
24
年
0737デフォルトの名無しさん
2012/04/25(水) 17:45:04.43Unicodeは東アジア圏の文字幅(半角/全角含む)については、その取り扱いは規定されているだろ。
Unicode Standard Annex #11
East Asian Width
http://www.unicode.org/reports/tr11/
東アジアの文字幅
http://ja.wikipedia.org/wiki/%E6%9D%B1%E3%82%A2%E3%82%B8%E3%82%A2%E3%81%AE%E6%96%87%E5%AD%97%E5%B9%85
0738デフォルトの名無しさん
2012/04/25(水) 19:36:54.24実際、たいていのプロポーショナルフォントでは2倍になっとらんし…。
何とかならんもんかね。
0739デフォルトの名無しさん
2012/04/25(水) 20:14:29.55英語圏から見るとほんとカオスなんだろうなw
0740デフォルトの名無しさん
2012/04/25(水) 20:28:09.29プロポーショナルフォントで1:2の関係になるわけないでしょ。
プロポーショナルフォントの意味分かってるの?
1:2にしたければ固定幅フォントを使え。
0741デフォルトの名無しさん
2012/04/25(水) 20:29:33.25ための単なる呼び名でglyphの幅とは関係無い。
今は同じフォントでも文字幅いくつも持って切換えられるから、全角半角の
文字幅比はフォント固定でも変わる。
文字幅半分のglyphを生成したいとかはレンダリングで対処すべき問題
0742デフォルトの名無しさん
2012/04/25(水) 20:35:04.43固定ピッチフォントが使われている時は、レンダラは属性を見て1:2の文字幅でレンダリングするべきだろ。
0743デフォルトの名無しさん
2012/04/25(水) 20:56:48.08>固定ピッチフォントが使われている時は、レンダラは属性を見て1:2の文字幅でレンダリングするべきだろ。
レンダリングで対処すべき問題ってことね。
固定ピッチフォントなんてのはUnicodeの関知する所じゃないし。
0744デフォルトの名無しさん
2012/04/25(水) 21:00:49.88文字の特性値を見れば
全角/半角の切り分けはできるって言いたいだけだよ。
0745デフォルトの名無しさん
2012/04/25(水) 21:24:40.16最初から話が噛み合ってないねw
0746デフォルトの名無しさん
2012/04/25(水) 21:28:35.44文字コードの責任だよ。
Unicodeの仕様を見てごらん。
Fullwidthと書いてあるよね?
Halfwidthと書いてあるよね。
Halfは半分という意味、Widthは幅という意味だよ。
0747デフォルトの名無しさん
2012/04/25(水) 21:31:01.29件の本を読めれ^^;
0748デフォルトの名無しさん
2012/04/25(水) 21:34:31.61全角/半角を見分けてレンダリングする、レンダラを作ろうとする場合に、
どの文字を全角として扱って、どの文字を半角として扱うかの根拠になるのは、
http://www.unicode.org/reports/tr11/
http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt
この2つだろ。
Unicodeが文字コードの規格では無いとでも言うつもりか?
0749デフォルトの名無しさん
2012/04/25(水) 21:36:46.68俺は別にUnicodeの仕様策定者でも解釈者でもなく
単におまえらより偉い先生の書いた本の内容通りに言ってるだけなわけで
おまえらが偉いなら本書いて世間に認められてからその珍妙な説を展開してくれ
0750デフォルトの名無しさん
2012/04/25(水) 21:38:39.180751デフォルトの名無しさん
2012/04/25(水) 21:40:11.73それともここでおまえらの珍説をたかが一人の人間に納得させると何かおまえらは勝った気になるのか?w
0752デフォルトの名無しさん
2012/04/25(水) 21:41:42.620753デフォルトの名無しさん
2012/04/25(水) 21:43:41.68勝った気になるとか何の話だ?アホか。
0754デフォルトの名無しさん
2012/04/25(水) 21:51:18.700755デフォルトの名無しさん
2012/04/26(木) 00:10:30.79:/ u\; ____
;/ ノル(<)\; / ;u ノ し\
;| (>) _) \;/ ⌒ \
;|::: ⌒(__ノェソ / 、 |
;.\ u ´ ソ / ^ |
;\ , | |
,ヾ \_ n^^- \ j; __/
;/ 浴Q;i  ̄丶/ ̄ \
;( ⌒) ´ ノ \
0756デフォルトの名無しさん
2012/04/26(木) 07:22:30.80だから、それはUnicodeと旧来のエンコーディングとの対応を取るための単なるラベル。
Glyphの幅は何も規定しない。どういうglyph幅を採用するかはフォントデザイナの裁量。
UAX #11にもわざわざ
In legacy implementations, there is often a corresponding difference in encoding
length (one or two bytes) as well as a difference in displayed width.
However, the actual display width of a glyph is given by the font and may be further
adjusted by layout.
って書いてあるでしょ。
0757デフォルトの名無しさん
2012/04/26(木) 17:15:34.07「半角」「全角」って言葉が現実的に無視できない存在であることは理解した方がいいよ。
少なくとも半角全角を区別する文字コードが存在して
それに対応する文字がUnicodeに登録されているのは事実。
0758デフォルトの名無しさん
2012/04/26(木) 17:40:43.57・East Asian Width参考特性が半角なら、フォントは1/2のサイズにしなければならない
・East Asian Width参考特性が半角なら、フォントは1/2のサイズにした方が良い
後者なら反対してる人は居ないんじゃないかな
0759デフォルトの名無しさん
2012/04/26(木) 18:58:59.64自分の解釈が間違ってるって認めたら死んじまうような
ペラペラのアイデンティティの上でぎりぎり生きてるような連中だから
0760デフォルトの名無しさん
2012/04/26(木) 22:41:20.21現実=本音
0761デフォルトの名無しさん
2012/04/26(木) 22:53:08.420762デフォルトの名無しさん
2012/04/26(木) 23:06:35.26こんなの常識。
0763デフォルトの名無しさん
2012/04/26(木) 23:26:45.82本音「1:2にするべきだ」
0764デフォルトの名無しさん
2012/04/27(金) 05:09:05.830765デフォルトの名無しさん
2012/04/27(金) 05:50:54.33そのうち半角全角も、ただの歴史になるだろ。
0766デフォルトの名無しさん
2012/04/27(金) 20:44:56.570767デフォルトの名無しさん
2012/04/27(金) 22:03:45.300768デフォルトの名無しさん
2012/04/28(土) 11:43:55.630769デフォルトの名無しさん
2012/04/28(土) 20:44:13.870770デフォルトの名無しさん
2012/04/28(土) 21:09:07.620771デフォルトの名無しさん
2012/04/29(日) 05:40:27.80ヤシ
香具師(やし)
0772デフォルトの名無しさん
2012/05/03(木) 13:16:56.46少なくとも半角と全角を同一視するうにコードは、市ね、
と言いたい。
少なくとも、半角と全角を同一視したうえで勝手に全角半角を切り替えるアプリ書いたぼけ、市ね、
と言いたい。
0773デフォルトの名無しさん
2012/05/03(木) 17:10:28.08君の方こそ何を言っているのかわからないよ。
>半角と全角を同一視するうにコード
0774デフォルトの名無しさん
2012/05/03(木) 20:04:15.75Unicode風でありながら、半角と全角の空白を同一のコードポイントを割り当てた文字コード
それが、うにコード
0775デフォルトの名無しさん
2012/05/03(木) 21:45:35.05¥ U+00a5 を
\ 0x5C
に変換するライブラリ、市ね
0776デフォルトの名無しさん
2012/05/03(木) 23:14:36.68それはUnicodeでなくて「Unicodeとローカルエンコードとの変換ルール」の話だと思うが、
既定でCP932変換ルール(Unicodeコンソーシアム公開のもの)でないのはKUSOだな。
オプションでCP932以外を指定できるなら可。
0777デフォルトの名無しさん
2012/05/04(金) 16:50:18.920778デフォルトの名無しさん
2012/05/06(日) 09:29:11.27あらどっこいしょ
0779デフォルトの名無しさん
2012/05/06(日) 11:08:02.26アラート
0780デフォルトの名無しさん
2012/05/07(月) 21:09:03.92alternateなんだからアルトに決まってんだろ!
\アルタネーッテ/
0781デフォルトの名無しさん
2012/05/07(月) 21:31:02.380782デフォルトの名無しさん
2012/05/09(水) 01:21:11.830783デフォルトの名無しさん
2012/05/11(金) 06:48:00.44一般的にはUTF16インディアン付なんでしょ?
0784デフォルトの名無しさん
2012/05/11(金) 07:26:20.20そんなことをやるのはバカだ。
いくらたくさんいようが、バカはバカだ。
0785デフォルトの名無しさん
2012/05/11(金) 07:56:49.55ちげーよ
単に「文字コードはUnicode」と言ったら
言ってる奴がアホなのでその意味を汲み取ってあげないといけない。
Windows意外ならBOM無しが多い。
ってかエンディアン月とか、もうアホかと
0786デフォルトの名無しさん
2012/05/11(金) 19:18:13.50Unicodeで保存する項目があるけどどんなUnicodeまでかまでわ表示されないだけど
0787デフォルトの名無しさん
2012/05/11(金) 19:32:02.130788デフォルトの名無しさん
2012/05/12(土) 15:12:52.520789デフォルトの名無しさん
2012/05/12(土) 17:29:03.250790デフォルトの名無しさん
2012/05/13(日) 05:27:44.760791デフォルトの名無しさん
2012/05/13(日) 05:33:56.53インディアンは付かない
UTF-16:Unicodeのインディアン付エンコード
0792デフォルトの名無しさん
2012/05/13(日) 12:09:07.66インディアン嘘付かない
UTF16:USOあり
インディアン嘘つき
0793デフォルトの名無しさん
2012/05/13(日) 13:25:10.900794デフォルトの名無しさん
2012/05/13(日) 14:33:09.620795デフォルトの名無しさん
2012/05/13(日) 16:37:51.400796デフォルトの名無しさん
2012/05/13(日) 22:39:55.24マジレスじゃないよね?
0798デフォルトの名無しさん
2012/05/13(日) 23:59:25.400799デフォルトの名無しさん
2012/05/14(月) 00:36:19.590800デフォルトの名無しさん
2012/05/14(月) 00:54:01.43がっかりした
残念だ
0801デフォルトの名無しさん
2012/05/14(月) 06:11:25.370802デフォルトの名無しさん
2012/05/14(月) 11:09:05.250803デフォルトの名無しさん
2012/05/14(月) 21:49:46.07↓
0804デフォルトの名無しさん
2012/05/14(月) 21:58:08.99「WOLF RPGエディター」とは?
・高度なRPG開発が可能な、完全無料のゲーム作成ツールです。
・雰囲気はRPGツクール2000に近い。RPGツクール2000で自作システムを作りこむ際に
不満だったところがいろいろ解消されていて、かなり自由度が高いです。ただし
その分初心者には難しいかも。すでにツクール2000で自作システムを組むのに
慣れた人やRPGツクールでは物足りないけどプログラミングはちょっとという方にお勧め。
・作成したゲームは自由に配布したり、コンテストに投稿することも可能。
また本ソフトを持たない人でもプレイ可能!ファイル暗号化も完備!
■作り方しだいでパズル系やカードゲームやシミュレーションやシューティングや
アクション、RTSや他なんでも作れます。
■また他の人がネット上で公開している「コモンイベント」を組み合わせて利用すれば、
自分では開発が難しいゲームシステムも容易に実現することができます。
0805デフォルトの名無しさん
2012/05/15(火) 20:57:07.53特にUTF16インディアン無しについて、教えてエロ委人
0806デフォルトの名無しさん
2012/05/15(火) 23:50:49.120807デフォルトの名無しさん
2012/05/16(水) 00:22:55.41むしろ判別不明なファイルの量産を防ぐために役だった。
0808デフォルトの名無しさん
2012/05/16(水) 07:57:48.67http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf
>Use of a BOM is neither required nor recommended for UTF-8
0809デフォルトの名無しさん
2012/05/16(水) 08:16:54.76推奨しない(使用しない方がよい)と解釈してしまうとは
残念だね
0810デフォルトの名無しさん
2012/05/16(水) 10:30:41.16「しているわけではない」?
「BOMは省略可」でなく、わざわざそう書いた意図を考えてみたほうが良い
まぁ君はBOM付きUTF-8を使えばいい
俺はデメリットの方が大きいから使わない
0811デフォルトの名無しさん
2012/05/16(水) 11:14:15.47雀の往来みたいな
あれってUTF16,UTF32の処理効率のために
LEでもBEでも扱えるようにするためのものなんじゃないの?
0812デフォルトの名無しさん
2012/05/16(水) 12:19:50.54みっともない
0813デフォルトの名無しさん
2012/05/16(水) 18:49:05.09BOMが邪魔なのはいいけど規格には従えって話しでしょ。
僕なら入力はBOMを許して出力時には出さないようにする。
BOMを扱えないKUSOな環境の方が問題だよ。
メモ帳の出力した規格に従ったファイルを扱えない
KUSOな環境をボクが使っているから
メモ帳は
KUSOだなんて。発想が
KUSOだよ。
0814デフォルトの名無しさん
2012/05/16(水) 20:14:20.600815デフォルトの名無しさん
2012/05/16(水) 20:26:12.66インディアンは付かないけどBOMは付く。
昔のWindowsはBOM無しUTF-8を上書き保存するとBOM無しで保存した気がするけど
最近は必ず付く気がする
0816デフォルトの名無しさん
2012/05/16(水) 20:36:16.64メモ帳でBOMの有無を選択出来るようにならない限り
メモ帳はKUSOと言われ続けるんじゃね?
0817デフォルトの名無しさん
2012/05/16(水) 20:42:58.74MSの文字コード仕事としてはUTF-16BE/LE、UTF-8を扱えるplain text iFilter提供の方が急務だろ
0818デフォルトの名無しさん
2012/05/16(水) 20:55:22.02・・すごく、大きいです・・アーッ!!
>>816
Unicode規格に従ったメモ帳が、Unicode規格に従わないシバンに
クソ扱いされるなんて、くそみそな世の中ですね。
0819デフォルトの名無しさん
2012/05/16(水) 20:58:53.680820デフォルトの名無しさん
2012/05/16(水) 21:00:14.55>Unicode規格に従わないシバンに
問題の本質が分からないならレスしない方がいいよw
0821デフォルトの名無しさん
2012/05/16(水) 21:14:16.530822デフォルトの名無しさん
2012/05/16(水) 21:30:50.690823デフォルトの名無しさん
2012/05/16(水) 22:03:42.78テキストファイルの内容として不適切
UTF16だから許されるわけではあるまい
0824デフォルトの名無しさん
2012/05/16(水) 22:09:49.01ASCIIへの前方互換を考慮して設計されたUTF-8で
それを台無しにするBOMを許可するとか不整合もいいとこだな
先頭がASCII互換を前提とするxmlとかshebangで現実に問題出てるし
0825デフォルトの名無しさん
2012/05/16(水) 22:12:59.550826デフォルトの名無しさん
2012/05/16(水) 22:30:46.74>先頭がASCII互換を前提とするxml
勝手にKUSOな前提作んな
UTF17のXMLとかあるだろ
0827デフォルトの名無しさん
2012/05/16(水) 22:37:05.810828デフォルトの名無しさん
2012/05/16(水) 22:41:16.450829デフォルトの名無しさん
2012/05/16(水) 22:49:47.84ユーザーがutf8をわざわざ指定しているのに
内容によってbom削ったら、それこそクレイジー。
ポリシーは統一していないと。
0830デフォルトの名無しさん
2012/05/17(木) 01:23:50.34BOMつきUTF8のXHTMLはwell formedじゃないのでパロります
0831デフォルトの名無しさん
2012/05/17(木) 07:21:35.45xmlがbomを禁止しておらずxhtmlとやらが不可なルールの下
xhtmlをbom付で作るとおかしくなったからbomはだめとか、最早被害妄想
0832デフォルトの名無しさん
2012/05/17(木) 07:37:00.690833デフォルトの名無しさん
2012/05/17(木) 14:22:47.20シフトJISこそ最強。
0834デフォルトの名無しさん
2012/05/17(木) 15:26:17.36|
∩___∩ |
| ノ _, ,_ ヽ (( | プラプラ
/ ● ● | (=)
| ( _●_) ミ _ (⌒) J ))
彡、 |∪| ノ
⊂⌒ヽ / ヽノ ヽ /⌒つ
\ ヽ / ヽ /
\_,,ノ |、_ノ
0835デフォルトの名無しさん
2012/05/17(木) 20:16:20.71こんだけアホで不毛なレスが湧いてるユニコードのどこがいいんだ。
この2ちゃんだってシフトJISだろ。ユニコードは10年かかっても普及しなかったクソコード。
0836デフォルトの名無しさん
2012/05/17(木) 20:34:38.770837デフォルトの名無しさん
2012/05/17(木) 20:52:40.82http://toro.2ch.net/test/read.cgi/tech/1306595564/619
0838デフォルトの名無しさん
2012/05/17(木) 21:09:43.85ユニコードがバグだらけの証拠を出してくるとは自爆乙。
ついでにHTMLのcontent-typeぐらい見れるようになった方がいいぜ。
0839デフォルトの名無しさん
2012/05/18(金) 02:02:10.420840デフォルトの名無しさん
2012/05/18(金) 03:56:22.55MSゴシックじゃなくMSPゴシックのような気がする
0841デフォルトの名無しさん
2012/05/18(金) 04:38:31.88────‐v──‐ | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
∧_∧ | この板は、Windows+IE、MS Pゴシック、文字サイズ:中が標準環境です。 |
と´⌒`つ´Д`)σ< 標準環境でない(この吹き出しの右端の縦線がズレている)方は、 こちらへ。 |
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ?|_________________________________|
http://toro.2ch.net/aastory/ AA長編@2ch掲示板
0842デフォルトの名無しさん
2012/05/18(金) 04:42:17.53http://tail.s170.xrea.com/html/text/aa_promo/aa_setting/
0843文字博士
2012/05/18(金) 17:44:31.72板ごとに変わってたまるかw
0844デフォルトの名無しさん
2012/05/18(金) 22:52:41.03え?
0845デフォルトの名無しさん
2012/05/18(金) 23:02:27.73わざとボケてるだろ
0846デフォルトの名無しさん
2012/05/18(金) 23:32:10.21藪の中という話にも書かれているとおり
0847デフォルトの名無しさん
2012/05/18(金) 23:52:13.29>>840あたりから?
0848デフォルトの名無しさん
2012/05/19(土) 08:39:35.500849デフォルトの名無しさん
2012/05/19(土) 12:01:52.57合成=インディアン子供作った
0850デフォルトの名無しさん
2012/05/19(土) 12:44:45.710851デフォルトの名無しさん
2012/05/20(日) 09:54:25.230852デフォルトの名無しさん
2012/05/20(日) 18:54:56.500853デフォルトの名無しさん
2012/05/20(日) 21:26:38.350854デフォルトの名無しさん
2012/05/20(日) 23:21:08.840855デフォルトの名無しさん
2012/05/23(水) 22:04:36.87合成とは別に用意したチンコとマンコの写真を一枚の絵にすること。
0856デフォルトの名無しさん
2012/05/24(木) 03:11:41.47まずは漢字を少なくするのから取り組まないとダメだろ
0857デフォルトの名無しさん
2012/05/24(木) 07:38:58.640858デフォルトの名無しさん
2012/05/24(木) 10:20:13.57/∵∴∵∴\
/∵∴∵∴∵∴\
/∵∴∴,(・)(・)∴|
|∵∵/ ○ \|
|∵ / 三 | 三 | / ̄ ̄ ̄ ̄ ̄
|∵ | __|__ | <うるせー馬鹿!
\| \_/ / \_____
\____/
0859デフォルトの名無しさん
2012/06/04(月) 01:20:21.22JAVAでNormalaizerクラスによる
NFCの正規化をしたいのですが
NFCと言ったら言語に依らず同じ結果になるのでしょうか?
シフトJISのIBM拡張文字を
cp932でUNIコードに変換した文字の膣内に、
Normalyzerにかけると別のコードになってしまう
文字があって困っています。。
0860デフォルトの名無しさん
2012/06/04(月) 09:40:44.390861859
2012/06/04(月) 09:43:23.14誤;膣内
正:中
0862デフォルトの名無しさん
2012/06/04(月) 09:49:36.07かなり古い本だけど風間一洋さんがまとめてる。
昔はぺーじもあったんだが、検索してもないな。
他に三線の情報まとめている人はいないのかな。
0863デフォルトの名無しさん
2012/06/04(月) 14:43:06.64普段どんな変換しているんだw
0864デフォルトの名無しさん
2012/06/08(金) 16:14:27.25左と右があるらしく、
片方はキーボードの2のところに見えるけど
もう片方はどこ?
0865デフォルトの名無しさん
2012/06/08(金) 17:23:06.360866デフォルトの名無しさん
2012/06/10(日) 03:21:24.73BOMの有無を自由に指定できるようになったら
euに訴えられると思う。
メモ帳はKUSOでなくてはならない。
0867デフォルトの名無しさん
2012/06/10(日) 05:36:39.570868デフォルトの名無しさん
2012/06/10(日) 08:27:27.33癖が付いてたから忘れてたわ。
あれはかなり区祖
0869デフォルトの名無しさん
2012/06/10(日) 23:58:54.20なのにUnicodeとUTF-8の違いがよくわからないんだぜ。
何やらインディアンとBOMが難しいことはよくわかった。
誰か3行でまとめてよ。
0870デフォルトの名無しさん
2012/06/11(月) 00:07:59.91UTF-8はその中の一つでエンコーディングの方法
UTFとUCSの違いが理解できると規格そのものは難しくはない(プログラミング上は難しい)
0871デフォルトの名無しさん
2012/06/11(月) 00:46:06.59Unicodeをデータで表すための仕様 : UTF-8, UTF-16、他
UTF-8 : エンディアンが無いからBOMは不要
UTF-16 : エンディアンが有るからBOMが必要
0872デフォルトの名無しさん
2012/06/11(月) 01:22:52.140873デフォルトの名無しさん
2012/06/11(月) 01:48:33.540874デフォルトの名無しさん
2012/06/11(月) 07:05:12.29なんでこんなにカオスな仕様ww
0875デフォルトの名無しさん
2012/06/11(月) 07:39:54.01これ分かり易い。
Unicode規格の中の特定のエンコードがunicodeなんだな。
3スレ目にしてようやく理解したぜ。
でもucsとかBomとかインディアンとかさっぱりだぜ。
0876デフォルトの名無しさん
2012/06/11(月) 12:14:30.400877デフォルトの名無しさん
2012/06/11(月) 12:57:31.21どの機種にも共通でデータを扱えるらしい
0878デフォルトの名無しさん
2012/06/11(月) 22:20:53.520879デフォルトの名無しさん
2012/06/11(月) 23:48:39.260880デフォルトの名無しさん
2012/06/12(火) 21:11:48.380881デフォルトの名無しさん
2012/06/12(火) 22:52:12.810882デフォルトの名無しさん
2012/06/20(水) 22:43:57.90KFCで性器化済み。
0883デフォルトの名無しさん
2012/06/20(水) 23:05:28.340884デフォルトの名無しさん
2012/06/20(水) 23:17:38.730885デフォルトの名無しさん
2012/06/21(木) 11:02:28.080886デフォルトの名無しさん
2012/06/28(木) 23:05:32.82間違えないようインディアンを付けた方がいい。
0887デフォルトの名無しさん
2012/07/01(日) 11:14:34.77奴ばかりいるんだが、実際のところの質問者は
メモ帳の保存の違いを聞いただけじゃないの?
質問の意図を考えずに質問文に単語レベルで反応するのイクナイ
0888デフォルトの名無しさん
2012/07/01(日) 16:17:01.24バカ真面目、結構じゃないか。
0889デフォルトの名無しさん
2012/07/01(日) 21:16:37.230890デフォルトの名無しさん
2012/07/01(日) 21:30:06.120891デフォルトの名無しさん
2012/07/01(日) 21:33:26.830892デフォルトの名無しさん
2012/07/01(日) 23:01:43.14スレタイは「Unicode隔離スレその4(UnicodeとUTF-8の違い)」でいいか?
0893デフォルトの名無しさん
2012/07/01(日) 23:12:53.63「UTFインデアンとUnicodeの違いは?」だな
あくまでインデアン。
0894デフォルトの名無しさん
2012/07/01(日) 23:14:36.10>>877あたりからおかしーぞ。
0895デフォルトの名無しさん
2012/07/02(月) 01:11:37.840896デフォルトの名無しさん
2012/07/02(月) 05:31:17.88・HTTPインディアン
・インターネットインディアン
・UTFインディアン
・マイクロインディアン
この違いを理解しないとこのスレの
内容について行くのは難しいだろう
0897デフォルトの名無しさん
2012/07/02(月) 06:08:53.260898デフォルトの名無しさん
2012/07/04(水) 21:09:49.23結合文字はまだ意味的な切れ目があるけど
サロゲートペアは当初の設計ミスによる無意味な分断。
やはりシフトJIS回帰しかない。
0899デフォルトの名無しさん
2012/07/05(木) 20:28:12.000900デフォルトの名無しさん
2012/07/05(木) 22:40:30.56エンコーディングはMIMEのcharsetとかファイルのメタデータで明示できる。
0901デフォルトの名無しさん
2012/07/05(木) 22:42:44.58Unicodeの
BOMみたいに、文字コードの判別を読むために
文字コードを知る必要があるおかしな
ことになっちゃったんだよねえ。
かといってHTTPヘッダーははやらなかったし。
ヘッダー化してもメタ情報と中身の整合性を保つのが難しそうだ
0902デフォルトの名無しさん
2012/07/06(金) 08:27:24.28httpdがファイルの中身を理解する必要があるから難しい。
0903デフォルトの名無しさん
2012/07/06(金) 08:34:36.86XMLはAscii互換系文字コードに限定して宣言まではAsciiのみにするとかすればよかったのに
UTF-16やBOM付きUTF-8を許可するからあんな有様に
http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing-no-ext-info
0904デフォルトの名無しさん
2012/07/06(金) 09:57:29.830905デフォルトの名無しさん
2012/07/07(土) 06:54:18.92データ以上の情報が無いなら
受信側の判断に任せて何もしなきゃいいのに
0906デフォルトの名無しさん
2012/07/07(土) 09:39:45.010907デフォルトの名無しさん
2012/07/07(土) 09:57:08.39指定するのを止めて欲しい
0908デフォルトの名無しさん
2012/07/20(金) 17:20:28.06違いが理解出来ないから
0909デフォルトの名無しさん
2012/07/20(金) 17:33:06.65Qt はどうなんだろ
0910デフォルトの名無しさん
2012/07/20(金) 18:12:31.01つまり最も保守されているライブラリの一つってことになる。
ただlibiconvはGPL2なので環境によっては自前のやつ使ってるんじゃないか。
Windows版QtはWindowsのライブラリ使ってるようだ。
0911デフォルトの名無しさん
2012/07/20(金) 18:37:37.42ひどいとかは?
0912デフォルトの名無しさん
2012/07/20(金) 18:45:19.26cp932と書かれているのに間違ってる変換があるとか
0913デフォルトの名無しさん
2012/07/20(金) 18:52:10.46ttp://www2d.biglobe.ne.jp/~msyk/software/libiconv-patch.html
0914デフォルトの名無しさん
2012/07/20(金) 18:58:54.45説明無しに配布するバカでることには違いない
0915デフォルトの名無しさん
2012/07/20(金) 19:34:19.880916デフォルトの名無しさん
2012/07/20(金) 19:46:06.79リンク先のみに書くことではないね。
クリックしたらダウンロード始まるように見えるし。
折角いいものを作っているのに、
見てもらう機会を逸しているかも。
0917デフォルトの名無しさん
2012/07/20(金) 20:25:58.080918デフォルトの名無しさん
2012/07/20(金) 20:38:35.680919デフォルトの名無しさん
2012/07/20(金) 20:44:32.96Unicodeの定義している変換表だけでは、
ISO-2022-JP←→cp932さえまともに変換できないので。
しかも何を持ってまともって言うかにも意見というか立場の相違がある。
0920デフォルトの名無しさん
2012/07/20(金) 20:48:27.82UnicodeマッピングルールのCP932ではないので
規格違反ではない
>>919
>ISO-2022-JP←→cp932
Unicode経由してないじゃん
0921デフォルトの名無しさん
2012/07/20(金) 21:04:55.79どういった規則で変換してんの?
unicode経由?
0922デフォルトの名無しさん
2012/07/20(金) 21:13:51.29規格違反なんて誰も言ってないのでは?
0923デフォルトの名無しさん
2012/07/21(土) 05:17:51.28いくらなんでもcp932とUnicodeとの変換で
〜を81 60←→U+301C
したらそれはバグだろう。
立場の相違とかでなくcp932の81 60はU+FF5Eと決まっている。
0924デフォルトの名無しさん
2012/07/21(土) 11:26:51.370925デフォルトの名無しさん
2012/07/21(土) 12:59:04.420926デフォルトの名無しさん
2012/07/21(土) 13:53:24.830927デフォルトの名無しさん
2012/07/21(土) 15:27:03.08U+FF5Eになっていたのは
コンソーシアムが縦書フォントを見て字形を間違え、
MSがU+301Cは使えないと判断したからの筈。
ウニコードはうんこ
0928デフォルトの名無しさん
2012/07/21(土) 16:40:15.04Unkode
0929デフォルトの名無しさん
2012/07/21(土) 16:41:28.08ちゃんと"WAVE DASH"と名前が付いてるのに間違ったのはMSだけの件について
0930デフォルトの名無しさん
2012/07/21(土) 17:42:29.99Unicode 1.0の時から出していたのに
MSだけが間違えたとか
なにいっちゃってんのこの人
0931デフォルトの名無しさん
2012/07/21(土) 18:22:23.18ttp://blog.rodoku.net/article/28326088.html
0932デフォルトの名無しさん
2012/07/21(土) 20:35:30.94のわりに間違いだらけですな
最初の「Windowsはshift_jis」の時点でもうアホかと
0933デフォルトの名無しさん
2012/07/21(土) 21:30:11.210934デフォルトの名無しさん
2012/07/21(土) 21:53:13.95「Windowsはshift_jis」
ってのがよくわかると思うよ
0935デフォルトの名無しさん
2012/07/21(土) 22:06:37.68どこにもShift_JIS()なんぞ使われない
しかもExcelの話とWindowsの話をすり替えられても
0936デフォルトの名無しさん
2012/07/21(土) 22:19:32.83表示系がcp932だと色々小細工しないとうまく行かないことがあるの
wndowsのGUI系は表示する時はワイド文字が使えるapiを使いなさいが暗黙のルールでしょ?
0937デフォルトの名無しさん
2012/07/21(土) 22:31:57.83ドザの低脳っぷりはよくわかりました。
0938デフォルトの名無しさん
2012/07/21(土) 22:36:06.88?
0939デフォルトの名無しさん
2012/07/21(土) 22:39:47.97> 表示系がcp932だと
その表示系の例をkwsk
0940デフォルトの名無しさん
2012/07/21(土) 22:42:16.24どす窓?
0941デフォルトの名無しさん
2012/07/21(土) 22:44:36.720942デフォルトの名無しさん
2012/07/21(土) 22:47:44.89シートで表示されてる文字が、マクロで使える文字列にすると
?
になる文字があるの知らないの?
0943デフォルトの名無しさん
2012/07/21(土) 22:51:26.680944デフォルトの名無しさん
2012/07/21(土) 22:53:02.810945デフォルトの名無しさん
2012/07/21(土) 23:07:10.31Excelのマクロはソースの文字コードと
MsgBoxがmbcsなのね。だがしかし
・ExcelとWindowsを混同するな
・cp932とshift_jisを混同するな
0946デフォルトの名無しさん
2012/07/22(日) 00:27:52.41区別付いてないし、>>934はもしかして本人?
0947デフォルトの名無しさん
2012/07/22(日) 00:31:40.400948デフォルトの名無しさん
2012/07/22(日) 09:59:54.780949デフォルトの名無しさん
2012/07/22(日) 10:17:58.80『よくわかる波ダッシュ問題』
『ズバリと書きたい』
『WindowsがEUC-JPで全角チルダ(0x8FA2B7)をもらうと「潤オ」と表示する』
クソワロタ。何が波ダッシュ問題だよ。
0950デフォルトの名無しさん
2012/07/22(日) 19:15:56.09別に個人の指摘に食って掛かるような内容でもないろうに
0951デフォルトの名無しさん
2012/07/22(日) 19:38:54.66普通にスルーされていたレベル。
「Winがもらう」と言う表現が出てくるあたり、
上のExcelの子もそうだけど同じ勘違いしてるんだよね
0952デフォルトの名無しさん
2012/07/22(日) 20:08:20.29だけじゃあ、わからんのだけど
0953デフォルトの名無しさん
2012/07/22(日) 20:25:52.160954デフォルトの名無しさん
2012/07/22(日) 20:29:32.500955デフォルトの名無しさん
2012/07/22(日) 22:07:40.96『Windowsはshift_jis』→違う
『sjis以外』→shift_jisとsjisの区別が付いていないし
『Windowsが〜をもらうと〜を表示』→データ読み取りも表示もアプリケーションの役割であってWindowsの話ではない。フォントもアプリ次第。
『内部でshift_jisに変換』→Windowsが内部shift_jisとかあり得ない
『WindowsがEUC-JPで〜もらうと』→WindowsがEUC-JPを受け取るとか意味不明
「シフトJISで入出力するアプリXにEUCのデータを与えるとYYと表示されました」だろ? 〜と関係無い
『Windowsが〜を送る』→Windowsがデータを送るとか意味不明。
『Windows以外が〜変換する場合』→何のことを言っているのか意味不明。
iconvとかならcp932もshift_jisも扱えるし、アプリ作成者またはユーザーが指定した文字コードで処理するだけ。
OSの話と糞アプリの仕様の話を区別しろってこった。
ついでにShift_JISとsjisは違う。
0956デフォルトの名無しさん
2012/07/22(日) 22:16:20.71文章で言い訳?
0957デフォルトの名無しさん
2012/07/22(日) 22:28:04.32まず俺から
System.あぼん(new[]{956});
0958デフォルトの名無しさん
2012/07/22(日) 22:37:39.89文字列をcp932で管理してるとハマる
windowsけなされたと勘違いしたんじゃないの?
0959デフォルトの名無しさん
2012/07/22(日) 22:51:36.21次スレらしきものがある…
0960デフォルトの名無しさん
2012/07/22(日) 23:23:35.98頭悪そうw
0961デフォルトの名無しさん
2012/07/22(日) 23:35:22.95焦ってるんかね、勢いなくなってきたから
0962デフォルトの名無しさん
2012/07/23(月) 01:04:48.09縁起が悪い
0963デフォルトの名無しさん
2012/07/23(月) 01:14:20.050964デフォルトの名無しさん
2012/07/23(月) 01:15:15.800965デフォルトの名無しさん
2012/07/23(月) 01:33:36.58馬鹿者ばかり集まるの?
特に>>1とか頭おかしいだろ
0966デフォルトの名無しさん
2012/07/23(月) 11:40:58.42文字コードについても語れるほどの知見があると思う勘違い。
生きてるだけで人生語る資格あるのと勘違いするのと同じ。
0967デフォルトの名無しさん
2012/07/23(月) 12:22:48.800968デフォルトの名無しさん
2012/07/24(火) 20:47:54.71文字コードスレに馬鹿者ばかり集まるんじゃなくて、
馬鹿者が集まるから文字コードスレができるんだ。
0969デフォルトの名無しさん
2012/07/24(火) 22:19:59.490970デフォルトの名無しさん
2012/07/24(火) 22:37:19.99見事に符合する
0971デフォルトの名無しさん
2012/07/25(水) 08:15:04.150972デフォルトの名無しさん
2012/07/25(水) 09:25:42.420973デフォルトの名無しさん
2012/07/25(水) 09:38:10.32/∵∴∵∴\
/∵∴∵∴∵∴\
/∵∴∴,(・)(・)∴|
|∵∵/ ○ \|
|∵ / 三 | 三 | / ̄ ̄ ̄ ̄ ̄
|∵ | __|__ | <うるせー馬鹿!
\| \_/ / \_____
\____/
0974デフォルトの名無しさん
2012/07/27(金) 02:39:45.39精神の安定が保てません
0975デフォルトの名無しさん
2012/07/27(金) 13:22:08.420976デフォルトの名無しさん
2012/07/27(金) 18:42:32.78発 者 同 チュウ 争
生 同 .じ + ゚ ・ + い
.し 士 .レ ゚∧,,∧∧ ゚ は、
.な で .ベ チュウ (* ゚( ) チュウ
.い し .ル .+ ゚ ・ + l っと ヽ .+ ゚ ・ +
.! ! か の ゚∧_ ∧∧ ゚ と__(__(^)(^) ∧∧ _∧
(*´・( ) ( )・`*)
l っと ヽ / つと l
と__(__(^)(^) (^)(^)_)_つ
0977デフォルトの名無しさん
2012/07/28(土) 07:45:19.00ご指摘ありがとうございます。
暇があったら訂正します。
0978デフォルトの名無しさん
2012/07/28(土) 10:39:02.36面白かったのに
0979デフォルトの名無しさん
2012/07/29(日) 21:55:03.15必死になってんじゃねーよ
おまえらが駄スレで争ってる間に
リア充は毎日セックルに励んでんだぞ。
人生もっと有意義に過ごせ。
0980デフォルトの名無しさん
2012/07/29(日) 22:19:56.68http://toro.2ch.net/test/read.cgi/tech/1342963035/
0981デフォルトの名無しさん
2012/07/30(月) 00:55:04.770982デフォルトの名無しさん
2012/07/30(月) 20:31:03.46http://engawa.2ch.net/test/read.cgi/underwear/1240791873/
レス数が950を超えています。1000を超えると書き込みができなくなります。