- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 52 名前：デフォルトの名無しさん mailto:sage [03/09/13 17:15]
- >>51
Windows-31J エンコーディングを使用したか?
- 53 名前：デフォルトの名無しさん mailto:sage [03/09/13 17:35]
- >>52
使ってるのはShift_JISです。
Windows-31JってMS932のことでしたっけ？ 試してみます。
- 54 名前：デフォルトの名無しさん [03/09/13 17:55]
- 必読ページ
www.ingrid.org/java/i18n/encoding/
- 55 名前：デフォルトの名無しさん mailto:sage [03/09/13 19:16]
- >>53
Windows-31Jでやってみました。が、ダメでした。
しかしおかげさまで問題を切り分けることができました。
どうやら途中に使っているJDBCドライバの問題っぽいです。
そっち方面検証してみます。お騒がせしました。
- 56 名前：デフォルトの名無しさん mailto:sage [03/09/13 20:27]
- データベースがEUCだったりするとたいがいうまくいかないね。
SJIS => UNICODE -> EUC -> UNICODE => SJIS
途中で、変換できないコードが混じっちゃう。
最近は、データベースの文字コードはできるだけUNICODEにしている。
それができないときは、SJIS。
JavaのWebアプリの場合だけど。
- 57 名前：デフォルトの名無しさん mailto:sage [03/09/14 01:00]
- データーベースがUnicodeじゃないとIEのsize属性での長さチェックと
うまくかみ合わなかったり
どのみちサーバ側でチェックをする必要はあるんだけどなんか嫌
- 58 名前：デフォルトの名無しさん [03/11/03 22:37]
- ICU使ってます？
- 59 名前：デフォルトの名無しさん [03/11/03 22:42]
- 使ってます
- 60 名前：デフォルトの名無しさん [03/11/03 22:59]
- 日本語でUnicodeならUTF-8よりUCS-2そのままのほうがかえって
メモリ消費少なくなったしせえへん？CJK共用漢字コード領域に
UTF-8の3バイト文字あったっけ？
- 61 名前：デフォルトの名無しさん mailto:sage [03/11/03 23:50]
- >>60
たしかにUTF-8だと漢字や記号の一部、半角カナ類は全部3バイトだね。
でも、日本語だけならいいんだけど、ASCII文字も扱いたい場合は
UCS-2の16ビット表現はASCII部分の文字も2バイトになっちゃうからねぇ。
- 62 名前：デフォルトの名無しさん mailto:sage [03/11/04 01:31]
- >>13
XMLの標準がUTF-8でさらに、
欧米人は本当はIS-8859-1しか使う気がなく
Unicode使ってもせいぜいUTF-8しか使わんのでしょう。
欧米系以外の外国人も英語を標準言語としており、
プログラミングなどの才には変数名などは英字のほうがわかりやすく
扱いやすくASCIIコードで事足りる記号が多いので、
無理してUTF-16を使う気を起こす人が少ないのでしょう。
まさに自分もこれに当てはまります。
- 63 名前：デフォルトの名無しさん mailto:sage [03/11/04 02:46]
- >>62
> 欧米人は本当はIS-8859-1しか使う気がなく
そんだったら、WinもMacもUnicodeサポートしてないんじゃないの？
逆に、超漢字は、BMPしかサポートしてないというお粗末感がある。
ちなみに、Unicode Consortiumは、アメリカにあるよ。
ISO-8859-1はヨーロッパじゃあもう使いたくないでしょう。
Euroが入ってないと。
- 64 名前：デフォルトの名無しさん mailto:sage [03/11/04 05:17]
- 最近じゃ代わりに ISO-8859-15 を使うとかどうとか。＜euro
プログラム言語では内部コードが UTF-16 てのも珍しくないけど。
- 65 名前：デフォルトの名無しさん [03/11/22 19:59]
- ICUのDLLがでかすぎるのだがUnicodeと日本語関係の文字コードに限定したサブセット版って誰かビルドして配布してくれてたりしないのかなあ
- 66 名前：デフォルトの名無しさん [03/11/22 20:07]
- >>65
集中治療室？
- 67 名前：デフォルトの名無しさん mailto:sage [03/11/22 20:34]
- >>63
非英語圏は英語圏産のソフトウェアの輸出先だからね。
日本が輸入最大手。
- 68 名前：デフォルトの名無しさん mailto:sage [03/11/22 22:14]
- UTF-8って内部処理には最悪なんだって。
文字列の末尾から先頭に向かって文字を検索できないだろ。
UNIX系のgccでは標準ライブラリは一文字四バイト固定のwchar_tだし、
MSVCは二バイト固定のwchar_tなんだよね。
- 69 名前：デフォルトの名無しさん mailto:sage [03/11/22 22:40]
- 可変長なものが内部処理には向かないのはあたりまえ。
- 70 名前：デフォルトの名無しさん mailto:sage [03/11/22 22:46]
- >>68
wchar_tはワイド文字なんだからutf-8でないのは当然なので、
wchar_tがutf-8でないことはutf-8を否定する理由にならない。
あと、末尾から先頭に向かって検索しづらい(できないわけじゃない)のは
utf-8に限った話ではない上、あるシステムが文字列を末尾から検索する
必要があるとも限らないし、それ以外のメリットとデメリットも色々ある。
もっと勉強して出直してきて。
- 71 名前：デフォルトの名無しさん mailto:sage [03/11/23 23:19]
- コード順でソートすると一部言語が混ざるのが不味い
- 72 名前：デフォルトの名無しさん mailto:sage [03/11/24 17:41]
- >>68
> 文字列の末尾から先頭に向かって文字を検索できないだろ。
ﾊｧ? そりゃシフトJISやEUCの話だ。
どこのバカにそんなデタラメ吹き込まれた?
>>70
UTF-8は単なるバイト列として末尾からでも検索できるはずだが。
- 73 名前：デフォルトの名無しさん mailto:sage [03/11/24 17:56]
- >>72
>>70はできないとは書いてないけど？
可変長だから末尾から「文字として」検索するのはちょっとややこしめ、という程度の意味で書いた。
- 74 名前：デフォルトの名無しさん mailto:sage [03/11/24 19:32]
- >>73
UTF-8のエンコード方式を理解してないだろ？
- 75 名前：デフォルトの名無しさん mailto:sage [03/11/24 21:25]
- > 「文字として」検索する
必要がないのがUTF-8の特長なんだが。
どーでもいーけどこの程度の初歩的な知識もないくせに
知ったかぶってUnicode叩く奴大杉
- 76 名前：デフォルトの名無しさん mailto:sage [03/11/24 21:30]
- まあUnicodeはクソだし。
- 77 名前：デフォルトの名無しさん mailto:sage [03/11/24 21:52]
- で、そういう奴に限って何がどう糞なのか説明しない。
たまに説明したかと思ったら>>68みたいな単なる嘘だったりするし。
- 78 名前：デフォルトの名無しさん mailto:sage [03/11/24 21:58]
- 16ビットにおさめようと思って作っていた時点で糞です。
糞に何をかぶせようと糞にかわりはありません。
- 79 名前：デフォルトの名無しさん mailto:sage [03/11/24 22:17]
- それじゃあたった8,836文字に収めようとしたJIS X 0208や
シフトJISの都合だけで11,280文字に詰め込もうとしたJIS X 0213なんて
話になりませんね。やはり時代はちょー漢字ですか?
- 80 名前：デフォルトの名無しさん mailto:sage [03/11/24 22:17]
- Unicodeも糞だがJISも糞だ。
それを弁えて何とかするのがエンジニアだろ?
糞だ何だと言い訳する暇あったら調べるなり
なんなり、もっと悪足掻きしろよ。
- 81 名前：デフォルトの名無しさん mailto:sage [03/11/24 22:18]
- で、悪あがきした結果がちょー感じ？
- 82 名前：デフォルトの名無しさん mailto:sage [03/11/24 22:41]
- むしろ悪あがきした結果はExtension BやOpenTypeの字形切り換えや
language tagやvariation selectorではないかい
漏れが理解できないのは、いくらUnicodeが糞でもシフトJISよりは
マシだと思ってるんだが(理由は>>72や>>79)なんでシフトJISから
移行するだけでもあんなに拒否反応示す奴が多いの? ってあたり。
そいつが超漢字に移行しようっていうならまだ話も分かるんだが。
- 83 名前：デフォルトの名無しさん mailto:sage [03/11/28 22:27]
- 今まで使っていた物が使えないから。
- 84 名前：デフォルトの名無しさん mailto:sage [03/12/01 00:30]
- 捨てませう。
- 85 名前：デフォルトの名無しさん mailto:sage [03/12/04 23:27]
- 大昔のことで忘れたが、UTF-8って、
ビットテストすれば何バイト目が分かる仕様じゃなかったっけ？
- 86 名前：デフォルトの名無しさん mailto:sage [03/12/05 11:18]
- ・１オクテット文字か
・マルチオクテット文字の先頭オクテットか
・マルチオクテット文字の後続オクテットか
が分かる。
マルチオクテット文字の何オクテット目かは、先頭かどうか以外は分からない。
- 87 名前：デフォルトの名無しさん mailto:sage [03/12/05 13:31]
- 先頭オクテットに関しては
・何オクテット文字の先頭か
もわかるはず。
00-7F 1オクテット文字
80-BF 後続オクテット
C2-DF 2オクテット文字の先頭
E0-EF 3オクテット文字の先頭
F0-F7 4オクテット文字の先頭
※C0-C1とF5-FDはRFC3629で使用禁止になった
- 88 名前：デフォルトの名無しさん mailto:sage [03/12/05 16:00]
- さんきぅ
単位はオクテットの方がよかったね(これまた大昔に指摘されたことだな)
ま、どっちにしてもシリアライズ向きか
Perlのutf8って、どのくらい使えるんだろう
- 89 名前：デフォルトの名無しさん mailto:sage [03/12/05 18:31]
- >>88
hyam.dip.jp/hiroshi/comp/perl/perl58.htm
> foreach $name ( < * > )
> でファイル名やディレクトリ名の "機能"を拾えない。
が5.8.1でも直ってないのでまだJPerlの置き換えはできまへん
- 90 名前：デフォルトの名無しさん [03/12/13 02:43]
- UNICODE 良く判らん・・・。UCS がキャラクタセットで、UTF がエンコーディング
なんだよね? UCS もキャラクタコードを持ってるという点ではエンコーディングと
考えてもいいの? 実際、Java や CLISP は内部的には UCS-2 で文字列を保持している
みたいだし。サロゲートペアとか考えなくてよくなるから、内部エンコーディングに
向いているのでしょうか?
UTF-8 が多いのは ASCII が使えれば十分な人が多いから?
各言語／ライブラリの内部エンコーディング／string のエンコーディング
Python: UTF-8?
Java: UCS-2/UTF-8
Tcl: UTF-8
Cocoa(Mac OS X): UTF-16
CLISP: UCS-2
Gauche: compile option dependent
Qt: UTF-8
Mule: has it's own encoding
XML: UTF-8 or UTF-16
自分で多言語対応文字列処理ライブラリを作る時は、UCS-2 を使うのが良いのでしょうか?
- 91 名前：デフォルトの名無しさん mailto:sage [03/12/13 02:50]
- とりあえずPythonはUCS-2だとだけ言っておく。
- 92 名前：デフォルトの名無しさん mailto:sage [03/12/13 02:52]
- thanx!
やっぱり固定長が便利って事だよね。
- 93 名前：デフォルトの名無しさん mailto:sage [03/12/13 02:54]
- std::basic_string<wchar_t>
linux-gcc:glibc(UCS4)/mingw32-gcc:msvcrt(UCS2)
ワイドキャラクタは、テンプレートを使えば
ロジックはそのままで型の導出の定義を替えて再コンパイルのみ。
インターフェースが変わるだけで上流工程に影響しない。
マルチバイトはロジックにパッチを当てなきゃならんので
論理のチェックもやり直し。
- 94 名前：デフォルトの名無しさん mailto:sage [03/12/13 03:38]
- ttp://homepage1.nifty.com/nomenclator/unicode/
- 95 名前：デフォルトの名無しさん mailto:sage [03/12/13 06:14]
- >UTF-8 が多いのは ASCII が使えれば十分な人が多いから?
USC2は情報量が足りないからサロゲートせなあかん、面倒
UCS4は無駄が多い
なによりUCSはstrcmpレベルから書き直さんとあかんよ
- 96 名前：デフォルトの名無しさん mailto:sage [03/12/13 06:21]
- JIS X 0213はUCSだと固定長ではすまないわけだが
(サロゲートを無視しても合成もある)
- 97 名前：デフォルトの名無しさん mailto:sage [03/12/13 11:07]
- >なによりUCSはstrcmpレベルから書き直さんとあかんよ
そんな必要ない。
// char *m = itoa<char, int>(100)
// char *w = itoa<wchar_t, long>(1234L)
template <typename C, typename I>
std::basic_string<C> itoa(I v, int radix = 10, bool caps = false) {
std::basic_string<C> buff;
C ch;
C af = (caps ? 'A' : 'a');
do {
ch = C(v % I(radix));
ch = ((ch > 9) ? (ch - C(10) + af) : (ch + C('0')));
buff += ch;
v /= I(radix);
} while (v);
std::reverse(buff.begin(), buff.end());
return buff;
}
- 98 名前：デフォルトの名無しさん mailto:sage [03/12/13 11:20]
- >97
型が混じってるぞ。
I r = v % I(radix);
C ch = (r >= I(10))? (af + (r - I(10)) : (C('0') + r);
ってところか。
- 99 名前：デフォルトの名無しさん mailto:sage [03/12/13 11:31]
- >>97
その調子で今まで作られた文字列処理関数すべてを書き換えてみて。
- 100 名前：デフォルトの名無しさん mailto:sage [03/12/13 11:42]
- >>99
つーか、作るまでも無く実はSTL+BOOSTなら大抵あるだろ。
boost::format(L"%5.3f:%3d") % 12.3 % 123
漏れも公開するかな。UCSはラクチンだよ。
- 101 名前：デフォルトの名無しさん mailto:sage [03/12/13 13:35]
- ところで内部コードがUTF-8って何かまずいことあるん？
UCS-2でも(OSによっては)出力する時点で変換しないとならないし
大して利便性は変わらないと思うんだが。
表現方法がいくつもあるほうが逆にやりづらいというかサポートするのが面倒。
- 102 名前：デフォルトの名無しさん mailto:sage [03/12/13 15:52]
- >>101
内部はUCSでいいじゃん。すでにJavaもVBもそうなってて不都合無いだろ。
C++も標準で困らないようになってる。
わざわざ検索処理とかCのランタイム書き直すの？
- 103 名前：デフォルトの名無しさん mailto:sage [03/12/13 16:10]
- >>102
UTF-16だろ
- 104 名前：デフォルトの名無しさん mailto:sage [03/12/13 19:39]
- jis x 0212 って「捨て」なんですか?
- 105 名前：デフォルトの名無しさん mailto:sage [03/12/13 21:37]
- >>96
結局、固定長で多言語を扱うというのは現実的には難しいのか。。。
- 106 名前：デフォルトの名無しさん mailto:sage [03/12/13 23:55]
- >104
Unicodeの中に生き残ってるでしょ。
- 107 名前：デフォルトの名無しさん mailto:sage [03/12/14 00:11]
- 超超超 超漢字！
超超超超 超漢字！
- 108 名前：デフォルトの名無しさん [03/12/14 01:17]
- .NET Framework的には、文字列stringはUTF-16だから、
次世代Longhornもこれに統一されるんじゃないの？
てことは、数年後にはUTF-16が事実上の標準になると。
- 109 名前：デフォルトの名無しさん mailto:sage [03/12/14 02:29]
- 文字コート関連のスレが他に無いので、ここで質問しても宜しいでしょうか?
euc.jp/i18n/charcode.ja.html#chap5
上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
のでしょうか。
EUC-JP はエスケープシーケンスを使わないという事ですので、エスケープ
シーケンスを使用した指示はしていないと思うのですが。
- 110 名前：デフォルトの名無しさん mailto:sage [03/12/14 03:47]
- >>109
> 上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
EUC は ISO 2022 に準拠してるとしか書いてないような…
> G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
> のでしょうか。
定数なので普通は何もしない。
既存の ISO-2022-JP の処理系があるなら ** を指示ってのにしたがって
G0 〜 G3,GL,GR を設定すれば EUC の処理系が作れるってだけ。
(SS2 と SS3 の処理は追加しなきゃいかんかったっけ？)
- 111 名前：デフォルトの名無しさん mailto:sage [03/12/14 08:52]
- >>109
EUC-JPは designate を省略しているが、invokeは省略しない。
ISO2022 designate invoke でググって見たら。
- 112 名前：111 mailto:sage [03/12/14 09:02]
- つうか、 ttp://euc.jp/i18n/charcode.ja.html#chap5 にちゃんと書いてあるじゃん。
指示(designate)は省略する。(あらかじめ指示してあると約束する)
EUC-JPを使うと言う取り決めは、G0,G1,G2,G3に
それぞれJIS X0201ローマ字,JIS X0208, JIS X0201カタカナ, JIS X0212を指示するという
取り決めとなるわけ。
(ただし、GOがASCIIなのかJIS X0201ローマ字なのかにはゆれがある。)
当然、呼び出し(invoke)は行う。
- 113 名前：デフォルトの名無しさん mailto:sage [03/12/14 15:37]
- G0にJIS X 0201ローマ字を指示するEUCってあったっけ?
(実装の解釈が変というのは除いて)
JIS X 0208本体のラテン文字・漢字用8ビット符号がいちおう該当するか。
これはG2もG3も使わないけど
- 114 名前：デフォルトの名無しさん mailto:sage [03/12/14 16:30]
- >>113
ttp://www.opengroup.or.jp/jvc/cde/euc.html
- 115 名前：デフォルトの名無しさん mailto:sage [03/12/14 16:40]
- >>114
見事なまでにバラバラだな
- 116 名前：デフォルトの名無しさん mailto:sage [03/12/14 17:19]
- >>110-112
レスどうもありがとうございます。
4.7 の所に省略すると書いてあるのに気付きませんでした。済みません。
エディタを作りたかったのですが、やっと ISO 2022 が理解出来ました。
どうもありがとうございました。
- 117 名前：デフォルトの名無しさん [03/12/14 21:07]
- 初歩的な質問ですが
EUC を SJIS に変換まではできたのですが、
この変換できた EUC のデータを
printf() 関数を使ってコンソールに出力したいので
CString szEUC;
szEUC = ....
printf( "%d\n", szEUC );
とやってみましたが うまくいきません。
EUCコードを 文字化けせずにコンソールに出力するには
何か設定が必要なのでしょうか？
- 118 名前：デフォルトの名無しさん mailto:sage [03/12/14 21:21]
- エスパー募集ですか？
- 119 名前：デフォルトの名無しさん mailto:sage [03/12/14 22:07]
- CString って MFCだよねぇ。
_MBCSと_UNICODEのどっちが定義されているかで入っているもの違うけど。
どっちにせよ、 CStringをそのままprintfで出力するのは反則だし。
_tprintf("%s\n", LPCTSTR(szEUC));
MFCスレで聞けば？
- 120 名前：117 mailto:sage [03/12/15 00:32]
- printf( "%d\n" szBuf ); → %s
また やってしもうたか・・・＿|￣|○
設定って、#define とかのことでした すんまそん
- 121 名前：デフォルトの名無しさん mailto:sage [03/12/15 02:10]
- SJISしか受け付けないコンソールにEUC出力すれば、
そりゃ文字化けするわなぁ。
- 122 名前：デフォルトの名無しさん [03/12/15 11:40]
- EUC-TWってSS2の後にA2〜B0を付けてPlaneを識別している
みたいですけどこういうのってISO 2022的にアリなんですか?
- 123 名前：122 mailto:sage [03/12/15 11:58]
- 94^3集合と考えればいちおうアリですね。
問題はISO-IRには別々の94^2集合しか登録されていないことですが。
- 124 名前：デフォルトの名無しさん [03/12/15 12:58]
- 内部コード UTF-8 は XML がらみのライブラリを使うときとかに多用するけど、
逆に OS 側やら他のライブラリは UTF-8 なんてこと殆どないんで、
かなりの場面でコード変換が必要になるなぁ。。
- 125 名前：デフォルトの名無しさん mailto:sage [03/12/15 15:40]
- UCS-2って文字集合のことですよね。
UTF-16はUCS-2の符号化方式の一種ですよね。
ところで、GNUのlibiconvっていうライブラリに符号化方式としてUSC-2が使えるんだけど、
これって何か特別な使い方があるのかな。ダンプしてみたらUTF-16BEと全く同じなんですよね。
- 126 名前：デフォルトの名無しさん mailto:sage [03/12/15 16:09]
- > UTF-16はUCS-2の符号化方式の一種ですよね。
違うと思う(前者は後者にない補助面の文字が存在してるから)
- 127 名前：デフォルトの名無しさん mailto:sage [03/12/15 20:04]
- UCS-2の文字番号をそのまま使う符号化方式もUCS-2と呼んでるんだろう、きっと。
BMP外の文字を使わなきゃUTF-16BEと同じになるのは道理。
UTF-16類とは、サロゲートとBOM位しか違わないんでない？
- 128 名前：デフォルトの名無しさん mailto:sage [03/12/15 22:57]
- UCS2は基本的に内部表現用なのでBE/LEどちらでもUCS2。
完全に実行環境に依存してる。
- 129 名前：デフォルトの名無しさん mailto:sage [03/12/16 00:57]
- iconv使うと実行ファイル+数メガの.so/.dllをくっつけないといかんので困る。
- 130 名前：デフォルトの名無しさん mailto:sage [03/12/16 10:06]
- SJIS←→UCSの変換なんてOSの変換表は
まるで信用できないからなあ
- 131 名前：125 mailto:sage [03/12/16 13:33]
- Thanks > 126-128
符号化方式としてのUCS-2ってのは使わない方がいいみたいですね。
さらに、UTF-16に関して質問なんですけど、私の認識では、UTF-16系の扱いは以下のようになってます。
・UTF-16 ＝ BOMを見てlittle endianかbig endianか判断せよ。
・UTF-16BE ＝ big endianに決まっている。
・UTF-16LE ＝ little endianに決まっている。
つまり、UTF-16はBOMがあるもので、BOMがない場合はUTF-16BEかUTF-16LEと明示的に
指定すべきものだと思っています。でもたまに「BOMなしUTF-16」とか「BOM付きUTF-16BE」
のような記述をWebサイトやアプリケーションに見受けます。
私の認識は間違ってます？
- 132 名前：デフォルトの名無しさん mailto:sage [03/12/16 15:59]
- 十数年前はチーズバーガーが１個２３０円だった。
それが、ついこの間まで１個８８円で売っていた。
これはつまり、その気になれば１個８８円で売れたモノを２３０円で売ってた訳だ。
その昔に１個２３０円で食ってたオレに言わせれば全く腹の立つ話だ。
- 133 名前：デフォルトの名無しさん mailto:sage [03/12/16 16:53]
- じゃあたった10MBかそこらのメモリが億単位の値段だったなんて
もう詐欺みたいなものですね
とかコピペにマジレスしてみるテスト
- 134 名前：デフォルトの名無しさん mailto:sage [03/12/19 19:24]
- >>131
好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
グズグズとそんなこと考えんで宜しい。
１０年後に UTF-16 なんて使ったら洟で笑われるぞ。
- 135 名前：デフォルトの名無しさん mailto:sage [03/12/19 19:35]
- 10年後には UTF-8 すらなくなっていますが。
- 136 名前：デフォルトの名無しさん mailto:sage [03/12/19 20:13]
- Asciiコードは無くなるかなあ？
- 137 名前：デフォルトの名無しさん mailto:sage [03/12/19 20:23]
- >>136
欧州市場はやっぱり無視できないから、新規の実装では使われなくなると思う。
- 138 名前：デフォルトの名無しさん mailto:sage [03/12/19 21:05]
- UTF-8という名のASCII
- 139 名前：デフォルトの名無しさん mailto:sage [03/12/20 00:09]
- UTF-8 って合成を考えると、一文字が最大 12 オクテットになるの??
- 140 名前：デフォルトの名無しさん mailto:sage [03/12/20 05:14]
- >>139 21
- 141 名前：デフォルトの名無しさん mailto:sage [03/12/20 21:50]
- どういう計算をして12オクテットになったのか謎ですが
3文字以上の合成だってあります。
- 142 名前：デフォルトの名無しさん mailto:sage [03/12/22 17:19]
- 合成で気になったんだが、合成の組み合わせと数に制限はあるのか？
例えば、U+306C U+0308 とか、U+0276 U+0328 U+0336 U+030F U+0360 とかは
Unicode文字として規格上正しいもんなのか……？
# 直感的には、明らかに正しくないことはわかってるのだが。
- 143 名前：デフォルトの名無しさん mailto:sage [03/12/22 20:18]
- >>142
JIS X 0221の規格票をざっと眺めた感じでは、制限無しの模様。
- 144 名前：デフォルトの名無しさん mailto:sage [03/12/22 22:38]
- >>142
残念ながらダイアクリティカルマークの
スタック(積み重ね)という概念は実在する
dl2.yukoncollege.yk.ca/ynlc/ynlcfonts/stacking/stacking.html
- 145 名前：デフォルトの名無しさん mailto:sage [03/12/24 13:26]
- >>144
そこのページ雪だるまがいぱーいあって季節的にGood!
- 146 名前：デフォルトの名無しさん mailto:sage [03/12/25 01:44]
- >好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
ISO C++ではワイドキャラクタはサポートされてますが、
マルチバイトがしっかり動く環境ではありません。
UCS-4マンセー。UCS-4でいいじゃん。
- 147 名前：デフォルトの名無しさん mailto:sage [03/12/25 01:58]
- だったらこの文字ユニファイして領域節約してくれよ
U・C・S!! U・C・S!!
- 148 名前：デフォルトの名無しさん mailto:sage [03/12/25 18:01]
- >>146
とりあえず、意味不明
- 149 名前：デフォルトの名無しさん mailto:sage [03/12/25 18:55]
- 正直utf-16でいい
- 150 名前：デフォルトの名無しさん mailto:sage [03/12/25 20:03]
- 正直utf-16のよさがわからない
- 151 名前：デフォルトの名無しさん mailto:sage [03/12/25 22:56]
- WinXP用ならUTF-16もいいが
他の環境を考えると
- 152 名前：デフォルトの名無しさん mailto:sage [03/12/26 00:58]
- UCS4だよ。一文字32ビット固定でいいやんけ。
|
 |
