MENU

テキストファイル形式の歴史：物理的制約から普遍的標準へ

画像クリックでインフォグラフィックサイトに遷移します

第1部：黎明期とデータ表現の基礎

1.1. 初期コンピュータにおける文字の表現：パンチカードから電気信号へ

テキストデータの歴史は、電子的な符号化よりも前に、物理的な記録媒体から始まります。初期のコンピュータシステムでは、パンチカードが主要なデータ入力および記録媒体として用いられていました 1。このカードは一般的に80桁の固定長を持ち、各桁に数字、文字、特殊記号などのデータが記録されました 1。この物理的な制約は、その後のデジタルテキスト表現の設計思想に深い影響を与えました。すなわち、1文字を特定の「バイト数」で表現するという「固定長」の概念は、パンチカードの「桁」という物理的な制約から引き継がれたものであったと考えられます 1。

この固定長という設計は、初期のプログラミングにおいて、データの可読性を高め、エラーを検出しやすくするという利点がありました 2。しかし、その一方で、複雑なデータ構造やロジックを表現する上での柔軟性を制限する側面も持ち合わせていました 2。パンチカードから磁気記録、そして電気信号へと技術が移行する中で、この「1文字＝1単位」という設計思想は、論理的なデータ表現の基盤となり、後の文字コードの進化を方向づける重要な出発点となりました。この固定長から可変長へと至る変遷は、技術が物理的な制約から解放されていく過程を象徴しています。

1.2. シングルバイト文字コードの確立：ASCIIとEBCDIC

パンチカード時代を経て、コンピュータが文字を電気信号として内部で扱うようになると、その表現方法を標準化する必要が生じました。この時期に登場したのが、ASCIIとEBCDICという二つの主要なシングルバイト文字コードです。

**ASCII (American Standard Code for Information Interchange)**は、7ビットで128種類の文字を表現する規格として、1963年に誕生しました 3。これは世界初の標準的な文字コードとされており、主にパーソナルコンピュータやUNIXシステムで広く普及しました 5。一方、**EBCDIC (Extended Binary Coded Decimal Interchange Code)**は、IBMが独自に開発した8ビット（256種類）の文字コードであり、主にIBMのメインフレームシステムで長年にわたり使用されました 5。

これらの文字コードは、技術的にも商業的にも対照的な道を歩みました。ASCIIはISO 646という国際規格の基礎となり、オープンなシステムの発展に寄与したのに対し 4、EBCDICは特定のベンダーのエコシステム内で強力な地位を築き上げました 5。この初期の分断は、その後の文字コードの歴史全体を支配する、「標準化」と「ベンダーロックイン」という二つの対立軸の始まりでした。

1.3. 異なるエンコーディング間の課題：ソート順と互換性の問題

ASCIIとEBCDICは、文字をバイナリデータとして表現するためのコード値の割り当てが根本的に異なっていました 8。この違いは、単にデータが異なる形式で保存されるという問題に留まらず、異なるシステム間でデータを交換する際の互換性や、データの処理ロジックそのものに影響を及ぼしました 8。

最も顕著な問題の一つは、文字列のソート結果が異なってしまうことでした。ASCII規格では、大文字のアルファベットが小文字よりも先にソートされますが、EBCDIC規格ではその順序が逆になります 10。これは、文字のコード値の大小関係がシステムごとに異なるためであり、単純なデータ変換では解決できない、より深い互換性の問題を示唆していました 8。

以下の表は、この二つの文字コード体系の主要な違いを整理したものです。

特性ASCIIEBCDIC
ビット長7ビット（128文字） 38ビット（256文字） 5
主な使用システムPC、UNIX 5IBMメインフレーム 5
アルファベットソート順大文字が小文字より先にソートされる 10小文字が全て大文字より先にソートされる 10

この表が示すように、異なる文字コードが共存する状況では、データ交換や処理において、見えないところで根本的な問題が発生する可能性がありました。この事実は、「単一の普遍的な標準」の必要性を強く浮き彫りにするものでした。

第2部：マルチバイトの時代と日本の特殊な進化

2.1. 漢字処理の必要性とJIS漢字コードの制定

