- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 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ビット固定でいいやんけ。
- 153 名前：デフォルトの名無しさん mailto:sage [03/12/26 12:55]
- 合成があるってば
- 154 名前：デフォルトの名無しさん mailto:sage [03/12/26 14:13]
- 漢字圏の人間はついついUCS-4で全部解決と
思ってしまうんだよなあ。
- 155 名前：デフォルトの名無しさん mailto:sage [03/12/26 15:06]
- その典型が昔のTRONですね
www.horagai.com/www/den/kanken.htm#04
最近のバージョンでは解決してるの?
- 156 名前：デフォルトの名無しさん [04/01/06 02:05]
- うーん、実態はそんなに単純じゃないんだけどなあ。
TRONの関係者の中にも多言語処理の複雑さを理解している
人たちはちゃんといたよ。昔のweblogをみると多言語の問題と
取り組んで悪戦苦闘している様子がうかがえた。
合成の問題のことは頻繁に話題になっていたよ。
一応TRONでは80年代ごろから多言語処理には
4層構造(言語層、文字属、スクリプト、フォント)で対応する
ということになっていたんだけど、悲しいかな人手不足で
全然研究、ましてや実装は進まなかったんだよ。
今超漢字の販売元は組み込み向けの製品に注力していて、
超漢字にはあまり時間をかけていない様子。改善されているのも
相変わらず漢字処理が中心だよ。明るいニュースはごく最近
SUNがJavaのTRONコードへの対応を約束したことぐらいかな。
まだまだ先の道のりはながいよ。
- 157 名前：デフォルトの名無しさん mailto:sage [04/01/06 20:27]
- > TRONの関係者の中にも多言語処理の複雑さを理解している
> 人たちはちゃんといたよ。
こんなのとか?
www.sumire.sakura.ne.jp/~oguma/tron/btm1999z.html#19991203
漢字がどうしても中心になるのは分からなくもないけどね
使いもしない文字のサポートが強化されたって一般受けしないばかりか
「シリア語ブラクラ」なんて汚名まで被る始末だし
- 158 名前：デフォルトの名無しさん [04/01/08 04:12]
- 思ったんだけど、
わざわざ全ての文字を１つの文字コードに詰め込まなくても、
JIS コードみたいに文字コードの切り替えを行うマークを導入すれば
かなりすっきりするんじゃない？
- 159 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:22]
- その切り替えタグに当たるコードは
どうすれば必要十分で、どういうルールで割り当てていく？
- 160 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:30]
- 仮に一文字２バイトで固定するなら、
文字として使える領域と
切り替えタグにしか使えない領域に分割すれば
いいんじゃない？
- 161 名前：あぼーん mailto:あぼーん [あぼーん]
- あぼーん
- 162 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:44]
- >>158
エスケープ・シーケンス unix で検索しる。
- 163 名前：デフォルトの名無しさん mailto:sage [04/01/08 05:02]
- >>162
Compound Text ってやつ？
なるほど、既にその手のものはあるんですな。
これで問題になることって何があるのかな？
- 164 名前：デフォルトの名無しさん mailto:sage [04/01/08 11:50]
- >>163
まともな処理をするのがめんどうくさい。
- 165 名前：デフォルトの名無しさん mailto:sage [04/01/08 11:58]
- そもそも、プログラミングを容易にするために（＝国際化の容易さに直結）、
シフトを追放しランダムアクセス性を付与することが、
Unicodeの重要目標だったわけで。
- 166 名前：デフォルトの名無しさん mailto:sage [04/01/08 18:45]
- ttp://www.d2.dion.ne.jp/~kuropoo/kanban/shimbun/iwateken.jpg
↑この看板のコウの字がJIS X0208その他の文字集合に見あたらないのですが、
「工」に包摂されているんでしょうか、それとも探し方が悪いのでしょうか……？
- 167 名前：デフォルトの名無しさん mailto:sage [04/01/11 05:54]
- >>166
MacOSX 10.3のヒラギノProに異字体として入ってるから（Stdの方には入ってないし、他のUnicodeフォントにも存在してない）文字集合としてはAdobe-ほげほげ-1.5とか以上でないと
入ってなさそうな感じですね。
印刷物に使うのはかまわないけど、インターネットとかには使えないよという警告がでますな。
- 168 名前：デフォルトの名無しさん mailto:sage [04/01/11 14:54]
- ほうちゃんと警告が出るのか。
つーかちゃんと異体字指定の方法を標準化して
インターネットでも使えるようにしてほしいんだが
- 169 名前：デフォルトの名無しさん mailto:sage [04/01/12 00:05]
- >>168
その辺はまだこれからの課題なんじゃないかな？
AdobeとAppleだけだもんな。今んとこ。
XにContributeされてるAdobeのフォントに日本語のが入ってくれば状況は一気に変わるのかも
知れないけど。
WinはOTFのヒラギノ購入＆インストールで対応できるのかな？
Win持ってないんで判らんのでWinの方でヒラギノ入れてるような奇特な人は試してください。
あ、でもInDesignでドキュメントが完全にコンパチブルだとか売りにしてるようだから、ちゃんと
使えるのだろうな、きっと。
- 170 名前：デフォルトの名無しさん [04/01/19 08:20]
- UTF-8 から JIS X 0208 への変換テーブルってどっかない？
- 171 名前：デフォルトの名無しさん mailto:sage [04/01/19 08:28]
- >>170
Perlかなんかで作れ。
- 172 名前：デフォルトの名無しさん mailto:sage [04/01/19 08:57]
- >>170
ftp://unicode.org/Public/ のどっか。
|
 |
