06/03/18 22:57:30
>>946
>ISO-2022-JP-MS は、Windows Codepage 50220, 50221 と互換性がありますので、NEC特殊文字(13区)、
>NEC選定IBM拡張文字 (89区～92区) を正しく扱えるようになっています。
13区と、NEC選定IBM拡張文字が使えるというのがポイントかと。
そうするとiso-2022-jp-cp932とかいう名前だったらOKとか（ｗ
951:デフォルトの名無しさん
06/03/18 23:37:38
そうじゃなくて、ESC $ ( ? という謎のエスケープが使えることなのでわ？
実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？
952:デフォルトの名無しさん
06/03/19 07:33:26
>>951
> そうじゃなくて、ESC $ ( ? という謎のエスケープが使えることなのでわ？
その通り。
そもそもMSに媚びた変換表を使う理由はWindowsとの相互運用のためなのに
Windowsで認識できない独自拡張を含める時点で手段と目的が転倒してる。
eucJP-msは比較的古くからあるし内部エンコーディングとしての用途もあるが
ふつう内部用には使わないステートフルなエンコーディングをわざわざ今さら
発明するのが全く意味不明。
> 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？
ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、
1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。
つまり範囲チェックすらせず機械的にCP932から変換している模様。
953:デフォルトの名無しさん
06/03/19 07:57:46
ESC $ ( ? はどんな文字集合を扱うんですか?
954:デフォルトの名無しさん
06/03/19 10:12:15
>>952
>> 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？
>ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、
>1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。
>つまり範囲チェックすらせず機械的にCP932から変換している模様。
それってOutlookの問題っすか？
ESC$(?つーのは
URLﾘﾝｸ(sourceforge.jp)
をみるとUDC（外字）を交換するための独自拡張みたいっすね。
C1はつかっていないみたいだけど。
iso-2022-jp-udcか（ｗ
955:デフォルトの名無しさん
06/03/19 21:29:27
>>954
> それってOutlookの問題っすか？
変換APIの問題だな。つーか実際にOutlookで転送を試してみた訳じゃなくて
変換APIの仕様から予想される挙動を書いただけだから。
> C1はつかっていないみたいだけど。
だから互換性がないんだってば。
> iso-2022-jp-udcか（ｗ
つーかそうやって何でもかんでも名前を付けたがる時点で終わってる。
文字コードは変換表ではない
URLﾘﾝｸ(web.archive.org)
まあiconvがパラメータにcharsetの名称しか取れないから
Ideographic Variation Sequencesと同じように「必要悪」なんだけど。
このスレの上の方で出ていたNFCとNFDに別のcharset名を付ける、みたいな
956:デフォルトの名無しさん
06/03/19 21:59:30
文字コードって次から次へと枠組み壊すヤツが出てくるよな。
957:デフォルトの名無しさん
06/03/20 08:20:55
野村雅昭とか野村雅昭とか野村雅昭とか？
958:デフォルトの名無しさん
06/03/20 11:42:13
せめて3つ目の一文字ぐらい伏せてあげて
959:デフォルトの名無しさん
06/03/20 11:47:54
字形変更と文字入れ換えとか
字形変更と文字入れ換えとか
字形変更と文字入れ換えとか
960:デフォルトの名無しさん
06/03/20 16:19:36
必要悪と言うか、「文字コード」ってそういうものだと思い始めてきた今日この頃。
> 文字コードは変換表ではない
「文字コード」自体がそもそも多義的だし、MIMEのcharsetとXMLのencoding/charsetは違う。
XMLはUTF-32の世界だから、encodingはUnicodeへの変換表だし。
UCS正規化の世界では、「‘文字コード’は変換表です。」
しかし、試しに実装していて思ったが、ISO-2022-JP-MSって中途半端だな。
ユーザ定義文字をなくすか、補助漢字も入れるかすればいいのに。
名前的にeucJP-msの文字を全部持ててほしいなぁ。
961:デフォルトの名無しさん
06/03/20 16:49:52
MIMEのcharset、XMLのencodingは、
CCS(Coded Character Set)のことでしょ。
XMLのcharsetはCS(Character Set)のこと。
> 文字コードは変換表ではない
これは、たぶんというか当然、前者のことでしょう。
962:デフォルトの名無しさん
06/03/21 00:53:23
XML 日本語プロファイルをみると、
URLﾘﾝｸ(www.w3.org)
確かに、XML の "Encoding" は CES であり、charset は
“A charset is a set of rules for mapping from a sequence of octets to a sequence of characters.”
と書かれてて、つまり ACS+CCS+CES なので両者は異なるわけだけど、
4.3.3 Character Encoding in Entities URLﾘﾝｸ(www.w3.org)
には Encoding を charset 的に扱うことが示唆されている。
ここで、XML の charset と encoding が同一視できる。
次に 2.2 Characters URLﾘﾝｸ(www.w3.org)
をみると、
“A character is an atomic unit of text as specified by ISO/IEC 10646:2000 [ISO/IEC 10646].”
とあり、 XML の文字集合は常に Unicode。
そしたらもう charset とか言いつつもただの Unicode への変換表じゃん。
ってか、ぶっちゃけ XML の話に限れば、両方 XML パーサーが文字コード変換プログラムに渡すパラメータでしょ？と。
str.decode(charset);
ここまで話は XML が UCS 正規化されているのを前提としているので、
MIME charset は変換表では無い、というのなら同意。
まぁ、遅かれ早かれこちらも毒されていくのだろうけど。
963:デフォルトの名無しさん
06/03/22 01:53:51
>>952
> ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、
> 1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。
> つまり範囲チェックすらせず機械的にCP932から変換している模様。
それと同じ挙動のencodingを定義しろよ。
iso-2022-jp-ms なんてイラネ。
964:デフォルトの名無しさん
06/03/22 11:15:56
こわそうなスレのようですが、教えてもらいたくてお寄りしました。
自前のアプリで unicode text も扱えるようにしようと調べているところですが、
unicode で書出すファイルには先頭に BOM を付けるようになっているようですが
これは必須ですか。またまじめな文書には必ず付いているものですか。
それとも、文字コードを見て、判定しないといけないのでしょうか。
965:デフォルトの名無しさん
06/03/22 12:39:51
>>964
UTF-16ならBOM必須。
つーか、BOMのないものは
UTF-16BEまたはUTF-16LEと明示する必要がある。
UTF-8のシグネチャは、まあ、好きにしてくれ。
966:デフォルトの名無しさん
06/03/22 14:02:39
>>964
UTF-16(Little Endian) のことを「unicode」って呼んでる？
それだったら、名前を「UTF-16(Little Endian)」とかにした上で、BOMはつけよう。
UTF-8は「UTF-8(BOM)」と「UTF-8N」に対応しておくのが無難だと思う。
967:デフォルトの名無しさん
06/03/22 14:43:11
>>966
> 名前を「UTF-16(Little Endian)」とかにした上で、BOMはつけよう。
「UTF-16（Little Endian）」なんていう紛らわしい表示にすると、
利用者からUTF-16LE（つまりBOMなし）と誤解される予感。
BOMが付いてるなら、単に「UTF-16」でいいやん。
968:964
06/03/22 14:49:28
>>965-966 ご親切に有難うございます。
unicode と言っているのは、VC++2005EEで default でコンパイルすると
なってしまう文字コードを想定しています。
しかし「明示する」とか「つける」という意味が初めてで分かりません。
ファイル先頭に 0xFFFE だか 0xFFEF だかをただ付けるだけでは駄目な
のですね。ファイル先頭の様式を並べたサイトとかあると助かりますが
ぐぐって見ます。
969:デフォルトの名無しさん
06/03/22 15:23:20
>>968
Unicode本で、32、47、79-81、400-402ページあたりを参照。
お望みの表は80ページのやつかな。
URLﾘﾝｸ(www.unicode.org)
URLﾘﾝｸ(www.unicode.org)
URLﾘﾝｸ(www.unicode.org)
URLﾘﾝｸ(www.unicode.org)
970:デフォルトの名無しさん
06/03/22 17:54:17
>>968
> unicode と言っているのは、VC++2005EEで default でコンパイルすると
> なってしまう文字コードを想定しています。
それだったら VisualStudioのスレで聞くか、
Microsoft のサポートに直接聞いた方が早いような気もする。
コンパイル結果の文字コードってのと、
実行時に特定のAPI使って生成された文字列の文字コードと、
VC++2005EE のエディタがデフォルトで使用する文字コードってのは全然別。
コンパイル結果の文字コードってのも、先頭に L が付いてる文字列リテラルとか
_T() で括られた文字列リテラルとか、etc etc
ちゃんと区別しないと何の事言ってるのかわからん。
とりあえず、スレ違いっぽい。
971:968,964
06/03/22 18:19:09
>>969
ご紹介有難うございます。
その後ぐぐって説明を読んでいますが、想像以上に複雑怪奇ですね。
自分のアプリの機能の１つは、ファイルをダブル・クリックすると文字であろうが
絵であろうが内容を見て表示するということです。文字の場合はしかるべき変換を
して edit control へ送り込んでいます。dos, linux, mac, jis, euc, .rtf,
.doc, .html（tagを抜く）, base64, ...と拡張して来ました。
edit control で文字にならないなら、.... 最後は hex。
これに unicode も含めたい。
で、今までのところ種種の文字変換を自前ってのは大変だなあとの感じ。
当面 SF_UNICODE を指定して edit control へ送るのかなと弱気になって
います。
972:デフォルトの名無しさん
06/03/22 20:39:56
「N'ko」って何て発音すればいいの?
973:デフォルトの名無しさん
06/03/23 06:02:07
「ンコ」でいいかと。
974:デフォルトの名無しさん
06/03/23 11:24:51
次スレのタイトルは、文字コード総合スレ part2 でよろ
975:デフォルトの名無しさん
06/03/23 14:03:41
統一はおかしいよな
976:デフォルトの名無しさん
06/03/23 14:11:17
あぁ、Raruty の右側のダイアログみたいな感じですね？（ぇ
UTF-16なテキストに対応するのでしたら、BOMがあるものだけ対応しておけばよいかと。
ついでにUTF-8も対応しておくといいんじゃないかな。
なお、edit controlまわりの話はわからないのですけれど、
文字コード変換はWin32 APIを使った方がいいのでは？
Shift_JISはCP932、EUC-JPはCP51932だと思えば、とりあえずはいいので。
URLﾘﾝｸ(msdn.microsoft.com)
977:デフォルトの名無しさん
06/03/23 14:52:55
>>976
>Shift_JISはCP932
工エｴ(´Д`)ｴエ工
978:デフォルトの名無しさん
06/03/23 15:04:25
なんでCP51932が使えないMultiByteToWideCharを出してんだろ……
CP51932がMultiByteToWideCharで使えないのってWindowsXPだけなんかな？
979:デフォルトの名無しさん
06/03/23 16:15:40
>>977
Shift-JISとCP932との違いを知らない人は相当いるよ。
あるいは知っていても大体同じだと言って区別をしない人も。
980:デフォルトの名無しさん
06/03/23 16:58:22
CP932と区別する場合は、Shift-JISではなくShift_JISと書きたい。
981:デフォルトの名無しさん
06/03/23 17:33:21
旧マックは正しいShift-JIS？
982:デフォルトの名無しさん
06/03/23 17:38:15
正しくないShift_JISはあるが、Shift-JISには正しいも正しくないもない。
983:デフォルトの名無しさん
06/03/23 17:49:20
>>980
Shift-JISとShift_JISとの違いを知らない人は相当いるよ。
あるいは知っていても大体同じだと言って区別をしない人も。
984:デフォルトの名無しさん
06/03/23 18:34:03
ShitJIS
985:971,968
06/03/23 18:39:30
>>976
ご助言を有難うございます。code page は GetACP() で済ませていまして
932 とかいうを知ったのはほんの数日前 VC++2005EE を使ってみてから。
WinAPI を使った変換は既に使っています。hex 表示でも右側に ascii 表示
をしますが、このときも SJIS, UTF-16, 純ascii、・・・ をマウスの
右クリックで変更可能にしないと何があるのか判別しにくいですから。
ただ、UTF は 16 しか対応していませんでした。というか GetACP() まかせ。
986:デフォルトの名無しさん
06/03/23 19:50:54
っていうか、Windowsで「Shift_JIS」って言っている時、
たいていShift_JISじゃなくてCP932じゃん。
987:デフォルトの名無しさん
06/03/23 20:20:48
「Windowsで」とは?
988:デフォルトの名無しさん
06/03/24 20:00:46
それこそ、意味もわからず「Shift_JIS」と書いているんだろ。
989:デフォルトの名無しさん
06/03/25 03:58:22
文字コードの種類は何故複数あるのでしょうか？
ｽﾚﾘﾝｸ(tech板)l50
990:デフォルトの名無しさん
06/03/26 09:35:52
↑
991:デフォルトの名無しさん
06/03/26 09:39:05
↑
992:デフォルトの名無しさん
06/03/26 21:21:33
↓
文字コード総合スレ part2
ｽﾚﾘﾝｸ(tech板)
↓
993:デフォルトの名無しさん
06/03/26 21:31:10
←
994:デフォルトの名無しさん
06/03/26 21:48:06
↓
←
995:985,971
06/03/27 07:15:05
教えて貰って UTF-16, UTF-8 の文書をファイル名ダブルクリックで表示するよう
やってるんだが、rich edit control は EM_STREAMIN & SF_UNICODE で UTF-16
は表示するが、UTF-8 は無視される。VS C++2005EE では project.sin ファイル
が UTF-8 なので、これで試しているが、手抜きだなあ。
996:デフォルトの名無しさん
06/03/27 09:20:09
出て行け
997:デフォルトの名無しさん
06/03/27 11:48:18
渡世人でごさんす。通りすがりでちょいとご挨拶したまでで、
長いは毛頭いたすつもりはありやせん。ご懸念なく。ヘイ。
おあにいさんもシマの見張りをご苦労さんでござんす。
998:デフォルトの名無しさん
06/03/27 13:07:15
UTF-8 と UTF-16 は別物。
SF_UNICODE の 「UNICODE」 は UTF-16 のことだから、UTF-8 が認識されないのは当たり前。
999:デフォルトの名無しさん
06/03/27 15:35:15
次スレは？
1000:デフォルトの名無しさん
06/03/27 15:37:16
文字コード総合スレ part2
ｽﾚﾘﾝｸ(tech板)
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。