Проблема с ord () и строкой - PullRequest
Новая
       6

Проблема с ord () и строкой

3 голосов
/ 06 июня 2011

У меня возникла эта проблема, если у меня есть:

mychr = '';

где 'пробел' в mychr равен # 255 (набирается вручную ALT + 255), и я пишу:

myord = ord (mychr)

возвращаемое значение myord 160, а не 255. Конечно, та же проблема также и с символом ALT + 254 и т. Д. Как я могу решить эту проблему? Я проверил на Delphi XE в режиме консоли.

Примечание: если я использую:

mychar = # 255;

тогда функция ord () возвращает значение правильно.

Ответы [ 3 ]

9 голосов
/ 06 июня 2011

Я думаю, что проблема в том, что сочетания клавиш Windows Alt + Num вставляют символы в соответствии с локальной кодовой страницей, в то время как современные Delphi используют символы Юникода, и они отличаются (если я думаю, что значение меньше или равно 127) Решение состоит в том, чтобы ввести значения #255 явно в коде. Кроме того, очень плохая привычка включать в код «невидимые» специальные символы, потому что вы не можете определить, какой это символ, не копируя его во внешний инструмент! Кроме того, вам придется доверять кодировке текста файла .pas. намного лучше использовать такие константы, как #255. Еще лучше, сделай 

const
  MY_PRECIOUS_VALUE = #255;

и используйте эту константу каждый раз, когда вам это нужно.

Обновление

Согласно английской статье в Википедии о Альт-код :

Если набранный номер имеет начальный 0 (ноль), используемый набор символов Кодовая страница Windows, которая соответствует текущий язык ввода. Для большинства систем используя латинский алфавит, это Windows-1252. Для полного списка, см. кодовая страница Если номер не имеет ведущий 0 (ноль), совместимость с DOS вызывается. Используемый набор символов кодовая страница DOS для текущего язык ввода. Для систем, использующих Английский, это кодовая страница 437. Для большинство других систем, использующих латиницу алфавит, это кодовая страница 850. Для полный список, см. кодовую страницу.

Так что, если вы действительно хотите продолжить ввод кодов Alt, вам лучше набрать Alt и 0255 с начальным нулем.

3 голосов
/ 06 июня 2011

Если вы введете ALT+255, используется кодовая страница DOS; для кодовых страниц DOS 437 и 850 (одна из которых вы, вероятно, используете) # 255 - NBSP (неразрывный пробел). В Unicode NBSP составляет $ A0 (160). Это объясняет, почему вы получаете Орд 160.

1 голос
/ 06 июня 2011

Режим консоли AFAIK использует набор символов OEM Ansi.А в Delphi XE вы находитесь не в мире Ansi, а в мире UCS-2 / Unicode. 

var MyChar: char;
    MyWideChar: WideChar; 
    MyAnsiChar: AnsiChar;
begin
  MyChar := #255;
  MyWideChar := #255;
  MyAnsiChar := #255;

Первые две переменные одинаковы, то есть символ с кодом Unicode 255 = $ 00FF, так как в Delphi XE char = WideChar.Для первой страницы Unicode см. эту статью .

Но MyAnsiChar - это то, что будет отображаться на консоли после преобразования из текущей кодовой страницы в кодовую страницу консоли OEM.

В диаграмме Unicode эта $ 00FF представляет собой крошечное значение y с тремой: 

U+00FF ÿ Latin Small Letter Y with diaeresis

Под консолью вы будете использовать набор символов OEM, т.е. кодовую страницу 347 .Так что в вашем случае $ FF - это НЕ символ, а специальный код 

FF  NBSP  Non Breaking SPace

, который преобразуется в U + 00A0 при преобразовании обратно в Unicode: 

U+00A0 NBSP  Non Breaking SPace

Это очень вероятночто вы находитесь в кодовой странице Windows-1252 , поэтому обычно Delphi XE AnsiString преобразует # 255 в незначительное значение y с тремой: 

FF ÿ Latin Small Letter Y with diaeresis

Вы можете использовать низкий уровень, например CharToOemBuff Windows-функции для выполнения преобразования в или из OEM-производителя или использования OEM-типа AnsiString: 

type
  TOemString = AnsiString(437);

Во всех случаях консоль не является лучшим способом ввода акцентированного текста всовременные Windows и Unicode Delphi XE.

Использование функции InputQuery, например, должно быть безопаснее, так как она будет возвращать переменную Unicode string.;)

...