From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: community@altlinux.ru Subject: Re: [Comm] UTF-8 =?koi8-r?b?wQ==?= Master 2.2 [JT] From: Anton Kovalenko Date: Thu, 06 Mar 2003 18:20:44 +0300 In-Reply-To: <3E67503A.2020707@altlinux.ru> (Aleksey Novodvorsky's message of "Thu, 06 Mar 2003 16:42:18 +0300") Message-ID: <87isuw1pyr.fsf_-_@lenin.home> User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.2 (i386-debian-linux-gnu) References: <20030306163139.719c46fe.ivan_shmykov@mail.ru> <3E67503A.2020707@altlinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: community-admin@altlinux.ru Errors-To: community-admin@altlinux.ru X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: community@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: >>>>> Aleksey Novodvorsky writes: >> 2. поддержка bash (readline), textutils, fileutils с >> точки зрения UTF8 > Поддержка UTF-8 базовыми утилитами Unix -- большая > проблема, так как требует их серьезного концептуального > пересмотра и тщательного аудита. Мое _личное_ мнение -- > сквозной переход Unix на UTF-8 locales практически > невозможен, так как приведет к большим проблемам с > security. Это очень странно слышать. Сквозной переход на UTF-8 locales -- попросту бессмысленен. А вот корректная поддержка multibyte characters, _частным случаем_ которой является UTF-8 -- уже становится традицией. Что же касается security, -- в системе, где имена файлов case sensitive, да ещё с такой приличной кодировкой, как UTF-8 (где невозможен \000 в середине строки, где любой встретившийся символ из диапазона ascii всегда означает самого себя, где никакой ascii-символ не имеет альтернативного представления) -- непонятно, откуда возьмутся проблемы. > Ввод/вывод UTF-8 поддерживается в KDE, Gnome2, OOo, > Mozilla, большинстве программ с GUI. Это они зря. Ломают устоявшиеся и _вполне работающие_ классические иксовые решения для i18n, только для того, чтобы работать с символами "вне локального charset". Впрочем, некоторым из них простительно -- портабельность под Windows требует жертв. Вот и Tk можно за это простить. >> 3. поддержка UTF-8 в ncurses >> > Нет Это при том, что upstream всё давно оттестировано и работает. > Что касается перехода к единой (и единственной) кодировке > всей системы, А эту реплику, товарищи, мы с негодованием отметаем. От неё за версту разит .... экзистенциоа... ао... нализьмом и неверием, товарищи, в прогрессивную мощь человечества. В общем, не на тот идеал смотрите. Единая кодировка для обмена информацией между иксовыми приложениями - COMPOUND_TEXT. Единая кодировка для удобного хранения строк _внутри одного_ приложения - wchars (кстати, постулировать, что "на самом деле wchars -- это unicode", нельзя). А для utf-8 роль Единой и Единственной вовсе не подходит. Она просто частный случай в зоопарке многобайтовых кодировок. Причём один из самых простых частных случаев. P.S. Между прочим, довольно интересно наблюдать за тем, как развивается почти любой open-source проект, где одним из авторов (или контрибуторов) становится японец. У такого проекта два пути -- либо там появляется нормальная (с моей точки зрения) поддержка i18n, либо рождается "японизированный" fork, бесполезный всем остальным. Но первое бывает чаще, что не может не радовать. -- With Best /usr/bin/wishes, Anton Kovalenko /* http://kovalenko.webzone.ru */