Гляну, спасибо

А можно кратки TL;TR? Если сложно, то не надо

А то там вступление, аннотация и краткое описание это копипаста друг друга

у меня ощущение что цифра в х100 Москвы слегка далека от реальности..

чтобы было понятней - вот например RFC на почтовый адрес https://datatracker.ietf.org/doc/html/rfc2822 (оно большое и сложное)
когда встречаются вкрапления
orig-date       =       "Date:" date-time CRLF
это читается так: определим токен с именем orig-date,
его значение - строка начинающаяся с "Date:", после нее идет токен date-time и завершается все токеном CRLF
Дальше - ищем определение токена date-time в том же тексте
date-time       =       [ day-of-week "," ] date FWS time [CFWS]
повторяем парсинг -  токен date-time состоит из
опционально - токен day-of-week, после которого следует символ ',',
обязательно - токен date, FTS, токен time, опционально токен CFWS

вот например секция синтаксиса определяющего формат даты

date-time       =       [ day-of-week "," ] date FWS time [CFWS]
day-of-week     =       ([FWS] day-name) / obs-day-of-week
day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
                        "Fri" / "Sat" / "Sun"
date            =       day month year
year            =       4*DIGIT / obs-year
month           =       (FWS month-name FWS) / obs-month
month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /
                        "May" / "Jun" / "Jul" / "Aug" /
                        "Sep" / "Oct" / "Nov" / "Dec"
day             =       ([FWS] 1*2DIGIT) / obs-day
time            =       time-of-day FWS zone
time-of-day     =       hour ":" minute [ ":" second ]
hour            =       2DIGIT / obs-hour
minute          =       2DIGIT / obs-minute
second          =       2DIGIT / obs-second
zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

собственно в том что я слинковал - описание - как читать такие форматы, что означают все символы типа
[ ] - опционально
/ - или
4*DIGIT - 4 раза повторить разрешенные значения DIGIT (который сам определяется тут https://datatracker.ietf.org/doc/html/rfc2234)

 A range of alternative numeric values can be specified compactly, using dash ("-") to indicate the range of alternative values.  Hence:
        DIGIT       =  %x30-39
   is equivalent to:
        DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

Вау

Спасибо, открыл мир

оно сначала кажется - ой как мутно и сложно, но когда начинаешь понимать как читать вот такие токены - RFC читаются очень легко а главное - понимаешь что все остальные форматы описания - переусложнены...

т.е. это как рекурсия для читателя. Вот попробуй сам отпарсить секцию синтаксиса определяющего дату -  за исключением некоторых токенов типа obs-year -  там все есть.

Cоответственно любой текст можно записать в таком же виде  ну типа вот твой пример, я взял одну строчку и предположил что количество элементов в UID: должно быть равно значению UID len: (и возможно соврал с синтаксисом в uid-length*uid-element

```

UID len: 04 UID: 89 86 65 9C ATQA: 04 00 SAK: 08

(я не особо умею описывать, я  в основном читаю такой формат легко, так что придумываю токены на ходу):

line = uid-token whitespace "len:" uid-length uid-token ":" uid-length*uid-element

ATQA-token ":" SAK-token ":" SAK

-element
uid-token = "UID" // фиксированный токен - константа "UIT"
whitespace = %x20 / %x09  // это space или tab
uid-length = 2*DIGIT
uid-element = 2*DIGIT

ATQA-token

= "

ATQA

"

ATQA-element

= 2*DIGIT whitespace 2*DIGIT

SAK-token

= "SAK"

SAK

-element = 2*DIGIT
```
ну и в итоге вообще любой формат от  структуры TCP/IP пакета до заголовков почты можно описать вот таким синтаксисом. и т.к. он единый, довольно строгий и давно существующий - по файлам в таком формате можно ходить и генерить парсеры.
Даже если формат  - недетерминистический (не все правила существуют или парсер написать невозможно, как например - разрешенный  формат почтового адреса в старых rfc) - его можно описать в ABNF\BNF синтаксисе..

В какую сторону и почему?

Урок, выученный кровью и слезами: рядом с описанием каждого типа пакетов пишите минимум один пример и как он должен расшифровываться. Лучше несколько. И каждый новый энкодер и парсер должны нести это в своих юнит-тестах. Без этого просто не принимать работу/не мержить в мастер.

О, офигенно, спасибо

По ЕС можно взять тут в Евростате - https://ec.europa.eu/eurostat/databrowser/view/tps00172/default/table?lang=en
По США публикуют отчеты, они гуглятся.
По остальным регионам надо точечно искать, бывает что публикуют, бывает что нет.
Оно все конечно приблизительное, но порядок +- понятен будет. Как и состояние экономики, хех.

э, а чем закончилось то

в какой цвет велостоянку покрасили в итоге

наши победили :)

serendipity

Посмотри в сторону PEG для описания грамматики чтобы не писать свой парсер для каждой платформы.

https://github.com/PhilippeSigaud/Pegged/wiki/PEG-Basics

а можешь в двух словах объяснить разницу PEG и LL ? К моему стыду раньше про PEG не слышал