文字コード統一スレ 1文字目

プログラムにおける文字コードの取り扱いについて議論する統一スレッド
です。

ほぼ前スレ
【UTF8】文字コード変換【SJIS】
http://pc5.2ch.net/test/read.cgi/tech/1063177450/

参考ホームページ
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
ISO-IR - 2.8.1 Coding systems with Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
ISO-IR - 2.8.2 Coding Systems without Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm

文字コードを統一するのか？
アホか？

アホw

「文字コード乱立スレ」ってわけにもいかんし…

新スレ発見！ 乙 >>1
リンク貼る前に埋めんな＞前スレ999-1000

>>1 乙

Win32 API で UTF16 を EUC-JP(-ms) にするときは、
　UTF16 →(WideCharToMultiByte)→ CP932 →(自分でがんがる)→ EUC-JP
が普通なのかなあ・・・。

ドキュメントでは WideCharToMultiByte の CodePage に 51932 を指定すれば一発でできそうに
書いてあるのに、実際やるとなんでﾀﾞﾒなんだよ（ｗ
CP20932 は微妙に変換ルールが違うみたいだしなあ(´･ω･`)

IMultiLanguage Interface
http://msdn.microsoft.com/library/default.asp?url=/workshop/misc/mlang/reference/ifaces/imultilanguage/imultilanguage.asp
これは対応している予感。使ったことないから知らないけど。

文字コードを統一？
TRONコードの出番か！

>>7
俺は変換テーブルを実行ファイルに組み込んでいる。
200KBぐらいだけど、これで特に問題はない。

ところでUTF16なんてあるの？

アホなスレタイだなｗ
「統一」いらんじゃんｗ

とういつ【統一】
まとまりのないばらばらな物事を１つのものにまとめること。

新しい文字コードでも作るつもりなのか？このスレ

1も読めないのか。読んで言っているのなら白痴だな。

>>7
うるさいことを言わなければコードページ20932がなんとなくEUC-JPに近い。
JIS X 0208 にない文字は変になるけど。

スレタイも読めないのか。読んで言っているのなら白痴だな。

>>13 辞書を引用し、都合のいい解釈をする
>>16 人の言葉をモジって言い返す
アホの典型

ではスレタイはどんな意味で統一と入れたのか

早く各種ローカルコードからUnicodeへのマッピングを統一してくれ．
あと，サロゲートペアってもうなくならんのだろうな…
結局固定ビット長で処理できねーじゃんか．

まずスレタイの意味を統一すべきだな。

>>19
32bitで固定

他に文字コード関連のスレを立てる人がいないように「統一」の
文字を入れました。もう立っているみたいですが。

普通「総合」じゃないのかな？

ま、洒落と言うことにしといてくださいな。

統一だろうが総合だろうがどうでもいいんだが・・・

>>7,15
ttp://msdn.microsoft.com/library/en-us/intl/unicode_81rn.asp
によるとCP20932はJIS X 0208-1990 & 0121-1990だな。

>>21 そりゃなんでもあまりにもスカスカ過ぎないか？
まぁメモリ潤沢な昨今のパソコンならそれでもいいと思うけど、
やっぱり2バイトくらいにとどめておいて欲しかった。
つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。
次の面に素直にもってくりゃよかったんだ。

> つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。

その通り。サロゲートペアは2バイトという幻想にとらわれた故の特殊事情であって、
もはやUnicodeとしてはサロゲートペアなんぞ使わないのが正しい。

さすがに第1群以降は使わないよな？
せめて最上位バイトを内部処理用フラグとして使いたい。
まぁ外に出すときにはクリアするが。

確かに文字コードは頭が痛くなる問題ですね。
早く標準が固まって欲しいです。

ただ、右から左にテキストを書くやつ(アラビア辺り?)とかは
絶望的じゃなかろうかと思ってみたりみなかったり。

>>30
標準ならあるぞ。たくさん(笑)

right-to-leftの何が絶望的なんだろう? ふつうにWindowsでも扱えるは
ずだけど。

ストリームの出現順の問題のことを言ってるのかな？

>>30
日本語は縦書きなんだが

>>30
描画方向が違うだけだと思うYO

日本でも昔の看板とかは右から左

笑止！それは一行一文字の縦書きにすぎぬわ！

そんなわけで本文なんかを横書きにする場合では、
相当古くから(もちろん明治維新よりは後だが)
今と同じく左から右へ書いていたそうな。

左←右圏でも縦書きされる場合があるらしい。看板とか。

まさにアホなスレタイ
文字表示雑談スレ

右から左に書く場合でも、数値だけは逆だったりするよね。
日本語にたとえれば、「。すで年2005は年今」みたいな感じ。

アホなスレタイだとアホしかよってこない。
スレタイってやっぱり大事なんだね。

>>8 動作要件に IE4 以上というのが気に掛かる・・・。
>>10 その方法を考えたけど、実行ファイルが肥大化するのと、他の Windows アプリとの
　　データ互換性が保証できなくなるのがネック・・・。
>>15 >>26 一見よさげだけど、たとえば「〜」なんか化けてしまうのが致命的・・・。

みなさんどうもでつ。もう少しいろいろ検討してみまつ。

>>27
ISO 10646 dis v.1

>>41　意外とまともな事言ってる人もいると思うが。

http://suika.fam.cx/~wakaba/-temp/wiki/wiki?ISO%2FIEC%2010646
>>43 それって、この表だとどの規格のこと？

>>45
DIS 10646:19911990-12-061st DIS

>>43
寝言言ってねえで素直にUTF-32でも使っとけ。

>>44
Unicodeは複数コードポイントを組合わせる可変長表現なのに、
相変わらず２バイト４バイト固定とか言ってますが。

結局シフトJISに統一されるんだよな

（・∀・）ｳﾝｺｰ

>>48 その「固定」ってのは sizeof wchar_t の話だと思う

総合といいたかったのか。なるほど。

>>51
Linux の gcc だと sizeof(wchar_t) == 4 で、
Windows の VC++ だと sizeof(wchar_t) == 2 だったり。

将来の主流は、__wchar64_t になると予言しておく。

typedef unsigned int wchar_t;
が
typedef unsigned _int64 swchar_t;
になって
typedef unsigned _int128 xwchar_t;
になって
typedef unsigned _int256 uwchar_t;
になって（ｒｙ

>>55
unsigned _int64って何だよ…

いまや#include <stdint.h>で、uint64_tじゃないのか?

>>51
wchar_tはUnicodeが入るとは限らないんだけど、そのままUTF-16やUTF-32
を突っ込んでる実装が多いから良しと仮定しましょう。
wchar_tにUTF-32が並んでいても、そこから文字（grapheme）単位に処理
するにはステートマシンで区切りを探さないといけない。
　http://www.unicode.org/reports/tr29/
こういったことを理解しての発言には見えない。
加えて、ICUもそうだけどUTF-16が処理対象の場合はサロゲート込みで処
理されるからサロゲートの有無で手間は全く変わらない。

>55
さすがに地球外知性とデータ送受信するようにでもならないとそこまでは……
いや、そうなったらそうなったで、向こうのコード体系を強引に押しつけられる悪寒orz

>>57
> そこから文字（grapheme）単位に処理
> するには
誰もそんなこと書いてないと思うが。

文字単位に処理することはあり得るだろう？

あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは
バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という
考え方もあった罠。
この考え方を Unicode にあてはめてみたり、とか。char を wchar_t に変えて。

>>61
> あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは
> バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という
> 考え方もあった罠。

それほど変ってないような…

そしてその「アプリケーションの責任」の技術的な部分の研究を、
一番行っているのはUnicodeの世界なのでは?

結局「一文字」単位に扱おうとすると,
ステートマシンは必要になるのか…
なんかあんまり変わってないな，昔と.

>>63
そういう領域はUnicodが解決しようとした問題領域に含まれていないものと思われ。

結局は、ASCII 系のコードしかなかった頃は基本単位（char） 1 つに
英数字程度しか入らなかったけど、Unicode では基本単位（wchar_t） 1 つに
漢字とかも入れられるようになりますたよ。

でも、国際化を考えるときは 1 基本単位＝ 1 文字と仮定するのはやめようね。
というのは変わってないということか。

http://www.hatena.ne.jp/1105667960

>>59
UAX #29でも触れられているけど、文字（grapheme）単位に
処理できないと文字列の文字数を得たり、分解したりできな
いのはもちろん、比較や検索も正しく行なえない。

normalize してもコードポイント一つであらわせない文字は正しく扱えません
としても、それほど困らないんだよなあ。
実装コストに見合うメリット無いし。

>>67-68
内部文字コードが Unicode 化された Visual Basic 4.0 以降や Java なんかでは、
「文字列をバイト単位で切り出すにはどうすればよいですか？」という質問が
必ず FAQ になってるよな（ｗ

U+F92FとU+F98DのkIRG_KSourceが間違ってる件について
これどうやったら修正させることができるんですか
韓国のNational Bodyが言い出さない限り何人たりとも修正できないんでしょうか
とりあえずUnicode 4.1.0βのレビューで指摘してみたけどシカトされますた
ほかの指摘事項はちゃんと反映されてたから指摘そのものは届いてるはず

ほかの指摘事項はたまたまほかの人が同じ指摘をしたんだろう

5件あって5件ともたまたま別の人が同時に指摘したってあんまりありそうにないような
「報告ありがとう。Unihanの専門家に転送しとくよ彼が今日中に反映してくれるだろう」
みたいな返信もちゃんと返ってきたし。
正規表現が間違いだらけだったから正しいの書いて送ったけど他の誰かが一字一句
ピッタリ一致するような正規表現をたまたま同時に送ってたとかありえなーい。
つーかスクリプトに通して検査するだけで見つかるような誤りがなんでボロボロ
出てきますか? なんのために機械可読な形式で提供してますか?

もう一回聞いてみればいいじゃん

戸籍やってる身からすれば
康煕字典体はきっちり入っていないと

ところで，Unicode って既存のコードとのラウンドトリップは考慮されてるの？
つまり Unicode に変換されたとたん，元のコードでは区別されていた文字が
同じ文字にマップされたりはしないの？
それはいわゆる機種依存文字も含めて？

文字コードを作る人は馬鹿ですか？
なんで固定バイト数にしないんだよ。
先頭数ビットを国コードにして残りを文字コードに割り当てる。

似ている文字でも国ごとに別の文字コードにするべきだ。
そして検索の機能として文字コード検索と、文字形検索の二つに分ける。

>>76
UNICODE棄てれば実現可能かもね

>>76
そしてPhishingが横行

多言語ドメインなんてくだらないものは捨てちまえ。

>>76
Emacsの内部コードがそんな感じよ。文字列表現はマルチバイトだけど。
国ごとじゃなくて文字集合ごとだけど実質あまり変わらん。

マジな話、文字形検索（文字コードではなく文字の形で
検索すると言う意味）って考え方ないの？

同じ形の字でも国が違えば検索に引っかからない方がいいだろうし、
同じ国でちょっと違う形の字でも同じとして検索した方がいいこともあるだろうし、
国は分からないけど、すべての国対象で似ている字を検索したいこともあると
思うんだけどなぁ。

1 I l | ! i │ �@ �T (以下略)をどこまで一緒にするのやら

>>75
文字コードA →Uniocde→文字コードA と、元に戻せることは配慮されてる。
そのために互換用文字とか元規格分離の原則とかがあるわけで。

機種依存文字は、例えばJIS X 0208のShift_JISとMicrosoftのCP932と
Appleの拡張Shift_JISは「別の文字コード」なので、Unicodeを介した
それぞれの変換で情報が失われないことは配慮されない、という扱い。

<とくを一緒にされなかっただけでも不幸中の幸い

へとヘは？

タと夕とか
トと卜とか

ロとか口とか

(以下略

C++ で文字コード変換したいと思った場合、
Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、
UCS-4 のコードから、文字種別などの文字情報を取得するライブラリが
OS標準にないというのが悲しい。

Windowsの事しか考えられないバカは去ってくれ。

>>90
そりゃ言いすぎ(w

けど、
> Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、
つーのが、もうスレの主旨には全く合わないな。
それが良いかどうか語りたいようなヲタの住むスレなんだから。

>>73
Unihan-4.0.1d4で修正されてますた。
つーかよく見たらUnihan-4.0.1d3のヘッダにも
> Similarly, U+F92F should map to kIRG_KSource 0-523E, not 0-523F, and U+F98D should
> map to kIRG_KSource 0-663C, not 0-663D.
って追加されてた。正直スマンカッタ＞unicode.orgの中の人

Unihan-4.1.0d4とUnihan-4.1.0d3の間違い

iconv(3) の引数 inbuf の型が、glibc 版だと char** になってて libiconv 版だと const char** なのがイヤン

>>94
SUS的にはchar**が定義らしいが、現実的にはconst char**じゃないと
面倒なんだよな。

>>83 に関連した疑問なんだが，各種日本語文字コード，Unicode間で
縦横無尽にマッピングしまくッっても安全な集合って
どこかで定義されてない？？

サロゲートうんこ

内部はgrapheme clusterを単位にした固定長コードにでもしないと
面倒でやってられんぞ

>>95
http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html
では const 付きだけど

http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.h.html
には const 付いてない(つД`)

>>96
\~￣―＼〜‖…−￥¢£¬とか
CP932におけるNEC選定IBM拡張文字 とか
古えの半角ｶﾅ とかの話?

�@�A�B�C�D�E�F�G�H

>>100 そう．そういう微妙な文字以外の
「安全な」文字の集合ってどこかでまとめてくれてないかな，と．
自鯖の掲示板で，サニタイジングのついでに警告を出したい．

>>98
コードポイント３つ４つの組合せもあるから、余裕も見て内部は
1 cluster=20byte位の固定長？素晴らしい富豪設計です。

>>103
任意のスカラ値の組み合わせが可能な訳じゃないからそんなに必要ない

よくある実装が必要な組み合わせだけ適当にPUAに割り当てて
知らない/対応する気のないスクリプトはそのまんま素通し
どうせ未定義の符号位置に関しては素通しにせざるを得ないんだし

つーかなんでこうも過度に汎用化したがるんだろうか
シフトJISのアプリケーションがISO 2022完全実装に対応できないから駄目なんて
文句言う奴はいないのになんでUnicodeになったとたん単なる地域化じゃ許されなく
なりますか? 単に漢字をたくさん使いたいだけというささやかな望みも叶いませんか?

>>102
(jisx0201左半面 or ASCII) + (jisx0208) - (\~￣―＼〜‖…−￥¢£¬)
前提がひどく厳しいのでこんなものじゃないかしら。
ISO-2022-JPの…なんてことは言わないで頂戴。

いわゆる機種依存文字や半角カナが非互換なのは、unicode以前からの通り。
\~￣―＼〜‖…−￥¢£¬は、unicodeの普及によって新たに生じた非互換。
(余談だけど、後者は終止unicodeのみで処理するときでさえいやらしい。)

「自鯖の掲示板」で「縦横無尽にマッピングしまく」る必要はないようにも思うが。

人間はなぜ同じ過ちを繰り返すのでしょうか？

>>107
過去の失敗から学ぼうとしないからだ、と何回言ったら分かるんだ

>>104
HangulやDevanagariは３つ４つ平気で使うよ。

>109 タイ語もたくさん使うよ。

>>109-110
だから3つ4つの任意の組み合わせがすべて必要なわけじゃないだろ。
Windowsのフォントフォルダ見てもインド語のフォントは500KBもないし
実際にPUA使ってリガチャを実装してるタイ語やインド語のフォントだって
BMPの6400文字で十分に足りてる。理論上可能なすべての組み合わせを
サポートするニダ150万コードポイント必要ニダUTCは謝罪と賠償しる!
とはさすがの韓国も言ってないみたいだし。
そもそもそんなこと言い出したらIdeographic Description Sequenceなんか
最大16コードポイントの並びだし。

>>111
要約すると「Windowsでは使わない、使えないから不要」ということ？
でしたら特定の実装上と限定して話しをして下さい。

ちなみにAppleのATSUIだと、PUA使ってリガチャを実装なんて変なこと
はやってないから、長いdecompositionで表現したcomplex scriptでも
glyph metamorphosis tableを使って適切なglyphを拾って来る。
この実装上では、complex scriptが扱えなかったり、ヒラギノOpenType
の豊富なglyphを使えないと粗悪品とみなされます。

Windowsが扱うコードをすべてutf-8に統一したいんですけど、できますか?
たとえば、コマンドプロンプトとかでutf-8で書いたコンソールに文字列を出力するjavaのコードをコンパイルしたものを実行したいんです。
現状では、コマンドプロンプトはMS932(Shift_JIS)と勝手に解釈してへんちくりんな文字列を出力します。

