07/10/06 10:18:53
>>169
6バイト
175:デフォルトの名無しさん
07/10/06 11:20:14
>>174
>>171以外ならそんな入力の場合に6バイトになるのかkwsk
176:デフォルトの名無しさん
07/10/06 11:20:34
×そんな入力
○どんな入力
177:デフォルトの名無しさん
07/10/06 11:23:48
ｽﾚﾘﾝｸ(tech板)
178:デフォルトの名無しさん
07/10/06 15:19:26
Javaは3バイトまで
179:デフォルトの名無しさん
07/10/06 17:15:03
ドイツ語圏は、ドイツ語を使う国々が集まって、表記法を統一する会議を何年かおきに
やっている。
なんで、東アジア、漢字を統一できなかったのか、残念。
180:デフォルトの名無しさん
07/10/06 17:25:36
U+10000からU+10FFFFまでは4バイト
181:デフォルトの名無しさん
07/10/06 17:27:11
>>179
ドイツ人は制定マニアだから。
そういうことが難しいからこそ、漢字圏なんじゃないのか?
182:デフォルトの名無しさん
07/10/06 17:56:29
ドイツ語圏はドイツ語圏だけど
漢字圏は中文圏じゃないし
日本語とかの別言語でも漢字を使っているからね
183:デフォルトの名無しさん
07/10/06 18:20:18
>>179 中国だって統一王朝が立つと文字の整理をやってるぞ
184:デフォルトの名無しさん
07/10/06 18:35:31
MySQLのUTF8は3バイト文字までしか対応していない
185:デフォルトの名無しさん
07/10/06 19:35:22
>>184
ありゃりゃ。みんなどうしてんの？
186:デフォルトの名無しさん
07/10/06 20:07:40
>>183
毛沢東もやった死ね
187:デフォルトの名無しさん
07/10/06 21:51:16
じゃあ漢字の統合のために台湾併合だな
188:デフォルトの名無しさん
07/10/06 23:34:15
日本もね
189:デフォルトの名無しさん
07/10/06 23:57:53
康熙字典体に統一で桶。
190:デフォルトの名無しさん
07/10/07 02:48:55
中国は文献がほとんどかえりみられなくなっては
日本から逆輸入というのを定期的に繰り返しているし。
文字の統一なんて掛け声以前の問題じゃなかろうか。
191:デフォルトの名無しさん
07/10/07 03:38:26
>>189
Unicodeはそういう方針だな。GB7589とGB7590は繁体字で入ってるし
並び順も康煕字典の部首画数順だし
192:デフォルトの名無しさん
07/10/07 05:22:31
80年代後半から90年代前半って
台湾の方が電子化進んでたよね
193:デフォルトの名無しさん
07/10/07 08:48:37
いまや日本＝秋葉原でHENTAI ANINEの国という認識だろ。
文字なんて「萌え」が残ってればおｋなんじゃね？
と秋葉帰りの外人から思われてるに違いない。
194:デフォルトの名無しさん
07/10/07 13:30:02
>>191 Unicode の康煕字典ベースは、Unicode の原典主義からの帰結やね。
並び順の、康煕字典の部首画数順はもしかして漢字文化圏のグローバルスタンダード?
>>193 向こうの濃いオタ連中は20年ぐらい前から現代日本風アイテムとして漢字を
認識してるから、それはない。
195:デフォルトの名無しさん
07/10/07 13:37:21
請け負ったWebの仕事で、UTF-8で作成してたんだが、
Shift-jisしか受け付けないサーバーだと完成間際で判明して
１から変換しなおし。何とか事なきを得たんだが、次回に
どうしてもクライアントがやりたがってる事をAjaxでやろうと
すると、どうしてもUTF-8を採用せざる負えない結果に…orz
javascriptでShift-jisからUTF-8に変換して表示させる事はできないでしょうか？
向こうのサーバー事情でPHPやらPerlは一切使わせて貰えない状況です。
何とかお助けくださいませ。。。。。。。。。。。。
196:デフォルトの名無しさん
07/10/07 14:15:38
ググレカス
197:デフォルトの名無しさん
07/10/07 14:40:15
>>194
CJKのどこからも文句の出ない並び順が康煕字典順しかなかったってことだろう
現代中国はにくづきとふなづきを統合したりしたまったく異なる部首を使ってるし
発音順は国によって全く異なるし
198:デフォルトの名無しさん
07/10/14 20:13:05
sjis,EUC,UTF8,16,32の判別ソフトをCで作っています。
UCS2も対応させたいのですが、何処か参考になるサイトは無いでしょうか
すみません、どなたか教えて下さいm(_ _)m
199:デフォルトの名無しさん
07/10/14 20:21:10
>>198
URLﾘﾝｸ(www.google.co.jp)
200:デフォルトの名無しさん
07/11/03 16:03:56
【日台中韓】韓・中・日・台が漢字の字体統一へ[11/03]
ｽﾚﾘﾝｸ(news4plus板)
201:デフォルトの名無しさん
07/11/03 19:20:21
字体統一って中国以外にメリットあるの？
202:デフォルトの名無しさん
07/11/03 19:22:45
日本すら未だに統一できてないのに秒速で漢字が増えてゆく国が統一とは
203:デフォルトの名無しさん
07/11/12 17:13:15
>>200
ウソだったらしい。もうなにがなんだか。
【日台中韓】 「中・日・韓・台の漢字統一」報道を否定！簡体字使用の変更は不可能[11/12]
ｽﾚﾘﾝｸ(news4plus板)
204:デフォルトの名無しさん
07/11/12 18:23:49
ヨタ記事をいちいち貼るなよ。
205:デフォルトの名無しさん
07/11/17 15:44:45
IMEパッドの文字の上にマウスを持っていくとでるバルーンヘルプの内容が取得できるライブラリ(関数)をしりませんか？
in:jisX0213:2004 1面, 1区, 1点
out:ucs, utf-8, Shift_JIS
見たいな、、、
206:デフォルトの名無しさん
07/11/18 00:29:36
超漢字検索の情報ウィンドウの内容を取得できるライブラリもほしい
207:デフォルトの名無しさん
07/11/20 23:35:37
JIS X 0213 面区点番号とunicodeのマッピングを
機械的に求めることはできますか？
208:デフォルトの名無しさん
07/11/21 11:39:36
テーブル引く
...というのは機械的だろうか？
209:デフォルトの名無しさん
07/11/21 13:03:01
ドイツ語は定期的にspellをドイツ語圏で統一するように会議をしているね。ま、向こうは意味まで
同じなのだが。形だけ揃えても意味ないし、朝鮮半島はハングルで統一されている。CKJで統一
する意味はないと思うのだがね。
210:デフォルトの名無しさん
07/11/21 19:13:46
perlで作ったcgiに一番ｵﾇﾇﾒなコードｋｗｓｋ
211:デフォルトの名無しさん
07/11/21 21:09:46
perlはなんでもいいよ。
Encode使えば割りとw何でもできるから。
好きなのにしな。
まあ今ならutf-8がいいだろうけど。
formにUnicodeな文字入力する奴もいるし。
212:デフォルトの名無しさん
07/11/24 02:48:07
なんかさ、gccのワイドリテラルの扱いってへんてこな感じね。
gcc3.4よか前だと単に1Byteを4Byteに展開するだけで何の文字コードでもなく、
3.4以上だとUTF-32LEになってるかのような動き。
さらにvc(UTF-16LE)とのクロスでの開発を考えると頭が痛くなるなあ・・
Win/Linuxのクロスでやってる人って内部コードってなににしてる？
213:デフォルトの名無しさん
07/11/24 02:52:40
>>212
ワイド文字をリテラルでは使わない。
UTF-8から変換。
214:デフォルトの名無しさん
07/11/24 03:07:35
ま、そだよね。基本的にはリテラルに日本語入れなきゃ円満なんだよね。
3.4以降はexec-charsetでどうとでもできそうだけど、古いのは・・
ソースをUTF-8にすればなんとか日本語入れてもコンパイルはできるか。
あぁ、でもvc7とかはUTF-8のソース確か受け付けなかったような。
ソースくらいは変換するべきか。面倒だな・・いろいろ。
215:デフォルトの名無しさん
07/11/24 04:02:12
全部\uxxxxで書いちゃえ。
216:デフォルトの名無しさん
07/11/24 04:22:36
うほ、なげやり
でもそれすらgccいけるけどvcは\u使えないとか罠があったり。。
いろいろ実験して、バッドノウハウだけ増えたな・・
vc,gccともソースがUTF-16系は不可、vcはシグニチャなしUTF-8ソース不可、
逆にgccはシグニチャありUTF-8ソース不可・・
217:デフォルトの名無しさん
07/11/24 04:45:06
いや、やっぱvcはUTF-8はBOMありなしどっちもだめだなぁ。ソースによる
みたいだ。最低だなsjisしか受け付けないのか・・。vc8なら平気かもしれないけど
vc ソースsjis 内部UTF-16LE(コンパイル時L変換)
gcc3.3以下 ソースsjis(リテラルに"表"とかだめ) 内部UTF-8(実行時iconv変換)
gcc3.4以上 ソースsjis 内部UTF-8(input-charset=cp932でgccでコンパイル時変換)
こんなしか選択肢がないような。あぁ、CVSで変換するとかならソースはもっと
自由度あるか。だりーな、Unicode対応・・。もうsjis/eucでいい気がしてきた。
218:デフォルトの名無しさん
07/11/24 15:53:48
vcがutf-8ダメだってのは、何がだめだっての？
219:デフォルトの名無しさん
07/11/24 17:14:21
vc7で、UTF-8のソースだと
#define XX "あ"
とかあるとだめだけど
#define XX "ああ"
だと平気。たぶんsjisとして処理してるから日本語リテラルが奇数バイト
だとだめみたいな感じ。
220:デフォルトの名無しさん
07/11/24 23:51:33
vc8使え。終了
221:デフォルトの名無しさん
07/11/25 10:34:26
00h～1Fh 制御文字
20h～7Fh 各国共通（1バイト文字）
80h～FFh 各国自由（1／2バイト文字）
16ビットPCを出すときに思い切って半角カナを廃止して
80h以降は日本では2バイト文字専用にすれば良かった
つーか70年代末期の最初のPCを出すときに80h以降は
予約領域かPCG領域にすれば良かったんだよな
222:デフォルトの名無しさん
07/11/25 10:36:33
あとからならどうとでも言える
カタカナだけでもいいから1バイトで処理したいという要求がどれだけ当時は切実だったことか
223:デフォルトの名無しさん
07/11/28 12:10:33
80年代前半は漢字が表示できないマシンがごろごろしてたし
1987年ごろのパソ通でも、漢字を使うと表示できないマシンが
あるから、カナ以外禁止というところもあったね。
224:デフォルトの名無しさん
07/11/28 14:01:29
テキストVRAMで漢字もOK、なPC9801も初期はJIS第2水準はオプションだったしなあ
225:デフォルトの名無しさん
07/11/28 18:40:35
>>224
初代は第1水準もオプション
226:デフォルトの名無しさん
07/11/28 18:44:17
テキストVRAMが歯抜けだったからね。＜無印PC-9801
オプションの漢字ROMボードを入れるとその隙間を埋めるRAMもついてきたってわけ。
227:デフォルトの名無しさん
07/11/29 21:02:51
おまえらいくつだよ・・おっさんばっかだな
まあ若い人は文字コードになんか興味ないか
228:デフォルトの名無しさん
07/11/29 21:29:00
28歳はおっさんですかそうですよね。
229:デフォルトの名無しさん
07/11/29 22:02:33
外見によっては22でもおっさん。
230:デフォルトの名無しさん
07/11/29 22:22:00
プログラマーは25才が卒業式です
231:226
07/11/30 00:24:07
>>227
失礼な。せめておばさんと呼べ。
232:デフォルトの名無しさん
07/11/30 07:21:18
時代背景を知らないと
テキストVRAMって文字サイズとか位置とか固定になっちゃうじゃんｗｗｗ
超バカスｗｗｗ
なんでグラフィックVRAMに全部書かないのｗｗｗ
とか言い出す奴がいそうだな。
8ビットマシンはグラフィックVRAMに漢字表示できるものもあったわけだが
233:デフォルトの名無しさん
07/11/30 08:53:49
武勇伝はチラシの裏でどうぞ
219はどうなった？
234:デフォルトの名無しさん
07/11/30 19:30:45
単にバイト列としてコンパイルしたいだけなら
#pragma setlocale("C") を入れときゃいいだけでは？
235:デフォルトの名無しさん
07/12/01 09:01:43
POSITION 160,100:PATTERN -16,KANJI$(4746)
236:デフォルトの名無しさん
07/12/01 16:08:27
KANJI$テラナツカシス
237:デフォルトの名無しさん
07/12/02 07:14:19
Unicodeはもうだめだな
サロゲートペア，異体字，半角カナ．．．問題ありすぎ
世界中の文字使えるったってほとんど意味無いしょ
第３水準で変な記号いっぱい追加されたけどそれも要らん
JISが大手PC・携帯メーカーに呼びかけて
MS，アップル，ドコモ，au，ソフトバンク，NEC，富士通，IBM
2バイト文字の最終統一規格を作るしかないんじゃないの？
8080H～FFFFHの16384字あれば十分
238:デフォルトの名無しさん
07/12/02 10:41:18
＞JISが大手PC・携帯メーカーに呼びかけて
逆だ。JISは大手に踊らされている御用団体だからね。
つーか、それができるのならJIS83辺りで統一できているはず。
# 実態は……言うまでもないよな。
＞8080H～FFFFHの16384字あれば十分
計算できる?
239:デフォルトの名無しさん
07/12/02 11:18:03
CJK互換漢字に4字追加されるみたい。
240:デフォルトの名無しさん
07/12/02 11:25:30
>>237
もうおなかいっぱい。
これ以上文字コードを増やさないでくれ。
241:デフォルトの名無しさん
07/12/02 11:45:05
しかも>>237のレベルでは…
242:デフォルトの名無しさん
07/12/02 18:39:01
UTF-8で統一されるのが楽かなあ
>>237
2バイト固定長はもう無理でしょう。というか固定長は結合文字の
存在もあるしコーディング上のメリットがないんだよなあ。
結合文字を考慮した文字検索アルゴリズムとかもうどうしていいんだか・・
243:デフォルトの名無しさん
07/12/02 19:06:21
TronコードでOK
244:デフォルトの名無しさん
07/12/02 20:31:22
>>243
TRONコードは、単に、すでにある文字集合をぶち込む枠組であって、
文字集合の整備は漢字の収集とかやったけど、処理の上位層について
TRON方面は概念を発表しただけで具体的なものは何も出てきて
いないし、現在の問題を何ら解決できるものではない。現状から見て、
たいした期待はできない。
245:デフォルトの名無しさん
07/12/03 01:24:14
グリフ単位での文字検索は諦めて、コードポイント単位で
やるしかないんじゃないの。当面は。
246:デフォルトの名無しさん
07/12/03 22:10:17
結合文字はそのコードポイントが別だから検索がめんどいんじゃないのか・・
247:デフォルトの名無しさん
07/12/03 22:22:07
このへんを実装すれば多分おｋ
URLﾘﾝｸ(www.unicode.org)
URLﾘﾝｸ(www.unicode.org)
248:デフォルトの名無しさん
07/12/03 23:03:38
UTF-8な文字「X」が文字コード AB CD EF で定義されているとして、
別の文字「Y」がこれらをシャッフルした文字コード（ AB EF CD など）で
定義されている、という組み合わせを探しています。
効率的な調べ方とかあるかしら？
249:デフォルトの名無しさん
07/12/03 23:14:28
たかだかx6だからベタでいいだろ。
250:デフォルトの名無しさん
07/12/04 01:18:41
>>249
char a[] = { 0xE3, 0x82, 0xA2, 0x00 };
char b[] = { 0xE3, 0xA2, 0x82, 0x00 };
ってしたときに、aは「ア」だけどbに割り当てられた文字はないでしょう？
そういうのをプログラム的に省きたかったんだ。無理っぽいなあ
251:デフォルトの名無しさん
07/12/04 01:25:35
>>250
んなこと悩んでいる間にベタで書けば5分掛からないだろ。わけわからん。
それともなんかのプログラムの動作中ってこと？
252:デフォルトの名無しさん
07/12/04 07:34:33
これって割り当てられてるってこと？
URLﾘﾝｸ(www.google.co.jp)
ア の検索結果 約 73,600,000 件中 1 - 10 件目 (0.05 秒)
URLﾘﾝｸ(www.google.co.jp)
㢂 の検索結果 約 2,740 件中 1 - 10 件目 (0.24 秒)
253:デフォルトの名無しさん
07/12/04 09:56:17
日本語の文字には無いけど、中国の文字にあるだろ
254:デフォルトの名無しさん
07/12/04 09:56:49
0xE3, 0xA2, 0x82 だから、文字コード 3882 だよ。
255:デフォルトの名無しさん
07/12/04 10:56:35
U+3882 はちゃんと ExtA に割りあてられてるな。
Windows なら Vista にするか対応フォントを入れれば見えるはず。
256:デフォルトの名無しさん
07/12/04 11:36:45
関数的に書くなら、
端から生成して、端からx6の組み合わせで生成して、
端からUTF-8になってないバイト列を落とすフィルタを通す、
という感じで書くかな。
257:デフォルトの名無しさん
07/12/04 12:05:37
>>251
AB CD EF は16進数の10～15ではなくて、6種類の変数A～Fという意味。
文字列処理関数のテストケースを書いてて、248 みたいな組み合わせが数通り欲しかったのさ。
文字コード一覧表を目視して解決しますた。あんがと。
>>255
ExtAってなんかの制御コード？
>>256
日本語フォントが用意されているかを調べる、というコードが書けない俺orz
258:デフォルトの名無しさん
07/12/04 12:28:23
「日本語フォント」なんて関係ないだろ。
「文字集合」で考えろ。
259:デフォルトの名無しさん
07/12/04 12:48:05
「UTF-8的にあり得る(3バイトの)バイト列」じゃなくて、
「UnicodeからJIS X 0208(あるいはCP932)にマップ可能なコードポイント」を抽出したいのか？
それはテーブル引くしかないような気がする。
260:デフォルトの名無しさん
07/12/04 12:53:57
ExtA = CJK Ideograph Extension A
U+3400～U+4DB5(Unicode3,4), U+4DBF(Unicode5)
いわゆる「機種依存文字」な漢字でUnicode2に入ってなかった奴が入った所と思った。確か
261:デフォルトの名無しさん
07/12/04 13:03:01
JIS X 0208あるいは指定した文字集合だけ考えればいいなら、
JIS X 0208の全ての区点コードをリストアップ ('あ'を例に)
↓
UTF-8の16進数表現に変換 (0xE3 0x81 0x82)
↓
バイト列をソートしたのものを一桁目に(CSV) (0x81 0x82 0xE3, 0xe3 0x81 0x82)
↓
一桁目でjoin (0x81 0x82 0xE3でjoin)
↓
join後、複数項目のあるものをリストアップ。
262:デフォルトの名無しさん
07/12/04 17:55:57
文字集合と符号化方式の概念が理解できてなかった。まさに>>259だ。
>>258、>>260-261
もthx!
263:デフォルトの名無しさん
07/12/04 23:52:17
>>233
ｽﾏﾝ、結局Linuxどうしてんのかレスなかったから見てなかった・・
Stringを自前で作って、各文字コード処理できるようにする方向でやってる
264:デフォルトの名無しさん
07/12/06 01:28:41
std::stringは結局役に立たんからね
265:デフォルトの名無しさん
07/12/06 19:00:37
EUC-JPって第2面をA121～FE7Eに配置できないのかな
第1バイトがA0～FFなら2バイト文字だと認識するようにすれば
いいと思うんだけど
266:デフォルトの名無しさん
07/12/06 20:32:41
>>260
U+4DBFに文字なんか割り当てられてたか?
ブロックの範囲と文字が収録されている範囲をごっちゃにしてる
通信用語の基礎知識あたりの鵜呑みじゃあるまいな
267:デフォルトの名無しさん
07/12/06 20:33:43
>>265
円記号問題どころの騒ぎじゃなくなります
メインフレーム各社の独自コードにはそういう変態割り当てをしたものが
けっこうあるけど
268:デフォルトの名無しさん
07/12/06 20:52:49
>>266
スマン
あたり
orz
3.0 と現行のを調べた。
レンジは 3.0 だと U+4DFF まで、5.0 だと U+4DBF まで、
中身が入ってるのは U+4DB5 まで、で合ってます？
間に入ったのは Yijing Hexagram Symbols って八卦かよw
269:デフォルトの名無しさん
07/12/06 22:09:16
>>268
うむ
ちなみにU+9FA5の後ろには本当に文字が断続的に追加されてるな
270:デフォルトの名無しさん
07/12/06 22:25:43
URLﾘﾝｸ(examples.oreilly.de)
aj16.tar.Zが更新されてる
pri108に対応していくつかのCIDにUnicodeが追加された模様
271:デフォルトの名無しさん
07/12/07 08:24:11
第１～第４＋非漢字で11233字
補助漢字で6067字
補助漢字と第３，第４でかぶるのが約2900字
11233＋6067－2900＝14400字
8080H～FFFFH＝16384字
272:デフォルトの名無しさん
07/12/07 08:42:20
>>267
それはSHift-JIS固有の問題。
273:デフォルトの名無しさん
07/12/07 09:30:20
何そのとんちんかんなレスはw
274:272
07/12/07 09:42:22
あ、ダメかｗ
言いたいのは1～2バイトに収まるようにシンプルにしてほしいってこった
275:デフォルトの名無しさん
07/12/07 10:57:54
UCS-2の過ちを繰り返すのかよw
276:デフォルトの名無しさん
07/12/07 12:51:45
繁体字とか簡体字とかハングルとか要らんだろｗ
277:デフォルトの名無しさん
07/12/07 13:41:14
ハングルという偉大な文字は必要ニダ！
278:デフォルトの名無しさん
07/12/07 13:47:08
自分に必要なありとあらゆるソフトウェアを、その独自規格に準拠したもの
のみでまかなえるなら好きにすればー?
# 文字コードが、文字集合を情報「交換」のために符号化したものである
# ということを理解してないやつがこんなにも多いのは何故だ?
279:デフォルトの名無しさん
07/12/07 13:48:26
漢字なんかいらんだろ（米国人(32)）
280:デフォルトの名無しさん
07/12/07 13:59:54
その昔、Win3.1の時代に漢字対応の必要をアメリカ人に説明しようとしたら、
通訳が「Chinese Characters」って訳しやがって説明に苦労したもんだぜ。
281:デフォルトの名無しさん
07/12/07 15:02:01
もうUTF-8で全部解決だろ
282:デフォルトの名無しさん
07/12/07 16:58:25
Unicode の符号化という点ならそうだけど
Unicode に入れられそうもない変体仮名とかを
符号化する場合を考えると Unicode だけに
頼れないし
283:デフォルトの名無しさん
07/12/07 18:32:19
plain textは諦めてくださいと遠くからUnicode神の声が聴えてきました。
ところで変体仮名のみの文字集合は既に定義されているのですか?
あるとすれば、どういう包接基準を採用しているのですか?
284:デフォルトの名無しさん
07/12/07 20:36:47
るりーる
285:デフォルトの名無しさん
07/12/07 21:04:53
>>272
>>265みたいなことをしたらShift_JISと同じ(もっと悪い)問題が起きるって
言ってるんだが。
>>282
入らないのは日本が入れろと言わないから。
異体字だって結局米国企業のAdobeが登録するまで日本は
なーーーんにもしなかった。
286:デフォルトの名無しさん
07/12/07 21:05:18
>>283
とりあえずTRONにはあるようだ
URLﾘﾝｸ(ja.wikipedia.org)
287:デフォルトの名無しさん
07/12/07 21:06:31
>>283
TRONコードに住民基本台帳収録変体仮名とその他の変体仮名が入ってる。
ということは住基統一コードにも変体仮名が入ってるのか
288:デフォルトの名無しさん
07/12/07 21:12:47
こういう文字をUnicodeに入れてくれって言う場合の
日本側の窓口はどこなんだろ。経産省？
密室でやらずに一回ぐらいパブリックコメントの募集してくれよ。
289:デフォルトの名無しさん
07/12/07 21:14:56
こんだけオープンにやってて密室もへったくれもあるか
URLﾘﾝｸ(std.dkuug.dk)
IVDの前回の公開レビューだって
URLﾘﾝｸ(www.unicode.org)
終了一週間くらい前になって気づいた俺が触れて回るまで
日本で取り上げているサイトが一切なかったという関心のなさっぷり
それで密室とかなんとかいっても説得力のかけらもない
290:デフォルトの名無しさん
07/12/07 21:37:49
そこへ持ってゆく文字の選定をしている日本側の窓口の話をしてるんだが。
291:デフォルトの名無しさん
07/12/07 22:11:20
とりあえず、英語が読めない人は、翻訳者を雇わないと、
投稿手順すら分からないのではないかと。
292:デフォルトの名無しさん
07/12/07 22:17:00
>>287
wikipediaにあるわw
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(www.chokanji.com)
TRONは何でもぶちこみ方式だろうから、
まだ異体字の包接基準はないのかな。
かなり知識がないと無理だね。
293:デフォルトの名無しさん
07/12/09 10:03:04
TRONはコード表はフリーなんだけど
その運用に事実上必要な異体字のデータベースで金稼いでるんだよね
超漢字検索で変体仮名を検索すると関連字として対応する漢字やひらがなが
出てくるし漢字から変体仮名を検索することもできる
294:デフォルトの名無しさん
07/12/09 12:07:54
いっそ日本代表は無視してUTCのfull memberになったほうが話が早いかもしれない
英語力と金が必要だけど
295:デフォルトの名無しさん
08/01/02 16:32:43
あけましておめでとうございます
結局JIS X 0221の改訂版は2007年中に出ませんでした。
JIS X 0213:2004で2004となるべきところが2003となるような誤植が
今回も発生するのでしょうか。
296:デフォルトの名無しさん
08/01/05 01:13:42
>>295
えっまぢ！？
そういや、12月20日前後の官報がデッドラインだと聞いてたんだけど、
チェックするの忘れてたよ。。。
あーあ、また関係者は地獄を見ることになるのかな・・・
297:デフォルトの名無しさん
08/01/05 01:33:09
そうこうしている間にもamendmentは増えてゆく～
298:デフォルトの名無しさん
08/01/05 01:43:49
>>296
ietf-charsetsで外人が「Hey, 内容変更が何もないのにどうして-2003が-2004
になったんだい? (大意)」みたいなことを安岡センセイに聞いてたのを思い出した。
そりゃ知らないやつは不思議に思うよなあ
299:デフォルトの名無しさん
08/01/05 06:06:50
ちゃんと出てるじゃん
制定年月日2007/12/20になってるから本当にギリギリだったみたいね
300:デフォルトの名無しさん
08/01/05 07:17:14
JISCで閲覧できる規格票が
CJKU_SR.txtをわざわざ50MBのPDFにしてたりしてワロタ
301:デフォルトの名無しさん
08/01/12 07:17:23
>>300
中の人が内規かなにかに従った結果なんだろうね
302:デフォルトの名無しさん
08/01/12 12:12:01
見た目までコントロールしたいからでしょ。
フォント環境の違いで誤解が生じないように。
303:デフォルトの名無しさん
08/01/12 12:27:42
仮にそうだとしてもフォントを埋め込めば済む話ではないの？
304:デフォルトの名無しさん
08/01/12 12:28:15
ただ数字が並んでるだけなのにどう誤解するというのだ
そもそも正文がテキストファイルなんだが
305:デフォルトの名無しさん
08/01/16 19:29:38
質問です
URLﾘﾝｸ(www.ac.cyberhome.ne.jp)
> 1文字毎をメモリに持つのではなく全てバイト列で処理すると言った方法の為、
> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが
普通のi18n対応アプリケーションは文字ごとに(codepointごとに?)
メモリに確保して、文字配列として処理されることが多い、けれども
バイト列で処理する…バイト列を喰わせても大丈夫な関数を用意して文字を操作する
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
*Javaとかのアプローチはcodepointごとに文字を操作。(分解合成がめんどい)
*Vimのアプローチはバイト列を独自関数で文字として操作。(patch workの集大成)
oniguruma とか sakura editor とか emcode.pm とか身近にあるのは
みんなpatch workの集大成なのですか？
306:デフォルトの名無しさん
08/01/16 19:40:01
> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが
ん、じぶんの理解だとここの部分の意図が汲めなくなるか…
内部で Unicode の codepoint に従って処理しているソフトは
あまりないけど…内部でなんらかのエンコードに変換して保持
してるソフトは多くて…でもVimはバイナリのまま保持するですよ…?
というような意味とか? ああなんかよくわからなくなってきた…orz
307:デフォルトの名無しさん
08/01/16 21:53:51
マルチバイト or ワイド文字と分解合成とは直交する問題だろ。
何が言いたいのだろう。
308:デフォルトの名無しさん
08/01/17 13:22:34
まともなi18nの仕事で「patch workの集大成」でないものなんてないぞ。
全ての文字、言語に通じている人間なんていないのだから。
309:デフォルトの名無しさん
08/01/17 14:09:39
仕様が実際patch workだからな
というか言語というものがそもそも...
310:デフォルトの名無しさん
08/01/18 14:46:18
>>307
URLﾘﾝｸ(anond.hatelabo.jp)
>喫煙と、麻薬や飲酒は直交する問題だと思いますが…
直行する = 相関性のみられない事象のこと = 分けて論じるべき議題
うむ。まずじぶんは小学生あたりからやり直すべきか。
てか日本語って難しいな orz
>>308-309
㌧くす。言語は日々の積み重ね。ちぃおぼえた
311:デフォルトの名無しさん
08/01/18 15:00:13
URLﾘﾝｸ(homepage.mac.com)
>「おそらく漢字ほど難しくないからそれほどでもないと思うけど、例えば
>"than" を "then" と書く若者が増えてるよ。」っと言っていました。
>「それって全く意味が違うじゃん。」っと言ったら、「orthogonalだね。」と
>言われました。「orthogonalって何？」と聞いたら、90℃（直角）との事。
>「何で180℃じゃないの？」っと聞いたら、「反対の意味って訳じゃないけど
>（左右みたいな）、ぜんぜん違う意味だから、orthogonalって言うんだよ。」
>っと教えてくれました。面白い表現ですね！
『欧米かっ！』と言わざるを得ない…。
グラフをイメージして相関性云々とか考え出すと,
なんで90度でねじれの関係になるんだ, とかわけかわからんかった orz
312:デフォルトの名無しさん
08/01/18 15:52:55
>>310
> >>307
> URLﾘﾝｸ(anond.hatelabo.jp)
> >喫煙と、麻薬や飲酒は直交する問題だと思いますが…
> 直行する = 相関性のみられない事象のこと = 分けて論じるべき議題
誤変換かもしれないが、直交と直行を混同するようでは先がおもいやられる...
313:デフォルトの名無しさん
08/01/18 16:25:40
本来の意味で使ってる可能性も・・・
314:デフォルトの名無しさん
08/01/18 17:07:36
>>310
文脈から汲めば、分けられないってことだろ
とはいえ>>312みたいな態度が一番気に食わん
315:デフォルトの名無しさん
08/01/18 17:59:53
直交ずる～というと2つのベクトルの内積(2直線の射影でもいいや)を考えるでしょ常考。
高校数学程度の概念は常識として知っておいてくださいな。
316:デフォルトの名無しさん
08/01/19 03:20:48
この文脈でそんな本来の意味の用語を使うわけないでしょ。
それくらい想像力働かせてくださいな。
317:デフォルトの名無しさん
08/01/19 07:02:46
直交⇔互いに独立
∴2つのベクトルの内積(2直線の射影でもいいや)=0
318:デフォルトの名無しさん
08/01/19 07:08:44
「2つのベクトルの内積(2直線の射影でもいいや)」が0以外の値を持つとき
それらは直交しない
つまり「直交」については最初から一貫して「本来の意味」で使われているw
馬鹿は >>315
319:デフォルトの名無しさん
08/01/19 12:20:41
数学総合スレはここですか?
320:デフォルトの名無しさん
08/01/19 14:12:35
>>319
直帰を許可します
321:デフォルトの名無しさん
08/01/21 00:06:37
ん？この流れム板のどこかのスレで見た気が。デジャヴ？
322:デフォルトの名無しさん
08/01/30 01:45:55
SJIS2004とかJISX213系の文字コード表って無いですかね
どうも変換がうまくできない・・・
323:デフォルトの名無しさん
08/01/30 07:47:52
JISCにあるじゃん
324:デフォルトの名無しさん
08/01/30 23:27:43
JISCのPDFから手で書き取れと申すか
※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
とりあえず機械可読な奴がほしかったらここでも見れ
URLﾘﾝｸ(x0213.org)
325:デフォルトの名無しさん
08/01/30 23:32:34
＞※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
ごめんJISCを甘く見てた……
326:デフォルトの名無しさん
08/01/30 23:40:52
JISC・・・ひでえな。
327:デフォルトの名無しさん
08/02/01 21:15:44
www.unicode.org落ちてる?
328:デフォルトの名無しさん
08/02/05 21:26:41
Joel Spolsky氏のブログ翻訳「ソフトウェ開発者なら絶対に最低限知っていなければならないユニコードと文字セットについて」
Servlet Garden ≫ Unicode and Character Sets (Translation)
URLﾘﾝｸ(www.t3.rim.or.jp)
329:デフォルトの名無しさん
08/02/05 23:42:35
Unicode Transformation Format 8 と UCS Transformation Format 8 で混乱するのだけど
それぞれをどう解釈したらいいんだろう？
330:デフォルトの名無しさん
08/02/05 23:56:23
略せばどっちもUTF-8。はい、同じ。
331:デフォルトの名無しさん
08/02/06 00:00:19
Unicode.orgがつけた名前
ISO/IECがつけた名前
中身おんなじ
332:デフォルトの名無しさん
08/02/06 00:11:42
互換性あるのはわかったけど、Unicodeのが4バイト、
UCSのが6バイトみたいなこと書かれてたんで5バイト目以降は違うってことかな？
333:デフォルトの名無しさん
08/02/06 00:32:16
ISO/IEC 10646はAmd2:2006で、0群17面以降には永久に文字を追加しないことにしたから
UTF-8にしたときには5オクテット以上にはならない。
Uniocde.org的には、単に追加予定なしなだけなので、UTF-8は理屈上最長の
6オクテットまで使っていいけど、でも文字入ってないよ？状態。
だから、結局中身おんなじ
334:デフォルトの名無しさん
08/02/06 01:09:46
もともとUnicode的にUTF-16の絡みで10FFFFまでになって、
おれにAmd2:2006で追従したんじゃないっけ。
どちらにしろ、今はどちらも4byteまで。
URLﾘﾝｸ(www.rfc-editor.org) 参考までにRFC
335:デフォルトの名無しさん
08/02/06 02:42:04
なるほど。納得できたありがとう。
336:デフォルトの名無しさん
08/02/06 18:15:44
いつの間にかIVS(漢字のVS)正式に決定してた。
URLﾘﾝｸ(www.unicode.org)
337:333
08/02/07 08:54:13
>>334
そうみたいね
俺古いRFC見てたわ
338:デフォルトの名無しさん
08/02/19 23:13:06
U+FDD0～U+FDEFが使用禁止になったのって何でだろう?
339:デフォルトの名無しさん
08/02/22 20:04:35
JIS X 0221:2007規格票の8. 注記3によると
「符号化文字でないことが保証された数値を必要とする内部処理」に使用するためだそうだ。
例として「表を終了させる、テキストの終わりを通知するなど」が挙げられてる
340:デフォルトの名無しさん
08/02/23 03:05:40
文字コードふぜいが表の終了とか意識するな。
341:デフォルトの名無しさん
08/02/23 08:30:49
文字集合はともかく、
符合化方式がその辺りを考慮するのは当然。
342:デフォルトの名無しさん
08/02/23 09:17:36
あとU+FFFFはBMPの最後のコードだから番兵に使うことを特に意識している
U+FFFEは言うまでもなくBOM判別用
343:デフォルトの名無しさん
08/02/23 13:25:24
ASCII にだってコントロールコードの領域があるしね
344:デフォルトの名無しさん
08/03/12 02:47:39
文字コードとやらに興味を抱き、とりあえずユニコードが標準と知り、
番号からUTF-16を使っていたのですが、
このスレの人は何を主に使っているのですか？
検索をしていると16よりも8の話題のほうが見つかるので、
実は8のほうがいいのかなと悩んだりしています。
345:デフォルトの名無しさん
08/03/12 03:08:25
つか、今、同じテキストファイルを変換してみたのですけれども、
よくよく考えたらUTF-8は可変で日本語の文章に関しては、
全てを2バイトで扱うUTF-16に比べて、
日本語部分を3バイトで扱うUTF-8は情報量が多いほど、
容量が無駄に大きくなってしまいませんか?
1.5倍ですよね。それを補うほどの使い勝手の良さがあるのでしょうか。
346:デフォルトの名無しさん
08/03/12 03:14:34
南北アメリカや西ヨーロッパの多く言語は平均すると一文字当たり2オクテット未満であらわせる。
347:デフォルトの名無しさん
08/03/12 03:27:30
後は１要素が1byteに収まるから扱いが楽、とか
まぁ日本語を基準に考えてる時点でUnicodeの思想から外れてる気はする
348:デフォルトの名無しさん
08/03/12 09:29:53
>>344
1.5倍程度でけちけちするな、多言語化ってのはそういうもんだ。
マジレスするとUTF-8側にメリットがあるというよりも、
UTF-16側がサロゲートペアやバイトオーダー、ASCII非互換、guessしずらいなど、
いろいろと面倒なのでUTF-8の方がよい。
349:デフォルトの名無しさん
08/03/12 10:57:52
WindowsがUTF-16なんで、自分のプログラムもUTF-16です。
350:デフォルトの名無しさん
08/03/12 23:33:43
ケチ臭いことを言うんだったら、ASCIIの制御文字の部分の方が勿体無いと思うけどね。
ホントにASCIIてクソだなあ。
351:デフォルトの名無しさん
08/03/13 02:21:38
ASCIIが7bitで治まってくれていて良かった。
ISO 8859-1みたいなんじゃなくて、ASCIIが8bit、
×も≠も欲しいなんて言い出さなくて本当に良かった。
奴等が重ね打ち馬鹿で本当に良かった。
352:デフォルトの名無しさん
08/03/13 19:16:38
すみません、
EUC-JP 系のエンコーディング（含 eucJP-ms, CP5132）においてどういう文字が
割り当てられているかを知りたいのですが、いいウェブページはないでしょうか。
353:デフォルトの名無しさん
08/03/13 20:07:35
>>2
354:デフォルトの名無しさん
08/03/13 20:25:25
そーいや、opengroup の eucjp-ms とユニコードの変換表のページはもう見れないのかな？
355:デフォルトの名無しさん
08/03/13 21:04:03
utf8がascii互換でソースに書いたり、ファイルに書き出すには一番使い勝手はいいと思う。
WinならAPIとの互換性のために、メモリ上はutf16が良い。Shift_JISに変更する気はあんまり起きない。
パーサーなどで、コードポイントを等間隔で扱いたいときにはutf32にしてる。
356:デフォルトの名無しさん
08/03/13 21:27:56
>>353
やはりそこら辺ぐらいですか?
まずは1バイト部分が気になっていたのですが、
>また、16進数で「21」～「7E」の文字にASCIIとJIS X 0201ローマ文字のいずれを使うかは、
>歴史的にはASCIIの方が正しいのですが、実際には使う人の自由にまかされます。
ということは例えば0x5cはreverse solidusでもyen signでも好きな方使え、ということ
なのかな? とほほー。
357:デフォルトの名無しさん
08/03/13 21:41:13
すみません、機種依存文字は、どうして、存在しますか、？
ローマ数字とか、文字化ける、現象の、ことです
358:デフォルトの名無しさん
08/03/13 22:03:50
各ベンダが似て非なる文字コードを使い続けたから。
359:デフォルトの名無しさん
08/03/13 22:22:37
似て非なる文字コードが多くて、判定をミスるからでそ。
360:デフォルトの名無しさん
08/03/13 22:28:35
>>354
numa氏が転載してくれてる
URLﾘﾝｸ(blog.livedoor.jp)
361:デフォルトの名無しさん
08/03/13 22:40:03
>>359
表示できない文字のことを言っている。>>357
362:デフォルトの名無しさん
08/03/13 22:41:16
>>357
お国はどちらで？
363:デフォルトの名無しさん
08/03/13 23:17:28
西村京太郎が書き込んだんだよ。
364:デフォルトの名無しさん
08/03/14 09:14:19
>>352
URLﾘﾝｸ(legacy-encoding.sourceforge.jp)
多分こっちの方がいい。
なお、IANA Charset では EUC-JP は ASCII だし、eucJP-ms, eucJP-ascii CP51932 も ASCII だぞ。
eucJP-0201 が JIS X 0201 Roman。
365:352
08/03/14 09:55:43
>>364
ありがとうございます。
>なお、IANA Charset では EUC-JP は ASCII だし、eucJP-ms, eucJP-ascii CP51932 も ASCII だぞ。
>eucJP-0201 が JIS X 0201 Roman。
なるほど。JIS X 0201 Roman はマイナーですね。
なお、今ググったら ICU のサイトもヒットしたので、そっちも参照してみます。
iconv や Perl-Encode なんかはこの辺どうなってるのかな。
しかし EUC-JP 系ってナニゲにタチが悪いですね。下手すると SJIS 系より悪いのではw
366:デフォルトの名無しさん
08/03/14 11:08:59
IANA charset repositoryのは、きっちり決まっているから何も問題ないぞ?
独自改変があるのは、どのコードでも同じだし。
その辺まで全部気にしたいのなら、Windows上でベンダー共同の文字拡張、
firefoxのEUC拡張とか、いろいろありすぎてやってられないと思う。
367:デフォルトの名無しさん
08/03/14 11:59:42
>>365
iconv は glibc iconv と libiconv と 森山さんのパッチ済み libiconv と Citrus iconv でも違って、
「EUC-JP」での \x00-\x7F までは ASCII と考えていい、これは IANA で定義されてるから。
ただ、それより多バイトは実装による。
Perl/Encode は Shift_JIS も EUC-JP も \x00-\x7F は ASCII だね。
なお、Shift_JIS は IANA 定義では \x00-\x7F が JISX 0201Roman なことに注意。
これにしたがっている実装はあまりないが、たまにあるので地雷。
ていうか、Shift_JIS でなく Windows-31J/CP932 を使えばトラブルは少ないのでこちらの方が回避は楽。
368:352
08/03/14 13:43:47
>>366 >>367
どうも有益な情報をありがとうございます。
文字コード処理にどのぐらい挙動の幅を持たせるかとかを悩んでいます。
>>365さんも書かれてますが、例えばHTMLでcharset=Shift_JIS or EUC-JPとなっている
が、拡張漢字のコードが入ってた場合（これは結構ある）にどうするかとか。
あと、差のある部分（全角記号等）をどっちだと思って処理するかとか。
369:デフォルトの名無しさん
08/03/14 14:01:57
サーバ側で、かつ、どのクライアントに対してもきっちりやりたいなら、
User-Agent: をみて、独自の拡張、改変にちゃんと対応するしかない。
firefoxのケースはググれば出てくる。
CP51932関連も読んでおいた方がいい。
370:デフォルトの名無しさん
08/03/15 06:16:20
>>365
Shift_JISだって、CP932、Shift_JISX0213、Shift_JIS-2004などの変種がある。
むかし補助漢字を無理やり埋め込む変種もあった。
> Windows上でベンダー共同の文字拡張、
eucJP-ms?
371:デフォルトの名無しさん
08/03/15 09:41:00
> 補助漢字を無理やり埋め込む変種もあった。
kwsk
そういう噂は聞いたことあるけど実際にどんな仕様だったのか調べてもわからない
372:デフォルトの名無しさん
08/03/15 10:19:31
>>370
> Shift_JISX0213、Shift_JIS-2004などの変種がある。
これって名前以外に違いあるんだっけ？
373:デフォルトの名無しさん
08/03/15 10:41:07
Shift_JISX0213は、JIS X 0212:2000に、
Shift_JIS-2004は、JIS X 0212:2004に基づいている。
UCS互換文字が10文字追加されている。
追加だから、表示などの用途に限れば、
Shift_JIS-2004だけで十分だが、
文字集合チェックしたければ区別する必要がある。
(>>352はそういうことをEUC-JPについて知りたいようだったので書いた)
374:デフォルトの名無しさん
08/03/15 10:54:07
そもそもサポートする必要ないよ、とか言ってみる。
増やせば増やすほど混乱の種が増す。
とくに「レガシー」エンコーディングプロジェクトのくせに新しいことをやりたがる奴らは
まとめて氏ね
375:デフォルトの名無しさん
08/03/15 10:58:43
BMP氏ね
376:デフォルトの名無しさん
08/03/15 11:00:35
時代はPNGです(そっちか)
377:デフォルトの名無しさん
08/03/15 11:26:08
>>373
thx
378:デフォルトの名無しさん
08/03/15 13:22:46
>>372
当時のfj.kanjiにいくつかの提案をまとめた記事があったはず。
379:デフォルトの名無しさん
08/03/15 14:11:30
うーんGoogle Groupsには残ってないようだ
当時ニュースグループには参加してなかったからログを探すのが困難だ
380:デフォルトの名無しさん
08/03/15 16:42:56
>>374
>そもそもサポートする必要ないよ、とか言ってみる。
世界中のソフトが足並みを揃えられればいいんだけどね。
現実的にはより「好意的に」データを処理してくれるアプリの方が
ユーザーのウケが良くて、困ったものだ。
それに「レガシー」とはいうものの、メールでもウェブページでもまだバリバリに
使われてるわけだし。
381:デフォルトの名無しさん
08/03/15 16:54:50
なにせここも Shift-JIS だしな
382:デフォルトの名無しさん
08/03/15 18:46:28
>>380
さすがにShift_JIS-2004をサポートした方がユーザーの受けがいいってことはないだろ
むしろ円記号や名簿の高橋さんが文字化けする! とか苦情が増えそうな気がする
383:デフォルトの名無しさん
08/03/15 18:47:21
> 世界中のソフトが
日本中のソフトだけだろ。
最近のソフトやプロトコルは日本人が口出ししない限りUTF-8のみなんて珍しくもないぞ
384:デフォルトの名無しさん
08/03/15 18:53:04
> それに「レガシー」とはいうものの、メールでもウェブページでもまだバリバリに
> 使われてるわけだし。
まだ使われているものをサポートすることは別に反対してない。
現在誰も使ってないどころかかつて使われたことすらないものを
「よかれと思って」付け足そうとする奴は氏ねと言ってる。
ISO-2022-JP-MSとか(頓挫したけど)
NEC選定IBM拡張漢字とIBM拡張漢字にVS付けて区別するとか
正気とは思えない
385:デフォルトの名無しさん
08/03/15 18:53:56
JIS X 0213のせいで日本の悲惨さ倍増w
386:352
08/03/17 04:46:50
皆さんどうも。
Win上だと例えばcharset=EUC-JPだけど実はCP51932なHTMLとかは
あんまり問題にならないのかもしれませんが、非Winだとそうでもなくて、
ちょっと情報を必要としていました。
ウェブブラウザとかメールソフトとかデータベースとか、日本人が開発の
中心にいないものも少なくないんじゃないですかね。そうすると日本語の
エンコーディングに関するバグの説明とか、面倒ですね。
387:デフォルトの名無しさん
08/03/17 05:01:27
糞会社が勝手に文字集合を独自拡張するのがまずいのであって、
受け手が四苦八苦しているのが悪いわけではない。
388:デフォルトの名無しさん
08/03/17 08:01:19
どうでもいいけどWin3より前の時代にアメリカの技術者と話をするときに、
通訳が「漢字」を"chinese characters"と訳すのには閉口させられたなぁ。
現物見せてやっと話が噛み合ったよ。
389:デフォルトの名無しさん
08/03/17 12:18:12
ややこしいが漢字を Chinese characters としている和英辞書があるんだよな。
大昔、千年以上前の日本人にとっては、漢字≒中国語文字かもしれないが
現代の日本人が漢字といえば国字 Japanese characters で漢字体のものを
指すのが普通だな。
通訳は空気を読むべきだと思うが、通訳が頼りない場合は
漢字だと誤訳・誤解されるおそれがあるので日本文字 Japanese characters と
言ったほうがいいかも。
390:デフォルトの名無しさん
08/03/17 12:31:27
普通「漢字」は「ひらがな」「カタカナ」を含まないけど、
文字コードの世界では、含めて「漢字」ということがあるからややこしい。
本来の狭い意味での「漢字」なら、
Japanese Charactersの中のChinese Charactersってことで問題ないはずだけど。
391:デフォルトの名無しさん
08/03/17 12:37:28
最近はKanjiで通じるようになってきたから嬉しい。
392:デフォルトの名無しさん
08/03/17 12:38:11
もうKanjiでおｋ
393:デフォルトの名無しさん
08/03/17 12:44:23
CJK Unified Ideographs のことだろ、Kanji って
ってな、合ってるんだけど間違ってる理解が今後増えそうで嫌だ
394:デフォルトの名無しさん
08/03/17 12:48:45
>>391>>392
それってひらがな、かたかなは含む?
395:388
08/03/17 12:55:49
あー、そんときは通訳が(理由は忘れたが)席を外したんで、
隙を狙って"Kanji is Japanese special character, not only Chinese."みたいなことを言った希ガス。
当然向こうは"???"となったから、「現物を見せましょう」という流れに持ってった。
# んで、「Windowsじゃそんな文字出せない」みたいなこと言われたんだよなw
396:デフォルトの名無しさん
08/03/17 13:15:36
>>394
391でも392でも無いけど、俺の知っている範囲では「含まない」。
たとえば、日本語学習者とか、日本の漫画やアニメのファンが
"HiraganaやKatakanaは何とかなるけど、Kanjiはホントに難しいyo"
とか、そういう風に口にする。
397:デフォルトの名無しさん
08/03/17 13:52:28
>>394
文字コードのことをちゃんと勉強してる技術者には、
KanjiっていえばHan charactersのうち日本語で使われてる文字だって伝わる。
Unicode万歳って感じだわ。
398:デフォルトの名無しさん
08/03/17 15:17:07
JISの「漢字集合」にはひらがなカタカナも含んだな
399:デフォルトの名無しさん
08/03/17 19:06:02
JIS X 0208の「漢字集合」だとラテン文字やキリル文字まで含むけど、
「漢字」だと漢字だけだよな。
400:デフォルトの名無しさん
08/03/17 23:49:15
JIS X 0208の「非漢字」のうち1文字はUnicodeでは漢字扱いだったな
Unicode 1.0では非漢字領域にもあったけどUnicode 1.1でunifyされたらしい
と安岡センセイか誰かの日記で読んだ
401:デフォルトの名無しさん
08/03/18 00:22:44
更級日記？
402:デフォルトの名無しさん
08/03/18 07:53:24
"仝" だっけ。一部の人にはハートマーク差し替え記号として知られるw
"〆" は文字だっけ？ JIS では記号だけど。
403:デフォルトの名無しさん
08/03/18 08:03:36
>>402
〆は0208由来の非漢字と補助漢字由来の漢字が両方入ってる
EUC-JPとラウンドトリップコンバージョンを確保する必要があるから
404:デフォルトの名無しさん
08/03/18 12:50:52
unicodeで
アファベットかどうかやひらがなかどうかやカタカナかどうかとか
文字種別みたいなものをロジック的に判別する方法ありますか？
それともSJISとかみたいに力任せですか？
あと濁点の「が」と「かﾞ」みたいなのを正規化する方法って決まってませんか？
405:デフォルトの名無しさん
08/03/18 13:11:04
>>404
>文字種
そういうAPIがあるプログラム言語とかライブラリ使え
どれがどの文字種かは >>unicode.org
>正規化
決まってる >>uniocde.org
406:デフォルトの名無しさん
08/03/18 15:00:42
>>405
>正規化
結合文字の正規化目的でNFCを使うとCJK互換漢字でハマるから注意
407:デフォルトの名無しさん
08/03/18 20:19:07
「神」が化けるとかだっけ
408:デフォルトの名無しさん
08/03/18 22:28:39
URLﾘﾝｸ(internet.watch.impress.co.jp)
409:デフォルトの名無しさん
08/03/19 00:28:49
Unicodeの正規化といえば、MediaWikiが外部から入力された文字列を全部正規化しやがって、
互換漢字を入力できずに困ったことがあったわ。
410:デフォルトの名無しさん
08/03/19 07:34:46
>>407
ファイル名が Unicode ベースなファイルシステムだと何らかの正規化がなされていると
思うけど、同じ場所に「神」という名前のファイルと「神」とのいう名前のファイルを作ろうと
したら、どうなるべきなのかな?
411:デフォルトの名無しさん
08/03/19 07:43:42
>>410
手元のWindowsXP/NTFSだと U+00C4 と A+U0308 を別々に作れた、なので正規化はしてないっぽい。
MacOSXだと作れないだろうね。
412:デフォルトの名無しさん
08/03/19 10:01:39
>>410
> > 何らかの正規化がなされていると思うけど
Mac OS Xくらいしか知らないよ。
Windows, UNIX系ではないんじゃない？
413:デフォルトの名無しさん
08/03/19 10:08:51
>>411
MacOSXでも作れる。
OSXのVFSはNFDに準じたファイル名の正規化を行うが、互換漢字は対象外
414:デフォルトの名無しさん
08/03/19 14:30:19
>>413
VFSじゃないだろ?
CarbonとHFS+でやってんじゃない?
すくなくとも10.3の調査ではそうだった。
だからターミナルからUFSやNFS上にファイルを作成すれば、
ファイル名はNFDされてなかった。
415:デフォルトの名無しさん
08/03/19 17:17:53
>>412
ほんとに? 正規化されてないUnicodeでファイル名を扱うっていうのは
混乱を招くような気がするのだが...
416:デフォルトの名無しさん
08/03/19 18:49:29
データそのものを正規化してしまうような仕組みは嬉しくないなあ。
正規化はソートや検索の時に動的にしてくれたほうが嬉しい。
417:デフォルトの名無しさん
08/03/19 19:02:26
>>416
ヘテロな環境で正規化の方法が違った場合、
USBサムドライブで困るよね。
418:デフォルトの名無しさん
08/03/19 20:53:24
>>414
Technical Q&A QA1173
Text Encoding in VFS
URLﾘﾝｸ(developer.apple.com)
URLﾘﾝｸ(developer.apple.com)
419:デフォルトの名無しさん
08/03/19 21:16:22
>>418
この文章だと10.2の頃からそうなっているみたいだけどそれは嘘。
Darwinのソースコード＆テストで調べた。
420:デフォルトの名無しさん
08/03/19 23:00:27
>>415
むしろ下手な正規化(大文字と小文字の同一視とか)をされるより
個々のアプリでの扱いに任せてもらった方が混乱は少ないよ
421:デフォルトの名無しさん
08/03/19 23:19:28
小文字と大文字の同一視は、
Mac, Winでそうだから避けられないのかねえ。
カタカナとひらがなはどうなんだとかきりがないねえ。
422:デフォルトの名無しさん
08/03/20 00:29:04
>>420
そうじゃなくて、NFCとかNFDとか、上に出てたでしょ。
423:デフォルトの名無しさん
08/03/20 00:54:10
>>419
まあ「VFS API」というのが実際に何を意味するかですかね。もしかして UNIX の
ファイルアクセス用の API （システムコール）程度の意味なのかも。
かつ HFS+ のことだけを念頭においているのかも。NFS とかは「例外」扱いだし。
実際 UFS や NFS は正規化はしないですね > Mac OS X
424:デフォルトの名無しさん
08/03/20 01:41:14
>>409
MediaWikiでは正規化されたくない文字は文字参照にするしかないね
それでも項目名には使えない
425:デフォルトの名無しさん
08/03/20 01:43:01
>>421
つ[Collation]
ただし事前処理として正規化が前提になってるのでもし互換漢字のソート順を
統合漢字と変えたかったりしたら使えない
426:デフォルトの名無しさん
08/03/20 07:50:55
>>423
HFS+オンリーで「VFSが」というもの…w
427:デフォルトの名無しさん
08/03/20 23:07:19
OS：WindowsXPproSP2
アプリ：DreamWeaverMX
DreamWeaverMXでhtmlファイルを新規作成したとき、<META>タグは以下の記述でした。
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
ここではcharsetで文字コードShift_JISを指定していますが、ページをIE6.0以降で見られることを想定した場合に
文字化けをできるだけ減らすためには、charsetの値はどのようにすればいいのでしょうか？
428:デフォルトの名無しさん
08/03/20 23:26:38
そのままでいいよ
429:デフォルトの名無しさん
08/03/20 23:50:02
板違いだからweb制作でも行け
430:デフォルトの名無しさん
08/03/21 12:26:11
>>428-429
了解。ありがとう
431:デフォルトの名無しさん
08/03/23 16:34:58
EUC-JP と宣言しながら CP51932 なウェブページがかなりあるのに
CP51932 相当の IANA 名を定義するような動きはなかったんですかね。
Shift_JIS と Windows-31J の区別はあるんだし。
432:デフォルトの名無しさん
08/03/24 00:50:39
CP51932だってどうしてわかるの
433:デフォルトの名無しさん
08/03/24 08:29:22
>>431
どれぐらい多いの？
日本語で書かれているウェブページのうち、何%がEUC-JPと宣言されてい
て、そのうち何%が実際はCP51932なの？
434:デフォルトの名無しさん
08/03/24 09:39:56
windows-31jって、今からでもwindows-932にならんかね。aliasでもいいんだけど。
他のwindows-コードページの番号ってなってるコードページと一貫性がない。
435:デフォルトの名無しさん
08/03/24 11:06:44
0x81～0x9Fの文字がある=Shift-JIS
0xFD～0xEFの文字がある=EUC
って解釈でいい？
436:デフォルトの名無しさん
08/03/24 14:55:39
まさか
437:デフォルトの名無しさん
08/03/24 19:59:20
そんな楽で良いなら
438:デフォルトの名無しさん
08/03/24 20:04:29
世の中に一体いくつの文字コードがあることか
439:デフォルトの名無しさん
08/03/24 20:06:57
UNICODEの存在意義がなくなる
440:デフォルトの名無しさん
08/03/25 00:08:24
>>434
Microsoftがietf-charsetsに提案してたようだが例によって途中からｇｄｇｄ
URLﾘﾝｸ(mail.apps.ietf.org)
こんなだからみんな面倒な登録手続きなんか無視して
好き勝手にcharset使い出してカオスになるんだろうな。
そういやISO-2022-JP-2004の登録手続きはどうなりましたか安岡センセイ
URLﾘﾝｸ(www.jstage.jst.go.jp)
こんなもの書いてる暇があったらShift_JIS-2004登録してください
規格通りに使いたくても使えないじゃないですか
441:デフォルトの名無しさん
08/03/25 00:09:56
もう全部x-つけといたらいいよ。
442:デフォルトの名無しさん
08/03/25 00:16:39
つーかさー
URLﾘﾝｸ(mail.apps.ietf.org)
なんでMartin Duerstセンセイともあろうお方が今さらこんなこと言ってるの?
RFC 1192ご覧になったことあります? つーか
> We also wish to thank the following people who contributed in many
> ways towards this document.
> Zhang Zhoucai Martin J. Duerst
見てないはずがないんだけど。
何でcharset-extensionとcharset-editionはみんなに無視されたのに
今度はうまくいくとか無邪気に思い込めるわけ?
443:デフォルトの名無しさん
08/03/25 00:17:15
RFC 1922の間違いorz
444:デフォルトの名無しさん
08/03/25 00:23:06
>>440
いやそのドキュメントは有意義だと思うよ。
ちゃんとまとめて、読めるようにしとかないと、
独自コード乱発は加速するばかりだから。
445:デフォルトの名無しさん
08/03/25 01:19:23
>>431
CP51932 相当の IANA 名をWindows-31Jって言うんじゃね？
テキストエンコーディングが何だろうと、文字集合は同じでしょ。
446:デフォルトの名無しさん
08/03/25 11:35:01
>>445
IANA charsetの「charset」は文字集合+符号化方式のセット
447:デフォルトの名無しさん
08/03/25 11:38:59
>>440
Martinセンセイにドキュメントがないだとか色々突っ込まれて力尽きてたはず。
使いたいなら後をついで進めるといいのかもしれないけど、
必要なドキュメントをJISが握ってる以上難しい気もしないでもない。
448:デフォルトの名無しさん
08/03/25 11:56:26
流れぶった切ってすまん。
日立のEBCDIKコード表探してるんだけど、
URLﾘﾝｸ(www.wdic.org) とか
URLﾘﾝｸ(www.pleasuresky.co.jp) とかじゃなくて
日立が提示してるオリジナルがいいんだけど、どっかにないですかね？
449:デフォルトの名無しさん
08/03/25 12:01:21
URLﾘﾝｸ(www.pleasuresky.co.jp)
450:デフォルトの名無しさん
08/03/25 12:04:00
>>449
なにこの汚いコードは
451:デフォルトの名無しさん
08/03/25 12:13:23
文字コードの判別、変換に挫折した…
情けねぇ…
452:デフォルトの名無しさん
08/03/25 18:13:48
EBCDIC くらいは知っとこうぜ
453:デフォルトの名無しさん
08/03/25 21:14:53
>>444
ドキュメントの有意義さは否定しないけど
実際にWebページやメールでそのドキュメントの通りに使えというなら
使えるようにしてくれなきゃ話が始まらない
>>447
俺はUnicodeでいいと思ってるからなー
使いたい人ががんばってくださいとしか
がんばらないで勝手に使うという最悪の選択だけはくれぐれもやめてほしい
454:デフォルトの名無しさん
08/03/25 21:21:11
UpperCharで
小文字 0xED40 纊
が
大文字 0xFA5C 纊
に変換されるのですが、この辺わかりやすく説明しているサイトないでしょうか～
455:デフォルトの名無しさん
08/03/25 21:35:00
>>454
URLﾘﾝｸ(support.microsoft.com)
456:デフォルトの名無しさん
08/03/25 21:41:47
>>455
非常に勉強になったよ。
ありがとう！
457:デフォルトの名無しさん
08/03/26 02:30:15
>>453
> 実際にWebページやメールでそのドキュメントの通りに使えというなら
言ってないw
458:デフォルトの名無しさん
08/03/26 02:37:51
なるほど
> ケータイの絵文字や、CP932のIBM拡張文字など
はインターネットで使うべきでないとは書いてるけど、代わりに何を使えとは確かに
直接書いてはいない。でもそれなら何で今インターネットで使えるJIS X 0208:1997
ベースのShift_JISではなくわざわざShift_JIS-2004に言及してるの?
Shift_JIS-2004の絵文字のうち
> 「♪」以外は収録されていなかった
そうだけどそれらは使っていいの? いいならcharsetパラメータには何を指定すればいいの?
459:デフォルトの名無しさん
08/03/26 08:47:40
結局世の中の流れとしてはこんな感じ?
1. いわゆるレガシーエンコーディングの、ベンダー毎の拡張みたいのは今後積極的
にはサポートされない。
-> 新たに IANA に登録されてたりすることはない?
-> charset にない文字を使っているようなのは化けてもしょうがないって感じ?
2. IBM拡張漢字、絵文字等をどうしても使いたい場合は Unicode で。
-> Windows-31J は IANA に登録されてるからアリ?
460:デフォルトの名無しさん
08/03/26 09:54:22
Windowsで扱える文字一覧みたいなものはどこかにないでしょうか？
461:デフォルトの名無しさん
08/03/26 12:14:50
コードページ毎で良ければここはどう。
URLﾘﾝｸ(www.microsoft.com)
462:デフォルトの名無しさん
08/03/26 13:04:19
>>460
U+0000からU+10FFFFまで扱えるよ
463:デフォルトの名無しさん
08/03/26 13:10:39
>>461
ちゃんと資料があったんですね。ありがとうございます。
464:デフォルトの名無しさん
08/03/26 13:12:18
>>462
すいません、ちゃんとフォントがあって表示できる
またはIMEから入力できるものという意味でした。
465:デフォルトの名無しさん
08/03/26 13:20:32
>>458
>> ケータイの絵文字や、CP932のIBM拡張文字など
>はインターネットで使うべきでないとは書いてるけど、代わりに何を使えとは確かに
>直接書いてはいない。
IANA charset登録済みのもの。
>でもそれなら何で今インターネットで使えるJIS X 0208:1997
>ベースのShift_JISではなくわざわざShift_JIS-2004に言及してるの?
なんでだろうねぇ。
Windows-31Jとして登録済みの「CP932」の方がマシだと思うんだけど。
>> 「♪」以外は収録されていなかった
>そうだけどそれらは使っていいの? いいならcharsetパラメータには何を指定すればいいの?
使っていい、Unicodeに登録されているんで、UTF-8を指定すればよい。
もちろん、JIS X 0213系のエンコーディングはダメ。
466:デフォルトの名無しさん
08/03/27 18:55:27
> Windows-31Jとして登録済みの「CP932」の方がマシだと思うんだけど。
他にも>>440の資料は突っ込みどころ大杉。
> JISにもUnicodeにも違反しており
未使用領域を使用禁止にしているJIS X 0208/0213と違ってUnicodeでPUAを
使うこと自体は何も規格に違反してない。いわば文字化けするのはUnicodeの仕様。
> Windows Vistaの方が、ある意味、正しい動作だと言える。
どっちかが正しい動作だと言うこと自体ミスリーディング。
規格を守っていても「字体化け」するのがJISやUnicodeの「仕様」。
もちろん安岡センセイがそんな初歩的なこと知らないはずがないので
確信犯なんだろうけど(とくに後者)。
467:デフォルトの名無しさん
08/03/27 20:05:38
しかし、文字コード関連は政治的な位置からものを書く人間が多すぎるな
468:デフォルトの名無しさん
08/03/27 20:16:54
文字コードはもともと政治の道具です
469:デフォルトの名無しさん
08/03/27 20:22:49
オタク好きするんだよ。政治というか、勢力争いの話はね。
そういうのが存在する分野の話になると、そこにばっかフォーカスすることになる。
それだけを固めた例としては、ゲーハー板。
470:デフォルトの名無しさん
08/03/28 00:04:05
>467
だったらネタ振ってくれ。例えばNew ASCII配列とか。
471:デフォルトの名無しさん
08/03/28 05:47:01
例まで絞るくらいなら、その話題を自分が振ればいいのに。
472:デフォルトの名無しさん
08/03/29 13:19:21
EBCDICとEBCDIKの違いがあるのも政治的な理由からですか？
473:デフォルトの名無しさん
08/03/29 15:58:10
メリケン野郎にはカナなんかいらんからだろ。
474:デフォルトの名無しさん
08/03/30 02:19:37
ICU のこのページ→ URLﾘﾝｸ(demo.icu-project.org) なんだけど、
Aliasってことは「等価な」エンコーディングって扱いなのかな?
もしそうだとすると日本語のエンコーディングに関しては鬱なような...
475:デフォルトの名無しさん
08/03/30 04:31:26
ちょっと横レスですが。
>>472-473
EBCDIKってのは日立方言だよ。
ネットではEBCDIC(カタカナ版)のことだと説明してることが多いけど、
誰かがそう書いたのをよく調べもせずに孫引きで書いている奴が多いだけ。
476:デフォルトの名無しさん
08/03/30 11:19:36
>474
「Converters with conflicting aliases」とか。
ibm-942-P12A-1999とibm-943-p15A-2003が
両方ともaliasにcp932を持ってる事の説明が付かないけど？
477:デフォルトの名無しさん
08/04/04 11:08:02
さて
Unicode 5.1のリリース予定日がやってまいりました
478:デフォルトの名無しさん
08/04/05 21:55:19
無事リリースされますた。
StandardizedVariants.htmlにIVDに関する言及が追加されますた
479:デフォルトの名無しさん
08/04/06 02:55:20
また新しい文字コードが一つ増えただけになるのか、それとも統合されるべく方向に行っているのか。
まったくこのスレのネタすら分からないけど、基本的にutf-8かutf-32?使っておけばよい?
16はなんか面倒とか聞いた覚えがあるが今はそこまで調べる気力なし…。
480:デフォルトの名無しさん
08/04/06 10:49:53
>>479
基本的に UTF-8 使っておけばよし
UTF-32、というか32ビットでの処理はアプリが内部で使う場合の話で
文字コードとして意識する必要はないよ
481:デフォルトの名無しさん
08/04/06 10:58:00
内部処理も行処理程度だとUTF-8のままってのが多いしね。
482:デフォルトの名無しさん
08/04/06 12:53:51
ユニコードで唯一の功績は UTF-8 を発明したこと。
提案したのは部外者だけど。
483:デフォルトの名無しさん
08/04/06 20:02:59
功績か?
utf-8って好き嫌いがはっきりしている気がする。
484:デフォルトの名無しさん
08/04/06 20:07:05
日本語が３～４バイトになるからなあ。
まあ仕方が無いのは分かるが。
485:デフォルトの名無しさん
08/04/06 21:08:59
>>482
Unicodeのエンコード方式の一つとしてはそうなのかもしれんが…
一長一短な気もするけど、今後Unicode対応アプリを作る上ではUTF-8はchar*で扱える
面だけ取れば悪くはないのかも
XMLとかもさ
だけど、結局ファイルやストリームから読み取る分にはUTF-8でいいけど、1～4バイトの
可変長ってのがね
処理内部はUTF-16として扱うのが一番楽だね１文字２バイトと単純計算できるし、
今はサロゲートペアのことを意識する必要が無いから
文字列はそもそもリソース定義すべきだから、ソース中に文字列で埋め込まないんであれば
エンコード方式さえはっきりしてればどうでもいいや
それより、SJISでコメント書いたソースをWindowsエミュレータやリビジョン管理(ClearCaseやCVS、SVN)
で使って、実機やテスト機(Linux)ではEUCだとコンパイル時にコメントが改行されてたりするんだよねｗ
うちんとこでは、Lunuxビルドはmakefileの中でnkfで文字コード変換されてるが…
486:デフォルトの名無しさん
08/04/06 21:19:34
> 今はサロゲートペアのことを意識する必要が無いから
いつかサロゲートペア対応に改良する暇はあるの？
初めからUTF-32にすればいいだろ。
487:デフォルトの名無しさん
08/04/06 21:26:20
ユニコードはエンコード方式がわかっても日本語とは限らないんだな。
CJKでしかないから。
488:485
08/04/06 21:33:50
>>486
Unicode 4.0を見てみたｗ
どう見ても、当面サロゲートペアを使う必要はなさそうだなあｗ
UTF-32でもいいんだけどさ、やっぱ１文字で４バイトってやだなー
特に理由ないんだけどさ
U+10000～を使うことが明らかなら別だけど、使わないしさ
>>487
CJKというか、CJKVのようだけどね
Unicodeは言語を識別するためのものじゃないし、それは別途ISO 639なり使って
管理するとかじゃないの？
489:デフォルトの名無しさん
08/04/06 21:37:48
今の仕様書を1990年に持っていけたらもっとマシなコード体系が出来上がるんだろうなあ…
490:485
08/04/06 21:43:44
>>489
時はバブル、んな将来的なことどうでもいいとか思われそうだがｗ
Y2Kなんて、もっと早急に対応してればあんなに世間が騒ぐこともなかったんだし
結局何も起きなかったけどさｗ
491:デフォルトの名無しさん
08/04/06 21:58:14
世の中の悪い事態の多くは、そうなることが予測不能だったからではなく、
そうなるとわかっているけど対処しなかったから起こったんだ、
とつい最近どっかで読んだけど、まったくだｗ
492:デフォルトの名無しさん
08/04/06 22:12:38
その意味では正に、
「過去に戻れても、やはり同じようになるよ」だな。
493:デフォルトの名無しさん
08/04/06 23:09:49
>>485
>今はサロゲートペアのことを意識する必要が無いから
さすがにもう時間の問題でしょ。
そろそろ JIS X 0213 が要求に入り始めるだろうし。
494:デフォルトの名無しさん
08/04/07 01:51:07
UTF-8は大好きですよ
495:485
08/04/07 08:49:15
>>493
JIS X0213はさすがに困ったちゃんな規格を作ってくれたもんだなぁと思いつつも、いわゆる第三～第四水準に
ようやく人名漢字として略されてたものとかが扱えるとかどうとかで恩恵を受ける人もいるんだろうか？
サロゲートペアを扱うとなると、１文字=2バイトの原則が壊れるんだよなぁ
そういや、2000年だかから中国のGB2312の拡張規格GB18030は、中国大陸における文字表示可能な機器の
全てが対応する必要があるとか訊いて社内で騒ぎになって、Windows2000ではGB18030フォンとパックやら
変なAPIで4バイト文字対応してたとおもうんだけど、こいつはUnicodeとどう親和性を取るつもりなのかな？
規格上はGB18030はISO/IEC 10646を丸ごと飲み込んじゃう規格なんだけど…
496:デフォルトの名無しさん
08/04/07 13:42:22
>>485
>今はサロゲートペアのことを意識する必要が無いから
サロゲートペア以外にも合成文字とかあるんですけど。
497:デフォルトの名無しさん
08/04/07 19:05:39
>>496
MacOS-Xの「ヒ+゜」とかね。
いつ「普通の」データとして飛び込んでくるか分かったもんじゃない。
498:デフォルトの名無しさん
08/04/07 19:12:03
何しろあれが正規形の一つだからな。
499:485
08/04/07 19:41:16
>>496
確かに…
合成文字はヤだなぁ
あと、くっつき方がキモいデーヴァナーガリー文字とかその類も…
500:デフォルトの名無しさん
08/04/07 20:01:44
>>497
Mac持ってないけど「ピ」は合成されてるの？
JISX0213の「か゜」とかじゃなくて？
501:デフォルトの名無しさん
08/04/07 20:26:25
>>500
>>413のNFD
502:デフォルトの名無しさん
08/04/07 20:46:58
>>485
もう現実を見るんだ。
固定バイトの文字コードなんて所詮夢だったんだよ。
503:デフォルトの名無しさん
08/04/07 21:20:35
それでも32bitあればなんとか…
504:デフォルトの名無しさん
08/04/07 21:25:05
HYPHEN-MINUSって文字が誕生した時からこの世はカオスさ
505:デフォルトの名無しさん
08/04/07 22:26:30
UTF-8は0x10入らないようにして欲しいなぁ。
506:485
08/04/08 09:22:27
>>502
そうか、やはりそうなのか…
固定バイトはもはや夢物語なんだなorz
合成文字といえば、ヨーロッパのラテン文字事情なんとかならんのでしょうか？？？
ローカライズにあたって、文字列検索の曖昧検索を行うわけなのだが、Aとキーされようと、
アクセントが付いてようとウムラウトだろうと引っかからないといけないのはまぁいいとして…
A+アクセントとかはやめて欲しいのだがｗ
いったい、ヨーロッパは何言語あるんだYO!
507:デフォルトの名無しさん
08/04/08 09:43:20
L10nされたあいまい検索は、各言語のネイティブの専門家によるアドバイスが
ないとムリポ。
（「エ」と「ヱ」を同一視するかどうかなんて日本人でも判断に困るだろ？）
508:485
08/04/08 11:31:51
>>507
だよねー
今月号の「NEWTON」を読んだら、ラテン語のアルファベットは当初英語で使われるものとほぼ
同じだったとか？
その後に、フランス語やらでアクセント記号が付けられたとかどうとか…
てっきり、逆だと思ってたんだが、Unicode 1.0策定時にCJKの統合に当たってルーツの異なる文字で
似ている物を同一視しようとした件、ラテン語圏でもやはりアクセント記号はそれくらい意味のある文化
の一つなんだろうか…
幸い、自分は合成文字には今のところ携わることはなさそうだが…
中国国家標準のGB 18030をどうにかしてもらいたい…
GB 2312、ASCII、ISO/IEC 10646をうまいこと包含しているという点ではうまいこと考えたなと関心
出来るんだけど、結局は1～4バイトのマルチバイト文字ってワケで、ISO/IEC 10646を包含したとしても
変なジレンマ作ってるだけだし…
そもそも、CJKのグリフが U+3400～U+4DFE、U+4E00～U+9FFEまでしか割り振られてないじゃんか！
BMP面で足りるじゃんかー！
509:デフォルトの名無しさん
08/04/08 13:30:47
>>507
ラテン語ネイティブも、油断してると、
JIS X 0208のFULLWIDTH LATIN (CAPTAL) LETTER *ってのがあるしね。
自前で実装しようとするとHALFWIDTHへの正規化を忘れちゃう。
>>508
表音音文字元祖のフェニキア文字の子孫の
ギリシャ文字でさえ発音記号はないからね。
アクセント記号はcollationの時にも、
取り払ってソートするか付いたままソートするか、
国によって標準的な取り扱いが違って難しい。
510:デフォルトの名無しさん
08/04/08 20:21:30
そのへんはそのうちCollationライブラリが何とかしてくれるから問題ない。
>>GB18030
Unicodeに変換して処理するだけなんだから別に関係ないでしょ
511:デフォルトの名無しさん
08/04/08 20:49:23
他国の心配する前に日本語の処理くらいまともにやってくれ
512:485
08/04/08 21:02:50
>>510
いやいや、GB 18030は現状はUnicodeでグリフのある領域はカバーしてるけど、Unicodeに無い
民族文字やらをどんどん増やす思惑があるらしい…
だったらその思惑をUnicodeコンソーシアムで提起して貰いたいものなんだが…
>>511
俺の文章？orz
どうせローカライズ以前に、各国の文言を用意するのは翻訳チームのすることで、俺は関わってないし
513:デフォルトの名無しさん
08/04/08 21:05:12
自国で独自路線に突っ走りまくってる日本じゃないんだからお前ごときが
他国の心配しなくてもちゃんと国際提案してくるからむしろ日本NBの怠慢ぶりを
何とかしてくれってば
514:デフォルトの名無しさん
08/04/08 21:21:00
そこでJIS第五水準ですよ
515:485
08/04/08 21:46:47
>>513
これは>>513の現場もそうだろうと思うのだが、日本人のSEに限らずPMに至るまで、
日本における標準化についてまともに考えている奴っている？
C++を理解するのにISO/IEC 14882を読んだり、仕様書を書くときに主語をちゃんと
付けることを意識するとかさ？
今俺が書いてる文章なんかは支離滅裂だけどorz
>>514
JIS X0213の二の舞はやめようよｗ
516:デフォルトの名無しさん
08/04/08 22:14:13
＞仕様書を書くときに主語をちゃんと付けることを意識するとかさ？
書かないまでも、意識していないと所謂「とんでも」文書ができあがるわけだが。
# 「マウスボタンが押すとウインドウが表示します」とか。
517:デフォルトの名無しさん
08/04/08 22:40:59
＞５１２
UNICODE的に、新規コードポイントの追加は、
まずは国内規格、次にUNICODEって順番じゃなかったっけ？
518:デフォルトの名無しさん
08/04/08 23:31:00
だから、ウニコードやまりゃいいじゃん
519:デフォルトの名無しさん
08/04/09 00:23:03
はやくExt-C出せー
520:デフォルトの名無しさん
08/04/09 02:59:07
>>515
なんで俺の職場の話がいきなり出てくるのか意味不明だが
日本における標準化の試みは
学者が机上の空論をあーでもないこーでもないと小田原評定のごとくこねくり回した
挙げ句黒船に全部持って行かれるのが通例。
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
の異体字アーキテクチャの検討なんて絵に描いたようだ
521:デフォルトの名無しさん
08/04/09 08:47:51
んー、
動画フォーマットとかはそうでもない気がするけど？
522:デフォルトの名無しさん
08/04/09 09:00:50
mbcs/wcs
ISLISP
IPv6, Mobile IP
この辺は日本の団体が組織的に関わってるよ。
523:デフォルトの名無しさん
08/04/09 09:29:05
個人名で論文や案を提出してレビューする形にしないと、
>>520が多い状況はなかなか改善できないと思う。
本来、案もレビューも書かない奴の意見なんて聞く必要ないんだ。
524:デフォルトの名無しさん
08/04/09 13:14:54
意味のあることを何も言えない奴って、無視されると
意味のあることを言った奴より怒るんだよね。
525:デフォルトの名無しさん
08/04/09 23:39:09
>>523-524
* Ideographic Variation Databaseという対案が明確に示されてる
* 日本は>>520を国際提案していない
話にもならんね
526:デフォルトの名無しさん
08/04/11 14:34:46
>>501
Mac OS XのHFS+は、
さらにアルファベットの大文字小文字の同一視もやってるよな。
ファイル名としては大文字小文字が保存されているけど、
比較ではcase ignoreだからFooがあればfooでopenする。
FULLWIDTHなアルファベットも同じ。
ただしFULLWIDTHとHALFWIDTHな文字は同一視しない。
WIDTH範疇が同じ場合に限り大文字小文字を区別。
527:デフォルトの名無しさん
08/04/11 15:11:34
＞WIDTH範疇が同じ場合に限り大文字小文字を区別。
×区別
○同一視
こうですか?
528:デフォルトの名無しさん
08/04/11 18:52:47
>>510
>そのへんはそのうちCollationライブラリが何とかしてくれるから問題ない。
そういえば Unicode で日本語の文字列をソートした場合、普通はどんな並び順に
なるんでしょうか/なるべきなんでしょうか。Collation のライブラリ毎に違うんでしょうか。
unicode.org の TR10 とか見てみましたがよくわかりませんでした。
529:デフォルトの名無しさん
08/04/11 20:02:25
>>526
Case SensitiveなHFS+もあるよ。
同一視する文字や使えない文字はファイルシステム毎に異なるから
あるファイル名が使えるかは単純には判断出来ない。
530:デフォルトの名無しさん
08/04/12 03:00:11
>>529
既にインストーラでは選べないんじゃない?
昔使ってたが、馬鹿アプリで問題発生したので使わなくなった。
アプリ内のファイルがCapitalizedなのに、
アプリが全部大文字でアクセスしてたw
531:デフォルトの名無しさん
08/04/17 22:38:32
URLﾘﾝｸ(std.dkuug.dk)
トンパ文字の提案キター
532:デフォルトの名無しさん
08/04/18 06:22:15
URLﾘﾝｸ(std.dkuug.dk)
ARIB互換漢字についてアメリカとイギリスからIVSを使えよボケと突っ込まれてるｗ
533:デフォルトの名無しさん
08/04/18 21:35:34
これからIVSを積極的に導入してくなら、現在異体字なのに別のコードポイントを
与えられている文字はIVSに吸収してくるとスッキリするんだけど。
今までのしがらみで無理かな。
534:デフォルトの名無しさん
08/04/18 21:48:21
標準に入らなくても、基準とデータは有意義に使われると思うよ。
535:デフォルトの名無しさん
08/04/18 22:25:21
原規格分離規則があるから、全部統一は無理
536:デフォルトの名無しさん
08/04/19 00:09:08
原規格分離規則ってCJK Unified Ideographs領域のみ適用で、
それ以降に定義された領域では使わないっていうアレか。
537:デフォルトの名無しさん
08/04/19 03:41:26
>>533
既存の互換漢字を削除はあり得ないけど、これから追加しようとしたら突っ込まれて当然だろう
538:デフォルトの名無しさん
08/04/20 11:42:06
Uniocde 5.1の文字一覧マダー(aary
URLﾘﾝｸ(www.unicode.org)
予告期限は過ぎてるんだけど
あともう5.2.0のディレクトリあって吹いたｗ
539:デフォルトの名無しさん
08/04/26 22:57:20
TIP URLﾘﾝｸ(www.unicode.org) 甲骨文字
540:デフォルトの名無しさん
08/04/26 23:04:50
文字コードとグリフを同じに扱おうとしたつけだ
いいじゃねぇの？
541:デフォルトの名無しさん
08/04/27 11:10:56
>>538
来てる
542:デフォルトの名無しさん
08/04/27 20:49:59
ところでT書体はまだですか
543:デフォルトの名無しさん
08/04/28 03:56:41
>>542
URLﾘﾝｸ(www.sakamura-lab.org)
4月中の公開は無理そう
つーか以前は「2006年春」って言っててそれもブッチしてなかったっけ
544:デフォルトの名無しさん
08/04/28 13:30:01
URLﾘﾝｸ(std.dkuug.dk)
結局ARIB互換漢字の追加は受理されたようだ
545:デフォルトの名無しさん
08/04/28 14:19:01
ARIBの仕様書が公開されてた
URLﾘﾝｸ(www.arib.or.jp)
JIS X 0213の指示には私用終端バイトを使って
JIS X 0208の独自拡張をESC 2/4 4/2で指示するという変態仕様
逆だろ…
546:デフォルトの名無しさん
08/04/29 08:16:41
まったくの初心者です。
↓のコードは何でしょうか？
17163542
何て書いてあるのか、教えてください
よろしく
547:デフォルトの名無しさん
08/04/29 08:20:26
板違い。こちらへどうぞ
URLﾘﾝｸ(love6.2ch.net)
548:デフォルトの名無しさん
08/04/29 08:23:07
>>547
すみません。
文字コードじゃないんですか？
549:デフォルトの名無しさん
08/04/29 09:10:30
こちらへどうぞ。
URLﾘﾝｸ(google.com)
550:デフォルトの名無しさん
08/05/01 06:43:38
>>543
やっぱり無理ですた
551:デフォルトの名無しさん
08/05/17 07:02:50
とあるアプリの文字エンコーディングの挙動が変だなと思ったので
問い合わせたら、「Win上のIEの挙動と同じにしている」とのこと。
具体的にはEUC-JPで0x5cが円記号で表示されるのですが。
これってreverse solidusが正解じゃなかったでしたっけ?
確かWinだとここら辺、フォントレベルでおかしなことをしてるんでしたっけ?
しかし正直なところもはやWinやIEの挙動を無視することもできず... トホホ。
552:デフォルトの名無しさん
08/05/17 08:02:14
>>551
「円記号で表示される」だけだと、
エンコーディングレベルで何かやってるのか、
単にフォントがU+005Cを円記号で表示してるだけなのかわからんな。
後者ならフォント変えれば REVERSE SOLIDUS に見えるでしょ。
553:デフォルトの名無しさん
08/05/17 08:23:48
IEと同じというなら後者だな。
Tahomaとかの欧文フォントならバックスラッシュ、
フォントリンクでかな漢字も表示出来ていい感じ。
554:デフォルトの名無しさん
08/05/17 09:44:03
501ですが、
アプリはMac OS Xのエディタです。なんでWin上での技術的背景ではなく
ユーザーエクスペリエンスを問題にしている、とでもいいますか。
IEを「普通に」使ってる分にはEUC-JPの0x5cは円に見える訳ですよね。
あえて欧文フォントを割り当ててバックスラッシュを表示できてもそれはある意味
「化けている」のではないでしょうか。
あるいはIEはあくまでもEUC-JPの0x5cに対してU+005cを表示していて、それが
どう見えるかはフォントやユーザの設定次第、とでも理解すべきでしょうか。
でもIE、確かASCIIやUTF-8だとデフォで0x5cはバックスラッシュ... ややこしいなあ。
555:デフォルトの名無しさん
08/05/17 11:48:24
なんでエディタの名前を書かないんだろう
人の話を聞く気がないならチラシの裏にでも書き捨てろ
556:デフォルトの名無しさん
08/05/17 12:15:02
>>554
実際にIE使ってみればわかるだろクズ
557:デフォルトの名無しさん
08/05/17 12:24:31
>>554
文字コードと文字フォントは別物だよ。
だから、
> あるいはIEはあくまでもEUC-JPの0x5cに対してU+005cを表示していて、それが
> どう見えるかはフォントやユーザの設定次第、とでも理解すべきでしょうか。
でOK。EUC-JPに限らずな。
558:デフォルトの名無しさん
08/05/17 15:10:46
>>551
0x5cというかU+005Cは、ASCIIやJIS X 0213だとUniccode基準で「REVERSE SOLIDUS」でなければおかしいけど、
一般的な日本語エンコードだとJIS X 0201基準だから「YEN SIGN」が正しい。
WindowsのOS標準和文フォントだと、0x5cというかU+005Cは「YEN SIGN」で実装。
Mac OS XのOS標準和文フォントだと、0x5cというかU+005Cは「REVERSE SOLIDUS」で実装。
Windows版のSafariでも、Shift_JIS/EUC-JP/ISO-2022-JPといった日本語エンコードなHTMLでは
和文フォントでも欧文フォントでも0x5cというかU+005CがU+00A5実装Glyph(YEN SIGN)でエイリアス表示され、
それ以外(UTF-8とか)だとフォントのU+005C実装Glyphでダイレクトに表示される。
Mozilla系ブラウザソフトでも「about:config」で、
“layout.enable_japanese_specific_transform default boolean false”を
“layout.enable_japanese_specific_transform user set boolean true”と設定変更すると、Safariと同じ挙動になる。
559:558
08/05/17 15:18:28
>>554
Mac OS Xのエディタでも、設定で0x5cというかU+005CをフォントのU+005Cでダイレクトに表示するか
U+00A5実装Glyph(YEN SIGN)でエイリアス表示かで選択できるものがある。
URLﾘﾝｸ(pc.watch.impress.co.jp)
URLﾘﾝｸ(pc.watch.impress.co.jp)
Windowsの方が日本のローカル規格的には親和な設計ではあるけど国際基準的にはいろいろ問題がある。
Mac OS Xだと国際基準的には親和な設計ではあるけど日本のローカル規格的にはいろいろ問題がある。
だから、Mac OS XやマルチプラットフォームなアプリだとOSやアプリレベルでWindowsとは違う日本ローカル規格対処策をしているものがある。
560:デフォルトの名無しさん
08/05/18 15:24:37
>>558
> Mac OS XのOS標準和文フォントだと、
> 0x5cというかU+005Cは「REVERSE SOLIDUS」で実装。
Mac OS Xだと、
内部SJISアプリの0x5CはYEN SIGN（CMapは83pvまたは90pv）、
内部UnicodeアプリのU+005Cは（標準では）REVERSE SOLIDUS（CMapはUniJIS）。
561:デフォルトの名無しさん
08/05/18 22:56:43
>>559
親和うんぬんの段落はちょっと短絡だろ。
もともとREVERSE SOLIDUSが要求されるところで、(例えば\n)
YEN SIGNを使ったり、YEN SIGNを表示に使ったりしていた過去があるんだから、
そんな単純に割り切れないよ。
562:デフォルトの名無しさん
08/05/18 23:23:33
ESC(BとESC(Jですら同じ扱いだからねぇ。UTF-8はそれこそ・・・
563:デフォルトの名無しさん
08/05/19 20:40:22
Vistaで実装されたとかいうJISX213で使われてるSJIS2004、Unicode3.2、EUC2004ってどうなってんのわかりません
Unicodeで実装されてる第三、第四水準漢字ってSJISにちゃんとマッピングされてんですかね。
なんか規則性なく適当に散りばめてるだけな気がするんで
一文字一文字マッピングされてる場所指定する等で対応しないと対応出来ないのかな？
JISX213レベルでのUnicode-SJIS-EUC全部の対応表があれば嬉しいんですが、そんなのって無いですかね
564:デフォルトの名無しさん
08/05/19 20:48:10
VistaのはJIS X 0213にある文字がUnicodeベースで使えるというだけで、
JIS2004自体に対応しているわけじゃなかったような。
565:デフォルトの名無しさん
08/05/19 21:39:56
>>563-564
Vistaの公式ページで資料もフォントも配布されているというのに、
「されたとかいう」
「どうなってんのわかりません」
「そんなのって無いですかね」
「じゃなかったような」
とかいうヤツってナンなの？ゆとり？
URLﾘﾝｸ(www.microsoft.com)
URLﾘﾝｸ(www.microsoft.com)
566:デフォルトの名無しさん
08/05/19 21:50:06
エンコーディングの話してるのに、フォントの資料を持ってきて
何いってんだか
567:デフォルトの名無しさん
08/05/19 22:04:09
>>566
これだからゆとりは困る。
これがエンコーディングの資料ではないとでも？
・Windows Vista ならびに Windows Server 2008 における JIS2004 対応に関する詳細資料
ホワイトペーパー「Microsoft Windows Vista および Windows Server 2008 における JIS X 0213:2004 (JIS2004) 対応について」(Version 1.2) は、こちら(XPS 形式、PDF 形式) をご参照ください。
・JIS X 0213:2004 / Unicode 実装ガイド
この実装ガイドでは、JIS 文字コードが Unicode 対応の JIS X 0213:2004 へ変更されたことに伴いアプリケーションへ与える影響および対応策などについて説明します。(XPS 形式 1.88 MB、PDF 形式 1.34 MB)
568:デフォルトの名無しさん
08/05/19 22:08:01
ゆとりゆとり言う奴に限って自分では質問に答えられない。
569:デフォルトの名無しさん
08/05/19 22:59:39
>>563
Vistaの実装ではShift_JIS-2004やEUC-JIS-2004には対応していません。
JIS X 0213はUnicodeのレパートリとして実装されています。
必要なら自分で変換してください。
570:デフォルトの名無しさん
08/05/20 21:20:03
>>569
オレオレ変換はやめてくれ
Shift_JISにはマッピングされていないから無理だと思っていただいた方が将来の人が助かる
571:デフォルトの名無しさん
08/05/20 21:43:15
自ら学び自ら考える力を身に付けるための教育(笑)
572:デフォルトの名無しさん
08/05/20 22:52:15
CP932なんて使ってないしShift_JIS-2004のためにも消えてくれ。
573:デフォルトの名無しさん
08/05/20 22:58:09
>>572
お前が使っていなくても、世間が使っている。
ほんと、DOS/Windowsの呪縛の1つだな。
574:デフォルトの名無しさん
08/05/20 23:15:09
2chはCP932だとおもっていたが如何
575:デフォルトの名無しさん
08/05/20 23:15:15
>>572
青空ｳﾝｺ工作員乙
576:デフォルトの名無しさん
08/05/25 00:59:45
URLﾘﾝｸ(www.unicode.org)
いつの間にかUnicodeの3面をTertiary Ideographic Plane(第三漢字面)とすることが決まってた。
現時点では1字も定義されてないが古代漢字や甲骨文字を収録するみたいだ。
577:デフォルトの名無しさん
08/05/25 01:08:50
>>576
これは便利だ
578:デフォルトの名無しさん
08/05/25 16:02:10
>>539で既出
579:デフォルトの名無しさん
08/05/30 01:20:21
Unicodeって、色々バージョンがあるみたいだが。
非Unicodeな文字コードとのマッピングが変わることってある？
基本的には予約領域に新しい文字が追加されていくj形という認識で合ってるのかな？
580:デフォルトの名無しさん
08/05/30 06:35:56
各ベンダーのマッピングは文字が追加されなくてもそれぞれ違う。
そもそも一対一対応ですらない。
例えば、URLﾘﾝｸ(support.microsoft.com)
581:デフォルトの名無しさん
08/05/30 20:36:13
IRGの追っかけやってれば知ってるだろうけどCNS11643とのマッピングはしょっちゅう変わってる
582:デフォルトの名無しさん
08/05/31 12:20:35
資金があればいい加減に文字コードを統一したいよな。
文字コード多すぎるだろう。
10年前のシステムならばしかたがないにしても、
現代のハードウェアやソフトウェアの質を考えたら、
行動を起こしてもいいと思うんだがなあ。
ビルちゃん、気まぐれで動かないかなあ。
583:デフォルトの名無しさん
08/05/31 13:16:57
資金とかの問題じゃないような。
584:デフォルトの名無しさん
08/05/31 13:36:15
現在の世の中に存在するコンピュータでも全てがMBやGB単位のメモリを積んでる訳じゃないんだ。
585:デフォルトの名無しさん
08/05/31 14:17:36
すみません、質問させてください。
ワードで文書を作成する際に文字コードを指定されました（JIS-X0208-1982）.
しかしこの意味が全くわかりません。
普通にワードの画面を開いて文書作成しただけではこのコードにならないということでしょうか？
ググってみると、記号について何年かごとに改正されてきたコードらしいのですが
１９８３はあっても１９８２がみつかりません。また、これをワードでの文書作成時に
どう使うのかが理解できません。
ワードでの文書作成時に「挿入」から記号を挿入する際に何か特殊なことをする必要が
あるのでしょうか？その場合、どうすればいいのでしょうか？
画面下にドロップダウンがあってunicode とかJISとか選べるみたいだったのでやったのですが、
この０２０８というが見つからないし、途方にくれています。
ズブの素人なので、わかりやすく説明していただけると助かります。おねがいします。
586:デフォルトの名無しさん
08/05/31 15:58:22
> ビルちゃん、気まぐれで動かないかなあ。
ビルちゃんはちゃんと動いているだろ。
気まぐれなのは相変わらずだが。(w
587:デフォルトの名無しさん
08/05/31 16:02:21
そのビルちゃんって、いま何兆円ぐらい持ってるの？
7ぐらい？
588:デフォルトの名無しさん
08/05/31 17:53:33
文字コードじゃなくて、文字集合を指定されただけじゃねーの。
589:デフォルトの名無しさん
08/05/31 22:17:23
>>582
> ビルちゃん、気まぐれで動かないかなあ。
一番動かないで欲しい人ですが？
590:デフォルトの名無しさん
08/06/01 00:32:59
>>585
超初心者向け質問スレがちゃんとあるというのに、こんな超廃人スレに来てるＫＹなヤツってナンなの？ゆとり？
【ﾏｼﾞﾚｽ】超初心者の質問に答えるスレ93【ｴｽﾊﾟｰ】
ｽﾚﾘﾝｸ(win板)
591:デフォルトの名無しさん
08/06/01 00:49:35
プログラム技術＠2ch掲示板
URLﾘﾝｸ(pc11.2ch.net)
この板はプログラムを作る人のための板です。
プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。
592:デフォルトの名無しさん
08/06/01 02:36:02
JIS-X0208-1982はJIS X 0208:1983の間違いだろう。
いわゆる機種依存文字だけ気にしていればいいんじゃね？
>588さん
俺の予想では、文字集合を指定されたんじゃなくて、
WordがシフトJISで保存すると勘違いした奴が、1978から1983改訂の際の
文字の入れ替えについて改訂後のことだと言いたかったに一票。
593:デフォルトの名無しさん
08/06/01 03:13:41
>>592
ありがとうございます！
私もこんなこと言われたの初めてで、びっくりした上、１９８２なんか
ないのに驚いたんですが、１９８３のことですかとは聞けなくて・・・。
本当にありがとうございました。