Microsoft 365 バージョン2309、Excelで先頭のゼロを削除しない設定が登場 53
ストーリー by nagazou
実装 部門より
実装 部門より
「Excel」の最新バージョン「2309」では、以前からテスト中だった、「自動データ変換」機能を抑制するオプションが追加されたそうだ。Excelで商品コードなど、ゼロから始まることのあるデータをインポートすると、自動的に数値として扱われ、冒頭のゼロが消えてしまうことがある。先頭のゼロを削除して数値に変換するといった自動データ変換機能が原因だった(窓の杜)。
そこで、この自動データ変換を無効化するオプションがテストされていたが、「2309」で正式な機能として導入された。加えて、CSVファイルなどを読み込む際に自動データ変換が実施されていれば通知する機能も導入された。意図した形でデータが読み込まれない場合、自動データ変換が問題を起こしていることが把握できるほか、その場で無効化もできるとしている。永続的に無効化することも可能。これにより、データの取り込みをスムーズに行えるようになったとしている。
そこで、この自動データ変換を無効化するオプションがテストされていたが、「2309」で正式な機能として導入された。加えて、CSVファイルなどを読み込む際に自動データ変換が実施されていれば通知する機能も導入された。意図した形でデータが読み込まれない場合、自動データ変換が問題を起こしていることが把握できるほか、その場で無効化もできるとしている。永続的に無効化することも可能。これにより、データの取り込みをスムーズに行えるようになったとしている。
先頭の0なんて絶対許さない世の中にしてくれればミスらなかったのに (スコア:2)
いままでこれが理由でお客様にはできる限り
コードは0以外から始めるようにしてくださいってお願いしてた。
逆に混乱が起きる気がする。
Re: (スコア:0)
コードは0以外から始めるようにしてくださいってお願いしてた。
斜め上に気を利かせて「’0****」で振ってきたりして
# EXCELやCSV上でのみ生きるが実際のシステムでは、、、
Re: (スコア:0)
数字のみのコードは使わず必ず英文字で始めてくださいでいいじゃん。
コードの種類を識別できるようにするためだとかなんとか理由をつけて
Re: (スコア:0)
電話番号が無理すぎる
Re:先頭の0なんて絶対許さない世の中にしてくれればミスらなかったのに (スコア:2)
電話番号は日本に限れば最初が0でなければ0つければいいかと思うのでなんとか対応可かなと思います。メンドいですが。
Re: (スコア:0)
国際番号で書けば…と思ったが先頭の+がやっぱり消えそうだ
Re: (スコア:0)
インドの数学者にでも文句言えばw
コピペはどうなるんだろう (スコア:1)
003をコピペすると3になるのが003になるんだろうか
Re: (スコア:0)
逆に必ず先頭の0が削られる動作を期待してる人から苦情から来るから、社内のエクセルを設定する必要あるかも。
戻せるようにしておけないものなの? (スコア:1)
文字データとして持っておいて、表示と計算だけ扱いを買えるようにすればいいと思うんだけど、なんで不可逆に変換しちゃうんだろう……。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re: (スコア:0)
12,345と12.345はどちらが大きいか、09/10/08と10/09/08はどちらが前か、国によって揉めそう。
#Excelは計算量を減らすためにそういう仕様になったんだろうけどね。
Re: (スコア:0)
文字データとして持っておいて、表示と計算だけ扱いを買えるようにすればいいと思うんだけど、なんで不可逆に変換しちゃうんだろう……。
そこは運用マターですから故となるかと
# 文字列で保持してvalue()で数値化しつつ計算する感じで
Re: (スコア:0)
セルの値が空欄か数値か文字列かを判定したりも出来る
→どれであるかは一意に決まる必要がある
個人的には自動型変換したあとに変換前と異なる文字列になっちゃう書式を指定してんのが駄目なんだと思う。
ユーザ書式でいいから変換前と同じ文字列になる書式が適用されてりゃだいぶ出来る事が増えると思う
(例:携帯番号はゼロ詰め11桁の数値表現、とかね)
Re: (スコア:0)
ZIPとして読み込めば元の文字データが得られるので、自前のローダではそっちばっかり読んでますね。速いし。
CSV開くの楽になるかな (スコア:0)
データ区切りや型を指定して取り込むよりも簡単になるかな
Re: (スコア:0)
100,002,300というデータがあったときに、合計が402や0ではなく、400でいいのかい?
Re: (スコア:0)
それはどう取り込みたいかの話であって
その話だとそもそも開く時に勝手な変換止めてほしいって話の方がポイント
100万行未満に限るけどCSV編集ツールとして余計な変換さえしなければやっぱりExcelは便利
他にもいろいろ変換あるかもしれんけど個人的に困ったのは
・日付っぽい列がExcelの日付型に変換される
・デフォルトで各列全てダブルクォーテーション括りなCSVもExcelで開くと必要な列だけダブルクォーテーションが残る
とかこの辺り
他でも書いたけどそもそもCSVが仕様を定めてから使いだしたものじゃないからしゃーないけど
Re: (スコア:0)
データ区切りや型を指定して取り込むよりも簡単になるかな
PHP「でしょ~」
Re: (スコア:0)
CSVを開くと「0を消すのか消さないのか、どっちにする?」と尋ねてくれるんだけど、
消してほしい列と消してほしくない列が混在してる場合も有るわけで、Microsoft
にはもうひと頑張りして欲しいところ。
Re: (スコア:0)
Excelのインポート機能を使うと良いよ!まさにその機能。
Re: (スコア:0)
住所を日付に変換してくれる便利機能も健在だよ
Re: (スコア:0)
CSV使うのやめて型とか書式も保存できるテキスト形式のSYLK使おうぜ!とか出来たら良いのだが、Unicode非対応なんだよなぁ。
# CSVをIDで始めると誤認したアレ。
違うそうじゃない (スコア:0)
クオーテーションで囲んでる要素は文字列型と認識してくれるだけでいいんだ
Re: (スコア:0)
その中にhref="hoge"とかあると……。
Re: (スコア:0)
それは href=""hoge"" にしてあるでしょcsvなら。
Re: (スコア:0)
それはたまたま君の使ってきたcsvの方言の一つがそうだっただけ。
Re: (スコア:0)
それはたまたま君の使ってきたcsvの方言の一つがそうだっただけ。
逆でしょ
セルやフォーム内でダブルクォーテーションエスケープしてないのが当たり前なんて昭和のノーガードくらいなものでしょう
Re: (スコア:0)
「昭和のノーガード」も「ダブルクォーテーションを重ねてエスケープ」も「バックスラッシュでエスケープ」(Sequel Proなんかではまだ生きてる)も、ぜんぶ正しいcsv。「ダブルクォーテーションを重ねてエスケープ」はそんな方言の中でたまたま広く使われるようになっただけ。
csvなら「ダブルクォーテーションを重ねてエスケープ」が当然というのは間違い。
Re: (スコア:0)
「昭和のノーガード」も「ダブルクォーテーションを重ねてエスケープ」も「バックスラッシュでエスケープ」(Sequel Proなんかではまだ生きてる)も、ぜんぶ正しいcsv。「ダブルクォーテーションを重ねてエスケープ」はそんな方言の中でたまたま広く使われるようになっただけ。
一応、今はRFC 4180もあるんで、流石にこれは言い過ぎ。
デファクトスタンダードが元だとしても、規格や仕様として確立されたのだから。
# そうじゃなきゃ標準化なんてできないよ
Re: (スコア:0)
でも、RFC 4180はあくまでInformationalであって、厳密に従うと今度は文字コードの問題が出るからなぁ。
US-ASCII前提の"TEXTDATA = %x20-21 / %x23-2B / %x2D-7E"なんて記述が有るし。
Re: (スコア:0)
ISOとかならともかくRFCで「規格や仕様として確立された」はさすがに言い過ぎ。
Re:違うそうじゃない (スコア:1)
RFC 4180はあくまでもcsvの比較的メジャーな方言を後追いで文書化したものに過ぎないので、それを指したいならcsvじゃなくてRFC 4180ってちゃんと書かないと。君、人に物事を伝える仕事を一度もしたことないでしょ。
あと、
> デファクトスタンダードが元だとしても、規格や仕様として確立されたのだから。
は大嘘だね。
自分で持ち出しときながらRFC 4180を読んですらいないのがよく分かる。
RFC 4180の先頭には、ちゃんとただのメモに過ぎず標準の類ではないと明記されてる。
This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
Re: (スコア:0)
21世紀になってもわりとみかける。
Re: (スコア:0)
「だけ」でもないんだけど、しかし引用符で頭に0入ってても数値化される仕様には頭抱えますね。
ン十年前に仕様引いた時は「とりあえず今はこれでいいだろ」だったんだろうなあ。
Re:違うそうじゃない (スコア:1)
数値でも何でも全部 " でくくる、というCSVデータもあれば、
改行・コンマ・"が含まれる場合のみ、"でくくる(そうでなければ文字列でもくくらない)というCSVデータもあるので、
「"でくくってたら文字列」「くくってなければ数値」って挙動も、それはそれで問題になりえる。
諸悪の根源はCSVの仕様の曖昧さなので、「型を指定する」以外に万能の解決策はないと思う。
自分にとっては、
・CSVの関連付け(ダブルクリック)でも、テキストインポートで開く
・テキストインポートで、過去に取り込んだ設定に基づいた取り込みができる
(見出し行を元に過去履歴から自動で設定してくれるとなお良し)
って挙動になるが一番うれしい。
Re: (スコア:0)
広く使われてる割に標準仕様が定まってなかったからしょうがないね
公開されたRFCだって後付けだし
そっちもなんだけど。 (スコア:0)
3E7とか 16進数も 3e^7に自動変換するのやめる機能作って欲しいです・・・。
Re:そっちもなんだけど。 (スコア:1)
画面表示と印刷結果が一致するのとどっちが早いかな?
-- う~ん、バッドノウハウ?
Re: (スコア:0)
窓の杜のリンクを見るとそれらも別途オプションが用意されてるみたいよ。
Re: (スコア:0)
ハイフン・スラッシュ入りの数字を意地でも西暦にする機能もオフで…。
いい加減shiftJIS設定廃止してくれ (スコア:0)
.CVSのShiftJIS指定はもはや迷惑でしかない。
Re: (スコア:0)
指定出来るようにはしておいて欲しいが、BOM無しの場合に一律でSJIS扱いされるのは迷惑かもしれん。
Re: (スコア:0)
試したことないけどコードページ依存じゃない?
他の国や言語でもShiftJISになるなんてことないだろうし。
Re: (スコア:0)
UTF-8なら文字コード0~127は1バイトなので、その範囲の英数記号で書いてあれば
UTF-8もISO/IEC 8859もシフトJISも同じものになり区別はつきません
Re: (スコア:0)
区別する必要がないケースを持ち出して何が言いたいのかわからん
Re: (スコア:0)
「俺様はUTF-8の仕様を知ってるんだぞ! すごいんだぞ!」って言いたいんじゃない?
Re: (スコア:0)
BOMなしのUTF-16「あの」
この自動変換が役に立ったことあるのか? (スコア:0)
インポートするときに取り除いて欲しくなるのに、数字列の先頭にゼロを付けて保存していることなんてあるのか?
Re: (スコア:0)
COBOLで何も考えずにDISPLAY(出力命令)するとゼロパディングしてきたはず。
PIC ZZ9とかしてゼロサプレスを明示するか、LOG10して切り捨てないとダメだったと思う。
パソコンで触るCSVのネタ元がホストコンピューターで動くCOBOL製バッチの中間出力の日報とかで、
固定長データ形式のファイルのレコード間に","やTabを入れただけのCSV(※)だったりしたなら、
ゼロパディングされていても、数値として扱いゼロサプレス化する事にも一定の合理性があったんだと思う。
そいつを今まで引きずっていたと。
※","やTabなしの固定長データファイルをそのまま配布すると、表計算アプリで開く際にフィールド長情報を設定しないといけない。
固定長データ形式でも、","やTabだけの区切り用フィールドをフィールド間に挟み込めば、
ストレージやメモリ効率は悪くなるけど、表計算アプリでフィールド長情報を調べずに開けるようになるというハック。
Re: (スコア:0)
COBOLに限らず固定長データならゼロ埋めはよくあることだよね……