ASCIIのようなシングルバイト文字コードは、文字数の少ない欧米言語には適していましたが、日本語や中国語などの漢字を扱うには文字数が圧倒的に不足していました 11。この課題を解決するため、日本では複数のバイトを組み合わせて1文字を表現する「マルチバイト文字コード」の導入が不可避となりました。

漢字コードの標準化に向けた研究は1970年代から始まりましたが、その過程は容易ではありませんでした 4。公的な標準を定める前に、「これで全部」と言えるような統一された漢字の一覧が存在しなかったため、まず漢字のリストアップから始める必要があったのです 4。このような文化的・社会的な課題を経て、1978年にようやくJIS C 6226（後のJIS X 0208）という公的な規格が制定されました 12。この規格は、行政情報処理用基本漢字や学術団体の研究成果を基に、合計6,802文字を収録し、日本語の情報交換の基礎を築きました 13。

JIS X 0208は、その後も複数回にわたる改訂（1983年、1990年、1997年、2012年）を経て進化しました 13。特に、JIS83やJIS90の改訂では、一部の文字の字形が変更されており、これがWindows OSにおけるJIS90とJIS2004の字体問題（例：しんにょうの点の数）として、現代にも影響を残しています 14。

2.2. 日本語文字コードの混迷：Shift_JIS、EUC-JP、そして機種依存文字

JIS X 0208は、あくまで「文字集合」を定めたものであり、それをコンピュータが処理できるバイト列に変換する「符号化方式」は複数存在しました。日本で特に広く使われたのは、以下の二つの方式です。

  • Shift_JIS: 1バイトのASCII文字と2バイトのJIS漢字コードを混在させる可変長エンコーディング方式です 16。この方式は、ASCIIとの互換性を保ちつつ日本語を表現できる利点がありましたが、バイト数が可変であるため、文字列処理のロジックが複雑になるというデメリットがありました 18。
  • EUC-JP: 1バイト文字と2バイト文字を明確に区別できる構造を持っており、主にUNIX系のシステムで利用されました 19。

この二つの主要な文字コードの存在は、日本国内でのシステム間における互換性を損なう主要な要因となりました 20。さらに、公的な標準であるJISが存在したにもかかわらず、多くのベンダーが独自の拡張文字（機種依存文字）を導入しました 4。例えば、Windows環境ではJIS X 0208に独自の文字を追加したWindows-31J（MS932）が事実上の標準となり、①や②といった丸囲み数字、旧字体などが含まれました 21。これらの機種依存文字は、異なるOSやアプリケーションで正しく表示されず、「文字化け」の主要な原因となりました 18。

2.3. 「文字化け」の構造とベンダーごとの拡張

文字化けとは、ファイルを保存した際の文字コードと、読み込む際の文字コードが異なる場合に、意味不明な文字列や記号に置き換わる現象です 24。この問題は、特にベンダー独自の拡張文字が乱立した日本の状況で深刻化しました。

Windows-31Jは、JIS X 0208の文字集合に、NECやIBMが選定した特殊文字・拡張文字を独自に追加したものでした 23。これらの拡張文字の存在は、後に制定された新しい標準（JIS X 0213）と衝突する可能性をはらんでいました。特に、IBM拡張文字が配置されていた領域は、新しい規格で別の文字が割り当てられていたため、互換性の問題が懸念されました 23。この複雑な状況は、文字コードの標準化が、市場のニーズに追いつかない速度で進み、その結果として部分的な解決策（ベンダー拡張）が乱立するという、技術史における典型的なパターンを示しています。

以下の表は、日本語の主要な文字コード体系を比較したものです。

特性JIS X 0208Shift_JISEUC-JPWindows-31J (MS932)
役割文字集合の規格 13符号化方式 19符号化方式 19Shift_JISの拡張 23
構造6,802文字の漢字を定義 13JISを可変長で符号化 16JISを可変長で符号化 19JIS + ベンダー拡張文字 23
主な使用環境標準規格 4Windows (事実上の標準) 18UNIX系 12Windows 23
特徴漢字の標準化 4ASCII互換だが文字列処理が複雑 181/2バイトの区別が明確 19機種依存文字を含む 21

2.4. リッチテキストフォーマット（RTF）：フォーマット情報の付加

