Menu
▾
▴
phpwiki-talk
|
From: Reini U. <ru...@x-...> - 2006-08-13 17:41:47
|
[redirected to the mailing list, I hate the tracker] SourceForge.net schrieb: > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=3865587 > By: mmaci > > Hi, > > I'm interested in making a hungarian site driven by PhpWiki. But there's a > probleme: our national charset contains two additional characters to iso-8859-1, > ő and ű (the long versions of ö and ü), that is only found in iso-8859-2. > These chars are frequent in hungarian, and it's impossible to leave them or > interchange them with latin1 chars. It would real ugly. The other thing is > that I have to use these characters in WikiNames, but current version of PhpWiki > does not support it. XxxóáYyy is ready (latin1 chars are usable), but if I > change óá to ő, it fails, and square brackets does not help. The [] creates > a link, but ő and ű is viewd as & #337 ; and & #369 ; . Could You please > help me how to solve the probleme? Is it a big work to add latin2 support into > PhpWiki? Normally it should work out of the box when you define('CHARSET', 'iso-8859-2'); (or define it in the config.ini) and your php supports it (via iconv) in the pcre functions. mbstring should not be needed afaik. latin-2 is single-byte. > I promise I'll gift the project with a hu.po file if iso-8859-2 will be ok... > Now there's nothing to it. Personally I'd rather prefer a cool layout in a new template, but we accept hungarian also :) -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Mici M. <mm...@fr...> - 2006-08-14 06:28:04
|
Hi, thanks for your answer but it's not so easy. PhpWiki uses htmlspecialchars() to masq strings, and PhpWiki passes a third argument to it containing the charset name. htmlspecialchars() does not know about latin2, it gives warnings. lib/XmlElement.php...: 502: Warning: htmlspecialchars(): charset `iso-8859-2' not supported, assuming iso-8859-1 lib/XmlElement.php...: 170: Warning: htmlspecialchars(): charset `iso-8859-2' not supported, assuming iso-8859-1 These two lines (502 and 170) are giving the message but lots of times in a page request. What's wrong? May I upgrade or reconfigure php to work, or the htmlspecialchars() function needs a workaround in PhpWiki? [phpwiki-1.3.12p3] [php-4.4.2-1.1] --=20 mm. Reini Urban <ru...@x-...> =EDrta: > [redirected to the mailing list, I hate the tracker] >=20 > SourceForge.net schrieb: > > Read and respond to this message at:=20 > > https://sourceforge.net/forum/message.php?msg_id=3D3865587 > > By: mmaci > >=20 > > Hi, > >=20 > > I'm interested in making a hungarian site driven by PhpWiki. But there's a > > probleme: our national charset contains two additional characters to iso-8859-1, > > "o and "u (the long versions of =F6 and =FC), that is only found in iso-8859-2. > > These chars are frequent in hungarian, and it's impossible to leave them or > > interchange them with latin1 chars. It would real ugly. The other thing is > > that I have to use these characters in WikiNames, but current version of PhpWiki > > does not support it. Xxx=F3=E1Yyy is ready (latin1 chars are usable), but if I > > change =F3=E1 to "o, it fails, and square brackets does not help. The [] creates > > a link, but "o and "u is viewd as & #337 ; and & #369 ; . Could You please > > help me how to solve the probleme? Is it a big work to add latin2 support into > > PhpWiki? >=20 > Normally it should work out of the box when you > define('CHARSET', 'iso-8859-2'); > (or define it in the config.ini) > and your php supports it (via iconv) in the pcre functions. > mbstring should not be needed afaik. latin-2 is single-byte. >=20 > > I promise I'll gift the project with a hu.po file if iso-8859-2 will be ok... > > Now there's nothing to it. >=20 > Personally I'd rather prefer a cool layout in a new template, but we=20 > accept hungarian also :) > --=20 > Reini Urban > http://phpwiki.org/ http://murbreak.at/ > http://helsinki.at/ http://spacemovie.mur.at/ > =0A=0A______________________________________________ Dobd fel a napod, dobd fel a vide=F3id! http://videa.hu |
|
From: Reini U. <ru...@x-...> - 2006-08-14 11:13:33
|
Mici Maci schrieb: > thanks for your answer but it's not so easy. PhpWiki > uses htmlspecialchars() to masq strings, and PhpWiki > passes a third argument to it containing the charset > name. htmlspecialchars() does not know about latin2, > it gives warnings. > > lib/XmlElement.php...: 502: Warning: htmlspecialchars(): > charset `iso-8859-2' not supported, assuming iso-8859-1 > > lib/XmlElement.php...: 170: Warning: htmlspecialchars(): > charset `iso-8859-2' not supported, assuming iso-8859-1 > > These two lines (502 and 170) are giving the message > but lots of times in a page request. What's wrong? May > I upgrade or reconfigure php to work, or the > htmlspecialchars() function needs a workaround in > PhpWiki? > > [phpwiki-1.3.12p3] > [php-4.4.2-1.1] Oje! http://www.mantisbt.org/mantis/bug_view_page.php?bug_id=6624 So you have to convert to UTF-8 and bite into the bullet. Note, that UTF-8 is not officially supported and not included. I posted a patch to the sf.net patch area, which should get around most issues. But since UTF-8 strings are asciiz-safe it is not so harmful to work without proper UTF-8 support in all string functions. (preg_match, strlen, ...) -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Reini U. <ru...@x-...> - 2006-08-14 11:23:53
|
Reini Urban schrieb: > Mici Maci schrieb: >> thanks for your answer but it's not so easy. PhpWiki >> uses htmlspecialchars() to masq strings, and PhpWiki >> passes a third argument to it containing the charset >> name. htmlspecialchars() does not know about latin2, >> it gives warnings. >> >> lib/XmlElement.php...: 502: Warning: htmlspecialchars(): >> charset `iso-8859-2' not supported, assuming iso-8859-1 >> >> lib/XmlElement.php...: 170: Warning: htmlspecialchars(): >> charset `iso-8859-2' not supported, assuming iso-8859-1 >> >> These two lines (502 and 170) are giving the message >> but lots of times in a page request. What's wrong? May >> I upgrade or reconfigure php to work, or the >> htmlspecialchars() function needs a workaround in >> PhpWiki? >> >> [phpwiki-1.3.12p3] >> [php-4.4.2-1.1] > > Oje! > http://www.mantisbt.org/mantis/bug_view_page.php?bug_id=6624 > > So you have to convert to UTF-8 and bite into the bullet. > Note, that UTF-8 is not officially supported and not included. > > I posted a patch to the sf.net patch area, which should get around most > issues. But since UTF-8 strings are asciiz-safe it is not so harmful to > work without proper UTF-8 support in all string functions. (preg_match, > strlen, ...) BTW: If you do have mbstring loaded in your php it's very easy. Simply set mb_internal_encoding('UTF-8'); somewhere ("lib/config.ini") and set mbstring.func_overload in the php.ini or .htaccess to 7 .htaccess: php_value mbstring.func_overload 7 The hugepatch comes from the fact, that not all servers support mbstring and strlen's are different in UTF-8 land. We do support now, input from UTF-8 land (e.g. MS IE), but convert this input to our charset. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Mici M. <mm...@fr...> - 2006-08-14 16:56:46
|
Hi, I tried to set the CHARSET in the config.ini to 1) utf-8=20 2) iso-8859-2 The 1) gone wrong because of a failed sql select. [There's a mysql in the background.] the sql query string should not contain utf encoded characters. The number 2) was wrong because htmlspecialchars... So I wrote a htmlspecialchars_workaround() function, that checks the third argument (which is the requested charset), and if it's 8859-2, it makes a few simple string replacement. [<, > and & is enough to replace to "<", ">" and "&"...] It calls the original htmlspecialchars in other cases. Now I can use iso-8859-2 in the config.ini, and Wiki seems to work. Of course I have had to append _workaround to all occurances os htmlspecialchars in the original code. Brrrr! Ugly and impossible to maintenance but maybe works... It's under testing now. 8-) Why don't use PhpWiki developers their own html escaper function?? htmlspecialchars() has more disadvatages than advantages, because it keeps the usable character set small, so excludes lots of people from lots of nations to join the project... mm. Reini Urban <ru...@x-...> =EDrta: > Reini Urban schrieb: > > Mici Maci schrieb: > >> thanks for your answer but it's not so easy. PhpWiki > >> uses htmlspecialchars() to masq strings, and PhpWiki > >> passes a third argument to it containing the charset > >> name. htmlspecialchars() does not know about latin2, > >> it gives warnings. > >> > >> lib/XmlElement.php...: 502: Warning: htmlspecialchars(): > >> charset `iso-8859-2' not supported, assuming iso-8859-1 > >> > >> lib/XmlElement.php...: 170: Warning: htmlspecialchars(): > >> charset `iso-8859-2' not supported, assuming iso-8859-1 > >> > >> These two lines (502 and 170) are giving the message > >> but lots of times in a page request. What's wrong? May > >> I upgrade or reconfigure php to work, or the > >> htmlspecialchars() function needs a workaround in > >> PhpWiki? > >> > >> [phpwiki-1.3.12p3] > >> [php-4.4.2-1.1] > >=20 > > Oje! > > http://www.mantisbt.org/mantis/bug_view_page.php?bug_id=3D6624 > >=20 > > So you have to convert to UTF-8 and bite into the bullet. > > Note, that UTF-8 is not officially supported and not included. > >=20 > > I posted a patch to the sf.net patch area, which should get around most=20 > > issues. But since UTF-8 strings are asciiz-safe it is not so harmful to=20 > > work without proper UTF-8 support in all string functions. (preg_match,=20 > > strlen, ...) >=20 > BTW: If you do have mbstring loaded in your php it's very easy. > Simply set > mb_internal_encoding('UTF-8'); > somewhere ("lib/config.ini") and set >=20 > mbstring.func_overload in the php.ini or .htaccess to 7 >=20 > .htaccess: > php_value mbstring.func_overload 7 >=20 > The hugepatch comes from the fact, that not all servers support mbstring=20 > and strlen's are different in UTF-8 land. > We do support now, input from UTF-8 land (e.g. MS IE), but convert this=20 > input to our charset. > --=20 > Reini Urban > http://phpwiki.org/ http://murbreak.at/ > http://helsinki.at/ http://spacemovie.mur.at/ >=20 > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1= 21642 > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > =0A=0A________________________________________________________________ Iratkozzon fel szakmai h=EDrlevel=FCnkre =E9s nyerje meg =D6n a 3 db k=E9ny= eztet=F5 wellness h=E9tv=E9ge egyik=E9t! kattintson ide: http://www.dashofer.hu/origo/?wa=3DCEMORI0632 |
|
From: Reini U. <ru...@x-...> - 2006-08-14 22:42:18
|
Mici Maci schrieb: > I tried to set the CHARSET in the config.ini to > 1) utf-8 > 2) iso-8859-2 > The 1) gone wrong because of a failed sql select. > [There's a mysql in the background.] the sql query > string should not contain utf encoded characters. of course you have to tell your database to accept utf-8. ALTER TABLE page DEFAULT CHARACTER SET utf8_general_ci; ALTER TABLE version DEFAULT CHARACTER SET utf8_general_ci; ALTER TABLE session DEFAULT CHARACTER SET utf8_general_ci; what we just do is telling the client talking to the database which charset we use for the transport. config.ini: CHARSET=UTF-8 => PearDB_mysql.php: SET NAMES 'utf8'; http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html > The number 2) was wrong because htmlspecialchars... So I > wrote a htmlspecialchars_workaround() function, that > checks the third argument (which is the requested charset), > and if it's 8859-2, it makes a few simple string replacement. > [<, > and & is enough to replace to "<", ">" and > "&"...] > It calls the original htmlspecialchars in other cases. > Now I can use iso-8859-2 in the config.ini, and Wiki > seems to work. Of course I have had to append > _workaround to all occurances os htmlspecialchars > in the original code. Brrrr! Ugly and impossible to > maintenance but maybe works... It's under testing > now. 8-) Well, why not. "_workaround" might be a bit too long though. > Why don't use PhpWiki developers their own html > escaper function?? htmlspecialchars() has more > disadvatages than advantages, because it keeps > the usable character set small, so excludes lots > of people from lots of nations to join the project... because you are the first with such an exotic eastern charset (czech and polish also) which is not supported by such a basic function. that tells us, that we seriously lack a lot of users. of course we accept any workaround function. > Reini Urban <ru...@x-...> írta: > >> Reini Urban schrieb: >>> Mici Maci schrieb: >>>> thanks for your answer but it's not so easy. PhpWiki >>>> uses htmlspecialchars() to masq strings, and PhpWiki >>>> passes a third argument to it containing the charset >>>> name. htmlspecialchars() does not know about latin2, >>>> it gives warnings. >>>> >>>> lib/XmlElement.php...: 502: Warning: htmlspecialchars(): >>>> charset `iso-8859-2' not supported, assuming iso-8859-1 >>>> >>>> lib/XmlElement.php...: 170: Warning: htmlspecialchars(): >>>> charset `iso-8859-2' not supported, assuming iso-8859-1 >>>> >>>> These two lines (502 and 170) are giving the message >>>> but lots of times in a page request. What's wrong? May >>>> I upgrade or reconfigure php to work, or the >>>> htmlspecialchars() function needs a workaround in >>>> PhpWiki? >>>> >>>> [phpwiki-1.3.12p3] >>>> [php-4.4.2-1.1] >>> Oje! >>> http://www.mantisbt.org/mantis/bug_view_page.php?bug_id=6624 >>> >>> So you have to convert to UTF-8 and bite into the bullet. >>> Note, that UTF-8 is not officially supported and not > included. >>> I posted a patch to the sf.net patch area, which should > get around most >>> issues. But since UTF-8 strings are asciiz-safe it is > not so harmful to >>> work without proper UTF-8 support in all string > functions. (preg_match, >>> strlen, ...) >> BTW: If you do have mbstring loaded in your php it's very > easy. >> Simply set >> mb_internal_encoding('UTF-8'); >> somewhere ("lib/config.ini") and set >> >> mbstring.func_overload in the php.ini or .htaccess to 7 >> >> .htaccess: >> php_value mbstring.func_overload 7 >> >> The hugepatch comes from the fact, that not all servers > support mbstring >> and strlen's are different in UTF-8 land. >> We do support now, input from UTF-8 land (e.g. MS IE), but > convert this >> input to our charset. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Mici M. <mm...@fr...> - 2006-08-15 11:15:07
|
Hi,
> of course we accept any workaround function.
You're welcome to rename it! :)
<?php function htmlspecialchars_workaround($str, $quote =3D
ENT_COMPAT, $charset =3D 'iso-8859-1') {
if (in_array(strtolower($charset),
array('iso-8859-2', 'iso8859-2', 'latin-2', 'latin2'))) {
if (! ($quote & ENT_NOQUOTES)) {
$str =3D str_replace("\"", """,
$str);
}
if ($quote & ENT_QUOTES) {
$str =3D str_replace("\'", "'",
$str);
}
return str_replace(array("<", ">", "&"),
array("<", ">", "&"), $str);
}
else {
return htmlspecialchars($str, $quote, $charset);
}
} ?>
Why is it enough to simply replace <, > and &? Because
8859-2 is an 8 bit wide encoding, so each byte is a single
char, and each str*() function is applicable on it. If you
replace these three chars to < > and &, all other
latin2 characters will be ready to display in an HTML
document using charset=3Diso-8859-2. No one else can
hide or modify the meaning of the chars than the <, >
and & signs.
mm.
=0A=0A_____________________________________________________________________=
__
FOTO.hu - Online fot=F3rendel=E9s kidolgoz=E1s. Folyamatos Akci=F3k! Kiv=E1=
l=F3 min=F5s=E9g! Ingyen h=E1zhoz sz=E1ll=EDt=E1s!=20
R=E9szletek=E9rt kattintson ide: http://www.foto.hu/index.php?zoneid=3Dorig=
o2=20
|
|
From: Reini U. <ru...@x-...> - 2006-08-15 11:47:28
|
Mici Maci schrieb: > Hi, >> of course we accept any workaround function. > You're welcome to rename it! :) > <?php function htmlspecialchars_workaround($str, $quote = Ok. Now how to handle this best? We need this only on certain charsets, which php upstream doesn't support, because they prefer utf-8. And we need it only for htmlspecialchars. rurban@reini /usr/src/php/phpwiki-dev/phpwiki $ grep -Rl htmlspecialchars . ./configurator.php ./lib/nusoap/nusoap.php ./lib/plugin/TexToPng.php ./lib/WikiDB/adodb/adodb-lib.inc.php ./lib/WikiDB/adodb/adodb.inc.php ./lib/WikiDB/adodb/drivers/adodb-csv.inc.php ./lib/WikiDB/backend/file.php ./lib/WikiDB/backend/flatfile.php ./lib/WikiPluginCached.php ./lib/XmlElement.php ./lib/XMLRPC/xmlrpc.inc ./lib/XmlRpcServer.php rurban@reini /usr/src/php/phpwiki-dev/phpwiki $ grep -Rl htmlentities . ./configurator.php ./doc/README.foaf ./lib/HttpClient.php ./lib/pear/DB/storage.php ./lib/plugin/ModeratedPage.php ./lib/plugin/WikiFormRich.php ./lib/XMLRPC/xmlrpc.inc ./passencrypt.php ./themes/default/templates/login.tmpl ./themes/default/templates/online.tmpl So we have some external libs also. We also could simply catch the warning and omit it. It's only the stupid warning, isn't it, or is there functionality missing also? And there're a lot of unsupported charsets. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
|
From: Reini U. <ru...@x-...> - 2006-08-15 12:18:22
|
Reini Urban schrieb:
> Mici Maci schrieb:
>> Hi,
>>> of course we accept any workaround function.
>> You're welcome to rename it! :)
>> <?php function htmlspecialchars_workaround($str, $quote =
>
> Ok. Now how to handle this best?
> We need this only on certain charsets, which php upstream doesn't
> support, because they prefer utf-8.
> And we need it only for htmlspecialchars.
>
> rurban@reini /usr/src/php/phpwiki-dev/phpwiki
> $ grep -Rl htmlspecialchars .
> ./configurator.php
> ./lib/nusoap/nusoap.php
> ./lib/plugin/TexToPng.php
> ./lib/WikiDB/adodb/adodb-lib.inc.php
> ./lib/WikiDB/adodb/adodb.inc.php
> ./lib/WikiDB/adodb/drivers/adodb-csv.inc.php
> ./lib/WikiDB/backend/file.php
> ./lib/WikiDB/backend/flatfile.php
> ./lib/WikiPluginCached.php
> ./lib/XmlElement.php
> ./lib/XMLRPC/xmlrpc.inc
> ./lib/XmlRpcServer.php
>
> rurban@reini /usr/src/php/phpwiki-dev/phpwiki
> $ grep -Rl htmlentities .
> ./configurator.php
> ./doc/README.foaf
> ./lib/HttpClient.php
> ./lib/pear/DB/storage.php
> ./lib/plugin/ModeratedPage.php
> ./lib/plugin/WikiFormRich.php
> ./lib/XMLRPC/xmlrpc.inc
> ./passencrypt.php
> ./themes/default/templates/login.tmpl
> ./themes/default/templates/online.tmpl
>
> So we have some external libs also.
>
> We also could simply catch the warning and omit it.
> It's only the stupid warning, isn't it, or is there functionality
> missing also? And there're a lot of unsupported charsets.
I've just looked into the php source and found that this warning can be
safely ignored by our error hook as already done somewhere else.
This is much easier than replacing all the htmlspecialchars occurences.
Most exotic charsets are not supported by htmlspecialchars, which just
prints a E_WARNING.
Even on simple 8bit charsets, where just <>& need to be replaced.
See <php-src>/ext/standard/html.c
Supported charsets are:
{ "ISO-8859-1", cs_8859_1 },
{ "ISO8859-1", cs_8859_1 },
{ "ISO-8859-15", cs_8859_15 },
{ "ISO8859-15", cs_8859_15 },
{ "utf-8", cs_utf_8 },
{ "cp1252", cs_cp1252 },
{ "Windows-1252", cs_cp1252 },
{ "1252", cs_cp1252 },
{ "BIG5", cs_big5 },
{ "950", cs_big5 },
{ "GB2312", cs_gb2312 },
{ "936", cs_gb2312 },
{ "BIG5-HKSCS", cs_big5hkscs },
{ "Shift_JIS", cs_sjis },
{ "SJIS", cs_sjis },
{ "932", cs_sjis },
{ "EUCJP", cs_eucjp },
{ "EUC-JP", cs_eucjp },
{ "KOI8-R", cs_koi8r },
{ "koi8-ru", cs_koi8r },
{ "koi8r", cs_koi8r },
{ "cp1251", cs_cp1251 },
{ "Windows-1251", cs_cp1251 },
{ "win-1251", cs_cp1251 },
{ "iso8859-5", cs_8859_5 },
{ "iso-8859-5", cs_8859_5 },
{ "cp866", cs_cp866 },
{ "866", cs_cp866 },
{ "ibm866", cs_cp866 },
/* now walk the charset map and look for the codeset */
...
if (!found) {
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"charset `%s' not supported, assuming iso-8859-1",
charset_hint);
}
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
http://helsinki.at/ http://spacemovie.mur.at/
|
|
From: Reini U. <ru...@x-...> - 2006-08-15 12:43:55
|
Reini Urban schrieb:
>> We also could simply catch the warning and omit it.
>> It's only the stupid warning, isn't it, or is there functionality
>> missing also? And there're a lot of unsupported charsets.
>
> I've just looked into the php source and found that this warning can be
> safely ignored by our error hook as already done somewhere else.
> This is much easier than replacing all the htmlspecialchars occurences.
Ok, this works:
lib/IniConfig.php:
function _unknown_charset_warning($error) {
if (preg_match('/^charset \`.+\' not supported, assuming iso-8859-1/',
$error->errstr))
return true; // Ignore error
return false;
}
and inside fixup_static_configs() after $charset = CHARSET;
if (defined('IGNORE_CHARSET_NOT_SUPPORTED_WARNING') and
IGNORE_CHARSET_NOT_SUPPORTED_WARNING) {
global $ErrorManager;
$ErrorManager->pushErrorHandler(new
WikiFunctionCb('_unknown_charset_warning'));
}
Now put in config.ini for all charsets not listed below the lines:
; Most exotic charsets are not supported by htmlspecialchars, which
prints a warning:
; "charset `bla' not supported, assuming iso-8859-1"
; Even on simple 8bit charsets, where just <>& need to be replaced.
; See <php-src>/ext/standard/html.c
; We can ignore these warnings then.
IGNORE_CHARSET_NOT_SUPPORTED_WARNING = true
> Most exotic charsets are not supported by htmlspecialchars, which just
> prints a E_WARNING.
> Even on simple 8bit charsets, where just <>& need to be replaced.
> See <php-src>/ext/standard/html.c
>
> Supported charsets are:
> { "ISO-8859-1", cs_8859_1 },
> { "ISO8859-1", cs_8859_1 },
> { "ISO-8859-15", cs_8859_15 },
> { "ISO8859-15", cs_8859_15 },
> { "utf-8", cs_utf_8 },
> { "cp1252", cs_cp1252 },
> { "Windows-1252", cs_cp1252 },
> { "1252", cs_cp1252 },
> { "BIG5", cs_big5 },
> { "950", cs_big5 },
> { "GB2312", cs_gb2312 },
> { "936", cs_gb2312 },
> { "BIG5-HKSCS", cs_big5hkscs },
> { "Shift_JIS", cs_sjis },
> { "SJIS", cs_sjis },
> { "932", cs_sjis },
> { "EUCJP", cs_eucjp },
> { "EUC-JP", cs_eucjp },
> { "KOI8-R", cs_koi8r },
> { "koi8-ru", cs_koi8r },
> { "koi8r", cs_koi8r },
> { "cp1251", cs_cp1251 },
> { "Windows-1251", cs_cp1251 },
> { "win-1251", cs_cp1251 },
> { "iso8859-5", cs_8859_5 },
> { "iso-8859-5", cs_8859_5 },
> { "cp866", cs_cp866 },
> { "866", cs_cp866 },
> { "ibm866", cs_cp866 },
|
|
From: Mici M. <mm...@fr...> - 2006-08-15 12:56:40
|
> We also could simply catch the warning and omit it. > It's only the stupid warning, isn't it, or is there functionality=20 > missing also? Simply omitting the warning is not a good idea. There's no missing functionality in htmlspecialchars, the boot is on the wrong leg: it replaces =F5 and =FB with &#xxx; type encodings. Imagine that you store a WikiPage in hungarian, that contains an =F5 character. If you click on the edit button, Wiki gives you back a text for editing containing &#nnn; replacements... The htmlspecialchars() makes unneeded replacements when it treats latin2 as latin1. Very frustrating. =0A=0A_____________________________________________________________________= __ FOTO.hu - Online fot=F3rendel=E9s kidolgoz=E1s. Folyamatos Akci=F3k! Kiv=E1= l=F3 min=F5s=E9g! Ingyen h=E1zhoz sz=E1ll=EDt=E1s!=20 R=E9szletek=E9rt kattintson ide: http://www.foto.hu/index.php?zoneid=3Dorig= o2=20 |
|
From: Reini U. <ru...@x-...> - 2006-08-15 13:52:00
|
Mici Maci schrieb: >> We also could simply catch the warning and omit it. >> It's only the stupid warning, isn't it, or is there > functionality >> missing also? > > Simply omitting the warning is not a good idea. There's > no missing functionality in htmlspecialchars, the boot is > on the wrong leg: it replaces ő and ű with &#xxx; type > encodings. Imagine that you store a WikiPage in > hungarian, that contains an ő character. If you click > on the edit button, Wiki gives you back a text for > editing containing &#nnn; replacements... The > htmlspecialchars() makes unneeded replacements > when it treats latin2 as latin1. Very frustrating. Sorry, cannot reproduce. The link to Hungarianőpage is still Hungarianőpage and editing introduces no escaped ő I even checked in the code the support hungarian, more unsupported charsets, into CVS. your workaround functions does the same as the php function htmlspecialchars(), php just prints the warning. With entities it's different, but there are no iso-8591-2 entities to my knowledge. So I'm waiting for your po :) Hopefully some pgsrc also. But even better some fresh and cooler layout. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X