アカウント名:
パスワード:
マルチバイト系の処理とか、ほとんど誰もチェックしてなくて、バグがたまってそうな気がする。
X11のプログラムを最後に作ってから15年くらい経ってるんで記憶があいまいですが、文字はコンパウンドストリングとかいうのに変換しないと表示できず、ちゃんとマルチバイトだとかマルチリンガルが考慮されていたような。まあ、だからと言って十分なチェックされてる保証は無いですが。
Xtの方の仕組みだったかな?
私も20年近く前の知識ですが、マルチバイト系(というかマルチリンガル系)の関数セットと、バイト系の関数セットの2通りがありますね。
個々のアプリケーションを書く個々のプログラマが、マルチリンガルのことを意識して、あえて難しいほうの書き方をしないと、そのプログラムはマルチバイト対応にならない(なのでマルチバイト対応アプリケーションの割合は全然高まらない)という仕組みです。どうやって世界中のプログラマにマルチリンガルの必要性を説いて回るんだ、と思ったものでした。
何もないところから、その仕組みを作ってXに入れさせただけでも、ものすごい功績だとは思いますけど。
ああ…Lesstifが日本語通らなくてソース修正しまくった思い出がよみがえってまいりました…。
で、デフォルトの文字列をUTF-8にしようとしたら日本の原理主義者が反対するというおなじみすぎる流れでもう笑うしかなかった。あいつらがいなかったらアプリケーションの(あいつらの主張によれば)なんちゃって国際化は10年くらい早まったんじゃねーの。
米国でコードを書いていた経験から言わせてもらうと、それは1byte文字コード圏の人を甘く見すぎです。
void mbcs2wcs(unsigned char *mbcs,unsigned short *wcs,int len){while(len--)*(wcs++)=*(mbcs++);}みたいなこと平気でやるからなぁ…# お前の事だぞ、Adobe。
だからこそ、日本語圏プログラマが率先してマルチバイトを利用していかねばならんのです。テスターだと思ってください。
Unicodeすらまともに扱えない連中がそれよりはるかにはるかに難しいISO/IEC 2022系のi18nにまともに対応してくれるという思考回路が理解不可能。
そう読み取ったら理解不可能だろうね
ここには、いまでもメールはISO-2022-JPに拘ってる奴が大勢いるじゃんよ。
Marericksの仕様の隙間を突いて [applech2.com]までISO-2022-JPでの送信に固執する奴とかどうにかしてほしい
折角なので関連リンク
日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か [srad.jp]
何で?
Win 32のUnicode系のAPIの使用率すらなかなか高まらないんだから、いわんやISO/IEC 2022ベースのマルチバイト系APIをや
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
マルチバイト系の処理とか (スコア:0)
マルチバイト系の処理とか、ほとんど誰もチェックしてなくて、バグがたまってそうな気がする。
Re:マルチバイト系の処理とか (スコア:1)
X11のプログラムを最後に作ってから15年くらい経ってるんで記憶があいまいですが、文字はコンパウンドストリングとかいうのに変換しないと表示できず、ちゃんとマルチバイトだとかマルチリンガルが考慮されていたような。
まあ、だからと言って十分なチェックされてる保証は無いですが。
Xtの方の仕組みだったかな?
Re:マルチバイト系の処理とか (スコア:1)
私も20年近く前の知識ですが、マルチバイト系(というかマルチリンガル系)の関数セットと、バイト系の関数セットの2通りがありますね。
個々のアプリケーションを書く個々のプログラマが、マルチリンガルのことを意識して、あえて難しいほうの書き方をしないと、
そのプログラムはマルチバイト対応にならない(なのでマルチバイト対応アプリケーションの割合は全然高まらない)という仕組みです。
どうやって世界中のプログラマにマルチリンガルの必要性を説いて回るんだ、と思ったものでした。
何もないところから、その仕組みを作ってXに入れさせただけでも、ものすごい功績だとは思いますけど。
Re: (スコア:0)
ああ…Lesstifが日本語通らなくてソース修正しまくった思い出がよみがえってまいりました…。
Perfect is the enemy of good (スコア:0)
で、デフォルトの文字列をUTF-8にしようとしたら日本の原理主義者が反対するというおなじみすぎる流れでもう笑うしかなかった。あいつらがいなかったらアプリケーションの(あいつらの主張によれば)なんちゃって国際化は10年くらい早まったんじゃねーの。
Re:Perfect is the enemy of good (スコア:1)
米国でコードを書いていた経験から言わせてもらうと、それは1byte文字コード圏の人を甘く見すぎです。
Re:Perfect is the enemy of good (スコア:1)
void mbcs2wcs(unsigned char *mbcs,unsigned short *wcs,int len){
while(len--)*(wcs++)=*(mbcs++);
}
みたいなこと平気でやるからなぁ…
# お前の事だぞ、Adobe。
Re: (スコア:0)
だからこそ、日本語圏プログラマが率先してマルチバイトを利用していかねばならんのです。
テスターだと思ってください。
Re: (スコア:0)
Unicodeすらまともに扱えない連中がそれよりはるかにはるかに難しいISO/IEC 2022系のi18nにまともに対応してくれるという思考回路が理解不可能。
Re: (スコア:0)
そう読み取ったら理解不可能だろうね
Re: (スコア:0)
ここには、いまでもメールはISO-2022-JPに拘ってる奴が大勢いるじゃんよ。
Re: (スコア:0)
Marericksの仕様の隙間を突いて [applech2.com]までISO-2022-JPでの送信に固執する奴とかどうにかしてほしい
Re:Perfect is the enemy of good (スコア:2)
折角なので関連リンク
日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か [srad.jp]
Re: (スコア:0)
何で?
Re: (スコア:0)
Win 32のUnicode系のAPIの使用率すらなかなか高まらないんだから、いわんやISO/IEC 2022ベースのマルチバイト系APIをや