アカウント名:
パスワード:
日付の比較で数字を数値に変換して判定してるんですね。意外。 てっきり日付型に変換して比較してるかと思ってました。
ところで、桁に意味を持たせたコードって一般的だと思うんだけど、それを数値に単純に数値として扱うのって一般的なのでしょうか。 仕事で業務システム間で連携するデータをEUCでやれという状況になってて、Access+VBAでプログラムを作ってます。 データ交換の資料がCSVの項目しか無かったりで、メーカーのSEと相談することが多いけど、自社製品でユーザーIDは8桁の数字としていて、各桁に意味を持たせたりしてるのに、交換用データにする時は数値として扱うのが普通みたいで驚いてます。
Microsoft CSVでは、「数値に見える文字列」は、たとえクォーテーションマークで括ってあっても数値として扱われます。そう言う事じゃないんでしょうか。
Microsoft CSVだからではなくExcelという表計算ソフトだからですね。他の表計算ソフトでもそのような仕様があったりします。
文字列にするのも同程度に一般的かと。
# JavaScriptで64-bitの整数IDが化ける
> JavaScriptで64-bitの整数IDが化ける
ちょっと話は変わるけど、VBAは符号無しの数値型が無いですね。 困ったのがutf-8で外字かどうかの判断。 私用領域(外字範囲)の途中から補数で負になってしまうため、文字コードを範囲指定できないのですね。 仕方なく正規表現で判断するようにしたけど、何か方法があるのかしら。
utf-8なら8ビットでは?どういう符号化をしたら私用領域の途中から補数で負になるのか想像がつかない。
Currency型を使うとか?
8bitに限ってはByte型がある
本当にUTF-8で8bit単位なら非ASCII文字はすべて負になるので「私用領域(外字範囲)の途中から」という説明と合わない。だからUTF-8とUnicodeの区別がついていないとかそういうレベルの混乱を疑っている
> Unicodeの区別がついていないとかそういうレベルの混乱を疑っている
御明察のとおりです。それとデータ交換する歳の外字についての話です。 (文字集合でUnicode,文字エンコードでutf-8)のつもりでutf-8と書いてました(日本語でutf-8を使うならUnicodeだろうという思い込みで)。
つ BigInthttps://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_... [mozilla.org]# BigIntが使えないブラウザの対応を止めるのは駄目なんだろうなぁ
各桁に意味を持たせたn桁の数字をIDとしたときに、CSVとして扱う過程で数値に変換されてバグるとか、まれによくあるやつですね。「12345678」を数値に直しても「123456789」のままだけど、「00001234」を数値に直すと「1234」になるので齟齬が生じるという。若いIDでテストしないと気付かないでスルーされちゃう。
> まれによくあるやつですね。
さすがに桁数が増えるのはないかなぁ。
たまにあるんやない? 昭和99年→昭和100年とか。
#4179180の話でしょ。
つバージョン番号
あるよ。CVEのシリアル番号。シリアル番号は4桁の0001から始まるが、CVE-YYYY-9999の次は、10000と5桁になる。
CSVとして扱う過程で数値に変換されてバグる
dnsのシリアルでは一般的な作法ですね。数値として(おおむね※)大小比較される前提で、日付を桁にエンコードします。
※単なる大小比較ではないので、注意。
DNS のシリアルは unsigned なのよね。
ISBN-10(9桁の数字+1桁のチェックディジット)みたいな罠があるので油断ならんね。実はまれに枝番があるとか。
> 自社製品でユーザーIDは8桁の数字としていて、各桁に意味を持たせたりしてるのに
こういうやり方だと長期間使うソフトウェアでは途中で桁の意味が変わったりしてトラブることがよくあるので要件として存在する場合、これとは別に真のユーザーIDを自動採番で作るのが普通ですね
日付型が無い時代に作られたやつ相手にするソフトだと数値か文字列でくれ!と求められますからねぇ。
>Access+VBA前世紀ですけど1/1/1〜9999/12/31を日の精度で扱えるように作った。10年前くらい同業のイトコからJavaのヤツにそれが載っかってると聞いて絶句…#作成者の名前くらい直せ…
古くなくても通信プロトコルで日付型をそのまま使う/使える方が少ないだろ。NTPですらEra number導入してるんだから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
数字と数値 (スコア:1)
日付の比較で数字を数値に変換して判定してるんですね。意外。
てっきり日付型に変換して比較してるかと思ってました。
ところで、桁に意味を持たせたコードって一般的だと思うんだけど、それを数値に単純に数値として扱うのって一般的なのでしょうか。
仕事で業務システム間で連携するデータをEUCでやれという状況になってて、Access+VBAでプログラムを作ってます。
データ交換の資料がCSVの項目しか無かったりで、メーカーのSEと相談することが多いけど、自社製品でユーザーIDは8桁の数字としていて、各桁に意味を持たせたりしてるのに、交換用データにする時は数値として扱うのが普通みたいで驚いてます。
Re:数字と数値 (スコア:1)
Microsoft CSVでは、「数値に見える文字列」は、たとえクォーテーションマークで括ってあっても数値として扱われます。
そう言う事じゃないんでしょうか。
Re: (スコア:0)
Microsoft CSVだからではなくExcelという表計算ソフトだからですね。
他の表計算ソフトでもそのような仕様があったりします。
Re: (スコア:0)
文字列にするのも同程度に一般的かと。
# JavaScriptで64-bitの整数IDが化ける
Re:数字と数値 (スコア:2)
> JavaScriptで64-bitの整数IDが化ける
ちょっと話は変わるけど、VBAは符号無しの数値型が無いですね。
困ったのがutf-8で外字かどうかの判断。
私用領域(外字範囲)の途中から補数で負になってしまうため、文字コードを範囲指定できないのですね。
仕方なく正規表現で判断するようにしたけど、何か方法があるのかしら。
Re: (スコア:0)
utf-8なら8ビットでは?
どういう符号化をしたら私用領域の途中から補数で負になるのか想像がつかない。
Re: (スコア:0)
Currency型を使うとか?
Re: (スコア:0)
8bitに限ってはByte型がある
Re: (スコア:0)
本当にUTF-8で8bit単位なら非ASCII文字はすべて負になるので「私用領域(外字範囲)の途中から」という説明と合わない。だからUTF-8とUnicodeの区別がついていないとかそういうレベルの混乱を疑っている
Re:数字と数値 (スコア:1)
> Unicodeの区別がついていないとかそういうレベルの混乱を疑っている
御明察のとおりです。それとデータ交換する歳の外字についての話です。
(文字集合でUnicode,文字エンコードでutf-8)のつもりでutf-8と書いてました(日本語でutf-8を使うならUnicodeだろうという思い込みで)。
Re:数字と数値 (スコア:1)
つ BigInt
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_... [mozilla.org]
# BigIntが使えないブラウザの対応を止めるのは駄目なんだろうなぁ
Re: (スコア:0)
各桁に意味を持たせたn桁の数字をIDとしたときに、CSVとして扱う過程で数値に変換されてバグるとか、まれによくあるやつですね。
「12345678」を数値に直しても「123456789」のままだけど、「00001234」を数値に直すと「1234」になるので齟齬が生じるという。
若いIDでテストしないと気付かないでスルーされちゃう。
Re:数字と数値 (スコア:4, おもしろおかしい)
ちょっと待て
Re: (スコア:0)
> まれによくあるやつですね。
さすがに桁数が増えるのはないかなぁ。
Re: (スコア:0)
たまにあるんやない? 昭和99年→昭和100年とか。
Re: (スコア:0)
#4179180の話でしょ。
Re: (スコア:0)
つバージョン番号
Re: (スコア:0)
あるよ。CVEのシリアル番号。
シリアル番号は4桁の0001から始まるが、
CVE-YYYY-9999の次は、10000と5桁になる。
Re: (スコア:0)
CSVとして扱う過程で数値に変換されてバグる
Re: (スコア:0)
dnsのシリアルでは一般的な作法ですね。数値として(おおむね※)大小比較される前提で、日付を桁にエンコードします。
※単なる大小比較ではないので、注意。
Re: (スコア:0)
DNS のシリアルは unsigned なのよね。
Re: (スコア:0)
ISBN-10(9桁の数字+1桁のチェックディジット)みたいな罠があるので油断ならんね。
実はまれに枝番があるとか。
Re: (スコア:0)
> 自社製品でユーザーIDは8桁の数字としていて、各桁に意味を持たせたりしてるのに
こういうやり方だと長期間使うソフトウェアでは途中で桁の意味が変わったりしてトラブることがよくあるので
要件として存在する場合、これとは別に真のユーザーIDを自動採番で作るのが普通ですね
Re: (スコア:0)
日付型が無い時代に作られたやつ相手にするソフトだと数値か文字列でくれ!と求められますからねぇ。
>Access+VBA
前世紀ですけど1/1/1〜9999/12/31を日の精度で扱えるように作った。
10年前くらい同業のイトコからJavaのヤツにそれが載っかってると聞いて絶句…
#作成者の名前くらい直せ…
Re: (スコア:0)
古くなくても通信プロトコルで日付型をそのまま使う/使える方が少ないだろ。
NTPですらEra number導入してるんだから。