Details
-
Type: Bug
-
Status: Open
-
Priority: Default
-
Resolution: Unresolved
-
Affects Version/s: 1.6.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
QuickFIX/J currently has limited support for alternate encodings (charsets). While it is 'good enough' for some cases, it still has drawbacks - it is limited to charsets that are a superset of ASCII (in particular, double-byte encodings are not supported), the encoding can only be set globally via CharsetSupport and applies to all fields (which can generate non-compliant messages), the engine still uses Strings for the most part with some awkward and inefficient handling to make it properly support encoded bytes, etc.
It would be better to have proper encoding support all around - with ASCII used for all standard fields, the MessageEncoding field used per-message to specify the encoding used in its Encoded* fields (e.g. EncodedText), using bytes array (or ByteBuffer) instead of Strings for more efficient and direct manipulation, supporting arbitrary charsets (not only ASCII supersets), etc.
Suggestions, additional related requirements and protocol-compliance corrections are welcome.
Attachments
Issue Links
- is duplicated by
-
QFJ-956 Checksum validation of incoming messages is not correct in some cases
- Closed