[CGI] MyDbEntries group listing: No shortname Really [NOBUG]

bbaab · Post by **bbaab** » Fri Jan 09, 2004 9:30 am

Well ...

Obviously, the "Knights" don't need a short name as such. Still, the entry I made - http://anidb.ath.cx/perl-bin/animedb.pl ... up&gid=653 - has "Knights" listed both as the full and as the short name for this group. How can this be a lame entry?

Post by **exp** » Fri Jan 09, 2004 12:00 pm

Having fullname = shortname is considered lame by the anidb scripts.
This is mainly done this way bc many ppl used to add groups with just their shorttitle or just their maintitle and often added that value in both fields.

BYe!
EXP

bbaab · Post by **bbaab** » Fri Jan 09, 2004 12:55 pm

exp wrote:Having fullname = shortname is considered lame by the anidb scripts.

Oh, well. Changing the fullname to "Knight<ZERO WIDTH SPACE>s" seems to work around this problem.

Thanks for the explanation.

wahaha · Post by **wahaha** » Fri Jan 09, 2004 1:38 pm

bbaab wrote:Oh, well. Changing the fullname to "Knight<ZERO WIDTH SPACE>s" seems to work around this problem.

Changed back, as it doesn't work well with Chii (and would most likely affect AoM aswell).

Please just ignore the lameness-warning (of which I have several myself) - it doesn't do any harm after all.

bbaab · Post by **bbaab** » Fri Jan 09, 2004 2:02 pm

wahaha wrote:
bbaab wrote:Oh, well. Changing the fullname to "Knight<ZERO WIDTH SPACE>s" seems to work around this problem.
Changed back, as it doesn't work well with Chii (and would most likely affect AoM aswell).

There goes my Unicode-fu.

No idea about AoM, but if Chii is written in Perl or C on a Unix system, I could write a few simple conversion routines. I had to write them anyway, due to the damn IDN in .com, .net and soon .de ...

wahaha · Post by **wahaha** » Fri Jan 09, 2004 2:35 pm

bbaab wrote:No idea about AoM, but if Chii is written in Perl or C on a Unix system, I could write a few simple conversion routines. I could write a few simple conversion routines.

*cough*
Don't you think that it's somewhat overkill making Chii Unicode-aware mainly to recognize a workaround for the webinterface with the only purpose to make one line of text disappear*? ^^;

*) And change the overall-values at the bottom

bbaab · Post by **bbaab** » Fri Jan 09, 2004 3:04 pm

wahaha wrote:
bbaab wrote:No idea about AoM, but if Chii is written in Perl or C on a Unix system, I could write a few simple conversion routines. I could write a few simple conversion routines.
*cough*
Don't you think that it's somewhat overkill making Chii Unicode-aware mainly to recognize a workaround for the webinterface with the only purpose to make one line of text disappear? ^^;

Well, yeah, but I don't think it's overkill to make Chii Unicode-aware.

Post by **exp** » Fri Jan 09, 2004 3:32 pm

all non-ascii chars will be removed from anidb anyway, someday.
i've just been too lazy to do it :P

the cgi will also convert any non-ascii character to "_" (again, not yet)

so there's really no point in making chii unicode aware }:o)

BYe!
EXP

bbaab · Post by **bbaab** » Fri Jan 09, 2004 9:49 pm

exp wrote:all non-ascii chars will be removed from anidb anyway, someday.
i've just been too lazy to do it

the cgi will also convert any non-ascii character to "_" (again, not yet)

so there's really no point in making chii unicode aware }:o)

Well, ok, it's your site, of course you can do whatever you please ... still, I'd think that names like "DNA_" or "Kiki_s Delivery Service" just might confuse someone ...

Elberet · Post by **Elberet** » Sun Jan 11, 2004 4:36 am

Since when are ² and ' not ASCII?

bbaab · Post by **bbaab** » Sun Jan 11, 2004 11:15 am

Elberet wrote:Since when are ² and ' not ASCII?

Since pretty much always.

ASCII covers the address range 32-127 (it's only 7 bit wide, after all). ² and ´ (which gets frequently used instead of ') aren't in it. They're at code positions 178 and 180 in Unicode, for example.

Post by **exp** » Sun Jan 11, 2004 11:24 am

The char replacement is depending on the chars.
Some non-ascii chars have a given ascii equivalent which will be used.

i.e.
ä => ae
ö => oe
ü => ue
ß => ss
² => ^2
´ => `
à => a
...

only chars for which no replacement has been added will be replaced by _

BYe!
EXP

Elberet · Post by **Elberet** » Sun Jan 11, 2004 2:45 pm

I didn't realize exp wants to convert everything into 7-bit ASCII. The characters between 128 and 255, which include the German "Umlaut" characters (ä, ö, ü...) as well as most accentuated vowels (á, à, â), are part of extended ASCII, so it's by no means necessary to use unicode, encoding or doublebyte chars to work with these.

Just out of curiousity... what's the reason why the AniDB clients can't work with characters >127? Java and .NET are aware of unicode, C, C++ and Delphi don't care about the byte value of a single byte character, and all extended ASCII chars except 255 are printable on a non-broken terminal.

Post by **exp** » Sun Jan 11, 2004 6:35 pm

well,

the main cause for it is that switching to full unicode doesn't work bc there are a lot of places where it would lead to problems and that the current way of handling things prevents the java jdbc driver for postgres from accessing the database it doesn't expect >127 chars in an SQL_ASCII database.
this is not that much of a problem atm bc i didn't have the time to finish the java implementation of the anidb api. and i prolly won't finish it any time soon.
as long as i only access the animedb database from perl i have no problem with 8-bit ascii.

BYe!
EXP