View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001968 | AniDB UDP API | Bug Report | public | 2012-01-04 16:13 | 2012-02-20 10:54 |
| Reporter | himself | Assigned To | Ommina | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001968: Unicode doesn't seem to work | ||||
| Description | Maybe I'm doing something wrong but here's what I'm getting: 1. In any encoding, sequences like "〹" don't work. They are treated literally (result: "&12345;") On the other hand, "&" works. 2. When using enc=utf8 and sending UTF8 encoded japanese characters, AniDB converts and stores those as 〹 (visible as such) while through web interface Unicode symbols are stored as they are. 3. (unrelated but minor) UDP API docs say that "parameters use form encoding", but as far as I understand form encoding is "%35%32%49" not "〹". | ||||
| Steps To Reproduce | AUTH [...]&enc=utf8 MYLIST EDIT [...]&storage=test???&storageテ Result: testテスト&storageテ | ||||
| Tags | No tags attached. | ||||
|
|
Well damn. It ate all the special markup. Let's try again: 1. In any encoding, sequences like "〹" don't work. They are treated literally (result: "〹") On the other hand, "&" works. 2. When using enc=utf8 and sending UTF8 encoded japanese characters, AniDB converts and stores those as 〹 (visible as such) while through web interface Unicode symbols are stored as they are. 3. (unrelated but minor) UDP API docs say that "parameters use form encoding", but as far as I understand form encoding is "%35%32%49" not "〹". Steps To Reproduce AUTH [...]&enc=utf8 MYLIST EDIT [...]&storage=test???&storageテ Result: testテスト&storageテ |
|
|
I'm not following. You want to send "テ" and have it converted to (katakana te - this is getting silly) by the API ? If you're using UTF8, why not just send te and be done with it, instead of an HTML representation? Is it not accepting the kana ? |
|
|
Initially I was sending in ANSI. But neither html form, nor just html encoding were being parsed (only & worked) So I gave up and switched to UTF8. But when I send (te) as UTF8 symbol, it's still stored as "&12486;" and displayed as such. Me (through API): "storage=(te)(su)(to)" Server: Storage set: "&12486;&12473;&12488;" Me (through web interface): what's the storage? Server: "&12486;&12473;&12488;" Me (through web interface): storage=(te)(su)(to) Server: Storage set: "(te)(su)(to)" |
|
|
Fixed, I believe, for next update. You'll be able to use either the kana directly, OR the HTML encoding for storing MYLIST values. Retrieved values will be the kana itself. |
|
|
Note to readers: this applies to MYLIST strings only. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-01-04 16:13 | himself | New Issue | |
| 2012-01-04 16:16 | himself | Note Added: 0003266 | |
| 2012-02-08 09:44 | Ommina | Assigned To | => Ommina |
| 2012-02-08 09:44 | Ommina | Status | new => assigned |
| 2012-02-17 08:58 | Ommina | Note Added: 0003275 | |
| 2012-02-17 08:58 | Ommina | Status | assigned => feedback |
| 2012-02-17 09:01 | Ommina | Note Edited: 0003275 | |
| 2012-02-17 09:02 | Ommina | Note Edited: 0003275 | |
| 2012-02-17 09:03 | Ommina | Note Edited: 0003275 | |
| 2012-02-17 09:29 | himself | Note Added: 0003276 | |
| 2012-02-17 09:29 | himself | Status | feedback => assigned |
| 2012-02-17 10:17 | Ommina | Status | assigned => confirmed |
| 2012-02-20 10:51 | Ommina | Note Added: 0003280 | |
| 2012-02-20 10:51 | Ommina | Status | confirmed => resolved |
| 2012-02-20 10:51 | Ommina | Resolution | open => fixed |
| 2012-02-20 10:54 | Ommina | Note Added: 0003281 |
