In Dart there is a literal for hex but not for binary numbers?
// bin
print(0b00001); // Too many positional arguments: 1 expected, but 2 found. (Documentation)
// Hex
print(0x0001);
I know that I can use:
var number = int.parse("00001", radix: 2);
But why is there no literal?
Related
I have this escaped string:
\u0414\u043B\u044F \u043F\u0440\u043E\u0434\u0430\u0436\u0438
\u043D\u0435\u0434\u0432\u0438\u0436\u0438\u043C\u043E\u0441\u0442\u0438
If I do:
print('\u0414\u043B\u044F \u043F\u0440\u043E\u0434\u0430\u0436\u0438 \u043D\u0435\u0434\u0432\u0438\u0436\u0438\u043C\u043E\u0441\u0442\u0438');
Console will show me:
Для продажи недвижимости
But if I get escaped 2 times string from the server:
\\u0414\\u043B\\u044F
\\u043F\\u0440\\u043E\\u0434\\u0430\\u0436\\u0438
\\u043D\\u0435\\u0434\\u0432\\u0438\\u0436\\u0438\\u043C\\u043E\\u0441\\u0442\\u0438
And do some replace job:
var result = string.replaceAll(new RegExp(r'\\'), r'\');
Compiler will not decode those characters and will show same escaped string:
print(result);
Console:
\u0414\u043B\u044F \u043F\u0440\u043E\u0434\u0430\u0436\u0438
\u043D\u0435\u0434\u0432\u0438\u0436\u0438\u043C\u043E\u0441\u0442\u0438
How I can remove those redunant slashes?
In string literals in Dart source files, \u0414 is a literal representing a unicode code point, whereas in the case of data returned from the server, you're just getting back a string containing backslashes, us, and digits that looks like a bunch of unicode code point literals.
The ideal fix is to have your server return the UTF-8 string you'd like to display rather than a string that uses Dart's string literal syntax that you need to parse. Writing a proper parser for such strings is fairly involved. You can take a look at unescapeCodeUnits in the Dart SDK for an example.
A very inefficient (not to mention entirely hacky and unsafe for real-world use) means of decoding this particular string would be to extract the string representations of the unicode codepoints with a RegExp parse the hex to an int, then use String.fromCharCode().
Note: the following code is absolutely not safe for production use and doesn't match other valid Dart code point literals such as \u{1f601}, or reject entirely invalid literals such as \uffffffffff.
// Match \u0123 substrings (note this will match invalid codepoints such as \u123456789).
final RegExp r = RegExp(r'\\\\u([0-9a-fA-F]+)');
// Sample string to parse.
final String source = r'\\u0414\\u043B\\u044F \\u043F\\u0440\\u043E\\u0434\\u0430\\u0436\\u0438 \\u043D\\u0435\\u0434\\u0432\\u0438\\u0436\\u0438\\u043C\\u043E\\u0441\\u0442\\u0438';
// Replace each \u0123 with the decoded codepoint.
final String decoded = source.replaceAllMapped(r, (Match m) {
// Extract the parenthesised hex string. '\\u0123' -> '123'.
final String hexString = m.group(1);
// Parse the hex string to an int.
final int codepoint = int.parse(hexString, radix: 16);
// Convert codepoint to string.
return String.fromCharCode(codepoint);
});
I'm having issues working with iOS Swift 2.0 to perform an XOR on a [UInt8] and convert the XORd result to a String. I'm having to interface with a crude server that wants to do simple XOR encryption with a predefined array of UInt8 values and return that result as a String.
Using iOS Swift 2.0 Playground, create the following array:
let xorResult : [UInt8] = [24, 48, 160, 212] // XORd result
let result = NSString(bytes: xorResult, length: xorResult.count, encoding: NSUTF8StringEncoding)
The result is always nil. If you remove the 160 and 212 values from the array, NSString is not nil. If I switch to NSUTF16StringEncoding then I do not receive nil, however, the server does not support UTF16. I have tried converting the values to a hex string, then converting the hex string to NSData, then try to convert that to NSUTF8StringEncoding but still nil until I remove the 160 and 212. I know this algorithm works in Java, however in Java we're using a combination of char and StringBuilder and everything is happy. Is there a way around this in iOS Swift?
To store an arbitrary chunk of binary data as as a string, you need
a string encoding which maps each single byte (0 ... 255) to some
character. UTF-8 does not have this property, as for example 160
is the start of a multi-byte UTF-8 sequence and not valid on its own.
The simplest encoding with this property is the ISO Latin 1 aka
ISO 8859-1, which is the
ISO/IEC 8859-1
encoding when supplemented with the C0 and C1 control codes.
It maps the Unicode code points U+0000 .. U+00FF
to the bytes 0x00 .. 0xFF (compare 8859-1.TXT).
This encoding is available for
(NS)String as NSISOLatin1StringEncoding.
Please note: The result of converting an arbitrary binary chunk to
a (NS)String with NSISOLatin1StringEncoding will contain embedded
NUL and control characters. Some functions behave unexpectedly
when used with such a string. For example, NSLog() terminates the
output at the first embedded NUL character. This conversion
is meant to solve OP's concrete problem (creating a QR-code which
is recognized by a 3rd party application). It is not meant as
a universal mechanism to convert arbitrary data to a string which may
be printed or presented in any way to the user.
string.format (formatstring, ···)
Returns a formatted version of its variable number of arguments following the description given in its first argument (which must be a string). The format string follows the same rules as the ISO C function sprintf. The only differences are that the options/modifiers *, h, L, l, n, and p are not supported and that there is an extra option, q.
Lua 5.3 doesn't support lld, how can I print lld in Lua 5.3?
Short answer: use %d.
In C sprintf, %lld is used to format a long long type, which is an integer type at least 64 bit.
In Lua 5.3, the type number has two internal representations, integer and float. Integer representation is 64-bit in standard Lua. You can use %d to print it no matter its internal representation:
print(string.format("%d", 2^62))
Output: 4611686018427387904
In Lua source file luaconf.h, you can see that Lua converts %d to the approapriate format:
#define LUA_INTEGER_FMT "%" LUA_INTEGER_FRMLEN "d"
and LUA_INTEGER_FRMLEN is defined as "", "l" or "ll" if different internal representation for integer is used:
#if defined(LLONG_MAX) /* { */
/* use ISO C99 stuff */
#define LUA_INTEGER long long
#define LUA_INTEGER_FRMLEN "ll"
//...
Should Lua string.format( "%c", value ) be equivalent to string.char( value )?
It seems not when character value is zero.
string.format( "%c", 0 ):len()
returns 0
string.char( 0 ):len()
returns 1
Even stranger,
string.format( "%c%s", 0, "abc" ):len()
returns 3; where any other non-zero-modulo-256 value for %c returns 4, so string.format is not truncating the whole string at null byte like C sprintf, just collapsing %c field to empty string instead of one-byte string. Note that C sprintf writes the zero byte followed by the abc bytes in this case.
I couldn't find anything in the Lua docs describing expected behavior in this case. Most other string handling in Lua seems to treat zero byte as valid string character.
This is on Lua 5.1.4-8 on OpenWrt.
Idiosyncracy or bug?
I think this is a bug.
In Lua 5.1 and LuaJIT 2.0, string.format formats one item at a time (using the sprintf provided by the host C runtime.) It then calls strlen to update the length of the output string. Since strlen stops at the null character, this character will be overwritten.
This is documented behaviour for %s, but probably unintentional for %c
This is fixed in Lua 5.2. I wouldn't expect any more updates to 5.1.
In the book "programming in lua" 2nd edition. In the chapter 2.4, there are some context like below:
"Strings in Lua have the usual meaning: a sequence of characters. Lua is
eight-bit clean and its strings may contain characters with any numeric code,
including embedded zeros. This means that you can store any binary data into
a string.
"
So this is not a bug
In Erlang how do I convert a string to a binary value?
String = "Hello"
%% should be
Binary = <<"Hello">>
In Erlang strings are represented as a list of integers. You can therefore use the list_to_binary (built-in-function, aka BIF). Here is an example I ran in the Erlang console (started with erl):
1> list_to_binary("hello world").
<<"hello world">>
the unicode (utf-8/16/32) character set needs more number of bits to express characters that are greater than 1-byte in length:
this is why the above call failed for any byte value > 255 (the limit of information that a byte can hold, and which is sufficient for IS0-8859/ASCII/Latin1)
to correctly handle unicode characters you'd need to use
unicode:characters_to_binary() R1[(N>3)]
instead, which can handle both Latin1 AND unicode encoding.
HTH ...