Making qr code generator - part 1

i’m trying to make a qr code generator while reading these:

• ISO IEC 18004 2015 Standard.pdf
• https:www.thonky.com/qr-code-tutorial

*

modes

mixing modes

multiple modes can be used in single qr code.

this can be done because we specify the length of each data segment.

example:

ECI(utf-8) - BYTE(data1) - ALPHANUMERIC(data2) - KANJI(data3)

extended channel interpretation (ECI) mode

we can encode data into various encodings like utf-8, ISO/IEC 8859-1(latin-1), ISO/IEC 8859-2(latin-2), and even raw bytes.

i had hard time understanding the ECI mode. the ECI mode only contains encoding format data like utf-8 and this instructs how to decode following data (usually byte mode data).

example 1:

ECI(utf-8) - BYTE(data1)

we treat data1 as utf-8 string.

example 2:

ECI(utf-8) - BYTE(data1) - NUMERIC(data2) - ECI(shift_jis) - BYTE(data3)

we treat

• data1 as utf-8 string.
• data2 as numeric data.
• data3 as shift_jis data.

kanji mode

kanjis can be encoded with utf-8 but, kanji mode is more efficient.

about utf-8

there are several ways to use utf-8 in qrcode

• just use utf-8 bytes some qrcode reader can just detect if utf-8 is used but others doesn’t.
• ECI mode we can define to use utf-8 encoding using ECI mode. but similarly, some qrcode reader doesn’t support ECI mode.
• byte order mark (BOM) we can use byte order mark (BOM) 0xEF 0xBB 0xBF at the front of the bytes.

error correction

qrcode uses Reed–Solomon error correction

error correction levels:

versions

the different sizes of qr codes are called versions.

version N is (17+4N)x(17+4N) pixels (1 <= N <= 40) so, version 1 is 21x21, version 2 is 25x25, … , version 39 is 173x173, version 40 is 177x177.

since each version has a maximum capacity, we should choose version that fits out data.

we can determine version to use for data with character capacities table

character counting

for each version and mode, data character count reserves a specific bits.

data encoding

numeric mode [0001]

split digits into group of three digits (ltr). last group can be one or two digits long.

for non last group with number N:

• convert to 10 bits binary

for last group with number N:

•   0 <= N <= 9   : 4  bits binary
•  10 <= N <= 99  : 7  bits binary
• 100 <= N <= 999 : 10 bits binary

and yes, article that i read[↗] was wrong. look at [7.4.3 Numeric mode] in the ISO/IEC 18004:2015 QR code standard specification.

=== example start ===

let's assume err corr level as L(low).

[42805902]
    → numeric mode <0001>
    → 8 chars → ver 1 → <00 00001000>

[42805902]
 ↓
[428] [059] [02]
 ↓
[428] [59]  [2]
 ↓
<01 10101100> <00 00111011> <0010>
 ↓
<01101011 00000011 10110010>

 ↓

final bits:
 <0001 0000001000 01101011 00000011 
  10110010>

=== example end ===

alphanumeric mode [0010]

split characters into group of two characters (ltr). last group can be a single character.

for each pair, treat two character as a base 45 number and convert to 11 bits binary (left pad with zeros).

if the pair is [RA], R and A each converts to 27 and 10 so in base 45, it’s (27 × 45) + 10 = 1225 = 100 1100 1001₍₂₎

if last group is a single character, convert it to 6 bits binary.

=== example start ===

let's assume err corr level as L(low).

[RAWPLUG2026 10 15]
    → alphanumeric mode <0010>
    → 18 chars → ver 1 → <00 00010010>

[RAWPLUG2026 10 15]
 ↓
[RA] [WP] [LU] [G2] [02] [6 ] [10] [ 1] [5]
 ↓
[WP] → (32 * 45) + 25 = 1465 = <101 10111001>
[RA] → (27 * 45) + 10 = 1225 = <100 11001001>
[LU] → (21 * 45) + 30 =  975 = <011 11001111>
[G2] → (16 * 45) +  2 =  722 = <010 11010010>
[02] → ( 0 * 45) +  2 =    2 = <000 00000010>
[6 ] → ( 6 * 45) + 36 = 0306 = <001 00110010>
[10] → ( 1 * 45) +  0 =   45 = <000 00101101>
[ 1] → (36 * 45) +  1 = 1621 = <110 01010101>
[5]  → 5                     =       <000101>
 ↓
 <10110111 00110011 00100101 11100111
  10101101 00100000 00000100 01001100
  10000001 01101110 01010101 000101>

 ↓

final bits:
 <0010 0000010010 10110111 00110011 
  00100101 11100111 10101101 00100000 
  00000100 01001100 10000001 01101110 
  01010101 000101>

=== example end ===

kanji mode [1000]

…

i don’t know whether should i learn about this mode, honestly.

byte mode [0100]

when it comes to bytes, there’s nothing to encode. bytes are just raw binary data.

=== example start ===

let's assume err corr level as L(low).

[6D AC D3 B4 25 12]
    → byte mode <0100>
    → 6 chars(bytes) → ver 1 → <00 00000110>

[6D AC D3 B4 25 12]
 ↓
<01101101 10101100 11010011 10110100 00100101 00010010>

 ↓

final bits:
 <0100 0000000110 01101101 10101100 
  11010011 10110100 00100101 00010010>

=== example end ===

ECI mode [0111]

byte mode alone doesn’t contains data about encoding by default (some qrcode readers do detect utf-8). using ECI mode, we can define encoding for byte mode.

ECI Designator:

list of supported ECI encodings[↗]

=== example start ===

let's assume err corr level as L(low).

[bong]
    → eci mode <0111>
    → utf-8 format \000026 → <00011010>

    → byte mode <0100>
    → 4 chars(bytes) → ver 1 → <00 00000100>

[bong]
 ↓
[62 6F 6E 67]
 ↓
<01100010 01101111 01101110 01100111>

final bits:
 <0111 00011010 0100 00 00000100 
  01100010 01101111 01101110 01100111>

=== example end ===

appendix

a. alphanumeric table

uppercase only for alphabets.

b. character capacities