Как взорвать эту строку в подстроки? - PullRequest
1 голос
/ 30 августа 2009

Рассмотрим этот пример:

zh_Hant_HK format = yy'年'M'月'd'日' ah:mm

Не уверен, что вы видите это, но я вижу там много китайских символов. Я получил эту строку из средства форматирования даты, которое соответствует азиатскому языку. Должен ли я учитывать что-то особенное при попытке получить «символ» по «символу», то есть смотреть на каждый символ отдельно в этой строке?

Ответы [ 3 ]

1 голос
/ 02 сентября 2009

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

for(int index = 0; index < [myString length]; index++) {
    unichar ch = [myString characterAtIndex:index];
    // Do stuff to unichar...
}

Одна вещь, которую вы должны сделать, это всегда обращаться с символом, который вы извлекаете из NSString, как тип unichar. Тип unichar не эквивалентен wchar_t или любому другому типу символов Юникода.

0 голосов
/ 31 августа 2009

Если ваша строка знает о кодировке (что должно быть, если она извлечена из форматирования даты), тогда вы можете просто получить представление unichar, используя characterAtIndex: , или как вы хотите получить доступ к символы.

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

0 голосов
/ 30 августа 2009

Зависит от представления строки.

Когда-то у нас были простые строковые представления (например, ASCII), в которых все коды символов занимали одну единицу пространства в строке (8 битов, игнорируя самый верхний). [Ранее были строковые представления из 6 и 9 битов, но они имели то же свойство единиц фиксированного размера).

Обработка неанглийских языков (Восточная Европа, Азия, ...) заставляла людей предлагать различные виды так называемых «двухбайтовых символьных строк» ​​(DBCS), в которых обычные символы занимали одну единицу (довольно почти такой же набор, как и символы ASCII), теперь почти повсеместно 8 бит, но остальные символы кодируются как два байта, первый из которых занимает часть 8-битного пространства, которое не требуется ASCII, и второй байт, предоставляя схема кодирования символов, ~~ 15-битные символы.

Разрыв таких строк беспорядочный, потому что подпрограмма, которая делает это, должна понимать точную схему кодирования DBCS и собирать 1 или 2 байта за раз в соответствии.

Вместе с Unicode, чтобы решить проблему, предоставив 16-битные символы. Большинство современных языков программирования (Java, C #) предоставляют эти 16-битные символы в качестве основы для своих строковых представлений. Жизнь стала намного проще (если мы игнорируем тот факт, что даже 16-битный юникод иногда позволяет составить два последовательных символа для формирования того, что равно другому символу, уже определенному в наборе).

Комитет, который улучшает Unicode, однако, не смог устоять и расширил Unicode за пределы 16 бит. Теперь мы застряли в тупой схеме DBCS (на самом деле хуже, некоторые занимают несколько байтов, IIRC), которую Unicode должен был исправить. Итак, для обработки строк в тех современные языки, вы снова должны понять, когда байт представляет отдельный символ, и когда он представляет вводную последовательность из нескольких символов.

Если вам повезет, строка, которую вы имеете, состоит только из 16-битных одиночных символов в Unicode. Если нет, вам нужно обратиться к руководству по Unicode и помолиться, чтобы у вас была библиотека управления строками Unicode, чтобы помочь вам сделать это правильно.

Этот последний бит - такая колоссальная стычка, что многие кодеры бьют и придерживаются символов Unicode-as-single-wide. Работает в Европе. Не рекомендуется в Азии.

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