アカウント名:
パスワード:
1.MS932, Windows-31JなどShift_JIS系のコードページに本来のShift_JISに入っていない文字がある2.企業毎にShift_JIS系コードページの実装で文字セットとそのコードポイントの割り当てに違いがある3.それぞれのShift_JIS系のコードページとUnicodeのコード変換の対応表に違いがある (#1123871は、多分これ)
なお、もしアプリケーションがどちらの並びにも対応できるならばAIXではIBM943を使用するほうがよいと思います。IBM943はWindowsのSJISと互換性があるためです。
ところで、マイクロソフトはMS-DOSにおける唯一の日本語用コードページである「CP932」をOEMメーカーの自由に任せていた。NECのPC-9800シリーズ、IBMのDOS/V、富士通のFMRシリーズなどは全てMS-DOSを搭載しているコンピュータであり、搭載されている文字符号化方式もShift_JISを採用しているにもかかわらず、登録されている文字集合がバラバラであった。ところが、マイクロソフトは1993年、Windows3.1の日本語版を出すにあたり、「CP932」の仕様をOEMの自由に任せるという方針を撤回した。日本のパーソナルコンピュータ市場で、特に大きなシェアを持つ上記2社の統合コードをWindowsにおける日本語標準コードとし、また、これをIANAに「Windows-31J」という名で登録したのである。
入出力だけじゃなく、内部処理も UTF-8 のままでないと、コード変換が起きて文字が変化する可能性は消えませんが。
途中のどこかではなく、入力の最初(IME)のところで既に問題が発生してます。
その IM は全く同一のシステムでの比較ですか? せめて両方とも同じバージョンの ATOK だとか、Anthy だとかで同じものに揃えて試さないと比較にならないのですが。
Microsoft IME とことえりの差とかにしか見えませんよ。
# そもそも IM を利用している段階で、プログラムによる加工が行われている訳ですが。
大元のコメントにある問題って、本来入力しようとした文字を IM が適切に変換していない/できないから発生している事ですよね? 「コピペで入力」してればそのまま化けずに入力されるのですが。
キーマップで割り当てられた文字を IM 経由で入力しようとした際に変換処理が発生している訳で、何も変換を行わずに入力 (つまりコード表などから入力) した場合には、何の問題もありませんよ、ということです。
IM を通して \ を押しても全角バックスラッシュに変換されない事が分かってるユーザなら、全角のバックスラッシュを入力してみてくれと言われたら \ を押したりせず、「きごう」と入れて変換するなりして全角バックスラッシュが出るように変換して入力しますよ。
IM に入力されたコードからどんな文字に変換されるかは IM 依存な訳で、UTF-8 にしたからという理由ではありません。
UTF-8しか無ければ問題ない。
過去のデータはすべて捨てろってこと?
Unicode 信者って必ずそういうけど、なんで?
「全角アルファベットを使うべきでない」は初めて聞きました。 どのあたりの規格か知りたいです。
少なくともUnicode Standard、JIS X 0202、JIS X 0208、JIS X 0213には、そのへんの変な文字は使うなと明記されています。
「全角アルファベットを使うべきでない」という仕様は無いと考えていいでしょうか?
本当にちゃんと探しましたか?
6.5.1で規定する漢字集合とISO/IEC 646の国際基準版とを同時に用いる場合、ISO/IEC 646で規定される図形文字と同じ図形文字は用いてはならない。
と書いてありますが。
因みに、Unicode Standardの「そのへんの変な文字は使うな」はJIS X 0221での禁止ということでしょうか?
Unicode StandardといえばUnicode Standardです。 Halfwidth and Fullwidth Formsのところに書いてありますよ。
#探し方がへたなだけかなぁ
そもそもこういう話には向いていないのでは? 全角とか書いてる時点で。
へー、ということは例えばJIS X 4801みたいなのでもいわゆる全角英数字は使用できないのか。
こういうとんちんかんなことを書くということは、JIS X 4801を読んでいないということですね。
「全角アルファベットを使うべきでない」という仕様は無いと考えていいでしょうか?本当にちゃんと探しましたか?6.5.1で規定する漢字集合とISO/IEC 646の国際基準版とを同時に用いる場合、ISO/IEC 646で規定される図形文字と同じ図形文字は用いてはならない。と書いてありますが。
Halfwidth and Fullwidth Formsのところに書いてありますよ。
要はJIS X 0208の方のラテン文字が変な文字だから使用禁止という訳ではなく、同じ文字が異なる符号で存在するので、どっちかに統一しましょうということが示されていたわけです。
違いますよ。原因と結果が逆です。
そもそも同じ名前のついた同じ文字なのだから、本当は内部での扱い(検索など)や表示で区別をしてはいけないんです。 ところがその辺をよく分かってないエセ技術者が、別の文字として扱っちゃったわけですね。 そういう世間の事情をくんで、JISでは1997年だったかの版で互換性のために代替名称として存在だけは認め、さらに『そういう変な文字は使うな』と明記したわけです。
なのでもう「全角〜」「半角〜」って呼び名はどうよと悩む意味は無さそうな感じです。
そもそも使うべきではないのだから、そういう呼び名がでることは普通ありませんよね。 それに、こういう濫用のせいで文字集合・符号化方式・字体をわけて考えられない技術者が量産されていることは留意したほうがいいでしょう。
まあ、もし重複符号化NGだったら、重複符号化バリバリのISO-2022-JPの立つ瀬がないですしね。
ISO/IEC 2022でいうところの一意な符号化に、ISO-2022-JPはなんら違反していませんよ。G0に文字集合をdesignateして切り替えているので。
そうです。用いてはならないと書かれていますし、
ですね。なので使うべきではないわけです。
その後ろに例外事項も書いてあります。
例外って言葉の意味、分かっていますか?
なので使うべきではないわけです。
なので と言われても。 質問の意図が伝わっていないですね。えーと…、私は規格に ~すべきではない という文言が書いてある箇所があるか確認しようとしています。
でいえば、最後が 用いるべきではない のように書かれたものです。~してはならない と書いてあるのを確認したいわけではないし、解釈した結果が 使うべきではない になることを確認したいわけでもないです。 なので、ここ以外に候補が無いのであれば、JIS X 0202、JIS X 0208、JIS X 0213は私が意図する
「全角アルファベットを使うべきでない」という仕様
には該当していないです。
話をそらしてもだめですよ。そもそも、
> は? いわゆる半角カナを使うべきでないというのは、文字コード判別とはまったく別の理由ですが。 > いわゆる全角アルファベットを使うべきでないというのと同じです。規格ぐらい読みなさい。 「全角アルファベットを使うべきでない」は初めて聞きました。 どのあたりの規格か知りたいです。
> は? いわゆる半角カナを使うべきでないというのは、文字コード判別とはまったく別の理由ですが。 > いわゆる全角アルファベットを使うべきでないというのと同じです。規格ぐらい読みなさい。
発端はこのコメントですが、A.C.は『使うべきではないということが規格に書いてある』とは書いていません。 書いてもいないものを勝手に読み取った、あなたのミスです。 で、使うべきではない理由は、『規格に使うなと書いてあるから』です。
あたかもJIS X 0201の文字とは別の文字のように呼ぶ理由は何でしょう。
別の文字として扱う場合の話なのですから、別の文字として扱うことに何も問題はないですね。
たとえば今やっている話みたいな両者の文字をあえて区別して扱わなければならない場合には、そういう呼び名を出すことに問題は無いですよね。
だめですね。あなたはまだレイヤーが混ざっています。 『代替名称を使って別の文字とみなす場合』だけではなく、『一つの符号化方式で複数の文字集合を扱った場合に、同じ文字が複数のコードポイントにあらわれる場合』があります。後者では半角・全角は不適です。
発端はこのコメントですが、A.C.は『使うべきではないということが規格に書いてある』とは書いていません。書いてもいないものを勝手に読み取った、あなたのミスです。
で、使うべきではない理由は、『規格に使うなと書いてあるから』です。
あなたは暴れすぎですね。
それらは分けて扱うことはできません。
まったく別物ですよ。混同しているのでは? 後者は『両者を異なった文字として用い』ない場合です。
旧世代の感覚
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
文字コード間変換 (スコア:0)
「~」の文字化け問題とかめんどくさー(;´Д`)
Re:文字コード間変換 (スコア:2, 興味深い)
UTF-8しか無ければ問題ない。
Re:文字コード間変換 (スコア:3, すばらしい洞察)
オマイラがShift_JISだと思ってる97% [mycom.co.jp]はShift_JISじゃなくてCP932(Windows31J,MS-Kanji等とも呼ぶ)だ。
本当に(規格上の)Shift_JISならunicodeと相互変換をしても文字(コード)化けはおきないハズ。(フォント環境の違いで字体化けはおきるかもしれんが)
Re:文字コード間変換 (スコア:3, 参考になる)
Shift_JISではなく正しくCP932として扱えばやはり変換しても化けない。CP932をShift_JISとして扱うから化ける。
Re:文字コード間変換 (スコア:2, 参考になる)
元コメント(#1123871)が言ってる「~」の文字化けの問題ってコードポイント自体の問題ではなく、コード変換テーブルの問題ですよね。
上の方で出てるコードページ(Shift_JIS, CP932, Windows-31J)で「~」はすべてコードポイントは8160で、一緒のはず。
CP932とShift_JISで文字化けが、っていう問題は
*MS932, Windows-31JなどShift_JIS系のコードページに本来のShift_JISに入っていない文字がある
*企業毎にShift_JIS系コードページの実装で文字セットとそのコードポイントの割り当てに違いがある
*それぞれのShift_JIS系のコードページとUnicodeのコード変換の対応表に違いがある (#1123871は、多分これ)
などという複数の原因があって、一緒くたにして議論するのはちょっと・・。
コード変換エンジンがそれぞれのShift_JIS系コードページ(特にShift_JISやCP932みたいな一般的なものに)にどのコードページ・コード変換テーブルの実装を割り当てているかが問題であって、CP932だから、Shift_JISだから化ける、化けないってのはちょっと本質的じゃない気がします。
ちなみにJavaを例にすると、
CP932はIBMの932のことで、マイクロソフトの932は Windows-31J か MS932。
Shift_JISはJDK1.4から本来のShift_JISになったはず(たしか)。
Shift_JISとUnicodeの変換に使われる変換テーブルと、CP932とUnicodeの変換に使われる変換テーブルが違うから、
「~」を Shift_JIS->Unicode->CP932 として変換すると一貫性が失われて文字が化ける、と。
重要なのは、行きと帰りで同じコードページ(というか、その文字にとって同じコード変換テーブルを持つコードページかな)を指定しないと文字化けを起こすということですね。
そういう意味で、行きと帰りで「正しい(文書などを作った人が意図した)」コードページを指定しないといけないんで、
一つのシステム上では一貫して同じコードページを使ったり、入力する前に強制的に揃えたりしないといけない。
こういうのを色々考えないといけないので、「めんどくさー」となりますよね。
Re:文字コード間変換 (スコア:1)
仕様上のShift_JISとunicodeの変換はunicodeコンソーシアムで決められてるから、ソレに従えば対応表は同じになるはず。でなければバグ。
CP932はMSローカル仕様だけど、CP932とunicodeの変換はMSで公開しているから、ソレに従えば対応表は同じになるはず。でなければバグ。
2,3は(使用者または変換実装者が)Shift_JIS系と一緒くたにするから発生する問題では?
個人的には(もはや誤解は解けないと思われるので)一般人がShift_JISと言ってきたら「どうせオマエの言ってるのはCP932のコトだろ」と扱うのが一番(97%)丸くおさめる方法じゃないかとは思いますが。
(ちなみに一般人がCGIと言ってきたら「どうせオマエの言ってるのはCommonGatewayInterfaceじゃなくてサーバ側プログラムならmod_xxxでもfastcgiでも何でもいいんだろ」と扱っても丸くおさまる)
Re:文字コード間変換 (スコア:1)
それ以外は状況に応じて個別対応か無視だな。
ところで「他ベンダーのCodepage 932」を調べたら
IBM932で検索したらAIXのマニュアルがhit [ibm.com]したけど、IBM943がデフォでIBM932は非推奨らしい。
でJava1.4 [sun.co.jp]および1.5 [sun.com]では(IBM932を意味してた)CP932はなく、CP942/943しかない。
もはやIBM932は現役じゃないんじゃないかな。
wikipedia:Microsoftコードページ932
ということらしいので、あとNEC CP932とFMR CP932とかありそうだが
Re:文字コード間変換 (スコア:0)
Microsoft社系OSのみで構成されたシステムならそーかもしれないけどね。
Re:文字コード間変換 (スコア:1)
WindowsアプリでWindowsAPIを使ってれば自動的にサポートされるかもしれないけど
独自変換してるアプリだとどのOS上であろうとサポートしてないかもしれないし(MySQL 4.1等のDB)、サポートしてるかもしれない。
ありがちなのはサポートしてるのにもかかわらずCP932を使わずにShift_JISを指定してハマってるんじゃないかと
Re:文字コード間変換 (スコア:3, 参考になる)
Shift_JISがCP932ではないから起きている問題なわけで、Shift_JISならShift_JIS、Windows-31J(CP932)ならWindows-31JとUnicodeとの相互変換をしてれば、変換できない文字は出てきません。WindowsはWindows-31Jを使っているので、Shift_JISや外国の文字なんか知らない、と変換しないだけのこと。
Unicode上の全文字がShift_JISで表示できれば文字化けは起きませんが、そんなことは無理。
あとは、Shift_JISとCP932に限らず、他のUnicode上の似た文字も寄せ集めてから変換すれば、化けることは少なくなります。○に株の㊑とか、①の❶➀➊とか。ゔとか。
okome
Re:文字コード間変換 (スコア:3, 参考になる)
いいえ。UTF-8しかなくたって、「〜」のつもりで「~」が使われたり
非互換な変換と全く同じ気持ち悪さを引きずる訳ですが。
あなたのシステムでUTF-8文書に「 ̄―\~∥…-¥¢£¬」と入力してみましょう。
「‾—\〜‖⃯−¥¢£¬」とはなりませんでしたか?
Re:文字コード間変換 (スコア:1)
それはやっぱり、Windows-31JやShift_JISに変換されているから起きている問題ですね。
okome
Re:文字コード間変換 (スコア:1)
WindowsとMac OS Xで、OS標準のものだけ使って文字入力して検証してみたら、
予想通りの結果になりました。
Re:文字コード間変換 (スコア:1)
入出力だけじゃなく、内部処理も UTF-8 のままでないと、コード変換が起きて文字が変化する可能性は消えませんが。
Re:文字コード間変換 (スコア:1)
「コード変換が介在しない、100% pure Unicode 環境でも問題は発生する」
です。
途中のどこかではなく、入力の最初(IME)のところで既に問題が発生してます。
- 「なみ[変換]」と入力すると、Windowsでは「~」(FULLWIDTH TILDE)になり、Macでは「〜」(WAVE DASH)になります。
- 全角入力モードで「-」を入力すると、Windowsでは「-」(FULLWIDTH HYPHEN-MINUS)になり、Macでは「−」(MINUS SIGN)になります。
IMEの、辞書や半角→全角変換テーブルの問題なので、ある種の「コード変換の問題」とは言えるのかもしれませんが……。Re:文字コード間変換 (スコア:1)
その IM は全く同一のシステムでの比較ですか? せめて両方とも同じバージョンの ATOK だとか、Anthy だとかで同じものに揃えて試さないと比較にならないのですが。
Microsoft IME とことえりの差とかにしか見えませんよ。
# そもそも IM を利用している段階で、プログラムによる加工が行われている訳ですが。
Re:文字コード間変換 (スコア:1)
> Microsoft IME とことえりの差とかにしか見えませんよ。
まさにその通り。でも、その「差」はコード変換とは「直接」関係があるわけではありませんよね。
Re:文字コード間変換 (スコア:1)
大元のコメントにある問題って、本来入力しようとした文字を IM が適切に変換していない/できないから発生している事ですよね? 「コピペで入力」してればそのまま化けずに入力されるのですが。
キーマップで割り当てられた文字を IM 経由で入力しようとした際に変換処理が発生している訳で、何も変換を行わずに入力 (つまりコード表などから入力) した場合には、何の問題もありませんよ、ということです。
IM を通して \ を押しても全角バックスラッシュに変換されない事が分かってるユーザなら、全角のバックスラッシュを入力してみてくれと言われたら \ を押したりせず、「きごう」と入れて変換するなりして全角バックスラッシュが出るように変換して入力しますよ。
IM に入力されたコードからどんな文字に変換されるかは IM 依存な訳で、UTF-8 にしたからという理由ではありません。
Re:文字コード間変換 (スコア:0)
Re:文字コード間変換 (スコア:0)
Re:文字コード間変換 (スコア:0)
Re:文字コード間変換 (スコア:0)
Re:文字コード間変換 (スコア:0)
IBM髙のつもりでNEC髙が使われているとか、CP932だとそんな問題気にしてないでしょ。
Re:文字コード間変換 (スコア:1)
行ったり来たり慣れるまで結構大変です。
AjaxはUTF-8だし、ファイルは直接いじりたいし。
Re:文字コード間変換 (スコア:0)
Re:文字コード間変換 (スコア:0)
過去のデータはすべて捨てろってこと?
Re:文字コード間変換 (スコア:2, 興味深い)
そうすれば、どんどんUTF-8の世界がひろがって、相対的に古いデータを取り扱うものは減っていく。
過去のデータを捨てる必要はないが、必要のなくなったデータは時間と共に消えていく。
古いデータが滅びるのは時間の問題じゃないですかね。
今日作ったデータが、20年後に"そのままの状態で"必要になることは無いと思います。
Re:文字コード間変換 (スコア:1)
Re:文字コード間変換 (スコア:1)
レジとかだと半角英数/カナのみだったりね
Re:文字コード間変換 (スコア:1)
とにかく、どれかに統一した方が扱いが楽になる
いろんな文字コードが混在してて自動認識すら完璧ではない今の状態で、
さらに文字コードを追加されてもなにも解決しないし下手すれば悪化するだけ
どーせどっかで妥協しなきゃならないのは確実なんだから、今あるもので妥協してもいいと思う
日本語しか見ないならShiftJISでもいいんだけど、そういうわけにもいかないみたいだし
UTF-8は良くできた妥協点だと思うな
Re:文字コード間変換 (スコア:0)
UTF-8信者です。
Re:文字コード間変換 (スコア:0)
UTF-8をShift_JISに変換すりゃ、ない文字は見えなくなるわな。
いつまで日本の隅っこでシフトJISなんかつついてなきゃならんのだ。
メールもUTF-8でうだうだ言ってくる人はいつまで古いソフト使ってるのかね。セキュリティ大丈夫? とか、Webで半角カナは使わないでくださいっていつの時代の文字コード判定だとか思うわけだ。コード判定がやりにくくなるというより、とりあえずまじないぐらいに思ってるんでしょな。
いちいち全角半角指定してないで、それぐらいサーバ側で変換かけろ、とか、言いたいことは山のよう。
Re:文字コード間変換 (スコア:1, 参考になる)
> いわゆる全角アルファベットを使うべきでないというのと同じです。規格ぐらい読みなさい。
規格には何でも書いてあるんですね。
文字コード判別のことは規格になんて書かれてませんが、半角カナが混じるとISO-2022-JP、Shift_JIS、EUC-JPが判定しにくくなるから使わないでほしいとしていたんですよ。規格読んでも歴史を追わないとすべての理由なんてわからないですよ。
今はページのエンコードと同じコードでFORMを返すので、半角カナ拒否みたいなのは単純に手抜きでしかないんです。
半角かなを使うべきではない、というのはFORMで半角かなを使わせないのとは全くつながらないわけではありませんが違う段階のお話です。ISO-2022-JPで半角かなを省いたのはそのような理由です。残念でした。何でこう間違ったことを堂々と言えるんですかね。
Re:文字コード間変換 (スコア:1)
> いわゆる全角アルファベットを使うべきでないというのと同じです。規格ぐらい読みなさい。
「全角アルファベットを使うべきでない」は初めて聞きました。
どのあたりの規格か知りたいです。
#気分の問題じゃなかったんだ…
「半角カナを使うな」は、単純に文字コードの制限だったと思うんですが。
8ビット目を使わないほうがいい(正しく処理できないサーバやクライアントが多かったから) → 7ビットで表現するISO-2022-JPを用意 → ISO-2022-JPには半角カナが定義されていない → 半角カナを使うな
Re:文字コード間変換 (スコア:1)
少なくともUnicode Standard、JIS X 0202、JIS X 0208、JIS X 0213には、そのへんの変な文字は使うなと明記されています。
Re:文字コード間変換 (スコア:1)
> なぜ突然ISO-2022-JPが出てくるわけ?
あ、「メールで半角カナ使うな」という話とごっちゃになっていました。失礼しました。
Re:文字コード間変換 (スコア:1)
「全角アルファベットを使うべきでない」という仕様は無いと考えていいでしょうか?
なんというか、MUST NOT(例外条件ありなのはMUST NOTにならないのかな?)ではなく、SHOULD NOTにあたる文言というか…
因みに、Unicode Standardの「そのへんの変な文字は使うな」はJIS X 0221での禁止ということでしょうか?
#探し方がへたなだけかなぁ
Re:文字コード間変換 (スコア:1)
本当にちゃんと探しましたか?
と書いてありますが。
Unicode StandardといえばUnicode Standardです。
Halfwidth and Fullwidth Formsのところに書いてありますよ。
そもそもこういう話には向いていないのでは? 全角とか書いてる時点で。
Re:文字コード間変換 (スコア:1)
こういうとんちんかんなことを書くということは、JIS X 4801を読んでいないということですね。
Re:文字コード間変換 (スコア:1)
互換性以外の目的でも許容するような文言が混じっていたのかと思って、確認しようとしていたんですが。
ありがとうございます。もう一度目を通します。
いわゆるを付ければOKだという考えではないので。この会話の上で付けろということであれば別にかまいませんが。
Re:文字コード間変換 (スコア:1)
違いますよ。原因と結果が逆です。
そもそも同じ名前のついた同じ文字なのだから、本当は内部での扱い(検索など)や表示で区別をしてはいけないんです。
ところがその辺をよく分かってないエセ技術者が、別の文字として扱っちゃったわけですね。
そういう世間の事情をくんで、JISでは1997年だったかの版で互換性のために代替名称として存在だけは認め、さらに『そういう変な文字は使うな』と明記したわけです。
そもそも使うべきではないのだから、そういう呼び名がでることは普通ありませんよね。
それに、こういう濫用のせいで文字集合・符号化方式・字体をわけて考えられない技術者が量産されていることは留意したほうがいいでしょう。
ISO/IEC 2022でいうところの一意な符号化に、ISO-2022-JPはなんら違反していませんよ。G0に文字集合をdesignateして切り替えているので。
Re:文字コード間変換 (スコア:1)
ですね。なので使うべきではないわけです。
例外って言葉の意味、分かっていますか?
Re:文字コード間変換 (スコア:1)
なので と言われても。
質問の意図が伝わっていないですね。えーと…、私は規格に ~すべきではない という文言が書いてある箇所があるか確認しようとしています。
でいえば、最後が 用いるべきではない のように書かれたものです。~してはならない と書いてあるのを確認したいわけではないし、解釈した結果が 使うべきではない になることを確認したいわけでもないです。
なので、ここ以外に候補が無いのであれば、JIS X 0202、JIS X 0208、JIS X 0213は私が意図する
には該当していないです。
普通の日本語としてこういう意味 [yahoo.co.jp]で使っています。Re:文字コード間変換 (スコア:1)
話をそらしてもだめですよ。そもそも、
発端はこのコメントですが、A.C.は『使うべきではないということが規格に書いてある』とは書いていません。
書いてもいないものを勝手に読み取った、あなたのミスです。
で、使うべきではない理由は、『規格に使うなと書いてあるから』です。
Re:文字コード間変換 (スコア:1)
別の文字として扱う場合の話なのですから、別の文字として扱うことに何も問題はないですね。
だめですね。あなたはまだレイヤーが混ざっています。
『代替名称を使って別の文字とみなす場合』だけではなく、『一つの符号化方式で複数の文字集合を扱った場合に、同じ文字が複数のコードポイントにあらわれる場合』があります。後者では半角・全角は不適です。
Re:文字コード間変換 (スコア:1)
『規格に書いてある』『規格に書かれていない』『(使うべきでないという)考え方だ』のどれも明記されているわけじゃありません。
判断に困ったから、まず規格の文言なのかA.C.の考え方なのか確認をしようとしていたんです。考え方の話は長くなりやすいから避けたいし、私が規格の文言を見落としているだけ という可能性は潰しておきたかったので。 kanieさんがそう考えているのはもう知っています。kanieさんが答えている内容が、私が今知りたいことでは無いということもはっきり分かりました。
私は『規格に使うなと書いてある』なら『使わない/使えない』と考えるので「kanieさんとは言葉の定義か考え方が自分と違うんだな」としか捉えられないです。
私の見落としの可能性が残っている状態じゃなおさらです。
『使うべきではない』という文言が規格に使われている箇所があるのか? に対する回答は無いでしょうか?
Re:文字コード間変換 (スコア:1)
あなたは暴れすぎですね。
Re:文字コード間変換 (スコア:1)
まったく別物ですよ。混同しているのでは?
後者は『両者を異なった文字として用い』ない場合です。
Re:文字コード間変換 (スコア:1)
若い人は、まともに教育すれば使わなくなるんだからまだ救いがある。
Re:文字コード間変換 (スコア:1)
どの規格にも明記されはじめたので。