Ключевые слова:unicode, (найти похожие документы)
Date: Wed, 31 Dec 2003 19:03:47 +0500
From: Valentin Nechayev <[email protected]>
Newsgroups: ftn.ru.unix.prog
Subject: Программирование и utf-8
SL> $subj - в разрезе программизма. Интересуют меня совершенно тупые
SL> вопросы, как то : чему равен sizeof(char) ;
Единице - по определению. utf-8 - случай так называемой многобайтовой
кодировки, а не кодировки в каком-нибудь wchar_t.
SL> нужен ли для этого режима
SL> держать отдельный компилер ;
Hет. По крайней мере пока ты не хочешь от компилятора, чтобы он воспринимал
в тексте программы строковые константы в локальной кодировке, а писал
уже в utf-8.
В utf-8, представление символов 0-127 идентично таковому в ascii.
SL> как писать программулю, работающую и в кои8
SL> и в утф-8,
1. Использовать конвертер (например, iconv()) для преобразования между
кодировками.
2. Программа должна быть рассчитана на различение понятий длины текста
в символах принятой кодировки и длины текста в char'ах (эту длину выдаёт
strlen()). Hапример, для последовательности русских букв второе
больше первого ровно в 2 раза.
3. Программа должна быть рассчитана на то, что не все символы являются
печатными; на то, что некоторые - модифицируют стоящие после них печатные
символы.
4. Программа должна быть рассчитана на то, что переход к следующему или
предыдущему символу в строке достигается не простым инкрементом/декрементом,
а более сложными средствами. В винде, например, они были оформлены отдельными
функциями (AnsiNext() и AnsiPrev()), под юниксами я что-то такого не вижу.
К тому же, поиск предыдущего символа может требовать скана с начала строки.
Это и для utf-8 справедливо, потому что отрывать модифицирующие dead chars
от последующих модифицируемых символов вредно для конечного результата.
SL> и тому подобное. Чтоб по одному эти вопросы не задавать - дайте
SL> урку, плиииииизззз :)
Ой не знаю. Сходи на www.unicode.org, может, найдётся правильный туториал.
Главное - учитывай, что utf-8 - только один из форматов передачи
последовательности символов юникода, и часть проблем (например, те же
dead chars) - свойство юникода вообще, а часть (многобайтные символы
переменной длины) - свойство транспортного формата.
From: Valentin Nechayev <[email protected]>
VN>> 4. Программа должна быть рассчитана на то, что переход к следующему
VN>> или предыдущему символу в строке достигается не простым
VN>> инкрементом/декрементом, а более сложными средствами. В винде,
VN>> например, они были оформлены отдельными функциями (AnsiNext() и
VN>> AnsiPrev()), под юниксами я что-то такого не вижу. К тому же,
VN>> поиск предыдущего символа может требовать скана с начала строки.
VN>> Это и для utf-8 справедливо, потому что отрывать модифицирующие
VN>> dead chars от последующих модифицируемых символов вредно для
VN>> конечного результата.
AC> Ой, а то не существует более аккуратного способа найти все dead chars,
AC> относящиеся к предыдущему символу, нежели скан с начала строки...
Я криво выразился. Имелось в виду, что надо знать адрес начала строки и
учитывать его при заглядываниях назад.