文字コードが文字そのものの表現に注力する一方で、テキストに装飾やレイアウト情報を付加するという別のニーズも高まっていました。この課題への回答の一つが、マイクロソフトが1987年に開発したRich Text Format (RTF) です 26。RTFは、テキストデータにフォント、サイズ、色、段落スタイルといった書式情報を付加することができ、多くのワープロソフトで読み書き可能なクロスプラットフォームな文書フォーマットとして普及しました 26。

RTFの歴史は、文字コードが文字の「同一性」という問題に取り組んでいたのとほぼ同時期に、より高次のレイヤーである「文字の見た目」という課題に挑んでいたことを示しています。この二つの流れは、最終的にユニコードが文字の統一的な定義を提供し、CSSやXMLといった技術がフォーマットを分離する、現代のウェブ標準へと収束していく過程を象徴しています。

第3部：普遍的文字集合の探求：ユニコードの誕生

3.1. 国際的な文字コード標準の乱立とユニコードの構想

1980年代後半、各国の独自文字コード標準が乱立する状況は、グローバルなデータ交換にとって大きな障害となっていました 4。欧米でもISO 8859シリーズのように言語ごとに異なる文字コードが使われ、多言語が混在する文書の作成や、国境を越えたネットワーク通信は非常に困難でした 3。

このような状況を背景に、「全世界の文字を統一的に扱える単一の文字コード」という構想が生まれ、1980年代後半からユニコードの検討が始まりました 16。この構想は、単なる技術的な課題解決ではなく、グローバル化が進む社会からの必然的な要請でした。

3.2. ユニコードとISO/IEC 10646：標準化の歩みと初期の妥協点

ユニコードは、非営利団体であるユニコードコンソーシアム（The Unicode Consortium）によって開発が進められました 27。同時期に、国際標準化機構（ISO）と国際電気標準会議（IEC）も、同様の目的を持つ公的な国際標準「ISO/IEC 10646」の策定を進めていました 29。当初、両者は別々に進行していましたが、後に協議を重ねて文字集合を統一することで合意しました 4。この合意により、ユニコードはISO/IEC 10646と同一の内容を持つ標準として確立され、相互に同期して更新されるようになりました 29。

この統合の経緯は、IT業界をリードする企業が主導する「デファクトスタンダード」と、公的な手続きを経て策定される「デジュリスタンダード」が、最終的に歩み寄ることで普遍的な標準が形成された、歴史的に重要な出来事として位置づけられます。

3.3. サロゲートペアの導入：文字空間の劇的な拡張

ユニコードの初期バージョンは、2バイト（16ビット）固定長の文字コード（UCS-2）として設計されていました 16。この方式では、理論上65,536文字しか表現できず、世界中のあらゆる文字を網羅するには不十分であることがすぐに判明しました 31。

この問題を解決するために導入されたのが「サロゲートペア」という仕組みです 32。これは、16ビットコードの未使用領域から2つのコードを組み合わせることで、本来の16ビットの範囲外である拡張領域（U+10000以降）の文字を表現する手法です 32。この導入により、ユニコードは100万文字以上の文字空間を獲得し、絵文字や歴史的な文字など、将来の文字追加にも柔軟に対応できるようになりました 32。この技術的選択は、固定長という設計上の制約を克服し、文字コードの適用範囲を飛躍的に拡大させました。

第4部：ユニコードの実践とUTFエンコーディング

4.1. 文字集合と符号化方式：ユニコードとUTFの違い

ユニコードは、世界中のすべての文字に固有の番号（コードポイント）を割り当てる「符号化文字集合」の規格です 34。一方、UTF（Unicode Transformation Format）は、そのコードポイントをコンピュータが処理可能なバイト列に変換するための「文字符号化方式」です 34。この二層構造は、文字コードの歴史における重要な転換点でした。初期の文字コードが文字集合と符号化方式を一体として扱っていたのに対し、ユニコードはこの二つを分離することで、文字の定義とデータの表現方法を独立させ、互換性の問題を劇的に改善しました。

4.2. UTF-8：可変長エンコーディングの仕組みとインターネットの標準

