Я не уверен, что полностью понимаю, но, похоже, у вас есть парсер для этого двоичного формата, и вы управляете кодом для него. Таким образом, этот ответ построен на этом предположении.
Анализатор каким-то образом будет заполнять структуры, классы или любую структуру данных, имеющуюся в вашем языке. Если вы реализуете ToStringдля всего, что анализируется, вы получите очень простой в использовании и легко поддерживаемый метод отображения этих двоичных данных в удобочитаемом формате.
Вы бы по существу имели:
byte[] arrayOfBytes; // initialized somehow
Object obj = Parser.parse(arrayOfBytes);
Logger.log(obj.ToString());
И это все, с точки зрения его использования. Конечно, это требует от вас реализации / переопределения ToStringфункции для вашего Objectкласса / структуры / чего бы то ни было, и вам также придется делать это для любых вложенных классов / структур / whatevers.
Кроме того, вы можете использовать условный оператор для предотвращения вызова ToStringфункции в коде выпуска, чтобы не тратить время на то, что не будет зарегистрировано вне режима отладки.
Вы ToStringможете выглядеть так:
return String.Format("%d,%d,%d,%d", int32var, int16var, int8var, int32var2);
// OR
return String.Format("%s:%d,%s:%d,%s:%d,%s:%d", varName1, int32var, varName2, int16var, varName3, int8var, varName4, int32var2);
Ваш первоначальный вопрос звучит так, как будто вы несколько пытались это сделать, и что вы думаете, что этот метод обременителен, но вы также в какой-то момент реализовали анализ двоичного формата и создали переменные для хранения этих данных. Поэтому все, что вам нужно сделать, это распечатать существующие переменные на соответствующем уровне абстракции (класс / структура, в которой находится переменная).
Это то, что вы должны сделать только один раз, и вы можете сделать это при сборке парсера. И он будет изменяться только при изменении двоичного формата (который в любом случае уже будет вызывать изменение вашего парсера).
Аналогичным образом: некоторые языки имеют надежные функции для преобразования классов в XML или JSON. C # особенно хорош в этом. Вам не нужно отказываться от своего двоичного формата, вы просто делаете XML или JSON в операторе ведения журнала отладки и оставляете свой код выпуска в покое.
Я лично рекомендую не идти по маршруту шестнадцатеричного дампа, потому что он подвержен ошибкам (вы начали с правого байта, уверены ли вы, когда читаете слева направо, что «видите» правильный порядок байтов и т. Д.) ,
Пример. Скажите, что вы ToStringsвыплевываете переменные a,b,c,d,e,f,g,h. Вы запускаете свою программу и замечаете ошибку g, но проблема действительно началась с c(но вы отлаживаете, так что вы еще не поняли). Если вы знаете входные значения (и должны это сделать), вы сразу же увидите, что cименно здесь начинаются проблемы.
По сравнению с шестнадцатеричным дампом, который просто говорит вам 338E 8455 0000 FF76 0000 E444 ....; если ваши поля различаются по размеру, где cначинается и каково значение - шестнадцатеричный редактор скажет вам, но я хочу сказать, что это подвержено ошибкам и требует много времени. Не только это, но вы не можете легко / быстро автоматизировать тест с помощью шестнадцатеричной программы просмотра. Распечатка строки после анализа данных точно скажет вам, о чем думает ваша программа, и станет одним из шагов на пути автоматического тестирования.
