アカウント名:
パスワード:
なんで㍻なんてのが必要なのかわかりません。「平成」でいいじゃないですか。
組文字をコードに入れたJISとか、そもそも機種依存文字の時代にそんなもん作ったメーカ(NECか富士通か知らないですが)に文句を言うべきかと。
1バイト、1ビットでも貴重だった昭和の頃ですから仕方なかったと思います。「昭和」で4バイト、外字「㍼」が2バイトなら小さいほうを選ぶのが正義です。「M/T/S」にして1バイトにしても今度は変換しなきゃならなくなりますからね。
よく言われるバイト節約の神話ですが、ぶっちゃけ元号と西暦ではそこまで差はないです。というか、固定レコード長上等の時代にはそれ以外の無駄の方がやたらと多くて正直誤差ですよ。とくにデータ境界を揃えたりとかやってると。
あとはまぁ、「入力した日付(元号+月日)をそのまま出力させる」ことが要求されるケースとか。例えば「昭和64年1月10日」の原データがあったとして、これを1989年1月10日で記録して出力時に元に戻そうとすると結構面倒なんですわ。果たして1989年1月10日は昭和64年か平成1年か? 西暦で保持してこれを「正しく」判定するには更に何らかの情報が必要になるという…。
汎用機の漢字in-漢字outとか知らない若い人かな?もう少し過去の事情を知らないと、ドヤ顔解説には向かないですよ
だから「元号採用がバイト数の節約」はそれほど効果のある話ではないって事だろ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
素朴な疑問ですが (スコア:0)
なんで㍻なんてのが必要なのかわかりません。
「平成」でいいじゃないですか。
Re: (スコア:1)
組文字をコードに入れたJISとか、そもそも機種依存文字の時代にそんなもん作ったメーカ(NECか富士通か知らないですが)に文句を言うべきかと。
Re:素朴な疑問ですが (スコア:0)
1バイト、1ビットでも貴重だった昭和の頃ですから仕方なかったと思います。
「昭和」で4バイト、外字「㍼」が2バイトなら小さいほうを選ぶのが正義です。
「M/T/S」にして1バイトにしても今度は変換しなきゃならなくなりますからね。
Re: (スコア:0)
よく言われるバイト節約の神話ですが、ぶっちゃけ元号と西暦ではそこまで差はないです。
というか、固定レコード長上等の時代にはそれ以外の無駄の方がやたらと多くて正直誤差ですよ。
とくにデータ境界を揃えたりとかやってると。
あとはまぁ、「入力した日付(元号+月日)をそのまま出力させる」ことが要求されるケースとか。
例えば「昭和64年1月10日」の原データがあったとして、これを1989年1月10日で記録して
出力時に元に戻そうとすると結構面倒なんですわ。
果たして1989年1月10日は昭和64年か平成1年か? 西暦で保持してこれを「正しく」判定するには
更に何らかの情報が必要になるという…。
Re: (スコア:0)
汎用機の漢字in-漢字outとか知らない若い人かな?
もう少し過去の事情を知らないと、ドヤ顔解説には向かないですよ
Re: (スコア:0)
だから「元号採用がバイト数の節約」はそれほど効果のある話ではないって事だろ。