Chapter 44: The Full ASCII Extension |
Standard Code 39 supports 43 characters: uppercase letters, digits, and a handful of special symbols. The Full ASCII extension unlocks the remaining 85 ASCII characters---including lowercase letters and control codes---by using paired shift characters ($, /, +, %). This powerful capability comes at a cost: each extended character consumes two symbol characters, effectively doubling the barcode length for mixed-case data. This chapter explores the technical mechanics of the extension and examines how its unique trade-offs shape its adoption across industries, from military logistics to healthcare labeling. |
|
44.1 The Origin and Necessity of the Extension |
When David Allais and Raymond Stevens developed Code 39 in 1974 at Interface Mechanisms Inc., they created a symbology that was revolutionary for its time: the first barcode that could encode both letters and numbers . The original specification supported 43 characters---digits 0 through 9, uppercase A through Z, and seven special characters (space, minus, period, dollar sign, slash, plus, and percent). The start and stop character, typically the asterisk, completed the set. |
For many early applications, this was sufficient. Inventory tracking, for instance, primarily used alphanumeric codes in uppercase. The U.S. military's LOGMARS system relied on this character set for equipment identification . But as computing systems evolved and data interchange expanded, the limitations became apparent. What if you needed to encode a person's name with mixed caseWhat about the myriad control characters that structured data in early computer systems |
The answer was Code 39 Full ASCII, also known as Code 39 Extended. This extension, formally documented in the ISO/IEC 16388 standard, enables encoding of every character in the standard 128-character ASCII table, including lowercase letters, punctuation marks beyond the original seven, and all 33 non-printing control characters . |
The beauty of the Full ASCII extension lies in its ingenuity: it achieves this expansion without altering the fundamental structure of the barcode or requiring a new symbology. Instead, it repurposes four special characters---the dollar sign ($), slash (/), plus (+), and percent (%)---as shift codes that modify the interpretation of the following character . |
|
44.2 Technical Mechanics: How Paired Characters Work |
Understanding the Full ASCII extension requires grasping the encoding logic of standard Code 39. Each standard character is represented by a pattern of nine elements: five bars and four spaces, with exactly three wide elements and six narrow ones . This 'three of nine' encoding gives the symbology its name and provides a self-checking property: a single printing defect cannot transform one valid character into another because the wide/narrow patterns are sufficiently distinct . |
The extension leverages the fact that four of the standard characters---$, /, +, and %---are rarely used in certain contexts. By pairing one of these 'shift' characters with a letter, the decoder, when operating in Full ASCII mode, interprets the pair as a completely different ASCII character. |
Consider the lowercase letter 'a.' In Full ASCII encoding, this is represented as '+A' . The decoder reads the plus sign, recognizes it as a shift indicator, then reads the following 'A.' Instead of transmitting the literal characters '+' and 'A,' the decoder, configured for Full ASCII mode, performs a translation and outputs the lowercase 'a.' If the same barcode were scanned by a reader not configured for Full ASCII, it would transmit '+A' literally . |
This pattern extends across the entire ASCII table. The shift characters combine with the 43 standard characters to cover all 128 possibilities. For example, lowercase letters are typically encoded by adding a '+' before the uppercase equivalent: '+B' for 'b,' '+C' for 'c,' and so on. Other extended characters use different shift prefixes: '/' maps to certain punctuation marks, '$' to others, and '%' to yet another set. The ISO/IEC specification provides the complete mapping table for all 128 ASCII characters . |
This encoding mechanism is elegant because it imposes no structural changes on the barcode itself. The same start and stop characters, the same quiet zone requirements, and the same check digit logic apply. The only difference is in the interpretation layer---whether the decoder is set to 'regular' or 'Full ASCII' mode . |
|
44.3 The Density Trade-Off: A Triple Penalty |
The most significant practical implication of the Full ASCII extension is its impact on barcode density. This is where the chapter title's assertion---'triples length for lowercase or control chars'---requires careful qualification. |
For characters already in the standard 43-character set, there is no density penalty. A capital 'A' is encoded as a single character in both regular and Full ASCII modes. However, for any character outside the standard set---lowercase letters, most punctuation marks, control characters---the encoding uses two standard characters. This effectively doubles the number of symbol characters required . |
The impact on printed barcode length can be even more dramatic than simple doubling due to the inter-character gap. Code 39 is a discrete symbology, meaning each character is separated by a gap of one narrow-element width. When you double the number of character symbols, you also double the number of inter-character gaps. The net effect is a printed barcode that is approximately twice as long for lowercase text compared to the same text in uppercase . |
The word 'SEAGULL' in regular Code 39 encodes as *SEAGULL*---nine characters including the start and stop asterisks. The same word in lowercase, 'seagull,' encodes as *+S+E+A+G+U+L+L*---seventeen characters, nearly double the length . For control characters, the encoding can be even more verbose, as certain characters may require specific shift combinations that don't correspond directly to a single uppercase letter. |
This density penalty has profound implications for barcode design. A standard Code 39 barcode is already less dense than more modern symbologies like Code 128, which achieves higher density through variable-width encoding and three distinct character sets . The Full ASCII extension exacerbates this limitation. A 10-character mixed-case string encoded in Full ASCII Code 39 may be roughly 40% to 50% wider than the same data encoded in Code 128 . |
In applications where label space is constrained---think pharmaceutical vials, small electronic components, or medical device labels---this density trade-off can be a deal-breaker. Yet in other contexts, where labels are large enough or data strings short enough, the trade-off is acceptable, especially given Code 39's widespread compatibility and the fact that nearly all barcode scanners in operation today can be configured for Full ASCII mode with a simple software setting . |
|
44.4 Industry Applications: Where Full ASCII Matters |
Despite the density penalty, Code 39 Full ASCII remains in active use across multiple industries. Its adoption is typically driven by legacy system compatibility, regulatory requirements, or the need for human-readable data in mixed case. Below, we examine several sectors where the Full ASCII extension has found a practical foothold. |
44.4.1 Military and Government Logistics |
The U.S. Department of Defense's LOGMARS (Logistics Applications of Automated Marking and Reading Symbols) program stands as perhaps the most prominent early adopter of Code 39 . While the standard LOGMARS specification primarily uses regular Code 39 for equipment marking, the Full ASCII extension becomes relevant when marking assets with serial numbers, nomenclature, or descriptive text that includes lowercase characters or specific punctuation. |
The MIL-STD-130 standard, which governs identification marking of U.S. military property, has evolved to reference Code 39 and its extended capabilities . In practice, military supply chains occasionally require encoding of data elements that contain lowercase letters---for instance, manufacturer-specific part numbers or technical specifications that follow proprietary naming conventions. The Full ASCII extension allows the symbology to accommodate these requirements without abandoning the proven Code 39 infrastructure. |
The density trade-off is less problematic in military logistics, where labels on large equipment, shipping containers, and pallets have ample real estate. The reliability of Code 39's self-checking property, combined with its established presence in government procurement systems, outweighs the length concerns . |
|
44.4.2 Automotive Industry |
The automotive industry, through standards developed by the Automotive Industry Action Group (AIAG), has long relied on Code 39 for part identification and supply chain tracking . The AIAG B-1 standard, which defines labels for shipping and receiving, originally mandated Code 39 for many application identifiers . |
While newer AIAG standards have shifted toward Code 128 and GS1-128 to support higher data density and the broader GS1 system, Code 39 remains entrenched in certain subsegments---particularly for suppliers who invested heavily in Code 39-based labeling systems before the transition, or for applications where the amount of data is modest. |
The Full ASCII extension becomes relevant when encoding part descriptions that include lowercase letters or special characters like parentheses, brackets, or mathematical symbols. For instance, automotive electronics components often have specifications that include mixed-case abbreviations (e.g., 'CANbus' or 'ECU'). Encoding these in regular Code 39 would be impossible; Full ASCII provides a path. The decision to use Full ASCII in automotive contexts often hinges on whether the downstream scanning systems are configured to handle the extension and whether the label size can accommodate the longer barcodes. |
|
44.4.3 Healthcare and Medical Device Labeling |
The healthcare sector presents a compelling case for the Full ASCII extension. The Health Industry Bar Code (HIBC) standard, widely used for medical device labeling, patient identification, and pharmaceutical tracking, has historically supported Code 39 among its permitted symbologies . |
In healthcare applications, the need for Full ASCII encoding arises frequently. Patient wristbands with names in mixed case, expiration dates encoded in formats requiring punctuation, and lot numbers that use lowercase manufacturer-specific codes all benefit from the extension. The HIBC standard's primary application identifiers may include data fields that require the full ASCII set. |
However, healthcare labels present a spatial challenge. A small vial, syringe, or ampule label has limited real estate; the density penalty of Full ASCII Code 39 can make the barcode either too long or require an X-dimension (narrow bar width) so small that printing and scanning become unreliable. For this reason, healthcare applications that require mixed case or extensive punctuation have largely migrated to Code 128, which supports the full ASCII set without a paired-character penalty . Nonetheless, older systems and certain device labeling requirements continue to rely on Code 39 Full ASCII, particularly in applications where the data payload is short. |
|
44.4.4 Library Systems and Asset Tracking |
Library management systems, university asset registries, and internal tracking systems were early adopters of barcode technology. Code 39's simplicity and low-cost implementation made it a natural choice . In library contexts, barcodes encode accession numbers, call numbers, or patron IDs---typically numeric or alphanumeric codes that fit within the standard 43-character set. |
However, asset tracking systems that include descriptive data---room numbers, owner initials in mixed case, or asset category codes with punctuation---may require Full ASCII. A university tracking system might encode 'Lab-101A' or 'HVAC-Unit3' on equipment tags. The Full ASCII extension handles these cases without requiring a symbology change. |
The density trade-off is less problematic in asset tracking because labels on equipment, furniture, or fixtures have ample space. Moreover, the scanning environment is often controlled---handheld scanners used in well-lit conditions---so the slightly longer barcodes are not a scanning impediment. |
|
44.4.5 Inventory Management and Industrial Tracking |
The broader industrial sector continues to use Code 39 extensively for inventory management, work-in-progress tracking, and assembly line routing . In environments where data needs are basic---serial numbers, work order codes, product IDs---the regular Code 39 suffices. |
The Full ASCII extension finds application in specialized industrial contexts. For instance, in high-tech manufacturing of electronics, telecommunications equipment, and aerospace components, part numbers may incorporate punctuation and mixed-case characters that are meaningful to engineering systems . In furniture manufacturing, product codes may include designator suffixes in lowercase. In photo finishing---a legacy application of Code 39---the ability to encode instructions or customer information in mixed case provides flexibility. |
The density trade-off is mitigated in these contexts by the size of the items being labeled---often pallets, crates, or large components---and by the fact that the data payload is typically short, often under 15 characters. For applications requiring longer data strings, implementers generally migrate to Code 128. |
|
44.5 Implementation Considerations and Pitfalls |
Deploying Code 39 Full ASCII requires attention to several practical considerations beyond basic barcode generation. |
44.5.1 Scanner Configuration |
The most common pitfall is scanner misconfiguration. A barcode generated in Full ASCII mode will scan correctly only if the scanner is also in Full ASCII mode. If a scanner is set to regular Code 39 decoding, it will interpret the shift characters literally, typically outputting the raw paired sequence . |
In a mixed environment where both regular and Full ASCII barcodes are in use, this creates a compatibility challenge. Some modern scanners support automatic detection or can be configured to detect and decode both modes, but this is not universal. Organizations deploying Full ASCII must plan for scanning infrastructure updates---whether reconfiguring existing scanners, deploying new ones, or ensuring that personnel know to adjust settings when scanning different types of labels . |
44.5.2 Software Encoding |
Barcode generation software must support the Full ASCII extension. While most barcode font packages and libraries include this capability, it is often a configurable option (e.g., 'Code39Extended=true'). Developers must be aware that enabling Full ASCII changes the encoding behavior: the library will automatically translate mixed-case strings into paired-character sequences . |
The risk of inadvertent encoding is real. A developer who enables Full ASCII but expects standard behavior may end up with barcodes that are longer than anticipated or that fail when scanned by non-configured readers. Conversely, disabling Full ASCII when mixed-case data is supplied may result in the library stripping or erroring on invalid characters. |
|
44.5.3 Check Digits |
The optional Modulo 43 check digit, frequently mandated in military and automotive applications, operates on the underlying standard characters---not on the decoded Full ASCII characters. The check digit is calculated from the sequence of standard Code 39 characters, which includes the shift characters . |
In practice, this means that if you encode 'seagull' as '+S+E+A+G+U+L+L,' the check digit is computed from those eight characters (plus signs and letters) using the Modulo 43 algorithm. The scanner, when in Full ASCII mode, verifies the check digit against the raw symbol characters and then translates the decoded data to lowercase. This is an important subtlety for developers implementing check digit logic. |
44.5.4 Human-Readable Interpretation |
For any barcode, the human-readable interpretation (the text printed below the barcode) should reflect what the user expects to see and scan. For Full ASCII barcodes, the human-readable text typically displays the final decoded string (e.g., 'seagull'), not the raw shift-character sequence. This avoids confusion and matches user expectations. |
However, this practice creates a minor disconnect between the visual reading and the encoded pattern. In troubleshooting or quality control contexts, it's useful to have systems that can display the raw encoding to verify that shift characters are correctly placed. |
|
44.6 Comparative Context: Code 39 vs. Code 128 |
No discussion of Code 39 Full ASCII is complete without acknowledging the alternative that rendered it less relevant for new implementations: Code 128. |
Code 128, introduced in 1981, was designed from the outset to support the full ASCII character set without a density penalty . It achieves this through a more compact encoding---each character is represented by 11 elements (six bars and five spaces) with varying widths---and through three distinct character sets (A, B, and C) that can be switched within the barcode . |
The density comparison is stark. A Code 128 barcode encoding a mixed-case string is approximately 30% to 40% shorter than the equivalent Code 39 Full ASCII barcode . For the 10-character example often cited in comparisons, Code 39 Full ASCII yields a barcode roughly 40% wider than Code 128 . For longer data strings, the difference compounds. |
Code 128 also offers a default check digit (modulo 103) and better error detection. Its inter-character encoding does not require the wide gaps that add length to Code 39. It is, by most objective measures, a superior symbology for new applications requiring full ASCII support. |
Given this, why does Code 39 Full ASCII persistThe answer lies in legacy infrastructure and compatibility. Code 39 enjoys the broadest installed base of any alphanumeric barcode symbology. It is supported by virtually every barcode scanner ever manufactured. For organizations with decades of investment in Code 39 scanning equipment, printing systems, and software, the cost of migrating to Code 128---which may require new scanners, updated software, and retrained personnel---outweighs the density benefits, especially for applications with short data strings . |
The self-checking property of Code 39 also remains a selling point. Because each character's encoding is sufficiently distinct, a single printing defect cannot transform it into another valid character . Code 128, which uses variable widths and more complex encoding, is not self-checking in the same sense, though its check digit provides error detection. In environments with low-quality printing or harsh scanning conditions, Code 39's self-checking can provide a reliability advantage. |
|
44.7 Quality and Printing Considerations |
The Full ASCII extension imposes no additional requirements on barcode quality beyond standard Code 39 specifications. The ISO/IEC 16388 standard defines dimensions, tolerances, and quality parameters that apply to both regular and Full ASCII modes . |
The recommended minimum height for manual scanning is 5.0 mm or 15% of the symbol width, whichever is greater . Quiet zones, the blank spaces before and after the barcode, must be at least 10 times the X-dimension (the width of the narrowest bar) . These specifications, when adhered to, ensure reliable scanning. |
However, the density penalty of Full ASCII can interact with these quality requirements in subtle ways. A longer barcode may require a smaller X-dimension to fit within a constrained label area. Reducing the X-dimension can make printing more challenging, as the precision required to maintain the wide-to-narrow ratio (typically 2.5:1 to 3:1) increases . At very small X-dimensions---below 0.19mm (7.5 mil)---common print defects like ink spread or insufficient resolution can lead to decoding failures . |
In practice, organizations deploying Full ASCII should carefully consider their available label space and choose an X-dimension that balances size constraints with print quality. If the label cannot accommodate the extended barcode at a reliable X-dimension, migrating to Code 128 may be the more practical choice. |
|
44.8 Future Viability and Migration Pathways |
The trajectory of barcode technology is clear: newer symbologies offer greater density, broader character support, and enhanced error protection. Code 128, GS1-128, and two-dimensional symbologies like Data Matrix and QR Code have displaced Code 39 in many new applications . |
Yet Code 39---and its Full ASCII extension---remain viable for specific use cases. The projection from most industry observers is that Code 39 will continue to decline in share of new implementations while maintaining a presence in legacy applications. The installed base is simply too large to disappear quickly. |
For organizations building new systems, the recommendation is to avoid Code 39 Full ASCII unless there is a compelling reason---typically, a requirement to maintain compatibility with existing scanning infrastructure or regulatory mandates that specify Code 39 . For organizations with existing Code 39 deployments that need to expand to mixed-case data, the Full ASCII extension provides a migration path that avoids a wholesale system overhaul. |
The decision framework is straightforward: if the data payload is short (under 20 characters) and the label space is sufficient to accommodate the extended barcode, Code 39 Full ASCII remains a practical choice. If the data is longer or space is constrained, Code 128 or a 2D symbology will be more appropriate. |
|
44.9 Summary |
The Code 39 Full ASCII extension achieves a remarkable technical feat: it expands a 43-character symbology to cover all 128 ASCII characters without altering its fundamental structure. By using four shift characters ($, /, +, %) paired with standard characters, it enables encoding of lowercase letters, full punctuation, and control codes in a way that is backward-compatible with standard Code 39 decoding when in regular mode. |
The cost of this flexibility is barcode density. Extended characters consume two symbol positions, effectively doubling the length of barcodes containing mixed-case data or punctuation. This penalty, combined with Code 39's inherently lower density compared to Code 128, makes the extension unsuitable for space-constrained applications or those with longer data payloads. |
In practice, the Full ASCII extension has found enduring application in industries where legacy infrastructure, regulatory mandates, or reliability considerations outweigh density concerns. The U.S. military's LOGMARS system, automotive supply chains through AIAG standards, healthcare labeling via HIBC, and industrial inventory management all continue to rely on Code 39---and occasionally its Full ASCII variant---for specific tracking and identification needs. |
For each of these industries, the decision to use Full ASCII reflects a balancing act: the technical requirement for a full character set versus the practical constraints of label size and scanning reliability. In many cases, the answer is to stay with regular Code 39 and design data strings that fit within its 43-character set. In others, where mixed-case or special characters are unavoidable, the Full ASCII extension provides a lifeline---a way to extend the life of systems that would otherwise require costly migration. |
The broader lesson from Code 39 Full ASCII is one that recurs throughout the history of information technology: the tension between extensibility and efficiency. The extension achieves extensibility through a clever encoding trick, but it sacrifices efficiency to do so. Understanding this trade-off, and choosing when to accept it, is the essence of practical engineering. For Code 39, the extension ensures that an iconic symbology remains relevant in a computing world that has long since moved beyond the constraints of uppercase-only data. |
As technology evolves, the role of Code 39 Full ASCII will continue to shrink relative to more modern symbologies. But for the millions of barcodes already in circulation---and for the organizations that rely on them---the extension provides a bridge, connecting a simpler time in barcode history to the complex, data-rich world of today. |
|
References |
Seagull Scientific Barcode Guide. 'Code 39 - Full ASCII.' barcodeguide.seagullscientific.com. |
ISO/IEC 16388:2023, 'Information technology - Automatic identification and data capture techniques - Code 39 bar code symbology specification.' |
ZXing Barcode Scanner Documentation. 'tryCode39ExtendedMode property.' pub.dev. |
ActivePDF Toolkit Documentation. 'Code 39 Full ASCII.' documentation.activepdf.com. |
SAP Mobile Infrastructure Documentation. 'Code39.' help.sap.com. |
DIN Standards Committee. 'ISO/IEC 16388:2023 Table of Contents.' din.de. |
Dynamsoft Barcode Reader Documentation. 'Code 39.' dynamsoft.com. |
BarcodeFYI. 'Code 39 Explained: The Self-Checking Alphanumeric Barcode.' barcodefyi.com. |
ISO Standards Catalog. 'ISO/IEC 16388:2023.' iso.org. |
Dynamsoft Blog. 'What is the Difference Between Code 39 and Code 128' dynamsoft.com. |
Aspose Documentation. 'Code 39.' docs.aspose.com. |
Wenglor Sensoric. 'Code39 Extended (full ASCII Code39).' wenglor.com. |
cs@easiersoft.com