現代において最も広く利用されている文字符号化方式はUTF-8です 7。その成功は、いくつかの技術的特性に起因します。

  • 可変長エンコーディング: UTF-8は、文字によって1〜4バイトの可変長で表現されます 17。ASCII文字は1バイト、日本語の漢字は通常3バイト、絵文字は4バイトで表現されます 17。
  • ASCII互換性: UTF-8の最大の強みは、ASCIIと完全な互換性を持つことです 36。ASCIIの文字はUTF-8でも同じ1バイトのコードで表現されるため、既存のASCIIベースのシステムでも問題なく扱うことができました 36。この後方互換性を持つ設計は、インターネットが既存のインフラを破壊することなく多言語環境へとスムーズに移行する上で、極めて重要な役割を果たしました 7。
  • 標準化: 1998年、IETF（Internet Engineering Task Force）は、インターネット標準作業における文字セットとしてUTF-8を正式に採用しました 7。この決定は、UTF-8をウェブ開発やデータ交換における事実上の世界標準へと押し上げました 7。

4.3. UTF-16とUTF-32：それぞれの特性とユースケース

ユニコードの符号化方式には、UTF-8以外にもUTF-16とUTF-32が存在し、それぞれ異なる特性を持っています 17。

  • UTF-16: 基本的には2バイト（16ビット）の固定長ですが、サロゲートペアの導入により、実際には2バイトまたは4バイトの可変長となっています 34。文字数が比較的多い日本語などを扱う場合、UTF-8よりもデータサイズが小さくなることがあります 34。
  • UTF-32: 常に4バイト（32ビット）の固定長で文字を表現します 17。これにより、文字のアクセスが非常に高速になる利点がありますが、メモリ消費量が大きいというデメリットがあります 17。そのため、主に内部処理用として使用され、ファイル形式として利用されることは稀です 17。

UTF-8がインターネットの標準である一方、UTF-16はWindowsなどの特定のOSで広く使われていた歴史があります 41。これは、文字コードがプラットフォームや用途に応じて使い分けられている実態を物語っており、インターネットのような多様なシステムが混在する環境では後方互換性のあるUTF-8が、特定の環境内で完結するシステムでは処理効率を重視したUTF-16が選ばれる傾向がありました。

4.4. バイトオーダーマーク（BOM）の役割と問題点

バイトオーダーマーク（BOM）は、UTF-16やUTF-32のようなマルチバイト文字コードにおいて、バイトの並び順（エンディアン）を示すために、ファイルの先頭に付加される特殊なバイト列です 34。

UTF-8はバイトの並び順が一意に定まっているため、BOMは必須ではありません 40。しかし、かつての一部のソフトウェア（特に旧版のMicrosoft製品）は、BOMを「UTF-8でエンコードされたファイル」を示す署名として扱っていました 40。このため、BOMを想定していないソフトウェア（特にLinux系のツールやプログラミング言語）では、ファイルの先頭にあるBOMが原因で、パーサーが正常に動作しないという問題が頻発しました 40。現在では、UTF-8ではBOMを付けないことが推奨されています 40。

以下の表は、主要なUTFエンコーディング方式を比較したものです。

特性UTF-8UTF-16UTF-32
バイト長1〜4バイト可変 172または4バイト可変 394バイト固定 39
ASCII互換性互換性あり 36互換性なし 17互換性なし 17
BOMの必要性任意（推奨されない） 40必須（エンディアン指定） 41必須（エンディアン指定） 41
主なユースケースインターネット、ウェブ開発 36特定OSの内部処理 41内部処理、高速アクセス 17

第5部：結論と今後の展望

5.1. 現代における文字化け問題の終焉

ユニコード、とりわけUTF-8の普及は、かつて日常的に発生していた「文字化け」問題を劇的に減少させました 36。多くのOSやアプリケーションがUTF-8を標準として採用しているため、多言語のデータ交換が格段にスムーズになりました 36。これは、文字コードの歴史が、ベンダーごとの閉じた世界から、普遍的な標準を基盤としたオープンな世界へと移行したことの明確な証左です。

しかし、文字化けの問題が完全に消滅したわけではありません。現代の文字化けの主な原因は、もはや標準規格の不備ではなく、レガシーな業務システムがShift_JISなどの古い文字コードに依存している場合や 18、人為的な設定ミス 25、あるいはデータの破損に起因する場合がほとんどです 24。文字コードの歴史は、新しい標準への移行期間における「負の遺産」が、依然として影響を与え続けているという事実を物語っています。

5.2. テキストファイル形式の歴史が示す技術的教訓

