[quote="lvd"][quote="Anonymous"]а FGetC? А ей-то откуда знать, UTF8 это файл, или там UTF16 или UNICODE Big Endian 32bit?
Допустим там у нас в файле в формате UTF8 лежит буква Б. тогда вызовы FGetC вернут последовательно коды $D0, $A1 Что соответствует символу #$401 Unicode - букве Б Эти два символа любая нормальная программя потом либо выдаст на консоль (пропатченую) которая буковку Б и выведет, либо пошлет на graphics.library->Text которая тоже пропатчена. Ну а если программа сама решит что-нибудь вывести, то незнаю.
Дополнительно надо пропатчить классы ввода строк, для верного перемещения курсора.
и все вроде. Мне интересно, нужно/хочется это еще кому-нибудь кроме меня.[/quote]
Ну хорошо, допустим FGetC ничего не знает про utf8 или unicode или как её там. И при чтении из Input() тебе падают уникодные 2байтовые символы. А как, спрашивается, эти 2байтовые символы будут обрабатываться всем тем абсолютным большиством прог, которые про твой уникод не знают и не желают знать? backward compability однако не выходит, если всё пропатчить
[/quote]
скорей ты патчем этим программы, работающие не с текстовыми файлами с толку собъешь.
А как ты его "абсолютное большинство прог" его обрабатывать будут собственно? максимум где предвижу глюки, так это в текстовых редакторах и графических (инструмент "текст"). Остальные программы максимум, что с этим текстом сделать могут, так это отсортировать строки, а это даже стандартными сишными функциями правильно делается.
Скажем так: а нужно ли "абсолютному большинству прог" знать, что это ОДИН ПЕЧАТАЕМЫЙ СИМВОЛ"? в остальном UTF-8 ничем от любой другой строки не отличается. большинство программ будут работать правильно не по задумке автора программы, а из-за некоей предусмотрительности авторов utf-8
кстати соотношение 1байт-1символ даже в стандартных кодировках не удовлетворяется. (esc-коды например,tab) Например штатный more ничего ни о esc, ни о tab не знает, и при этом нормально работает.
кстати UTF-8 может отражать один символ последовательностью до 6 байт.
для кодирования символов с кодами больше 128 кодируется последовательностями байт с кодами 128-253. а меньшие 128 - один в один (возможен лишь конфликт с кодом CSI-$9B) я уже говорил о том, что неверную utf8-последовательность можно интерпретировать код-в-код.
насчет кодов 128-160 (вторая область управляющих кодов) - вроде как-то жила на амиге кодировка cp866 aka dos aka oem, и глюков было вроде немного.
подойдя с другой стороны, можно представить utf-8 коды как нечто вроде esc-последовательностей в тексте для переключения кодировок.
зы. приведи возможный глюк.
ззы. Кто-нибудь, приведите мне пример исходника какого-нибудь патча! чтобы понять как патчи делать! да что говорить, пробовать надо.
