[QFJ-38] FIX Message support double-byte charset. Created: 21/Jul/06 Updated: 02/Apr/15 Resolved: 09/Jun/14 |
|
Status: | Closed |
Project: | QuickFIX/J |
Component/s: | Engine |
Affects Version/s: | 1.0.1 |
Fix Version/s: | 1.6.0 |
Type: | New Feature | Priority: | Default |
Reporter: | Lejiang | Assignee: | amichair |
Resolution: | Fixed | Votes: | 0 |
Labels: | encoding |
Attachments: | Field.java Message.java MessageUtils.java | ||||||||||||||||||||||||||||||||
Issue Links: |
|
Description |
We use double-byte charset in no english country.QFJ get the fix message length using String.length(),get checksum using String.charAt().But these String method not support double-byte charset,e.g. GBK. In GBK encoding: We wish QFJ to support double-byte charset. |
Comments |
Comment by Steve Bate [ 26/Jul/06 ] |
Can you describe a little more how you are using multibyte charsets? Are you only placing the multibyte data in "Encoded*" FIX fields (e.g., EncodedText) or the entire FIX message? The patch makes it appear that you are encoding the entire message. |
Comment by Lejiang [ 27/Jul/06 ] |
Yes,the mutil-bytes charset chars are in the body fields of message,not only in the "encoded*" FIX fields. I'm working on the FIX Dialect(Subset) and its default charset is double-bytes charset--GBK. Now the primary problem is it. See more about this FIX Dialect,please refer to QF maillist:QFJ:The problems in definite a new protocol of FIX subset. We have changed some codes of QFJ to adapt this FIX Dialect.If the QFJ can directly support this feature,will be perfect for us. |
Comment by amichair [ 09/Jun/14 ] |
It should work now for any charset that is a superset of ASCII, which is most of them. The issue title is a bit misleading, since GBK (stated in description) is a multibyte charset that is backward-compatible with ASCII, and so should work now, whereas a double-byte charset such as UTF-16 will not (all double-byte charsets are by definition not backward-compatible with ASCII). The current solution uses the global CharsetSupport, but there is still no proper support for all (non-ASCII compatible) encodings, MessageEncoding fields, etc. I'll open a separate issue for that. |