>>113
毎回MultiByteToWideChar(CP_UTF8, で変換するしかない。

>>113
CygwinのLC_ALLにutf-8って指定できなけったった？

OutputStreamWriter(system.out, "MS932")

>115
Cygwin のロケール周りはきちんと実装されていないはず。

経済産業省が、こんなこと発表してた。
http://www.jisc.go.jp/newstopics/2004/041221kanjicode.htm

現在、最新のＪＩＳ漢字コード表を採用した情報機器は多くありません。
しかしながら、人名用漢字の改正を契機に最新のＪＩＳ漢字コード表が普及することが期待されます。
人名用漢字（９８３字）の水準ごとの字数は、次のとおりです。
第１水準：６８５字 第２水準：１９１字 第３水準：１０７字 第４水準：０字 合計：９８３字
（注）第１水準漢字及び第２水準漢字しか実装していない情報機器では、
１０７字の人名用漢字について情報交換が行えないことになります。

これは、Unicode導入をどんどん進めろと言いたいわけか ?

>>118
AppleもMicrosoftも、UnicodeのレパートリとしてしかJIS X 0213はサポートしないと
ずっと前から言っている。それをようやく追認しただけ。
その発表書いた中の人のコメント↓
http://slashdot.jp/comments.pl?sid=230343&op=&threshold=1&commentsort=0&mode=nested&startat=&pid=0

リンク先にはもうコメント付けられないからここに書いとこう
> ＃戸籍統一コード のページができているのにも気がついた。これはいわゆる
> 住基コードなんだろうか。
違うもの(なんつー税金の無駄遣い…)。
http://www.itscj.ipsj.or.jp/senmon/03sen/moji.html

> JIS X 0213の2000年版と2004年版でUCSが違う(正確には2000年版では「参考」
> として載せられていた363個のUCSが、2004年版では「規定」になったうえにUCSでの
> 符号位置も変わった)
それは(Unicode 3.0以前に)対応するUCSがないと「規定」されていたものに
(Unicode 3.1以降への)対応を追加しただけだからまあ許せるけど
2面93区27点をU+9B1D(規定)からU+9B1C(規定)に変えたのをお忘れですかセンセイ
そもそも「変わった」とか他人事のように言ってるけどあんたが変えたんでしょうに

> 変えたのをお忘れですか
これは本気で忘れてる可能性もあるんだよな
あれだけあれこれ言い訳してるJIS X 0213:2004の解説でもこの件には
なぜか一切触れてないし

JIS X 0213 で例示字形が大幅に変えられたことの影響はどうでるか。

以前、小形克宏氏は「文字の海、ビットの舟」で
「ほとんどのフォントベンダーの対応は、... 世間が新しいMS書体を
どう受け入れるかを見極めた後になるはず。」としていた。
http://internet.watch.impress.co.jp/www/column/ogata/sp18.htm
しかし、Windows でまず登場したのは、ジャストシステムからで、
一太郎2005ユーザー登録特典の「JIS X 0213:2004」対応フォント
が登場した。http://www.ichitaro.com/2005/taro/toku07.html

日本工業標準調査会のサイトが「最近、JIS X 0213:2004について問合せが
多いため」と、JIS X0213 関連の情報をまとめたページを作ったのは、
ここからリンクがあるためだろう。http://www.ichitaro.com/value/jis.html

このフォントは一太郎で標準ではなく、無償であってもオプションのフォントだ。
そうなっている一番の理由は、JIS2004 での大幅な例示字形の変更に対応して
表外漢字字体表の印刷標準字体を使ったフォントだからに違いない。
既存の文書までフォントが変わったことで、意識しないのに字体が
大きく変わってしまっては困るから。
標準のフォントを変えたり、それしか使えなくなっては 83JIS の時の二の舞。

今後マイクロソフトが JIS2004 にどう対応するのかは、はっきりしないとしても
似たような対応になるだろう。
マイクロソフトは表外漢字字体表が制定された時に、JIS漢字の例示字形について
「今回仮に例示字体・字形を差し替えたとしても、差し替えられた面区点位置に
包摂されている字体・字形をもとに実装することは依然として規格に反しない」
「こうした利用者が意識しない変更を生産者が押しつけるわけにはいかないので、
利用者が意識して表外漢字字体表の字体を選択できるよう生産者は考えざるをえない」
との見解を表明していた。もっともな見解だ。
MS の方こそ、当面は今の MS明朝・MSゴシックでやっていって、どんな利用者の要求
があるか様子みましょう、となって急がないかもしれない。

人名用漢字は印刷標準字体の方で規定されている。
もともと第1・第2水準漢字を規定した JIS X 0208 の例示字形は変更されていないと
いうから、第1・第2水準の漢字の字形は、JIS としても実装としても、
2種類あることになって、必要に応じて使い分けることになっていくのか。

>>119 があげていた安岡先生のコメントに
> でもJIS X 0213の「エンコーデング」の主流が「Adobe-Japan1」
> になるのだけは、個人的に勘弁してほしい。
とあった。Adobe が「エンコーデング」というのは笑えるが、けっこう強そう。

>>122
某フォントスレからの情報

213 ：名無し~3.EXE ：2005/05/01(日) 04:40:02 ID:++Vj6Nxl
Meiryoは印刷標準字体になるって噂もあったが変わってないな

218 ：213 ：2005/05/01(日) 18:45:08 ID:++Vj6Nxl
違った
Adobe Japan1-5相当になってるっぽい
でもデフォルトで印刷標準字体になるって言ってた気がするんだが…。
Longhornの環境だとデフォルトで'nlck' featureが適用されるんだろうか

231 ：名無し~3.EXE ：2005/05/02(月) 19:39:51 ID:BAiJXOjJ
Longhornではこういうことができるらしい
<Inline Typography.EastAsianLanguage="NLCKanji">葛</Inline>飾区
<Inline Typography.EastAsianLanguage="JIS90">葛</Inline>城市
第64代横綱<Inline Typography.EastAsianExpertForms="True">曙</Inline>
Avalonマンセー

>>124
> Adobe が「エンコーデング」というのは笑えるが、
Adobe-Japan1-0〜Adobe-Japan1-6はCIDをビッグエンディアンでそのまんま並べた
エンコーディングの名称でもある

> Longhornではこういうことができるらしい
> <Inline Typography.EastAsianLanguage="NLCKanji">葛</Inline>飾区
そういえば、Longhorn ではインターフェースを XML 使って構築する話、
どこかで聞いたな。そこでフォントも指定できるか。

印刷標準字体を採用となれば、葛飾区は喜ぶ方の口だったっけね。
茨城県や芦屋市もいいのかな。小樽市や灘区はどうなん ? どっちでもいい ?

奈良県に葛城市ができたのは知らなかったぞ。
こっちは、JIS X 0213:2004 改正で消滅した字体の方を使ってるじゃないか。
なんなら、JIS X 0208 字体を使い続ければいいけど、たいていは、いちいちフォント切り換えないぞ。

JIS漢字コードとその実装の字形が2種類になるのは、表外漢字字体表からの当然の帰結。

将来、文字コードのトピックにちょうどよくなりそうなので、書いておこう。

2004年10月1日、奈良県に葛城市が誕生した。奈良県北葛城郡新庄町と同郡當麻町の合併である。
なお「葛」の字形は、「北葛城郡」は漢字の『人』を書く方(JIS X 0213:2004字形)だったが、
新市名「葛城市」はカタカナのヒを書くの方(JIS X 0208字形)に変わった。
新市名称公募は、2004年1月6日から1月31日までの受付期間で行われ、以下が結果報告のサイトからの引用。

応募点数で最も多かったのは『白鳳市』で205点、次いで漢字の『人』を書く『葛城市』143点、
カタカナのヒを書く『葛城市』89点、ひらがなの『かつらぎ市』85点の順になりました。

その後、新市名称候補選定小委員会を経て、合併協議会において協議・決定された名称が、
第3位だったカタカナのヒを書く『葛城市』である。

なお、なぜ第3位が浮上したかというと、新市名称候補選定小委員会が
「人」と書いても「ヒ」と書いても同じ「葛城市」だから同一と考え、
そこからパソコン等で使われている方との理由で「ヒ」と書く「葛城市」を
候補として選び、住民アンケートの結果、第1位を獲得したからである。
このとき、すでに表外漢字字体表はもちろん、JIS X 0213:2004 も公示されていたが、
候補選定小委員会で検討された様子はない。届いていなかったと思われる。

>>132
「パソコン等で使われている方」でちょっと思い出した事が。
こないだ、青森県西津軽郡車力村が他と合併して「つがる市」に
なったんだけど、その時にある字名の表記が変更になった。
旧：青森県西津軽郡車力村大字下牛潟字靎舞岬（つるまいみさき/靎は雨冠の下に金+鳥（U+974E））
新：青森県つがる市下牛潟町靏舞岬（つるまいみさき/靏は雨冠の下に鶴（U+974F））
http://www.city.tsugaru.aomori.jp/tugaru/pdf/add_shariki.pdf

鶴にするならともかく、どっちも第3水準だし最初は疑問に思ったんだけど、
これって靏がWindowsの外字部分に含まれてたから表記しやすい
方に、って事だったのかもしれない。

統一するってことは、世界中の文字を表現できるようにするってことだよな？
しかし、それぞれが持ち寄った文字数をみると漢字圏が大きすぎる
普段は使わない人々からすれば対応するだけ無駄が多すぎとしか思えない

言語統一を推進するほうが将来的にいいじゃんてことになる。だから無理

あのね、Apple, IBM, Microsoft, Sunの様な会社は、
漢字文化圏も重要なマーケットと考えているんですよ。
君のいる三流ソフトハウスは違うだろうけど。

漢字文化圏でも今や重心はあっちの国だがな。

sunの禿、ギコが見れてうれしいって言ってた気がするなぁ。

>>134
いいから黙ってUTF-8使っとけ

なるほどねえ。Longhorn での WinFX のクラスライブラリ予定を見たら、
"FontEastAsianLanguage 列挙体" なんてのがあって、
フォントによって字形(glyphs) が異なるバージョンを並べて、選択できるようになってる。
JIS78, JIS83, JIS90, JIS04, HojoKanji と、ここまで日本向けか。
確かに、これが簡単でないと、この先は困るよ。よくわかっていらっしゃる。
日本もまだ、Microsoft の重要なマーケットですって。

ちなみに Mac OS X の対応してそうな機能
http://developer.apple.com/fonts/Registry/

>>140
これは最新の情報ではないよ。実際に使えるのはもっと多い。
フォントパネルからTypographyパレットを出せば、フォント毎に
使用可能なFont Featureが列挙される。
>>131
で出ている「葛」もヒラギノを使っていればどちらの字体も選べる。
これはOSXのAAT+ATSUIで「今」できる機能

「Updated 2/5/98」だから最新の情報なわけはないと思ってたけどやっぱりそうか。

あとはAdobe Japan1-6をJIS X 4165(ISO/IEC 10036)に登録してくれれば
インターネットでの情報交換も問題ないんだけどねえ
誰かやってくれないかなあ

第3水準漢字を含む人名用漢字表のテキストを作る実験してみました。報告します。

人名用漢字表テキストを作る簡単な方法は、経済産業省から
「人名用漢字の文字符号に関する規格検討会報告」（PDFファイル）
をダウンロードし、この中の人名用漢字表をエディタ等にコピー&ペーストして
Unicode のエンコーディングで保存する方法です。これなら入力手段も不要です。
すべて BMP 内ですから、サロゲートペア対応までは必要ありません。
http://www.jisc.go.jp/newstopics/2004/041221kanjicode.htm

最初は、総務省の法令データ提供システムから「戸籍法施行規則」を見て、
そこの漢字表を調べたのですが、正式の表の形を知るにはこちらが必要でも、
内容はとんでもないものでした。一度、見比べて下さい。
http://law.e-gov.go.jp/htmldata/S22/S22F00501000094.html

水準別の一覧表としては、こちらを参照できます。
http://www.eonet.ne.jp/~kotobukispace/ddt/itaizy/jinm0409.html

人名用漢字を表示するには、やはり JIS X 0213:2004 対応フォントが必要なようです。
たとえば、一太郎2005 で入手できる JS平成明朝W3[JISX0213:2004] を使えば、
第3水準漢字も含めすべて表示されますし、戸籍に認める正しい字形です。
Windows では、他のフォントを使うと第3水準の分の半分ほどが表示できませんでした。
表示される字も、字形が人名用漢字としては正しくないものが多く出ます。
たとえば、「人」と書く「葛」が正しい所が、「ヒ」と書く「葛」になるわけです。
JISの包摂基準では同じ字であっても、戸籍上の名では字形が限定される点が、
この先、人名データの扱いが難しくなる所です。
「葛城市の山田広葛くん」が誕生したら、２つの「葛」の字形は異なるのが正しい、
なんてケース、どう処理しますか。
まあ、表外漢字字体表を楯に、人名優先で有無を言わせず印刷標準字体を使うのが、
簡単だとは思ってますが。ごめんなさい、葛城市。

漢字表のコピペ先のエディタとしては、Windows XP の場合はメモ帳が適当でした。
このテキストを表示させようとして、予想以上の壊滅的打撃を受けたのがエディタでした。
第3水準漢字をきちんと表示できないものが多そうです。
Unicode のエンコーディングを読み書きできるということと Unicode 対応ということが、
まったく違うことだ、という当たり前のことが現実のものとなります。

> なんてケース、どう処理しますか。
Longhornまで待つかMacを買うかだな。

> Longhornまで待つかMacを買うかだな。
その限りならそうとして、MacはJIS X 0213:2004対応済? 待ち?

Mac OS Xは、JIS X 0213:2000に対応すると一時言ったけど、
結局Unicodeに含まれる限りにおいて、と修正。
2004も同様。いわゆる対応はやらない。

>>148 なるほど。
Shift_JIS-2004 はサポートしないと言っているということかな。

レパートリが揃っているか、という意味なら現時点で対応済み。

>>149
Shift_JISX0213には対応してるみたいよ。
2004は知らん。

>>150
内部がUnicodeだと、合成に対応しているかどうかが問題になる。
半濁点つきのカキクケコ(鼻濁音用)とか、半濁点つきのトツセ(アイヌ語用)とか。
そこまで注意しないと、がっかりする人が出るはめになる。

セミナー：　CJKV 日中韓越情報処理
ttp://www.jtpa.org/event_in_silicon_valley/000285.html

講演は英語だってさ。

最近（でもないか?）CJKV って聞く様になったけど、何で越南だけ追加されたんだろう

>>151
OSXは現状で合成に対応してます。
ATSUIは正しくレンダリングするし、区切り判定も合成文字を１文字と
認識します。
このスレでも散見されるけど、合成対応は意味がないから無視という姿
勢のアプリケーションではだめですね。

>154
おお。なかなか。
ところでデーヴァナーガリーなんかのリガチャはどうなるんだっけ?
あれを一律「一文字」にされると古典を扱うときヽ(`Д´)ﾉｳﾜｧｧﾝなことになるんでちと気になって。

>>151
青空文庫の中の人によればShift_JIS-2004には未対応
http://www.siesta.co.jp/aozora/archives/001145.html
これは去年の話だからもしかしたらTigerは対応したのかもしれないが
そこまでは知らん

包摂に対する考え方が、JISとUnicodeは違うけど、
2004なら追加文字で問題がなくなる→JIS X 0213対応ってわけ?

>>150
いまはまだ過渡期とはいえ、Unicode でレパートリが揃い、使えれば
「JIS X 0213:2004 対応」と言う段階に入ってきていると思う。
少なくとも、ジャストシステムが「JIS X 0213:2004 対応フォント」
と言うときには、その意味で使っている。
このフォントで、Shift_JIS-2004 のテキストが表示できるわけじゃない。
ATOK2005も「Unicodeを使うJIS X 0213:2004 対応」での入力手段。
>>119 にあるように、規格作成当事者からも
> JIS X 0213の「エンコーディング」を捨ててしまう
は追認されてる。

蛇足だけど、Unicode マンセーって言ってるわけじゃない。
Unicode導入とは非関税障壁撤廃が進んでいるというだけのこと。
ただ、それで便利にできる所は利用する。
中国の方が日本より上手に対応してきた。

>>159
> 中国の方が日本より上手に対応してきた。

これマジレス?

つまり中国を見習って、Unicodeの全文字を含み1文字最大4バイトで表現する
新しい文字集合とエンコーディングをJISで定義して、全ての市販ソフトに
その採用を義務付けろと主張するわけだな? >159

超漢字マンセー

GB18030の影響でMeは発禁

>>157
2004で追加された以外の文字ではまだ問題が残ってる。
JISとUnicodeで包摂規準が明らかに矛盾してる文字の一覧とか
調べてみたいんだが面倒で挫折中。

>>160
波ダッシュはチルダではないとか意地を張ったりしないで
GBKをそのまんま追認した点とか。

>>165
> 意地を張ったりしないで

これってマジレス?

>>155
複雑なリガチャ付き文字はマウス操作やカーソルキー移動では１文字扱いですが、
デリート時は適度に分割されて扱われます。
Devanagariは理解できないので実装の正確さは判断できません。
OSX標準の状態でもDevanagariを扱うためのリソースは揃っていますので、実物で
確かめてみて下さい。

>>166
94x94の表の空き領域にも全部PUAへの写像を定義した点とか

Unicode 4.1でU+2B00とU+2B01、U+2B08とU+2B09のグリフが入れ替わった件について
http://www.unicode.org/versions/Unicode4.1.0/erratafixed.html

>>169を見て気づいた。
Code2001のU+1D301〜U+1D303の実装がおかしい。

実はU+1D300〜U+1D305の文字名で地と人が入れ替わってる件について

>>171
http://academy3.2ch.net/test/read.cgi/gengo/1040929046/170

>>172
つーかそれ書いたの漏れ。

U+3020のナンバー君がMeiryoでポストン君に変わってる件について
http://www.post.japanpost.jp/zipcode/zipmanual/image/052-1.jpg
これは包摂の範囲なんですか? U+3004のJISマークもそのうち変わりますか?
http://www.jisc.go.jp/newjis/newjismknews.htm
ちなみにユーロ記号はデザインが変わったとき新たにコードを割り当てられた。
まあUnicodeの欧米偏重は今に始まったことじゃないけど

この際だから>>169も解説しちゃおう
U+2B00〜U+2B0Dの矢印類はKPS 9566をソースに北朝鮮が追加提案した(N2056)。
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2056/J1n599903.pdf
このときの並び順は右上→左上の順だった。
すくなくともPDAM2まではその順だったのだが(N2395)、
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2395.pdf
FPDAM2になってなぜか突然グリフの順番が左上→右上に入れ替わった。
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2491.pdf
後から説明しているところによると(N2926 T.7とか)、Unicodeの他の矢印では
左上→右上だったからそれに合わせたかったのだろうとか。
でもFPDAM2で入れ替えたのはグリフだけで、名前を入れ替え忘れて(証拠は
N2491のチャートに残ってる)、そのままAmendment 2=Unicode 4.0 BMPに
なってしまった。
正式にAmendmentになってしまった以上もう名前は変えられないので
グリフを入れ替えることにした(N2926)。
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N2926.pdf
もうアホかと。

ユニコードHPが見られなくなっているんですが、
自分だけでしょうか･･･。

Unicode Home Page
http://www.unicode.org/

>>175
世界中であなただけです。

Ideographic Variation Sequencesキター
http://www.unicode.org/reports/tr37/tr37-1.html
# 例によって日本はシカトして事実上中国のSimplified Variant専用になる予感

>>175
一週間以上たってるが、俺も見れねぇ。

今見られるよ
ちなみに Announcements のトップは UCB の記事で 2005.05.06 の日付け

2005.05.09 だったorz

サロゲートペア、動作テスト中
呼吸深く𠹭囉仿謨(コロロホルム)や吸ひ入るる――北原白秋
呼吸深く��囉仿謨(コロロホルム)や吸ひ入るる――北原白秋

サロゲートペア対応
Netscape ○
Firefox ○
MS IE6 ×

>>182
IEはレジストリ弄る必要がある　ウチはIEで表示出来てるぞ

>>183
そうだったのか、知らなかった。と、調べてみたものの、よくわからなかった。
レジストリの弄り方、教えて下さいませ。

おっと、「non BMP対応」を説明した
http://charset.info/surrogate.html を発見。
ここの「レジストリを修正してフォントを指定する」をやったら
IEで無事に表示できました。

>>157 >>164
Unicode での JIS X 0213対応で問題として残っているのは、包摂規準以外にもありそう。
JIS X 0213 の文字の中には、完成形での収録が認められず、
「文字合成」で表現することになった文字が25文字ある。
http://charset.info/composite.html ここにある。
１文字だけでは表現することができない文字があるわけで、
表現するには合成可能な「結合文字」を使わなければならないんだが、
これを全部正しく処理できるシステムとフォントという条件は、かなり敷居が高い。
表示できても、「正規化」に対応していないと問題が起こるし。
今は厳しすぎかも。とりあえず Y.OzFont4 がベストなのかな。
Macならうまくいくか?

>>186
それは規格に適合してない処理系だから、
>>157>>164の話とはレベルが全然違うでしょ

そう。「規格に適合してない」という実装の問題が一つあって、
これは、きちんと実装されれば解決の話。確かにレベル違うな。

一方、U+309Aの合成可能な半濁点を使わなければ、鼻濁音等が表現できないんだが、
これは JIS X 0213にはなかったりするズレは、
やはり Unicodeと JIS X 0213の関係の問題でもあるんじゃないかと
思ったりするが、どんなもんなんでしょう。
JIS X 0213:2004対応を言うジャストシステムの平成書体で、
U+309A が合成可能になっていないのはバグだろうか。

ジャストシステムの書体使ってるけどU+309Aはちゃんと合成できるよ
(ただしJIS X 0213に規定されてる組み合わせだけ)
そんなことよりこの書体の問題はU+02EFとU+02F0に規格違反の文字が
入ってること

U+02EFとU+02F0 にこれがあるのは知らなかった。
Y.OzFont4 もここに同じグリフがあるんだけど、どうしてなんでしょう?
事情おしえて。

あれ。
U+02EF MODIFIER LETTER LOW DOWN ARROWHEAD
U+02F0 MODIFIER LETTER LOW UP ARROWHEAD
となってて、どちらも Introduced in Version: 4.0 とある。
規格になったんじゃないでしょか。

規格になっているのなら、
これとJIS X 0213の声調記号 1-11-69 (U+02E9 U+02E5) と 1-11-70 (U+02E5 U+02E9) が
文字合成でできたりすることとの関係は、どうなってんだろう。
同じなら、どっちが正規化形式なのか調べておこう。

>>190-192
U+02EF MODIFIER LETTER LOW DOWN ARROWHEAD
U+02F0 MODIFIER LETTER LOW UP ARROWHEAD
はUnicodeのチャート見れば分かるけど
http://www.unicode.org/charts/PDF/U02B0.pdf
JIS X 0213の1-11-69、1-11-70とはまったく違う文字。
じゃあ何でY.OzFont4やジャストシステムの平成書体がそこにグリフ入れてるかというと
たぶんJIS X 0213:2000のカッコ付きUCSがその値だったからだと思うけど
Unicode的には完璧に違反。

ちなみにカッコ付きUCSは単なる「参考」であって、
JIS X 0213:2000では1-11-69、1-11-70には対応するUCSは存在しないと
「規定」されていたので、いちおう違反はしていないという建前

なるほど。
合成の方の 1-11-69 (U+02E9 U+02E5) と 1-11-70 (U+02E5 U+02E9) とは
Unicode 的には無関係ということか。
こういうケースも、包摂範囲とは認められない違反となるのか。
でもって、これらのフォントでは、無関係だけどグリフ置換でこれを使うために、
あえてこの形で置いてあるわけかな。

いやこの場合まったく包摂の余地ないし。なんでもかんでも多重にグリフを付与できる
魔法の言葉じゃないですよ?

グリフ置換するためにコードを与える必要はない。
Y.OzFont4は独自仕様であえて与えている(技術的問題ではない)と作者が明言している。
ジャストシステムのほうは知らないけど。

そうなんだ、いろいろ教えてもらいました。ありがとう。

"こんにちは"とだけ書いたUTF-8なテキストファイルを作成するコンソールプログラムを作りたいのです。
環境はMSVC6.0でして、プリプロセッサ定義の_MBCSを消去して_UNICODEとUNICODEを追加し、リンクオプション・エントリポイントには「wmainCRTStartup」を設定しました。
結果は文字化けしたものが出力されてしまいます。何がいけないのかご教授願えますでしょうか。

#define tstring wstring
#define tofstream wofstream

// IMBUE_NULL_CODECVTマクロについては　ttp://www.codeproject.com/vcpp/stl/upgradingstlappstounicode.asp）
// からコピーしました。長いので略します。

void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
USES_CONVERSION;
tofstream zFileOut ;
IMBUE_NULL_CODECVT( zFileOut )
zFileOut.open( "C:\\temp\\test.txt", ios::out|ios::binary ) ;
zFileOut << _T("こんにちは");
}

>>198
そもそもそこのURLの中にUTF-8という言葉も出てこなし、UTF-16から8への変換をしているコードも見当たらない。
肝心のクラスもNullCodecvtっていかにも何もしなさそうな名前だ。（実際そうだし）

つまりそこのはASCII限定だろ。

>>199
すみません、UTF-8とUTF-16の違いもわかっていませんでした。
少し調べたのですが、UNICODEは文字セットの呼称、そのためのエンコード方式にUTF-8（可変マルチバイト）,
UTF-16（固定マルチバイト）などがある、ということでよいでしょうか。
また、リンク先の記事では、メモリ中のUNICODE（16ビット固定？）の文字をwfstreamでファイル出力すると
ASCII文字のコードが8ビットにされてしまうことが問題にされているのですね。
質問を変えさせてください。

(1)　"<?xml version="1.0" encoding="UTF-8"?>"といったようにUTF-8が指定されているXMLファイル
がありますが、これはそのファイル自体の文字コードがUTF-8でなければならないことを意味するのでしょうか。

(2) STLのfstreamでUTF-8形式のファイルを作成したいのですが以下のコードでは
うまく行きません。解決方法をご教授願えませんでしょうか。
（環境はMSVC6です。プリプロセッサで"_UNICODE"を定義したうえエントリポイントも
先の投稿の通り変更しています。）

void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
wofstream zFileOut ;
zFileOut.open( "C:\\temp\\test.txt", ios::out) ;
zFileOut << _T("こんにちは");}
}

(1) ファイルは別のエンコーディングでも構わない。
ただ、そのXMLデータの場合、処理系が解釈する場合はUTF-8と想定する。
処理系に渡す際、UTF-8エンコーディングに変換するのは、
XML処理系を含むシステムの責任。

例えば、JIS X 0208に含まれる文字しか使われていないとして、
ファイルはShift_JIS, EUC-JP, ISO-2022-JPエンコーディングで、
処理系に渡す際に(encoding="UTF-8"と宣言されているので)UTF-8に変換して
渡すシステムも一向に問題がない。

これは例えばhttpによるContent-Type: text/xml; charset=XXXも場合も同様。
http://www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing-with-ext-info

ドキュメントエンティティと外部表現の違い。
ドキュメントエンティティがどのような外部表現をもつかXMLの仕様が関与するところではない。

>>200
(1)XMLパーザにそのファイルをそのまま渡すのなら、UTF-8でなければ
ならない。201さんも書いているようにUTF-8でなくてもいい場合も
あるけど、ややこしいのでUTF-8にしときなさい。

(2)Windowsだったら
WideCharToMultiByte(CP_UTF8, 0, L"こんにちは", -1, dest, destlen, NULL, NULL);
てな感じでUTF-8にしてからofstream(wofstreamではない)に出せばいい
んじゃないかな。C++標準の範囲でUTF-8化できるかどうかは知らない。

上のURL本文のプログラムは、確かにUTF-8化ができる様子ないな。UTF-16だけでしょ。
あとのスレッド http://www.codeproject.com/vcpp/stl/upgradingstlappstounicode.asp#xx557556xx
の codecvt_UTF16_to_CESU8 あたりがUTF-8化のものなのか、試したら。
ここのCESU-8とか"UTF-8 light"って、どんなものかは知らないが。

CESU-8 で検索するといろいろ出るな。
UTF-8 ならsarrogate対応を4バイトでするところを、
3バイト×2 = 6バイトにしておく方法か。

CP_UTF8にはセキュリティホールがある罠

KPS9566を拡張すれば結構いい感じの文字コードになるかも。

KPS9566ってどっちかというと最悪に近いと思うけど
(将軍様専用ハングルの件は置いたとしても)

そうかもしれんな…

>>205
マジ？

詳しくはほぼ前スレに書いた

>>210
読んだ。なるほどと思った気がする。

アドバイスありがとうございます。
(1)については了解いたしました。ファイルはUTF-8のエンコーディングで行きたいと思います。
>>202
以下のようなコードを試して見ましたがやはり文字化けしたものが出力されます。
（結果のファイルをWinのノードパッドでUTF-8形式でオープンして確認しました。）

void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
ofstream zFileOut;
char dest[1024];
WideCharToMultiByte(CP_UTF8, 0, L"こんにちは", -1, dest, 1000, NULL, NULL);
zFileOut.open( "C:\\temp\\test.txt", ios::out ) ;
zFileOut << dest << endl;
}

デバッガではdestのアドレスに以下のようなコードが書き込まれていました。
E2 80 9A C2 B1 E2 80 9A C3 B1 E2 80 9A C3 89 E2 80 9A C2 BF E2 80 9A C3 8D 00
ちなみにC形式でのFILEを用いて出力してみましたが、まったく同じ結果が得られました。

>>203
こちらも試しましたがやはり文字化けしてしまいます。

なにかさらにヒントがあればご教授ください、、、。

そのソースは何エンコーディングでファイルに保存されているの?
WideCharToMultiByte()のWideCharっていうのは、そのエンコーディングのことなの?
# なおそのAPIのことは全然知りません。

>>212
こぴぺして試したらきちんとUTF-8で保存されていた。
ソースはSHIFT-JISで保存。

いろいろやって出来ればいいんだけど、
その場合、UTF-8にしたくて標準C++の範囲でよいなら、簡単な話としては、
ソースファイルをUTF-8で保存してコンパイルが通るか、という問題なんじゃないの。
MSVC Toolkit 2003(フリーのやつ)でやる限り、
入門的な標準C++プログラムをUTF-8(ただしBOM付き)で保存すれば、
> "こんにちは"とだけ書いたUTF-8なテキストファイルを作成するコンソールプログラム
は出来てしまうんだけどね。MSVC6.0は知らないけど。
gcc だと、BOMなしのUTF-8にすればコンパイルできるようだな。

>>214
そのコンパイラはShift_JISを理解して、
wchar_tなL"こんにちわ"の文字列リテラルを構成するんだね。

wchar_tはUCS-2なのかな?

>>212
たしかに、おかしいね。
L"こんにちは" が期待通りの値になってないのかな?

WideCharToMultiByte() というのは、名前は変だけど、
エンコーディング変換をするWin32APIを使っているんでなかったっけ。

>>212
俺はそのコードでうまくできたけど。

VC6とBCC5.5ではうまくいくことを確認した。
どちらもソースはSHIFT-JISで保存。

アメリカに在住しておりまして、返事が遅くなりすみません。

コードを試していただいた方々ありがとうございました。
大切なことを言い忘れていましたが、私の環境は英語版XP上の英語版MSVC6なんです。
XPのシステムロケールはJapaneseにしています。
（コントロールパネル->Regional and Language Options->Advancedタブ->Language for non-Unicode programsにJapaneseを指定）
ソースファイル自体はSHIFT_JISで保存されているように思われます。
（Meadowのモード行でSと表示されています。）

いっそのこと、自前で書いてしまうのはどうか？
UTF16とCESU-8の相互なら大した手間ではないと思う。

>>221
L"申し上げます"がメモリ内でどうなっているか、hex dumpするとどうなってる?

$ printf 申し上げます | iconv -f euc-jp -t shift_jis | hexdump -C
00000000 90 5c 82 b5 8f e3 82 b0 82 dc 82 b7 |.\..........|

つーわけで2byte目がbackslashなんだけど処理できている?
出来てないならコンパイラがShift_JISを扱えないね。

echo "こ"(cp932で"82 B1") | iconv -f cp1250 -t utf-8 | hex
E2 80 9A C2 B1
cp1251でもcp1252でも同じだからそういったヨーロッパ言語を使うようになってんじゃないの。
vcがosの言語の設定を見てないのか、設定方法が間違ってるか...。

>>222
私の技量ではちょっと遠慮したい感じです。

>>223,224
確かに224さんの"こ"のメモリダンプ結果が私がデバッガで見たものと同じですね。

> vcがosの言語の設定を見てないのか、設定方法が間違ってるか...。

みたいですね。XPのシステムロケール以外に設定する項目を知らないのですが、
いずれにしてもプログラム的には問題なさそうなので（みなさんの環境では動いているようですし）、
設定あたりの線で調べてみたいと思います。ありがとうございました。

日本版のVC++が特別版(Shift_JIS対応)ってことはないかな?

　wchar_t *p = L"申し上げます";
　for (char *q = (char *)p; *q != '\0'; q++) {
　 printf("%02x ", *q);
　}
printf("\n");

するとどうなるの?

英語版MSVCのソースエディタ内で「申し上げます」とタイプすると変換を確定した時点で
「\し繧ｰます」などと表示されてしまいます。Meadowで編集した上でセーブし（この際には一応
SHIFT_JISでセーブされているように見えます）、コンパイルすると

warning C4129: '?' : unrecognized character escape sequence

というwarningが出ます。warningをコピペしましたが'\202'は画面上では'・'のように見えます。
一応ビルドは終了するので実行するとコンソールには

ffffff90

と表示されました。何かおわかりになりますでしょうか。

>「\し繧ｰます」などと表示されてしまいます。Meadowで編集した上でセーブし（この際には一応

MSVCのエディタでは「申し上げます」が入力できないので、代わりにMeadowで編集した、という意味です。

>>227
そのコンパイラ/統合環境はShift_JIS対応じゃないです。
「申」の2byte目にあるbackslashを処理できてない。
m18nされてないのでしょう。

一応、L"文字列"を解釈しようとしているようですが。
とりあえずヘルプを読んだ方が良さそう。
実はwchar_t文字列リテラルに対応してないか、UTF-8辺りに固定なのか。

VCのコンパイラは日本語版でもShift_JISにL10Nされてるだけで、UTF-8すら使えない。
英語版だとどんなMBCSも使えないんでは。

日本版は過去の経緯という事情でShift_JISオンリーになっていても、
米版はUTF-8利用可能という可能性がないでもないが…さて

どのバージョンか忘れたけどutf-8なソースをコンパイルしようとすると
「utf-8には対応してません」的なメッセージを出してたときがあったな。
.NET Framework SDK v2.0のcl.exeを試してみたら
cp932のソースは問題なくコンパイルできた。
utf-8のソースはBOMなしだとcp932として扱うみたい(つまり文字コードの判定はしない)。
BOM付きだとutf-8として認識した。ただし、
char str[] = "こんにちは";
みたいな普通の文字列はcp932に変換された状態でstrに入る。
ワイド文字リテラル(L"こんにちは")は正しく変換された。

WindowsはそもそもUTF-8なMBCSはサポートしてないからな

cp65001とかあるし脈はあると思うけどね。実際にちょっとだけ機能するし。
sjis依存なコードがたくさんあるから実用できないだろうけど。

残念ながらシステムのコードページとしては利用できない。APIの仕様上不可能。
たとえばWM_IME_CHARは1文字が3バイト以上になることをまるっきり考慮してない。
(64ビットWindowsならWin16を捨てたから実装可能かも)
*.nlsは1文字2バイト以下のDBCS←→UCS-2の変換しかサポートできない構造だし。
GB18030も同様にシステムのコードページには設定できない。

今のVC++2003のサブセットにあたる VC++ Toolkit 2003はフリーダウンロードだから、
試す価値ある。英語版しかないから、日本でもこれ使ってるよ。
http://msdn.microsoft.com/visualc/vctoolkit2003/
これはUnicodeのソースファイルを解釈できる。
UTF-8 でも UTF-16 でもいい。ただし、BOMがないと判定に失敗して
コンパイルエラーになることが多い。
この場合、C++でやる限り、文字列リテラルやstringは、
実行ファイル内ではUTF-8になっている。
だから、ofstream のファイル出力もUTF-8になる。
cout出力からファイル名・パス名までUTF-8になってしまうので、注意いるが、
リダイレクトでUTF-8を得るには好都合な時もある。
ソースがUTF-16でも結果はUTF-8。ソースがShift_JISなら結果もShiff_JIS。

> 実行ファイル内ではUTF-8になっている。

"UTF-8の文字列リテラル"
L"UTF-8の文字列リテラル"

のどっちが?

これは標準C++と.NET Frameworkだけがサポートされるバージョンだから、それが前提で
"UTF-8の文字列リテラル"
の方

簡単なサンプルさらしちゃえば、これをUTF-8(BOM付き)かUTF-16で保存して実行すれば、
UTF-8(BOM付き)のテキストができる、ということで。
標準C++だけの VC++ Toolkit 2003では、文字列に L つけたらエラーになっちゃう。

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

int main() {
char bom[] = {0xEF, 0xBB, 0xBF}; // UTF-8のBOM
string s = "こんにちは。𠹭囉仿謨はnon-BMPテスト";
ofstream out("test.txt");
out.write(bom, 3);
out << s << endl;
}

>>238
要するに「何もしてない」って事だと思うが、
BOMがないとどうしてコンパイルエラーになるんだろう…
一応コードポイントの有効範囲くらいは調べているのだろうか。

シグニチャが無いと、Shift_JISだとしてリテラル解釈するから
文字列が不完全になってコンパイルエラーになるのよ。

シグニチャありだと一応そこら辺を処理しているように見えるけど、
実はLatinとして扱っているだけという可能性もある。

>>241
えーと、では、>>236にあるように英語版しかないけど、
そのコンパイラはソースのエンコーディングをShift_JISとして解釈するって事ですか?
OSのロケールにしたがって、l10n処理しているんでしょうか。

"申"とか大丈夫なのかな? (2byte目がbackslashだけど)

BOMがないとシステム設定のコードページを優先して、
Unicodeエンコーディングの判定はBOM付けてくれれば可能だから、
BOMなしのときは、Unicodeだとの判定は絶対確実でないとされないのかな、
とか推測してみたりする。

>>243
Windowsはメモ帳なんかもBOM付けるから、その仕様だと自然な感じですね。

VisualStudio 2003付属のCL.exeは、シグネチャ付きUTF-8のソースなら
MBCS文字列もワイド指定付き文字列も、ちゃんと処理しているみたいよん。

>>239 のサンプルコードは、Cygwin版のgcc や MinGW でも、
BOM無しUTF-8で保存してコンパイルできた。結果は同じ。
こちらは、どうエンコーディング判定してるのかな。

gccのmbchar拡張がなければ、{
　gccはBOMさえ外してあればスルーでしょ。要するに判定なし。
　これはどの環境でも同じ。
}

そうでしたか。判定しなくていい仕様なのか。

マイクロソフトは「Windows Vista」で日本語フォント環境を一新。
JIS X 0213:2004規格に対応するとともに、
画面上での可読性を大幅に向上させるまったく新しいデザインのフォント（フォント名：メイリオ）
開発を開発中と発表。
ttp://www.microsoft.com/japan/presspass/detail.aspx?newsid=2353
ttp://pc.watch.impress.co.jp/docs/2005/0729/ms.htm
ttp://www.itmedia.co.jp/news/articles/0507/29/news049.html

【社会】"混乱大丈夫？" 次期OSウィンドウズ・ビスタで漢字１５０字形を変更
ttp://www.yomiuri.co.jp/national/culture/news/20050729i306.htm
http://news19.2ch.net/test/read.cgi/newsplus/1122621294/l50

Windows Vista 日本語フォント環境を一新
http://pc8.2ch.net/test/read.cgi/pcnews/1122649116/l50

>>249

Visa、 XP以前の混在企業システム環境だと、オワットル。

＞開発を開発中

＞Visa

よろこんでコピペする前に>>122-あたりから嫁
さんざん既出だし前の字体が使えなくなるなんてこともない

MACが無視されているのはなぜ？

>>253
合成対応やcomplex script対応やJIS X 0213対応や字形の沢山入ったフォント
やらOSXでは何年も前に実装済みなのであまり話題がありません。

Vista beta1を調べてみた結果
・Meiryoは>>125とか>>139な感じ
・新ＭＳ ゴシック/ＭＳ 明朝はグリフ自体が入れ替えられてて
　OpenType Featureはccmpとvertしかない
　(ほぼ一太郎の2004JISフォントと同等)
・Uniscribeに
　ScriptGetFontAlternateGlyphs
　ScriptGetFontFeatureTags
　ScriptGetFontLanguageTags
　ScriptGetFontScriptTags
　ScriptItemizeOpenType
　ScriptPlaceOpenType
　ScriptPositionSingleGlyph
　ScriptShapeOpenType
　ScriptSubstituteSingleGlyph
みたいなAPIが追加されていて、Win32からでも字形は制御できるらしい

Vistaのメモ帳で「葛飾区」と打って、フォントをMeiryoに切り替えるだけで
文字化けするわけだがいいのかこれで?

>>256
同じ文字コードに、フォントによって違う字形が割り当てられているのはいやだ。
特に、住所管理とか人名管理とかそういうシステムではどうすんだ。
葛飾区役所のシステム担当とか終わりそうだ。

葛飾区の役人は今やってる方法のまま暮らしていれば問題ない。

>>258
中途半端にえらい役所のやつが、VistaのＰＣを勝手に導入して
「こらー、これで俺のところの区の字がでねーぞ、なんとかしろー」
とかいいそうだ。

>同じ文字コードに、フォントによって違う字形が割り当てられている

それは当たり前なのでは?

717：login:Penguin：2005/07/30(土) 10:41:03 ID:Hd+4jW+B
>>716
CP932の定義が変わって、
CP932とUnicodeのマッピングが変わるわけでしょ?
とりあえず>>711のPDFくらい読めよ。

http://internet.watch.impress.co.jp/www/column/ogata/sp13.htm
でも概略は理解できるよ。

JIS X 0208の1978, 1983, 1997が同じ文字集合を規定している
というセンスだと理解不可能。

> 特に、住所管理とか人名管理とかそういうシステムではどうすんだ。
そんなシステムでフォントすら規定してないほうがどうかと思うが…

>>261
リンク元くらい書いてほしいなあ。login:Penguinで分かったけど
http://pc8.2ch.net/test/read.cgi/linux/1003159137/717
> CP932とUnicodeのマッピングが変わるわけでしょ?
変わんねーよ(Shift_JISではJIS X 0213の2面の漢字とか使えない)
PDFのどこを読んだらそういう結論に到達するのやら
つーか「考え方」の5-(7)ってどれだよ

>>259
逆だろ? 葛飾区は今まで出せなかった字がVistaでは出るようになる。
困るのは葛城市。しかもJIS字体にした理由が「PCで出しやすいように」。
合併したのは2004年。もうアホかと。

文字集合が違うんだから同じコードで字形が違っても全然不思議じゃない。

REVERSE SOLIDUSに円記号が割り当たってる方がよほど奇妙なんだけど
>>257はそっちは問題にせんの?

MeiryoのU+005CはちゃんとREVERSE SOLIDUSの字形になってるけど
システムの言語を日本語にするとU+005Cでわざわざ円記号が表示されるように
何か特別な細工をしてる模様。
円記号以外の英数字はClearTypeが掛かってるのでMS UI Gothicじゃないのは確実。
そこまでやりますか

なぜか文字集合の違いにしたがってる奴がいるようだが
同じJIS X 0208:1997やJIS X 0213:2004で字形が違ってたってぜんぜん不思議
じゃないのだが。喪前らこそ規格票読んでるのか?
参考:
http://toyohira.asablo.jp/blog/2005/07/30/38169

いちおう漏れの疑問の意図を説明しとくと、
規格に適合してるか否かを聞きたかったんじゃなくて(適合するのは分かってる)
新ＭＳ ゴシックとMeiryoはどちらも同じシステム上に標準で存在する
2004JIS対応を主張するフォントなのに、切り替えただけで文字化けが発生する
仕様なわけだが(規格上はもちろん問題ないが)、
MicrosoftはVistaに標準で存在する日本語フォントだけでもなんとかする気は
なかったのか? ってことなんだが。
文字化けが発生する「仕様」であることを世間に思い知らせるためあえてこう
したのかもしれんが、互換性を無視してそこまでdrasticな考えができるなら
IEはとっくの昔にCSS完全準拠になってるはずだし。

>>268
まだVistaがβだからであって、正式版までには解消されている、って期待はないの？

>>269
マジでそう期待したい。
ちなみに正式版ではどう解消されてる(する余地がある)と思う?

表外漢字字体表の字体に変更すると、
JIS X 0213と矛盾が生じる文字についてはどうなっているの?

>>271
その28文字については、表外漢字字体表の字体変更しないんじゃない?
当たり前だけど。

http://www.yomiuri.co.jp/national/culture/news/20050729i306.htm
にもある168文字の内訳ってどこかに書いてある?

補助漢字を無視したいところだけど、
補助漢字はUnicodeに入っているしねー。

>>263
> つーか「考え方」の5-(7)ってどれだよ

http://www.jsa.or.jp/domestic/instac/h13reports/JCSmain_Web.pdf

じゃないかな。(読んだことがある人ならすぐピンと来るはず)

http://internet.watch.impress.co.jp/www/column/ogata/sp13.htm
http://internet.watch.impress.co.jp/www/column/ogata/sp13/hyou2.htm
に、その要約があるけど、(調査報告には例示字体の表もある)
その9つのケースについて、現状のVista&Meiryoでどうなっているか、
誰かまとめてくれる人いませんかね? (僕は残念ながら持ってないです…)

>>274
＞現状のVista&Meiryo

要はOpenTypeの'jp04'グリフってことじゃねえの？
そうであれば、基本はJIS04が変更したとおり。
ただし「微細な字形差」に関しては無視しているものもある。

>>272
> 168文字の内訳
JIS X 0213:2004に関する経済産業省の報道発表
ttp://www.jisc.go.jp/newstopics/2005/040220kanjicode.pdf

>>275
なんとMeiryoには'jp04' featureがない('nlck'はある)。AJ1-5相当だから
当然かもしれんが。
正式版までにサポートされるのかサードパーティー製のAJ1-6フォントを
インストールしたときに備えてAPIの口のみ用意してるのかは知らん

>>271
別区点に追加されたほうの面区点を使えってこと

> じゃないかな。(読んだことがある人ならすぐピンと来るはず)
5-(7)って数字の根拠が分からない。そんな章番号とかはないみたいだし
> その9つのケースについて、現状のVista&Meiryoでどうなっているか、
Meiryoは単なるAJ1-5相当のOpenTypeフォント(要するにデフォルト字形は90JIS)。
だから>>256のような「文字化け」が起きる

> 5-(7)
ようやく分かった。2.1.5 (7)のUCS互換漢字10文字のことか。
当然2004JIS・ISO/IEC 10646:2003がやったとおりのことをやって対応
(字形変更ではなく対応するUCS符号位置のグリフを追加実装)。ヒラギノなんかと一緒。

Shift_JISのtext/plainやtext/htmlはどう扱うの? > Vista
(CSVなど全般的に)

>>280でいうと、追加した文字の方になったわけ?

>>281
CP932のマッピングに一切変更はない。
UCSのレパートリとしてしかサポートしないとずっと言い続けてた通り

もちろん「葛」みたいに字形が変わった字は結果的にShift_JISでも変わるけど、
それはたまたまで印刷標準字体をShift_JISで完全にサポートする気ははじめから
ないということ。

メーラーを作っているのですが、受信したメールが正しく表示されません。
JIS→Shift_JISの変換を勉強のためにも自力で変換したいのですが、
どう変換していいのか分かりません。
JISの文字コードをShift_JISに変換するときのアルゴリズムのヒントを教えていただけませんでしょうか。
1byteずつ読み込んでいって変換していかなきゃいけないというところまでは分かります。

勉強のために自力で変換したいという人が
検索もせずに質問するとはこれいかに

そのくらい調べられない奴には絶対にメーラーなんぞ作って欲しくは無い罠。

>>284
マジでやめてくれ。

言語は何よ?
>>8でどうなのよ。

perlならEncode.pmな。

Shift_JISのままBase64でエンコードしたほうが被害は少なそうだ。

iso-2022-jpと書けない時点で終どうしようもない。

＞勉強のために自力で変換したいという人が
＞検索もせずに質問するとはこれいかに
ここ一週間調べたのですが、今ひとつ理解できるものが見つからないんです。
かなり運が悪いようです。

＞そのくらい調べられない奴には絶対にメーラーなんぞ作って欲しくは無い罠。
メーラーが初めてなだけでネットワーク関係のプログラミング経験は豊富です。
バイトですが十数件のCGIも手がけました。
フリーで配布しているものもあり、結構多くの方に利用していただいています。
CGIはPerlで組んでいて、jcode.plを使っていました。

今回はC++で作っています。

とりあえず
つ libiconv

……てゆーか、jcode.pl読めばわかるんジャマイカ?

CGIってネットワークプログラミングに含まれていたのか。

この板の「ネットワークプログラミング」スレでCGIなんて書き込んだら
鼻で笑われるだけだけどな。

>>284
バベルじゃダメ？

> フリーで配布しているものもあり、結構多くの方に利用していただいています。 

フリーCGIで日本語(もちろん文字コードでんでんで)の扱いがクソレベルな物ばかり掴まされている漏れなので、
よろしければお前のCGIの配布サイトを教えてくだちい。

> かなり運が悪いようです。

悪いのは運ではなくて頭

>>284
inがJIS文字列で処理結果がshiftjis文字列のはず。バグあるはず。
そもそもcharがunsignedではない環境ではあぼーんする恐れあり。
std::string jis2sjis(const std::string& in) {
    bool is_ascii = true;
    std::string::const_iterator begin = in.begin(), end = in.end();
    std::string out;
    while (begin != end) {
        if (*begin == 0x1B) {
            if (*(begin + 1) == 0x24 && *(begin + 2) == 0x42) is_ascii = false;
            else if (*(begin + 1) == 0x28 && *(begin + 2) == 0x42) is_ascii = true;
            begin += 3;
            continue;
        }
        if (is_ascii) out.push_back(char(*begin));
        else {
            unsigned char hib = unsigned char(*begin), lob = unsigned char(*++begin);
            lob += (hib & 1) ? 0x1f : 0x7d;
            if (lob >= 0x7f) ++lob;
            hib = unsigned char(((hib - 0x21) >> 1) + 0x81);
            if (hib > 0x9f) hib += 0x40;
            out.push_back(char(hib));
            out.push_back(char(lob));
        }
        ++begin;
    }
    return out;
}

馬鹿は出てくるなよ…

>>291
完全に経験不足(ﾜﾗ

CJKV日中韓越情報処理
http://www.amazon.co.jp/exec/obidos/ASIN/4873111080/
Unicode標準入門
http://www.amazon.co.jp/exec/obidos/ASIN/4798100307/
国際化と日本語処理
http://www.amazon.co.jp/exec/obidos/ASIN/4756134815/

最後はJavaだけど、Unicode経由する場合のマッピング問題の理解にはよいでしょう。

Vista beta1の文字コード表がExtBに未対応なのを見ると確かにかなり暫定的なもの
である可能性は高そうだ
XPからそのまま移植しただけみたいな

>>284
もし環境が Windows ならば、
MultiByteToWideChar -> WideCharToMultiByte と呼び出す。
IE5以上が入っていれば、
IMultiLanguage2 を取得して、ConvertString メソッドを呼び出す。
Windows 以外なら、
iconv とか、ICU とか、バベルとかその辺を使う。

> 勉強のためにも自力で変換したい

MultiByteToWideChar がISO-2022-JPを変換できるのはWin2k以降で
IE5より条件厳しいし。

文字コード支離滅裂なのって日本だけなの？

日本の文字コード体系を真似た中台韓も同様の状況じゃなかったっけ？

ベトナムも。

それからEU内はISO-8859-*で扱おうとするとやっかい。
隣国間のやりとりで結構問題になった。
島国日本に比べるとずっと近くて交流が多いから。

まあ日本語は他の2byte圏より多少歴史がある分、面倒なしがらみも多いわけだが

>>309
他の2byte文字を知っての言葉か？

>>310
他の2byte文字とやらの説明よろ

中国は国家権力でGB18030を強制できるので楽と言えば楽だよね。

>>311
質問を質問で返すなよ

>>312
311!=310なんで別に返してるわけじゃないよ。説明よろ。

何が聞きたいんだ

他の2byte文字圏が日本語に負けず劣らず面倒であることの証明だろ

他の2byte文字って何？

だからそれを説明しろといってるんだろ

スネークマンショーのつもりかよ

だ〜れ〜？

CJKVだろ
ttp://www.amazon.co.jp/exec/obidos/ASIN/4873111080
でも読め

ここでいいのかなぁ…Windowsで文字コードの判定に
IMultiLanguage2::DetectInputCodepageを使ってみました。Googleのページ
(UTF-8)すらまともに判定できていませんが、精度はこんなものでしょうか？

質問なので上げときます。

試さずに言うけど、googleのトップページなんて
文字量が少ないんだから判定しにくいのも当然なのでは？

文字コードの範囲限定してないし…

トルコ語(Windows)と判定されました。

>>324
指定方法ってあるんでしょうか？

せっかくメタタグあるんだから、MLDETECTCP_HTML指定してやれば
まともに判断してくれまいか。

つうか、Win32Apiスレの話だよな、こんなの。

どうするよ「表」

文字コードが何種できてもいいけどさ
5c入るコードに文字振るのやめない？
どんどん増えてく

>>326
読み込むのがHTMLとは限らないんですよ。次のページのコードも
参考にしましたが…
DOBON.NET .NET Tips - 文字コードを判別する
ttp://dobon.net/vb/dotnet/string/detectcode.html

あきらめの悪い奴だな

>>329
>>328のサイトので我慢します。

>>330
C++でもいいんならバベルはどうだ？
サンプリングしたデータを下にスコアリングを行うからかなりの精度で判別するぞ。

>>331
ありがとうございます、Babelの存在を忘れていました。一応C♯とC++を
考えているので、考慮に入れたいと思います。

>>327
意味不明

>>333
もちろん意味わかっててそう言ってるんだよな。

0x22, 0x27, 0x2Fとかきりがないけどな。
いまやUTF-8の時代だし。

>>328
このページの判定ルーチンは、一バイト目に0のあるバイナリファイルを食わせると、
配列の外にアクセスして例外が起きそうな気が。

まあ.NETならそれを足がかりにバッファオーバーフロー起こして攻略とかできないから

>>335
だいたいそれならISO-2022-JPを真っ先に滅ぼさなきゃならない
(実際日本語を想定してないメールゲートウェイでトラブルの元になってる)
ことには気付いてるんだろうかね

>>338
> (実際日本語を想定してないメールゲートウェイでトラブルの元になってる)

(　ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　　_, ._
（；ﾟ Дﾟ）

ESCを捨てるゲートウェイの話とか聞いたことない?

ISO-2022-JP の問題なら今は ESC よりも瘢雹だろう。

amp;(瘢雹)は挟まるだけだからまだマシ
<→&lt;や>→&gt;はその後が全部化ける

utf-8の日本語
すでに複数存在するって本当？

>>338
いつの話だよ。
MIMEエンコードもしてないメールなの?

Structual fieldなら問題外だし。

瘢雹でぐぐればそういうメールアーカイブがバリバリ現役なのは分かると思いますが。
いくら綺麗事を並べたところでascii圏の認識なんてそんなもん。

メールアーカイブなんぞメールのトラブルとは何の関係もないやんけ

>>343
MicrosoftとAppleとLinux(つーかglibc?)とJavaとJISで全部ちょこっとづつ違うんじゃなかったっけ。
「〜」等の記号のコードポイントが違ったり正規化表現が違ったり。(正規化はUnicodeの範疇だけど)

>>346
メールのトラブルじゃなきゃ何が起きてもいいわけじゃないし

>>347
それはUTF-8ではなくShift_JISの方
そして違うのはコードポイントというかUCSへのマッピング

>>349
でも全部UTF-8で処理するCGI作ってWinとMacからそれぞれ「スケジュール2005年4月〜9月」などと入力してPOSTしたら、「〜」が異なるコードポイントでやってきますですよ?

そもそもWinとMacでは同じに見えても違う波線だから当然と言えば当然。

>>350
だからUTF-8の方は一種類なんだって。
1. あるUTF-8にはＸＸＸという文字があるけど違うUTF-8にはない、みたいなことはない。
2. あるUTF-8のYYYというコードポイントの文字はZZZだけど違うUTF-8では別の文字、みたいなこともない。

でもShift_JISでは、1. も2. も現実に起こってるの。
で、そのいろいろ微妙に違うShift_JIS達をユニコードに変換するときに、それぞれがいろいろ微妙に違う変換テーブルを使ってるのが原因。
UTF-8側の問題じゃないの。OK?

原規格との変換テーブルを規定しないUnicode側の問題だろ。

むかしは規定してたけどな。
きっと管理しきれなくなってやめたんだろうなぁ……。
ちゃんとやろうとするなら、SJISだけでいくつの方言を面倒みないといけないやら。

> でも全部UTF-8で処理するCGI作って

ていうかユニコード側が規定してもベンダが従うとは限らないし、
ベンダはマッピングを変更したり増やしたりもするだろうし、
ユニコード側にそれの管理をさせるのは無茶だろ。

混乱の元だってのは確かにその通りかもしれないけど、他にどうしろと？

よしUTF-128ぐらいで手を打とうじゃないか
言語問わず、今現在使われてる部分は意地でも文字振りません

Unicodeがマッピング・テーブルを公開していた頃も
ベンダはそれに従ってなかったし。

>>357
UTF-8でも、36bitコードまでリニアな拡張で扱えるが。

それはUTF-8ではない。

＞36bitコード
(　´д)ﾋｿ(´д｀)ﾋｿ(д｀　)

>>360
だから、「UTF-8の *リニアな拡張* 」だって言ってんだろ？
先頭バイトの上位ビットに7個1が並んでいたら、↓ 36bitになるだろうが。

11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

UTF-8 符号化では 0xfe と 0xff のバイトは絶対に使用しない。

拡張って言葉の意味が分からないの?

ちなみに0xfeと0xffを使わない理由はUTF-16のBOMが100%判別できるようにするためだな

>>351 >>352
ええと、理屈はわかるんですが、現実として、WinとMacとLinuxの混在環境
で全部UTF-8に統一しても、人間から見たら「同じ」と認識されるはずの
ものが異なるバイトパターンを構成するために、システム的には「同じ」
にならないと言う問題があって、これを解決するためには、どこかで
UTF-8 to UTF-8変換をする必要があるのではないでしょうか。

この状況を称して「UTF-8の日本語はすでに複数存在する」と言っても
過言ではない、と思うんですけれども。

> UTF-8 to UTF-8
お前が言わんとすることに似たようなことは既に存在する。
http://www.google.co.jp/search?hl=ja&c2coff=1&q=Unicode+%E6%AD%A3%E8%A6%8F%E5%8C%96&lr=lang_ja

>>366
UTF-8は文字エンコードの規格。
見た目は同じで違う文字、というのは文字セットの問題。
だから、UTF-8云々の議論はかみ合わない。

それに、バイトパターンが一致しないのは、BOM有無とか改行の問題じゃないの？
あるいは、UTF-8なら本来2バイトで表せる文字を3バイトで記録するような誤った実装の
アプリを使っているとか、サロゲートペアをそのまま2文字で扱うエラーとか…

>>367
ぅぃ。問題自体が今さらなのは承知しております。

が、その対策が、この関数／メソッドを呼べばOK!にはなってなくて、
未だにアプリケーション毎の個別対応に依存しているようにしか
見えないのはどうしたものかと。

Javaの世界ですら、10年前から既知の問題なのにどこにも(ベンダ依存
マッピング問題を含む)統一されたフレームワークが見あたりません……。

私が知らないだけだったら、是非教えてください。

>>368
厳密にはそうなんですが、現状は、
Conten-Type: text/html; charset="UTF-8"
や
export LANG=ja_JP.UTF-8
のように、文字セットの情報は交換してないので、事実上UTF-8というだけで
文字セットまで含んでしまってます。せめてUTF-8-msとかUTF-8-appleのよう
に区別してくれたら〜(;_;)

ちなみにバイトパターンについては、「スケジュール4月〜9月」という文字列
を、Windowsのメモ帳とMac OS Xのテキストエディットで入力、エンコーディ
ングはどちらもUTF-8で保存すると、以下のようになります。
od -j 3 -tx1 win.txt (BOMが入るので頭3バイト切り捨ててます)
0000003 e3 82 b9 e3 82 b1 e3 82 b8 e3 83 a5 e3 83 bc e3
0000023 83 ab 34 e6 9c 88【ef bd 9e】39 e6 9c 88
od -tx1 mac.txt
0000000 e3 82 b9 e3 82 b1 e3 82 b8 e3 83 a5 e3 83 bc e3
0000020 83 ab 34 e6 9c 88【e3 80 9c】39 e6 9c 88
おや、MacでもNFCなのか。WebDAVのリクエストはNFDで投げてくるので、
てっきりNFDになるのかと……。

MACのwebdavリクエストってかなり行儀悪いよねえ

俺も複数あるようにとれちゃうけど、
とにかくあれだUTF-8って統括してるってのりじゃないんだ

マッピング誰がつけたの？

>>370
厳密な指定が無い限りユーザが何を入力するかは好み(運)次第でしょ。
MacOSXのinput methodだとU+301C WAVE DASHの方が入力し易いけど、
U+FF5E FULLWIDTH TILDEも入力できるし、WindowsのIMEで「から」を
入力するとU+301C WAVE DASHになるみたいだし。

MacOSXではHFS+との互換性や同じファイル名を作らせないためにVFSは
NFDにnormalizeしてるけど、NFC/NFD/複雑な合成文字のいずれも扱えます。
http://developer.apple.com/ja/qa/qa2001/qa1173.html

>>370
あほ? (w

>>370
だからUTF-8の問題ではないだから、UTF-8-msとかUTF-8-appleとかを作って解決すべき問題ではないの。

http://euc.jp/i18n/ucsnote.ja.html
これだろ?

UnicodeじゃなくてJIS X 0208に限っても、
−〜ー─と利用者が入力し間違う余地はある。

これを文字コード(のエンコーディング)の問題だと思う奴は馬鹿じゃないの?

>>370
これ読んで出直し。
http://www.unicode.org/reports/tr17/

Content-Typeがutf-8で萎えた、こだわって欲しかった

こんなんに任せてっからだめなんだよ！そのうちUとuの変換表作り始めるぜ

>>374
GNU libiconvはNFDが扱えないため、DarwinのlibiconvはUTF-8にだけNFCへの
normalizerを追加してUTF-8-MACと称してます。
Darwin的にはUTF-8の問題ではない物をUTF-8-APPLEを作って解決するのはありw

そもそもAppleのNFDって互換漢字をNormalizeしないよな
されたらそれはそれで困るけど。

↑はHFS+に格納する場合

>>380
詳しく

>>381
http://developer.apple.com/ja/technotes/tn1150.html#UnicodeSubtleties

規格上は同一の文字コードでも出力時の選択に応じて
便宜上別の名前をつけるのはよくあることだべ
エンディアンの違いでx-utf-16le-bomとx-utf-16be-bomとか
使用するエスケープシーケンスの違いでiso-2022-jp-3とiso-2022-jp-3-strictとか

>>383
IANAにもUTF-16LEとかあるのでその辺は承知してます。
それらの場合、UTF-16やISO-2022に直結した問題なので説得力があるのですが、UTF-8-MAC
はSambaが動かないバグに泥縄で対処するために作った物の様です。
UTF-8-DARWIN-VFSとでも名付けるのが機能や泥縄感wを表して良いと思うのですが、
UTF-8-MACを使ったためにこのスレでも見られる変な誤解が広まっています。

Mac OS Xは、HFS+のドライバ@Darwinや
CarbonのFrameworkに個別の変換実装を持っていてアホ丸出し。

>>384
UTF-16LEはBOM禁止でUTF-16とは明確に違うべ

MSGOTHICの文字情報を
euc-jpのマッピングに揃えたら
euc見れる？？サイズかわって無理？

>>387
何が知りたいのかよくわからんが、

「MS Gothic フォント内のグリフの並び方をEUC-JPの並びに変えたら、
Win32 API の文字表示APIでシフトJIS文字列を渡すところでEUC-JP文字
列を渡して画面に表示できるようになるか？」

という意味？

相手にしないのが吉

>388
ですです！
フォントについて知らな過ぎのくせにイメージだけで喋っちゃってました。
グリフって？ってとこから構築してました
伝わってよかったありがとう

>389
ひどい！

shiftjisもeucもアスキーよけた同じような感じだと思ってたんだけど
結論は無理っぽい？？

これ半角カナ全滅しますね、フォントだけで吸収できないもんですか
ハイもう喋りません、ごめんなさい

半角カナ ｲﾗﾈ

392 名前：デフォルトの名無しさん[sage] 投稿日：2005/09/13(火) 09:20:39
　　半角カナ ｲﾗﾈ

393 Name： デフォルトの名無しさん [sage] Date： 2005/09/13(火) 09:47:44 ID: Be:
392 名前：デフォルトの名無しさん[sage] 投稿日：2005/09/13(火) 09:20:39
　　半角カナ ｲﾗﾈ

質問です。
WindowsAPIもしくは、C言語関数で
ISO-8859-*からUNICODEへ変換する関数はありますか？
教えて君で申し訳ないですが、いくら調べても見つからないので、
書き込ませてもらいました。
ご存じでしたらお願いします。

>>395
> 教えて君で申し訳ないですが、いくら調べても見つからないので、

このスレくらい読め。

iconv <- unix
MultiByteToWideChar <- win32api
# MultiByteToWideChar, 新しいMSDNのページだと検索に引っかかってこない……。

半角に包まれたcursesダイアログが目に染みるあなた
起動時のくるくるインジケータ※に￥が混ざりどっち回転なのかわからなくなるとお悩みの方！
コピーライトゥ にせんご、と読んでる天然も共に戦いましょう！
今こそ立ち上がるのです！！！

半角って難ですか?

>>397
MultiByteToWideCharで可能と言うことでしょうか？
因みにmbstowcsでも可能でしょうか？
あと、対象OSはWindowsCEなのですが、
第1引き数のCP_UTF7・8はCEでサポートされないとMSDNに書いてあるのですが、
ここには何をしていすれば良いですか？
全くの素人で申し訳ないですが、宜しくお願いします。

>>400
最初の引数はIsValidCodePage()の引数がそのまま使える。
IsValidCodePage()の項目にはコードページの一覧がある。

>>400
第一引数はマルチバイト文字列に関するコードページなので、
ISO-8859-*に対応するコードページを指定してやればいい。
変換後はUCS-2かUTF-16固定のはず。

>>401-402
ありがとうございます。
助かりました。

太玄経(U+1D300〜)の文字名間違い指摘キター

UTF-8な以下のXMLファイルを（notepadで作成し、UTF-8でセーブしました）、

<?xml version="1.0" encoding="UTF-8"?>
<RootNode><ChildNode value="てすと" /></RootNode>

以下のMSXMLを使ったプログラムで読み込もうとしています。

#import "msxml4.dll"
using namespace MSXML2;
int main()
{
CoInitialize(0);
{
IXMLDOMDocumentPtr pzDomDoc( "MSXML.DOMDocument" );
pzDomDoc->validateOnParse = VARIANT_FALSE;
pzDomDoc->load( "C:\\temp\\japanese_text.xml" );
IXMLDOMElementPtr pzDomRoot = pzDomDoc->documentElement;
IXMLDOMElementPtr pzDomNode = pzDomRoot->firstChild;
/*-->*/_variant_t varAttr(pzDomNode->getAttribute( "value" ));
}
CoUninitialize();
return 0;
}

"-->"の行のvarAttrに空文字が帰ってきてしまいます。環境はVisualC++6.0英語版です。
原因がわかる方いらっしゃいますでしょうか。

（XML関連のスレはあまり人がいらっしゃらないような気がしたので敢えてここで質問させていただきましたが
もしスレ違いでしたらすみません、、、。）

ちなみに>>405のコードの中で
pzDomDoc->save( "C:\\temp\\japanese_text_out.xml" );
としてファイルにセーブしなおしてみたところ日本語の属性がきちんと元のままセーブされていました。属性を取り出すところで何かが起こってるのだと思うのですが、、、。
言い忘れましたがOSは"英語版"WindowsXP(SP1)です。VC++も含めて英語版の環境であることが問題なのでしょうか？

とりあえずBSTRはwcharらしいから
リテラルにL付けてみたら？

すみません、私の勘違いだったようです。デバッガでは>>405のコードのvarAttrの値が
varAttr{"" VT_BSTR}
と表示されるので空文字が返ってきているのだと思ってしまっていました。文字列はちゃんと返されているようです。
一人でスレを汚してすみませんでした！

XMLのｽﾚへ帰れ。原因は知ってるがここでは教えてやらん。
ただ、ヒントだけは出しておく pzDomRoot != "/RootNode"

>>410
カコワルイ

我々も文字コードで天下を統一するぞ！！！！


UTF-8で天下統一だ！！！

UTF-8は尾張の織田信長だ！！！！

UTF-8でなくて、Unicodeと言っちゃダメなのか? と突っ込んでみる。

413＝明智光秀

>>413
UTF-8はUnicodeの一形態なんだから、お前の文は意味がない。

UTF-7も仲間に入れてよ〜、ということだろう。

UTF-7イラネ
RFCも更新されずに見捨てられてるし

>>416
いやいや、UTF-32も仲間に入れてよ〜、ということだな。

UCS-2＝松平家康
UCS-4＝羽柴秀吉
UTF-7＝明智光秀
UTF-8＝織田信長
UTF-16＝徳川家康
UTF-32＝豊臣秀吉

UTF-8がUTF-7にヌッコロされるという図は想像出来んのだが

ISO-2022 毛利

Shift_JIS＝武田信玄
EUC-JP＝上杉謙信

>シフトJISは共通基盤となっている。この共通基盤を維持することが、
>言語の共通性を維持するために、とても大事なのだ。
ttp://openblog.seesaa.net/article/6106946.html#comment

16秒遅かったか。

>>423
南堂、あいかわらずだなヽ( ´ー`)ノ

「シフトJISが共通基盤」って鎖国でもするつもりか？
内部コードSJIS対応パッチなんてどこもマージしてくれないぞ。
Citrus Projectでもない限り。

>>423
> 私の旧型パソコン（Windows98）は、対応できなかった。google に接続するたびに、異常を起こした。
> たいていは、マシンがビジー状態になってストップするだけであり、再起動すれば直った。しかし、
> あるときついに、ビジー状態のあげく、CPUが過熱して、パソコンが壊れてしまった。
>
> 　つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> 　つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> 　つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> 　つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> 　つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。

お茶吹いたｗ

>>426
それも日本のプロジェクトだな。

>>427
UTF-8って怖いね(w

UTF-8のせいでうちのおじいちゃんは…

巷で「UTF-8最強！！！！」と叫ぶ輩を見掛けるのには
こんな理由があったのか。

　　　　　|;:;:;:;|　　　　　　　　　　　　　　　　　　ヾ;:;:;:|
　　　　　|;:;:;:;|　　　 ,,,;;:iii;;;;;　　　　,.-＝＝--､.　`!;:;|ヽ
　　　　　 〉;:;:|　,.-''"￣￣￣`ヽ⌒|　　--｡､-､ ヽ-`'　|　　　　
　　　　　i　`u　i　-‐'"ヾ'"　　::　::!　　　　　　:　|　　ノ　　これはUTF-8の独裁政治だ！
　　　　　 i　　　|　　　　　　 ノ　　 ヾ､＿＿＿ノ　　::|　　　　　日本の未来が不安。
　　　　　　|　|　 ヽ､＿＿,.-i　　　　　i　､　　　　:　　:|　　
　　　　　　 | |　　:　　　: '" `〜ー〜'"　ヽ　:　:　　 ::|　

皆で文字化け検査テスト用に最適な文字列を考えようぜ！！？
とりあえずざっくりこんな感じでどう？

ｾﾞﾝｶｸ&ハンカク表う〜。

>>427
PCが壊れた原因をUTF-8のせいにするとは
とんだアフォだなw

もっと賢い対応方法を考えることができないのかよw

とりあえずGoogleにShift JISをはくように指定できる。

そこで UTF-9 と UTF-18

俺なんかUTF-256を指定したら赤ちゃん出来たよ。危険すぎ。

織田信長=「パソコンをぶっ壊す！！！」だったのか。分かった。

サイバーな戦国時代ですね

俺はUTF+8で保存したら、ディスクの空き容量が増加したよ。

http://science4.2ch.net/test/read.cgi/infosys/1045473594/64

64 名前：非決定性名無しさん[] 投稿日：2005/09/01(木) 16:06:49
http://www.itmedia.co.jp/news/articles/0508/31/news062.html

＞ 　JIS委員の南堂久史氏は、Webサイト「2004 JISをめぐる混乱」で、
＞ 「従来のJISでは、略字が大幅に取り入れられ、日本の伝統的な
＞ 文字遣いが犠牲になってしまっていた」などと、新JISで正字体を
＞ 採用した経緯を説明。略字を使っていた一部機関などに犠牲が出る
＞ ことを詫びつつも、正字体の必要性を訴えている。

南堂氏ってJIS委員・・・・あｑｗせｄｒｆｔｇｙふじｋ

>>441
> 初出時、「JIS委員の見解」として掲載した部分は、JIS委員のものではありませんでした。お詫びして訂正いたします
となってITmediaの記事には、もうない。初出のインチキ記事のせいで、
本物委員・安岡先生、反論をあちこちに書き込んでたな。ごくろうさま。

麻雀牌文字の提案キタコレ
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2975.doc

それにしてもカナダとドイツのファビョりようが面白すぎる
そこは漢字圏の人間が10年前に通った道ですよ?

中国ってどうやって文字打ち込んでるの？？！！
漢字それぞれ発音が違うんでしょ？アルファベットで無理やり当て字っぽくだすんだべ？
他想像つかない、そすっと連文節とか出なそうだ、1字ずつ変換してんだろうか

韓国はカナ入力みたいな事してもキーボードあまるだろう
日本語が5音だけでよかった

>>444
前に中国語のGlobal IMEで遊んでみたことがあるんだが、
それぞれのキーに簡単な漢字が割り当てられていて、
それを組み合わせていくようだ。（木を2つ入力して変換すると林になるという具合）
あと、ローマ字みたいなピンイン入力もあった気がする。

流石に赤五筒を入れないだけの良識(wは持ち合わせているか。

SJ３はpin-inで入力できたな。

>>444
大陸のネイティブな中国人はたいがい五筆。
日本語のような読み入力→変換ではなく、
目的の漢字に対応するコード(基本はキー4つ)による直接入力。
そのキーは漢字の造りや画を元に決められる。
中国の本屋やスーパーにいくと教本が山のようにある。

中国語学習者はピンインが多いと思う。
同じピンインに対応する漢字が多いので入力メソッドが馬鹿だと
しんどいことこの上ない単漢字変換になってしまうが、
よく使われてるやつでは辞書を元に入力予測方式や短縮入力
ができるので、かなり楽。

俺は以前五筆を覚えかけたが日本にいる間はDvorakで生活してるので
ピンインに戻ってしまった。
QWERTY前提なんだよな五筆。

個人的に一番楽なのは携帯で使える筆画入力だったりする。
たまに書き順わからなくなってピンインに逃げるけど。

俺の知り合いはピンインだったよ。
五筆は国定なんでしょ。あんなの馬鹿馬鹿しいって言っていた。

IMEがバカでも問題がない五筆と
IMEの品質次第のピンインってとこ？

大陸 … ピンイン
台湾 … 注音

だったと思っていたけど、現実はもっと複雑なのかな。
ちなみにSCIMにはpinyin, chewing両方のIMEがある。

漢字読めるけど書けない人大量生産の日本とはだいぶ違うんだ
書けなきゃ話にならないね

その代わりはらわないでとめたから×とか
そういうアホな教育はやってませんから

つーか細部に注意をいきとどかせるなんてことやってる余裕がない。
やってたら中国製品の質もずっとマシになってたんじゃないかと思わないでもない。

なんせガキは喋れるけど書けない文字がいっぱいある。ひらがなねーし。
自分の名前くらいは幼稚園で教わるけど。
ちんたらやってたら他の教科の学習も不自由するんじゃなかろうか。

クォック・グーから漢字＆チュノムに変換できるベトナム語のIMEがあるといいな。
現状ではチュノムのフォントですら文字鏡くらいしかなかったような気がするが。

このフォントを無償公開しているって事はないのかな。
http://www.mojikyo.org/html/institute/sokai/02/sokai02.htm

NIK-code、T-code、TUT-codeを試してみたが、覚えられ中田 orz

四角號碼で入力できる大漢和みたいなIMEはないのかねぇｗ

>>456
文字鏡フォントと同じもののような希ガス

>>458
欲しいのは字形データだけじゃなくて、
ベトナム(or Unicode)のエンコーディングスキームでできた、
適切に国際化されたシステムならどこでもつかえる、
事実上文字鏡専用ではないフォントな希ガス

>>458
> 文字鏡フォントと同じもののような希ガス

…記事にそう書いてあるよね…

これ寄贈したんだから、ベトナムは使っていいんでしょ?
寄「贈」だから、配布していいんじゃないのかな?

>>459
チュノムはUnicodeだとCJK Unified Ideographs Extension Aで初めて入ったと思う。

>>460
寄贈先がベトナムの研究機関だからそこが配布の条件を決めるということになるんだろう。

月刊言語2005年10月号が「インド系文字の世界――デーヴァナーガリー文字入門」を
特集していたり、アジアの文字への関心は、いま盛り上がり時期なのかな。
http://thistle.est.co.jp/tsk/detail.asp?sku=50510&page=1

というか、国が文字をこれだけ使うと決めれば言いだけの事なのになぜ未だに手書き文字の戸籍をみとめるんだ？
花押とかサインの類が手書きなのは認めても、全ての人が認識できない物に意味は無いんじゃないのか？

土
口　野家

士
口　野家

>>463
水彩油絵などはこの世から無くしてしまえ。1024x768 32bit以内で表現しろ。
と言ってるようなものだな

>>463
いや、新しいのは基本的に認めてないぞ。

>>465
なんでそうなるんだよ。芸術作品をどうこうしろなどとは言ってないだろ。
情報の交換である文書は正確に意味が伝わらないとダメだろが。
だから文書の中で表現する時の文字は全て規定しろって言いたいんだよ
ようするに文書を紙の上に表現する事を前提にしているところを、電子化する事を前提にしろと考え方を変えろと言ってるんだ

>>467
あんた全然わかってないよ。
つーか、こんなカス人間が文字コード規定しろとか、笑わせるよな。

まあなんだ。変えるべきは電子化の方法であって、
戸籍や文字文化のシステムの方じゃないわな

Windows入れた後に外字インストールすんのめんどくさいんだよ

「戸籍法施行規則」でもって、戸籍上の氏名のうち名の方の文字は制限されているから、
JIS X 0213:2004対応フォントを使えばそれですむ。
氏の文字の方はやっかいだから、法務省も原則として統一する方向で、
誤字俗字の排除を進めているようだけど、強制的なやり方は
国会が認めてくれなかったということだろうね。

でも法務省の基本方針にならうなら、外字に頼ることは少なくなると思うが・・・
誤字俗字を正字に引き直す法務省の判断基準は、「新 誤字俗字・正字一覧表」で分かるよ。
http://www.teihan.co.jp/contents/k007.htm
司法書士あたりで必需品になってるやつさ。
まずはこの基準で統一して処理するのは、正当かと思うんだが。
文句を言ってきた相手に何と言うかは、それぞれの判断で・・・
なお、戸籍には「よみかた」は記載されない。住民票には記載される所が多いらしい。

この辺りね。
http://homepage2.nifty.com/n-bunko/pc/kotoba06.html
http://homepage2.nifty.com/n-bunko/pc/kotoba06b.html ←古い版

http://www.meti.go.jp/press/20041221008/041221jinmei.pdf とか。

いちおここにもはっとく

Globalization Gotchas
http://macchiato.com/slides/gotchas.html

そーいやAdobeがAJ1-6をUnicodeで符号化するためにVariation Seqeuncesの
登録制度の標準化を進めてるようだが。
http://www.unicode.org/reports/tr37/tr37-2.html
いつの間にか更新されてた。
> This collection could be targeted at the representation of person and place names,
> for example.
という登録例がズバリ示されてるな

Unicode(UTF-8)…ASCIIの拡張
GB18030…GB2312(EUC)の拡張
TRONコード…JIS X 0208(GLに割り当てた場合)の拡張
みんな自分が可愛いんですね(当たり前か)

>>474
登録例は「芦」で「芦田さんは芦屋のお嬢様だ」ときたわけですね。
これは、提案者のAdobeにとっては
> AJ1-6をUnicodeで符号化するために
という目的があるとして、内容は
> Variation Seqeuncesの登録制度の標準化
として異体字を扱うために汎用的に利用できるものと理解していいんでしょうか。

cp932・・・Shift_JISの横領
自分以外が憎いのさ！

>>476
そうみたい。TRの規定を満たせば理論上は誰でも登録できるはず。
具体的な目的がちゃんとあるから、Language Tagみたいに申し訳程度に
規定しといて事実上誰にも使われないようなものにはならないでしょう
>>477
Shift_JISってもともとMicrosoftが作ったんじゃなかったっけ?
後から互換性がないようにJISでシフト符号化文字集合を規定しておいて
「MSのシフトJIS」は附属書1と互換性がないとか言われても困るような。
独自拡張として放っておかれたままのほうがまだマシだったかも

>>478
Shift JISの制定過程はなんかややっこしいらしい。
http://ja.wikipedia.org/wiki/Shift_JIS
http://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:Shift_JIS

http://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:Shift_JIS
> シフトJISはアメリカ製ソフトの日本語化に適していたので、

http://www.iana.org/assignments/character-sets でいうところの
JIS_X0201の延長線上で、JIS X 0208の漢字を使うのに適していたので、

とした方が性格だろうな。
半角仮名(JIS X 0201 Kana)のみはそれ以前から使えていたわけだから。

それから、アスキーの担当者が昔語りしているのがどこかにあるはず。
fj.kanjiでもうpされていたような気がする。

>>480
「アメリカ製ソフトの日本語化に適してい」るのは圧倒的にEUCだからなあ。
半角カナの呪縛が大きいんだろうな。

しかし文字コードみてると、互換性を錦の御旗にレガシーなものをひっぱると
後々に禍根を残すだけだねまったく。

当時は階層ディレクトリの区切り文字に \
(つーかISO 646 invariantじゃない文字)を使う変態なOSなんてなかったから
ここまで問題になるとは思っていなかったようだ。
つーかそこはWikipediaだから直接なおしに行けばいい

何に比べて「アメリカ製ソフトの日本語化に適していた」のかが書かれていないんだな。
おそらくJIS X 0208を単独の符号化文字集合として使ってGLに割り当てた場合だろう
(実際PC-9801のテキストVRAMはそんな構造してたし)。
EUCはシフトJISの反省に立って作られた符号化方式だからシフトJISより改善されてる
のはある意味当たり前だ

>>483
'が2byte目に来たらPascalのリテラル文字列で困るんじゃないか?
# Cの\だってそうだけど、あまり一般的でなかったからPacalにした。
# もちろんmulti byte文字を理解しない8bit throughの処理系の話。

>>484
EUCは、ISO 2022が出た時には準備万端だぞ?
JIS X 0208出た時には問題なしだろ。(それどころかC6226の頃かも)

>>484
> 何に比べて「アメリカ製ソフトの日本語化に適していた」のかが書かれていないんだな。

いや、一番重要だったのは、既にあるJIS X 0201 Kanaを、
GRに割り当てたことを仮定しているプログラム/データ資産のはず。

PC-8001上のN-Basicで書かれたプログラムなど。

これを捨てて良ければ、EUC-JP相当のもので良かった。

>>485
GRに割り当てるのが正当化されたのは
もっと後のISO 2022の改訂からじゃなかったっけ?
複数バイト図形文字集合はG0=GLにしか割り当てられなかったはず

すくなくともX 0208より後なのは確実。X 0208とGB 2312のエスケープシーケンス
だけ他の複数バイト図形文字集合より短いのは、まさに当時
> 複数バイト図形文字集合はG0=GLにしか割り当てられなかったはず
だったからで、この制限がなくなってからも互換性のためX 0208の指示シーケンス
は1バイト短いまま。

> 'が2byte目に来たらPascalのリテラル文字列で困るんじゃないか?
'はシフトJISの2バイト目に来ないので困らないと思う。
(ISO 646 invariant云々は不適切だったので忘れてくれ)
つーか当時困らなかったからこれでいいと思って場当たり的に決めて
今になって困ってるわけだろ。
なんかどっかで聞いた話だな。きっと2バイトで足りるに違いな(ucs

JIS C 6228-1975
JIS C 6228-1984 のちにJIS X 0202-1984
JIS X 0202-1991 のちにJIS X 0202:1991
JIS X 0202:1998

> 複数バイト図形文字集合はG0=GLにしか割り当てられなかったはず
なんでそんな仕様だったかというと、単独で使うことを想定してたんだろう。
(たしかそのためにC 6226の1区はASCIIと同じ並びにするという話もあったはずだが
どこ行ったんだ)
ASCIIの文字を全部含んでいればASCIIを使う必要はないと。
現実にはその見通しは甘かったばかりか重複符号化に苦しめられてるわけだが。

>>490
変更があったのなら1984だろうね。1991ってことはないから。

安岡孝一氏が日本での文字コードの歴史を書いている中で、
「シフトJIS の誕生」についても触れている。
きっちりと資料に当たって書かれている所がいい。

「日本における最新文字コード事情」
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/ISCIE2001.pdf

>>493
文献のところの吉田茂(内閣告示)の吉は、
士と土が混在しているけど、これはオリジナルに合わせてるのかな。

鋭く細かい所に気づくなあ。面白い。確かに使い分けられているね。
http://www.aozora.gr.jp/kanji_table/touyoukanji_hyou/
ここの後の方に、当用漢字表のとき「土」になっている官報の画像版があって
確認できる。その通りにしたんだろう。
当用漢字字体表の時は「士」に変わったわけかな。
吉田茂の「吉」の字のエピソードを確かどこかで読んだけど、
あれは「JIS漢字字典」だったっけ。

「JIS漢字字典」のコラム３、吉田茂の決断だね。
読売新聞社刊「日本語の現場」第二集の逸話だって。

>>495
こんなところに取り込んだ画像があったんだね。

>>492
1991はSSの後の1文字をGRにすることを認める変更じゃないの。
その前年に補助漢字ができてるから。
しかしJIS X 0208改訂のきっちり1年後に必ず後を追うように改訂してるな

> AJ1-6をUnicodeで符号化するために
のソース。
http://www.imug.org/pastevents05.html#Jnames

>>498
SSの後の1文字がGRにできるようになったのは1998年の規格から。

>>499
ソース提供、ありがとう。
TRにないみたいなので、どこかなと思ってた。

>>500
なんと、そんなに新しかったのか。
それまで公式にはEUC-JPのSS2/SS3の使い方はISO 2022に適合してなかったのね。

>>501
さすがにTRにそんなことはモロに書かないよ
表向きの目的を掲げるだけでしょ

あのさ俺の苗字ってハシゴ高なわけだけど

郵便物とか封書とかでハシゴ高印字してくるの
水道局だけなんだ。話はそんだけ
NTTは使ってないだけか？水道局はフォントがあるのか？
郵便局は出せるだろうけど、関係を作る方法が思いつかない
ハシゴ高廃止してもらって構わないんだけど、
通帳とか免許とか1文字だけ手書きなのうんざり

私の名前には巳が含まれるのだが、某証券会社では已が使われていた。
その後その証券会社が吸収されても已のままだったのにさらに吸収されたら正しく巳になった。
さて、字形がおかしかったのか、そもそもコードもおかしかったのか……

聡なんだが、不動産屋と契約したら、
不動産屋の死にかけのババアが勝手に聰で契約書作っていた。
不動産への登録もこっち。
更新の時に、前の人年寄だから漢字違っているけれど、
# くたばったババアはあちこちで勝手に旧字体にしていたらしい。
延長なのでこのままにしてください、ってそのままだったのが、
いつの間にか正しいのに変っていた。しかしこれ文字コード全然関係ない…

旧字旧かな厨氏ね

どこに旧字旧かな厨がいるんだよ
意味もなく煽る藻前が(ry

厨じゃなくて婆な

http://www004.upp.so-net.ne.jp/hitosen/ujina/ujina93.html
> 旧字体を通用字体に変更したい場合は、本籍地の役所で「文字更正の申し出」をすれば、
> 通用字体に変更することが可能です。手続はものすごく簡単です。

「文字更正の申し出」に当てはまらない氏名の変更は、
http://homepage1.nifty.com/lawsection/tisikibako/ujinohenkou.htm
> 家庭裁判所に「氏の変更の許可申立書」を提出します。

登記のための法務局提出書類にサインするとき、司法書士に
「斎」＝「齋」、「斉」＝「齊」、しかし「斎」≠「斉」、「齋」≠「齊」と言われた。
本当は「齋」なんだけど、めんどくさいから「斎」ですませた。
登記簿は「齋」になってた。

その時、使った実印は、オヤジが作ってたやつで「斉」だったが、
印鑑登録に字体は関係ないということか。
これ文字コードに関係あるのかな。

>>509
しかも既に亡くなっているし。

>>511
字源的には書士の言う通り。
JISとしては四つとも別の字。

>>511は特に"齋藤"とは書いてないが、「JIS漢字字典」の人名音訓を調べると、
済藤、斎藤、剤藤、斉藤、濟藤、齋藤、薺藤、齎藤、齊藤(区点順)
とJISの範疇内でもこれだけのサイトーの別があるらしい。

「人名外字1500V3」フォントの所をみると

●異体字のバリエーションもこんなに豊富です！
・斉藤の「斉」→３１種類

>>511
「斎藤」は元来、藤原一門の神事担当職と言ったニュアンスの伝統的な苗字。
「一斉」の「斉」には、「斎藤」の「斎」のような「さい」という音が元々はない。
勿論、「斎」のように神事を扱うという意味合いもない。

>>512
実印は明らかに読みが違うもの以外は苗字がなく名前だけでも大抵のものが登録できる。
例えば「阿久津美莉」さんが「�_」なんて実印を作ることもできる。

今昔文字鏡の「斉」は68種。

「斎」と書いて「キンジェー」と読むらしいが、タイの方である期間ヴェジな生活を送るという
華僑由来のイベントがあるらしい。激しくスレ違いだが。

で、その68種類の文字を区別しなければならないんですか？

他人事で済む奴はいつもそう言うんだ

おれには斉以外認識できない

中国語がTraditional ChineseとSimplified Chineseで別個の文字集合になっているように、
日本語もTraditional JapaneseとSimplified Japaneseで別個の文字集合にすればよかったんだ。

といい加減なことを言ってみるテスト。

>>520
むしろ他人事で済まされなかったらたまらんからだろ
済はさんずい+済なのになんで68種類ないんですか? とか
(こたえ: あまり苗字に使われない文字だから)

> さんずい+済
さんずい+斉orz

>>522
ソ連とアメリカが、東日本と西日本に分割していたら、そうなったかもね。

唐突なやつだな。
ソ連なんて地続きの樺太でもさんざんてこずって、北方領土をかすめとるのが
せいぜい、北海道にはとりつけもできなかったんだから分割なんてありえない。

正直「社長の名前を一発で変換できるIME」みたいなしょーもない話だと思う

日本の漢字って中国からパクったわりに発音どれもあってなさそうだよね、
日本らしくする為に名前全部ひらがな表記とかすればいい

バカなのか釣りなのか

>>528
訓読みって知ってる？

中国人も自国の文字のわりに発音どれもあってなさそうだわな。

表意なのに形すら違うからな。

>>530
きっと訓読みがない国の人なんだよ

>>528
>>528
>>528
>>528
>>528

新人名用漢字の「たまひよ」名前ランキング
http://women.benesse.ne.jp/hakase/sitemap/ranking.htm

人気の漢字を見ると、凜と凛の入力ミス多発の予感

「同一の字種」だからどっちでもいいのでは？
つうかよくわからん「同一の字種」。

「１字種１字体の原則は維持するが、
例外的に１字種について２字体を認めることを排斥するものではない。」
よくわからんねえ。どっちでもいいんだか、区別せよと言うんだか

そもそも凜は凛の正字だからこちらの字体が人名用漢字として登録されたけど、
誰も使わないものだからなし崩しに凛も新人名用漢字として認められるようになった。
IMEから凜を簡単に入力できないというのも大きかったと思われ

　　　 _ 　∩
　　(　ﾟ∀ﾟ)彡　包摂！包摂！
　　(　 ⊂彡
　 　|　　　|　
　 　し ⌒Ｊ

でもって、この場合は「康熙字典」の字体の方が
俗字とされる「凛」だったりするわけで、
こっちが広く使われる由来だったりするんだろうか。これも分かりにくいなあ。

http://www.taishukan.co.jp/kanji/qa_shape.html#Q3048
こんな所にＱ＆Ａがあった。
>「凛（りん）」の右下の部分が「示」ではなく「禾」になっている字が、パソコンで出ないのですが、どうしてでしょうか？

http://jvn.jp/jp/JVN%2318282718/006082/index.html
正規化しなきゃしないでIDNの脆弱性だフィッシングだと
何をやっても文句を言われて大変ですなあ

>>542
IMEが変換しない(少なくとも当初の)理由は83JIS以前の機器で字が出ないから
「誤って」使われないようにするためだったと思われ
実際にはJIS(X 0208)に収録されている文字でさえこうなんだから
Shift_JISじゃ出せない文字なんてよほど強力に使用を推進しなきゃ
普及させられるわけないよなあ

もっともだ。この先も、90JISまでのフォントしか持っていない機器がある以上、
Vistaに新フォントが搭載されようが、JISX0213:2004の新しい文字なんて、
デフォルトの設定のままでポンポン出てくるなんて、無理な話だってことね。

MicrosoftはIMEのデフォルト設定で印刷標準字体を優先して出すと言ってるけどね。
「2004JISでカモメの字体が訂正」とか不勉強にもほどがある記事が大真面目で
IT系のニュースサイトにすら掲載されるんだから
どれだけ鷗を使えることが知られていないか分かろうってもんだ

堯槇遙および凛が人名用漢字に追加されたのに瑤と煕が追加されなかったのは
なんで？

南堂さんが圧力をかけなかったから。

妄想を鵜呑みにしてる奴発見

>>547
単純に頻度が足りなかっただけ

何しろ頻度が足りていれば
糞，屍，呪，癌，姦まで追加の検討対象になったくらいだし

パブリックコメントに出したら、糞，屍，呪，癌，姦なんて入れるな!
という批判が多く出たおかげで、やっと削除できたというほどに
「常用平易」なら入れろという最高裁判決に困ってたみたい

俺は「常用平易なら入れろ」に賛成だけどな。
意味的に不適切な字を削除しても無意味なことは
あくま君問題の結末が証明していると思うんだが。

常用平易でも除外されてる文字があるのが謎

南堂さんが(ry

もうそのネタは秋(ry

「糞」や「尻」を入れるんなら同程度に頻度の高い「肛」も入れろ、
第二水準差別するなゴルァという俺のコメントは黙殺されたけどな。

委員「また、『やらないか？』か！」

> 同程度に頻度の高い
の根拠が不明

膣と肛門が同程度の頻度
根拠は不明

>膣と肛門が同程度の頻度
両刀使いだから

多くの文字コードに対応した外国産のWinアプリを使用しているのですがこのアプリで
SJISを指定して「ゾ」の文字を保存すると「ソ」、「 ] 」、16進でいうと 0x83, 0x5c, 0x5d と
3バイトで保存されてしまうのです。SJISの文字コード表でみると「ゾ」は、0x83,0x5d の
ようなのでこれはバグなのでしょうか？メモ帳などでこれを開くと「ソ」、「 ] 」と2文字で
表示されます。

転はどうですか?

>>563 レス遅れました。
「貼」「 ] 」の2文字（3バイト）になりますね。2バイト目が0x5dの文字がダメってことですか。
でも（当たり前かもしれないが）このアプリで読み込めばちゃんと「ゾ」とか「転」とか表示
されるんですよね。そもそも３バイトにエンコードってありなんでしょうか？

どういう訳か知らんが、閉じブラケット ] (0x5d) の手前に
バックスラッシュ \ (0x5c) を入れたいんだろうな

もちろんこんな処理は不正

>>565
なるほど0x5cは \ でしたか。そのアプリが ] の前に \ を入れたい
理由は分かりました。やっぱりアプリのバグのようです。
ありがとうございました。

厳密に言えば、「尻」が圧倒的に多くて使用度数 3279 回 (1422位)。
続いて「肛」の 811 回 (2208位)　と「糞」の 773 回 (2236位) がほとんど
同じ。上位3000位まで取って候補を選定したんだから、ずいぶん上位に
入ってることが分かると思う。
これは、表外漢字字体表の選定にも今回の人名用漢字表の選定でも決定的な
役割を果たした(新)凸版調査の順位そのものなので >>561 の推測は間違い。
ちなみに、人名漢字のパブコメは、数が多すぎて、委員は法務省のまとめを
見ただけで、個別のコメントに目を通してはいないだろうと思う。

さらに言うと、驚くべきことに「膣」(399回、2623位)よりも「腟」(820回、
2197位) の方が多かったりする。それなのに印刷標準字体が「膣」であると
いうことに、この問題を理解する鍵がある。

第二水準差別するなってそういう意味か。
第二水準の文字全部入れろとか言うよくいるアホかと思った

とりあえず「腟」は解体新書を出すときに作られた字だと言う話を思い出した。

腟=肉＋室＝にくむろか。
エロイな。

>>553
> 意味的に不適切な字を削除しても無意味なことは
> あくま君問題の結末が証明していると思うんだが。
糞・尻が使えなくても久素・史理で「くそ・しり」と読ませるのは
許されるのだから無意味といったこと?

かな文字もあるしな。

ほとんど同意してしまう部分があるけど、
人名用漢字として選定する権限と責任のある仕組みの上では、
漢字は選定できても、読みは制限できないという点で別問題かも
とは思ってしまう。
もっとも人名用漢字の制度を設ける必要あるかないかに直結するかな。

本当は怖い親権の濫用

地名って一水、二水の範囲で網羅してるの？

行政地名は網羅してるけど
地名はそれだけではない罠

年賀状の宛先が書けないケースもあるってこと？
それとも、歴史上の地名とかの話？

大たわ(山+定)とか。JISどころかCJK ExtBにもGT書体にもない。
年賀状に書く必要のある地名なのかどうか知らないけど。

山にはよくあるけど >大たわ
尾根部分だから殆ど人住んでないだろーな。
山小屋なら「○○小屋」で通じるから住所いらないし。

「山偏に定」と書いて「撓」の当て字とかあるな。
こういうの当て字っていうのか？

>>575
http://pyrite.s54.xrea.com/timei/

「タワ」って鞍部(尾根の釣り下がった部分)のことだろ?
要するに「垂れている」ってことなんだけど。(タル、タルミなど)
乢、垰とも書くよな。
道が尾根をクロスして登り下りすると峠になる。

>581
すごいの見付けた

かわだ 西広門田

どーゆー配分だこれ

MS IMEの人名/地名モードもATOK2005も
「かわだ」で変換できるのがさすが。難読地名の代表なのかな。
かな文字より漢字の方が多いんじゃ、ふつう配分できんだろー

流石て…ﾌﾂｳ ﾔﾝ...
川渡(カワド)が別の読みの地名とクッツイタという説があったような。

MS IMEの変換モードが「一般」だと「りん」で「凛」は出ても「凜」は出ないから、
パソコンで出ないなんて話になるんだろうけど、
「人名/地名」モードに変えればどっちも出るし、一度「凜」使えば一般モードに戻してもOK。
これもフツウ。それすらしないから「凛」が大杉。

そういうわけで>>539の
> なし崩しに凛も新人名用漢字として認められるようになった。
だとすると・・・

JISの地名漏れ多すぎじゃね？ こんなもん？

個人的にはこの程度で済んでるんならかなりマシな部類だと思うが…

78JISは「国土行政区画総覧使用漢字」昭和47年版の3251字をすべて収録した。
それ以後にJIS漢字にもないような難しい漢字の地名が新設されたとは思えないから
JIS漢字の地名の漏れはそのままこの資料の漏れと言っていい。
いわゆる「幽霊漢字」の多くもこの資料が典拠だし

だから>>576に書いたように
> 行政地名は網羅してるけど
> 地名はそれだけではない罠

俺もASCIIコード圏に生まれたかったよﾏﾏﾝ

>>590
国土行政区画総覧じゃなくて日本行政区画便覧を使ってたらまた違ってたかもなぁ

>>592
現代において文字コードに困らないのは結局ASCIIだけだしな
ISO-8859-Xたちもそれはそれで化け化けらしいし

>>592
それは、アメリカに生まれたかったということで宜しいか?
#ヒント：ASCIIのフルスペリング

まぁ実際、英語を母国語とする英国でさえ一部文字コードがASCIIではないからねぇ。

ブリテンにはスコットランドもウェールズもあるからね。

ついでに言うとアメリカも今ではスペイン語人口が多い罠。

ASCIIには、ユーロもポンドもないからねえ。

つーかいい加減アメリカもメートル使えよな
いつまでもインチとかフィートとか言ってんじゃねーよ

ASCIIにバックスラッシュが入ったのは、“/\”で and を、“\/”で or を表現したかったALGOL厨の陰謀らしい。
Latin-1に、"oeリガチャ"（フランス語で、「心臓」とかを表すのに使う。超必須）が入らなかったのは、÷を入れたかったドイツの数学者の陰謀らしい。
ちなみに、Latin-1の0xFF (y diaeresis) を使う単語は、仏語に４つしかなく、そのいずれもがほとんど一般には使われないらしい。

つまり0xFFにoeリガチャを割り当てなかったフランス人ﾜﾛｽ、てことでFA?

どこも日本みたいな過ち犯してんのかよ
だせーなー

ISO-8859-1 の元になった DEC のコードでは「oeリガチャ」は確かに×÷の位置に
定義されてるね。「yダイアレシス」は今とは別の位置に定義されていて、大文字
もあったが、アイスランド語が書けるようにしようとか下手に色気を出したので、
アサッテの位置に追いだされたようだ。

そして文字コード指定のない(あるいは欠けてしまった)ISO-8859シリーズは、
日本の場合より悪いことに、コンピュータによる推測が絶望的だったりする。

どいつもこいつも0x20〜0x7Fと0xA0〜0xFFを使うことに変わりはないので、
日本のように「文字コードによってはこのバイトは使わない」ということがない。
(まず使わないだろう、というヒューリスティックな推測はできるけど)


しかしどこの文字コードも主に政治の結果が色濃いのが笑えるなｗ

Latin-1って名前もあれだよな、ドイツ語入ってんのに。

>>600
最近某所でそんな話を不味いノンアルコールビールを飲みながら聞いたんだが…。

そこでヨーロッパ人にとってはUTF-8サイコー
判定間違えて文字化けもしないぜウホッとなるわけですよ

日本は文字化け先進国
なれって怖いよねあたりまえのように数種扱い続けてる

>>608
漢字ひらがなカタカナalphabetが混在する物を当たり前のように扱ってきたからかもしれんｗ

>>607
まあそれはユーロ記号の件が一番大きいんだけどな。
それ以前にも何度か混乱していた時期があると聞いたが、どうやって乗り越えたのやら。

責任の一端はTeXにあるという説を提唱してみる。
やつが余計なお世話をしなければ、いかに愚鈍なヤンキーといえども
「あれ、文字、全然足りなくね？」
と即座に気づいたであろう。

ASCIIにバックスラッシュが入ったのは、R.W.Bemerが、ALGOLのand と or を使えるようにしたかったため。
彼のホームページに経緯が詳述してあったけど、１年前に癌で死んでホームページが消されてから、
そのあたりの資料も一切合財が雲散霧消してしまった。

le «ÿ» est utilise en gallois et en vieux francais.
On le recontre encore aujourd'hui dans des toponymes comme «l'Haÿe-les-Roese»,
des noms comme «de Croÿ», «Louÿ», or des expressions comme «kir à l'aÿ».
Cette lettre est extremement rare et son insertion dans ISO 8859-1 est pour le moins insolite.

>>612
URLは? それが本当ならwaybackmachineに残ってそうなものだが。

Character histories: notes on some Ascii code positions
http://www.cs.tut.fi/~jkorpela/latin1/ascii-hist.html

ASCIIの誕生←ここの参考文献[4]に載っているかも。
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/ASCII.html

>>615
> Character histories: notes on some Ascii code positions
> http://www.cs.tut.fi/~jkorpela/latin1/ascii-hist.html

そっからリンクがあったんだが、ドメイン屋にのっとられてる上に
robots.txtでwayback machineが弾かれてて軒並消滅してた。

作業中だったら言ってくれよ
同じ末路たどってたゴール手前

嘆や漢の右側だけの文字って文字コードはあります？できれば、旧字体のがあればいいんですけど...

U+26C29にある。JIS(第4水準)やUnicodeの例示字形では新字体だけど
旧字体も包摂されてるはず

般若心経は全部出るようになったんですかね

もともと般若心経で JIS X 0208 になかった字は「罣」がひとつ
だけで、これは補助漢字にも X 0213 にもはいっているから
とうぜん出るでしょう。

>>621
もうひとつ「埵」も X 0208 になかった字だけれど、
これも補助漢字・X 0213 の両方にある。

もしかして、鳩摩羅什訳だと>>621で、玄奘三蔵訳だと>>622という違い?

四
圭　これは？あとどうやって出したのその漢字

ヒント：数値文字参照

>>604
ISO-8859シリーズの判別にはEncaが使えるかもしれない。
ttp://trific.ath.cx/software/enca/

EUC-JP,KR,CNとかBig5の区別をするのに各言語の文字
出現頻度を使いたいんだが、どこかにリソースないかな?
日本語のデータはメーリングリストのログ等で準備できるんだが、
中国語、韓国語なんかはgoogleすらできないんだorz

完成記念

観自在菩薩行深般若波羅蜜多時照見五蘊皆空度一切苦厄
舎利子色不異空空不異色色即是空空即是色受想行識亦復如是
舎利子是諸法空相不生不滅不垢不浄不増不減是故空中無色
無受想行識無眼耳鼻舌身意無色声香味触法
無眼界乃至無意識界無無明亦無無明尽乃至無老死亦無老死尽
無苦集滅道無智亦無得以無所得故菩提薩埵依般若波羅蜜多
故心無罣礙無罣礙故無有恐怖遠離一切顛倒夢想究竟涅槃
三世諸仏依般若波羅蜜多故得阿耨多羅三藐三菩提
故知般若波羅蜜多是大神呪是大明呪是無上呪是無等等呪
能除一切苦真実不虚故説般若波羅蜜多呪即説呪曰
羯諦羯諦波羅羯諦波羅僧羯諦菩提娑婆訶

２年以上前に同じことを考えた人がいた。
libcharguessというのでCJKのエンコーディングは判別可能みたい。
開発が停止しているのが残念だが、いちおう使えるのでよしとするｗ

ttp://sourceforge.net/projects/libcharguess/

呪と咒は異体字だったのか。

般若心経と並んでポピュラーな観音経（普門品第二十五）には「虫偏に元（U+8696）」
があるんだけど、X 0213から漏れてる。

　 若惡獸圍遶　利牙爪可怖　念彼觀音力　疾走無邊方
→蚖蛇及蝮蠍　氣毒煙火燃　念彼觀音力　尋聲自迴去
　 雲雷鼓掣電　降雹澍大雨　念彼觀音力　應時得消散
　　　　　　　　　　　　　↑これもX 0213

明治以降の日本で用例が不足してたんだろう

そういや文字コードの順番ってどうやって決めたん？

>>630
ちゃんとはいってる補助漢字サイコー。

仏典関係でいうと「あぬるだ」の「ヌ」がExt-A(3779)で、かつ0213からも
抜けてるんだよなあ。

>>632
第一水準は音読みの順になっている。第2水準は部首順。ほかは知らん。

>>633
少
兔 という字か。免でも同じか? フォントによって違うな。

>>632>>634
第一水準で1ヶ所だけ順番が狂ってるのはJIS漢字字典にもあるし結構有名？

>>633
仏典・漢籍は補助漢字の方が強い。

「千字文」ももうJISで書けるんでしたっけ。

どのJISよ？

JIS X 0208: 書けない
JIS X 0212: 「清」の左側が「冫」の字がない。「清」でよければ書ける
JIS X 0213: 書ける（書けるように委員が要望したらしい）
JIS X 0221: 書ける

> JIS X 0213: 書ける（書けるように委員が要望したらしい）

http://www.l-h.co.jp/lhcontents/l-hlib/senji_newjis.html
ここを見るとそう思えますね。U+9D7E [鵾] が第4水準に入ってる。
これのテキスト、なかなか良い。
ただ、「祇」がどうも気になる。「祗」の方が適切じゃないかと。

ttp://tar-yan.cocolog-nifty.com/weblog/2005/11/unicode__sip_52b1.html
拡張Bのフリーフォント。たあやんのフォントは昔からお世話になってるけど
ここまでやるとは。

>>640
をいをい「祇」と「祗」は全然別の字だぞ。
偏のネと示は字体の違いに過ぎないしJISでも包摂されてるけど。
まともな研究者ならしめすへんが示で書かれてないから
駄目なんて言ったりしないし「祗」で代用なんてありえない。

人名用漢字に「俺の苗字がない」って騒いでる奴の多くは
結局そういう絵合わせレベルでしか漢字の異同を認識できない素人なんだよなあ
とはいえ行政がそういう素人に合わせた運用してるんだから仕方ないよな

>U+9D7E

JIS X 0213 に「学芸」としか書いてないのがあやしげ :-)

千字文はいろいろテキストがあるし、「祗」と「祇」は古くから混同されて
いるから、「祇」になっているテキストもあるのかも。

智永のを見たら「祗」になっていたが、「清」はさんずいだった。

> 「祇」と「祗」は全然別の字
だから、もしかして違うんじゃないと思ったということなんだけど・・・
岩波文庫版『千字文』の意味解釈からすれば、「祗」がよさげかと。
でも、「祇」になってるテキスト、けっこうあるかもね。

ついでに、
しめすへんが「示」か「ネ」かは、関係ないことです。
つうか、JISX0213:2004フォントで見れば、どっちも「示」でそこに差はない。

そういえば以前、人名用漢字の表で、「祇」が正しいのに元が「示」を使っているせいで
「祗」を入れてしまったものがあったな。
JIS X 0208 の字体で見て、勘違いしたんだろう。表外漢字字体表があれでは仕方ないな。

>>641
> ｛転載等の注意｝フリーソフト（データ）です。
> 二次配布は作成者にｅ−ｍａｉｌにて、お問い合わせ下さい。

か。いわゆる自由なフォントではないみたいだな。

神津島村に祗苗島（ただなえじま）って島があるんだけど、
http://www2.kankyo.metro.tokyo.jp/sizen/tyoujuu/hogoku/ichiran.htm
ではわざわざ袛を使ってる。まぁそんだけなんだけども。

貼ってから気づいた。これ衣偏じゃんか

>>649
またレアな字を……

マピオンの表示がちょっと受けた。
ttp://www.mapion.co.jp/c/f?uc=1&grp=all&nl=34/12/14.843&el=139/11/44.769&scl=25000&bid=Mlink

子のスレに隊する朝鮮だな。

どっちでもいいんだという高等な逃げとの解釈もあるかと。

↓島の住民からの一言

京都の祇園へ行くと祇園の「祇」が正字(示氏)ではなく
JIS83の字体(ネ氏)で書いてあるのがいっぱいある。

「新漢語林」で引いたら、祇・祁は「ネ」の方も「示」と同字になってた。
つまり、JIS字体は俗字という扱いと違って、「同等に用いられてきた字体」とされてた。
「ネ」の示偏はかなり古くからあるのかな。

ていうか、楷書だったら「ネ」だろ。

結局しめすへんの話になってる……。

木簡に書かれた漢隷だとだいたい「示」のようだけど、>>656 が
いうように楷書は昔から「ネ」がふつう。薦季直表（３世紀）の
「神略」の「神」はすでに「ネ」になっている。
ttp://www.nisk.jp/shodokisochishiki/shodojinbutsujiten/img/no03_ph_02_l.jpg

ttp://it.nikkei.co.jp/pc/news/index.aspx?i=2005121203753da
漢字12万字表示可能・東大教授らが世界最多のフォント集
東京大学の坂村健教授らは、約12万字からなる世界最多の漢字フォント集を制作した。
パソコンソフトに応用すれば、普段使わない難しい漢字や古い漢字を
パソコンで簡単に表示できるようになるという。
14日からソフト開発会社などに無償公開する。

懲りない人だ。

まあ、フォントは利用価値もあるからいいんじゃないの?
Unicodeとのmapping tableはあるのかな。

東大・坂村研究室、約35万文字の漢字フォントを無償公開
http://pcweb.mycom.co.jp/news/2005/12/13/023.html

>>661

>「宋明異体字」が34,499字
>「金文釈文文字」661字

を使うことによってどうして

>戸籍データベースの統合

の問題が解決するのか教えてくれ。

文字数にこだわられてもな。
品質ってのも重要なんだけどな。

なんかこう、
かゆい所に手が届かなくてイライラするってカンジだよな。

加藤弘一って有名なの？
何か、今授業で文字コード熱く語ってるんだけど。
JIS X 0213を潰した戦犯の一人として芝野に恨まれてるって言ってる。

>>665
南堂センセが有名だというような意味では、確かに有名。

>>665
文字コード界の困ったちゃん。
南堂なみに電波なら害はなかったのだろうが、中途半端にまともなのが
困ったところ。

サイトにあるインタビューにはいいのがあるね。

>>660
GTとUnicodeのマッピングなら
http://www.open-text.com/download.htm
のCODETBL.LZHから作れそうだけど、Extension A/Bに対応する部分はない。

Unicode 5.0β
http://www.unicode.org/versions/beta.html

日本に直接影響しそうな変更は今のところなさそうだが、

このスレの住人的に char と wchar_t ってどうなの？

typedef unsigned long long wchar;

#define char const wchar* const* const

>>670
バージョンアップ早いねえ。

>672
俺これでいいよ
union {
char utf8;
char jis;
char euc;
char sjis;
} kyarakuta;

もうこうしない？

せめてunsignedは付けてくれ。

>>675
こう？

unsigned union {
char utf8;
char jis;
char euc;
char sjis;
} kyarakuta;

ああ、もうそれでいいや。

UTF-8＝国際連合

>>674-677
クスッた。でもガ板には貼らない。

unsigned union カワユス

某所の情報によると
Windows Vistaの新しいCTPではメイリオのデフォルト字形が変わっていて
>>256-あたりの問題は解消しているらしい。
ただしＭＳ ゴシック/明朝には相変わらず新しいほうの字形しか入っていないらしい。

Shift-JISは誰が発明してたかが一部blogで話題になってるね。
http://slashdot.jp/~yasuoka/journal/334730
http://d.hatena.ne.jp/ogwata/20051229/p1
http://spaces.msn.com/members/furukawablog/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry#comment

以下古川語録。

「それがまぎれもない史実であることは、当時のマイクロソフトの本社の廊下に256x256の升目と紙に切り抜いたブロックを紙片を
ずらしながら紙と鋏でマッピングの配置を山下さんが考え、それに対する助言をアスキーの西さんや、古川が求められた記憶があります。」
自分の脳内にあるから「史実」であると。古川氏ﾃﾗｵｿﾛｼｽ。

「99.99%の確立で、MSAの手書き漢字CP/Mのコード体系なる文書があるとすれば、それも山下さんの起草したものではないかと推測します。」
99.99%で論文は剽窃（他人の論文を自分の名前で発表）と断言。古川氏ﾃﾗｺﾜｽ。

確率と確立を書き間違えている文章に信憑性はない。
これが定説。

> それがまぎれもない史実であることは、〜記憶があります。
とか日本語として変だし。
つーかシフトJISの発明者なんて別に名誉でもない(むしろ孫子の代まで
文字コード関係者から祟られそうな)称号なんてどうでもいいわけだが。

「本人が言ってるのだから剽窃は史実ニダ! 謝罪と賠償を請求しる!」ってことですか。
# むしろわれわれ(誰?)が謝罪と賠償を請求したい
# 3種類の文字コードに対応させたり円記号問題を回避するために
# どれだけのコストが無駄になってきたことか

よくまぁ、非関税障壁として訴えられなかったもんだw

TRONは訴えられたけどなw
やっぱ政治力の違い?

MicrosoftのほうはMS漢字コードと呼び、デジタルリサーチのほうはシフトJISと
呼び、漢字スペースを漢字用のコードで表現するか20H２個で表現するかの
違いがあると本で読んだ気がする。
MS漢字コードは漢字スペースを20H２個で表現し、シフトJISは漢字スペースを
漢字用のコードで表現すると書いてあった記憶があるが、実際にMS-DOSを使って
みると漢字用のコードを使っていて「あれ？」と思った記憶もある。これは
古川 享 ブログでの話とは逆だ。
その本はアスキー出版のMS-DOSエンサイクロペディアだったような、
ちがったような、日経BYTEだったかも、あいまいな記憶しかない。
NECのPC-9800のMS-DOSのマニュアルには漢字コード体系についての名前が
見当たらなかった。Microsoft以外の人がMS漢字コードと呼んでいただけかも
しれない、一方デジタルリサーチ側は自分たちのコードにシフトJISという
名前を付けたのではないかと憶測でものを言ってみる。
で本当はどうなの？
　　　　　　　　名前　　　　漢字スペース
Microsoft　　　　　？　　　　　？
デジタルリサーチ　？　　　　　？

小形氏が『「シフトJIS」という名称を考えたのは、どなたなのでしょうか？』
と聞いているので回答があるといいなあ。

688です。名前の479は間違い（別スレの名前）でした。

> (略)と本で読んだ気がする。
>>682の安岡センセイのblogに思いっきり書いてありますがな。
チラシの裏でもせめて読んでから書けば?

つまり、MSAはディレクトリ区切り記号としてのバックスラッシュを意識する必要がなかった。
#CP/M(86)にディレクトリの概念がない上にUnixではスラッシュなのだから蓋し当然である。

当時はA-MSでさえディレクトリ名に漢字を使うことは想定外だったのだろう。
仮に想定していたのなら、その時点で対策をとったはずだ。
想定しつつ対策しなかったとすれば、無能である。

いやCP/MやMS-DOS 1.0ではディレクトリの存在自体が想定外でしたから

C言語がはやりだすのももっと後の時代になってからだしな

ちょいスレ違いかもしれんが質問
iconv 関数の使い方がよくわからんで困ってるんですが
GNU iconv の使い方が纏まっているサイトかMLか掲示板ってないかしら？
iconv 関数から -1 が帰ってくるのに errno が 0 になってたりでわけわからんちん

自己解決
ここでどうにかなりそう
ttp://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/index.html
スレ汚しスマンコ

>>694
ぐぐればman pageとかひっかかるのに。
他にはThe Single UNIX(R) Specification, Version 3とか。
http://www.unix.org/version3/online.html

>>694
errnoってのは、システム絡みのエラーですよ。カーネルとか。
strlen(3)みたいな関数はerrno使わないんです。

>>696-697
ありがとうございます
解決できたので、ご報告までに

Windowsの環境でiconv.dllからiconv関数を呼び出していたのですが、
iconv.dllはmsvcr71.dllのerrnoを設定していて、
呼び出し側はmsvcr80.dllのerrnoを見ていたのでうまく動作できていませんでした
呼び出し側もmsvcr71.dllからerrnoを取得するようにすることで正しいerrnoを取得できるようになりました

ホント、スレ汚しですいません

>>697
つ http://www.linux.or.jp/JM/html/LDP_man-pages/man3/iconv.3.html

X0213:2004の2-94-5のUCS対応がU+29FCEで例示字形がU+29FD7に
なってい.る件、どう解釈すれば良いのでしょうか。

JISとしてはUCS対応もU+29FD7にしたかったようですが、日本提案で
U+29FCEを追加させ、10646:2001が発行された後で気付いたという
間抜けなのでISOに拒否され、X0213で包摂しろという話になったよう
ですが、2004改正では括弧付きだったUCS対応がU+29FCEになった
だけで、包摂規準は追加されていず、例示字形も変更されていない
ようです。デザイン差なのでしょうか。

そもそもUnicodeはJIS X 0213の包摂規準にないような包摂も行ってるから
JIS X 0213の立場ではUnicodeがどんな例示字形を使ってるかは関係ない。

ちなみにAJ1-6はどっちも同じグリフを割り当てている。
Mac OS X 10.2のヒラギノはU+29FD7にはグリフが入ってるけどU+29FCEには入って
ない。これTigerあたりだと解消されてるの?

Simsun-ExtBやMingLiU-ExtBだとU+29FCEとU+29FD7に字形差がない（両方とも予鳥）。

字形の差
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=29FCE
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=29FD7

UCS対応をU+29FD7に変更したいという申請
http://ra.dkuug.dk/JTC1/SC2/WG2/docs/n2334.pdf

10646の2001版と2003版の違い（最後のページの右上）
http://www.cse.cuhk.edu.hk/~irg/irg/CJK/IRGN972_CJK_B_FontIssues.pdf

なお、2001版の最終ドラフトは2003版と同じ字形だったようです。

>>701
U+29FCEがU+29FD7の字形（JISの字形）を包摂すると考えるのは
無理だと思います。又、JISがU+29FCEとU+29FD7を包摂する為には
新しい包摂規準が必要だと思います。結局、現状のJISとU+29FCEは
違いに包摂されない別の字というになります。

そんなこと言われても規格で(JIS側、Unicode側ともに)U+29FCEに対応するって
明言されてるし。つーかN2324にはなんで間違いが生じたのかという肝心な点が
書かれてない。

以下JIS X 0213:2004の解説からの引用。
> この規格の2000年版の原案作成委員会では，もともと，2-94-5の字体として，この版の字体と異なる
> 形を用いていた。その字体に基づいて，この規格の2-94-5の追加のための国際提案を，ISO/IEC 10646を
> 担当するISO/IEC JTC 1/SC2/WG2のもとでCJK統合漢字を担当するIRG（Ideographic Rapporteur Group）
> に対して行い，国際的に承認された。それが，UCSの00029FCEである。
> しかし，この規格の2000年版の原案作成委員会は，原案作成作業の最終段階で，この規格の2-49-5を
> 現在の形に変更した。これは，偶然にも，00029FD7の形と一致していた。
> ISO/IEC JTC 1/SC2/WG2を担当するJSC2は，この状況を誤りとして認知し，00029FCEと00029FD7と
> を統合することによって訂正する可能性について，WG2 に問題提起を行った（ ISO/IEC JTC
> 1/SC2/WG2/N2334参照）。しかし，審議の結果，UCSと各国の国内規格との対応関係を変更することによ
> る実装上の混乱を問題視し，UCSの符号及び各国の国内規格（この規格を含む。）との対応を変更しない
> というWG2の基本方針を，この場合にも適用することが確認された。
> この規格が規定する2-94-5とUCSとの対応は，国際規格との整合性の立場から，WG2の決定に合わせ
> たものである。

N2353で却下されたときの回答。
http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/n2353.pdf
> Mr. Mike Ksar - We will have to reject this Corrigendum request. JIS X0213 has
> changed the shape in almost non-distinguishable way. We recommend to Japan
> that these characters be treated as glyph variants and not change the current
> Part 2 source mapping.

以下も参照。
http://hp.vector.co.jp/authors/VA000964/pubrev03.htm

N2353は引用だけじゃなくてちゃんと該当部分を全部読んでみることをお勧めする。

結論:
・JISの2-94-5とUCSのU+29FCEの例示字形の違いは、UCS的にはglyph variants
・しかしUCSの例示字形をそのまま実装すると、JISに適合しない(包摂規準がない)
・実際各社のJIS X 0213対応を主張する実装はそのまま実装していない(>>701-702)

「UCS的に glyph variants である」ではなくて「JIS的に glyph variants に
しろ」と言っているように思えます。根拠は、UCSのUCSのU+29FCEの字
形を変更する提案が拒否（無期限保留）されていることです。U+29FCEは
日本起源なので、UCS的に glyph variants であるなら、日本の都合で字
形を変更しても構わない筈です。U+29FCEとU+29FD7の字形を同じにして
いる実装はUCSに適合しないのではないでしょうか。

私も今さらUCS対応を変更して良いとは思えません。やはり、JISの例示
字形をU+29FCEに合わせ、包摂規準を追加してU+29FD7の字形も包摂
するのが正しい処置ではないでしょうか。或いは、U+29FCEの字形には
堪えられないというのであれば、2-94-5を幽霊文字にして、改めて正しい
文字（U+29FD7相当）をJISに追加するべきかもしれません。

Shift-JISコードだとさぁ、1バイトコードは半角、2バイトコードは全角って文字の幅
簡単にもとまるけどさぁ、当たり前だけどUnicodeは文字の集合とコードポイント決めてるだけで､
文字の幅に関して規則なんかないんだよね。フォントの問題になるのかな？
あぁ、エディタ作る時、カーソル移動の処理で面倒だな。
WindowsでもGetStringTypeExで半角か全角かなんて、正確に判別できるのか謎だ。

>>707
そもそも、ShiftJISで1:2になると思う方がアナクロ。
プロポーショナルフォントだとそうならないからこそ、AAが作れるとも言える。
現に最近のGraphicalなIDEはプロポーショナルフォントを正しく使ったエディタを装備している。
#プロポーショナルフォントを等幅に配置するエディタもあるけどな。

>>708
プロポーショナルの事は既に論外で、忘れてた。
つか、最近のプロポーショナルを使ってIDEって例えば何よ？調べてないけどVisual Studioの事？Eclipse??
でも、プログラミング用のエディタでプロポーショナルに完全対応しててもなんかメリットあるかね？？
一般の文章書くならいいかもしれんけど。

メリット? 勿論、英語が読みやすいことだな。
記号だらけのアセンブラやperlならいざ知らず、それらでさえコメントを書くことを考えれば
プロポーショナルの恩恵は大きいと思うが。

>>707
GetStringTypeExの全角半角の判定は単に予めどれが全角でどれが半角か決められているだけでは？

一応は基準があります。
http://www.unicode.org/reports/tr11/tr11-14.html

これを読むとマイクロソフトの変則マッピングを支持したくなりますが、
X0213にマクロンやチルダが追加（X0208からある上線とは別に）が
された時点で破綻しています。

ユニコードの全角マクロンが鬼子ですね。X0201でチルダと同じに
置かれているし、訓令式ローマ字表記はマクロンを多用しているので、
西洋人が勘違いするのも無理は無いのですが。

X0201でチルダと同じに「位置に」置かれているし

X0208の上線の位置も単なる幾何学記号なのか変音符なのか微妙。

PHP には
mb_strwidth -- 文字列の幅を返す
ttp://jp2.php.net/manual/ja/function.mb-strwidth.php
なんてのが

原規格主義の人はISO/IEC 10646:2003 Amendment 1 を購入して、29FCE で検索してみると
何かいいことある「かも」。　買うの嫌だという人はN2926あたりで同じキーで検索すれば・・・

>>704
解説ではもってまわったことしか書いてないけど、要するに、JIS X 0213の某委員が、規格出版直前に突然、「えい♪」と
2-94-5 の字体を独断で変えたんらしいんだな。するとそれが、たまたまU+29FD7の形と一致してしまったと。

慌てた国際担当の委員の人が、何とか10646の出版規格に記載（電子）されている対応関係を変更できないか、と
国際委員会にお伺いをたててみたけど、「一度決まった対応関係は絶対に変更できんのじゃゴルァ。
変えるなら対応じゃなくて字形の方だゴルァ」と却下されたらしいんだな。
で、それは至極もっともなんで、すごすごと引き下がったと。

ところが某社のＯＳ開発者は、この一連の経緯の文書を中途半端に読み、また実際の字形を見て、てっきり2-94-5は
U+29FD7になると早とちりしてしまい、自身のＯＳフォントにそのコードで文字を入れてしまったんだろうな。
（この誤解を助長するような某出版物も出てしまったこともあるけど。）
そのＯＳは当時、たまたま「先進的に」JIS X 0213 の対応を謳ってたし、引きずられて誤解した人もいたんだろうな。

しかし粛々と改正作業はすすみ、今回の10646改正で、一応、この件はカタがついた、と。こんなところじゃない？
同じ字形の文字が複数個あるのは気持ち悪い？何を今更。　よーくExt Bを見ると、他にもほら、あちこちに・・・orz.

> 根拠は、UCSのUCSのU+29FCEの字形
> を変更する提案が拒否（無期限保留）されていることです。
これのソースは? >>715によれば2003 Amd.1で訂正され「た」みたいだけど

> 2-94-5を幽霊文字にして、改めて正しい
> 文字（U+29FD7相当）をJISに追加するべきかもしれません。
これ以上ISO 2022系の規格を延命する必要はないと思うが
やるならヒキヅナの正しい文字を追加してもらいたい

そういやExtension Bをマルチカラム化するって話はどこに行ったんだろう
満場一致で決定してたような気がするんだが

> 同じ字形の文字が複数個あるのは気持ち悪い？
気持ち悪いだけでなくて最近だとフィッシングの問題があるな
4万字分の危ない文字のテーブルを持つのは実用的じゃないし
どうしたらいいのやら

多言語化なんかやめてしまえばよい

英語圏のインテリどもに1ヶ月でいいからsjis使わせよう
全角のカタカナあたり空けてみっちり
極東の猿に同情してもらおう！
バイト列を丁重に持て成せ！

意味わからん

Thanks >>715

| > を変更する提案が拒否（無期限保留）されていることです。
| これのソースは? >>715によれば2003 Amd.1で訂正され「た」みたいだけど

「無期限」ではなかったようですね。Amd.1は気が付きませんでした。
（Amd.1の発行日は2005月11日18日）

それならそうとX0213に10646が改正される予定と書いておいて欲し
かった。X0213:2004の発行から一年近く不整合になっていたのは
確かだし、X0221で考えると今でも不整合のままなのでは。

とにかく、すっきりしました。もう一度、Thanks >>715

>>722
X0221-1:2001にはExt.Bが含まれていないけど、今改正中のX0221には
Amd.1は反映されていないはずだから「これから」不整合になりそう。
(それともどうにか突っ込むのかな?)
日本独自の解説に期待しましょうか。X0213対応の日本語レパートリも
(ようやく)作られるはずだし。

| X0221-1:2001にはExt.Bが含まれていないけど、
はい。そうでした。

もう一件、前から疑問に思っていることがあります。これは他所で
聞いた事が無い話なので、ひょっとすると、指摘するのは私が最初
かもしれません。

面区点1-11-60（合成可能なグレーブアクセント）は、普通、単純に
U+0300にマッピングすると思います。ですが、X0213の合成可能文字は
現在位置の前進を伴わない文字とされているので、修飾される文字の
前に置くものだと思います。一方、U+0300は修飾される英字の後に置く
ものです。JISとUCSの間で変換するとき、順序を交換しなければ
ならないような気がするのですが、そういう事をしているのは見た事が
有りません。私の思い込みでしょうか。

U+0300も(実装されていれば)現在位置は前進しないよ。
左ベアリングがマイナスなだけ。
確かに現実の活字で左ベアリングをマイナスにすることは不可能だと思うけど

>>724
>ですが、X0213の合成可能文字は
>現在位置の前進を伴わない文字とされているので、修飾される文字の
>前に置くものだと思います。
そんなことない。

>>724
「現在位置の前進を伴わない文字」ってのはnon-spacing characterと同義で、
Unicodeの結合文字も（つまりU+0300も）non-spacing characterの一種。
つーわけで「現在位置の前進を伴わない文字」という用語には
「基底文字の前に置かれる」なんて意味は含まれていない。

X0213の合成文字の左ベアリングがマイナスであることを、UCS対応以外
の記述から確認（又は推測）することは出来ますか。

#
そうでないという記述も見付けられないのですが、ユニコード以前は
non-spacing文字をspacing文字の前に置くのが常識だったと思います。
それを明文化したものとして ISO 6937 ((CCITT T.51) がありますが、
残念ながらネットでは見られないようです。下記URLの4.1の注釈で、
6937のアクセント文字の配置が10646の逆であることが述べられて
います。

http://www.w3.org/TR/1999/WD-charmod-19991129/

X0213と6937が同じだというつもりはありませんが、X0213のUCS対応
のみを根拠にして、non-spacing文字の配置が従来と逆になると判断
するのには少し抵抗があります。

6937はタイプライターでの実装を想定してるから。
>>725でも書いたけどタイプライターで左ベアリングをマイナスにするのは
不可能でしょう。
その後、テキストVRAMでは重ね打ちが不可能だから8859になった。
> ユニコード以前は
X0213ってUnicodeよりぜんぜん後だし。
でもそう言われてみると確かに具体的な合成のやり方が書かれていない
気がするな。97JISの解説で「合成可能といいつつ合成の実装方法が不明」と
過去の規格票を批判してたのはなんだったんだ?

芝野センセイによると6937はタイプライターモデルで10646は活字モデルなんだそうな。
http://libsys.lib.keio.ac.jp/proc020125/naiyo020125_1.html
>>725で活字では云々と書いたのはスマンありゃ嘘だった

>>708
プロポーショナルフォントに対応すること自体は大いに結構なのだが、
その副作用で等幅フォント使ったときに上下の文字位置がずれるのは
勘弁してほしい。
Eclipse とか Eclipse とか Eclipse とか。

>>731
そんなに嫌なら使うなよ。

この場合の使うなというのはEclipseを? プロポーショナルフォントを?

コンピュータ

Eclipseのコードフォーマットは全角半角問わず指定した文字で折り返すので
マジ使い物にならん

> 指定した文字で
指定した文字数で

http://pag.csail.mit.edu/~adonovan/hacks/eclipse-emacs.html

>>737
スレ違いにレスもなんだが、これ使いものになるならありがたいな。

>>728
>X0213の合成文字の左ベアリングがマイナスであることを、UCS対応以外
>の記述から確認（又は推測）することは出来ますか。

いや、0213が規定しているのは「合成可能」というところまでで、
具体的な合成方法は規定していない。

「合成する場合に基底文字の前か後かがあいまいだから
明確化したほうがいいんじゃないか」という話は5年以上前に
某MLで出て、某オブザーバーが委員会に持ち込んだが、
結局訂正票には反映されなかったようだ。

どうせ誰も既存のシフトJISのシステム上で合成なんか実装しないと
思ってるんだろうな

>>728
JIS X 0213:2004の例えば1-11-36→<00E6,0300>と対応させた例に基づくと、
X0213は、合成列では基底文字の後に結合文字を並べるとする
X0221の規定を踏襲しているものと推定できるのでは?

みんな UNICODE を utf8 で使え。メールはそれを Base64 にして送れ。

以上。

なんでwindowsのunicodeはutf-8じゃないんだ？

UTF8を扱えるほど優秀なプログラマが居ないからであります、サー！

>>743
当時はもう1byte文字２byte文字の区別が要らなくなる。
全て1文字は2byteで統一されると信じていたから。

UTF-16 は もう さよならなの?

UTF-16はいいけど、Windowsの古いUnicode対応部分はUCS-2だろ?

WindowsXPでサロゲート対応したらしいけど、面倒くせぇなぁ。
可変長面倒くせぇなぁ。
でさぁ、OSがUnicode対応したのはわかってるけどさ、XPで標準でインストール
されるUnicodeフォントってどのくらいの文字数カバーしてんのかな？？
やっぱ、Unicodeにアプリも本格対応しだすのは、メイリオ搭載のVistaからかな？？
つか、DBアプリでさDB側でUnicodeのキャラクタセットってどのくらい使われているのかな？
やっぱ、いくらDB側のキャラクタセットがUnicodeでもクライアントが表示できなきゃ意味ないよね。

その為に NLS がある

| X0213ってUnicodeよりぜんぜん後だし。

「ユニコードは妙なことをしてるんだなぁ」と思っていましたが、「昔は妙な
ことをしていたんだなぁ」って思うべきなのですね。確かに、今となっては
ユニコードが世間の常識ですね。

| どうせ誰も既存のシフトJISのシステム上で合成なんか実装しない

ごもっとも（笑）

>>748
ひとつのフォントにすべての文字を詰め込むなんて発想はUnicode 2.0時代の遺物です。
http://d.hatena.ne.jp/kazama/20041207/p2

>>751
そうだったんか、知らんかった。

Windows 2000からフォントリンクがあるからそれでとりあえずはなんとかしろ。

EUC←→SJISの変換だけができる、ごくごく小さい
ライブラリってあります？ C言語用で。

自分で書くのが一番早い

>>754
スレ違い。

>>754

単純なEUC-SJIS変換だと、片道10ステップ程度なので、ライブラリになる
ような規模ではない。で、JVC外字とかX0213とか言い出すと仕様が発散
して綺麗なライブラリーにならない。あるかもしれないけど、定番というもの
はないので、自分で書く方が利口です。

>>754
ttp://web.archive.org/web/20040220152952/http://alfin.mine.utsunomiya-u.ac.jp/~niy/algo/s/sjis2euc.html
ttp://web.archive.org/web/20040208203415/http://alfin.mine.utsunomiya-u.ac.jp/~niy/algo/e/euc2sjis.html

static inline unsigned sjis2jisKanji(unsigned char * dest, unsigned char const * src)
{
#if 0 // 仕様のまま実装した例。理解のために残す。
if (code1 >= 0xe0) {// 1バイトカナの隙間
code1 -= 0x40;
}
if (code2 >= 0x80) {// 0x7fの穴
--code2;
}
if (code2 >= 0x9e) {// 偶数ブロック
code1 = (code1 - 0x70) * 2;
code2 -= 0x7d;
} else {// 奇数ブロック
code1 = (code1 - 0x70) * 2 - 1;
code2 -= 0x1f;
}
#endif
unsigned code1 = src[0];code1 = code1 * 2 - 0xe1;
code1 &= 0x7f;// 1バイトカナの隙間
unsigned code2 = src[1];code2 -= 0x1f;
if (code2 > 0x7f - 0x1f) {// 0x7fの穴
--code2;
}
if (code2 >= 0x7f) {// 偶数ブロック
code2 -= 0x5e;
++code1;
}
dest[0] = code1;dest[1] = code2;return 2;
}
static inline unsigned sjis2eucKanji(unsigned char * dest, unsigned char const * src)
{unsigned rtn = sjis2jisKanji(dest, src);dest[0] |= 0x80;dest[1] |= 0x80;return rtn;}

UCS2<===>EUC-JPの変換表で
005c<===>5c '\'
007e<===>7e '~'
ff3c<===>a1c0 '＼'
ff5e<===>8fa2b7 '〜'
のところが
005c<===>5c '\'
007e<===>7e '~'
005c<===>a1c0 '＼'
007e<===>8fa2b7 '〜'
となっている物があったのですが、理由はなんでしょうか?

ttp://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch3_1_1

その変換表だとa1c0で \ のサニタイジングを貫通されそうで怖い

UCS<===>EUC-JP
005c<===>5c '\'
007e<===>7e '~'
005c<===>a1c0 '＼'
007e<===>8fa2b7 '〜'

微妙に誤記がありそう。UCSの005cはEUCの何になる？

>>763
多対一マッピングじゃないの? 確かJDKがそういう変換をする。
プログラミング言語なのでASCIIの範囲はそのままマップするしかないけど
それ以外は可能な限り規格票に忠実な変換をするというポリシーだった希ガス

ってEUCか。Shift_JISなら分かるんだけど

005c<===>5c '\'
007e<===>7e '~'

であれば、

005c<===>a1c0 '＼'
007e<===>8fa2b7 '〜'

はありえなくて、

005c<===a1c0 '＼'
007e<===8fa2b7 '〜'

でしょう?
そこんところはちゃんとして。

まぁ、言葉の厳密な定義なんて、決まってないかもしれんし、色々あると思うけど､
Unicode --> 文字セットを定義し、各文字に一意のコードポイントを定義
UTF-8, UTF-16, UTF-32 --> エンコーディングスキームでUnicodeの文字セットのコードポイントを
どのコードユニットにマッピングさせるかを定義。
まぁ、そんな感じに俺は言葉を使ってる。
UCS-2とかは、まだ、お勉強中。

>>764

005c<===>5c '\'
005c<===　a1c0 '＼'

なのか

005c<===　5c '\'
005c<===>a1c0 '＼'

なのか

00a5<===>5c '\'
005c<===>a1c0 '＼'

なのか

これで話が違ってくるのだが。

そもそもEUCの0x5cは円マークじゃ無いでそ。

JIS X 0201を採用しているベンダもある

yen &#a5;
backslash c;

￥ ¥ \

yensignとbackslash を適切にutf-8に移行させる方法は？

>773
究極的には自分で「適切」と思われるコンバータ書くしかないんでは。

¥と\

printf("そのコンバータの値段は¥4です。\n");

>>773

yensign と backslash というのは　yen sign と back solidus のことですか。
もし、そうなら、簡単です。

yen sign は 5c (u+005c)
back solidusは c2a5 (u+00a5)

これ以外の方法はありません。他は全て誤りです。でも、万一、yensign が
fullwidth yen sign を意味しているとしたら話が変わってきますので、そこの
ところ、もう一度、ご確認くださいませ。

というのは誤りです。

>>777
REVERSE SOLIDUSちゃいますの?

書きながら何か違和感があると思ったんだが、そういうことだったのか。

orz

>>777は釣りの類なのか？

結局>>776はどうすんだよ?

ソース内で意図的にyen使ってる奴は漢の中の漢

777です。間違えたのは素で間違えたので釣る積もりはなかったです。
でも、冗談半分、本気半分。

まじめな話、元のコードは何なのかってこと。ASCIIなのかX0201なのか。

X0201ならC的に誤り。エスケープシーケンスの逆スラッシュを円記号で
代用することはANSIでもISOでも許されていない。理屈からいうと??/と
するべきだが、これは飽くまでも理屈でしかない。

実用上、ASCIIだと思うしかない。だから、円記号はX0208の216fに書き
換えるしかない。或いは、逆スラッシュの形状が円記号に見えるフォントを
使いつづけるか。誰が見ても円記号に見えるけど、これは逆スラッシュを
デフォルメしたものなのですと言い張る。

> 誰が見ても円記号に見えるけど、これは逆スラッシュをデフォルメしたものなのですと言い張る。

MSは本気でこういうこと逝っているんじゃなかったっけ?

0x5cは見た目はYEN SIGNだけどREVERSE SOLIDUS。誰がなんといおうとも￥はREVERSE SOLIDUS。
ｱｯﾋｬｯﾋｬ!ヽ(ﾟ∀ﾟ)ﾉ

>>784
JIS Cでは「X0201を使うならバックスラッシュを円記号に置き換える」と書いてある。

「JIS X 0201の文字集合を使うから」となっているのかな?

それならShift_JISでは¥でいいということですね。
cp932ではどうなってんだ? >>785なのか?

UNICODEの日本語ソート順序、」みたいな
一見すると訳わからんものをMSは実装している。

>>787
MSの資料 Windows Codepage 932
ttp://www.microsoft.com/globaldev/reference/dbcs/932.mspx
では、字形は￥で、5C = U+005C : REVERSE SOLIDUS (YEN SIGN)と曖昧な定義になっている。

CP932のUnicodeの変換表
ttp://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
では、0x5C 0x005C #REVERSE SOLIDUSと定義。

どう表示されるかにかかわらずCP932では常に0x5cをREVERSE SOLIDUSとして扱う、でいいはず。

JISのC言語の規格を読んだことが無いので786が本当だと仮定すると、

X0201で書かれたJIS規格C言語のプログラムをX0201以外に変換する
ときには、円記号をバックスラッシュに変更しなければならない。
つまり、単純な文字コードの変換では済まず、C言語のプログラムに
特化した変換処理が必要になる。そういうゴタゴタを避ける為、
ANSIやISOは逆スラッシュと円記号の混同（欧州大陸ではアクセント
付き英字と括弧類の混同）を許していない。

ところで、ANSI準拠やISO準拠ではなくて、JIS準拠のコンパイラーって
世間に存在するのかな。

JIS X 3010 解説より

JIS X 0201で規定する文字集合の中には、プログラム言語Cの基本文字集合の要素\と~
は, 含まれていないが, この規格(JIS X 3010)では, 国際一致規格の趣旨に沿って, 元の
国際規格どおりの(\と~を含む)文字集合を採用した。ただし, ASCIIでの\と~
は, それぞれ, JIS X 0201 では, ¥(円記号)と‾(オーバライン)に対応しており,
原始プログラム中で, \と~の代替表記として¥と‾を使用して混乱が生じる
おそれはない。したがって, 処理系が, 符号化文字集合として JIS X 0201 を採用している場合は,
この規格の中の\と~をそれぞれ¥と‾に置き換えて仕様を解釈しても,
実用上は, 問題ない。ただし, ¥と‾を使って記述されたプログラムは, 規格厳密合致
プログラムではない。

>>790
ISO規格合致の処理系は JIS X 0201 で\を使って書かれたプログラムを処理
できるので「ISO準拠でなくて、JIS準拠のコンパイラー」というのは意味がない。

>>791
> JIS X 0201 で\を使って書かれた

書けへんやん

>>792
「JIS X 0201で」は「処理できる」にかかってるんじゃねえの。

>>

ちなみに、フォントをBatangやGulimにするとW横線になります。

>>791

つまり、JISのCは現実を公式に追認したということになるが、
本音はともかく、建前としては拙いのではなかろうか。
真面目にロケールを見てソース文字集合を判断するコンパイラーは
使えないかもね。

>>796
いや問題の記述はUnicodeなんて影も形もなかったC89からありますから
単にISO 646シリーズのことしか想定してないだけ

>>796
> 規格厳密合致プログラム

ってわざわざ"strictly"付けてるけど、
"conforming program"でもないんじゃないの?
¥や‾なprogramは。

昔は printf ("暴\風雨警報");　なんぞと書いたりしましたね。
「暴」の第2バイトが5Cなのですが、最初、これには完全にはまった。

そういえば DOS 2.10 の時代に「蜃気楼」というファイル名を使って
ファイルが消えてしまったこともありのした。先頭バイトE5が削除された
ファイルの印だったりするもので。今となっては遠い昔の語りぐさ。

>>799
FATは今でも生き残ってるわけだが
削除ファイルの表し方は変わったんだっけ?

ファイル名の方をいじって保存するんじゃなかったか

あれ? >>796→>>791ね。
まあ「解説」だからアレなのかな。

javaで文字列をアスキーコードへ変換方法教えて下さい

ほんとうにASCIIでいいのか？
実はCP932とかに変換したいんじゃないのか？

>>799
蜃気楼ﾜﾛｽ

先頭がE5のファイル名はディスク上では05として保存される。
で、LFNを使うと5番目のエントリは最初の一文字が05になったりして、またややこしい。

>>805
言われてようやく思い出した
ﾃﾗﾅﾂｶｼｽ

ってか日本の公用語を英語にしちゃえばいいんじゃない?

アメリカの州の一つにすればいいよね。実質そうなんだし。

>>807-808
日本語の中の人に謝れ！

>>808

んなことしたら、アメリカの首都が日本になってしまうぞ。なんたって、
GDPの1/3近くが集中しているのだからな。

日本自体はカリフォルニアやニューヨーク並かそれ以上の有力州になるが、
英語の下手な元日本人は二等国民扱いになるぞ、それ。
……十年もすれば全米でもっとも英語のスコアの高い州になりそうな気もするが。

>>803
String str = "abc";
byte[] ascii = str.getBytes("US-ASCII");

GDP で首都が決まるかよ。Ex. アメリカの都市を見よ

スコアは高くてもしゃべれない、ということになりそう…

オーストラリアなんて当時メルボルンとシドニーが首都をめぐって揉めに揉めた末に
その中間にあるキャンベラが首都になったという経緯があるくらいだしな

printf("わが国の2005年度のGDPがnになると仮定します。\n");

printf("わが国の2005年度のGDPが&#yen;nになると仮定します。\n");

ドロンするとします

ハワイ

まぁもし仮になるにしてもたぶんグアムと同じ扱いってことになるんじゃないか？
もし選挙権ありだったら日本は票全体の1/3くらいを握ることになるからすごく優遇されるぞ

>>819
アメリカの選挙、特に大統領選の方式知ってる?

日本はアメリカに常に YES なんだし選挙権いらないんじゃない？

スレタイ的にはUnicode追従という事でよろしいですね。

>>820
大統領選なら推薦人120人くらいになるんじゃない？ものすごく大きいと思うが。
まぁそうなるからもしアメリカに入るになっても選挙権はつけないとなるんだろうと言ってる。
そもそもアメリカに入るという話自体ありえないんだけどな。

もう属国だからね。

そんなに属国がいやならまずは核武装とエネルギー資源の確保をしないとなぁ・・・
あと食料自給率もどうにかしないと

自民党が政権を持つ限りアメリカ追随のまま

民主党になってもその点はほぼ同じだと思われ

民主党の歴史を考えればな。つまり属国のまま。

アメリカの属国が嫌だという人間の大半は中国の属国にしたい奴か、鎖国したい奴のどっちか

自民党で括りなさんな。田中一族だって自民党だよ。

戦争に全面的に協力して街壊してから
食料衣服もっていく日本の政治家達見てると
ちゃんと義務教育とか終えたのか心配になっちゃうよね

靖国に感情的な奴もぐるだろうか、
今って太平洋戦争の時よりもあくどいように感じる
俺は零戦で突っ込む！誇りをもて！

お願いだからスレタイを見てください。

世界征服して文字コードを強制統一スレが何か？

そりゃ中国とかモンゴルとかじゃね?
中国語は句読点が真中に来るのがどうも慣れない。なんだありゃ。

>833
まずは国内の統一からどーぞ

句読点を真中に打つのは台湾だけではありませんか。

各国毎に文字コードを統一して、
それを UTF-64 に含めよう。

UCS64じゃなくて、UTF-64なんだ。

そうやってちまちま 16→32→64 てな流れでやるから
あ、やっぱり足りね！とかってことになんだよ！
思い切っていっきに1024ぐらいまでいっとけ、な？

UTF64か。全ての人に1群（256面）づつ割り当てて自由に使わせても
1000年くらいは持つだろうな。足りなくなる前はUTF128とUTF256を
標準化すれば銀河の寿命が尽きるまで安泰というわけだ。

せっかく自主憲法制定しても、UTF-8で符号化ですか?
TRONコー(ry

>840
銀河評議会辺りから「んなローカルな文字コード使ってんじゃねーよ田舎モン」言われそうだｗ

UTF4096
UTF16384
UTF65536
UTF131072
UTF1M
UTF1G
UTF1T

もはやここまできたら文字の図形そのまんま転送してるのと同じ。

>>843
マジメな話、将来的には全部画像ファイルになるかもな。
各種記憶メディアの容量は馬鹿でかくなり続けてるし、
CP'Uに処理速度もアホみたいに速くなってればOCR処理も一瞬で終わるし、
画像ファイルならフォントがなくて表示できないだとか、
ロケールの違いでうまく表示・処理できないなんて類のことから解放されるし。

OCRした結果は何コードにするの？

>>845
UTF-1024

コードなんて内部でも必要とせず、
常に画像データで持ち比較の場合は画像類似度で判定。

文字コードに「日ペンの美子ちゃん」が追加される時代がくる

そんな英語圏の連中にとってオーバースペックにもほどがある代物は
一部の日本人の妄想の中にしか存在しません

表示と印刷に限ればPDFがすでに実現してる

検索も結構いけてる > PDF

STLPort 5.0.1をWindowsでビルドしたんだけど、UnitTestで3/329が通らない。
見てみると、std::use_facet<>のテストでのassert。

調べてみると、どうも「CP1252(Latin-1)な言語環境じゃなきゃ通らない」テストになってた。
しかも、use_facet<>の実装も間違ってる始末。

ポンド記号とかをGetLocaleInfoA()で取得した後、MultiByteToWideChar(CP_ACP)→WideCharToMultiByte(CP1252)
なんて処理を行ってる。

これだから外人は…

>>852
微妙にスレ違いな気がするぽ
もっと適切なスレに逝け

ここでいいと思う。

いや、やっぱりよくない

まあいいじゃねえかよ。
言いたかったのは「これだから外人は」ってことなんだろうから。

>>849
いや英語圏というか文字の種類が数十文字の言語にとっては
現時点でももうオーバースペックだよ。

一般人にとってはそうだろうね。
けどUnicodeなんかはベンダー主導の部分も大きくて、
英語圏のソフトウェアベンダーに取っては必要不可欠。
ドメスティックな奴は彼らにとってはわけわからんし。

英語圏の人間でも各種記号が増えるのは嬉しいんじゃないの。

¢ € £

ユニコードってのは、最初はCJKなんて含んでいなかったんですよ。
8859シリーズが増えすぎて手に負えなくなって、しかたが無いから
16ビットにしてしまえと。まあ、確かに、欧米だけならBMPだけで
間に合っていただろうけど。

bitmap にしてしまうと bmpstrcmp() とかいうイメージの比較関数を
C言語に標準で用意する必要性が・・・。(リターン値は double で
何パーセント似ているかが返される)。

BMPってBasic Multilingual Planeのことだろ･･･

ハハ。以前打ち合わせ2時間やった帰り際に>>861みたいなことを
お客さんに言われたことがあるよ。どうしようかと思ったｗ

>>862
フィッシングで釣り放題の予感

> C言語に標準で
「言語情報や字体情報はリッチテキストで表せばいい」って
絵空事を言ってる人たちが意図的に触れない点ですな。
char→wchar_tすら遅々として進まないのに
プログラミング言語の標準ライブラリとかOSのAPIがすべて文字列の代わりに
XMLのマークアップとか受け取れるようになるなんて本気で思ってる人
どれくらいいるんでしょうかね。
ただでさえ
> 英語圏の連中にとってオーバースペックにもほどがある
のに。

欧米で日本語流行らないかな
漢字をおしゃれだと思ってる欧米人も少なくは無いんだろうが
身体に亀仙人とか彫っちゃう感覚なんだもんな
意味含めて1ヶ月流行らんかな

日本語をローマ字で書く程度ならそんなに苦労はしないかも知れないが、
実際には平仮名カタカナ漢字と3種類の文字を覚え、更に漢字の音読み
訓読みを覚えなければならないので全部使えるようになるまでは英語圏の
やつらにはかなり大変なんじゃねえの?

日本はまだマシなものだ

そうか? 要するに言葉を覚えるより文字を覚えるのが大変ということだが。
まあ、中国語とかも大変そうだが。

日本語を流暢に話す欧米人はそこそこみかけるが（ＴＶでね）
仮名漢字交じりの文章をスラスラ書く欧米人は見たことないなぁ。

>>871
それがいるんだ。

中には日本好きが高じすぎて、当の日本人より詳しいのも。
希出漢字の書き順まで完璧。知識階級に多い。

夏期休暇でアメリカに行った際の出来事。
ＬＡで信号待ちをしていると 気の良さそうな２人組のお兄さんが、
「おまえは 日本人か？」と気さくに聞いてきました。
「そうだ」と答えると、「漢字のタトゥー （刺青）を 彫ったんだけど、
どういう意味か教えろよ」と言われ、差し出された腕を見ると
『武蔵』と彫ってありました。
「日本で最も有名な剣豪だよ」と伝えると 彼は満面の笑みを浮かべていました。
続いてもう一人が腕を差し出すと そこには『朝鮮』と大きく彫ってありました。
「KOREAだよ」と教えてあげた後の彼の悲しそうな顔が忘れられません。

コピペ乙

全米が泣いた

「K-1ファイターだよ」と教えてあげた後の彼の悲しそうな顔が忘れられません。

WinFX Runtime ComponentのJan CTPを入れて、Loose XAMLで
>>125みたいな指定が実際に可能である(エラーにならない)ことを確認した。
ただしXPではUniscribeが古いままなせいか、それとも単にまだ実装されていないのか、
メイリオや小塚明朝を指定しても実際に字形の切り替えは反映されなかった。

はやっているのは日本語ではなくて中国語だという説も。

中国は簡体字だろうって？

台湾も香港も、大陸系でも欧米に往来するような連中は教養として
繁体字を書けますので。

正体字か常用漢字体かは見分けられるだろう

>>879
海外の華僑は繁体字を使ってるんでしょ?

例えば、円のような字があれば紛れもなく日本語だろうけど、常用漢字体と
いっても、それまで草の根で使われてきた字を公認したものもあるので、
単純には見分けられない。台湾香港の手書きの繁体字が日本の正字体
（康煕字典体）と一致しているわけでもない。活字は示偏で手書きはネ偏
とかいうのも普通です。

UTS #37の承認キター
http://www.unicode.org/reports/tr37/
で、AJ1-6の登録マダー? (AAry

ietf-charsetsのメーリングリストがいつ行っても落ちてるんですけど
今さら新しいcharsetを登録したいやつなんかいないだろって感じですか?
http://mail.apps.ietf.org/ietf/charsets/threads.html

前に揉めたから日本人ははねてるんだろうな(w

ISO-2022-JP-3を事実上葬った太田センセイですか?
今となっては結果的にGJだった気もするが(w

So?

E・∇・ﾖﾉｼ　＜888ｹﾞｯﾄ♫

javaでISO-2022-JPからUTF-8への変換は出来るの？

Java API でって事か?

>>889
できる。

ISO-2022-JP-2でG2にISO-8859-7が指示できるのは何のため?

ギリシャ文字使うのにX0208使いたくなかったから。

>>893
JIS X 0201カナ（´・ω・） カワイソス
つーかマジでダブルスタンダードだとは誰も思わなかったのかね入れた奴らは

むしろISO-8859-5あたりが指示できない方が問題じゃないかと。

ロシヤ文字はkoi8のほうが標準だったからね。

結局ISO-2022で世界統一しようというのも日本人だけの妄想ってことだな

X11はcompound textでやっていたけどね。
ISO-2022-JP-2みたいな文字(集合)利用制限付きはうまくいかなかった。

なんでもぶっ込み型しか利用されないのよね。
ctextにしてもunicodeにしても。

ISO-2022-INTがRFCになってたらうまくいってたんだろうか

　　　 _ 　∩
　　< ｀∀´>彡　KPS9566!KPS9566!
　　(　 ⊂彡
　 　|　　　|　
　 　し ⌒Ｊ

DNSやURL w/UTF-8で、
似た文字を一つにUNIFYして正規化する、とかいうのどうなったの?

よくわからんがとりあえずnameprepでぐぐってみれ

もとはといえば最初に常用漢字とＪＩＳが違うという縦割り行政丸出しの時点で
もうだめだったな・・・

俺的には昔より最近の「印刷標準字体」にたまげた

>>903
その差を埋めようとしたのが83JISじゃないか!
何であんなに叩かれるんだ!

安易だからさ。

>>905

非互換の変更で、朝日文字を採用したからでしょ。

Unicode FA11 は崎の異体字、大→立です。いわゆる「たちざき」
この JIS コードは 7975 だそうです。
たしかに手元のブラウザで EUC-JP F9F5 で表示できます。
しかし JIS X 0213-2004 の1面89区85点を見てもみあたりません。
http://www.itscj.ipsj.or.jp/ISO-IR/233.pdf
どこを見れば「たちざき」が載っているのでしょうか？

1-47-82

>>909 ありがとうございました、無事見つかりました。
今まで区点コードとJISコードは 0x2020 の違いだけだと
思い込んでいたのですが、そうではないのでしょうか？

JISコードと区点コードの間にも Unicode との
マッピングのようなマッピングを持たなければならないのでしょうか？

>>908
> この JIS コードは 7975 だそうです。

それはNEC選定IBM拡張文字としてのコードであって、正式な（？）JISコードじゃないから。

いま、下の変換表を見てみましたところ、
http://examples.oreilly.de/english_examples/nutshell/cjkv/adobe/jisx0213-all.txt
EUC-JP F9F5 = JIS 7975 = 区点 1-89-85 = Unicode U+7CBC のようです。
U+7CBC は CJK Unified Idiograph で「憐」のつくりをへんに持ち、
「喩」の右下の二本の並行曲線をへんに持つ、変わった漢字です。

手元のブラウザで EUC-JP F9F5 は「たちざき」に見えているのですが。

>>911 え？そうだったんですか。丸付き数字とかだけかと思ってました。
ということは、EUC-JP F9F5 で「たちざき」が見えているこのコードは、
「えせ」EUC-JP ってことでしょうか？

>>913
「えせ」ってのは響きが宜しくない。

「独自拡張された」EUC-JP（JIS X 0208ベース）ぐらいが適当か。

1-89-85が﨑な文字コードと1-47-82が﨑な文字コードは別の物だよ。

>>914 >>915 わかりました。DBの統合に際して
気をつけなければと思って調査しているのですが、
どうやらJIS X 0208 + 拡張文字ベースの EUC-JP
と JIS X 0213 ベースの EUC-JP が混在しているようです。
マップを細かく切り替えながら乗り切ることにします。

うわ、eucJP-openとEUC-JISX0213が混ざっているのですか・・・がんばってください・・・。

EUC-JISX0213はJIS X 0213を見ればいいとして、
eucJP-open（独自拡張されたEUC-JP）は、
http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html
やここからいけるリンクの先をご覧になるとよろしいかと。

ところでUnicode 5.0(ベータ)でUTF-8最後の2byte領域につっこまれたNKoってどこの文字か知ってる人います？

>>913
むしろ丸付き数字はNEC拡張とJIS X 0213で互換性がある。

http://std.dkuug.dk/jtc1/sc2/WG2/docs/n2765.pdf
>Manden (or Manding) people live mainly in West Africa
>literary dialect commonly known as Kangbe ‘the clear language’, and also known as N’Ko.
これかなー

Vai script はまだなのか……

UTF-9を使うとLaten-1が1バイト、CJKは2バイトに収まるというが

>やるならヒキヅナの正しい文字を追加してもらいたい

化石レス、スマソ。それって、
http://hp.vector.co.jp/authors/VA000964/hikiduna.htm
のこと？だいたい、あそこで言ってる事って正しいの？

>>922
バイトには違いないがオクテットじゃなくてノネット(9ビットバイト)だからあまり実用的
じゃない。つーかJoke RFCだし。

UTF-9ってRFC 4042に載ったもの以外に、こんなのもあったなあ。
http://www3.ietf.org/proceedings/99jul/I-D/draft-abela-utf9-00.txt

>>923
それこそ自分の目で確かめろだ

>925
あのページって、南堂某みたいなトンデモだと思ってた。

南堂某と一緒くたにしたらあまりに失礼だ。

Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/
> 　主要な OSS (libiconv、glibc、Perl、Ruby、Python、PHP、ostgreSQL、
> MySQL、nkf など) の各ソフトウェアで、Microsoft標準キャラクタセット
> をシフト JIS符号化方式、日本語EUC符号化方式、7ビットJISコード符号化
> 方式の各々 の間で相互変換できるようにする事を目的とします。

Windows-31JはともかくISO-2022-JP-MSは混乱を新たに追加するだけだと
思うがなあ…。

>>928
OSCや、
http://www.ospn.jp/osc2006/modules/eguide/index.php?begin=1142521200&end=1142607600&msg=1
YAPCで発表もなさいますね。
http://tokyo.yapcasia.org/blog/ja/sessions.html

そうだ！南堂某にあやまれ。

ISO-2022-JP-MSって、変換に問題が生じるから新しく作るってことか？
なんか考え方がunicode的というか傲慢というか。
実装だけでなくガイドラインもとか言ってるから自分たちの提唱する
方式が支配的になればハッピーというつもりだろうが、
それなら最初の問題の立て方の段階から合意を形成する必要があるよね。

>>932
私の代わりにISO-2022-JP-MSが本当に必要なのかMLで議論してきてください（ぉ

まぁ、この手のプロジェクトの必要性自体は認めますけど。
Perl/EncodeでEUC-JP使っていて、U+301C周りではまったことあるし。

辛辣ですな(w
http://slashdot.jp/~alp/journal/348517
http://slashdot.jp/~witch/journal/348491
http://slashdot.jp/~oku/journal/348499
> Unicode.org の変換表は、4.0.1 で規格に取り込むかたちで完全に策定されています。
これ本当? OBSOLETEになったEASTASIAの変換表も更新されて
取り込まれたりしてるの?
>>933
面倒なので勝手にやってもらって勝手にコケてもらうことにします。
自分の関わってる某OSSプロダクトでISO-2022-JP-MSをサポートしろとか言われたら
全力で拒否するけど。

ISO-2022-JP-MS はともかく、CP932/CP1932/eucJP-ms についてはこけることはないでしょ。
だって、もう八割方終わってるし。

コケル、ってのは広まらない、ってことでそ。

> CP1932
CP51932?

>>921
日本人でこれ使いたい人がいるとは・・・

http://lucia.itscj.ipsj.or.jp/itscj/servlets/ScmDoc20

を見ると、Amendment 3にvai が入ってるね。まだDAMレベルの投票だから、あと
１年半待て。

iso-2022-jp-ms なんてデファクトでしょ。
Outlook Expressで、何の躊躇いもなく「�@」とか送ってくる輩がゴマンといるし、
gooだのyahooだののwebメールで textarea に入れた「�@」もメールでは同様に
エンコードされる。

ただＵnicodeと関わらない普通のOSSはサポートなんて考えなくていいんじゃないかな。
iso-2022のコードを、unicodeに変換するルーチンはサポートして欲しい気もするけど。

いちいちメールに半角カナ中点とか�@とか使う連中に「使うな」と注意してるとこっちが
木印扱いされかねない昨今だからなぁ。

すみません、ここはservletのURLでしたね。
http://std.dkuug.dk/jtc1/sc2/
このリンクから“REGISTERS & SEARCH”をクリックして、
vaiで検索すると、n3817が出てきます。

どうしてISO-2022-JP系である必要があるのか分からない。

変換テーブルの非互換を増やさないため、
典型的な変換テーブルを持った文字コードを増やすというのは分かるけど、
文字集合が違うとあらたに文字コードが増えただけなのでは?

>>939
iso-2022-jp-ms と cp5022x は違うよ。
おまけに cp5022x は WideCharToMultiByte と ConvertINetUnicodeToMultiByte で同じじゃなかったりする。
WideCharToMultiByte は補助漢字使えるけど、ConvertINetUnicodeToMultiByte は使えないとか。

iso-2022-jp-ms と eucJP-ms も補助漢字サポートする/しないで
一貫性なかったりしてなんだかなー、な感じがある。

>>936
本家libiconvに取り込まれれば、それだけで実装としては広まるよね。
まぁ、ユーザが知らなければ駄目なわけですが。

>>937
すみません、CP51932ですね

>>939
発想がiconv的なのだと思います。（Unicode的という声もログにありましたけど）
iconvは定義外の文字を投げるとエラーを出す実装が多いので、
いわゆる機種依存文字は変換できない（と思います）。

変換するためには、
* "iso-2022-jp" でいわゆる機種依存文字も許容するようにする
* いわゆる機種依存文字を許容する別の名前を作る
の二種類があり、後者を取った、と。

iconvのようにエラーを出さないルーズな実装では、
iso-2022-jpのaliasにiso-2022-jp-msをつくるだけ、の場合もあるかもしれません。

nkf とかだと、いわゆる機種依存文字を許容するかどうかはオプションで指定などと逃げられますが、
iconvだとそうもいきませんからね。