Персонажи En Dash и Start of Guarded Area - PullRequest
Новая
       9

Персонажи En Dash и Start of Guarded Area

0 голосов
/ 18 мая 2018

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

У меня есть два CSV-файла, содержащие данные из QuickBooks.Один был создан с использованием встроенной функции создания отчетов QuickBooks, а другой - с помощью API доступа к данным, использующего QuickBooks SDK.В обоих этих CSV-файлах есть текстовый столбец, который я могу использовать в качестве ключа для связи данных в указанных файлах.

Однако в одной конкретной строке есть один конкретный символ, который двафайлы не могут быть согласованы:

  • В QuickBooks персонаж имеет визуальный вид тире
  • В CSV, созданном непосредственно QuickBooks, персонаж экспортируется какen-dash (U + 2013 или десятичный код 8211)
  • НО API на базе SDK считывает его из QuickBooks как символ «Начало охраняемой зоны» (U + 0096 или десятичный код 150).

Это вызывает проблему, потому что мой код думает, что две строки различны (какими они технически являются, но не должны быть), и, следовательно, не соответствует им.Я убежден, что где-то вдоль строки должна быть какая-то ошибка кодирования, но я не могу найти никакой связи между этими двумя символами.

Я не ожидаю, что кто-то сможет выяснить, что именнопроисходит, поскольку у нас нет доступа к тому, что QuickBooks или API делают закулисными.Но я надеюсь, что кто-то может дать мне некоторое представление о том, почему этот персонаж неправильно переведен.

Ответы [ 2 ]

0 голосов
/ 29 октября 2018

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

Насколько я могу судить, QuickBooks фактически хранит и выводит свои данныеиспользуя windows-1252 (это кодировка, используемая при экспорте в текстовый файл из QB).Но когда данные читаются через API на основе SDK, где-то вдоль строки коды Windows-1252 неправильно интерпретируются как Unicode (либо с помощью QB SDK, стороннего API или самой .NET Framework; у меня нет никакого способазная).

Это работает большую часть времени, потому что коды символов от 0 до 127 (включая все буквы в английском алфавите) одинаковы между двумя кодировками.Но начиная с 128, две схемы расходятся, поэтому 150 в windows-1252 означает «en-dash», а в Unicode - «Начало охраняемой области».

Чтобы исправить это, я использовал следующий код: 

Dim Builder As New Text.StringBuilder(Input)
For i = 0 To Builder.Length - 1
    Dim n = AscW(Builder(i))

    If n > 127 AndAlso n < 256 Then
        Dim b As Byte = n
        Builder(i) = System.Text.Encoding.Default.GetChars({b})(0)
    End If
Next

Return Builder.ToString

Получает код символа для каждого символа (используя AscW) и, если код находится в диапазоне от 127 до 256 (исключительно) (255 является последним символом в windows-1252), правильно его интерпретируетиспользуя кодировку windows-1252, а затем должным образом преобразует ее в Unicode.

0 голосов
/ 24 октября 2018

Проблема в том, что они (вероятно) внутренне кодируют en-dash как U + 0096, что соответствует байт Windows-1252 (0x96) для en-dash , но в Unicode это фактическипредставляет специальный символ «Начало охраняемой зоны» .

По некоторым причинам обратной совместимости веб-браузеры преобразовывают этот символ в U + 2013 для отображения на веб-странице.

ИтакЕсть две проблемы - неправильное кодирование на стороне QuickBooks и сбивающее с толку поведение браузера, который преобразует символ из windows-1252 в Unicode.

Существует несколько связанных с этим вопросов:

...