パンチカードの固定長という物理的制約から始まり、ASCIIとEBCDICの分断、そして日本のマルチバイト文字コードの混迷を経て、ユニコードとUTF-8が世界標準を確立するまでの歴史は、技術の進化が単線的ではないことを示唆しています。この変遷から、いくつかの重要な技術的教訓を導き出すことができます。

第一に、後方互換性の力です。UTF-8がこれほどまでに普及した最大の要因は、既存のASCIIシステムと互換性があったことです 36。既存の膨大な資産との調和を考慮した設計は、新しい技術の普及を加速させる上で不可欠な要素です。

第二に、標準化の重要性です。ベンダー独自の拡張がもたらした互換性の問題は、統一された標準が技術的なエコシステム全体の健全性を保つ上でいかに重要であるかを雄弁に物語っています。ユニコードとISO/IEC 10646の統合は、その理想的な成功例です 29。

そして第三に、固定長から可変長への脱却です。パンチカードの桁という物理的制約から始まった固定長の概念は、ユニコードのサロゲートペアやUTF-8の可変長という設計思想の変革によって克服されました 17。この歴史は、今日の常識が、明日の技術革新によっていかに問い直されるかを示唆しています。テキストファイル形式の歴史は、単なる文字の記録ではなく、データ表現の柔軟性を追求し続けた人類の試みの記録であり、この探求は絵文字や異体字セレクタといった新たな表現形式の出現によって、今もなお続いています 15。

