Записываю двоичные данные (20 байт) в файл при разных значениях ПорядокБайтов
    
ПотокКонечный = ФайловыеПотоки.ОткрытьДляЗаписи(ПолноеИмяФайла+"_B");    
    ЗаписьДанных = Новый ЗаписьДанных(ПотокКонечный,,ПорядокБайтов.BigEndian);
    ЗаписьДанных.Записать(ДД);
    ЗаписьДанных.Закрыть();
    ПотокКонечный.Закрыть();

ПотокКонечный = ФайловыеПотоки.ОткрытьДляЗаписи(ПолноеИмяФайла+"_L");    
    ЗаписьДанных = Новый ЗаписьДанных(ПотокКонечный,,ПорядокБайтов.LittleEndian);
    ЗаписьДанных.Записать(ДД);
    ЗаписьДанных.Закрыть();
    ПотокКонечный.Закрыть();

результат смотрю notepad++ с плагином HEX
никакой разницы в файлах.
Это так должно быть ?

может у тебя однобитовые знаяения и для них порядок байтов не играет роли

порядок байтов имеет смысл, когда записываешь в поток числа из нескольких байт. например, int32 - это 4 байта. вот эти 4 байта и будут перестанавливаться.

как записывается хеш SHA-1 (20 байт) на NIX-сах ?
Потому что какая то какая то ерунда получается выходной код на никсах и на винде вроде по разному сохраняется в файл

есть фича которая преобразует 20 байт (5 слов по 4 байта) из big-endian в little ?

(3) за порядок же BOM отвечает или он одинаковый и там и там?

(5) без бома

(6) юникод и без бома? или это utf-8 кге априори все однобайтовое?

функция на вебсервере вычисляет SHA1  и пишет в файл на клиенте.
наверно сервер на никсах
потому что делаю тоже самое на 1с8 но файл получается другой

(8) вероятно у тебя "на 1с8" на вход функции другое подается

проверь кодировку входящих и учти бом если утф8

(9)файл от SHA1 20 байт - бом не влазит

другая инфа на входе - маловероятно . Это канонизированный XML c того же сервера же.

(10) вот этот твой xml ты и сервер по разному читаете перед тем как считать хеш

Перепробовал  все типы канонизации - результат не различается.
написал на c# - результат такой же как и 1с8
но все не равно серверному.
серверный BE 8F 8D 91 D9 22 AB 0D 3C B4 E2 18 2A AC 04 34 AD 61 3A FA
1ц - шный AA A2 58 90 03 7B 24 86 6B FA 52 10 0E 92 95 32 70 7A AD 08

(12) откуда ты знаешь что и как "функция на вебсервере вычисляет SHA1  и пишет в файл на клиенте." ?

(13) ну из практики же
Есть файл, есть алгоритм, есть пример на C# (как бы на сервере так)

(14) а подумать?

(12) Символ конца строки в одном случае включается в хэш, в другом не включается?

(15) в точку.
но в какую.

(16) Нет. Канонизатор режет все что после последнего ">"

(18) А как там с переносами строк? Юникс или виндовс?

для примера, файл hello word, (hw.txt) создан в Windows notepad++

Windows:
certutil -hashfile hw.txt sha1
Хэш SHA1 hw.txt:
2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
CertUtil: -hashfile — команда успешно выполнена.

Debian 4.19.194-3:
sha1sum hw.txt
2aae6c35c94fcfb415dbe95f408b9ce91ee846ed  hw.txt

echo "hello world">hwd.txt

sha1sum hwd.txt
22596363b3de40b06f981fb85d82312e8c0ed511  hwd.txt

file hwd.txt
hwd.txt: ASCII text

file hw.txt
hw.txt: ASCII text, with no line terminators

(21) Я так понимаю что hash SHA1 - он и в Африке SHA1
Проблема (наверно) в записи в файл, но и это не точно.
Прога на серверная, создает хэш пишет в файл, и потом же саа это проверяет. Так что ей без разницы как записано в файл, если она его по одному закону пишет и читает. А вот Клиентской программе как создать файл чтоб сервер скушал...

(19) по правилам канонизации
а еще данные это одна строка, без ВК или ПС

Во-первых,файл должен быть без ByteOrderMark.
Во-вторых,кодировка должна быть utf-8.
В третьих,убрать символы завершения файла,если они есть (код 26).
И не забыть,что перевод строки должен быть два символа 13 и 10.
При передаче по http именно такие переводы строки в текстовых файлах получаются.

я правильно понимаю что пытаешься для маркировки отправить?

(25) ну типа того
XML канонизируется на сервере, вычисляется SHA1 (20 байт) , пишется в файл на клиенте.
Клиент подписывает хэш - получается файл формата XML. Сервер забирает файл подписи и соеденяет с исходным файлом данных. Потом все хранится в базе серверав виде одного документа.
Это точно.
Дальше наверно так:
При проверке достоверности этого документа отделяется часть подписи , проверяется её достоверность (кидается на клиента - клиент проверяется ,отвечает true/false),
Хэш вычисляется из документа и сравнивается с хэш из подписи, если они равны то Ок.

т.е.хэш видно, каким он должен быть.

(26) Дичь какая-то. Зачем все так сложно и непонятно. Чего добиться то пытаетесь?

(26) хехе
было такое когда для МДЛП делал
оказалось там надо xml правильно делать
т.е. там путаница с кодировками была и XML надо уже канонизированный отправлять
т.е. какой отправил, такой и хешить/подписывать надо

(29) я же говорю - канонизирую и хэш считаю.
(28) что непонятно? достоверность электронного документа хранящегося на сервере гарантируется ЭЦП клиента.