【ITニュース解説】A Real .xlsx With Working Formulas in Plain JavaScript, No Library

このニュース記事は、JavaScriptというプログラミング言語を使って、Excelのファイル形式である.xlsxを、特別なライブラリに頼らずに直接作成した開発者の取り組みを紹介している。システムエンジニアを目指す初心者にとって、ファイル形式の内部構造の理解や、既存のツールを使わずに問題を解決する発想は非常に役立つ学びとなるだろう。

開発者がこの挑戦を始めたのは、自身の運営するタイムカード計算サイトで、集計結果をExcelで使える形式で提供したいというニーズがあったからだ。当初はCSV形式でのダウンロードを提供していたが、Excelで開くと「41時間30分」といった合計時間が「17:30」と誤って表示されたり、日付が正しく認識されないなど、多くの問題が発生した。CSVはデータ自体は渡せるが、Excelのセルの書式や計算式を正確に表現するには不向きだったのだ。そこで開発者は、日付や時間が適切に表示され、さらにセルに「=SUM()」のような実際の計算式が埋め込まれた「本物の.xlsxファイル」を提供することを目標とした。これにより、もし入力ミスがあってもExcel上で数値を修正すれば合計が自動で更新されるという、ユーザーにとっての利便性も向上する。

通常、このような複雑なファイル形式を扱う場合は、専用のライブラリを用いるのが一般的である。しかし開発者は、自身のサイトのJavaScriptコードが約80KBと軽量だったため、何倍ものサイズになる可能性のあるライブラリを導入したくなかった。その代わりに、自力で.xlsxファイルを生成するコードをわずか177行、9KBで書き上げたという。これは、必要最小限の機能に絞り込み、コードの肥大化を防ぐという、ソフトウェア開発における重要な視点を示している。

.xlsxファイルは、その実態が「zipファイル」であることを理解することが、手動作成の鍵となる。ユーザーが普段目にする.xlsxファイルは、実は拡張子を.zipに変えて解凍すると、その中に複数のXMLファイルが格納されているのがわかる。これらXMLファイルには、ワークブックの全体像やシートの構成、セルのスタイル、そして実際のデータが記述されている。開発者は、これらのXMLファイルをJavaScriptで生成し、それらを「圧縮せずに」一つのzipファイルとしてまとめることで.xlsxファイルを作成した。圧縮処理が不要だったため、zipファイルの作成に必要なCRC-32チェックサムの計算や、ファイルヘッダーの記述などもJavaScriptで自作している。また、生成されるファイルのタイムスタンプを固定することで、同じ入力からは常に全く同じ内容のファイルが作られるようにし、テストの効率を大幅に向上させる工夫も凝らした。

Excelのセルにデータを書き込む際にもいくつかの工夫がある。文字列データは「インライン文字列」という形式でセル内に直接書き込むことで、より複雑な「共有文字列テーブル」を管理する手間を省いた。小規模なファイルではこの方法で十分だ。特に重要なのは、計算式を含むセルだ。例えば、合計時間を表示するセルには、Excelが後で計算する「=SUM(E2:E8)」のような計算式（<f>タグ）だけでなく、その計算結果を示す「キャッシュ値」（<v>タグ）も一緒に書き込んでいる。これにより、Excelがファイルを開いた瞬間や、計算機能を持たないプレビューでファイルを表示した際にも、正しい合計値がすぐに表示され、ユーザーが空白や不正な値を見るのを防ぐことができる。

Excelにおける時間と日付の扱いは、この開発者が直面した具体的な「落とし穴」として詳しく解説されている。Excelは時間を「1日を1.0とした小数値」として内部的に管理しているが、表示形式に注意が必要だ。一般的なh:mm形式では、24時間を超える時間（例えば41時間30分）は「17:30」と表示されてしまう。これは、表示形式が時計のように24時間で一周してしまうためだ。この問題を解決するためには、[h]:mmという特殊なカスタム書式を使用する必要がある。角括弧で囲まれた[h]は、時間を24時間でラップせずに総時間として表示する指示となり、正しく「41:30」と表示されるようになる。日付についても、Excelは「1899年12月30日を基準日とした通し番号」で日付を扱っている。これは、過去の表計算ソフトのバグを引き継いだ結果だが、JavaScriptで日付をExcel形式に変換する際には、この基準日からの日数を正確に計算し、オフセットを加える必要がある。

開発の最終段階で直面した「#####」という表示のバグは、システムエンジニアを目指す初心者にとって特に重要な教訓となる。生成された.xlsxファイルは、内部的な整合性に関する全てのテストをクリアしていたにもかかわらず、実際のExcelで開くと、日付を表示する一部のセルが「#####」と表示されてしまったのだ。これはエラーを示すものではなく、単に「この列幅では、この日付の文字列を全て表示しきれません」というExcelからのメッセージだった。このバグは、テストがファイルの内部的な「正しさ」は検証しても、実際のユーザーがファイルを使う際の「表示」や「見やすさ」まではカバーできていなかったことを浮き彫りにした。解決策は、該当する列の幅を広げることだった。この経験から開発者は、「ファイル形式が技術的に正しいこと」と「人が実際にそのファイルを問題なく利用できること」は異なるという教訓を得た。そのため、最終的な確認として「実際の環境で、実際のExcelでファイルを開いてみる」ことの重要性を強調している。

このような手動での.xlsxファイル生成は、グラフの描画、複数のシートにわたる複雑なデータ処理、大量の行の管理、または既存の.xlsxファイルの読み込みといった、高度な機能が必要な場合には適していない。そうした複雑なケースでは、機能豊富で安定したライブラリを利用する方が賢明だ。しかし、今回のように「ユーザーが入力した少量のデータを、整理されたシンプルなスプレッドシートとして提供する」という特定の目的においては、手書きのアプローチは非常に有効だ。コードは小さく、処理は高速で、開発者自身がファイルの隅々までその構造を理解できるという大きなメリットがある。このニュース記事は、問題解決のための創造的な思考、ファイルフォーマットに関する深い知識、そしてユーザー体験を重視したテストの重要性といった、システムエンジニアに求められる多岐にわたるスキルを学ぶ良い機会となるだろう。