引用文献

  1. パンチカードシステム – Wikipedia https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%B3%E3%83%81%E3%82%AB%E3%83%BC%E3%83%89%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0
  2. パンチカードとは？意味をわかりやすく簡単に解説 – trends https://trends.codecamp.jp/blogs/media/terminology452
  3. 文字コード http://ss.sguc.ac.jp/kataoka/basic/charcode.html
  4. 第１２章 文字コード標準 （日本語文字の符号化） – 日本規格協会 https://www.jsa.or.jp/datas/media/10000/md_2466.pdf
  5. EBCDICとは？意味をわかりやすく簡単に解説 – xexeq.jp https://xexeq.jp/blogs/media/it-glossary586
  6. 文字コードの基礎と役割 ~ 種類と特徴：テキストエンコーディングの鍵！【備忘録-基本情報技術者試験対策 #17-1】 https://nlab-notebook.com/entry/character-code-types-and-features
  7. UTF-8 – Wikipedia https://en.wikipedia.org/wiki/UTF-8
  8. ASCII SBCS 文字と EBCDIC SBCS 文字の違いの処理 – IBM https://www.ibm.com/docs/ja/cobol-linux-x86/1.1.0?topic=fdcbdr-handling-differences-in-ascii-sbcs-ebcdic-sbcs-characters
  9. EBCDIC および ASCII 照合シーケンスにおけるソート順の相違 – IBM https://www.ibm.com/docs/ja/db2/11.5.x?topic=sequences-ebcdic-ascii-collating-sequence-sort-order
  10. 5 言語ソートと文字列検索 https://docs.oracle.com/cd/E16338_01/server.112/b56307/ch5lingsort.htm
  11. コンピュータ入門（鈴木） https://edu.isc.chubu.ac.jp/hsuzuki/iip/2021-nyumon/act7/7-4.html
  12. テキストファイルとは – 京都の制作会社M2 【有限会社エム・ツー】 https://www.emtwo.co.jp/column/textfile.html
  13. JIS X 0208 – Wikipedia https://ja.wikipedia.org/wiki/JIS_X_0208
  14. JIS X 0208およびJIS X 0213の字形・字体の変更点 – CyberLibrarian – asahi-net.or.jp https://www.asahi-net.or.jp/~ax2s-kmtn/ref/jisrev.html
  15. Windows と日本語のテキストについて – Windows Blog for Japan https://blogs.windows.com/japan/2020/02/20/about-windows-and-japanese-text/
  16. Unicodeとは？ その歴史と進化、開発者向け基礎知識 – Build Insider https://www.buildinsider.net/language/csharpunicode/01
  17. UTF-8、ASCII、文字エンコーディングに関連する質問一覧 – Zenn https://zenn.dev/m_nakano_teppei/articles/0f4268efdfb19b
  18. 文字コードの基礎知識と選び方：ANSI, UTF-8などの違いを徹底解説 https://hissori.com/character-encoding/
  19. 文字コード（UTF-8,Shift_JIS,EUC-JP,ISO-2022-JP）についての俺的まとめ – 今日もスミマセン。 https://snaka72.hatenadiary.org/entry/20100710/SUMMARY_ABOUT_JAPANESE_CHARACTER_CODE
  20. 【備忘録】文字コードって何？基本と使い分けガイド – エヌエスアイ フリーク https://nsi-freak.com/character-code-guide/
  21. 環境依存文字・機種依存文字に関する基礎知識。文字化けが起きる原因は？ – Blastmail https://blastmail.jp/blog/mail/environment-dependent-character
  22. 他のPCではちゃんと表示されない!?機種依存文字 – モルガンデータシステム https://morgan.co.jp/dataentry/input2-4/
  23. JIS X 0208と0213と機種依存文字 – 弘前学院聖愛中学高等学校 https://www.seiai.ed.jp/sys/text/csd/cf14/c14b050.html
  24. 文字化けとは？原因と対策 – ITとPCに関連する用語の解説 https://it-notes.stylemap.co.jp/programs/text-garbling%E2%86%92-causes-and-solutions/
  25. 文字化けの変換＆防止法3選｜原因からわかりやすく解説 – 株式会社ノベルティ https://noveltyinc.jp/media/mojibake
  26. Rich Text Format – Wikipedia https://ja.wikipedia.org/wiki/Rich_Text_Format
  27. ユニコードコンソーシアム – Wikipedia https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%8B%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B7%E3%82%A2%E3%83%A0
  28. Unicode Consortium https://www.unicode.org/consortium/
  29. ISO/IEC 10646 – JIS X 0213 Wiki https://x0213.org/wiki/wiki.cgi?page=ISO%2FIEC+10646
  30. Unicodeとの相違点とISO/IEC 10646との互換性の詳細 – 株式会社一創 https://www.issoh.co.jp/column/details/7728/
  31. 文字コード第七回：文字コードの歴史 – 社内SEになりました https://systemengineers.hateblo.jp/entry/2021/08/07/142124
  32. サロゲートペア 【surrogate pair】 – 文字コード – IT用語辞典 e-Words https://e-words.jp/w/%E3%82%B5%E3%83%AD%E3%82%B2%E3%83%BC%E3%83%88%E3%83%9A%E3%82%A2.html
  33. サロゲートペアについて調べてみる #文字コード – Qiita https://qiita.com/zumi0/items/fd80289e41453aad48ad
  34. カオス過ぎる Unicode, UTF-8, UTF-16, UTF-32 の違い概要まとめ – Qiita https://qiita.com/tatsubey/items/0ba0d3b84c012fd4d19b
  35. ユニコード規格 – IBM https://www.ibm.com/docs/ja/xl-c-aix/13.1.0?topic=set-unicode-standard
  36. UTF-8ってなに？文字コードの仕組みや文字化けの原因・対処法についても解説 https://www.creativevillage.ne.jp/category/topcreators/web-creator/128985/
  37. 【文字コード】utf-8とshift-jis(sjis)の違いを解説 – trends https://trends.codecamp.jp/blogs/media/difference-word256
  38. RFC 2279: UTF-8, a transformation format of ISO 10646 – Pike Programming Language http://pike.lysator.liu.se/docs/ietf/rfc/22/rfc2279.xml
  39. 文字と文字列と文字コードのお話 – C# – Qiita https://qiita.com/sawasaka/items/232daf6751805ff135d8
  40. Byte order mark – Wikipedia https://en.wikipedia.org/wiki/Byte_order_mark
  41. Using Byte Order Marks – Win32 apps – Microsoft Learn https://learn.microsoft.com/en-us/windows/win32/intl/using-byte-order-marks
  42. 文字化けはなぜ起こる？原因・理由と直し方、復元・変換方法を解説 | マーケトランク https://www.profuture.co.jp/mk/column/garbled-text
  43. いま改めて「文字コード」について（その３） https://xn--ruq167cnto080a.com/media_key/3399/
  44. UTF-8とは？文字化けを防ぎSEOに強い文字コードをWeb制作初心者にもわかりやすく解説 https://www.profuture.co.jp/mk/column/what-is-utf-8
レポート