The Wrong Capitalization of Letters in URLs Can Cause Page Access Failure—A Trick for Using an INI File to Solve Case Problems in AutoHotkey

In an effort to take advantage of the hidden index built into the AutoHotkey.com site, I’ve started writing a script I call AutoHotkeyQuickReg.ahk which parses the downloaded pages. The first step involved those searches which downloaded a command page.

The original version of the AutoHotkey Quick Reference script pops up a MsgBox which displays the syntax of the command, then offers the option to open the Web page in the default browser. Recently, I added a new feature which parses and displays information about the built-in AutoHotkey variables whenever detecting the “Variables and Expressions” page. However, I had to find a way to deal with the problem of letter case (capitalization) sensitivity. Get it wrong and either the Web page doesn’t come up or the right data won’t load.

Applications with Letter Case Sensitivity Problems

As a scripting language, AutoHotkey is not case sensitive. To AutoHotkey, an uppercase R works the same as a lowercase r. This makes the language very forgiving, but not all of the computing world works that way. For example, when it comes to capitalization, JavaScript, the Web language used to extend the power of HTML, demands case consistency. For The most part, the Web page language HTML doesn’t care about letter case—except for the situations discussed in this blog.

*          *          *

New to AutoHotkey? See “Introduction to AutoHotkey: A Review and Guide for Beginners.”

*          *          *

Often Web pages won’t respond unless the addresses use the right letter case. That’s because most sites run on Linux or other Unix-like servers. Linux is case sensitive. However, if you happen to access a Windows Web server, then the case of the address characters won’t matter.

For example, computoredge.com runs on a Linux server. If you enter in all lowercase:

http://www.computoredge.com/autohotkey/downloads/

a Web page address error page displays. However, if formatted with the proper capitalization, the correct page loads:

http://www.computoredge.com/AutoHotkey/Downloads/

Many Web servers fix this problem with a redirect which corrects the URL as long as the letters match. (I have yet to do this for ComputorEdge.com.) However, if a site is case sensitive, then there are ways to protect against errors. One page commonly loaded by the hidden index search includes “Variables and Expressions” which contains special case-sensitivity problems.

