zoukankan      html  css  js  c++  java
  • 需要中文版《The Scheme Programming Language》的朋友可以在此留言(内附一小段译文)

      首先给出原著的链接:http://www.scheme.com/tspl4/

      我正在持续翻译这本书,大概每天都会翻译两小时。若我个人拿不准的地方,我会附上原文,防止误导;还有些不适合翻译的术语,我会特意不翻译。

      想看翻译的人,可以在下面留言。发这篇博文,就是为了看看有多少人需要,我的翻译有没有公开的价值。

      若真有人需要,我可以把翻译不断分享给大家~


      在此先给出一小段译文,分享给大家。

      本段译文只在排版上于原著每段中加了些换行,别的均与原著保持了一致。


    Chapter 7. 输入和输出 

      所有的输入和输出操作都经由 端口 执行。
      端口就是(可能是无限大的)数据流的指针,这数据常为一个文件。
      流是一个通路,可供程序存取字节或字符。
      端口类型有:输入端口、输出端口、双向端口。

      端口是一等对象,和Scheme中的其他对象一样。
      端口没有供打印的表示方法(原文是have a printed representation)。
      有三个内置的端口:通用输入端口、通用输出端口、通用错误端口,
      分别连接到进程的:标准输入、标准输出、标准错误流。
      语言本身提供了很多种打开新的端口的方法。

      输入端口往往指向有限的流,例如存储在硬盘上的输入文件。
      如果一个输入操作(例如:get-u8get-charget-datum)从一个已达有限流末尾的端口读取,
      则会返回一个特殊的 eof (end of file) 对象
      谓词 eof-object? 可以用来判断输入操作的返回值是否是eof对象。

      端口类型有binarytextual
      binary端口允许程序于流中读写8-bit无符号字节、"octets,"。
      textual端口允许程序读写字符。

      很多时候,流被组织成字节序列, 但这些字节其实是字符的编码。
      此时,可以借助transcoder创建textual端口,从而在输入时将字节解码成字符、在输出时将字符编码成字节。
      transcoder内封装了codec,它确定了字符如何表示成字节。
      有三个标准的codec:latin-1 codec, Unicode utf-8 codec, Unicode utf-16 codec。
      在 latin-1 中,每个字符用一个字节表示。
      在 utf-8 中,每个字符用一到四个字节表示。
      在 utf-16 中,每个字符用两个或四个字节表示。

      transcoder内还封装了eol style,用来确定 识别哪种 以及 如何识别 行尾标志。
      如果 eol style 是 none,那么不识别任何一种行尾标志。
      另外六个标准 eol styles 如下所示:

    lf line-feed 换行字符
    cr carriage-return 回车字符
    nel Unicode next-line C-n字符
    ls Unicode line-separator 行分割字符
    crlf 换行字符+回车字符
    crnel C-n字符+回车字符

      不同的 eol style 下,输入输出操作也会不同。
      输入时,除 none 之外的所有 eol style 下,均会将 各种行尾标志 转换为 单换行字符。
      输出时,除 none 之外的所有 eol style 下,均会将 换行字符 转换为 各自风格的行尾标志。
      在输入方向,除 none 之外的所有 eol style 都是等价的;
      而在输出方向,则只有 none 和 lf 是等价的。

      除了 codec 和 eol style,transcoder内只还封装了一块信息:error-handling模式, 确定了当编码解码错误出现时,会如何处理。
      例如,在输入方向上,用封装的 codec 无法将一个字节序列转换成字符;
      或者,在输出方向上,用封装的 codec 无法将一个字符转换成字节序列。
      error-handling模式有:ignoreraisereplace
      在 ignore 模式下,出错的字节序列或字符会被忽略。
      在 raise 模式下,会抛出一个异常,类型是:i/o-decoding 或 i/o-encoding
      在输入方向,端口定位到字节序列之后。
      在 replace 模式下,会产生一个替换的字符或字符编码:
      在输入方向,替换字符是 U+FFFD,
      而在输出方向,替换字符则如下:
      当 codec 为 utf-8 或 utf-16 时,替换字符是 U+FFFD;
      当 codec 为 latin-1 时,替换字符则是 问号字符 ( ? )。

      为了效率,端口会有缓存机制, 从而消除向操作系统逐字节或字符取用的开销。
      标准的buffer模式有三个:blocklinenone
      在block模式下,将输入输出流分成很多块分别操作,每块流的大小与实现相关。
      在line模式下,缓存将构建成一行一行的,或者是实现相关的大小。
      上面这两种模式,仅在 textual输出端口 中有明显区别;
      因为 binary端口 中并不分行,而 输入 则往往在流开始可读时便直接读取了。
      在none模式下,没有缓存,因此会直接输出到流中,也仅在需要时才去输入。

      本章余下的内容有:
      transcoder上的操作、
      文件端口、标准端口、字符串和字节向量端口、自定义端口(custom ports)、
      通用端口操作、输入操作、输出操作、
      方便的输入输出、文件系统操作、字节向量和字符串的相互转换。

     

  • 相关阅读:
    log4net封装类
    (转)MySQL InnoDB 架构
    备份宽带不足,innobackupex备份导致从库不可写
    从库查询阻塞xtrabackup备份,应该是kill备份还是kill查询的问题
    rabbitmq群集安装
    MySQL索引选择问题(要相信MySQL自己选择索引的能力)
    binlog_format产生的延迟问题
    命令行登录mysql报Segmentation fault故障解决
    MySQL5.7.21启动异常的修复
    大查询对mha切换的影响
  • 原文地址:https://www.cnblogs.com/icedream61/p/5207009.html
Copyright © 2011-2022 走看看