[25] | 1 | '\" |
---|
| 2 | '\" Copyright (c) 1997 by Sun Microsystems, Inc. |
---|
| 3 | '\" |
---|
| 4 | '\" See the file "license.terms" for information on usage and redistribution |
---|
| 5 | '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES. |
---|
| 6 | '\" |
---|
| 7 | '\" RCS: @(#) $Id: binary.n,v 1.38 2008/01/02 21:21:37 dkf Exp $ |
---|
| 8 | '\" |
---|
| 9 | .so man.macros |
---|
| 10 | .TH binary n 8.0 Tcl "Tcl Built-In Commands" |
---|
| 11 | .BS |
---|
| 12 | '\" Note: do not modify the .SH NAME line immediately below! |
---|
| 13 | .SH NAME |
---|
| 14 | binary \- Insert and extract fields from binary strings |
---|
| 15 | .SH SYNOPSIS |
---|
| 16 | \fBbinary format \fIformatString \fR?\fIarg arg ...\fR? |
---|
| 17 | .br |
---|
| 18 | \fBbinary scan \fIstring formatString \fR?\fIvarName varName ...\fR? |
---|
| 19 | .BE |
---|
| 20 | .SH DESCRIPTION |
---|
| 21 | .PP |
---|
| 22 | This command provides facilities for manipulating binary data. The |
---|
| 23 | first form, \fBbinary format\fR, creates a binary string from normal |
---|
| 24 | Tcl values. For example, given the values 16 and 22, on a 32-bit |
---|
| 25 | architecture, it might produce an 8-byte binary string consisting of |
---|
| 26 | two 4-byte integers, one for each of the numbers. The second form of |
---|
| 27 | the command, \fBbinary scan\fR, does the opposite: it extracts data |
---|
| 28 | from a binary string and returns it as ordinary Tcl string values. |
---|
| 29 | .SH "BINARY FORMAT" |
---|
| 30 | .PP |
---|
| 31 | The \fBbinary format\fR command generates a binary string whose layout |
---|
| 32 | is specified by the \fIformatString\fR and whose contents come from |
---|
| 33 | the additional arguments. The resulting binary value is returned. |
---|
| 34 | .PP |
---|
| 35 | The \fIformatString\fR consists of a sequence of zero or more field |
---|
| 36 | specifiers separated by zero or more spaces. Each field specifier is |
---|
| 37 | a single type character followed by an optional flag character followed |
---|
| 38 | by an optional numeric \fIcount\fR. |
---|
| 39 | Most field specifiers consume one argument to obtain the value to be |
---|
| 40 | formatted. The type character specifies how the value is to be |
---|
| 41 | formatted. The \fIcount\fR typically indicates how many items of the |
---|
| 42 | specified type are taken from the value. If present, the \fIcount\fR |
---|
| 43 | is a non-negative decimal integer or \fB*\fR, which normally indicates |
---|
| 44 | that all of the items in the value are to be used. If the number of |
---|
| 45 | arguments does not match the number of fields in the format string |
---|
| 46 | that consume arguments, then an error is generated. The flag character |
---|
| 47 | is ignored for for \fBbinary format\fR. |
---|
| 48 | .PP |
---|
| 49 | Here is a small example to clarify the relation between the field |
---|
| 50 | specifiers and the arguments: |
---|
| 51 | .CS |
---|
| 52 | \fBbinary format\fR d3d {1.0 2.0 3.0 4.0} 0.1 |
---|
| 53 | .CE |
---|
| 54 | .PP |
---|
| 55 | The first argument is a list of four numbers, but because of the count |
---|
| 56 | of 3 for the associated field specifier, only the first three will be |
---|
| 57 | used. The second argument is associated with the second field |
---|
| 58 | specifier. The resulting binary string contains the four numbers 1.0, |
---|
| 59 | 2.0, 3.0 and 0.1. |
---|
| 60 | .PP |
---|
| 61 | Each type-count pair moves an imaginary cursor through the binary |
---|
| 62 | data, storing bytes at the current position and advancing the cursor |
---|
| 63 | to just after the last byte stored. The cursor is initially at |
---|
| 64 | position 0 at the beginning of the data. The type may be any one of |
---|
| 65 | the following characters: |
---|
| 66 | .IP \fBa\fR 5 |
---|
| 67 | Stores a byte string of length \fIcount\fR in the output string. |
---|
| 68 | Every character is taken as modulo 256 (i.e. the low byte of every |
---|
| 69 | character is used, and the high byte discarded) so when storing |
---|
| 70 | character strings not wholly expressible using the characters \eu0000-\eu00ff, |
---|
| 71 | the \fBencoding convertto\fR command should be used first to change |
---|
| 72 | the string into an external representation |
---|
| 73 | if this truncation is not desired (i.e. if the characters are |
---|
| 74 | not part of the ISO 8859\-1 character set.) |
---|
| 75 | If \fIarg\fR has fewer than \fIcount\fR bytes, then additional zero |
---|
| 76 | bytes are used to pad out the field. If \fIarg\fR is longer than the |
---|
| 77 | specified length, the extra characters will be ignored. If |
---|
| 78 | \fIcount\fR is \fB*\fR, then all of the bytes in \fIarg\fR will be |
---|
| 79 | formatted. If \fIcount\fR is omitted, then one character will be |
---|
| 80 | formatted. For example, |
---|
| 81 | .RS |
---|
| 82 | .CS |
---|
| 83 | \fBbinary format\fR a7a*a alpha bravo charlie |
---|
| 84 | .CE |
---|
| 85 | will return a string equivalent to \fBalpha\e000\e000bravoc\fR, |
---|
| 86 | .CS |
---|
| 87 | \fBbinary format\fR a* [encoding convertto utf-8 \eu20ac] |
---|
| 88 | .CE |
---|
| 89 | will return a string equivalent to \fB\e342\e202\e254\fR (which is the |
---|
| 90 | UTF-8 byte sequence for a Euro-currency character) and |
---|
| 91 | .CS |
---|
| 92 | \fBbinary format\fR a* [encoding convertto iso8859-15 \eu20ac] |
---|
| 93 | .CE |
---|
| 94 | will return a string equivalent to \fB\e244\fR (which is the ISO |
---|
| 95 | 8859\-15 byte sequence for a Euro-currency character). Contrast these |
---|
| 96 | last two with: |
---|
| 97 | .CS |
---|
| 98 | \fBbinary format\fR a* \eu20ac |
---|
| 99 | .CE |
---|
| 100 | which returns a string equivalent to \fB\e254\fR (i.e. \fB\exac\fR) by |
---|
| 101 | truncating the high-bits of the character, and which is probably not |
---|
| 102 | what is desired. |
---|
| 103 | .RE |
---|
| 104 | .IP \fBA\fR 5 |
---|
| 105 | This form is the same as \fBa\fR except that spaces are used for |
---|
| 106 | padding instead of nulls. For example, |
---|
| 107 | .RS |
---|
| 108 | .CS |
---|
| 109 | \fBbinary format\fR A6A*A alpha bravo charlie |
---|
| 110 | .CE |
---|
| 111 | will return \fBalpha bravoc\fR. |
---|
| 112 | .RE |
---|
| 113 | .IP \fBb\fR 5 |
---|
| 114 | Stores a string of \fIcount\fR binary digits in low-to-high order |
---|
| 115 | within each byte in the output string. \fIArg\fR must contain a |
---|
| 116 | sequence of \fB1\fR and \fB0\fR characters. The resulting bytes are |
---|
| 117 | emitted in first to last order with the bits being formatted in |
---|
| 118 | low-to-high order within each byte. If \fIarg\fR has fewer than |
---|
| 119 | \fIcount\fR digits, then zeros will be used for the remaining bits. |
---|
| 120 | If \fIarg\fR has more than the specified number of digits, the extra |
---|
| 121 | digits will be ignored. If \fIcount\fR is \fB*\fR, then all of the |
---|
| 122 | digits in \fIarg\fR will be formatted. If \fIcount\fR is omitted, |
---|
| 123 | then one digit will be formatted. If the number of bits formatted |
---|
| 124 | does not end at a byte boundary, the remaining bits of the last byte |
---|
| 125 | will be zeros. For example, |
---|
| 126 | .RS |
---|
| 127 | .CS |
---|
| 128 | \fBbinary format\fR b5b* 11100 111000011010 |
---|
| 129 | .CE |
---|
| 130 | will return a string equivalent to \fB\ex07\ex87\ex05\fR. |
---|
| 131 | .RE |
---|
| 132 | .IP \fBB\fR 5 |
---|
| 133 | This form is the same as \fBb\fR except that the bits are stored in |
---|
| 134 | high-to-low order within each byte. For example, |
---|
| 135 | .RS |
---|
| 136 | .CS |
---|
| 137 | \fBbinary format\fR B5B* 11100 111000011010 |
---|
| 138 | .CE |
---|
| 139 | will return a string equivalent to \fB\exe0\exe1\exa0\fR. |
---|
| 140 | .RE |
---|
| 141 | .IP \fBH\fR 5 |
---|
| 142 | Stores a string of \fIcount\fR hexadecimal digits in high-to-low |
---|
| 143 | within each byte in the output string. \fIArg\fR must contain a |
---|
| 144 | sequence of characters in the set |
---|
| 145 | .QW 0123456789abcdefABCDEF . |
---|
| 146 | The resulting bytes are emitted in first to last order with the hex digits |
---|
| 147 | being formatted in high-to-low order within each byte. If \fIarg\fR |
---|
| 148 | has fewer than \fIcount\fR digits, then zeros will be used for the |
---|
| 149 | remaining digits. If \fIarg\fR has more than the specified number of |
---|
| 150 | digits, the extra digits will be ignored. If \fIcount\fR is |
---|
| 151 | \fB*\fR, then all of the digits in \fIarg\fR will be formatted. If |
---|
| 152 | \fIcount\fR is omitted, then one digit will be formatted. If the |
---|
| 153 | number of digits formatted does not end at a byte boundary, the |
---|
| 154 | remaining bits of the last byte will be zeros. For example, |
---|
| 155 | .RS |
---|
| 156 | .CS |
---|
| 157 | \fBbinary format\fR H3H*H2 ab DEF 987 |
---|
| 158 | .CE |
---|
| 159 | will return a string equivalent to \fB\exab\ex00\exde\exf0\ex98\fR. |
---|
| 160 | .RE |
---|
| 161 | .IP \fBh\fR 5 |
---|
| 162 | This form is the same as \fBH\fR except that the digits are stored in |
---|
| 163 | low-to-high order within each byte. This is seldom required. For example, |
---|
| 164 | .RS |
---|
| 165 | .CS |
---|
| 166 | \fBbinary format\fR h3h*h2 AB def 987 |
---|
| 167 | .CE |
---|
| 168 | will return a string equivalent to \fB\exba\ex00\exed\ex0f\ex89\fR. |
---|
| 169 | .RE |
---|
| 170 | .IP \fBc\fR 5 |
---|
| 171 | Stores one or more 8-bit integer values in the output string. If no |
---|
| 172 | \fIcount\fR is specified, then \fIarg\fR must consist of an integer |
---|
| 173 | value. If \fIcount\fR is specified, \fIarg\fR must consist of a list |
---|
| 174 | containing at least that many integers. The low-order 8 bits of each integer |
---|
| 175 | are stored as a one-byte value at the cursor position. If \fIcount\fR |
---|
| 176 | is \fB*\fR, then all of the integers in the list are formatted. If the |
---|
| 177 | number of elements in the list is greater |
---|
| 178 | than \fIcount\fR, then the extra elements are ignored. For example, |
---|
| 179 | .RS |
---|
| 180 | .CS |
---|
| 181 | \fBbinary format\fR c3cc* {3 -3 128 1} 260 {2 5} |
---|
| 182 | .CE |
---|
| 183 | will return a string equivalent to |
---|
| 184 | \fB\ex03\exfd\ex80\ex04\ex02\ex05\fR, whereas |
---|
| 185 | .CS |
---|
| 186 | \fBbinary format\fR c {2 5} |
---|
| 187 | .CE |
---|
| 188 | will generate an error. |
---|
| 189 | .RE |
---|
| 190 | .IP \fBs\fR 5 |
---|
| 191 | This form is the same as \fBc\fR except that it stores one or more |
---|
| 192 | 16-bit integers in little-endian byte order in the output string. The |
---|
| 193 | low-order 16-bits of each integer are stored as a two-byte value at |
---|
| 194 | the cursor position with the least significant byte stored first. For |
---|
| 195 | example, |
---|
| 196 | .RS |
---|
| 197 | .CS |
---|
| 198 | \fBbinary format\fR s3 {3 -3 258 1} |
---|
| 199 | .CE |
---|
| 200 | will return a string equivalent to |
---|
| 201 | \fB\ex03\ex00\exfd\exff\ex02\ex01\fR. |
---|
| 202 | .RE |
---|
| 203 | .IP \fBS\fR 5 |
---|
| 204 | This form is the same as \fBs\fR except that it stores one or more |
---|
| 205 | 16-bit integers in big-endian byte order in the output string. For |
---|
| 206 | example, |
---|
| 207 | .RS |
---|
| 208 | .CS |
---|
| 209 | \fBbinary format\fR S3 {3 -3 258 1} |
---|
| 210 | .CE |
---|
| 211 | will return a string equivalent to |
---|
| 212 | \fB\ex00\ex03\exff\exfd\ex01\ex02\fR. |
---|
| 213 | .RE |
---|
| 214 | .IP \fBt\fR 5 |
---|
| 215 | .VS 8.5 |
---|
| 216 | This form (mnemonically \fItiny\fR) is the same as \fBs\fR and \fBS\fR |
---|
| 217 | except that it stores the 16-bit integers in the output string in the |
---|
| 218 | native byte order of the machine where the Tcl script is running. |
---|
| 219 | To determine what the native byte order of the machine is, refer to |
---|
| 220 | the \fBbyteOrder\fR element of the \fBtcl_platform\fR array. |
---|
| 221 | .VE 8.5 |
---|
| 222 | .IP \fBi\fR 5 |
---|
| 223 | This form is the same as \fBc\fR except that it stores one or more |
---|
| 224 | 32-bit integers in little-endian byte order in the output string. The |
---|
| 225 | low-order 32-bits of each integer are stored as a four-byte value at |
---|
| 226 | the cursor position with the least significant byte stored first. For |
---|
| 227 | example, |
---|
| 228 | .RS |
---|
| 229 | .CS |
---|
| 230 | \fBbinary format\fR i3 {3 -3 65536 1} |
---|
| 231 | .CE |
---|
| 232 | will return a string equivalent to |
---|
| 233 | \fB\ex03\ex00\ex00\ex00\exfd\exff\exff\exff\ex00\ex00\ex01\ex00\fR |
---|
| 234 | .RE |
---|
| 235 | .IP \fBI\fR 5 |
---|
| 236 | This form is the same as \fBi\fR except that it stores one or more one |
---|
| 237 | or more 32-bit integers in big-endian byte order in the output string. |
---|
| 238 | For example, |
---|
| 239 | .RS |
---|
| 240 | .CS |
---|
| 241 | \fBbinary format\fR I3 {3 -3 65536 1} |
---|
| 242 | .CE |
---|
| 243 | will return a string equivalent to |
---|
| 244 | \fB\ex00\ex00\ex00\ex03\exff\exff\exff\exfd\ex00\ex01\ex00\ex00\fR |
---|
| 245 | .RE |
---|
| 246 | .IP \fBn\fR 5 |
---|
| 247 | .VS 8.5 |
---|
| 248 | This form (mnemonically \fInumber\fR or \fInormal\fR) is the same as |
---|
| 249 | \fBi\fR and \fBI\fR except that it stores the 32-bit integers in the |
---|
| 250 | output string in the native byte order of the machine where the Tcl |
---|
| 251 | script is running. |
---|
| 252 | To determine what the native byte order of the machine is, refer to |
---|
| 253 | the \fBbyteOrder\fR element of the \fBtcl_platform\fR array. |
---|
| 254 | .VE 8.5 |
---|
| 255 | .IP \fBw\fR 5 |
---|
| 256 | This form is the same as \fBc\fR except that it stores one or more |
---|
| 257 | 64-bit integers in little-endian byte order in the output string. The |
---|
| 258 | low-order 64-bits of each integer are stored as an eight-byte value at |
---|
| 259 | the cursor position with the least significant byte stored first. For |
---|
| 260 | example, |
---|
| 261 | .RS |
---|
| 262 | .CS |
---|
| 263 | \fBbinary format\fR w 7810179016327718216 |
---|
| 264 | .CE |
---|
| 265 | will return the string \fBHelloTcl\fR |
---|
| 266 | .RE |
---|
| 267 | .IP \fBW\fR 5 |
---|
| 268 | This form is the same as \fBw\fR except that it stores one or more one |
---|
| 269 | or more 64-bit integers in big-endian byte order in the output string. |
---|
| 270 | For example, |
---|
| 271 | .RS |
---|
| 272 | .CS |
---|
| 273 | \fBbinary format\fR Wc 4785469626960341345 110 |
---|
| 274 | .CE |
---|
| 275 | will return the string \fBBigEndian\fR |
---|
| 276 | .RE |
---|
| 277 | .IP \fBm\fR 5 |
---|
| 278 | .VS 8.5 |
---|
| 279 | This form (mnemonically the mirror of \fBw\fR) is the same as \fBw\fR |
---|
| 280 | and \fBW\fR except that it stores the 64-bit integers in the output |
---|
| 281 | string in the native byte order of the machine where the Tcl script is |
---|
| 282 | running. |
---|
| 283 | To determine what the native byte order of the machine is, refer to |
---|
| 284 | the \fBbyteOrder\fR element of the \fBtcl_platform\fR array. |
---|
| 285 | .VE 8.5 |
---|
| 286 | .IP \fBf\fR 5 |
---|
| 287 | This form is the same as \fBc\fR except that it stores one or more one |
---|
| 288 | or more single-precision floating point numbers in the machine's native |
---|
| 289 | representation in the output string. This representation is not |
---|
| 290 | portable across architectures, so it should not be used to communicate |
---|
| 291 | floating point numbers across the network. The size of a floating |
---|
| 292 | point number may vary across architectures, so the number of bytes |
---|
| 293 | that are generated may vary. If the value overflows the |
---|
| 294 | machine's native representation, then the value of FLT_MAX |
---|
| 295 | as defined by the system will be used instead. Because Tcl uses |
---|
| 296 | double-precision floating point numbers internally, there may be some |
---|
| 297 | loss of precision in the conversion to single-precision. For example, |
---|
| 298 | on a Windows system running on an Intel Pentium processor, |
---|
| 299 | .RS |
---|
| 300 | .CS |
---|
| 301 | \fBbinary format\fR f2 {1.6 3.4} |
---|
| 302 | .CE |
---|
| 303 | will return a string equivalent to |
---|
| 304 | \fB\excd\excc\excc\ex3f\ex9a\ex99\ex59\ex40\fR. |
---|
| 305 | .RE |
---|
| 306 | .IP \fBr\fR 5 |
---|
| 307 | .VS 8.5 |
---|
| 308 | This form (mnemonically \fIreal\fR) is the same as \fBf\fR except that |
---|
| 309 | it stores the single-precision floating point numbers in little-endian |
---|
| 310 | order. This conversion only produces meaningful output when used on |
---|
| 311 | machines which use the IEEE floating point representation (very |
---|
| 312 | common, but not universal.) |
---|
| 313 | .VE 8.5 |
---|
| 314 | .IP \fBR\fR 5 |
---|
| 315 | .VS 8.5 |
---|
| 316 | This form is the same as \fBr\fR except that it stores the |
---|
| 317 | single-precision floating point numbers in big-endian order. |
---|
| 318 | .VE 8.5 |
---|
| 319 | .IP \fBd\fR 5 |
---|
| 320 | This form is the same as \fBf\fR except that it stores one or more one |
---|
| 321 | or more double-precision floating point numbers in the machine's native |
---|
| 322 | representation in the output string. For example, on a |
---|
| 323 | Windows system running on an Intel Pentium processor, |
---|
| 324 | .RS |
---|
| 325 | .CS |
---|
| 326 | \fBbinary format\fR d1 {1.6} |
---|
| 327 | .CE |
---|
| 328 | will return a string equivalent to |
---|
| 329 | \fB\ex9a\ex99\ex99\ex99\ex99\ex99\exf9\ex3f\fR. |
---|
| 330 | .RE |
---|
| 331 | .IP \fBq\fR 5 |
---|
| 332 | .VS 8.5 |
---|
| 333 | This form (mnemonically the mirror of \fBd\fR) is the same as \fBd\fR |
---|
| 334 | except that it stores the double-precision floating point numbers in |
---|
| 335 | little-endian order. This conversion only produces meaningful output |
---|
| 336 | when used on machines which use the IEEE floating point representation |
---|
| 337 | (very common, but not universal.) |
---|
| 338 | .VE 8.5 |
---|
| 339 | .IP \fBQ\fR 5 |
---|
| 340 | .VS 8.5 |
---|
| 341 | This form is the same as \fBq\fR except that it stores the |
---|
| 342 | double-precision floating point numbers in big-endian order. |
---|
| 343 | .VE 8.5 |
---|
| 344 | .IP \fBx\fR 5 |
---|
| 345 | Stores \fIcount\fR null bytes in the output string. If \fIcount\fR is |
---|
| 346 | not specified, stores one null byte. If \fIcount\fR is \fB*\fR, |
---|
| 347 | generates an error. This type does not consume an argument. For |
---|
| 348 | example, |
---|
| 349 | .RS |
---|
| 350 | .CS |
---|
| 351 | \fBbinary format\fR a3xa3x2a3 abc def ghi |
---|
| 352 | .CE |
---|
| 353 | will return a string equivalent to \fBabc\e000def\e000\e000ghi\fR. |
---|
| 354 | .RE |
---|
| 355 | .IP \fBX\fR 5 |
---|
| 356 | Moves the cursor back \fIcount\fR bytes in the output string. If |
---|
| 357 | \fIcount\fR is \fB*\fR or is larger than the current cursor position, |
---|
| 358 | then the cursor is positioned at location 0 so that the next byte |
---|
| 359 | stored will be the first byte in the result string. If \fIcount\fR is |
---|
| 360 | omitted then the cursor is moved back one byte. This type does not |
---|
| 361 | consume an argument. For example, |
---|
| 362 | .RS |
---|
| 363 | .CS |
---|
| 364 | \fBbinary format\fR a3X*a3X2a3 abc def ghi |
---|
| 365 | .CE |
---|
| 366 | will return \fBdghi\fR. |
---|
| 367 | .RE |
---|
| 368 | .IP \fB@\fR 5 |
---|
| 369 | Moves the cursor to the absolute location in the output string |
---|
| 370 | specified by \fIcount\fR. Position 0 refers to the first byte in the |
---|
| 371 | output string. If \fIcount\fR refers to a position beyond the last |
---|
| 372 | byte stored so far, then null bytes will be placed in the uninitialized |
---|
| 373 | locations and the cursor will be placed at the specified location. If |
---|
| 374 | \fIcount\fR is \fB*\fR, then the cursor is moved to the current end of |
---|
| 375 | the output string. If \fIcount\fR is omitted, then an error will be |
---|
| 376 | generated. This type does not consume an argument. For example, |
---|
| 377 | .RS |
---|
| 378 | .CS |
---|
| 379 | \fBbinary format\fR a5@2a1@*a3@10a1 abcde f ghi j |
---|
| 380 | .CE |
---|
| 381 | will return \fBabfdeghi\e000\e000j\fR. |
---|
| 382 | .RE |
---|
| 383 | .SH "BINARY SCAN" |
---|
| 384 | .PP |
---|
| 385 | The \fBbinary scan\fR command parses fields from a binary string, |
---|
| 386 | returning the number of conversions performed. \fIString\fR gives the |
---|
| 387 | input bytes to be parsed (one byte per character, and characters not |
---|
| 388 | representable as a byte have their high bits chopped) |
---|
| 389 | and \fIformatString\fR indicates how to parse it. |
---|
| 390 | Each \fIvarName\fR gives the name of a variable; when a field is |
---|
| 391 | scanned from \fIstring\fR the result is assigned to the corresponding |
---|
| 392 | variable. |
---|
| 393 | .PP |
---|
| 394 | As with \fBbinary format\fR, the \fIformatString\fR consists of a |
---|
| 395 | sequence of zero or more field specifiers separated by zero or more |
---|
| 396 | spaces. Each field specifier is a single type character followed by |
---|
| 397 | an optional flag character followed by an optional numeric \fIcount\fR. |
---|
| 398 | Most field specifiers consume one |
---|
| 399 | argument to obtain the variable into which the scanned values should |
---|
| 400 | be placed. The type character specifies how the binary data is to be |
---|
| 401 | interpreted. The \fIcount\fR typically indicates how many items of |
---|
| 402 | the specified type are taken from the data. If present, the |
---|
| 403 | \fIcount\fR is a non-negative decimal integer or \fB*\fR, which |
---|
| 404 | normally indicates that all of the remaining items in the data are to |
---|
| 405 | be used. If there are not enough bytes left after the current cursor |
---|
| 406 | position to satisfy the current field specifier, then the |
---|
| 407 | corresponding variable is left untouched and \fBbinary scan\fR returns |
---|
| 408 | immediately with the number of variables that were set. If there are |
---|
| 409 | not enough arguments for all of the fields in the format string that |
---|
| 410 | consume arguments, then an error is generated. The flag character |
---|
| 411 | .QW u |
---|
| 412 | may be given to cause some types to be read as unsigned values. The flag |
---|
| 413 | is accepted for all field types but is ignored for non-integer fields. |
---|
| 414 | .PP |
---|
| 415 | A similar example as with \fBbinary format\fR should explain the |
---|
| 416 | relation between field specifiers and arguments in case of the binary |
---|
| 417 | scan subcommand: |
---|
| 418 | .CS |
---|
| 419 | \fBbinary scan\fR $bytes s3s first second |
---|
| 420 | .CE |
---|
| 421 | .PP |
---|
| 422 | This command (provided the binary string in the variable \fIbytes\fR |
---|
| 423 | is long enough) assigns a list of three integers to the variable |
---|
| 424 | \fIfirst\fR and assigns a single value to the variable \fIsecond\fR. |
---|
| 425 | If \fIbytes\fR contains fewer than 8 bytes (i.e. four 2-byte |
---|
| 426 | integers), no assignment to \fIsecond\fR will be made, and if |
---|
| 427 | \fIbytes\fR contains fewer than 6 bytes (i.e. three 2-byte integers), |
---|
| 428 | no assignment to \fIfirst\fR will be made. Hence: |
---|
| 429 | .CS |
---|
| 430 | puts [\fBbinary scan\fR abcdefg s3s first second] |
---|
| 431 | puts $first |
---|
| 432 | puts $second |
---|
| 433 | .CE |
---|
| 434 | will print (assuming neither variable is set previously): |
---|
| 435 | .CS |
---|
| 436 | 1 |
---|
| 437 | 25185 25699 26213 |
---|
| 438 | can't read "second": no such variable |
---|
| 439 | .CE |
---|
| 440 | .PP |
---|
| 441 | It is \fIimportant\fR to note that the \fBc\fR, \fBs\fR, and \fBS\fR |
---|
| 442 | (and \fBi\fR and \fBI\fR on 64bit systems) will be scanned into |
---|
| 443 | long data size values. In doing this, values that have their high |
---|
| 444 | bit set (0x80 for chars, 0x8000 for shorts, 0x80000000 for ints), |
---|
| 445 | will be sign extended. Thus the following will occur: |
---|
| 446 | .CS |
---|
| 447 | set signShort [\fBbinary format\fR s1 0x8000] |
---|
| 448 | \fBbinary scan\fR $signShort s1 val; \fI# val == 0xFFFF8000\fR |
---|
| 449 | .CE |
---|
| 450 | If you require unsigned values you can include the |
---|
| 451 | .QW u |
---|
| 452 | flag character following |
---|
| 453 | the field type. For example, to read an unsigned short value: |
---|
| 454 | .CS |
---|
| 455 | set signShort [\fBbinary format\fR s1 0x8000] |
---|
| 456 | \fBbinary scan\fR $signShort su1 val; \fI# val == 0x00008000\fR |
---|
| 457 | .CE |
---|
| 458 | .PP |
---|
| 459 | Each type-count pair moves an imaginary cursor through the binary data, |
---|
| 460 | reading bytes from the current position. The cursor is initially |
---|
| 461 | at position 0 at the beginning of the data. The type may be any one of |
---|
| 462 | the following characters: |
---|
| 463 | .IP \fBa\fR 5 |
---|
| 464 | The data is a byte string of length \fIcount\fR. If \fIcount\fR |
---|
| 465 | is \fB*\fR, then all of the remaining bytes in \fIstring\fR will be |
---|
| 466 | scanned into the variable. If \fIcount\fR is omitted, then one |
---|
| 467 | byte will be scanned. |
---|
| 468 | All bytes scanned will be interpreted as being characters in the |
---|
| 469 | range \eu0000-\eu00ff so the \fBencoding convertfrom\fR command will be |
---|
| 470 | needed if the string is not a binary string or a string encoded in ISO |
---|
| 471 | 8859\-1. |
---|
| 472 | For example, |
---|
| 473 | .RS |
---|
| 474 | .CS |
---|
| 475 | \fBbinary scan\fR abcde\e000fghi a6a10 var1 var2 |
---|
| 476 | .CE |
---|
| 477 | will return \fB1\fR with the string equivalent to \fBabcde\e000\fR |
---|
| 478 | stored in \fIvar1\fR and \fIvar2\fR left unmodified, and |
---|
| 479 | .CS |
---|
| 480 | \fBbinary scan\fR \e342\e202\e254 a* var1 |
---|
| 481 | set var2 [encoding convertfrom utf-8 $var1] |
---|
| 482 | .CE |
---|
| 483 | will store a Euro-currency character in \fIvar2\fR. |
---|
| 484 | .RE |
---|
| 485 | .IP \fBA\fR 5 |
---|
| 486 | This form is the same as \fBa\fR, except trailing blanks and nulls are stripped from |
---|
| 487 | the scanned value before it is stored in the variable. For example, |
---|
| 488 | .RS |
---|
| 489 | .CS |
---|
| 490 | \fBbinary scan\fR "abc efghi \e000" A* var1 |
---|
| 491 | .CE |
---|
| 492 | will return \fB1\fR with \fBabc efghi\fR stored in \fIvar1\fR. |
---|
| 493 | .RE |
---|
| 494 | .IP \fBb\fR 5 |
---|
| 495 | The data is turned into a string of \fIcount\fR binary digits in |
---|
| 496 | low-to-high order represented as a sequence of |
---|
| 497 | .QW 1 |
---|
| 498 | and |
---|
| 499 | .QW 0 |
---|
| 500 | characters. The data bytes are scanned in first to last order with |
---|
| 501 | the bits being taken in low-to-high order within each byte. Any extra |
---|
| 502 | bits in the last byte are ignored. If \fIcount\fR is \fB*\fR, then |
---|
| 503 | all of the remaining bits in \fIstring\fR will be scanned. If |
---|
| 504 | \fIcount\fR is omitted, then one bit will be scanned. For example, |
---|
| 505 | .RS |
---|
| 506 | .CS |
---|
| 507 | \fBbinary scan\fR \ex07\ex87\ex05 b5b* var1 var2 |
---|
| 508 | .CE |
---|
| 509 | will return \fB2\fR with \fB11100\fR stored in \fIvar1\fR and |
---|
| 510 | \fB1110000110100000\fR stored in \fIvar2\fR. |
---|
| 511 | .RE |
---|
| 512 | .IP \fBB\fR 5 |
---|
| 513 | This form is the same as \fBb\fR, except the bits are taken in |
---|
| 514 | high-to-low order within each byte. For example, |
---|
| 515 | .RS |
---|
| 516 | .CS |
---|
| 517 | \fBbinary scan\fR \ex70\ex87\ex05 B5B* var1 var2 |
---|
| 518 | .CE |
---|
| 519 | will return \fB2\fR with \fB01110\fR stored in \fIvar1\fR and |
---|
| 520 | \fB1000011100000101\fR stored in \fIvar2\fR. |
---|
| 521 | .RE |
---|
| 522 | .IP \fBH\fR 5 |
---|
| 523 | The data is turned into a string of \fIcount\fR hexadecimal digits in |
---|
| 524 | high-to-low order represented as a sequence of characters in the set |
---|
| 525 | .QW 0123456789abcdef . |
---|
| 526 | The data bytes are scanned in first to last |
---|
| 527 | order with the hex digits being taken in high-to-low order within each |
---|
| 528 | byte. Any extra bits in the last byte are ignored. If \fIcount\fR is |
---|
| 529 | \fB*\fR, then all of the remaining hex digits in \fIstring\fR will be |
---|
| 530 | scanned. If \fIcount\fR is omitted, then one hex digit will be |
---|
| 531 | scanned. For example, |
---|
| 532 | .RS |
---|
| 533 | .CS |
---|
| 534 | \fBbinary scan\fR \ex07\exC6\ex05\ex1f\ex34 H3H* var1 var2 |
---|
| 535 | .CE |
---|
| 536 | will return \fB2\fR with \fB07c\fR stored in \fIvar1\fR and |
---|
| 537 | \fB051f34\fR stored in \fIvar2\fR. |
---|
| 538 | .RE |
---|
| 539 | .IP \fBh\fR 5 |
---|
| 540 | This form is the same as \fBH\fR, except the digits are taken in |
---|
| 541 | reverse (low-to-high) order within each byte. For example, |
---|
| 542 | .RS |
---|
| 543 | .CS |
---|
| 544 | \fBbinary scan\fR \ex07\ex86\ex05\ex12\ex34 h3h* var1 var2 |
---|
| 545 | .CE |
---|
| 546 | will return \fB2\fR with \fB706\fR stored in \fIvar1\fR and |
---|
| 547 | \fB502143\fR stored in \fIvar2\fR. |
---|
| 548 | .RE |
---|
| 549 | Note that most code that wishes to parse the hexadecimal digits from |
---|
| 550 | multiple bytes in order should use the \fBH\fR format. |
---|
| 551 | .IP \fBc\fR 5 |
---|
| 552 | The data is turned into \fIcount\fR 8-bit signed integers and stored |
---|
| 553 | in the corresponding variable as a list. If \fIcount\fR is \fB*\fR, |
---|
| 554 | then all of the remaining bytes in \fIstring\fR will be scanned. If |
---|
| 555 | \fIcount\fR is omitted, then one 8-bit integer will be scanned. For |
---|
| 556 | example, |
---|
| 557 | .RS |
---|
| 558 | .CS |
---|
| 559 | \fBbinary scan\fR \ex07\ex86\ex05 c2c* var1 var2 |
---|
| 560 | .CE |
---|
| 561 | will return \fB2\fR with \fB7 -122\fR stored in \fIvar1\fR and \fB5\fR |
---|
| 562 | stored in \fIvar2\fR. Note that the integers returned are signed, but |
---|
| 563 | they can be converted to unsigned 8-bit quantities using an expression |
---|
| 564 | like: |
---|
| 565 | .CS |
---|
| 566 | set num [expr { $num & 0xff }] |
---|
| 567 | .CE |
---|
| 568 | .RE |
---|
| 569 | .IP \fBs\fR 5 |
---|
| 570 | The data is interpreted as \fIcount\fR 16-bit signed integers |
---|
| 571 | represented in little-endian byte order. The integers are stored in |
---|
| 572 | the corresponding variable as a list. If \fIcount\fR is \fB*\fR, then |
---|
| 573 | all of the remaining bytes in \fIstring\fR will be scanned. If |
---|
| 574 | \fIcount\fR is omitted, then one 16-bit integer will be scanned. For |
---|
| 575 | example, |
---|
| 576 | .RS |
---|
| 577 | .CS |
---|
| 578 | \fBbinary scan\fR \ex05\ex00\ex07\ex00\exf0\exff s2s* var1 var2 |
---|
| 579 | .CE |
---|
| 580 | will return \fB2\fR with \fB5 7\fR stored in \fIvar1\fR and \fB\-16\fR |
---|
| 581 | stored in \fIvar2\fR. Note that the integers returned are signed, but |
---|
| 582 | they can be converted to unsigned 16-bit quantities using an expression |
---|
| 583 | like: |
---|
| 584 | .CS |
---|
| 585 | set num [expr { $num & 0xffff }] |
---|
| 586 | .CE |
---|
| 587 | .RE |
---|
| 588 | .IP \fBS\fR 5 |
---|
| 589 | This form is the same as \fBs\fR except that the data is interpreted |
---|
| 590 | as \fIcount\fR 16-bit signed integers represented in big-endian byte |
---|
| 591 | order. For example, |
---|
| 592 | .RS |
---|
| 593 | .CS |
---|
| 594 | \fBbinary scan\fR \ex00\ex05\ex00\ex07\exff\exf0 S2S* var1 var2 |
---|
| 595 | .CE |
---|
| 596 | will return \fB2\fR with \fB5 7\fR stored in \fIvar1\fR and \fB\-16\fR |
---|
| 597 | stored in \fIvar2\fR. |
---|
| 598 | .RE |
---|
| 599 | .IP \fBt\fR 5 |
---|
| 600 | .VS 8.5 |
---|
| 601 | The data is interpreted as \fIcount\fR 16-bit signed integers |
---|
| 602 | represented in the native byte order of the machine running the Tcl |
---|
| 603 | script. It is otherwise identical to \fBs\fR and \fBS\fR. |
---|
| 604 | To determine what the native byte order of the machine is, refer to |
---|
| 605 | the \fBbyteOrder\fR element of the \fBtcl_platform\fR array. |
---|
| 606 | .VE 8.5 |
---|
| 607 | .IP \fBi\fR 5 |
---|
| 608 | The data is interpreted as \fIcount\fR 32-bit signed integers |
---|
| 609 | represented in little-endian byte order. The integers are stored in |
---|
| 610 | the corresponding variable as a list. If \fIcount\fR is \fB*\fR, then |
---|
| 611 | all of the remaining bytes in \fIstring\fR will be scanned. If |
---|
| 612 | \fIcount\fR is omitted, then one 32-bit integer will be scanned. For |
---|
| 613 | example, |
---|
| 614 | .RS |
---|
| 615 | .CS |
---|
| 616 | set str \ex05\ex00\ex00\ex00\ex07\ex00\ex00\ex00\exf0\exff\exff\exff |
---|
| 617 | \fBbinary scan\fR $str i2i* var1 var2 |
---|
| 618 | .CE |
---|
| 619 | will return \fB2\fR with \fB5 7\fR stored in \fIvar1\fR and \fB\-16\fR |
---|
| 620 | stored in \fIvar2\fR. Note that the integers returned are signed, but |
---|
| 621 | they can be converted to unsigned 32-bit quantities using an expression |
---|
| 622 | like: |
---|
| 623 | .CS |
---|
| 624 | set num [expr { $num & 0xffffffff }] |
---|
| 625 | .CE |
---|
| 626 | .RE |
---|
| 627 | .IP \fBI\fR 5 |
---|
| 628 | This form is the same as \fBI\fR except that the data is interpreted |
---|
| 629 | as \fIcount\fR 32-bit signed integers represented in big-endian byte |
---|
| 630 | order. For example, |
---|
| 631 | .RS |
---|
| 632 | .CS |
---|
| 633 | set str \ex00\ex00\ex00\ex05\ex00\ex00\ex00\ex07\exff\exff\exff\exf0 |
---|
| 634 | \fBbinary scan\fR $str I2I* var1 var2 |
---|
| 635 | .CE |
---|
| 636 | will return \fB2\fR with \fB5 7\fR stored in \fIvar1\fR and \fB\-16\fR |
---|
| 637 | stored in \fIvar2\fR. |
---|
| 638 | .RE |
---|
| 639 | .IP \fBn\fR 5 |
---|
| 640 | .VS 8.5 |
---|
| 641 | The data is interpreted as \fIcount\fR 32-bit signed integers |
---|
| 642 | represented in the native byte order of the machine running the Tcl |
---|
| 643 | script. It is otherwise identical to \fBi\fR and \fBI\fR. |
---|
| 644 | To determine what the native byte order of the machine is, refer to |
---|
| 645 | the \fBbyteOrder\fR element of the \fBtcl_platform\fR array. |
---|
| 646 | .VE 8.5 |
---|
| 647 | .IP \fBw\fR 5 |
---|
| 648 | The data is interpreted as \fIcount\fR 64-bit signed integers |
---|
| 649 | represented in little-endian byte order. The integers are stored in |
---|
| 650 | the corresponding variable as a list. If \fIcount\fR is \fB*\fR, then |
---|
| 651 | all of the remaining bytes in \fIstring\fR will be scanned. If |
---|
| 652 | \fIcount\fR is omitted, then one 64-bit integer will be scanned. For |
---|
| 653 | example, |
---|
| 654 | .RS |
---|
| 655 | .CS |
---|
| 656 | set str \ex05\ex00\ex00\ex00\ex07\ex00\ex00\ex00\exf0\exff\exff\exff |
---|
| 657 | \fBbinary scan\fR $str wi* var1 var2 |
---|
| 658 | .CE |
---|
| 659 | will return \fB2\fR with \fB30064771077\fR stored in \fIvar1\fR and |
---|
| 660 | \fB\-16\fR stored in \fIvar2\fR. Note that the integers returned are |
---|
| 661 | signed and cannot be represented by Tcl as unsigned values. |
---|
| 662 | .RE |
---|
| 663 | .IP \fBW\fR 5 |
---|
| 664 | This form is the same as \fBw\fR except that the data is interpreted |
---|
| 665 | as \fIcount\fR 64-bit signed integers represented in big-endian byte |
---|
| 666 | order. For example, |
---|
| 667 | .RS |
---|
| 668 | .CS |
---|
| 669 | set str \ex00\ex00\ex00\ex05\ex00\ex00\ex00\ex07\exff\exff\exff\exf0 |
---|
| 670 | \fBbinary scan\fR $str WI* var1 var2 |
---|
| 671 | .CE |
---|
| 672 | will return \fB2\fR with \fB21474836487\fR stored in \fIvar1\fR and \fB\-16\fR |
---|
| 673 | stored in \fIvar2\fR. |
---|
| 674 | .RE |
---|
| 675 | .IP \fBm\fR 5 |
---|
| 676 | .VS 8.5 |
---|
| 677 | The data is interpreted as \fIcount\fR 64-bit signed integers |
---|
| 678 | represented in the native byte order of the machine running the Tcl |
---|
| 679 | script. It is otherwise identical to \fBw\fR and \fBW\fR. |
---|
| 680 | To determine what the native byte order of the machine is, refer to |
---|
| 681 | the \fBbyteOrder\fR element of the \fBtcl_platform\fR array. |
---|
| 682 | .VE 8.5 |
---|
| 683 | .IP \fBf\fR 5 |
---|
| 684 | The data is interpreted as \fIcount\fR single-precision floating point |
---|
| 685 | numbers in the machine's native representation. The floating point |
---|
| 686 | numbers are stored in the corresponding variable as a list. If |
---|
| 687 | \fIcount\fR is \fB*\fR, then all of the remaining bytes in |
---|
| 688 | \fIstring\fR will be scanned. If \fIcount\fR is omitted, then one |
---|
| 689 | single-precision floating point number will be scanned. The size of a |
---|
| 690 | floating point number may vary across architectures, so the number of |
---|
| 691 | bytes that are scanned may vary. If the data does not represent a |
---|
| 692 | valid floating point number, the resulting value is undefined and |
---|
| 693 | compiler dependent. For example, on a Windows system running on an |
---|
| 694 | Intel Pentium processor, |
---|
| 695 | .RS |
---|
| 696 | .CS |
---|
| 697 | \fBbinary scan\fR \ex3f\excc\excc\excd f var1 |
---|
| 698 | .CE |
---|
| 699 | will return \fB1\fR with \fB1.6000000238418579\fR stored in |
---|
| 700 | \fIvar1\fR. |
---|
| 701 | .RE |
---|
| 702 | .IP \fBr\fR 5 |
---|
| 703 | .VS 8.5 |
---|
| 704 | This form is the same as \fBf\fR except that the data is interpreted |
---|
| 705 | as \fIcount\fR single-precision floating point number in little-endian |
---|
| 706 | order. This conversion is not portable to the minority of systems not |
---|
| 707 | using IEEE floating point representations. |
---|
| 708 | .VE 8.5 |
---|
| 709 | .IP \fBR\fR 5 |
---|
| 710 | .VS 8.5 |
---|
| 711 | This form is the same as \fBf\fR except that the data is interpreted |
---|
| 712 | as \fIcount\fR single-precision floating point number in big-endian |
---|
| 713 | order. This conversion is not portable to the minority of systems not |
---|
| 714 | using IEEE floating point representations. |
---|
| 715 | .VE 8.5 |
---|
| 716 | .IP \fBd\fR 5 |
---|
| 717 | This form is the same as \fBf\fR except that the data is interpreted |
---|
| 718 | as \fIcount\fR double-precision floating point numbers in the |
---|
| 719 | machine's native representation. For example, on a Windows system |
---|
| 720 | running on an Intel Pentium processor, |
---|
| 721 | .RS |
---|
| 722 | .CS |
---|
| 723 | \fBbinary scan\fR \ex9a\ex99\ex99\ex99\ex99\ex99\exf9\ex3f d var1 |
---|
| 724 | .CE |
---|
| 725 | will return \fB1\fR with \fB1.6000000000000001\fR |
---|
| 726 | stored in \fIvar1\fR. |
---|
| 727 | .RE |
---|
| 728 | .IP \fBq\fR 5 |
---|
| 729 | .VS 8.5 |
---|
| 730 | This form is the same as \fBd\fR except that the data is interpreted |
---|
| 731 | as \fIcount\fR double-precision floating point number in little-endian |
---|
| 732 | order. This conversion is not portable to the minority of systems not |
---|
| 733 | using IEEE floating point representations. |
---|
| 734 | .VE 8.5 |
---|
| 735 | .IP \fBQ\fR 5 |
---|
| 736 | .VS 8.5 |
---|
| 737 | This form is the same as \fBd\fR except that the data is interpreted |
---|
| 738 | as \fIcount\fR double-precision floating point number in big-endian |
---|
| 739 | order. This conversion is not portable to the minority of systems not |
---|
| 740 | using IEEE floating point representations. |
---|
| 741 | .VE 8.5 |
---|
| 742 | .IP \fBx\fR 5 |
---|
| 743 | Moves the cursor forward \fIcount\fR bytes in \fIstring\fR. If |
---|
| 744 | \fIcount\fR is \fB*\fR or is larger than the number of bytes after the |
---|
| 745 | current cursor position, then the cursor is positioned after |
---|
| 746 | the last byte in \fIstring\fR. If \fIcount\fR is omitted, then the |
---|
| 747 | cursor is moved forward one byte. Note that this type does not |
---|
| 748 | consume an argument. For example, |
---|
| 749 | .RS |
---|
| 750 | .CS |
---|
| 751 | \fBbinary scan\fR \ex01\ex02\ex03\ex04 x2H* var1 |
---|
| 752 | .CE |
---|
| 753 | will return \fB1\fR with \fB0304\fR stored in \fIvar1\fR. |
---|
| 754 | .RE |
---|
| 755 | .IP \fBX\fR 5 |
---|
| 756 | Moves the cursor back \fIcount\fR bytes in \fIstring\fR. If |
---|
| 757 | \fIcount\fR is \fB*\fR or is larger than the current cursor position, |
---|
| 758 | then the cursor is positioned at location 0 so that the next byte |
---|
| 759 | scanned will be the first byte in \fIstring\fR. If \fIcount\fR |
---|
| 760 | is omitted then the cursor is moved back one byte. Note that this |
---|
| 761 | type does not consume an argument. For example, |
---|
| 762 | .RS |
---|
| 763 | .CS |
---|
| 764 | \fBbinary scan\fR \ex01\ex02\ex03\ex04 c2XH* var1 var2 |
---|
| 765 | .CE |
---|
| 766 | will return \fB2\fR with \fB1 2\fR stored in \fIvar1\fR and \fB020304\fR |
---|
| 767 | stored in \fIvar2\fR. |
---|
| 768 | .RE |
---|
| 769 | .IP \fB@\fR 5 |
---|
| 770 | Moves the cursor to the absolute location in the data string specified |
---|
| 771 | by \fIcount\fR. Note that position 0 refers to the first byte in |
---|
| 772 | \fIstring\fR. If \fIcount\fR refers to a position beyond the end of |
---|
| 773 | \fIstring\fR, then the cursor is positioned after the last byte. If |
---|
| 774 | \fIcount\fR is omitted, then an error will be generated. For example, |
---|
| 775 | .RS |
---|
| 776 | .CS |
---|
| 777 | \fBbinary scan\fR \ex01\ex02\ex03\ex04 c2@1H* var1 var2 |
---|
| 778 | .CE |
---|
| 779 | will return \fB2\fR with \fB1 2\fR stored in \fIvar1\fR and \fB020304\fR |
---|
| 780 | stored in \fIvar2\fR. |
---|
| 781 | .RE |
---|
| 782 | .SH "PORTABILITY ISSUES" |
---|
| 783 | The \fBr\fR, \fBR\fR, \fBq\fR and \fBQ\fR conversions will only work |
---|
| 784 | reliably for transferring data between computers which are all using |
---|
| 785 | IEEE floating point representations. This is very common, but not |
---|
| 786 | universal. To transfer floating-point numbers portably between all |
---|
| 787 | architectures, use their textual representation (as produced by |
---|
| 788 | \fBformat\fR) instead. |
---|
| 789 | .SH EXAMPLES |
---|
| 790 | This is a procedure to write a Tcl string to a binary-encoded channel as |
---|
| 791 | UTF-8 data preceded by a length word: |
---|
| 792 | .CS |
---|
| 793 | proc \fIwriteString\fR {channel string} { |
---|
| 794 | set data [encoding convertto utf-8 $string] |
---|
| 795 | puts -nonewline [\fBbinary format\fR Ia* \e |
---|
| 796 | [string length $data] $data] |
---|
| 797 | } |
---|
| 798 | .CE |
---|
| 799 | .PP |
---|
| 800 | This procedure reads a string from a channel that was written by the |
---|
| 801 | previously presented \fIwriteString\fR procedure: |
---|
| 802 | .CS |
---|
| 803 | proc \fIreadString\fR {channel} { |
---|
| 804 | if {![\fBbinary scan\fR [read $channel 4] I length]} { |
---|
| 805 | error "missing length" |
---|
| 806 | } |
---|
| 807 | set data [read $channel $length] |
---|
| 808 | return [encoding convertfrom utf-8 $data] |
---|
| 809 | } |
---|
| 810 | .CE |
---|
| 811 | .SH "SEE ALSO" |
---|
| 812 | format(n), scan(n), tclvars(n) |
---|
| 813 | .SH KEYWORDS |
---|
| 814 | binary, format, scan |
---|