I’ve noted that with the restoration of the AutoHotkey.com hidden index, AutoHotkey.com most often corrects the case of URLs. However, within a page without an exact case match, anchor jumps (e.g. …htm#yweek) fail.

Case Sensitivity within Web Pages

While most of the HTML source code within a Web page ignores a letter’s case, a few parameters don’t. For example, the ID parameter, which acts as an internal anchor, found within certain tags must conform exactly to the original case when used in the URL:

<tr id="Sec">

This HTML Table Row tag <tr> found in the”Variables and Expressions” page on AutoHotkey.com includes the anchor id=”Sec” as a jump within a page. When added to the following URL the browser immediately repositions the loaded page within the browser to the anchor location:

https://autohotkey.com/docs/Variables.htm#Sec

However, appending the ID with all lowercase letters (#sec) does nothing:

https://autohotkey.com/docs/Variables.htm#sec

This presents a problem when highlighting text to parse information about a variable. Get the case wrong and the search fails.

Initially, capitalizing the first letter of the clipboard text seemed like a possible solution, but too many of the variables contain multiple uppercase letters both in the variable and the anchor ID (e.g. A_TickCount and TickCount). The problem gets worse when you note that AutoHotkey variables start with A_, while the anchor IDs only use the remaining portion of the variable name. The quick reference needs to work for both A_Now and Now—regardless of case. I looked for a way to ensure that the case format of the ID remained consistent. I settled upon using an INI lookup table to correct case problems.

Note: While other techniques exist for ignoring case problems in Regular Expressions—in particular adding the i) option to the beginning of the RegEx causing the expression to become case insensitive—using the following INI file approach offers other advantages discussed at the end of this blog.

Changing Letter Case with INI Files

Most INI files (e.g. filename.ini), Windows text files used primarily for reading initial settings when loading programs, normally contain settings needed by an app. However, I found that the built-in AutoHotkey capability for reading INI files (INIRead command) offered a simple way to create a lookup table for correcting case sensitive syntax.

Note: While the simplicity of the INI file in AutoHotkey makes it attractive for use in many scripts, it does not necessarily represent the best way to manipulate saved file data in AutoHotkey. In many apps, using commands such as FileAppend and FileRead in conjunction with the Comma Separated Values (CSV) file format offers much more flexibility—although slightly more complex techniques.

For example, the book AutoHotkey Applications includes discussions about how to use CSV files in the AddressBook.ahk script (e.g. Chapter Eleven, “The Address Book App (ListView, Right-Click Menus, CSV Data File, and E-mail)”), the CalorieCount.ahk script (e.g. Chapter Sixteen “Manipulating Data Files in a Variable for CalorieCount (ListView, FileRead)”), and the RecipeTree.ahk script (e.g. Chapter Eighteen (“Building a Recipe Book with TreeView, Part II (CSV File Format for Data)”). Each script includes additional chapters addressing data manipulation methods with CSV files.

An INI file contains only text—readable and editable by any text editor. The structure of an INI file includes two levels of identification: the Section Name and Keys. When writing or editing an INI file the Section Names always appear within square brackets ([section name]) while the Keys equate to a Value (e.g. StartValue=1):

[SectionName]
Key=Value

All Keys assigned to a particular Section must fall in a list directly below the Section Name.

When reading an INI file, AutoHotkey first locates the Section, then the corresponding Key:

IniRead, OutputVar, Filename, Section, Key

Using an INI file works as a lookup table for correcting the case of IDs because the search key is not case sensitive while OutputVar always returns the exact case stored in the file. For example, if I set up a partial INI with the section name Variables and add keys for the Web page anchor IDs locating the built-in time/date variables:

[Variables]
YYYY=YYYY
MM=MM
DD=DD
MMMM=MMMM
MMM=MMM
DDDD=DDDD
DDD=DDD
WDay=WDay
YDay=YDay
YWeek=YWeek
Hour=Hour
Min=Min
Sec=Sec
MSec=MSec
Now=Now
NowUTC=NowUTC

the command to find the WDay ID can call any combination of upper and lowercase letters (i.e. “wday”, “wDay”, “WdaY”, etc), but always returns the proper case format to OutputVar (“WDay”):

IniRead, OutputVar, VarList, Variables, wday

Since I parsed the INI file keys directly from the “Variables and Expressions” page source code, the IniRead command returns the proper case for every anchor ID contained in the page. (Next time, I discuss how I quickly created the parsed anchor ID list with Ryan’s RegEx Tester.)

This INI system works well and may come in handy for other application. I originally started down the INI file lookup table path when the AutoHotkey.com secret index temporarily disappeared. At that time, the site’s built-in case insensitivity in the URLs had also gone fishing. I planned to use these INI file techniques with commands as well as variables. With the return of the hidden AutoHotkey.com index, I thought I had left the INI approach behind. However, parsing problems with the “Variables and Expressions” page bought it back.

Add More to the INI File

As I mentioned earlier, using the i) option in the primary RegExReplace() function makes the entire expression case insensitive. This might make the highlighted INI file technique obsolete except for one addition advantage. More useful keys may be included in the file.

For example, if I highlight the word “week” and execute the AutoHotkey Quick Ref.ahk hotkey (^!m),  rather than popping up the YWeek MsgBox window, it directly loads the entire Web page in the default browser. Since no “Week” anchor ID exists in the “Variables and Expressions” page, the script defaults to loading the page. This can be remedied by adding “Week” as an additional key to the INI file:

[Variables]
YYYY=YYYY
MM=MM
DD=DD
day=DD
MMMM=MMMM
MMM=MMM
DDDD=DDDD
DDD=DDD
WDay=WDay
YDay=YDay
YWeek=YWeek
Week=YWeek
Hour=Hour
Min=Min
Sec=Sec
MSec=MSec
Now=Now
NowUTC=NowUTC

Now, rather than jumping directly to the browser, highlighting “week” (or “day” for the A_DD variable) in any document and using the hotkey pops open the window showing the variable definition.

Next time, we use Ryan’s RegEx Tester for quick-and-dirty data extraction to create the INI file.