【Googleスプレッドシート表示形式】見えているものも大切なんだよ ってはなし
ExcelとGoogleスプレッドシート、違ってる点は色々ありますが今回は勘違いしやすい(ミスを起こしやすい)表示形式の話をしましょう。
この「表示形式」の ExcelとGoogleスプレッドシートの扱いの違いを知らないと、
Excelと同じ感覚でGoogleスプレッドシートで数式を作ってしまったり、逆にGoogleスプレッドシートと同じ要領でExcelで式を作ってしまうと、想定外の結果が返ってきて
「なんでそーなるの!」(コント55号)
と混乱してしまうかもしれませんw
というわけで、しっかりこの noteでポイントを学んでおきましょう!ついでに スキボタンも押しちゃいましょうw
先週の noteは LETとLAMBDAで書く再帰式でサイコロシミュレーションを作ってみました。
ちなみに今回のタイトルですが、以前書いた「GAS 大切なことは目に見えないんだよ ってはなし」のアンサーソングみたいなイメージですw
Googleスプレッドシートの文字列系関数は、セルに表示された情報をそのまま扱う
今回の伝えたい事は 👆 これです。
Googleスプレッドシートの 文字列関数の挙動
この結果、違和感がありませんか?
=LEFT(A2)
LEFT関数でA2セルの左から1文字を取得すると ¥ が
※LEFT関数で第2引数を省略した場合は 1として扱われます
=MID(A2,5,1)
MID関数でA2セルの左から5番目から1文字取得すると , が
=SPLIT(A2,",")
SPLIT関数で , を区切り文字として分割すると ¥199 と 800 が
=LEN(A2)
LEN関数で文字数を取得すると ¥と , も1文字とカウントして 8 が
結果として返っています。
「んん??」となる人は Excelを使ってきた人ですね。
A2 セルの ¥199,800 は あくまでも表示形式を「通貨(JPY)」に設定しているから、見た目だけ 先頭の ¥ や 3桁区切りの , が表示されているだけで、A2セルの実態(真の値)は数式バーに表示されている 199800 という数値だからです。
つまり Googleスプレッドシートの場合は、本当の中身の値ではなくセルに表示されている表示形式が適用された結果 を対象として処理をしているということです!
Excel の文字列系関数は表示形式に影響されない
一方、Excelの場合は違います。
=LEFT(A2)
LEFT関数で 199800 の左から1文字を取得して 1 が
=MID(A2,5,1)
MID関数で199800の左から5番目から1文字取得すると 0 が
=TEXTSPLIT(A2,",")
TEXTSPLIT関数で , を区切り文字として分割しようとしても、199800には , は存在しないので 文字列化された 199800 が
=LEN(A2)
LEN関数で文字数を取得すると ¥や , は無視され 199800の文字数 6 が
結果として返ります。
Excelに慣れている人は、これが当然なんですよね。
セルに表示されているのは「表示形式」が付加された(いわゆる インスタ等の画像加工で 盛られた)もので、数式バーに表示される 真の値(すっぴんの状態)が本物である、という感覚かと思います。
Excelはセルの表示形式に惑わされることなく、真の値(199800)を対象として結果を返す ってことです。
同じ値に対して 同じ関数 で返る結果なのに Googleスプレッドシートと Excelで違う!
これは落とし穴ですよねw
Googleスプレッドシート の文字列系関数は 表示形式を変更すると再計算され結果が変わる
Googleスプレッドシートの文字列系関数が、表示形式を適用したあとのセルに表示された「目に見える」ものを対象とするということは、
表示形式を切り替えたら 関数の結果が変わる
ということです。
上の動画を見てください。最初に 199800 だったものを メニューバーの ¥ボタンで 表示を「通貨」とすると 関数の結果が全て変わりました。
さらに表示形式を
199800 → ¥199,800.00 → ¥199,800.0 → ¥199,800
と変えると 連動して LEN関数で取得した文字数が
6 → 11 → 10 → 8
と変化しているのが分かりますね。(最後は 小数点以下の表示がなくなっているので .0 の2文字が減っている)
面白いですが、関数の結果が表示形式で変わってしまうのは結構怖い ですしExcelに慣れている人からすると かなり違和感があるかと思います。
一方 最初に触れる表計算がGoogleスプレッドシートの世代だと、これが当たり前で「Excel側が 見た目と結果が違うの変じゃね?」って感覚なのかもしれませんね。
日付、日時のケースを確認しよう
それでは、数値以上に 表示形式と中身(シリアル値)が違う 日付や日時の場合はどうでしょうか?
確認していきましょう。
Excelの場合は日付は数式バーでも見ても日付形式。でも文字列系関数で扱う場合は シリアル値を対象とする
先にExcelから見ていきましょう。
たとえば 2024/12/07 という日付データが A2に入っていた場合、このセルを選択して数式バーで中身を見ても 2024/12/07 となっています。
じゃあ 2024/12/07 は真の値か?というと、そこはなんとも微妙で 数式内で利用すると
2024/12/07 は シリアル値 45633 として扱われます。
その為、LEFT関数で一番左の1字を取得すると 4 ですし、RIGHT関数で取得した一番右の1字は 3、LEN関数の文字数は 5と、全てシリアル値 45633を対象とした結果が返ります。
先ほどの 通貨のケースは 数式バーに真の値が表示されているので良いですが、日付はパッと見どこにも 表示されてない 45633 という数値で扱われるというのは、初心者にはなかなか理解しがたかい点かもしれません。
シリアル値ってなになに??という方は、数式でカレンダーを作る回の noteで 少しシリアル値について触れてますんで参照ください。
Googleスプレッドシートは 日付データは 表示されているものを 文字列系関数で扱える
A2セルの 2024/12/07 から 年だけを取り出そうとして =LEFT(A2,4) としても、シリアル値を対象とする Excelでは意味がありません。
しかし、Googleスプレッドシートだと コレがいけちゃうんです。
文字列系関数で取り出した 2024は 数字で構成された文字列であることに注意は必要ですが、 =LEFT(A2,4) で 年の部分 2024が取り出せちゃいましたw
=SPLIT(A2,"/") とすれば、横並びで 年、月、日が 数値で取得できます。
表示が 2024年12月7日(土) となっている日付データだった場合は
=SPLIT(A2,"年月日()")
とすれば、年、月、日、曜日 を一発で取得できますし
=MID(A2,LEN(A2)-1,1)
で 曜日の 土 だけを抜き出すことができます。
日付データをSPLIT関数で 年、月、日 に分割する方法は、以前の SPLIT関数の超応用例でも紹介しました。
Googleスプレッドシートなら 簡単に 日時を 日付と時間に分割できる
さらに 日時表示だった場合は、 日付と時間の間に半角スペースがあることを利用して簡単に 日付と時間に分割できます。
たとえば A2セルに 2024/12/07 17:35:10 という日時データが(このままの表示で)入っていた場合
=SPLIT(A2," ")
このように 半角スペースを区切り文字としてSPLITするだけで、日時を一発で日付と時間に分割することが出来ちゃいます。
超簡単ですね。
日付系関数を理解した上で注意して使おう
上で紹介した 表示形式とSPLIT関数を利用して 曜日を取り出したり、年月日に分割したり、日付と時間に分割する方法は 便利で簡単なんですが、 Excelでは通用しないのと、表示形式が変わってしまった時に正しい結果が返らないというリスクがあります。
その点を理解し、かつ 正攻法(日付系関数を使う方法)もしっかり理解した上で使いましょう。
その他の表示形式のケースを確認しよう
通貨、日付、日時以外の表示形式も同様に 見た目のまま 文字列系関数で扱えるのか?確認していきましょう。
パーセント表示、カスタム数値形式
パーセント表示やカスタム数値形式も影響を受けますね。
最後の文字を取得する RIGHT関数の結果がわかりやすいですが、パーセント表示は最後の1文字が % となっており、 カスタム数値形式で「0個」という設定をした方は 最後の1文字が 個 となっていますね。
特殊なカスタム数値形式の場合
では、カスタム数値形式で
このようにした場合はどうでしょうか?
これは ; の前後で 正の数の時と、負の数の時で 表示形式を分けて設定する書き方です。
#,##0 この部分が 3桁数字のカンマ区切りの指定
_) _ の後ろの文字と同じ幅のスペースを入れるという意味です。
この場合 ) と同じ幅のスペースを入れることにより、
負の数でも正の数でも 数字の右端を揃えることが出来ます。
[Red] 書式設定で簡易的に条件付き書式のように
条件に応じて色を付けることができます。
今回の場合は ;の後ろに [Red](#,##0) と指定しているので、マイナスの時は 赤字で カッコで囲んだ カンマ3桁区切りの数値を表示するという指定になっています。
セルに 8を入れた場合、これは正の数なので
このように数値の後ろに ) 分のスペースが入るのですが、これを 1文字とカウントしているようで、 RIGHT関数で 右端の1文字を取得すると 半角スペース ですし、LENで取得した 文字数は 2文字となります。
-15と入れた場合は、表示される (15) を対象として 先頭、末尾はそれぞれ ( ) となり、全部でカッコを含めた 4文字という結果になります。
もう一つの特殊な表示形式 セル埋めを見てみましょう。
*は、後ろに付けた文字列を セルの幅分くりかえして埋めるという表示形式の設定です。
なので 0*/ とすれば 入力した数字の右側 を ///// と繰り返しセルの隙間を埋めますし、 */0 とすれば 数字の左側を //// と埋めます。
このように セルの幅を変えるのに応じて / の 繰り返し数は見た目上は増減しますが、LEN関数で取得する文字数には変化がありません。
どうやら この表示形式の場合は、繰り替えし文字 / は1つと見なしてカウントしているようで 見た目上の繰り返しは 数式側には影響しないみたいです。
セルの見た目のまま テキストとして取得する TO_TEXT関数で確認すると 中身は 200/ と、やはり /は1つのみ付いているのがわかります。
チェックボックス、真偽値は 表示形式に影響されない
チェックボックスはどうでしょうか?
チェックボックスは チェックオフが FALSE(5文字)、チェックオンが TRUE(4文字) として 文字列操作関数では扱われるようです。
チェックボックス表示かどうかは、影響ないみたいですね。チェックボックスは表示形式というより、データの入力規制だからでしょうか?
文字列の表示形式は 文字列操作系関数には影響がない
実は同じ表示形式でも @ で指定する 文字列の表示形式の場合は、文字列操作系関数に影響を与えません。
上は @様 というカスタム表示形式で 文字列の後ろに「様」をつけています。
しかしRIGHTで取得した最後の1文字は 田中の 「中」ですし、文字数は 2文字となっており、表示形式で付与した 「様」が文字列系関数では認識されていません。
数値(日付や日時含む)の表示形式は文字列系関数に影響があるけど、文字列 や 真偽値 の表示形式は影響がないってことですね。
数値の表示形式の影響を受ける関数
次に 数値(日付や日時含む)の表示形式で影響を受ける主要な関数を確認しておきましょう。
文字列系関数は影響を受ける
まず、最初から登場している文字数を取得するLEN関数、そして 文字列から指定した箇所を抽出する LEFT関数、MID関数、RIGHT関数、これらは影響を受ける関数です。
文字列探索、置換系関数も影響を受ける
FINDやSEARCHといった文字列を検索する関数、そしてSUBSTITUTEやREPLACEなどの置換系関数も 表示形式適用後の値を対象として処理がされます。
中身が数値であることは変わらず REGEX系関数は使えない
日付の表示形式で 2024年12月7日(土) と見た目は文字列のようになっていても、中身がシリアル値(数値)であるおとには変わりありません。
セルが文字列かどうかを調査する ISTEXT関数で評価すると FALSEを返しますし、日付かどうかを判定する ISDATE関数、数値かどうか判定する ISNUMBER関数 は、どちらも TRUEを返します。
その為、文字列を対象とし 数値を引数にとれない REGEX系の関数 REGEXMATCH、REGEXEXTRACT、REGEXREPLACE は 使用できません。
文字列結合系、文字列分割系関数は 関数によって違う
文字列結合系関数は関数によって違います。
CONCAT関数やCONCATENATE関数 のような区切り文字を挟まない単純結合の関数は 表示形式の影響を受けず 日付はシリアル値に戻して 連結します。
関数ではないですが 演算子の & による連結も同様です。
一方、区切り文字を入れて文字を連結する JOIN関数やTEXTJOIN関数、逆に区切り文字を指定して分割する SPLIT関数は 表示形式を 適用した後の値を対象とします。(影響を受けます)
REPT関数も 表示形式の影響ありで、セル上で見えるまま繰り返されます。
DATEVALUEは 表示形式の影響を受ける
日付文字列を シリアル値に変換する DATEVALUEという関数があります。
ちょっとわかりづらいんですが、これは 日付の形になっている文字列をシリアル値変換する関数であって、本物の日付データ(文字列ではない)には本来は使うことができません。(Excelでは出来ない)
しかし Googleスプレッドシートの場合は、本物の日付データでも 表示形式が yyyy/MM/dd だったり、yyyy-MM-dd 、yyyy年MM月dd日 の場合は、DATEVALUE関数が使えます。
一方、曜日情報を表示させた yyyy年MM月dd日(ddd) だと DATEVALUE関数は機能せずエラーを返します。同じく シリアル値そのままの場合もダメです。
中身の情報は同じでも、表示形式によっては関数がエラーを返す例ですね。
EXACT関数は 表示形式の影響を受ける
2つの文字の厳密な一致を判定する関数が EXACT関数です。
Excelの場合は 表示形式が違っていても 中身が一緒であれば EXACT関数は TRUEを返します
しかし Googleスプレッドシートの場合は EXACT関数は 数値の表示形式の影響を受けます。
表示形式を変えただけで
コロっと騙されちゃう EXACTさん・・・。
厳密ってなにかね??って感じですね。
文字列系関数以外は 基本的には 影響を受けない
COUNTIFやXLOOKUP、XMATCHなどの関数は ワイルドカードを使って 指定した文字列を「含む」セルを検索できます。※ XLOOKUP、XMATCHは検索モードを 2に指定する必要あり
しかしこれらの関数は文字列系関数と違って、表示形式の影響を受けません。
その為 2024年〇月〇日(〇) と表示されているデータ範囲を "*年*" で検索しても、いずれもヒットしません。
VLOOKUPやHLOOKUP、MATCH関数も同様です。
SORT関数やUNIQUE関数も 表示形式の影響は受けません。
上は各セル毎にカスタム数値形式で ZZZやFFFといった文字列を数値の左に付加していますが、その影響を受けることなく並び替えや重複排除されているのがわかります。
QUERY関数の order by による並び替えの場合は、表示形式自体がデータの先頭のものに書き換えられてしまいました。
これは QUERY関数が 列の型を判別して処理する関数である為かと思います。
とりあえずは、文字列系関数以外は 基本的には 表示形式の影響を受けないと思ってよいでしょう。
IMPORTRANGEは参照しているセル範囲の表示形式と連動する
IMPORTRANGE関数は 他のスプレッドシートを同期させるのに便利な関数ですが、基本的にはセル内の数値や文字列のみを取得し、セルや文字の色、太字などのフォント設定は取得できません。
しかし、意外と表示形式は連動の対象になっているようで、元シートの表示形式を変えると、IMPORTRANGE関数で出力した結果も連動して 表示が変わります。
それに伴い IMPORTRANGEで出力した範囲から LEN関数で取得した文字数の方も変化しているのがわかりますね。
さすがに表示形式で設定した文字の色は 連動しませんし、IMPORTRANGEの結果を出力しているセル範囲の表示形式を直接設定した場合は、そちらが優先されます。
IMPORTRANGEで表示形式も同期するのは面白いですね。
ちなみにIMPORTRANGEは名前付き範囲やテーブルと非常に相性がよく
このような書き方ができるのでおススメです。
表示形式の影響を受ける 機能
関数ではないですが、表示形式の影響を受ける機能も幾つかあります。
こちらも見ていきましょう。
検索と置換は表示形式の影響を受ける
表示形式の影響を受ける 代表的なものは「検索」機能です。
上のような Ctrl + Fで発動できる簡易検索、
Ctrl + H の検索と置換、どちらも 表示形式で付加した 文字や 数字を検索できます。
さらに
表示形式で付加している文字「年」に対して置換まで出来ちゃいます。
ただし、このように 日付データが文字列化してしまうことがあるので注意。
〇年〇月〇日 表示だと 文字列化してしまいますが、 yyyy/MM/dd 表示の日付であれば、文字列化することなく 2024 を2025 に一括変更なんてことも可能です。
日付は表示形式が違うと検索と置換でヒットしないことも
Excelの場合、表示形式だけが違う同じ日付が入ったセルが幾つかあった場合、それらは数式バーで見ると いずれも同じ(上の場合は 2024/12/7) となっており、検索で全て見つけることができます。
しかしGoogleスプレッドシートの場合、日付の型として判断される表示形式だった場合は、数式バー上もその日付表示となります。
2024年12月7日(土) という曜日入りだけは 数式バー上は 2024/12/07 となっていますが、それ以外は セルの表示と数式バーの表示が一緒なのがわかりますね。
これが検索にも影響します。つまり 2024/12/7で 検索しても
このように 2024/12/7 という0無しの表示形式になっているセルしかヒットせず、同じ日付であるはずの 2024/12/07 や 2024-12-07、2024年12月7日、これらの表示形式の日付を見つけることが出来ません。
これがちょっと厄介だったりします。
検索オプションを「数式内」にチェックすることで、数式バーの表示が同じものであれば 表示が違っても検索できます。
2024/12/07 で「数式内も検索」とすることで、数式バー上は 2024/12/07となっている 2024年12月7日(土) も検索にヒットしてるのがわかります。
しかし、数式バー上の表示が違う 2024/12/7 や 2024-12-07、2024年12月7日など、これらを検索でヒットさせることが出来ません。
これが結構困ります。
良い解決策が見当たらないので、いい方法を発見したら noteで紹介したいと思います。
「テキストを列に分割」も表示形式の影響を受ける
また「テキストを列に分割」という機能も 表示形式で付加された 文字を区切りとして指定することが出来ます。
たとえば 日付データを / で分割すると
こんな感じで SPLIT関数と同じようなことが出来ます。
ちなみに日付の /で区切る方法は Excelでも同様に可能です。
検索と置換は 文字列の表示形式にも効果がある
ちなみに FINDやSUBSTITUTE、SPLITなどの 文字列関数で扱えるのは数値の表示形式で付加した結果のみですが、検索と置換 機能は 文字列の表示形式も対象となります。
@様 の表示形式を適用した上記の A2:A5が 簡易検索で「様」にヒットしてるのがわかりますね。
これは Excelとは違う点です。
ただし 文字列の表示形式で付加された文字を置換する場合は注意が必要で、
このように様を殿に置換したつもりが
山田様 → 山田殿様
となってしますw
これは、山田様の「@様」 という表示形式で付加した「様」は 置換で 「殿」に出来たけど、「@様」とう表示形式は変わっていないので置換後の「山田殿」に「様」が付いてしまう為です。
表示形式の方を直さないと意味がないですね。
表示形式をそぎ落とす 最強メイク落とし関数とは?
Googleスプレッドシートにおいて 表示形式(特に日付や数値の表示形式)が 検索や置換といった機能、そして 文字列系関数の結果に多大な影響を与えることを 紹介してきました。
じゃあ、表示形式をそぎ落とした本当の姿、言うなれば メイク落としでクレンジングした すっぴん の値で 関数の結果を得たい場合はどうすれば良いでしょうか?
※ちなみに データを綺麗にすることを本当にクレンジングという言葉で表現します
余計な表示形式をそぎ落とす TO_PURE_NUMBER関数
表示形式によって付加されたものをそぎ落す、最強メイク落とし関数と言える関数が TO_PURE_NUMBER関数です。
これはExcelには無い関数で、説明にも
とあります。
とりあえず試してみましょう。
このように 表示形式で付加された余計な文字や 小数点の表示設定、通貨の¥マークや 3桁区切りのカンマは削除され、日付はどんな表示形式でも全てシリアル値に変換され、全て ピュアな数値になってますね!
さらにこの TO_PURE_NUMBER関数は ARRAYFORMULAと組み合わせて使えます。
空白は空白のまま返るんで、空白セルを気にせず
一気にこんな式で処理できちゃいます。
TO_PURE_NUMBER関数は 文字列の表示形式もそぎ落とせる
NUMBERって付くと数値にしか使えないように感じますが、文字列に対してもこの関数は有効です。
@様 の表示形式で付加した 様 が削除されて セルの本来の中身になってますね。
文字列と数値が混在したセル、数字のみで構成された文字列 はそのまま勝手に数値に変換されることなく 00156という 文字列のまま出力されています。
さらにチェックボックスは FALSE、TRUEに エラーはエラーのまま、チップに関しても問題なく処理できています。
TO_PURE_NUMBER関数は、全ての表示形式を過ぎ落とす 最強メイク落としすっぴん関数と言ってよいんじゃないでしょうかw
VALUE関数、N関数との比較
TO_PURE_NUMBER関数は聞きなれないって人は、ExcelにもあるVALUE関数やN関数を使って 数値化する方法はどうだろ?と考えるかもしれません。
どちらも 数値化する関数ではありますが
このように VALUE関数は表示形式で文字を付加したものの数値化や 曜日入りの日付のシリアル値化ができません。
一方 N関数の方は数値、日付の表示形式には全て対応出来てますが、どちらも空白を 0としてしまうのが悩ましいです。
文字列への対応はどちらもダメです。
VALUE関数の方は 文字列を対象とした場合は #VALUE! エラーとなりますし、N関数の方は文字列を0にしてしまいます。
N関数は 00156のような 数字で構成された文字列も 文字列扱いで 0にしちゃうんですよね。
表示形式をそぎ落とすという使い方だと、VLUE関数やN関数ではなく TO_PURE_NUMBER関数が 最適であるとわかりますね。
表示形式を加味せず、真の値(数値)の文字数を取得する
というわけで Googleスプレッドシートにおいて、表示形式を加味せずに 真の値(数値)、日付ならシリアル値を対象として LEN関数で文字数を取得したい場合は
このような式を使います。
ARRAYFORMULAを組み合わせて複数セルを一気に処理する場合は
こんな式になります。
直接LEN関数を使った式と比較すると 結果の数値が違っているのがわかりますね。
LEFT、MID、RIGHT関数を使う際に、真の値を対象としたい時も同様で、 TO_PURE_NUMBER関数 と組み合わせればOKです!
GAS で 表示形式を 考慮して値を取得する
表示形式を適用した見た目を GAS(GoogleAppsScript)で取得する方法もにも触れておきましょう。
セルの見た目のままを取得する getDisplayValue()
GASで スプレッドシートの値を取得する際、通常は Rangeクラスの getValue()、getValues() を使います。
たとえば、とりあえず開いて選択しているセル範囲の値を取得して ログに書き出したい場合
function displayFormatTest1() {
const sheet = SpreadsheetApp.getActiveSheet();
const range = sheet.getActiveRange();
const values = range.getValues();
console.log(values);
}
こんなコードを書くかと思いますが、これで表示形式が適用された(または日付を含む)セル範囲を取得した場合
こんな結果となります。
数値は表示形式で色々付加する前の ピュアな数値として取得できてますね。これは TO_PURE_NUMBER関数を使った時と同じです。
一方、日付はいずれの表示形式であっても 中身の日付が 2024/12/07 のものは
と返ってきます。
これは セルに日付データが入っていた場合、GAS側で自動で 日付の型(Dateオブジェクト)であると判断する為です。
処理によってはこの方が都合がいい場合もあるんですが、単純にメールに転記したいとか ドキュメントに出力したい、他の文字と日付を組み合わせて文章を作りたい、なんて時は ちょっと面倒なことも。
日付表示や 表示形式を付加した セル上の見た目通りの値を取得したい!って時の為の メソッドが別に用意されています。
それが getDisplayValue()、getDisplayValues() です。
こちらを実行するコードを
function displayFormatTest2() {
const sheet = SpreadsheetApp.getActiveSheet();
const range = sheet.getActiveRange();
const displayValues = range.getDisplayValues();
console.log(displayValues);
}
こんな感じで用意して実行してみると
このようにセルの見た目通りの 値や日付を取得できます。※やはりセル埋めの表示形式の 繰り返し文字(画像だと /)は1つとして扱われる
ただし、結果は全て 文字列 となっている点に注意が必要です。
[ [ 'UUU1' ],
[ 'WWW4' ],
[ '5.00 ' ],
[ '16.44 ' ],
[ '(8.00)' ],
[ '¥199,800' ],
[ '/91' ],
[ '2024/12/07' ],
[ '2024/12/7' ],
[ '2024-12-07' ],
[ '2024年12月7日' ],
[ '2024年12月7日(土)' ] ]
それでも GASでセル上の見た目のまま値を取得したい!って時もあるんで、便利なメソッドですよね。
getDisplayValue()、getDisplayValues() は、シート関数の TO_TEXT関数のような処理が出来るメソッドと言えます!
これでGASからも 表示形式を付加した結果をそのまま使いたい時、表示形式なしで真の値を使いたい時、どちらも対応できますね!
Googleスプレッドシートの表示形式 まとめ
最後に今回紹介した Googleスプレッドシートの「表示形式」の扱いについてまとめです。
マニアックなネタなんでネット上に情報はあまり無いですが、「いきなり答える備忘録」さんが 以前(2023年9月)に取り上げてましたw さすがですね。
Googleスプレッドシートで 文字列系関数を 日付や表示形式を設定した数値に対して使う場合は Excelとは勝手が違うってことに注意しましょう!
次回のネタは未定です・・・。年末は忙しいんで軽めのネタになるかも。