PHPackages                             gugglegum/memory-size - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Parsing & Serialization](/categories/parsing)
4. /
5. gugglegum/memory-size

ActiveLibrary[Parsing & Serialization](/categories/parsing)

gugglegum/memory-size
=====================

Parser and formatter for human-friendly memory or file sizes based on standards

1.0.3(5y ago)410.9k↓16.7%1MITPHPPHP >=7.1

Since May 23Pushed 5y ago1 watchersCompare

[ Source](https://github.com/gugglegum/memory-size)[ Packagist](https://packagist.org/packages/gugglegum/memory-size)[ RSS](/packages/gugglegum-memory-size/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (4)Dependencies (1)Versions (5)Used By (1)

Memory Size
===========

[](#memory-size)

This is easy to use Composer package to deal with human-friendly formatted sizes of memory blocks or files (like "32 KB", "4.87 MiB" and so on). It consist of 2 parts: Parser and Formatter. The parser allows to parse formatted sizes in human-friendly view. Whereas the formatter allows to format size to human-friendly view. They are compatible each other, so parser able to parse string generated by formatter and vise-versa. This package was made with a focus on international standards and you may add your own standard implementation. Generally here's two main standards available out-of-the-box:

1. JEDEC Standard 100B.01 (JESD100B.01) ([https://en.wikipedia.org/wiki/JEDEC\_memory\_standards](https://en.wikipedia.org/wiki/JEDEC_memory_standards))
2. ISO/IEC 80000 ([https://en.wikipedia.org/wiki/ISO/IEC\_80000](https://en.wikipedia.org/wiki/ISO/IEC_80000))

The JESD100B.01 describes old-style measure units like "KB", "MB" & "GB" which are means 1024 bytes, 1024^2 bytes & 1024^3 bytes accordingly. Although these measure units are well-known and popular they are deprecated because they collide with SI (metric) prefixes where "M" means 1000^2 (million) and "G" means 1000^3 (billion). By the way, with "Kilo" prefix there's no collision because SI-prefix for "Kilo" defined as "k" (lowercase). Also JESD100B.01 allows to use shortened records contains only prefix, i.e. "K", "M" and "G". These records are little confusing but not so inconsistent as "KB", "MB" and "GB". Note that JESD100B.01 defines only kilobytes, megabytes and gigabytes. It's not defined terabytes, petabytes and so on. So "TB" unit should not be treated as 1024^4. If you need a standard which defines also "TB", "PB", etc. you may write your own standard implementation and set it into parser or formatter. Or you may write me and offer your own elegant solution of this problem.

The ISO/IEC 80000 is more modern standard. It solves problem of inconsistency of memory prefixes and SI-prefixes by introducing new binary prefixes especially for degrees of 2: "KiB", "MiB", "GiB", "TiB", "PiB", etc. which means 1024, 1024^2, 1024^3, 1024^4, 1024^5, etc. But this standard also refers to SI-prefixes. So, "1 MB" means 1000000 (1000^2) bytes, "1 GB" means 1000000000 (1000^3) bytes and so on.

These two standards (JESD100B.01 and ISO/IEC 80000) are implemented as separated classes with standard interface. You may define which standard and in which order to use or you can make your own standard implementation and pass your standard instance to the parser or to the formatter.

Parser
------

[](#parser)

For example, you want to accept from a user the size of anything in bytes (e.g. via config file or command line arguments). Of course, you can force a user to specify the exact size in bytes. But this is not very convenient when it comes to gigabytes and terabytes. Or maybe you need to parse data that already contains formatted file sizes like "700M" or "4.38GB". You may use this parser for this. Here's an example:

```