Почему Delphi IBX TWideMemoField преобразует порядок байтов в строку UTF8 и как этого избежать? - PullRequest
Новая
       37

Почему Delphi IBX TWideMemoField преобразует порядок байтов в строку UTF8 и как этого избежать?

0 голосов
/ 03 сентября 2018

Я использую Delphi 2009 с IBX для базы данных Firebird 3 (у меня нет выбора, чтобы выбрать другие технологии, я должен адаптироваться к ситуации). У меня есть следующие определения:

Поле BLOB Firebird определено как: 

BLOB SUB_TYPE 0 SEGMENT SIZE 80

TWideMemoField определяется как: 

object MainQryNOTES: TWideMemoField
  FieldName = 'NOTES'
  Origin = 'INVOICES.NOTES'
  ProviderFlags = [pfInUpdate]
  BlobType = ftWideMemo
end

Тестовая строка "Цель по инфляции,%", и в ней ее можно прочитать из поля BLOB в программном обеспечении IBExpert как: 

26 04 35 04 3B 04 4C 04 20 00 3F 04 3E 04 20 00
38 04 3D 04 44 04 3B 04 4F 04 46 04 38 04 38 04
2C 00 20 00 25 00

Странно то, что Delphi инвертирует порядок байтов, например кириллический символ Ц имеет представление HEX UTF8 как 04 26, но он хранится в базе данных как 26 04, и аналогичная ситуация точно также с другими символами (это можно проверить с помощью таблиц https://www.w3schools.com/charsets/ref_utf_basic_latin.asp и https://www.w3schools.com/charsets/ref_utf_cyrillic.asp). В моем случае у меня есть только 2-байтовые символы, но я думаю, что аналогичная ситуация будет и с 3-х и 4-х байтовыми символами UTF8.

Итак - как я могу настроить TWideMemoField, чтобы он не запрашивал преобразование порядка байтов строк UTF8?

1 Ответ

0 голосов
/ 03 сентября 2018

Ваш текст не кодируется как UTF8, он кодируется как UTF16. Символ Ц U + 0426 . По соглашению, 16-битная кодовая единица хранится в порядке байтов с прямым порядком байтов, $ 26 $ 04.

Другими словами, все ведет себя как ожидалось и как задумано, и я не вижу необходимости в том, чтобы вы пытались что-то исправить, потому что ничего не сломано.

...